Consider CPACE for Key Exchange

[ignoramous]

https://www.ietf.org/archive/id/draft-irtf-cfrg-cpace-06.html

[MihanEntalpo]

I've read the document briefly, and it looks like it's a draft for now, that doesn't have some real implementation of propesed algorythm (As I can see, correct me if I'm wrong). It would be cool, if where were some ready javascript (or other language) implementation, because this is my hoppy project, I'm not a cryptographer, and so, I'm relying on proven and reliable algorythms that are already implemented by professionals (you can see list of libraries, used by cryptboard here: https://cryptboard.io/about at the "Tools and libraries used in this project" paragraph).

Also, for now I don't know, how can described algorythm be used in case of the cryptboard web app. Would you kindly state your thoughts on how it could be implemented (from the side of user) and how could it make usage of the tool easier / safer?

[MihanEntalpo]

As there are not enough information on what to do really, closing this.

[ignoramous]

I've read the document briefly, and it looks like it's a draft

Well, CPACE isn't a standard yet (it will be), but it is a pretty good upgrade to the existing scheme.

some real implementation of propesed algo

There is. Although, a bit contrived in the spec. Someone wrote a brief summary of the protocol (not sure based on which draft version); https://gist.github.com/Sc00bz/1375a5dc7d1e8a1ffdfb789d3f4c6593

And here's a Go impl (of draft 1): https://github.com/FiloSottile/go-cpace-ristretto255/blob/24d601e2e469f9754e5b9cc3cb5b484cf9695003/cpace.go#L106

A libsodium impl (usable in javascript with libsodium.js, may be?) also exists: https://github.com/jedisct1/cpace

[MihanEntalpo]

Thanks for the information.

[CPace](https://tools.ietf.org/id/draft-haase-cpace-01.html) is a protocol for two parties that share a low-entropy secret (password) to derive a strong shared key without disclosing the secret to offline dictionary attacks.

and

CPace is a balanced PAKE, meaning that both parties must know the low-entropy secret.

I'm trying to guest, how would I use this.

My current use-case of the cryptboard is following:

1) Open it on remote machine without clipboard access 2) Open it on my own machine 3) Using my mobile phone open both QR-codes of pages, so public keys would be exchanged, and all three devices could send messages to each other. 4) As public keys has benn exchanged, data could be encrypted now, and could be decrypted only by receiver.

Ok, CPACE allows two parties to create some strong cryptographic key, the both know, by using some data-exchange operations and calculations, where password, known by both parties is involved.

For example, I could: 1) Open the site in remote machine 2) Open the site in local machine 3) Enter some simple password on both of them (for example, "hello") and..... How do they know that one of them should write to another, to build common secret key?

Both of instances would have it's own UID, so, I need to type first UID on the second machine, and type UID of second machine on the first one. As it's UUID - it becames quite hard to do manually (and clipboard doesn't work), and there are some chance of error while typing it, so I still need the QR-code that is a essential part of the system when you don't have clipboard access, must copy data, and have visual access to some interface, where QR-code could be displayed.

Ok, I can make interface, where, 1) after password is entered, QR-code containing UID generated, 2) and after open it with mobile phone, I get into a "pairing page", where I told to open another QR-code (from my second machine) to make it paired. 3) When, the "pairing" page send to server request about "This two UIDs wants to get paired", 4) server prepares some service messages, that being read by clients, make them know, that "UID1 wants to create shared key with UID2" and "UID2 wants to create shared key with UID1" (actually, that it would be only one message, to the first UID about second one (server would sort whoose two UIDs by alphabet, and first one - would be the first, because we need only one key-generating-sequence, not two)). 5) So, client1, after reading service message from server, about client2 want to create shared key, send to client2 message (via server of course) with it's UID and random X, 6) client2 acquires this data from server, make required calculations with the data and it's password, and send intermediate data to client1 7) client1 make it's part of calculations with the known password, and send intermediate data back 9) both clients make some calculations on intermediate data and got the key. 10) After that key could be used for symmetric encryption, such as AES.

What problems are solved with this approach?

1) Slightly less chance to use man-in-the-middle attack. But not zero, because you have to somehow share the password. Ok, it could be just "password" or "123qwe" because random generation makes it stronger. But, BOTH of parties should know it. 2) Maybe, not-so-good RSA key generation could be less safe than this algorythm - I'm not a cryptogaphist, so I cannot examine this risk scientifically. Also, ability to specify your own RSA keys, generated on a physical hardware with good crypto-randomness and lots of key bits solves this problem better.

What new problems are introduces by this approach? 1) Usage became less convinient. Now you not only should open QR-code, by also enter some password. Any automatic passwor dgeneration couldn't be used, as password should be equal on two machines, and known by you. If you want to connect multiple devices, or multiple people to use cryptboard as a chat, you have to enter the same password everywhere, or enter different passwords on every pair of devices. So, between PC1 and Mobile password would be "password1", between PC2 and Mobile - it would be "password2", and between PC1 and PC2 it would be "password3". Or everywhere it would be just "password". 2) Passwords should be shared between parties by some side-channel, and there are always a way to leak. This is a purpose of encrypted chat, to NOT send anything so important like password via possible hostile environment. If you use cryptboard with AES+RSA encryption, you've examined source code (or event deployed your own server), and after keys exchange you've compared the avatar of your counterpart, or even manually compared UID and public key, it's done, you could relax, as you a safe now. In case when you should share password, you must play in conspiracy game with you counterpart as in old good times (pass little papers with password, use riddles to make your receiver know of tha password and so on). I don't see how passing password is safe.

Anyway, lets imagine that password itself could be used as an encryption key and it couldn't be broken. So, if I know password "123qwe", and you don't know it, you cannot brutforce it, because there are no such algorythms available (just imagine). What would you want to do in this case? Of course, steal the password somehow. This is what you'll want to do with CPACE.

So, if I didn't convince you, that this application is not the case where such algorythm should be applied, please make your proposition on how it could be really used, and how to solve the problems above

[ignoramous]

Ah, I see. So this is a group, not just one-to-one communication (like Direct Messages).

In that case, CPACE really doesn't help (as you identified). Sorry for the confusion.

For group messaging such as the one supported by cryptboard today, you might want to give KeyBase KEX (KeyExchange) for teams with PTKs (per-team keys) a look (it isn't ground breaking or anything, but pretty solid).

I guess, there's nothing much from CPACE's PoV to do here. Closing...

[MihanEntalpo]

It's even more complicated. PTKs (per-team keys) is used for "groups", but there is no "groups" concept in cryptboard. In cryptboard every user has it's list of receivers, and able to send messages to all of them (like in usual webchat with multiple users in a chatroom). But user can disable sending of message to some of the receiver. Also, some of the receivers could not know about user itself, just accept messages. Every message sent is encrypted for each receiver by it's public key, so there are no any "group" or any "group key", and message got encrypted by public keys of every receiver separatedly. Also, any group key would be not such secure as a personal keys.