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


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


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

This is basically a substitution cipher where words are converted to numbers and then those numbers are substituted for new numbers as the encryption step. You'd need to assume the language of plaintext, let's assume it's English. Every time the word "the" occurs in the original text, it will cause the same number to be output to replace it. Using some ...


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

I think the attack models establish constraints on the cipher parameters that allow you to confirm guesses in a brute force or probabilistic search. A simple way to look at it is that they let your write equations involving the cipher parameters. For example, in $c = enc(p,k)$, you can fix two of the parameters and solve for the third. Clearly $c$ (...


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

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