[2729] in Kerberos
krb_mk_priv: How big is the encrypted data?
daemon@ATHENA.MIT.EDU (Jonathan I. Kamens)
Tue Jun 15 14:12:13 1993
Date: Tue, 15 Jun 93 13:55:02 -0400
From: Jonathan I. Kamens <jik@GZA.COM>
To: kerberos@Athena.MIT.EDU
Cc: jik@GZA.COM
I understand that the gateway between comp.protocols.kerberos and the Kerberos
mailing list isn't working right now, so I'm sending this separately to both.
Please send any mailed responses to me as well as to the list, because I'm not
subscribed to it.
Thank you.
------ Forwarded Article <1vl29l$ijp@pad-thai.aktis.com>
------ From jik@GZA.COM (Jonathan I. Kamens)
From: jik@GZA.COM (Jonathan I. Kamens)
Newsgroups: comp.protocols.kerberos
Subject: krb_mk_priv: How big is the encrypted data?
Date: 15 Jun 1993 17:52:53 GMT
Organization: Geer Zolot Associates
Distribution: world
Message-ID: <1vl29l$ijp@pad-thai.aktis.com>
NNTP-Posting-Host: pad-thai.aktis.com
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
------ End of Forwarded Article
