Getting chilly for charity

I’m not sure if you’ve been on the Internet lately, but there’s this “ice bucket challenge” thing going around. Sure enough, some members of the AgileBits crew were challenged, and in good form … we challenged all of our co-workers.

We’ve made a donation to ALS (as well as several other causes near and dear to our hearts) and thoroughly enjoyed helping our teammates take the plunge.

Now that we’ve done our good deed for the week, we challenge YOU. Make the world a better place. Donate to a worthy cause and dump a bucket of ice water on a friend.

Large even prime number discovered

You have probably been taught that two is the only even prime number. But today mathematicians at the University of Southern North Dakota at Hoople have discovered a new, large, even prime. It is more than a million digits long and is equal to the value of 3²²³⁷⁵⁶¹+3¹¹¹⁸⁷⁸¹.

Many people are under the erroneous belief that two is the only even prime number, but as Professor Paul Forester explains, “tings get really meshuga vhen numbers get large.” For example, when some number n gets very large, it becomes approximately the same as its successor. Because:

\displaystyle\lim_{n \to \infty} \frac{1}{n} = \frac{1}{n+1}

we can see that n must get closer and closer to n+1 when n is very large. So when numbers are pretty much the same as their neighbors at these large values, the notion of odd and even don’t hold in the traditional sense.

What does this mean for cryptography

First of all, this surprising mathematical discovery has no (immediate) bearing on the security of 1Password, as 1Password does not use the kind of cryptography that depends heavily on the theory of prime numbers. But this might have some implications for cryptography. At the moment, the only immediately visible impact is that it should make some of the slowest cryptographic computations quicker and more efficient.

In some cryptographic systems (though not 1Password), the software must generate large, randomly chosen prime numbers. This is a very time consuming process, and it works by first picking large random numbers, then checking whether they are prime through a series of tests. Almost all software implementations of this will only pick odd numbers by setting the least significant bit of the random number of 1. But this excludes half of the numbers it could pick, thus failing to find any of the even large primes.

Testing for primes

Once a random number is picked in the appropriate range it needs to be tested for primality. Many of the tests result in answers that aren’t quite definitive. Indeed, a number of tests produce results of either “definitely not prime” and “possibly prime” and each of these tests may different amounts of time to run. The general strategy is to run the quickest tests first on your candidate number, and only then run the more expensive tests. If your candidate number passes a sufficient number of those tests, then you can determine with sufficiently high probability that the number really is prime.

There is a way, of course, to definitively test whether a number, N, is prime. And that is to attempt to divide by every prime number less than or equal to the square root of N. But while that approach if definitive, it is simply far too many divisions to actually test.

The prime numbers in cryptography

The prime numbers used in cryptographic systems are typically 1024 bits (about 308 digits) long. Pairs of these are generated and multiplied together to produce 2048 bit (about 616 digit) products. Note that when you multiply, say, a five digit number by a three digit number you usually end up with an eight (five plus three) digit number. This holds when using bits instead of decimal numbers. So the product of two 1024 bit numbers will typically be a 2048 bit number.

Even for 300 digit numbers, which are far, far smaller than the million digit prime announced Saturday, it isn’t feasible to run definitive primality tests in the time we need when picking prime numbers. Indeed, it is probably near the edge of the NSA’s capability to factor 1024 bit products of 512 bit primes. This is why it is no longer recommended to use 1024 bit RSA keys.

A note on key sizes

If I am saying that 1024 bit keys aren’t safe, why does 1Password “only” use 256 bit keys? This is because different kinds of encryption systems have different kinds of keys. Keys used for the AES algorithm are completely random numbers. Guessing the key means trying every single 256 bit key until you find the one that works. That just isn’t possible even for a 128 bit key. But for public key encryption systems, not just any public key will do. Not just any 2048-bit numbers can be an Rivest-Shamir-Adleman (RSA) public key. Instead, it must (essentially) be the product of two 1024-bit prime numbers (which are, in essence, the private key).

I say “essentially” in there because if two prime numbers are p and q, then the actually public key isn’t p times q, pq, but is in fact Φ(p)Φ(q), which works out to (p-1)(q-1) in this case. The Φ function is known of as Euler’s totient function. For quite some time, I believed that there was a mathematician whose name sounded like “Oiler” who worked on similar stuff as the mathematician I’d read about, whose name I pronounced “Yuler”. Along the same lines, it was only when someone read the Little Prince aloud that I realized that the word I’d heard as “yu-neek” was the same as the one that I pronounce “un-ee-cue”. I still think of the Prince as “un-ee-cue in all the world.”

