How I implemented my own crypto - loup-vaillant http://loup-vaillant.fr/articles/implemented-my-own-crypto <comment><AUTHOR> I would like to clarify:

The thing that I said was "table stakes" for implementing cryptography was _passing the algorithm test vectors_ , which this author's previous post claimed as a security feature.

If you're unfamiliar with the concept, a test vector is a series of strings and intermediate values used to ensure that your (say) OCB3 is the same as everyone else's OCB3.

Had he asked, I'd further claim that not having dumb C bugs is also table stakes for cryptography, since serious crypto vulnerabilities happen at a higher level of abstraction. The author grazes past (somewhat disconcertingly) one such class of bugs when he discusses carry propagation and limb scheduling in the context of Poly1305. Improper carry propagation is an example of the kind of security vulnerability for which there are no test vectors and no memory safety validation tools.

You just have to know what a carry propagation bug is, where to look for them (not Poly1305), and what the impact of one is.

Hopefully, the author of this library does.

<comment><USER2> > You just have to know what a carry propagation bug is

This is one of the things that drives me nuts about the crypto community. The natural response upon reading, "You just have to know X" if you don't already know is to go search for X. Well, 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. The thing that "you just have to know" is not so easy to find. The courteous thing to do when mentioning something that "you just have to know" but which is not easy to find is to provide a pointer or a short in-line explanation. When you don't do that you leave your reader with no choice but to publicly expose their ignorance of this purportedly crucial knowledge by asking, which I will now proceed to do as a public service: What the hell is a carry propagation bug? Where do you look for them? And what is their impact?

And while we're at it, what are "table stakes"?

<comment><AUTHOR> Give me a fucking break.

Sean, Marcin, and I spent the better part of a year _individually replying to tens of thousands of emails_ from people doing the Cryptopals challenges that we wrote and published for free. Do you know how much work that was? Here's a hint: it was a lot of work.

There are a lot of charges you can level at me to try to win a dumb message board argument, but the one where I want cryptography to be a secret priesthood known only to the anointed select is not one of them --- nor is the argument that I haven't taken the time to help make these kinds of cryptographic attacks easier for people to learn about.

Please immediately find one of those other arguments to substitute for this one, and, if you have it in you, take a moment to retract.

Thanks in advance.

<comment><USER2> I do sincerely apologize for taking my frustrations out on you, because you have indeed gone above and beyond the call to help make crypto accessible.

Nonetheless, I still stand by the substance of my comment: when you (not you specifically, but anyone) say, "You have to know X" you should check that doing a Google search for X yields some reasonable results, and if it doesn't, provide a hint on how to proceed.

<comment><USER3> > Nonetheless, I still stand by the substance of my comment: when you (not you > specifically, but anyone) say, "You have to know X" you should check that > doing a Google search for X yields some reasonable results, and if it > doesn't, provide a hint on how to proceed.

Do you actually believe you are personally entitled to demand special research tips from domain experts?

<comment><USER4> I don't think it's too much to ask for links to resources.

If it's a common enough remedy that needs linking, you could just write a dedicated blog post describing the recommended resources or whatever and just link to that.

Sometimes the hard part of researching things is knowing what to look for or where to look for it.

<comment><USER3> You can _ask_ for anything you want. But I wouldn't expect anyone to do work for you just because you demand it.

Give me $100 and I'll send you a link to some good crypto books.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> 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't roll your own crypto" comes across as dismissive or patronising. I'm not a huge fan of the phrasing. But as a first-order approximation, it is correct. If you want to roll your own crypto, that needs to be your _thing_. It's very unlikely you're going to be a fantastic full-stack web developer _and_ be able to do that. If it's really what you want to do then awesome! Go study it, learn it, practice it. But if you're doing it as a side-hobby, never put it into production.

<comment><USER6> 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 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.

Surely people who invent and implement cryptographic algorithms for a living can be expected to be better than your run-off-the-mill programmer, but as I've said elsewhere implementing crypto is also not a black art. It requires about the same level of skill as e.g. implementing a production-ready low- level network protocol or a file system. That rules out many programmers but not all. That concerns implementations. As for algorithms, their development requires extensive experience in _cryptanalysis_ (not just applied cryptography!). Some pros have that, others don't.

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...

<comment><USER7> 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.

<comment> loup-vaillant > _a network protocol is not designed to be error-proof in an intentionally > antagonistic environment_

Err, really? That may be the case sometimes. Also these days many things can be antagonistic: anything online is exposed to adversaries. So is anything that routinely reads untrusted input on everyone's computer (like a video player, or a pdf reader).

Thinking of the sheer amount of potentially vulnerable code out there makes me a little scared.

<comment><USER7> But is the code you're speaking of the security-specific code, or the network- specific code? If you attack a networking protocol, what are you attacking if not the associated cryptography? A networking protocol without any cryptography doesn't really need to be attacked because it's already wide open.

You introduce the confidentiality, authentication and integrity (which is really just going to be part of the authentication) through cryptography and security-specific code.

I'm not saying people don't attack networking protocols, or that there is no incentive for doing so. I'm saying that the portion that plays the _defensive role_ is in the security software, not the overlying networking protocol.

<comment><USER8> re networking vs security-critical code

Anything that accepts data from potentially-malicious sources is security- critical if it's itself privileged or produces data/events that go to something else privileged. Such analysis is usually used to determine the "Trusted Computing Base" (TCB) of a system that encompasses everything that might be used to break the security policy. All people who do real, security engineering keep it in mind, minimize it, strengthen it, and document what's left.

Here's an example from high-assurance field of what that looks like where they prototype an architecture for VPN's that minimizes TCB of key components:

