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

How I implemented my own crypto

loup-vaillant.fr

Post reply on HN
Print view View original

331–340 of 409 posts

Re: How I implemented my own crypto

#331

Post by tptacek »

lisper wrote: post #329
tptacek wrote: post #325

Earlier quoted context omitted.

The "flying community" does not have the attitude that any random person should take the stick on a 737. Like the cryptography community, the flying community encourages newcomers to learn and get certified. This is a genuinely weird argument you're trying to make.

As a member of both communities I can tell you that I perceive a genuine difference in attitudes. The crypto community says, "Don't write your own crypto." The aviation community says something more analogous to, "Absolutely, write your own crypto! Just don't use the results of your first effort for anything mission-critical until it has been checked out by someone who knows what they are doing. And oh by the way, he…

Sure! Now replace flying planes with building your own planes.

Re: How I implemented my own crypto

#332

Post by tptacek »

kelnos wrote: post #326
Kalium wrote: post #315

Earlier quoted context omitted.

https://www.google.com/search?client=ubuntu&channel=fs&q=+%2... I submit that "carry-propagation bug" is easily looked up. You're asking for people to provide footnotes and extra information so that you can learn what they're talking about when they delve into jargon. I get it. It makes it so much easier to follow along. Then you can learn! Two points come to mind. First, the bit of jargon you've picked on is in fact…

I clicked your link, and the results weren't useful. They were mostly links to reports about fixes for carry-propagation bugs in various pieces of software (which did not explain what a carry-propagation bug is). Ironically, the fourth result was a link to a different HN discussion about someone trying to figure out what a carry-propagation bug is, and failing to find any good resources through Google. (Although, to…

It's not especially easy! That's what worries me about laypeople writing crypto libraries. If you know to look, you stand a reasonable chance of learning enough about error oracle side channels to avoid writing something that recapitulates Bleichenbacher's RSA attack. But even if you remember someone telling you to look out for carry propagation bugs, I'm not sure you have a good chance of figuring how how to test for (or exploit) a carry propagation bug. And there are other bugs like this.

Re: How I implemented my own crypto

#333

Post by dahart »

idlewords wrote: post #317
dahart wrote: post #312

Earlier quoted context omitted.

I agree crypto is actually hard. But there are lots of domains where details matter and small errors have big consequences. Vehicles, medicine, and manufacturing are all places where errors have killed people. Obviously severity depends on the situation, but generally speaking I'd rather my encryption get broken than die. Software defects in the Therac-25 radiation therapy machine killed several people [1]. Software…

I agree too! The point I'm trying to make is that even in critical software, where people's lives are in the balance, there can be minor errors that don't bring down the entire edifice. Whereas in crypto code, there seems to be only one kind of error possible.

I see a few kinds of intermediate crypto errors possible. You can weaken the crypto without breaking it, you can leak metadata, you can screw up protocols without compromising the algorithm, etc..

But yes in some sense you're completely right, perhaps just because the aim of a crypto algorithm is so narrow? The number of things you can do right with a pair of encrypt/decrypt functions is so limited that the number of things you can do wrong is also pretty small.

There's certainly a lot more than can go wrong with "drive a car" than with "encrypt this message".

Re: How I implemented my own crypto

#334

Post by Kalium »

davidw wrote: post #297
tptacek wrote: post #295

Earlier quoted context omitted.

If someone posted a message on HN about doing DIY appendectomies with Arduino-controlled robots and I pointed out that you need to go to med school to do surgeries, you would not in fact be harping on me for not having explained why.

I think it's perfectly normal to be curious about a field and want to know more without necessarily wanting to charge off and do it yourself.

You're right! That's perfectly normal and extremely common.

People are skittish about this in the realm of cryptography because the costs of getting it wrong can be very high. Further, programmers have a culture where experimenting by writing something yourself is perfectly reasonable and extremely common.

When these two meet in the context of crypto, I know just enough to get worried that someone's going to get overconfident from a primer and do something they believe to be very clever. History has a nasty tendency to validate fear this as well-intentioned clever people do things that they believe are good enough.

Re: How I implemented my own crypto

#335

Post by lisper »

tptacek wrote: post #331
lisper wrote: post #329

Earlier quoted context omitted.

As a member of both communities I can tell you that I perceive a genuine difference in attitudes. The crypto community says, "Don't write your own crypto." The aviation community says something more analogous to, "Absolutely, write your own crypto! Just don't use the results of your first effort for anything mission-critical until it has been checked out by someone who knows what they are doing. And oh by the way, he…

Sure! Now replace flying planes with building your own planes .

Huh? Did you not read the last sentence?

"In fact, the aviation community literally encourages people to build their own airplanes!"

https://www.google.com/search?client=safari&rls=en&q=build+y...

http://www.kitplanes.com/homebuilders-portal/firsttimebuilde...

Re: How I implemented my own crypto

#336

Post by fapjacks »

lisper wrote: post #330
elsjaako wrote: post #322

