Security: Key Generation

kandjar

From what I read in your documentation:



[quote]

Instead it is encrypted with a random 128-bit number that was picked when 1Password first created your Agile keychain. That 128-bit number is your true decryption key. This key, in turn, is encrypted using your master password.[/quote]



The database is fully encrypted with this randomly generated key.

I'm not so much concern about the 128 bit length of the key than I am about it's randomness...



It's a known fact that computer aren't random machine; at the end of the day, it's gonna be a pseudo-random generated key.

Most PRNGs have a hard time having a full coverage with maintaining a good distribution.

This could definitively lead to weakness while attempting to hack the database.



Would it be possible to have more detail regarding the generation of this random key?



--



[edit]

Regarding this 128b key, changing the master password will just reencrypt the key, the 128b key itself doesn't change, correct?

Assuming I'm willing to wait for the whole database to be re-encrypted with a new key, is there a way to request a regeneration of this key?

[/edit]







Thanks,

Kandjar

jpgoldberg

Terrific questions, Kandjar!



[quote name='kandjar' timestamp='1306300527' post='27720']

I'm not so much concern about the 128 bit length of the key than I am about it's randomness...



Would it be possible to have more detail regarding the generation of this random key?[/quote]



You are absolutely correct that getting good random numbers for these keys is crucial. I remember back in the 1990s when Netscape produced its own secure web server. It turned out that even when they were using 128 bit encryption, their random number generator was only pulling from a 32-bit space. This was a big embarrassment for them when it was discoverd and helped sway people toward using what later became Apache.



But enough history. On the Mac and iOS we use Apple's SecRandomCopyBytes(), which in turn gets its entropy from /dev/urandom. SecRandomCopyBytes is designed to provide cryptographically appropriate random numbers.



I'll have to consult with Stefan about how exactly this is done on Windows, but we most certainly are using cryptographically appropriate sources of randomness.



[quote]

Regarding this 128b key, changing the master password will just reencrypt the key, the 128b key itself doesn't change, correct?

Assuming I'm willing to wait for the whole database to be re-encrypted with a new key, is there a way to request a regeneration of this key?

[/quote]



You are correct. This design choice is similar to what you find in other tools that separate the key from the password such as SSH private keys or GPG/PGP keys.



If you really want to force the creation of a new key, you should export your 1Password data to a 1Password Interchange Format file (1pif). Be careful how you handle that 1pif as it is not encrypted at all. Then create a new 1Password data file and import the 1pif. It is only when you create a new data file that a new key will be generated.



Thanks. These are great questions. Please ask more!



Cheers,



-j

kandjar

[quote name='jpgoldberg' timestamp='1306457838' post='27842']

On the Mac and iOS we use Apple's SecRandomCopyBytes(), which in turn gets its entropy from /dev/urandom. SecRandomCopyBytes is designed to provide cryptographically appropriate random numbers.

I'll have to consult with Stefan about how exactly this is done on Windows, but we most certainly are using cryptographically appropriate sources of randomness.

[/quote]



I see; so potentially, assuming that you own a Mac (or an iPad for example) and a Windows version of iPassword;

it may be better to initially create the database using one OS or the other.



One may have a slightly better random key than the other. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />

Well, I doubt it will matter much; but if you could investigate on what's happening on the window side, that would be really nice.





[quote]

If you really want to force the creation of a new key, you should export your 1Password data to a 1Password Interchange Format file (1pif). Be careful how you handle that 1pif as it is not encrypted at all. Then create a new 1Password data file and import the 1pif. It is only when you create a new data file that a new key will be generated.

[/quote]



I think that's fair enough; it's not a process I would want to do daily or weekly.

So that solution is a perfectly fine and I agree; the fact that the intermediate file is unencrypted requires that much more precaution.



I will have to do the intermediate file process anyway since I'm seriously considering migrating from another password manager (Spb'yuck! Oops, let's stay polite, that's not fair for them) to 1password.

jpgoldberg

[quote name='kandjar' timestamp='1306549032' post='27920']

I see; so potentially, assuming that you own a Mac (or an iPad for example) and a Windows version of iPassword;

it may be better to initially create the database using one OS or the other.[/quote]



I know from Stefan that we are using well trusted cryptographic libraries on Windows as well. I'm just not sure exactly what they are and what our calls to the system are. I'm an old Unix guy, so it is easier for me to answer questions about OS X and I've looked at Apple's Security tools fairly closely. (Indeed the suite of tools in OS X 10.6 have been validated as FIPS 140-2 compliant).



[quote]

One may have a slightly better random key than the other. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />[/quote]