[https://os.inf.tu-dresden.de/mikrosina/dach2005.pdf](https://os.inf.tu- dresden.de/mikrosina/dach2005.pdf)

Far as qualifying the TCB, the seL4 team's What is Proved and What is Assumed is a great illustration of keeping it real about the security claims:

[https://sel4.systems/Info/FAQ/proof.pml](https://sel4.systems/Info/FAQ/proof.pml)

Also shows their TCB is a lot bigger than their tiny kernel. Fortunately, there's been high-assurance developments to solve most of _those_ things. I've seen robust, networking stacks but don't think they're high-assurance yet. If they're complex and done in C, here be dragons.

</comment></comment></comment></comment></comment></comment><comment><USER9> It was a fun read, except when all the C bugs were listed. It's getting tiresome to hear about folks writing nominally Important software in a language where it is extraordinarily difficult to get things absolutely correct, with paltry excuses such as "it needs to be fast" or "it needs to be portable [0] to a VAX-11/750." It doesn't give me confidence that these completely usual bugs popped up early on, and it will not surprise me when more show themselves.

The author's lack of practical familiarity with the memory hierarchy, caching, and pipelining—evidenced by his surprise by the speed gained by fetching more than a byte at a time—also makes me suspicious of his understanding of the semantics of his program. (I understand that this is a form of _ad hominem_ as it relates to arguing the correctness of software, but it's a consideration worth noting in a broader context of trust.)

It would be great if this was written in another language.

[0] Most "portable" code written in C is not portable. Look at any mature C project and see the layers and layers of macros and hacks to make things portable.

<comment><USER10> Curious about the other language. What other language that doesn't add another layer between the code and system instructions were you thinking about?

<comment><USER11> Most programming languages with compilers to native code (JIT/AOT), the myth of high level Assembler for C only applies if your computer is a PDP-11 or a basic 8-bit CPU like a 6502 or Z80.

The ANSI C and C++ standards define the concept of abstract machine for the language semantics, just like in most languages.

Additionally you have the concepts of sequence points, the new memory model semantics for multi-threaded code and the beloved UB.

UB which doesn't exist in most languages, because their rather leave it implementation defined or lose the opportunity to target some strange CPU not able to support the language semantics.

Also Assembly doesn't has UB, making it ironic that it is safer to write straight Assembly at the expense of portability than C or C derived languages.

<comment><USER12> > Also Assembly doesn't has UB, making it ironic that it is safer to write > straight Assembly at the expense of portability than C or C derived > languages.

You just need to know your compiler flags/configuration to produce exact assembly output (if you want that). And about assembly not having UB, BSF and BSR are pretty good examples for that.

<comment><USER11> That _just_ is quite ironic, because it is even version dependent across releases of the same compiler, which means anything fine tuned for version X can break on version X + 1, due to changes on the optimizer.

And I doubt anyone is regularly reviewing the produced Assembly every single time they change compilers.

Assembly doesn't have more than 200 documented cases that hardly any human is capable of remembering.

</comment></comment></comment></comment></comment><comment><USER13>
        found an error in the Argon2 reference implementation.

This is exactly why I like as many people writing crypto as possible[0]. Bugs like the one the writer found show up in reference implementations, and are found by absolutely no one unless someone writes an alternate implementation that behaves differently.

Edit: A further example, a lot of people write crypto as part of various CTFs. This is a case of "writing crypto" that poses no threat to the community.

[0] That doesn't mean they should use it in production.

</comment><comment><USER14> I've always seen 'rolling your own crypto' as not being recommendation against writing your own library, but creating your own primitive.

Sure, writing your own library is _very_ difficult, but you have a simpler set of problems, which proper testing, another set of eyes and enough tools will take care of the big problems.

Now, implementing your own primitive and recommending to use it is _bad_. For a primitive to be deemed secure, it has to undergo years of review and testing by seasoned cryptographers.

This isn't a recommendation to write your own library, but my opinion that it is okay to do so if you want something that none of the major libraries offer.

<comment><USER15> Even just using crypto primitives is dangerous unless you've got experience. There's an old post from matasano about it [https://www.nccgroup.trust/us/about-us/newsroom-and- events/b...](https://www.nccgroup.trust/us/about-us/newsroom-and- events/blog/2009/july/if-youre-typing-the-letters-a-e-s-into-your-code-youre- doing-it-wrong/)

<comment><USER14> Every line of code written can be a severe vulnerability, not just code dealing with crypto. In case of crypto, being well-informed is good enough to not mess up those kind of implementations (on a theoretical level). The problems mentioned can be pointed out and verified on paper. But you can't say the same thing for code.

<comment> Ar-Curunir No, you can write crypto code, even when knowing stuff about the crypto, and still mess up. Crypto is problematic because you often cannot easily check whether you're wrong (it could be a tiny edge case that isn't tested because your input space is huge).

<comment><USER14> I didn't deny messing up crypto code is a thing. I'm saying messing up code is a separate problem from messing up how one architects projects using crypto.

What you say as messing up with edge cases, etc. is a programming problem. The errors talked about in the link he posted is about using faulty crypto. Today it is common knowledge to never use ECB.

What cipher mode you use is a problem you think about before you even start writing a single line of code. But you are talking about programming errors, which one can make in all areas, not only ones involving crypto. Those errors can break security similar to messing up crypto implementation.

</comment></comment></comment></comment></comment><comment><USER16> Hey, fantastic work! Really happy to see some amateur crypto development out there. I started as an amateur also, now I work in crypto product dev.

Definitely impressed if this is your first crypto work. I really like the simplicity, reminds me of OpenSSH.

I gotta agree with some of the naysayers though - this needs more time to brew. Even if it's perfect, there still more proof to show.

My suggestions:

* A long-running interoperability test between your lib and another. Test vectors don't catch everything. Run it for a week, check results and publish the results.

* Fuzzing. You need to to catch false results, random crashes, stack overflows, etc. Fuzz every input, do it for random lengths (both underflow and overflow).

* Maybe port it and test on Win, Mac, ARM, MIPS. I find a lot of bugs shake out during ports.

* Timing. You can't prevent all side-channel attacks, but bits going out are easy attack vectors. Use a high-precision timing mechanism to catch any unusual spikes. Capture a few hours of points for each functional path, and publish the results. (crypto_aead_unlock has two return paths, it might be better to maintain timing).

* Personal preferences: Rather than using int returns, use bool. Zero your ctx vars, e.g. a_ctx ctx = {0,};

I spend more time in testing products than development, honestly. Publish as much relevant data as you can.

<comment> loup-vaillant > _Definitely impressed if this is your first crypto work._

It is. :-)

> _A long-running interoperability test between your lib and another._

Already have one for all primitives. Just tweak the parameters to make it run for a long time. The test code is in test/sodium.c and test/donna.c

> _Fuzzing. You need to to catch false results, random crashes, stack > overflows, etc. Fuzz every input, do it for random lengths (both underflow > and overflow)._

I'm not sure how to go about it. I already check every input size, from zero to several times the size of the internal block, in my comparison tests.

Of course, all inputs are correct. Incorrect inputs result in undefined behaviour, checking for that is out of scope. (That's why most functions return void.)

> _Maybe port it and test on Win, Mac, ARM, MIPS. I find a lot of bugs shake > out during ports._

Yeah, I only tried GCC and Clang on my Intel Ubuntu machine. But I did use Valgrind, ASan, MSan, UBSan, and the TIS-Interpreter. I also compiled under various standards: C99, C11, C++98, C++11, C++14, C++17.

> _Timing. […] Use a high-precision timing mechanism to catch any unusual > spikes_

Isn't that a bit overkill? I'd rather manually review the source code for the absence of secret dependant branches or secret dependent array indices. I'm not implementing AES or RSA, the primitive I have chosen were specifically designed to easily avoid timing attacks.

> _crypto_aead_unlock has two return paths, it might be better to maintain > timing_.

No. There are 2 cases to consider: failure, and success. Each path runs in constant time, so timing can only distinguish success from failure… which is revealed anyway by the return code.

> _Rather than using int returns, use bool._

I'm afraid bool is a tiny bit less portable than int. I also went with the flow about error codes, which are traditionally int.

> _Zero your ctx vars, e.g. a_ctx ctx = {0,};_

I'm not sure how to do it portably, with zero dependency.

</comment></comment><comment><USER17> Whenever I feel the need for a tin foil hat I start to wonder if there is a FUD campaign powered by the "establishment" to encourage people not to investigate this area of computer science so that security holes will remain unnoticed.

But, yes I wouldn't start out on writing a crypto library, then again I wouldn't attempt to build an OS or a 3D stack or even an web server either. All cases where a security breach could have devastating effects as well.

<comment><USER18> Writing your own crypto is the only way to become good at it, or to understand more about crypto.

* DJB wrote NaCl

* Frank wrote libsodium / libHydrogen

* Brian wrote Ring

* Thai Duong and Bleichenbacher wrote Tink

* Eric Young wrote OpenSSL

* Jason Donenfeld wrote Wireguard

* Shoup wrote NTL

* Emily Stark, Mike Hamburg and Dan Boneh wrote SJCL

* Thomas Pornin wrote 6 SSL libraries and then BearSSL

* Adam Langley wrote everything else

* ...

<comment><AUTHOR> This is a deeply misleading list.

Daniel Bernstein, Daniel Bleichenbacher, Dan Boneh and Thomas Pornin are professional cryptographers and world-renowned experts. Even I would feel comfortable writing crypto if Bleichenbacher was watching behind my back.

Frank "wrote" libsodium, but libsodium is effectively a port of NaCl. Frank had Daniel Bernstein watching behind his back.

Eric Young wrote OpenSSL. Look how that turned out! Has there been a class of cryptographic vulnerability that OpenSSL hasn't had?

And yet consider: for all the effort that people like Bernstein and Boneh put into writing strong, safe crypto, the entire world has blundered into vulnerability after vulnerability because the amateurish crypto in OpenSSL is the one every else ended up using.

It's as if you set out to prove my point.

Finally: you obviously know that "writing your own crypto" isn't the only way to become good at it. In fact, it's a terrible way to get good at it. The right way to get good at crypto is to learn how to break it. But that takes effort, and you can have a blog post crowing about your new crypto library just a few weeks after deciding to write one.

<comment><USER18> > are professional cryptographers and world-renowned experts

They were not in the beginning. And implementing crypto helped them get there. That's my point.

> Finally: you obviously know that "writing your own crypto" isn't the only > way to become good at it. In fact, it's a terrible way to get good at it. > The right way to get good at crypto is to learn how to break it.

I strongly disagree with you on this, but I'll add a twist: I'm mostly saying to become good in "applied" crypto you must roll your own. There are too many problems you can't understand until you actually write code and try to make it secure. If you want to become good in theoretical crypto, then don't roll your own obviously.

This works in any field btw. The best web pentesters are the people who have implemented websites on their own as well.

<comment><AUTHOR> I would suggest that for each of them, a 10+ year career in academic cryptography, in each case accompanied by significant new research results, is what helped them get there. Implementing a library, not so much.

As for your second point: literally everyone can implement cryptography that appears secure to them. It's tautological.

<comment><USER18> > I would suggest that for each of them, a 10+ year career in academic > cryptography, in each case accompanied by significant new research results, > is what helped them get there. Implementing a library, not so much.

I believe that what made them exceptional (for most of them) is the combination of theoretical learning and hands-on programming. That's my entire point. I think we can agree to disagree. But that's an opinion I'll probably hold for the next years as this is the direction I want to take as well.

> As for your second point: literally everyone can implement cryptography that > appears secure to them. It's tautological.

And the process of putting it out there and looking for ways to make it more secure is how you learn. Proof: he already learned a bunch about Frama-C and other C oddities and documented these via his blogpost. Plus he found a bug in the Argon2 implementation. That's a win.

<comment><AUTHOR> Why don't you ask them? Most of these people aren't hard to get ahold of. One of them you even share a Slack with. I would be surprised to learn that any of them believed doing a library implementation of pre-existing crypto constructions was an important part of their education, but I like to be surprised.

<comment><USER18> I did ;) surprise

