Re: Phil Zimmermann's suggestion for large ciphers

[Werner Koch <wk@xxxxxxxxxxxxxxxxx>]

hal@xxxxxxxx writes:

> Phil suggests that we take advantage of the fact that when we go to large
> block ciphers like Twofish, there are no backwards-compatibility issues.

Please note that the RFC already handles ciphers with different
blocksizes; the only problem ist that there are some glitches in the
specification.  

> The plaintext would be followed by a SHA-1 hash of the plaintext data.

To avoid the need to create new packet types in the future (maybe there will
be a demand for a larger sized digest algorithm or someone likes to
replace SHA-1 by RIPE-MD160) we should at least encode a version number
in the encrypted data packet. 
 
> This gives us a standard CFB mode, with a standard IV; a simple form of
> redundancy at the beginning to verify the correct key; and a SHA-1 hash

Keep the Zero-IV and extend the current scheme.  Implementions must
already cope with this to be compatible with rfc2440 and there is no
security risk with this.

> Larger ciphers must use the new format.  Again, this is a perfect

  If a cipher with id >= 7 is listed in the preferences an
  implementations SHOULD use the new format.

I think there are no implementations which are yet using those
ciphers, so we can easily fix it without breaking rfc2440 too much.

> opportunity to make this change because large ciphers won't be backwards
> compatible, anyway.

But they are compatible with rfc2440 - despite the fact that we don't
have a cipher id for those official assigned (except the reserved ones
for AES).

> originated with the other.  What we want is simple integrity protection.
> For this purpose there is no need for a shared secret and it is

Right.

> Another issue is whether to use a fixed hash like SHA-1 rather than
> allowing the specification of a hash algorithm in the header.  There is
> no need for variable hash algorithms in this context.  The attacker does

"There will never be the need for more than 640k of RAM" ;-)

We have already specified hash preferences which may be utilized to 
use a different hash algorithm.  So it would be wise to encrypt a 
version number, the type of MDC used and the hash algorithm with the
encrypted text.  We are already prefixing the message with some random
bytes and a kind of checksum; we can simple add those additional 
information and don't increase the risk of a known plaintext attack as
the structure of the data which follows is anyway known (literal data
packet or compressed data packet).


-- 
Werner Koch at guug.de           www.gnupg.org           keyid 621CC013