I defer to Stefan about the Windows end of things, but I know that everyone one of us follow expert recommendations in exactly how to use cryptographic routines. We have always understood the importance of good choices for randomness when creating keys.



[quote]

Well, I doubt it will matter much; but if you could investigate on what's happening on the window side, that would be really nice.[/quote]

I'll ask him to respond.



[quote]

So that solution [to changing the encryption key for the entire data base] is perfectly fine and I agree; the fact that the intermediate file is unencrypted requires that much more precaution.[/quote]

Again, I'll have to defer to others about Windows. On the Mac you can use "Secure Empty Trash" or srm from the command line. I'm sure that there are plenty of utilities to properly delete files on Windows, and I suspect that you know more than I do in that respect.



[quote]

I will have to do the intermediate file process anyway since I'm seriously considering migrating from another password manager (Spb'yuck! Oops, let's stay polite, that's not fair for them) to 1password.

[/quote]

I'm glad we are winning your approval. I know that you haven't been happy with every bit of our design decisions, but I am very gratified by your consideration.



On Mac OS X you can securely erase files by putting them in the Trash and then using Secure Empty Trash (or use srm from the command line). I'm not familiar with what tools are available on Windows, but I'm sure that there are plenty.





Cheers,



-j

Stefan von Dutch

[quote name='jpgoldberg' timestamp='1306457838' post='27842']

On the Mac and iOS we use Apple's SecRandomCopyBytes(), which in turn gets its entropy from /dev/urandom. SecRandomCopyBytes is designed to provide cryptographically appropriate random numbers.



I'll have to consult with Stefan about how exactly this is done on Windows

[/quote]



On Windows, we use a combination of CoCreateGUID and a PRNG. To avoid PRNG predictability, we reposition the PRNG frequently using the time of day as a pseudo random seed. The PRNG isn't perfect (none of them are), but the algorithm used to generate GUIDs is extremely complex.

brenty

The important thing to remember is that the purpose of using randomness in cryptography is to avoid predictability. So, while computers themselves are not capable of producing truly random numbers, the use of feedback from unpredictable system processes and environmental noise collected from device drivers and other sources results in unpredictable, pseudorandom (as in, indistinguishable from "truly" random) data which is perfectly suitable for cryptographic applications.



Thanks for bringing this up, kandjar. I showed up late to the party again, it seems, but this was a good read! <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />

jpgoldberg

I'm kind of partial to the [url="http://xkcd.com/221/"]xkcd getRandomNumber function[/url]:



[img]http://imgs.xkcd.com/comics/random_number.png[/img]

kandjar

[quote name='jpgoldberg' timestamp='1306773833' post='28133']

I'm kind of partial to the [url="http://xkcd.com/221/"]xkcd getRandomNumber function[/url]:



[img]http://imgs.xkcd.com/comics/random_number.png[/img]

[/quote]



Lol!!!! Love it!



How about:

[code]

int getRandomNumber()

{

return numberOfWindowsBlueScreenSinceNoon();

}

[/code]



Not as random I guess <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_tongueout.png' class='bbc_emoticon' alt=':-P' />

It's a matter of time elapsed * big numbers <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />

benfdc

I'd been wondering about some of these questions myself. Not too surprised to find a discussion in the forums, and not surprised at all to discover that AgileBits has taken a very thoughtful approach.



I do find it "interesting" that 1P/Mac uses standard OS X resources to obtain FIPS 140-2 caliber "random" keys whereas 1P/Win shuns Microsoft's cryptographic services (some of which are FIPS 140-2 certified) in favor of what strikes me as more of a roll-your-own method.



—Ben F

jpgoldberg

[quote name='benfdc' timestamp='1312313803' post='36128']

I'd been wondering about some of these questions myself. Not too surprised to find a discussion in the forums, and not surprised at all to discover that AgileBits has taken a very thoughtful approach.[/quote]

Thanks!



[quote]

I do find it "interesting" that 1P/Mac uses standard OS X resources to obtain FIPS 140-2 caliber "random" keys whereas 1P/Win shuns Microsoft's cryptographic services (some of which are FIPS 140-2 certified) in favor of what strikes me as more of a roll-your-own method.[/quote]

We certainly didn't roll our on on Windows, but we do rely on a set of libraries that work on all of the Windows versions we support. So that excludes relying directly on tools built into Vista and Windows 7. If we could get people away from Windows XP, that would make life easier.



There is actually some news on the Mac side of things. CDSA and direct support for OpenSSL dynamic libraries are being deprecated and replaced with the Common Crypto framework in OS X and iOS. This is good news for us for a number of reasons. Common Crypto is much easier to deal with and it means that we can share more of our code between Mac OS X and iOS. Also, Apple really seems to be working to get FIPS certification for this moving much faster than it did with CDSA.



