Hi all,
Why don't we use an even more elegant RSA signature called " full-domain hash
RSA signature" ?
As you know, a SHAKE (as a variable output-length hash function) naturally
produces a hash value which fits any given modulus size. Therefore, no paddings
are needed which avoids any potentia
AM
To: tls@ietf.org
Subject: Re: [TLS] RSA-PSS in TLS 1.3
On Thu, 3 Mar 2016 13:35:46 +
"Dang, Quynh (Fed)" wrote:
> Why don't we use an even more elegant RSA signature called "
> full-domain hash RSA signature" ?
Full Domain Hashing was originally developed
PSS+SHAKE128/512+SHAKE128 or PSS+SHAKE256/512+SHAKE256 (as SHAKEs being used as
MGF) would be more efficient options. NIST is working on a formal specification
for the SHAKEs being used as fixed output-length hash functions such as
SHAKE128/256, SHAKE128/512 and SHAKE256/512.
Prepending a rand
Hi Sean and all,
I support the first condition: A spec gets a "Y" when it has the IETF consensus.
Regards,
Quynh.
From: TLS on behalf of Hannes Tschofenig
Sent: Thursday, March 31, 2016 9:45 AM
To: Sean Turner;
Subject: Re: [TLS] call for consensus:
Hi Sean,
I would like to express my opinion again.
I think the first requirement is great and sufficient.
I have great support, appreciation and respect for the open source communities.
However, the second requirement means that an IETF consensus can have no values
in theory and that sounds n
Hi Stephen,
The one below can be used.
[FIPS 180-4] Federal Information Processing Standards Publication
(FIPS PUB) 180-4, Secure Hash Standard (SHS), August 2015.
Regards,
Quynh.
From: TLS on behalf of Stephen Farrell
Sent: Thursday,
Hi Eric,
1. For this text: "plus the length of the output of the signing algorithm. "
in the last paragraph of Section 4.8.1, did you mean "plus the output of the
signing algorithm." ?
2. "The length (in bytes) of the following TLSCiphertext.fragment. The length
MUST NOT exceed 2^14 + 256. An
On 5/24/16, 12:13 PM, "Martin Thomson" wrote:
>On 24 May 2016 at 08:20, Dang, Quynh (Fed) wrote:
>> 1. For this text: "plus the length of the output of the signing
>>algorithm.
>> " in the last paragraph of Section 4.8.1, did you mean "plus the o
On 5/24/16, 12:58 PM, "ilariliusva...@welho.com on behalf of Ilari
Liusvaara" wrote:
>On Tue, May 24, 2016 at 03:20:17PM +, Dang, Quynh (Fed) wrote:
>> Hi Eric,
>>
>> 1. For this text: "plus the length of the output of the signing
>> algorithm
On 5/24/16, 2:42 PM, "Martin Thomson" wrote:
>On 24 May 2016 at 10:46, Dang, Quynh (Fed) wrote:
>>>We discussed this at quite some length. I originally took your
>>>position, but the IVs add an extra layer of safety at very little
>>>cost.
>>
Hi Eric and all,
In my opinion, we should give better information about data limit for AES_GCM
in TLS 1.3 instead of what is current in the draft 14.
In this paper: http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf, what is called
confidentiality attack is the known plaintext differentiality atta
Hi Eric and all,
In my opinion, we should give better information about data limit for AES_GCM
in TLS 1.3 instead of what is current in the draft 14.
In this paper: http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf, what is called
confidentiality attack is the known plaintext differentiality atta
eaking this notion does
>not break confidentiality. Can you explain what you mean by
>"confidentiality", in a precise way? I can then try to tell you whether
>this notion will imply yours.
>
>Regards
>
>Kenny
>
>On 12/07/2016 14:04, "TLS on behalf of Dang, Quynh
>>data bytes. To come to the 2^38 record limit, they assume that each
>>record is the maximum 2^14 bytes. Of course, at a 1Gbps rate, it'd take
>>over a year to encrypt that much data...
>>
>>> -----Original Message-
>>> From: TLS [mailto:tls-boun
Hi Kenny,
On 7/12/16, 1:05 PM, "Paterson, Kenny" wrote:
>Hi
>
>On 12/07/2016 16:12, "Dang, Quynh (Fed)" wrote:
>
>>Hi Kenny,
>>
>>The indistinguishability-based security notion in the paper is a stronger
>>security notion than the (old)
Hi Kenny,
On 7/12/16, 1:39 PM, "Paterson, Kenny" wrote:
>Hi
>
>On 12/07/2016 18:12, "Dang, Quynh (Fed)" wrote:
>
>>Hi Kenny,
>>
>>On 7/12/16, 1:05 PM, "Paterson, Kenny" wrote:
>>
>>>Hi
>>>
>>>On 12/
the maximum 2^14 bytes. Of course, at a 1Gbps rate, it'd take
>>over a year to encrypt that much data...
>>
>>> -----Original Message-
>>> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Dang, Quynh (Fed)
>>> Sent: Tuesday, July 12, 2016 11:1
Good morning Kenny,
On 7/12/16, 3:03 PM, "Paterson, Kenny" wrote:
>Hi,
>
>> On 12 Jul 2016, at 18:56, Dang, Quynh (Fed) wrote:
>>
>> Hi Kenny,
>>
>>> On 7/12/16, 1:39 PM, "Paterson, Kenny"
>>>wrote:
>>>
>>
Hi Kenny,
On 7/12/16, 3:03 PM, "Paterson, Kenny" wrote:
>Hi,
>
>> On 12 Jul 2016, at 18:56, Dang, Quynh (Fed) wrote:
>>
>> Hi Kenny,
>>
>>> On 7/12/16, 1:39 PM, "Paterson, Kenny"
>>>wrote:
>>>
>>
, Scott Fluhrer (sfluhrer) wrote:
>>> -Original Message-
>>> From: Paterson, Kenny [mailto:kenny.pater...@rhul.ac.uk]
>>> Sent: Tuesday, July 12, 2016 1:17 PM
>>> To: Dang, Quynh (Fed); Scott Fluhrer (sfluhrer); Eric Rescorla;
>>> tls@ietf.org
>>> Su
known plaintexts. In protocols such as TLS and Ipsec, there are known
plaintexts, but I don¹t think the amount of known plaintexts (even though
the amount of encrypted repeated-plaintexts can be big) is enough to
create risk for AES_128 by the targeted plaintext recovery attack. A known
plaintex
Hi Eric and all,
Regardless of the actual record size, each 128-bit block encryption is
performed with a unique 128-bit counter which is formed by the 96-bit IV and
the 32-bit counter_block value called CB in NIST SP 800-38D under a given key
as long as the number of encrypted records is not mo
eying too often than needed would just create more room for issues for the
connection/session without gaining any additional practical security at all.
Quynh.
From: Martin Thomson
Sent: Sunday, November 13, 2016 6:54 PM
To: Dang, Quynh (Fed)
Cc: e...@rtfm.
Hi Ilari,
You were right, for testing, a smaller number should be used.
Quynh.
From: ilariliusva...@welho.com on behalf of Ilari
Liusvaara
Sent: Monday, November 21, 2016 3:42 PM
To: Dang, Quynh (Fed)
Cc: Martin Thomson; tls@ietf.org; c...@ietf.org
Hi Sean and all,
I agree with everyone that the text in (b) was not very good text.
The problem with (c) is that it is not precise at places and it leaves out a
lot of informative discussions which users should know.
The sentence "The maximum amount of plaintext data that can be safely encry
Hi Kenny,
From: TLS mailto:tls-boun...@ietf.org>> on behalf of
"Paterson, Kenny" mailto:kenny.pater...@rhul.ac.uk>>
Date: Friday, February 10, 2017 at 4:06 AM
To: Sean Turner mailto:s...@sn3rd.com>>
Cc: IRTF CFRG mailto:c...@irtf.org>>,
"mailto:tls@ietf.org>>" mailto:tls@ietf.org>>
Subject: Re:
Hi Rene,
From: TLS mailto:tls-boun...@ietf.org>> on behalf of Rene
Struik mailto:rstruik@gmail.com>>
Date: Friday, February 10, 2017 at 10:51 AM
To: Sean Turner mailto:s...@sn3rd.com>>,
"mailto:tls@ietf.org>>" mailto:tls@ietf.org>>
Cc: IRTF CFRG mailto:c...@irtf.org>>
Subject: Re: [TLS] [Cfr
tls@ietf.org>>" mailto:tls@ietf.org>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
(#765/#769)
Dear Quynh,
On 10/02/2017 12:48, "Dang, Quynh (Fed)"
mailto:quynh.d...@nist.gov>> wrote:
Hi Kenny,
Hi,
My preference is to go with th
truik
Sent: Friday, February 10, 2017 2:02:14 PM
To: Dang, Quynh (Fed); Sean Turner;
Cc: IRTF CFRG
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
(#765/#769)
Hi Quynh:
Not sure where to start (there is vast literature on side channel attacks and
other impleme
o either measure the amount of plaintext or ciphertext.
Regards,
Quynh.
From: Paterson, Kenny
Sent: Friday, February 10, 2017 2:06:46 PM
To: Dang, Quynh (Fed); Sean Turner
Cc: IRTF CFRG;
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PR
Hi Markulf,
The probability of a bad thing to happen is actually below (or about) 2^(-33).
It practically won’t happen when the chance is 1 in 2^32. And, to achieve that
chance, you must collect 2^48 128-bit blocks.
Regards,
Quynh.
From: TLS mailto:tls-boun...@ietf.org>> on behalf of
Markulf
Hi Markulf and all,
I provided more explanation below.
From: 'Quynh' mailto:quynh.d...@nist.gov>>
Date: Monday, February 13, 2017 at 10:45 AM
To: Markulf Kohlweiss mailto:mark...@microsoft.com>>,
"Paterson, Kenny"
mailto:kenny.pater...@rhul.ac.uk>>, Sean Turner
mailto:s...@sn3rd.com>>
Cc: Anto
n't think point 2 is a problem because it gives people a good enough
heuristic, however this can be fixed easily by minimally modifying the
original text.
Atul
On 2017-02-14 03:59, Dang, Quynh (Fed) wrote:
Hi Markulf and all,
I provided more explanation below.
From: 'Quynh'
t;
Regards,
Quynh.
________
From: Dang, Quynh (Fed)
Sent: Tuesday, February 14, 2017 1:20:12 PM
To: Atul Luykx; Dang, Quynh (Fed)
Cc: Markulf Kohlweiss; Antoine Delignat-Lavaud; IRTF CFRG; tls@ietf.org
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage&q
nding to a success probability of 2^{-32}.
Atul
On 2017-02-14 11:45, Yoav Nir wrote:
Hi, Quynh
On 14 Feb 2017, at 20:45, Dang, Quynh (Fed)
mailto:quynh.d...@nist.gov>>
wrote:
Hi Sean and all,
Beside my suggestion at
https://www.ietf.org/mail-archive/web/tls/current/msg22381.html [1],
I hav
.3 "Limits on key usage" PRs
(#765/#769)
Hi Quynh,
I'm meant to be on vacation, but I'm finding this on-going discussion
fascinating, so I'm chipping in again.
On 15 Feb 2017, at 21:12, Dang, Quynh (Fed)
mailto:quynh.d...@nist.gov>> wrote:
Hi Atul,
I hope you
Hi Sean, Joe, Eric and all,
I would like to address my thoughts/suggestions on 2 issues in option a.
1) The data limit should be addressed in term of blocks, not records. When the
record size is not the full size, some user might not know what to do. When the
record size is 1 block, the limit
g>>
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769).
On 25 Feb 2017, at 14:28, Dang, Quynh (Fed)
mailto:quynh.d...@nist.gov>> wrote:
Hi Sean, Joe, Eric and all,
I would like to address my thoughts/suggestions on 2 issues in option a.
1) The data li
gt;>" mailto:tls@ietf.org>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
(#765/#769).
Hi,
On 01/03/2017 14:31, "TLS on behalf of Dang, Quynh (Fed)"
mailto:tls-boun...@ietf.org> on behalf of
quynh.d...@nist.gov<mailto:quynh.d...@nist.g
g>>
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769).
On 01 Mar 2017, at 13:18, Dang, Quynh (Fed)
mailto:quynh.d...@nist.gov>> wrote:
From: Aaron Zauner mailto:a...@azet.org>>
Date: Wednesday, March 1, 2017 at 8:11 AM
To: 'Quynh' mai
What is the percentage ? Even all records were small, providing a correct
number would be a good thing. If someone wants to rekey a lot often, I am not
suggesting against that.
Quynh.
because they result from small writes.
On Mar 1, 2017 6:48 AM, "Dang, Quynh (Fed)"
mailto:quynh.d...@ni
;,
"tls@ietf.org<mailto:tls@ietf.org>" mailto:tls@ietf.org>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
(#765/#769).
On 2 March 2017 at 05:44, Dang, Quynh (Fed)
mailto:quynh.d...@nist.gov>> wrote:
OK. What is the percentage ? E
42 matches
Mail list logo
