Live data from Hacker News

Viewing profile — jpgoldberg

jpgoldberg

HN member
Joined
Sun, Jun 10, 2012, 12:57 AM UTC
HN karma
222
Public activity
57 items

About jpgoldberg

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 ]

Recent public activity

  1. 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…

  2. 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.

  3. 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…

  4. 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…

  5. 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…

  6. 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…

  7. 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…

  8. 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…

  9. 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…

  10. 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…

  11. comment
    Comment #11212650

    Right. This would be unauthenticated with all of the problems that that entails.

  12. 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…

  13. 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"…

  14. 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" (…

  15. 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.

  16. 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…

  17. 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…

  18. 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…

  19. 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…

  20. 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 …

  21. 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 …

  22. 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.

  23. comment
    Comment #10504890

    The web app runs in Chrome, Firefox, and Opera. But nothing native yet.

  24. 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.

  25. 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…