I'm not sure that cryptographic library functions should have default parameters, at least for parameters that affect security.

The argument (no pun intended) for default parameters would be to provide a reasonable value for library users who do not have the expertise to select the parameter value themselves.

The problem with this is that if someday the expert opinion on what the default value should be changes, then the library is in an unfortunate position.

If they update the library to match the newer expert opinion, it breaks existing code. If they do not update the library, then new applications using it will get the bad default value. Maybe they can leave the default alone, but make the library generate a warning that the default is no longer good and the application should be updated to explicitly pick a better value.

If the library had not supplied a default value, then all users of the library would have to make a choice. The library documentation could suggest what choice is considered best at the time, but make the programmer actually say it in the code. That way, if expert opinion changes, the recommendation can change and at least new users of the library might use the better value.

> If they update the library to match the newer expert opinion, it breaks existing code. If they do not update the library, then new applications using it will get the bad default value.

This is true for lower-level cryptography libraries like OpenSSL or Libsodium. This isn't true, however, for the sort of higher-level libraries I recommend developers use.

See https://github.com/defuse/php-encryption which implements version tagging in its ciphertext output.

If Taylor Hornby has to publish a version 3 that uses, say, NORX instead of AES-256-CTR+HMAC-SHA256, the first 4 bytes will identify the version of the library that was used to encrypt the original message. Backwards compatibility is transparent to the end user. (Headers are covered by the HMAC.)

There are at two problems with this design principle.

The first is that some crypto primitives, whether you want them to or not, have implicit defaults. For instance, when enciphering data with a block cipher, ECB is an implied default.

More importantly, even if you require options, the characteristics of the different choices can push developers towards insecure implied defaults. Even in a library that forces you to pick a block cipher mode, for instance, developers have a strong tendency to pick ECB because it doesn't require an IV (and very few developers understand the concept of an IV).

I generally think RSA libraries should default to OAEP.

Updating the default doesn't need to break code. There can be some means of querying the default. Or as much as I hate to reference TLS, the default can be a cipher list which evolves over time.

Or something like this: http://externals.io/thread/442#email-12842

'Looks like a competent PHP dev could make a decent living as a crypto/SSL consultant.

Dupe from two weeks ago (plus a few other times that this user submitted it). Conversation here: https://news.ycombinator.com/item?id=13171409

There are really only two points being made on that (very short) thread:

1. That PHP is not as a language handicapped for encryption (but the article doesn't claim that it is).

2. That doing public key encryption in PHP sound like a bad idea.

I happen to agree with point (2), but the other thread doesn't resolve that argument, so we're not missing much.

Never seen it before and I am reasonably acttive here.

It floated near the top of page two for a while then died off. I don't know that it ever landed on the front page for any appreciable length of time.

This is an extremely unproductive comment that has nothing to do with the article.

I know nothing about individual readers' knowledge. However, when addressing the general audience (programmers and in particular PHP developers), I've seen enough projects (both open source and proprietary) that attempted to provide public key encryption to have an idea of the average developer's competence here.

For example, this library for integrating with a payment gateway: https://github.com/pagarme/pagarme-php/issues/29

There are people who can do public key encryption in PHP safely†, but when left to their own devices most people will not. Thus, the headline.

† I would go as far as to claim the global population of full-time PHP developers who can securely implement public key encryption in PHP without outsourcing to libsodium is less than 10.

Do all 10 work at your company, or are the remaining 9 employed elsewhere?

You get called out for using clickbait headlines, and then double down by stating an absurd and baseless opinion. Not a good look, man. Decide what you want; to share insights and information or gain attention.

> Do all 10 work at your company, or are the remaining 9 employed elsewhere?

I'm only aware of one other person who fits the criteria I've stated (many others would if I loosened the "work with PHP full time" restriction).

> You get called out for using clickbait headlines, and then double down by stating an absurd and baseless opinion.

Absurd and baseless?

There are probably very few security researchers that have looked at more application-layer cryptography features than I have, especially those written in PHP. If you know of any: Ask them if they believe my assessment of the PHP community is wrong.

https://paragonie.com/security/advisories

https://github.com/issues?utf8=%E2%9C%93&q=author%3Aparagoni...

You're free to dislike the headline. I've got nothing to say in defense of it.

> You're free to dislike the headline. I've got nothing to say in defense of it

Please don't use such headlines on HN. As this thread demonstrates, they derange discussion.

OK, I thought the "use the original headline" rule was stricter but just reread the guidelines and saw that I was wrong.

Well, you wrote the headline, so I think the real recommendation here is to avoid cutesy headlines.

Nobody is assaulting your ego; you're doing that to yourself. I'm not doubting your experience or knowledge, and I appreciate that you're driven to share it. I can see that you genuinely care, and that your intent is most likely virtuous.

I am, however, suspicious of your approach to and style of communication; as are others. Generating attention is the not the same as interest, man.

It's baseless because you can't quantify how many full time PHP devs there are in the world outside of your own acquaintance. That's not enough information to lend your statements any validity. You can stand on your own merits without trashing everybody you don't know.

> You can stand on your own merits without trashing everybody you don't know.

I think I see the problem here.

You're parsing my statements as a sort of attack on others.

Let's try this: The global population of full-time PHP developers who are qualified to perform brain surgery is probably less than 10.

Is that statement less controversial?

Understanding cryptography isn't exactly a requirement for being a successful PHP developer. Additionally, the folks who do know cryptography very rarely find themselves working on PHP full-time: There's too much industry demand in other areas.

That most developers who work on PHP full-time do not have this particular skillset is NOT an attack on most developers. It's simply an observation and a reasonable consequence of the absence of market pressures.

Also, it's a difficult subject.

Feel free to find out who CiPHPerCoder is before you throw insults ;-)

This is extremely unproductive and has nothing whatsoever to do with the article.

Wouldn't it be more productive if they titled their article with something that describes the content of the article?

> If a belief I hold is wrong, then I don't know it, I merely believe it.

This is true whether the belief you hold is right or wrong.

Looks like blog spam. Third time this user submits the same link and he/she only posts from one domain.

https://news.ycombinator.com/newsfaq.html - See: "Are reposts ok?"

Also, your claim that I only post from one domain is demonstrably false: https://news.ycombinator.com/submitted?id=CiPHPerCoder

Happy to discuss better strategies for raising security awareness among PHP developers if sharing content on HN is viewed as annoying.

Here you go, https://www.reddit.com/r/PHP/

You have -5 karma. The person you're accusing of being a spammer has hundreds of comments here. Moreover, authors are allowed to post their own articles. Please don't crud threads on HN up with pointless personal attacks.