Hot answers tagged

10

ECB leaks if blocks are identical. For uniformly random data identical blocks become likely when you encrypt about $2^{n/2}$ blocks with an $n$ bit block cipher. CBC and CTR mode develop similar weaknesses when they encrypt that much data. => As long as you encrypt reasonable amounts (up to a petabyte or so) of random data with a 128 bit block cipher, like ...


8

Indeed, ECB is such that encrypting twice the same plaintext leads to the same ciphertext. Even worse, encrypting a plaintext containing twice the same plaintext block leads to a ciphertext containing twice the same ciphertext block. Either is a disadvantage because it goes against the ideal of a cipher: depriving the adversary from any knowledge about the ...


7

In the first block, the IV provides the "randomness", and in subsequent blocks you just use the previous block of ciphertext instead. Based on the assumption, that the cipher is not weak and behaves like a pseudorandom permutation, this is basically the same: You XOR something unpredictable on the plaintext, and then encrypt. As long as the IV is chosen ...


6

The modes you are referencing are specifically modes of operations for block ciphers, and therefore are not directly applicable to hash functions. Block cipher operations take 2 inputs, the key and a block-sized input value, and output a block-sized keyed permutation of the input. Hash functions take a variable length input, and output a fixed length value. ...


5

It is highly misleading to call how RSA Encryption is used as 'ECB mode'. With ECB mode, we break the plaintext into N bit segments, and send each one through the block cipher separately. The block cipher is deterministic, and so if two plaintext blocks happen to be the same, so will the corresponding ciphertext blocks. Now, with RSA encryption, we take ...


5

All modern block ciphers are supposed to be pseudorandom permutations, meaning that they cannot be efficiently distinguished from a truly random permutation without knowledge of the key. (If a practical distinguisher were to be found for a particular cipher, that cipher would be considered broken by modern standards.) This also implies that no two secure ...


4

What you have devised is no longer ECB. ECB encrypts multiple blocks using the same key. The reason we have modes of operation is so that we can encrypt multiple blocks using the same key in a way that is secure, that is identical blocks of plaintext do not encrypt to the same ciphertext block, among other properties. What you have devised uses a different ...


4

ECB is not secure even with per file keys, because if two blocks of the file are identical, this is visible in the ciphertext. The only * cases where ECB is secure is encrypting completely random data or encrypting a single block per key. You should pick something more secure if your can help it. If there is literally no other option than RC4 and AES ECB, ...


3

As CodesInChaos notes in the comments, having more ciphertext–plaintext pairs doesn't help with brute force guessing attacks. Well, that is, except for the minor issue of unicity. Basically, to narrow the results of your brute force attack down to a single key, you do need to have enough ciphertext–plaintext pairs that the length of the known plaintext ...


3

Better is a subjective term. However for the choice between ECB and CBC, the choice should be CBC for almost all situations. Although ECB and CBC are modes of operation of a block cipher, you could also turn this way of thinking around and see the block cipher as a configuration option for the mode of operation. The mode of operation has a big influence on ...


3

As long as the IV is chosen correctly, every individual block of the encrypted output will be uniformly random over the set of all bit-patterns of the given size. Each block is independent from the clear text, but they are not independent from each other. The first block contains the IV itself, which by construction is uniformly random and independent from ...


3

Yes there is a significant difference concerning brute-force. ECB suffers from multi target attacks whenever you encrypt the same message block. This is always possible in a chosen-plaintext attack and often possible in practice with a known-plaintext attack. With CBC the IV means that the plaintexts passed to the blockcipher are almost certainly unique ...


3

As Maarten Bodewes already wrote in a comment, if you ignore the computational overhead of XOR, then there is essentially no difference in CBC and ECB for a bruteforce attack. However, the question is actually mixing oranges and apples (and it is not obvious), because the security weakness of modes of operation has nothing to do with the underlying ...


2

In short, yes. The complementation property of DES states that if $DES_K(P) = C$, then $DES_{\overline{K}}(\overline{P}) = \overline{C}$, where $\overline{X}$ is the complement of a string $X$. ECB with DES takes a message $M_1M_2\cdots M_\ell$ and computes $C_1C_2\cdots C_\ell$, where $C_i = DES_K(M_i)$, for $1\le i\le\ell$. Therefore, if you encrypt ...


