12,328 reputation
11352
bio website vyznev.net
location Helsinki, Finland
age
visits member for 3 years, 3 months
seen Nov 20 at 10:54

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 started programming (in AmigaBASIC) when I was 10 years old. Nowadays, I'm most comfortable using Perl, C and JavaScript. I know Java and PHP too, but I can't really say I like them. I also know some Python, but not as much as I'd like.


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.


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:


May
24
comment Common password derivation function for different encryption methods
For some strange reason, if you ask PBKDF2 for more than one hash output block's worth of key material, it repeats the whole key-stretching process several times. This severely slows down the key derivation for legitimate users, whereas attackers typically don't suffer at all (since they only need to derive one output block to confirm their guess). PBKDF2+HKDF doesn't have that issue.
May
23
comment Which tamper-protection algorithm provides the shortest output?
... Hence, we just slapped a MAC onto any serialized data items, without any associated data; if users wanted to poke into the HTML code and replace one serialized string with another, that was fine with us, as long as we knew they couldn't pwn the server by feeding in some serialized code and telling the deserializer to overwrite a common library function with it.
May
23
comment Which tamper-protection algorithm provides the shortest output?
@D.W.: Also worth noting is that, sometimes, you might not care about replay attacks: for example, I once worked on an in-house web app framework that supported passing arbitrary serialized data structures as hidden variables. On the framework level, we did not care about replay or pick-and-mix attacks -- those, if they were an issue, would be checked for at the application level. But we did want to stop untrusted data from going into the deserialization library, since it wasn't designed with security in mind, and had "features" that allowed e.g. arbitrary code execution. ...
May
23
comment Which tamper-protection algorithm provides the shortest output?
... A convenient feature of SIV mode, in this regard, is that it can take a tuple of strings as associated data, rather than just a single string, so you don't have to worry about details like unambiguous encoding.
May
23
comment Which tamper-protection algorithm provides the shortest output?
@D.W.: Good point, although it really goes beyond algorithm choice, and into threat modelling. The general answer, with an AEAD algorithm, is to pass any extra (meta)data, which you want to tie the protected data to, into the algorithm as Associated Data. This might include e.g. a form ID, a timestamp, the user ID and any other hidden fields on the form. Note that all of those effectively become integrity-protected too: the authentication tag will only match if all of them are unchanged (although an attacker might still be able replace all of them, together, with an earlier set of values).
May
22
comment Common password derivation function for different encryption methods
+1. Also, if you might need more than 256 bits of key material, consider using PBKDF2+HKDF (i.e. use PBKDF2 to derive one hash output block's worth of bits, then feed that into the expansion stage of HKDF as the PRK input).
May
8
comment Decrypt a public encrypted message and Sign a signature, how the math is different?
@CodesInChaos: I think this could actually be a pretty good "FAQ" question, and your comment, with some embellishment (e.g. compare RSA signing with RSA encryption and DSA / ElGamal signing with ElGamal encryption), could make a good answer for it. I may try to write one later, unless someone else does it first.
May
5
comment Difference between a nonce and IV
Related, but less specific question: crypto.stackexchange.com/questions/3965/…
May
4
comment How do I produce a stream of secure random numbers from AES-Counter mode?
@owlstead: I'm not aware of any attacks for $E_K(K)$, but there's definitely an attack for, say, $E_K(D_K(0))$.
Apr
26
comment How secure would HMAC-SHA3 be?
@fgrieu: As far as I can tell, the argument is that Keccak provides this level of security when used with the generic sponge MAC construction (= prepend key to message; CSF §5.11.2), of which the inner HMAC pass can be seen as an instance. That security, in turn, is claimed to follow from the Keccak flat sponge claim (Keccak reference §1.5), which is a pretty strong claim that, loosely speaking, says that Keccak is as good as a random oracle against attacks using $\lll 2^{c/2}$ work.
Apr
25
comment Solving Vignere Encryption
@vignere_solve: OK, here's the hint: I was wrong about letter case. The correct cipher alphabet has 64 characters: AZ, az, 09, + and /. It just happens that, with this particular alphabet and key, most lowercase letters are encrypted to uppercase ones, and vice versa.
Apr
23
comment Solving Vignere Encryption
@vignere_solve: No problem. Ps. I did solve it, and it turns out that one of the early assumptions I made is wrong. However, you can still decode most of the text despite the wrong assumption, and, once you do, it's not hard to figure out what the mistake it. Let me know if you need a further hint.
Apr
15
comment Block cipher and parity of permutation
Generalizing your first example, if we start with any permutation, and extend the state space being permuted by at least one extra bit (which does not affect the permutation and is not affected by it), then the resulting extended permutation will be even.
Apr
1
comment What is h in this RSA variant?
Ugh... I looked at the paper to try and fix the broken math formatting in the question, but it turns out to be like that in the paper too. :-( Honestly, most of the paper looks a lot like SCIgen output anyway.
Mar
23
comment Certificate signature with SHA-1 and RSA: where do 1888 bits come from?
See also identical question on security.SE.
Mar
23
comment Choice of reduction polynomial in Whirlpool's internal cipher
Ps. See also this related question.
Mar
23
comment Is this approach to generating a “random” number from a sha512 hash effective?
The list of participants' names might not have enough entropy to prevent you from cheating even without help from others. In particular, if you can guess who might sign up for the raffle (and in what order), you could compile a bunch of likely participant lists in advance, and, after testing a large number of possible secret inputs against those lists, select the one that has the best chance of giving you a favorable outcome if the actual participant list happens to match one of your guesses.
Mar
13
comment I need a 64-bit cryptographic hash for 96 bits of data
+1. The birthday bound is a harsh mistress.
Feb
20
comment How to represent a 32-byte SHA2 hash in the shortest possible string?
For case-insensitive file systems, it's probably best to stick with base 32 or 36, which can be encoded using single-case letters and numbers. In particular, the distinct printable ASCII characters allowed in Windows file names are not quite enough to encode six bits per character: there are 9 reserved characters and 26 equivalent upper/lowercase pairs, leaving only 60 usable characters (including space, which you don't seem to count; also, some file systems may have additional reserved characters).
Feb
13
comment Can someone explain the ECB Penguin?
@JoshBond: The "pattern" arises because pixels and cipher blocks don't line up exactly: an uncompressed true-color pixel takes up three bytes, while most common block ciphers encrypt blocks of either 8 or 16 bytes (64 or 128 bits).