Does anyone know why Noise protocol was ruled out for p2p traffic? vtnerd mentioned that it was yesterday in #monero-dev

But I wasn't able to find any other information on this

<vtnerd> I had a discussion with jberman, where it was difficult for me to list strong arguments in favor of implementing it

<vtnerd> basically, we could in theory make it hard to identify as monero traffic, but in practice the default ports are going to give it away

<vtnerd> so the value add for noise is that port+dpi is probably difficult (because dpi could identify ssl more easily)

<vtnerd> but that was the small benefit, with the downside of maintaining a custom implementation or making yet-another dependency

<vtnerd> if you feel strongly about it, most this is in the ssl PR, and we can discuss switching to noise instead

<vtnerd> also note that we aggressively “pin” TLS/SSL versions and ciphersuites

I was just wondering about it haha

What do you mean by 'pin'?

<vtnerd> we force newish version of SSL, so that downgrade attacks on older SSL versions are not possible

<vtnerd> all monero SSL uses this logic, so its standard across all monero related ssl stuff

<ravfx:xmr.mx> Does monero wallets enforce HSTS? Like if I enable it on my nodes?

<vtnerd> uh it doesn’t use HSTS. afaik this is super specific to browsers mostly

<ravfx:xmr.mx> Ok, so not going to lose time to set that up

<vtnerd> there is a flag in the wallet —daemon-ssl enabled that requires SSL with a signed cert

<ravfx:xmr.mx> Well, my node force tls by default and wallets seam to be fine with that (autodetect)

<ravfx:xmr.mx> For rpc

<vtnerd> the only issue with autodetect is that it allows MitM - an attacker pretends that SSL is disabled, etc

<ravfx:xmr.mx> Yeah, its why I asked about HSTS.

<vtnerd> yes, use —daemon-ssl enabled to simulate HSTS mode

<ravfx:xmr.mx> I mean if someone mitm me, dose it will notice that the cert changed (even if the cert is valid)?

<ravfx:xmr.mx> I use a reverse proxy to enable tls

<interestingband:matrix.org> "rekt.news/cutting-corners", "Can't audit everything? Just draw some arbitrary lines and hope attackers respect the boundaries" :D

<kayabanerve:matrix.org> github.com/monero-oxide/monero-oxide/tree/fcmp%2B%2B/audits is my organization and presentation of the FCMP++ audits w.r.t. the modules in the codebase.

<kayabanerve:matrix.org> (the GBP academia is included with the GBP folder corresponding to the GBP impl)

<kayabanerve:matrix.org> Some libs from Serai are used as deps, audited some years ago: github.com/serai-dex/serai/tree/dev…her%20Stack%20crypto%20March%202023

<kayabanerve:matrix.org> For the Rust ed25519 library we use, we have the option of formally verified arithmetic for the field implementations.

<kayabanerve:matrix.org> And then while the Monero node may not be audited, Cuprate serves as a canary. Any large enough institution should run both.

<kayabanerve:matrix.org> Oh. Serai also has a BBP over a variety of our cryptography libs, Monero has its BBP.

<kayabanerve:matrix.org> monero-oxide, not yet inclusive to the fcmp++ code, is also something I've currently stated I'll accept reports for under Serai's BBP, pending its own program.

<kayabanerve:matrix.org> All in all, it puts Monero's posture in a decent place.

<kayabanerve:matrix.org> I do believe the best solution to security on a node level is independent implementations.

<kayabanerve:matrix.org> FCMP++ is almost entirely done and moving to redundant reviews (which are only redundant until they aren't).

<kayabanerve:matrix.org> We've also finally straightened out multisig, hash to curve?

<kayabanerve:matrix.org> Oh. I saw the posted link and figured I'd comment re: Monero yet missed _who_ posted it. Never mind then.