Reputation
601
Top tag
Next privilege 1,000 Rep.
See votes, expandable usercard
Badges
3 14
Newest
 Necromancer
Impact
~27k people reached

Apr
29
comment Does Microsoft use Dual_EC_DRBG by default?
When one calls NTSTATUS ret = BCryptGenRandom(NULL, output, size, BCRYPT_USE_SYSTEM_PREFERRED_RNG), which RNG is used? BCRYPT_USE_SYSTEM_PREFERRED_RNG behavior is not well documented with respect to its interactions with BCRYPT_RNG_ALGORITHM and BCRYPT_RNG_DUAL_EC_ALGORITHM. (Or maybe more correctly, its ambiguous in the NIST security policy). I ask because I've seen others use it, like Wine.
Apr
21
comment Where are the ChaCha20 test vectors/examples?
@orlp - except its missing some macro definitions, like U32TO8_LITTLE ad U8TO32_LITTLE. I have not been able to find it in the ecrypt-sync.h header file or the various chacha.c files.
Mar
21
awarded  Necromancer
Jan
11
awarded  Popular Question
Jan
11
awarded  Nice Question
Dec
8
revised Implementation specific differences between RDRAND and RDSEED
Added reference to "Intel Digital Random Number Generator (DRNG) Software Implementation Guide"
Dec
8
comment Implementation specific differences between RDRAND and RDSEED
@CodesInChaos - yeah, I get what you are saying. It probably was not worth mentioning/asking because of the nature of statistics....
Nov
29
revised Implementation specific differences between RDRAND and RDSEED
added 202 characters in body
Nov
29
asked Implementation specific differences between RDRAND and RDSEED
Nov
21
comment Edwards / Montgomery ECC with Weierstrass Implementation?
Oh, cool. I was looking for this information. Also see Bernstein's SafeCurves: choosing safe curves for elliptic-curve cryptography
Nov
20
awarded  Yearling
Nov
3
revised Should Increment functions be near-constant time?
Improved flow.
Nov
3
revised Should Increment functions be near-constant time?
Added additional information.
Nov
3
comment Should Increment functions be near-constant time?
@Poncho - I'm going to hold off on accepting because I'm interested in a treatment when the counter or iv is considered secret. But I like your counter example. I was not aware it was a problem.
Nov
3
comment Should Increment functions be near-constant time?
Thanks Poncho. "the counter doesn't have to be updated in constant time (because it's not secret)" - but if a protocol declares it to be secret, then it is secret. Or am I missing something obvious?
Nov
3
comment Should Increment functions be near-constant time?
My open questions are closer to: (1) does the counter or iv survive long enough in a particular state for the attacker to learn something about it; and (2) if the attacker learns something, then what is the resulting risk? If the attacker learns something about the counter or iv, then a protocol like TLS has violated its security design.
Nov
3
comment Should Increment functions be near-constant time?
Thanks Maarteen. "... does not have to be near constant time as the counter does not have to be secret." - that's actually the pivot point. Under protocols like TLS, the counter or iv is secret. If you or I said it should be treated as public, then that's just bike sheding because they have already defined it as secret. That is, we are telling them how to run their project.
Nov
3
asked Should Increment functions be near-constant time?
Oct
24
revised AMD and RDRAND instruction
Fixed page number in reference. Added info on RDSEED.
Oct
17
revised AMD and RDRAND instruction
Added info on NIST modules.