Building Production-Grade End to End Encrypted Applications

hi everyone thanks for joining us I'm excited to announce our first speakers a song initial with their talk building production grade end-to-end encrypted applications

yeah hi everyone thank you so much for coming uh we're built like like she said uh our talk is called building production grade n10 encrypted applications I'm Esson this is initial so I'm a senior engineer at skiff initial is the director of security for skiff just to give a brief background about what skiff is we're not going to talk too much about skiff during the presentation but we want to give a bit of a motivation for why we're speaking about this skiff is a privacy first workspace we say for the next generation of the internet with end-to-end encryption built in by default so what this looks like is we have a suite of products for workspace collaboration

skiff mail which is an end-to-end encrypted email platform skip Pages for document collaboration real time calendar and then drive which is intend encrypted file storage and so you can imagine a lot of teams and businesses and individuals use skiff to sort of work on their most sensitive research or projects I lead the development of skiff mail and skiff calendar and initials director of security across the entire product Suite to start we'll talk a little bit about nt10 encrypted applications and how they differ from traditional applications so in a traditional application let's take the example of like a traditional email service provider your email that you send let's say to another friend is going to be in plain text or can be

decrypted by the server that is providing the service so in a sense we can say that the server this email service provider holds the keys to your email and if the server is compromised it's potentially possible for the contents of your email to be leaked in an end-to-end encrypted application data is encrypted everywhere and can only be decrypted by the user sending the email and the friend or the user receiving the email so in a sense the user holds the keys to their email and on our service all we see is a cipher text sort of encrypted meaningless string of letters and numbers that cannot be reversed into the actual email content so if the server is compromised

only that Cipher text is leaked so overall like their end-to-end encryption seems really cool right like it has all these privacy advantages so why isn't every app intent encrypted um and one answer for that is that it makes a lot of feature development and a lot of things you would do to build a really nice compelling easy to use product a lot harder and why is it harder it's it's because of this property we just talked about which is that our service doesn't have the keys to the user's information so a lot of different activities that would normally be pretty simple become much more complex because of this let's take account recovery right like let's say a

user forgets their password when um and is trying to log into their account and a normal traditional application you may just need to verify their identity verify their email address in some way and then you can just reset their password and give them access to the account but an end-to-end encrypted model that becomes a lot harder because we also have to help the user recover their keys but we don't have actually have access to that key as the service provider another sort of thing that becomes much more challenging is real-time collaboration so in a traditional application let's say multiple users are like typing on a document you maybe just send all those different changes that

they're making to a server the server runs some algorithm to reconcile them and then can like distribute that back out to the users but for end-to-end encrypted products we don't know the actual changes users are making to these documents so that becomes a lot more of a challenge how do you reconcile changes maybe on the client we'll talk about some strategies for that later and then observability of product bugs so there's a lot of really cool Frameworks that you can install in your front end that will help you track when users are seeing errors and users are maybe a user is can't click a button for some reason or maybe users in a certain country are not able to load the site

um but a lot of these will break n10 encryption because they'll send information about the user's page or the user's content that they're typing to the server so in end-to-end encrypted applications understanding what issues users are facing and solving those issues becomes a lot more challenging and then there's many other challenges as well so at skiff We Believe really strongly in usable privacy making privacy first products that are as simple to use as their traditional Alternatives so a lot of what we'll talk about in this talk is how we've developed clever solutions to a lot of these problems that make the end user experience seamless even if the application is end-to-end encrypted with that I'll turn it over to initial

thanks Hassan for that intro so what I'm going to talk about here is we're going to go you know in the theme of b-sides is uh you know putting the Cyber in space or maybe it's the other way I don't remember but we're going to go through a mission we're going to build an end-to-end encrypted mission log for our spaceship and so what is the one of the first things you're going to have to do in developing an application well the captain's got to be able to log in so let's just recap you know most applications right we have the captain will just type their password in the password would have been sent over the

