<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ 
	<!ENTITY IEEE.802.15.6_2012 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml6/reference.IEEE.802.15.6_2012.xml">
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
 <?rfc toc="yes" ?>
 <?rfc symrefs="yes" ?>
 <?rfc sortrefs="yes"?> 
 <?rfc compact="yes" ?>
 <?rfc subcompact="no" ?>  
 <?rfc iprnotified="no" ?>
  <?rfc strict="no" ?>

<rfc category="info" docName="draft-moskowitz-small-crypto-00" ipr="trust200902">
 <front>
<title abbrev="Small Crypto">Small Crypto for Small IOT</title>
        <author fullname="Robert Moskowitz" initials="R." surname="Moskowitz" >
        <organization>Huawei</organization>
        <address>
        <postal> 
          <street> </street>
          <city>Oak Park</city>
          <region>MI</region>
          <code>48237</code> 
        </postal>
        <email>rgm@labs.htt-consult.com</email>
        </address>
        </author>
    <author fullname="Liang Xia" initials="L." surname="Xia">
        <organization>Huawei</organization>
        <address>
        <postal>
        <street>No. 101, Software Avenue, Yuhuatai District</street>
        <city>Nanjing</city>
        <country>China</country>
        </postal>
        <email>Frank.xialiang@huawei.com</email>
        </address>
    </author>
<date year="2017"/>
   <area>Security Area</area>
   <workgroup>CURDLE</workgroup>
    <keyword>RFC</keyword>
     <keyword>Request for Comments</keyword>
     <keyword>I-D</keyword>
     <keyword>Internet-Draft</keyword>
     <keyword>Keccak</keyword>
     <keyword>EDDSA</keyword>
     <keyword>IOT</keyword>

<abstract>
<t>
	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.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
	The <xref target="Keccak">Keccak</xref> algorithm at a width of 
	b=1600 was selected by NIST for SHA-3 as defined in <xref 
	target="NIST.FIPS.202">FIPS 202</xref>.  It is further used to 
	define additional hashing functions in <xref 
	target="NIST.SP.800_185">NIST SP 800-185</xref>, 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 not well suited for small 
	messages and 8 bit processors that are common in IOT.
</t>
<t>
	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.
</t>
<t>
	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.
</t>
<t>
	Finally, Keccak also provides an AEAD cipher, Ketje, to thus 
	deliver in a single base function, the full suite of symmetric 
	cryptographic functions.
</t>
<section title="Document status">
<t>
	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.
</t>
</section> 
</section>
<section anchor="terms" title="Terms and Definitions">
<section title="Requirements Terminology">
<t>
                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 <xref target="RFC2119">RFC 2119</xref>.
</t>
</section>
<section title="Notations">
 <t> This section will contain notations </t> 
</section> 
<section title="Definitions">
        <t>
                TBD
        </t>
</section> 
</section> 
<section anchor="BasicKeccak" title="Keccak Basics">
<t>
	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.
</t>
<t>
	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. 
</t>
<section anchor="KeccakParameters" title="Keccak Parameters">
<t>
	The Keccak primitive is:
<figure> <artwork><![CDATA[
    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.
]]></artwork> </figure>
</t>
<t>
	Instances are denoted
<figure> <artwork><![CDATA[
    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
]]></artwork> </figure>
</t>
</section> 
</section> 
<section anchor="KeccakSmall" title="Keccak[144,256]">
<t>
	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.
</t>
<t>
	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.
</t>
<t>
	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.
</t>
</section> 
<section anchor="KetjeSr" title="The Ketje authenticated encryption scheme">
<t>
	<xref target="Ketje">Ketje Sr</xref> is already defined to 
	use b=400.
</t>
</section> 
<section anchor="Ed25519Small" title="Using SHAKE128i in Ed25519">
<t>
	Ed25519, <xref target="RFC8032">RFC 8032</xref>, 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.
