Please Stop Writing Secure Messaging Tools (2015) • Hacker News Board

Re: Please Stop Writing Secure Messaging Tools (2015)

#71

Post by hdhzy » Tue, Oct 24, 2017, 6:55 PM UTC

subway wrote: post #25

t0mbstone wrote: post #24

Just use Keybase!

I can't help but get an embrace, extend, extinguish vibe from keybase. It was a nifty key discovery service initially, but more and more feels like a closed platform, and gives me a sense of deja vu akin to XMPP on GTalk.

It's also worth noting that there are Keybase alternatives in the works, e.g. Linked Identities [0] for proofs about social accounts (Github, Twitter etc.) that just utilizes OpenPGP, and Key Transparency [1] for tracking changes in keys.

[0]: https://tools.ietf.org/html/draft-vb-openpgp-linked-ids-01

[1]: https://security.googleblog.com/2017/01/security-through-tra...

Re: Please Stop Writing Secure Messaging Tools (2015)

#72

Post by throwaway25869 » Tue, Oct 24, 2017, 10:09 PM UTC

ndesaulniers wrote: post #28

gumby wrote: post #10

The essay I wish she had written would have said, "we don't need more 'secure messaging systems' -- we should be making all the following tools secure by design" For example, (and whether you love them or hate them) Apple takes this seriously: your fingerprints don't leave the device and are implemented by a piece of hardware in such a way that even Apple doesn't have access to them. Compare that to the Android imple…

I maintain the Fingerprint stack on Google Nexus/Pixel devices. > your fingerprints don't leave the device and are implemented by a piece of hardware in such a way that even Apple doesn't have access to them. This is true for Google, too. > Compare that to the Android implementations which have fingerprints in the filesystem. They're not stored in plaintext. They're encrypted with keys that remain in hardware. You ca…

> They're encrypted with keys that remain in hardware. You can never read the keys, only encrypt files with them, from applications running in a separate physical address space, accessible only through the hypervisor.

By 'in hardware', I'm guessing you don't mean real silicon / flash, but rather whatever persistent storage is provided by the SoC vendor's TrustZone implementation. In my opinion calling that 'hardware' implies a level of security and verification that is not actually present, and is disingenuous.

If history has shown us anything, it's that relying on a chipmaker's security assurances for platform software features can only end in tears. You don't need to look very far to find real world examples of exploits against TZ stacks [1].

[1] https://www.blackhat.com/docs/us-15/materials/us-15-Shen-Att...

Re: Please Stop Writing Secure Messaging Tools (2015)

#73

Post by vxNsr » Thu, Nov 02, 2017, 5:47 AM UTC

kcmastrpc wrote: post #44

vxNsr wrote: post #11

Earlier quoted context omitted.

I would think that at least half of the domains mentioned are being used in some way by developers. So it's entirely possible to dogfood them. Some examples I know I've used: PMS, Wiki, Calendar, VFM. I'd love a good group password vault, so far I've come up empty for something open source...

https://bitwarden.com self-hosted / free / open-source password vault. extensions for every major browser out there (edge / ff 57)

Thanks! I'm looking into this. Never heard of these guys