<comment><AUTHOR> What did he say? Share with the class!

<comment><USER18> I can't share this kind of personnal information Thomas. I'm sure you understand! I guess you'll have to take my word for it.

<comment><AUTHOR> Ok, I'll ask Thomas Pornin myself.

<comment><USER19> I indeed learned a lot, and still learn a lot, by doing implementations. Doing a proper implementation forces me to consider all aspects; when the code runs properly, I know that I have, by definition, been exposed to all the parts. You cannot get that kind of exhaustiveness from simply reading an article.

However, doing implementations is not at all the same thing as publishing implementations! The first one or two attempts are always flawed in some way; only the third one can hope to be reasonably good. I took care to properly kill and dispose of the corpses of all my learning code.

The trick (and it's a difficult one) is to decide in advance that the code you write to learn will have to be deleted -- and stick to it. Developers have trouble letting go of their creations, in general. If you can maintain that discipline, then there is no problem in "writing your own crypto". But that is a big "if".

<comment><AUTHOR> I've found that a good motivation for writing learning-only "throwaway" crypto code is as models for writing attack code; you don't even have to throw the code away, just publish it with the exploit.

But then, I'm a believer that everyone should learn crypto by breaking it, and clearly not everyone agrees with me.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> 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.

This sounds weird to me, how is a shift (which only apply itself on the bit value, not the number value) triggering a sign extension? I don't think you're talking about integer promotion here unless you had a uint16_t = uint8_t << 24 or something like this.

<comment><USER20> I believe this[1] is the patch that fixes this bug. I tried to reproduce the behavior but couldn't succeed. Maybe I was doing something wrong. Would really appreciate it if someone here could show a test case where this matters.

[1] [https://github.com/LoupVaillant/Monocypher/commit/347189c50c...](https://github.com/LoupVaillant/Monocypher/commit/347189c50c053cf13ce1310818c2913f4904c1eb)

<comment> loup-vaillant Your failure to reproduce the behaviour is normal: on the compilers I have tested, this doesn't affect the generated binary.

To see the difference, you need to first modify the makefile to use UBSan instead of just GCC (just comment the active CC line, and uncomment the right one). You may want to tone down the optimisations for faster compilation as well. Then you can run `make clean` and `./test.sh`. You should have a warning on commits prior to this patch.

</comment></comment></comment><comment><USER14> I'm amazed that the reference implementation of Argon2 had a bug. So that means anyone who deployed Argon2 today didn't really use Argon2 (I'm being pedantic), but something else?

libsodium also got it wrong, so that brought down my opinion of it being a trusted and well-reviewed library.

Now the question is, will they continue to use the same implementation or move to the fixed code?

<comment> loup-vaillant Maybe the authors will fix the code in subsequent versions of Argon2. Right now, backward compatibility is deemed more important. The effects of this bug are practically negligible anyway. I bet a single bit of additional entropy in a password would compensate that a hundred fold.

I'm a bit disappointed however at their not updating the specs. I signalled the bug in January, and the latest version of the appear to have been published in March. I guess they had other priorities.

Don't be too hard on Libsodium: they only got it wrong because they reused the reference implementation. (Also, I don't see them breaking backward compatibility either.)

<comment><USER14> I'm also referring to the orgs who used Argon2 in production. If they move to the fixed version of Argon2 in libsodium, they'll have to make a plan to securely move to the correct implementation by hashing the passwords again. It can be done, but I'm wondering if they'll even bother.

<comment><USER21> There is hardly anyone using Argon in production.

The few hipsters who jumped on the new hashing algorithm bandwagon can't have much users.

</comment></comment></comment></comment><comment><USER22> I really liked that read, good writing style and the author was coming from the same place that I'm usually coming from (can we redo this ourselves and shave off some bloat in the process).

However, as it stands now, it looks more like a cautionary tale on why he should have listened when people told him not to do it :-)

I suspect a worthier goal would have been to look for ways to improve the linking footprint of libsodium instead of rolling your own library. Maybe turn the "I want the smaller version without the huge lookup table please" in a compile time option or so. That way more people could have used it without having to commit to "I'll use this little known experimental library instead of libsodium". Commit in the sense of "people will ask why and I will have to defend my decision", not in the sense of "oh no we are locked in!!"

<comment> loup-vaillant Reducing the linking footprint wasn't my only goal. Reducing the source code is also important, if only to facilitate tests and audits —thus increasing confidence. That huge table for instance would need to be tested. Every single value would need to be checked for correctness, or I would have to demonstrate they came from a sound generator.

\---

I've been careful not to lock people in. If people want to upgrade to faster primitives, they can. I don't think they will ever need to, though.

</comment></comment><comment><USER23> 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.

<comment><USER18> It's risky but sometimes it's the only way. To be fair the code size is relatively small so it should be easier to audit than other products. My guess is that his blog post is also some motivation to get new pair of eyes on the library. If there's any fund for that, I'd be happy to look at it ;)

</comment></comment><comment><USER24> Write a crypto library and blog about how great it is.

Apply the tools that other people used to find bugs in it and repeat blogging about how great it is.

...

In the end you get a library that is slower and smaller (because you left out the optimized code, duh). It's still not as small as the smallest.

Is this easier to audit? Dubious but it doesn't matter because if people hadn't wanted the extra speed they wouldn't have added the optimized code anyway.

Plus, that code is already audited and rolled out and works! Who cares about auditing another library that provides nothing new?

The only non obviously-garbage argument here is usability which I am too lazy to look at because it is too fuzzy to refute anyway.

By all means, write your own crypto but DON'T USE IT! And of course don't tell other people to use it either.

<comment> loup-vaillant Let's list the pros and cons of each libraries (let's assume we trust all 3 libraries):

Monocypher vs TweetNaCl:

      Good:
        Monocypher uses more modern primitives (Blake2b, Chacha20)
        Monocypher provides password derivation
        Monocypher is a bit easier to use
        Monocypher is much faster
      Bad:
        Monocypher is twice as big
      Conclusion:
        Monocypher utterly outclasses TweetNaCl.

Monocypher vs Libsodium:

      Good:
        Monocypher is much smaller
        Monocypher is easier to deploy
        Monocypher is a bit easier to use
      Bad:
        Monocypher is a bit slower (except Argon2i, which is faster)
      Conclusion:
        If performance matters, use NaCl.  Otherwise, use Monocypher.

Nothing new, you say?

> _By all means, write your own crypto but DON 'T USE IT! And of course don't > tell other people to use it either._

Get back to me in a couple years, we'll count the CEVs since version 1.0.

</comment></comment><comment><USER25> Main lesson not learned: instead of testing, prove correctness in high assurance code like this. Rigorously and formally. Preferably even refine the proof to executable code.

(Yes, it would take somewhere on the order of 10k LOC to prove correctness of this 1k.)

