#StackBounty: #elliptic-curves #diffie-hellman #key-exchange #backdoors About a SETUP mechanism on ECDH

Bounty: 50

I’m following these three articles:

  1. Kleptography: Using Cryptography Against Cryptography,
  2. Kleptographic Attack on Elliptic Curve Based
    Cryptographic Protocols
    and
  3. Elliptic Curve Kleptography .

In the first article, a kleptogrpahic attack based on DLP cryptosystem is described. In particular, we can read (pg 67) that $$ z equiv g^{c_1-Wt}Y^{-ac_1-b} bmod p$$
where $c_1$ is the private key of Alice (the sender); $Y equiv g^X bmod p$ is the public key of Eve (eavesdropper); $g$ is a generator of $mathbb{Z}_p$ and $a,b,W$ are three integers used for precaution. Indeed, even if a user is able to invert the hash function $H$, then it is still impossible to detect if the device has been contaminated with a SETUP mechanism (pg 68-69).

In the second article, an analogous of this attack is presented in the context of elliptic curves. Here (pg 139907, algorithm 5)
$$z = (c_1-Wt)P+(-ac_1-b)Y $$
where $P$ is the base point of a strong elliptic curve $E$ over $mathbb{F}_q$. Here, there is not a well know theory such as quadratic-residues and their distributions $mathbb{Z}_p$. Indeed, in 3 we can read: "This kind of
probabilistic detection by the user is very difficult in
elliptic curve cryptosystems compared to discrete log
systems where quadratic residuosity can be used to test a
possible relation between the attacker’s public key and $z$".

Then, my first question is: could the SETUP attack applied to EC be simplified? For example, deleting some extra number $a$ or $b$?

However, in the third article, $z$ is a little more complicated than what we saw in the first two papers.
begin{equation}
z = (ac_1 + h cdot j)P + (bc_1+e cdot u)Y
end{equation}

where $a,h,e,b$ are fixed integers, and $j,u in {0,1 }$ are uniformly and independently chosen at random.

Therefore, my second question rises. What is the best implementation of SETUP attack in ECDH? The second article or the third one?

Here, the "best implementation" means that comparing the algorithms in 2 and 3, we want to find the faster and easier algorithm which leads to the same result and which is the safest. Indeed, the security is based on the randomness of $z$, and in 1 is explained why. Following this first direction, one can think that the algorithm in 2 is secured as the first one 1. However, on elliptic curves, strange things may happen, and in order to obtain the randomness of $z$, we should use the third algorithm 3. I don’t think this is the case, i.e. I think 2 it’s enough to reach the wanted level of security, without using extra integers $a,u$ as in 3.


Get this bounty!!!

#StackBounty: #protocol-design #key-exchange #nonce Use of nonces in the SIGMA protocol and not in C(2e, 2s) of NIST SP800-56a?

Bounty: 50

While reading the paper on the SIGMA: the ‘SIGn-and-MAc’ Approach to Authenticated Diffie-Hellman and its Use in the IKE Protocols (Krawczyk,2003), I noticed that in the "full-fledge" protocol section on page 24, the author says "Very importantly, the protocols should separate the functions of DH exponentials and freshness nonces into different elements".

I have a few questions based on this:

  1. Why can the DH exponentials NOT be used for freshness during key exchange protocols?
  2. Based on my reading on NIST SP800-56A, this protocol is similar to C(2e, 2s) scheme with a bilateral key confirmation. In the NIST schemes, however, while producing the MAC tags for key confirmation, it appears that the ephemeral public key is used for freshness. Why is it okay here but not in the SIGMA protocol?

If I’m conflating the two protocols, I’d like to understand the differences in SIGMA vs the NIST scheme that allows the ephemeral public key to be used for freshness in one case but not the other.


Get this bounty!!!

#StackBounty: #key-exchange #end-to-end-encryption #blockchain #keybase How can I verify Keybase's end-to-end encryption between me…

Bounty: 50

The premise of end-to-end encryption (E2EE) is that the client is secure and trustworthy, your end devices is secure and trustworthy, but the network and server need not be trusted. You’ve read all the code in the client, or someone you trust has done so for you. But after loading the code onto your phone — installing the Keybase app — and starting a chat with your friend, you still need to verify that the server sent you the right encryption key. Since you can’t host your own server, it has to be the Keybase, Inc’s server that sends you the encryption key of your friend.

It’s pretty standard for E2EE software that the (client) code is open, the server sends you the encryption key, and you can check the encryption keys out of band. In Signal you check the safety number, in Wire you check the device fingerprints, and in Telegram you check the encryption key. If they match, you know (based on the open client code and the cryptography it uses) that there is no (wo)man in the middle.

How does this work with Keybase? Their documentation explains parts of it:

Alice and Bob share a symmetric encryption key, which they pass through the server by encrypting it to each of their devices’ public encryption keys.

Okay, so either we verify the symmetric key (identical on both phones), or we verify the public key (I should be able to display mine on my phone, and my friend will call up what their phone thinks my public key is, and that should match).

The weird thing is that there is no button to do either of this. The documentation doesn’t mention any and I can’t find it when looking around.

Further on, it explains the public keys are put into your signature chain:

All Keybase devices publish a crypto_box public key and a crypto_sign public key when they’re first provisioned. Those keys live in the user’s signature chain […] A chat symmetric encryption key is 32 random bytes. It’s shared by everyone in the chat, […] When a new device needs this shared key, another device that has it will encrypt it with the new device’s public crypto_box key and then upload it to the Keybase server.

So if I’m reading this right, when my friend opens a new chat with me, their client generates the shared secret, it will take the public key from the crypto_box inside my signature chain and encrypt the shared secret with that public key, and upload the result to Keybase’s server so that I can download and decrypt it, thereby establishing the shared secret and starting the chat.

