Security Forums :: View topic - Which operation mode for container encryption?

Which operation mode for container encryption?

Security Forums -> Cryptographic Theory and Cryptanalysis - Internal and Transmission Security

Author: Pirol,

Posted: Thu Jun 24, 2004 12:42 am Post subject: Which operation mode for container encryption?
----
Hi,

i try to implement an application for container encryption like bestcrypt or drivecrypt in java. therefor i've implemented my own filesystem based on the taditional unix filesystem.

i like to know which operation mode of a blockcipher i should use (or maybe not a blockcipher?).

because of the problem that i need random access to the container file i can't encrypt the whole container in cbc-mode at all. in this case i have always to read from the beginning of the file :/
ecb mode is not secure enough in my opinion, because same plaintext produces same ciphertext :/
does it make sense for example to encrypt maybe 10 blocks at once? should i use several iv's for this case Question

what do you think, how bestcrypt or drivecrypt solves this problem?

Thanx a lot

Pirol

Author: JustinT, Location: Asheville, NC, US / Uberlândia, MG, Brazil

Posted: Thu Jun 24, 2004 6:52 am Post subject: Search a bit.
----
ECB is trivial to implement, yet completely insecure, so I'd highly suggest not using it. Try doing a forum search for "CTR mode", "Counter mode", "mode of operation", and "modes of operation", as it should return results including the most in-depth discussions we've had on the issue of which mode to choose. Personally, as will echo through my posts, I prefer CTR (Counter) mode, for use with block ciphers, as it essentially utilizes them in a stream cipher-like manner. You'll read more about that, once you've referred to the threads in a search. I'll leave you with this short bit, so you can start perusing, and gathering opinions on the choices you'll need to address before you begin such an implementation process.

To be concise, it's probably best to use a good block cipher, like Twofish, in a good mode of operation, like CTR, with 256-bit keys, at all times. Just read through my posts, for ideas on what parameters are conservatively secure - modes of operation included. There's a lot that goes into a cryptographic design process, so always hold the most precedence for security.

Author: Pirol,

Posted: Thu Jun 24, 2004 10:34 am Post subject:
----
thanx for giving me the right way JustinT.

one question in advance:

in "Handbook of Applied Cryptography, by A. Menezes, P. van Oorschot, and S. Vanstone, CRC Press, 1996" i have read, that Counter Mode is just a simplification of the OFB Mode.
As i understood the only difference is, that i use my counter instead of the IV (or as the IV) and reset the cipher before processing the next block, followed by a new update of the IV (with my counter).

Sorry for my question, but my english is not so well, so i'm not sure understanding all right Rolling Eyes

regards Pirol

Author: JustinT, Location: Asheville, NC, US / Uberlândia, MG, Brazil

Posted: Thu Jun 24, 2004 7:35 pm Post subject: How about this?
----
Does this bit of information, along with the simple "equation" I've given, help?

JustinT wrote:

Counter mode, just as OFB, is a mode of stream ciphering, modeled in the likes of the simple Vernam cipher, where plaintext is simply XOR'd with a stream of key material. To quickly define this:

Ki := E(K, Nonce || i) (where the counter, i = 1, ..., k and nonce is simply a contraction of a "number used once")
Ci := Pi XOR Ki

It is an extremely lucid mode of operation. Since the encryption and decryption functions are identical, it only requires the you implement the encryption function of a cipher, and does not require padding, unlike that of traditional CBC mode. When speed is of the essence, arbitrary parallelized computation is possible. Its security is relative to that of the block cipher. If counter mode is secure, then so should be the block cipher; if counter mode is insecure, then, as such, so should be the block cipher. Of course, this is taking into consideration information leakage, which is a general concern of block cipher modes of operation. Provided that you address information leakage, and use a unique nonce, both random and unpredictable, CTR will provide you with a highly efficient and secure mode of operation. If using this mode is a convenient possibility, both implementation-wise and security-wise, then do so, over CBC.

