<rucknium> MRL meeting in this room in two hours.

<syntheticbird> i want it now

<kayabanerve:matrix.org> I may or may not be present but my update is monero-oxide/monero-oxide cba7117

<kayabanerve:matrix.org> I did the initial changes to indexing instructed by CS's latest commentary, and merged the performance fixes jberman wanted. I have to do a complete side-by-side review to confirm there's no other discrepancies/deviations, but that should model the performance hit and be usable for that evaluation.

<kayabanerve:matrix.org> I'm sure @sgp_:monero.social: can provide commentary on the being-discussed audits to follow up.

<gingeropolous> i won't be present, my update is the final 5% of monerosim. some issue where the particular launch order of activity causes some wallets to not send, while others send tons of txs.

<rucknium> Meeting time! monero-project/meta #1368

Hi

<jpk68:matrix.org> Hello

<rucknium> 1. Greetings

<vtnerd> Hi

<iamnew117:matrix.org> Hello

<rucknium> 2. Updates. What is everyone working on?

Hi

<jberman> waves

Me: finished carrot_core review, wrote seraphis-migration/monero #310, likely to look at multisig next (blocking hf afaik)

<jberman> Reviewing upstream PR's, rebased seraphis-migration/monero #89 , FCMP++ audit tasks

<jpk68:matrix.org> I've been doing a bit of preliminary research on SAM protocol parameters, namely signature and encryption types for destinations

<jpk68:matrix.org> Can elaborate if anyone is interested

<kayabanerve:matrix.org> I posted my update prior re: the Generalized Bulletproofs.

<vtnerd> me: lws+lwsf are up-to-date with fcmp++/carrot and working on testing /feed protocol this week

<rucknium> 3. FCMP code integration audit overview (seraphis-migration/monero #294).

<jberman> We're engaged in discussions with a number of candidates for Phase 1. From the quotes we've received and candidates we've spoken to, we feel $50k is a sound budget for this phase. I've also opened a CCS requesting ~$150k budgeted for all 3 phases here: repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/663

<jberman> AFAIK, we should have all quotes by next week's meeting

<rucknium> Anything more on this item?

<jberman> Nothing from me

<rucknium> 4. FCMP beta stressnet (seraphis-migration/monero #166).

<rucknium> AFAIK, this update from @kayabanerve:matrix.org is about beta stressnet readiness progress: monero-oxide/monero-oxide cba7117

<articmine> Sorry I am late

<rucknium> "I did the initial changes to indexing instructed by CS's latest commentary, and merged the performance fixes jberman wanted. I have to do a complete side-by-side review to confirm there's no other discrepancies/deviations, but that should model the performance hit and be usable for that evaluation."

<rucknium> CS = Cypher Stack.

<jberman> kayaba notes those 2 issues highlighted in that commit description are also now immediate blockers, and I pinged Diego on that as well

<jberman> So the main blocking items there are now 1) a response to those raised issues, and 2) kayaba's complete review

<jberman> I can also check the perf hit today/tomorrow

<jberman> W.r.t. beta stressnet, yep this is the final blocking task

<jberman> Would like this item settled before launching

<rucknium> 5. Grease Payment Channels (repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/651).

<rucknium> More discussion on Grease?

<syntheticbird> Greasus christ when are we going to have a payment channel 🥁

