4 ms·

Maybe I'm naieve, but I think perhaps the problems with OpenSSL had come to light a little bit sooner if all dangerous code had clearly been marked 'unsafe'. I

by tinco 12y ago

Maybe I'm naieve, but I think perhaps the problems with OpenSSL had come to light a little bit sooner if all dangerous code had clearly been marked 'unsafe'. I would not expect any unsafe calls in a crypto library. It would defeat almost the whole purpose of implementing a crypto library in Haskell. It would be like implementing a web application in Ruby, and then using static type annotations everywhere using some eDSL. BTW, I don't think this article is meant to argue the advantages of Haskell, it is meant to describe a solution to a problem in Haskell.

CJefferson 12y ago
Now wandering further off-topic I realise! I think everyone who had ever looked at the code for OpenSSL (including myself) knew it was an unsafe time bomb waiting to go off, it's just no-one could be bothered to replace it, or do the basic complete re-engineer the BSD folks are now doing.
- gcr 12y ago
  It's easy to point fingers, but I think any library which handles strong crypto over network sockets is going to be pretty hairy. I bet that if I showed you a random 100 lines from the "LibreSSL" code and a random 100 lines from the "OpenSSL" code, stripping out all identifiers, that you wouldn't be able to tell which library is which by judging quality alone. That sounds like a fun experiment, actually. Someone should go and make that.
  - gerardvanvooren 12y ago
    > I bet that if I showed you a random 100 lines from the "LibreSSL" code and a random 100 lines from the "OpenSSL" code, stripping out all identifiers, that you wouldn't be able to tell which library is which by judging quality alone. That's quite easy. In 100 lines of OpenSSL you have 6 nested #ifdefs and the code is unreadable formatted.
4ad 12y ago
You definitely need to use unsafe Haskell code in order to implement most cryptographic primitives in a way making them resistant to timing attacks. You simply have to be able to write constant-time primitives, and this is not possible in Haskell without unsafe. The point of this blog post is how to enforce memory safety at compile time even when using unsafe.
- chpatrick 12y ago
  Why isn't it possible? The safe versions just do bounds checking, which still seems constant time to me. If you mean that somewhere in the stack something must do pointer math you're right, but that's a given whatever you do crypto or not.
  - 4ad 12y ago
    My response was to tinco in respect to the use of unsafe in general when writing crypto code, it wasn't about the particular use of unsafe in this article... (which isn't about crypto anyway, so how could it be?).
    - chpatrick 12y ago
      I'm disagreeing with this statement: "You definitely need to use unsafe Haskell code in order to implement most cryptographic primitives in a way making them resistant to timing attacks." Safe indexing is constant time too, unless you're out of bounds and you have to process the exception, in which case your program is wrong anyway.
      - tinco 12y ago
        I think you're right, you could even write a monad/language extension in which it's only possible to perform constant time operations effectively ruling out a class of vulnerabilities.
        chpatrick 12y ago
protomyth 12y ago
> Maybe I'm naieve, but I think perhaps the problems with OpenSSL had come to light a little bit sooner if all dangerous code had clearly been marked 'unsafe'. After listening to Bob Beck's talk[1], I think people did know how unsafe that code was but no one wanted to take a shot at fixing it until it all went bad. At 2:12 into the video (the Jon Snow slide), he explains why nobody looked (or admitted they looked)[2]. Code can be so bad in any language to discourage people from even attempting to figure out how it works. 1) https://www.youtube.com/watch?v=GnBbhXBDmwU https://www.youtube.com/watch?v=GnBbhXBDmwU 2) quotes "Why did WE not look" & "It is your parents talking about how you got made horrible"
- leoc 12y ago
  You can deeplink YouTube videos thusly: https://www.youtube.com/watch?v=GnBbhXBDmwU#t=130 https://www.youtube.com/watch?v=GnBbhXBDmwU#t=130

by tinco 12y ago

CJefferson 12y ago

Now wandering further off-topic I realise! I think everyone who had ever looked at the code for OpenSSL (including myself) knew it was an unsafe time bomb waiting to go off, it's just no-one could be bothered to replace it, or do the basic complete re-engineer the BSD folks are now doing.

gcr 12y ago
It's easy to point fingers, but I think any library which handles strong crypto over network sockets is going to be pretty hairy. I bet that if I showed you a random 100 lines from the "LibreSSL" code and a random 100 lines from the "OpenSSL" code, stripping out all identifiers, that you wouldn't be able to tell which library is which by judging quality alone. That sounds like a fun experiment, actually. Someone should go and make that.
- gerardvanvooren 12y ago
  > I bet that if I showed you a random 100 lines from the "LibreSSL" code and a random 100 lines from the "OpenSSL" code, stripping out all identifiers, that you wouldn't be able to tell which library is which by judging quality alone. That's quite easy. In 100 lines of OpenSSL you have 6 nested #ifdefs and the code is unreadable formatted.

4ad 12y ago

You definitely need to use unsafe Haskell code in order to implement most cryptographic primitives in a way making them resistant to timing attacks. You simply have to be able to write constant-time primitives, and this is not possible in Haskell without unsafe. The point of this blog post is how to enforce memory safety at compile time even when using unsafe.

chpatrick 12y ago
Why isn't it possible? The safe versions just do bounds checking, which still seems constant time to me. If you mean that somewhere in the stack something must do pointer math you're right, but that's a given whatever you do crypto or not.
- 4ad 12y ago
  My response was to tinco in respect to the use of unsafe in general when writing crypto code, it wasn't about the particular use of unsafe in this article... (which isn't about crypto anyway, so how could it be?).
  - chpatrick 12y ago
    I'm disagreeing with this statement: "You definitely need to use unsafe Haskell code in order to implement most cryptographic primitives in a way making them resistant to timing attacks." Safe indexing is constant time too, unless you're out of bounds and you have to process the exception, in which case your program is wrong anyway.
    - tinco 12y ago
      I think you're right, you could even write a monad/language extension in which it's only possible to perform constant time operations effectively ruling out a class of vulnerabilities.
      - chpatrick 12y ago

protomyth 12y ago

> Maybe I'm naieve, but I think perhaps the problems with OpenSSL had come to light a little bit sooner if all dangerous code had clearly been marked 'unsafe'. After listening to Bob Beck's talk[1], I think people did know how unsafe that code was but no one wanted to take a shot at fixing it until it all went bad. At 2:12 into the video (the Jon Snow slide), he explains why nobody looked (or admitted they looked)[2]. Code can be so bad in any language to discourage people from even attempting to figure out how it works. 1) https://www.youtube.com/watch?v=GnBbhXBDmwU https://www.youtube.com/watch?v=GnBbhXBDmwU 2) quotes "Why did WE not look" & "It is your parents talking about how you got made horrible"

leoc 12y ago
You can deeplink YouTube videos thusly: https://www.youtube.com/watch?v=GnBbhXBDmwU#t=130 https://www.youtube.com/watch?v=GnBbhXBDmwU#t=130