Slashdot Mirror

While the NIST curves are suspect, slow, and problematic in a number of other ways, there are fast and safe elliptic curves.

BIND suffers from the fact that it's a database program without a real database inside. It dates from the days before UNIX/Linux had database programs. Almost the only other major UNIX/Linux program with that problem is Sendmail, which should have died decades ago. (QMail should have replaced Sendmail, but the author does not promote it well. He does, however, offer a $500 reward for anyone finding a security bug. That's been offered since 1997, with no takers.)

There isn't really anything better out there. The "standard" cryptographic algorithms like AES, SHA-2 and RSA have received the most public scrutiny by far.
If you think the NSA can break those, you have to ask why they can't break whatever other, less tested primitive you are proposing we use instead.

You probably want to use longer key lengths than the minimum recommendation anyway, especially for public key cryptography - it's cheap.
Specifications with magic numbers are more suspect, but this has been known for a long time. You could use elliptic curves that weren't chosen by the NSA, like Curve25519.

http://vimeo.com/18279777

http://cr.yp.to/talks/2010.12.28/slides.pdf

(Bernstein on Elliptical curve cryptography.)

This should be the default github license:

http://cr.yp.to/publicdomain.html

If you don't care enough to specify a license, you should abandon your copyrights to it.

Did the author of the summary read the article? The article for some reason mentions individualized video feeds for every American which is unrealistic and nothing like the sort of thing anyone has said the NSA is recording.
12,000 PB is far, far larger than the 272 PB estimated to hold all US domestic phone calls for a year, plus the foreign and international calls (which people forgot the NSA captures).

I recommend people read the archive.org description of the problem of archiving phone calls (TL;DR 272 PB) and DJB's article on cryptanalysis (PDF) (TL;DR NSA isn't stupid).

The author of the summary was Cold Fjord -- that's all we really need to say.

Did the author of the summary read the article? The article for some reason mentions individualized video feeds for every American which is unrealistic and nothing like the sort of thing anyone has said the NSA is recording. 12,000 PB is far, far larger than the 272 PB estimated to hold all US domestic phone calls for a year, plus the foreign and international calls (which people forgot the NSA captures).

I recommend people read the archive.org description of the problem of archiving phone calls (TL;DR 272 PB) and DJB's article on cryptanalysis (PDF) (TL;DR NSA isn't stupid).

Thank you, yes, I was speaking of file system corruption. And because any ongoing email management, such as deleting or even marking as read or unread the old messages, causes change in the content of the mbox file, from the message edited onward, the claim that "it's only risking messages after the point where you edit" is disingenuous. I'm afraid it's not "ignorance" speaking, it's lengthy and painful experience.

_If_ the mbox files re absolutely static, then mbox can be considered reasonably stable. But if the messages are resorted into new folders, or even worse if the oldest, earliest entries are ever deleted, then the contents of the mbox file _from that message forward_ have to be rewritten. There is no graceful way with most filesystems to simply "snip this 3095 characters content out of the middle between the start and end of this particular message". The means used can be fascinatingly clever and complex but normally involve overwriting _everything after the beginning of the removal_ with the remaining, preserved old content. And we could explore further what happens on the disk when you actually try to delete content after a certain point in a file, and how that churns the underlying filesystem itself, but it's heavily filesytem dependent.

This means that touching the early entries, and any accidents that occur, corrupts anything after those early entriees. It also means that touching those mbox files causes filesystem churn, becuase the files no longer match the old files and have distinct contents. Unless deletions or additions fo the entries somehow aligns with the old blocks, even most deduplication based filesystems will fail to optimize. And the tendency of some old mbox users to keep _everything_ in simple, large mbox "folders" which are actually single mbox files compounds the issue with backup problems tied to very, very large files, and tied to small edits of those very, very large files causing churn in the backup system.

