Live data from Hacker News

How I implemented my own crypto

loup-vaillant.fr

161–170 of 409 posts

Re: How I implemented my own crypto

#161
post #23

The v1.0.0 was published the day a bug was fixed and yet the first sentence of this post is "Monocypher is ready for production". Sure, OpenSSL has bugfixes on regular basis as well, but I believe that further fragmenting the crypto ecosystem with a new library and little commercial support to properly back it and pay for security audits is risky.

> The v1.0.0 was published the day a bug was fixed and yet the first sentence of this post is "Monocypher is ready for production".

You have to consider the nature of the bug, as well as the fix. The bug was an Undefined Behaviour that had no effect on the binaries I could generate. The fix was 10 characters. Running the automated test suite took longer than fixing the bug.

If there were reasons to delay 1.0, this bug was not it.

> I believe that further fragmenting the crypto ecosystem with a new library and little commercial support to properly back it and pay for security audits is risky.

I agree fragmentation is a problem. I just couldn't satisfy myself with existing alternatives. As for support, I designed Monocypher specifically to need very little of it. Ideally, the only notable changes from now on will be about the manual and the test suite.

Re: How I implemented my own crypto

#162
post #143
post #135

Earlier quoted context omitted.

> That he only used unsigned types is irrelevant If he had used a signed type, it would have got sign extended and the result would have been different.

We can agree on that. But now I am completely lost as to what your original point was...

I admit I am as well :D

Re: How I implemented my own crypto

#163
It's interesting that Frama-C was mentioned. I have been playing with it the last few months and would love to hear exactly how it was used. I've read through a lot of the documentation but haven't found many examples of it being used

Re: How I implemented my own crypto

#164
post #152
post #75

I am terrified that I do not consider myself competent enough to write a crypto library, and yet there isn't a single mention - in this article, nor at the time of writing the comments here on Hacker News - of many of the pitfalls I know to avoid when undertaking such an endeavour. There is even a list of "you have to do A, B, C, and that's about it" that is missing some major - well known, even! - items. I know "don…

You can do crypto as a side-hobby and safely put it into production. Of course, you can also do it wrong, but it is with little work possible to do it correctly. Normally I wouldn't speak against what you said because the critique is only very minor, but I heard this too often. Your warning is too strong. People should try their own crypto and with little care it is not unsafer. Maybe giving a list of do's for that w…

> Of course, you can also do it wrong, but it is with little work possible to do it correctly.

GCHQ loves people who think this.

Have a look at some of the game console cryptography. These are companies with strong financial incentive to get it right. They're large well funded multinational organisations. They still get it wrong.

Re: How I implemented my own crypto

#165
post #70
post #27

First let me say that I've followed your work a bit and I'm really impressed with the library. I'm currently planning on rolling my own crypto as well and your library is on my list of the things to look at. One question: > I was shifting a uint8_t, 24 bits to the left. I failed to realise that integer promotion means this unsigned byte would be converted to a signed integer, and overflow if the byte exceeded 127. Th…

The problem happens if you do uint64_t = uint8_t uint8_t u8 = 255; uint64_t u64 = u8 prints "ffffffffff000000". If you instead do uint64_t u64 = (uint64_t) u8 or uint64_t u64 = (uint32_t) u8 It prints "00000000ff000000" as most people expect. (I think the second example with (uint32_t) will only work if "int" is at most 32 bits, but I might be wrong).

