Hot answers tagged

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 ...


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 ...


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, ...


4

No, this is not a secure way of encrypting. Specifically, it does not meet the requirements for indistinguishability under chosen plaintext attack (IND-CPA), a basic security definition for encryption. According to IND-CPA, no attacker should be able to win the following game: The attacker selects two equal-length plaintext messages. The defender picks ...


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

"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

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

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 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