Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACEDC14F61C for ; Wed, 28 Aug 2024 09:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.104 X-Spam-Level: X-Spam-Status: No, score=-6.104 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyF4p864V061 for ; Wed, 28 Aug 2024 09:21:28 -0700 (PDT) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99445C14F61E for ; Wed, 28 Aug 2024 09:21:28 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id 98e67ed59e1d1-2d3d7a1e45fso4944921a91.3 for ; Wed, 28 Aug 2024 09:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724862088; x=1725466888; darn=irtf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=A7tJzneg5LzPyQiHEqtJxl+hmppJW1/u7Ap2cfXsprk=; b=noH4Wrqmg3xLYt1oBLQ8yfNsqXElwImzvm7IsnHaH97x4MQHLleJGUe+WBYLod/ve3 7Gtpor1b20JwpB1mfu+WOkMREQKrn6XfHXqV9hjSqi7J2lrhG3Zyy74xCWDK3VQkJyZL WH14/ibXxy7BGlzXB/zE6nQW2+8SrD8gTMQJU0bvpRwf9Zcili2yHB9+ML+ul7dtB5bA UK9UQFbP24YTnEIw7ChQ+EWF0V2MnaojlUCHvS5zyJhVXfQTgDSevIcS3kvEEDGBEJYa hA2R0BIHseDo1pqiJUWxqlKusbQ9C1EXAmQYCSH4xov/0nZUlnOvrgbQf9Qz3BK0exe8 TTzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724862088; x=1725466888; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=A7tJzneg5LzPyQiHEqtJxl+hmppJW1/u7Ap2cfXsprk=; b=GcYSfwkNYHrm8yo6xS4+T6GNHPzMB2srxFow+Oy2J7IK6H4rP6GHDruNukWMvoWPcT gA0zHMDpS2DQJ70+Up1HQ936vjJ1UsJ2XPwN84b+Xqa6etCh59ruoOfrsxsK0ONGmcM0 CDvFSqnYONC50oFV8mx21Zp8efhZ8vt9MIBn7J9ZX4C9Q0MmK43IHh2ji/GrmN3JF3GO 5PjhborDqkKT6TGeC8w6INo2YVpUU0HBzJ/MUZCMKrhVGDA6MyAYOAjBTWDaI57Lw2uu fbqf0PiQX/KKhAowCUTEEgKxLL2vTUMcpKDJuS2Jy7kSb7vTZZSkLZ7NV+LsIBV9tYvC MBfQ== X-Forwarded-Encrypted: i=1; AJvYcCVjrFAQC6kM8aytWY+Ku6Ity1GtZYMPrOMPSqnZcSM87lojCGpHDRzgAVgjgrk1lQdkFl1f@irtf.org X-Gm-Message-State: AOJu0Yz5LlINrQ4wrRBEVbaSFiaj+vsxhfic3Ji2Xs1E3tP7FaG39Aq9 RkMNAk+2gxCTcyLbn/sio5fNSMFfU385VqwLlDIH20ohpMiiMiDtjgSb95rCLFPhPlkrQavXeF7 he0tvyptVgicnZW3MoZXaFjQeJKhNKhnTTt0= X-Google-Smtp-Source: AGHT+IE7689gHZtbPfdm9cYmpl0HkXcXt+f3kqTvliEKAx0u7/gbDhJP6gng4Gk1DY2oWgBZMWkdXsyLGCYy0YIjOg8= X-Received: by 2002:a17:90a:f48a:b0:2c9:67f5:3fae with SMTP id 98e67ed59e1d1-2d646cebc9fmr15427873a91.28.1724862087612; Wed, 28 Aug 2024 09:21:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jean-Philippe Aumasson Date: Wed, 28 Aug 2024 18:21:10 +0200 Message-ID: To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary="00000000000004d4510620c0c066" Message-ID-Hash: T5DZAP4G4YGSDP4DDDMNPSIDBTPKKPJY X-Message-ID-Hash: T5DZAP4G4YGSDP4DDDMNPSIDBTPKKPJY X-MailFrom: jeanphilippe.aumasson@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-cfrg.irtf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: cfrg@irtf.org X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5BCFRG=5D_Re=3A_BLAKE3_I-D?= List-Id: Crypto Forum Research Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000004d4510620c0c066 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you guys for your input, we appreciate your taking the time to clarify IETF/CFRG's mission and how B3 would fit (or not). We'll think about it and further evaluate the relevance of B3 to IETF. I would just like to respond to 2 statements: Benson wrote "Nevertheless, neither BLAKE2 nor BLAKE3 are designed as cryptographically secure hash functions, so it might not be a good fit for CFRG." and Phillip wrote "I don't see a need for a Blake 3. Applications using Blake 2 can simply transition to SHA-2 + SHA-3." I don't know if Benson's statement is exactly what they intended to convey, but it's obviously not correct: both B2 and B3 are, obviously, designed to be cryptographically secure hash functions. B3 is also a PRF, MAC, KDF, and XOF. Regarding the need for B3: the SHA-2 family does not offer those extra functionalities. The SHA-3 family does but at much slower speed. K12/TurboSHAKE are faster than 24-round SHA-3s but are significantly less used than B3, be it in open-source and proprietary projects. On Mon, Aug 26, 2024 at 6:19=E2=80=AFPM Phillip Hallam-Baker wrote: > +1 EKR > > Sort of. I think he understates the case. > > IETF doesn't select algorithms on its own, it is a part of the wider > industry and the primary means by which IETF chooses algorithms is by > public competition sponsored by a major stakeholder. To date, that > stakeholder has been NIST for historical reasons, UK doesn't put its > country on its stamps because Rowland Hill and NIST holds cryptographic > algorithm competitions. But if NIST stopped doing that, we would find or > build an alternative. > > We had a public competition for digest algorithms not so long ago. The > Blake proposals were not selected. The outcome of the competition was tha= t > we came to the conclusion SHA-2 is actually fit for purpose but came up > with SHA-3 as an alternative. We thus have two digest algorithms that we > have a high degree of confidence in. I don't see a need for a Blake 3. > Applications using Blake 2 can simply transition to SHA-2 + SHA-3. > > CFRG is chartered for "discussing and reviewing uses of cryptographic > mechanisms, both for network security in general and for the IETF in > particular." I don't see adding a third digest as helping either cause. > > The security of any application is determined by the weakest algorithm it > accepts. There is a good argument for having a backup algorithm but havin= g > more than one backup seems more likely to hurt than help. At the very lea= st > it means having to spend time and effort tracking an additional random > variable. > > Even if people are nervous about SHA-2, we can always use SHA-2-512. In a > world where we are having to implement PQC algorithms, I can't really see > an argument for using SHA-2-256 any more. Just use 512 bits and be done, > the chance of 512 bits being broken at the same time as 256 is not zero b= ut > it means all bets are off. That is not an eventuality it makes sense to > plan for because if that falls, nothing we know today can be relied on. > > CFRG is chartered for "discussing and reviewing uses of cryptographic > mechanisms, both for network security in general and for the IETF in > particular." > > > > > > On Sat, Aug 24, 2024 at 1:30=E2=80=AFPM Eric Rescorla wrot= e: > >> >> >> On Fri, Aug 23, 2024 at 11:56=E2=80=AFPM Benson Muite >> wrote: >> >>> On 22/08/2024 05.20, Eric Rescorla wrote: >>> > I don't actually think the question of how much an algorithm is used = in >>> > the wild is that relevant to the question of adoption. The more >>> relevant >>> > question is whether there are IETF groups who want to use a given >>> > algorithm, because that is where CFRG should focus its limited >>> resources. >>> > >>> >>> RFC 7693 [1] documents Blake 2. Blake 3 is an improved version of this= , >>> so is worth reviewing. Blake 2 was done through the independent >>> submission stream [2], rather than through a research or working group. >>> >>> 1) https://datatracker.ietf.org/doc/html/rfc7693 >>> 2) https://www.rfc-editor.org/about/independent/ >> >> >> I don't think this follows at all. There are lots of things in the >> Independent Stream >> I wouldn't want to see CFRG spend effort on, for instance the GOST >> algorithms. >> >> -Ekr >> >> >>> >>> > -Ekr >>> > >>> > >>> > On Wed, Aug 21, 2024 at 9:51=E2=80=AFAM Chris Barber >> > > wrote: >>> > >>> > Dear Chris, >>> > >>> > You are comparing specific implementations on a particular CPU, n= ot >>> > the algorithms themselves. The "sha3" library you are using is no= t >>> > optimized and may not accurately reflect the performance of >>> > TurboSHAKE compared to, for example, XKCP. In software, the >>> > performance of BLAKE3 and TurboSHAKE/KT12 is theoretically very >>> > close but highly dependent on the implementation in practice. >>> > >>> > Since this discussion is about adoption, I believe it would be mo= re >>> > relevant to compare the algorithms themselves. What properties do= es >>> > BLAKE3 have that TurboSHAKE doesn't? "it's already used a lot in >>> the >>> > wild" can be sufficient to justify a specification. >>> > >>> > >>> > On Thu, Aug 15, 2024 at 11:07=E2=80=AFPM Christopher Patton >>> > >> > > wrote: >>> > >>> > Hi all, >>> > >>> > Before adopting BLAKE3, I think it would be useful to see how >>> > much of a difference it would make in our applications. I wou= ld >>> > suggest looking through RFCs published by CFRG and assess how >>> > performance would change if they could have used BLAKE3. Off >>> the >>> > top of my head: >>> > - RFC 9180 - HPKE (replace HKDF?) >>> > - draft-irtf-cfrg-opaque - OPAQUE >>> > - RFC 9380 - hashing to elliptic curves >>> > >>> > I'll add my own data point: draft-irtf-cfrg-vdaf. This draft >>> > specifies an incremental distributed point function (IDPF), a >>> > type of function secret sharing used in some MPC protocols. >>> Most >>> > of the computation is spent on XOF evaluation. For performanc= e >>> > reasons, we try to use AES wherever we can in order to get >>> > hardware support. We end up with a mix of TurboSHAKE128 and >>> AES, >>> > which is not ideal. It would be much nicer if we could afford >>> to >>> > use a dedicated XOF, but TurboSHAKE128 is not fast enough in >>> > software. I threw together some benchmarks for B3: >>> > >>> https://github.com/cjpatton/libprio-rs/compare/main...cjpatton:libprio-= rs:exp/blake3-for-idpf?expand=3D1 >>> < >>> https://github.com/cjpatton/libprio-rs/compare/main...cjpatton:libprio-= rs:exp/blake3-for-idpf?expand=3D1 >>> > >>> > >>> > The results were interesting. Compared to Turbo, B3 is 30% >>> > faster, as expected. Compared to the baseline (mix of Turbo a= nd >>> > AES), B3 is 2-3x slower for the client operation, as expected= ; >>> > but the server was slightly faster, which frankly is a bit of= a >>> > mystery. We'll need to dig into the code more to be certain, = as >>> > there may be some obvious inefficiencies on the client side. >>> But >>> > preliminarily, I would say B3 is probably too slow in softwar= e >>> > for this application. >>> > >>> > Chris P. >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > CFRG mailing list -- cfrg@irtf.org >>> > To unsubscribe send an email to cfrg-leave@irtf.org >>> > >>> > >>> > _______________________________________________ >>> > CFRG mailing list -- cfrg@irtf.org >>> > To unsubscribe send an email to cfrg-leave@irtf.org >>> > >>> > >>> > >>> > _______________________________________________ >>> > CFRG mailing list -- cfrg@irtf.org >>> > To unsubscribe send an email to cfrg-leave@irtf.org >>> >>> _______________________________________________ >>> CFRG mailing list -- cfrg@irtf.org >>> To unsubscribe send an email to cfrg-leave@irtf.org >>> >> _______________________________________________ >> CFRG mailing list -- cfrg@irtf.org >> To unsubscribe send an email to cfrg-leave@irtf.org >> > _______________________________________________ > CFRG mailing list -- cfrg@irtf.org > To unsubscribe send an email to cfrg-leave@irtf.org > --00000000000004d4510620c0c066 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank y= ou guys for your input,=C2=A0we appreciate=C2=A0your taking the time to cla= rify IETF/CFRG's mission and how B3 would fit (or not). We'll think= about it and further evaluate the relevance of B3 to IETF.
=C2=A0
I would just like to respond to 2 statements:=C2=A0

