A couple of years ago I built a mIRC script to encrypt text based around OTP. It's not as secure as a true OTP as it uses pads of a set length as it's "keys", so if the message length exceeds the pad length, it will loop back round to the start of the pad and carry on. To counteract this somewhat, it uses TWO pads at the same time and alternates between them (well it's not quite that simple but still). Also, as it's designed to encrypt text, it shuffles the words around, but in such a way that it can unshuffle them again. In addtion, it performs rotary bitshifts either left or right, but again in such a way that it still knows which way to bitshift to decrypt.
If you have access to the algorithm then the shuffling, the bitshifting, and the other protection mechanisms are uesless in security terms. However, if you gain access to the pads without the algorithm, they provide another layer of encryption to be broken.
One standard method to break weak encryption is to look for possible patterns of letters. For example, in a simple substitution scheme you might notice that "iu" appears often, and conclude that this represents "th". This then gives you pointers to additional patterns, and so on. While it's not quite that simple, the same attack can be used against OTPs where the pad length is shorter than the message. The shorter the pad in comparison to the message, the greater the scope for attack.
Word shuffling does nothing to prevent this method of attack (although it does provide confusion by not producing a sensible sentance), but bitshifting and the use of two pads at varying rates (it's not a simple case of letter 1 uses value 1 of pad 1, letter 2 uses value 1 of pad 2, letter 3 uses value 2 of pad 1, etc) does do a reasonable job of screwing this attack vector up.
Quote:
|
Originally Posted by hyfe
Yeah, but if the transmitting the one-time pad fails, you can always try again with a new one. The message won't have been compromised.
|
This is the encrypted version of the above quote:
Quote:
|
Originally Posted by crypto output
5F7S7C7145310G271J5631632U513H3M40334T70122H3D6P7T2P3P0B5E52271S70126L5E4I24191P085F4N4O7T58250H2A17 0C5A5N4O6O6M6U101B385C483C0E7J104A3I546M6C3N3K7F4P7B5K61166A6H0825571B6N7F541R3R6E2C7I513F2K6U3R081F 4P1B5J145F6N681E6F7U5B3G372B4G2T560F6A7447216B6R384N504T5O2Q0E114A556L
|
Unfortunately, due to limitations about what data values mIRC can display and store, the encrypted output is in double zero padded base 32* instead of bytewise binary (ie. 8 zero padded base 2), making it longer than the plaintext when saved to disk. This appears to violate one of the general principals of encryption - the encryption should not alter the length of the message. However, follow the previous asterix to find out why this is not quite as bad as it seems.
If you are interested, you can find the script
here. Hyfe's post was encrypted using the two default pads contained in the zip file, so if you want you can actually follow the algorithm all the way through on paper.
* ie. 1 becomes "01", 255 becomes "7V", 25 becomes "0P" and 32 becomes "10". The zero padding is there to ensure that each value of the message is a group of two characters. This ensures that it can be decrypted, as otherwise I would have no way of knowing which values were a single character in length and which were a group of two. This way they are
always in groups of two.
If you divide the length of the encrypted message by two, you have the length, in bytes, of the original message. The extra length is caused by the difference in representation, NOT by the encryption algorithm.