Minutes:
YouTube recording: https://youtu.be/67oSla3NVmA
This is a transcript of the discussion after the call. Feel free to continue the discussion in this topic.
- Post quantum encryption
Q: Do you consider Integration of post quantum encryption hyper keys?
A: In the first stage, we are not considering of quantum mechanisms. But definitely on the agenda in the future.
- Group size limits, gas costs, scaling
Q: Any limits on the size of the groups?
A: Some of the operations will be, in terms of complexity, around O-n something that is a little worrying, for example the gas cost of some operations. We should perform this theoretical analysis.
Q: How does the gas costs scale with the size of the group?
A: Most of the operations are in terms of O1, so it’s the best in terms of complexity etc. Some of them are quite demanding especially when it comes to studying session data offchain. And so when we plan to keep as less as possible in the smart contracts or maybe just a few hashes to be able to restore the sessions and so on.
Q: So, the amount of information, that’ll be stored onchain is sufficient enough to reconstitute a chat, but not too much to blow up. So what are you storing off chain?
A: We are the storing session data concerning the ability to allow you to restore the session and keep going with the previous chats once you log out and log back in.
Q: You can still understand what members are in what chat group and that’s assuming you mean what addresses are part of what chat group if you’re looking at the smart contract. What are the thoughts on obfuscating that? More precisely, one of the future goals is to increase the privacy around that? How do you plan to do it? ( assuming, if you can make chat keys - a deterministic key from some master key for any given group then making that connection really hard to do**)
A: Not sure yet but it’s one of the ideas that came around recently. Both how to keep it secret or even if we want to have it secret, it still needs to be explored.
Q: You said there will be one smart contract per group, but it was not clear. There’s a set of small contracts. It sounded like you have a separate one for the login process. Can you provide additional details? (Because this should also definitely take the gas costs into consideration and the practical implications of this).
A: Still thinking about it and how to do it. But what we have in mind is having a separate smart contract for the login and the registration. And then, another one for the group management.
Q: And regarding resuming sessions, I assume that it’s not about retrieving messages or anything, it is just about managing the excess keys that you need. You will not use this smart contract to coordinate that. Let’s say someone wants to resume their chatting and then they switch off the device, switch it back on and rejoins. How would that process look like? How would you go back into the session and they get the messages and so on? Just for the sake of additional details.
A: Resuming a session would not use a smart contract but rather the message layer, something like Waku store. De-mls acts like a message security layer on top of this.
- Restoring a chat from seed phrase
Q: In the instance, I have my seed phrase that generates key material that allows me to kind of regenerate the address to ownership of that. If I lose my phone would I be able to reconstitute my old chats based on material somewhere? How would I reconstitute my chat if all I have left is just a seed phrase that generates my addresses?
A: For example, we use the modified version of sign limited Ethereum. So maybe the key materials can be stored on the wallet that when you log in once again with your wallet that maybe you can create your session here again from the presentation. It will be derived from that but that also plays into the question asked before regarding the anonymization. So because it’s linked to your Ethereum identity, there’s this link but there’s still ways to obfuscate it but it’s not in focus for now. It’s definitely on the agenda, the obfuscation part. There’s still stealth addresses, we cannot directly use it but learn from it and apply ideas.
We can also apply some cryptographic tools to accumulate something. The only thing that you need to put in regarding your identity is the ACL list. So you can jump to the group without revealing your identity and there are a lot of tools that support that. However the focus right now is on the testnet, meaning this is currently out of scope.
- Testnet
Q: Do you have an idea on a timeline for any level of prototype that could be used for testnet?
A: The main goal for this quarter is to have to have a simple test on top of Waku using something like Waku chat2. You can spin up a few chat2 nodes and then Establish the key material and chat using the keys that have been established via de-mls. And that’s all the main focus for this year. Everything else is will be focused on in the future. We already have a small PoC, that needs to be extended with the login mechanism.
- Group admin communication
Q: How would the communication with the group admin work, if somebody wants to join the group, how would this work? And how do they do that securely?
A: Whenever you want to join a group, you have to contact the admin of the group. They will check If your address was registered meaning if it’s in the ACL and if so, they will accept you to the group.
Q: You say registered in the ACL and how would one get into the ACL in the first place? Why do you still need that admin if you interact with the smart contract directly? And how is that the communication with this admin secure?
A: We use the Access list and it’s on the Smart Contract is because we use openMLS for all cryptography site and openMLS includes all group our authentication by itself. From the technical side anyone in the group can invite new people because we need to send a sort of a welcome message for them and then we provide by using a part of: our key which also connect to group key.
And also in regards to scalability, in the future so that the admin is not a single point of (potential) failure that can compromise scalability of the whole approach and security. The goal would be to have a set of members within the group that can add other members so that there should be two types of members in the groups to one that can invite others.
- Several user devices
Q: A user could have several devices, is that correct?
A: This is something we’d like to include, but it’s more a wish than a reality at the moment.
Q: If you have a specific user with, let’s say four devices, and one device gets compromised. How is this situation handled? From the point of view of the group and the other users there is one user but that is this user and the malicious actor.
A: If you go to the VAC RC page there is one for the Waku noise protocols and one is about multi device usage, the approach will be very similar to this. So as you can synchronize, key materials across your devices. To other users you look like one but you actually are “shared” these between your devices. But then if one of your devices is compromised it just means you are compromised as well. This is something we consider as a future work item, to include that into this specification as well.