New answers tagged

0

McNerdHair is correct to require you to use an authenticated mode. There are more options than GCM mode though: GCM mode is fast. It is sometimes called a 1.5 pass authenticated mode because of the fast GMAC calculation. It is standardized by NIST. CCM mode is another NIST certified mode specifically created for packet encryption, i.e. transport mode ...


5

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


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


-1

This thing should be simple. First you need a crypto library like openssl. If there is a registration phase, you could have the clients generate a pair of private/public keys, (DH or RSA, using openssl) then announce the public part on the server, also called client certificate. And that's it. On every new client-server connection, a symmetric key ...


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


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

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


0

To clarify and expand what I said in the comment: A GPU-based cracker can go through a LOT of MD5 hash per seconds. According to this, one based on the (old) NVIDIA Geforce 8800 Ultra can compute about 200 million hashes per seconds. Since your keyspace is a bit above 2 millions entry large, it means that you can get through ALL of it in about one second ...



Top 50 recent answers are included