6 ms·

IronPigeon - Decentralized communication protocol for sending secure messages

121 points by obilgic 13y ago

blackhole 13y ago
This is a fantastic idea that would be really cool if it worked... but is there a cryptographer in the room that can verify that it actually does work? There's a dime-a-dozen "secure" communication methods that aren't really secure.
- switch33 13y ago
  The encryption doesn't seem very clearly throughly analyzed in the description of it. According to the github description: "To send a message via IronPigeon, a pair of endpoints must exist. Endpoints have both public and private components, containing the public and private cryptographic key pairs respectively. When party A shares its public endpoint with party B, party B can send party A messages. When two parties each create their own endpoints and exchange their public components, the two parties may communicate securely." The crypto practice of using both public/private keys is good. It makes sure that the communication is based on a trust scheme where one person must trust the other however there may be ways to fake such things depending on how they implement the crypto. The messages should be put through AES 256byte encryption or similar so there is no reading the message while it's in transit till it is recieved by the right address. Instead it's left up to the user how they encrypt their messages. However I don't think I would trust it that much primarily the main thing that this is trying to sell is that it is like doing e-mail messages that are decentralized in circulation, have an expiration time limit, and the messages require the reciever to set up an endpoint to recieve messages. It's a good start, but it needs better explanation about some of the encryption that is used.
  - aarnott 13y ago
    Yes, we need to describe it better. The messages are all symmetrically encrypted using a unique key for each message. The symmetric key is then asymmetrically encrypted using each recipient's public key. We're using strong crypto and we're using it as it is implemented by the platform, so we're not re-inventing the wheel.
tptacek 13y ago
Is this running RSA PKCS #1 v1.5 signatures on every message, and CBC-encrypting without a MAC? It's a little hard to follow the code (the crypto specifics appear to be platform-specific). Also, the WP8 code uses a CSPRNG for keys (good) but the insecure random number generator for IVs. Why? Where do my peer's pubkeys come from? How are they stored? How are they validated? Do I have one per peer, or one single RSA key I send to all my peers? How screwed am I if I lose my RSA key to an attacker? Are all my old messages now decryptable? Exactly what happens when an RSA verification fails? What about when decryption fails?
- switch33 13y ago
  If it's CBC without a MAC that's a problem. The fact that this relies on MEF means that MEF should also be secure. Also if the code is based off of .NET I'm not so sure i'd trust it. Hackers are targeting .NET a lot more now. Theres been a lot of reversing going on for it. But alas .NET can be somewhat secure if you use a decent obfuscation method for the compiled binaries. Also someone who also likes encryption yay!
  - tptacek 13y ago
    .NET's crypto libraries are good enough, but this seems to be configured in "1990s crypto mode". I have no idea why reversing matters here. It's an open source project.
    - switch33 13y ago
      Yeah but this shit still scares me: http://www.reddit.com/r/netsec/comments/1km0of/injecting_arbritary_code_into_net_assemblies/ http://www.reddit.com/r/netsec/comments/1km0of/injecting_arb... Lol at the reference to "1990s crypto mode." The standards are always funky.
      - tptacek 13y ago
        You can inject into processes on Unix OS's too. Again, not sure what that has to do with this project.
