transcript.md

Welcome everybody to our monthly Gordian Blockchain Commons and Wallet Interoperability Meeting.

So first, what is Blockchain Commons?

We're a community interested in self-sovereign control of digital assets.

We bring together stakeholders to collaboratively develop interoperable infrastructure.

We design decentralized solutions where everyone wins and we are a neutral, not-for-profit to enable people to control their own digital destiny.

We are only able to do this work due to the support from our sponsors.

These are some of our recent sponsors.

However, I have to say it's been a tough year.

We've lost a number of sponsors.

They remain interested in our tech, but they are having their own problems with funding, whether or not it's getting the next round of their financing or other challenges.

So definitely if you're able to be a sponsor, please contact me or you can directly sponsor us on GitHub.

But we can also support your company on specific projects that are related to our work.

If you're interested in this talk to us, in particular, I wanted to thank Human Rights Foundation who basically offered us a grant to continue some of our FROST workshops and work and Foundation Devices for our recent Gordian Seal Transport Protocol funding.

So thank you very much, Foundation Devices and HRF.

We also appreciate our individual sponsors.

Really what this does is show that there is a community of developers out there that are following us and it helps organizations like HRF and other grant organizations to know that we're legitimate.

So our slide here, I'd like to see more on the top than on the past.

So if there's any way you can support us as an individual, it would be greatly appreciated.

How to continue to be involved?

We have a number of different channels to be able to communicate.

They're all on this blockchaincommons.com subscribe link, including getting emails about the Gordian developer meetings, the one you're at today, but also our other workshops like our FROST workshops, et cetera.

This is an announcements only mailing list.

For broader discussions, we have a private signal channel.

Just ask, you know, click on the link and we'll add you.

I can also add you to the Google Calendar invites to Gordian meetings.

No way to automate that easily.

So just send me a mail and I will be glad to add you.

At our last meeting, we had a presentation on PageJoin.

We discussed a little bit about what's going on with SSH envelope, which we'll be talking about more.

We talked about request response and why there's some real power in the request response.

How much that can improve the user interface of our tools.

Really, maybe less user interface, but more user experience.

The table that we showed showed how many interactions with the user could be simplified or made more direct.

So if you haven't seen the request response use case video, it's on YouTube.

And it definitely informs sort of some aspects of the upcoming meeting where we're talking about GSTP as a way to do request responses.

Today we're going to be talking about a update.

We've had, seed tool was one of our first command line tools for interoperability.

It was a reference tool.

We use the CLI tools a lot to test our code and to test our interoperability.

But it was written in C++, which was more challenging.

I think the world is moving more to Rust.

So we did a major move over seed tool to Rust.

We'll be talking about that more today.

And then I wanted to talk a little bit about why we're supporting SSH.

And Wolf will be sharing with us about the new SSH envelope command line updates.

And then we'll close the meeting with a presentation on the Gordian SEAL transaction protocol and hopefully some discussion about what are its implications.

Because I think it's a very powerful tool that there really aren't any alternatives for.

So seed tool CLI, it's available now.

It's updated to our newest specifications.

There's a new user manual.

Wolf, do you want to go ahead and take over?

Yeah, good morning, everybody.

I'm Wolf McNally.

I'm the lead researcher for blockchain commons.

And I write a lot of our specifications and I write code to go along with it as well as libraries that are open source and freely available as well as tools which anybody can use that actually both showcase, exercise, and make available our technologies to everyone.

So let me share my screen here.

You should be seeing my browser window here.

It's not an extraneous window, it's out of my way.

So this is the blockchain commons GitHub account, our seed tool CLI Rust repo.

And we have if you search our account for seed tool, you'll see several different things called seed tool.

One is the original C++, command line tool which Christopher mentioned which we have now deprecated.

Another is this tool you're looking at right now which is the new Rust version which will be adding all our features to going forward.

And the third is seed tool for iOS which is a fully featured very user friendly iOS app which is available in the app store as well as fully open source.

And generally speaking, seeds for anybody who's not completely familiar with this, you might be watching on YouTube or whatever, seeds are cryptographically generated strong, when generated numbers which can be used to derive all kinds of other objects, private keys, bitcoin addresses, things like that.

And we have always felt that this is a natural starting place, a kind of a root of the tree if you will for various kinds of cryptographic operations including those used by bitcoin but also just generally for other cryptographic techniques.

So here we're discussing the deprecation of the seed tool.

Using the Rust tools, you have to install Rust itself which their instructions are really available just Google install Rust and you'll see very easy step by step instructions to installing that on your system.

Did that use the Rust tool cargo install, ctool, cli?

And then from now on you can just basically say ctool and it will do it.

Really briefly here, actually I'm going to spend most of the time in the browser in this even though I can switch to my terminal and I will for a little bit later.

But I mostly want to...

Why don't you show the manual also?

Yeah, so the actual manual which Shannon just finished and wrote is here.

And this is a very thorough treatment of everything in ctool.

There's also a more brief overview document but basically describes use cases.

You want to create a seed, you want to import a seed from another source, you want to translate a seed to different form, you want to back up a seed using SSKR which is our sharded secret key reconstruction which allows you to do social key recovery by splitting your key or your seed into several pieces and giving it to your associates and then a quorum of those shares is required to restore but nobody individually can restore from their shares.

Or you want to create a seed envelope and we'll be talking about envelope quite a bit today.

Envelope is a Gordian envelope, it's a general purpose hierarchical container that supports a lot of very advanced and necessary these days cryptographic techniques like allision as well as which can be used for redaction and other purposes as well as compression and encryption and various things like SSKR.

So we also support an envelope form of seeds.

So the manual discusses installing the seeds, generating seeds.

Now you can generate seeds using the built-in cryptographically strong random number generator or if you want to entirely control that the seed is generated from random sources you can actually flip coins or roll dice or draw cards from the deck and the tool actually supports inputting those forms directly to use as entropy for creating the seed.

Obviously seeds are very sensitive, you don't want to reveal seeds, you want to make sure that you have seeds that are safe and backed up.

And so of course we support SSKR as one form of backing them up, we also support MIP39 which is a very well recognized as well as ByteWords which is a form that we use.

And so we want to basically make it very easy for people to control their private data like seeds and that's what seed tool is all about, it's about generating and transforming seeds into other formats that are useful including backup formats like SSKR.

So very briefly, if you just type seed tool you'll get 16 random bytes or 120 random bits generated cryptographically strong as hex.

If you actually want to input coin flips you say in bits and this becomes an entropy which is then stretched to create the data that outputs and so obviously the more the better when it comes to entropy because like one bit there's only two possible output values whereas if you put coin 32 times or 64 times you have a much better entropy to use.

Same thing with cards, you see six of clubs, nine of spades, eight of clubs, so you can just draw cards purely from the deck shuffling the card in each time and get very clean entropy so you can get much better entropy.

You don't just tell it how big the seed you want it to be is by specifying count.

You can store seed as bit 39 by inputting as hex and outputting as bit 39.

This is exactly what you would use to replicate the seed in many tools that allow bit 39 input.

