The DMZ

Mark Buffalo

16:00

@ArtOfCode This is because of turnover

Iszi

@Quill Dunno what you're talking about. Aside from the recent @TildalWave/@Shog9 debacle, I can't remember the last time I've seen SEI actually step in and kick someone off.

Mark Buffalo

It's a classic symptom of turnover. Inability to add new features because nobody knows what does what

Terry Chia

Anyway, my opinions probably don't matter to SEI but hey, they have lost me as an active contributor.

Rоry McCune

whispersystems.org/blog/whatsapp-complete <-- end-2-end encryption on whatsapp....

Quill

@Iszi exactly. If the CMs jumped in at every instance of a chat argument to "support existing communities", it'd be overbearing

Rоry McCune

16:01

that'll annoy some people

Terry Chia

@RоryMcCune Nice to see them actually get that done.

Iszi

@Quill Now mods do jump in when needed, which still isn't very often. My point was that seeing SEI themselves get involved is extremely rare.

As for Meta burnout, anyone else remember when this was a thing?

Sep 12 '12 at 13:49, by Scott Pack

status-bydesign-because-fuck-you

Rоry McCune

@TerryChia signal protocol and all

Simon

@Iszi Oh Packy, we need you here.

Terry Chia

@RоryMcCune Axolotl was a much cooler name. :P

Rоry McCune

16:03

@TerryChia true true

Mark Buffalo

@RоryMcCune Argh! ENCRYPTION!

Foiled again

Terry Chia

@Iszi Heh.

M'vy

Mobile chat, where mods aren't blue and room owners not in italic

Simon

#mobileproblems

Coding in languages that don't require a semicolon has broken me for life.

Mark Buffalo

@ThomasPornin Stupid question time. Is revokable encryption possible? Let's say a key was compromised. You revoke that key, and it can not be decrypted again. Even retroactively. ..?

Simon

16:18

Markus pls, that implies that there's a server somewhere controlling the decryption.

ArtOfCode

@MarkBuffalo that does't sound possible

Mark Buffalo

Would probably need a third party?

Yup

@Simon or there's a server with a third key

Verify if key is allowed to be used... if so, send a randomized key that matches something

Terry Chia

@MarkBuffalo en.wikipedia.org/wiki/Forward_secrecy is a similar concept.

M'vy

You would have to control the key and only deliver it in the right condition. Once the data and the key are out somewhere, you have no mean of avoiding decryption.

Mark Buffalo

@TerryChia Interesting, thank you.

@M'vy And I'd ike to find a solution to this

Iszi

16:23

No, more like: Data is stored encrypted with DK (data key) on server. User requests data from server, authenticating with UK (user key). Server verifies privileges, decrypts data, then re-encrypts with UK before sending to the user.

Problem remains after this point though: User has (and may have copied) the data in a form that can be decrypted with UK perpetually. Revocation of UK would only restrict the user from accessing additional data sets that they formerly had permissions to.

Simon

We have enough Brits in here already oszi.

diagprov

@Simon hello Simon

Simon

@diagprov !!!!!!!!

M'vy

Simon simoning

Simon

Oh you sneaky bastard.

Rоry McCune

16:25

@Simon did you know.. that during WWII there was a plan to relocate the monarchy to Canada, in the event of a possible German invasion of the UK

Simon

@RоryMcCune !!!!!!!!!!!!!!!!!!!!!

I ALMOST WAS BORN BRIT

Iszi

@MarkBuffalo The key (no pun intended) to keeping the user from exercising broad access rights beyond the lifetime of their permissions is to never give them decryption keys for more data than they actually need and request at any given time.

Rоry McCune

@Simon yep but for some tactical changes, I could've been speaking german and you'd be the one with the tea and the stiff upper lip!

diagprov

@Simon I feel you are really an honorary Brit.

Simon

I'm already a fan of tea.

diagprov

16:27

Exactly.

Simon

Maybe I have Brit ancestors, I should check it out.

Iszi

