0
$\begingroup$

Just for anyone reading this: DO NOT ROLL YOUR OWN ALGORITHM.

Besides that, is implementing a well-trusted protocol with well-trusted algorithms and libraries a good idea? Is this likely to colossally fail like rolling your own crypto? Could this be used in production after enough peer review? (I know that rolling your own crypto is definitely NOT secure)

Let's say I'm trying to implement a simple JavaScript website that generates RSA key pairs, RSA encrypts, and signs, and also AES encrypts data (e.g. an asymmetric key exchange than a symmetric conversation; the simplest protocol out there). If I use well-respected libraries, respected algorithms (i.e. AES & RSA) and peer-review the website, is this likely to have vulnerabilities?

(We're ignoring all the issues of authenticity in code with JavaScript) (Also, I'm not implementing my own algorithm, i.e. AES, to keep that clear)

$\endgroup$
  • $\begingroup$ There many libraries over there and they have some known problems, etc and waiting for your help! This is a good way to learn. $\endgroup$ – kelalaka Oct 12 at 15:18
  • $\begingroup$ A trustworthy protocol is relatively easy to identify. (Which isn't to say that it's at all hard to make incorrect judgements on protocols based on limited knowledge.) Finding trustworthy implementations probably won't be easy for JavaScript. $\endgroup$ – Future Security Oct 12 at 15:30
  • $\begingroup$ @FutureSecurity how can I know if I have found a trustworthy implementation? Should I look for an implementation with the most scrutiny? $\endgroup$ – mngxyuiso Oct 12 at 15:32
  • 1
    $\begingroup$ JavaScript is notorious for its messiness and ubiquitous use of vulnerable libraries. I'm not a JS programmer primarily for those kinds of headaches. I'd recommend a binding of lib Sodium for other languages. It's not possible to use one in a browser, however. You would need a pure JS port, but I wouldn't trust a JS reimplementation. $\endgroup$ – Future Security Oct 12 at 16:05
  • $\begingroup$ Oh. Good. It turns out that there actually is an official JS build. (Cross compiled from the original. That avoids a lot of the danger of re-implementation. Not everything, though. Side channel attacks for example.) Someone else will know more on the topic than I do, so keep looking into things..Don't trust people just because they're confident, though. And don't trust software just because it's popular. $\endgroup$ – Future Security Oct 12 at 16:12
2
$\begingroup$

If you have to implement or design and implement your own protocol then using well established libraries is generally the way to do it. JavaScript is a large eco-system. For such ecosystems it is not adviced to implement your own (partial) "hazardous materials" library for the low level functionality that you require. It is much more likely that there is something out there that would be more secure.

Of course, if there already is a higher level protocol or protocol implementation out there then you should definitely try and use or improve that. Developing transport security - which is often what is tried with JavaScript - is very hard. This is why most of the time the best solution is to use TLS underneath.

$\endgroup$
  • $\begingroup$ I have implemented e.g. web-security one time because it was easier to implement and secure my own internal product than what was already out there. But that was kind of a unique situation because I could not find any documentation on the web-security of Glassfish and Tomcat (Java Application Servers) and I suspected that they were broken - as they proved to be. But note that at that time I was already a seasoned secure developer and CS student. $\endgroup$ – Maarten - reinstate Monica Oct 12 at 15:46
  • $\begingroup$ great experience from earliest times. $\endgroup$ – kelalaka Oct 12 at 17:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.