Re: ECB-Counter AES mode

Karl Malbrain wrote:
"Phil Carmody" <thefatphil_demunged@xxxxxxxxxxx> wrote in message news:878wr3zaxv.fsf@xxxxxxxxxxxxxxxxxxxxxxx
"Karl Malbrain" <malbrain@xxxxxxxxx> writes:
"Phil Carmody" <thefatphil_demunged@xxxxxxxxxxx> wrote in message
news:87hc5rzbjo.fsf@xxxxxxxxxxxxxxxxxxxxxxx
"Karl Malbrain" <malbrain@xxxxxxxxx> writes:
"David Eather" <eather@xxxxxxxxxx> wrote in message
news:hOqdnVML1bSaxa3UnZ2dnUVZ_t_inZ2d@xxxxxxxxxxxxxxxx
Karl Malbrain wrote:
Is there an obvious weakness I'm overlooking in empressing a
sequential counter value over the plain text block with XOR prior
to AES encryption and removing the counter value after AES
decryption?

Thanks, Karl m

Some applications like databases may have sequential numbers which
when xored with your counter may cause some information leakage.
IIRC BS mentions this briefly in "practical crypto"

Thanks. The counter then should start with some 128 bit random value.

Nope. The bottom-most bits are still liable to be in sync with
the bottom-most bits of any DB counter. All you're doing is
changing the phase, not removing the correlation entirely.

The counter is 128 bits, the same as the block size. In any event,
could you elaborate on how the correlation could be exploited? How is
it different than, at best, obtaining a plain-text/cypher text
correlation?

No I wouldn't; I was simply warning that shifting your counter
will not remove whatever correlation you accepted as an undesirable
risk earlier.

What would an acceptable level of risk be for determining that two 16 byte plaintexts are sequential in value? The pigeon hole property says 2^64 for this correlation. I guess that's sufficient.

karl m

The correct way "according to Hoyle" is to hash the counter value before xoring into the plaintext and xoring the hash out after the encryption.


The sort of information leak you could get is if the 128 bit block contained data plus a record number - aaa...aaa 0001 , aaa...aaa 0002, etc would after the first xor be something like aaa...aaa NNNN, aaa...aaa NNNN and hence would encrypt to the same value - telling all about which entries contain the same data. (I assume the idea for the xor of the counter was to stop this happening)
.

Relevant Pages

  • Re: ECB-Counter AES mode
    ... sequential counter value over the plain text block with XOR prior ... to AES encryption and removing the counter value after AES ... not removing the correlation entirely. ... xoring into the plaintext and xoring the hash out after the encryption. ...
    (sci.crypt)
  • Re: ECB-Counter AES mode
    ... Karl Malbrain wrote: ... sequential counter value over the plain text block with XOR prior ... not removing the correlation entirely. ... before xoring into the plaintext and xoring the hash out after the encryption. ...
    (sci.crypt)
  • Encryption A97
    ... I've been playing with some encryption code from the web ... and have been pleased with this sample code from Rob Bovey. ... Essentially it takes a string and puts it through an XOR process and saves ...
    (microsoft.public.access.modulesdaovba)
  • Re: What is the name of this cipher algorithm?
    ... The first method seeds the encryption ... originalKey will not be well-mixed into the state (unless MIXES is ... Looks like RC4 plus a weird almost-periodic XOR of 'M_subKey'. ...
    (sci.crypt)
  • Re: Fast Encryption
    ... However, the program could easily be used to store passwords, etc. ... When I started using encryption for my shareware protection, I was struck by how many partially documented solutions there are. ... If only casual encryption is required, you won't find much faster than a simple XOR algorithm. ...
    (microsoft.public.vc.mfc)