I like to provide serious replies to jokes, so

In terms of blockchains, new with this JtR jumbo release is support for many additional cryptocurrency-related "formats", such as wallets and more. Please check out the full announcement for a list of added formats. People tend to forget their passphrases, and JtR can help recover weak and partially-forgotten ones. (But not a fully forgotten strong passphrase.)

In terms of AI, even JtR 1.0 released in 1996 was trained on real passwords and used that training to try candidate passwords in order of decreasing estimated probability. That was one aspect distinguishing it from all other password cracker programs of the time. More recent JtR releases include training based on the RockYou leak, but all of them can easily be re-trained by the user on the user's passwords cracked so far, to target further passwords more efficiently (assuming they have greater similarity than RockYou's to those already cracked, and the number of already cracked passwords is large enough to provide meaningful statistics - ideally, millions, but a few thousand also works to some extent). During our tuning of the algorithms, we've also done proper out-of-sample testing (with different training and test sets), etc. - like you would with an AI project.

Others have already explained some of the value of offensive security tools for defense, but FWIW I and others on our team also contributed purely defensive tools, including for password security, and more. Please feel free to check out our website: https://www.openwall.com/

You're right. I know how we got stuck with this versioning scheme so far, but that's not an excuse. I hope we'll have a 2.0 soon, likely to mark the planned merging of JtR jumbo and Johnny the GUI projects into one.

Theoretically. That way, anyone with an OpenCL project could claim FPGA support, but this tends not to work in practice, and would be extremely inefficient (except in terms of much lower development effort) if it worked. I am not aware of anyone having actually run hashcat on FPGA, are you? I know someone (on team hashcat) who tried and failed. JtR also supports OpenCL for many years, but we didn't claim FPGA support until we've introduced Verilog designs and communication framework for specific boards, and confirmed that this actually works.

I agree this is a major problem. A reason why we targeted those boards (ZTEX 1.15y original and their US clones) is that most of them had been mining Bitcoin and were then resold for a fraction of the original price on eBay or such (original started at 999 EUR + VAT, resale prices were $50 to 250 EUR depending on seller and quantity) when Bitcoin went to ASIC-only mining a few years ago. We were hoping this secondary market would last longer, but unfortunately it's already hard to find those boards offered for sale. Perhaps some are still mining certain minor altcoins. I think best bet now is to ask in cryptocurrency forums where owners of those boards were previously discussing their usage.

ZTEX's series 2 boards are unfortunately "overpriced" (and are not resold for less because they were never used for mining much). They won't deliver the same, let alone better, performance per dollar as compared to the resale prices that existed for ZTEX 1.15y boards.

In the future, we might (but perhaps only if we receive funding for this) target the current altcoin mining boards of choice - VCU1525/BCU1525. They still cost a lot (about $4k each), but are really powerful and are also available on Amazon's AWS F1 instances (which are reasonably priced for occasional use). Our current introduction of FPGA support will then serve as a first step - we got to have started somewhere, and we now have these designs we could port over to newer devices (with a lot of effort, but less than starting from scratch without experience).

20 years ago I used to build Linux 2.0.x without module support, and this sort of made sense. It still could make a little bit of sense, but the reality is that current kernels are huge (meaning an increase in vulnerability count, too) and most systems are running distro-provided kernels built with module support anyway.

If you want to protect the kernel from root, you need something other than current LKRG "main" branch. Something like Adam's in my opinion even more controversial LKRG "experimental" branch (in the same Bitbucket repo, feel free to explore), which implements what I call (in e-mails with Adam) BSD securelevel on steroids (oh and yes, I used securelevel 20 years ago too; gave up since), and which I find suitable only for a minority of users (sysadmins) who are able to configure that thing reasonably. Of course, it deals with further module (un)loading, and other "legitimate" ways that root could backdoor the kernel.