Benson wrote=C2=A0 "Nevertheless, neither BLAKE2 nor BLAKE3 ar= e designed as cryptographically secure hash functions, so it might not be a= good fit for CFRG."

and Phillip wrote "= I don't see a need for a Blake 3. Applications using Blake 2 can simply= transition to SHA-2=C2=A0+ SHA-3."

I don'= ;t know if Benson's statement is exactly what they intended to convey, = but it's obviously not correct: both B2 and B3 are, obviously, designed= to be cryptographically secure hash functions. B3 is also a PRF, MAC, KDF,= and XOF. Regarding the need for B3: the SHA-2 family does not offer those = extra functionalities. The SHA-3 family does but at much slower speed. K12/= TurboSHAKE are faster than 24-round SHA-3s but are significantly less used = than B3, be it in open-source and proprietary projects.



On Mon, Aug 26, 2024 at 6:19=E2=80=AFPM P= hillip Hallam-Baker <phill@hall= ambaker.com> wrote:
+1 EKR

Sort o= f. I think he understates the case.

IETF doesn't select algorithms on its own, it is a part of t= he wider industry and the primary means by which IETF chooses algorithms is= by public competition sponsored by a major=C2=A0stakeholder. To date, that= stakeholder has been NIST for historical reasons, UK doesn't put its c= ountry on its stamps because Rowland Hill and NIST holds cryptographic algo= rithm competitions. But if NIST stopped doing that, we would find or build = an alternative.