network to the server the server hashes that password and then Compares those hash values to authenticate the captain ultimately this leaks the password to the server but you know you're using it to hash however an end-to-end encrypted scheme we might want to use that password to help generate the user's encryption keys so that would imply that sending the password to the server would break the end-to-end encrypted end-to-end encryption guarantees so we can actually use a class of algorithms called an asymmetric or augmented Pig you may have heard about this as the SRP secure remote password um you know it's now it's more modernized version It's called opaque and SRP just to provide a brief recap

allows us to authenticate the client to the server without needing to send the password it also has a very strong benefit in being fishing resistant because the server also authenticates to the client so here we have you know passwords are not sent over the network great right and we're mutually authenticated both server and client and I'm just going to take a tangent here is that when reviewing kind of oauth's top 10 you know both the 2023 release candidate 2021 also talking about these exact type of issues there's really no mention of SRP which has been around for 20 years or opaque as potential solutions to password leakage problems in the industry it's not even mentioned in the

nist standards and so one of the things that I recommend looking at for for most applications is actually adopting SRP or opaque as a way to prevent password leakage entirely in in traditional applications the way SRP works is just to provide a really quick example is it uses a diffie-hellman like key exchange and a you know challenge response mechanism but I won't go into that here so if you get anything from the slide from this presentations you can't leave passwords if you don't have them right and this has been a huge problem in the industry for many years so the one thing we're heavily pushing for is you know traditional applications to adopt these sorts of mechanisms

all right so now that rant is over let's walk through how we can generate Keys required for SRP to authenticate to the Mission Log server we take our password and run it through argon2id which some of you might be familiar with as a modern successor to you know pbk df2 apps script decrypt all that fun stuff we'll take it through argon2id generate some random data we'll take that random data and process it through another function called an hmac key derivation function and this basically just generates more random data and from that we can actually generate cryptographically secure Keys we'll generate two key pairs that we'll talk about in this presentation we'll generate some signing keys and we'll

generate encryption Keys the signing key pairs you actually use for the SRP protocol I mentioned earlier and then the encryption key pair is actually what we'll use to bootstrap the the end-to-end encrypted of the user data okay great but what happens when I forgetful Captain forgets their password and wants to reset it if the encryption keys are derived from the password does this mean the captain loses all of their mission log data so we'll talk about how we can go through a forgot password ultimately here if we're thinking about the captain their goal is to recover Mission Log data and change their password right changing the password and losing their data would be a mission

critical failure the first step here what we're going to do is to generate a new asymmetric key pair called the recovery key pair and that's the key pair here in the middle Black Box this recovery key pair is used to encrypt that user's asymmetric encryption keys I showed on the previous slide this encrypted recovery payload is now stored on the mission lock server but can't be used to access the encryption Keys nor the mission log data so now what do we do with this recovery key pair right we've encrypted this payload what do we do with it we can actually use Shamir secret sharing split this private key material up into three shards where two shards are needed to

reconstruct the private keys and what we can do is we can be clever about how we give these shards and how we how the user can access them so for example you know we can give one we can store one on the users on the captain's device we can store another one as a PDF document the captain hides underneath their bed and a third we can actually store maybe on the server because again only two are needed to reconstruct the private key and so by putting one on on the server we can actually have the user go through traditional forgot password forgot password mechanisms you can do you know email verification you could do phone number verification you can run

any sort of advanced heuristics that we're already used to in in traditional applications but the point is the captain needs two of the three to reconstruct their keys so let's go through the actual process of resetting the password the captain can present two of the three shards we can reassemble that recovery private key which is then used to decrypt that payload the recovery key payload which actually again gets them access to the decryption keys so Captain has their data we can actually run a very similar process to gain access to the signing keys for SRP to reset their password it's very much the exact same process it's just it's just a different key pair so all of this complexity can be hidden

within like the appropriate user flows and so to the to the to the caption they're just resetting their password but all of this happens behind the scenes great so now that we've talked about that about how the how the captain can authenticate to the Mission Log we'll talk about how the captain can actually use these keys to encrypt data awesome so yeah so our motivation for this section is now we know how a user authenticates like the captain authenticates to their mission log but we want to understand okay how does the actual n10 encryption process work like let's say you wanted to upload a mission log and have it be intent encrypted how how would you do that

