11,808 reputation
11149
bio website vyznev.net
location Helsinki, Finland
age
visits member for 3 years
seen Aug 30 at 14:00

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:


Aug
29
comment The security of an encrypt-and-MAC
It's not necessarily that impractical: you can derive the unique encryption and MAC keys from a master key and some nonce (e.g. a message number) using a KDF. Sure, changing the key for each message is probably slightly slower than using the same key for all of them, but then, if you're using HMAC you're presumably not aiming to squeeze every last bit of performance from your hardware anyway. (If you are, consider using a universal hashing based MAC instead.)
Aug
27
comment RC4 system pitfalls
Your description seems to be missing some possibly relevant details. For instance, what key is used for the HMAC? Is the HMAC output also encrypted, and if so, how? And how are the segment lengths transmitted?
Aug
26
comment The specification of modern, non-communicating cipher machinery
I agree with @owlstead, and have voted to close this question as essentially unanswerable. There might be a meaningful and practical question hidden behind it, but if you want it answered, you'll have to be more explicit about what it is. As currently written, I'm fairly sure the only kind of literature such questions have been considered in is science fiction and fantasy. (And for that, we have another Stack Exchange site.)
Aug
26
comment Lagrange Interpolation for finite field GF(2^8), for Secret Reconstruction
Is the result you're getting actually 104, not 14? Because that's what you should be getting if you calculate 17 × 3 + 34 × 3 + 61 in GF(2^8). The reason you're not getting 10 is that the points (1,17), (2,34) and (3,61) do not satisfy y = 5x² + 2x + 10 in GF(2^8). To make the reconstruction work in GF(2^8), you need to calculate the shares in that field too; see poncho's second answer for details.
Aug
26
comment Lagrange Interpolation for finite field GF(2^8), for Secret Reconstruction
If you're using operator overloading to implement Galois field arithmetic, remember that you need to overload addition and subtraction too. And don't forget to overload the non-assignment versions of the operators, either.
Aug
25
comment Generating an IV for ESP 3DES-CBC
@JuanAndrés: For details on the "fixed IV trick", see crypto.stackexchange.com/questions/5421/…. Basically, it's just a clever way to perform both the NIST-recommended IV derivation and the actual CBC encryption using a single call to a CBC encryption function.
Aug
23
comment Is it theoretically possible to construct a string that contain its own hash value?
@Mys_721tx: If you have a practical chosen-prefix preimage attack on the hash, then you can use it to find such a string: just choose a prefix equal to the desired hash value. I'm not familiar with the attacks on MD4, but most attacks on Merkle-Damgård style hashes do tend to allow chosen prefixes. That said, AFAIK the best known preimage attacks on MD4 aren't really that practical yet: the Laurent attack still needs about $2^{102}$ compression function computations to find a full preimage.
Aug
22
comment Is it theoretically possible to construct a string that contain its own hash value?
@RickyDemer: Thanks, fixed.
Aug
22
comment How resilient to attackers with extreme resources available is this encryption method?
I believe the reason why the answers you're getting are so all over the place is that you haven't defined the scenario fully. In particular, are you trying to implement a secure communication channel or secure file storage? If the latter, what exactly is the authentication part used for; who's authenticating what to whom, and for what purpose? What kind of resources do the legitimate users and/or servers have? Can your users securely store random encryption keys? Can they store random 256-bit keys at all, even insecurely?
Aug
22
comment Multiple parties must encrypt and get the same result
Are the hashes (and the 8 digits stored in plain) public information, or can you keep them hidden on your own servers and only allow on-line existence queries? That would significantly affect the options you'll have.
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.