Reputation
3,891
Top tag
Next privilege 5,000 Rep.
Approve tag wiki edits
Badges
8 30
Newest
 Enlightened
Impact
~101k people reached

Oct
12
comment Encrypt hash using hash of hash?
Even Google doesn't bother with TLS offloading appliances any more, particularly since AESNI instructions in modern CPUs. If they don't need it, you don't either. A 24-7 operations team to avoid denial of service attacks is absolutely ludicrous, fantastical thinking. And the effort of keeping up-to-date with OpenSSL patches is no extra work if you're also keeping up-to-date with all of the other software on your server. It also pales in comparison to the effort of writing and maintaining your own custom authentication protocol.
Oct
9
comment Inverting One-Way Functions
An intelligent adversary would notice the trivial pattern after two or three tries. Brute force is what you use when you have no better cryptanalytic tool at your disposal.
Oct
9
comment Encrypt hash using hash of hash?
B(P) alone thwarts a dictionary attack on the database if B is a hash with a large work factor, and the introduction of these extra mechanisms does not improve upon the situation. TLS protects against eavesdroppers (your protocol does not — e.g., it fails trivially to an active man-in-the-middle). A bespoke authentication protocol (and as a consequence, a bespoke implementation) is far more likely to contain exploitable flaws than simply following standard best practices by encrypting data over the wire with TLS, and protecting passwords at rest with bcrypt or scrypt.
Oct
9
comment Encrypt hash using hash of hash?
It might be helpful if you explained how the client and server pre-establish K. That said, if an attacker knows P, the can trivially calculate K and B(P). If an attacker doesn't know P, what attack does this thwart?
Oct
9
comment Encrypt hash using hash of hash?
You're encrypting (C, B(P)) with K = H(B(P)), but you never send K to the server. If you send K to the server, an eavesdropper can decrypt (C, B(P)), so there's no point in encrypting it in the first place. Furthermore, combining standard primitives is no less prone to error than inventing your own wholesale.
Oct
9
comment Encrypt hash using hash of hash?
How does the server ever learn K = H(B(P))? Also, what are your goals? What is the standard approach for what you're trying to accomplish, how does it fall short of your security requirements, and how do you believe this scheme improves upon the situation?
Oct
7
comment Why do we require a CSPRNG's output to be indistinguishable from true random?
I said nothing even remotely resembling that.
Oct
7
comment Is there a correct way to generate a symmetric key?
TL;DR, symmetric keys for modern ciphers are nothing more than cryptographically random blobs of the appropriate length.
Oct
6
comment Is my protocol that uses hybrid cryptography and AES-GCM secure?
Also, it should be said that if you're implementing this as a toy project for the sake of learning, great! If you intend to ever use this in a real-world system, just use GPG.
Oct
6
comment Is my protocol that uses hybrid cryptography and AES-GCM secure?
In fact, typically the point of the AAD is to be provided implicitly as context rather than being something entirely attacker-controlled. Also, the filename being used as the nonce is extremely bad — nonces must never repeat, and if you ever reuse a filename or send the same file with a few modifications, the entire security of the system collapses.
Oct
6
comment Is it safe to initialize secret keys by just reading /dev/random on Linux?
The early boot entropy problem is entirely a non-issue outside of very special-case software. By the time your userspace service has started, there is already plenty of entropy in the kernel. And I'm rather swayed by the argument that userspace CSPRNGs have been a frequently-recurring source of failures in the real world: for example, Debian OpenSSH keys and repeated ECDSA keys in Android bitcoin wallets.
Oct
6
comment Why do we require a CSPRNG's output to be indistinguishable from true random?
A block cipher and random number generator have distinct and independent security requirements.
Oct
6
comment Is it safe to initialize secret keys by just reading /dev/random on Linux?
Additionally, it's worth mentioning that getrandom(2) is a better option, if available on the platform.
Oct
6
comment Is it safe to initialize secret keys by just reading /dev/random on Linux?
Why bother with a userspace CSPRNG and not simply read from /dev/urandom directly? One in userspace should be totally unnecessary.
Oct
6
comment Is it safe to initialize secret keys by just reading /dev/random on Linux?
It should give a \0 on average once every 256 bytes.
Oct
5
comment Why do we require a CSPRNG's output to be indistinguishable from true random?
Now you need to demonstrate that a) this is the only thing the attacker can possibly learn, and b) that this can't possibly lead to an exploitable weakness. See points 4 and 2, respectively, in CodesInChaos' answer.
Oct
5
comment Why do we require a CSPRNG's output to be indistinguishable from true random?
#2 is just as important, to me. Known shortcomings are obvious areas for analysts to attack, which they frequently do, and to devastating effect.
Oct
5
comment Why do we require a CSPRNG's output to be indistinguishable from true random?
"The only information the attacker can get from this is the cipher's block size, and this doesn't weaken the security one bit." [citation needed]
Oct
4
awarded  Yearling
Sep
21
comment If I know the hash function that produced a hash key, how easily can I generate an input to hash to the same key?
Also, your clarification about the difference between "any" and "particular" only confuses the issue more. You say by "any" you don't care what the string is, and then you say by "particular" that there may be several, but you don't care what the string is — both of those seem to be the exact same thing. Additionally, it's unclear what you mean by the word "convey".