so first just to explain some really simple Primitives that we'll use there are two sort of classes of cryptographic algorithms that are going to be relevant to this discussion asymmetric and symmetric encryption so I'll start by explaining symmetric encryption symmetric encryption is a pretty simple crypto class of cryptographic algorithms where you basically just have a key and you insert into this algorithm this key you can or a passphrase you can call it multiple things plus plain text and you get ciphertext and then if you use that same key that same passphrase plus ciphertext you get plain text right so like imagine I was sending a package initial and I didn't want it to be intercepted by anyone in

between I could put a lock box in this package right and and lock it with a combination lock send that package to initial and if initial if I've told initial the combination before like maybe I texted it to him or something else he can use that same combination to open the lock box and retrieve what was inside asymmetric encryption Works a little differently so an asymmetric encryption you actually generate two keys a public key and a private key and then these are this is called a key pair um and these this public key and private key are related through a special mathematical operation where the public key can be used to encrypt um a piece of information that is only

able to be decrypted by the private key so the reason these are called public and private is because the idea is basically you can share your public key with the world um anyone so in this case initial could share his public key with me post it on a public messaging board whatever and I can use that to let's say encrypt a letter for him in this case but then only he can decrypt that letter with a private key so the cool thing with asymmetric encryption is like I don't need to do this step that I mentioned before where like maybe I text the passphrase to him out of band instead because there's two keys I can just use

his public key to encrypt something and he can decrypt it with a private key so at skiff like National was mentioning and for most nt10 encrypted applications we we assign each user an asymmetric key pair so this is the public and private key so let's go through encrypting the mission log there's one more Nuance you might think okay so like asymmetric encryption is really cool there's these two keys you can post the public key like what's the disadvantage of asymmetric encryption right um and the disadvantage is because of the mathematical operations involved asymmetric encryption is actually very slow for encrypting large amounts of data um like like let's say a file like the mission log

um so symmetric encryption is fast but it has this problem where you have to share the key in advance so how do we combine these two things to encrypt our mission log properly so what we'll do is we generate a symmetric key called the data key this this key is very small like maybe 32 bytes 32 characters and we'll use the data key to encrypt the mission log with a symmetric Cipher this is very fast because a symmetric Cipher is fast at encrypting large amounts of data and then we use the user key pair to encrypt the data key itself and this is also very fast because the data key is very small it's only 32 bytes

and then we'll store two things we'll store the encrypted data key and we'll store the encrypted mission log now let's walk through how decryption works so to decrypt we'll use a user's key pair to decrypt this data key that's fast because the data key is small and then we'll use the data key to decrypt the mission log so you can see in this data in this diagram right here there's an encrypted data key with the user's key pair we do decryption we get the data key out and then we use the data key with the encrypted Mission Log and we'll get the point text mission log out so now let's say I wanted to share this

mission log with initial so I've uploaded it I've done all those operations now if I want to share the mission log initial all I have to do is encrypt that data key with initials key pair as well and upload that to the server now initial can follow the same procedure to decrypt the document that I just described one other really cool property of sharing a document in this way is notice that I did not need to re-encrypt the entire document a second time I only needed to re-encrypt the data key so it turns out this approach actually scales really really well when you're sharing with a large number of collaborators um even in even as a further Advantage

than just an individual so now let's say we have multiple Mission Log entries I've you know uploaded it I've shared the single Mission Log initial a bunch of time has passed we've accumulated multiple of these Mission logs and we want to share a folder of these Mission logs and I want to share a folder with these of these Mission logs without going as opposed to you know going through this process of like sharing each one with him as I generate them so one way to do this is to kind of treat folders like a user where a folder is sort of a special construct that actually has its own asymmetric key pair and when I add a log to a folder instead

of sharing it with a user what I'm actually doing it as I'm sharing the logs data key with the folder key pair so now let's say I want to decrypt a file that is stored in a folder a mission log that is stored in a folder we kind of follow this tree hierarchy so we have an example here on the right where there's a mission logs folder in that there's a year one logs folder and in that there's a 422 log for today so what I'll do is I'll use my key to decrypt the mission log folder and then I'll use the mission logs key to decrypt the year one logs folder and then I'll use the year one logs key pair

