Re: [SAMBA4][PATCH] Fix up AES sign/seal on DCE/RPC

[Ken Raeburn <raeburn@MIT.EDU>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sep 10, 2005, at 00:29, Andrew Bartlett wrote:
> This patch adds a new function:
> OM_uint32
> gss_wrap_size (
>             OM_uint32 * /*minor_status*/,
>             const gss_ctx_id_t /*context_handle*/,
>             int /*conf_req_flag*/,
>             gss_qop_t /*qop_req*/,
>             OM_uint32 /*req_input_size*/,
>             OM_uint32 * /*output_size*/
>         );
>
> This tells the caller what the wrapped size would be, given an input
> size.  From there, I can tell what the 'signature' portion would be.

What is there in the GSSAPI specification that makes you think that  
the output size will always be uniquely determined by the input size,  
independent of the data?  Granted, it's probably usually true,  
perhaps true with all the mechanisms Samba is likely to run into, but  
I do think it's an assumption unsupported by the GSSAPI specification.

For example, does the GSSAPI allow for a "wrap" token encoding to  
first compress the data?  (Whether you'd *want* to is a different  
question, and beside the point, which is that the GSSAPI allows for  
mechanisms for which this function cannot be implemented as  
described.)  Upper or lower limits, perhaps; a precise size, I don't  
think so.

I think it's also a mistake to assume that there's always a trivially  
separable "signature portion".

Ken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD4DBQFDInWJUqOaDMQ+e5gRAuesAKCFrVCSAYb1AFGk8NyB2WvDasZpiwCVFZw7
by7PH/7RIKZ1PdBePNSlEA==
=NvHV
-----END PGP SIGNATURE-----