Ilmari Karonen

6,291 reputation

725

bio	website	vyznev.net
	location	Helsinki, Finland
	age
visits	member for	1 year, 9 months
	seen	yesterday
stats	profile views	90

I'm not really a cryptographer, I just play one on the internet.

Seriously, I'm just a programmer and mathematician interested in puzzles and information security. I don't have any kind of formal crypto training, but I've picked up a few things here and there over the years. Topics I'm particularly interested in include protocol design and analysis, classical ciphers and information-theoretically secure crypto techniques such as one time pads and secret sharing schemes.

Please consider any (original) code I post to Stack Overflow (and other Stack Exchange sites) to be released under CC-Zero unless stated otherwise. You may do whatever you want with it and don't have to credit me in any way, although of course that would be nice.

	6,291 reputation	bio	website	vyznev.net	visits	member for	1 year, 9 months
725 badges		location	Helsinki, Finland		seen	yesterday

summary answers questions tags badges favorites bounties reputation activity

195 Comments

suggestions reviews revisions comments badges posts accepts all

Jan 16	comment	How do single use passwords work for an encrypted message @hunter: I suppose they might derive the actual encryption key directly using PBKDF2 from the user's permanent password, and then save an encrypted copy of that key for each one-time password. Or the statement on the website might just be missing some details.
Jan 11	comment	Is it possible to break a hash-based block cipher? Paŭlo, I know you're perfectly aware of this, but for others reading this answer, it may be worth pointing out that the "tweakable block cipher" $Enc_k^n(P)=P\oplus H(k,n)$ described above is also trivially distinguishable from a pseudorandom permutation, being linear in $P$. As indistinguishability from a PRP is the usual security property expected of a block cipher, I'd be hesitant to call this a block cipher of any kind at all (except maybe a "hopelessly broken" one).
Jan 11	comment	Deriving Keys for Symmetric Encryption and Authentication @Thomas: I believe I've seen the term "generalized counter" used in the literature for such deterministic non-repeating sequences.
Jan 11	comment	Creating an encryption key from several other keys and using hash functions Alternatively, you could also use any standard key derivation function, such as HKDF (RFC 5869).
Jan 10	comment	How secure is the knapsack? I assume you'd also want the process for generating $W$ and $X$ to give you $S$ as well (since knowing a hard problem that even you can't solve, and which may or may not have a solution, isn't generally very useful), right? What were you actually planning to do with it if you had one, anyway?
Jan 10	comment	How and why can a decryption program tell me that a key is incorrect? @Paŭlo: While storing a plain hash of a low-entropy password would be bad, I'm not aware of any issues with storing a hash of an encryption key properly derived from the password using a key-stretching KDF. If there's something wrong with that that I'm missing, please do let me know.
Jan 10	comment	Why is RSA usually limited to messages up to 1 block possible duplicate of Why is asymmetric cryptography bad for huge data?
Jan 9	comment	Using CBC with a fixed IV and a random first plaintext block @Joshua: In the scheme you've described in your question, the first ciphertext block is, in effect, the IV for the rest of the message. (That's how CBC works: every block of ciphertext is, in effect, used as the IV for the next block.) It's not predictable, even if the first plaintext block (or the "real" IV that's XORed with it) is, because it's obtained by encrypting the plaintext with an unknown (to the attacker) key.
Jan 9	comment	Using CBC with a fixed IV and a random first plaintext block Note that that's assuming that the adversary does not have oracle access to the block cipher. Even if the adversary does have such access to the high-level CBC mode encryption function (i.e. they can request the encryption of chosen plaintexts), CBC mode prevents them from directly feeding chosen inputs to the block cipher as long as they cannot predict the IV. Thus, the ability to predict the IV and oracle access to the block cipher are essentially equivalent for an IND-CPA adversary attacking CBC mode using this IV generation method -- either one implies the other.
Jan 9	comment	Using CBC with a fixed IV and a random first plaintext block @Joshua: It becomes unpredictable (to an adversary who does not know the key) when it passes through the block cipher.
Jan 7	comment	How and why can a decryption program tell me that a key is incorrect? Related: How does GPG verify succesful decryption? and Can I determine if a user has the wrong symmetric encryption key?
Jan 6	comment	Why xor the message into the state for sponge hashes? My point with the last sentence was that replacement is not really "mixing" at all; it just means throwing away part of the state and using that space to store the unmixed input for some later mixing step. At some point, you'll have to combine the input and the existing state in some nontrivial way; certainly that way doesn't have to be XOR -- it could be modular addition, or multiplication, or even something like an S-box -- but it has to be something other than just replacement. XOR seems as good a choice as any to me.
Jan 6	comment	Why xor the message into the state for sponge hashes? Replacing throws away the replaced part of the internal state. Of course, if the remaining part of the state is long enough, that might not matter, but then why bother even calculating the part you're going to replace anyway? And then you need to decide how you're going to mix the part you just replaced with the rest of the state...
Dec 28	comment	DES key expansion: why are these two descriptions different? Why are you using DES? We're not in the 70s anymore.
Dec 18	comment	Good enough deterministic PRNG based on hashes @Alexandre: According to the HMAC specification, if the given key is longer than the input block size of the hash, it is first reduced by hashing it with the plain hash. The input block size of SHA-512 is 128 bytes, so if the key $K$ is longer than that, $\text{HMAC-SHA512}(K,X)=\text{HMAC-SHA512}(\text{SHA512}(K),X)$, and thus the first 64 bytes of tonyk's construction will directly leak the effective MAC key.
Dec 16	comment	*phi(PQ) = (P-1) * (Q-1)** Simple equations like yours are pretty easy to format; I just added `$$` around what you'd written to trigger display math mode. For more advanced tricks, see this page.
Dec 9	comment	How can I break a Vigenère cipher with partial plain text? @Thomas: The `PASS` is kind of a red herring in this case, though; it's not actually all part of the same word.
Dec 9	comment	How can I break a Vigenère cipher with partial plain text? Good observation about the repeat. Your guess at the partial key is close, too, although one of the letters is off by one. Anyway, I'm kind of trying not to reveal too much of the solution, since it's pretty obvious (from the plaintext!) that it was meant as a challenge to be worked out by the student.
Dec 4	comment	Is there a secret sharing scheme which allows delegation/re-sharing without reconstructing the original secret? @Dilip: I'm not assuming that the shares of the two schemes are interchangeable. For example, I could take a secret shared using a 3-out-of-5 scheme and re-share it using a 7-out-of-10 scheme; then anyone with either 3 original shares or 7 new shares could recover the secret (but someone with 2 original and 6 new shares would still have no clue about it). Lemma 1 just says that I'd need to know at least 3 original shares to (recover and) re-share the secret; if the original scheme is secure, then there cannot be any shortcut that would allow me to do it with only 2.
Dec 4	comment	Is there a secret sharing scheme which allows delegation/re-sharing without reconstructing the original secret? @Dilip: I did mean to say $j$. The hypothetical expanded scheme requires $j$ shares to reconstruct the secret, while the original scheme is supposed to require $k$. If the holders of $k-1$ shares under the original scheme could somehow obtain $j$ or more shares under the new scheme, that would break the original scheme, contradicting the assumption that the original scheme was secure.