Internet DRAFT - draft-moskowitz-small-crypto
draft-moskowitz-small-crypto
CURDLE R. Moskowitz
Internet-Draft L. Xia
Intended status: Informational Huawei
Expires: May 3, 2018 October 30, 2017
Small Crypto for Small IOT
draft-moskowitz-small-crypto-00
Abstract
This memo proposes to leverage the Keccak algorithm at a function
"width" of b=400 to provide a set of "small" cryptographic functions
well suited to the IOT constrained environment. As such, only 128
bit security level is provided here. The full set of NIST approved
Keccak derived functions that can work within the b=400 constraint,
plus the 3rd round candidate in the CAESAR competition, Ketje, are
defined.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Moskowitz & Xia Expires May 3, 2018 [Page 1]
Internet-Draft Small Crypto October 2017
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Document status . . . . . . . . . . . . . . . . . . . . . 3
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3
2.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
3. Keccak Basics . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Keccak Parameters . . . . . . . . . . . . . . . . . . . . 4
4. Keccak[144,256] . . . . . . . . . . . . . . . . . . . . . . . 4
5. The Ketje authenticated encryption scheme . . . . . . . . . . 5
6. Using SHAKE128i in Ed25519 . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8.1. Defense against future attacks . . . . . . . . . . . . . 5
8.2. Security Comparisons . . . . . . . . . . . . . . . . . . 5
8.2.1. SHAKE128i to SHA-256 . . . . . . . . . . . . . . . . 5
8.2.2. KMAC128i to HMAC(SHA-256) . . . . . . . . . . . . . . 5
8.2.3. Ketje Sr to AES-CCM . . . . . . . . . . . . . . . . . 5
8.2.4. Ed25519i to Ed25519 . . . . . . . . . . . . . . . . . 6
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
10.1. Normative References . . . . . . . . . . . . . . . . . . 6
10.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 7
A.1. Pacemaker connected via Body Area Network . . . . . . . . 7
A.2. Automotive CAN FD Sensors . . . . . . . . . . . . . . . . 7
A.3. Building Automation and Control Network Sensors . . . . . 8
Appendix B. Performance Comparisons . . . . . . . . . . . . . . 8
B.1. SHAKE128i to SHA-256 . . . . . . . . . . . . . . . . . . 8
B.2. KMAC128i to HMAC(SHA-256) . . . . . . . . . . . . . . . . 8
B.3. Ketje Sr to AES-CCM . . . . . . . . . . . . . . . . . . . 8
B.4. Ed25519i to Ed25519 . . . . . . . . . . . . . . . . . . . 8
B.5. Keccak Hardware to AES Hardware . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
The Keccak [Keccak] algorithm at a width of b=1600 was selected by
NIST for SHA-3 as defined in FIPS 202 [NIST.FIPS.202]. It is further
used to define additional hashing functions in NIST SP 800-185
[NIST.SP.800_185], all with b=1600. This selection is well suited
for 64 bit processors and large messages. It can take advantage of
multiple core CPUs and works well even on 32 bit processors. It is
Moskowitz & Xia Expires May 3, 2018 [Page 2]
Internet-Draft Small Crypto October 2017
not well suited for small messages and 8 bit processors that are
common in IOT.
A full set of function widths of 25, 50, 100, 200, 400, and 800 are
also defined in Keccak. Selection of values of other than 1600 is a
risk/design trade off. A width of 400 is used here as the smallest
that can provide 128 bits security strength.
Keccak provides more than a secure hash function. FIPS 202 defines
the SHAKE function to provide a hash output of arbitrary length,
rather than current practice of truncating a longer hash to the
needed length. SP 800-185 defines a keyed hash, KMAC, that does not
require the HMAC complexity and computational cost. This also can
provide a PRF.
Finally, Keccak also provides an AEAD cipher, Ketje, to thus deliver
in a single base function, the full suite of symmetric cryptographic
functions.
1.1. Document status
Significant portions of this document are stubs. That is not because
the information is not available. Rather the information for those
sections need to be formatted for inclusion in this document. All
the algorithms exist for Keccak and need only be adjusted for B=400.
There is considerable performance data and security comparison data
from the Keccak team. It needs extraction from other publications
and formatted into this document.
2. Terms and Definitions
2.1. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2.2. Notations
This section will contain notations
2.3. Definitions
TBD
Moskowitz & Xia Expires May 3, 2018 [Page 3]
Internet-Draft Small Crypto October 2017
3. Keccak Basics
Keccak is a extendable-output function (XOF) sponge construction
hash. It breaks from the 'standard' ARX (addition, rotation and
exclusive-or (XOR)) hash approach. Instead it using only bit-level
transpositions, bit-level additions and multiplications (in GF(2)).
This contributes to its superior performance.
This leads to one important nomenclature difference in Keccak. It
does not have a block size. Rather in Keccak there is bit-rate which
is one of the variable parameters.
3.1. Keccak Parameters
The Keccak primitive is:
Keccak-f[b], where b is 25, 50, 100, 200, 400, 800 or 1600 bits
b=1600 is used in FIPS 202 and SP 800-185. Here, b=400 is used.
Instances are denoted
Keccak[r, c]
capacity c determines the proven security strength against
generic attacks
for a security level of n bits, the capacity must be c = 2n
and bitrate r = b - c
Thus for b=400 and a strength of 128 bits, r=144 and c=256
4. Keccak[144,256]
The instance Keccak[144,256] can be used for SHAKE128 [FIPS 202],
cSHAKE128, KMAC128, KMACXOF128, TupleHash128, TupleHashXOF128,
ParallelHash128, ParallelHashXOF128 [SP 800-185]. The difference is
a bitrate of 144 rather than 1344.
Some of the above variants, such as the parallel hashes are not of
value in small devices with small r which is not amendable to tree
hashing.
To distinguish the form of the above hashes between the standard
r=1344 and r=144, a designation of 'i' is appended to each name so
that here SHAKE128i and KMAC128i are used.
Moskowitz & Xia Expires May 3, 2018 [Page 4]
Internet-Draft Small Crypto October 2017
5. The Ketje authenticated encryption scheme
Ketje Sr [Ketje] is already defined to use b=400.
6. Using SHAKE128i in Ed25519
Ed25519, RFC 8032 [RFC8032], specifies the parameter H(x) as SHA-512.
A new form, Ed25519i, will use SHAKE128i for H(x). This one change
will bring Ed25519 more into the 'reach' of the constrained
environment.
The use of SHAKE128i is the only variant between Ed25519 and
Ed25519i.
7. IANA Considerations
TBD. OID assignments
8. Security Considerations
8.1. Defense against future attacks
The safety margin in Keccak can be increased or de-creased simply by
changing the number of rounds in Keccak-f. This is explained in
"Note on Keccak parameters and usage" [NotesPandU], Section 6.
8.2. Security Comparisons
This memo proposes a radical change in the basic cryto-primatives
used in protocols. As such, care is called for.
Keccak is not new. It has been well reviewed as explained in "Why
Keccak is not ARX" [notARX]. Still, it is important to compare each
Keccak function proposed here against the current Best Practice.
8.2.1. SHAKE128i to SHA-256
TBD.
8.2.2. KMAC128i to HMAC(SHA-256)
TBD.
8.2.3. Ketje Sr to AES-CCM
TBD.
Moskowitz & Xia Expires May 3, 2018 [Page 5]
Internet-Draft Small Crypto October 2017
8.2.4. Ed25519i to Ed25519
TBD.
9. Acknowledgments
Sections here draw heavily on information available on the Keccak
[Keccak] site. I thank the Keccak Team in making this information
openly available.
10. References
10.1. Normative References
[NIST.FIPS.202]
Dworkin, M., "SHA-3 Standard: Permutation-Based Hash and
Extendable-Output Functions", FIPS PUB 202,
DOI 10.6028/nist.fips.202, August 2015,
<http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf>.
[NIST.SP.800_185]
Kelsey, J., Change, S., and R. Perlner, "SHA-3 Derived
Functions: cSHAKE, KMAC, TupleHash and ParallelHash",
Special Publication SP 800-185,
DOI 10.6028/nist.sp.800-185, December 2016,
<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-185.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, <https://www.rfc-
editor.org/info/rfc8032>.
10.2. Informative References
[IEEE.802.15.6_2012]
IEEE, "IEEE Standard for Local and metropolitan area
networks - Part 15.6: Wireless Body Area Networks",
IEEE 802.15.6-2012, DOI 10.1109/ieeestd.2012.6161600,
February 2012, <http://ieeexplore.ieee.org/servlet/
opac?punumber=6161598>.
Moskowitz & Xia Expires May 3, 2018 [Page 6]
Internet-Draft Small Crypto October 2017
[Keccak] Bertoni, G., Daemen, J., Peeters, M., Van Assche, G., and
R. Van Keer, "Team Keccak Home Page",
<https://keccak.team/index.html>.
[Ketje] Bertoni, G., Daemen, J., Peeters, M., Van Assche, G., and
R. Van Keer, "The Ketje authenticated encryption scheme",
<https://keccak.team/ketje.html>.
[notARX] "Why Keccak is not ARX", <https://keccak.team/2017/
not_arx.html>.
[NotesPandU]
Bertoni, G., Daemen, J., Peeters, M., and G. Van Assche,
"Note on Keccak parameters and usage", February 2010,
<https://keccak.team/files/
NoteOnKeccakParametersAndUsage.pdf>.
[RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S.
Donaldson, "Transmission of IPv6 over Master-Slave/Token-
Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163,
May 2017, <https://www.rfc-editor.org/info/rfc8163>.
Appendix A. Use Cases
TBD.
A.1. Pacemaker connected via Body Area Network
In-body sensors, like pacemakers, connected via the Body Area Network
(BAN [IEEE.802.15.6_2012]) will be very power conscious. Battery
replacement can often require surgery. This will lead to loose
interpretation of the HIPAA protection requirements to the detriment
of the patient. In-body sensors are an important class of devices
that would benefit from the most power and code efficient security
components that still meet a strong security claim.
A.2. Automotive CAN FD Sensors
CAN FD (CAN with Flexible Data-Rate) is an extension to the original
CAN bus protocol specified in ISO 11898-1. Developed in 2011 and
released in 2012. Its larger data payload of 64 bytes can support a
encrypting and authenticating protocol, but various in-vehicle
constraints can make this challenging. Sensors may be in a very high
temperature environment, making even a marginal CPU temperature
increase due to heavy computations catastrophic. Cost is always a
automotive component constraint and security tends to come in last in
the cost competition. Thus any way that the cost of security can be
lowered is a major win.
Moskowitz & Xia Expires May 3, 2018 [Page 7]
Internet-Draft Small Crypto October 2017
A.3. Building Automation and Control Network Sensors
BACnet (ISO 16484-5) is the standard for wired, in-building control
systems. Recently IPv6 support (RFC 8163 [RFC8163]) was added. Some
BACnet devices are extremely constrained; 4-bit processors are still
common. Though AES on such 4-bit processors is available, it is
extremely slow. A smaller security suite would be a real benefit for
this environment.
Appendix B. Performance Comparisons
Most new crypto algorithm changes are to reduce risk. This proposal
is to reduce cost and thus enable security in a lower class of
devices as currently supported. This will only come about if there
is a real performance improvement to justify potential non-
interoperability.
Performance improvements can come for lower CPU/power demands,
smaller code size, and/or smaller storage/memory requirements.
B.1. SHAKE128i to SHA-256
TBD. Magnitude faster?
B.2. KMAC128i to HMAC(SHA-256)
TBD.
B.3. Ketje Sr to AES-CCM
TBD.
B.4. Ed25519i to Ed25519
TBD.
B.5. Keccak Hardware to AES Hardware
TBD.
Authors' Addresses
Robert Moskowitz
Huawei
Oak Park, MI 48237
Email: rgm@labs.htt-consult.com
Moskowitz & Xia Expires May 3, 2018 [Page 8]
Internet-Draft Small Crypto October 2017
Liang Xia
Huawei
No. 101, Software Avenue, Yuhuatai District
Nanjing
China
Email: Frank.xialiang@huawei.com
Moskowitz & Xia Expires May 3, 2018 [Page 9]
