BLAKE Cryptographic Hash Function

4003-482-01 Crypto Final Project
Final Paper: https://speakerdeck.com/breandan/blake-cryptographic-hash-function-paper

Transcript

1. Team Asteroid BLAKE 256
2. BLAKE Hash - Overview • NIST SHA-3 Hash Competition Finalist ◦ Four specifications - BLAKE 224, 256, 384, 512 ◦ HAIFA construction - Salt handling ◦ Three-stage internal hash function • Stage 1 - Initialization ◦ Input: 8 chaining words, 4 salt words, 2 counter words ◦ Additionally, 16 constant words ◦ Produces 16-word input for the rounds arranged in a 4x4 matrix
3. BLAKE Hash - Overview • Stage 2 - Rounds ◦ Input: 16 chaining words, 16 message words, 16 constant words ◦ 14 rounds of the "G function" per message block • Stage 2 cont'd - G function ◦ Applies the Gi function eight times ◦ First - Columns of the input 4x4 matrix ◦ Second - Diagonals of the input 4x4 matrix
4. BLAKE Hash - Overview • Stage 2 cont'd - Gi function ◦ Four input words, a row or diagonal from the 4x4 matrix ◦ Additionally, two constant words and two message words selected with a permutation ◦ Four output words put back into the row or column • Stage 3 - Finalization ◦ Input: 4x4 matrix (16 words), 8 original chaining words, 8 salt words ◦ Produces the next 8 chaining words
5. Original Design Fields • int [] digest - also chaining values • int [] currentmessage • final int [] constants • final int [][] permutation table • int makes sense because of the word size Methods hash, rounds, initialize, finalize, digest
6. Original Design Hash Helper methods Rounds initialize Message Bytes finalize 64 Byte Block Write to digest 1 Byte at a time (Pack into current message)
7. Original Design Rounds m <- initialize message for r in 0...13 //14 rounds per message block //four columns then four diagonals for i in 0...3 perform Gi function on column i //using r and i for the permutations for i in 0...3 perform Gi function on diagonal i+4 //using r and i+4 for the permutations finalize (m) //and write to the digest
8. Original Time Measurements TESTS 1 million zero bytes 10 million zero bytes 100 mil. zero bytes rounds 68.2% 107 67.3% 1114 69.2% 10682 initialize 27.4% 43 19.8% 328 18.1% 2801 hash 1.3% 2 3.0% 50 2.9% 445 finalize 0% 0 0.8% 13 0.9% 132 misc 2.2% 5 8.1% 150 9% 1378 TOTAL 1.6 sec 157 16.76 sec 1655 156.24 sec 15438
9. Original Measurement Analysis • Rounds ◦ Takes a majority (average 68%) of code execution time ◦ Major contributors ▪ looping for row, column steps ▪ in-line arithmetic (yields same pattern of values) ▪ indexing operations for our fields
10. Revised design • Unwrapped inner i loops in rounds • Side effect - reduced in-line arithmetic ◦ e.g. - pre: m[1][(g+1)%4] = (m[1][(g+1)%4] ^ m[2][(g+2)%4]) >>> 12; ◦ post: m[1][3] = (m[1][3] ^ m[2][0]) >>> 12; ◦ 64 lines like this executed per round, 14 rounds per message block • Parallelizing caused problems with profiling
11. Revised Time Measurements TESTS 1 million zeros 10 million zeros 100 million zeros rounds 52.7% 78 60.9% 910 70.4% 10312 initialize 37.2% 55 26.6% 398 18.2% 2670 hash 1.4% 2 1.9% 28 1.6% 241 finalize 3.4% 5 1.0% 15 0.6% 91 misc 5.5% 8 9.6% 144 9.1% 1336 TOTAL 1.51 sec 148 15.04 sec 1495 148.34 sec 14650
12. Revised Measurements Analysis • Noticable and consistent time savings ◦ 100 million bytes hashed - 148.34s vs 156.24s. ◦ 10 million bytes hashed - 15.14s vs 16.76s. ◦ 1 million bytes hashed - 1.51s vs 1.60s. • Between 5% and 10% gains for each category.
13. Afterthoughts • Cryptographic primitives can reuse aspects of their predecessors and still be quite strong. • Methods for optimizing algorithms, and how it affects the running time. • Java is not a great platform for fast execution. • Future Work: ◦ Implementations in C and/or FPGA (hardware) for platform advantages and parallelization. ◦ Analysis though NIST test suite and TEST001
14. Questions?