@Simon Earl Grey, hot.

Jeff Ferland

I just want a Shengen zone passport...

Simon

wot

Jeff Ferland

"Almost a brit"

Iszi

16:28

A wild @JeffFerland appears!

M'vy

Well he got pinged iirc

diagprov

@JeffFerland depending on June, a British one may or may not be any good for that purpose. You'll need to become French or something :)

Although, confusingly, the UK is not actually in the Shengen Zone right now, although we do have free movement.

David Freitag

@JeffFerland o/

Simon

Could you imagine a French Canadian with a British accent?

M'vy

Maybe you should join us. You're on the wrong side of the fun line

David Freitag

16:30

@Simon I can't even imagine a french canadian

Simon

:DDDD

David Freitag

@M'vy The fun line? Is that a euphemism?

Iszi

@TerryChia @MarkBuffalo Also, regarding comparisons to PFS: The problem with implementing the same logic that provides PFS is that you are handing the user the encrypted data *and* the decryption key (session key) every time. If the user retains the session key, they will be able to decrypt the data sent within that session regardless of what happens to the long-term key.

Again, this does still prevent the user from getting *additional* data in the future so long as the additional data uses a key that the user has not been given. It just doesn't keep the user from accessing the same data (…

M'vy

@DavidFreitag no further comment

David Freitag

@M'vy ( ͡◉ ͜ ʖ ͡◉)

Huge sale on Spartan 6 FPGA boards

xilinx.com/products/boards-and-kits/dk-s6-embd-g.html

Has 1 10Gbps Ethernet and a x1 PCIe lane

$400

Mark Buffalo

16:33

@Iszi Even if 3+ keys are used

?

Iszi

Okay, Chat.SE: What's the point of hiding one line behind "(see full text)"?

Mark Buffalo

@Iszi My idea is for a chat protocol

Iszi

@MarkBuffalo I'm not sure what your suggested implementation would look like. Walk me through a scenario?

M'vy

Rule #1 of Internet, once the data is out, it's not yours anymore.

Mark Buffalo

Yup

David Freitag

16:35

Rule #34 of the internet...

Iszi

@M'vy That's Rule #1 of computing in general.

M'vy

W/e

Iszi

Not Internet-dependent. Hell, really not computer-dependent for that matter. They just make it a hell of a lot easier.

David Freitag

@Iszi Not for an offline machine with full-system encryption

Iszi

@DavidFreitag Maybe if the key's been destroyed.

David Freitag

16:36

@Iszi With a remotely destroyable key

Iszi

@DavidFreitag No, it must already be destroyed. Else one with the key may exfiltrate the data.

David Freitag

@Iszi If they have data but no key exfiltrated data is useless

Iszi

@DavidFreitag In the context of my statement "exfiltrated" implies "decrypted and copied".

Mark Buffalo

User A sends encrypted messages to User B. User B requests information from the server to decrypt, checks if User B is allowed to do so. If so, send third key so user B can decrypt contents. Don't worry if user b shares decrypted information... just prevent him from requesting information with that key if revoked

And discard the server key after use

Each time a communication occurs, generate new server key information

This is very rough example

I feel I'm not explaining it right

David Freitag

I can't believe you guys are talking about theoretical crypto systems and nobody has pinged @ThomasPornin

diagprov

16:40

@MarkBuffalo What's the threat of being able to decrypt the message, though? Isn't the main threat the risk to the decrypted data being shared in the first place - that is, if all parties retain a decrypted message, any one of them will do as a target to leak that message.

Mark Buffalo

@DavidFreitag I pinged him earlier

Arperum

@DavidFreitag The first message did.

Iszi

Why bother sending the third key? Sure, there should be at least three keys involved:

1. Server key used for secure communications.
2. User key used for secure communications and authentication.
3. Data key used to protect data in storage.

But the server never needs to send the user any additional keys. Just use key 3 to decrypt the data, then re-encrypt with key 2 before sending. (Note: User never has key 3.)

