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

Ken Raeburn raeburn at MIT.EDU
Sat Sep 10 05:56:20 GMT 2005

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".

Version: GnuPG v1.4.1 (Darwin)


More information about the samba-technical mailing list