You can turn bit 39 mnemonic back into hex and this is compatible with all the other systems that use bit 39.

Byte words are four letter words, there's a vocabulary of 256 words, we use this in our UR format, each of these two letter combinations LP, that's the first and last letters of one of these words so each of these words represents a byte but this is the human readable form of that and so it allows transportation, this is byte words, this is the byte words format so if you put the input format is these byte words and the output format is hex by default and so on and we support metadata so you can tag your, if you create an envelope form because envelope is very flexible in terms of very powerful nested metadata if you like.

You can say that the seed tool, you're going to create a seed but you want it to be named my seed, a note and a date for creation date and this is the actual envelope, UR colon envelope, these are the byte words that make up the envelope which is edits root C bar which is the concise binary object representation language kind of think JSON but binary but we have an output format, we say envelope format, this is our envelope tool which we'll be discussing a little bit more later as well, we say envelope format, we feed the same envelope back into it and we get a much better human readable form of this where an envelope is a subject in this case the 16 bytes of the seed with a set of assertions on it, for example a type declaration is a seed, the date it was created, it has name declaration which is we've given here and the note so envelope again supports very rich metadata but it focuses all on the subject which is the actual seed itself which is very easy to extract and use just for its own purposes.

We also support SSKR, seed tool out SSKR groups two of three splits the envelope given into actually in this case we're basically generating a new seed and splitting it into three shares any two of which can be used to reconstruct the original seed.

You can do the same thing with byte words if you wish to have human readable words and so on.

So the whole idea is to have a very fully featured command line tool and like I say our C++ tool had a lot of this functionality going forward, our Rust tool has all of it and we'll be talking a little bit more about our Rust stack later in this conversation but question?

All right well anyway I think that's me.

I think that's a question.

Okay please.

Yeah I had a question about the input of the C2 command if you stretch certain input into an output and you use that input over and over again will it always stretch into the same output?

That's my question.

Yes but you don't do that.

When you generate entropy it's a single use thing.

If you we have as you can see here we have a deterministic flag which you can input a string and that is stretched using the hashkey derivation function to the full length that you request in this case 64 bytes.

As this suggests we only want you to use this for testing purposes because an actual seed uses real entropy generated and used only once.

Yeah of course.

So yeah but yes once the core entropy is generated then obviously the quality of entropy is going to make a difference but if you use the same entropy again you're going to get the exact same seed so the entropy itself should be used once and thrown away and the seed itself should be kept very secret.

There are two main uses so you absolutely can compare this to say Ian Coleman's seed tool on it which is a web page.

We will generate the same values from the same if you have the entire entropy it will generate the same values.

That being said you can still make mistakes etc so we recommend that only for testing the tools to make sure that your wallet which maybe is written in Java is not having any problems with the code and you can test it against Ian Coleman's etc.

Basically there are situations in particular with SSKR where there's additional randomness that is initialized that's actually for each individual share so every time you do SSKR it's completely different value and that's the other place you can use the deterministic flag to make sure that every time you do the SSKR split you're getting the exact same value.

There's a lot of detail in here.

If you compare the seed tool command line versus the iOS app it has a lot more effort in it to make sure that you do the right thing.

For instance if you don't have enough randomness to be 128 bits it will warn you and there's a little button that will say I want to fill in the rest of the bits to make sure I at least get up to 128 and it will fill it for you but then once you've reached 128 bits of cards or whatever it is you can't really do that on the CLI interface so it really is a more advanced tool and thus as much as we can recommend people be careful we always have to say so again.

And you want to add tools have always been sharper tools than GUI apps.

The manual does say how much to use for everything for all of the coin flips, card draws, etc.

It's a simple formula.

Okay that's great.

I was just asking because of course I know you need to diversify all the time every time use another randomness if you're working in production but for presentation purposes and also learning but it comes in handy that you put in exactly the same randomness to see whether it all works.

So that's the reason why I asked.

Yeah and that's what the deterministic platform.

Yeah exactly.

Yeah that was good news.

Thank you.

And there are situations maybe where you want like a series of random things based on the same entropy so sort of like BIP85 I guess where again it might be useful to have like here's my initial entropy and then now I have the 10 random values that I need for whatever application that I'm using.

But we're talking about BIP85 only a tiny bit right after this.

Actually is there anything else Wolf that you're...

None on C tool.

Okay so let me just quickly come back to here.

So you know where are we with C tool?

So C tool at this point I consider it you know it is not just a test release I think we now are saying hey it's you know ready you can the previous C tool had a security review on it and this one does not.

We still have we need to pass the hat at some point to get the same level of security review that we had on the previous libraries for the Rust libraries.

But other than that I do believe it is feature complete as compared to the old C tool CLI.

However there are new features in this and in particular you saw that one of the big advantages of C tool CLI and Rust is that we now support SSKR envelopes which allows us to have the metadata like you know putting in a note in there etc.