… but where does that signature chain come from? This has to be fetched from Keybase servers, so since there is no way to display it, I have to trust the server to send me the right key. How does that make sense when they claim “all messages are secure, end-to-end encrypted”? The client also occasionally and briefly displays a banner above the chat saying “end-to-end encrypted”.

There is documentation about how to do the verification step by step, but aside from that the instructions are broken (there is no sigs field in root_desc, the result of root.json?hash=X), this is not something I can do on my phone. A malicious server could return the correct answers to my command line client while telling the mobile app that the signature chain contains an entirely different key (namely the one the malicious actor uses to perform the MitM).

When talking about it to others, they mention this blockchain thing as the reason why it’s secure without needing to verify anything yourself, but I can’t figure out how it works.

  1. Do Keybase chats require any kind of key to be manually verified for end-to-end encryption, or does the blockchain data (which the app could verify silently under the hood) somehow prevent us from having to compare fingerprints/keys/sigchains?
  2. If we do need to compare fingerprints/keys/sigchains, how can that be done in the Keybase app?

Update: A friend linked this GitHub issue, where it is basically said that the whole blockchain thing isn’t yet done by the app. Leaving in the middle whether (something like) SPV is a good solution, it is currently not implemented. That strikes out the first option if I’m not mistaken.

Since the app also seems not to allow fulfilling the second option (comparing keys), I guess this concludes that there is no E2EE currently implemented in Keybase? An attack is hard to pull off: even a malicious server (very ideal position) would have to MitM from the start, so they have to have prior knowledge of whom to target. But we do trust the server to be honest at least some of the time. Or am I still missing some way that makes this true end to end encryption?

Update 2: It was mentioned on hacker news that the app should check third party proofs by itself. This is not exactly what end to end encryption means since it still relies on third parties, but nevertheless, having to own 2 or more companies’ servers before being able to MitM someone’s keys (which are additionally TOFU’d) should give quite some confidence.
However, when checking in Wireshark whether it actually does this (ask the Twitter API for the proof string and verify the signature with the the public key it received from Keybase), Keybase on my phone did not contact Twitter at all. (It did, however, proudly proclaim that the new chat was end to end encrypted.)

For those wondering whether the Wireshark test controls for various things:

  • The username with whom a chat was started was never typed into the test system (the one that started the chat) prior to the packet capture.
  • The two accounts never had any sort of contact before, on any device. They also don’t follow each other. Until the chat was established, the other party did not even know my username, so they could not have triggered anything either.
  • The packet capture started before the username was typed into the search field on the test device and ended only after Keybase completely established the chat and claimed it was end to end encrypted.
  • Twitter seems to host all its services on its own IP range, and none of the IPs the test system talked to during chat establishment fell inside that range. If this assumption is false and the Keybase client uses endpoints outside of 104.244.40.0/21, please comment. I checked all IPs and all are implausible to be a front for Twitter (details on hacker news), but I would be interested to know if Twitter publishes tweets on Amazon Web Services’ Simple Storage Service or something.
  • It is deemed implausible for the mobile Keybase client to simply have downloaded all signature chains from all users that exist on Keybase and to have checked all their proofs prior to starting the packet capture. This is the only way I can think of how the third party hosted proof could have been verified prior to the packet capture.


Get this bounty!!!

#StackBounty: #key-exchange #end-to-end-encryption #blockchain #keybase How can I verify Keybase's end-to-end encryption between me…

Bounty: 50

The premise of end-to-end encryption (E2EE) is that the client is secure and trustworthy, your end devices is secure and trustworthy, but the network and server need not be trusted. You’ve read all the code in the client, or someone you trust has done so for you. But after loading the code onto your phone — installing the Keybase app — and starting a chat with your friend, you still need to verify that the server sent you the right encryption key. Since you can’t host your own server, it has to be the Keybase, Inc’s server that sends you the encryption key of your friend.

It’s pretty standard for E2EE software that the (client) code is open, the server sends you the encryption key, and you can check the encryption keys out of band. In Signal you check the safety number, in Wire you check the device fingerprints, and in Telegram you check the encryption key. If they match, you know (based on the open client code and the cryptography it uses) that there is no (wo)man in the middle.

How does this work with Keybase? Their documentation explains parts of it:

Alice and Bob share a symmetric encryption key, which they pass through the server by encrypting it to each of their devices’ public encryption keys.

Okay, so either we verify the symmetric key (identical on both phones), or we verify the public key (I should be able to display mine on my phone, and my friend will call up what their phone thinks my public key is, and that should match).

The weird thing is that there is no button to do either of this. The documentation doesn’t mention any and I can’t find it when looking around.

Further on, it explains the public keys are put into your signature chain:

All Keybase devices publish a crypto_box public key and a crypto_sign public key when they’re first provisioned. Those keys live in the user’s signature chain […] A chat symmetric encryption key is 32 random bytes. It’s shared by everyone in the chat, […] When a new device needs this shared key, another device that has it will encrypt it with the new device’s public crypto_box key and then upload it to the Keybase server.

So if I’m reading this right, when my friend opens a new chat with me, their client generates the shared secret, it will take the public key from the crypto_box inside my signature chain and encrypt the shared secret with that public key, and upload the result to Keybase’s server so that I can download and decrypt it, thereby establishing the shared secret and starting the chat.

… but where does that signature chain come from? This has to be fetched from Keybase servers, so since there is no way to display it, I have to trust the server to send me the right key. How does that make sense when they claim “all messages are secure, end-to-end encrypted”? The client also occasionally and briefly displays a banner above the chat saying “end-to-end encrypted”.