Having an RFC for an older, simpler protocol does not make it ideal for modern use. mbox was useful when filesystems were distinctly slowed by many hundreds or thousands of files in one directory, and when the number of inodes available for your home directory and the ability to monitor or mange a mailbox in a consistent format was critical. But Maildir and various tools based on it have, correctly, replaced it. The filesystem issues are one critical reason, and the other is what Dan Bernstein talked about when he wrote Maildir: safe locking or transaction handling for multiple simultaneous client access. (See http://cr.yp.to/proto/maildir.html)

Maildir successfully follows one of the critical lessons of robust programming. If you make only small changes, you make only small mistakes, and the message handling is vastly safer from adding, deleting, or relocating small files than from merging or extracting individual messages stored in a necessarily vulnerable single archive.

I run qmail for sending/receiving mail (on Gentoo; netqmail package), using maildir, of course. On top of that, I run the Courier IMAP server on my internal network (with TLS encryption). Until a few months ago I used Mutt as a client (console-based), but I've moved to using Roundcube (web-based email), which I initially installed for my wife, and have been happy with it. I also have some automatic filtering to folders via Maildrop (another Courier utility; it looks at a ~/.mailfilter file to route mail).

Roundcube/the IMAP server's search is OK most of the time - I keep my inbox small and move older mail to sub-folders - when I want to do advanced searches or search large mailboxes I log in and grep through folders of interest; this works well with the maildir format with one file per message. Maildir was also quite resilient when I had a HD crash and needed to recover some lost mail (block scan for blocks that look like mail headers found most missing items, and I do better backups now - mail is under ~/.maildir and gets backed up automatically).

I would move older messages to maildir (there are plenty of mbox converters, and almost anything non-proprietary should be convertible to mbox or maildir via existing programs or a short perl script) - even if at some point maildir dies off entirely, which seems unlikely, converting it to another format will always be trivial due to its simplicity and it has the advantages mentioned above of being able to search easily with grep etc.

Oh, wait, it's the arcfour key scheduling thing again.

This is an old arcfour weakness, not news. Everybody knows about it (and how to avoid it). The SSL people just never bothered to do it.

According to the slides, this attack works by exploiting a bias in the output of RC4, not the key schedule at all...

Slides from a Bernstein talk
A quote:

Summary so far:
DNSSEC does nothing to improve DNS availability.

Neither does DNSCurve.

DNSSEC allows astonishing levels of DDoS amplification, damaging Internet availability.

Which is not a problem of DNSSEC per say but a basic problem of DNS. It is also solvable. It just requires will to deploy the solutions.

DNSSEC does nothing to improve DNS privacy.

This was a explicit non goal of DNSSEC.

DNSSEC, even with NSEC3, leaks private DNS data.

No more than DNS leaks private data.

Slides from a Bernstein talk
A quote:

Summary so far:
DNSSEC does nothing to improve DNS availability.
DNSSEC allows astonishing levels of DDoS amplification, damaging Internet availability.
DNSSEC does nothing to improve DNS privacy.
DNSSEC, even with NSEC3, leaks private DNS data.

qmail. I understand the author offered a security bounty that's never been paid out.

$500 would buy maybe a day's labor from a competent security researcher. Maybe two days back in 1997. That's a pretty tiny incentive for someone to do work on a speculative basis.

qmail. I understand the author offered a security bounty that's never been paid out.

Doesn't mean it's invulnerable.

qmail. I understand the author offered a security bounty that's never been paid out.

The US is in trouble because of mindsets like yours - the belief, brainwashed into children from birth, that America is somehow a shining beacon of freedom, unique amongst the world. And in particular the belief that the Constitution is somehow better or more powerful than other countries equivalents. Reality check: many countries have constitutions. And most of the ideas that form of the basis of US government were formed by, gosh, foreigners!

It is especially a problem for you because as far as I know, there is no punishment in the United States Code for passing laws or regulations that are unconstitutional. Or if there are, they're apparently ineffective. The result is that the US Government, quite independent of any other nations, routinely wipes its ass with the entire document and passes laws that they know full well flatly contradict the constitution (in spirit, wording or both). Here are a couple of blatant examples from recent history.

(1) The Magnitsky bill. This is a bill of attainder - it enumerates the people it intends to punish. Bills of attainder are explicitly forbidden by the constitution because they were abused throughout history. The constitution says "No Bill of Attainder or ex post facto Law shall be passed". Doesn't get any clearer than that.

(2) ITAR. This was a law that censored free speech by cryptographers, in a ham-fisted attempt to stop knowledge of cryptography from spreading (apparently the USG believed non-Americans were too stupid to develop the maths themselves). It was struck down by the courts and then re-passed as EAR, which was struck down again. The constitution says "Congress shall make no law ... abridging the freedom of speech". Doesn't get any clearer than that. Yet what was the punishment for the Congressmen and bureaucrats who, on learning that their law was unconstitutional, immediately re-passed it? Nothing!

And that's ignoring all the other obvious problems like the abandonment of the warrant system (4th amendment).

You blow all this off as if it can be blamed entirely on "them". Get over it. The "us" versus "them" mentality that typifies US thinking will eventually cause your country to slide ever further into authoritarianism.

Okay, so first, what you want is a message authentication code (MAC).

The "industry standard" for MACs is HMAC-SHA-1 or HMAC-SHA-256. You should consider using one of these if at all possible. There are many robust implementations of these, which may also contain protection against less obvious attacks like timing attacks.
(These typically have a verification function that take the message, the given hash, and the key, and returns true if the message is valid. E.g. crypto_auth_verify )

If you really do need the performance and are willing to use a bleeding-edge algorithm, there is nothing technically wrong with using BLAKE2's keyed hashing mode. (Use blake2*_init_key(), or pass a key and keylen to blake2*())
Though if you are going to cut it down to 64 bits anyway, you should also check out SipHash, which is even faster and is geared towards this use case. It uses a 128-bit key and outputs a 64-bit hash.

There are much more efficient hashes than MD5 that would work as well for fewer clock cycles. http://cr.yp.to/hash127.html comes to mind.

Just like quicksort(3) is far faster than bubblesort so too is a highly threadable code faster than non-threadble code

First, just to be pedantic, I'll point out that quicksort is as bad as bubblesort in the worst case, to a constant factor (you should have picked heapsort or mergesort). That aside, it is worth noting (and I am somewhat bothered by this when it comes to TFA) that we still do not know if it is even possible to optimize any program by parallelizing it; see the NC-vs-P question:

https://en.wikipedia.org/wiki/P-complete

Multithreading is not a magic bullet, and in all likelihood it is not generally applicable.

Languages do not, contrary to belief, express intent, the provide a strict set of instructions that the computer MUST respect

Wrong on all counts. Imperative languages are a way to convey instructions to a computer; declarative languages do not convey instructions, and programming in a declarative language requires an entirely different mode of thinking (it is closer to asking a question that giving instructions). It is also not strictly necessary for the computer to do exactly what a program expresses; there has been some work on compiler optimizations that have a (tunable) chance of not maintaining soundness.

In the end a good algorithm with no compiler help will beat optimized "dumb" code in all cases larger than "toy" (say, a few dozen "n" in Big-O notation)

If you are convinced of this, try implementing something more complex than the algorithms you see in Knuth's books; say, this:

http://eurocrypt2010rump.cr.yp.to/9854ad3cab48983f7c2c5a2258e27717.pdf

Then ask yourself this: could the constant factors in your implementation be better? At the end of the day, big constant factors will hurt your performance so badly that you might as well have used an asymptotically worse algorithm; indeed, consider fast integer multiplication:

https://en.wikipedia.org/wiki/Sch%C3%B6nhage%E2%80%93Strassen_algorithm

10000 digits are needed before that algorithm actually outperforms the asymptotically worse Toom-Cook family of algorithms. Here is an even more extreme example:

https://en.wikipedia.org/wiki/Coppersmith%E2%80%93Winograd_algorithm

Sure, that's a better matrix multiplication algorithm in the asymptotic sense...but only for matrices that are so large that you cannot even store them on today's computers.

So really, while you are right that asymptotic improvements will always beat constant factor improvements (which is what compilers are mostly going to do for you), you are wrong to ignore the importance of constant factor improvements. In the real world, constant factors matter. In the real world, quicksort and mergesort will use asymptotically worse algorithms below a certain problem size because of constant factors. In the real world, large integer multiplication is done using Karatsuba or Toom-Cook methods, not FFT methods, because of constant factors. In the real world, if you are not using a compiler to optimize your code, your code is going to be slower than it needs to be, even if you spent hours hand-tuning it, unless you are only dealing with toy problems.

According to the (extensive) benchmark data here, this is even slower than the previous SHAx.

Somewhat disappointing, when both Skein and Blake are about twice as fast, and appear to be perfectly acceptable from a security standpoint. (From what I have read anyway.) So, out of curiosity, what is the argument for keccak that puts it ahead?

That's nice if you have a selected Intel chip, but many sold today lack such modern extensions, including the i3 you mention.

For the rest, it would great if SSH supported high-speed software crypto like Salsa20 or the improved ChaCha variant. Even on my ancient Athlon 64 fileserver, Salsa20/8 and ChaCha8 would give me perfectly usable crypto at < 5 cycles/byte. That is roughly 400MB/s, and modern chips get closer to 2 cycles/byte and at twice the clock rate with more cores. At this point, aggregate crypto performance is several GB/s, and hardware AES is basically unnecessary.

Unfortunately, I'm stuck with AES which is slow as hell. Or AES-XTS on disk, which is even worse. The Salsa20 key/iv setup is virtually free, and while it is not suited to generic block crypto, it would be perfect for an encrypting filesystem. (XSalsa20 affords 24 bytes of nonce within which to put a transaction# + disk ID + block# avoiding all the expense of a mode like XTS.)

That's nice if you have a selected Intel chip, but many sold today lack such modern extensions, including the i3 you mention.

For the rest, it would great if SSH supported high-speed software crypto like Salsa20 or the improved ChaCha variant. Even on my ancient Athlon 64 fileserver, Salsa20/8 and ChaCha8 would give me perfectly usable crypto at < 5 cycles/byte. That is roughly 400MB/s, and modern chips get closer to 2 cycles/byte and at twice the clock rate with more cores. At this point, aggregate crypto performance is several GB/s, and hardware AES is basically unnecessary.

Unfortunately, I'm stuck with AES which is slow as hell. Or AES-XTS on disk, which is even worse. The Salsa20 key/iv setup is virtually free, and while it is not suited to generic block crypto, it would be perfect for an encrypting filesystem. (XSalsa20 affords 24 bytes of nonce within which to put a transaction# + disk ID + block# avoiding all the expense of a mode like XTS.)

Hmm, and totally unrelated, nobody's using Hash127 either ...

Since this is about BIND, let me start the inevitable thread about the BIND alternatives.

BIND is the swiss army knife of DNS servers. It has a lot of features and can do pretty much everything. It's also a big binary and sometimes difficult to configure. CVE

Unbound and NSD are a suite of DNS servers from the same people. One (NSD) puts your web page on the Internet; the other (Unbound) looks for web pages on the Internet. NSD CVE Unbound CVE

PowerDNS (which like Unbound/NSD, is two separate programs) has a lot of flexibility with connecting to databases or what not to resolve a DNS name. Used by Wikimedia, among others. CVE

MaraDNS. I think it's the best one, but my opinion is a little biased. It was once a single program, now two separate programs (like Unbound/BSD and PowerDNS) Easy-to-configure; tiny binary suitable for embedded systems. CVE

DjbDNS. Great tiny two-program DNS suite. Hasn't been updated since 2001 and yes, it has security problems (I'm already taking bets that a follow-up to this post will pretend DjbDNS is magically perfectly secure). Zinq is a currently maintained unofficial fork.

