hal(_at_)rain(_dot_)org 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