Re: applying AES-GCM to secure shell: proposed "tweak"

[nisse%lysator.liu.se@localhost (Niels Möller)]

Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost> writes:

> I have, and if you want to do it properly it makes the header read incredibly
> complicated.

What I do is basically that I check that the length doesn't exceed the
maximum message size, and that the padding length abides the rules in
the spec (these checks examine the first 5 bytes of the decrypted
first block). I'd do the same checks if length and/or padding were
unencrypted. Besides this, nothing interesting is done to the packet
data until the complete packet is read.

If this is not the "proper" way of doing it, I'd appreciate a hint of
what other checks are needed and why. I may well be missing something.

> I've just had a look and it's about 700 lines of code to safely
> process the packet header with appropriate checking and whatnot, with a lot of
> awkward length-checking and data handling.

I simply don't get this. I'm now looking at the corresponding
functions in (the development version of) lsh. There's one function
that handles the reading of transport packets, including processing of
the message header in the first block, and it is 165 lines (including
some i/o and some debugging code), and a second function that applies
the current crypto, mac and decompression algorithms to a complete
packet, which is 64 lines more. Code in question is the functions
decode_packet and transport_read_packet in
http://cvs.lysator.liu.se/viewcvs/viewcvs.cgi/*checkout*/lsh/src/transport_read.c?content-type=text%2Fplain&root=lsh

Sure, there's some extra book-keeping for handling the first block,
but I don't understand how that could amount to many hundreds of lines
of code.

Regards,
/Niels