There are many many other DNS servers, both open source and non-open source. Rick Moen has a great list of the open-source ones

Actually, anything by DJB is both well organized and terrible to read at the same time. Also, never GNU licensed but still.

He gives us a few case studies which show problems in the current layout: http://cr.yp.to/slashpackage/studies.html

If you care to read slashpackage page, you'll see he suggests something like gobolinux does.

If you think it's worth a lol, then do you think you can make a grand in prize money?

djbdns - if you want a secure one.

Not so fast:

http://cr.yp.to/djbdns/ipv6mess.html

I've replied in detail to this article before, but my main point remains: Bernstein's attacking a strawman version of IPv6. Real IPv6 implementations have gateways that allow IPv6 clients to contact IPv4 servers. This removes most of the problems he discusses.

http://marc.info/?l=openbsd-misc&m=128822984018595&w=2

While these are interesting objections, and appear to be objects to real problems in IPv6 rather than imagined ones, none seem like showstoppers.

http://cr.yp.to/djbdns/ipv6mess.html:

... after all, once IPv6 is working, we can move everything to IPv6, so who cares about IPv4? The problem is that this mistake has gigantic effects on the cost of making IPv6 work in the first place.

That's what's wrong, and why it's going to be a mess.

Don't create replacements that can't grandfather in what they replace. FFS.