to decrypt the 422 log so you might notice this is kind of following like a tree structure right like a recursive structure for those of you that are familiar with like recursive algorithms um and it and indeed this sort of forms like this key system that we're describing kind of can be generalized to any tree where you have one root node that you are shared on and then want to decrypt any of the sub elements of that node so we just described a case of shared documents at skiff we also are investigating using a similar approach for several other product features so you can imagine that this would work well for a team inbox like a a user

inbox that or an inbox that an email that multiple users have access to or shared calendars um that are popular in many other calendar softwares so this is a calendar where multiple users can view and edit events um and and I'll also just add that um besides these use cases these are some use cases that we have at skip but you can imagine many other such use cases for what is essentially just a generic tree of end-to-end encrypted information can have applicability for a wide range of n10 encrypted applications but a lot of folks here and a lot of folks around the world are not developing on intent encrypted applications just yet so we wanted to

talk a little bit about how this can also be applicable to more traditional applications right so let's say you don't have an intent encrypted you don't have you don't have these keys on the client but you still want to apply some of these principles and let's take the example of you're storing a user's first name right typically when you're storing a user's first name maybe you collect it on sign up and then it goes through a bunch of different like data storage Services user authentication Services whatever is ultimately stored in the database and then later you want to read it all the way out right so you like retrieve it from the database retrieve it through a user storage service

whatever whatever eventually you display it on the user's page but a lot of those intermediary Services don't actually need to do anything with the user's first name they're just kind of passing it on and passing it through so one sort of principle you can borrow from what we just discussed is at the at the like sort of API layer or the last service that needs to actually do a computation with the users um first name you can encrypt this piece of information right and then when you're feeding it through all the dependent Services those services will just pass on this encrypted piece of data and then on on the other hand when you're pulling it out you can decrypt it

at the layer that you need to access it and what's really powerful about this is it means that now you've isolated the set of services that have access to the plain text copy of this user's name and as a security engineer you can spend a lot less time worried about hardening and like protecting the services that um have only have access to the encrypted copy because you know that they even if there was a compromise of those Services an attacker would only recover the cipher text and then on the other side as an engineer who's working on these Services you can spend a lot you can worry a lot less about a compromise of these

Services compromising the user's first name or any other piece of information that's encrypted in this way because your your application is only ever operating off the ciphertext uh with that I'll turn it over to initial to talk about how we can use this end-tent encrypted context to enable many product features in different n10 encrypted applications awesome thanks Hassan so we talked a lot about data data being read data being written sharing that data but ultimately there's other things about data right data schemas will change data transmission layers will change and so how do you adapt end-to-end encrypted applications for a lot of these future goals when you don't even have access to the underlying data

so basically everything about data except the data could change and so how do we handle that so let's talk about an example for like notifications let's say I want to send this on a calendar invite to go over the mission log I would encrypt a notification for Assan containing the event title and maybe the time my phone sends out encrypted notification data to the server the server delivers that encrypted notification to uh to assan's phone I'm sorry the other way around to to my phone and then assan's phone decrypts and displays the notification so essentially what we've described is real-time unidirectional communication right and if you're not really going to enter an encrypted app end-to-end

encrypted notifications are actually very simple can be supported by traditional applications and the way you would do that is on device enrollment of you know accepting these push notifications from Apple or Google you generate keys and you send those keys to your server and you simply encrypt those notifications before sending them out so this is really easy to set up don't need to have a full end-to-end encrypted applications but you can send end-to-end encrypted notifications in traditional applications actually very simply great what about bi-directional real-time communication so we can actually use a data structure an algorithm called crdt conflict-free replicated data type I won't go into that here in this talk but the point is is that crdds are

