830 reputation
426
bio website en.wikipedia.org/wiki/…
location United Kingdom
age 27
visits member for 3 years, 4 months
seen Mar 20 at 10:34

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.


Oct
31
asked Cryptanalysis and weaknesses of SEED cipher
Sep
5
awarded  Popular Question
Jul
9
comment Selecting bijective functions for permutations
@CodesInChaos Surely those first operations aren't sufficient? I understand the s-box somewhat, though from my understanding it's a transposition of smaller chunks rather than the entire block.
Jul
9
asked Selecting bijective functions for permutations
Jul
4
accepted Is it worth applying a MAC on data in a HSM?
Jul
4
accepted Potential vulnerability in DH key selection - am I understanding this right?
Jun
6
awarded  Popular Question
May
2
comment Is it worth applying a MAC on data in a HSM?
I'd have gone for EAX mode or GCM immediately if possible, but I'm using a pre-written AES library that doesn't offer such modes, and I've already eaten up half of my program space with libraries without even implementing the storage or request processing code. Adding EAX or GCM would be tricky to get right, and there might not be space. I'll take your advice on the hash, though.
May
2
comment Is it worth applying a MAC on data in a HSM?
@RickyDemer I usually write it as AES(block, key)
May
1
comment Is it worth applying a MAC on data in a HSM?
Whoops, typo! Fixed. Am using a pre-written AES lib so I'd rather avoid code for custom modes.
May
1
revised Is it worth applying a MAC on data in a HSM?
edited body
May
1
comment Is it worth applying a MAC on data in a HSM?
@fgrieu Each "record on the HSM" is stored inside the HSM. I hadn't considered the power loss issue, but a solution would be to store each entry twice and alternate writes across the two by switching an entry's flag as an atomic operation. As per memory correctness, I generally don't see it being a problem, though I can see why a HMAC would work well for such a situation. Perhaps you should write an answer to reflect what you've said here - it seems like a cogent argument to use a MAC.
May
1
revised Is it worth applying a MAC on data in a HSM?
changed key generation method
May
1
comment Is it worth applying a MAC on data in a HSM?
I could easily switch to AES-128-ECB for deriving the key. Essentially I'd do $k_r = AES(k_s, k_m)$ where $k_s$ is the secondary key and $k_m$ is the master key in the firmware.
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.