Re: [PATCH 2/3] Store header and trailer byte counts in schan_context for future use

[Henri Verbeet]

On 30 August 2010 18:37, Mikko Rasa <tdb(a)tdb.fi> wrote:
> +            ctx->trailer_bytes = pgnutls_mac_get_key_size(pgnutls_mac_get(ctx->session));
> ...
> -            stream_sizes->cbHeader = 5;
> -            stream_sizes->cbTrailer = mac_size + 256; /* Max 255 bytes padding + 1 for padding size */
> +            stream_sizes->cbHeader = ctx->header_bytes;
> +            stream_sizes->cbTrailer = ctx->trailer_bytes;
> Does this imply TLS record padding should be disabled? I imagine an
> encrypted message may not fit in the application provided buffers
> otherwise.

[PATCH 2/3] Store header and trailer byte counts in schan_context for future use

[Mikko Rasa]

On 31.08.2010 16:16, Henri Verbeet wrote:
> On 30 August 2010 18:37, Mikko Rasa<tdb(a)tdb.fi>  wrote:
> > +            ctx->trailer_bytes = pgnutls_mac_get_key_size(pgnutls_mac_get(ctx->session));
> > ...
> > -            stream_sizes->cbHeader = 5;
> > -            stream_sizes->cbTrailer = mac_size + 256; /* Max 255 bytes padding + 1 for padding size */
> > +            stream_sizes->cbHeader = ctx->header_bytes;
> > +            stream_sizes->cbTrailer = ctx->trailer_bytes;
> > Does this imply TLS record padding should be disabled? I imagine an
> > encrypted message may not fit in the application provided buffers
> > otherwise.

That was originally so I could determine the end of the message and fill 
a SECBUFFER_EXTRA buffer if there's any leftover data (probably because 
the input buffer contained part of the next message).  However, since I 
had to do my own TLS frame decoding anyway in a later patch, I don't 
really need to know the MAC size anymore.

I'll produce a revised patchset shortly, taking into account Hans's 
feedback as well.

-- 
Mikko