We had a = public competition for digest algorithms not so long ago. The Blake proposa= ls were not selected. The outcome of the competition was that we came to th= e conclusion SHA-2 is actually fit for purpose but came up with SHA-3 as an= alternative. We thus have two digest algorithms that we have a high degree= of confidence in. I don't see a need for a Blake 3. Applications using= Blake 2 can simply transition to SHA-2=C2=A0+ SHA-3.

CFRG is chartered for "discussing and rev= iewing uses of cryptographic mechanisms, both for network security in gener= al and for the IETF in particular." I don't see adding a third dig= est as helping either cause.

The security of any application is determined by the weakest algori= thm it accepts. There is a good argument for having a backup algorithm but = having more than one backup seems more likely to hurt than help. At the ver= y least it means having to spend time and effort tracking an additional ran= dom variable.
<= br>
Even if peo= ple are nervous about SHA-2, we can always use SHA-2-512. In a world where = we are having to implement PQC algorithms, I can't really see an argume= nt for using SHA-2-256 any more. Just use 512 bits and be done, the chance = of 512 bits being broken at the same time as 256 is not zero but it means a= ll bets are off. That is not an eventuality it makes sense to plan for beca= use if that falls, nothing we know today can be relied on.

CFRG is chartered for "discussing a= nd reviewing uses of cryptographic mechanisms, both for network security in= general and for the IETF in particular."=C2=A0