Let’s get back to key sizes. Not every public key system uses the RSA algorithm. The Diffie-Hellman (DH) system uses different mathematics, but has key length requirements similar to RSA. 1024 bits is no longer considered secure against the likes of the NSA. The third kind of public key algorithm in use is based on elliptical curves, and is sometimes called ECDH because it is actually based on the same logic as Diffie-Hellman at its heart, though it works through different mathematical operations. One advantage of ECDH is that it works with much smaller keys. So a 256-bit ECDH key is perfectly reasonable.

What to trust in this article

This article was posted on April 1, 2014. The claim that an even prime number other than two has been found is bogus. The notion of odd and even holds for all integers, no matter how large. The fictitious University of Southern North Dakota at Hoople is the creation of the real Peter Schickele. The fictitious mathematician Paul Forester is my resurrection of the great 20th century mathematician, Pál Erdős. Everything else here is actually meant to be reliable information. Including those bits that are un-ee-cue in all the world.

Where’s Eddy?

You may remember that AgileBits won a Macworld Eddy Award in 2013 for 1Password 4 for Mac (We were a little bit excited about it). 1Password 4 has been a labour of love for the entire team, from developers to support, and it was a true honour to be singled out for such a prestigious award.

Well, because the powers-that-be at AgileBits are pretty awesome, they decided to share the honour. So, not only is there a shiny new Eddy from 2013 sitting next to his friend from 2010 on our office shelf, but Eddy is also gracing the shelves and homes of every AgileBits employee! I was completely blown away by this generosity, and it got me thinking: how were the rest of the AgileBits team celebrating the arrival of this shiny award?

As it turns out, there’s some excitement, a little bit of weirdness, and a whole lot of smiles. Check out some of our photos here and give us a like on Facebook to check out the full gallery!

The top 6 worst passwords from the Star Trek universe [Updated]

You would think that, once we master space exploration and how to replicate the perfect cup of Earl Grey, everyone in the future according to Star Trek would understand the necessity for unique, strong passwords.

Unfortunately, you would be wrong. And no, as we’ll see later, biometrics (like voice authentication) don’t seem to help.

As the following evidence from various Star Trek clips shows, some of the passwords used by Starfleet’s finest are weaker than the passwords stolen from the recent Sony and Yahoo hacks. Clearly, these officers could’ve used 1Password.

1. Kirk, Scotty, and Checkov needed our Strong Password Generator

The longest password needed to blow up the Enterprise in Star Trek III is just five characters. My U.S. social security number is longer than that but, fortunately, I’m pretty sure it can’t self destruct anything.

2. It shouldn’t be this easy to eject the warp core

B’Elanna gets points for getting past five characters (yet she loses points for using her own name in her password). But it’s way too easy to strand a ship in the middle of nowhere with a simple “computer!” callout and what is still a weak password.

3. Honestly, who made it this easy to blow up ships

If it was this easy to blow up ships in the 24th century, I’d probably look for abandoned derelicts everywhere I went and do it as a hobby. Those explosions are totally GIF-worthy.

4. Picard’s authorization is so weak, the computer rejects it

Ok, maybe that torn power conduit had something to do with it, but still. If I were the Enterprise computer, I would’ve locked Picard out a long time ago and made him upgrade to a much stronger self destruct password.

5. Chekov’s ship-wide status update password is laughably short

With a password that weak, officers would break into the internal comms every other day and post Burger King-like prank announcements that the Enterprise was switching teams to the Romulans or launching a package delivery service.

6. The password to our shields might as well be 1-2-3-4-5

In Star Trek II: Wrath of Khan, Kirk and Spock are able to remotely shut down the shields of the Starfleet ship Khan “borrowed” by transmitting nothing more than a five-character “prefix code” of 16309.

I know luggage with tougher combinations than that.

Even worse, they looked it up in what seems to be not much more than an Excel spreadsheet of all Starfleet ship prefix codes. What could possibly go wrong?

The clip here doesn’t include the statement of the code. If you want that, skip to around 6:50 in this longer clip. Thanks to Joe Kissell for schooling us on our bad Star Trek passwords.

Honorary mention: Data’s perfect-yet-flawed password

You might think Data created the perfect password that time he went nuts, took over the Enterprise, and mimicked Picard’s voice (hooray for 24th century biometrics!), all in the name of dropping in to say hi to dad. There’s just one problem: he said it out loud for everyone to hear, or at least for the computer to record and tell Picard later.

Did we miss any great moments in bad Star Trek passwords? Let us know on Twitter, Facebook, or our forums!

Use better passwords than Starfleet

