hal(_at_)rain(_dot_)org writes:
1 byte version (should be 1)
This is probably a good idea. If perturbed by an attacker to a later
Yes and the reason for this is simply to extend the range of possible
packet formats (view it as a packet subtype).
attacker could execute a rollback attack by changing a V2 to a V1.
We can deal with that at that time by making sure that V2 and V1 look
And he could also do this by changing the packet type.
1 byte MDC method (should be 2 to match SHA, or 0 to disable MDC)
This one worries me. It allows an attacker to turn a 2 into a 0. Also,
I see your point. The reason I suggest this is that there are a lot
of people who prefer to use RIPE-MD160 and this way we have te
opportunity to do just this. The packet format may also be used for
some very small applications which use a subset of OpenPGP and don't
implement SHA1 at all. My solution to this is to say in the standard,
that this SHOULD be SHA1 and an implementation SHOULD fail if this
condition is not met.
whether it is a messed up message by an attacker. If we choose a fixed
hash algorithm this ambiguity cannot arise.
I guess we will have new hash algorithms with a larger digest size in the
near future and this way we can more easily extend the specs to make
it possible to use this hash (Frankly, don't see any need in a MDC for
a larger hash, but if some one wants and has only implemented this
larger hash ...).
1 byte number of extra bytes (m) at the end of the encrypted text
From now on CFB encrypted with an IV of all zeroes without
any strange syncing.
This is fine for automatic parsing of messages to let the parse know
how may bytes he has to hold back.
terms of explaining what we are doing to others in the field. The "pseudo
IV" we have now is hard to explain. I had to go to some lengths in
getting our FIPS 140 certification (a standard security certification)
I can't remember that the Internet Standards Process (BCP9) or our
chapter says anything about FIPS certification. PGPG is a widely
deployed quasi-standard and believed to be really good secure.
If you need some certification it is matter of your company to work
it out.
2 byte the last two bytes of the random data.
You have not shown whether these are encrypted. I presume that they are,
Ah sure. It is what we are currently using.
My proposal was that we have four bytes, two random ones and then those
same two random ones repeated. These would all be encrypted. It's not
But that will be not better than the current practice. It is okay for
PK encryption but when using a symmetric-only encryption it may not
detect wrong passphrases in all cases. But okay, we catch this with
the MDC and therefore I think it is good enough.
Make the "pseudo-IV" prefix partially non-random - i.e. the last two
bytes being checksum for the other 14. No big deal security-wise and
noticeable help in detecting the right key.
This isn't too bad for 128 bit block ciphers like Twofish or AES, but as
a general principle we would need to apply it to all ciphers, including
64 bit block ciphers. I don't like taking away 16 of the 64 bits of IV
So we could always use 128 bits and use only the lower half for 64 bit
blocksize ciphers. But okay, with the MDC we don't really need it.
I agree that it would be sensible to encourage the new format when we go
to new block ciphers. Unfortunately the next version of PGP will have
Twofish support without MDC, since we were not able to come to consensus
Ahhh great: I'm holding back Twofish support for GnuPG for many weeks
now, only to have the chance to use 128 bit block ciphers as a
criteria to decide whether to use MDCed encryption - but NAI has already
decided to make facts and thereby ignoring the discussion at the WG.
But sure, it is your companies decision - tssss.
BTW, how did you solve the ambiguities in the rfc regarding the use of
synced CFB and length of IVs?
By this, do you mean the special sync operation after reading the pseudo
IV and check bytes?
Yes.
#define CIPHER_MODE_PHILS_CFB 3
--
Werner Koch at guug.de www.gnupg.org keyid 621CC013