Hi Rachel,
On Thu, Jul 19, 2007 at 05:54:53PM +0100, Rachel Willmer wrote:
Hi guys
I have a couple of questions about the creation and parsing of
encrypted data packets (Section 13.9).
The I-D draft copy I've got in front of me is bis19, but I don't think
the current version has any more info...
The answers might, of course, be blindingly obvious - in which case,
flame me privately please :-)
No, they are not. Back in the day when I was implementing ePointPGP, I have
experimented quite a bit until I got it right. The wording of the standard,
while technically correct, indeed has ample room for improvement.
1] Parsing a Symmetrically Encrypted Data Packet (Tag 9)
Section 13.9 gives a good explanation of how to create the SE packet,
but there's no information on how you parse it. Do you need to do the
same sequence of XOR-ing and resyncing as in the creation? It would be
useful to have some explanation of this...
Yes, but instead of repeating two bytes, you may want to check that they are
identical in order to find out with large probability that the symmetrical
key used for decryption is wrong. Note, however that this check possibly
consitiutes a security vulnerability for server-side applications.
Here is a compact, high-level code (in java) from ePointPGP with the
necessary explaination:
http://epoint.cvs.sourceforge.net/epoint/epoint/java/net/sourceforge/epoint/pgp/ENCRYPTEDPacket.java?revision=1.10&view=markup
2] What happens if the plaintext doesn't fit neatly into the
blocksize? Is this algorithm-dependent? or do you just pad with
zeroes?
No need to pad. CFB encrypts each block by XOR-ing the output of the block
cipher (whose input depends on past plaintext and IV) with plaintext.
Therefore, you can decrypt partial blocks without problems.
3] A suggestion for a future draft if there is one: it would be useful
to have in one section the list of all mandatory algorithms and packet
types for a minimum implementation, rather than having to trawl
through the doc to pick this info out.
I agree.
P.S. Yes, I realise I could probably guess the answers to [1] and [2]
from looking at the GPG code, but I'd rather do the implementation
purely from the spec, rather than by reference to an existing
implementation, if possible...
Nevertheless, I would suggest looking at implementations and do extensive
interoperability tests because OpenPGP's flavor of CFB is quite unusual.
--
Daniel
signature.asc
Description: Digital signature