Tag Info

The really simple explanation for the difference between the two is this: ECB (electronic code book) is basically raw cipher. For each block of input, you encrypt the block and get some output. The problem with this transform is that any resident properties of the plaintext might well show up in the ciphertext – possibly not as clearly – that's what blocks ...

ECB and CBC are only about encryption. Most situations which call for encryption also need, at some point, integrity checks (ignoring the threat of active attackers is a common mistake). There are combined modes which do encryption and integrity simultaneously; see EAX and GCM (see also OCB, but this one has a few lingering patent issues).

The capacity of AES in terms of file encryption is practically unlimited for the time being, especially in OFB or CTR mode. An 8 GB file comprises short of $2^{29}$ 128-bit AES blocks. If one uses CBC or OFB CFB mode, odds of a collision (that is, the same block appearing in ciphertext, which reveals 128 bit worth of potentially usable information about the ...

If you mean how much data can safely be encrypted by AES with a single key (and IV), AES is designed to encrypt up to $2^{64}$ blocks of data before becoming susceptible to certain statistical attacks (in particular distinguishing the encrypted file from truly random data), because of its 128-bit block size. 8GB (= $2^{36}$ bits = $2^{29}$ blocks) is quite ...

Yes, simply encrypting each 16-byte block with AES-128 will insure their confidentiality if they are all different, w.r.t. to an adversary that can't break AES (nitpick: given that AES is an even permutation, we should also assume that more than two plaintext/ciphertexts pairs remain unknown, but that's a practical certainty). That use of AES can be named ...

Yes, this is one case where ECB mode is secure. It can be shown to be secure trivially from the indistinguishability assumptions of AES; that AES with an unknown key cannot be distinguished from a random permutation. If the plaintexts are all 16 bytes long, then in ECB mode, this directly means that the ECB mode encryption of those plaintexts are ...

While I'll try to answer your question at a theoretical level below, I'd like to first stress the following: It's a bad sign if, in the course of writing software, one is making such low-level decisions about encryption methods. Encryption security is extremely brittle, with seemingly insignificant details causing complete failure. With that said, the ...

I believe what you are seeing is that .NET automatically uses PKCS #7 padding. This will always add padding. Thus if your plaintext is a complete block length, one extra block of padding will be added. The reason the ciphertext ends up being the same in both of your test cases is that it is adding the same padding in both cases (see PaddingMode Enumeration ...

As far as is publicly known, no, you can't. If you could, that would constitute a practical known-plaintext key recovery attack on AES, and the existence of such an attack would mean that AES would be considered totally insecure by modern cryptographic standards. If you do figure out how to do that, publish it and you'll be famous. (Or, if you'd prefer ...

Well, assuming that you have a fixed block cipher (that is, you don't change the block cipher as the length of the message increases), then given a message of length $N$: Both ECB and OFB take $O(N)$ time for both encryption and decryption. Both ECB and OFB take $O(1)$ space in addition to the space to hold the encrypted/decrypted message (which is ...

Assuming: the objective is to protect the confidentiality of the user names from an attacker having read access to the encrypted data, the ability to add usernames of her choice, and nothing else (in particular, no access to the key, even by proxy of a computer or device holding the key, or side channel); the IV is randomly chosen for each individual ...

Use the master key in ECB mode. I have heard/read that this is cryptographically weak (Why?). The reason I include ECB mode here is that it could allow me to save half the storage space. Since the messages are only one block long, I suspect this may affect the 'traditional' arguments against ECB. Because any identical plaintexts will encrypt to the ...

No for practical definitions of possible, assuming the key was chosen truly randomly, and no side-channel information is available (such as the power-consumption traces of the encrypting device, or the time it took, for many encryptions). The design of AES strives to be such that the best way to find the key from plaintext-ciphertext examples is to try keys ...

As CodesInChaos comments, your basic idea seems sound, although a 64-bit block size leaves you with a rather low security margin. Personally, I'd be more comfortable using a cipher with a 128-bit block size (like AES), zero-padding the IDs to 64 bits, appending 64 random bits and encrypting the resulting 128-bit block. This means that: even with the ...

OFB is a mode of operation to ensure confidentiality of messages a) longer than the block size of the encryption algorithm, and b) that can be re-broadcast. The motivation for these kinds of modes it to avoid the weaknesses that come from using plain ECB mode. To be precise, the typical attack on ECB mode involves analyzing the ciphertext and looking for ...

As noted by poncho, both ECB and OFB encryption (and decryption) require $O(n)$ time and $O(1)$ additional space (excluding the input and output, which may be modeled as unseekable streams). These hold both in the average and in the worst case, and it's worth noting that the complexities approach their asymptotes very quickly; typically, the time complexity ...

Correct me if I'm wrong, but it sounds like the question is really, "If I encrypt a document multiple times with different keys in ECB mode, does the common vulnerability of patterns in plaintext showing in ciphertext go away?" The answer to this is no. Consider a simple cipher which has the following mappings: $E_{k_1}(0)=1234, E_{k_1}(1)=8532, ...

A replay attack works by blindly re-using an earlier message or ciphertext, or fragment thereof, typically one that was encrypted or signed. A simple example would be a bunker which receive the encrypted message "I'm General X, open the door". Now if this encrypted message was captured a week earlier and replayed by some opponent, well you get the idea. ...

ECB mode is a deterministic encryption, instead in OFB if the initial vector is random choosed (and of course published with the cryptogram) is a random encryption. What's the matter with det.enc.? The problem is that if you encoded two time the same message you are going to get two time the same chipertext, so the adversary can understand that you said the ...

I think what you are looking for is a Password-Based Key Derivation Function (PBKDF). You can take a moderately strong password, like 12-14 random letters and numbers (no dictionary words though!), and throw it into the PBKDF function together with some other parameters, e.g. salt, number of iterations and the desired key length. After that you have a ...

Search for passwords on IT Security and you will find tons of advice on how to store passwords, and how not to. Your scheme is not a good method for hashing passwords: it is a fast hash, it lacks any salt, and it unnecessarily limits the password length. People have studied this at great length: before trying to re-invent the wheel, I suggest you read up ...

What you are looking for is a Pseudo Random Function that should be indistinguishable from uniform, even if the key material that is passed to it is not. One potential problem with your scheme is that the AES key schedule is not particularly good at extracting the entropy from keys that are not selected (pseudo-)randomly, such as passwords and pass-phrases. ...

There is a NIST definition of CTS (CipherText Stealing) mode at: http://csrc.nist.gov/publications/nistpubs/800-38a/addendum-to-nist_sp800-38A.pdf. The title of that addendum answers the question: "Recommendation for Block Cipher Modes of Operation: Three Variants of Ciphertext Stealing for CBC Mode". The paper is also useful to understand that there are ...

For a key recovery attack, you'd basically need to break AES itself. There are no known practical key recovery attacks on AES (and if there were, it would not be considered safe to use), so your pretty much only hope would be to find some kind of side-channel attack on the AES implementation, or on the overall crypto framework it is part of. Alternatively, ...

A replay attack simply means that an attacker who intercepts a valid message can re-send that message as many times as they want. If there's nothing in the message that could not be legitimately repeated, then the recipient will have no reason not to accept it as a valid message. In general, all encryption modes are potentially vulnerable to replay ...

Wikipedia has an excellent visual demonstration of the insecurity of ECB mode when applied to (potentially) repetitive data: Here, the first picture on the left shows a simple cartoon image (Tux the Penguin). The second image is the same, but with the (raw, uncompressed RGB) image data encrypted using ECB mode. While details of the image are ...