Agreed all around. Also there is a '6' in my post where there should be a '64'.
Great minds think alike. <g> Charles From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Matt Caswell (fr...@baggins.org) Sent: Tuesday, August 21, 2012 9:35 AM To: openssl-users@openssl.org Subject: Re: OpenSSL DES generates '\n' in encrypted code On 21 August 2012 14:14, 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. Actually, I think you mean multiply the first character's value by n, and add the second. Multiply the result by n and add the third etc. Just before you sent this, I was just thinking of exactly the same algorithm!! 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.) Yes - it could 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. Your target character space does not have to be the same size as your input character space. If the target character space is bigger by a sufficient amount then this is not a problem.
