Re: A patch to loop.c for better cryption support
On Mon, Oct 16, 2000 at 06:23:32PM +, David Wagner wrote: (snip) > > Using SHA1(sector #) should be ok, as long as you don't expect your > plaintexts to have similar patterns. (If you do think your plaintexts > might begin with the SHA1-hashes of sector numbers, you could use a > "keyed hash", or more precisely, a pseudorandom function. For instance, > you could encrypt the sector number using a secret IV-generation key.) I think our discussion may be drifting a bit. Perhaps revisiting some crypto system fundamentals might be helpful. The loop device driver provides a transfer module API, nothing more. Placing encryption code (which includes hashes) into the loop device driver is not appropriate. The crypto functionality should be wholly contained in the transfer modules. IMHO, all that we should ask of the loop.c transfer API is: a) Type of transformation needed (encipher or decipher). b) Data bits to be transformed and length. c) Key bits and length. d) A *UNIQUE* IV seed associated *ONLY* (!!) with the data in step b) above. A design goal of all modern crypto systems is that the security of the system rest soley in the key. IV's must be unique, not secret. Unique IVseed means "never duplicated". An increasing block | sector # is one means to meet the unique requirement. Transfer modules are free to further mangle the IVseed via whatever method they feel is appropriate. Reed H. Petty [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
Ingo Rohloff wrote: >-snip--- > As an example, it is not true that CBC encryption > can use an arbitrary nonce initialization vector: it is essential > that the IV be unpredictable by the adversary. (To see this, suppose > the IV is a sequence number: 0, 1, 2, ... . Then a (first) encryp- > tion of 0x followed by an encryption of > 0x0001 is recognizably distinct from a (first) encryption > of 0x followed by an encryption of > 0x. Clearly this violates violates the notion of a > secure encryption sketched in Section 2.) >-snip--- > >So I think what is written in "Applied Cryptography" (by Bruce Schneier) >is correct. A sequence is ok, as long as you can't predict the start >of the sequence. No, a sequence is not ok, even if the beginning is unpredictable. Why? The encryption of 0 with IV v followed by encryption of 1 with IV v+1 is distinguishable from the reverse. (Because, with high probability, v and v+1 differ only in their low bit.) The problem is that the patterns in the IV sequence can interact with patterns in the plaintext. And, if the plaintext is patterned (e.g., ASCII-encoded English), there is a reasonable chance that you can get two plaintexts which start with blocks that differ only in their low bit; and this is the case that leads to the bad interaction, when you use a counter as your IV sequence. Using SHA1(sector #) should be ok, as long as you don't expect your plaintexts to have similar patterns. (If you do think your plaintexts might begin with the SHA1-hashes of sector numbers, you could use a "keyed hash", or more precisely, a pseudorandom function. For instance, you could encrypt the sector number using a secret IV-generation key.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
Ingo Rohloff wrote: >> There is a paper about why it is a bad idea to use >> sequence numbers for CBC IV's. I just have to find the reference to it. > >Does this mean sequence as in 0,1,2,3,4 ... or does this mean >any pre-calculate-able sequence ? In the former case we might just use >a simple one way hash-function over the requested sector number. It just means that 0,1,2,3,... is bad. Using SHA1(sector #) should be ok. But do think carefully about what happens when you modify a sector!! In particular, will you be re-using the old IV when you write the new data? That could be problematic. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
> > > > IV generation is what I am worried about. > > > There is a paper about why it is a bad idea to use > > > sequence numbers for CBC IV's. I just have to find the reference to it. > > Does this mean sequence as in 0,1,2,3,4 ... or does this mean > > any pre-calculate-able sequence ? In the former case we might just use > > a simple one way hash-function over the requested sector number. > > > > I guess it means 0,1,2,3,4..., but you might want to check > http://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt Ok, I read it and here is the paragraph, which refers to IVs: -snip--- RECOMMENDATION 10: Each transform should fully specify one partic- ular function (though this function may be probabilistic or state- ful). For example, if one has a mechanism like DES-CBC, one must specify how the initialization vector is to be selected. The reason for this recommendation is experience that indicates that if a transform is not completely specified, implementors will not know how to finish the "missing pieces" in a way that is cryptograph- ically correct. As an example, it is not true that CBC encryption can use an arbitrary nonce initialization vector: it is essential that the IV be unpredictable by the adversary. (To see this, suppose the IV is a sequence number: 0, 1, 2, ... . Then a (first) encryp- tion of 0x followed by an encryption of 0x0001 is recognizably distinct from a (first) encryption of 0x followed by an encryption of 0x. Clearly this violates violates the notion of a secure encryption sketched in Section 2.) -snip--- So I think what is written in "Applied Cryptography" (by Bruce Schneier) is correct. A sequence is ok, as long as you can't predict the start of the sequence. The key sentence in the above statement is: "It is essential that the IV be unpredictable by the adversary" If I understand this correctly it means that you CAN use a simple increasing sequence, as long as you make sure that the start value of the sequence is unknown. A simple implementation (which doesn't affect loop.c, but only the ciphers) is to calculate an IVseed from the key and use an addition of "IVseed" + "block/sector number" as IV for the encryption of one block/sector. (This is simplified a version of the approach suggested by David Wagner. He suggested to encrypt the block/sector number and then use the the encrypted sector number as IV. This seems even more secure, but if the above paragraph is correct than simply using a sequence, which starts at an unpredictable point should be enough... Comments ?) so long Ingo PS: I plan to put a revised implementation and patch set of Twofish on my homepage "http://www.in.tum.de/~rohloff". Please have a look at the description of the above scheme in my twofish implementation. I would like to hear some comments about it... I will do a second version, which implements David Wagners approach, because after some though I think the performance degradation is less than I expected at a first glance... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
David Wagner wrote: > > Marc Mutz wrote: > >> There are some who believe that "not unique" IVs (across multiple > >> filesystems) facilitates some methods of cryptanalysis. > > > >Do you have a paper reference? > > (However, it does get one > thing wrong: it claims that it's ok to use a serial number for your > IV. This is not correct, and I can give a reference for this latter, > subtler point, if you like.) > Yes, please. Is it the paper by P. Rogaway, cited in the paper on Counter mode, submitted to NIST's "Modes of Operation" workshop? > >As CTR mode _requires_ unique IVs (CBC does not), > > Sorry, that turns out not to be the case. Both CBC and CTR mode > require unique IV's (for security). > My copy of A.C. says: "While the IV should be unique for each message encrypted with the same key, it is not an absolute requirement." On the other hand, Counter mode trivially _requires_ different IVs because if two IVs are the same under the same key, the bitstream that CTR mode generates will be identical. Not good. > >the upper half of the > >IV could be initialized from the key > > It's a bad idea to include key material in your IV. (Kerberos did > it, and there were some attacks as a result.) I recommend against it. The IV would not contain any key material. If you have a cipher with a 128 bit key and you need 64 bits of IV, you simply request 192 bits of "key", use the lower third for the IV and the upper third as the key. -- Marc Mutz <[EMAIL PROTECTED]> http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
Ingo Rohloff wrote: > > > I can convert the stuff _in place_ (it actually works, anyone please > > complain loudly if it shouldn't) even when my 'cryptfile' is /dev/hdax > > and I don't have sizeof(/dev/hdax) space left on my hard drives. > This could be dangerous. I'm not sure that the kernel handles > this kind of concurrent access to the same encrypted blocks > correctly. (I admit, that I think it should work but it still might > be dangerous...) > I also think it should work, because dd has to read the block before writing it. By the time dd has the block and starts writing, the kernel should have no business any more with that read request. The bs=4k is needed in the case where the underlying filesystem has that blocksize. The current method then results in a 4k encryption chunk size. Reading the dd default of 512 bytes and writing them back before the rest of the 4k chunk has been read, would result in garbage read and subsequently written. I have actually tested this with a 100+ Mbyte filesystem. It is currently the only way to change the passphrase and/or the cipher used. > > IV generation is what I am worried about. > > There is a paper about why it is a bad idea to use > > sequence numbers for CBC IV's. I just have to find the reference to it. > Does this mean sequence as in 0,1,2,3,4 ... or does this mean > any pre-calculate-able sequence ? In the former case we might just use > a simple one way hash-function over the requested sector number. > I guess it means 0,1,2,3,4..., but you might want to check http://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt I have not gotten around to reading it, but it is cited in one of the papers that are already on NIST's "Modes of Operation" Workshop page. (see http://www.nist.gov/aes). > In the latter case, we might be able to use a message digest algorithm > which includes the sector number and part of the key. > (Both approaches slow the encryption further down, but for > security concerned people this doesn't matter...) If we use hashes, then we can make the following (taken from Appl. Crypto.): Let P[0]..P[N] be the N plaintext blocks, each the size of the cipher block size, of a 512 byte encryption chunk. Let H be a message digest (e.g. SHA-1), with the digest trunctated to the cipher's block size. Let E the cipher, K the key, C[0]..C[N] the ciphertext. Calculate h=H(P[2..N]). Encrypt P[0]..P[N] in CBC mode, using h as IV. To decrypt, first decrypt C[2..N] with C[1] as IV, then calculate h=H(P[2..N]) and decrypt C[0,1] with h as IV. Marc -- Marc Mutz <[EMAIL PROTECTED]> http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
Ingo Rohloff wrote: snip I can convert the stuff _in place_ (it actually works, anyone please complain loudly if it shouldn't) even when my 'cryptfile' is /dev/hdax and I don't have sizeof(/dev/hdax) space left on my hard drives. This could be dangerous. I'm not sure that the kernel handles this kind of concurrent access to the same encrypted blocks correctly. (I admit, that I think it should work but it still might be dangerous...) I also think it should work, because dd has to read the block before writing it. By the time dd has the block and starts writing, the kernel should have no business any more with that read request. The bs=4k is needed in the case where the underlying filesystem has that blocksize. The current method then results in a 4k encryption chunk size. Reading the dd default of 512 bytes and writing them back before the rest of the 4k chunk has been read, would result in garbage read and subsequently written. I have actually tested this with a 100+ Mbyte filesystem. It is currently the only way to change the passphrase and/or the cipher used. snip IV generation is what I am worried about. There is a paper about why it is a bad idea to use sequence numbers for CBC IV's. I just have to find the reference to it. Does this mean sequence as in 0,1,2,3,4 ... or does this mean any pre-calculate-able sequence ? In the former case we might just use a simple one way hash-function over the requested sector number. I guess it means 0,1,2,3,4..., but you might want to check http://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt I have not gotten around to reading it, but it is cited in one of the papers that are already on NIST's "Modes of Operation" Workshop page. (see http://www.nist.gov/aes). In the latter case, we might be able to use a message digest algorithm which includes the sector number and part of the key. (Both approaches slow the encryption further down, but for security concerned people this doesn't matter...) snip If we use hashes, then we can make the following (taken from Appl. Crypto.): Let P[0]..P[N] be the N plaintext blocks, each the size of the cipher block size, of a 512 byte encryption chunk. Let H be a message digest (e.g. SHA-1), with the digest trunctated to the cipher's block size. Let E the cipher, K the key, C[0]..C[N] the ciphertext. Calculate h=H(P[2..N]). Encrypt P[0]..P[N] in CBC mode, using h as IV. To decrypt, first decrypt C[2..N] with C[1] as IV, then calculate h=H(P[2..N]) and decrypt C[0,1] with h as IV. Marc -- Marc Mutz [EMAIL PROTECTED] http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
Ingo Rohloff wrote: There is a paper about why it is a bad idea to use sequence numbers for CBC IV's. I just have to find the reference to it. Does this mean sequence as in 0,1,2,3,4 ... or does this mean any pre-calculate-able sequence ? In the former case we might just use a simple one way hash-function over the requested sector number. It just means that 0,1,2,3,... is bad. Using SHA1(sector #) should be ok. But do think carefully about what happens when you modify a sector!! In particular, will you be re-using the old IV when you write the new data? That could be problematic. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
Ingo Rohloff wrote: -snip--- As an example, it is not true that CBC encryption can use an arbitrary nonce initialization vector: it is essential that the IV be unpredictable by the adversary. (To see this, suppose the IV is a sequence number: 0, 1, 2, ... . Then a (first) encryp- tion of 0x followed by an encryption of 0x0001 is recognizably distinct from a (first) encryption of 0x followed by an encryption of 0x. Clearly this violates violates the notion of a secure encryption sketched in Section 2.) -snip--- So I think what is written in "Applied Cryptography" (by Bruce Schneier) is correct. A sequence is ok, as long as you can't predict the start of the sequence. No, a sequence is not ok, even if the beginning is unpredictable. Why? The encryption of 0 with IV v followed by encryption of 1 with IV v+1 is distinguishable from the reverse. (Because, with high probability, v and v+1 differ only in their low bit.) The problem is that the patterns in the IV sequence can interact with patterns in the plaintext. And, if the plaintext is patterned (e.g., ASCII-encoded English), there is a reasonable chance that you can get two plaintexts which start with blocks that differ only in their low bit; and this is the case that leads to the bad interaction, when you use a counter as your IV sequence. Using SHA1(sector #) should be ok, as long as you don't expect your plaintexts to have similar patterns. (If you do think your plaintexts might begin with the SHA1-hashes of sector numbers, you could use a "keyed hash", or more precisely, a pseudorandom function. For instance, you could encrypt the sector number using a secret IV-generation key.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
On Mon, Oct 16, 2000 at 06:23:32PM +, David Wagner wrote: (snip) Using SHA1(sector #) should be ok, as long as you don't expect your plaintexts to have similar patterns. (If you do think your plaintexts might begin with the SHA1-hashes of sector numbers, you could use a "keyed hash", or more precisely, a pseudorandom function. For instance, you could encrypt the sector number using a secret IV-generation key.) I think our discussion may be drifting a bit. Perhaps revisiting some crypto system fundamentals might be helpful. The loop device driver provides a transfer module API, nothing more. Placing encryption code (which includes hashes) into the loop device driver is not appropriate. The crypto functionality should be wholly contained in the transfer modules. IMHO, all that we should ask of the loop.c transfer API is: a) Type of transformation needed (encipher or decipher). b) Data bits to be transformed and length. c) Key bits and length. d) A *UNIQUE* IV seed associated *ONLY* (!!) with the data in step b) above. A design goal of all modern crypto systems is that the security of the system rest soley in the key. IV's must be unique, not secret. Unique IVseed means "never duplicated". An increasing block | sector # is one means to meet the unique requirement. Transfer modules are free to further mangle the IVseed via whatever method they feel is appropriate. Reed H. Petty [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
Marc Mutz wrote: >> There are some who believe that "not unique" IVs (across multiple >> filesystems) facilitates some methods of cryptanalysis. > >Do you have a paper reference? There's no paper, because it's too trivial to appear in a paper. But you can find this weakness described in any good crypto textbook. See, e.g., Bruce Schneier's _Applied Cryptography_; the section on CBC mode says that IV's must not repeat. (However, it does get one thing wrong: it claims that it's ok to use a serial number for your IV. This is not correct, and I can give a reference for this latter, subtler point, if you like.) >As CTR mode _requires_ unique IVs (CBC does not), Sorry, that turns out not to be the case. Both CBC and CTR mode require unique IV's (for security). >the upper half of the >IV could be initialized from the key It's a bad idea to include key material in your IV. (Kerberos did it, and there were some attacks as a result.) I recommend against it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
kernel wrote: >There are some who believe that "not unique" IVs (across multiple >filesystems) facilitates some methods of cryptanalysis. It's a not a matter of "belief"; it's a matter of fact. The weakness is that the first block of ciphertext depends only on the IV and the first block of plaintext. Thus, if the IV is the same for two sectors, then you can tell from the two ciphertexts whether the two plaintexts start with the same 8-byte (or 16-byte) prefix. Since what we're encrypting is often patterned, and thus repeats in the beginning of the plaintext may be semi-common, this is not so good. The right thing is to use non-repeating, unpredictable IV's. One way to do this is to use E_k(sector number) as your IV, as I mentioned earlier; or, if you want relocatibility, you could use E_k(sector number + seed). Ask on sci.crypt if you need more specific advice. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
IV's should never be repeated (per key). If you are using CBC mode, they should not be just a counter, either (for different reasons). A simple implementation technique is simply to use the encryption of a block number / sector number / counter as your IV. This ensures that IV's don't repeat and that they all look cryptographically random. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
Reed Petty wrote: > Caution is advised when depending upon crypto systems that use relative > block numbers as IV. The security may not be a strong as hoped. > There are some who believe that "not unique" IVs (across multiple > filesystems) facilitates some methods of cryptanalysis. ... Ahh that explains it... > Perhaps losetup can allow the user to specify a "IVseed" value > and then pass to the transfer modules IVseed + relative block. > This would also allow existing absolute block based encrypted file > systems to be relocated (IVseed = absolute # of 1st block), satisfy > those among us who demand unique IVs, and allow those who prefer > operational convenience at the cost of weaker security to do so. An IVseed is a good idea. What would you think of using a secure hash function on the key as IVseed ? This should ensure almost unique IVs and you don't need a second parameter two encrypt/decrypt a file. (On the other hand this scheme is of course weaker than your approach...) so long Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
> So, the only provision that needs to be made to ensure backwards > compatibility (both with the kerneli patch and other modules that still > use absolute block numbers) is a way to switch between the new approach > and the old, defaulting to the new. The easiest way to do this, IMO, is > to allocate a new field 'encryption_chunk_size' or so from the set of > reserved words in struct loop_info. One might even get away with a > single bit, indicating whether to use 512 byte blocks or underlying > blocks as encryption chunks. Maybe lo_flags could be used when it > becomes allowed to set the single bit LO_FLAGS_USE_512_BYTE_CHUNKS or > so. Then teach losetup to set this bit unless instructed not to. Yes that's the start. I have to study loop.c more intensivly, because I think I found at least two more trap doors. (It's amazing that it works at all :-) ) Look at the line if (size > len) size = len This seems to be horrible wrong... A CBC chain always has to decrypt/encrypt a whole block otherwise the data my be irrecoverable. (With the sector approach it works, because len is sectors << 9 ...) And also block = current_request->sector / (blksize >> 9); offset = (current_request->sector % (blksize >> 9)) << 9; The whole operation will go wrong if offset != 0 . so long Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
> BTW, kerneli would also not handle the case of switching block sizes anyways, > with relative IVs or not, because it does not restart its CFB chain inside > the device blocks every 512 byte blocks with a new IV. My (inofficial) patch set for twofish and blowfish does though :-). I'm not sure if the CBC modes at the moment reset the Chain at all. (I have to have a closer look at the kerneli-patches... But this has to wait until tuesday, because that's the day of my last exam in university.) > When you switch > from a bigger block size to a smaller you would need backwards peeking to > earlier blocks (and know the block size anyways). hmm hmm. I think its' possible without that: Example: Blocksize 1024, so for example the chunk from offset 5120 - 6143. would be encrypted with IV 5. Know we switch to 512 Bytes. to encrypt/decrypt from offset 5120 - 6143 you use the IVs 10 and 11. So I don't see the problem. > Similar problem for going to bigger blocks. > Ingo's change makes it a bit less painless, but > still not trivial to handle. The only problem I see ARE bigger blocks. Imagine the example again. Chunk 5120 - 6143, encrypted as two sectors with IVs 10 and 11. Now we want to use 1024 as Block size and encrypt the chunk as a whole with an IV of 5. What happens if a program (lets say "dd bs=512") requests the chunk from 5632 - 6143 ? As far as I can tell the upper layers won't align the request to a block of 1024 bytes. To decrypt/encrypt the data correctly we would have to read and decrypt chunk 5120 - 6143 and return only 5632 - 6143. If a write access happens this is even worse, because we would have to: read the block, update the block, write the block. (Without the read we can't update the data correctly.) THAT's why I want to use sectors as maximum unit... so long Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
> _I_ can use my approach, but not yours, to bring my already existing > crypted fs into the new state. The losetup option to set the encryption > chunk size is used only once for each fs, but at that one time you can > do: Ok, I understand what you mean. > Q> losetup -e blowfish --use-fs-blocksize \ > /dev/loop0 cryptfile > Q> losetup -e blowfish /dev/loop1 cryptfile > Q> dd if=/dev/loop0 of=/dev/loop1 bs=4k > Q> losetup -d /dev/loop1 > Q> losetup -d /dev/loop0 > (Replace bs=4k" with the blocksize of your underlying filesystem). I.e., The "bs=4k" shouldn't be necessary at all. Because this would imply that the correct behaviour of the encryption is dependent on the blocksize in which the data is requested by an outer read() call. If this is really the case something is broken. (AFAIK the current behaviour is broken, because it exactly relies on this fact.) > I can convert the stuff _in place_ (it actually works, anyone please > complain loudly if it shouldn't) even when my 'cryptfile' is /dev/hdax > and I don't have sizeof(/dev/hdax) space left on my hard drives. This could be dangerous. I'm not sure that the kernel handles this kind of concurrent access to the same encrypted blocks correctly. (I admit, that I think it should work but it still might be dangerous...) > Whether you use a signed or unsigned int for the sector address does not > affect the encryption at all. So I don't see your point here... Well you said that my patch was a shot from the hip and complained that I declared IV as "int" even if "request.sector" was declared as "unsigned int" :-). > much the same idea as you). In fact, your approach could well be default > way of encryption, but there should be a way to set the block size. At > least to the block size of the underlying (call it compatibility mode or > so). Yet, I think that there may be some clever uses for a completely > free choice of the encryption chunk size, down to one cipher block size > and up to the underlying's block size. To build in a backward compatible way is OK, but I'm still concerned about bigger blocksizes than sectors: The reason I wanted sectors is, that it seems that the smallest chunk of data that can be requested from the outside is one sector, which means 512 bytes. (I'm not sure if this is correct, but because ReiserFS works with the sector approach I guess it has to be true.) It should be no problem to implement smaller encryption chunk sizes. On the other hand, if we use more than one sector, we might run into the problem that some utility which accesses the loop device on a more direct way ( - bypasses the FS - ) uses sectors as access unit and NOT blocks. In this case we would have to ensure that the accesses are always aligned to the chosen blocksize and this makes things more complicated. (It is possible though...) > IV generation is what I am worried about. > There is a paper about why it is a bad idea to use > sequence numbers for CBC IV's. I just have to find the reference to it. Does this mean sequence as in 0,1,2,3,4 ... or does this mean any pre-calculate-able sequence ? In the former case we might just use a simple one way hash-function over the requested sector number. In the latter case, we might be able to use a message digest algorithm which includes the sector number and part of the key. (Both approaches slow the encryption further down, but for security concerned people this doesn't matter...) > PS: Ingo, it's vger.kernel.org, not vger.linux.org. Yes I found that out... I just imagined that I sent my first message to vger.linux.org, don't ask me why :-). so long Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
Ian Sterling wrote: > But, it seems to me that being able to have a different IV for > each filesystem would be a good thing, but having it depend on something > as volatile as sector of the disk, seems bad. It's not the sector of the _disk_. It's the requested sector of the loop device. The requested sector is just another encoding of the requested offset within the loop device. It is completely independent of the underlying medium, on which the data is hosted. > What about the first block of the underlying file holding an IV? The idea is, not to use an IV per file system or file or ... but per sector (or more general a unit of encrypted data.) The reason for this is that if you don't use this scheme similar sectors will be encrypted similar. By comparing sectors you can tell when sectors are identical without knowing anything about the used cipher. so long Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
Andi Kleen wrote: > > On Fri, Oct 13, 2000 at 10:15:21PM +, Marc Mutz wrote: > > This thread was about encryption. And it was about IV's. The only > > encryption that vanilla loop.c (from 2.2.17) offers is 'none' and 'xor'. > > None is just that: a no-op. And xor does not use an IV. So the only > > ciphers that could possibly have been adressed by this patch are the > > ones in the kerneli patch. So the on-disk format did _not_ change > > And any other filter modules which use the open loadable block > converter interface in the loop device. That kerneli exists as a patch is > IMHO just an historical accident, near all of it can be done fine without > ever touching any linux source at all. Please take a small peek out of > your small world ;) > OK, I did not think of such. Are there any? Can you give an example and pointers? > BTW, kerneli would also not handle the case of switching block sizes anyways, > with relative IVs or not, because it does not restart its CFB chain inside > the device blocks every 512 byte blocks with a new IV. When you switch > from a bigger block size to a smaller you would need backwards peeking to > earlier blocks (and know the block size anyways). Similar problem for > going to bigger blocks. Ingo's change makes it a bit less painless, but > still not trivial to handle. Please re-read my mails. I never said that the current kerneli patch does this right. In the end, I just suggest that Ingos patch included some mechanism to allow for backwards compatibility. Marc Mutz wrote in reply to Ingo Rohloff: > Your approach is not so far away from what I suggested (which is a > simplification of what Alex suggested to me when I came up with pretty > much the same idea as you). In fact, your approach could well be default > way of encryption, but there should be a way to set the block size. At > least to the block size of the underlying (call it compatibility mode or > so). So, the only provision that needs to be made to ensure backwards compatibility (both with the kerneli patch and other modules that still use absolute block numbers) is a way to switch between the new approach and the old, defaulting to the new. The easiest way to do this, IMO, is to allocate a new field 'encryption_chunk_size' or so from the set of reserved words in struct loop_info. One might even get away with a single bit, indicating whether to use 512 byte blocks or underlying blocks as encryption chunks. Maybe lo_flags could be used when it becomes allowed to set the single bit LO_FLAGS_USE_512_BYTE_CHUNKS or so. Then teach losetup to set this bit unless instructed not to. - Old losetups would still work the same way they do today. - When switching to new losetups, one can do the conversion using the command line switch (e.g.) --use-compatibility-IVs You can even make compatibility mode support in the kernel a compile-time option. Is this mechanism acceptable? > Yet, I think that there may be some clever uses for a completely > free choice of the encryption chunk size, down to one cipher block size > and up to the underlying's block size. The above snippet was just a train of thoughts. Marc -- Marc Mutz <[EMAIL PROTECTED]> http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
Andi Kleen wrote: On Fri, Oct 13, 2000 at 10:15:21PM +, Marc Mutz wrote: snip This thread was about encryption. And it was about IV's. The only encryption that vanilla loop.c (from 2.2.17) offers is 'none' and 'xor'. None is just that: a no-op. And xor does not use an IV. So the only ciphers that could possibly have been adressed by this patch are the ones in the kerneli patch. So the on-disk format did _not_ change And any other filter modules which use the open loadable block converter interface in the loop device. That kerneli exists as a patch is IMHO just an historical accident, near all of it can be done fine without ever touching any linux source at all. Please take a small peek out of your small world ;) OK, I did not think of such. Are there any? Can you give an example and pointers? BTW, kerneli would also not handle the case of switching block sizes anyways, with relative IVs or not, because it does not restart its CFB chain inside the device blocks every 512 byte blocks with a new IV. When you switch from a bigger block size to a smaller you would need backwards peeking to earlier blocks (and know the block size anyways). Similar problem for going to bigger blocks. Ingo's change makes it a bit less painless, but still not trivial to handle. snip Please re-read my mails. I never said that the current kerneli patch does this right. In the end, I just suggest that Ingos patch included some mechanism to allow for backwards compatibility. Marc Mutz wrote in reply to Ingo Rohloff: snip Your approach is not so far away from what I suggested (which is a simplification of what Alex suggested to me when I came up with pretty much the same idea as you). In fact, your approach could well be default way of encryption, but there should be a way to set the block size. At least to the block size of the underlying (call it compatibility mode or so). interrupted So, the only provision that needs to be made to ensure backwards compatibility (both with the kerneli patch and other modules that still use absolute block numbers) is a way to switch between the new approach and the old, defaulting to the new. The easiest way to do this, IMO, is to allocate a new field 'encryption_chunk_size' or so from the set of reserved words in struct loop_info. One might even get away with a single bit, indicating whether to use 512 byte blocks or underlying blocks as encryption chunks. Maybe lo_flags could be used when it becomes allowed to set the single bit LO_FLAGS_USE_512_BYTE_CHUNKS or so. Then teach losetup to set this bit unless instructed not to. - Old losetups would still work the same way they do today. - When switching to new losetups, one can do the conversion using the command line switch (e.g.) --use-compatibility-IVs You can even make compatibility mode support in the kernel a compile-time option. Is this mechanism acceptable? Yet, I think that there may be some clever uses for a completely free choice of the encryption chunk size, down to one cipher block size and up to the underlying's block size. snip The above snippet was just a train of thoughts. Marc -- Marc Mutz [EMAIL PROTECTED] http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
_I_ can use my approach, but not yours, to bring my already existing crypted fs into the new state. The losetup option to set the encryption chunk size is used only once for each fs, but at that one time you can do: Ok, I understand what you mean. Q losetup -e blowfish --use-fs-blocksize \ /dev/loop0 cryptfile Q losetup -e blowfish /dev/loop1 cryptfile Q dd if=/dev/loop0 of=/dev/loop1 bs=4k Q losetup -d /dev/loop1 Q losetup -d /dev/loop0 (Replace bs=4k" with the blocksize of your underlying filesystem). I.e., The "bs=4k" shouldn't be necessary at all. Because this would imply that the correct behaviour of the encryption is dependent on the blocksize in which the data is requested by an outer read() call. If this is really the case something is broken. (AFAIK the current behaviour is broken, because it exactly relies on this fact.) I can convert the stuff _in place_ (it actually works, anyone please complain loudly if it shouldn't) even when my 'cryptfile' is /dev/hdax and I don't have sizeof(/dev/hdax) space left on my hard drives. This could be dangerous. I'm not sure that the kernel handles this kind of concurrent access to the same encrypted blocks correctly. (I admit, that I think it should work but it still might be dangerous...) Whether you use a signed or unsigned int for the sector address does not affect the encryption at all. So I don't see your point here... Well you said that my patch was a shot from the hip and complained that I declared IV as "int" even if "request.sector" was declared as "unsigned int" :-). much the same idea as you). In fact, your approach could well be default way of encryption, but there should be a way to set the block size. At least to the block size of the underlying (call it compatibility mode or so). Yet, I think that there may be some clever uses for a completely free choice of the encryption chunk size, down to one cipher block size and up to the underlying's block size. To build in a backward compatible way is OK, but I'm still concerned about bigger blocksizes than sectors: The reason I wanted sectors is, that it seems that the smallest chunk of data that can be requested from the outside is one sector, which means 512 bytes. (I'm not sure if this is correct, but because ReiserFS works with the sector approach I guess it has to be true.) It should be no problem to implement smaller encryption chunk sizes. On the other hand, if we use more than one sector, we might run into the problem that some utility which accesses the loop device on a more direct way ( - bypasses the FS - ) uses sectors as access unit and NOT blocks. In this case we would have to ensure that the accesses are always aligned to the chosen blocksize and this makes things more complicated. (It is possible though...) IV generation is what I am worried about. There is a paper about why it is a bad idea to use sequence numbers for CBC IV's. I just have to find the reference to it. Does this mean sequence as in 0,1,2,3,4 ... or does this mean any pre-calculate-able sequence ? In the former case we might just use a simple one way hash-function over the requested sector number. In the latter case, we might be able to use a message digest algorithm which includes the sector number and part of the key. (Both approaches slow the encryption further down, but for security concerned people this doesn't matter...) PS: Ingo, it's vger.kernel.org, not vger.linux.org. Yes I found that out... I just imagined that I sent my first message to vger.linux.org, don't ask me why :-). so long Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
BTW, kerneli would also not handle the case of switching block sizes anyways, with relative IVs or not, because it does not restart its CFB chain inside the device blocks every 512 byte blocks with a new IV. My (inofficial) patch set for twofish and blowfish does though :-). I'm not sure if the CBC modes at the moment reset the Chain at all. (I have to have a closer look at the kerneli-patches... But this has to wait until tuesday, because that's the day of my last exam in university.) When you switch from a bigger block size to a smaller you would need backwards peeking to earlier blocks (and know the block size anyways). hmm hmm. I think its' possible without that: Example: Blocksize 1024, so for example the chunk from offset 5120 - 6143. would be encrypted with IV 5. Know we switch to 512 Bytes. to encrypt/decrypt from offset 5120 - 6143 you use the IVs 10 and 11. So I don't see the problem. Similar problem for going to bigger blocks. Ingo's change makes it a bit less painless, but still not trivial to handle. The only problem I see ARE bigger blocks. Imagine the example again. Chunk 5120 - 6143, encrypted as two sectors with IVs 10 and 11. Now we want to use 1024 as Block size and encrypt the chunk as a whole with an IV of 5. What happens if a program (lets say "dd bs=512") requests the chunk from 5632 - 6143 ? As far as I can tell the upper layers won't align the request to a block of 1024 bytes. To decrypt/encrypt the data correctly we would have to read and decrypt chunk 5120 - 6143 and return only 5632 - 6143. If a write access happens this is even worse, because we would have to: read the block, update the block, write the block. (Without the read we can't update the data correctly.) THAT's why I want to use sectors as maximum unit... so long Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
So, the only provision that needs to be made to ensure backwards compatibility (both with the kerneli patch and other modules that still use absolute block numbers) is a way to switch between the new approach and the old, defaulting to the new. The easiest way to do this, IMO, is to allocate a new field 'encryption_chunk_size' or so from the set of reserved words in struct loop_info. One might even get away with a single bit, indicating whether to use 512 byte blocks or underlying blocks as encryption chunks. Maybe lo_flags could be used when it becomes allowed to set the single bit LO_FLAGS_USE_512_BYTE_CHUNKS or so. Then teach losetup to set this bit unless instructed not to. Yes that's the start. I have to study loop.c more intensivly, because I think I found at least two more trap doors. (It's amazing that it works at all :-) ) Look at the line if (size len) size = len This seems to be horrible wrong... A CBC chain always has to decrypt/encrypt a whole block otherwise the data my be irrecoverable. (With the sector approach it works, because len is sectors 9 ...) And also block = current_request-sector / (blksize 9); offset = (current_request-sector % (blksize 9)) 9; The whole operation will go wrong if offset != 0 . so long Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
Reed Petty wrote: Caution is advised when depending upon crypto systems that use relative block numbers as IV. The security may not be a strong as hoped. There are some who believe that "not unique" IVs (across multiple filesystems) facilitates some methods of cryptanalysis. ... Ahh that explains it... Perhaps losetup can allow the user to specify a "IVseed" value and then pass to the transfer modules IVseed + relative block. This would also allow existing absolute block based encrypted file systems to be relocated (IVseed = absolute # of 1st block), satisfy those among us who demand unique IVs, and allow those who prefer operational convenience at the cost of weaker security to do so. An IVseed is a good idea. What would you think of using a secure hash function on the key as IVseed ? This should ensure almost unique IVs and you don't need a second parameter two encrypt/decrypt a file. (On the other hand this scheme is of course weaker than your approach...) so long Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
On Fri, Oct 13, 2000 at 10:15:21PM +, Marc Mutz wrote: > Andi Kleen wrote: > > > > On Fri, Oct 13, 2000 at 05:04:08PM +, Marc Mutz wrote: > > > Andi Kleen wrote: > > > > > > > > > > > 2.4 has already broken backwards compatibility to 2.2 (IV changed > > > > from disk absolute to relative). When you change it now (before 2.4.0) > > > > it is relatively painless. I think the change is a good idea. > > > > > > > > > You're wrong. All kernels from int-2.2.10.4 onwards can be configured to > > > use relative block numbers as IV's. Both the FAQ in Documentation/crypto > > > and my HOWTO suggest to set CONFIG_BLK_DEV_LOOP_USE_REL_BLOCK to 'y'. > > > > That is not a standard kernel option. I'm not talking about any unofficial > > patchkits like the i* patches, just about what the standard loop device does. > > An encryption module can be backwards compatible itself by mapping the blocks > > itself, but without changes it will have an incompatible on disk format. > > > > This thread was about encryption. And it was about IV's. The only > encryption that vanilla loop.c (from 2.2.17) offers is 'none' and 'xor'. > None is just that: a no-op. And xor does not use an IV. So the only > ciphers that could possibly have been adressed by this patch are the > ones in the kerneli patch. So the on-disk format did _not_ change And any other filter modules which use the open loadable block converter interface in the loop device. That kerneli exists as a patch is IMHO just an historical accident, near all of it can be done fine without ever touching any linux source at all. Please take a small peek out of your small world ;) BTW, kerneli would also not handle the case of switching block sizes anyways, with relative IVs or not, because it does not restart its CFB chain inside the device blocks every 512 byte blocks with a new IV. When you switch from a bigger block size to a smaller you would need backwards peeking to earlier blocks (and know the block size anyways). Similar problem for going to bigger blocks. Ingo's change makes it a bit less painless, but still not trivial to handle. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
Andi Kleen wrote: > > On Fri, Oct 13, 2000 at 05:04:08PM +, Marc Mutz wrote: > > Andi Kleen wrote: > > > > > > > > 2.4 has already broken backwards compatibility to 2.2 (IV changed > > > from disk absolute to relative). When you change it now (before 2.4.0) > > > it is relatively painless. I think the change is a good idea. > > > > > > You're wrong. All kernels from int-2.2.10.4 onwards can be configured to > > use relative block numbers as IV's. Both the FAQ in Documentation/crypto > > and my HOWTO suggest to set CONFIG_BLK_DEV_LOOP_USE_REL_BLOCK to 'y'. > > That is not a standard kernel option. I'm not talking about any unofficial > patchkits like the i* patches, just about what the standard loop device does. > An encryption module can be backwards compatible itself by mapping the blocks > itself, but without changes it will have an incompatible on disk format. > This thread was about encryption. And it was about IV's. The only encryption that vanilla loop.c (from 2.2.17) offers is 'none' and 'xor'. None is just that: a no-op. And xor does not use an IV. So the only ciphers that could possibly have been adressed by this patch are the ones in the kerneli patch. So the on-disk format did _not_ change between recent int-2.2.x.y kernels and 2.4-testx, provided the user followed the recommendations and used the previously mentioned option to use relative block numbers as IV's. Marc -- Marc Mutz <[EMAIL PROTECTED]> http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
kernel wrote: > > > Caution is advised when depending upon crypto systems that use relative > block numbers as IV. The security may not be a strong as hoped. > There are some who believe that "not unique" IVs (across multiple > filesystems) facilitates some methods of cryptanalysis. > Do you have a paper reference? I know that there are issues when using sequence numbers as IVs for CBC, but that is an isolated problem for CBC-like modes. > Strong security is the reason absolute block numbers were chosen at > the time I introduced loop.c cipher-block-chaining support (in > kernel 2.1.130). This has the unfortunate side effect of preventing > filesystem relocation... leading some to claim that loop.c is now > broken. A crypto system is only as strong as its weakest link. > Perhaps we should make Counter mode available for loop_gen.c. It does not have the artifacts that CBC has when seqence numbers are used as IVs. On the contrary: sequential IVs are an integral part of CTR mode encryption. This mode is not only just as secure as CBC, but has also the added bonus of only requiring encryption, something the AES would benfit from immensely, since decryption is so much slower for Rijndael than encryption and reads (decryption) are typically used more often in a filesystem than writes (encryption). > Perhaps losetup can allow the user to specify a "IVseed" value > and then pass to the transfer modules IVseed + relative block. > This would also allow existing absolute block based encrypted file > systems to be relocated (IVseed = absolute # of 1st block), Hm, I don't get you here. If I was to use absolute block numbers as IVs on a 1k block size ext2 filesystem, I could theoretically end up with the following mapping of loop device blocks vs. ext2 blocks Q> loop:0 1 2 3 4 5 Q> ext2:12 13 14 22 23 24 If I used IVseed = 12 here, the first three blocks would decrypt correctly, yet the forth would decrypt to white noise. > satisfy > those among us who demand unique IVs, and allow those who prefer > operational convenience at the cost of weaker security to do so. > As CTR mode _requires_ unique IVs (CBC does not), the upper half of the IV could be initialized from the key, whose length would thus grow by 50%. The lower half would contain the relative block number in units of 512 bytes. > Reed H. Petty > [EMAIL PROTECTED] Marc -- Marc Mutz <[EMAIL PROTECTED]> http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
On Fri, Oct 13, 2000 at 04:28:30AM +0200, Andi Kleen wrote: (snip) > 2.4 has already broken backwards compatibility to 2.2 (IV changed > from disk absolute to relative). When you change it now (before 2.4.0) > it is relatively painless. I think the change is a good idea. > Caution is advised when depending upon crypto systems that use relative block numbers as IV. The security may not be a strong as hoped. There are some who believe that "not unique" IVs (across multiple filesystems) facilitates some methods of cryptanalysis. Strong security is the reason absolute block numbers were chosen at the time I introduced loop.c cipher-block-chaining support (in kernel 2.1.130). This has the unfortunate side effect of preventing filesystem relocation... leading some to claim that loop.c is now broken. A crypto system is only as strong as its weakest link. Perhaps losetup can allow the user to specify a "IVseed" value and then pass to the transfer modules IVseed + relative block. This would also allow existing absolute block based encrypted file systems to be relocated (IVseed = absolute # of 1st block), satisfy those among us who demand unique IVs, and allow those who prefer operational convenience at the cost of weaker security to do so. Reed H. Petty [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
On Fri, Oct 13, 2000 at 05:04:08PM +, Marc Mutz wrote: > Andi Kleen wrote: > > > > > 2.4 has already broken backwards compatibility to 2.2 (IV changed > > from disk absolute to relative). When you change it now (before 2.4.0) > > it is relatively painless. I think the change is a good idea. > > > You're wrong. All kernels from int-2.2.10.4 onwards can be configured to > use relative block numbers as IV's. Both the FAQ in Documentation/crypto > and my HOWTO suggest to set CONFIG_BLK_DEV_LOOP_USE_REL_BLOCK to 'y'. That is not a standard kernel option. I'm not talking about any unofficial patchkits like the i* patches, just about what the standard loop device does. An encryption module can be backwards compatible itself by mapping the blocks itself, but without changes it will have an incompatible on disk format. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
Andi Kleen wrote: > > 2.4 has already broken backwards compatibility to 2.2 (IV changed > from disk absolute to relative). When you change it now (before 2.4.0) > it is relatively painless. I think the change is a good idea. You're wrong. All kernels from int-2.2.10.4 onwards can be configured to use relative block numbers as IV's. Both the FAQ in Documentation/crypto and my HOWTO suggest to set CONFIG_BLK_DEV_LOOP_USE_REL_BLOCK to 'y'. Marc -- Marc Mutz <[EMAIL PROTECTED]> http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
Ingo Rohloff wrote: > > > First: This breaks backward-compatibility. > Right, (I mentioned this), but the backward-compatible > way means: > Don't confuse the backwards-compatible way with the current (broken, of course) way of doing things. It is right that the _current_ approach of using the blocks of the underlying as encryption units has all the problems that you describe. Yet, the fix that I suggested is clean and works exactly as what you want to do. There is only one difference: _I_ can use my approach, but not yours, to bring my already existing crypted fs into the new state. The losetup option to set the encryption chunk size is used only once for each fs, but at that one time you can do: Q> losetup -e blowfish --use-fs-blocksize \ /dev/loop0 cryptfile Q> losetup -e blowfish /dev/loop1 cryptfile Q> dd if=/dev/loop0 of=/dev/loop1 bs=4k Q> losetup -d /dev/loop1 Q> losetup -d /dev/loop0 (Replace bs=4k" with the blocksize of your underlying filesystem). I.e., I can convert the stuff _in place_ (it actually works, anyone please complain loudly if it shouldn't) even when my 'cryptfile' is /dev/hdax and I don't have sizeof(/dev/hdax) space left on my hard drives. > BUT: "unsigned int" and "int" have the same bit size right ? > The crypto algorithms only care about the bits not the > signedness (and if they do, they only have to interpret > the IV as signed... no problem...) Whether you use a signed or unsigned int for the sector address does not affect the encryption at all. So I don't see your point here... Your approach is not so far away from what I suggested (which is a simplification of what Alex suggested to me when I came up with pretty much the same idea as you). In fact, your approach could well be default way of encryption, but there should be a way to set the block size. At least to the block size of the underlying (call it compatibility mode or so). Yet, I think that there may be some clever uses for a completely free choice of the encryption chunk size, down to one cipher block size and up to the underlying's block size. IV generation is what I am worried about. There is a paper about why it is a bad idea to use sequence numbers for CBC IV's. I just have to find the reference to it. Marc PS: Ingo, it's vger.kernel.org, not vger.linux.org. -- Marc Mutz <[EMAIL PROTECTED]> http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
Andi Kleen wrote: snip 2.4 has already broken backwards compatibility to 2.2 (IV changed from disk absolute to relative). When you change it now (before 2.4.0) it is relatively painless. I think the change is a good idea. snip You're wrong. All kernels from int-2.2.10.4 onwards can be configured to use relative block numbers as IV's. Both the FAQ in Documentation/crypto and my HOWTO suggest to set CONFIG_BLK_DEV_LOOP_USE_REL_BLOCK to 'y'. Marc -- Marc Mutz [EMAIL PROTECTED] http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
On Fri, Oct 13, 2000 at 04:28:30AM +0200, Andi Kleen wrote: (snip) 2.4 has already broken backwards compatibility to 2.2 (IV changed from disk absolute to relative). When you change it now (before 2.4.0) it is relatively painless. I think the change is a good idea. Caution is advised when depending upon crypto systems that use relative block numbers as IV. The security may not be a strong as hoped. There are some who believe that "not unique" IVs (across multiple filesystems) facilitates some methods of cryptanalysis. Strong security is the reason absolute block numbers were chosen at the time I introduced loop.c cipher-block-chaining support (in kernel 2.1.130). This has the unfortunate side effect of preventing filesystem relocation... leading some to claim that loop.c is now broken. A crypto system is only as strong as its weakest link. Perhaps losetup can allow the user to specify a "IVseed" value and then pass to the transfer modules IVseed + relative block. This would also allow existing absolute block based encrypted file systems to be relocated (IVseed = absolute # of 1st block), satisfy those among us who demand unique IVs, and allow those who prefer operational convenience at the cost of weaker security to do so. Reed H. Petty [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
Andi Kleen wrote: On Fri, Oct 13, 2000 at 05:04:08PM +, Marc Mutz wrote: Andi Kleen wrote: snip 2.4 has already broken backwards compatibility to 2.2 (IV changed from disk absolute to relative). When you change it now (before 2.4.0) it is relatively painless. I think the change is a good idea. snip You're wrong. All kernels from int-2.2.10.4 onwards can be configured to use relative block numbers as IV's. Both the FAQ in Documentation/crypto and my HOWTO suggest to set CONFIG_BLK_DEV_LOOP_USE_REL_BLOCK to 'y'. That is not a standard kernel option. I'm not talking about any unofficial patchkits like the i* patches, just about what the standard loop device does. An encryption module can be backwards compatible itself by mapping the blocks itself, but without changes it will have an incompatible on disk format. This thread was about encryption. And it was about IV's. The only encryption that vanilla loop.c (from 2.2.17) offers is 'none' and 'xor'. None is just that: a no-op. And xor does not use an IV. So the only ciphers that could possibly have been adressed by this patch are the ones in the kerneli patch. So the on-disk format did _not_ change between recent int-2.2.x.y kernels and 2.4-testx, provided the user followed the recommendations and used the previously mentioned option to use relative block numbers as IV's. Marc -- Marc Mutz [EMAIL PROTECTED] http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
On Fri, Oct 13, 2000 at 03:50:41AM +0100, Ian Stirling wrote: > > > > On Fri, Oct 13, 2000 at 04:19:49AM +, Ingo Rohloff wrote: > > > 2.4 has already broken backwards compatibility to 2.2 (IV changed > > from disk absolute to relative). When you change it now (before 2.4.0) > > it is relatively painless. I think the change is a good idea. > > I've been away from the list for a while, so this has probably been > discussed. > But, it seems to me that being able to have a different IV for > each filesystem would be a good thing, but having it depend on something > as volatile as sector of the disk, seems bad. > What about the first block of the underlying file holding an IV? > > Then, if a loopback mount attempt finds a valid IV block at the > start (heavily CRC'd or similar, so the likelyhood of it ever > finding false magic is negligable (Say 10^-50)) it mounts > the filesystem, using the IV found. > > Please tell me where the glaring error is :) The loop device does not support any metadata. Such stuff has to be stored somewhere else. If you want metadata in your loop encryption module you can just supply it with a private ioctl from losetup. I don't think such policy belongs in the main loop device, it already carries enough cruft. [if you wanted a loop device that supports metadata I would wait for the new LVM IBM promised to release someday -- it'll apparently support such things. But a simple user space solution looks cleaner to me for now.] Also the sector number AFAIK works fine as an IV as long as you use a cipher with a sufficiently big block size (e.g. one of the AES candidates with 128bit blocks). With short block sizes predictible IV is a bigger problem. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
> > On Fri, Oct 13, 2000 at 04:19:49AM +, Ingo Rohloff wrote: > 2.4 has already broken backwards compatibility to 2.2 (IV changed > from disk absolute to relative). When you change it now (before 2.4.0) > it is relatively painless. I think the change is a good idea. I've been away from the list for a while, so this has probably been discussed. But, it seems to me that being able to have a different IV for each filesystem would be a good thing, but having it depend on something as volatile as sector of the disk, seems bad. What about the first block of the underlying file holding an IV? Then, if a loopback mount attempt finds a valid IV block at the start (heavily CRC'd or similar, so the likelyhood of it ever finding false magic is negligable (Say 10^-50)) it mounts the filesystem, using the IV found. Please tell me where the glaring error is :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
On Fri, Oct 13, 2000 at 04:19:49AM +, Ingo Rohloff wrote: > Hi again, > > Marc Mutz wrote: > > > > The loop device supports different IVs; > > > the IVs are initilized with the requested block > > > number. > > > > I believe a better way is to use the requested > > > sector number from CURRENT->sector. > > > Using this value should make the encryption and decryption > > > process completely independent from the underlying device. > > > Two times no. > > > > First: This breaks backward-compatibility. > Right, (I mentioned this), but the backward-compatible > way means: 2.4 has already broken backwards compatibility to 2.2 (IV changed from disk absolute to relative). When you change it now (before 2.4.0) it is relatively painless. I think the change is a good idea. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
Hi again, Marc Mutz wrote: > > The loop device supports different IVs; > > the IVs are initilized with the requested block > > number. > > I believe a better way is to use the requested > > sector number from CURRENT->sector. > > Using this value should make the encryption and decryption > > process completely independent from the underlying device. > Two times no. > > First: This breaks backward-compatibility. Right, (I mentioned this), but the backward-compatible way means: You might get problems over NFS using a backing file. You get problems if you burn a backing file to a CD (at least that's what it says in the FAQ), or if you copy it to another partition with a different file system (which handles blocks differently) or ... Has anyone tried to use an encrypted backing file on ReiserFS. I would be interested if it works with the old patch set. I even created an encrypted ReiserFS in a backing file, which was hosted on an uncrypted ReiserFS. (ReiserFS doesn't care about sector boundries, so it is especially useful for testing in this case.) I bet that this won't work with the old approach. (Even if this might be, because the cryption algorithms don't care about block boundries too :-( ) I know it works with my approach because I tried (even over NFS). > Second: I don't know much of the block device handling > in Linux, but what you produced seems like a quick > shot. I can see this e.g. at the point where you > declare 'sector' to be 'int' (7th hunk), whereas in > include/linux/blkdev.h request.sector is declared > _unsigned_ int. Well ok, my fault. BUT: "unsigned int" and "int" have the same bit size right ? The crypto algorithms only care about the bits not the signedness (and if they do, they only have to interpret the IV as signed... no problem...) > I don't know what request.sector is for loop > devices (The block number of the underlying > filesystem, if any? The hard sector number of the > underlying blockdevice? Always the 512-byte-blocks > number?), but if it is not the latter, i.e. always > "position >> 9", you have just shifted the issue > from one level (the fs block size) to another > (whatever units sector is in). No I haven't. Because as you can see from the source: 1. The CURRENT->sector is the requested sector of the loop device, which has nothing (whatsoever) to do with the underlying backing medium (it is even independent, of using a backing file or device.) 2. It is ALWAYS assumed to be 512 bytes. (This doesn't change, even if the blocksize of the backing device is SMALLER than 512 bytes.) You got it right, it is (position >> 9). But "position" means requested position within the loop device, which is as I said completely independent of the backing medium. You can even have two DIFFERENT (using different passwords) encrypted filesystems in the same backing file. Both mounted at the same time. (For example in a 2Mb file you can use the first MB for the first FS and the second Mb for the second FS.) you can do that like this: dd if=/dev/zero of=crypt.tst bs=1024 count=2048 losetup -e twofish /dev/loop0 crypt.tst (give Password 1) losetup -e twofish -o 1048576 /dev/loop1 crypt.tst (give Password 2) mke2fs -b 1024 /dev/loop0 1024 mke2fs -b 1024 /dev/loop1 1024 mount /dev/loop0 /mnt1 mount /dev/loop1 /mnt2 BTW this is _tested_. It works. (And you can do it over NFS And you can burn crypt.tst to a CD without any problems.) Try this with the current approach... It won't work. > The better solution (for 2.2. and 2.4; in 2.5 Andries Brouwer has > something more clean in his mind, IIUHC) is to add a new field to struct > loop_info to indicate the encryption chunk size and patch losetup/mount > to set this to 512 by default and to the filesystem block size if asked > to by some command line switch. This allows people to convert their > stuff. This makes things more complicated. (It also gives you more choices, but I don't think that the choices are very useful. It only gives you a higher chance of corrupting your data.) Converting the stuff is not so difficult. Copy your encrypted stuff to somewhere else (if you like use PGP to crypt it anyway). Change kernel. Remake filesystem on crypted medium. Copy your stuff back. > You may want to join [EMAIL PROTECTED] (majordomo) if you want > to work on this. Ah thanks for the hint, I didn't know this mailing list. I hope it is not in dutch ? If it is I apologize for posting in english. (I can't speak dutch). so long Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
Hi again, Marc Mutz wrote: The loop device supports different IVs; the IVs are initilized with the requested block number. I believe a better way is to use the requested sector number from CURRENT-sector. Using this value should make the encryption and decryption process completely independent from the underlying device. Two times no. First: This breaks backward-compatibility. Right, (I mentioned this), but the backward-compatible way means: You might get problems over NFS using a backing file. You get problems if you burn a backing file to a CD (at least that's what it says in the FAQ), or if you copy it to another partition with a different file system (which handles blocks differently) or ... Has anyone tried to use an encrypted backing file on ReiserFS. I would be interested if it works with the old patch set. I even created an encrypted ReiserFS in a backing file, which was hosted on an uncrypted ReiserFS. (ReiserFS doesn't care about sector boundries, so it is especially useful for testing in this case.) I bet that this won't work with the old approach. (Even if this might be, because the cryption algorithms don't care about block boundries too :-( ) I know it works with my approach because I tried (even over NFS). Second: I don't know much of the block device handling in Linux, but what you produced seems like a quick shot. I can see this e.g. at the point where you declare 'sector' to be 'int' (7th hunk), whereas in include/linux/blkdev.h request.sector is declared _unsigned_ int. Well ok, my fault. BUT: "unsigned int" and "int" have the same bit size right ? The crypto algorithms only care about the bits not the signedness (and if they do, they only have to interpret the IV as signed... no problem...) I don't know what request.sector is for loop devices (The block number of the underlying filesystem, if any? The hard sector number of the underlying blockdevice? Always the 512-byte-blocks number?), but if it is not the latter, i.e. always "position 9", you have just shifted the issue from one level (the fs block size) to another (whatever units sector is in). No I haven't. Because as you can see from the source: 1. The CURRENT-sector is the requested sector of the loop device, which has nothing (whatsoever) to do with the underlying backing medium (it is even independent, of using a backing file or device.) 2. It is ALWAYS assumed to be 512 bytes. (This doesn't change, even if the blocksize of the backing device is SMALLER than 512 bytes.) You got it right, it is (position 9). But "position" means requested position within the loop device, which is as I said completely independent of the backing medium. You can even have two DIFFERENT (using different passwords) encrypted filesystems in the same backing file. Both mounted at the same time. (For example in a 2Mb file you can use the first MB for the first FS and the second Mb for the second FS.) you can do that like this: dd if=/dev/zero of=crypt.tst bs=1024 count=2048 losetup -e twofish /dev/loop0 crypt.tst (give Password 1) losetup -e twofish -o 1048576 /dev/loop1 crypt.tst (give Password 2) mke2fs -b 1024 /dev/loop0 1024 mke2fs -b 1024 /dev/loop1 1024 mount /dev/loop0 /mnt1 mount /dev/loop1 /mnt2 BTW this is _tested_. It works. (And you can do it over NFS And you can burn crypt.tst to a CD without any problems.) Try this with the current approach... It won't work. The better solution (for 2.2. and 2.4; in 2.5 Andries Brouwer has something more clean in his mind, IIUHC) is to add a new field to struct loop_info to indicate the encryption chunk size and patch losetup/mount to set this to 512 by default and to the filesystem block size if asked to by some command line switch. This allows people to convert their stuff. This makes things more complicated. (It also gives you more choices, but I don't think that the choices are very useful. It only gives you a higher chance of corrupting your data.) Converting the stuff is not so difficult. Copy your encrypted stuff to somewhere else (if you like use PGP to crypt it anyway). Change kernel. Remake filesystem on crypted medium. Copy your stuff back. You may want to join [EMAIL PROTECTED] (majordomo) if you want to work on this. Ah thanks for the hint, I didn't know this mailing list. I hope it is not in dutch ? If it is I apologize for posting in english. (I can't speak dutch). so long Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
On Fri, Oct 13, 2000 at 04:19:49AM +, Ingo Rohloff wrote: Hi again, Marc Mutz wrote: The loop device supports different IVs; the IVs are initilized with the requested block number. I believe a better way is to use the requested sector number from CURRENT-sector. Using this value should make the encryption and decryption process completely independent from the underlying device. Two times no. First: This breaks backward-compatibility. Right, (I mentioned this), but the backward-compatible way means: 2.4 has already broken backwards compatibility to 2.2 (IV changed from disk absolute to relative). When you change it now (before 2.4.0) it is relatively painless. I think the change is a good idea. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
On Fri, Oct 13, 2000 at 04:19:49AM +, Ingo Rohloff wrote: snip 2.4 has already broken backwards compatibility to 2.2 (IV changed from disk absolute to relative). When you change it now (before 2.4.0) it is relatively painless. I think the change is a good idea. I've been away from the list for a while, so this has probably been discussed. But, it seems to me that being able to have a different IV for each filesystem would be a good thing, but having it depend on something as volatile as sector of the disk, seems bad. What about the first block of the underlying file holding an IV? Then, if a loopback mount attempt finds a valid IV block at the start (heavily CRC'd or similar, so the likelyhood of it ever finding false magic is negligable (Say 10^-50)) it mounts the filesystem, using the IV found. Please tell me where the glaring error is :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
On Fri, Oct 13, 2000 at 03:50:41AM +0100, Ian Stirling wrote: On Fri, Oct 13, 2000 at 04:19:49AM +, Ingo Rohloff wrote: snip 2.4 has already broken backwards compatibility to 2.2 (IV changed from disk absolute to relative). When you change it now (before 2.4.0) it is relatively painless. I think the change is a good idea. I've been away from the list for a while, so this has probably been discussed. But, it seems to me that being able to have a different IV for each filesystem would be a good thing, but having it depend on something as volatile as sector of the disk, seems bad. What about the first block of the underlying file holding an IV? Then, if a loopback mount attempt finds a valid IV block at the start (heavily CRC'd or similar, so the likelyhood of it ever finding false magic is negligable (Say 10^-50)) it mounts the filesystem, using the IV found. Please tell me where the glaring error is :) The loop device does not support any metadata. Such stuff has to be stored somewhere else. If you want metadata in your loop encryption module you can just supply it with a private ioctl from losetup. I don't think such policy belongs in the main loop device, it already carries enough cruft. [if you wanted a loop device that supports metadata I would wait for the new LVM IBM promised to release someday -- it'll apparently support such things. But a simple user space solution looks cleaner to me for now.] Also the sector number AFAIK works fine as an IV as long as you use a cipher with a sufficiently big block size (e.g. one of the AES candidates with 128bit blocks). With short block sizes predictible IV is a bigger problem. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
[added cc: linux-crypto] Ingo Rohloff wrote: > > Hi, > > First some explanation. Most cryption algorithms initialize > the cryption process with some init values, called IV (by me :-). > This means that two identical clear messages will give > different encrypted messages, if different IVs are used. > > The loop device supports different IVs; > the IVs are initilized with the requested block > number. > > I believe a better way is to use the requested > sector number from CURRENT->sector. > Using this value should make the encryption and decryption > process completely independent from the underlying device. > Two times no. First: This breaks backward-compatibility. Second: I don't know much of the block device handling in Linux, but what you produced seems like a quick shot. I can see this e.g. at the point where you declare 'sector' to be 'int' (7th hunk), whereas in include/linux/blkdev.h request.sector is declared _unsigned_ int. I don't know what request.sector is for loop devices (The block number of the underlying filesystem, if any? The hard sector number of the underlying blockdevice? Always the 512-byte-blocks number?), but if it is not the latter, i.e. always "position >> 9", you have just shifted the issue from one level (the fs block size) to another (whatever units sector is in). The better solution (for 2.2. and 2.4; in 2.5 Andries Brouwer has something more clean in his mind, IIUHC) is to add a new field to struct loop_info to indicate the encryption chunk size and patch losetup/mount to set this to 512 by default and to the filesystem block size if asked to by some command line switch. This allows people to convert their stuff. You may want to join [EMAIL PROTECTED] (majordomo) if you want to work on this. Marc -- Marc Mutz <[EMAIL PROTECTED]> http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
[added cc: linux-crypto] Ingo Rohloff wrote: Hi, First some explanation. Most cryption algorithms initialize the cryption process with some init values, called IV (by me :-). This means that two identical clear messages will give different encrypted messages, if different IVs are used. The loop device supports different IVs; the IVs are initilized with the requested block number. I believe a better way is to use the requested sector number from CURRENT-sector. Using this value should make the encryption and decryption process completely independent from the underlying device. Two times no. First: This breaks backward-compatibility. Second: I don't know much of the block device handling in Linux, but what you produced seems like a quick shot. I can see this e.g. at the point where you declare 'sector' to be 'int' (7th hunk), whereas in include/linux/blkdev.h request.sector is declared _unsigned_ int. I don't know what request.sector is for loop devices (The block number of the underlying filesystem, if any? The hard sector number of the underlying blockdevice? Always the 512-byte-blocks number?), but if it is not the latter, i.e. always "position 9", you have just shifted the issue from one level (the fs block size) to another (whatever units sector is in). The better solution (for 2.2. and 2.4; in 2.5 Andries Brouwer has something more clean in his mind, IIUHC) is to add a new field to struct loop_info to indicate the encryption chunk size and patch losetup/mount to set this to 512 by default and to the filesystem block size if asked to by some command line switch. This allows people to convert their stuff. You may want to join [EMAIL PROTECTED] (majordomo) if you want to work on this. Marc -- Marc Mutz [EMAIL PROTECTED] http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
A patch to loop.c for better cryption support
Hi,
First some explanation. Most cryption algorithms initialize
the cryption process with some init values, called IV (by me :-).
This means that two identical clear messages will give
different encrypted messages, if different IVs are used.
The loop device supports different IVs;
the IVs are initilized with the requested block
number.
I believe a better way is to use the requested
sector number from CURRENT->sector.
Using this value should make the encryption and decryption
process completely independent from the underlying device.
This is especially important when using a backing file.
At the moment (as far as i heard) you can't use a backing
file on a harddisk and then burn it to a CD, because the
blocksize changes. Using sectors as atomic encryption unit
should solve this problem.
There is one drawback: The cryption algorithms have to
know this semantic. At the moment most of the cryption algorithms
use CBC mode to crypt a stream. When sector numbers are
used as IV's the CBC mode has to be restarted periodically
after 512 bytes with an incremented sector number as new IV's.
(Please CC me if you want to comment :-) )
so long
Ingo
PS: Please have a look at the patch. It is against linux-2.4test9.
I already mailed this patch to Alexander Kjeldaas who
maintains the international crypto patch, but I don't know
who maintains the loop device. (I know that it was originally
written by Theodore Ts'o, but is he also the Maintainer ?)
Please include the patch into the main tree...
--- linux-2.4test9/drivers/block/loop_old.c Tue Oct 10 14:25:10 2000
+++ linux-2.4test9/drivers/block/loop.c Tue Oct 10 16:09:11 2000
@@ -169,7 +169,7 @@
}
static int lo_send(struct loop_device *lo, char *data, int len, loff_t pos,
- int blksize)
+ int IV)
{
struct file *file = lo->lo_backing_file; /* kudos to NFsckingS */
struct address_space *mapping = lo->lo_dentry->d_inode->i_mapping;
@@ -182,7 +182,6 @@
index = pos >> PAGE_CACHE_SHIFT;
offset = pos & (PAGE_CACHE_SIZE - 1);
while (len > 0) {
- int IV = index * (PAGE_CACHE_SIZE/blksize) + offset/blksize;
size = PAGE_CACHE_SIZE - offset;
if (size > len)
size = len;
@@ -221,7 +220,7 @@
struct lo_read_data {
struct loop_device *lo;
char *data;
- int blksize;
+ int IV;
};
static int lo_read_actor(read_descriptor_t * desc, struct page *page, unsigned long
offset, unsigned long size)
@@ -230,8 +229,8 @@
unsigned long count = desc->count;
struct lo_read_data *p = (struct lo_read_data*)desc->buf;
struct loop_device *lo = p->lo;
- int IV = page->index * (PAGE_CACHE_SIZE/p->blksize) + offset/p->blksize;
-
+ int IV = p->IV;
+
if (size > count)
size = count;
@@ -251,7 +250,7 @@
}
static int lo_receive(struct loop_device *lo, char *data, int len, loff_t pos,
- int blksize)
+ int IV)
{
struct file *file = lo->lo_backing_file;
struct lo_read_data cookie;
@@ -259,7 +258,7 @@
cookie.lo = lo;
cookie.data = data;
- cookie.blksize = blksize;
+ cookie.IV = IV;
desc.written = 0;
desc.count = len;
desc.buf = (char*)
@@ -270,7 +269,7 @@
static void do_lo_request(request_queue_t * q)
{
- int block, offset, len, blksize, size;
+ int sector, block, offset, len, blksize, size;
char*dest_addr;
struct loop_device *lo;
struct buffer_head *bh;
@@ -296,8 +295,9 @@
}
dest_addr = current_request->buffer;
+ sector = current_request->sector;
len = current_request->current_nr_sectors << 9;
-
+
blksize = BLOCK_SIZE;
if (blksize_size[MAJOR(lo->lo_device)]) {
blksize = blksize_size[MAJOR(lo->lo_device)][MINOR(lo->lo_device)];
@@ -348,7 +348,7 @@
if ((lo->transfer)(lo, current_request->cmd,
bh->b_data + offset,
- dest_addr, size, block)) {
+ dest_addr, size, sector)) {
printk(KERN_ERR "loop: transfer error block %d\n",
block);
brelse(bh);
@@ -371,10 +371,10 @@
pos = ((loff_t)current_request->sector << 9) + lo->lo_offset;
spin_unlock_irq(_request_lock);
if (current_request->cmd == WRITE) {
- if (lo_send(lo, dest_addr, len, pos, blksize))
+ if (lo_send(lo, dest_addr, len, pos, sector))
goto error_out_lock;
} else {
- if (lo_receive(lo, dest_addr, len, pos, blksize))
+ if (lo_receive(lo, dest_addr, len, pos, sector))
goto error_out_lock;
}
done:
A patch to loop.c for better cryption support
Hi,
First some explanation. Most cryption algorithms initialize
the cryption process with some init values, called IV (by me :-).
This means that two identical clear messages will give
different encrypted messages, if different IVs are used.
The loop device supports different IVs;
the IVs are initilized with the requested block
number.
I believe a better way is to use the requested
sector number from CURRENT-sector.
Using this value should make the encryption and decryption
process completely independent from the underlying device.
This is especially important when using a backing file.
At the moment (as far as i heard) you can't use a backing
file on a harddisk and then burn it to a CD, because the
blocksize changes. Using sectors as atomic encryption unit
should solve this problem.
There is one drawback: The cryption algorithms have to
know this semantic. At the moment most of the cryption algorithms
use CBC mode to crypt a stream. When sector numbers are
used as IV's the CBC mode has to be restarted periodically
after 512 bytes with an incremented sector number as new IV's.
(Please CC me if you want to comment :-) )
so long
Ingo
PS: Please have a look at the patch. It is against linux-2.4test9.
I already mailed this patch to Alexander Kjeldaas who
maintains the international crypto patch, but I don't know
who maintains the loop device. (I know that it was originally
written by Theodore Ts'o, but is he also the Maintainer ?)
Please include the patch into the main tree...
--- linux-2.4test9/drivers/block/loop_old.c Tue Oct 10 14:25:10 2000
+++ linux-2.4test9/drivers/block/loop.c Tue Oct 10 16:09:11 2000
@@ -169,7 +169,7 @@
}
static int lo_send(struct loop_device *lo, char *data, int len, loff_t pos,
- int blksize)
+ int IV)
{
struct file *file = lo-lo_backing_file; /* kudos to NFsckingS */
struct address_space *mapping = lo-lo_dentry-d_inode-i_mapping;
@@ -182,7 +182,6 @@
index = pos PAGE_CACHE_SHIFT;
offset = pos (PAGE_CACHE_SIZE - 1);
while (len 0) {
- int IV = index * (PAGE_CACHE_SIZE/blksize) + offset/blksize;
size = PAGE_CACHE_SIZE - offset;
if (size len)
size = len;
@@ -221,7 +220,7 @@
struct lo_read_data {
struct loop_device *lo;
char *data;
- int blksize;
+ int IV;
};
static int lo_read_actor(read_descriptor_t * desc, struct page *page, unsigned long
offset, unsigned long size)
@@ -230,8 +229,8 @@
unsigned long count = desc-count;
struct lo_read_data *p = (struct lo_read_data*)desc-buf;
struct loop_device *lo = p-lo;
- int IV = page-index * (PAGE_CACHE_SIZE/p-blksize) + offset/p-blksize;
-
+ int IV = p-IV;
+
if (size count)
size = count;
@@ -251,7 +250,7 @@
}
static int lo_receive(struct loop_device *lo, char *data, int len, loff_t pos,
- int blksize)
+ int IV)
{
struct file *file = lo-lo_backing_file;
struct lo_read_data cookie;
@@ -259,7 +258,7 @@
cookie.lo = lo;
cookie.data = data;
- cookie.blksize = blksize;
+ cookie.IV = IV;
desc.written = 0;
desc.count = len;
desc.buf = (char*)cookie;
@@ -270,7 +269,7 @@
static void do_lo_request(request_queue_t * q)
{
- int block, offset, len, blksize, size;
+ int sector, block, offset, len, blksize, size;
char*dest_addr;
struct loop_device *lo;
struct buffer_head *bh;
@@ -296,8 +295,9 @@
}
dest_addr = current_request-buffer;
+ sector = current_request-sector;
len = current_request-current_nr_sectors 9;
-
+
blksize = BLOCK_SIZE;
if (blksize_size[MAJOR(lo-lo_device)]) {
blksize = blksize_size[MAJOR(lo-lo_device)][MINOR(lo-lo_device)];
@@ -348,7 +348,7 @@
if ((lo-transfer)(lo, current_request-cmd,
bh-b_data + offset,
- dest_addr, size, block)) {
+ dest_addr, size, sector)) {
printk(KERN_ERR "loop: transfer error block %d\n",
block);
brelse(bh);
@@ -371,10 +371,10 @@
pos = ((loff_t)current_request-sector 9) + lo-lo_offset;
spin_unlock_irq(io_request_lock);
if (current_request-cmd == WRITE) {
- if (lo_send(lo, dest_addr, len, pos, blksize))
+ if (lo_send(lo, dest_addr, len, pos, sector))
goto error_out_lock;
} else {
- if (lo_receive(lo, dest_addr, len, pos, blksize))
+ if (lo_receive(lo, dest_addr, len, pos, sector))
goto error_out_lock;
}
done:
