Hot answers tagged

6

The IV is a random non-secret value. Its sole purpose is to prevent two similar blocks from yielding the same ciphertext as it could give information away about the structure of the plain text. In general you just generate the IV randomly and concatenate it to the ciphertext. The IV must be of the same length as the block for AES-CBC, which is 128 bits. You ...


3

You should always use an AEAD mode if you can, especially over the network. Crypto++ seems to support GCM, which is a good AEAD mode that has seen use in TLS 1.2. (There are others that are just as good, but TLS's "star power" lends GCM a lot of credibility.) Importantly, AEAD modes authenticate "additional data." This is unencrypted data not included with ...


3

You should not deploy your own encryption scheme for this, neither share symetric keys with multiple parties. To protect data on transit between each client and the server, you should use TLS to protect those connections. TLS will take care of symetric key agreement and encryption decryption to each client the right way, avoiding many many things you are ...


2

Absolutely. There is no risk from appending the nounce/iv to encrypted text.


2

From what I understand about the information betrayed by observing results of TRIM operations on LUKS encrypted volumes, actual plain-text data is not likely to be recovered. As you say, filesystem and data layout information can be inferred. Rather, details on the crypto implementation could help an attacker reduce the key space in a brute-force attack. ...


1

Using the same Key and IV pair for multiple file encryption is very dangerous because encrypting the two files with the same same content will result the same ciphertext for any block mode encryption. Here are a few related posts about this: Why must IV/key-pairs not be reused in CTR mode? Dangers of using CTR mode for encryption AES-CBC and IV — ...


1

No, it is not secure. First of all, you're suggesting a MAC-then-encrypt, which is known to be vulnerable to "chosen ciphertext" attacks (i.e. an attacker can take a valid message, modify it, and observe the result to gain information about the plaintext). Secondly, you're suggesting the use of a hash rather than a MAC or even better a digital signature. A ...


1

KW allows you to establish a long term secret but still use a different CEK for each message, this is important for some use cases, but not all. In the case of using JWE to send a single message to multiple recipients who all have different long term keys, this is essential as you need to wrap the CEK multiple times once for each recipient. JWE supports a ...



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