2

It's not ECB, but you "invited" another mode of operation. The best idea to describe your algorithm is as a stream cipher with an other function than XOR to interleave your key stream with the plaintext: The "IV key hash" generates a key stream like a good stream cipher should, and encrypting the plaintext with the key stream block is like XOR in a normal ...


2

Commandline openssl enc normally does Password Based Encryption which derives the actual key, and IV (although IV is ignored for ECB), from the password or passphrase you enter, using a variant of PBKDF1. To get "raw" encryption you must specify the key in hex with -K (uppercase), in which case -nosalt is irrelevant (because it applies only to PBKDF). Except ...


2

Perhaps. You indicate this is from an embedded device. This strongly implies everything the device needs to decrypt it is already present in the firmware of the machine, including both the algorithm and the key. Here is a blog post on how a talented engineer accomplished a similar feat through reverse engineering. Note that this was not a cryptographic ...


2

In general, this is a bad idea. I won't give you any concrete attacks, but will try to explain why you shouldn't do this. In general, if you want to encrypt a key then you should do it using a secure mode for this purpose. (One is the SIV mode of operation. Another is just to use GCM or CCM.) First, I want to stress that you should always use an ...


2

I suppose you have removed the base64 decoding, so you are working on the raw data. Then indeed the first block is decrypted as if we were in ECB-mode, because after decrypting the first block, we xor with the IV, which is all 0 and indeed has no effect. However, the IV for the next block will be the original previous ciphertext block. So after decrypting ...


2

"RSA/ECB/PKCS1Padding" - as you already found out - is not really implementing ECB. For instance Bouncy Castle also has "RSA/None/PKCS1Padding" to mean the same thing. ECB is used for block cipher modes of operation, and RSA is not a block cipher. For block ciphers ECB makes some kind of sense; it basically means performing the block cipher operation for ...


2

The concept of encrypting blocks independently but based on the address is sound. It's commonly used in disk encryption. In the simplest case you could use a tweakable blockcipher in an ECB like mode using the block index as tweak. But let's say you want to use an existing block cipher, like AES. In that case you want to turn that block cipher into a ...


2

The HSM is not supposed to expose its actual key material; that's the whole point of them, often: they're not as easy to compromise as a PC where key material is in memory that can leak etc. The value 86016e6572617465642044455333204b6579000000000000 is just, after the first two bytes, the ASCII representation of "enerated DES3 Key", which makes it very ...


1

Let me try to provide an answer for your question (despite the answers in the comment section). Some research showed that a recently discovered vulnerability allowed to extract the keys from SafeNet HSM (which the Luna G5 is). Therefore it should under normal circumstances NOT be possible to extract any private keys from the HSM. To your question in the ...


1

ECB is bad because identical plaintext blocks result in identical ciphertext blocks. Encrypted data is therefore not pseudo-random. This is how Tux looks like after ECB encryption: CTR mode doesn't have this problem. Data encrypted with CTR mode is pseudo-random and doesn't show any pattern. So CTR is much better. CBC and CFB can also decrypt parallel, ...


1

Yes this would work as stated by you. Explanation: If you're using a library supporting ECB (which you are actually using in this example) you can input the whole 32 bytes of plaintext and will receive the corresponding 32 bytes of ciphertext. Splitting the operation into two calls doesn't make any difference for libraries as internally they do nothing ...


1

This is why we use random initialization vectors (IVs) for all such algorithms.


1

This may sound crazy and absurd, but it seems that this scheme is simply broken: on encryption, the last block is somehow padded (the exact method is not really relevant, but perhaps the trailing bytes of penultimate plaintext block are copied) and encrypted, then finally ciphertext is trimmed to match plaintext size; on decryption, the same buffer is ...


1

Both: Secure deterministic encryption for one-block messages. ECB: No expansion for block-sized messages. Faster. SIV: Authentication. Works for messages of any size.



Only top voted, non community-wiki answers of a minimum length are eligible