Seth

775 reputation

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

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

	775 reputation	bio	website		visits	member for	1 year, 10 months
15 badges		location			seen	yesterday

summary answers questions tags badges favorites bounties reputation activity

55 Actions

suggestions reviews revisions comments badges posts accepts all

Jun 17	comment	Security of authenticated encryption modes gcm & ccm It's my understanding that the different versions of OCB were motivated by desires to improve performance, simplify the proof, support associated data --- basically everything but security concerns. The "attack" you mention basically says that if you encrypt several gigabytes of data under the same key, an attacker can create a forgery with probability 2^-64; i.e., there is roughly a one-in-a-quintillion chance that the attacker will succeed. I doubt this is much of a concern for practioners.
Jun 8	comment	Questions about the ideal cipher model Your characterization of an ideal block cipher in the last paragraph is a bit off --- an ideal block cipher is a set of random permutations, one for each possible key. So the elf would have a set of tables.
Jun 4	revised	Encrypt-then-MAC paradigm added 119 characters in body
Jun 4	answered	Encrypt-then-MAC paradigm
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