hal(_at_)rain(_dot_)org writes:
I think the only thing I have changed is that I am using version 1.
Okay.
As I described earlier, I propose not to have any mechanism for turning
the MDC on and off, or for selecting a hash algorithm, because these would
leave openings for an attacker to possibly modify this selector. He might
be able to turn off the MDC, which would completely defeat the purpose.
Together with the version number I can live with this.
However because we are handling the CFB SYNC differently it will produce
completely garbled data, which I view as an acceptable failure mode.
What do you think?
I think this is reasonable.
5.X. Symmetrically Encrypted Integrity Protected Data Packet (Tag 15)
Symmetrically Encrypted Data Packet. In either case, the cipher
algorithm octet is prefixed to the session key before it is
Don't know wthether I understand it: Does it mean, that the first 8
bits of the session key are known? So we actually have only 248 bit
Twofish? Why not putting the algorithm octet just after the 2
checksum bytes in the prefix?
Unlike the Symmetrically Encrypted Data Packet, no special CFB
resynchronization is done after encrypting this prefix data.
And we should cleanup the ambiguity about this in rfc2440.
it includes all of the plaintext, and then also includes two octets
of values 0xD0, 0x14. These represent the encoding of a Modification
So you can use your old implemenation idea of a fixed block at the end
of the encrypted data. That is okay.
Note: future designs of new versions of this packet should consider
rollback attacks since it will be possible for an attacker to change
the version back to 1.
So we also solved this issue :-)
We should also mention that an implemenation SHOULD use this new
packet for ciphers others than 1,2,3,4,5 (which are the ones from the
current rfc). And that it MAY use the new packet if the preferences
of a receiver's key indicate that an algorithm other than 1..5 can
be used (this is because we can assume, that the new packet type is
supported by the implemenation used at the receivers side).
Another suggestion for the next version:
Extend the marker paket with a version number of the RFC: "PGP/1.1"
instead of a bare "PGP". This may be useful in the future.
You did good work with this and I can agree with it.
What do the others think?
--
Werner Koch at guug.de www.gnupg.org keyid 621CC013