Comment by createdapril24

I agree that each person/organization should look at the security properties of a system and assess their risk against what technology is appropriate. It's entirely reasonable that as a non-targeted person with low value secrets, many of the attacks here don't have ROI for a potential attacker and as a result are neither likely or impactful.

What's important is that other persons and organizations who may be targeted - that they choose what technology to use, knowing what kinds of attacks are possible. For example a human rights activist might very well be targeted by phishing attacks and choose not to store secrets by this method.

I am just trying to enumerate the properties so that persons/organizations can evaluate a match to their use case. I don't believe any system is perfect for all use cases and I don't hold any system to such a standard.

The GP comment about "easy to brute force" must be read in context with the remainder of the comment about "easy to brute force":

"Relies on human adherence to password best practices to maintain sufficient entropy. Learning from industry that this does not work in widespread adoption"

The GP's statement can be boiled down to: "users will choose poor passwords" (as in Password1!) because it has been shown time and again that "users will choose poor passwords" if left to their own devices to do so.

The 'easy to brute force' part then comes in as "for those users who choose poor passwords, this rig linked below will brute force their passwords pretty quickly":

https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27...

Note that the above performance page is a few years old, updating it for 8x of a newer Nvidia GPU should result in even more impressive performance numbers.

And in all fairness, any cryptography where a user chooses a poor password is then vulnerable to "easy to brute force" by a rig such as the one above. Not because the encryption algorithm is easy to brute force (usually it is not) but because the user picked a poor password, and that poor password itself is easy to brute force.

> The thing is... this won't happen. If I'm dealing with an attacker so sophisticated to pull this off, it's likely they have 1000 other vectors that are more effective and dangerous.

Don’t delude yourself. These phishing pages with mirrored login portals happen to podunk organizations all of the time.

If someone manages to get a link to your page and is interesting in the contents, duping it and sending a phishing link to the suspected password holder is a trivial spear phishing attack (with an annoyingly high success rate).

mprime1 feel free to use or alter any of the content you agree with to update the documentation for your project.

That's a good point, I wasn't very specific about this (trying to keep it concise). To be specific here, the con is that there isn't what the industry calls Cryptographic Agility. https://en.wikipedia.org/wiki/Cryptographic_agility.

It is not true this con applies to all cryptography (e.g. look at TLS). It has more to do with how cryptography is configured, parameters are negotiated and keys are managed, than with point-in-time choices about algorithms. The con here is that unlike other deployments of cryptography, this one doesn't have parameter negotiation and key management - and therefore doesn't have cryptographic agility.

Re: "I'd wager that... AES..." is a also a good point. Modern cryptography has shown to be robust for decades and past their deprecation point. However, as you said, it IS a wager. There have been catastrophic failures of cryptographic primitives in the past. The con of this system is you will need to make a wager and tie yourself to the fate - you can't mitigate the risk if the catastrophic event comes or appears to be coming to pass.

Please share this silver bullet pake with the rest of the class?

Argon2-HMAC-SHA512 more like it? Or something else?