Subject: [TLS] Revised I-D: Use of KCipher-2 with Poly1305 in Transport Layer Security (draft-kiyomoto-kcipher2-tls-02)

From: Yoshiaki Hori <[email-masked]>
Date: Mon, 2 Nov 2015 22:52:59 +0900

Hi,

We've posted a new version of “Use of KCipher-2 with Poly1305
in Transport Layer Security” (draft-kiyomoto-kcipher2-tls-02)
that address to add a cipher suite, KCipher-2 [RFC7008] and
Poly1305 running with AEAD for TLS1.2.

Name:           draft-kiyomoto-kcipher2-tls
Revision:       02
Title:          Use of KCipher-2 with Poly1305 in Transport Layer Security
Document date:  2015-11-01
Group:          Individual Submission
Pages:          6
URL:
https://www.ietf.org/internet-drafts/draft-kiyomoto-kcipher2-tls-02.txt
Status:
https://datatracker.ietf.org/doc/draft-kiyomoto-kcipher2-tls/
Htmlized:       https://tools.ietf.org/html/draft-kiyomoto-kcipher2-tls-02
Diff:
https://www.ietf.org/rfcdiff?url2=draft-kiyomoto-kcipher2-tls-02

Abstract:
   This document describes the use of the KCipher-2 stream cipher with
   Poly1305 in Transport Layer Security (TLS) protocols version 1.2 and
   Datagram Transport Layer Security (DTLS) protocols.  KCipher-2 is a
   stream cipher with a 128-bit key and a 128-bit initialization vector,
   which provides fast, efficient encryption and decryption.

We address alternative stream cipher suite for TLS because we
concern a risk of “single stream cipher suite, Chacha20 with
Poly1305. Our colleague is preparing KCipher-2 with Poly1305
code based on openssl-1.0.2 which will be available as an open
source soon.

The current Kcipher-2 with Poly1305 implementation can run with
around 60% or more throughput comparing with Chacha20-Poly1305
under a small block size, e.g. 16 bytes and 64 bytes.
We expect performance improvement with further optimization
because the current code development in an early stage.

We have tentative two performance reports run with different
environment, which are indicated with [i] and [k] respectively.
The case [i] is running with Intel(R) Core(TM) i5-4300U
[email-masked] 2.50GHz / RAM 8.00GB / openSUSE13.2 64bit.
Also, the case [k] is with Intel(R) Core(TM) i7-4770K 3.50GHz /
 Host OS: Windows 7 64bit with 32GB / Guest OS: Ubuntu 14.10
64bit with 7GB / gcc 4.9.1.

Performance Results:

(1) in case [i] environment: with Intel(R) Core(TM) i5-4300U
    [email-masked] 2.50GHz / RAM 8.00GB / openSUSE13.2 64bit.

chacha20-poly1305 [i]:

block size [byte]   throughput [kbytes/sec]
      16               31,586.83
      64              101,580.14
     256              188,614.93
    1024              248,756.57
    8192              272,231.08

kc2-poly1305 [i]:

block size [byte]   throughput [kbytes/sec]
      16               16,938.10
      64               54,679.51
     256              156,798.30
    1024              294,867.97
    8192              388,743.17

(2) in case [k] environment: with Intel(R) Core(TM) i7-4770K
    3.50GHz / Host OS: Windows 7 64bit with 32GB / Guest OS:
    Ubuntu 14.10 64bit with 7GB / gcc 4.9.1

chacha20-poly1305 with no-SIMD [k]:

block size [byte]   throughput [kbytes/sec]
      16               51,704.44
      64              173,918.85
     256              403,878.27
    1024              616,232.62
    8192              721,810.77

kc2-poly1305 [k]:

block size [byte]   throughput [kbytes/sec]
      16               30,338.55
      64              101,063.15
     256              284,340.82
    1024              544,837.63
    8192              736,327.00

Yoshiaki Hori

---

From: Hanno Böck <[email-masked]>
Date: Tue, 3 Nov 2015 12:37:57 +0100

On Mon, 2 Nov 2015 22:52:59 +0900
Yoshiaki Hori <[email-masked]> wrote:

> Title:          Use of KCipher-2 with Poly1305 in Transport Layer

I feel I've written almost the same on multiple occassions lately, but
I'll do it again:

I think one of the major problems of TLS (and other crypto) in the past
has been that it has grown to be too complicated. I'm therefore
strictly against adding new options without any reasonable rationale
behind them.

The rationale here seems to be "let's have another algorithm just in
case". That "just in case" here is that if chacha20 turns out to be
insecure we don't have another streamcipher. However we'd of course
still have AES-GCM.

I think TLS has suffered a lot in the past from feature bloat. I'd
propose to go the other way: Lower the number of options if they don't
make sense.

Therefore: Please don't introduce another algorithm into TLS - unless
you have very good arguments (i.e. it is vastly better than the other
options or you have serious arguments why you think AES-GCM and
chacha20/poly1305 are in danger of being real-world-broken any time
soon).

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: [email-masked]
GPG: BBB51E42