David Freitag

o

Mark Buffalo

Nearly all encryption is a moot point if you can compromise either end point

David Freitag

16:41

Sorry for the extraneous ping, @ThomasPornin, please don't maul me!

Mark Buffalo

I get that

The idea is to discard the third key, the man in the middle key, after use. So each individual message will be encrypted with new information. This way, if either User A or B is comprised, there's at least an additional layer of protection there

Now, if User B receives the server key, they can save that, yes

Iszi

@MarkBuffalo User should never have Server Key.

Mark Buffalo

No, no. I mean their public key

I already see issues with this design

Iszi

@MarkBuffalo Public keys are meant to be public.

The problem you posed was how to use encryption to revoke a user's access to data. If you assume the user retained a copy during a time that they were allowed access, the answer is you can't.

Mark Buffalo

Yes, I'm aware

@Iszi This is true, but the user would have to store evwry single key

Each new message would have a new key

Iszi

16:46

@MarkBuffalo Not at all impossible, and really not even necessary. Once they have the key and the data, they can simply decrypt the data and store it in the clear.

diagprov

@Iszi Yep or re-encrypt.

Mark Buffalo

Key set*

David Freitag

@Iszi Or store the id for that message and request the message and key again from the server

Mark Buffalo

@Iszi Right. Now imagine for millions of users. You'll be storing a ridiculous amount of key information

So you might get some details eventually, but all of them? Currently feels impractical.

diagprov

@MarkBuffalo I can't see what the additional key protects that is not already protected in the end-to-end scenario - actually, with a third party able to read the clear you have the server in the middle as a target.

Mark Buffalo

16:49

You are correct, but what if the server doesn't know what's being sent?

Either to or fro

Iszi

@MarkBuffalo Now I think you're threat modeling wrong. Are we talking a rogue user wanting to use privileges that have been revoked? Or are we talking an attacker trying to compromise accounts that have already been - or are becoming, during the attack - disabled?

David Freitag

@Iszi Both, presumably

Mark Buffalo

@Iszi I'm bored at lunch and just thinking.

diagprov

@MarkBuffalo how would it not know?

Mark Buffalo

Let's say a rogue attacker is collecting communications

@diagprov Hence why I'm trying to brainstorm and find out if there is a way

Iszi

16:50

@diagprov Ogres & Onions.

David Freitag

@Iszi Layers.

Iszi

@MarkBuffalo Okay, that's what TLS is for. What are you trying to fix?

Mark Buffalo

The attacker stores the encrypted communications for later date, such as a time when they find a weakness in the protocol or something

Or maybe they're on the hunt for private keys from User A, or User B

But they need a third key, which is no longer stored anywhere.

Unless User A or B stores it

Or maybe there is a way around this. .

Iszi

@MarkBuffalo I'm still not clear on what you're looking to do that isn't either covered in TLS with PFS, or just impossible.

Mark Buffalo

Yeah, assume TLS is broken

Iszi

16:54

@MarkBuffalo Take the specific protocol out of the equation. Apply same concepts.

Mark Buffalo

@Iszi To be frank, I am not sure what I'm trying to do lol

Iszi

Okay, then I VtC as unclear what you are asking.

Mark Buffalo

Other than this: discard third key after encryption

Yeah, no worries... I'm just rambling

Iszi

Like @TerryChia said, check this out.

Forward secrecy

In cryptography, forward secrecy (FS; also known as perfect forward secrecy) is a property of secure communication protocols in which compromise of long-term keys does not compromise past session keys. Forward secrecy protects past sessions against future compromises of secret keys or passwords. If forward secrecy is utilized, encrypted communications and sessions recorded in the past cannot be retrieved and decrypted should long-term secret keys or passwords be compromised in the future, even if the adversary actively interfered. == History == The term "perfect forward secrecy" was coined by C...

Mark Buffalo

I will. Gotta get back to work

diagprov

16:56