crazygringo 13y ago
So how long will it be before someone comes up with a distributed decentralized solution for encrypted "e-mail", much like a kind of BitTorrent+DHT+Tor for communications? With some kind of intermediate "routing" where a few clients keep a message "online" until the intended recipient finally downloads it, or some kind of timeout expires? But also supporting G-Chat-like functionality whenever both computers are online at the same time? I mean, forget about interoperability with SMTP or existing e-mail addresses... just make it crypto-only, with client software just like BitTorrent programs like uTorrent, Transmission, Vuze, etc.
- switch33 13y ago
  There are a few people who have made decent DHT implementations similar to even what Kademilla's protocols are open sourced on github( https://github.com/isaaczafuta/pydht https://github.com/isaaczafuta/pydht ). The real deal is people are ok with using just p2p clients with some chat features. It's much easier to be secure on p2p. Tor is the opposite of privacy as far as i'm concerned as well. Tor mail was being targeted a lot recently. I'm looking more forward to the newer skype called Tox: http://tox.im/ http://tox.im/, though it still doesn't sound like a perfect solution yet. This sound interesting if people adapt it more: http://jinroh.github.io/kadoh/ http://jinroh.github.io/kadoh/ Pidgin and Off the Record have been backdoored way too much over the years. It is about time for a new chat implementation that works.
  - wskinner 13y ago
    Can you give more details about the OTR backdoor(s) you are referring to? I've never heard of this and google doesn't return much either.
    - switch33 13y ago
      https://twitter.com/pr0f_srs/status/202819821254082560 https://twitter.com/pr0f_srs/status/202819821254082560 Within 1 google away. . .?
      - 13y ago
jared314 13y ago
There was some criticism when this showed up on reddit[1] about the lack of a detailed protocol description and punting on the key distribution. It sounds like a good project publicized to early. [1] http://www.reddit.com/r/programming/comments/1km3dn/ironpigeon_a_decentralized_communication_protocol/ http://www.reddit.com/r/programming/comments/1km3dn/ironpige...
- switch33 13y ago
  A bit what we said plus some more interesting feedback. Even more problems; you must trust a "cloud-like" service for the keys exchanged. Bleh, this isn't going to get used anytime soon.
  - aarnott 13y ago
    Yes, the project owners (including myself) are concerned about the trusted cloud service model as well. That's just a sample, and we'd like to replace it with a trustless model. NFC is looking good for key exchange between folks who are close enough to shake hands. I don't think the key signing parties that OpenPGP relies on will work for the typical end user, which is what IronPigeon is targeting.
hepek 13y ago
isn't bimessage a much better thought-out project with similar goals.
- aarnott 13y ago
  I'd say they have different goals and different scaling capabilities. BitMessage may be a good way to facilitate public key exchange for IronPigeon though.

121 points by obilgic 13y ago

This is a fantastic idea that would be really cool if it worked... but is there a cryptographer in the room that can verify that it actually does work? There's a dime-a-dozen "secure" communication methods that aren't really secure.

switch33 13y ago
The encryption doesn't seem very clearly throughly analyzed in the description of it. According to the github description: "To send a message via IronPigeon, a pair of endpoints must exist. Endpoints have both public and private components, containing the public and private cryptographic key pairs respectively. When party A shares its public endpoint with party B, party B can send party A messages. When two parties each create their own endpoints and exchange their public components, the two parties may communicate securely." The crypto practice of using both public/private keys is good. It makes sure that the communication is based on a trust scheme where one person must trust the other however there may be ways to fake such things depending on how they implement the crypto. The messages should be put through AES 256byte encryption or similar so there is no reading the message while it's in transit till it is recieved by the right address. Instead it's left up to the user how they encrypt their messages. However I don't think I would trust it that much primarily the main thing that this is trying to sell is that it is like doing e-mail messages that are decentralized in circulation, have an expiration time limit, and the messages require the reciever to set up an endpoint to recieve messages. It's a good start, but it needs better explanation about some of the encryption that is used.
- aarnott 13y ago
  Yes, we need to describe it better. The messages are all symmetrically encrypted using a unique key for each message. The symmetric key is then asymmetrically encrypted using each recipient's public key. We're using strong crypto and we're using it as it is implemented by the platform, so we're not re-inventing the wheel.

tptacek 13y ago

Is this running RSA PKCS #1 v1.5 signatures on every message, and CBC-encrypting without a MAC? It's a little hard to follow the code (the crypto specifics appear to be platform-specific). Also, the WP8 code uses a CSPRNG for keys (good) but the insecure random number generator for IVs. Why? Where do my peer's pubkeys come from? How are they stored? How are they validated? Do I have one per peer, or one single RSA key I send to all my peers? How screwed am I if I lose my RSA key to an attacker? Are all my old messages now decryptable? Exactly what happens when an RSA verification fails? What about when decryption fails?

