[2730] in Kerberos
Re: krb_mk_priv: How big is the encrypted data?
daemon@ATHENA.MIT.EDU (Steve Lunt)
Tue Jun 15 15:27:34 1993
Date: Tue, 15 Jun 93 14:55:45 EDT
From: Steve Lunt <lunt@ctt.bellcore.com>
To: jik@gza.com, kerberos@Athena.MIT.EDU
Length of input plus 25 bytes. I make it 32 just to be safe.
-- Steve
> Date: Tue, 15 Jun 93 13:55:02 -0400
> From: Jonathan I. Kamens <jik@gza.com>
> Subject: krb_mk_priv: How big is the encrypted data?
>
> The Kerberos V4 krb_mk_priv function expects the application developer to
> give it a pointer to memory in which it can store the encrypted version of the
> data that the application wants to protect.
>
> However, the manual page for krb_mk_priv does not document how big this block
> of memory has to be. It makes sense that it is closely related to the amount
> of data being encrypted, because (as I understand things) the DES algorithm
> produces the same number of bytes as its output as it is given as input
> (rounded up to the nearest eight bytes, or something like that). However,
> krb_mk_priv appears to use more memory than just what is required by the DES
> routines.
>
> I'm using krb_mk_priv in my application, and I'd rather not solve this problem
> by allocating some huge buffer that I don't expect to ever overflow.
>
> So, in short, my four question are: (1) How can I determine how much memory I
> need to allocate for krb_mk_priv? (2) Is this documented anywhere? (3) If
> so, where? (4) If not, why not :-)?
>
> Another interesting thing about krb_mk_priv is that the address of the
> encrypted data that it returns is not the beginning of the allocated buffer,
> so if you allocate memory for krb_mk_priv to use, you have to keep the address
> of that memory around so that you can free that address rather than trying to
> free the pointer that krb_mk_priv gives you. This one took me a long time to
> figure out, and I didn't figure it out until I linked my application against a
> debugging malloc library. :-)
>
> Thanks.
>
> --
> Jonathan Kamens Geer Zolot Associates jik@GZA.COM