[zxcmx]

With lots of "security best practice" crypto constructions you can quickly find yourself needing to use unreviewed and unsupported libraries. This is a different kind of security hell.

It's worst when you're publishing an API and you need to support web clients, plus android, IOS and ideally not make things super difficult for customers using say, erlang.

As someone who used to regularly recommend things like "Use a high level / simplified library - try keyczar! Or crypto_box! etc" it has been disheartening to see how almost any even slightly niche choice will quickly devolve to developers having to pull in a bunch of dodgy looking objective-c code written say, 3 years ago by a single unknown developer.

It's usually worked out better from a whole-system perspective to stick with very widely supported standards (flawed as they are) and maintain a checklist of known footguns. It makes me sad.

Of course if your crypto is opaque to clients / not part of your integration surface then you've got a lot more wiggle room.

Perhaps what I've taken the long-winded route to getting to is, for anything where interop is important, I believe that popularity is absolutely valuable due to network effects and momentum.

[anonsivalley652]

That is true. The real world is dirty and messy:

- supporting public LAMP apps

- database servers that have public IP addresses that are barely filtered

- boxes not getting updates

- under-secured Linux boxes with almost every option recompiled to on

- chmod 777 developers

- substituting signatures of checksums for signatures of data

- not using HMAC and opening themselves up to length-extension and chosen plaintext attacks

- storing SSL/SSH private keys unencrypted on unencrypted laptops

- downloading HR data to a laptop and leaving it

I actually was fired once from a big name university in the SF Bay Area for refusing to haphazardly ruin the network security of a credit card processing private campus network to facilitate a new vendor remoting into terminals.

Integrity through awareness/caution, processes and standard components.

Bringing in a bunch of random dependencies, regardless of license or support status, is inviting all sorts of gaping attack surfaces.