<?xmlversion="1.0"?>version="1.0" encoding="UTF-8"?> <!DOCTYPE rfc SYSTEM"rfc2629.dtd" [ <!ENTITY RFC4086 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml'> <!ENTITY RFC4634 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4634.xml'> <!ENTITY BLAKE2 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7693.xml'> ]> <?rfc compact="no"?> <?rfc toc="yes"?> <?rfc symrefs="yes"?>"rfc2629-xhtml.ent"> <rfccategory="info"xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"docName="draft-irtf-cfrg-argon2-13">docName="draft-irtf-cfrg-argon2-13" number="9106" obsoletes="" updates="" submissionType="IRTF" category="info" consensus="true" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3"> <front> <title abbrev="Argon2">The memory-hardArgon2password hashMemory-Hard Function for Password Hashing andproof-of-work functionProof-of-Work Applications </title> <seriesInfo name="RFC" value="9106"/> <author initials="A." surname="Biryukov" fullname="Alex Biryukov"> <organization>University of Luxembourg</organization> <address> <email>alex.biryukov@uni.lu</email> </address> </author> <author initials="D." surname="Dinu" fullname="Daniel Dinu"> <organization>University of Luxembourg</organization> <address> <email>daniel.dinu@intel.com</email> </address> </author> <author initials="D." surname="Khovratovich" fullname="Dmitry Khovratovich"> <organization>ABDK Consulting</organization> <address> <email>khovratovich@gmail.com</email> </address> </author> <author initials="S." surname="Josefsson" fullname="Simon Josefsson"> <organization>SJD AB</organization> <address> <email>simon@josefsson.org</email> <uri>http://josefsson.org/</uri> </address> </author> <dateday="11" month="March"month="September" year="2021"/><workgroup>CFRG</workgroup><workgroup>Crypto Forum</workgroup> <keyword>Argon2d</keyword> <keyword>Argon2i</keyword> <keyword>Argon2id</keyword> <keyword>KDF</keyword> <keyword>Cryptocurrency</keyword> <keyword>Time-Space Trade-Off Attacks</keyword> <keyword>Security</keyword> <abstract> <t>This document describes the Argon2 memory-hard function for password hashing and proof-of-work applications. We provide an implementer-oriented description with test vectors. The purpose is to simplify adoption of Argon2 for Internet protocols. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</t> </abstract> </front> <middle> <section anchor="intro"title="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>This document describes the <xreftarget="ARGON2ESP">Argon2</xref>target="ARGON2ESP" format="default">Argon2</xref> memory-hard function for password hashing and proof-of-work applications. We provide animplementer orientedimplementer-oriented description with test vectors. The purpose is to simplify adoption of Argon2 for Internet protocols. This document corresponds to version 1.3 of the Argon2 hash function.</t> <t>Argon2 is atraditional<xreftarget="HARD">memory-hardtarget="HARD" format="default">memory-hard function</xref>. It is a streamlined design. It aims at the highestmemory fillingmemory-filling rate and effective use of multiple computing units, while still providing defense againsttradeofftrade-off attacks. Argon2 is optimized for the x86 architecture and exploits the cache and memory organization of the recent Intel and AMD processors. Argon2 has one primaryvariant: Argon2idvariant, Argon2id, and two supplementaryvariants:variants, Argon2d and Argon2i. Argon2d uses data-dependent memory access, which makes it suitable for cryptocurrencies and proof-of-work applications with no threats from side-channel timing attacks. Argon2i uses data-independent memory access, which is preferred for password hashing and password-based key derivation. Argon2id works as Argon2i for the first half of the first pass over thememory,memory and as Argon2d for the rest, thus providing both side-channel attack protection and brute-force cost savings due to time-memorytradeoffs.trade-offs. Argon2i makes more passes over the memory to protect from <xreftarget="AB15">tradeofftarget="AB15" format="default">trade-off attacks</xref>.</t><t> Argon2id MUST<t>Argon2id <bcp14>MUST</bcp14> be supported by any implementation of this document, whereas Argon2d and Argon2iMAY<bcp14>MAY</bcp14> be supported. </t> <t> Argon2 is also a mode of operation over a fixed-input-length compression function G and a variable-input-length hash function H. Even though Argon2 can be potentially used with an arbitrary function H, as long as it provides outputs up to 64 bytes, the <xref target="RFC7693" format="default">BLAKE2b function</xref> is used in thisdocument it is <xref target="BLAKE2">BLAKE2b</xref>.</t>document.</t> <t>For further background and discussion, see the <xreftarget="ARGON2">Argon2target="ARGON2" format="default">Argon2 paper</xref>.</t><t>The<t> This document represents the consensus of the Crypto Forum Research Group (CFRG).</t> <section anchor="reqs"> <name>Requirements Language</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xreftarget="RFC2119">RFC 2119</xref>.</t> <t> This document represents the consensus of the Crypto Forum Research Group (CFRG).</t>target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> </section> </section> <sectiontitle="Notation and Conventions"> <t>x^y --- integernumbered="true" toc="default"> <name>Notation and Conventions</name> <dl indent="15"> <dt>x^y</dt><dd>integer x multiplied by itself integer ytimes</t> <t>a*b --- multiplicationtimes</dd> <dt>a*b</dt><dd>multiplication of integer a and integerb</t> <t>c-d --- subtractionb</dd> <dt>c-d</dt><dd>subtraction of integer d from integerc</t> <t>E_f --- variablec</dd> <dt>E_f</dt><dd>variable E with subscript indexf</t> <t>gf</dd> <dt>g /h --- integerh</dt><dd>integer g divided by integer h. The result is a rationalnumber</t> <t>I(j) --- functionnumber.</dd> <dt>I(j)</dt><dd>function I evaluated atj</t> <t>Kj</dd> <dt>K ||L --- stringL</dt><dd>string K concatenated with stringL</t> <t>aL</dd> <dt>a XORb --- bitwiseb</dt><dd>bitwise exclusive-or between bitstrings a andb</t> <t>ab</dd> <dt>a modb --- remainderb</dt><dd>remainder of integer a modulo integer b, always in range [0,b-1]</t> <t>a >>> n --- rotationb-1]</dd> <dt>a >>> n</dt><dd>rotation of 64-bit string a to the right by nbits</t> <t>trunc(a) --- thebits</dd> <dt>trunc(a)</dt><dd>the 64-bit value, truncated to the 32 least significantbits</t> <t>floor(a) --- thebits</dd> <dt>floor(a)</dt><dd>the largest integer not bigger thana</t> <t>ceil(a) --- thea</dd> <dt>ceil(a)</dt><dd>the smallest integer not smaller thana</t> <t>extract(a, i) --- thea</dd> <dt>extract(a, i)</dt><dd>the i-th set of32-bits32 bits from bitstring a, starting from0-th</t> <t>|A| --- the0-th</dd> <dt>|A|</dt><dd>the number of elements in setA</t> <t>LE32(a) --- 32-bitA</dd> <dt>LE32(a)</dt><dd>32-bit integer a converted to abytestringbyte string in littleendian. Example:endian (for example, 123456 (decimal) is 40 E2 0100.</t> <t>LE64(a) --- 64-bit00)</dd> <dt>LE64(a)</dt><dd>64-bit integer a converted to abytestringbyte string in littleendian. Example:endian (for example, 123456 (decimal) is 40 E2 01 00 00 00 0000.</t> <t>int32(s) --- 32-bit00)</dd> <dt>int32(s)</dt><dd>32-bit string s is converted to a non-negative integer in littleendian.</t> <t>int64(s) --- 64-bitendian</dd> <dt>int64(s)</dt><dd>64-bit string s is converted to a non-negative integer in littleendian.</t> <t>length(P) --- the bytelengthendian</dd> <dt>length(P)</dt><dd>the byte length of string P expressed as 32-bitinteger</t> <t>ZERO(P) --- theinteger</dd> <dt>ZERO(P)</dt><dd>the P-byte zerostring</t>string</dd> </dl> </section> <section anchor="argon2-algorithm"title="Argon2 Algorithm">numbered="true" toc="default"> <name>Argon2 Algorithm</name> <section anchor="argon2-inouts"title="Argon2numbered="true" toc="default"> <name>Argon2 Inputs andOutputs">Outputs</name> <t>Argon2 has the following input parameters:<list style="symbols"> <t>Message</t> <ul spacing="normal"> <li>Message string P, which is a password for password hashing applications.MUSTIt <bcp14>MUST</bcp14> have a length not greater than2^(32) - 1 bytes.</t> <t>Nonce2^(32)-1 bytes.</li> <li>Nonce S, which is a salt for password hashing applications.MUSTIt <bcp14>MUST</bcp14> have a length not greater than 2^(32)-1 bytes. 16 bytes isRECOMMENDED<bcp14>RECOMMENDED</bcp14> for password hashing.Salt SHOULDThe salt <bcp14>SHOULD</bcp14> be unique for eachpassword.</t> <t>Degreepassword.</li> <li>Degree of parallelism p determines how many independent (but synchronizing) computational chains (lanes) can be run. ItMUST<bcp14>MUST</bcp14> be an integer value from 1 to2^(24)-1.</t> <t>Tag2^(24)-1.</li> <li>Tag length TMUST<bcp14>MUST</bcp14> be an integer number of bytes from 4 to2^(32)-1.</t> <t>Memory2^(32)-1.</li> <li>Memory size mMUST<bcp14>MUST</bcp14> be an integer number of kibibytes from 8*p to 2^(32)-1. The actual number of blocks is m', which is m rounded down to the nearest multiple of4*p.</t> <t>Number4*p.</li> <li>Number of passes t (used to tune the running time independently of the memory size)MUST<bcp14>MUST</bcp14> be an integer number from 1 to2^(32)-1.</t> <t>Version2^(32)-1.</li> <li>Version number vMUST<bcp14>MUST</bcp14> be one byte0x13.</t> <t>Secret0x13.</li> <li>Secret value K isOPTIONAL.<bcp14>OPTIONAL</bcp14>. If used, itMUST<bcp14>MUST</bcp14> have a length not greater than 2^(32)-1bytes.</t> <t>Associatedbytes.</li> <li>Associated data X isOPTIONAL.<bcp14>OPTIONAL</bcp14>. If used, itMUST<bcp14>MUST</bcp14> have a length not greater than 2^(32)-1bytes.</t> <t>Typebytes.</li> <li>Type yof Argon2: MUST<bcp14>MUST</bcp14> be 0 for Argon2d, 1 for Argon2i, or 2 forArgon2id.</t> </list></t>Argon2id.</li> </ul> <t>The Argon2 output, or"tag""tag", is a string T bytes long.</t> </section> <section anchor="argon2-operation"title="Argon2 Operation">numbered="true" toc="default"> <name>Argon2 Operation</name> <t>Argon2 uses an internal compression function G with two 1024-byteinputs andinputs, a 1024-byte output, and an internal hash functionH^x()H^x(), with x being its output length in bytes.HereHere, H^x() applied to string A is the<xref target="BLAKE2">BLAKE2b (Section 3.3)</xref>BLAKE2b (<xref target="RFC7693" section="3.3" sectionFormat="comma"/>) function, which takes (d,ll,kk=0,nn=x) asparametersparameters, where d is A padded to a multiple of 128 bytes and ll is the length of d in bytes. The compression function G is based on its internal permutation. A variable-length hash function H' built upon H is also used. G is described in <xreftarget="G-function"></xref>target="G-function" format="default"/>, and H' is described in <xreftarget="H-function"></xref>.</t>target="H-function" format="default"/>.</t> <t>The Argon2 operation is as follows.<list style="numbers"></t> <ol spacing="normal" type="1"><li> <t>Establish H_0 as the 64-byte value as shown below. If K, X, or S has zerolengthlength, it is justabsentabsent, but its length field remains.<figure title="H_0 generation"> <artwork></t> <figure> <name>H_0 Generation</name> <artwork name="" type="" align="left" alt=""><![CDATA[ H_0 = H^(64)(LE32(p) || LE32(T) || LE32(m) || LE32(t) || LE32(v) || LE32(y) || LE32(length(P)) || P || LE32(length(S)) || S || LE32(length(K)) || K || LE32(length(X)) || X)</artwork> </figure></t>]]></artwork> </figure> </li> <li> <t>Allocate the memory as m' 1024-byteblocksblocks, where m' is derived as:<figure title="Memory allocation"> <artwork></t> <figure> <name>Memory Allocation</name> <artwork name="" type="" align="left" alt=""><![CDATA[ m' = 4 * p * floor (m / 4p)</artwork>]]></artwork> </figure> <t> For p lanes, the memory is organized in a matrix B[i][j] of blocks with p rows (lanes) and q = m' / p columns.</t> </li> <li> <t>Compute B[i][0] for all i ranging from (and including) 0 to (not including) p.<figure title="Lane starting blocks"> <artwork></t> <figure> <name>Lane Starting Blocks</name> <artwork name="" type="" align="left" alt=""><![CDATA[ B[i][0] = H'^(1024)(H_0 || LE32(0) || LE32(i))</artwork>]]></artwork> </figure></t></li> <li> <t>Compute B[i][1] for all i ranging from (and including) 0 to (not including) p.<figure title ="Second lane blocks"> <artwork></t> <figure> <name>Second Lane Blocks</name> <artwork name="" type="" align="left" alt=""><![CDATA[ B[i][1] = H'^(1024)(H_0 || LE32(1) || LE32(i))</artwork>]]></artwork> </figure></t> <t>Compute</li> <li> <t anchor="step5">Compute B[i][j] for all i ranging from (and including) 0 to (not including)p,p and for all j ranging from (and including)2)2 to (not including) q. The computationMUST<bcp14>MUST</bcp14> proceed slicewise (<xreftarget="indexing"></xref>): firsttarget="indexing" format="default"/>): first, blocks from slice 0 are computed for all lanes (in an arbitrary order of lanes), then blocks from slice 1 arecomputedcomputed, etc. The block indices l and z are determined for each i, j differently for Argon2d, Argon2i, and Argon2id.<figure title="Further block generation"> <artwork></t> <figure> <name>Further Block Generation</name> <artwork name="" type="" align="left" alt=""><![CDATA[ B[i][j] = G(B[i][j-1], B[l][z])</artwork> </figure></t>]]></artwork> </figure> </li> <li> <t>If the number of passes t is larger than 1, we repeatthe steps. However<xref target="step5" format="none">step 5</xref>. We compute B[i][0] and B[i][j] for all i raging from (and including) 0 to (not including) p and for all j ranging from (and including) 1 to (not including) q. However, blocks are computed differently as the old value is XORed with the new one:<figure title="Further passes"> <artwork></t> <figure> <name>Further Passes</name> <artwork name="" type="" align="left" alt=""><![CDATA[ B[i][0] = G(B[i][q-1], B[l][z]) XOR B[i][0]; B[i][j] = G(B[i][j-1], B[l][z]) XOR B[i][j].</artwork> </figure></t>]]></artwork> </figure> </li> <li> <t>After t steps have been iterated, the final block C is computed as the XOR of the last column:<figure title="Final block"> <artwork></t> <figure> <name>Final Block</name> <artwork name="" type="" align="left" alt=""><![CDATA[ C = B[0][q-1] XOR B[1][q-1] XOR ... XOR B[p-1][q-1]</artwork> </figure></t> <t>The]]></artwork> </figure> </li> <li>The output tag is computed asH'^T(C).</t> </list></t>H'^T(C).</li> </ol> </section> <section anchor="H-function"title="Variable-length hash function H'">numbered="true" toc="default"> <name>Variable-Length Hash Function H'</name> <t>Let V_i be a 64-byteblock,block and W_i be its first 32 bytes. Then wedefine: <figure title="Functiondefine function H' as follows: </t> <figure> <name>Function H' fortagTag andinitial block computations"> <artwork>Initial Block Computations</name> <sourcecode type="pseudocode"> if T <= 64 H'^T(A) = H^T(LE32(T)||A) else r = ceil(T/32)-2 V_1 = H^(64)(LE32(T)||A) V_2 = H^(64)(V_1) ... V_r = H^(64)(V_{r-1}) V_{r+1} = H^(T-32*r)(V_{r}) H'^T(X) = W_1 || W_2 || ... || W_r || V_{r+1}</artwork></sourcecode> </figure></t></section> <section anchor="indexing"title="Indexing">numbered="true" toc="default"> <name>Indexing</name> <t>To enable parallel block computation, we further partition the memory matrix into SL = 4 vertical slices. The intersection of a slice and a lane is called a segment, which has a length of q/SL. Segments of the same slice can be computed in parallel and do not reference blocks from each other. All other blocks can be referenced.</t><figure title="Single-pass<figure> <name>Single-Pass Argon2 with planesLanes and 4slices"> <artwork>Slices</name> <artwork name="" type="" align="left" alt=""><![CDATA[ slice 0 slice 1 slice 2 slice 3 ___/\___ ___/\___ ___/\___ ___/\___ / \ / \ / \ / \ +----------+----------+----------+----------+ | | | | | > lane 0 +----------+----------+----------+----------+ | | | | | > lane 1 +----------+----------+----------+----------+ | | | | | > lane 2 +----------+----------+----------+----------+ | ... ... ... | ... +----------+----------+----------+----------+ | | | | | > lane p - 1 +----------+----------+----------+----------+</artwork>]]></artwork> </figure> <sectiontitle="Computingnumbered="true" toc="default"> <name>Computing the32-bit values32-Bit Values J_1 andJ_2">J_2</name> <sectiontitle="Argon2d">numbered="true" toc="default"> <name>Argon2d</name> <t>J_1 is given by the first 32 bits of block B[i][j-1], while J_2 is given by the next32-bits32 bits of block B[i][j-1]:<figure title ="Deriving</t> <figure> <name>Deriving J1,J2 inArgon2d"> <artwork>Argon2d</name> <artwork name="" type="" align="left" alt=""><![CDATA[ J_1 = int32(extract(B[i][j-1], 0)) J_2 = int32(extract(B[i][j-1], 1))</artwork> </figure></t>]]></artwork> </figure> </section> <sectiontitle="Argon2i">numbered="true" toc="default"> <name>Argon2i</name> <t>For eachsegmentsegment, we do the following.FirstFirst, we compute the value Zas <figure title="Inputas: </t> <figure> <name>Input tocomputeCompute J1,J2 inArgon2i"> <artwork>Argon2i</name> <artwork name="" type="" align="left" alt=""><![CDATA[ Z= ( LE64(r) || LE64(l) || LE64(sl) || LE64(m') || LE64(t) || LE64(y)), where r -- the) ]]></artwork> </figure> <t>where</t> <dl indent="5" spacing="compact"> <dt>r:</dt><dd>the passnumber l -- thenumber</dd> <dt>l:</dt><dd>the lanenumber sl -- thenumber</dd> <dt>sl:</dt><dd>the slicenumber m' -- thenumber</dd> <dt>m':</dt><dd>the total number of memoryblocks t -- theblocks</dd> <dt>t:</dt><dd>the total number ofpasses y -- thepasses</dd> <dt>y:</dt><dd>the Argon2 type (0 for Argon2d, 1 for Argon2i, 2 forArgon2id) </artwork> </figure>Argon2id)</dd> </dl> <t> Then wecomputecompute:</t> <artwork name="" type="" align="left" alt=""><![CDATA[ q/(128*SL) 1024-byte values G(ZERO(1024),G(ZERO(1024), Z || LE64(1) || ZERO(968) )), G(ZERO(1024),G(ZERO(1024), Z || LE64(2) || ZERO(968) )),... , G(ZERO(1024),G(ZERO(1024), Z || LE64(q/(128*SL)) || ZERO(968) )), ]]></artwork><t> which are partitioned into q/(SL) 8-byte values X, which are viewed as X1||X2 and converted to J_1=int32(X1) andJ_2=int32(X2).J_2=int32(X2).</t> <t> The values r, l, sl, m', t, y, and i are represented as 8 bytes inlittle-endian.</t>little endian.</t> </section> <sectiontitle="Argon2id">numbered="true" toc="default"> <name>Argon2id</name> <t>If the pass number is 0 and the slice number is 0 or 1, then compute J_1 and J_2 as for Argon2i, else compute J_1 and J_2 as for Argon2d.</t> </section> </section> <sectiontitle="Mappingnumbered="true" toc="default"> <name>Mapping J_1 and J_2 toreference block index [l][z]">Reference Block Index [l][z]</name> <t>The value of l = J_2 mod p gives the index of the lane from which the block will be taken. For the first pass (r=0) and the first slice(sl=0)(sl=0), the block is taken from the current lane.</t> <t>The set W contains the indices that are referenced according to the following rules:<list style="numbers"> <t>If</t> <ol spacing="normal" type="1"><li>If l is the current lane, then W includes the indices of all blocks in the last SL - 1 = 3 segments computed and finished, as well as the blocks computed in the current segment in the current pass excludingB[i][j-1].</t> <t>IfB[i][j-1].</li> <li>If l is not the current lane, then W includes the indices of all blocks in the last SL - 1 = 3 segments computed and finished in lane l. If B[i][j] is the first block of a segment, then the very last index from W isexcluded.</t> </list> </t>excluded.</li> </ol> <t>Then take a block from W with anon-uniformnonuniform distribution over [0, |W|) using themapping <figure title="Computing J1"> <artwork>following mapping: </t> <figure> <name>Computing J1</name> <artwork name="" type="" align="left" alt=""><![CDATA[ J_1 -> |W|(1 - J_1^2 / 2^(64))</artwork> </figure></t>]]></artwork> </figure> <t>To avoid floating point computation, the following approximation is used:<figure title="Computing</t> <figure> <name>Computing J1,part 2"> <artwork>Part 2</name> <artwork name="" type="" align="left" alt=""><![CDATA[ x = J_1^2 / 2^(32) y = (|W| * x) / 2^(32) zz = |W| - 1 - y</artwork> </figure></t>]]></artwork> </figure> <t>Then take the zz-th index fromW,W; it will be the z value for the reference block index [l][z].</t> </section> </section> <section anchor="G-function"title="Compression function G">numbered="true" toc="default"> <name>Compression Function G</name> <t>The compression function G is built upon the BLAKE2b-based transformation P. P operates on the 128-byte input, which can be viewed as8eight 16-byte registers:<figure title="Blake round function P"> <artwork></t> <figure> <name>Blake Round Function P</name> <artwork name="" type="" align="left" alt=""><![CDATA[ P(A_0, A_1, ... ,A_7) = (B_0, B_1, ... ,B_7)</artwork> </figure></t>]]></artwork> </figure> <t>The compression function G(X, Y) operates on two 1024-byte blocks X and Y. It first computes R = X XOR Y. Then R is viewed asaan 8x8 matrix of 16-byte registers R_0, R_1, ... , R_63. Then P is first applied to each row, and then to each column to get Z:<figure title="Core</t> <figure> <name>Core ofcompression function G"> <artwork>Compression Function G</name> <artwork name="" type="" align="left" alt=""><![CDATA[ ( Q_0, Q_1, Q_2, ... , Q_7)<-<- P( R_0, R_1, R_2, ... , R_7) ( Q_8, Q_9, Q_10, ... , Q_15)<-<- P( R_8, R_9, R_10, ... , R_15) ... (Q_56, Q_57, Q_58, ... , Q_63)<-<- P(R_56, R_57, R_58, ... , R_63) ( Z_0, Z_8, Z_16, ... , Z_56)<-<- P( Q_0, Q_8, Q_16, ... , Q_56) ( Z_1, Z_9, Z_17, ... , Z_57)<-<- P( Q_1, Q_9, Q_17, ... , Q_57) ... ( Z_7, Z_15, Z 23, ... , Z_63)<-<- P( Q_7, Q_15, Q_23, ... , Q_63)</artwork> </figure></t>]]></artwork> </figure> <t>Finally, G outputs Z XOR R:<figure> <artwork></t> <artwork name="" type="" align="left" alt=""><![CDATA[ G: (X, Y) -> R -> Q -> Z -> Z XOR R</artwork> </figure> <figure title="Argon2 compression function G."> <artwork>]]></artwork> <figure> <name>Argon2 Compression Function G</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +---+ +---+ | X | | Y | +---+ +---+ | |---->XOR<-------->XOR<---- --------| | \ / | +---+ | | R | | +---+ | | | \ / | P rowwise | | | \ / | +---+ | | Q | | +---+ | | | \ / | P columnwise | | | \ / | +---+ | | Z | | +---+ | | | \ / ------>XOR | \ /</artwork> </figure></t>]]></artwork> </figure> </section> <section anchor="P-permutation"title="Permutation P">numbered="true" toc="default"> <name>Permutation P</name> <t>Permutation P is based on the round function of BLAKE2b. The8eight 16-byte inputs S_0, S_1, ... , S_7 are viewed as a 4x4 matrix of 64-bit words, where S_i = (v_{2*i+1} || v_{2*i}):<figure title="Matrix element labeling"> <artwork></t> <figure> <name>Matrix Element Labeling</name> <artwork name="" type="" align="left" alt=""><![CDATA[ v_0 v_1 v_2 v_3 v_4 v_5 v_6 v_7 v_8 v_9 v_10 v_11 v_12 v_13 v_14 v_15</artwork>]]></artwork> </figure> <t> It works as follows:<figure title="Feeding matrix elements to GB"> <artwork></t> <figure> <name>Feeding Matrix Elements to GB</name> <artwork name="" type="" align="left" alt=""><![CDATA[ GB(v_0, v_4, v_8, v_12) GB(v_1, v_5, v_9, v_13) GB(v_2, v_6, v_10, v_14) GB(v_3, v_7, v_11, v_15) GB(v_0, v_5, v_10, v_15) GB(v_1, v_6, v_11, v_12) GB(v_2, v_7, v_8, v_13) GB(v_3, v_4, v_9, v_14)</artwork>]]></artwork> </figure> <t> GB(a, b, c, d) is defined as follows:<figure title="Details</t> <figure> <name>Details ofGB"> <artwork>GB</name> <artwork name="" type="" align="left" alt=""><![CDATA[ a = (a + b + 2 * trunc(a) * trunc(b)) mod 2^(64) d = (d XOR a) >>> 32 c = (c + d + 2 * trunc(c) * trunc(d)) mod 2^(64) b = (b XOR c) >>> 24 a = (a + b + 2 * trunc(a) * trunc(b)) mod 2^(64) d = (d XOR a) >>> 16 c = (c + d + 2 * trunc(c) * trunc(d)) mod 2^(64) b = (b XOR c) >>> 63</artwork>]]></artwork> </figure> <t> The modular additions in GB are combined with 64-bit multiplications. Multiplications are the only differencetofrom the original BLAKE2b design. This choice is done to increase the circuit depth and thus the running time of ASIC implementations, while having roughly the same running time on CPUs thanks to parallelism and pipelining. </t> </section> </section> <section anchor="parameter-choice"title="Parameter Choice">numbered="true" toc="default"> <name>Parameter Choice</name> <t>Argon2d is optimized for settings where the adversary does not get regular access to system memory or CPU,i.e. he can noti.e., they cannot run side-channel attacks based on the timing information, norhecan they recover the password much faster using garbage collection. These settings are more typical for backend servers and cryptocurrency minings. Forpracticepractice, we suggest the following settings:<list style="symbols"> <t>Cryptocurrency</t> <ul spacing="normal"> <li>Cryptocurrency mining,thatwhich takes 0.1 seconds on a 2GhzGHz CPU using 1 core—-- Argon2d with 2 lanes and 250 MB ofRAM.</t> </list></t>RAM.</li> </ul> <t>Argon2id is optimized for more realistic settings, where the adversarypossiblycan possibly access the same machine, use itsCPUCPU, or mount cold-boot attacks. We suggest the following settings:<list style="symbols"> <t>Backend</t> <ul spacing="normal"> <li>Backend server authentication,thatwhich takes 0.5 seconds on a 2 GHz CPU using 4 cores—-- Argon2id with 8 lanes and 4 GiB ofRAM.</t> <t>KeyRAM.</li> <li>Key derivation for hard-drive encryption,thatwhich takes 3 seconds on a 2 GHz CPU using 2 cores--- Argon2id with 4 lanes and 6 GiB ofRAM.</t> <t>FrontendRAM.</li> <li>Frontend server authentication,thatwhich takes 0.5 seconds on a 2 GHz CPU using 2 cores--- Argon2id with 4 lanes and 1 GiB ofRAM.</t> </list></t>RAM.</li> </ul> <t>We recommend the following procedure to select the type and the parameters for practical use of Argon2.<list style="numbers"> <t></t> <ol spacing="normal" type="1"><li> Ifyou are OK witha uniformly safeoption, butoption that is not tailored to your application orhardware,hardware is acceptable, select Argon2id with t=1 iteration, p=4lanes andlanes, m=2^(21) (2 GiB of RAM), 128-bit salt, and 256-bit tag size. This is the FIRSTRECOMMENDED option.</t> <t><bcp14>RECOMMENDED</bcp14> option.</li> <li> If much less memory is available, a uniformly safe option is Argon2id with t=3 iterations, p=4lanes andlanes, m=2^(16) (64 MiB of RAM), 128-bit salt, and 256-bit tag size. This is the SECONDRECOMMENDED option.</t> <t>Otherwise,<bcp14>RECOMMENDED</bcp14> option.</li> <li>Otherwise, start with selecting the type y. If you do not know the difference betweenthemthe types or you consider side-channel attacksasto be a viable threat, chooseArgon2id.</t> <t>SelectArgon2id.</li> <li>Select p=4lanes.</t> <t>Figurelanes.</li> <li>Figure out the maximum amount of memory that each call can afford and translate it to the parameterm.</t> <t>Figurem.</li> <li>Figure out the maximum amount of time (in seconds) that each call canafford.</t> <t>Selectafford.</li> <li>Select the salt length. A length of 128 bits is sufficient for allapplications,applications but can be reduced to 64 bits in the case of spaceconstraints.</t> <t>Selectconstraints.</li> <li>Select the tag length. A length of 128 bits is sufficient for most applications, including key derivation. If longer keys are needed, select longertags.</t> <t>Iftags.</li> <li>If side-channel attacks are a viablethreat,threat or if you're uncertain, enable thememory wipingmemory-wiping option in the librarycall.</t> <t>Runcall.</li> <li>Run the scheme of type y, memorymm, and planes,lanes using a different number of passes t. Figure out the maximum t such that the running time does not exceed the affordable time. If itexceedseven exceeds for t = 1, reduce maccordingly.</t> <t>accordingly.</li> <li> Use Argon2 with determined values m, p, andt.</t> </list></t>t.</li> </ol> </section> <section anchor="test-vectors"title="Test Vectors">numbered="true" toc="default"> <name>Test Vectors</name> <t>This section contains test vectors for Argon2.</t> <section anchor="argon2d-test-vectors"title="Argon2dnumbered="true" toc="default"> <name>Argon2d TestVectors">Vectors</name> <t>We provide test vectors with complete outputs (tags). For the convenience of developers, we also provide some interimvariables,variables -- concretely, the first and last memory blocks of each pass.</t><figure> <artwork><sourcecode type="test-vectors"> ======================================= Argon2d version number 19 ======================================= Memory: 32 KiB Passes: 3 Parallelism: 4 lanes Tag length: 32 bytes Password[32]: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 Salt[16]: 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 Secret[8]: 03 03 03 03 03 03 03 03 Associated data[12]: 04 04 04 04 04 04 04 04 04 04 04 04 Pre-hashing digest: b8 81 97 91 a0 35 96 60 bb 77 09 c8 5f a4 8f 04 d5 d8 2c 05 c5 f2 15 cc db 88 54 91 71 7c f7 57 08 2c 28 b9 51 be 38 14 10 b5 fc 2e b7 27 40 33 b9 fd c7 ae 67 2b ca ac 5d 17 90 97 a4 af 31 09 After pass 0: Block 0000 [ 0]: db2fea6b2c6f5c8a Block 0000 [ 1]: 719413be00f82634 Block 0000 [ 2]: a1e3f6dd42aa25cc Block 0000 [ 3]: 3ea8efd4d55ac0d1 ... Block 0031 [124]: 28d17914aea9734c Block 0031 [125]: 6a4622176522e398 Block 0031 [126]: 951aa08aeecb2c05 Block 0031 [127]: 6a6c49d2cb75d5b6 After pass 1: Block 0000 [ 0]: d3801200410f8c0d Block 0000 [ 1]: 0bf9e8a6e442ba6d Block 0000 [ 2]: e2ca92fe9c541fcc Block 0000 [ 3]: 6269fe6db177a388 ... Block 0031 [124]: 9eacfcfbdb3ce0fc Block 0031 [125]: 07dedaeb0aee71ac Block 0031 [126]: 074435fad91548f4 Block 0031 [127]: 2dbfff23f31b5883 After pass 2: Block 0000 [ 0]: 5f047b575c5ff4d2 Block 0000 [ 1]: f06985dbf11c91a8 Block 0000 [ 2]: 89efb2759f9a8964 Block 0000 [ 3]: 7486a73f62f9b142 ... Block 0031 [124]: 57cfb9d20479da49 Block 0031 [125]: 4099654bc6607f69 Block 0031 [126]: f142a1126075a5c8 Block 0031 [127]: c341b3ca45c10da5 Tag: 51 2b 39 1b 6f 11 62 97 53 71 d3 09 19 73 42 94 f8 68 e3 be 39 84 f3 c1 a1 3a 4d b9 fa be 4a cb</artwork> </figure></sourcecode> </section> <section anchor="argon2i-test-vectors"title="Argon2inumbered="true" toc="default"> <name>Argon2i TestVectors"> <figure> <artwork>Vectors</name> <sourcecode type="test-vectors"> ======================================= Argon2i version number 19 ======================================= Memory: 32 KiB Passes: 3 Parallelism: 4 lanes Tag length: 32 bytes Password[32]: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 Salt[16]: 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 Secret[8]: 03 03 03 03 03 03 03 03 Associated data[12]: 04 04 04 04 04 04 04 04 04 04 04 04 Pre-hashing digest: c4 60 65 81 52 76 a0 b3 e7 31 73 1c 90 2f 1f d8 0c f7 76 90 7f bb 7b 6a 5c a7 2e 7b 56 01 1f ee ca 44 6c 86 dd 75 b9 46 9a 5e 68 79 de c4 b7 2d 08 63 fb 93 9b 98 2e 5f 39 7c c7 d1 64 fd da a9 After pass 0: Block 0000 [ 0]: f8f9e84545db08f6 Block 0000 [ 1]: 9b073a5c87aa2d97 Block 0000 [ 2]: d1e868d75ca8d8e4 Block 0000 [ 3]: 349634174e1aebcc ... Block 0031 [124]: 975f596583745e30 Block 0031 [125]: e349bdd7edeb3092 Block 0031 [126]: b751a689b7a83659 Block 0031 [127]: c570f2ab2a86cf00 After pass 1: Block 0000 [ 0]: b2e4ddfcf76dc85a Block 0000 [ 1]: 4ffd0626c89a2327 Block 0000 [ 2]: 4af1440fff212980 Block 0000 [ 3]: 1e77299c7408505b ... Block 0031 [124]: e4274fd675d1e1d6 Block 0031 [125]: 903fffb7c4a14c98 Block 0031 [126]: 7e5db55def471966 Block 0031 [127]: 421b3c6e9555b79d After pass 2: Block 0000 [ 0]: af2a8bd8482c2f11 Block 0000 [ 1]: 785442294fa55e6d Block 0000 [ 2]: 9256a768529a7f96 Block 0000 [ 3]: 25a1c1f5bb953766 ... Block 0031 [124]: 68cf72fccc7112b9 Block 0031 [125]: 91e8c6f8bb0ad70d Block 0031 [126]: 4f59c8bd65cbb765 Block 0031 [127]: 71e436f035f30ed0 Tag: c8 14 d9 d1 dc 7f 37 aa 13 f0 d7 7f 24 94 bd a1 c8 de 6b 01 6d d3 88 d2 99 52 a4 c4 67 2b 6c e8</artwork> </figure></sourcecode> </section> <section anchor="argon2id-test-vectors"title="Argon2idnumbered="true" toc="default"> <name>Argon2id TestVectors"> <figure> <artwork>Vectors</name> <sourcecode type="test-vectors"> ======================================= Argon2id version number 19 ======================================= Memory: 32 KiB, Passes: 3, Parallelism: 4 lanes, Tag length: 32 bytes Password[32]: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 Salt[16]: 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 Secret[8]: 03 03 03 03 03 03 03 03 Associated data[12]: 04 04 04 04 04 04 04 04 04 04 04 04 Pre-hashing digest: 28 89 de 48 7e b4 2a e5 00 c0 00 7e d9 25 2f 10 69 ea de c4 0d 57 65 b4 85 de 6d c2 43 7a 67 b8 54 6a 2f 0a cc 1a 08 82 db 8f cf 74 71 4b 47 2e 94 df 42 1a 5d a1 11 2f fa 11 43 43 70 a1 e9 97 After pass 0: Block 0000 [ 0]: 6b2e09f10671bd43 Block 0000 [ 1]: f69f5c27918a21be Block 0000 [ 2]: dea7810ea41290e1 Block 0000 [ 3]: 6787f7171870f893 ... Block 0031 [124]: 377fa81666dc7f2b Block 0031 [125]: 50e586398a9c39c8 Block 0031 [126]: 6f732732a550924a Block 0031 [127]: 81f88b28683ea8e5 After pass 1: Block 0000 [ 0]: 3653ec9d01583df9 Block 0000 [ 1]: 69ef53a72d1e1fd3 Block 0000 [ 2]: 35635631744ab54f Block 0000 [ 3]: 599512e96a37ab6e ... Block 0031 [124]: 4d4b435cea35caa6 Block 0031 [125]: c582210d99ad1359 Block 0031 [126]: d087971b36fd6d77 Block 0031 [127]: a55222a93754c692 After pass 2: Block 0000 [ 0]: 942363968ce597a4 Block 0000 [ 1]: a22448c0bdad5760 Block 0000 [ 2]: a5f80662b6fa8748 Block 0000 [ 3]: a0f9b9ce392f719f ... Block 0031 [124]: d723359b485f509b Block 0031 [125]: cb78824f42375111 Block 0031 [126]: 35bc8cc6e83b1875 Block 0031 [127]: 0b012846a40f346a Tag: 0d 64 0d f5 8d 78 76 6c 08 c0 37 a3 4a 8b 53 c9 d0 1e f0 45 2d 75 b6 5e b5 25 20 e9 6b 01 e6 59</artwork> </figure></sourcecode> </section> </section> <section anchor="iana"title="IANA Considerations"> <t>None.</t>numbered="true" toc="default"> <name>IANA Considerations</name> <t>This document has no IANA actions.</t> </section> <section anchor="security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <section anchor="security-hash"title="Securitynumbered="true" toc="default"> <name>Security ashash functiona Hash Function andKDF">KDF</name> <t>The collision and preimage resistance levels of Argon2 are equivalent to those of the underlying BLAKE2b hash function. To produce a collision, 2^(256) inputs are needed. To find a preimage, 2^(512) inputs must be tried.</t> <t>The KDF security is determined by the key length and the size of the internal state of hash function H'. To distinguish the output of the keyed Argon2 from random, a minimum of (2^(128),2^length(K)) calls to BLAKE2b are needed. </t> </section> <section anchor="security-tradeoff"title="Securitynumbered="true" toc="default"> <name>Security againsttime-space tradeoff attacks">Time-Space Trade-off Attacks</name> <t>Time-spacetradeoffstrade-offs allow computing a memory-hard function storing fewer memory blocks at the cost of more calls to the internalcomressioncompression function. The advantage oftradeofftrade-off attacks is measured in the reduction factor to the time-area product, where memory and extra compression function cores contribute to thearea,area and time is increased toaccomodateaccommodate the recomputation of missed blocks. A high reduction factor may potentially speed up the preimage search. </t> <t>Thebest known attacksbest-known attack on the 1-pass and 2-pass Argon2i is the low-storage attack described in <xreftarget="CBS16"></xref>,target="CBS16" format="default"/>, which reduces the time-area product (using the peak memory value) by the factor of 5. The best attack on3-pass and moreArgon2i with 3 passes or more is described in <xreftarget="AB16"></xref>target="AB16" format="default"/>, with the reduction factor being a function of memory size and the number ofpasses. Forpasses (e.g., for 1 gibibyte ofmemory:memory, a reduction factor of 3 for 3 passes, 2.5 for 4 passes, 2 for 6passes.passes). The reduction factor grows by about 0.5 with every doubling of the memory size. To completely prevent time-spacetradeoffstrade-offs from <xreftarget="AB16"></xref>,target="AB16" format="default"/>, the number of passesMUST<bcp14>MUST</bcp14> exceed the binary logarithm of memory minus 26. Asymptotically, the best attack on 1-pass Argon2i is given in <xreftarget="BZ17"></xref>target="BZ17" format="default"/>, with maximal advantage of the adversary upper bounded byO(m^(0.233))O(m^(0.233)), where m is the number of blocks. This attack is also asymptotically optimal as <xreftarget="BZ17"></xref>target="BZ17" format="default"/> alsoproveproves the upper bound on any attackofis O(m^(0.25)). </t> <t>The besttradeofftrade-off attack on t-pass Argon2d is the rankingtradeofftrade-off attack, which reduces the time-area product by the factor of 1.33. </t> <t>The best attack on Argon2id can be obtained by complementing the best attack on the 1-pass Argon2i with the best attack on a multi-pass Argon2d.ThusThus, the besttradeofftrade-off attack on 1-pass Argon2id is the combined low-storage attack (for the first half of the memory) and the ranking attack (for the second half), whichbring togethergenerate the factor of about 2.1. The besttradeofftrade-off attack on t-pass Argon2id is the rankingtradeofftrade-off attack, which reduces the time-area product by the factor of 1.33. </t> </section> <section anchor="security-general"title="Securitynumbered="true" toc="default"> <name>Security fortime-bounded defenders">Time-Bounded Defenders</name> <t>A bottleneck in a system employing thepassword-hashingpassword hashing function is often the function latency rather than memory costs. A rational defender would then maximize thebruteforcebrute-force costs for the attacker equipped with a list of hashes, salts, and timinginformation,information for fixed computing time on thedefender’sdefender's machine. The attack cost estimates from <xreftarget="AB16"></xref>target="AB16" format="default"/> imply that for Argon2i, 3 passes is almost optimal forthemostofreasonable memorysizes, and thatsizes; for Argon2d and Argon2id, 1 pass maximizes the attack costs for the constant defender time. </t> </section> <section anchor="security-recommend"title="Recommendations">numbered="true" toc="default"> <name>Recommendations</name> <t> The Argon2id variant with t=1 and2GiB2 GiB memory is the FIRSTRECOMMENDED<bcp14>RECOMMENDED</bcp14> option and is suggested as a default setting for all environments. This setting is secure against side-channel attacks and maximizes adversarial costs on dedicatedbruteforcebrute-force hardware. The Argon2id variant with t=3 and 64 MiB memory is the SECONDRECOMMENDED<bcp14>RECOMMENDED</bcp14> option and is suggested as a default setting for memory-constrained environments. </t> </section> </section><section anchor="ack" title="Acknowledgements"> <t>We thank greatly the following authors who helped a lot in preparing and reviewing this document: Jean-Philippe Aumasson, Samuel Neves, Joel Alwen, Jeremiah Blocki, Bill Cox, Arnold Reinhold, Solar Designer, Russ Housley, Stanislav Smyshlyaev, Kenny Paterson, Alexey Melnikov, Gwynne Raskind.</t> </section></middle> <back><references title="Normative References"> <reference anchor="RFC2119" target = "http://www.rfc-editor.org/info/rfc2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author surname="Bradner" initials ="S."/> <date month="March" year="1997" /> </front> <seriesInfo name="RFC" value="2119"/> </reference> <reference anchor="BLAKE2" target="https://www.rfc-editor.org/info/rfc7693"> <front> <title> The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC) </title> <author initials="M-J." surname="Saarinen" fullname="M-J. Saarinen" role="editor"> <organization/> </author> <author initials="J-P." surname="Aumasson" fullname="J-P. Aumasson"> <organization/> </author> <date year="2015" month="November"/> <abstract> <t> This document describes the cryptographic hash function BLAKE2 and makes the algorithm specification and C source code conveniently available to the Internet community. BLAKE2 comes in two main flavors: BLAKE2b is optimized for 64-bit platforms and BLAKE2s for smaller architectures. BLAKE2 can be directly keyed, making it functionally equivalent to a Message Authentication Code (MAC). </t> </abstract> </front> <seriesInfo name="RFC" value="7693"/> </reference><displayreference target="RFC7693" to="BLAKE2"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7693.xml"/> </references><references title="Informative References"> <!-- &RFC4086; --><references> <name>Informative References</name> <reference anchor="ARGON2"target = "https://www.cryptolux.org/images/0/0d/Argon2.pdf">target="https://www.cryptolux.org/images/0/0d/Argon2.pdf"> <front> <title>Argon2: the memory-hard function for password hashing and other applications</title> <author initials="A." surname="Biryukov" fullname="Alex Biryukov"/> <author initials="D." surname="Dinu" fullname="Daniel Dinu"/> <author initials="D." surname="Khovratovich" fullname="Dmitry Khovratovich"/> <datemonth="October" year="2015" />month="March" year="2017"/> </front><seriesInfo name="WWW" value="www.cryptolux.org" /></reference> <reference anchor="HARD" target="https://eprint.iacr.org/2014/238.pdf"> <front> <title>High Parallel Complexity Graphs and Memory-Hard Functions</title> <author initials="J." surname="Alwen" fullname="Joel Alwen"/> <author initials="V." surname="Serbinenko" fullname="Vladimir Serbinenko"/> <dateyear="2014" />year="2015" month="June"/> </front> <seriesInfoname="STOC" value="2015"/>name="DOI" value="10.1145/2746539.2746622"/> <refcontent>STOC '15</refcontent> </reference> <reference anchor="CBS16" target="https://eprint.iacr.org/2016/027.pdf"> <front> <title>Balloon Hashing:Provably Space-Hard Hash Functions with Data-Independent Access Patterns</title> <author initials="H." surname="Corrigan-Gibbs" fullname="Henry Corrigan-Gibs"/>A Memory-Hard Function Providing Provable Protection Against Sequential Attacks</title> <author initials="D." surname="Boneh" fullname="Dan Boneh"/> <author initials="H." surname="Corrigan-Gibbs" fullname="Henry Corrigan-Gibbs"/> <author initials="S." surname="Schechter" fullname="Stuart Schechter"/> <datemonth="January" year="2016" />month="May" year="2017"/> </front> <seriesInfoname="Asiacrypt" value="2016"/>name="DOI" value="10.1007/978-3-662-53887-6_8"/> <refcontent>ASIACRYPT 2016</refcontent> </reference> <reference anchor="AB16" target="https://eprint.iacr.org/2016/115.pdf"> <front> <title>Efficiently Computing Data-Independent Memory-Hard Functions</title> <author initials="J." surname="Alwen" fullname="Joel Alwen"/> <author initials="J." surname="Blocki" fullname="Jeremiah Blocki"/> <datemonth="December" year="2015" />month="March" year="2016"/> </front> <seriesInfoname="Crypto" value="2016"/>name="DOI" value="10.1007/978-3-662-53008-5_9"/> <refcontent>CRYPTO 2016</refcontent> </reference> <reference anchor="BZ17" target="https://eprint.iacr.org/2017/442.pdf"> <front> <title>On the Depth-Robustness and Cumulative Pebbling Cost of Argon2i</title> <author initials="J." surname="Blocki" fullname="Jeremiah Blocki"/> <author initials="S." surname="Zhou" fullname="Samson Zhou"/> <date month="May"year="2017" />year="2017"/> </front> <seriesInfoname="TCC" value="2017"/>name="DOI" value="10.1007/978-3-319-70500-2_15"/> <refcontent>TCC 2017</refcontent> </reference> <reference anchor="ARGON2ESP" target="https://www.cryptolux.org/images/d/d0/Argon2ESP.pdf"> <front> <title>Argon2: New Generation of Memory-Hard Functions for Password Hashing and Other Applications</title> <author initials="A." surname="Biryukov" fullname="Alex Biryukov"/> <author initials="D." surname="Dinu" fullname="Daniel Dinu"/> <author initials="D." surname="Khovratovich" fullname="Dmitry Khovratovich"/> <date month="March"year="2016" />year="2016"/> </front> <seriesInfoname="Euro SnP" value="2016"/>name="DOI" value="10.1109/EuroSP.2016.31"/> <refcontent>Euro SnP 2016</refcontent> </reference> <reference anchor="AB15" target="https://eprint.iacr.org/2015/227.pdf"> <front> <title>Tradeoff Cryptanalysis of Memory-Hard Functions</title> <author initials="A." surname="Biryukov" fullname="Alex Biryukov"/> <author initials="D." surname="Khovratovich" fullname="Dmitry Khovratovich"/> <date month="December"year="2015" />year="2015"/> </front> <seriesInfoname="Asiacrypt" value="2015"/>name="DOI" value="10.1007/978-3-662-48800-3_26"/> <refcontent>ASIACRYPT 2015</refcontent> </reference> </references> </references> <section anchor="ack" numbered="false" toc="default"> <name>Acknowledgements</name> <t>We greatly thank the following individuals who helped in preparing and reviewing this document: <contact fullname="Jean-Philippe Aumasson"/>, <contact fullname="Samuel Neves"/>, <contact fullname="Joel Alwen"/>, <contact fullname="Jeremiah Blocki"/>, <contact fullname="Bill Cox"/>, <contact fullname="Arnold Reinhold"/>, <contact fullname="Solar Designer"/>, <contact fullname="Russ Housley"/>, <contact fullname="Stanislav Smyshlyaev"/>, <contact fullname="Kenny Paterson"/>, <contact fullname="Alexey Melnikov"/>, and <contact fullname="Gwynne Raskind"/>.</t> <t>The work described in this document was done before <contact fullname="Daniel Dinu"/> joined Intel, while he was at the University of Luxembourg.</t> </section> </back> </rfc>