[Privacy-pass] Where we are with BBS and a true rate limiting alternative
Watson Ladd <watsonbladd@gmail.com> Tue, 25 June 2024 22:48 UTC
Return-Path: <watsonbladd@gmail.com>
X-Original-To: privacy-pass@ietfa.amsl.com
Delivered-To: privacy-pass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA80C1840F6 for <privacy-pass@ietfa.amsl.com>; Tue, 25 Jun 2024 15:48:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQDtSqAa-x2Q for <privacy-pass@ietfa.amsl.com>; Tue, 25 Jun 2024 15:48:39 -0700 (PDT)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C662BC1840F4 for <privacy-pass@ietf.org>; Tue, 25 Jun 2024 15:48:39 -0700 (PDT)
Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-42108856c33so42067225e9.1 for <privacy-pass@ietf.org>; Tue, 25 Jun 2024 15:48:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719355718; x=1719960518; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=CppECTRu/EaavI4AV2TVPVZe7LjCvG2esv3tAUzGBK4=; b=JVe/ULBJeaykkI8AXM6XzZb8WaOc5bpEGJBQcAPcnXZ09v5gyK2FXw0x+/Lo7INEgl gtD+hVv+R4qdu28FG4l7uhmepP6lEIHKEfqIz7BoRtl9Q2tAvee6DTEM1oQm0GFWSGbY 5a8GrVm8KtoLVxB6XBtBkbi/22godFULNAyxbd+Y7ZUSlOLPFIJ1qBcBUtKtQnxn3dG6 eDbxpyfl+N+r85aEO+RO2eSC4IO+cxekzEuQZTDqBl1J/BEA4u1JEOTrW/4ujXluT7iK 2zIE0Hi25l+vYuR9zPGVMIECkocYojbr6fm7DPbJS84FLBiIPAYeXwrOnBAC6ZiuaMQQ eeCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719355718; x=1719960518; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=CppECTRu/EaavI4AV2TVPVZe7LjCvG2esv3tAUzGBK4=; b=budaOwa9yhiH0Bv/0exc2N0ly5ZYAKSTwQhp2iNCN4HeNsZANsQjRoxf3dVkIsFdTp w2FBi0Wfm2/iI0fpvGgKdcx8/bPPFxkwEwIE76IaSKkfopv8GLPf4mSaeZH9GZGpx2Mi mWBfbLXhi3TpqQXd8T71hlMBn7bpGRLNHAtFSbwOIhwcHjalYCMuWo6US6fXfM+WWIwz T3miAWvx/URtdrnmX9dAgxoFYtV2Tuaix8NRanjk5b21np09w1R+UV+xQcmPmiIdZ00/ 4cKtc+COj263cjc1PFWBSLDnali+5zaBaHSC98pOakiq3HWVxWY7npFIpwT8Dw7t09QF pWyg==
X-Gm-Message-State: AOJu0Yzk/xTTOeRCb3gx7bGCOe2dUUpX38ph3FtIwHug4SQnPmhLAk5Z YEqfITEBoFJEgit1pXzip6aSBRAOgk7ZxX76YtyCawDmafH/pQghjKti8nVwTdGuehYGzy0swKB 51orKondn5xr/YFzgYZzlWFj/WuJ9dQ==
X-Google-Smtp-Source: AGHT+IE3fXTMQXod+faRmJE1kQSGjKaT+2GlDxIeqtEt7N+8n24ioliCBLNXTvyuflo4kNxlNWljq5coS9nIPdRJ8aU=
X-Received: by 2002:a05:600c:4353:b0:424:a664:485a with SMTP id 5b1f17b1804b1-424a6644998mr17964045e9.8.1719355717881; Tue, 25 Jun 2024 15:48:37 -0700 (PDT)
MIME-Version: 1.0
From: Watson Ladd <watsonbladd@gmail.com>
Date: Tue, 25 Jun 2024 15:48:26 -0700
Message-ID: <CACsn0c=odKu40eoZ8rjTOZVP4kveMKYDm1Qgs5OiccFNbm1DxA@mail.gmail.com>
To: privacy-pass@ietf.org
Content-Type: text/plain; charset="UTF-8"
Message-ID-Hash: SENEX3VAP73ZKFQVKZFFZ2IR6PLGMGKK
X-Message-ID-Hash: SENEX3VAP73ZKFQVKZFFZ2IR6PLGMGKK
X-MailFrom: watsonbladd@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Privacy-pass] Where we are with BBS and a true rate limiting alternative
List-Id: Privacy Pass Protocol <privacy-pass.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/privacy-pass/aA28iCjDF-W1VnSf1c6biwI5clQ>
List-Archive: <https://mailarchive.ietf.org/arch/browse/privacy-pass>
List-Help: <mailto:privacy-pass-request@ietf.org?subject=help>
List-Owner: <mailto:privacy-pass-owner@ietf.org>
List-Post: <mailto:privacy-pass@ietf.org>
List-Subscribe: <mailto:privacy-pass-join@ietf.org>
List-Unsubscribe: <mailto:privacy-pass-leave@ietf.org>
Dear privacy pass, Over the past few months a group of us have been discussing some of the desiderata for privacy pass, and trying to ensure we have a flexible, well-considered cryptographic foundation for deployments. Currently what we have is a number of extensions, but each extension has to be examined anew and they don't compose: if you want both public metadata and rate limiting, it takes a new document to make them work. Instead we can make sure that the single token format supports a bunch of features. Foundationally we use a blind issuing variant of BBS, where the user proves that they have asked for the right fields. Some can be hidden, and others revealed to the issuer, and then a different set shown to origins. In addition it's possible to do zero-knowledge proofs efficiently over equations for the secret values. For rate limiting one of the fields is a secret key x. On showing the user computes Y=(x+k)^{-1}H(origin), and proves with a range proof that k is small and transmits Y to the origin. There are some very short range proofs available. The origin blocks repeated use of Y. This has some big benefits: origins can set the rate limit without cooperation from the issuer. The issuer no longer needs to be split. The origin could also use a nym by having k=0 and using Y as a user identifier. We also have a way to do issuer blindness where the origin learns only that an issuer they trust issued the credential. This resolves a number of the challenges for the web environment of existing solutions. We do need to write this all up, and there's significant modifications to CFRG drafts (or new ones) needed to make it all work, and there are some subtleties that lead to needing particular kinds of ZKP that complicate the efficency story somewhat. However, we're extremely optimistic that these are not showstopers and the time and space consumption is moderate enough to make it practical. Sincerely, Watson -- Astra mortemque praestare gradatim
- [Privacy-pass] Where we are with BBS and a true r… Watson Ladd
- [Privacy-pass] Re: Where we are with BBS and a tr… Christopher Patton
- [Privacy-pass] Re: Where we are with BBS and a tr… Christopher Wood
- [Privacy-pass] Re: Where we are with BBS and a tr… Watson Ladd
- [Privacy-pass] Re: Where we are with BBS and a tr… Christopher Wood
- [Privacy-pass] Re: Where we are with BBS and a tr… Kosei Akama
- [Privacy-pass] Re: Where we are with BBS and a tr… Watson Ladd
- [Privacy-pass] Re: Where we are with BBS and a tr… Christopher Wood
- [Privacy-pass] Re: Where we are with BBS and a tr… Kosei Akama