Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Crypto Challenge For The Telegram Developers

thoughtcrime.org

Post reply on HN
Print view View original

121–130 of 136 posts

Re: A Crypto Challenge For The Telegram Developers

#121

Post by anonymoushn »

paveldurov wrote: post #113
moxie wrote: post #112

Earlier quoted context omitted.

Does this mean that you were unable to recover Alice's message?

Alas, I am not a cryptographer and not even a member of the Telegram team. I'm just a guy who backs Telegram financially and proposed to start their contest. I described my motives behind it here https://news.ycombinator.com/item?id=6938622 As for your contest, I will make sure the Telegram team will have a look at it once they are awake. As far as I understand, you designed it to be similar to Telegram's contest. Ho…

You can generate your own messages according to the scheme he gave (even using the same public key from Bob if you like), but they will not be aggregated into a public log.

Re: A Crypto Challenge For The Telegram Developers

#122

Post by tptacek »

lawnchair_larry wrote: post #84
danielweber wrote: post #83

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.

Dual EC was not particularly common. Here's a metric: name a couple of products that you or I use regularly that ever used it.

It's not as if you could design a system with Dual EC instead of HMAC DRBG and not know it; Dual EC requires bignum math. It is incredibly slow for a CSPRNG.

Re: A Crypto Challenge For The Telegram Developers

#123

Post by tveita »

tptacek wrote: post #122
lawnchair_larry wrote: post #84

Earlier quoted context omitted.

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.

Dual EC was not particularly common. Here's a metric: name a couple of products that you or I use regularly that ever used it. It's not as if you could design a system with Dual EC instead of HMAC DRBG and not know it; Dual EC requires bignum math. It is incredibly slow for a CSPRNG.

This is disingenuous. RSA used it as a default in a commercial crypto library, as you must know. End users won't generally be aware that it's being used in a product, but that doesn't mean it isn't out there.

It is unlikely that most developers changed the default unless it was having a noticeable impact on performance, which wouldn't be the case if it was just used for key generation.

http://www.wired.com/threatlevel/2013/09/rsa-advisory-nsa-al...

> In its advisory, RSA said that all versions of RSA BSAFE Toolkits, including all versions of Crypto-C ME, Micro Edition Suite, Crypto-J, Cert-J, SSL-J, Crypto-C, Cert-C, SSL-C were affected.

> In addition, all versions of RSA Data Protection Manager (DPM) server and clients were affected as well.

> “Every product that we as RSA make, if it has a crypto function, we may or may not ourselves have decided to use this algorithm,” said Sam Curry, chief technical officer for RSA Security. “So we’re also going to go through and make sure that we ourselves follow our own advice and aren’t using this algorithm.”

Here's someone who has dug up a decent amount of real-world products:

http://security.stackexchange.com/questions/43164/which-prod...

Re: A Crypto Challenge For The Telegram Developers

#124

Post by femto »

meowface wrote: post #118
femto wrote: post #92

Earlier quoted context omitted.

For me, the following lines also stood out: "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…

Even scarier, researchers have shown that there are ways of backdooring CPUs via transistor doping so that even if the manufacturer suspects a backdoor, it may still be very difficult for them to find it: http://www.techrepublic.com/blog/it-security/researchers-cre... Full paper: http://people.umass.edu/gbecker/BeckerChes13.pdf

Interesting. The "doping" attack seems to be aimed specifically at random number generating circuits. Presumably such attacks could be definitively detected by using the RNG to generate a long sequence and checking that the distribution of probabilities is as expected [1]? Is my understanding correct?

[1] http://www.johndcook.com/Beautiful_Testing_ch10.pdf

Re: A Crypto Challenge For The Telegram Developers

#126

Post by belorn »

nardi wrote: post #115
nardi wrote: post #94

Earlier quoted context omitted.

Integrate it and distribute it with non-open-source software. So, any commercial use whatsoever.

