But is it secure?
[b]How are the passwords stored? [/b]
[b]Is the backup encrypted? If so with what algorithm? [/b]
[b]Is the master password salted?[/b]
I see a quote from a comparison of password managers during last years Black Hat Europe conference "[color=#000000][font=arial, helvetica, sans-serif][size=3]Belenko said that he himself had been using 1Password Pro, which may be the most-installed password manager for Apple iOS. But he ceased using it after testing the application's cryptography. "When we recovered my master password in five seconds? That was a moment," he said."[/size][/font][/color]
[url="http://www.informationweek.com/security/encryption/security-fail-apple-ios-password-manager/232602738"]ref [/url]
Without answers to these questions I have no idea if the backup or shared file that's generated by 1Password is simply a packet of my secret info just waiting to be opened by people who will do terrible things with the contents.
Comments
-
Khad from Agile actually responded directly in the comments to the Information Week article linked above, providing link to Agile's response at http://blog.agilebits.com/2012/03/16/strong-security-requires-strong-passwords/
The Information Week article was vague at best, and since the researchers were discussing iOS apps it's likely that they were in fact using much shorter passwords or numeric PINs commonly used in 1Password 3.x, rather than the longer and more complex ones encouraged for use on the desktop app. IMHO this is a big part of the reason that 1Password 4 now uses the "real" Master Password rather than creating a secondary, lower-security version for iOS data.
The design of the Agile Keychain used in 1Password 3 has also been documented at http://help.agilebits.com/1Password3/agile_keychain_design.html I believe the 1Password 4 format has changed slightly and I don't think it's been documented yet but it's a safe bet that it improves on the earlier baseline design.Flag 0 -
Thanks! Those are both very informative articles but I'm still curious however to see articles specific to version 4. Did they end up using [color=#333333]PBKDF2 on the iOS platform? Are they actually using AES 256 as suggested they would? Sorry to poke and prod, but specifics are important. [/color]
[color=#333333](I should mention that the linked articles are great for details, but they're written for version 3 with a mind for future development)[/color]Flag 0 -
[quote]Did they end up using PBKDF2 on the iOS platform? [/quote]
Yes. We issued an update days after the Elcomsoft paper was published nearly a year ago:
http://blog.agilebits.com/2012/04/09/1password-ios-pbkdf2-goodness/
[quote]Are they actually using AES 256 as suggested they would?[/quote]
In the new iCloud format, yes.
We should have some more technical details specific to version 4 available soon.Flag 0 -
Hi all. These are some great questions!
Let's separate out a few of them as there are a number of separate questions.
As Khad already pointed out, we addressed the specific concerns of the Elcomsoft research back in March and April. I've never really had a chance to write about padding oracles and why so many developers (including us) using standard library routines ended up being caught out by it. And I'll resist the temptation to go into that now. So yes, we added PBKDF2 to iOS back in April (it was a bit tricky to get this for devices running iOS 3) and also took steps that thwarted the particular attack that the Elmcomsoft research mentioned.
So now let's talk about what we have today.
Because 1Password is an encryption system it is the data formats that matter. Security questions are about what happens if someone captures the data.
There are three data formats to consider.[list=1]
[*]Agile Keychain format (used by 1Password 3 and 1Password for Windows)
[*]The new Cloud Keychain format (currently used only for iCloud syncing, but will eventually replace the Agile Keychain)
[*]The local format (on iOS this is an SQLite file with encrypted data in the records.)
[/list]
The local formats are subject to rapid change, so I'm not ready to document that yet. The quick answer is PBKDF2 is with 256-bit AES encryption of all data, including Title and Location (URL) information. All with appropriate salts and initialization vectors.
The Agile Keychain format has already been well discussed. It uses PBKDF2 all the appropriate salts and so on, but leaves some information (Title and URL most notably) unencrypted.
1Password 4 is our first publicly released phase of transitioning to the Cloud Keychain format. So I'm going to keep my answers to the technical questions focused on that. A lot of this is based on some documents that will be appearing "any day now".
[quote]How are passwords stored?[/quote]
I will take this question to be about Master Passwords. Your Master Password isn't stored in any form. Instead a pair of Key Encryption Keys (KEKs) are derived from it using PBKDF2. The specific details are that we use PBKDF-HMAC-SHA512 with a number of rounds calibrated when the Cloud Keychain is first created, but with a minimum of 10,000 rounds. It is salted with 16 bytes of salt. (All random items such as keys, salts, IVs are taken from the cryptographically appropriate SecRandomCopyBytes, which in turn uses /dev/random )
This gives us 512 bits of KEK, which we split into a 256-bit derived encryption key and a 256-bit derived MAC (Message Authentication Code) key. The derived MAC key is used to see that the stored encrypted master key hasn't been tampered with. If it hasn't, then the derived key encryption key is used to decrypt it. That master key is a 256-bit AES key and a 256-bit MAC key. It is used to decrypt the item specific keys that we have for each item.
The derived keys (encryption and MAC) are derived from your Master Password. All other keys are created randomly.
This helps me keep track of all of these different keys:
[i]Each item key's encrypted with the master key[/i]
[i]And the master key's encrypted with the derived key[/i]
[i]And the derived key comes from the MP[/i]
[i]Oh hear the word of the XOR[/i][
[i]Them keys, them keys, them random keys[/i] (3x)
[i]Oh hear the word of the XOR[/i]
[quote]Is the backup encrypted?[/quote]
Your data is always encrypted, and so backups are in the same format as the actual data (which is encrypted).
[quote]Is the master password salted?[/quote]
Yes (16 bytes of salt) But we go beyond just hashing and salting. Take a look at
[url="http://blog.agilebits.com/2012/07/31/1password-is-ready-for-john-the-ripper/"]http://blog.agilebit...ohn-the-ripper/[/url]
for a better understanding of why.
[quote]Are they actually using AES 256[/quote]
Yes.
Anyway, I've gotten behind on getting this fully documented for people, so I will head back to that task.
Cheers,
-jFlag 0 -
Jeffrey, thanks for your answer! Your song makes me laugh. It's just right for the holiday season <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/smile.png' class='bbc_emoticon' alt=':)' />
You've understood my concerns accurately. The important aspect is the format or layers of encryption applied to the data because that is the primary attack vector, with the most associated risk. I like the level of detail and appreciate that you've taken the questions seriously.
But now for one final doozy. How long must the master key be to take 25,100 and 1m years to brute-force given current, generally available CPU and GPU speeds? Are there significant advantages of using parallel processing to speed this up? (If I had the inclination and time I'd try to come up with an answer myself, but I think you're in a much better position to answer it accurately.)
Again, thanks for the replies. In the end these can be great reasons to use your product! And as such you might just put this info into the promotional literature as well! <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/smile.png' class='bbc_emoticon' alt=':)' />Flag 0 -
On behalf of Jeffrey, you are quite welcome! <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />
There is actually a handy chart in the aforelinked John the Ripper blog post:
http://blog.agilebits.com/2012/07/31/1password-is-ready-for-john-the-ripper/
Most folks don't know what any of the above means, but we have some technical documents with the details for geeks like us who are interested. As Jeff mentioned, we have him working hard to update them for the new Cloud Keychain format at this very moment.
http://help.agilebits.com/1Password3/agile_keychain_design.html
http://help.agilebits.com/1Password3/cloud_storage_security.html
Please do let us know if you have any other questions.Flag 0 -
I use 1Password on an iPhone and an iPad with syncing via iCloud.
As I know Apple uses server-side-encryption. That means Apple basically has the possibility to access data. Does this also affect data of 1Password?
To make it clear:
Are 1Password data 'double encrypted' by Apple's encryption and 1Password's encryption? That would mean 1Password's data could not be decrypted by Apple.Flag 0 -
[quote name='TerryP' timestamp='1355589410' post='65467']I may be wrong. But as far as i know, the titles of each entry are not encrypted at all. At least in 1PW3.[/quote]
Thanks for your reply.
Sorry, but I have to say that this was not my question.
Titles do not include sensitive data so its not important whether they are encrypted or not.
Are the main data (user, password, ...) encrypted in a way that even Apple's employees cannot access the data with theit server-side key when stored in iCloud?Flag 0 -
Welcome to the forums, iNotes4You! Good question. I merged your post with this existing thread.
The short answer is that all data synced via iCloud is encrypted. It is not possible to read even metadata like titles of iCloud data without the master password. Please see above for some more details and let me know if you have any other questions.Flag 0 -
[quote name='khad' timestamp='1355604739' post='65486']Welcome to the forums, iNotes4You! Good question. I merged your post with this existing thread.
The short answer is that all data synced via iCloud is encrypted. It is not possible to read even metadata like titles of iCloud data without the master password. Please see above for some more details and let me know if you have any other questions.[/quote]
Thank you very much khad.
As a normal user with less knowledge in security designs you get crazy if starting investigations about the question 'Are my data secure when using the awesome iCloud?'. The articles you refer to are very helpful and answered my question.
My suggestion however is to make that point clear to the public. I am living in Germany and there are many many articles about the poor security of iCloud and Dropbox. They all refer to the Terms and Conditions of cloud providers with the words 'APPLE (, ...) HAS THE KEY'. It is not mentioned that there are secure solutions like that of your company. Sorry to say that some articles on your website are helpful for insiders but too cloudy and too long for the public. I am a software developer too and we all must keep the KISS principle in mind if we talk to the public.
Sensitive data are not only credentials but also documents created with iWork applications or documents scanned with the camera of an iOS device.
Would't it be a great extension to 1Password to store these informations too?
Thank You very much again.Flag 0 -
[quote name='TerryP' timestamp='1355589410' post='65467']
I may be wrong. But as far as i know, the titles of each entry are not encrypted at all. At least in 1PW3.
[/quote]
We reworked the iCloud format to fully encrypt everything include item titles. Also, the encryption was upgraded. You could see the iCloud data by logging into http://developer.icloud.com or (probably) in ~/Library/Mobile Documents folder on your Mac.Flag 0 -
[quote name='roustem' timestamp='1355677389' post='65601']
We reworked the iCloud format to fully encrypt everything include item titles.
[/quote]
Thanks for this. I didn't realize this.Flag 0 -
[quote name='roustem' timestamp='1355677389' post='65601']
We reworked the iCloud format to fully encrypt everything include item titles. Also, the encryption was upgraded. You could see the iCloud data by logging into [url="http://developer.icloud.com"]http://developer.icloud.com[/url] or (probably) in ~/Library/Mobile Documents folder on your Mac.
[/quote]
Does this mean, the encryption includes the titles and everything, even if i don't sync with the cloud, but exchange the file with iTunes? Or is this a "cloud-only" feature?Flag 0 -
[quote name='TerryP' timestamp='1355681393' post='65620']
Does this mean, the encryption includes the titles and everything, even if i don't sync with the cloud, but exchange the file with iTunes? Or is this a "cloud-only" feature?
[/quote]
At the moment it is only used in iCloud. We hope to start using the new format everywhere once Mac and Windows apps can support it.Flag 0 -
Hi all,
The gory detailed specification doc for the Cloud Keychain format really will be published soon. (Other documents that explain things that explain those gory details will follow.)
Let me elaborate a bit on what Roustem said. At the moment, only 1Password on iOS supports this new format, so it is being used for iCloud syncing among iOS devices only. But once 1Password on Mac and other platforms support it, you will see it used more broadly. Because of all of the platforms we support, we need to phase in the new format piecemeal.
As for the "encrypting everything", Title and Location are fully encrypted in the Cloud Keychain format. Some metadata (creation time, etc) is still available. Here is an excerpt with a complete list of what is NOT encrypted:
[quote]
#### Unencrypted metadata
{:.no_toc}
Some metadata remains unencrypted: Which folder an item is in; what category (Login, Credit Card, ...) an item belongs to; creation time; modify time; and last sync time. Additionally file creation, modify, and access times will typically be available from the filesystem.
The item [UUIDs](#uuids) are fully available, which can be used to determine how many attachments, if any, an item has associated with it. The UUID of any folder an item belongs to is unencrypted.
[/quote]
Everything else is fully encrypted in the data file.
Cheers,
-jFlag 0 -
I am an absolute layman when it comes to encryption algorithims/software, but after quickly purusing this thread discussing the additional icloud algorithm improvements that encrypt additional data types (metadata etc.), I wonder if you could explain excactly what type of data is unencrypted/exposed in the existing 1Password 3 and 1Password 4 Dropbox compatible keychain formats? The reason I am asking this, is as you know that if you wish to synch a 1Password 3 file on a Mac with an iPad or iPhone you currently are forced to use the Dropbox synch method since iCloud keychain formats are not currently compatible with the Mac and we will have to wait until 1Password 4 for Mac is released (with an unknown schedule).
I am asking this because Agilebits seems to be promoting synching only through Dropbox/iCloud in the future because of its decision to drop the local wifi synch feature (with no user friendly alternative provided or planned in the near future). In a separate thread on this forum I understand that you are trying to explain to us that even if the Dropbox server was hacked and our keychain stolen, brute force methods would still be impractical to break the password if a strong password was used in the first place. But I am getting the impression from this thread that some data types are unencrypted in the keychain code and can be potentially read and examined by a hacker without even breaking the password. Exactly what types of data are currently unencrypted in the current 1Password 3 keychain?
I apologize in advance if this question is not properly phrased in the correct technical terms, but hopefully you get the drift of my questions/concerns and can respond accordingly. If I am completly misinterperting something please feel free to disuade me from my concerns. I am sure I am not the only one who has them based upon recent Agilebit design decisons implemented in 1Password 4.Flag 0 -
Hi Neocybersailor, those are some great questions.
[quote name='Neocybersailor' timestamp='1355758217' post='65714']
I wonder if you could explain excactly what type of data is unencrypted/exposed in the existing 1Password 3 and 1Password 4 Dropbox compatible keychain formats?[/quote]
You can read about what is and isn't encrypted in the Agile Keychain Format (the format that is currently being used for Dropbox syncing and for 1Password 3 on the Mac and 1Password for Windows) here:
[url="http://help.agilebits.com/1Password3/cloud_storage_security.html"]http://help.agilebit...e_security.html[/url]
As also noted in a blog post quite a while back, we've indicated that we have been working on updating our data format
[url="http://blog.agilebits.com/2011/04/23/looking-ahead-in-security/"]http://blog.agilebit...ad-in-security/[/url]
The release of 1Password 4 on iOS is where that phase out publicly begins. I should note that the "new" 1Password browser extensions from summer 2011 were really the first place that we used a data format that encrypts everything, including Title and Location.
[quote]
The reason I am asking this, is as you know that if you wish to synch a 1Password 3 file on a Mac with an iPad or iPhone you currently are forced to use the Dropbox synch method since iCloud keychain formats are not currently compatible with the Mac and we will have to wait until 1Password 4 for Mac is released (with an unknown schedule).[/quote]
That is correct. At the moment our new Cloud Keychain format is only handled by 1Password 4 on iOS and so is only used for synching among iOS devices (where we currently are using iCloud for that). Transitioning from Agile Keychain Format to our new Cloud Keychain Format involves getting things ready one platform at a time.
[quote]
I am asking this because Agilebits seems to be promoting synching only through Dropbox/iCloud in the future because of its decision to drop the local wifi synch feature[/quote]
Ideally, it would have been nice to have the new Cloud Keychain Format fully in place before discontinuing WiFi syncing. But as 1Password4 was a complete rewrite and eliminating WiFi sync at this point will save lots of trouble down the road, we did it this way. Building wifi sync into 1Password4 and then later removing it would be a disaster at the time of its removal, while perpetuating the problems that led us to want to remove it in the first place.
For those people who really, really don't want to use the Agile Keychain Format on the cloud, you may continue to use 1Password3 on iOS until we have the new data format available on the Mac. If you don't edit or modify your data on multiple platforms, you may (or may not) find iTunes File transfer for your 1Password data useful as a temporary workaround.
I should note that I think that the risks of capture of your data from your come computer (say, for example it is stolen or broken into) is on par the the risk of data capture from "the cloud", and so I don't really feel that there is much security gain from avoiding Dropbox for 1Password syncing. And ...
[quote]In a separate thread on this forum I understand that you are trying to explain to us that even if the Dropbox server was hacked and our keychain stolen, brute force methods would still be impractical to break the password if a strong password was used in the first place.[/quote]
That is correct.
[quote]
But I am getting the impression from this thread that some data types are unencrypted in the keychain code and can be potentially read and examined by a hacker without even breaking the password. Exactly what types of data are currently unencrypted in the current 1Password 3 keychain?[/quote]
Again see the document I linked to above that describes this in detail (or the blog post for a simpler overview). Most notably, the Location (URL) and the Title you assign to an item are not encrypted in the Agile Keychain Format. Roughly the sort of data that might also be visible in a browser bookmarks file. Please see the linked documents for an explanation of why we felt that this was necessary at the time.
[quote]I apologize in advance if this question is not properly phrased in the correct technical terms[/quote]
Your questions have been stated extremely clearly and on target. And even if they hadn't been, there would be no need to apologize. What goes on "under the hood" in any crypto system is far far more complicated than how things appear to the user.
We've worked hard to provide details and explanations of the innards of 1Password for those who wish to know while also presenting a straightforward tool that people can use well without having to know the how things work under the hood. I recommend that you follow our blog, which often goes into explanations of some of the technology involved.
Cheers,
-jFlag 0 -
Hi J (and any other AB moderator),
I am posting because I would like to ask for an update regarding when we customers can use 1P, completely and securely, as it is intended. To do that, we need to be able to use the v4 new Cloud Keychain format. Thank you J for the detailed information.
I am not trying to inflame, but when I refer to using 1P completely and security - I mean just that. A specific example is, when I learned of this design decision (imo, a flaw) in late 2010, I immediately ceased using the location field for anything other than sites I could not care less about someone knowing I visit. I also stopped using the Title as one normally would; for example instead of MyRealBankName, I might title it Bank1 and then remember which one that might be (after all I could have more than 1). I probably do not need to go into the why, but in short - if a person knows the name of all of your banks, places you shop, social sites you use and so on, they do not need to try to crack 1Passwords encrypted password. They know all of the places you use and the locations. It makes social engineering much much easier and also enables someone to see you use a known insecure site to then focus their attention on that one knowing they can compromise it, perhaps get a credit card number which can then be used to cause havoc like the whole Amazon/ Apple fiasco.
In Dec 2010, I hopped into a discussion on GetSatisfaction regarding partial encryption. At the time, there was a dismissive nature about it. But the topic picked up steam from customers and would be customers. In Jan 2011 AB (and I think it was you J) indicated the data format would change and that it was needed particularly since the Cloud aspect changed the vectors. The discussion also moved over to the AB forum of the time.
In an April 2011 blog post (but there were more forum discussions leading up to the post), it was first openly shared the format would be changing to "have even more of your data fully encrypted, with the remainder well obfuscated." as well as the increased number of iterations (which has occurred). Other "under the hat" options were referenced.
Why am I bringing this up? The main reason is - I want to fully use 1Password securely and I think customers deserve that too. Most people do not drill into encryption or even think about attack vector scenarios. They simply trust AgileBits. That trust is partially why I felt compelled to post this today. When looking to see if there were updates regarding Cloud Keychain support, I saw this reply from MikeT to a potential customer "Before purchasing I have a few questions" . There were many questions/ answers but here is one that makes my point.
Question:
- Can i make a backup of all my data on local PC in simple format, where i can read my passwords ? Is our data secure on your website ? Please let me know detailed answer before I make purchase. Are all my website passwords stored in same plain text on your servers ?
Answer:
None of your private data, especially username/password are stored in clear view anywhere. It's all encrypted with AES encryption among other security features. You can find out more by reading our keychain design document.
Your backups are also encrypted with the same encryption. You can choose to export your data via text format (CSV) or 1Password Interchange File, which is the decrypted output of your 1Password data and can be imported in other tools if they support it.
In addition, your 1Password data is always stored on your computers locally, we do not store or host your data anywhere. You may choose to sync your data with Dropbox, which then would place a copy of the encrypted data file on Dropbox's servers.
I am not trying to pick on MikeT but that is clearly not an accurate answer; there is not even a way that it could be without Cloud Keychain format (which this is not since it is referring to a local computer etc). Sure, MikeT gives him the link to read more about the Agile Keychain - but how many will just trust "None of your private data, especially username/password are stored in clear view anywhere." That is just not true. Some people use title to store things like some number like a credit card number or employee badge number, and then the username and password for pin and second question. Regardless, title, location etc is private data.
So what do I want and why am I bringing all of this up. Again, for the reasons cited above and ultimately want at least an estimate for when we customers can expect Cloud Keychain support on not just iOS, but Windows and OSX? I have seen some moderators/ admins write pretty soon and things like that - that is not what we deserve. Give us real information. If there is a beta available - let me/ us know. I would be willing to risk breakage and report any issues. I have licenses for 1P for iOS, OSX and Windows. I am happy to be a guinea pig.
I personally have been waiting for over 2 years and it has been publicly promised for nearly 2 years. Support for v3 software was stated as well, which means there should be no reason it is not already available for all existing customers. Give us the option to choose the data format or to upgrade the existing.
In the same way we customers deserve to know a timeframe, especially after being promised this in 2011, we also deserve answers that can be trusted (so do potential customers). The response by MikeT is one of many where the easy response is that everything is encrypted when that is just not accurate at this time. I wish it were.
Given the effort to link and reference, cite discussion timelines and overall the issue with Agile Keychain - I hope it is clear that I am not trolling or bashing 1Password for sport. I have much better ways to spend my time.
I love the promise of 1Password, the design and cross platform potential. Unfortunately, that promise is flawed. Two plus years ago I was excited to see that AgileBits respond to concern expressed by customers. But after two years+ we get an iOS app (that was a paid upgrade lets not forget) but no timeline or even goal about when the Cloud Keychain can be used across platforms.
If an answer about when we can expect Cloud Keychain compatible OSX and Windows releases (even in beta form for those that choose), it pains me to say that it appears the promise of the new data format, v3 support and all the coming soon (some of which was well over a year ago) was nothing more than a means of stringing us customers along, and even more disturbing, perhaps using it to milk us for the v4 iOS upgrade. A timeline or goal date, without a cutesy pretty soon, soon, coming soon, not long now - would go a long way. Right now, those responses could mean a year+ still.
Regards,
BenFlag 0 -
Hi Ben,
I remember those discussions back in the GetSatisfaction days! You've asked about a lot of things here, so forgive me if I only address a few of them.
The short answer is that I can't make any promises about when the Cloud Keychain format will be rolled out to other platforms, but it is something we are working on intensively.
At the moment, as you know, it is iOS only and so we've taken advantage of avoiding confusion by limiting that to iCloud syncing, but the Cloud Keychain format will be rolled out to other platforms.
As you note, the wait for the Cloud Keychain format has been a long wait. This is one of the reasons why we never make promises about when things will be released. It's also part of why we very rarely announce features before they are delivered. Our promise back in 2011 about a new data format was a rare exception.
At the time of the April 2011 blog post we still didn't know if we could manage to encrypt everything or whether some data would just need to be well obfuscated. Roustem had a cool idea, but we weren't sure it would work. Happily it did and we are able to actually able to fully encrypt the Location data as well. We knew what we wanted to do, but were reluctant to promise things until we were certain that we could deliver it. That's why the "or obfuscated" hedging is in that old blog post.
The trick, by the way, is the separation of an item overview from the full item details. This allows us to decrypt part of every item as soon as the Master Password is provided. This way items can be looked up quickly without us having to have massive amounts of data decrypted. We had to experiment to see whether this was computationally practical on the devices that 1Password runs on. We really don't want launching 1Password to drain your iPhone battery.
I suspect that we've already pointed you to the document that explained why we didn't encrypt Title and Location when we first designed the Agile Keychain Format.
http://help.agilebits.com/1Password3/cloud_storage_security.html
Anyway, there are other reasons why it took more than a year to go from that particular public promise to where we are now (new format only available on iOS). One was learning the importance of authenticated encryption, another is that we needed to change the ways that the browser extensions interact with the 1Password data files. So the complete rebuild of the browser extensions that was rolled out in the Summer of 2011 was part of the data format redesign.
And as I said here, we don't promise a time line. What I can tell you is that a version of 1Password for Mac which handles the Cloud Keychain format is being very actively worked on. Windows is also being worked on, but not with the intensity of focus that we see on the Mac at this point. So while no time line, it is very likely that a Mac version with Cloud Keychain Support will precede a Windows version.
It's hard to word our brief description of Agile Keychain security. A brief one-liner will often say "your secrets are well encrypted", but one has to read further to see exactly what is meant by "your secrets". I don't have the words to express how happy I will be on that day when everyone is using the Cloud Keychain format and the confusion about that will go away.
Again, no promises about timing, but we are in a nice position now.
- The format is done
- It's been getting positive comments by the cryptographic community at large (instead of just the ones we consulted privately before release)
- We see that it works, and have been tuning things about syncing operations.
- We've got code that supports it.
So yes, you still have to wait before the Cloud Keychain format will replace the agilekeychain format, but we are much further down that road. And now you see exactly what it is that you are waiting for, although I don't know if that makes the wait easier or harder.
Cheers,
-j
–-
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits
http://agilebits.comFlag 0