<rucknium> 6. Discussion: Post-quantum security and ethical considerations over elliptic curve cryptography (monero-project/research-lab #131). Safeguarding cryptocurrency by disclosing quantum vulnerabilities responsibly (research.google/blog/safeguarding-c…quantum-vulnerabilities-responsibly).

lol -- I've still writing up the distributed KEs ideas. Been a bit tied up with easter holidays and things the last few days

still confident I'll get it out this week

<rucknium> code2: Thanks

<syntheticbird> Ever since the last comment of this issue and the discussion about economical safety during the MRL meeting there has been discussion about jamtis and carrot.

<syntheticbird> ngl a recap about what where we are on PQ discussion would be greatly appreciated

<syntheticbird> from what i remember, adding turnstile support was on the table for carrot

tevador is working on a Jamtis-PQ spec. The PQ aspect would be aimed at forward secrecy in case of a future quantum adversary. PQ tx protocol sounds infeasible with current quantum crypto.

Carrot PQ forward secrecy: github.com/jeffro256/carrot/blob/ma…address-conditional-forward-secrecy

<semisimple> After looking a bit into the quantum topic, it seems to me it is a really tough nut to crack. Almost all PQC schemes have extremely large address and signature sizes that it becomes really tough to implement into a blockchain that is targeting a high number of transactions. Even full quantum blockchains like QRL without much privacy are not really efficient

Jamtis-PQ aims to close this last privacy gap (forward secrecy if an address is known)

Jamtis-PQ will feature CSIDH-1024 for quantum-resistant public key encryption

<semisimple> UkoeHB: I would be interested how that would look like. Is there a draft or do you want to wait until it is finished?

<syntheticbird> I thought isogeny based public cryptosystem were broken during the NIST competition ?

It's work in progress

syntheticbird: the break of SIKE/SIDH has no effect on CSIDH, which is a different cryptosystem

<jpk68:matrix.org> Is CSURF still being considered?

<syntheticbird> tevador: ack.

semisimple: I am not working on it, tevador is.

Yes, the selected parameters are sort of a CSURF variant

Details here (this will be part of the Jamtis-PQ specs): monero-project/research-lab #151#issuecomment-3640488509

<syntheticbird> If I understand correctly the last tech meeting. Their is advocacy for skipping the new carrot key hierarchy for the upcoming HF and push towards deploying Jamtis-PQ after that? is that correct?

A limitation of Jamtis-PQ is that the view tag is still calculated using traditional ECDH, so a quantum attacker will be able to locate e-notes, but not decrypt them.

syntheticbird: that's what I have advocated. No one else has commented yay or nay.

<jberman> tevador: what are your thoughts on contracting a research firm to explore a maximally efficient complete PQ protocol?

jeffro256 should comment on that

jberman: I think kayabanerve made some estimates around ~500 KB per transaction for a full PQ protocol

<semisimple> I have no credibility, but in my opinion the quantum threat is indeed not to be underestimated even though it is probably still a bit in the future. I consider any effort and funds to be well spent.

Probably some work should start on this front, but I'm skeptical anything practical will come up. There was a RingCT-like PQ protocol published a while ago that had ~100 KB transactions.

<jberman> tevador: "and being a couple years old, is lacking my current knowledge and more modern developments" presumably there may be further developments on that front

Can RingCT or FCMP++ not be translated 1:1 to a PQ scheme?

<kayabanerve:matrix.org> I don't think there's a clear path to decentralizing Grease and I'm unclear about the benefit of middle-man-premised payment channel technology

<kayabanerve:matrix.org> I'm interested to see JAMTIS-PQ (or any other such scheme) following the FCMP++ upgrade.

<syntheticbird> ukoehb what do you mean

UkoeHB: probably something based on STARKS, which are hash based, so PQ proof.

<syntheticbird> oh wait nvm i just understand

<kayabanerve:matrix.org> FCMP++ is premised as a composition of membership, spend-auth + linkability, balance, and range. I did chicken scratch on a PQ composition a couple year ago, suggesting something approximate to Bitcoin's P2PKH.

<kayabanerve:matrix.org> Specifically, I noted on a specific additively-homomorphic commitment scheme (Ajtai?) be used for all computational purposes, yet the current output key be replaced with a 32-byte Blake2 hash or similar, in order to achieve succinct outputs and likely addresses as well. All unpacking would be deferred to the inputs.

tevador: if hashes are required, why would CSIDH key exchange work? Perhaps I should just read up on it.

<kayabanerve:matrix.org> The clearest way to achieve the ~5 goals of a private payment protocol is yes, to take the rock-solid FRI with conservative parameters and call it a day. Ideally, the choice of hashes and commitments used are sufficiently forward-thinking to enable more efficient proofs in the future.

There is no hash-based post-quantum key exchange protocol. Hash-based protocols are only for proofs and signatures.

<kayabanerve:matrix.org> There are more specific proofs we could discuss the application ol for each and every component. That discussion would be poor due to how involved it'd be and the fact we aren't currently investing that involvement (even if we should be).

<jbabb:cypherstack.com> I have seen these recently tho haven't had time to digest them

<jbabb:cypherstack.com> SHRIMPS: 2.5 KB post-quantum signatures across multiple stateful devices delvingbitcoin.org/t/shrimps-2-5-kb…ross-multiple-stateful-devices/2355

<jbabb:cypherstack.com> see also the similar SHRINCS: 324-byte stateful post-quantum signatures with static backups324-byte stateful post-quantum signatures with static backups delvingbitcoin.org/t/shrincs-324-by…signatures-with-static-backups/2158

<jbabb:cypherstack.com> ofc not applicable to us but interesting comparison points

<kayabanerve:matrix.org> Hash-based signatures, such as SHRINCS presumable is by the name, almost certainly cannot be used by Monero.

tevador: I guess I'm confused how you can do a key exchange but can't do a signature.

<kayabanerve:matrix.org> Monero needs a non-interactive re-randomizable signature scheme, and I'd say one which reasonably supports arbitrary threshold schemes while remaining indistinguishable.

With EC-like operations.

<kayabanerve:matrix.org> A hash-based scheme wouldn't achieve re-randomization.

It's the opposite. With hashes, you can do a signature, but can't do key exchange. You need CSIDH or lattices for key exchange.

<kayabanerve:matrix.org> ... wouldn't offer?

<kayabanerve:matrix.org> ... wouldn't enable?

<kayabanerve:matrix.org> Ugh. Or you use a non-rerandomizable signature scheme, but you do the signature transparently, then publish a ZK proof that a valid signature exists (without revealing which public key was associated) D: Such a mess to consider.

Yes, if we want to keep stealth addresses, then it has so be something lattice-based.

Can you use CSIDH or lattices for signatures? Or is it just prohibitively expensive?

<kayabanerve:matrix.org> Here's my extremely-limited chicken scratch from a couple years ago. I started the notes right as I hit my burn out: github.com/kayabaNerve/monero-pq

CSIDH can do plain signatures, but not the kind Monero needs.

<kayabanerve:matrix.org> Note it can be criticized to all hell for its addressing proposal and it was never meant to be an address proposal like JAMTIS. It was meant to be a very basic draft of modularity and composition to enable discussing and scoping individual sections, while any actual development would be on a dead-simple, slow af, giant, FRI-ba [... too long, see mrelay.p2pool.observer/e/j53ivfcKTDZMQ1Q0 ]

I will look into that. It would be odd to me for plain signatures to work, but not e.g. RingCT.

<kayabanerve:matrix.org> I wouldn't be surprised about how one couldn't re-randomize an isogeny map

<kayabanerve:matrix.org> tevador: Maybe a code-based signature?

<kayabanerve:matrix.org> Not to say we should move to code-based cryptography, to say I don't believe we are explicitly limited to lattices. I'd assume, at this time, we'd be limited to lattices or codes.

<kayabanerve:matrix.org> Lattices are the most likely candidate for good performance across all proofs, but any LWE-premised proofs are going to be hell to put into a multisignature protocol unless the signature scheme was explicitly designed with that in mind (such as Raccoon)

<rucknium> 7. More Jamtis features in Carrot (seraphis-migration/monero #310).

Anyways... The roadmap is: 1) FCMP++/Carrot 2) Jamtis-PQ (for full PQ privacy, but not soundness. 3) Some full PQ protocol.

