Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E707127978; Wed, 23 May 2018 13:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5xAefl_sdb9; Wed, 23 May 2018 13:16:38 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A829127010; Wed, 23 May 2018 13:16:38 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id v2-v6so20691728oif.3; Wed, 23 May 2018 13:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=v80QUkHTnAQOazlx+jcoQGpsG5QvgWyzBdB1L0txUFo=; b=agUX37yWnvB4RhFGYx3SSI4O+MgfKVpVUI9mc1a2XifEQqTTrGGgbbTfkni8q0HANy 001Ehtc/viY5yQWOjRI9rq3Nzo5cyF4ncsb95powqOiDh43BNzPgKZ/9HXq6jhExf8sE kDYBg3wFCJQ6VK8Jx+xh6YBESij72U2Mi1GbpnOAhWQVCjQg9BUESzwJ/rajj4sm74St l9f37eK8bub+mopEK46Yqpx2L/X7B4j9CDMPtBAhUEp0Xaq98+P0tcLzbwAPA1h+E0uC k/3b25RgZEggh9b6vmmDOiuWoFxAx4uw9NMNgMZSmwr+YuQ4Y2+cJ1/1Ips/CE4g5NyW ePmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=v80QUkHTnAQOazlx+jcoQGpsG5QvgWyzBdB1L0txUFo=; b=jQZSXvJDucXCfXwdT2kzZscwG0oK3iJAXsnPG8ll/wgbYwEF/cFrD/qUj37nC5YwPH W8A9sJf52mfAi9ZUoVy+mpvmfm9lp1ebvNlmO9ytGC0H7ecjUKNXIZKGgu9BsKr23ZfB TayEy+BKb5UdROinPYgJyMANGeAwakHDgBYbmGGm/3IDRNivLQoI1sWgT+7y96V17Z3u 1Op09kR6aP7pCmvsRIYkCvcYLDDAH86Up/vNx+cbKLfFhPjfLgqHOSFQwZ7wV5uBiEeF oomuWMKLDeGlIu/+wCddIXqMA+H/2544lCzi/6Lxtkqt5bSy+xPqSNOyxgjkJJG5sCgj BsfA== X-Gm-Message-State: ALKqPwfNd0SHIylHm3AfTiZaXB20ieq311DCjyroyJQzIHXuVhl4RkNY bmmW+81sXpQGli20SmPe7/4YCUwZpNORYeAimiE= X-Google-Smtp-Source: AB8JxZreQ6TiOkSLO/oK/cPhxz3DYuMUpls8wi645zCFhva9RNregAl5zrfYHWXt/GIARUzbYZNV7Z40TsAWHUvBex0= X-Received: by 2002:aca:3b0b:: with SMTP id i11-v6mr2277645oia.271.1527106597667; Wed, 23 May 2018 13:16:37 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 2002:a9d:23:0:0:0:0:0 with HTTP; Wed, 23 May 2018 13:16:37 -0700 (PDT) In-Reply-To: <41e7a726-0175-7e3d-d35c-d413bf01ea12@nostrum.com> References: <152709922899.26838.11074435093932176947.idtracker@ietfa.amsl.com> <41e7a726-0175-7e3d-d35c-d413bf01ea12@nostrum.com> From: Phillip Hallam-Baker Date: Wed, 23 May 2018 16:16:37 -0400 X-Google-Sender-Auth: Hh3wKfuvN31XqoPfmKE-0tuIrDs Message-ID: To: Adam Roach Cc: Spencer Dawkins , The IESG , SPASM , lamps-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000049c91f056ce5360e" Archived-At: Subject: Re: [lamps] Spencer Dawkins' No Objection on charter-ietf-lamps-02-00: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 20:16:40 -0000 --00000000000049c91f056ce5360e Content-Type: text/plain; charset="UTF-8" I am not sure that that is possible. Signature is easy, just pickle the data and signature in a hash-chain and you are done. Problem with confidentiality is it is break once and it fails. All that you can do by adding technology to a public key encryption system is to provide additional ways to decrypt. The only way to protect against quantum cryptanalysis is to only use quantum resistant crypto. We can do that (e.g. Kerberos) but it ain't easy. Forward secrecy doesn't provide quantum resistance and it only works at the message layer, I don't know how to apply forward secrecy to data at rest (would love to hear suggestions), What I do to provide protection is a multi-layer encryption stack with crypto going on at the Transport, Transaction and Data layers. I can't use forward secrecy above the transaction layer. On Wed, May 23, 2018 at 3:35 PM, Adam Roach wrote: > On 5/23/18 1:13 PM, Spencer Dawkins wrote: > >> 4. Specify the use of a pre-shared key (PSK) along with other key >> management techniques with supported by the Cryptographic Message >> Syntax (CMS) as a near-term mechanism to protect present day >> communication from the future invention of a large-scale quantum >> computer. >> >> I found it confusing because "near-term" isn't "near-term from now", it's >> "near-term after the invention of quantum computing destroys civilization. >> > > My understanding is that the intention is "near-term from now." The idea > is that LAMPS should develop something that you could use, say, next year > to encrypt email you send so that, 15 years from now when someone finally > builds a 4,000 qubit machine, they can't dig out your (then) 14-year-old > email and decrypt it. > > /a > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --00000000000049c91f056ce5360e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I a= m not sure that that is possible.

Signature is easy, just pickle the data and signature in a hash-= chain and you are done.

P= roblem with confidentiality is it is break once and it fails. All that you = can do by adding technology to a public key encryption system is to provide= additional ways to decrypt. The only way to protect against quantum crypta= nalysis is to only use quantum resistant crypto. We can do that (e.g. Kerbe= ros) but it ain't easy.


Forward= secrecy doesn't provide quantum resistance and it only works at the me= ssage layer, I don't know how to apply forward secrecy to data at rest = (would love to hear suggestions),

What I do to provide protection is a multi-layer encryption stac= k with crypto going on at the Transport, Transaction and Data layers. I can= 't use forward secrecy above the transaction layer.



On Wed, May 23, 2018 at 3:35 PM, Adam Roach <adam@n= ostrum.com> wrote:
On 5/23/18 1:13 PM, Spencer Dawkins wrote:
4. Specify the use of a pre-shared key (PSK) along with other key
management techniques with supported by the Cryptographic Message
Syntax (CMS) as a near-term mechanism to protect present day
communication from the future invention of a large-scale quantum
computer.

I found it confusing because "near-term" isn't "near-ter= m from now", it's
"near-term after the invention of quantum computing destroys civilizat= ion.

 My understanding is that the intention is "near-term from now." T= he idea is that LAMPS should develop something that you could use, say, nex= t year to encrypt email you send so that, 15 years from now when someone fi= nally builds a 4,000 qubit machine, they can't dig out your (then) 14-y= ear-old email and decrypt it.

/a


_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

--00000000000049c91f056ce5360e--