On Fri, Jun 16, 2000 at 05:38:28PM -0700, Jon Callas wrote:
Or maybe we should just do the sync anyway.
It's one thing to not be standard, but it's another to not be consistent.
The only thing that one can complain about PGP-CFB for is that it's not
standard CFB. I don't see that as an issue.
Other systems, like CMS, use CBC mode not CFB at all, so we're no less
different even if we switch.
I would prefer to keep one encryption mode and use it everywhere. The one
to use, is of course PGP-CFB. However, if we're going to change it, we
should discuss using CBC mode.
I agree with this since I separate the operators from the core, though
cfb mode is one of the standard calls in openssl. For all else I have
a cfbomatic routine.
However wasn't there something about NOT resetting if the block length
for the cipher was over 9 bytes in length?
Let me bring up another consideration (while looking for the above).
3.6.2.1...
These are followed by an 8-octet Initial Vector for the decryption of
the secret values, if they are encrypted, and then the secret key
values themselves.
5.5.3...
- [Optional] If secret data is encrypted, eight-octet Initial
Vector (IV).
and
With V3 keys, the MPI bit count prefix
(i.e., the first two octets) is not encrypted. Only the MPI non-
prefix data is encrypted. Furthermore, the CFB state is
resynchronized at the beginning of each new MPI value, so that the
CFB block bou
The symmetric ciphers are used more than one place - one is for
unlocking secret keys, and we have resyncs here.
So what happens for secret keys using a cipher with a 128 bit block
size? Do we use 16 octet IVs? Do we resync on mpi boundaries for a
V3 key (is this possible - I don't see anywhere in the spec where it
says you MUST use IDEA to encrypt V3 secret key material)?
(Actually I have a problem in my current opgp implementation since I
don't support block sizes other than 8 bytes (no, I refuse to always
use "octet"), but as soon as I can get the new algorithms going I know
where and how to fix it).