<comment><USER26> Proving correctness isn't enough. You have to test it too. It's perfectly possible for the proof to have errors (bugs). It's also possible for the proof to be incomplete: you can prove the algorithm is correct and implemented correctly to spec and still have vulnerabilities.

<comment> loup-vaillant While 100% confidence is impossible (because I'm Bayesian), machine checked proofs do help. It's then a matter of cost/benefit.

</comment></comment></comment><comment><USER27> I still believe it's a bad idea to roll your own crypto, interesting as an exercise, but I would never use it in a production environment.

<comment><USER28> How will cryptography libraries ever develop if someone doesn't roll their own?

<comment><USER29> Through sweat and blood. Don't expect crypto libraries to be secure the first few years after their release. That's why people favor the mature, battle- tested libraries.

<comment><USER30> But then again, we still got Heartbleed.

<comment><USER31> Yeah and imagine the kind of exciting bugs that exist in new and immature libraries! :)

<comment><USER30> Yes, but are hackers going after common used libraries to get more vulnerable systems to attack or are they going to spend time on some unknown homebuilt crypto? In some cases, security through obscurity works well in practice.

<comment><USER5> > In some cases, security through obscurity works well in practice.

This is not one of those cases. Absolutely not. I'm moderately competent at finding security bugs in things, but I doubt I could find any in OpenSSL. I am confident I could find some in your average hand-rolled code.

The thing is people make the same mistakes. There's a set of well-known mistakes that are very easy to make, especially if you're not versed with the entire history of implementing crypto - which is the case for the majority of people rolling their own. This makes it very, very easy to guess what mistakes they will make, and if you know what you're looking for it's easy to find it.

My "personal best" for finding a crypto bug in a project is 50 seconds.

I doubt anyone has found a bug in OpenSSL (or any established crypto project) anywhere near that fast.

<comment><USER30> You got to consider your most likely risk for attack. Targeted or at random by a botnet? For example, you are most likely more secure in practice by writing your own website than using Wordpress, simply because you are more likely to get hit by a botnet targeting every Wordpress site than someone going directly for you.

<comment><USER5> This is off-topic. We are talking about security vs obscurity in the context of cryptography libraries.

<comment><USER32> Replace WordPress with OpenSSL and website with crypto.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER33> Are there other fields where the slogan "don't roll your own XXX unless you are an infallible expert" is applicable?

<comment><USER34> Parachute?

<comment><USER35> Actually you do roll your own parachute once you have done enough jumps. But your reserve chute is always rolled by a certified professional specifically certified to roll reserve chutes, and not by yourself. (if I remember correctly, my memory is a bit fuzzy from when I jumped a couple of years back)

<comment><USER36> Well, you are _using_ the product, but not _manufacturing_ it.

</comment></comment></comment></comment><comment><USER37> Have the library functions been tested (or proved) to be constant time ? This is a critical property of libsodium.

Another question is what make the difference in number of line of codes with libsodium ? I mean what do these lines of of libsodium that your lib doesn't have contain ?

Also, is this a fair metric ? You know we can have 1000 char long lines in C. ;)

<comment> loup-vaillant > Have the library functions been tested (or proved) to be constant time ?

Just check the absence of secret dependent branches, and secret dependent array indices, it's pretty simple.

> _what make the difference in number of line of codes with libsodium ?_

Less lines means less need for eyeballs, tests, and audits. Libraries the size of TweetNaCl (and, to a lesser extent, Monocypher), can be subjected to very rigorous audits, and increase confidence accordingly.

> _what do these lines of of libsodium that your lib doesn 't have contain ?_

I can see 3 sources: redundant primitives (Monocypher is not redundant), alternate implementation (Monocypher sticks to portable C), and verbose implementations (Monocypher keeps it simple).

> _Also, is this a fair metric ?_

Not quite: I did not count the size of the header in Monocypher and TweetNaCl. Still, I don't think Libsodium has less than 22K lines of actual code. (Note: I counted everything with sloccount)

On the other hand, my lines never exceed 80 characters.

</comment></comment><comment><USER38> I have read the article and I still don't understand what was the purpose of such a project.

What's wrong with ZIP or 7-Zip + AES encryption? Or GPG with a GUI? Or any other existing tool that's already stable and multi-platform?

<comment><USER39> This is a library, unlike the ones that you mentioned.

</comment></comment><comment><USER40> Hi,

I've browsed through the code and i don't see why say it is not good in MT setting... an first view the code is completely reentrant...

Another thought: i strongly suspect that inlining these store_le... and load_le... function will show pretty significant performance boost

</comment><comment><USER41> I only had a brief look at it but it seems that crypto_check doesn't verify whenever the signers public key is on the curve.

<comment> loup-vaillant I'm not sure. If there is such a test, you should find it on `ge_frombytes_neg`. I bet it returns -1 in line 1315 if that happens. (It triggers a rejection when that happens.)

If I'm right about this, it would explain why this code path is never hit: it would only trigger with invalid public keys. I'll test that as soon as I can.

</comment></comment><comment><USER42> 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

