00:00:07.440
so hello everyone uh I'm Rio Kazimara i
00:00:10.800
go by myself 01 on the internet and this
00:00:13.120
is end to end encryption saves lives and
00:00:16.400
you can start saving lives with Ruby too
00:00:18.720
and yes this is the right talk the
00:00:20.400
intended title was too long for the CFP
00:00:23.279
so the slides are available through this
00:00:25.119
QR code or you can find the link in the
00:00:27.279
discord and I tweeted the URL and uh
00:00:30.080
there's also a Japanese subtitled slides
00:00:32.239
and I have a lot of text lot of diagrams
00:00:34.719
I'm and I'm going through very quickly
00:00:36.640
so uh you want to uh you might want to
00:00:38.480
like uh open the slides and follow it
00:00:41.559
along so I'm going to wait like
00:00:44.840
uh 10 more seconds
00:00:55.280
okay let's go then hi or welcome to
00:00:59.039
Matsyama i am very happy to have you all
00:01:01.199
here in Matsyama and in my
00:01:03.479
hometown and I do a lot of stuff uh if
00:01:06.880
anything catches your interest let's
00:01:08.400
talk and also I do a lot of stuff that
00:01:11.360
is more relevant to this talk especially
00:01:13.600
I've been working uh on writing editing
00:01:16.159
and implementing uh standards in W3C and
00:01:19.119
the IETF
00:01:20.960
so uh before we start the usual disqu
00:01:23.840
disclaimer when I talk about security
00:01:25.280
stuff uh crypto cryptographic API is
00:01:28.080
very easy to misuse and uh operational
00:01:30.880
sec security is also very difficult uh
00:01:33.280
the protocol being uh theoretically safe
00:01:35.600
doesn't mean that uh it is safe from
00:01:37.759
operational screw-ups you've seen it on
00:01:39.680
the news um uh I've done my research but
00:01:42.880
I don't consider myself a security
00:01:44.479
expert uh or cryptography expert which
00:01:46.960
means I am not DJ so uh if you're not
00:01:49.920
sure please have your system audited by
00:01:51.680
a security expert before going to
00:01:53.119
production and uh the MLS implementation
00:01:56.320
I'm talking today is uh nowhere near uh
00:01:59.200
production ready uh it passes uh it says
00:02:01.759
most but it passes actually all the test
00:02:03.840
vectors but uh it lacks validation on
00:02:06.079
error cases and uh I've heard like
00:02:08.479
validation is important in this uh
00:02:09.920
today's sess another session so I'm
00:02:12.400
planning to release a full version uh
00:02:14.319
before the next IATF which is which
00:02:16.319
expects on
00:02:17.720
July so I happen to be known as the SMTP
00:02:22.800
guy which means uh stop using SMTP or
00:02:25.760
more like SMTP is dead and I have two
00:02:28.480
problems with SMTP one is it lacks
00:02:30.800
strong identity and uh two it lacks uh
00:02:34.160
end to end encryption so what what is
00:02:37.519
end encryption is that uh it means uh
00:02:41.040
the people who run the service cannot
00:02:43.120
read your messages like uh you uh your
00:02:46.080
usual messaging apps like line Facebook
00:02:48.160
messenger signal WhatsApp they all have
00:02:50.480
uh their each own version of E2E and to
00:02:54.319
talk about why end to end encryption is
00:02:56.239
important we have to mention some
00:02:57.840
international spares so please bear with
00:02:59.519
me for a while
00:03:01.680
uh end to end encryption is more
00:03:03.599
important than ever because uh there is
00:03:05.440
more incre increasing tensions in the
00:03:07.599
international affairs and more powerful
00:03:09.599
people want to control the internet even
00:03:11.360
in democratic countries and end to end
00:03:13.920
encryption provides a safe method to
00:03:15.599
communicate under oppression and in
00:03:17.599
through in war zones this is what I mean
00:03:20.000
by end to end encryption save
00:03:21.959
lives but hey doesn't end to encryption
00:03:24.959
save uh help criminals too uh like
00:03:28.000
people ask like that and yes end to end
00:03:31.440
encryption is being targeted by
00:03:32.879
authorities even in democratic countries
00:03:35.040
uh but even if you ban end to end
00:03:37.120
encryption criminals will still use them
00:03:39.040
because they are criminals and banning
00:03:41.280
end toend encryption
00:03:42.920
disproportionately harms v vulnerable
00:03:45.200
people and uh the internet society
00:03:48.159
published a a blog post describing how
00:03:51.680
en encryption saves children who are
00:03:53.840
otherwise vulnerable on the
00:03:55.959
internet so uh HTTPS or TLS also helps
00:04:00.560
criminals but uh are you going to ban
00:04:02.640
HTTPS or TLS altogether like uh we uh we
00:04:06.080
can't imagine an internet without HTTPS
00:04:08.239
TLS today right so yeah here's the end
00:04:11.200
of the political part and let's go back
00:04:12.959
to talking tech because this is a Ruby
00:04:14.720
guide right yeah and messaging layer
00:04:18.160
security is a more interoperable version
00:04:20.479
of doing end to-end encryption and the
00:04:23.360
MLS provides key exchange uh through uh
00:04:26.800
of through multiple parties and
00:04:29.040
messaging layer security has two
00:04:30.479
documents one is the protocol document
00:04:32.160
which is uh in RFC 9420 and the
00:04:35.840
architecture document which is to become
00:04:37.360
an RFC soon and today is topic is about
00:04:40.479
the implementation of the protocol and
00:04:42.639
now we can say we kind of have RSC 9420
00:04:45.520
on Ruby and because MLS uh brings
00:04:50.080
interoperability in secure messaging we
00:04:52.560
could say that messaging layer security
00:04:54.560
is essentially SMTP
00:04:57.639
yol and I wanted to publish a gem of MLS
00:05:01.680
but the MLS gem already exists for a
00:05:04.160
defunct website and it exists since uh
00:05:07.199
2012 which means it predates the 00
00:05:09.919
internet draft of messaging layer
00:05:11.360
security which came out in uh 2018 so I
00:05:15.680
named my gem Melos which is taken after
00:05:19.039
a novel that is in most Japanese middle
00:05:21.120
school high school
00:05:22.360
textbooks and uh as it's named after a
00:05:25.600
novel that talks about speedrunning to
00:05:27.680
save your friend's life uh we're going
00:05:29.840
to any% speedrun through the messaging
00:05:31.759
layer security protocol uh please know
00:05:33.759
that this uh this will be very quick and
00:05:35.440
this will uh emit major cases too so uh
00:05:40.400
uh MLS depends on HPK hybrid public key
00:05:43.600
encryption and it is uh a form of
00:05:46.479
encrypt with public key decrypt with
00:05:48.560
private key that is used in TLS but more
00:05:50.639
formalized and it works in the
00:05:52.800
combination of a key encapsulation
00:05:54.720
mechanism KM which is a as a a symmetric
00:05:58.880
crypto and uh uh key diversion function
00:06:01.840
KDF which uh which is almost a hash and
00:06:05.400
AEAD authenticated encryption with
00:06:07.680
associ data which is symmetric crypto
00:06:10.800
and the uh these are available in Ruby
00:06:12.880
as the HPKE gem and there are two
00:06:17.120
security characteristics that we want
00:06:18.639
out of secure messaging uh one is called
00:06:20.960
forward secrecy and which means uh
00:06:23.520
messages sent at a certain point in time
00:06:26.000
are secure in the face of a later
00:06:28.000
compromise of a group member which means
00:06:30.240
it's secure against harvest uh cipher
00:06:32.800
text now and decrypt it later uh if we
00:06:35.120
have the
00:06:36.199
capability and uh there the another one
00:06:39.120
is a post compromised security which
00:06:41.120
means uh messages are secure even if a
00:06:44.000
group member was compromised at some
00:06:45.680
point in the past uh in this case each
00:06:49.120
member updates their key so that group
00:06:51.600
secrets are not always encrypted with
00:06:53.280
the same private key that have been
00:06:55.199
compromised in the
00:06:57.000
past okay uh uh so we uh we uh uh the
00:07:02.560
these two uh characteristics are
00:07:04.880
described in this diagram uh forward
00:07:06.800
secrecy is uh secures the message of the
00:07:09.440
past and post compromise security me uh
00:07:11.919
secures the messages in the future of
00:07:14.160
the
00:07:15.160
compromise and to achieve this it's uh
00:07:17.759
it in two person groups it's very easy
00:07:20.720
uh you could uh boost party serves as
00:07:22.880
the same ch uh common secret called a
00:07:25.360
chain key of generation zero then for
00:07:28.479
for the future generations uh when
00:07:30.560
sending a message uh we create a message
00:07:33.440
key with an HMAX shot 256 out of the
00:07:36.160
chain key and uh we get another uh the
00:07:39.680
chain key of the next generation with a
00:07:41.360
hmax shot 256 with a different
00:07:44.440
key and to uh to extend that to three
00:07:48.560
plus person is very difficult because uh
00:07:50.720
if if we were to do the same method in 3
00:07:53.919
plus persons number of the edges in an
00:07:56.080
endnode complete graph is O N squared
00:07:58.319
which is uh very
00:07:59.879
inefficient so we're going to use the
00:08:02.479
your favorite data structure that turns
00:08:04.319
O into O login which is
00:08:07.479
trees and uh we have three parts in uh
00:08:10.879
MLS and this is this is a taken a
00:08:13.199
diagram taken from the RFC and this is
00:08:15.919
kind of confusing because it hides the
00:08:17.759
fact that there are actually three parts
00:08:19.599
to uh doing
00:08:22.520
MLS one is the key schedule uh so a
00:08:26.800
group has a a state variable called an
00:08:29.039
epoch uh which is like a generation and
00:08:31.680
in each epoch then there's a epoch
00:08:34.159
secret which is updated using the commit
00:08:36.680
secret and if we assume we can get the
00:08:39.440
same commit secret uh for each group
00:08:41.760
member uh we can assume that the group
00:08:44.240
secret state the next next gener
00:08:46.880
generation epoch secret would be same uh
00:08:49.200
among all members so there is nothing
00:08:52.000
much difficult uh in this part because
00:08:54.320
it's just a lot of uh chaining together
00:08:56.000
a lot of
00:08:57.800
hashes the second part is the secret
00:09:00.640
tree uh assuming that we have a common
00:09:03.200
epoch secret among uh among the group
00:09:05.360
members uh then we can derive the sender
00:09:08.560
keys uh using the uh uh secret
00:09:13.160
tree and the secret tree is created like
00:09:16.399
this it's a lot of code but it mean uh
00:09:18.480
it's like each user is assigned a leaf
00:09:21.040
in the tree and from the base encryption
00:09:22.959
secret we recursively populate the tree
00:09:25.440
down with a left hash right hash left
00:09:28.080
hash right hash then we get the le uh
00:09:30.080
leaf key uh
00:09:32.200
keys then the actual ratcheting part
00:09:35.279
looks like this in the actual code but
00:09:38.160
it it essentially boils down to this and
00:09:41.040
you can see that it is uh really similar
00:09:42.959
to the two uh twoperson method uh we are
00:09:45.200
going to uh derive the key and nons out
00:09:47.839
of the ratchet secret and also the uh a
00:09:50.560
different secret out of the ratchet
00:09:52.160
secret which is the next generation's
00:09:53.839
ratchet
00:09:55.480
secret so the first two parts were easy
00:09:58.720
given the assumptions but how do you
00:10:01.120
actually get the uh the commit secret uh
00:10:04.240
consistently among each group uh group
00:10:06.080
member and this part is done by the
00:10:08.080
hardest part of MLS which is called
00:10:11.160
treekm in 3km uh it as in the secret
00:10:15.200
tree users are assigned a leaf node and
00:10:17.519
users have their uh leaf key pair the
00:10:20.160
public private key
00:10:21.560
pair and if when a user wants to update
00:10:24.959
their group secret uh the group secret
00:10:27.600
or their leaf key what what uh what will
00:10:30.959
happen is the user will create an update
00:10:34.120
path uh to do that user generates a
00:10:37.360
random uh path secret at their leaf then
00:10:40.480
the parent path secret let's say uh node
00:10:43.920
one's path secret is created through
00:10:45.600
hashing zero's path secret uh three's is
00:10:48.800
created through a hashing one then seven
00:10:51.040
with three then you calculate up to the
00:10:54.399
root which is seven in this diagram and
00:10:56.800
the commit secret of this tree is
00:10:59.120
calculated from the roots path secret by
00:11:01.440
taking yet another hash of the root
00:11:03.360
roots path
00:11:04.920
secret and uh to convey that to the
00:11:08.079
group members uh when zero creates it
00:11:10.959
update path the yellow uh we find the
00:11:13.920
co-path nodes along the update path
00:11:16.720
which are green and if all parent nodes
00:11:20.240
the uh in the tree uh like 5 9 11 13
00:11:24.079
there are if they're all populated we
00:11:25.760
encrypt the path secret to its co uh
00:11:28.320
this to the key of its copath node uh
00:11:30.959
one's path secret will be encrypted to
00:11:32.880
two threes will be encrypted to five uh
00:11:35.680
secret like
00:11:37.160
that and we can see this is possible in
00:11:40.399
a twoleaf tree which is like uh uh a
00:11:43.600
group with two users uh user one which
00:11:46.399
is a node in zero creates an update path
00:11:49.200
so creates a secret at zero takes a hash
00:11:51.920
and one has a path secret then the path
00:11:55.120
secret of one is encrypted to two's
00:11:57.360
public key and as node two knows the
00:12:01.279
private key so the two can decrypt the
00:12:04.079
uh path secret on node one then get the
00:12:07.040
commit secret out of one's path
00:12:09.959
secret but what happens if there are
00:12:12.800
blanks in the tree uh what we do is we
00:12:16.560
calculate the resolution of the copath
00:12:18.959
node to figure out which nodes keys are
00:12:22.040
available then we encrypt the path
00:12:24.160
secret of the update path node to each
00:12:26.720
key uh let's see some examples uh the
00:12:29.760
resolution of the node indicated in the
00:12:31.680
diagram it will be uh a list of 32 in
00:12:34.880
that order uh the indicated node has
00:12:37.839
unmerged leaves uh which will come up
00:12:39.760
later uh so its resolution is itself
00:12:42.240
number three then the index uh the list
00:12:45.200
of uh unmerged leaves which is a list of
00:12:47.360
two then uh concatenate it becomes three
00:12:49.839
and two then uh the resolution of the
00:12:53.440
node which is the root node indicate
00:12:55.680
that will be three two and nine then 14
00:13:00.279
uh you take the left part of uh left
00:13:03.839
part's resolution first and right part's
00:13:05.600
resolution which is a blank so you go
00:13:07.519
left first and you go right and so the
00:13:10.320
resolution is used to figure out the set
00:13:12.480
of keys that are necessary to encrypt to
00:13:15.200
every node under that node
00:13:18.240
so what excel happens is you uh you
00:13:21.760
calculate the path secret for each node
00:13:23.680
on update path one three and seven then
00:13:26.480
to encrypt the one's pass to encrypt
00:13:29.360
one's password secret uh you take the
00:13:31.680
copass node two then uh you take the
00:13:33.680
resolution of the copass node and
00:13:35.680
encrypt it to each key of the resolution
00:13:38.480
you do the same for three and you do the
00:13:40.639
same for
00:13:42.440
seven uh so let's look at an example of
00:13:45.360
how a group changes over time a group is
00:13:48.399
updated through messages called
00:13:50.240
proposals and commits and proposals are
00:13:53.680
uh messages that uh add and remove users
00:13:56.720
notifies an update of users leaf key and
00:13:59.680
it injects pre-shared keys and also
00:14:02.639
commits will fix those uh proposals
00:14:05.360
informations and advances the group's
00:14:07.360
epoch to a next generation and update
00:14:09.839
paths are conveyed in the commit message
00:14:14.160
uh if if a user wants to join a group
00:14:17.199
then uh the users will publish uh their
00:14:20.160
identity which includes their public key
00:14:22.720
uh to a directly directory use uh using
00:14:25.440
a key
00:14:27.000
package and to create to create a group
00:14:30.720
you user A creates a initial group with
00:14:33.440
him uh himself only then to add user B
00:14:36.480
uh A will download the key package of B
00:14:39.279
and then sends an ad proposal including
00:14:41.600
the key package of B then uh commits the
00:14:44.560
uh changes uh A sends a welcome message
00:14:47.440
to introduce B into the group uh to uh
00:14:50.320
add a C into a group of AB the same
00:14:53.199
happens for
00:14:54.519
C uh when adding what happens at the
00:14:57.279
tree is that uh you add the leaf node
00:15:00.079
from the key package in the proposal to
00:15:03.120
uh to the leftmost empty node uh to add
00:15:05.440
to the top uh top graph uh what happens
00:15:08.000
is uh you uh uh the 10 node 10 is added
00:15:12.480
then you uh you will add the leaf index
00:15:15.040
to intermediate nodes above that uh and
00:15:18.399
to the immerse list of those
00:15:21.160
nodes then uh to update a key user let's
00:15:25.440
say user B wants to update user B sends
00:15:27.839
an update proposal notifying the group
00:15:29.680
of its leaf key update then the other
00:15:32.079
the other user A commits that the uh
00:15:34.399
commits that update to include it in the
00:15:36.160
next epoch
00:15:39.199
uh when updating you replace the leaf
00:15:41.839
node of the sender let's say number four
00:15:44.880
uh with the leaf uh leaf node inside the
00:15:47.199
update proposal then you blank all the
00:15:49.680
nodes on its uh direct path up to the
00:15:51.680
root like uh in the
00:15:53.880
blue then when removing a user let's say
00:15:57.279
Z wants to remove B uh Z sends a remove
00:16:00.399
proposal and a commit at the same time
00:16:03.360
uh in this case B cannot decrypt the
00:16:05.680
pass secret included in the commits
00:16:07.759
update path
00:16:08.880
Uh so B will not know the next epoch
00:16:11.600
secret so B's group cannot advance to
00:16:14.079
the next
00:16:15.320
generation uh what happens is uh you uh
00:16:19.759
blank the spec specified node in the
00:16:21.839
proposal let's say number eight then uh
00:16:24.399
you blank the all the nodes on its
00:16:26.079
direct path up the route like an update
00:16:28.880
then in this case the right half of the
00:16:31.120
tree is fully uh fully empty so the tree
00:16:34.000
is shrunk to the uh the left half so now
00:16:37.199
uh instead of seven three becomes the
00:16:39.600
new
00:16:41.000
route and uh if we are going to blank
00:16:44.480
out nodes in the tree uh when are the
00:16:46.399
intermediate parent nodes going to be
00:16:47.759
filled uh they are uh they will be
00:16:49.519
filled during the processing of a commit
00:16:51.920
and when processing a commit the update
00:16:54.320
update path inside the commit will be
00:16:56.320
merged into the ratchet tree then parent
00:16:58.800
nodes are created based on the update
00:17:00.399
path is uh update path is node
00:17:03.400
content and we are emitting a lot of
00:17:06.000
stuff because this is already getting
00:17:07.679
too long for an any% speedrun uh we are
00:17:10.400
omitting stuff like injection of
00:17:11.839
pre-shared keys transcript hashes which
00:17:14.559
means uh the uh hashes that summarize
00:17:16.880
the proposal commits that take take uh
00:17:19.120
took place in the last generation and s
00:17:22.400
uh signing and verification of messages
00:17:24.559
and there are two types of messages
00:17:26.400
public and private which is uh one is uh
00:17:29.120
uh clear text and one is uh
00:17:32.520
encrypted and let's show some
00:17:34.640
implementation tricks that uh I did to
00:17:37.360
uh do this in Ruby and when you say
00:17:39.760
binary protocols you're going to say "Oh
00:17:41.760
it's just it's just a pack and unpack
00:17:43.919
it's very easy." But no it doesn't work
00:17:46.000
like that because MLS has variable
00:17:48.160
length vectors and optional values in
00:17:50.000
their strcts
00:17:51.919
uh variable length vectors look like
00:17:54.000
this uh so there's a leng uh length
00:17:57.039
encoded in the first part then the main
00:17:59.600
main body will be coming up after that
00:18:02.480
the it is based on the variable length
00:18:04.720
integer encoding in quick and you take a
00:18:07.600
two bit prefix and if it's 0 0 the
00:18:10.000
length is will be the next six bits if
00:18:12.400
01 it's the next 14 then if it's uh one
00:18:15.840
one the next uh next 30 bits will be the
00:18:18.400
length so you can encode a vector up to
00:18:20.640
2 to the 30th power
00:18:23.320
bytes optional values look like this
00:18:26.000
there's a flag called present and if the
00:18:28.160
value is present uh the present value
00:18:30.640
was one then the value comes after that
00:18:33.520
you cannot uh uh decode this with an
00:18:36.160
pack and
00:18:37.320
unpack so uh I defined strrus like this
00:18:41.760
to uh because there are lots of strrus
00:18:44.640
in uh uh MLS so I I wanted to have a
00:18:48.480
easy way to define strrus so it it is
00:18:50.960
defined like this in the code uh so a
00:18:53.840
private message have a group id which is
00:18:56.480
a vector epoch which is a uh 64-bit
00:19:00.080
unsigned integer and it has a 8 bit
00:19:03.440
unsigned integer content type
00:19:05.120
authenticated vector data is a vector
00:19:07.600
and so on
00:19:09.440
so the uh we have a class called
00:19:12.559
meorrruct base which has the initialize
00:19:15.760
and new and rest which is the d
00:19:17.360
serializer and the uh raw method which
00:19:20.000
is a serializer and these operate based
00:19:21.919
on the strruct constant that we defined
00:19:24.799
in the
00:19:26.280
class and the d serialization happens
00:19:29.600
like this uh for uh like in 8 then we
00:19:32.799
unpack the in 16 unpack with a
00:19:35.039
difference uh format then when it's a
00:19:37.919
vector you're going call vectors parse
00:19:40.240
parse vec method like and we we have a
00:19:42.880
long list of uh types and sometimes a
00:19:47.200
class let's say uh sender is nested in a
00:19:50.000
framed content so we have a we have a
00:19:53.039
class type which takes another uh
00:19:55.880
argument so we're going to recursively
00:19:58.240
call new and rest on that class
00:20:02.200
uh and we uh we can handle multiple uh
00:20:05.919
multiple instances of a class with a uh
00:20:08.240
that is encoded in a vector like in this
00:20:10.640
classes case and we sometimes have
00:20:13.039
values that depend on other values let's
00:20:15.200
say leaf index only exists when the
00:20:17.360
sender type is
00:20:19.240
0x01 so we're going to call the proc
00:20:22.080
object that is defined u this cgx sender
00:20:25.679
type equals equals 0x01 if that's true
00:20:29.280
uh the predicate content will be true so
00:20:31.200
the uh element will be d serialized then
00:20:34.400
uh if if not if not uh we will get
00:20:38.600
nothing and uh if if we're going to
00:20:41.520
handle trees in Ruby we uh like po uh
00:20:44.640
handling it with pointers like the
00:20:46.400
linkbased trees they are very hard
00:20:48.320
because it's hard to do pointers in Ruby
00:20:50.559
so we're going to do it with an array
00:20:52.400
because uh MLS operates on complete
00:20:54.880
balanced trees and they can be described
00:20:56.960
with a flat array for example the tree
00:20:59.039
on the right is uh list of 0 to 9 then
00:21:02.080
nil as the 10 uh 10 is and uh 12 13 14
00:21:07.360
will be nil
00:21:09.320
too and leaf nodes will be always in uh
00:21:12.960
evenly indexed then parent nodes will be
00:21:15.039
odd oddly indexed in this case and we
00:21:17.600
define operations such as left which uh
00:21:20.159
which index is the left of this index
00:21:22.400
right of this index which is a parent
00:21:24.080
which is a sibling based on the array
00:21:26.000
based trees
00:21:27.480
characteristics and these algorithms are
00:21:30.480
uh conveniently defined in the appendex
00:21:33.120
of the RFC and also this comes with this
00:21:35.440
uh convenient serialization and d
00:21:37.440
serialization
00:21:39.720
format and now uh to finish this talk
00:21:42.559
let's talk about uh the ongoing future
00:21:44.400
work in introducing modern cryptography
00:21:46.400
and Ruby
00:21:48.080
And uh so we talked about how hybrid key
00:21:51.520
public key encryption and it is very
00:21:53.360
nice because it's uh uh it makes it hard
00:21:57.280
it makes it harder to misuse and uh also
00:22:00.240
we have uh uh OpenSSL itself has APIs to
00:22:03.600
do HPKE and I talked about that in at
00:22:06.080
rub Taiwan 2023 but haven't worked on it
00:22:09.039
much since but doing is it do is doing
00:22:13.440
HPKE with uh OpenSSL's API a really a
00:22:16.640
good idea i uh I'm kind of iffy about
00:22:19.919
that because uh the protocols need the
00:22:22.960
whole cipher suit not only the
00:22:24.640
encapsulation decapsulation and open
00:22:26.880
seal uh and we you you also want access
00:22:29.679
to the constants such as the hashes uh
00:22:32.640
hashes length the key lengths uh that
00:22:35.679
the cipher suit defines and the openslk
00:22:40.000
context remembers those values but you
00:22:42.000
have to uh call it those functions
00:22:45.000
separately and some APIs of opensl jam
00:22:48.559
are intentionally undocumented but I'm
00:22:50.320
not going to fix it uh you have to know
00:22:52.080
what you're doing to use uh those
00:22:53.600
undocumented APIs because it is
00:22:55.760
dangerous
00:22:57.360
But I found like some miss missing or
00:22:59.760
maybe not missing but uh hard to do
00:23:01.760
thing in OpenSSL
00:23:03.640
uh I found it confu uh I found the
00:23:06.720
difference of the uh Edwards curves such
00:23:09.440
as two uh x25519 and gener generic
00:23:13.120
elliptic curves they have different APIs
00:23:15.600
and
00:23:17.120
uh so these have different APIs so I had
00:23:19.360
to work uh come up with a convoluted
00:23:21.520
workaround to get a consistent API uh
00:23:24.159
that which is a uh to check the
00:23:27.600
correspondence of key pairs and also to
00:23:31.120
uh get e uh EC public private keys in uh
00:23:34.320
a form that TLS and MLS wants it's it is
00:23:36.960
not uh uh it is not apparent uh for a
00:23:41.440
private key you call pkey.private key.2S
00:23:44.159
in binary but if you do that to a public
00:23:46.559
key it doesn't work you have to convert
00:23:48.159
it to a big number first then you have
00:23:50.159
to uh you have to call TS uh 2S binary
00:23:53.480
later and also uh it has a different API
00:23:56.640
from X2559 and uh generic
00:24:00.760
ECS and uh there's uh additional
00:24:03.679
features shipping in OpenSSL 3.5.0 O
00:24:06.640
which is uh postquantum cryptography uh
00:24:09.039
which is uh algorithms that are strong
00:24:10.799
against quantum computers such as MLM
00:24:13.679
MLDDSA and SLHDSA and there is an
00:24:16.960
internet draft that adds MLKM into MLS
00:24:19.679
and uh if we have uh ML CM API in Ruby
00:24:24.720
then we can uh uh imple implement this
00:24:28.000
uh internet draft in Ruby too and you
00:24:31.120
might ask MLS is end to end encryption
00:24:33.679
so it's a clientized thing right ruby is
00:24:35.919
a serverside
00:24:37.080
lang no Ruby is not just Rails we
00:24:40.640
because we have uh Ruby Wasn't right now
00:24:43.760
so now that I've worked with OpenSSL and
00:24:46.080
embed TLS uh in the Ruby ecosystem uh
00:24:48.799
I'm thinking of uh implementing a uh
00:24:50.960
grand unifying crap cryptography API or
00:24:54.080
a unified API wrapper that calls open
00:24:56.799
SSL uh web crypto API for the browser
00:24:59.919
and embed TLS in embedded environments
00:25:02.960
uh in a consistent way so I' I've wrote
00:25:06.960
a very quick example of calling web
00:25:08.880
crypto APIs random number generator uh
00:25:12.159
and if if we write rappers for all other
00:25:14.720
functions uh all commonly used functions
00:25:16.960
and have a consistent API through uh web
00:25:19.919
crypto and openSSL then we uh we can say
00:25:22.880
that we can have uh MLS in on the
00:25:26.000
browser too
00:25:28.400
so to end this talk let's answer the
00:25:31.039
question in the description of this
00:25:33.480
talk why do you need end to end
00:25:35.760
encryption in Ruby or why do you need
00:25:38.960
even modern cryptography in Ruby because
00:25:42.559
one Ruby needs to stay relevant or else
00:25:45.760
people just go to Python go Rust or
00:25:48.159
whatever the cool kids use these days
00:25:50.559
but actually Python doesn't have an MLS
00:25:52.799
implementation yet so it's a win for
00:25:55.080
Ruby and also two Ruby needs freedom on
00:25:59.039
the internet and the free internet needs
00:26:01.440
Ruby
00:26:03.159
too so that's the end of my talk uh I'm
00:26:05.679
going to give some quick shoutouts uh
00:26:07.760
first shout out to the messaging layer
00:26:09.279
security working group at the IETF and
00:26:11.760
shout outs to protocol implementers in
00:26:13.840
Ruby the list is growing and we have two
00:26:16.320
more talks about network protocols today
00:26:18.240
you're definitely going to that one
00:26:19.520
right and uh next uh shout out to Ruby
00:26:23.039
Kaki 2025 organizer team with uh and
00:26:25.360
especially local organizers who uh uh
00:26:27.840
helped uh us make this conference a
00:26:31.400
thing and more shout outs to sponsors
00:26:34.559
especially the ones I have personal
00:26:36.080
connections with uh code taxon and blum
00:26:38.679
security and I want to give one one more
00:26:41.760
special shout out and it's my
00:26:44.240
grandmother uh she used to live some
00:26:47.279
blocks away from this venue and please
00:26:49.279
note the past tense i wanted to invite
00:26:51.679
her on stage today but sadly she passed
00:26:54.880
away uh last October just before Ka on
00:26:58.039
rails this could have been the perfect
00:27:00.640
opportunity to show what I've been
00:27:01.919
working uh in the Ruby Ruby world and uh
00:27:05.039
encrypt encryption and security
00:27:08.559
uh still I am very grateed and honored
00:27:10.880
that we could have this Ruby Kai game in
00:27:12.799
my father's hometown and I was able to
00:27:14.880
speak in
00:27:16.520
it uh so if you have any questions or
00:27:19.279
comments uh please tweet at me at S01 or
00:27:22.080
I'm also on Fedverse S01 Rubyocial and
00:27:25.520
also find me in drinks uh drinkups or in
00:27:28.400
the venue i am at code tax day two and
00:27:30.799
day four drinkup and I'll I'll be
00:27:32.640
playing music in the Ruby music mixin
00:27:34.720
after day three so thank you