eventually consistent and I mean that in the computer science like Theory perspective in that when when the clock when collaborators are you know reading and writing from documents and generating these diffs these disks are encrypted distributed out to all the clients and the clients are guaranteed to eventually see the same data and so what we can support here is bi-directional end-to-end encrypted real-time communication and so application encrypted live collaboration and traditional apps really only needs an ephemeral layer sorry ephemeral Keys like per collaboration device and per collab live collaboration session so live collaboration for traditional applications can be pretty easily supported as well and this also has the advantage of protecting user data from leaking into caches you know

often used to support live collaborate live collaboration okay so we talked about bi-directional unidirectional real-time communication what about like data changes right oftentimes your back-end Engineers will say like well this data schema doesn't work anymore we need to make some updates but you don't have access to the content not only do you don't have access to the content you have no control over when a client will come back online to actually perform the data upgrade right as a back-end engineer if I'm on my database run a data migration great I can do that but I can't tell a customer to come online and say hey we need your device to come online so we can run this data migration so we can

like support you know support you in the future that's just not acceptable imagine trying to call you know if you're a consumer application trying to call a billion customers it's just it's not going to work so what we can do here is for like the mission log example we can maybe build like an initial version of this Mission Log but let's say Mission Control wants to update the schema to clarify like the time is UTC they want to add audio you know recording the planet information just like they're just trying to add things to it because you know ski must change over time I think unfortunately the captain and the crew have disappeared into a

wormhole and we have no idea when they're going to come back but Mission Control Engineers are just like well we have to keep moving on we have to keep building and so they want to make sure we have both forwards and backwards compatibility and actually we take a we take a lesson out from you know the SRE playbooks and infrastructure engineering uh protobots which are often often related to you know grpc or internal service communication and we can actually use protobufs to perform you know to allow for this backwards and forwards sorry excuse me forwards and backwards compatibility and so the way this happens is that protobufs actually will Auto generate code for serialization and

deserialization and you can say like why not just use Json it's been around for a while supported everywhere so you can imagine like if we're making so many different schema changes over time you're going to have a bunch of these if statements or case switches about you know version one this is the schema version two this is the schema and that requires humans getting it right and we know how that can happen especially over time if we're talking about years and years of data and data schema changes but the nice thing about protobuf is that it's self-documenting you get exactly what you get exactly what you see you know what fields are deprecated and the serialization and

deserialization is auto-generated by the protocol itself so you never have to worry about your spec being out of date it also has a nice Advantage is that it's a binary serialization format so it's a lot more efficient than Json but that's just a nice slight advantage great so another thing about building you know production grade applications is your users or your engineers want to be able to debug and you know observe user behavior and be able to fix issues at the end of the day right traditional clients find monitoring like such as recession replay or user monitoring can leak user data or data about the user so what can we do here right we can see

an example of this is like some some you know product that offers session monitoring right the user is clicking around they're maybe adding products to a cart they get angry but ultimately you're recording the user session and for doing that in an end-to-end encrypted application though it may not break the actual underlying cryptographic guarantees it really goes against the spirit of it and so we're actually very very interested in future work coming out of the ietf known as the distributed aggregation protocol and at a high level what this protocol allows you to do is send anonymized metrics that anonymized metrics to your server and the way they're anonymized is that multiple users will have to report the

same information and once it hits a certain threshold you'll get that data so let's say you're you know you're seeing thousands of users run into an error you'll still see that information but you won't know anything about the end user which is great but right now as we're still exploring this like we really rely on heavily pre-production testing automated testing and user error reports you know probably the same as as many people here as well so even this occurs actually in the security space as well you say like oh haha like bad front-end Engineers like you're recording user data actually we have a problem with this in the security Community as well so if you look at content security

policy trusted types it's a fairly new reporting it's a fairly new policy Beyond normal CSP trusted types was heavily pushed by Google and a few others to help protect against Dom based xss and what this does is it it looks for potentially unsanitized data Landing into into an into a bad sink but great I get this report I'll find my dom based xss I can go solve these issues the problem is is that this starts leaking user data and how does it do that well because it's Dom based access has the user input is part of is part of the actual like script sample that is sent back to your backend server so you can actually see an example of

