On Mon, Nov 19, 2001 at 05:02:45PM -0000, Mayers, Philip J wrote: > All, > > I'm having some trouble interpreting the enctypes in both the RFC and the > MIT code. Specifically, I'm pulling a Ticket from an MIT credcache, and > using the key to decrypt it. In des-cbc-crc mode, I can expect the data to > look like this, right? > > <confounder - 8 bytes><crc - 4 bytes><data><pad to 8 bytes> > > ...except obviously not, since how do I know what's padding and what's data? > There's no length field? Could someone clarify this?
That's basically correct. There is no length field at this level. Either you expect a certain amount of data, or (more likely) the data itself gives the length, e.g. because it is ASN.1 DER. For example, a PA-ENC-TIMESTAMP with des-cbc-crc might be <confounder - 8 bytes> <crc - 4 bytes> 30 1A A0 11 18 0F "20011120101449Z" <padding - 7 bytes> or some such. > Also, the RFC mentions > that des_string_to_key uses the des-cbc MAC - which one (not desmac-k I > presume). Could someone clarify the various string_to_key algorithms? Someone else will have to cover that for you, although for des-cbc-crc one can have a look at MIT's or Heimdal's libdes, or at OpenSSL's libcrypto. Each have a `des_string_to_key' implementation that does the right thing. Cheers, -- Jacques A. Vidrine <[EMAIL PROTECTED]> http://www.nectar.com/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED]
