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