You may have noticed last week that our customer support seemed… perfectly normal, as if our commitment to swift, human-to-human responses hadn’t changed at all. Funny thing about that, because it hasn’t. But for the week, we here at AgileBits were helping customers from a land far, far away.

Most of us just got home from what we like to call AGConf, an occasional gathering of the remote AgileBits crew. For AGConf[3] this year, we visited Now Larimar in Punta Cana, Dominican Republic, and while spandex suits and cosplay were not on the menu (for our team, anyway), we did:

• meet face-to-face
• plow through support tickets
• make sure the beach was there
• get not one but two talks from the indelible Merlin Mann
• philosophize on the future of 1Password and AgileBits
• have some of our best hackathons yet
• go ziplining over the length of seven city blocks
• check in on support tickets again
• make sure the sports bar was there
• try on our new 1Password t-shirts we hope to start selling soon
• check on the pool

Yes, “pontificate” and “drinks” and “beach” were in there, all while making sure the most important part of the company (psssst—that’s our customers) were taken care of. Your eyes also do not deceive you—”the future” and “1Password” were indeed on the AGConf[3] schedule. We have some incredible stuff lined up for 1Password 4 for Mac and beyond, and though I shouldn’t spill anything yet, I sure did consider it.

AGConf[3] was a fantastic success. We had a great time seeing each other, making new friends with the new members of our growing team, answering and collaborating on support tickets as a team in the same room, and introducing Kyle to the Coconut Rum Mojito. In fact, a very special guest and 1Password fan even graced our presence in spirit.

More on that in my next post.

Sometimes, a book comes along that effects change. The kind of change that gets you right [there], in that special place in your data file. The venerable Joe Kissell’s new ebook, Take Control of Your Passwords, may just be such a book.

Through chapters like “Understanding the Problems with Passwords” and “Apply Joe’s Password Strategy,” Take Control of Your Passwords does exactly what it says on the tin—it gives you an easy-to-read overview of why it’s more critical than ever to use a tool that creates strong, unique passwords for each of your apps and services. You can see Joe’s video introduction below, and here he is in the book on password reuse, a topic we’ve covered once or twice here on the Agile Blog:

reusing passwords is a terrible, terrible idea. Just. Don’t. Ever. Do. It.

It would be pretty hard to simplify it any more than that.

When you get to the “Choose a Password Manager” chapter, Joe highlights some of the players in this space but makes it pretty darn easy to Do The Right Thing with a cliff note at the beginning:

Tip: If reading about password manager features makes you drowsy and you’d rather pick one and get on with it, allow me to suggest 1Password. It’s what I use, and I think you’ll like it.

Get 20 percent off!

If you don’t want to take my word for it, though, or if you’d like to read Joe’s approach to such an important topic as taking control of your passwords, we managed to get you a coupon for 20 percent off your order! Just click this link to visit the Take Control of Your Passwords page, add the book to your cart or create a bundle with other great Take Control books, and the 20 percent discount will appear automatically in your shopping cart!

You can think of it like we’re helping you take control of getting 20 percent off your Take Control books! Thanks to Joe Kissell for writing such a useful book and recommending 1Password, as well as the folks at TidBITS Publishing!

Sure, we released the major, year-in-the-making upgrade that is 1Password 4 in December, but we still make the previous version 3 of 1Password Pro, 1Password for iPhone, and 1Password for iPad available in the Purchased section of the App Store on your device. In fact, we still offer our critically acclaimed support to customers who use them!

I bring this up because Dropbox is making some changes that 1Password 3 for iOS users will want to know about, especially those who haven’t used the service for sync yet. If you’re a 1Password 4 user, just keep on passwordin’; none of these changes affect you because 1Password 4 for iOS already uses Dropbox’s spiffy new services.

Long story short: Dropbox is growing like crazy, and it recently made some significant changes to its API, the service that apps like 1Password use to move your data around. 1Password 3 uses the old version of this API, which will continue to work after March, but will no longer accept new users.

If you already use Dropbox to sync your 1Password 3 for iOS data

You’re fine. We worked out a deal with Dropbox to keep that door open for the time being.

If you own 1Password 3 for iOS but never hooked up Dropbox for sync