There is documentation about how to do the verification step by step, but aside from that the instructions are broken (there is no sigs field in root_desc, the result of root.json?hash=X), this is not something I can do on my phone. A malicious server could return the correct answers to my command line client while telling the mobile app that the signature chain contains an entirely different key (namely the one the malicious actor uses to perform the MitM).

When talking about it to others, they mention this blockchain thing as the reason why it’s secure without needing to verify anything yourself, but I can’t figure out how it works.

  1. Do Keybase chats require any kind of key to be manually verified for end-to-end encryption, or does the blockchain data (which the app could verify silently under the hood) somehow prevent us from having to compare fingerprints/keys/sigchains?
  2. If we do need to compare fingerprints/keys/sigchains, how can that be done in the Keybase app?

Update: A friend linked this GitHub issue, where it is basically said that the whole blockchain thing isn’t yet done by the app. Leaving in the middle whether (something like) SPV is a good solution, it is currently not implemented. That strikes out the first option if I’m not mistaken.

Since the app also seems not to allow fulfilling the second option (comparing keys), I guess this concludes that there is no E2EE currently implemented in Keybase? An attack is hard to pull off: even a malicious server (very ideal position) would have to MitM from the start, so they have to have prior knowledge of whom to target. But we do trust the server to be honest at least some of the time. Or am I still missing some way that makes this true end to end encryption?

Update 2: It was mentioned on hacker news that the app should check third party proofs by itself. This is not exactly what end to end encryption means since it still relies on third parties, but nevertheless, having to own 2 or more companies’ servers before being able to MitM someone’s keys (which are additionally TOFU’d) should give quite some confidence.
However, when checking in Wireshark whether it actually does this (ask the Twitter API for the proof string and verify the signature with the the public key it received from Keybase), Keybase on my phone did not contact Twitter at all. (It did, however, proudly proclaim that the new chat was end to end encrypted.)

For those wondering whether the Wireshark test controls for various things:

  • The username with whom a chat was started was never typed into the test system (the one that started the chat) prior to the packet capture.
  • The two accounts never had any sort of contact before, on any device. They also don’t follow each other. Until the chat was established, the other party did not even know my username, so they could not have triggered anything either.
  • The packet capture started before the username was typed into the search field on the test device and ended only after Keybase completely established the chat and claimed it was end to end encrypted.
  • Twitter seems to host all its services on its own IP range, and none of the IPs the test system talked to during chat establishment fell inside that range. If this assumption is false and the Keybase client uses endpoints outside of 104.244.40.0/21, please comment. I checked all IPs and all are implausible to be a front for Twitter (details on hacker news), but I would be interested to know if Twitter publishes tweets on Amazon Web Services’ Simple Storage Service or something.
  • It is deemed implausible for the mobile Keybase client to simply have downloaded all signature chains from all users that exist on Keybase and to have checked all their proofs prior to starting the packet capture. This is the only way I can think of how the third party hosted proof could have been verified prior to the packet capture.


Get this bounty!!!

#StackBounty: #key-exchange #end-to-end-encryption #blockchain #keybase How can I verify Keybase's end-to-end encryption between me…

Bounty: 50

The premise of end-to-end encryption (E2EE) is that the client is secure and trustworthy, your end devices is secure and trustworthy, but the network and server need not be trusted. You’ve read all the code in the client, or someone you trust has done so for you. But after loading the code onto your phone — installing the Keybase app — and starting a chat with your friend, you still need to verify that the server sent you the right encryption key. Since you can’t host your own server, it has to be the Keybase, Inc’s server that sends you the encryption key of your friend.

It’s pretty standard for E2EE software that the (client) code is open, the server sends you the encryption key, and you can check the encryption keys out of band. In Signal you check the safety number, in Wire you check the device fingerprints, and in Telegram you check the encryption key. If they match, you know (based on the open client code and the cryptography it uses) that there is no (wo)man in the middle.

How does this work with Keybase? Their documentation explains parts of it:

Alice and Bob share a symmetric encryption key, which they pass through the server by encrypting it to each of their devices’ public encryption keys.

Okay, so either we verify the symmetric key (identical on both phones), or we verify the public key (I should be able to display mine on my phone, and my friend will call up what their phone thinks my public key is, and that should match).

The weird thing is that there is no button to do either of this. The documentation doesn’t mention any and I can’t find it when looking around.

Further on, it explains the public keys are put into your signature chain:

All Keybase devices publish a crypto_box public key and a crypto_sign public key when they’re first provisioned. Those keys live in the user’s signature chain […] A chat symmetric encryption key is 32 random bytes. It’s shared by everyone in the chat, […] When a new device needs this shared key, another device that has it will encrypt it with the new device’s public crypto_box key and then upload it to the Keybase server.

So if I’m reading this right, when my friend opens a new chat with me, their client generates the shared secret, it will take the public key from the crypto_box inside my signature chain and encrypt the shared secret with that public key, and upload the result to Keybase’s server so that I can download and decrypt it, thereby establishing the shared secret and starting the chat.

… but where does that signature chain come from? This has to be fetched from Keybase servers, so since there is no way to display it, I have to trust the server to send me the right key. How does that make sense when they claim “all messages are secure, end-to-end encrypted”? The client also occasionally and briefly displays a banner above the chat saying “end-to-end encrypted”.

There is documentation about how to do the verification step by step, but aside from that the instructions are broken (there is no sigs field in root_desc, the result of root.json?hash=X), this is not something I can do on my phone. A malicious server could return the correct answers to my command line client while telling the mobile app that the signature chain contains an entirely different key (namely the one the malicious actor uses to perform the MitM).

When talking about it to others, they mention this blockchain thing as the reason why it’s secure without needing to verify anything yourself, but I can’t figure out how it works.

  1. Do Keybase chats require any kind of key to be manually verified for end-to-end encryption, or does the blockchain data (which the app could verify silently under the hood) somehow prevent us from having to compare fingerprints/keys/sigchains?
  2. If we do need to compare fingerprints/keys/sigchains, how can that be done in the Keybase app?