</t>
<t>
	The use of SHAKE128i is the only variant between Ed25519 and Ed25519i.
</t>
</section> 
<section anchor="IANA" title="IANA Considerations">
<t>
        TBD.  OID assignments
</t>
</section>
<section title="Security Considerations">
<section anchor="FutureProof" title="Defense against future attacks">
<t>
	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 
	<xref target="NotesPandU">"Note on Keccak parameters and 
	usage"</xref>, Section 6.
</t>
</section>
<section anchor="SecComp" title="Security Comparisons">
<t>
	This memo proposes a radical change in the basic cryto-primatives 
	used in protocols.  As such, care is called for.
</t>
<t>
	Keccak is not new.  It has been well reviewed as explained in <xref 
	target="notARX">"Why Keccak is not ARX"</xref>.  Still, it is 
	important to compare each Keccak function proposed here against the 
	current Best Practice.
</t>
<section anchor="SecSHAKE128i" title="SHAKE128i to SHA-256">
<t>
        TBD.
</t>
</section>
<section anchor="SecKMAC128i" title="KMAC128i to HMAC(SHA-256)">
<t>
        TBD.
</t>
</section>
<section anchor="SecKetjeSr" title="Ketje Sr to AES-CCM">
<t>
        TBD.
</t>
</section>
<section anchor="SecEd25519i" title="Ed25519i to Ed25519">
<t>
        TBD.
</t>
</section>
</section>
</section>
<section title="Acknowledgments">
<t>
	Sections here draw heavily on information available on the <xref 
	target="Keccak">Keccak</xref> site.  I thank the Keccak Team in 
	making this information openly available.
</t>
</section>
</middle>
<back>
<references title="Normative References">
        <?rfc include="reference.RFC.2119.xml"?>
        <?rfc include="reference.RFC.8032.xml"?>
<reference anchor="NIST.FIPS.202" target="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf">
	<front>
	<title>SHA-3 Standard:  Permutation-Based Hash and Extendable-Output Functions</title>
	<author initials="M." surname="Dworkin" fullname="Morris J. Dworkin">
	<organization>National Institute of Standards and Technology</organization>
	</author>
	<date month="August" year="2015"/>
	</front>
	<seriesInfo name="FIPS" value="PUB 202"/>
	<seriesInfo name="DOI" value="10.6028/nist.fips.202"/>
</reference>
<reference anchor="NIST.SP.800_185" target="http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-185.pdf">
	<front>
	<title>SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and ParallelHash</title>
	<author initials="J." surname="Kelsey" fullname="John Kelsey">
	<organization>National Institute of Standards and Technology</organization>
	</author>
	<author initials="S." surname="Change" fullname="Shu-jen Change">
	<organization>National Institute of Standards and Technology</organization>
	</author>
	<author initials="R." surname="Perlner" fullname="Ray Perlner">
	<organization>National Institute of Standards and Technology</organization>
	</author>
	<date month="December" year="2016"/>
	</front>
	<seriesInfo name="Special Publication" value="SP 800-185"/>
	<seriesInfo name="DOI" value="10.6028/nist.sp.800-185"/>
</reference>
</references>
<references title="Informative References">
        <?rfc include="reference.RFC.8163.xml"?>
        &IEEE.802.15.6_2012;
<reference anchor="NotesPandU" target="https://keccak.team/files/NoteOnKeccakParametersAndUsage.pdf">
  <front>
    <title>Note on Keccak parameters and usage</title>
<author fullname="Guido Bertoni" initials="G." surname="Bertoni"> 
	<address/> 
</author> 
<author fullname="Joan Daemen" initials="J." surname="Daemen"> 
	<organization>Radboud University</organization>
	<address/> 
</author> 
<author fullname="Michaël Peeters" initials="M." surname="Peeters"> 
	<organization>STMicroelectronics</organization>
	<address/> 
