Seth

730 reputation

bio	website
	location
	age
visits	member for	1 year, 9 months
	seen	yesterday
stats	profile views	10

I am a math/computer nerd. Nothing to see here, move along.

	730 reputation	bio	website		visits	member for	1 year, 9 months
15 badges		location			seen	yesterday

summary answers questions tags badges favorites bounties reputation activity

51 Actions

suggestions reviews revisions comments badges posts accepts all

Apr 15	comment	Is there an existing AEAD scheme with minimal IV requirements? It looks like if you change "Prepend randomness and message length, and append redundancy" to "Prepend message length and append redundancy", you'd lose IND-CPA security, retain OPerm security (modulo length-preservation), and still gain INT-CTXT security. But you'd also lose the ability to do streaming encryption in cases where the message length is not known in advance.
Apr 14	revised	Is there an existing AEAD scheme with minimal IV requirements? added 311 characters in body
Apr 13	revised	Is there an existing AEAD scheme with minimal IV requirements? added 15 characters in body
Apr 13	revised	Is there an existing AEAD scheme with minimal IV requirements? added 92 characters in body
Apr 13	answered	Is there an existing AEAD scheme with minimal IV requirements?
Mar 1	revised	What is the difference between MAC and HMAC? deleted 3 characters in body
Mar 1	answered	What is the difference between MAC and HMAC?
Feb 27	comment	Validating successful decryption in AES That looks fine. If you want to ensure that nothing in the header is tampered with, you could also compute $\mathsf{HMAC}(\mathsf{header} + c, k_m)$. Just be certain that you can't have $(\mathsf{header}, c)$ and $(\mathsf{header}', c')$ such that $\mathsf{header} + c$ = $\mathsf{header}' + c'$. I don't think this is a problem if headers are JSON strings, though.
Feb 26	comment	Is Truecrypt's multiple/cascading encryption safe? Perhaps someone more familiar with the history of crypto will correct me, but it's my understanding that Applied Cryptography was written before AES, at a time when the NSA was actively trying to cripple private-sector encryption. This included knocking down the DES key length to 56 bits so it could be brute-forced. Triple DES was one method cryptographers developed to fight this. In contrast, AES uses 128 bit keys (or longer), and the cryptographic community is more confident in our ability to design blockciphers. Cascading different types of ciphers addresses a different threat.
Feb 25	awarded	Critic
Feb 22	comment	Why nobody considers counter re-keying as a standard Block Cipher Mode? Note that this lets you set the tweak directly to $i$, rather than running it through some more complex function $F$. Also, you CAN build a tweakable cipher by running the tweak through a PRF and using that as a blockcipher key (which correponds roughly to SDL's scheme), but this is pretty slow.
Feb 22	revised	Symmetric encryption mode where ciphertext size is plain text size added 12 characters in body
Feb 22	answered	Symmetric encryption mode where ciphertext size is plain text size
Feb 21	comment	Validating successful decryption in AES You might want to Google PBKDF2 for handling the passphrase. Once you have a random "master" key M, you can do things like set your encryption key to HMAC(M, "Encryption key") and your MAC key to HMAC(M, "MAC key") [truncate the outputs as needed]. Or set the encryption key to AES(M,0x00...0000)AES(M,0x0...0001) and the MAC key to AES(M,0x00...0002). It doesn't matter where you store the IV, but when you compute the MAC, the IV needs to be part of the input string. Otherwise an attacker can mess with the IV to tamper with the plaintext - a common security hole. Not using a MAC is another. :)
Feb 21	comment	Validating successful decryption in AES The passphrase would be used to generate both the MAC key and the encryption key. So in that sense, they're not independent. But if you derive them from a pseudo-random function (PRF) using a master key (which is in turn derived from the passphrase), then the probability of an incorrect passphrase giving a correct MAC key but a incorrect encryption key is negligible. (If your PBKDF algorithm gives you enough bits for both an encryption key and a MAC key, then you can forgo the PRF).
Feb 20	revised	Validating successful decryption in AES added 235 characters in body
Feb 20	answered	Validating successful decryption in AES
Feb 14	comment	Why is OCB-AES mode not becoming a standard for authenticated encryption? $2^{60}$ blocks = 16 exabytes. Okay, point conceded: next time I want to encrypt 16 exabytes, I'll stay away from OCB3. :) On the other hand, as long as you encrypt fewer than 16 terabytes, the bound stays comfortably below $2^{-40}$.
Feb 14	comment	Use of CBC-AES-256 to encrypt usernames @amaterasu When you say the "key an IV are hardcoded and used for every username" do you mean that only one IV is being used? Each username must have its own IV, and in CBC mode, each IV needs to be a random 16-byte value. It's fine if the attacker sees the IVs, so you can go ahead and store them in the database.
Feb 14	comment	Use of CBC-AES-256 to encrypt usernames How are you storing the key? Can you guarantee that an attacker who compromises the server will not be able to steal the key? If not, encryption won't do you much good! (In contrast, salting and hashing passwords is a good practice, because there's no key sitting around that can undo these operations).