for anyone who wants to run that themselves:

  #include 
  #include 

  int main(){

    uint8_t start = -1;
    printf("%x\n", start); // prints 0xff
    uint64_t result = start 

Re: How I implemented my own crypto

#166
post #77

Earlier quoted context omitted.

I understand the issue, but not the explanation. Your example is different, this is because you're doing an addition. I can see how this could be a problem if you want to do a rotation (a > 60) and hence why you should use a ^ instead of a + here (example: https://github.com/gvanas/KeccakCodePackage/blob/master/SnP/... )

6.5.7.3 of the C99 standard specifies that each operand of a bit shift first undergoes integer promotion.

yesh! Alright I see the issue. This `int` then gets sign extended to a 64-bit register.

Re: How I implemented my own crypto

#167
post #141
post #84

Earlier quoted context omitted.

Unfortunately the architectural details of the machine will leak through to the program you are writing, and you will need to twist your code in order to get correct behaviour and fast execution. Case in point is the recent article posted on HN about the platform specific details of getTimeMilliseconds() in Java.

Could you link that article? I searched and couldn't find it on hN.

I believe the article was http://pzemtsov.github.io/2017/07/23/the-slow-currenttimemil... Although I couldn't easily find it in my history or on HN. I had to resort to the Googles.

Re: How I implemented my own crypto

#168
post #123
post #20

Earlier quoted context omitted.

Those are two separate arguments. Of course there should be competition in crypto libraries. However the " don't roll your own " advice is to prevent people who don't have sufficient experience, education nor resources to write their own library that can compete - effectively leaving their systems vulnerable. The thing about the " don't roll your own " advice is it's aimed at people who don't competently know what th…

How do you expect people to become competent if you constantly tell them to not do something? All that will happen is that people who don't listen to warnings will write crypto libraries and everyone will be forced to use them because nobody else wrote one. The fact that there was no independent implementation of Argon2 that found there was a bug in the reference implementation shows that the " don't roll your own "…

Again I feel the need to reiterate that the rule only needs to apply to those it needs explaining to. Ie nobody who is smart enough to roll their library would not do so for a production system without it having undergone rigorous testing first. Sure we might write hobby projects (I've written my own encryption ciphers for fun) but that's very different from actually using said cipher on live and/or business critical systems.

Simply put, the rule is there to remind people that rolling your own crypto libraries is dangerous. It's not meant to be taken literally to the daft extremes that yourself and a few others on here have. It's just meant to stop those lacking common sense from leaving themselves vulnerable.

Re: How I implemented my own crypto

#169
post #75

I am terrified that I do not consider myself competent enough to write a crypto library, and yet there isn't a single mention - in this article, nor at the time of writing the comments here on Hacker News - of many of the pitfalls I know to avoid when undertaking such an endeavour. There is even a list of "you have to do A, B, C, and that's about it" that is missing some major - well known, even! - items. I know "don…

I apologize if that sounds dismissive (it's not intended to) but your post is not more than the usual vague FUD. Take a look at so-called 'professional' cryptographers and their libraries, and you'll find that practically all of their code had severe bugs. Professionals make errors like everyone else, 'professional' just means you're being paid for it. You will have a hard time finding a professional and widely used…

So I have two points for you:

> Take a look at so-called 'professional' cryptographers and their libraries, and you'll find that practically all of their code had severe bugs. Professionals make errors like everyone else, 'professional' just means you're being paid for it. You will have a hard time finding a professional and widely used crypto library that wasn't essentially compromised in one of its functions at one time or another. Not only that, professionals from the closed-source department have a long history of coming up with compromised or bogus, sometimes even ridiculous cryptographic algorithms and implementations. Two typical examples: CMEA cell phone encryption, and the Crypto AG backdoor debacle.

This doesn't diminish the claim that the modal individual should not attempt to "roll their own crypto." You're pointing out that professionals make mistakes, but of course they do - that indicates nothing about the propensity for amateurs to make mistakes.

> It requires about the same level of skill as e.g. implementing a production-ready low-level network protocol or a file system.

I have never implemented a low level network protocol or a file system (although at least the former sounds like a fun project) - so I cannot claim you're wrong here. However, I will point out that a network protocol is not designed to be error-proof in an intentionally antagonistic environment, which is a difficulty unique to cryptographic software. There are incentives involved in breaking crypto code that do not present themselves in other areas of software development, even if the programming difficulty itself is not entirely dissimilar.

> Last but not least, many popular and widely used crypto libraries started as a side hobby. For example, libtomcrypt started that way. In fact, many widely respected cryptographers started as hobbyists. For example, Bruce Schneier. Of course, the ones who are widely accepted as peers are also those who are in the 'hire me as a consultant, not the other guy' business, and they will naturally advise everyone to not roll their own crypto but to rely on their expertise...

They can start as side hobbies, but they are not going to remain that way for any meaningful amount of time if they are to be widely deployed and safe. You can only choose two out of those three.

More importantly, there is no cabal of cryptographers spreading FUD to line their own pockets with consulting fees. The cryptography consulting industry is very small compared to the actual security consulting industry. In the application security consulting industry I do believe there are firms that try to secure business this way, but that industry is much larger (and has firms which try to misrepresent cryptographic competency). I have had significant interactions with engineers at Riscure and NCC Crypto, which is a sizable portion of all the "real" cryptanalytic consulting work that occurs (at least in the United States) - they never struck me as being the sort to suggest what you're saying. That leaves Rambus/CR and a select few other firms doing real crypto consulting, which leads me to believe the industry is, on the whole, very legitimate.

Re: How I implemented my own crypto

#170
post #152

Earlier quoted context omitted.

You can do crypto as a side-hobby and safely put it into production. Of course, you can also do it wrong, but it is with little work possible to do it correctly. Normally I wouldn't speak against what you said because the critique is only very minor, but I heard this too often. Your warning is too strong. People should try their own crypto and with little care it is not unsafer. Maybe giving a list of do's for that w…

Sorry, but this is not good advice. Widely-used crypto implementations have had the benefit of years of analysis by dozens of high-expertise stakeholders who have a lot to lose should the crypto fail. Even that isn't always enough to catch all weaknesses and vulnerabilities. This cowboy-programming attitude being extended to security is no small part of why we are so vulnerable as a society to attacks on our computer…

You are wrongly assuming I say to throw away the work of others. I never said so.
Post reply on HN