How secure is your library? about near-js-encryption-box

[abacabadabacaba]

When developing cryptographic code, there are many ways to get it wrong without noticing. Many of the possible flaws cannot be found by testing, and the fact that some components (such as TweetNaCl) were audited doesn't say much about the security of the entire program.

Having said that, I believe that this specific combination of primitives (Ed25519 signature scheme and X25519 key agreement used by NaCl box) is not vulnerable to cross-protocol attacks. Moreover, both are secure individually. Thus, the way the keys are used here should be secure, however, a proper proof is needed to confirm this.

So, the reason for this notice is not because there are any weaknesses that we know about, but rather because this is an unverified cryptographic code which may have weaknesses that we don't know about.

[sandoche]

Hi @VlodkoMr,

It's usually not recommended to store encrypted data on chain because there is a chance that in the future the encryption will be cracked (for example with quantum computing). So if you do so make sure you have ways to upgrade to a better encryption algorithm in the future in case this algorithm is at risk.

As concern the algorithm itself, near-js-encryption-box uses TweetNaCl which has been audited (https://tweetnacl.js.org/audits/cure53.pdf) which is a good thing.

Nevertheless in order to use TweetNaCl I had to convert the Ed25519 signing key pair into Curve25519, I used ed2curve-js to do so. If you check the ed2curve-js repo you can see the following statement:

Note that there's currently no proof that this is safe to do. It is safer to share both Ed25519 and Curve25519 public keys (their concatenation is 64 bytes long).

Before using it in production it would be wise to make an security audit.

Congrats on the chat app by the way!

[VlodkoMr]

Thank you!!!