StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POCTR mode in Linux Kernel
primarykey
Id
14462486
data
AcceptedAnswerId
0
AnswerCount
1
ClosedDate
CommentCount
14
CommunityOwnedDate
CreationDate
2013-01-22T15:48:43.917
FavoriteCount
1
LastActivityDate
2013-01-29T14:38:25.733
LastEditDate
2013-01-23T13:06:14.540
LastEditorUserId
20270
OwnerUserId
1794345
ParentId
0
PostTypeId
1
Score
1
ViewCount
1497
LastEditorDisplayName
text
Body
I am currently experiencing some Kernel development for filesystem purposes that requires AES ciphering and I encounter the following constraints : <ul> <li>I must be able to cipher a plaintext of any length</li> <li>Padding (if any) is unnoticeable</li> <li>The overhead that might result of padding bytes is unacceptable</li> </ul> On the paper, there is an easy way to solve this : use the CTR encryption mode ! With that brilliant idea (hum...), I am happily diving into the crypto API sources of the Linux Kernel to learn how to get started. At this point I notice that the ciphering function involves the use of miscellaneous functions : <ul> <li>The crypt_inplace function. Its purpose is to handle the case when the user wants to store the cipher text in the same memory area as the given plaintext. (same as crypt_segment but with the memory constraint)</li> <li>The crypt_segment function. It is the standard ciphering function. It ciphers a whole block of data (that is 16 bytes for AES).</li> <li>The crypt_final function. When the given plaintext's length L is not a multiple of the underlying block cipher blocksize, this function performs the ciphering on the remaining bytes.</li> </ul> Thus with our L bytes long plaintext and with AES, the first L/16 blocks are processed using crypt_segment or crypt_inplace depending on what is requested. The remaining L mod 16 bytes are then ciphered using crypt_final. The inner crypt_segment functions is defined as follows : (crypt_inplace is very similar) <pre><code>static int crypto_ctr_crypt_segment(struct blkcipher_walk *walk, struct crypto_cipher *tfm) { void (*fn)(struct crypto_tfm *, u8 *, const u8 *) = crypto_cipher_alg(tfm)->cia_encrypt; unsigned int bsize = crypto_cipher_blocksize(tfm); u8 *ctrblk = walk->iv; u8 *src = walk->src.virt.addr; u8 *dst = walk->dst.virt.addr; unsigned int nbytes = walk->nbytes; do { /* create keystream */ fn(crypto_cipher_tfm(tfm), dst, ctrblk); crypto_xor(dst, src, bsize); /* increment counter in counterblock */ crypto_inc(ctrblk, bsize); src += bsize; dst += bsize; } while ((nbytes -= bsize) >= bsize); return nbytes; } </code></pre> As you can see, the counter is incremented on a blocksize basis. On most use cases it will not be an issue but consider this scenario : <ol> <li>Write request at a given place p (this can be a (sector,offset) particular value on a hard drive for instance) : 11-byte long plaintext</li> <li>Read request for 8 bytes at p+3 : here, we want to get back the 8 last bytes of the initial plaintext from the written ciphertext.</li> </ol> The first step will be done with a single call to crypt_final in the ciphering sequence. Then, the 11 ciphered bytes are written at the right place. But when we want to retrieve the last 8 bytes of this chunk of data, due to the "block-wide" ciphering, we need the 3 previous bytes, stored in p, p+1 and p+2 to perform the deciphering operation. Obviously, in a filesystem point of view, when a read is requested, there is no way for the kernel to know this kind of things if it does not make some hardware-dependent assumptions. Hence, here is my question : is there a way to set up the CTR mode to always perform (de)ciphering operations on a byte basis or should I create my own implementation of CTR mode to enforce this ? (I did not find any entry point in ctr source code to do this configuration operation, I might have missed something) Thanks in advance, I hope I have not stunned you with the big post ! PS : The code snippet in this post can be found in the ctr.c file under the crypto directory of a Linux Kernel source tree. The displayed version comes from the 3.8-rc3 Kernel release. <hr> <h2>EDIT :</h2> In fact, the CTR mode is designed to handle any length of data. I will recall the description found in the ISO/IEC 10116 specification. Let assume our plaintext P is divided into chunks ( Pi )0 of equal length (j bits). Let K be the key supplied for the encryption and IV the initialization vector for the counter. The ciphertext C will be divided into chunks ( Ci )0 like the plaintext P. The CTR mode introduce a counter, which walks at each processed chunk. That said, we will call the counter block used for ciphering (resp. deciphering) the chunk Pi (resp. Ci) CTRi Finally, let CTR1 = IV With these notations, here is what the computation may look like : <blockquote> FOR i from 1 to n DO <ol> <li>Y = AES_encrypt(CTRi, K) <- Y is 16-bytes long</li> <li>E = Truncate(Y, j) <- Only keep the j leftmost bits of Y</li> <li>Ci = Pi XOR E</li> <li>CTRi+1 = ComputeNextCTR(CTRi) <- Usually ComputeNextCTR is a simple incrementation.</li> </ol> DONE </blockquote> In the CTR version found in the Linux Kernel, this behaviour is enforced with j taking the value of the underlying block cipher blocksize (128 bits with AES), except for the last step where a truncation occurs if the given plaintext has not a suitable length. My question was : is there a way to tell the crypto API to apply the j parameter I want ? To me, it seems like the answer is "No.", so I would have to "reinvent" the wheel and make a new implementation of the CTR mode to get this extra feature. Since I may have missed something, I would be grateful to the person who will clearly state this. Bonus one : If the answer is "No.", a quick overview of how the algapi of the Crypto API works would be very very welcome (I am currently digging into this). Thanks in advance again.
Tags
<c><linux><linux-kernel><cryptography>
Title
CTR mode in Linux Kernel
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. This table or related slice is empty.
PostTypePostTypeId
1. PTQuestion
UserLastEditorUserId
1. USHasturkun
UserOwnerUserId
1. USRerito
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. PO
 singulars
 PostTypePostTypeId
 PTAnswer
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 POCTR mode in Linux Kernel
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.