You may have a decision to make. If you hook up 1Password 3 for iOS to Dropbox before the end of March, you’ll get grandfathered in with our other customers and can continue to use Dropbox for sync past March. If you don’t hook it up, that option will disappear when the clock strikes midnight on Monday, April 1.

No, this isn’t an elaborate and ultimately unfunny setup for an April Fool’s joke. Our April Fool’s jokes are much nerdier.

Give it some thought, but remember you only have a couple weeks to decide. Give 1Password 4 for iOS a look as well. You don’t have to take our word for it, but it really is our finest work to date with over 20 major new features like Web Mode with a full browser and form filling for Logins, Credit Cards, and Identities, the ActionBar, Global Search, viewing attachments, and more.

Either way, we love all our customers and are happy to help with any questions you have!

1Password is moving to using 256-bit AES keys instead of 128-bit keys. We already started this within the browser extensions in the summer of 2011, and the new Cloud Keychain Format also uses 256-bit keys.

Why do you think we are making this move? If your answer is because AES 256 is stronger than AES 128, you’d be wrong. There is a technical sense in which AES 256 is enormously stronger than AES 128, but in every sense that actually matters for security there is no difference. Let me explain.

AES? Keys?

AES (the Advanced Encryption Standard) is a fundamental building block of the encryption within 1Password and most everything else that uses encryption in the modern world. It takes a key and some data (plaintext) as input and transforms that data into something that looks entirely random (ciphertext). The only way to get meaning out of the ciphertext is to use AES and the same key to transform it back into the plaintext. A key is just a number, and AES can work with keys of three different sizes, 128 bits, 192 bits, and 256 bits.

AES, by the way, is always a 128-bit cipher operating on 128-bit chunks of data (blocks) at a time; so when I use expressions like “AES256″ or “256-bit AES” in what follows, I’m just talking about key size.

If you’ve been curious about why 1Password didn’t jump on the 256-bit key bandwagon earlier or why we seem to be doing so now, read on. Even if those particular questions never crossed your mind, this article may give you some insight into what sorts of things go into security choices.

Talking about big numbers

The numbers that we need to talk about are just too big to write out normally. When we are dealing with numbers like 65536, I can opt whether to express it as “65536″ or “2¹⁶“, depending on what is most useful in the context. And maybe when dealing with a number like 2³² I can say things like “4.3 trillion”.

But the numbers we deal with in cryptography are so big that I have to write them in exponential form. The number of possible keys that a 128-bit key allows is just too enormous to write otherwise. Sure, I could write out 2¹²⁸ in words with the help of a numbers to words converter, but it is neither informative nor manageable. Nor would it be useful for me to write out the number in decimal, as it would be 39 digits long.

And one more thing about writing numbers in words: when I do so here, I will be using the US English, short scale, conventions; “billion” means 10⁹, not 10¹².

Searching for keys is harder than digging up bones

Molly (one of my dogs) doesn’t really enjoy dog toys that much, but she will certainly not allow Patty (the other dog) to play with any toys. Molly, then, steals and hide Patty’s toys. Suppose that Molly has a possible 2¹²⁸ sniff-proof hiding places she can hide them in. Also suppose that Patty knows about all of those hiding places, but she doesn’t know which one Molly has used. Patty might try to look in each one until she finds her toys. Searching each and every one of those 2¹²⁸ hiding places until she finds the one with the toy is what we’ll call a brute force attack.

On average, Patty will find the right one after searching about half way through all of the hiding places. This means that, on average, she’ll have to try 2¹²⁷ hiding places before she finds her toys. If you thought it was going to be 2⁶⁴, pause for a moment. In fact, 2¹²⁸ divided by 2 is 2¹²⁷. Each additional power of two doubles the number, so halving the number means just taking one off of the exponent.

Molly might imagine that, to be extra secure instead of using “only” 2¹²⁸ possible hiding places, she might use 2²⁵⁶ possible hiding places. 2²⁵⁶ is enormously bigger than 2¹²⁸. Hugely bigger. Unimaginably bigger. Mind-boggingly bigger, though to be honest, the number 2 is enough to boggle Molly’s mind. In fact, 2²⁵⁶ is 2¹²⁸ times bigger than 2¹²⁸.

Now, I just said that moving to  2²⁵⁶ hiding spaces makes the number of places that Patty would need to search unbelievably, enormously, mind-bogglingly bigger. But Molly would be wrong to think that this made it more secure. Why? Because searching through “only” 2¹²⁸ hiding spaces is already so mind-bogglingly, amazingly and unimaginably hard that there is no gain in making it harder.

