Ilmari Karonen

6,291 reputation

725

bio	website	vyznev.net
	location	Helsinki, Finland
	age
visits	member for	1 year, 9 months
	seen	May 12 at 7:27
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	May 12 at 7:27

summary answers questions tags badges favorites bounties reputation activity

195 Comments

suggestions reviews revisions comments badges posts accepts all

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.)
May 26	comment	How to calculate a key for Hill Cipher? Could you clarify your question a little? In particular, is there something you want to know that e.g. the Wikipedia article on the Hill cipher doesn't explain?
May 26	comment	What is the time complexity of the RC4 encryption & decryption algorithms? This is very similar to Complexity of ECB and OFB; note that most stream ciphers like RC4 behave very much like a block cipher in OFB mode. Anyway, the short answer is, it's all $O(n)$.
May 23	comment	Is this a secure multiparty protocol? Wait... you say you "don't care about the confidentiality of inputs", but if I'm reading your description right, anyone who knows the function $F$ (which I'd normally assume to be public knowledge unless specified otherwise) and the input $D$ can obviously compute the output $F(D)$. So I must be missing something, but what?
May 13	comment	Assistance Cracking Classical Cipher Alas, this question is not really on topic for crypto.SE either. The FAQ is pretty clear about it. (Personally, I kind of like these kinds of questions, at least as long as they look reasonably likely to be answerable and show more research effort than just "please break this cipher for me", but the consensus seems to be that they're all off topic here.)
May 12	comment	Does NTRU decrypt correctly now? I edited your answer to have nicer math and quote formatting; could you please check that I didn't break anything? (Ps. I looked at the P1363.1 draft and the Hirschhorn et al. paper, but I have to say I couldn't really figure out how they managed to get those specific formulas out of that paper. Maybe someone more familiar with it can clarify?)
May 9	comment	Encryption with “constant” initialization vector considered harmful @mtraut: I've corrected my answer somewhat to note that CBC mode is not quite as vulnerable to IV reuse as other common modes; in particular, in the specific scenario you describe, the only leak I can think of is that if the key, IV and plaintext are all identical, then so will the ciphertexts be too. However, I should note that CBC mode, if used without a MAC, has its own set of vulnerabilities such as padding oracle attacks.
May 6	comment	Is my HMAC secure if I have a complete series of HMAC'd prefix strings @fgrieu: I'd assume that the OP is using $\operatorname{HMAC}(m)$ as a shorthand for $\operatorname{HMAC-H}_K(m)$ for some fixed hash $\operatorname{H}$ and key $K$. It would at least seem to make sense in context.
May 6	comment	How do I demonstrate that a PRNG not designed for cryptography is not suitable for generating passwords? You're right, I should've made that cleared. I do suspect that they may indeed be using exactly that method, but they don't actually come out and say so.
May 4	comment	Is my HMAC secure if I have a complete series of HMAC'd prefix strings @yarek: You're absolutely correct. However, for HMAC specifically, one might be able to prove message confidentiality based on the security properties of the underlying hash function.
May 2	comment	Can I encrypt user input in a way I can't decrypt it for a certain period of time? It's possible (and actually quite easy) to use multi-level secret sharing to create one special share which is always needed to recover the secret. See my answer for more details.
May 1	comment	Software implementation of a commutative cipher? You could try to use truncated hashes, but unless the number of SSNs that need to be compared is quite small, it'll be hard (or impossible) to choose a hash length that is short enough not to be identifiable (especially if an attacker can narrow down the search space to a given geographical region) yet long enough not to yield too many false matches.
May 1	comment	Software implementation of a commutative cipher? I'll quote poncho's comment to a now deleted answer that suggested more or less the same: "The problem is using a hash that there are only $10^9 \approx 2^{30}$ possible SSNs -- what one side could do is just hash all possible SSNs, and then look up all the hashed SSNs that the other side gave." Using a different salt for each hash would help some, but not much; it slows the brute force breaking (and legitimate checking) of $n$ hashes by roughly a factor of $n$.
Apr 30	comment	A fair peer-based coin-flipping protocol? Yes, that's a possible optimization. More generally, if you do this with $n$ peers, only $n-1$ of them need to publish commitments.
Apr 30	comment	A fair peer-based coin-flipping protocol? It can reject it, yes, but nothing in the protocol as you wrote it says it should do so. Remember that computers (which are what you'd use to implement this protocol in practice) only do what you tell them to, not what you want them to. :)
Apr 30	comment	A fair peer-based coin-flipping protocol? possible duplicate of How to fairly select a random number for a game without trusting a third party?
Apr 24	comment	cipher text only attack - how to know when to stop when brute-force attack? This sounds a lot like crypto.stackexchange.com/questions/2394/…
Apr 23	comment	Existing dictionaries of popular words to help solve a random substitution cipher? @CodeInChaos: Nice find. The Wikipedia list is also a good example of the fact that the source material does make a difference in word frequencies. I'm pretty sure that, for example, in almost any other corpus "median" would not be the 122-nd most common English word (and, in particular, it would not outrank "average", which is 142-nd in the Wikipedia list).
Apr 17	comment	How can I do a brute force (ciphertext only) attack on an CBC-encrypted message? Sorry, I wrote "encrypted" when I meant "decrypted". Fixed.