PQ Transaction Signatures #001

What are the key sizes and signatures sizes?

Our slides: https://github.com/ZKNoxHQ/Communications/tree/main/pqts-breakout Running the demo: https://visionary-nougat-217eaa.netlify.app/

Reacted to "Our slides: https://..." with 👍

Reacted to "Our slides: https://..." with 👍

You are aiming for LVL1 security guarantees for Lattices. How confident are you with LVL one (128 classical), I heard comments that it is likely that the parameters will need adjustments in the future. Should not we have a security gap to account for attack improvements?

How did you determine the precompile gas cost? And how does native implementations of Dilithium and Falcon compares with native ECDSA in terms of performance?

does the on chain cost for precompiles include the calldata cost of signatures?

A Pimlico key ot paste if you don't have one: pim_Y8VztkEto45P6yzNiEt5Tx Our very secret key if you are lazy: 0x0000000000000000000000000000000000000000000000000000000000000001 to paste both in prequantum and postquantum private keys (seed) (no need to connext extension once you have an ac ount).

Is there a need to change the hashing algorithm (from keccak to poseidon2?) when we choose either of these signature schemes?

precompile gas cost is a rule of thumb looking at CPU cycles (SUPERCOP) compared to ecdsa

Reacted to "precompile gas cost ..." with 👍

Replying to "Is there a need to c..." This is something to discuss

Reacted to "This is something to..." with 👍

Replying to "Is there a need to c..." Assuming you are referring to the hash inside the signature scheme: If you modify it, it is a different scheme and no longer the standardized one. At the same time, you may gain some advantages wrt L1-zkEVMs or aggregation of these signatures (which we don’t do for ECDSA, but may be interesting for large PQ signatures)

Reacted to "This is something to..." with 👍

falcon propose this separation of hash directly in the precompile, we did a FALZKON in Cairo, replacing keccak by a more zk friendly function (blake2s has its AIR)

Replying to "Is there a need to c..." Apologies, I was referring to the hashing to arrive at the account address corresponding to the new keys.

We also specified a zk friendly version of DILITHIUM over M31

Replying to "Is there a need to c..." Ah. That one seems mostly independent to me

Replying to "You are aiming for L..." Dilithium has already a specification that is official

Replying to "You are aiming for L..." Shoudn’t we wait for FN-DSA instead of integrating Falcon? It will be Keccak/Sha3 all over again.

We also instantiated a ZK version of Dilithium for BabyBear, KoalaBear.

Replying to "You are aiming for L..." https://blog.cloudflare.com/pq-2025/#ml-kem-768-and-x25519 Discusses how they choose to use a higher level security (level 3) but aim is just to get 128 bits classical

What will happen to the current 4337 ecosystem (bundlers, etc), still working the same ?

Two questions: First, 8141, is still compatible with 7701, isn’t it? And second, Can you pls elaborate on the migration paths that is being considered? We have EOA, delegated EOA, 4337 smart accounts and several non 4337 smart accounts.

Is there supposed to be slides? We can’t see them

Replying to "Is there supposed to..." No slide for this specific contribution

Reacted to "No slide for this sp..." with 👍

aggregation for CL ? or EL ?

Replying to "aggregation for CL ?..." EL

Replying to "aggregation for CL ?..." I think this was referring to EL

Reacted to "I think this was ref..." with 👍

A réagi à "I think this was r..." avec 👍

Replying to "How did you determin..." falcon is much faster for verificaiton, dilitium a little faster for verification Signing times are where the performance issues are

Replying to "How did you determin..." Sig/key size are the biggger impact

Replying to "does the on chain ..." No

Replying to "does the on chain co..." It can. There is the cost of memory expansion and the CALLDATA carrier cost that would be part of it too.

Is there link to these slides as well?

Replying to "Is there link to the..." We'll provide it as soon as the presentation is over

Reacted to "We'll provide it as ..." with 🙌

Reacted to "We'll provide it as ..." with 🙌

Would you use the proof of seed for migration, or as a signature scheme itself (use a PQ proving scheme and some nonce and binding with the message) ?

Replying to "Would you use the pr..." The latter

Replying to "Would you use the pr..." Migration requires user input and we believe many users will be laggards when it comes to this sort of stuff, unfortunately...

Répondre à "Would you use the ..." Totally agree, consensus solving is hard in term of conception easy in term of migration. execution layer is the opposite. We have a working solution today, but convincing users and protocols will take years.

Replying to "Would you use the pr..." Indeed!

For the proof of seed and the variants you mentioned right now, does the verifier need to know which variant is used, i.e., which part in the chain was exposed and which was not?

Répondre à "Would you use the ..." We need this red button as a parachute. We don't want to use it, but you of course prefer to be seated with a proper one just in case.

Replying to "For the proof of see..." We need to settle on a specific circuit, so I'd say yes

Replying to "Would you use the pr..." This is 100% our point. We're developing this stuff with the hope of never having to use it. Basically having wasted our time will be the best outcome lol