this as we were testing this in our staging environment if you look at the script sample towards the bottom right above the black box you'll see Dom parser error parts from string and then you can see user data saying heya so there's not even a way to turn this off like so really the solution we have is we can either look for Dom based xss and have this reporting enabled or we literally have to fly blind like we've been doing for the last few years and so this isn't a great example either so it's not just to say that like we have issues in front end tools we actually have a problem with these privacy issues

in in the security Community as well in the apps like community so we talked a lot here about a lot of things Keys a lot you know a ton of a ton of work well we hope to have accomplished here is that clarifying A lot of misconceptions around the limitations of end-to-end encrypted applications right authentication password recovery efficient data sharing you know real-time Communications over both unidirectional and bi-directional channels we also talked about where it does actually get challenging from our experience right data migrations observability but we hope that you know if you're building more traditional applications what hopefully you can take away from this talk and take back to your own organizations you know is using SRP or

opaque to prevent you know password leakage and actually protect against phishing you don't need to you know buy into the hype of you know Hardware Keys they're great they do their job but we've had this protocol for you know 20 years to deal with this issue application layer encryption at trust boundaries to prevent data leakage though you know it can happen at you know people have talked about it a lot we do think it's fairly fairly powerful and you know privacy preserving observability like we talked about the distribution aggregation protocol coming out of the ietf to improve user privacy doesn't require end-to-end encryption but still allows you to collect this data in a you know

more user friendly and private way um with that being said we just wanted to give us a couple special shout outs Zach uh who you know was that skiff he made a large amount of the crypto engineering contributions that we talked about here co-founders who built a lot Andrew and Jason who built a lot of the original implementations um our entire team we're a small team of you know 15 people um and we're presenting here today because of a lot of their work and contributions to to what we've been able to do and you know we are standing on the Giants we are standing on the shoulders of giants both like cryptographers a lot of these protocols

that have been built over the last 20 20 years and obviously a shout out to all the b-sides volunteers and organizers because we wouldn't be here to be able to talk about this without them awesome so we talked a lot you might have questions happy to take those now we have about eight minutes six seven minutes for questions so uh feel free to raise your hand and I'll try to see you in the light

yeah for sure for sure

yeah really good question so yeah I'll repeat the question the question is um sort of a clarification on how the folder sharing is working um sort of asking like I use uh about how you use your users key to get access to the folder and then also let's say that the access was revoked uh how what sort of would you rotate yeah so the way this will work uh there's kind of a Nuance here that that we um simplified for the purpose of the presentation but I can explain it in more detail so a folder kind of has this hybrid structure at least at skiff where it kind of has this like asymmetric key pair where it almost acts like a user

which was the analogy I was making but it also can sort of act like a document so users can be shared on a folder a folder actually has its own data key and the data key it exists alongside this asymmetric key pair that a user sorry a folder has where it can kind of act like a user and have documents underneath it so that that maybe answers like the first part of your question like that's how you kind of are shared as a user on a folder um and then the second part of the question was key rotation right so let's say a user is unshared from a folder what ends up happening um so one really simple way to do this

is to sort of re-encrypt the entire tree uh that that's not very efficient um so initial do you know what our approach is yeah so the the what we're comparing here against is traditional applications right versus in this context key rotation what we can actually do is just pretty much use server side controls here because what we can say is that the user is unshared on that document we can simply say they no longer access the ciphertext so though cryptographically there's an issue ultimately if the user doesn't have access to that Cipher text they don't have access to the plain text and you could argue like well what if they have access to the old type of text

well that's no different than a user in a traditional application copying and pasting the dot somewhere else so we really have to care about can we protect the document against future changes and that's the real question or the confidentiality of that document for for like with future changes and so we can do is apply server side control and then look at like okay if we really need to re-encrypt this this specific document like allowing the user to do that but in most cases the server-side access control is is sufficient

yeah so my question is I use a password and then I generate a I think an encryption right if I use it okay no there's um there's a there's a couple of salts in secret like server side Secrets involved uh sorry not server side but yeah there's halting involved and whatnot so you won't client-side so the client has to remember uh so the salts are considered public they're not they don't need to be um you can't so it's actually what one password does is they do they don't store the salt to make this a lot hard to make this brute forcing a lot harder but technically to keep the protocol secure you can store the password in

