15:00:45 <br-m> <rucknium> MRL meeting in this room in two hours.
15:01:00 <br-m> <syntheticbird> i want it now
15:06:06 <br-m> <kayabanerve:matrix.org> I may or may not be present but my update is https://github.com/monero-oxide/monero-oxide/commit/cba7117d2cb4a45444c54005604b2a943a8517f1
15:07:42 <br-m> <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.
15:08:13 <br-m> <kayabanerve:matrix.org> I'm sure @sgp_:monero.social: can provide commentary on the being-discussed audits to follow up.
15:53:08 <br-m> <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. 
17:00:25 <br-m> <rucknium> Meeting time! https://github.com/monero-project/meta/issues/1368
17:00:28 <tevador> Hi
17:00:30 <br-m> <jpk68:matrix.org> Hello
17:00:31 <br-m> <rucknium> 1. Greetings
17:00:37 <br-m> <vtnerd> Hi
17:01:16 <br-m> <iamnew117:matrix.org> Hello
17:01:56 <br-m> <rucknium> 2. Updates. What is everyone working on?
17:02:19 <UkoeHB> Hi
17:03:06 <br-m> <jberman> waves
17:03:09 <UkoeHB> Me: finished carrot_core review, wrote https://github.com/seraphis-migration/monero/issues/310, likely to look at multisig next (blocking hf afaik)
17:04:39 <br-m> <jberman> Reviewing upstream PR's, rebased https://github.com/seraphis-migration/monero/pull/89 , FCMP++ audit tasks
17:05:02 <br-m> <jpk68:matrix.org> I've been doing a bit of preliminary research on SAM protocol parameters, namely signature and encryption types for destinations
17:05:14 <br-m> <jpk68:matrix.org> Can elaborate if anyone is interested
17:05:46 <br-m> <kayabanerve:matrix.org> I posted my update prior re: the Generalized Bulletproofs.
17:07:01 <br-m> <vtnerd> me: lws+lwsf are up-to-date with fcmp++/carrot and working on testing /feed protocol this week
17:07:27 <br-m> <rucknium> 3. FCMP code integration audit overview (https://github.com/seraphis-migration/monero/issues/294).
17:10:26 <br-m> <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: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/663
17:11:13 <br-m> <jberman> AFAIK, we should have all quotes by next week's meeting
17:13:12 <br-m> <rucknium> Anything more on this item?
17:13:36 <br-m> <jberman> Nothing from me
17:13:49 <br-m> <rucknium> 4. FCMP beta stressnet (https://github.com/seraphis-migration/monero/issues/166).
17:14:07 <br-m> <rucknium> AFAIK, this update from @kayabanerve:matrix.org  is about beta stressnet readiness progress: https://github.com/monero-oxide/monero-oxide/commit/cba7117d2cb4a45444c54005604b2a943a8517f1
17:14:20 <br-m> <articmine> Sorry I am late 
17:14:21 <br-m> <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."
17:14:35 <br-m> <rucknium> CS = Cypher Stack.
17:15:25 <br-m> <jberman> kayaba notes those 2 issues highlighted in that commit description are also now immediate blockers, and I pinged Diego on that as well
17:16:14 <br-m> <jberman> So the main blocking items there are now 1) a response to those raised issues, and 2) kayaba's complete review
17:16:43 <br-m> <jberman> I can also check the perf hit today/tomorrow
17:17:44 <br-m> <jberman> W.r.t. beta stressnet, yep this is the final blocking task
17:18:21 <br-m> <jberman> Would like this item settled before launching
17:20:55 <br-m> <rucknium> 5. Grease Payment Channels (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/651).
17:21:10 <br-m> <rucknium> More discussion on Grease?
17:23:58 <br-m> <syntheticbird> Greasus christ when are we going to have a payment channel 🥁
17:24:36 <br-m> <rucknium> 6. Discussion: Post-quantum security and ethical considerations over elliptic curve cryptography (https://github.com/monero-project/research-lab/issues/131). Safeguarding cryptocurrency by disclosing quantum vulnerabilities responsibly (https://research.google/blog/safeguarding-cryptocurrency-by-disclosing-quantum-vulnerabilities-responsibly/).
17:24:37 <code2> lol -- I've still writing up the distributed KEs ideas. Been a bit tied up with easter holidays and things the last few days
17:25:05 <code2> still confident I'll get it out this week
17:25:09 <br-m> <rucknium> code2: Thanks
17:26:35 <br-m> <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. 
17:26:58 <br-m> <syntheticbird> ngl a recap about what where we are on PQ discussion would be greatly appreciated
17:28:37 <br-m> <syntheticbird> from what i remember, adding turnstile support was on the table for carrot
17:29:38 <UkoeHB> 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.
17:29:55 <tevador> Carrot PQ forward secrecy: https://github.com/jeffro256/carrot/blob/master/carrot.md#211-address-conditional-forward-secrecy
17:30:34 <br-m> <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
17:30:37 <tevador> Jamtis-PQ aims to close this last privacy gap (forward secrecy if an address is known)
17:31:34 <tevador> Jamtis-PQ will feature CSIDH-1024 for quantum-resistant public key encryption
17:32:34 <br-m> <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?
17:32:47 <br-m> <syntheticbird> I thought isogeny based public cryptosystem were broken during the NIST competition ?
17:32:50 <tevador> It's work in progress
17:33:29 <tevador> syntheticbird: the break of SIKE/SIDH has no effect on CSIDH, which is a different cryptosystem
17:33:39 <br-m> <jpk68:matrix.org> Is CSURF still being considered?
17:33:42 <br-m> <syntheticbird> tevador: ack.
17:33:44 <UkoeHB> semisimple: I am not working on it, tevador is.
17:34:24 <tevador> Yes, the selected parameters are sort of a CSURF variant
17:35:31 <tevador> Details here (this will be part of the Jamtis-PQ specs): https://github.com/monero-project/research-lab/issues/151#issuecomment-3640488509
17:37:05 <br-m> <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?
17:37:49 <tevador> 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.
17:37:52 <UkoeHB> syntheticbird: that's what I have advocated. No one else has commented yay or nay.
17:38:11 <br-m> <jberman> tevador: what are your thoughts on contracting a research firm to explore a maximally efficient complete PQ protocol?
17:38:12 <tevador> jeffro256 should comment on that
17:39:13 <tevador> jberman: I think kayabanerve made some estimates around ~500 KB per transaction for a full PQ protocol
17:40:02 <br-m> <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.
17:41:33 <tevador> 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.
17:42:21 <br-m> <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
17:42:31 <UkoeHB> Can RingCT or FCMP++ not be translated 1:1 to a PQ scheme?
17:43:02 <br-m> <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
17:43:52 <br-m> <kayabanerve:matrix.org> I'm interested to see JAMTIS-PQ (or any other such scheme) following the FCMP++ upgrade.
17:43:57 <br-m> <syntheticbird> ukoehb what do you mean
17:44:08 <tevador> UkoeHB: probably something based on STARKS, which are hash based, so PQ proof.
17:44:41 <br-m> <syntheticbird> oh wait nvm i just understand
17:44:58 <br-m> <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.
17:46:11 <br-m> <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.
17:46:21 <UkoeHB> tevador: if hashes are required, why would CSIDH key exchange work? Perhaps I should just read up on it.
17:46:55 <br-m> <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.
17:47:22 <tevador> There is no hash-based post-quantum key exchange protocol. Hash-based protocols are only for proofs and signatures.
17:47:34 <br-m> <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).
17:47:39 <br-m> <jbabb:cypherstack.com> I have seen these recently tho haven't had time to digest them
17:47:39 <br-m> <jbabb:cypherstack.com> SHRIMPS: 2.5 KB post-quantum signatures across multiple stateful devices https://delvingbitcoin.org/t/shrimps-2-5-kb-post-quantum-signatures-across-multiple-stateful-devices/2355
17:47:39 <br-m> <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 https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/2158
17:48:02 <br-m> <jbabb:cypherstack.com> ofc not applicable to us but interesting comparison points
17:48:08 <br-m> <kayabanerve:matrix.org> Hash-based signatures, such as SHRINCS presumable is by the name, almost certainly cannot be used by Monero.
17:48:35 <UkoeHB> tevador: I guess I'm confused how you can do a key exchange but can't do a signature.
17:48:46 <br-m> <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.
17:48:57 <UkoeHB> With EC-like operations.
17:49:04 <br-m> <kayabanerve:matrix.org> A hash-based scheme wouldn't achieve re-randomization.
17:49:15 <tevador> 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.
17:49:22 <br-m> <kayabanerve:matrix.org> ... wouldn't offer?
17:49:23 <br-m> <kayabanerve:matrix.org> ... wouldn't enable?
17:50:24 <br-m> <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.
17:50:25 <tevador> Yes, if we want to keep stealth addresses, then it has so be something lattice-based.
17:50:30 <UkoeHB> Can you use CSIDH or lattices for signatures? Or is it just prohibitively expensive?
17:51:07 <br-m> <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: https://github.com/kayabaNerve/monero-pq
17:51:15 <tevador> CSIDH can do plain signatures, but not the kind Monero needs.
17:52:19 <br-m> <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 https://mrelay.p2pool.observer/e/j53ivfcKTDZMQ1Q0 ]
17:52:20 <UkoeHB> I will look into that. It would be odd to me for plain signatures to work, but not e.g. RingCT.
17:52:53 <br-m> <kayabanerve:matrix.org> I wouldn't be surprised about how one couldn't re-randomize an isogeny map
17:52:58 <br-m> <kayabanerve:matrix.org> tevador: Maybe a code-based signature?
17:53:31 <br-m> <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.
17:55:21 <br-m> <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)
17:58:13 <br-m> <rucknium> 7. More Jamtis features in Carrot (https://github.com/seraphis-migration/monero/issues/310).
17:58:23 <tevador> Anyways... The roadmap is: 1) FCMP++/Carrot 2) Jamtis-PQ (for full PQ privacy, but not soundness. 3) Some full PQ protocol.
17:58:37 <br-m> <kayabanerve:matrix.org> 👍️
17:59:49 <tevador> The proposal is not to ship the Carrot key hierarchy with FCMP++
18:00:16 <br-m> <kayabanerve:matrix.org> I don't believe that was planned at this time
18:00:48 <tevador> I'm quoting #310
18:01:44 <br-m> <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
18:02:19 <br-m> <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 
18:02:40 <br-m> <syntheticbird> hell, some would fcmp++ would be on mainnet by now
18:03:39 <br-m> <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
18:03:40 <tevador> Any delay to FCMP++ means more transactions that WILL be fully deanonymized in the future.
18:04:57 <tevador> I think the wallet-side work will be significantly reduced if we stick to the legacy hierarchy for the fork.
18:05:56 <br-m> <rucknium> UkoeHB: Do you have more comments now about "More Jamtis features in Carrot"?
18:06:32 <tevador> I think it became "Fewer Jamtis features in Carrot"
18:08:31 <br-m> <rucknium> Any more discussion on this item?
18:08:54 <br-m> <jberman> (btw I have another agenda item to raise, apologies for the late addition)
18:09:09 <tevador> What is planned for the fork (AFAIK): Janus attack mitigation, forward secret key images and full chain membership set.
18:09:36 <br-m> <rucknium> @jberman:monero.social: You can raise it.
18:09:58 <UkoeHB> The proposal is to never ship the Carrot key hierarchy, not to do it after.
18:10:53 <br-m> <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 https://mrelay.p2pool.observer/e/vqGmvvcKakJZMjZa ]
18:11:11 <br-m> <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).
18:11:56 <br-m> <syntheticbird> (may the good health be with you)
18:12:11 <br-m> <jberman> The report: https://github.com/cypherstack/fcmp-review/releases
18:12:33 <tevador> More reviews can't hurt if it's done in parallel with other work.
18:14:18 <UkoeHB> Sounds good to me
18:14:39 <br-m> <articmine> I support this review 
18:15:19 <UkoeHB> I also proposed an audit for tevador's mx25519 crate.
18:16:29 <br-m> <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?
18:16:47 <br-m> <jberman> UkoeHB: Ya I think that one is worth a distinct CCS, just need to follow through on it
18:17:51 <br-m> <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
18:19:08 <br-m> <jberman> Imo this would be a low risk, relatively low cost, solid value item to bang out
18:19:28 <br-m> <rucknium> What do others think? Follow the rule in this case or no?
18:20:32 <br-m> <syntheticbird> rules are meant to be broken
18:20:48 <br-m> <syntheticbird> idk something inspirational like that yk what i mean
18:21:14 <br-m> <rucknium> @syntheticbird:monero.social: That phrase came up in my head too 🙂
18:21:25 <br-m> <articmine> Given the lack of opposition there is a case for making an exception 
18:22:38 <br-m> <rucknium> We'll make an exception. More discussion of this proposal? Any objections or reservations?
18:23:54 <br-m> <jberman> I'll highlight a comment shared by kayaba that it's CS conducting a review of CS, rather than an independent party
18:23:55 <br-m> <syntheticbird> nope
18:25:42 <br-m> <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
18:27:12 <br-m> <kayabanerve:matrix.org> I'm not opposed to the follow-up composition review
18:27:23 <br-m> <rucknium> @jberman:monero.social: I agree. What would be an alternative? Another firm doing a review?
18:27:44 <br-m> <sgp_> I'm not opposed for the price
18:27:50 <br-m> <kayabanerve:matrix.org> In an ideal sense, though I don't think CS actually represents a conflict
18:27:52 <br-m> <jberman> @rucknium: yep
18:28:10 <br-m> <rucknium> What delicate parts of the protocol would this review hit?
18:29:01 <br-m> <rucknium> In other words, what could go wrong if a review misses something?
18:29:29 <br-m> <kayabanerve:matrix.org> This will primarily cover the interoperability between the membership and SA+L proof, and the SA+L proof itself
18:31:34 <br-m> <rucknium> @kayabanerve:matrix.org  and @sgp_:monero.social  : Neither of you are in favor, just "not opposed"? Is that correct?
18:32:59 <br-m> <kayabanerve:matrix.org> I honestly don't care and effectively see it as a "why not" at an acceptable price, to be blunt
18:33:31 <br-m> <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
18:33:58 <br-m> <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
18:34:02 <br-m> <rucknium> The price is good. Makes it easier to approve.
18:34:09 <br-m> <kayabanerve:matrix.org> *others here
18:35:55 <br-m> <sgp_> @rucknium: Ideally multiple firms would be solicited but for the price I'm not concerned, basically
18:37:40 <br-m> <sgp_> More solicitations for this is likely to be a waste of everyone's time
18:38:09 <br-m> <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.
18:39:54 <br-m> <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 
18:39:54 <br-m> <genoce:matrix.org> I thought that the symmetrically encrypted carrot self-enote would work without the new carrot key hierachy too? UkoeHB
18:40:34 <br-m> <jberman> Thank you @rucknium:monero.social. I'll respect the rule going forward, appreciate the exception
18:40:53 <br-m> <rucknium> We can end the meeting here. Feel free to continue discussing topics. Thanks everyone.
18:48:02 <UkoeHB> 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.
18:50:46 <br-m> <genoce:matrix.org> UkoeHB: I agree with this take
18:51:06 <br-m> <genoce:matrix.org> Thank you for your work
19:39:30 <br-m> <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
19:48:26 <tevador> Is this the latest version? https://github.com/jeffro256/carrot/blob/master/carrot.md
19:49:33 <br-m> <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.
19:49:33 <br-m> <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 https://mrelay.p2pool.observer/e/vMaPwfcKcTc2Zmpt ]
19:50:10 <br-m> <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 
19:52:12 <br-m> <jeffro256> @tevador yes 
19:55:10 <br-m> <jeffro256> PQ changes are in https://github.com/jeffro256/carrot/pull/6
19:56:37 <br-m> <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
19:58:31 <br-m> <jeffro256> For more info on the risk: read the "LW2LW relationship" section at https://gist.github.com/tevador/d3656a217c0177c160b9b6219d9ebb96?permalink_comment_id=5044400#gistcomment-5044400. Assume that the PQ adversary with possession of public Jamtis-PQ addresses is same as a filter-asset LWS
20:00:35 <UkoeHB> 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.
20:03:11 <UkoeHB> jeffro256: what would be the perf multiplier for doing view tags on CSIDH?
20:03:53 <tevador> jeffro256: Sadly, using CSIDH for the view tag is not feasible for performance reasons. Scan times would increase 1000x.
20:31:15 <UkoeHB> tevador: will Jamtis-PQ be able to prevent Janus attacks that use the CSIDH key? Since `d_e` won't be recomputed.
20:31:39 <UkoeHB> Since the janus anchor isn't included *
20:37:50 <tevador> 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.
20:39:12 <UkoeHB> tevador: I don't follow. What prevents someone from copy pasting `z5^j * E` to an address with `z5^z * E`?
20:40:54 <tevador> Can you be more specific? Which value would the attacker put in the transaction?
20:42:20 <tevador> Specifically, what Z_e and j would be used to mount a Janus attack.
20:47:13 <tevador> I don't see how to execute the attack in a way that matches all 4 shared secrets. At least X
20:47:18 <tevador> X3 will differ
20:51:09 <UkoeHB> Reading #151 now
20:51:47 <tevador> jeffro256: Let's define key exchange properties: 1) Fast enough for view keys. 2) Supports unlinkable subaddresses. 3) Address size < 1 KB.
20:51:47 <tevador> CSIDH has 2) and 3). NTRU/Kyber have 1) and 3). AFAIK there is no PQ key exchange that has all 3 properties.
20:53:23 <br-m> <jpk68:matrix.org> Would McEliece have 1 and 2? Apologies if this is a dumb question
20:55:33 <tevador> AFAIK McEliece has none.
20:57:53 <br-m> <jpk68:matrix.org> Alright, thanks. Just asked because it was mentioned in the Jamtis-PQ spec (and disqualified for addresses that are too large).
21:00:38 <UkoeHB> tevador: 151 mentions CSIDH keys need to be validated, implying a hf would be required. Did this change? You mentioned soft-forking.
21:32:05 <UkoeHB> 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 
21:32:05 <UkoeHB> user (whose addresses are known). Only amounts, key images, and change-identification would be hidden.
21:35:56 <UkoeHB> Amendment: all selfsends would be protected from all but primary view tag checks (and auxiliary selfsends would be immune to this as well).
21:41:29 <br-m> <syntheticbird> Doesn't McEliece have the longest key in the entire PQ algorithm kingdom
21:58:30 <br-m> <syntheticbird> lmfao 128 bit security is a 1MB public key
22:04:38 <UkoeHB> 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, 
22:04:38 <UkoeHB> and the normal path (with CSIDH) for 3-byte matches. Auxiliary selfsends would be checked for all txs with exclusive selfsend successes.
22:07:01 <UkoeHB> 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.
22:11:32 <UkoeHB> Filter-assist layer only needs to care about npbits/ncbits. The vb layer can branch on how large the match is.
22:41:38 <UkoeHB> 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.
22:44:39 <UkoeHB> Which isn't a problem because all known addresses can be linked via `k_fa` from solving DLPs.
22:45:31 <UkoeHB> Only a small problem* since matching enotes to specific addresses is a bit useful for fund flow analysis.