</author> 
<author fullname="Gilles Van Assche" initials="G." surname="Van Assche"> 
	<organization>STMicroelectronics</organization>
	<address/> 
</author> 
<date month="February" year="2010"/>
</front>
</reference>
<reference anchor="Keccak" target="https://keccak.team/index.html">
  <front>
    <title>Team Keccak Home Page</title>
<author fullname="Guido Bertoni" initials="G." surname="Bertoni"> 
	<address/> 
</author> 
<author fullname="Joan Daemen" initials="J." surname="Daemen"> 
	<organization>Radboud University</organization>
	<address/> 
</author> 
<author fullname="Michaël Peeters" initials="M." surname="Peeters"> 
	<organization>STMicroelectronics</organization>
	<address/> 
</author> 
<author fullname="Gilles Van Assche" initials="G." surname="Van Assche"> 
	<organization>STMicroelectronics</organization>
	<address/> 
</author> 
<author fullname="Ronny Van Keer" initials="R." surname="Van Keer"> 
	<organization>STMicroelectronics</organization>
	<address/> 
</author> 
<date/>
</front>
</reference>
<reference anchor="notARX" target="https://keccak.team/2017/not_arx.html">
  <front>
    <title>Why Keccak is not ARX</title>
<author/> 
<date/>
</front>
</reference>
<reference anchor="Ketje" target="https://keccak.team/ketje.html">
  <front>
    <title>The Ketje authenticated encryption scheme</title>
<author fullname="Guido Bertoni" initials="G." surname="Bertoni"> 
	<address/> 
</author> 
<author fullname="Joan Daemen" initials="J." surname="Daemen"> 
	<organization>Radboud University</organization>
	<address/> 
</author> 
<author fullname="Michaël Peeters" initials="M." surname="Peeters"> 
	<organization>STMicroelectronics</organization>
	<address/> 
</author> 
<author fullname="Gilles Van Assche" initials="G." surname="Van Assche"> 
	<organization>STMicroelectronics</organization>
	<address/> 
</author> 
<author fullname="Ronny Van Keer" initials="R." surname="Van Keer"> 
	<organization>STMicroelectronics</organization>
	<address/> 
</author> 
<date/>
</front>
</reference>
</references>   
<section anchor="Uses" title="Use Cases">
<t>
	TBD.
</t>
<section anchor="BAN" title="Pacemaker connected via Body Area Network">
<t>
	In-body sensors, like pacemakers, connected via the Body Area 
	Network (<xref target="IEEE.802.15.6_2012">BAN</xref>) 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.
</t>
</section>
<section anchor="CAN_FD" title="Automotive CAN FD Sensors">
<t>
	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.
</t>
</section>
<section anchor="BACnet" title="Building Automation and Control Network Sensors">
<t>
	BACnet (ISO 16484-5) is the standard for wired, in-building control 
	systems.   Recently IPv6 support (<xref target="RFC8163">RFC 
	8163</xref>) 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.
</t>
</section>
</section>
<section anchor="Performance" title="Performance Comparisons">
<t>
	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.
</t>
<t>
	Performance improvements can come for lower CPU/power demands, 
	smaller code size, and/or smaller storage/memory requirements.
</t>
<section anchor="PerfSHAKE128i" title="SHAKE128i to SHA-256">
<t>
        TBD.  Magnitude faster?
</t>
</section>
<section anchor="PerfKMAC128i" title="KMAC128i to HMAC(SHA-256)">
<t>
        TBD.
</t>
</section>
<section anchor="PerfKetjeSr" title="Ketje Sr to AES-CCM">
<t>
        TBD.
</t>
</section>
<section anchor="PerfEd25519i" title="Ed25519i to Ed25519">
<t>
        TBD.
</t>
</section>
<section anchor="PerfHardware" title="Keccak Hardware to AES Hardware">
<t>
        TBD.
</t>
</section>
</section>
</back>
</rfc>
