Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>,
	WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Ephemeral key lifetime & system sleep
Date: Wed, 07 Dec 2016 17:04:45 -0500	[thread overview]
Message-ID: <87d1h3jszm.fsf@alice.fifthhorseman.net> (raw)
In-Reply-To: <CAHmME9pEq1weLxpOC1c0_nFcO9pmJRtTQ3=H8Hh8AtZyhamqpw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

On Wed 2016-12-07 16:20:43 -0500, Jason A. Donenfeld wrote:
> But I was thinking that instead of this, maybe it'd be simpler and
> even more desirable to simply *always wipe all keys immediately
> /before/ system suspend*. This would have the desirable property of
> preventing ephemeral key recovery from physical access to the ram or
> CPU of a suspended system, or attacks against modified SMM handlers
> pilfering data during resume just before handing control back to the
> kernel. Is this desirable? Is it absurd?
>
> The downside is that if you put your computer to sleep for just a
> couple of seconds, when it comes back up, the [mostly invisible
> anyway] 1-RTT handshake must occur again, and you won't be able to
> decrypt any packets that were sent to you before going to sleep and
> arrived after resuming.
>
> The upside is the tinfoil hat security properties outlined above.

I think scrubbing the ephemeral keys prior to suspend is the right thing
to do.  It's simpler to reason about, sounds straightforward to
implement, the usability cost isn't that great, and it's likely to be
the right thing in almost all long-term suspend cases.

    --dkg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply	other threads:[~2016-12-07 22:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-07 21:20 Jason A. Donenfeld
2016-12-07 22:04 ` Daniel Kahn Gillmor [this message]
2016-12-08  0:54   ` Jason A. Donenfeld
2016-12-08  2:12   ` Kalin KOZHUHAROV

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d1h3jszm.fsf@alice.fifthhorseman.net \
    --to=dkg@fifthhorseman.net \
    --cc=Jason@zx2c4.com \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).