First theme was where we are today, where we stand and what our measure should be. So, questions to the panelists. Number one, by when do you plan or suggest to migrate? Maybe we can start from Mike.
All right. By the way, thank you, Jay, for having us all here. We just did this IPO roadshow for BitGo in January. And it's an interesting process. And there's a whole bunch of investors that have no idea what we really do. And yet they're all asking me about quantum cryptography. I was really surprised. I mean, it was a top three question. It's on everybody's mind. So, you know, I don't know, news cycles tend to pick up negative titles faster. To Dan's point, there's other applications that probably should be more worried because you've got encrypted material that could be decrypted later potentially regardless of kind of the timeline. But unless it's a super super high priority thing for the world. And so, when it comes to cryptocurrencies, we trust them because we trust the cryptography. And then all of a sudden, if you can't trust the cryptography, then you have to rethink everything. So, people are worried about it right now. Imagine you had a billion dollars, you're like, 'Geez, the dollar doesn't look very good. Maybe I'll put it in that Bitcoin thing.' But I don't understand quantum. And everybody says it's like a threat and it's going to be here like tomorrow. And AI is going to kill all of us. So, there's a lot of reasons why people are worried about it. And we got to take that out.
So, I agree with Dan, we should not rush it. There's a lot of competing voices about what the right answer is. But then lastly, at least for Bitcoin, it's going to take a while. So, even if we had it fixed today, the next set of issues, the more societal problems. First, you got to migrate all the wallets. So, they said what, 6 some odd million Bitcoins are potentially exposed. And then you got to figure out what to do with Satoshi's coins, which is kind of the existential, you know, I don't know, philosophical problem for Bitcoin. No matter what you pick is kind of ugly. So, I think we got to get on it right now, at least be working on it in earnest. I think more awareness around it is super important. Everybody here I know has at least some interest in it. Hopefully we get a decision in terms of the protocol relatively soon so that we can get on to these other problems, but it's cryptography. You never want to rush cryptography.
Google has publicly announced that we are aiming for our internal migration to be done by 2029, which is based on some of the quantum research that recently came out that makes things sound a lot scarier than they used to be. Different platforms scaling better and so on and so forth. The question is, should you rush anything? You should definitely not rush anything. The biggest problem is like Dambreville mentioned, the store-now-decrypt-later attacks which definitely add urgency for encryption. I would argue there is a separate problem for signatures, especially on web PKI which is the thing that I'm the most familiar with and interested in, that signatures are much much harder to migrate than encryption is.
Encryption, you set the client to say that they would like to use ML-KEM. You set the server to prefer ML-KEM if the client offers it and your connection is PQC. You can see that with like Chrome, Firefox, and I think some of Safari as well, are asking for a PQC key exchange, and various servers, in particular Google's and Cloudflare's, respond to that, and the connections are protected. You don't have to involve any CAs. These keys live for like usually seconds at best. And so this transition is much much easier in a lot of ways than the signatures, where now you have to talk about CAs. You need to, you get this problem where you're not secure until everyone is secure, because if there are some players in the trust system that are still using old signatures, then the attacker can always say like, 'Well, I'm this player, but I am using still the old signatures, even though there would be a PQC signature.' So, you need to have various ways of like ratcheting mechanisms that tell clients which kind of keys they can trust to be PQC, which keys they should still accept for legacy reasons, and so on.
So, there's a lot of complexity in the signature case. I wouldn't say you should rush the signature migration, but you should go at a consistent pace. The complexity of the system is just so high that waiting until you see more data does not feel responsible anymore.
Yeah, so in terms of, for Anchorage Digital, we're the number of a federally chartered bank, we're building things from scratch. So, the quantum question for us is, because it's a regulated bank with other people's money involved, a lot of the concerns that Pickle has is very similar to what we're dealing with. Like we want to make sure that other people's money are safe and all that. That being said, we don't want to rush the transition to quantum as Dan said. And the tricky part that I'm kind of thinking about is how do we make sure that the system design is flexible so that when a new standard is agreed upon, it's very easy for us to transition into. So, I think having those sort of system guardrails and sort of knowing the rough shape of what that solution might look like is super helpful just from a system design point of view. But yeah, I wouldn't put a hard timeline on it.
Okay. Yeah, over to Hart. Let's start with a couple of migration related questions. Yeah, so we wanted to ask you all generally about standards. So, yeah, what did the standards get right? What are some issues with standards? I know, you know, dare I mention XMSS? What do you think about the standards process?
How deeply technical do you want me to go? So overall, there is a lot of stuff that the standards have learned from what we did wrong with previous cryptographic algorithms. I've seen way too many implementations where people that are nowhere near the cryptographic layer are like looking at the N and P and Q separately and storing it in various different formats and so on. One thing that the standards get right is that all the keys and ciphertext and so on, they are just binary blobs. They are just defined and that encourages anyone else to not look into how to parse them and parse them in different ways. We've seen very many vulnerabilities that just come from people parsing cryptographic elements when there was no need to do so. So that is one thing that they get right.
Implementation-wise I think, Falcon aside, they're very easy to implement. Much easier than elliptic curve cryptography ever was or RSA for that matter to securely implement in particular. They work very well with currently existing CPU infrastructures like they basically want to use vector instructions and CPUs have vector instructions. So they are not as bad performance-wise as you otherwise would think they are given the key size increases.
So yeah, and then if you get into what they did get wrong, there are too many options. XMSS is one of the places where there are too many options. XMSS is the way that you get rid of an option. But the fact that just if you look at the ML-DSA standard there were six different standards in this standard. There are three different sizes and then there's a pre-hashed version and not pre-hashed version. The pre-hashed version technically isn't even a fully qualified signature scheme because it needs a hash function on top of that defined. And if you look at the NIST book, then you will see that a signature scheme does not need that usually.
So it just causes a lot of friction when there are too many options because one system will do one thing, the other system does the other slightly different thing. Now, these two systems cannot talk to each other. SLH-DSA is I think the champion of too many options. I don't know how many variants of SLH-DSA there are these days. Options, especially options that aren't very meaningful, are not usually a good thing to have. I would be much happier if the options had very different performance numbers. Like, UOV is one of the candidates that is very interesting to me because it has very small signatures that you trade off with this very large public key. That is as an implementer a trade-off that I can make in a system. Whereas the difference between ML-DSA 44 and 65 sure is a kilobyte, but what am I trading off here? They're supposedly both secure, so why do I have to care about these different schemes when they both do the same thing? Pre-hashes are even worse where like, well, we have another way of doing this already. I don't have a reason to select one over the other, which just leads to more of these incompatibilities.
Actually, if I can add to that, I totally agree with everything Sophie said. There's a lot of complexity in these standards. What's interesting to me is the standards I think are often designed for internet use. Whereas on the blockchain, there's a lot of other needs for standards to satisfy. Just to give some examples, on the blockchain we use a lot of HD wallets, right? So you'd like the signature scheme to support hierarchical derivation, HD. You'd like the signature scheme to support threshold signatures because that's very common on the blockchain space. You'd like the signature scheme to be friendly to zero knowledge proofs. We'd like to be able to do a zero knowledge proof of a signature. And in the existing signature scheme, I don't know how much of that has actually played a role. And of course I forgot to say the most important thing that on a blockchain it's really important that the signature is short. We don't want to spend a lot of time and a lot of space on signatures.
And so there's a lot of requirements for blockchain based signatures. And what we're seeing is that actually many of the projects are actually deviating away from this. So Sophie mentioned SLH-DSA with all the options that it has. Well, it looks like Bitcoin and Ethereum are starting to coalesce around hash based signatures, but they're not using the NIST hash based signature. They're basically inventing their own. And in fact I'm happy to talk about the SPHINCS and SPHINCS+ proposals that are being thrown around. So it's quite interesting that the blockchain community because of the NIST issues is kind of going down its own path of standard signatures.
One more dimension that I want to mention, which Sophie and I have talked about this quite a lot, which is when it comes to signatures, should you do standard signatures or should you do hybrid signatures? And so I don't know, maybe Sophie you want to talk about hybrid signatures?
Okay, that's a spicy one. Yeah, I actually am kind of ambivalent about it. So for encryption I would say do hybrid. Oh yeah. So basically we have these classical schemes that we know have a bunch of analysis on for years. And we have these new schemes that have comparatively less analysis on them and the implementations that exist have been audited and looked at to quite a large extent where the new stuff, they were just written, they definitely have some testing problems that we will find, like how we do side channel protections and so on in the new things that we don't yet know fully. So the idea is can we get both? And the answer is yes, you can get both security properties of the classical and the new algorithms both for encryption and for signatures. For encryption you need a key derivation function, but it's not that relevant for this discussion. For signatures it's very very simple. You just add two ampersands between your verification calls, so you just verify both of them and if both of them are verified then you have a hybrid.
For encryption I think hybrids are like, yeah, do them. Don't even think about it. That's what all the browsers are doing. That's what IETF is doing and so on. You don't really need to concern yourself with it. The cost is fairly minimal and the benefit is clearly there. For signatures this is a much more complicated question. Interestingly enough not in the way that I thought it would be. Like I just explained how hybrid signatures work and how simple they are. It turns out that maybe that simplicity actually makes them more complicated because people come up with different ways of putting together two ampersands until the cows come home which has led to a pretty large coordination headache actually with hybrid signatures.
To the point that given that signatures don't have the store-now-decrypt-later attack and you can technically change them if you're in a system that can change them, like if you can revoke your signatures, which isn't always true, but if you can change signatures, and like the IETF mailing list isn't able to come up with a hybrid scheme that works for everyone, then maybe just go with pure. If you cannot change your signatures, again, the cost of doing a hybrid signature is not that high, so you should probably just do it.
Right, interesting. Actually, Dan, you answered the next question yourself. But probably to summarize, do you feel blockchain world will be a wild west of guys creating their own signatures, not following NIST standardizations? Do you think a world like that evolving into actual reality?
Oh, yeah, I think it's pretty clear this is where we're going to go.
But will that demean some of the security primitives we have or that will be done in a very informal manner?
So will that demean some of the guarantees we want to have with responsibilities that NIST and others try to enforce because traditional finance has moved kind of full-flesh to...
Look, some blockchains adopted Falcon, some chains are adopting various parts of the versions of the ML-DSA options. Ethereum and Bitcoin seem to be coalescing on the hash-based signature schemes. And like I said, they're inventing their own versions. So maybe it's worthwhile, do you guys want to hear about what's happening with hash-based signatures in the Bitcoin world?
So there's this proposal basically that you basically can't use a hash-based signature on the blockchain because the signature is too big. So, what do you do? You have to shrink the signature somehow. So, how do you shrink the signature? Well, with hash-based signatures, we know that if you're building what's called a one-time signature, a signature that can only be used to sign one message, and then you have to change your public key, we know those signatures are not that big. Those can actually be controlled. The length can be controlled. So, the idea is to basically create two keys. One key that's going to be used as a long-term key, but you're only going to use that in case of recovery, like your wallet blows up and you need to recover your keys, you recover the long-term many-time signature scheme, which generates long signatures, but you only generate those long signatures on the rare event that you have to recover your wallet.
And then, separately, you have another signature scheme, which is only good for a small number of signatures, and as a result, it generates short signatures. So, when you transact normally and you sign transactions, you're going to use the few-time signature scheme, so your signatures are going to be relatively short. And when you run out of signatures in the short scheme, you just use the long-term scheme to sign a new public key. So you kind of have these two parallel tracks, one for recovery and one for daily use. The daily use one is short, the recovery one is long. So that's kind of at a very high level the direction that people are going in. That's not something that NIST considered. The blockchain developed this, and that seems to be a good way to go.
Now, where you get pushback is interesting is exactly when it comes to wallets. So, when you look at the wallet providers, they are quite worried about hash-based signatures because generating a public key in a hash based signature takes like a Ledger wallet a couple of minutes. Generating a signature takes tens of seconds to just generate a single signature. And so they're a little more worried about where this is headed. One would expect that their microprocessor providers would add support for hashing, fast hashing, into the processor so that the hardware wallets will actually be able to generate these signatures at a fast enough pace.
The problem is again, we want, there's a lot of demand for these signatures to be ZK friendly, right? So you want to be able to generate a proof of knowledge of a signature and to do that typically you would not use the NIST standard hash functions, but rather you would use hash functions that are more friendly to ZK proofs. And those are very unlikely to be supported by the hardware. So we're back to very slow hashing, very slow public key generation. So this is what I meant by we shouldn't be rushing these things. There's a lot of technical challenges in deciding exactly what signature standard or which signature scheme to use. There are all these problems as you think, if you design these things in a room, it's actually, you can design a scheme that looks perfectly fine on paper but then you realize oh my god there's all the hardware wallets that have a problem with the scheme. There's all the HSMs that have a problem with the scheme.
Actually, I want to give one quick example of a problem with rushing to post quantum that I hope people remember. This is a, let's just say it's a hypothetical example but it's actually a company that came to ask me that they want to be post quantum compliant like really fast really soon. So what can they do? And the answer is well, they have to adopt one of the post quantum signature schemes. The problem is that their HSM card doesn't support a post quantum signature. So what do you do? Well, if you need to generate a post-quantum signature, but your HSM card where your keys live don't support post-quantum signatures. So what do you do?
Yeah, oh my god. Take the key out of the HSM and generate the signature outside of the HSM, right? At that point, you are far more likely to be vulnerable to a classical attacker than to a quantum computer. So that's the sort of thing that I would say is not the right direction to go in. And that's what I mean by rushing to post-quantum. I think what I love about the Google 2029 deadline is that the right solution is you can go to your HSM provider and say, 'Look, we have this 2029 deadline. You guys have to add post-quantum support before 2029 so we can meet our deadline.' And migrate only once they add post-quantum support. Don't take your keys out of the HSM where they're much more vulnerable than they are to be stolen by a quantum computer.
So, you probably have an opinion on that, too.
Let's see, was that a real case where somebody took it out of the HSM?
Uh okay, it, I don't want to...
Sounds like a yes. But actually we had a company we worked with, a major bank, and came up with the same thing, not even related to post-quantum. And you know, it's surprising. This is why people can screw up security implementations all the time. Anyone that's familiar with this knows, of course, that the whole point of the HSM is to not expose the key. Why would you ever take it out? But yes, people come up with these solutions when they're backed up against the wall.
Yeah, that's a drawback of rush. Right. With that, we'll move to the next theme. Over to Hart, which brings the next question.
Yes, but I think people have been addressing this a lot already. But just talking about two or three variables for post-quantum cryptography that trade against each other and one that is non-negotiable for you all. If you have to choose, what will be non-negotiable?
Speed, hardware, signature size, ZK-friendly, conservatism, anything you like. Agility even.
Why don't you start us off?
Okay, I'll start it. Actually, I think for Bitcoin, the block size wars are kind of happening somewhat implicitly. You mentioned already, on one hand, there's paths you could take to solve the post-quantum problem. However, the natural solution has massive blocks. And of course, there's a lot of people that think the massive blocks are a problem. Of course, the signatures are substantially larger, about 100x, I think. So if you're only willing to have small blocks, it's going to constrain the solution that you can ultimately pick. It also is going to force you to either wait a really long time to have something that's of the right size, or you're going to have to accept a larger signature size in the end. So Dan and Sophie are probably much better equipped to answer some of the specific differences. For me, look, I think we need to solve it in a way that's just secure, is not going to have further problems down the road. So, we can't rush it. I would throw block size to the wind. I don't think that's a real concern. I'd much rather have security where you can't lose your money.
Well, I'm mostly not responsible for blockchain-related use cases, so I'm just going to trade all of those off. I think one thing that Dan said is very much true. Like, if your key is currently in an HSM, it should probably remain in an HSM. Maybe you do a hybrid where the PQC part doesn't live in an HSM for now, but you should not trade off quantum safety against classical security boundaries that you have in place that are protecting you right now. At least not without analyzing that that is the right trade-off very very deeply.
There's a lot of cases where the trade-off is kind of between complexity and cost. My favorite example is Merkle tree certificates. That's sort of the new shiny way of dealing with certificates. Kind of similar actually to the hash-based signatures that Dan was mentioning. Certificates are sent with every TLS connection. If you make them a lot larger, you are going to slow down the internet quite considerably. It costs a lot. But there are ways that you can make these things smaller. In the case of MTCs, the way that it works is basically the CAs publish a Merkle tree of all the certificates that they're currently vouching for, and then the browser vendors distribute the root of this Merkle tree to the various browsers. Then the browsers communicate to servers that they know about this root, and then the server can send a much smaller Merkle tree inclusion proof instead of sending the certificate chain with its ML-DSA signatures.
That is kind of, it's very similar to the schemes that Dan mentioned. Not quite the same thing, but it's also using heavily hash functions and heavily changing the way that we distribute trust. It's now a much more involved system where the browser vendors, which previously distributed the roots for the CAs and that was kind of it, now they need to do something on a much much more frequent scale. And you have to have a fallback mechanism in case the browser isn't up to date and so on. So, you have a lot more complexity. But for the web at least we decided that that is worth it because the cost of ML-DSA pure would be too high.
The interesting thing is that this also goes kind of closer to Dan's point that this is the right thing for web PKI. I'm fairly certain that it's not the right thing for other PKI frameworks, actually. And so you're seeing kind of divergence of ecosystems that previously used the same solutions, mostly because the solutions that we had were ridiculously great. ECDSA signatures are just 64 bytes of data and you have your signature, you don't need to worry about anything. Now you're no longer in this world where a signature is basically free. So now you're starting to think like, well, I could have a hash of this thing and publish the hash somewhere and then that can replace it so that I get one less signature here and suddenly that starts making sense. Before, well, sure, technically the hash is half the size of the signature, but who cares? Now the hash is orders of magnitude smaller, so people care. So I think that is the biggest trade-off that I can see, a trade-off between complexity on the one hand and just eating the cost of the overhead on the other hand, which is kind of the same answer that you also gave.
So, for me, I think the most important variable is post-quantum agility. Because we're integrating with so many different chains and so on, each chain will kind of have their own set of trade-offs. So, some chains who really care about the block size will want to make sure the signature size is small. Some chains really want top performance. We really have to be able to support all of them. So, making sure we can kind of adapt as new signature schemes come out and as each chain works through their decisions is super super important.
Actually, maybe I'll make a spicy take a
A little bit here in that, you know, there's no theorem that says that post-quantum signatures can't be less than 128 bytes. So today, it's true, ECDSA is great, BLS is great. These are wonderful signatures, lots of amazing properties, very short. The post-quantum signatures that we have today are dramatically worse. But there's no theorem that says that they have to be dramatically worse. And it's actually likely that over time, you know, we'll come up with better and better signatures. In fact, they are improving over time. So keeping that in mind, to me, actually, post-quantum agility is quite important. You know, I actually am a little bit nervous that ML-DSA is getting kind of enshrined everywhere in a way that's going to be difficult to change later on. Already, we have better algorithms than ML-DSA, and it's going to be very, very difficult to move to those algorithms. So please, whatever you build, just keep in mind there will be better signatures coming in the future. So let's not enshrine what we have today and be ready to move to something better when it's available.
Indeed. Do you like to call?
I definitely agree. Cryptography is always good to have. The very interesting thing is if you look at the history of things, it's like we had the Merkle, these hash-based stuff first in asymmetric cryptography, and then we had RSA, and that was kind of what we stayed with. It's like in retrospect, we got incredibly lucky that the first schemes that we looked at were really good.
Yeah. Yeah.
Do you want to call out a couple of alternatives of ML-DSA, better alternatives of ML-DSA which you feel will replace?
You asking for better—what are better signatures?
Yeah, than ML-DSA. From your perspective.
Well, okay, just if you want to stay with a family of ML-DSA, just in the last crypto conference there was a scheme that showed that you can change how ML-DSA works and end up with a shorter signature, as just one example. You know, there's proposals now on ePrint for better threshold signatures from lattices. So yeah, there's like new ideas coming up, and we just have to be open to adopting them as they become available.
Indeed. Right. Probably for Sophie, yeah. So you have a clean sheet of paper and you're designing institutional custody, right? So you talked about post-quantum agility as one of the factors, but which one would you concede to the others?
Yeah, I think so yeah. The variable I would anchor on is obviously post-quantum agility. For the other ones, I think—I'm trying to think which—wait, can you go back to the list? I think for us, things like on-chain affordability don't matter as much because if you're storing, say, signatures on like a private chain or in a private database, memory is cheap. Obviously, in a blockchain-based system, you have to replicate that many, many times, so it becomes a lot more expensive. But there are some benefits to kind of operating in a more centralized system.
Well, let's see. Eliminating single points of failure is definitely a requirement. So we started out with Bitcoin ECDSA, then you know, we added P2SH to allow multi-sig capabilities. On other chains, we don't have native multi-sig, so you end up using MPC sharding of different types. They tend to not facilitate well to cold storage, so this can make it difficult. Anyway, depending on what scheme you end up with, you're going to need something so that you don't have a single point of failure. And if you can't deal with it in various shards that are compatible with cold storage, then you probably end up with multi-signature. And if you end up with multi-signature, then the space requirement becomes doubly hard.
Mhm. Now, let's move to the next theme, which actually touches how to remove single point of failure, which is MPC friendliness. You talked about multi-sig, that's one approach. It comes with cost and a couple of other nuances. Then the other aspect is how to make signatures threshold-friendly. Just for the audience, MPC is just a technique where you can create secret shares of the keys which are never assembled in one place, and then you can perform signature as if the signature was coming from the same private key. And among all the contenders, there is a huge spectrum of possibilities of whether they can support MPC or not, and that's what we will dive into in the next section. Hart.
