[dmix]

I currently use Pass and two things I prefer with it over Steel are:

- Steel uses a SQLite db while Pass uses a directory of .gpg files for each password, which is easier to backup using git and simple file sync systems

- Pass uses GPG to encrypt files which is reliable and preferable over rolling your own crypto

[ludbb]

While using AES-256-CFB is not "rolling their own crypto", Steel has some other functionality around (see https://gitlab.com/Rosvall/steel/blob/master/crypto.c) which provides bad implementations, namely generate_pass which seeds from timestamp and verify_hmac which is not a constant time comparison function.

[stouset]

Yes, it absolutely is[0] for essentially the exact examples you cite.

[0]: http://www.cs.berkeley.edu/~daw/teaching/cs261-f12/misc/if.h...).

[nvr82]

Steel is not rolling it's own crypto. It uses AES in cfb mode as implemented by libmcrypt.

[stouset]

Building your own abstractions on top of AES directly is no less dangerous or prone to error.

[orthecreedence]

> Building your own abstractions on top of AES directly is no less dangerous or prone to error.

You're telling me it's just as dangerous to implement a well-known library that has working AES-CFB as it is to roll your own AES-CFB implementation?

That's silly. Yes, it's dangerous to do any form of crypto. But there are really good resources on how to implement it correctly, and if you're using an existing library, the risks are significantly reduced.

[stouset]

Yes, insofar as the likelihood of introducing an exploitable catastrophic flaw in either scenario is essentially 1.

If you think you can just slap AES on something and call it a day, you're going to have a bad time.

[orthecreedence]

This can be reduced to a simple mathematical equation:

    (risk of hand rolling AES * risk of poor implementation) > risk of poor implementation

Also, if your assumption that the likelihood of introducing a catastrophic flaw is 1 was correct, there would be no correctly implemented crypto anywhere (although it would make the above equation false).

I agree with the nature of your arguments: crypto must be treated with care, and must be vetted by experts. However the whole "DON'T DO CRYPTO EVER!!" mindset is a lot more harmful in the long run. It's a powerful and dangerous tool, but it should be documented and understood instead of making us cower in fear.

[stouset]

Sorry, I missed your reply to this. In case you do ever read this, my point is that:

    (risk of an amateur hand rolling AES * risk of poor implementation by an amateur) = risk of poor implementation by an amateur + epsilon = 1

Even experts make mistakes in these things, but amateurs don't even stand a chance. An amateur will make more mistakes doing both, for sure, but there are bound to be enough catastrophic flaws that it simply doesn't even matter at that point. More real-world attackers are going to try and exploit your abstractions on top of AES than try to exploit your AES implementation itself.