91–100 of 136 posts
Earlier quoted context omitted.
I don't keep up on everything, but I thought Dual_EC_DRBG was used by nobody else for any real world crypto. Did these guys look over the Wiki page and decide it would be fun to be the first?
They aren't using it, but Dual_EC_DRBG is fairly widely used actually. There was a false meme denying that this was the case, but RSA and others proved that wrong.
Earlier quoted context omitted.
Open source doesn't imply trustworthiness and it's a very dangerous assumption to make. Any open source system can be screwed with in a variety of ways. The simplest and most effective option is to publish both the source and the binaries, but built latter from the an altered source. This will work in a vast majority of cases, because a lot of people make this ridiculous assumption that publishing the source automati…
> This will work in a vast majority of cases, because a lot of people make this ridiculous assumption that publishing the source automatically implies that the guy is good, open and trustworthy all over. And won't bother verifying the binaries. Probably worth linking to Ken Thompson's Reflections on Trusting Trust paper, which illustrates exactly what you're saying with a hypothetical (or not) C compiler backdoor. ht…
"I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well installed microcode bug will be almost impossible to detect."
Presumably to would be possible to introduce a bug into every CPU manufactured, that even the manufacturer is unaware of.
Is there a decent “Crypto Not For Dummies But For Reasonably Competent Programmers Who Have Thus Far Taken It For Granted But Want To Get Up To Speed Fairly Quickly On Concepts And Implementation” text?
this is a reminder that prizes or cash for breaking crypto products is a silly PR stunt. mega did the same thing, ended up paying out some money, then their product is "secure" by the same sort of argument. same deal with cryptocat and several other cryptoturds. i do find it amusing to hear moxie ranting about how much better textsecure is when the license on it is such shit. can't argue with the fact that it's open…
The license on the TextSecure app is GPLv3. What would you like to do with TextSecure that this license prohibits?
I have been saying this a couple of times in similar threads, but I think Threema [1] deserves a little more attention. Complete end-to-end encryption using NaCl. The interface they created is simple and gets the point across. Also, they're actually saying "don't trust us!", which ironically makes me trust them. [1]: https://threema.ch/en/
Their protocol doesn't provide any forward secrecy. It uses the PGP protocol model, which is increasingly being seen as an architectural dead end (particularly given the recently revealed ciphertext recording capabilities of NSA): https://whispersystems.org/blog/asynchronous-security/
Do you have additional information?
Earlier quoted context omitted.
It's really not even enough to open source their server software because you would still have to trust that they ran that open source software unmodified on their machines.
Yep, that's also absolutely true. You'd have no idea if their servers were actually running the code they published. Moxie's TextSecure on the other hand does full end-to-end encryption, with no work done by any server. Same with OTR and similar message encryption plugins. It baffles me why people are sticking to the "everything on the server" route for applications that focus on user privacy and security in this day…
Earlier quoted context omitted.
Their protocol doesn't provide any forward secrecy. It uses the PGP protocol model, which is increasingly being seen as an architectural dead end (particularly given the recently revealed ciphertext recording capabilities of NSA): https://whispersystems.org/blog/asynchronous-security/
That's not what their FAQ says: https://threema.ch/en/faq.html (scroll down, they specifically claim to provide forward secrecy) Do you have additional information?
> "Yes, Threema provides forward secrecy on the network connection. Client and server negotiate temporary random keys, which are only stored in RAM and replaced every time the app restarts (and at least once every 7 days). An attacker who has captured the network traffic will not be able to decrypt it even if he finds out the long-term secret key of the client or the server after the fact."
My reading is that they have an end-to-end secure protocol that does not provide forward secrecy, which happens to be routed through a server which uses HTTPS w/ an ephemeral cipher suite for the network transport, with a TLS session ticket that they rotate the key on every 7 days.
We should ask them for more details, but if true, that would be pretty deceptive of them.
For reference, here's a list (probably incomplete? (EDIT: and feel free to add!)) of ways this protocol is broken: 1. There's no authentication at any point. The whole thing is trivially MITM-able. 2. The RNG is Dual_EC_DRBG, which is backdoored. 3. The RSA public key is small enough that an attacker of sufficient means could break it. 4. The RSA plaintext is unpadded. Proper padding is critical for safe RSA encrypti…
They are using SHA-1, which is indeed broken, not as broken as MD5 and its predecessors yet, but still less than a birthday attack.
> The message key is defined as the 128 lower-order bits of the SHA1 of the message body (including session, message ID, etc.).
A reduced SHA-1 cut down from 160 to 128 bits is not collision resistant. I'm not sure what implication this has for this protocol but if strong collision resistance is required this may be a point of weakness.
Earlier quoted context omitted.
That's not what their FAQ says: https://threema.ch/en/faq.html (scroll down, they specifically claim to provide forward secrecy) Do you have additional information?
Yikes, that actually looks like potentially deceptive marketing to me. > "Yes, Threema provides forward secrecy on the network connection. Client and server negotiate temporary random keys, which are only stored in RAM and replaced every time the app restarts (and at least once every 7 days). An attacker who has captured the network traffic will not be able to decrypt it even if he finds out the long-term secret key…
If I'm understanding you correctly, and you're understanding them correctly, that is quite deceptive indeed.
Earlier quoted context omitted.
The license on the TextSecure app is GPLv3. What would you like to do with TextSecure that this license prohibits?
Integrate it and distribute it with non-open-source software. So, any commercial use whatsoever.