We’re Moving! Come on over and check-out the new place!


After a long time without generating headlines,
things are about to start hopping at GRC

My 5+ year project to address the website login nightmare by eliminating usernames and passwords has its own web forum with more than 1,014 participants at last count. They’re all using their SQRL identities to login with SQRL clients for Windows, iOS, Android and a web extension for Firefox, Chrome and the new Chromium version of Edge. (And you can too!)

The instant I no longer need to be working to get SQRL finished, a day which is fast approaching, I will immediately be back to work on the long-awaited upgrade to SpinRite 6.

This blog has always been hosted at WordPress.org on their servers. But I’ll be hosting this blog’s successor and replacing this one. Our contract here ends next month, and I’m ready with the replacement site… so THIS will be the final notice from this blog.

Since you are subscribed here, I hope you will come over to our new location and re-subscribe there. (One of the many annoyances of not hosting our own blog is that I have no access to the list of this blog’s subscribers… so it’s up to you to re-join over there.)

If you’re curious to learn more about SQRL, you will find links to the SQRL forums there. You can check them out, grab a SQRL client, create your SQRL identity (it’s all free, of course) and see what I’ve been working on for the past five and a half years. I think you’ll find that the time was not wasted.

The replacement blog is at:  https://blog.grc.com

I hope to see you there!  Come on over and say HI!


Posted in Uncategorized | Tagged , , , | 5 Comments

The “Encryption” Debate

“Encryption” is quoted in the title of this essay because encryption is NOT what any of this is actually about. The debate is not about encryption, it’s about access. It should be called “The Device Access Debate” and encryption should have never been brought into it.

Modern smartphones have batteries, screens, memory, radios, encryption, and a bunch of other stuff. Collectively, they all make the phone go, they are all good, and we want as much of each them as the device’s manufacturer can squeeze in. We do not want smaller batteries, lower resolution screens, less memory, less capable radios, or weaker encryption. And it is entirely proper for Apple to boast about the battery life, screen resolution, memory, radio, and encryption strength of their products. The FBI is entirely correct when it says that Apple is actively marketing the newly increased encryption strength of their latest phones and operating systems. That’s as is should be, in the same way that Apple is marketing their device’s battery life and screen resolution. Those are all features of modern smartphones, and Apple knows what their users want. We all want those things.

The fourth amendment to the US Constitution states: The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no warrants shall issue, but upon probable cause, supported by oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized.

The 4th amendment is about managing access. It does not provide that under no circumstances, ever, can duly authorized law enforcement officials enter someone’s home. It provides a managed and monitored mechanism―a compromise―between the privacy rights of the individual and the needs of the citizenry who surround that person. And it is under this 4th amendment that US citizens have enjoyed the balanced guarantee that their home is their castle and that only a lawfully issued search warrant, meeting the test of probable cause, would allow law enforcement authorities a legal right to enter.

Mapping the 4th amendment onto encrypted devices:
Without weakening their devices’ encryption, Apple could arrange to be able to respond to court orders in the United States. If Apple wished to be able to respond to lawful search warrants to unlock their devices, they could embed a single, randomly derived, high-entropy (256-bit) unique per-device key in the hardware secure enclave of every device. This key would not be derived from any formula or algorithm, so there would be no master secret that might somehow escape or become known to a malicious agency. It would be truly random and far too lengthy for any possible brute force guessing attack to be feasible. Upon embedding each individual random per-device key, Apple would securely store a copy of that key in their own master key vault. In this way, without sacrificing anyone’s security, only Apple, on a device by device basis, could unlock any one of their own devices.

This might appear to place an undue burden upon Apple. But this, too, seems balanced. Apple is, as the FBI correctly observed, obtaining great marketing value from the strength of their security technology. It is understandable that Apple would rather not be able to respond to court orders to unlock their devices. But this attitude is not in keeping with constitutional precedent.

Users of Apple’s products would know that our devices sport the latest and greatest strongest encryption, making them utterly impervious to any attacker, hacker, border official, local or foreign government. And that as with the interiors of our homes, only in accordance with due legal process, and Apple’s continuing assistance, could our device be unlocked in compliance with a search warrant. And if, at any time in the future, Apple decided this was the wrong decision, they could destroy their vault of per-device unlocking keys and we would be no worse off than we are today.

