Kalmar

The MRL discussed finalizing the post-quantum encryption variant for the Jamtis address scheme. After comparing options in the provided table (AC1024, BC512, AN509 etc.), there was general support for proceeding with Jamtis-AC1024 due to its strong security margin, reasonable performance impact on scan times and pruned tx sizes, and privacy properties. Concerns around BC512 (higher scan time, lower relative security) and alternatives like NTRU variants or PEGASIS/CSURF were addressed. LWS compatibility and view tag handling (including change outputs) were clarified with additional symmetric secrets. No major objections; tevador to decide on next steps for R&D. rucknium: 4. Post-quantum encryption (#issuecomment-4412416686" target="_blank" rel="nofollow noopener">github.com/monero-project…). tevador: The goal for today is to hopefully make a final decision on the PQ encryption variant for Jamtis. See the table in the linked comment for details. tevador: Any objections to going forward with Jamtis-AC1024? rucknium: "Monero adopts a PQ protocol" = Resistance to PQ counterfeiting and theft, right? sgp_: None from me. Just to clarify, AC512 isn't considered because it doesn't offer meaningful efficiency compared to AC1024 right? The extra margin is cheap in this case? gingeropolous: is the argument against BC512 mainly the 5x scan time? tevador: rucknium: Yes, that has to be adopted before Q-Day. jberman: I think it's worth noting that clients would have to download the pruned tx data, so mobile scan time (which is presently usually bottlenecked by download speeds via remote daemons) would increase from pruned tx sizes as well rucknium: tevador, how confident are you that CSIDH-1024 won't be broken for 60 years? jberman: I note this because Jamtis-AN509 looks pretty attractive in that table as well, but when considering the 4.35x pruned tx size impact on mobile wallets, it's harder to swallow tevador: I'm fairly confident about CSIDH-1024. gingeropolous: because "Alice received an enote in tran. X." vs. "Alice might have received an enote in tran. X." seems like quite the difference tevador: There are 2 arguments against BC512: 1. Scan time 2. (in-)security jberman: All things considered, I +1 that Jamtis-AC1024 is the strongest option on this table here as a positive incremental step forward toward improved PQ privacy tevador: Although even BC512 is likely good for ~20 years longer than Curve25519 sgp_: gingeropolous: the key distinction is that you can't continue using that information to discover transactions where those outputs might be spent. That significantly mitigates the privacy downside articmine: 2 security is a concern for me jpk68: Would AN509 allow for a non-interactive protocol like CSIDH would? gingeropolous: 2^60 vs 2^72 ? tevador: Yes, AC1024 and AN509 are functionally almost equivalent, except AN509 loses privacy if the address generator tier is compromised, AC1024 does not. tevador: Yes, 2^72 is 4096 times harder to break (actually more due to practical reasons) than 2^60. gingeropolous: yeah 20 vs 50 yrs as in your scenario. though part of me is attracted to the 20 b/c it keeps the fire lit. 50 years ppl can handwaive "its fine......" tevador: The choice is either high privacy for 20 years and then none vs medium privacy for 50 years and then none. jberman: We have to deal with PQ to prevent hidden inflation, so the timeline is sooner than 20 years regardless jeffro256: Besides the fact that it still doesn't hide the social graph with timing information? I have a feeling that with all these variations, our addressing protocol suite might end up like TLS: many different modular cryptographic components with one overarching generalized architecture jberman: and can't really be handwaved rbrunner: I guess there are no variants of NTRU-509 that are bit less heavy, but still quite attractive? NT-300 or whatever ... rbrunner: NTRU-300 tevador: No, the security of lattices drops very fast, NTRU-300 would be completely insecure. sgp_: I was initially drawn to the "flashy" privacy of BC over AC, but in practice it's a high extra cost (and in practice, a lower security margin) to provide better privacy only in a specific edge case, at least that's how I currently view it jeffro256: So are we disabling LWS for AC1024? jeffro256: Or we send s_vv to the LWS ? jeffro256: s_vb tevador: No, LWS will work independently of the PQ encryption layer. jeffro256: Okay so primary vt is still PQ insecure right ? tevador: The expensive CSIDH-1024 calculation kicks in after a 24-bit view tag match, which is a relatively managable amount of CPU time. tevador: For AC1024, the whole view tag is classical. For BC512, the secondary view tag is PQ. gingeropolous: yeah i can get behind AC1024 tevador: gingeropolous: Can you elaborate? gingeropolous: i mean the arguments for it vs. the bc512 make sense. jeffro256: So if both secondary and primary view tags are not hidden from a QA, then the social graph is revealed with extremely high probability , getting exponentially higher the more interactions b/t 2 entities gingeropolous: i think either are probably fine, if we're going to bolt on a PQ preventative thing, based on whats been presented to my feeble brain tevador: jeffro256: How so? The QA can find received enotes, but cannot locate outgoing payments. sgp_: this is minimized because they need to know what address to check to see if it received funds, right? tevador: Yes, the all this assumes that your Jamtis address is known to the attacker and the attacker is not the sender. jeffro256: tevador: They can locate view tags for change enotes , and all outgoing txs must have a change enote even if change amount is 0 tevador: No, view tags for change enotes are calculates with symmetric crypto, which is PQ-proof. sgp_: Even if they weren't, you could use a different change address jeffro256: Then LWS cannot find change enotes for AC1024 . Thats fine if that's the tradeoff we want to take , but that should be noted tevador: LWS can locate the enotes, because users will give the LWS server their symmetric secret for internal view tags. jeffro256: Oh , but a different symmetric secret from s_vb? tevador: Yes, a single purpose secret, s_fa tevador: #43-additional-keys" target="_blank" rel="nofollow noopener">gist.github.com/tevador/639d08… rbrunner: Can't ever have too many keys and secrets :) jeffro256: Ah interesting , I didn't see that in the updated spec, sorry. Interesting . so now there's 3 scan paths jeffro256: Yeah that could work koe000: jeffro255: we discussed it a few weeks ago in here, maybe you forgot jeffro256: In that case, I think AC1024 is a decent choice jeffro256: Given the performance of better privacy options neptunian: Yeah. Given it's sufficiently strong and still PQ with reasonable overhead, I'd choose AC1024. jeffro256: Yes I do remember discussing , but I guess I didn't quite get that we were talking about slightly different things rucknium: We should probably move to the next item. I will leave it to tevador to decide whether the discussion today is enough to go forward with AC1024 R&D or if even more discussion is needed. neptunian: I do have a question about BC1024 and related. neptunian: We already sort of concluded that performance overhead for it is entirely undesirable (see #issuecomment-4412416686" target="_blank" rel="nofollow noopener">github.com/monero-project…), however, I would like to know if PEGASIS or CSURF would make this at all feasible. neptunian: I'm just curious as to whether or not this would be viable after both variants receive more scrutiny. neptunian: I don't have much else to add here since most topics seem to have been covered. I'm just throwing out a curiosity I have. tevador: CSUDH-1024 performs the same as CSIDH-1024 and PEGASIS is not much faster and only has a proof of concept, far from practically usability. tevador: CSURF-1024 tevador: From the PEGASIS paper: Our implementation in SageMath takes 1.5s to compute a group action at the CSIDH-512 security level, 21s at CSIDH-2048 level and around 2 minutes at the CSIDH-4096 level #c674935" target="_blank" rel="nofollow noopener">libera.monerologs.net/monero-researc…