Update: A friend linked this GitHub issue, where it is basically said that the whole blockchain thing isn’t yet done by the app. Leaving in the middle whether (something like) SPV is a good solution, it is currently not implemented. That strikes out the first option if I’m not mistaken.

Since the app also seems not to allow fulfilling the second option (comparing keys), I guess this concludes that there is no E2EE currently implemented in Keybase? An attack is hard to pull off: even a malicious server (very ideal position) would have to MitM from the start, so they have to have prior knowledge of whom to target. But we do trust the server to be honest at least some of the time. Or am I still missing some way that makes this true end to end encryption?

Update 2: It was mentioned on hacker news that the app should check third party proofs by itself. This is not exactly what end to end encryption means since it still relies on third parties, but nevertheless, having to own 2 or more companies’ servers before being able to MitM someone’s keys (which are additionally TOFU’d) should give quite some confidence.
However, when checking in Wireshark whether it actually does this (ask the Twitter API for the proof string and verify the signature with the the public key it received from Keybase), Keybase on my phone did not contact Twitter at all. (It did, however, proudly proclaim that the new chat was end to end encrypted.)

For those wondering whether the Wireshark test controls for various things:

  • The username with whom a chat was started was never typed into the test system (the one that started the chat) prior to the packet capture.
  • The two accounts never had any sort of contact before, on any device. They also don’t follow each other. Until the chat was established, the other party did not even know my username, so they could not have triggered anything either.
  • The packet capture started before the username was typed into the search field on the test device and ended only after Keybase completely established the chat and claimed it was end to end encrypted.
  • Twitter seems to host all its services on its own IP range, and none of the IPs the test system talked to during chat establishment fell inside that range. If this assumption is false and the Keybase client uses endpoints outside of 104.244.40.0/21, please comment. I checked all IPs and all are implausible to be a front for Twitter (details on hacker news), but I would be interested to know if Twitter publishes tweets on Amazon Web Services’ Simple Storage Service or something.
  • It is deemed implausible for the mobile Keybase client to simply have downloaded all signature chains from all users that exist on Keybase and to have checked all their proofs prior to starting the packet capture. This is the only way I can think of how the third party hosted proof could have been verified prior to the packet capture.


Get this bounty!!!

#StackBounty: #key-exchange #end-to-end-encryption #blockchain #keybase How can I verify Keybase's end-to-end encryption between me…

Bounty: 50

The premise of end-to-end encryption (E2EE) is that the client is secure and trustworthy, your end devices is secure and trustworthy, but the network and server need not be trusted. You’ve read all the code in the client, or someone you trust has done so for you. But after loading the code onto your phone — installing the Keybase app — and starting a chat with your friend, you still need to verify that the server sent you the right encryption key. Since you can’t host your own server, it has to be the Keybase, Inc’s server that sends you the encryption key of your friend.

It’s pretty standard for E2EE software that the (client) code is open, the server sends you the encryption key, and you can check the encryption keys out of band. In Signal you check the safety number, in Wire you check the device fingerprints, and in Telegram you check the encryption key. If they match, you know (based on the open client code and the cryptography it uses) that there is no (wo)man in the middle.

How does this work with Keybase? Their documentation explains parts of it:

Alice and Bob share a symmetric encryption key, which they pass through the server by encrypting it to each of their devices’ public encryption keys.

Okay, so either we verify the symmetric key (identical on both phones), or we verify the public key (I should be able to display mine on my phone, and my friend will call up what their phone thinks my public key is, and that should match).

The weird thing is that there is no button to do either of this. The documentation doesn’t mention any and I can’t find it when looking around.

Further on, it explains the public keys are put into your signature chain:

All Keybase devices publish a crypto_box public key and a crypto_sign public key when they’re first provisioned. Those keys live in the user’s signature chain […] A chat symmetric encryption key is 32 random bytes. It’s shared by everyone in the chat, […] When a new device needs this shared key, another device that has it will encrypt it with the new device’s public crypto_box key and then upload it to the Keybase server.

So if I’m reading this right, when my friend opens a new chat with me, their client generates the shared secret, it will take the public key from the crypto_box inside my signature chain and encrypt the shared secret with that public key, and upload the result to Keybase’s server so that I can download and decrypt it, thereby establishing the shared secret and starting the chat.

… but where does that signature chain come from? This has to be fetched from Keybase servers, so since there is no way to display it, I have to trust the server to send me the right key. How does that make sense when they claim “all messages are secure, end-to-end encrypted”? The client also occasionally and briefly displays a banner above the chat saying “end-to-end encrypted”.

There is documentation about how to do the verification step by step, but aside from that the instructions are broken (there is no sigs field in root_desc, the result of root.json?hash=X), this is not something I can do on my phone. A malicious server could return the correct answers to my command line client while telling the mobile app that the signature chain contains an entirely different key (namely the one the malicious actor uses to perform the MitM).

When talking about it to others, they mention this blockchain thing as the reason why it’s secure without needing to verify anything yourself, but I can’t figure out how it works.

  1. Do Keybase chats require any kind of key to be manually verified for end-to-end encryption, or does the blockchain data (which the app could verify silently under the hood) somehow prevent us from having to compare fingerprints/keys/sigchains?
  2. If we do need to compare fingerprints/keys/sigchains, how can that be done in the Keybase app?

Update: A friend linked this GitHub issue, where it is basically said that the whole blockchain thing isn’t yet done by the app. Leaving in the middle whether (something like) SPV is a good solution, it is currently not implemented. That strikes out the first option if I’m not mistaken.

