4 ms·

I noticed in July of 2022 that Go did exactly the vulnerable example and reported it to the security team. https://github.com/golang/go/issues/53849 https://gi

I noticed in July of 2022 that Go did exactly the vulnerable example and reported it to the security team. https://github.com/golang/go/issues/53849 https://github.com/golang/go/issues/53849 It was fixed as of Go 1.21 https://go.dev/doc/go1.21 https://go.dev/doc/go1.21 --- The article cites JavaScript, which is not constant time. There's no sure way to do constant time operations in JavaScript and thus no secure way to do crypto directly in Javascript. Browsers like Firefox depend on low level calls which should be implemented in languages that are constant time capable. JavaScript needs something like constant time WASM in order to do crypto securely, but seeing the only constant time WASM project on GitHub has only 16 stars and the last commit was 2 years ago, it doesn't appear to have much interest. https://github.com/WebAssembly/constant-time https://github.com/WebAssembly/constant-time However, for JavaScript, I recommend Paul's library Noble which is "hardened to be algorithmically constant time". It is by far the best library available for JavaScript. https://github.com/paulmillr/noble-secp256k1 https://github.com/paulmillr/noble-secp256k1

gmac 3y ago
In JS you’d use SubtleCrypto, (as long as it implements what you need), right?
- Zamicol 3y ago
  Yes, SubtleCrypto is preferred when usable. There's two main issues with SubtleCrypto, a minor problem and a major problem. The minor problem is that it doesn't support much. 13 year old modern algorithms like Ed25519 and Ed25519ph are largely unsupported and browser support moves at glacial speed. Ed25519ph isn't supported by any, even though it's been adopted by NIST (see FIPS 186-5). This is where libraries like Paul's must be used. For browser support see https://caniuse.com/mdn-api_subtlecrypto_sign_ed25519 https://caniuse.com/mdn-api_subtlecrypto_sign_ed25519 The major problem with SubtleCrypto is that it requires the original message to sign and verify. SubtleCrypto.sign(algorithm, key, data) and SubtleCrypto.verify(algorithm, key, signature, data) This is contrasted to Go's ECDSA package which expects a digest to sign and verify. See https://pkg.go.dev/crypto/ecdsa#PrivateKey.Sign https://pkg.go.dev/crypto/ecdsa#PrivateKey.Sign This means that if signing a 2 GB document, Go can easily verify the signature using the 256 bit digest, while Javascript would require the whole 2 GB document to be loaded into SubtleCrypto.verify before verification and is an enormous waste of resources. If it isn't clear from the above what the problem is, let me rephrase: SubtleCrypto's sign and verify always rehashes, so a developer cannot give it the digest. Instead, developers are forced to give it the whole document so it can rehashed by SubtleCrypto. This is a significant design blunder that others, like Go, avoided and will motivate developers to use less constant time safe libraries like Paul's.
  - gmac 3y ago
    Thanks, that’s a helpful summary. I knew about the ed25519 issue (but not the others) from writing this: https://github.com/jawj/subtls https://github.com/jawj/subtls

gmac 3y ago

In JS you’d use SubtleCrypto, (as long as it implements what you need), right?

Zamicol 3y ago
Yes, SubtleCrypto is preferred when usable. There's two main issues with SubtleCrypto, a minor problem and a major problem. The minor problem is that it doesn't support much. 13 year old modern algorithms like Ed25519 and Ed25519ph are largely unsupported and browser support moves at glacial speed. Ed25519ph isn't supported by any, even though it's been adopted by NIST (see FIPS 186-5). This is where libraries like Paul's must be used. For browser support see https://caniuse.com/mdn-api_subtlecrypto_sign_ed25519 https://caniuse.com/mdn-api_subtlecrypto_sign_ed25519 The major problem with SubtleCrypto is that it requires the original message to sign and verify. SubtleCrypto.sign(algorithm, key, data) and SubtleCrypto.verify(algorithm, key, signature, data) This is contrasted to Go's ECDSA package which expects a digest to sign and verify. See https://pkg.go.dev/crypto/ecdsa#PrivateKey.Sign https://pkg.go.dev/crypto/ecdsa#PrivateKey.Sign This means that if signing a 2 GB document, Go can easily verify the signature using the 256 bit digest, while Javascript would require the whole 2 GB document to be loaded into SubtleCrypto.verify before verification and is an enormous waste of resources. If it isn't clear from the above what the problem is, let me rephrase: SubtleCrypto's sign and verify always rehashes, so a developer cannot give it the digest. Instead, developers are forced to give it the whole document so it can rehashed by SubtleCrypto. This is a significant design blunder that others, like Go, avoided and will motivate developers to use less constant time safe libraries like Paul's.
- gmac 3y ago
  Thanks, that’s a helpful summary. I knew about the ed25519 issue (but not the others) from writing this: https://github.com/jawj/subtls https://github.com/jawj/subtls