Cryptographic Right Answers - <AUTHOR> https://gist.github.com/tqbf/be58d2d39690c3b366ad <comment><USER2> > If you can get away with it: use SHA-512/256, which truncates its output and > sidesteps length extension attacks.

Note that "SHA-512/256" is a separate algorithm, not to be confused with "SHA-512 or SHA-256" which are two other less secure algorithms.

<comment><USER3> Unless you know something about SHA-512 that I don't, calling it less secure than SHA-512/256 seems like a mistake.

<comment><USER4> SHA-512 allows a length extension attack that SHA-512/256 does not. Some links:

[http://en.wikipedia.org/wiki/Length_extension_attack](http://en.wikipedia.org/wiki/Length_extension_attack) [http://cryptopals.com/sets/4/challenges/29/](http://cryptopals.com/sets/4/challenges/29/)

<comment><USER3> First off, thanks for the reply.

I have to say it feels a bit weird to deduct points (so to speak) from a highly regarded cryptographic hash function because it doesn't outright prevent one particular, broken MAC generation scheme, but I guess the argument has some merit.

While I think it's harmless to say that SHA-512/256 is stronger than SHA-256 (as they otherwise provide the same theoretical level of security), I still think it's wrong to claim that SHA-512/256 is also stronger than SHA-512, which has a vastly greater theoretical security margin.

Just use a MAC algorithm that isn't terrible.

<comment><USER5> Susceptibility to length extension would also have disqualified SHA2-512 from SHA-3, where that property was a requirement, so it seems like the cryptographic community has come to conclusion about this.

The "security margin" of a full SHA2-512 digest, over its truncated SHA2-512/256 alternative, is not meaningful in practice.

If you want to use full-width SHA2-512, go ahead. SHA2-512/256 is safer.

</comment></comment></comment></comment></comment><comment><USER6> > Password handling (Was: scrypt or PBKDF2): In order of preference, use > scrypt, bcrypt, and then if nothing else is available PBKDF2.

What's the reason to prefer scrypt over bcrypt? And, what's the reason to prefer both over PBKDF2? (Asking because I see quite a few bits of software that use PBKDF2.)

> Asymmetric signatures (Was: Use RSASSA-PSS with SHA256 then MGF1+SHA256 > yabble babble): Use Nacl, Ed25519, or RFC6979.

Could you make a recommendation for or against using GPG, since that's by far the most common approach for asymmetric signatures? (Obviously such a recommendation would need to point at specific key/algorithm choices to use or avoid.)

> Client-server application security (Was: ship RSA keys and do custom RSA > protocol) Use TLS.

Using which of the many TLS implementations?

<comment><USER7> _What 's the reason to prefer scrypt over bcrypt?_

scrypt is asymptotically much more expensive to crack.

 _And, what 's the reason to prefer both over PBKDF2?_

scrypt is asymptotically much more expensive to crack.

bcrypt is asymptotically marginally more expensive to crack than PBKDF2, but not enough to matter; I'm guessing tptacek's point here is that bcrypt has more library support available (despite PBKDF2 being the _de jure_ standard). I wouldn't say there's a strong argument in either direction.

 _Could you make a recommendation for or against using GPG, since that 's by far the most common approach for asymmetric signatures?_

Avoid if possible. The code was written by a colony of drunk monkeys, in an era before anyone understood the basics of modern cryptography; I'm really not sure which is worse between gnupg and OpenSSL. Of course, GPG is the standard for encrypted email, just like SSL/TLS is the standard for web sites, so you may have no choice...

(FYI: [https://vuxml.freebsd.org/freebsd/pkg- gnupg.html](https://vuxml.freebsd.org/freebsd/pkg-gnupg.html) )

<comment><USER6> > Avoid if possible. The code was written by a colony of drunk monkeys, in an > era before anyone understood the basics of modern cryptography; I'm really > not sure which is worse between gnupg and OpenSSL. Of course, GPG is the > standard for encrypted email, just like SSL/TLS is the standard for web > sites, so you may have no choice...

Are there any viable FOSS implementations of the OpenPGP standard other than GPG? Detached GPG signatures seem to be the most common mechanism to validate software distribution and similar.

<comment><USER8> Has anyone checked [https://github.com/google/end-to- end](https://github.com/google/end-to-end) ? I want to believe google did their due diligence.

</comment></comment></comment></comment><comment><USER9> Considering the recommendations for NaCL, what is the current status of it? There is NaCL proper and its webpage has link to a 2011 version. Then there is TweetNaCL which seems more recent with a 2014 release. And finally there is libsodium which is not from DJB. What is the recommended version to use? I'd guess TweetNaCL because it is most recent, but idk.

On a slightly related note, I just noticed that there is also µNaCL for embedded use that seems really cool.

<comment><USER5> The current state of it is that Nacl (pronounced: "turnips") circa 2011 is just fine, Tweetnacl is just fine, and if you have packaging concerns, you can use libsodium --- but stick to the constructions that are also in Nacl/Tweetnacl, because libsodium took things a little further than I think they should have.

<comment><USER10> Could you elaborate on what you think shouldn't have been included in libsodium? I'm very interested in this, as someone who uses libsodium.

<comment><USER5> Anything that libsodium does, or allows clients to do, that Nacl doesn't allow you to do.

Nacl isn't an open source project or helpmate for application programmers; it's an academic effort to design the best misuse-resistant crypto interface for programmers. I like libsodium, but it is not that.

</comment></comment></comment></comment><comment><USER11> > If your threat model is criminals, prefer DH-1024 to sketchy curve > libraries. If your threat model is governments, prefer sketchy curve > libraries to DH-1024. But come on, find a way to one of the previous > recommendations.

I got a serious chuckle out of this. :)

</comment><comment><USER12> Pardon my ignorance, but is the NaCl referred to in the gist this NaCl? [http://nacl.cr.yp.to/](http://nacl.cr.yp.to/) Or does it refer to libsodium here? [https://github.com/jedisct1/libsodium](https://github.com/jedisct1/libsodium)

I realize that the library is probably available via my package manager, but it'd be nice if the install page ([http://nacl.cr.yp.to/install.html](http://nacl.cr.yp.to/install.html)) linked to an archive over HTTPS and had some signatures to compare hosted elsewhere.

<comment><USER11> Yes to the first question. Libsodium is a fork of NaCl and it even says so in the description.

</comment></comment><comment><USER13> AES-GCM allows the caller to supply additional authenticated data (AAD) -- data that is only authenticated but not encrypted. However NaCl's authenticated encryption mode doesn't seem to provide anything like this: [http://nacl.cr.yp.to/secretbox.html](http://nacl.cr.yp.to/secretbox.html)

So when I have AAD, what should I do when using NaCl? Add it as part of the message to crypto_secretbox(), or should I authenticate this data separately?

<comment><USER14> You could use libsodium instead of NaCl, which has an AEAD interface:

[https://download.libsodium.org/doc/secret- key_cryptography/a...](https://download.libsodium.org/doc/secret- key_cryptography/aead.html)

<comment><USER15> Unfortunately that interface is rather dangerous because of the 64-bit nonces - it is essentially only useful for encrypting multiple messages over a single connection.

</comment></comment></comment><comment><USER16> The lack of justifications makes this as useful as anybody else out there claiming "use X. Don't use Y".

Eg: > Avoid: AES-CBC, AES-CTR by itself, block ciphers with 64-bit blocks --- most especially Blowfish, which is inexplicably popular, OFB mode. Don't ever use RC4, which is comically broken.

Why not 64-bit blocks? What's wrong with them? How do they affect us?

Mind you, I'm not saying the statement is incorrect, but with no justification for it, I'm not convinced why I should avoid them.

<comment><USER5> I mean this sincerely and not as snark: if this is a question you have to ask, just use Nacl; don't design with ciphers yourself. Since there is a "right answer" to this question and a "wrong one", "convincing" doesn't seem like a good use of anyone's time.

The right way to learn about cryptography is to start by learning how to break it. If that's something you're willing to sink time into, try this thing we set up:

[http://cryptopals.com](http://cryptopals.com)

It's totally free and by the send of set 3, you'll have an appreciation for block sizes.

<comment><USER11> Hey Thomas, does anyone at Matasano still review submissions if someone wants to submit them for a particular programming language? I'm looking to establish myself as the luminary crypto nerd of the furry fandom :3

<comment><USER5> I don't know why you got downvoted. Maybe it's the furry thing. Cryptopals is still ongoing (there's a set 8 in the works, all elliptic curve attacks). As for posting the solutions: we're doing that, too, in the abstract, but we're all busy and every time we bring it up a bunch of people say "noooo don't post solutions".

<comment><USER11> Heh. Haters gonna hate.

Okay, very glad to hear that there's still work being done on that end. I'll start sending solutions in then :3

</comment></comment></comment></comment></comment><comment><USER7> Since this is heading towards the top of HN, I figure it's worth responding to the specifics here:

 _AES-GCM_

As tptacek says, this has pitfalls on some platforms. I also dislike exposing AES cores to malicious data, which is my primary reason for preferring a hash- based MAC construction.

 _Avoid: key sizes under 128 bits._

My recommendation for 256-bit symmetric keys isn't because I think AES-128 can be broken mathematically; rather, it's because AES implementations have a history of leaking some of their key bits via side channels. This is less of an issue now than it was five years ago (implementors have found and closed some side channels, and hardware AES implementations theoretically shouldn't have any) but given the history of leaking key bits I'd prefer to have a few to spare.

 _Avoid: userspace random number generators_

Thomas and I have argued about this at length; suffice to say that, as someone who has seen interesting misbehaviours from kernel RNGs I'd prefer to use them for seeding and then generate further bits from a uesrspace RNG. (Thomas's counterargument, which has some validity, is that he has seen interesting misbehaviours from userspace RNGs. This largely comes down to a question of whether you think the person writing your userland crypto code is more or less prone to making mistakes than the average kernel developer.)

 _avoid RSA_

Thomas is correct to imply that a random RSA implementation is more likely to be broken than an average elliptic curve implementation. This is true for the same reason as a random program written in python is more likely to have bugs than a random program written in Brainfuck: Inexperienced developers usually don't even try hard problems. On the other hand, _for any particular developer_ , an RSA implementation they write is more likely to be correct than an elliptic curve implementation they write.

I also continue to be wary of mathematical breakthroughs concerning elliptic curves. Depending on the amount of new research we see in the next few years I might be comfortable recommending ECC some time between 2020 and 2025.

 _use NaCl_

This is not entirely a bad idea. The question of "implement yourself or use existing libraries" comes down to the availability of libraries and whether the authors of the library are more or less prone to making errors than you; "random developer vs. NaCl developers" is straightforward and doesn't have the same answer as "random developer vs. OpenSSL developers".

 _you discover that you made a mistake and your protocol had virtually no security. That happened to Colin_

Just to clarify this, the (very embarrassing) bug Thomas is referring to was in the at-rest crypto, not the encrypted client-server transport layer.

 _Online backups (Was: Use Tarsnap): Remains Tarsnap. What can I say? This recommendation stood the test of time._

I have to agree with Thomas on this one. ;-)

<comment><USER5> * If you're concerned about attacker data hitting the AES core, Salcha20+Poly1305 doesn't have that problem, and is generally preferable to AES-GCM in every scenario anyways. There is no scenario I can think of where you can do CTR+HMAC and can't do Salcha20+Poly1305. If you have to stick with standards-grade crypto, GCM is your best bet.

* The track record of userspace RNGs vs. kernel RNGs speaks pretty loudly. In any case, we should be clear that you're advocating for "bootstrap with /dev/urandom and then expand in-process", not, like, havaged or dakarand. We're closer on this than people think.

* I'm not even talking about people writing their own RSA. Do I need to say that? If so, recommendation #1: don't write your own RSA. I'm saying that all else equal, if you're using good libraries, _still avoid RSA_ , for the reasons I listed.

* In fairness, the CTR problem you had is also a threat to GCM. This used to be why I recommended CBC a few years ago: because we kept finding gameover CTR bugs in client code, and not so often CBC bugs. My opinion on this has changed completely in the last year or so.

<comment><USER7> _If you 're concerned about attacker data hitting the AES core, Salcha20+Poly1305 doesn't have that problem, and is generally preferable to AES-GCM in every scenario anyways._

Right. And I'm optimistic about Salcha20 and Poly1305, but I'd like to see a few more years of people attacking them before I would be willing to recommend them.

 _we should be clear that you 're advocating for "bootstrap with /dev/urandom and then expand in-process"_

Right. Or to be even more precise: Use HMAC_DRBG with _entropy_input_ coming from /dev/urandom.

Also: For $DIETY's sake, if you can't read /dev/urandom, _exit with an error message_. Don't try to fall back to reading garbage from the stack, hashing the time and pid, or any other not-even-remotely-secure tricks. Denial of service is strictly superior to falsely pretending to be secure in almost all conceivable scenarios.

</comment></comment></comment><comment><USER17> One problems I have with most cryptographic libraries, like OpenSSL and NaCl as recommended here, is their extensive use of globally mutable variables. I can't understand how that seems a good idea in 2015.

</comment><comment><USER18> > Avoid: offbeat TLS libraries like PolarSSL, GnuTLS, and MatrixSSL.

I'm interested to hear the rationale behind this. Those seem like reasonable options considering OpenSSL's (and their) security history.

<comment><USER5> I've reviewed the code of several of these libraries (I won't say which ones I have which levels of confidence in), and: short summary: if you want to be the site that reincarnates 1990s RSA bugs or 2000's-era curve bugs, go ahead and use a TLS library nobody else uses.

<comment><USER6> PolarSSL and MatrixSSL definitely seem far off the beaten path, but _many_ projects use GnuTLS (both as one of the more well-known non-OpenSSL codebases and because it has a GPL-compatible license). I'd be interested to know if you're concerned about it in particular.

<comment><USER19> There was a GnuTLS vulnerability introduced in 2000 was discovered in 2014 due to an audit. To summarize there was a refactoring that had no accompanying test coverage that had the effect of inverting a check.

Bugs happen to everyone, but the process that led to this one is really concerning. (OpenSSL certainly has bad process too but as the GP mentions, more people are hammering on it.)

This blog post has more (including an LWN article about it):

[http://gehrcke.de/2014/03/gnutls-vulnerability-is-unit- testi...](http://gehrcke.de/2014/03/gnutls-vulnerability-is-unit-testing-a- matter-of-language-culture/)

<comment><USER6> Every security library has had vulnerabilities, and I'd be more concerned about libraries that _don 't_ (since it implies nobody is looking). Does GnuTLS seem significantly more prone to vulnerabilities than other implementations?

<comment><USER5> I would flag use of GnuTLS in an audit. Sev:lo.

<comment><USER6> What would you recommend that _isn 't_ derived from the OpenSSL codebase, for C projects that can't use OpenSSL for license reasons?

Your recommendation for TLS elsewhere in the thread was:

> You should use BoringSLL, LibreSSL, Go crypto/tls, or OpenSSL, in roughly > that order.

Three of those are based on OpenSSL, and Go crypto/tls presumably only works with Go.

<comment><USER5> Porting to Windows and using schannel.

Sorry.

<comment><USER6> Guess I'll be sticking to GnuTLS then, if there's no better option available for GPLed projects to use.

<comment><USER20> Another option is wolfSSL ([https://wolfssl.com/wolfSSL/Home.html](https://wolfssl.com/wolfSSL/Home.html)) which is GPL-compatible, but also has a commercial license option. They have an OpenSSL compatibility layer, but are not a derivative of OpenSSL.

My experience with their software has been very positive, and they have avoided the majority of recent insecurities. Plus they have great support for anyone working on open source projects.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER21> For reference, Colin's 2009 "Cryptographic Right Answers" blog post is here: [http://www.daemonology.net/blog/2009-06-11-cryptographic- rig...](http://www.daemonology.net/blog/2009-06-11-cryptographic-right- answers.html)

</comment><comment><USER22> > _Avoid: constructions with huge keys, cipher "cascades"_

Can anyone please explain what's wrong with e.g. 4096 bit keys (instead of 1024 bit) and piling 2-3 different or same encryption passes? Performance implications are obvious; what are security implications?

<comment><USER7> This is in the context of symmetric keys, so I'm guessing "huge keys" is a reference to the fact that "448-bit crypto" is a giant red flag because it screams "we're using blowfish".

<comment><USER5> See I just write 1/5th of a recommendation and leave it open-ended so Colin or 'pbsd can make it look like I was smart to begin with. Yeah... Blowfish... that's what I meant... :)

<comment><USER7> Well, in the more general case "huge symmetric keys" is a flag for "doesn't understand crypto", but 448-bit blowfish keys are the most common place I see this happening.

</comment></comment></comment></comment><comment><USER23> > There is a class of crypto implementation bugs that arises from how you feed > data to your MAC, so, if you're designing a new system from scratch, Google > "crypto canonicalization bugs".

I get a whole bunch of links about javax.xml.crypto.dsig throwing exceptions, which wasn't terribly illuminating.

I think the reference is to the bugs discussed on page 21 here: [http://www.contextis.com/documents/33/Exploiting_XML_Digital...](http://www.contextis.com/documents/33/Exploiting_XML_Digital_Signature_Implementations- HITBKL20131.pdf) but I'm not sure.

<comment><USER24> It boils down to this:

Make sure the data fed to your MAC is unambiguous. Or rather, make sure the data fed to your MAC is done in such a way that you cannot have different messages appear the same to the MAC encoder.

For instance, say you sort and concatenate your options without a delimiter. Then ["ab", "cd"] will have the same MAC as ["a", "bcd"], as in both cases the actual data fed to the MAC will be "abcd". This is a very bad thing.

</comment></comment><comment><USER25> What if I need to send up encrypted logs from a number of clients? I tried to use nacl for this, but in its opinionated style, it holds that I have to have a sender private key to authenticate my logs, and it won't decrypt unless I provide the corresponding public key on the other end.

I don't want authentication here - there's no way for me to manage these keys; I just want to prevent someone from reading my logs off the disk...

<comment><USER26> Do you want symmetric encryption? NaCl does that too, it's just a section bellow the asymmetric ones on its documentation.

But I'm not sure you completely thought this out. If somebody can read your disk, and if that includes software configuration, the only way to make it impossible for people to read your logs is by using asymmetric crypto. And yes, that'll require using different keys on the writing and reading software.

</comment></comment><comment><USER27> "Asymmetric encryption (Was: Use RSAES-OAEP with SHA256 and MGF1+SHA256 bzzrt pop ffssssssst exponent 65537): Use Nacl.

You care about this if: you need to encrypt the same kind of message to many different people, some of them strangers, and they need to be able to accept the message asynchronously, like it was store-and-forward email, and then decrypt it offline. It's a pretty narrow use case."

Is this like bitmessage?

</comment><comment><USER15> Also:

For each key you use, pick 1 format of messages for it to authenticate. Document that format. Version-control that documentation along with the code that uses it. If the format changes in a non-back-compat way, pick a new key (so try to use a backwards-compatible format). Ensure the documented messages make sense (try not to have a "fire this person" message without knowing who is that person) - timestamps and/or nonces can really help here.

If you can't pick just 1 format, you can say have the first 16 bytes of the message be a UUID, and document each UUID-format (with the same documentation rules as if you are not using a UUID).

Seriously, that and "don't mix secret and unauthenticated things" together covers 90% of all vulnerabilities.

</comment><comment><USER28> Can anyone elaborate why we shouldn't use BouncyCastle?

<comment><USER29> The message here is avoid low-level crypto - if you find yourself having to mess around IV's or choosing modes and padding then you are far more likely to screw something up.

NaCl/libSodium provide higher level interfaces where the underlying primitives are removed from the developer which makes it much more difficult to implement bad crypto (at least as far as the individual constructs go...protocol design may still get you)

<comment><USER28> Ahh got it, thanks!

</comment></comment></comment><comment><USER30> Didn't notice at first that it was from Thomas Ptacek.

But still feels odd OP is sharing it since it was a secret link.

<comment><USER7> tptacek posted it to twitter, so I don't think it was secret.

<comment><USER11> Probably posted as a "secret" gist so as to not clutter up his gist history? That's the only reason I can imagine.

Or, more than likely, he had it as "secret" to get feedback from colleagues and other crypto folks before he published it.

<comment><USER5> Nope. This is literally just something I was going to twerp-storm, and then I thought, "I don't want to be that guy on Twitter" (any more than I already am), and so I found the least official place I could to put it.

<comment><USER7> ... and then it ended up at the top of HN anyway.

<comment><USER5> Leave Britney alone. She's not well.

<comment><USER7> I feel like I'm missing something here.

</comment></comment></comment></comment></comment></comment></comment><comment><USER25> Is there anything wrong with using haveged after the system has been up long enough to generate a seed the traditional way?

I occasionally use it to make /dev/random unblock for applications that think they need to use /dev/random to generate keys (cough gpg cough).

</comment><comment><USER31> _Avoid: ... SRP, J-PAKE, ..._

Are there any recommended schemes for password-authenticated key exchange?

<comment><USER5> Don't do password-authenticated key exchange.

<comment><USER32> And what about zero-knowledge password proofs in general? (I tend to agree that PAKE is bad idea, but I'm not sure if my reasons are same as yours)

In my opinion one should create encrypted channel essentially without any authentication and then do authentication inside of such channel, with ZKPP being one of the interesting ways of how to do that (with "plug password into scrypt and use the result as EdDSA secret key" being particularly straightforward solution), which obviously assumes that you have threat model where exposing password to server is meaningful security concern (usually it is not).

I've seen many systems where ZKPP is the right thing to do (such systems usually involve offline operation with multiple users using same device), but their authors came up with some weird-ass construction with bunch of symmetric primitives that is anything but secure.

</comment></comment></comment><comment><USER33> Hypothetically, if any weakness is found in Curve25519, what happens to NaCl users?

<comment><USER26> The same thing that happens to 2048 bit RSA users if yet another weakness is found on it. Or the same thing that happens on the users of the NIST curves if some weakness is found (or disclosed).

</comment></comment><comment><USER34> This article does plenty right but gets a few things wrong. Overlooks a few others. I'm going to hit on a few of these in order I see them.

"Avoid cipher cascades." I've pushed and successfully used cascades in highly assured work for years. Cryptographers talk down about it but "meet in the middle" is best attack they can cite. So, they're full of it & anyone who cascaded might have avoided many algorithm/mode breaks. My polymorphic cipher works as follows: three strong algorithms applied out of almost 10 potentials; algorithms are randomly selected with exception that each pass is a new algorithm; separate keys; separate, initial, counter values; process driven by a large, shared secret. Breaking it without the secret requires breaking all three and no cryptographer has proven otherwise despite massive speculation.

I'll briefly mention scrypt because it's _ironically_ great advice. I asked cryptographers for over a decade to deliver a slow-by-design hash function that couldn't be sped up. They, for years on end, criticized me (see Schneier's blog comments) saying it was foolish and we just need to iterate a fast one. I expected problems and hackers delivered them. I had to homebrew a cryptosystem that input a regular HMAC scheme into another scheme: (a) generated a large, random array in memory, (b) did impossible to speed up operations on random parts of it, (c) iterated that excessively, and (d) finished with a proper HMAC. Array size always higher than GPU or FPGA onboard memory in case opponents used them. Eventually in a discussion, a Schneier commenter told me about scrypt and I finally got to ditch the inefficient homebrew. A true outlier in the crypto field.

Avoid RSA: bad advice for commercial if NSA is opponent. All his risks are true. NaCl is great and my default recommendation. Yet, he doesn't mention that NSA has another reason for pushing ECC: they own 26 patents on it that they license conditionally on the implementation details along with ability to restrict export. We know what NSA's goal for crypto is and therefore I avoid ECC commercially like the plague. I just used RSA implementations and constructions pre-made by experts with review by experts. Esp GPG, as NSA haven't even broken it. They use it internally, actually.

For asymmetric signatures, see above. All points apply. I'll just add that, for post-quantum, there's been tremendous process in Merkle signatures with things such as unlimited signatures. Their security just depends on a hash function, there's no known quantum attacks on them, and they're doing pretty good against classical attacks, too. So, I'm following and doing private R&D on standardizing Merkle signatures plus hardware to accelerate it on either end.

He says use OpenSSL and avoid MatrixSSL, PolarSSL, etc. He said some vague stuff about their quality. Problem: anyone following the git comments of OpenBSD team that tore through OpenSSL knows that IT WAS S __*. It was about the worst quality code they 've run into with so much complexity and potential to be exploited that the NSA would be proud of it. I'd be surprised if Matrix, Polar, etc are worse and less structured than that. If OpenSSL is really the best, then we're in a bad situation and need to fund a clean-slate design by experts like Galois and Altran-Praxis.

Although I'm focused on problematic points, his last piece of advice deserves special mention: use TLS. These protocols have proven difficult to implement properly. TLS and their ilk have had many problems along with massive effort to smash them. Against that backdrop, it's actually done pretty well and using it like he suggests is best option for COTS security. Medium to high assurance systems can always use variants custom-designed for that level. Most don't need that, though.

<comment><USER5> The oddball TLS libraries do not have poorer "code quality" than OpenSSL, though they are not perfect and have received far, far less scrutiny than OpenSSL, so if you have to bet on which is going to have memory corruption, OpenSSL isn't a sure bet.

But my concerns aren't about code quality. They're cryptographic.

<comment><USER34> I appreciate you clarifying on that.

</comment></comment></comment><comment><USER35> Wow...so hard to keep up with best practices.

<comment><USER26> Best practices are:

\- Use OpenSSL with TLSv1.2 for TLS

\- Use Tarsnap for online backups

\- Use NaCl for anyhing else

\- Try not to use anything new that you invent before it's reviewed

</comment></comment><comment><USER36> Recommends openssl, ignores libressl exists at all.

</comment><comment><USER37> useful, but..

\- What about the correct password length ?

</comment><comment><USER38> It cracks me up that on Office 365, Microsoft has a Lync auto discover protocol that uses https but the certificates have name mismatches.

Then again, it cracks me up that Microsoft have https at all, given the protocol checks https and http when it goes to lyncdiscover.domainname

</comment><comment><USER39> > Random IDs (Was: Use 256-bit random numbers): Remains: use 256-bit random > numbers.

256-bit random identifiers are overkill. 122 random bits (as in a GUID) should still be more than sufficient. Size is important for IDs because people whine about the storage overhead. A 256-bit identifier requirement may unfortunately convince some people that it's better to use much smaller, non-random identifiers, and that'd be a shame.

<comment><USER40> The 256 bit advice is golden if only to encourage people to not use GUIDs in these scenarios.

GUIDs are unique--not necessarily unguessable. Any implementation may be using a CSPRNG but in general you shouldn't rely on that (unless its your implementation and its a documented behaviour.)

Honestly I've found this (perhaps pedantic) mistake to be highly correlated with other badness/sloppiness.

GUIDs are awesome, and can be used in plenty of places near crypto, like OAuth 1.0-style nonces, IDs for public keys... just don't use them for their "randomness".

<comment><USER39> Of course you have to be aware of your implementation. On Windows, UuidCreate returns unguessable GUIDs. (COM security depends on this property.) libuuid provides similar guarantees if /dev/urandom is available.

But anyway, my point wasn't that you should necessarily use GUIDs for unguessable IDs (although that's fine if you're using real randomness), but that 256 bits is overkill and that 128-ish is good enough.</comment></comment></comment>


Socat: "the hard coded 1024 bit DH p parameter was not prime" - <AUTHOR> http://www.openwall.com/lists/oss-security/2016/02/01/4 <comment><AUTHOR> It irks me that in security advisories that fix a _possible_ backdoor—like here—sometimes no root cause analysis is done or communicated to the public. Who chose this parameter? Who wrote the code? Who committed it? So I did a little sleuthing...

Here is the commit introducing the non-prime parameter (committed by Gerhard Rieger who is the same socat developer who fixed the issue today): [http://repo.or.cz/socat.git/commitdiff/281d1bd6515c2f0f8984f...](http://repo.or.cz/socat.git/commitdiff/281d1bd6515c2f0f8984fc168fb3d3b91c20bdc0)

The commit message reads: _" Socat did not work in FIPS mode because 1024 instead of 512 bit DH prime is required. Thanks to Zhigang Wang for reporting and sending a patch."_ So a certain Zhigang Wang presumably chose this prime. Who is he?

Apparently he is an Oracle employee involved with Xen and Socat. Here is a message he wrote: [http://bugs.xenproject.org/xen/bug/19](http://bugs.xenproject.org/xen/bug/19)

So why has Gerhard seemingly not asked Zhigang how he created the parameter?

<comment><USER2> I'm pretty sure that when you generate a prime you're using the Miller–Rabin primality test in which case you only probabilistically choose a prime.

In fact, the is_prime functions in openssl don't check if a number is prime. They only check that a number is prime within 1-2^-80 probability. I'm not sure what the implications are though.

See [https://www.openssl.org/docs/manmaster/crypto/BN_generate_pr...](https://www.openssl.org/docs/manmaster/crypto/BN_generate_prime.html)

<comment><USER3> 2^-80 is an incomprehensibly tiny number. Malice or incompetence are both FAR more likely.

<comment><USER4> You know, I never know what to make of that logic - what if that tiny probability was exactly this one time? It's not like we saw it happen twice, and it could happen at some point. To my gut it seems you can't really know until you have other positive or negative observations.

I wonder if someone has compiled a list of very improbable events that have been observed.

<comment><USER4> Wow - this has got to be my most downvoted comment. I can't edit the original anymore, so here's my update:

I guess the harsh reaction came from the fact that I didn't define the scope very well: My question wasn't in reference to M-R specifically, just in general. I understand that in this case it makes sense to look at likelier causes (see Sharlin's response).

My point was that it's interesting to look at what happens (or what our reaction is) when very very very improbable events do happen. It seems weird to go with the assumption that because something is extremely unlikely that it won't happen.

When I roll a dice 20 times, I get a particular arrangement of numbers. Given the total number of arrangements possible, that particular arrangement is extremely unlikely, yet I just got it.

A guy got struck by lightning 7 times ([https://en.wikipedia.org/wiki/Roy_Sullivan](https://en.wikipedia.org/wiki/Roy_Sullivan)). The odds of any person getting struck by lightning is 1 in 10000. Seven times in a row is 1 in 2^93. But then when you start drilling down, you see that he's a park ranger, and that he's out while lightning happens, which makes the probability that he'll get struck much higher.

If I had phrased the question to you asking what the likelihood of _any given person_ in the world being struck seven times was, you could have calculated the former and said 2^-93 is such a small probability that it's not worth thinking about - and yet here is Roy Sullivan, so there's some sort of conflict in my logic. What's wrong with the former calculation?

Why is it that for any given person the probability is 2^-93 but for Roy it's somehow different, even though he is a "given person"? Is it that the 1 in 10000 number was wrong? But then if we look at all the people who never once got struck, it seems about right. If we inflate that number to 1 in 100 to make Roy likelier to get 7 in a row, then it seems everyone also should be getting shocked more often at least once or twice.

Or maybe it's that somehow the probability changes when we have more information and those two numbers and situations are not comparable on an absolute scale. Maybe if you get hit twice then you're much likelier to get hit again because you're probably in some dangerous location - but how was I to know to factor this in? It seems that it's very much about how you calculate the probability. Who knows what other hidden factors could be wildly affecting the true value of the probability?

That also makes me think - is there even such a thing as the "true" or inherent probability of an event happening?

edit: Or maybe it's the law of large numbers - given enough "trials" or in this case lightning events with people around, even something with an absurdly small probability is bound to happen eventually. But then why do we never factor that in and always just call it a day with 10000^7?

<comment><USER5> You've touched upon an old conflict. [http://lesswrong.com/lw/oj/probability_is_in_the_mind/](http://lesswrong.com/lw/oj/probability_is_in_the_mind/)

<comment><USER6> There's no need to refer people to lesswrong for this. The interpretation of probability as a subjective degree of knowledge/evidence is well-known. For example: [http://plato.stanford.edu/entries/probability- interpret/](http://plato.stanford.edu/entries/probability-interpret/) or [http://plato.stanford.edu/entries/epistemology- bayesian/](http://plato.stanford.edu/entries/epistemology-bayesian/)

No need to spam links to that cult site.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> Q: How does p not being a prime => backdoor?

A: p not being a prime means two things:

* subgroup confinement attacks (where you send a public key made with a fake generator g) should be able to take place if the code is weak -> this is because there must be low order subgroups.

* the generator g might not be of great order. This can be easily tested if you know how to factor p: the order of the multiplicative group (Zp)* is the euler's totient function on p. If you know the order of the multiplicative group then you have an algorithm to find the order of your generator: you try all the divisors of the group's order, see the smallest one that works.

Unfortunately, if you don't know how to factor p then you can't easily do that.

Another question is: How can they know it's not a prime if they don't know the factorization of p? We have efficient provable tests for that: they tell you if p is prime or not and nothing else.

<comment><USER8> > We have efficient provable tests for that: they tell you if p is prime or > not and nothing else.

I think this is a typo -- the efficient general-form tests are _probable_ rather than _provable_.

[https://en.wikipedia.org/wiki/Primality_test#Probabilistic_t...](https://en.wikipedia.org/wiki/Primality_test#Probabilistic_tests)

<comment><USER9> There are exact tests that run in polynomial time, like [https://en.wikipedia.org/wiki/AKS_primality_test](https://en.wikipedia.org/wiki/AKS_primality_test)

<comment><USER8> I hate to say that a polynomial-time test isn't efficient because many people use that as the very _definition_ of efficient, but my understanding is that AKS is incredibly impractical because the polynomial is ginormous, even though its asymptotic behavior is nice. So if you actually wanted to know if, say, a 1024-bit number was definitely prime, you wouldn't be able to run AKS on it in a "reasonable time" on a real computer.

<comment><USER7> I haven't actually studied to what extent the AKS tests are do-able. I always figured there would be no problem running one for a 1024 bits prime. Found this on SO: [http://cs.stackexchange.com/questions/23260/when-is-the- aks-...](http://cs.stackexchange.com/questions/23260/when-is-the-aks- primality-test-actually-faster-than-other-tests)

Also, to further the discussion on probable vs provable: the probable tests are enough in our case because they tell us _provably_ if an integer is not a prime (that we care), but _probably_ if an integer is a prime (which we don't care here).

<comment><USER10> This is not conclusive, but the best deterministic primality test (an AKS variant by Pomerance and Lenstra) is 6th power. 1024^6 is quite large.

</comment></comment></comment></comment></comment></comment><comment><USER11> I always wonder if when things like this get found, there's someone in the NSA going "Wow they finally found it, only took them x years"

<comment><USER12> >> I always wonder if when things like this get found, there's someone in the NSA going "Wow they finally found it, only took them x years"

I would guess they were aware of the problem weather they created it or not. So yes.

<comment><USER13> > I would guess they were aware of the problem weather they created it or not.

While it's smart to assume so, it's also pretty laughable to think that the NSA has an exhaustive list of encryption vulnerabilities.

<comment><USER14> > While it's smart to assume so, it's also pretty laughable to think that the > NSA has an exhaustive list of encryption vulnerabilities.

True, but in this case I'm sure they have enough hardware to factor any widely deployed primes used in crypto or semi crypto comms software. After all, that is half of the NSAs job description.

<comment><USER15> I expect you have enough hardware to factor widely deployed primes. Compound numbers might be a different story.

</comment></comment></comment></comment></comment><comment><USER16> Title is misleading -- this appears to be an issue with a tool called socat, not with OpenSSL. That's a world of a difference in the severity of the issue.

<comment><USER17> I think the first line is confusing and misleading until I read yours.

> In the OpenSSL address implementation the hard coded 1024 bit DH p parameter > was not prime.

It should have been worded "In Socat, the DH p parameter used by OpenSSL implementation was hardcoded and was not a prime."

<comment><USER18> The original phrasing is correct, but confusing if you aren't familiar with socat. Socat fundamentally works by giving it a pair of addresses; they are referring to socat's implementation of addresses starting with "OPENSSL:" (caps-insensitive), AKA "OpenSSL addresses".

<comment><USER17> I see. You are right, and yes I may have jumped to the gun too quickly.

</comment></comment></comment></comment><comment><USER19> This is a vulnerability in socat's TLS support. It has nothing to do with OpenSSL (besides the fact that OpenSSL provided a footgun API by leaving it to application developers to supply DH parameters).

<comment><USER20> "Footgun API" \- I like that!

Its an interesting challenge though, I wonder if the person who picked the constant the first time understood the ramifications of it being prime or not. And if they did, how hard they worked to validate its primality.

</comment></comment><comment><USER21> Very nice asymmetric backdoor!

If you happen to know the factorization and the factors are not too large (e.g. two 500-bit factors + some chaff), then you can just use Pohlig-Hellman algorithm to solve the DLP modulo each individual factor, combine the results and recover the shared Diffie-Hellman secret.

But without this trapdoor information (and, say, if p was chosen to be a Blum integer), computing the Diffie-Hellman shared secret is as hard as factoring that modulus (see [https://crypto.stanford.edu/~dabo/abstracts/DHfact.html](https://crypto.stanford.edu/~dabo/abstracts/DHfact.html)).

</comment><comment><USER22> Someone should really write a set of unit tests available in every conceivable language, marked as "Please copy this unit test into your test base, and use it to verify all your primes are prime".

You can even make it a bit fuzzy- Miller-Rabin uses random numbers, right? So make it that every time the unit test is run it generates new random values. Your test won't be deterministic, but it will fail at least some of the time which should be enough to raise an alarm of a problem.

<comment><USER23> I'm aware that factoring a prime into composites is one of the most difficult computational problems, but isn't it cheap to determine if a number is prime ? a^(p-1) == a mod p (where == means "congruent to" ). with modular exponentiation isn't it simple to compute the modulus ?

<comment><USER24> The little Fermat test requires you to test all "a"s in order to remove false positives. For most numbers, testing a few thousand bases is enough but you have Carmichael numbers that break the test.

There are better primality checks, but they all have downsides (either slow but provable or fast but probabilistic). Finding prime numbers can be shown to be easier than finding factors (see: how GIMPS checks for primality), but that doesn't make it easy.

</comment></comment></comment><comment><USER25> Nice catch. Now, the real question is who committed it, and how they came up with the number.

If it is a backdoor, it's pretty smart, because it's very deniable as a "stupid mistake". And if it's a stupid mistake, it's extra stupid, because this committer will have trouble convincing the world that that's all it was. At the very least, somebody needs to be going through all this person's commits with a fine-toothed comb.

The methods of handling situations like this in the face of a known threat is going to be interesting. You hate to ban or hinder a good programmer from a project, but once possibly-bitten, twice shy.

<comment><USER26> Aren't large non-primes usually created by multiplying two large but smaller primes together. Factoring is then the challenge. Or is there more to this that I'm missing?

<comment><USER25> The question is whether they:

a) knew it was non-prime, and used it to weaken the crypto

b) knew it was non-prime, and used it because they didn't think it needed to be prime (which is a massive sin of ignorance)

c) grabbed 1024 bits of rand() and didn't check if it was prime (again, stupid)

d) grabbed some rand and checked the prime-ness using a bad method

e) used a "prime number generator" that produced bad output

I agree that making non-prime numbers is not terribly difficult, but the question of how they got the number is only interesting in that it gives info about why.

<comment><USER27> f) Used a machine with bad RAM that flipped a bit.

This case could actually be tested for - see if any of the one-bit differences from the number used are prime.

<comment><USER28> A bit could have been flipped in the software or the result of the function (true/false), but in the number itself there appear to be no single bit flips that make it prime (at least in the binary representation).

Edit: A single bit flip could have been used as "semi" plausible deniability in the case of malicious intent.

</comment></comment></comment></comment></comment><comment><USER29> >there is no indication of how these parameters were chosen

Is there really no protocol used in projects undertaken by the security community that would ensure that each component of the tools we rely on has a known history?

<comment><USER30> Well, socat has a git repo at git://repo.or.cz/socat.git so you can see the history of the prime number. In particular, it was upgraded from a 512 bit prime to a 1024 bit "prime" in commit 281d1bd on Jan 23, 2015.

Neither the code then, or the new code in this patch, have comments indicating how the prime was generated. (It is only mentioned in the advisory that openssl dhparams was used for the recent patch)

</comment></comment><comment><USER31> Might be an interesting exercise to search through github for large numeric constants and find ones that aren't prime, then manually check through those for ones that are supposed to be.

</comment><comment><USER32> This is the reason RFC 5114 exists.

[http://tools.ietf.org/html/rfc5114](http://tools.ietf.org/html/rfc5114)

</comment><comment><USER33> Has anyone checked the new number is a prime?

</comment><comment><USER8> Some community-vetted larger DH parameters that software developers can use:

[https://datatracker.ietf.org/doc/draft-ietf-tls- negotiated-f...](https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated- ff-dhe/)

</comment><comment><USER34> Previously:

        915       static unsigned char dh1024_p[] = {
        916      0xCC,0x17,0xF2,0xDC,0x96,0xDF,0x59,0xA4,0x46,0xC5,0x3E,0x0E,
        917      0xB8,0x26,0x55,0x0C,0xE3,0x88,0xC1,0xCE,0xA7,0xBC,0xB3,0xBF,
        918      0x16,0x94,0xD8,0xA9,0x45,0xA2,0xCE,0xA9,0x5B,0x22,0x25,0x5F,
        919      0x92,0x59,0x94,0x1C,0x22,0xBF,0xCB,0xC8,0xC8,0x57,0xCB,0xBF,
        920      0xBC,0x0E,0xE8,0x40,0xF9,0x87,0x03,0xBF,0x60,0x9B,0x08,0xC6,
        921      0x8E,0x99,0xC6,0x05,0xFC,0x00,0xD6,0x6D,0x90,0xA8,0xF5,0xF8,
        922      0xD3,0x8D,0x43,0xC8,0x8F,0x7A,0xBD,0xBB,0x28,0xAC,0x04,0x69,
        923      0x4A,0x0B,0x86,0x73,0x37,0xF0,0x6D,0x4F,0x04,0xF6,0xF5,0xAF,
        924      0xBF,0xAB,0x8E,0xCE,0x75,0x53,0x4D,0x7F,0x7D,0x17,0x78,0x0E,
        925      0x12,0x46,0x4A,0xAF,0x95,0x99,0xEF,0xBC,0xA6,0xC5,0x41,0x77,
        926      0x43,0x7A,0xB9,0xEC,0x8E,0x07,0x3C,0x6D,
        927       };

      $ echo 'isprime(143319364394905942617148968085785991039146683740268996579566827015580969124702493833109074343879894586653465192222251909074832038151585448034731101690454685781999248641772509287801359980318348021809541131200479989220793925941518568143721972993251823166164933334796625008174851430377966394594186901123322297453)' | gp -q
      0

With fix

        xio-openssl.c
        915       static unsigned char dh2048_p[] = {
        916      0x00,0xdc,0x21,0x64,0x56,0xbd,0x9c,0xb2,0xac,0xbe,0xc9,0x98,0xef,0x95,0x3e,
        917      0x26,0xfa,0xb5,0x57,0xbc,0xd9,0xe6,0x75,0xc0,0x43,0xa2,0x1c,0x7a,0x85,0xdf,
        918      0x34,0xab,0x57,0xa8,0xf6,0xbc,0xf6,0x84,0x7d,0x05,0x69,0x04,0x83,0x4c,0xd5,
        919      0x56,0xd3,0x85,0x09,0x0a,0x08,0xff,0xb5,0x37,0xa1,0xa3,0x8a,0x37,0x04,0x46,
        920      0xd2,0x93,0x31,0x96,0xf4,0xe4,0x0d,0x9f,0xbd,0x3e,0x7f,0x9e,0x4d,0xaf,0x08,
        921      0xe2,0xe8,0x03,0x94,0x73,0xc4,0xdc,0x06,0x87,0xbb,0x6d,0xae,0x66,0x2d,0x18,
        922      0x1f,0xd8,0x47,0x06,0x5c,0xcf,0x8a,0xb5,0x00,0x51,0x57,0x9b,0xea,0x1e,0xd8,
        923      0xdb,0x8e,0x3c,0x1f,0xd3,0x2f,0xba,0x1f,0x5f,0x3d,0x15,0xc1,0x3b,0x2c,0x82,
        924      0x42,0xc8,0x8c,0x87,0x79,0x5b,0x38,0x86,0x3a,0xeb,0xfd,0x81,0xa9,0xba,0xf7,
        925      0x26,0x5b,0x93,0xc5,0x3e,0x03,0x30,0x4b,0x00,0x5c,0xb6,0x23,0x3e,0xea,0x94,
        926      0xc3,0xb4,0x71,0xc7,0x6e,0x64,0x3b,0xf8,0x92,0x65,0xad,0x60,0x6c,0xd4,0x7b,
        927      0xa9,0x67,0x26,0x04,0xa8,0x0a,0xb2,0x06,0xeb,0xe0,0x7d,0x90,0xdd,0xdd,0xf5,
        928      0xcf,0xb4,0x11,0x7c,0xab,0xc1,0xa3,0x84,0xbe,0x27,0x77,0xc7,0xde,0x20,0x57,
        929      0x66,0x47,0xa7,0x35,0xfe,0x0d,0x6a,0x1c,0x52,0xb8,0x58,0xbf,0x26,0x33,0x81,
        930      0x5e,0xb7,0xa9,0xc0,0xee,0x58,0x11,0x74,0x86,0x19,0x08,0x89,0x1c,0x37,0x0d,
        931      0x52,0x47,0x70,0x75,0x8b,0xa8,0x8b,0x30,0x11,0x71,0x36,0x62,0xf0,0x73,0x41,
        932      0xee,0x34,0x9d,0x0a,0x2b,0x67,0x4e,0x6a,0xa3,0xe2,0x99,0x92,0x1b,0xf5,0x32,
        933      0x73,0x63
        934       };

      $ echo 'isprime(27788893276069724796504555675597658900595616769773727063231875314156885361379100133264804184710789407128574011804155595735704837674243828066040543912171576627544718762752948158991754559261759162739343094515270757451837630913502740443023902769553802723685440839891240497710460941757089246131322686180648463540974702859210630184042730717698427486397505787974799692901205514386555272667298045803284972074823213104807295638814082142694729938965663710648170010420323923305528998108799706139846097432481556448740855888110797022123731105964852194684036975049177742094726795060211226322344210328442014189175085444396370522979)' | gp -q
      1

The original error could have been checked with a quick code review verifying that the provided number was in fact prime. This should have been done when the original patch was submitted.

<comment><USER35> Kind of interesting that the first nonprime version ended in a comma, as if it originated as a fragment of a longer array of bytes. That's nonstandard C, and I'd expect that whatever tool(s) generate those arrays would know not to add a comma after the final entry.

<comment><USER36> <cynical thought>That's a nice piece of plausible deniability, huh? I wonder if the committer has a few extra bytes that he can claim were supposed to be there which make a number that passes all the primality tests? That'd be a nice excuse for the NSA/3PLA overlords to have given him...

<comment><USER37> Extra bytes would have made it not a 1024-bit integer.

<comment><USER38> Whicgh provides an excuse for why the prime was truncated, and OOPS made it into a not-prime.

</comment></comment></comment></comment></comment><comment><USER39> That looks like it's for 'socat', not openssl itself ...

</comment><comment><USER40> I'm curious, is there a list of known primes held somewhere?

<comment><USER41> Pi would be a good source, but they are in the wrong order.

<comment><USER24> Pi would be a horrible source. Why would you want to use a deterministic digit generation function to generate your entropy. Even if you always used very large digit offsets. I can't imagine it being a remotely good idea.

<comment><USER42> As a source of primes? OP never said he wanted them to be random, and pi does contain every (finite) number. :P

<comment><USER43> That is not know to be the case, only conjectured.

<comment><USER44> I thought it was proven to be trancendental? Or were you saying that this property of trancendental numbers is only conjectured?

<comment><USER45> Pi is transcendental, which means that it is not a root of a non-zero polynomial with rational coefficients.

Being transcendental does not imply that a number's expansion in a given base must include every digit string. Consider the number 1/10^1! + 1/10^2! + 1/10^3! + 1/10^4! + ....

This number, whose decimal expansion is 0.110001000000000000000001... is transcendental (proven by Liouville in 1844). Its decimal expansion clearly does not contain every decimal number. It only contains the digits 0 and 1, and after the first two places never even contains consecutive 1s.

It is known that "almost all" real numbers do in fact contain in their base b expansion every sequence of base b numbers, each sequence occurring with frequency proportional to its length. These are called "normal" numbers. Very few interesting numbers (where "interesting" means that we have some reason to be interested in aside from their normality) are known to be normal, though.

<comment><USER40> Sorry to go off topic here, but can you give an example of a number that isn't interesting?

<comment><USER45> By "interesting" I mean a number that arises out of something else that one might be interested in.

For instance, consider pi. If you are interested in geometry, pi will turn up. If you are interesting in number theory, pi will turn up (e.g., it is connected to zeta functions). If you are interested in probability and statistics, pi will turn up. If you are interested in differential equations, pi will come to the party.

If you somehow have never encountered pi, I can convey it to you by telling you about one of those things. For instance, I could tell you that it is the period of the non-zero solutions of the differential equation y'' \+ y = 0.

An uninteresting number would be one that has no known connection to other things. If I have a particular uninteresting number, and I want to convey it to you, I'll have to just tell you the number.

A random number would almost certainly be uninteresting, such as this hex fraction, which came from /dev/urandom on my computer: 0.bfdab557104bf2d8952fb1ea0adfd732794a353d5b35d95cda927f4ad8f6dd11f11b2e968298. It is extremely unlikely that anyone has ever seen that number before. The only known thing interesting about it is that it was made specifically as an example of a number that is not otherwise interesting.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER46> It's interesting that all the time no one noticed it was not actually prime. This leans skepticism towards assumptions that widely used security critical open source code is reviewed by anyone competent at evaluating it, even over long periods of time.

</comment><comment><USER47> Mirror here: [http://marc.ttias.be/oss- security/2016-02/msg00003.php](http://marc.ttias.be/oss- security/2016-02/msg00003.php)

</comment><comment><USER24> I think most people are glossing over the first part of the title. Why is the DH p parameter hardcoded? Why not just generate one on each startup?

<comment><USER48> Generating those parameters is very slow. Just run `time openssl dhparam -text -noout 1024` a few times and see for yourself.

<comment><USER24> Then do it on first run and store it in ~/.socat_prime and do a primality check each time it's loaded.

</comment></comment></comment><comment><USER49> The older version I was using, 18.104.22.168, is not affected. So much for "updates".</comment>


Four Squared Signs You Are a Foursquare Addict - <AUTHOR> http://blog.louisgray.com/2010/05/four-squared-signs-you-are-foursquare.html

<comment><USER2> 1\. When you have time to reach your destination, you decide to take detours so you can check-in at a favorite place of your choice.</comment>


Why is Atom Closed Source? - <AUTHOR> http://discuss.atom.io/t/why-is-atom-closed-source/82/44

<comment><USER2> GH is shooting its own foot here. The fact this is the first issue discussed before Atom has even been made public makes me think we'll see a lot of backlash. Eventually GH will cave in and release it under proper license, so why upset everyone in the first place? Some of GH's appeal relies in its image as a dev-friendly, "cool" company.

Now, as for Atom, they don't need to worry about forking when its opensourced, as GH's branding and integration with the present GH functionality will likely to deter most from using forks.

</comment><comment><USER3> > _it 's not going to be open source but you will be able to look at the code > and send pull requests. So it's very similar to open source in that you can > fix bugs and add features if your changes get accepted by Github, but has > the limitation that you can't redistribute your changes by creating your own > editor based on Atom if Github should not accept your changes._

So it is open source... Just not free software. Get the terms straight, guys.

<comment><USER4> Love the double dipping. "GitHub can profit off your code, but you can't do anything with it and have no rights to it!"

<comment><USER5> well, its not "your" code is it? GitHub have written it. If you don't want them to profit off your work, don't submit patches to Atom?

<comment><USER4> The whole point is they're trying to have it both ways. They want to benefit from other people's work freely (that's why they're accepting pull requests), but do not want to let others benefit from their work in the same way.

</comment></comment></comment></comment><comment><USER6> There is a legitimate problem in the software/developer tools ecosystem that everyone wants everything to be free, which means no one can make money building it.

I'm actually looking forward to Github's solution to this, given they are generally pretty smart folk. Perhaps they'll find a model that others can follow.

<comment><USER7> On the flip side, they do seem to be making money off of services built upon the free software licensed Git.

<comment><USER6> True. SaaS FTW.

Git wasn't really their codebase though, although, true, they do employ core people now (IIRC/AFAIK).

Pessimistically, given that Atom is not initially/wonderfully open source, if Git _had_ been Github's codebase from day 1, it is likely they would have had the same "crap, we must charge for this somehow" thoughts they are having now, and Git as we know it would not have happened.

</comment></comment></comment><comment><USER8> This was already posted 13 hours ago: [https://news.ycombinator.com/item?id=7310017](https://news.ycombinator.com/item?id=7310017)

</comment><comment><USER9> It seems that the answer to this question is quite simply that github want to make money selling the product which seems reasonable. Why is there so much outrage, if you only use open source (in the free software definition) software then simply don't use atom?

<comment><USER10> Totally agree. If you want an open source editor, just don't use atom. It's not that difficult of a decision to make. I hate it when developers feel "entitled" to open source software. No, not everything is open source. There are some pieces of software that you will have to buy.

I use open source software every single day of my life, but I also pay for software. I pay for Sublime Text, it's worth it. If Atom is better than Sublime, sure I'll buy it.

In my opinion paying for something is about supporting the devs so they can continue making great products and feed their families.

It's fine for a company to make a profit, that's why they are a company after all. In a utopian society everything would be free, but we don't live there.

</comment></comment><comment><USER11> someone mentioned in that thread that the .app file contains a package.json which states it is under an apache license.

I think the default that npm init gives is BSD, so this seems like a nominally conscious decision on their part.

I don't really think it would make sense for github (a services company) to start selling commercial desktop software, but whatever.</comment>


How to measure the success of your web app - <AUTHOR> http://www.thinkvitamin.com/features/webapps/how-to-measure-the-success-of-your-web-app <comment><AUTHOR> A lot of people here are starting web based businesses, but may not understand the right numbers to look at. This article is like Webonomics 101.</comment>


Opera 10.5 beta released - Fastest JS engine in the world (Windows only) - <AUTHOR> http://www.opera.com/next/

<comment><AUTHOR> Just installed it, and I have to say, they've made some great UI improvements. I use visual tabs, and the Aero effect on the thick tab bar looks great. And the new inline search is awesome as well. Anyone else notice any new UI niceties?

BTW, don't try to install this over your Opera 10.1 installation. It won't work.</comment>


"Becoming Warren Buffett," the Man, Not the Investor - <AUTHOR> http://www.newyorker.com/business/currency/becoming-warren-buffett-the-man-not-the-investor?intcid=mod-latest <comment><USER2> Lots of investors understand how to value companies, far fewer actually apply it regularly. I'm always amused when some Wall Street advisor discusses a businesses cash flow and growth rate using terms from his valuation courses, then starts talking about market sentiment and concludes by analyzing it's chart.

It's like a physicist laying out the math perfectly for an orbital launch, but then starts analyzing launch times using Astrology.

Very, very few investors apply valuation methodologies so well they they become true value investors, the name is really a marketing label for most funds. One necessary part of being a value investor that Buffett harps on in his letters is psychology, the ability to avoid bias in order to make decisions and not undo them in a panic. He works really hard to insulate himself from irrational fears, and focus on known facts.

For example, he tries to never know what a company's stock trades at when he reads their annual reports and start making his own estimate of it's value. If it's a great company and it's trading for $100, he doesn't want to be subconsciously biased to raising his valuation estimate just to justify buying it.

There is a great story from his partnership days. His partners were told up front he'd never discuss what they were invested in, he didn't want anyone front-running his trades at hurting the partnerships results. But one day during a market tumble a partner rushes in and demands to know if Buffett had invested in certain stocks that had crumbled. Warren just buzzes his secretary, asks how much the partner's share was worth, and told her to write him a check for that amount, and told the guy you're out.

He wasn't going to panic. He wasn't going to let others try to panic him.

<comment><USER3> (disclaimer: I say this as someone who's has invested into Berkshire Hathaway)

Buffet's success is only partly his ability to value companies and buy them at good price. He is good at that, no doubt, but it's just half of the story.

The real genius is the way Buffet has structured his business to give him permanent advantage. The core of Berkshire Hathaway is the insurance business, GEICO and Berkshire Reinsurance. These companies are very profitable and generate huge cash inflow. This cash is cheaper compared to what other investors get trough financial sector. Especially when times are tough and money is tight. When other investors must sell something they own or get expensive loan, Buffet is drowning in cash and looking ways to spend it.

Someone who is just as good at valuing companies starts several percentage points behind Buffet when they scramble to finance their acquisition.

<comment><USER4> This is all true but before he structured his businesses this way, he ran a pure investment partnership for several years where his results were entirely due to his security-picking abilities (the aforementioned anecdote about returning the investor his money is from those days). He clobbered the Dow in those years too.

<comment><USER5> Buffett is an interesting case.

When he got going, people were mostly just buying what their broker told them to, which was some company the broker had heard about that morning on the elevator. There was such little information out there that his philosophy (buy and sell on fundamentals looking at various ratios) gave him a major advantage. This was Ben Graham and The Intelligent Investor, who Buffett studied under at Colombia, then worked with him.

I'd say Buffett's biggest innovation past that is realizing the role of management. He talks about it in various ways, but I think his main rule comes down to "avoid psychopaths in management; it's a fundamental people don't understand how to discount correctly." There's a lot to that, it turns out.

Then he got into insurance, as you say, to get lots of cheap cash to invest. Compare him to say, Jay Gold, who mostly got rich through stock manipulation or Michael Milken who got rich by inventing the junk bond (a "new" financial product) then went to jail.

Not many successful stock pickers out there; most rich finance people made it from commissions of some form or another, not market gains.

The world is different now though; Graham's methodologies are so beat to death at this point that there's no advantage to be had. Buffett's philosophies on the importance of the management team (not being psychopaths) still apply though.

<comment><USER2> No one follows Grahams methodologies because you can't raise money doing it. They pay lip service to it. Riches on wall street come from fees on other peoples money, something Buffett voluntarily gave up in the late 60s.

And as far as "avoid psychopaths in management" that's actually nearly opposite Buffett's real philosophy, which is "you want to own a business any fool can run, because sooner or later a fool will be running it". He looks for businesses with strong competitive barriers.

<comment><USER5> > No one follows Grahams methodologies because you can't raise money doing it.

Or because they're old and beat to death and don't work anymore? They used to work and that's where Buffett started.

> Riches on wall street come from fees on other peoples money

Yes, that's mostly true, which is what I said (I said, "most rich finance people made it from commissions of some form or another, not market gains.")

> And as far as "avoid psychopaths in management" that's actually nearly > opposite Buffett's real philosophy,

No, it's really not.

> which is "you want to own a business any fool can run, because sooner or > later a fool will be running it".

Didn't Peter Lynch say that? It's a good quote though; I've certainly used it. My favorite Buffett quote is "Risk comes from not knowing what you're doing."

Also "Long ago, Ben Graham taught me that 'Price is what you pay; value is what you get.' Whether we're talking about socks or stocks, I like buying quality merchandise when it is marked down"

The guy has said lots of interesting things and is worth learning more about if you're even tangentially interested in business and investing.

</comment></comment></comment></comment></comment></comment><comment> nappy-doo I've been a longtime Buffett follower. I haven't seen the HBO documentary yet but am looking forward to it.

I would recommend Buffett's authorized biography "The Snowball" by Alice Schroeder. Before writing it, WB told AS that if she got different stories from different tellers to go with the one that was least flattering to WB.

Since it was written, WB hasn't denounced the book, but has broken off what were cordial ties with the author. Speculation abounds, but mostly it's because she hints that Susie wasn't entirely faithful to Buffett when she left Omaha and moved to California. (She never comes out and says it, but it's implied.)

In any case, it's an excellent book, and the one written with the most access to Buffett and his notes.

<comment><USER6> I also read The Snowball, and my take on it was that Buffett is a seriously duplicitous man. He says one thing and does another. He believes in companies that pay dividends, yet BH does not. He is a folksy family man that has two wives. He is a big Democrat and believer in equality, and yet during the Washington Post workers strike he was working very hard with Katharine Graham to deliver the newspaper and counter the union's efforts.

<comment><USER7> Honestly though, why would you want him to pay dividends? He is going to invest the money far better than I will.

<comment><USER8> You might need an income not all investing is for 100% capital growth

<comment><USER9> So sell some shares. It can be better than a dividend for tax purposes. This is a common topic at the annual meetings, and Buffett has addressed it in detail before: [http://www.fool.com/retirement/2016/12/02/warren-buffetts- st...](http://www.fool.com/retirement/2016/12/02/warren-buffetts-strategy-to- get-income-from-any-st.aspx)

<comment><USER8> What about the cost of the trade you don't pay to receive dividends. And in the UK if you have your investments in an ISA or stay under your personal allowance (5k£) - the UK is a little more sensible when it comes to tax on investments.

<comment><USER9> BRK.B shares currently trade around US$160ish/share. The dividend equivalent to selling even a _single_ share would incur $24 in taxes (15%), and the transaction fee for a discount broker is around $7 or $8. So unless the shares have tripled since you bought them, which would have had to have been in 2003 or prior, you're coming out ahead in the US after only one share (savings on long-term capital gains taxes exceed the transaction fee cost). If you sell two shares at a time, it gets you back to 1997.

Yes, tax-advantaged accounts are a different question, but Berkshire can't pay a dividend to just "the people who need money in a tax-advantaged account". If you want a smaller impact from fees, make fewer, larger transactions.

It's not like this requires particularly large sums. At 7 shares per transaction you're already under the industry average stock index fund expense ratio (0.76%), and unlike those funds, that's a cost that's incurred once on just the shares you sell, not annually on your whole investment. People pay higher (relative) fees to withdraw cash from an ATM.

<comment><USER10> > US$160ish/share. The dividend equivalent to selling even a single share > would incur $24 in taxes (15%),

You aren't taking the purchase price of that share into consideration. If you bought the share at $140, your profit is only $20, and the tax on the equivalent dividend would only be $3.

What's the equivalent CGT on that $20 profit?

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> I came across an interesting story the other day about his relationship with Rose Blumkin, Founder of Nebraska Furniture Mart and how she tricked him into buying NFM without a non-compete clause and he paid the price. Story: [http://www.infoblizzard.com/the-blog-smog/a-humorous- story-a...](http://www.infoblizzard.com/the-blog-smog/a-humorous-story-about- rose-blumkin-the-founder-of-nebraska-furniture-mart-and-how-she-worked-over- billionaire-warren-buffet)

<comment><USER12> I read the link and am left to wonder at the role of business ethics in a business deal. Was it unethical for her to start a competing business? Seems like an uncool move, but of course I'm reading this years after the fact.

<comment><USER13> On a practical level, if I sell my small business, is a non-compete really something that's practical? If all I know is furniture sales and all my contacts are in the furniture business, etc what am I supposed to do now, assuming the sale didn't make me incredibly wealthy to the point where I dont need to work ever again?

Its unrealistic to expect people to suddenly learn new skillsets later in life, especially if they have decades invested into these skillsets. I think this is why non-competes in many industries are ultimately unenforceable and why the courts or state legislatures never want to make non-competes powerful. People aren't machines. They can't really be retooled. If I get a job with Bigco and then switch to Smallco, Bigco shouldnt be able to tell me I can't be a programmer there. Corporations shouldn't have this level of power over us.

Even if we dismiss the first scenario as a 'business sale' I'd argue that sole proprietor businesses or any business with only a few people is much closer to being an employee somewhere. You can't expect someone to give up their only skills for 5 to 10 years for a modest sale. Not every sale is a SV-like billion dollar plus sale.

<comment><USER14> Usually a non-compete like that is geographically boxed.

When you're selling a business, you're selling the future. If you sell your furniture business, then turn around and open up a store down the road, you're attacking the ROI that you projected going forward and the buyer acted upon in good faith. Sketchy.

Employees are a different matter, as it's a one-sided arrangement where the employee has little bargaining power. Small businesses are different -- both parties are free agents.

<comment><USER13> My thinking is that I sell my furniture store but then get a job at a different furniture store. I don't necessarily see that as an attack on their ROI. But yes, starting a new company nearby I could see being blocked for x amount of time. The problem I see is that NDA's aren't that granular. They're fairly strict and can hurt one's ability to find work.

</comment></comment></comment></comment></comment><comment><USER15> From the article: financial questions "are easy," as Buffett says. "It's the human problems that are the tough ones."

Preach. The more I 'practice business' the more I come to appreciate that the only thing out of your control are people (and that's probably a good thing). Everything else you can structure some kind of deal to resolve, but people are emotional, untrusting, illogical and often good at hiding their true motives.

<comment><USER2> I think Buffett would say not just people, but you are emotional, untrusting, illogical and good at hiding your motives from yourself. Thats why he preaches about how you live your life affects the quality of your decisions. He's not on Wall Street for a reason, living in Nebraska shields him from a lot of superfluous nonsense and allows him to focus on factual analysis and decisions.

</comment></comment><comment><USER16> I find some of his dealings disturbing. [https://www.publicintegrity.org/2015/04/03/17024/warren- buff...](https://www.publicintegrity.org/2015/04/03/17024/warren-buffetts- mobile-home-empire-preys-poor) On a personal level he took over a local manufacturing co. in the city I live in. My former neighbor was working there when he took over the company. In a press release he said he was pleased with managements performance at the company and they should continue to operate as they were. My neighbor in his early 60's was worked 7 days a week , 11 to 12 hr. days. It was apparent they were trying to force him out. They accomplished their goal , he had a stroke on the job and died a few days later. I agree Warren was not responsible personally , I don't know where the buck stops. I lost a good neighbor soon after his dog passed.

<comment><USER2> Sounds like you have a problem with the owners/managers, not Warren. Do you really think he came all the way from Nebraska to point out your neighbor and tell management to work him to death?

Warren is notoriously hands off with the businesses he buys. He typically buys them because they are well run and he doesn't have time to fix anything.

<comment><USER16> By took over I meant he bought the company. If you read the bottom of my comment . . ( I agree Warren was not responsible personally , I don't know where the buck stops. )

</comment></comment></comment><comment><USER17> OT, but it's annoying the way The New Yorker writes cooperation 'coöperation' (ditto 'reëlect'). There's zero justification for this, etymologically or orthographically, it's just pure pretension.

<comment><USER18> Lol typical hacker news blowhard going off on something they have no idea about . "Orthographically" speaking there IS a justification and you would've found it if you spent three seconds of effort:

diaeresis (plural diaereses)

1\. (orthography) A diacritic ( ¨ ) placed over a vowel letter (especially the second of two consecutive ones) indicating that it is sounded separately, usually forming a distinct syllable, as in the English words naïve, Noël and Brontë, the French haïr and the Dutch ruïne.

It makes perfect sense to use the diacritic in this way and it is part of their style guide, has been for some time.

You couldn't even spend the time researching what you're complaining about. Talk about pretension.

<comment><USER17> I'm well aware it's a diaeresis, and that it's part of their house style. That's exactly what I'm objecting to. The diaeresis is obsolete modern English (with rare exceptions) and putting it in interrupts the flow of reading. There is no excuse for it in 'cooperation', and only the only reason they do it is in order to show off they know about it - IOW pretension.

<comment><USER18> >There is no excuse for it in 'cooperation'

Yes, there is. A) it is a perfectly grammatically and orthographically correct usage of the di B) There is no prescriptive body which governs usage of American English - there's no need for an "excuse" to use an orthographic feature of the language as if it is some clause violated.

The reason they do it is because it's the New Yorker. It's their house style. It's what their readers expect and understand and it has become a tradition and perhaps even emblematic of the magazine and its brand. Complaining about the "pretentiousness" of the New Yorker is like complaining about the convoluted commands in eMacs or vim - it's not a problem, it's a feature.

<comment><USER17> Any deviation from the norms of English calls attention to itself, and distracts from the meaning. This can be done by great writers, but always with reason.

Good writing reveals something about the reader. Bad writing reveals something about the writer.

However since you now seem to agree that it's pretentious, which was my original point, I'll leave it there.

</comment></comment></comment></comment></comment><comment><USER19> This is just rich-people worship. What this has to do with tech, other than that a bunch of tech people also worship the rich, is beyond me. Pass.

<comment><USER2> If you could understand who Buffett is and what he does, it would broaden your understanding of the world immensely.

<comment><USER20> I'm probably gonna be downvoted for this, but what the heck. I watched the Warren Buffet documentary on HBO with my 11 year old daughter. Now, I've raised my daughter to have an entrepreneurial mindset and to always look at ways to add value to the world. The major points of the documentary that stood out to her were that he has lots of money. He owns pieces of companies who do well, and in turn he does well. His wife didn't feel that was an ideal way to live her life and left to provide value to actual people.

I didn't really know what to say, because she is right. Warren Buffet is good at picking companies who are undervalued and making money from that. That's a skill I guess. But do you want a country filled with Warren Buffets? Is there any reason to value this kind of parasitic success? The guy isn't really much different than the mafia or a loan shark. He loans money to companies he thinks will succeed, and wants interest paid back to him. At least Bill Gates provided value (and he was predatory in doing so) and his work changed the world. Aside from his eventual philanthropy, it's hard to see how Warren Buffet has changed the world.

Maybe I'm missing something. But how do you inspire a young person to be like Warren Buffet. And more importantly, should you?

<comment><USER21> _Is there any reason to value this kind of parasitic success?_

I'm not sure you quite understand what Buffett does. Yes, his company invests in other companies. However, it's more typical for him to invest to: (1) gain a controlling share and (2) realign the company's management and strategy.

He often _turning around_ companies through his own expertise. Not just "loaning them money and collecting interest".

<comment><USER20> So I should have said, a benevolent Gordon Gekko.

<comment><USER21> So you would have preferred the companies to be less successful? Maybe laid some people off?

Yes Buffett got rich, but he got rich by creating things, which requires new jobs. A lot of other people got rich along with him.

</comment></comment></comment></comment></comment></comment><comment><USER22> I've figured out how to produce returns using cash secured or naked option strategies utilizing informational asymmetry gained from rigorous analysis of corporate Q's and K's that will actually generate wealth not slowly build it like value investing does.

This critical edge that has been hiding in plain sight but validated by actual large funds using the same methods.

Someday, newyorker.com and HN will be reading how a "Korean Canadian stock whiz turns his $50,000 CAD tax free savings account into $50,000,000 CAD"

edit: due to downvotes I will not be revealing this prized strategy.

<comment><USER23> The downvotes say it all, but don't ever write naked options. The strategy has positive expectancy, except every few years you lose >100% of capital, since the risk is almost unbounded.

<comment><USER24> I write naked puts almost every week. It's about the only way I buy highly liquid tech stocks nowadays. The risk is absolutely bounded, of course (and similar to buying a stock outright).

Naked _options_ are not the problem; naked calls are, of course, far more risky and most investors are barred from writing naked calls on individual issues.

</comment></comment></comment><comment><USER25> It's interesting to note that Buffets wife was regularly active in supporting civil rights as well as Buffet himself. Combine this with his $5Billion bailout of Goldman Sachs along with Goldmans CEO joining the battle lines along with the Linux community, white and black hat hackers and you've got a perfect storm for an attack on the trump administration which will result in its fiery demise.

<comment><USER26> Man, I'm starting to hate elaborate fantasies about how Trump will finally go down almost as much as I actually hate Trump, and that's a pretty high bar.</comment></comment>


Snap is reportedly about to launch its own gaming platform - <AUTHOR> https://techcrunch.com/2018/06/27/snap-is-reportedly-about-to-launch-its-own-gaming-platform/ <comment><USER2> why isn't there more excitement around this? This could be huge for SNAP</comment>


Winograd Schemas - <AUTHOR> https://www.cs.nyu.edu/davise/papers/WS.html <comment><USER2> Not a Winograd Schema, but I once read an example where adding the word "the" to an English sentence inverted the meaning:

"The criminals were in the possession of the police."

"The criminals were in possession of the police."

One of the odder quirks of English.

<comment><USER3> As a casual observer that _does_ seem like a Winograd Schema. What disqualifies it?

<comment><USER4> Winograd schemas depend on world knowledge. The phrases "in the possession of" and "in possession of" mean different things apart from any particular knowledge about police or criminals.

<comment><USER5> Dennis Skinner, member of the British House of Commons, once said in a speech that "half the Tories opposite are crooks!". When asked to withdraw the statement, he said "OK, half the Tories opposite aren't crooks."

So in the presence of 'half', even 'not' can be unpredictable...

<comment><USER6> Amusing... but this isn't the same kind of ambiguity as he intentionally made the negation have the wrong scope. The expected negation would be "It is not the case that half the Tories opposite are crooks".

<comment><USER5> But haven't you then still left the crook-edness of the other half unstated and suspiciously ambiguous?

</comment></comment></comment></comment></comment></comment><comment><USER7> [https://en.wikipedia.org/wiki/Winograd_Schema_Challenge](https://en.wikipedia.org/wiki/Winograd_Schema_Challenge)

<comment><USER8> So I assume that a question-answering RNN will crack that in a year or two.

</comment></comment><comment><USER9> The classical Winograd schema as a Turing test is effectively the voight- kampff test: one could imagine that the council advocated violence, and surreptitiously sought to create say a false flag, but our mirror system and sense of morality make that interpretation less palatable.

</comment><comment><USER10> There is a programming project in Artificial Intelligence named Shrdlite that is a course given at the University of Gothenburg and Chalmers University of Technology. The course also includes the nearley parser to provide a blocksworld, similar to Terry's original work. For more information, see the course webpages:

[http://ChalmersGU-AI-course.github.io/](http://ChalmersGU-AI- course.github.io/)</comment>


Apple's 'key growth driver' in 2020 will be a new $399 iPhone, top analyst says - <AUTHOR> https://www.cnbc.com/2019/10/14/apple-iphone-se2-will-cost-399-and-launch-in-q1-2020-kuo-says.html <comment><USER2> I feel like Apple missed the point with this relaunch of the SE 2. We want SMALL, not necessarily inexpensive. This is just the same inefficiently large phone that pushed me to the SE to begin with. What I think most SE owners wanted was a phone the size of an old SE, but with an edge-to-edge screen and a price point around $500-600.</comment>


Who really runs a site – with short description - <AUTHOR> http://whorunsthis.host/ <comment><USER2> It says our site ([https://wormhole.network](https://wormhole.network)) is ran by Oracle - I might have missed the buy-out and I might be a millionaire! :)

Also, I've tested with news.ycombinator.com with good results, but then I tried with whorunsthis.site and it said "Whoisguard, Inc" accompanied by the YCombinator description. Oh, and the WTF button stopped working.

Hope this helps with something :)

<comment><AUTHOR> Haha, sure thanks! Having trouble properly extracting domains and getting around domain privacy ...

</comment></comment><comment><AUTHOR> I implemented some features you suggested! Would love to get some more feedback.

Direct link to extension: [https://chrome.google.com/webstore/detail/who-runs- this/jfcc...](https://chrome.google.com/webstore/detail/who-runs- this/jfccjdbjpkmppcpdogdfbgillpaakmgn)</comment>


From Cubicle to Startup in 27 Days - <AUTHOR> http://akkuo.com/from-cubicle-to-startup-in-27-days/

<comment><USER2> Good writeup. There were a couple things you probably could have done better (which you probably know).

* Nevada LLC - Half the time I've seen people do it, it's not worth the effort to form a company outside your actual state of operation. Especially not for an LLC, which is already not well suited for companies which plan to take outside investment at any point.

* LegalZoom - This is also usually not worth it. You mentioned in your post that LegalZoom is a major part of your expenses so far. Did you take a few minutes to actually look at your state's website for creating an LLC? Here in Michigan, it's literally a one-page form that takes less than 2 minutes to fill out, with a $25 filing fee. And yet, I meet people all the time here who used LegalZoom to form their LLC.

* Filing an LLC simply for personal protection - A lot of people don't realize that simply filing an LLC does _not_ protect your personal assets. Someone can still try to sue you personally and it's up to the court to decide if your LLC is valid and protects you personally. Filing is easy. But you have to actually operate on a day-to-day basis like a real company for it to hold up in court should the time come. This means doing things like doing _all_ transactions through a separate company bank account, presenting yourself as a representative of your company when you meet potential partners or customers (e.g. making sure your LLC is on your business card), using the LLC for all legal docs, dealing with applicable business insurances, etc. IANAL, so be sure to look up the actual rules of the game for your state.

* Kickstarter title - I didn't think it was that good. It doesn't even mention "iPhone" in the title, so I would have had no clue what you're talking about without visiting the page and reading up.

I don't want to sound like this is all negative though. This was a great writeup of your experience. I especially liked the points about developing a physical product.

EDIT: By the way, your homepage is awesome, especially the "Charge Ready" slide.

<comment><USER3> Hey JangoSteve,

Great points man! We definitely should have looked into California LLC practices a bit more, however we just knew it's an $800 filing fee per year here and we'd experience more taxation than in Nevada.

I think I forgot to mention it, but we did set up a Corporate Checking Account and got Credit Cards in the company's name and that's what we purchase everything through.

Great feedback on the title and I'll make sure the next one does better.

Much appreciated for your time and insights! Jon

</comment></comment><comment><USER4> As you realize, your video needs a lot of work. You need to focus more on the product less on you or your company. We don't see any actual footage of the cable being plugged in, just some rather plain mockups of how it could work. You have a working prototype, show it! Better lighting, better editing and better sound also help give your product more credibility.

This is a good first draft, you just have to go through a couple more iterations.

<comment><USER3> Hey Mustpax,

Agreed...It was done with a friend who didn't have much time to spare, but it was better than what I could produce on my own.

Definitely agree with you on not focusing on us(company) and more on the product. Funny how it's a no-brainer when you look back at it, but during the filming we just simply forgot.

We'll focus on a top-notch video on the next project we work on.

Thank you for you time and feedback man! Every little bit helps. -Jon

</comment></comment><comment><USER5> Hey -- thanks so much to the founders for this well-thought write up. Learned a lot.</comment>