Cheers,



-j

benfdc

[quote name='jpgoldberg' timestamp='1306457838' post='27842']

If you really want to force the creation of a new key, you should export your 1Password data to a 1Password Interchange Format file (1pif). Be careful how you handle that 1pif as it is not encrypted at all. Then create a new 1Password data file and import the 1pif. It is only when you create a new data file that a new key will be generated.

[/quote]



Is there a way for Windows users to force creation of a new master encryption key? Last time I checked, 1P/Win could only import logins.



I'm mostly a Mac person, but I'm also something of a 1P evangelist, and I have friends and family whom I have turned on to 1Password who don't have Macs. I'll usually start them out with a "baby" master password and encourage them to beef it up later if they take to the program. But it seems to me that the benefit of changing the master password is marginal at best, because an attacker who can get hold of an older copy of the keychain (user backups, 1Password backups, recovered Dropbox versions, etc.) and break the old master password would obtain the master encryption key. Very few users would have the know-how to hunt down and purge those old backups.



If I had my druthers, users changing a master password would be confronted with a prompt asking whether they also wish to change the master encryption key(s). A help box could explain the costs (time) and benefits (security) of changing the master key(s) to a keychain whose security may have been compromised. This would address two concerns:[list=1]

[*]Users who may not understand what changing a master password does, and does not, accomplish.

[*]Users who do want to re-encrypt their keychains with new master keys but lack the requisite tools or expertise.

[/list]

Whadda ya say?



—Ben F



p.s. There also needs to be a way for the 1Password app to signal the browser extensions to "flush their caches" when a master password changes. It is both confusing and frustrating when a browser extension won't accept the new password, and it's a bit frightening to see the old password work. Where is that old data? How long will it be there? How can I be sure that it's gone?

benfdc

An alternative approach to the new master password / old master key issue (for all I know you might be doing this already) would be to generate a new master key whenever a master password is changed, and to "demote" the old master key for use with legacy entries only. New entries, and edited entries, would be encrypted with the new master key. This would provide the protection that users intuitively expect when they opt to upgrade their passphrase before putting "important" data into their keychain, or upgrade their passphrase before changing/improving login passwords.



Such an approach might improve the correspondence between the protection which 1Password actually provides and the protection which users might intuitively expect based on a simpler mental model of how the program works.



In addition, it ought to be possible for 1Password to update older entries "in the background" after a master password change, so that eventually all of the user's data is encrypted with the new master key and the old master key can be retired. I imagine that there could be pros and cons to this approach, but it could be a better option than the potentially-confusing "Change encryption key too?" prompt that I suggested in my previous post.

jpgoldberg

Ben, you are absolutely correct that the effects of a master password change is not clear to users. We either need to make it clear what it does or make it behave the way that users think it does.



I don't want to go into detail about all of your suggestions. They contain ideas that we've explored. We know that we need to do something, but getting something that works extremely reliably is a challenge. We need a system that won't leave people locked out of their data if there is a power failure or disk crash or system failure during the process. This is one of the reasons why we try to avoid re-encrypting everything during a master password change.



These are all things that we are working on, but it's still a bit too early to tell what our solution will be for our new data format.



Cheers,



-j

benfdc

Either I'm confused or we're not communicating well (or both). Or perhaps I am reading too much into the "[url="http://help.agilebits.com/1Password3/agile_keychain_design.html#hierarchy_of_encryption_keys"]hierarchy of encryption keys[/url]" discussion in your keychain design document. If your current design doesn't allow for multiple keys with the same security level then my "easy" solution may not be quite so easy after all. That said …



The primary system (Dropbox users may have additional options) for not locking people out of their data if there is a system crash, or for recovering data after changing, and then forgetting, the master password, is File > Restore Data File From Backup …



Encouraging folks to burn all of their backups immediately after changing a master password carries clear risks.



But let's set aside the problem of how best to retroactively protect data that was entered into 1Password with a weak master password. My main focus is on a user who wants to increase security by "beefing up" the master password before entering stuff like credit cards and banking logins. If you generate a new master encryption key whenever the user changes the master password, and you simultaneously "expire" the old master encryption key (so that it becomes a decrypt-only key, analogous to an expired or revoked PGP subkey), wouldn't new and edited keychain data be safe even if an attacker obtains, and cracks, an older version of the keychain? And wouldn't that align fairly well with a naïve expectation of the protection afforded by changing the master password?



—Ben F