There are a few features there that we're not quite sure what the right way to implement is one of which is that the C tool iOS app also allows you to attach a descriptor which is a well known DC bore value so that we can consistently export whatever the Bitcoin descriptor is and that's very useful if you're trying to you know in a multi-sig situation where you don't know which public key this applies to in some you know taproot complex descriptor you can put the descriptor in there so that's very valuable we're trying to puzzle out what's the right way to do that with the CLI version of it we're open to ideas there but we also have this concept of an attachment that allows wallets to be able to put in data that is not as well known as say descriptors are which could include proprietary data like you know this is you know some state value that we want to store so that you when you restore you know the counts are the same as your old wallets counts and things of that nature all of those things are defined as attachments and again we don't quite have a good idea for what you know people need in the attachments and what the command line how do we what are the affordances in a command line version of something with attachments because the whole point of attachments is we don't know what they are you know we're not supposed to know what they are they can be anything you know foundation devices can have something very very specific that they don't have to worry about interop but they want people to be able to back up that's a good place for attachment so you know what's the right thing to do when we receive one or if somebody wants to add one purely from the ctool CLI so that's an open question no commitments at this point for either of those but we're definitely looking for input it has also been suggested that seed tool should support bip85 which raises some interesting complications because we have another tool called key tool that does do some derivation stuff but bip85 is kind of a weird hodgepodge it's only really used by the bitcoin community could be useful beyond that so we've invited the the person who has taken over the bip85 draft on bitcoin core to present next month so we'll have a greater discussion about bip85 and the implications for not only seed tool CLI but you know our entire stack next month just clarification if i make Christopher the coordinate envelope allows you to you know again there's a subject with a set of assertions anybody can place an assertion on envelope an additional assertion and republish that that's totally capable the whole point of attachments is to create a well-known framework for third parties attaching data to envelopes where they can be their knowledge as understood to be either documented in which case there's a url where you can actually go and see where the documentation for the attachment is or undocumented in which case it's entirely proprietary and you might be able to reverse engineer or you might not but but the point is it's the design it's there and designed to be understood to be ignorable if you don't if you don't if you don't know what it means and so whereas you know other assertions placed on envelopes could be anything and you know you may want to just project them outright rather than say we accept attachments even if we don't understand them so i mean if you're backing up a trezor key and you're using it for some nft on some other blockchain the you know a descriptor isn't useful um so you can just ignore it um uh but then you may have some other things you want to store about that nft or its script or whatever that is unique to your particular wallet's capabilities you'd basically put that into uh an attachment so that's an example of the flexibility that we offer any questions on ctool cli or advice or advice what would you like to see it do so go ahead i'm i'm not an expert in arc and all these new things that are happening on bitcoin in terms of but but but essentially they they have they deal in like pre-signed transactions where you need to know the state of the pre-signed transaction so your wallet balance is basically a secret and some pre-signed transactions that you can redeem so i guess these pre-signed transactions would then be something that you could put as an attachment but they would need to be backed up constantly for each time you for each time you you make a transaction i guess yeah exactly and that's actually it was like yeah that is exactly what attachments are for and then you will see in the gstp stuff that we're coming up with which you know the primary client for gstp is uh backups uh you would then be able to have an attachment within a request response that is then uh encrypted and authenticated to a backup server that you can have a persistent connection with over time every time your wallet changes it shards it to the three servers or however whatever methodology you've got um so those are all that's you know absolutely in the design to be able to support um uh you know those kinds of things in the future so uh yes and that would be something to to maybe keep an eye on as well as they develop how to sort of get them to to trend towards using a standardized way of storing state instead of inventing your own forever yeah exactly and that's why we try to get as many wallet vendors at the at these meetings as we can and record them if they're not able to uh to be here so um as far as i know we're the only uh people that are really being open and trying to do this as an open standard um there are obviously ledger um uh you know uh shipped their somewhat controversial um seed recovery technology um and uh but it's you know they chose who can you can recover with and exactly what the you know their trust model is is uh um interesting choices and uh you know we don't believe that you should be locked into a single organization's choice and we're seeing this trend now oh well you know we have to offer what ledger offers so we're going to have our own proprietary set of choices so uh yeah we definitely need to see some um some some more openness on this um let me move on to the next one so um i wanted to first mention yssh so we've just released a major update of uh envelope cli that uh in addition to the keys we already have offers ssh keys and so i needed to talk a little bit about why ssh so um traditionally ssh keys have been used for authentication uh anybody who's done uh you know a direct connection to a unix box or whatever from remote unix box has used ssh keys it's been around for a long time it's it's mature a lot of security reviews etc on it it's not perfect um but it's uh it's broadly deployed but for the past two or three years now um they've been used for code signing um it's been it was built in to git um at least three years ago and github and gitlab and several of the other services now uh enable you to use this and what this means is that you don't necessarily have to use pgp anymore to sign your code um but not just sign your code sign your commits your tags uh be able to make other kinds of proofs about your source code base and uh we have a uh an open source um uh a thing uh called gordian server which basically installs bitcoin core on uh mackintosh or on a unix system and installs tor and does a lot of these other different types of things for you um and uh you know we've just been frustrated with the whole uh pgp signing uh you know techniques pgp is now what 34 years old it'll be 35 years old next next year um you know it's it's a pain uh so we really want to modernize how we secure our code bases and uh this basically would allow us to be able to offer an alternative um and uh to be able to do more with software supply chain including our own software supply chain you know i would like say if we hire radically open software to uh do a security review of some of our source code base they ought to be able to say hey you know these uh commits and these files are um have been reviewed by us as of this particular version um uh envelope has absolutely the capability to express that very very precise uh statement and um uh we'd like to see more of that uh at you know at minimum for our own tools but hopefully others will be interested um uh it also demonstrates something important you know we've been saying probably since the day one of envelope that we really wanted to not um necessarily have uh you know uh what what is sometimes called uh cryptographic agility um but more about cryptographic flexibility like we were not locked into any one particular approach um and we felt like this also demonstrated our flexibility um by supporting ssh and uh wolf do you want to take over from here and explain what we've done okay so um let's see if we go over this here okay so this is our repo for our uh bc envelope cli rest um again in our account bc the bc envelope cli rest this is also available on um uh grates.io you can just do a cargo install bc envelope cli and from then on this is available as envelope and uh again you can start with the same envelope help now this is not a new tool um we've had this for a while uh but what is new in this is our ability to sign envelopes uh using ssh keys and to support that we started out with a we added a new chapter to our documentation there's a fair amount of documentation chapters here um but we added a new one just on signing where we start out by discussing the various signing algorithms now um the one that we prefer and the one that is the default is still shanor signatures signatures um which are you know based on on elliptic curves we've also supported in our stack in a rust stack ecdsa um but now that's actually available in our api or in our tool api as a separate option um again uh but unless you have a specific reason to use any of these other any of these other formats um shanor is fine and shanor is the default so if you sign an envelope and you don't specify a particular kind of signing key or your kind of algorithm then you'll you'll get a short short signature and that's great um so then uh but we do support these various uh uh signing algorithms that are all prefix ssh these are the exact same signing algorithms used by ssh keychain which is kind of the go-to tool for manipulating s stitch keys um and um uh then this document goes into the various kinds of signing primitives we mentioned seeds here we do support ur seed uh and this is again we just talked about seed tool a minute ago um seeds are not signers or verifiers they're not used directly to sign or verify but they're used to derive other objects and in fact you can use uh seed to derive some of these other objects there's a derivation um chart here which shows what you can derive you can either you know our envelope tool can use random random numbers uh cryptographically strong random number generator to generate a private key base or you can provide a seed which will you know based on the seed itself generate the same private key base um so um we go into what you know what uh what these various uh objects are uh the private key base the public key base um and uh and as well as the more specific signing private key and signing public key and the important thing to remember is and before in our previous release the tool you can only use this priv keys and pub keys the private key base and the public key base to sign and verify uh envelop now you can also extract and use the signing private keys and signing public keys and that's because they are tuned to whatever um signing algorithm you specify whereas private keys directly signs and verify snore only um and uh the public key base is actually a bag of two keys uh which contains a signing public key and an agreement public key and this document only mentions the agreement public key and passing um because that's used for cryptography for actually public key cryptography uh primarily um and uh whereas the signing public key is used for the main subject here which is signing and verification so um so uh then we talk about the you know the difference between what we call signers and verifiers because um as you can see these private the the private key base as well as the signing private key can be used as signers whereas they can all be used as verifiers with certain restrictions like again the uh private key base can only be used to sign and verify snore directly but you can derive those things from it that can be tuned to the algorithms you want and again most of the time unless you are really care about using ssh keys for a specific reason like uh the things that are forthcoming in our work with uh git and github then you don't need to worry about a lot of these things you use it pretty much like you always did to sign and verify it so um you know here we are showing a simple example of uh of an envelope which is this is just the envelope this is the subject it's string alice there's one assertion knows bob um i always have to emphasize and we'll see this later when we talk about uh gstp gordian sealed transport protocol that this is what's called envelope notation it's not json it's not um anything else it's actually just a human readable format of the binary structure that is envelopes and you always see a subject at the top and then if it has assertions um a pair of square brackets and then the predicate object pairs which are the assertions and so there's one assertion knows knows bob on the subject alice and these can be arbitrary or arbitrarily complex this is about as simple as it gets uh which is why envelopes even though they're very simple structures can be very rich so in this case where you can see which actually telling it to use its random number generator to generate a new private key base which is again just key material um and then um or use a seed which has been generated by seed tool or something else um and then generate the private key base from that so here you see the the private key base um here we're actually creating a signer which is actually we're actually you know deriving the public key base from the private key base which is a ur sign private key which is by again by default a snore key um uh and uh and then we generate the public key base from that and then we basically go through the example of actually signing and verifying an envelope in this case we're adding a verified by signature assertion develop and i'll allude to this again later in my uh presentation on gstp but it's important to always understand that with envelopes these assertions are on the subject only in which case all we're verifying here by the signature is the subject not the nose bob assertion and that's generally not what you want so envelopes allow this feature called wrapping where you actually the curly braces here represent this envelope wrapped in another envelope which allows you to add assertions to the envelope of the whole and this is generally the correct way to add um uh various kinds of assertions to the envelope as a whole that if anything changes inside the the the main of the body of the envelope because this is now the sub this part here is now the subject of the envelope um so any assertions on it like a signature require that nothing inside here change this is now frozen or the signature will become invalidated and then this basically shows the verification process and then we get into actually signing with ssh keys and this is the kind of the main topic here because this is what's new um where we actually are generating a signer and we're telling it which ssh algorithm we want and ssh keys if you ever used ssh keygen you know these keys always have a comment associated with them which is often the identity of the owner of the key which is often the machine the user name and machine that the key was generated on or where you intend the key to be used um so that's where you add this here and then we have again a sign in private key but this is actually now um an ed25519 ssh sign in key um you can also import existing uh ssh keys from existing key files so if you have an existing key file which is often in uh uh privacy encoded mail or privacy enhanced mail pem format um uh uh which is the format that uh open ssh uses you can import that directly in uh envelope import redirect from this file here and then if that's if the password is encrypted if the key is encrypted which often is in ssh uh um in the ssh world you'll be given an opportunity to actually enter the password which will decrypt the password and then put it into the ur format that you can then continue to use with uh with the envelope tool and so this again shows how we have a wrapped envelope here which is this envelope here and then we are signing the envelope with the signer that we generated on the wrapped envelope and then we're formatting the envelope in implementation so we can actually read it and that's what it looks like there that's a sign fully signed envelope signed by an ssh key same thing we divided for the uh the verifier which is the the uh signing public key uh from the from the signer which was a signing private key um and then we use the same things we did before with the shnor key to uh um to verify the signature and we also specify silent here the reason why um you might want to specify this is because often you want to verify as a multi-step process in your pipeline and to do that you want to hand the envelope uh to be verified to the envelope tool and then assuming the verification goes correctly just immediately hand the result of that off the next thing in the in the unix pipeline uh command line pipeline um and so it affords that but if you don't want that if you just want to verify and be silent then you can specify that um and then of course you can again you can export keys so if the shsigner i i i developed earlier i want to export that to the pem format used by open ssh you can do that easily you can also even encrypt it um so if you wish to encrypt it in a form that will be used by open ssh you can do that as well and you can also do that with public keys public keys have a single line format here's the comment so the comment flows through as you'd expect this is the same behavior that you've learned to expect from ssh keygen uh you can even export signatures and the final thing you can do is there's a new sub command info which you can use on a number of different objects but in particular with ssh objects like the signer it will tell you the format it's a ur signing private key the uh a human realable description the algorithm it uses and the ssh fingerprint which is exactly what you get back from ssh keygen as well and even the the ASCII art that ssh keygen will show you as a way of quickly visualize visually recognizing your key and and distinguish it from other keys so that's the general functionality that's now made available in the envelope tool and again we're going to continue advancing the envelope tool with based on feedback and requests we get from the from the community especially those who are sponsors but we have we take every we take everybody's comments very seriously so are there any questions yeah i wanted um have you have you gone through all the possible attacks on those signing keys either the current key attacks or the the data texts and how does the system respond to them um i'm not personally familiar with the tax here you're referring to i think that if there are weaknesses in the ssh key structures we've probably inherited them um and uh i'm not sure we're um adding any new attack surfaces obviously we deal with um you know when we're dealing with private keys in ur format we're generally dealing with the unencrypted form of those and not the encrypted form uh so again because this is a command line tool and because you know command line tools uh we you know we expect that our users know what you know what they're doing or are studying best practices we we hope that they will use them in ways that are responsible and don't expose private information um if you want to you know mention a particular attack i might be able to address that uh more specifically but i'm not familiar with the attacks you're referring to yeah i'll speak a little bit more about this you know yes um there are a lot of issues with ssh keys uh in uh you know how they're distributed their use in uh tofu situations with authentication um but it is you know uh you know uh because it is so broadly used it also has a lot of additional um work and uh uh you know efforts to improve those and we will inherit those improvements we're largely using uh uh you know well-used libraries for a lot of the fundamental code here um uh that being said you know um you know for instance there is a group that is meeting in two weeks in vancouver that's going to be talking about adding quantum keys to uh ssh in case a condom computer uh you know arrives it'll protect uh ssh keys as well and uh will will benefit uh you know as that evolves and matures there are however some real limitations in general with the ssh key architecture as someone who's involved with carry knows um you know there isn't um uh you know really with ssh keys they're generated individually on individual machines um often using hardware devices uh you know i have a i've been playing around with a wonderful little um ssh tool that um uh uses apple's truss zone so uh it will use the touch id on your macbook pro um or uh if you're running on ios it will use the truss zone and face id to secure your keys uh your private keys we don't work with those at this particular point they're you know how the interface to those types of truss zone type capabilities isn't as mature as we'd like it to be uh everyone is kind of a hand crafted interface we hope to have some influence on being able to make that better but there are also other limitations you notice that um although we keep um uh signing keys separate for from um key agreement keys there are a lot of other purposes that ssh keys can be used for so uh this is where uh with using it with envelope and not using the native ssh key mechanisms but use the envelope uh ssh key mechanisms we can add more attributes to an ssh key so we can do things like say it expires there is no date there's no standard for when an ssh key should expire there's no standard for pre-committing to a future ssh key so i've actually been playing around in a proof of concept where the allowed signers file for a github repo is uh actually an envelope and you can basically put future signers as commits um to the uh uh to the allowed signers file inside that repo but then allied them so that nobody can see them uh until they're needed so you know in a you know carry kind of has some features like this i can pre-commit a dozen uh uh you know ssh keys uh expire those and or revoke those as needed um and then when i need to prove that key number seven is the one i want to use now i can basically do an inclusion proof and prove that yes this is an allowed signer for this git repo um this end up ends up making git uh repos um you know a private ledger uh you know for that particular repo uh and uh that gives you a lot of the kinds of things that carry does except for the fact it's a standard format it works with github it works with github um you can use it without envelope if you don't need a lesion by uh lists etc so i think um uh there's some real power uh for us to be able to offer this um uh if there are people interested in it i mean i think we've the where where we're at with envelope cli ssh is um you know it doesn't do hardware it doesn't do phyto it doesn't do a couple of other things of that nature but it is enough for us to be able to demonstrate that we can do the 8020 of what carry and some of the other micro ledger projects do but with straight up standard um you know well supported well understood um uh format which is uh the git format and um uh you know basically supplementing it with uh with envelope um we'll see if there's some interest in that i think that it's a powerful solution um um but we'll we'll see what what uh other people say and give it a try so it's really right now oriented to the process yep uh really quickly i'll point out that we're using a very um respected crate called uh ssh key which is you know uh provides a lot of the sh key functionality we're using it does have hooks for phyto and things like that in it we're not currently using them um but again if there's community interest in that then that is a way that we can extend our stack thank you for that explanation that was great and i i really do think that um for example in kerry um the inventor there's simply says you got to keep your keys secret that's it which um opens up a whole spectrum for other parties to to help you keep your secret secret so uh definitely we will um i will be um on the lookout for keep keep looking out for the the good work you're doing on this side and then hopefully one day i'm able to you know to uh to combine stuff yeah and absolutely the you know our next topic um you know there is nothing that says you have to use the kinds of keys and the kinds of material when you're doing um uh you know a gordian depository uh you know shares with uh um uh you know with the with a request response protocol so you could create your own um the the the share servers don't care uh other than the fact that you know if you put too much data there um they want they're probably going to want to charge you so but we'll talk about that later right now we're going to talk one level below the gordian depository um so um uh well i think wolf has gone over all of this we do consider this uh um version uh 0.9 um uh there are two features in the old uh c++ version of envelope which are envelope dips maybe you want to show the slides christopher am i not we're seeing your face on yeah we're seeing your face on the slides oh interesting um slides or you see in the slides oh sorry it's this new tabs that zoom has yeah i i have the same problem with zoom tabs my apologies no problem i'm on the correct so um you know we don't have the diff support and the mermaid output um so although we've deprecated it uh there are times in which i go back to envelope cli swift to uh um uh to you know to do a uh the mermaid output or whatever um uh the new features obviously generate signer and import and export and uh and info etc is all in um uh the the the rust uh code base now um and you know next steps really is a lot up to feedback from you uh we're not planning on doing a lot of work on this other than if you know someone discovers a bug or in some of my proof of concepts um without you know feedback from the community that this is uh that this is valuable or that our supply chain security for cryptographic code is um superior to some of the existing stuff that's out there there are two um sort of breaking changes if you've already got scripts that are using the old envelope cli uh two of the commands have been replaced to be more specific and that's generally yeah because trish keys and pub keys refers to private key bases public key bases specifically but now we're we're using more than that to sign and verify so we've adopted the more general term signer and verifier um so uh our uh our big topic for today and i think you know really and this is a the culmination of a year and a half or more of a work toward a goal of doing this right is the gordian seal transaction protocol um there's a bcr on it that's been a around for a while envelope request response has been around for a year and a half or so this adds encryption to it or it always implied that you could encrypt it but this is more explicit um uh what's really powerful and new is uh there's a real problem especially with wallets that are hardware devices or have various other kinds of constraints or at a remote place that um there may be state information that needs to be kept uh about the process of the whatever protocol you're implementing under gstp where you you know it could be as simple as you know we're at the third round of five or whatever but it could be other kinds of of of stuff how do you do that in a fashion such that you don't have to store all of this and this is both useful from a constrained wallet perspective where you don't have much room to store all the state um but it also has implications on servers where um uh you know they also don't want to have to always process the state um uh state also can be used uh to create a number of different types of attacks so we can also encrypt the state so we're going to talk a lot more about that in the next half hour or so um uh but i definitely wanted to thank foundation devices who was the research sponsor for this work um uh so uh ken and team thank you very very much and if you're um uh interested in sponsoring other specific work maybe you love you know rss h keys thing or you want to see more of gordian seal transaction protocol let us know um and we'll talk a little bit more at the end uh you know about where do we go from here this is the underlying thing for gordian depositories which allows us to do um things like ledger does for uh various kinds of uh seed recovery work but it can be used for a lot more than just seed recovery but that's our current um model uh wolf do you want to take over sure so can also begin with yeah so um i'm wolf mcknelling i'm the lead researcher of blockchain commons and in this talk i'm going to discuss gstp which stands for gordian seal transaction protocol this is a uh a protocol for transaction on various kinds of peer-to-peer and client server devices uh and we'll explain the motivations for more as we went as we go um but first i also want to thank our research sponsor which is foundation devices and i think we have ken carpenter here today from foundation devices this gstp we started developing with it showed it to foundation and foundation said oh we might be able to use something and so they have generously provided funds to enable us to extend this and the benefits of that are now available to the entire community so we definitely thank foundation for sponsoring us in this regard so i want to discuss briefly our rust stack everything you see here on the right is available on crates.io the ellipses are are libraries or crates and the or everything here is a crate but the the ellipses are libraries and the rectangles are uh are actually command line tools so um in this previous in the previous part of this talk we discussed both the uh ctool cli nbc envelope cli um christopher a moment ago mentioned the depot server which is a way that people can anonymously and securely store small pieces of information could be large but you know often small which are shards of keys which cannot be you know keys cannot be reconstructed from them individually but it's a way of social key recovery and then these things build on these other crates we have we also have the dc bore cli which is a deterministic cbore cli tool that we have and so i just want to point out a couple things here that you know there are transitive dependencies here that we haven't shown like the sskr and pretty much everything else depends on vc rand for fuzz testing and things like that so you know we've simplified the diagram by eliminating transitive dependencies i also want to point out that we ourselves benefit from the open source community that for example our vc ur crate adds dc bore functionality to the ur crate by dominik spiker and so he actually took our spec for ur and our other reference implementations implemented a new third party crate and i said well this is great we don't have to implement our own now but we do want to add some direct dc bore capability so we actually created our bc ur crate based on that and that's what our the rest of our stack is based on but you know we definitely thank dominik for his implementation as well as other third parties who implemented our ur standard as well so we're also going to focus on this particular crate the bc envelope crate this is where our support our direct support for gstp is currently located the bc envelope crate if you look at the cargo.toml file in it it has quite a few different features you can basically use it as is where all the features are turned on by default and that's fine and rust is very good about you know large code base compiling you know stripping dead code and not including what you don't need in your final thing but if you want to actually turn off any of these features for specific purposes you can turn off gstp you can turn off encryption you can turn off whatever you don't want because envelope itself is currently an internet draft with the ietf and it's very spare it's only got one thing that i would call a feature other than its general architecture it's hierarchical kind of merciful tree tree like structure one feature that's kind of inherent to it which is elision but all these other things that we're going to be talking about including encryption compressions available although that's not relevant to today's talk all these other things are are features that are layered on top of that and we have other blockchain comments researcher bcr documents that describe each of those features those are all implemented in this crate and turned on by default so you can use those just by you know batteries are included here so i want to talk about you know kind of an overview or motivations for gstp before we get down into the details obviously if we're describing a peer-to-peer architecture uh you know i just want to acquaint you with some make sure we're on the same page regarding certain terminology we're going to talk about requests and responses where a request is created by a sender and received by a recipient and where the response the roles are reversed of sending recipient in the response fairly fairly straightforward what starts to get interesting is that gstp is very agnostic about the channel you're using so that channel could be the internet using rest or some you know tcpip dp whatever could be bluetooth which has you know various kinds of security built into it but also you can use it with no security at all could be nfc either nfc cards or other tools that that uh related using nfc could be tor which is very obviously very secure but again it's like an extension of of the web or it could be even some like qr codes which have absolutely no security at all our stack actually includes a way of including arbitrary amounts of data in qr codes using multi-part ur's and that's you know the subject of other talks we've done and so on so but you you'd be nice if you had a protocol that could be equally secure with all this because um oops let me do that again um because the one thing you can say is that because these are all consistent you have to assume everything is unreliable and insecure from the start and you'd like something that kind of handles all these cases which is why we designed gstp guardian serial transaction protocol so i want to talk a little bit about the kind of the goals and key components of gstp the first thing we want to support asynchronous communications between peers in peer-to-peer environments where there could be multiple peers chatting back and forth as well as client server environments we want to support multimodal transactions this means using more than one channel as desired so you might start with a qr code and then continue with uh internet protocol or bluetooth or anything like that um we want to support out-of-the-box unique ids for request response parents this is useful for um auditing for making sure that you're matching requests and responses across time and space we want to support bi-directional encryption using public key cryptography including encrypted multicast so if you're actually chatting in a multi-way you want to have multiple receivers we want to have self-signed requests that include public keys for authentication and this supports things like trust and first use or toshu but also enables you to you know immediately see that the person who sent you the message is also the person who owes the private key that signed the message and this is like a standard feature of gstp we very critically and christopher mentioned this earlier we want to support message encapsulated state and this is including having a standard slot for what's called a self-encrypted continuation and this is a black box to the receiver but they are obligated to send it back to you so you can continue the computation once you receive their response and that's also bi-directional both all senders and receivers have the capability of including self-encrypted continuations and then we also in this continuation mechanism we implemented expected response id and continuous timeout mechanisms to avoid things like replay attacks so that's also very useful and generally speaking um i've always been a huge fan of idempotent actions which are actions which should repeated cause no additional effect and so our architecture for envelope for gstp and things like that are designed to while not we don't require it we certainly encourage the design of apis and architectures that that rely on idempotent actions what are the benefits of this well we want to reduce state management we want to our continuations allow peers to offload private state information into the past messages minimizing and ideally eliminating the amount of local state needed for unveiling tasks and this hopefully you know when combined with idempotency increases fault tolerance we want to make this more scalable so especially like in client server situations you know it's not always the case where adding more servers gives you more bandwidth because if they all depend on a set of shared state in a database then there's database contention and so on whereas if all the state you need to continue the the uh the computation is included in the request that you can only you can access because you encrypted it to yourself in a previous step any server can handle the request and so that allows what's called horizontal scalability which is you know adding more servers gives you linear increases in capacity and obviously security self-encrypted continuations making the privacy and integrity of the sender's state information and then we include the expected response ids and timeouts and continuations to help confront manipulation of continuations for like replay attacks and efficiency obviously is a big concern as well so envelope is a binary structure and it's designed to be you know deterministic and minimalistic so you only you only need to pay for what you use so continuations and responses enable things like pagination streaming and increment processing of large result sets obviously you know that if you have used certain REST APIs you might get back a token from the server where space he says if you want to continue this page pagination of this send back this token same idea here but actually much more flexible and very secure so to lay the foundation for this i want to discuss requests and responses as distributed function calls and you know remote procedure calls are nothing new but i want to make clear how we've implemented them using our stack and how it fulfills the the goals that we've just discussed so let's start by looking at just a a Rust kind of generic function signature here it's an asynchronous function which means you know it can be paused and headed off to other threads while it happens it just has a generic name do it has two arguments of two different types the ellipso indicates it could have more and then it has a result which which in Rust basically is either a success type or a failure type and this is all highly relevant to what we're translating this to of course this applies pretty much to any language so this is how that appears as an envelope now earlier in this meeting i discussed the general structure of envelopes envelopes always have a subject which in this case is the the the function identifier and then a set of assertions which are predicate object pairs which essentially make assertions about the subject and that translates in this case to the function identifier and the arguments are assertions on the function identifier these chevrons here essentially are shorthand for seabor tags because again this is a this is a human-readable form of a seabor structure so it's important to realize that you know we're translating it to text and so rather we could just you know spell out the the name this is this is function and starting this parent with parentheses this is parameter but because we do this so much when we deal with what we call envelope expressions here we have a shorthand which is these double chevrons and because this is a human-readable format you never need to type these it's always for output this is not a round tripping format so but it is essential to understand what's going on inside envelopes as you construct them and use them and so this envelope format is widely used but we're going to come back to envelope expressions in a minute but this is essentially what an envelope looks like that translates this so what do we do with this from here so we want to encapsulate this in a request and to do this we we generate um a random id um this is what we call an apparently random identifier which is like a super uuid it's actually 32 bytes which is twice as long as a uuid um uh you know we only show the four first four bytes of it for brevity here um and this is a seabor tag this is also seabor tag so it's an s and seabor tag showing this this arid is a request and this is the subject of the envelope again it had the subject uh the subject has one assertion which is uh the predicate body and then this as the uh the whole expression as the object um i'll come back to that in a moment on the response side it's the same basic pattern there's the same uh uh arid the same uh uh id because it's the response to this is however it's tagged response not request and then it has either uh the predicate result with the success type or the predicate error with the failure type so again i'm going to kind of hammer this home a little bit here um this is the subject of these envelopes in one case on the left side is request with the arid on the other on the right hand side is response with the arid and each of these envelopes has exactly one assertion on it in the first case it's body with the expression in the other case it's result with success or error with the failure i want to point out here that this is the predicate which is um the single quotes indicate this is a known value which in envelope parlance is just actually it's in a small integer so um if you see things in close in single quotes it's not a string not like you'd see in jason file it's actually like two or three bytes maybe um uh as a from a 64 bit um uh known address space you can use strings as well though there's no reason why you can't use strings uh there's no reason why you have to use known values um so again this kind of speaks to the flexibility of envelopes i want to point out that because this is a common mistake people make that on the left hand side that's not the object you know there's predicate object pairs this is just the subject of the actual uh of the actual object and so if you want to see the whole object of that uh of that assertion it's the entire envelope expression all right uh and this is these are examples of complete assertions so just a single argument assertion or a result or or uh error assertion all right so now we're going to look at things from the sender's perspective we have a request uh which has the assertion which is body and the expression which is the uh the uh the object of the assertion and now we want to add the things that make uh gordian sealed transaction protocol useful and what it is the first thing we want to add is on an authentication layer we want to make sure that the receiver knows that whoever sent this owns a private key which is essentially the the key that's been signed with so if we're going to actually provide that public key this so we add an assertion called sender public key and we add our public key base to this this is a schnor signing key um as i mentioned earlier we support ssh keys now um but our stack currently uses schnor keys for everything else where you don't need um ssh keys um and then we also add a sender continuation now this is this is what we want to receive back when we actually are because we're the sender in this case um if we want to uh when we receive back the response to this we want to continue our computation without storing state locally we need to um encapsulate that state here and that state again what you're seeing here is uh you know the capital s state here that can be any envelope it means arbitrarily complex um but we're you know we're just using an identifier for the type here but the thing is we're going to encrypt it so this is now encrypted back to ourselves as indicated by the light blue which is the sender's color here this is encrypted to ourselves only we can read it so we're going to send this and the receiver is going to be obligated to send it back to us um we are also going to include the receivers uh the the recipients continuation which is uh what they sent to us that's encrypted back to them as indicated by the orange color um so this has always been a black box to us we received it maybe at some point in the past but it's optional we didn't receive one we don't attach it um but we don't know what's in here it's only for for use by the receiver um the next thing i do is actually want to verify the envelope by adding a signature and as i've mentioned elsewhere uh because an assertion only uh is on the subject and because the subject is just this string here the request of the request id um this all that would do is verify this we want to verify the whole envelope however so this isn't the right way to do this um what we're going to do you know right that's the actual subject so we'll remove that and this is how we do it correctly so we want to sign the whole envelope and to do that we actually want to wrap the envelope in another envelope and this is a standard feature of envelopes you wrap an envelope and then now the subject of the envelope is the whole previous envelope and now we can add its own assertions to it so now when we add the verified by signature then that we are now um we've been it's impossible to modify any of the contents of the the subject which is the area in curly braces without invalidating the outer signature all right so now we've got a signed request we've also included a public key base so with nothing more than that's here the receiver can verify that whoever is identified here must have the also the corresponding private key so that's the main thing we've we've done there and this is useful for trust on first use and things like that we'll discuss that more a little bit later the next thing we want to add is our layer of encryption so again if we just just like when you sign an envelope that's an assertion only makes uh a an assertion about the subject when you encrypt an envelope you're only encrypting the subject and so if you encrypted this right now you'd basically have the encrypted envelope with the verified by signature and it's important to realize that with envelopes this signature would still verify because um even encrypted structures in uh in envelopes they declare their hash of the unencrypted value so um you could so the signature still verifies you when you transform transform an envelope in this way but we want even this to be entirely hidden because it could lead to correlation attacks that we don't want so we're not going to encrypt that we're actually going to do the same thing we did before we're going to extend the subject we're going to assign the whole envelope we're going to wrap the envelope and then we're going to which basically makes that the whole subject of the envelope we're not going to add any new assertions to it yet but then we're going to encrypt that and now we have a symmetrically encrypted envelope that that's it it's all it is is the envelope now i said symmetrically encrypted but we want to use public key cryptography here so what do we do how do we deal with this all we do is we add one assertion which is called a sealed message and again as indicated by the orange color here this is created using the recipient's public key um it also includes an ephemeral sender that now it's not our it's not our public key in this but it's an ephemeral center we create just for the sealed message and we attach this has recipient to it and this basically means that when the recipient receives it they can use the ephemeral sender's public key which is included and their private key use key agreement to find the actual um to create the um to recover the symmetric key that this was encrypted with so that basically allows you to this is called static ephemeral static ephemeral static public key encryption basically so because on our side we've just created ephemeral sender we're using their static public key and so we've encrypted this entire message in a public key way and we can add more than one of these assertions too if we want and i mentioned encrypted multicast this is where if you wanted several receivers to be potentially decrypt this message you could add more has recipient assertions with um sealed messages that are in the encrypt the symmetric key just to those recipients and then that set of recipients could also decrypt this message all right so this is what is actually sent to the sender so on the on uh sent to the recipient and the recipient side now they're going to reverse this process they're going to use their private key recover the symmetric key and decrypt the original envelope leaving this so now we stripped off the encryption layer and now we have the authentication and request so the next thing this does and this happens automatically in our stack is the next thing it does is it extracts the sender public key you see there and then checks that against the verified by signature and makes sure that those match and that's that's you know an important part of the process to avoid spoofing and things like that but it's pretty much provided as part of the the batteries included nature of our of our russ stack so once that happens that's stripped off and now you have the request the next thing you can do is you have what's called a sealed request structure and then you can parse out the various parts of that including the id the sender the peer continuation which is the encrypted black box that you're going to pass back to the other side again the state which starts out encrypted but now you're now because you're the recipient you can decrypt it it's automatically decrypted for you using your private key and now you have everything you need to actually execute the the remote procedure call to do it with the two arguments once you do that then you compose your result which is either success or failure which is again before uses the the response though the the same id with the response tag and the the result and success type assertion and then we reverse the process again we add the sender public key our sender public key in this case not not the previous sender's public key we add our state continuation but we encrypt it and again this is how this happens automatically in our stack and we add the recipient continuation which is what we're passing back to the to the other side for them to continue the their own computation and finally we wrap it and and verify it with our signature and then we encrypt that and give it the hazard cipient sealed message so that the receiver can the new receiver can decrypt it so it's exactly the same process on both sides so we want to discuss the trust on first use or tofu pairing which is this is what our gordian depot uses it assumes that there's people out there who want to back up their seeds and they want to store a small piece of data like an sskr share which they need to retrieve a quorum of later to recover their their highly sensitive seeds but they don't want to trust any one party with the whole seed and so and they don't necessarily want to do this in you know as a public service you may want to make it so you don't have to register for a for an account so how do we handle this so in this case we have a client server architecture and the server starts by publishing a discovery message and the discovery message the main thing that you need to to put in the discovery message is its public key and this is not an encrypted message this is essentially something that's open and discoverable if it's a standalone device this could be published as a ur with an envelope if it's a standalone device it could display a qr code which is then read by a camera or if it's like the depot server for instance it uses it it provides a single get call which allows you to get the public key and then from then on it's all post calls with just envelopes and and no third party can tell whether it's whether it's a request or a response or whatever because it's all just ur envelopes going back and forth once the client has the service public key oh and i should mention that that any of these channels can be mixed and matched for this so the the discovery packet can be sent one way and then further further communications can be carried on through any of the other channels that you want to support so then the the client now can compose that full stack request that you saw with the authentication encryption layers and then and then the server now has the client's public key because that's included in the in the client's message and so it can send back a response that can only be read by the client so that's how you bootstrap a trust on first use kind of conversation using gstp so i want to walk through a little bit of code i don't want to belabor this because not every read thrust in the audience so i'm going to go kind of quickly but i just want to kind of show how it looks in code when you strip off these layers and you process the an incoming request from say the service point of view this is a function called handle request string and this assumes that you can see here that's receiving a ur string and it's also returning a ur string so this is the top level of of a server that that receives strings and output strings as its responses and most this is error handling code here the important thing here is the from ur string which actually converts the ur which is just text into the binary structure which is an envelope by stripping off that ur so now it has the request and now that handles it down to the handle request method here which receives the envelope as an encrypted request as you can see it's still in the encrypted state it hands that down to another function called handle unverified response and mostly this is here to handle errors from that notice that there's a function called new early failure here it's used here as well this is where an error occurs say for example in decoding the ur maybe there was the ur was corrupted you don't know anything about it you don't know who sent it you don't know what was in it you can't tell because you can never get past that so you have to send back a message that basically says this was an invalid request or there's some kind of other message other error in like you couldn't decrypt it for some reason like it was it was made for example it was sent the wrong you know it would encrypt to the wrong public key so you couldn't you decode it because you you have the private private key you have a private key but it wasn't the private key that was necessary so these are these are causes of early failures so then that's passed down to the handle unverified request which then and a lot happens here this is the sealed request try from the encrypted request and this actually strips off the outer two layers and actually verifies that the the signature is created by the person who actually enclosed their public key so you know that much you don't know that they're in your database you don't know that you're you know whether you're doing trust on first use or not that's for you to decide at this lower level where you're actually handling the verified request but at this point you've got you you can parse out all this information the id the function the sender public key the peer continuation the seal and then basically create a sealed response and this is again this is the next level below so this is this is where we call handle verified request with the sealed request and then this is where we generate the response there's two ways of generating response either in response to the successful execution of this or if there's a failure now we can pass back a fairly detailed error message where a wrong parameter was added or the person is an unknown database or whatever so this is where so we again have the the okay and error responses here the last thing before we send back our response is that we want to add the there's two last things one is we want to add the the authentication layer and that's where we're saying we're actually creating the sealed response which includes our public key and then finally we want to create the actual seal the envelope which we're passing our private key here so we can actually use it to create our encryption layer and we also are adding an expiry date so what this does is this actually puts into our own continuation the last date which our continuation can use so that's checked up here so if there's one of these that arrives and the continuation has expired you can say sorry it's too late to use that so that's one of the two checks the other one that it's not shown here is a expected request id that's because this is a response not a request but the client generally would put an expected response id into that which the server has to will return as part of its continuation and that will be checked by the client as oh well I was expecting this particular response id but your response id is different so I have to reject this okay so one layer deeper we actually handle a verified request where the unencrypted completely parsable request comes in and as you can see this is where it's dispatched and I just wanted to point out that there's in this case for example the start recovery function this is where a user says I lost my public key or I want to use some other method that a fallback method to recover my to my recover my share and this gives us case where the server is actually passing saying like okay here's my continuation here's what the start recovery needs to to actually change your you know rotate your your your public key to a different public key and then this is encrypted handed back and again this is just a black box to the client but the client has to hand it back to you at some point and that happens here and finish recovery function so this is where the where the server basically unwraps the state and basically says oh okay this is what I need and so I'm going to call I'm going to actually finish the recovery rotate the public key but if that state is missing it can't do it so you know again the interplay is anything you need to continue this is the start of the of the function this is the continuation of the function and the difference is this will this may come back through some other method like like you know through a phone number or through an email or something like that something that has nothing to do with how this this request was originally made but that's the second factor that requires a user to authenticate so they can actually rotate their key all right sorry if that was a little bit disjointed but that is basically the walkthrough of Gordian tilled transaction protocol and I hope you've done a pretty good job of explaining why we why we think this is a great way of doing things and kind of demonstrating its flexibility and and the fact that incorporates a lot of best practices into a very you know understandable structure so I'm open for questions would you go back to the benefit slides yeah so um the the key thing here that I want to point out is that you know this is the foundation for a wide variety of protocols obviously our first use case is the the Gordian depositories but can really be used for a wide variety of other things I'm hoping to use it with git repos for supply chain security it can be used in you know a wide variety of protocol situations and many of those protocols can many of the protocols can also take advantage of the general benefits of of envelope with in particular a lesion so you know we can have a situation where you know I send you something we establish a tofu but then you decide well I'm only going to give you some information back because you have not fully authenticated here is how you can fully authenticate and then you know you basically can do a couple more rounds in there where you're slowly revealing additional information to each other to improve the the trust that you have between the two parties and maybe you don't even necessarily go all the way to the end of the protocol you have sufficient information to be able to meet your risk model or whatever it is that's appropriate for you at that particular point and although there might be additional steps that someone can go through you it is sufficient for you to take action based on the protocol and do the function that you've been requested to do so I think there's a lot of opportunities to use state to use a lesion to use other things I mean even as an example you know I've been trying to puzzle out you know there could be you know when you actually put the the when you create say an envelope inside a git repo it actually might have alighted your private keys and you go well that seems kind of stupid that's you know why would I put my private keys into a public git repo but that would then allow you for instance to prove that the key did exist and in your past or allow you to do some different types of things and because it's just a hash and a proof of existence you can basically do integrity checks in a very stateless fashion I think there are a lot of opportunities here for advanced protocols that I don't really see you know anything else that supports it with the the level of of you know ability to do privacy to do progressive trust and other different types of techniques out there so this really I think is a foundation for a huge number of opportunities.