your own database and the client can query it and that's like perfectly acceptable the salt the salt okay yeah um the other thing that happens here is that what I didn't go into is that the SRP protocol also takes you can take into account the um the bootstrapping of that on the SRP protocol that actually prevents like the fishing so even if a user typed in it's like their password somewhere else the assuming they weren't just capturing the password which would break you know if that can't do anything about but if they were also running SRP on this phishing website you couldn't use that same uh response to then log into like you know Skip for example so it does

protect against that when it doesn't protect against is like yeah the pat like the password leaks somewhere else and somebody typed it in again like we're hosed either way like and so our comparison is always are we do we have the equivalent security considerations in a traditional application or do we exceed them right we should never be worse so in some cases we'll actually be equivalent like the security model is no different but what we're hoping is I don't know most cases we're actually better okay I mean because you said don't use physical fight or two keys and I think they have better protection than all of this right yeah so we offer MFA um MFA is possible right because you can

still you could still basically don't don't respond on the SRP protocol until like the MFA challenge was completed so you can still do MFA as much as you want like skiff we supported web offend you can support all these keys so you can do all of that like none of that is uh prevented in these systems oh okay

all right yeah you can just say it you just say it yeah that's fine okay

yeah that's a great question um we haven't built that it's something we're exploring oh sorry the question was can this scheme be used to support saml SSO kind of these other Federated authenticated approaches the answer is yes we're looking into it but we're really inspired by what one password recently launched with their kind of uh you know Federated identity uh you know integrating with basically OCTA and that is you know they they run a very very similar authentication process to this um though maybe not exactly the same and so we're pretty inspired that you know if they can support it on a you know one password with real Enterprise customers using OCTA like we could we there will

be differences but we think it's very possible they've proven it out so we're not um we're very optimistic that we could support that in the future um

yeah so you want to take the question yeah yeah so the question was um we're talking about the folder sharing again and and the question was if we treat a use a folder like a user where it has its own key pair are we sharing the private key with the users that have access to that folder um and the answer is yes so the way it works is any user that is shared on that folder has access to the private key of the folder and then they use that private key of the folder to decrypt any child documents

yeah so the the follow-up was what about in a situation where a user has access to the parent folder but does not have access to we don't want them to have access to the child folder So currently cryptographically that's not really possible to support at least in our framework um you may be able to support that by server side controls like initial was mentioning where you could just not present the user the encrypted piece of information but um if they were pretend it's not protected in like sort of an end-to-end encrypted context right like if they did gain access to that Cipher text for that that subfolder they're not supposed to have access to or that sub document that

you're not supposed to have access to they would technically be able to decrypt it foreign

hey thanks for the great talk have you put much thought into solving the problem of the use meeting to trust the client-side software that you're serving them showing that you haven't been compiled or compromised into something that undermine your controls yeah really great question initial you want to take that yeah yeah this is a tough one right yeah so the question is um basically have we thought about the Integrity of our client software right the client software used to generate these keys and encrypt a decrypt and and all that and it's tough because we don't really have a way to assure the Integrity of the client besides hashing like all the scripts like through CSP and like assuring those

like hashes are valid or so it's a little bit tough we we're thinking about it more but we don't have a great solution to that like you could say like oh we can package it up in the desktop apps and users can run it that way so we're looking at stuff like that but we're open to ideas I know cloudflare has been working on this with I think they had a partnership with WhatsApp if I remember correctly to try to do better um our client-side app like to assure I think what they did was like when WhatsApp makes an update then cloudflare will look at like the hash of that update and make sure that it's like

still valid and so you kind of run into like two-party computation scheme maybe completely butchering that so somebody can correct me but that's something I think that's like the closest we can get like we're just sort of reliant on you know what what specs are coming out of web browsers at the end of the day and the closest thing I've seen is like CSP and like hashing all the scripts or and whatnot and like you know you can do that but obviously we always have like JavaScript dependency so it's like okay you know it's Turtles all the way down again right you're talking about supply chain uh issues here that we're not immune to just like any other app like