LKRG "main" as currently announced is for easier reasonable use on typical systems. It doesn't protect the kernel from root (authorized root, or root obtained via e.g. userspace exploits or, unfortunately, via a subset of kernel exploits that will bypass LKRG), but it detects some kernel vulnerability exploits (no, not only for known vulnerabilities - that's an error in the BleepingComputer & Slashdot story) and protects the kernel from those (as well as from other unauthorized changes, such as Rowhammer bitflips).

Your reference to April fools is spot on. This is our most controversial project ever (as the very first sentence of our announcement says), and on January 29 when we made the announcement I happened to say in a chat with Adam: "i wish it were closer to April 1, but that would have been too long a wait ;-)"

We're not delusional, and we try to do our best not to mislead the prospective users of LKRG (see also my other comments here, and the original announcement).

Yes, we share this concern. What matters even more: will fewer or more systems get compromised as a result? Or even: will the cumulative damage of those compromises decrease or increase? We have no answers to these, yet we feel that an imperfect security measure like this may have its reasonable uses on some systems.

"Only detects known vulnerabilities" is an error in the BleepingComputer article, but regardless - yes, ideally you should be all patched, but realistically you might not be and there might be yet unknown vulnerabilities where LKRG, as long as it's relatively unpopular, will likely just happen to defeat the usual/straightforward exploits for them. That said, we do in fact only recommend use of LKRG for systems where you expect not to be up-to-date with all patches anyway, and ask that admins of better maintained systems think twice before deciding on possibly using LKRG.

Actually, it's one of several errors in BleepingComputer's rewording of our original announcement. I am grateful to them for reporting on our work and I understand that journalists have to reword for original content and copyright reasons, but this inevitably leads to errors, and we'd be happier with people reading our original announcement.

No, LKRG is not just for known vulnerabilities. It is both for currently known and for future vulnerabilities that are yet unknown, but it's limited in the vulnerability categories and exploitation/persistence methods that it will catch.

In the original announcement, we acknowledge that LKRG is highly controversial, can be bypassed, is limited in what it can do, and isn't always a good idea to use. We say that it provides merely the controversial notion of security through diversity (as long as LKRG, or a given branch of it, is not very popular), much like running an uncommon OS kernel would, but without the usual drawbacks of actually running an uncommon OS.

Indeed, that's not perfect security, unlike fixing all security vulnerabilities would be - but realistically the Linux kernel is monolithic and so huge (and growing) and distros enable so much of its functionality by default (including with module auto-loading, ouch) that in practice it will always have plenty of vulnerabilities anyway, and a clutch like LKRG may fit some Linux installs just right, unfortunately. Not make them "secure" - just reduce the percentage of successful compromises in the real world.

We try to give some guidelines on where LKRG may be beneficial (on systems that are not well-maintained or not promptly rebooted into new kernels anyway) and where it's probably not (on otherwise hardened and/or well-maintained and promptly updated/rebooted/live-patched systems). We're not delusional, and we try to do our best not to mislead the prospective users of LKRG.

Presentation slides (view online or download PDF), and links to the paper (PDF) and "dedrop" source code (GitHub):
http://www.openwall.com/presentations/WOOT13-Security-Analysis-of-Dropbox/

USENIX WOOT '13 web page dedicated to this talk, including video and audio (view/listen online or download the video .mp4 via a direct link from there):
https://www.usenix.org/looking-inside-drop-box

(Somehow the Slashdot story only links to a third-party article and to the paper PDF, but not to any of the authors' and the conference's web-based content.)

The existing password hashing methods won't run on GPU well for user authentication, even when they do run well for cracking passwords. They lack sufficient parallelism within one hash computation. This is an issue I first raised in 1998, in pre-GPU context (it applies to recent CPUs as well, and the problem is getting worse with time).

