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

Mar 7	comment	How does the energy consumption of the SHA-3 finalists compare? You can accept your own answer, although you'll need to wait some time before the software lets you do that. However, for the benefit of others who may also be interested, it would be very nice if you could also summarize your findings briefly in your answer, instead of just giving a link.
Feb 17	comment	How to attack a general polyalphabetic cipher? @Lunar: If you've got enough ciphertext, you can mostly guess each column of the tableau just by looking at single letter frequencies. The rest will then just be fine tuning.
Feb 17	comment	Why not use CTR with a randomized IV? Ps. If you're using random IVs with CTR mode, and you can use full length IVs, there's never any reason to use anything less. Sure, fixing the low-order bits of the counter prevents partial overlaps for short messages, but it's pretty easy to prove that the increased probability of full overlaps more than compensates for it.
Feb 17	comment	Why not use CTR with a randomized IV? However, note that generating truly unpredictable IVs is also easy to get wrong, and that predictable IVs open CBC up to some fairly serious attacks, like the BEAST attack on SSL/TLS. Alas, it seems there's still no such thing as the perfect fool-proof cipher mode.
Feb 10	comment	Does RSA padding have to be unpredictable if the payload is? The safe method Thomas Pornin describes in the answer you linked to is basically RSA-KEM, at least once you add the fairly obvious step of using the derived single-use key $h(x)$ only to encrypt a second symmetric key, which may then be safely used to encrypt data for multiple recipients.
Feb 10	comment	Best choice of finite field for AES on a 4-bit microcontroller? @ConradoPLG: 256 bytes is a lot. Admittedly, I've never tried writing code to compute Galois field inverses on a 4-bit processor, but I'd be very surprised if it took that much space.
Feb 3	comment	Does anyone know which encryption scheme produces the following output? Are those hash marks really part of the data? o_O Anyway, it's almost certainly some home-brew scheme, and, if that's really what the data looks like, probably not very hard to break at all. Can you give us a few (made up) passwords and the corresponding "encrypted" data?
Jan 16	comment	Key space size when either of two public keys are valid for authentication? You're right, I tried to deliberately keep my answer simple and assume the simplest and worst case. It's not really clear what the OP is talking about. He mentions SHA-256, public keys and user authentication; since users typically don't authenticate themselves with public keys, I suspect at least one of these is a mistake. I sort of assumed that the "public key" part was the red herring; you seem to have taken it at face value and answered accordingly. In any case, +1.
Jan 12	comment	Two mutually untrusted parties want to exchange data: how to ensure each one gets the data it needs? I don't think either of these questions should be deleted, but one of them (it doesn't really make much difference which) should be closed and the answers merged into the other one.
Jan 12	comment	Two mutually untrusted parties want to exchange data: how to ensure each one gets the data it needs? You mean 16 instead of 64, right? Of course, you could even go all the way down to individual bits, yielding at most a 2-fold advantage to the first quitter.
Jan 12	comment	Two mutually untrusted parties want to exchange data: how to ensure each one gets the data it needs? possible duplicate of Two untrusted party want to exchange data: how to ensure each one gets the data it needs?
Jan 1	comment	Obtaining the key length from the ciphertext of an auto-encipher Could you describe the cipher you're trying to analyze? I assume it's some variant of the autokey cipher, but it would help to know the details.
Dec 24	comment	How does one design a traffic analysis resistant protocol? (continued) About the best you can do is make that information as useless as you can, by making the server/network so widely used that just connecting to it tells little to anyone (which is really only tangentially related to crypto). Of course, you can also try to mask the message traffic as something else (as I believe e.g. TOR tries to look like HTTPS), but that's quite hard to do reliably.
Dec 24	comment	How does one design a traffic analysis resistant protocol? You're always going to leak some information about contact patterns. If you have a central server, an eavesdropper will know you connected to the server. If you have a distributed network, an eavesdropper will know you connected to the network.
Dec 23	comment	How does one design a traffic analysis resistant protocol? Yes, the trusted server is there as a simplification. If you don't trust anyone else, but do trust the people you're talking with, you could always have one of them act as the server (or even spread the load around in various ways). If you don't even wholly trust your conversation partners, things get tricky. However, in any case designing a robust and scalable distributed IM system is complicated enough even without throwing crypto into the mix.
Dec 16	comment	Creating a hash of XOR'd blocks I first thought it might've been supposed to be $h(m)=H(M_1)\oplus H(M_2)\oplus\dotsb\oplus H(M_\ell)$, where $H$ is a PRF, but that's not preimage resistant either. (You need to hash about as many random blocks as there are bits in the output and do some linear algebra to get first preimages, but that's a negligible amount of work.)
Dec 16	comment	How to choose a padding mode with AES All padding schemes leak some information about the length of the plaintext (unless all possible plaintexts are shorter than one padding block), None just leaks more of it. One should also beware padding oracle attacks; the best way to avoid them is to encrypt-then-MAC, but in any case it's a good idea not to try to verify the validity of padding.
Dec 15	comment	RSA: If n=35, show that e will equal d $\gcd(3,24) \ne 1$.
Dec 13	comment	Proof of security for RSA signatures Ps. This is exercise 12.2 from Introduction to modern cryptography (hopefully now with a link that actually shows the page).
Nov 24	comment	Is a book cipher provably secure? +1 for the 130 million figure. That's not really all that much; we're talking about the equivalent of a 27-bit keyspace.