It requires specific care in order to achieve this, as it relies on the requisite security of the rest of the system; but, the solid etiquette for good, complete security that you will gain from learning the specific caretaking measures of cryptographic primitives is never a bad habit to fall into.

So, here you have a very concise overview of counter mode, which, still, sums up the majority of how this incredibly facile construction works.

If you care to go more in-depth with this, refer to official documentation that sanctions CTR as a specified and suggested mode in NIST SP 800-38A, as well as the initial suggestions, by seasoned cryptographers Lipmaa, Rogaway, and Wagner, which pushed for the NIST specification. I hope that provides some clarity for your understanding.

Last edited by JustinT on Mon Jul 12, 2004 8:22 pm; edited 1 time in total

Author: Pirol,

Posted: Mon Jul 12, 2004 6:17 pm Post subject:
----
Hi again,

ctr-mode is just fine. fortunately the java-provider i use offers this mode. one more question about this mode.

how should i generate the counter value? does it make sense to take the first 8 byte of the hash value from the passphrase?

Regards Pirol

Author: JustinT, Location: Asheville, NC, US / Uberlândia, MG, Brazil

Posted: Mon Jul 12, 2004 10:57 pm Post subject: Deriving the counter.
----
The criteria for deriving the counter, or ctr, as it's most commonly denoted by cryptographers, isn't that strict, nor should it be. There isn't one definitive way that is best in every situation, so it makes sense to standardize several ways to go about it, in a secure manner. The main concern is that you never use the same counter, nonce, and key combination more than once. Everything about this mode should be unique (nonce, counter, key, et cetera). I usually prefer to keep all of my cryptographic values random, so I'll use a cryptographically secure pseudo-random number generator, or some substitute that achieves similar, sufficient results (i.e., a simple linear feedback shift register will do, in most cases, since the randomness or unpredictability of the value isn't one of the concerns, as it would be with some other modes; only uniqueness is considered). This derivation can be arbitrary, protocol-specific, et cetera. It's a loose aspect of the mode.

Even though a hash function does provide a nice pseudo-random mapping that would more than suffice for this purpose, I would personally keep this separate from a passphrase. I would use the hash output of some other value, instead. The mode is simple enough, so it's nice to keep things organized and independent. After all, CTR is essentially a mere concatenation of a nonce and counter, that is encrypted to form a stream of key material; it's about as primitive and easy to analyze as modes can get. It's quite simple to keep values random and independent from one another, so that's the route I take; that's how I would do it. Either way, modes of operation are volatile things, and we've learned a tremendous amount of valuable information about them within the last decade (a lot of which I've discussed here). They should be crafted with meticulous precision, because they all depend heavily on the environment in which they operate. Ensuring that the entire system is secure is just as important to a mode of operation, as the parameters for the mode itself. It's so important, that one faulty parameter may mean the difference between security and compromise.

For the best insightful comments on deriving a counter, again, I will recommend that you peruse the standardized documentation for the recommended block cipher modes of operation, entitled NIST SP 800-38A, as well as the initial suggestions, by seasoned cryptographers Lipmaa, Rogaway, and Wagner, which led to this standardization of CTR mode. My method for going about counter derivation is one of the recommend methods, but they also list several others to choose from, that are decent in their own respect and appropriate for certain situations.

Perhaps you can compare the above information to your available options, and find the most resolute answer to your question. Oh, and be careful with information leakage. No mode is perfect, and will eventually leak information. Fortunately, CTR leaks little, so to mitigate the effects of this, and keep it to a negligibly insignificant amount, limit yourself to encrypting 2^60 blocks of information under a single key; that's around 2^64 bytes.

If you read about the forum, and explore other literary notes on cryptography, there are many solid reasons why CTR is the best confidentiality mode, out of the five common choices.

Security Forums -> Cryptographic Theory and Cryptanalysis - Internal and Transmission Security

output generated using printer-friendly topic mod, All times are GMT + 2 Hours

Page 1 of 1