jpgoldberg
- Karma
- 222
- Created
- June 10, 2012 (14y ago)
- Submissions
- 0
Jeffrey Goldberg
Plays with crypto, works for AgileBits (but don't speak for them, blah blah). Has done sysadm stuff.
keybase.io proof: [ my public key: https://keybase.io/jpgoldberg; my proof: https://keybase.io/jpgoldberg/sigs/zvE012tQcwlLb_hCw1HwgbGQyUQHlCJ6vUfkHvUUhaE ]
To elaborate on what my colleague, Ben, said, we have been in the process moving to more common cross platform code. A it more than a year ago we had - 1Password for Mac and iOS written in Objective-C and Swift -…
Another reason for the local hosting is so that we (I work for 1Password) are never in a position to acquire secrets can be used to decrypt your data.
Interestingly Microsoft presented EverParse designed to produce verified parsers for these sorts of data formats at USENIX Security 2019. https://www.usenix.org/conference/usenixsecurity19/presentat... But it's only for…
I'm hoping that parser generators get more usable. I completely concur that using parser-generators to create safe parsers that will accept all and only valid input is a way to eliminate a large class of bugs. But…
[Disclosure: I work for AgileBits, the makers of 1Password] I'd like to elaborate on the two points made by @epistasis 1. Ability to deliver of a malicious client does not depend on where your encrypted data lives. If…
[Disclosure: I work for AgileBits, the makers of 1Password] Thanks. I (as you'd expect) agree with both points. The second one is particularly challenging. Deterministic builds are possible for some categories of…
It is important to separate three security concerns: 1. Crypto delivered to the browser over HTTPS depends on the integrity of HTTPS. 2. A browser is a very hostile environment (injected JS, other browser extensions,…
And now my reply to your first point. Thank you for letting people know that this interprocess communication is readable by something running as root on the user's machine. For those interested in this, please see an…
I'm giving a separate reply to each of your questions. This is "Couldn't you just pair it once and then be done with it?" To pair it once would mean that a long term secret would need to be stored. Now we consider…
You've asked multiple questions. I'd like to give you a separate reply for each. I really really don't like talking about how our competitors might do things. (I work for AgileBits, the makers of 1Password). But I can…
Right. This would be unauthenticated with all of the problems that that entails.
And where would you store the keys for that communication in a way that an attacker with root privileges couldn't get it? "Encrypting" with keys available to the attacker is mere obfuscation. In this case, it would…
And where would the secret part of the TLS key be stored? As I've said before, encrypting with a key that is available to the attacker would merely be obfuscating. The only "value" of such obfuscation would be to…
You are correct that we are vague about the threat model in this case. But please keep in mind that encrypting local data at rest defends against a whole category of "compromise" (i.e., the data stored long term on the…
Are you suggesting simple DH without any long term secret? Hmm. I'm fairly sure we thought through that option, but at moment I can't see see/recall why we rejected it.
The browser would have to hold on to the shared key long term. Where does it put this? Encrypting with a key that is available to attackers (who have the same set a privileges needed to run localhost sniffing) is not…
[Disclosure: I work for AgileBits, the makers of 1Password] We've talked about this several times, most recently was in June. Please see https://blog.agilebits.com/2015/06/17/1password-inter-proces... This falls into…
Oh that would be nice. The difficulty is in keeping track of "supported services" and making sure that they haven't changed their password change forms yesterday. Standardized password change forms would make our lives…
For your second question boils down to "item sharing" versus "vault sharing". Item sharing is more flexible than vault sharing, but it requires more work to see who has access to what. It also involves many more public…
Well spotted about the revocation and password change issue. At the moment, the way we address this is through server policy to prevent the user with rescinded access from getting any new vault data from the server. But…
I remember doing that in the 90s. There was the "password book" locked away in a location I won't disclose in case they still do it that way. We all used SSH public keys (this was kind of new back then), so really only…
It's more of a threat to us than you describe. If a potential team of N people have k members who need a Linux client, then that might cost us N customers, not just k.
The web app runs in Chrome, Firefox, and Opera. But nothing native yet.
Oh. Never mind. I somehow had it confused with a JavaScript implementation. Not sure how I had that misconception in my head.
Notice I said "almost every other crypto library". I had NaCl specifically in mind with that qualification. It's no secret how you feel about crypto delivered over the web and run in the browser, but one of the the…