aarnott

3 ms·

1.
by aarnott 13y ago
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
2.
by aarnott 13y ago
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.
3.
by 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.
4.
by aarnott 13y ago
But if you have signed the message, MACs are redundant, so why have them?
5.
by aarnott 13y ago
What would you use instead of RSA for public keys?
6.
by aarnott 13y ago
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 forwa
7.
by 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
8.
by 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 w
9.
by aarnott 13y ago
> .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?
10.
by aarnott 13y ago
> 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
11.
by aarnott 13y ago
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