2,212 reputation
423
bio website touset.org
location San Francisco, CA
age 30
visits member for 1 year, 9 months
seen 1 hour ago

Cyclist. Rubyist.


Apr
24
answered Using beginning of TLS ecnrypted data to reveal secret
Apr
22
comment Is less security required for a short stream cipher than for the AES enciphering of very long messages?
You might know it will be free of intentional backdoors. But you're trading that off for the overwhelming probability of multiple unintentional trivially-exploited catastrophic vulnerabilities.
Apr
21
revised Leaving authentication data blank less secure for AES GCM?
added 4 characters in body
Apr
21
answered Leaving authentication data blank less secure for AES GCM?
Apr
18
comment Using Stream Cipher as CSPRNG
Ah, great point. Thanks for the correction.
Apr
18
comment Using Stream Cipher as CSPRNG
Yes, there absolutely is. Cryptography is hard, and if you believe it's a simple exercise to write secure code to a public spec, you're in for a bad time. Established companies with huge security teams like Amazon, Google, and Facebook can get details wrong. The notion that a developer with no cryptographic background working solo will do a better job is laughable.
Apr
17
comment Using Stream Cipher as CSPRNG
Then you must use a real CSPRNG which is continuously reseeded like Fortuna. A stream cipher alone is not good enough, as it has a trivial distinguisher from a purely random stream: outputs won't repeat until the counter overflows. If you're running this on any *nix, use /dev/urandom. If on Windows, use CryptGenRandom. If on both platforms, use an if statement and pick whichever one is available. Your scenario is precisely the type where a poor technical decision like writing your own RNG can result in catastrophic financial consequences.
Apr
17
comment Using Stream Cipher as CSPRNG
I don't understand how "they... do not like exposed public APIs". Unless you're building a language and runtime environment from scratch, you're using public APIs. If you include any of the eStream portfolio, you're using public APIs.
Apr
17
comment Using Stream Cipher as CSPRNG
Why is it not sufficient to use the CSPRNG built into your operating system? /dev/urandom on any *nix, CryptGenRandom on Windows.
Apr
10
comment Leak-proof protocol: is such a thing possible?
Why can't a malicious implementation leak whatever it wants directly to the NSA? It could do something obvious like opening a network connection and sending them secret keys directly, or something more surreptitious like remembering the keys and waiting for an incoming connection with a specific fingerprint before leaking that data to the client over the normal encrypted protocol?
Apr
10
comment Leak-proof protocol: is such a thing possible?
If you assume one of the sides is malicious, what's to stop them from subverting your communication outside of the protocol? For instance, simply handing the session key over to the NSA.
Apr
9
comment IV = Filename XOR CipherKey?
Just use a random number as the IV. Store it alongside the ciphertext.
Apr
8
comment Secure AES Key Generation via Salsa20?
@e-sushi I wasn't quoting you. MattNordhoff mentioned using /dev/random if you're super-paranoid, and I was refuting that. Even your characterization that /dev/urandom "falls back to" a PRNG when it runs out of entropy isn't correct, though. They're both using a CSPRNG (I argue, the same one) all the time; if you check the algorithms in the paper carefully, the only functional difference when entropy is low is that /dev/urandom skips re-mixing entropy back into other entropy pools. The random number returned is $F \circ H \circ M(S , H(S))$ in both cases, for some internal seed $S$.
Apr
8
comment Secure AES Key Generation via Salsa20?
@e-sushi Nope. It's the same CSPRNG on Linux for both. The only difference is that /dev/random blocks when the entropy pool is "exhausted" (which itself is a meaningless concept, given that it's just a PRG), and /dev/urandom doesn't.
Apr
7
comment Secure AES Key Generation via Salsa20?
@MattNordhoff /dev/random is not "more secure" than /dev/urandom. They use the same CSPRNG as each other on all modern UNIXes.
Apr
5
comment encrypting data signals using the time variations between two independent coupling functions
I followed the links from Gizmodo and thought it was just the abstract. I didn't notice there was a link to actually download it from there!
Apr
5
comment Wrong Test Vector for HKDF with HMAC-SHA256
@RichieFrame I already tested it with two existing HKDF implementations. The test vector is correct.
Apr
4
comment Wrong Test Vector for HKDF with HMAC-SHA256
Comparing the results against any other implementation of HKDF would trivially confirm for you that it is your implementation that is buggy, and not the test vector. Put succinctly, if you hear hoof prints, think horses — not zebras.
Apr
4
answered encrypting data signals using the time variations between two independent coupling functions
Apr
3
comment A specific way for deniable encryption
What about the "trivial" solution, which is to use a stream cipher where the full keystream $\left|k\right| = \left|m\right|$ is used, and $c = k \oplus m$? You can then compute an alternate keystream $k'$ for any other text $m'$ of equal length by $k' = c \oplus m'$.