Ilmari Karonen

6,341 reputation

725

bio	website	vyznev.net
	location	Helsinki, Finland
	age
visits	member for	1 year, 10 months
	seen	Jun 14 at 14:08
stats	profile views	91

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,341 reputation	bio	website	vyznev.net	visits	member for	1 year, 10 months
725 badges		location	Helsinki, Finland		seen	Jun 14 at 14:08

summary answers questions tags badges favorites bounties reputation activity

192 Comments

suggestions reviews revisions comments badges posts accepts all

Jul 22	comment	Recovering state of modified RC4 key scheduling algorithm Cross-posted to math.SE: math.stackexchange.com/questions/173909/…
Jul 22	comment	Is this a secure implementation of password reset email? @Polynomial: The big difference between passwords and authentication tokens is that we get to choose the tokens, and need not take human memorability into account in choosing them. We can easily pick a random 128-bit string as a token, but very few user-chosen passwords will contain that much entropy. In particular, using sufficiently long random tokens obviates the need for key-stretching KDFs (and also allows the use of the same token for both user identification and authentication, although that isn't actually needed in this case).
Jul 20	comment	Is this a secure implementation of password reset email? @PeterFriend: As long as the token submissions also include the user ID (which they should), you don't have to worry about indexing the tokens or ensuring their uniqueness. And as long as your tokens are long enough (say, 128 bits) brute force attacks will not be practical.
Jul 5	comment	Poor man's SSL - is this method as safe as SSL/TLS? You might want to consider writing your own I/O abstraction layer. Nothing fancy, just a bunch of simple and fairly high-level methods that will take care of your I/O needs and let you change the underlying transport mechanism in one place as needed.
Jul 5	comment	Poor man's SSL - is this method as safe as SSL/TLS? Also, if sending data in multiple messages, remember to include a sequence number to protect against message dropping or replay attacks.
Jul 3	comment	Vulnerabilities of encrypting data with known regularities Just to be pedantic, decrypting the last block with OFB mode doesn't require decrypting the entire ciphertext, just generating the entire keystream. All you need to do that are $k_1$ and the IV.
Jun 30	comment	Multiple Hash Functions that work in either nesting Thanks, corrected. You're right that some commutativity is needed here, and that some of the group axioms are not, although it would at least be nice to have the map $x \mapsto a \bullet x$ be invertible for all $a$. Still, all the obvious examples I actually have in my head are, in fact, abelian groups, although that might of course just be due to my limited imagination.
Jun 21	comment	Chaum undeniable signature - justification for probability of misleading the verifier? No problem. By the way, have you read Chaum and van Antwerpen's original paper? The proofs therein are pretty short and straightforward.
Jun 21	comment	Is symmetric encryption vulnerable to plain-text-attacks? @gereeter: Indeed, AES, or any other secure block cipher, is IND-CPA secure in all the classic non-deterministic modes of operation (CBC, CFB, OFB and CTR), provided that an appropriate IV or nonce is used. However, it's worth noting that no non-authenticating cipher mode can achieve full IND-CCA2 security, since all such modes are at least somewhat malleable. For IND-CCA2, you need to encrypt-then-MAC or use an authenticating encryption mode.
Jun 18	comment	Is this password migration strategy secure? Ps. For related questions, see crypto.stackexchange.com/questions/2840/… and crypto.stackexchange.com/questions/2831/…
Jun 18	comment	Is this password migration strategy secure? @fgrieu (and CodeInChaos): It looks like you've pretty much answered the question. Would you like to turn you comment into an actual answer so that it can be accepted?
Jun 9	comment	How hard is to find the operators of an addition knowing the sum of them? It should also be noted that being NP-hard only means that some cases of the problem are hard to solve, not that all or even most of them are. In particular, there are plenty of easy instances of the subset sum problem (such as any instance where $A$ contains both $X$ and $B-X$). For crypto, it's not enough to have a problem that is known to be sometimes hard; we also need a way to generate instances of it that are each extremely likely to be among the hard ones.
Jun 3	comment	OpenPGP Signature Packet hashed data @calccrypto: Ps. I realized that I missed some parts of the hash input when reading the RFC myself. I've updated my answer, hopefully all the parts of the input are there now. Alas, I probably won't be able to fix any possibly remaining mistakes before next week or later.
Jun 3	comment	OpenPGP Signature Packet hashed data Other places where the term "hash context" is used, particularly section 3.7.1.1, suggest that it basically means an object or data structure that contains the internal state of the hash function and supports methods for providing further input and for finalizing the hash and returning the output. (Most cryptographic hash implementations provide such an API.) In various parts of the RFC, it is recommended that several hashes be computed in parallel by maintaining multiple hash contexts.
Jun 1	comment	How to get the keyword from a keyword cipher? In particular, in your table you have the plaintext frequency of `F` given as 2.228, while in your ciphertext the frequency of `W` is 2.492 (out of 100, I assume). That seems like a perfectly plausible amount of random variation, assuming that `F` indeed encrypts to `W`.
May 29	comment	Algorithm to securely exchange identities @Ricky: Depends on what the anonymous channel is like. If it's a single central server that timestamps all messages, then my attack won't work (but yours might). However, if it's a relay network like IRC, Usenet or various P2P networks, then different participants might receive messages in a different order.
May 29	comment	Algorithm to securely exchange identities ... One way to fix that would be for all participants to actually include all the four public keys (preferably in some canonical order, such as sorted by binary representation) in the confirmation messages in step 5 (and abort if there's a mismatch).
May 29	comment	Algorithm to securely exchange identities Ps. If the anonymous channel doesn't guarantee consistent message ordering, there could be issues with step 5. For example, if Alice, Bob, Carol and Dave post their public keys in order, but Bob can somehow also arrange to post a second public key so that Alice and Bob see it before Dave's key but Dave sees it after his own key, then the fact that Dave confirms that everything is right in step 5 tells Bob that the last posted key was indeed Dave's. (It also means that Alice and Carol now think they have Dave's key but actually only have two keys from Bob.)
May 29	comment	Algorithm to securely exchange identities Looks like this should indeed work, although one does need to think carefully about the trust model. For example, if the participants trust each other not to deviate from the protocol (and post multiple public keys in step 4), I believe step 5 isn't even needed. The same goes if the participants just don't care about how many valid keys they end up with at the end of step 4.
May 28	comment	Which MACs can be converted into a secure unkeyed hash function? If an attacker can generate given-prefix collisions for the underlying hash, they can generate collisions for HMAC as long as they know the key. AFAIK, pretty much all known collision attacks on common hash functions do yield given-prefix collisions. (The only way they might not is if they exploited some special weakness in the default initial state of the hash.)