Tom Zerucha, <tzeruch(_at_)ceddec(_dot_)com>, writes:
In effect what we have now (with buffering or pipes between threads) is:
ciphertext | dearmor | pkdecrypt | symdecrypt | sigver | deliteral
There may be multiple sigvers, one per level of nesting (I use a stack
instead of spawning another layer).
What will happen is that this will insert something between the symdecrypt
and the sigver sections. It will function nearly the same as the sigver,
except we are creating a completely new and disjoint syntax for handling
the new packet.
For me, it is really ugly to add a new layer when the existing one can
easily be modified to work and provide the same function.
Instead we fiddle with the definitions to make it incompatible with the
existing layers just enough so it must be a new layer, but realize that
all this new verbage simply exists to forcibly create a new layer, and not
for any functional reason.
These statements are only valid in the context of your implementation.
I have implemented it in a different way which did not require adding any
new layers. I simply added calls to the hash function in the decryption
module, as well as the 20 byte holdback buffer. As it happened I
already had a buffer in the decryption module so modifying it to hold
back 20 bytes was easy. There were then two extra functions added to
the decryption module, one to finalize and retrieve the hash value,
and one to retrieve the value from the holdback buffer (which holds the
final 20 bytes at the end of processing). These are then compared at
the end of the packet. It was not a difficult change.
I don't believe we should judge the difficulty based on just how it
affects your implementation. If you would like some help I suspect we
could work with you to make similar modifications to your symdecrypt
module.
I asked what didn't work about extending "signature" packets to
"verification" packets (with the zero algorithm or something similar -
or even keeping the signature packet format with a different ID number
for MDC only packets).
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.
I did mention this, in my original message on this topic, when I wrote:
We have also discussed providing integrity protection via some
modification to the signature packet format rather than by a new form
of encrypted packet. There would be a special kind of "signature" which
would just consist of a hash of the message to protect its integrity.
However, Phil argues that this kind of integrity protection is inherently
tied to the use of encryption. It has no functional effect if not used
in conjunction with encryption. This is unlike our other signatures,
which are cryptographically useful transformations even on their own.
Because of this close tie to the encryption functionality it makes most
sense to make it part of the encrypted packet.
How many lines of code did each method take? How many cpu-seconds?
Which is the most architecturally attractive way to do it? Which method
is the most logical and coherent? Which method would you use if you
were designing from scratch, rather than trying to shoehorn it into an
existing implementation so as to change it as little as possible?
Altering one byte to add a definition to the signature packet is less of
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
spare.
Holding back 20 bytes does not take a big machine, or any OS or API calls.
It is a simple circular buffer and about half a page of code.
I don't. If you are going to do this then at least force an EOF and
append 20 bytes without any packet information (i.e. the new stream
packets would indicate an end where the message ends, but there would be
20 bytes (or whatever) extra following not encapsulated in any packet).
Let's not go down the path of putting bytes outside a packet. That would
violate all of our conventions.
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
easily. This is by no means universal.
One of my implementations is for the Palm Pilot. Adding a layer instead
of a few lines in an existing layer) is a really big deal there (exclusive
of adding algorithms). Holding back 20 bytes when I am already against
the memory limitations is going to be very painful.
Surely a 20 byte holdback buffer can't be a major problem, when adding the
new hash context is going to take at least 84 bytes of ram.
I have pointed out that we can do it without bloating the code. But it
seems everyone wants to bloat it. Assuming PRZ isn't doing another
"hit-and-run", what does HE think of the alternatives?
Phil is out of the country now, but I have spoken at great length to him
about this over the past month. I assure you that Phil is THE strongest
supporter of integrating the MDC feature with a new encryption packet.
I cannot over emphasize how strongly he opposes doing it as a hack of
the signature packet.
I showed earlier how inappropriate the signature packet is for this
purpose. I listed all the fields and showed how few of them made any
sense in this context. I can understand that this is the path of least
resistance for kludging this feature into existing code, but we would
prefer an approach which makes sense architecturally. Signature packets
are not appropriate for this purpose.
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
because of the larger impact on the existing code base.
Conversely, extending the existing structure is easy enough to warrant
being a SHOULD.
As far as I know, there are three implementations that are affected:
your reference implementation, the Gnu Privacy Guard, and the commercial
PGP from Network Associates. If we can come to agreement then we can get
these changes into all of these implementations, and make it a SHOULD as
Werner suggested.
Hal Finney
Network Associates, Inc.