it's the same issues that you would have in both cases thank you yeah we have a question up top oh okay great yeah yeah that's the light is there

you can you can talk I probably can't I can't see you though that's okay um there was a question on key rotation on the user piece

is

it worth

it yeah so yeah

thank you have access

yeah okay um I'll take those backwards so the second question was around is there a way to if I have a document of a very large document to selectively share just parts of that document from a cryptographic standpoint I I can't speak to product strategy but I can say like it's very possible Right all we're doing is just treating these this one large document that the user looks at one document but treated as multiple cryptographic documents right and so you can just compose that and say like well pages one through ten is actually like one document and you know 11 and 13 through 13 is a separately shared document and then the rest is that so it's like that you could just

split up across multiple documents to support that that would be fairly straightforward you would have to do a sort of work in the ux to make sure like the it's pretty seamless for the user but that's where the complications would be um and then the first question was around the rotation of the data encryption keys so generally we try to avoid in our application to re-encrypt that data like we try to avoid it as much as possible because the real issue becomes that if a user has like a huge document and they're re-encrypting we have to have the client online and users don't like to wait right they're just going to close out the Chrome tab

or the browser Tab and leave or you know they turn off their computer like users do all sorts of you know crazy things and so we try to avoid those re-encryption operations as much as possible there are cases where we will have to go re-encrypt especially if like you know the user is requesting it and whatnot but for small documents it's great it's like super easy you do it it's fast right but even with symmetric keys right if I have like a zip file of like two gigs right I have to read I have to download that that file which is usually not too pumped if you have a fast internet connection re-encrypt even with

Modern Hardware but the problem is you have to re-upload that payload and so we try to avoid the the re-encrypt operations as much as possible right and and sort of say like well if the user doesn't have access you know to the cipher attacks we can actually you know deploy server-side controls to protect against it and we can get around it we can try to get around it that way in a lot of cases just to add one thing um we left this out of the presentation but uh these are a lot of these questions about the cryptography are really really awesome to hear um just wanted to plug that we actually have a white paper on our website that

is sort of more of a technical paper like almost like a research paper type thing um that you can go and read and it spells out all of these operations and all of the sort of things that we do at skiff to encrypt data in much more detail it's just really simple link skiff.com white paper so if you want to read that after the talk it goes into a lot more detail and like sort of math and cryptography detail on a lot of these things okay

right okay so the question is how do you deal with data coming into the system or out of the system that needs to be decrypted in order to have third-party interoperability especially in the cases of email for example if you're sending a message from skiffmail to Gmail or the other way around so um actually what we do what what this slide was heavily inspired by what we do actually do at skiff um and in these cases what we do is a user is attempting to send to an external address that is not in skip systems you know whether it's a skiff.com address or a custom domain we actually have the user encrypt it with this special like encryption users keys

or decryption users keys and so this way we we can we let the email go through as long as possible in our system stays encrypted and then only for the purposes of processing that and sending it out like via smgp will be decrypt and so we and then and then we delete the plain text copies we never store right and so this is one thing we also we're hinting at here but didn't explicitly say is that you don't like we we do as much as possible on these trust boundaries to say we're only going to process this data and we're not actually going to store it and if we can you know differentiate the storage and the

processing of the the plain text Data you can actually still reduce a lot of risk um because if you're storing all the data that you know you can compromise whatever that data storage is and leak everything but if you're processing it and that processing step is compromised the only thing you can access is future data that is being processed in that pipeline not all previous data so you can actually do a lot of you get a lot of risk mitigation this way too

yes we're looking at like supporting pgp um we were using more modern Cipher schemes um but we think like you know we've had a lot of users that are pgp users it's something we're exploring haven't decided on I'm just told I have to stop so there's a ton of follow-up questions I think there's a come meet us in the hallway like I look like a traffic cone so come find me it should be hard to find so all right thanks everyone and yeah thanks for coming to the talk