Although the perfect math of encryption does provide for absolute privacy, we all know that privacy can be horribly abused and used against the greater public welfare. The founders of the United States, whom many revere, understood this well. Apple should too.

People who intend to comment: Please recognize that I understand there are many additional subtleties, such as handling the demands of foreign authorities. It is probably the case that the applicable laws of each country should be honored. This essay intended only to clarify the confusion between encryption and access, and the scheme I have proposed is sufficiently flexible to accommodate any specific access policy Apple might choose and/or change as needed.


Follow-up, 20 hours later:
I wrote this post to separate the issue of encryption strength from access policy. Much ink and angst has been expended over phrases involving “backdoors” and “weakened encryption.” All such concerns are red herrings because unbreakable encryption simply gives Apple unbreakable access control. Apple could design a completely secure facility to manage unlocking individual devices. Whether Apple should do so is deservedly one of the most critical questions of our time, and is worthy of truly engaging debate. If we decide that we want to leave things as they are, that’s fine. But we should not conflate whatever policy Apple implements with their user’s security. We can have both.

Posted in Uncategorized | 111 Comments

Yes… TrueCrypt is still safe to use.

So opens the short editorial I wrote this morning and placed at the top of GRC’s new TrueCrypt Final Version Repository page.


The impetus for the editorial was the continual influx of questions from people asking whether TrueCrypt was still safe to use, and if not, what they should switch to, and so on. By this time, one of the TrueCrypt developers, identified as David, had been heard from, and his interchange confirmed the essential points of my conjectured theory of the events surrounding the self-takedown of TrueCrypt.org, etc.

Rather than repeating that entire editorial here, I’m posting this as a pointer to it since folks here have thanked me for maintaining a blog and not relying solely upon Twitter.  And also, this venue supports feedback and interaction which GRC’s current read-only format can not.



Posted in Uncategorized | Tagged , | 169 Comments

An Imagined Letter from the TrueCrypt Developer(s)

As I wrote yesterday, we know virtually nothing about the developer(s) behind TrueCrypt. So any speculation we entertain about their feelings, motives, or thought processes can only be a reflection of our own. With that acknowledgement, I’ll share the letter I think they might have written:

TrueCrypt is software. Frankly, it’s incredibly great software. It’s large, complex and multi-platform. It has been painstakingly designed and implemented to provide the best security available anywhere. And it does. It is the best and most secure software modern computer science has been able to create. It is a miracle, and a gift, and it has been a labor of love we have toiled away, thanklessly for a decade, to provide to the world… for free.

TrueCrypt is open source. Anyone could verify it, trust it, give back, contribute time, talent or money and help it to flourish. But no one has helped. Most just use it, question it and criticize it, while requiring it to be free, and complaining when it doesn’t work with this or that new system.

After ten years of this mostly thankless and anonymous work, we’re tired. We’ve done our part. We have what we want. And we feel good about what we have created and freely given. Do we use it?  Hell yes.  As far as we know, TrueCrypt is utterly uncrackable, and plenty of real world experience, and ruthlessly still-protected drives, back up that belief.

But hard drives have finally exceeded the traditional MBR partition table’s 32-bit sector count. 2.2 terabytes is not enough. So the world is moving to the GPT. But we’re not. We’re done. You’re on your own now. No more free lunch.

We’re not bitter. Mostly we’re just tired and done with TrueCrypt. Like we wrote above, as far as we know today, it is a flawless expression of cryptographic software art. And we’re very proud of it. But TrueCrypt, which we love, has been an obligation hanging over our heads for so long that we’ve decided to not only shut it down, but to shoot it in the head. If you believe we’re not shooting blanks you may want to switch to something else. Our point is, now, finally, it’s on you, not us.

Good luck with your NSA, CIA, and FBI.

Please also see Brad Kovach’s blog posting about this topic. Very useful.


Posted in Uncategorized | 105 Comments

Whither TrueCrypt?

My guess is that the TrueCrypt self-takedown
is going to turn out to be legitimate.

We know NOTHING about the developers behind TrueCrypt.