A solution is to define a new password hashing method with sufficient (configurable) parallelism within one instance. We could then consider running it on GPU, unless it is GPU-unfriendly by other criteria. Do we really want to, though? GPUs in servers are not yet common, except in computing clusters. Their reliability may be lower than that of other typical server components. The drivers are currently relatively unreliable as well (although they may be reliable enough if running the same code, with no upgrades). Sure, computing clusters use them anyway, and get them to run reliably enough for their needs, but the extra hurdle and/or risk is there. Will we get embedded GPUs in typical servers soon? Will they be similar to current gamers' or HPC GPUs or not? This is not clear. Then there's Intel MIC, which delivers GPU-like performance, but is a lot closer to a CPU - it will require a lot of parallelism in the algorithm too, but it may run certain types of otherwise GPU-unfriendly code. Is this possibly a better target?

For current GPUs, a better strategy might be to make them inefficient - by using GPU-unfriendly hashes (for cracking, and for validation as well - as a side-effect).

We had a project last summer to research this kind of possibilities, focusing on use of FPGA boards in authentication servers. This could optionally buy us GPU-unfriendliness (if we want to make things more difficult for attackers with GPUs, but not FPGAs, and for botnets, which almost surely will lack FPGAs). We even considered some moderate CPU-unfriendliness of the component that we'd put on FPGA. Specifically, we experimented with bcrypt on FPGA, as well as with much smaller Blowfish-like "non-crypto" cores (not actual Blowfish), so that we could hopefully fit hundreds or thousands of those per chip (and have them somewhat CPU-unfriendly as well). Yuri, our GSoC 2011 student working on this project, did have some of this implemented in an experimental fashion, and some of it even worked (on FPGA boards kindly provided by Pico Computing), but an outcome of the summer project was that this would be time-consuming to bring to desired levels of performance and reliability. At that point, the project was put on hold.

A simpler and cheaper alternative (if there are only a handful of customers for this) may be to use dedicated servers, existing HSMs, or microcontrollers for just the password hashing. Indeed, microcontrollers are super slow, so their only function would be to hold and apply a local parameter, with the rest of the hashing method implemented on the host's CPU and RAM. If dedicated servers are used, they would need to be separate from authentication servers - that is, they won't know usernames, won't have access to any database, won't have any persistent storage except for the local parameter, and the OS and software indeed. They will accept password, salt, and parameters (such as the configurable per-hash processing and memory cost settings), and provide the hash. Thus, their attack surface would be minimal and they'd provide an extra layer of security against network-based attacks. We'd do this with FPGA boards as well, and we'd also have the greater/unusual computational complexity as a security layer (in case the local parameter or its backup copy is leaked/stolen), but well - using typical and pre-existing server hardware, drivers, etc. is just simpler and cheaper unless we start a new business and expect to have plenty of customers (although that might be possible).

Prospective customers for these solutions involving extra hardware would be organizations with large user/password databases (millions of records): social networks, major service providers, banks, some government sites.

Yes, you don't need to reference a dictionary when you approve something as a passphrase. passwdqc does not reference a dictionary for that. However, you mentioned requiring "a couple of punctuation chars" - and this almost ensures at least 3 words (well, it could also be e.g. a single word mangled by inserting/replacing characters, which is why I said "almost"). passwdqc has a similar requirement, although it does not insist on punctuation specifically. For non-repeats, passwdqc insists on there being enough different characters for the required minimum length (not for the actual length - there's no problem with some repetition if the minimum would be reached without those portions anyway).

Sure, but fully going from a passphrase to a phrase-derived short password likely reduces guessing entropy (not the same thing as Shannon entropy, by the way; the latter is even more obviously reduced, but is less relevant). In fact, I think some of the passwords that JtR cracks in its incremental mode (which considers character frequencies) are actually built using the first-letter-of-each-word method. Indeed, many of those passwords will happen to use a subset of possible characters only - those that are more common as first letters of words. In your example, this is defeated by the use of non-letters and capital letters (which may be less frequent than even the least frequent lowercase letters at these character positions), but still. Overall, I think c2RlfV&t would be a decent password for many kinds of uses (if you did not post it, indeed), but it would not provide equivalent security to that of the original passphrase (if that one were not posted as well).

The story was posted at: http://linux.slashdot.org/story/12/07/04/1922244/john-the-ripper-cracks-slow-hashes-on-gpu - please check it out for the comments thread.