<kayabanerve:matrix.org> 👍️

The proposal is not to ship the Carrot key hierarchy with FCMP++

<kayabanerve:matrix.org> I don't believe that was planned at this time

I'm quoting #310

<kayabanerve:matrix.org> And I'm noting I think that specific comment is already the plan, in case someone wants to correct me or further explain any distinction

<syntheticbird> a counter argument to this proposal, carrot self-enote are symmetrically encrypted and do provide some level of QC protection. This is minimal but can be used by people right now to mitigate damage from future decryption. If we remove the new hierarchy for jamtis PQ we're removing this capability and we do not have any guarantee on when Jamtis-PQ will be shipped

<syntheticbird> hell, some would fcmp++ would be on mainnet by now

<jberman> there have been some discussions about bringing the Carrot key hierarchy in with the fork. I'm personally in favor of shipping after so as to not delay the fork

Any delay to FCMP++ means more transactions that WILL be fully deanonymized in the future.

I think the wallet-side work will be significantly reduced if we stick to the legacy hierarchy for the fork.

<rucknium> UkoeHB: Do you have more comments now about "More Jamtis features in Carrot"?

I think it became "Fewer Jamtis features in Carrot"

<rucknium> Any more discussion on this item?

<jberman> (btw I have another agenda item to raise, apologies for the late addition)

What is planned for the fork (AFAIK): Janus attack mitigation, forward secret key images and full chain membership set.

<rucknium> @jberman:monero.social: You can raise it.

The proposal is to never ship the Carrot key hierarchy, not to do it after.

<jberman> Back in June 2024, Aaron (Sarang) completed a security review of the FCMP++ composition at Cypher Stack. @UkoeHB recently raised that that report didn't have a follow-up formal review, and I figured it would make sense to have Cypher Stack conduct such a review because they have a new team that has also identified issues in th [... too long, see mrelay.p2pool.observer/e/vqGmvvcKakJZMjZa ]

<jberman> If at all possible, would love to get MRL sign-off on this. I apologize for not raising this further in advance (health complications got in the way).

<syntheticbird> (may the good health be with you)

<jberman> The report: github.com/cypherstack/fcmp-review/releases

