-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Aloha!
Efthymios Iosifides wrote:
> The reputation aspect is not necessarily and strictly correlated
> with it's provenance, but with it's actual security and performance.
> And the SPECK we shall note that performs quite well. Also we shall
> not
Hi
I think Rich Salz already said exactly what CFRG would say:
> If someone wants to see SPECK adopted by IETF protocols, the first thing
>that will have to happen is papers analyzing it.
There's some analysis already, but not that much.
Regards,
Kenny
On 21/03/2016 14:27, "TLS on behalf
If we’re going to get into the cryptanalysis of SPECK then this thread should
move off the TLS list and possibly to the CFRG list.
spt
> On Mar 21, 2016, at 10:07, Efthymios Iosifides wrote:
>
> >I don't see any compelling argument for the inclusion of SPECK? Not only
>
> other hand we shall evaluate if the SPECK could be actually used
> what about the future specifications
> what if we could prove that ..
Those are all great questions. But in the current state of things, they are
unanswered questions.
If someone wants to see SPECK adopted by IETF protocols,
>I don't see any compelling argument for the inclusion of SPECK? Not only
would the affiliation with NSA give the >TLS-WG a bad rep. in the public,
more importantly, it makes one of our main problems worse: combinatorial
explosion >of possible cipher-suites in TLS. This problem is so bad that it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Aloha!
Tom Ritter wrote:
> On 17 March 2016 at 21:09, Martin Thomson
> wrote:
>> On 18 March 2016 at 12:37, Mike Hamburg
>> wrote:
>>> No. The goal should be to remove ciphers, not add new ones,
>>>
On 17 March 2016 at 21:09, Martin Thomson wrote:
> On 18 March 2016 at 12:37, Mike Hamburg wrote:
>> No. The goal should be to remove ciphers, not add new ones, unless we have
>> a really compelling reason.
>
> A necessary, but sufficient set of
There is no serious proposal to use Speck in TLS 1.3. One major reason is that
there is insufficient cryptanalysis of it.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Piling on, I can't see why we would want to do this
-Ekr
On Thu, Mar 17, 2016 at 7:09 PM, Martin Thomson
wrote:
> On 18 March 2016 at 12:37, Mike Hamburg wrote:
> > No. The goal should be to remove ciphers, not add new ones, unless we
> have
> >
Hello all.
I have just found on the ietf archives an email discussion about the
inclusion of the SPECK Cipher
in the tls standards.
It's reference is below :
https://www.ietf.org/mail-archive/web/tls/current/msg13824.html
Even though that this cipher originates from the NSA one cannot find a
On 18 March 2016 at 12:37, Mike Hamburg wrote:
> No. The goal should be to remove ciphers, not add new ones, unless we have
> a really compelling reason.
A necessary, but sufficient set of reasons might include:
1. thorough cryptanalysis
2. advantages over existing ciphers
No. The goal should be to remove ciphers, not add new ones, unless we have a
really compelling reason. Short source code is not a compelling reason in a
protocol so complicated as TLS.
Cheers,
— Mike
> On Mar 16, 2016, at 11:35 PM, Efthymios Iosifides
> wrote:
>
>
12 matches
Mail list logo