Here's how I call CRYPT.VCX to encrypt data:

*========================================================================================
* Encrypts a string with a password and returns the 
* encrypted result.
*========================================================================================
LParameter tcData, tcPassword

	Local loCrypt, lcEncrypted, llOK

	loCrypt = NewObject("_CryptApi",Home()+"FFC\_Crypt.vcx")
	lcEncrypted = ""
	llOK = .T.

	llOK = loCrypt.EncryptSessionBlockString( ;
		 m.tcData, m.tcPassword, @lcEncrypted )
	If not m.llOK
		lcEncrypted = NULL
	EndIf
	
Return m.lcEncrypted

You pass in data and a password. The opposite direction is

*========================================================================================
* Decrypts a string with a password and returns the result 
* back as plain text
*========================================================================================
LParameter tcEncrypted, tcPassword

	Local loCrypt, lcData, llOK

	loCrypt = NewObject("_CryptApi",Home()+"FFC\_Crypt.vcx")
	lcData = ""
	llOK = .T.

	llOK = loCrypt.DecryptSessionBlockString( ;
		m.tcEncrypted, m.tcPassword, @lcData )
	If not m.llOK
		lcData = NULL
	EndIf
	
Return m.lcData

This uses block-wise encryption. As such the string is always padded up to the block size, which is 8 bytes using the default configuration. That means any field length has to be a multiple of 8. Theoretically, you could avoid this by using a stream cipher which returns encrypted data of the same length as the original string. A stream cipher is a huge security problem which is why I wouldn't recommend using one.