Hot answers tagged

4

I assume the client and server communicate via some secure channel e.g. TLS? Otherwise anyone sitting on the wire can mount a replay attack i.e. intercept the ciphertext sent to the client, and send that ciphertext back to the server to impersonate the intended recipient. From the comments it sounds like you are using the ciphertext passed to the client as ...


3

This all generally looks reasonable, but there are a couple of items to review: First and foremost, the note in Puzzlepalace's answer about the need for TLS most definitely applies. And preferably HSTS as well, if you can. Second, there are theoretical (read, not practical) attacks on GCM with nonces (IV) with lengths of other than 96-bits. So, while ...


2

A) AES keys are comprised of binary bits, not strings of characters. They should indeed be random, and no other properties are required. However, this does imply that they should be random bits, and not ASCII characters. B) If you decrypt ciphertext with an arbitrary random key, you will get some bytes as the plaintext. Whether these bytes constitute a ...


2

The simplest way of dealing with this I can think of is to more or less implement CBC mode yourself. All it requires is for you to be sure of the block size used: Build a random (and unique) IV of the same size as the AES block size (128 bits). Encrypt that block and store the result (let's call it A) Build a chain of 128-bits blocks containing your actual ...


2

It depends on the mode of operation and the padding method (if used). CTR, OFB, and CFB modes will always produce a plaintext length after decryption that is equal to the original, even if an incorrect key or IV is used. Authenticated encryption modes are specified to return no plaintext if the key is incorrect or the ciphertext has been tampered with. ...


2

The length of the decrypted bytes should always be a multiplicative of the block size, no matter if a correct key is used or not. There might of course be a situation where the decryption with the wrong key results in an output that looks like it uses a valid padding and by removing the padding the length is unequal to the original length. But that ...


1

Using MySQL's built-in functions for encrypting and decrypting information is generally not recommended for exactly the reason that you described - MySQL is often configured to log queries. If that's the case, the plain text data (and the encryption/decryption keys!) are written in plain text to the logs! Having said that - If you must use aes_encrypt and ...


1

Although in your case the IV should be okay in plaintext in the DB, there is a severe vulnerability if you allow the user to control the IV. The IV in decryption is used (and only used) to XOR the first block into the final plaintext - so if an attacker can control the IV they can arbitrarily control the first block of data, and the rest of the plaintext ...


1

Blowfish is secure enough for TLS/SSL but AES is preferred. Especially 256, because 128 is still considered unbreakable and 256 is even more secure.


1

All modern ciphers aim to produce what looks like random data - it's one of the core principles of information theory. Ciphers that don't produce apparently random looking data tend to have fairly serious flaws, since this provides an avenue for attack - going back to pre-computer ciphers, enigma had this issue, and fell, in part, due to pattern recognition ...


1

A: Any encryption key for any symmetric algorithm can and should be a random string of bits. Applying any kind of pattern would reduce the keyspace and thus reduce security. A string of 16 random ASCII characters would work as a key, but it would not be a very good one. A random bit string of that length has 128 bits of entropy. There are 95 printable ASCII ...



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