This tries to evaluate password strength by guessing the next character of your password.
Here’s a Bruce Schneier blog posting on it
I tried it out with a few of my (old) passwords (no longer in use). It was able to guess the next character about 25% of the time, and it was able to guess whole words (I use a variant of passphrases) about 10% of the time. What I want is an offline variant of this that can tell me the true entropy of my passwords. Interestingly, with about half my (old, not longer in use) passwords, it was unable to guess any of the next characters.
I would only use this to test password strength if I had an offline version, AND I had the source code to that offline version.
This points out the weakness in pure passphrases, the entropy is related to the number of words, not the number of characters.
Here are several attempts over the past few years to try to find out who Satoshi Nakamoto, the pseudonymous inventor of Bitcoin, really is.
Satoshi Nakamoto is (probably) Nick Szabo is an analysis of online sources to find writing similar to that of the Bitcoin whitepaper. I don’t know who LikeInAMirror is, this is the only post to this blog. For reference, Unenumerated is Nick Szabo’s blog, and it’s worth reading. Certainly Nick Szabo has strong circumstantial ties to Satoshi Nakamoto and Bitcoin.
Dorit Ron and Adi Shamir (the ‘S’ in RSA) claimed to find a link between Ross Ulbricht (the infamous Dread Pirate Roberts from the Silk Road) and Satoshi Nakamoto. Here is the NYTimes blog posting, here is the second revision of the paper, here is a rebuttal from Dustin Trammell, here is a Reddit thread that’s gathers a lot of information together, and here is a retraction of the claim. So we’re pretty sure Satoshi Nakmoto is indeed not Dustin Trammell.
The article Who Is Satoshi Nakamoto by vice.com has another list of suspects. I hesitate to call them likely suspects.
Joshua Davis, in a 2011 New Yorker article, attempted to track down Satoshi Nakamoto. Here’s a PDF link (not sure whether it’s licit or not, sorry). He turned up a few names, but again, nothing definitive. The individual that Joshua tried to connect to Satoshi, Michaal Clear, went on to publish a rebuttal of sorts. And someone annotated the article.
After the New Yorker article was published, Adam Penenberg wrote on his attempt in an article for Fast Company and turned up a patent application. To his credit, he doesn’t claim the patent filers are Satoshi Nakamoto, but more to point out just how hard it will be to unmask him.
In one of the comments, someone points out that the magic user agent string that bypasses authentication contains the string “backdoor” in reverse.
The article is worth reading on its own as a good example of reverse engineering.
This was a “of course!” moment for me.
Yes, exactly, fingerprints are authentication, not authorization. The fingerprint is a moniker, a hash, a “true name”. In fact, it’s a pretty awesome username, because it’s hard for me to forget it.
But any biometric value is horrible for a password. Once it’s copied, I am screwed, because I can’t change it. This is why biometrics should never be used for passwords, because even if they were hard to copy (and they currently are not), you can’t change them.
Now, one big challenge is that authentication in the current parlance combines identification with proof of identification – the combination of userid and password is the authentication. So we should have three things:
- identification – who you are. Anyone can know this.
- authentication – id + password. You prove that you are you.
- authorization – authentication + rights. You can now access some specific thing
Authorization without authentication is just “here is a set of things that anyone is allowed to access”. Public domain is a set of rights attached to the user “anyone”.
I’d love to see iOS 7.1 with the fingerprint just being the id, and then there’s still a traditional and optional password. This would be far more secure for most people, because most people don’t use a password on their phone, but it doesn’t pretend to be actually secure, you need a password for that.
Or a second phone to do the phone-in authentication to use the first one
Biometrics (the use of your own biological data as a key to a lock) sounds cool and awesome.
And it’s a disaster. Why is it a disaster? Because it’s the one password you can’t change. So if it’s hacked, you’re permanently screwed. And to date, they always get hacked, easily.
Tsutomu Matsumoto in particular has been able to defeat many biometrics systems with literally dollars in parts.
At best, this kind of thing would be a secondary or tertiary piece of information. At best.
It has an excellent pedigree – one of the main developers is Daniel J. Bernstein, who has a very enviable record of making robust software.
Something new from the NSA: The SIMON and SPECK Families of Lightweight Block Ciphers
In this paper we propose two families of block ciphers, SIMON and SPECK, each
of which comes in a variety of widths and key sizes. While many lightweight
block ciphers exist, most were designed to perform well on a single platform
and were not meant to provide high performance across a range of devices. The
aim of SIMON and SPECK is to fill the need for secure, ﬂexible, and analyzable
lightweight block ciphers. Each offers excellent performance on hardware and
software platforms, is ﬂexible enough to admit a variety of implementations on
a given platform, and is amenable to analysis using existing techniques. Both
perform exceptionally well across the full spectrum of lightweight applications,
but SIMON is tuned for optimal performance in hardware, and SPECK for optimal
performance in software.
Bruce Schneier had a comment on this: SIMON and SPECK: New NSA Encryption Algorithms
I don’t know anything about the context of this paper. Why was the work done, and why is it being made public? I’m curious.
I don’t think he was alluding to nefarious aims, but just an honest “um, thanks?”.
An Introduction to OpenSSL Programming (Part I) by Eric Rescorla (the author of the main SSL/TLS book). This is a good companion piece to the book.
Use OpenSSL with Asynchronous Sockets, I/O Completion Ports and Ceritificate Signing has a lot of useful details on mixing and matching SSL and sockets.
Secure programming with the OpenSSL API, Part 1: Overview of the API article from developerWorks.
Cleaning up the build process for OpenSSL on Windows: http://codefromthe70s.org/sslimprov.aspx
The OpenSSL mailing list is at: https://groups.google.com/forum/?hl=en&fromgroups#!forum/mailing.openssl.dev
This is a copy of the original SSLv2 spec: http://www.webstart.com/jed/papers/HRM/references/ssl.html