| bio | website | vyznev.net |
|---|---|---|
| location | Helsinki, Finland | |
| age | ||
| visits | member for | 1 year, 9 months |
| seen | 11 hours ago | |
| stats | profile views | 90 |
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.
|
Sep 22 |
comment |
Why is there a strong distinction between stream and block ciphers? Would you guys mind taking this discussion to chat? |
|
Sep 22 |
comment |
Why is there a strong distinction between stream and block ciphers? In an effort to keep this question from being closed, I've edited it to remove the argumentative last paragraph, leaving only the actual question. Further improvements are welcome. |
|
Sep 22 |
comment |
Why is there a strong distinction between stream and block ciphers? The last paragraph makes this seem more like an argument than a question. Please note that you should only ask practical, answerable questions based on actual problems that you face here. If you don't want to risk your question being closed or downvoted, I'd strongly suggest rewriting it to be more of an actual question (perhaps just deleting the last paragraph outright). |
|
Sep 21 |
comment |
Is it considered insecure in an HOTP implementation to publicly provide the next counter? @Devin: I amended my answer to suggest using a timestamp as the counter to avoid storing individual counter values for each client. |
|
Sep 19 |
comment |
Shortcuts / practicality of brute forcing block cipher (AES) + ECB with known plaintext @CodesInChaos: I'm not that familiar with padding oracle attacks, but AAUI, at least the original attack by Vaudenay relies on the fact that CBC decryption XORs the block cipher decryption of the last block with the previous ciphertext block. With ECB, that doesn't happen. (It does seem to me that a similar attack should be possible with padded CFB mode, just with the blocks reversed. Of course, CFB mode doesn't really need padding anyway, as the last block can simply be truncated.) |
|
Sep 17 |
comment |
Encryption scheme with equivalent keys? I was curious about how the DUKPT key derivation process actually worked, and found this presentation from AsiaCrypt 2010 on Google. (It's actually about an optimized variant, but they describe the standard version too.) The interesting feature, not really mentioned in this answer, is that the derived keys effectively form a tree hierarchy, so that the $n$-th transaction key can be derived from the BDK using only $O(\log n)$ derivation steps. |
|
Sep 7 |
comment |
Stretching passwords for encrypting small files Ps. While encrypting a random key with the password-derived key indeed doesn't provide a security benefit, it can be convenient if you ever want to change the password (or allow the file to be decrypted with more than one password or other key). |
|
Sep 7 |
comment |
Stretching passwords for encrypting small files +1 In fact, deriving encryption keys from passwords is the primary purpose of PBKDF2 and its ilk; the name stands for Password Based Key Derivation Function, version 2. The fact that they can also be used for user authentication is just a side benefit. |
|
Aug 30 |
comment |
Do I have to have a different salt for each password? That's also OK. You can toss the username into PBKDF2 along with the password if you like, it'll just act as a sort of an extra ad hoc salt (but you should still use a proper random per-user salt too, because usernames can be predictable). The point of having the username part there is that, because it's not meant to be secret, you can store it in plain in the database and use it to look up the correct record to test the password against. |
|
Aug 30 |
comment |
Do I have to have a different salt for each password? Sure, that's fine — it doesn't matter how they enter the name and password, as long as the backend code gets some kind of user/role identifier that's not also doing double duty as a secret authentication code. Having two separate input boxes/lines/prompts/whatever for the username and password is just a common user interface convention. |
|
Aug 17 |
comment |
Can I use PBKDF2 for authentication and decryption? @fgrieu: That works, but is needlessly slow if the total amount of key material to be generated is more than the output length of the KDF used to instantiate PBKDF2. (Of course, if an attacker also needs to generate the same amount of key material to test each password guess, then the slowdown applies to them too, but that's not the case in the OP's scenario.) |
|
Aug 17 |
comment |
How do I store encrypted files on a web server and decrypt them locally? Two disadvantages that I can think of are that a) the PBKDF2 output doesn't depend on the file key, so the server can tell which files are encrypted with the same password, and b) using PBKDF2 to generate more than one hash output length of data requires essentially running the whole iterated hashing twice or more; time which could be better spent by doubling the iteration count. (Also, don't let the modulo arithmetic scare you: all you need to do is take any byte/word/whatever in the key and increment it. Or change the key in any other way that, preferably, isn't its own inverse like XOR is.) |
|
Aug 16 |
comment |
How do I store encrypted files on a web server and decrypt them locally? Ps. I made a small tweak to the suggested protocol, replacing XOR with modular addition, so that the server can't send the client a bogus but valid-looking file key simply by swapping $C_K$ and $C_K'$. I don't think there's any way the server could've actually exploited that for anything other than wasting its own and the client's time, but it was easy enough to fix anyway. |
|
Aug 16 |
comment |
How do I store encrypted files on a web server and decrypt them locally? Well, it doesn't really matter if it's the same or a different client that uploads and downloads the files; after the encrypted file, $C_K$ and $C_K'$ have been sent to the server, the client can safely forget everything but the password $P$. |
|
Aug 15 |
comment |
Using chi square for distinguishing between compressed and random data Wikipedia has a pretty good description of Pearson's chi-squared test. The challenge, really, is coming up with a suitable null hypothesis to test; for example, even very poor pseudorandom streams will usually satisfy the simple hypothesis that the frequencies of individual bytes are uniformly distributed, no matter what test you use. |
|
Aug 15 |
comment |
Making My Own SSTP VPN This might be better suited for security.SE than crypto.SE. |
|
Aug 14 |
comment |
PBKDF2 and salt Actually, while PBKDF2 can be used for simple password hashing (and is actually quite good for it), what it's actually designed for is deriving encryption keys from passwords. That's what the acronym "PBKDF2" stands for: "Password-Based Key Derivation Function, version 2". |
|
Aug 14 |
comment |
What is the actual difference between security through obscurity and true encryption? @mikeazo: Thanks, nice links! However, when linking to the arXiv, it's usually more convenient to link to the abstract page (arxiv.org/abs/1109.5542), and to drop the version number ("v1") if you don't specifically want to link to a particular version of the paper. |
|
Aug 7 |
comment |
Why is 2 the inverse of 10? While there are indeed many ways to find the inverse, the most common method is probably the extended Euclidean algorithm. |
|
Aug 3 |
comment |
Which of these 3 AES 128 symmetric encrypt/decrypt routines is most secure? OK, we now have answers recommending each of the three options. Let the voting begin! :) |