@Iszi That's possible but assuming a scenario decrypt with data key, re-encrypt with user key, delete data key, the plaintext still exists on the server, following what is described. Layering encryption won't bring in an ability to revoke keys, which was what as asked for.

Iszi

I think it covers what you're after, otherwise what you're after is probably impossible, impractical, or not worth the expense.

diagprov

Well, actually, you could refuse to decrypt something encrypted twice, I guess.

Iszi

@diagprov You'd need multiple servers handling the request and sending data/keys to the user either separately or under separate keys not held by the central server.

And now I have a meeting. Back later.

diagprov

@Iszi Actually, I think you can do it with just one server. User A encrypts with the pubkey of B, then encrypts again with the ephemeral key for server S. Server S stores the message+ephermeral key. It then either decides to deliver (decrypt with eph key) or just delete the ephemeral key, rendering the data it has undecryptable.

An attack on the server will reveal the ephemeral key used to encrypt the data encrypted with the PK of B already.

Mark Buffalo

@diagprov This

diagprov

17:01

So, basically, it peels a layer.

Mark Buffalo

Server wont even have the key required to decrypt the message after the first time

diagprov

@MarkBuffalo Yeah my mistake was thinking you were proposing to decrypt on the server, sorry.

Mark Buffalo

@diagprov no worries

The idea is to somehow make it more annoying and difficult for attackers

Ohnana

oh look i missed another drama bomb

Mark Buffalo

:x

diagprov

17:04

You should also look at the "future secrecy" in the axolotl ratchet. Essentially even a compromise of an ephemeral key at any given point in time is not supposed to affect the security of any later key - whispersystems.org/blog/advanced-ratcheting

Mark Buffalo

Will read later, thanks. Meeting time.

diagprov

@MarkBuffalo I guess your original question was more along the lines of "can this be enforced in the actual properties of the system" rather than having the server arbitrarily decide, though, right?

David Freitag

17:28

@Ohnana yarp

Simon

I've been so good at not starting the drama lately, I might have to request to be awarded a medal.

Matthew

@Simon hands over a chocolate medal reading "Not a Drama Llama"

Simon

@Matthew Aw, that's lovely, thanks.

@LucasKauffman is gonna be really jealous.

Matthew

hands @LucasKauffman a chocolate medal reading "Llama, not Drama"

Simon

Lucky Lucas.

He didn't even have to work for it.

JukEboX

17:45

Basic HTML code

^_^

Matthew

@Simon Well, he has been being a llama for years with minimal drama

Simon

He is rewarded for his non-action?

Blasphemy!

Matthew

@Simon He is rewarded for not fitting the stereotype of his kind!

Simon

Oh look, over there! Is that a Phemy? Oh noooo, it's the Blas kind of phemy!

Matthew

Do you want me to take your medal away?

Simon

17:53

I already ate it.

Matthew

OK, I'm not touching it...

Simon

I can let you know when you can get it back though.

diagprov

@Simon technically though your medal was also awarded for not causing drama.

I.e., not doing something.

Simon

No, mine was for good behavior and acting nice surely is an action!

SEJPM

18:29

did anybody already bring up the topic of WhatsApps Signal Protocol incorporation yet?

Rоry McCune

@SEJPM I mentioned it, but there wasn't much chat :)

SEJPM

@RоryMcCune :/

Matthew

@RоryMcCune We don't talk infosec anymore

SEJPM

what a bunch of security professionals, do not even care about 1 billion new end-to-end encryption users :/

Rоry McCune

@SEJPM it'll likely need to wait till @CodesInChaos and/or @ThomasPornin are about :)

Simon

18:31

@Matthew YOU ALWAYS FORGET

YOU DONUT

Rоry McCune

@Matthew but we still talk Security :)

Matthew

I know...

@SEJPM Is it actually end-to-end? Or does Facebook still have access?

SEJPM

@Matthew it now deploys the Signal Protocol (formerly known as Axolotl, an improved version of OTR)

I'm reading the whitepaper right now

Matthew

