We are beating this to death but one problem is that the encoded string is not an exact number even of *bits* (except for favorable values of 'n').
I don't know what is so fascinating about this problem but I was thinking about it again this morning. There may be 94 *possible* characters but any given string has at most 24 unique characters. I don't know if it is possible to exploit that fact in some way. It also occurred to me that perhaps the OP does not *really* need encryption. If so, there are "obfuscation" techniques that would be much simpler to implement than encryption and might satisfy management, auditors, or whoever is driving this requirement -- and would inherently produce "printable" output of 24 characters. They would make the string not obviously a password, social security number, or whatever it is now. If the OP is interested, please respond and I will elaborate. Keep in mind than an awful lot of homegrown encryption implementations are a lot weaker than they seem. You can use AES256, but if the key is stored in some file that would be relatively easy for a rogue employee to get into, then your security is a lot "less than AES256." Charles -----Original Message----- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Ben Laurie Sent: Tuesday, August 21, 2012 1:47 PM To: openssl-users@openssl.org Subject: Re: OpenSSL DES generates '\n' in encrypted code On Tue, Aug 21, 2012 at 2:14 PM, Charles Mills <charl...@mcn.org> wrote: > Actually, there IS *almost* a general solution to this problem. > > The input consists of characters from some set of 'n' characters. (Perhaps 'n' is 94 -- 0x21 through 0x7e inclusive -- but it does not matter.) You need to pack those characters with maximum density. It's conceptually the easiest if 'n' is 64, but basically you convert each character to an integer from 0 to 'n', and multiply the first character's value times the second's times the third's, etc., until you have done all 24. You have a problem dealing with the leftover bits when you overflow whatever size integer your system supports, but it is a solvable problem. (Perhaps OpenSSL BN will help with this; I don't know.) Now you end up with a string of somewhat less than 24 bytes: 18 if 'n' is 6, 20 if n is 94. (Actually 19.2 bytes, which is going to be the problem.) > > Encrypt the 20 bytes (into 20 bytes). Now reverse the process: divide the result by 'n' and represent the remainder as one of your 'n' legal characters; repeat until you have converted the whole string. Unfortunately, because of that leftover .8 byte you are going to end up with 25 characters. *Almost* a solution. > > If you can figure out a way to encrypt 19.2 bytes into 19.2 bytes rather than 20 you have it solved. Doesn't CFB mode work at the bit level? Also, CTR mode can be used for partial bytes. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