Fortunately, the future isn’t written yet. Let’s change your timeline in online security—get 1Password and follow our guides to use our Strong Password Generator on Mac, iOS, and PC so it’s much, much harder to blow up your ship.

Guess what? A Post-It under your keyboard is not the worst place to keep a password

The Sophos NakedSecurity blog has some excellent password security advice to kick off your Monday morning: “Before being interviewed on TV, wipe passwords off whiteboard“. Here’s a shot from TVP, a Polish television channel, that prompted this timely refresher:

Passwords on whiteboard in background of TV interview

Note that “hasło” is the Polish word for ‘password’.

I guess a scrap of paper under your keyboard is no longer the absolute worst place to keep your passwords. But, of course, 1Password users know there is a much, much better way to manage strong and unique passwords.

“Check out my debit card!” Or: why people make bad security choices

Yes, the stories are true, and no, this isn’t The Onion. People are, once again, displaying their affinity for tweeting photos of things that should never be tweeted.

Let’s set the scene and put you in the shoes of a number of today’s (possibly young, possibly naïve) Twitter users: you get your first debit card, you’re excited, you want to tell your friends. But who calls or even texts in private anymore? So you take a quick picture of your newfound glory and power, then tweet about it to not just your friends, but the world—credit card number, your name, and the card’s expiration date; the works.

Don’t believe me? A new Twitter bot, @NeedADebitCard, has been retweeting these posts, and plenty of them.

Blurred version of debit card posted on TwitterThe card that you see at right was posted publicly to Twitter. Note that I’m the one who actually took the precaution of blurring the number, name, and other details. In the original tweet and the many others like it, all of those are fully visible.

Considering that credit card details (along with verification codes, and billing addresses) can be bought on the black market for about one US dollar a piece if you buy in bulk, posting these really isn’t going to be tragic. Most people’s credit card details have been stolen a dozen times over (mostly through breaches of traditional merchants). But tweeting these certainly reflects some bad habits. For the record, the AgileBits store does not keep a copy of your full credit card numbers when you purchase through us. And when you purchase through iTunes or the Apple Mac Store, then we get no information about you or your purchase at all.

Credit card stored in 1PasswordFortunately, you, my informed 1Password-using reader, can keep your credit and debit card details safely stored in the 1Password Wallet instead of posting them to Twitter or Instagram.

I laughed, but I shouldn’t have

I must confess that I laughed when Stu, my colleague here at AgileBits, pointed these out. If we want to stop people from making poor security decisions (and we certainly do), then we need to understand why people make them in the first place. Of course, some people don’t fully understand the public nature of Twitter, and that certainly plans a role in many cases. But there are other aspects of human nature at play.

There are times, and I think this is one of them, when we can’t blame the users. Instead, the blame falls with the designers of the systems that people must use. But before I talk about credit and debit cards, let me talk about Social Security numbers.

Social Security numbers and identity

For those of you outside of the United States who aren’t familiar with US Social Security numbers, they very roughly correspond to national insurance numbers or national identity numbers. They are officially used as tax payer identification numbers, among other things.

When the system was first set up, Social Security numbers were not at all secret. They were used both by banks and by employers so that income could be reported to the tax authorities. Indeed, like many people, I included my Social Security number on a résumé back in the 1980s as a courtesy to prospective employers. These numbers were used for identification in the same way that a name is, except that there are plenty of people who share my name, while I should be the only one with my Social Security number. Knowing my Social Security numbers was never intended to prove my identity. In other words: knowledge of the number was not supposed to be used for authentication.

Let’s consider this distinction between “identification” and “authentication”. Identification is how you figure out who you are talking about. Authentication is how you test whether someone really is that person. For a typical website, your username (or email address) serves to identify you, while your password is used to authenticate that identity. You may or may not wish to make your username public, but you certainly don’t want to make your password public.

Through a convoluted history that I won’t go into (in short, blame the banks), Social Security numbers switched away from being used merely for identification; the came to be used for authentication as well. They got used in a way that they were never designed for. This led to various problems, a number of new laws, and simply helped to muddle the distinction between identification and authentication.

Credit cards are more confusing

When credit cards and debit cards were originally designed, the numbers were pretty much for  used only for identification, though there were exceptions. People would authenticate themselves by having physical possession of the card and by a producing a signature with a pen on a piece of paper. Certainly there was a lot of scope for fraud which meant some care was needed in not making the identity numbers all too public, but still the card numbers were not designed as authentication.

