Security Audit

[tanx]

Hi,

we're using forge for our app and were wondering if forge already went through an in depth security review?

Thanks

[dlongley]

Hi @tanx,

We've done an internal review and so has Scytl. They use forge in all of their online elections to perform cryptographic operations in their JavaScript-based voting clients. If you do any sort of security audit, we can add your company to a list of reviewing companies that we can include with the project.

[devgeeks]

@dlongley do you know if Scytl made the results of their audit available? Did they feed back any issues to you after having it done?

[dlongley]

@devgeeks, I asked Scytl to see what kind of feedback they were able to give; they provided a brief, informal summary of what they reviewed and their experience with forge. Here's their response (from Sandra Guasch Castelló):

We have tested the functionalities we are using from Forge, which do not cover the whole library, for compatibility with other libraries such as Java BouncyCastle, OpenSSL and Apache.

The functionalities are AES encryption, triple DES encryption, RSA signatures and encryption, Base64 encoding/decoding, SHA-256 hash functions, x.509 certificate parsing and pkcs#12 opening and parsing.

As you may remember, we had some trouble with the pkcs#12 functionality, but it was not a security fault, in fact it was because your pkcs#12 implementation was behaving strictly well

Another thing that we have had trouble with, is the getBytes function, which is misleading because it does not return bytes, but a string. That method caused us some trouble when working with numbers, and maybe you could consider renaming it for preventing misuse.

Also, we have analyzed the implementation of the PRNG provided by Forge. About that, we have two main conclusions:

1. Forge obtains some entropy from the browser environment, however more entropy could be obtained from other sources available in the browser, and specifically if mobile devices are considered.
2. Forge implements the Fortuna PRNG, which is intended for long-live applications (because of the division of the entropy collected in different pools, etc). However, we believed that for short-live applications it would be more useful to collect all the entropy at the same pool.
   Therefore, we are using an alternative.

In conclusion, in general we have not been looking at the implementations themselves, but checking if they were correct by testing the compatibility against reference libraries.

[bluehallu]

"In conclusion, in general we have not been looking at the implementations themselves, but checking if they were correct by testing the compatibility against reference libraries."

How is that a security audit?

[sandra1234567890]

It's not. That was my point on explaining what we did.

[elimisteve]

So no security audit yet, correct? Thanks.

[daviddahl]

It might be worthwhile to see if these auditing projects are operational and open for audits:

https://opencryptoaudit.org/
https://wiki.mozilla.org/MOSS/Secure_Open_Source