@SEJPM But does it apply that between userA and userB or between userA-Facebook, and Facebook-userB? I've not investigated in detail, I will admit

Rоry McCune

@Matthew it's end-2-end using the signal protocol

so there should be no facebook opportunity to decrypt

SEJPM

18:35

@Matthew it says it's end-to-end and you can actually verify the other party

Matthew

@RоryMcCune That's good then. I like this. I might actually use it...

Rоry McCune

and unless they've left a dynamic code push backdoor in their mobile app, apart from upgrades it wouldn't be easily removable

@Matthew yeah I wish there was a desktop client too, then it would be even better

but they don't seem too interested in that.

Matthew

Would clash with Facebook messenger too much?

SEJPM

@RоryMcCune there is...

Rоry McCune

@SEJPM ooh wherebouts, I was looking but couldn't easily find it.

I found some unofficial clients and a web client

SEJPM

18:37

web.whatsapp.com

Simon

@SEJPM You edited that to add ellipsis?

diagprov

@RоryMcCune it was pointed out on HN that actually while it might be e2e, we have no idea how many keys the messages are encrypted for. It's conceivable (although hopefully RE will prove it wrong) that the client could encrypt for a WhatsApp key and share all your messages with them.

Simon

You might just be the worst human being on earth.

SEJPM

@Simon YES

Rоry McCune

@SEJPM but I'd guess the web client can't do end-2-end

Simon

18:37

YOU'RE A BAD PERSON

COME HERE YOU GOTTA GET WHIPPED 1500 TIMES

Rоry McCune

@diagprov yeah backdoors are still possible, but I'd guess harder to pull off

SEJPM

@diagprov there are ways to confirm the use of the protocol

diagprov

@RоryMcCune indeed.

SEJPM

somebody will do this soon(tm), I'm sure

Matthew

I'd be even happier with an open implementation, so could choose my app and infrastructure - XMMP with full end to end, for example

SEJPM

18:41

one difference between WhatsApp and Signal: WhatsApp uses Server-side fanout for group chats and Signal uses Client-side fanout, thus Whatsapp can still build group chats social graphs as opposed to OpenWhisperSystems

diagprov

@SEJPM yeah that's why I said RE might confirm it. If every message happens to use SenderKeys with multiple keys even with one contact, you know they're up to no good.

SEJPM

other interesting fact: IIRC Signal uses ZRTP for voice encryption, WhatsApp uses SRTP

Simon

I'd like to use a such encryption with my donut to make sure that no one intercepts our xox's.

SEJPM

Noise pipes (AES/GCM/Curve25519/SHA256) is used for Client-Server encryption

diagprov

@SEJPM that's a shame, but then, almost nobody uses ZRTP.

Simon

18:45

@SEJPM What's the purpose of this?

What happens once you scan the code?

SEJPM

github.com/whispersystems/libsignal-protocol-java

@Simon idk

@Simon I guess it syncs your phone with your browser and authorizes your browser

^^^ the library used by WhatsApp (as per their Whitepaper)

Simon

That'd be cool.

Rоry McCune

hey @Simon found a pic of you on the Internet!

Simon

om

I might just go get a dozen donuts and eat that for dinner.

SEJPM

eprint.iacr.org/2006/424.pdf

Simon

18:50

I wasn't even born in 2006.

SEJPM

^^ ZRTP, SRTP, ... VoIP protocol comparison

TL;DR: ZRTP is a key negotiation protocol apparently and SRTP is a data transfer protocol

and if you have a means for a secure key exchange (e.g. Signal Protocol / Axolotl) you can skip ZRTP and start outright with SRTP

"Signal voice calls are encrypted with the RedPhone encryption protocol, which is based on the ZRTP key-agreement protocol (developed by Phil Zimmermann) and SRTP."

Rоry McCune

@FiloSottile The desktop client is a view onto your phone, and the connection between desktop and phone is e2e.

Tweeted by moxie on April 5, 2016 at 6:18 PM in reply to FiloSottile