Since the app also seems not to allow fulfilling the second option (comparing keys), I guess this concludes that there is no E2EE currently implemented in Keybase? An attack is hard to pull off: even a malicious server (very ideal position) would have to MitM from the start, so they have to have prior knowledge of whom to target. But we do trust the server to be honest at least some of the time. Or am I still missing some way that makes this true end to end encryption?

Update 2: It was mentioned on hacker news that the app should check third party proofs by itself. This is not exactly what end to end encryption means since it still relies on third parties, but nevertheless, having to own 2 or more companies’ servers before being able to MitM someone’s keys (which are additionally TOFU’d) should give quite some confidence.
However, when checking in Wireshark whether it actually does this (ask the Twitter API for the proof string and verify the signature with the the public key it received from Keybase), Keybase on my phone did not contact Twitter at all. (It did, however, proudly proclaim that the new chat was end to end encrypted.)

For those wondering whether the Wireshark test controls for various things:

  • The username with whom a chat was started was never typed into the test system (the one that started the chat) prior to the packet capture.
  • The two accounts never had any sort of contact before, on any device. They also don’t follow each other. Until the chat was established, the other party did not even know my username, so they could not have triggered anything either.
  • The packet capture started before the username was typed into the search field on the test device and ended only after Keybase completely established the chat and claimed it was end to end encrypted.
  • Twitter seems to host all its services on its own IP range, and none of the IPs the test system talked to during chat establishment fell inside that range. If this assumption is false and the Keybase client uses endpoints outside of 104.244.40.0/21, please comment. I checked all IPs and all are implausible to be a front for Twitter (details on hacker news), but I would be interested to know if Twitter publishes tweets on Amazon Web Services’ Simple Storage Service or something.
  • It is deemed implausible for the mobile Keybase client to simply have downloaded all signature chains from all users that exist on Keybase and to have checked all their proofs prior to starting the packet capture. This is the only way I can think of how the third party hosted proof could have been verified prior to the packet capture.


Get this bounty!!!

#StackBounty: #key-exchange #end-to-end-encryption #blockchain #keybase How can I verify Keybase's end-to-end encryption between me…

Bounty: 50

The premise of end-to-end encryption (E2EE) is that the client is secure and trustworthy, your end devices is secure and trustworthy, but the network and server need not be trusted. You’ve read all the code in the client, or someone you trust has done so for you. But after loading the code onto your phone — installing the Keybase app — and starting a chat with your friend, you still need to verify that the server sent you the right encryption key. Since you can’t host your own server, it has to be the Keybase, Inc’s server that sends you the encryption key of your friend.

It’s pretty standard for E2EE software that the (client) code is open, the server sends you the encryption key, and you can check the encryption keys out of band. In Signal you check the safety number, in Wire you check the device fingerprints, and in Telegram you check the encryption key. If they match, you know (based on the open client code and the cryptography it uses) that there is no (wo)man in the middle.

How does this work with Keybase? Their documentation explains parts of it:

Alice and Bob share a symmetric encryption key, which they pass through the server by encrypting it to each of their devices’ public encryption keys.

Okay, so either we verify the symmetric key (identical on both phones), or we verify the public key (I should be able to display mine on my phone, and my friend will call up what their phone thinks my public key is, and that should match).

The weird thing is that there is no button to do either of this. The documentation doesn’t mention any and I can’t find it when looking around.

Further on, it explains the public keys are put into your signature chain:

All Keybase devices publish a crypto_box public key and a crypto_sign public key when they’re first provisioned. Those keys live in the user’s signature chain […] A chat symmetric encryption key is 32 random bytes. It’s shared by everyone in the chat, […] When a new device needs this shared key, another device that has it will encrypt it with the new device’s public crypto_box key and then upload it to the Keybase server.

So if I’m reading this right, when my friend opens a new chat with me, their client generates the shared secret, it will take the public key from the crypto_box inside my signature chain and encrypt the shared secret with that public key, and upload the result to Keybase’s server so that I can download and decrypt it, thereby establishing the shared secret and starting the chat.

… but where does that signature chain come from? This has to be fetched from Keybase servers, so since there is no way to display it, I have to trust the server to send me the right key. How does that make sense when they claim “all messages are secure, end-to-end encrypted”? The client also occasionally and briefly displays a banner above the chat saying “end-to-end encrypted”.

There is documentation about how to do the verification step by step, but aside from that the instructions are broken (there is no sigs field in root_desc, the result of root.json?hash=X), this is not something I can do on my phone. A malicious server could return the correct answers to my command line client while telling the mobile app that the signature chain contains an entirely different key (namely the one the malicious actor uses to perform the MitM).

When talking about it to others, they mention this blockchain thing as the reason why it’s secure without needing to verify anything yourself, but I can’t figure out how it works.

  1. Do Keybase chats require any kind of key to be manually verified for end-to-end encryption, or does the blockchain data (which the app could verify silently under the hood) somehow prevent us from having to compare fingerprints/keys/sigchains?
  2. If we do need to compare fingerprints/keys/sigchains, how can that be done in the Keybase app?

Update: A friend linked this GitHub issue, where it is basically said that the whole blockchain thing isn’t yet done by the app. Leaving in the middle whether (something like) SPV is a good solution, it is currently not implemented. That strikes out the first option if I’m not mistaken.

Since the app also seems not to allow fulfilling the second option (comparing keys), I guess this concludes that there is no E2EE currently implemented in Keybase? An attack is hard to pull off: even a malicious server (very ideal position) would have to MitM from the start, so they have to have prior knowledge of whom to target. But we do trust the server to be honest at least some of the time. Or am I still missing some way that makes this true end to end encryption?

