Re: Electronic Codebook/Cipher Block Chaining/Cipher Feedback/ Output Feedback

From: David A. Scott (daVvid_a_scott_at_email.com)
Date: 12/30/03 

Date: 30 Dec 2003 15:16:04 GMT

nospam@technosoft21.com (Benjamin Choi) wrote in
news:7eeb3109.0312300142.4b25e967@posting.google.com:

> How about CBC? CBC works fine with a constant IV, and you don't have
> to worry about periods. The only problem is that you may have to do
> some padding. Probably you could pad with random bits, but first
> measure the plaintext length as a 128-bit integer, encrypt it and send
> it as an extra block. Then you can snip out the padding after
> decryption easily.

   Actually this is harder than you suspect. Since it must be done in
a way to give no information to the attacker. One way if you have a
source of "random data" is to always fill the last block with random
data then add an additonal random block of data. This last block
is such that you only use a random number in a range that matches your
likely ending pad. In other words if your using 16 byte blocks but the
file types you encrypt are always in mutliples of 2 and at that you still
have more multples of 4, You would chop the possbile random numbers up
in weight ranges such that those more likey to occur would have a greater
range in this case the odd ranges would not exist and the 4,8,12,16 ranges
would be double that of the 2,6,10,14 ranges. If you don't know or assume
they are the same you could make them the same or even select a range and
encrypt the last block a second time with the same key or a special key
just for padding.

    The problems of sending a length even if encrypted with a second key
is this. Note that one could blindly test the key searching for a solution
but your leaking information in that most keys if you could test them
would lead to an integer that was not possible meaining the key could be
rejected.

   Example say you don't padd but encrypt a purely random message of 160
bytes. Use a random IV and CBC mode so that you send exactly 11 blocks.
Any key the oponent tests. Maybe he got it from torture or scanning you
hardrive or whatever. He hay no way of knowing if the key is corrent
since random data was encrypted and very key tested leads to a possible
set of data that could be the original data encrypted. But it may only
appeared to be random it could have been text compressed with say LZW3s
but they would not know and would be unlikely to test unless they had
other reasons to belive the key was the correct key.

   Know take the same example. But add a length as a 16 byte word.
That only has this single number. You than encrypt it with your
second key the the padding key. True the attacker will be looking
for two keyes instead of one. And if the main encrypt key is found
and not the other. The attacker would only have 16 possible plain
text message to test or worry about. But if he searchs you harddrive
or under torture you reaval the two keys they could be tested.
If the two keys lead to something where the returning number is in
a reasonable range. They would assume you gave the correct keys
since it would be very hard to come up with the wrong keys. That could
even lead to a possible number that was valid. At this point of course
since the data looks white but they sure its correct they may ask hay we
know you gave is the correct keys so this is that data. Did you
compress this from one of Scott's bijective compressors or what?

   If you used may way of random padding. Every two sets of keys leads
to something possible. So they gain no information. Sure if the data
was readable text. They could eyeball it as ascii in all three cases.
But they would have to check in your case they only need to check
the number. That would catch the ascii or whatever kind of weird
file that's encrypted. Maybe you tried compressing with pkzip and removed
the 2 starting characters. No matter what you made it weaker by your
padding method.

> --
> Benjamin Choi
>

David A. Scott 

-- 
My Crypto code
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott16u.zip
http://www.jim.com/jamesd/Kong/scott19u.zip old version
My Compression code http://bijective.dogma.net/
**TO EMAIL ME drop the roman "five" **
Disclaimer:I am in no way responsible for any of the statements
 made in the above text. For all I know I might be drugged.
As a famous person once said "any cryptograhic
system is only as strong as its weakest link"

Relevant Pages

  • Re: Padding twice in GCM - why?
    ... to a block boundary with zeros *twice*, first at the end of the ... "AAD", and then again at the end ... lot of padding at the end of the ciphertext. ... In the encrypt direction, a pipelined implementation of GCM (and GCM was ...
    (sci.crypt)
  • RE: AES 128 CryptEncrypt problem ,help me thanks
    ... The reason you see this is because by default block encryption is done with ... If you really want to (eg. you do your own padding and you communicate the ... recommended to use ECB mode. ... BLOCK size which AES_128 can encrypt by once is 16byte. ...
    (microsoft.public.platformsdk.security)
  • Re: How to encrypt a data small than 128 bits
    ... say from 4 bytes to 256 bytes; but AES uses to encrypt 128 ... Look up "block cypher modes"to see how to use a block cypher for text ... For padding there are two common methods. ... For CTR mode you do not need padding as a block cypher in CTR mode is ...
    (sci.crypt)
  • Re: Crypto problems in Vista
    ... Calling CryptGetKeyParam() was revealing... ... The ciphertext is ALWAYS longer than the plaintext. ... If the plaintext I encrypt is always 128 bits, ... for padding, but I cannot switch it off. ...
    (microsoft.public.platformsdk.security)
  • Re: Padding Problem UPDATE (Still broken)
    ... > problem on the Perl end, and any encrypted e-mail I create I can retrieve ... > The problem comes when my Java program tries to decrypt the file created ... but I'm assuming Padding is just the padding of data on the end. ... and now use this to encrypt: ...
    (comp.lang.perl.misc)