meta user
network profile
| bio | website | vyznev.net |
|---|---|---|
| location | Helsinki, Finland | |
| age | ||
| visits | member for | 1 year, 9 months |
| seen | May 12 at 7:27 | |
| 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.
|
May 12 |
comment |
Does NTRU decrypt correctly now? I edited your answer to have nicer math and quote formatting; could you please check that I didn't break anything? (Ps. I looked at the P1363.1 draft and the Hirschhorn et al. paper, but I have to say I couldn't really figure out how they managed to get those specific formulas out of that paper. Maybe someone more familiar with it can clarify?) |
|
May 12 |
revised |
Does NTRU decrypt correctly now? nicer quote and math formatting, links, add reference to Hirschhorn et al. |
|
May 10 |
reviewed | Approve suggested edit on Are there any MGF1 and OS2IP functions available in C? |
|
May 9 |
revised |
Encryption with “constant” initialization vector considered harmful fix typo |
|
May 9 |
comment |
Encryption with “constant” initialization vector considered harmful @mtraut: I've corrected my answer somewhat to note that CBC mode is not quite as vulnerable to IV reuse as other common modes; in particular, in the specific scenario you describe, the only leak I can think of is that if the key, IV and plaintext are all identical, then so will the ciphertexts be too. However, I should note that CBC mode, if used without a MAC, has its own set of vulnerabilities such as padding oracle attacks. |
|
May 9 |
revised |
Encryption with “constant” initialization vector considered harmful correction per comments |
|
May 9 |
answered | Encryption with “constant” initialization vector considered harmful |
|
May 8 |
answered | Complexity of ECB and OFB |
|
May 7 |
revised |
Order of hashing concatenation fix typo in title |
|
May 6 |
comment |
Is my HMAC secure if I have a complete series of HMAC'd prefix strings @fgrieu: I'd assume that the OP is using $\operatorname{HMAC}(m)$ as a shorthand for $\operatorname{HMAC-H}_K(m)$ for some fixed hash $\operatorname{H}$ and key $K$. It would at least seem to make sense in context. |
|
May 6 |
comment |
How do I demonstrate that a PRNG not designed for cryptography is not suitable for generating passwords? You're right, I should've made that cleared. I do suspect that they may indeed be using exactly that method, but they don't actually come out and say so. |
|
May 6 |
revised |
Is it possible take a piece of data in secret? fix typo in title, retag, put example scenario in a quote box, add commas |
|
May 5 |
answered | How do I demonstrate that a PRNG not designed for cryptography is not suitable for generating passwords? |
|
May 4 |
comment |
Is my HMAC secure if I have a complete series of HMAC'd prefix strings @yarek: You're absolutely correct. However, for HMAC specifically, one might be able to prove message confidentiality based on the security properties of the underlying hash function. |
|
May 3 |
awarded | Enthusiast |
|
May 2 |
comment |
Can I encrypt user input in a way I can't decrypt it for a certain period of time? It's possible (and actually quite easy) to use multi-level secret sharing to create one special share which is always needed to recover the secret. See my answer for more details. |
|
May 2 |
answered | Can I encrypt user input in a way I can't decrypt it for a certain period of time? |
|
May 1 |
comment |
Software implementation of a commutative cipher? You could try to use truncated hashes, but unless the number of SSNs that need to be compared is quite small, it'll be hard (or impossible) to choose a hash length that is short enough not to be identifiable (especially if an attacker can narrow down the search space to a given geographical region) yet long enough not to yield too many false matches. |
|
May 1 |
comment |
Software implementation of a commutative cipher? I'll quote poncho's comment to a now deleted answer that suggested more or less the same: "The problem is using a hash that there are only $10^9 \approx 2^{30}$ possible SSNs -- what one side could do is just hash all possible SSNs, and then look up all the hashed SSNs that the other side gave." Using a different salt for each hash would help some, but not much; it slows the brute force breaking (and legitimate checking) of $n$ hashes by roughly a factor of $n$. |
|
Apr 30 |
revised |
Any techniques for evading frequency based crypt analysis without encrypting? add direct link |