IPV6 has implementation issues, AND it has some engineering mistakes built in. it's not that simple.

http://cr.yp.to/djbdns/ipv6mess.html

http://marc.info/?l=openbsd-misc&m=128822984018595&w=2

It can be rolled out over time and quietly fade out V4.

Why would we ever want to "fade out" IPv4? Why should we? The IPv4 network has worked, robustly and reliably for 30 years. Running out of address space is not a good enough reason to totally drop interoperability with this working standard.

"there is one network that has aol.com and cnn.com and cs.utk.edu and an incredible number of other sites. Normal people call this network ``the Internet.'' They insist on being connected to the Internet, so that they can exchange email and web pages and so on with other Internet sites.

IPv4 is going nowhere fast. IPv6 either supports connections to the internet, i.e. to IPv4 sites, or else it will remain an essentially academic exercise.

UNOFFICIAL COMMENT: Cryptanalysis of Skein

http://cr.yp.to/hash/skein-20101206.pdf

The IPv6 Mess.

Seems like a solid critique, but I haven't found any proposed solutions of how it could have been managed more smoothly. Were there any?

The IPv6 Mess.

http://cr.yp.to/djbdns/ipv6mess.html

-paul

GPS's don't use UTC for the simple reason that using a discontinuous time system at the low-level is insane. The Russian GLONASS does have leap seconds, and every time a leap second get applied the system has hiccups (as expected). The GPS system simply keeps its own true seconds-since-the-GPS-epoch counter and never steps this for leap seconds. Adding the leap seconds is left for the display routines in the individual end-user GPS devices.