But then we started using credit cards remotely, first by making payments over the telephone and later for use over computer networks. Neither physical possession of the cards nor a signature on paper could be used for authentication any more. So the card numbers themselves, along with the three digit security (CVV), codes became the means of authentication. As with Social Security numbers, we ended up using a piece of information for authentication that was never designed to be used that way.

Here we go again. This time with checks

Over the past few years I found that when I telephone my bank, and after they have identified me, they request my checking account number. It appears that knowledge of my checking account number is now being used as part of their authentication system. Again, account numbers were never meant for this purpose. Indeed my checking account number is printed on every check I write. These are not secret.

The system that we all use has been giving people mixed messages about what is and isn’t secret. Or it’s been trying to use non-secret information in ways that are only appropriate for secrets. On one hand we are told to keep our credit card numbers secret, while on the other hand we are conditioned to toss over those numbers to any hotel, clerk, or waiter.

Helping people get things right

This misuse of Social Security and credit card numbers evolved through a process of changing scenarios and needs at the time, making due with what was available. It’s not a surprise that the system is far from what we would expect if we designed in intelligently from scratch, so of course our existing, incoherent system is going to cause confusion.

When we do have the opportunity to design something from the ground up, we have the responsibility to ensure that it is easy for people to behave securely. We may not always be able to fully succeed in that attempt, but it must be a guiding design principle for anyone who wants security systems to work for people.

Finally, when we observe people systematically behaving insecurely, we have to ask not “how can people be so stupid” but instead “how is the system leading them to behave insecurely.” Maintaining a clear distinction between non-secret identification information and secret authentication information would be one place to start.

Join the discussion in our forums

I’ve created a forum topic to discuss this article. Please join us there.

Cipher of Advanced Encryption Substitution And Rotation

In the rapidly changing world of eternal mathematical truths, we need to innovativize for the sustanation of our competitive advantage. So instead of serving our customer base with the same old encryption algorithms that are used by governments, military, and most of the Internet, we want to provide the world with new, proprietary systems that should clearly set us apart in the marketplace and among the expert community.

With great pleasure, I’d like to introduce our forthcoming encryption system: Cipher of Advanced Encryption Substitution And Rotation (CAESAR).

Rationale for CAESAR

No salt but the finest

Himalayan Rock SaltUsing block equality (described below) largely obviates the problem of obtaining a good salt or nonce in our cryptography. But because we will be transitioning to our new system, there are cases where we still need to find a good salt. Most cryptographic implementations have been written in the C programming language, and so for past decades the fashion as been for C-salt. C-salt, of course, was an improvement on table salt, which entirely failed to discourage the use of tables in cracking passwords.

Times have changed, and C-salt is now passé. Instead people have been discovering the virtues of Himalayan salt. Thus we sent off an expedition to Pakistan, Afghanistan, Nepal, India, and Bhutan to find and bring back the finest and rarest of salts for our encryption recipes. To protect our interests, this salt and its origins must remain secret.

Rotation, modularity, and alphabets

Pretty much all computer ciphers are based on the theory of finite groups. CAESAR is no different. Indeed, despite the fact that we just came up with the system recently, the use of groups and rotation in CAESAR may fairly be said to be precedent setting. Yeah, history can be weird that way.

We are faced with one difficulty in our approach. Our expedition to far off lands described above discovered something that completely shocked us in addition returning with a source of salt. They discovered that not everyone speaks English. Not only did this astonishing discovery lead to our researchers submitting a number of papers to various academic journals (oddly, we have not heard back from them), and caused considerable delays and expense for the expedition itself; it also means that our original rotation would not work as effectively in alphabets that use more than the English letters A through Z.

After careful consideration of this issue, we realized that requiring such people to use English would actually increase their security. They would be using a language that those around them may not be able to read, thus giving them a second layer of encryption. This showed how forward thinking our design was. It automatically provided higher security in some unanticipated cases.

All blocks are equal!

Blockrights designOne of the problem with the kinds of block ciphers is their lack of equality when used in CBC or CTR modes. We, however, want to return the spirit of ECB mode in which all blocks are equal (Credit for this particular insight goes to the people at 0-Day Clothing).

In addition to the fairness issues in support of the notion that all blocks should be treated equally, it must be noted that mathematics is built on the notion of a mathematical function. Ensuring that a given input produces a unique value, turning to something like ECB mode helps restore us to mathematical purity.

Where to from here?

I have provided only a few of the highlights of CAESAR and our new thinking in cryptography. This custom made, bleeding-edge scheme will doubtless place us in a unique position in the security community. Look for more new projects in the future, possibly a year from the date of this article’s publication, April 1. One we are looking at is System of Natural Additive Key Encryption—Overloaded In Layers.