Date: Thu, 10 Mar 2022 12:11:29 -0500 Subject: [PATCH] added Ramakrishnan Muthukrishnan's slides --- Ramakrishnan_Muthukrishnan/talk.html | 204 +++++++++++++++++++++++++++ 1 file changed, 204 insertions(+) create mode 100644 Ramakrishnan_Muthukrishnan/talk.html diff --git a/Ramakrishnan_Muthukrishnan/talk.html b/Ramakrishnan_Muthukrishnan/talk.html new file mode 100644 index 0000000..e43196d --- /dev/null +++ b/Ramakrishnan_Muthukrishnan/talk.html @@ -0,0 +1,204 @@ + + + + + + + + + Easy, Secure and private information transfer with Magic Wormhole + + + + + +

Easy, Secure and private information transfer with Magic Wormhole

+Ramakrishnan Muthukrishnan ram@leastauthority.com +

Mar 20, 2022

Hi, I am Ram

Long time free software user and programmer.
Long time FSF associate member (membership #255).
Have bits and pieces of code contributed to various free software projects.
Loves tinkering with electronics and radios - Ham radio callsign VU3RDD.
Lives in Bangalore, India.

Message/File transfer landscape

Isnât file transfer a solved problem?

FTP (RFC 765) came out in June 1980.

Message/File transfer landscape

even in 2022, transferring files from one computer to another computer is âhardâ.
involves mostly non-free software running on âcloudâ computers (i.e.Â someone elseâs computers).
reliant on âservice as software substituteâ.
part with private information (phone numbers, email address)
one time transfer is hard.
often not secure with files and other information being available to the service providers in plaintext form.

Magic Wormhole

protocol
program
Originally written in Python and available in most GNU/Linux distributions
Ports to other language runtimes available (Haskell, Rust, Go)
C bindings possible via Go toolchain

Magic wormhole features

no need for any user accounts
no need to know other partyâs user name, email address or IP address.
A short, human pronouncable one-time code is used for the transfer. +
- This code is conveyed to the other side by some other means (by whispering into the ears, by other messaging applications etc).
- Words from the PGP wordlist is used to create codes.
direct connection between peers when possible.
connection via a relay server when direct connections are not possible.
No data saved anywhere.
data that leaves a computer fully encrypted.
synchronous transfer, so both the parties need to be online during the transfer.
connection via Tor.

How it works

4-purple-sausages

PAKE

P - Password A - Authenticated K - Key E - Exchange

EKE -> SRP -> SPAKE2 -> J-PAKE -> O-PAQUE

Properties

Passwords never leave the client, so we are not reliant on a remote serverâs security policies to protect the password.
User credentials (username/password) are never exposed

PAKE

SPAKE2

Let us call the two parties involved as side A and side B.
each user types a (same) password.
we convert the string of bytes that comprise the password into a scalar number, pw. +
- first do HKDF of the byte string to get a uniform distribution.
- then do base256 decode of the byte string. This is the scalar number we use.
We now need to derive a session key.

SPAKE2

Side A first picks a random scalar number x and then generates an element on the elliptic curve: X = x . g where g is the generator element. Same with side B (Y = y . g).
Now they blind these values as follows:
+
- X* = X + pw . M
- Y* = Y + pw . N
- M and N are public constants.
Side A sends X* to side B and side B sends Y* to side A.
Now Side A knows X, x and Y*
+
- Side B knows, Y, y and Y*
Side A now can recover Y and so calculates the key as follows:
+
- KA = x . Y = x . y . g = x . (Y* - pw . N)
Side B does:
+
- KB = y . X = y . x . g = y . (X* - pw . M)

So, after this process, both the sides should end up with the same key.

Now that side A has KA, it can calculate the âsession keyâ by hashing a few parameters:

SK = H(A, B, X*, Y*, pw, K)

where K = KA or KB depending on the side calculating the SK.

Connections

Direct +
- direct encrypted record pipe
via relay when direct connection is not possible +
- same as direct, but each client connects to a transit relay and the relay server connects the two peers and essentially hands over encrypted records from one side to another.

Protocol

APP ID
JSON messages.
Each message has an ack message.
Mailbox can be used to pass short text messages.
For larger files/directories, we use the transit protocol. +
- each client pass connection hints to the other side after establishing a mailbox connection.
- then each client tries to connect directly. If that fails, they connect via a relay.

+ + + + + + +

Future plans

dilated wormhole +
- durable connections: file transfers can resume after network disruptions.
- multiplexed TCP connection.
- bidirectional initiation.
availability of clients on more platforms
more usage of the protocol in the wild (introduce two devices to each other in a secure way).

Questions?

Reach out to me at ram@rkrishnan.org

+ + -- 2.25.1