Viewing profile — jpgoldberg
jpgoldberg
HN member- Joined
- Sun, Jun 10, 2012, 12:57 AM UTC
- HN karma
- 222
- Public activity
- 57 items
- HN profile
- View on Hacker News ↗
About jpgoldberg
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 ]
Recent public activity
-
comment
Comment #26803930
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 wr…
-
comment
Comment #26798119
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.
-
comment
Comment #22051108
Interestingly Microsoft presented EverParse designed to produce verified parsers for these sorts of data formats at USENIX Security 2019. https://www.usenix.org/conference/usenixse…
-
comment
Comment #21716677
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 eli…
-
comment
Comment #15709888
[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 o…
-
comment
Comment #15709760
[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…
-
comment
Comment #13821754
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 (in…
-
comment
Comment #11213300
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 tho…
-
comment
Comment #11213277
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 n…
-
comment
Comment #11213224
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…
-
comment
Comment #11212650
Right. This would be unauthenticated with all of the problems that that entails.
-
comment
Comment #11212620
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 o…
-
comment
Comment #11212603
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"…
-
comment
Comment #11212566
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" (…
-
comment
Comment #11212507
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.
-
comment
Comment #11212481
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 need…
-
comment
Comment #11212318
[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/1pass…
-
comment
Comment #10517827
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 pass…
-
comment
Comment #10515406
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 w…
-
comment
Comment #10514934
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 …
-
comment
Comment #10504911
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 …
-
comment
Comment #10504901
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.
-
comment
Comment #10504890
The web app runs in Chrome, Firefox, and Opera. But nothing native yet.
-
comment
Comment #10504035
Oh. Never mind. I somehow had it confused with a JavaScript implementation. Not sure how I had that misconception in my head.
-
comment
Comment #10503635
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…