On Sat, Jun 14, 2014 at 08:43:06PM -0400, Andy Dougherty wrote:
http://blog.booking.com/hardening-perls-hash-function.html , with the old
hash function it was possible to mount an meaningful attack on perl5's
hash function. Working code to demonstrate this was posted to the
perl5-security mailing list. Obviously, that code was not made public.
That's fine. Nobody is asking for that code, I think. It should also be
easily reproducible, and not very interesting.

Neither is anybody asking for personal details of people who might not
want to be known. Nor other details of the attack, that is simply boring.

What I am askign for is the evidence that shows the new method is actually
secure against these attacks, as Yves repeatedly has claimed to exist and is

There is no need to keep such knowledge secret, UNLESS the whole thing is
mere obfuscation.

Given that there are known alternatives who _cannot_ suffer from the
attack (and that are employed in other scripting languages), there needs
to be evidence that is strong enough to show that the new method is at
least as secure, otherwise it's faulty.

What you and others seem to propose is that there is a secret piece of
knowledge that is required to maintain the security of perl.

If this were true, that would be both a dangerous precedent, because to
maintain Perl, one must have access to the secret cabal that controls this
knowledge, which puts maintainers of forks at a security disadvantage
which simply is nonethical, it also would prove it is mere obfuscation -
real-world cryptography algorithms aren't secret, and the only reason to keep
analysis or knowledge secret is either to prolong the lifetime of a
expected-to-be-insecure algorithm or to give the people holding the knowledge
an advantage over the rest of the world.

Surely, this cannot be the goal?

Nothing is lost, and a lot is to be gained, if it were admitted that the
security fixes are mere obfuscation designed to stall attacks and slow down
analysis for a while, while an actual solution is being sought.

It is telling that every time I suggested an alternative (such as falling
back to a safe algorithm once the attack is detected), these parts of my
arguments were _completely_ ignored, while the powers that are go for an
unproven ad-hoc algorithm that is impossible to maintain and whose *sole*
security rests on yelling at everybody who points out there there isn't
any security.

So take your pick: either it is mere obfuscation, or it is unethical
because required information to maintain perl is withhold.

I personally go for the former.
His changes have rendered that attack ineffective. That is more than
mere obfuscation. It is a concrete improvement. It was a real security
I am sorry to bring the message to you: You do not understand
obfuscation. As I have explained already, it's easy to obfuscate your
hash function so that the same attack will no longer work. Claiming that
this also means the method is secure against trivially-modified (or more
sophisticated) attacks is simply a non-sequitur.

Try it with logic: What you are claiming is that anything that renders an
attack ineffective isn't merely obfuscation. But since obfuscation (e.g.
by replacing the hash function with similar one) *can* (and generally
does) render an attack ineffective, your reasoning must be wrong.

I understand well that there is a set of keys that cause havoc with e.g.
perl 5.006, and that that set of keys doesn't work anymore. I also expect
that no similar static (small) set of keys does exist.

What I do not understand is why people make the obvious non sequitur of
then claiming that other sets of keys don't exist, that those sets of keys
cannot be created with reasonable effort and that the internal state isn't
leaked (which requires some form cryptography that simply isn't in the

If all you want to protect against is some script kiddie using a fixed URL
he found on the internet, then you are completely overdoing it: simply
adding some per-process constant to the hash output will suffice.

That cannot be the goal, can it?
My goal is to eiher do it properly, or not at all. Yves goal is obfuscation,
to make analysis harder, in the hope to deter attackers, rather than any
actual improvement in security.
If it becomes significantly harder to analyze that an attack using that
vector becomes impractical, then that indeed is an actual improvement
in security.
No. What that does is simply deter the good people who would actually try
to analyse the security. It doesn't deter the bad people who just want
to cause problems. Nobody honest is interested in analysing obfuscation,
there is nothing to gain there. Only the bad people can gain from that.

This is why obfuscation is dangerous - it gives a false sense of security.

The other dangerous aspect is the sheer amount of effort that people
invest on this list to silence actual security discussions, foremost among
them Yves himself.

That is certainly not how security processes work.

                 The choice of a Deliantra, the free code+content MORPG
       -----==- _GNU_ http://www.deliantra.net
       ----==-- _ generation
       ---==---(_)__ __ ____ __ Marc Lehmann
       --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de
       -=====/_/_//_/\_,_/ /_/\_\

Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2021 Grokbase