Replying to "For the proof of see..." Ok, but it could be that different users exposed different intermediate keys, right? How do you know which one to pick?

Reacted to "This is 100% our poi..." with 💯

Reacted to "We need this red but..." with 👏

If user use a proper BIP39 derivation, which is the case of most wallets and hardware, they are covered

Replying to "For the proof of see..." This is a very important topic and I'd defer it to discussion time afterwards

Reacted to "If user use a proper..." with 👍

Reacted to "This is a very impor..." with 👍

That is also having this in mind we specified proper derivation path for the PQ keys. We are compatible with this solution.

Would gladly sync here

Institutions typically don't use seed phrases for wallets storing the bulk of their funds though

Reacted to "Institutions typical..." with 👍

Replying to "Institutions typical..." I hear you but institutions are also much more proactive, and will likely migrate as soon as they can

Having partial solution is better than no solution. Sorry for them if they chose to deviate from standards

My slides on Cryptographic Agility: https://docs.google.com/presentation/d/1bP-4kwKojabAnv_FSmfbzIl0pQs_PP8YLBgjrwLKzw0/edit?usp=sharing

Reacted to "Having partial solut..." with 👍

And institutions will be easier to convince than single users.

Reacted to Having partial solut... with "👍"

Reacted to "Having partial solut..." with 👍

Because they will have experts to warn them internally.

Reacted to I hear you but insti... with "👍"

Replying to "That is also having ..." Yeah, I was very excited to see this mentioned on your slides! Let's set a meeting up to get things going.

Proof of seed works much better with EdDSA over RFC 8032. You can check the details here: https://fc26.ifca.ai/preproceedings/190.pdf

Actually, if you use hardened path, the proof of seed described works fine

Eddsa is better for non hardened.

Reacted to "This is a very impor..." with 👍

Does proof of seed work with a compromised 7702 delegated account as well? Most of them have a sweeper in place atm.

here is a description of how the proof of seed applies: https://github.com/ZKNoxHQ/PQBIP39

Reacted to "here is a descriptio..." with 👍

(quantum safe eoa migration part)

Replying to "Actually, if you use..." Actually, if you use hardened path, the proof of seed described works fine True but I am not sure if this has been the regime for a good range of accounts specially for the custodians and HSM-managed accounts.

Our derived path and how it is managed in most wallet is compatible with the circuit

Répondre à "Does proof of seed..." we need seed deactivation quick

Répondre à "Does proof of seed..." i mean, eao deactivation

Reacted to "i mean, eao deactiva..." with 👍

Répondre à "Does proof of seed..." https://ethereum-magicians.org/t/eip-7851-deactivate-reactivate-a-delegated-eoas-key/22344

It's a really broad technique, it works with pretty much every key-derivation step which involves at least one cryptographic hashing step between master seed and master key. BIP-32 and ECDSA are an interesting special case, but they are very much a special case.

A réagi à "It's a really broa..." avec 👍

Reacted to "It's a really broad ..." with 👍

Reacted to "here is a descriptio..." with 👍

But wouldn’t apps need to change their signature schemes to support this as well?

no

we prove it with the Aave integration, no change in the contract

this is aave sepolia contract we interact with

The beauty of AA!

Aren’t there several apps that still rely on ecrecover. It took us a lot of work to convince them to support EIP1271

If you mean "a smart contract with some on-chain custom cryptographic logic" tho, then you are right. But that's a compeltely different can of worms and I don't think we can do much about it anyway

No change necessary on user wallets other than installing the proof of seed app, that was a fixed point in our development process.

yes, some Dapp still use msg.sender and need to be updated

As for apps, they would need AA support or delegation features, yes. Some of them don't, and those would need change.

I will open a group Danno

actually some needs to update, like safe

https://pqbeat.xyz/protocols/

Indeed. But again, I wouldn't stress too much over this. The only apps becoming insecure in this case are the apps that are dead (team walked away). Actively maintained apps will probably migrate in time anyway.

Again, it's not the devs that worry me...

Reacted to "Indeed. But again, I..." with 👍

Reacted to "Again, it's not the ..." with 👍

Yeah, agreed, convincing users will be easier than big Dapps

Reacted to "Indeed. But again, I..." with 👍

i meant harder

Reacted to "i meant harder" with 😄

I was like "wait wat?" lol

Convincing users to migrate is the most difficult. Both 4337 and 7702 have shown that

Reacted to "i meant harder" with 😄

Reacted to "I was like "wait wat..." with 😂

They don't need to do anything. I forgot to mention in the call: the 4337 accounts can be safely opened FOR the users by sponsors, and they deterministically derive from the EOA address.

We do need to worry about developers, wallets, and HW wallets, before we settle on a set of sigs. Their input is a concern we need to think about once we have a general path.

Actually native AA, or disabling eoa in 7702 is required to have a clean deployment without front running

Replying to "They don't need to d..." I cofounded an AA company that provides AA infra on several chains. We provide it for Ethereum Foundation as well. But our biggest challenge in the past 3 years is convincing users to migrate to an AA account. That is the reason for my question.

bye thx antonio