How long is long?

Patty is a very fast dog – well, at least in her youth she was. Even today, over short distances, she can outrun Molly, who is ten years her junior. So let’s imagine that Patty could search hiding spaces as quickly as a super computer can add two numbers. Actually, let’s suppose that she gets together with a billion other dogs, each of which can search a hiding place as quickly as it takes a super computer to add two numbers. Working at this unimaginable speed, these billion super fast dogs working under Patty’s direction might be able to search 2⁵⁰ hiding spaces per second, which is about one quadrillion hiding spaces per second. There are about 31557600 seconds per year, so working like a billion super computers, Patty with her friends could check about 2⁷⁵, or 10 septillion, hiding places per year.

At that rate it would take 2⁵³ years (10 quadrillion years) to work through half of the 2¹²⁸ hiding spaces. If we take the universe to be about 15 billion years old, then the amount of time it would take Patty, working faster than the combined power of a billion super computers, would be more than 600,000 times the age of the universe.

In case my analogy has gone too far astray, I’m estimating that, as an extremely fast estimate, all of the computing power on Earth turned to trying AES keys couldn’t check more than 2⁷⁵ keys per year (and really that is a very very high estimate). At that rate, it would take more than half a million times the age of the universe to go through half of the 2¹²⁸ possible AES keys.

Now, single-minded Molly, who will spend an entire day barking at a squirrel up a tree, may think that half a million universes ages isn’t too long to wait. But nobody else would even consider trying such a brute force attack. Patty is a clever dog, and so she wouldn’t even consider trying a brute force attack on 2¹²⁸ hiding spaces.

Patty might try other attacks. She might figure that Molly didn’t pick the hiding place in a truly random fashion, and so Patty might know which sorts of places to search first. Or Patty might try to secretly follow Molly to the hiding place. Or maybe there is a way that Patty can trick Molly into bringing her the toys. Those are the kinds of attacks that Molly needs to defend against. But she gains nothing by increasing the number of possible hiding places, because even if Patty had all of the resources on Earth searching Molly’s hiding places, Patty couldn’t even make a dent before the universe comes to an end.

The difference between zero and zero is zero

The chances of Patty and all of her super fast friends finding Molly’s hiding spot is as close to zero as we could possibly want. Let’s call Patty’s chances in this case ϵ₁ (epsilon 1), a really small number.  If Molly uses 2²⁵⁶ possible hiding spaces instead of 2¹²⁸, the chances of Patty and her friends finding the one with the toys is another number as close to zero as we could possible want. We’ll call these chances  ϵ₂ (epsilon 2). Sure, ϵ₂ is many times smaller than ϵ₁, but both ϵ₁ and ϵ₂ are already as close to zero as we could possibly want. Molly’s practical security gain in using the larger number of hiding spaces is pretty much the difference between ϵ₁ and ϵ₂. That difference, for all meaningful purposes, is zero.

It takes a lot of dog food to keep Patty searching

We all know that dogs like to eat. And we all know that computers consume electricity. As it happens, computation (and inspecting hiding places) has to consume energy. It’s actually the destruction (or overwriting) of information that necessarily consumes energy, but that happens when Patty forgets about a previous hiding place so she can think about the next one. If Patty and her friends could move on to checking a new possible key using the absolute theoretical minimum energy for a single computation, 2.85 × 10^-21 J, she and her pack of billion super fast (and now unfathomablely  efficient) of dogs would require about  1/100th of the total amount of energy humanity uses in a year to work through half of the 2¹²⁸ hiding spaces.

The answers to some questions remain TOP SECRET

I have tried to explain all this to Molly countless times, but she just stares blankly as if to ask, “Well, then why does the US government require 256-bit AES keys for TOP SECRET material?”  Actually, all Molly says with her stares is, “Huh?”. I tend to read a bit more into these than is really there. My only answer to her is that it is the same reason that she likes being blow dried after a bath on her left side, but hates it on her right side. Some things, in the mind of Molly and in government, remain a mystery.

I have some reasonably charitable speculation for why those requirements are there, but it remains speculation, and we can continue that discussion in our discussion forums.

