Return-Path: X-Original-To: tls@mail2.ietf.org Delivered-To: tls@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 4A31E112E38E1 for ; Wed, 8 Jul 2026 03:57:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1783508239; bh=WcTr9BGMPsHGWnyH6NhojI+L3PCVG7Lugo4EUpPltz8=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=ZsD6tc9ZIDbiXGVq+FB0pDFN6a3kCjTI74X4TLLcgYizQTaucrQwebCPn05QQTrN9 7MzS21dwDr/CVRgEHhWk0M111M1hxk1lK8O7x4NI2DaFyhHpGbIynYa7XKvo+dRimM tWm7waYTskzhv+XKs/Vn/GjB/0zLWXsJWakOHUfM= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=nist.gov Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o77ctLYX01QY for ; Wed, 8 Jul 2026 03:57:18 -0700 (PDT) Received: from SA9PR09CU002.outbound.protection.outlook.com (mail-southcentralusazon11010008.outbound.protection.outlook.com [40.93.193.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id A3B4C112E38CC for ; Wed, 8 Jul 2026 03:57:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=k1DDYRmkYZBmLlb3W08SVddV2EyH1baNruOzUaw6IAYmCBxifLHEGACoWssp+j9psJRTs9ewax+3MQnlbOrFAbIJd1Ovdxk0sKp5gISonlbaGHVeEtSRr9pBPrOaIa9keKvJExyObVXLH4eArDwFokSJh02pjwwLtrFtQCCmNGpkygIJJNbQzOFHx04pSi/JtVe8AcNU0YLEv1qVww1da0fzRv4k19UE0TP65slCWGco6uwtPT9GLI26BdNWT3EptdSo1XUuHmvadKzQG/ZtgZIJtN1MRNNIz9wWGRJnEVTE55ighzBefZQE3LkHntVw+iqZNq138sg4QjXQ/mGYtg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lis85Arr5uBHwfV3iOVpKjsqRYElk8bwByAXoUZP1JY=; b=lFSmJN6ckuR7vfYy1GrY+ePHGfNg+kt1TJ5hHxO+J2mxdi092+JnrKC3n2Tb4lBGhavhQ+wZ2kbOHGcLB1qkNWOV1Z8QN62WjX+tuJHyufbNDqtXMpm/XoOW0BcGbQ79X3Y1LY65gZ0xSCqsvYFK2OTKy8VoQJwXC/5JKVjjficIj0/CaR7KBGgU5KE9tbCPw7K+8Kh95dw/TpmAdQfR9zlobJMSbW4rkdYS5gaI3jBYa8G1JKzDc2CS/cQlhrgZep2PhDtCyfgcAxu/5TFLUcBGNwqlOUYteKgkAz5cCIbPhFKtnrMweBbHESSQQuzBP7xV2ovp4l0cd61dxJqLig== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lis85Arr5uBHwfV3iOVpKjsqRYElk8bwByAXoUZP1JY=; b=xvwb2GEaQO71lUu1GleUQ+e05W1CDTjeDc6ezEKsrrm9kdfdZ0OiEH617jhYqwXltIoBt4n134xU8YYKagNmS3kLJuKYOHcIG010jBfBMyMTOjOhY2ohKKG15SPoSFmnSWtf8dUj8PAzu1/0+greelEwah3PtGcg3yBrKb92bSlWiInqX6dXlb2ceqh3/JK8oGFK/VC+9jhmc1sahvLERSjbOn+wQAsBssquPIwbjBGPkp6QYCxnxaq1K+lTCKqRKy1vI4u90LFtzlBeZUYmwctwrpy7X0c9mLE1xfZMGq9J9Zv4b0MzNZgT+jIs8aioi+t5pLBW8dLseAgFJDEVgA== Received: from MW4PR09MB10059.namprd09.prod.outlook.com (2603:10b6:303:1fc::22) by MN2PR09MB5370.namprd09.prod.outlook.com (2603:10b6:208:210::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.181.15; Wed, 8 Jul 2026 10:57:09 +0000 Received: from MW4PR09MB10059.namprd09.prod.outlook.com ([fe80::def7:ba99:ec18:2ef6]) by MW4PR09MB10059.namprd09.prod.outlook.com ([fe80::def7:ba99:ec18:2ef6%7]) with mapi id 15.21.0181.010; Wed, 8 Jul 2026 10:57:09 +0000 From: "Dang, Quynh H. (Fed)" To: TLS List Thread-Topic: [EXTERNAL] [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08) Thread-Index: AQHdDmPpS4A4f7+4gUCR7GGTM2oYyLZjGEgAgAAKPACAADrugIAABLGAgAAJmMCAAAe5AA== Date: Wed, 8 Jul 2026 10:57:08 +0000 Message-ID: References: <178231320760.1520243.5914961961176039994@dt-datatracker-f9b87776f-8pmmg> <76f613e9-e952-40fb-a6e0-745392575b91@appelbaum.net> <9445dee2-e5e0-4770-ac51-efc901f2489f@huitema.net> <423F84EA-7426-45BE-8153-C2228C611D72@thomwiggers.nl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nist.gov; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: MW4PR09MB10059:EE_|MN2PR09MB5370:EE_ x-ms-office365-filtering-correlation-id: e80809cc-056d-4341-0072-08dedcdfa7dd x-ms-exchange-atpmessageproperties: SA x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|23010399003|1800799024|366016|4022899009|56012099006|4143699003|5023799004|6133799003|22082099003|18002099003|55112099003|3023799007|8096899003|13003099007|38070700021; x-microsoft-antispam-message-info: lUL45nE7xs6EpLokoq97IZEuGSA6Xf1fYIr7QgTLovKX7XucJwKFzKiBE45hT8Qp7RcNxAQosnxQqbDAAWjTmWXAls/AFIDECIiYpwM0syDMEt4kEH7G00rzptnPb2HlsFzOZy1Mwa4ojwoiobWn/sFfbro4JbAvVQBSh2rq427x777SPV3QWHdxf1+vwpVwhF4vp6mKrbDnoAylGn72zlISEQdkMpmA54GxzdV3IIVOoEaX70Pot0ie9LLYeUGvQcpkfyhMr5QGdpXnpMSTaIgjwpMk22CvXsARi+pwLrnSiMX+FxgQgHBpO0D/9/8FMyERu5i5KocTzBaMSbmuTTI0SG916meFTzFiePYKHuIWa49d+YhOKMP/v6561ldzi5Q9XepJye9sZbO+8VCFowhfrD8yRPRqp2m+ZXeb5jBNDLRwhYePdqLUYqMvEl54gcmwNgo3RGtiuiWaohb9ijPgMSdU9jtMk9d2zF7QINbGVR8KaNoZ848K1kIhXwXnIMRnfT9mBR8AAk0yfGp3X6Vx+oYL2QKznCghPGPZk8Bpju+xJwM+lRuA2kozR8K9+V/iqASV3b3kWTByYN9eI+jGv/jNWIMQWXts9APcChPledcFe89oal9+qqkQZO7ocVH9Um05TaLbLBtvW3T4geRTHR8kzl4BwQW6g+jmGn3uCkWYdrhAdLQKuWKwXTCHTGtePWC8/FXBLynAV2sSbG1XlBimz1D8+wtSpjUzpB0= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MW4PR09MB10059.namprd09.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(366016)(4022899009)(56012099006)(4143699003)(5023799004)(6133799003)(22082099003)(18002099003)(55112099003)(3023799007)(8096899003)(13003099007)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?hyTRhdt9eWw/3Aj79MU+nFHRAyTBTvZE78dafNhKWLAxceh7IxxHkm3dhTBu?= =?us-ascii?Q?aKZq+5BiGWYmaVVqk/i2YIyExgImFKCyFeSf8eSHT/c+pMT+/6Li+P4qZbi6?= =?us-ascii?Q?79U6iEkOA5P4WQq55aHop6WjZh9fQs7HLqXDaz+XhUxBL9vUAEtt+DQkNNyc?= =?us-ascii?Q?SezkucWsEZgpzdxzi+Yh7E9kV7l6X+CPTzdAu0EjK20c/PBHQBhvrz2DRJxI?= =?us-ascii?Q?HwR8N1cRDXu2oUpkuhbvPM73rsPyjeAZbwpBuzVjJ+3RVsxKUjD2ds17NJ/x?= =?us-ascii?Q?3qxgFsuDKUGEXdoFwV7mLY7uuf1PH1SfA/3g4xlpdr0Corc90v31SBfmDS0m?= =?us-ascii?Q?d5aWb/G1wZ/grzZTxmF6C/43YtR4h7q7u3w5m80TLhXT2tc+4jVOou8hxUIU?= =?us-ascii?Q?7ObAwbiY36IOYvOm6aDgLq89TaCkI0CNAyjFmaMwmrKYtqGo3K5kvwWNZ3nx?= =?us-ascii?Q?10sHgJIBwD79Soy/S5rR67bYusvacU2ab8e4eEgqv7duWgrhSj0ca95uAXNB?= =?us-ascii?Q?ICuCT/70smRHeEx2qgk/QQnnoLsi8UoSSWCxrStC9ibtFHUSbs6BkNXQxgx7?= =?us-ascii?Q?VxQ/Sbuud7/VXD3BuCi/PF7ohi6wdyRZHklVV3wyS2ixfhfwCrQTtN0pTZbp?= =?us-ascii?Q?iqR4mUuXh4Aqyy5FzGzCX4VpqhRnKkoXdaR6VE1Q3V1w03bRCdid93aPRALv?= =?us-ascii?Q?IYnyyEuxAkoshQaxGphU1rVfOTZuWoJUr8WK0GIh0ivQxhRLJ7TBHq2Z3EeN?= =?us-ascii?Q?tjk3jTkx+A4ZWLDHe99Azr4iFlNaFErzd4J8TRIKrq52LusUI3i9ypcNzfrn?= =?us-ascii?Q?z/hG1w0nFKi0h1lrbaOhp+nYnu71sZXBl8kmBb93UziiEaXPVF3cNpDZud4L?= =?us-ascii?Q?9c+B4osNByLfpE42RATGnokc3xl1F3W2ynSXfvDOTIH1CjsYn9VSGebpz5Fu?= =?us-ascii?Q?TnraGgKP465tB6AIUBEV26e4vGbb+uDtOnuzWtaRMBVZfjNiW3tOwsAvaxr8?= =?us-ascii?Q?OxeHyRvFW2BJNLpvpQww6g8y1P29NGfCV6BlX9U9IEPw2PgMJ4aELhQILx2s?= =?us-ascii?Q?KxeAabXusFuqH77kxI2pBJtCHuTKklydLqV3nHKB+Czcdow5+7ULgBdS4c42?= =?us-ascii?Q?n84QDiknUfG9zTaWYjm0nu5dTPLoeSx5QmPB/EDESF1/sghSs6yNzeUc7/oC?= =?us-ascii?Q?f7nKhZLyWhBGCxNtv99f1L8rJQJQ+859wPYxoXS6ijF7jZ1b6Y2ufXTnAXBn?= =?us-ascii?Q?bRiSXSGM3PRq+EyDhN21MTl8oEkaBUhRgQSly41IKhdAkPXdCN1ux8GqMyiX?= =?us-ascii?Q?vPmbBMq4C4wPPKj/tkso393MiLSRO04F5O33gqZ4ImUCqqNx0FOse/WU2/J3?= =?us-ascii?Q?FG0wqOuLbHfeTn7jkr2uPmIRMH3so9ujeEAHKuz4JUg97r+YBKWWsb8ISkRq?= =?us-ascii?Q?Wl6K5jPupD+nAOZFR78JooVlpBiD/uIl9gFiBeGBafKliqel/8XqvcjGQuwW?= =?us-ascii?Q?7l7HRJhe0BhsHdgGeLp0jV/CnBHPPoa9RYzoAd5+7I1ksW/SWhdE+12LHEE1?= =?us-ascii?Q?nMMcJelf+/W8AO1/L5HQW5XKzxho5ZRupngxiJBhCLshch149xKWjX3wyPqo?= =?us-ascii?Q?iT2FVT/UWQnSalhNvVoO9sVIs9X1qfab6yibR4JHrjl/pDgBQGx0MocyTsP3?= =?us-ascii?Q?n0Hg/It+iFcACx571F1NiMB6vwg=3D?= Content-Type: multipart/alternative; boundary="_000_MW4PR09MB10059BA70D322CACF51690F7EF3FF2MW4PR09MB10059na_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW4PR09MB10059.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e80809cc-056d-4341-0072-08dedcdfa7dd X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2026 10:57:08.4850 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR09MB5370 Message-ID-Hash: IY6AVQJ2YFIECS42MI36YFJXMMCLVTWK X-Message-ID-Hash: IY6AVQJ2YFIECS42MI36YFJXMMCLVTWK X-MailFrom: quynh.dang@nist.gov X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "Markku-Juhani O. Saarinen" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BTLS=5D_Re=3A_=5BEXTERNAL=5D_Re=3A_WG_Last_Call=3A_draft-ietf-tl?= =?utf-8?q?s-mlkem-08_=28Ends_2026-07-08=29?= List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --_000_MW4PR09MB10059BA70D322CACF51690F7EF3FF2MW4PR09MB10059na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And NSA did not ask us to consider removing the hash. Regards, Quynh. From: Dang, Quynh H. (Fed) Sent: Wednesday, July 8, 2026 6:42 AM To: TLS List Cc: Markku-Juhani O. Saarinen Subject: RE: [EXTERNAL] [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (En= ds 2026-07-08) Hi all, See the discussion here about removing the hash of the message m. https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/WFRDl8DqYQ4/m/qmVAN= i7EAwAJ The reason to remove it was that hashing m would be bad, introduce a cost f= or side-channel security implementations (ask Markku for detail). In addit= ion, we require an approved RBG. If the RBG of a system is broken, or contr= olled by the attacker, the security of the whole system should be assumed t= o be broken anyway. I was a main author of the FIPS 203. Top level cryptographers know ML-KEM was not back-doored. Regards, Quynh. From: Thom Wiggers > Sent: Wednesday, July 8, 2026 5:52 AM To: Eliot Lear > Cc: > > Subject: [EXTERNAL] [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2= 026-07-08) Hi, ML-KEM is arguably not backdoorable unless you break the RNG. Bad RNG is so= mething that we can't really protect against anyway. Classic cryptography i= s also broken if the RNG is busted. Finally, the TLS key schedule still mix= es in all messages from both sides rendering the point moot for TLS. On a more instructive point, ETSI's "quantum-safe enterprise transport secu= rity" (ETSI TS 104 145, paragraph 5.3.2) relies exactly o= n generating the encapsulation seed deterministically instead of randomly s= ampling one. This mainly breaks forward secrecy, which is certainly bad. Bu= t hybrids or not are not relevant to this. In the classic approach they sim= ply fixed the DH public key of the server, iirc. Friends don't let friends = use ETS. Cheers, Thom Op 8 jul 2026, om 11:35 heeft Eliot Lear = > het volgende geschreven: Hi! ~~~~Disclaimer I'm not a cryptographer. ~~~~ Please see below. On 08.07.2026 08:04, Viktor Dukhovni wrote: On Tue, Jul 07, 2026 at 10:27:56PM -0700, Christian Huitema wrote: I just read Jacob Applebaum's message. Given his description of the late-standardization suspicious change that looks like a backdoor in the ML-KEM specification, I agree with his conclusion. The WG should not ask fo= r publication of the current graph, not until the changes requested by Jacob are made. The removal of whitening of the `m` random input to Encaps is not a plausible backdoor. If all you have is a broken RNG, you're free to apply whitening to obtain a new less bad RNG and use that instead. Nothing stops an ML-KEM implementation from hashing some input (any number of times, mixing in whatever additional inputs, ...) to produce its random values. The abstract algorithm starts from the final output of an adequate RNG that requires no further post-processing. There's nothing suspicious about this simplification. The critique in question makes no sense to me. Don't use a broken RNG. That sounds about right to me, but as someone who is not a cryptographer, p= erhaps someone who is could explain how this amounts to a back door, and no= t a requirement for a good PRNG? And if it's not a back door, should we re= ally relitigate NIST's choices here? Eliot * By "back door", I mean an intentionally placed undisclosed weakness that = could be exploited by the people who placed it there. ___________________________________________= ____ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-leave@ietf.org --_000_MW4PR09MB10059BA70D322CACF51690F7EF3FF2MW4PR09MB10059na_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

And NSA did not ask= us to consider removing the hash.

 

Regards,=

Quynh. <= /span>

 

From: Dang, Quynh H. (Fed)
Sent: Wednesday, July 8, 2026 6:42 AM
To: TLS List <tls@ietf.org>
Cc: Markku-Juhani O. Saarinen <mjos.crypto@gmail.com>
Subject: RE: [EXTERNAL] [TLS] Re: WG Last Call: draft-ietf-tls-mlkem= -08 (Ends 2026-07-08)

 

Hi all,<= /span>

 

See the discussion = here about removing the hash of the message m.

 

https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/WFRDl8DqYQ4/m/qmVA= Ni7EAwAJ

 

The reason to remov= e it was that hashing m would be bad, introduce a cost for side-channel sec= urity implementations (ask Markku for detail).  In addition, we requir= e an approved RBG. If the RBG of a system is broken, or controlled by the attacker, the security of the whole system= should be assumed to be broken anyway.

 

I was a main author= of the FIPS 203.

 

Top level cryptogra= phers know ML-KEM was not back-doored.

 

Regards,=

Quynh. <= /span>

 

From: Thom Wiggers <thom@thomwiggers.nl>
Sent: Wednesday, July 8, 2026 5:52 AM
To: Eliot Lear <lear@lear.ch&= gt;
Cc: <tls@ietf.org> <tls@ietf.org>
Subject: [EXTERNAL] [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 = (Ends 2026-07-08)

 

Hi,

 

ML-KEM is arguably not backdoorable unless you break= the RNG. Bad RNG is something that we can’t really protect against a= nyway. Classic cryptography is also broken if the RNG is busted. Finally, t= he TLS key schedule still mixes in all messages from both sides rendering the point moot for TLS.

 

On a more instructive point, ETSI’s “qua= ntum-safe enterprise transport security” ( 

Cheers,

 

Thom

 

 

Hi!

~~~~Disclaimer
I'm not a cryptographer.
~~~~

Please see below.

On 08.07.2026 08:04, Viktor Dukhovni wrote:<= /o:p>

On Tue, Jul 07, 2026 at 10:27:56PM -0700, Christian Huitema wrote:
 
I just read Jacob Applebaum's message. Given his description of the
late-standardization suspicious change that looks like a backdoor in t=
he
ML-KEM specification, I agree with his conclusion. The WG should not a=
sk for
publication of the current graph, not until the changes requested by J=
acob
are made.
The removal of whitening of the `m` random input to Encaps is not a
plausible backdoor.  If all you have is a broken RNG, you're free=
 to
apply whitening to obtain a new less bad RNG and use that instead.
 
Nothing stops an ML-KEM implementation from hashing some input (any
number of times, mixing in whatever additional inputs, ...) to produce=

its random values.  The abstract algorithm starts from the final =
output
of an adequate RNG that requires no further post-processing.
 
There's nothing suspicious about this simplification.  The critiq=
ue in
question makes no sense to me.  Don't use a broken RNG.

 

That sounds about right to me, but as someone who is not a cryptographer= , perhaps someone who is could explain how this amounts to a back door, and= not a requirement for a good PRNG?  And if it's not a back door, should we really relitigate NIST's choices here?

Eliot


* By "back door", I mean an intentionally placed undisclosed weak= ness that could be exploited by the people who placed it there.<= /span>

 

<OpenPGP_0x87B66B46D9D27A33.asc>___________= ____________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to = tls-leave@ietf.org

 

--_000_MW4PR09MB10059BA70D322CACF51690F7EF3FF2MW4PR09MB10059na_--