← Back to context

Comment by arp242

6 days ago

What people mean with "trust" here is whether they trust there are no subtle security issues. While I think "don't roll your crypto" has been somewhat overstated at times (someone has to write crypto), there is certainly some truth in that you need to be very careful writing this code and that mistakes are incredibly easy to make, even for competent developers.

If I were to release something like this then people can see that 1) this is a guy with >20 years of various contributions to open source and he seems like a basically competent guy we can trust (as much as you can ever trust a single person), but also that 2) he's not a crypto guy and there may very well be oversights. Maybe there are none, but you know...

If someone like, say, Filippo Valsorda would release someone like this, then people could see that 1) is basically the same as me, and 2) he's also a well known crypto guy with a good track record. This is not a guarantee there are no oversights, but I would certainly be surprised if there were major ones. I would certainly trust that more than anything I would write.

The whole signing stuff is kind of a red herring IMO. I mean, it's not bad to have I guess, but honestly I don't really care. If anything, focusing to strongly on "box ticking security" so early on seems like the wrong thing to focus on.

Thanks for your feedback 'I tried to use of the shelf stuff for the crypto and utilised what I believe to be battle tested.

CLI uses node.js built-in crypto module only -randomBytes - createDecipheriv - createCipheriv.

Web app uses Web Crypto API only.

I'll send Filippo a Postcard and see if he will review it :-P