I would point out that that because the envelope itself is a hierarchical structure and because if you allied a branch of that tree you're leaving a hash in place that is a cryptographic commitment to what was to everything that was in that branch but you can reveal just the top level of that branch without revealing everything down inside it and but any step that when you reveal that you basically not just reveal that that yes you know what was in there that you were committed to but also you know you can reveal just parts of it and leave the rest delighted too so you haven't revealed everything yet but you're still committed to what's there.

Also we're taking advantage of a variety of of you know in the same way I was talking about SSH demonstrating not not necessarily cryptographic agility but cryptographic flexibility we have this same kind of flexibility in the future for how we do the permits.

I mean right now we have two ways to recover the symmetric key that lets you unwrap an envelope.

We have the way that was demonstrated here with the the sealed message with the ephemeral private key with ephemeral keys but there's also the SSKR method where you basically oh I have to assemble things from multiple places.

There could be additional ones in the future that for instance used frost where it would require a quorum of parties to basically agree in order to unwrap the next level of the envelope.

So there's a lot of interesting capabilities there.

Ken did you want to just make a quick statement or anything?

We thank you for your support for this research.

Oh he left okay again we want to thank Foundation Devices for helping us get to this point and all of our sponsors in the past that helped us build the the foundation underneath this of envelope and SSKR and seeds etc.

We are at four minutes past when we should be ending so any last questions before we continue and record this and save this for everybody.

I am not hearing anything Espen Erfan.

There's definitely some nice comments in the chat.

Hank thanked us and Ken thanked us as well before he dropped off.

Okay well thank you again.

So next month we are going to have as one of our focuses the you know discussion on Zoom is hiding my button.

We're going to be back to the first Wednesday date so it'll be Wednesday August 7th and we'll be using the Zoom URL that we've been using for previous first Wednesdays.

We're going to have a presentation on BIP85 and you know hopefully have a discussion about the implications of that and then I'm hoping to have a demo of how to use SSH with envelope on with Git so a more specific detailed proof of concept for that.

If you have something you would like to present about wallet interoperability whether or not it's a question or a proposal or you know a concern let us know.

We'd be glad to you know give you some time to discuss your specific needs so just let us know before the Wednesday before the 7th which I guess is the first or the 30th.

So thank you very much and see you in four weeks.

Thanks.

Thank you everybody.

Thank you.

Thank you.