As I see it, it really doesn't matter what UTC does as long as computers implement the low-level (internal) timekeeping correctly. If un*x/linux were to have a true seconds-since-the-epoch counter in the kernel with no leap seconds then time difference calculations would be trivial. Each program wouldn't have to have special (and probably largely untested) logic to deal with the time discontinuity around leap second time. Leap seconds (just like daylight-savings-time/normal-time) could be added by the display routines that map seconds-since-the-epoch into a human readable time. There is no need to muck up the low-level timekeeping for these oddities. Only programs that print out the time would need to even know that a leap second occurred, and in most cases that would all be done by the library routines.

Dan Bernstein first tried to get this low-level stuff straightened out, but folks largely didn't care to fix the problem because POSIX essentially mandated one do things in the more complicated fashion. http://cr.yp.to/proto/utctai.html

I'd like to introduce you to Dan Bernstein, creator of QMail and DJBDNS.

Certainly, he could've accepted that BIND, Sendmail and Postfix were functional, but what fun would that be?

Even if Dan isn't self-respecting, I'm sure there are many (myself included) that respect him.

http://cr.yp.to/export.html

sure it's free speech vs export rather than free speech vs copyright, but a lot of what DJB did with respect to submitting all sorts of documents designed to blur the lines between software and speech is relevant to this argument.

http://cr.yp.to/clockspeed.html

clockspeed uses a hardware tick counter to compensate for a persistently fast or slow system clock. Given a few time measurements from a reliable source, it computes and then eliminates the clock skew.

sntpclock checks another system's NTP clock, and prints the results in a format suitable for input to clockspeed. sntpclock is the simplest available NTP/SNTP client.

taiclock and taiclockd form an even simpler alternative to SNTP. They are suitable for precise time synchronization over a local area network, without the hassles and potential security problems of an NTP server.

This version of clockspeed can use the Pentium RDTSC tick counter or the Solaris gethrtime() nanosecond counter.

I'm convinced that IPv6 has been such a pain to move to because they didn't think about a transition plan from IPv4 at all.

http://cr.yp.to/djbdns/ipv6mess.html

And as an aside, is a 128 bit address really necessary? Couldn't we have gotten along with a 64 bit address? 1.8e19 addresses seem like enough for a long time, too.

That's one of the major flaws of the transition plan: not making IPv6 addresses just a superset of IPv4 addresses. If they had, legacy IPv4 systems would still be reachable from IPv6 systems, just not vice-versa, and everyone would automatically be upgraded to "on IPv6" as soon as their OS's protocol stack and applications were upgraded.

... the browser will automatically alter the response ...

This smacks of the thinking behind PHP's magic quotes.

