329 reputation
16
bio website mattnordhoff.com
location
age
visits member for 7 months
seen 4 hours ago

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
Mar
19
answered Why does Openssh use only SHA1 for signing and verifying of digital signatures?
Mar
19
comment Why does Openssh use only SHA1 for signing and verifying of digital signatures?
I don't know SSH well, but I'd bet that Paŭlo Ebermann's first comment is right. Notice that it also uses SHA-1 for RSA, but it uses SHA-2 for ECDSA, with a comment pointing to the RFC that mandates it. (See ssh_ecdsa_sign in ssh-ecdsa.c and key_ec_nid_to_hash_alg in key.c.)
Mar
11
comment I need a 64-bit cryptographic hash for 96 bits of data
Sounds like this might be a case for a non-cryptographic, hash table-type hash, e.g. SipHash (which is actually more cryptographically-inclined than most). They're a bazillion times faster, mostly resist accidental collisions (but not malicious attacks), and it's not like you can get real security out of 64 bits anyway.
Mar
3
comment NTRU crypto from unseen.is; myth busting help
Re "I thought extremely strong = widely used/available?", it's not that simple. If something is patented, or slow, or hasn't received a lot of analysis, or isn't significantly better than current practice, it might not be popular, even if it's good.
Mar
1
awarded  Enthusiast
Feb
22
awarded  Commentator
Feb
19
awarded  Custodian
Feb
19
reviewed Edit suggested edit on Can we ensure the security of a crypto-algorithm and -implementaton against acoustic cryptanalysis?
Feb
19
revised Can we ensure the security of a crypto-algorithm and -implementaton against acoustic cryptanalysis?
Gave link the related title text.
Feb
18
comment Is it necessary to use single hash function for signature generation and HMAC?
@e-sushi The other day I posted a really short answer, and got both down- and up-voted. Here I didn't say much about the SSH protocol (since I don't know it) or give more concrete performance details, so I chickened out. Also it had been shorter in my head...
Feb
18
comment Is it necessary to use single hash function for signature generation and HMAC?
SSH supports two AEAD cipher suites that don't use HMAC, AES-GCM and ChaCha20-Poly1305. (Or at least recent OpenSSH releases support them.) ChaCha20-Poly1305 in particular is intended to be easy to implement and very fast in software. I question whether you should be especially concerned about SSH or HMAC-SHA256 performance, though. I suspect you would have to be transferring a lot of data on a really bad CPU for it to be a problem. I also note that implementations of everything you want should already exist. Edit: OpenSSH typically uses HMAC-MD5 by default, by the way.
Feb
6
comment Do both client and server need to implement OpenSSL protections to protect from CBC attacks
During the BEAST excitement in 2011, it was discovered that some broken SSL implementations cannot handle empty records, so modern implementations no longer use that mitigaton. Instead, they use "1/n-1 record splitting", where they first send a one-byte record, and then a second record with the rest of the data. (Some broken implementations were incompatible with this, too, but you can't have everything.)
Feb
1
comment How do institutions like banks do RSA with big primes?
@fgrieu Sounds pretty close. I get 1.5 ms (660 signs/s) on my 32-bit, four-year-old Xeon, Xen VPS with openssl speed rsa (single-threaded). (13,100 verifies/s, or... 0.076 ms.)