<comment><USER43> Part of it is described in the Frama-C blog ([http://blog.frama-c.com/index.php?post/2017/03/07/A-simple-E...](http://blog.frama-c.com/index.php?post/2017/03/07/A-simple- EVA-tutorial)). It actually presents a tutorial on the EVA plug-in (former Value Analysis) with Monocypher as a case study.

Note that this is the initial stage of using Frama-C. The next step would probably include writing some specifications for functional behavior (in ACSL), and then using the WP plug-in (based on weakest precondition calculus) to prove those specifications, providing much stronger guarantees.

A few Frama-C case studies are on Github ([https://github.com/Frama-C/open- source-case-studies](https://github.com/Frama-C/open-source-case-studies)), including an old release of Monocypher, but they constitute mostly a initial parametrization of the EVA plug-in. Most advanced users of Frama-C apply it on industrial code that is not available, but academic users regularly publish papers with case studies (searching "frama-c" on Google Scholar gives good results).

</comment></comment><comment><USER44> Heads up the the author: The Reddit and HN links in the timeline are switched :)

</comment><comment><USER45> I see crypto as black magic. Can anyone recommend some introductory resource to demystify it a bit?

Why is it so hard?

<comment> loup-vaillant Here's a good introduction to cryptography: [https://www.crypto101.io/](https://www.crypto101.io/)

</comment></comment><comment><USER46> So where is the Mono / C# wrapper, or C# implementation of this? (:

<comment> loup-vaillant The only bindings I'm aware of right now are for Crystal (it may or may not be up to date):

[https://github.com/konovod/monocypher.cr](https://github.com/konovod/monocypher.cr)

I think I will personally do C++, OCaml, and perhaps Lua. For the rest, either someone contributes, or you'll have to look at the FFI yourself…

</comment></comment><comment><USER47> I thought the first rule of crypto was never role your own crypto.

<comment> loup-vaillant I'm the exception. :-)

Seriously though, Monocypher is getting getting past the "own crypto" stage at this point.

</comment></comment><comment><USER48> Inb4 "don't roll your own crypto"

</comment><comment><USER39> I really liked your previous articles/tutorials about Poly1305 and Chacha20. Is there any plain to make similar articles about the other constructions that you implemented on this library?

Is there also any plain to implement scrypt (based on the salsa), SPHINCS (uses BLAKE(1) and Chacha), Ed448-Goldilocks, Keccak or any of the CAESAR candidates? (The ones that seemed the most interesting to me were NORX, Keyak (based on keccak) and HS1-SIV (based on chacha)).

<comment> loup-vaillant I don't think I'll write for the other primitives, I don't know them well enough to comment on them properly.

I won't add other primitives to Monocypher, that would defeat the purpose of a "one true cipher suite". One stream cipher, one authenticator, one hash, one password key derivation, one key exchange, one signature. That is enough.

When some of those primitives becomes obsolete, I'll consider writing a new, incompatible version of Monocypher. For instance, we can switch to curve448 if curve25519 isn't secure enough. I think at least a decade will pass before we come to that, though.

</comment></comment><comment><USER24> TLDR: Crypto library with two claimed advantages: Better usability and smaller code than libsodium. However, it is also slower.

<comment><USER36> Having all of that would be great, but most of the time you need to weigh one against another. Smaller code means smaller attack surface and supposedly fewer ways to shoot yourself in the foot ("I know, I'll use CBC"); of course, checking whether the author doesn't shoot you in the foot by choice of algorithms, _or their implementation_ , is advised.</comment></comment>


ThinkGeek's Clip-on 8-Bit Tie: An April Fool's Joke Becomes a Real Product - <AUTHOR> http://www.thinkgeek.com/apparel/hats-ties/9352/?cpg=59T

<comment><AUTHOR> Here's the background story, in case you missed it in April: [http://kotaku.com/gaming/thinkgeek/thinkgeeks-8+bit-tie- not-...](http://kotaku.com/gaming/thinkgeek/thinkgeeks-8+bit-tie-not-just- vaporwear-249062.php)</comment>


Resources for Learning about Machine Learning  - <AUTHOR> http://blog.smellthedata.com/2010/06/resources-for-learning-about-machine.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+ThisNumberCrunchingLife+%28This+Number+Crunching+Life%29 <comment><USER2> Do you think one day machines will have Resources for Learning about Human Learning?</comment>


YouTuber creates fake Nirvana song using artificial intelligence - <AUTHOR> https://www.nme.com/news/music/youtuber-creates-fake-nirvana-song-using-artificial-intelligence-2690860 <comment><USER2> We're calling markov chains AI now?

Only the lyrics have been generated. Everything else you hear is just the musician, trying their best to sound like nirvana. No AI wizardry involved.

The lyrics sound less like an unreleased nirvana song, and more like a cut up of their previous songs. Which is to be expected when you feed a relatively small corpus of lyrics into a markov generator.

I get that this is just supposed to be fun. My point is that the title is misleading.

<comment><USER3> It's pretty decent imitation, but yeah I was hoping the whole song was AI. Then again most AI songs are still pretty lame.

</comment></comment><comment><USER4> I was hoping the whole song/audio was generated. Looks more like fragments of existing nirvana lyrics re-arranged into a semi-coherent ordering. I recognize almost all the lyrics from existing songs.

</comment><comment><USER5> It's only the lyrics that are generated (and he's just using markov chains?) , the music seems to be written by the guy doing them based on the article.

So barely anything to do with AI?

</comment><comment><USER6> You can listen to actual AI-generated songs in the style of Nirvana with the OpenAI Jukebox: [https://jukebox.openai.com/?song=807313705](https://jukebox.openai.com/?song=807313705)

<comment><USER7> Very cool, but the two Nirvana tracks on there are pretty terrible.

</comment></comment><comment><USER8> I didn't like this as much as some other AI songs, notably Metallica [1]. It seems this model wasn't trained long enough as this song is the In Bloom/Breed riff with some lyrics and the general structure of Smells Like Teen Spirit.

[1] [https://www.youtube.com/watch?v=zTG1Nb1hND0](https://www.youtube.com/watch?v=zTG1Nb1hND0)

</comment><comment><USER9> Does anyone remember Microsoft Songsmith? [https://www.youtube.com/watch?v=wHduATM-o7M](https://www.youtube.com/watch?v=wHduATM-o7M)

<comment><USER9> Also, to follow up, the introduction campaign for Songsmith is one of the worst things I've ever seen [https://youtu.be/3oGFogwcx-E](https://youtu.be/3oGFogwcx-E)

<comment><USER10> I thought you were exaggerating. I was wrong.

</comment></comment></comment><comment><USER11> Click bait title, it just created some lyrics, I was hoping for a deepfake of the voice like "Voice synthesis" channel on YouTube.

</comment><comment><USER12> Hey if you're interested in human voice synthetized and mimicked by AI check out this awesome project [https://www.descript.com/lyrebird- ai](https://www.descript.com/lyrebird-ai)

Overdub allows you to replace recorded words and phrases with synthesized speech that's tonally blended with the surrounding audio.

</comment><comment><USER13> YouTuber creates fake Nirvana song using fake artificial intelligence.</comment>


Kitchen Knives: The New Bling (2013) [pdf] - <AUTHOR> https://www.oxfordsymposium.org.uk/wp-content/uploads/2013/06/Hertzmann.pdf <comment><USER3> What's truly amazing to me is the low cost of truly high quality kitchen knives available today.

Ikea sells a 3 knife set for $30[1] that is made with the exact same steel as high end German knife brands - x50crmov15.

IMO, the real problem with kitchen knives in most homes is they are woefully under-sharpened. A budget knife that's sharpened once or twice a month will completely outperform the most expensive knife that's never sharpened.

___

1\. [https://www.ikea.com/us/en/p/ikea-365-3-piece-knife- set-9034...](https://www.ikea.com/us/en/p/ikea-365-3-piece-knife- set-90341170/)

<comment><USER4> Your overall point is well taken, but X50CrMoV15 is commodity stainless steel. Those German knives use it because people leave their knives out wet on their counters, not because it's amazing at cutting.

The worst is Misen, though, which brags about AUS8 steel as if it were Blue Paper Steel and not generic tool steel.

<comment><USER5> I think this observation is very much on point. Imho, there's a bit of what amounts to fetishism in the knife-making community about steels. Truthfully, the primary differences should be in fit, finish, and balance for a knife. It's just as possible to put a fine edge on the cheapest steel in the world as as it is an expensive tool steel like 440C. Jay Fisher, a custom knife-maker, likes to makes the point that a ceramic flint-knapper can put an edge on a stone that will scare any knifemaker alive, as long as the edge doesn't accidentally touch anything too solid and chip.

An AUS8 blade hits a nice balance between corrosion resistance, end-user servicing, decent maximum hardness, and manufacturability, though focusing on "our steel is special" seems to sell blades. Plus, I think it's worth noting that if most manufacturers were to make blades out of more expensive knife making steel like S3OV, not only would they likely corrode, people would be close to incapable of properly caring for those blades properly anyway. It's not an easy task, especially for someone who is only using the knife to achieve their primary goal: cooking.

<comment><USER6> I don't get the steel fetishism either, and with kitchen knives it's clearly very much about environment: your fancy-pants pocket knife steel may not do well in an environment where it's sat around damp and with food residue on it for hours or days, shoved into a dishwasher, or whatever.

I'm not mad on pocketknives, but I've got a small handful in 440C, a couple in AUS-8, and then one in S35VN. The latter used to be considered fairly high end as a blade steel but now appears to be increasingly commonplace in even relatively inexpensive knives.

From a practical standpoint, and for my use cases, there's no significant difference between any of these, except that the S35VN is harder to sharpen.

I have no complaints with edge retention or sharpness for any of the 440C or AUS-8 knives I own even though they're looked down on as blade steels by the knife community and, in fact, my favourite pocketknife for everyday and DIY use is the very inexpensive Ontario Rat #1 in AUS-8. It fits my hand well, is a great cutting tool, and is incredibly easy to sharpen and maintain.

</comment></comment></comment></comment><comment><USER7> And copper pots!

Funny thing this article doesn't really talk about REALLY expensive knives. Just "Mall Fancy" (gatekeeper's delight: if you can buy it in a mall, it's not 'real' bling.) There's a custom knife store I visited in Portland last year that goes up to $3k for handmade knives.

Expensive knives are silly. $49 Victorinox is probably one of the best knives out there unless you're a sushi chef according to just about every review. I have one, it's great. Better than my Shyun for the price and easier to put on edge on.

But don't take my anecdote for it: go talk to a chef and ask what kind of knives they use. Know what the answer will be? In most restaurants they are from Sysco. Source: friends that work back of the house.

<comment><USER4> The Victorinox Fibrox has been a popular pick (and rhetorical tool for debunking Veblen knives) for years because Cooks Illustrated championed it, but it underperforms in tests and, in particular, has an apparently bad factory edge --- you could correct that, but I doubt many owners really do.

I think the Fibrox still works as a rhetorical tool. It's true that most people would be just as happy with a $50 Fibrox as they would be with an expensive Shun. But it's not the case that the Fibrox holds up well in serious tests against other knives.

The flip side of professional kitchens getting their knives from services is that they're also constantly refreshed with new sharp blades (the service takes the dulled blades back and replaces them with new ones), which is something that isn't true for home cooks. I wouldn't read too much into that.

(I have a Mac MBK-85; it's great. Just get a Mac.)

<comment><USER8> The fibrox is _fine_ , but a single 8" Shun chef's knife is near the price of an MBK-85 for a not-dissimilar level of performance.

I have a Fibrox santoku, Shun 7" Chef's knife (VG-10), Ohishi 270mm (VG-5), and some of the Ikea 365 knives (e.g. 6" chef's knife), as well as some K-Sabatier. For the money, the Ikea 365 knives outperform the Fibrox - <USER2> hold the edge much better. The K-Sabatier are better than the fibrox for not too much more money (and they're pretty classic). The Ohishi was the best value and is my favorite knife but it's a bit on the large side. I also have a few other random knives (arcos ham knife, dexter russel boning knife, mac bread knife)

I recommend the Ikea ones to most people. They are super cheap, sharp, and hold their edge pretty good. If they wanted an upgrade pick, I'd recommend an Ohishi or similar (there's a few similar ones online that are high quality), but I don't think buying a Shun isn't a terrible proposition - they are readily available in most markets and good quality. Buying a knife block isn't recommended though.

Relatedly - I usually buy family members getting married decent set for a gift too - and the smaller sets of Victorinox are usually nice.

<comment><USER9> About a decade ago I looked into this. I had a Shun Santoku (VG10), but my brother wanted to get me a nice knife as a wedding gift. I did a little research on the knife forums (very interesting world, I could see spending a lot of money on a combination of metallurgical tech and art if you get sucked into that).

Exotic stainless (e.g. powdered steel) sounded like it would be challenging for an amateur to sharpen, and I wasn't sure I could be trusted to take proper care of a carbon blade, so I hedged and went with a semi-stainless (SKD) 240mm Yoshikane wa-Gyuto. I kinda wish it had a little more belly, but it's sharp, cuts well, and is easy to sharpen.

</comment></comment></comment></comment><comment><USER10> I have a single high-end kitchen knife, a Masakage Mizu gyuto. At under $200, it's not the height of bling, but still an order of magnitude above the cheapest thing that could possibly work. I bought it after handling almost everything in a shop specializing in Japanese knives, and I selected it largely based on its feel and balance.

It is much better at cutting things than any other kitchen knife I've used (yes, most were properly sharpened), though compared to German knives around $100, its advantage for me as a home cook is mostly that it feels good to cut with, not that I couldn't do all the same things with a cheaper, lower- performing knife. The difference in performance comes from the blade stock being thinner, the grind being convex instead of flat, and the blade being thinner immediately behind the sharpened edge.

There are downsides: the steel is not stainless, and being much harder than a typical German knife makes it prone to chip if it accidentally contacts something hard. Stainless options with similar characteristics exist, but it's widely believed that they can't get quite as sharp.

</comment><comment><USER11> I was never much of a believer in knives until I lost some dexterity in my right hand and to keep from sticking my fingers under my old chef's knife I went down to a japanese knife shop and bought a knife so tall that I couldn't possibly stick my fingertip under the blade. I think it was about $200. It was and remains absurdly sharp. It is as sharp if I use it for three meals a day for a year as my Global was if I frequently and conscientiously honed it. It really makes a big difference if instead of crushing a sushi roll, you actually manage to cut it. I'm a believer now, just my own labor savings alone was worth the price. Was I supposed to not buy it just because it has a somewhat fancy appearance?

</comment><comment><USER12> I'm not a knife guy and I'm not a foodie, but I did splurge on a knife made by the almazan kitchen guys on youtube - it's a knife but it's very tall. It's over twice as tall as a regular chef's knife but the same length, and I use it as a scraper, and to transfer bits across the kitchen to the stove, and just generally love the hand feel of it. I haven't been able to find this shape anywhere else. It's almost like a clever, but it's thin, has a nice rocking motion, and fits my hand perfectly. It's not even that great of a knife, it's hard to keep it super sharp, but it's still my favorite knife in the kitchen.

<comment><USER13> That sounds like a Chinese knife (often wrongly called cleaver - it's not meant for chopping).

[https://www.seriouseats.com/2019/12/chinese-cleaver- kitchen-...](https://www.seriouseats.com/2019/12/chinese-cleaver-kitchen- knife.html)

</comment></comment><comment><USER14> I've been using budget Victorinox for about 15 years, and they're still going strong. If you sharpen them regularly, use a steel, and don't do anything too crazy with them... Most modern knives will do an excellent job in the kitchen. The key is finding the ones that feel good in your hand, I think.

<comment><USER15> I have a few of the victorianox lineup and they are great! I was told by numerous people that if you are not going to spend 250+ don't bother and get a victorianox.

I love the set I have.

</comment></comment><comment><USER16> I take issue with his characterization of wedding knives as bling. For many younger couples, they replace a collection of stamped knives and yard sale finds, so they are a qualitative upgrade. They often get used a lot, as families cook more than singles, so they are probably one of the more intensively used gifts.

Finally, they act as a commitment device and a symbol of being married - singles and unmarried people rarely have a matching knife set. Sort of like wedding rings, which aren't usually purchased for their own blinginess, but as a symbol.

Over the course of a 20000 day marriage, an extra 200$ isn't going to make much of a difference

</comment><comment><USER17> I'm no culinary artist but I got a set of Kitchen Aid brushed stainless steel knives that have served us well. I love the built-in sharpener that comes as part of the wood block.

Not only do they look nice, but the fact that they have no separate material for the handles (they are 100% metal) means that they won't be breaking or getting stained and we can throw them in the dish washer if we want.

[https://www.amazon.com/KitchenAid-KKFSS14BO-Classic- Brushed-...](https://www.amazon.com/KitchenAid-KKFSS14BO-Classic-Brushed- Stainless/dp/B01DKR4KJ6)

</comment><comment><USER18> FWIW, my wife and I cook a lot, and the best knives we've found so far are Victorinox knives from Amazon. These replaced a much more expensive set that would get dull within a week and was otherwise unremarkable. They are stainless, not too heavy, and they keep their edge really well. $85 for a set of 3, although I recommend getting their santoku as well. Touch them up with $10 Accursharp sharpener every now and then, and you can't really do much better. Although they certainly aren't a showpiece - just a practical, high quality knife set.

</comment><comment><USER19> My favorite three kitchen knives are a stainless paring knife with a sheath they gave me for speaking at PyCon Argentina a few years ago, a cheap cubic zirconia paring knife I had to buy a diamond hone to resharpen after I dropped it and broke the tip off, and a scabby-looking French-style full-sized kitchen knife I found buried in the garden and resharpened with concrete and broken ceramic. It's a hardened carbon steel and holds an edge better than the stainless knife.

<comment><USER20> > _full-sized kitchen knife I found buried in the garden_

Um… Maybe my imagination is running away with me, but I struggle to find a sensible reason for burying a large knife in the garden.

<comment><USER19> I suspect the previous owner had a knife she didn't know how to sharpen and wanted to supplement the iron in the soil for the nasturtiums.

<comment><USER21> Or it was a murder weapon.

<comment><USER19> Seems a lot less likely. She's a well-known actress; I doubt she ever killed anyone, even in self-defense. There just aren't enough murders around here to make it a reasonable guess.

<comment><USER21> Yeah, don't think it's a given (and you have more context to determine that). It's just what comes to mind when hearing/reading about a buried knife (i.e. something you don't typically bury & could be evidence in a crime case).

</comment></comment></comment></comment></comment></comment><comment><USER22> While I definitely see the effects of that phenomenon, such as someone I know splurging on a beautiful Damascus steel knife. Then I read through to the bottom and turns out that I was just as much part of this phenomenon with my $100 Wusthof knife.

However, in defense of my claim that it's not _just_ bling, it's my daily workhorse knife for cooking at home, and it's the only chef's knife I own. It sees more use than any other knife I own. That said, I definitely stake some claim of my identity in my choice of brand and the knife's appearance, so it's definitely not purely functional.</comment>


Can Ethics Be Taught [in Business Schools]? - <AUTHOR> http://www.businessethics.ca/blog/2009/11/teaching-ethics-in-business-schools.html

<comment><USER2> Great post.

IMHO, the answer is a definite _Yes_ : ethics can be taught. The further removed from the humble worker the management becomes, the greater the risk of unethical behavior. It's all about structure. The reason our economy (USA) busted in late 2008 is because the "management" class of people became too disembodied from the standard middle-class worker.

 _The first problem is that Orwin neglects that the main goal of business education is to teach people management skills. So we can usefully teach people to devise management structures that minimize wrong-doing on the part of their employees, even if we can't change the characters of future managers themselves._

It's not about changing "character" so much as allowing transparency in the process and what's expected. It's very interesting to observe who totally freaks out over policy and such that promotes transparency . . . cliques and class-stereotypes dissolve under the lens of transparency.</comment>


What are your goals for 2009? - <AUTHOR>

My major goal is to do a better job balancing family, work and exercise. <comment><USER2> successfully relocate to atlanta for my job and try to hit the startup scene there.

improve my fitness, which has been going downhill a bit in the last month or so due to injuries and holidays.

launch a project and get it to profitability.</comment>


Straight from Detroit  - <AUTHOR> http://techcrunch.com/2012/04/09/valley-to-detroit-motor-city-woos-laid-off-yahoo-employees/

<comment><USER2> Ann Arbor is a much better choice. Detroit is not a good place to move. There isn't much left and it's not very safe.</comment>


Objective-C vs Lua - <AUTHOR> http://od-eon.com/blogs/tudor/lua-vs-obj-c/

<comment><USER2> Kneejerk criticism first.

First question I asked myself: What does programming the Smalltalk-style message sending interface look like? What does [dict setObject:x forKey:y]; look like?

It looks like this:

dict:setObject_forKey(x, y);

Well.. okay. I know some people dislike the message sending syntax, but the API is written for that syntax. This is verbose, but readable (if you're familiar with Cocoa):

\- (NSIndexPath _)tableView:(UITableView_ )tableView targetIndexPathForMoveFromRowAtIndexPath:(NSIndexPath _)sourceIndexPath toProposedIndexPath:(NSIndexPath_ )proposedIndexPath;

This, on other hand...

function tableView_targetIndexPathForMoveFromRowAtIndexPath_toProposedIndexPath(tableView, sourceIndexPath, proposedIndexPath);

...is... not winning the fight, let's say.

Second: what on earth is this:

      function crunchCookie(self, sender)
      	self.button = self:view():viewWithTag(1)
    	self.button:setImage_forState(UIImage:imageNamed('cookie-crunched.png'), UIControlStateNormal)
    	self.label = self:view():viewWithTag(2)
    	self.label:setHidden(false)
      end

Is this Android programming now? Do I have to fish my widgets out by hand?

Anyway, this still looks pretty cool. Hooking up a garbage collected scripting language on top of Obj-C with minimal memory overhead is awesome.

<comment><USER3> I know it is a personal thing, but I actually like the Smalltalk-style message system. I don't spend as much time look things up. It is interesting now that iOS gains enough popularity to attract enough people who prefer C/C++ style message syntax. Apple did the property thing to help, but It still feels a little weird.

</comment></comment><comment><USER4> \- If you remove the boilerplate, you can likely get the Objective-C version down to about 40 lines.[1]

\- Can Lua/Wax not use IB? The Objective-C version uses IB to lay the views out, while the Lua version seems to lay it out manually? It does for the main UIWindow, at least.

\- The Objective-C and Lua code don't behave the same way. This isn't a 1:1 comparison.

1\. Less, if you turn your AppDelegate into a UIApplication subclass (so it is a singleton, and you can not worry about dealloc in there because the app will be gone by the time dealloc is reached).

<comment><USER5> I was going to disagree with you about the boilerplate until I actually looked at the article, and you're right, it's just silly that the the Objective-C version gets about 10 additional methods that serve no real purpose.

<comment><USER6> The author must not be very experienced with iOS development because you can simply ignore all those extra empty methods if you do not wish to implement them.

It is really not fair to compare a verbose standard project template from Xcode with a a condensed Lua version.

<comment><USER7> It is only 'not fair' if the number of lines of code is important. Only the most naive programmers think that LOC actually means anything.

If you were really keen, you might consider which of the lines were authored by the programmer, and which were inserted by the tool 'auto-magically'.

In that case, Objective-C may actually come out ahead in this example!

Of course, I don't know how much of the Lua code was boilerplate supplied by the toolchain, all that stuff about twiddling the bounds and the frame might be boilerplate. In _that_ case, the actual amount of code written by both would be almost exactly the same.

And then we get onto secondary claims, e.g. benefits of garbage collection. (See the pretty graph)

Lastly we could compare them on 'prettiness' of code. Objective-C is quite ugly, but 'underscorising' the function names doesn't improve it much if at all.

\-----

So overall everything is equal apart from the garbage collection/memory usage thing which tips the scales in Lua's favour.

Now, on iOS the speed can be a big issue, so knowing if there is a performance penalty that comes with that is a big deal, which I don't see covered in the article.

<comment><USER6> """And then we get onto secondary claims, e.g. benefits of garbage collection. (See the pretty graph)"""

The pretty graphs are actually very misleading.

The graphs that drop down in the Lua version actually show the system load and not memory usage. So it shows _nothing_ about garbage collection.

If you look at the process list in for the Objective-C version you can see that some other process, 'installd', is hogging most of the CPU.

I bet the author was syncing with iTunes or installing some software while running these tests.

What you can see in the Instruments screenshots is that the Lua version uses about 200KB more memory for the 'same' application.

<comment><USER8> Yes - it's pretty obvious that that CPU graph is not accurate.

</comment></comment></comment></comment></comment></comment><comment><USER9> People often complain about the verbosity of objective-c, but if you have a method that takes several parameters, how is

foo (a, b, c, d) memorable? You have to remember the order of parameters, and the function name rarely makes this obvious, so unless you use this func all the time, you end up reading the docs.

fooWithBarAndBlatAndFazAndFooz(a,b,c,d) makes the parameter ordering obvious, but is to me less readable than:

fooWithbar: a blat: b faz: c fooz: d

Which is just about as concise as you can get. Of course it would be "nice" if objective-c allowed for parameter order to not be meaningful, but that would require dictionaries of parameters, instead of what really happens, translation to a function with a fixed parameter list, which is pretty efficient.

Message passing syntax looking initially complex is a lazy reason to dump an entire system when the alternative has much worse integration and support.

<comment><USER10> You can't create an "easy to use" function if you name it foo and you name your variables a, b, c and d or blat or faz or whatever.

"Which is just about as concise as you can get. Of course it would be "nice" if objective-c allowed for parameter order to not be meaningful, but that would require dictionaries of parameters, instead of what really happens"

It's pretty easy for the compiler to look at the param name at the call site and compare it to what was declared. No dictionaries needed at run-time.

</comment></comment><comment><USER8> Looks very nice, and god knows it would be nice to have a next generation replacement for obj-c, but...

1\. Obj-c may be verbose but XCode 4 does a lot of the heavy lifting with templates, snippets, and auto-completion, not to mention the continuous feedback on errors. It doesn't _feel_ anywhere near as heavy as it looks. How much of that is available in LUA?

2\. What does the picture look like when you want to access C api's and not just send messages? One of the most positive aspects of Obj-C is that you can use C libraries directly without either performance or code overhead - e.g. OpenGL, CoreGraphics, not to mention all manner of OSS C-libraries.

<comment><USER11> I share your reservations about the loss of XCode functionality. The verbosity of Obj-C and the Cocoa APIs is mitigated to a large degree by code completion and integrated documentation. Losing that, the visual debugger, and, presumably, the tight integration with Instruments would be a big productivity loss.

<comment><USER8> Right - also there doesn't seem to be a story for closures and GCD.

</comment></comment></comment><comment><USER12> I must say I didn't like the authors cocksure attitude that "Most of the people dislike the syntax of Obj-C and it does slow down development".

And also, the whole discussion turned into a discussion about exactly how dynamically typed something is, and that feels quite irrelevant to what he tried to show.

</comment><comment><USER13> With the underscores, Wax looks a bit like PyObjC or RubyCocoa. Lua is a fun language, so I will certainly give it a try. I would love to see a Framework in MacRuby, as I think Ruby, as a true Object Oriented language, may be better suited to Cocoa/IOS development. But this is certainly a project to watch.

</comment><comment><USER14> Sounds like Cycript (<http://cycript.org>), but Cycript allows messages to be written in Objective-C syntax rather than underscore-ized, which makes using Cocoa not so painful.</comment>


Seth's Blog: When execution gets cheaper, so should planning - <AUTHOR> http://sethgodin.typepad.com/seths_blog/2012/04/when-execution-gets-cheaper-so-should-planning.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+typepad%2Fsethsmainblog+%28Seth%27s+Blog%29 <comment><USER2> That's not the sufficient advice. The real advice would be - what to do when you've build it and it doesn't work as expected. And that's something what should be planned or you will loose time roaming in the darkness.</comment>


Succulent Poaching in California - <AUTHOR> https://www.sfgate.com/science/article/poaching-dudleya-succulent-norcal-plants-china-13704017.php <comment><USER2> > Though altogether unremarkable as far as flora goes, Dudleya farinosa has > captured the hearts of Chinese, Korean and Japanese collectors, some of whom > are willing to pay upwards of $50 for a single plant, officials said.

The article doesn't mention it, but when flowering the plant is spectacular. I've seen the biggest stretches along the coastal section of Route 1 south of Big Sur. Around June is the time IIRC.

[https://en.wikipedia.org/wiki/Dudleya_farinosa](https://en.wikipedia.org/wiki/Dudleya_farinosa)

<comment><USER3> I think I've got one of these in a planter on my back balcony. There is something alien and amazing about the flowering of succulents. If you're in Southern California (or planning a visit), I highly recommend the Huntington Library and Gardens (near Pasadena), where they have a magnificent collection.

On that topic, I'm going to take this opportunity to quote one of my favorite passages from Walter Pater, from the beginning of his essay on Michelangelo, since I don't know when I'll next have the opportunity to do so (at least here on Hacker News):

 _Critics of Michelangelo have sometimes spoken as if the only characteristic of his genius were a wonderful strength, verging, as in the things of the imagination great strength always does, on what is singular or strange. A certain strangeness, something of the blossoming of the aloe, is indeed an element in all true works of art; that they shall excite or surprise us is indispensable._

[https://www.gutenberg.org/files/2398/2398-h/2398-h.htm](https://www.gutenberg.org/files/2398/2398-h/2398-h.htm)

</comment></comment><comment><USER4> >When pressed, the man reportedly told the woman the packages contained something "very valuable," while pointing to the ocean.

Not the brightest poachers..

<comment><USER5> I don't think he realized he was doing anything wrong.

</comment></comment><comment><USER6> Some time ago I received as a gift from a friend a similar species with fiery red leaves. It was fake of course. The poor thing was painted in red, (spray painted with aerosol cans), to mimick red leaves. The plant is suffocated by the treatment and dies normally shortly the after purchase, but I could save mine removing the plastic coat with a lot of patience.

Mexican street flower sellers practice a few notorious scams. The oromelia for example with a huge (and a little repulsive) fake flower made with carboard and sewed carnation petals. Is an interesting world.

</comment><comment><USER7> Similar incidents threaten succulent plants of the genus Haworthia, largely endemic to South Africa. These plants have a stunning amount of variation and features which make for interesting hybrids: things which make them attractive to hobbyists and succulent gardeners. Rare Haworthia specimens are commonly grown in commercial nurseries or even by tissue culture labs, though many exotic species are still discovered in nature. Many are removed from their habitat illegally, put up for sale on eBay for hundreds of dollars.

</comment><comment><USER8> Has anyone just considered farming these?

<comment><USER9> _Dudleya farinosa is easily purchased from a number of native plant sellers in California. At Yerba Buena Nursery in Half Moon Bay, you can buy a gallon — yes, a gallon — of Dudleya for $20. But that 's not what international collectors appear to be after. According to a Press Democrat investigation, "large, wild-harvested Dudleya are considered luxury items ... Imperfections inflicted by the elements are a plus."_

\-- TFA

</comment></comment><comment><USER10> Beware, the sfgate.com site messes with your browser history and back button. I still regard such design as wrong-headed and bad.

</comment><comment><USER11> Site breaks back button.

</comment><comment><USER12> fossils were the only thing to make sense to me in this fucked up world

<comment><USER12> No love for Adaptation? [https://www.youtube.com/watch?v=mdYIqSZblv0](https://www.youtube.com/watch?v=mdYIqSZblv0)</comment></comment>


The 4G speeds AT&T is bragging about are actually slower than their 3G speeds - <AUTHOR> http://www.pcmag.com/article2/0,2817,2381915,00.asp?r=2

<comment><USER2> Upload is slower; 4G download actually faster thatn 3G so take this with a grain of salt.

</comment><comment><USER3> I wonder if government institutions will be connected to this some day? If so that makes me think about how easy it would become to cut the general public internet off without interrupting your own operations.</comment>


Ask HN: Founders, how much time do you spend on your startup per week? - <AUTHOR> I had a conversation with a friend who said they worked 12 hrs/week on their company when they were raising money, he was too depressed dealing with a lot of rejection to do more than that.  Three years later got an offer to sell the company for $250 mm, which he turned down.  He was a lot more productive after he finished the fundraising :)
I find myself in the office working on my bootstrapped internet business around 45 hours per week, putting in another 1-2 hrs/day at home, a few hours on the weekends, all of which adds up to 8-12 hours of "deep work" per week given the emails/calls I have to do.
I'm curious how much time other founders dedicate to their startup, along with how much time they spend on "deep work" in the course of a week. <comment><USER2> Most weeks (especially during climbing season or when travelling} I spend maybe 2 hours in total doing customer support and keeping things running. I can ramp that down to zero for a while if necessary, without much in the way of consequences.

That's by design, since the entire goal operation was to maximise my free time.

When I'm building out a new feature (and when building the thing in the first place) I'll sometimes push up closer to 20 hour weeks.

As one could imagine, I've never got behind this concept that building a product should involve 80 hour weeks and burning down your life until the day somewhere down the road when you "make it". Life needs to happen while you're living it, and happily I've found that one can build a profitable software business by launching early and building at a comfortable pace.

<comment><USER3> Do you by chance need a business parter (aka me?)? Think about it! You could cut down the hours you spend in half, and at the same time earn a climbing partner!

It's a win-win for both of us!

</comment></comment><comment><USER4> Running ManyPixels, mostly doing Sales/Management/Culture/Hiring -- I divide my time in 2-3 blocks of 2 hours per day on each and leave a lot of time on weekend to think about the bigger picture. This could be considered as work.

I use my calendar a lot and every morning I start with 2 hours of sales and it built me a habit, and I become more efficient at doing it.

I would say on average 40 hours per week.

<comment><AUTHOR> Thanks for sharing, I like the structure.

</comment></comment><comment><USER5> I spend 30 minutes per week on my solo "lifestyle biz" (minutes, not hours). Built up a large target audience over 10 years working at most 20 hours per week. now I'm coasting, doing $500k profit/year. You don't have to kill yourself to do well. I don't know how to code either, it's been mostly through content marketing and lead generation.

<comment><AUTHOR> How did you build the audience?

What sort of biz is it?

</comment></comment><comment><USER6> 60-70 hrs/week. Typical 9-5 with a few hours each night and some long stretches on Saturday/Sunday.

I'm all in favor of work/life balance, but, in my experience, an early stage founder simply can't give less. Markets move too quickly and there's too much to be done.

</comment><comment><USER7> I am a solo bootstrapped founder (like yourself) and RescueTime consistently shows 45 to 50 hours per week.

I strongly believe WHAT I do in those ~50 hours is much much more important than squeezing in another 10-20 hours per week.

<comment><AUTHOR> Completely agree. You can work 80 hours and get less done than an efficient person doing 40.

</comment></comment><comment><USER8> Somewhere between 30-60 hours per week on my startup, on top of my regular 9-5. I'm a solo founder/dev so working on the site takes up a lot of my time.</comment>


Ford First Automaker to Test Autonomous Cars in Winter Weather, Snow - <AUTHOR> https://recode.net/2016/01/10/ford-says-its-the-first-carmaker-to-test-self-driving-cars-in-the-snow-but-google-has-too/ <comment><USER2> BBC story:

[https://news.ycombinator.com/item?id=10881563](https://news.ycombinator.com/item?id=10881563)</comment>