Michael Egorov: Ways to scale sharing of encrypted data | Swarm Orange Summit Madrid 2019

all right hello everyone my name is Mike Michael I'm the CTO of new cypher and I wanted to talk about how to share data while it's encrypted in a scalable manner so this talk is more like well there is already some system which allows to share encrypted data data being developed in swarm so I wanted to kind of to start a conversation with a swarm team about like what what ways are kind of more optimal or like more scalable for different situations but when you share data while it's encrypted and mainly I will compare two ways to share encrypted data one is the approach we are using a new cipher which is which is using proxy encryption and another is a correct me if I'm wrong I think I think Daniel Danny probably can can do that if that another approach is using kind of kind of trees of keys which are allowed to to share data between multiple users pretty efficiently so I will first like overview different methods the scalability properties and when when I think one method error has advantage over the other and vice versa okay well first of all just for those who don't know what proxy encryption is it's a cryptographic primitive which which we use in new cipher so this is some cryptographic primitive which allows to form data which was encrypted for one person to be encrypted for the other person so for example or over here data was encrypted for Ellis although Ellis yeah yes here Alice can read this data this data could be encrypted by some someone else and Ellis can permission to Bob and Charlie by great marine so-called dream Krypton keys from Alice to Bob and from Alice to Charlie and using those some untrusted proxy can transform ciphertext which was created for Ellis into being encrypted for Bob or for Charlie so proxy over call proxy Ursula another character can convert re-encrypted texts for like whoever LS allows to convert so proxy can be used for like for access control well if you have just one proxy it doesn't sound very much decentralized so and what we what we are doing is we're actually splitting the operation of proxy encryption into multiple proxies so you require like em out of an proxies to actually be convert in cipher texts to to get them converted for Bob and if some proxies are malicious if there are only few of them that's still fine right okay no they actually malicious proxies cannot ever decrypt the data even if they come together and do their malicious things like collusion they would probably only are like be able to transform this data for Bob to whom Alice granted access in the first place but they wouldn't be able to reconstruct this ciphertext you probably would ask why would like why wouldn't Alice just give some some key to Bob to be able to permit a terminal to decrypt but like the thing is that here proxies can apply like any conditions like for example I want to allow Bob to read this data only when this happened or like only only like until that time or maybe I can revoke the revoke that access and then Bob cannot cannot read the data so malicious proxies would be able to like say okay I'm not going to follow these requests anymore I you know keep the ring corruption keys and continued rain Crips if a Bob and a for all the proxies do that then you know it's too bad but they couldn't be able to read there in the day to decrypt the data themselves so that's kind of how it works with proxy encryption and with new cipher if which is the network of these proxies incentivized to work properly right so well let's just look at different ways to share encrypted data from scalability point of view so for that let's just say m is number of messages you've sent and received these number of participants in multi-user setting and let's say G's number of grand chief of operations right and let's say we're probably using some public key cryptography which is relatively heavy weighted so yeah and we're interested in number of these highly weighted operations which we do well what's the naive way to share in what saying just for simplicity imagine a multi-user chat everybody sends message to some group and everybody else in the group has to read messages in the chat the most simple like dumb way to create this would be to encrypt for everyone so I have B participants and then or you know you pretty much encrypt like every user who send messages would encrypt messages for everyone in this group chat and do all of P or like number so it's like to encrypt sorry to send message you need to do number of operations proportional to number of participants and also number of communications proportional to number of participants so it's kind of well not convenient or if you store those messages not not storage efficient and also like the participants would need to be able to store like to have at hand all public keys for all the participants well is it possible to do better well obviously you can use proxy interruption but I'm not talking about that what say what I would do sessions like when a new user joins and new user leaves you have a new session starting and let's say you have session keys well yeah the dumb way to do it with session keys would be that you have an admin in the group who like sets a new session key when the grant or revoke happens and sends this session key to every participant in the group well then they said min with every grant every well this admin should do all of the operations like number of operations proportional to number of participants and well I mean this admin of the group should be online all the time and like Oh at least all the time the grants and the rocks happen and then you know if this admin should exist which is probably not super cool not always super cool and well other than that after after this operation happened everybody can use session key to use to read messages in the current session so is it possible to do it better well and I think I believe that's something similar to what swarm users currently is using like kind of kind of trees of keys which allow you to to do like to do it so that after every grant or revoke operation every every participant or in the group or has to do all of log B operations like where a log B world where P is like number of participants so you have to do a kind of logarithmic or work and also this well this is probably coming from this paper like on instance encryption called a synchronous ratchet entry's so in this case like North Central Admin is needed and this achieves perfect forward secrecy which actually comes with pluses and minuses the biggest plus the perfect certs for secrecy is its privacy properties well with a and it's also it's big - because by definition perfect forward secrecy is that the new user like cannot compromise the sessions which he wasn't involved in so he cannot treat the past he cannot treat the future if like let's say somebody revoked this user so and not having to not being able to read the past means no access to to the history unless somebody explicitly sends this user all the past session keys so how would this righteous in trees work well just to just to kind of give a brief overview of my understanding and and again I'm I think that's maybe what one was using right now with access control but correct me if I'm wrong I don't know who is the best person to answer that but anyway so how those trees work is that imagine that every user has his key pair like a private and public key or let's say lambda 1 2 3 4 5 is private keys and G to the power lambda 1 2 3 4 5 are public keys so and well what happens here is that there is a binary tree and each node in the tree has public private key associated with it with it so the raw leaves in the tree our user keys so we have lambda and G to put to the power lambda G to the power lambda the public key is public and lambda the private key is obviously not known to anyone so let's say let's say user 5 by knowing public key of user 6 lambda G to the power lambda lambda 6 can derive to the power lambda 5 times lambda 6 which is like the de jamón secret between users five and five and six so what if this DV Helen her secret is used or like hash of it maybe is used as a private key for this for this node and then the public key for this node is G to the power that and this is public then to derive their kind of kind of private key on the top you would need to know what user five would need to know public user six public user seven and public key of these node in the tree so which means that the user five would need to to do like logarithmic number of operations to derive a shared secret which can be derived by anyone who in who is in this tree so anyone in this tree users from one to six can derive is gr key which is the session key so let's say in a new session and user joins and he publishes the public key and then this user can derive the groups group session key for like this users is in place and other users if they believe this user should really be in this tree also can derive the same the same key and then this key can be used for the session so and this like granting a granting permission in this session requires well logarithmic number of operation from every user and revoke an access means that well they have to recompute the tree so well each user's does again live like the logarithmic number of operations yeah so this is kind of a great very elegant approach and well it's it can be used for like you know group chats and some and stuff so what's wrong with this approach or is there anything wrong well well first of all its it has this perfect forward secrecy property property so if you want to share the past data you kind of need to the user who wants to know the past data who wants to to be able to have access to all the past messages so which is you were either encrypting those messages explicitly for that user so kind of going bypassing this whole thing or encrypting there all the session keys from the past and well I don't know how safe is that effort that's the first thing and second thing is that what if you want to kind of go with a different granularity than than those sessions like what if you and I want to share the data like which is like from half of their one of their last sessions to do like half of some other session right in this case you you would have to like send really like encrypted messages to this user so well anyway and also like what happens if we if we want somebody some stranger to write to this stream of data so let's say right now we had everyone having access to to this to this collection of data right so all like em all them you'll be users can read and write so what happens if we want to have some different user who can only write but cannot read right if we want to do that well here this session key is kind of known by everyone so it's kind of like a symmetric key we don't want the writing character to be to know this well in principle if we kind of modify this original definition and use this private key not as private not as like symmetric key but as private key for public key encryption maybe it would be possible to calculate public key for the strangers so strangers could write but then the strangers would need to update this key every time you change you change the session so maybe maybe that's alright but it kind of excludes that headless stranger and headless strangers who only like know the initial public key for the thing and that's it and so that this stranger like in the best case scenario would need to to be like to have the read access and update the update to the public the public key every time it's updated cells would probably exclude some IOT use cases anyway so and if you use proxy or encryption for this kind of thing well first of all we call the stranger in recall so this Enrico encrypts with so the data is always encrypted for Alice's public key and you don't change the key under which data is encrypted and in record the writing character needs just you only know the public key and then and then you just tell the group of proxies which like who you like granted access to in a cryptographically secure way so you give their encryption keys to the group of proxy and then of course Enrico cannot read the data he just encrypts for LS and then you know what say Bob and Charlie read the data after the proxy transformed data to them when when it could so a grant and revoke here would be just of one because Alice would just grant grant permission to like let's say Bob and Charlie and whatever and Bob doesn't do anything with that well Ella also technically would just need to accept the Aryan Krypton keys but also she needs to validate that they are valid during query encryption keys so it's let's say o of 1 & 2 decrypt messages well Bob would need to do like Oh one operation well technically M operations where m is number of proxies you distributed in every encryption key with and encryption is just you know encryption for one public key so in recoil who wouldn't even have to be connected to internet enrico just can be can have the hard-coded public key and then produce everything encrypted Felice public key and then Alice can just figure out who to share the data with on the downside this Alice is kind of the admin of the group so the alice is a kind of real character it probably can be made into a group of characters though okay so and now like is it possible to make this sharing granular so imagine that you have I don't know multiple types of data or maybe data distributed over time so how to how to share different pieces of data separately well one way would be it would be this so what we call it kind of encryption for labels but basically you can have LS deriving different private keys for different labels and there are different public key is corresponding to them and then if you want to have data to have like multiple labels you just with symmetric key encryption is with symmetric key and you encrypt a symmetric key with derived key for different labels and attached all that together right and then if you have if you were granted access to some label proxies have re-encrypt and key from these labels private private key to their public key and they will be able to decrypt the message so this in principle can be used to share let's say ranges of time ranges of data so for example imagine you have different labels for every year every I don't know months everyday or like whatever granularity you want to have and then you kind of kind of all the data as is encrypted with symmetric key and each symmetric key is encrypted for like you know today's for today's public key and also for this what's a week's pay this month's public key and then you have this several encrypted symmetric keys and ciphertext combined together so and then you can let's say when you give access you say I want to give access from let's say this data this day which would mean I want to give access to like all their like full years in between or like full months in between and you know some full days in between so you create this number of your encryption keys which is in the best case or like the number proportional to log of tunnel time range and well if you don't use days but kind of do binary so you would have number of encryption keys proportional to log of this time range and and grant access this way well there are only problem of the problem with this approach is that this would require Alice to create this public private key pairs for all the like let's say every day right in advance but there are if this is really needed to share like time ranges of data it's there exists attribute based proxy encryption where like enrico can say I encrypt data for this label and then Alice can grant access for like a bunch of labels right so well anyway this is kind of kind of kind of coming to the end of the talk so and yeah I review the sharing data using the trees of keys versus sharing data using proxy encryption and I believe that if you want perfect forward secrecy then probably multi-user like data sharing using trees of keys is probably about her but if you do need to share secrecy its sorry to share history then proxy encryption is clearly better when you have write-only participants I think it's still better with proxy encryption and yeah if you want to impose any limits on the any kind of limits to how many data you can do how much data you can decrypt for example or like any limits of unlike where when you want to if you want to share data only when some transaction happened or whatever or then it's probably better to to do proxy encryption as well and also if you need revocation if you believe in revocation her proxy encryption is better of course you might say that a revocation probably doesn't work because if you had access to this data you probably could have just downloaded all this data and now you have access to all of it well I mean that's kind of true but maybe you didn't or maybe you had some limits on how many every encryptions you can do and then and then actually revocation makes sense so yeah that's yeah and I wanted to point out that our new cyber team is is actually here the summit so after the talks if if you will have more questions we can talk to them so the question that I have is that is it is it true that it provides it also provides a measure against actually linking of content that I was able to decrypt to some other con to to some ciphertext that other people know that it's needed so basically if I'm granted access through proxy encryption to let's say somebody's medical records right then even if I can read it I don't want to be so one advantage over swarm encrypt current swarm encryption would be that I cannot disclose any information that would in addition to providing the data also proof that is that particular data also so do you want to not be able to let's say for example you want to not be able to have access to like who else has access to this data hmm well I mean it can protect I guess like for example if you depends on what your fashion of course right so if you let's say you have the ciphertext which is produced by public key encryption so maybe it has a symmetric key encryption part doesn't matter but if you heard the whole thing the kind of EC part and and the ciphertext parts or maybe just the C part right in this case if you do that then I guess the the reader of the data he will get he will get a completely a completely different ciphertext but actually mmm in our case you know setting the reader of the the reader of the data against the ciphertext which is under cryptical by him right and then and then he asks the proxy to transform so if you yes a good question is what what your which data you would link right because if you if you has access to if you link there originally like encrypted data right then then then I guess there if the reader has access to that anyway he will be able to link right well the good thing is that the the data which the reader actually can decrypt is the ciphertext is different from the original ciphertext so well you probably would be able to have it to have it linked to have it linked in the green cryptid form for some different readers but yeah if you said that one of our colleagues pointed this out yeah I guess they're all here so can talk more yeah can you undo the proxy encryption are you mean to with the proxy encryption different way like from Bob to Ellis yeah exactly right yeah so there are algorithms approxi encryption algorithms which are unidirectional and be directional so ours is unidirectional so if you encrypt from Alice to Bob us from Alice to Bob not the other way around but the rather definitely our algorithms which have both ways so you you have either we use a unidirectional and is there any difference between them apart from this well I mean there are yeah well there are different properties of different proxy encryption algorithms for example ours is CCC secure because we're based in it only is there are some CPA secure proxy encryption algorithms and yeah well they are also like I think kind of kind of unknown and most proxy encryption algorithms where you in principle could not do anonymize could you let me think so there are different like anonymity properties for the proxy encryption algorithms and yeah so there's a bunch of stuff okay so thank you very much