Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Salsa20

2,276 views

Published on

This report is made by Amit (facebook.com/titanium009) for his summer project @ ISI, Kolkata.... Drop me a mail if you want (titanium009@gmail.com)

  • Some of these essay writing guides can be very helpful, but I don't think you should support and promote services that sell essays (written by others) to students, who then turn them in as their own work. That's just wrong, on many levels. Check out HelpWriting.net for loads of helpful tips, advice and instruction to help students write their own standout essays!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Salsa20

  1. 1. INDIAN STATISTICAL INSTITUTE SalsaA Detailed Study on Salsa under the guidance of Dr. Bimal K. Roy Amit Kumar Ghosh , Abhijnan Chattopadhyay, Priyanka Syal, Preetha BhattacharjeeThe document gives an overall description over specifications of Salsa as hash function, expansionfunction, encryption function ; a range of benchmarks relevant to cryptographic speed ; andexplains, at a lower level, techniques to achieve this performance ; and discusses modern daycryptanalysis and security of Salsa and point all alternative measures and other variants listed tilldate.
  2. 2. Table of ContentsDesigning Salsa20 ............................................................................................................................. 2 Introduction .................................................................................................................................. 2 Operations..................................................................................................................................... 2 Encryption ..................................................................................................................................... 3 Hashing ......................................................................................................................................... 4Benchmarking Salsa20 ...................................................................................................................... 5 The Salsa20 structure .................................................................................................................... 5 Salsa20 on different Platforms ....................................................................................................... 5Salsa20 specification ......................................................................................................................... 7 Defining Functions ......................................................................................................................... 7 Specification .................................................................................................................................. 8 The Salsa20 hash function ......................................................................................................... 8 The Salsa20 expansion function ................................................................................................. 9 The Salsa20 encryption function ................................................................................................ 9Security and cryptanalysis of Salsa20 ............................................................................................... 9 Side Channel Attacks ..................................................................................................................... 9 Notes on the uniform randomness and diagonal constants ............................................................ 9 Differential Cryptanalysis of Salsa20/8 ......................................................................................... 10 Truncated differential cryptanalysis of five rounds of Salsa20 .................................................. 10 Algebraic attacks ......................................................................................................................... 11 Other notions of security ............................................................................................................. 11Alternative Proposals ..................................................................................................................... 11 Extending the Salsa20 nonce ....................................................................................................... 11 1|P a ge
  3. 3. Designing Salsa20 Introduction eSTREAM, the ECRYPT Stream Cipher Project, called for submissions of stream ciphers in November 2004. It received more than 30 proposals from 97 cryptographers in 19 countries, and over the subsequent years collected a total of 200 papers. The final eSTREAM portfolio," containing four software stream ciphers and four hardware stream ciphers, was announced in April 2008. The portfolio was revised in September 2008 to eliminate a hardware stream cipher, F-FCSR v2, that had been broken. Salsa20/r is a software-oriented (profile 1) stream cipher proposed by Daniel J. Bernstein. The algorithm supports keys of 128 bits and 256 bits. During its operation, the key, a 64-bit nonce (unique message number), a 64-bit counter and four 32-bit constants are used to construct the 512-bit initial state. After r iterations of the Salsa20/r round function, the updated state is used as a 512-bit keystream output. Each such output block is an independent combination of the key, nonce, and counter and, since there is no chaining between blocks, the operation of Salsa20/r resembles the operation of a block cipher in counter mode. Salsa20/r therefore shares the very same implementation advantages, in particular the ability to generate output blocks in any order 70 and in parallel. The maximum length of the keystream produced by Salsa20/r is 2 bits. Operations Topic ExplanationsInteger multiplications Argument Counter-argument  The basic argument for integer  integer multiplication takes multiplication is that the output bits several cycles on typical CPUs, are complicated functions of the input and many more cycles on some bits, mixing the inputs more thoroughly CPUs. For comparison, a than comparably complex series of  A further argument against integer simple integer operations is multiplication is that it increases the always reasonably fast. risk of timing leaks. What really matters Multiplication might be slightly is not the speed of integer faster on some CPUs but it is multiplication, but the speed of not consistently constant-time integer multiplication, fast. which is often much slower.S-box lookups Argument Counter-argument[An S-box lookup is an array  S-boxes is that a single table lookup  A simple integer operationlookup using an input- can mangle its takes one or two 32-bit inputsdependent index. Most input quite more thoroughly than a rather than one 8-bit input, so itciphers are designed to take chain of a few simple integer electively mangles severaladvantage of this operation. operations taking the same amount of 8-bit inputs at once. It is notFor example, typical high- time. obvious that a series of S-boxspeed AES software has  A further argument against S-box lookups-even withseveral 1024-byte S-boxes, lookups is that, on most platforms, rather large S-boxes, as in AES,each of which converts theyare vulnerable to timing attacks. increasing L1 cache pressure on8-bit inputs to 32-bit outputs.] NISTs statement to the contrary large CPUs and forcing different (table lookup is not vulnerable to implementation techniques for 2|P a ge
  4. 4. timing attacks") is erroneous. small CPUs -is faster than a comparably complex series of integer operations.Rotations Argument Counter-argument[Rotations account for about The basic argument for rotations is that oneone third of the integer xor of a rotated quantity provides as muchoperations in Salsa20, and diffusion as two xors of shifted quantities.more on the UltraSPARC.Replacing some of therotations with a comparablenumber of additions mightachieve comparable diusion in fewer rounds.] Encryption Topic ExplanationsDifferent encryption and The popularity of CBC appears to be a historical accident. I have found verydecryption few people arguing for CBC over counter mode, and none of the arguments are even marginally convincing. On occasion I encounter the superstitious notion that encryption by xor is too simple"; but a one-time pad (in conjunction with aWegman-Carter MAC) provably achieves perfect secrecy (and any desired level of integrity), so there is obviously nothing wrong with xor. There are several clear arguments against CBC. One disadvantage of CBC is that it requires different code for encryption and decryption, increasing costs in many contexts. Another disadvantage of CBC is that the extra communication from the cryptanalyst into the cipher state is a security threat; regaining the original level of confidence means adding rounds, taking additional time.Stream’s dependency over Argument Counter-argumentplaintext  The basic argument for incorporating  One counterargument is that plaintext into the stream (specically, “free" is a wild exaggeration. incorporating plaintext bytes into Incorporating the plaintext into subsequent bytes of the stream) is that the stream takes time for every this allows message authentication for block, and generating an free." After encrypting the plaintext, authenticator takes time for one generate a constant number of every message. additional stream bytes and output  Incorporation of plaintext, them as an authenticator of the being extra communication plaintext. from the cryptanalyst into the . cipher state, is a security threat. Regaining the original level of condence means adding rounds, which takes additional time for every block.State Argument Counter-argument  The argument for a larger state is that  A larger state loses time in one does not need as many cipher some contexts. Reuse forces rounds to achieve the same serialization: one cannot take conjectured security level. Copying advantage of extra hardware to 3|P a ge
  5. 5. state across blocks seems to provide reduce the latency of just as much mixing as the rst few encrypting or decrypting long cipher rounds. A larger messages. Furthermore, large state therefore saves some time after states reduce the number of the first block.. messages that can be processed simultaneously on limited hardware.Block Size Argument Counter-argument  The basic argument for a larger block  A larger block size also loses size, say 256 bytes, one does not need time. On most CPUs, the as many cipher rounds to achieve the communication cost of same conjectured security level. Using sweeping through a 256-byte a larger block size, like copying state block is a bottleneck; CPUs are across blocks, seems to provide just as designed for computations that much mixing as the rst few cipher dont involve so much rounds. A larger state therefore saves data. time. Hashing Topic ExplanationsImplementation of Block Argument Counter-argumentcipher  The basic argument for a block cipher  The basic disadvantage of a for keeping the k words independent block cipher is that the k words of the n words is that, for fixed k, it is consume valuable easy to make a block cipher be an communication resources. A invertible function of n. But this 64-byte block cipher with a 32- feature seems to be of purely historical byte key would need interest. Invertibility is certainly not to repeatedly sweep through 96 necessary for encryption. bytes of memory (plus a few bytes of temporary storage) for its 64 bytes of output; in contrast, Salsa20 repeatedly sweeps through just 64 bytes of memory (plus a few bytes of temporary storage) for its 64 bytes of output.Code-Length Argument Counter-argument  Using two different kinds of rounds is  The basic counterargument is the idea that attacks will have some that extra code is expensive in extra difficulty passing through the many contexts. It increases switch from one kind to another. This pressure on a CPUs L1 cache, extra difficulty would allow the cipher for example, and it increases to reach the same security level with the minimum size of a fewer rounds.. hardware implementation.Diffusion among words  Salsa20 views its 16 words as a 4 4 array. During the rst round, there is no communication between columns; each column has its own chain of 12 serial 4|P a ge
  6. 6. operations modifying the words in that column. During the second round, there is no communication between rows; each row has its own chain of 12 serial operations modifying the words in that row. Et cetera.  There are pairs (i; j) such that a change in word i has no opportunity to affect word j until the third round. A different communication structure would allow much faster diffusion of changes through all 16 words. On the other hand, it doesnt appear to be possible to achieve much faster diffusion of changes through all 512 bits.Modifications other than add- There are many plausible ways to modify each word in a column using other wordsrotate-xor in the same column. The author settled on xor a rotated sum" as bouncing back and forth between incompatible structures on the critical path. The author chose xor a rotated sum" over add a rotated xor" for simple performance reasons: the x86 architecture has a three-operand addition (LEA) but not a three-operand xor. Benchmarking Salsa20 The Salsa20 structure Encryption of a 64-byte block is xor with the output of the Salsa20 hash function, where the input consists of the 32-byte Salsa20 key, the 8-byte nonce (unique message number), the 8-byte block counter, and 16 constant bytes. The reader is cautioned that encryption time is slightly longer than hashing time: in particular, a 64-byte xor is not free. The Salsa20 hash function regards its 64-byte input x as an array of 16 words in little-endian form. It performs 320 invertible modfications, where each modfication changes one word of the array. The resulting words are added to the original words, producing, in little-endian form, the 64-byte output Salsa20(x). Each modifiation involves xoring into one word a rotated version of the sum of two other words. Thus the 320 modifiations involve, overall, 320 additions, 320 rotations, and 320 xors. The rotations are all by constant distances. The entire series of modfications is a series of 10 identical double-rounds. Each double-round is a series of 2 rounds. Each round is a set of 4 parallel quarter-rounds. Each quarter-round is a series of 4 word modifiations. Salsa20 on different PlatformsPlatform Name Implementation Comparison to AES timingsAMD Athlon salsa20_word_pm software takes 29:25 Osvik reports that unpublished software|with no Athlon cycles for a Salsa20 round, totalling protection against timing leaks|takes 225 Athlon 585 cycles (9:15 cycles/byte) for 20 rounds, cycles (over 14 cycles/byte) to encrypt a 16-byte totalling 645 cycles (10:08 cycles/byte) for block with a 16-byte AES key, assuming that the key the Salsa20 hash function, timed as 680 was pre-expanded into 176 bytes. One can cycles with 35 cycles timing overhead. The reasonably extrapolate that similar software would timings are actually 655 or 656 cycles most of take over 300 Athlon cycles (over 18 cycles/byte) to the time but 849 cycles on every eighth call, encrypt a 16-byte block with a 32-byte AES key, presumably because of branch assuming that the key was pre-expanded into 240 mispredictions. bytes. The compiled code occupies 1248 bytes. Its main loop occupies 937 bytes and handles 4 rounds.IBM PowerPC salsa20_word_aix software takes 33 PowerPC 5|P a ge
  7. 7. RS64 IV RS64 IV cycles for each Salsa20 round, totalling 660 cycles (10:32 cycles/byte) for 20 rounds, totaling 756 cycles (11:82 cycles/byte) for the Salsa20 hash function, timed as 770 cycles with 14 cycles timing overhead. The compiled code for the Salsa20 hash function occupies 768 bytes. Its main loop occupies 392 bytes and handles 2 rounds.Intel Pentium salsa20_word_pii software takes 37:5 Osvik reports that unpublished software|with noIII pentium III cycles for each Salsa20 round, protection against timing leaks|takes 224 Pentium totalling 750 cycles (11:72 cycles/byte) for 20 III cycles (14 cycles/byte) to encrypt a 16-byte block rounds, totalling 837 cycles (13:08 with a 16-byte AES key, assuming that the key was cycles/byte) for the Salsa20 hash function, pre-expanded into 176 bytes. timed as 872 cycles with 35 cycles timing One can reasonably extrapolate that similar overhead. (The timings are actually 859 software would take over 300 Pentium III cycles cycles most of the time but 908 cycles on (over 18 cycles/byte) to encrypt a 16-byte block every fourth call, presumably because of with a 32- byte AES key, assuming that the key was branch mispredictions.) pre-expanded into 240 bytes. The compiled code for the Salsa20 hash function occupies 1280 bytes. Its main loop occupies 937 bytes and handles 4 rounds.Intel Pentium 4 salsa20_word_p4 software takes 48 Pentium Osvik reports that unpublished software|with nof12 4 f12 (Willamette) cycles for each Salsa20 protection against timing leaks|takes 260 Pentium round, totalling 960 cycles (15 cycles/byte) 4 (f12?) cycles (16:25 cycles/byte) to encrypt a 16- for 20 rounds, totaling 1052 cycles (16:44 byte block with a 16-byte AES key, assuming that cycles/byte) for the Salsa20 hash function, the key was pre-expanded into 176 bytes. Matsui timed as 1136 cycles with 84 cycles timing and Fukuda report that unpublished software|with overhead. no protection against timing leaks|takes 251 The compiled code for the Salsa20 hash Pentium 4 (f29?) cycles (15:68 cycles/byte) and function occupies 1144 bytes. Its main loop 284 Pentium 4 f33 cycles (17:75 cycles/byte). occupies 629 bytes and handles 4 rounds. One can reasonably extrapolate that similar software would take over 340 Pentium 4 f12 cycles (over 21 cycles/byte) to encrypt a 16-byte block with a 32-byte AES key, assuming that the key was pre-expanded into 240 bytes.Intel Pentium salsa20_word_pm software takes 33:75 The Pentium M might compute AES in marginallyM Pentium M cycles for each Salsa20 round, less time than the Pentium III, but both CPUs face totalling 675 cycles (10:55 cycles/byte) for 20 the same basic AES bottleneck: encrypting a 16- rounds, totalling 740 cycles (11:57 byte block with a 16-byte AES key requires 200 S- cycles/byte) for the Salsa20 hash function, box lookups, which cannot take fewer than 200 timed as 790 cycles with 50 cycles timing cycles (12:5 cycles/byte). Similarly, encrypting a 16- overhead. (The timings are actually 780 or byte block with a 32-byte AES key requires 280 S- 781 cycles most of the time but 856 cycles on box lookups, which cannot take fewer than 280 every eighth call, presumably because of cycles (17:5 cycles/byte). Even more S-box lookups branch mispredictions.) are required if keys are not pre-expanded. The compiled code for the Salsa20 hash function occupies 1248 bytes. Its main loop occupies 937 bytes and handles 4 rounds.Motorola salsa20_word_macos software takes 24:5 Lipmaa reports that AES software by Ahrens|with, 6|P a ge
  8. 8. PowerPC 7410 PowerPC 7410 cycles for each Salsa20 round, presumably, no protection against timing totalling 490 cycles (7:66 cycles/byte) for 20 leaks|takes 401 PowerPC 7400 cycles (over 25 rounds, totaling approximately 570 cycles cycles/byte) to encrypt a 16-byte block with a 16- (8:91 cycles/byte) for the Salsa20 hash byte AES key, assuming that the key was function, timed as approximately 584 cycles pre-expanded into 176 bytes. I am not aware of any with 14 cycles timing overhead. (Precise relevant differences between the PowerPC 7400 timings are dicult: the CPUs cycle counter and the PowerPC 7410. has 16-cycle resolution.) It should be possible to do somewhat better|my The compiled code for the Salsa20 hash own public-domain AES software, including key function occupies 768 bytes. Its main loop expansion, takes about 490 cycles on the PowerPC occupies 392 bytes and handles 2 rounds. 7410|but AES is clearly much slower than Salsa20 on this CPUSun salsa20_word_sparc software takes 40:5 Lipmaa reports that unpublished software|with,UltraSPARC II UltraSPARC II cycles for each Salsa20 round, presumably, no protection against timing totalling 810 cycles (12:66 cycles/byte) for 20 leaks|takes 270 UltraSPARC II cycles (over 16 rounds, totaling 881 cycles (13:77 cycles/byte) to encrypt a 16-byte block with a 16- cycles/byte) for the Salsa20 hash function, byte AES key, assuming that the key was timed as 892 cycles with 11 cycles timing pre-expanded into 176 bytes. One can reasonably overhead. extrapolate that similar software would take over The compiled code for the Salsa20 hash 370 UltraSPARC II cycles (over 23 cycles/byte) to function occupies 936 bytes. Its main loop encrypt a 16-byte block with a 32-byte AES key, occupies 652 bytes and handles 2 rounds. assuming that the key was pre-expanded into 240 bytes.Sun salsa20_word_sparc software takes 41 AES on an UltraSPARC III is at least as slow as AESUltraSPARC III UltraSPARC III cycles for each Salsa20 round, on an UltraSPARC II. totalling 820 cycles (12:82 cycles/byte) for 20 rounds, totaling 889 cycles (13:90 cycles/byte) for the Salsa20 hash function, timed as 905 cycles with 16 cycles timing overhead. The compiled code for the Salsa20 hash function occupies 936 bytes. Its main loop occupies 652 bytes and handles 2 rounds. Salsa20 specification Defining Functions Functions Inputs & Definition OutputsThe If y is a 4-wordquarterround sequence thenfunction quarterround(y) is a 4-word sequence 7|P a ge
  9. 9. The rowround If y is a 16-wordfunction sequence then rowround(y) is a 16-word sequence.The If x is a 16-wordcolumnround sequence thenfunction columnround(x) is a 16-word sequence.The doubleround If x is a 16-word A double round is a column round followed by a row round: doubleround(x) =function sequence then rowround(columnround(x)). doubleround(x) is a 16-word sequence.The littleendian If b is a 4-bytefunction sequence then littleendian(b) is a word. Specifications Functions Inputs & Outputs DefinitionThe Salsa20 If x is a 64-bytehash function sequence then Salsa20(x) is a 64- byte sequence. 8|P a ge
  10. 10. The Salsa20 If k is a 32-byte orexpansion 16-byte sequencefunction and n is a 16-byte sequence then Salsa20k(n) is a 64-byte sequence.The Salsa20 Let k be a 32-byteencryption or 16-bytefunction sequence. Let v be an 8-byte sequence. Let m be a l-byte sequence for some l€{1,2,…, }. The Salsa20 encryption of m with nonce v under key k, denoted Salsa (v) m, is an l-byte sequence. Security and cryptanalysis of Salsa20 Side-channel attacks Natural Salsa20 implementations take constant time on a huge variety of CPUs; here constant means input-independent. There is no incentive for the authors of Salsa20 software to use variable-time operations such as S-box lookups. Timing attacks against Salsa20 are therefore just as di_cult as pure cryptanalysis of the Salsa20 outputs. The operations in Salsa20 are also among the easiest to protect against power attacks and other side-channel attacks. Notes on the uniform randomness and diagonal constants † Salsa20 column round: Each Salsa20 column round affects each column in the same way starting from the diagonal. Each Salsa20 row round affects each row in the same way starting from the diagonal. Consequently, shifting the entire Salsa20 hash-function input array along the diagonal has exactly the same effect on the output. † Salsa20 expansion function: o Eliminates this shift structure by limiting the attackers control over the hash- function input. In particular, the input diagonal is always 0x61707865, 0x3320646e, 0x79622d32, 0x6b206574, which is different from all its nontrivial shifts. In other words, two distinct arrays with this diagonal are always in distinct orbits under the shift group. o Eliminates this rotation structure. The input diagonal is different from all its nontrivial shifts and all its nontrivial rotations and all nontrivial shifts of its nontrivial 9|P a ge
  11. 11. rotations. In other words, two distinct arrays with this diagonal are always in distinct orbits under the shift/rotate group. † Salsa20 hash function: Operations are almost compatible with rotation of each input word by, say, 10 bits. Rotation changes the effect of carries that cross the rotation boundary, but it is consistent with all other carries, and with the Salsa20 operations other than addition. † Attacks based on Non-randomness: Simon Fischer, Willi Meier, Côme Berbain, Jean- François Biasse and M. J. B. Robshaw published a paper which shows that Stream cipher initialisation should ensure that the initial state or keystream is not detectably related to the key and initialisation vector. In this paper we analyse the key/IV setup of the eSTREAM Phase 2 candidates Salsa20 and TSC-4. In the case of Salsa20 we demonstrate a key recovery attack on six rounds and observe non-randomness after seven. For TSC-4, non-randomness over the full eight-round initialisation phase is detected, but would also persist for more rounds.Differential Cryptanalysis of Salsa20/8The idea of a differential attack is that some “small” differences in input states have a perceptiblechance of producing “small” differences after the first step of the computation, the second step ofthe computation, etc. Salsa AESSalsa20 is quite different in this respect from Salsa20 has 16-byte inputs, 64-byte outputs, andciphers such as AES where the input size is as 32-byte keys; there are ,choices of (n, ,k) solarge as the state size. AES has 16-byte inputs, there is no a-priori reason to believe that any of16-byte outputs, and (at least) 16-byte keys; the choices have the 128-bit quantitythere are 2384 choices of (n, ,k) so presumably and the 512-bit quantity and Salsak Salsakthere are more than ,choices in which both (n) are “small”.of the 128-bit quantities and AESk AESk (n) are “small”. † Yukiyasu Tsunoo , Teruo Saito , Hiroyasu Kubo , Tomoyasu Suzaki, and Hiroki Nakashima published a paper which presents a cryptanalysis of the Salsa20 stream cipher proposed in 2005. Salsa20 was submitted to eSTREAM, the ECRYPT Stream Cipher Project. The cipher uses bitwise XOR, addition modulo , and constant-distance rotation operations on an internal state of 16 32-bit words. † It is reported that there is a significant bias in the differential probability for Salsa20’s 4th round internal state. It is further shown that using this bias, it is possible to break the 256-bit secret key 8-round reduced Salsa20 model with a lower computational complexity than an exhaustive key search. The cryptanalysis method exploits characteristics of addition, and succeeds in reducing the computational complexity compared to previous methods.Truncated differential cryptanalysis of five rounds of Salsa20Going further detail of the paper presented by Yukiyasu Tsunoo , Teruo Saito , Hiroyasu Kubo ,Tomoyasu Suzaki, and Hiroki Nakashima; Paul Crowley published another paper stating “Truncateddifferential cryptanalysis of five rounds of Salsa20” which present an attack on Salsa20 reduced tofive of its twenty rounds.This attack uses many clusters of truncated differentials and requires ,work and plaintexts.This conclusion leaves some open questions. 10 | P a g e
  12. 12. It is clear that a naive attack of this type cannot be extended to more than a handful of rounds; thishas no negative implications for the security of the full Salsa20- 32/20 presented to eSTREAM.Nonetheless, the degree of clustering exhibited by these differential characteristics is surprising; it ismore usual for a single differential trail to dominate. It is also striking to find differential trails whoseoverall probability is so greatly mispredicted by the products of the probabilities of its components,marking a violation of the independence assumption usual in differential cryptanalysis. In bothinstances, it would bear investigation whether other ciphers that rely heavily on addition mod 2n tointroduce nonlinearity in GF(2) would also show these properties in differential cryptanalysis, orrelated properties in other forms of cryptanalysis.Algebraic attacksGeneral-purpose equation-solving methods, notably Buchbergers algorithm for computing Groebnerbases, are remarkably powerful. Clegg, Edmonds, and Impagliazzo in proved for a comparableproblem, namely finding proofs in propositional logic|that a Groebner-basis computation can quicklysolve any problem that can be quickly solved by various ad-hoc proof-finding techniques.Even better, the Groebner-basis computation can quickly solve other problems that cannot be quicklysolved by the ad-hoc techniques. It would be interesting to see analogous theorems regarding variousad-hoc cryptanalytic techniques. Fortunately, there does not seem to exist any “small” set ofequations for the state bits in Salsa20. Each of the 320 32-bit additions in the Salsa20 computationrequires dozens of quadratic equations, producing a substantially larger system of equations than arerequired to describe, for example, the bits in AES. Groebner-basis techniques for solving the AES-bitequations are, by the most optimistic estimates, slightly faster than brute-force search for a 256-bitkey, but they use vastly more memory and thus have a much worse price-performance ratio.Algebraic attacks against Salsa20 appear to be even more difficult.Other notions of security Attacks ExplanationWeak-key attacks This type of attack seems highly implausible for Salsa20. The Salsa20 key is mangled along with the input in an extremely complicated way. Any key differences rapidly spread through the entire Salsa20 state for the same reason that input differences do.Equivalent-key attacks This type of attack, like a weak-key attack, seems highly implausible for Salsa20 as machine would violate the Salsa20 security conjecture. In other words, there is no need to make a separate conjecture regarding equivalent keys.Related-key attacks The standard solutions to all the standard cryptographic problems -encryption, authentication, etc. - are protocols that do not allow related-key attacks on the underlying primitives.There is no evidence of violence till date.Key Recovery Attack At FSE 2008 Aumasson et al. improved this attack on Salsa20/7 and presented the first key-recovery attack on Salsa20/8. . It is a differential attack based on a technique called probabilistic neutral bits. The authors identify collision and preimage attacks for two simplified variants, then we discuss differential attacks on the original version, and exploit a high-probability differential to reduce complexity of collision search from 2256 to 279 for 3-round Rumba. 11 | P a g e
  13. 13. Alternative ProposalsExtending the Salsa20 nonceDaniel J. Bernstein, the creator of Salsa published an another paper entitled “Extending the Salsa20nonce” which introduces the XSalsa20 stream cipher. XSalsa20 is based upon the Salsa20 streamcipher but has a much longer nonce: 192 bits instead of 64 bits. XSalsa20 has exactly the samestreaming speed as Salsa20, and its extra nonce-setup cost is slightly smaller than the cost ofgenerating one block of Salsa20 output. The paper proves that XSalsa20 is secure if Salsa20 issecure: any fast attack on XSalsa20 using q queries and succeeding with probability p can beconverted into a fast attack on Salsa20 succeeding with probability at least p/(q + 1).The paper introduces a new family of stream ciphers, XSalsa20. XSalsa20 is, at first glance, quitesimilar to Salsa20: it is built from exactly the same operations, has exactly the same protectionsagainst side-channel attacks, has exactly the same streaming speed, supports 256-bit keys, andallows reduced- round variants such as XSalsa20/12. Note that the speed reports above are forfull-round Salsa20/20, not Salsa20/12. The advantage of XSalsa20 over Salsa20 is a longer nonce:192 bits rather than 64 bits. The disadvantage is that nonce setup is less efficient-but theextra cost here is comparable to, and in fact slightly smaller than, the cost of generating a singleSalsa20 output block.XSalsa20 might at first appear to be an ad-hoc design, following standard principles but potentiallyvulnerable to new attacks. On the contrary! The paper proves that any fast successful attack onXSalsa20 can be converted into a fast successful attack on Salsa20. Confidence in the security ofSalsa20 therefore implies confidence in the security of XSalsa20.The paper is not meant to take a position in the dispute regarding the necessity of longer nonces. Thepaper does not claim any benefits for XSalsa20 in an application that already works with Salsa20s64-bit nonces. What the paper shows is that-in case an application does want longer nonces-theSalsa20 nonce can be safely extended at surprisingly low cost.References 1. Daniel J. Bernstein, Salsa20 - Design, Specification, Security and Speed. URL: http://www.ecrypt.eu.org/stream/p3ciphers/salsa20/salsa20_p3.zip 2. Paul Crowley, Truncated differential cryptanalysis of five rounds of Salsa20. URL: http://eprint.iacr.org/2005/375 3. Yukiyasu Tsunoo , Teruo Saito , Hiroyasu Kubo , Tomoyasu Suzaki, and Hiroki Nakashima, Differential Cryptanalysis of Salsa20/8. URL: http://sasc.crypto.rub.de/files/sasc2007_039.pdf 4. Jean-Philippe Aumasson, Simon Fischer, Shahram Khazaei, Willi Meier and Christian Rechberger , New Features of Latin Dances: Analysis of Salsa, ChaCha, and Rumba. URL: http://www.springerlink.com/content/j35241j881018085/ 5. Simon Fischer, Willi Meier, Côme Berbain, Jean-François Biasse and M. J. B. Robshaw, Non- randomness in eSTREAM Candidates Salsa20 and TSC-4. URL: http://www.springerlink.com/content/46wv58h040218wp4/ 6. Daniel J. Bernstein, Extending the Salsa20 nonce. URL: http://cr.yp.to/snuffle/xsalsa- 20110204.pdf 7. Robshaw, Matthew; Billet, Olivier (Eds.), New Stream Cipher Designs. URL: http://www.springer.com/computer/security+and+cryptology/book/978-3-540-68350-6 12 | P a g e

×