 The next talk is again on fbj implementation this time for Sphinx 256. It's a joint work between Doreen Ahmet, Andreas Curiga, Paul Spindon and Doreen is giving the talk. Okay. Thank you for the introduction and welcome to my talk So we all know that the clock is ticking and as soon as the hardware is bid enough and ready It will break today's public key encryption signing so which is based on RSA and a cleat curve cryptography The good thing is that at least hash functions will stay alive. Although they lose a few bits in security What I will talk today is I make a short introduction about the hash based signatures, so this talk is all only about signatures and Then I show the key ideas of my Implementation about Sphinx 256 and I have some new results about the Sphinx plus, which is one of the sheen in the NIST post-quantum competition So post-quantum signatures algorithm enables Signure signing even when the time of quantum computers arrived There are several Approach for post-quantum Signed signing there is also this website which we hear from the post-quantum zoo and There are these lattice-based core space and so on but whenever we do signature we rely always or on hash function because line one of almost all signature sheens have Take the hash from Digist so they all lie on the Security of breaking the hash function and hash-based signing algorithms just only rely on the security of the hash functions So hash-based signature sheens are just the most conservative choice in this Case because we are rely only on the hash function nothing else So let's go back to the 19. I don't know 70s 80s from the lampard one-time signature sheen I Make an example just for 256 bit security and we have all Parameters that are just 256 bit longs the first thing we need is a 512 random numbers which are Unpredictable and for all random number we calculate its hash The X are the random number and why the corresponding hash of X and And all the wise is now our public key which we can publish and Now if we sign We take the first line as all hash algorithm We calculate the biggest of the message and then have a look at the bits and for all bits if the Digist bit zero is a zero. I take the X zero zero the next one or it's a one So I take the one and so on and go all this through and give this 256 random number in my signature so a verifier with get the signature can now calculate the The biggest as well and then check if X zero zero Correspond and take the hash it gets why zero zero and so on So and this is simply the base idea of this hash-based signature sheens The problem here is that we can only use such a peak key pair once because let's imagine We I make a second signature. They have already 75% of my signature random numbers Are then in public domain and then otherwise you may find the biggest which correspondent to Yeah, to the random numbers which are already in public So now it's make a time step to the closer and This sheen has been introduced a little bit so that instead of we need five hundred and twelve random numbers, which is need much less and we can sign more than one bit per Per random number. It is paid with a bit more computation time, but it really shrinks the key sizes and More important the signature sizes So what we have so far is a secure signing system, which is quite fast because it's our only hash calls for a small input And but we still can only make one signature per key pair So then we come to the idea of Merkel trees Where we just put some key pairs together. This are the as example for four key pairs We have x and y exist a secret tree with the corresponding public key And let's take just a hash of the public key and then hash some public keys together until we get this structure here So all the ends are a function of the public keys And if we now want to say in with let's say the key pair two we simply put the signature the public key and This two yellow nodes so that the verifier can verify if it takes the hash of n 2 0 and n 3 0 It gets n 1 1 and if you take the upper layer And 0 1 and and see 1 1 Then he should get the top node and so he can check if the public key from the one-time signature is correct and Can therefore all also verify if the whole signature is correct But we still have a problem we have to Have a list where we write which Private keys which key pairs in the in the nodes did we already use? So because if we have I don't know a crash or something of our system We have to ensure that it's not start from the beginning was from the key pair one if we already used it So it's kind of problem and it's called the state-based, which is a criticism of hash by sing term and Now this is where the things came in this thing. This is a group published in 2015 a group around under us hildesing and So the basic idea is make the the Merkel tree just very big so that we can Choose a random start point and then we don't have to make this list and The a big big tree needs a lot of competition because to calculate the public key We have to calculate the whole tree. So the second idea is that they break this Whole tree in small sub trees and every sub tree kind of signs the previous public key and so we can build a really huge tree with less processing power than if you like one big tree and the first thing is that in The very lowest level there. We really sign our message. We add some security margin that if we take the The same note twice in the because we choose it random It's not broken yet. So we can have a few things just on the same starting point and this is the picture from the Things for the day. So that's still from the authors. Thank you Okay, this is about the sheen of Sphinx and What I did is I took the algorithm and put it on a FPGA. So I started with counting How Much processing do I really need? So this is what you see here are the functions and it's mainly the Chacha permutation and the Chacha 12 which have to be and Processed a lot of times And this is also the basic idea for my hardware. It's simply if I have a very fast Calculation for this Chacha permutation. I have a fast signing Implementation this leads to this architecture In the center is the Chacha 12 which can call which can calculate a P. Chacha and the Chacha 12 Instructions and it's a fully unrolled pipeline so I can give a message in on the top and every cycle and It goes through all stages all is unrolled It's at this that's the advantage that there are no marks and the marks is for the rounds because they're just Liner is through and then on the output. I got always a result This leads to very high throughput in the hash function and the system around is just It's just built to ensure that I can really handle one input and one output per clock cycle And if you do hardware implementation side channels are always a team What you see on the left is the sheen again with the horse, which is this few-time signature sheen and This 12 trees up here. So this is just a single channel And What we found so far is that you you can see and you know where it is And if you make so you have closer look on the side channels, you can find out which starting point you choose So the running starting point But we did not manage to get any Private bits because the starting point is always in public domain. It's part of the signature and so for the moment we are Safe with our implementation So but this is not the end because for the NIST Not competition The authors made some changes to the to the scheme It mainly they changed the hash function to show three. So shake to shake And the signature sheen in the bottom is a bit different and they generate mask. I didn't talk about the mask yet But they were in the keys before and now they are see their so they're randomly generated and This just reduces the key size a bit Compared to the Sphinx 256 they have some trade-offs Actually, they published six in in sensation three for every security level and There is always a fast version which the signature is a little bigger and the small versions which is also slower so I took this new algorithm and adjusted my Implementation and as you see it always looks the same than before. It's a little bit more generic because There are the different security levels and the hash function changed Of course, there are also some changements in the control unit in the state machine But they do not affect the prefer performance of the implementation a lot So and here are the results But you can see on a first view. It's especially compared to the presentation before it's quite big But it's easy to get a high Frequency on the hash function because as you may know from the char competition And especially char three is very good for hardware implementation and you get a high throughput. There are no additions or so It's just combinatorial Processing's and this is really good for hardware Our latency is in the is in milliseconds, which is maybe comparable to some RSA implementations But they are quite big, but it's not huge So let's see it this way here. You see this red hearts. This is I love FPGAs and this is why I put this one and the blue dots are the performance result of the Outers for Sphinx plus, which is in the NIST competitions And they have a second instantiation with the horror car hash function where they have an accelerator on their processor and the blue to green compared is more or less a factor of 10 in speed and Compared to my FVGA implementation. I got more than a factor 10 again So compared to only the processor without acceleration. I'm more than a hundred times faster An interesting side note here is that the Sphinx 256, which is the red one Performs quite well compared to the Sphinx plus, which is now at the NIST competition. So to summarize I think it's the first implementation of Sphinx. I have not seen any other published I Have got 600 signature preparation if I have one instance on an FPGA. It's a on a Kintex 7 Xilinx and it's quite A robust again side-channel tax Do you have any questions? Thanks Dorian for the talk. We have actually time for plenty of questions. So volunteers first You mentioned that it's protected against such and a simple power analysis. Can you elaborate a bit? Why because as far as I understand it's just a fully Unrolled pipeline Implementation so where does the protection come from? So it's actually unprotected, but it's hard to attack Okay And you didn't succeed. All right, okay. We didn't succeed in attacking the thing is that the key bits are Just part of the input of the hash function And So the Ketserk, I think there are some papers which Attack Ketserk, but I don't know if by heart if from an FPGA implementation and so we have about 60,000 flip-flops in the Ketserk and I turn it all always so there are always 50% of this flip-flop toggling and We made some correlations if we just change a single bit in the input we had like weeks for tracing and We have like a million Traces for the first and we changed some of the input make a million traces again And then a test of course with again a lot of traces and then we try to correlate, but we could not find Difference in the yeah, okay, do you open source source code? No, okay Because it would be nice challenge. I guess I know it's it would be nice So you have actually asked the sales from Company, which all right, it's the IP. So sorry Are there any other questions, okay? Hey, um, which processor did you use for your performance comparisons? Oh The I think that do you mean this one here? Yes. Oh I think it's a 3.5 gigahertz. It's the this one which used the outers from Sphinx I don't know by heart which processor it is It's also not my code, but I know that the outers are in here. Maybe they can give an answer No Okay, so it's a I think it's a sky. It's a sky like with three help gigahertz. So select this You said it's in a product. It's a product available for purchase It's a HSM. Yeah. Yeah Are there any further questions if not let thanks the speaker again