Re: [cryptography] Security Discussion: Password Based Key Derivation for Elliptic curve Diffie–Hellman key agreement
Thanks for all the comments so far! Is there a reason you did not consider using OTR? Or another of the many secure chat protocols? We did not want to use OTR, because we do not want to have forward secrecy and message deniability. Our idea is to built an encryption scheme that is completely transparent to the user, it should not appear different to him if he is chatting over an encrypted Facebook chat or not. This way we hope to make encryption easier, less of hassle and more mainstream. If we had session keys that expire after the conversation is over, the user wouldn't be able to read the messages later on (or on a different device) or send offline messages (all things possible with original Facebook Messenger). What safeguards do you have against a MITM attack? We were thinking to query the public key server over HTTPS and validate the certificate (either through a CA or hard coded in the plugin). Also, wouldn't you have to compromise the public key server (to deliver wrong pub keys to both parties) and the communication channel to Facebook (to intercept the message) at the same time? Therefore, we thought that only Facebook itself would have a realistic opportunity for MITM attacks (meaning the user would have to trust us, that we don't cooperate with them). We also thought about building a decentralized Web-of-Trust, but found it hard to establish a second secure channel (assuming that users don't necessarily engage in real life) without impacting usability. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Security Discussion: Password Based Key Derivation for Elliptic curve Diffie–Hellman key agreement
A MITM attack is more than just trusting your SSL cert or Facebook. How do we know *you* aren’t secretly intercepting our messages? Does your platform assume we have to trust *you*? On Dec 18, 2013, at 3:36 AM, SafeChat.IM i...@safechat.im wrote: Thanks for all the comments so far! Is there a reason you did not consider using OTR? Or another of the many secure chat protocols? We did not want to use OTR, because we do not want to have forward secrecy and message deniability. Our idea is to built an encryption scheme that is completely transparent to the user, it should not appear different to him if he is chatting over an encrypted Facebook chat or not. This way we hope to make encryption easier, less of hassle and more mainstream. If we had session keys that expire after the conversation is over, the user wouldn't be able to read the messages later on (or on a different device) or send offline messages (all things possible with original Facebook Messenger). What safeguards do you have against a MITM attack? We were thinking to query the public key server over HTTPS and validate the certificate (either through a CA or hard coded in the plugin). Also, wouldn't you have to compromise the public key server (to deliver wrong pub keys to both parties) and the communication channel to Facebook (to intercept the message) at the same time? Therefore, we thought that only Facebook itself would have a realistic opportunity for MITM attacks (meaning the user would have to trust us, that we don't cooperate with them). We also thought about building a decentralized Web-of-Trust, but found it hard to establish a second secure channel (assuming that users don't necessarily engage in real life) without impacting usability. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Security Discussion: Password Based Key Derivation for Elliptic curve Diffie–Hellman key agreement
The app/plugin will be open source, so you can see what we are doing. Messages will only be sent to the Facebook XMPP server. On Dec 18, 2013, at 4:24 PM, Jason Goldberg jgoldb...@oneid.com wrote: A MITM attack is more than just trusting your SSL cert or Facebook. How do we know *you* aren’t secretly intercepting our messages? Does your platform assume we have to trust *you*? On Dec 18, 2013, at 3:36 AM, SafeChat.IM i...@safechat.im wrote: Thanks for all the comments so far! Is there a reason you did not consider using OTR? Or another of the many secure chat protocols? We did not want to use OTR, because we do not want to have forward secrecy and message deniability. Our idea is to built an encryption scheme that is completely transparent to the user, it should not appear different to him if he is chatting over an encrypted Facebook chat or not. This way we hope to make encryption easier, less of hassle and more mainstream. If we had session keys that expire after the conversation is over, the user wouldn't be able to read the messages later on (or on a different device) or send offline messages (all things possible with original Facebook Messenger). What safeguards do you have against a MITM attack? We were thinking to query the public key server over HTTPS and validate the certificate (either through a CA or hard coded in the plugin). Also, wouldn't you have to compromise the public key server (to deliver wrong pub keys to both parties) and the communication channel to Facebook (to intercept the message) at the same time? Therefore, we thought that only Facebook itself would have a realistic opportunity for MITM attacks (meaning the user would have to trust us, that we don't cooperate with them). We also thought about building a decentralized Web-of-Trust, but found it hard to establish a second secure channel (assuming that users don't necessarily engage in real life) without impacting usability. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Security Discussion: Password Based Key Derivation for Elliptic curve Diffie–Hellman key agreement
Dear mailing list, A friend and me are working on a plugin that enables encryption on top of Facebook messaging. The idea is to encrypt messages before they leave the chat client, sending only the cipher to Facebook and decrypt the message on the receiver client, before it is displayed. The plugin automatically realizes which users have it installed and only encrypts these chats. Since the reliability of the cryptographic system is a crucial part of the design, I would to discuss the protocol here: First, we use PBKDF2 to derive a 256 bit data block from a passphrase the user chooses and a salt (the username). We advise the user to use a long and hard-to-guess passphrase. We use Parvez Anandam’s JavaScript implementation [1]. This data block serves as the private key for a secp256r1 elliptic curve. We cannot use a random private key, as we have to be able to generate the same private key on different devices of the user. Given this private key, and another user’s public key (exchange through a public key server), we calculate the shared key as defined in the Elliptic curve Diffie–Hellman (ECDH) key agreement protocol: Given Alice’s private key ‘a’ and the elliptic curve ‘G’ (defined by the secp256r1 parameters), Alice’s public key ‘A’ is defined as: A = a*G (Analogously for Bob: B = b*G) If Alice has her private key ‘a’ and Bob’s public key B, she can calculate the shared key S S = a*B = a*b*G Bob has his private key ‘b’ and Alice’s public key ‘A’ to derive the same secret: S’ = b*A = b*a*G = a*b*G = S Tom Wu’s library [2] is used to implement all ECDH related stuff. The shared secret together with a random salt is used as a starting block to generate a 256bit AES key, which eventually encrypts the message. The cipher and the random salt are sent to the other person, so that he can reproduce the symmetric key. We use the Gibberish library for that purpose [3]. Our process is also depicted here: http://goo.gl/ghzWSl Do you see a problem with that approach? I am looking forward to comments and concerns. Thanks! Felix [1] http://anandam.com/pbkdf2/ [2] http://www-cs-students.stanford.edu/~tjw/jsbn/ [3] https://github.com/mdp/gibberish-aes___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Security Discussion: Password Based Key Derivation for Elliptic curve Diffie–Hellman key agreement
In very general terms, you cannot hope to achieve confidentiality without authenticity. Your key exchange does not offer authenticity. I would suggest instead having the user's keys be signing keys, and do straightforward signed ephemeral ECDH. This should also gain you forward secrecy. Unfortunately this will introduce a data dependency in your protocol, which may cause an unacceptable extra round trip. With that assumed fixed, your protocol relies entirely on a third party (the 'public key server') for authenticity of the key exchange. If the overall aim is to avoid having to trust a third party (Facebook) to keep messages secret, adding more third parties to the problem doesn't seem a great solution. From your own point of view, you should consider this a major legal and technical liability. From your users point of view, why should they place their trust in you? So, establishing the true authenticity keys of the recipient and sender is absolutely vital. Consider a different way of bootstapping everything, perhaps by having users distribute and confirm their public keys in person, or by multiple entirely separate channels. The symmetric step also offers no ciphertext authenticity, so you will have a CBC padding oracle or timing attack here, allowing an intermediary to recover messages. Is there a reason you did not consider using OTR? Or another of the many secure chat protocols? Cheers, Joseph Birr-Pixton On 17 December 2013 18:01, SafeChat.IM i...@safechat.im wrote: Dear mailing list, A friend and me are working on a plugin that enables encryption on top of Facebook messaging. The idea is to encrypt messages before they leave the chat client, sending only the cipher to Facebook and decrypt the message on the receiver client, before it is displayed. The plugin automatically realizes which users have it installed and only encrypts these chats. Since the reliability of the cryptographic system is a crucial part of the design, I would to discuss the protocol here: First, we use PBKDF2 to derive a 256 bit data block from a passphrase the user chooses and a salt (the username). We advise the user to use a long and hard-to-guess passphrase. We use Parvez Anandam’s JavaScript implementation [1]. This data block serves as the private key for a secp256r1 elliptic curve. We cannot use a random private key, as we have to be able to generate the same private key on different devices of the user. Given this private key, and another user’s public key (exchange through a public key server), we calculate the shared key as defined in the Elliptic curve Diffie–Hellman (ECDH) key agreement protocol: Given Alice’s private key ‘a’ and the elliptic curve ‘G’ (defined by the secp256r1 parameters), Alice’s public key ‘A’ is defined as: A = a*G (Analogously for Bob: B = b*G) If Alice has her private key ‘a’ and Bob’s public key B, she can calculate the shared key S S = a*B = a*b*G Bob has his private key ‘b’ and Alice’s public key ‘A’ to derive the same secret: S’ = b*A = b*a*G = a*b*G = S Tom Wu’s library [2] is used to implement all ECDH related stuff. The shared secret together with a random salt is used as a starting block to generate a 256bit AES key, which eventually encrypts the message. The cipher and the random salt are sent to the other person, so that he can reproduce the symmetric key. We use the Gibberish library for that purpose [3]. Our process is also depicted here: http://goo.gl/ghzWSl Do you see a problem with that approach? I am looking forward to comments and concerns. Thanks! Felix [1] http://anandam.com/pbkdf2/ [2] http://www-cs-students.stanford.edu/~tjw/jsbn/ [3] https://github.com/mdp/gibberish-aes ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Security Discussion: Password Based Key Derivation for Elliptic curve Diffie–Hellman key agreement
What safeguards do you have against a MITM attack? On Dec 17, 2013, at 12:01 PM, SafeChat.IM i...@safechat.immailto:i...@safechat.im wrote: Dear mailing list, A friend and me are working on a plugin that enables encryption on top of Facebook messaging. The idea is to encrypt messages before they leave the chat client, sending only the cipher to Facebook and decrypt the message on the receiver client, before it is displayed. The plugin automatically realizes which users have it installed and only encrypts these chats. Since the reliability of the cryptographic system is a crucial part of the design, I would to discuss the protocol here: First, we use PBKDF2 to derive a 256 bit data block from a passphrase the user chooses and a salt (the username). We advise the user to use a long and hard-to-guess passphrase. We use Parvez Anandam’s JavaScript implementation [1]. This data block serves as the private key for a secp256r1 elliptic curve. We cannot use a random private key, as we have to be able to generate the same private key on different devices of the user. Given this private key, and another user’s public key (exchange through a public key server), we calculate the shared key as defined in the Elliptic curve Diffie–Hellman (ECDH) key agreement protocol: Given Alice’s private key ‘a’ and the elliptic curve ‘G’ (defined by the secp256r1 parameters), Alice’s public key ‘A’ is defined as: A = a*G (Analogously for Bob: B = b*G) If Alice has her private key ‘a’ and Bob’s public key B, she can calculate the shared key S S = a*B = a*b*G Bob has his private key ‘b’ and Alice’s public key ‘A’ to derive the same secret: S’ = b*A = b*a*G = a*b*G = S Tom Wu’s library [2] is used to implement all ECDH related stuff. The shared secret together with a random salt is used as a starting block to generate a 256bit AES key, which eventually encrypts the message. The cipher and the random salt are sent to the other person, so that he can reproduce the symmetric key. We use the Gibberish library for that purpose [3]. Our process is also depicted here: http://goo.gl/ghzWSl Do you see a problem with that approach? I am looking forward to comments and concerns. Thanks! Felix [1] http://anandam.com/pbkdf2/ [2] http://www-cs-students.stanford.edu/~tjw/jsbn/ [3] https://github.com/mdp/gibberish-aes ___ cryptography mailing list cryptography@randombit.netmailto:cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Security Discussion: Password Based Key Derivation for Elliptic curve Diffie–Hellman key agreement
On Dec 17, 2013, at 10:01 , SafeChat.IM i...@safechat.im wrote: A friend and me are working on a plugin that enables encryption on top of Facebook messaging. The idea is to encrypt messages before they leave the chat client, sending only the cipher to Facebook and decrypt the message on the receiver client, before it is displayed. The plugin automatically realizes which users have it installed and only encrypts these chats. I briefly thought about doing this a few years ago. Actually, I was even more interested in leveraging it for the key distribution and distributed identity management aspect. But then, when I looked at the various app interfaces and designs, I ran away from Facebook very quickly. It was absolutely impossible to do anything on Facebook that is secure in the face of other apps. Unless they've done a very un-Facebook-like revision, you cannot achieve meaningful security. Greg. smime.p7s Description: S/MIME cryptographic signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Security Discussion: Password Based Key Derivation for Elliptic curve Diffie–Hellman key agreement
Sounds just like the Bitcoin blockchain to me. Or maybe the fork Namecoin. - Sent from my phone Den 18 dec 2013 02:20 skrev James A. Donald jam...@echeque.com: On 2013-12-18 04:38, Joseph Birr-Pixton wrote: In very general terms, you cannot hope to achieve confidentiality without authenticity. Your key exchange does not offer authenticity. I would suggest instead having the user's keys be signing keys, and do straightforward signed ephemeral ECDH. This should also gain you forward secrecy. Unfortunately this will introduce a data dependency in your protocol, which may cause an unacceptable extra round trip. With that assumed fixed, your protocol relies entirely on a third party (the 'public key server') for authenticity of the key exchange. If the overall aim is to avoid having to trust a third party (Facebook) to keep messages secret, adding more third parties to the problem doesn't seem a great solution. Google solution: Implement a protocol such that the key server cannot tell the owner of the name on thing, and someone else trying to contact the owner of the name a different thing, and cannot rewrite the past. Bittorrent serves immutable files globally, such that the file must be the same for all. Need a bittorent like algorithm for serving slowly mutable tree structures. Viewed as a history, it is a grow only data structure with an ever increasing immutable past. The history, however, is kind of like a git history, representing a fully mutable but slowly changing present. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Security Discussion: Password Based Key Derivation for Elliptic curve Diffie–Hellman key agreement
On 17/12/13 21:38 PM, Joseph Birr-Pixton wrote: In very general terms, you cannot hope to achieve confidentiality without authenticity. Actually, you can achieve confidentiality, you just can't prove it in cryptographic terms. The original poster should not be dissuaded by claims that no MITM solution makes it worthless. The same trick was done to SSL and look at where that got us: mass surveillance because it is too hard to deploy in 100% of circumstances. Also, look at Greg Rose's post. The bar is very very low because anyone who wants to MITM a facebook user can also slip in many other approaches. Doing just enough to force the attacker to go active -- by *any means* -- is a really good tool. In the alternate, add some MITM protection as a second generation. There are some easy, sorta maybe methods like sharing the number over another channel (phone, SMS, skype). You can much better appreciate what works for your design once it is up and running, and once your users start telling you what they can do. This you cannot achieve at all if you design in some cold-war PKI design from the get-go. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
