808 reputation
224
bio website en.wikipedia.org/wiki/…
location United Kingdom
age 26
visits member for 2 years, 11 months
seen Oct 20 at 16:03

Pentester, ex-developer, security researcher, reverse engineer, electronics tinkerer, internet activist, zombie eradicator, promulgator of useless facts, shrubbery inspector, bacon aficionado.

Strengths: Security, Crypto, Win32 API, C#, .NET, PHP, x86 assembly

All answers and comments are encrypted with ROT256-ECB.

Opinions are my own. Advice provided with no warranty.


May
1
comment Is it worth applying a MAC on data in a HSM?
Simplicity. I couldn't think of a scenario where the xor would be problematic. Could you provide details on a practical related-key attack for this setup?
May
1
comment Is it worth applying a MAC on data in a HSM?
@RickyDemer The server sends the secondary key to the HSM device when a request is needed, where it computes the record key. Since the key will be in RAM, and that's inside the uC chip, it cannot be retrieved feasibly in an on-site environment. Tampering with the HSM code would also be immediately detected, because re-flashing it would mean an outage.
May
1
comment Is it worth applying a MAC on data in a HSM?
@RickyDemer Per record, yes. Does that sound odd to you?
May
1
comment Is it worth applying a MAC on data in a HSM?
Mainly. Ultimately I'll be using it in a site that isn't security critical - just a game. The HSM will be handling password reset questions and "select 3 letters from your secret word" type authentication, as additional defense against remote attackers.
Apr
30
asked Is it worth applying a MAC on data in a HSM?
Mar
27
comment Potential vulnerability in DH key selection - am I understanding this right?
@Thomas One would think so, but it's a surprising pain in the ass to attack in any practical way unless you have a decent number of samples. Every implementation after Java 1.4.2 uses a 48-bit seed based on the current microsecond-resolution timestamp and some difficult-to-predict system statistics. It's absolutely possible, given various prerequisites, but therein lies the catch.
Mar
27
comment Potential vulnerability in DH key selection - am I understanding this right?
Figured as much. In this case I'm trying to break the system rather than fix it (that's someone else's job!) so I guess this definitely counts as a vulnerability.
Mar
27
asked Potential vulnerability in DH key selection - am I understanding this right?
Mar
26
comment Is it feasible to break Diffie-Hellman key exchange when the implementation uses a poor-quality PRNG?
Correction: the seed was the system time in milliseconds on Java 1.4.2 and earlier.
Mar
26
comment Is it feasible to break Diffie-Hellman key exchange when the implementation uses a poor-quality PRNG?
@HenrickHellström According to the docs, it looks like the setSeed method (as called by the constructor) uses all 48 bits. However, the default seed in pre-Java7 is simply the current time as a millisecond-resolution value.
Mar
26
accepted What cipher mode is suitable for independantly decryptable short messages?
Mar
26
accepted Simple homomorphic crypto for 32-bit integers
Mar
26
asked Is it feasible to break Diffie-Hellman key exchange when the implementation uses a poor-quality PRNG?
Jan
19
accepted Is it possible to break a hash-based block cipher?
Jan
10
comment Is it possible to break a hash-based block cipher?
@SamuelNeves Perhaps my nomenclature is off a little. However, wouldn't introduction of a CBC-like mode of operation preclude it being a stream cipher? Granted it's not strictly in either category. Regardless, the question stands as-is.
Jan
10
comment Is it possible to break a hash-based block cipher?
@Thomas Hence my choice of CBC.
Jan
10
asked Is it possible to break a hash-based block cipher?
Jan
6
asked Simple homomorphic crypto for 32-bit integers
Dec
20
comment Why is it important that phi(n) is kept a secret, in RSA?
This is excellent. Very well done.
Nov
29
comment What cipher mode is suitable for independantly decryptable short messages?
@IlmariKaronen Ah, that makes sense. I was erroneously considering each packet as a block.