IronPigeon - Decentralized communication protocol for sending secure messages | Hacker News Reader

IronPigeon - Decentralized communication protocol for sending secure messages

github.com

121 pointsobilgic41 comments

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?

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!

.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.

> .NET's crypto libraries are good enough

Many of them call directly into the operating system anyway.

> but this seems to be configured in "1990s crypto mode"

What do you mean?

RSA, PKCS #1 v1.5 signatures, unauthenticated CBC.

That's AES, a government standard. And in fact the only option for some platforms (like Windows Phone 8 for example) if you want to rely on what's built into the OS.

What would you use instead of RSA for public keys?

Yeah but this shit still scares me: http://www.reddit.com/r/netsec/comments/1km0of/injecting_arb...

Lol at the reference to "1990s crypto mode." The standards are always funky.

You can inject into processes on Unix OS's too. Again, not sure what that has to do with this project.

That may be true, but if injection and backdooring a chat service is as easy as just using some simple code thats already floating in the blackmarket. How long do you think before that project would be backdoored?

The answer is before the thing is even used there would be some people including some code to attack it. Especially because chat clients are good for botnets. Hackers think they are yummy.

There's plenty of code floating around the white market for injecting code into running UNIX processes. It's a documented feature of the dynamic linker, and has been for decades.

Injecting code into a process running in the same security domain is not an attack, regardless of platform.

This is pretty silly.

Tell that to the well made botnets developed for teamviewer, msnchat, and the hackers targeting skype as well.

It's just another way to mask botnet traffic.

All messages are both signed and encrypted. I can't remember the order, but when it was determined some research was done about the various attacks to mitigate the problem you allude to. I _believe_ we encrypt first, then sign, so that any tampering is detected before decryption begins.

Using MEF is optional for the apps that use this library. But I don't see that it opens up new attack vectors. Feel free to enlighten me if you know more on this.

And I agree with the other replies to your message about .NET being inherently insecure. It's trivially easy to inject code into any process, native or managed. If you have code executing on the machine (not some VM or runtime), from a security perspective you probably can own it if you like. So IMO the interesting attack vectors have to come in over the network.

Signatures and message authentication codes aren't the same thing.

But if you have signed the message, MACs are redundant, so why have them?

> It's a little hard to follow the code.

Docs are coming soon. A formal spec and some illustrations should help clear this up. The project is very young and developed on "spare time", and weren't prepared for this to be publicized so much yet. Thanks for your patience as we catch up with demand for documentation.

> the crypto specifics appear to be platform-specific

Yes, the implementation is written as a .NET "portable library" so that it can run on any platform, but that means crypto isn't directly available. So there are individual projects for each platform that provides the crypto for the core library via an extensibility point.

> the insecure random number generator for IVs. Why?

The threat models and crypto documentation I've seen never suggests that IVs have to be produced by cryptographically strong RNGs. The keys do, but IVs just have to be random. The fact that IVs may be predictable don't compromise security -- but if they are repeatedly used that can compromise it. And whether it's crypto or not, any RNG would seem equally likely to produce a duplicate IV (very unlikely).

> 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?

Most of the public key exchanges are not considered part of the protocol, since different applications may exchange keys with different mechanisms and yet still be interoperable with other apps. In the existing implementations, the key exchange happens via a web service that acts as a lookup that gives public keys in exchange for an email address. Since this implies the client must trust the web service, which I'm not thrilled about, we're evaluating alternatives. NFC to directly exchange keys between two smartphones seems attractive from several points, but of course has cons as well.

> How screwed am I if I lose my RSA key to an attacker? Are all my old messages now decryptable?

Someone who obtains your RSA key also needs another symmetric secret to download your inbox (out of scope for the spec, but in the sample network service) to find out where your messages are online. Your messages may no longer be online (as the sample clients delete them from the cloud as soon as they are downloaded). So damage seems to be fairly contained. In the future, expiration and renewal policies can help mitigate this further.

If decryption or signature verification fails, the message is thrown out. An app using IronPigeon _may_ choose to inform the user of the failure, but the samples don't do this, and I wouldn't recommend it myself.

If IVs are predictable and inputs are influenced by attackers (ie, attackers get a degree of chosen plaintext), attackers can mount a byte-at-a-time decryption attack a la ECB mode; this is what the BEAST attack did. I don't know that this is plausible with Random(), but why even make people wonder? What was the logic behind dropping to an insecure RNG for a random crypto parameter?

It sounds like you're also building a system from scratch that doesn't have forward secrecy. Why don't the parties arrange for temporary secrets and use the public keys solely to ensure that they've securely agreed on them? The system you've built is less secure than OTR, which is widely implemented and already has libraries that work on WinAPI.

