Tom Zerucha <tzeruch(_at_)ceddec(_dot_)com> writes:
Encrypted_Data -+- Data_Containter_Packet -+- Onepass
! !- Plaintext
! !- Signature
!- MDC_Packet
Not true. Just as you run the encryptor and get two or more packets out
Partly true, for my implementaion such a scheme would make for
sense ;-)
No one has yet told me why this is any less secure, slower, or harder than
tacking the 20 bytes onto the end of the plaintext.
How many lines of code did each method take? How many cpu-seconds?
You know that I implemented this in GnuPG (it is in 0.9.6, use
--force-mdc). But the way I implemented it was more a hack. Using a
different packet than the signature packet would have made more sense
as it will lead to a cleaner implementation.
I dropped this to check my proposol and Phil's and it turned out that
Phil's was the easiest to implement. Holding back the 20 bytes is
really easy if you are already doing some buffering and it can be
coded in a way to minimize any performance penalty (which is anyway in
the MDC calculation).
a hack than holding back 20 bytes. Don't assume everyone is running on
big machines with an OS or API calls to handle this and CPU cycles to
Not CPU cycles but larger buffers are needed.
It may be easy to add in your implementation, and you may not be trying to
do stream I/O and have something that handles errant packet boundaries
GnuPG handles everything has stream (with the strange partial header
scheme of PGP 5 which claims to save some bytes :-)
of adding algorithms). Holding back 20 bytes when I am already against
the memory limitations is going to be very painful.
As Hal already said, the extra memory needed for the hashing context
outweights some 20 bytes.
I have pointed out that we can do it without bloating the code. But it
Actually the signature packet hack bloated my code (although a
different type of packet won't do so).
If this is going to require another layer, then all such algorithms using
this new method should be given a MAY level of compliance and not SHOULD
I only wanted to get a faster consensus, therefore I suggested SHOUlD
- but it has now turned out that NAI is doing anyway there own way, we
can use MAY and an implementor can decide whether to print a warning
or now.
[Really fine that we have a holiday tomorrow :-), back on Monday]
--
Werner Koch at guug.de www.gnupg.org keyid 621CC013