I understand the down votes, and kind of expected it. But this is the actual practical reality, guys. Large software companies avoid GPLv3 like the plague. If you want your software to be used widely, then you need to use BSD/MIT/Apache/etc.

Since when is Google and Oracle not defined as "large software companies"?

Companies that avoid GPLv3 (but not GPLv2) do so because of either the patent clause, or the DRM clause. That is, they either want to by pass the license with legal restrictions, or hardware restrictions.

This is only relevant for external products, and says nothing about internal use. the actual practical reality, dead seriously, is that gplv3 is used by most large software companies that exist in the world. It would surprise me if Microsoft did not have some debian machines laying around somewhere hosting some website.

Re: A Crypto Challenge For The Telegram Developers

#127

Post by xnyhps »

SomeCallMeTim wrote: post #109
xnyhps wrote: post #43

Earlier quoted context omitted.

Yeah, when I started actually trying to back it up, I noticed I was probably a factor 5 off. Namely, if you look at the keylength.com values for asymmetric key sizes, 768 in 2009 ago should come close to the difficulty of 896 today. The RSA 768 challenge was broken in 2009 ( http://eprint.iacr.org/2010/006 ), which cost them "the equivalent of almost 2000 years of computing on a single core 2.2GHz AMD Opteron". Renti…

>Amazon EC2 I'm not sure how they compare in practice, but it might be worth calculating how many hours an Amazon G2 instance would take, using their high-end graphics cards as CUDA processors. I think the cost per performance ratio is much lower, and that could change the equation in the other direction.

I really don't know how well the required operations execute on a GPU. I've only skimmed the RSA 768 paper to find that line.

Re: A Crypto Challenge For The Telegram Developers

#128

Post by ash »

paveldurov wrote: post #113
moxie wrote: post #112

Earlier quoted context omitted.

Does this mean that you were unable to recover Alice's message?

Alas, I am not a cryptographer and not even a member of the Telegram team. I'm just a guy who backs Telegram financially and proposed to start their contest. I described my motives behind it here https://news.ycombinator.com/item?id=6938622 As for your contest, I will make sure the Telegram team will have a look at it once they are awake. As far as I understand, you designed it to be similar to Telegram's contest. Ho…

Have you taken part in Telegram contest design?

> How large is the prize?

I think the "prize" is obvious. Breaking this "unbreakable" 896bit-RSA + no auth + no signature + MD2 + XOR is a necessary condition for the Telegram contest to be taken seriously.

Re: A Crypto Challenge For The Telegram Developers

#129

Post by acqq »

danielweber wrote: post #83
sdevlin wrote: post #32

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…

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?

Dual_EC_DRBG is used:

http://security.stackexchange.com/questions/43164/which-prod...

> Since we know the RSA BSAFE library uses Dual_EC_DRBG (...) by default, I would guess that this would be the main vector.

> As for the use of BSAFE, I can easily find (hint: use your favourite search engine to search for the terms "This product includes" "RSA BSAFE") implementations, oddly skewed towards imaging and gaming devices: surprisingly many printer/copier/fax devices use BSAFE, though for unknown purposes. Including Ricoh, Minolta, Océ/Canon, Brother, Fuji/Xerox, Epson ... Your Playstation (PDF), PSP, or your Nintendo DS wifi (PDF) Software from Adobe, Hitachi, Oracle and HP Some Nokia phones(PDF)

Re: A Crypto Challenge For The Telegram Developers

#130

Post by blahbl4hblahtoo »

moxie wrote: post #37
m-app wrote: post #13

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/

Hello, Mr. Moxie...I was just wondering if I understood you about what you said here...is the PGP model being considered a dead end because of the "store it forever in Utah" model of the NSA? Excuse my ignorance, but, don't all public key systems actually end up using a symmetric key to crypt a message and that key doesn't get re-used? How is that different from PFS? (If this is too grade school, a "RTFM" is cool...)
Post reply on HN