^answer to the web client E-2-E thing

that's an interesting approach for sure

so the website essentially mirrors what's on the phone

unusual

SEJPM

@RоryMcCune how else would you implement multi target e2e?

Simon

wat

CodesInChaos

Offline messaging to multiple devices doesn't play nicely with forward secrecy.

Simon

18:54

o

SEJPM

@CodesInChaos each message has it's own key

a bunch of one-time (public) keys are buffered on the server

Rоry McCune

@SEJPM well I'd have thought they'd have a full desktop client (windows/osx/linux) and it would be a first class citizen with the mobile clients

CodesInChaos

@SEJPM But if one device doesn't read the messages, its keys will be around forever.

Rоry McCune

rather than have the web be this kind of proxy for the mobile client

CodesInChaos

so bad for forward secrecy.

Rоry McCune

18:55

@SEJPM one user can (I presume) already have multiple mobile devices, so they must handle multi device stuff

SEJPM

@CodesInChaos the keys get removed after they were used and the server apparently opts for "error on the sender" rather than "loose FS"

@CodesInChaos whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf

CodesInChaos

@SEJPM But if one device doesn't read messages for a week, it can't delete its keys for a week. And all messages in the mean time will be vulnerable.

SEJPM

@RоryMcCune phone was there first and as soon as you switch your primary client, your long term keys change and the other end gets a security warning

Rоry McCune

@SEJPM sure you should get told when the keys change, that doesn't preclude multiple clients per user

SEJPM

@CodesInChaos I'm not sure if you're still talking about FS as I know it (each message has it's own unique, strong key), because buffering public keys doesn't count as "breaking FS" AFAIK

Henry White Hat Hacker

18:59

Hello Everyone.

SEJPM

@RоryMcCune a) the protocol was designed to be 1-1 b) if there were multiple clients, this would actually be kinda bad (?) because Facebook may add itself as standard recipient silently if the protocol allows such things, right now the recipient would just drop a malformed message (i.e. multiple recipients)

Also, the WhatsApp security guide is no fun to read. I only enjoy reading crypto specifications when they're broken.

Tweeted by matthew_d_green on April 5, 2016 at 3:51 PM

The beautiful thing is: once you have a secure messaging channel, the security for phone calls is simple. https://t.co/2TmYnkDEtI

Tweeted by matthew_d_green on April 5, 2016 at 3:48 PM

Rоry McCune

@SEJPM huh seems a bit of a limitation, you would've thought it would be possible to have a master key for the user and explicitly authorize sub-keys to enable individual devices, but then I'm no cryptographer, so i am likely wrong

SEJPM

@RоryMcCune I'd say the reason here is: "Hey, this is an awesome protocol, please don't mess with it", using a e2e proxy is the easiest (modular) solution which can be independently (of the main IM protocol) verified secure (even by non-cryptographers)

@MarkBuffalo Heil NSA. Your hobby of spying and data-mining WhatsApp messages is gone

CodesInChaos

@SEJPM I view FS as "how much of my old messages can be decrypted if an endpoint gets compromised"

Mark Buffalo

@SEJPM lulz

I'm not NSA

Gilles

19:05

@SEJPM Is that meant ironically? Because voice is actually not that easy to encrypt: it has very leaky timing side channels

SEJPM

@Gilles this is serious

Gilles

voice messages are easy, but phone calls aren't

Mark Buffalo

@SEJPM and no its not ;)

The selectors still exist

They'll wait for it to be broken and decrypt

SEJPM

@Gilles the message is written by a cryptographer, codec related stuff wasn't taken into account there, but only raw data security

@CodesInChaos every old message is vulnerable, because you stored them!

I think FS is more about, "my endpoint got compromised today, will an attacker be able to read tomorrow's messages (passively)"?

@MarkBuffalo they're using Signal Protocol (aka Axolotl) which has already withstood cryptanalysis for years

Mark Buffalo

Also, compromising either end point = your unencrypted data. If I were NSA, I wouldn't care