Are 256-bit keys less secure than 128-bit keys?

When Bruce Schneier advises:

[F]or new applications I suggest that people don’t use AES-256. AES-128 provides more than enough security margin for the [foreseeable] future. But if you’re already using AES-256, there’s no reason to change.

people need to pay attention. But paying attention and evaluating doesn’t always mean agreeing.

Briefly, there is a long-known problem with how AES deals with 256-bit AES keys. (Of course in this business a “long-known problem” means about 10 years old.) AES does multiple rounds of transforming each chunk of data, and it uses different portions of the key in these different rounds. The specification for which portions of the key get used when is called the “key schedule”. The key schedule for 256-bit keys is not as well designed as the key schedule for 128-bit keys. And in recent years there has been substantial progress in turning those design problems into potential attacks on AES 256. This is the basis for Bruce Schneier’s advice on key choice.

One of the two reasons why I reject Schneier’s advice is that the issue with the AES 256-bit key schedule only opens up the possibility of a related key attack. Related key attacks depend on things being encrypted with keys that are related to each other in specific ways. Imagine if a system encrypts some stuff with a key, k₁ and encrypts some other stuff with a different key, k₂. The attacker doesn’t know what either k₁ or k₂ are, but she does know the difference between those two keys are.  If knowing the relationship between keys (without knowing the keys) gives the attacker some advantage in discovering the keys or decrypting material encrypted with those keys, then we have a related key attack.

When cryptographic systems are properly designed, related key attacks should not be relevant because good crypto systems shouldn’t use or create related keys. Cryptographers worry about related key attacks on AES because they know that some systems will be poorly designed, so it is still important to build ciphers that aren’t vulnerable to related key attacks. A spectacular case of using related keys with a cipher (RC4) for which related key attacks were easy was probably the design WEP WiFi encryption standard. This is one of several reasons why it is possible to discover a WEP Wi-Fi key after just a few minutes (though remember: Just because it’s easy doesn’t mean it is right or legal).

Each and every encryption key used in 1Password is selected independently using a cryptographically appropriate random number generator. This means that there is no way for an attacker to know of any relationship among keys used or generated by 1Password. There is no relationship among keys.

So why 256 bits now?

I hope I’ve persuaded you that 256-bit AES does not reduce any meaningful threat. Essentially it reduces the chance of a successful brute force attack from effectively zero to effectively zero.

So why are we moving to 256-bit AES keys?

1. There is no longer any reason not to move to 256-bit keys

1Password data needed to be encrypted and decrypted on first generation iPhones. Lots of encryption operations using 256-bit keys would have been slow and would drained batteries faster. On desktop computers, we were able to move to 256-bit keys within our 1Password browser extension. But for our principal data format – the one that is used across platforms – we needed to consider the minimal hardware it would run on.

1Password 4 for iOS requires iOS version 6 (which includes development features that allows for our awesome new Web Mode). This means all the devices 1Password 4 will run on are sufficiently powerful that we no longer need to be concerned about performance issues with 256-bit keys.  The performance concerns that we had in the past—both speed and power consumption—are no longer a concern today.

2. Tougher key derivation

This one is subtle. And I’d like to thank Solar Designer of the Openwall Project for drawing my attention to this. It turns out that a side effect of using 256-bit keys in 1Password can make things even harder for automated Master Password guessing programs, not because such keys are harder to attack, but through a more convoluted chain. Don’t worry if you find this section confusing.

1Password uses PBKDF2 to slow down password crackers that could be used to automate guessing your Master Password if someone gets hold of your data. PBKDF2 is a Key Derivation Function – a system that churns your Master Password into a number that can be used as an encryption key. With our new Cloud Keychain Format, we use PBKDF2 to turn your Master Password into two 256-bit keys. One is an HMAC key, used for an integrity check on the data; and the other is a key used to actually decrypt the master key. To derive that total of 512-bits from your Master Password, 1Password uses HMAC-SHA512 within PBKDF2 in the Cloud Keychain format.

Password cracking systems, like hashcat, can speed up their operations by using GPUs (Graphic Processing Units) which can perform some kinds of computations blindingly fast, but there are some computation artifacts of SHA-512 that make this harder on GPUs. Solar Designer mentions this in his discussion of the future of password hashing (slide 35 and elsewhere).

