function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

“Unrecognized base64 character: \ ” base64decode from Private Key / IV stored in custom settings

I have been able to encrypt and decrypt the body of some JSON requests being sent to and from and a ruby on rails app hosted elsewhere by hardcoding the private key and the IV inside my code as follows:

    string keystring = 'theyKEYrandomstringhereendswith\n';
    string IVstring = 'theIVrandomstringhereendswith\n';
    blob key= EncodingUtil.base64Decode(keystring);
    blob IV = EncodingUtil.base64Decode(IVstring);
    blob responsetoparseblob2 = crypto.decrypt('AES256',key,IV,responsetoparseblob);

No problems here, except of course that I shouldn't hardcode things like this, but rather place the key and iv in a custom settings object and take the values from there, as follows:

    list<Encryption__c> decrypt = [select key__c,iv__c from Encryption__c where Name='Decrypt' limit 1];
    string key = decrypt[0].key__c;
    string iv =  decrypt[0].iv__c;
    Blob keyval = EncodingUtil.base64Decode(key);
    Blob ivval = EncodingUtil.base64Decode(iv);

Where encryption__c does have the record with the appropriate key and IV. The Key and IV values themselves end with \n.
When the code is executed, I get a "System.StringException: Unrecognized base64 character: \" error on the base64decode lines. This only occurs now that I am pulling these values from a text field in custom settings, but as mentioned earlier, when i just base64decode the key/iv directly, there is no such error.
I have my speculations as to why this is happening, but I'm still not able to resolve it. I tried adding a backslash to perhaps unescape this backslash, only to get a similar error:
"common.apex.runtime.impl.ExecutionException: Unrecognized base64 character: \\\"

Does a value being stored in a field and then stored as a string differ from the same value being stored directly as a string? Is there another function that I should be using to convert the string once it is pulled from custom settings, or is there a daft mistake I am making here that is not apparent to me? Thank you!



EncodingUtil.base46Decode method will decode an already encoded Base64 String....But in your case - you are trying to decode a plain string that has '\' character in it. Because Base64 encoded keys will not have ' \ ' character(Ref:Wiki) in them, if you'll always be storing a normal string in that custom setting that ends with ' \n ' then you need to encode it into Base64 before you can decode it.

//Put the values in Default Organization Level of your custom setting
final Encryption__c decrypt = Encryption__c.getOrgDefaults();
String KeyString = EncodingUtil.base64Encode(Blob.valueOf(decrypt.key__c));
String IvString = EncodingUtil.base64Encode(Blob.valueOf(decrypt.iv__c)); Blob keyval = EncodingUtil.base64Decode(keyString); Blob ivval = EncodingUtil.base64Decode(IvString);

Can I ask, If the values you are storing in custom setting are already encoded to Base64 then how & why do they have ' \n ' at the end.





That's a very good question. We are generating those IVs and Keys from some ruby code on the target app. Seems like no matter how many times we try to generate one it always has that \ near the end.


The key/iv i'm using already is base64encoded and in that form has the \ near the end.


If base64 decode isn't meant to handle the \ at all, I'm still surprised that it handles the hardcoded version successfully...


Furthermore, we were able to do a workaround by double encoding the key/iv on the rails side, and then i double decoded it on my end:


store the double encoded version in custom settings.

base64decode it --> blob ---> tostring --> base64decode ---> blob used in decryption method.


There is something "different" about decoding this directly from a string, or setting it as a string from a field value.. and I am puzzled by this onconsistency!


"You're doing it wrong" may be the final answer here, which I am amenable to as well :)