You Can Save Lives With End-to-end Encryption in Ruby


Summarized using AI

You Can Save Lives With End-to-end Encryption in Ruby

Ryo Kajiwara • April 17, 2025 • Matsuyama, Ehime, Japan • Talk

You Can Save Lives With End-to-end Encryption in Ruby

This talk by Ryo Kajiwara at RubyKaigi 2025 focuses on the importance of end-to-end (E2E) encryption in Ruby, particularly through the implementation of the Messaging Layer Security (MLS) protocol as per RFC 9420. Kajiwara discusses how encryption significantly impacts our ability to communicate securely, especially in oppressive situations.

Key Points Covered:

- Introduction to E2E Encryption:

- Kajiwara highlights that E2E encryption ensures that only the communicating users can read the messages, preventing even service providers from accessing them.
- He makes a case for how it is crucial in current geopolitical climate where surveillance and control are increasing.

  • Practical Application in Ruby:

    • The talk covers the Ruby implementation of the MLS protocol, which facilitates authenticated key exchanges in group messaging scenarios.
    • Kajiwara mentions the code challenges and solutions he faced, specifically mentioning a gem named "Melos" developed for MLS.
  • Technical Mechanics of MLS:

    • He explains key concepts like forward secrecy and post-compromise security which are essential for secure messaging and elaborates on how they are achieved through cryptographic techniques.
    • The implementation details include examples of tree data structures and how they relate to the secret management in a group context.
  • Impact and Future Work:

    • Kajiwara discusses current limitations of encryption in Ruby and ongoing efforts to keep it relevant in the evolving landscape of web security.
    • He emphasizes the need for Ruby developers to implement modern cryptography, suggesting that it is vital for ensuring personal privacy and security on the internet.
  • Concluding Remarks:

    • Kajiwara reiterates the importance of end-to-end encryption in saving lives, especially highlighting its need in vulnerable situations. He encourages developers to consider security implications in their applications and to contribute to the Ruby ecosystem.
    • He finishes with a personal note, expressing gratitude to the community and a touching tribute to his late grandmother.

The overall message underscores the critical role of secure communication protocols and the responsibilities developers have in utilizing them effectively to protect user data.

You Can Save Lives With End-to-end Encryption in Ruby
Ryo Kajiwara • Matsuyama, Ehime, Japan • Talk

Date: April 17, 2025
Published: May 27, 2025
Announced: unknown

"Why do you need End-to-end Encryption in Ruby?"

This talk will cover the Ruby implementation of the Messaging Layer Security protocol (RFC 9420), which enables authenticated key exchange in group messaging systems. By learning how end-to-end encryption in group messaging works, you could be more confident about the security of your daily messages that are sent through your messaging apps. And yes, it does save actual lives.

This talk covers how the protocol works, details of the Ruby implementation, why it is important for Ruby, and the ongoing work on the future of modern cryptography in Ruby.

https://rubykaigi.org/2025/presentations/s01.html

RubyKaigi 2025

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
Explore all talks recorded at RubyKaigi 2025
+66