Update 2: It was mentioned on hacker news that the app should check third party proofs by itself. This is not exactly what end to end encryption means since it still relies on third parties, but nevertheless, having to own 2 or more companies’ servers before being able to MitM someone’s keys (which are additionally TOFU’d) should give quite some confidence.
However, when checking in Wireshark whether it actually does this (ask the Twitter API for the proof string and verify the signature with the the public key it received from Keybase), Keybase on my phone did not contact Twitter at all. (It did, however, proudly proclaim that the new chat was end to end encrypted.)

For those wondering whether the Wireshark test controls for various things:

  • The username with whom a chat was started was never typed into the test system (the one that started the chat) prior to the packet capture.
  • The two accounts never had any sort of contact before, on any device. They also don’t follow each other. Until the chat was established, the other party did not even know my username, so they could not have triggered anything either.
  • The packet capture started before the username was typed into the search field on the test device and ended only after Keybase completely established the chat and claimed it was end to end encrypted.
  • Twitter seems to host all its services on its own IP range, and none of the IPs the test system talked to during chat establishment fell inside that range. If this assumption is false and the Keybase client uses endpoints outside of 104.244.40.0/21, please comment. I checked all IPs and all are implausible to be a front for Twitter (details on hacker news), but I would be interested to know if Twitter publishes tweets on Amazon Web Services’ Simple Storage Service or something.
  • It is deemed implausible for the mobile Keybase client to simply have downloaded all signature chains from all users that exist on Keybase and to have checked all their proofs prior to starting the packet capture. This is the only way I can think of how the third party hosted proof could have been verified prior to the packet capture.


Get this bounty!!!

#StackBounty: #key-exchange #end-to-end-encryption #blockchain #keybase How can I verify Keybase's end-to-end encryption between me…

Bounty: 50

The premise of end-to-end encryption (E2EE) is that the client is secure and trustworthy, your end devices is secure and trustworthy, but the network and server need not be trusted. You’ve read all the code in the client, or someone you trust has done so for you. But after loading the code onto your phone — installing the Keybase app — and starting a chat with your friend, you still need to verify that the server sent you the right encryption key. Since you can’t host your own server, it has to be the Keybase, Inc’s server that sends you the encryption key of your friend.

It’s pretty standard for E2EE software that the (client) code is open, the server sends you the encryption key, and you can check the encryption keys out of band. In Signal you check the safety number, in Wire you check the device fingerprints, and in Telegram you check the encryption key. If they match, you know (based on the open client code and the cryptography it uses) that there is no (wo)man in the middle.

How does this work with Keybase? Their documentation explains parts of it:

Alice and Bob share a symmetric encryption key, which they pass through the server by encrypting it to each of their devices’ public encryption keys.

Okay, so either we verify the symmetric key (identical on both phones), or we verify the public key (I should be able to display mine on my phone, and my friend will call up what their phone thinks my public key is, and that should match).

The weird thing is that there is no button to do either of this. The documentation doesn’t mention any and I can’t find it when looking around.

Further on, it explains the public keys are put into your signature chain:

All Keybase devices publish a crypto_box public key and a crypto_sign public key when they’re first provisioned. Those keys live in the user’s signature chain […] A chat symmetric encryption key is 32 random bytes. It’s shared by everyone in the chat, […] When a new device needs this shared key, another device that has it will encrypt it with the new device’s public crypto_box key and then upload it to the Keybase server.

So if I’m reading this right, when my friend opens a new chat with me, their client generates the shared secret, it will take the public key from the crypto_box inside my signature chain and encrypt the shared secret with that public key, and upload the result to Keybase’s server so that I can download and decrypt it, thereby establishing the shared secret and starting the chat.

… but where does that signature chain come from? This has to be fetched from Keybase servers, so since there is no way to display it, I have to trust the server to send me the right key. How does that make sense when they claim “all messages are secure, end-to-end encrypted”? The client also occasionally and briefly displays a banner above the chat saying “end-to-end encrypted”.

There is documentation about how to do the verification step by step, but aside from that the instructions are broken (there is no sigs field in root_desc, the result of root.json?hash=X), this is not something I can do on my phone. A malicious server could return the correct answers to my command line client while telling the mobile app that the signature chain contains an entirely different key (namely the one the malicious actor uses to perform the MitM).

When talking about it to others, they mention this blockchain thing as the reason why it’s secure without needing to verify anything yourself, but I can’t figure out how it works.

  1. Do Keybase chats require any kind of key to be manually verified for end-to-end encryption, or does the blockchain data (which the app could verify silently under the hood) somehow prevent us from having to compare fingerprints/keys/sigchains?
  2. If we do need to compare fingerprints/keys/sigchains, how can that be done in the Keybase app?

Update: A friend linked this GitHub issue, where it is basically said that the whole blockchain thing isn’t yet done by the app. Leaving in the middle whether (something like) SPV is a good solution, it is currently not implemented. That strikes out the first option if I’m not mistaken.

Since the app also seems not to allow fulfilling the second option (comparing keys), I guess this concludes that there is no E2EE currently implemented in Keybase? An attack is hard to pull off: even a malicious server (very ideal position) would have to MitM from the start, so they have to have prior knowledge of whom to target. But we do trust the server to be honest at least some of the time. Or am I still missing some way that makes this true end to end encryption?

Update 2: It was mentioned on hacker news that the app should check third party proofs by itself. This is not exactly what end to end encryption means since it still relies on third parties, but nevertheless, having to own 2 or more companies’ servers before being able to MitM someone’s keys (which are additionally TOFU’d) should give quite some confidence.
However, when checking in Wireshark whether it actually does this (ask the Twitter API for the proof string and verify the signature with the the public key it received from Keybase), Keybase on my phone did not contact Twitter at all. (It did, however, proudly proclaim that the new chat was end to end encrypted.)

