IETF Logo Mail Archive

Re: [openpgp] AEAD Chunk Size

Derek Atkins <derek@ihtfp.com> Thu, 14 March 2019 12:36 UTC

Return-Path: <derek@ihtfp.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F190129515 for <openpgp@ietfa.amsl.com>; Thu, 14 Mar 2019 05:36:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.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 oofARVa4APz8 for <openpgp@ietfa.amsl.com>; Thu, 14 Mar 2019 05:36:44 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C46B12008F for <openpgp@ietf.org>; Thu, 14 Mar 2019 05:36:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id B9B84E2042; Thu, 14 Mar 2019 08:36:41 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 29776-02; Thu, 14 Mar 2019 08:36:40 -0400 (EDT)
Received: from securerf.ihtfp.org (99-46-190-172.lightspeed.tukrga.sbcglobal.net [99.46.190.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id AAEA4E2040; Thu, 14 Mar 2019 08:36:40 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1552567000; bh=+06XbEpoCEq4UAO4/9i5+eGcWJq/vMbvq8dvcB8T5Ro=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=SUr8XyqGRN2pp2QFCYIpZ7MECRxaNO6Ic9qHfrMxo5doqp2H0kd3q5FGPn9jnSeLe muvxFP7B/W7NzmVWuUf8nuX217108rt0eeLFWdRYW8qvF6rfdA54lWLvKFyf1YDAnB wjd89hhF7ZwIsBsM4WJm1/hsRDkWLKbpH8hRZbsg=
Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id x2ECaZ5d008393; Thu, 14 Mar 2019 08:36:35 -0400
From: Derek Atkins <derek@ihtfp.com>
To: "Neal H. Walfield" <neal@walfield.org>
Cc: Vincent Breitmoser <look@my.amazin.horse>, Werner Koch <wk@gnupg.org>, openpgp@ietf.org
References: <87d0n174w6.fsf@wheatstone.g10code.de> <87mumh33nc.wl-neal@walfield.org> <3GFS71V7BTJNZ.29C5TO8OY0O44@my.amazin.horse> <sjmy35isypu.fsf@securerf.ihtfp.org> <87r2bax5u2.wl-neal@walfield.org>
Date: Thu, 14 Mar 2019 08:36:33 -0400
In-Reply-To: <87r2bax5u2.wl-neal@walfield.org> (Neal H. Walfield's message of "Wed, 13 Mar 2019 14:27:17 +0100")
Message-ID: <sjmlg1hskdq.fsf@securerf.ihtfp.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/cm-7XSi-jhAHp9PQdYObEpgbbYU>
Subject: Re: [openpgp] AEAD Chunk Size
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Mar 2019 12:36:47 -0000

Neal,

"Neal H. Walfield" <neal@walfield.org> writes:

>> > ...really? All this is just to save a few cpu cycles in the rare
>> > cases of data
>> > corruption that should have been handled by other layers
>> > (filesystem / transport
>> > layer) in the first place? Why even bother?
>> 
>> No, it is more than that.  Imagine using OpenPGP to encrypt a full
>> filesystem to tape backup.  You necessarily want to be able to chunk
>> that as you are saving (and restoring).
>
> I don't think Vincent is disputing the validity of Werner's use case
> per se.  I think he is saying the marginal utility of that is tiny
> (it's "just a performance improvement") relative to ciphertext
> integrity (a security property).

IMHO it is a bit of both.  Again, looking at this historically (having
written the original streaming code back in ~1995), the idea was to
provide early-notification of cryptographic failure without having to
buffer the whole complete message.  Granted, this was written before
AEAD techniques came into the public eye, but I don't think I would have
done it much differently at the time.

There were at the time systems with limited RAM and/or temp space, but
we still wanted to be able to encrypt & sign LARGE data sets.  Again,
think of a 'tar -czf - / | pgp ... | <network or tape>' as the model we
were using at the time.

If you are on tape, you CAN get "transmission" errors.  Think: Bit Rot.
It's a real thing.  Spinning rust can also have failures, but it's a bit
less common.  Even RAM can have bit errors -- this is why ECC (error
correction, not elliptic curve) RAM is used in servers!

Protecting against transmission error, bit rot, etc is just common
sense!

But the ability to do this in a space that can't "hold" the full data
set is exactly why we have streaming capability.

-derek

-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant

v2.23.0 | Report a Bug | By Email