Mailing List Archive

On Tue, 14 Jun 2005 17:50:32 +0100, Adam Langley said:

> With libgcrypt 1.2.1 there is a message boundary bug. In short,
> E('abc') will cause E(ctr) to be calculated and the last 13 bytes to
> be discarded. E('def') will use another, fresh, E(ctr+1) and will
> discard another 13 bytes. This is incorrect (by [1] above, and by
> OpenSSL's implementation)

Thanks for reporting and for the patch. However, to apply this patch
we need to get a copyright assignment for the FSF from you. That is a
bit of a lengthly process so maybe we better fix it for ourself. If
you are willing to sign a such an assignment (or a disclaimer) anyway
and save us some work, please contact me by private mail.


Shalom-Salam,

Werner

On 6/17/05, Werner Koch <wk@gnupg.org> wrote:
> Thanks for reporting and for the patch. However, to apply this patch
> we need to get a copyright assignment for the FSF from you. That is a
> bit of a lengthly process so maybe we better fix it for ourself. If
> you are willing to sign a such an assignment (or a disclaimer) anyway
> and save us some work, please contact me by private mail.

The patch is tiny, so if the copyright assignment is a pain it might
well be easier to close your eyes and type it in again.

I should point out that since submitting the patch it has been noted
that the NIST is contradictory on the subject of counter mode. There
are documents which suggest that the current libgcrypt implementation
is correct and some that favour my patch.

My recommendation would be to either
1) drop the patch and make a big note in the documentation that the
implemented cipher mode is not suitable for use as a stream cipher.
2) implement stream counter mode (e.g. my patch) as a separate mode.

Sorry about the confusion.


AGL

--
Adam Langley agl@imperialviolet.org
http://www.imperialviolet.org (+44) (0)7906 332512
PGP: 9113 256A CC0F 71A6 4C84 5087 CDA5 52DF 2CB6 3D60

Adam Langley <alangley@gmail.com> writes:

> I should point out that since submitting the patch it has been noted
> that the NIST is contradictory on the subject of counter mode. There
> are documents which suggest that the current libgcrypt implementation
> is correct and some that favour my patch.

The current libgcrypt implementation was done (by me) according to
<http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf>.
There are even self tests against the test vectors in tests/simple.c.

I'm not aware of any contradictory Counter mode description published
by NIST. Can you give some more information?

> [1] http://csrc.nist.gov/CryptoToolkit/modes/workshop1/papers/lipmaa-ctr.pdf

That is one input paper, hardly authoritative. However, if your patch
implement their idea of Counter mode, it may certainly be that it is
useful too. Maybe you can ask them if they have come up with another
name of their mode, given the conflict.

> My recommendation would be to either
> 1) drop the patch and make a big note in the documentation that the
> implemented cipher mode is not suitable for use as a stream cipher.
> 2) implement stream counter mode (e.g. my patch) as a separate mode.

Both approaches sound better than changing the current implementation.

Cheers,
Simon

On Fri, 17 Jun 2005 19:53:06 +0100, Adam Langley said:

> I should point out that since submitting the patch it has been noted
> that the NIST is contradictory on the subject of counter mode. There
> are documents which suggest that the current libgcrypt implementation
> is correct and some that favour my patch.

Hmmm, I have no current use for CTR so I don't have a real opinion.
Simon implemented it and thus he should decide.

> 2) implement stream counter mode (e.g. my patch) as a separate mode.

To keep backwards compatibility that is a better solution.

Thanks,

Werner