On Wed, 1 Apr 1998, Hal Finney wrote:
The purpose of the 1-pass signature packets is not primarily to provide
multiple signature capability. The main purpose is to allow the signer
to process the entire message in one pass.
The rest of the message is technical commentary, sort of Oh, yea - it
would have to be done this way.
The SIGNER needs the one pass format to do signatures in one pass.
With old-style signatures, the signature has to go at the front of
the message. But the signer can't create the signature until he has
processed the whole message. So he then has to go back and stick the
signature back at the front of the message, which requires some buffering
and re-scanning of the data.
It requires two read passes. The first doesn't write, but only formats
and hashes. Then the sig would be written out. Then a second read would
write out the real (e.g. literal encasulated) data.
But you are right, you could not handle a stream this way. Unless you had
a filesystem that allowed for insertion at the head as well as the tail.
With the 1-pass signature, the signer puts the 1-pass packet at the
front to tell the verifier what hash to use, then comes the message,
and then comes the signature. This is a much more natural flow for all
parties.
Except that the validity data comes later (which would be known), so you
do all the work and find the signature is expired or something else is
wrong.
You could also have split the signature packet, with everything up to the
2 hash verification bytes and the MPI integers appearing afterword. This
would leave one format and thus one mode and parser.
PGP 2.X creates many temp files to deal with the buffering needed by the
signature structure, and the need to know all packet lengths in advance.
The one-pass signature packets and partial packet length specifiers are
designed to allow processing messages without any temporary files, which
enhances security and performance.
Security, maybe. If you implement a loop that can pass data between each
layer:
in->dearmor->decrypt->decompress->deliteral->out
something like:
ret=fread(BUFSIZ); ret=dearmor_update(ret); ret=decrypt_update(ret) ...
with the potential for missing layers, etc. This is not something that
would help performance (since you have to call the update lots of times
instead of one call to a sub with an internal loop). You could use huge
buffers, and comression would still require realloc, but that is a memory
usage for CPU tradeoff.
If you use threads with pipes or other OS structures, then those become an
attack point as much as temp files. Even if you use huge buffers, the OS
will probably respond by swapping out your passphrase, so you have a
virtual temp file.
For *verification*, you merely need to retain the original signature
packet until the end, so it is a few K.
For pure signing, the file must already exist as plaintext to be read in
(so there is no added security in not reading it a second time, but there
is added performance), and then the signature packet can be written out
(like a detached signature, and then optionally append the plaintext).
--- reply to tzeruch - at - ceddec - dot - com ---