Iszi

19:12

@SEJPM Actually, quite the opposite. Say you interface with a system on 300 consecutive days. Days 1-100 are all fine, everything's hunky-dory. On day 101 an attacker starts sniffing your network and somehow simultaneously compromises your main encryption key. You move along blissfully unaware until day 201. Once you discover the compromise, you nuke from orbit, kick the attacker out of his MitM spot, change keys, and resume business until the end of the story at day 300.

SEJPM

@Iszi nice explanation, thank you!

Iszi

@SEJPM Without PFS, all transmissions from day 1-200 would be vulnerable if the attacker somehow was able to get the chunk of time he was missing. With PFS, only days 101-200 are vulnerable even if the attacker somehow finds the traffic from 1-100.

diagprov

@SEJPM that'd be "future secrecy", which is part of the self-healing ratchet in axolotl.

SEJPM

@CodesInChaos, I'm sorry about being wrong :(

CodesInChaos

I don't there is one "correct" definition

SEJPM

19:16

> In cryptography, forward secrecy (FS; also known as perfect forward secrecy[1]) is a property of secure communication protocols in which compromise of long-term keys does not compromise past session keys.

Forward secrecy

In cryptography, forward secrecy (FS; also known as perfect forward secrecy) is a property of secure communication protocols in which compromise of long-term keys does not compromise past session keys. Forward secrecy protects past sessions against future compromises of secret keys or passwords. If forward secrecy is utilized, encrypted communications and sessions recorded in the past cannot be retrieved and decrypted should long-term secret keys or passwords be compromised in the future, even if the adversary actively interfered. == History == The term "perfect forward secrecy" was coined by C...

even was in the HAC apparently :(

Iszi

In fact, even if the attacker has your keys, good PFS should ensure the protection of days 101-200 unless the attacker is actually resident on one of the endpoints instead of just MitM.

CodesInChaos

For offline messages it gets trickier, because there is no clear distinction between long and short term keys.

Iszi

@MarkBuffalo I thought you were NSA.

Mark Buffalo

@Iszi the only government I've ever worked for was a tribal government

Iszi

Also, to all: Forgive me if I'm jumping in and covering territory you've already been through. Was AFK for a bit, and didn't trawl log.

@MarkBuffalo Right, the Navajo-Seminole Alliance. NSA. ;-) #TotallyNotRacist

Mark Buffalo

19:19

Baha

SEJPM

> buffalos are the NSA

Mark Buffalo

:|

I'm not saying anything.

SEJPM

@MarkBuffalo #NSAconfirmed

CodesInChaos

DJB suggested renaming FS to "key erasure".

diagprov

@CodesInChaos I guess the closest you'd get is that a compromise of the key that identifies you doesn't compromise the keys you have created on a per-message basis that you intend to throw away once the message is delivered.

CodesInChaos

19:31

@diagprov I don't think that's a good definition, since it doesn't preclude long term encryption keys.

I don't like viewing FS as something you have or don't have. It's more about windows of vulnerability.

diagprov

@CodesInChaos better?

@CodesInChaos well you do have it, assuming you haven't done something silly, but only from the moment you dispose of the ephemeral keys.

So long as those keys are required to exist, they can be stolen.

CodesInChaos

For example even a ephemeral DH TLS connection remains vulnerable until it gets closed.

Compare that with Noise, where you rotate keys after each message.

diagprov

@CodesInChaos isn't it per record?

CodesInChaos

@diagprov I doubt it. Pretty sure it's only per-connection.

SmokeDispenser

'evening

CodesInChaos

19:35

And if you have multiple devices and don't use one of them for a long time, it'll keep its keys around for a long time, you're vulnerable for a long time.

Which is why I said that multiple devices doesn't play well with FS.

diagprov

@CodesInChaos huh some how I have it in my head it was per record. Maybe I am being too optimistic :) I will find out though.

@CodesInChaos yeah you're right, I was being way too optimistic.

Transcript for