More reviews can't hurt if it's done in parallel with other work.

Sounds good to me

<articmine> I support this review

I also proposed an audit for tevador's mx25519 crate.

<rucknium> We had a "rule" to post proposals for spending from the FCMP research fund at least 24-48 hours before the MRL meeting for final approval. This review seems very reasonable, but is it possible to follow the rule? Will a lot of time be lost if we wait a week?

<jberman> UkoeHB: Ya I think that one is worth a distinct CCS, just need to follow through on it

<jberman> @rucknium: At worst we lose a week + possibly availability with CS for other work at a later time, so it could compound a bit

<jberman> Imo this would be a low risk, relatively low cost, solid value item to bang out

<rucknium> What do others think? Follow the rule in this case or no?

<syntheticbird> rules are meant to be broken

<syntheticbird> idk something inspirational like that yk what i mean

<rucknium> @syntheticbird:monero.social: That phrase came up in my head too 🙂

<articmine> Given the lack of opposition there is a case for making an exception

<rucknium> We'll make an exception. More discussion of this proposal? Any objections or reservations?

<jberman> I'll highlight a comment shared by kayaba that it's CS conducting a review of CS, rather than an independent party

<syntheticbird> nope

<jberman> My contention is that since this is essentially a new team that has demonstrably identified issues in existing work (their GPB follow-up), that they are close to de facto independent / worthy of the task

<kayabanerve:matrix.org> I'm not opposed to the follow-up composition review

<rucknium> @jberman:monero.social: I agree. What would be an alternative? Another firm doing a review?

<sgp_> I'm not opposed for the price

<kayabanerve:matrix.org> In an ideal sense, though I don't think CS actually represents a conflict

<jberman> @rucknium: yep

<rucknium> What delicate parts of the protocol would this review hit?

<rucknium> In other words, what could go wrong if a review misses something?

<kayabanerve:matrix.org> This will primarily cover the interoperability between the membership and SA+L proof, and the SA+L proof itself

<rucknium> @kayabanerve:matrix.org and @sgp_:monero.social : Neither of you are in favor, just "not opposed"? Is that correct?

<kayabanerve:matrix.org> I honestly don't care and effectively see it as a "why not" at an acceptable price, to be blunt

<kayabanerve:matrix.org> Can't hurt, cheap enough it's probably worth it for peace of mind, but I already have peace of mind and don't care accordingly

<kayabanerve:matrix.org> That's why I said I'm not opposed and am effectively kicking the advocacy to jberman, though others hear also seemed to think it worthwhile

<rucknium> The price is good. Makes it easier to approve.

<kayabanerve:matrix.org> *others here

<sgp_> @rucknium: Ideally multiple firms would be solicited but for the price I'm not concerned, basically

<sgp_> More solicitations for this is likely to be a waste of everyone's time

<rucknium> I'm seeing some in favor and some "not opposed". No one opposed. I think that's reaches the threshold to proceed with it.

<genoce:matrix.org> > <@syntheticbird> a counter argument to this proposal, carrot self-enote are symmetrically encrypted and do provide some level of QC protection. This is minimal but can be used by people right now to mitigate damage from future decryption. If we remove the new hierarchy for jamtis PQ we're removing this capability and we do not have any guarantee on when Jamtis-PQ will be shipped

<genoce:matrix.org> I thought that the symmetrically encrypted carrot self-enote would work without the new carrot key hierachy too? UkoeHB

<jberman> Thank you @rucknium:monero.social. I'll respect the rule going forward, appreciate the exception

<rucknium> We can end the meeting here. Feel free to continue discussing topics. Thanks everyone.

genoce: yes, the carrot hierarchy should only be useful for adding wallet functionality. But the main beneficiaries are cold/hardware wallets, so most users wouldn't have a reason to adopt it. Much simpler to just wait a little longer for Jamtis-PQ so most or all users can benefit and wallet complexity is minimized.

<genoce:matrix.org> UkoeHB: I agree with this take

<genoce:matrix.org> Thank you for your work

<jeffro256> @SyntheticBird Cryptographic support for the PQ turnstile for Carrot is already in the updated version of the spec and implemented in the code > <@syntheticbird> from what i remember, adding turnstile support was on the table for carrot

Is this the latest version? github.com/jeffro256/carrot/blob/master/carrot.md

<jeffro256> > A limitation of Jamtis-PQ is that the view tag is still calculated using traditional ECDH, so a quantum attacker will be able to locate e-notes, but not decrypt them.