I did warn you at the beginning of this section that this particular reason is convoluted and subtle. The short version is that a side-effect of using 256-bit AES keys is that it makes PBKDF2 more effective in certain circumstances.

3. People (and Molly) feel better about 256-bit keys

If Molly feels that 128-bit keys aren’t sufficiently secure, she may incorrectly reject systems that use 128-bit keys instead of 256-bit keys. In doing so, she may make choices that actually weaken her security overall. I might not agree with her reasoning, but we do have to recognize that her feelings do matter to her choices. And I certainly want to keep Molly secure. So if by offering 256-bit keys we enable Molly to make better security choices (even if for the wrong reasons), that is a good thing.

As long as there is no reason not to use 256-bit AES keys, it makes sense to use them. We have now reached the point where there is no harm in using 256-bit keys, and so the reassurance that comes with using them is worthwhile.

Now, security is a tough business. And tough people in a tough business can talk tough. When I threatened to shoot somebody if we used the expression “military grade” to describe our use of 256-bit AES keys, I wasn’t expecting that I’d have to shoot the guy who signs the checks. But a promise is a promise. So, Dave Teare, the gauntlet is down. Water pistols at dawn!

In conclusion

If there is any overall lesson here, beyond explaining why we’ve made the choices we have about key size for 1Password, it’s that seemingly simple questions about security and cryptography rarely have simple answers and explanations. On the one hand, we want people to understand what goes on under the hood and the thinking that goes into various design elements; but we also want to make it easy for people to behave securely without requiring that they understand what’s going on at the deeper levels.

A quantum of bits [Update: March 20, 2013]

I reached out to the cryptographic community for any insight into Molly’s question about why the NSA insists that TOP SECRET material be encrypted using 256-bit keys. The answer came from Steven Bellovin of Columbia University:

@jpgoldberg @marshray Just heard that during the AES competition, NSA said in the open meetings it was for defense against quantum computing

Quantum computers, if they are every made practical, will be able to do amazing things. They will certainly change how we design cryptographic systems. It’s not that quantum computers will be faster or more powerful. Indeed, in some very important respects they will be less powerful than current computers. But there are some things that they will be able to do in less “time”.  I put “time” in scare quotes because it has a different meaning in this context from the ordinary use of the word. Oh, what a big difference it is. In this context it means the number of distinct steps an algorithm must take in performing some computation.

Searching through 2¹²⁸ keys (on a classical, non-quantum, computer) takes a number of steps that is proportional to 2¹²⁸. But for a quantum computer it takes a number of steps proportional to the square root of that number, 2⁶⁴. If a quantum computer is ever built capable of performing that task, we don’t know how the actual speed of each individual step will compare to those of current computers, but the NSA is taking no chances. Something with the effective strength of a 64-bit key isn’t strong enough. A 256-bit key against a quantum brute force attack would have the effective strength of a 128 bit key against a classical brute force attack.

I very much doubt that we will see a quantum computer actually capable of handing such things within the next thirty years. But if the past is any guide, my predictions about the future should be taken with a large grain of salt.

 

Yes! Take that, Betteridge’s Law of Headlines!

Of course, we’re on the Facebooks just like the Tweeters and even the Google+es. It’s a great way to stay in touch with us, and it’s great to see that Facebook seems to agree.

If you haven’t seen the news, Facebook announced a pretty big change coming to the News Feed, the place where everyone posts their deep, personal journal entries right next to their Instagramed lunches.

I’ll let you head over and read all about it on your own time, because the real news from all this appears at 1:16 in the video Facebook made (at the bottom of the page). As eagle-eyed AgileBits Caffeinated Problem Solver Chris De Jabet noticed, the 1Password Chrome extension makes a cameo. While I don’t have security clearance to know whether 1Password is company policy over there, it is at least a great reminder that your Facebook account should really have a good, strong password to protect your personal space!

The security of your 1Password data depends on only one secret—your Master Password. It also depends on plenty of things that aren’t secret. For example, 1Password uses the AES encryption algorithm, every detail of which is defined by public standards; your security depends on the security of AES, but there is nothing secret about it.

Another non-secret is the design of our data format, including the Agile Keychain format and the Cloud Keychain Format. Indeed, we have a history of being very open about our data format, and this is good for your security.

Third party apps and 1Password data

