sweis

I think Intel backed away from the documentation that implied all signed enclaves had to go through them. I think people can attest their own SGX enclaves.

This sounds familiar.

Facebook supports PGP too, by the way: https://www.facebook.com/notes/protect-the-graph/securing-em...

And runs as a Tor hidden service at https://facebookcorewwwi.onion/: https://www.facebook.com/notes/protect-the-graph/making-conn...

And we had some smart outside people review it: https://twitter.com/matthew_d_green/status/75140316340882636...

Here's a whitepaper to start: https://fbnewsroomus.files.wordpress.com/2016/07/secret_conv...

Hi. To move all messages to be E2E encrypted, we need credible solution for web clients and every other platform, including old feature phones. This is easier said than done, but is something we are thinking about.

Secret Conversations is a step in the right direction.

I am confident Facebook will meet your high standards when it comes to E2E encryption for Messenger.

Got it. Here's the code: https://github.com/passbolt/passbolt/blob/master/app/Control...

I didn't know gpgauth existed, but this is what they appear to be using (the site has a broken cert): https://gpgauth.org/

I haven't found it in the code yet, but the landing page's protocol diagram with optional "/auth/verify" might have potential to be abused as a decryption oracle. It depends how they check the nonce.

I have seen strong interest in SGX among some large Intel customers.

The headline misses the most interesting part: This is released by the NSA.

This map has much better pew pew sounds: http://threatbutt.com/map/

Nate Lawson has a good explanation of timing attacks (against my own code): http://rdist.root.org/2009/05/28/timing-attack-in-google-key...

I briefly looked at Telegram's crypto code a couple months ago. Here's a few funny things I spotted:

Telegram's message format uses ambiguous padding, so they have to try all padding lengths when validating a message: https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/...

That loop leaks timing information, as does the "Utilities.arraysEquals" method it uses. I'm not sure if it opens up a timing attack, but it's suspect: https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/...

There is another spot where they pad with zero bytes without any authentication. This may leave room to mess with the protocol: https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/...

There are also some weird things throughout the code, like using SecureRandom.nextDouble() all over: https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/... https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/...

This Yagisawa paper is of poor quality and lacks adequate proofs. It unfortunately uses the exact title as a 2011 paper by Brakerski, Gentry, and Vaikuntanathan: https://eprint.iacr.org/2011/277.pdf

The BGV paper is the real deal.

This team is hiring, by the way: https://www.facebook.com/careers/department?req=a0I1200000G4...

Hi. Someone else commented, but you should have received an encrypted verification email with a link. We don't want to start sending you encrypted notifications until we confirm you're actually able to read them.

If you click that verification link, you'll receive a web notification that it's enabled should start receiving encrypted notifications.

Check your spam folder in case your mail provider's or client's spam filter is mislabeling it.

If you don't see it, try unchecking and rechecking the opt-in box, which should trigger a new verification email. (We've had a feature request for a "Resend" button".)

Hi Scott. We're not using PEAR.

If you are interested in looking at the implementation and other interesting security stuff, we have a lot of security openings:

Security Software Engineer - https://www.facebook.com/careers/department?req=a0IA000000G2...

Open Source Security Engineer - https://www.facebook.com/careers/department?req=a0I1200000G4...

PrivateCore Software Engineer - https://www.facebook.com/careers/department?req=a0I1200000G4...

Security Infrastructure - https://www.facebook.com/careers/department?req=a0IA000000G4...

Hi. We use a generic subject line "Encrypted Notification from Facebook" and tried to remove fields that leak metadata. The From: field should just say "Facebook".

Please contact me if you do see anything leaking metadata about the plaintext email.

Thanks, I noticed the square brackets as well. We'll look into it.

Hi Chris. I worked on this and want to diagnose your server error.

When you decrypted from the command line, did you notice the plaintext blob preceding the HTML message content? Look for "Content-Type: text/plain;" and see if there is an unmodified verification URL there.

You might have only noticed the HTML one, which will be a pain to cut & paste. If it's still broken, please contact me.

Incidentally, I've been using both GPGTools/Mail.app and Gmail/Mailvelope without trouble. The latter doesn't open clicked links in a new tab, though. I've had to "Copy as" and paste in another tab.

Looks like they have some code on Github: https://github.com/ProjectVault/orp/tree/master/software/os/...

Strange that this let me resubmit the same link. Usually HN will detect duplicates.

An LWN article about clear containers is here: http://lwn.net/SubscriberLink/644675/54520a696ff9cddc/

"When you sign up for a passcard, your registrar will give you a secret key"

How is this decentralized if the registrar issues your secret keys for you? Couldn't they hijack your identity at any time?

It sounds more like a federated system of identity providers like OpenID.

Facebook is hiring for open source security engineers, by the way: https://www.facebook.com/careers/department?req=a0I1200000G4...

Hi. You can easily find corroboration that I work at Facebook and my contact information. Please feel free to contact me with details of your issues.

If you have specific security vulnerabilities to report, here's a link to our Whitehat program: https://www.facebook.com/whitehat/report/

That was the Facebook AV Marketplace, which to my knowledge does not exist anymore. Here's the old post about it from 2012: https://www.facebook.com/notes/facebook-security/the-faceboo...

Hi everyone. I work on the security team at Facebook. While investigating the claims of this post, we've confirmed that Facebook doesn't use Recorded Future -- an open source aggregator of public data -- to scan any private content. That means we haven't partnered with or directed Recorded Future to scan anyone's message links.

It's hard to tell precisely what's going on based on the amount of information in the post. It's possible that another interaction, including one that could be occurring on the client machine, is consuming the URL and generating this behavior.

We'll update if any new information is discovered.

Yep, we ran the entire Linux stack pinned in the L3 cache, so no data or code hit main memory which was not encrypted.

Ironically, we could test this by disabling VT-d and using a DMA device to read encrypted main memory. Here's an old demo video: https://www.youtube.com/watch?v=chvJpEmXvDk