so, doesn't seem terribly difficult, everything in noise is done with interfaces so i am going to make my bitcoin/nostr for the:
- diffie hellman - secp256k1
- hash function - SHA256 using the SIMD implementation i use religiously now
- cipher - ie, the encryption - i want to use chacha-poly-20 built off https://github.com/lukechampine/frand replacing AES for the cipher stream
i've found a "noiseconn" which implements a net.Conn that uses a noise protocol based cipher suite and i'll be adapting from that - it's a very short and sweet little thing, but i'm not sure yet if i can drop in my ciphersuite
so, first thing to do is build the cipher suite
i'm firmly of the opinion that even though p256 is probably NSA backdoored, secp256k1 - by 15 years of bulletproof security of bitcoin - and by its deterministic, non-arbitrary group parameters is likely not backdoored and more than equally secure as edwards
and i also think that, based on what lukechampine, the guy who wrote the fast CSPRNG based on chacha20 says, that AES is possibly broken or certainly not as fast as what he recommends, so i'm gonna make a full bitcoiner-gopher-crazyperson cryptosystem based on actually all well proven strong security components
they say you should not build your own cryptosystems but i understand them well enough and no part of it is in any way in my mind questionable, just, not been used together before
the hash was simple, and the diffie hellman pretty straight forward (same algo as nostr for nip-04 DMs) but the actual encryption will be another thing
default nonce length for AES is 16 bytes, with the exception of GCM which uses 12... i am thinking to use straight 32 byte long nonces, as this makes preimage attacks basically impossible, and block size is anyhow gonna be 32 bytes so i think that makes sense (same as it is almost never worth using 32 bit values anymore unless it's over the wire or on disk)
and the signature will be a standard schnorr 64 byte signature, and because it needs it, the public key has to be part of it (it's ostensibly AEAD) - so, i think it's gonna be:
32 bytes nonce, message, 32 bytes pubkey, 64 bytes signature
i've tested similar encryption already, using the same hash functions and signature algorithm last year, it was able to push about 8mb/s/core, so i think that's ok, also, i was using AES then, so now, using the block cipher construction with chacha-poly-20 it probably will be faster than that, which i think will mean it's essentially going to be more secure and faster, just a little more base overhead on messages, which probably also can permit less frequent rekeying but i'll not tinker with that
Showing page 1 of
1 pages
