349 reputation
19
bio website mattnordhoff.com
location
age
visits member for 10 months
seen 53 mins ago

Jul
7
awarded  Critic
Jul
7
awarded  Citizen Patrol
Jun
21
comment DH “prime size” security in OpenSSL
By the way, you don't need to generate your own parameters. You can use, for example, get_rfc3526_prime_2048 to load some standard ones.
Jun
16
comment AES VS PRNG+HASH+XOR
You've invented a slightly odd and complicated stream cipher. It would be simpler to use an actual stream cipher (e.g. ChaCha or AES-CTR ;-) instead of the undefined "PRNG" and remove the hashing. (I'm avoiding subject of authenticated encryption.)
Jun
13
comment Why does AES-GCM need MAC? (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256)
The hash function is also used to authenticate the handshake in the Finished message; see section 7.4.9.
May
31
comment Update to “Cryptographic Right Answers”
To clarify: AES-CTR authenticated with HMAC-SHA256 using Encrypt-then-MAC is still a Good Idea. (AEADs like AES-GCM or AES-OCB are also a Good Idea. As Percival wrote then, it was and still is complicated and debatable, and the field is still evolving. You have to be different kinds of careful in every case.) Unauthenticated AES-CTR -- or unauthenticated anything else -- is always an awful idea.
May
21
comment Simple way to extend AES to 256-bit block size
FYI, Rijndael was originally defined with multiple block sizes, including 256 bits; this was left out of the AES specification, as NIST was uninterested. I'm not sure these variants have received enough cryptanalysis, and I'm not implicitly endorsing this endeavor (or dis-endorsing it either).
May
11
comment Security of KDF1 and KDF2 (hash based KDF's)
@owlstead I don't get it, though. $c|K$ and $K|c$ would be equally vulnerable to a length extension attack as long as $OtherInfo$ comes last, wouldn't they? In other words, KDF3 is equally vulnerable, if that's the "possible security issue".
May
11
comment Security of KDF1 and KDF2 (hash based KDF's)
I should, perhaps, have mentioned the optional "OtherInfo" concatenated on, e.g. $H(x | y | OtherInfo)$.
May
11
comment Security of KDF1 and KDF2 (hash based KDF's)
Your "this page" says, nebulously, that $H(K | c)$ has "a possible security issue" fixed by using $H(c | K)$ instead. The former is used by ISO KDF1 and KDF2, the latter by KDF3 and NIST SP 800-56A. Does it matter?
Apr
23
comment Is it necessary to use single hash function for signature generation and HMAC?
@owlstead But they don't win hands down in my heart. :'(
Apr
23
awarded  Revival
Apr
19
comment Using Stream Cipher as CSPRNG
Where is the seed for your CSPRNG supposed to come from?
Apr
8
awarded  Nice Answer
Apr
6
comment Secure AES Key Generation via Salsa20?
I think taking a perfectly good cryptographic key, doing unspecified, weird and possibly insecure things to it with a cipher, and using that as a key for a second cipher is a bad idea. You have a cipher and a key. Don't complicate it. At best it's strange, and at worst something goes wrong and it's badly insecure.
Apr
6
comment Secure AES Key Generation via Salsa20?
/dev/urandom does produce cryptographically secure bytes. You can just read 16, 24 or 32 bytes and use them as an AES key. (The super-paranoid can use /dev/random if they prefer.) Salsa20 is a stream cipher that is currently considered secure. You could use it in a CSPRNG and maybe even a KDF, but you have no reason to further process your key here.
Mar
22
comment How does compression before encryption leak info about the input?
I think "it is much less difficult to gain information" should be "it is much more difficult to gain information"?
Mar
20
answered Is it necessary to use single hash function for signature generation and HMAC?
Mar
19
revised Why does Openssh use only SHA1 for signing and verifying of digital signatures?
Link references in the RFC quotes, just for fun. Also whitespace, just for fun.
Mar
19
revised Why does Openssh use only SHA1 for signing and verifying of digital signatures?
added 165 characters in body