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