Research Professor Matthew Green, Johns Hopkins Cryptographer who recently helped to launch the TrueCrypt Audit, is currently as clueless as anyone. But his recent tweets indicate that he has come to the same conclusion that I have:

  • I have no idea what’s up with the Truecrypt site, or what ‘security issues’ they’re talking about.
  • I sent an email to our contact at Truecrypt. I’m not holding my breath though.
  • The sad thing is that after all this time I was just starting to like Truecrypt. I hope someone forks it if this is for real.
  • The audit did not find anything — or rather, nothing that we haven’t already published.
  • The anonymous Truecrypt dev team, from their submarine hideout. I emailed. No response. Takes a while for email to reach the sub.
  • I think it unlikely that an unknown hacker (a) identified the Truecrypt devs, (b) stole their signing key, (c) hacked their site.
  • Unlikely is not the same as impossible. So it’s *possible* that this whole thing is a hoax. I just doubt it.
  • But more to the point, if the Truecrypt signing key was stolen & and the TC devs can’t let us know — that’s reason enough to be cautious.
  • Last I heard from Truecrypt: “We are looking forward to results of phase 2 of your audit. Thank you very much for all your efforts again!”

I checked out the cryptographic (Authenticode) certificate used to sign the last known authentic version (v7.1a) of TrueCrypt, signed on Feb. 7th, 2012:


You’ll notice that nine months after being used to sign the v7.1a Windows executable the signing certificate expired (on November 9th of 2012.)

The just-created Windows executable version of TrueCrypt, v7.2, was signed on May 27th, 2014 with THIS certificate:


You’ll notice that the certificate which signed it was minted on August 24th of 2012, a few months before the previous certificate was due to expire, just like we’d expect, and also by the same CA (GlobalSign), though having a longer public key (4096 bits). This all exactly passes the smell test.

In a comment below, Taylor Hornby of Defuse Security noted that “The GPG signatures of the files also check out. The key used to sign them is the same as the one that was used to sign the 7.1a files I downloaded months ago.” So, again, this speaks of either a willful and deliberate act by the developers, or a rather stunning compromise of their own security. While, yes, the latter is possible, it seems much more likely, if also much less welcome, that TrueCrypt has been completely abandoned by its creators.

So, given the scant evidence, I think it’s much more likely that the TrueCrypt team – whomever they are – legitimately created this updated Windows executable and other files which would imply that they also took down their long-running TrueCrypt site.

Which, of course, leaves us asking why?  We don’t know because we don’t know anything about them or their motives. They might be in Russia or China where Windows XP is still a big deal (with a more than 50% share) and personally annoyed with Microsoft for cutting off support for Windows XP.  Or anything else.

What’s creepy is that we may never know.


Posted in Uncategorized | 191 Comments

A quick mitigation for Internet Explorer’s new 0-day vulnerability

The Internet industry press has been milking the news of the end of Windows XP support for much more than it’s worth. Now, over the weekend, we get news of another, in a continuing series of, (0-day) flaws in Internet Explorer.  (Oh My God! It’s the XPocalypse!!)

Or maybe not quite yet.

May 1st, 2014: Microsoft has decided to patch everyone’s
versions of Internet Explorer v6 through v11… even on XP.
So nothing changes yet.  Stay tuned. (And update your IE’s!)

Web browsers are growing incredibly complex. It’s pretty clear that they will be our next-generation operating platforms. And as the last annual “Pwn2Own” contest showed, none of them can currently withstand the focused attention of skilled and determined attackers, especially when some prize money is dangled on the other side of the finish line.

With most recent exploits, the path to exploitation is convoluted and complex and this one is no exception. In this case it depends upon encountering malicious Web content with IE’s ActiveScripting and ActiveX enabled (which is the default in both cases). That will load an Adobe SWF (Shockwave FLASH) file which first prepares the machine for exploitation, then uses JavaScript against the vulnerable version of IE (presently all versions of IE) to exploit a subtle flaw in the age-old and long-ago deprecated VML (vector markup language) rendering library. (Which is, nonetheless, still hanging around “just in case.”)

To immediately protect any use of Internet Explorer – yes, even on creaky old WinXP (the XPocalypse has been delayed):  You must first open a command prompt window with administrative privileges. This is done by right-clicking on the Command Prompt icon in the start menu and selecting “Run As Administrator.” Commands issued within this window will have the privilege required to make system level changes.

32-bit systems only require the first command. But since 64-bit systems have both a 32-bit and 64-bit version of the vulnerable file, both commands must be used with them:

regsvr32 -u "%CommonProgramFiles%\Microsoft Shared\VGX\vgx.dll"
regsvr32 -u "%CommonProgramFiles(x86)%\Microsoft Shared\VGX\vgx.dll"

