Good morning Apostolos, answers inline.
On November 27, 2013 at 10:40:00 AM, Apostolos Emmanouilidis (aemmanou(a)redhat.com) wrote:
Hi,
While reading and testing the AeroGear JS crypto library, I came up with
some questions/findings. Before opening JIRAs I'd like to discuss them
with you.
a) The KeyPair function which creates a pair of cryptographic keys for
assymetric encryption is using the SJCL ECC library [1] to generate keys
if no keys are provided.
sjcl.ecc.elGamal.generateKeys( 192,0 )
If I understand well, the first argument (192) is the elliptic curve
and the second argument (0) is the paranoia. These values are hardcoded
inside aerogear.crypto.js. Is there any specific reason for which the
values are 192 and 0? According the BSI recommendations [3] and NSA
suite cryptography sheet [2]], the elliptic curve is recommended to be
256 for secret level or 384 for top secret. The SJCL source code shows
that if paranoia is set to be 0 then the random value generator [7] is
called with paranoia value 0 and the consequence is that the SCJL
randomWords is called with paranoia value 0. According the SCJL author's
comments [6], calling the randomWords with paranoia value 0 is
explicitly warned against, and is for use only in unit tests where
entropy may not be available. Maybe we should consider increasing the
For this release, asymmetric encryption wasn’t our first priority becausethe development
of the server for key management will be necessary. We are aware about NIST
recommendations, but if you want some sense of high encryption and paranoia, we should
never use standard curves recommended by NIST.
That said, the solo reason to stick to default values is because we didn’t start the
development of the server as well the tests between client/server.
elliptic curve and paranoia values or allow the user to set his
desired
values by passing them when creating the keys. The same applies for
digital signatures support ECDSA [8].
It can be provided as an alternative parameter, but the main idea of the API is to make it
simple for newcomers.
Below you can see some performance results for
sjcl.ecc.elGamal.generateKeys(elliptic curve). Unfortunately I'm facing
issues when trying to measure the performance on Safari and Chrome
browsers. If I manage to resolve them, I'll let you know their
performance statistics.
b) The getRandomValue method [4] which creates cryptographically pseudo
random values is using the window.crypto.getRandomValues of the
WebCryptoAPI [9]. The browser compatibility map for this method,
according [5] is:
Regarding the Android browser support, the crypto.getRandomValue is
supported in Android versions >= 4.0. In previous Android versions, I
receive an exception on line aerogear.crypto.js line 86. This means that
the crypto.getRandomValue is not supported in Android versions < 4.0.
Shouldn't we add a check to verify whether WebCryptoAPI is supported on
the browser? Something like if (window.crypto &&
window.crypto.getRandomValue) {....} else { //handle the case }. My
Sure we can do it.
first thought is to use to SJCL random to produce cryptographically
pseudo-random values in the cases where the WebCryptoAPI is not
supported by the browser. There are some vulnerabilities [6] if SJCL
randomWords is called without calling startCollectors() to start the
entropy collector on page load and paranoia is set to 0. SJCL
startCollectors() needs to be called on page load so that entropy
collector is started and the random values produced from SJCL are
Agreed, the entropy on SJCL is completely poor, that’s the reason why we prefer
WebCrypto.
strong. To be honest this solution seems to me as quite dirty. Should
we
add an alternative pseudo-random values generator in the cases where the
WebCryptoAPI is not supported by the browser?
JS cryptography is already tough to deal with, introduce weak RNGs would make things
worse. Into this scenario, if for some reason the browser doesn’t support it, we can raise
an error or something like that.
Thanks for testing, feel free to add Jiras and assign to me if you want.
--
abstractj