New answers tagged

0

JSON Web Encryption essentially does this. Additionally it lets you select different Content Encryption Key (CEK) for each token. BASE64URL(UTF8(JWE Protected Header)) || '.' || BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE Authentication Tag) For my case, I ...


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

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


0

As far as I know its not the string working as a pattern or key, but array of bytes for example. Key length is very important. You do not use a random String key as keyword, but you can generate 128bit array of bytes from a string keyword. Hash algorithms does that for you. As an example you can use SHA hash algorithm to hash a keyword,Then use 128bits of it ...


0

A 128-bit key for AES need only be 128 bits long. No other properties are required, though other properties might be desired. If you choose a 16-character string, then you're not really using those 128 bits to their fullest. ASCII only supports 7 bits per character (the first bit of each byte is always zero), and your real-world entropy top out at around 6 ...


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


0

However, now I am trying to use "Type in the encryption key when you start up" and to save it in a session cookie (encrypted) but I do not know how to tell the user if his key is correct or not. Is there any reason why you are storing this client-side? The cookie will be sent with every request, and encryption here seems wrong because you will need ...


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.


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


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


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


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



Top 50 recent answers are included