For those wondering whether the Wireshark test controls for various things:

  • The username with whom a chat was started was never typed into the test system (the one that started the chat) prior to the packet capture.
  • The two accounts never had any sort of contact before, on any device. They also don’t follow each other. Until the chat was established, the other party did not even know my username, so they could not have triggered anything either.
  • The packet capture started before the username was typed into the search field on the test device and ended only after Keybase completely established the chat and claimed it was end to end encrypted.
  • Twitter seems to host all its services on its own IP range, and none of the IPs the test system talked to during chat establishment fell inside that range. If this assumption is false and the Keybase client uses endpoints outside of 104.244.40.0/21, please comment. I checked all IPs and all are implausible to be a front for Twitter (details on hacker news), but I would be interested to know if Twitter publishes tweets on Amazon Web Services’ Simple Storage Service or something.
  • It is deemed implausible for the mobile Keybase client to simply have downloaded all signature chains from all users that exist on Keybase and to have checked all their proofs prior to starting the packet capture. This is the only way I can think of how the third party hosted proof could have been verified prior to the packet capture.


Get this bounty!!!

#StackBounty: #key-exchange #end-to-end-encryption #blockchain #keybase How can I verify Keybase's end-to-end encryption between me…

Bounty: 50

The premise of end-to-end encryption (E2EE) is that the client is secure and trustworthy, your end devices is secure and trustworthy, but the network and server need not be trusted. You’ve read all the code in the client, or someone you trust has done so for you. But after loading the code onto your phone — installing the Keybase app — and starting a chat with your friend, you still need to verify that the server sent you the right encryption key. Since you can’t host your own server, it has to be the Keybase, Inc’s server that sends you the encryption key of your friend.

It’s pretty standard for E2EE software that the (client) code is open, the server sends you the encryption key, and you can check the encryption keys out of band. In Signal you check the safety number, in Wire you check the device fingerprints, and in Telegram you check the encryption key. If they match, you know (based on the open client code and the cryptography it uses) that there is no (wo)man in the middle.

How does this work with Keybase? Their documentation explains parts of it:

Alice and Bob share a symmetric encryption key, which they pass through the server by encrypting it to each of their devices’ public encryption keys.

Okay, so either we verify the symmetric key (identical on both phones), or we verify the public key (I should be able to display mine on my phone, and my friend will call up what their phone thinks my public key is, and that should match).

The weird thing is that there is no button to do either of this. The documentation doesn’t mention any and I can’t find it when looking around.

Further on, it explains the public keys are put into your signature chain:

All Keybase devices publish a crypto_box public key and a crypto_sign public key when they’re first provisioned. Those keys live in the user’s signature chain […] A chat symmetric encryption key is 32 random bytes. It’s shared by everyone in the chat, […] When a new device needs this shared key, another device that has it will encrypt it with the new device’s public crypto_box key and then upload it to the Keybase server.

So if I’m reading this right, when my friend opens a new chat with me, their client generates the shared secret, it will take the public key from the crypto_box inside my signature chain and encrypt the shared secret with that public key, and upload the result to Keybase’s server so that I can download and decrypt it, thereby establishing the shared secret and starting the chat.

… but where does that signature chain come from? This has to be fetched from Keybase servers, so since there is no way to display it, I have to trust the server to send me the right key. How does that make sense when they claim “all messages are secure, end-to-end encrypted”? The client also occasionally and briefly displays a banner above the chat saying “end-to-end encrypted”.

There is documentation about how to do the verification step by step, but aside from that the instructions are broken (there is no sigs field in root_desc, the result of root.json?hash=X), this is not something I can do on my phone. A malicious server could return the correct answers to my command line client while telling the mobile app that the signature chain contains an entirely different key (namely the one the malicious actor uses to perform the MitM).

When talking about it to others, they mention this blockchain thing as the reason why it’s secure without needing to verify anything yourself, but I can’t figure out how it works.

  1. Do Keybase chats require any kind of key to be manually verified for end-to-end encryption, or does the blockchain data (which the app could verify silently under the hood) somehow prevent us from having to compare fingerprints/keys/sigchains?
  2. If we do need to compare fingerprints/keys/sigchains, how can that be done in the Keybase app?

Update: A friend linked this GitHub issue, where it is basically said that the whole blockchain thing isn’t yet done by the app. Leaving in the middle whether (something like) SPV is a good solution, it is currently not implemented. That strikes out the first option if I’m not mistaken.

Since the app also seems not to allow fulfilling the second option (comparing keys), I guess this concludes that there is no E2EE currently implemented in Keybase? An attack is hard to pull off: even a malicious server (very ideal position) would have to MitM from the start, so they have to have prior knowledge of whom to target. But we do trust the server to be honest at least some of the time. Or am I still missing some way that makes this true end to end encryption?

Update 2: It was mentioned on hacker news that the app should check third party proofs by itself. This is not exactly what end to end encryption means since it still relies on third parties, but nevertheless, having to own 2 or more companies’ servers before being able to MitM someone’s keys (which are additionally TOFU’d) should give quite some confidence.
However, when checking in Wireshark whether it actually does this (ask the Twitter API for the proof string and verify the signature with the the public key it received from Keybase), Keybase on my phone did not contact Twitter at all. (It did, however, proudly proclaim that the new chat was end to end encrypted.)

For those wondering whether the Wireshark test controls for various things:

  • The username with whom a chat was started was never typed into the test system (the one that started the chat) prior to the packet capture.
  • The two accounts never had any sort of contact before, on any device. They also don’t follow each other. Until the chat was established, the other party did not even know my username, so they could not have triggered anything either.
  • The packet capture started before the username was typed into the search field on the test device and ended only after Keybase completely established the chat and claimed it was end to end encrypted.
  • Twitter seems to host all its services on its own IP range, and none of the IPs the test system talked to during chat establishment fell inside that range. If this assumption is false and the Keybase client uses endpoints outside of 104.244.40.0/21, please comment. I checked all IPs and all are implausible to be a front for Twitter (details on hacker news), but I would be interested to know if Twitter publishes tweets on Amazon Web Services’ Simple Storage Service or something.
  • It is deemed implausible for the mobile Keybase client to simply have downloaded all signature chains from all users that exist on Keybase and to have checked all their proofs prior to starting the packet capture. This is the only way I can think of how the third party hosted proof could have been verified prior to the packet capture.


