*35C3 preroll music*
Herald: The next talk is called "The year in post-quantum crypto" by Tanja Lange,
she's researching in Eindhoven, and Daniel Bernstein, researching at the University
of Chicago. They both had the first ever conference on post-quantum cryptography in
2006 and they both contribute to libsalt crypto library. Their talk is going to be
a summary of the NIST post-quantum crypto competition and they're gonna provide an
overview of problems of post-quantum cryptography and hopefully show us how to
integrate post-quantum crypto in existing software. Please welcome them with a huge
round of applause.
*applause*
Tanja Lange: All right, well, thank you. First of all, this title word post-quantum
cryptography, what it means, we're talking about cryptography where we're designing
the systems under the assumption that our attacker - not the user, just the attacker
- has a large quantum computer. Also to remind you from three years ago, when we
showed you the attacker, we're talking about attackers. All right. So, we're
seeing like over the last few years 2015, say middle August, there was a big
announcement by the NSA saying "Oh yeah, acutally the world should care about post-
quantum cryptography. We need more research." They finally wake up to it and
actually they had a nice roll-out effect, that pretty much every agency - just
highlighting three of them here, so U.K., the Netherlands and the NSA themselves -
made some statements about the urgency of rolling out post-quantum, that normal
cryptography that we're currently using, so elliptic curves and RSA and Diffie-
Hellman and finite fields, will be broken as soon as a quantum computer, and the
NIST, which is the National Institute for Standards and Technology, so it's an
institute in the U.S., which is working on standards said, ok, we're gonna call for a
standardization project for post-quatum cryptography. So yes, it's a U.S.
institution, but it has in cryptography a mostly good history. They have been
running competitions which gave us AES. They've been running competitions which
gave us the SHA3. And they also, without a competition, gave us Dual_EC.
*laughter* TL: So, competitions with NIST, good
thing, everything else, well, judge for yourself. This sounds like a great story.
It's also a little bit disappointing when you look at where it started. So back in
2003, Dan here coined the term post- quantum cryptography and then they've been
running around for 10 years going like "The end is nigh, please invest in post-
quantum cryptography, do something", just that 10 years later the NSA said "Oh my
God, we have to do something, quatum computers are comming". So it's a little
bit. Yeah, I told you so. Not a great story, but.
Daniel J. Bernstein: All right so what happened with this competition. Well after
NIST said "Hey everybody, send us some proposals for post-quantum crypto to
standardize", a lot of people did. So, they said actually more than 80
submissions came in and some of them were incomplete, like one of the requirements
was include software, and whatever reasons, they said some of the submissions
are not complete, but they posted 69 complete submissions, the submission teams
include 260 people from around the world, all sorts of academia, industry, maybe
even some government people. There's lots and lots of names and we're not gonna go
through, like, what all these things are, but we are going to say something...
TL: Oh we have 60 minutes. DJB: Oh that's true. So BIG QUAKE: This is
a code based system... *laughter*
No, we're gonna give you some idea of, like, what the big picture is of how well
these things have held up. So, these were all posted by NIST on the 21st of December
last year, and some of you who saw our LatticeHacks talk last year remember that
this list, already there was some damage to it by the time of our talk on the 28th
of December 2017. By the end of the year, there were eight submissions that had
attacks, at different levels of severity. I should explain the color coding here.
The stuff that's in brown is less security than claimed, which could be for instance
they claimed something was, it would take 2 to the 128 operations to break and
somebody says "no, it's 2 to the 100 or 2 to the 80". Does that really matter? Or
maybe a different direction is somebody says: "this is a system where you can
reuse the key any number of times", which we expect for for normal crypto systems
that you can publish your key and people can keep sending you messages or you can
sign many times under some keys, but sometimes people claimed they had that
feature and they turned out to be wrong; those were attackable, like HILA5 in this
list, which is not necessarily kicking them out of the competition, because NIST
said, you can have a system with one-time keys that can be useful for some
applications. The things in red are, everything that they proposed, all the
concrete parameters are broken. The underlines are those where there's attacks
scripts, Python scripts, stage scripts, whatever it takes to demonstrate that,
yeah, look, here's here's your secret key, or decrypting something. So that was the
end of 2017. How about now. Well, OK, let's extrapolate, three days from now.
Probably the situation is at least the following. At least by twenty eighth of
December 2018, 22 submissions have attacks. So it's about a third of those 69
submissions, and you can see more, well, most, well, 13 of those, out of the 22,
are red, mostly with underlines. I think some of this is from us, a lot from other
people. And I think we did well early on establishing that people should put out
scripts to demonstrate that ,yeah, you really can break these things. So again
the underlines are demonstrated attacks; some of the submitters have withdrawn the
broken submissions; some of them have not. TL: All right, so when you look at this,
we're not going to go through explaining those, but let me categorize these. So
when we look at the ones which are not completely smashed and broken, we can put
them into boxes, we can say "hey, what is the underlying mathematical problem",
"what do we hope is something the attacker has to do in order to break the
cryptosystem". And then there is one category of using error-correcting codes,
which is then used for building an encryption system or a signature scheme,
hash functions, you can only build signature schemes from, isogeny-based
crypto, for the competition we're only seeing an encryption system, and honestly
all the signatures we have seen so far are pretty inefficient. Lattices we see for
both, that is something we talked about last year, so if you want to get a full-
blown lattice explanation, go for last year's talk. And then finally, there's
something using systems in many variables, many equations, and we get signatures and
encryption from that. So that's one way of saying "Well, these are good things for
post-quantum". It does not mean that everything which isn't in these boxes is
secure. You can still design a system, which somehow relates to this math
problem, but the attacker can do a way around. Some of those systems, RaCoSS I'll
get back to later, is a code-based system - code-based is on the list, first one up
there - so should be totally secure, and yet it's one of the red underlined
systems. So just being in one of the categories does not mean it's secure, but
it's at least some hopeful and helpful thing to box things. There are other ways
of describing why this is the situation we have now.
DJB: As an example of this kind of categorization, sometimes people might
say: "Oh, lattice-based cryptography is is the safe thing to do. All of that red was
people who were not using lattice-based- cryptography and everything lattice-based
is good, everything else is scary". But if you look at the lattice-based systems,
it's not all black. There's some red stuff here. Compact LWE. That one is broken,
with a script, we're quite sure it's broken. There's some others with some
damage, DRS, HILA5. So it's not that the lattice-based submissions have held up
perfectly and also it's not just that these are isolated mistakes that people
have made. There's ongoing research which is making better and better lattice
attacks. For instance, some papers from last month and this month from the three
authors listed there are talking about lattice-based systems being broken by
decryption failures. Now this phenomenon, most of the lattice submissions have
occasional decryption failures. Once every 2 to the 64 ciphertexts maybe, you won't
be able to decrypt. Which might sound like "oh, it's no big deal, it's, maybe
occasionally you might have some user has that happen and they'll just, the browser
will reconnect, whatever it takes, it's not a significant failure rate". Except
that those failures, if the attacker is trying to decrypt a particular cipher text
or maybe attack or figure out somebody's secret key, they can usually get that
information out of watching the pattern of decryption failures, if decryption
failures happen often enough. And these papers are saying, for two different
reasons, decryption failures are actually happening more often, maybe much more
often than people claim. So that's kind of scary.
TL: All right. One explanation, which I of course like very much. I've been running a
European protocol, PQCRYPTO, and just use everything in our portfolio. It's good
right? Actually, it's looking better than the arguments saying: "I'll use everything
lattice-based. We have one which is slightly scratched, but everything else is
good. Right. Yay." DJB: Except, well, there's another
explanation than just, well, whoever these PQCRYPTO project people are, obviously the
right people, putting together a great portfolio. There's another possibility.
Not saying this is right, but you could imagine the cryptanalysts who are deciding
what to do out of that huge pile of 69 submissions. Maybe they thought the people
who were in this project doing this stuff for some number of years are maybe not the
top targets. Maybe you should look at the other 49 submissions. Maybe you should
look at the submissions with the specification written in Microsoft Word.
Probably more likely to be broken. Maybe there's other ways that you can decide how
to - no offence to Microsoft people - TL: It worked.
DJB: yeah, that did work coincidentally. Yeah. So, the thing to keep in mind is
that there's a huge pile of submissions, more than a million words in these 69
submission documents, and this is like, a word in English is usually a kind of
imprecise thing, reviewing that, this is I would say more effort than reviewing a
million lines of code. This is a lot of stuff, lot of junk to go through. There's
a real flood, there's too much for us to all the people who care about attacking
systems to, to actually go through everything. So people are making a
selecttion, and maybe they just haven't bothered looking at these PQCRYPTO
submissions. So, if you want to actually have security review, it's really
important to keep this denial of service effect in mind, that the flood of
submissions has to be small enough that it can be handled by the number of people who
are looking at these submissions and evaluating the security.
TL: So, call for help, please join, please break. Don't break ours.
*laughter* TL: Now, one thing which in this audience
is a little funny, but in an normal academic conference where you talk to like
40 or 100 people, we like, we actually have a lot of people now being interested
in post-quantum cryptography. This was this year's conference on this, when Dan
and I started this in 2006, we were looking at an audience of 40. This is 350
people. Well, they would probably fit in here, but, well - for academics, this is
big. There's a huge interest right now. This was the combined conference together
with a NIST workshop. And so people are looking. So that's the good news. There's
more denial of service going on, I mentioned RaCoSS already as one which is
broken, but not withdrawn. Broken actually three different ways, where our last
message to them was basically "abandon all hope, this is not gonna work", but they
keep on hoping. If I zoom in there, they have, they are on the way to publishing
new parameters. *laughter*
TL: When he was reading it out, actually at the conference, he was saying "the keys
and signature size may be several dozens of terabytes". Well, there is some effect
that we're most likely not going to break it so easily, because when you're trying
to download several terabytes of data, it might not reconnect.
DJB: So, NIST is certainly aware of the fact that there's just this denial of
service on security analysis. And one of the ways that they tried to simplify the
picture is, said, after their conference they put out this call saying, "all right,
if you have similar submissions, see if you can merge them". And then hopefully
you get something which is, you know, going to be a combined submission that's
easier for us to analyze than these two separate submissions in the first place.
And they said this is an interesting little guarantee. They said "NIST will
accept a merged submission to the second round if either of the submissions being
merged would have been accepted". So you can imagine kind of attacking this if
there's a strong submission and you have a weak submission, like the strong one, they
surely have to accept that, and then you merge your weak submission into the strong
one if you can somehow convince the other team to do that, then your weak submission
is also going to get into the the second round, but NIST said "well, you should
only merge submissions that are similar and the merged submissions should be like
a combination of the two original submissions". So that sounds kind of
reasonable, an example, while the first announcement of a merger - I don't think
NIST said that you have to publicly announce - but HILA5 merged with Round2,
and of course this was after the HILA5 attack and part of the merger was fixing
the issue in that attack, and they formed Round5 and they said "Round5, this result
of the merge, is a leading lattice-based candidate in terms of security, bandwidth
and CPU performance". So, three weeks later, the security turned out to be kind
of a problem. Mike Hamburg said that here is a very strong reason to believe that
decryption failures are much much more likely than what they claimed, and as a
result of that, and they they accepted the argument and said yeah, oops. As a result
of that, like I mentioned before, decryption failures are something that
attackers can use to break security. And it's not that that a full attack was
implemented, but it's pretty clear that the attack would work, and this is also an
interesting attack because the mergers were supposed to be just taking, like take
the best features of your two submissions, that you're merging. But this was a
mistake. The vulnerability that Hamburg exploited was a mistake that was not in
either of the submissions that were being put together. So there's some process of
break and fix and merge, making more mistakes, which get broken and then fixed
and, well, what was the fix. They said, "oh, here's a proposed fix". They're
"looking at the security proof adjustments", there will be a Round5 real
proposal, their actual merge will be in the future. I think now they have Round5a,
Round5b and Round5c, where A is broken, B is questionable, C is still not defined.
What does a security proof, what does a security proof mean, if you have a
security proof previously that they were adjusting, and the security proof is for
something that is not actually secure. Very strange. More merger announcements,
post-quantum RSA encryption and post- quantum RSA signatures merged to form
post-quantum RSA, saying that that "is a leading candidate in terms of depth of
security analysis, amount of network traffic, and flexibility". For people not
familiar with post-quantum RSA, this means using RSA with gigabyte or terabyte keys,
which is leading in the amount of network traffic.
*laughter* *applause*
DJB: We want the internet to have as much cryptography as possible.
TL: Use more bandwidth. DJB: Yeah. Remember, you have, if you're
measuring the amount of encrypted data on your network, this increases that. More
mergers, more mergers, more mergers. Some of these are kind of gluing submissions
together in a way that does not simplify the, the security analysis. But this last
one is a good example, I would say, of a merge entry. NTRU-HRSS and NTRUEncrypt,
two of the NTRU-based submissions, they actually put some thought into what they
wanted to keep and what they wanted to throw away. And so analyzing the merge is
easier than analyzing the, both of the initial submissions. After the November
deadline for mergers, NIST said they will announce the second round candidates.
Maybe it'll be, probably less than 30, some hints it'll be 25 or even 20,
candidates, and maybe that's starting to get down to a small enough flood that we
can start seriously analyzing what's left. They're going to announce that, I think on
exactly January 10th they're scheduled to do that, and then a week after this
announcement they said, "Well, the government might be shutting down, and in
that case we're not allowed to do any work, so we're going to be completely
silent in case of a shutdown". It's important in the U.S. government, during
shutdown there's a definition of essential personnel, like NSA, and non-essential
personnel, like people protecting us against NSA.
*laughter* DJB: - and only the essential personnel
are allowed to do work. You know what else is not allowed to do work? The backend
database for NIST's web pages, which might sound a little bit weird, although maybe
they're paying Oracle for the backend database, and they have to turn off the
payments to Oracle. I don't know what's going on here, but if you look for the
competition information, you can't find it on their web pages anymore. We're not
quite sure how long this shutdown is going to last. Of course, there are some people
who say that this is not a problem, because we can figure out without this
competition how to protect ourselves against quantum computers.
*laughter* TL: All right, now that we have aliens
already, are quantum computers actually coming? Big question, we don't know. What
we can monitor is progress in quantum computing and just middle December, there
was a news item from IonQ, which is a small startup company, announcing their
largest ever quantum computer based on ion traps. All the other quantum computers
we've seen so far, which are of this size, like 40 to 70, they were using
superconducting qubits. So, it is again a race between different technologies, but
both of them are advancing, and there are some more which are growing. So, it looks
like it's coming. Whenever I see that picture like this, I'm reminded of a nice
joke from a colleague of mine, Steven Galbraith.
*laughter* TL: Can you distinguish? Yep. So, with all
these news coming up, the National Academy of Sciences in the US has been
interviewing people for the last about year and a half. So they got people in
physics and engineering, building quantum computers, people doing quantum
algorithms, people doing quantum error- correcting codes, and putting all of this
together into a report, which just came out, where they look into, well, what is
the progress and what are the prospects. So the first part of key findings, the
first one is the good news, saying don't panic. We do not expect that anything is
going to happen in the next 10 years which will threaten RSA 2048 or similar, where I
assume what they mean, well, elliptic curves, discrete logs on finite fields. So
that's the good news. But they wouldn't have just one key finding, it actually
goes on, two three, ten, by the time they reach 10, I think this is panic. So that
they say is, well, it takes forever to roll out these things. The hazard of such
a machine is high enough. And then, "the deployment of post-quantum cryptography is
critical for minimizing the chances of a potential security and privacy disaster".
These are strong words from the National Academy of Sciences.
DJB: So, OK, can we deploy post-quantum cryptography? Is it deployable? Well, some
people would say we've already deployed it, but maybe that doesn't include the
NIST submissions, so let's look at the deployability of the NIST submissions. The
main thing that matters for deployment in most applications, the main problem for
post quantum cryptography, is the sizes. So, here's a picture of the night sky over
Leipzig. No, this is a picture of, on the horizontal axis is the size of your public
key for a bunch of signature systems, not all of the signature systems, for instance
WalnutDSA, which is broken with a script in the first five versions -
TL: Post-quantum RSA is missing. DJB: Yeah, post-quantum RSA is also
omitted from this, sorry. TL: It's kind of, of
*laughter* DJB: Yeah, that would be like, I'm one of
the designers of post-quantum RSA by the way.
TL: I'm not. DJB: It's the future of cryptography.
*laughter* DJB: That was good. Yeah. So what you can
see here is, for example this "gui" submission, this has, you can get your
your verticals, the signature size down to just 32 bytes or 35 bytes, something like
that, but you need something like 400,000 bytes in your public key. And then there's
three different dots for gui. Those are three different security levels, and maybe
all the different submissions here are maybe not exactly comparable on the
security levels. It should be a three dimensional graph, if we measure
everything properly by exactly how secure it is, which of course we're not quite
sure about until there's been enough security analysis. You can see, various
different trade-offs are possible, none of which are down where we want to be with
things like under 100 bytes for your public key and under 100 bytes for your
signature, which is what we're used to right now. That's what ecliptic curve
crypto gives us, is signature sizes and public sizes, which are both below 100
bytes. And that's something you can fit into your applications much more easily
than, say, 100,000 byte public keys or 10,000 byte signatures. There's various
different trade-offs, and maybe your application can handle some of that, but
there's nothing that's just really small, which is what we're used to right now.
Another more complicated graph. This is for encryption and showing more
candidates. Well, there are more encryption submissions. This is still not
all of the encryption submissions, but a representative sample. And you can see
that, well, there's still no really great sizes here. The best in terms of sizes is
"sike", supersingular isogeny keyexchange, which is something like 400, little less
than 400 bytes for the public key and for the cipher text, and then it starts
getting bigger from there. And you get, on this graph you get things up to megabyte
or bigger. You can get a little below 300-400 bytes, you can get down to 100 or
so bytes for the cipher text, as long as you are willing to accept a public key
that's much, much bigger, with some of these code-based systems. And then just to
zoom in on some of the smaller ones, you can start seeing where some different
candidates are. This is everything which is public key and cipher text below 1280
bytes. And again, you see "sike" down there, a little below 400 bytes, and then
some other possibilities. But well, what are the security levels of these things?
Could all of these be broken? There's not actually that many of them, how many of
these have actually been studied? It's kind of scary. And again, much bigger
sizes than we're used to in cryptography. TL: So, yes, size does matter.
*laughter* TL: So, Google and Cloudflare this year in
April were saying, well, we don't really know what the outcome of this competition
is going to be, but we have some categories of different crypto systems,
and let's just send dummy packets of data of respective sizes, and see what happens
when we do this on the Internet. Now this is Google and Cloudflare, so they they
were doing this on the Chrome browser for connections that go through Cloudflare, so
they could actually see from where it came, where it ended, whether it came
back, whether it dropped. Dan mentioned "sike", so this is the one category of
supersingular isogenies, those are just 400 bytes. And that was pretty much fine,
so when you look at the first column, you have a small latency increase. You also
see the inaccuracy, that's a -0.2. So, the numbers are mostly correct. Then there is,
in the lattices, this was the zoom-in what Dan was showing, those are mostly
something that could take a, we have structured lattices, those are around the
MTU, so 1,100 something bytes. And that was, mostly worked, some small increases,
but under 20 percent, so this is also something we feel like, yes, you could
actually deploy this on the Internet. Then a different category still within lattices
are unstructured lattices. Those would come with 10 kilobytes of data for the
public key. And there they just noticed that too many pages, including, like, top
pages on Alexa 500, such as LinkedIn, were just dropping. They tried, funny enough,
9999, where fewer pages was dropping, so 10K was worse than 9999, but even then
LinkedIn was still dropping. And so they decreased it to a third, as basically a
placeholder, measured with these 3300 bytes, and then scaled up by a factor of
three. Now, those increases in the latency is what they said, well, this is not
acceptable. So then for the next experiments, they were only looking at
isogenies and structured lattices. Isogenies are also special, not just being
the smallest, but also being the slowest. Well okay, not absolutely the slowest, but
it's the only system where the speed is much more an issue than the size. And so
despite Google having quite a few computers, they were saying we can't
actually use isogenies for the speed reasons. Size would be awesome, but speed,
not so sure. It's also a relatively recent system, it's just in 2012. So maybe also
it's a security question. So just now in December, they announced that they're
actually building a new experiment, they announced which candidate they have
chosen, NTRU-HRSS, which Dan just mentioned was also one of the recent
mergers. And so this is one of the structured lattices systems, designers are
Andreas Hulsing, Joost Rijneveld, Peter Schwab and John Schanck. Great score for
Eindhoven team, current professor, former student, and then some collaborators. And
so they're now building a system which is a combined elliptic curve, so that's the
combined EC, that's combined elliptic curves and post-quantum. This is the
second round running, and so this would come to some Internet browser near you
soon. Another nice result, I mean this is not the only thing up there. The IETF this
year finished standardizing XMSS, which is a hash based signature system. It's been
in the making, down there you see the timeline, it's been in the making for
three years. It's not really fast, but it's also the first of its kind. This was
the first time that IETF has published a post-quantum RFC, request for comments,
but that's basically their standards. And so there's a lot of boilerplate text,
which was developed in this thing, in the process of making the standard, which is
dealing with, yeah, post-quantum, quantum attacks and so on, how you should handle
it. XMSS is interesting. It's not one of the NIST submissions, because it doesn't
satisfy the normal thing that you learn in primary school, what a signature should be
doing. Signature you expect to have a public key. You use it to sign something,
and then you have a signature. XMSS, you have a public key, you have a state. You
get a message, you sign it, and you update your state. And if you ever forget to
update your state, you will lose security. So it's something which is not as cool as
a normal signature scheme, but there are also many applications where you actually
know how many signatures you've made. I mean, if you're doing operating system
updates, you better know how often you got your key out of the drawer and used it. So
it is not impossible to use, but it might not be exactly what you want for your web
applications. DJB: Good thing about XMSS is still, if
you can count, then the size is much smaller than the signature systems that we
were looking at before. Another size advantage, size advance is something
called Glowstick. I should explain the name. This is starting from a lattice
submission called Saber, which is one of the unbroken ones, and Saber has a big
version called FireSaber, high security level, scaled up. It also has a small
version called LightSaber. *laughter and groans*
DJB: And this Glowstick is the even smaller version. It's like, let's scale it
down as far as we can get that it's not quite broken, and there's various
technical details and it hasn't been broken in the months since it's been
proposed, the six months or so, and it is interesting. I mean, it is something which
is a good challenge. It's nice to have these scaled down problems, so we can try
different ways of attacking these things and people who like breaking stuff, it's
good to have the simpler systems to practice doing attacks, and that gives you
some insight into what could work against the larger systems.
TL: All right. So, since we're coming to funny names... Oh, no, since we're coming
to sizes, why do we still care about big sizes? I mean, people are scaling things
down. Google says, oh, we don't like big sizes. So why do people say post-quantum
systems are bigger and we still care about it? So one of the reasons is, well,
highlighting McEliece here, which is our submission in this competition, these have
had a lot of analysis. So classic McEliece is based on a system from 1978, basically
unchanged except for some changes where we can really prove this is the same as that.
It has one of the shorter ciphertext, just 200 bytes, so that's actually kind of
tolerable on the Internet, but a megabyte of key. Key generation is also pretty
slow, but then the, well, it's nowadays called encapsulation, decapsulation
because all you want is your AES key, you don't want to actually encrypt the
message, but basic thing of encryption and decryption of that. So, nice system, very
good history in security, pretty fast, pretty small, except for the public keys.
It's like, "Grandma, why do you have so big keys?". Why are these keys so big? So
one thing is, it's like a two dimensional key. We have this big matrix there, what
you see on the left is an identity matrix. This thing has about 7000 columns. It's
like pretty long. It's only for, the height is n-k, which is just like thousand
five hundred, so it's really long and stretched. And so all of this part on your
right-hand side, that part is random and you have to send that. You can of course,
everybody remembers what an identity matrix looks like. You can forget about
this one, but this one you have to send, because the encryption works by the sender
thinking, which of those around 7000 column he wants to pick, and then just
XORing them up, and for doing that, well, you need to have this big matrix.
And if you calculate, well, 1547 times 5413 , that's the part of the right matrix,
you're getting to this one megabyte size. Now what are the issues with having big keys?
It's bandwidth, but honestly, when you download, a picture it's also a megabyte.
So, it might not be so bad. I mean, if you're on the German trains then you will
hate it, but - *laughter*
TL: - normally, elsewhere in the world or on your mobile, it's fine. Google was
saying, we actually excluded some systems, so they didn't experiment with classic
McEliece, largest they looked at was 10,000 kilobytes, and even then some dropped,
and they said, well, some are too large to be viable within TLS.
So they just said, well, we don't do this. But then again, you have a secure system.
You can just also design a secure protocol to go with it. We don't need to stick with TLS.
But there is a real problem with having a megabyte of key, because if your
protocol assumes that the client generates this one megabyte and then just throws it
at the server, and the server has to accept one megabyte from every single
client that is throwing a megabyte at it, and then has to do something with it,
well, this is really an invitation for a denial of service attack, because you're
allocating memory on the server for doing these operations. The operations are pretty fast,
it's just XORing 0s and 1s, but you have to allocate 1 megabyte for each client.
And so this is a problem, no matter what the protocol we designed,
we have to deal with the possibility of denial of service attacks, or avoid them.
So, can servers avoid storing these big keys? You want to XOR
these columns, so one of the first limitation on small devices was saying,
well, "I'm a very small device, but I can pick those positions and then, outside
world, please be nice to me and spoon feed me one column at a time". So the small
device memorizes 1500 bits, not so big, and then gets the next column.
If it was selected, it XORs it in, if it wasn't selected, well, it keeps the intermediate
state. So this works. And at the end, you output the normal ciphertext. But what we
have here is, we're operating in a friendly environment where we do not
expect this outside world to do something nasty to us, and also we have some memory.
Now if we put this on the real Internet and we don't want to have any state, so we
cannot memorize these 1500, because, well, we don't know when the next column is
going to come, so we output and send this back to this client. That's not gonna work.
When you tell the client, "Oh, this is my current result", then the server
gets the next column, maybe XORs it in, maybe not, sends it back to the client,
anybody who is watching this traffic could see whether there was a change or there
was no change. So this is not a way of dealing with it. So what Dan and I have
been busy with, and, well, I put 2018 with a question mark, we still have like three
days, right? So we're working on this system called McTiny, tiny because it's
made for tiny web servers, where we assume that this web server is not allocating
any per-client storage, any per-client state. And so, we again work with spoon feeding
things, but we're making sure that everything that the server gets and sends
out is encrypted, is authenticated, there is some stuff to avoid replay attacks, so
that somebody can't just say, "oh, what if I change the column here or there". So all
these things are encrypted, and what we do is we use properties of doing these sums
and pieces by chunking up this big matrix into chewable pieces that are small enough
to fit in one MTU and still have some space for some cookies. So this is similar
to normal uses of cookies, this is a cookie, encrypted to the server, send to
a client, you handle the storage, and then client sends the next piece,
sends the old cookie. Now, the cookie is encrypted, but the way that the key is
handled is the same for all clients. So there is no per-client storage of any
keys. It's a symmetric key, it's pretty small. So that's the one thing that the
server remembers, and then it gets a packet, it from this cookie part recovers
all the, like, which columns to pick, what's the intermediate result, and then
does some computation, sends it back. So, the result of this is that we need several
round trips, but there's absolutely no per-client state on the server.
DJB: Of course you could say, well, there were still all that bandwidth, and what if
you do have bandwidth problems, but some people say that we're familiar with
sending a lot of data around, so that's really not a big deal. Something else that
could interfere with deployment is patents. Now Tanja mentioned before that
classic McEliece does not have patents, but what if somebody says, "I just don't
want to handle the megabyte", or for whatever reason people want something
smaller or there are signature questions. Well, we have a lot of information about
some systems which are patented. The 18 systems shown here, because NIST had as
one of the rules for the competition that you had to deliver statements to them,
signed by every member of the submission team, saying either "we do not have
patents, patent applications on our submission", or, "here's the patents,
patent applications, here's their numbers". And so, OK, as a result of that
and NIST, after checking they had a complete pile of statements, put them
online, so now we know that these are exactly the 18 submissions where the
submission teams claim patents on their submissions, including for example Compact
LWE and DME and WalnutDSA, which are rapidly broken by scripts that are online.
And RLCE-KEM, that one has half of the parameters are broken, there's another
half which are not broken. It's not that the patented submissions are somehow
better than the rest of the submissions, but well, for some reason people think
they can make money off of patents, and maybe they're not actually so wrong,
because you can't just throw away these 18 submissions and say "that's the end of it".
The problem is that there's some patents which cover more submissions. Now,
NIST does not require these submitters to say that, "here's which patents are, which
submissions are covered by my patent". The submitters are only required to say
something about their own submissions, and also NIST has no way to say anything about
whatever random patent trolls that are out there, that have not submitted anything.
They can't impose any rules on that. I mean, of course you can try doing patent
searches, but you won't necessarily find things, for instance this patent. Nobody
noticed until it was revealed in, well, by a member of some submission team, this
patent was issued in 2015, at the top there, which might make you think, "oh, if
something was published before 2015, it would be okay", and some submissions were
published earlier. But what's important is the date down at the bottom here, which is
the priority date of February 18th 2010. If you look on Google Patents, one good
thing is they put the priority date pretty far up, where you can easily see it. What
this means is that, in order to be prior art for this patent, well, you have to
check what exactly they filed in 2010. They might have made later changes,
but the 2010 thing, assuming that has all the same stuff as the patent, which it's
possible to find out, this, anything that was published after 2010 is not prior art
for this. Now what's really scary about this patent, and I hope that really soon
I'm gonna have analysis online of which submissions are covered by which patents
of all the patents I've seen. This one is by far the scariest, because this one
covers a whole bunch of submissions. This one covers basically every submission
which is using what's called the LPR cryptosystem, a ring-LWE-lattice-based
crypto system. This is a very popular type of lattice-based crypto system, which was
published by L, P, and R, Lyubashevsky, Peikert, and Regev, in May 2010, which is
after this patent application was filed. Now, there was a talk in April which had
the same stuff from LPR, and it seems like there might even have been a talk in
January from LPR, but they didn't put the slides online, and then, well, it starts
getting into interesting questions of patent law. This looks like a very
strong patent, covering a whole lot of submissions, and there's more cases,
there's a whole company called ISARA that is specializing in planting landmines,
patent landmines, around things that other people are doing, sometimes on things that
other people have already published, and then you get a court fight about it. This
is gonna be a problem; it's something we really have to watch out for, is what is
patented, and again, I hope to be sometime soon done with some patent analysis.
Of course, some people would say that we don't have to worry about patents as long
as we find something that we can deploy, that somebody tries deploying it
and they don't get sued. TL: Not sure that's going to be deployed
anytime soon. I mean, 95 out of 3000, *Laughter* okay. All right. Funny names, I said.
So what do you see here? Can anybody read phonetics? Yeah? "si-said". Okay, so,
seaside. Now, CSIDH is what you really always wanted. CSIDH is an efficient post-
quantum commutative group action. Did you know that you wanted a commutative group
action? Actually, you did. So, what all people ask me is, like, "I'm using Diffie-
Hellman these days. What can you give me in the post-quantum world?". And then it
depends a lot on how you define Diffie- Hellman. Some features that we come to use
from Diffie-Hellman are that, well, you publish a public key, I publish a public key,
other people publish public keys, and we can reuse them. Kind of nice. Also, we
don't have to talk to each other. We can just look up the other public key on the
phone book, have a shared key, and start using that one. And if I send you
something encrypted with our shared public keys, like, combined thing of this, then
you will be able to decrypt this. There are some nice other features; you can
blind things, you can like take your g to the a and then multiply, compute in the
exponent times r, so put some blinding factors there, and there is no difference
whether I'm the initiator or I am the responder in this. We don't have this
anywhere else in post quantum cryptography. All the systems that you see
for NIST submissions make a difference between are you the sender, are you the
responder. So this is the first efficient post-quantum, well, Diffie-Hellman-like
thing, which, well, by fancy math called commutative group action. So, if you are a
user, you don't want to know all the details. I'm not going to give an entire
talk about this, unless, maybe next year. What you see exposed to you is just one
single finite field element. So there is some fixed prime, that all the people in
the system know, and then everybody's public key is just one single field
element. So Alice computes her field element, Bob computes his field element,
they post these somewhere, and then sometime later, years later, maybe if
quantum computers are built, they find each other, they compute their shared
public key, they combine the shared, the public keys into their shared secret key,
sorry, and then they have the shared secret. Now, a little bit of the math
behind this, A actually appears in some form there, so this is one of the
elliptic curves that we've been talking about in, gosh,
when was this, 2013 or so. No, 14 at least. DJB: 14.
TL: So there's EA: y^2 = x^3, and then A, this public key A, x^2 + x, and that what
the computation is to go from one key to another key is using an isogeny, same
isogeny kind of thing that you heard in sike before, it's a math object that just
means you move from one elliptic curve to another elliptic curve. If somebody tells
you to implement this, what you need to get doing is, well, take this prime p,
compute modulo p for addition, multiplications and divisions, out of
those you for instance build the curve operations, and then some more operations
which computes an isogeny, but all of those are just combined from those things.
So there's nothing particularly scary behind it, except for, well, we came up
with this thing in January 2018 at this lovely beach. Was great there, but please
don't use it yet. Experiment with it all you want, but this has not had enough
analysis. But another reason why you might want this is security, key sizes and so on.
So, what are we looking at? First of all, how many keys are there? So how big
do we have to look at this p? When you have fixed your prime p, say n bits, then
there are square root of p, so 2 to the n over 2, many such curves. So these are the
numbers of public keys. And then, similar to how the elliptic curve discrete log,
kind of meet-in-the-middle attacks, work, so basically smart bruce force search, you
get a square root of the number of keys as your security. So if you have square root
of p many keys, it takes your fourth root of p time to find out what Alice's key is.
So if you want 128 bit security, you have to choose your prime p four times as many
bits, so a 512 bit prime. But this is a talk on post-quantum cryptography.
So where do we stand there? Elliptic curves would be totally broken. Nice enough for
isogenies, we don't have any complete break. There are some sub-exponential
attacks, so doesn't have full exponential security as we maybe would like to have,
on the other hand, with RSA and finite field Diffie-Hellman, we have been dealing
with the growth of keys, with sub- exponentil attacks, so this is something
we're familiar with. It doesn't kill things, but you look at the literature,
it's mostly asymptotics, so we and also some others have been looking into
details. I think our analysis, which we have at quantum.isogeny.org, is the most
detailed one, looking into, like, what actual security you get against somebody
with a really really big quantum computer. Now with elliptic curves, you'll hopefully
have also learned that you must always validate, you need to get a point,
somebody says "oh, this is my public key", the first thing you do is check, is this
thing on the curve, does it have the right order? Same thing for isogeny-based
crypto, for CSIDH you have a very quick check, you check that this curve has the
number of points, you know what it is, you don't even need to do full point counting,
you just take a point, do some scalar multiplications, and you check it. This is
another thing that we've gotten totally used to doing. This is another thing that
is really really really hard for most post-quantum systems. Most post-quantum
systems you add another proof to it, so typically when you encrypt to somebody's
key and you're sending something which looks like a key, you reveal all the
secrets in there, that's why you can't reuse it, or you have to do a big zero
knowledge proof to prove that you actually generated this thing properly. With CSIDH,
it's just there. All you need to do is check if it's a valid curve, and you're done.
Size it's also pretty neat. So, 32 bytes for the secret key, 64 bytes.
So just twice as large as normal elliptic curves, that is really like bottom-left
corner of Dan's graph where there was nothing, so CSIDH does fill a big gap, a
big gap, but a small key, there with something, which pre-quantum has at least
128 bit security and post-quantum, so what NIST was asking for is comparisons with
AES-128 and then you look at, like, how big are the sizes, how big are the quantum
computers and so on. And we think that CSIDH-512, to the best of our knowledge,
based on the latest analysis, will be as secure as that. There is some code written
by Lorenz, somewhere? Ah, Lorenz. Yay. This is on Skylake. Your mileage may vary.
This is a, it's not a super-quick hack, but it's not deployment code. So this is
not yet constant time, there are some others who've been working on constant
time, it makes it about three times slower. It is similar to sike in that it's
really nice small keys, but somewhat slow. On the other hand, this is still very new,
it's just from January. So we're still figuring out ways to make it faster,
whereas, well, sike has been doing a lot of work getting to the speed that they
have now. So there's hope that this will get faster, and there's some hope it will
remain unbroken until next year, but, well, I'm not sure yet where I'd put my
money, at the, at this moment I think actually CSIDH has a better chance than
sike of surviving, but who knows. Don't use it for anything yet.
DJB: Speaking of broke, there's a lot of people who are investing
in crypto currencies, - *laughter*
DJB: - and I think, I think it's Nick Mathewson's fault, this whole quantum-
cyber blockchain idea, if you know something earlier than 2016, well anyway,
there's variations of it since then, like quantum AI blockchain, apparently you can
buy the t-shirt. We have about 10 minutes left, so I'd like to finish things off
with some comments on software. Now this is looking back at 40 years of public key
cryptography, well RSA was from '77 or so, the McEliece cryptosystem from '78, and
then, well, here's some, some schematics of what the software quality has been in
cryptography, on a scale of "good", "bad", "terrible", and "horrifying". 1978, I
don't actually know, I haven't seen software from back then. By 1988, it was
clear that the software quality was horrifying. By 1998, it had moved up to
terrible. By 2008, it moved up to bad. And by 2018, it has jumped back down to
horrifying. *laughter and applause*
DJB: And of course a major contributor to this is all of these NIST submissions,
which have code written by mathematicians, who barely can implement anything and
certainly don't have good code quality. There's occasional submission teams that
have people who can write code, but in general, if you, well, for a good time,
pick up a random - TL: McEliece is fine!
DJB: Yeah, the classic McEliece code is fine. There's other submissions where the
code is is fine, but if you just take a random submission and look at the code,
it's, well, interesting. If you would like to find out where the software is and
download it. *laughter*
DJB: Yeah, NIST doesn't work very well. I did look, archive.org has, like, you
search for "NIST round one" on DuckDuckGo, and the top link is to the NIST page, and
then you take the URL for that, put it into archive.org, and I tried a few of the
submissions and the zip files that NIST prepared with the specifications and the
code, those are available from archive.org. I guess they got most or all
of them. You can also look for more than half the submissions, there are upstream
websites with newer code. NIST has not updated the code, but lots of submissions,
the submission teams have, lots of the fastest code, and even some faster while
improved code, is available in our SUPERCOP benchmarking framework, so this
is the system for unified performance evaluation related to cryptographic
operations and primitives, bench.cr.yp.to, and this one has, well, 170 primitives
from 40 of the 69 submissions. Might have accidentally left out all of the patented
submissions, well, the SUPERCOP policy is anybody who sends us code to put in, we'll
benchmark it, it doesn't have to be unpatented, it doesn't have to be secure,
we benchmark MD5, we benchmark RSA-512. But anyways, there's 40 submissions where
code is in there, from other people or from me painfully going through getting
code to actually work. The primitives are, for instance, RSA-512, and RSA-1024, and
RSA-2048. They're all RSA, but they're different primitives, or different
mathematical functions with different security levels and, well, in these
submissions, there's typically three different security levels, sometimes more
choices, sometimes less and then a lot of the primitives have multiple
implementations, like reference code and optimized code for different platforms
maybe. So, okay, a lot of those are collected in this benchmarking framework,
all with the same API. libpqcrypto, I think I might have a few minutes to say a
little more about this, libpqcrypto is focusing on having an API which is
suitable for cryptographic deployment in the future. If you imagine that the
implementation quality of the underlying crypto is dramatically improved, at least
that interface layer is supposed to be something that you'll be able to use. Some
more examples of things out there, pqm4 is a library optimized for small ARM
microcontrollers, the ARM Cortex-M4, or pqhw is for FPGAs, and this last one,Open
Quantum Safe, that one, they don't have as many primitives maybe as libpqcrypto or
SUPERCOP, but what's cool about that project is, they've got working
integrations of all of these into OpenSSL and OpenSSH. So if you're in, say the TLS
world, then that's clearly the way to use these post-quantum proposals, at least
quite a few of them, inside TLS. Okay, let me look a little bit at libpqcrypto and
then we'll finish this off. There's lots of cryptographic libraries which give you
a nice, simple API for hash. They'll have some simple function like sha256, which
takes a message, okay, in C you have to say there's a pointer to the beginning of
the message plus the length of the message, and then gives you back some hash
of some 256 bit, 32 byte hash. In a higher level language, of course, you say
something like "h = sha256(m)", and m knows what its length is, but in C it
looks like you have h and m and the length of m as arguments. Why not do this for all
cryptographic functions? Somehow, it's really weird, lots of cryptographic
libraries just have a nice, simple interface for hashing, and then if you
want to do something like public key signatures, it's, well, okay, first we're
going to find the factory, which is producing the keys, while the generator
method for the key, blah blah blah, and well, you can just say, and what
libpqcrypto does is, it simply says, you sign something, with whichever signature
scheme, you have to tell it, well, I'm going to put the signed message somewhere,
and then the length of the message is an output, the message you're signing and the
length are inputs, and your secret key is an input. And then it just takes
everything in wire format, produces everything in wire format. You don't have
to have conversion functions, input/output serializations etc. This is actually an
API that goes back to, we've been doing SUPERCOP for many years, and SUPERCOP, the
salt (NaCl) library, libsodium etc. are all using the same API. And this is
something which, actually people have measured the impact on usability of
cryptographic libraries depending on the different API provided by these libraries,
and so we're pretty confident about benefits of having a nice, simple way to
use crypto. NIST looked at this and said, well, ok, yeah. People should submit
something to the post-quantum competition using this API, but they didn't have test
code that people could use to make sure that they were following the
rules. They didn't require that everybody pass any particular set of tests and they
accepted submissions which didn't work, for example, in SUPERCOP. So, well, ok,
that's why I had to do a bunch of work to integrate a bunch of submissions into,
into SUPERCOP. But it's been sufficiently close to everybody using this that there
has been a lot of code shared between these different projects, Open Quantum
Safe is also starting from the same API and then providing higher level
integrations into OpenSSL and OpenSSH. OK. There's a bunch of different signature
systems and a bunch of different encryption systems in libpqcrypto. Here's
an example of what the higher level API looks like in Python. If you want to use
libpqcrypto and sign a message, well first somebody has to generate a public
key and a secret key using the pqcrypto library. Signature system, here's one of
the signature systems; Sphincs is a stateless hash-based signature system, you
don't have to record anything when you sign message, and then 128 is security
level 2 to the 128, using the SHA-256 hash, and well, you just have to know this
name and then you say, give me a key pair, sign a message using a secret key, open a
message using a public key. Now this is not "you get a signature and then you do
verify of a message and a signature". This is another little API detail, designed to
protect people against screwing up. There's lots of applications which verify
signatures, and then if the verification fails, nobody's ever tested it, and the
verification failure is ignored. What actually works to protect application
programmers is have an interface where you have a signed message as one bundle, it
goes into the opening a signature, opening a signed message and producing a message,
and the cryptographic library does not produce a message as output if the
signature was invalid. So the signed message is produced, is handled by the
cryptographic library producing a message if the signature is valid. Also there's an
exception being raised, but even if you ignore the exception in Python or if
you're using a lower level language without exceptions, then you just aren't
given back a message. This is what lots of little thought that goes into the API.
Maybe a bigger example in Python; this is a whole thing of using the library,
generating a key, signing some random message and opening the message. OK. What's
going to happen in libpqcrypto coming up is, first of all, one of the big problems
with code quality is there's lots of exposure to timing attacks. I saw a great
talk earlier today about Spectre, and there's lots and lots of these attacks,
and part of fixing these attacks is fixing software, along with we're going to have
to do lots of hardware fixes. There's been some work on some implementations to fix
this, but much more is required. Need a lot more work on correctness. Lots and
lots of the code doesn't even pass address sanitizer. And this was, I don't want to
tell you how much pain to get code working and address sanitizer, where, I mean
anybody writing code professionally is going to be using these automatic tests as
they're writing the code, and this is something that just doesn't happen when
you ask a bunch of mathematicians to write code. Formal verification. We'll do much
more than testing and do much more than, say, address sanitizer does and much more
than even an expert auditor will do. That formal verification is going to guarantee
that your code is doing what it's supposed to for every possible input, which I used
to be very skeptical about because it seemed so painful to do for any realistic
code, but I've started getting much more enthusiastic about it, because the tools
are getting much much better. And one example of something I did was a sorting
verification, where some really fast sorting code is actually completely
verified to work correctly, the machine code is verified, so you compile it, even
if there's compiler bugs, then the machine code is what's verified, so the
verification isn't going to rely on some compiler being correct. This is using the
angr toolkit, also, I don't know if there's any Trail of Bits people here,
Manticore I understand has similar features, I used angr, but, well. There's
really cool tools out there for doing symbolic execution and as part of that
formal verification. Speed is important and trying to get the code volume down,
there's lots of duplication, we need more internal libraries to get post-quantum
crypto on a smaller, easier to review code base. And finally, hopefully, at the end
of all this we'll be able to throw away as many primitives as possible and focus on a
small number of things, where we can say "We've really, seriously reviewed these.
We've reviewed the designs, we've reviewed the implementations, and we're confident
that these things are secure". That's it. Thank you for your attention.
*applause*
Herald: Thank you Tanja & Daniel. If you would like to leave at this point, please do
that very quietly, we'll have a short run of Q&A. Signal angel, your first question.
Microphone: [unintelligible] from older submission in code base, are there any
other ones that use smaller keys? TL: Use smaller keys you said?
Signal angel: Yeah. From all the submissions -
TL: Yeah, so code-based cryptography, there's two submissions classic McEliece,
which I highlighted because it's ours, and there's NTS-KEM [CHECK], which has these
gigantic keys. Both of those are using goppa codes, which is what has received
the most analysis so far, but at this gigantic list of - Yep. What Dan is
showing here, several of those are actually code based. So, bigquake for
instance, down there, is a code-based system, then -
DJB: Lake, that's, that's - TL: Bike is one, lake is one, down there,
so lake would be fitting this by saying it's very small keys and signatures and
ciphertext. The downside is, it is using far less well-studied codes. So we need to
see how that develops. Herald: Thank you. For people in the room,
please try to limit your questions to a single sentence. Microphone number 3, your
question. Microphone 3: OK. How exactly do you
define post-quantum crypto? I mean, you have Shor's algorithm, you have the other
algorithms, but do you say, OK, it's just secure against factoring, discrete
logarithms, or do you also take into account optimization problems and stuff
like that? DJB: Yeah. So, I mean the definition
is, we're trying to protect against any attacker who has a big quantum computer
and we have a rough understanding of what quantum computers can do, because they're
limited by the laws of quantum physics. Which tells us that, OK, if you can build
a computer that supports what are called Toffoli gates and Hadamard gates, then you
can, well, it's not completely proven, but it's very plausible that you can simulate
the matrix at that point, a quantum matrix.
Microphone 3: Yes, but that's the universal model.
DJB: Yes, you have a universal quantum computer at that point. The problem is,
how do we know, even if we say, well OK, by believing that quantum physics is
everything we can do in the universe, that tells us we have a computation build out
of Hadamards and Toffolis. That doesn't tell you what kinds of algorithms you can
put together. And there's this big problem that's always been a problem for
cryptography, is trying to imagine what all possible algorithms are, and sometimes
people miss something. And so if somebody ever tells you, "oh, the system is
provably secure, there's, there can't possibly be an algorithm which is faster
than this to break the system", no there's no guarantees, and lots of people have
been overconfident and burned, because there is actually a faster algorithm.
We've had a lot of work on people trying to figure out good algorithms using
quantum computers, for instance for the sub-exponential attacks that Tanja was
mentioning against CSIDH, and that's something where, there's a long history to
those attacks, starting with Cooperberg's algorithm, and this is going beyond Shor's
algorithm and Grover's algorithm. And it's really important to look more at what sort
of quantum algorithms could attack cryptographic systems. There's been some
initial work, but there definitely needs to be more.
TL: I mean, our attacker is allowed to do whatever they want. That's why I'm showing
this as attacker. The attacker is not playing by the rules. The only thing we
know is our attacker has a quantum computer.
Microphone 3: Okay. Herald: Right, signal angel, your next
question. Signal angel: Question from the Internet.
Size does matter, but what about the performance of post-quantum cryptography
compared to classical algorithms for embedded or FPGA devices, for example of
firmware signing or communication and encryption?
TL: OK. So on the big list, and quickly firing up. pqm4, that's using a Cortex ARM
M4, so that's a rather small device. They did not implement all algorithms and for
some of them they said, it is very cumbersome to do with the big keys. So
yes, it's more of an issue. I mean, we're spoiled with elliptic curves, just having
256 bits there, and all the systems are larger than that. CSIDH is the closest you
get, but then it has the big computation. But there is effort, and these smaller and
more fitting systems have been implemented. Hopefully we'll get better.
Herald: Thanks. Microphone number 4, your question.
Microphone 4: You said, when Google did some tests, that said it's just too slow,
they cannot really use it. Would the solution be acceleration units, like used
for AES in CPUs? TL: So, Google was excluding the use of
the supersingular isogenies based on speed. I assume that's what you mean,
rather than the big ones with bandwidth. I don't know all the details of it. My
assumption is, it was factoring in also the security, like how much time have
people spent on analyzing it, which made them more comfortable with the structured
lattices than the supersingular isogenies. You can speed things up if you have a big
engine, which would be manufactured to do finite field arithmetic, but that is much,
much bigger than, say, an AES engine. DJB: Maybe just an extra comment. I think
that the choice they made of NTRU-HRSS is really an excellent choice of, it's
something which is small enough to fit into most applications, I mean 1,000 bytes
or so, it's much bigger than elliptic curve crypto, but compared to all the data
we tend to send around, it usually fits, unless you got, like, some really small
communication happening, then you usually can fit a kilobyte or so, which is the
NTRU-HRSS sizes. And it's something which, it's got some history of study. I would be
the last person to say that lattices are definitely secure, and we actually, our
NTRU Prime submission is worried about ways that something like NTRU-HRSS could
maybe be broken, but there's no evidence of any problems, and NTRU has held up for
about 20 years of study without being broken. So, it's also reasonably fast, so
it's a reasonable compromise between the different constraints of trying to have
something secure and not ridiculously big, and, well, if it gets broken, then
we're in trouble. But hopefully it's okay. Herald: Thanks. Signal angel. The final
question please. Signal angel: The final question. Can
CSIDH drawn on a hardware accelerator make for regular elliptic curves, or is it is
the handling of isogenies more problematic?
TL: All right, so depends what your hardware accelerator has. If it's like one
of fairly generic elliptic curve arithmetics, you can probably use it.
We're getting some speed from not using elliptic curves in Weierstrass form, but
Montgomery forms, so you probably would want to modify the accelerator they're
currently using to fit this better. Also, most systems are optimized for 256 bit
elliptic curves or 384, with 512 bits we're a little bit outside, but most of
the operations would be looking just the same. The most time we spend on doing a
big scalar multiplication, and then we have some operations in these isogenies,
but they are fairly similar. If you have, like, the field arithmetic built up, you
can just put these together and have an isogeny computation as well. So yes, it
can get faster. As I said, this is from January, we're still working on the
security analysis, so don't build any hardware, at this moment, quite yet.
*laughter* Herald: Thank you so much. Please give
them a huge round of applause for the talk.
*applause*
*postroll music*
subtitles created by c3subtitles.de in the year 2020. Join, and help us!