Let me jump to the what has prompted this article before returning to the virtues of publicly detailing our data format. Recently there’s been progress on third party tools and applications that can read 1Password data, and there are some important factors to consider about these tools:

• Third party tools for reading 1Password data do not reflect a “break” in 1Password. They, like 1Password, require your Master Password in order to read your data.
• We have to advise you to never enter your 1Password Master Password into anything that isn’t 1Password. We aren’t casting aspersions on the integrity or competence of any developers, but we simply can’t advise otherwise.
• Third party tools are “third party”. Although we may sometimes help them understand the details of our data format, they are entirely independent of AgileBits. The fact that we may maintain a good relationship with them is not an endorsement of what they produce.
• Third party tools exemplify the fact that there is no data lock in with 1Password.

The existence of third party tools for reading 1Password data has had people ask about the security implications of us being so open about our data format. Our openness is a good thing, and here’s why.

No lock-in

Vendor lock-in, roughly speaking, is when you depend on a particular vendor to be able to use what is already yours. An example that many of us face is with ink for inkjet printers.

The manufacturers of various inkjet printers make it very hard for you to purchase ink from any other vendors. Thus, to continue using their printer, you need a supply of their ink. Not only does that get expensive, but if you spent a lot of money on the printer, you need to worry about what might happen if the vendor goes out of business and no longer provides ink. You may not be able to use your printer at all.

I have more than 1500 items in my 1Password data, and it would be absolutely catastrophic if I were to lose access to these. This is, of course, why good backups are essential and why I need a Master Password that I’m not going to forget. “Data availability” is the jargon used for this aspect of data security, and it is one that people often overlook. Years ago, I wrote about the importance of backups in “Keeping your data at your fingertips (Part I)“, then I wrote about being sure you have access to those backups. Now it’s time to talk about part II of that first article: avoiding data lock-in.

Could you lose access to your own password data if we disappeared from the face of the Earth or turned evil? We have no plans to do either, but you should know that even if the worst were to happen to AgileBits, you would still have access to your data. One of the reasons for this is that, once you have purchased a copy of 1Password, you can continue using it forever as long as you have an operating system that supports it. Our (rare) paid upgrades are optional.

The second way we avoid locking you into 1Password is through the ability to export data to a more neutral format. Not all versions are yet where we want them to be with respect to export, and we’re working on that. But there is usually some path, if not always a simple click away, to export your 1Password data.

Enabling third parties prevents lock-in

It’s this third way that we avoid lock-in that is relevant to today’s topic. Our data format design is specified well enough so that people with no connection to AgileBits can write software to be able to handle it. Of course your data remains completely unusable without your Master Password; third party software still needs you to enter your 1Password Master Password.

There are, indeed, at least two projects independent of us, which are developing software that can read 1Password data (once you’ve given them your Master Password.). James Brown (@RogueLazer) has developed some Python libraries which can – given the Master Password – read both the Agile Keychain Format (1Password 2 and 3 for Mac, 1Password for Windows) and the Cloud Keychain Format (1Password 4). Indeed, RogueLazer’s efforts and queries have led to substantial improvements in our documentation. Another project is the very recent release of the tooPasswordapp for iOS. Its developers tell me that they worked straight from our documentation. I should also add that, in its own way, the John the Ripper module for the Agile Keychain data could be called another third party tool.

Without passing any judgement on any third party developers, we have to advise people to never enter their 1Password Master Passwords into anything other than 1Password. I have no reason to doubt the integrity or competence of these third party developers, and RogueLazer’s project is even open-source. But it would be irresponsible for us to do anything other than advise you never to give your 1Password Master Password to anyone or any other application.

So while we can’t endorse those systems, and indeed we have to advise you against using them; their existence is still a Good Thing. They are proof that our openness about our data formats means that you do not have to fear data lock-in.

Kerckhoffs’ Principle: No secrets beyond the key

Kerckhoffs’ Principle states that you should assume that your adversary knows as much about the system you use as you do. This is why – despite what I may have said on April Fools Day last year – security experts are skeptical of security systems that hide the details of how they operate. They are particularly skeptical of systems that derive their security from keeping the details of how they work secret. I could go on at great length about why openness about the system improves security. Indeed, my first draft of this article did go on at great length. I’ll try to be more concise this time through.

Too Many Secrets