Get this bounty!!!

#StackBounty: #key-exchange #end-to-end-encryption #blockchain #keybase How can I verify Keybase's end-to-end encryption between me…

Bounty: 50

The premise of end-to-end encryption (E2EE) is that the client is secure and trustworthy, your end devices is secure and trustworthy, but the network and server need not be trusted. You’ve read all the code in the client, or someone you trust has done so for you. But after loading the code onto your phone — installing the Keybase app — and starting a chat with your friend, you still need to verify that the server sent you the right encryption key. Since you can’t host your own server, it has to be the Keybase, Inc’s server that sends you the encryption key of your friend.

It’s pretty standard for E2EE software that the (client) code is open, the server sends you the encryption key, and you can check the encryption keys out of band. In Signal you check the safety number, in Wire you check the device fingerprints, and in Telegram you check the encryption key. If they match, you know (based on the open client code and the cryptography it uses) that there is no (wo)man in the middle.

How does this work with Keybase? Their documentation explains parts of it:

Alice and Bob share a symmetric encryption key, which they pass through the server by encrypting it to each of their devices’ public encryption keys.

Okay, so either we verify the symmetric key (identical on both phones), or we verify the public key (I should be able to display mine on my phone, and my friend will call up what their phone thinks my public key is, and that should match).

The weird thing is that there is no button to do either of this. The documentation doesn’t mention any and I can’t find it when looking around.

Further on, it explains the public keys are put into your signature chain:

All Keybase devices publish a crypto_box public key and a crypto_sign public key when they’re first provisioned. Those keys live in the user’s signature chain […] A chat symmetric encryption key is 32 random bytes. It’s shared by everyone in the chat, […] When a new device needs this shared key, another device that has it will encrypt it with the new device’s public crypto_box key and then upload it to the Keybase server.

So if I’m reading this right, when my friend opens a new chat with me, their client generates the shared secret, it will take the public key from the crypto_box inside my signature chain and encrypt the shared secret with that public key, and upload the result to Keybase’s server so that I can download and decrypt it, thereby establishing the shared secret and starting the chat.

… but where does that signature chain come from? This has to be fetched from Keybase servers, so since there is no way to display it, I have to trust the server to send me the right key. How does that make sense when they claim “all messages are secure, end-to-end encrypted”? The client also occasionally and briefly displays a banner above the chat saying “end-to-end encrypted”.

There is documentation about how to do the verification step by step, but aside from that the instructions are broken (there is no sigs field in root_desc, the result of root.json?hash=X), this is not something I can do on my phone. A malicious server could return the correct answers to my command line client while telling the mobile app that the signature chain contains an entirely different key (namely the one the malicious actor uses to perform the MitM).

When talking about it to others, they mention this blockchain thing as the reason why it’s secure without needing to verify anything yourself, but I can’t figure out how it works.

  1. Do Keybase chats require any kind of key to be manually verified for end-to-end encryption, or does the blockchain data (which the app could verify silently under the hood) somehow prevent us from having to compare fingerprints/keys/sigchains?
  2. If we do need to compare fingerprints/keys/sigchains, how can that be done in the Keybase app?

Update: A friend linked this GitHub issue, where it is basically said that the whole blockchain thing isn’t yet done by the app. Leaving in the middle whether (something like) SPV is a good solution, it is currently not implemented. That strikes out the first option if I’m not mistaken.

Since the app also seems not to allow fulfilling the second option (comparing keys), I guess this concludes that there is no E2EE currently implemented in Keybase? An attack is hard to pull off: even a malicious server (very ideal position) would have to MitM from the start, so they have to have prior knowledge of whom to target. But we do trust the server to be honest at least some of the time. Or am I still missing some way that makes this true end to end encryption?

Update 2: It was mentioned on hacker news that the app should check third party proofs by itself. This is not exactly what end to end encryption means since it still relies on third parties, but nevertheless, having to own 2 or more companies’ servers before being able to MitM someone’s keys (which are additionally TOFU’d) should give quite some confidence.
However, when checking in Wireshark whether it actually does this (ask the Twitter API for the proof string and verify the signature with the the public key it received from Keybase), Keybase on my phone did not contact Twitter at all. (It did, however, proudly proclaim that the new chat was end to end encrypted.)

For those wondering whether the Wireshark test controls for various things:

  • The username with whom a chat was started was never typed into the test system (the one that started the chat) prior to the packet capture.
  • The two accounts never had any sort of contact before, on any device. They also don’t follow each other. Until the chat was established, the other party did not even know my username, so they could not have triggered anything either.
  • The packet capture started before the username was typed into the search field on the test device and ended only after Keybase completely established the chat and claimed it was end to end encrypted.
  • Twitter seems to host all its services on its own IP range, and none of the IPs the test system talked to during chat establishment fell inside that range. If this assumption is false and the Keybase client uses endpoints outside of 104.244.40.0/21, please comment. I checked all IPs and all are implausible to be a front for Twitter (details on hacker news), but I would be interested to know if Twitter publishes tweets on Amazon Web Services’ Simple Storage Service or something.
  • It is deemed implausible for the mobile Keybase client to simply have downloaded all signature chains from all users that exist on Keybase and to have checked all their proofs prior to starting the packet capture. This is the only way I can think of how the third party hosted proof could have been verified prior to the packet capture.


Get this bounty!!!