On Sat, Aug 24, 2024 at 1:30=E2=80=AFPM Eric Rescorla= <ekr@rtfm.com>= wrote:


On Fri, Aug 23, 2024 at 11:56=E2=80=AFPM Bens= on Muite <benson_muite@emailplus.org> wrote:
On 22/08/2024 05.20, Eric Rescorla wrote:
> I don't actually think the question of how much an algorithm is us= ed in
> the wild is that relevant to the question of adoption. The more releva= nt
> question is whether there are IETF groups who want to use a given
> algorithm, because that is where CFRG should focus its limited resourc= es.
>

RFC 7693 [1] documents Blake 2.=C2=A0 Blake 3 is an improved version of thi= s,
so is worth reviewing. Blake 2 was done through the independent
submission stream [2], rather than through a research or working group.

1) https://datatracker.ietf.org/doc/html/rfc7693 2) https://www.rfc-editor.org/about/independent/

I don't think this follows at all. There = are lots of things in the Independent Stream
I wouldn't want = to see CFRG spend effort on, for instance the GOST algorithms.

-Ekr



> -Ekr
>
>
> On Wed, Aug 21, 2024 at 9:51=E2=80=AFAM Chris Barber <cbarbernash@gmail.com
> <mailto:= cbarbernash@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Dear Chris,
>
>=C2=A0 =C2=A0 =C2=A0You are comparing specific implementations on a par= ticular CPU, not
>=C2=A0 =C2=A0 =C2=A0the algorithms themselves. The "sha3" lib= rary you are using is not
>=C2=A0 =C2=A0 =C2=A0optimized and may not accurately reflect the perfor= mance of
>=C2=A0 =C2=A0 =C2=A0TurboSHAKE compared to, for example, XKCP. In softw= are, the
>=C2=A0 =C2=A0 =C2=A0performance of BLAKE3 and TurboSHAKE/KT12 is theore= tically very
>=C2=A0 =C2=A0 =C2=A0close but highly dependent on the implementation in= practice.
>
>=C2=A0 =C2=A0 =C2=A0Since this discussion is about adoption, I believe = it would be more
>=C2=A0 =C2=A0 =C2=A0relevant to compare the algorithms themselves. What= properties does
>=C2=A0 =C2=A0 =C2=A0BLAKE3 have that TurboSHAKE doesn't? "it&#= 39;s already used a lot in the
>=C2=A0 =C2=A0 =C2=A0wild" can be sufficient to justify a specifica= tion.
>
>
>=C2=A0 =C2=A0 =C2=A0On Thu, Aug 15, 2024 at 11:07=E2=80=AFPM Christophe= r Patton
>=C2=A0 =C2=A0 =C2=A0<cpatton=3D40cloudflare.com@dmarc.ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:40cloudflare.com@dmarc.ietf.org>> wr= ote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi all,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Before adopting BLAKE3, I think it wo= uld be useful to see how
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0much of a difference it would make in= our applications. I would
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0suggest looking through RFCs publishe= d by CFRG and assess how
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0performance would change if they coul= d have used BLAKE3. Off the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0top of my head:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- RFC 9180 - HPKE (replace HKDF?)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- draft-irtf-cfrg-opaque - OPAQUE
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- RFC 9380 - hashing to elliptic curv= es
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I'll add my own data point: draft= -irtf-cfrg-vdaf. This draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0specifies an incremental distributed = point function (IDPF), a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type of function secret sharing used = in some MPC protocols. Most
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of the computation is spent on XOF ev= aluation. For performance
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0reasons, we try to use AES wherever w= e can in order to get
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0hardware support. We end up with a mi= x of TurboSHAKE128 and AES,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0which is not ideal. It would be much = nicer if we could afford to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0use a dedicated XOF, but TurboSHAKE12= 8 is not fast enough in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0software. I threw together some bench= marks for B3:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://github.com/cjpatton/libp= rio-rs/compare/main...cjpatton:libprio-rs:exp/blake3-for-idpf?expand=3D1 <https://github.com/cjpatton/libprio-rs/compare/main...cjpatton:= libprio-rs:exp/blake3-for-idpf?expand=3D1>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The results were interesting. Compare= d to Turbo, B3 is 30%
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0faster, as expected. Compared to the = baseline (mix of Turbo and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0AES), B3 is 2-3x slower for the clien= t operation, as expected;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0but the server was slightly faster, w= hich frankly is a bit of a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mystery. We'll need to dig into t= he code more to be certain, as
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0there may be some obvious inefficienc= ies on the client side. But
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0preliminarily, I would say B3 is prob= ably too slow in software
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for this application.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Chris P.
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_____________________________________= __________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CFRG mailing list -- cfrg@irtf.org <mailto:cfrg@irtf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0To unsubscribe send an email to cfrg-leave@irtf.org=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:cfrg-leave@irtf.org>
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0CFRG mailing list -- cfrg@irtf.org <mailto:cfrg@irtf.org>
>=C2=A0 =C2=A0 =C2=A0To unsubscribe send an email to cfrg-leave@irtf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:cfrg-leave@irtf.org>
>
>
> _______________________________________________
> CFRG mailing list -- cfrg@irtf.org
> To unsubscribe send an email to cfrg-leave@irtf.org

_______________________________________________
CFRG mailing list -- cfr= g@irtf.org
To unsubscribe send an email to cfrg-leave@irtf.org
_______________________________________________
CFRG mailing list -- cfr= g@irtf.org
To unsubscribe send an email to cfrg-leave@irtf.org
_______________________________________________
CFRG mailing list -- cfr= g@irtf.org
To unsubscribe send an email to cfrg-leave@irtf.org
--00000000000004d4510620c0c066--