#20 [**] KINK_ENCRYPT format (section 5.1.8)

i agree that KINK uses the output of the kcrypto function.
it will make a calculation cost slightly high.  but as my experience
of implementing KINK, i can say that it will be fine to use the library
directly.  and Ken's comment is important.  we can not say that
such crypto algorithm will not published.

> #20 [**] KINK_ENCRYPT format (section 5.1.8)
> 
> 	The format of the encrypted part of KINK_ENCRYPT (section 5.1.8) is
> 	vague.  I think of using the output of raw encryption algorithms
> 	(i.e. E(confounder | plaintext | pad)) or using EncryptedData.
> 
> 	treat "encryption with 
> 	integrity protection" output as a whole, don't peek under the covers to 
> 	find a "checksum" part you can throw away  (Ken Raeburn)
> 
> 	drop references to the initialization vector  (Ken Raeburn)
> 
> 	Please use the output of the kcrypto encrypt
> 	operation directly.  Of most importance is to make sure that all
> 	kcrypto enctypes will work even if it is not possible to decompose the
> 	kcrypto checksum from the encrypted data.  This probably means that in
> 	some cases you will have double checksums.
> 	You also need to deal with making sure you can determine the length of
> 	the plaintext.  (Sam Hartman)