From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id DF27C6DE0140 for ; Mon, 5 Feb 2018 07:15:32 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.067 X-Spam-Level: X-Spam-Status: No, score=-0.067 tagged_above=-999 required=5 tests=[AWL=-0.047, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AOU6GV6yh_K for ; Mon, 5 Feb 2018 07:15:31 -0800 (PST) Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com [209.85.215.46]) by arlo.cworth.org (Postfix) with ESMTPS id 8C1046DE00C4 for ; Mon, 5 Feb 2018 07:15:30 -0800 (PST) Received: by mail-lf0-f46.google.com with SMTP id g72so42199803lfg.5 for ; Mon, 05 Feb 2018 07:15:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gaute-vetsj-com.20150623.gappssmtp.com; s=20150623; h=date:from:subject:to:references:in-reply-to:mime-version:user-agent :message-id:content-transfer-encoding; bh=QnYbkERRSu06PKxzepJC8LysicF8z8NAx32x/KYqvzE=; b=14gbJSm5CAC8gxRxydw/ookzsRUGL2i+MOmH9W3U4onXs4IF7CvBR8dYiBmzdvnnWt PuqaaozZ7tKc6WYF0EKkRBCyTHpQ5mABoVJshlx06ElMePLzZqNbaDU6M+H5LrHp/3XG uMinXlmpqKDp0JlBmMeO59go/Go0vJgAeeLi42cDsW/cXLICdmMM06G1q5yFAU7lB8QR kNstY7/LlW/M7pyToKAlAtDOYm8e/sX3NIZQR0t3n7CRnO/5RSb/2LmdymvmNzkYq7FP LhFSvd9XZEZotyh8k7C2Q80J/UrQDssZdZCXWPeheDVJZ5F+jEdVjcQ6S0wf/g0ZUHqI Vbjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:references:in-reply-to :mime-version:user-agent:message-id:content-transfer-encoding; bh=QnYbkERRSu06PKxzepJC8LysicF8z8NAx32x/KYqvzE=; b=kPF4+BazKQHkHrHJjXNpjQmoeMpTLJJiU3n59REkhWc51jms1EXUoM3U6wgHD3raaE pwVu6VNJGnrMToUnBx10dOZru2r1iqDgCxAOq17LDeymfuUPwpei3I8tsnwnu1h1WYQ/ R5+Ap/u8ACTrKK0B37NvcQlY7vC8AxaltCGE/9zvagz10piDMxPUIes3Qs8xI1eZ/V+d SQR4loxS81UGlqJqkNsaCh98iWL/7CBYyKvW6pfbZocdj3RSIt9vu2Xugg/geBTmDBgO 0lE3z1yjdwIda5L6xO1+maHD91CbQKktAloNij+9YIyW89MOr1tVibSBlIueaW0GXyMS 1BJw== X-Gm-Message-State: AKwxytchXkVDusyYE2eDXA+r1JQOl3aMIuztwF48k57DKt/YLhlOk/w6 7fD5FcUvFLBScKO8VRZ6qE2m4w== X-Google-Smtp-Source: AH8x227VMSHlrD0vZrudvZd/p/HtzkxQj27cd3T27Zhvc5DCVilrk939joQvdQt3oJB0ZKifZC4q/A== X-Received: by 10.25.93.83 with SMTP id p19mr24760796lfj.113.1517843728440; Mon, 05 Feb 2018 07:15:28 -0800 (PST) Received: from localhost ([128.39.46.106]) by smtp.gmail.com with ESMTPSA id w23sm1891355lfd.97.2018.02.05.07.15.27 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 05 Feb 2018 07:15:27 -0800 (PST) Date: Mon, 05 Feb 2018 16:15:24 +0100 From: Gaute Hope Subject: Re: Bcc, throw-keyids, and metadata hiding [was: Re: Announcing Astroid v0.11] To: astroidmail@googlegroups.com, Daniel Kahn Gillmor , notmuch@notmuchmail.org References: <1517741078.emojmmucvz.astroid@strange.none> <87y3k822b5.fsf@fifthhorseman.net> <1517765623.i18bm10e0r.astroid@strange.none> <87mv0o1u7k.fsf@fifthhorseman.net> <1517771221.hi89l1togg.astroid@strange.none> <87bmh41mk5.fsf@fifthhorseman.net> <87372g1b9n.fsf@fifthhorseman.net> <1517815399.2w186vjjm2.astroid@strange.none> <87h8qvzvhp.fsf@fifthhorseman.net> In-Reply-To: <87h8qvzvhp.fsf@fifthhorseman.net> MIME-Version: 1.0 User-Agent: astroid/v0.10.2-26-g61e8fdce (https://github.com/astroidmail/astroid) Message-Id: <1517843248.cvlu0mp4mk.astroid@strange.none> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 15:15:33 -0000 Daniel Kahn Gillmor writes on februar 5, 2018 9:33: > On Mon 2018-02-05 08:33:36 +0100, Gaute Hope wrote: >> Yes; this seems like the ultimate approach to this problem, unless=20 >> it will be possible for GPG to completely hide receivers - I am guessing= =20 >> this is inherently impossible?=20 >=20 > I'm not sure how gpg could do that -- the metadata leak of most > recipients (To:, Cc:) is *outside* of the material that GnuPG handles, > since GnuPG doesn't see the mesage headers when it's encrypting the > body. Maybe i'm misunderstanding you though? >=20 I mean the recipient key list in the header of the encrypted=20 packet [0][1]. I assume there must be a key list entry for each receiving k= ey=20 (even though it does not need to be accurate). It would be better to=20 just remove the whole table of receiving keys, than setting each of them to= 0. Regards, Gaute [0] https://www.ietf.org/rfc/rfc4880.txt [1] https://crypto.stackexchange.com/questions/10253/why-are-the-first-few-= bytes-of-a-gpg-encryption-always-the-same =