13,071 reputation
11455
bio website vyznev.net
location Helsinki, Finland
age
visits member for 3 years, 5 months
seen Jan 21 at 12:14

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.


Aug
21
comment Strength of CBC with Ciphertext Stealing
@D.W.: Good point, I forgot to address that part of the question. That said, even plain CBC still leaks most of the length of the plaintext, it just rounds it up to the nearest cipher block size (i.e. typically 8 or 16 bytes). If you're in a situation where leaking the plaintext length matters, you should pad your messages yourself to a sufficiently long fixed length, rather than relying on the limited and incidental padding provided by CBC mode.
Aug
19
comment Am I insecurely implementing AES in Python?
+1 for "an insecure scheme looks just like a secure scheme".
Aug
12
comment Pre-image resistant but not 2nd pre-image resistant?
@HenrickHellström: Usually, hash functions are assumed to be maps from $\{0,1\}^*$ to $\{0,1\}^n$ for some fixed $n$. No such map is a bijection. But yes, if we're allowed to narrow down the domain or expand the range of our hash function enough to make it bijective (or at least injective), it's easy to make even trivially weak hash functions 2nd preimage resistant. In particular, the identity function is clearly 2nd preimage and collision resistant, but finding first preimages is trivial.
Aug
9
comment How to supply the GCM authentication tag to the OpenSSL command line tools?
The auth_tag parameter actually has nothing to do with associated data; that's what the (confusingly similar-named) auth_data parameter is for.
Aug
9
comment Does impersonating an SRP server give you enough information for an off-line dictionary attack?
Ps. This question is related, but asks about an attack scenario where the attacker knows the verifier $v$, e.g. because they've compromised a legitimate server. My question is about the case where the attacker does not know $v$, but can otherwise impersonate a legit server to the client.
Aug
9
comment Alice's forgetful banking
@CodesInChaos: I think I see what you mean now: the client's proof of knowing the password is a value that depends only on the password and on values known by the (fake) server, so once the server has it they can run a dictionary attack on it. What's confusing me is that there's a section in the 1998 SRP paper that seems to say that including $v$ in the calculation of $B$ somehow averts this attack (although I don't really see how, since the fake server can just pick a random $B$). It's confusing me enough that I asked a separate question about it.
Aug
9
comment Alice's forgetful banking
@Nick: I gave some reasons in this answer, but the real problem in your scenario is that, with a combined account identifier/authenticator, you have no way of referring to the account without also disclosing the information needed to access it. (As for your second question, I'd say the optimal choice would be to use $M$ bits for identification and $N-M$ bits for authentication, where $M$ is the minimum number of bits needed to uniquely identify the user.)
Aug
9
comment Alice's forgetful banking
@CodesInChaos: Wait, how does that work? Maybe I'm missing something simple, but I can't see any obvious way for a fake server to obtain the user's verifier from an SRP authentication attempt. Explain? (Anyway, a good way to mitigate such issues in practice is to use a key stretching KDF such as PBKDF2 to hash the password. That's a useful precaution anyway, in case a legitimate server gets compromised. The iteration count should generally be chosen so that the hashing process takes about 0.1 to 1 seconds on a typical client.)
Aug
9
comment Any problems with this secure time synchronization scheme?
@nightcracker: Our very first meta question was about literature recommendations (but see also this later question). Generally, I'd say the SE network frowns on 1) vague subjective questions with many equally valid answers and 2) answers that only link to external resources. Asking "What's a good book about X?" tends to fall into both categories, whereas "Is there any way to do X?" doesn't.
Aug
8
comment Securing content and login with “same” password
@user12889: If you don't want to allow username sniffing, you could always serve a dummy salt (such as an HMAC of the username using a fixed key) for any unknown usernames. Just try to avoid timing attacks (e.g. by always doing both a DB lookup for the salt and the HMAC calculation for any username before deciding which one to send). That said, generally one ought to assume usernames to be public information anyway; protecting them against guessing may slow down some attacks, but you shouldn't rely on it for any real security. That also means it's OK to leak them if you need to.
Aug
7
comment Securing content and login with “same” password
@D.W.: Agreed, the second scheme is better, if it's feasible. However, then you're no longer really implementing an encrypted file storage server, but simply a generic file storage server with secure password authentication.
Jul
25
comment Clipper chip (SKIPJACK) key exchange protocol
FWIW, the Wikipedia page no longer includes that remark. It was apparently added in this edit back in 2007, and removed in this recent edit, which also added a citation to the NIST publication you link to.
Jul
18
comment using random encrypted RSA challenge as key material
The output of HKDF-Expand is uniquely determined by its parameters (PRK, info, length). Thus, if you want to derive multiple independent keys from the same PRK using HKDF, you need to either 1) use a different info parameter for each, or 2) generate them all with one call to HKDF-Expand and split the output. Generally, just appending a counter to the info string will work fine. (Ps. See also my edit to the answer.)
Jul
18
comment Secret sharing scheme with possibility to change the secret
If the encryption method used is secure, it should not be vulnerable to known-plaintext attacks.
Jul
1
comment Designing a protocol to record attendance to lectures
The teacher can see the students in the classroom when he's teaching, right? So he cannot gain any information by looking at the pictures that he couldn't gain equally well just by looking at the students himself (and having a good memory for faces). And you implied that was acceptable above.
Jul
1
comment Designing a protocol to record attendance to lectures
On a disk? Or a USB stick, if you prefer. Why is that a problem, anyway? Disk space is cheap nowadays. Or is there some hidden requirement here? In any case, I don't think most modern face recognition programs actually store images of the faces (unless told to do so e.g. for review purposes), but only relatively compact abstract representations of the facial features of the subject.
Jul
1
comment Why is “mod(n)” so central to most aspects of cryptography?
@mikeazo: Definitely at least related. I'm still on the fence about the duplication; they are essentially the same question, modulo (pun not intended) the mention of XOR, but asked in rather different ways. In particular, merging the answers wouldn't really work in either direction.
Jul
1
comment Designing a protocol to record attendance to lectures
OK, so how about just having the teacher make up nicknames for each student, then, and verifying visually which students are present in each class. Or, if there are too many students for that, mount a camera in the classroom and use facial recognition software to track which students are present, assigning an arbitrary random ID to each face. At the end of the semester, each student shows up with photo ID to link their real name (or official student ID) to their face. Seems kind of silly, but also seems to satisfy your requirements (and a face is a lot harder to forge than a signature).
Jun
30
comment Designing a protocol to record attendance to lectures
How are you going to keep the teacher from just looking at the students to see who's present?
Jun
26
comment How can I do a brute force (ciphertext only) attack on an CBC-encrypted message?
@MaxiWheat: Yes, that's true. If the actual plaintext is indistinguishable from a random sequence of bits, then there's no way to tell it apart from any incorrect decryptions. In particular, the raw output of many ciphers does look effectively indistinguishable from random (unless one knows the key). However, that's not always the case: for example, a CTR mode ciphertext might start with a non-random nonce, or a CBC mode ciphertext might end with non-random padding, etc. It really depends on the details of the mode, cipher, etc. used to produce the inner ciphertext.