Microsoft's so-called security experts should have known that this was a bad idea, especially if they'd worked with the UTF-7 XSS vulnerabilities. Any time you take a parsed language and haphazardly change the way that it parses, you're opening the door to security holes. That's probably why Dan Bernstein, years ago, said "Don't parse" in his page about qmail security.

I am secretly hoping this was a Bind error wishing everyone would switch to the far superior http://cr.yp.to/djbdns.html

Actually I'm pretty sure BIND 9 was advertised as a near-complete rewrite too.

That said, I'm not touching either version ever again after using http://cr.yp.to/djbdns.html

Their focus on security was a result of needing to distinguish themselves in the free marketplace.

Ah, so that's how the practice of corporal mortification first originated. Crowded marketplace and all. In the modern guise, carborundum Kevlar asbestos underpants.

You can tell a lot about a software developer by whether the developer considers features a liability or an asset, and how much bad is accepted along with the good. I can hardly think of a line of work one is less likely to "stumble into" for lack of any other obvious way to distinguish oneself. Sure, anyone out there can toss these off:

D. J. Bernstein / Papers

For recreation, he writes up Putnam competition solution sets.

Security researchers as a clan seem to share a taste for mortification culture. Half the time, DJB writes likes he's either wearing a hair shirt or knitting one. Anyone else witnessed his epic rant "Var is my hair shirt"?

Oh, and along with specializing in the warm Caribbean waters of security research, we'll go ten years without missing a biannual ship date, since we're casting about for anything trivial to up the flag pole.

I once had a math-geek acquaintance with underdeveloped social skills who decided to balance the equation by becoming an avid sky diver. Last I spoke to him about this, long ago, he had by some miracle survived 80 dives, and a few close calls, including once with his arm tangled in his main which was fluttering above him like a limp condom. Before he decided to risk tangling his reserve, it caught some air and he descended hanging by a partially dislocated arm.

I once asked him what's the difference between the main and the reserve, aside from the basic fact that it's smaller and tends to lead to a hard landing (which probably feels soft as butter until the adrenaline wears off).

His answer: you need extra certification to pack a reserve, and the one or two people at each club who do this (more often that you'd like to think) are almost always close to sober.

There's a lot of people in the Linux camp who seem to reason along the lines that "if it doesn't get used much, it shouldn't exist". Which translates in my metaphor to death by popularity.

There is a decent amount of it. I use Mueller's book, Tom's Hardware and similar, plus with hardware manufacturer websites. There is also this: http://cr.yp.to/hardware/build-20090123.html

The fastest code that I know of for AES in CTR mode is Kasper-Schwabe. It does 8 128-bit encryptions at a time, so it also should be suitable for, say, PMAC if you doctor it. I believe that it does not handle decryption (outside of CTR mode where it's the same as encryption) or other key sizes. Modes other than CTR lose some optimization, and should be ~20% slower. It should be available on Kasper's homepage. It requires SSSE3 and reportedly achieves 6.9 cycles/byte on Nehalem for CTR mode.

My code is available here. On Nehalem, it achieves ~9.4 cycles encrypting, ~11.1 cycles decrypting in essentially any mode. It is suitable for encryption or decryption, and supports all three key sizes (longer keys are slower, of course). A newer (unreleased, experimental) version makes slight performance improvements (maybe down to 9.1 cycles encrypting on Nehalem) and implements an optimization for CTR mode that brings it down to ~7.5 cycles. Email me (mhamburg AT cs DOT stanford DOT edu) if you want to try the experimental version. However, my code fundamentally requires SSSE3, and it performs quite poorly on Conroe.

Also, Dan Bernstein (homepage) has somewhere a fast conventional (not timing-attack resistant, but not requiring any sort of SSE) implementation of AES for several processors, and I've heard Crypto++ is pretty fast too.

I believe that all of the above libraries are public-domain and patent-free.

Out of curiosity, what's your application? Can you just get a VIA Nano or Intel Westmere core and run on that?

"Today, we are introducing an experimental new incentive for external researchers to participate."

D. J. Bernstein did the same thing in 1997, offering a reward for finding bugs in qmail: http://cr.yp.to/qmail/guarantee.html

Daniel J Bernstein has a fix for spam - his Internet Mail 2000. You can see it at:

http://cr.yp.to/im2000.html

Regards,
    Bill Drissel