These commands unregister (-u) the VML renderer, making it inaccessible to the exploit attempt.  Your IE browser will no longer be able to render vector markup language content, but it’s been unused on the web for many years.

You can perform a “before and after” test to confirm that VML rendering has been disabled with this simple VML rendering of an office layout: http://www.vmlmaker.com/gallery/visio/office_layout.htm. The proper response is a BLANK PAGE. If you receive a notice that “A VML capable browser is required…” you must add the vmlmaker.com domain to IE’s “Compatibility View” for the test to function properly. This is done under the settings menu.

Note: An additional test can be performed by searching the Windows registry (search: Data with “Match whole strings only” disabled) for references to vgx.dll. If it is found showing its location as the “Default” data of an “InprocServer32” key, then it is still registered and available.

You can confidently leave things this way.. since you are never going to need VML and, as this circus shows, we’re all a lot better off without it!

(My most recent work: An Evaluation of the Effectiveness of Chrome’s CRLSets.)


Posted in Uncategorized | 106 Comments

The Lesson of Lavabit

An implication of undeliverable security painted a bullseye…Post’s Permalink

On Thursday, August 8th, Ladar Levison, the owner and operator of the semi-secure Lavabit.com eMail system, shut down his nearly ten year old service rather than be forced to continue to comply with United States law enforcement demands for the disclosure of personal and private information belonging to his service’s clients. The Lavabit web site now simply displays this notice:

My Fellow Users,

I have been forced to make a difficult decision: to become complicit in crimes against the American people or walk away from nearly ten years of hard work by shutting down Lavabit. After significant soul searching, I have decided to suspend operations. I wish that I could legally share with you the events that led to my decision. I cannot. I feel you deserve to know what’s going on–the first amendment is supposed to guarantee me the freedom to speak out in situations like this. Unfortunately, Congress has passed laws that say otherwise. As things currently stand, I cannot share my experiences over the last six weeks, even though I have twice made the appropriate requests.

What’s going to happen now? We’ve already started preparing the paperwork needed to continue to fight for the Constitution in the Fourth Circuit Court of Appeals. A favorable decision would allow me resurrect Lavabit as an American company.

This experience has taught me one very important lesson: without congressional action or a strong judicial precedent, I would _strongly_ recommend against anyone trusting their private data to a company with physical ties to the United States.

Ladar Levison
Owner and Operator, Lavabit LLC

Defending the constitution is expensive! Help us by donating to the Lavabit Legal Defense Fund here.

What is the lesson of Lavabit?

When news first surfaced about Edward Snowden’s presumptive use of Lavabit’s eMail service for his eMail communication the assumption was that it was somehow “secure.” So I researched the nature of the service that was being offered, and I was not impressed. The trouble was, it was making a lot of noise about security, but as an eMail store-and-forward service it didn’t (and couldn’t) really do anything that was very useful from a security standpoint: Ladar had arranged to encrypt and store incoming eMail to a user’s inbox in such a fashion that his service could not then immediately decrypt the eMail. It would not be until the user logged in that the Lavabit servers would be able to derive the decryption key in order to forward the then decrypted eMail to the user.

As you can see, while this did offer somewhat useful encryption of data-at-rest, it didn’t actually offer his users any real protection because both incoming and outgoing eMail would necessarily be transmitted in the clear.

This architecture would, therefore, inherently expose the Lavabit service, its servers, its owners, and thus its users’ data to law enforcement demands. Which, it seems clear, is exactly what happened. Ladar made his service a target by offering “security” that wasn’t actually secure. (And how very wrong is it that he cannot even share the exact nature of the demands that were made upon him?!)

I am impressed that Ladar chose to shutdown his service rather than continue to promise something that he now unequivocally knew was no longer secure in the face of law enforcement’s quasi-legal incursions. It would have probably been better if he hadn’t attempted to offer security that was beyond his ability to provide.

During my weekly Security Now! podcast with Leo Laporte, we use the acronym “TNO” (Trust No One) to refer to any system where readily available cryptographic technology is properly employed in such a fashion that it is not necessary to trust the behavior of any third party. Unfortunately, without going to extraordinary lengths (e.g. S/MIME, PGP, GnuPG, etc.), today’s eMail technology is resistant to the TNO principle.

In coming weeks our Security Now! podcast will be delving deeply into the ways and means of producing true TNO eMail security.

Steve's Sig

Posted in Uncategorized | 233 Comments