If the security of a system depends on the secrecy of the system (in addition to the secrecy of the key) then that secret is actually a vulnerability.

Suppose my two dogs, Patty and Molly, have developed their own security systems. Mr Talk, the neighbor’s cat, wants to break into their systems. Patty has developed hers so that all of the secrecy is in her password. Everything else about the system can be made public. The security of Molly’s system, on the other hand, depends not just on her password, but also on keeping aspects of her system design secret.

Mr Talk will study both systems very carefully. He’s very patient and will pick them apart. As he learns more about Patty’s system, it doesn’t get any weaker. After all, Patty made the details of the system public in the first place. But as Mr Talk learns more about Molly’s system, the weaker it becomes. From Mr Talk’s point of view (that of the attacker), Molly’s system has a vulnerability that is waiting to be discovered through analysis. Indeed, Molly’s system has that vulnerability by its very design.

Public scrutiny

It’s easy to use the Advanced Encryption Standard (AES) algorithm from some standard library in some software and call it secure. AES is certainly strong enough. But unless it is used in the right ways at the right times as part of the right constructions, it would probably be a mistake to call such software secure.

We do believe that we use AES, PBKDF2, HMAC and other technologies in the right ways at the right times in the right constructions. A great deal of care and research went into those sorts of decisions. But the only way for the world to share our confidence is if we document our decisions. Sure, most people aren’t in a position to directly evaluate said decisions, but everyone can take comfort in the fact that there are enough people who can, and do, look at those details.

We’ve been here before, and we’ll be here again

This isn’t the first time Kerckhoffs’ Principle has come up. I specifically discussed it when talking about creating good, strong Master Passwords, when I said that we should use a system for coming up with Master Passwords that doesn’t lose its strength if the attacker knows the system that we used. Kerckhoffs’ Principle also came up (though not by name) in discussion about how 1Password stands up to password cracking tools.

All of this is to say that Kerckhoffs’ Principle runs strong and deep through 20th and 21st century thinking about cryptography. Even if I don’t mention it by name, you should keep an eye out for it.

Yes, that’s right, we’re doing a podcast, we hope you enjoy this first episode. We’ve got more great content for you to enjoy in the coming weeks and months so please do ‘stay tuned’.

Your hosts, Stu & Khad, introduce The 1Password Show and talk about all the new features in 1Password 4 for iOS.

Podcast: Play in new window | Download

You can subscribe to the podcast via iTunes / Podcasts for iOS or via good old fashioned RSS which should work with all those fancy podcatcher apps too.

Show Notes

• Say hello to the new 1Password for iOS
• Toward Better Master Passwords
• 1Password USB Sync
• Security of storing 1Password data in the Cloud
• 1Password 4.1 for iOS adds… way too much great stuff to fit in a post title
• “Open in 1Password” bookmarklet for opening sites into 1Password’s browser
• 1Password 4 for iOS Transition FAQs

Can’t argue with this advice. I mean, look at that guy. He has a beard and everything.

[Note: I'm going to bug our actual design guy to see if he can do a better job of Zelda-fying the 1Password logo. If he's successful, I'll update it here.]

Have you been feeling… not so get-stuff-done-y? Like you could really use a fantastic tool to create and effortlessly use strong, unique passwords for all your sites, save time by filling web forms with a click, and jot down ideas and other sensitive information you don’t want lying around in sticky notes?

Would you perhaps like to acquire said fantastic tool at 50 percent off?

Then head on over to the Mac App Store’s Get Stuff Done Productivity Sale, because 1Password is part of it! For a limited time you can pick up 1Password for 50 percent off, along with a number of other fine Mac apps!

Don’t forget, though: limited time is not synonymous with “indefinitely.” Run, don’t walk.

The newest seat on the 1Password Express has been taken by none other than Poster, the universal WordPress blogging client from Tom Witkins.

Whether you setup a new WordPress blog hosted at WordPress.com or your own web host, Poster will display a 1Password button on the login screen if you have it installed. Tap it, and you’ll quickly switch over to the new 1Password for iOS where you can unlock with your Master Password (if necessary) and search for your site’s Login. From there you can copy your password, double-tap the Home button for the app switcher, switch back to Poster, and get down to writing.

Poster really is a great app, I’ve been using it more often to blog with my iPad. We’d like to thank Tom for making it easier to log in with 1Password!