<jeffro256> This can have some pretty bad long-term privacy consequences when the account is used multiple times, and the adversary has multiple public addresses of people. They can effectively make a probabilistic social graph of interactions, with its certainty increasing the more "links" between accounts. I have a post on the Jamtis gi [... too long, see mrelay.p2pool.observer/e/vMaPwfcKcTc2Zmpt ]

<jeffro256> If we're going the PQ exchange route, I cannot support having the view tag key exchange happen over an elliptic curve, because that somewhat defeats the point of the regular key exchange

<jeffro256> @tevador yes

<jeffro256> PQ changes are in jeffro256/carrot #6

<syntheticbird> ukoehb ack on the encrypted self-enote. I'm happy to be wrong. In this case I would tend to support your proposal, but as seen with Seraphis and FCMP++ timeline, waiting a "little longer" is really not something I would be betting on

<jeffro256> For more info on the risk: read the "LW2LW relationship" section at gist.github.com/tevador/d3656a217c0…ment_id=5044400#gistcomment-5044400. Assume that the PQ adversary with possession of public Jamtis-PQ addresses is same as a filter-asset LWS

syntheticbird: skipping carrot key hierarchies would bring Jamtis-PQ closer since there's less wallet work needed. But yes, a little longer may mean over a year.

jeffro256: what would be the perf multiplier for doing view tags on CSIDH?

jeffro256: Sadly, using CSIDH for the view tag is not feasible for performance reasons. Scan times would increase 1000x.

tevador: will Jamtis-PQ be able to prevent Janus attacks that use the CSIDH key? Since `d_e` won't be recomputed.

Since the janus anchor isn't included *

The CSIDH key is not subject to the Janus attack because all addresses use the same base curve, e.g. all addresses have Z_5 = z5^j * E where E is the base curve.

tevador: I don't follow. What prevents someone from copy pasting `z5^j * E` to an address with `z5^z * E`?

Can you be more specific? Which value would the attacker put in the transaction?

Specifically, what Z_e and j would be used to mount a Janus attack.

I don't see how to execute the attack in a way that matches all 4 shared secrets. At least X

X3 will differ

Reading #151 now

jeffro256: Let's define key exchange properties: 1) Fast enough for view keys. 2) Supports unlinkable subaddresses. 3) Address size < 1 KB.

CSIDH has 2) and 3). NTRU/Kyber have 1) and 3). AFAIK there is no PQ key exchange that has all 3 properties.

<jpk68:matrix.org> Would McEliece have 1 and 2? Apologies if this is a dumb question

AFAIK McEliece has none.

<jpk68:matrix.org> Alright, thanks. Just asked because it was mentioned in the Jamtis-PQ spec (and disqualified for addresses that are too large).

tevador: 151 mentions CSIDH keys need to be validated, implying a hf would be required. Did this change? You mentioned soft-forking.

tevador: Ok I am even more confused. Is there only one CSIDH key in addresses? Is the shared secret supposed to be recovered after decrypting the index? Wouldn't that allow a PQ observer who knows an address to uncover indices? 24 bits of view tags + however many bits an index could heuristically imply means we'd have to assume PQ observers have strong confidence in the set of non-auxiliary-selfsend enotes owned by each

user (whose addresses are known). Only amounts, key images, and change-identification would be hidden.

Amendment: all selfsends would be protected from all but primary view tag checks (and auxiliary selfsends would be immune to this as well).

<syntheticbird> Doesn't McEliece have the longest key in the entire PQ algorithm kingdom

<syntheticbird> lmfao 128 bit security is a 1MB public key

Mitigation for exclusive selfsend primary view tag analysis: only use 1 byte of the view tag, the rest gibberish. A filter-assist layer will send all 1-byte matches along with 3-byte matches (assuming 3 bytes for the primary view tag - a 2000x cost for CSIDH-1024 would be 11-bit slowdown, so 3 bytes seems reasonable) to the view-balance layer. The vb layer checks exclusive selfsends for both 1-byte and 3-byte matches,

and the normal path (with CSIDH) for 3-byte matches. Auxiliary selfsends would be checked for all txs with exclusive selfsend successes.

Instead of 1b + 2b gibberish, can do complementary view tag with `k_vb` for a small optimization. So normal: 3b primary view tag, exclusive selfsend: 1b primary + 2b complementary, auxiliary selfsend: 3b auxiliary view tag.

Filter-assist layer only needs to care about npbits/ncbits. The vb layer can branch on how large the match is.

Ah the exact index `j` would be hidden by `s_ct` (unless the generate-address tier is compromised). So only known address matching would be possible.

Which isn't a problem because all known addresses can be linked via `k_fa` from solving DLPs.

Only a small problem* since matching enotes to specific addresses is a bit useful for fund flow analysis.