Earlier quoted context omitted.

Isn't this the point of the usual advice, "don't write your own crypto"? There are a million gotchas, and most of these you've just gotta know.

Yes, and this is kind of the point I'm trying to make. "Don't write your own crypto" is the wrong message IMHO. The message should be something more like, "Absolutely, write your own crypto, because that's the best way to learn, and here's a pointer to how to get started. Just don't use the results of your early efforts for anything mission critical, and if you want to know why, read this..." And, taking my own advic…

I have the strongest instinct that "Don't write your own crypto" is one of the few successful barrier-to-entry phrases in the same spirit as something like "Surfing sucks, don't try it".

Re: How I implemented my own crypto

#337

Post by willtim »

moosingin3space wrote: post #274
willtim wrote: post #25

Earlier quoted context omitted.

OCaml was used recently by the MirageOS folks to implement a better TLS than OpenSSL.

TLS != crypto. TLS is actually very well-suited for a higher-level language like Rust or OCaml, especially due to how state machine patterns can be expressed safely in those languages. Crypto, on the other hand, often relies on low-level intrinsics to get good performance and cache timing attack resistance.

TLS depends on crypto and the mirage team implemented it using OCaml. It supports low-level intrinsics for timing attack resistance. See: https://github.com/mirleft/ocaml-nocrypto

Re: How I implemented my own crypto

#338

Post by [deleted] »

lisper wrote: post #328
Kalium wrote: post #315

Earlier quoted context omitted.

https://www.google.com/search?client=ubuntu&channel=fs&q=+%2... I submit that "carry-propagation bug" is easily looked up. You're asking for people to provide footnotes and extra information so that you can learn what they're talking about when they delve into jargon. I get it. It makes it so much easier to follow along. Then you can learn! Two points come to mind. First, the bit of jargon you've picked on is in fact…

> I submit that "carry-propagation bug" is easily looked up. Well, obviously anything is easily looked up. The problem is that in this case the results aren't very helpful if you don't already know what it is. I even said this in my OP: " if you go search for "carry propagation bug" you will find lots of examples of carry propagation bugs being found and fixed, but no explanation of what one is."

[deleted]

Re: How I implemented my own crypto

#339

Post by int_19h »

raverbashing wrote: post #136
int_19h wrote: post #100

Earlier quoted context omitted.

> We've had to wait till C99 to get stdint.h, clearly portability is kind of an afterthought in C. C provided "at least N bits" guarantees for its integer types since its first standard (for the curious: char at least 8-bit, short at least 16-bit, long at least 32-bit; in C99, long long as least 64-bit). This is the most that you can get if you want absolute portability, because there are architectures out there wher…

Good explanation And to me this shows clearly that we shouldn't be using C then. If an arch can't address an 8 bit sized element there are two choices for what happens if you write: char *a = "test"; char x = a[1]; Either char takes 32bytes or the a[1] read will shuffle the bytes to get a 32bit value whose least significant digits are a[1] And saying that int32_t are "conditionally supported" is really proof we're ma…

On SHARC, char is 32-bit (so is short, int and long).

I don't see why it's a problem, though? As noted earlier, C accommodates that. Sure, there's a lot of C code that's written with the assumption that chars are always 8-bit, because they usually are. But it's definitely possible to write portable C code that doesn't make such assumptions.

int32_t is required to be supported on any architecture on which one of the standard types is exactly 32-bit. Since long is required to be at least 32-bit, and any 8-bit microcontroller would have to support long, it would be 32-bit as well, and so it'd have int32_t (typedef'd to long). The only case where you wouldn't have it is either if the architecture has a word larger than 32 bits as its smallest addressable unit, or if it has non-8-bit bytes.

In practice, this is really not an issue, because you don't have to target the absolute most portable subset of C. The reason for making those features conditionally supported is so that when they are there, they behave the same. So you can say "my code runs on any platform that supports ISO C, and has int32_t in stdint.h". Not only that, but you can enforce it at compile-time with clear error messages, e.g.:

    #ifndef INT32_MAX
    #error "int32_t requrired"
    #endif
Your code is still portable. It's less portable than the mandatory subset of C, but it's a strictly defined part of the spec that behaves the same on all platforms that support that part.

Re: How I implemented my own crypto

#340

Post by wiz21c »

TylerE wrote: post #302
lisper wrote: post #298

Earlier quoted context omitted.

> Carry propagation is one pixel in the 4K movie that is safe crypto implementation This is exactly the sort of thing I'm talking about. This is semantically equivalent to, "If you don't already know this, then you are too stupid, and my time is too valuable, for me to do anything beyond pointing out that you are stupid and my time is valuable." That may be true, but it's not helpful. > There are programs that teach…

With all due respect, some things should only be done by trained professionals. Crypto is one of them. Flying a commercial airliner is another.

I sure hope that all that you have learned has been learned from trained professionals...

Like making love, like walking, like being kind to others, like cooking, etc.

Post reply on HN