switch33 13y ago
If it's CBC without a MAC that's a problem. The fact that this relies on MEF means that MEF should also be secure. Also if the code is based off of .NET I'm not so sure i'd trust it. Hackers are targeting .NET a lot more now. Theres been a lot of reversing going on for it. But alas .NET can be somewhat secure if you use a decent obfuscation method for the compiled binaries. Also someone who also likes encryption yay!
- tptacek 13y ago
  .NET's crypto libraries are good enough, but this seems to be configured in "1990s crypto mode". I have no idea why reversing matters here. It's an open source project.
  - switch33 13y ago
    Yeah but this shit still scares me: http://www.reddit.com/r/netsec/comments/1km0of/injecting_arbritary_code_into_net_assemblies/ http://www.reddit.com/r/netsec/comments/1km0of/injecting_arb... Lol at the reference to "1990s crypto mode." The standards are always funky.
    - tptacek 13y ago
      You can inject into processes on Unix OS's too. Again, not sure what that has to do with this project.

crazygringo 13y ago

So how long will it be before someone comes up with a distributed decentralized solution for encrypted "e-mail", much like a kind of BitTorrent+DHT+Tor for communications? With some kind of intermediate "routing" where a few clients keep a message "online" until the intended recipient finally downloads it, or some kind of timeout expires? But also supporting G-Chat-like functionality whenever both computers are online at the same time? I mean, forget about interoperability with SMTP or existing e-mail addresses... just make it crypto-only, with client software just like BitTorrent programs like uTorrent, Transmission, Vuze, etc.

switch33 13y ago
There are a few people who have made decent DHT implementations similar to even what Kademilla's protocols are open sourced on github( https://github.com/isaaczafuta/pydht https://github.com/isaaczafuta/pydht ). The real deal is people are ok with using just p2p clients with some chat features. It's much easier to be secure on p2p. Tor is the opposite of privacy as far as i'm concerned as well. Tor mail was being targeted a lot recently. I'm looking more forward to the newer skype called Tox: http://tox.im/ http://tox.im/, though it still doesn't sound like a perfect solution yet. This sound interesting if people adapt it more: http://jinroh.github.io/kadoh/ http://jinroh.github.io/kadoh/ Pidgin and Off the Record have been backdoored way too much over the years. It is about time for a new chat implementation that works.
- wskinner 13y ago
  Can you give more details about the OTR backdoor(s) you are referring to? I've never heard of this and google doesn't return much either.
  - switch33 13y ago
    https://twitter.com/pr0f_srs/status/202819821254082560 https://twitter.com/pr0f_srs/status/202819821254082560 Within 1 google away. . .?
    - 13y ago

jared314 13y ago

There was some criticism when this showed up on reddit[1] about the lack of a detailed protocol description and punting on the key distribution. It sounds like a good project publicized to early. [1] http://www.reddit.com/r/programming/comments/1km3dn/ironpigeon_a_decentralized_communication_protocol/ http://www.reddit.com/r/programming/comments/1km3dn/ironpige...

switch33 13y ago
A bit what we said plus some more interesting feedback. Even more problems; you must trust a "cloud-like" service for the keys exchanged. Bleh, this isn't going to get used anytime soon.
- aarnott 13y ago
  Yes, the project owners (including myself) are concerned about the trusted cloud service model as well. That's just a sample, and we'd like to replace it with a trustless model. NFC is looking good for key exchange between folks who are close enough to shake hands. I don't think the key signing parties that OpenPGP relies on will work for the typical end user, which is what IronPigeon is targeting.

hepek 13y ago

isn't bimessage a much better thought-out project with similar goals.

aarnott 13y ago
I'd say they have different goals and different scaling capabilities. BitMessage may be a good way to facilitate public key exchange for IronPigeon though.