Re: ECB+CTR Mode?
From: Tom St Denis (tomstdenis_at_iahu.ca)
Date: 08/11/03
- Next message: Michael Amling: "Re: new hash algorithm"
- Previous message: John E. Hadstate: "Re: ECB+CTR Mode?"
- In reply to: John E. Hadstate: "Re: ECB+CTR Mode?"
- Next in thread: John E. Hadstate: "Re: ECB+CTR Mode?"
- Reply: John E. Hadstate: "Re: ECB+CTR Mode?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 11 Aug 2003 14:08:23 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
John E. Hadstate wrote:
| "Mark Wooding" <mdw@nsict.org> wrote in message
| news:slrnbjf0ad.u6.mdw@tux.nsict.org...
|
|>John E. Hadstate <nospam@null.nil> wrote:
|>
|>
|>>CTR mode has the same shortcoming as all stream ciphers: the CT stream
|>>must be authenticated. This causes an expansion of the ciphertext.
|>
|>Ummm... your mode needs authenticating if it's going to resist chosen-
|>ciphertext attacks. But in fact it doesn't even resist chosen-
|>plaintext: it leaks descending sequences.
|>
|
|
| Actually, it leaks other sequences too. See Paul Rubin's response.
|
| I may have hit on a variation that allows authentication and
| integrity-checking without expanding the CT. The assumption would be that
| the application processing the decrypted PT contains some "sanity
checking"
| to ensure that decrypted "garbage" is caught.
"sanity checking" is exactly what a MAC provides.
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/N6NUsP+tEsHHY0ARAs8yAJ97GLZ4klIYBjWEESBKVEMyhceNoQCfVMEs
fLh0h7ZNoXaiM12rO6daPW8=
=XUFG
-----END PGP SIGNATURE-----
- Next message: Michael Amling: "Re: new hash algorithm"
- Previous message: John E. Hadstate: "Re: ECB+CTR Mode?"
- In reply to: John E. Hadstate: "Re: ECB+CTR Mode?"
- Next in thread: John E. Hadstate: "Re: ECB+CTR Mode?"
- Reply: John E. Hadstate: "Re: ECB+CTR Mode?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|