13,720 reputation
11458
bio website vyznev.net
location Helsinki, Finland
age
visits member for 3 years, 7 months
seen 22 hours ago

I'm not really a cryptographer, I just play one on the Internet. ;-)

I'm a PhD student in biomathematics, working on stochastic individual-based models of evolution in spatially structured populations. My other interests include cryptography, programming games and puzzles, photography and graphic design.


I'm the main author and maintainer of the Stack Overflow Unofficial Patch (SOUP), a user script for browsers with GreaseMonkey-compatible user script support (Firefox, Chrome, Opera, possibly Safari) that fixes or works around a number of outstanding issues with the Stack Exchange user interface.

I tend to answer a lot more questions than I ask. Some answers I'm rather proud of:

CC-Zero 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.


Dec
28
comment Why shouldn't I use ECB encryption?
@giorgim: Even if you don't have any MAC or AE mode available, using CBC is still strictly better than ECB. If you do have a MAC function, CBC-then-MAC is a perfectly good AE mode.
Dec
28
comment Why shouldn't I use ECB encryption?
@giorgim: There's really no good reason to use ECB (except as a building block for other modes). Pretty much any crypto library provides at least CBC or CTR mode, and if not, they're trivial to implement yourself. Slap an HMAC (or CMAC) on top of that, and you're good to go.
Dec
28
comment What are the security implications of multiple hashing?
Ps. See also this related answer of mine. (I tried to look for it earlier, but couldn't find it here, because it turns out I actually posted it on SO.)
Dec
28
comment What are the security implications of multiple hashing?
@BobBrown: Right. Multiple hashing isn't (necessarily) bad. There are plenty of good and standard algorithms, like PBKDF2, that basically work by hashing the password multiple times. What's generally a bad idea is designing your own non-standard password hashing scheme, without any idea of what makes such as scheme secure.
Dec
23
comment Why shouldn't I use ECB encryption?
@D.W.: I think this is an excellent question for this site, because it asks a simple, common question in a way that invites good answers, makes a great resource to reference later, and is likely to show up well in searches. We've already got several questions that kind of skirt this topic, but this is the first one that just comes straight out and asks the literal question in the title. Not every question here has to be hard in order to be good.
Dec
22
comment Why shouldn't I use ECB encryption?
@supercat: That's basically disk encryption, so you could use modes designed for that. I believe XTS is considered a good choice, although, like all disk encryption modes, it has its limitations (which you should understand before using it). If possible, it should be combined with a MAC of some sort to defend against active attacks.
Dec
22
comment Why shouldn't I use ECB encryption?
Related: crypto.stackexchange.com/questions/225/…, crypto.stackexchange.com/questions/5405/…, crypto.stackexchange.com/questions/12529/…, crypto.stackexchange.com/questions/2963/…, crypto.stackexchange.com/questions/14487/…, etc.
Dec
19
comment What is the fixed point attribute of DES (when used with weak-keys)
@mikeazo: The DES weak keys have been discussed in this question, but I think what Bush is asking about the existence of fixed points for those weak keys, as discussed e.g. here and here.
Nov
17
comment Consequences of AES without any one of its operations
@poncho: That looks like an answer to me. Want to make it one?
Nov
16
comment CCA security of a system that splits messages and encrypts each packet
Is this homework? It appears to be phrased as such. If so, let me just give a hint: en.wikipedia.org/wiki/Malleability_%28cryptography%29
Nov
16
comment Why sorting is needed for Meet-in-the-middle attack
Small note: In practice, you probably wouldn't use a binary search, but rather you'd sort both sets and run a list merge on them. In any case, though, you still end up doing about $O(n \log n)$ comparisons; without sorting, that would be $O(n^2)$, which is no more efficient than brute force.
Nov
12
comment IPsec authentication and encryption lgorithms
As the Wikipedia page notes, actual IPsec implementations typically seem to be on the kernel level (for example, the Linux kernel includes one since v2.5), and so won't generally be portable per se. The underlying crypto algorithms, however, are, and can be found e.g. in the OpenSSL library, which should meet your specs (cross-platform support, written in C). Of course, OpenSSL is really a TLS/SSL library, so it contains a lot of other stuff besides the crypto primitives, too, but as long as you don't mind the extra cruft (which is all in a shared library, anyway), it might be a good choice.
Oct
10
comment Why is TLS SRP verifier based on user name?
@nefarel: Dunno. I might mutter something about Merkle-Damgård length extension attacks, or about provable reducibility to the PRF-ness of the SHA1 compression function, but honestly I have no real idea. It looks sort of like a clumsy imitation of HMAC, but since the folks who designed SRP are pretty smart cryptographers, presumably it's a clever imitation of HMAC, I just don't know exactly how or why. That might make an interesting question in itself.
Sep
25
comment Why are we advising PKI if we know that quantum computers will break them?
Practical quantum computing, like practical fusion power, has been "10-20 years in the future" for several decades already. Basically, in both cases, we thought we knew the theory, and that the rest would be just a simple matter of engineering. Alas, sometimes "mere engineering" turns out to be not so easy, after all.
Sep
14
comment Solution with high decryption cost and low encryption cost
You mean the comment you left on the question above? I don't see any obvious issues there; obviously with such a small keyspace, you'll want to use a large slowdown factor; say, at least around $s = 32$ (or more, if practical).
Sep
11
comment Isn't a simple Vernam cipher as secure as known symmetric key algorithms?
@Rox: See Kerckhoff's principle: a secure cryptosystem should remain secure even if the attacker knows exactly how it works (and, in particular, how you produced your key). Besides, if someone trying to crack your cipher didn't already know that you used a standard PRNG, now they do, because you posted about it here. Mind you, even if they didn't know, they might guess it anyway, since it's such a common amateur mistake.
Aug
28
comment Solution with high decryption cost and low encryption cost
Alas, this does not meet the 100,000+ messages/sec encryption requirement, at least not if the messages have different keys.
Aug
28
comment Good challenges for a crypto competition for teenagers
Sure you can do visual crypto without a computer. Just get some semitransparent graph paper and color in the squares. The resolution won't be too great, but you should be able to make some recognizable images.
Aug
28
comment Good challenges for a crypto competition for teenagers
Honestly, I think this could be a good subjective question, and I don't think the closing reason quoted by @e-sushi really applies (as the question is really asking for answers based on expertise, not for purely personal opinions). That said, the current bunch of answers isn't particularly inspiring. I really wish someone would come up with at least one really good, comprehensive answer to set the proper tone here.
Aug
9
comment Recover from compromised shares with Shamir Secret Sharing
+1. Of course, it's worth noting that the dealer still needs to be trusted; a malicious dealer could construct their polynomial with a non-zero constant term, thereby changing the secret (potentially to one of their choosing, if they can guess the original secret).