On Mon, Sep 16, 2013 at 08:34:11PM +0200, Dominik Paulus wrote: > Hi, > > On Mon, Sep 16, 2013 at 12:58:40PM +0200, dominik.d.paulus@xxxxxxxxxxxxxxxxxxxxxxx wrote: > > We are currently trying to add encryption support to the usbip kernel > > driver. Unfortunately, there is almost no documentation for the kernel > > crypto API. So far, we couldn't figure out how to use the GCM encryption > > mode in the kernel. There seems to be infrastructure for IV generation > > in place (e.g. seqiv.c, the geniv stuff and the RFC 4106 implementation), > > but no code directly using it. > > > > What's the recommended way to use the IV generators with a "high-level" > > API? > > Sorry, that mail probably got a bit too short. To explain our problem a bit > more: We are currently using a 64-bit counter to generate IVs. As the > keys are randomly generated for each session and thus never reused, > that's probably a not too bad idea (if it is, please tell us why ;)), > assuming this counter is never going to overflow. We pass the IVs > directly to aead_request_set_crypt for each message. This currently > works quite fine. It's usual the use of random IVs but I don't think that any known pattern (as a counter) in the IV generation should cause any reduction in the algorithm strength (and if it does, it's probably a weakness in the algorithm itself). The only thing that should be avoided for sure is the reuse of the same IV. > > However, we would expect that IV generation is at least partially handled > by the crypto API. As I said, there seems to be infrastructure for that, > that abstracts the sequence number quite nicely. The seqiv generator > seems to provide a high-level interface to the AEAD crypto, including an > abstraction for the sequence number generation. However, due to the lack > of documentation and/or reference code using the API, we couldn't find > out how to use it yet. I haven't used the IV generation facility of the Crypto API, but it seems to be very straightforward although there's no documentation about that. You should use aead_givcrypt_set_callback(), aead_givcrypt_set_assoc() and aead_givcrypt_set_crypt() as you would use the regular aead functions, that includes that you have to provide a buffer with length equals to the algorithm block size for the IV. And then you should call aead_givcrypt_set_giv() passing a counter and another IV buffer. The difference between the two IV buffers that you have to provide to aead_givcrypt_set_crypt() and aead_givcrypt_set_giv() is that the first one will be updated by the algorithm during the encryption of each block and the second one will contain the generated IV that you will have to use to decrypt data. The last step is to call crypto_aead_givencrypt() as you would call crypto_aead_encrypt(). Under the cover the Crypto API will generate a random salt in the first use of each request. This salt will be xor'd with the given counter to create the new IV. That has an advantage over a simple count, that usually will start with the same value every time the system is rebooted. > > Any help on this would be appreciated. If we feel competent enough to do > so after finishing this project, we would also volunteer to extend the > introduction in Documentation/crypto/api-intro.txt a bit. > That is probably a very good idea! I also want to improve the documentation as soon I have some time to do it :) > Regards, > Tobias Polzer and Dominik Paulus > -- > To unsubscribe from this list: send the line "unsubscribe linux-crypto" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