Crypto RNGs take a toll on the system as they can drain the entropy pool. There are attacks that involve draining entropy pools, which can be mitigated to some extend by only using crypto RNG when necessary.

Why do you say there is no forward secrecy? Every single message is encrypted with a new key, so the only viewers are the folks the message is explicitly sent to. You say this is less secure than OTR, but I fail to see why. I'd say the reverse is true.

Also, in IronPigeon attackers don't get any degree of chosen plaintext or ciphertext except for keys that are one-time use only, so the attack is moot.

None of the crypto models I've ever read about assume that IV is anything more than nonce quality. In fact in many implementations the IV is given as the first block of a ciphertext (not encrypted itself), so it's hardly treated as a secret, therefore any predictability is harmless.

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.

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 ). 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/, though it still doesn't sound like a perfect solution yet.

This sound interesting if people adapt it more: 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.

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.

https://twitter.com/pr0f_srs/status/202819821254082560 Within 1 google away. . .?

When you say back-door, do you mean exploit? Those are very different things.

By your logic people shouldn't be using Linux, Windows or any other software because people have found exploitable bugs in them.

There has never been a backdoor in Pidgin. Instead Pidgin has a very healthy security community and they release several CVE's each year.

I would use Pidgin over Tox without a blink since Pidgin has been around the block longer (almost 10 years now) while Tox hasn't released a single Security advisory yet. So I'm sure there's a lot of "low hanging fruit" exploits waiting to be found in Tox.

These look useful wonder how good their implementation is:

http://sipdht.sourceforge.net/

http://www.tixati.com/ <-- Just the beginning description of it is great from what I can see.

Something i'd have to look into. . . :D

Well, I think what you proposed is better than Bitmessage. But to end user Bitmessage provides same benefits (+ a few backdraws). I have been thinking exactly what you have proposed. But based purely on DHT, with intermediate hops and message polling when retrieving data, without direct connections between clients. If you have read freenet's freemail implementation paper, that describes parts of the process. Because freenet is distributed encrypted key/value storage solution.

Basic feature of DHT is that data automatically expires after a while if not refreshed to group of nodes. This would allow more efficient routing that what Bitmessage does. That's one of the primary reasons why I don't like it. I also suspect that a key streams in bitmessage could become overloaded, because there's no way to loadbalance key streams.

> 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?

That's an issue I've looked at while developing BitWeav [1]. Basically you can either make it a requirement that nodes store content or get them to do it voluntarily.

In the former circumstance, Bitcoin basically makes it a requirement that blocks are stored in the blockchain for the functioning of the payment system (correct me if I'm wrong, but that's the gist of it).

So the other more feasible alternative is incentives. The main approach I took with BitWeav is severing the connection to the node if they don't store certain messages for the benefit of the network. To explain briefly, BitWeav is a scalable decentralised and P2P microblogging system, and when nodes send a message in reply to another message, they MUST store and serve it if required, for the purposes of improving the quality of service. If they don't, they will be 'booted' from the network, a fair exchange. It is also worth noting that there are always people who donate resources to the network selflessly.

To finish off with a quote that comes from the early days of the Bitcoin mailing list: "Yes, [we will not find a solution to political problems in cryptography,] but we can win a major battle in the arms race and gain a new territory of freedom for several years." — Satoshi Nakamoto. Cryptography is not the end-all solution to all our problems, but it is good for escalating the situation until people enact change. We should solve the problem at its root.

[1] - http://bitweav.org

RetroShare seems to be what you're looking for: http://retroshare.sourceforge.net/

It's the encrypted, decentralized/p2p, open-source communication suite (it also allows you to stay anonymous). You get:

- VoIP

- Chat (incl. group chat)

- Messaging

- Filesharing

- Forums, Channels

This kind of solution is called "darknet": https://en.wikipedia.org/wiki/Darknet_(file_sharing)

Darknet is silly and confusing name for technology. Even if it sounds so cool. I think that Friend to Friend (F2F) network is much more descriptive name for technology, if you don't want to sound so elitistic.

Retroshare kind of works like that, and it keeps the messages within your trusted network of friends. I think they have some articles about it here:

https://retroshareteam.wordpress.com/

Bitmessage is also similar but sends the message to everyone.

It's also been brought up before, but BitMessage [0] is trying to accomplish this using a similar design to Bitcoin, hence the name.

[0] http://bitmessage.org/

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.

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.

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.

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/ironpige...

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.

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.

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

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.

Reply on news.ycombinator.com