From david at bamsoftware.com Sun Apr 25 14:17:05 2021 From: david at bamsoftware.com (David Fifield) Date: Sun, 25 Apr 2021 15:17:05 -0600 Subject: [noise] Security audit of Noise-based DNS tunnel, protocol layering Message-ID: <20210425211705.lo44wa7zm5lgvkem@bamsoftware.com> A Noise-based DNS tunnel I wrote has recently had a security audit. You can see the report and a summary of changes here: https://www.bamsoftware.com/software/dnstt/security.html#cure53-turbotunnel-2021 Of the 4 Noise-related issues discovered, 3 had to do with a dependency Noise library, which has already been updated: https://github.com/flynn/noise/security/advisories/GHSA-g9mp-8g3h-3c5c I want to talk about this one: "UCB-02-005: Client ID security considerations & Noise authenticated data." https://www.bamsoftware.com/software/dnstt/cure53-turbotunnel-2021.pdf#page=8 To understand what it's about, you need to know two things about how the tunnel is structured: 1. The DNS tunnel server needs to be able to distinguish among multiple concurrent client sessions. When the server receives a DNS query containing some encapsulated data, it needs to know which ongoing session to deliver that data to. In a non-tunneled TCP-based service, sessions would be distinguished (inside the kernel TCP) by their source IP address and port. But a network-layer source address won't work for a DNS tunnel, as queries are generally forwarded by an intermediate recursive resolver, removing the original source information. So in my implementation, DNS tunnel clients attach to every query a "client ID," a 64-bit number randomly generated by the client. The client ID may be compared to connection IDs in QUIC: abstract identifiers not tied to any particular network address. The DNS tunnel server maintains a mapping from client IDs to sessions, which in this case are outgoing TCP connections. The server creates a new session the first time it sees a new client ID. When a DNS query arrives at the server bearing a certain client ID, not only is the data it contains delivered upstream to the associated session, but the response to the query is also eligible to contain downstream data from the same session. 2. UDP-based DNS is unreliable and unordered. In order to establish a reliable stream abstraction over DNS messages, we have the DNS messages encode not raw application-layer data, but *packets* of a user-space sequencing and reliability protocol, in this case KCP. The details are not important; it's enough to know that KCP, like TCP, uses sequence numbers and acknowledgements, and does retransmission of lost data. Rather than let KCP interface with the network directly, we intercept its network calls and encapsulate the packets in DNS messages. On top of a session discriminated by client ID, and a reliable stream provided by KCP, we overlay a Noise protocol. Noise messages are delimited by 16-bit length prefixes, the same way you might do if you were transferring them over TCP. The protocol stack looks like this: user data Noise KCP DNS messages Notably, the KCP-layer headers are not protected by the Noise layer. It's similar to running TLS over a TCP connection: the TLS is internally encrypted and integrity-protected, but the containing TCP headers are subject to certain kinds of manipulation. For more discussion, see https://www.bamsoftware.com/software/dnstt/protocol.html#crypto. Back to UCB-02-005. Though it is outside the censorship circumvention threat model (in that model, encrypted DNS hides the client ID from all relevant adversaries) the audit rightly notes that if an attacker can discover or guess a user's client ID, they can send queries on behalf of, and receive responses intended for, that client. This because a client ID attached to a DNS query is a token that entitles the sender to interact with the data stream associated with that client ID. It's a bit like TCP hijacking, where an attacker can manipulate a connection if it knows a client's source IP address, port, and current sequence numbers. The attacker cannot actually *do* anything with the data it hijacks, because the reassembled KCP packets contain Noise messages, to which the attacker does not know the key; and any injected data will invariably fail integrity checks and at worst cause the session to terminate. But the fact is, certain kinds of manipulation are possible. To mitigate this risk, the audit report recommends folding the client ID into the associated data in the Noise AEAD construction. While a reasonable suggestion, I don't think it actually solves the problem in this case. The reason is the way the protocol stack is layered. Noise messages are at a higher layer than KCP packets and the DNS messages that carry them. DNS messages are not independently authenticated. An attacker that sends DNS queries bearing the client ID of some client would still be able to claim DNS responses intended for that client. To make it work the way the audit report intends, the protocol stack would rather have to look like this: user data KCP Noise DNS messages That is, let every DNS message contain an encapsulated Noise message, independently authenticatable along with the attached client ID as additional data. The Noise messages contain KCP packets, which carry user data. In this model, the server would authenticate each incoming query before acting on it, which would prevent processing of any queries other than those sent by the legitimate Noise-layer peer. I actually considered this alternative layering while designing the DNS tunnel protocol, and decided against it for two reasons: somewhat greater implementation complexity (you need to account for retransmission of handshake messages outside of KCP), and bandwidth limitations. DNS messages, especially queries, are squeezed for bandwidth. See discussion here: https://www.bamsoftware.com/software/dnstt/survey.html#Generalobservations After you account for the need for DNS-safe encoding, the amount of raw data you can pack into a query is only about 140 bytes. An 8-byte explicit nonce, 16-byte AEAD tag, and 1-byte type indicator (to distinguish handshake messages from transport messages) eat about 18% of available space, not counting the additional overhead of client ID and KCP headers. The benefit of placing Noise higher in the protocol stack is that Noise messages can be longer, explicit nonces are not needed, and AEAD tag overhead is amortized over multiple DNS messages. But the design choice was based mostly on intuition, and I did not actually try the alternative design to see how much it affects efficiency. Now I'm wondering if it's worth rearchitecting the protocol stack to be based on out-of-order Noise messages, something like https://noiseprotocol.org/noise.html#out-of-order-transport-messages https://www.wireguard.com/papers/wireguard.pdf#page=12 (Section 5.4.6) Questions of bandwidth efficiency aside, it would be a better design cryptographically. On the other hand, it would break compatibility with existing installations, and as I understand things, it would not greatly diminish the class of attackers able to interfere with a session: it would exclude on-path, non-flow-blocking attackers who can passively listen for client IDs and inject traffic; but an in-path, flow-blocking attacker could still deny service by dropping packets. I'm writing this to invite comment. What do you think? Am I overlooking any more subtle attack, which the current protocol design is vulnerable to, but the alternative would not be? From trevp at trevp.net Tue May 4 17:34:02 2021 From: trevp at trevp.net (Trevor Perrin) Date: Tue, 4 May 2021 17:34:02 -0700 Subject: [noise] Security audit of Noise-based DNS tunnel, protocol layering In-Reply-To: <20210425211705.lo44wa7zm5lgvkem@bamsoftware.com> References: <20210425211705.lo44wa7zm5lgvkem@bamsoftware.com> Message-ID: Hi David, Nice to hear about dnstt!, some thoughts: On Sun, Apr 25, 2021 at 2:17 PM David Fifield wrote: > > A Noise-based DNS tunnel I wrote has recently had a security audit. You > can see the report and a summary of changes here: > https://www.bamsoftware.com/software/dnstt/security.html#cure53-turbotunnel-2021 > Of the 4 Noise-related issues discovered, 3 had to do with a dependency > Noise library, which has already been updated: > https://github.com/flynn/noise/security/advisories/GHSA-g9mp-8g3h-3c5c Nonce overflow isn't that likely (2^64 messages!), and the small-subgroup validation check doesn't matter for Noise, though I suppose this is the kind of application where you might want to specify one way or another to avoid some sort of "fingerprinting" of implementations. Invalid ciphertexts incrementing the nonce looks like a good catch though. > I want to talk about this one: "UCB-02-005: Client ID security > considerations & Noise authenticated data." > https://www.bamsoftware.com/software/dnstt/cure53-turbotunnel-2021.pdf#page=8 [...] > Back to UCB-02-005. Though it is outside the censorship circumvention > threat model (in that model, encrypted DNS hides the client ID from all > relevant adversaries) the audit rightly notes that if an attacker can > discover or guess a user's client ID, they can send queries on behalf > of, and receive responses intended for, that client. This because a > client ID attached to a DNS query is a token that entitles the sender to > interact with the data stream associated with that client ID. It's a bit > like TCP hijacking, where an attacker can manipulate a connection if it > knows a client's source IP address, port, and current sequence numbers. > The attacker cannot actually *do* anything with the data it hijacks, > because the reassembled KCP packets contain Noise messages, to which the > attacker does not know the key; and any injected data will invariably > fail integrity checks and at worst cause the session to terminate. But > the fact is, certain kinds of manipulation are possible. > > To mitigate this risk, the audit report recommends folding the client ID > into the associated data in the Noise AEAD construction. While a > reasonable suggestion, I don't think it actually solves the problem in > this case. Using the associated-data for AEAD would be a nonstandard use of Noise, if you want to "bind" additional data the more-supported way would be to include it into the prologue or handshake data, so it's used in deriving the session keys but doesn't require calculations on every packet. But I also agree with your last sentence, I'm not sure how that would improve anything: Binding the Noise messages to a clientID would prevent reuse of the Noise messages across a *different* clientID but that doesn't really seem like the issue they're describing? Is there an actual issue here? Even if an attacker discovering or guessing a client ID would be a DoS threat, how would that happen? If a server supported a X simultaneous connections and an attacker probed Y client IDs they might find a collision with Z probability, and you could maybe juggle X, Y, and Z to feel a little uncomfortable with a 64-bit space, so at most you might want to consider a larger client ID? Trevor From aep at exys.org Wed May 19 05:07:28 2021 From: aep at exys.org (Arvid Picciani) Date: Wed, 19 May 2021 14:07:28 +0200 Subject: [noise] earlier IK Message-ID: In order to not share the responder static key between multiple servers, i am considering creating a responder key per initiator. the responder key is then loaded hot only when needed and can be revoked more fine grained. This would require the responder to know which key to load. The current IK pattern has the initiator static encrypted with the responder static, so i can't look up the matching receiver keys. I could just use IX , but i actually want encrypted 0RTT payload, so something like XIK: <- s ... -> s, ss, e, es <- e, ee, se i'm assuming 0RTT payload has the same protection as IK, i.e. Source 1 and Destination 2, except it looses identity hiding, as that's kind of the point is this correct? thanks, Arvid -- +4916093821054 -------------- next part -------------- An HTML attachment was scrubbed... URL: From filippo at ml.filippo.io Wed May 19 06:07:23 2021 From: filippo at ml.filippo.io (Filippo Valsorda) Date: Wed, 19 May 2021 15:07:23 +0200 Subject: [noise] earlier IK In-Reply-To: References: Message-ID: Sounds like what you want is KK with the initiator's s in the prologue. You obviously lose all initiator identity hiding, but otherwise it should have the same payload properties as regular KK. 2021-05-19 14:07 GMT+02:00 Arvid Picciani >: > In order to not share the responder static key between multiple servers, > i am considering creating a responder key per initiator. > the responder key is then loaded hot only when needed and can be revoked more fine grained. > > This would require the responder to know which key to load. The current IK pattern has the initiator static encrypted with the responder static, so i can't look up the matching receiver keys. > > I could just use IX , but i actually want encrypted 0RTT payload, > > so something like > > XIK: > <- s > ... > -> s, ss, e, es > <- e, ee, se > > i'm assuming 0RTT payload has the same protection as IK, i.e. Source 1 and Destination 2, > except it looses identity hiding, as that's kind of the point > > is this correct? > > thanks, > Arvid > > -- > +4916093821054 > _______________________________________________ > Noise mailing list > Noise at moderncrypto.org > https://moderncrypto.org/mailman/listinfo/noise > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aep at exys.org Wed May 19 06:16:56 2021 From: aep at exys.org (Arvid Picciani) Date: Wed, 19 May 2021 15:16:56 +0200 Subject: [noise] earlier IK In-Reply-To: References: Message-ID: yes. actually, there might be a better option. If i send the _responder_ static key in prelude we get some minimal identity hiding because the responder key changes frequently. however, i'm unsure about the security implications because noise never sends the responder static anywhere for precedent. Does an attacker gain any advantage by knowing the public key for the responder? Is it easier to break then maybe since they can also observe the 0RTT payload encrypted for that recipient? On Wed, May 19, 2021 at 3:08 PM Filippo Valsorda wrote: > Sounds like what you want is KK with the initiator's s in the prologue. > > You obviously lose all initiator identity hiding, but otherwise it should > have the same payload properties as regular KK. > > 2021-05-19 14:07 GMT+02:00 Arvid Picciani : > > In order to not share the responder static key between multiple servers, > i am considering creating a responder key per initiator. > the responder key is then loaded hot only when needed and can be revoked > more fine grained. > > This would require the responder to know which key to load. The current IK > pattern has the initiator static encrypted with the responder static, so i > can't look up the matching receiver keys. > > I could just use IX , but i actually want encrypted 0RTT payload, > > so something like > > XIK: > <- s > ... > -> s, ss, e, es > <- e, ee, se > > i'm assuming 0RTT payload has the same protection as IK, i.e. Source 1 and > Destination 2, > except it looses identity hiding, as that's kind of the point > > is this correct? > > thanks, > Arvid > > -- > +4916093821054 > _______________________________________________ > Noise mailing list > Noise at moderncrypto.org > https://moderncrypto.org/mailman/listinfo/noise > > > _______________________________________________ > Noise mailing list > Noise at moderncrypto.org > https://moderncrypto.org/mailman/listinfo/noise > -- +4916093821054 -------------- next part -------------- An HTML attachment was scrubbed... URL: From justin at specialbusservice.com Wed May 19 06:33:14 2021 From: justin at specialbusservice.com (Justin Cormack) Date: Wed, 19 May 2021 14:33:14 +0100 Subject: [noise] earlier IK In-Reply-To: References: Message-ID: Knowing the public key isn't a security issue, other than what it reveals about identity. Justin On Wed, 19 May 2021 at 14:17, Arvid Picciani wrote: > > yes. > actually, there might be a better option. If i send the _responder_ static key in prelude we get some minimal identity hiding because the responder key changes frequently. > > however, i'm unsure about the security implications because noise never sends the responder static anywhere for precedent. > Does an attacker gain any advantage by knowing the public key for the responder? Is it easier to break then maybe since they can also observe the 0RTT payload encrypted for that recipient? > > On Wed, May 19, 2021 at 3:08 PM Filippo Valsorda wrote: >> >> Sounds like what you want is KK with the initiator's s in the prologue. >> >> You obviously lose all initiator identity hiding, but otherwise it should have the same payload properties as regular KK. >> >> 2021-05-19 14:07 GMT+02:00 Arvid Picciani : >> >> In order to not share the responder static key between multiple servers, >> i am considering creating a responder key per initiator. >> the responder key is then loaded hot only when needed and can be revoked more fine grained. >> >> This would require the responder to know which key to load. The current IK pattern has the initiator static encrypted with the responder static, so i can't look up the matching receiver keys. >> >> I could just use IX , but i actually want encrypted 0RTT payload, >> >> so something like >> >> XIK: >> <- s >> ... >> -> s, ss, e, es >> <- e, ee, se >> >> i'm assuming 0RTT payload has the same protection as IK, i.e. Source 1 and Destination 2, >> except it looses identity hiding, as that's kind of the point >> >> is this correct? >> >> thanks, >> Arvid >> >> -- >> +4916093821054 >> _______________________________________________ >> Noise mailing list >> Noise at moderncrypto.org >> https://moderncrypto.org/mailman/listinfo/noise >> >> >> _______________________________________________ >> Noise mailing list >> Noise at moderncrypto.org >> https://moderncrypto.org/mailman/listinfo/noise > > > > -- > +4916093821054 > _______________________________________________ > Noise mailing list > Noise at moderncrypto.org > https://moderncrypto.org/mailman/listinfo/noise From matvey.mukha at gmail.com Fri Jun 4 09:15:15 2021 From: matvey.mukha at gmail.com (Matvey Mukha) Date: Fri, 4 Jun 2021 18:15:15 +0200 Subject: [noise] Noise handshake pattern validity question Message-ID: Hello, Can I please ask a question about Noise handshake pattern validity? I'm looking at the validity rule number 4 and the four cases it outlines. If we take case number 3, "After an 'es' token...", what is the reason that the case cannot be safely extended to say "...unless there has also been an 'ee' or an 'se' token"? Would not it still fulfill the general description of rule number 4? In practice, if we take the IX handshake pattern: -> e, s <- e, ee, se, s, es What would be the negative effects of removing 'ee' from it? -> e, s <- e, se, s, es Thank you for the Noise Framework! -Matvey From loup at loup-vaillant.fr Fri Jun 4 10:20:42 2021 From: loup at loup-vaillant.fr (Loup Vaillant-David) Date: Fri, 04 Jun 2021 19:20:42 +0200 Subject: [noise] Noise handshake pattern validity question In-Reply-To: References: Message-ID: > In practice, if we take the IX handshake pattern: > -> e, s > <- e, ee, se, s, es > What would be the negative effects of removing 'ee' from it? > -> e, s > <- e, se, s, es Loss of forward secrecy. You can no longer guarantee that leaking the long term keys will not break the secrecy of past key exchanges. In this case: - Leaking the client key compromises the `se` exchange. - Leaking the server key compromises the `es` exchange. - Compromising both compromise *both* exchanges, and breaks secrecy. The `ee` exchange on the other hand is never compromised by future leaks (the private halves are erased). That's why you need it. Note that the only Noise patterns that do not have `ee` are the non- interactive patterns N, X, and K. That's because the recipient does not respond, and as such cannot provide an ephemeral key of its own. This makes forward secrecy impossible to achieve: if the recipient key is leaked, then the message is revealed. That's a big reason why we favour interactive protocols whenever possible. Loup. From david at bamsoftware.com Sat Jun 5 22:44:26 2021 From: david at bamsoftware.com (David Fifield) Date: Sat, 5 Jun 2021 23:44:26 -0600 Subject: [noise] Security audit of Noise-based DNS tunnel, protocol layering In-Reply-To: References: <20210425211705.lo44wa7zm5lgvkem@bamsoftware.com> Message-ID: <20210606054426.nthy3likwq2ms6kt@bamsoftware.com> On Tue, May 04, 2021 at 05:34:02PM -0700, Trevor Perrin wrote: > > I want to talk about this one: "UCB-02-005: Client ID security > > considerations & Noise authenticated data." > > https://www.bamsoftware.com/software/dnstt/cure53-turbotunnel-2021.pdf#page=8 > [...] > > Back to UCB-02-005. Though it is outside the censorship circumvention > > threat model (in that model, encrypted DNS hides the client ID from all > > relevant adversaries) the audit rightly notes that if an attacker can > > discover or guess a user's client ID, they can send queries on behalf > > of, and receive responses intended for, that client. This because a > > client ID attached to a DNS query is a token that entitles the sender to > > interact with the data stream associated with that client ID. It's a bit > > like TCP hijacking, where an attacker can manipulate a connection if it > > knows a client's source IP address, port, and current sequence numbers. > > The attacker cannot actually *do* anything with the data it hijacks, > > because the reassembled KCP packets contain Noise messages, to which the > > attacker does not know the key; and any injected data will invariably > > fail integrity checks and at worst cause the session to terminate. But > > the fact is, certain kinds of manipulation are possible. > > > > To mitigate this risk, the audit report recommends folding the client ID > > into the associated data in the Noise AEAD construction. While a > > reasonable suggestion, I don't think it actually solves the problem in > > this case. > > Using the associated-data for AEAD would be a nonstandard use of > Noise, if you want to "bind" additional data the more-supported way > would be to include it into the prologue or handshake data, so it's > used in deriving the session keys but doesn't require calculations on > every packet. I see, thanks for that information. Putting that information in the prologue indeed seems like a better way to effect the binding. I see in the spec where it requires zero-length associated data in transport messages: https://noiseprotocol.org/noise.html#processing-rules "Transport messages are then encrypted and decrypted by calling EncryptWithAd() and DecryptWithAd() on the relevant CipherState with zero-length associated data." > But I also agree with your last sentence, I'm not sure how that would > improve anything: Binding the Noise messages to a clientID would > prevent reuse of the Noise messages across a *different* clientID but > that doesn't really seem like the issue they're describing? > > Is there an actual issue here? Even if an attacker discovering or > guessing a client ID would be a DoS threat, how would that happen? If > a server supported a X simultaneous connections and an attacker probed > Y client IDs they might find a collision with Z probability, and you > could maybe juggle X, Y, and Z to feel a little uncomfortable with a > 64-bit space, so at most you might want to consider a larger client > ID? I don't think there's any serious issue. An attacker can check whether a particular client ID is currently in use, and with a sustained attack can deny service to a known client ID, but the space is meant to be big enough not to be easily guessable. It is true that incoming packets pass through a lot of non-trival code (the KCP layer) before they are seen by Noise authentication. Authenticating each packet individually would reduce attack surface, from a code security standpoint. Binding the Noise connection with a client ID is not needed, I think. Replaying messages with a different client ID wouldn't do anything: those messages would wind up in a different queue on the server. It would be like replaying someone else's TCP connection from a different IP address—it doesn't interact with the original connection. I think I'll leave the dnstt layering alone, for the sake of backward compatibility. I'm working on another kind of tunnel now, one that has more space available per packet, and maybe I'll experiment with per-packet authentication there. Thanks for your comments. From Jason at zx2c4.com Sun Aug 8 15:33:13 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Mon, 9 Aug 2021 00:33:13 +0200 Subject: [noise] another thread on montonic counter alternatives Message-ID: Hi folks, We've had this discussion a few times in various forms, but it's come up again recently, with Karolin Varner (CC'd) emailing me with some fresh enthusiasm about the problem space, so I thought this might be something worth discussing again, perhaps this time with some input from the Noise mailing list. NoiseIK is 1-RTT, so WireGuard sticks a timestamp in the first message to prevent replay attacks. Responders reject packets with timestamps that are larger than the last one received. If a responder reboots, there's subsequently no session to disrupt with a replay anyway, so it's not an issue. Generally this works well, provided initiators have a reliable monotonic counter. Generally timestamps are considered reliable-enough monotonic counters. Issues with this begin from two angles: Angle 1) Embedded devices without a battery powered RTC that want to use WireGuard to bootstrap have a chicken & egg problem. Angle 2) Initiators that are using the old, crusty, and insecure NTP protocol can have their time hijacked. Angle 2 presents some interesting possibilities. An adversary who sets somebody's time backwards can prevent them from connecting until their time is set right again. Adversaries who set somebody's time forward, say, to the maximum TAI64N value, and then subsequently have an initiator send an initiation message, can then render that initiator's static private key forever useless, since that future timestamp can always be replayed, and will always set the responder's greatest-yet value to that maximum. So, if your NTP is hijacked, your key is forever DoS'd. We've talked about a few solutions before to this. They all have various pitfalls. Idea 0) Insist people don't use NTP but rather some authenticated alternative. Insist people have battery-powered RTCs. Idea 1) Store a monotonic counter on disk, and just increment it by 1, or even some random value bounded far below the limit, on each handshake. The downside is this relies on storage that doesn't wear out and is always available. Idea 2) For a given system boot, store in memory the time of the first handshake, and then increment that timestamp by 1 on each handshake. The problem is figuring out when to sample that initial golden timestamp. And it doesn't actually solve Angle 2, because that initial golden timestamp still might wind up NTP sync'd at some point. Idea 3) Insist people who must use NTP disable large jumps. This has the same issue as Idea 2, in that the bootstrapping timestamp is still an issue. Idea 4) Require the responder to also have a synchronized clock and reject handshakes that are too far into the future. This might alleviate Angle 2 to a large degree but it causes big issues for Angle 1, potentially. Other clever ideas? Jason From karo at cupdev.net Sun Aug 8 16:18:59 2021 From: karo at cupdev.net (Karolin Varner) Date: Mon, 9 Aug 2021 01:18:59 +0200 Subject: [noise] another thread on montonic counter alternatives In-Reply-To: References: Message-ID: <6cd87006-902a-3411-4928-67ec5d1f77e2@cupdev.net> Good evening, I can see this has been copiously discussed… On 8/9/21 12:33 AM, Jason A. Donenfeld wrote: > Angle 2 presents some interesting possibilities. An adversary who sets > somebody's time backwards can prevent them from connecting until their > time is set right again. Adversaries who set somebody's time forward, > say, to the maximum TAI64N value, and then subsequently have an > initiator send an initiation message, can then render that initiator's > static private key forever useless, since that future timestamp can > always be replayed, and will always set the responder's greatest-yet > value to that maximum. So, if your NTP is hijacked, your key is > forever DoS'd. In my view this presents a major problem. I don't have data on this, but I think this is a common setup. Mine was vulnerable and if you didn't take care to prevent this yours is probably too. At the very least there should be a bold, red warning on the webpage "do not use WG with NTP". > Other clever ideas? 0) Just send the value of tsmax to the peer? This basically surmounts to falling back to fully interactive but is a minimal change? 1) Pick a random time stamp/a time stamp based on the peers `MAC(cookie_secret, IP | Port)` and accept that for a single time only. This also basically surmounts to an interactive handshake with minimal changes. Is changing the protocol an option? Two options for that: 2) Fall back to an interactive handshake using cookies. Define a protocol version two, mandate that in V2 the cookie must be mixed into the handshake hash. Assign a cookie in case of timestamp failure. 3) Use a stateless responder; forego the timestamp entirely. Instead of storing the handshake state (ck, h, eskr) locally, they could be encrypted with a random key and included in the second message. This way, there is no responder state an attacker could interrupt. 2) is 1-RTT in the normal case and 2-RTT with the attack agains the counter. 3) is always 1-RTT and always interactive but requires a response for replayed old handshakes. Jason pointed out, that it would be preferable to use a Noise-XK handshake which is a standard fully-interactive handshake but 1.5-RTT. I was assuming 1-RTT-ness was a necessity. Of course, coming up with a new handshake is…generally foolish and even though both my proposal technially fit into the noise-IK pattern, noise-XK certainly is more trustworthy. Noise XK could also be used as a fallback only, but this would considerably increase complexity. As far as mitigations go: a) Do not drop handshake state after three minutes, just ratchet the key `MixKey(empty)` so the attack can not disrupt active sessions. b) Jason's angle 4 but with a flag. A command line switch "interpret counter as timestamp and reject timestamps off by more than 20m". Best, Karolin From trevp at trevp.net Mon Aug 9 17:09:58 2021 From: trevp at trevp.net (Trevor Perrin) Date: Mon, 9 Aug 2021 17:09:58 -0700 Subject: [noise] another thread on montonic counter alternatives In-Reply-To: <6cd87006-902a-3411-4928-67ec5d1f77e2@cupdev.net> References: <6cd87006-902a-3411-4928-67ec5d1f77e2@cupdev.net> Message-ID: On Sun, Aug 8, 2021 at 5:04 PM Karolin Varner wrote: > > 2) Fall back to an interactive handshake using cookies. Define a protocol version two, mandate that in V2 the cookie must be mixed into the handshake hash. Assign a cookie in case of timestamp failure. That could be deployed in a backwards-compatible way, I think? If the client's V1 handshake is rejected due to an old timestamp, the client is given the cookie which enables it to do the V2 handshake? > Jason pointed out, that it would be preferable to use a Noise-XK handshake which is a standard fully-interactive handshake but 1.5-RTT. I was assuming 1-RTT-ness was a necessity. > Of course, coming up with a new handshake is…generally foolish and even though both my proposal technially fit into the noise-IK pattern, noise-XK certainly is more trustworthy. I thought the goal of IK here was: server only stores state if client is authenticated. And the goal of timestamp was: replayed messages can't invalidate an existing session state. If those are still the requirements I'm not sure that XK meets them. XK has better identity hiding (only reveals the client's identity after forward-secrecy is negotiated), but that trades off against the requirement that unauthenticated clients can't cause servers to store state. (Unless you put the state in a cookie, I suppose - which you also suggested...) Trevor From karo at cupdev.net Tue Aug 10 00:53:40 2021 From: karo at cupdev.net (Karolin Varner) Date: Tue, 10 Aug 2021 09:53:40 +0200 Subject: [noise] another thread on montonic counter alternatives In-Reply-To: References: <6cd87006-902a-3411-4928-67ec5d1f77e2@cupdev.net> Message-ID: <4aea0fd6-a37e-3cf5-8df8-79ef119adff6@cupdev.net> On 8/10/21 2:09 AM, Trevor Perrin wrote: > On Sun, Aug 8, 2021 at 5:04 PM Karolin Varner wrote: >> >> 2) Fall back to an interactive handshake using cookies. Define a protocol version two, mandate that in V2 the cookie must be mixed into the handshake hash. Assign a cookie in case of timestamp failure. > > That could be deployed in a backwards-compatible way, I think? If the > client's V1 handshake is rejected due to an old timestamp, the client > is given the cookie which enables it to do the V2 handshake? Yes! I was thinking InitHello with a flag set in the reserved bytes, peer responds with cookie and a compatibility flag set as well. The flag would be ignored by legacy responders, these would also respond with the flag set to zero in cookie replies so the initiator knows not to use V2 when resending InitHello with a cookie. Peers generating messages without a cookie should skip the cookie mixing step (not mix {0}^n) so the message can be processed by legacy peers and modern ones alike. There may be non-standard implementations which assert the reserved bytes to be {0}^3, so sending a one-time-counter using an entirely new packet type might be even more compatible. Such a message would be entirely ignored by all but the worst implementations. Karolin From nadim.kobeissi at outlook.com Tue Aug 10 22:33:33 2021 From: nadim.kobeissi at outlook.com (Nadim Kobeissi) Date: Wed, 11 Aug 2021 05:33:33 +0000 Subject: [noise] Reliability of locally-derived timestamps Message-ID: <427A7098-819C-4DA0-B312-C84C337BF62A@outlook.com> Hi, A separate thread discusses the problem with relying on timestamps as monotonic counters: https://moderncrypto.org/mail-archive/noise/2021/002118.html One of the discussed “angles” as to why timestamps are likely to be unreliable: > Angle 2) Initiators that are using the old, crusty, and insecure NTP > protocol can have their time hijacked.” Karolin Varner supplements discussion on this angle with: > In my view this presents a major problem. I don't have data on this, but I think this is a common setup. There seems to be room for improvement here in terms of empirical data. Is there interest and/or value in obtaining serious data on how big of a problem insecure NTP is, and furthermore to classify the prevalence of insecure NTP (and its impact) in different categories (desktop, mobile, server, etc.) where Noise/WireGuard could be useful? I’d like to understand if such a study could be useful to Noise/WireGuard. Thanks, Nadim Sent from my computer From john at sys.casa Fri Aug 13 13:38:27 2021 From: john at sys.casa (john at sys.casa) Date: Fri, 13 Aug 2021 20:38:27 +0000 Subject: [noise] generated go from noise-explorer uses deprecated point multiplication Message-ID: Hey folks, I was checking out the auto-generated go implementations of various noise protocols on https://noiseexplorer.com/ - really cool site/tool btw. I noticed the generated go code uses a deprecated API for point scalar multiplication. For example; this is the generated dh function for IK: func dh(private_key [32]byte, public_key [32]byte) [32]byte { var ss [32]byte curve25519.ScalarMult(&ss, &private_key, &public_key) return ss } you can see the use of ScalarMult, which is deprecated. https://pkg.go.dev/golang.org/x/crypto at v0.0.0-20210812204632-0ba0e8f03122/curve25519#ScalarMult. curve25519.ScalarBaseMult The go-docs suggest switching from ScalarMult to X25519 - here's a quick reference on what that could look like for `dh` func dh(private_key [32]byte, public_key [32]byte) [32]byte { var ss [32]byte point, _ := curve25519.X25519(public_key[:], private_ key[:]) subtle.ConstantTimeCopy(1, ss[:], point[:32]) return ss } so to summarize; 1) should noise end its usage of the now deprecated x25519.ScalarMult when auto-generating go implementations? 2) where do you make the changes that will affect the autogenerated go code? 3) the low-level api for operating across the ed25519 curve is another solution here - is it worth pondering the tradeoffs in switching entirely to this API? https://github.com/FiloSottile/edwards25519 In response to my own question 3, here are some trade-offs I observed. upsides ======= 1. Constant-time implementations for each curve operation used in IK. 2. Addresses some issues with the inconsistency between implementations of curve/ed 25519. (read more: https://hdevalence.ca/blog/2020-10-04-its-25519am) 3. edwards25519 planned to merge with the internal ed25519 API in go1.17 4. Provides an array of useful extensions/operations for utilization across curve 25519. downsides ========= 1. Fairly significant API change 2. More involved interface that may be inconvenient/unfamiliar to users. 3. Is currently not a go std pkg/module/library. This email us looking to open up a discussion ~ please share your thoughts, whatever they may be :) -- Regards, John S -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - john at sys.casa - 5550f851.asc Type: application/pgp-keys Size: 3179 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 855 bytes Desc: OpenPGP digital signature URL: From yawning at schwanenlied.me Fri Aug 13 14:17:11 2021 From: yawning at schwanenlied.me (Yawning Angel) Date: Fri, 13 Aug 2021 21:17:11 +0000 Subject: [noise] generated go from noise-explorer uses deprecated point multiplication In-Reply-To: References: Message-ID: <4e4c8a98-123f-924a-15d5-c040a921e189@schwanenlied.me> Hello, On 8/13/21 8:38 PM, john at sys.casa wrote: > 1) should noise end its usage of the now deprecated x25519.ScalarMult > when auto-generating go implementations? See 11.1 and 12.1 of the Noise Protocol specification. > 3) the low-level api for operating across the ed25519 curve is another > solution here - is it worth pondering the tradeoffs in switching > entirely to this API? https://github.com/FiloSottile/edwards25519 No. For several reasons. 1) Recent versions of `x/crypto/curve25519` already use that package (If people are wondering why your scalar multiply performance cratered recently after updating their import, this is why). See: https://github.com/golang/crypto/blob/0ba0e8f031222feafe2c6fe04ba9c3da11dd361a/curve25519/curve25519.go#L14 2) That package does not (on it's own) implement u-coordinate only "multiplication". Doing an Ed25519 scalar-point multiply and then converting to Montgomery u-coordinate will be slower than having a dedicated code path. 3) 32-bit performance is awful. > 1. Constant-time implementations for each curve operation used in IK. Huh? `x/crypto/curve25519` has always been constant time. > 2. Addresses some issues with the inconsistency between implementations > of curve/ed 25519. (read more: > https://hdevalence.ca/blog/2020-10-04-its-25519am) Nothing the noise protocol framework does, has anything to do with how Ed25519 verification has many divergent implementations[0]. This is totally irrelevant in the context of noise. > 3. edwards25519 planned to merge with the internal ed25519 API in go1.17 It's internal, and not accessible from normal code. You would need to import Filo's standalone version. > 4. Provides an array of useful extensions/operations for utilization > across curve 25519. I guess you could reuse the scalar and finite field implementations? It doesn't provide much else apart from a way to go from a twisted Edwards point to a u-coordinate... > downsides > ========= > 1. Fairly significant API change If you mean, use the raw field element library, and implement the multiplications that you need by hand, then sure. If you just want to use the library for the sake of using it, then bumping your import does so, without any changes. Don't get me wrong, I like the edwards25519 library, and I've used it for other things. But as far as Noise is concerned, there isn't really a decision to be made here. If the library uses recent `x/crypto/curve25519` then it will be used, if not, it won't. Regards, -- Yawning Angel [0]: Off-topic, if people need to solve the Ed25519 verification behavior issue in, ed25519consensus (implements ZIP-215) and curve25519-voi (implements several variants) exist to solve this. Really, "Just use Ristretto" though. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From nadim.kobeissi at outlook.com Fri Aug 13 15:00:59 2021 From: nadim.kobeissi at outlook.com (Nadim Kobeissi) Date: Fri, 13 Aug 2021 22:00:59 +0000 Subject: [noise] generated go from noise-explorer uses deprecated point multiplication In-Reply-To: <4e4c8a98-123f-924a-15d5-c040a921e189@schwanenlied.me> References: <4e4c8a98-123f-924a-15d5-c040a921e189@schwanenlied.me> Message-ID: Noise Explorer author here. I’ll take a close look at this tomorrow. Thanks for your patience everyone. Nadim Sent from my iPhone > On 13 Aug 2021, at 11:17 PM, Yawning Angel wrote: > > Hello, > >> On 8/13/21 8:38 PM, john at sys.casa wrote: >> 1) should noise end its usage of the now deprecated x25519.ScalarMult >> when auto-generating go implementations? > > See 11.1 and 12.1 of the Noise Protocol specification. > >> 3) the low-level api for operating across the ed25519 curve is another >> solution here - is it worth pondering the tradeoffs in switching >> entirely to this API? https://github.com/FiloSottile/edwards25519 > > No. For several reasons. > > 1) Recent versions of `x/crypto/curve25519` already use that package (If > people are wondering why your scalar multiply performance cratered > recently after updating their import, this is why). See: > https://github.com/golang/crypto/blob/0ba0e8f031222feafe2c6fe04ba9c3da11dd361a/curve25519/curve25519.go#L14 > > 2) That package does not (on it's own) implement u-coordinate only > "multiplication". Doing an Ed25519 scalar-point multiply and then > converting to Montgomery u-coordinate will be slower than having a > dedicated code path. > > 3) 32-bit performance is awful. > >> 1. Constant-time implementations for each curve operation used in IK. > > Huh? `x/crypto/curve25519` has always been constant time. > >> 2. Addresses some issues with the inconsistency between implementations >> of curve/ed 25519. (read more: >> https://hdevalence.ca/blog/2020-10-04-its-25519am) > > Nothing the noise protocol framework does, has anything to do with how > Ed25519 verification has many divergent implementations[0]. This is > totally irrelevant in the context of noise. > >> 3. edwards25519 planned to merge with the internal ed25519 API in go1.17 > > It's internal, and not accessible from normal code. You would need to > import Filo's standalone version. > >> 4. Provides an array of useful extensions/operations for utilization >> across curve 25519. > > I guess you could reuse the scalar and finite field implementations? It > doesn't provide much else apart from a way to go from a twisted Edwards > point to a u-coordinate... > > >> downsides >> ========= >> 1. Fairly significant API change > > If you mean, use the raw field element library, and implement the > multiplications that you need by hand, then sure. If you just want to > use the library for the sake of using it, then bumping your import does > so, without any changes. > > Don't get me wrong, I like the edwards25519 library, and I've used it > for other things. But as far as Noise is concerned, there isn't really > a decision to be made here. If the library uses recent > `x/crypto/curve25519` then it will be used, if not, it won't. > > Regards, > > -- > Yawning Angel > > [0]: Off-topic, if people need to solve the Ed25519 verification > behavior issue in, ed25519consensus (implements ZIP-215) and > curve25519-voi (implements several variants) exist to solve this. > Really, "Just use Ristretto" though. > > _______________________________________________ > Noise mailing list > Noise at moderncrypto.org > https://moderncrypto.org/mailman/listinfo/noise From yawning at schwanenlied.me Fri Aug 13 15:34:45 2021 From: yawning at schwanenlied.me (Yawning Angel) Date: Fri, 13 Aug 2021 22:34:45 +0000 Subject: [noise] generated go from noise-explorer uses deprecated point multiplication In-Reply-To: References: <4e4c8a98-123f-924a-15d5-c040a921e189@schwanenlied.me> Message-ID: On 8/13/21 10:00 PM, Nadim Kobeissi wrote: > Noise Explorer author here. I’ll take a close look at this tomorrow. Thanks for your patience everyone. There really isn't much to look at. The new API is more ergonomic, but forces contributory behavior by checking if the output is a low-order point, and spits out an error. RFC 7748 has this check as a MAY. The noise spec prefers not having the check (which is what the deprecated API does). As an aside, I misspoke about the parts of the spec, dummy psks don't have anything to do with this, Sorry it's been a while since I've thought about this. I seem to vaguely recall years ago, some explicit use case that involved sending the neutral element, but I might just be confused. Regards, -- Yawning Angel -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From nadim.kobeissi at outlook.com Sat Aug 14 00:23:48 2021 From: nadim.kobeissi at outlook.com (Nadim Kobeissi) Date: Sat, 14 Aug 2021 07:23:48 +0000 Subject: [noise] generated go from noise-explorer uses deprecated point multiplication In-Reply-To: References: <4e4c8a98-123f-924a-15d5-c040a921e189@schwanenlied.me> Message-ID: Hello everyone, I’ve looked through the exchange between John and Yawning and I understand the issue better now. A look at ScalarMult indicates that Yawning is correct: its deprecation has to do entirely with ensuring “contributory behavior” to mitigate for low-order points. To quote: "Deprecated: when provided a low-order point, ScalarMult will set dst to all zeroes, irrespective of the scalar. Instead, use the X25519 function, which will return an error.” [1] I agree with Yawning that if this is the only reason for the deprecation of ScalarMult, then no change should be made to the current Go-generated Noise Explorer code. This is for two reasons: 1. RFC 7748 marks the low-order point check as optional. 2. Trevor has repeatedly expressed his opinion which seems to oppose APIs which return errors on low-order points. So this should be Trevor’s call and not mine. However there is still one important concern. The common definition of “deprecation” in the context of software engineering seems to include the possibility that the deprecated functionality will be removed entirely in future software updates. [2] It would be good if Filippo (who `git blame` indicates is responsible for this deprecation in 2019 [3]) could shed light on whether ScalarMult is scheduled for removal in the future. In that case, there would need to be some alternative code to the Go crypto API such that the low-order point check could be bypassed in order to keep with the current targeted behavior for Noise Handshake Pattern implementations. Or, alternatively, Trevor would validate that low-order point checks are not anathema to the intended behavior of Noise Handshake Pattern implementations. Have a good week-end, Nadim Sent from my computer References: [1] https://github.com/golang/crypto/blob/master/curve25519/curve25519.go#L19-L21 [2] https://docs.oracle.com/javase/8/docs/technotes/guides/javadoc/deprecation/index.html [3] https://github.com/golang/crypto/commit/f4817d981bb690635456c5c1c6aa0585e5d45891 > On 14 Aug 2021, at 12:34 AM, Yawning Angel wrote: > > On 8/13/21 10:00 PM, Nadim Kobeissi wrote: >> Noise Explorer author here. I’ll take a close look at this tomorrow. Thanks for your patience everyone. > There really isn't much to look at. The new API is more ergonomic, but > forces contributory behavior by checking if the output is a low-order > point, and spits out an error. RFC 7748 has this check as a MAY. The > noise spec prefers not having the check (which is what the deprecated > API does). > > As an aside, I misspoke about the parts of the spec, dummy psks don't > have anything to do with this, Sorry it's been a while since I've > thought about this. I seem to vaguely recall years ago, some explicit > use case that involved sending the neutral element, but I might just be > confused. > > Regards, > > -- > Yawning Angel > > _______________________________________________ > Noise mailing list > Noise at moderncrypto.org > https://moderncrypto.org/mailman/listinfo/noise From filippo at ml.filippo.io Sat Aug 14 02:36:10 2021 From: filippo at ml.filippo.io (Filippo Valsorda) Date: Sat, 14 Aug 2021 11:36:10 +0200 Subject: [noise] =?utf-8?q?generated_go_from_noise-explorer_uses_deprecat?= =?utf-8?q?ed_point_multiplication?= In-Reply-To: References: <4e4c8a98-123f-924a-15d5-c040a921e189@schwanenlied.me> Message-ID: <81bb0b27-d88b-48d6-b138-1a626a381126@www.fastmail.com> _o/ We don't remove deprecated APIs. x/crypto follows the Go 1 Compatibility Promise. See https://golang.org/wiki/Deprecated. Indeed, this deprecation is due mostly to contributory behavior. The X25519 APIs have been discussed at length, so I won't rehash the debate, but I'll mention that there were real-world security vulnerabilities due to the old API behavior. Note that the Noise spec has the equivalent of a MAY for checking low order points: > Alternatively, implementations are allowed to detect inputs that produce an all-zeros output and signal an error instead. This behavior is discouraged because it adds complexity and implementation variance, and does not improve security. This behavior is allowed because it might match the behavior of some software. > https://noiseprotocol.org/noise.html#the-25519-dh-functions The new API also uses slices, which is generally more ergonomic, saves copies of secret material, and most importantly avoids silently copying a short buffer into a fixed size array. All in all, a Noise implementation is probably going to be fine with either. 2021-08-14 09:23 GMT+02:00 Nadim Kobeissi : > Hello everyone, > > I’ve looked through the exchange between John and Yawning and I understand the issue better now. > > A look at ScalarMult indicates that Yawning is correct: its deprecation has to do entirely with ensuring “contributory behavior” to mitigate for low-order points. To quote: "Deprecated: when provided a low-order point, ScalarMult will set dst to all zeroes, irrespective of the scalar. Instead, use the X25519 function, which will return an error.” [1] > > I agree with Yawning that if this is the only reason for the deprecation of ScalarMult, then no change should be made to the current Go-generated Noise Explorer code. This is for two reasons: > 1. RFC 7748 marks the low-order point check as optional. > 2. Trevor has repeatedly expressed his opinion which seems to oppose APIs which return errors on low-order points. So this should be Trevor’s call and not mine. > > However there is still one important concern. The common definition of “deprecation” in the context of software engineering seems to include the possibility that the deprecated functionality will be removed entirely in future software updates. [2] It would be good if Filippo (who `git blame` indicates is responsible for this deprecation in 2019 [3]) could shed light on whether ScalarMult is scheduled for removal in the future. In that case, there would need to be some alternative code to the Go crypto API such that the low-order point check could be bypassed in order to keep with the current targeted behavior for Noise Handshake Pattern implementations. Or, alternatively, Trevor would validate that low-order point checks are not anathema to the intended behavior of Noise Handshake Pattern implementations. > > Have a good week-end, > > Nadim > Sent from my computer > > References: > [1] https://github.com/golang/crypto/blob/master/curve25519/curve25519.go#L19-L21 > [2] https://docs.oracle.com/javase/8/docs/technotes/guides/javadoc/deprecation/index.html > [3] https://github.com/golang/crypto/commit/f4817d981bb690635456c5c1c6aa0585e5d45891 > > > On 14 Aug 2021, at 12:34 AM, Yawning Angel wrote: > > > > On 8/13/21 10:00 PM, Nadim Kobeissi wrote: > >> Noise Explorer author here. I’ll take a close look at this tomorrow. Thanks for your patience everyone. > > There really isn't much to look at. The new API is more ergonomic, but > > forces contributory behavior by checking if the output is a low-order > > point, and spits out an error. RFC 7748 has this check as a MAY. The > > noise spec prefers not having the check (which is what the deprecated > > API does). > > > > As an aside, I misspoke about the parts of the spec, dummy psks don't > > have anything to do with this, Sorry it's been a while since I've > > thought about this. I seem to vaguely recall years ago, some explicit > > use case that involved sending the neutral element, but I might just be > > confused. > > > > Regards, > > > > -- > > Yawning Angel > > > > _______________________________________________ > > Noise mailing list > > Noise at moderncrypto.org > > https://moderncrypto.org/mailman/listinfo/noise > > _______________________________________________ > Noise mailing list > Noise at moderncrypto.org > https://moderncrypto.org/mailman/listinfo/noise > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nadim.kobeissi at outlook.com Sat Aug 14 03:51:53 2021 From: nadim.kobeissi at outlook.com (Nadim Kobeissi) Date: Sat, 14 Aug 2021 10:51:53 +0000 Subject: [noise] generated go from noise-explorer uses deprecated point multiplication In-Reply-To: <81bb0b27-d88b-48d6-b138-1a626a381126@www.fastmail.com> References: <4e4c8a98-123f-924a-15d5-c040a921e189@schwanenlied.me> <81bb0b27-d88b-48d6-b138-1a626a381126@www.fastmail.com> Message-ID: Ah, I had indeed forgotten about the Go 1 Compatibility Promise and it’s good to see Go’s own deprecation policy page, which is a more relevant reference than the random other one from another programming language that I found on Google Search. Thanks for this clarification; this likely settles the issue (at least until Go 2: Attack of the Gopher). Nadim Sent from my iPad On 14 Aug 2021, at 11:36 AM, Filippo Valsorda wrote:  _o/ We don't remove deprecated APIs. x/crypto follows the Go 1 Compatibility Promise. See https://golang.org/wiki/Deprecated. Indeed, this deprecation is due mostly to contributory behavior. The X25519 APIs have been discussed at length, so I won't rehash the debate, but I'll mention that there were real-world security vulnerabilities due to the old API behavior. Note that the Noise spec has the equivalent of a MAY for checking low order points: > Alternatively, implementations are allowed to detect inputs that produce an all-zeros output and signal an error instead. This behavior is discouraged because it adds complexity and implementation variance, and does not improve security. This behavior is allowed because it might match the behavior of some software. > https://noiseprotocol.org/noise.html#the-25519-dh-functions The new API also uses slices, which is generally more ergonomic, saves copies of secret material, and most importantly avoids silently copying a short buffer into a fixed size array. All in all, a Noise implementation is probably going to be fine with either. 2021-08-14 09:23 GMT+02:00 Nadim Kobeissi >: Hello everyone, I’ve looked through the exchange between John and Yawning and I understand the issue better now. A look at ScalarMult indicates that Yawning is correct: its deprecation has to do entirely with ensuring “contributory behavior” to mitigate for low-order points. To quote: "Deprecated: when provided a low-order point, ScalarMult will set dst to all zeroes, irrespective of the scalar. Instead, use the X25519 function, which will return an error.” [1] I agree with Yawning that if this is the only reason for the deprecation of ScalarMult, then no change should be made to the current Go-generated Noise Explorer code. This is for two reasons: 1. RFC 7748 marks the low-order point check as optional. 2. Trevor has repeatedly expressed his opinion which seems to oppose APIs which return errors on low-order points. So this should be Trevor’s call and not mine. However there is still one important concern. The common definition of “deprecation” in the context of software engineering seems to include the possibility that the deprecated functionality will be removed entirely in future software updates. [2] It would be good if Filippo (who `git blame` indicates is responsible for this deprecation in 2019 [3]) could shed light on whether ScalarMult is scheduled for removal in the future. In that case, there would need to be some alternative code to the Go crypto API such that the low-order point check could be bypassed in order to keep with the current targeted behavior for Noise Handshake Pattern implementations. Or, alternatively, Trevor would validate that low-order point checks are not anathema to the intended behavior of Noise Handshake Pattern implementations. Have a good week-end, Nadim Sent from my computer References: [1] https://github.com/golang/crypto/blob/master/curve25519/curve25519.go#L19-L21 [2] https://docs.oracle.com/javase/8/docs/technotes/guides/javadoc/deprecation/index.html [3] https://github.com/golang/crypto/commit/f4817d981bb690635456c5c1c6aa0585e5d45891 > On 14 Aug 2021, at 12:34 AM, Yawning Angel > wrote: > > On 8/13/21 10:00 PM, Nadim Kobeissi wrote: >> Noise Explorer author here. I’ll take a close look at this tomorrow. Thanks for your patience everyone. > There really isn't much to look at. The new API is more ergonomic, but > forces contributory behavior by checking if the output is a low-order > point, and spits out an error. RFC 7748 has this check as a MAY. The > noise spec prefers not having the check (which is what the deprecated > API does). > > As an aside, I misspoke about the parts of the spec, dummy psks don't > have anything to do with this, Sorry it's been a while since I've > thought about this. I seem to vaguely recall years ago, some explicit > use case that involved sending the neutral element, but I might just be > confused. > > Regards, > > -- > Yawning Angel > > _______________________________________________ > Noise mailing list > Noise at moderncrypto.org > https://moderncrypto.org/mailman/listinfo/noise _______________________________________________ Noise mailing list Noise at moderncrypto.org https://moderncrypto.org/mailman/listinfo/noise _______________________________________________ Noise mailing list Noise at moderncrypto.org https://moderncrypto.org/mailman/listinfo/noise -------------- next part -------------- An HTML attachment was scrubbed... URL: