Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/851 Thanks!
Our next speaker is a master's student
from the Netherlands. His name is Don
Sprinkles.
He told me that he's maybe
the youngest speaker on this
and this is Congress.
So if you know anyone, any speaker
younger than 23 just
let him know so that he loses the
contest.
And please pull out pen and paper,
because this talk is
a course done holds
on his university, so this will be
graded afterwards.
Don sprinkles police on
we should share our secrets.
Thank you, Harold, for introducing me and
thanks for inviting me here on this
conference is kind of an honor.
So my name is Don Sprinkles.
I'm from the Rutgers University where
I did a research internship
on an algorithm called Schlemiel Secrets
Sharing.
So this talk is about
kind of a bit about some secret sharing,
but should be a secret. Sharing is not
new and it's kind of about
crypto implementation,
because I would like to make a point
to you.
So first of all, I'm done sprinkles.
I study at Rutgers University where I did
my bachelor's in chemistry.
And after finishing chemistry.
Yeah, I just skip to computer science
because that's obviously better.
So.
On a regular day, I'm currently
doing implementation of elliptic
curve cryptography, and
that's kind of a specific field.
So I would like to share some of my
knowledge with you on how cryptographic
implementation actually works.
So the other people
that are involved in this publication, in
this research are better.
Schwiebert, which is my supervisor, and
Sean Moss, he's a company of
of he's the CEO of a company in Taiwan,
in Taipei. And they do a Bitcoin
well block chain stuff.
So first of all,
because I don't know really what
the mathematical
knowledge of you guys are is.
I would like to ask you, um.
You've heard of this.
OK, that's really good.
Second question, who actually means
why? Who actually knows why we
say this all the time?
OK, so that's a pity because
I wanted to explain this.
Well, actually, I wanted to explain the
second one.
So rolling your own Krypto is a bad idea
because it's not that easy, you
can do stuff wrong very
easily, you can screw it up very easily.
And the second one, you've also
got this case implementing
your own crypto, as we have seen
yesterday in Philippa's stock,
is really hard.
And in his case, one
carry flag in the CPU
can screw up your security
and in his case, have a full
key, uh, full private key recovery.
So in this talk, I'm going to try to
explain to you,
why is implementing your own crypto so
very hard?
And for this, I use the most easy,
most simple crypto scheme, which
is German secret sharing.
So this is my
outline.
I'll talk about what's your secret
sharing is like, Thierry?
How can you do this stuff on paper?
And then I'll go to into the
implementation?
Um, I think this is a better outline.
I'll try to make the first part a little
like easy to understand and the second
part maybe a bit less easy
to understand, but I think
that everybody here can easily follow
this. OK, so
the first part.
Well, we've got this
well, problem, most
people don't really consider this
problem, but, um,
when you've got a key and I always
use the example of a Bitcoin wallet key
because Bitcoin is a buzzword and
everybody will go to it's OK if you
mention Bitcoin one one
once or twice in your abstract.
So you've got your Bitcoin key
and you want to keep your bitcoins secure
because it holds, I think, maybe tens of
thousands of euros in the worst case.
And secure means two things,
the first thing is.
Nobody can ever, like, um,
compromise your secrets,
so your secret has to be secret,
and the other thing is you don't want to
lose your secrets because losing
your secrets also means losing your
money.
And the straightforward way
to back up your case is
to give one or two of your keys to
your bank, and you saw it on a piece
of paper over there, or you take somebody
you really trust, like your spouse
or your lawyer, and you give it
to them.
But then you have this thing called a
single point of failure.
And the single point of failure
is one way that stuff can easily
go wrong.
So instead of giving it
to one person,
we don't really want to give it to one
person because one entity
may break. And this may be like
our house burning down because that's
a piece of paper was stored
below our sink and now
it's gone.
So instead, we want
to split up our trust
into little pieces and every piece we
want to give to some entity
or some person that we trust
to keep it secure for us.
I should be a secret sharing solstice.
But first, let me take some easy
examples to do, like
how could we do this in a simple,
real straightforward way?
And the first idea was just
to be, OK, we have a key or
maybe say 30 characters.
And we just take the first 10 characters
and then the second 10 and a 13,
and we give the first 10 to
a single person and the second
then we give to another person, etc..
Um, but in the case of cryptograph
case, so in the case of Bitcoin
wallet, keys and stuff, then
if you've got the first two, it's quite
easy to brute force the key
to get the last one.
So this is not really secure.
A more theoretical,
more secure approach would be to
be would be to use
some kind of one time pad construction
and a one time bad construction is where
you generate a random key.
And then this key will actually
be used to decrypt a
secret. And in our case, we can generate
two shares.
That's all I'll call them.
Our shares A and B and AMP are
randomly generated and
randomly generated, and B, we
use to generate another share.
C, and we generate these
things by using the actual combination
of M, A and B,
where is the secret?
And then to reconstruct
the secret, we can,
uh, compute the exact combination
of A, B and C and we can see why this
works because C equals M,
A and B and because do X
or cancel each other, those
A's and B's cancel each other and then
we get Ambac.
But here we only solved
the single point of failure problem
in the case of confidentiality, we
only know that if we do this,
then the secret will remain secure.
But this not does not solve
losing one of these shares.
And in our case, if it if backing
up your secret of losing
your secrets, um, is
your problem, then this not doesn't solve
anything. So.
We want something better and.
We have something better and we have
something better for about 40
years now.
So show me a secret. Sharing was
published by Shamir almost 40 years ago,
and it's called a threshold scheme.
And the threshold scheme implies that
we can share
a number of shares from
our secret.
And in the parameters of our scheme, we
can set a number of shares
that is required to restore the original
secrets.
So.
We don't need all the secrets.
We don't need all the sheriffs to restore
the secrets, we can just we'll say
distribute five sheriffs and
then only three of them will restore
our original secrets.
And losing one or two sheriffs isn't
really a big problem for us.
Also, this scheme is
provably secure, probably
secure, is often used as a
term. I don't really like this term
because it doesn't really say anything.
So I used the term information
theoretically secure, which is quite
better information.
Theoretically secure means that if you
don't have enough shares in this case,
then you won't be able to restore the
secrets.
And this is not like encryption
where the key is unknown, where you can
brute force the key, you can try every
key. But the key space is so large that
it is impossible to do this now.
In this case, even with unlimited
power and millions of years
of computing power, we
still will never be able
to reconstruct the the
secrets.
And so
this implies also that this is
resistant against quantum computers
because extra computation power
does not give us
an advantage here.
So here's an example.
Let's say I've got my secret message.
My secret key M
and I want to distribute this
among my friends so that they only
have to share and cannot do anything,
but I would still be able to recompute
my original secrets if
any time I lose
my secrets. So I distribute five
of these shares by by just computing
that.
And on each of my friends, as a share,
I might lose my share sometime in the
future and I'll ask my schanzenbach
and even even if some
of them well, in our case, one
of them spoils the fun and
does not give me my share back because
he's evil, then in our
case, we can still restore the share
because in the beginning
I set the threshold value to four.
So in this case.
Foreshores is enough to restore my
secret, I use these
four chairs, I recompute my secrets
and I got back my message.
Obviously, it is easy to understand when
you see this, so let's go into the
math and the math is quite
fun and this is like
notation quite difficult
to understand.
But I'll tell you anyway,
so for a,
uh, a threshold
scheme of, uh, what we want
to add, the, uh, like distributes and
shares and the thresholds
of recombining to the original secrets.
České, then
we construct a random polynomial
of the Greek minus one.
So a times X
to the power K minus one up
until the lowest coefficient.
But instead of filling in the lowest
coefficients as a random value,
we fill in the lowest coefficient as a
secret message.
So this simplifies to just using a
number.
Then we've got this polynomial P
and we start generating points
on this polynomial.
So four X equals one X equals
do X equals three, etc.
up till. And then we distribute
these points as the shares
and we distribute these points so that
in the end we can use these points to
reconstruct the secrets and
in our case.
So when we got this polynomial,
when we got all the coefficients
of this polynomial, we also have the
lowest coefficients.
So we do form.
So we take these points
and we can make a system of equations
just like back in linear algebra
and this system of equations we can
solve by filling in the X and Y values
of these points.
And if we've got enough points, then we
can actually find the original polynomial
and we will do this.
So in practice we use
a set of formulas called Lagrange
Interpellation, which you can look
up on Wikipedia, but this is easier
to explain.
So I'll explain it by using this.
So.
This may be hard to understand.
So I've got pictures.
First we take 42
was our secret message, obviously,
then we generate a random
polynomial in our case, our first
coefficient is four and our second
coefficient is minus 25.
So you've got this nice parabola
and we can construct points on this
parabola so that we
like, in our case, four points.
And we saw here
three coefficients.
So a threshold is very important.
Um.
We see that if you only have two
points, um,
to reconstruct the secret with the only
thing you can do.
It's well, you can generate
a line and get some random
value on the lowest coefficients
and well, this does not give back
your secrets. Only if you take a third
points, then you can make this parabola.
You can fill in X equals zero
and you could back your secret message.
So solving the
system of equations
is like filling in these X and Y values,
then you can solve this on a piece of
paper. You can do this within, I think,
five minutes and then you will get
your message back, which
is 42.
So this is
all good. Well, we
know this thing is information
theoretically secure, so nothing could go
wrong. Well, well, yeah,
it can.
So this thing is information
theoretically secure for confidentiality,
which means if your secret is secret,
it will remain secret.
But nobody said
you couldn't change the secrets.
So what we all want to do is
to hack this. We just
have a share of dispersants
and we will tamper with this.
Shall we make another share, which looks
like the original share, but actually,
um, constructs to a different secret.
So all we can do this is here is a
polynomial degree to
degree one.
Um, so this is just
line take two points.
If I generate another point
and we generate a new line through this
point by me giving back a malicious
secret or malicious share, then
we get a new point, which is not original
point. And if I have enough information
about the original secrets and if I have
enough information about the X values
of the other shares, then I can actually
choose this point.
So how to solve this?
Well, that's two things
to solving this.
And I'll come back to this later.
The first thing is I knew that the
other points that was shared
was on X equals two.
So this gives me information about
how I can make this specific
slope to get a new value.
And the other thing is I knew something
about the original secrets and show me
a secret. Sharing assumes that the secret
is secret. Well, because it's secret
sharing. But this may not be the case
in every time.
Um, so I knew something
about the original secrets.
So a solution would be to randomize
the secrets and.
Well, you might say, but then you
cannot secret anything anymore.
Yeah. I'll get back to this.
Mm hmm.
So here's part two.
This was my introduction.
Now get to the implementation part,
and this is where most normal
cryptographers stop talking
because they say we've got this
beautiful scheme, it works, we
know how to use it, and now
it's done like implementations.
Magic implementation is easy.
And as a cryptographic engineer, I would
like to make the point to you that
cryptographic engineering is not always
the most easy part of this process.
So, um,
the the story is a bit more like
a company in Taiwan ask us,
hey, we want a library for a secret
sharing any library.
And, um, we ask, how
do you want it? Well, we want it secure
and we want to be able to use it anywhere
on any platform like Android,
iOS, maybe
microcontroller somewhere in the distant
future.
Um, so we think
what libraries are out there.
So as a gesture,
which are the most popular libraries,
um, and we
looked at the codes and
we needed a code that was
really, really secure and also
secure us against channel resistance
and this code.
Either didn't really put it well
to other platforms or it
had some cash or timing
flaws that in our case
wasn't really acceptable.
So this does not mean that these
libraries are bad, just good
gold, good libraries only for our
requirements.
This didn't fit.
So,
yeah, we are going to implement this
thing ourselves.
And I'll take four challenges
that I have had with my implementation.
And these are not the only four
challenges that I had.
There are a lot more challenges, but
I think these are the best, uh,
to explain cryptographic
implementation challenges to you.
So the first thing is
this integrity problem, which we saw in
the last slide from the
from the previous part
and how to encode our values
because we were only using just values
and not like bytes or integers,
and we will have to choose something to
compute and how to prevent sexual
attacks. I'll explain how such analytics
work and how to make
this thing fast in the end,
because I like really fast growth
and I like really challenging
optimization problems.
Um, so the first part.
This integrity problem, we could either
randomize these X values or
randomize the secrets and
these X values are not really easy to
randomize because we we we would need
to choose really big
X values.
In our case, this really slows down our
computation and.
It's the the security
decreases with the number of shares
that we give out.
So instead we chose, OK,
we just randomize the stuff that goes
in the algorithm and we've got a really
random polynomial and nobody can use
anything. So we use
some term which we which is called
hybrid encryption.
So instead of using our message
and pulling it directly through
the secret algorithm,
we instead we generate a randomized
key. This thing, we can pull
through the Shimonoseki sharing algorithm
and then we use this key to encrypt
our secret message.
And so in this
case, we don't have to
pull text to
through an algorithm which is actually
used for, well, numbers and stuff.
And more more importantly, we can
pull this thing through an algorithm
which is used for randomized numbers.
This is how it works.
We encrypt the secrets under my skin,
and when we want to decrypt it, we just
take the key shares.
So the shares of the keys, we get the key
back by recombining the original key
and then we use this key to decrypt
the original ciphertext.
And this week, we will get back
to secrets.
So the second challenge
is how to encode our values.
This may be a little bit hard to
understand why this is a problem for
people that don't know
really the the
the the finite fields
arithmetic stuff.
But it essentially boils down to
this. In the beginning, we had these
numbers and when
we were working in computers, we cannot
just use any numbers because
we're limited.
We're restricted to using like integers,
assigned integers or bytes
or etc..
So in our case, we want to
take a
a, um,
structure, a mathematical structure
in which we can compute
these numbers
and we want to take our original
like this key and we want to
map it to this
structure, to this mathematical
structure.
And the most common thing that we do
in cryptography is we
take a really large brime.
And we take this prime and we compute
modulo this brime,
and this works really well for
spots where we actually have to have
a prime order or
a large order, um,
in our case is not a requirement.
So we will map to a structure
that's that has exactly 256
elements.
So when we have constructed
maps, that has exactly
two hundred and fifty six elements.
Then we can map a bite
to one of these numbers
and for the mathematicians,
the bottom thing is what we use.
We use a finite field reduced by the
final polynomial.
Um, and you'll see later on
this, this allows us to do a
really, really powerful optimization
trick.
Um, and it boils down to the
fact that when we have every
byte separately in our key,
then we can just implement our
algorithm for one byte
and then we just put a for loop around
this. And for each byte
we will seek Whicher
and this allows us to parallelize
over these bytes and the later I'll
show how we do this.
But first.
First thing, rules of cryptographic
implementation in software.
So such gentle attacks are
attacks that are not
attacks on the outputs of an algorithm,
so let's say I put something in the
algorithm, I see what kind of output
it delivers, and then I'll know
if the algorithm did something or did not
do something. Inside channels are a
little bit more subtle.
Instead of taking the output, we take a
property of the algorithm
and we take a property that we can
measure.
And the best example is timing.
We can measure how long an algorithm
takes.
And if we know that a key
contains the one at a certain position
and then it will take a longer time
to compute, then we can
measure the algorithms
computation.
And if it takes a long time, then
we'll know, oh, there's the one.
And if it takes a shorter time, then
we'll know. Oh it, it's probably a zero
and we can do this iteratively
and do this number of times and
we can like take are just
a big statistics tool box and
put a load of statistics on this and
then it's sometimes really
easy to crack an algorithm.
So the first rule of general
resistance is we may never branch
in an algorithm.
So branching is
you have an execution path and you choose
where to go next.
So if statements are forbidden,
L statements forbidden, logical
and logical or are forbidden,
switch statements are forbidden,
etc..
So the second one is
similar to the first one, but uses
a uses a specific trick
and it's called a cache timing attack.
So we use the fact that
if we take something from memory,
the timing may be different.
When it's when a piece of data,
when a piece of memory is already in CPU
cache, then when it
has to be fetched from the main ROM
module.
And this can be a really big time and
we can have really big
bad for nobilities because of this.
And the last one is something that's
often forgotten.
We are not allowed to use variable time
instructions from the CPU
and.
So on Intel processors,
for example, the division instruction
is often variable time,
but also if you look at the manuals of
some maybe older, uh,
CPU's and you also see that some
of those are instructions.
For example, the multiplication may
actually be, uh, in variable
time. So you really have to look out for
this.
And that kind of brings me to my last
point, how do we do this in
a high level language like C
and how do we
do this fast?
And this we do
through bit slicing
and slicing it a really awesome
technique.
So.
We had all these bites
and we shared these bites separately,
so what we can do is we can paralyze
of these bites.
And remember that a
CPU, a CPU
is made up only of logical instructions.
Right.
So we would be able
to to multiply and add
using only logical instructions.
Right.
So what we do is we take
these bites, we take
the first bits of every bite
and we put it in the register.
I will take the second bits of
every bites and we'll put in another
in another register.
And for every bit in
these bites, we will put
it in a separate register.
And in the end, we will have used eight
different registers.
So.
Now, we will implement this algorithm
instead of using normal operators
like, I don't know, division,
multiplication, etc.,
we will implement this thing using only
logical bitwise operators.
So only really bitwise
and bitwise
and bitwise or and
remember, like, this is a
full EDAR for two
bits.
And this is just a really small
part of how the CPU adds
to numbers.
And this is an example of how we could do
this. So.
We'll make this whole thing inside
these kind of circuits and we have to
finished this computation in our
case, we were building on a 32 bit
platform so we could easily run
on all the alarm devices.
And in this case, we have a really large,
more bulky computation, but we also
have a parallelism factor of 30
to.
And well, this
was a 32 bit platform, if we
use a 64 bit platform,
we will get 64
bit parallelism and even
even on AC, X2 and IVAX,
um, this works.
And even if the CPU wouldn't
clock down, this would have worked
in every five 12.
So in the end,
we've got this overview of how we
implement such a
such an algorithm.
So we take this really random
thing.
This, by the way, is one of these other
challenges that I did not talk
about.
And we generate random key.
We encrypt.
We have this key, a secret message.
And then,
uh, and then we take this
key and we slice it
so that we actually, um.
Uh, can can
computers are a Secret Service,
uh, in parallel.
And then when we had done with these
computations, we actually have to undo
the business operation
and we got our shares and
restoring the original secrets is just
the other way around.
We take our shares, we bid
slice up our
share values.
We executed the recommendation
algorithm using this these leogrande
interpolation formulas, we
have to the slice operation in the end
and we use this key
to decrypt and verify
the original ciphertext.
So the performance of this thing
is quite good, I think.
Well.
This these are kind of bad
benchmarks because I did not make
that, uh, like
proper and well,
I made this presentation, did some
benchmarks, not really accurate.
And so a ditzy loop
takes 10 microseconds, etc.
The other things also take 10
microseconds. I have no clue
why the bindings actually are
better than the other ones.
If anyone is able to tell me, please
do.
Um, but in the end,
roughly 100000 calls
per second.
And this is plenty performance.
We don't really need to get
more performance.
But if we do, um, well,
I notice that's about more than
half of the time.
It's in the encryption algorithm and not
in the secret sharing.
So to optimize this further, we
may just use a better encryption
implementation because in
our case we use tweaked salt
and we salt is a really secure,
really good implementation,
which is really portable, but it is not
optimized for performance.
So in the end,
stuff that could have gone wrong.
And the first thing is that.
Well, this is something that we
as cryptographers often see on, for
example, stack overflow that
people think that's encrypting
secrets will make it secure
against integrity, because
if a secret is encrypted,
people will know how to change it
to get another value.
But in the case of cryptography, this
is not the case. People
integrity is only
assumed if you have a
message, authentication codes
or in our case, you use an authenticated
encryption scheme.
And the second thing that could have gone
wrong is timing attacks and
timing attacks is stuff
that actually exists in a
lot of implementations
and.
So this gives me the impression that the
amount of cryptography engineers in this
world, maybe a little bit too small
because otherwise we would have had,
um, constant time,
crypto implementations, for example, in
the ghost in the library, which I
think we may not have,
or, um, we wouldn't
have timing leaks in Decrypt,
which was published recently
in the May the Force Be With You
paper.
So this is kind of a problem
and this last problem that,
um, in this case, it was an armory
and armory is a high security
Bitcoin wallet system and
armory had this German
secret sharing implemented
and they did not generate polynomial
fully randomly.
And I think this led to actually
led to quite
bad variabilities in their
implementation.
So.
It's kind of dangerous terrain to
to implement these cryptographic codes.
OK, here's a sidetrack.
This is something that most programmers
so not limited to cryptographers, most
programmers do not think about
the existence of their codes as a tool
for everybody to,
well, do whatever they want with it.
And I think it's important to
ask ourselves, we have built
this software, what
does this software, how is this software
meant to be used and and
can it be used for
people with malicious intent,
for people who don't actually want to
play by the rules?
And I'm telling you this because
I think that most programmers
will actually have to think
a bit more about this sometime.
So in our case,
we distribute secrets
to the masses
and we distribute secrets
to trust trusted people and stuff.
So I do not really think
that's the malicious user is
able to, um,
to to use this for many malicious
purposes because
power is most of the time centralized.
And Destil, most
of the time allows us only
to decentralize this power.
But the most important thing
is that we are responsible for
writing our own software and
whether I'm making a cryptographic
library or if
I'm making testing code for Volkswagen,
then.
We are responsible for stuff that
happens with.
So to get back, I'll
show you a small demo.
This will obviously grow from.
So I have installed
my secret sharing tool.
Yeah, I try to.
So, uh, can we use
plus. No, we cannot use plus.
We can use plus.
How does this work?
Let's make us.
Let's make us five secrets
with a restoration threshold for
who, uh, what's
my secret?
Well, um.
Yeah, I don't know.
So we've got a
couple of secrets here.
So here's the third one, and
I'll copy paste this into my, uh.
Into my restoration script.
So we start with so I'll I'll
ditch the first one and I'll
take the second one up to the first one
so you can actually see what happens when
we ditch one of those.
Yes, Democrats,
OK, so at the beginning
of the talk, I said to you, do not
implement your own Krypto and.
Well.
I hope that you may have seen
a couple of reasons and have
like I have given you quite a bit of
feeling about why implementing
crypto is hard.
Um, and
so I'll say to you, please
do implement your own crypto, try
to implement crypto, try to understand
how the crypto works.
But if you're not really sure,
if you're not 100 percent sure
about what your implementation does
and if your implementation is secure
against every attack vector,
if it's, I don't know, maybe some
channel resistance or checking
that single carry bits
in this single flag
register, then
put a big warning in bold face
letters at the top of your read me
saying, hey, guys,
this is academic code.
I used to go to learn myself how
crypto implementation works, but I'm not
really sure. I have not checked this with
any cryptographers.
Please do not use this for
your really high, secure,
well, valid software or whatever.
So
that's it.
These are some people I want to thank
and, uh,
my slides can be on my website can be
found on my website.
I've got some extra reading for you if
you'd like to have some, um.
I forgot to register my DECT extension.
This one does not work.
Um, so that's it.
Do you have any questions,
Don Sprinkles?
Thank you very much.
Thank you.
Any questions, please feel
free to assemble behind the microphones
and I will put you through then.
Let's start with number three.
How do you make sure you didn't make
an implementation mistake to have
unit test?
Well, so,
um, that's the
that's the terrible thing, is that in a
cryptographic implementation world?
Um, well, I do have unit tests.
Unit tests do not always
fix your problem because.
Your key space is large enough
that you won't be able to test
everything, and in
the case of my
elliptic curve implementations,
the only thing I can try to do is prove
every single function,
and that's really
error prone and can also be done wrong.
But I'm honestly
not 100 percent
sure about the fact that my
implementation does not contain an error
or any errors.
I checked it.
People checked it for me
and I'm well,
quite sure, but I still
am not this hundred percent
sure. And I think this is with all
code that is security
security relevant.
And I feel.
Microphone number four, please,
first of all, thank you for the
interesting talk, one technical question,
um, I've seen from
your demo that the ciphered
the actual chairs
are quite a bit larger than the original
text. Um, and
my question is, how does
the the number of inform
or the number of bytes, information scale
with the number of
shares you have and with the number of
the required chairs?
OK, so I'll get back to the slide.
Um, the
what we do here is we have this
encryption key and we have
this point, this X value.
So we have to add
one single value for X.
So one byte because we were working bytes
and this is the one, the two to three
and this will be the first bite of
our share. So this as one byte.
And then we'll take this key and this key
has to be randomly generated
and this key in our case, we use
Salsa 20 as an encryption algorithm,
which uses up to four hundred
and fifty six Bilski, which is
32 bytes, and this
adds another 32 bytes.
So in the end, we only have
thirty three bytes which are actually
added to our shares.
But like the amount
of shares that we generate and
the threshold will always
generate the same amount
of bytes in the shares and actually from
the shares alone, you cannot see what
the threshold of the algorithm
was in the first place.
This is also a question.
And we have a question from our IOC
chat.
Yes, first of all, Gillis is
saying on Twitter, thank you for losing
later. So I just thought this
is a big discussion on the IOC, how to
defend against social engineering.
What have some of the shareholders evely
plot against you?
And are there any ideas to remedy this
issue?
Yeah, that's a good question,
um, that's the thing that I
hadn't solved for myself because I
don't have every person's environment.
Um, so my
own recommended stuff in my rehme
and stuff is generate five
shares and fortius will construct your
original secret.
But even this I'm not
aware of it is secure.
In your case. You have to.
Yeah, well, you have to choose yourself
who you trust with your shares.
So I cannot really
answer this question for you.
OK, microphone number two.
A question about the integrity problem.
How exactly does your hybrid
encryption engine solve this problem
and what does your tool if
you put in some tampered
secret?
Yeah, that's a good question.
So, um.
So here we actually
could spoil the secret because
the original secrets, while some
value that we knew.
Um, and
what this does is it randomize
us the value that come
out of any type of secret.
So if we if we tamper with a share,
if we change even one bit, then
the value that will come out of
the secret will be fully random.
Um, because the original thing was fully
random.
Um, and what our
algorithm will do is in the
salsa, twenty one, three or
five authenticated encryption,
decryption step, um,
this will actually fill on
the authentication deck of the ciphertext
and it will say recombination
filled or otherwise the key
or the ciphertext was invalid
and will just say, no, this
won't work.
Mike, one, please.
Hello.
Um, it's similar to a previous
question, probably, but I mean,
assuming I'm trying to protect my
huge Bitcoin wallet
and in that case, I don't want to really
fully trust anyone.
And would
it be an option to.
So I would like to avoid that if
three of my family components
agree with each other, they steal my
wallet, basically.
Is it an option to double up the shares
and they keep 50 percent of it?
Yeah, but then you also have
the larger problem of, um,
of that losing the shares.
Actually, it may be a risk for you.
So, um, that's the tradeoff
here.
So there's a lot like
let me tell you, uh, small anecdotes of
which you can use. This also
is, for example, if you get your
Bitcoin wallet and you want your
relatives to be able to inherit your
wealth after you die, then
you may choose to
distribute your shares among your family
members and people, um,
so that after you die, you can actually
tell them, yeah, OK. Then you're allowed
to reconstruct the secret and then you
can inherit my bitcoin wealth.
Um, and there's also an application for
this. But in your case.
Well, if you have, uh,
if you have a system where
you have yourself most of the shares,
then in this case you always
have, uh, the fact
that, um,
that if you lose those shares,
then you will also maybe
lose the secrets, which in your case may
be what you want.
I see police and DODIG
is asking if just separate them,
separating the message into individual
bites and then applying for each
bite separately, doesn't it suffer from
the similar problems as the electronic
code book mode and stream ciphers, namely
that data patterns are not hidden?
Yes,
so that's also
why we use this hybrid
encryption scheme and so
this hybrid encryption scheme, this
encryption works on the whole block, on
the whole message, and
the secret sharing works on the
individual bytes.
And there is no pattern in there
because we generated this secret key
fully, randomly.
OK, microphone three, please.
Well, I come from a feud which
is quite similar in a
way to the problems that you have
considered here, which are error
correction codes
and well, in my
view, there are a lot of error correction
cards. And for instance, there is the low
density parity check code,
which can be,
from my point of view, of course, in
a way, hacked to
make a similar implementation.
But have you consider it other
codes?
So, um, I did.
And the reason that we actually use this
was not because of real security
stuff, but because,
um, the twenty
one, three or five implement
implementation was, um,
already there.
Um, if I would do this in
a more sophisticated way,
um, a secret sharing is not the only
threshold scheme that exists there.
So we also got, uh, Feldman,
verifiable secret sharing.
And we also have, um, Pieterson,
verifiable secret sharing.
And this is actually secret sharing that,
um, solves the integrity problem.
But they are a little bit more complex.
Um, so that's probably what I
would have used.
Number two, please.
Hi, great
dog.
And back to implementations, could you go
a bit into the relationship between
optimizations both from
compilers and just what we as
programmers tend to do ourselves and
vulnerabilities in
in general?
Basically, what I'm asking is, do you
hate compiler developers?
Well.
So, yeah, compilers
sometimes make assumptions
that are correct in normal codes.
But when I do something in my C-code,
then I mean it, yes, um,
no, I do not hate
C compiler developers.
Uh, I choose to program in C
and the really, really low level stuff.
I actually program in, uh,
assembly, so.
Yeah, well, they
do not have this obligation
to cater to us as cryptography
engineers, so.
Yeah. What can I say.
Maybe it's nice to have an
option where you can say to the compiler,
yes, I really, really want
to use these, these things and what
and please do not assume
that because this
stuff in memory is not read
after this line that you do
not have to really electrolyzer to zero,
because I really want to set this
key value to zero at the end.
And so, yeah, well,
there are tricks and components that you
can exploit and this is mostly the
way we do it when we actually need
to really tell the compiler,
yes, we want to do this this way.
And most of the time, Peter
and I, we look at the assembly code that
rolls out of it and we think, OK, well,
they did it. Um, and yeah,
now it's it's just OK.
And if it's really, really critical, then
we implemented in assembly.
What would be your advice to
you basically told people to implement
their own kryptonite, since we have not
enough cryptographic engineers?
That's a good advice, but what would you
tell them to check for?
How to see if there is going to be
a timing problem.
So.
Yeah, that's.
We you can
always look at the assembly codes
and see if there's stuff.
Well, so the first two items
that I showed you this do not branch
and this do not look up.
Well, compilers won't do this wrong if
you don't put an if statement there, they
won't actually introduce a branch.
And also, most of the time they won't
change an instruction.
Well, like a bitwise instruction, they
won't change it to a multiplication
either.
So if you have these kinds of really
simple instructions, then it's actually,
um, actually,
well, not that big a deal.
Um, and another
thing is this is maybe
not really good for
me to say, but.
Well, there are a lot of
not really good implementations
out there. And as long as you're one is
better than the others, then
it's then it's it's good.
Right.
Microphone number four, please.
So what you said we
don't have the threshold.
And what happens if we
give the reassembly application
more or less shares than
it expects?
Does it try to solve the problem nominal
of the wrong degree or
so? If so, if we
have less than the required
amount of shares, then it will
reconstruct the bad polynomial
and it will try to use the lowest
coefficient of this bad polynomial to
decrypt our secrets.
And this will fail if we
have, um, too
many shares.
Then the
the solving of the equations will
actually just work.
So more shares will not
be a bad thing.
There's only one problem, which is if
you add duplicate shares,
then it will fail with the same
with the first error.
Um, and that's
one thing that I did not solve yet
in a in a crude manner.
OK, number three, uh,
hi, thank you for the talk.
How close is your coat to be used in
production?
Uh, so
do you mean, um, uh,
how much review got and
stuff this thing and whatever
it's needed, uh, how
safe it is to use it in production.
So that's a really dangerous question,
because if I say it's super safe,
then people will use it and it may turn
out that it was not safe.
And then I feel like it's
my fault.
Uh, well, no. So the efforts I did was,
um, I made it and
I checked and checked
it by putting it, um,
uh, so about like having
it checked by other cryptographic
engineers.
And having my method checked
by other cryptography engineers
and in the course see codes,
I expect there won't be any problems
because also the way we do it is this bit
slice slice operations
using only bitwise operations.
Um, it's quite easy
to do this correctly.
And go ahead.
Thank you.
You were talking about optimizations and
I was thinking that instead of picking
one very large prime to use as
a model for a finite field
pick, a prime, which is just slightly
bigger than your secret, is this
implementable? Can you use a variable
prime?
Yes,
but.
Modulo reductions are
tricky in, uh, in
in how constant time, um.
Uh, implementations are done, so
when we do Magilla reductions
in, uh, electric cryptography,
we most of the time we do this
kind of, um, conditional
subtraction.
And this conditional subtraction will be
done, uh, when
only when when a number is larger
than the prime or if, uh,
if a number overflows or
in the flows, uh, during a subtraction.
And this can be quite easily done in,
uh, in software because
we have we can just do this in constant
time. But this becomes a lot harder,
not only when our prime
is, um.
When our prime is not chosen
at, uh, like the time
when we built the software, but
also when this prime is not really
regular, so that's why there
is this prime, which is called to
due to the power. Two hundred and fifty
five, minus 19, which is a really
popular prime to implement crypto if
because it's really easy to reduce
because any number above
that we can carry it
to the lowest limb and multiply it by
19.
But if we do not have a really, uh,
regular problem, then this problem
becomes actually really hard and we would
have to use a multiple library, which are
often not, um, suchan
or resistant.
All right. Thank you.
Number two, please, the way
I understand this, right, the security of
the whole thing depends on
the integrity and security of the
machine. It's being Computron.
Is there any way to distribute the
computation of your secret sharing
of your music, which I now the rent?
Um, I think that there are
threshold schemes. Yes.
Where you, uh,
where you compute, uh, where you
can compute these things separately on
separate computers.
But it doesn't mean secrets are in case
we assume that the dealer's computer
so the person who gets out of the house
is actually trusted, um,
because it also holds the secrets.
So if we trust the computer to hold the
secrets, then we'll also trust the two
computers. Yes.
Yes.
Any further questions?
No, so then, please,
a warm applause for Don Sprinkles.