From MAILER-DAEMON Fri Dec 26 13:21:49 2008 Date: 26 Dec 2008 13:21:49 -0800 From: Mail System Internal Data Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA Message-ID: <1230326509@letters.cs.ucsb.edu> X-IMAP: 1217955950 0000000469 NonJunk $Forwarded Status: RO This text is part of the internal format of your mail folder, and is not a real message. It is created automatically by the mail system software. If deleted, important folder data will be lost, and it will be re-created with the data reset to initial values. From hash-forum@nist.gov Tue Aug 5 05:48:34 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m75CmSIi022632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 5 Aug 2008 05:48:30 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m75CjawE017453; Tue, 5 Aug 2008 08:45:38 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m75ChYvm028443; Tue, 5 Aug 2008 08:43:35 -0400 Date: Tue, 5 Aug 2008 08:43:34 -0400 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Larry Bassham To: Multiple recipients of list Subject: Re: Hash StateQuestion X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: <20080707190433.A31C21D65@victory.concentric.com> <962B7847-B94E-4A48-B41F-CCD8ECCE4A63@nist.gov> <20080728014423.992F14EDE@bellona.concentric.com> <5c8fcb9c0807280654g7cd9db50v6ec80848a3197e1a@mail.gmail.com> <5BBAB160-BF75-4D4B-9BA4-55DC7185B2C6@cryptolib.com> <51590d340807281806v1cf6fb31g6199c47809a5865b@mail.gmail.com> <020BDA03-8635-4255-B3D2-F597549DB49E@cryptolib.com> <001301c8f6a8$2b5f8cc0$821ea640$@org> In-Reply-To: <001301c8f6a8$2b5f8cc0$821ea640$@org> Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 05 Aug 2008 05:48:30 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 1 Since its state never changes, I would say no. Larry B. On Aug 4, 2008, at 11:06 PM, John Washburn wrote: > > My algorithm contains a fixed (invariant regardless of message or hash > value) lookup table as part of compression function. > > Is this lookup table to be considered part of the Hash State which is > encoded in the C struct as part of the reference implementation and > thus > included in the definition of the struct? > > > > From hash-forum@nist.gov Mon Aug 4 21:16:05 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m754G0w2011674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 Aug 2008 21:16:01 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m75380QN013865; Mon, 4 Aug 2008 23:08:09 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m7536HHs007368; Mon, 4 Aug 2008 23:06:17 -0400 Date: Mon, 4 Aug 2008 23:06:17 -0400 Message-Id: <001301c8f6a8$2b5f8cc0$821ea640$@org> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "John Washburn" To: Multiple recipients of list Subject: Hash StateQuestion X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Microsoft Office Outlook 12.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" MIME-Version: 1.0 In-Reply-To: <020BDA03-8635-4255-B3D2-F597549DB49E@cryptolib.com> References: <20080707190433.A31C21D65@victory.concentric.com> <962B7847-B94E-4A48-B41F-CCD8ECCE4A63@nist.gov> <20080728014423.992F14EDE@bellona.concentric.com> <5c8fcb9c0807280654g7cd9db50v6ec80848a3197e1a@mail.gmail.com> <5BBAB160-BF75-4D4B-9BA4-55DC7185B2C6@cryptolib.com> <51590d340807281806v1cf6fb31g6199c47809a5865b@mail.gmail.com> <020BDA03-8635-4255-B3D2-F597549DB49E@cryptolib.com> X-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: Delayed for 01:05:07 by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 04 Aug 2008 21:16:01 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 2 My algorithm contains a fixed (invariant regardless of message or hash value) lookup table as part of compression function. Is this lookup table to be considered part of the Hash State which is encoded in the C struct as part of the reference implementation and thus included in the definition of the struct? From hash-forum@nist.gov Sun Jul 27 19:59:41 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m6S2xacL024508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 27 Jul 2008 19:59:37 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m6S1rg7l009014; Sun, 27 Jul 2008 21:53:44 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m6S1oJDP005970; Sun, 27 Jul 2008 21:50:19 -0400 Date: Sun, 27 Jul 2008 21:50:19 -0400 Message-Id: <20080728014423.992F14EDE@bellona.concentric.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Colin B To: Multiple recipients of list Subject: Time Trouble X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 In-Reply-To: <20080707190433.A31C21D65@victory.concentric.com> <962B7847-B94E-4A48-B41F-CCD8ECCE4A63@nist.gov> X-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: Delayed for 01:04:53 by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sun, 27 Jul 2008 19:59:37 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 3 Has anyone figured out how to do the timing measurements for section 2.B.2? The time() and clock() routines in Visual Studio 2005/windows give values in milliseconds and only change every ten milliseconds - that's also elapsed time and not process time. The best I've been able to do is count how many hashes can be done in 10ms using 1000 bits and 1000 bytes of random data. This has to be repeated several times because the system will sometimes go and do other things for a while, reducing the count. Regards, Colin. From hash-forum@nist.gov Sun Jul 27 20:32:06 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m6S3W1RI027512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 27 Jul 2008 20:32:02 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m6S3UOkR017528; Sun, 27 Jul 2008 23:30:35 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m6S3RYL6030205; Sun, 27 Jul 2008 23:27:34 -0400 Date: Sun, 27 Jul 2008 23:27:34 -0400 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: =?WINDOWS-1252?Q?Sean_O=92Neil?= To: Multiple recipients of list Subject: Re: Time Trouble X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: <20080728014423.992F14EDE@bellona.concentric.com> In-Reply-To: <20080728014423.992F14EDE@bellona.concentric.com> Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sun, 27 Jul 2008 20:32:02 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 4 On 28 Jul 2008, at 03:50, Colin B wrote: > Has anyone figured out how to do the timing measurements for > section 2.B.2? The time() and clock() routines in Visual Studio > 2005/windows give values in milliseconds and only change every ten > milliseconds - that's also elapsed time and not process time. The > best I've been able to do is count how many hashes can be done in > 10ms using 1000 bits and 1000 bytes of random data. This has to be > repeated several times because the system will sometimes go and do > other things for a while, reducing the count. You are making a hash function and you've never heard of the clock counter??? Does RDTSC ring a bell? Look it up. unsigned long long _rdtsc(void) {__asm rdtsc} AKA unsigned __int64 _rdtsc(void) {__asm _emit 0x0F __asm _emit 0x31} /me is scratching his head Best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. From hash-forum@nist.gov Mon Jul 28 05:11:57 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m6SCBqi8007115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Jul 2008 05:11:53 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m6SC92JW018602; Mon, 28 Jul 2008 08:10:09 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m6SC7lqE032384; Mon, 28 Jul 2008 08:07:47 -0400 Date: Mon, 28 Jul 2008 08:07:47 -0400 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Doug Whiting To: Multiple recipients of list Subject: RE: Time Trouble X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_E1BEC7FFF6C889489E8C09F722F185CD17C300DAC0SJCXCH07hifnc_" In-Reply-To: <20080728014423.992F14EDE@bellona.concentric.com> References: <20080707190433.A31C21D65@victory.concentric.com> <962B7847-B94E-4A48-B41F-CCD8ECCE4A63@nist.gov>,<20080728014423.992F14EDE@bellona.concentric.com> X-To: "hash-forum@nist.gov" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 28 Jul 2008 05:11:53 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 5 --_000_E1BEC7FFF6C889489E8C09F722F185CD17C300DAC0SJCXCH07hifnc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorry for the earlier empty email. I pushed send by mistake while starting = my message. Yes, it's a real shame that C doesn't have a standard way to do this. Below= is some code that you are free to copy if you wish. I have used variants o= f this function for years, all the way back to AES days, and the code is en= tirely mine, so I hereby release it to the public domain. If you keep readi= ng below, I also give some concrete suggestions on how to use it. This code works on x86 family CPUs (32-big and 64-bit), under MSVC, gcc, an= d BorlandC, including older compiler versions where the __rdtsc() function = is not defined. It also checks for ANSI compiles (i.e., -ansi using gcc, /Z= a using MSVC, and -A using Borland) and disables the call, to avoid compile= -time warnings/errors. The function HiResTime() currently returns only 32 b= its, mostly for historical reasons. However, that's enough to do most timin= g measurements, and you could easily enhance it to return 64 bits if desire= d. I normally compile with multiple compilers -- e.g., three versions of MS= VC (v4.2, v6.0 and v9.0), at least two versions of gcc, plus Borland -- and= take performance measurements on all of them. /************** Timing routine (for performance measurements) ***********/ /* unfortunately, this is generally assembly code and not very portable */ #if defined(_M_IX86) || defined(__i386) || defined(_i386) || defined(__i386= __) || defined(i386) || \ defined(_X86_) || defined(__x86_64__) || defined(_M_X64) || defined(_= _x86_64) #define _Is_X86_ 1 #endif #if defined(_Is_X86_) && (!defined(__STRICT_ANSI__)) && (defined(__GNUC__)= || !defined(__STDC__)) && \ (defined(__BORLANDC__) || defined(_MSC_VER) || defined(__MINGW_H) || de= fined(__GNUC__)) #define HI_RES_CLK_OK 1 /* it's ok to use RDTSC opcode */ #if defined(_MSC_VER) && defined(_M_X64) #include #pragma intrinsic(__rdtsc) /* use MSVC rdtsc call where defined */ #endif #endif uint_32t HiResTime(void) /* return the current value of time stam= p counter */ { #if defined(HI_RES_CLK_OK) uint_32t x[2]; #if defined(__BORLANDC__) #define COMPILER_ID "BCC" __emit__(0x0F,0x31); /* RDTSC instruction */ _asm { mov x[0],eax }; #elif defined(_MSC_VER) #define COMPILER_ID "MSC" #if defined(_MSC_VER) && defined(_M_X64) x[0] =3D (uint_32t) __rdtsc(); #else _asm { _emit 0fh }; _asm { _emit 031h }; _asm { mov x[0],eax }; #endif #elif defined(__MINGW_H) || defined(__GNUC__) #define COMPILER_ID "GCC" asm volatile("rdtsc" : "=3Da"(x[0]), "=3Dd"(x[1])); #else #error "HI_RES_CLK_OK -- but no assembler code for this platform (?)" #endif return x[0]; #else /* avoid annoying MSVC 9.0 compiler warning #4720 in ANSI mode! */ #if (!defined(_MSC_VER)) || (!defined(__STDC__)) || (_MSC_VER < 1300) FatalError("No support for RDTSC on this CPU platform\n"); #endif return 0; #endif /* defined(HI_RES_CLK_OK) */ } +++++++++++++++++++++++++++++++++++++++++++++++++++++++ For example, what I normally do in my timing routines is call this routine = a few times (say 10) and take the minimum difference, to calibrate the over= head, which is usually 50-100 clocks, depending on the compiler. Here's an = example: #define TIMER_SAMPLE_CNT (10) uint_32t dtMin =3D 0xFFFFFFFF; /* big number to start */ uint_32t t0,t1,i; for (i=3D0;i < TIMER_SAMPLE_CNT;i++) /* calibrate the overhead for mea= suring time */ { t0 =3D HiResTime(); t1 =3D HiResTime(); if (dtMin > t1-t0) /* keep only the minimum time */ dtMin =3D t1-t0; } +++++++++++++++++++++++++++++++++++++++++++++++++++++++ Then I call the code to be measured similarly, as follows: uint_32t tMin =3D 0xFFFFFFFF; /* big number to start */ for (i=3D0;i < TIMER_SAMPLE_CNT;i++) /* calibrate the overhead for mea= suring time */ { t0 =3D HiResTime(); RoutineToBeTimed(); /* do the work */ t1 =3D HiResTime(); if (tMin > t1-t0 - dtMin) /* keep only the minimum time */ tMin =3D t1-t0 - dtMin; } /* now tMin =3D # clocks required for running RoutineToBeTimed() */ If possible, you should implement the routine of interest so that it comple= tes in less than, say, 100K clocks. That way, in most cases, there will be = no OS overhead or task switches. Running it several times helps get rid of = such overhead, as occasionally you'll see a huge spike in the time differen= ce due to such a time slice change. If you think about it, the minimum valu= e is almost always what you want, but sometimes I actually give both min an= d median times; although those rarely differ by much, it's often comforting= to make sure. Note that, in VM environments, the rdtsc instruction usually itself gets em= ulated and thus dtMin is thousands of clocks. In those cases, unfortunately= , the results are usually not very repeatable. I don't know of any way arou= nd this problem, so I suggest running your timing measurements in a non-VM = window. I hope this is helpful. I've taken such measurements a lot over the years o= n many different types of algorithms, and this method has proven to be very= reliable. It is particularly nice because the times involved can be quite = short, down to less than 100 clocks -- you don't have to iterate for long p= eriods of time to get a valid measurement. Doug Whiting Chief Scientist, Hifn ________________________________________ From: hash-forum@nist.gov [hash-forum@nist.gov] On Behalf Of Colin B [mesad= esign@colinb.cts.com] Sent: Sunday, July 27, 2008 6:50 PM To: Multiple recipients of list Subject: Time Trouble Has anyone figured out how to do the timing measurements for section 2.B.2?= The time() and clock() routines in Visual Studio 2005/windows give values = in milliseconds and only change every ten milliseconds - that's also elapse= d time and not process time. The best I've been able to do is count how man= y hashes can be done in 10ms using 1000 bits and 1000 bytes of random data.= This has to be repeated several times because the system will sometimes go= and do other things for a while, reducing the count. Regards, Colin. ________________________________ This email message is for the sole use of the intended recipient(s) and may= contain confidential and privileged information which is protected from di= sclosure. Any unauthorized review, use, disclosure or distribution by any m= eans is prohibited. If you are not the intended recipient, please contact t= he sender by reply email or at (408) 399-3500 and destroy all copies of the= original message. --_000_E1BEC7FFF6C889489E8C09F722F185CD17C300DAC0SJCXCH07hifnc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Sorry for the earlier empty email. I pushed send by= mistake while starting my message.

 

Yes, it's a real shame that C doesn't have a standa= rd way to do this. Below is some code that you are free to copy if you wish= I have used variants of this function for years, all the way back to AES = days, and the code is entirely mine, so I hereby release it to the public domain. If you keep reading belo= w, I also give some concrete suggestions on how to use it.

 

This code works on x86 family CPUs (32-big and= 64-bit), under MSVC, gcc, and BorlandC, including older compiler versions = where the __rdtsc() function is not defined. It also checks for ANSI compil= es (i.e., -ansi using gcc, /Za using MSVC, and -A using Borland) and disables the call, to avoid compile-time warning= s/errors. The function HiResTime() currently returns only 32 bits, mostly f= or historical reasons. However, that's enough to do most timing measurement= s, and you could easily enhance it to return 64 bits if desired. I normally compile with multiple compiler= s -- e.g., three versions of MSVC (v4.2, v6.0 and v9.0), at least two = versions of gcc, plus Borland -- and take performance measurements on = all of them.

 

 

/************** Timing routine (for performance measurements) **********= */
/* unfortunately, this is generally assembly code and not very portable */<= br> #if defined(_M_IX86) || defined(__i386) || defined(_i386) || defined(__i386= __) || defined(i386) || \
    defined(_X86_)   || defined(__x86_64__) || def= ined(_M_X64) || defined(__x86_64)
#define _Is_X86_    1
#endif


#if  defined(_Is_X86_) && (!defined(__STRICT_ANSI__)) &&am= p; (defined(__GNUC__) || !defined(__STDC__)) && \
    (defined(__BORLANDC__) || defined(_MSC_VER) || defined(_= _MINGW_H) || defined(__GNUC__))
#define HI_RES_CLK_OK         1&nbs= p;         /* it's ok to use RDTSC = opcode */

#if defined(_MSC_VER) && defined(_M_X64)
#include <intrin.h>
#pragma intrinsic(__rdtsc)        &= nbsp;/* use MSVC rdtsc call where defined */
#endif


#endif

uint_32t HiResTime(void)        =    /* return the current value of time stamp counter */=
    {
#if defined(HI_RES_CLK_OK)
    uint_32t x[2];
#if   defined(__BORLANDC__)
#define COMPILER_ID "BCC"
    __emit__(0x0F,0x31);      =      /* RDTSC instruction */
    _asm { mov x[0],eax };
#elif defined(_MSC_VER)
#define COMPILER_ID "MSC"
#if defined(_MSC_VER) && defined(_M_X64)
    x[0] =3D (uint_32t) __rdtsc();
#else
    _asm { _emit 0fh }; _asm { _emit 031h };
    _asm { mov x[0],eax };
#endif
#elif defined(__MINGW_H) || defined(__GNUC__)
#define COMPILER_ID "GCC"
    asm volatile("rdtsc" : "=3Da"(x[0]),= "=3Dd"(x[1]));
#else
#error  "HI_RES_CLK_OK -- but no assembler code for this platform= (?)"
#endif
    return x[0];
#else
    /* avoid annoying MSVC 9.0 compiler warning #4720 in ANS= I mode! */
#if (!defined(_MSC_VER)) || (!defined(__STDC__)) || (_MSC_VER < 1300)     FatalError("No support for RDTSC on this CPU platfo= rm\n");
#endif
    return 0;
#endif /* defined(HI_RES_CLK_OK) */
    }

+++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;++++++++++++++

 

For example, what I normally do in my timing routin= es is call this routine a few times (say 10) and take the minimum differenc= e, to calibrate the overhead, which is usually 50-100 clocks, depending on = the compiler. Here's an example:

 

#define TIMER_SAMPLE_CNT (10)

 

    uint_32t dtMin =3D 0xFFFFF= FFF;        /* big number to start */

    uint_32t t0,t1,i;

 

    for (i=3D0;i < TIMER_SAMPLE_CNT;i++) = /* calibrate the overhead for measuring time */
        {
        t0 =3D HiResTime();
        t1 =3D HiResTime();
        if (dtMin > t1-t0)  = ;            /* keep= only the minimum time */
            dtMin = =3D t1-t0;
        }

 

++++++++++&= #43;++++++++++++++&= #43;++++++++++++++&= #43;++++++++++++++<= /font>

 

Then I call the code to be measured similarly, as f= ollows:

 

    uint_32t tMin =3D 0xF= FFFFFFF;         /* big number to s= tart */

    for (i=3D0;i < TIMER_SA= MPLE_CNT;i++)  /* calibrate the overhead for measuring time */=
        {
        t0 =3D HiResTime();

   =      RoutineToBeTimed();    &n= bsp;        /* do the work */
        t1 =3D HiResTime();
        if (tMin > t1-t0 - dtMin)&nbs= p;      /* keep only the minimum time */
            tMin =3D= t1-t0 - dtMin;
        }

    /* now tMin =3D # clo= cks required for running RoutineToBeTimed() */

 

If possible, you should implement the routine of in= terest so that it completes in less than, say, 100K clocks. That way, in mo= st cases, there will be no OS overhead or task switches. Running it several= times helps get rid of such overhead, as occasionally you'll see a huge spike in the time difference du= e to such a time slice change. If you think about it, the minimum value is = almost always what you want, but sometimes I actually give both min and med= ian times; although those rarely differ by much, it's often comforting to make sure.

 

Note that, in VM environments, the rdtsc instructio= n usually itself gets emulated and thus dtMin is thousands of clocks. = In those cases, unfortunately, the results are usually not very repeat= able. I don't know of any way around this problem, so I suggest running your timing measurements in a non-VM window.

 

I hope this is helpful. I've taken such measurement= s a lot over the years on many different types of algorithms, and this meth= od has proven to be very reliable. It is particularly nice because the time= s involved can be quite short, down to less than 100 clocks -- you don't have to iterate for long periods of t= ime to get a valid measurement.

 

Doug Whiting

Chief Scientist, Hifn

________________________________________
From: hash-forum@nist.gov [hash-forum@nist.gov] On Behalf Of Colin B [mesad= esign@colinb.cts.com]
Sent: Sunday, July 27, 2008 6:50 PM
To: Multiple recipients of list
Subject: Time Trouble

Has anyone figured out how to do the timing measurements for section 2.B.2?= The time() and clock() routines in Visual Studio 2005/windows give values = in milliseconds and only change every ten milliseconds - that's also elapse= d time and not process time. The best I've been able to do is count how many hashes can be done in 10ms usi= ng 1000 bits and 1000 bytes of random data. This has to be repeated several= times because the system will sometimes go and do other things for a while= , reducing the count.

Regards, Colin.


This email message is for = the sole use of the intended recipient(s) and may contain confidential and = privileged information which is protected from disclosure. Any unauthorized= review, use, disclosure or distribution by any means is prohibited. If you are not the intended recipient, please = contact the sender by reply email or at (408) 399-3500 and destroy all copi= es of the original message.
 --_000_E1BEC7FFF6C889489E8C09F722F185CD17C300DAC0SJCXCH07hifnc_-- From hash-forum@nist.gov Mon Jul 28 07:05:40 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m6SE5ZYp030957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Jul 2008 07:05:36 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m6SE2YqV020571; Mon, 28 Jul 2008 10:02:43 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m6SE155Y007335; Mon, 28 Jul 2008 10:01:05 -0400 Date: Mon, 28 Jul 2008 10:01:05 -0400 Message-Id: <5c8fcb9c0807280654g7cd9db50v6ec80848a3197e1a@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "mheyman@gmail.com" To: Multiple recipients of list Subject: Re: Time Trouble X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <20080707190433.A31C21D65@victory.concentric.com> <962B7847-B94E-4A48-B41F-CCD8ECCE4A63@nist.gov> <20080728014423.992F14EDE@bellona.concentric.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 In-Reply-To: X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 28 Jul 2008 07:05:36 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 6 A bit of advice from my experience trying to test the performance of functions: Unfortunately, rdtsc only works on older processors with only one core (I have read that some CPUs with multiple cores will work but I have never used one). The main issue is that the cores typically end up with different counter values because one core may sleep for a bit while the other keeps running. Meanwhile, your code can bounce between cores so different readings of the counter. Windows provides OS support to help ameliorate this with QueryPerformanceCounter() which is supposed to work over multiple cores but I have found this to be inaccurate as well (sometimes returning values that say the function finishes before it started). If you must run on a multitasking operating system that knows about multiple cores, the best I have been able to come up with is to run many trials (20-1000, you will need more trials for longer running functions), and print out or plot out the timing results. You will see clusters of results depending on the number of cores you have. For example, if you have 2 cores, you will see three clusters - one for when the two counter queries occurred on the same core, one for the early core --> late core bounce, and one for the late core --> early core bounce. Depending on how long your test runs, these clusters will smear because other processes took a time slice and you will need more trials to be sure you get a clean run with no OS interference. The values may also smear because the first test runs on a cold cache. The fastest time in the middle cluster is the closest thing to a good timing value you can get. I have verified this by running the same simple test on Windows and FreeDOS on a dual core AMD processor. The clusters may not be well defined enough to clearly separate them. In this case just wait a bit and try again and hope the CPU counters have become more separate. If somebody knows a way to get valid timing results while running in a virtual machine, I'd love to hear it. I now have a quad core processor as my main machine but, luckily, I have not actually had to do timing tests on it. -Michael Heyman From hash-forum@nist.gov Mon Jul 28 08:30:09 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m6SFU2tJ018581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Jul 2008 08:30:03 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m6SFRQ46005565; Mon, 28 Jul 2008 11:27:31 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m6SFR9Bi019731; Mon, 28 Jul 2008 11:27:09 -0400 Date: Mon, 28 Jul 2008 11:27:09 -0400 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Brian Gladman" To: Multiple recipients of list Subject: Re: Time Trouble X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Microsoft Windows Mail 6.0.6001.18000 Content-Transfer-Encoding: 7bit Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original MIME-Version: 1.0 In-Reply-To: <5c8fcb9c0807280654g7cd9db50v6ec80848a3197e1a@mail.gmail.com> References: <20080707190433.A31C21D65@victory.concentric.com> <962B7847-B94E-4A48-B41F-CCD8ECCE4A63@nist.gov> <20080728014423.992F14EDE@bellona.concentric.com> <5c8fcb9c0807280654g7cd9db50v6ec80848a3197e1a@mail.gmail.com> X-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 28 Jul 2008 08:30:04 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, STOX_REPLY_TYPE shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 7 ----- Original Message ----- From: To: "Multiple recipients of list" Sent: Monday, July 28, 2008 3:01 PM Subject: Re: Time Trouble > > A bit of advice from my experience trying to test the performance of > functions: > > Unfortunately, rdtsc only works on older processors with only one core > (I have read that some CPUs with multiple cores will work but I have > never used one). The main issue is that the cores typically end up > with different counter values because one core may sleep for a bit > while the other keeps running. Meanwhile, your code can bounce between > cores so different readings of the counter. > > Windows provides OS support to help ameliorate this with > QueryPerformanceCounter() which is supposed to work over multiple > cores but I have found this to be inaccurate as well (sometimes > returning values that say the function finishes before it started). I have found the following code at the start of a timing routine to be reliable for timing on multiple core machines running Windows It works by forcing the OS to run the process only on the core that it starts on. ------------------------------------------------------ // we need to constrain the process to one core in order to // obtain meaningful timing data HANDLE ph; DWORD_PTR afp; DWORD_PTR afs; ph = GetCurrentProcess(); if(GetProcessAffinityMask(ph, &afp, &afs)) { afp &= (1 << GetCurrentProcessorNumber()); if(!SetProcessAffinityMask(ph, afp)) { printf("Couldn't set Process Affinity Mask\n\n"); return -1; } } else { printf("Couldn't get Process Affinity Mask\n\n"); return -1; } ------------------------------------------------------ Brian Gladman From hash-forum@nist.gov Mon Jul 28 08:30:11 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m6SFU5b9018630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Jul 2008 08:30:07 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m6SFRQ4E005565; Mon, 28 Jul 2008 11:27:33 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m6SFRJwI019775; Mon, 28 Jul 2008 11:27:19 -0400 Date: Mon, 28 Jul 2008 11:27:19 -0400 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Doug Whiting To: Multiple recipients of list Subject: RE: Time Trouble X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" In-Reply-To: <5c8fcb9c0807280654g7cd9db50v6ec80848a3197e1a@mail.gmail.com> References: <20080707190433.A31C21D65@victory.concentric.com> <962B7847-B94E-4A48-B41F-CCD8ECCE4A63@nist.gov> <20080728014423.992F14EDE@bellona.concentric.com> ,<5c8fcb9c0807280654g7cd9db50v6ec80848a3197e1a@mail.gmail.com> X-To: "hash-forum@nist.gov" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 28 Jul 2008 08:30:07 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 8 Agreed, but if your test is quick enough (say < 100K clks, which is enough for most reasonable hash function parameters), no task switch will occur in general. That's why my code uses only the min value (and the median as a sanity check). The shorter the test, the more reliable the result. ________________________________________ From: hash-forum@nist.gov [hash-forum@nist.gov] On Behalf Of mheyman@gmail.com [mheyman@gmail.com] Sent: Monday, July 28, 2008 7:01 AM To: Multiple recipients of list Subject: Re: Time Trouble A bit of advice from my experience trying to test the performance of functions: Unfortunately, rdtsc only works on older processors with only one core (I have read that some CPUs with multiple cores will work but I have never used one). The main issue is that the cores typically end up with different counter values because one core may sleep for a bit while the other keeps running. Meanwhile, your code can bounce between cores so different readings of the counter. Windows provides OS support to help ameliorate this with QueryPerformanceCounter() which is supposed to work over multiple cores but I have found this to be inaccurate as well (sometimes returning values that say the function finishes before it started). If you must run on a multitasking operating system that knows about multiple cores, the best I have been able to come up with is to run many trials (20-1000, you will need more trials for longer running functions), and print out or plot out the timing results. You will see clusters of results depending on the number of cores you have. For example, if you have 2 cores, you will see three clusters - one for when the two counter queries occurred on the same core, one for the early core --> late core bounce, and one for the late core --> early core bounce. Depending on how long your test runs, these clusters will smear because other processes took a time slice and you will need more trials to be sure you get a clean run with no OS interference. The values may also smear because the first test runs on a cold cache. The fastest time in the middle cluster is the closest thing to a good timing value you can get. I have verified this by running the same simple test on Windows and FreeDOS on a dual core AMD processor. The clusters may not be well defined enough to clearly separate them. In this case just wait a bit and try again and hope the CPU counters have become more separate. If somebody knows a way to get valid timing results while running in a virtual machine, I'd love to hear it. I now have a quad core processor as my main machine but, luckily, I have not actually had to do timing tests on it. -Michael Heyman This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information which is protected from disclosure. Any unauthorized review, use, disclosure or distribution by any means is prohibited. If you are not the intended recipient, please contact the sender by reply email or at (408) 399-3500 and destroy all copies of the original message. From hash-forum@nist.gov Mon Jul 28 08:57:48 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m6SFvfRj025668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Jul 2008 08:57:42 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m6SFtRhl027343; Mon, 28 Jul 2008 11:55:32 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m6SFt4Qa010059; Mon, 28 Jul 2008 11:55:04 -0400 Date: Mon, 28 Jul 2008 11:55:04 -0400 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: zooko To: Multiple recipients of list Subject: Re: Time Trouble X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: <20080707190433.A31C21D65@victory.concentric.com> <962B7847-B94E-4A48-B41F-CCD8ECCE4A63@nist.gov> <20080728014423.992F14EDE@bellona.concentric.com> <5c8fcb9c0807280654g7cd9db50v6ec80848a3197e1a@mail.gmail.com> In-Reply-To: <5c8fcb9c0807280654g7cd9db50v6ec80848a3197e1a@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 28 Jul 2008 08:57:42 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 9 On Jul 28, 2008, at 8:01 AM, mheyman@gmail.com wrote: > Windows provides OS support to help ameliorate this with > QueryPerformanceCounter() which is supposed to work over multiple > cores but I have found this to be inaccurate as well (sometimes > returning values that say the function finishes before it started). This is because it returns a 32-bit value (unsigned) and wraps around. As long as the only thing you do with it is subtract the latter from the earlier, and as long as the operation you are measuring takes less than 2^32 counts, then you won't get the wrong answer due to the wrap-around. However, you can get the wrong answer due to slew between CPUs, which is apparently dependent on your BIOS and HAL: http://msdn.microsoft.com/en-us/library/ms644904(VS.85).aspx DJB's infrastructure for timing stream ciphers is very good because it exposes a lot of issues which are typically overlooked in benchmarks, and which can be the most important performance issues in some use cases. Please see the graphs and source code here: http://cr.yp.to/streamciphers/timings.html (DJB's timing system presumably doesn't work on Windows, but this should not deter people from using it. Just boot an Ubuntu live cd or something.) Regards, Zooko From hash-forum@nist.gov Mon Jul 28 13:22:56 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m6SKMpWR001158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Jul 2008 13:22:52 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m6SKK7GC008417; Mon, 28 Jul 2008 16:20:13 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m6SKIEHA015743; Mon, 28 Jul 2008 16:18:14 -0400 Date: Mon, 28 Jul 2008 16:18:14 -0400 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Larry Bassham To: Multiple recipients of list Subject: NIST Statistical Test Suite X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 28 Jul 2008 13:22:53 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 10 I wanted to let everyone on the hash-forum list know that there is a new version of the NIST Statistical Test Suite (version 2.0) available. The changes are basically to simplify the package a bit. There is one version that has been tested to function correctly on Windows XP, Mac OS X, and Ubuntu Linux (all on x86 processors). The Windows specific GUI has been removed. The tests are all the same as the previous version. The will be a revision of the documentation to follow, but the existing document will provide accurate descriptions of the tests. Larry B. From hash-forum@nist.gov Mon Jul 28 14:04:54 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m6SL4nVZ010504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Jul 2008 14:04:50 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m6SL23Z4013932; Mon, 28 Jul 2008 17:02:14 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m6SL1cR1006745; Mon, 28 Jul 2008 17:01:38 -0400 Date: Mon, 28 Jul 2008 17:01:38 -0400 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Doug Whiting To: Multiple recipients of list Subject: RE: Time Trouble X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" In-Reply-To: References: <20080707190433.A31C21D65@victory.concentric.com> <962B7847-B94E-4A48-B41F-CCD8ECCE4A63@nist.gov> <20080728014423.992F14EDE@bellona.concentric.com> <5c8fcb9c0807280654g7cd9db50v6ec80848a3197e1a@mail.gmail.com> X-To: "hash-forum@nist.gov" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 28 Jul 2008 14:04:50 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 11 How do you detect the presence of Vista at run-time, so that my code can be tested on XP systems as well? I can't find it in the documentation, so I'm hoping you just know this off the top of your head. Thanks! Doug > -----Original Message----- > From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of > Brian Gladman > Sent: Monday, July 28, 2008 8:27 AM > To: Multiple recipients of list > Subject: Re: Time Trouble > > > ----- Original Message ----- > From: > To: "Multiple recipients of list" > Sent: Monday, July 28, 2008 3:01 PM > Subject: Re: Time Trouble > > > > > > A bit of advice from my experience trying to test the performance of > > functions: > > > > Unfortunately, rdtsc only works on older processors with only one > core > > (I have read that some CPUs with multiple cores will work but I have > > never used one). The main issue is that the cores typically end up > > with different counter values because one core may sleep for a bit > > while the other keeps running. Meanwhile, your code can bounce > between > > cores so different readings of the counter. > > > > Windows provides OS support to help ameliorate this with > > QueryPerformanceCounter() which is supposed to work over multiple > > cores but I have found this to be inaccurate as well (sometimes > > returning values that say the function finishes before it started). > > I have found the following code at the start of a timing routine to be > reliable for timing on multiple core machines running Windows > > It works by forcing the OS to run the process only on the core that it > starts on. > > ------------------------------------------------------ > // we need to constrain the process to one core in order to > // obtain meaningful timing data > HANDLE ph; > DWORD_PTR afp; > DWORD_PTR afs; > ph = GetCurrentProcess(); > if(GetProcessAffinityMask(ph, &afp, &afs)) > { > afp &= (1 << GetCurrentProcessorNumber()); > if(!SetProcessAffinityMask(ph, afp)) > { > printf("Couldn't set Process Affinity Mask\n\n"); return - > 1; > } > } > else > { > printf("Couldn't get Process Affinity Mask\n\n"); return -1; > } > ------------------------------------------------------ > > Brian Gladman > > This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information which is protected from disclosure. Any unauthorized review, use, disclosure or distribution by any means is prohibited. If you are not the intended recipient, please contact the sender by reply email or at (408) 399-3500 and destroy all copies of the original message. From hash-forum@nist.gov Mon Jul 28 14:18:45 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m6SLIdt5013156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Jul 2008 14:18:40 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m6SLGIYn018729; Mon, 28 Jul 2008 17:16:26 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m6SLFdfi001724; Mon, 28 Jul 2008 17:15:39 -0400 Date: Mon, 28 Jul 2008 17:15:39 -0400 Message-Id: <5BBAB160-BF75-4D4B-9BA4-55DC7185B2C6@cryptolib.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: =?WINDOWS-1252?Q?Sean_O=92Neil?= To: Multiple recipients of list Subject: Re: Time Trouble X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: <20080707190433.A31C21D65@victory.concentric.com> <962B7847-B94E-4A48-B41F-CCD8ECCE4A63@nist.gov> <20080728014423.992F14EDE@bellona.concentric.com> <5c8fcb9c0807280654g7cd9db50v6ec80848a3197e1a@mail.gmail.com> In-Reply-To: <5c8fcb9c0807280654g7cd9db50v6ec80848a3197e1a@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 28 Jul 2008 14:18:40 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 12 > If somebody knows a way to get valid timing results while running in a > virtual machine, I'd love to hear it. RDTSC emulation in VMWare can be disabled by setting monitor_control.virtual_rdtsc = false in the vmx file and Parallels Desktop does not emulate it at all. I hope it helps. Best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. From hash-forum@nist.gov Mon Jul 28 18:19:33 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m6T1JQkq024522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Jul 2008 18:19:29 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m6T1GriE030986; Mon, 28 Jul 2008 21:16:56 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m6T1FjOv005408; Mon, 28 Jul 2008 21:15:45 -0400 Date: Mon, 28 Jul 2008 21:15:45 -0400 Message-Id: <51590d340807281806v1cf6fb31g6199c47809a5865b@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "geoffrey park" To: Multiple recipients of list Subject: Re: Time Trouble X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <20080707190433.A31C21D65@victory.concentric.com> <962B7847-B94E-4A48-B41F-CCD8ECCE4A63@nist.gov> <20080728014423.992F14EDE@bellona.concentric.com> <5c8fcb9c0807280654g7cd9db50v6ec80848a3197e1a@mail.gmail.com> <5BBAB160-BF75-4D4B-9BA4-55DC7185B2C6@cryptolib.com> Content-Type: multipart/alternative; boundary="----=_Part_24100_15966533.1217293619562" MIME-Version: 1.0 In-Reply-To: <5BBAB160-BF75-4D4B-9BA4-55DC7185B2C6@cryptolib.com> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 28 Jul 2008 18:19:29 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 13 ------=_Part_24100_15966533.1217293619562 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Just a quick note about RDTSC on modern multicore processors - You need to be aware that many systems have variable clocks - notebooks in particular will typically slow the clock when the system is idle to save power. Some systems with several cores can halt or slow cores independantly. If your calibration is done before the chipset detects the CPU demand and speeds up, your test results may be completely incorrect. Also, after a task switch on a multicore system, your thread may wake up on a different processor, with a different performance counter, which you cannot assume is in sync with the first one. Windows QueryPerformanceCounter is supposed to deal with some of these issues, but I'm not sure how reliable it is either. The suggestion in the thread above, to measure short tests, under 10 ms (min Windows task switch) is good advice. Do this many times, toss out anomolous high times (probably due to task switch) and average. If you are just tuning an algorithm for speed, consider using VTune (works with Intel cpus, costs money) or Code Analyst (AMD, free). -Geoff Park On Mon, Jul 28, 2008 at 5:15 PM, Sean O'Neil wrote: > > If somebody knows a way to get valid timing results while running in a >> virtual machine, I'd love to hear it. >> > > RDTSC emulation in VMWare can be disabled by setting > monitor_control.virtual_rdtsc = false in the vmx file and Parallels Desktop > does not emulate it at all. I hope it helps. > > > Best regards, > Sean O'Neil > http://www.enrupt.com/ - Raising the bar. > > > ------=_Part_24100_15966533.1217293619562 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Just a quick note about RDTSC on modern multicore processors - You need to be aware that many systems have variable clocks - notebooks in particular will typically slow the clock when the system is idle to save power. Some systems with several cores can halt or slow cores independantly.
 
If your calibration is done before the chipset detects the CPU demand and speeds up, your test results may be  completely incorrect. Also, after a task switch on a multicore system, your thread may wake up on a different processor, with a different performance counter, which you cannot assume is in sync with the first one.
 
Windows QueryPerformanceCounter is supposed to deal with some of these issues, but I'm not sure how reliable it is either.
 
The suggestion in the thread above, to measure short tests, under 10 ms (min Windows task switch) is good advice.  Do this many times, toss out anomolous high times (probably due to task switch) and average.
 
If you are just tuning an algorithm for speed, consider using VTune (works with Intel cpus, costs money) or Code Analyst (AMD, free).
 
-Geoff Park

 
On Mon, Jul 28, 2008 at 5:15 PM, Sean O'Neil <sean@cryptolib.com> wrote:

If somebody knows a way to get valid timing results while running in a
virtual machine, I'd love to hear it.

RDTSC emulation in VMWare can be disabled by setting monitor_control.virtual_rdtsc = false in the vmx file and Parallels Desktop does not emulate it at all. I hope it helps.


Best regards,
Sean O'Neil
http://www.enrupt.com/ - Raising the bar.



------=_Part_24100_15966533.1217293619562-- From hash-forum@nist.gov Tue Jul 29 06:12:32 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m6TDCRpZ014427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 29 Jul 2008 06:12:28 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m6TD9V2P024408; Tue, 29 Jul 2008 09:09:39 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m6TD8o8E003763; Tue, 29 Jul 2008 09:08:50 -0400 Date: Tue, 29 Jul 2008 09:08:50 -0400 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Larry Bassham To: Multiple recipients of list Subject: Re: NIST Statistical Test Suite X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 29 Jul 2008 06:12:28 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 14 The web page for the RNG Statistical Test Suite is below. http://csrc.nist.gov/groups/ST/toolkit/rng/index.html Larry B. On Jul 29, 2008, at 7:57 AM, Karan, Cem (Civ, ARL/CISD) wrote: > Can you give us a link? > > Thanks, > Cem Karan > > -----Original Message----- > From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of > Larry Bassham > Sent: Monday, July 28, 2008 4:18 PM > To: Multiple recipients of list > Subject: NIST Statistical Test Suite > > > > I wanted to let everyone on the hash-forum list know that there is > a new version of the NIST Statistical Test Suite (version 2.0) > available. The changes are basically to simplify the package a bit. > There is one version that has been tested to function correctly on > Windows XP, Mac OS X, and Ubuntu Linux (all on x86 processors). > The Windows specific GUI has been removed. > The tests are all the same as the previous version. > > The will be a revision of the documentation to follow, but the > existing document will provide accurate descriptions of the tests. > > Larry B. > From hash-forum@nist.gov Tue Jul 29 06:26:52 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m6TDQlYd016436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 29 Jul 2008 06:26:48 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m6TDNdiD003288; Tue, 29 Jul 2008 09:23:44 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m6TDNShL001587; Tue, 29 Jul 2008 09:23:28 -0400 Date: Tue, 29 Jul 2008 09:23:28 -0400 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: =?WINDOWS-1252?Q?Sean_O=92Neil?= To: Multiple recipients of list Subject: Re: Time Trouble X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: <20080707190433.A31C21D65@victory.concentric.com> <962B7847-B94E-4A48-B41F-CCD8ECCE4A63@nist.gov> <20080728014423.992F14EDE@bellona.concentric.com> ,<5c8fcb9c0807280654g7cd9db50v6ec80848a3197e1a@mail.gmail.com> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 29 Jul 2008 06:26:48 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 15 On 28 Jul 2008, at 17:27, Doug Whiting wrote: > Agreed, but if your test is quick enough (say < 100K clks, which is > enough for most reasonable hash function parameters), no task > switch will occur in general. That's why my code uses only the min > value (and the median as a sanity check). The shorter the test, the > more reliable the result. From my own experience measuring speed of all kinds of functions since RDTSC was first added to the Intel processors, the minimal value is the most correct one and the easiest one to measure. It is usually returned either 100% or 3/4 or the lowest i've seen 2/3 of the time, with the remaining 1/3 or 1/4 being the next one or few up [every RDTSC value in Core 2 Duo is a multiple of 13 clock cycles], with a very small percentage of random fluctuations, IRQ interrupts and task switches that only contribute garbage to the median value [a good source of entropy though]. The most precise way to measure speed of your function is to count every sane value returned [easy to do with a small table], throw away everything below 3% and print out the remaining top 2-3 with their adjusted frequencies. The minimal value is somehow always on top. Only the algorithms that use very large tables that do not fit in cache will have a very nasty distribution of clock cycle values, but I doubt that we will have a single function of that kind here. Another side-effect of the modern CPUs to watch out for is the speed's dependency on the location in memory, especially for all the inlined functions. It can cause severe biases regardless of their speeds or the number of iterations. On 28 Jul 2008, at 14:07, Doug Whiting wrote: > for (i=0;i < TIMER_SAMPLE_CNT;i++) /* calibrate the overhead > for measuring time */ > { > t0 = HiResTime(); EmptyFunctionCall(); // is missing here > t1 = HiResTime(); > if (dtMin > t1-t0) /* keep only the minimum > time */ > dtMin = t1-t0; > } Best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. From hash-forum@nist.gov Tue Jul 29 06:40:36 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m6TDeURB018805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 29 Jul 2008 06:40:32 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m6TDbsZM005257; Tue, 29 Jul 2008 09:38:00 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m6TDbXUE029750; Tue, 29 Jul 2008 09:37:33 -0400 Date: Tue, 29 Jul 2008 09:37:33 -0400 Message-Id: <020BDA03-8635-4255-B3D2-F597549DB49E@cryptolib.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: =?WINDOWS-1252?Q?Sean_O=92Neil?= To: Multiple recipients of list Subject: Re: Time Trouble X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: <20080707190433.A31C21D65@victory.concentric.com> <962B7847-B94E-4A48-B41F-CCD8ECCE4A63@nist.gov> <20080728014423.992F14EDE@bellona.concentric.com> <5c8fcb9c0807280654g7cd9db50v6ec80848a3197e1a@mail.gmail.com> <5BBAB160-BF75-4D4B-9BA4-55DC7185B2C6@cryptolib.com> <51590d340807281806v1cf6fb31g6199c47809a5865b@mail.gmail.com> In-Reply-To: <51590d340807281806v1cf6fb31g6199c47809a5865b@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 29 Jul 2008 06:40:32 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 16 On 29 Jul 2008, at 03:15, geoffrey park wrote: > Just a quick note about RDTSC on modern multicore processors - You > need to be aware that many systems have variable clocks - notebooks > in particular will typically slow the clock when the system is idle > to save power. Some systems with several cores can halt or slow > cores independantly. Faster or slower, it will not affect the measurement. > If your calibration is done before the chipset detects the CPU > demand and speeds up, your test results may be completely > incorrect. Also, after a task switch on a multicore system, your > thread may wake up on a different processor, with a different > performance counter, which you cannot assume is in sync with the > first one. That is why the sanity check. We only test fast functions with sane (<100K clocks) execution times. There should be no task switches or processor switches during their operation, only occasional hardware interrupts that add a few thousand clock cycles. > Windows QueryPerformanceCounter is supposed to deal with some of > these issues, but I'm not sure how reliable it is either. It is practically useless for our purpose. I also forgot to mention that it is also essential to measure processing of random inputs, not the same input many times. Best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. From koc@letters.cs.ucsb.edu Fri Aug 1 01:44:35 2008 +0300 Delivered-To: cetinkoc@gmail.com Received: by 10.210.104.6 with SMTP id b6cs33282ebc; Thu, 31 Jul 2008 15:52:40 -0700 (PDT) Received: by 10.114.178.13 with SMTP id a13mr10814584waf.158.1217544758640; Thu, 31 Jul 2008 15:52:38 -0700 (PDT) Return-Path: Received: from outbound-mail-253.bluehost.com (outbound-mail-253.bluehost.com [74.220.219.251]) by mx.google.com with SMTP id m40si580773wag.50.2008.07.31.15.52.37; Thu, 31 Jul 2008 15:52:38 -0700 (PDT) Received-SPF: neutral (google.com: 74.220.219.251 is neither permitted nor denied by best guess record for domain of benji@cs.ucsb.edu) client-ip=74.220.219.251; Authentication-Results: mx.google.com; spf=neutral (google.com: 74.220.219.251 is neither permitted nor denied by best guess record for domain of benji@cs.ucsb.edu) smtp.mail=benji@cs.ucsb.edu Received: (qmail 28963 invoked by uid 0); 31 Jul 2008 22:52:35 -0000 Received: from unknown (HELO host132.hostmonster.com) (74.220.207.132) by forwardproxy2.bluehost.com with SMTP; 31 Jul 2008 22:52:34 -0000 Received: from stamps.cs.ucsb.edu ([128.111.41.14]) by host132.hostmonster.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1KOh0c-0006J8-OW for koc@cryptocode.net; Thu, 31 Jul 2008 16:52:34 -0600 Received: from [192.168.1.86] (armadillo.cs.ucsb.edu [128.111.41.107]) (authenticated bits=0) by stamps.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m6VMqWfZ011986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 31 Jul 2008 15:52:33 -0700 Message-ID: <48924053.1040205@cs.ucsb.edu> Date: Thu, 31 Jul 2008 15:44:35 -0700 From: Benji Dunson User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Cetin Kaya Koc Subject: 290 Fall 08 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0a6 (stamps.cs.ucsb.edu [128.111.41.14]); Thu, 31 Jul 2008 15:52:33 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on stamps X-Virus-Status: Clean X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on stamps.cs.ucsb.edu X-user: ::::128.111.41.14:host132.hostmonster.com:::::: Status: RO X-Status: A X-Keywords: X-UID: 17 Hi Cetin, Can you please provide me with the title, description and class website of your 290 in the Fall. I also need to know if the course counts for Systems, Applications or Foundations for the MS students. I hope all is well! Benji -- Benji Dunson Undergraduate Advisor Computer Science University of California, Santa Barbara Santa Barbara, CA 93106 (805) 893-4321 ph (805) 893-8553 fax benji@cs.ucsb.edu From hash-forum@nist.gov Tue Aug 5 19:06:47 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m7626gfd012132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 5 Aug 2008 19:06:43 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m7614KbC025266; Tue, 5 Aug 2008 21:04:22 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m7612iVw014631; Tue, 5 Aug 2008 21:02:45 -0400 Date: Tue, 5 Aug 2008 21:02:44 -0400 Message-Id: <002401c8f75e$3dd0f4f0$b972ded0$@org> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "John Washburn" To: Multiple recipients of list Subject: RE: Hash StateQuestion X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Microsoft Office Outlook 12.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 In-Reply-To: References: <20080707190433.A31C21D65@victory.concentric.com> <962B7847-B94E-4A48-B41F-CCD8ECCE4A63@nist.gov> <20080728014423.992F14EDE@bellona.concentric.com> <5c8fcb9c0807280654g7cd9db50v6ec80848a3197e1a@mail.gmail.com> <5BBAB160-BF75-4D4B-9BA4-55DC7185B2C6@cryptolib.com> <51590d340807281806v1cf6fb31g6199c47809a5865b@mail.gmail.com> <020BDA03-8635-4255-B3D2-F597549DB49E@cryptolib.com> <001301c8f6a8$2b5f8cc0$821ea640$@org> X-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 05 Aug 2008 19:06:43 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 18 I thought not, but it is best to make sure. -----Original Message----- From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Larry Bassham Sent: Tuesday, August 05, 2008 7:44 AM To: Multiple recipients of list Subject: Re: Hash StateQuestion Since its state never changes, I would say no. Larry B. On Aug 4, 2008, at 11:06 PM, John Washburn wrote: > > My algorithm contains a fixed (invariant regardless of message or hash > value) lookup table as part of compression function. > > Is this lookup table to be considered part of the Hash State which is > encoded in the C struct as part of the reference implementation and > thus > included in the definition of the struct? > > > > No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.5.12/1592 - Release Date: 8/5/2008 6:03 AM From hash-forum@nist.gov Thu Aug 28 12:11:45 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m7SJBddA021910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 28 Aug 2008 12:11:40 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m7SHxpcK003011; Thu, 28 Aug 2008 13:59:59 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m7SHxh0H012021; Thu, 28 Aug 2008 13:59:43 -0400 Date: Thu, 28 Aug 2008 13:59:43 -0400 Message-Id: <7.0.1.0.2.20080828134335.02327e90@nist.gov> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Shu-jen Chang To: Multiple recipients of list Subject: Fwd: Long message attacks and randomized hashing (& NIST Correction) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/mixed; boundary="=====================_10472906==_" Mime-Version: 1.0 X-To: hash-forum@nist.gov X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 28 Aug 2008 12:11:41 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 19 --=====================_10472906==_ Content-Type: text/html; charset="us-ascii" FYI - a correction to the security requirements in Section 4.A.ii Bullet 3. The attached correction will also be posted on our web site at http://csrc.nist.gov/groups/ST/hash/federal_register.html .

Regards,
Shu-jen


X-Sieve: CMU Sieve 2.3
Date: Thu, 28 Aug 2008 13:25:20 -0400
From: "John Kelsey" <john.kelsey@nist.gov>
To: hash-function@nist.gov
Subject: Long message attacks and randomized hashing
User-Agent: Internet Messaging Program (IMP) H3 (4.2)
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: john.kelsey@nist.gov
X-NIST-MailScanner-Information:

Everyone,

Shoichi Hirose pointed out a minor error in our call for algorithms, 
involving the resistance of (optional) randomized hashing modes to 
second-preimage attacks.  We ignored the long-message second preimage 
attack in these requirements.

The text should be corrected as follows:

/////

4.A.ii Bullet 3 should have stated:

      If a construct is specified for the use of the candidate 
algorithm in an n-bit randomized hashing scheme, the construct must, 
with overwhelming probability, provide n-k bits of security against 
the following attack: The attacker chooses a message, M1 of length at 
most 2k bits. The specified construct is then used on M1 with a 
randomization value r1 that has been randomly chosen without the 
attacker's control after the attacker has supplied M1. Given r1, the 
attacker then attempts to find a second message M2 and
randomization value r2 that yield the same randomized hash value. Note 
that in order to meet this specific security requirement, the 
specified randomized hashing construct may place restrictions on the 
length of the randomization value.

/////

I don't expect this change to affect any submissions, since it 
slightly relaxes requirements on an optional thing submitters may do, 
decreasing the vulnerability of the optional randomized hashing 
construction to an entirely academic attack.  (However, I'm a little 
embarrassed to have missed the omission, all things considered.)

Thanks,

--John Kelsey, NIST
--=====================_10472906==_ Content-Type: application/octet-stream; name="Correction to the security requirements.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Correction to the security requirements.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAMAAAAAAAAAAA EAAAMgAAAAEAAAD+////AAAAAC8AAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAJWAJBAAA8BK/AAAAAAAAEAAAAAAABgAAGAsAAA4AYmpiaq71rvUAAAAAAAAAAAAAAAAAAAAA AAAJBBYALhIAAMyfAADMnwAAGAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAKQAAAAAAKgDAAAAAAAAqAMAAKgD AAAAAAAAqAMAAAAAAACoAwAAAAAAAKgDAAAAAAAAqAMAABQAAAAAAAAAAAAAALwDAAAAAAAAZAQA AAAAAABkBAAAAAAAAGQEAAAAAAAAZAQAAAwAAABwBAAADAAAALwDAAAAAAAAYBIAAHYBAACIBAAA AAAAAIgEAAAAAAAAiAQAAAAAAACIBAAAAAAAAIgEAAAAAAAAYwUAAAAAAABjBQAAAAAAAGMFAAAA AAAA3xEAAAIAAADhEQAAAAAAAOERAAAAAAAA4REAAAAAAADhEQAAAAAAAOERAAAAAAAA4REAACQA AADWEwAAaAIAAD4WAACOAgAABRIAABUAAAAAAAAAAAAAAAAAAAAAAAAAqAMAAAAAAABjBQAAAAAA AAAAAAAAAAAAAAAAAAAAAABjBQAAAAAAAGMFAAAAAAAAYwUAAAAAAABjBQAAAAAAAAUSAAAAAAAA AAAAAAAAAACoAwAAAAAAAKgDAAAAAAAAiAQAAAAAAAAAAAAAAAAAAIgEAADbAAAAGhIAABYAAACR BQAAAAAAAJEFAAAAAAAAkQUAAAAAAABjBQAACgAAAKgDAAAAAAAAiAQAAAAAAACoAwAAAAAAAIgE AAAAAAAA3xEAAAAAAAAAAAAAAAAAAJEFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAYwUAAAAAAADfEQAAAAAAAAAAAAAAAAAAkQUAAAAAAACRBQAA cgAAAGUQAABUAAAAqAMAAAAAAACoAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZREAAAAAAACIBAAAAAAAAHwEAAAMAAAAUF9JdjAJ yQEAAAAAAAAAAGQEAAAAAAAAbQUAABAAAAC5EAAADgAAAAAAAAAAAAAA3xEAAAAAAAAwEgAAMAAA AGASAAAAAAAAxxAAAJ4AAADMGAAAAAAAAH0FAAAKAAAAzBgAABwAAABlEQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABl EQAANgAAAMwYAAAAAAAAAAAAAAAAAACoAwAAAAAAAJsRAABEAAAAYwUAAAAAAABjBQAAAAAAAJEF AAAAAAAAYwUAAAAAAABjBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYwUA AAAAAABjBQAAAAAAAGMFAAAAAAAABRIAAAAAAAAFEgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAhwUAAAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGMFAAAA AAAAYwUAAAAAAABjBQAAAAAAAGASAAAAAAAAYwUAAAAAAABjBQAAAAAAAGMFAAAAAAAAYwUAAAAA AAAAAAAAAAAAALwDAAAAAAAAvAMAAAAAAAC8AwAAhAAAAEAEAAAkAAAAvAMAAAAAAAC8AwAAAAAA ALwDAAAAAAAAQAQAAAAAAAC8AwAAAAAAALwDAAAAAAAAvAMAAAAAAACoAwAAAAAAAKgDAAAAAAAA qAMAAAAAAACoAwAAAAAAAKgDAAAAAAAAqAMAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQuQS5p aSBCdWxsZXQgMyBzaG91bGQgaGF2ZSBzdGF0ZWQ6DQ1JZiBhIGNvbnN0cnVjdCBpcyBzcGVjaWZp ZWQgZm9yIHRoZSB1c2Ugb2YgdGhlIGNhbmRpZGF0ZSBhbGdvcml0aG0gaW4gYW4gbi1iaXQgcmFu ZG9taXplZCBoYXNoaW5nIHNjaGVtZSwgdGhlIGNvbnN0cnVjdCBtdXN0LCB3aXRoIG92ZXJ3aGVs bWluZyBwcm9iYWJpbGl0eSwgcHJvdmlkZSBuLWsgYml0cyBvZiBzZWN1cml0eSBhZ2FpbnN0IHRo ZSBmb2xsb3dpbmcgYXR0YWNrOiBUaGUgYXR0YWNrZXIgY2hvb3NlcyBhIG1lc3NhZ2UsIE0xIG9m IGxlbmd0aCBhdCBtb3N0IDJrIGJpdHMuIFRoZSBzcGVjaWZpZWQgY29uc3RydWN0IGlzIHRoZW4g dXNlZCBvbiBNMSB3aXRoIGEgcmFuZG9taXphdGlvbiB2YWx1ZSByMSB0aGF0IGhhcyBiZWVuIHJh bmRvbWx5IGNob3NlbiB3aXRob3V0IHRoZSBhdHRhY2tlcpJzIGNvbnRyb2wgYWZ0ZXIgdGhlIGF0 dGFja2VyIGhhcyBzdXBwbGllZCBNMS4gR2l2ZW4gcjEsIHRoZSBhdHRhY2tlciB0aGVuIGF0dGVt cHRzIHRvIGZpbmQgYSBzZWNvbmQgbWVzc2FnZSBNMiBhbmQgcmFuZG9taXphdGlvbiB2YWx1ZSBy MiB0aGF0IHlpZWxkIHRoZSBzYW1lIHJhbmRvbWl6ZWQgaGFzaCB2YWx1ZS4gTm90ZSB0aGF0IGlu IG9yZGVyIHRvIG1lZXQgdGhpcyBzcGVjaWZpYyBzZWN1cml0eSByZXF1aXJlbWVudCwgdGhlIHNw ZWNpZmllZCByYW5kb21pemVkIGhhc2hpbmcgY29uc3RydWN0IG1heSBwbGFjZSByZXN0cmljdGlv bnMgb24gdGhlIGxlbmd0aCBvZiB0aGUgcmFuZG9taXphdGlvbiB2YWx1ZS4NDQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAAwgA AAYIAAAlCAAAbggAAG8IAADKCAAAzQgAAB0JAAAeCQAAIAkAADMJAAA0CQAAYwkAAGQJAABlCQAA gQkAAIIJAACDCQAA4QkAAOIJAADjCQAA6gkAAOwJAADtCQAA7gkAACMKAAAkCgAAJQoAAD4KAAA/ CgAAQAoAAHUKAACqCgAACAsAAA8LAAAXCwAAGAsAAPnx+eri6uLq4tjqzuri2Ori2Ori2Ori2Mbq 4tjq4tjqv+q46rEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAMFWjOK+MAFmhtU6wAAAwVaM4r4wAWaDRHOAAADBVozivjABZoQS42AAAPFWjOK+MAFmhI YQoASCoCEhVozivjABZoSGEKADYIgUgqAQASFWjOK+MAFmhIYQoANgiBSCoCAA8VaM4r4wAWaEhh CgA2CIEMFWjOK+MAFmhIYQoAAA8VaM4r4wAWaFELRAA2CIEMFWjOK+MAFmhRC0QAJQAGAAAkCAAA JQgAABcLAAAYCwAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA5AAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAABnZBpC PAARAAAKJgALRgQADcYHATgEAWgBBg+EaAFehGgBZ2QaQjwAAAQAAGdkSGEKAAAEAAYAABgLAAD9 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAABAQEsADGQaAEfsNAv ILDgPSGwCAcisAgHI5CgBSSQoAUlsAAAF7DQAhiw0AIMkNACAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACGAg8AEgABAJwADwAEAAAAAwAA AAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABEAABA8f8CAEQADAQAAAAAAAAAAAYATgBvAHIAbQBhAGwAAAACAAAAHABDShgAX0gBBGFKGABt SAkEbkgEBHNICQR0SAQEAAAAAAAAAAAAAAAAAAAAAAAARABBAPL/oQBEAAwFAAAAAAAAAAAWAEQA ZQBmAGEAdQBsAHQAIABQAGEAcgBhAGcAcgBhAHAAaAAgAEYAbwBuAHQAAAAAAFIAaQDz/7MAUgAM BQAAAAAAAAAADABUAGEAYgBsAGUAIABOAG8AcgBtAGEAbAAAABwAF/YDAAA01gYAAQoDbAA01gYA AQUDAABh9gMAAAIACwAAACgAawD0/8EAKAAABQAAAAAAAAAABwBOAG8AIABMAGkAcwB0AAAAAgAA AAAAAAAAAAAAGAMAAAQAABIAAAAA/////wAAAAAkAAAAJQAAABcDAAAaAwAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAQgADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAAAAAAAaAwAAmgAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAABwAGAAAYCwAABgAAAAAGAAAYCwAABwAAAAAGAAAYCwAACAAA AA8AAPA4AAAAAAAG8BgAAAACCAAAAgAAAAEAAAABAAAAAQAAAAIAAABAAB7xEAAAAP//AAAAAP8A gICAAPcAABAADwAC8JIAAAAQAAjwCAAAAAEAAAABBAAADwAD8DAAAAAPAATwKAAAAAEACfAQAAAA AAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAATwQgAAABIACvAIAAAAAQQAAAAOAABT AAvwHgAAAL8BAAAQAMsBAAAAAP8BAAAIAAQDCQAAAD8DAQABAAAAEfAEAAAAAQAAAAAAAAAaAwAA BwAAAAAABgAAABoDAAAzAAcAAAAAABoDAAAHAAAAAAAaAwAABwAEAIt+thp2AmxO/w//D/8P/w// D/8P/w//D/8PEACZXM8k3D8aOv8P/w//D/8P/w//D/8P/w//DxAAvQAlT2CeaKz/D/8P/w//D/8P /w//D/8P/w8QAHhUXnm+YAaX/w//D/8P/w//D/8P/w//D/8PEAABAAAAAhABAAAAAAAAAAAA0AIA AAAAAAATGAAAD4SEAxGEmP4VxgUAAYQDBl6EhANghJj+NQgANggAbygAh2gAAAAAiEgAAAIAAAAu AAEAAAAEkAEAAAAAAAAAAADQAgAAAAAAAAoYAAAPhOwEEYSY/hXGBQAB7AQGXoTsBGCEmP6HaAAA AACISAAAAgABAC4AAQAAAAKSAQAAAAAAAAAAANACAAAAAAAAChgAAA+EvAcRhEz/FcYFAAG8BwZe hLwHYIRM/4doAAAAAIhIAAACAAIALgABAAAAAJABAAAAAAAAAAAA0AIAAAAAAAAKGAAAD4SMChGE mP4VxgUAAYwKBl6EjApghJj+h2gAAAAAiEgAAAIAAwAuAAEAAAAEkAEAAAAAAAAAAADQAgAAAAAA AAoYAAAPhFwNEYSY/hXGBQABXA0GXoRcDWCEmP6HaAAAAACISAAAAgAEAC4AAQAAAAKSAQAAAAAA AAAAANACAAAAAAAAChgAAA+ELBARhEz/FcYFAAEsEAZehCwQYIRM/4doAAAAAIhIAAACAAUALgAB AAAAAJABAAAAAAAAAAAA0AIAAAAAAAAKGAAAD4T8EhGEmP4VxgUAAfwSBl6E/BJghJj+h2gAAAAA iEgAAAIABgAuAAEAAAAEkAEAAAAAAAAAAADQAgAAAAAAAAoYAAAPhMwVEYSY/hXGBQABzBUGXoTM FWCEmP6HaAAAAACISAAAAgAHAC4AAQAAAAKSAQAAAAAAAAAAANACAAAAAAAAChgAAA+EnBgRhEz/ FcYFAAGcGAZehJwYYIRM/4doAAAAAIhIAAACAAgALgABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAAV GAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAX kAAAAAAAAAAAAABoAQAAAAAAABUYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP5PSgQAUUoEAG8o AIdoAAAAAIhIAAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRgAAA+EcAgRhJj+FcYFAAFw CAZehHAIYISY/k9KBQBRSgUAbygAh2gAAAAAiEgAAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAA AAAVGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEA AAAXkAAAAAAAAAAAAABoAQAAAAAAABUYAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP5PSgQAUUoE AG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRgAAA+E4BARhJj+FcYF AAHgEAZehOAQYISY/k9KBQBRSgUAbygAh2gAAAAAiEgAAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEA AAAAAAAVGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC3 8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP5PSgQA UUoEAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRgAAA+EUBkRhJj+ FcYFAAFQGQZehFAZYISY/k9KBQBRSgUAbygAh2gAAAAAiEgAAAEAp/ABAAAAAwADAAAAAAAAAAAA 0AIAAAAAAAAjGAAAD4Q4BBGEmP4VxgUAATgEBl6EOARghJj+NQgBNggAQ0oYAE9KAABRSgAAYUoY AG8oAIdoAAAAAIhIAAADADQALgAAAAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhKAFEYSY /hXGBQABoAUGXoSgBWCEmP6HaAAAAACISAAAAgABAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAA ChgAAA+EcAgRhEz/FcYFAAFwCAZehHAIYIRM/4doAAAAAIhIAAACAAIALgABAAAAAIABAAAAAAAA AAAAAAAAAAAAAAAKGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+h2gAAAAAiEgAAAIAAwAuAAEA AAAEgAEAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP6HaAAAAACI SAAAAgAEAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+E4BARhEz/FcYFAAHgEAZehOAQ YIRM/4doAAAAAIhIAAACAAUALgABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4SwExGEmP4V xgUAAbATBl6EsBNghJj+h2gAAAAAiEgAAAIABgAuAAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAoY AAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP6HaAAAAACISAAAAgAHAC4AAQAAAAKCAQAAAAAAAAAA AAAAAAAAAAAAChgAAA+EUBkRhEz/FcYFAAFQGQZehFAZYIRM/4doAAAAAIhIAAACAAgALgABAAAA FxAAAAAAAAAAAAAAaAEAAAAAAAAVGAAAD4Q4BBGEmP4VxgUAATgEBl6EOARghJj+T0oBAFFKAQBv KACHaAAAAACISAAAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABkYAAAPhAgHEYSY/hXGBQAB CAcGXoQIB2CEmP5PSgQAUUoEAF5KBABvKACHaAAAAACISAAAAQBvAAEAAAAXkAAAAAAAAAAAAABo AQAAAAAAABUYAAAPhNgJEYSY/hXGBQAB2AkGXoTYCWCEmP5PSgUAUUoFAG8oAIdoAAAAAIhIAAAB AKfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRgAAA+EqAwRhJj+FcYFAAGoDAZehKgMYISY/k9K AQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAZGAAAD4R4DxGE mP4VxgUAAXgPBl6EeA9ghJj+T0oEAFFKBABeSgQAbygAh2gAAAAAiEgAAAEAbwABAAAAF5AAAAAA AAAAAAAAaAEAAAAAAAAVGAAAD4RIEhGEmP4VxgUAAUgSBl6ESBJghJj+T0oFAFFKBQBvKACHaAAA AACISAAAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUYAAAPhBgVEYSY/hXGBQABGBUGXoQY FWCEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAGRgA AA+E6BcRhJj+FcYFAAHoFwZehOgXYISY/k9KBABRSgQAXkoEAG8oAIdoAAAAAIhIAAABAG8AAQAA ABeQAAAAAAAAAAAAAGgBAAAAAAAAFRgAAA+EuBoRhJj+FcYFAAG4GgZehLgaYISY/k9KBQBRSgUA bygAh2gAAAAAiEgAAAEAp/AEAAAAmVzPJAAAAAAAAAAAAAAAAL0AJU8AAAAAAAAAAAAAAACLfrYa AAAAAAAAAAAAAAAAeFReeQAAAAAAAAAAAAAAAP///////////////////////wQAAAAAAAAAAAAA AP//BAAAABIARKNuixkACQQbAAkEDwAJBBkACQQbAAkEDwAJBBkACQQbAAkEEgAJBAEACQQDAAkE BQAJBAEACQQDAAkEBQAJBAEACQQDAAkEBQASACAgCn8ZAAkEGwAJBA8ACQQZAAkEGwAJBA8ACQQZ AAkEGwAJBBIAAQAJBAMACQQFAAkEAQAJBAMACQQFAAkEAQAJBAMACQQFAAkEAgC7bEoRAAAAAAAA AAAAAQIAAgDJd3xeu2xKEQAAAAAPARIA0AIAANACAABkAAAAZAAAAAEACwAAAAQAAAAIAAAA5QAA AAAAAAAKAAAASUcJAEhhCgDZQhUAuHM1AEEuNgA0RzgAGkI8AFELRABYa4cAbVOsAM4r4wD/QAOA AQAXAwAAFwMAABiqMgEBAAAAFwMAAAAAAAAXAwAAAAAAAAIQAAAAAAAAABgDAABAAAAQAEAAAP// AQAAAAcAVQBuAGsAbgBvAHcAbgD//wEACAAAAAAAAAAAAAAA//8BAAAAAAD//wAAAgD//wAAAAD/ /wAAAgD//wAAAAAGAAAARxaQAQAAAgIGAwUEBQIDBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAFQA aQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAA AAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAICAgICBId6ACAAAACACAAAAAAA AAD/AQAAAAAAAEEAcgBpAGEAbAAAAEMWkAGICQICAwAAAAAAAAADAAAAAAAuCBYAAAAAAAAAAQAQ AAAAAABQAE0AaQBuAGcATABpAFUAAACwZTB9DmbUmgAAPzWQAQAAAgcDCQICBQIEBId6ACAAAACA CAAAAAAAAAD/AQAAAAAAAEMAbwB1AHIAaQBlAHIAIABOAGUAdwAAADsGkAECAAUAAAAAAAAAAAAA AAAAAAAAEAAAAAAAAAAAAAAAgAAAAABXAGkAbgBnAGQAaQBuAGcAcwAAACIABADxCIgYAPDQAgAA aAEAAAAADNzIZkbjyIYj48iGDABgAAAAdgAAAKICAAABAAEAAAAEAAMQBQAAAHYAAACiAgAAAQAB AAAABQAAAAAAAAAhAwDwEAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIB6AFtAC0AIGBMjQA ABAAGQBkAAAAGQAAABcDAAAXAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAA0yg3EA8BAACAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAASFAAAAAAKfD/DwEAAT8AAOQEAAD///9/////f////3////9/////f/// /3////9/2UIVAAAAAAAyAAAAAAAAAAAAAAAAAAAAAAD//xIAAAAAAAAA/gAiAEkAZgAgAGEAIABj AG8AbgBzAHQAcgB1AGMAdAAgAGkAcwAgAHMAcABlAGMAaQBmAGkAZQBkACAAZgBvAHIAIAB0AGgA ZQAgAHUAcwBlACAAbwBmACAAdABoAGUAIABjAGEAbgBkAGkAZABhAHQAZQAgAGEAbABnAG8AcgBp AHQAaABtACAAaQBuACAAYQBuACAAbgAtAGIAaQB0ACAAcgBhAG4AZABvAG0AaQB6AGUAZAAgAGgA YQBzAGgAaQBuAGcAIABzAGMAaABlAG0AZQAsACAAdABoAGUAIABjAG8AbgBzAHQAcgB1AGMAdAAg AG0AdQBzAHQALAAgAHcAaQB0AGgAIABvAHYAZQByAHcAaABlAGwAbQBpAG4AZwAgAHAAcgBvAGIA YQBiAGkAbABpAHQAeQAsACAAcAByAG8AdgBpAGQAZQAgAG4ALQBrACAAYgBpAHQAcwAgAG8AZgAg AHMAZQBjAHUAcgBpAHQAeQAgAGEAZwBhAGkAbgBzAHQAIAB0AGgAZQAgAGYAbwBsAGwAbwB3AGkA bgBnACAAYQB0AHQAYQBjAGsAOgAgAFQAaABlACAAYQB0AHQAYQBjAGsAZQByACAAYwBoAG8AbwBz AGUAcwAgAGEAIABtAGUAcwBzAGEAZwBlACwAIABNADEAIABvAGYAAAAAAAAAGgBDAG8AbQBwAHUA dABlAHIAIABTAGUAYwB1AHIAaQB0AHkAIABEAGkAdgBpAHMAaQBvAG4AGgBDAG8AbQBwAHUAdABl AHIAIABTAGUAYwB1AHIAaQB0AHkAIABEAGkAdgBpAHMAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAA AAAcAAAABgAAAAQAAAAAAAwAAQAMAAIADAADAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y +U9oEKuRCAArJ7PZMAAAAKACAAASAAAAAQAAAJgAAAACAAAAoAAAAAMAAACoAQAABAAAALQBAAAF AAAA2AEAAAYAAADkAQAABwAAAPABAAAIAAAAAAIAAAkAAAAkAgAAEgAAADACAAAKAAAAUAIAAAsA AABcAgAADAAAAGgCAAANAAAAdAIAAA4AAACAAgAADwAAAIgCAAAQAAAAkAIAABMAAACYAgAAAgAA AOQEAAAeAAAAAAEAACJJZiBhIGNvbnN0cnVjdCBpcyBzcGVjaWZpZWQgZm9yIHRoZSB1c2Ugb2Yg dGhlIGNhbmRpZGF0ZSBhbGdvcml0aG0gaW4gYW4gbi1iaXQgcmFuZG9taXplZCBoYXNoaW5nIHNj aGVtZSwgdGhlIGNvbnN0cnVjdCBtdXN0LCB3aXRoIG92ZXJ3aGVsbWluZyBwcm9iYWJpbGl0eSwg cHJvdmlkZSBuLWsgYml0cyBvZiBzZWN1cml0eSBhZ2FpbnN0IHRoZSBmb2xsb3dpbmcgYXR0YWNr OiBUaGUgYXR0YWNrZXIgY2hvb3NlcyBhIG1lc3NhZ2UsIE0xIG9mAAAeAAAABAAAAAAAAAAeAAAA HAAAAENvbXB1dGVyIFNlY3VyaXR5IERpdmlzaW9uAAAeAAAABAAAAAAAAAAeAAAABAAAAAAAAAAe AAAACAAAAE5vcm1hbAAAHgAAABwAAABDb21wdXRlciBTZWN1cml0eSBEaXZpc2lvbgAAHgAAAAQA AAAxMgAAHgAAABgAAABNaWNyb3NvZnQgT2ZmaWNlIFdvcmQAAABAAAAAAEA6aQ0AAABAAAAAANKT AywJyQFAAAAAAGiwKYEIyQFAAAAAAEw5WDAJyQEDAAAAAQAAAAMAAAB2AAAAAwAAAKICAAADAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN1ZwuGxCTlwgA Kyz5rjAAAADsAQAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAgAAAAAYAAACIAAAAEQAAAJAAAAAX AAAAmAAAAAsAAACgAAAAEAAAAKgAAAATAAAAsAAAABYAAAC4AAAADQAAAMAAAAAMAAAAywEAAAIA AADkBAAAHgAAAAgAAABOSVNUAAAAAAMAAAAFAAAAAwAAAAEAAAADAAAAFwMAAAMAAAAPJwsACwAA AAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAP8AAAAiSWYgYSBjb25zdHJ1Y3Qg aXMgc3BlY2lmaWVkIGZvciB0aGUgdXNlIG9mIHRoZSBjYW5kaWRhdGUgYWxnb3JpdGhtIGluIGFu IG4tYml0IHJhbmRvbWl6ZWQgaGFzaGluZyBzY2hlbWUsIHRoZSBjb25zdHJ1Y3QgbXVzdCwgd2l0 aCBvdmVyd2hlbG1pbmcgcHJvYmFiaWxpdHksIHByb3ZpZGUgbi1rIGJpdHMgb2Ygc2VjdXJpdHkg YWdhaW5zdCB0aGUgZm9sbG93aW5nIGF0dGFjazogVGhlIGF0dGFja2VyIGNob29zZXMgYSBtZXNz YWdlLCBNMSBvZgAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAA/v///wsAAAAMAAAA DQAAAA4AAAAPAAAAEAAAABEAAAD+////EwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAb AAAAHAAAAB0AAAAeAAAA/v///yAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAD+////KAAAACkA AAAqAAAAKwAAACwAAAAtAAAALgAAAP7////9////MQAAAP7////+/////v////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAA AAAwRlV2MAnJATMAAACAAAAAAAAAAEQAYQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAIB////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAAAAQAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgEBAAAABgAAAP// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAAA6BgAAAAAAABXAG8AcgBk AEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA GgACAQIAAAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAu EgAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAoAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAHwAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4A ZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgEEAAAA//////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAP////////////// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABxAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAQAAAP7///////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGHwAAAE1pY3Jvc29mdCBPZmZpY2UgV29y ZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAA== --=====================_10472906==_ Content-Type: text/plain; charset="us-ascii"; format=flowed --=====================_10472906==_-- From hash-forum@nist.gov Thu Aug 28 12:11:51 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m7SJBlrN021923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 28 Aug 2008 12:11:48 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m7SHxpcC003011; Thu, 28 Aug 2008 13:59:57 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m7SHwFwW009402; Thu, 28 Aug 2008 13:58:15 -0400 Date: Thu, 28 Aug 2008 13:58:15 -0400 Message-Id: <20080828135114.53783ipvwza1pm6q@webmail.nist.gov> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "John Kelsey" To: Multiple recipients of list Subject: Long message attacks and randomized hashing X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 28 Aug 2008 12:11:48 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 20 Everyone, Shoichi Hirose pointed out a minor error in our call for algorithms, involving the resistance of (optional) randomized hashing modes to second-preimage attacks. We ignored the long-message second preimage attack in these requirements. The text should be corrected as follows: ///// 4.A.ii Bullet 3 should have stated: If a construct is specified for the use of the candidate algorithm in an n-bit randomized hashing scheme, the construct must, with overwhelming probability, provide n-k bits of security against the following attack: The attacker chooses a message, M1 of length at most 2k bits. The specified construct is then used on M1 with a randomization value r1 that has been randomly chosen without the attacker's control after the attacker has supplied M1. Given r1, the attacker then attempts to find a second message M2 and randomization value r2 that yield the same randomized hash value. Note that in order to meet this specific security requirement, the specified randomized hashing construct may place restrictions on the length of the randomization value. ///// I don't expect this change to affect any submissions, since it slightly relaxes requirements on an optional thing submitters may do, decreasing the vulnerability of the optional randomized hashing construction to an entirely academic attack. (However, I'm a little embarrassed to have missed the omission, all things considered.) Thanks, --John Kelsey, NIST From hash-forum@nist.gov Sat Aug 30 09:27:19 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m7UGREKi032582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 30 Aug 2008 09:27:15 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m7UFTsQ2025893; Sat, 30 Aug 2008 11:29:55 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m7UFSZBn005729; Sat, 30 Aug 2008 11:28:35 -0400 Date: Sat, 30 Aug 2008 11:28:35 -0400 Message-Id: <48B9653A.7090106@mit.edu> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Ronald L. Rivest" To: Multiple recipients of list Subject: Re: Long message attacks and randomized hashing X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: <20080828135114.53783ipvwza1pm6q@webmail.nist.gov> References: <20080828135114.53783ipvwza1pm6q@webmail.nist.gov> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: Delayed for 00:55:53 by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 30 Aug 2008 09:27:15 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 21 Hi John -- Shouldn't the revised text say "... M1 of length at most 2**k bits ... " and not 2k bits ?? Can you explain the reason for the change in specs? It doesn't seem necessary, unless you explicitly want to encourage the use of chaining variables that have the same size as the final hash output -- arguably a poor choice. Or have I misunderstood something? Cheers, Ron Rivest On 8/28/2008 1:58 PM, John Kelsey wrote: > > Everyone, > > Shoichi Hirose pointed out a minor error in our call for algorithms, > involving the resistance of (optional) randomized hashing modes to > second-preimage attacks. We ignored the long-message second preimage > attack in these requirements. > > The text should be corrected as follows: > > ///// > > 4.A.ii Bullet 3 should have stated: > > If a construct is specified for the use of the candidate > algorithm in an n-bit randomized hashing scheme, the construct must, > with overwhelming probability, provide n-k bits of security against > the following attack: The attacker chooses a message, M1 of length at > most 2k bits. The specified construct is then used on M1 with a > randomization value r1 that has been randomly chosen without the > attacker's control after the attacker has supplied M1. Given r1, the > attacker then attempts to find a second message M2 and randomization > value r2 that yield the same randomized hash value. Note that in order > to meet this specific security requirement, the specified randomized > hashing construct may place restrictions on the length of the > randomization value. > > ///// > > I don't expect this change to affect any submissions, since it > slightly relaxes requirements on an optional thing submitters may do, > decreasing the vulnerability of the optional randomized hashing > construction to an entirely academic attack. (However, I'm a little > embarrassed to have missed the omission, all things considered.) > > Thanks, > > --John Kelsey, NIST > > > > -- Ronald L. Rivest Room 32-G692, Stata Center, MIT, Cambridge MA 02139 Tel 617-253-5880, Email From hash-forum@nist.gov Tue Sep 2 11:31:04 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m82IUxPP010060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Sep 2008 11:31:00 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m82Hp6rM017943; Tue, 2 Sep 2008 13:51:18 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m82HnjaD024477; Tue, 2 Sep 2008 13:49:45 -0400 Date: Tue, 2 Sep 2008 13:49:45 -0400 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Robert Jueneman" To: Multiple recipients of list Subject: Opportunity for "live" hash testing X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit X-To: References: <20080828135114.53783ipvwza1pm6q@webmail.nist.gov> <48B9653A.7090106@mit.edu> In-Reply-To: <48B9653A.7090106@mit.edu> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: Delayed for 00:38:10 by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 02 Sep 2008 11:31:00 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 22 I've been following this forum with interest, although I don't plan to submit a new hash function. However, I have recently become involved in an effort to test a file storage system that involves millions of records, and close to 3 terabytes of data per device, and in my case a total of over 20 TB of data. I'm looking for errors that might occur at a BER of 10^-9 to 10^-12. Unfortunately, I don't have or know of a file synchronization utility that is really suitable for the intended purpose. What I would like to find is a utility that will hash all of the files in a folder, and store that hash somewhere (preferably somewhere associated with the file itself but without modifying the file, perhaps in an NTFS Alternate Data Stream for Vista/XP, or a resource fork on the Mac's HFS+ file system. After completing the first pass over the data, it would be possible to re-verify the data at will, by re-computing the hash. Ideally, the association of the hash with the file should survive the file being renamed, moved from one location or another, or even from one file system type to another. Right now, I'm primarily concerned about accidental file modifications caused by cascaded hardware/firmware/software errors, as opposed to attempts to spoof the system, so the length of the hash isn't particularly important -- SHA-1 would be good enough. About the best data rates we can get over FireWire 800 presently is 31 megabytes/second, but hopefully the hash function can keep up easily. Does anyone have such a utility? We need one for both the Mac (Leopard 10.5.4) using HFS+ and the PC (XP SP3 and Vista SP1) using NTFS. Support for FAT, and for Linux would be good for extra credit! Regards, Bob Robert R. Jueneman Chief Scientist SPYRUS, Inc. www.spyrus.com From hash-forum@nist.gov Tue Sep 2 13:10:07 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m82KA1cj021280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Sep 2008 13:10:02 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m82K8J4Q003542; Tue, 2 Sep 2008 16:08:40 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m82K6jfA032733; Tue, 2 Sep 2008 16:06:45 -0400 Date: Tue, 2 Sep 2008 16:06:45 -0400 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Sean O'Neil" To: Multiple recipients of list Subject: Re: Opportunity for "live" hash testing X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: <20080828135114.53783ipvwza1pm6q@webmail.nist.gov> <48B9653A.7090106@mit.edu> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 02 Sep 2008 13:10:03 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 23 On 2 Sep 2008, at 19:49, Robert Jueneman wrote: > About the best data rates we can get over FireWire 800 presently is 31 > megabytes/second, but hopefully the hash function can keep up easily. Any hash function can keep up with that speed, even the dog-slow MD6 or Whirlpool can. You can easily use SHA-1 and even SHA-2. SHA-256 is faster on 32-bit processors, but SHA-512 is faster on 64-bit processors, although MD5 beats them all by speed. > Does anyone have such a utility? We need one for both the Mac > (Leopard > 10.5.4) using HFS+ and the PC (XP SP3 and Vista SP1) using NTFS. > Support for FAT, and for Linux would be good for extra credit! http://md5deep.sourceforge.net/ There you go. That can do it all. You probably don't even need more than a half of MD5 [in rounds] for your purposes. Best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. From hash-forum@nist.gov Tue Sep 2 13:37:31 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m82KbPgw024969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Sep 2008 13:37:27 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m82KZpYq025329; Tue, 2 Sep 2008 16:35:58 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m82KZbn0025982; Tue, 2 Sep 2008 16:35:37 -0400 Date: Tue, 2 Sep 2008 16:35:37 -0400 Message-Id: <2B849E5F-C9A5-4833-9664-C18F3AE10F6F@mac.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Jeff Johnson To: Multiple recipients of list Subject: Re: Opportunity for "live" hash testing X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov References: <20080828135114.53783ipvwza1pm6q@webmail.nist.gov> <48B9653A.7090106@mit.edu> In-reply-to: Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 02 Sep 2008 13:37:28 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 24 On Sep 2, 2008, at 1:49 PM, Robert Jueneman wrote: > > Does anyone have such a utility? We need one for both the Mac > (Leopard > 10.5.4) using HFS+ and the PC (XP SP3 and Vista SP1) using NTFS. > Support for FAT, and for Linux would be good for extra credit! > I have a linux port of the BSD mtree(8) command (which verifies hashes) that I carry around within RPM sources that should do mostly what you want. Dunno if rpmmtree (developed mostly from Mac OS X sources) does resource forks on Mac OS X or not. (aside) And I can pretty easily wire up any additional hash function within rpm packages if useful for comparison timing and/or random "real world" testing. 73 de Jeff From hash-forum@nist.gov Wed Sep 3 12:49:45 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m83JnbqJ022242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Sep 2008 12:49:40 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m83Jm8Ri017628; Wed, 3 Sep 2008 15:48:14 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m83JkD5D030524; Wed, 3 Sep 2008 15:46:13 -0400 Date: Wed, 3 Sep 2008 15:46:13 -0400 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Larry Bassham To: Multiple recipients of list Subject: KATMCT files X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 03 Sep 2008 12:49:41 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 25 Everyone should be using the genKAT.c file provided to generate their KAT and MonteCarlo values. This file and additional information can be found at: http://csrc.nist.gov/groups/ST/hash/sha-3/Submission_Reqs/ test_vectors.html Additionally, you shouldn't need to alter the genKAT.c file other than changing the include file to match your implementations header file name. If you have multiple header files adding those is also acceptable. You shouldn't need to make any other changes to genKAT.c. Do not, for example, append your source code or include your source code into the genKAT.c file in any way. If you wish to show additional features such as different internal word_size choices, sample values for other hash lengths, etc., please provide these as an Additional_Implementation. These requirements are necessary to help facilitate the vetting process. Larry B. From hash-forum@nist.gov Fri Oct 10 03:28:10 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m9AAS4Pj004546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Oct 2008 03:28:05 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m9A8fm3v021669; Fri, 10 Oct 2008 04:41:50 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m9A8cGHG003981; Fri, 10 Oct 2008 04:38:16 -0400 Date: Fri, 10 Oct 2008 04:38:16 -0400 Message-Id: <5902D0FFEB1E474C973D6FC637C5D6A1@FORTRESSIL.local> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Carmi Gressel To: Multiple recipients of list Subject: Willl there be a week's grace for the final submission? X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <5.1.1.5.2.20060425130827.032c6588@email.nist.gov> Content-type: multipart/alternative; boundary="----=_NextPart_000_000C_01C92AC3.F5CD94D0" X-Mailer: Microsoft Office Outlook 11 X-To: hash-forum@nist.gov In-reply-to: <5.1.1.5.2.20060425130827.032c6588@email.nist.gov> X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: Delayed for 01:44:59 by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 10 Oct 2008 03:28:06 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00,HTML_MESSAGE, MIME_HEADER_CTYPE_ONLY,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 26 This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C92AC3.F5CD94D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Shu-jen: As the examination of the August 31 submissions took longer than the 25 of Sept date, will there be a 2 week's grace for the final submission? NIST writes that it will welcome meeting with submitters in Washington. We would appreciate meeting before the examiners try to read our documentation in depth. We know from experience with 7 previous technology transfers to silicon fabs that a 1.5 hour lecture of the concept and architecture, suddenly makes documentation friendly, readable and alive. Sincerely, Carmi Carmi Gressel FortressGB Ltd. Omer Industrial Park 8B Omer 84965, ISRAEL Mb +972-54-7776 059 Hm+972-8-9920 518 Fx +972-8-6466 729 Skype - Carmi.Gressel FGB - Tel IL +972-9-6909 727 UK +44-20-7874 595 _____ -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.4.6/323 - Release Date: 24/4/2006 ------=_NextPart_000_000C_01C92AC3.F5CD94D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear = Shu-jen:

 

As the examination of the August 31 submissions took
longer than the 25 of Sept date, will there be a 2 week's grace
for the final submission?

 

NIST writes that it will welcome = meeting with submitters in Washington.
We would appreciate meeting before the examiners try to read our
documentation in depth.

 

We know from experience with 7 = previous technology transfers
to silicon fabs that a 1.5 hour lecture of the concept and architecture, =
suddenly makes documentation friendly, readable and = alive.

 

Sincerely,<= /p>

 

Carmi

 

 

 

Carmi = Gressel

   FortressGB Ltd.
      Omer Industrial Park = 8B

          Omer = 84965, ISRAEL

Mb = +972-54-7776 059  Hm+972-8-9920 518

   Fx +972-8-6466 729   Skype - = Carmi.Gressel

       FGB - Tel IL +972-9-6909 727   UK +44-20-7874 595

 


--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.6/323 - Release Date: = 24/4/2006

------=_NextPart_000_000C_01C92AC3.F5CD94D0-- From hash-forum@nist.gov Fri Oct 10 10:45:24 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m9AHjJlu001327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Oct 2008 10:45:20 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m9AHhvU0000811; Fri, 10 Oct 2008 13:44:01 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m9AHgxvG031223; Fri, 10 Oct 2008 13:42:59 -0400 Date: Fri, 10 Oct 2008 13:42:59 -0400 Message-Id: <7.0.1.0.2.20081010133017.02481868@nist.gov> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Shu-jen Chang To: Multiple recipients of list Subject: Re: Willl there be a week's grace for the final submission? X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: text/plain; charset="us-ascii"; format=flowed Mime-Version: 1.0 References: <5.1.1.5.2.20060425130827.032c6588@email.nist.gov> <5902D0FFEB1E474C973D6FC637C5D6A1@FORTRESSIL.local> <7.0.1.0.2.20081010101541.0247e9e8@nist.gov> <48EF7BB6.7040004@gmail.com> <7.0.1.0.2.20081010122131.0246e1c0@nist.gov> <48EF8F5E.1050801@gmail.com> In-Reply-To: <48EF8F5E.1050801@gmail.com> X-Cc: hash-forum@nist.gov X-To: "Aryeh M. Friedman" X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 10 Oct 2008 10:45:20 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 27 At 01:22 PM 10/10/2008, you wrote: >Shu-jen Chang wrote: >>Dear Mr. Friedman, >> >>Are you referring to the following text? If not, would you please >>identify the source of the writing that Mr. Gressel was referring >>to, as I'm really confused now. When you said RFP, did you mean our >>Federal Register Notice? I have drafted one FRN to publish our >>draft requirements and evaluation criteria of the new hash >>algorithm, and another FRN to call for new hash algorithms, and I >>don't recall any mentioning of meeting with submitters prior to >>their submission reviews. Therefore, I'm perplexed. I am not aware >>of any RFP that was done on behalf of the hash competition, but >>that does not necessarily mean that it hasn't been done. In any >>case, I would appreciate it very much if you can enlighten me on this. >> >> *5. Initial Planning for the First SHA-3 Candidate Conference* >> An open public conference will be held shortly after the end of >> the submission period, at which the submitter of each complete and >> proper submission package will be invited to publicly discuss and >> explain their candidate algorithm. The documentation for these >> candidate algorithms will be made available at the Conference. >> Details of the conference will be posted at < >> http://www.nist.gov/hash-competition>. >> >>Thanks, >>Shu-jen > >Yes that is what I was referring to. Sorry for the terminology >confusion I was using RFP informally (should of remembered federal >employees are overly formal). I think the original question was >asking about a post submission conference not a pre-submission one. Thanks very much for the reply. For the competition, we have to be very precise and formal. :-) Again, we can't meet with the submitters before the reviews; we will meet the first round candidates at the first SHA-3 Conference. Thanks, Shu-jen From hash-forum@nist.gov Fri Oct 10 09:05:20 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m9AG5F3P018970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Oct 2008 09:05:16 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m9AG34sN025623; Fri, 10 Oct 2008 12:04:11 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m9AG1r2V022834; Fri, 10 Oct 2008 12:01:53 -0400 Date: Fri, 10 Oct 2008 12:01:53 -0400 Message-Id: <48EF7BB6.7040004@gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Aryeh M. Friedman" To: Multiple recipients of list Subject: Re: Willl there be a week's grace for the final submission? X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <5.1.1.5.2.20060425130827.032c6588@email.nist.gov> <5902D0FFEB1E474C973D6FC637C5D6A1@FORTRESSIL.local> <7.0.1.0.2.20081010101541.0247e9e8@nist.gov> Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed In-reply-to: <7.0.1.0.2.20081010101541.0247e9e8@nist.gov> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 10 Oct 2008 09:05:16 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 28 Shu-jen Chang wrote: > > Dear Mr. Gressel, > > I don't think you intended to send this email to hash-forum; we at > NIST treat every hash submission with extreme care and we do not > discuss anything about the submissions outside our review team. > However, since you made your submission public, I'd like to point out > that we did everything that we had promised to do on time. Your > submission was received on 8/29/2008, and you were notified of the > review status on 9/29/2008, which is before the 9/30/2008 deadline > that we had promised. > > In fairness to every contender, the final submission deadline is > 10/31/2008, and no grace period will be granted. > > About meeting with submitters to discuss their submissions, we are a > bit confused. Would you enlighten us as where you saw that writing? If > we grant one contender the chance to discuss his/her submission before > the review, we will have to grant everyone the same opportunity. > Considering the potential number of submissions and the origin of the > submissions, it's probably unrealistic to accommodate this. It was mentioned in the initial RFP. > > Regards, > Shu-jen > > > At 04:38 AM 10/10/2008, you wrote: > >> This is a multi-part message in MIME format. >> >> ------=_NextPart_000_000C_01C92AC3.F5CD94D0 >> Content-Type: text/plain; >> charset="us-ascii" >> Content-Transfer-Encoding: 7bit >> >> Dear Shu-jen: >> >> >> >> As the examination of the August 31 submissions took >> longer than the 25 of Sept date, will there be a 2 week's grace >> for the final submission? >> >> >> >> NIST writes that it will welcome meeting with submitters in Washington. >> We would appreciate meeting before the examiners try to read our >> documentation in depth. >> >> >> >> We know from experience with 7 previous technology transfers >> to silicon fabs that a 1.5 hour lecture of the concept and architecture, >> suddenly makes documentation friendly, readable and alive. >> >> >> >> Sincerely, >> >> >> >> Carmi >> >> >> >> >> >> >> >> Carmi Gressel >> >> FortressGB Ltd. >> Omer Industrial Park 8B >> >> Omer 84965, ISRAEL >> >> Mb +972-54-7776 059 Hm+972-8-9920 518 >> >> Fx +972-8-6466 729 Skype - Carmi.Gressel >> >> FGB - Tel IL +972-9-6909 727 UK +44-20-7874 595 > > > > > From hash-forum@nist.gov Fri Oct 10 08:50:39 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m9AFoTrr015915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Oct 2008 08:50:33 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m9AFmGhI014631; Fri, 10 Oct 2008 11:49:23 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m9AFjou9024085; Fri, 10 Oct 2008 11:45:50 -0400 Date: Fri, 10 Oct 2008 11:45:50 -0400 Message-Id: <7.0.1.0.2.20081010101541.0247e9e8@nist.gov> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Shu-jen Chang To: Multiple recipients of list Subject: Re: Willl there be a week's grace for the final submission? X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: text/plain; charset="us-ascii"; format=flowed Mime-Version: 1.0 References: <5.1.1.5.2.20060425130827.032c6588@email.nist.gov> <5902D0FFEB1E474C973D6FC637C5D6A1@FORTRESSIL.local> In-Reply-To: <5902D0FFEB1E474C973D6FC637C5D6A1@FORTRESSIL.local> X-Cc: hash-forum@nist.gov X-To: Carmi Gressel X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 10 Oct 2008 08:50:33 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 29 Dear Mr. Gressel, I don't think you intended to send this email to hash-forum; we at NIST treat every hash submission with extreme care and we do not discuss anything about the submissions outside our review team. However, since you made your submission public, I'd like to point out that we did everything that we had promised to do on time. Your submission was received on 8/29/2008, and you were notified of the review status on 9/29/2008, which is before the 9/30/2008 deadline that we had promised. In fairness to every contender, the final submission deadline is 10/31/2008, and no grace period will be granted. About meeting with submitters to discuss their submissions, we are a bit confused. Would you enlighten us as where you saw that writing? If we grant one contender the chance to discuss his/her submission before the review, we will have to grant everyone the same opportunity. Considering the potential number of submissions and the origin of the submissions, it's probably unrealistic to accommodate this. Regards, Shu-jen At 04:38 AM 10/10/2008, you wrote: >This is a multi-part message in MIME format. > >------=_NextPart_000_000C_01C92AC3.F5CD94D0 >Content-Type: text/plain; > charset="us-ascii" >Content-Transfer-Encoding: 7bit > >Dear Shu-jen: > > > >As the examination of the August 31 submissions took >longer than the 25 of Sept date, will there be a 2 week's grace >for the final submission? > > > >NIST writes that it will welcome meeting with submitters in Washington. >We would appreciate meeting before the examiners try to read our >documentation in depth. > > > >We know from experience with 7 previous technology transfers >to silicon fabs that a 1.5 hour lecture of the concept and architecture, >suddenly makes documentation friendly, readable and alive. > > > >Sincerely, > > > >Carmi > > > > > > > >Carmi Gressel > > FortressGB Ltd. > Omer Industrial Park 8B > > Omer 84965, ISRAEL > >Mb +972-54-7776 059 Hm+972-8-9920 518 > > Fx +972-8-6466 729 Skype - Carmi.Gressel > > FGB - Tel IL +972-9-6909 727 UK +44-20-7874 595 From MAILER-DAEMON Wed Oct 22 07:53:00 2008 Date: 22 Oct 2008 07:53:00 -0700 From: Mail System Internal Data Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA Status: RO X-Status: X-Keywords: X-UID: 30 This text is part of the internal format of your mail folder, and is not a real message. It is created automatically by the mail system software. If deleted, important folder data will be lost, and it will be re-created with the data reset to initial values. From carmi@fortressgb.com Sat Oct 18 05:25:28 2008 Date: Sat, 18 Oct 2008 07:43:55 -0400 From: Carmi Gressel Reply-To: hash-forum@nist.gov To: Multiple recipients of list Subject: An apology to Shu-jen Chang for an untimely posting. Status: RO X-Status: X-Keywords: NonJunk X-UID: 31 This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C93126.EB6E1C30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Shu-jen: My abject apologies for (mistakenly) posting a misplaced uninformed letter on the forum. Under the circumstances, the examiners did a very recommendable job, apparently pouring over thousands of pages of difficult to understand support data. They finished their work on time, (for some unexplained reason I hoped to receive the list of deficiencies on an earlier date.) We look forward, at some future date, to be able to explain, face to face, to the NIST examiners, our massively diffusive, multipermutation (Schnorr/Vaudenay's guideline) design, based on simple tenets, supported by massive innovative tests, (past, present and future). We apologize in advance for our non-conventional submission. Sincerely, Carmi Carmi Gressel FortressGB Ltd. Omer Industrial Park 8B Omer 84965, ISRAEL Mb +972-54-7776 059 Hm+972-8-9920 518 Fx +972-8-6466 729 Skype - Carmi.Gressel FGB - Tel IL +972-9-6909 727 UK +44-20-7874 595 ------=_NextPart_000_0018_01C93126.EB6E1C30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear = Shu-jen:

 

My abject = apologies for (mistakenly) posting a misplaced uninformed
letter on the forum.

 

Under the circumstances, the examiners did a very recommendable job, = apparently
pouring over thousands of pages of difficult to understand support data. =

They finished = their work on time, (for some unexplained reason I
hoped to receive the list of deficiencies on an earlier date.) =  

 

We look = forward, at some future date, to be able to explain, face to
face, to the NIST examiners, our massively diffusive, multipermutation =
(Schnorr/Vaudenay's guideline) design, based on simple tenets,
supported by massive innovative tests, (past, present and = future).

 

We apologize = in advance for our non-conventional submission.

 

Sincerely,

 

Carmi

 

Carmi = Gressel

   FortressGB Ltd.
      Omer Industrial Park = 8B

          Omer = 84965, ISRAEL

Mb = +972-54-7776 059  Hm+972-8-9920 518

   Fx +972-8-6466 729   Skype - = Carmi.Gressel

       FGB - Tel IL +972-9-6909 727   UK +44-20-7874 595

 

------=_NextPart_000_0018_01C93126.EB6E1C30-- From hash-forum@nist.gov Tue Oct 21 09:41:50 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m9LGfh0P003349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Oct 2008 09:41:45 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m9LGeC6I006114; Tue, 21 Oct 2008 12:40:18 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m9LGc1Ss031997; Tue, 21 Oct 2008 12:38:01 -0400 Date: Tue, 21 Oct 2008 12:38:01 -0400 Message-Id: <7bb08a5f0810210925v6365438ey9c720555d41c1f54@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Jason Martin" To: Multiple recipients of list Subject: Spaces versus underscores in directory names? X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 21 Oct 2008 09:41:45 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 32 Hi All, I realize this is a silly question, but since it could interfere with automated testing I'll ask anyway: In some places in the submission specifications the directory names have spaces in them, but in other places the spaces are either omitted or replaced with underscores. For example, compare "Reference_Implementation" in http://csrc.nist.gov/groups/ST/hash/sha-3/Submission_Reqs/optical_media.html with "Reference Implementation" at the end of 2.C.1 in http://csrc.nist.gov/groups/ST/hash/sha-3/Submission_Reqs/ref_and_optim.html Now, I realize that the difference doesn't matter to a human, but if it matters, please let me know which naming convention to use. Thanks, --jason Jason Worth Martin Asst. Professor of Mathematics http://www.math.jmu.edu/~martin From hash-forum@nist.gov Tue Oct 21 11:05:31 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m9LI5PSw018828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Oct 2008 11:05:26 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m9LI4G8Y024265; Tue, 21 Oct 2008 14:04:22 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m9LI3H2C012916; Tue, 21 Oct 2008 14:03:17 -0400 Date: Tue, 21 Oct 2008 14:03:17 -0400 Message-Id: <50E2349F-92C2-4ED3-ADBC-EAD486846BF1@nist.gov> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Larry Bassham To: Multiple recipients of list Subject: Re: Spaces versus underscores in directory names? X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: <7bb08a5f0810210925v6365438ey9c720555d41c1f54@mail.gmail.com> In-Reply-To: <7bb08a5f0810210925v6365438ey9c720555d41c1f54@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 21 Oct 2008 11:05:26 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 33 I don't really care for the Ref and Opt Implementations if you uses spaces or underscores. Underscores probably make things more portable and have less problems. The important one is to make sure there is a root level directory with the name "KAT_MCT". Larry B. On Oct 21, 2008, at 12:38 PM, Jason Martin wrote: > > Hi All, > > I realize this is a silly question, but since it could interfere with > automated testing I'll ask anyway: > > In some places in the submission specifications the directory names > have spaces in them, but in other places the spaces are either omitted > or replaced with underscores. For example, compare > "Reference_Implementation" in > > http://csrc.nist.gov/groups/ST/hash/sha-3/Submission_Reqs/ > optical_media.html > > with "Reference Implementation" at the end of 2.C.1 in > > http://csrc.nist.gov/groups/ST/hash/sha-3/Submission_Reqs/ > ref_and_optim.html > > Now, I realize that the difference doesn't matter to a human, but if > it matters, please let me know which naming convention to use. > > Thanks, > --jason > > Jason Worth Martin > Asst. Professor of Mathematics > http://www.math.jmu.edu/~martin > From hash-forum@nist.gov Tue Oct 21 21:08:05 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m9M47t0G010850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Oct 2008 21:07:56 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m9M45GXu021301; Wed, 22 Oct 2008 00:05:40 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m9M43ibu002620; Wed, 22 Oct 2008 00:03:44 -0400 Date: Wed, 22 Oct 2008 00:03:44 -0400 Message-Id: <689cf6ae0810212057l60fa7e15u2c8c5e42af5d01da@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "?? ?" To: Multiple recipients of list Subject: Re: Spaces versus underscores in directory names? X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <7bb08a5f0810210925v6365438ey9c720555d41c1f54@mail.gmail.com> <50E2349F-92C2-4ED3-ADBC-EAD486846BF1@nist.gov> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 In-Reply-To: <50E2349F-92C2-4ED3-ADBC-EAD486846BF1@nist.gov> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 21 Oct 2008 21:07:57 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 34 I feel that people think question in his way and express his thinking, he just can do with what he think. but the reader or listener donot always think in his way, and he real had thought all thing? So it need sufficient exchange. The "face to face" is one way. It seems that NIST will meet some one whose submission pass primary election. If NIST meet them, they are luck to fullly explain their thinking. 2008/10/22, Larry Bassham : > > > I don't really care for the Ref and Opt Implementations if you uses spaces > or underscores. Underscores probably make things more portable and have > less problems. The important one is to make sure there is a root level > directory with the name "KAT_MCT". > > Larry B. > > > On Oct 21, 2008, at 12:38 PM, Jason Martin wrote: > > > > > Hi All, > > > > I realize this is a silly question, but since it could interfere with > > automated testing I'll ask anyway: > > > > In some places in the submission specifications the directory names > > have spaces in them, but in other places the spaces are either omitted > > or replaced with underscores. For example, compare > > "Reference_Implementation" in > > > > > http://csrc.nist.gov/groups/ST/hash/sha-3/Submission_Reqs/optical_media.html > > > > with "Reference Implementation" at the end of 2.C.1 in > > > > > http://csrc.nist.gov/groups/ST/hash/sha-3/Submission_Reqs/ref_and_optim.html > > > > Now, I realize that the difference doesn't matter to a human, but if > > it matters, please let me know which naming convention to use. > > > > Thanks, > > --jason > > > > Jason Worth Martin > > Asst. Professor of Mathematics > > http://www.math.jmu.edu/~martin > > > > > > > From hash-forum@nist.gov Wed Oct 22 13:06:03 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m9MK5vMk006239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Oct 2008 13:05:59 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m9MK4pRB001255; Wed, 22 Oct 2008 16:04:53 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m9MK2xuN011195; Wed, 22 Oct 2008 16:02:59 -0400 Date: Wed, 22 Oct 2008 16:02:59 -0400 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Doug Whiting To: Multiple recipients of list Subject: First Candidate Conference X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-To: "hash-forum@nist.gov" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 22 Oct 2008 13:05:59 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 35 Are there details available yet on the 1st Candidate Conference? Apparently it's to be right after FSE, but I haven't seen any official announcement -- I can't find anything on the web site, but maybe I'm missing it. I don't really want to make travel reservations until I know for sure. Thanks, Doug Whiting This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information which is protected from disclosure. Any unauthorized review, use, disclosure or distribution by any means is prohibited. If you are not the intended recipient, please contact the sender by reply email or at (408) 399-3500 and destroy all copies of the original message. From hash-forum@nist.gov Wed Oct 22 14:14:48 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m9MLEfaq016235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Oct 2008 14:14:42 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m9MLDKqm018798; Wed, 22 Oct 2008 17:13:22 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m9MLCPIN018570; Wed, 22 Oct 2008 17:12:25 -0400 Date: Wed, 22 Oct 2008 17:12:25 -0400 Message-Id: <7.0.1.0.2.20081022160957.02433c88@nist.gov> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Shu-jen Chang To: Multiple recipients of list Subject: Re: First Candidate Conference X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: text/plain; charset="us-ascii"; format=flowed Mime-Version: 1.0 References: In-Reply-To: X-To: hash-forum@nist.gov X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 22 Oct 2008 14:14:42 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 36 There was some hang-up on NIST's contract support that we are waiting for a contract to be awarded (soon) before we can work on the SHA-3 Conference logistics. We still plan to host the SHA-3 Conference from 2/25/2009 to 2/27/2009 (if necessary, to noon on 2/28/2009) in KU Leuven, Belgium. As frustrated as we have been about the contracting progress, we did not want to make any official announcement before this issue is resolved. Shu-jen At 04:02 PM 10/22/2008, Doug Whiting wrote: >Are there details available yet on the 1st Candidate Conference? >Apparently it's to be right after FSE, but I haven't seen any >official announcement -- I can't find anything on the web site, but >maybe I'm missing it. I don't really want to make travel >reservations until I know for sure. > >Thanks, >Doug Whiting > >This email message is for the sole use of the intended recipient(s) >and may contain confidential and privileged information which is >protected from disclosure. Any unauthorized review, use, disclosure >or distribution by any means is prohibited. If you are not the >intended recipient, please contact the sender by reply email or at >(408) 399-3500 and destroy all copies of the original message. From hash-forum@nist.gov Wed Oct 22 08:42:55 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m9MFgon4028486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Oct 2008 08:42:51 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m9MFfVmj016352; Wed, 22 Oct 2008 11:41:37 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m9MFetCS029037; Wed, 22 Oct 2008 11:40:55 -0400 Date: Wed, 22 Oct 2008 11:40:55 -0400 Message-Id: <7648FEB9-F4A9-47D0-A21F-D45348C76141@nist.gov> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Larry Bassham To: Multiple recipients of list Subject: Re: Dos or Unix EOL or does it matter X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed References: <7bb08a5f0810220758k2795ee48k2b3b4e0243b1e22f@mail.gmail.com> In-Reply-To: <7bb08a5f0810220758k2795ee48k2b3b4e0243b1e22f@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 22 Oct 2008 08:42:51 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 37 I think I've had a mix of both. Doesn't matter to me. Larry B. On Oct 22, 2008, at 11:10 AM, Jason Martin wrote: > > Hi All, > > Another pedantic question. For the optical media, do the text files > need to have DOS End-of-Line indicators or Unix End-of-Line indicates? > Again, I am assuming that humans can run the files through the > necessary conversions on an as-needed basis, but I don't want my > submission to break because the test scripts are assuming one format > and I'm using another. > > Also, the optical media is supposed to be ISO 9660, but there are > different flavors of ISO 9660. I'm assuming that ISO 9660 with Joliet > is okay since it's readable by every OS I know of... if it isn't > please let me know. > > Thanks, > jason > > Jason Worth Martin > Asst. Professor of Mathematics > http://www.math.jmu.edu/~martin > From hash-forum@nist.gov Wed Oct 22 08:14:12 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m9MFE6Ka023073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Oct 2008 08:14:08 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m9MFCUs5027139; Wed, 22 Oct 2008 11:12:36 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m9MFAtaE031977; Wed, 22 Oct 2008 11:10:55 -0400 Date: Wed, 22 Oct 2008 11:10:55 -0400 Message-Id: <7bb08a5f0810220758k2795ee48k2b3b4e0243b1e22f@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Jason Martin" To: Multiple recipients of list Subject: Dos or Unix EOL or does it matter X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 22 Oct 2008 08:14:08 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 38 Hi All, Another pedantic question. For the optical media, do the text files need to have DOS End-of-Line indicators or Unix End-of-Line indicates? Again, I am assuming that humans can run the files through the necessary conversions on an as-needed basis, but I don't want my submission to break because the test scripts are assuming one format and I'm using another. Also, the optical media is supposed to be ISO 9660, but there are different flavors of ISO 9660. I'm assuming that ISO 9660 with Joliet is okay since it's readable by every OS I know of... if it isn't please let me know. Thanks, jason Jason Worth Martin Asst. Professor of Mathematics http://www.math.jmu.edu/~martin From hash-forum@nist.gov Thu Oct 23 08:00:28 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m9NF0L7v031297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 23 Oct 2008 08:00:22 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m9NEw0rH002086; Thu, 23 Oct 2008 10:58:05 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m9NEtkdQ006034; Thu, 23 Oct 2008 10:55:46 -0400 Date: Thu, 23 Oct 2008 10:55:46 -0400 Message-Id: <49008e7a.2275420a.7710.407b@mx.google.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Danilo Gligoroski" To: Multiple recipients of list Subject: NIST methodology for measuring the clock cycles of optimized implementations X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Microsoft Office Outlook 12.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 In-Reply-To: <7.0.1.0.2.20081022160957.02433c88@nist.gov> References: <7.0.1.0.2.20081022160957.02433c88@nist.gov> X-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 23 Oct 2008 08:00:22 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 39 Hi, I want to ask NIST about their methodology for measuring the clock cycles of optimized implementations? METHODOLOGY I (we are measuring the speed of our hash functions by this methodology that is present in Dr. Brian Gladman implementation of SHA-2): "Experiment": 1. Measure the duration c01 of executing Hash once. 2. Measure the duration c02 of executing Hash two times. Total experiment: 1. Repeat the "Experiment" N times 2. c1 = Minimum( of all c01) 3. c2 = Minimum( of all c02) Estimated number of cycles for execution of Hash is: c2 - c1 METHODOLOGY II Dan Bernstein has different methodology (in his software eBASH for measuring speed of hash functions): "Experiment": Measure the duration c01 of executing Hash once. Total experiment 1. Repeat "Experiment" N times 2. c1 = Median (of all c01) Estimated number of cycles for execution of Hash is: c1 METHODOLOGY III Some source codes posted publicly on Internet, for measuring CPU cycles for different functions have the following methodology: "Experiment": Measure the duration c01 of executing Hash once Total experiment: 1. Repeat "Experiment" N times 2. c1 = Minimum (of all c01) Estimated number of cycles for execution of Hash is: c1 I think that it would be useful to know what will be the NIST methodology? Regards Danilo Gligoroski From hash-forum@nist.gov Thu Oct 23 08:40:41 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m9NFeasV004374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 23 Oct 2008 08:40:37 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m9NFdMSa023912; Thu, 23 Oct 2008 11:39:26 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m9NFcqu8001509; Thu, 23 Oct 2008 11:38:52 -0400 Date: Thu, 23 Oct 2008 11:38:52 -0400 Message-Id: <8DD4C4DE-CA78-46BD-B9B5-6566D2C759E6@nist.gov> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Larry Bassham To: Multiple recipients of list Subject: Re: NIST methodology for measuring the clock cycles of optimized implementations X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: <7.0.1.0.2.20081022160957.02433c88@nist.gov> <49008e7a.2275420a.7710.407b@mx.google.com> In-Reply-To: <49008e7a.2275420a.7710.407b@mx.google.com> Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 23 Oct 2008 08:40:37 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 40 I will probably be looking at something like: foreach message length foreach i in 1..100 obtain random message, M_i measure duration of hash(M_i) determine both min and median of durations And of course do that for each of the required hash lengths (224, 256, 384, 512) Larry B. On Oct 23, 2008, at 10:55 AM, Danilo Gligoroski wrote: > > Hi, > > I want to ask NIST about their methodology for measuring the clock > cycles of > optimized implementations? > > > METHODOLOGY I > (we are measuring the speed of our hash functions by this > methodology that > is present in Dr. Brian Gladman implementation of SHA-2): > "Experiment": > 1. Measure the duration c01 of executing Hash once. > 2. Measure the duration c02 of executing Hash two times. > > Total experiment: > 1. Repeat the "Experiment" N times > 2. c1 = Minimum( of all c01) > 3. c2 = Minimum( of all c02) > > Estimated number of cycles for execution of Hash is: c2 - c1 > > > METHODOLOGY II > Dan Bernstein has different methodology (in his software eBASH for > measuring > speed of hash functions): > "Experiment": > Measure the duration c01 of executing Hash once. > > Total experiment > 1. Repeat "Experiment" N times > 2. c1 = Median (of all c01) > > Estimated number of cycles for execution of Hash is: c1 > > > METHODOLOGY III > Some source codes posted publicly on Internet, for measuring CPU > cycles for > different functions have the following methodology: > "Experiment": > Measure the duration c01 of executing Hash once > > Total experiment: > 1. Repeat "Experiment" N times > 2. c1 = Minimum (of all c01) > > Estimated number of cycles for execution of Hash is: c1 > > > I think that it would be useful to know what will be the NIST > methodology? > > Regards > Danilo Gligoroski > > > From hash-forum@nist.gov Thu Oct 30 14:23:29 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m9ULNPDF016896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 30 Oct 2008 14:23:25 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m9ULLttL020019; Thu, 30 Oct 2008 17:22:00 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m9ULLQas023101; Thu, 30 Oct 2008 17:21:26 -0400 Date: Thu, 30 Oct 2008 17:21:26 -0400 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Paul Hoffman To: Multiple recipients of list Subject: Re: SHA-3 lounge X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: text/plain; charset="us-ascii" X-To: hash-forum@nist.gov References: In-Reply-To: Mime-Version: 1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: Delayed for 00:42:01 by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 30 Oct 2008 14:23:26 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, URI_HEX shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 42 At 4:38 PM -0400 10/30/08, Jean-Philippe Aumasson wrote: >Hi, > >This is to announce the creation of a "SHA-3 lounge", at >http://131002.net/sha3lounge/ I note that some attacks are (already) listed but there are no links to papers on the attacks. Such links could be as valuable as the links to the algorithms themselves. --Paul Hoffman, Director --VPN Consortium From hash-forum@nist.gov Thu Oct 30 15:19:52 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m9UMJkQZ024697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 30 Oct 2008 15:19:48 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m9UKeCu8024422; Thu, 30 Oct 2008 16:40:20 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m9UKcTZ6001283; Thu, 30 Oct 2008 16:38:29 -0400 Date: Thu, 30 Oct 2008 16:38:29 -0400 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Jean-Philippe Aumasson" To: Multiple recipients of list Subject: SHA-3 lounge X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 30 Oct 2008 15:19:48 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, URI_HEX shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 43 Hi, This is to announce the creation of a "SHA-3 lounge", at http://131002.net/sha3lounge/ Best, JP From hash-forum@nist.gov Thu Oct 30 20:38:26 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m9V3cKYn028036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 30 Oct 2008 20:38:22 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m9V3WOrt008949; Thu, 30 Oct 2008 23:32:26 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m9V3T4Hk022226; Thu, 30 Oct 2008 23:29:04 -0400 Date: Thu, 30 Oct 2008 23:29:04 -0400 Message-Id: <20081031032416.95228.qmail@cr.yp.to> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "D. J. Bernstein" To: Multiple recipients of list Subject: Generalized birthday attacks on PHASH X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Cc: ark@cs.rit.edu X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 30 Oct 2008 20:38:22 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 44 http://www.cs.rit.edu/~ark/20081117/slide01.html and the accompanying http://www.cs.rit.edu/~ark/20081117/phash.pdf (to be presented at Milcom 2008 in a few weeks) describe a hash function PHASH, apparently a SHA-3 submission. If I'm reading the documents correctly then the proposed 256-bit hash xors together 128 256-bit encryptions of separate blocks (and does a tree for longer messages), allowing * collisions to be found in time roughly 2^(256/9) by Wagner's generalized birthday attack on a machine of size 2^(256/9), or time roughly 2^(256/19) by my parallel generalized birthday attack on a machine of size 2^(256/9.5), * preimages to be found in time roughly 2^(256/17) on a machine of size 2^(256/8.5), etc. Similar comments, with doubled exponents, apply to the proposed 512-bit hash. We're still before the SHA-3 submission deadline. Perhaps the authors would like to revise their submission to specify a much larger block size and an appropriate output filter. Of course, it's also possible that I misread the paper and am stating an attack on something that isn't actually what the paper describes, and it's also possible that the authors didn't actually submit what the paper describes; if I'm raising a false alarm, my apologies! ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago From hash-forum@nist.gov Thu Oct 30 23:02:43 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m9V62cai008830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 30 Oct 2008 23:02:39 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m9V5kEMX021361; Fri, 31 Oct 2008 01:46:17 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m9V5jJc9026591; Fri, 31 Oct 2008 01:45:19 -0400 Date: Fri, 31 Oct 2008 01:45:19 -0400 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Jean-Philippe Aumasson" To: Multiple recipients of list Subject: Re: SHA-3 lounge X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 In-Reply-To: X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 30 Oct 2008 23:02:39 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, URI_HEX shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 45 @Simon: I've been informed of the existence of a similar project organized by ECRYPT II. We may merge the two projects. @Paul: The attacks cited are reported in the MD6 document, and have been discovered by non-coauthors. That's why I've put them here. On Thu, Oct 30, 2008 at 10:21 PM, Paul Hoffman wrote: > > At 4:38 PM -0400 10/30/08, Jean-Philippe Aumasson wrote: >>Hi, >> >>This is to announce the creation of a "SHA-3 lounge", at >>http://131002.net/sha3lounge/ > > I note that some attacks are (already) listed but there are no links to papers on the attacks. Such links could be as valuable as the links to the algorithms themselves. > > --Paul Hoffman, Director > --VPN Consortium > > From hash-forum@nist.gov Fri Oct 31 06:03:15 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m9VD3ASp020124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 31 Oct 2008 06:03:11 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m9VD1sQT012620; Fri, 31 Oct 2008 09:02:04 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m9VD0Jah002646; Fri, 31 Oct 2008 09:00:19 -0400 Date: Fri, 31 Oct 2008 09:00:19 -0400 Message-Id: <200810310848.19246.ark@cs.rit.edu> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Alan Kaminsky To: Multiple recipients of list Subject: Re: Generalized birthday attacks on PHASH X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 In-Reply-To: <20081031032416.95228.qmail@cr.yp.to> References: <20081031032416.95228.qmail@cr.yp.to> X-To: "D. J. Bernstein" , hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 31 Oct 2008 06:03:11 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 46 On Thursday 30 October 2008 11:24 pm, D. J. Bernstein wrote: > http://www.cs.rit.edu/~ark/20081117/slide01.html and the accompanying > http://www.cs.rit.edu/~ark/20081117/phash.pdf (to be presented at Milcom > 2008 in a few weeks) describe a hash function PHASH, apparently a SHA-3 > submission. Dr. Bernstein: Thank you for your comments on PHASH. PHASH is a design concept for parallelizable hash functions, it is not a hash function submitted to the SHA-3 competition. -- -Alan Kaminsky Associate Professor Department of Computer Science B. Thomas Golisano College of Computing and Information Sciences Rochester Institute of Technology From hash-forum@nist.gov Fri Oct 31 10:54:47 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m9VHse3G031321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 31 Oct 2008 10:54:42 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m9VHoBsw000411; Fri, 31 Oct 2008 13:51:11 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m9VHl2gH025004; Fri, 31 Oct 2008 13:47:02 -0400 Date: Fri, 31 Oct 2008 13:47:02 -0400 Message-Id: <490B4190.6010905@mit.edu> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Ronald L. Rivest" To: Multiple recipients of list Subject: Re: SHA-3 lounge X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: References: MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 31 Oct 2008 10:54:43 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED,URI_HEX shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 47 Hi Jean-Philippe -- The SHA-3 hash lounge is a good idea. I have a minor issue which perhaps you can figure out a good way to handle. I do worry that merely listing "attacks" may imply to some that a scheme is somehow broken, whereas in truth it is "more validated". Similarly, listing "none yet" under the attacks may imply to some that the scheme has withstood all attackers, whereas in fact in may just not have been looked at yet. I'm not sure how one could best address this. Maybe listing "attacks and security studies" rather than just "attacks"? Maybe (e.g. for MD6) saying how many rounds MD6 has in addition to how many can be distinguished from random, e.g. ("(MD6 has 96/104/136/168 rounds for output sizes 224/256/384/512 bits.)") Thanks! Cheers, Ron On 10/31/2008 1:45 AM, Jean-Philippe Aumasson wrote: > @Simon: > > I've been informed of the existence of a similar project organized by > ECRYPT II. We may merge the two projects. > > @Paul: > > The attacks cited are reported in the MD6 document, and have been > discovered by non-coauthors. That's why I've put them here. > > > On Thu, Oct 30, 2008 at 10:21 PM, Paul Hoffman wrote: >> At 4:38 PM -0400 10/30/08, Jean-Philippe Aumasson wrote: >>> Hi, >>> >>> This is to announce the creation of a "SHA-3 lounge", at >>> http://131002.net/sha3lounge/ >> I note that some attacks are (already) listed but there are no links to papers on the attacks. Such links could be as valuable as the links to the algorithms themselves. >> >> --Paul Hoffman, Director >> --VPN Consortium >> >> > > > -- Ronald L. Rivest Room 32-G692, Stata Center, MIT, Cambridge MA 02139 Tel 617-253-5880, Email From hash-forum@nist.gov Fri Oct 31 11:20:13 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m9VIK77r003019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 31 Oct 2008 11:20:09 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m9VIIJkR026172; Fri, 31 Oct 2008 14:18:25 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m9VIHBW8021652; Fri, 31 Oct 2008 14:17:11 -0400 Date: Fri, 31 Oct 2008 14:17:11 -0400 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Jean-Philippe Aumasson" To: Multiple recipients of list Subject: Re: SHA-3 lounge X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <490B4190.6010905@mit.edu> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 In-Reply-To: <490B4190.6010905@mit.edu> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 31 Oct 2008 11:20:09 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, URI_HEX shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 48 Hi Ronald, No problem with that, agree that "Attacks" sounds too negative, so I've changed it to "Cryptanalysis", which is more neutral. Hope this will be okay to you. Best, JP On Fri, Oct 31, 2008 at 6:47 PM, Ronald L. Rivest wrote: > > Hi Jean-Philippe -- > > The SHA-3 hash lounge is a good idea. > > I have a minor issue which perhaps you can figure out > a good way to handle. > > I do worry that merely listing "attacks" may imply to some > that a scheme is somehow broken, whereas in truth it is > "more validated". Similarly, listing "none yet" under the > attacks may imply to some that the scheme has withstood all > attackers, whereas in fact in may just not have been looked > at yet. > > I'm not sure how one could best address this. Maybe listing > "attacks and security studies" rather than just "attacks"? Maybe > (e.g. for MD6) saying how many rounds MD6 has in addition to how > many can be distinguished from random, e.g. ("(MD6 has 96/104/136/168 > rounds for output sizes 224/256/384/512 bits.)") > > Thanks! > > Cheers, > Ron > > > On 10/31/2008 1:45 AM, Jean-Philippe Aumasson wrote: >> >> @Simon: >> >> I've been informed of the existence of a similar project organized by >> ECRYPT II. We may merge the two projects. >> >> @Paul: >> >> The attacks cited are reported in the MD6 document, and have been >> discovered by non-coauthors. That's why I've put them here. >> >> >> On Thu, Oct 30, 2008 at 10:21 PM, Paul Hoffman >> wrote: >>> >>> At 4:38 PM -0400 10/30/08, Jean-Philippe Aumasson wrote: >>>> >>>> Hi, >>>> >>>> This is to announce the creation of a "SHA-3 lounge", at >>>> http://131002.net/sha3lounge/ >>> >>> I note that some attacks are (already) listed but there are no links to >>> papers on the attacks. Such links could be as valuable as the links to the >>> algorithms themselves. >>> >>> --Paul Hoffman, Director >>> --VPN Consortium >>> >>> >> >> >> > > -- > Ronald L. Rivest > Room 32-G692, Stata Center, MIT, Cambridge MA 02139 > Tel 617-253-5880, Email > > From hash-forum@nist.gov Fri Oct 31 11:26:20 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id m9VIQEa4004036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 31 Oct 2008 11:26:16 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m9VIIVA8021446; Fri, 31 Oct 2008 14:18:36 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m9VIIAAt023500; Fri, 31 Oct 2008 14:18:10 -0400 Date: Fri, 31 Oct 2008 14:18:10 -0400 Message-Id: <96804547672778596094702937572212351378-Webmail2@me.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Adam Montville To: Multiple recipients of list Subject: Re: SHA-3 lounge X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 31 Oct 2008 11:26:16 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, URI_HEX shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 49 For what it's worth, I agree with Mr. Rivest -- the first thing that came to mind when I saw the "attacks" was that there were some successes against the associated submissions -- if that section is not intended to be used as a collection of (semi-) successful attacks. Some suggestions: "Attack Assessments" or "Security Assessments." Use of the word "assessment" seems to appropriately convey the essence of gathered papers -- the existence of a paper respecting a given submission does not imply successful attack or a broken algorithm,and the non-existence of a paper respecting a given submission implies only that no such assessment has yet been published/posted. Kind Regards, Adam On Friday, October 31, 2008, at 10:47AM, "Ronald L. Rivest" wrote: > >Hi Jean-Philippe -- > >The SHA-3 hash lounge is a good idea. > >I have a minor issue which perhaps you can figure out >a good way to handle. > >I do worry that merely listing "attacks" may imply to some >that a scheme is somehow broken, whereas in truth it is >"more validated". Similarly, listing "none yet" under the >attacks may imply to some that the scheme has withstood all >attackers, whereas in fact in may just not have been looked >at yet. > >I'm not sure how one could best address this. Maybe listing >"attacks and security studies" rather than just "attacks"? Maybe >(e.g. for MD6) saying how many rounds MD6 has in addition to how >many can be distinguished from random, e.g. ("(MD6 has 96/104/136/168 >rounds for output sizes 224/256/384/512 bits.)") > >Thanks! > >Cheers, >Ron > > >On 10/31/2008 1:45 AM, Jean-Philippe Aumasson wrote: >> @Simon: >> >> I've been informed of the existence of a similar project organized by >> ECRYPT II. We may merge the two projects. >> >> @Paul: >> >> The attacks cited are reported in the MD6 document, and have been >> discovered by non-coauthors. That's why I've put them here. >> >> >> On Thu, Oct 30, 2008 at 10:21 PM, Paul Hoffman wrote: >>> At 4:38 PM -0400 10/30/08, Jean-Philippe Aumasson wrote: >>>> Hi, >>>> >>>> This is to announce the creation of a "SHA-3 lounge", at >>>> http://131002.net/sha3lounge/ >>> I note that some attacks are (already) listed but there are no links to papers on the attacks. Such links could be as valuable as the links to the algorithms themselves. >>> >>> --Paul Hoffman, Director >>> --VPN Consortium >>> >>> >> >> >> > >-- > Ronald L. Rivest > Room 32-G692, Stata Center, MIT, Cambridge MA 02139 > Tel 617-253-5880, Email > > > From hash-forum@nist.gov Fri Oct 31 18:32:00 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA11VsY5022498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 31 Oct 2008 18:31:55 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA11Uodk004626; Fri, 31 Oct 2008 21:30:55 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA11TPDl026766; Fri, 31 Oct 2008 21:29:25 -0400 Date: Fri, 31 Oct 2008 21:29:25 -0400 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Sean O'Neil" To: Multiple recipients of list Subject: Re: SHA-3 lounge X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 31 Oct 2008 18:31:56 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED,URI_HEX shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 50 > http://131002.net/sha3lounge/ Yes, EnRUPT was indeed submitted: http://www.enrupt.com/enrupt_sha-3_submission Best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. From hash-forum@nist.gov Sat Nov 1 17:33:15 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA20X9W3015768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 1 Nov 2008 17:33:11 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA20WJN6026715; Sat, 1 Nov 2008 20:32:24 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA20Upa6022101; Sat, 1 Nov 2008 20:30:51 -0400 Date: Sat, 1 Nov 2008 20:30:51 -0400 Message-Id: <20081102002411.34334.qmail@cr.yp.to> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "D. J. Bernstein" To: Multiple recipients of list Subject: Re: SHA-3 lounge X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas In-Reply-To: <490B4190.6010905@mit.edu> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 01 Nov 2008 17:33:11 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 51 Ronald L. Rivest writes: > Maybe (e.g. for MD6) saying how many rounds MD6 has in addition to how > many can be distinguished from random, e.g. ("(MD6 has 96/104/136/168 > rounds for output sizes 224/256/384/512 bits.)") In http://cr.yp.to/streamciphers/broken-20080330.pdf and other lists of stream-cipher attacks I included a separate statement of the best attack on each cipher---where, of course, different round counts make different ciphers. For example, here are the best attacks known on five different stream ciphers: 256-bit Salsa20/7: 2^151-operation attack by Aumasson et al. 256-bit Salsa20/8: 2^251-operation attack by Aumasson et al. 256-bit Salsa20/9 and above: brute force 128-bit Salsa20/7: 2^111-operation attack by Aumasson et al. 128-bit Salsa20/8 and above: brute force In the end the eSTREAM committee selected Salsa20/12 (and HC-128 and Rabbit and SOSEMANUK and various hardware ciphers) and didn't seem to care that I had defined Salsa20 as Salsa20/20. For MD6 it sounds like the starting situation is something like 256-bit MD6/18: 2^100-operation attack 256-bit MD6/19 and above: brute force and something similar for other output sizes; so I'd suggest reporting exactly that (with correct numbers and references) in lists of attacks. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago From hash-forum@nist.gov Sat Nov 1 22:01:52 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA251kq2010556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 1 Nov 2008 22:01:48 -0700 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA250t9o025086; Sun, 2 Nov 2008 01:00:57 -0400 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA24xVCP021194; Sun, 2 Nov 2008 00:59:32 -0400 Date: Sun, 2 Nov 2008 00:59:31 -0400 Message-Id: <490D326A.9030902@mit.edu> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Ronald L. Rivest" To: Multiple recipients of list Subject: Re: SHA-3 lounge X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: <20081102002411.34334.qmail@cr.yp.to> References: <20081102002411.34334.qmail@cr.yp.to> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 01 Nov 2008 22:01:48 -0700 (PDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 52 Hi Dan -- I agree with you. The MD6 report gives an appropriate naming scheme, e.g. MD6-256-r18 for MD6 with 256-bit outputs and 18 rounds. However, this doesn't address the other point of my note, which is that it may be helpful when folks see an attack on a reduced-round version to also see how many rounds are in the full version, as proposed... But I'm sure we'll all be seeing many charts comparing this and that aspect of all of the submissions... Do we know how many submissions were made?? Cheers, Ron On 11/1/2008 8:30 PM, D. J. Bernstein wrote: > Ronald L. Rivest writes: >> Maybe (e.g. for MD6) saying how many rounds MD6 has in addition to how >> many can be distinguished from random, e.g. ("(MD6 has 96/104/136/168 >> rounds for output sizes 224/256/384/512 bits.)") > > In http://cr.yp.to/streamciphers/broken-20080330.pdf and other lists of > stream-cipher attacks I included a separate statement of the best attack > on each cipher---where, of course, different round counts make different > ciphers. For example, here are the best attacks known on five different > stream ciphers: > > 256-bit Salsa20/7: 2^151-operation attack by Aumasson et al. > 256-bit Salsa20/8: 2^251-operation attack by Aumasson et al. > 256-bit Salsa20/9 and above: brute force > > 128-bit Salsa20/7: 2^111-operation attack by Aumasson et al. > 128-bit Salsa20/8 and above: brute force > > In the end the eSTREAM committee selected Salsa20/12 (and HC-128 and > Rabbit and SOSEMANUK and various hardware ciphers) and didn't seem to > care that I had defined Salsa20 as Salsa20/20. > > For MD6 it sounds like the starting situation is something like > > 256-bit MD6/18: 2^100-operation attack > 256-bit MD6/19 and above: brute force > > and something similar for other output sizes; so I'd suggest reporting > exactly that (with correct numbers and references) in lists of attacks. > > ---D. J. Bernstein > Research Professor, Computer Science, University of Illinois at Chicago > > > -- Ronald L. Rivest Room 32-G692, Stata Center, MIT, Cambridge MA 02139 Tel 617-253-5880, Email From hash-forum@nist.gov Mon Nov 3 12:00:15 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA3K0598027629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 3 Nov 2008 12:00:07 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA3IW1ZI015978; Mon, 3 Nov 2008 13:32:05 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA3ISt6p029135; Mon, 3 Nov 2008 13:28:55 -0500 Date: Mon, 3 Nov 2008 13:28:55 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Doug Whiting To: Multiple recipients of list Subject: algorithm "release" schedule X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_E1BEC7FFF6C889489E8C09F722F185CD17CD73E5A0SJCXCH07hifnc_" X-To: "hash-forum@nist.gov" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: Delayed for 01:25:08 by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 03 Nov 2008 12:00:08 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 53 --_000_E1BEC7FFF6C889489E8C09F722F185CD17CD73E5A0SJCXCH07hifnc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable When will the submitted algorithm details be made available on the NIST web= site? Is there a schedule for this? Doug Whiting ________________________________ This email message is for the sole use of the intended recipient(s) and may= contain confidential and privileged information which is protected from di= sclosure. Any unauthorized review, use, disclosure or distribution by any m= eans is prohibited. If you are not the intended recipient, please contact t= he sender by reply email or at (408) 399-3500 and destroy all copies of the= original message. --_000_E1BEC7FFF6C889489E8C09F722F185CD17CD73E5A0SJCXCH07hifnc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

When will the submitted algorithm details be made av= ailable on the NIST web site? Is there a schedule for this?

 

Doug Whiting

 


This email message is for = the sole use of the intended recipient(s) and may contain confidential and = privileged information which is protected from disclosure. Any unauthorized= review, use, disclosure or distribution by any means is prohibited. If you are not the intended recipient, please = contact the sender by reply email or at (408) 399-3500 and destroy all copi= es of the original message.
 --_000_E1BEC7FFF6C889489E8C09F722F185CD17CD73E5A0SJCXCH07hifnc_-- From hash-forum@nist.gov Mon Nov 3 13:12:21 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA3LCDF6011147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 3 Nov 2008 13:12:16 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA3L9Snw016182; Mon, 3 Nov 2008 16:09:30 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA3L6IOk027504; Mon, 3 Nov 2008 16:06:18 -0500 Date: Mon, 3 Nov 2008 16:06:18 -0500 Message-Id: <7.0.1.0.2.20081103133801.024be5c0@nist.gov> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Shu-jen Chang To: Multiple recipients of list Subject: Re: algorithm "release" schedule X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: text/html; charset="us-ascii" Mime-Version: 1.0 References: In-Reply-To: X-To: hash-forum@nist.gov X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 03 Nov 2008 13:12:17 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, MIME_HTML_ONLY,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 54 We are diligently opening and processing the submission packages. As one would expect, many packages arrived on the last minute, and quite a few submitters sent in updates soon after mailing their submissions. We need time to process and review all of these before we can determine which submissions are "complete and proper". As soon as we are ready, we will post the first round candidates at one shot. We don't have a release schedule yet, but we are trying the best that we can.

We will announce the number of submissions that we have received soon.

Thanks,
Shu-jen


At 01:28 PM 11/3/2008, you wrote:
When will the submitted algorithm details be made available on the NIST web site? Is there a schedule for this?
 
Doug Whiting
 

This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information which is protected from disclosure. Any unauthorized review, use, disclosure or distribution by any means is prohibited. If you are not the intended recipient, please contact the sender by reply email or at (408) 399-3500 and destroy all copies of the original message.

From hash-forum@nist.gov Tue Nov 4 07:00:35 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA4F0QcX008528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Nov 2008 07:00:31 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA4EvQsl026428; Tue, 4 Nov 2008 09:58:44 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA4ErFZ1026480; Tue, 4 Nov 2008 09:53:15 -0500 Date: Tue, 4 Nov 2008 09:53:15 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Dmitry Khovratovich" To: Multiple recipients of list Subject: Attack on EnRUPT X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/alternative; boundary="----=_Part_66608_4299927.1225810279753" MIME-Version: 1.0 X-To: "Multiple recipients of list" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 04 Nov 2008 07:00:31 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 55 ------=_Part_66608_4299927.1225810279753 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, we have found a preimage attack on EnRUPT-512 with complexity 2^480. The paper is now at our web-site http://lj.streamclub.ru/papers/hash/enrupt.pdf and is to be submitted to ePrint. -- Best regards, Dmitry Khovratovich and Ivica Nikolic University of Luxembourg, Laboratory of Algorithmics, Cryptography and Security ------=_Part_66608_4299927.1225810279753 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all,

we have found a preimage attack on EnRUPT-512 with complexity 2^480. The paper is now at our web-site
http://lj.streamclub.ru/papers/hash/enrupt.pdf

and is to be submitted to ePrint.

--
Best regards,
Dmitry Khovratovich and Ivica Nikolic

University of Luxembourg,
Laboratory of Algorithmics, Cryptography and Security
------=_Part_66608_4299927.1225810279753-- From hash-forum@nist.gov Tue Nov 4 07:49:31 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA4FnN8Y014961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Nov 2008 07:49:26 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA4FlmVb006819; Tue, 4 Nov 2008 10:47:53 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA4FkdLQ008807; Tue, 4 Nov 2008 10:46:39 -0500 Date: Tue, 4 Nov 2008 10:46:39 -0500 Message-Id: <7643C090-81EA-470F-BA47-01B1D61160D1@cryptolib.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Sean O'Neil" To: Multiple recipients of list Subject: Re: Attack on EnRUPT X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 04 Nov 2008 07:49:27 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 56 > we have found a preimage attack on EnRUPT-512 with complexity > 2^480. The paper is now at our web-site > http://lj.streamclub.ru/papers/hash/enrupt.pdf Now that's a bit of a lie. The time complexity is 2^480, plus the not mentioned fine print of whopping 2^384 memory! What is the total complexity? 2^864? How many EnRUPT circuits can fit in 2^384 bits of memory? Quoting the specification: "The cheapest generic attacks are the parallel brute-force attacks. One ïrRUPT circuit is equivalent to about (H+P+5)â‹…w bits of memory. ïrRUPT updates P words of the state per clock cycle. Thus only the attacks requiring fewer clock cycles than would do as many ïrRUPT circuits as can fit in the same area as the code, all the processors and all the memory required for the attack, can be considered faster or cheaper than the brute force. Please measure your attacks correctly." In other words, one EnRUPT-512 circuit is as big as less than two kilobits of memory or 2^11. The 2^373 EnRUPT circuits that can fit in the memory required for that "attack" will find a preimage in 2^139 time. Far from 2^480! The same goes for TMTO that applies to every single algorithm out there. Any 512-bit secure cipher or a 512-bit hash preimage can be broken with ~2^256 RAM and ~2^256 time. Or with 2^384 RAM in 2^128 time. But 2^480??? This "attack" only proves the high security margin of EnRUPT. Best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. From hash-forum@nist.gov Tue Nov 4 09:34:24 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA4HYHhl029929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Nov 2008 09:34:19 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA4HSBHb003059; Tue, 4 Nov 2008 12:28:17 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA4HPuIC018438; Tue, 4 Nov 2008 12:25:57 -0500 Date: Tue, 4 Nov 2008 12:25:56 -0500 Message-Id: <4910839C.4050005@larc.usp.br> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Paulo S. L. M. Barreto" To: Multiple recipients of list Subject: Re: Attack on EnRUPT X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 In-Reply-To: <7643C090-81EA-470F-BA47-01B1D61160D1@cryptolib.com> References: <7643C090-81EA-470F-BA47-01B1D61160D1@cryptolib.com> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 04 Nov 2008 09:34:20 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 57 Sean O'Neil wrote: > In other words, one EnRUPT-512 circuit is as big as less than two > kilobits of memory or 2^11. The 2^373 EnRUPT circuits that can fit in > the memory required for that "attack" will find a preimage in 2^139 > time. Far from 2^480! Fair point... > This "attack" only proves the high security margin of EnRUPT. .. but here I tend to disagree. The attack proves nothing at all; it's just irrelevant. Best, Paulo Barreto. From hash-forum@nist.gov Tue Nov 4 10:03:55 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA4I3mPU002040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Nov 2008 10:03:51 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA4HvAOi007516; Tue, 4 Nov 2008 12:57:20 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA4HuPYw016237; Tue, 4 Nov 2008 12:56:25 -0500 Date: Tue, 4 Nov 2008 12:56:25 -0500 Message-Id: <7EDEBED9-EDC9-4663-B71B-94C567C080C6@cryptolib.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Sean O'Neil" To: Multiple recipients of list Subject: Re: Attack on EnRUPT X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed References: <7643C090-81EA-470F-BA47-01B1D61160D1@cryptolib.com> <4910839C.4050005@larc.usp.br> In-Reply-To: <4910839C.4050005@larc.usp.br> Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 04 Nov 2008 10:03:51 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 58 >> This "attack" only proves the high security margin of EnRUPT. > > .. but here I tend to disagree. The attack proves nothing at all; > it's just > irrelevant. Yes, you are right. I have exaggerated there. What I meant to say is that if that is the only thing people could come up with since the publication of ïrRUPT in August and since the publication of EnRUPT in February, my own confidence in it is growing. It is the simplest algorithm on earth. It is such a simple algorithm, that any structural flaw would result in a very quick attack breaking it completely. What puzzles me is why they hadn't simply e-mailed me about it before the submission deadline? It is certainly not a 3-day attack. It must have taken weeks just to draw the pictures and write that paper... Looks like we are not all friends here. Best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. From hash-forum@nist.gov Tue Nov 4 10:31:52 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA4IVi5S005499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Nov 2008 10:31:46 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA4IP1HU031144; Tue, 4 Nov 2008 13:25:41 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA4IOUZP010571; Tue, 4 Nov 2008 13:24:30 -0500 Date: Tue, 4 Nov 2008 13:24:30 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Dmitry Khovratovich" To: Multiple recipients of list Subject: Re: Attack on EnRUPT X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <7643C090-81EA-470F-BA47-01B1D61160D1@cryptolib.com> <4910839C.4050005@larc.usp.br> <7EDEBED9-EDC9-4663-B71B-94C567C080C6@cryptolib.com> Content-Type: multipart/alternative; boundary="----=_Part_71647_18015320.1225822715113" MIME-Version: 1.0 In-Reply-To: <7EDEBED9-EDC9-4663-B71B-94C567C080C6@cryptolib.com> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 04 Nov 2008 10:31:47 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 59 ------=_Part_71647_18015320.1225822715113 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline We started working on the function yesterday. As soon as the paper was finished we sent a message. On Tue, Nov 4, 2008 at 6:56 PM, Sean O'Neil wrote: > > What puzzles me is why they hadn't simply e-mailed me about it before the > submission deadline? It is certainly not a 3-day attack. It must have taken > weeks just to draw the pictures and write that paper... Looks like we are > not all friends here. > > > Best regards, > Sean O'Neil > http://www.enrupt.com/ - Raising the bar. > > > > -- Best regards, Dmitry Khovratovich University of Luxembourg, Laboratory of Algorithms, Cryptography and Security, + 352 46 66 44 5478 ------=_Part_71647_18015320.1225822715113 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline We started working on the function yesterday. As soon as the paper was finished we sent a message.


On Tue, Nov 4, 2008 at 6:56 PM, Sean O'Neil <sean@cryptolib.com> wrote:

What puzzles me is why they hadn't simply e-mailed me about it before the submission deadline? It is certainly not a 3-day attack. It must have taken weeks just to draw the pictures and write that paper... Looks like we are not all friends here.


Best regards,
Sean O'Neil
http://www.enrupt.com/ - Raising the bar.






--
Best regards,
Dmitry Khovratovich

University of Luxembourg,
Laboratory of Algorithms, Cryptography and Security,
+ 352 46 66 44 5478
------=_Part_71647_18015320.1225822715113-- From hash-forum@nist.gov Tue Nov 4 10:48:19 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA4ImDXr007546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Nov 2008 10:48:15 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA4IdDwo011093; Tue, 4 Nov 2008 13:39:26 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA4IcaZ2009945; Tue, 4 Nov 2008 13:38:36 -0500 Date: Tue, 4 Nov 2008 13:38:36 -0500 Message-Id: <5035DD26-7D00-44EC-98C0-9D963871AAF7@cryptolib.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Sean O'Neil" To: Multiple recipients of list Subject: Re: Attack on EnRUPT X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: <7643C090-81EA-470F-BA47-01B1D61160D1@cryptolib.com> <4910839C.4050005@larc.usp.br> <7EDEBED9-EDC9-4663-B71B-94C567C080C6@cryptolib.com> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 04 Nov 2008 10:48:15 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 60 On 4 Nov 2008, at 19:24, Dmitry Khovratovich wrote: > We started working on the function yesterday. As soon as the paper > was finished we sent a message. Wow! That was unbelievably fast! Good job. However, an attack with the total time+memory complexity of 2^864 does not break the 512-bit TMDTO or parallel brute-force resistance of any 512-bit hash. You may want to correct your paper to tone down your claims a little. Best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. From hash-forum@nist.gov Tue Nov 4 11:15:43 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA4JFaAR011289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Nov 2008 11:15:38 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA4JCqDm001415; Tue, 4 Nov 2008 14:12:57 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA4JCMXP013999; Tue, 4 Nov 2008 14:12:22 -0500 Date: Tue, 4 Nov 2008 14:12:22 -0500 Message-Id: <49109E46.5030806@qualcomm.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Greg Rose To: Multiple recipients of list Subject: Errata in specification X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed MIME-Version: 1.0 X-To: "hash-forum@nist.gov" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 04 Nov 2008 11:15:39 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 61 I'd like to thank Tor Bjøstad from the University of Bergen for spotting a couple of errors in the specification for Boole. While they are minor in keystrokes, they are of course fundamentally important. The errata appear below. I'm sure I'm not the only one to have made such errors. What should I (and others) do to correct such a mistake? regards, Greg. Errata: On page 7 section 3.2, describing cycling the register, in step 1, "for i=1..14" should be "for i = 0..14". In figure 1 on page 6, the arrow leading from "rsum" to the register is one cell too far right. (If revising the paper, I would probably write text to explain the diagram too.) In section 3.6, describing the nonlinear functions (in two places), "fourth-degree function of 5 bits of the input" should say "fourth-degree function of 9 bits of the input". Similarly, in the 64-bit case, "9 bits of the input" should say "26 bits of the input". From hash-forum@nist.gov Tue Nov 4 11:31:05 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA4JUxg7013203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Nov 2008 11:31:01 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA4JR2Qd026833; Tue, 4 Nov 2008 14:27:07 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA4JQd2K009999; Tue, 4 Nov 2008 14:26:39 -0500 Date: Tue, 4 Nov 2008 14:26:39 -0500 Message-Id: <49109E9D.1080702@ellipticsemi.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Tom St Denis To: Multiple recipients of list Subject: Re: Attack on EnRUPT X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: <7EDEBED9-EDC9-4663-B71B-94C567C080C6@cryptolib.com> References: <7643C090-81EA-470F-BA47-01B1D61160D1@cryptolib.com> <4910839C.4050005@larc.usp.br> <7EDEBED9-EDC9-4663-B71B-94C567C080C6@cryptolib.com> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 04 Nov 2008 11:31:01 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 62 Sean O'Neil wrote: > >>> This "attack" only proves the high security margin of EnRUPT. >> >> .. but here I tend to disagree. The attack proves nothing at all; >> it's just >> irrelevant. > > Yes, you are right. I have exaggerated there. What I meant to say is > that if that is the only thing people could come up with since the > publication of ïrRUPT in August and since the publication of EnRUPT in > February, my own confidence in it is growing. It is the simplest > algorithm on earth. It is such a simple algorithm, that any structural > flaw would result in a very quick attack breaking it completely. > > What puzzles me is why they hadn't simply e-mailed me about it before > the submission deadline? It is certainly not a 3-day attack. It must > have taken weeks just to draw the pictures and write that paper... > Looks like we are not all friends here. > > Best regards, > Sean O'Neil > http://www.enrupt.com/ - Raising the bar. Totally off topic, just wanted to point out that cryptolib.com (found via enrupt.com) is vulnerable to cross-site scripting attacks. Also calling a library "cryptolib" is a bit lame and sounds like cryptlib (a much more stable/mature library). http://cryptolib.com/challenges.php?nick=%3Cscript%3Ealert(%22I%27m+an+XSS%22)%3B%3C%2Fscript%3E :-) Tom From hash-forum@nist.gov Tue Nov 4 11:47:25 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA4JlI5t015415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Nov 2008 11:47:20 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA4JfMr2024933; Tue, 4 Nov 2008 14:41:27 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA4JejvG005722; Tue, 4 Nov 2008 14:40:45 -0500 Date: Tue, 4 Nov 2008 14:40:45 -0500 Message-Id: <7bb08a5f0811041138x6c740526mc34e2b513e3a08c4@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Jason Martin" To: Multiple recipients of list Subject: Typo in ESSENCE compression function specification X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 04 Nov 2008 11:47:21 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 63 Hi All, Indeed Greg is not alone in having typographical errors! An anonymous read just pointed out to me two minor typos in the specification for the compression function of ESSENCE. In the pseudo-code listed on pages 4 and 13 in "ESSENCE: A Family of Cryptographic Hashing Algorithms," the line "r1 := r1" should be "r2 := r1". (The diagrams are correct.) I have made the correction in the on-line version of the document. --jason Jason Worth Martin Asst. Professor of Mathematics http://www.math.jmu.edu/~martin From hash-forum@nist.gov Tue Nov 4 13:13:05 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA4LCxAe026379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Nov 2008 13:13:01 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA4L8YUX015781; Tue, 4 Nov 2008 16:08:41 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA4L6vUI018500; Tue, 4 Nov 2008 16:06:57 -0500 Date: Tue, 4 Nov 2008 16:06:57 -0500 Message-Id: <3A4F1C2F-626B-4E77-8B5F-EE27D09A803C@cryptolib.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Sean O'Neil" To: Multiple recipients of list Subject: Re: Attack on EnRUPT X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: <7643C090-81EA-470F-BA47-01B1D61160D1@cryptolib.com> <4910839C.4050005@larc.usp.br> <7EDEBED9-EDC9-4663-B71B-94C567C080C6@cryptolib.com> <49109E9D.1080702@ellipticsemi.com> In-Reply-To: <49109E9D.1080702@ellipticsemi.com> Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 04 Nov 2008 13:13:01 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 64 > Totally off topic, just wanted to point out that cryptolib.com > (found via enrupt.com) is vulnerable to cross-site scripting attacks. Not anymore it isn't. All the original scripts were by Mr. Hayz. I hadn't checked them too much for security issues. Thanks for reporting it, although this mailing list is hardly the right place for it. Best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. From hash-forum@nist.gov Tue Nov 4 13:23:58 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA4LNq3u027843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Nov 2008 13:23:54 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA4LMaA8020896; Tue, 4 Nov 2008 16:22:53 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA4LM6B4015578; Tue, 4 Nov 2008 16:22:06 -0500 Date: Tue, 4 Nov 2008 16:22:06 -0500 Message-Id: <.1225833412@magma.ca> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Tom St Denis To: Multiple recipients of list Subject: Re: Re: Attack on EnRUPT X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-To: "Sean O'Neil" X-To: Multiple recipients of list , X-Mailer: AtMail PHP 5.2 MIME-Version: 1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 04 Nov 2008 13:23:54 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 65 On Tue 04/11/08 4:06 PM , "Sean O'Neil" sean@cryptolib.com sent: > > > > Totally off topic, just wanted to point out that > cryptolib.com > > (found via enrupt.com) is vulnerable to cross-site > scripting attacks. > > > Not anymore it isn't. All the original scripts were by Mr. Hayz. I > > hadn't checked them too much for security issues. Thanks for > > reporting it, although this mailing list is hardly the right place > > for it. Then don't advertise your website in your signature. :-) Tom From hash-forum@nist.gov Tue Nov 4 13:38:02 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA4Lbus1029632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Nov 2008 13:37:58 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA4LaZkO030000; Tue, 4 Nov 2008 16:36:38 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA4LZvMQ010468; Tue, 4 Nov 2008 16:35:57 -0500 Date: Tue, 4 Nov 2008 16:35:57 -0500 Message-Id: <20081104222556.tbzwfxpr0g40kkkw@email.ee.ethz.ch> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: henzen@iis.ee.ethz.ch To: Multiple recipients of list Subject: Re: Attack on EnRUPT X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1; format="flowed" MIME-Version: 1.0 In-Reply-To: References: <7643C090-81EA-470F-BA47-01B1D61160D1@cryptolib.com> <4910839C.4050005@larc.usp.br> <7EDEBED9-EDC9-4663-B71B-94C567C080C6@cryptolib.com> X-Cc: Multiple recipients of list X-To: hash-forum@nist.gov, Dmitry Khovratovich X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 04 Nov 2008 13:37:58 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 66 > We started working on the function yesterday. As soon as the paper was > finished we sent a message. Then, why is the ïrRUPT specification the oldest one in their paper? In fact on page 2 they include the oldest ïrRUPT algorithm, WITHOUT the "execute ïr2s(h);" string, as in the first (old) version and not in the submitted variant! I don't know if that is relevant to the attack, but some doubts are rising... Regards, Luca From hash-forum@nist.gov Tue Nov 4 14:46:36 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA4MkU8L005561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Nov 2008 14:46:31 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA4MiubX014782; Tue, 4 Nov 2008 17:45:01 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA4MhpiB015817; Tue, 4 Nov 2008 17:43:51 -0500 Date: Tue, 4 Nov 2008 17:43:51 -0500 Message-Id: <4910CDEC.2020208@reikon.us> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Thomas Dixon To: Multiple recipients of list Subject: Re: Attack on EnRUPT X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 In-Reply-To: <49109E9D.1080702@ellipticsemi.com> References: <7643C090-81EA-470F-BA47-01B1D61160D1@cryptolib.com> <4910839C.4050005@larc.usp.br> <7EDEBED9-EDC9-4663-B71B-94C567C080C6@cryptolib.com> <49109E9D.1080702@ellipticsemi.com> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 04 Nov 2008 14:46:32 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 67 I agree with O'Neil that the mention of 2^384 memory is paramount. I also agree with Barreto that the attack appears to be irrelevant. That said, it is interesting that the version described in the paper is not the version detailed on the site referenced (http://www.enrupt.com/SHA3), which implies a mistake or dishonesty on part of the authors. I suggest they utilize the submitted variant for cryptanalysis instead. In addition, I feel the posting of vulnerabilities on personal sites to this mailing list is unwarranted. A discrete email to the author would have sufficed. Please remember to attack the designs, and not the designers. From hash-forum@nist.gov Tue Nov 4 16:12:33 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA50CPsq015152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Nov 2008 16:12:29 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA508mPn007617; Tue, 4 Nov 2008 19:08:51 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA507eBk015601; Tue, 4 Nov 2008 19:07:41 -0500 Date: Tue, 4 Nov 2008 19:07:40 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Paul Hoffman To: Multiple recipients of list Subject: Do we care about all attacks? X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: text/plain; charset="us-ascii" X-To: hash-forum@nist.gov Mime-Version: 1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 04 Nov 2008 16:12:29 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 68 Greetings again. I am intrigued to see attacks that require more memory than possibly be created in the next few hundred years. I understand that "all attacks get better, never worse", but some attacks that can be described also have lower bounds for how much better they can get. Those lower bounds may take as much, if not more, research to determine than the attack itself. However, if an attack can never (as in, for 100 years with trillions of US$) be made useful, I wonder if it is useful to even consider it as an attack that would possibly lower the standing of the function in the competition. Consider this scenario (which seems likely to exist, given the number of submissions). Function A is significantly slower than SHA-2, and has no known attacks. Function B is faster than than SHA-2, but has some known attacks that can be proven to have lower bounds that are outside what is considered practical. For extra complexity, consider Function C, which is even faster than Function B, but has some known attacks that are currently incredibly impractical, but those attacks do not have proven lower bounds. What should the cryptographic community's recommendation to NIST be? --Paul Hoffman, Director --VPN Consortium From hash-forum@nist.gov Tue Nov 4 18:15:34 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA52FQ2b026922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Nov 2008 18:15:28 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA52D1PV007309; Tue, 4 Nov 2008 21:13:05 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA52CAno027850; Tue, 4 Nov 2008 21:12:10 -0500 Date: Tue, 4 Nov 2008 21:12:10 -0500 Message-Id: <65410B4C-33E6-4D78-8A5A-C2F15255A8AB@zooko.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: zooko To: Multiple recipients of list Subject: Re: Do we care about all attacks? X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 04 Nov 2008 18:15:28 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 69 Dear Paul Hoffman: You ask an interesting question about how should we view attacks which are not feasible to actually carry out. However, there is a different objection to the Khovratovich attack on EnRUPT [1]. The objection is not that the attack is infeasible to carry out, but that the attack takes more time * memory than a generic ("brute force") attack on any hash function would. See for example Birukov and Shamir's paper "Cryptanalytic Time/Memory/ Data Tradeoffs for Stream Ciphers" [2]. Biryukov, ironically, is Khovratovich's PhD supervisor (based on Khovratovich's home page). :-) Bernstein has a nice essay on the subject: http://cr.yp.to/papers.html#bruteforce Regards, Zooko [1] http://lj.streamclub.ru/papers/hash/enrupt.pdf [2] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.23.766 --- http://allmydata.org -- Tahoe, the Least-Authority Filesystem http://allmydata.com -- back up all your files for $10/month From hash-forum@nist.gov Wed Nov 5 13:47:40 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA5LlXDI026059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Nov 2008 13:47:36 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA5LjGII030130; Wed, 5 Nov 2008 16:45:40 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA5LfQ3e019372; Wed, 5 Nov 2008 16:41:26 -0500 Date: Wed, 5 Nov 2008 16:41:26 -0500 Message-Id: <5211F241-9C9E-44C9-8902-013D1ECCF8C7@cryptolib.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Sean O'Neil" To: Multiple recipients of list Subject: Re: Errata in specification X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Type: text/plain; charset=MACINTOSH; delsp=yes; format=flowed References: <49109E46.5030806@qualcomm.com> In-Reply-To: <49109E46.5030806@qualcomm.com> Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 05 Nov 2008 13:47:36 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 70 On 4 Nov 2008, at 20:12, Greg Rose wrote: > I'm sure I'm not the only one to have made such errors. What should > I (and others) do to correct such a mistake? It's a very good question, Greg. For instance, EnRUPT specification has a typo in Section 1.1.3: x Ð H words of internal state, recommended H=(h+P*wÐ1)/w/P*P. should read: x Ð H words of internal state, recommended H=(2*h+P*wÐ1)/w/P*P. Which is correct everywhere else in the paper (the h there should also be italic). It looks like it is also not sufficiently clear from a single line about H: H Ð Number of words in the internal state x; s*P ² H ² 6*s*P, 2*h ² H, that H is a tunable parameter that can take any value within those margins. We probably should have included a short description for it in 3.4. The original EnRUPT specification explains it much better. So, how do we correct such errors? Best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. From hash-forum@nist.gov Wed Nov 5 14:09:29 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA5M9Nal028747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Nov 2008 14:09:25 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA5M2aV3031782; Wed, 5 Nov 2008 17:02:43 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA5M27HV029795; Wed, 5 Nov 2008 17:02:07 -0500 Date: Wed, 5 Nov 2008 17:02:07 -0500 Message-Id: <7.0.1.0.2.20081105164435.0243be58@nist.gov> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Shu-jen Chang To: Multiple recipients of list Subject: Submission tally X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: text/plain; charset="us-ascii"; format=flowed Mime-Version: 1.0 References: <20081102002411.34334.qmail@cr.yp.to> <490D326A.9030902@mit.edu> In-Reply-To: <490D326A.9030902@mit.edu> X-To: hash-forum@nist.gov X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 05 Nov 2008 14:09:25 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 71 >Do we know how many submissions were made?? We have received 64 submissions, but not all of these are "complete and proper". As soon as we are ready to make the determination for all the submissions, we will post the first round candidates on our web site. Thanks, Shu-jen From hash-forum@nist.gov Wed Nov 5 15:03:46 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA5N3fhP002589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Nov 2008 15:03:42 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA5MwtjU018495; Wed, 5 Nov 2008 17:59:01 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA5MvTO4009684; Wed, 5 Nov 2008 17:57:29 -0500 Date: Wed, 5 Nov 2008 17:57:29 -0500 Message-Id: <4912225E.2060309@larc.usp.br> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Paulo S. L. M. Barreto" To: Multiple recipients of list Subject: Re: Submission tally X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 In-Reply-To: <7.0.1.0.2.20081105164435.0243be58@nist.gov> References: <20081102002411.34334.qmail@cr.yp.to> <490D326A.9030902@mit.edu> <7.0.1.0.2.20081105164435.0243be58@nist.gov> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 05 Nov 2008 15:03:43 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 72 Shu-jen Chang wrote: > We have received 64 submissions, but not all of these are "complete and proper". Three times as much as AES submissions. If the fraction of complete and proper submissions is the same as well, we can expect some 45 first round candidates. Impressive. Paulo. From hash-forum@nist.gov Thu Nov 6 02:18:59 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA6AIsds006766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Nov 2008 02:18:55 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA6AFWRR021492; Thu, 6 Nov 2008 05:15:36 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA6AEE9J001100; Thu, 6 Nov 2008 05:14:14 -0500 Date: Thu, 6 Nov 2008 05:14:14 -0500 Message-Id: <4912C12F.4060303@ugd.edu.mk> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Aleksandra Mileva To: Multiple recipients of list Subject: Another errata in specification X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8"; format=flowed MIME-Version: 1.0 X-To: X-To: Multiple recipients of list , X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 06 Nov 2008 02:18:55 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 73 We like to thank Danilo Gligoroski and Chen Ke-Fei Lin for pointing one big error in NaSHA specification. In Part2B1.pdf on page 10, in step 6, "FOR i = 0 TO N - 1 DO" should be "FOR i = 0 TO N - 2 DO". Aleksandra From hash-forum@nist.gov Thu Nov 6 02:48:36 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA6AmWMl009361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Nov 2008 02:48:33 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA6AgiJl012126; Thu, 6 Nov 2008 05:42:45 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA6AgMFE023102; Thu, 6 Nov 2008 05:42:22 -0500 Date: Thu, 6 Nov 2008 05:42:22 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Sean O'Neil" To: Multiple recipients of list Subject: Re: Another errata in specification X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Type: text/plain; charset=WINDOWS-1252; format=flowed References: <4912C12F.4060303@ugd.edu.mk> In-Reply-To: <4912C12F.4060303@ugd.edu.mk> Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 06 Nov 2008 02:48:33 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 74 There is another small error in EnRUPT specification in Section 1.1.2: / – Rounded integral division operation; / operator in C. Should read: / – Truncated integral division operation; / operator in C. Best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. From hash-forum@nist.gov Thu Nov 6 03:23:57 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA6BNqHW012660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Nov 2008 03:23:53 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA6BJ5j8029604; Thu, 6 Nov 2008 06:19:09 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA6BIK0G026251; Thu, 6 Nov 2008 06:18:20 -0500 Date: Thu, 6 Nov 2008 06:18:20 -0500 Message-Id: <4912D089.6010004@ugd.edu.mk> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Aleksandra Mileva To: Multiple recipients of list Subject: Another errata in specification 2 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/alternative; boundary="------------010108020701070200030608" MIME-Version: 1.0 X-To: X-To: Multiple recipients of list , X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 06 Nov 2008 03:23:54 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 75 --------------010108020701070200030608 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Previous message doesn't resolve the error. In Part2B1.pdf on page 10, in step 6, instead of Compute the string of bits S^{(*N*)} as follows FOR i=*0* to N-1 DO A_1||A_2||A_3||...||A_{*2tq*}<- MT(LinTr^{*2t*}_2^{n+2}(S^{(*i*)})), B_1||B_2||B_3||...||B_{q-1}||B_q <-M_{i+1}, S^{*i+1*}:=B_1||A_2||B_2||A_4||...||B_{q-1}||A_{2q-2}||B_q||A_{2q}, NEXT i The proper text is Compute the string of bits S^{(*N-1*)} as follows FOR i=*1* to N-1 DO A_1||A_2||A_3||...||A_{*2q*}<- MT(LinTr^{*2q*}_2^{n+2}(S^{(*i*-1)})), B_1||B_2||B_3||...||B_{q-1}||B_q <-M_{i+1}, S^{*i*}:=B_1||A_2||B_2||A_4||...||B_{q-1}||A_{2q-2}||B_q||A_{2q}, NEXT i And in step 7, instead of S^{(*N*)} sholud be S^{(*N-1*)} Sorry Aleksandra --------------010108020701070200030608 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit Previous message doesn't resolve the error.
In Part2B1.pdf on page 10, in step 6,  instead of

Compute the string  of bits S^{(N)} as follows

FOR i=0 to N-1 DO
    A_1||A_2||A_3||...||A_{2tq}<- MT(LinTr^{2t}_2^{n+2}(S^{(i)})),
    B_1||B_2||B_3||...||B_{q-1}||B_q <-M_{i+1},
    S^{i+1}:=B_1||A_2||B_2||A_4||...||B_{q-1}||A_{2q-2}||B_q||A_{2q},
NEXT i

The proper text is

Compute the string  of bits S^{(N-1)} as follows

FOR i=1 to N-1 DO
    A_1||A_2||A_3||...||A_{2q}<- MT(LinTr^{2q}_2^{n+2}(S^{(i-1)})),
    B_1||B_2||B_3||...||B_{q-1}||B_q <-M_{i+1},
    S^{i}:=B_1||A_2||B_2||A_4||...||B_{q-1}||A_{2q-2}||B_q||A_{2q},
NEXT i

And in step 7,  instead of S^{(N)} sholud be S^{(N-1)}

Sorry
Aleksandra


--------------010108020701070200030608-- From hash-forum@nist.gov Thu Nov 6 06:33:30 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA6EXNoi003346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Nov 2008 06:33:25 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA6EVnlB010733; Thu, 6 Nov 2008 09:31:58 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA6ETFKH026818; Thu, 6 Nov 2008 09:29:15 -0500 Date: Thu, 6 Nov 2008 09:29:15 -0500 Message-Id: <200811061417.mA6EHJm3014278@darch.cs.rit.edu> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Stanislaw P Radziszowski" To: Multiple recipients of list Subject: hash parallelizability X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 X-Mailer: ELM [version 2.5 PL8] X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 06 Nov 2008 06:33:25 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 76 > > http://www.cs.rit.edu/~ark/20081117/slide01.html and the accompanying > http://www.cs.rit.edu/~ark/20081117/phash.pdf (to be presented at Milcom > 2008 in a few weeks) describe a hash function PHASH, apparently a SHA-3 > submission. > > If I'm reading the documents correctly then the proposed 256-bit hash > xors together 128 256-bit encryptions of separate blocks (and does a > tree for longer messages), allowing > > * collisions to be found in time roughly 2^(256/9) by Wagner's > generalized birthday attack on a machine of size 2^(256/9), or time > roughly 2^(256/19) by my parallel generalized birthday attack on a > machine of size 2^(256/9.5), > > * preimages to be found in time roughly 2^(256/17) on a machine of > size 2^(256/8.5), > > etc. Similar comments, with doubled exponents, apply to the proposed > 512-bit hash. > > We're still before the SHA-3 submission deadline. Perhaps the authors > would like to revise their submission to specify a much larger block > size and an appropriate output filter. Of course, it's also possible > that I misread the paper and am stating an attack on something that > isn't actually what the paper describes, and it's also possible that the > authors didn't actually submit what the paper describes; if I'm raising > a false alarm, my apologies! > > ---D. J. Bernstein > Research Professor, Computer Science, University of Illinois at Chicago PHASH was not meant as a SHA-3 competition submission. Rather, as pointed earlier by Alan, it is a design concept, and in particular an argument making a case for the parallelizability of the new hash. For reasons listed in the above note, in order to have parallelizability, we suggest an XOR tree collecting hashes of blocks jointly with block indices, also compressed at each level of the tree by a (perhaps special purpose) block cipher. Some parameters listed there just as examples are indeed vulnerable to the generalized birthday attack (thanks for the note!). On the other hand, one can clearly recommend parameters which are efficient, parallelizable and resistant to known attacks with given bound on computational effort. The XOR tree of degree, say, 32 with blocks of 512 bits should be enough for any reasonable attack scenarios. This would allow much better parallelization than that provided by MD6 (tree of degree 4). Staszek Radziszowski From hash-forum@nist.gov Thu Nov 6 06:35:35 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA6EZTeZ003568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Nov 2008 06:35:31 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA6EW7V0030335; Thu, 6 Nov 2008 09:32:12 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA6EVeLN032695; Thu, 6 Nov 2008 09:31:40 -0500 Date: Thu, 6 Nov 2008 09:31:40 -0500 Message-Id: <20081105234317.63763.qmail@cr.yp.to> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "D. J. Bernstein" To: Multiple recipients of list Subject: X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas In-Reply-To: X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 06 Nov 2008 06:35:31 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-5.7 required=5.0 tests=AWL,BAYES_00,MISSING_SUBJECT, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 77 The SHA-3 Zoo maintainers, on the basis of this paper "Cryptanalysis of EnRUPT," characterized EnRUPT first as "broken" and then as "wounded." Those characterizations are unjustified. The "attack" stated in the paper is simultaneously slower and vastly more expensive than a standard generic brute-force attack machine. Specifically: A very small search circuit will evaluate a typical hash in about a microsecond, and therefore has a good chance of finding a preimage for an h-bit hash in 2^h microseconds. A standard attack machine built from 2^c such circuits has a good chance of finding a preimage in 2^(h-c) microseconds; more generally, it has chance about 2^(s+c-h) of finding a preimage in 2^s microseconds. For example, with a 512-bit hash, a large but realistic brute-force machine containing 2^50 parallel search circuits has a good chance of finding a preimage in 2^462 microseconds (which of course is much longer than the universe will last, but that's a side issue), chance about 1/2^50 of finding a preimage in 2^412 microseconds, etc. For comparison, the paper "Cryptanalysis of EnRUPT" says that its "memory requirement is around 2^384," making it vastly more expensive than the brute-force machine described above; and that it uses "around 2^480 compression function calls," making it also much slower than the brute-force machine described above. An attacker would have to be crazy to switch to this "attack." >From skimming the details of the "attack" my impression is that there are also a huge number of lookups in the size-2^384 memory. If this is true then the 2^480 compression-function calls aren't even the main cost in the attack. Random access to a huge amount of memory takes much longer than a microsecond. Maybe someone will find a real attack on EnRUPT using the same ideas (is the precomputation table necessary? can operations be parallelized?), but maybe not! Here are three analogous examples: (1) The Courtois paper "Algebraic attacks on combiners with memory and several outputs" claims that its "attack" is "faster than exhaustive search" because it finds a 544-bit key using only 2^534 cycles. However, the attack uses 2^380 bits of fast memory, making it vastly less cost-effective than brute force. I've looked at the details of the attack and am confident that nothing along similar lines will ever beat brute force. (2) ProVEST-4 was claimed to be broken by Joux and Reinhard 2^53 times faster than brute force. I looked very closely at the attack and found that it was much, much, much slower than claimed; I improved it and in this case _was_ able to beat brute force, but only by a factor of 2^28. (3) Let's look ahead to quantum computers for a moment. Recall that a reasonable-size quantum computer can find a preimage of any h-bit hash in time proportional to 2^(h/2) hash evaluations by Grover's algorithm. It is very frequently asserted that a quantum computer can find a _collision_ in time proportional to 2^(h/3) hash evaluations, and that we will therefore have to increase h by a factor of 1.5 in post-quantum cryptography. However, a closer look reveals that this quantum algorithm needs an insanely large quantum computer, size proportional to 2^(h/3). This is solidly beaten by _conventional_ parallel collision search (Wiener and van Oorschot), which takes time 2^(h/3) on a non-quantum computer of size only 2^(h/6), improving the overall price-performance ratio from 2^(2h/3) to 2^(h/2). I've tried several quantum approaches and can't beat 2^(h/2) for price-performance ratio. I conjecture that 2^(h/2) is optimal. (There are some papers proving that 2^(h/3) quantum measurements are optimal, but those papers don't analyze space.) If I'm right then quantum computers are useless in finding collisions. I can't condone misevaluation of attack costs, and in particular I can't condone labelling non-attacks as "attacks." No matter what happens with EnRUPT, we need to reject the crazy notion that an algorithm using time 2^480 and space 2^384 can qualify as an "attack" on a 512-bit hash. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago From hash-forum@nist.gov Thu Nov 6 07:15:38 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA6FFWfV008256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Nov 2008 07:15:34 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA6FE0EB009927; Thu, 6 Nov 2008 10:14:07 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA6FD0pO025618; Thu, 6 Nov 2008 10:13:01 -0500 Date: Thu, 6 Nov 2008 10:13:00 -0500 Message-Id: <4913071F.80504@mit.edu> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Ronald L. Rivest" To: Multiple recipients of list Subject: Re: X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: <20081105234317.63763.qmail@cr.yp.to> References: <20081105234317.63763.qmail@cr.yp.to> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 06 Nov 2008 07:15:34 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 78 Hi Dan -- Your statement that "2**462 microseconds is much longer than the universe will last" is of course debatable; see: http://en.wikipedia.org/wiki/1_E19_s_and_more (Note that 2**462 microseconds is only about 10**125 years...) :-) Cheers, Ron On 11/6/2008 9:31 AM, D. J. Bernstein wrote: > The SHA-3 Zoo maintainers, on the basis of this paper "Cryptanalysis of > EnRUPT," characterized EnRUPT first as "broken" and then as "wounded." > Those characterizations are unjustified. The "attack" stated in the > paper is simultaneously slower and vastly more expensive than a standard > generic brute-force attack machine. > > Specifically: A very small search circuit will evaluate a typical hash > in about a microsecond, and therefore has a good chance of finding a > preimage for an h-bit hash in 2^h microseconds. A standard attack > machine built from 2^c such circuits has a good chance of finding a > preimage in 2^(h-c) microseconds; more generally, it has chance about > 2^(s+c-h) of finding a preimage in 2^s microseconds. > > For example, with a 512-bit hash, a large but realistic brute-force > machine containing 2^50 parallel search circuits has a good chance of > finding a preimage in 2^462 microseconds (which of course is much longer > than the universe will last, but that's a side issue), chance about > 1/2^50 of finding a preimage in 2^412 microseconds, etc. > > For comparison, the paper "Cryptanalysis of EnRUPT" says that its > "memory requirement is around 2^384," making it vastly more expensive > than the brute-force machine described above; and that it uses "around > 2^480 compression function calls," making it also much slower than the > brute-force machine described above. An attacker would have to be crazy > to switch to this "attack." > >>From skimming the details of the "attack" my impression is that there > are also a huge number of lookups in the size-2^384 memory. If this is > true then the 2^480 compression-function calls aren't even the main > cost in the attack. Random access to a huge amount of memory takes much > longer than a microsecond. > > Maybe someone will find a real attack on EnRUPT using the same ideas (is > the precomputation table necessary? can operations be parallelized?), > but maybe not! Here are three analogous examples: > > (1) The Courtois paper "Algebraic attacks on combiners with memory > and several outputs" claims that its "attack" is "faster than > exhaustive search" because it finds a 544-bit key using only > 2^534 cycles. However, the attack uses 2^380 bits of fast memory, > making it vastly less cost-effective than brute force. I've > looked at the details of the attack and am confident that nothing > along similar lines will ever beat brute force. > > (2) ProVEST-4 was claimed to be broken by Joux and Reinhard 2^53 > times faster than brute force. I looked very closely at the > attack and found that it was much, much, much slower than > claimed; I improved it and in this case _was_ able to beat brute > force, but only by a factor of 2^28. > > (3) Let's look ahead to quantum computers for a moment. Recall that a > reasonable-size quantum computer can find a preimage of any h-bit > hash in time proportional to 2^(h/2) hash evaluations by Grover's > algorithm. > > It is very frequently asserted that a quantum computer can find a > _collision_ in time proportional to 2^(h/3) hash evaluations, and > that we will therefore have to increase h by a factor of 1.5 in > post-quantum cryptography. > > However, a closer look reveals that this quantum algorithm needs > an insanely large quantum computer, size proportional to 2^(h/3). > This is solidly beaten by _conventional_ parallel collision > search (Wiener and van Oorschot), which takes time 2^(h/3) on a > non-quantum computer of size only 2^(h/6), improving the overall > price-performance ratio from 2^(2h/3) to 2^(h/2). > > I've tried several quantum approaches and can't beat 2^(h/2) for > price-performance ratio. I conjecture that 2^(h/2) is optimal. > (There are some papers proving that 2^(h/3) quantum measurements > are optimal, but those papers don't analyze space.) If I'm right > then quantum computers are useless in finding collisions. > > I can't condone misevaluation of attack costs, and in particular I can't > condone labelling non-attacks as "attacks." No matter what happens with > EnRUPT, we need to reject the crazy notion that an algorithm using time > 2^480 and space 2^384 can qualify as an "attack" on a 512-bit hash. > > ---D. J. Bernstein > Research Professor, Computer Science, University of Illinois at Chicago > > > -- Ronald L. Rivest Room 32-G692, Stata Center, MIT, Cambridge MA 02139 Tel 617-253-5880, Email From hash-forum@nist.gov Thu Nov 6 07:57:42 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA6FvbqQ012459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Nov 2008 07:57:38 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA6Fu2Ic030546; Thu, 6 Nov 2008 10:56:09 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA6FsdLm014581; Thu, 6 Nov 2008 10:54:39 -0500 Date: Thu, 6 Nov 2008 10:54:39 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Stefan.Lucks@uni-weimar.de To: Multiple recipients of list Subject: Re: your mail X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: TEXT/PLAIN; charset=US-ASCII MIME-Version: 1.0 References: <20081105234317.63763.qmail@cr.yp.to> In-Reply-To: <20081105234317.63763.qmail@cr.yp.to> X-To: Multiple recipients of list X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 06 Nov 2008 07:57:38 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 79 > The SHA-3 Zoo maintainers, on the basis of this paper "Cryptanalysis of > EnRUPT," characterized EnRUPT first as "broken" and then as "wounded." > Those characterizations are unjustified. I disagree! They are justified. > The "attack" stated in the paper is simultaneously slower and vastly > more expensive than a standard generic brute-force attack machine. The authors of that paper follow an old tradition of academic cryptanalysis: They count the running time of an attack, mostly disregarding other ressources, such as storage. Yes, this is crude and perhaps even a bit unfair. Some cryptosystems are sorted out, which would survive a less crude cryptanalysis. I can understand well that the designers of EnRUPT protest against this approach. But actually, that simplistic approach to evaluate attacks is more than useful to sort out the good candidates - which withstand attacks even in such a pessimistic setting - from the doubful ones, and to put the cryptanalysts' focus on the not-yet-doubtful ones. The time for the SHA-3 comptition is short, there are a lot of submissions, and the number of qualified cryptanalysts is limited. Note that essentially the same approach to evaluate cryptanalytic results has been used with good success to focus attention on the strongest candidates of the AES competition. There may be time for more precise attack estimates when the field of candidates has been narrowed down to a handful of finalists, but hardly before. I am sorry for you, Sean, Karsten and Luca, but EnRUPT is wounded, at least. Mainly, because with the attack given, most people will put their focus on other hash functions. There are plenty without an attack even in the "time is all that counts model. So long Stefan P.S.: I am not interested in a lengthy discussion on which attacks should count, and which should not. (At the end, neither of us will decide, but NIST will do.) We had this discussion before, Dan. Feel free to reply, but don't expect me to answer. We had this discussion before, and we agreed to disagree. But Dan, you really should not play down the good work done by Dimitry and Ivica. They deserve better. -- ------ Stefan Lucks -- Bauhaus-University Weimar -- Germany ------ Stefan dot Lucks at uni minus weimar dot de ------ I love the taste of Cryptanalysis in the morning! ------ From hash-forum@nist.gov Thu Nov 6 08:20:51 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA6GKiE1014880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Nov 2008 08:20:46 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA6GALwf009699; Thu, 6 Nov 2008 11:10:27 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA6G9lF6013895; Thu, 6 Nov 2008 11:09:47 -0500 Date: Thu, 6 Nov 2008 11:09:47 -0500 Message-Id: <5EB2E594-E83D-43D1-BE3D-2A81DC6A05BC@mac.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Jeff Johnson To: Multiple recipients of list Subject: Re: Re: X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.929.2) References: <20081105234317.63763.qmail@cr.yp.to> <4913071F.80504@mit.edu> In-reply-to: <4913071F.80504@mit.edu> X-To: hash-forum@nist.gov Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 06 Nov 2008 08:20:47 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 80 On Nov 6, 2008, at 10:13 AM, Ronald L. Rivest wrote: > > Hi Dan -- > > Your statement that "2**462 microseconds is much longer than > the universe will last" is of course debatable; see: > http://en.wikipedia.org/wiki/1_E19_s_and_more > (Note that 2**462 microseconds is only about 10**125 years...) > I'll take that bet, and offer 10**56-to-1 odds that the universe will survive forever for payment up front. Any takers? ;-) 73 de Jeff From hash-forum@nist.gov Thu Nov 6 09:04:11 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA6H43V6021642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Nov 2008 09:04:06 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA6GsM84011163; Thu, 6 Nov 2008 11:55:39 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA6GpU2Y002661; Thu, 6 Nov 2008 11:51:30 -0500 Date: Thu, 6 Nov 2008 11:51:30 -0500 Message-Id: <49131F54.8020001@larc.usp.br> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Paulo S. L. M. Barreto" To: Multiple recipients of list Subject: Re: your mail X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 In-Reply-To: References: <20081105234317.63763.qmail@cr.yp.to> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 06 Nov 2008 09:04:06 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 81 Dear Stefan, Sorry, but I take sides with Dan, as I have already hinted. If one is to count an "attack" that is grossly worse than brute force, and a submission is to be considered "wounded" because of this, I can "wound" *all* submissions without even knowing them, including your own submission Skein. Paulo. >> The SHA-3 Zoo maintainers, on the basis of this paper "Cryptanalysis of >> EnRUPT," characterized EnRUPT first as "broken" and then as "wounded." >> Those characterizations are unjustified. > > I disagree! They are justified. > >> The "attack" stated in the paper is simultaneously slower and vastly >> more expensive than a standard generic brute-force attack machine. > > The authors of that paper follow an old tradition of academic > cryptanalysis: They count the running time of an attack, mostly > disregarding other ressources, such as storage. Yes, this is crude and > perhaps even a bit unfair. Some cryptosystems are sorted out, which would > survive a less crude cryptanalysis. I can understand well that the > designers of EnRUPT protest against this approach. > > But actually, that simplistic approach to evaluate attacks is more than > useful to sort out the good candidates - which withstand attacks even in > such a pessimistic setting - from the doubful ones, and to put the > cryptanalysts' focus on the not-yet-doubtful ones. The time for the SHA-3 > comptition is short, there are a lot of submissions, and the number of > qualified cryptanalysts is limited. > > Note that essentially the same approach to evaluate cryptanalytic results > has been used with good success to focus attention on the strongest > candidates of the AES competition. There may be time for more precise > attack estimates when the field of candidates has been narrowed down to a > handful of finalists, but hardly before. > > I am sorry for you, Sean, Karsten and Luca, but EnRUPT is wounded, at > least. Mainly, because with the attack given, most people will put their > focus on other hash functions. There are plenty without an attack even in > the "time is all that counts model. > > So long > > Stefan > > P.S.: > > I am not interested in a lengthy discussion on which attacks should count, > and which should not. (At the end, neither of us will decide, but NIST > will do.) We had this discussion before, Dan. Feel free to reply, but > don't expect me to answer. We had this discussion before, and we agreed > to disagree. But Dan, you really should not play down the good work done > by Dimitry and Ivica. They deserve better. > > > > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - http://www.avg.com > Version: 8.0.175 / Virus Database: 270.9.0/1771 - Release Date: 06/11/2008 07:58 > From hash-forum@nist.gov Thu Nov 6 09:42:40 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA6HgXaH026670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Nov 2008 09:42:35 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA6HbhsB002561; Thu, 6 Nov 2008 12:38:53 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA6HZsVr029117; Thu, 6 Nov 2008 12:35:54 -0500 Date: Thu, 6 Nov 2008 12:35:54 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Owen Anderson To: Multiple recipients of list Subject: Re: X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.929.2) References: <20081105234317.63763.qmail@cr.yp.to> Mime-Version: 1.0 (Apple Message framework v929.2) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes In-Reply-To: <20081105234317.63763.qmail@cr.yp.to> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 06 Nov 2008 09:42:36 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 82 On Nov 6, 2008, at 6:31 AM, D. J. Bernstein wrote: > The SHA-3 Zoo maintainers, on the basis of this paper "Cryptanalysis > of > EnRUPT," characterized EnRUPT first as "broken" and then as "wounded." > Those characterizations are unjustified. The "attack" stated in the > paper is simultaneously slower and vastly more expensive than a > standard > generic brute-force attack machine. For what it's worth, they have since revised the classification scheme to something that I think is much more fair, as it avoids using the negatively-associated word "wounded." * No external cryptanalysis known * External cryptanalysis known * Cryptanalysis known that invalidates the authors' claims or makes it unsuitable for SHA-3 (i.e. broken) As of now, two hashes (WaMM and Sgail) are listed as "broken" because there are trivial 2nd preimage attacks known against them. Two others (MD6 and now EnRUPT) are listed as having known external cryptanalytic results. Depending on your outlook, having external cryptanalytic results can be either a good thing (It was attacked and still didn't break!) or a bad thing (What if this attack is the tip of the iceberg?). I think it's best to leave that interpretation up to the viewer. --Owen From hash-forum@nist.gov Thu Nov 6 10:29:05 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA6IT0jX001608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Nov 2008 10:29:01 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA6IMqvT021501; Thu, 6 Nov 2008 13:24:02 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA6ILfkQ027765; Thu, 6 Nov 2008 13:21:41 -0500 Date: Thu, 6 Nov 2008 13:21:41 -0500 Message-Id: <49133460.9020102@mit.edu> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Ronald L. Rivest" To: Multiple recipients of list Subject: Re: X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: References: <20081105234317.63763.qmail@cr.yp.to> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 06 Nov 2008 10:29:01 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 83 Whether a cryptanalysis is external or internal is irrelevant to whether it is a serious attack or not. In the case of MD6, we were collaborating with the "attackers" (Jean-Philippe Aumasson and Itai Dinur) to see how well their new attacks (which are generic and potentially applicable to any hash function) would apply to MD6. The results of this work is described in our submitted report, just as our own internal analyses are described. The results, while excellent, are neither surprising nor disturbing; they can distinguish MD6 from random for a few more rounds than do naive statistical attacks. MD6 is a conservative design with a large number of rounds. The right question to ask is: has *your* design been tested with respect to these attacks? If it has not, this may be a weakness in your submission, as your design may be particularly vulnerable to this class of attacks. A submission that doesn't consider all possible classes of attacks is arguably weaker than one that does... So, rather than noting whether there is external or internal cryptanalysis, one should be noting whether there are reasons (either from external review/attack or internal review/attack) for believing that the proposal is secure against the various known classes of attacks... Cheers, Ron On 11/6/2008 12:35 PM, Owen Anderson wrote: > > On Nov 6, 2008, at 6:31 AM, D. J. Bernstein wrote: >> The SHA-3 Zoo maintainers, on the basis of this paper "Cryptanalysis of >> EnRUPT," characterized EnRUPT first as "broken" and then as "wounded." >> Those characterizations are unjustified. The "attack" stated in the >> paper is simultaneously slower and vastly more expensive than a standard >> generic brute-force attack machine. > > For what it's worth, they have since revised the classification scheme > to something that I think is much more fair, as it avoids using the > negatively-associated word "wounded." > > * No external cryptanalysis known > * External cryptanalysis known > * Cryptanalysis known that invalidates the authors' claims or makes it > unsuitable for SHA-3 (i.e. broken) > > As of now, two hashes (WaMM and Sgail) are listed as "broken" because > there are trivial 2nd preimage attacks known against them. Two others > (MD6 and now EnRUPT) are listed as having known external cryptanalytic > results. Depending on your outlook, having external cryptanalytic > results can be either a good thing (It was attacked and still didn't > break!) or a bad thing (What if this attack is the tip of the > iceberg?). I think it's best to leave that interpretation up to the > viewer. > > --Owen > > > -- Ronald L. Rivest Room 32-G692, Stata Center, MIT, Cambridge MA 02139 Tel 617-253-5880, Email From hash-forum@nist.gov Thu Nov 6 10:37:38 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA6IbVtQ003275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Nov 2008 10:37:34 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA6ILrV1012461; Thu, 6 Nov 2008 13:22:58 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA6IJr5H023471; Thu, 6 Nov 2008 13:19:53 -0500 Date: Thu, 6 Nov 2008 13:19:53 -0500 Message-Id: <20081106181444.13471.qmail@cr.yp.to> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "D. J. Bernstein" To: Multiple recipients of list Subject: Re: Evaluating attack costs X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas In-Reply-To: X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 06 Nov 2008 10:37:34 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.3 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 84 Once again: No matter what happens with EnRUPT, we need to reject the crazy notion that an algorithm using time 2^480 and space 2^384 can qualify as an "attack" on a 512-bit hash. Taking an "attack" that's slower and more expensive than brute force, and using it as an excuse to throw away a proposal, is irresponsible. Real-world cryptographic engineering is already hard enough: we have _real_ attacks to worry about, and real efficiency problems, and real implementation problems. I can't look a user in the eye and tell him that we're failing to meet his requirements because we're too busy trying to dodge crackpot "attacks" that break a hash in time 2^480 on a machine of size 2^384. I'm not saying that EnRUPT is my favorite design. On the contrary: my initial _speculation_, based on a quick glance at EnRUPT, is that the diffusion is too slow and will lead to attacks. But throwing away proposals on the basis of this sort of speculation would be stupid, just like throwing away proposals on the basis of "attacks" slower than brute force. If nobody can come up with a real attack then I'll have to conclude that my speculation was wrong. If someone _does_ come up with a real attack then I will stop paying attention to EnRUPT---but I will continue objecting to the ludicrous notion that a hash can be "broken" by an "attack" taking time 2^480 on a machine of size 2^384. Stefan admits that ignoring storage costs, machine costs, communication costs, etc. is "simplistic" (i.e., wrong), but says that we're forced into this level of sloppiness because "the number of qualified cryptanalysts is limited." I disagree. We already have a much better approach to focus cryptanalytic attention: try to break the _fast_ functions first. Here's how Bruce Schneier put it in his blog: "Immediately sort them based on performance and features. Ask the cryptographic community to focus its attention on the top dozen, rather than spread its attention across all 80." This doesn't require any misevaluation of attack costs. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago From hash-forum@nist.gov Thu Nov 6 11:13:34 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA6JDSS3008953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Nov 2008 11:13:30 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA6J83dO016957; Thu, 6 Nov 2008 14:09:14 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA6J6Bu7021602; Thu, 6 Nov 2008 14:06:11 -0500 Date: Thu, 6 Nov 2008 14:06:11 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Markku-Juhani O. Saarinen" To: Multiple recipients of list Subject: fse '09 - special session on hash functions proposal X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 06 Nov 2008 11:13:30 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 85 Hi, I just sent this to the Bart Preneel and Orr Dunkelman, but I think it belongs to the list as well. Regarding the SHA-3 contest and FSE 2009: The FSE '09 deadline is already on November 24, and that's little too soon for most us to have any relevant and polished cryptanalytic or performance papers ready on the SHA-3 candidates already known. In a few months the situation will be completely different. A person from NIST has informed me that apparently the First Candidate Conference will not have slots for performance-related or cryptanalytic results from people who are not "contestants" -- such as myself. See below for the exact wording. I therefore propose that the "European" FSE '09 organizers would consider taking the task in their own hands by dedicating a special session for the most recent results on hash function cryptanalysis, with paper submission deadlines in January (or even early February) 2009. I'm sure that there would be no shortage of reviewers who can judge papers in a week or two on this very special topic. I believe that such a session would be popular. Also some people -- especially students -- could more easily justify the travel costs to FSE if they were to give a talk, even a short talk. ---------------- Date: Thu, 06 Nov 2008 11:06:10 -0500 From: Sara Caswell To: MJOS@IKI.FI Subject: Re: first candidate conference submission deadlines At this moment we can't promise non-candidates speaking slot. We are in the process of reviewing the submissions, and before we get a chance to weed out the incomplete submissions, it's hard to say anything concrete about the conference program. (...) ---------------- Best Regards, - Markku // Markku-Juhani O. Saarinen http://www.m-js.com // Royal Holloway, University of London / Envault Corporation From hash-forum@nist.gov Thu Nov 6 10:54:54 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA6IslRG006172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Nov 2008 10:54:49 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA6IqXE8011799; Thu, 6 Nov 2008 13:53:55 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA6IpDVv022793; Thu, 6 Nov 2008 13:51:13 -0500 Date: Thu, 6 Nov 2008 13:51:13 -0500 Message-Id: <7.0.1.0.2.20081106134507.024d6b18@nist.gov> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Shu-jen Chang To: Multiple recipients of list Subject: Re: Blank subject lines X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: text/plain; charset="us-ascii"; format=flowed Mime-Version: 1.0 References: <20081105234317.63763.qmail@cr.yp.to> <49133460.9020102@mit.edu> In-Reply-To: X-To: hash-forum@nist.gov X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 06 Nov 2008 10:54:49 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 86 This is probably not Professor Bernstein's fault. There was a problem with his initial email (with a proper Subject line) that he had to try it a few times. I'm sure the oversight was caused unintentionally during these retries. Shu-jen At 01:36 PM 11/6/2008, you wrote: >Could I request that submitters include a relevant subject line in all >correspondence? > >Bob > >Robert Jueneman >Chief Scientist >SPYRUS, Inc. >1860 Hartog Dr. >San Jose, CA 95131 >1-408-393-4307 (Office) >1-408-422-2378 (Cell) > > >-----Original Message----- >From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of >Ronald L. Rivest >Sent: Thursday, November 06, 2008 10:22 AM >To: Multiple recipients of list >Subject: Re: > > >Whether a cryptanalysis is external or internal is >irrelevant to whether it is a serious attack or not. >In the case of MD6, we were collaborating with the >"attackers" (Jean-Philippe Aumasson and Itai Dinur) to >see how well their new attacks (which are generic and >potentially applicable to any hash function) would apply >to MD6. The results of this work is described in our >submitted report, just as our own internal analyses are >described. The results, while excellent, are neither >surprising nor disturbing; they can distinguish MD6 from >random for a few more rounds than do naive statistical >attacks. MD6 is a conservative design with a large >number of rounds. > >The right question to ask is: has *your* design been >tested with respect to these attacks? If it has not, >this may be a weakness in your submission, as your design >may be particularly vulnerable to this class of attacks. >A submission that doesn't consider all possible classes of >attacks is arguably weaker than one that does... > >So, rather than noting whether there is external or internal >cryptanalysis, one should be noting whether there are reasons >(either from external review/attack or internal review/attack) >for believing that the proposal is secure against the various >known classes of attacks... > >Cheers, >Ron > > >On 11/6/2008 12:35 PM, Owen Anderson wrote: > > > > On Nov 6, 2008, at 6:31 AM, D. J. Bernstein wrote: > >> The SHA-3 Zoo maintainers, on the basis of this paper "Cryptanalysis >of > >> EnRUPT," characterized EnRUPT first as "broken" and then as >"wounded." > >> Those characterizations are unjustified. The "attack" stated in the > >> paper is simultaneously slower and vastly more expensive than a >standard > >> generic brute-force attack machine. > > > > For what it's worth, they have since revised the classification scheme > > > to something that I think is much more fair, as it avoids using the > > negatively-associated word "wounded." > > > > * No external cryptanalysis known > > * External cryptanalysis known > > * Cryptanalysis known that invalidates the authors' claims or makes it > > > unsuitable for SHA-3 (i.e. broken) > > > > As of now, two hashes (WaMM and Sgail) are listed as "broken" because > > there are trivial 2nd preimage attacks known against them. Two others > > > (MD6 and now EnRUPT) are listed as having known external cryptanalytic > > > results. Depending on your outlook, having external cryptanalytic > > results can be either a good thing (It was attacked and still didn't > > break!) or a bad thing (What if this attack is the tip of the > > iceberg?). I think it's best to leave that interpretation up to the > > viewer. > > > > --Owen > > > > > > > >-- > Ronald L. Rivest > Room 32-G692, Stata Center, MIT, Cambridge MA 02139 > Tel 617-253-5880, Email From hash-forum@nist.gov Thu Nov 6 10:41:30 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA6IfPq8004029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Nov 2008 10:41:26 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA6IbhtU020334; Thu, 6 Nov 2008 13:38:50 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA6IaH8g024726; Thu, 6 Nov 2008 13:36:17 -0500 Date: Thu, 6 Nov 2008 13:36:17 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Robert Jueneman" To: Multiple recipients of list Subject: Re: Blank subject lines X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit X-To: References: <20081105234317.63763.qmail@cr.yp.to> <49133460.9020102@mit.edu> In-Reply-To: <49133460.9020102@mit.edu> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 06 Nov 2008 10:41:26 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 87 Could I request that submitters include a relevant subject line in all correspondence? Bob Robert Jueneman Chief Scientist SPYRUS, Inc. 1860 Hartog Dr. San Jose, CA 95131 1-408-393-4307 (Office) 1-408-422-2378 (Cell) -----Original Message----- From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Ronald L. Rivest Sent: Thursday, November 06, 2008 10:22 AM To: Multiple recipients of list Subject: Re: Whether a cryptanalysis is external or internal is irrelevant to whether it is a serious attack or not. In the case of MD6, we were collaborating with the "attackers" (Jean-Philippe Aumasson and Itai Dinur) to see how well their new attacks (which are generic and potentially applicable to any hash function) would apply to MD6. The results of this work is described in our submitted report, just as our own internal analyses are described. The results, while excellent, are neither surprising nor disturbing; they can distinguish MD6 from random for a few more rounds than do naive statistical attacks. MD6 is a conservative design with a large number of rounds. The right question to ask is: has *your* design been tested with respect to these attacks? If it has not, this may be a weakness in your submission, as your design may be particularly vulnerable to this class of attacks. A submission that doesn't consider all possible classes of attacks is arguably weaker than one that does... So, rather than noting whether there is external or internal cryptanalysis, one should be noting whether there are reasons (either from external review/attack or internal review/attack) for believing that the proposal is secure against the various known classes of attacks... Cheers, Ron On 11/6/2008 12:35 PM, Owen Anderson wrote: > > On Nov 6, 2008, at 6:31 AM, D. J. Bernstein wrote: >> The SHA-3 Zoo maintainers, on the basis of this paper "Cryptanalysis of >> EnRUPT," characterized EnRUPT first as "broken" and then as "wounded." >> Those characterizations are unjustified. The "attack" stated in the >> paper is simultaneously slower and vastly more expensive than a standard >> generic brute-force attack machine. > > For what it's worth, they have since revised the classification scheme > to something that I think is much more fair, as it avoids using the > negatively-associated word "wounded." > > * No external cryptanalysis known > * External cryptanalysis known > * Cryptanalysis known that invalidates the authors' claims or makes it > unsuitable for SHA-3 (i.e. broken) > > As of now, two hashes (WaMM and Sgail) are listed as "broken" because > there are trivial 2nd preimage attacks known against them. Two others > (MD6 and now EnRUPT) are listed as having known external cryptanalytic > results. Depending on your outlook, having external cryptanalytic > results can be either a good thing (It was attacked and still didn't > break!) or a bad thing (What if this attack is the tip of the > iceberg?). I think it's best to leave that interpretation up to the > viewer. > > --Owen > > > -- Ronald L. Rivest Room 32-G692, Stata Center, MIT, Cambridge MA 02139 Tel 617-253-5880, Email From hash-forum@nist.gov Thu Nov 6 12:28:17 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA6KSBRi017656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Nov 2008 12:28:12 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA6KJb9j022272; Thu, 6 Nov 2008 15:20:44 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA6KGqCr005967; Thu, 6 Nov 2008 15:16:52 -0500 Date: Thu, 6 Nov 2008 15:16:52 -0500 Message-Id: <98EBB542F32B9D4CBB1EC5FE1D93D45B16448F69C9@ES02SNLNT.srn.sandia.gov> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Schroeppel, Richard" To: Multiple recipients of list Subject: RE: Evaluating attack costs X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 In-Reply-To: <20081106181444.13471.qmail@cr.yp.to> References: ,<20081106181444.13471.qmail@cr.yp.to> X-Cc: "rcs@xmission.com" X-cc: "Schroeppel, Richard" , X-To: "hash-forum@nist.gov" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 06 Nov 2008 12:28:12 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 88 I'm going to quibble here. I haven't looked at Enrupt or the (alleged?) attack. However, to take DJB's paragraph out of context: Q: Does an algorithm using time 2^480 and space 2^384 count as an attack on a 512-bit hash? A: It depends on what's assumed about the space. If the space is passive, and is treated like a long tape, and not read or written too many times, I'd treat it as a fixed one time cost. If I understand DJB, he wants us to multiply time*space. If the memory is active in some way, doing some kind of computing, I can see this. But if it's just "DVDs in a warehouse", I think not. Consider this prehistoric attack on double-DES: I have two P/C pairs, and am looking for keys K and L such that DES(L,DES(K,P1)) = C1 and also P2,C2. We attack this by trying all Ks, encrypting P1,P2 and writing the results to a tape. We also try all Ls, decrypting C1,C2 and writing the results to a second tape. We look for a coincidence on the tapes by sorting them and comparing. How should we cost this attack? Does it break 2DES? If we charge 2^56 * 4 for the cost of the encryptions, 2^56 for the cost of the tapes, 2^56 * 56 *2 for the cost of sorting, and a bit more to scan and compare the tapes, our total is around 2^56 * smallish. We regard 2DES as having around 56 bits of security. If we instead multiply the tape size by the elapsed time for the encryptions, we get a number around 2^112, and regard 2DES as having around 112 bits of security. The right answer is 2^56, not 2^112. If the memory is doing handstands or other fancy tricks, it's fair to treat it as part of the computer. But if it's spending most of its time in the warehouse gathering dust, it's just an additive cost. Rich Schroeppel rschroe@sandia.gov ________________________________________ From: hash-forum@nist.gov [hash-forum@nist.gov] On Behalf Of D. J. Bernstein [djb@cr.yp.to] Sent: Thursday, November 06, 2008 11:19 AM To: Multiple recipients of list Subject: Re: Evaluating attack costs Once again: No matter what happens with EnRUPT, we need to reject the crazy notion that an algorithm using time 2^480 and space 2^384 can qualify as an "attack" on a 512-bit hash. Taking an "attack" that's slower and more expensive than brute force, and using it as an excuse to throw away a proposal, is irresponsible. Real-world cryptographic engineering is already hard enough: we have _real_ attacks to worry about, and real efficiency problems, and real implementation problems. I can't look a user in the eye and tell him that we're failing to meet his requirements because we're too busy trying to dodge crackpot "attacks" that break a hash in time 2^480 on a machine of size 2^384. I'm not saying that EnRUPT is my favorite design. On the contrary: my initial _speculation_, based on a quick glance at EnRUPT, is that the diffusion is too slow and will lead to attacks. But throwing away proposals on the basis of this sort of speculation would be stupid, just like throwing away proposals on the basis of "attacks" slower than brute force. If nobody can come up with a real attack then I'll have to conclude that my speculation was wrong. If someone _does_ come up with a real attack then I will stop paying attention to EnRUPT---but I will continue objecting to the ludicrous notion that a hash can be "broken" by an "attack" taking time 2^480 on a machine of size 2^384. Stefan admits that ignoring storage costs, machine costs, communication costs, etc. is "simplistic" (i.e., wrong), but says that we're forced into this level of sloppiness because "the number of qualified cryptanalysts is limited." I disagree. We already have a much better approach to focus cryptanalytic attention: try to break the _fast_ functions first. Here's how Bruce Schneier put it in his blog: "Immediately sort them based on performance and features. Ask the cryptographic community to focus its attention on the top dozen, rather than spread its attention across all 80." This doesn't require any misevaluation of attack costs. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago From hash-forum@nist.gov Thu Nov 6 14:01:20 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA6M1Fxa028808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Nov 2008 14:01:16 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA6LxHED005106; Thu, 6 Nov 2008 17:00:22 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA6LvvIB020297; Thu, 6 Nov 2008 16:57:57 -0500 Date: Thu, 6 Nov 2008 16:57:57 -0500 Message-Id: <7A15A8C1-351C-4191-B6DE-0BAD728FBBFB@pgpeng.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Jon Callas To: Multiple recipients of list Subject: Re: Evaluating attack costs X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes X-Mailer: Apple Mail (2.929.2) References: <20081106181444.13471.qmail@cr.yp.to> Mime-Version: 1.0 (Apple Message framework v929.2) In-Reply-To: <20081106181444.13471.qmail@cr.yp.to> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 06 Nov 2008 14:01:16 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 89 On Nov 6, 2008, at 10:19 AM, D. J. Bernstein wrote: > > Once again: No matter what happens with EnRUPT, we need to reject the > crazy notion that an algorithm using time 2^480 and space 2^384 can > qualify as an "attack" on a 512-bit hash. > > Taking an "attack" that's slower and more expensive than brute force, > and using it as an excuse to throw away a proposal, is irresponsible. > Real-world cryptographic engineering is already hard enough: we have > _real_ attacks to worry about, and real efficiency problems, and real > implementation problems. I can't look a user in the eye and tell him > that we're failing to meet his requirements because we're too busy > trying to dodge crackpot "attacks" that break a hash in time 2^480 > on a > machine of size 2^384. I agree with Dan on this. There's no rigorous way to differentiate between a legitimate attack and an irrelevant attack, but I know one when I see it. I also know some that are in the middle. Many of the ones in the middle are context-dependent, which means among other things that it should be compared against other systems. With my engineering hat on, if an algorithm has a break that takes 2^384 memory, it's hard for me to even say that with a straight face. I'm not even that concerned with 2^150 memory. (Rationale: 2^40 memory is not inconceivable today; if I expect the algorithm to be in use for the next century and memory to double every year, then 2^150 is still okay, because I don't expect this to be possible.) Sure, another algorithm that needs 2^200 memory is better. I'll prefer that one to the other. Once we get to 2^256, it's really dodgy because that's above the birthday bound. An attack that needs 2^384 memory might be interesting to some cryptanalysts, but as an engineer, it (perhaps counterintuitively) makes me feel better about the algorithm. As an engineer, I am worried by two things: cryptanalysis and a lack of cryptanalysis. Cryptanalysis that requires more memory than the planet can hold is a lower-grade attack than cryptanalysis that requires the memory in my laptop. Let me offer as an example a 16-round block cipher. An attack against a 14-round subset is a bit worrisome. No attacks at all are also worrisome. A six-round attack is better than either from my viewpoint because it means that someone looked at the cipher, got that partial result, and considered it worth publishing. But that 14-round attack starts looking better the longer it stands. Suppose we knew through divine inspiration that N rounds is the best possible attack. Then we want to have N+1 rounds in the cipher. If N=14, then this cipher has one round too many. The goal of this competition is to get a good hash function by consensus more than getting the best one controversially. If reasonable persons have doubts about SHA3, they will use SHA2 (which looks better every year that no new attacks come in). Consensus is served by people feeling good about some set of functions. A dodgy attack looks artificially bad at first, but as time goes on might artificially look good. Jon -- Jon Callas CTO, CSO PGP Corporation Tel: +1 (650) 319-9016 200 Jefferson Drive Fax: +1 (650) 319-9001 Menlo Park, CA 94025 PGP: ed15 5bdf cd41 adfc 00f3 USA 28b6 52bf 5a46 bc98 e63d From hash-forum@nist.gov Thu Nov 6 13:48:56 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA6Lmn8Q027146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Nov 2008 13:48:51 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA6LiKlA007870; Thu, 6 Nov 2008 16:45:34 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA6Lfgp8019612; Thu, 6 Nov 2008 16:41:42 -0500 Date: Thu, 6 Nov 2008 16:41:42 -0500 Message-Id: <20081106213418.GA22469@ssh.esat.kuleuven.be> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Sebastiaan Indesteege To: Multiple recipients of list Subject: Collisions for EnRUPT X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/mixed; boundary="yNb1oOkm5a9FJOVX" Mime-Version: 1.0 X-Cc: "Sean O'Neil" X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 06 Nov 2008 13:48:51 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 90 --yNb1oOkm5a9FJOVX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, I've constructed a practical collision attack on EnRUPT-256 (default values for all other tunable parameters). An example colliding message pair is attached to this e-mail, in the form of C-code which is to be linked against the reference implementation of EnRUPT. The output of the program is given below ---- Example collision pair for EnRUPT-256 2008-11-06, Sebastiaan Indesteege, COSIC, Katholieke Universiteit Leuven m1 = 13c84b456270176e04f9317ec36ce7d3e121786a347411197f64a3c940077576a14f9086fdc7334a413a769196062ca1 EnRUPT-256(m1) = 5396cd1094431281b6be0a2aa78aaeda5414891efeaea0adb5d4364be9814899 m2 = 13c84b456a70176e04f9315c436ce7d3e1217848bc7411197f64a3cb48077576a14f9084fdc7334a413a769396062ca1 EnRUPT-256(m2) = 5396cd1094431281b6be0a2aa78aaeda5414891efeaea0adb5d4364be9814899 m1 and m2 collide! ---- The attack is based on linearisation, which does work very well, contrary to what is claimed in Sect. 4.10 of the EnRUPT specification document. The attack has an estimated time complexity of 2^47 calls to the ir2s() function, and negligible memory requirements, before optimisations. With optimisations, it's probably closer to 2^40. Both are significantly lower than the birthday bound. A write-up with more details will follow. Regards, Sebastiaan Indesteege -- Sebastiaan Indesteege sebastiaan.indesteege@esat.kuleuven.be K.U.Leuven, ESAT SCD/COSIC, http://www.esat.kuleuven.be/cosic/ Kasteelpark Arenberg 10 bus 2446, phone: +32 16 321049 B-3001 Leuven-Heverlee, Belgium. fax: +32 16 321969 Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm --yNb1oOkm5a9FJOVX Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="enruptcoll.c" /* * Copyright (c) 2008 Sebastiaan Indesteege * * * Permission to use, copy, modify, and distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ /* * Example collision pair for EnRUPT-256, using the defaults for the other * tunable parameters. This file should be linked with the reference * implementation of EnRUPT. * * 2008-11-06, Sebastiaan Indesteege, COSIC, Katholieke Universiteit Leuven */ #include "EnRUPT_ref.h" #include #include #include #define HASHBITLEN 256 #define LEN 48*8 static const uint8_t m1[] = { 0x13, 0xc8, 0x4b, 0x45, 0x62, 0x70, 0x17, 0x6e, 0x04, 0xf9, 0x31, 0x7e, 0xc3, 0x6c, 0xe7, 0xd3, 0xe1, 0x21, 0x78, 0x6a, 0x34, 0x74, 0x11, 0x19, 0x7f, 0x64, 0xa3, 0xc9, 0x40, 0x07, 0x75, 0x76, 0xa1, 0x4f, 0x90, 0x86, 0xfd, 0xc7, 0x33, 0x4a, 0x41, 0x3a, 0x76, 0x91, 0x96, 0x06, 0x2c, 0xa1 }; static const uint8_t m2[] = { 0x13, 0xc8, 0x4b, 0x45, 0x6a, 0x70, 0x17, 0x6e, 0x04, 0xf9, 0x31, 0x5c, 0x43, 0x6c, 0xe7, 0xd3, 0xe1, 0x21, 0x78, 0x48, 0xbc, 0x74, 0x11, 0x19, 0x7f, 0x64, 0xa3, 0xcb, 0x48, 0x07, 0x75, 0x76, 0xa1, 0x4f, 0x90, 0x84, 0xfd, 0xc7, 0x33, 0x4a, 0x41, 0x3a, 0x76, 0x93, 0x96, 0x06, 0x2c, 0xa1 }; uint8_t h1[HASHBITLEN/8]; uint8_t h2[HASHBITLEN/8]; void printbytes(uint8_t const *p, int n) { int i; for (i=0; i!=n; ++i) printf("%02x", p[i]); printf("\n"); } int main() { int i; printf("Example collision pair for EnRUPT-256\n"); printf("2008-11-06, Sebastiaan Indesteege, COSIC, Katholieke Universiteit Leuven\n\n"); /* Hash first mesage */ if (Hash(HASHBITLEN, m1, LEN, h1) != SUCCESS) errx(1, "Hashing failed!"); printf("m1 = "); printbytes(m1, LEN/8); printf("EnRUPT-256(m1) = "); printbytes(h1, HASHBITLEN/8); printf("\n"); /* Hash second mesage */ if (Hash(HASHBITLEN, m2, LEN, h2) != SUCCESS) errx(1, "Hashing failed!"); printf("m2 = "); printbytes(m2, LEN/8); printf("EnRUPT-256(m2) = "); printbytes(h2, HASHBITLEN/8); printf("\n"); /* Verify collision */ for (i=0; i!=32; ++i) { if (h1[i] != h2[i]) { printf("ERROR: m1 and m2 do NOT collide\n"); return 1; } } printf("m1 and m2 collide!\n\n"); return 0; } --yNb1oOkm5a9FJOVX-- From hash-forum@nist.gov Thu Nov 6 15:00:08 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA6N01Iw002917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Nov 2008 15:00:03 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA6MtcZ6018020; Thu, 6 Nov 2008 17:56:42 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA6Mrkrn003770; Thu, 6 Nov 2008 17:53:46 -0500 Date: Thu, 6 Nov 2008 17:53:46 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Jayant Krishnamurthy" To: Multiple recipients of list Subject: Re: X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <20081105234317.63763.qmail@cr.yp.to> <49133460.9020102@mit.edu> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 In-Reply-To: <49133460.9020102@mit.edu> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 06 Nov 2008 15:00:04 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 91 Here's a suggestion for improving the table: Add columns to the table listing generic types of attacks (e.g. differential attacks), then list the safety factor of every hash function for every type of attack. (By safety factor I mean the total number of rounds divided by the number of rounds broken by the attack. I'm not sure how this would apply to hash functions without rounds). The table should also clearly note when the resistance of a hash function to a class of attacks has not been tested. Adding this information would make the table a more useful overview of cryptanalytic results against the listed hash functions. -Jayant On Thu, Nov 6, 2008 at 1:21 PM, Ronald L. Rivest wrote: > > Whether a cryptanalysis is external or internal is > irrelevant to whether it is a serious attack or not. > In the case of MD6, we were collaborating with the > "attackers" (Jean-Philippe Aumasson and Itai Dinur) to > see how well their new attacks (which are generic and > potentially applicable to any hash function) would apply > to MD6. The results of this work is described in our > submitted report, just as our own internal analyses are > described. The results, while excellent, are neither > surprising nor disturbing; they can distinguish MD6 from > random for a few more rounds than do naive statistical > attacks. MD6 is a conservative design with a large > number of rounds. > > The right question to ask is: has *your* design been > tested with respect to these attacks? If it has not, > this may be a weakness in your submission, as your design > may be particularly vulnerable to this class of attacks. > A submission that doesn't consider all possible classes of > attacks is arguably weaker than one that does... > > So, rather than noting whether there is external or internal > cryptanalysis, one should be noting whether there are reasons > (either from external review/attack or internal review/attack) > for believing that the proposal is secure against the various > known classes of attacks... > > Cheers, > Ron > > > On 11/6/2008 12:35 PM, Owen Anderson wrote: >> >> On Nov 6, 2008, at 6:31 AM, D. J. Bernstein wrote: >>> >>> The SHA-3 Zoo maintainers, on the basis of this paper "Cryptanalysis of >>> EnRUPT," characterized EnRUPT first as "broken" and then as "wounded." >>> Those characterizations are unjustified. The "attack" stated in the >>> paper is simultaneously slower and vastly more expensive than a standard >>> generic brute-force attack machine. >> >> For what it's worth, they have since revised the classification scheme to >> something that I think is much more fair, as it avoids using the >> negatively-associated word "wounded." >> >> * No external cryptanalysis known >> * External cryptanalysis known >> * Cryptanalysis known that invalidates the authors' claims or makes it >> unsuitable for SHA-3 (i.e. broken) >> >> As of now, two hashes (WaMM and Sgail) are listed as "broken" because >> there are trivial 2nd preimage attacks known against them. Two others (MD6 >> and now EnRUPT) are listed as having known external cryptanalytic results. >> Depending on your outlook, having external cryptanalytic results can be >> either a good thing (It was attacked and still didn't break!) or a bad thing >> (What if this attack is the tip of the iceberg?). I think it's best to >> leave that interpretation up to the viewer. >> >> --Owen >> >> >> > > -- > Ronald L. Rivest > Room 32-G692, Stata Center, MIT, Cambridge MA 02139 > Tel 617-253-5880, Email > > From hash-forum@nist.gov Thu Nov 6 15:14:30 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA6NENmi005211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Nov 2008 15:14:24 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA6NAJ6r014840; Thu, 6 Nov 2008 18:11:26 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA6N91nd001384; Thu, 6 Nov 2008 18:09:01 -0500 Date: Thu, 6 Nov 2008 18:09:01 -0500 Message-Id: <56420.189.18.249.87.1226012862.squirrel@webmail.larc.usp.br> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Paulo S. L. M. Barreto" To: Multiple recipients of list Subject: Re: Collisions for EnRUPT X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain;charset=iso-8859-1 MIME-Version: 1.0 X-To: hash-forum@nist.gov References: <20081106213418.GA22469@ssh.esat.kuleuven.be> In-Reply-To: <20081106213418.GA22469@ssh.esat.kuleuven.be> X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 06 Nov 2008 15:14:24 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 92 On Thu, November 6, 2008 19:41, Sebastiaan Indesteege said: > Hello, > > I've constructed a practical collision attack on EnRUPT-256 (default > values for all other tunable parameters). An example colliding message > pair is attached to this e-mail, in the form of C-code which is to be > linked against the reference implementation of EnRUPT. The output of > the program is given below Ah, *now* we're talking! Can anyone confirm that this is a collision for EnRUPT-256? Paulo. From hash-forum@nist.gov Thu Nov 6 15:54:36 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA6NsUFc009473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Nov 2008 15:54:31 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA6NqKwK003415; Thu, 6 Nov 2008 18:53:24 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA6NoggO018302; Thu, 6 Nov 2008 18:50:42 -0500 Date: Thu, 6 Nov 2008 18:50:42 -0500 Message-Id: <49138171.2060009@reikon.us> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Thomas Dixon To: Multiple recipients of list Subject: Re: Collisions for EnRUPT X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 In-Reply-To: <56420.189.18.249.87.1226012862.squirrel@webmail.larc.usp.br> References: <20081106213418.GA22469@ssh.esat.kuleuven.be> <56420.189.18.249.87.1226012862.squirrel@webmail.larc.usp.br> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 06 Nov 2008 15:54:32 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 93 Paulo S. L. M. Barreto wrote: > On Thu, November 6, 2008 19:41, Sebastiaan Indesteege said: >> Hello, >> >> I've constructed a practical collision attack on EnRUPT-256 (default >> values for all other tunable parameters). An example colliding message >> pair is attached to this e-mail, in the form of C-code which is to be >> linked against the reference implementation of EnRUPT. The output of >> the program is given below > > Ah, *now* we're talking! Can anyone confirm that this is a collision for > EnRUPT-256? > > Paulo. > I can confirm that using the reference implementation (from http://www.enrupt.com/SHA3/), along with the given source, the output matches that of the original post. From hash-forum@nist.gov Thu Nov 6 16:11:11 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA70B6ZR011543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Nov 2008 16:11:07 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA7086ZS028396; Thu, 6 Nov 2008 19:08:08 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA705c4v015110; Thu, 6 Nov 2008 19:05:38 -0500 Date: Thu, 6 Nov 2008 19:05:38 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Sean O'Neil" To: Multiple recipients of list Subject: Re: Collisions for EnRUPT X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: <20081106213418.GA22469@ssh.esat.kuleuven.be> <56420.189.18.249.87.1226012862.squirrel@webmail.larc.usp.br> In-Reply-To: <56420.189.18.249.87.1226012862.squirrel@webmail.larc.usp.br> Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 06 Nov 2008 16:11:07 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 94 Well, it looks like EnRUPT is out then, more work to be done... Good luck to everyone else, especially to all the simplest, the smallest and the fastest submissions! :) On Thu, November 6, 2008 19:41, Sebastiaan Indesteege said: > I've constructed a practical collision attack on EnRUPT-256 Best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. PS: I also wish everyone fewer crackpot "attacks" to deal with. ;) From hash-forum@nist.gov Thu Nov 6 16:23:42 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA70NcCF013160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Nov 2008 16:23:39 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA70MrUi025926; Thu, 6 Nov 2008 19:22:55 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA70KRfN012043; Thu, 6 Nov 2008 19:20:27 -0500 Date: Thu, 6 Nov 2008 19:20:27 -0500 Message-Id: <56983.189.18.249.87.1226016667.squirrel@webmail.larc.usp.br> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Paulo S. L. M. Barreto" To: Multiple recipients of list Subject: Re: Collisions for EnRUPT X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain;charset=iso-8859-1 MIME-Version: 1.0 X-To: hash-forum@nist.gov References: <20081106213418.GA22469@ssh.esat.kuleuven.be> <56420.189.18.249.87.1226012862.squirrel@webmail.larc.usp.br> <49138171.2060009@reikon.us> In-Reply-To: <49138171.2060009@reikon.us> X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 06 Nov 2008 16:23:39 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 95 On Thu, November 6, 2008 21:50, Thomas Dixon said: > I can confirm that using the reference implementation (from > http://www.enrupt.com/SHA3/), along with the given source, the output > matches that of the original post. Then it is unquestionably broken. Maybe Sebastiaan can tell if the other sizes can be broken as well and at what cost? Paulo. From hash-forum@nist.gov Thu Nov 6 19:07:51 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA737k8f004985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Nov 2008 19:07:47 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA734EAn007468; Thu, 6 Nov 2008 22:04:19 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA7337O0005836; Thu, 6 Nov 2008 22:03:07 -0500 Date: Thu, 6 Nov 2008 22:03:07 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: zooko To: Multiple recipients of list Subject: Re: Collisions for EnRUPT X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: <20081106213418.GA22469@ssh.esat.kuleuven.be> <56420.189.18.249.87.1226012862.squirrel@webmail.larc.usp.br> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 06 Nov 2008 19:07:47 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 96 Way to go, Sebastian Indesteege! irRUPT has many good qualities, including small state size, fast performance on 32-bit CPUs, and especially its simplicity. Hopefully simplicity means we learn more when it breaks. Can any stream hash with such small state size and few cycles per byte be secure? (I hope so! They have the kind of performance properties that I want.) Is there a hash function which is similarly simple to describe, but which is resistant to linear cryptanalysis? How is it that irRUPT's analysis based on testing compressibility of ANFs appeared to the designers to preclude linear cryptanalysis but was wrong? Is the notion of testing compressibility of ANFs inherently unreliable, or is there a variant of it which would have predicted this attack? What would the designers of irRUPT do differently if they had seen this linear cryptanalysis attack? Scanning through the other submissions that have already been posted on the SHA-3 Zoo site, I see that Boole is a stream hash with small state size and few cycles per byte. Hopefully the cryptanalysts will be staring hard at it next. ;-) Thanks, Zooko --- http://allmydata.org -- Tahoe, the Least-Authority Filesystem http://allmydata.com -- back up all your files for $10/month From hash-forum@nist.gov Thu Nov 6 19:21:16 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA73LBeB005929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Nov 2008 19:21:12 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA73HuPC030191; Thu, 6 Nov 2008 22:18:00 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA73Hbha001381; Thu, 6 Nov 2008 22:17:37 -0500 Date: Thu, 6 Nov 2008 22:17:37 -0500 Message-Id: <4913B131.4090903@qualcomm.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Greg Rose To: Multiple recipients of list Subject: Re: Collisions for EnRUPT X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: References: <20081106213418.GA22469@ssh.esat.kuleuven.be> <56420.189.18.249.87.1226012862.squirrel@webmail.larc.usp.br> MIME-Version: 1.0 X-To: "hash-forum@nist.gov" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 06 Nov 2008 19:21:12 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 97 zooko wrote: > Way to go, Sebastian Indesteege! > > irRUPT has many good qualities, including small state size, fast > performance on 32-bit CPUs, and especially its simplicity. Hopefully > simplicity means we learn more when it breaks. Can any stream hash > with such small state size and few cycles per byte be secure? (I > hope so! They have the kind of performance properties that I want.) > > Is there a hash function which is similarly simple to describe, but > which is resistant to linear cryptanalysis? > > How is it that irRUPT's analysis based on testing compressibility of > ANFs appeared to the designers to preclude linear cryptanalysis but > was wrong? Is the notion of testing compressibility of ANFs > inherently unreliable, or is there a variant of it which would have > predicted this attack? > > What would the designers of irRUPT do differently if they had seen > this linear cryptanalysis attack? > > Scanning through the other submissions that have already been posted > on the SHA-3 Zoo site, I see that Boole is a stream hash with small > state size and few cycles per byte. Hopefully the cryptanalysts will > be staring hard at it next. ;-) Yeah, and I'll be trying to figure out what went wrong with EnRUPT too. I'd rather break it myself than have someone break it to me... Greg. From hash-forum@nist.gov Thu Nov 6 20:43:17 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA74hB58012684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Nov 2008 20:43:12 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA74Pu2s027666; Thu, 6 Nov 2008 23:25:58 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA74P9mq001796; Thu, 6 Nov 2008 23:25:09 -0500 Date: Thu, 6 Nov 2008 23:25:09 -0500 Message-Id: <86917377-B43C-42D8-880A-F4E74187B3B7@cryptolib.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Sean O'Neil" To: Multiple recipients of list Subject: Re: Collisions for EnRUPT X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed References: <20081106213418.GA22469@ssh.esat.kuleuven.be> <56420.189.18.249.87.1226012862.squirrel@webmail.larc.usp.br> <49138171.2060009@reikon.us> <56983.189.18.249.87.1226016667.squirrel@webmail.larc.usp.br> In-Reply-To: <56983.189.18.249.87.1226016667.squirrel@webmail.larc.usp.br> Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 06 Nov 2008 20:43:12 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 98 > Maybe Sebastiaan can tell if the other sizes can be broken as well > and at what cost? The cost of this attack would most probably be simply squared for EnRUPT64x2-512/4, that is 80-96 bits according to Sebastiaan's calculations. I know that tweaks are not accepted past the submission deadline, but the solution is most certainly to replace (2*x[r^1] ^ x [r+4]) with (2*x[r^1] | x[r+4]) in ïr1 [to be called ör1], which has exactly the same strength according to all our other tests, but requires the brackets that make it look a bit unattractive in C/PHP [replacing it with & is significantly weaker btw]. It is obvious that having to guess, I had overestimated the cost of linearization quite significantly and chosen the prettier variant over the stronger one. Learning something new every day... From now on, EnRUPT can be considered updated with ör1. At the first glance, just over a half of the state in input is required to find a collision, so according to my wild speculation, even with a sufficient amount of nonlinearity [for any such round function that is], the number of rounds would probably also have to be doubled to prevent any kind of modifications of this attack from succeeding. While this lowers the speed by half, it seems inevitably required for collision resistance of stream hash functions of such structure. With s=8, only EnRUPTx4 with H=16 truncated to produce a hash value of any wanted size would be as fast as the recommended x2 variants, at least in hardware. > What would the designers of irRUPT do differently if they had seen > this linear cryptanalysis attack? Actually, this attack has nothing to do with linear cryptanalysis. It is linearization, that is approximation of ADD with XOR. It is something the cost of which I simply could not find anywhere or measure myself. It is a structural issue very similar to Guess-and- Determine attacks and does not depend on the quality of the round function at all, and hence cannot be picked up by the ANF analysis. Now that we can see its real cost, it should be easy to prevent it without any structural changes affecting resistance to any other attacks. If I as much as suspected that linearization could be that cheap, I would have most certainly chosen OR instead of XOR to combine the neighbours. The delta accumulators XOR them together and the input words with them continuously anyway. If a cheap ADD->XOR approximation still leaves the attacker with a large and complex set of nonlinear equations to solve, they are out of luck [see PPS below]. The truth is, block hashing has been studied for quite a few years. So between block and stream hashing, we chose the least researched variant. Even if the block hash had survived all the attacks, we would probably have never known if the stream hashing was secure or not. Now thanks to Sebastiaan's efforts we see a potential weakness in such structures that needs to be thoroughly considered by the designer. Best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. PS: I have noticed that people point out the apparently low diffusion rate of EnRUPT. It is actually roughly the same as in XXTEA. Appearances can be deceiving. The subtle single-bit left shift just hides it. Each bit is updated by 4 bits of the neighbours as in XXTEA, shift-rotated mostly by 4,5,7 and 8 bits. Then the delta accumulators spread the word... PPS: For the curious ones, f=rotr((2*x[r^1]|x[r+4])^d[1]^r,w/ 4),f^=f<<3,x[r+2]^=f,d[r&1]^=f^x[r], that is replacing the only ADD in ör1 (multiplication by 9) with XOR [let's call this one xör1] is about as strong as ör1 itself according to the thorough ANF analysis, so linearization should have no effect at all. If it wasn't for the damn brackets, I would have certainly chosen OR instead of XOR to combine the neighbours, just in case... So if tweaks are even remotely allowed, ör1 is the tweak. xör1 is just as good, especially good for hardware, just not as pretty looking in software. From hash-forum@nist.gov Fri Nov 7 00:33:37 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA78XWpv003559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Nov 2008 00:33:33 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA78TC3v019193; Fri, 7 Nov 2008 03:29:18 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA78Rtst021720; Fri, 7 Nov 2008 03:27:55 -0500 Date: Fri, 7 Nov 2008 03:27:55 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Stefan.Lucks@uni-weimar.de To: Multiple recipients of list Subject: Re: Evaluating attack costs X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: TEXT/PLAIN; charset=US-ASCII MIME-Version: 1.0 References: <20081106181444.13471.qmail@cr.yp.to> <7A15A8C1-351C-4191-B6DE-0BAD728FBBFB@pgpeng.com> In-Reply-To: <7A15A8C1-351C-4191-B6DE-0BAD728FBBFB@pgpeng.com> X-To: Multiple recipients of list X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 07 Nov 2008 00:33:33 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 99 On Thu, 6 Nov 2008, Jon Callas wrote: > With my engineering hat on, if an algorithm has a break that takes 2^384 > memory, it's hard for me to even say that with a straight face. Why should 2^384 units of memory be any worse than, say, 2^400 computations? Any technolgy which would enable humans to either store such a lot of information, or to perform so many computations, is pure science fiction -- more fiction than science, indeed. We very deliberately force ourselves to deal with such huge numbers, but then we must not assume that any science fiction technology preserves the current cost ratio between space and computation. There is one limit: Memory is irrelevant if you don't have the time to read or write it at least once. (Passive memory, not doing any fancy computations!) > Cryptanalysis that requires more memory than the planet can hold is a > lower-grade attack than cryptanalysis that requires the memory in my > laptop. What is worse: Cryptanalysis which could be performed in a few months if one had more memory than the planet can hold? Or cryptanalysis which takes a modeate amount of memory and a few million years? Yes, I am seriously asking that question. My personal answer is neither is worse or better. Both attacks can be valid cryptanalytic observations - attacks always improve. Without a further improvement, neither attack is practical. > Consensus is served by people feeling good about some set of functions. A > dodgy attack looks artificially bad at first, but as time goes on might > artificially look good. Agreed! And this is why I am so irritated that Dan feels the urge to turn down the good work done by Dimitry and Ivica. So long Stefan -- ------ Stefan Lucks -- Bauhaus-University Weimar -- Germany ------ Stefan dot Lucks at uni minus weimar dot de ------ I love the taste of Cryptanalysis in the morning! ------ From hash-forum@nist.gov Fri Nov 7 01:27:48 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA79RgxL010663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Nov 2008 01:27:43 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA79NOWa007599; Fri, 7 Nov 2008 04:23:27 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA79N7pt031258; Fri, 7 Nov 2008 04:23:07 -0500 Date: Fri, 7 Nov 2008 04:23:07 -0500 Message-Id: <08EB9FB3-6A04-4186-B3D3-8E969C3445C0@pgpeng.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Jon Callas To: Multiple recipients of list Subject: Re: Evaluating attack costs X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes X-Mailer: Apple Mail (2.929.2) References: <20081106181444.13471.qmail@cr.yp.to> <7A15A8C1-351C-4191-B6DE-0BAD728FBBFB@pgpeng.com> Mime-Version: 1.0 (Apple Message framework v929.2) In-Reply-To: X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 07 Nov 2008 01:27:44 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 100 On Nov 7, 2008, at 12:27 AM, Stefan.Lucks@uni-weimar.de wrote: > > On Thu, 6 Nov 2008, Jon Callas wrote: > >> With my engineering hat on, if an algorithm has a break that takes >> 2^384 >> memory, it's hard for me to even say that with a straight face. > > Why should 2^384 units of memory be any worse than, say, 2^400 > computations? Any technolgy which would enable humans to either > store such > a lot of information, or to perform so many computations, is pure > science > fiction -- more fiction than science, indeed. We very deliberately > force > ourselves to deal with such huge numbers, but then we must not > assume that > any science fiction technology preserves the current cost ratio > between > space and computation. Because of some realities of scaling. Let me insert the sound of one hand waving, but in general, it's easier to parallelize a large calculation (like exhausting a keyspace of a block cipher) than to parallelize lots of small hunks of memory into a large one. I can intuit how you would try 2^400 keys, even if you need more computers than fit into a galactic cluster better than I can intuit 2^400 units of memory. In the Poetics, Aristotle said that probably impossibilities are better than improbable possibilities. He was talking about fiction and drama, but the principle applies here. An impossible calculation is intuitively preferable to a massive chunk of memory. > There is one limit: Memory is irrelevant if you don't have the time to > read or write it at least once. (Passive memory, not doing any fancy > computations!) I think you're touching on exactly what I'm saying here. > > >> Cryptanalysis that requires more memory than the planet can hold is a >> lower-grade attack than cryptanalysis that requires the memory in my >> laptop. > > What is worse: Cryptanalysis which could be performed in a few > months if > one had more memory than the planet can hold? Or cryptanalysis which > takes > a modeate amount of memory and a few million years? > > Yes, I am seriously asking that question. > > My personal answer is neither is worse or better. Both attacks can be > valid cryptanalytic observations - attacks always improve. Without a > further improvement, neither attack is practical. My answer is that the second is worse. I can imagine parallelizing that calculation into a grid computation of all the light-bulb and door-knob controllers on the earth. I simply don't worry about more memory than a planet. > > >> Consensus is served by people feeling good about some set of >> functions. A >> dodgy attack looks artificially bad at first, but as time goes on >> might >> artificially look good. > > Agreed! And this is why I am so irritated that Dan feels the urge to > turn > down the good work done by Dimitry and Ivica. I don't think he's turning it down, he's expressing an opinion about its relevance to the competition. Jon -- Jon Callas CTO, CSO PGP Corporation Tel: +1 (650) 319-9016 200 Jefferson Drive Fax: +1 (650) 319-9001 Menlo Park, CA 94025 PGP: ed15 5bdf cd41 adfc 00f3 USA 28b6 52bf 5a46 bc98 e63d From hash-forum@nist.gov Fri Nov 7 01:30:40 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA79UZeF010893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Nov 2008 01:30:35 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA79NDxi007565; Fri, 7 Nov 2008 04:23:19 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA79MqsF031189; Fri, 7 Nov 2008 04:22:52 -0500 Date: Fri, 7 Nov 2008 04:22:52 -0500 Message-Id: <20081107091636.GB30756@ssh.esat.kuleuven.be> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Sebastiaan Indesteege To: Multiple recipients of list Subject: Re: Collisions for EnRUPT X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas In-Reply-To: <86917377-B43C-42D8-880A-F4E74187B3B7@cryptolib.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 References: <20081106213418.GA22469@ssh.esat.kuleuven.be> <56420.189.18.249.87.1226012862.squirrel@webmail.larc.usp.br> <49138171.2060009@reikon.us> <56983.189.18.249.87.1226016667.squirrel@webmail.larc.usp.br> <86917377-B43C-42D8-880A-F4E74187B3B7@cryptolib.com> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 07 Nov 2008 01:30:36 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 101 On Thu, Nov 06, 2008 at 11:25:09PM -0500, Sean O'Neil wrote: > > >Maybe Sebastiaan can tell if the other sizes can be broken as well > >and at what cost? > > The cost of this attack would most probably be simply squared for > EnRUPT64x2-512/4, that is 80-96 bits according to Sebastiaan's > calculations. I'm afraid I have to disagree here. Increasing the state size does not appear to help at all. Some quick experiments lead to a 10-round differential with complexity approximately 2^44 (before optimisations) for EnRUPT64x2-512/4. For EnRUPT64x2-384/4, I found an 8-round differential with complexity approximately 2^54. Slightly higher, but still significantly below the birthday bound. > I know that tweaks are not accepted past the submission > deadline, but the solution is most certainly to replace (2*x[r^1] ^ x > [r+4]) with (2*x[r^1] | x[r+4]) in ïr1 [to be called ör1], which has > exactly the same strength according to all our other tests, but > requires the brackets that make it look a bit unattractive in C/PHP > [replacing it with & is significantly weaker btw]. It is obvious that > having to guess, I had overestimated the cost of linearization quite > significantly and chosen the prettier variant over the stronger one. > Learning something new every day... From now on, EnRUPT can be > considered updated with ör1. I do not think this will help. OR can either absorp or pass differences, at a cost in probability of .5 per bit. This can actually give an adversary more freedom when building a differential, possibly even leading to better attacks. > At the first glance, just over a half of the state in input is > required to find a collision, so according to my wild speculation, > even with a sufficient amount of nonlinearity [for any such round > function that is], the number of rounds would probably also have to > be doubled to prevent any kind of modifications of this attack from > succeeding. While this lowers the speed by half, it seems inevitably > required for collision resistance of stream hash functions of such > structure. With s=8, only EnRUPTx4 with H=16 truncated to produce a > hash value of any wanted size would be as fast as the recommended x2 > variants, at least in hardware. Increasing the number of rounds per word would indeed help, but I'm not convinced that merely doubling it is going to be enough. > >What would the designers of irRUPT do differently if they had seen > >this linear cryptanalysis attack? > > Actually, this attack has nothing to do with linear cryptanalysis. It > is linearization, that is approximation of ADD with XOR. It is > something the cost of which I simply could not find anywhere or > measure myself. Simply put, the oversight in the initial security analysis with respect to this type of attacks is that an adversary can find a message pair following the differential one message word at a time. This means that the complexities should be added rather than multiplied. Regards, Sebastiaan -- Sebastiaan Indesteege sebastiaan.indesteege@esat.kuleuven.be K.U.Leuven, ESAT SCD/COSIC, http://www.esat.kuleuven.be/cosic/ Kasteelpark Arenberg 10 bus 2446, phone: +32 16 321049 B-3001 Leuven-Heverlee, Belgium. fax: +32 16 321969 Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm From hash-forum@nist.gov Fri Nov 7 03:13:00 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA7BCtCr021213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Nov 2008 03:12:56 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA7BC6Nl003305; Fri, 7 Nov 2008 06:12:09 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA7BBpuf017000; Fri, 7 Nov 2008 06:11:51 -0500 Date: Fri, 7 Nov 2008 06:11:51 -0500 Message-Id: <49142244.2010001@larc.usp.br> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Paulo S. L. M. Barreto" To: Multiple recipients of list Subject: Re: attacking all submissions X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 In-Reply-To: References: <20081105234317.63763.qmail@cr.yp.to> <49131F54.8020001@larc.usp.br> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 07 Nov 2008 03:12:56 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 102 Just an addendum: Stefan.Lucks@uni-weimar.de wrote: > Now, please tell me how you can find a collision in less than O(2^{n/2}) > time, or a preimage faster than in O(2^n) time? For " *all* submissions > without even knowing them", as you claim? Or for Skein, specifically? First, this is not what I claimed (read my text again). Second, beware of your own text: you are asking for "a collision in less than O(2^{n/2}) time, *or* a preimage faster than in O(2^n) time" and this too can certainly be achieved. Cheers, Paulo. From hash-forum@NIST.GOV Fri Nov 7 03:15:24 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA7BFJ1R021432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Nov 2008 03:15:20 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA7BBuIN011434; Fri, 7 Nov 2008 06:11:57 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA7BBcpB016125; Fri, 7 Nov 2008 06:11:38 -0500 Date: Fri, 7 Nov 2008 06:11:38 -0500 Message-Id: <4914216B.70904@larc.usp.br> Errors-To: sara@NIST.GOV Reply-To: hash-forum@NIST.GOV Originator: hash-forum@nist.gov Sender: hash-forum@NIST.GOV Precedence: bulk From: "Paulo S. L. M. Barreto" To: Multiple recipients of list Subject: Re: attacking all submissions X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 In-Reply-To: References: <20081105234317.63763.qmail@cr.yp.to> <49131F54.8020001@larc.usp.br> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 07 Nov 2008 03:15:20 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 103 Hi Stefan, >> [...] I can "wound" *all* submissions without even knowing them, >> including your own submission Skein. > > Please tell me how! > > (I didn't want to, but I couldn't resist to take the bite.) Why, isn't it obvious? Recall my full paragraph: > If one is to count an "attack" that is grossly worse than brute force, > and a submission is to be considered "wounded" because of this, I can > "wound" *all* submissions without even knowing them, including your own > submission Skein. Just pick brute force and insert somewhere a huge useless loop that plays with a huge useless data structure. This is grossly worse than brute force and applies to any hash, doesn't it? Cheers, Paulo. From hash-forum@nist.gov Fri Nov 7 03:42:55 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA7BgpUe024179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Nov 2008 03:42:52 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA7BdfZA031693; Fri, 7 Nov 2008 06:39:43 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA7BcnO2004564; Fri, 7 Nov 2008 06:38:49 -0500 Date: Fri, 7 Nov 2008 06:38:49 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Stefan.Lucks@uni-weimar.de To: Multiple recipients of list Subject: Re: attacking all submissions X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: TEXT/PLAIN; charset=US-ASCII MIME-Version: 1.0 References: <20081105234317.63763.qmail@cr.yp.to> <49131F54.8020001@larc.usp.br> <4914216B.70904@larc.usp.br> In-Reply-To: <4914216B.70904@larc.usp.br> X-To: Multiple recipients of list X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 07 Nov 2008 03:42:52 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 104 > > Please tell me how! > > > > (I didn't want to, but I couldn't resist to take the bite.) > > Why, isn't it obvious? [...] Please read my complete email you are replying to. I made it very specific what I meant. Stefan -- ------ Stefan Lucks -- Bauhaus-University Weimar -- Germany ------ Stefan dot Lucks at uni minus weimar dot de ------ I love the taste of Cryptanalysis in the morning! ------ From hash-forum@nist.gov Fri Nov 7 04:00:44 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA7C0dxI026371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Nov 2008 04:00:40 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA7BsjJZ025973; Fri, 7 Nov 2008 06:55:51 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA7Bqvkk031616; Fri, 7 Nov 2008 06:52:57 -0500 Date: Fri, 7 Nov 2008 06:52:57 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Stefan.Lucks@uni-weimar.de To: Multiple recipients of list Subject: Re: attacking all submissions X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: TEXT/PLAIN; charset=US-ASCII MIME-Version: 1.0 References: <20081105234317.63763.qmail@cr.yp.to> <49131F54.8020001@larc.usp.br> <49142244.2010001@larc.usp.br> In-Reply-To: <49142244.2010001@larc.usp.br> X-To: Multiple recipients of list X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 07 Nov 2008 04:00:40 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 105 On Fri, 7 Nov 2008, Paulo S. L. M. Barreto wrote: > Stefan.Lucks@uni-weimar.de wrote: > > Now, please tell me how you can find a collision in less than O(2^{n/2}) > > time, or a preimage faster than in O(2^n) time? For " *all* submissions > > without even knowing them", as you claim? Or for Skein, specifically? > > First, this is not what I claimed (read my text again). I apologise for misunderstanding you! I see, you wrote "If one is to count an 'attack' that is grossly worse than brute force, [...]". I agree that any such attack is garbage, and not a valid attack. I thought you sided with Dan, but apparently, when you wrote "grossly worse than brute force" you meant something different from him. In any case, my point was and is that Dimitry's and Ivica's actually improves over brute force, even if it only does only in some well-established theoretical model. Their work deserves respect. > Second, beware of your own text: you are asking for "a collision in less > than O(2^{n/2}) time, *or* a preimage faster than in O(2^n) time" and > this too can certainly be achieved. Certainly? OK, I take the bite again. How can this be achieved? So long Stefan -- ------ Stefan Lucks -- Bauhaus-University Weimar -- Germany ------ Stefan dot Lucks at uni minus weimar dot de ------ I love the taste of Cryptanalysis in the morning! ------ From hash-forum@nist.gov Fri Nov 7 04:10:31 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA7CAQ7E029920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Nov 2008 04:10:27 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA7C8H3b022479; Fri, 7 Nov 2008 07:08:20 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA7C7wsE028903; Fri, 7 Nov 2008 07:07:58 -0500 Date: Fri, 7 Nov 2008 07:07:58 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Sean O'Neil" To: Multiple recipients of list Subject: Re: attacking all submissions X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: <20081105234317.63763.qmail@cr.yp.to> <49131F54.8020001@larc.usp.br> <49142244.2010001@larc.usp.br> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 07 Nov 2008 04:10:27 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 106 On 7 Nov 2008, at 12:52, Stefan.Lucks@uni-weimar.de wrote: >> Second, beware of your own text: you are asking for "a collision >> in less >> than O(2^{n/2}) time, *or* a preimage faster than in O(2^n) time" and >> this too can certainly be achieved. > > Certainly? OK, I take the bite again. How can this be achieved? With all due respect, it sounds like someone who has never heard of time-memory trade-offs or parallel brute-force. Best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. From hash-forum@nist.gov Fri Nov 7 05:09:11 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA7D961e005579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Nov 2008 05:09:07 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA7D3lUH025131; Fri, 7 Nov 2008 08:03:54 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA7D2DEj014437; Fri, 7 Nov 2008 08:02:13 -0500 Date: Fri, 7 Nov 2008 08:02:13 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Stefan.Lucks@uni-weimar.de To: Multiple recipients of list Subject: Re: attacking all submissions X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: TEXT/PLAIN; charset=US-ASCII MIME-Version: 1.0 References: <20081105234317.63763.qmail@cr.yp.to> <49131F54.8020001@larc.usp.br> <49142244.2010001@larc.usp.br> In-Reply-To: X-To: Multiple recipients of list X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 07 Nov 2008 05:09:07 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 107 On Fri, 7 Nov 2008, Sean O'Neil wrote: > > On 7 Nov 2008, at 12:52, Stefan.Lucks@uni-weimar.de wrote: > > > >Second, beware of your own text: you are asking for "a collision in less > > >than O(2^{n/2}) time, *or* a preimage faster than in O(2^n) time" and > > >this too can certainly be achieved. > > > >Certainly? OK, I take the bite again. How can this be achieved? > > > With all due respect, it sounds like someone who has never heard of > time-memory trade-offs or parallel brute-force. I guess, you are one of those who have heard of time-memory tradeoffs or parallel brute force? Then please explain how you can improve over O(2^n) computations for preimages or O(2^{n/2}) computations for collisions. So long Stefan -- ------ Stefan Lucks -- Bauhaus-University Weimar -- Germany ------ Stefan dot Lucks at uni minus weimar dot de ------ I love the taste of Cryptanalysis in the morning! ------ From hash-forum@nist.gov Fri Nov 7 05:32:27 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA7DWM99009443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Nov 2008 05:32:23 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA7DVR5u012874; Fri, 7 Nov 2008 08:31:30 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA7DV4tM011310; Fri, 7 Nov 2008 08:31:04 -0500 Date: Fri, 7 Nov 2008 08:31:04 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Sean O'Neil" To: Multiple recipients of list Subject: Re: attacking all submissions X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: <20081105234317.63763.qmail@cr.yp.to> <49131F54.8020001@larc.usp.br> <49142244.2010001@larc.usp.br> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 07 Nov 2008 05:32:23 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 108 On 7 Nov 2008, at 14:02, Stefan.Lucks@uni-weimar.de wrote: >>>> Second, beware of your own text: you are asking for "a collision >>>> in less >>>> than O(2^{n/2}) time, *or* a preimage faster than in O(2^n) >>>> time" and >>>> this too can certainly be achieved. > Then please explain how you can improve over O(2^n) computations for > preimages or O(2^{n/2}) computations for collisions. So is it "time" or "computations"? What is it that you are talking about? Computational complexity or specifically *time*? It is hard to argue with someone who is continuously shifting the ground, confusing *time* with *computational complexity*, confusing the number of required known/chosen plaintext/ciphertext pairs with memory requirements, and completely dismissing the notion of the *cost* of attack by disregarding the cost of memory, not even mentioning his blunt dismissal of generic parallel brute-force and time-memory-data trade-offs, which apply to every single cipher and hash function serving as the basis for determining if someone's cryptanalysis is a successful attack or not... Best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. From hash-forum@nist.gov Fri Nov 7 06:09:49 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA7E9h10015833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Nov 2008 06:09:45 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA7DxICD022356; Fri, 7 Nov 2008 08:59:24 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA7DwZid001449; Fri, 7 Nov 2008 08:58:35 -0500 Date: Fri, 7 Nov 2008 08:58:35 -0500 Message-Id: <491447BF.8010400@larc.usp.br> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Paulo S. L. M. Barreto" To: Multiple recipients of list Subject: Re: attacking all submissions X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 In-Reply-To: References: <20081105234317.63763.qmail@cr.yp.to> <49131F54.8020001@larc.usp.br> <4914216B.70904@larc.usp.br> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 07 Nov 2008 06:09:45 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 109 Stefan, >>> Please tell me how! >>> >>> (I didn't want to, but I couldn't resist to take the bite.) >> Why, isn't it obvious? [...] > > Please read my complete email you are replying to. I made it very specific > what I meant. I too made my original text very specific, yet you truncated my text when quoting it, then changed the conditions of the discussion. Since this discussion is getting too heated (and too boring, and pointless), I'll do as you told you were going to do yourself regarding Dan Bernstein, namely, no more comments... for now, at any rate. Cheers, Paulo. From hash-forum@nist.gov Fri Nov 7 02:47:29 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA7AlOas018362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Nov 2008 02:47:25 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA7AijdP030936; Fri, 7 Nov 2008 05:44:49 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA7AhrPg026340; Fri, 7 Nov 2008 05:43:53 -0500 Date: Fri, 7 Nov 2008 05:43:53 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Stefan.Lucks@uni-weimar.de To: Multiple recipients of list Subject: attacking all submissions X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: TEXT/PLAIN; charset=US-ASCII MIME-Version: 1.0 References: <20081105234317.63763.qmail@cr.yp.to> <49131F54.8020001@larc.usp.br> In-Reply-To: <49131F54.8020001@larc.usp.br> X-To: Multiple recipients of list X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 07 Nov 2008 02:47:25 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 110 Dear Paulo, > [...] I can "wound" *all* submissions without even knowing them, > including your own submission Skein. Please tell me how! (I didn't want to, but I couldn't resist to take the bite.) I am sure you know the usual model, but to avoid any misunderstandings, I'll describe it here. You have access to an infinite amount of memory (i.e., "Memory is free"). To write to the memory, you send an integer A ("address") and a value V, and from then on, Mem(A)=V. Any value previously stored at Mem(A) is lost, then. To read from memory, you send an integer A and receive the value V you most recently did store there. You have to make sure Mem(A) has been set to any value, before you read it. You are charged for any computations you do. Each memory store and memory read operation counts as a computation. Now, please tell me how you can find a collision in less than O(2^{n/2}) time, or a preimage faster than in O(2^n) time? For " *all* submissions without even knowing them", as you claim? Or for Skein, specifically? This is a theoretical model. Of course, it overestimates the adversary's capabilities -- but this is always better than underestimating the adversary. I.e., if there is no attack in that model, then there is no attack in a more realistic model. In any case, the model has been very useful in the past. It is implicit in almost all the cryptanalysis done during the AES competition. The main benefit is that this model avoids the cryptanalyst to get bogged down with too many dirty details, time-memory tradeoffs and the like. In other words, it is useful to get at least preliminary results quickly. So long Stefan -- ------ Stefan Lucks -- Bauhaus-University Weimar -- Germany ------ Stefan dot Lucks at uni minus weimar dot de ------ I love the taste of Cryptanalysis in the morning! ------ From hash-forum@nist.gov Fri Nov 7 06:36:25 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA7EaJOH020608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Nov 2008 06:36:20 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA7ER83s004994; Fri, 7 Nov 2008 09:27:12 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA7EQLQW026232; Fri, 7 Nov 2008 09:26:21 -0500 Date: Fri, 7 Nov 2008 09:26:21 -0500 Message-Id: <20081107142208.11725.qmail@cr.yp.to> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "D. J. Bernstein" To: Multiple recipients of list Subject: Re: Evaluating attack costs X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas In-Reply-To: <98EBB542F32B9D4CBB1EC5FE1D93D45B16448F69C9@ES02SNLNT.srn.sandia.gov> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 07 Nov 2008 06:36:21 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00,OBSCURED_EMAIL, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 111 Rich's double-DES example is instructive. Even though it's only at a 56-bit level it already illustrates the insanity of imagining instant access to unlimited quantities of free RAM. The goal here is to find 56-bit DES keys K,L such that simultaneously DES_L(DES_K(P1)) = C1 and DES_L(DES_K(P2)) = C2, given P1,P2,C1,C2. In other words, fix P1,P2, and define H as the hash function that maps (K,L) to (DES_L(DES_K(P1)),DES_L(DES_K(P2))); the goal is then to find a preimage (K,L) of (C1,C2) under H, given (C1,C2). Rich considers a "prehistoric attack" that works as follows. Compute the 23-byte string (DES_K(P1),DES_K(P2),K) for each 56-bit key K, and the 23-byte string (DES_L^(-1)(C1),DES_L^(-1)(C2),L) for each 56-bit key L. Store all of these strings on tape. Sort the complete list of strings to find collisions. Of course, there are much better ways to find collisions, but Rich insists on using the sophomoric store-and-sort algorithm, because he's trying to argue that RAM doesn't matter in evaluating attack costs. So let's take Rich's attack exactly as stated and see how expensive it is. It appears that tape can still be manufactured at slightly lower costs than disk, about $0.05/gigabyte, but Rich needs to store 23*2^57 bytes, i.e., 3 billion gigabytes, costing about 150 million dollars. Rich doesn't say how he plans to sort these 3 billion gigabytes of data on tape (aside from saying that sorting has "cost" 2^56*56*2), but let's look at the latest reported speed records for _disk_ sorting in http://www.hpl.hp.com/hosted/sortbenchmark/: * about 2400 seconds to sort 181 gigabytes on an Athlon 64; * about 200 seconds to sort 1024 gigabytes on a well-connected 910-node cluster costing millions of dollars. Even if Rich manages to build a cluster that can sort 1000 times as much data per second as the 910-node cluster---and that scales perfectly up to 3 billion gigabytes!---he'll need a week to get the sorting done. Let's compare this to the cost of a brute-force key search for a 56-bit key. The DES Cracker _ten years ago_ was built for under $250000 and was able to search 2^55 DES keys in only 4 days. The same money today would buy twenty COPACOBANA boxes, which together can search 2^55 DES keys in only 9 _hours_. For 150 million dollars we can reduce the COPACOBANA time to _one minute_. (COPACOBANA is built from FPGAs, by the way; at this scale we could easily afford ASICs and achieve even higher speeds.) To summarize: Compared to a standard brute-force 56-bit key-search machine, Rich has spent just as much money on _tapes_, plus even more money on a massive sorting cluster, and still needs TEN THOUSAND TIMES LONGER to carry out his attack. Rich says that these two are equally difficult attacks, "56 bits"; but he's clearly making _at least_ a 13-bit error, more than 20% of his "56 bits," even if we give him the massive sorting cluster for free. Scaling up to larger attacks makes the error even more obvious. Sorting n small pieces of data needs time proportional to n^(1/2) on the optimal two-dimensional mesh of size n---enough time for the same mesh to carry out n^(3/2) small parallel computations. (In principle three-dimensional machines could reduce square root to cube root, but the third dimension is limited by power input and by heat output.) This scaling has become increasingly obvious to people working on serious computations: * Over the years RAM access has become slower and slower and slower relative to computation, an unavoidable consequence of chips becoming larger and larger. The speed ratio scales as the square root of the chip size. * Access to storage on parallel machines has become slower and slower and slower relative to computation, an unavoidable consequence of machines becoming larger and larger. The speed ratio scales as the square root of the machine size. The same error that leads Rich to disregard factors of more than ten thousand in a "2^56" attack will also lead to factors of more than a billion in a "2^128" attack, and more than 2^60 in a "2^256" attack. I will readily agree that careful evaluation of attack costs isn't needed when we're talking about a 40-bit collision attack on a 512-bit hash. But if someone claims that the security level has been reduced 6%, from 512 bits to 480 bits, then we obviously can't tolerate the sort of sloppiness that leads to exponent errors of more than 20%. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago From hash-forum@nist.gov Fri Nov 7 06:47:25 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA7ElJEC022361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Nov 2008 06:47:21 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA7EiCQ8003785; Fri, 7 Nov 2008 09:44:13 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA7EhHcw028877; Fri, 7 Nov 2008 09:43:17 -0500 Date: Fri, 7 Nov 2008 09:43:17 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Stefan.Lucks@uni-weimar.de To: Multiple recipients of list Subject: Re: attacking all submissions X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: TEXT/PLAIN; charset=US-ASCII MIME-Version: 1.0 References: <20081105234317.63763.qmail@cr.yp.to> <49131F54.8020001@larc.usp.br> <49142244.2010001@larc.usp.br> In-Reply-To: X-To: Multiple recipients of list X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 07 Nov 2008 06:47:21 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 112 > So is it "time" or "computations"? What is it that you are talking about? Please read my previous postings in this thread. I gave a precise description of a computational model, which actually is quite common in cryptanalysis. -- ------ Stefan Lucks -- Bauhaus-University Weimar -- Germany ------ Stefan dot Lucks at uni minus weimar dot de ------ I love the taste of Cryptanalysis in the morning! ------ From hash-forum@nist.gov Fri Nov 7 07:04:51 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA7F4k4V025545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Nov 2008 07:04:47 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA7EwxZs004303; Fri, 7 Nov 2008 09:59:18 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA7EwIpN027584; Fri, 7 Nov 2008 09:58:18 -0500 Date: Fri, 7 Nov 2008 09:58:18 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Stefan.Lucks@uni-weimar.de To: Multiple recipients of list Subject: Re: attacking all submissions X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: TEXT/PLAIN; charset=US-ASCII MIME-Version: 1.0 References: <20081105234317.63763.qmail@cr.yp.to> <49131F54.8020001@larc.usp.br> <4914216B.70904@larc.usp.br> <491447BF.8010400@larc.usp.br> In-Reply-To: <491447BF.8010400@larc.usp.br> X-To: Multiple recipients of list X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 07 Nov 2008 07:04:48 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 113 > Since this discussion is getting too heated (and too boring, and pointless), > I'll do as you told you were going to do yourself regarding Dan Bernstein, > namely, no more comments... for now, at any rate. Fine! Some people fell the urge to neglect Dimitry's and Ivica's attack, and some dont. So long Stefan -- ------ Stefan Lucks -- Bauhaus-University Weimar -- Germany ------ Stefan dot Lucks at uni minus weimar dot de ------ I love the taste of Cryptanalysis in the morning! ------ From hash-forum@nist.gov Fri Nov 7 09:13:46 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA7HDdFW013679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Nov 2008 09:13:41 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA7HCCJB013400; Fri, 7 Nov 2008 12:12:44 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA7H9RSa004263; Fri, 7 Nov 2008 12:09:28 -0500 Date: Fri, 7 Nov 2008 12:09:27 -0500 Message-Id: <49147474.8020109@iaik.tugraz.at> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Christian Rechberger To: Multiple recipients of list Subject: Re: Comments on SHA-3 Zoo X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: <49133460.9020102@mit.edu> References: <20081105234317.63763.qmail@cr.yp.to> <49133460.9020102@mit.edu> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 07 Nov 2008 09:13:42 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 114 Ronald L. Rivest wrote: > > Whether a cryptanalysis is external or internal is > irrelevant to whether it is a serious attack or not. > In the case of MD6, we were collaborating with the > "attackers" (Jean-Philippe Aumasson and Itai Dinur) to > see how well their new attacks (which are generic and > potentially applicable to any hash function) would apply > to MD6. The results of this work is described in our > submitted report, just as our own internal analyses are > described. The results, while excellent, are neither > surprising nor disturbing; they can distinguish MD6 from > random for a few more rounds than do naive statistical > attacks. MD6 is a conservative design with a large > number of rounds. > > The right question to ask is: has *your* design been > tested with respect to these attacks? If it has not, > this may be a weakness in your submission, as your design > may be particularly vulnerable to this class of attacks. > A submission that doesn't consider all possible classes of > attacks is arguably weaker than one that does... > > So, rather than noting whether there is external or internal > cryptanalysis, one should be noting whether there are reasons > (either from external review/attack or internal review/attack) > for believing that the proposal is secure against the various > known classes of attacks... > > Cheers, > Ron Let me second Ron's suggestion here: to allow a fair comparison, eventually, attack methods and results need to be listed regardless of their origin. The SHA-3 Zoo (part of a project funded by the European commission) is work in progress in an early stage. As we move forward with it, more details will be added. For transparency reasons (and to facilitate multi-author editing) we make all updates available immediately. The internal/external distinction that is currently in place comes from the simple fact that we didn't go through a sufficient number of submissions yet to list internal cryptanalysis. We keep adding new candidates as we receive them. Until NIST publishes the first round candidates, this depends on submitters believing that early external scrutiny actually helps to build confidence, (hint, hint, ;-) ) Once the list of candidates is stable, we might want to have different tables allowing different means to compare the candidates. Your continued flow of suggestions is of course very welcome. Best regards, Christian From hash-forum@nist.gov Fri Nov 7 09:26:58 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA7HQrUK015997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Nov 2008 09:26:54 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA7HQMUq005284; Fri, 7 Nov 2008 12:26:27 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA7HQ0it005416; Fri, 7 Nov 2008 12:26:00 -0500 Date: Fri, 7 Nov 2008 12:26:00 -0500 Message-Id: <49147924.7030203@qualcomm.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Greg Rose To: Multiple recipients of list Subject: Re: attacking all submissions X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: References: <20081105234317.63763.qmail@cr.yp.to> <49131F54.8020001@larc.usp.br> <4914216B.70904@larc.usp.br> <491447BF.8010400@larc.usp.br> MIME-Version: 1.0 X-To: "hash-forum@nist.gov" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 07 Nov 2008 09:26:54 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 115 Stefan.Lucks@uni-weimar.de wrote: >> Since this discussion is getting too heated (and too boring, and pointless), >> I'll do as you told you were going to do yourself regarding Dan Bernstein, >> namely, no more comments... for now, at any rate. > > Fine! Some people fell the urge to neglect Dimitry's and Ivica's attack, > and some dont. I'm inclined to accept the work behind the attack as being valuable, irrespective of the current argument about its precise complexity; after all, it was a pre-announcement, not a submission for peer review, where (admittedly gross) details must be correct. Fundamentally, I see the work as being neither more nor less interesting than analyzing 25 rounds of a 100-round hash function. That is to say, still interesting and worth looking at and understanding. first and last word on this subject, Greg. From hash-forum@nist.gov Fri Nov 7 11:18:54 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA7JIihK002148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Nov 2008 11:18:50 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA7JI6ZZ026767; Fri, 7 Nov 2008 14:18:11 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA7JGKrB005280; Fri, 7 Nov 2008 14:16:20 -0500 Date: Fri, 7 Nov 2008 14:16:20 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Orr Dunkelman To: Multiple recipients of list Subject: Re: fse '09 - special session on hash functions proposal X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed MIME-Version: 1.0 References: In-Reply-To: X-To: Multiple recipients of list X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 07 Nov 2008 11:18:50 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 116 Dear all, While Markku suggests some interesting idea, FSE will not accommodate his request. The deadline of FSE is 24th of November (23:59 CET). Any attacks found after the deadline can still be presented in the rump session of FSE. We plan on having a relatively longer rump session in this FSE, to accommodate these presentations. I would like to point out two small details: * students traveling to FSE may apply for support from the conference (and are encouraged to do so in case of a need). * FSE is organized by IACR, it is not a "European" (nor "American", "Asian", or even "African") venue. Best regards to all, and see you in Leuven, -- Orr Dunkelman, Ecole Normale Superieure Departement d'Informatique Tel. +33-1-44-32-20-50 On Thu, 6 Nov 2008, Markku-Juhani O. Saarinen wrote: > > Hi, > > I just sent this to the Bart Preneel and Orr Dunkelman, but I think it > belongs to the list as well. > > Regarding the SHA-3 contest and FSE 2009: > > The FSE '09 deadline is already on November 24, and that's little too > soon for most us to have any relevant and polished cryptanalytic or > performance papers ready on the SHA-3 candidates already known. In a > few months the situation will be completely different. > > A person from NIST has informed me that apparently the First Candidate > Conference will not have slots for performance-related or cryptanalytic > results from people who are not "contestants" -- such as myself. See > below for the exact wording. > > I therefore propose that the "European" FSE '09 organizers would > consider taking the task in their own hands by dedicating a special > session for the most recent results on hash function cryptanalysis, > with paper submission deadlines in January (or even early February) > 2009. I'm sure that there would be no shortage of reviewers who can > judge papers in a week or two on this very special topic. > > I believe that such a session would be popular. Also some people -- > especially students -- could more easily justify the travel costs to > FSE if they were to give a talk, even a short talk. > > ---------------- > Date: Thu, 06 Nov 2008 11:06:10 -0500 > From: Sara Caswell > To: MJOS@IKI.FI > Subject: Re: first candidate conference submission deadlines > > At this moment we can't promise non-candidates speaking slot. We are > in the process of reviewing the submissions, and before we get a > chance to weed out the incomplete submissions, it's hard to say > anything concrete about the conference program. (...) > ---------------- > > Best Regards, > - Markku > > // Markku-Juhani O. Saarinen http://www.m-js.com > // Royal Holloway, University of London / Envault Corporation > > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm From hash-forum@nist.gov Fri Nov 7 16:37:14 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA80b8qD020077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Nov 2008 16:37:09 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA80aONw010138; Fri, 7 Nov 2008 19:36:31 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA80YDuo017061; Fri, 7 Nov 2008 19:34:13 -0500 Date: Fri, 7 Nov 2008 19:34:13 -0500 Message-Id: <98EBB542F32B9D4CBB1EC5FE1D93D45B16448F6A03@ES02SNLNT.srn.sandia.gov> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Schroeppel, Richard" To: Multiple recipients of list Subject: RE: Evaluating attack costs X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 In-Reply-To: <20081107142208.11725.qmail@cr.yp.to> References: <98EBB542F32B9D4CBB1EC5FE1D93D45B16448F69C9@ES02SNLNT.srn.sandia.gov>,<20081107142208.11725.qmail@cr.yp.to> X-Cc: "rcs@xmission.com" X-cc: "Schroeppel, Richard" , X-To: "hash-forum@nist.gov" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 07 Nov 2008 16:37:09 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,OBSCURED_EMAIL, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 117 Dan, this is silly. My note was discussing how to evaluate attack costs, using an attack on the 2DES cipher as an example. The question I addressed is whether the simple meet-in-the-middle attack should be regarded as costing O(2^56) (adding up the various component costs) or O(2^112) (multiplying execution time by the cost of tape). You sidestepped this issue. Instead, you pointed out that I ignored some log factors: One for the width of the data, and another in the NlogN sorting cost. This doesn't address the problem of devising a reasonable cost metric for memory, and how memory cost should be figured into the total computing cost. We can distinguish various kinds of memory -- tape, RAM, smart RAM, associative, etc. Sometimes they can be substituted, sometimes not. They will have different costs and access properties: 1GB of tape is cheaper than 1GB of RAM, and may or may not be just as useful in a particular situation. Should we count them as equally costly, so as to focus on the math? If we are going to get into comparing costs of chips and tape versus DVDs, we'll soon be talking about power consumption, financial discount rates, and environmental permits. Is this relevant to an abstract math discussion? If we are going to argue that 2^200 is a good attack, but 2^1000 is not, we're counting angels on pinheads. The cost of sorting machines isn't really in the same league. The reason for saying that 2^200 counts, but 2^1000 does not, is a judgment: we judge it more likely that the 2^200 is a harbinger of a yet to be discovered real attack, one that might not require every atom of silicon in the planet. Or that somehow a quantum computer can do 2^200 things, but not 2^1000. The basis for making such a judgment is perhaps better left unexamined, but it's not grounded in mathematics. Add, or multiply? Rich ________________________________________ From: hash-forum@nist.gov [hash-forum@nist.gov] On Behalf Of D. J. Bernstein [djb@cr.yp.to] Sent: Friday, November 07, 2008 7:26 AM To: Multiple recipients of list Subject: Re: Evaluating attack costs Rich's double-DES example is instructive. Even though it's only at a 56-bit level it already illustrates the insanity of imagining instant access to unlimited quantities of free RAM. The goal here is to find 56-bit DES keys K,L such that simultaneously DES_L(DES_K(P1)) = C1 and DES_L(DES_K(P2)) = C2, given P1,P2,C1,C2. In other words, fix P1,P2, and define H as the hash function that maps (K,L) to (DES_L(DES_K(P1)),DES_L(DES_K(P2))); the goal is then to find a preimage (K,L) of (C1,C2) under H, given (C1,C2). Rich considers a "prehistoric attack" that works as follows. Compute the 23-byte string (DES_K(P1),DES_K(P2),K) for each 56-bit key K, and the 23-byte string (DES_L^(-1)(C1),DES_L^(-1)(C2),L) for each 56-bit key L. Store all of these strings on tape. Sort the complete list of strings to find collisions. Of course, there are much better ways to find collisions, but Rich insists on using the sophomoric store-and-sort algorithm, because he's trying to argue that RAM doesn't matter in evaluating attack costs. So let's take Rich's attack exactly as stated and see how expensive it is. It appears that tape can still be manufactured at slightly lower costs than disk, about $0.05/gigabyte, but Rich needs to store 23*2^57 bytes, i.e., 3 billion gigabytes, costing about 150 million dollars. Rich doesn't say how he plans to sort these 3 billion gigabytes of data on tape (aside from saying that sorting has "cost" 2^56*56*2), but let's look at the latest reported speed records for _disk_ sorting in http://www.hpl.hp.com/hosted/sortbenchmark/: * about 2400 seconds to sort 181 gigabytes on an Athlon 64; * about 200 seconds to sort 1024 gigabytes on a well-connected 910-node cluster costing millions of dollars. Even if Rich manages to build a cluster that can sort 1000 times as much data per second as the 910-node cluster---and that scales perfectly up to 3 billion gigabytes!---he'll need a week to get the sorting done. Let's compare this to the cost of a brute-force key search for a 56-bit key. The DES Cracker _ten years ago_ was built for under $250000 and was able to search 2^55 DES keys in only 4 days. The same money today would buy twenty COPACOBANA boxes, which together can search 2^55 DES keys in only 9 _hours_. For 150 million dollars we can reduce the COPACOBANA time to _one minute_. (COPACOBANA is built from FPGAs, by the way; at this scale we could easily afford ASICs and achieve even higher speeds.) To summarize: Compared to a standard brute-force 56-bit key-search machine, Rich has spent just as much money on _tapes_, plus even more money on a massive sorting cluster, and still needs TEN THOUSAND TIMES LONGER to carry out his attack. Rich says that these two are equally difficult attacks, "56 bits"; but he's clearly making _at least_ a 13-bit error, more than 20% of his "56 bits," even if we give him the massive sorting cluster for free. Scaling up to larger attacks makes the error even more obvious. Sorting n small pieces of data needs time proportional to n^(1/2) on the optimal two-dimensional mesh of size n---enough time for the same mesh to carry out n^(3/2) small parallel computations. (In principle three-dimensional machines could reduce square root to cube root, but the third dimension is limited by power input and by heat output.) This scaling has become increasingly obvious to people working on serious computations: * Over the years RAM access has become slower and slower and slower relative to computation, an unavoidable consequence of chips becoming larger and larger. The speed ratio scales as the square root of the chip size. * Access to storage on parallel machines has become slower and slower and slower relative to computation, an unavoidable consequence of machines becoming larger and larger. The speed ratio scales as the square root of the machine size. The same error that leads Rich to disregard factors of more than ten thousand in a "2^56" attack will also lead to factors of more than a billion in a "2^128" attack, and more than 2^60 in a "2^256" attack. I will readily agree that careful evaluation of attack costs isn't needed when we're talking about a 40-bit collision attack on a 512-bit hash. But if someone claims that the security level has been reduced 6%, from 512 bits to 480 bits, then we obviously can't tolerate the sort of sloppiness that leads to exponent errors of more than 20%. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago From hash-forum@nist.gov Fri Nov 7 18:12:10 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA82C4so001006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Nov 2008 18:12:06 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA82BQEX003694; Fri, 7 Nov 2008 21:11:29 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA82AHT4004198; Fri, 7 Nov 2008 21:10:17 -0500 Date: Fri, 7 Nov 2008 21:10:17 -0500 Message-Id: <2a9a3e6a0811071810q39baf568gb5b1fee3c21008fd@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Chen Ke-Fei Lin" To: Multiple recipients of list Subject: Will NIST allow minor fixes in the submission packages X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/alternative; boundary="----=_Part_28886_21464103.1226110206239" MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 07 Nov 2008 18:12:06 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 118 ------=_Part_28886_21464103.1226110206239 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I noticed on Bruce Schneier hash blog that Skein is not good programmed. This is Doug Whiting saying: "Whoops, you are right! Sorry about that. I think that my problem was that I needed a full-sized block buffer, so I ended up using cfg for two purposes and forgot that that changed its size. Thanks for catching this. We'll have to change the code (and vectors) to match the spe, which is correct. ..." So - Skein is improper submission!!!?! Does NIST allows changing of code? If NIST allow change of one submission, they have to allow change on all others including broken ??!? Is this wise? Lin ------=_Part_28886_21464103.1226110206239 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I noticed on Bruce Schneier hash blog that Skein is not good programmed.

This is Doug Whiting saying:
"Whoops, you are right! Sorry about that. I think that my problem was that I needed a full-sized block buffer, so I ended up using cfg for two purposes and forgot that that changed its size. Thanks for catching this. We'll have to change the code (and vectors) to match the spe, which is correct. ..."

So - Skein is improper submission!!!?!  
Does NIST allows changing of code?

If NIST allow change of one submission, they have to allow change on all others including broken ??!?

Is this wise?

Lin
------=_Part_28886_21464103.1226110206239-- From hash-forum@nist.gov Fri Nov 7 18:39:22 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA82dHfA005327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Nov 2008 18:39:18 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA82cnOl023175; Fri, 7 Nov 2008 21:38:51 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA82c9d1024922; Fri, 7 Nov 2008 21:38:09 -0500 Date: Fri, 7 Nov 2008 21:38:09 -0500 Message-Id: <6.0.0.22.2.20081107213412.01c75bb0@email.nist.gov> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Shu-jen Chang To: Multiple recipients of list Subject: Re: Will NIST allow minor fixes in the submission packages X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: text/plain; charset="us-ascii"; format=flowed Mime-Version: 1.0 References: <2a9a3e6a0811071810q39baf568gb5b1fee3c21008fd@mail.gmail.com> In-Reply-To: <2a9a3e6a0811071810q39baf568gb5b1fee3c21008fd@mail.gmail.co m> X-To: hash-forum@nist.gov X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 X-Sender: sjchang@email.nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 07 Nov 2008 18:39:19 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 119 I'm sorry that we can't accept any changes after the submission deadline. Shu-jen At 09:10 PM 11/7/2008, you wrote: >I noticed on Bruce Schneier hash blog that Skein is not good programmed. > >This is Doug Whiting saying: >"Whoops, you are right! Sorry about that. I think that my problem was that >I needed a full-sized block buffer, so I ended up using cfg for two >purposes and forgot that that changed its size. Thanks for catching this. >We'll have to change the code (and vectors) to match the spe, which is >correct. ..." > >So - Skein is improper submission!!!?! >Does NIST allows changing of code? > >If NIST allow change of one submission, they have to allow change on all >others including broken ??!? > >Is this wise? > >Lin From hash-forum@nist.gov Fri Nov 7 20:41:45 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA84fdrR019484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Nov 2008 20:41:41 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA84f1qp026360; Fri, 7 Nov 2008 23:41:03 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA84ddXP027868; Fri, 7 Nov 2008 23:39:39 -0500 Date: Fri, 7 Nov 2008 23:39:39 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Doug Whiting To: Multiple recipients of list Subject: RE: Will NIST allow minor fixes in the submission packages X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" In-Reply-To: <6.0.0.22.2.20081107213412.01c75bb0@email.nist.gov> References: <2a9a3e6a0811071810q39baf568gb5b1fee3c21008fd@mail.gmail.com>,<6.0.0.22.2.20081107213412.01c75bb0@email.nist.gov> X-To: "hash-forum@nist.gov" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 07 Nov 2008 20:41:41 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 120 I don't understand. Are you saying that, because some papers have typos in them, or, in Skein's case, because the C code has a minor bug (one line) that makes it not conform to the Skein specification in all cases, that a submission will be rejected? Or you are saying that what NIST posts will have the typos and will not correct them on the NIST site? The latter sounds reasonable -- you have a lot to manage. The former seems quite harsh and would probably eliminate almost all the contestants -- I've seen emails so far on this list from perhaps half a dozen entrants with typos of various sorts. Has anyone here ever written a technical paper without a typo? We're not talking about changing an algorithm to avoid a break. We're talking about fixing minor typos and bugs. Please clarify what you mean here. Thanks. ________________________________________ From: hash-forum@nist.gov [hash-forum@nist.gov] On Behalf Of Shu-jen Chang [shu-jen.chang@nist.gov] Sent: Friday, November 07, 2008 6:38 PM To: Multiple recipients of list Subject: Re: Will NIST allow minor fixes in the submission packages I'm sorry that we can't accept any changes after the submission deadline. Shu-jen At 09:10 PM 11/7/2008, you wrote: >I noticed on Bruce Schneier hash blog that Skein is not good programmed. > >This is Doug Whiting saying: >"Whoops, you are right! Sorry about that. I think that my problem was that >I needed a full-sized block buffer, so I ended up using cfg for two >purposes and forgot that that changed its size. Thanks for catching this. >We'll have to change the code (and vectors) to match the spe, which is >correct. ..." > >So - Skein is improper submission!!!?! >Does NIST allows changing of code? > >If NIST allow change of one submission, they have to allow change on all >others including broken ??!? > >Is this wise? > >Lin This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information which is protected from disclosure. Any unauthorized review, use, disclosure or distribution by any means is prohibited. If you are not the intended recipient, please contact the sender by reply email or at (408) 399-3500 and destroy all copies of the original message. From hash-forum@nist.gov Fri Nov 7 20:55:16 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA84tBxd020908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Nov 2008 20:55:12 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA84sbuU002145; Fri, 7 Nov 2008 23:54:42 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA84sIQA023294; Fri, 7 Nov 2008 23:54:18 -0500 Date: Fri, 7 Nov 2008 23:54:18 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Sean O'Neil" To: Multiple recipients of list Subject: Re: Will NIST allow minor fixes in the submission packages X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: <2a9a3e6a0811071810q39baf568gb5b1fee3c21008fd@mail.gmail.com>,<6.0.0.22.2.20081107213412.01c75bb0@email.nist.gov> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 07 Nov 2008 20:55:12 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 121 On 8 Nov 2008, at 05:39, Doug Whiting wrote: > Has anyone here ever written a technical paper without a typo? > We're not talking about changing an algorithm to avoid a break. > We're talking about fixing minor typos and bugs. I must disagree with this protest. A few small typos in the specification is one thing. It does not make a submission incomplete or improper. But a bug in the reference implementation that the entire team had a full year to implement and debug is a serious problem. NIST was very clear about accepting only mature submissions, not some buggy last minute patches. I agree with NIST policy on this one. Out of 64 submissions there must be plenty of good "complete and proper" mature and debugged ones to choose from. If the team could not even implement their own algorithm correctly, how can the whole world trust their design for decades to come??? Best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. From hash-forum@nist.gov Fri Nov 7 21:22:36 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA85MUlb025472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Nov 2008 21:22:31 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA85LnJr020703; Sat, 8 Nov 2008 00:21:52 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA85LaZD009902; Sat, 8 Nov 2008 00:21:36 -0500 Date: Sat, 8 Nov 2008 00:21:36 -0500 Message-Id: <9418DB6C0B9D434190E54A78E931C3D10850ED1D@XCH-NW-7V1.nw.nos.boeing.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Bugbee, Larry" To: Multiple recipients of list Subject: RE: Will NIST allow minor fixes in the submission packages X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit X-To: References: <2a9a3e6a0811071810q39baf568gb5b1fee3c21008fd@mail.gmail.com>,<6.0.0.22.2.20081107213412.01c75bb0@email.nist.gov> In-Reply-To: Content-Type: text/plain; charset="US-ASCII" MIME-Version: 1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 07 Nov 2008 21:22:31 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 122 I hope the purpose of this exercise to find several good algorithms for use by the community at large, including myself, a non-submitter. ..rather than a contest between submitters for fewest typos first try. Then there is fairness. A lot of work went into the original submissions and it is unfair to allow late changes to displace otherwise good work. Interesting dilemma, but I must come back to the original intent. We are looking for good algorithms. I say post what was submitted, as submitted. Allow errata to be submitted and posted alongside. Let the community decide the severity/significance of the errata. If considered major, as judged by the community of submitters, one vote each, the algorithm does not advance. When done, I hope we not only get a new SHA3 standard, but also a nice family of credible alternatives. It would be sad to see an excellent algorithm disqualified because one line, not central to the algorithm per se, could not be fixed. Larry -----Original Message----- From: Doug Whiting [mailto:DWhiting@hifn.com] Sent: Friday, November 07, 2008 8:40 PM To: Multiple recipients of list Subject: RE: Will NIST allow minor fixes in the submission packages I don't understand. Are you saying that, because some papers have typos in them, or, in Skein's case, because the C code has a minor bug (one line) that makes it not conform to the Skein specification in all cases, that a submission will be rejected? Or you are saying that what NIST posts will have the typos and will not correct them on the NIST site? The latter sounds reasonable -- you have a lot to manage. The former seems quite harsh and would probably eliminate almost all the contestants -- I've seen emails so far on this list from perhaps half a dozen entrants with typos of various sorts. Has anyone here ever written a technical paper without a typo? We're not talking about changing an algorithm to avoid a break. We're talking about fixing minor typos and bugs. Please clarify what you mean here. Thanks. ________________________________________ From: hash-forum@nist.gov [hash-forum@nist.gov] On Behalf Of Shu-jen Chang [shu-jen.chang@nist.gov] Sent: Friday, November 07, 2008 6:38 PM To: Multiple recipients of list Subject: Re: Will NIST allow minor fixes in the submission packages I'm sorry that we can't accept any changes after the submission deadline. Shu-jen At 09:10 PM 11/7/2008, you wrote: >I noticed on Bruce Schneier hash blog that Skein is not good programmed. > >This is Doug Whiting saying: >"Whoops, you are right! Sorry about that. I think that my problem was >that I needed a full-sized block buffer, so I ended up using cfg for >two purposes and forgot that that changed its size. Thanks for catching this. >We'll have to change the code (and vectors) to match the spe, which is >correct. ..." > >So - Skein is improper submission!!!?! >Does NIST allows changing of code? > >If NIST allow change of one submission, they have to allow change on >all others including broken ??!? > >Is this wise? > >Lin This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information which is protected from disclosure. Any unauthorized review, use, disclosure or distribution by any means is prohibited. If you are not the intended recipient, please contact the sender by reply email or at (408) 399-3500 and destroy all copies of the original message. From hash-forum@nist.gov Fri Nov 7 21:24:04 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA85NvkR025774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Nov 2008 21:23:58 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA85LnJh020703; Sat, 8 Nov 2008 00:21:50 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA85LMlH009108; Sat, 8 Nov 2008 00:21:22 -0500 Date: Sat, 8 Nov 2008 00:21:22 -0500 Message-Id: <49151E97.90108@csail.mit.edu> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Eran Tromer To: Multiple recipients of list Subject: Re: Evaluating attack costs X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 In-Reply-To: <98EBB542F32B9D4CBB1EC5FE1D93D45B16448F6A03@ES02SNLNT.srn.sandia.gov> References: <98EBB542F32B9D4CBB1EC5FE1D93D45B16448F69C9@ES02SNLNT.srn.sandia.gov>,<20081107142208.11725.qmail@cr.yp.to> <98EBB542F32B9D4CBB1EC5FE1D93D45B16448F6A03@ES02SNLNT.srn.sandia.gov> MIME-Version: 1.0 X-CC: hash-forum@nist.gov X-To: "Schroeppel, Richard" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 07 Nov 2008 21:23:58 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 123 Hi Richard, On 2008-11-07 19:34, Schroeppel, Richard wrote: > Add, or multiply? I find that a helpful way to think about computation vs. memory costs is in terms of marginal cost per unit throughput, measured in units of equipment_cost*time per instance of the cryptanalytic problem. Here, "equipment" includes both computation and storage (as well as cryptanalytic paraphernalia such as wires, optroelectrics, slotted sheets of papers and bicycles chains). You can use the dollar value for concreteness, or ignore the constants for asymptotics. So different kinds of equipment are treated additively; but you multiply their cost by the duration during which they're dedicated to a particular instance. A box of tapes that are dedicated to breaking a specific key is accounted for just like a CPU dedicated to breaking that key. Under this definition, an algorithm that performs T ops *in serial* using memory M will indeed cost T*M. As Dan pointed out, if you've bought so many tapes, why are you accessing them using one measly CPU, when you could use a much faster parallel implementation to reduce time without significantly increasing the total equipment cost? Surely the cost measure should reflect the difference between these two implementations, yet the T+M measure doesn't. Caveats: the naive equipment*time measure neglects non-equipment resources (power, maintenance) and nonrecurring costs (R&D, precomputation). Also, marginal cost doesn't work well when you consider one-time challenges. And time by itself is still relevant, since a $1M-and-1year break is worse than a $1K-and-1000years break (they have the same cost per throughput, but in the latter case maybe everybody's still safe for a millennium). Eran From hash-forum@nist.gov Fri Nov 7 21:49:42 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA85naep029148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Nov 2008 21:49:37 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA85n0Kv002271; Sat, 8 Nov 2008 00:49:01 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA85mUka027902; Sat, 8 Nov 2008 00:48:31 -0500 Date: Sat, 8 Nov 2008 00:48:30 -0500 Message-Id: <9FA16888AD1BF64ABCE6C2532CCEB98A05F06B14@xmb-sjc-219.amer.cisco.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Krishna Sankar (ksankar)" To: Multiple recipients of list Subject: RE: Will NIST allow minor fixes in the submission packages X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit X-To: References: <2a9a3e6a0811071810q39baf568gb5b1fee3c21008fd@mail.gmail.com>,<6.0.0.22.2.20081107213412.01c75bb0@email.nist.gov> <9418DB6C0B9D434190E54A78E931C3D10850ED1D@XCH-NW-7V1.nw.nos.boeing.com> In-reply-to: <9418DB6C0B9D434190E54A78E931C3D10850ED1D@XCH-NW-7V1.nw.nos.boeing.com> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 07 Nov 2008 21:49:37 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 124 Agree with Larry completely. This is an exercise in developing a few good algorithms in a participative way. If an algorithm can be made better either by the community or by the submitters, we should allow that, within reason, of course. We should have flexible rules not brittle ones. But in the end, I think, usually a few will rise to the top and we will know if something is a serious error or a typo anyway. Cheers & have a nice weekend |-----Original Message----- |From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of |Bugbee, Larry |Sent: Friday, November 07, 2008 9:22 PM |To: Multiple recipients of list |Subject: RE: Will NIST allow minor fixes in the submission packages | | |I hope the purpose of this exercise to find several good algorithms for |use by the community at large, including myself, a non-submitter. |..rather than a contest between submitters for fewest typos first try. | | |Then there is fairness. A lot of work went into the original |submissions and it is unfair to allow late changes to displace otherwise |good work. | |Interesting dilemma, but I must come back to the original intent. We |are looking for good algorithms. I say post what was submitted, as |submitted. Allow errata to be submitted and posted alongside. Let the |community decide the severity/significance of the errata. If considered |major, as judged by the community of submitters, one vote each, the |algorithm does not advance. | |When done, I hope we not only get a new SHA3 standard, but also a nice |family of credible alternatives. It would be sad to see an excellent |algorithm disqualified because one line, not central to the algorithm |per se, could not be fixed. | |Larry | | |-----Original Message----- |From: Doug Whiting [mailto:DWhiting@hifn.com] |Sent: Friday, November 07, 2008 8:40 PM |To: Multiple recipients of list |Subject: RE: Will NIST allow minor fixes in the submission packages | | |I don't understand. Are you saying that, because some papers have typos |in them, or, in Skein's case, because the C code has a minor bug (one |line) that makes it not conform to the Skein specification in all cases, |that a submission will be rejected? Or you are saying that what NIST |posts will have the typos and will not correct them on the NIST site? |The latter sounds reasonable -- you have a lot to manage. The former |seems quite harsh and would probably eliminate almost all the |contestants -- I've seen emails so far on this list from perhaps half a |dozen entrants with typos of various sorts. Has anyone here ever written |a technical paper without a typo? We're not talking about changing an |algorithm to avoid a break. We're talking about fixing minor typos and |bugs. | |Please clarify what you mean here. Thanks. | |________________________________________ |From: hash-forum@nist.gov [hash-forum@nist.gov] On Behalf Of Shu-jen |Chang [shu-jen.chang@nist.gov] |Sent: Friday, November 07, 2008 6:38 PM |To: Multiple recipients of list |Subject: Re: Will NIST allow minor fixes in the submission packages | |I'm sorry that we can't accept any changes after the submission |deadline. | |Shu-jen | | |At 09:10 PM 11/7/2008, you wrote: |>I noticed on Bruce Schneier hash blog that Skein is not good |programmed. |> |>This is Doug Whiting saying: |>"Whoops, you are right! Sorry about that. I think that my problem was |>that I needed a full-sized block buffer, so I ended up using cfg for |>two purposes and forgot that that changed its size. Thanks for catching |this. |>We'll have to change the code (and vectors) to match the spe, which is |>correct. ..." |> |>So - Skein is improper submission!!!?! |>Does NIST allows changing of code? |> |>If NIST allow change of one submission, they have to allow change on |>all others including broken ??!? |> |>Is this wise? |> |>Lin | |This email message is for the sole use of the intended recipient(s) and |may contain confidential and privileged information which is protected |from disclosure. Any unauthorized review, use, disclosure or |distribution by any means is prohibited. If you are not the intended |recipient, please contact the sender by reply email or at (408) 399-3500 |and destroy all copies of the original message. | | | | From hash-forum@nist.gov Fri Nov 7 22:59:20 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA86xEMw005450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Nov 2008 22:59:15 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA86wWAF012111; Sat, 8 Nov 2008 01:58:34 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA86vcH0027380; Sat, 8 Nov 2008 01:57:38 -0500 Date: Sat, 8 Nov 2008 01:57:38 -0500 Message-Id: <49153849.4020806@mit.edu> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Ronald L. Rivest" To: Multiple recipients of list Subject: Re: Will NIST allow minor fixes in the submission packages X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: References: <2a9a3e6a0811071810q39baf568gb5b1fee3c21008fd@mail.gmail.com>, <6.0.0.22.2.20081107213412.01c75bb0@email.nist.gov> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 07 Nov 2008 22:59:15 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 125 This is an interesting (but perhaps not unexpected) situation. My initial reaction is to treat it like voting (since I think about voting a lot these days); "what is the voter's intent?" http://blog.wired.com/photos/uncategorized/2007/08/15/punch_card_and_magnifying_glass_3.gif This approach would say that if there is overwhelming evidence as to what the submitter's intent is, then that should be considered as the submission, even if there are minor inconsistencies with that interpretation in the submission package, including in the code. However, one could also make the argument that in this contest code is "special", in that it defines an algorithm in a precise way that mere English might not do in a submission, and that it also allows application of the proposed algorithm for evaluation purposes. This suggests that maybe "the code should rule" in cases where the written english spec and the code disagree. Of course, none of us submitters can be absolutely sure that our code is free from bugs. With MD6, we did a "clean room" re-implementation of the algorithm from the English specs, and compared input/output pairs for the two independently developed code bases; this revealed a couple of minor issues that had to be fixed. We're quite confident that our code is consistent with our specification now. A related issue is the submission or publication of of security proofs after the submission deadline. We can have the same issue here with "moving targets". This may be less problematic, since the hash function itself is not changing, only the proferred evidence for its security. I suspect the only workable approach will be along the following lines: -- NIST does not accept changes after the submission deadline (with 64 submissions, it would be a potential administrative nightmare to track versions...) -- NIST encourages each submitter to host a web site regarding its submission, where corrections, revisions, proposed improvements, additional argumentation or evaluation can be posted. NIST posts a link to each such web site. -- However, NIST does not commit in any way to paying attention to any such posted material during Round 1, as it determines which algorithms to promote to Round 2. However, submitters with only minor corrections to make to their submission can make it clear on their web site what changes they intend to make in a Round 2 submission. NIST *may* pay attention this material, but is not committed to do so. Other reviewers of the submitted algorithms might want to check the relevant web sites for such proposed minor corrections... But that's just my two cents; NIST will have to puzzle this out... (Or maybe one can say they already have, since they have a clear set of rules posted for this competition, with minor changes allowed at the beginning of Round 2; hopefully the best algorithms will survive Round 1 in spite of minor issues with the submitted material...) Cheers, Ron On 11/7/2008 11:39 PM, Doug Whiting wrote: > I don't understand. Are you saying that, because some papers have typos in them, or, in Skein's case, because the C code has a minor bug (one line) that makes it not conform to the Skein specification in all cases, that a submission will be rejected? Or you are saying that what NIST posts will have the typos and will not correct them on the NIST site? The latter sounds reasonable -- you have a lot to manage. The former seems quite harsh and would probably eliminate almost all the contestants -- I've seen emails so far on this list from perhaps half a dozen entrants with typos of various sorts. Has anyone here ever written a technical paper without a typo? We're not talking about changing an algorithm to avoid a break. We're talking about fixing minor typos and bugs. > > Please clarify what you mean here. Thanks. > > ________________________________________ > From: hash-forum@nist.gov [hash-forum@nist.gov] On Behalf Of Shu-jen Chang [shu-jen.chang@nist.gov] > Sent: Friday, November 07, 2008 6:38 PM > To: Multiple recipients of list > Subject: Re: Will NIST allow minor fixes in the submission packages > > I'm sorry that we can't accept any changes after the submission deadline. > > Shu-jen > > > At 09:10 PM 11/7/2008, you wrote: >> I noticed on Bruce Schneier hash blog that Skein is not good programmed. >> >> This is Doug Whiting saying: >> "Whoops, you are right! Sorry about that. I think that my problem was that >> I needed a full-sized block buffer, so I ended up using cfg for two >> purposes and forgot that that changed its size. Thanks for catching this. >> We'll have to change the code (and vectors) to match the spe, which is >> correct. ..." >> >> So - Skein is improper submission!!!?! >> Does NIST allows changing of code? >> >> If NIST allow change of one submission, they have to allow change on all >> others including broken ??!? >> >> Is this wise? >> >> Lin > > This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information which is protected from disclosure. Any unauthorized review, use, disclosure or distribution by any means is prohibited. If you are not the intended recipient, please contact the sender by reply email or at (408) 399-3500 and destroy all copies of the original message. > > > > > -- Ronald L. Rivest Room 32-G692, Stata Center, MIT, Cambridge MA 02139 Tel 617-253-5880, Email From hash-forum@nist.gov Sat Nov 8 04:36:10 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA8Ca3XW026605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 8 Nov 2008 04:36:06 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA8CZSjE003815; Sat, 8 Nov 2008 07:35:33 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA8CYJI7009279; Sat, 8 Nov 2008 07:34:19 -0500 Date: Sat, 8 Nov 2008 07:34:19 -0500 Message-Id: <4915872D.1000809@ellipticsemi.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Tom St Denis To: Multiple recipients of list Subject: Re: Evaluating attack costs X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: <98EBB542F32B9D4CBB1EC5FE1D93D45B16448F6A03@ES02SNLNT.srn.sandia.gov> References: <98EBB542F32B9D4CBB1EC5FE1D93D45B16448F69C9@ES02SNLNT.srn.sandia.gov>,<20081107142208.11725.qmail@cr.yp.to> <98EBB542F32B9D4CBB1EC5FE1D93D45B16448F6A03@ES02SNLNT.srn.sandia.gov> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 08 Nov 2008 04:36:06 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 126 Schroeppel, Richard wrote: > We can distinguish various kinds of memory -- tape, > RAM, smart RAM, associative, etc. Sometimes they can be > substituted, sometimes not. They will have different costs > and access properties: 1GB of tape is cheaper than 1GB of > RAM, and may or may not be just as useful in a particular > situation. Should we count them as equally costly, so as to > focus on the math? > Not that my opinion matters, but ... I'm going to have to agree with DJ on this issue. Memory requirements cannot be just pushed away under some fuzzy notion of it being free. Look at the GNFS for example. A 1024-bit factoring takes roughly 2^86 time (though it's never been done so ...), but more importantly 2^44 memory. In the estimates for walltime people may be lazy and just extrapolate from earlier factorings and just linearly multiply through, e.g. if a 2^43 time factoring is performed in 6 months, then this would be 2^43 * 6 months. However, they ignore things like getting 2^44 bits of memory tightly coupled to a node doing matrix reductions is a lot harder than say 2^22 bits. So not only is the amount of memory important, but also it's usage inside the algorithm as well. If you can't isolate small pockets and work on them as oppose to random access to the entire array, it won't scale linearly with time. I think it's rightly justified to multiply through since any attack on an n-bit hash that requires an a-bit table and a b-time complexity where a*b > 2^n [or 2^n/2 depending on the attack] is not a real attack (you could just build as many circuits as you use memory on any hash). It doesn't mean we dismiss the analysis, but it's not a full break, it's more on the league with say a break of "15 of 25 rounds" type thing. My $0.02 CAD contribution :-) Tom From hash-forum@nist.gov Sat Nov 8 09:21:39 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA8HLYVP024509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 8 Nov 2008 09:21:35 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA8HKRO5029329; Sat, 8 Nov 2008 12:21:03 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA8HHpjZ023620; Sat, 8 Nov 2008 12:17:51 -0500 Date: Sat, 8 Nov 2008 12:17:51 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Paul Hoffman To: Multiple recipients of list Subject: Re: Will NIST allow minor fixes in the submission packages X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: text/plain; charset="us-ascii" X-To: hash-forum@nist.gov References: <2a9a3e6a0811071810q39baf568gb5b1fee3c21008fd@mail.gmail.com>, <6.0.0.22.2.20081107213412.01c75bb0@email.nist.gov> <49153849.4020806@mit.edu> In-Reply-To: <49153849.4020806@mit.edu> Mime-Version: 1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 08 Nov 2008 09:21:35 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 127 At 1:57 AM -0500 11/8/08, Ronald L. Rivest wrote: >Of course, none of us submitters can be absolutely sure >that our code is free from bugs. With MD6, we did a "clean >room" re-implementation of the algorithm from the English >specs, and compared input/output pairs for the two independently >developed code bases; this revealed a couple of minor issues >that had to be fixed. I would be surprised if that were not true for over 50% of the submissions. >We're quite confident that our code is >consistent with our specification now. And so was Doug, et. al. > -- NIST does not accept changes after the submission deadline > (with 64 submissions, it would be a potential administrative > nightmare to track versions...) > -- NIST encourages each submitter to host a web site regarding > its submission, where corrections, revisions, proposed > improvements, additional argumentation or evaluation can be > posted. NIST posts a link to each such web site. > -- However, NIST does not commit in any way to paying attention to > any such posted material during Round 1, as it determines > which algorithms to promote to Round 2. However, submitters > with only minor corrections to make to their submission can > make it clear on their web site what changes they intend > to make in a Round 2 submission. NIST *may* pay attention > this material, but is not committed to do so. Other reviewers of > the submitted algorithms might want to check the relevant > web sites for such proposed minor corrections... > >But that's just my two cents I'll make that four cents. Good suggestion. >NIST will have to puzzle this out... NIST has a lot to puzzle out, particularly with respect to what attacks to consider and which to reject out of hand. --Paul Hoffman, Director --VPN Consortium From hash-forum@nist.gov Sat Nov 8 13:26:24 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA8LQJYl014962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 8 Nov 2008 13:26:20 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA8LPW1I006849; Sat, 8 Nov 2008 16:25:35 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA8LMBOI027976; Sat, 8 Nov 2008 16:22:12 -0500 Date: Sat, 8 Nov 2008 16:22:11 -0500 Message-Id: <20081108210918.46B0550E5@alexander.concentric.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Colin B To: Multiple recipients of list Subject: RE: Will NIST allow minor fixes in the submission packages X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 In-Reply-To: <2a9a3e6a0811071810q39baf568gb5b1fee3c21008fd@mail.gmail.com>,<6.0.0.22.2.20081107213412.01c75bb0@email.nist.gov> X-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 08 Nov 2008 13:26:20 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 128 If this is a collaborative effort to develop good algorithms, then we all need to see all the submissions regardless of whether or not they are complete and proper, but if that had been stated at the beginning you wouldn't have seen anything from me. If, on the other hand, this is truly a competition then the rules must hold. I'll let you know which side of the fence I'm on when I see whether or not my submission is accepted. Regards, Colin. ---- wrote: > > > I hope the purpose of this exercise to find several good algorithms for > use by the community at large, including myself, a non-submitter. > ..rather than a contest between submitters for fewest typos first try. > > > Then there is fairness. A lot of work went into the original > submissions and it is unfair to allow late changes to displace otherwise > good work. > > Interesting dilemma, but I must come back to the original intent. We > are looking for good algorithms. I say post what was submitted, as > submitted. Allow errata to be submitted and posted alongside. Let the > community decide the severity/significance of the errata. If considered > major, as judged by the community of submitters, one vote each, the > algorithm does not advance. > > When done, I hope we not only get a new SHA3 standard, but also a nice > family of credible alternatives. It would be sad to see an excellent > algorithm disqualified because one line, not central to the algorithm > per se, could not be fixed. > > Larry > > > -----Original Message----- > From: Doug Whiting [mailto:DWhiting@hifn.com] > Sent: Friday, November 07, 2008 8:40 PM > To: Multiple recipients of list > Subject: RE: Will NIST allow minor fixes in the submission packages > > > I don't understand. Are you saying that, because some papers have typos > in them, or, in Skein's case, because the C code has a minor bug (one > line) that makes it not conform to the Skein specification in all cases, > that a submission will be rejected? Or you are saying that what NIST > posts will have the typos and will not correct them on the NIST site? > The latter sounds reasonable -- you have a lot to manage. The former > seems quite harsh and would probably eliminate almost all the > contestants -- I've seen emails so far on this list from perhaps half a > dozen entrants with typos of various sorts. Has anyone here ever written > a technical paper without a typo? We're not talking about changing an > algorithm to avoid a break. We're talking about fixing minor typos and > bugs. > > Please clarify what you mean here. Thanks. > > ________________________________________ > From: hash-forum@nist.gov [hash-forum@nist.gov] On Behalf Of Shu-jen > Chang [shu-jen.chang@nist.gov] > Sent: Friday, November 07, 2008 6:38 PM > To: Multiple recipients of list > Subject: Re: Will NIST allow minor fixes in the submission packages > > I'm sorry that we can't accept any changes after the submission > deadline. > > Shu-jen > > > At 09:10 PM 11/7/2008, you wrote: > >I noticed on Bruce Schneier hash blog that Skein is not good > programmed. > > > >This is Doug Whiting saying: > >"Whoops, you are right! Sorry about that. I think that my problem was > >that I needed a full-sized block buffer, so I ended up using cfg for > >two purposes and forgot that that changed its size. Thanks for catching > this. > >We'll have to change the code (and vectors) to match the spe, which is > >correct. ..." > > > >So - Skein is improper submission!!!?! > >Does NIST allows changing of code? > > > >If NIST allow change of one submission, they have to allow change on > >all others including broken ??!? > > > >Is this wise? > > > >Lin > > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information which is protected > from disclosure. Any unauthorized review, use, disclosure or > distribution by any means is prohibited. If you are not the intended > recipient, please contact the sender by reply email or at (408) 399-3500 > and destroy all copies of the original message. > > > > > > From hash-forum@nist.gov Sat Nov 8 14:32:59 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA8MWs7M020701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 8 Nov 2008 14:32:55 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA8MWLuj003616; Sat, 8 Nov 2008 17:32:23 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA8MWBHd029163; Sat, 8 Nov 2008 17:32:11 -0500 Date: Sat, 8 Nov 2008 17:32:11 -0500 Message-Id: <49161185.1070403@gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Brian L. Matthews" To: Multiple recipients of list Subject: Re: Will NIST allow minor fixes in the submission packages X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8; format=flowed In-Reply-To: <20081108210918.46B0550E5@alexander.concentric.com> References: <20081108210918.46B0550E5@alexander.concentric.com> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 08 Nov 2008 14:32:55 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 129 I'm just an interested observer, so I don't know how much my opinion counts, but I'd hate to see an otherwise good algorithm dropped from consideration because of typos in the paper or code. Brian From hash-forum@nist.gov Sat Nov 8 14:33:00 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA8MWtOM020706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 8 Nov 2008 14:32:56 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA8MWLut003616; Sat, 8 Nov 2008 17:32:26 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA8MVbXG027357; Sat, 8 Nov 2008 17:31:37 -0500 Date: Sat, 8 Nov 2008 17:31:37 -0500 Message-Id: <491610E5.5000000@cs.ucsb.edu> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Cetin Kaya Koc To: Multiple recipients of list Subject: RE: Will NIST allow minor fixes in the submission packages X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 08 Nov 2008 14:32:56 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 130 NIST may have the resources but definitely not the time (perhaps it has neither) to check "provably" that each submission has the correct implementation, i.e., the code truly matches the English description. There are a lot of ambiguities one has to worry about in the definitions of many algorithms. Therefore, I suggest prudence, rather than a formula-based approach in determining which submissions are worthy of considering. -- __________________________________________________________ Cetin Kaya Koc * http://cs.ucsb.edu/~koc US Cell: +1 805 403 4191 ******* TR Cell: +90 532 405 6417 From hash-forum@nist.gov Sat Nov 8 15:13:33 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA8NDSLE025172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 8 Nov 2008 15:13:29 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA8NCqOL017513; Sat, 8 Nov 2008 18:12:54 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA8NCVGG008275; Sat, 8 Nov 2008 18:12:31 -0500 Date: Sat, 8 Nov 2008 18:12:31 -0500 Message-Id: <39c307da0811081458m440e173cve90b3a0f1b4e0db5@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Souradyuti Paul" To: Multiple recipients of list Subject: Re: Will NIST allow minor fixes in the submission packages X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <2a9a3e6a0811071810q39baf568gb5b1fee3c21008fd@mail.gmail.com> <6.0.0.22.2.20081107213412.01c75bb0@email.nist.gov> <49153849.4020806@mit.edu> Content-Type: multipart/alternative; boundary="----=_Part_50552_9216479.1226185131691" MIME-Version: 1.0 In-Reply-To: X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 08 Nov 2008 15:13:29 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 131 ------=_Part_50552_9216479.1226185131691 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline *"NIST has a lot to puzzle out, particularly with respect to what attacks to consider and which to reject out of hand."* It is foreseeable that there would be many attacks with complexities too large -- however, lower than brute force -- to be implemented in machines. The situation would be worse when the details of the attack are fuzzy or the underlying assumptions are disputed. In such cases, the attacker may choose to construct a "reasonable" scaled-down version of the hash algorithm and then argue by attacking the reduced version with practical complexities predicted by her original attack. However, I admit that it may be sometimes difficult to reasonably scale down the original algorithm. Have a nice weekend. -Soura ***************************************** Souradyuti Paul Computer Security Division, NIST, Tel No. +1-301-975-3195 Fax No.+1-301-975-8670 Web: http://www.esat.kuleuven.be/~psourady ****************************************** On Sat, Nov 8, 2008 at 12:17 PM, Paul Hoffman wrote: > > At 1:57 AM -0500 11/8/08, Ronald L. Rivest wrote: > >Of course, none of us submitters can be absolutely sure > >that our code is free from bugs. With MD6, we did a "clean > >room" re-implementation of the algorithm from the English > >specs, and compared input/output pairs for the two independently > >developed code bases; this revealed a couple of minor issues > >that had to be fixed. > > I would be surprised if that were not true for over 50% of the submissions. > > >We're quite confident that our code is > >consistent with our specification now. > > And so was Doug, et. al. > > > -- NIST does not accept changes after the submission deadline > > (with 64 submissions, it would be a potential administrative > > nightmare to track versions...) > > -- NIST encourages each submitter to host a web site regarding > > its submission, where corrections, revisions, proposed > > improvements, additional argumentation or evaluation can be > > posted. NIST posts a link to each such web site. > > -- However, NIST does not commit in any way to paying attention to > > any such posted material during Round 1, as it determines > > which algorithms to promote to Round 2. However, submitters > > with only minor corrections to make to their submission can > > make it clear on their web site what changes they intend > > to make in a Round 2 submission. NIST *may* pay attention > > this material, but is not committed to do so. Other reviewers of > > the submitted algorithms might want to check the relevant > > web sites for such proposed minor corrections... > > > >But that's just my two cents > > I'll make that four cents. Good suggestion. > > >NIST will have to puzzle this out... > > NIST has a lot to puzzle out, particularly with respect to what attacks to > consider and which to reject out of hand. > > > --Paul Hoffman, Director > --VPN Consortium > > -- ------=_Part_50552_9216479.1226185131691 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
"NIST has a lot to puzzle out, particularly with respect to what attacks to consider and which to reject out of hand."
 
It is foreseeable that there would be many attacks with complexities too large -- however, lower than brute force --  to be implemented in machines. The situation would be worse when the details of the attack are fuzzy or the underlying assumptions are disputed. In such cases, the attacker may choose to construct a "reasonable" scaled-down version of the hash algorithm and then argue by attacking the reduced version with practical complexities predicted by her original attack. However, I admit that it may be sometimes difficult to reasonably scale down the original algorithm.
 
Have a nice weekend.
-Soura     

*****************************************
Souradyuti Paul

Computer Security Division,
NIST,  
Tel No. +1-301-975-3195
Fax No.+1-301-975-8670

Web: http://www.esat.kuleuven.be/~psourady
******************************************

On Sat, Nov 8, 2008 at 12:17 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

At 1:57 AM -0500 11/8/08, Ronald L. Rivest wrote:
>Of course, none of us submitters can be absolutely sure
>that our code is free from bugs.  With MD6, we did a "clean
>room" re-implementation of the algorithm from the English
>specs, and compared input/output pairs for the two independently
>developed code bases; this revealed a couple of minor issues
>that had to be fixed.

I would be surprised if that were not true for over 50% of the submissions.

>We're quite confident that our code is
>consistent with our specification now.

And so was Doug, et. al.

>  -- NIST does not accept changes after the submission deadline
>     (with 64 submissions, it would be a potential administrative
>     nightmare to track versions...)
>  -- NIST encourages each submitter to host a web site regarding
>     its submission, where corrections, revisions, proposed
>     improvements, additional argumentation or evaluation can be
>     posted.  NIST posts a link to each such web site.
>  -- However, NIST does not commit in any way to paying attention to
>     any such posted material during Round 1, as it determines
>     which algorithms to promote to Round 2.  However, submitters
>     with only minor corrections to make to their submission can
>     make it clear on their web site what changes they intend
>     to make in a Round 2 submission.  NIST *may* pay attention
>     this material, but is not committed to do so.  Other reviewers of
>     the submitted algorithms might want to check the relevant
>     web sites for such proposed minor corrections...
>
>But that's just my two cents

I'll make that four cents. Good suggestion.

>NIST will have to puzzle this out...

NIST has a lot to puzzle out, particularly with respect to what attacks to consider and which to reject out of hand.


--Paul Hoffman, Director
--VPN Consortium




--
------=_Part_50552_9216479.1226185131691-- From hash-forum@nist.gov Sat Nov 8 16:48:45 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mA90mdL6001548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 8 Nov 2008 16:48:40 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mA90m54J007887; Sat, 8 Nov 2008 19:48:06 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mA90kmoD023857; Sat, 8 Nov 2008 19:46:48 -0500 Date: Sat, 8 Nov 2008 19:46:48 -0500 Message-Id: <20081108191042.66184.qmail@cr.yp.to> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "D. J. Bernstein" To: Multiple recipients of list Subject: Re: Evaluating attack costs X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas In-Reply-To: <98EBB542F32B9D4CBB1EC5FE1D93D45B16448F6A03@ES02SNLNT.srn.sandia.gov> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 08 Nov 2008 16:48:40 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 132 Compared to a standard 56-bit key-searching FPGA cluster, Rich's "56 bit" attack machine costs just as much (even if we give him a massive computer cluster for free!) and is TEN THOUSAND TIMES SLOWER. In other words, the "56 bit" evaluation was wrong by _at least_ 13 bits. It's important to understand that this type of error becomes even more severe for larger attacks: storage-access costs grow as the square root of the machine size. This isn't just a real-world observation but also a theorem from the VLSI literature. See, e.g., Richard P. Brent and H. T. Kung, "The area-time complexity of binary multiplication," Journal of the ACM 28 (1981), 521-534, Theorem 3.3: "... any n-bit multiplication chip must satisfy (A/A_0)(T/T_0)^(2 alpha) >= n^(1+alpha), for all alpha in (0,1)." There are similar lower bounds for the (A,T) curves achievable for sorting, routing, etc., and upper bounds that aren't very far away. Rich says he was ignoring "some log factors," namely one log for the data size and one log for comparison-based sorting. What makes Rich lose a factor of TEN THOUSAND on a more expensive attack machine is not these log factors (the encryption also has to pay the data-size log, and the sorting machines that I cited use smarter sorting algorithms that reduce the second log to a small constant), but the fundamental square-root slowdown caused by accessing huge arrays of storage. Rich says that his "issue" was to break 112-bit security, and that his attack machine does this. I agree---the machine is simultaneously much faster and much less expensive than a 112-bit brute-force search. The problem is that we often have to make tighter comparisons. When someone claims a "480 bit" attack on a 512-bit hash, does he have a real attack, or has he been deluded by sloppy evaluation of attack costs? As for Rich's question "Add, or multiply?": In the attacker's hat, I can choose a wide range of area-time tradeoffs for parallel preimage search. The resulting (A,T) curve has the product AT ("price-performance ratio") being very close to a constant number of dollar-seconds, and stretches from tiny A up to larger A's than I could possibly afford. Consequently, if I compute the price-performance ratio for a new "attack," and see that it's _worse_ than the price-performance ratio for parallel preimage search, then I immediately know that the attack is useless, no matter what its specific (A,T) might be. This is one of the basic reasons that price-performance ratio, the product of A and T, is a useful concept. Similarly, if a new collision "attack" has a worse price-performance ratio than parallel collision search, then the attack is useless. Of course, it's possible that an attack with a _better_ AT is still useless for me, because its minimum A is larger than I can afford, or its minimum T is longer than I can wait; price-performance ratio is a good initial filter, but sometimes the entire (A,T) curve is important. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago From hash-forum@nist.gov Tue Nov 11 09:29:17 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mABHTC3q010588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 Nov 2008 09:29:13 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mABGMYVx011789; Tue, 11 Nov 2008 11:23:41 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mABGJqeM023189; Tue, 11 Nov 2008 11:19:52 -0500 Date: Tue, 11 Nov 2008 11:19:52 -0500 Message-Id: <6.0.0.22.2.20081111105637.01d1b350@email.nist.gov> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Shu-jen Chang To: Multiple recipients of list Subject: RE: Will NIST allow minor fixes in the submission packages X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: text/plain; charset="us-ascii"; format=flowed Mime-Version: 1.0 References: <2a9a3e6a0811071810q39baf568gb5b1fee3c21008fd@mail.gmail.com> <6.0.0.22.2.20081107213412.01c75bb0@email.nist.gov> In-Reply-To: X-To: hash-forum@nist.gov X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 X-Sender: sjchang@email.nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: Delayed for 01:04:54 by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 11 Nov 2008 09:29:13 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 133 At 11:39 PM 11/7/2008, you wrote: >I don't understand. Are you saying that, because some papers have typos in >them, or, in Skein's case, because the C code has a minor bug (one line) >that makes it not conform to the Skein specification in all cases, that a >submission will be rejected? Or you are saying that what NIST posts will >have the typos and will not correct them on the NIST site? The latter >sounds reasonable -- you have a lot to manage. The former seems quite >harsh and would probably eliminate almost all the contestants -- I've seen >emails so far on this list from perhaps half a dozen entrants with typos >of various sorts. Has anyone here ever written a technical paper without a >typo? We're not talking about changing an algorithm to avoid a break. >We're talking about fixing minor typos and bugs. > >Please clarify what you mean here. Thanks. We are working on a solution regarding correction handling, and will post our decision soon. Thanks, Shu-jen >________________________________________ >From: hash-forum@nist.gov [hash-forum@nist.gov] On Behalf Of Shu-jen Chang >[shu-jen.chang@nist.gov] >Sent: Friday, November 07, 2008 6:38 PM >To: Multiple recipients of list >Subject: Re: Will NIST allow minor fixes in the submission packages > >I'm sorry that we can't accept any changes after the submission deadline. > >Shu-jen > > >At 09:10 PM 11/7/2008, you wrote: > >I noticed on Bruce Schneier hash blog that Skein is not good programmed. > > > >This is Doug Whiting saying: > >"Whoops, you are right! Sorry about that. I think that my problem was that > >I needed a full-sized block buffer, so I ended up using cfg for two > >purposes and forgot that that changed its size. Thanks for catching this. > >We'll have to change the code (and vectors) to match the spe, which is > >correct. ..." > > > >So - Skein is improper submission!!!?! > >Does NIST allows changing of code? > > > >If NIST allow change of one submission, they have to allow change on all > >others including broken ??!? > > > >Is this wise? > > > >Lin > >This email message is for the sole use of the intended recipient(s) and >may contain confidential and privileged information which is protected >from disclosure. Any unauthorized review, use, disclosure or distribution >by any means is prohibited. If you are not the intended recipient, please >contact the sender by reply email or at (408) 399-3500 and destroy all >copies of the original message. From hash-forum@nist.gov Tue Nov 11 12:57:21 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mABKvFf5002027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 Nov 2008 12:57:16 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mABKsUr9016086; Tue, 11 Nov 2008 15:56:33 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mABKpkT7011395; Tue, 11 Nov 2008 15:51:46 -0500 Date: Tue, 11 Nov 2008 15:51:46 -0500 Message-Id: <20081111205527.29548.qmail@cr.yp.to> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "D. J. Bernstein" To: Multiple recipients of list Subject: Re: Will NIST allow minor fixes in the submission packages X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas In-Reply-To: <2a9a3e6a0811071810q39baf568gb5b1fee3c21008fd@mail.gmail.com> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 11 Nov 2008 12:57:16 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 134 It seems to me that, in the end, cryptographic users will be imposing security requirements and performance requirements on SHA-3 software and hardware. For example, it's a disaster if attackers can find preimages for the SHA-3 software that users have actually deployed. What if there's a "SHA-3 specification" defining something different from the SHA-3 function that's actually deployed? What if it's much harder to find preimages in that function? Do we have any less of a disaster? Of course not! Another situation: If there's a "SHA-3 specification" defining a weak function while the actual SHA-3 code is strong, then obviously the specification should be fixed, but there hasn't been a disaster. The users remain safe and can continue using the same code. Similarly, if there's a difference between the speed of a specified "SHA-3" and the speed achieved by the actual SHA-3 software, then what matters to cryptographic users is the speed of the actual software. Imagine stripped-down SHA-3 submissions consisting of just software, just like the original MD5 code. We'd have no trouble accurately and confidently measuring the speed that SHA-3 users would actually see (which reminds me: http://bench.cr.yp.to/results-hash.html already has measurements on more than 50 machines for the first SHA-3 candidates sent to eBASH). We'd have no trouble verifying cryptanalytic results such as the EnRUPT-256 collision. Of course, cryptanalysts would sometimes need some extra work to figure out what the code is doing, but again they'd be able to call on the computer for assistance. Imagine, by contrast, stripped-down SHA-3 submissions consisting of just "specifications" written in semi-formal English, often with extremely unclear semantics and certainly with no standardized method of having computers understand the specifications. We'd have no easy way to run benchmarks or to verify cryptanalytic results. Obviously we'd try to fix this by writing code, but would the code match what the "specifications" say? We'd run test vectors through code from different people, but what if everyone is misinterpreting the English definition in the same way? NIST required functions to be defined twice, first as code and second as a "specification." My own submission (CubeHash) has a one-page spec and a 99-line implementation, so it wasn't a huge hassle for me to sit down and do a reimplementation and manually check all sorts of intermediate values; but of course most functions are more complicated, and I'm not surprised to hear that many people submitted specifications that don't actually match their code. (I'm not saying that simple hash functions are best; honestly, I don't know.) I think it would be crazy for NIST to reject submissions on the basis of discrepancies (more precisely, discrepancies detected in the last two months of 2008) between specifications and implementations. Anyone could have avoided this risk by submitting a copy of the reference C code as a specification; but it seems that almost everyone took the opportunity to provide a potentially helpful _different_ definition of the _same_ function, and I'd hate to see people punished for this extra effort. At the same time, I would like a clear statement from NIST that the reference implementation is the ultimate definition of the hash function under consideration. If there are discrepancies between the code and the other documentation, it's not nice to have to throw away cryptanalytic work that started from the other documentation, but it's much worse to have to throw away cryptanalytic work that started from the code _and_ performance evaluation that started from the code _and_ reimplementation effort that started from the code _and_ tests that started from the code and all the other effort supported by having a definition that can be easily understood by a computer. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago P.S. Note to nitpickers: Yes, NIST required specifications to be in English, but NIST also required the reference implementation to be in English! Here's the rule: "It is required that the submission packages be in English. This requirement includes the cover sheet, algorithm specification and supporting documentation, source code, and intellectual property information." Obviously this rule can't stop a valid reference implementation from being a valid specification. From hash-forum@nist.gov Thu Nov 13 11:35:20 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mADJZCSj019753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Nov 2008 11:35:13 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mADITAiV001263; Thu, 13 Nov 2008 13:29:13 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mADIRKIk018829; Thu, 13 Nov 2008 13:27:21 -0500 Date: Thu, 13 Nov 2008 13:27:20 -0500 Message-Id: <1226600347.5832.22.camel@calypso> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Christophe De =?ISO-8859-1?Q?Canni=E8re?= To: Multiple recipients of list Subject: NKS2D-224 and the cost of brute force X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Evolution 2.12.1 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-hGcni/IFfYWOdHjOgTXM" X-Cc: Geoffrey Michael Park X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: Delayed for 01:05:13 by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 13 Nov 2008 11:35:14 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 135 --=-hGcni/IFfYWOdHjOgTXM Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Funnily enough, if you're lucky to check messages in the right order, it turns out that the cost of brute force is not all that high: ---- 2008-11-13, Christophe De Cannière, COSIC, Katholieke Universiteit Leuven m1 = 10 NKS2D-224(m1) = 98dbcc87f24e14918ce6acc24340f01b871a5c8ff58f749c6bc15251 m2 = d0 NKS2D-224(m2) = 98dbcc87f24e14918ce6acc24340f01b871a5c8ff58f749c6bc15251 m1 and m2 collide! ---- Note: in order to avoid errors when compiling the reference code with gcc, you might want to apply the patch attached to this message. Cheers, Christophe Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm --=-hGcni/IFfYWOdHjOgTXM Content-Disposition: attachment; filename=nks2dcoll.c Content-Type: text/x-csrc; name=nks2dcoll.c; charset=UTF-8 Content-Transfer-Encoding: 8bit /* * Copyright (c) 2008 Sebastiaan Indesteege * * * Permission to use, copy, modify, and distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ /* * Example collision pair for NKS2D-224. This file should be linked * with the reference implementation of NKS2D. * * 2008-11-13, Christophe De Cannière, COSIC, Katholieke Universiteit Leuven */ #include #include #include #include "SHA3API.h" #define HASHBITLEN 224 #define LEN 8 static const uint8_t m1[] = {0x10}; static const uint8_t m2[] = {0xD0}; uint8_t h1[HASHBITLEN/8]; uint8_t h2[HASHBITLEN/8]; void printbytes(uint8_t const *p, int n) { int i; for (i=0; i!=n; ++i) printf("%02x", p[i]); printf("\n"); } int main() { int i; printf("Example collision pair for NKS2D-224\n"); printf("2008-11-13, Christophe De Cannière, COSIC, Katholieke Universiteit Leuven\n\n"); /* Hash first mesage */ if (Hash(HASHBITLEN, m1, LEN, h1) != SUCCESS) errx(1, "Hashing failed!"); printf("m1 = "); printbytes(m1, LEN/8); printf("NKS2D-224(m1) = "); printbytes(h1, HASHBITLEN/8); printf("\n"); /* Hash second mesage */ if (Hash(HASHBITLEN, m2, LEN, h2) != SUCCESS) errx(1, "Hashing failed!"); printf("m2 = "); printbytes(m2, LEN/8); printf("NKS2D-224(m2) = "); printbytes(h2, HASHBITLEN/8); printf("\n"); /* Verify collision */ for (i=0; i!=HASHBITLEN/8; ++i) { if (h1[i] != h2[i]) { printf("ERROR: m1 and m2 do NOT collide\n"); return 1; } } printf("m1 and m2 collide!\n\n"); return 0; } --=-hGcni/IFfYWOdHjOgTXM Content-Disposition: attachment; filename=gcc-compatible.diff Content-Type: text/x-patch; name=gcc-compatible.diff; charset=UTF-8 Content-Transfer-Encoding: 7bit Common subdirectories: Reference Implementation/CellAutoDemo and gcc-compatible/CellAutoDemo diff -u Reference Implementation/NKS2DCAhash.c gcc-compatible/NKS2DCAhash.c --- Reference Implementation/NKS2DCAhash.c 2008-10-10 22:24:42.000000000 +0200 +++ gcc-compatible/NKS2DCAhash.c 2008-11-13 18:39:54.000000000 +0100 @@ -14,9 +14,10 @@ #include #include #include -#include #include "NKS2DCAhash.h" +#define FALSE 0 + /** * @brief Returns value of a single bit at position x,y in a * bit array w bits wide by h rows diff -u Reference Implementation/NKS2DCAhash.h gcc-compatible/NKS2DCAhash.h --- Reference Implementation/NKS2DCAhash.h 2008-10-04 21:30:44.000000000 +0200 +++ gcc-compatible/NKS2DCAhash.h 2008-11-13 18:39:54.000000000 +0100 @@ -8,9 +8,11 @@ //------------------------------------------------------------------- typedef int BOOL; -typedef __int64 DataLength; +typedef int64_t DataLength; typedef unsigned char BitSequence; +typedef enum { SUCCESS = 0, FAIL = 1, BAD_HASHLEN = 2 } HashReturn; + #define ALL_NEIGHBORS 0x300000 #define RECT_NEIGHBORS 0x100000 #define DIAG_NEIGHBORS 0x200000 diff -u Reference Implementation/SHA3API.c gcc-compatible/SHA3API.c --- Reference Implementation/SHA3API.c 2008-10-06 17:09:42.000000000 +0200 +++ gcc-compatible/SHA3API.c 2008-11-13 18:39:54.000000000 +0100 @@ -9,7 +9,6 @@ #include #include "SHA3API.h" -#include "NKS2DCAhash.h" #ifdef _DEBUG #define DBG_Print printf @@ -361,4 +360,4 @@ } return HashEx(hashbitlen, data, databitlen, hashval, nRules, 1, rules, overlap); -} \ No newline at end of file +} diff -u Reference Implementation/SHA3API.h gcc-compatible/SHA3API.h --- Reference Implementation/SHA3API.h 2008-10-11 16:25:28.000000000 +0200 +++ gcc-compatible/SHA3API.h 2008-11-13 18:39:54.000000000 +0100 @@ -9,11 +9,7 @@ * @date 2008 */ -typedef int BOOL; -typedef __int64 DataLength; -typedef unsigned char BitSequence; - -typedef enum { SUCCESS = 0, FAIL = 1, BAD_HASHLEN = 2 } HashReturn; +#include "NKS2DCAhash.h" /** * @brief Hash state structure. Holds all intermediate state during hash generation. --=-hGcni/IFfYWOdHjOgTXM-- From hash-forum@nist.gov Thu Nov 13 12:40:13 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mADKe65Y027157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Nov 2008 12:40:07 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mADKdC5a006896; Thu, 13 Nov 2008 15:39:17 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mADKbkqI017767; Thu, 13 Nov 2008 15:37:46 -0500 Date: Thu, 13 Nov 2008 15:37:46 -0500 Message-Id: <20081113202305.1b2a3200@gamma> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Brandon Enright To: Multiple recipients of list Subject: Re: NKS2D-224 and the cost of brute force X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Mime-Version: 1.0 X-Mailer: Claws Mail 3.6.1 (GTK+ 2.12.11; x86_64-pc-linux-gnu) References: <1226600347.5832.22.camel@calypso> In-Reply-To: <1226600347.5832.22.camel@calypso> X-Cc: christophe.decanniere@esat.kuleuven.be, bmenrigh@ucsd.edu X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 13 Nov 2008 12:40:07 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 136 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 13 Nov 2008 13:27:20 -0500 Christophe De Cannière wrote: > Funnily enough, if you're lucky to check messages in the right order, > it turns out that the cost of brute force is not all that high: > > ---- > 2008-11-13, Christophe De Cannière, COSIC, Katholieke Universiteit > Leuven > > m1 = 10 > NKS2D-224(m1) = > 98dbcc87f24e14918ce6acc24340f01b871a5c8ff58f749c6bc15251 > > m2 = d0 > NKS2D-224(m2) = > 98dbcc87f24e14918ce6acc24340f01b871a5c8ff58f749c6bc15251 > > m1 and m2 collide! > ---- > > Note: in order to avoid errors when compiling the reference code with > gcc, you might want to apply the patch attached to this message. > > Cheers, > Christophe > Ah you beat me too it. I was thinking about this last night and came up with the same attack. The trouble with cellular automata is that from one generation to the next, some cells (bits) don't matter. Take a simplified example like Conway's "life" automata: [fixed-width font required] Starting with: ===================== | | | | | | ===================== | | X | X | X | | ===================== | | X | | X | | ===================== | | X | X | X | | ===================== | | | | | | ===================== Or: ===================== | | | | | | ===================== | | X | X | X | | ===================== | | X | X | X | | ===================== | | X | X | X | | ===================== | | | | | | ===================== Both evolve to: ===================== | | | X | | | ===================== | | X | | X | | ===================== | X | | | | X | ===================== | | X | | X | | ===================== | | | X | | | ===================== Now, NKS2D is a more complicated automata with a more complicated rule but the fundamental problem is the same -- some bits just don't matter in the long run. A good hash needs a single bit to effect every other bit of state after some number of rounds but cellular automata tend to be designed in a way such that a single cell only effects neighboring cells. Now I'm not going to say that cellular automata hashes are impossible but I can't think of any hacked up rule that would overcome the cell/bit localization and isolation problem. Brandon -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkcjK8ACgkQqaGPzAsl94Lw2gCgkTbZ791ABBxWvARjqAjNMydl kLEAoIwy1DQBsHp8LA0qS2o4zs6NydA5 =KHL8 -----END PGP SIGNATURE----- From hash-forum@nist.gov Thu Nov 13 18:32:34 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAE2WSXo002129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Nov 2008 18:32:29 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAE2Vet7029925; Thu, 13 Nov 2008 21:31:45 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAE2UMvp004962; Thu, 13 Nov 2008 21:30:22 -0500 Date: Thu, 13 Nov 2008 21:30:22 -0500 Message-Id: <51590d340811131817g40c12422mbd912ea1a161ba31@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "geoffrey park" To: Multiple recipients of list Subject: Re: NKS2D-224 and the cost of brute force X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <1226600347.5832.22.camel@calypso> <20081113202305.1b2a3200@gamma> Content-Type: multipart/alternative; boundary="----=_Part_43896_4578526.1226629033439" MIME-Version: 1.0 In-Reply-To: <20081113202305.1b2a3200@gamma> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 13 Nov 2008 18:32:29 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 137 ------=_Part_43896_4578526.1226629033439 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Oops! Looks like the configuration I used for 224 bit is way too weak. Goo= d work Cristophe! I was aware that cellular automata, or at least the totalizing ones I'm using are inherently lossy, i.e. different patterns that add to same total are possible. For the 512 bit configuration I attempted to fix this by using three different rules to generate patterns from the same input. The separate streams are XORed at the Finalize stage. Note also that some rules are way more lossy than others. Conway's Game of Life, for example, often collapses to blank from even very complex starting patterns. For fun you can try different rules, data overlap, or multiple streams. To make it even easier to find collisions NKS2D can be configured all the way down to a 16 bit hash. Just check out the HashEx and InitEx functions. -Geoff Park On Thu, Nov 13, 2008 at 3:37 PM, Brandon Enright wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Thu, 13 Nov 2008 13:27:20 -0500 > Christophe De Canni=E8re wrote: > > > Funnily enough, if you're lucky to check messages in the right order, > > it turns out that the cost of brute force is not all that high: > > > > ---- > > 2008-11-13, Christophe De Canni=E8re, COSIC, Katholieke Universiteit > > Leuven > > > > m1 =3D 10 > > NKS2D-224(m1) =3D > > 98dbcc87f24e14918ce6acc24340f01b871a5c8ff58f749c6bc15251 > > > > m2 =3D d0 > > NKS2D-224(m2) =3D > > 98dbcc87f24e14918ce6acc24340f01b871a5c8ff58f749c6bc15251 > > > > m1 and m2 collide! > > ---- > > > > Note: in order to avoid errors when compiling the reference code with > > gcc, you might want to apply the patch attached to this message. > > > > Cheers, > > Christophe > > > > Ah you beat me too it. I was thinking about this last night and came > up with the same attack. > > The trouble with cellular automata is that from one generation to the > next, some cells (bits) don't matter. Take a simplified example like > Conway's "life" automata: > > [fixed-width font required] > > Starting with: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | | | | | | > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | | X | X | X | | > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | | X | | X | | > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | | X | X | X | | > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | | | | | | > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Or: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | | | | | | > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | | X | X | X | | > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | | X | X | X | | > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | | X | X | X | | > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | | | | | | > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Both evolve to: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | | | X | | | > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | | X | | X | | > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | X | | | | X | > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | | X | | X | | > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | | | X | | | > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > Now, NKS2D is a more complicated automata with a more complicated rule > but the fundamental problem is the same -- some bits just don't > matter in the long run. A good hash needs a single bit to effect every > other bit of state after some number of rounds but cellular automata > tend to be designed in a way such that a single cell only effects > neighboring cells. > > Now I'm not going to say that cellular automata hashes are impossible > but I can't think of any hacked up rule that would overcome the > cell/bit localization and isolation problem. > > Brandon > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (GNU/Linux) > > iEYEARECAAYFAkkcjK8ACgkQqaGPzAsl94Lw2gCgkTbZ791ABBxWvARjqAjNMydl > kLEAoIwy1DQBsHp8LA0qS2o4zs6NydA5 > =3DKHL8 > -----END PGP SIGNATURE----- > > > ------=_Part_43896_4578526.1226629033439 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
 
Oops!  Looks like the configuration I used for 224 bit is way too= weak. Good work Cristophe!
 
I was aware that cellular automata, or at least the totalizing ones I&= #39;m using are inherently lossy,
i.e. different patterns that add to same total are possible.
 
For the 512 bit configuration I attempted to fix this by using three d= ifferent rules to generate patterns from the same input. The separate strea= ms are XORed at the Finalize stage.
Note also that some rules are way more lossy than others. Conway's= Game of Life, for example, often collapses to blank from even very complex= starting patterns.
 
For fun you can try different rules, data overlap, or multiple streams= To make it even easier to find collisions NKS2D can be configured all the= way down to a 16 bit hash. Just check out the HashEx and InitEx funct= ions.
 
 -Geoff Park
 

 
On Thu, Nov 13, 2008 at 3:37 PM, Brandon Enright= <bmenrigh@ucsd.e= du> wrote:

-----BEGIN PGP SIGNED MESSAG= E-----
Hash: SHA1

On Thu, 13 Nov 2008 13:27:20 -0500
Christophe = De Canni=E8re <christophe.decanniere@esat.kuleuven.be> wrote:

> Funnily = enough, if you're lucky to check messages in the right order,
> it turns out that the cost of brute force is not all that high:
>= ;
> ----
> 2008-11-13, Christophe De Canni=E8re, COSIC, Katholi= eke Universiteit
> Leuven
>
> m1 =3D 10
> NKS2D-224= (m1) =3D
> 98dbcc87f24e14918ce6acc24340f01b871a5c8ff58f749c6bc15251
>
&g= t; m2 =3D d0
> NKS2D-224(m2) =3D
> 98dbcc87f24e14918ce6acc24340= f01b871a5c8ff58f749c6bc15251
>
> m1 and m2 collide!
> ---= -
>
> Note: in order to avoid errors when compiling the reference co= de with
> gcc, you might want to apply the patch attached to this mes= sage.
>
> Cheers,
> Christophe
>

Ah you beat me too it.  I was thinking about this last night and came<= br>up with the same attack.

The trouble with cellular automata is th= at from one generation to the
next, some cells (bits) don't matter. =  Take a simplified example like
Conway's "life" automata:

[fixed-width font required]<= br>
Starting with:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
|   |   |   |   |   |
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
|   | = X | X | X |   |
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
|   | X |   | X |   |
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
|   | X | X | X |   |
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
|   | &nb= sp; |   |   |   |
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

Or:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
|   |   |   |   | =   |
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
|   | X | X | X |   |
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
|   | X | X | X |   |
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
|   | X | X | X= |   |
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
|   |   |   |   |   |
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Both evolve to:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
| &n= bsp; |   | X |   |   |
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
|   | X |   | X |   |
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
| X | &n= bsp; |   |   | X |
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
|   | X |   | X |   |
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
|   |   | X |   |   |
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


Now, NKS2D is a more complicat= ed automata with a more complicated rule
but the fundamental problem is = the same  -- some bits just don't
matter in the long run. A goo= d hash needs a single bit to effect every
other bit of state after some number of rounds but cellular automata
ten= d to be designed in a way such that a single cell only effects
neighbori= ng cells.

Now I'm not going to say that cellular automata hashes= are impossible
but I can't think of any hacked up rule that would overcome the
cell= /bit localization and isolation problem.

Brandon

-----BEGIN P= GP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFA= kkcjK8ACgkQqaGPzAsl94Lw2gCgkTbZ791ABBxWvARjqAjNMydl
kLEAoIwy1DQBsHp8LA0qS2o4zs6NydA5
=3DKHL8
-----END PGP SIGNATURE-----<= br>


------=_Part_43896_4578526.1226629033439-- From hash-forum@nist.gov Fri Nov 14 00:20:05 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAE8Jxrn028526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Nov 2008 00:20:01 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAE8JKkD026824; Fri, 14 Nov 2008 03:19:22 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAE8HtQx031643; Fri, 14 Nov 2008 03:17:55 -0500 Date: Fri, 14 Nov 2008 03:17:55 -0500 Message-Id: <20081114081544.33241308@moray> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Brandon Enright To: Multiple recipients of list Subject: Re: NKS2D-224 and the cost of brute force X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Mime-Version: 1.0 X-Mailer: Claws Mail 3.6.1 (GTK+ 2.12.11; i686-pc-linux-gnu) References: <1226600347.5832.22.camel@calypso> <20081113202305.1b2a3200@gamma> <51590d340811131817g40c12422mbd912ea1a161ba31@mail.gmail.com> In-Reply-To: <51590d340811131817g40c12422mbd912ea1a161ba31@mail.gmail.com> X-Cc: geoffrey.park@gmail.com, bmenrigh@ucsd.edu X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 14 Nov 2008 00:20:01 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 138 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 13 Nov 2008 21:30:22 -0500 or thereabouts "geoffrey park" wrote: > Oops! Looks like the configuration I used for 224 bit is way too > weak. Good work Cristophe! > > I was aware that cellular automata, or at least the totalizing ones > I'm using are inherently lossy, > i.e. different patterns that add to same total are possible. > > For the 512 bit configuration I attempted to fix this by using three > different rules to generate patterns from the same input. The separate > streams are XORed at the Finalize stage. > Note also that some rules are way more lossy than others. Conway's > Game of Life, for example, often collapses to blank from even very > complex starting patterns. > > For fun you can try different rules, data overlap, or multiple > streams. To make it even easier to find collisions NKS2D can be > configured all the way down to a 16 bit hash. Just check out the > HashEx and InitEx functions. > > -Geoff Park > "Lossy" bit patterns can be found for NKS2D-512 too: Example collision pair for NKS2D-512 2008-11-13, Christophe De Cannière, COSIC, Katholieke Universiteit Leuven 2008-11-14, Brandon Enright, UC San Diego m1 = 1f560d6f NKS2D-512(m1) = 84c46a3b7a82c1a061784b546cad4f936f3d2ebd931c2048a888383a0f3f7baa13ababc86e92ca5c58dcbda4a3d60c9f2e82469d517322c7b1e81b4ad8045cb1 m2 = 1f560d6d NKS2D-512(m2) = 84c46a3b7a82c1a061784b546cad4f936f3d2ebd931c2048a888383a0f3f7baa13ababc86e92ca5c58dcbda4a3d60c9f2e82469d517322c7b1e81b4ad8045cb1 m1 and m2 collide! Brandon -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkdM7sACgkQqaGPzAsl94LmeACeOMAwerPPf+fKoHbaQA+9YtCY aZsAn28zP6xBwRQfB9fIyXisTU6OG7EE =ge6T -----END PGP SIGNATURE----- From hash-forum@nist.gov Fri Nov 14 04:06:18 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAEC6DAw018092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Nov 2008 04:06:14 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAEC5XHj018953; Fri, 14 Nov 2008 07:05:37 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAEC4LLq016174; Fri, 14 Nov 2008 07:04:21 -0500 Date: Fri, 14 Nov 2008 07:04:21 -0500 Message-Id: <61739.200.158.173.51.1226663220.squirrel@webmail.larc.usp.br> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Paulo S. L. M. Barreto" To: Multiple recipients of list Subject: A concrete question on what a successful attack consists of X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain;charset=iso-8859-1 MIME-Version: 1.0 X-To: hash-forum@nist.gov References: <1226600347.5832.22.camel@calypso> <20081113202305.1b2a3200@gamma> <51590d340811131817g40c12422mbd912ea1a161ba31@mail.gmail.com> <20081114081544.33241308@moray> In-Reply-To: <20081114081544.33241308@moray> X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 14 Nov 2008 04:06:15 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 139 I wonder what this forum thinks of the announcement in . Do the 2^122.5 resp. 2^249.7 collision attacks count as breaks of Vortex-256 resp. Vortex-512? Do the other observations, like the O(2^{3n/4}) preimage attack? Cheers, Paulo. From hash-forum@nist.gov Fri Nov 14 06:21:45 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAEELd1g031713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Nov 2008 06:21:41 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAEEKujE009661; Fri, 14 Nov 2008 09:21:03 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAEEJsxO000529; Fri, 14 Nov 2008 09:19:54 -0500 Date: Fri, 14 Nov 2008 09:19:54 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Ivica Nikolic" To: Multiple recipients of list Subject: Cryptanalysis of Edon-R X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/alternative; boundary="----=_Part_8726_21898828.1226671887039" MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 14 Nov 2008 06:21:41 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 140 ------=_Part_8726_21898828.1226671887039 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, we have found a preimage attack on Edon-R with complexity and memory 2^{2n/3} for n-bit digests and various free start attacks (collisions, (second) preimages) with negligible complexity. The attacks are presented in our paper which is available at : http://lj.streamclub.ru/papers/hash/edon-r.pdf Best regards, Ivica Nikolic, Dmitry Khovratovich, Ralf-Philipp Weinmann Laboratory of Algorithms, Cryptography and Security, University of Luxembourg, Luxembourg ------=_Part_8726_21898828.1226671887039 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all,

we have found a preimage attack on Edon-R with complexity and memory 2^{2n/3} for n-bit digests and various free start attacks (collisions, (second) preimages) with negligible complexity.
The attacks are presented in our paper which is available at :
http://lj.streamclub.ru/papers/hash/edon-r.pdf

Best regards,
Ivica Nikolic, Dmitry Khovratovich, Ralf-Philipp Weinmann

Laboratory of Algorithms, Cryptography and Security,
University of Luxembourg,
Luxembourg

------=_Part_8726_21898828.1226671887039-- From hash-forum@nist.gov Fri Nov 14 08:11:08 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAEGB3LO009033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Nov 2008 08:11:04 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAEGAIfG007773; Fri, 14 Nov 2008 11:10:23 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAEG8ucV029835; Fri, 14 Nov 2008 11:08:56 -0500 Date: Fri, 14 Nov 2008 11:08:56 -0500 Message-Id: <20081114160344.64745.qmail@cr.yp.to> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "D. J. Bernstein" To: Multiple recipients of list Subject: 2^185 preimage attack on MD6-256 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas In-Reply-To: <61739.200.158.173.51.1226663220.squirrel@webmail.larc.usp.br> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 14 Nov 2008 08:11:04 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 141 After the recent flood of attacks on hash functions that I had never heard of before this month, I'm pleased to announce that I've found an attack on MD6-256 with time complexity just 2^185. The attack is a "multiple-preimage attack" that simultaneously attacks 2^32 legitimate target signatures and successfully forges at least one signed message by finding a preimage of the underlying hash. Surely there will be more than 2^32 signatures generated using SHA-3, so this is a realistic attack scenario if MD6 is being considered for SHA-3. Recall from Rivest's description of MD6 at Crypto that computing MD6 takes a fraction of a millisecond on a single CPU core. The total time for the attack is under 2^185 milliseconds---I'm talking about actual wall-clock time, not some simplified model. The attack doesn't fit on a single PC, but is easily implemented on a large cluster of a billion current Core 2 Quad PCs. Memory consumption per PC is negligible. Special-purpose hardware will be even less expensive. The attack isn't guaranteed to succeed; a detailed analysis shows that it has only about 1 chance in 100 of succeeding. However, repeating the attack will increase the success probability, and in any event I think we can agree that 1 chance in 100 is already an unacceptable threat for SHA-3 users. Can we please kick MD6 out of the hash competition now? ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago P.S. Preliminary analysis suggests that, astonishingly, Skein and Keccak will both succumb to analogous attacks, and that the attack on Skein will be even faster than the attack on MD6. Who would have imagined that three hash-function designs with such different design principles would share a critical weakness? From hash-forum@nist.gov Fri Nov 14 08:24:42 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAEGObim010289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Nov 2008 08:24:38 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAEGNvt6019140; Fri, 14 Nov 2008 11:24:02 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAEGNaAC027713; Fri, 14 Nov 2008 11:23:36 -0500 Date: Fri, 14 Nov 2008 11:23:36 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Daniel Brown To: Multiple recipients of list Subject: RE: 2^185 preimage attack on MD6-256 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" In-Reply-To: <20081114160344.64745.qmail@cr.yp.to> References: <61739.200.158.173.51.1226663220.squirrel@webmail.larc.usp.br> <20081114160344.64745.qmail@cr.yp.to> X-To: "hash-forum@nist.gov" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 14 Nov 2008 08:24:38 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 142 ha ha > -----Original Message----- > From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of D. > J. Bernstein > Sent: Friday, November 14, 2008 11:09 AM > To: Multiple recipients of list > Subject: 2^185 preimage attack on MD6-256 > > > After the recent flood of attacks on hash functions that I had never > heard of before this month, I'm pleased to announce that I've found an > attack on MD6-256 with time complexity just 2^185. > > The attack is a "multiple-preimage attack" that simultaneously attacks > 2^32 legitimate target signatures and successfully forges at least one > signed message by finding a preimage of the underlying hash. Surely > there will be more than 2^32 signatures generated using SHA-3, so this > is a realistic attack scenario if MD6 is being considered for SHA-3. > > Recall from Rivest's description of MD6 at Crypto that computing MD6 > takes a fraction of a millisecond on a single CPU core. The total time > for the attack is under 2^185 milliseconds---I'm talking about actual > wall-clock time, not some simplified model. The attack doesn't fit on a > single PC, but is easily implemented on a large cluster of a billion > current Core 2 Quad PCs. Memory consumption per PC is negligible. > Special-purpose hardware will be even less expensive. > > The attack isn't guaranteed to succeed; a detailed analysis shows that > it has only about 1 chance in 100 of succeeding. However, repeating the > attack will increase the success probability, and in any event I think > we can agree that 1 chance in 100 is already an unacceptable threat for > SHA-3 users. Can we please kick MD6 out of the hash competition now? > > ---D. J. Bernstein > Research Professor, Computer Science, University of Illinois at > Chicago > > P.S. Preliminary analysis suggests that, astonishingly, Skein and > Keccak > will both succumb to analogous attacks, and that the attack on Skein > will be even faster than the attack on MD6. Who would have imagined > that > three hash-function designs with such different design principles would > share a critical weakness? From hash-forum@nist.gov Fri Nov 14 08:38:58 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAEGcp8c011528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Nov 2008 08:38:52 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAEGcBJC029966; Fri, 14 Nov 2008 11:38:15 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAEGbjoM024735; Fri, 14 Nov 2008 11:37:45 -0500 Date: Fri, 14 Nov 2008 11:37:45 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Alfred Menezes To: Multiple recipients of list Subject: RE: 2^185 preimage attack on MD6-256 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed MIME-Version: 1.0 References: <61739.200.158.173.51.1226663220.squirrel@webmail.larc.usp.br> <20081114160344.64745.qmail@cr.yp.to> In-Reply-To: X-To: Multiple recipients of list X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 14 Nov 2008 08:38:53 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 143 On Fri, 14 Nov 2008, Daniel Brown wrote: > > ha ha > >> -----Original Message----- >> From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of D. >> J. Bernstein >> Sent: Friday, November 14, 2008 11:09 AM >> To: Multiple recipients of list >> Subject: 2^185 preimage attack on MD6-256 >> >> >> After the recent flood of attacks on hash functions that I had never >> heard of before this month, I'm pleased to announce that I've found an >> attack on MD6-256 with time complexity just 2^185. >> >> The attack is a "multiple-preimage attack" that simultaneously attacks >> 2^32 legitimate target signatures and successfully forges at least one >> signed message by finding a preimage of the underlying hash. Surely >> there will be more than 2^32 signatures generated using SHA-3, so this >> is a realistic attack scenario if MD6 is being considered for SHA-3. >> >> Recall from Rivest's description of MD6 at Crypto that computing MD6 >> takes a fraction of a millisecond on a single CPU core. The total time >> for the attack is under 2^185 milliseconds---I'm talking about actual >> wall-clock time, not some simplified model. The attack doesn't fit on a >> single PC, but is easily implemented on a large cluster of a billion >> current Core 2 Quad PCs. Memory consumption per PC is negligible. >> Special-purpose hardware will be even less expensive. >> >> The attack isn't guaranteed to succeed; a detailed analysis shows that >> it has only about 1 chance in 100 of succeeding. However, repeating the >> attack will increase the success probability, and in any event I think >> we can agree that 1 chance in 100 is already an unacceptable threat for >> SHA-3 users. Can we please kick MD6 out of the hash competition now? >> >> ---D. J. Bernstein >> Research Professor, Computer Science, University of Illinois at >> Chicago >> >> P.S. Preliminary analysis suggests that, astonishingly, Skein and >> Keccak >> will both succumb to analogous attacks, and that the attack on Skein >> will be even faster than the attack on MD6. Who would have imagined >> that >> three hash-function designs with such different design principles would >> share a critical weakness? > > > From hash-forum@nist.gov Fri Nov 14 10:30:09 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAEIU1TU023998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Nov 2008 10:30:05 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAEISedh021751; Fri, 14 Nov 2008 13:29:04 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAEIRS80024229; Fri, 14 Nov 2008 13:27:28 -0500 Date: Fri, 14 Nov 2008 13:27:28 -0500 Message-Id: <491dc202.130c420a.03ae.6ebd@mx.google.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Danilo Gligoroski" To: Multiple recipients of list Subject: RE: Cryptanalysis of Edon-R X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Microsoft Office Outlook 12.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0068_01C9468E.61B8A140" MIME-Version: 1.0 In-Reply-To: References: X-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 14 Nov 2008 10:30:05 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 144 This is a multipart message in MIME format. ------=_NextPart_000_0068_01C9468E.61B8A140 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Ivica, I am reading your attack. Nice work (in the part of free start pre-images) but for real pre-image attacks, your attack is still not better than brute force attack. Actually it is much worse. To find second pre-images you need 2^{2n/3} hash computations and 2^{2n/3} memory. So, I have cheaper attack on Edon-R that needs 2^{n-1} hash computations and n bits of memory. Best regards, Danilo Gligoroski P.S. About your observations "we can invert the quasigroup operation Q(x; y) with negligible effort." - As you say - it is indeed simple observation that is already given in the documentation. If you carefully read the documentation in the part where we give attacks on Edon-R with local collisions you will find the notation "left conjugates" and our attacks are with complexity O(1). That means "with negligible effort" you can invert quasigroup operations. From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Ivica Nikolic Sent: Friday, November 14, 2008 3:20 PM To: Multiple recipients of list Subject: Cryptanalysis of Edon-R Hi all, we have found a preimage attack on Edon-R with complexity and memory 2^{2n/3} for n-bit digests and various free start attacks (collisions, (second) preimages) with negligible complexity. The attacks are presented in our paper which is available at : http://lj.streamclub.ru/papers/hash/edon-r.pdf Best regards, Ivica Nikolic, Dmitry Khovratovich, Ralf-Philipp Weinmann Laboratory of Algorithms, Cryptography and Security, University of Luxembourg, Luxembourg ------=_NextPart_000_0068_01C9468E.61B8A140 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ivica,

 

I am reading your attack. Nice work (in the part of free = start pre-images) but for real pre-image attacks,

your attack is still not better than brute force attack. = Actually it is much worse.

To find second pre-images you need 2^{2n/3} hash = computations and 2^{2n/3} memory.

 

So, I have cheaper attack on Edon-R that needs =  2^{n-1}  hash computations and n bits of memory.

 

Best regards,

Danilo Gligoroski

 

P.S. About your = observations “we can invert the = quasigroup operation Q(x; y) with negligible effort.” – As you say – it is indeed simple observation that is already given in the documentation. If you carefully = read the documentation in the part where we give attacks on Edon-R with local collisions you will find the notation “left conjugates” and = our attacks are with complexity O(1). That means “with negligible = effort” you can invert quasigroup operations.

 

 

 

 

 

From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Ivica Nikolic
Sent: Friday, November 14, 2008 3:20 PM
To: Multiple recipients of list
Subject: Cryptanalysis of Edon-R

 

Hi all,

we have found a preimage attack on Edon-R with complexity and memory = 2^{2n/3} for n-bit digests and various free start attacks (collisions, (second) preimages) with negligible complexity.
The attacks are presented in our paper which is available at :
http://lj.streamc= lub.ru/papers/hash/edon-r.pdf

Best regards,
Ivica Nikolic, Dmitry Khovratovich, Ralf-Philipp Weinmann

Laboratory of Algorithms, Cryptography and Security,
University of Luxembourg,
Luxembourg

------=_NextPart_000_0068_01C9468E.61B8A140-- From hash-forum@nist.gov Fri Nov 14 10:43:29 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAEIhNTw025506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Nov 2008 10:43:25 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAEIgU11024713; Fri, 14 Nov 2008 13:42:37 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAEIg3Nq021941; Fri, 14 Nov 2008 13:42:03 -0500 Date: Fri, 14 Nov 2008 13:42:03 -0500 Message-Id: <491DC669.5020101@mit.edu> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Ronald L. Rivest" To: Multiple recipients of list Subject: Re: 2^185 preimage attack on MD6-256 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: <20081114160344.64745.qmail@cr.yp.to> References: <20081114160344.64745.qmail@cr.yp.to> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 14 Nov 2008 10:43:25 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 145 Hi Dan -- Gee, I think challengers should be prepared to demo their attacks, or else be ignored! If you are willing to demo your attack, please be prepared to accept 100 billion MD6 images for the grand challenge! (Caveat: these will be supplied on standard format punch cards.) (Caveat: you have to supply your own computing cluster and power for the attack.) (Caveat: if no ones around when you finish the attack, please turn out the lights when you leave...) Cheers, Ron On 11/14/2008 11:08 AM, D. J. Bernstein wrote: > After the recent flood of attacks on hash functions that I had never > heard of before this month, I'm pleased to announce that I've found an > attack on MD6-256 with time complexity just 2^185. > > The attack is a "multiple-preimage attack" that simultaneously attacks > 2^32 legitimate target signatures and successfully forges at least one > signed message by finding a preimage of the underlying hash. Surely > there will be more than 2^32 signatures generated using SHA-3, so this > is a realistic attack scenario if MD6 is being considered for SHA-3. > > Recall from Rivest's description of MD6 at Crypto that computing MD6 > takes a fraction of a millisecond on a single CPU core. The total time > for the attack is under 2^185 milliseconds---I'm talking about actual > wall-clock time, not some simplified model. The attack doesn't fit on a > single PC, but is easily implemented on a large cluster of a billion > current Core 2 Quad PCs. Memory consumption per PC is negligible. > Special-purpose hardware will be even less expensive. > > The attack isn't guaranteed to succeed; a detailed analysis shows that > it has only about 1 chance in 100 of succeeding. However, repeating the > attack will increase the success probability, and in any event I think > we can agree that 1 chance in 100 is already an unacceptable threat for > SHA-3 users. Can we please kick MD6 out of the hash competition now? > > ---D. J. Bernstein > Research Professor, Computer Science, University of Illinois at Chicago > > P.S. Preliminary analysis suggests that, astonishingly, Skein and Keccak > will both succumb to analogous attacks, and that the attack on Skein > will be even faster than the attack on MD6. Who would have imagined that > three hash-function designs with such different design principles would > share a critical weakness? > > > -- Ronald L. Rivest Room 32-G692, Stata Center, MIT, Cambridge MA 02139 Tel 617-253-5880, Email From hash-forum@nist.gov Fri Nov 14 11:25:19 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAEJP9uo032024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Nov 2008 11:25:11 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAEJODJl025789; Fri, 14 Nov 2008 14:24:17 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAEJNCck007691; Fri, 14 Nov 2008 14:23:13 -0500 Date: Fri, 14 Nov 2008 14:23:12 -0500 Message-Id: <491DCE5D.8020404@nist.gov> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Bill Burr To: Multiple recipients of list Subject: Corrections to SHA-3 Submissions and the Next Steps X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/alternative; boundary="------------010705090106060702030307" MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 14 Nov 2008 11:25:11 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 146 This is a multi-part message in MIME format. --------------010705090106060702030307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks, NIST has received 64 submissions in the SHA-3 competition. We are reviewing them now and expect to post all the accepted SHA-3 submissions by early December 2008. There have been several questions about correcting errors to SHA-3 submissions. NIST does not intend to disqualify submissions for errors that can be reasonably considered to be typos, minor ambiguities, or minor coding errors. However, NIST is concerned about fairness and maintaining an accurate history of the submissions and any corrections made to them. Therefore NIST intends to initially post the submissions as they were received on Oct. 31, and will base our acceptance of the candidate algorithms on the initial submissions. We do plan to allow minor corrections as explained below. These changes will not affect the acceptance of the submissions but may be needed to accurately evaluate the security or performance characteristics of the algorithm. NIST will accept three kinds of corrections to the SHA-3 submissions: * Corrections that fix simple typos or errors to the text or code, or that resolve or clarify ambiguities, but do not constitute technical changes to the submitted algorithm. NIST will refuse to accept changes that seem to be responses to attacks, even if an attack can be blocked by a very simple change, unless there is a convincing argument that the attack is only the result of a typo in the first place. * Changes that correct inconsistencies between the textual definition of the algorithm and the reference code, and/or the optimized code. In this case submitters may resolve the inconsistency in favor of either the code or the text; we presume that they know which states their original intent. If code changes, then test vectors, known answer tests and Monte Carlo tests may also change. * Simple corrections to the reference or optimized code that fix coding bugs. At this stage NIST may reject changes to optimized code that have a large effect on performance, although improved optimized code for different platforms may be considered later in the competition. Again, changes to the code may result in changes to test vectors, known answer and Monte Carlo tests. We are concerned about managing the updating of the submissions and maintaining a history of the changes. NIST asks submitters who wish to submit a copy of the updated specification or code to provide it before Jan 15, 2009, along with a specific change list, explaining what was changed and the reason for the change. Only one such update will be accepted. The corrected specification and/or code will be the "official" version of the submission for the first workshop. Note that NIST will not accept updates inconsistent with the criteria above. Updates received after January 15, 2009 will not be accepted before the workshop. We will consider a second round of corrections a month or two after the first workshop. To ensure that the errata for each algorithm are available to researchers as soon as possible, submitters may choose to maintain a web page for their algorithm. If submitters provide the URL for an errata page to NIST, we will establish pointers from the official SHA-3 website to this supplementary information for each such submission. NIST encourages submitters to post corrected versions of their specifications on their own site as soon as possible so that researchers studying their particular algorithm can obtain the most accurate specification. More than 20 of the submissions have been posted on the Ecrypt "SHA-3 Zoo" page , and several of these have apparently already been broken. We have not yet verified these breaks, and will not consider these attacks in our determination of acceptability. Therefore, we will post all "acceptable" submissions, including those that may already have been broken. However, we believe that in some cases the designers have conceded that their algorithm has been broken. If submitters concede that their algorithm has been broken, they should notify NIST so that this can be noted on the NIST website. Regards, Bill -- William E. Burr Manager, Security Technology Group NIST 100 Bureau Dr., MS 8931 Gaithersburg, MD. 20899 Bldg. 222, Rm B362 Tel: 301-975-2914 Fax: 301-975-8670 --------------010705090106060702030307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Folks,

NIST has received 64 submissions in the SHA-3 competition.  We are reviewing them now and expect to post all the accepted SHA-3 submissions by early December 2008.

There have been several questions about correcting errors to SHA-3 submissions.  NIST does not intend to disqualify submissions for errors that can be reasonably considered to be typos, minor ambiguities, or minor coding errors.  However, NIST is concerned about fairness and maintaining an accurate history of the submissions and any corrections made to them.  Therefore NIST intends to initially post the submissions as they were received on Oct. 31, and will base our acceptance of the candidate algorithms on the initial submissions. 

We do plan to allow minor corrections as explained below.  These changes will not affect the acceptance of the submissions but may be needed to accurately evaluate the security or performance characteristics of the algorithm.

NIST will accept three kinds of corrections to the SHA-3 submissions:
  • Corrections that fix simple typos or errors to the text or code, or that resolve or clarify ambiguities, but do not constitute technical changes to the submitted algorithm.  NIST will refuse to accept changes that seem to be responses to attacks, even if an attack can be blocked by a very simple change, unless there is a convincing argument that the attack is only the result of a typo in the first place.
  • Changes that correct inconsistencies between the textual definition of the algorithm and the reference code, and/or the optimized code.  In this case submitters may resolve the inconsistency in favor of either the code or the text; we presume that they know which states their original intent.  If code changes, then test vectors, known answer tests and Monte Carlo tests may also change.
  • Simple corrections to the reference or optimized code that fix coding bugs.  At this stage NIST may reject changes to optimized code that have a large effect on performance, although improved optimized code for different platforms may be considered later in the competition.  Again, changes to the code may result in changes to test vectors, known answer and Monte Carlo tests.
We are concerned about managing the updating of the submissions and maintaining a history of the changes. NIST asks submitters who wish to submit a copy of the updated specification or code to provide it before Jan 15, 2009, along with a specific change list, explaining what was changed and the reason for the change. Only one such update will be accepted. The corrected specification and/or code will be the "official" version of the submission for the first workshop.

Note that NIST will not accept updates inconsistent with the criteria above. Updates received after January 15, 2009 will not be accepted before the workshop.  We will consider a second round of corrections a month or two after the first workshop.

To ensure that the errata for each algorithm are available to researchers as soon as possible, submitters may choose to maintain a web page for their algorithm.  If submitters provide the URL for an errata page to NIST, we will establish pointers from the official SHA-3 website to this supplementary information for each such submission.  NIST encourages submitters to post corrected versions of their specifications on their own site as soon as possible so that researchers studying their particular algorithm can obtain the most accurate specification.

More than 20 of the submissions have been posted on the Ecrypt "SHA-3 Zoo" page <http://ehash.iaik.tugraz.at/wiki/The_SHA-3_Zoo>, and several of these have apparently already been broken.  We have not yet verified these breaks, and will not consider these attacks in our determination of acceptability. Therefore, we will post all “acceptable” submissions, including those that may already have been broken.   However, we believe that in some cases the designers have conceded that their algorithm has been broken.  If submitters concede that their algorithm has been broken, they should notify NIST so that this can be noted on the NIST website.

Regards,

Bill

-- 
William E. Burr
Manager, Security Technology Group
NIST
100 Bureau Dr., MS 8931
Gaithersburg, MD. 20899
Bldg. 222, Rm B362
Tel: 301-975-2914
Fax: 301-975-8670
--------------010705090106060702030307-- From hash-forum@nist.gov Fri Nov 14 11:25:02 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAEJOvTf031984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Nov 2008 11:24:58 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAEJODJb025789; Fri, 14 Nov 2008 14:24:15 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAEJO0pW009571; Fri, 14 Nov 2008 14:24:00 -0500 Date: Fri, 14 Nov 2008 14:24:00 -0500 Message-Id: <491DCEE5.6060907@larc.usp.br> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Paulo S. L. M. Barreto" To: Multiple recipients of list Subject: Re: 2^185 preimage attack on MD6-256 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 In-Reply-To: <20081114160344.64745.qmail@cr.yp.to> References: <20081114160344.64745.qmail@cr.yp.to> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 14 Nov 2008 11:24:58 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 147 D. J. Bernstein wrote: > After the recent flood of attacks on hash functions that I had never > heard of before this month, I'm pleased to announce that I've found an > attack on MD6-256 with time complexity just 2^185. [snip] > P.S. Preliminary analysis suggests that, astonishingly, Skein and Keccak > will both succumb to analogous attacks, and that the attack on Skein > will be even faster than the attack on MD6. Who would have imagined that > three hash-function designs with such different design principles would > share a critical weakness? That's amazing! Has anybody independently checked Dan's attack? (Sorry for playing the devil's advocate, Dan -- this will only increase confidence that these three candidates are out of the competition, scornful comments notwithstanding) Paulo. From hash-forum@nist.gov Fri Nov 14 12:47:30 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAEKlN24009379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Nov 2008 12:47:25 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAEKkXNq017989; Fri, 14 Nov 2008 15:46:38 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAEKjT4w011891; Fri, 14 Nov 2008 15:45:29 -0500 Date: Fri, 14 Nov 2008 15:45:29 -0500 Message-Id: <491DE090.2020307@mit.edu> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Ronald L. Rivest" To: Multiple recipients of list Subject: Re: Corrections to SHA-3 Submissions and the Next Steps X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=windows-1252; format=flowed In-Reply-To: <491DCE5D.8020404@nist.gov> References: <491DCE5D.8020404@nist.gov> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 14 Nov 2008 12:47:25 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 148 Hi Bill -- This policy seems just about right; thanks. Such a "grace period" for fixing typos should lead to an improved final result, by preventing otherwise excellent submissions from being disqualified... I can certainly sympathize with those who have discovered small typos or errors just after the submission deadline... As mentioned in my earlier email, there is another form of revision that perhaps deserves some thought; this has to do with the arguments for the security of the submission. Even without changing the algorithm, the character of a submission may change due to further developments by submitters and/or by others. The submitter may develop a proof or analysis that covers attacks not discussed (or not handled well) in the original submission, for example. Attacks may be developed by third parties. Some of this is invited and expected. Some of these may merely represent deferred work by the submitters (they didn't write up their security arguments in much detail before the submission deadline). Some represents the sort of clever attacks that is expected, invited, and valuable in this public evaluation process. There is a question, then, as to what portion of such post-deadline security evaluations are part of what NIST expects to evaluate during the first round? All of it? None of it? (I.e. only the material submitted by the deadline?) Only material by third parties? Only material by the submitters? Etc... Probably the best approach is merely to claim that all such material is "potentially relevant", without committing to either considering it or excluding it... But if you had crisper guidance, that might be helpful... Cheers, Ron On 11/14/2008 2:23 PM, Bill Burr wrote: > Folks, > > NIST has received 64 submissions in the SHA-3 competition. We are > reviewing them now and expect to post all the accepted SHA-3 submissions > by early December 2008. > > There have been several questions about correcting errors to SHA-3 > submissions. NIST does not intend to disqualify submissions for errors > that can be reasonably considered to be typos, minor ambiguities, or > minor coding errors. However, NIST is concerned about fairness and > maintaining an accurate history of the submissions and any corrections > made to them. Therefore NIST intends to initially post the submissions > as they were received on Oct. 31, and will base our acceptance of the > candidate algorithms on the initial submissions. > > We do plan to allow minor corrections as explained below. These changes > will not affect the acceptance of the submissions but may be needed to > accurately evaluate the security or performance characteristics of the > algorithm. > > NIST will accept three kinds of corrections to the SHA-3 submissions: > > * Corrections that fix simple typos or errors to the text or code, > or that resolve or clarify ambiguities, but do not constitute > technical changes to the submitted algorithm. NIST will refuse to > accept changes that seem to be responses to attacks, even if an > attack can be blocked by a very simple change, unless there is a > convincing argument that the attack is only the result of a typo > in the first place. > > * Changes that correct inconsistencies between the textual > definition of the algorithm and the reference code, and/or the > optimized code. In this case submitters may resolve the > inconsistency in favor of either the code or the text; we presume > that they know which states their original intent. If code > changes, then test vectors, known answer tests and Monte Carlo > tests may also change. > > * Simple corrections to the reference or optimized code that fix > coding bugs. At this stage NIST may reject changes to optimized > code that have a large effect on performance, although improved > optimized code for different platforms may be considered later in > the competition. Again, changes to the code may result in changes > to test vectors, known answer and Monte Carlo tests. > > We are concerned about managing the updating of the submissions and > maintaining a history of the changes. NIST asks submitters who wish to > submit a copy of the updated specification or code to provide it before > Jan 15, 2009, along with a specific change list, explaining what was > changed and the reason for the change. Only one such update will be > accepted. The corrected specification and/or code will be the "official" > version of the submission for the first workshop. > > Note that NIST will not accept updates inconsistent with the criteria > above. Updates received after January 15, 2009 will not be accepted > before the workshop. We will consider a second round of corrections a > month or two after the first workshop. > > To ensure that the errata for each algorithm are available to > researchers as soon as possible, submitters may choose to maintain a web > page for their algorithm. If submitters provide the URL for an errata > page to NIST, we will establish pointers from the official SHA-3 website > to this supplementary information for each such submission. NIST > encourages submitters to post corrected versions of their specifications > on their own site as soon as possible so that researchers studying their > particular algorithm can obtain the most accurate specification. > > More than 20 of the submissions have been posted on the Ecrypt "SHA-3 > Zoo" page , and several > of these have apparently already been broken. We have not yet verified > these breaks, and will not consider these attacks in our determination > of acceptability. Therefore, we will post all “acceptable” submissions, > including those that may already have been broken. However, we believe > that in some cases the designers have conceded that their algorithm has > been broken. If submitters concede that their algorithm has been > broken, they should notify NIST so that this can be noted on the NIST > website. > > Regards, > > Bill > > -- > William E. Burr > Manager, Security Technology Group > NIST > 100 Bureau Dr., MS 8931 > Gaithersburg, MD. 20899 > Bldg. 222, Rm B362 > Tel: 301-975-2914 > Fax: 301-975-8670 > -- Ronald L. Rivest Room 32-G692, Stata Center, MIT, Cambridge MA 02139 Tel 617-253-5880, Email From hash-forum@nist.gov Fri Nov 14 13:14:58 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAELEqou012100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Nov 2008 13:14:54 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAELE5ew015858; Fri, 14 Nov 2008 16:14:10 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAELDbvv005432; Fri, 14 Nov 2008 16:13:37 -0500 Date: Fri, 14 Nov 2008 16:13:37 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Karan, Cem (Civ, ARL/CISD)" To: Multiple recipients of list Subject: RE: Corrections to SHA-3 Submissions and the Next Steps X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Cc: "Bill Burr" X-To: References: <491DCE5D.8020404@nist.gov> In-Reply-To: <491DCE5D.8020404@nist.gov> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0008_01C94672.3A9020F0" MIME-Version: 1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 14 Nov 2008 13:14:54 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 149 This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C94672.3A9020F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit On Friday, November 14, 2008 2:23 PM Bill Burr wrote: <> > We are concerned about managing the updating of the > submissions and maintaining a history of the changes. NIST > asks submitters who wish to submit a copy of the updated > specification or code to provide it before Jan 15, 2009, > along with a specific change list, explaining what was > changed and the reason for the change. Only one such update > will be accepted. The corrected specification and/or code > will be the "official" version of the submission for the > first workshop. <> Bill, have you considered using a version control system like Subversion (http://subversion.tigris.org/), or a Wiki system like Trac (http://trac.edgewall.org/)? You'd have a history of any changes that are made, in a very user-friendly form. Thanks, Cem Karan ------=_NextPart_000_0008_01C94672.3A9020F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPKzCCAmcw ggHQoAMCAQICAQQwDQYJKoZIhvcNAQEFBQAwYTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxHDAaBgNVBAMTE0RvRCBDTEFT UyAzIFJvb3QgQ0EwHhcNMDAwNTE5MTMxMzAwWhcNMjAwNTE0MTMxMzAwWjBhMQswCQYDVQQGEwJV UzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEc MBoGA1UEAxMTRG9EIENMQVNTIDMgUm9vdCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA tTD+ZL7qzG3tgSz3f+kZug5paijhqanLlVgf8eaaaVPgiD+RxVG5Y5eo5iGME142PKhX+vhwLExq y78wp0wW5DJc+BKwUfgWV40vtE36LqiU6Cph1FcNR85uLC9+mGfMAAirtpYWNcKFkeVboArHZlJi 82F1lReuvCpWKaXgK1MCAwEAAaMvMC0wHQYDVR0OBBYEFGycpfBcj21BjcQXO5BXwg+jzW3+MAwG A1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEAr3FE+ZcjzGhpjEMHQbqIILMiAEHImKBVHM0/ brGTXK36GJq7HHNv/SRCj4efUc++hp/p14pITwjZaZSsP+YPLZcPKJN2T2Lf/6DNYfimhgwxNCDc fy+o+zm+le44WQJiwd5sFU/g35275HlzJP1jZJX3SqiZH0hllcd7v3gy53owggQbMIIDhKADAgEC AgEiMA0GCSqGSIb3DQEBBQUAMGExCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1l bnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRwwGgYDVQQDExNEb0QgQ0xBU1MgMyBSb290 IENBMB4XDTAzMDQwOTE0MDgyM1oXDTA5MDQwNzE0MDgyM1owZDELMAkGA1UEBhMCVVMxGDAWBgNV BAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxHzAdBgNVBAMT FkRPRCBDTEFTUyAzIEVNQUlMIENBLTYwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKrT+mpL 1n6K3Zpw8AdypnLKY49xS7/0kLBTmcSu531yWV9WAmVZIhCl1IH5S/SR00ZhjmykEqixCufNBRoP P6EPAJcvuHEoMGNkUkZCJWfsvwREp72pF0H2xNtNbJPNIwf9u5tex4ycsNkSlkV7Yc3YVUDWFdQ5 lWjZ/aEnxsm3AgMBAAGjggHeMIIB2jAdBgNVHQ4EFgQU6KsjNXpbIFoUKfVKyfCWFoA4YrYwDgYD VR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wDAYDVR0kBAUwA4ABADAfBgNVHSMEGDAWgBRs nKXwXI9tQY3EFzuQV8IPo81t/jAwBgNVHSAEKTAnMAsGCWCGSAFlAgELBTALBglghkgBZQIBCwkw CwYJYIZIAWUCAQsKMIGDBgNVHRIEfDB6hnhsZGFwOi8vZHMtMy5jM3BraS5jaGFtYi5kaXNhLm1p bC9jbiUzZERvRCUyMENMQVNTJTIwMyUyMFJvb3QlMjBDQSUyY291JTNkUEtJJTJjb3UlM2REb0Ql MmNvJTNkVS5TLiUyMEdvdmVybm1lbnQlMmNjJTNkVVMwgbAGA1UdHwSBqDCBpTCBoqCBn6CBnIaB mWxkYXA6Ly9kcy0zLmMzcGtpLmNoYW1iLmRpc2EubWlsL2NuJTNkRG9EJTIwQ0xBU1MlMjAzJTIw Um9vdCUyMENBJTJjb3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUy Y2MlM2RVUz9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeTANBgkqhkiG9w0BAQUFAAOB gQBwDqycTcsAhWoXHpW+9uHk9a5D/7csvQ1abGZzNMiQTCPj5FXf1reFttfiyGD8gHkXIHaF54hp OivADuLbRxNxhr2LI4JwtPICm62FvrIsXjK8h2WPoay5HDsbqzHnhKpwRcqwQ6/D0G64lARdi/rg Ptass3e2FNwdvxPh26hQFzCCBCcwggOQoAMCAQICAxywCjANBgkqhkiG9w0BAQUFADBkMQswCQYD VQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsT A1BLSTEfMB0GA1UEAxMWRE9EIENMQVNTIDMgRU1BSUwgQ0EtNjAeFw0wNjAzMDgwMDAwMDBaFw0w OTAzMDcyMzU5NTlaMHIxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAK BgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExHzAdBgNVBAMTFktBUkFOLkNF TS5GLjEyNTg2MTM3NjMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM+EXr+HA1pewupbWmZ4 YCtrMMennsGmEzRbj0plmfZfwhA+R9AGzV3fMORSFpJNXxeOQg5qDmpItyVFFqDAOfuuWCcz1vap g0Wif5FrYGZeLppXImE9rwcZxHYWWp/N7PK1Bt1VhY2KB+QowrneVQcbA69+rWKiIYbUsTsRXkpR AgMBAAGjggHXMIIB0zAOBgNVHQ8BAf8EBAMCBSAwIAYDVR0RBBkwF4EVY2VtLmthcmFuQHVzLmFy bXkubWlsMB8GA1UdIwQYMBaAFOirIzV6WyBaFCn1SsnwlhaAOGK2MB0GA1UdDgQWBBRpwgvGfLf0 DuqvMXJPwb5sEJn3VjAWBgNVHSAEDzANMAsGCWCGSAFlAgELCTCBjAYDVR0SBIGEMIGBhn9sZGFw Oi8vZW1haWwtZHMtNC5jM3BraS5kZW4uZGlzYS5taWwvY24lM2RET0QlMjBDTEFTUyUyMDMlMjBF TUFJTCUyMENBLTYlMmNvdSUzZFBLSSUyY291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50 JTJjYyUzZFVTMIG3BgNVHR8Ega8wgawwgamggaaggaOGgaBsZGFwOi8vZW1haWwtZHMtNC5jM3Br aS5kZW4uZGlzYS5taWwvY24lM2RET0QlMjBDTEFTUyUyMDMlMjBFTUFJTCUyMENBLTYlMmNvdSUz ZFBLSSUyY291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50JTJjYyUzZFVTP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5MA0GCSqGSIb3DQEBBQUAA4GBAIzpJlHIqlTNPOxS0Epi 7gzvp/YnheuUQZYtwKX9ZnTCW4gmtQ9nkM2nofjlJXhthLr/+inbQluJuabJpXaJUcGQTTx4b98B Iu9Q7XtDPFBXdwwY3fSIHtj0nEnYERfLqvVUgmTTPa9ps09hPe4DW5StGXHwjAbZ34O19qG/QC0j MIIEcjCCA9ugAwIBAgIDHLAEMA0GCSqGSIb3DQEBBQUAMGQxCzAJBgNVBAYTAlVTMRgwFgYDVQQK Ew9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMR8wHQYDVQQDExZE T0QgQ0xBU1MgMyBFTUFJTCBDQS02MB4XDTA2MDMwODAwMDAwMFoXDTA5MDMwNzIzNTk1OVowcjEL MAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYD VQQLEwNQS0kxDDAKBgNVBAsTA1VTQTEfMB0GA1UEAxMWS0FSQU4uQ0VNLkYuMTI1ODYxMzc2MzCB nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEArFfTC+8lz+DzENwVm+Hf2Iqt452M3Ba+62ASid1g fvhfscFkXGPckJ88xVusJ9x9JGITzdXj2I9L3jnBIGCR6l/r+2U4NZqjC/8waxvn2sV8JfZVqoIX woCb+6BFiYAfJMN6sTrWpMRQFMGyNhlXDud+3SbGduVX7oyIlGNJ0YcCAwEAAaOCAiIwggIeMA4G A1UdDwEB/wQEAwIGwDAfBgNVHSMEGDAWgBToqyM1elsgWhQp9UrJ8JYWgDhitjAdBgNVHQ4EFgQU inK/whPqvhZnavfwilVngimvlZQwFgYDVR0gBA8wDTALBglghkgBZQIBCwkwgYwGA1UdEgSBhDCB gYZ/bGRhcDovL2VtYWlsLWRzLTQuYzNwa2kuZGVuLmRpc2EubWlsL2NuJTNkRE9EJTIwQ0xBU1Ml MjAzJTIwRU1BSUwlMjBDQS02JTJjb3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292 ZXJubWVudCUyY2MlM2RVUzCBtwYDVR0fBIGvMIGsMIGpoIGmoIGjhoGgbGRhcDovL2VtYWlsLWRz LTQuYzNwa2kuZGVuLmRpc2EubWlsL2NuJTNkRE9EJTIwQ0xBU1MlMjAzJTIwRU1BSUwlMjBDQS02 JTJjb3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9j ZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeTApBgNVHSUEIjAgBgorBgEEAYI3FAICBggr BgEFBQcDBAYIKwYBBQUHAwIwQAYDVR0RBDkwN4EVY2VtLmthcmFuQHVzLmFybXkubWlsoB4GCisG AQQBgjcUAgOgEAwOMTI1ODYxMzc2M0BtaWwwDQYJKoZIhvcNAQEFBQADgYEAGnJ9RbiOICWSnRtG KW+rm2tv99/Gv13Bs6RrJKmyEYlnW8pldRdUn3NvHzArIutntVP8A/QLXU5p+Fe9ZN4NZJLEW5Iw d2/PAecGRiCU8upmhY7HdewxG2IjwLnzc9CBf+fopsa3eBNBpzDoGRHv/eIu+iZST3dVl0rpkncF r/gxggLGMIICwgIBATBrMGQxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQx DDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMR8wHQYDVQQDExZET0QgQ0xBU1MgMyBFTUFJTCBD QS02AgMcsAQwCQYFKw4DAhoFAKCCAbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDgxMTE0MjEwMTE3WjAjBgkqhkiG9w0BCQQxFgQUB3Hii+dYe3ALlqONJtnCkeSd 25IwWAYJKoZIhvcNAQkPMUswSTAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwegYJKwYBBAGCNxAEMW0wazBkMQsw CQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNV BAsTA1BLSTEfMB0GA1UEAxMWRE9EIENMQVNTIDMgRU1BSUwgQ0EtNgIDHLAKMHwGCyqGSIb3DQEJ EAILMW2gazBkMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQL EwNEb0QxDDAKBgNVBAsTA1BLSTEfMB0GA1UEAxMWRE9EIENMQVNTIDMgRU1BSUwgQ0EtNgIDHLAK MA0GCSqGSIb3DQEBAQUABIGAbXK/ury3zwhHYm+RqRVCIDZqd/Xs+4awKy+EpLpAOIWUJzMGhysL Aeai+aPo36HT9ddMK5iScTM5BsEdn8eY98l6NNTPbhaiZCywUwI9NC/JK9YsKNEc4xeJVUf6IrA8 eBkeI2r96unYIElhC/MyR4y29CwK0C285n5mPiQTSx8AAAAAAAA= ------=_NextPart_000_0008_01C94672.3A9020F0-- From hash-forum@nist.gov Fri Nov 14 14:23:05 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAEMN0SS019898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Nov 2008 14:23:01 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAEMM5Hi026867; Fri, 14 Nov 2008 17:22:08 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAEMLOP7012099; Fri, 14 Nov 2008 17:21:24 -0500 Date: Fri, 14 Nov 2008 17:21:24 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "John Wilkinson" To: Multiple recipients of list Subject: Re: 2^185 preimage attack on MD6-256 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <20081114160344.64745.qmail@cr.yp.to> <491DCEE5.6060907@larc.usp.br> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 In-Reply-To: <491DCEE5.6060907@larc.usp.br> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 14 Nov 2008 14:23:01 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 150 In case anyone else missed it, I think Dan is just making a point that "attacks" can sound serious, when, in fact, they are simply variations on generic attacks that apply to any hash function. (100*2^185*(2^32)^2 ~= 2^256) On Fri, Nov 14, 2008 at 2:24 PM, Paulo S. L. M. Barreto wrote: > > D. J. Bernstein wrote: >> After the recent flood of attacks on hash functions that I had never >> heard of before this month, I'm pleased to announce that I've found an >> attack on MD6-256 with time complexity just 2^185. > [snip] >> P.S. Preliminary analysis suggests that, astonishingly, Skein and Keccak >> will both succumb to analogous attacks, and that the attack on Skein >> will be even faster than the attack on MD6. Who would have imagined that >> three hash-function designs with such different design principles would >> share a critical weakness? > > That's amazing! Has anybody independently checked Dan's attack? (Sorry for > playing the devil's advocate, Dan -- this will only increase confidence that > these three candidates are out of the competition, scornful comments > notwithstanding) > > Paulo. > > From hash-forum@nist.gov Fri Nov 14 17:05:46 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAF15fFg002951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Nov 2008 17:05:42 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAF14msl031317; Fri, 14 Nov 2008 20:04:53 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAF13nYU005688; Fri, 14 Nov 2008 20:03:49 -0500 Date: Fri, 14 Nov 2008 20:03:49 -0500 Message-Id: <62629.201.92.247.254.1226710245.squirrel@webmail.larc.usp.br> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Paulo S. L. M. Barreto" To: Multiple recipients of list Subject: Re: 2^185 preimage attack on MD6-256 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain;charset=iso-8859-1 MIME-Version: 1.0 X-To: hash-forum@nist.gov References: <20081114160344.64745.qmail@cr.yp.to> <491DCEE5.6060907@larc.usp.br> In-Reply-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 14 Nov 2008 17:05:43 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 151 On Fri, November 14, 2008 20:21, John Wilkinson said: > > In case anyone else missed it, I think Dan is just making a point that > "attacks" can sound serious, when, in fact, they are simply variations > on generic attacks that apply to any hash function. > (100*2^185*(2^32)^2 ~= 2^256) Ah, well noticed! Still, whichever way you choose (i.e. either multiplying or adding the costs) the result is proportionally better than the "attack" that originated all this fuss. That's an eloquent way to make a point, Dan -- I think this time even Stefan will agree ;-) Cheers, Paulo. From hash-forum@nist.gov Sat Nov 15 00:28:46 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAF8SfrU003511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 15 Nov 2008 00:28:42 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAF8RVYQ021791; Sat, 15 Nov 2008 03:27:33 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAF8QAPG013369; Sat, 15 Nov 2008 03:26:11 -0500 Date: Sat, 15 Nov 2008 03:26:10 -0500 Message-Id: <20081115081758.75d95c60@gamma> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Brandon Enright To: Multiple recipients of list Subject: Near and truncated collisions in Spectral Hash (shash-###) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=US-ASCII Mime-Version: 1.0 X-Mailer: Claws Mail 3.6.1 (GTK+ 2.12.11; x86_64-pc-linux-gnu) X-Cc: bmenrigh@ucsd.edu, Cetin Kaya Koc X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 15 Nov 2008 00:28:42 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 152 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Colleagues, Even though I have not been able to find a full collision in shash, I have a few results which I believe are interesting in their own right. To reduce the length of this email, rather than provide the hash of m1 and the hash m2, I will provide the difference (XOR) of the two hashes and a colliding-bit count in this format: shash-### (### bits or ##.##%): m1 = XXXX... m2 = XXXX... hashdiff = XXX... For most of the shash size options I have multiple message pairs with the same bit collision count but for brevity I'll only include one. Near collisions: ================= shash-128 (122 bits or 95.31%): m1 = 0e5897f7454f3388baecdabc2e78c5c2a66eceedeb759ae591036e99c9e133c729380e392fd723024511f64bf058806f5d97752918137de0d16156b9d14c26e0 m2 = 0e5897f74550cc48baecdabc2e78c5c2a66eceedeb759ae591036e99c9e133c729380e392fd723024511f64bf058806f5d97752918137de0d16156b9d14c26e0 hashdiff = 00880000800000000800000008080000 shash-224 (215 bits or 95.98%): m1 = a2bbd509657c83d7520b5d40c8b236a4b7b330f7a1e95ee07b62b8da045690e28a412dd4acbf952cad4e645432c53056f4e1cfebd22b48a9014a776bfde2ace1 m2 = 9d442509657c83d7520b5d40c8b236a4b7b330f7a1e95ee07b62b8da045690e28a412dd4acbf952cad4e645432c53056f4e1cfebd22b48a9014a776bfde2ace1 hashdiff = 0098000000080000002000000010000000000000000040000000a000 shash-512 (482 bits or 94.14%) m1 = ba585480aabf5af1f919bf1ab2f086d86d2bfcf627e988e3dd02c5606fb2700de898909c26153076474d9f1cc973141fe518a2e95c3b5713f9af2ce8ef99d309 m2 = ba585480aabf5af1f919bf1ab2f086d86d2bfcf627e988e3dd02c5606fb58ff3e898909c26153076474d9f1cc973141fe518a2e95c3b5713f9af2ce8ef99d309 hashdiff = 0000000000000000000000000000d0800000000000000000000000000f0004a30020003005000000008000700000003000000c0000000000200000e000000000 Truncated collision: ===================== shash-512 (22 bytes or 34.38%) m1 = 628398d4009dd8b5c6ce65be618598a1b2f2a3810e08fcea00e1c5e56ada0d4d73cfe5518c088bc68e18c102bb44e96521be35dc69ab8c6b0594d0f22a9a1f87 m2 = 628398d4009dd8b5c6ce65be618598a1b2f2a3810e08fcea00e1c5e56ada0d4d73cc1aae8c088bc68e18c102bb44e96521be35dc69ab8c6b0594d0f22a9a1f87 hashdiff = 000000000000000000000000000000000000000000000e400000000f000030100000cb34006030800007c8000000000080000000500000200080e00006001000 Comments: ========== Based on my work on shash-128 and my inability to get a near-collision in more than 122 bits I'm starting to think that the technique I'm using can not find a full collision in only a single block (512 bits) of input. Unfortunately I haven't had much success extending my attack into another block. I believe the truncated hash collision of 22 full bytes found in shash-512 is a serious break. Although the authors make no claim about the security of shash under truncation, it is widely accepted that a quality hash function should hold up well when truncated. At this point I think it is very unlikely that I'm going to be able to improve or extend this attack to a full collision. Regardless, if the results I've provided above can be independently verified (the test vectors verify for me but I'm nervous none-the-less) then I believe Spectral Hash should be considered broken. Regards, Brandon - -- Brandon Enright Network Security Analyst UC San Diego (UCSD) bmenrigh@ucsd.edu -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkehbwACgkQqaGPzAsl94Kq4QCfTqAiPLEFEMmvoRuej7YcHueJ OUcAn1VDbZK7fToPSxrh7JWwvGD1rQdr =V/JU -----END PGP SIGNATURE----- From hash-forum@nist.gov Sat Nov 15 17:54:56 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAG1snt7016699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 15 Nov 2008 17:54:51 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAG1ropC027203; Sat, 15 Nov 2008 20:53:55 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAG1q55j017638; Sat, 15 Nov 2008 20:52:05 -0500 Date: Sat, 15 Nov 2008 20:52:05 -0500 Message-Id: <51590d340811151742o4f8839eck419d6305f8111d77@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "geoffrey park" To: Multiple recipients of list Subject: Re: NKS2D-224 and the cost of brute force X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <1226600347.5832.22.camel@calypso> <20081113202305.1b2a3200@gamma> <51590d340811131817g40c12422mbd912ea1a161ba31@mail.gmail.com> <20081114081544.33241308@moray> Content-Type: multipart/alternative; boundary="----=_Part_24968_19137203.1226799730483" MIME-Version: 1.0 In-Reply-To: <20081114081544.33241308@moray> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 15 Nov 2008 17:54:52 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 153 ------=_Part_24968_19137203.1226799730483 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Brandon, Can you tell me how you found those collisions? Was it just a brute force search, or did you find a pattern for generating collisions easily? In my own tests on smaller hash lengths I was able to generate hashes for all possible input values, sort them and count duplicates. I chose CA rules that gave less than 2^n-1 collisions. Of course it also has to be hard to find the colliding patterns. Do you have a suggestion to fix the algorithm? Or do you feel cellular automata are doomed as cryptographic hashes? -Geoff On Fri, Nov 14, 2008 at 3:17 AM, Brandon Enright wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Thu, 13 Nov 2008 21:30:22 -0500 or thereabouts "geoffrey park" > wrote: > > > Oops! Looks like the configuration I used for 224 bit is way too > > weak. Good work Cristophe! > > > > I was aware that cellular automata, or at least the totalizing ones > > I'm using are inherently lossy, > > i.e. different patterns that add to same total are possible. > > > > For the 512 bit configuration I attempted to fix this by using three > > different rules to generate patterns from the same input. The separate > > streams are XORed at the Finalize stage. > > Note also that some rules are way more lossy than others. Conway's > > Game of Life, for example, often collapses to blank from even very > > complex starting patterns. > > > > For fun you can try different rules, data overlap, or multiple > > streams. To make it even easier to find collisions NKS2D can be > > configured all the way down to a 16 bit hash. Just check out the > > HashEx and InitEx functions. > > > > -Geoff Park > > > > "Lossy" bit patterns can be found for NKS2D-512 too: > > Example collision pair for NKS2D-512 > 2008-11-13, Christophe De Canni=E8re, COSIC, Katholieke Universiteit Leuv= en > 2008-11-14, Brandon Enright, UC San Diego > > m1 =3D 1f560d6f > NKS2D-512(m1) =3D > 84c46a3b7a82c1a061784b546cad4f936f3d2ebd931c2048a888383a0f3f7baa13ababc86= e92ca5c58dcbda4a3d60c9f2e82469d517322c7b1e81b4ad8045cb1 > > m2 =3D 1f560d6d > NKS2D-512(m2) =3D > 84c46a3b7a82c1a061784b546cad4f936f3d2ebd931c2048a888383a0f3f7baa13ababc86= e92ca5c58dcbda4a3d60c9f2e82469d517322c7b1e81b4ad8045cb1 > > m1 and m2 collide! > > > Brandon > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (GNU/Linux) > > iEYEARECAAYFAkkdM7sACgkQqaGPzAsl94LmeACeOMAwerPPf+fKoHbaQA+9YtCY > aZsAn28zP6xBwRQfB9fIyXisTU6OG7EE > =3Dge6T > -----END PGP SIGNATURE----- > > > ------=_Part_24968_19137203.1226799730483 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Brandon,

Can you tell me how you found those collisions? Was it just= a brute force search, or did you find a pattern for generating collisions = easily?

In my own tests on smaller hash lengths I was able to genera= te hashes for all possible input values, sort them and count duplicates. I = chose CA rules that gave less than 2^n-1 collisions. Of course it also has = to be hard to find the colliding patterns.

Do you have a suggestion to fix the algorithm? Or do you feel cellular = automata are doomed as cryptographic hashes?

-Geoff

On Fri, Nov 14, 2008 at 3:17 AM, Brandon Enright <bmenrigh@ucsd.edu>= ; wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 13 Nov 2008 21:30:22 -0500 or thereabou= ts "geoffrey park"
<geoffrey.park@gmail.com&= gt; wrote:

> Oops!  Looks like the configuration I= used for 224 bit is way too
> weak. Good work Cristophe!
>
> I was aware that cellular automata, or at least the totalizing ones > I'm using are inherently lossy,
> i.e. different patterns that add to same total are possible.
>
> For the 512 bit configuration I attempted to fix this by using three > different rules to generate patterns from the same input. The separate=
> streams are XORed at the Finalize stage.
> Note also that some rules are way more lossy than others. Conway's=
> Game of Life, for example, often collapses to blank from even very
> complex starting patterns.
>
> For fun you can try different rules, data overlap, or multiple
> streams. To make it even easier to find collisions NKS2D can be
> configured all the way down to a 16 bit hash. Just check out the
> HashEx and InitEx functions.
>
>  -Geoff Park
>

"Lossy" bit patterns can be found for= NKS2D-512 too:

Example collision pair for NKS2D-512
2008-11-13, Christophe De Canni=E8re, COSIC, Ka= tholieke Universiteit Leuven
2008-11-14, Brandon Enright, UC San Diego

m1 =3D 1f560d6f
NKS2D-512(m1) =3D 84c46a3b7a82c1a061784b546cad4f936f3d2ebd931c2048a888383a0= f3f7baa13ababc86e92ca5c58dcbda4a3d60c9f2e82469d517322c7b1e81b4ad8045cb1

m2 =3D 1f560d6d
NKS2D-512(m2) =3D 84c46a3b7a82c1a061784b546cad4f936f3d2ebd931c2048a888383a0= f3f7baa13ababc86e92ca5c58dcbda4a3d60c9f2e82469d517322c7b1e81b4ad8045cb1

m1 and m2 collide!


Brandon

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkkdM7sACgkQqaGPzAs= l94LmeACeOMAwerPPf+fKoHbaQA+9YtCY
aZsAn28zP6xBwRQfB9fIyXisTU6OG7EE
=3Dge6T
-----END PGP SIGNATURE-----



------=_Part_24968_19137203.1226799730483-- From hash-forum@nist.gov Tue Nov 18 04:46:11 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAICk2Ym009016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Nov 2008 04:46:03 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAIBjP0S024394; Tue, 18 Nov 2008 06:45:30 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAIBheaD025489; Tue, 18 Nov 2008 06:43:40 -0500 Date: Tue, 18 Nov 2008 06:43:40 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Ivica Nikolic" To: Multiple recipients of list Subject: Preimages for Boole X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/alternative; boundary="----=_Part_52025_24118038.1227008280857" MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: Delayed for 00:59:08 by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 18 Nov 2008 04:46:04 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 154 ------=_Part_52025_24118038.1227008280857 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, it seems that preimages for Boole-n can be found with 2^{9n/16} computations and negligible memory. The attack is presented in the paper which is available at: http://lj.streamclub.ru/papers/hash/boole.pdf Best regards, --------------------------------------------------------------- Ivica Nikolic Laboratory of Algorithms, Cryptography and Security, University of Luxembourg, 6, rue Richard Coudenhove-Kalergi, L-1359 Luxembourg-Kirchberg Luxembourg Tel: +352 46 66 44 5490 ------=_Part_52025_24118038.1227008280857 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all,

it seems that preimages for Boole-n can be found with 2^{9n/16} computations and negligible memory.
The attack is presented in the paper which is available at:
http://lj.streamclub.ru/papers/hash/boole.pdf


Best regards,
---------------------------------------------------------------
Ivica Nikolic
Laboratory of Algorithms, Cryptography and Security,
University of Luxembourg,
6, rue Richard Coudenhove-Kalergi,
L-1359 Luxembourg-Kirchberg
Luxembourg
Tel:  +352 46 66 44 5490
------=_Part_52025_24118038.1227008280857-- From hash-forum@nist.gov Tue Nov 18 06:59:40 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAIExVW7020027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Nov 2008 06:59:33 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAIEv7qr000372; Tue, 18 Nov 2008 09:57:13 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAIEsOIC025571; Tue, 18 Nov 2008 09:54:24 -0500 Date: Tue, 18 Nov 2008 09:54:24 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Ivica Nikolic" To: Multiple recipients of list Subject: Preimage attacks on CubeHash512-r/4 and CubeHash512-r/8 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/alternative; boundary="----=_Part_50574_13187097.1227019475742" MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 18 Nov 2008 06:59:34 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 155 ------=_Part_50574_13187097.1227019475742 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, we have found preimage attacks on CubeHash512-r/4 and CubeHash512-r/8 that require $2^{496}$ and $2^{480}$ computations respectively and negligible memory. The attacks are presented in our paper which is available at : http://lj.streamclub.ru/papers/hash/cubehash.pdf Best regards, Ivica Nikolic, Dmitry Khovratovich, Ralf-Philipp Weinmann Laboratory of Algorithms, Cryptography and Security, University of Luxembourg, Luxembourg ------=_Part_50574_13187097.1227019475742 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all,

we have found preimage attacks on CubeHash512-r/4 and CubeHash512-r/8 that require $2^{496}$ and $2^{480}$ computations
respectively and negligible memory.
The attacks are presented in our paper which is available at :
http://lj.streamclub.ru/papers/hash/cubehash.pdf

Best regards,
Ivica Nikolic, Dmitry Khovratovich, Ralf-Philipp Weinmann

Laboratory of Algorithms, Cryptography and Security,
University of Luxembourg,
Luxembourg
------=_Part_50574_13187097.1227019475742-- From hash-forum@nist.gov Tue Nov 18 07:13:31 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAIFDPJC021537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Nov 2008 07:13:27 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAIFBTGh020687; Tue, 18 Nov 2008 10:11:39 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAIFAvET026914; Tue, 18 Nov 2008 10:10:57 -0500 Date: Tue, 18 Nov 2008 10:10:57 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Jean-Philippe Aumasson" To: Multiple recipients of list Subject: Re: Preimage attacks on CubeHash512-r/4 and CubeHash512-r/8 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 In-Reply-To: X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 18 Nov 2008 07:13:27 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.2 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED,URI_HEX shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 156 Dear all, Also have some results on CubeHash in http://www.131002.net/data/papers/AMNP08.pdf Best, JP On Tue, Nov 18, 2008 at 3:54 PM, Ivica Nikolic wrote: > Hi all, > > we have found preimage attacks on CubeHash512-r/4 and CubeHash512-r/8 that > require $2^{496}$ and $2^{480}$ computations > respectively and negligible memory. > The attacks are presented in our paper which is available at : > http://lj.streamclub.ru/papers/hash/cubehash.pdf > > Best regards, > Ivica Nikolic, Dmitry Khovratovich, Ralf-Philipp Weinmann > > Laboratory of Algorithms, Cryptography and Security, > University of Luxembourg, > Luxembourg > From hash-forum@nist.gov Tue Nov 18 07:27:03 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAIFQvvk022520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Nov 2008 07:26:58 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAIFPTkA031837; Tue, 18 Nov 2008 10:25:35 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAIFOol6025103; Tue, 18 Nov 2008 10:24:50 -0500 Date: Tue, 18 Nov 2008 10:24:50 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Dmitry Khovratovich" To: Multiple recipients of list Subject: Re: Preimage attacks on CubeHash512-r/4 and CubeHash512-r/8 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: Content-Type: multipart/alternative; boundary="----=_Part_63819_26984305.1227021800417" MIME-Version: 1.0 In-Reply-To: X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 18 Nov 2008 07:26:59 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 157 ------=_Part_63819_26984305.1227021800417 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi again, only after we have published the paper we noticed the appendix on generic attacks. Well, this implies that our attack was discovered before though the exact memory requirements were out of scope. Thus the memoryless approach we refer to can still be useful in attacks on other proposals. Dmitry, Ivica, Ralf. On Tue, Nov 18, 2008 at 3:54 PM, Ivica Nikolic wrote: > Hi all, > > we have found preimage attacks on CubeHash512-r/4 and CubeHash512-r/8 that > require $2^{496}$ and $2^{480}$ computations > respectively and negligible memory. > The attacks are presented in our paper which is available at : > http://lj.streamclub.ru/papers/hash/cubehash.pdf > > Best regards, > Ivica Nikolic, Dmitry Khovratovich, Ralf-Philipp Weinmann > > Laboratory of Algorithms, Cryptography and Security, > University of Luxembourg, > Luxembourg > -- Best regards, Dmitry Khovratovich University of Luxembourg, Laboratory of Algorithms, Cryptography and Security, + 352 46 66 44 5478 ------=_Part_63819_26984305.1227021800417 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi again,

only after we have published the paper we noticed  the appendix on generic attacks. Well, this implies that our attack was discovered before though the exact memory requirements were out of scope.

Thus the memoryless approach we refer to can still be useful in attacks on other proposals.

Dmitry, Ivica, Ralf.

On Tue, Nov 18, 2008 at 3:54 PM, Ivica Nikolic <cube444@gmail.com> wrote:
Hi all,

we have found preimage attacks on CubeHash512-r/4 and CubeHash512-r/8 that require $2^{496}$ and $2^{480}$ computations
respectively and negligible memory.
The attacks are presented in our paper which is available at :
http://lj.streamclub.ru/papers/hash/cubehash.pdf

Best regards,
Ivica Nikolic, Dmitry Khovratovich, Ralf-Philipp Weinmann

Laboratory of Algorithms, Cryptography and Security,
University of Luxembourg,
Luxembourg



--
Best regards,
Dmitry Khovratovich

University of Luxembourg,
Laboratory of Algorithms, Cryptography and Security,
+ 352 46 66 44 5478
------=_Part_63819_26984305.1227021800417-- From hash-forum@nist.gov Tue Nov 18 08:10:04 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAIG9wal026822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Nov 2008 08:10:00 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAIG7A38021852; Tue, 18 Nov 2008 11:07:19 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAIG69ak012582; Tue, 18 Nov 2008 11:06:09 -0500 Date: Tue, 18 Nov 2008 11:06:09 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Ivica Nikolic" To: Multiple recipients of list Subject: Correct links for Boole and CubeHash512 attacks X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/alternative; boundary="----=_Part_55692_31445572.1227023637129" MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 18 Nov 2008 08:10:00 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 158 ------=_Part_55692_31445572.1227023637129 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, we somehow mix the links for the attacks on Boole and CubeHash512. Here are the correct links: Boole: http://lj.streamclub.ru/papers/hash/boole.pdf CubeHash512: http://lj.streamclub.ru/papers/hash/cubehash.pdf Sorry for the inconvenience. Ivica, Dmitry, Ralf ------=_Part_55692_31445572.1227023637129 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

we somehow mix the links for the attacks on Boole and CubeHash512.
Here are the correct links:

Boole:
http://lj.streamclub.ru/papers/hash/boole.pdf

CubeHash512:
http://lj.streamclub.ru/papers/hash/cubehash.pdf

Sorry for the inconvenience.

Ivica, Dmitry, Ralf ------=_Part_55692_31445572.1227023637129-- From hash-forum@nist.gov Tue Nov 18 09:05:24 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAIH5GvG001139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Nov 2008 09:05:19 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAIH32uC028586; Tue, 18 Nov 2008 12:03:07 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAIH2B1w031545; Tue, 18 Nov 2008 12:02:11 -0500 Date: Tue, 18 Nov 2008 12:02:11 -0500 Message-Id: <3D37C124-A500-44C7-BDA5-C06860843701@cryptolib.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Sean O'Neil" To: Multiple recipients of list Subject: Re: Collisions for EnRUPT X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: <20081106213418.GA22469@ssh.esat.kuleuven.be> <56420.189.18.249.87.1226012862.squirrel@webmail.larc.usp.br> <49138171.2060009@reikon.us> <56983.189.18.249.87.1226016667.squirrel@webmail.larc.usp.br> <86917377-B43C-42D8-880A-F4E74187B3B7@cryptolib.com> <20081107091636.GB30756@ssh.esat.kuleuven.be> In-Reply-To: <20081107091636.GB30756@ssh.esat.kuleuven.be> Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 18 Nov 2008 09:05:20 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 159 After studying Sebastiaan's linearization attack in detail, we have come to the conclusion that EnRUPT does not require any structural changes, corrections or tweaks and that its dismissal is more than premature. It is only a matter of setting the 's' parameter to a slightly higher value increasing the amount of diffusion in the state between inputs. It is incorrect to call EnRUPT/s broken in general as there is no structural flaw exploited in this attack. Only EnRUPT/4 is broken so far. After a detailed study of this attack, we can recommend the following variants: EnRUPT64x2-224/8, s=H=8 EnRUPT64x2-256/8, s=H=8 EnRUPT64x2-384/12, s=H=12 EnRUPT64x2-512/16, s=H=16 That is, EnRUPT64x2/H by simply setting s=H. In general, s should be set to approximately (h+63)/64+4P-2 for all EnRUPT variants throwing all such linearization based collision searches well beyond the birthday bound. At such speed, its preimage resistance will also be higher. In regard to the other variants included in the submission, we can recommend EnRUPT32x2-128/6, s=6, H=8 EnRUPT32x2-160/7, s=7, H=10 EnRUPT32x2-192/8, s=8, H=12 On 18 Nov 2008, at 10:08, Sebastiaan Indesteege wrote: > It seems that the method I described indeed fails to find good > differentials if you increase the s parameter to these values. As NIST insisted, we have submitted a highly parameterised algorithm. It looks like we have chosen a variant that is a little too fast to resist linearization based collision searches. Even being 2-4 times slower, EnRUPT still has a competitive performance at 10-20 CPB on 64- bit CPUs, much faster than most submissions. Or maybe we should have submitted EnRUPT/2H or EnRUPT/64 like Professor Bernstein did with CubeHash/1 just to avoid someone labelling it as "broken" in a hurry? Are we looking for a good algorithm or are we looking to get rid of all the most competitive algorithms as quickly as possible? I hope that Sebastiaan will have the time to include in his paper his own measurements of what values of s are sufficient to resist such attacks against EnRUPT/s. I sincerely apologise for any inconvenience caused. We will publish a paper with our findings after Sebastiaan Indesteege publishes the details of his cryptanalysis. With best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. From hash-forum@nist.gov Tue Nov 18 09:18:50 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAIHIiZ9002745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Nov 2008 09:18:46 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAIHHC8u030538; Tue, 18 Nov 2008 12:17:18 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAIHGPpX027434; Tue, 18 Nov 2008 12:16:25 -0500 Date: Tue, 18 Nov 2008 12:16:25 -0500 Message-Id: <4922F74D.1080206@ellipticsemi.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Tom St Denis To: Multiple recipients of list Subject: Re: Collisions for EnRUPT X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: <3D37C124-A500-44C7-BDA5-C06860843701@cryptolib.com> References: <20081106213418.GA22469@ssh.esat.kuleuven.be> <56420.189.18.249.87.1226012862.squirrel@webmail.larc.usp.br> <49138171.2060009@reikon.us> <56983.189.18.249.87.1226016667.squirrel@webmail.larc.usp.br> <86917377-B43C-42D8-880A-F4E74187B3B7@cryptolib.com> <20081107091636.GB30756@ssh.esat.kuleuven.be> <3D37C124-A500-44C7-BDA5-C06860843701@cryptolib.com> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 18 Nov 2008 09:18:46 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 160 Sean O'Neil wrote: > > After studying Sebastiaan's linearization attack in detail, we have > come to the conclusion that EnRUPT does not require any structural > changes, corrections or tweaks and that its dismissal is more than > premature. It is only a matter of setting the 's' parameter to a > slightly higher value increasing the amount of diffusion in the state > between inputs. > > It is incorrect to call EnRUPT/s broken in general as there is no > structural flaw exploited in this attack. Only EnRUPT/4 is broken so > far. After a detailed study of this attack, we can recommend the > following variants: Not that I'm saying this applies ... but wasn't FEAL broken with a linear style attack, renamed FEAL-4 then re-proposed as FEAL-8? .... interesting parallels hehehehe :-) Tom From hash-forum@nist.gov Tue Nov 18 09:51:19 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAIHpCwO006744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Nov 2008 09:51:15 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAIHmW1T030904; Tue, 18 Nov 2008 12:48:38 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAIHlhZE026556; Tue, 18 Nov 2008 12:47:43 -0500 Date: Tue, 18 Nov 2008 12:47:43 -0500 Message-Id: <96BE6B86-BF1D-42F7-8766-E35BF3C23246@cryptolib.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Sean O'Neil" To: Multiple recipients of list Subject: Re: Collisions for EnRUPT X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: <20081106213418.GA22469@ssh.esat.kuleuven.be> <56420.189.18.249.87.1226012862.squirrel@webmail.larc.usp.br> <49138171.2060009@reikon.us> <56983.189.18.249.87.1226016667.squirrel@webmail.larc.usp.br> <86917377-B43C-42D8-880A-F4E74187B3B7@cryptolib.com> <20081107091636.GB30756@ssh.esat.kuleuven.be> <3D37C124-A500-44C7-BDA5-C06860843701@cryptolib.com> <4922F74D.1080206@ellipticsemi.com> In-Reply-To: <4922F74D.1080206@ellipticsemi.com> Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 18 Nov 2008 09:51:16 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 161 On 18 Nov 2008, at 18:16, Tom St Denis wrote: > Not that I'm saying this applies ... but wasn't FEAL broken with a > linear style attack, renamed FEAL-4 then re-proposed as > FEAL-8? .... interesting parallels hehehehe :-) FEAL was not originally proposed as FEAL-n, was it? EnRUPT is proposed as EnRUPT/s. There is a parallel that has always been there. If we had proposed an over-designed algorithm such as EnRUPT/32, it would have most certainly received less cryptanalysis and we would have never learned about the weakness of EnRUPT/4. It has become an unfortunate custom in the academic world not to publish [and even not accept for publication] results of unsuccessful cryptanalysis. Now EnRUPT is benefiting from fast and interesting cryptanalytic results everyone can learn from. Best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. From hash-forum@nist.gov Tue Nov 18 10:04:56 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAII4mvs008750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Nov 2008 10:04:52 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAII3DdU004816; Tue, 18 Nov 2008 13:03:23 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAII28Dn022936; Tue, 18 Nov 2008 13:02:08 -0500 Date: Tue, 18 Nov 2008 13:02:08 -0500 Message-Id: <4923012F.5080202@ellipticsemi.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Tom St Denis To: Multiple recipients of list Subject: Re: Collisions for EnRUPT X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: <96BE6B86-BF1D-42F7-8766-E35BF3C23246@cryptolib.com> References: <20081106213418.GA22469@ssh.esat.kuleuven.be> <56420.189.18.249.87.1226012862.squirrel@webmail.larc.usp.br> <49138171.2060009@reikon.us> <56983.189.18.249.87.1226016667.squirrel@webmail.larc.usp.br> <86917377-B43C-42D8-880A-F4E74187B3B7@cryptolib.com> <20081107091636.GB30756@ssh.esat.kuleuven.be> <3D37C124-A500-44C7-BDA5-C06860843701@cryptolib.com> <4922F74D.1080206@ellipticsemi.com> <96BE6B86-BF1D-42F7-8766-E35BF3C23246@cryptolib.com> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 18 Nov 2008 10:04:53 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 162 Sean O'Neil wrote: > > On 18 Nov 2008, at 18:16, Tom St Denis wrote: > >> Not that I'm saying this applies ... but wasn't FEAL broken with a >> linear style attack, renamed FEAL-4 then re-proposed as FEAL-8? .... >> interesting parallels hehehehe :-) > > FEAL was not originally proposed as FEAL-n, was it? EnRUPT is proposed > as EnRUPT/s. > > There is a parallel that has always been there. If we had proposed an > over-designed algorithm such as EnRUPT/32, it would have most > certainly received less cryptanalysis and we would have never learned > about the weakness of EnRUPT/4. It has become an unfortunate custom in > the academic world not to publish [and even not accept for > publication] results of unsuccessful cryptanalysis. Now EnRUPT is > benefiting from fast and interesting cryptanalytic results everyone > can learn from. Oh yeah, I'm not critiquing your approach. I just found it funny that there was a parallel with the 4 -> 8, linear attack, etc... And you're right, FEAL was originally proposed as just FEAL without the round number modifier, that's why I said "renamed FEAL-4." Tom From hash-forum@nist.gov Tue Nov 18 10:47:16 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAIIl8ZQ015477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Nov 2008 10:47:11 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAIIj24I025340; Tue, 18 Nov 2008 13:45:09 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAIIhhxM010375; Tue, 18 Nov 2008 13:43:43 -0500 Date: Tue, 18 Nov 2008 13:43:43 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Orr Dunkelman To: Multiple recipients of list Subject: Re: Collisions for EnRUPT X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed MIME-Version: 1.0 References: <20081106213418.GA22469@ssh.esat.kuleuven.be> <56420.189.18.249.87.1226012862.squirrel@webmail.larc.usp.br> <49138171.2060009@reikon.us> <56983.189.18.249.87.1226016667.squirrel@webmail.larc.usp.br> <86917377-B43C-42D8-880A-F4E74187B3B7@cryptolib.com> <20081107091636.GB30756@ssh.esat.kuleuven.be> <3D37C124-A500-44C7-BDA5-C06860843701@cryptolib.com> <4922F74D.1080206@ellipticsemi.com> <96BE6B86-BF1D-42F7-8766-E35BF3C23246@cryptolib.com> In-Reply-To: <96BE6B86-BF1D-42F7-8766-E35BF3C23246@cryptolib.com> X-To: Multiple recipients of list X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 18 Nov 2008 10:47:11 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 163 On Tue, 18 Nov 2008, Sean O'Neil wrote: > There is a parallel that has always been there. If we had proposed an > over-designed algorithm such as EnRUPT/32, it would have most certainly > received less cryptanalysis and we would have never learned about the > weakness of EnRUPT/4. It has become an unfortunate custom in the academic > world not to publish [and even not accept for publication] results of > unsuccessful cryptanalysis. Now EnRUPT is benefiting from fast and > interesting cryptanalytic results everyone can learn from. Well, you cannot hold the stick from both ends. Academic conferences do accept papers which break less than the full cipher/hash/MAC, sometimes with an amazingly unrealistic data/time/memory complexity. Sometimes, there are even papers which offer an attack which is less efficient than a generic attack, and they get published. Then people, including you (as you've done so many times) complain about "why these papers get published?". In my view, this is exactly what you now tell us we should do, i.e., we should accept papers that fail (but offer cryptanalysis of reduced round variants). Thanks, we have been doing this for years now, and it seems we'll continue to do so for years to come, but now maybe people will understand why a related-key attack on 10-round AES-192 with data complexity of 2^120 CPs gets accepted to an international academic conference. So next time, before you attack academics that do exactly what you want them to do, please spend the time required to understand what they are doing (sometimes we are doing things right), why they are doing so (sometimes we have good reasons, and not running after more publications, as you mentioned several times in public as a reason), and make sure that you really understand what you are complaining about (because now you complain about us not doing something that we actually do, and when we do it, you complain why we do so). Best Regards, Orr. -- Orr Dunkelman, Ecole Normale Superieure Departement d'Informatique Tel. +33-1-44-32-20-50 Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm From hash-forum@nist.gov Tue Nov 18 11:00:42 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAIJ0Z1v017075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Nov 2008 11:00:37 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAIIxFrG001090; Tue, 18 Nov 2008 13:59:22 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAIIwliQ008337; Tue, 18 Nov 2008 13:58:47 -0500 Date: Tue, 18 Nov 2008 13:58:47 -0500 Message-Id: <84ee25d80811181051p38479b67g50b0d182d267eb1b@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Kasra Nassir" To: Multiple recipients of list Subject: Re: Collisions for EnRUPT X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <20081106213418.GA22469@ssh.esat.kuleuven.be> <56420.189.18.249.87.1226012862.squirrel@webmail.larc.usp.br> <49138171.2060009@reikon.us> <56983.189.18.249.87.1226016667.squirrel@webmail.larc.usp.br> <86917377-B43C-42D8-880A-F4E74187B3B7@cryptolib.com> <20081107091636.GB30756@ssh.esat.kuleuven.be> <3D37C124-A500-44C7-BDA5-C06860843701@cryptolib.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 In-Reply-To: <3D37C124-A500-44C7-BDA5-C06860843701@cryptolib.com> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 18 Nov 2008 11:00:38 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 164 Hi all, I quiet agree with Sean O'Neil, The fact is despite the current 'variant' of the algorithm could be attacked, SHA-3 is trying to find an algorithm that could not be attacked (well clearly there exits many other reasons for existence of this competition). So given that any algorithm (EnRUPT included) increases the number of rounds it runs or similar action is take, the algorithm should not be labeled Broken. EnRUPT has interested many because of its simple structure and credit should be given to this. With new proposed s=H=... proposal if EnRUPT is not broken again, I don't see any other reason why it should be "crossed out" of the competition. With best regards From hash-forum@nist.gov Tue Nov 18 11:00:50 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAIJ0ifd017093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Nov 2008 11:00:46 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAIIxOa6001145; Tue, 18 Nov 2008 13:59:32 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAIIxBpd009206; Tue, 18 Nov 2008 13:59:11 -0500 Date: Tue, 18 Nov 2008 13:59:11 -0500 Message-Id: <20081118135449.233c2563@cs.columbia.edu> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Steven M. Bellovin" To: Multiple recipients of list Subject: Re: Preimage attacks on CubeHash512-r/4 and CubeHash512-r/8 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Mime-Version: 1.0 X-Mailer: Claws Mail 3.6.1 (GTK+ 2.14.3; x86_64--netbsd) References: In-Reply-To: X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 18 Nov 2008 11:00:46 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 165 > we have found preimage attacks ... > that require $2^{496}$ and $2^{480}$ computations > respectively and negligible memory. Portions intentionally elided, because my point is independent of this particular result. I think it's worthwhile for the community to discuss what class of attack actually suggests a weakness worth avoiding. Take this example. If web pages I've consulted and my calculations are right, the observable universe has a mass of 10^55 g (http://curious.astro.cornell.edu/question.php?number=342). A hydrogen atom masses 8.37*20^-25 g, yielding a total number of baryons of about 10^79, or 2^262. Let's turn each of those baryons into a computer. (That 10^55 number includes dark matter, which is presumably not composed of baryons, but let's pretend.) Let's further assume that each of these computers can calculate a hash function in 10^-15 seconds (which is pretty good for a baryon), giving us an operation rate of 2^312 hashes/second. At 2^480 operations/hash, the entire visible universe could solve one in a mere 10^43 years. Of course, the solar system will be long gone by then -- the sun will last only about another 10^10 years (http://curious.astro.cornell.edu/question.php?number=389), but perhaps something will still care. And there's good news. http://arxiv.org/abs/hep-th/0510003 suggests that one plausible number for the lifetime of the universe is 10^60, so it can solve 10^17 hashes before The End. More seriously -- an attack of 2^480 computations is not indicative of a weakness. It may be useful as a guide to figuring out an attack, or as an indication of the strength of a system, but in itself it's in no way, shape, or form an "attack", and I don't know that it's right to label it as such. My question, though, is broader: what value is useful? There have been key length calculations over the years (i.e., RFC 3766) about system strengths; what is good enough here? Obviously, we want more if we can get it cheaply enough, but what is the floor? --Steve Bellovin, http://www.cs.columbia.edu/~smb From hash-forum@nist.gov Tue Nov 18 11:28:58 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAIJSpwf020404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Nov 2008 11:28:53 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAIJRNKQ003360; Tue, 18 Nov 2008 14:27:28 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAIJQdk9032221; Tue, 18 Nov 2008 14:26:39 -0500 Date: Tue, 18 Nov 2008 14:26:39 -0500 Message-Id: <4923156E.5010403@ellipticsemi.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Tom St Denis To: Multiple recipients of list Subject: Re: Preimage attacks on CubeHash512-r/4 and CubeHash512-r/8 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: <20081118135449.233c2563@cs.columbia.edu> References: <20081118135449.233c2563@cs.columbia.edu> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 18 Nov 2008 11:28:54 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 166 Steven M. Bellovin wrote: > >> we have found preimage attacks ... >> that require $2^{496}$ and $2^{480}$ computations >> respectively and negligible memory. >> > > Portions intentionally elided, because my point is independent of this > particular result. > > I think it's worthwhile for the community to discuss what class of > attack actually suggests a weakness worth avoiding. Take this example. > If web pages I've consulted and my calculations are right, the > observable universe has a mass of 10^55 g > (http://curious.astro.cornell.edu/question.php?number=342). A hydrogen > atom masses 8.37*20^-25 g, yielding a total number of baryons of about > 10^79, or 2^262. Let's turn each of those baryons into a computer. > (That 10^55 number includes dark matter, which is presumably not > composed of baryons, but let's pretend.) Let's further assume that > each of these computers can calculate a hash function in 10^-15 > seconds (which is pretty good for a baryon), giving us an operation rate > of 2^312 hashes/second. At 2^480 operations/hash, the entire visible > universe could solve one in a mere 10^43 years. Of course, the solar > system will be long gone by then -- the sun will last only about > another 10^10 years > (http://curious.astro.cornell.edu/question.php?number=389), but perhaps > something will still care. > Which raises the question "do we really need a 512-bit hash?" Of course the answer is "not really." But don't let that stop anyone. Why we have perfectly expended resources on things we don't need! That's the way! When the process opened up I commented that what we really need is a hash that focuses on smaller outputs (e.g. optimized by not computing state it throws away) for purposes like MACs and what not. And without failure every single proposal I've skimmed through seems to have totally wholesale ignored this. So, no, an attack on the order of 2^400 work is not something to worry about, by that same token, "128-bits" and beyond levels of security is equally meaningless. You can't on the one hand throw out attacks that take that much time due to being impractical, then suggest that brute force is necessarily thwarted by using larger parameters. Tom From hash-forum@nist.gov Tue Nov 18 11:42:53 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAIJgkJe022045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Nov 2008 11:42:49 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAIJfOUb001549; Tue, 18 Nov 2008 14:41:28 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAIJepii028219; Tue, 18 Nov 2008 14:40:51 -0500 Date: Tue, 18 Nov 2008 14:40:51 -0500 Message-Id: <20081118143852.4c1c8157@cs.columbia.edu> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Steven M. Bellovin" To: Multiple recipients of list Subject: Re: Preimage attacks on CubeHash512-r/4 and CubeHash512-r/8 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Mime-Version: 1.0 X-Mailer: Claws Mail 3.6.1 (GTK+ 2.14.3; x86_64--netbsd) References: <20081118135449.233c2563@cs.columbia.edu> <4923156E.5010403@ellipticsemi.com> In-Reply-To: <4923156E.5010403@ellipticsemi.com> X-Cc: tstdenis@ellipticsemi.com X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 18 Nov 2008 11:42:49 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 167 On Tue, 18 Nov 2008 14:26:39 -0500 Tom St Denis wrote: > > Which raises the question "do we really need a 512-bit hash?" Of > course the answer is "not really." Actually, that isn't quite clear. A 512-bit hash has 256-bit strength against collisions. NSA's Suite B uses 256-bit AES for Top Secret, so the two match. (Well, NSA would settle for 192-bit AES, but for simplicity they upped it to 256.) Why so large? If a large quantum computer can be built, a brute-force attack on a 256-bit key would be O(2^128), and they want that to be out of reach. Going larger is questionable, though. --Steve Bellovin, http://www.cs.columbia.edu/~smb From hash-forum@nist.gov Tue Nov 18 12:12:27 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAIKCKRK025011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Nov 2008 12:12:23 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAIKAaRF004398; Tue, 18 Nov 2008 15:10:43 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAIK9O8f022521; Tue, 18 Nov 2008 15:09:24 -0500 Date: Tue, 18 Nov 2008 15:09:24 -0500 Message-Id: <49231E85.7040608@ellipticsemi.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Tom St Denis To: Multiple recipients of list Subject: Re: Preimage attacks on CubeHash512-r/4 and CubeHash512-r/8 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: <20081118143852.4c1c8157@cs.columbia.edu> References: <20081118135449.233c2563@cs.columbia.edu> <4923156E.5010403@ellipticsemi.com> <20081118143852.4c1c8157@cs.columbia.edu> MIME-Version: 1.0 X-CC: hash-forum@nist.gov X-To: "Steven M. Bellovin" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 18 Nov 2008 12:12:23 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 168 Steven M. Bellovin wrote: > On Tue, 18 Nov 2008 14:26:39 -0500 > Tom St Denis wrote: > > >> Which raises the question "do we really need a 512-bit hash?" Of >> course the answer is "not really." >> > > Actually, that isn't quite clear. A 512-bit hash has 256-bit strength > against collisions. NSA's Suite B uses 256-bit AES for Top Secret, so > the two match. (Well, NSA would settle for 192-bit AES, but for > simplicity they upped it to 256.) Why so large? If a large quantum > computer can be built, a brute-force attack on a 256-bit key would be > O(2^128), and they want that to be out of reach. > > Going larger is questionable, though. > That assumes that a circuit as complex as a hash could be constructed *and* you could run it for O(2^64) time (assuming a 128-bit key) without stability problems. It's probably not impossible to complete such a feat down the road, but so far it doesn't look possible. With that in mind, a 256-bit hash would be more than enough since cycle finding there would still take O(2^128) time (from what I understand Grover's algorithm is for searching an unsorted list). So a 256-bit keyed block cipher coupled with a 256-bit hash would provide "at least" 128-bits of security which is an insane amount anyways. From practical numbers, dnet took two years to find a 64-bit RC5-12 key. An 80-bit key is 65536 times harder to search. A 96-bit key would be 4 billion times harder, and so on. Even if you had a few orders of magnitude more MIPS it's still impractical/impossible to search a 96-bit key, let alone a 128-bit one (or a 256-bit one assuming you don't have a QC). I'm fine with the argument that QC is not to be ruled out, and therefore a 256-bit symmetric key seems like a good future proofing idea. But just because it's a round number more than anything else. A 192-bit key even with QC would be more than safe from searches, but from a technical standpoint it's easier to store a 32-byte key since it's a nice power of two in terms of storage. Tom From hash-forum@nist.gov Tue Nov 18 12:26:57 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAIKQoTB026665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Nov 2008 12:26:53 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAIKPO6D028498; Tue, 18 Nov 2008 15:25:30 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAIKOsBL021559; Tue, 18 Nov 2008 15:24:54 -0500 Date: Tue, 18 Nov 2008 15:24:54 -0500 Message-Id: <49232170.6030002@larc.usp.br> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Paulo S. L. M. Barreto" To: Multiple recipients of list Subject: Re: Preimage attacks on CubeHash512-r/4 and CubeHash512-r/8 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 In-Reply-To: <20081118143852.4c1c8157@cs.columbia.edu> References: <20081118135449.233c2563@cs.columbia.edu> <4923156E.5010403@ellipticsemi.com> <20081118143852.4c1c8157@cs.columbia.edu> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 18 Nov 2008 12:26:53 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 169 Steven M. Bellovin wrote: > On Tue, 18 Nov 2008 14:26:39 -0500 > Tom St Denis wrote: > >> Which raises the question "do we really need a 512-bit hash?" Of >> course the answer is "not really." > > Actually, that isn't quite clear. A 512-bit hash has 256-bit strength > against collisions. NSA's Suite B uses 256-bit AES for Top Secret, so > the two match. (Well, NSA would settle for 192-bit AES, but for > simplicity they upped it to 256.) Why so large? If a large quantum > computer can be built, a brute-force attack on a 256-bit key would be > O(2^128), and they want that to be out of reach. > > Going larger is questionable, though. Am I right in assuming you are criticizing the terms of NIST's SHA-3 call (section 4.A), whereby "NIST expects the SHA–3 algorithm of message digest size n to meet the following security requirements at a minimum [...] Preimage resistance of approximately n bits" ? Paulo. From hash-forum@nist.gov Tue Nov 18 12:55:58 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAIKtovC029507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Nov 2008 12:55:53 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAIKrb0r002277; Tue, 18 Nov 2008 15:53:43 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAIKqbHw013023; Tue, 18 Nov 2008 15:52:38 -0500 Date: Tue, 18 Nov 2008 15:52:37 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Helger Lipmaa To: Multiple recipients of list Subject: Re: Preimage attacks on CubeHash512-r/4 and CubeHash512-r/8 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed MIME-Version: 1.0 References: <20081118135449.233c2563@cs.columbia.edu> <4923156E.5010403@ellipticsemi.com> <20081118143852.4c1c8157@cs.columbia.edu> <49231E85.7040608@ellipticsemi.com> In-Reply-To: <49231E85.7040608@ellipticsemi.com> X-To: Multiple recipients of list X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 18 Nov 2008 12:55:54 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 170 Generic finding collisions on a quantum computer takes 2^{2n/3} time, see for example http://portal.acm.org/citation.cfm?id=1008731.1008735 Helger (new to this emailing list and still quite confused) On Tue, 18 Nov 2008, Tom St Denis wrote: > > Steven M. Bellovin wrote: >> On Tue, 18 Nov 2008 14:26:39 -0500 >> Tom St Denis wrote: >> >> >>> Which raises the question "do we really need a 512-bit hash?" Of >>> course the answer is "not really." >> >> Actually, that isn't quite clear. A 512-bit hash has 256-bit strength >> against collisions. NSA's Suite B uses 256-bit AES for Top Secret, so >> the two match. (Well, NSA would settle for 192-bit AES, but for >> simplicity they upped it to 256.) Why so large? If a large quantum >> computer can be built, a brute-force attack on a 256-bit key would be >> O(2^128), and they want that to be out of reach. >> >> Going larger is questionable, though. >> > That assumes that a circuit as complex as a hash could be constructed *and* > you could run it for O(2^64) time (assuming a 128-bit key) without stability > problems. It's probably not impossible to complete such a feat down the > road, but so far it doesn't look possible. > > With that in mind, a 256-bit hash would be more than enough since cycle > finding there would still take O(2^128) time (from what I understand Grover's > algorithm is for searching an unsorted list). So a 256-bit keyed block > cipher coupled with a 256-bit hash would provide "at least" 128-bits of > security which is an insane amount anyways. From practical numbers, dnet > took two years to find a 64-bit RC5-12 key. An 80-bit key is 65536 times > harder to search. A 96-bit key would be 4 billion times harder, and so on. > Even if you had a few orders of magnitude more MIPS it's still > impractical/impossible to search a 96-bit key, let alone a 128-bit one (or a > 256-bit one assuming you don't have a QC). > > I'm fine with the argument that QC is not to be ruled out, and therefore a > 256-bit symmetric key seems like a good future proofing idea. But just > because it's a round number more than anything else. A 192-bit key even with > QC would be more than safe from searches, but from a technical standpoint > it's easier to store a 32-byte key since it's a nice power of two in terms of > storage. > > Tom > From hash-forum@nist.gov Tue Nov 18 17:39:27 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJ1dLgg027616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Nov 2008 17:39:23 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJ1bfX1013866; Tue, 18 Nov 2008 20:37:46 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJ1aM0L014164; Tue, 18 Nov 2008 20:36:22 -0500 Date: Tue, 18 Nov 2008 20:36:22 -0500 Message-Id: <5edad67143ac9f27c85b9b45416a2e3c@www3.mail.volny.cz> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: v.klima@volny.cz To: Multiple recipients of list Subject: A multicollision attack on Edon-R X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Mailer: Volny.cz Webmail2 2.107 X-To: hash-forum@nist.gov MIME-Version: 1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 18 Nov 2008 17:39:23 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 171 Colleagues, we have found a multicollision attack on Edon-R (n = 256, 512). For finding 2^K multicollisions we need K * 2^{n/2} hash computations and 2^{n/2} memory. It is the same complexity as in the case of generic multicollisions attack on n-bit hash function with n-bit chaining value. Note that Edon-R has 2n-bit chaining value. You can find the preliminary version of the paper at http://cryptography.hyperlink.cz/BMW/EDONR_analysis_vk.pdf Best regards, Vlastimil Klima From hash-forum@nist.gov Tue Nov 18 22:33:50 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJ6XjFK017676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Nov 2008 22:33:46 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJ6WJBS024358; Wed, 19 Nov 2008 01:32:25 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJ6V2TI002357; Wed, 19 Nov 2008 01:31:02 -0500 Date: Wed, 19 Nov 2008 01:31:02 -0500 Message-Id: <4923B12D.1000702@mit.edu> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: David Wilson To: Multiple recipients of list Subject: Re: Preimage attacks on CubeHash512-r/4 and CubeHash512-r/8 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: <4923156E.5010403@ellipticsemi.com> References: <20081118135449.233c2563@cs.columbia.edu> <4923156E.5010403@ellipticsemi.com> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 18 Nov 2008 22:33:46 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 172 Tom St Denis wrote: > > Steven M. Bellovin wrote: >> >>> we have found preimage attacks ... >>> that require $2^{496}$ and $2^{480}$ computations >>> respectively and negligible memory. [...] > Which raises the question "do we really need a 512-bit hash?" Of course > the answer is "not really." Arguably, one of the reasons for such a hash is "insurance." Right now, it seems possible that with a distributed network one might be able to pull off the 2^{63} collision attack against SHA-1 (I understand this is currently being attempted). This is only a factor of 2^{17} better than brute force, yet it crosses the line into feasibility. By contrast, the 2^{32} improvement over brute force for CubeHash512-r/8 earns a back-of-the-envelope calculation from a Columbia professor suggesting that the solar system will be long gone before such an attack could possibly be mounted. :) QC fantasies aside, you are correct that a 256-bit hash would more than meet our needs if we could be completely assured that it was indeed an ideal hash function. But we don't have that assurance (at least not for any function with reasonable performance). If we did, I don't think we'd need a SHA-3 competition. My concern isn't about 2^{480} attacks, it's that someone finding a 2^{480} attack within a few weeks raises the question of whether or not they can refine their analysis to find a 2^{300} attack within a few months, and then a 2^{60} attack within a few years. (Note that I am not disparaging CubeHash with this hypothetical. Given that some parts of this attack were apparently already known to the designer, who then explicitly suggested setting the parameter b=1 instead of the b=4 or 8 that were analyzed, the answer to "whether or not" might well lean toward "not.") Regards, David Wilson From hash-forum@nist.gov Tue Nov 18 23:00:39 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJ70YmU019971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Nov 2008 23:00:35 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJ6xcVg025115; Wed, 19 Nov 2008 01:59:41 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJ6xDUI025368; Wed, 19 Nov 2008 01:59:13 -0500 Date: Wed, 19 Nov 2008 01:59:13 -0500 Message-Id: <9418DB6C0B9D434190E54A78E931C3D1086429A7@XCH-NW-7V1.nw.nos.boeing.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Bugbee, Larry" To: Multiple recipients of list Subject: do we really need a 512-bit hash was: Preimage attacks on CubeHash... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit X-To: References: <20081118135449.233c2563@cs.columbia.edu> <4923156E.5010403@ellipticsemi.com> <4923B12D.1000702@mit.edu> In-Reply-To: <4923B12D.1000702@mit.edu> Content-Type: text/plain; charset="US-ASCII" MIME-Version: 1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 18 Nov 2008 23:00:35 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 173 Tom St Denis wrote: > > Steven M. Bellovin wrote: >> >>> we have found preimage attacks ... >>> that require $2^{496}$ and $2^{480}$ computations respectively and >>> negligible memory. [...] > Which raises the question "do we really need a 512-bit hash?" Of > course the answer is "not really." I have to disagree, at least for some applications. We have some electronic "documents" that, under ideal conditions, are to be signed and retained for the "life-of-the-airplane" plus 50 years. ...and DC-3s are still flying. You can do the math. While we all know this won't happen, we do need to do the best we can. If we can find ways to push good integrity out 30+ years, perhaps our successors will find a way to extend it another 30 years. ...and so on. There are at least a half dozen possible schemes, each with their issues, but the most promising is a combination. One essential element, however, is to apply several very strong hashes signed with strong keys and algorithms. Besides strength, we want redundancy providing us with a window of time to re-group. It is not perfect, but we must do the best we can. We very much want to see several strong hash algorithms survive this competition. Their length is secondary. Larry From hash-forum@nist.gov Wed Nov 19 05:05:30 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJD5Pl3022730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 05:05:26 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJD3QLM022037; Wed, 19 Nov 2008 08:03:31 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJD1jlr028277; Wed, 19 Nov 2008 08:01:45 -0500 Date: Wed, 19 Nov 2008 08:01:45 -0500 Message-Id: <7731938b0811190451o17daedc1he99cc7bd102f47d1@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Peter Maxwell" To: Multiple recipients of list Subject: Re: do we really need a 512-bit hash was: Preimage attacks on CubeHash... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <20081118135449.233c2563@cs.columbia.edu> <4923156E.5010403@ellipticsemi.com> <4923B12D.1000702@mit.edu> <9418DB6C0B9D434190E54A78E931C3D1086429A7@XCH-NW-7V1.nw.nos.boeing.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 In-Reply-To: <9418DB6C0B9D434190E54A78E931C3D1086429A7@XCH-NW-7V1.nw.nos.boeing.com> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 05:05:27 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 174 I would think the necessity for a 512-bit digest would be that the maximum AES key size is 256-bits and a hash is susceptible to a birthday attack to generate collisions at 2^n/2 which for a 512-bit hash is 256-bits. So it is probably seen as equivalent security. 2008/11/19 Bugbee, Larry : > > Tom St Denis wrote: >> >> Steven M. Bellovin wrote: >>> >>>> we have found preimage attacks ... >>>> that require $2^{496}$ and $2^{480}$ computations respectively and >>>> negligible memory. > [...] >> Which raises the question "do we really need a 512-bit hash?" Of >> course the answer is "not really." > > I have to disagree, at least for some applications. We have some > electronic "documents" that, under ideal conditions, are to be signed > and retained for the "life-of-the-airplane" plus 50 years. ...and DC-3s > are still flying. You can do the math. > > While we all know this won't happen, we do need to do the best we can. > If we can find ways to push good integrity out 30+ years, perhaps our > successors will find a way to extend it another 30 years. ...and so on. > > There are at least a half dozen possible schemes, each with their > issues, but the most promising is a combination. One essential element, > however, is to apply several very strong hashes signed with strong keys > and algorithms. Besides strength, we want redundancy providing us with > a window of time to re-group. It is not perfect, but we must do the > best we can. > > We very much want to see several strong hash algorithms survive this > competition. Their length is secondary. > > Larry > > > From hash-forum@nist.gov Wed Nov 19 05:59:15 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJDx9Cj028164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 05:59:10 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJDvcZn010058; Wed, 19 Nov 2008 08:57:43 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJDv6mG011995; Wed, 19 Nov 2008 08:57:07 -0500 Date: Wed, 19 Nov 2008 08:57:06 -0500 Message-Id: <20081119084758.1ef0eb1d@cs.columbia.edu> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Steven M. Bellovin" To: Multiple recipients of list Subject: Re: Preimage attacks on CubeHash512-r/4 and CubeHash512-r/8 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Mime-Version: 1.0 X-Mailer: Claws Mail 3.6.1 (GTK+ 2.14.3; x86_64--netbsd) References: <20081118135449.233c2563@cs.columbia.edu> <4923156E.5010403@ellipticsemi.com> <20081118143852.4c1c8157@cs.columbia.edu> <49232170.6030002@larc.usp.br> In-Reply-To: <49232170.6030002@larc.usp.br> X-Cc: pbarreto@larc.usp.br X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 05:59:11 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 175 On Tue, 18 Nov 2008 15:24:54 -0500 "Paulo S. L. M. Barreto" wrote: > > Steven M. Bellovin wrote: > > On Tue, 18 Nov 2008 14:26:39 -0500 > > Tom St Denis wrote: > > > >> Which raises the question "do we really need a 512-bit hash?" Of > >> course the answer is "not really." > > > > Actually, that isn't quite clear. A 512-bit hash has 256-bit > > strength against collisions. NSA's Suite B uses 256-bit AES for > > Top Secret, so the two match. (Well, NSA would settle for 192-bit > > AES, but for simplicity they upped it to 256.) Why so large? If a > > large quantum computer can be built, a brute-force attack on a > > 256-bit key would be O(2^128), and they want that to be out of > > reach. > > > > Going larger is questionable, though. > > Am I right in assuming you are criticizing the terms of NIST's SHA-3 > call (section 4.A), whereby "NIST expects the SHA___3 algorithm of > message digest size n to meet the following security requirements at > a minimum [...] Preimage resistance of approximately n bits" ? > No. But NIST is going to have to make a decision at some point about what effort attack is at all indicative of trouble. I think that that's a useful topic for public discussion. --Steve Bellovin, http://www.cs.columbia.edu/~smb From hash-forum@nist.gov Wed Nov 19 05:59:15 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJDxAnK028169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 05:59:11 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJDvcZx010058; Wed, 19 Nov 2008 08:57:47 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJDvUZG013053; Wed, 19 Nov 2008 08:57:30 -0500 Date: Wed, 19 Nov 2008 08:57:30 -0500 Message-Id: <49241AE0.6060608@ellipticsemi.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Tom St Denis To: Multiple recipients of list Subject: Re: Preimage attacks on CubeHash512-r/4 and CubeHash512-r/8 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: <4923B12D.1000702@mit.edu> References: <20081118135449.233c2563@cs.columbia.edu> <4923156E.5010403@ellipticsemi.com> <4923B12D.1000702@mit.edu> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 05:59:12 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 176 David Wilson wrote: > Arguably, one of the reasons for such a hash is "insurance." Right > now, it seems possible that with a distributed network one might be > able to pull off the 2^{63} collision attack against SHA-1 (I > understand this is currently being attempted). This is only a factor > of 2^{17} better than brute force, yet it crosses the line into > feasibility. I thought the attacks against SHA-1 weren't on all 80 rounds? Eitherway, we do have SHA-2 for now. Hash digest size does not equate to strength though. You could just as easily have a 512-bit hash be less secure against collisions than a 64-bit hash. > QC fantasies aside, you are correct that a 256-bit hash would more > than meet our needs if we could be completely assured that it was > indeed an ideal hash function. But we don't have that assurance (at > least not for any function with reasonable performance). If we did, I > don't think we'd need a SHA-3 competition. Which misses the point that output size does not guarantee security. So why not just focus on more likely to be secure 256-bit [or smaller] primitives. Also misses the point that for MAC purposes computing large outputs just to truncate is a waste of effort. There is probably room for improvement in that domain. > My concern isn't about 2^{480} attacks, it's that someone finding a > 2^{480} attack within a few weeks raises the question of whether or > not they can refine their analysis to find a 2^{300} attack within a > few months, and then a 2^{60} attack within a few years. (Note that I > am not disparaging CubeHash with this hypothetical. Given that some > parts of this attack were apparently already known to the designer, > who then explicitly suggested setting the parameter b=1 instead of the > b=4 or 8 that were analyzed, the answer to "whether or not" might well > lean toward "not.") Well yeah, by that same token a 2^200 attack against a new 256-bit hash would equally be alarming (say against pre-images or whatever). But that doesn't mean larger is better. Tom From hash-forum@nist.gov Wed Nov 19 05:59:18 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJDxBXX028175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 05:59:12 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJDvlkS013760; Wed, 19 Nov 2008 08:57:51 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJDvXIS013083; Wed, 19 Nov 2008 08:57:33 -0500 Date: Wed, 19 Nov 2008 08:57:33 -0500 Message-Id: <49241B2D.1090408@ellipticsemi.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Tom St Denis To: Multiple recipients of list Subject: Re: do we really need a 512-bit hash was: Preimage attacks on CubeHash... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: <9418DB6C0B9D434190E54A78E931C3D1086429A7@XCH-NW-7V1.nw.nos.boeing.com> References: <20081118135449.233c2563@cs.columbia.edu> <4923156E.5010403@ellipticsemi.com> <4923B12D.1000702@mit.edu> <9418DB6C0B9D434190E54A78E931C3D1086429A7@XCH-NW-7V1.nw.nos.boeing.com> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 05:59:13 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 177 Bugbee, Larry wrote: > I have to disagree, at least for some applications. We have some > electronic "documents" that, under ideal conditions, are to be signed > and retained for the "life-of-the-airplane" plus 50 years. ...and DC-3s > are still flying. You can do the math. > > We very much want to see several strong hash algorithms survive this > competition. Their length is secondary. > So you disagree when I say "we don't need a 512-bit hash" but then say that length is of secondary importance? Output length does not equate to strength. Tom From hash-forum@nist.gov Wed Nov 19 06:13:19 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJEDEuu029948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 06:13:15 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJEBbqN018507; Wed, 19 Nov 2008 09:11:42 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJEBDdi008428; Wed, 19 Nov 2008 09:11:13 -0500 Date: Wed, 19 Nov 2008 09:11:13 -0500 Message-Id: <49241BFF.8000507@ellipticsemi.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Tom St Denis To: Multiple recipients of list Subject: Re: do we really need a 512-bit hash was: Preimage attacks on CubeHash... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: <7731938b0811190451o17daedc1he99cc7bd102f47d1@mail.gmail.com> References: <20081118135449.233c2563@cs.columbia.edu> <4923156E.5010403@ellipticsemi.com> <4923B12D.1000702@mit.edu> <9418DB6C0B9D434190E54A78E931C3D1086429A7@XCH-NW-7V1.nw.nos.boeing.com> <7731938b0811190451o17daedc1he99cc7bd102f47d1@mail.gmail.com> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 06:13:15 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 178 Peter Maxwell wrote: > I would think the necessity for a 512-bit digest would be that the > maximum AES key size is 256-bits and a hash is susceptible to a > birthday attack to generate collisions at 2^n/2 which for a 512-bit > hash is 256-bits. So it is probably seen as equivalent security. > Yeah, but do we even need AES-256? Realistically a 192-bit symmetric key is more than enough against normal and quantum computers. The only reason I'd favour 256 over 192 is that it's a nice round number (in binary) thus making hardware easier to design. But if you accept that QC is the future then AES-256 only has 128-bits of strength, not 256. They can't both be simultaneously true. Therefore, SHA-256 + AES-256 makes the more appropriate pairing. And even if QC is not possible on that scale, finding a collision in O(2^128) time isn't possible, therefore, the "added" security of SHA-512 over SHA-256 is non existent. Therefore, you're wasting resources computing the larger hash. Tom > > > 2008/11/19 Bugbee, Larry : > >> Tom St Denis wrote: >> >>> Steven M. Bellovin wrote: >>> >>>>> we have found preimage attacks ... >>>>> that require $2^{496}$ and $2^{480}$ computations respectively and >>>>> negligible memory. >>>>> >> [...] >> >>> Which raises the question "do we really need a 512-bit hash?" Of >>> course the answer is "not really." >>> >> I have to disagree, at least for some applications. We have some >> electronic "documents" that, under ideal conditions, are to be signed >> and retained for the "life-of-the-airplane" plus 50 years. ...and DC-3s >> are still flying. You can do the math. >> >> While we all know this won't happen, we do need to do the best we can. >> If we can find ways to push good integrity out 30+ years, perhaps our >> successors will find a way to extend it another 30 years. ...and so on. >> >> There are at least a half dozen possible schemes, each with their >> issues, but the most promising is a combination. One essential element, >> however, is to apply several very strong hashes signed with strong keys >> and algorithms. Besides strength, we want redundancy providing us with >> a window of time to re-group. It is not perfect, but we must do the >> best we can. >> >> We very much want to see several strong hash algorithms survive this >> competition. Their length is secondary. >> >> Larry >> >> >> >> > > > From hash-forum@nist.gov Wed Nov 19 06:13:24 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJEDJUT029963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 06:13:20 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJEBli8018560; Wed, 19 Nov 2008 09:11:53 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJEBZTs008915; Wed, 19 Nov 2008 09:11:35 -0500 Date: Wed, 19 Nov 2008 09:11:35 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Dmitry Khovratovich" To: Multiple recipients of list Subject: Re: Cryptanalysis of Edon-R X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <491dc202.130c420a.03ae.6ebd@mx.google.com> Content-Type: multipart/alternative; boundary="----=_Part_76571_9202667.1227102989385" MIME-Version: 1.0 In-Reply-To: <491dc202.130c420a.03ae.6ebd@mx.google.com> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 06:13:20 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 179 ------=_Part_76571_9202667.1227102989385 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Fri, Nov 14, 2008 at 7:27 PM, Danilo Gligoroski < danilo.gligoroski@gmail.com> wrote: > Hi Ivica, > > > > I am reading your attack. Nice work (in the part of free start pre-images= ) > but for real pre-image attacks, > > your attack is still not better than brute force attack. Actually it is > much worse. > > To find second pre-images you need 2^{2n/3} hash computations and 2^{2n/3= } > memory. > > > > So, I have cheaper attack on Edon-R that needs 2^{n-1} hash computation= s > and n bits of memory. > > > Yes, that is why we consider our analysis to be an attack: it takes much fewer computations than the brute force attack. We count the total complexity using the classical cryptanalysis approach. In this widely used approach (look at the proceedings of different conferences - Eurocrypt, FSE= , etc.) the attack complexity is usually measured in the number of computations. In various time-memory tradeoffs one can trade on either memory or time but not on the number of computations. The question of which approach is the correct one is still discussed. In th= e widespread approach Edon-R does not provide the n-bit security against preimage attacks as it was required by NIST. > Best regards, > > Danilo Gligoroski > > > > P.S. About your observations "we can invert the quasigroup operation Q(x; > y) with negligible effort." =96 As you say =96 it is indeed simple observ= ation > that is already given in the documentation. If you carefully read the > documentation in the part where we give attacks on Edon-R with local > collisions you will find the notation "left conjugates" and our attacks a= re > with complexity O(1). That means "with negligible effort" you can invert > quasigroup operations. > > > > > > > > > > > > *From:* hash-forum@nist.gov [mailto:hash-forum@nist.gov] *On Behalf Of *I= vica > Nikolic > *Sent:* Friday, November 14, 2008 3:20 PM > *To:* Multiple recipients of list > *Subject:* Cryptanalysis of Edon-R > > > > Hi all, > > we have found a preimage attack on Edon-R with complexity and memory > 2^{2n/3} for n-bit digests and various free start attacks (collisions, > (second) preimages) with negligible complexity. > The attacks are presented in our paper which is available at : > http://lj.streamclub.ru/papers/hash/edon-r.pdf > > Best regards, > Ivica Nikolic, Dmitry Khovratovich, Ralf-Philipp Weinmann > > Laboratory of Algorithms, Cryptography and Security, > University of Luxembourg, > Luxembourg > --=20 Best regards, Dmitry, Ivica ------=_Part_76571_9202667.1227102989385 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Fri, Nov 14, 2008 at 7:27 PM, Danilo Gligoroski <danilo.gligoroski@gmail.com> wrote:

Hi Ivica,

 <= /p>

I am reading y= our attack. Nice work (in the part of free start pre-images) but for real pre-image attacks,

your attack is= still not better than brute force attack. Actually it is much worse.

To find second= pre-images you need 2^{2n/3} hash computations and 2^{2n/3} memory.

 <= /p>

So, I have che= aper attack on Edon-R that needs  2^{n-1}  hash computations and n bits of memory.

 <= /p>

 Yes, that is why we consider our ana= lysis to be an attack: it takes much fewer computations than the brute forc= e attack. We count the total complexity using the classical cryptanalysis a= pproach. In this widely used approach (look at the proceedings of different= conferences - Eurocrypt, FSE, etc.) the attack complexity is usually measu= red in the number of computations.

In various time-memory tradeoffs one can trade on either memory or time= but not on the number of computations.

The question of which approa= ch is the correct one is still discussed. In the widespread approach  = Edon-R does not provide the n-bit security against preimage attacks as it w= as required by NIST. 

Best regards,<= /span>

Danilo Gligoro= ski

 <= /p>

P.S= About your observations "we can invert the quasigroup operation Q(x; y) with negligible effort." =96 As you say =96 it is indeed simple observation that is already given in the documentation. If you carefully re= ad the documentation in the part where we give attacks on Edon-R with local collisions you will find the notation "left conjugates" and our attacks are with complexity O(1). That means "with negligible effort" you can invert quasigroup operations.

 <= /p>

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: hash-forum@nist.gov [mailto:hash-forum= @nist.gov] On Behalf Of Ivica Nikolic
Sent: Friday, November 14, 2008 3:20 PM
To: Multiple recipients of list
Subject: Cryptanalysis of Edon-R

 

Hi all,

we have found a preimage attack on Edon-R with complexity and memory 2^{2n/= 3} for n-bit digests and various free start attacks (collisions, (second) preimages) with negligible complexity.
The attacks are presented in our paper which is available at :
http://lj.streamclub.ru/papers/hash/edon-r.pdf

Best regards,
Ivica Nikolic, Dmitry Khovratovich, Ralf-Philipp Weinmann

Laboratory of Algorithms, Cryptography and Security,
University of Luxembourg,
Luxembourg




--
Best regards,
Dmitry= , Ivica
------=_Part_76571_9202667.1227102989385-- From hash-forum@nist.gov Wed Nov 19 07:09:31 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJF9Plg004853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 07:09:27 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJF7cl3029163; Wed, 19 Nov 2008 10:07:45 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJF6c42025900; Wed, 19 Nov 2008 10:06:38 -0500 Date: Wed, 19 Nov 2008 10:06:38 -0500 Message-Id: <7731938b0811190655q38226f30yc868bb048406c28@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Peter Maxwell" To: Multiple recipients of list Subject: Re: do we really need a 512-bit hash was: Preimage attacks on CubeHash... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <20081118135449.233c2563@cs.columbia.edu> <4923156E.5010403@ellipticsemi.com> <4923B12D.1000702@mit.edu> <9418DB6C0B9D434190E54A78E931C3D1086429A7@XCH-NW-7V1.nw.nos.boeing.com> <7731938b0811190451o17daedc1he99cc7bd102f47d1@mail.gmail.com> <49241BFF.8000507@ellipticsemi.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 In-Reply-To: <49241BFF.8000507@ellipticsemi.com> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 07:09:27 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 180 2008/11/19 Tom St Denis : > Yeah, but do we even need AES-256? Realistically a 192-bit symmetric key is > more than enough against normal and quantum computers. The only reason I'd > favour 256 over 192 is that it's a nice round number (in binary) thus making > hardware easier to design. Yes, I would tend to agree, 256-bit is probably overkill but like a lot of technology: its there so we use it. Having said that the extra resources of implementing 256-bit keys as compared to 128-bit keys are in most applications irrelevant, so the over engineering might be worthwhile. Given the requirement that TOP SECRET needs 256-bit keys for AES it may suggest something, or again it may be hedging of bets. > But if you accept that QC is the future then AES-256 only has 128-bits of > strength, not 256. They can't both be simultaneously true. Therefore, > SHA-256 + AES-256 makes the more appropriate pairing. Not really having a good knowledge of quantum computing principles I can't really comment, but my intuition would be that algebraic attacks using GF(2) or even GF(2^8) will probably advance quicker. I would also guess that if that very effective algebraic attacks were ever possible then difference in key size would probably not matter a jot anyway. I'm not sure I follow your argument on why SHA-256 + AES-256 is a good pairing. Take the example of a digital signature scheme, the whole security is predicated on the collision resistance of the hash function - so a 256-bit digest can only give 128-bits of security, which makes it by a massive magnitude the weakest part of the construction. > And even if QC is not possible on that scale, finding a collision in > O(2^128) time isn't possible, therefore, the "added" security of SHA-512 > over SHA-256 is non existent. Therefore, you're wasting resources computing > the larger hash. > I think I've missed something, are you saying that is isn't possible to find a collision for a 256-bit digest algorithm with the equivalent to 128-bit work? Peter From hash-forum@nist.gov Wed Nov 19 07:09:41 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJF9ZpQ004876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 07:09:37 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJF7pAS021340; Wed, 19 Nov 2008 10:07:57 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJF7acd028392; Wed, 19 Nov 2008 10:07:36 -0500 Date: Wed, 19 Nov 2008 10:07:36 -0500 Message-Id: <20081119150346.72577.qmail@cr.yp.to> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "D. J. Bernstein" To: Multiple recipients of list Subject: Re: Preimage attacks on CubeHash512-r/4 and CubeHash512-r/8 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas In-Reply-To: <4923B12D.1000702@mit.edu> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 07:09:37 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 181 > Given that some parts of this attack were apparently already known to > the designer, Not just "some parts." The entire attack was described in detail in the "complexity of generic attacks" part of the CubeHash submission: This appendix comments in more detail on the complexity of standard generic attacks against CubeHashr/b, i.e., attacks that immediately generalize from CubeHash's r-round transformation to any invertible transformation T having the same 128-byte state size. ... Standard generic preimage attack: The attacker expands the h-bit target arbitrarily into a 128-byte final state Z, works backwards to an end-of-message state Y=..., and searches for collisions between the last 128-b bytes of ... and ..., obtaining a preimage ... Finding a preimage in this way means evaluating T approximately 2^{522-4b-lg b} times. As above, the chance of success drops off quadratically with fewer T evaluations. For example, if T is as fast as a single round of CubeHash, then a fantasy-universe attacker capable of 2^511 bit operations would be able to evaluate T 2^500 times, but still would have only about a 2^{-8} chance of breaking b=4 with these attacks. Note that the preimage attack is explicitly reduced to a collision search. Low-memory collision searches have been standard since Pollard's famous 1975 paper, and low-memory _parallel_ collision searches have been standard since the famous 1994 paper by van Oorschot and Wiener; but finding a collision in 1024-8b bits still takes a very long time for any reasonable value of b. The attack is also mentioned in the "analysis of attacks" part of the CubeHash submission: CubeHashr/b becomes very easy to break if b is very large. For example, CubeHashr/112 allows an attacker to use the last 112-byte block of input to freely adjust 112 of the 128 state bytes. This last-block ``message modification'' effectively reduces the influence of the previous input blocks to a ``narrow pipe'' of only 16 bytes, so the attacker has a reasonable chance of finding a collision after cycling through just 2^64 input messages. ... However, the attacker loses control over the state as b decreases. Generic attacks have success probability dropping exponentially with the ``pipe size'' 1024-8b. For example, CubeHashr/32 has a 768-bit pipe, putting generic attacks---including advanced attacks such as ``herding''---far out of reach. Both of these documents are (and were) on the "CubeHash submission" web page, http://cubehash.cr.yp.to/submission.html. Furthermore, the attack has always been mentioned on the "CubeHash security" web page, http://cubehash.cr.yp.to/security.html. The Nikolic--Khovratovich--Weinmann paper states the same attack (with various claims of novelty), states a low-memory collision-search algorithm (with reference to some 1992 paper instead of 1975 Pollard), and summarizes the attack cost as "2^496 computations" for b=4 (without saying what a "computation" is). > My concern isn't about 2^{480} attacks, it's that someone finding a > 2^{480} attack within a few weeks raises the question of whether or not > they can refine their analysis to find a 2^{300} attack within a few > months, and then a 2^{60} attack within a few years. Wow. What do you think about people who found the attack within a few _minutes_ by simply reading the CubeHash web pages? CubeHash was designed to fit into 1024 bits of memory, with no extra space for counters, buffers, etc. This inevitably allows generic narrow-pipe attacks somewhere in the 2^512 stratosphere. Increasing the CubeHash block size b produces standard speedups in these attacks, as explained in the CubeHash submission. I don't claim novelty for any of this; I think that most people here already understand pipe sizes! ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago From hash-forum@nist.gov Wed Nov 19 07:23:07 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJFN0J6005925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 07:23:01 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJFLdhg031212; Wed, 19 Nov 2008 10:21:45 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJFL8ED023788; Wed, 19 Nov 2008 10:21:08 -0500 Date: Wed, 19 Nov 2008 10:21:08 -0500 Message-Id: <49242c44.1e068e0a.047c.523e@mx.google.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Danilo Gligoroski" To: Multiple recipients of list Subject: Current progres of the cryptanalysis of Edon-R X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Microsoft Office Outlook 12.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 In-Reply-To: <7731938b0811190451o17daedc1he99cc7bd102f47d1@mail.gmail.com> References: <20081118135449.233c2563@cs.columbia.edu> <4923156E.5010403@ellipticsemi.com> <4923B12D.1000702@mit.edu> <9418DB6C0B9D434190E54A78E931C3D1086429A7@XCH-NW-7V1.nw.nos.boeing.com> <7731938b0811190451o17daedc1he99cc7bd102f47d1@mail.gmail.com> X-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 07:23:01 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 182 Hi all, Edon-R is the fastest SHA-3 candidate in the SHA-3-Zoo, has very simple algebraic description, and some provable properties against differential analysis. Naturally it attracted attention from cryptographers. 1. The analysis from Khovratovic and Nikolic found pseudo-collisions in Edon-R. Although for me as one of Edon-R's designers it was very unpleasant news, a closer look at their attack tells us that the actual second preimage attack on Edon-R (using the weakness of pseudo-collisions) is more costly than generic brute force attack. Their attack can be avoided in Edon-R if there are additional one or two rounds in the middle of the computation of the compression function R. Well, it will decrease the speed of Edon-R from 2.40 cycles/byte (with the newest Intel C++ v11.0) to 3.20 cycles/byte, BUT my dilemma is - should I think to defend (to tweak) the hash function from an attack that in the literature is treated as "... an overall pseudo-collision is not always of practical concern since most hash functions specify a fixed IV." - HAC, page 372. Additionally, NIST in their competition call are not mentioning pseudo-collision attack anywhere. The opinion from other cryptographers on this matter is highly appreciated. 2. The work of Khovratovic and Nikolic is partly overlapped by another excellent analysis of Edon-R made by Klima. Klima is representing the compression function in a very clear graphical way which I expect to provoke further research in Edon-R (strengths and weaknesses). The findings of Klima are that Edon-R is "almost" as ordinary strengthened MD design. That "almost" is in the small additional factor of 2^65 to the generic multicollision attack. That additional factor of just 2^65 hash computations is the consequence of Merkle-Damgaard strengthening. I would say - in Klima's analysis we see very concretely the Merkle-Damgaard strengthening in action. And that provokes a natural idea for tweaking: Instead of working with maximum 2^64 bits long messages, make Edon-R to work with 2^128 bits long messages. It will make the Klima's attack to need additional work-factor of 2^128 hash computations. BUT, again, my dilemma is should I change anything in Edon-R when the multicollision attack needs 2^n/2 + 2^65 computations and 2^n/2 memory. The opinion from colleagues-cryptographers on this matter is highly appreciated. Best regards, Prof. Danilo Gligoroski From hash-forum@nist.gov Wed Nov 19 07:23:03 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJFMw5u005914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 07:22:59 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJFLdhq031212; Wed, 19 Nov 2008 10:21:47 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJFLSBh024778; Wed, 19 Nov 2008 10:21:28 -0500 Date: Wed, 19 Nov 2008 10:21:28 -0500 Message-Id: <49242e79.1c048e0a.182d.2c5a@mx.google.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Danilo Gligoroski" To: Multiple recipients of list Subject: RE: Cryptanalysis of Edon-R X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Microsoft Office Outlook 12.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0169_01C94A62.92612420" MIME-Version: 1.0 In-Reply-To: References: <491dc202.130c420a.03ae.6ebd@mx.google.com> X-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 07:23:00 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 183 This is a multipart message in MIME format. ------=_NextPart_000_0169_01C94A62.92612420 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > Yes, that is why we consider our analysis to be an attack: it takes much fewer computations than the brute force attack. Fewer computations?!!?! What are you doing with the 2^2n/3 memory? You are searching it? Right? And that is for you "no computation". Who is covering the cost of "no computation" in memory? OK - how costly is your "no computation" in memory? Another interesting term in your post: "widespread approach". From the discussions in this and other forums I can say that at least that "widespeadness" that you are mentioning is 50:50 (if not less in favour of your approach). Best regards, Danilo! ------=_NextPart_000_0169_01C94A62.92612420 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> Yes, = that is why we consider our analysis to be an attack: it takes much fewer = computations than the brute force attack.

 

Fewer computations?!!?! What are you doing with the = 2^2n/3 memory?

You are searching it? Right? And that is for you = “no computation”.

 

Who is covering the cost of “no computation” = in memory?

 

OK – how costly is your “no = computation” in memory?

 

 

Another interesting term in your post: = “widespread approach”. From the discussions in this and other forums I = can say that

at least that “widespeadness” that you are = mentioning is 50:50 (if not less in favour of your approach).

 

Best regards,

Danilo!

 

------=_NextPart_000_0169_01C94A62.92612420-- From hash-forum@nist.gov Wed Nov 19 07:51:01 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJFotPs008628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 07:50:57 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJFnVKo006827; Wed, 19 Nov 2008 10:49:39 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJFnEVZ022966; Wed, 19 Nov 2008 10:49:14 -0500 Date: Wed, 19 Nov 2008 10:49:14 -0500 Message-Id: <4924343E.2080708@ellipticsemi.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Tom St Denis To: Multiple recipients of list Subject: Re: do we really need a 512-bit hash was: Preimage attacks on CubeHash... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: <7731938b0811190655q38226f30yc868bb048406c28@mail.gmail.com> References: <20081118135449.233c2563@cs.columbia.edu> <4923156E.5010403@ellipticsemi.com> <4923B12D.1000702@mit.edu> <9418DB6C0B9D434190E54A78E931C3D1086429A7@XCH-NW-7V1.nw.nos.boeing.com> <7731938b0811190451o17daedc1he99cc7bd102f47d1@mail.gmail.com> <49241BFF.8000507@ellipticsemi.com> <7731938b0811190655q38226f30yc868bb048406c28@mail.gmail.com> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 07:50:57 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 184 Peter Maxwell wrote: > 2008/11/19 Tom St Denis : > > >> Yeah, but do we even need AES-256? Realistically a 192-bit symmetric key is >> more than enough against normal and quantum computers. The only reason I'd >> favour 256 over 192 is that it's a nice round number (in binary) thus making >> hardware easier to design. >> > > Yes, I would tend to agree, 256-bit is probably overkill but like a > lot of technology: its there so we use it. Having said that the extra > resources of implementing 256-bit keys as compared to 128-bit keys are > in most applications irrelevant, so the over engineering might be > worthwhile. Given the requirement that TOP SECRET needs 256-bit keys > for AES it may suggest something, or again it may be hedging of bets. > Well I'm willing to grant that QC *may* be a practical threat against 128-bit keys sometime in the not distant future. That would make at least 192-bit keys seem prudent. And like I said I'd argue for 256 over 192 just due to rounding issues alone (if you're going to waste 8 bytes of space might as well be key data). "More secure than secure" line of thinking just boggles my mind. You can't brute force a 96-bit secret. You just can't. So the idea that 97-bits is "more secure" is meaningless. If by that logic 97-bits isn't more secure than 96, than neither is 98, 99, 100, ..., 128, ... 256. Take dnet for example, even if you suppose that computing doubles in power every 18 months (which it won't) indefinitely, it'd still be 48 years before brute forcing a 96-bit secret is computable in a 2 years span. But that would also mean having 2^32 the power as the mid 2000s, by comparison we're really only about ~2048x the power of a 1980s computer (assuming single core). So we've jumped up 12-bits, 14-bits if you allow for higher end quad-cores. That's in a 28 year span. And largely for the last 10 years things have plateaued quite a bit. Cores are still in the 2-3GHz range, roughly have the same MIPS, just consume less power, and there are more cores. So we're already 4-bits behind where we should be under the "doubles every 18 months" guide. Assuming that 20nm is the bottom end of practical limits (physically, not just technologically) we're already half-way there. So density is only likely to increase 2x maybe 3x so long as we make chips out of the same technology. That's an extra 2-bits (to be generous). Core design might get more efficient (fewer stalls, higher IPC) that's maybe another couple of bits. So all in all you're looking at plateauing at maybe 16 to 64 times faster than what we have now in terms of realistic performance gains. That means what? You can brute force a 70-bit key in 2 years on a 2020 computer? Big deal. Even if you move to dedicated hardware the improvement is still trivial. A typical AES core can do 1 round per cycle at say 500-600MHz, which is roughly "4 cycles/round" when scaled up to 2GHz like your typical desktop. Even then, if you say your typical AES-128 implementation takes 256 cycles on a processor, that's only a 6.4x improvement in hardware. So an extra 3 bits. In a core that is a 1000 times smaller, an extra 10 bits. So you're upto an 83-bit key by 2020 in 20nm tech taking 2 years to break. There isn't room for improvement as you can't physically make smaller transistors, and you can't really do better than 1 round/cycle (the path is a bit long otherwise). Short of having more chips. But at this point you'd have over 100K chips, so to say get upto 96-bits you'd need 8192 times that or 819,200,000 chips (each with say 500 cores or so) running 10-cycle AES at max clock rate. I know this is fast and loose with the math, but let's be realistic. We're already fairly high up there on the small scale transistors, they're not going to get much smaller. And we're talking about a 4 billion times improvement in efficiency required to make a 96-bit break realistic. Imagine if we used 128-bit keys! Now can you kinda get why I think "added bits" != "added security" once you get past a certain point? > Not really having a good knowledge of quantum computing principles I > can't really comment, but my intuition would be that algebraic attacks > using GF(2) or even GF(2^8) will probably advance quicker. I would > also guess that if that very effective algebraic attacks were ever > possible then difference in key size would probably not matter a jot > anyway. > But that's not key-size that's round #s. Would AES-256 with 128 0-bits be weaker or stronger than AES-128? > I'm not sure I follow your argument on why SHA-256 + AES-256 is a good > pairing. Take the example of a digital signature scheme, the whole > security is predicated on the collision resistance of the hash > function - so a 256-bit digest can only give 128-bits of security, > which makes it by a massive magnitude the weakest part of the > construction. > But you *can't* compute O(2^128) work. It's a meaningless to say that SHA-512 is more secure than SHA-256 solely predicated on the cycle finding attacks. My reasons are simply as follows 1. Assume QC is likely to happen 2. You need at least 96-bits of security to prevent brute force (or cycle finding) 3. Therefore you need at least 192-bits of key to resist brute force [against QC] 4. QC against SHA-256 takes at least O(2^128) time 5. Same for AES-256 Therefore, since AES-256 + SHA-256 provides more than 96-bits of security they're a secure pairing. I realize *why* people designed SHA-512 and why they think it's a good idea, but that doesn't make it so. Tom From hash-forum@nist.gov Wed Nov 19 07:51:03 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJFovMI008640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 07:50:59 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJFnJqM022647; Wed, 19 Nov 2008 10:49:24 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJFmpSg022126; Wed, 19 Nov 2008 10:48:51 -0500 Date: Wed, 19 Nov 2008 10:48:51 -0500 Message-Id: <72CF8F2B2766084DBD7AEAFCAE4A3B790909CCBA@frsnprexc1.usr.ingenico.loc> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Thomas PEYRIN" To: Multiple recipients of list Subject: RE: Current progres of the cryptanalysis of Edon-R X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-To: References: <20081118135449.233c2563@cs.columbia.edu> <4923156E.5010403@ellipticsemi.com> <4923B12D.1000702@mit.edu> <9418DB6C0B9D434190E54A78E931C3D1086429A7@XCH-NW-7V1.nw.nos.boeing.com> <7731938b0811190451o17daedc1he99cc7bd102f47d1@mail.gmail.com> <49242c44.1e068e0a.047c.523e@mx.google.com> Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C94A5C.B003CE7E" MIME-Version: 1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 07:50:59 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 185 This is a multi-part message in MIME format. ------_=_NextPart_001_01C94A5C.B003CE7E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well, it will decrease the speed of Edon-R from 2.40 cycles/byte (with the newest Intel C++ v11.0) to 3.20 cycles/byte, BUT my dilemma is - should I think to defend (to tweak) the hash function from an attack that in the literature is treated as "... an overall pseudo-collision is not always of practical concern since most hash functions specify a fixed IV." - HAC, page 372. Additionally, NIST in their competition call are not mentioning pseudo-collision attack anywhere.=20 =20 =20 A pseudo-collision attack on a compression function invalidates the assumption for the "Merkle-Damgard" collision resistance proof. Indeed, a pseudo-collision attack on the compression function doesn't necessarily imply a collision attack on the whole hash function ... but that implies that you have no more valid proof of security regarding your domain extension algorithm. =20 Thomas. =20 About Ingenico Throughout the world businesses rely on Ingenico for = secure and expedient electronic transaction acceptance. Ingenico = products leverage proven technology, established standards and = unparalleled ergonomics to provide optimal reliability, versatility and = usability. This comprehensive range of products is complemented by a = global array of services and partnerships, enabling businesses in a = number of vertical sectors to accept transactions anywhere their = business takes them. www.ingenico.com This message may contain confidential and/or privileged = information. If you are not the addressee or authorized to receive this = for the addressee, you must not use, copy, disclose or take any action = based on this message or any information herein. If you have received = this message in error, please advise the sender immediately by reply = e-mail and delete this message. Thank you for your cooperation. ------_=_NextPart_001_01C94A5C.B003CE7E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Well, it will decrease the speed = of Edon-R from 2.40 cycles/byte (with the newest Intel C++ v11.0) to 3.20 = cycles/byte, BUT my dilemma is - should I think to defend (to tweak) the hash = function from an attack that in the literature is treated as "... an overall pseudo-collision is not always of practical concern since most hash =  functions specify a fixed IV." - HAC, page 372. Additionally, NIST in their competition call are not mentioning

pseudo-collision attack = anywhere.

 

 

A pseudo-collision = attack on a compression function invalidates the assumption for the = “Merkle-Damgard” collision resistance proof. Indeed, a pseudo-collision attack on the = compression function doesn’t necessarily imply a collision attack on the whole = hash function … but that implies that you have no more valid proof of = security regarding your domain extension algorithm.

 

Thomas.

 

 

 
About Ingenico = Throughout the world businesses rely on Ingenico = for secure and expedient electronic transaction acceptance. Ingenico = products leverage proven technology, established standards and = unparalleled ergonomics to provide optimal reliability, versatility and = usability. This comprehensive range of products is complemented by a = global array of services and partnerships, enabling businesses in a = number of vertical sectors to accept transactions anywhere their = business takes them.
www.ingenico.com

This message may contain confidential and/or privileged information. = If you are not the addressee or authorized to receive this for the = addressee, you must not use, copy, disclose or take any action based on = this message or any information herein. If you have received this = message in error, please advise the sender immediately by reply e-mail = and delete this message. Thank you for your cooperation.
------_=_NextPart_001_01C94A5C.B003CE7E-- From hash-forum@nist.gov Wed Nov 19 08:06:13 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJG66Li010708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 08:06:08 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJG4dm8020759; Wed, 19 Nov 2008 11:04:45 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJG3R4O021513; Wed, 19 Nov 2008 11:03:27 -0500 Date: Wed, 19 Nov 2008 11:03:27 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Dmitry Khovratovich" To: Multiple recipients of list Subject: Re: Cryptanalysis of Edon-R X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <491dc202.130c420a.03ae.6ebd@mx.google.com> <49242e79.1c048e0a.182d.2c5a@mx.google.com> Content-Type: multipart/alternative; boundary="----=_Part_77746_13445979.1227110274453" MIME-Version: 1.0 In-Reply-To: <49242e79.1c048e0a.182d.2c5a@mx.google.com> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 08:06:09 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 186 ------=_Part_77746_13445979.1227110274453 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wed, Nov 19, 2008 at 4:21 PM, Danilo Gligoroski < danilo.gligoroski@gmail.com> wrote: > > Yes, that is why we consider our analysis to be an attack: it takes > much fewer computations than the brute force attack. > > > > Fewer computations?!!?! What are you doing with the 2^2n/3 memory? > > You are searching it? Right? And that is for you "no computation". > Well, binary search can be done in ~lg n trials. It is not zero but negligible compared to n. > Another interesting term in your post: "widespread approach". From the > discussions in this and other forums I can say that > > at least that "widespeadness" that you are mentioning is 50:50 (if not less > in favour of your approach). > The "widespreadness" is defined not by forums but by the state of the art. I would be interested to look at the 50 percent of papers on cryptanalysis that do not give priority to the number of computations when measuring the complexity. > > > Best regards, > > Danilo! > > > -- Best regards, Dmitry Khovratovich ------=_Part_77746_13445979.1227110274453 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Wed, Nov 19, 2008 at 4:21 PM, Danilo Gligoroski <danilo.gligoroski@gmail.com> wrote:

> Yes, that is why we consider our analysis to be an attack: it takes much fewer computations than the brute force attack.

 

Fewer computations?!!?! What are you doing with the 2^2n/3 memory?

You are searching it? Right? And that is for you "no computation".


Well, binary search can be done in ~lg n trials. It is not zero but negligible compared to n.
 

Another interesting term in your post: "widespread approach". From the discussions in this and other forums I can say that

at least that "widespeadness" that you are mentioning is 50:50 (if not less in favour of your approach).


The "widespreadness" is defined not by forums but by the state of the art. I would be interested to look at the 50 percent of papers on cryptanalysis that do not give priority to the number of computations when measuring the complexity.
 

 

Best regards,

Danilo!

 




--
Best regards,
Dmitry Khovratovich
------=_Part_77746_13445979.1227110274453-- From hash-forum@NIST.GOV Wed Nov 19 08:06:18 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJG6CNg010724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 08:06:14 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJG4oRH020802; Wed, 19 Nov 2008 11:04:54 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJG4Vgf023372; Wed, 19 Nov 2008 11:04:31 -0500 Date: Wed, 19 Nov 2008 11:04:31 -0500 Message-Id: Errors-To: sara@NIST.GOV Reply-To: hash-forum@NIST.GOV Originator: hash-forum@nist.gov Sender: hash-forum@NIST.GOV Precedence: bulk From: "Dmitry Khovratovich" To: Multiple recipients of list Subject: Re: Preimage attacks on CubeHash512-r/4 and CubeHash512-r/8 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <4923B12D.1000702@mit.edu> <20081119150346.72577.qmail@cr.yp.to> Content-Type: multipart/alternative; boundary="----=_Part_77756_4121339.1227110418355" MIME-Version: 1.0 In-Reply-To: <20081119150346.72577.qmail@cr.yp.to> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 08:06:14 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 187 ------=_Part_77756_4121339.1227110418355 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wed, Nov 19, 2008 at 4:07 PM, D. J. Bernstein wrote: > > > CubeHash was designed to fit into 1024 bits of memory, with no extra > space for counters, buffers, etc. This inevitably allows generic > narrow-pipe attacks somewhere in the 2^512 stratosphere. Increasing the > CubeHash block size b produces standard speedups in these attacks, as > explained in the CubeHash submission. I don't claim novelty for any of > this; I think that most people here already understand pipe sizes! > Does it imply that CubeHash does not fit the n-bit security requirement against preimage attacks? If the answer is different for different versions - which versions do? > > ---D. J. Bernstein > Research Professor, Computer Science, University of Illinois at Chicago > > -- Best regards, Dmitry Khovratovich ------=_Part_77756_4121339.1227110418355 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Wed, Nov 19, 2008 at 4:07 PM, D. J. Bernstein <djb@cr.yp.to> wrote:


CubeHash was designed to fit into 1024 bits of memory, with no extra
space for counters, buffers, etc. This inevitably allows generic
narrow-pipe attacks somewhere in the 2^512 stratosphere. Increasing the
CubeHash block size b produces standard speedups in these attacks, as
explained in the CubeHash submission. I don't claim novelty for any of
this; I think that most people here already understand pipe sizes!

Does it imply that CubeHash does not fit the n-bit security requirement against preimage attacks? If the answer is different for different versions - which versions do?
 

---D. J. Bernstein
  Research Professor, Computer Science, University of Illinois at Chicago




--
Best regards,
Dmitry Khovratovich
------=_Part_77756_4121339.1227110418355-- From hash-forum@nist.gov Wed Nov 19 08:20:34 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJGKSND012056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 08:20:30 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJGJAUd020103; Wed, 19 Nov 2008 11:19:16 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJGIcI1021158; Wed, 19 Nov 2008 11:18:38 -0500 Date: Wed, 19 Nov 2008 11:18:38 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Jonathan Katz To: Multiple recipients of list Subject: quantum computers and collision attacks X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 08:20:31 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 188 Just to clarify, quantum computers can find collisions in an n-bit hash in time 2^{n/3}. This can serve as justification for why a 256-bit hash would not be sufficient (though a 512-bit hash leaves a large safety margin even in this case...). (Apologies if this goes through twice; I was having problems with my email.) On Tue, Nov 18, 2008 at 3:52 PM, Helger Lipmaa wrote: > > Generic finding collisions on a quantum computer takes 2^{2n/3} time, see > for example http://portal.acm.org/citation.cfm?id=1008731.1008735 > > Helger > (new to this emailing list and still quite confused) From hash-forum@nist.gov Wed Nov 19 08:48:34 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJGmSwD015480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 08:48:30 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJGko5L006539; Wed, 19 Nov 2008 11:46:56 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJGkIJ8013298; Wed, 19 Nov 2008 11:46:18 -0500 Date: Wed, 19 Nov 2008 11:46:18 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Karan, Cem (Civ, ARL/CISD)" To: Multiple recipients of list Subject: RE: do we really need a 512-bit hash was: Preimage attacks on CubeHash... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit X-To: References: <20081118135449.233c2563@cs.columbia.edu> <4923156E.5010403@ellipticsemi.com> <4923B12D.1000702@mit.edu> <9418DB6C0B9D434190E54A78E931C3D1086429A7@XCH-NW-7V1.nw.nos.boeing.com> <7731938b0811190451o17daedc1he99cc7bd102f47d1@mail.gmail.com> <49241BFF.8000507@ellipticsemi.com> In-Reply-To: <49241BFF.8000507@ellipticsemi.com> Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 08:48:30 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 189 On Wednesday, November 19, 2008 9:11 AM Tom St Denis wrote: > Peter Maxwell wrote: > > I would think the necessity for a 512-bit digest would be that the > > maximum AES key size is 256-bits and a hash is susceptible to a > > birthday attack to generate collisions at 2^n/2 which for a 512-bit > > hash is 256-bits. So it is probably seen as equivalent security. > > > Yeah, but do we even need AES-256? Realistically a 192-bit > symmetric key is more than enough against normal and quantum > computers. The only reason I'd favour 256 over 192 is that > it's a nice round number (in > binary) thus making hardware easier to design. > > But if you accept that QC is the future then AES-256 only has > 128-bits of strength, not 256. They can't both be > simultaneously true. > Therefore, SHA-256 + AES-256 makes the more appropriate pairing. > > And even if QC is not possible on that scale, finding a collision in > O(2^128) time isn't possible, therefore, the "added" security > of SHA-512 over SHA-256 is non existent. Therefore, you're > wasting resources computing the larger hash. I tend to see it as future proofing against new attacks we don't know about. Going back to SHA-1, if there was no attack better than brute force, we wouldn't really need to be doing anything here. The various members of the SHA-2 family may eventually start to suffer attacks that don't break them 100%, but weaken them to the point that a brute force search over whatever bits that aren't broken can be searched over in a reasonable time frame. And, yes, I know that that sounds like I'm arguing length == security; you're right they are NOT equal. But until someone can create a proof demonstrating the actual, guaranteed security against all possible attacks, known and unknown of a hash, length is one more tool in the arsenal. Thanks, Cem Karan From hash-forum@nist.gov Wed Nov 19 08:48:37 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJGmU1S015489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 08:48:32 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJGko5V006539; Wed, 19 Nov 2008 11:46:58 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJGkhrv014039; Wed, 19 Nov 2008 11:46:43 -0500 Date: Wed, 19 Nov 2008 11:46:43 -0500 Message-Id: <7731938b0811190838j22333ad1hae6b8ce8a4ecaccb@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Peter Maxwell" To: Multiple recipients of list Subject: Re: do we really need a 512-bit hash was: Preimage attacks on CubeHash... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <20081118135449.233c2563@cs.columbia.edu> <4923156E.5010403@ellipticsemi.com> <4923B12D.1000702@mit.edu> <9418DB6C0B9D434190E54A78E931C3D1086429A7@XCH-NW-7V1.nw.nos.boeing.com> <7731938b0811190451o17daedc1he99cc7bd102f47d1@mail.gmail.com> <49241BFF.8000507@ellipticsemi.com> <7731938b0811190655q38226f30yc868bb048406c28@mail.gmail.com> <4924343E.2080708@ellipticsemi.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 In-Reply-To: <4924343E.2080708@ellipticsemi.com> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 08:48:32 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 190 2008/11/19 Tom St Denis : > > Peter Maxwell wrote: >> >> 2008/11/19 Tom St Denis : >> >> >>> >>> Yeah, but do we even need AES-256? Realistically a 192-bit symmetric key >>> is >>> more than enough against normal and quantum computers. The only reason >>> I'd >>> favour 256 over 192 is that it's a nice round number (in binary) thus >>> making >>> hardware easier to design. >>> >> >> Yes, I would tend to agree, 256-bit is probably overkill but like a >> lot of technology: its there so we use it. Having said that the extra >> resources of implementing 256-bit keys as compared to 128-bit keys are >> in most applications irrelevant, so the over engineering might be >> worthwhile. Given the requirement that TOP SECRET needs 256-bit keys >> for AES it may suggest something, or again it may be hedging of bets. >> > > Well I'm willing to grant that QC *may* be a practical threat against > 128-bit keys sometime in the not distant future. That would make at least > 192-bit keys seem prudent. And like I said I'd argue for 256 over 192 just > due to rounding issues alone (if you're going to waste 8 bytes of space > might as well be key data). > > "More secure than secure" line of thinking just boggles my mind. You can't > brute force a 96-bit secret. You just can't. So the idea that 97-bits is > "more secure" is meaningless. If by that logic 97-bits isn't more secure > than 96, than neither is 98, 99, 100, ..., 128, ... 256. > Take dnet for example, even if you suppose that computing doubles in power > every 18 months (which it won't) indefinitely, it'd still be 48 years before > brute forcing a 96-bit secret is computable in a 2 years span. But that > would also mean having 2^32 the power as the mid 2000s, by comparison we're > really only about ~2048x the power of a 1980s computer (assuming single > core). So we've jumped up 12-bits, 14-bits if you allow for higher end > quad-cores. That's in a 28 year span. And largely for the last 10 years > things have plateaued quite a bit. Cores are still in the 2-3GHz range, > roughly have the same MIPS, just consume less power, and there are more > cores. So we're already 4-bits behind where we should be under the "doubles > every 18 months" guide. > > Assuming that 20nm is the bottom end of practical limits (physically, not > just technologically) we're already half-way there. So density is only > likely to increase 2x maybe 3x so long as we make chips out of the same > technology. That's an extra 2-bits (to be generous). Core design might get > more efficient (fewer stalls, higher IPC) that's maybe another couple of > bits. So all in all you're looking at plateauing at maybe 16 to 64 times > faster than what we have now in terms of realistic performance gains. That > means what? You can brute force a 70-bit key in 2 years on a 2020 computer? > Big deal. > > Even if you move to dedicated hardware the improvement is still trivial. A > typical AES core can do 1 round per cycle at say 500-600MHz, which is > roughly "4 cycles/round" when scaled up to 2GHz like your typical desktop. > Even then, if you say your typical AES-128 implementation takes 256 cycles > on a processor, that's only a 6.4x improvement in hardware. So an extra 3 > bits. In a core that is a 1000 times smaller, an extra 10 bits. So you're > upto an 83-bit key by 2020 in 20nm tech taking 2 years to break. There > isn't room for improvement as you can't physically make smaller transistors, > and you can't really do better than 1 round/cycle (the path is a bit long > otherwise). Short of having more chips. But at this point you'd have over > 100K chips, so to say get upto 96-bits you'd need 8192 times that or > 819,200,000 chips (each with say 500 cores or so) running 10-cycle AES at > max clock rate. > I know this is fast and loose with the math, but let's be realistic. We're > already fairly high up there on the small scale transistors, they're not > going to get much smaller. And we're talking about a 4 billion times > improvement in efficiency required to make a 96-bit break realistic. > Imagine if we used 128-bit keys! > > Now can you kinda get why I think "added bits" != "added security" once you > get past a certain point? I completely agree with you that computing power hasn't got a snowball's chance in hell of being able to brute force even a 128-bit key. The way I see it is that any increase in key space is an attempt to ameliorate the effects of any future advances in cryptanalysis, it might end up being a futile attempt but again the actual cost is pretty small so why not. Personally, if the key size were to be 256-bits instead of 128-bits I would prefer the block size to match, but that's another topic entirely. > >> Not really having a good knowledge of quantum computing principles I >> can't really comment, but my intuition would be that algebraic attacks >> using GF(2) or even GF(2^8) will probably advance quicker. I would >> also guess that if that very effective algebraic attacks were ever >> possible then difference in key size would probably not matter a jot >> anyway. >> > > But that's not key-size that's round #s. Would AES-256 with 128 0-bits be > weaker or stronger than AES-128? > Depends whether you know in advance which bits were fixed to zero ;-) I would guess (anyone with experience in algebraic techniques feel free to correct me) that if you increase the key size from 128-bits to 256-bits then you'd see a corresponding increase in the number of free variables. From what I've read, most current techniques rely on creating a representative overdetermined system of linear equations by substituting for quadratic pairs. If the number of initial variables has increased then you'd need at least a polynomial increase in the number of linear equations to create an overdetermined system - so in that sense you would realise a real improvement in security. As regards to the number of rounds, I would imagine that any increase would increase the highest algebraic degree and hence also increase the number of linear equations necessary. I could have got the wrong end of the stick here and be talking complete non-sense, but that's my current understanding. >> I'm not sure I follow your argument on why SHA-256 + AES-256 is a good >> pairing. Take the example of a digital signature scheme, the whole >> security is predicated on the collision resistance of the hash >> function - so a 256-bit digest can only give 128-bits of security, >> which makes it by a massive magnitude the weakest part of the >> construction. >> > > But you *can't* compute O(2^128) work. It's a meaningless to say that > SHA-512 is more secure than SHA-256 solely predicated on the cycle finding > attacks. > > My reasons are simply as follows > > 1. Assume QC is likely to happen > 2. You need at least 96-bits of security to prevent brute force (or cycle > finding) > 3. Therefore you need at least 192-bits of key to resist brute force > [against QC] > 4. QC against SHA-256 takes at least O(2^128) time Given that in a normal block-cipher scenario a quantum computer would effectively half the key size - would this apply in a collision attack which already has the n/2 generic birthday attack (which would give it n/4 = 2^64 in a quantim computing scenario)? Given that a fair number of hash algorithms are based on a block-cipher design I would instinctivly think that, but I would need to read a bit more to make any real assertion. > 5. Same for AES-256 > > Therefore, since AES-256 + SHA-256 provides more than 96-bits of security > they're a secure pairing. > > I realize *why* people designed SHA-512 and why they think it's a good idea, > but that doesn't make it so. > > Tom > > Peter From hash-forum@nist.gov Wed Nov 19 09:02:46 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJH2eVp017495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 09:02:41 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJH12i2015610; Wed, 19 Nov 2008 12:01:09 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJH0YdS010635; Wed, 19 Nov 2008 12:00:34 -0500 Date: Wed, 19 Nov 2008 12:00:34 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Hal Finney" To: Multiple recipients of list Subject: Re: do we really need a 512-bit hash was: Preimage attacks on CubeHash... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <20081118135449.233c2563@cs.columbia.edu> <4923156E.5010403@ellipticsemi.com> <4923B12D.1000702@mit.edu> <9418DB6C0B9D434190E54A78E931C3D1086429A7@XCH-NW-7V1.nw.nos.boeing.com> <7731938b0811190451o17daedc1he99cc7bd102f47d1@mail.gmail.com> <49241BFF.8000507@ellipticsemi.com> <7731938b0811190655q38226f30yc868bb048406c28@mail.gmail.com> <4924343E.2080708@ellipticsemi.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 In-Reply-To: <4924343E.2080708@ellipticsemi.com> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 09:02:42 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 191 You can't just linearly extrapolate current computing trends in a security evaluation. You need to look at technologies which might plausibly come into existence which could present threats to your security. Eric Drexler sketched a design for a mechanical nanocomputer in his book Nanosystems, in the 1990s. http://www.e-drexler.com/d/06/00/Nanosystems/toc.html He concludes "a 1000 MIPS computer can occupy less than one cubic micron and consume less than 0.1 microwatt of power" (http://www.e-drexler.com/d/06/00/Nanosystems/ch1/chapter1_8.html). He has also presented ideas for self-assembly of nanomechanical systems, which would allow, for example, large volumes of material to be turned into nanocomputers or other devices, cheaply and automatically. A cubic kilometer of devices such as he describes can execute 2^120 instructions per second, allowing brute forcing of 128 bit keys. Much more speculatively, If you could create a quantum computer of the size and speed of Drexler's nanocomputer, and put together a cubic kilometer of them, you could brute force a 256 bit key in a matter of hours, consuming 1e8 terawatts. This kind of technology would be game-changing, if it comes into existence. Progress towards nanotechnology can be tracked on sites like nanodot.org. Of course there is never any certainty as to what path the future will take, but in threat analysis we need to at least consider worst case conditions. Mechanical nanotech can hardly be ruled out within the time frame when current cryptographic standards may still be in use. An adequate threat model must consider the possibility that brute forcing keys on the order of 100-200 bits will be technologically possible within a few decades. Hal Finney From hash-forum@nist.gov Wed Nov 19 09:02:45 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJH2dFY017491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 09:02:41 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJH1BQF003707; Wed, 19 Nov 2008 12:01:17 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJH0uXn011374; Wed, 19 Nov 2008 12:00:56 -0500 Date: Wed, 19 Nov 2008 12:00:56 -0500 Message-Id: <7731938b0811190847l10eab8c3s8f1c3f33c081a95e@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Peter Maxwell" To: Multiple recipients of list Subject: Re: Current progres of the cryptanalysis of Edon-R X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <20081118135449.233c2563@cs.columbia.edu> <4923156E.5010403@ellipticsemi.com> <4923B12D.1000702@mit.edu> <9418DB6C0B9D434190E54A78E931C3D1086429A7@XCH-NW-7V1.nw.nos.boeing.com> <7731938b0811190451o17daedc1he99cc7bd102f47d1@mail.gmail.com> <49242c44.1e068e0a.047c.523e@mx.google.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 In-Reply-To: <49242c44.1e068e0a.047c.523e@mx.google.com> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 09:02:41 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 192 In reference to your question 1... Personally, I would have severe reservations of using an algorithm that has demonstratable pseudo-collisions. I had to read twice there, 2.4 cycles/byte, that is pretty darn fast! Also, I doubt anyone would really worry about that going up to 3.2 cycles/byte and probably a fair bit more. If it was me I'd add the extra rounds - why risk loss of confidence for what is really a very small performance hit (I know in percentage terms it looks bad, but on absolute terms is very little). Peter From hash-forum@nist.gov Wed Nov 19 09:04:23 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJH4HjE017638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 09:04:19 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJH1BQP003707; Wed, 19 Nov 2008 12:01:20 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJH0xrj011396; Wed, 19 Nov 2008 12:00:59 -0500 Date: Wed, 19 Nov 2008 12:00:59 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Helger Lipmaa To: Multiple recipients of list Subject: Re: quantum computers and collision attacks X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed MIME-Version: 1.0 References: In-Reply-To: X-To: Multiple recipients of list X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 09:04:19 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 193 Yes, sorry - that was a typo. The email was meant to clarify that in the case of QC, hash length actually has to be larger than imagined. Helger On Wed, 19 Nov 2008, Jonathan Katz wrote: > > Just to clarify, quantum computers can find collisions in an n-bit > hash in time 2^{n/3}. This can serve as justification for why a 256-bit hash > would not be sufficient (though a 512-bit hash leaves a large safety margin > even in this case...). > > (Apologies if this goes through twice; I was having problems with my email.) > > On Tue, Nov 18, 2008 at 3:52 PM, Helger Lipmaa > wrote: >> >> Generic finding collisions on a quantum computer takes 2^{2n/3} time, > see >> for example http://portal.acm.org/citation.cfm?id=1008731.1008735 >> >> Helger >> (new to this emailing list and still quite confused) > From hash-forum@nist.gov Wed Nov 19 09:31:13 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJHV8Qc020685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 09:31:09 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJHTLIA024848; Wed, 19 Nov 2008 12:29:29 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJHTC8a003712; Wed, 19 Nov 2008 12:29:12 -0500 Date: Wed, 19 Nov 2008 12:29:12 -0500 Message-Id: <49244ABB.8030807@mit.edu> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: David Wilson To: Multiple recipients of list Subject: Re: Preimage attacks on CubeHash512-r/4 and CubeHash512-r/8 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: <20081119150346.72577.qmail@cr.yp.to> References: <20081119150346.72577.qmail@cr.yp.to> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 09:31:10 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 194 D. J. Bernstein wrote: >> Given that some parts of this attack were apparently already known to >> the designer, > > Not just "some parts." The entire attack was described in detail in the > "complexity of generic attacks" part of the CubeHash submission: My apologies; I had seen the claim that the attack used less memory than suggested in the submission, but didn't know the details. Thanks for the explanation. [...] >> My concern isn't about 2^{480} attacks, it's that someone finding a >> 2^{480} attack within a few weeks raises the question of whether or not >> they can refine their analysis to find a 2^{300} attack within a few >> months, and then a 2^{60} attack within a few years. > > Wow. What do you think about people who found the attack within a few > _minutes_ by simply reading the CubeHash web pages? In the parenthetical that immediately followed in my original mail, I explained why I *didn't* think this was necessarily true of CubeHash (namely, that this had been explicitly acknowledged and dealt with in the original submission by recommending b=1). More generally, though, I wasn't trying to make a point about CubeHash, but rather about hash functions in general, using the numbers from this recent analysis as an example--and all I said was it "raises the question" about further attacks. If someone can come up with a good argument for why 2^{480} is the lower bound for a particular type of attack on a particular hash function, I'd be fine with using it myself. (I would, however, wonder if NIST would find it acceptable, given section 4.A.iii of the Federal Register notice.) David Wilson From hash-forum@nist.gov Wed Nov 19 09:31:14 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJHV9bx020689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 09:31:10 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJHTLI0024848; Wed, 19 Nov 2008 12:29:27 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJHSYfR002840; Wed, 19 Nov 2008 12:28:34 -0500 Date: Wed, 19 Nov 2008 12:28:34 -0500 Message-Id: <49244A32.5090106@larc.usp.br> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Paulo S. L. M. Barreto" To: Multiple recipients of list Subject: Re: quantum computers and collision attacks X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 In-Reply-To: References: MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 09:31:10 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 195 Jonathan Katz wrote: > Just to clarify, quantum computers can find collisions in an n-bit > hash in time 2^{n/3}. An additional information is that the Brassard-Hoyer-Tapp algorithm takes 2^{n/3} quantum memory as well. I'm only unsure about the number of quantum gates needed (shame on me), but it seems reasonable to guess it's not worse than the above figures. Paulo. From hash-forum@nist.gov Wed Nov 19 10:54:53 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJIsiIi031391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 10:54:46 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJIpsCa007876; Wed, 19 Nov 2008 13:52:05 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJIoXQ7006563; Wed, 19 Nov 2008 13:50:33 -0500 Date: Wed, 19 Nov 2008 13:50:33 -0500 Message-Id: <49245f3b.2006420a.11c6.ffffb7e0@mx.google.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Danilo Gligoroski" To: Multiple recipients of list Subject: RE: Cryptanalysis of Edon-R X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Microsoft Office Outlook 12.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0190_01C94A7F.A0CE33A0" MIME-Version: 1.0 In-Reply-To: References: <491dc202.130c420a.03ae.6ebd@mx.google.com> <49242e79.1c048e0a.182d.2c5a@mx.google.com> X-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 10:54:47 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 196 This is a multipart message in MIME format. ------=_NextPart_000_0190_01C94A7F.A0CE33A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >>> Yes, that is why we consider our analysis to be an attack: it takes much fewer computations than the brute force attack. >>Fewer computations?!!?! What are you doing with the 2^2n/3 memory? >>You are searching it? Right? And that is for you "no computation". >Well, binary search can be done in ~lg n trials. It is not zero but negligible compared to n. Excellent! Binary search! Are you aware how much time, CPU cycles, energy, and put whatever measure you want, you need to do a binary search on a structure with 2^170 elements? You can stick with your theoretical ~ lg n - but that measuring just counts levels of the binary tree. It does not measure the SPEED of your search. The real measuring would give you that you are spending orders of magnitude more time in your "binary search of 2^170 elements" than simple re-computation of hash values. At the end your "computations" will overcome dramatically simple brute force attack. Another interesting term in your post: "widespread approach". From the discussions in this and other forums I can say that at least that "widespeadness" that you are mentioning is 50:50 (if not less in favour of your approach). >The "widespreadness" is defined not by forums but by the state of the art. I would be interested to look at the 50 percent of papers on cryptanalysis that do not give >priority to the number of computations when measuring the complexity. The state of the art in cryptanalysis is to give fair treatment both to number of computations and memory requirements of the attacks. And that approach is mostly because cryptographers had long discussions with cryptanalysts - about time-memory trade off issues. More particularly for this hash competition. NIST were very careful in the wording for the security requirements: Collision resistance of approximately n/2 bits, Preimage resistance of approximately n bits, Second-preimage resistance of approximately n-k bits for any message shorter than 2^k bits, They are not giving any priority to the "number of computations when measuring the complexity". Best regards, Danilo! ------=_NextPart_000_0190_01C94A7F.A0CE33A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>>> Yes, that is why we consider our analysis to be an attack: it takes much = fewer computations than the brute force attack.

 

>>Fewer computations?!!?! What = are you doing with the 2^2n/3 memory?

>>You are searching it? Right? = And that is for you "no computation".


>Well, binary search can be done = in ~lg n trials. It is not zero but negligible compared to n.

 

Excellent! Binary search! Are you aware how much time, = CPU cycles, energy, and put whatever measure you want, =

you need to do a binary search on a structure with 2^170 elements?  You can stick with your theoretical ~ lg n – but = that

measuring just counts levels of the binary tree. It does = not measure the SPEED of your search.

 

The real measuring would give you that you are spending = orders of magnitude more time in your “binary search of 2^170 = elements”

than simple re-computation of hash values. At the end = your “computations” will overcome dramatically simple brute force = attack.

 

 

 

Another interesting = term in your post: "widespread approach". From the discussions in this and other forums I = can say that

at least that "widespeadness" that you are mentioning is 50:50 (if not less = in favour of your approach).


>The "widespreadness" = is defined not by forums but by the state of the art. I would be interested = to look at the 50 percent of papers on cryptanalysis that do not give >priority to the number of = computations when measuring the complexity.
 

 

The state of the art in cryptanalysis is to give fair = treatment both to number of computations and memory requirements of the attacks. And = that approach is mostly because cryptographers had long discussions with cryptanalysts – about time-memory trade off = issues.

 

More particularly for this hash competition. NIST were = very careful in the wording for the security requirements:

 

           = ;            = Collision resistance of approximately n/2 bits,

           = ;            = Preimage resistance of approximately n bits,

           = ;            = Second-preimage resistance of approximately n-k bits for any message shorter than = 2^k bits,

 

They are not giving any priority to the = “number of computations when measuring the complexity”.

 

Best regards,

Danilo!

------=_NextPart_000_0190_01C94A7F.A0CE33A0-- From hash-forum@nist.gov Wed Nov 19 11:08:32 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJJ8Nl6001356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 11:08:25 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJJ6Pvs018690; Wed, 19 Nov 2008 14:06:32 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJJ5Llu004530; Wed, 19 Nov 2008 14:05:21 -0500 Date: Wed, 19 Nov 2008 14:05:21 -0500 Message-Id: <49246193.130c420a.6490.ffffc777@mx.google.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Danilo Gligoroski" To: Multiple recipients of list Subject: RE: Current progres of the cryptanalysis of Edon-R X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Microsoft Office Outlook 12.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0198_01C94A81.06873290" MIME-Version: 1.0 In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B790909CCBA@frsnprexc1.usr.ingenico.loc> References: <20081118135449.233c2563@cs.columbia.edu> <4923156E.5010403@ellipticsemi.com> <4923B12D.1000702@mit.edu> <9418DB6C0B9D434190E54A78E931C3D1086429A7@XCH-NW-7V1.nw.nos.boeing.com> <7731938b0811190451o17daedc1he99cc7bd102f47d1@mail.gmail.com> <49242c44.1e068e0a.047c.523e@mx.google.com> <72CF8F2B2766084DBD7AEAFCAE4A3B790909CCBA@frsnprexc1.usr.ingenico.loc> X-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 11:08:26 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 197 This is a multipart message in MIME format. ------=_NextPart_000_0198_01C94A81.06873290 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Well, it will decrease the speed of Edon-R from 2.40 cycles/byte (with the newest Intel C++ v11.0) to 3.20 cycles/byte, BUT my dilemma is - should I think to defend (to tweak) the hash function from an attack that in the literature is treated as "... an overall pseudo-collision is not always of practical concern since most hash functions specify a fixed IV." - HAC, page 372. Additionally, NIST in their competition call are not mentioning pseudo-collision attack anywhere. A pseudo-collision attack on a compression function invalidates the assumption for the "Merkle-Damgard" collision resistance proof. Indeed, a pseudo-collision attack on the compression function doesn't necessarily imply a collision attack on the whole hash function . but that implies that you have no more valid proof of security regarding your domain extension algorithm. Thomas. Thank you Thomas. Very good point. But the dilemma whether to think to tweak Edon-R is still present. Why? Because Edon-R if you look it trough the Klima's reduction is classical n-bit MD construction which is pseudo-collision resistant. So we still can use the benefits of the MD collision resistance proof. Namely, Klima's attack is "orthogonal" to Khovratovich-Nikolic attack. The variables that you keep constant in Klima's attack in order to reduce the function from 2n to n-pipe, have to be "free" in Khovratovich-Nikolic attack in order to get pseudo collisions for the 2n-pipe version. Best regards, Danilo! ------=_NextPart_000_0198_01C94A81.06873290 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Well, it will decrease the speed of Edon-R from 2.40 cycles/byte (with the newest = Intel C++ v11.0) to 3.20 cycles/byte, BUT my dilemma is - should I think to defend = (to tweak) the hash function from an attack that in the literature is = treated as "... an overall pseudo-collision is not always of practical concern = since most hash  functions specify a fixed IV." - HAC, page 372. Additionally, NIST in their competition call are not = mentioning

pseudo-collision attack anywhere.

 

 

A = pseudo-collision attack on a compression function invalidates the assumption for the “Merkle-Damgard” collision resistance proof. Indeed, a pseudo-collision attack on the compression function doesn’t = necessarily imply a collision attack on the whole hash function … but that = implies that you have no more valid proof of security regarding your domain = extension algorithm.

 

Thomas.

 

 

 

Thank you Thomas.

Very good point.

 

But the dilemma whether to think to tweak Edon-R is still present. Why?

Because Edon-R if you look it trough the Klima’s = reduction is classical n-bit MD construction which

is pseudo-collision resistant. So we still can use the = benefits of the MD collision resistance proof.

Namely, Klima’s attack is “orthogonal” = to Khovratovich-Nikolic attack. The variables that you keep

constant in Klima’s attack in order to reduce the = function from 2n to n-pipe, have to be “free” in =

Khovratovich-Nikolic attack in order to get pseudo = collisions for the 2n-pipe version.

 

Best regards,

Danilo!

 

 

------=_NextPart_000_0198_01C94A81.06873290-- From hash-forum@nist.gov Wed Nov 19 11:08:49 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJJ8iQe001442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 11:08:45 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJJ6ZFP018713; Wed, 19 Nov 2008 14:06:41 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJJ6Nt2006460; Wed, 19 Nov 2008 14:06:23 -0500 Date: Wed, 19 Nov 2008 14:06:23 -0500 Message-Id: <492462c7.1e70420a.28ca.ffffc6cb@mx.google.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Danilo Gligoroski" To: Multiple recipients of list Subject: RE: Current progres of the cryptanalysis of Edon-R X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Microsoft Office Outlook 12.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 In-Reply-To: <7731938b0811190847l10eab8c3s8f1c3f33c081a95e@mail.gmail.com> References: <20081118135449.233c2563@cs.columbia.edu> <4923156E.5010403@ellipticsemi.com> <4923B12D.1000702@mit.edu> <9418DB6C0B9D434190E54A78E931C3D1086429A7@XCH-NW-7V1.nw.nos.boeing.com> <7731938b0811190451o17daedc1he99cc7bd102f47d1@mail.gmail.com> <49242c44.1e068e0a.047c.523e@mx.google.com> <7731938b0811190847l10eab8c3s8f1c3f33c081a95e@mail.gmail.com> X-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 11:08:45 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 198 In reference to your question 1... Personally, I would have severe reservations of using an algorithm that has demonstratable pseudo-collisions. I had to read twice there, 2.4 cycles/byte, that is pretty darn fast! Also, I doubt anyone would really worry about that going up to 3.2 cycles/byte and probably a fair bit more. If it was me I'd add the extra rounds - why risk loss of confidence for what is really a very small performance hit (I know in percentage terms it looks bad, but on absolute terms is very little). Peter Thank you Peter, I appreciate your opinion. At the end (whatever is the fait of this hash function) I will consider all collected opinions from this forum. Best regards, Danilo! From hash-forum@nist.gov Wed Nov 19 11:22:14 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJJM7uG003100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 11:22:09 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJJKsEt026666; Wed, 19 Nov 2008 14:21:01 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJJKWn1006613; Wed, 19 Nov 2008 14:20:32 -0500 Date: Wed, 19 Nov 2008 14:20:32 -0500 Message-Id: <49246687.2040501@mit.edu> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Ronald L. Rivest" To: Multiple recipients of list Subject: Re: Cryptanalysis of Edon-R X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=windows-1252; format=flowed In-Reply-To: <49245f3b.2006420a.11c6.ffffb7e0@mx.google.com> References: <491dc202.130c420a.03ae.6ebd@mx.google.com> <49242e79.1c048e0a.182d.2c5a@mx.google.com> <49245f3b.2006420a.11c6.ffffb7e0@mx.google.com> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 11:22:10 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 199 I would think that an "interesting" or "significant" attack on a proposed hash function would be one that was more effective than what one could mount against a hypothetical "ideal" hash function that required the same volume/power/circuitry to implement as the proposal. Do these attacks qualify as significant in this metric? Digressing: binary search on 2**170 elements is an interesting notion. If each element took 1 cubic nanometer to store, then the storage would occupy a cube 10**17 meters on a side. It takes light over ten years to traverse such a volume... (mutter mutter Schwarzchild radius mutter mutter...) Cheers, Ron On 11/19/2008 1:50 PM, Danilo Gligoroski wrote: >> >> Yes, that is why we consider our analysis to be an attack: it takes > much fewer computations than the brute force attack. > > > >> >Fewer computations?!!?! What are you doing with the 2^2n/3 memory? > >> >You are searching it? Right? And that is for you "no computation". > > >>Well, binary search can be done in ~lg n trials. It is not zero but > negligible compared to n. > > > > Excellent! Binary search! Are you aware how much time, CPU cycles, > energy, and put whatever measure you want, > > you need to do a binary search on a structure with 2^170 elements? You > can stick with your theoretical ~ lg n – but that > > measuring just counts levels of the binary tree. It does not measure the > SPEED of your search. > > > > The real measuring would give you that you are spending orders of > magnitude more time in your “binary search of 2^170 elements” > > than simple re-computation of hash values. At the end your > “computations” will overcome dramatically simple brute force attack. > > > > > > > > Another interesting term in your post: "widespread approach". From > the discussions in this and other forums I can say that > > at least that "widespeadness" that you are mentioning is 50:50 (if > not less in favour of your approach). > > >>The "widespreadness" is defined not by forums but by the state of the > art. I would be interested to look at the 50 percent of papers on > cryptanalysis that do not give >priority to the number of computations > when measuring the complexity. > > > > > The state of the art in cryptanalysis is to give fair treatment both to > number of computations and memory requirements of the attacks. And that > approach is mostly because cryptographers had long discussions with > cryptanalysts – about time-memory trade off issues. > > > > More particularly for this hash competition. NIST were very careful in > the wording for the security requirements: > > > > Collision resistance of approximately /n//2 bits, > > Preimage resistance of approximately /n /bits, > > Second-preimage resistance of approximately /n-k > /bits for any message shorter than 2^/k /bits, > > > > They are not giving any priority to the “number of computations when > measuring the complexity”. > > > > Best regards, > > Danilo! > -- Ronald L. Rivest Room 32-G692, Stata Center, MIT, Cambridge MA 02139 Tel 617-253-5880, Email From hash-forum@nist.gov Wed Nov 19 12:05:25 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJK5JR4008207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 12:05:21 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJK3Zlj016270; Wed, 19 Nov 2008 15:03:41 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJK1vVK029879; Wed, 19 Nov 2008 15:01:57 -0500 Date: Wed, 19 Nov 2008 15:01:57 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Hal Finney" To: Multiple recipients of list Subject: Re: Cryptanalysis of Edon-R X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <491dc202.130c420a.03ae.6ebd@mx.google.com> <49242e79.1c048e0a.182d.2c5a@mx.google.com> <49245f3b.2006420a.11c6.ffffb7e0@mx.google.com> <49246687.2040501@mit.edu> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 In-Reply-To: <49246687.2040501@mit.edu> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 12:05:21 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 200 On Wed, Nov 19, 2008 at 11:20 AM, Ronald L. Rivest wrote: > Digressing: binary search on 2**170 elements is an interesting > notion. If each element took 1 cubic nanometer to store, then > the storage would occupy a cube 10**17 meters on a side. It takes > light over ten years to traverse such a volume... > (mutter mutter Schwarzchild radius mutter mutter...) Maybe not quite so bad as this; I think you dropped a factor of 10**9. 2**170 is 10**51 elements, requiring 10**17 UNITS on a side, not meters. With nanometer size units then it is 10**8 meters on a side, or 10**5 kilometers. This happens to be approximately the diameter of the Earth. So all you have to do is to convert the entire Earth into a nanotech storage array and you're all set. Hal Finney From hash-forum@nist.gov Wed Nov 19 12:05:25 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJK5KJg008214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 12:05:21 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJK3jFg018038; Wed, 19 Nov 2008 15:03:49 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJK3Rci001199; Wed, 19 Nov 2008 15:03:27 -0500 Date: Wed, 19 Nov 2008 15:03:27 -0500 Message-Id: <50676.201.95.58.20.1227124059.squirrel@webmail.larc.usp.br> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Paulo S. L. M. Barreto" To: Multiple recipients of list Subject: Re: Cryptanalysis of Edon-R X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain;charset=iso-8859-1 MIME-Version: 1.0 X-To: hash-forum@nist.gov References: <491dc202.130c420a.03ae.6ebd@mx.google.com> <49242e79.1c048e0a.182d.2c5a@mx.google.com> <49245f3b.2006420a.11c6.ffffb7e0@mx.google.com> <49246687.2040501@mit.edu> In-Reply-To: <49246687.2040501@mit.edu> X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 12:05:22 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 201 On Wed, November 19, 2008 17:20, Ronald L. Rivest said: > Digressing: binary search on 2**170 elements is an interesting > notion. If each element took 1 cubic nanometer to store, then > the storage would occupy a cube 10**17 meters on a side. It takes > light over ten years to traverse such a volume... > (mutter mutter Schwarzschild radius mutter mutter...) Never mind a black hole. If you can store a bit in a hydrogen atom (say, by distinguishing between the two states of its hyperfine structure) you "only" need 1/3 the mass of the Earth for 2^170 bits, or about twice the mass of Saturn to store the same amount of 512-bit hash values ;-) Paulo. From hash-forum@nist.gov Wed Nov 19 12:10:44 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJKAc0b008780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 12:10:40 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJK3Zlt016270; Wed, 19 Nov 2008 15:03:43 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJK3NFH001149; Wed, 19 Nov 2008 15:03:23 -0500 Date: Wed, 19 Nov 2008 15:03:23 -0500 Message-Id: <98EBB542F32B9D4CBB1EC5FE1D93D45B1644E1A266@ES02SNLNT.srn.sandia.gov> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Schroeppel, Richard" To: Multiple recipients of list Subject: RE: Cryptanalysis of Edon-R X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 In-Reply-To: <49246687.2040501@mit.edu> References: <491dc202.130c420a.03ae.6ebd@mx.google.com> <49242e79.1c048e0a.182d.2c5a@mx.google.com> <49245f3b.2006420a.11c6.ffffb7e0@mx.google.com> <49246687.2040501@mit.edu> X-Cc: "'rcs@xmission.com'" X-cc: "Schroeppel, Richard" , X-To: "'hash-forum@nist.gov'" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 12:10:40 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 202 Prefetch. -----Original Message----- From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Ronald L. Rivest Sent: Wednesday, November 19, 2008 12:21 PM To: Multiple recipients of list Subject: Re: Cryptanalysis of Edon-R I would think that an "interesting" or "significant" attack on a proposed hash function would be one that was more effective than what one could mount against a hypothetical "ideal" hash function that required the same volume/power/circuitry to implement as the proposal. Do these attacks qualify as significant in this metric? Digressing: binary search on 2**170 elements is an interesting notion. If each element took 1 cubic nanometer to store, then the storage would occupy a cube 10**17 meters on a side. It takes light over ten years to traverse such a volume... (mutter mutter Schwarzchild radius mutter mutter...) Cheers, Ron On 11/19/2008 1:50 PM, Danilo Gligoroski wrote: >> >> Yes, that is why we consider our analysis to be an attack: it >> >> takes > much fewer computations than the brute force attack. > > > >> >Fewer computations?!!?! What are you doing with the 2^2n/3 memory? > >> >You are searching it? Right? And that is for you "no computation". > > >>Well, binary search can be done in ~lg n trials. It is not zero but > negligible compared to n. > > > > Excellent! Binary search! Are you aware how much time, CPU cycles, > energy, and put whatever measure you want, > > you need to do a binary search on a structure with 2^170 elements? > You can stick with your theoretical ~ lg n - but that > > measuring just counts levels of the binary tree. It does not measure > the SPEED of your search. > > > > The real measuring would give you that you are spending orders of > magnitude more time in your "binary search of 2^170 elements" > > than simple re-computation of hash values. At the end your > "computations" will overcome dramatically simple brute force attack. > > > > > > > > Another interesting term in your post: "widespread approach". From > the discussions in this and other forums I can say that > > at least that "widespeadness" that you are mentioning is 50:50 (if > not less in favour of your approach). > > >>The "widespreadness" is defined not by forums but by the state of the > art. I would be interested to look at the 50 percent of papers on > cryptanalysis that do not give >priority to the number of computations > when measuring the complexity. > > > > > The state of the art in cryptanalysis is to give fair treatment both > to number of computations and memory requirements of the attacks. And > that approach is mostly because cryptographers had long discussions > with cryptanalysts - about time-memory trade off issues. > > > > More particularly for this hash competition. NIST were very careful in > the wording for the security requirements: > > > > Collision resistance of approximately /n//2 > bits, > > Preimage resistance of approximately /n /bits, > > Second-preimage resistance of approximately > /n-k /bits for any message shorter than 2^/k /bits, > > > > They are not giving any priority to the "number of computations when > measuring the complexity". > > > > Best regards, > > Danilo! > -- Ronald L. Rivest Room 32-G692, Stata Center, MIT, Cambridge MA 02139 Tel 617-253-5880, Email From hash-forum@nist.gov Wed Nov 19 13:14:46 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJLEfaA015206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 13:14:42 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJLD6Il002388; Wed, 19 Nov 2008 16:13:12 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJLCXJD014993; Wed, 19 Nov 2008 16:12:33 -0500 Date: Wed, 19 Nov 2008 16:12:33 -0500 Message-Id: <492480f0.0af5660a.0cca.0a66@mx.google.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Danilo Gligoroski" To: Multiple recipients of list Subject: RE: Cryptanalysis of Edon-R X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Microsoft Office Outlook 12.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 In-Reply-To: <49246687.2040501@mit.edu> References: <491dc202.130c420a.03ae.6ebd@mx.google.com> <49242e79.1c048e0a.182d.2c5a@mx.google.com> <49245f3b.2006420a.11c6.ffffb7e0@mx.google.com> <49246687.2040501@mit.edu> X-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 13:14:42 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 203 Ronald L. Rivest wrote: I would think that an "interesting" or "significant" attack on a proposed hash function would be one that was more effective than what one could mount against a hypothetical "ideal" hash function that required the same volume/power/circuitry to implement as the proposal. Do these attacks qualify as significant in this metric? HA HA, Whatever attack it is - it needs just one tiny additional property: To be polynomially reducible to become an attack to all other hash functions. :-) :-) Cheers, Danilo! From hash-forum@nist.gov Wed Nov 19 13:01:10 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJL15MC013641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 13:01:06 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJKx7Wo022773; Wed, 19 Nov 2008 15:59:16 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJKwdrC019057; Wed, 19 Nov 2008 15:58:39 -0500 Date: Wed, 19 Nov 2008 15:58:39 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Robert Jueneman" To: Multiple recipients of list Subject: RE: do we really need a 512-bit hash was: Preimage attacks on CubeHash... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit X-To: References: <4923B12D.1000702@mit.edu> <9418DB6C0B9D434190E54A78E931C3D1086429A7@XCH-NW-7V1.nw.nos.boeing.com> In-Reply-To: <9418DB6C0B9D434190E54A78E931C3D1086429A7@XCH-NW-7V1.nw.nos.boeing.com> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 13:01:06 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 204 I completely agree with Larry. Air-worthiness certificates, student loan records, medical records, and even mortgage records and other long-term contracts impose exceedingly difficult requirements in term of the longevity of a digital signature -- easily approaching 100 years. People sometimes assume that someone else (typically the next administration, or the next CEO, or the tooth fairy), will somehow be motivated to go back and revalidate and re-sign all of those documents, but I submit that just ain't gonna happen. If it is signed once, that's likely to be it, period. (Being able to READ all of those document 100 years from now is a different challenge, but not one for this discussion.) In talks I have given, I've made the point that one of my ancestors, one Don Louis Lorimer, who founded of Cape Girardeau, MO, in 1793, figures prominently in TWO U.S. Supreme Court cases, one of which was brought by my grandmother in 1946. She contested the transference of a major piece of land to the U.S. Government that had been bequeathed to the city nearly a century and a half earlier for certain beneficent purposes, saying in effect, "if you aren't going to use the property in accordance with the terms of the will, please give it back to the heirs and successors, namely me." (She lost, in a landmark case that for the first time established the right of eminent domain of the U.S. Government against another governmental agency, namely the city.) So here I am, citing a U.S. Supreme Court case that involved records from 200 years ago. Other ancestral records go back even further, to the time of Charlemagne, over 1200 years ago. Clearly, no one has a crystal ball good enough to predict the future of technology over the next 1000 years,. But I remember when IBM and NIST confidently proclaimed that single-DES would be secure for many centuries, and yet it survived for less than three decades. I designed a couple of the earliest hash functions, QCMDCV4, only to have Don Coppersmith break it within a few months (thereby convincing me that I shouldn't participate in these competitions, except as a interested observer). Ron Rivest's contributions (MD2, MD4, MD5) have lasted a considerably longer, but even NSA's contributions (SHA-0, SHA-1) are now endangered if not broken. So although I agree that length does not necessarily imply strength, I would certainly urge a very conservative approach. A 512-bit hash is certainly not too long to deal with -- not when we have terabytes of storage on a desktop these days, and gigabit LANs. Bob Robert R. Jueneman Chief Scientist SPYRUS, Inc. -----Original Message----- From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Bugbee, Larry Sent: Tuesday, November 18, 2008 10:59 PM To: Multiple recipients of list Subject: do we really need a 512-bit hash was: Preimage attacks on CubeHash... Tom St Denis wrote: > > Steven M. Bellovin wrote: >> >>> we have found preimage attacks ... >>> that require $2^{496}$ and $2^{480}$ computations respectively and >>> negligible memory. [...] > Which raises the question "do we really need a 512-bit hash?" Of > course the answer is "not really." I have to disagree, at least for some applications. We have some electronic "documents" that, under ideal conditions, are to be signed and retained for the "life-of-the-airplane" plus 50 years. ...and DC-3s are still flying. You can do the math. While we all know this won't happen, we do need to do the best we can. If we can find ways to push good integrity out 30+ years, perhaps our successors will find a way to extend it another 30 years. ...and so on. There are at least a half dozen possible schemes, each with their issues, but the most promising is a combination. One essential element, however, is to apply several very strong hashes signed with strong keys and algorithms. Besides strength, we want redundancy providing us with a window of time to re-group. It is not perfect, but we must do the best we can. We very much want to see several strong hash algorithms survive this competition. Their length is secondary. Larry From hash-forum@nist.gov Wed Nov 19 13:28:30 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJLSOPC016679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 13:28:26 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJLRGIK009094; Wed, 19 Nov 2008 16:27:21 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJLQqEP010488; Wed, 19 Nov 2008 16:26:52 -0500 Date: Wed, 19 Nov 2008 16:26:52 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Daniel Brown To: Multiple recipients of list Subject: RE: Cryptanalysis of Edon-R [->hypothetical physics for memory ...] X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" In-Reply-To: <50676.201.95.58.20.1227124059.squirrel@webmail.larc.usp.br> References: <491dc202.130c420a.03ae.6ebd@mx.google.com> <49242e79.1c048e0a.182d.2c5a@mx.google.com> <49245f3b.2006420a.11c6.ffffb7e0@mx.google.com> <49246687.2040501@mit.edu> <50676.201.95.58.20.1227124059.squirrel@webmail.larc.usp.br> X-To: "hash-forum@nist.gov" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 13:28:26 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 205 > -----Original Message----- > From: Paulo S. L. M. Barreto > Sent: Wednesday, November 19, 2008 3:03 PM > To: Multiple recipients of list > Subject: Re: Cryptanalysis of Edon-R > > ... > If you can store a bit in a hydrogen atom ... you > "only" need 1/3 the mass of the Earth for 2^170 bits > ... IF you can store a bit in a photon, you need much less space, as photons can occupy the same space. And, 2^170 photons, each of wave length 1m, have energy of "only" about 10^26 joules. Dan From hash-forum@nist.gov Wed Nov 19 13:56:48 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJLufk0020142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 13:56:43 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJLt93Z019645; Wed, 19 Nov 2008 16:55:15 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJLsSi8002223; Wed, 19 Nov 2008 16:54:28 -0500 Date: Wed, 19 Nov 2008 16:54:28 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Dmitry Khovratovich" To: Multiple recipients of list Subject: Re: Cryptanalysis of Edon-R X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <491dc202.130c420a.03ae.6ebd@mx.google.com> <49242e79.1c048e0a.182d.2c5a@mx.google.com> <49245f3b.2006420a.11c6.ffffb7e0@mx.google.com> Content-Type: multipart/alternative; boundary="----=_Part_82122_2636810.1227131046491" MIME-Version: 1.0 In-Reply-To: <49245f3b.2006420a.11c6.ffffb7e0@mx.google.com> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 13:56:44 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 206 ------=_Part_82122_2636810.1227131046491 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wed, Nov 19, 2008 at 7:50 PM, Danilo Gligoroski < danilo.gligoroski@gmail.com> wrote: > > More particularly for this hash competition. NIST were very careful in the > wording for the security requirements: > > > > Collision resistance of approximately *n*/2 bits, > > Preimage resistance of approximately *n *bits, > > Second-preimage resistance of approximately *n-k *bits > for any message shorter than 2^*k *bits, > > > > They are not giving any priority to the "number of computations when > measuring the complexity". > Actually, there is no necessity to deal with the NIST requirements. The Edon-R submission states that the *work factor* for finding a preimage is ~2^n (Table 3.19, page 56). In the abstract it is stated that the conjectured cryptographic security is O(2^n) *hash computations* for finding preimages. Well, the gap between 2^n and 2^{2n/3} seems to be too large to be covered with the search expenses. -- Best regards, Dmitry Khovratovich ------=_Part_82122_2636810.1227131046491 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Wed, Nov 19, 2008 at 7:50 PM, Danilo Gligoroski <danilo.gligoroski@gmail.com> wrote:

More particularly for this hash competition. NIST were very careful in the wording for the security requirements:

 

                        Collision resistance of approximately n/2 bits,

                        Preimage resistance of approximately n bits,

                        Second-preimage resistance of approximately n-k bits for any message shorter than 2^k bits,

 

They are not giving any priority to the "number of computations when measuring the complexity".

Actually, there is no necessity to deal with the NIST requirements. The Edon-R submission states that the work factor for finding a preimage is ~2^n (Table 3.19, page 56).

In the abstract it is stated that the conjectured cryptographic security is O(2^n) hash computations for finding preimages.

Well, the gap between 2^n and 2^{2n/3} seems to be too large to be covered with the search expenses.

--
Best regards,
Dmitry Khovratovich
------=_Part_82122_2636810.1227131046491-- From hash-forum@nist.gov Wed Nov 19 13:57:00 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJLuoPp020174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 13:56:53 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJLt93j019645; Wed, 19 Nov 2008 16:55:17 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJLt0Er002971; Wed, 19 Nov 2008 16:55:00 -0500 Date: Wed, 19 Nov 2008 16:55:00 -0500 Message-Id: <20081119214830.GA22764@titan.cry.pto> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Thomas Pornin To: Multiple recipients of list Subject: Re: do we really need a 512-bit hash was: Preimage attacks on CubeHash... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas In-Reply-To: <4924343E.2080708@ellipticsemi.com> Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 References: <20081118135449.233c2563@cs.columbia.edu> <4923156E.5010403@ellipticsemi.com> <4923B12D.1000702@mit.edu> <9418DB6C0B9D434190E54A78E931C3D1086429A7@XCH-NW-7V1.nw.nos.boeing.com> <7731938b0811190451o17daedc1he99cc7bd102f47d1@mail.gmail.com> <49241BFF.8000507@ellipticsemi.com> <7731938b0811190655q38226f30yc868bb048406c28@mail.gmail.com> <4924343E.2080708@ellipticsemi.com> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 13:56:53 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 207 On Wed, Nov 19, 2008 at 10:49:14AM -0500, Tom St Denis wrote: > Assuming that 20nm is the bottom end of practical limits Some researchers at IBM built a 6nm transistor; this was announced by the end of 2002: http://www-03.ibm.com/press/us/en/pressrelease/22069.wss so it seems that the physical limit is somewhat below 6nm. > So density is only likely to increase 2x maybe 3x so long as we make > chips out of the same technology. A real boost would be efficient use of the third dimension. Today's semi-conductors are desperately flat, and we talk about how many transistors we may cram into a given _surface_. We know how to build a chip with less than a dozen layers. If we could spread a thousand layers over a single chip, then we would have hundreds of cores, and they would be faster than today's cores thanks to the reduced distance between transistors. Of course this is a technological nightmare and industry is far from that point, but this means that "physical" limits are still remote. If you are after hard limits, then energy consumption is a better candidate. If you divide the total energy expected to be given out by our faithful Sun (the big ball of hot gas which converts 2 billion tons of mass to high energy photons and neutrinos every second) by the smallest amount of energy variation that we technologically envision (say the transition between two "adjacent" energy levels for a single electron around a typical atom), and then assume that a (classic, non-QC) computer will require at least that much energy for each computational step, then you find out a convincing hard limit on what power an attacker may ever had. It will be around 2^220. Of course, we all know that. It is a classic computation. We also know that there are actual "physical" limits which are below that. It is preposterous to imagine that a mankind-built classical computer will even reach 2^180. However, let me point out that the important word in the text above is: "convincing". We do not know how to prove that a hash function is secure. We do not know whether there exists such a thing as a secure hash function. However, we need security, and security is twofold: a system is "secure enough" if both following conditions are true: 1. No successful attack is performed on the system. 2. The system administrator is sufficiently sure of "1" that he may sleep at night. So part of the security is to gather trust in the security of the hash function. The function must be secure, yes, but it must also be convincingly secure as well. Since we are currently unable to prove security, we have to rely on approximations. The best known approximation so far is to show the function to be secure by showing the function creator to be smart. And by "smart", we mean "smarter than his ferocious peers". Hence, we setup a game of wits, in which the attackers are given impossible power, and if the function still resists then the creator is really good. So it is customary to consider that attackers have much more computing power than is plausible. It is part of the rules of the game. And since we want the game to be convincing, then the amount of power given to the attacker should be really striking. There comes the Sun: the ability to capture the big ball of gas in the sky, and to burn it all for a single task, is really god-like. The Sun has a long history of being a deity, which means that, as far as mental pictures go, the Sun is quite strong. To sum up, we want security to be convincing, which means that function creators must be able to defeat gods. Gods have the Solar power of performing 2^220 steps of computation, which is enough to find a collision in a 440-bit hash function. So you cannot defeat a god with a hash function which has an output smaller than that. Round that up to the next power of 2 (powers of 2 are traditional) and you end up with requiring a 512-bit hash function. As a side note, we also give to the attacker 2^220 bits of RAM, because although we do not know what kind of RAM a star-wielding deity may use, we are ready to believe that resetting an array of n bits will use n elementary chunks of energy as well. Of course, in the mundane world, RAM is more expensive than clock cycles, but we are not talking about practicality here. This is the difference with the 2DES exemple that Bernstein detailed a few days ago. That example used the dollar as a unit of cost. The dollar (or euro or yen or barrel of oil) is what you use when you want to show that an attack is practical (and you were given too few of said dollars to build it yourself). Here, we are talking about how showing attacks are NOT practical. So we give outrageously exaggerated amounts of power to the attacker, and show that even such power is not sufficient. This super-power needs not be "reasonable", even when it comes to comparing clock cycles with RAM size; actually, it needs to be _obviously unreasonable_ and hitting the hard limit of Sun-based energy fits the bill. The "1 bit = 1 clock cycle" rule also conveniently means that you can multiply the number of steps (in clock cycles) by the needed RAM size (in bits) to get a measure of "cost" (in the humans-vs-gods game described above) which seems to remain stable when time-memory trade-offs are applied. It makes the game easier to play. And QC in all that ? The Hell with QC. It totally ruins my nice speach. --Thomas Pornin From hash-forum@nist.gov Wed Nov 19 14:24:41 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJMOZx1024572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 14:24:36 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJMNIHT010304; Wed, 19 Nov 2008 17:23:23 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJMM4ND026725; Wed, 19 Nov 2008 17:22:05 -0500 Date: Wed, 19 Nov 2008 17:22:04 -0500 Message-Id: <49249068.9050409@ellipticsemi.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Mike Borza To: Multiple recipients of list Subject: Re: do we really need a 512-bit hash was: Preimage attacks on CubeHash... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 In-Reply-To: References: <4923B12D.1000702@mit.edu> <9418DB6C0B9D434190E54A78E931C3D1086429A7@XCH-NW-7V1.nw.nos.boeing.com> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 14:24:37 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 208 I have been watching this discussion trying to resist pressing the reply button, and even now hesitate to jump in. But here goes. I laud the goal of producing a hash algorithm that has the longevity to survive the foreseeable future and then some. The choice of a 512 bits hash to complement 256 bits AES makes sense in terms of consistent security against brute force attacks. Steve Bellovin made a simple, elegant argument that supports Tom St Denis' original point that 512 bits is really unnecessary to stave off brute force attacks until "The End" (my paraphrase of those original contributions, and yes, Tom is a colleague of mine). And this is really the central point. Successful attacks on a (cryptographically useful) hash algorithm are going to come from improvements in cryptanalysis and underlying mathematical techniques. The practical question then for me is: do extra bits of brute force attack resistance buy anything significant in terms of resistance to unknown future cryptanalytic progress? I don't know, but I wouldn't want to place a significant bet on it. The principal of make it big and you make it hard to defeat sounds good.... The best I can say is that it might buy some extra time in the event of a breakthrough that yields a significant reduction in the effective security level. The SHA-1 experience was that progress came steadily and fairly quickly, and when it happened the urgency to abandon ship and find alternatives went way up. Mike Borza On 19/11/08 03:58 PM, Robert Jueneman wrote: > I completely agree with Larry. > > Air-worthiness certificates, student loan records, medical records, and > even mortgage records and other long-term contracts impose exceedingly > difficult requirements in term of the longevity of a digital signature > -- easily approaching 100 years. People sometimes assume that someone > else (typically the next administration, or the next CEO, or the tooth > fairy), will somehow be motivated to go back and revalidate and re-sign > all of those documents, but I submit that just ain't gonna happen. If > it is signed once, that's likely to be it, period. (Being able to READ > all of those document 100 years from now is a different challenge, but > not one for this discussion.) > > In talks I have given, I've made the point that one of my ancestors, one > Don Louis Lorimer, who founded of Cape Girardeau, MO, in 1793, figures > prominently in TWO U.S. Supreme Court cases, one of which was brought by > my grandmother in 1946. She contested the transference of a major piece > of land to the U.S. Government that had been bequeathed to the city > nearly a century and a half earlier for certain beneficent purposes, > saying in effect, "if you aren't going to use the property in accordance > with the terms of the will, please give it back to the heirs and > successors, namely me." (She lost, in a landmark case that for the > first time established the right of eminent domain of the U.S. > Government against another governmental agency, namely the city.) So > here I am, citing a U.S. Supreme Court case that involved records from > 200 years ago. > > Other ancestral records go back even further, to the time of > Charlemagne, over 1200 years ago. > > Clearly, no one has a crystal ball good enough to predict the future of > technology over the next 1000 years,. But I remember when IBM and NIST > confidently proclaimed that single-DES would be secure for many > centuries, and yet it survived for less than three decades. I designed a > couple of the earliest hash functions, QCMDCV4, only to have Don > Coppersmith break it within a few months (thereby convincing me that I > shouldn't participate in these competitions, except as a interested > observer). Ron Rivest's contributions (MD2, MD4, MD5) have lasted a > considerably longer, but even NSA's contributions (SHA-0, SHA-1) are now > endangered if not broken. > > So although I agree that length does not necessarily imply strength, I > would certainly urge a very conservative approach. A 512-bit hash is > certainly not too long to deal with -- not when we have terabytes of > storage on a desktop these days, and gigabit LANs. > > Bob > > Robert R. Jueneman > Chief Scientist > SPYRUS, Inc. > > > -----Original Message----- > From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of > Bugbee, Larry > Sent: Tuesday, November 18, 2008 10:59 PM > To: Multiple recipients of list > Subject: do we really need a 512-bit hash was: Preimage attacks on > CubeHash... > > > Tom St Denis wrote: > >> Steven M. Bellovin wrote: >> >>> >>> >>>> we have found preimage attacks ... >>>> that require $2^{496}$ and $2^{480}$ computations respectively and >>>> negligible memory. >>>> > [...] > >> Which raises the question "do we really need a 512-bit hash?" Of >> course the answer is "not really." >> > > I have to disagree, at least for some applications. We have some > electronic "documents" that, under ideal conditions, are to be signed > and retained for the "life-of-the-airplane" plus 50 years. ...and DC-3s > are still flying. You can do the math. > > While we all know this won't happen, we do need to do the best we can. > If we can find ways to push good integrity out 30+ years, perhaps our > successors will find a way to extend it another 30 years. ...and so on. > > There are at least a half dozen possible schemes, each with their > issues, but the most promising is a combination. One essential element, > however, is to apply several very strong hashes signed with strong keys > and algorithms. Besides strength, we want redundancy providing us with > a window of time to re-group. It is not perfect, but we must do the > best we can. > > We very much want to see several strong hash algorithms survive this > competition. Their length is secondary. > > Larry > > > > > From hash-forum@nist.gov Wed Nov 19 15:33:01 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJNWt67032199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 15:32:56 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJNVJtQ009570; Wed, 19 Nov 2008 18:31:23 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJNUOI8029960; Wed, 19 Nov 2008 18:30:24 -0500 Date: Wed, 19 Nov 2008 18:30:24 -0500 Message-Id: <4924a003.0af5660a.0cca.1fd4@mx.google.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Danilo Gligoroski" To: Multiple recipients of list Subject: RE: Cryptanalysis of Edon-R X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Microsoft Office Outlook 12.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01CA_01C94AA6.3E81CB90" MIME-Version: 1.0 In-Reply-To: References: <491dc202.130c420a.03ae.6ebd@mx.google.com> <49242e79.1c048e0a.182d.2c5a@mx.google.com> <49245f3b.2006420a.11c6.ffffb7e0@mx.google.com> X-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 15:32:57 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 209 This is a multipart message in MIME format. ------=_NextPart_000_01CA_01C94AA6.3E81CB90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit More particularly for this hash competition. NIST were very careful in the wording for the security requirements: Collision resistance of approximately n/2 bits, Preimage resistance of approximately n bits, Second-preimage resistance of approximately n-k bits for any message shorter than 2^k bits, They are not giving any priority to the "number of computations when measuring the complexity". Actually, there is no necessity to deal with the NIST requirements. The Edon-R submission states that the work factor for finding a preimage is ~2^n (Table 3.19, page 56). In the abstract it is stated that the conjectured cryptographic security is O(2^n) hash computations for finding preimages. Well, the gap between 2^n and 2^{2n/3} seems to be too large to be covered with the search expenses. Ah - your attack is MUCH MUCH more expensive than 2^n hash computations. You can continue to repeatedly claim that your attack needs "just" 2^{2n/3} computations, on purposely forgetting the other "tiny" part that you are dealing with 2^{2n/3} stored hash values (i.e. with 2^170 for 256 bits and 2^341 for 512 bits). BUT that "tiny" detail when reduced into "hash computations" makes your attack to have 2^{4n/3} hash computations. Classical time-memory trade off. But in your case the attack is with a flaw: it is much worse than simple brute force attack. Keep claiming that you have "attack" better than brute force. Neither me nor you will decide who is right. Best regards, Danilo Gligoroski ------=_NextPart_000_01CA_01C94AA6.3E81CB90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

More particularly for = this hash competition. NIST were very careful in the wording for the security requirements:

 

        = ;            =     Collision resistance of = approximately n/2 bits,

        = ;            =     Preimage resistance of = approximately n bits,

        = ;            =     Second-preimage resistance of = approximately n-k bits for any message shorter than 2^k bits,

 

They are not giving = any priority to the "number of computations when measuring the complexity".

Actually, there is no necessity to deal with the = NIST requirements. The Edon-R submission states that the work factor = for finding a preimage is ~2^n (Table 3.19, page 56).

In the abstract it is stated that the conjectured cryptographic security = is O(2^n) hash computations for finding preimages.

Well, the gap between 2^n and 2^{2n/3} seems to be too large to be = covered with the search expenses.



 

Ah – your attack is MUCH MUCH more expensive = than 2^n hash computations.

You can continue to repeatedly claim that your = attack needs “just” 2^{2n/3} computations,

on purposely forgetting the other = “tiny” part that you are dealing with 2^{2n/3} stored hash values

(i.e. with 2^170 for 256 bits and 2^341 for 512 = bits).

 

BUT that “tiny” detail when reduced = into “hash computations” makes your attack to

have 2^{4n/3} hash computations. Classical = time-memory trade off.

But in your case the attack is with a flaw: it is = much worse than simple brute force attack.

 

Keep claiming that you have “attack” = better than brute force.

Neither me nor you will decide who is = right.

 

Best regards,

Danilo Gligoroski

 

------=_NextPart_000_01CA_01C94AA6.3E81CB90-- From hash-forum@NIST.GOV Wed Nov 19 15:46:21 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAJNkFGL001080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 15:46:17 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAJNinbm006415; Wed, 19 Nov 2008 18:44:53 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAJNiYse024899; Wed, 19 Nov 2008 18:44:34 -0500 Date: Wed, 19 Nov 2008 18:44:34 -0500 Message-Id: Errors-To: sara@NIST.GOV Reply-To: hash-forum@NIST.GOV Originator: hash-forum@nist.gov Sender: hash-forum@NIST.GOV Precedence: bulk From: Jon Callas To: Multiple recipients of list Subject: Re: do we really need a 512-bit hash was: Preimage attacks on CubeHash... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes X-Mailer: Apple Mail (2.929.2) References: <20081118135449.233c2563@cs.columbia.edu> <4923156E.5010403@ellipticsemi.com> <4923B12D.1000702@mit.edu> <9418DB6C0B9D434190E54A78E931C3D1086429A7@XCH-NW-7V1.nw.nos.boeing.com> <7731938b0811190451o17daedc1he99cc7bd102f47d1@mail.gmail.com> <49241BFF.8000507@ellipticsemi.com> Mime-Version: 1.0 (Apple Message framework v929.2) In-Reply-To: <49241BFF.8000507@ellipticsemi.com> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 15:46:17 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 210 On Nov 19, 2008, at 6:11 AM, Tom St Denis wrote: > > Peter Maxwell wrote: >> I would think the necessity for a 512-bit digest would be that the >> maximum AES key size is 256-bits and a hash is susceptible to a >> birthday attack to generate collisions at 2^n/2 which for a 512-bit >> hash is 256-bits. So it is probably seen as equivalent security. >> > Yeah, but do we even need AES-256? Realistically a 192-bit > symmetric key is more than enough against normal and quantum > computers. The only reason I'd favour 256 over 192 is that it's a > nice round number (in binary) thus making hardware easier to design. Both of these are the correct answer. We have 512-bit hashes because they crypto-balance with 256-bit block ciphers. We have 256-bit block ciphers because 128-bit ciphers will last for the next fifty-ish years, assuming that we have Moore's Law, Quantum Crypto, or whatever continuing advancement of brute force attacks. 256 is the next convenient number after 128. The problem with 192-bit crypto is that it's neither fish nor fowl. In some cases, it is literally nothing more than 256-bit crypto truncated (e.g. SHA-384, which is a stepped-down version of SHA-512). In these cases there is no benefit to 192 bits over 256 except that the parameters are smaller. It is only in the cases where 192 fits and 256 doesn't that you'd bother to use it. In general, it isn't worth discussing. Just do 256 bits and you'll be happy. (And if you need more than 256 bits of cipher oomph, look at the Threefish block cipher that is the core of the Skein hash. It is a 512- bit cipher or 1024-bit cipher and runs at twice the speed of AES. Yeah, I'm a co-author, but it's still cool.) Jon -- Jon Callas CTO, CSO PGP Corporation Tel: +1 (650) 319-9016 200 Jefferson Drive Fax: +1 (650) 319-9001 Menlo Park, CA 94025 PGP: ed15 5bdf cd41 adfc 00f3 USA 28b6 52bf 5a46 bc98 e63d From hash-forum@nist.gov Wed Nov 19 16:13:46 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAK0DeRC004457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 16:13:41 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAK0CA1T019641; Wed, 19 Nov 2008 19:12:14 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAK0BfQM011605; Wed, 19 Nov 2008 19:11:41 -0500 Date: Wed, 19 Nov 2008 19:11:41 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Dmitry Khovratovich" To: Multiple recipients of list Subject: Re: Cryptanalysis of Edon-R X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <491dc202.130c420a.03ae.6ebd@mx.google.com> <49242e79.1c048e0a.182d.2c5a@mx.google.com> <49245f3b.2006420a.11c6.ffffb7e0@mx.google.com> <4924a003.0af5660a.0cca.1fd4@mx.google.com> Content-Type: multipart/alternative; boundary="----=_Part_83449_17021654.1227139141482" MIME-Version: 1.0 In-Reply-To: <4924a003.0af5660a.0cca.1fd4@mx.google.com> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 16:13:41 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 211 ------=_Part_83449_17021654.1227139141482 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Thu, Nov 20, 2008 at 12:30 AM, Danilo Gligoroski < danilo.gligoroski@gmail.com> wrote: > BUT that "tiny" detail when reduced into "hash computations" makes your > attack to > > have 2^{4n/3} hash computations. > How? > Classical time-memory trade off. > Time <> Computations. -- Best regards, Dmitry Khovratovich University of Luxembourg, Laboratory of Algorithms, Cryptography and Security, + 352 46 66 44 5478 ------=_Part_83449_17021654.1227139141482 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Thu, Nov 20, 2008 at 12:30 AM, Danilo Gligoroski <danilo.gligoroski@gmail.com> wrote:

BUT that "tiny" detail when reduced into "hash computations" makes your attack to

have 2^{4n/3} hash computations.


How?
 

Classical time-memory trade off.


Time <> Computations.


--
Best regards,
Dmitry Khovratovich

University of Luxembourg,
Laboratory of Algorithms, Cryptography and Security,
+ 352 46 66 44 5478
------=_Part_83449_17021654.1227139141482-- From hash-forum@nist.gov Wed Nov 19 16:54:24 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAK0sJVj008536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 16:54:20 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAK0qqJV006226; Wed, 19 Nov 2008 19:52:54 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAK0q3Tt026369; Wed, 19 Nov 2008 19:52:03 -0500 Date: Wed, 19 Nov 2008 19:52:03 -0500 Message-Id: <7731938b0811191648g6e280aa7qd22771850525252f@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Peter Maxwell" To: Multiple recipients of list Subject: Re: do we really need a 512-bit hash was: Preimage attacks on CubeHash... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <4923B12D.1000702@mit.edu> <9418DB6C0B9D434190E54A78E931C3D1086429A7@XCH-NW-7V1.nw.nos.boeing.com> <49249068.9050409@ellipticsemi.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 In-Reply-To: <49249068.9050409@ellipticsemi.com> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 16:54:20 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 212 2008/11/19 Mike Borza : > > And this is really the central point. Successful attacks on a > (cryptographically useful) hash algorithm are going to come from > improvements in cryptanalysis and underlying mathematical techniques. > The practical question then for me is: do extra bits of brute force > attack resistance buy anything significant in terms of resistance to > unknown future cryptanalytic progress? I don't know, but I wouldn't > want to place a significant bet on it. The principal of make it big and > you make it hard to defeat sounds good.... The best I can say is that > it might buy some extra time in the event of a breakthrough that yields > a significant reduction in the effective security level. The SHA-1 > experience was that progress came steadily and fairly quickly, and when > it happened the urgency to abandon ship and find alternatives went way up. > You may not want to place a significant bet on it, but considering the only other choice - would you bet against it? Especially comparing the implementation costs of a 512-bit hash as opposed to a 256-bit hash are *in most cases* negligable. From hash-forum@nist.gov Wed Nov 19 17:34:45 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAK1Yd37013137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 17:34:41 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAK1XWQ2010880; Wed, 19 Nov 2008 20:33:35 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAK1Woai008751; Wed, 19 Nov 2008 20:32:50 -0500 Date: Wed, 19 Nov 2008 20:32:50 -0500 Message-Id: <54587.201.95.58.20.1227144062.squirrel@webmail.larc.usp.br> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Paulo S. L. M. Barreto" To: Multiple recipients of list Subject: RE: Cryptanalysis of Edon-R [->hypothetical physics for memory ...] X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain;charset=iso-8859-1 MIME-Version: 1.0 X-To: hash-forum@nist.gov References: <491dc202.130c420a.03ae.6ebd@mx.google.com> <49242e79.1c048e0a.182d.2c5a@mx.google.com> <49245f3b.2006420a.11c6.ffffb7e0@mx.google.com> <49246687.2040501@mit.edu> <50676.201.95.58.20.1227124059.squirrel@webmail.larc.usp.br> In-Reply-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 17:34:41 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 213 [Sorry for the part of this message that is related to an increasingly off-topic discussion] On Wed, November 19, 2008 19:26, Daniel Brown said: > IF you can store a bit in a photon, you need much > less space, as photons can occupy the same space. > And, 2^170 photons, each of wave length 1m, have > energy of "only" about 10^26 joules. Oops, *now* you're getting close to the Schwarzschild radius, which is about 3 mm for 2^170 bits stored in photons, and roughly half a meter for 2^170 512-bit blocks. Although I feel pair creation would have taken over long before you reached this energy density anyway... At least the laws of physics don't seem to prevent attacks. I presume we can also disregard improvements to quantum collision-finding attacks? Or maybe there is a way to circumvent the need for 2^{n/3} space here? There is prior art in other areas of crypto itself (e.g. Regev's improvement to Kuperberg's quantum algorithm for the dihedral hidden subgroup problem). Paulo. From hash-forum@nist.gov Wed Nov 19 17:48:20 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAK1mEd6014480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 17:48:15 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAK1lCEk030653; Wed, 19 Nov 2008 20:47:16 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAK1kqvo002683; Wed, 19 Nov 2008 20:46:52 -0500 Date: Wed, 19 Nov 2008 20:46:52 -0500 Message-Id: <20081119203626.153d88f3@cs.columbia.edu> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Steven M. Bellovin" To: Multiple recipients of list Subject: Re: do we really need a 512-bit hash was: Preimage attacks on CubeHash... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Mime-Version: 1.0 X-Mailer: Claws Mail 3.6.1 (GTK+ 2.14.3; x86_64--netbsd) References: <20081118135449.233c2563@cs.columbia.edu> <4923156E.5010403@ellipticsemi.com> <4923B12D.1000702@mit.edu> <9418DB6C0B9D434190E54A78E931C3D1086429A7@XCH-NW-7V1.nw.nos.boeing.com> <7731938b0811190451o17daedc1he99cc7bd102f47d1@mail.gmail.com> <49241BFF.8000507@ellipticsemi.com> In-Reply-To: X-Cc: jon@pgpeng.com X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 17:48:15 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 214 On Wed, 19 Nov 2008 18:44:34 -0500 Jon Callas wrote: > We have 256-bit block ciphers because 128-bit ciphers will last for > the next fifty-ish years, assuming that we have Moore's Law, Quantum > Crypto, or whatever continuing advancement of brute force attacks. > 256 is the next convenient number after 128. > > The problem with 192-bit crypto is that it's neither fish nor fowl. > In some cases, it is literally nothing more than 256-bit crypto > truncated (e.g. SHA-384, which is a stepped-down version of SHA-512). > In these cases there is no benefit to 192 bits over 256 except that > the parameters are smaller. It is only in the cases where 192 fits > and 256 doesn't that you'd bother to use it. In general, it isn't > worth discussing. Just do 256 bits and you'll be happy. It's worth noting that NSA's fact sheet on Suite B says "CNSSP-15 correctly states that 192-bit AES keys are sufficient for protecting even TOPSECRET information. However, Suite B uses only 256-bit keys to enhance interoperability." (http://www.nsa.gov/ia/Industry/crypto_suite_b.cfm) --Steve Bellovin, http://www.cs.columbia.edu/~smb From hash-forum@nist.gov Wed Nov 19 19:49:23 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAK3nITw026695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 19:49:19 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAK3m65f014744; Wed, 19 Nov 2008 22:48:12 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAK3lCJc008716; Wed, 19 Nov 2008 22:47:12 -0500 Date: Wed, 19 Nov 2008 22:47:12 -0500 Message-Id: <64ba6f640811191937r13947188g60f889db82c06b2c@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "dhiren patel" To: Multiple recipients of list Subject: Re: do we really need a 512-bit hash was: Preimage attacks on CubeHash... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <4923B12D.1000702@mit.edu> <9418DB6C0B9D434190E54A78E931C3D1086429A7@XCH-NW-7V1.nw.nos.boeing.com> <49249068.9050409@ellipticsemi.com> <7731938b0811191648g6e280aa7qd22771850525252f@mail.gmail.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 In-Reply-To: <7731938b0811191648g6e280aa7qd22771850525252f@mail.gmail.com> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 19:49:19 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 215 Hi all! I think instead of arguing on security, complexity, survivability in near and far future - we should just think about scalable scheme - that can produce 128 - 160 - 192 - 256 - 384 - 512 - 1024 bit hash digest. Based on the requirement, user can have flexibility to choose and compute. -dhiren On 11/20/08, Peter Maxwell wrote: > > 2008/11/19 Mike Borza : > > > > > And this is really the central point. Successful attacks on a > > (cryptographically useful) hash algorithm are going to come from > > improvements in cryptanalysis and underlying mathematical techniques. > > The practical question then for me is: do extra bits of brute force > > attack resistance buy anything significant in terms of resistance to > > unknown future cryptanalytic progress? I don't know, but I wouldn't > > want to place a significant bet on it. The principal of make it big and > > you make it hard to defeat sounds good.... The best I can say is that > > it might buy some extra time in the event of a breakthrough that yields > > a significant reduction in the effective security level. The SHA-1 > > experience was that progress came steadily and fairly quickly, and when > > it happened the urgency to abandon ship and find alternatives went way up. > > > > > You may not want to place a significant bet on it, but considering the > only other choice - would you bet against it? Especially comparing > the implementation costs of a 512-bit hash as opposed to a 256-bit > hash are *in most cases* negligable. > > -- Dr. Dhiren Patel Dean - Alumni & Resource Generation Professor - Computer Engineering Department N I T Surat, Gujarat - INDIA 395007 From hash-forum@nist.gov Wed Nov 19 21:24:31 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAK5OQve003086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 21:24:27 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAK5Mcdm009294; Thu, 20 Nov 2008 00:22:42 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAK5LRU9025731; Thu, 20 Nov 2008 00:21:27 -0500 Date: Thu, 20 Nov 2008 00:21:27 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Sandy Harris" To: Multiple recipients of list Subject: Re: Preimage attacks on CubeHash512-r/4 and CubeHash512-r/8 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <20081118135449.233c2563@cs.columbia.edu> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 In-Reply-To: <20081118135449.233c2563@cs.columbia.edu> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 19 Nov 2008 21:24:27 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 216 Steven M. Bellovin wrote: > > >> we have found preimage attacks ... >> that require $2^{496}$ and $2^{480}$ computations >> respectively and negligible memory. > > Portions intentionally elided, because my point is independent of this > particular result. > > I think it's worthwhile for the community to discuss what class of > attack actually suggests a weakness worth avoiding. ... Hashes will be used with ciphers: hash to create cipher key, or hash doing authentication and the system fails if the authentication fails, or hash + public key = digital signature. etc. The hash designer does not want the hash to be the weakest link, so we need hashes to be about as strong as the ciphers they'll be used with. We use 2n-bit hashes with n-bit key block ciphers so that the cost of a birthday attack on the hash roughly matches that has a brute force attack on the cipher. Is that the right thing to do? Exhaustive search takes negligible memory and is easily parallelized. Birthday attacks need memory and I'm not sure how well they parallelize. Certainly any attack on an n-bit hash with less than 2^(n/2) time and small memory requirements is a major weakness; the hash can be broken faster than an n-bit block cipher. As for memory, a codebook with 2^blocksize entries breaks a block cipher and 2^(blocksize/2) weakens it significantly. One cycle worth of data breaks a stream cipher. No calculations, all you need are table stores and lookups. If we're looking at Whatever-512 used with AES, then 2^128 memory breaks the AES with almost no computation. If the blocksize was 256 like the key, then 2^256. We therefore do not need to worry about attacks on Whatever that take more than 2^256 memory. To combine these, look at the memory * calculation product. For a 2n-bit hash, if the product is < 2^n, I'd call it broken because that is cheaper than brute force or codebooks against an n-bit block cipher. If the product is < 2^2n, I'd say it an interesting theoretical attack, worth watching for improvements. > More seriously -- an attack of 2^480 computations is not indicative of > a weakness. It may be useful as a guide to figuring out an attack, or > as an indication of the strength of a system, but in itself it's in no > way, shape, or form an "attack", and I don't know that it's right to > label it as such. Yes, in general writers should use the more neutral "analysis" rather than "attack" or even "cryptanalysis". > My question, though, is broader: what value is useful? There have been > key length calculations over the years (i.e., RFC 3766) about system > strengths; what is good enough here? Obviously, we want more if we can > get it cheaply enough, but what is the floor? -- Sandy Harris, Quanzhou, Fujian, China From hash-forum@nist.gov Thu Nov 20 02:07:11 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAKA76cE031366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 20 Nov 2008 02:07:07 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAKA5gIA004918; Thu, 20 Nov 2008 05:05:49 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAKA50ni018260; Thu, 20 Nov 2008 05:05:00 -0500 Date: Thu, 20 Nov 2008 05:05:00 -0500 Message-Id: <20081120100515.35180.qmail@cr.yp.to> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "D. J. Bernstein" To: Multiple recipients of list Subject: The uselessness of quantum collision algorithms X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas In-Reply-To: <54587.201.95.58.20.1227144062.squirrel@webmail.larc.usp.br> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 20 Nov 2008 02:07:07 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 217 Background: The Brassard--Hoyer--Tapp quantum algorithm is often claimed to force larger hash-function sizes, because it finds an n-bit collision in time proportional to 2^(n/3). However, the algorithm requires a machine of size 2^(n/3), so it's actually a giant step backwards from _classical_ parallel collision search, which finds an n-bit collision in time 2^(n/3) on a vastly less expensive machine of size 2^(n/6). Paulo S. L. M. Barreto writes: > the Brassard-Hoyer-Tapp algorithm > takes 2^{n/3} quantum memory as well. I'm only unsure about the number > of quantum gates needed (shame on me) Grover and Rudolph ("How significant are the known collision and element distinctness quantum algorithms?") comment that memory qubits can be "trivially extended to processing qubits." They call the distinction "artificial" and "blurred." > Or maybe there is a way to circumvent the need for 2^{n/3} space here? I've looked for better quantum algorithms, and found some, but the best ones boil down to classical parallel collision search. I conjecture that every black-box quantum algorithm to find n-bit collisions has price-performance ratio Omega(2^(n/2)). Grover's preimage algorithm doesn't have this problem; it uses time proportional to 2^(n/2) on a _small_ quantum computer, and certainly beats classical computers once n is large enough. In other words, in post-quantum cryptography, preimages will have essentially the same cost as collisions; there's a quantum-to-classical cost ratio but that's essentially independent of n. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago From hash-forum@nist.gov Thu Nov 20 06:05:55 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAKE5oVA025559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 20 Nov 2008 06:05:51 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAKE4JwU006999; Thu, 20 Nov 2008 09:04:26 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAKE2a1a001074; Thu, 20 Nov 2008 09:02:36 -0500 Date: Thu, 20 Nov 2008 09:02:36 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Orr Dunkelman To: Multiple recipients of list Subject: Re: Preimage attacks on CubeHash512-r/4 and CubeHash512-r/8 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed MIME-Version: 1.0 References: <20081118135449.233c2563@cs.columbia.edu> In-Reply-To: X-To: Multiple recipients of list X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 20 Nov 2008 06:05:51 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 218 On Thu, 20 Nov 2008, Sandy Harris wrote: > We use 2n-bit hashes with n-bit key block ciphers so that the cost > of a birthday attack on the hash roughly matches that has a brute > force attack on the cipher. Is that the right thing to do? Exhaustive > search takes negligible memory and is easily parallelized. Birthday > attacks need memory and I'm not sure how well they parallelize. Birthday attacks do not use memory. If you use Floyd/Nivach algorithms you need either 2 to log_n memory cells, and take only slightly more time than a "standard" birthday attacks. Nivach's algorithm is also highly suitable for FPGAs, and other hardware, as the communication costs are really small. > To combine these, look at the memory * calculation product. What about data? and multiple queries? Assume for a second I can break your hash function in time of factoring a 2048-bit number, how would you compare this to 2^500 compression function calls? What happens if I need a huge table, but access it only once to obtain something (and as far as I am concerend, it can take up to a year to find the entry I am interested in), which then leads to reducing the time complexity of the attack from 2^80 years to one year? > Yes, in general writers should use the more neutral "analysis" rather > than "attack" or even "cryptanalysis". > Attack is attack is attack. The question whether the adversary (attacker) wishes to use this specific attack is up to him/her. I would suggest to use the term broken carefully, but an attack is a legitimate technical name. -- Orr Dunkelman, Ecole Normale Superieure Departement d'Informatique Tel. +33-1-44-32-20-50 Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm From hash-forum@nist.gov Thu Nov 20 14:27:33 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAKMRRJc021375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 20 Nov 2008 14:27:29 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAKMQ191006655; Thu, 20 Nov 2008 17:26:06 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAKMP7Tc003059; Thu, 20 Nov 2008 17:25:07 -0500 Date: Thu, 20 Nov 2008 17:25:07 -0500 Message-Id: <4A43B7BD5F98824E8DB2C49495BFB4BB3B988B6F5E@GVW0673EXC.americas.hpqcorp.net> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Haber, Stuart (HPL Princeton)" To: Multiple recipients of list Subject: longevity [was RE: do we really need...was: Preimage attacks...] X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" In-Reply-To: References: <4923B12D.1000702@mit.edu> <9418DB6C0B9D434190E54A78E931C3D1086429A7@XCH-NW-7V1.nw.nos.boeing.com> X-To: "hash-forum@nist.gov" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 20 Nov 2008 14:27:29 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 219 I completely agree with both Larry and Bob about the importance of the problem of ensuring integrity for very long-lived digital objects. But as I pointed out at the second NIST hash bash (just after Crypto '06), a cryptographic guarantee of integrity that will last for a hundred years does not require that we design a hash function now that will withstand all of the next century's engineering and algorithmic advances. Rather, we can use the availability of a new hash function design to "renew" integrity certificates (i.e. digital signatures, time-stamp certificates, or even simple lists of hash values) that were computed with a current hash function that is about to be deprecated. Some years later, when the advent of a surprising advance in quantum nanocomputer cryptanalysis motivates the standards-blessed adoption of an even newer hash function before the expected collapse of SHA-3, renewed certificates can be renewed yet again. The renewing process must be performed carefully, as described at http://www.hpl.hp.com/techreports/2007/HPL-2007-58.html (or at http://eprint.iacr.org/2007/238). -- Stuart -----Original Message----- From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Robert Jueneman Sent: Wednesday, November 19, 2008 3:59 PM To: Multiple recipients of list Subject: RE: do we really need a 512-bit hash was: Preimage attacks on CubeHash... I completely agree with Larry. Air-worthiness certificates, student loan records, medical records, and even mortgage records and other long-term contracts impose exceedingly difficult requirements in term of the longevity of a digital signature -- easily approaching 100 years. People sometimes assume that someone else (typically the next administration, or the next CEO, or the tooth fairy), will somehow be motivated to go back and revalidate and re-sign all of those documents, but I submit that just ain't gonna happen. If it is signed once, that's likely to be it, period. (Being able to READ all of those document 100 years from now is a different challenge, but not one for this discussion.) In talks I have given, I've made the point that one of my ancestors, one Don Louis Lorimer, who founded of Cape Girardeau, MO, in 1793, figures prominently in TWO U.S. Supreme Court cases, one of which was brought by my grandmother in 1946. She contested the transference of a major piece of land to the U.S. Government that had been bequeathed to the city nearly a century and a half earlier for certain beneficent purposes, saying in effect, "if you aren't going to use the property in accordance with the terms of the will, please give it back to the heirs and successors, namely me." (She lost, in a landmark case that for the first time established the right of eminent domain of the U.S. Government against another governmental agency, namely the city.) So here I am, citing a U.S. Supreme Court case that involved records from 200 years ago. Other ancestral records go back even further, to the time of Charlemagne, over 1200 years ago. Clearly, no one has a crystal ball good enough to predict the future of technology over the next 1000 years,. But I remember when IBM and NIST confidently proclaimed that single-DES would be secure for many centuries, and yet it survived for less than three decades. I designed a couple of the earliest hash functions, QCMDCV4, only to have Don Coppersmith break it within a few months (thereby convincing me that I shouldn't participate in these competitions, except as a interested observer). Ron Rivest's contributions (MD2, MD4, MD5) have lasted a considerably longer, but even NSA's contributions (SHA-0, SHA-1) are now endangered if not broken. So although I agree that length does not necessarily imply strength, I would certainly urge a very conservative approach. A 512-bit hash is certainly not too long to deal with -- not when we have terabytes of storage on a desktop these days, and gigabit LANs. Bob Robert R. Jueneman Chief Scientist SPYRUS, Inc. -----Original Message----- From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Bugbee, Larry Sent: Tuesday, November 18, 2008 10:59 PM To: Multiple recipients of list Subject: do we really need a 512-bit hash was: Preimage attacks on CubeHash... Tom St Denis wrote: > > Steven M. Bellovin wrote: >> >>> we have found preimage attacks ... >>> that require $2^{496}$ and $2^{480}$ computations respectively and >>> negligible memory. [...] > Which raises the question "do we really need a 512-bit hash?" Of > course the answer is "not really." I have to disagree, at least for some applications. We have some electronic "documents" that, under ideal conditions, are to be signed and retained for the "life-of-the-airplane" plus 50 years. ...and DC-3s are still flying. You can do the math. While we all know this won't happen, we do need to do the best we can. If we can find ways to push good integrity out 30+ years, perhaps our successors will find a way to extend it another 30 years. ...and so on. There are at least a half dozen possible schemes, each with their issues, but the most promising is a combination. One essential element, however, is to apply several very strong hashes signed with strong keys and algorithms. Besides strength, we want redundancy providing us with a window of time to re-group. It is not perfect, but we must do the best we can. We very much want to see several strong hash algorithms survive this competition. Their length is secondary. Larry From hash-forum@nist.gov Thu Nov 20 15:49:29 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAKNnMwr030915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 20 Nov 2008 15:49:24 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAKNm0Su018191; Thu, 20 Nov 2008 18:48:04 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAKNl0uJ001849; Thu, 20 Nov 2008 18:47:00 -0500 Date: Thu, 20 Nov 2008 18:47:00 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Robert Jueneman" To: Multiple recipients of list Subject: RE: longevity [was RE: do we really need...was: Preimage attacks...] X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit X-To: References: <4923B12D.1000702@mit.edu> <9418DB6C0B9D434190E54A78E931C3D1086429A7@XCH-NW-7V1.nw.nos.boeing.com> <4A43B7BD5F98824E8DB2C49495BFB4BB3B988B6F5E@GVW0673EXC.americas.hpqcorp.net> In-Reply-To: <4A43B7BD5F98824E8DB2C49495BFB4BB3B988B6F5E@GVW0673EXC.americas.hpqcorp.net> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 20 Nov 2008 15:49:24 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 220 I'm not trying to be completely unrealistic here. If we can design something that will last 100 years, I'll be perfectly happy. (Dead, but happy.) If it doesn't last for 1000, or perhaps the 10,000 years the Mormons would probably like, my great-great-great-grandkids can worry about it -- the media probably won't be readable anyway! However, from an academic perspective, unless I misread or misunderstand it, Stuart's note was primarily concerned about maintaining the integrity of the original TIME-STAMP, as opposed to the integrity of the document itself. If someone discovers a method of generating a collision on demand for SHA-X, then they would be able to generate a new text, one that is beneficial to those currently living that would match the original hash and the timestamp, as well as the new timestamp. So instead of merely updating or resigning the hash/signature, it is necessary to rehash the entirely of the original file with the new hash function. Generating several quadrillion hash functions would be bad enough, but reprocessing millions of exabytes of data would be a really daunting task. That's probably enough on this tread. I know from previous discussions that some people are particularly concerned with computing modest hash functions on minimal hardware, e.g., for RFID tags and similar applications. So be it. But for digital signatures with extended longevity, a 512-bit or even a 1024-bit hash (if that should ever be proposed) is a trivial amount of data to store, and a almost trivial amount of computation, compared to the volume of data being processed. Peace. Bob -----Original Message----- From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Haber, Stuart (HPL Princeton) Sent: Thursday, November 20, 2008 2:25 PM To: Multiple recipients of list Subject: longevity [was RE: do we really need...was: Preimage attacks...] I completely agree with both Larry and Bob about the importance of the problem of ensuring integrity for very long-lived digital objects. But as I pointed out at the second NIST hash bash (just after Crypto '06), a cryptographic guarantee of integrity that will last for a hundred years does not require that we design a hash function now that will withstand all of the next century's engineering and algorithmic advances. Rather, we can use the availability of a new hash function design to "renew" integrity certificates (i.e. digital signatures, time-stamp certificates, or even simple lists of hash values) that were computed with a current hash function that is about to be deprecated. Some years later, when the advent of a surprising advance in quantum nanocomputer cryptanalysis motivates the standards-blessed adoption of an even newer hash function before the expected collapse of SHA-3, renewed certificates can be renewed yet again. The renewing process must be performed carefully, as described at http://www.hpl.hp.com/techreports/2007/HPL-2007-58.html (or at http://eprint.iacr.org/2007/238). -- Stuart -----Original Message----- From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Robert Jueneman Sent: Wednesday, November 19, 2008 3:59 PM To: Multiple recipients of list Subject: RE: do we really need a 512-bit hash was: Preimage attacks on CubeHash... I completely agree with Larry. Air-worthiness certificates, student loan records, medical records, and even mortgage records and other long-term contracts impose exceedingly difficult requirements in term of the longevity of a digital signature -- easily approaching 100 years. People sometimes assume that someone else (typically the next administration, or the next CEO, or the tooth fairy), will somehow be motivated to go back and revalidate and re-sign all of those documents, but I submit that just ain't gonna happen. If it is signed once, that's likely to be it, period. (Being able to READ all of those document 100 years from now is a different challenge, but not one for this discussion.) In talks I have given, I've made the point that one of my ancestors, one Don Louis Lorimer, who founded of Cape Girardeau, MO, in 1793, figures prominently in TWO U.S. Supreme Court cases, one of which was brought by my grandmother in 1946. She contested the transference of a major piece of land to the U.S. Government that had been bequeathed to the city nearly a century and a half earlier for certain beneficent purposes, saying in effect, "if you aren't going to use the property in accordance with the terms of the will, please give it back to the heirs and successors, namely me." (She lost, in a landmark case that for the first time established the right of eminent domain of the U.S. Government against another governmental agency, namely the city.) So here I am, citing a U.S. Supreme Court case that involved records from 200 years ago. Other ancestral records go back even further, to the time of Charlemagne, over 1200 years ago. Clearly, no one has a crystal ball good enough to predict the future of technology over the next 1000 years,. But I remember when IBM and NIST confidently proclaimed that single-DES would be secure for many centuries, and yet it survived for less than three decades. I designed a couple of the earliest hash functions, QCMDCV4, only to have Don Coppersmith break it within a few months (thereby convincing me that I shouldn't participate in these competitions, except as a interested observer). Ron Rivest's contributions (MD2, MD4, MD5) have lasted a considerably longer, but even NSA's contributions (SHA-0, SHA-1) are now endangered if not broken. So although I agree that length does not necessarily imply strength, I would certainly urge a very conservative approach. A 512-bit hash is certainly not too long to deal with -- not when we have terabytes of storage on a desktop these days, and gigabit LANs. Bob Robert R. Jueneman Chief Scientist SPYRUS, Inc. -----Original Message----- From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Bugbee, Larry Sent: Tuesday, November 18, 2008 10:59 PM To: Multiple recipients of list Subject: do we really need a 512-bit hash was: Preimage attacks on CubeHash... Tom St Denis wrote: > > Steven M. Bellovin wrote: >> >>> we have found preimage attacks ... >>> that require $2^{496}$ and $2^{480}$ computations respectively and >>> negligible memory. [...] > Which raises the question "do we really need a 512-bit hash?" Of > course the answer is "not really." I have to disagree, at least for some applications. We have some electronic "documents" that, under ideal conditions, are to be signed and retained for the "life-of-the-airplane" plus 50 years. ...and DC-3s are still flying. You can do the math. While we all know this won't happen, we do need to do the best we can. If we can find ways to push good integrity out 30+ years, perhaps our successors will find a way to extend it another 30 years. ...and so on. There are at least a half dozen possible schemes, each with their issues, but the most promising is a combination. One essential element, however, is to apply several very strong hashes signed with strong keys and algorithms. Besides strength, we want redundancy providing us with a window of time to re-group. It is not perfect, but we must do the best we can. We very much want to see several strong hash algorithms survive this competition. Their length is secondary. Larry From hash-forum@nist.gov Thu Nov 20 21:51:18 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAL5pBNE032226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 20 Nov 2008 21:51:12 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAL5nnV6027681; Fri, 21 Nov 2008 00:49:52 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAL5mRaY013664; Fri, 21 Nov 2008 00:48:27 -0500 Date: Fri, 21 Nov 2008 00:48:27 -0500 Message-Id: <95F701E3-606A-413A-8BD2-97EF3093A23B@qualcomm.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Greg Rose To: Multiple recipients of list Subject: Re: Preimages for Boole X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: "hash-forum@nist.gov" X-Cc: Greg Rose Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-24--169373690; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v753.1) References: In-Reply-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 20 Nov 2008 21:51:12 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 221 --Apple-Mail-24--169373690 Content-Type: multipart/alternative; boundary=Apple-Mail-23--169373778 --Apple-Mail-23--169373778 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I'm just back from vacation, but I can confirm that (with minor tweaks and a slight increase in complexity) this attack works. Rats. I believe a simple fix is possible, and after sleeping on it for a few weeks will probably release a new version, but for the purposes of NIST, I think my submission is dead. Greg. On Nov 18, 2008, at 3:43 , Ivica Nikolic wrote: > Hi all, > > it seems that preimages for Boole-n can be found with 2^{9n/16} > computations and negligible memory. > The attack is presented in the paper which is available at: > http://lj.streamclub.ru/papers/hash/boole.pdf > > > Best regards, > --------------------------------------------------------------- > Ivica Nikolic > Laboratory of Algorithms, Cryptography and Security, > University of Luxembourg, > 6, rue Richard Coudenhove-Kalergi, > L-1359 Luxembourg-Kirchberg > Luxembourg > Tel: +352 46 66 44 5490 --Apple-Mail-23--169373778 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
I'm just back from vacation, but I can confirm that (with minor = tweaks and a slight increase in complexity) this attack works. Rats. I = believe a simple fix is possible, and after sleeping on it for a few = weeks will probably release a new version, but for the purposes of NIST, = I think my submission is = dead.

Greg.

On Nov 18, 2008, = at 3:43 , Ivica Nikolic wrote:

Hi = all,

it seems that preimages for Boole-n can be found with = 2^{9n/16} computations and negligible memory.
The attack is = presented in the paper which is available at:
http://lj.streamclu= b.ru/papers/hash/boole.pdf


Best = regards,
--------------------------------------------------------------= -
Ivica Nikolic
Laboratory of Algorithms, Cryptography and = Security,
University of Luxembourg,
6, rue Richard = Coudenhove-Kalergi,
L-1359 = Luxembourg-Kirchberg
Luxembourg
Tel: =A0+352 46 66 44 = 5490

= --Apple-Mail-23--169373778-- --Apple-Mail-24--169373690 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFLzCCBSsw ggMToAMCAQICAwN9ezANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNzA0MTkyMTIyNTBaFw0w OTA0MTgyMTIyNTBaMDgxFTATBgNVBAMTDEdyZWdvcnkgUm9zZTEfMB0GCSqGSIb3DQEJARYQZ2dy QHF1YWxjb21tLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOB3mC8o347L9EV/ XpiGoCemopUo2y4u99QxeRfMa+J/003Eh6Ijthpzi0Gp35pTv142yG5EjNBD18nwW4P7nU0vvi5l LcFN1HAlMXrdoi+Uak56+ohmeVgnqhqipiw7OVYJEs3Xs9p+BNL7CyD64EFRuHOhFQoX9laAPqxf i+ogAUlh5fElGn7NGxTCVW1ZdkkFAWpoVrnwRf1Xit/ejZ6BAhDeHxaY+ByA5oDttDIF1gngMhFP IIgk2B9duqRNIUi+SGJh+1VMeQAwzbaepzHZFNm7apizwlzThfcdfBj0v/iP5YF796lwONfnnKaI BO7TiyuUf3GWW8I2RZeoWEECAwEAAaOB/DCB+TAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJ FkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZzBABgNVHSUEOTA3BggrBgEFBQcDBAYIKwYBBQUHAwIGCisGAQQBgjcK AwQGCisGAQQBgjcKAwMGCWCGSAGG+EIEATAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUHMAGGFmh0 dHA6Ly9vY3NwLmNhY2VydC5vcmcwGwYDVR0RBBQwEoEQZ2dyQHF1YWxjb21tLmNvbTANBgkqhkiG 9w0BAQUFAAOCAgEABKj1M0PY310l9KPQX3kyUA54Nd2CoOlWA59ORyY+GdddtdE5LYc4Gg9oBQlB ug5Aoaf2b+dvG0YhhepOcG4w8Ar109mO9aXD94K/Cp9jljypioXhq4uvRPEim+iZc+W9UbmlD0Np 9xRq3ngPK0hwmRpq9vg8V+4oTnHnjZV9HD86GAvGe3ssQc0JLsCymXb9Id28IVHNhvllJFc4oSZr ZxmzqP4GtSm0Rz8Qj8Fu2Je8XjpuLxm8BlXOMzXqDdZOcYo/9Puoj6SvSRLx8xKNN2pyI+QD0bh7 bUx2trcx3H8yEUNL9s6YXdXm+1E88rKTiByTqwMTBVheuF8cYspndaBCY7gZZcfJUobVCCLC/tkd tw5SUHtERPGTk3cZ6jk5tBSzGh8jlkaA6R1Q7wTX9HAJSl8ceCklNtKolxX021uw1F4dHfiF5ihK T8j+wdKWm0jSIQ1M1vx1QGnTPJyZJ/H0d6wabHDfcvGZAMcxdGC6473y+wsFl1gvkcx9HvrpjyXL +Aplxe+8RJ/vWXMuRU/Khz6H/M0q3GELjbqyyaBdYsYrEdQnEcu0vE/yBD11WOeyWdxL8oc4gV5H p9YKeNIGtg6dX8+qX1pvdpNuDLLLMu5whqvms+eCzwHWzdnc+7TE7V646u228Dq4t7aZOiRLZ7Ek WFIqCJ4Uz5T5qgAxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVo dHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkx ITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDA317MAkGBSsOAwIaBQCgggGHMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTEyMTA1Mzg0OVowIwYJ KoZIhvcNAQkEMRYEFDdhF3A0/EOPlEAat1/v6m0Hj3tAMIGRBgkrBgEEAYI3EAQxgYMwgYAweTEQ MA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQD ExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2Vy dC5vcmcCAwN9ezCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwG A1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0 aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwN9ezANBgkqhkiG9w0B AQEFAASCAQB6PHmhOblH/ryJ87Azqho8GYynVwlQvipSNRJ6IhhF26PA0UcnqcNB0HfTda6Fc6J6 Trzb2bpLQyDpmk+oCY2MySrDQGTeSmPsukkOIkGwt1Zzf8BTWLUFnP2528woFhsQOic6c0Oy6FIs rq9s7OurGCFJyAMttobWS74ZYQaHeYvFlXE0WYqYCa2LNB9Jc1pspe1vONEQ+8TuqUfQ5zweDmVY HQNHTRYkVCs1yF8PS0vTVsCsO11Xbyqrokggk7YWRlJFHTYD/gdKsVvSMhWrz+sSQZxYM6jRtG6Z 2ERVpjxQuRj7yhbXCNHgqDv5EZOp0Vzu16aXoDMcRrbafhe7AAAAAAAA --Apple-Mail-24--169373690-- From hash-forum@nist.gov Fri Nov 21 00:32:24 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAL8WJ2a012232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Nov 2008 00:32:20 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAL8UhGh002433; Fri, 21 Nov 2008 03:30:47 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAL8TlQ5029271; Fri, 21 Nov 2008 03:29:47 -0500 Date: Fri, 21 Nov 2008 03:29:47 -0500 Message-Id: <2a9a3e6a0811210016v7f8b993dg668ddc9890cd1d0a@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Chen Ke-Fei Lin" To: Multiple recipients of list Subject: Re: Cryptanalysis of Edon-R X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <491dc202.130c420a.03ae.6ebd@mx.google.com> <49242e79.1c048e0a.182d.2c5a@mx.google.com> <49245f3b.2006420a.11c6.ffffb7e0@mx.google.com> Content-Type: multipart/alternative; boundary="----=_Part_16066_5852813.1227255414294" MIME-Version: 1.0 In-Reply-To: X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 21 Nov 2008 00:32:20 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 222 ------=_Part_16066_5852813.1227255414294 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wed, Nov 19, 2008 at 10:54 PM, Dmitry Khovratovich < khovratovich@gmail.com> wrote: > > Well, the gap between 2^n and 2^{2n/3} seems to be too large to be covered > with the search expenses. > > Ha, ha, You selling pineapples as apples. I mean: Every yours hash computation in 2^{2n/3} accompanied by search in 2^{2n/3} set, is pineapple. (and pineapples more expensive than apples) Every hash computation in 2^n brute force attack is apple. C.K.F. Lin ------=_Part_16066_5852813.1227255414294 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wed, Nov 19, 2008 at 10:54 PM, Dmitry Khovratovich <khovratovich@gmail.com> wrote:

Well, the gap between 2^n and 2^{2n/3} seems to be too large to be covered with the search expenses.



Ha, ha,

You selling pineapples as apples.

I mean: Every yours hash computation in 2^{2n/3} accompanied by search in 2^{2n/3} set, is pineapple. (and pineapples more expensive than apples)
Every hash computation in 2^n brute force attack is apple.

C.K.F. Lin

------=_Part_16066_5852813.1227255414294-- From hash-forum@nist.gov Fri Nov 21 01:53:59 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAL9rsi2021789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Nov 2008 01:53:55 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAL9qY1f005085; Fri, 21 Nov 2008 04:52:41 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAL9pJIv021032; Fri, 21 Nov 2008 04:51:19 -0500 Date: Fri, 21 Nov 2008 04:51:19 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Dmitry Khovratovich" To: Multiple recipients of list Subject: Re: Cryptanalysis of Edon-R X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <491dc202.130c420a.03ae.6ebd@mx.google.com> <49242e79.1c048e0a.182d.2c5a@mx.google.com> <49245f3b.2006420a.11c6.ffffb7e0@mx.google.com> <2a9a3e6a0811210016v7f8b993dg668ddc9890cd1d0a@mail.gmail.com> Content-Type: multipart/alternative; boundary="----=_Part_97232_14046223.1227260681665" MIME-Version: 1.0 In-Reply-To: <2a9a3e6a0811210016v7f8b993dg668ddc9890cd1d0a@mail.gmail.com> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 21 Nov 2008 01:53:55 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 223 ------=_Part_97232_14046223.1227260681665 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri, Nov 21, 2008 at 9:29 AM, Chen Ke-Fei Lin wrote: > On Wed, Nov 19, 2008 at 10:54 PM, Dmitry Khovratovich < > khovratovich@gmail.com> wrote: > >> >> Well, the gap between 2^n and 2^{2n/3} seems to be too large to be covered >> with the search expenses. >> >> > > Ha, ha, > > > You selling pineapples as apples. Serious argument. > > > I mean: Every yours hash computation in 2^{2n/3} accompanied by search in > 2^{2n/3} set, is pineapple. (and pineapples more expensive than apples) > Every hash computation in 2^n brute force attack is apple. Do you claim that search in 2^{2n/3} takes more than 2^{n/3} hash computations? > > -- Best regards, Dmitry Khovratovich ------=_Part_97232_14046223.1227260681665 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Fri, Nov 21, 2008 at 9:29 AM, Chen Ke-Fei Lin <chen.ke.fei.lin@gmail.com> wrote:
On Wed, Nov 19, 2008 at 10:54 PM, Dmitry Khovratovich <khovratovich@gmail.com> wrote:

Well, the gap between 2^n and 2^{2n/3} seems to be too large to be covered with the search expenses.



Ha, ha,
 


You selling pineapples as apples.

Serious argument.
 


I mean: Every yours hash computation in 2^{2n/3} accompanied by search in 2^{2n/3} set, is pineapple. (and pineapples more expensive than apples)
Every hash computation in 2^n brute force attack is apple.


Do you claim that search in 2^{2n/3}  takes more than 2^{n/3} hash computations?
 

--
Best regards,
Dmitry Khovratovich
------=_Part_97232_14046223.1227260681665-- From hash-forum@nist.gov Fri Nov 21 05:05:52 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mALD5lfv007689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Nov 2008 05:05:48 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mALD4HSo023996; Fri, 21 Nov 2008 08:04:22 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mALD2usV004904; Fri, 21 Nov 2008 08:02:56 -0500 Date: Fri, 21 Nov 2008 08:02:56 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Ivica Nikolic" To: Multiple recipients of list Subject: Preimage attack on Sarmal-512 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/alternative; boundary="----=_Part_100630_28740922.1227272210731" MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 21 Nov 2008 05:05:48 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 224 ------=_Part_100630_28740922.1227272210731 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, we found a preimage attack on Sarmal-512 that requires max(2^{512-s},2^{256+s}) computations and 2^s memory. The paper is available at: http://lj.streamclub.ru/papers/hash/sarmal.pdf Best regards, Ivica Nikolic Laboratory of Algorithms, Cryptography and Security, University of Luxembourg, ------=_Part_100630_28740922.1227272210731 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

we found a preimage attack on Sarmal-512 that requires max(2^{512-s},2^{256+s}) computations and 2^s memory.
The paper is available at:
http://lj.streamclub.ru/papers/hash/sarmal.pdf

Best regards,

Ivica Nikolic
Laboratory of Algorithms, Cryptography and Security,
University of Luxembourg,

------=_Part_100630_28740922.1227272210731-- From hash-forum@nist.gov Fri Nov 21 05:19:27 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mALDJMZc009399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Nov 2008 05:19:23 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mALDHwbJ011658; Fri, 21 Nov 2008 08:18:00 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mALDHfGK001011; Fri, 21 Nov 2008 08:17:41 -0500 Date: Fri, 21 Nov 2008 08:17:41 -0500 Message-Id: <20081121131131.87037.qmail@cr.yp.to> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "D. J. Bernstein" To: Multiple recipients of list Subject: Re: Cryptanalysis of Edon-R X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas In-Reply-To: X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 21 Nov 2008 05:19:23 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 225 Dmitry Khovratovich writes: > Do you claim that search in 2^{2n/3} takes more than 2^{n/3} hash > computations? You _can_ do a lookup in time proportional to only 2^(n/3) on a standard two-dimensional circuit of size 2^(2n/3). You have only 2^(2n/3) lookups to do, so you can finish all of them in time proportional to 2^n. However, the same time bound O(2^n) can be achieved by a standard brute-force search circuit containing _one_ hashing circuit and a tiny amount of storage. This is much, much, much less expensive than your stupendously large attack machine. Furthermore, a standard brute-force search circuit of size 2^(0.4n) finds preimages in time proportional to 2^(0.6n). Compared to your attack machine, this is simultaneously much, much, much less expensive _and_ much, much, much faster. There are other big advantages of brute force---attacking p preimages at once is p times more cost-effective than attacking one preimage, for example, and success probability drops off only _linearly_ with time (whereas many other attacks drop off quadratically)---but, whether or not these advantages are applicable, the attacker would have to be completely insane to choose your attack. > complexity is usually measured in the number of computations In baby algorithms courses? Yes. There's a common belief that students can't handle anything more complicated than counting instructions. In supercomputing? Of course not. Accessing storage is fundamentally much more expensive than carrying out local computation, and the costs grow with the amount of storage, so machine cost and computation time are very poorly predicted by simple instruction counts. The number-field sieve, for example, can find primes by pure sieving, but NFS implementations actually use a combination of sieving and ECM, with ECM playing an increasingly critical role in larger computations. This change produces a drastic _increase_ in the number of instructions but an even more drastic _improvement_ in price-performance ratio. I suppose that one could mindlessly compare * the number of simplified textbook descriptions of NFS that use pure sieving (frequently commenting on how few instructions are used by sieving) to * the number of NFS software and hardware implementation papers that use sieving+ECM (usually commenting on the relevant costs), but the simple fact is that sieving+ECM is _better_ than pure sieving; people actually finishing record-setting computations are not following the oversimplified instruction-counting model. Sometimes cryptanalytic papers are written by people without any supercomputing experience. Those papers often have massively inaccurate cost evaluations. Occasionally the computations are important enough to trigger subsequent implementation papers correcting the erroneous cost evaluations; but if an attack is claimed to take "time 2^200" and "space 2^200," and isn't properly generalized to cover smaller computations, then it's not easy to write an implementation paper! ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago From hash-forum@nist.gov Fri Nov 21 06:28:32 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mALESQf0008907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Nov 2008 06:28:28 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mALEQdSl021888; Fri, 21 Nov 2008 09:26:43 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mALEPkDx008192; Fri, 21 Nov 2008 09:25:46 -0500 Date: Fri, 21 Nov 2008 09:25:46 -0500 Message-Id: <59765.143.107.111.183.1227277108.squirrel@webmail.larc.usp.br> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Paulo S. L. M. Barreto" To: Multiple recipients of list Subject: An observation on Groestl X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain;charset=iso-8859-1 MIME-Version: 1.0 X-To: hash-forum@nist.gov References: In-Reply-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 21 Nov 2008 06:28:28 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 226 There is an interesting alternative way (N.B. this is *not* an attack) to look at the Groestl compression function f, namely, as conventional Davies-Meyer on top of an Even-Mansour cipher. This observation may be applicable to CRUNCH as well, but given its much more involved description I don't want to be commit to that right now. Details in . Paulo Barreto. From hash-forum@nist.gov Sat Nov 22 14:07:50 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAMM7iCD020258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 22 Nov 2008 14:07:45 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAML6nJo028252; Sat, 22 Nov 2008 16:06:51 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAML55N7016613; Sat, 22 Nov 2008 16:05:05 -0500 Date: Sat, 22 Nov 2008 16:05:05 -0500 Message-Id: <000001c94ce5$812a3ae0$837eb0a0$@org> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "John Washburn" To: Multiple recipients of list Subject: Reference implementation for Ponic X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Microsoft Office Outlook 12.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 In-Reply-To: <59765.143.107.111.183.1227277108.squirrel@webmail.larc.usp.br> References: <59765.143.107.111.183.1227277108.squirrel@webmail.larc.usp.br> X-Cc: X-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: Delayed for 00:59:37 by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 22 Nov 2008 14:07:46 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 227 Is there a link to the reference implementation for Ponic? http://ehash.iaik.tugraz.at/wiki/Ponic I have worked my way down to the P's and have four questions on the Ponic implementation. Question One There is the probable typo on page 1: Should the statement >> represents bitwise shift left operation. Actually read: >> represents bitwise shift *right* operation ? The remaining 3 questions are regarding the definition of the circular shift registers. 1) In which direction is the shift (left or right)? 2) What it mean to "step" a circular shift register? I infer it means the circular shift register is shifted one bit. I infer this answer because of the next question. 3) What is the output of a Ponic circular shift register? I infer that it is the single bit which is rotated out one end of the CSR and rotated into the other end. I infer the output is a single bit because steps 1a, 1b, and 1c of the round function admit only one bit of information upon which to decide the conditional "stepping" of CSR(n-1) or CRS(N+1) If Peter Schmidt-Nielsen is on this list serve, can you answer the above questions or provide a link to the reference implementation? If anyone has his email or other contact information can you pass one these questions. In Liberty, John Washburn P.S. Here is the excerpt from the paper cited above. 1. for each n from 0 to 5 a. csr(n) is stepped, and the output saved. b. if the output is 1, csr(n-1 modulo 6) is stepped, discarding the output. c. if the output is 0, csr(n+1 modulo 6) is stepped, discarding the output. From hash-forum@nist.gov Sun Nov 23 17:44:27 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAO1iJH4020069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 23 Nov 2008 17:44:21 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAO0gO0B023324; Sun, 23 Nov 2008 19:42:28 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAO0egCY012060; Sun, 23 Nov 2008 19:40:42 -0500 Date: Sun, 23 Nov 2008 19:40:42 -0500 Message-Id: <4A43B7BD5F98824E8DB2C49495BFB4BB3B9931459E@GVW0673EXC.americas.hpqcorp.net> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Haber, Stuart (HPL Princeton)" To: Multiple recipients of list Subject: RE: longevity [was RE: do we really need...was: Preimage attacks...] X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" In-Reply-To: References: <4923B12D.1000702@mit.edu> <9418DB6C0B9D434190E54A78E931C3D1086429A7@XCH-NW-7V1.nw.nos.boeing.com> <4A43B7BD5F98824E8DB2C49495BFB4BB3B988B6F5E@GVW0673EXC.americas.hpqcorp.net> X-To: "hash-forum@nist.gov" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: Delayed for 01:00:20 by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sun, 23 Nov 2008 17:44:22 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 228 Bob, No, you've misunderstood, I am indeed concerned with maintaining the integrity of the original document itself -- and the way I suggest doing so has the side-effect of extending the integrity of the original time-stamp certificate. As you wrote, it is indeed "necessary to rehash the entirety of the original file with the new hash function" -- along with some other information -- as spelled out in my note (to repeat, at www.hpl.hp.com/techreports/2007/HPL-2007-58.html). If you're trying to use a new hash function to guarantee the integrity of an old file, you've really got to expect to have to touch once again every bit of the file in question. The renewing process must take place at a time that is *before* any catastrophic preimage-computing break of the original hash function -- an event that in real life we can't hope to pinpoint exactly, but this competition is evidence that the community tries its best to adopt new hash functions before the catastrophe arrives. I agree with Bob that "That's probably enough on this thread". Anyone who's interested is welcome to discuss this outside the mailing list. -- Stuart -----Original Message----- From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Robert Jueneman Sent: Thursday, November 20, 2008 6:47 PM To: Multiple recipients of list Subject: RE: longevity [was RE: do we really need...was: Preimage attacks...] I'm not trying to be completely unrealistic here. If we can design something that will last 100 years, I'll be perfectly happy. (Dead, but happy.) If it doesn't last for 1000, or perhaps the 10,000 years the Mormons would probably like, my great-great-great-grandkids can worry about it -- the media probably won't be readable anyway! However, from an academic perspective, unless I misread or misunderstand it, Stuart's note was primarily concerned about maintaining the integrity of the original TIME-STAMP, as opposed to the integrity of the document itself. If someone discovers a method of generating a collision on demand for SHA-X, then they would be able to generate a new text, one that is beneficial to those currently living that would match the original hash and the timestamp, as well as the new timestamp. So instead of merely updating or resigning the hash/signature, it is necessary to rehash the entirely of the original file with the new hash function. Generating several quadrillion hash functions would be bad enough, but reprocessing millions of exabytes of data would be a really daunting task. That's probably enough on this tread. I know from previous discussions that some people are particularly concerned with computing modest hash functions on minimal hardware, e.g., for RFID tags and similar applications. So be it. But for digital signatures with extended longevity, a 512-bit or even a 1024-bit hash (if that should ever be proposed) is a trivial amount of data to store, and a almost trivial amount of computation, compared to the volume of data being processed. Peace. Bob -----Original Message----- From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Haber, Stuart (HPL Princeton) Sent: Thursday, November 20, 2008 2:25 PM To: Multiple recipients of list Subject: longevity [was RE: do we really need...was: Preimage attacks...] I completely agree with both Larry and Bob about the importance of the problem of ensuring integrity for very long-lived digital objects. But as I pointed out at the second NIST hash bash (just after Crypto '06), a cryptographic guarantee of integrity that will last for a hundred years does not require that we design a hash function now that will withstand all of the next century's engineering and algorithmic advances. Rather, we can use the availability of a new hash function design to "renew" integrity certificates (i.e. digital signatures, time-stamp certificates, or even simple lists of hash values) that were computed with a current hash function that is about to be deprecated. Some years later, when the advent of a surprising advance in quantum nanocomputer cryptanalysis motivates the standards-blessed adoption of an even newer hash function before the expected collapse of SHA-3, renewed certificates can be renewed yet again. The renewing process must be performed carefully, as described at http://www.hpl.hp.com/techreports/2007/HPL-2007-58.html (or at http://eprint.iacr.org/2007/238). -- Stuart -----Original Message----- From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Robert Jueneman Sent: Wednesday, November 19, 2008 3:59 PM To: Multiple recipients of list Subject: RE: do we really need a 512-bit hash was: Preimage attacks on CubeHash... I completely agree with Larry. Air-worthiness certificates, student loan records, medical records, and even mortgage records and other long-term contracts impose exceedingly difficult requirements in term of the longevity of a digital signature -- easily approaching 100 years. People sometimes assume that someone else (typically the next administration, or the next CEO, or the tooth fairy), will somehow be motivated to go back and revalidate and re-sign all of those documents, but I submit that just ain't gonna happen. If it is signed once, that's likely to be it, period. (Being able to READ all of those document 100 years from now is a different challenge, but not one for this discussion.) In talks I have given, I've made the point that one of my ancestors, one Don Louis Lorimer, who founded of Cape Girardeau, MO, in 1793, figures prominently in TWO U.S. Supreme Court cases, one of which was brought by my grandmother in 1946. She contested the transference of a major piece of land to the U.S. Government that had been bequeathed to the city nearly a century and a half earlier for certain beneficent purposes, saying in effect, "if you aren't going to use the property in accordance with the terms of the will, please give it back to the heirs and successors, namely me." (She lost, in a landmark case that for the first time established the right of eminent domain of the U.S. Government against another governmental agency, namely the city.) So here I am, citing a U.S. Supreme Court case that involved records from 200 years ago. Other ancestral records go back even further, to the time of Charlemagne, over 1200 years ago. Clearly, no one has a crystal ball good enough to predict the future of technology over the next 1000 years,. But I remember when IBM and NIST confidently proclaimed that single-DES would be secure for many centuries, and yet it survived for less than three decades. I designed a couple of the earliest hash functions, QCMDCV4, only to have Don Coppersmith break it within a few months (thereby convincing me that I shouldn't participate in these competitions, except as a interested observer). Ron Rivest's contributions (MD2, MD4, MD5) have lasted a considerably longer, but even NSA's contributions (SHA-0, SHA-1) are now endangered if not broken. So although I agree that length does not necessarily imply strength, I would certainly urge a very conservative approach. A 512-bit hash is certainly not too long to deal with -- not when we have terabytes of storage on a desktop these days, and gigabit LANs. Bob Robert R. Jueneman Chief Scientist SPYRUS, Inc. -----Original Message----- From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Bugbee, Larry Sent: Tuesday, November 18, 2008 10:59 PM To: Multiple recipients of list Subject: do we really need a 512-bit hash was: Preimage attacks on CubeHash... Tom St Denis wrote: > > Steven M. Bellovin wrote: >> >>> we have found preimage attacks ... >>> that require $2^{496}$ and $2^{480}$ computations respectively and >>> negligible memory. [...] > Which raises the question "do we really need a 512-bit hash?" Of > course the answer is "not really." I have to disagree, at least for some applications. We have some electronic "documents" that, under ideal conditions, are to be signed and retained for the "life-of-the-airplane" plus 50 years. ...and DC-3s are still flying. You can do the math. While we all know this won't happen, we do need to do the best we can. If we can find ways to push good integrity out 30+ years, perhaps our successors will find a way to extend it another 30 years. ...and so on. There are at least a half dozen possible schemes, each with their issues, but the most promising is a combination. One essential element, however, is to apply several very strong hashes signed with strong keys and algorithms. Besides strength, we want redundancy providing us with a window of time to re-group. It is not perfect, but we must do the best we can. We very much want to see several strong hash algorithms survive this competition. Their length is secondary. Larry From hash-forum@nist.gov Mon Nov 24 05:58:58 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAODwqld022472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 24 Nov 2008 05:58:54 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAODuenI020948; Mon, 24 Nov 2008 08:56:44 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAODt7N5011994; Mon, 24 Nov 2008 08:55:07 -0500 Date: Mon, 24 Nov 2008 08:55:07 -0500 Message-Id: <20081124134440.GA25036@titan.cry.pto> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Thomas Pornin To: Multiple recipients of list Subject: Re: longevity [was RE: do we really need...was: Preimage attacks...] X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas In-Reply-To: <4A43B7BD5F98824E8DB2C49495BFB4BB3B9931459E@GVW0673EXC.americas.hpqcorp.net> Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 References: <4923B12D.1000702@mit.edu> <9418DB6C0B9D434190E54A78E931C3D1086429A7@XCH-NW-7V1.nw.nos.boeing.com> <4A43B7BD5F98824E8DB2C49495BFB4BB3B988B6F5E@GVW0673EXC.americas.hpqcorp.net> <4A43B7BD5F98824E8DB2C49495BFB4BB3B9931459E@GVW0673EXC.americas.hpqcorp.net> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 24 Nov 2008 05:58:54 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 229 On Sun, Nov 23, 2008 at 07:40:42PM -0500, Haber, Stuart (HPL Princeton) wrote: > The renewing process must take place at a time that is *before* any > catastrophic preimage-computing break of the original hash function There is a standard format for that; it is called "Evidence Record Syntax", published in August 2007 as RFC 4998. It includes provisions for renewal of time stamps, and of hash functions, the latter indeed requiring a complete rehash of the original data with a new hash function. Note that the hash function renewal needs to be performed before the actual attack on the protected data. Pinpointing that moment is not easy, and we have to resort to an approximation, namely that actual attacks on _our_ data should occur only after, or at least not long before, the publication of a cryptanalysis method in the academic circles. A further approximation is to assume that such publications are preceded by years of warnings (e.g. collisions on the compression function, which for MD5 were published in 1996, eight years before the actual 2004 collision attack). A simple additional protection is to compute _two_ ERS with distinct hash functions, which hopefully will not be broken simultaneously. This shows that even if the future SHA-3 is defined to be _the_ rock-solid standard hash function, having other sturdy hash functions around is also a good idea. Hopefully, the NIST competition will isolate quite a few "good" functions, not just one. One may notice that RFC 4998 uses hash trees to share time stamps (this is used to apply an evidence record on a group of documents, and also to compute several distinct evidence records with the cost of a single time stamp). Time stamps are normally resilient to collisions (a signature computed over a colliding pair just proves that both inputs existed at the signature date, which is true); a time stamp is defeated only with a a second-preimage attack. This is not true, however, in the presence of hash trees, where an attack may become substantially cheaper than a full second-preimage. Cheaper, but no cheaper than a collision attack. This means that in the context of RFC 4998 evidence records, one should use resistance to _collisions_ as the baseline for assessing security. --Thomas Pornin From hash-forum@nist.gov Tue Nov 25 01:33:55 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAP9XnRG026193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 25 Nov 2008 01:33:50 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAP9QjMN006669; Tue, 25 Nov 2008 04:26:50 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAP9P0CX020577; Tue, 25 Nov 2008 04:25:00 -0500 Date: Tue, 25 Nov 2008 04:25:00 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Dmitry Khovratovich" To: Multiple recipients of list Subject: Cryptanalysis of DCH X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/alternative; boundary="----=_Part_1706_15090995.1227604564768" MIME-Version: 1.0 X-To: "Multiple recipients of list" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 25 Nov 2008 01:33:50 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 230 ------=_Part_1706_15090995.1227604564768 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, the DCH compression function does not take H_{i-1} as an input to the non-linear transformation. This leads to the attack based on the generalized birthday paradox, which we describe in http://lj.streamclub.ru/papers/hash/dch.pdf Both collisions and preimages can be found in 2^45 computations and memory. David Wilson, the author, also published the note on the attack on his web-site: http://web.mit.edu/dwilson/www/hash/ -- Best regards, Dmitry Khovratovich and Ivica Nikolic University of Luxembourg, Laboratory of Algorithms, Cryptography and Security, + 352 46 66 44 5478 ------=_Part_1706_15090995.1227604564768 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all,

the DCH compression function does not take H_{i-1} as an input to the non-linear transformation. This leads to the attack based on the generalized birthday paradox, which we describe in http://lj.streamclub.ru/papers/hash/dch.pdf

Both collisions and preimages can be found in 2^45 computations and memory.

David Wilson, the author, also published the note on the attack on his web-site: http://web.mit.edu/dwilson/www/hash/


--
Best regards,
Dmitry Khovratovich and Ivica Nikolic

University of Luxembourg,
Laboratory of Algorithms, Cryptography and Security,
+ 352 46 66 44 5478
------=_Part_1706_15090995.1227604564768-- From hash-forum@nist.gov Thu Nov 27 03:27:14 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mARBR9HN028290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 27 Nov 2008 03:27:10 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mARBQ0GW012516; Thu, 27 Nov 2008 06:26:03 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mARBPhKU027484; Thu, 27 Nov 2008 06:25:43 -0500 Date: Thu, 27 Nov 2008 06:25:43 -0500 Message-Id: <492E81FF.5080300@iaik.tugraz.at> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Florian Mendel To: Multiple recipients of list Subject: Re: Cryptanalysis of DCH X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090502030302040407070500" In-Reply-To: References: MIME-Version: 1.0 X-CC: Dmitry Khovratovich , dwilson@mit.edu X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: Delayed for 00:26:51 by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 27 Nov 2008 03:27:10 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 231 This is a cryptographically signed message in MIME format. --------------ms090502030302040407070500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, We have found a practical collision and preimage attack on DCH-n. The attack is based on the observation of Khovratovich and Nikolic that the chaining value is not used in the underlying block cipher. The attack is described in: http://ehash.iaik.tugraz.at/uploads/9/9b/Dch.pdf best regards, Florian Mendel -- Florian Mendel, IAIK - Graz University of Technology __ Inffeldgasse 16a, 8010 Graz, Austria __ _| |_ Tel: +43 316 873 5505 | || | Fax: +43 316 873 5594 |_ _||__| http://www.iaik.tugraz.at |__| IAIK --------------ms090502030302040407070500 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIa/jCC BLMwggOboAMCAQICARYwDQYJKoZIhvcNAQEFBQAwQTEQMA4GA1UEChMHRXVyb1BLSTEtMCsG A1UEAxMkRXVyb1BLSSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTIyODA5 NTA1MloXDTEwMTIzMTExNTkwMFowUjELMAkGA1UEBhMCQVQxEDAOBgNVBAoTB0V1cm9QS0kx MTAvBgNVBAMTKEV1cm9QS0kgQXVzdHJpYW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1hZUNUa0lyv5ttAn7ZRyfI4zO+Bc2fmTi lpAIBfJ/2yqfdHKCd/r2czeCme85S298uhCrDtKZXQp6wZpxGsZrZw5n8mrXVVy6HUTFTyKa pz/4W3vS0f3fKljpUioJ9lBUwQyARDcNzCP63+Iv9OqrHgb4QoSfmDlrX5KmaGDaEgoNYbkY wFDn0b81I16j8mXDDECtQM/ZsxzjkHZz1ks3jl/q9EW1OxdD6ytgsePXzfmfWjdwsB8KyjXI UNpLMBzPK3qTjwevGUQjfCCJ1hC26t2G9BWPcHUUw0/4gCL/jGDLUAmMWo1z1H/gyk9VrTsU uP3HZ7fElMpfqmIqyr69AgMBAAGjggGjMIIBnzBMBglghkgBhvhCAQ0EPxY9SXNzdWVkIHVu ZGVyIHBvbGljeToKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzBk BggrBgEFBQcBAQRYMFYwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwLmV1cm9wa2kub3JnOjgw MjYwKgYIKwYBBQUHMAKGHmh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdDA7BgNVHR8E NDAyMDCgLqAshipodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3JsL2NybC5kZXIw TgYDVR0gBEcwRTBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93d3cuZXVy b3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzAdBgNVHQ4EFgQUdCnYUa/CPJin1/8xj0D3UOgH AegwHwYDVR0jBBgwFoAUjNyLsaVKkOdOiHMYPJ3VXn7kss0wDAYDVR0TBAUwAwEB/zAOBgNV HQ8BAf8EBAMCAfYwDQYJKoZIhvcNAQEFBQADggEBALvbHv34QJkgCzJ92trxCWkGmeahGFQ8 ZQCFlgeaAI5d2B8K9XVJ7IduoETxq+evWfDaiUBHahQ6c2oC9uhuqI4pzJpsEJimYpccHRBA 85S5spyfLfpboY1lSGraFxZwTsV9+wGftlCOZy3UF9Ip0VLP1wrRsTvfCBjLybj45ay3L3o5 F+MojQ2VPC0w/z56yD9caU+fl2pJSU7Q5fUlUfYD0PexVzDEWX4r3lGn6G5UD/zC8zNqH7fh sJxsH/TeraHbvUk8AZu4IULWzrpytR7JpOX/VRfeF65foy7GoTkBuGPx9EsbXJzZ/ygab947 O5yIAqr6bibMh7i1ZDcpnacwggU3MIIEH6ADAgECAgcCQt/N+2FTMA0GCSqGSIb3DQEBBQUA MFIxCzAJBgNVBAYTAkFUMRAwDgYDVQQKEwdFdXJvUEtJMTEwLwYDVQQDEyhFdXJvUEtJIEF1 c3RyaWFuIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA4MDIyODE1MTgwNVoXDTEzMDIy ODE1MTgwNVowgb0xLTArBgNVBAMTJEV1cm9QS0kgSUFJSyBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEmMCQGA1UEChMdR3JheiBVbml2ZXJzaXR5IG9mIFRlY2hub2xvZ3kxSDBGBgNVBAsT P0luc3RpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21t dW5pY2F0aW9uczENMAsGA1UEBxMER3JhejELMAkGA1UEBhMCQVQwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCVatVA1TczvPSG2IZoIPtEBXNgZSdUx58syuOEoZs9HOc0MocB 2ko3jIDfB9YIP7bLEag1yjrlO8GxfkBCiTQvnfNDEIMvetuwJmHSgaTxJ3PRlOWDJMi/IbNe X1yq2sOYyszpbK5/jm6JAl/XbYNmNuiPxx2PR3iVZBL4v38sF7o0x/ale5P7RmW4KXq36Mpc /KaAW4cMrDUAGNqcc9EIwkTAx1moGt8u7v/CTgWIilXbhB1BBBjp+Cy9ukBX+HnwimWlAcKF DTqmwFmgJA+QlCEQYHs0o2ylWF+41N8MivLlYqvqQlpOFqWStBpKr8lxkcjpFRzFry2ORWlK 16+bAgMBAAGjggGkMIIBoDAOBgNVHQ8BAf8EBAMCAcYwDwYDVR0TAQH/BAUwAwEB/zAdBgNV HQ4EFgQUOXTH3cjx+wpwPQ7KfUUCrKGb154wVgYDVR0gBE8wTTBLBgwrBgEEAZUSAQIBAQEw OzA5BggrBgEFBQcCARYtaHR0cDovL2V1cm9wa2kuaWFpay5hdC9jYS9ldXJvcGtpLWF0L2Nw cy8xLjEvMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jYS5pYWlrLnR1Z3Jhei5hdC9jYXBz by9jcmxzL0V1cm9QS0lBdXN0cmlhbi5jcmwwgZoGCCsGAQUFBwEBBIGNMIGKMEIGCCsGAQUF BzABhjZodHRwOi8vY2EuaWFpay50dWdyYXouYXQvY2Fwc28vT0NTUD9jYT1FdXJvUEtJQXVz dHJpYW4wRAYIKwYBBQUHMAKGOGh0dHA6Ly9jYS5pYWlrLnR1Z3Jhei5hdC9jYXBzby9jZXJ0 cy9FdXJvUEtJQXVzdHJpYW4uY2VyMB8GA1UdIwQYMBaAFHQp2FGvwjyYp9f/MY9A91DoBwHo MA0GCSqGSIb3DQEBBQUAA4IBAQCmsYc+Rdrfd3sV8jqDipRkd/BGEwGFiWydTmEMRimyr2Sm qNVX4khjAEyLcVjyYK+Fc+XREwOttYcKQHFKaRZRDby0RvniwP3LX1Du3xXnEHij9oB6A2aE Tg1ouAnCikXQQ4C3eBfM9vaK9VR0k/akaqKzTTPBl8ao7TmOfTTdIBrVSoPYjeXR/qm1A34n Pb0gR5sBMEZEcZgDN2oKSDsrK2bHp7AG36R/AtnGyW4j1hI5hR35VCmAToz4dbUKhZjDFJU+ FgmANAWh0+AetShQ7qpS6IyHXxdDGYW/7SHbwWsi4pmRnRm/xaYLVCo3zRJDwaXq3JlKOh2V if4IFzAgMIIFgDCCBGigAwIBAgIHA0DrJxk2fDANBgkqhkiG9w0BAQUFADCBvTEtMCsGA1UE AxMkRXVyb1BLSSBJQUlLIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSYwJAYDVQQKEx1HcmF6 IFVuaXZlcnNpdHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/SW5zdGl0dXRlIGZvciBBcHBs aWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMQ0wCwYDVQQH EwRHcmF6MQswCQYDVQQGEwJBVDAeFw0wODAyMjgxNTQ0MTdaFw0xMzAyMjgxNTQ0MTdaMIGs MRwwGgYDVQQDExNFdXJvUEtJIElBSUsgU2lnIENBMSYwJAYDVQQKEx1HcmF6IFVuaXZlcnNp dHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/SW5zdGl0dXRlIGZvciBBcHBsaWVkIEluZm9y bWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMQ0wCwYDVQQHEwRHcmF6MQsw CQYDVQQGEwJBVDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALBs2U2/lTXnomXh gNULWkAXS507A6UtmsbrAIXXK7XIWgyjbKiYASrdej0LPKGuFtxbZ+A/e1cSV8yrCWsB+4s8 jZwL+xbWeXIGcaKarv0npeXSqX0UZl7DM5mVID+FwG1T73qjmIGvE6i5qDnNEv0siGeit7m0 AH3dF2uckq6eKuozAvchlJOQk27PqaPRFCS5APiCNBrB9AUShjXMHso1wC1raxlsGDc/yneC 2Z4OOBZLkswPIMu0qUwVfGVR7u3WFLEP3cPXw8lWb1Ka8GzGLBivt4PRz+wyibDfWx/i/Snh TzfEuB4y1PFjvsFQ3o3am2zHpqvy1WPfUsxRLQ0CAwEAAaOCAZIwggGOMA4GA1UdDwEB/wQE AwIBxjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSu7lUGF3pTERMYq6TOHHEJGoMU8zBQ BgNVHSAESTBHMEUGDCsGAQQBlRIBAgMBATA1MDMGCCsGAQUFBwIBFidodHRwOi8vZXVyb3Br aS5pYWlrLmF0L2NhL2lhaWsvY3BzLzEuMy8wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2Nh LmlhaWsudHVncmF6LmF0L2NhcHNvL2NybHMvRXVyb1BLSUlBSUsuY3JsMIGSBggrBgEFBQcB AQSBhTCBgjA+BggrBgEFBQcwAYYyaHR0cDovL2NhLmlhaWsudHVncmF6LmF0L2NhcHNvL09D U1A/Y2E9RXVyb1BLSUlBSUswQAYIKwYBBQUHMAKGNGh0dHA6Ly9jYS5pYWlrLnR1Z3Jhei5h dC9jYXBzby9jZXJ0cy9FdXJvUEtJSUFJSy5jZXIwHwYDVR0jBBgwFoAUOXTH3cjx+wpwPQ7K fUUCrKGb154wDQYJKoZIhvcNAQEFBQADggEBAAgys3wJ2CixcC8KuuO3a9k8u0nT0+PafLR9 wMQMWsz7xDTLNxiTJKnLvdFw86D+CH+nXxRweo/KDVYT56q5rfKs45I6mZDV+z/wecNX3odW MuY5a6j0g/RR4Qz/wokfeUzff5Yi6Hh1P9ce0u3/EHAHancJI3FxoZpLU5qNWZNo+fI6nluO BmdJCWZgCR9ijucmFubnu4EbWlyhiH2e0H2taU6zWvW/83yqbEO0BhDKVWWVtWvlF/ptBZQE JzAD1q5XJobPNQ/IANfs5ZcfuC1+Pm6FEG0cMVnDCGlRoA57oTIFaODWQPr4gxMy11/MYe9V ufBih5AU1z6V4IwJ5SYwggXAMIIEqKADAgECAgcDpyM/VXyUMA0GCSqGSIb3DQEBBQUAMIGs MRwwGgYDVQQDExNFdXJvUEtJIElBSUsgRW5jIENBMSYwJAYDVQQKEx1HcmF6IFVuaXZlcnNp dHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/SW5zdGl0dXRlIGZvciBBcHBsaWVkIEluZm9y bWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMQ0wCwYDVQQHEwRHcmF6MQsw CQYDVQQGEwJBVDAeFw0wODAzMTExMzM4MDJaFw0xMTAzMTExMzM4MDJaMIHKMRAwDgYDVQQq EwdGbG9yaWFuMQ8wDQYDVQQEEwZNZW5kZWwxFzAVBgNVBAMTDkZsb3JpYW4gTWVuZGVsMSYw JAYDVQQKEx1HcmF6IFVuaXZlcnNpdHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/SW5zdGl0 dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRp b25zMQ0wCwYDVQQHEwRHcmF6MQswCQYDVQQGEwJBVDCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAJrUp6dkhChk2TCNRBC62mrtEpIaA4Ln2mqpd+v4rWhO5RuhXwCI8tAm7Btg i0rqEeHLO0ChvOoEKPrQ+mzm7X7Dr8vE+COvCjqNOPOdHI1j5r1UrblNjsDHKI1X+iRbLAM8 cI4kNS2IazRC4TXoFmGWwHnFUlc2+59r+Nz67M3PsbfTV9SL39tqOMzrn/s3X/UxG0pFu4M5 Eh9k3KNnVBxHyIj7bVSyolaoWtqzW/fxiisIOyy8oBM86VrRFUTBgWAhB/xSx+volwXSn1T8 qZV+MNjV0yyBVZvE1pwR1s3Q4kl5iH9B7n0TOm883ADCs42/Oc/IdbnV86dx8mslM08CAwEA AaOCAcUwggHBMA4GA1UdDwEB/wQEAwIEMDAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBTZa0mn pCOlxZAN6ThSg96rPektTTBQBgNVHSAESTBHMEUGDCsGAQQBlRIBAgMBATA1MDMGCCsGAQUF BwIBFidodHRwOi8vZXVyb3BraS5pYWlrLmF0L2NhL2lhaWsvY3BzLzEuMy8wSAYDVR0fBEEw PzA9oDugOYY3aHR0cDovL2NhLmlhaWsudHVncmF6LmF0L2NhcHNvL2NybHMvRXVyb1BLSUlB SUtfRW5jLmNybDCBmgYIKwYBBQUHAQEEgY0wgYowQgYIKwYBBQUHMAGGNmh0dHA6Ly9jYS5p YWlrLnR1Z3Jhei5hdC9jYXBzby9PQ1NQP2NhPUV1cm9QS0lJQUlLX0VuYzBEBggrBgEFBQcw AoY4aHR0cDovL2NhLmlhaWsudHVncmF6LmF0L2NhcHNvL2NlcnRzL0V1cm9QS0lJQUlLX0Vu Yy5jZXIwKAYDVR0RBCEwH4EdZmxvcmlhbi5tZW5kZWxAaWFpay50dWdyYXouYXQwHwYDVR0j BBgwFoAU3UP298kNEZZgTQSlVkIYEiSm2uowDQYJKoZIhvcNAQEFBQADggEBAFh7b01xzkrx IPd+V+k6wuOfTneZc4KjZ1eKM4PGPkD0D5FeDFqisa6UvR/z/nSL91H2ayBAqTrMgaUDpDS7 R31X5l9pEsq7SHsV5mZfdGPeHMz1Ay/41sCCScWR8PVYmUKm61mQSKcWu4wAJv56QvT5yX3N 0iWjhFzW7/BE1q9VR7SKbjv0hUkvyYzvyQ1x9BFu0RMjFP/5bv1CGjCSiN1ZQaU3c2scLPvp mTxUldR/zNvCxwoEFDoflmLXv4G3ylSOYPckypIBvi2YkIjeVCieCQ3S1XAbNZQPHrvj+RTg 3GXuaxDq0RklE5LqwYd7ta7sj1JviO7eN7uV6EDmgGwwggXAMIIEqKADAgECAgcDrMdbmkE7 MA0GCSqGSIb3DQEBBQUAMIGsMRwwGgYDVQQDExNFdXJvUEtJIElBSUsgU2lnIENBMSYwJAYD VQQKEx1HcmF6IFVuaXZlcnNpdHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/SW5zdGl0dXRl IGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25z MQ0wCwYDVQQHEwRHcmF6MQswCQYDVQQGEwJBVDAeFw0wODAzMTExMzM4MzFaFw0xMTAzMTEx MzM4MzFaMIHKMRAwDgYDVQQqEwdGbG9yaWFuMQ8wDQYDVQQEEwZNZW5kZWwxFzAVBgNVBAMT DkZsb3JpYW4gTWVuZGVsMSYwJAYDVQQKEx1HcmF6IFVuaXZlcnNpdHkgb2YgVGVjaG5vbG9n eTFIMEYGA1UECxM/SW5zdGl0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3Np bmcgYW5kIENvbW11bmljYXRpb25zMQ0wCwYDVQQHEwRHcmF6MQswCQYDVQQGEwJBVDCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALcwiAt5a6AmvwD6BL5zoXRoOl8GdDObLT0R DOludJPlbkdNwaxK9fKQyapL6MZFQftXGRuibqrxYvOV48McAE/LBgRxLUEw4qZDV0XuVb8d bSi+TaIvjy45FcH4O/pDmE05VK5EsLkPczloIa03XW6e186nDjDdHXMwHGbqS08swxLrRy7X PFtbk0yliN4rt1I55CV+2NyoCpGJezk+n1y/sMAylRDTOlpQ/yWS3e6WADVPj3iQsjG2doxQ buv+HnIF5mCWDjg+YpcUrcJX3V66pkCBwlBy74aBkrKdQzEtRUTPILcAlzkYjQm6PcgtI1vK L2DOBDhogF4uVkaqDE8CAwEAAaOCAcUwggHBMA4GA1UdDwEB/wQEAwIGwDAMBgNVHRMBAf8E AjAAMB0GA1UdDgQWBBRDoxdgZX84qas2qxRkqcGJJDqCqDBQBgNVHSAESTBHMEUGDCsGAQQB lRIBAgMBATA1MDMGCCsGAQUFBwIBFidodHRwOi8vZXVyb3BraS5pYWlrLmF0L2NhL2lhaWsv Y3BzLzEuMy8wSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NhLmlhaWsudHVncmF6LmF0L2Nh cHNvL2NybHMvRXVyb1BLSUlBSUtfU2lnLmNybDCBmgYIKwYBBQUHAQEEgY0wgYowQgYIKwYB BQUHMAGGNmh0dHA6Ly9jYS5pYWlrLnR1Z3Jhei5hdC9jYXBzby9PQ1NQP2NhPUV1cm9QS0lJ QUlLX1NpZzBEBggrBgEFBQcwAoY4aHR0cDovL2NhLmlhaWsudHVncmF6LmF0L2NhcHNvL2Nl cnRzL0V1cm9QS0lJQUlLX1NpZy5jZXIwKAYDVR0RBCEwH4EdZmxvcmlhbi5tZW5kZWxAaWFp ay50dWdyYXouYXQwHwYDVR0jBBgwFoAUru5VBhd6UxETGKukzhxxCRqDFPMwDQYJKoZIhvcN AQEFBQADggEBAEip5KId1eGzTC0Dbsx5JSAPj1RlwiEbC3XHZZTlIwVRGU+IEbQ11PstT/5V XQd0uQljtLsol35ByG3d1k5uxe1azTdqLcn5kXeBsGuhMnUhiB3xYXxF79IjtV3EadidO0Jc ULfSVyQDcYyV83VL3mNSIoysoijgiENwEJSZjexrDSXk6YQPbgm6UoH1A1uT3fWwllp5+680 8z5KBb4ea/i3lCgMOogHkG+qiYEyszeJhM6adx9+eLzGdvUdIza3Nb0/1Yrlx/YeR5u7ll+C oix7zjm9mm356X9+UyA1tszPVLWAriSsvaKuVgWDzrfRBxgy1RILFukFJ4NNEtw+DhExggQv MIIEKwIBATCBuDCBrDEcMBoGA1UEAxMTRXVyb1BLSSBJQUlLIFNpZyBDQTEmMCQGA1UEChMd R3JheiBVbml2ZXJzaXR5IG9mIFRlY2hub2xvZ3kxSDBGBgNVBAsTP0luc3RpdHV0ZSBmb3Ig QXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczENMAsG A1UEBxMER3JhejELMAkGA1UEBhMCQVQCBwOsx1uaQTswCQYFKw4DAhoFAKCCAkswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgxMTI3MTExODIzWjAjBgkq hkiG9w0BCQQxFgQUnbJkmR+/OEMn6yldj4WgGR69qG8wUgYJKoZIhvcNAQkPMUUwQzAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgckGCSsGAQQBgjcQBDGBuzCBuDCBrDEcMBoGA1UEAxMTRXVyb1BLSSBJQUlL IEVuYyBDQTEmMCQGA1UEChMdR3JheiBVbml2ZXJzaXR5IG9mIFRlY2hub2xvZ3kxSDBGBgNV BAsTP0luc3RpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBD b21tdW5pY2F0aW9uczENMAsGA1UEBxMER3JhejELMAkGA1UEBhMCQVQCBwOnIz9VfJQwgcsG CyqGSIb3DQEJEAILMYG7oIG4MIGsMRwwGgYDVQQDExNFdXJvUEtJIElBSUsgRW5jIENBMSYw JAYDVQQKEx1HcmF6IFVuaXZlcnNpdHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/SW5zdGl0 dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRp b25zMQ0wCwYDVQQHEwRHcmF6MQswCQYDVQQGEwJBVAIHA6cjP1V8lDANBgkqhkiG9w0BAQEF AASCAQCc0NfhLkPA8P1kWudI3v2XYh20gMlscY0HL8ZBTxeWeqCvJDUQMLFoc5u4u/C5V4LI 6cVtXOTgJyfk39mB74rkgpYTpa6U5Mcshh2QV5XLo6HjWfB9Yt2YZu0od+O6a4slrfpaDaFG mBCELpjxpOL6d+OUqPk3KN9wmQ+CGQ3N7XeFS213eqefwfucHbd8vNJwprzVcRcNUzTJX5fZ ta1fAkhAaXKtzTKQYCHuotySrgW7kx6UM60V5PxdbUaFWlVroOkIC03awd7VOX43O11rSi9E eTvUQFXSBwmQUHDqLt2dJn3zpnJHT918wWqz+wt4kzrJ5qVE3eG96anKTrYlAAAAAAAA --------------ms090502030302040407070500-- From hash-forum@nist.gov Thu Nov 27 04:29:16 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mARCTAtg007335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 27 Nov 2008 04:29:11 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mARCK4fU007595; Thu, 27 Nov 2008 07:20:06 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mARCJOqr002635; Thu, 27 Nov 2008 07:19:24 -0500 Date: Thu, 27 Nov 2008 07:19:24 -0500 Message-Id: <492E8E53.8050309@win.dtu.dk> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: =?ISO-8859-1?Q?S=F8ren_Steffen_Thomsen?= To: Multiple recipients of list Subject: Near-collision attack on the Blue Midnight Wish compression function X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-To: "hash-forum@nist.gov" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 27 Nov 2008 04:29:11 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 232 Dear all, I have found a free-start near-collision attack on the Blue Midnight Wish (BMW) compression function. The attack requires negligible time and space, and works for all four digest sizes of BMW. It results in a collision in all but 24 output bits. See http://www2.mat.dtu.dk/people/S.Thomsen/bmw/nc-compress.pdf. I am not claiming that the attack is a break of the BMW hash function, nor that any security claims made by the designers are invalidated. Best regards, Søren. -- Søren Steffen Thomsen PH.D. student DTU Mathematics ------------------------------- Technical University of Denmark Department of Mathematics Matematiktorvet 303S Building 303S 2800 Kgs. Lyngby Direct +45 4525 3010 Mobile +45 2290 5443 S.Thomsen@mat.dtu.dk www.mat.dtu.dk/ From hash-forum@nist.gov Thu Nov 27 05:02:00 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mARD1tQt013394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 27 Nov 2008 05:01:56 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mARD0qZK026821; Thu, 27 Nov 2008 08:00:56 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mARD0feT018575; Thu, 27 Nov 2008 08:00:41 -0500 Date: Thu, 27 Nov 2008 08:00:41 -0500 Message-Id: <492E97B3.6020106@cs.ucsb.edu> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Cetin Kaya Koc To: Multiple recipients of list Subject: Re: collisions in Spectral Hash (shash-###) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: <20081127133026.rj9xm6uo00oco0w8@webmail.uib.no> References: <20081115081758.75d95c60@gamma> <20081127114711.pxh339bogkc0w4kc@webmail.uib.no> <20081127133026.rj9xm6uo00oco0w8@webmail.uib.no> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 27 Nov 2008 05:01:56 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 233 Hi Tor There are a couple of bugs in the software implementation which causes these outputs. We have fixed the bugs but have not released the new code yet. If you can be patient, we will send you one. Of course, you are welcome to do mathematical analysis on shash without regard to this (buggy) implementation. __________________________________________________________ Cetin Kaya Koc * http://cs.ucsb.edu/~koc US Cell: +1 805 403 4191 ******* TR Cell: +90 532 405 6417 Tor.Bjorstad@ii.uib.no wrote: > > Hi again, > > Bad form to quote oneself, but it seems I fired off the previous > message a bit too quickly. > > Quoting Tor.Bjorstad@ii.uib.no: >> Suffice to say, shash does not appear to handle very long strings of >> 0-bits very well. When hashing long sequences of zeroed data blocks, >> the well-being of the internal state suffers. This led me, somewhat by >> chance, to a new class of even closer near-collisions (albeit for >> rather long messages). > > Can somebody please verify that, after one processes either 3360 or > 6720 512-bit data blocks, all equal to 0, the entire contents of both > sPrism and hPrism becomes 0? > > This leads to the following collision (as well as a preimage of 0), > for all variants of shash: > > // m1 is a character array consisting of 430080 zero-bytes > Hash (512, m1, 430080 << 3, h1); > h1= > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > // m2 is a character array consisting of 215040 zero-bytes > Hash (512, m2, 215040 << 3, h2); > h2= > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > (Using the reference implementation from > http://www.cs.ucsb.edu/~koc/shash/sHash-reference.zip) > > If this can be verified and reproduced, I'd say that shash is dead. > (Though I'm pretty confident that my test code checked and > double-checked and is correct, there's always a danger that one's > somehow done something very silly instead.) > > Cheers, Tor > From hash-forum@nist.gov Thu Nov 27 03:58:36 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mARBwVJA032578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 27 Nov 2008 03:58:32 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mARAx22Y018749; Thu, 27 Nov 2008 05:59:04 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mARAvHiY005282; Thu, 27 Nov 2008 05:57:17 -0500 Date: Thu, 27 Nov 2008 05:57:17 -0500 Message-Id: <20081127114711.pxh339bogkc0w4kc@webmail.uib.no> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Tor.Bjorstad@ii.uib.no To: Multiple recipients of list Subject: Re: Near and truncated collisions in Spectral Hash (shash-###) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" MIME-Version: 1.0 In-Reply-To: <20081115081758.75d95c60@gamma> References: <20081115081758.75d95c60@gamma> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 27 Nov 2008 03:58:32 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 234 Hi all, Quoting Brandon Enright : > Even though I have not been able to find a full collision in shash, I > have a few results which I believe are interesting in their own right. Following Brandon's email I've been fuzzing around with shash-### a bit. In particular I was looking at the propagation of small differences within a single state block. (There seem to be issues with single-bit diffusion.) One interesting effect was obtained by hashing all-zero bitstrings of variable length, which leads to differences appearing in the final message padding but not elsewhere. But I digress. Eventually one thing led to another: Suffice to say, shash does not appear to handle very long strings of 0-bits very well. When hashing long sequences of zeroed data blocks, the well-being of the internal state suffers. This led me, somewhat by chance, to a new class of even closer near-collisions (albeit for rather long messages). Let "input" be an array of 2097664 bits (262208 bytes), all set to 0. Hash (512, input, 2097664, output); dc 92 3e 11 eb c0 1f 65 7f d3 64 92 b8 3d dd 2e a0 09 2c 2f b4 65 50 5a 82 d8 89 e8 17 b1 1e 80 35 1c 5f 13 19 ab 45 7b 95 d4 99 f6 2e 9c 87 62 2b a1 f0 7d ec 7e 75 7f 40 29 59 c7 51 b0 1b ec Hash (512, input, 33280, output); fc 92 3e 11 eb c0 0f 65 7f d3 64 92 78 3d dd 2e a0 09 2c 2f b4 65 b0 5a 82 d8 89 e8 17 b1 4e 80 35 1c 4f 13 19 ab 45 7b 95 d4 99 f6 2e 9c 37 62 0b a1 f0 7d fc 7e 75 7f 40 29 59 c7 01 b0 1b ec Delta (weight 17, equal in 495 positions): 20 00 00 00 00 00 10 00 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 e0 00 00 00 00 00 00 00 50 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 b0 00 20 00 00 00 10 00 00 00 00 00 00 00 50 00 00 00 The same input pair (as well as various others of the same type) yield a weight-7 delta for shash-256 and a weight-3 (!!) delta for shash-128, which is even better than the single-block near-collisions discovered by Brandon. I think this seems like a promising avenue for further attack - my results so far have been found by reasonably dumb heuristic search, a next step will be to have a closer look at what is actually happening to the internal state of shash when feeding in a lot of zero blocks. > At this point I think it is very unlikely that I'm going to be able to > improve or extend this attack to a full collision. Regardless, if the > results I've provided above can be independently verified (the test > vectors verify for me but I'm nervous none-the-less) then I believe > Spectral Hash should be considered broken. Brandon's near-collisions verify on my computer. (I'd be happy if someone would double-check my results, as well.) I also strongly agree that this kind of structured behaviour is rather undesirable in a cryptographic hash function, whether it will lead to discovery of explicitly colliding message pairs or not. Seems dangerous to me. Cheers, Tor E. Bjørstad -- Tor E. Bjørstad - PhD student, Dept. of Informatics, UiB, Norway Mail: tor.bjorstad@ii.uib.no - Web: http://www.ii.uib.no/~tor/ From hash-forum@nist.gov Thu Nov 27 04:35:03 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mARCYwQA008276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 27 Nov 2008 04:34:59 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mARCXskB014997; Thu, 27 Nov 2008 07:33:57 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mARCXQNE030319; Thu, 27 Nov 2008 07:33:26 -0500 Date: Thu, 27 Nov 2008 07:33:26 -0500 Message-Id: <20081127133026.rj9xm6uo00oco0w8@webmail.uib.no> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Tor.Bjorstad@ii.uib.no To: Multiple recipients of list Subject: Re: collisions in Spectral Hash (shash-###) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" MIME-Version: 1.0 In-Reply-To: <20081127114711.pxh339bogkc0w4kc@webmail.uib.no> References: <20081115081758.75d95c60@gamma> <20081127114711.pxh339bogkc0w4kc@webmail.uib.no> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 27 Nov 2008 04:35:00 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: A X-Keywords: X-UID: 235 Hi again, Bad form to quote oneself, but it seems I fired off the previous message a bit too quickly. Quoting Tor.Bjorstad@ii.uib.no: > Suffice to say, shash does not appear to handle very long strings of > 0-bits very well. When hashing long sequences of zeroed data blocks, > the well-being of the internal state suffers. This led me, somewhat by > chance, to a new class of even closer near-collisions (albeit for > rather long messages). Can somebody please verify that, after one processes either 3360 or 6720 512-bit data blocks, all equal to 0, the entire contents of both sPrism and hPrism becomes 0? This leads to the following collision (as well as a preimage of 0), for all variants of shash: // m1 is a character array consisting of 430080 zero-bytes Hash (512, m1, 430080 << 3, h1); h1= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 // m2 is a character array consisting of 215040 zero-bytes Hash (512, m2, 215040 << 3, h2); h2= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (Using the reference implementation from http://www.cs.ucsb.edu/~koc/shash/sHash-reference.zip) If this can be verified and reproduced, I'd say that shash is dead. (Though I'm pretty confident that my test code checked and double-checked and is correct, there's always a danger that one's somehow done something very silly instead.) Cheers, Tor -- Tor E. Bjørstad - PhD student, Dept. of Informatics, UiB, Norway Mail: tor.bjorstad@ii.uib.no - Web: http://www.ii.uib.no/~tor/ From hash-forum@nist.gov Thu Nov 27 13:31:23 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mARLVHCg007747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 27 Nov 2008 13:31:19 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mARLU3ev005301; Thu, 27 Nov 2008 16:30:07 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mARLSc3h003678; Thu, 27 Nov 2008 16:28:38 -0500 Date: Thu, 27 Nov 2008 16:28:38 -0500 Message-Id: <492F0EAA.6000302@mit.edu> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: David Wilson To: Multiple recipients of list Subject: Re: Cryptanalysis of DCH X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: <492E81FF.5080300@iaik.tugraz.at> References: <492E81FF.5080300@iaik.tugraz.at> MIME-Version: 1.0 X-CC: hash-forum@nist.gov, Dmitry Khovratovich X-To: florian.mendel@iaik.tugraz.at X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 27 Nov 2008 13:31:19 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 236 Hi Florian, From an initial read, it looks like this analysis ignores the additional dithering input. When the counter resets, it advances another (non-counter-based) dither input (sec. 1.2 of the DCH specification). Thus, the assertion that "$\gamma_i = \gamma_j$ for $i \equiv j$ (mod 32)" is incorrect. The attacks that follow rely heavily on this assertion. Please let me know if I have misinterpreted your attack and feel free to follow up with me off-list. Regards, David P.S. I do freely admit that the attack of Khovratovich and Nikolic is a legitimate and full break; while the error in DCH is fairly straightforward and likely patchable, fixing it would involve a change to the algorithm that would exceed the bounds of the SHA-3 entry specification. Florian Mendel wrote: > Hi all, > > We have found a practical collision and preimage attack on DCH-n. The > attack is based on the observation of Khovratovich and Nikolic that the > chaining value is not used in the underlying block cipher. The attack is > described in: http://ehash.iaik.tugraz.at/uploads/9/9b/Dch.pdf > > best regards, > > Florian Mendel > From hash-forum@nist.gov Fri Nov 28 05:24:25 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mASDOFNO006662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 28 Nov 2008 05:24:16 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mASD4N0E004214; Fri, 28 Nov 2008 08:04:27 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mASD2ga8004535; Fri, 28 Nov 2008 08:02:42 -0500 Date: Fri, 28 Nov 2008 08:02:42 -0500 Message-Id: <5a199b7a0811280501v12143a2pfcec1ad17e7ee6f5@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Maria Naya" To: Multiple recipients of list Subject: Second preimage attack on Ponic X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/alternative; boundary="----=_Part_53681_6991216.1227877264007" MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 28 Nov 2008 05:24:17 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED,URI_HEX shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 237 ------=_Part_53681_6991216.1227877264007 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, we have found a second preimage attack on Ponic-512 with complexity 2^{265}. You can find it here: http://131002.net/data/papers/ponic.pdf Best regards, Maria ------=_Part_53681_6991216.1227877264007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello,

we have found a second preimage attack on Ponic-512 with complexity 2^{265}.
You can find it here:
------=_Part_53681_6991216.1227877264007-- From hash-forum@nist.gov Fri Nov 28 08:02:06 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mASG21rc028366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 28 Nov 2008 08:02:02 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mASG0lSd017311; Fri, 28 Nov 2008 11:00:51 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mASFxrgP004576; Fri, 28 Nov 2008 10:59:53 -0500 Date: Fri, 28 Nov 2008 10:59:53 -0500 Message-Id: <493014A8.6000900@iaik.tugraz.at> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Tomislav Nad To: Multiple recipients of list Subject: Collision for Boole X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070009060306080203010204" MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 28 Nov 2008 08:02:02 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 238 This is a cryptographically signed message in MIME format. --------------ms070009060306080203010204 Content-Type: multipart/mixed; boundary="------------010302020702060609000406" This is a multi-part message in MIME format. --------------010302020702060609000406 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Dear all, We have found a collision attack on Boole. The attack is based mainly on the fact that the Boolean functions f_1 and f_2 are not invertible. The collision is constructed during the input phase of Boole and works for for all output sizes of Boole. We have constructed a practical collision attack on Boole32 (256 bit hash). An example colliding message pair is attached to this e-mail. The code has to be linked against the reference implementation of Boole and WORDSIZE has to be changed to 32 in Boole.h. The output is given below. The attack has an estimated time complexity of 234. Note that the same attack applies also for Boole64 with an estimated time complexity of 266. We are currently working on a paper which describes the attack in detail. ---- Example collision pair for Boole32 2008-11-28, Tomislav Nad, IAIK, Graz University of Technology m1 = a0bc0dbea1e5e09ebcb018243403415f0b177f217b31b82df5db2a23a866bb7c004ebc0fe11adc4555b36c86f59ed7bad7eb4405c3265558556eaf94980d9839596fd2d9d55ecff15df3155c10dc14fa22672d7587fbd016af0c15b84719bfdd Boole32(m1) = 3f71dd7bd86ac4731bc1567791d6fc8479c411530e3c8230d97cbca36c19e01f m2 = a0bc0dbea1e5e09ebcb01824cbfcbea00b177f217b31b82d0a24d5dca866bb7c004ebc0fe11adc4555b36c86f59ed7bad7eb4405c3265558556eaf94980d9839596fd2d9d55ecff15df3155cef23eb0522672d7587fbd01650f3ea474719bfdd Boole32(m2) = 3f71dd7bd86ac4731bc1567791d6fc8479c411530e3c8230d97cbca36c19e01f m1 and m2 collide! ----- Regards, Tomislav Nad -- Tomislav Nad, IAIK - Graz University of Technology Inffeldgasse 16a, 8010 Graz, Austria Tel: +43 316 873 5503 Fax: +43 316 873 5594 http://www.iaik.tugraz.at --------------010302020702060609000406 Content-Type: text/x-csrc; name="boolecoll.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="boolecoll.c" /* * Copyright (c) 2008 Sebastiaan Indesteege * * * Permission to use, copy, modify, and distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ /* * Example collision pair for Boole32. This file has to be linked to the * reference implementation of Boole. In Boole.h of the reference * implementation the WORDSIZE has to be changed to 32. * * 2008-11-28, Tomislav Nad, IAIK, Graz University of Technology */ #include "Boole.h" #include #include #include #define HASHBITLEN 256 #define LEN 24*4*8 static const uint8_t m1[] = { 0xa0,0xbc,0xd,0xbe, 0xa1,0xe5,0xe0,0x9e, 0xbc,0xb0,0x18,0x24, 0x34,0x3,0x41,0x5f, 0xb,0x17,0x7f,0x21, 0x7b,0x31,0xb8,0x2d, 0xf5,0xdb,0x2a,0x23, 0xa8,0x66,0xbb,0x7c, 0x0,0x4e,0xbc,0xf, 0xe1,0x1a,0xdc,0x45, 0x55,0xb3,0x6c,0x86, 0xf5,0x9e,0xd7,0xba, 0xd7,0xeb,0x44,0x5, 0xc3,0x26,0x55,0x58, 0x55,0x6e,0xaf,0x94, 0x98,0xd,0x98,0x39, 0x59,0x6f,0xd2,0xd9, 0xd5,0x5e,0xcf,0xf1, 0x5d,0xf3,0x15,0x5c, 0x10,0xdc,0x14,0xfa, 0x22,0x67,0x2d,0x75, 0x87,0xfb,0xd0,0x16, 0xaf,0xc,0x15,0xb8, 0x47,0x19,0xbf,0xdd }; static const uint8_t m2[] = { 0xa0,0xbc,0xd,0xbe, 0xa1,0xe5,0xe0,0x9e, 0xbc,0xb0,0x18,0x24, 0xcb,0xfc,0xbe,0xa0, 0xb,0x17,0x7f,0x21, 0x7b,0x31,0xb8,0x2d, 0xa,0x24,0xd5,0xdc, 0xa8,0x66,0xbb,0x7c, 0x0,0x4e,0xbc,0xf, 0xe1,0x1a,0xdc,0x45, 0x55,0xb3,0x6c,0x86, 0xf5,0x9e,0xd7,0xba, 0xd7,0xeb,0x44,0x5, 0xc3,0x26,0x55,0x58, 0x55,0x6e,0xaf,0x94, 0x98,0xd,0x98,0x39, 0x59,0x6f,0xd2,0xd9, 0xd5,0x5e,0xcf,0xf1, 0x5d,0xf3,0x15,0x5c, 0xef,0x23,0xeb,0x5, 0x22,0x67,0x2d,0x75, 0x87,0xfb,0xd0,0x16, 0x50,0xf3,0xea,0x47, 0x47,0x19,0xbf,0xdd }; uint8_t h1[HASHBITLEN/8]; uint8_t h2[HASHBITLEN/8]; void printbytes(uint8_t const *p, int n) { int i; for (i=0; i!=n; ++i) printf("%02x", p[i]); printf("\n"); } int main() { int i; printf("Example collision pair for Boole32\n"); printf("2008-11-28, Tomislav Nad, IAIK, Graz University of Technology\n\n"); /* Hash first mesage */ if (Hash(HASHBITLEN, m1, LEN, h1) != SUCCESS) errx(1, "Hashing failed!"); printf("m1 = "); printbytes(m1, LEN/8); printf("Boole32(m1) = "); printbytes(h1, HASHBITLEN/8); printf("\n"); /* Hash second mesage */ if (Hash(HASHBITLEN, m2, LEN, h2) != SUCCESS) errx(1, "Hashing failed!"); printf("m2 = "); printbytes(m2, LEN/8); printf("Boole32(m2) = "); printbytes(h2, HASHBITLEN/8); printf("\n"); /* Verify collision */ for (i=0; i!=32; ++i) { if (h1[i] != h2[i]) { printf("ERROR: m1 and m2 do NOT collide\n"); return 1; } } printf("m1 and m2 collide!\n\n"); return 0; } --------------010302020702060609000406-- --------------ms070009060306080203010204 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIa8jCC BLMwggOboAMCAQICARYwDQYJKoZIhvcNAQEFBQAwQTEQMA4GA1UEChMHRXVyb1BLSTEtMCsG A1UEAxMkRXVyb1BLSSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTIyODA5 NTA1MloXDTEwMTIzMTExNTkwMFowUjELMAkGA1UEBhMCQVQxEDAOBgNVBAoTB0V1cm9QS0kx MTAvBgNVBAMTKEV1cm9QS0kgQXVzdHJpYW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1hZUNUa0lyv5ttAn7ZRyfI4zO+Bc2fmTi lpAIBfJ/2yqfdHKCd/r2czeCme85S298uhCrDtKZXQp6wZpxGsZrZw5n8mrXVVy6HUTFTyKa pz/4W3vS0f3fKljpUioJ9lBUwQyARDcNzCP63+Iv9OqrHgb4QoSfmDlrX5KmaGDaEgoNYbkY wFDn0b81I16j8mXDDECtQM/ZsxzjkHZz1ks3jl/q9EW1OxdD6ytgsePXzfmfWjdwsB8KyjXI UNpLMBzPK3qTjwevGUQjfCCJ1hC26t2G9BWPcHUUw0/4gCL/jGDLUAmMWo1z1H/gyk9VrTsU uP3HZ7fElMpfqmIqyr69AgMBAAGjggGjMIIBnzBMBglghkgBhvhCAQ0EPxY9SXNzdWVkIHVu ZGVyIHBvbGljeToKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzBk BggrBgEFBQcBAQRYMFYwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwLmV1cm9wa2kub3JnOjgw MjYwKgYIKwYBBQUHMAKGHmh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdDA7BgNVHR8E NDAyMDCgLqAshipodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3JsL2NybC5kZXIw TgYDVR0gBEcwRTBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93d3cuZXVy b3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzAdBgNVHQ4EFgQUdCnYUa/CPJin1/8xj0D3UOgH AegwHwYDVR0jBBgwFoAUjNyLsaVKkOdOiHMYPJ3VXn7kss0wDAYDVR0TBAUwAwEB/zAOBgNV HQ8BAf8EBAMCAfYwDQYJKoZIhvcNAQEFBQADggEBALvbHv34QJkgCzJ92trxCWkGmeahGFQ8 ZQCFlgeaAI5d2B8K9XVJ7IduoETxq+evWfDaiUBHahQ6c2oC9uhuqI4pzJpsEJimYpccHRBA 85S5spyfLfpboY1lSGraFxZwTsV9+wGftlCOZy3UF9Ip0VLP1wrRsTvfCBjLybj45ay3L3o5 F+MojQ2VPC0w/z56yD9caU+fl2pJSU7Q5fUlUfYD0PexVzDEWX4r3lGn6G5UD/zC8zNqH7fh sJxsH/TeraHbvUk8AZu4IULWzrpytR7JpOX/VRfeF65foy7GoTkBuGPx9EsbXJzZ/ygab947 O5yIAqr6bibMh7i1ZDcpnacwggU3MIIEH6ADAgECAgcCQt/N+2FTMA0GCSqGSIb3DQEBBQUA MFIxCzAJBgNVBAYTAkFUMRAwDgYDVQQKEwdFdXJvUEtJMTEwLwYDVQQDEyhFdXJvUEtJIEF1 c3RyaWFuIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA4MDIyODE1MTgwNVoXDTEzMDIy ODE1MTgwNVowgb0xLTArBgNVBAMTJEV1cm9QS0kgSUFJSyBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEmMCQGA1UEChMdR3JheiBVbml2ZXJzaXR5IG9mIFRlY2hub2xvZ3kxSDBGBgNVBAsT P0luc3RpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21t dW5pY2F0aW9uczENMAsGA1UEBxMER3JhejELMAkGA1UEBhMCQVQwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCVatVA1TczvPSG2IZoIPtEBXNgZSdUx58syuOEoZs9HOc0MocB 2ko3jIDfB9YIP7bLEag1yjrlO8GxfkBCiTQvnfNDEIMvetuwJmHSgaTxJ3PRlOWDJMi/IbNe X1yq2sOYyszpbK5/jm6JAl/XbYNmNuiPxx2PR3iVZBL4v38sF7o0x/ale5P7RmW4KXq36Mpc /KaAW4cMrDUAGNqcc9EIwkTAx1moGt8u7v/CTgWIilXbhB1BBBjp+Cy9ukBX+HnwimWlAcKF DTqmwFmgJA+QlCEQYHs0o2ylWF+41N8MivLlYqvqQlpOFqWStBpKr8lxkcjpFRzFry2ORWlK 16+bAgMBAAGjggGkMIIBoDAOBgNVHQ8BAf8EBAMCAcYwDwYDVR0TAQH/BAUwAwEB/zAdBgNV HQ4EFgQUOXTH3cjx+wpwPQ7KfUUCrKGb154wVgYDVR0gBE8wTTBLBgwrBgEEAZUSAQIBAQEw OzA5BggrBgEFBQcCARYtaHR0cDovL2V1cm9wa2kuaWFpay5hdC9jYS9ldXJvcGtpLWF0L2Nw cy8xLjEvMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jYS5pYWlrLnR1Z3Jhei5hdC9jYXBz by9jcmxzL0V1cm9QS0lBdXN0cmlhbi5jcmwwgZoGCCsGAQUFBwEBBIGNMIGKMEIGCCsGAQUF BzABhjZodHRwOi8vY2EuaWFpay50dWdyYXouYXQvY2Fwc28vT0NTUD9jYT1FdXJvUEtJQXVz dHJpYW4wRAYIKwYBBQUHMAKGOGh0dHA6Ly9jYS5pYWlrLnR1Z3Jhei5hdC9jYXBzby9jZXJ0 cy9FdXJvUEtJQXVzdHJpYW4uY2VyMB8GA1UdIwQYMBaAFHQp2FGvwjyYp9f/MY9A91DoBwHo MA0GCSqGSIb3DQEBBQUAA4IBAQCmsYc+Rdrfd3sV8jqDipRkd/BGEwGFiWydTmEMRimyr2Sm qNVX4khjAEyLcVjyYK+Fc+XREwOttYcKQHFKaRZRDby0RvniwP3LX1Du3xXnEHij9oB6A2aE Tg1ouAnCikXQQ4C3eBfM9vaK9VR0k/akaqKzTTPBl8ao7TmOfTTdIBrVSoPYjeXR/qm1A34n Pb0gR5sBMEZEcZgDN2oKSDsrK2bHp7AG36R/AtnGyW4j1hI5hR35VCmAToz4dbUKhZjDFJU+ FgmANAWh0+AetShQ7qpS6IyHXxdDGYW/7SHbwWsi4pmRnRm/xaYLVCo3zRJDwaXq3JlKOh2V if4IFzAgMIIFgDCCBGigAwIBAgIHA0DrJxk2fDANBgkqhkiG9w0BAQUFADCBvTEtMCsGA1UE AxMkRXVyb1BLSSBJQUlLIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSYwJAYDVQQKEx1HcmF6 IFVuaXZlcnNpdHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/SW5zdGl0dXRlIGZvciBBcHBs aWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMQ0wCwYDVQQH EwRHcmF6MQswCQYDVQQGEwJBVDAeFw0wODAyMjgxNTQ0MTdaFw0xMzAyMjgxNTQ0MTdaMIGs MRwwGgYDVQQDExNFdXJvUEtJIElBSUsgU2lnIENBMSYwJAYDVQQKEx1HcmF6IFVuaXZlcnNp dHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/SW5zdGl0dXRlIGZvciBBcHBsaWVkIEluZm9y bWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMQ0wCwYDVQQHEwRHcmF6MQsw CQYDVQQGEwJBVDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALBs2U2/lTXnomXh gNULWkAXS507A6UtmsbrAIXXK7XIWgyjbKiYASrdej0LPKGuFtxbZ+A/e1cSV8yrCWsB+4s8 jZwL+xbWeXIGcaKarv0npeXSqX0UZl7DM5mVID+FwG1T73qjmIGvE6i5qDnNEv0siGeit7m0 AH3dF2uckq6eKuozAvchlJOQk27PqaPRFCS5APiCNBrB9AUShjXMHso1wC1raxlsGDc/yneC 2Z4OOBZLkswPIMu0qUwVfGVR7u3WFLEP3cPXw8lWb1Ka8GzGLBivt4PRz+wyibDfWx/i/Snh TzfEuB4y1PFjvsFQ3o3am2zHpqvy1WPfUsxRLQ0CAwEAAaOCAZIwggGOMA4GA1UdDwEB/wQE AwIBxjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSu7lUGF3pTERMYq6TOHHEJGoMU8zBQ BgNVHSAESTBHMEUGDCsGAQQBlRIBAgMBATA1MDMGCCsGAQUFBwIBFidodHRwOi8vZXVyb3Br aS5pYWlrLmF0L2NhL2lhaWsvY3BzLzEuMy8wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2Nh LmlhaWsudHVncmF6LmF0L2NhcHNvL2NybHMvRXVyb1BLSUlBSUsuY3JsMIGSBggrBgEFBQcB AQSBhTCBgjA+BggrBgEFBQcwAYYyaHR0cDovL2NhLmlhaWsudHVncmF6LmF0L2NhcHNvL09D U1A/Y2E9RXVyb1BLSUlBSUswQAYIKwYBBQUHMAKGNGh0dHA6Ly9jYS5pYWlrLnR1Z3Jhei5h dC9jYXBzby9jZXJ0cy9FdXJvUEtJSUFJSy5jZXIwHwYDVR0jBBgwFoAUOXTH3cjx+wpwPQ7K fUUCrKGb154wDQYJKoZIhvcNAQEFBQADggEBAAgys3wJ2CixcC8KuuO3a9k8u0nT0+PafLR9 wMQMWsz7xDTLNxiTJKnLvdFw86D+CH+nXxRweo/KDVYT56q5rfKs45I6mZDV+z/wecNX3odW MuY5a6j0g/RR4Qz/wokfeUzff5Yi6Hh1P9ce0u3/EHAHancJI3FxoZpLU5qNWZNo+fI6nluO BmdJCWZgCR9ijucmFubnu4EbWlyhiH2e0H2taU6zWvW/83yqbEO0BhDKVWWVtWvlF/ptBZQE JzAD1q5XJobPNQ/IANfs5ZcfuC1+Pm6FEG0cMVnDCGlRoA57oTIFaODWQPr4gxMy11/MYe9V ufBih5AU1z6V4IwJ5SYwggW6MIIEoqADAgECAgcCLHBKrpw3MA0GCSqGSIb3DQEBBQUAMIGs MRwwGgYDVQQDExNFdXJvUEtJIElBSUsgRW5jIENBMSYwJAYDVQQKEx1HcmF6IFVuaXZlcnNp dHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/SW5zdGl0dXRlIGZvciBBcHBsaWVkIEluZm9y bWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMQ0wCwYDVQQHEwRHcmF6MQsw CQYDVQQGEwJBVDAeFw0wODExMjcxMzM5MDZaFw0xMTExMjcxMzM5MDZaMIHGMREwDwYDVQQq EwhUb21pc2xhdjEMMAoGA1UEBBMDTmFkMRUwEwYDVQQDEwxUb21pc2xhdiBOYWQxJjAkBgNV BAoTHUdyYXogVW5pdmVyc2l0eSBvZiBUZWNobm9sb2d5MUgwRgYDVQQLEz9JbnN0aXR1dGUg Zm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMx DTALBgNVBAcTBEdyYXoxCzAJBgNVBAYTAkFUMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEArdttlPPyiXQcfNaxUmw8mXGsij68oGPwlkxwcGcLrL+7738AefMTtG6OrJdlMU8c e0pZybwu2BV5M/Vcug79hd9aY0TYRMEkhU16griXNqkImEz0rAvSJGtFuPP9Z1QJ0XNG9kZQ rdD5ODYPsijU3B04b8qWDby5xJ81KG2x7K6T5mYg6U8vfXm7UsnS5skZxvaTHOgtPKIat/LY ZmDTycdsXX2zuRVJ9hjki+nG9DYJfgRifVRKfS0QAft8oD4Io4hRKlkIk7JFVA+loL3uY7oa KgATptfG4FLN8ALEESNQE00DY0DMJpHd/JrvArcriVfovCYv+5K5Ko8o3odfGwIDAQABo4IB wzCCAb8wDgYDVR0PAQH/BAQDAgQwMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFNS8USUyDcW4 HBZG3l0e0DgKbd3oMFAGA1UdIARJMEcwRQYMKwYBBAGVEgECAwEBMDUwMwYIKwYBBQUHAgEW J2h0dHA6Ly9ldXJvcGtpLmlhaWsuYXQvY2EvaWFpay9jcHMvMS4zLzBIBgNVHR8EQTA/MD2g O6A5hjdodHRwOi8vY2EuaWFpay50dWdyYXouYXQvY2Fwc28vY3Jscy9FdXJvUEtJSUFJS19F bmMuY3JsMIGaBggrBgEFBQcBAQSBjTCBijBCBggrBgEFBQcwAYY2aHR0cDovL2NhLmlhaWsu dHVncmF6LmF0L2NhcHNvL09DU1A/Y2E9RXVyb1BLSUlBSUtfRW5jMEQGCCsGAQUFBzAChjho dHRwOi8vY2EuaWFpay50dWdyYXouYXQvY2Fwc28vY2VydHMvRXVyb1BLSUlBSUtfRW5jLmNl cjAmBgNVHREEHzAdgRt0b21pc2xhdi5uYWRAaWFpay50dWdyYXouYXQwHwYDVR0jBBgwFoAU 3UP298kNEZZgTQSlVkIYEiSm2uowDQYJKoZIhvcNAQEFBQADggEBAFeoU6Sd+M9BzSF7BbSD 2HATt3fEMIzPS5k1raikQU5056UNy8iCkg/cW7DWUOez9KlqSjsfs9xYnGufUi/C9HHYuc2U 1uqi7J3uhgee9GRo0iy6TC1nG/cpTSUDmR6r85NBHuugyYs8xj2AkN9JKLKfiOB5kalI6VeJ SiLrUbLBtzEKvWzBqNp5gjdmVvhH2SyzEJrYbsGp1H6Pvvq0RcUS+YduiO7y69dSQ1lzHzzg frpW4Klnj95JkwBVJG+g61hIwRdcna8KzWIpfTf4dZPANwNzKSckDqdyHU+zJOt/lBc4iZFS hM7rzZVedlidn3EPVfD+Yn1lim13bbD0jF8wggW6MIIEoqADAgECAgcD1ViHhc9jMA0GCSqG SIb3DQEBBQUAMIGsMRwwGgYDVQQDExNFdXJvUEtJIElBSUsgU2lnIENBMSYwJAYDVQQKEx1H cmF6IFVuaXZlcnNpdHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/SW5zdGl0dXRlIGZvciBB cHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMQ0wCwYD VQQHEwRHcmF6MQswCQYDVQQGEwJBVDAeFw0wODExMjcxMzM1MjRaFw0xMTExMjcxMzM1MjRa MIHGMREwDwYDVQQqEwhUb21pc2xhdjEMMAoGA1UEBBMDTmFkMRUwEwYDVQQDEwxUb21pc2xh diBOYWQxJjAkBgNVBAoTHUdyYXogVW5pdmVyc2l0eSBvZiBUZWNobm9sb2d5MUgwRgYDVQQL Ez9JbnN0aXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29t bXVuaWNhdGlvbnMxDTALBgNVBAcTBEdyYXoxCzAJBgNVBAYTAkFUMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA4QVx07SO58dqk9jJzGWw9IhSh2pyfwZ1PI7D4OyV81uo6nX9 WkIIlrgXIin+SfjGg4vwOhkBpDpDqYsn5FC+HV0qmvezf/DmuJMXczFXJZZJq/invDu22z+M P+qksgO+BXvfC6iP/IovOPDF8NZHdRmccWSktxm5gy0Y3vXU0JxNxaNAGOgGQO+CfCzxONfR gsHMpFkFlwdQrh3JBlJlIHpfjzhvl6bddWCtrvGazDZPVdbGXToaVnhtjG+SNrVuWqubGjRX Q7ttNVtRyBwJxkclscV3ZgObydoWed5TwsruVj8FrgL6RlexzGExGaKqufSoKZD0zS+bwpwH 1nPDVQIDAQABo4IBwzCCAb8wDgYDVR0PAQH/BAQDAgbAMAwGA1UdEwEB/wQCMAAwHQYDVR0O BBYEFFC5jw/NBM83a0KQ3O7D3qOToilpMFAGA1UdIARJMEcwRQYMKwYBBAGVEgECAwEBMDUw MwYIKwYBBQUHAgEWJ2h0dHA6Ly9ldXJvcGtpLmlhaWsuYXQvY2EvaWFpay9jcHMvMS4zLzBI BgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY2EuaWFpay50dWdyYXouYXQvY2Fwc28vY3Jscy9F dXJvUEtJSUFJS19TaWcuY3JsMIGaBggrBgEFBQcBAQSBjTCBijBCBggrBgEFBQcwAYY2aHR0 cDovL2NhLmlhaWsudHVncmF6LmF0L2NhcHNvL09DU1A/Y2E9RXVyb1BLSUlBSUtfU2lnMEQG CCsGAQUFBzAChjhodHRwOi8vY2EuaWFpay50dWdyYXouYXQvY2Fwc28vY2VydHMvRXVyb1BL SUlBSUtfU2lnLmNlcjAmBgNVHREEHzAdgRt0b21pc2xhdi5uYWRAaWFpay50dWdyYXouYXQw HwYDVR0jBBgwFoAUru5VBhd6UxETGKukzhxxCRqDFPMwDQYJKoZIhvcNAQEFBQADggEBAEXz IF0SpcMrpUtKHLx+R8ViT7AzpgMo02Z6ZoVvfgHZM+LZYQRBRxIpcpVhKYBdGGlR4w9pzuF9 Yz4ByZd2uDAl+78s9+h/QRsuzw4mO/LRkIaDcXcJns73j6L7sLgR0rVUYwbhKeia9531vzUE q2m39ElbCOBfFHILkzzrSbINQFrEXdFNJBeYYsTP1WouILFeI/Gb1Df60gmvjA+k8qER+3Bm nk7vat3C7Aoo2MqLj/Ze6Zj65OU9zGTmW/SXK5anY0gTV7HtoiUzLqTOW5EiAM9pH15CAV69 Ya5lg2NWtWDHf9x5PZ22aGqlrSJdN4PheFqiQ6xkeseanZNlifgxggQ8MIIEOAIBATCBuDCB rDEcMBoGA1UEAxMTRXVyb1BLSSBJQUlLIFNpZyBDQTEmMCQGA1UEChMdR3JheiBVbml2ZXJz aXR5IG9mIFRlY2hub2xvZ3kxSDBGBgNVBAsTP0luc3RpdHV0ZSBmb3IgQXBwbGllZCBJbmZv cm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczENMAsGA1UEBxMER3JhejEL MAkGA1UEBhMCQVQCBwPVWIeFz2MwCQYFKw4DAhoFAKCCAlgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgxMTI4MTU1NjI0WjAjBgkqhkiG9w0BCQQxFgQU fRj3ugWyllzQTOF28fYjI5AVv0wwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMIHJBgkrBgEEAYI3EAQxgbswgbgwgawxHDAaBgNVBAMTE0V1cm9QS0kgSUFJ SyBFbmMgQ0ExJjAkBgNVBAoTHUdyYXogVW5pdmVyc2l0eSBvZiBUZWNobm9sb2d5MUgwRgYD VQQLEz9JbnN0aXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQg Q29tbXVuaWNhdGlvbnMxDTALBgNVBAcTBEdyYXoxCzAJBgNVBAYTAkFUAgcCLHBKrpw3MIHL BgsqhkiG9w0BCRACCzGBu6CBuDCBrDEcMBoGA1UEAxMTRXVyb1BLSSBJQUlLIEVuYyBDQTEm MCQGA1UEChMdR3JheiBVbml2ZXJzaXR5IG9mIFRlY2hub2xvZ3kxSDBGBgNVBAsTP0luc3Rp dHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0 aW9uczENMAsGA1UEBxMER3JhejELMAkGA1UEBhMCQVQCBwIscEqunDcwDQYJKoZIhvcNAQEB BQAEggEA1myL2E64J5z8v5D9PDbCi9uEKonyDLy7IWNO2paCwsHIRVRUIzqbrFTHSYSxMcMu +q4h/D4zGh/KWQzsn+7smrZOEY3d0Wt87Du+DwQJ6IAqO8GVous6y3tONJCyeJ7pnabkqy25 /aLc0JQ/ofNZNyyqDXaS5Z8b8usf+ua7ZlHni9fznfplIZufX2MbcloGajSgbomtY4YJPm2z zrpETdBAQKltCal8FJdW66TgJ33+0oQFHTyrcX6mZMEqfUqtVmdIH3Xi6478JwcP/i2lozJR vwtFf0EzJnux8Fwfvd3XDSsAvkwZe0/tAmjlE/TOpYse2E7SM1UsZK6zOzQMIgAAAAAAAA== --------------ms070009060306080203010204-- From hash-forum@nist.gov Fri Nov 28 08:56:19 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mASGuD3l004419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 28 Nov 2008 08:56:14 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mASGt8c7027602; Fri, 28 Nov 2008 11:55:12 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mASGsWoY016135; Fri, 28 Nov 2008 11:54:32 -0500 Date: Fri, 28 Nov 2008 11:54:32 -0500 Message-Id: <49301F37.7000308@iaik.tugraz.at> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Tomislav Nad To: Multiple recipients of list Subject: Re: Collision for Boole X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010907060308090409050208" In-Reply-To: <493014A8.6000900@iaik.tugraz.at> References: <493014A8.6000900@iaik.tugraz.at> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 28 Nov 2008 08:56:15 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 239 This is a cryptographically signed message in MIME format. --------------ms010907060308090409050208 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sorry. The attack complexities are 2^{34} and 2^{66} respectively. Tomislav Nad wrote: > Dear all, > > We have found a collision attack on Boole. The attack is based mainly > on the fact that the Boolean functions f_1 and f_2 are not invertible. > The collision is constructed during the input phase of Boole and works > for for all output sizes of Boole. > > We have constructed a practical collision attack on Boole32 (256 bit > hash). An example colliding message pair is attached to this e-mail. > The code has to be linked against the reference implementation of > Boole and WORDSIZE has to be changed to 32 in Boole.h. The output is > given below. > The attack has an estimated time complexity of 234. Note that the same > attack applies also for Boole64 with an estimated time complexity of > 266. We are currently working on a paper which describes the attack in > detail. > > > ---- > Example collision pair for Boole32 > 2008-11-28, Tomislav Nad, IAIK, Graz University of Technology > > m1 = > a0bc0dbea1e5e09ebcb018243403415f0b177f217b31b82df5db2a23a866bb7c004ebc0fe11adc4555b36c86f59ed7bad7eb4405c3265558556eaf94980d9839596fd2d9d55ecff15df3155c10dc14fa22672d7587fbd016af0c15b84719bfdd > > Boole32(m1) = > 3f71dd7bd86ac4731bc1567791d6fc8479c411530e3c8230d97cbca36c19e01f > > m2 = > a0bc0dbea1e5e09ebcb01824cbfcbea00b177f217b31b82d0a24d5dca866bb7c004ebc0fe11adc4555b36c86f59ed7bad7eb4405c3265558556eaf94980d9839596fd2d9d55ecff15df3155cef23eb0522672d7587fbd01650f3ea474719bfdd > > Boole32(m2) = > 3f71dd7bd86ac4731bc1567791d6fc8479c411530e3c8230d97cbca36c19e01f > > m1 and m2 collide! > ----- > > Regards, > Tomislav Nad > --------------ms010907060308090409050208 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIa8jCC BLMwggOboAMCAQICARYwDQYJKoZIhvcNAQEFBQAwQTEQMA4GA1UEChMHRXVyb1BLSTEtMCsG A1UEAxMkRXVyb1BLSSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTIyODA5 NTA1MloXDTEwMTIzMTExNTkwMFowUjELMAkGA1UEBhMCQVQxEDAOBgNVBAoTB0V1cm9QS0kx MTAvBgNVBAMTKEV1cm9QS0kgQXVzdHJpYW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1hZUNUa0lyv5ttAn7ZRyfI4zO+Bc2fmTi lpAIBfJ/2yqfdHKCd/r2czeCme85S298uhCrDtKZXQp6wZpxGsZrZw5n8mrXVVy6HUTFTyKa pz/4W3vS0f3fKljpUioJ9lBUwQyARDcNzCP63+Iv9OqrHgb4QoSfmDlrX5KmaGDaEgoNYbkY wFDn0b81I16j8mXDDECtQM/ZsxzjkHZz1ks3jl/q9EW1OxdD6ytgsePXzfmfWjdwsB8KyjXI UNpLMBzPK3qTjwevGUQjfCCJ1hC26t2G9BWPcHUUw0/4gCL/jGDLUAmMWo1z1H/gyk9VrTsU uP3HZ7fElMpfqmIqyr69AgMBAAGjggGjMIIBnzBMBglghkgBhvhCAQ0EPxY9SXNzdWVkIHVu ZGVyIHBvbGljeToKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzBk BggrBgEFBQcBAQRYMFYwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwLmV1cm9wa2kub3JnOjgw MjYwKgYIKwYBBQUHMAKGHmh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdDA7BgNVHR8E NDAyMDCgLqAshipodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3JsL2NybC5kZXIw TgYDVR0gBEcwRTBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93d3cuZXVy b3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzAdBgNVHQ4EFgQUdCnYUa/CPJin1/8xj0D3UOgH AegwHwYDVR0jBBgwFoAUjNyLsaVKkOdOiHMYPJ3VXn7kss0wDAYDVR0TBAUwAwEB/zAOBgNV HQ8BAf8EBAMCAfYwDQYJKoZIhvcNAQEFBQADggEBALvbHv34QJkgCzJ92trxCWkGmeahGFQ8 ZQCFlgeaAI5d2B8K9XVJ7IduoETxq+evWfDaiUBHahQ6c2oC9uhuqI4pzJpsEJimYpccHRBA 85S5spyfLfpboY1lSGraFxZwTsV9+wGftlCOZy3UF9Ip0VLP1wrRsTvfCBjLybj45ay3L3o5 F+MojQ2VPC0w/z56yD9caU+fl2pJSU7Q5fUlUfYD0PexVzDEWX4r3lGn6G5UD/zC8zNqH7fh sJxsH/TeraHbvUk8AZu4IULWzrpytR7JpOX/VRfeF65foy7GoTkBuGPx9EsbXJzZ/ygab947 O5yIAqr6bibMh7i1ZDcpnacwggU3MIIEH6ADAgECAgcCQt/N+2FTMA0GCSqGSIb3DQEBBQUA MFIxCzAJBgNVBAYTAkFUMRAwDgYDVQQKEwdFdXJvUEtJMTEwLwYDVQQDEyhFdXJvUEtJIEF1 c3RyaWFuIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA4MDIyODE1MTgwNVoXDTEzMDIy ODE1MTgwNVowgb0xLTArBgNVBAMTJEV1cm9QS0kgSUFJSyBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEmMCQGA1UEChMdR3JheiBVbml2ZXJzaXR5IG9mIFRlY2hub2xvZ3kxSDBGBgNVBAsT P0luc3RpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21t dW5pY2F0aW9uczENMAsGA1UEBxMER3JhejELMAkGA1UEBhMCQVQwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCVatVA1TczvPSG2IZoIPtEBXNgZSdUx58syuOEoZs9HOc0MocB 2ko3jIDfB9YIP7bLEag1yjrlO8GxfkBCiTQvnfNDEIMvetuwJmHSgaTxJ3PRlOWDJMi/IbNe X1yq2sOYyszpbK5/jm6JAl/XbYNmNuiPxx2PR3iVZBL4v38sF7o0x/ale5P7RmW4KXq36Mpc /KaAW4cMrDUAGNqcc9EIwkTAx1moGt8u7v/CTgWIilXbhB1BBBjp+Cy9ukBX+HnwimWlAcKF DTqmwFmgJA+QlCEQYHs0o2ylWF+41N8MivLlYqvqQlpOFqWStBpKr8lxkcjpFRzFry2ORWlK 16+bAgMBAAGjggGkMIIBoDAOBgNVHQ8BAf8EBAMCAcYwDwYDVR0TAQH/BAUwAwEB/zAdBgNV HQ4EFgQUOXTH3cjx+wpwPQ7KfUUCrKGb154wVgYDVR0gBE8wTTBLBgwrBgEEAZUSAQIBAQEw OzA5BggrBgEFBQcCARYtaHR0cDovL2V1cm9wa2kuaWFpay5hdC9jYS9ldXJvcGtpLWF0L2Nw cy8xLjEvMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jYS5pYWlrLnR1Z3Jhei5hdC9jYXBz by9jcmxzL0V1cm9QS0lBdXN0cmlhbi5jcmwwgZoGCCsGAQUFBwEBBIGNMIGKMEIGCCsGAQUF BzABhjZodHRwOi8vY2EuaWFpay50dWdyYXouYXQvY2Fwc28vT0NTUD9jYT1FdXJvUEtJQXVz dHJpYW4wRAYIKwYBBQUHMAKGOGh0dHA6Ly9jYS5pYWlrLnR1Z3Jhei5hdC9jYXBzby9jZXJ0 cy9FdXJvUEtJQXVzdHJpYW4uY2VyMB8GA1UdIwQYMBaAFHQp2FGvwjyYp9f/MY9A91DoBwHo MA0GCSqGSIb3DQEBBQUAA4IBAQCmsYc+Rdrfd3sV8jqDipRkd/BGEwGFiWydTmEMRimyr2Sm qNVX4khjAEyLcVjyYK+Fc+XREwOttYcKQHFKaRZRDby0RvniwP3LX1Du3xXnEHij9oB6A2aE Tg1ouAnCikXQQ4C3eBfM9vaK9VR0k/akaqKzTTPBl8ao7TmOfTTdIBrVSoPYjeXR/qm1A34n Pb0gR5sBMEZEcZgDN2oKSDsrK2bHp7AG36R/AtnGyW4j1hI5hR35VCmAToz4dbUKhZjDFJU+ FgmANAWh0+AetShQ7qpS6IyHXxdDGYW/7SHbwWsi4pmRnRm/xaYLVCo3zRJDwaXq3JlKOh2V if4IFzAgMIIFgDCCBGigAwIBAgIHA0DrJxk2fDANBgkqhkiG9w0BAQUFADCBvTEtMCsGA1UE AxMkRXVyb1BLSSBJQUlLIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSYwJAYDVQQKEx1HcmF6 IFVuaXZlcnNpdHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/SW5zdGl0dXRlIGZvciBBcHBs aWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMQ0wCwYDVQQH EwRHcmF6MQswCQYDVQQGEwJBVDAeFw0wODAyMjgxNTQ0MTdaFw0xMzAyMjgxNTQ0MTdaMIGs MRwwGgYDVQQDExNFdXJvUEtJIElBSUsgU2lnIENBMSYwJAYDVQQKEx1HcmF6IFVuaXZlcnNp dHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/SW5zdGl0dXRlIGZvciBBcHBsaWVkIEluZm9y bWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMQ0wCwYDVQQHEwRHcmF6MQsw CQYDVQQGEwJBVDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALBs2U2/lTXnomXh gNULWkAXS507A6UtmsbrAIXXK7XIWgyjbKiYASrdej0LPKGuFtxbZ+A/e1cSV8yrCWsB+4s8 jZwL+xbWeXIGcaKarv0npeXSqX0UZl7DM5mVID+FwG1T73qjmIGvE6i5qDnNEv0siGeit7m0 AH3dF2uckq6eKuozAvchlJOQk27PqaPRFCS5APiCNBrB9AUShjXMHso1wC1raxlsGDc/yneC 2Z4OOBZLkswPIMu0qUwVfGVR7u3WFLEP3cPXw8lWb1Ka8GzGLBivt4PRz+wyibDfWx/i/Snh TzfEuB4y1PFjvsFQ3o3am2zHpqvy1WPfUsxRLQ0CAwEAAaOCAZIwggGOMA4GA1UdDwEB/wQE AwIBxjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSu7lUGF3pTERMYq6TOHHEJGoMU8zBQ BgNVHSAESTBHMEUGDCsGAQQBlRIBAgMBATA1MDMGCCsGAQUFBwIBFidodHRwOi8vZXVyb3Br aS5pYWlrLmF0L2NhL2lhaWsvY3BzLzEuMy8wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2Nh LmlhaWsudHVncmF6LmF0L2NhcHNvL2NybHMvRXVyb1BLSUlBSUsuY3JsMIGSBggrBgEFBQcB AQSBhTCBgjA+BggrBgEFBQcwAYYyaHR0cDovL2NhLmlhaWsudHVncmF6LmF0L2NhcHNvL09D U1A/Y2E9RXVyb1BLSUlBSUswQAYIKwYBBQUHMAKGNGh0dHA6Ly9jYS5pYWlrLnR1Z3Jhei5h dC9jYXBzby9jZXJ0cy9FdXJvUEtJSUFJSy5jZXIwHwYDVR0jBBgwFoAUOXTH3cjx+wpwPQ7K fUUCrKGb154wDQYJKoZIhvcNAQEFBQADggEBAAgys3wJ2CixcC8KuuO3a9k8u0nT0+PafLR9 wMQMWsz7xDTLNxiTJKnLvdFw86D+CH+nXxRweo/KDVYT56q5rfKs45I6mZDV+z/wecNX3odW MuY5a6j0g/RR4Qz/wokfeUzff5Yi6Hh1P9ce0u3/EHAHancJI3FxoZpLU5qNWZNo+fI6nluO BmdJCWZgCR9ijucmFubnu4EbWlyhiH2e0H2taU6zWvW/83yqbEO0BhDKVWWVtWvlF/ptBZQE JzAD1q5XJobPNQ/IANfs5ZcfuC1+Pm6FEG0cMVnDCGlRoA57oTIFaODWQPr4gxMy11/MYe9V ufBih5AU1z6V4IwJ5SYwggW6MIIEoqADAgECAgcCLHBKrpw3MA0GCSqGSIb3DQEBBQUAMIGs MRwwGgYDVQQDExNFdXJvUEtJIElBSUsgRW5jIENBMSYwJAYDVQQKEx1HcmF6IFVuaXZlcnNp dHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/SW5zdGl0dXRlIGZvciBBcHBsaWVkIEluZm9y bWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMQ0wCwYDVQQHEwRHcmF6MQsw CQYDVQQGEwJBVDAeFw0wODExMjcxMzM5MDZaFw0xMTExMjcxMzM5MDZaMIHGMREwDwYDVQQq EwhUb21pc2xhdjEMMAoGA1UEBBMDTmFkMRUwEwYDVQQDEwxUb21pc2xhdiBOYWQxJjAkBgNV BAoTHUdyYXogVW5pdmVyc2l0eSBvZiBUZWNobm9sb2d5MUgwRgYDVQQLEz9JbnN0aXR1dGUg Zm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMx DTALBgNVBAcTBEdyYXoxCzAJBgNVBAYTAkFUMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEArdttlPPyiXQcfNaxUmw8mXGsij68oGPwlkxwcGcLrL+7738AefMTtG6OrJdlMU8c e0pZybwu2BV5M/Vcug79hd9aY0TYRMEkhU16griXNqkImEz0rAvSJGtFuPP9Z1QJ0XNG9kZQ rdD5ODYPsijU3B04b8qWDby5xJ81KG2x7K6T5mYg6U8vfXm7UsnS5skZxvaTHOgtPKIat/LY ZmDTycdsXX2zuRVJ9hjki+nG9DYJfgRifVRKfS0QAft8oD4Io4hRKlkIk7JFVA+loL3uY7oa KgATptfG4FLN8ALEESNQE00DY0DMJpHd/JrvArcriVfovCYv+5K5Ko8o3odfGwIDAQABo4IB wzCCAb8wDgYDVR0PAQH/BAQDAgQwMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFNS8USUyDcW4 HBZG3l0e0DgKbd3oMFAGA1UdIARJMEcwRQYMKwYBBAGVEgECAwEBMDUwMwYIKwYBBQUHAgEW J2h0dHA6Ly9ldXJvcGtpLmlhaWsuYXQvY2EvaWFpay9jcHMvMS4zLzBIBgNVHR8EQTA/MD2g O6A5hjdodHRwOi8vY2EuaWFpay50dWdyYXouYXQvY2Fwc28vY3Jscy9FdXJvUEtJSUFJS19F bmMuY3JsMIGaBggrBgEFBQcBAQSBjTCBijBCBggrBgEFBQcwAYY2aHR0cDovL2NhLmlhaWsu dHVncmF6LmF0L2NhcHNvL09DU1A/Y2E9RXVyb1BLSUlBSUtfRW5jMEQGCCsGAQUFBzAChjho dHRwOi8vY2EuaWFpay50dWdyYXouYXQvY2Fwc28vY2VydHMvRXVyb1BLSUlBSUtfRW5jLmNl cjAmBgNVHREEHzAdgRt0b21pc2xhdi5uYWRAaWFpay50dWdyYXouYXQwHwYDVR0jBBgwFoAU 3UP298kNEZZgTQSlVkIYEiSm2uowDQYJKoZIhvcNAQEFBQADggEBAFeoU6Sd+M9BzSF7BbSD 2HATt3fEMIzPS5k1raikQU5056UNy8iCkg/cW7DWUOez9KlqSjsfs9xYnGufUi/C9HHYuc2U 1uqi7J3uhgee9GRo0iy6TC1nG/cpTSUDmR6r85NBHuugyYs8xj2AkN9JKLKfiOB5kalI6VeJ SiLrUbLBtzEKvWzBqNp5gjdmVvhH2SyzEJrYbsGp1H6Pvvq0RcUS+YduiO7y69dSQ1lzHzzg frpW4Klnj95JkwBVJG+g61hIwRdcna8KzWIpfTf4dZPANwNzKSckDqdyHU+zJOt/lBc4iZFS hM7rzZVedlidn3EPVfD+Yn1lim13bbD0jF8wggW6MIIEoqADAgECAgcD1ViHhc9jMA0GCSqG SIb3DQEBBQUAMIGsMRwwGgYDVQQDExNFdXJvUEtJIElBSUsgU2lnIENBMSYwJAYDVQQKEx1H cmF6IFVuaXZlcnNpdHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/SW5zdGl0dXRlIGZvciBB cHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMQ0wCwYD VQQHEwRHcmF6MQswCQYDVQQGEwJBVDAeFw0wODExMjcxMzM1MjRaFw0xMTExMjcxMzM1MjRa MIHGMREwDwYDVQQqEwhUb21pc2xhdjEMMAoGA1UEBBMDTmFkMRUwEwYDVQQDEwxUb21pc2xh diBOYWQxJjAkBgNVBAoTHUdyYXogVW5pdmVyc2l0eSBvZiBUZWNobm9sb2d5MUgwRgYDVQQL Ez9JbnN0aXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29t bXVuaWNhdGlvbnMxDTALBgNVBAcTBEdyYXoxCzAJBgNVBAYTAkFUMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA4QVx07SO58dqk9jJzGWw9IhSh2pyfwZ1PI7D4OyV81uo6nX9 WkIIlrgXIin+SfjGg4vwOhkBpDpDqYsn5FC+HV0qmvezf/DmuJMXczFXJZZJq/invDu22z+M P+qksgO+BXvfC6iP/IovOPDF8NZHdRmccWSktxm5gy0Y3vXU0JxNxaNAGOgGQO+CfCzxONfR gsHMpFkFlwdQrh3JBlJlIHpfjzhvl6bddWCtrvGazDZPVdbGXToaVnhtjG+SNrVuWqubGjRX Q7ttNVtRyBwJxkclscV3ZgObydoWed5TwsruVj8FrgL6RlexzGExGaKqufSoKZD0zS+bwpwH 1nPDVQIDAQABo4IBwzCCAb8wDgYDVR0PAQH/BAQDAgbAMAwGA1UdEwEB/wQCMAAwHQYDVR0O BBYEFFC5jw/NBM83a0KQ3O7D3qOToilpMFAGA1UdIARJMEcwRQYMKwYBBAGVEgECAwEBMDUw MwYIKwYBBQUHAgEWJ2h0dHA6Ly9ldXJvcGtpLmlhaWsuYXQvY2EvaWFpay9jcHMvMS4zLzBI BgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY2EuaWFpay50dWdyYXouYXQvY2Fwc28vY3Jscy9F dXJvUEtJSUFJS19TaWcuY3JsMIGaBggrBgEFBQcBAQSBjTCBijBCBggrBgEFBQcwAYY2aHR0 cDovL2NhLmlhaWsudHVncmF6LmF0L2NhcHNvL09DU1A/Y2E9RXVyb1BLSUlBSUtfU2lnMEQG CCsGAQUFBzAChjhodHRwOi8vY2EuaWFpay50dWdyYXouYXQvY2Fwc28vY2VydHMvRXVyb1BL SUlBSUtfU2lnLmNlcjAmBgNVHREEHzAdgRt0b21pc2xhdi5uYWRAaWFpay50dWdyYXouYXQw HwYDVR0jBBgwFoAUru5VBhd6UxETGKukzhxxCRqDFPMwDQYJKoZIhvcNAQEFBQADggEBAEXz IF0SpcMrpUtKHLx+R8ViT7AzpgMo02Z6ZoVvfgHZM+LZYQRBRxIpcpVhKYBdGGlR4w9pzuF9 Yz4ByZd2uDAl+78s9+h/QRsuzw4mO/LRkIaDcXcJns73j6L7sLgR0rVUYwbhKeia9531vzUE q2m39ElbCOBfFHILkzzrSbINQFrEXdFNJBeYYsTP1WouILFeI/Gb1Df60gmvjA+k8qER+3Bm nk7vat3C7Aoo2MqLj/Ze6Zj65OU9zGTmW/SXK5anY0gTV7HtoiUzLqTOW5EiAM9pH15CAV69 Ya5lg2NWtWDHf9x5PZ22aGqlrSJdN4PheFqiQ6xkeseanZNlifgxggQ8MIIEOAIBATCBuDCB rDEcMBoGA1UEAxMTRXVyb1BLSSBJQUlLIFNpZyBDQTEmMCQGA1UEChMdR3JheiBVbml2ZXJz aXR5IG9mIFRlY2hub2xvZ3kxSDBGBgNVBAsTP0luc3RpdHV0ZSBmb3IgQXBwbGllZCBJbmZv cm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczENMAsGA1UEBxMER3JhejEL MAkGA1UEBhMCQVQCBwPVWIeFz2MwCQYFKw4DAhoFAKCCAlgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgxMTI4MTY0MTI3WjAjBgkqhkiG9w0BCQQxFgQU QgDFEHdmqigQYESyzIFPLInDRuMwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMIHJBgkrBgEEAYI3EAQxgbswgbgwgawxHDAaBgNVBAMTE0V1cm9QS0kgSUFJ SyBFbmMgQ0ExJjAkBgNVBAoTHUdyYXogVW5pdmVyc2l0eSBvZiBUZWNobm9sb2d5MUgwRgYD VQQLEz9JbnN0aXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQg Q29tbXVuaWNhdGlvbnMxDTALBgNVBAcTBEdyYXoxCzAJBgNVBAYTAkFUAgcCLHBKrpw3MIHL BgsqhkiG9w0BCRACCzGBu6CBuDCBrDEcMBoGA1UEAxMTRXVyb1BLSSBJQUlLIEVuYyBDQTEm MCQGA1UEChMdR3JheiBVbml2ZXJzaXR5IG9mIFRlY2hub2xvZ3kxSDBGBgNVBAsTP0luc3Rp dHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0 aW9uczENMAsGA1UEBxMER3JhejELMAkGA1UEBhMCQVQCBwIscEqunDcwDQYJKoZIhvcNAQEB BQAEggEAhjNBCump0mp1wyIHaE9c8QpbCzH6l30dh76zJ5JwRHFGz6H0T/4Wp8UvYByShYAa Ms7zrI4G+S13t86VelddSobGsC655dv2GqEvsIq+jQ7IAzdw8ddr/ukFW7YXVF76XNJ/KY+b 6ZZSXV7KBPsLjDuE+VtCOeH5R+klsUpb4N9LmOZvGmxGC/EU0sYaaKCR12NcjK4yo/Ea12AD omHl7VkQ7eZ3JoQMyM9M+Q7lA0MeiWuvHiftLkJ0z2hm4bt1D+dK7UnUYfJtSjrwU7ZMscgJ IN9rult6TzG9GCw4verwLcd8Qt+WPynNYSkrL6QwIDM4VoARys/6VDNkdV78JQAAAAAAAA== --------------ms010907060308090409050208-- From hash-forum@nist.gov Sat Nov 29 06:26:31 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mATEQPbP021212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 29 Nov 2008 06:26:27 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mATEF7ZL015771; Sat, 29 Nov 2008 09:15:11 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mATEDE3u010564; Sat, 29 Nov 2008 09:13:14 -0500 Date: Sat, 29 Nov 2008 09:13:14 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "nasour bagheri" To: Multiple recipients of list Subject: Free start collision, second preimage, and preimage on JH X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: WorldClient 9.0.4 Content-Type: multipart/alternative; boundary="_1129-1732-26-PART-BREAK" MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 29 Nov 2008 06:26:27 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,HTML_FONT_FACE_BAD, HTML_MESSAGE,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 240 --_1129-1732-26-PART-BREAK Content-Type: text/plain; charset=us-ascii Dear All , If I have understood the JH hash scheme correctly, the $E_d$ block is a permutation. So we can see this scheme as a variant of Sponge hah function. Now one can select a message in his choice (but considering the specific padding rule) and combined with the given target and reverse the hash function. However, he/she has not any control over the achieved IV. The same approach can be used for free start collision and second preimage. The complexity of attacks is one or two JH function in reverse. The designer has not presented any security against free start attacks. I am not claiming that the attack is a break of the JH hash function, nor that any security claims made by you are invalidated. Best regards, Nasour ****************************************************************** Ph.D. Student Electrical Engineering Department Iran University of Science and Technology (IUST) http://webpages.iust.ac.ir/n_bagheri/ ********************************************************************* --_1129-1732-26-PART-BREAK Content-Type: text/html; charset=us-ascii
Dear All ,
 
If I have understood the JH hash scheme correctly, the $E_d$ block is a permutation. So we can see this scheme as a variant of Sponge hah function. Now one can select a message in his choice (but considering the specific padding rule) and combined with the given target and reverse the hash function. However, he/she has not any control over the achieved IV. The same approach can be used for free start collision and second preimage. The complexity of attacks is one or two JH function in reverse. The designer has not presented any security against free start attacks.
 
I am not claiming that the attack is a break of the JH hash function,
nor that any security claims made by you are invalidated.
 
Best regards,
Nasour 
 
******************************************************************
Ph.D. Student
Electrical Engineering Department
Iran University of Science and Technology (IUST)
http://webpages.iust.ac.ir/n_bagheri/
*********************************************************************
--_1129-1732-26-PART-BREAK-- From hash-forum@nist.gov Sat Nov 29 07:10:17 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mATFABJx027232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 29 Nov 2008 07:10:13 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mATF9Kbm028249; Sat, 29 Nov 2008 10:09:24 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mATF8pdK018364; Sat, 29 Nov 2008 10:08:51 -0500 Date: Sat, 29 Nov 2008 10:08:51 -0500 Message-Id: <7a91b6960811290704y295ad1f7k5a432d8928e93828@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Hongjun Wu" To: Multiple recipients of list Subject: Re: Free start collision, second preimage, and preimage on JH X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: Content-Type: multipart/alternative; boundary="----=_Part_57682_25077618.1227971053027" MIME-Version: 1.0 In-Reply-To: X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 29 Nov 2008 07:10:13 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,HTML_FONT_FACE_BAD, HTML_MESSAGE,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 241 ------=_Part_57682_25077618.1227971053027 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline The attack given by Nasour is to find two different IVs together with two different messages that generate the same message digest. :-) The attack may be called "free" start attack, but it is too "free". I believe that Nasour's attack can also be applied to MD5, SHA-1 and SHA-2 .. ( with one or two hash reverses to find two different IVs with two different messages to generate the same message digest ) By the way, I need to point out that the design of JH is quite different from Sponge since the messeage in JH is XORed with the both the input and output of the bijective function. Best Regards, hongjun On Sat, Nov 29, 2008 at 3:13 PM, nasour bagheri wrote: > Dear All , > > If I have understood the JH hash scheme correctly, the $E_d$ block is a > permutation. So we can see this scheme as a variant of Sponge hah function. > Now one can select a message in his choice (but considering the specific > padding rule) and combined with the given target and reverse the hash > function. However, he/she has not any control over the achieved IV. The same > approach can be used for free start collision and second preimage. The > complexity of attacks is one or two JH function in reverse. The designer has > not presented any security against free start attacks. > > I am not claiming that the attack is a break of the JH hash function, > nor that any security claims made by you are invalidated. > > Best regards, > Nasour > > ****************************************************************** > Ph.D. Student > Electrical Engineering Department > Iran University of Science and Technology (IUST) > http://webpages.iust.ac.ir/n_bagheri/ > ********************************************************************* > ------=_Part_57682_25077618.1227971053027 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline The attack given by Nasour is to find two different IVs together with two different messages that generate the same message digest.  :-)    The attack may be called "free" start attack, but it is too "free".

I believe that Nasour's attack can also be applied to MD5, SHA-1 and SHA-2 ... ( with one or two hash reverses to find two different IVs with two different messages to generate the same message digest )   

By the way, I need to point out that the design of JH is quite different from Sponge since the messeage in JH is XORed with the both the input and output of the bijective function.

Best Regards,
hongjun



On Sat, Nov 29, 2008 at 3:13 PM, nasour bagheri <n_bagheri@iust.ac.ir> wrote:
Dear All ,
 
If I have understood the JH hash scheme correctly, the $E_d$ block is a permutation. So we can see this scheme as a variant of Sponge hah function. Now one can select a message in his choice (but considering the specific padding rule) and combined with the given target and reverse the hash function. However, he/she has not any control over the achieved IV. The same approach can be used for free start collision and second preimage. The complexity of attacks is one or two JH function in reverse. The designer has not presented any security against free start attacks.
 
I am not claiming that the attack is a break of the JH hash function,
nor that any security claims made by you are invalidated.
 
Best regards,
Nasour 
 
******************************************************************
Ph.D. Student
Electrical Engineering Department
Iran University of Science and Technology (IUST)
http://webpages.iust.ac.ir/n_bagheri/
*********************************************************************

------=_Part_57682_25077618.1227971053027-- From hash-forum@nist.gov Sat Nov 29 07:30:22 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mATFUEu2029473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 29 Nov 2008 07:30:15 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mATF9Kbw028249; Sat, 29 Nov 2008 10:09:26 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mATF9CUM019065; Sat, 29 Nov 2008 10:09:12 -0500 Date: Sat, 29 Nov 2008 10:09:12 -0500 Message-Id: <7a91b6960811290708kc23d907n67e685fbc3ec80d3@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Hongjun Wu" To: Multiple recipients of list Subject: Re: Free start collision, second preimage, and preimage on JH X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <7a91b6960811290704y295ad1f7k5a432d8928e93828@mail.gmail.com> Content-Type: multipart/alternative; boundary="----=_Part_57704_30823670.1227971304459" MIME-Version: 1.0 In-Reply-To: <7a91b6960811290704y295ad1f7k5a432d8928e93828@mail.gmail.com> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 29 Nov 2008 07:30:15 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,HTML_FONT_FACE_BAD, HTML_MESSAGE,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 242 ------=_Part_57704_30823670.1227971304459 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline correction to my previous e-mail. there is a mistake in my e-mail. Nasour's attack cannot be applied to MD5, SHA-1 and SHA-2... But it can be applied to a number of hash schemes that are invertible when the message is known. Best Regards, hongjun On Sat, Nov 29, 2008 at 4:04 PM, Hongjun Wu wrote: > The attack given by Nasour is to find two different IVs together with two > different messages that generate the same message digest. :-) The attack > may be called "free" start attack, but it is too "free". > > I believe that Nasour's attack can also be applied to MD5, SHA-1 and SHA-2 > ... ( with one or two hash reverses to find two different IVs with two > different messages to generate the same message digest ) > > By the way, I need to point out that the design of JH is quite different > from Sponge since the messeage in JH is XORed with the both the input and > output of the bijective function. > > Best Regards, > hongjun > > > > > On Sat, Nov 29, 2008 at 3:13 PM, nasour bagheri wrote: > >> Dear All , >> >> If I have understood the JH hash scheme correctly, the $E_d$ block is a >> permutation. So we can see this scheme as a variant of Sponge hah function. >> Now one can select a message in his choice (but considering the specific >> padding rule) and combined with the given target and reverse the hash >> function. However, he/she has not any control over the achieved IV. The same >> approach can be used for free start collision and second preimage. The >> complexity of attacks is one or two JH function in reverse. The designer has >> not presented any security against free start attacks. >> >> I am not claiming that the attack is a break of the JH hash function, >> nor that any security claims made by you are invalidated. >> >> Best regards, >> Nasour >> >> ****************************************************************** >> Ph.D. Student >> Electrical Engineering Department >> Iran University of Science and Technology (IUST) >> http://webpages.iust.ac.ir/n_bagheri/ >> ********************************************************************* >> > > ------=_Part_57704_30823670.1227971304459 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline correction to my previous e-mail.

there is a mistake in my e-mail.  Nasour's attack cannot be applied to MD5, SHA-1 and SHA-2...

But it can be applied to a number of hash schemes that are invertible when the message is known.

Best Regards,
hongjun

On Sat, Nov 29, 2008 at 4:04 PM, Hongjun Wu <wuhongjun@gmail.com> wrote:
The attack given by Nasour is to find two different IVs together with two different messages that generate the same message digest.  :-)    The attack may be called "free" start attack, but it is too "free".

I believe that Nasour's attack can also be applied to MD5, SHA-1 and SHA-2 ... ( with one or two hash reverses to find two different IVs with two different messages to generate the same message digest )   

By the way, I need to point out that the design of JH is quite different from Sponge since the messeage in JH is XORed with the both the input and output of the bijective function.

Best Regards,
hongjun




On Sat, Nov 29, 2008 at 3:13 PM, nasour bagheri <n_bagheri@iust.ac.ir> wrote:
Dear All ,
 
If I have understood the JH hash scheme correctly, the $E_d$ block is a permutation. So we can see this scheme as a variant of Sponge hah function. Now one can select a message in his choice (but considering the specific padding rule) and combined with the given target and reverse the hash function. However, he/she has not any control over the achieved IV. The same approach can be used for free start collision and second preimage. The complexity of attacks is one or two JH function in reverse. The designer has not presented any security against free start attacks.
 
I am not claiming that the attack is a break of the JH hash function,
nor that any security claims made by you are invalidated.
 
Best regards,
Nasour 
 
******************************************************************
Ph.D. Student
Electrical Engineering Department
Iran University of Science and Technology (IUST)
http://webpages.iust.ac.ir/n_bagheri/
*********************************************************************


------=_Part_57704_30823670.1227971304459-- From hash-forum@nist.gov Sat Nov 29 07:37:33 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mATFbSnt030216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 29 Nov 2008 07:37:29 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mATFaUAi030785; Sat, 29 Nov 2008 10:36:34 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mATFa6fN004674; Sat, 29 Nov 2008 10:36:06 -0500 Date: Sat, 29 Nov 2008 10:36:06 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "nasour bagheri" To: Multiple recipients of list Subject: Re: Free start collision, second preimage, and preimage on JH X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: In-Reply-To: X-Mailer: WorldClient 9.0.4 Content-Type: multipart/alternative; boundary="_1129-1902-31-PART-BREAK" MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 29 Nov 2008 07:37:30 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,HTML_FONT_FACE_BAD, HTML_MESSAGE,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 243 --_1129-1902-31-PART-BREAK Content-Type: text/plain; charset=us-ascii Dear all, I must correct my previous email and mention that the attack can find pseudo-collision, not free-start collision and pseudo-second preimag, not free-start second preimag. Acknowledgements: spacial thanks go to Hongjun Wu to correct me. Best regards, Nasour ********************************************************************* Ph.D. Student Electrical Engineering Department Iran University of Science and Technology (IUST) http://webpages.iust.ac.ir/n_bagheri/ ********************************************************************* -----Original Message----- From: "nasour bagheri" To: Multiple recipients of list Date: Sat, 29 Nov 2008 09:13:14 -0500 Subject: Free start collision, second preimage, and preimage on JH Dear All , If I have understood the JH hash scheme correctly, the $E_d$ block is a permutation. So we can see this scheme as a variant of Sponge hah function. Now one can select a message in his choice (but considering the specific padding rule) and combined with the given target and reverse the hash function. However, he/she has not any control over the achieved IV. The same approach can be used for free start collision and second preimage. The complexity of attacks is one or two JH function in reverse. The designer has not presented any security against free start attacks. I am not claiming that the attack is a break of the JH hash function, nor that any security claims made by you are invalidated. Best regards, Nasour ****************************************************************** Ph.D. Student Electrical Engineering Department Iran University of Science and Technology (IUST) http://webpages.iust.ac.ir/n_bagheri/ ********************************************************************* --_1129-1902-31-PART-BREAK Content-Type: text/html; charset=us-ascii
Dear all,
 
I must correct my previous email and mention that the attack can find  pseudo-collision, not free-start collision and pseudo-second preimag, not free-start second preimag.
 
Acknowledgements: spacial thanks go to Hongjun Wu to correct me.
 
 Best regards,
Nasour
 *********************************************************************
Ph.D. Student
Electrical Engineering Department
Iran University of Science and Technology (IUST)
http://webpages.iust.ac.ir/n_bagheri/
*********************************************************************

-----Original Message-----
From: "nasour bagheri" <n_bagheri@iust.ac.ir>
To: Multiple recipients of list <hash-forum@nist.gov>
Date: Sat, 29 Nov 2008 09:13:14 -0500
Subject: Free start collision, second preimage, and preimage on JH

Dear All ,
 
If I have understood the JH hash scheme correctly, the $E_d$ block is a permutation. So we can see this scheme as a variant of Sponge hah function. Now one can select a message in his choice (but considering the specific padding rule) and combined with the given target and reverse the hash function. However, he/she has not any control over the achieved IV. The same approach can be used for free start collision and second preimage. The complexity of attacks is one or two JH function in reverse. The designer has not presented any security against free start attacks.
 
I am not claiming that the attack is a break of the JH hash function,
nor that any security claims made by you are invalidated.
 
Best regards,
Nasour 
 
******************************************************************
Ph.D. Student
Electrical Engineering Department
Iran University of Science and Technology (IUST)
http://webpages.iust.ac.ir/n_bagheri/
*********************************************************************
--_1129-1902-31-PART-BREAK-- From hash-forum@nist.gov Sun Nov 30 10:39:39 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mAUIdWjH032361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 30 Nov 2008 10:39:33 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mAUHvEoR000872; Sun, 30 Nov 2008 12:57:19 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mAUHtUds030988; Sun, 30 Nov 2008 12:55:30 -0500 Date: Sun, 30 Nov 2008 12:55:30 -0500 Message-Id: <200646.4694.qm@web36408.mail.mud.yahoo.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Peter To: Multiple recipients of list Subject: Re: Second preimage attack on Ponic X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/alternative; boundary="0-1100789258-1228066965=:4694" MIME-Version: 1.0 X-To: hash-forum@nist.gov X-Mailer: YahooMailWebService/0.7.260.1 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: Delayed for 00:41:04 by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sun, 30 Nov 2008 10:39:33 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,FORGED_YAHOO_RCVD, HTML_MESSAGE,RCVD_IN_DNSWL_MED,URI_HEX shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 244 --0-1100789258-1228066965=:4694 Content-Type: text/plain; charset=us-ascii Neat attack! Can I correctly summarize it by saying: "It allows one to perform a birthday attack (2^n/2) as a second preimage attack."? The algorithm could be protected from this attack by simply doubling the internal state. (Or even just the internal state that isn't controlled by the attacker.) For this reason I suggest replacing the 6 CSRs with 10 CSRs. Also expanding the other portions of the algorithm, such as adding 4 new sboxes (One for each new CSR), and increasing the number of rounds in the NLF to 10 (Again, just increasing it to reflect the new number of CSRs). This will increase the time-complexity of the attack to 2^512, no better than the generic attack for all hash bit lengths. Nonetheless, this does slow down the algorithm if fixed, and (if unfixed) brings the algorithm to have no more security against second preimage than a 256 bit random oracle. I consider this attack to break Ponic in hash bit lengths above 256, and therefore disqualifies Ponic from SHA-3 unless simply expanded as above. I will release revised source-code for the expanded internal state shortly. P.S. The new sboxes should be generated in the same manner described in the PDF, (changing xrange(6) to xrange(10)) --- On Fri, 11/28/08, Maria Naya wrote: From: Maria Naya Subject: Second preimage attack on Ponic To: "Multiple recipients of list" Date: Friday, November 28, 2008, 8:02 AM Hello, we have found a second preimage attack on Ponic-512 with complexity 2^{265}.You can find it here: http://131002.net/data/papers/ponic.pdf Best regards, Maria --0-1100789258-1228066965=:4694 Content-Type: text/html; charset=us-ascii
Neat attack!
Can I correctly summarize it by saying: "It allows one to perform a birthday attack (2^n/2) as a second preimage attack."?

The algorithm could be protected from this attack by simply doubling the internal state. (Or even just the internal state that isn't controlled by the attacker.) For this reason I suggest replacing the 6 CSRs with 10 CSRs. Also expanding the other portions of the algorithm, such as adding 4 new sboxes (One for each new CSR), and increasing the number of rounds in the NLF to 10 (Again, just increasing it to reflect the new number of CSRs). This will increase the time-complexity of the attack to 2^512, no better than the generic attack for all hash bit lengths.
Nonetheless, this does slow down the algorithm if fixed, and (if unfixed) brings the algorithm to have no more security against second preimage than a 256 bit random oracle.

I consider this attack to break Ponic in hash bit lengths above 256, and therefore disqualifies Ponic from SHA-3 unless simply expanded as above.

I will release revised source-code for the expanded internal state shortly.

P.S. The new sboxes should be generated in the same manner described in the PDF, (changing xrange(6) to xrange(10))

--- On Fri, 11/28/08, Maria Naya <maria.naya.plasencia@gmail.com> wrote:
From: Maria Naya <maria.naya.plasencia@gmail.com>
Subject: Second preimage attack on Ponic
To: "Multiple recipients of list" <hash-forum@nist.gov>
Date: Friday, November 28, 2008, 8:02 AM

Hello,

we have found a second preimage attack on Ponic-512 with complexity 2^{265}.
You can find it here:

--0-1100789258-1228066965=:4694-- From hash-forum@nist.gov Mon Dec 1 06:13:53 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB1EDmLl002075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 1 Dec 2008 06:13:49 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB1E7Kvm032458; Mon, 1 Dec 2008 09:07:28 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB1E5fsC006357; Mon, 1 Dec 2008 09:05:41 -0500 Date: Mon, 1 Dec 2008 09:05:41 -0500 Message-Id: <20081201140218.E4EA92258004@postaci.uekae.tubitak.gov.tr> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: orhun@uekae.tubitak.gov.tr To: Multiple recipients of list Subject: improved cryptanalysis of SHAMATA-BC X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain;charset=iso-8859-9 MIME-Version: 1.0 X-To: hash-forum@nist.gov References: <20081128160720.619492258004@postaci.uekae.tubitak.gov.tr> In-Reply-To: <20081128160720.619492258004@postaci.uekae.tubitak.gov.tr> X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 01 Dec 2008 06:13:50 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 245 Dear all, I, as a designer, would like to announce that Ewan Fleischmann and Michael Gorski posted a note to ecyrpt SHA-3 Zoo page related to SHAMATA hash function. They have described a one-round block cipher, which they call SHAMATA-BC, using the building blocks of SHAMATA such as DataLoad and ClockRegister. They show that SHAMATA-BC is very weak. Unfurtunely, SHAMATA-BC is a faulty design. We have fixed the design and show that SHAMATA-BC is indeed much weaker than Ewan Fleischmann and Michael Gorski claim. The xor of left part of a ciphertext with the right part of the corresponding plaintext simply gives the "key". The details are available at the SHA-3 Zoo page. I cordially belive that SHAMATA-BC is one of the weakest block cipher which can be designed by using the building blocks of SHAMATA. However, everyone can design a weak block cipher from the building blocks of a cryptographic primitive independently whether the primitive is secure or not. The most important issue is to write down a statement related to security levels of both. By the way, SHAMATA is a register based hash function, like sponge constructions. It is not a block cipher based hash fucntion. Data blocks are loaded into the registers and then the registers are clocked. SHAMATA has no internal block cipher like SHA family. The clocking mechanism is invertible. So, it is trivial that one can easily deduce the current data loaded, from the current internal state and the next internal state. This fact is valid for almost all sponge constructions. Roughly speaking, the analysis of SHAMATA-BC just says that the clocking mechanism is invertible by deducing the data (which is called "the key") from the current and the next internal states (which are called "the plaintext" and "the ciphertext" respectively). Best regards, Orhun From hash-forum@nist.gov Mon Dec 1 08:04:54 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB1G4lZf012649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 1 Dec 2008 08:04:49 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB1G321C019800; Mon, 1 Dec 2008 11:03:07 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB1G1cBe019631; Mon, 1 Dec 2008 11:01:38 -0500 Date: Mon, 1 Dec 2008 11:01:38 -0500 Message-Id: <49340980.8080908@win.dtu.dk> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: =?ISO-8859-1?Q?S=F8ren_Steffen_Thomsen?= To: Multiple recipients of list Subject: Second preimage attack on MeshHash X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-To: "hash-forum@nist.gov" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 01 Dec 2008 08:04:50 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 246 Dear all, I have found a second preimage attack on MeshHash. See http://www.mat.dtu.dk/people/S.Thomsen/meshhash/2ndpreimage.pdf. The attack finds a second preimage of, e.g., MeshHash-256 in time about 2^194. It uses a meet-in-the-middle approach, exploiting the relatively small state. Best regards, Søren. -- Søren Steffen Thomsen PH.D. student DTU Mathematics ------------------------------- Technical University of Denmark Department of Mathematics Matematiktorvet 303S Building 303S 2800 Kgs. Lyngby Direct +45 4525 3010 Mobile +45 2290 5443 S.Thomsen@mat.dtu.dk www.mat.dtu.dk/ From hash-forum@nist.gov Tue Dec 2 03:30:01 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB2BTtJo016127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Dec 2008 03:29:57 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB2BSQV2009962; Tue, 2 Dec 2008 06:28:29 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB2BQjWS025822; Tue, 2 Dec 2008 06:26:45 -0500 Date: Tue, 2 Dec 2008 06:26:45 -0500 Message-Id: <493518C5.3070603@larc.usp.br> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Paulo S. L. M. Barreto" To: Multiple recipients of list Subject: Re: Second preimage attack on MeshHash X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 In-Reply-To: <49340980.8080908@win.dtu.dk> References: <49340980.8080908@win.dtu.dk> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 02 Dec 2008 03:29:57 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 247 Søren Steffen Thomsen wrote: > Dear all, > > I have found a second preimage attack on MeshHash. See > http://www.mat.dtu.dk/people/S.Thomsen/meshhash/2ndpreimage.pdf. The > attack finds a second preimage of, e.g., MeshHash-256 in time about > 2^194. It uses a meet-in-the-middle approach, exploiting the relatively > small state. Hmm... are you sure this is not roughly the same idea put forward in Dan Bernstein's "attack" against MD6? Just asking... Paulo. From hash-forum@nist.gov Tue Dec 2 04:07:15 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB2C7AMQ021258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Dec 2008 04:07:11 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB2BtkYO004345; Tue, 2 Dec 2008 06:55:52 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB2BtKLF016081; Tue, 2 Dec 2008 06:55:20 -0500 Date: Tue, 2 Dec 2008 06:55:20 -0500 Message-Id: <49352010.6040507@win.dtu.dk> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: =?ISO-8859-1?Q?S=F8ren_Steffen_Thomsen?= To: Multiple recipients of list Subject: Re: Second preimage attack on MeshHash X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="ISO-8859-1" In-Reply-To: <493518C5.3070603@larc.usp.br> References: <49340980.8080908@win.dtu.dk> <493518C5.3070603@larc.usp.br> MIME-Version: 1.0 X-To: "hash-forum@nist.gov" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 02 Dec 2008 04:07:11 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 248 I must admit that I don't see any similarity at all. My attack is an unbalanced meet-in-the-middle attack. Being able to invert the "compression function" in time 2^64 leads to a second preimage attack in time about 2^((l+64)/2), where l is the state size. Since l < 2n-64 for the most common values of n, the attack is faster than brute force. I am open to reasonable argumentation, though. /Søren Paulo S. L. M. Barreto wrote: > Søren Steffen Thomsen wrote: >> Dear all, >> >> I have found a second preimage attack on MeshHash. See >> http://www.mat.dtu.dk/people/S.Thomsen/meshhash/2ndpreimage.pdf. The >> attack finds a second preimage of, e.g., MeshHash-256 in time about >> 2^194. It uses a meet-in-the-middle approach, exploiting the relatively >> small state. > > Hmm... are you sure this is not roughly the same idea put forward in Dan > Bernstein's "attack" against MD6? > > Just asking... > > Paulo. > -- Søren Steffen Thomsen PH.D. student DTU Mathematics ------------------------------- Technical University of Denmark Department of Mathematics Matematiktorvet 303S Building 303S 2800 Kgs. Lyngby Direct +45 4525 3010 Mobile +45 2290 5443 S.Thomsen@mat.dtu.dk www.mat.dtu.dk/ From hash-forum@nist.gov Tue Dec 2 03:57:10 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB2Bv4HL018006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Dec 2008 03:57:05 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB2BtkYY004345; Tue, 2 Dec 2008 06:55:54 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB2BtbNs016152; Tue, 2 Dec 2008 06:55:37 -0500 Date: Tue, 2 Dec 2008 06:55:37 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Markku-Juhani O. Saarinen" To: Multiple recipients of list Subject: initial comments on the FSB SHA-3 proposal X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 02 Dec 2008 03:57:05 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 249 Hi, As the author of [1], I was quite astonished to see the FSB SHA-3 proposal come to light [2]. [1] M.-J. O. Saarinen, "Linearization Attacks Against Syndrome Based Hashes." In K. Srinathan, C. Pandu Rangan, M. Yung (Eds.): Indocrypt 2007, LNCS 4859, Springer-Verlag 2007. pp. 1-9. [2] D. Augot et al, "Fast Syndrome-Based hash function SHA-3 Proposal" http://www-rocq.inria.fr/secret/CBCrypto/index.php?pg=fsb ---- Let me just go through sections 5.1 and 5.2 (p. 12) of the specification point by point. "5.1 Limitations - First of all, FSB is slower than the traditional MD5 or SHA-1. It uses much more cycles per byte to hash and also has an important initialization time" That's not good. "- FSB has a large description: about 2 millions bits generated from digits of Pi are used." Try fitting 2 million bits of Pi that into a microcontroller. "- FSB uses a large internal state (about 4 times the ?nal hash size) which makes it necessary to add a ?nal compression function. Reducing the size of the internal state will reduce the security of the compression function, so this ?nal compression is mandatory. Here, we use Whirlpool," Their hash proposal uses an another hash function internally. So we need to implement Whirpool to implement FSB. "- FSB still uses the Merkle-Damg?ard domain extender. This is probably not the best choice, but it is the simplest one." Simple is good. XOR is simple. XOR is good. No we come to the... "5.2 Advantages - The most decisive advantage of FSB is that it comes with a proof of reduction to hard algorithmic problems. An algorithm able to ?nd collisions on FSB or to invert FSB is also able to solve hard problems from coding theory." The algorithmic problems have hard AVERAGE CASE complexities for GENERAL problems, but that does not make collision search any harder in specific FSB cases as I quite clearly demonstrate in [1]. "These problems have been well studied for many years and it is unlikely that new attacks could be much more e?cient than the existing ones." I beg to differ. Three previous incarnations of FSB have been totally trashed, and I think I see a gaping linear hole in this. I will have to come back to this later, no collision claims yet. "The design of FSB is very simple: wether you see the compression function as the XOR of shifted vectors or the XOR of columns of a quasi-cyclic matrix, in both cases, describing FSB is simple. Having an easy to understand design helps when it comes to implementation." But then again, you need to implement Whirlpool too. "Also FSB uses mostly very simple operations: some shifts and some XORs. It is thus easy to obtain an optimized implementation spending a majority of time on operations that cannot be compressed." Now they are saying that the speed does not suck. Even though it does. "FSB is very ?exible in terms of parameters: these have to be selected with caution in order to ensure all the security requirements, but proposing sets of parameters for all lengths from 160 to 512 bits would be possible. This could avoid having to use truncated hashes." In the SHA-3 project, if I didn't miss something, we are trying to find a plug-in replacement for the SHA family; not some parametrizable theoretical construct. That's for conferences and journals. "The reference implementation of FSB we provide is relatively e?cient (apart from the long initialization time) and is suitable for any set of parameters." Sigh,. Best Regards, - markku // Markku-Juhani O. Saarinen http://www.m-js.com From hash-forum@nist.gov Tue Dec 2 06:01:13 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB2E173E031774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Dec 2008 06:01:08 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB2DxJaH007232; Tue, 2 Dec 2008 08:59:23 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB2Dw6dM031896; Tue, 2 Dec 2008 08:58:06 -0500 Date: Tue, 2 Dec 2008 08:58:06 -0500 Message-Id: <20081202135200.67375.qmail@cr.yp.to> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "D. J. Bernstein" To: Multiple recipients of list Subject: Re: Second preimage attack on MeshHash X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas In-Reply-To: <49352010.6040507@win.dtu.dk> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 02 Dec 2008 06:01:09 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 250 This attack is looking for (n+64)-bit collisions between f(x) and g(y). The function f is easy to compute but the function g is about 2^64 times more expensive. Standard low-memory collision search uses roughly 2^(n/2+32) evaluations of f and g, i.e., roughly 2^(n/2+96) easy operations. That's roughly 2^224 easy operations for n=256, or 2^352 for n=512. The original attack balances the costs of f and g by building a table of 2^(n/2) values of g and doing 2^(n/2+64) table lookups of values of f. The computations of f and g then take 2^(n/2+64) easy operations, but the table lookups are much slower, and the storage is very expensive. Can f and g be balanced in low-memory collision search? Recall that the standard approach is to build a function such as (0,x) |-> f(x) and (1,y) |-> g(y), evaluating f for half its inputs and g for the other half, and then cycle through iterates of that function (composed with a random-looking map from the range back to the domain); a collision in the function has a good chance of being a collision between f and g. The obvious way to balance f and g is to instead build, e.g., (r,x) |-> f(x) for any nonzero 64-bit string r, (0,y) |-> g(y), and then cycle through 2^(n/2+64) iterates, of which only about 2^(n/2) will be evaluations of g. Unfortunately, there's already a good chance of an f collision after 2^(n/2+32) iterates, producing a cycle that has nothing to do with g. (I'm assuming that the attack isn't nice enough to give us an injective function f.) I think that one can do much better with parallel collision search (with distinguished points), although this needs to be confirmed by proofs and experiments if it isn't already in the literature somewhere. Imagine iterating the above function along 2^80 separate trails, with 2^(n/2-16) steps in each trail; each trail is short enough to have a negligible chance of cycling. Overall there will be 2^(n/2+64) evaluations of f and 2^(n/2) evaluations of g, so there will be a good chance of a collision between f and g, plus a thicket of roughly 2^64 internal collisions in f. There's enough time to review every colliding trail pair to find the collision between f and g. With a smaller machine, let's say limited to 2^40 trails, the average trail would be involved in 2^24 collisions, so weeding out the chaff quickly enough would be more complicated. To summarize, a machine of size 2^p should be able to find a collision between f and g, and therefore a preimage in MeshHash-n, in time roughly 2^(n/2+64-p) for p >= 64. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago From hash-forum@nist.gov Tue Dec 2 07:03:39 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB2F3WSA005353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Dec 2008 07:03:35 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB2Espw2020969; Tue, 2 Dec 2008 09:54:57 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB2ErY2r021642; Tue, 2 Dec 2008 09:53:34 -0500 Date: Tue, 2 Dec 2008 09:53:34 -0500 Message-Id: <49354905.8020103@larc.usp.br> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Paulo S. L. M. Barreto" To: Multiple recipients of list Subject: Re: initial comments on the FSB SHA-3 proposal X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 In-Reply-To: References: MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 02 Dec 2008 07:03:36 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 251 Markku-Juhani O. Saarinen wrote: > > Hi, > > As the author of [1], I was quite astonished to see the FSB SHA-3 proposal > come to light [2]. > > [1] M.-J. O. Saarinen, "Linearization Attacks Against Syndrome Based > Hashes." In K. Srinathan, C. Pandu Rangan, M. Yung (Eds.): Indocrypt > 2007, LNCS 4859, Springer-Verlag 2007. pp. 1-9. > > [2] D. Augot et al, "Fast Syndrome-Based hash function SHA-3 Proposal" > http://www-rocq.inria.fr/secret/CBCrypto/index.php?pg=fsb > > ---- > > Let me just go through sections 5.1 and 5.2 (p. 12) of the specification > point by point. There seem to be two main points to your criticism: (1) efficiency, and (2) security. Your point on efficiency sounds fair enough albeit a bit harsh (although, mind you, I feel it's a bit too early to focus on efficiency; I'd rather leave that to the next phase of the SHA-3 competition and concentrate on security issues now), Finiasz claims your criticism on security is unfounded in section 5.3 of his recent work "Syndrome Based Collision Resistant Hashing," presented at PQCrypto'2008 . Does that address your security concerns? Paulo. From hash-forum@nist.gov Tue Dec 2 07:38:12 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB2Fc7Or008550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Dec 2008 07:38:08 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB2FapB6008008; Tue, 2 Dec 2008 10:36:58 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB2Fa0eB012423; Tue, 2 Dec 2008 10:36:00 -0500 Date: Tue, 2 Dec 2008 10:36:00 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Markku-Juhani O. Saarinen" To: Multiple recipients of list Subject: Re: initial comments on the FSB SHA-3 proposal X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed MIME-Version: 1.0 References: <49354905.8020103@larc.usp.br> In-Reply-To: <49354905.8020103@larc.usp.br> X-To: Multiple recipients of list X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 02 Dec 2008 07:38:08 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 252 On Tue, 2 Dec 2008, Paulo S. L. M. Barreto wrote: > There seem to be two main points to your criticism: (1) efficiency, and (2) > security. Your point on efficiency sounds fair enough albeit a bit harsh I agree, it is difficult to beat SHA-1 and MD5 speed with "provable security" type of hash functions. > security issues now), Finiasz claims your criticism on security is > unfounded in section 5.3 of his recent work "Syndrome Based Collision >Resistant Hashing," presented at PQCrypto'2008 . > > Does that address your security concerns? Not fully, I will have to have concrete proof (i.e. collisions) before I can claim that. Let me just say that the appendix of my IndoCrypt 2007 paper contains actual collisions on then-current choice of FSB securty parameters with claimed 2^128 security. Cheers, - markku // Markku-Juhani O. Saarinen http://www.m-js.com From hash-forum@nist.gov Tue Dec 2 08:19:48 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB2GJh6L013342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Dec 2008 08:19:44 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB2GIXe5012028; Tue, 2 Dec 2008 11:18:39 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB2GIJ6p003743; Tue, 2 Dec 2008 11:18:19 -0500 Date: Tue, 2 Dec 2008 11:18:19 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Markku-Juhani O. Saarinen" To: Multiple recipients of list Subject: Re: initial comments on the FSB SHA-3 proposal X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed MIME-Version: 1.0 References: <49354905.8020103@larc.usp.br> In-Reply-To: X-To: Multiple recipients of list X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 02 Dec 2008 08:19:44 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 253 On Tue, 2 Dec 2008, Markku-Juhani O. Saarinen wrote: > This is perhaps just a stupid priority issue.. but it would have been nice of > Finiasz to include my IndoCrypt 2007 paper in the references. I was the first > (and only?) person to write about linearization attacks on FSB. Sorry. I'll take this back, keep quiet, and get some sleep.. :)) It is in there. Cheers, - markku // Markku-Juhani O. Saarinen http://www.m-js.com From hash-forum@nist.gov Tue Dec 2 08:19:46 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB2GJdI5013319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Dec 2008 08:19:41 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB2GIMF2007993; Tue, 2 Dec 2008 11:18:26 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB2GHcJG002158; Tue, 2 Dec 2008 11:17:38 -0500 Date: Tue, 2 Dec 2008 11:17:38 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Markku-Juhani O. Saarinen" To: Multiple recipients of list Subject: Re: initial comments on the FSB SHA-3 proposal X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed MIME-Version: 1.0 References: <49354905.8020103@larc.usp.br> In-Reply-To: <49354905.8020103@larc.usp.br> X-To: Multiple recipients of list X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 02 Dec 2008 08:19:41 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 254 On Tue, 2 Dec 2008, Paulo S. L. M. Barreto wrote: >> [1] M.-J. O. Saarinen, "Linearization Attacks Against Syndrome Based >> Hashes." In K. Srinathan, C. Pandu Rangan, M. Yung (Eds.): Indocrypt >> 2007, LNCS 4859, Springer-Verlag 2007. pp. 1-9. >> >> [2] D. Augot et al, "Fast Syndrome-Based hash function SHA-3 Proposal" >> http://www-rocq.inria.fr/secret/CBCrypto/index.php?pg=fsb > security issues now), Finiasz claims your criticism on security is unfounded in > section 5.3 of his recent work "Syndrome Based Collision Resistant Hashing," > presented at PQCrypto'2008 > . > > Does that address your security concerns? This is perhaps just a stupid priority issue.. but it would have been nice of Finiasz to include my IndoCrypt 2007 paper in the references. I was the first (and only?) person to write about linearization attacks on FSB. Cheers, - markku // Markku-Juhani O. Saarinen http://www.m-js.com From hash-forum@nist.gov Tue Dec 2 09:18:30 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB2HIO5a021125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Dec 2008 09:18:25 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB2HHDfp002111; Tue, 2 Dec 2008 12:17:17 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB2HGOS4025766; Tue, 2 Dec 2008 12:16:24 -0500 Date: Tue, 2 Dec 2008 12:16:24 -0500 Message-Id: <49356CA2.2060306@inria.fr> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Nicolas Sendrier To: Multiple recipients of list Subject: Re: initial comments on the FSB SHA-3 proposal X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: References: <49354905.8020103@larc.usp.br> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 02 Dec 2008 09:18:25 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 255 Hi, The matter certainly has to be examined in details, but maybe there is a small confusion here. The parameters in Markku's Indocrypt paper appendix are r=w=1024. For 128 bits resistance against collision search we now propose r=1024 and w=128. More generally, we use w=r/8 errors with a state of size r between 640 and 1984 (see Table 2 page 4). Thanks to Markku's work we know that * for w >= r the system is not preimage resistant * for w >= r/2 the system is not collision resistant In both case there is polynomial time attack by inverting an (r x r) binary matrix For lower values of w (more or less in the range r/2 <= w <= r for preimage and r/4 <= w <= r/2 for collision) the linearization attack still poses a significant threat (more efficient than, or at least competitive with, information set decoding and generalized birthday attack). For even lower values of w (recall we use w=r/8), information set decoding and generalized birthday attack are better. As we say in A.3, page 17, "linearization attack is devastating" for large w (you see Markku we've read your paper). We simply make sure in "SHA-3 FSB" that w is small enough (which costs us a lot in terms of efficiency, by the way). Cheers, and be nice, Nicolas Markku-Juhani O. Saarinen wrote: > > > On Tue, 2 Dec 2008, Paulo S. L. M. Barreto wrote: > >> There seem to be two main points to your criticism: (1) efficiency, >> and (2) >> security. Your point on efficiency sounds fair enough albeit a bit harsh > > I agree, it is difficult to beat SHA-1 and MD5 speed with "provable > security" type of hash functions. > >> security issues now), Finiasz claims your criticism on security is >> unfounded in section 5.3 of his recent work "Syndrome Based Collision >> Resistant Hashing," presented at PQCrypto'2008 > . > >> >> Does that address your security concerns? > > Not fully, I will have to have concrete proof (i.e. collisions) before I > can claim that. Let me just say that the appendix of my IndoCrypt 2007 > paper contains actual collisions on then-current choice of FSB securty > parameters with claimed 2^128 security. > > Cheers, > - markku > > // Markku-Juhani O. Saarinen http://www.m-js.com > From hash-forum@nist.gov Wed Dec 3 02:14:12 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB3AE6BL001592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Dec 2008 02:14:07 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB3AD8DY010842; Wed, 3 Dec 2008 05:13:10 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB3ABf1X007822; Wed, 3 Dec 2008 05:11:41 -0500 Date: Wed, 3 Dec 2008 05:11:41 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Ivica Nikolic" To: Multiple recipients of list Subject: Re: Second preimage attack on MeshHash X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <49352010.6040507@win.dtu.dk> <20081202135200.67375.qmail@cr.yp.to> Content-Type: multipart/alternative; boundary="----=_Part_909_31873156.1228298940939" MIME-Version: 1.0 In-Reply-To: <20081202135200.67375.qmail@cr.yp.to> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 03 Dec 2008 02:14:08 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 256 ------=_Part_909_31873156.1228298940939 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I would like to propose you two improvements for the attack. First, you can easily fix the value of pipe[0] with the input word in both directions (forward and backward), hence reduce the attack space from 320 bits to 256 bits (for 256-bit digest). Second, you can launch the memoryless version of meet-in-the-middle attack (basically what Dan said). Let f(x) is the forward function for MITM and g(x) is the backward function (the one for which you pay 2^{64}). Then the switching function h(x) in the MITM attack can be defined as H(x)={ f(x), if r(x)=1 g(x), if r(x)=0 where r(x) is some pseudo random function. For this particular case, since g(x) costs 2^{64}, define r(x) =(trunk_64(x)>0). Then, since the MITM space is 256 bits, the cycle (the collision) will be found after approximately 2^{128} computations of H(x). In term of cost this means, around 2^{128} evaluations of f(x) and 2^{64} evaluations of g(x), hence the total cost is around 2^{128}. But, the probability that a collision is found between f(x) and g(x) is around 2^{-64} (because r(x) evaluates f(x) much more than g(x)). But, if you repeat the collision search 2^{64} times, you can expect to find collisions between f(x) and g(x) with high probability. For this you will pay in total 2^{64}*2^{128}=2^{192}. Hence, the preimage attack on MeshHash-256 requires 2^{192} computations and negligible memory. Best regards, Ivica Nikolic Laboratory of Algorithms, Cryptography and Security, University of Luxembourg ------=_Part_909_31873156.1228298940939 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

I would like to propose you two improvements for the attack.

First, you can easily fix the value of pipe[0] with the input word in both directions (forward and backward), hence reduce the attack space from 320 bits to 256 bits (for 256-bit digest).

Second, you can launch the memoryless version of meet-in-the-middle attack (basically what Dan said).  Let f(x) is the forward function for MITM and g(x) is the backward function (the one for which you pay 2^{64}). Then the switching function h(x) in the MITM attack can be defined as

                         H(x)={   f(x), if r(x)=1

                                    g(x), if r(x)=0

where r(x) is some pseudo random function. For this particular case, since g(x) costs 2^{64}, define r(x) =(trunk_64(x)>0). Then, since the MITM space is 256 bits, the cycle (the collision) will be found after approximately 2^{128} computations of H(x). In term of cost this means, around 2^{128} evaluations of f(x) and 2^{64} evaluations of g(x), hence the total cost is around 2^{128}. But, the probability that  a collision is found  between f(x) and g(x) is around 2^{-64} (because  r(x) evaluates f(x) much more than g(x)). But, if you repeat the collision search 2^{64} times, you can expect to find collisions between f(x) and g(x) with high probability. For this you will pay in total 2^{64}*2^{128}=2^{192}.

Hence, the preimage attack on MeshHash-256 requires 2^{192} computations and negligible memory. 


Best regards,
Ivica Nikolic
Laboratory of Algorithms, Cryptography and Security,
University of Luxembourg
------=_Part_909_31873156.1228298940939-- From hash-forum@nist.gov Wed Dec 3 04:43:26 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB3ChLs6016344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Dec 2008 04:43:22 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB3CfwpX003441; Wed, 3 Dec 2008 07:42:02 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB3Cefr0001699; Wed, 3 Dec 2008 07:40:41 -0500 Date: Wed, 3 Dec 2008 07:40:41 -0500 Message-Id: <49367BAE.7000507@iaik.tugraz.at> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Mario Lamberger (IAIK)" To: Multiple recipients of list Subject: Re: Cryptanalysis of DCH X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080401000203080109000508" In-Reply-To: <492F0EAA.6000302@mit.edu> References: <492E81FF.5080300@iaik.tugraz.at> <492F0EAA.6000302@mit.edu> MIME-Version: 1.0 X-CC: dwilson@MIT.EDU X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 03 Dec 2008 04:43:22 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 257 This is a cryptographically signed message in MIME format. --------------ms080401000203080109000508 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Hi David, hi all, your remark was of course right. Nevertheless our claims still hold. a fixed version of our attack can be found at http://ehash.iaik.tugraz.at/uploads/9/9b/Dch.pdf Regards, Mario David Wilson wrote: > > Hi Florian, > > From an initial read, it looks like this analysis ignores the > additional dithering input. When the counter resets, it advances > another (non-counter-based) dither input (sec. 1.2 of the DCH > specification). Thus, the assertion that "$\gamma_i = \gamma_j$ for > $i \equiv j$ (mod 32)" is incorrect. The attacks that follow rely > heavily on this assertion. > > Please let me know if I have misinterpreted your attack and feel free > to follow up with me off-list. > > Regards, > David > > P.S. I do freely admit that the attack of Khovratovich and Nikolic is > a legitimate and full break; while the error in DCH is fairly > straightforward and likely patchable, fixing it would involve a change > to the algorithm that would exceed the bounds of the SHA-3 entry > specification. > > Florian Mendel wrote: >> Hi all, >> >> We have found a practical collision and preimage attack on DCH-n. The >> attack is based on the observation of Khovratovich and Nikolic that the >> chaining value is not used in the underlying block cipher. The attack >> is described in: http://ehash.iaik.tugraz.at/uploads/9/9b/Dch.pdf >> >> best regards, >> >> Florian Mendel >> > > -- Dr. Mario Lamberger IAIK - Institute for Applied Information Processing and Communications Inffeldgasse 16a, 8010 Graz, AUSTRIA - room nr. F3.14 phone: +43 (0) 316 873 5531 mail: mario.lamberger@iaik.tugraz.at web: http://www.iaik.tugraz.at/lamberger --------------ms080401000203080109000508 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIbBDCC BLMwggOboAMCAQICARYwDQYJKoZIhvcNAQEFBQAwQTEQMA4GA1UEChMHRXVyb1BLSTEtMCsG A1UEAxMkRXVyb1BLSSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTIyODA5 NTA1MloXDTEwMTIzMTExNTkwMFowUjELMAkGA1UEBhMCQVQxEDAOBgNVBAoTB0V1cm9QS0kx MTAvBgNVBAMTKEV1cm9QS0kgQXVzdHJpYW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1hZUNUa0lyv5ttAn7ZRyfI4zO+Bc2fmTi lpAIBfJ/2yqfdHKCd/r2czeCme85S298uhCrDtKZXQp6wZpxGsZrZw5n8mrXVVy6HUTFTyKa pz/4W3vS0f3fKljpUioJ9lBUwQyARDcNzCP63+Iv9OqrHgb4QoSfmDlrX5KmaGDaEgoNYbkY wFDn0b81I16j8mXDDECtQM/ZsxzjkHZz1ks3jl/q9EW1OxdD6ytgsePXzfmfWjdwsB8KyjXI UNpLMBzPK3qTjwevGUQjfCCJ1hC26t2G9BWPcHUUw0/4gCL/jGDLUAmMWo1z1H/gyk9VrTsU uP3HZ7fElMpfqmIqyr69AgMBAAGjggGjMIIBnzBMBglghkgBhvhCAQ0EPxY9SXNzdWVkIHVu ZGVyIHBvbGljeToKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzBk BggrBgEFBQcBAQRYMFYwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwLmV1cm9wa2kub3JnOjgw MjYwKgYIKwYBBQUHMAKGHmh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdDA7BgNVHR8E NDAyMDCgLqAshipodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3JsL2NybC5kZXIw TgYDVR0gBEcwRTBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93d3cuZXVy b3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzAdBgNVHQ4EFgQUdCnYUa/CPJin1/8xj0D3UOgH AegwHwYDVR0jBBgwFoAUjNyLsaVKkOdOiHMYPJ3VXn7kss0wDAYDVR0TBAUwAwEB/zAOBgNV HQ8BAf8EBAMCAfYwDQYJKoZIhvcNAQEFBQADggEBALvbHv34QJkgCzJ92trxCWkGmeahGFQ8 ZQCFlgeaAI5d2B8K9XVJ7IduoETxq+evWfDaiUBHahQ6c2oC9uhuqI4pzJpsEJimYpccHRBA 85S5spyfLfpboY1lSGraFxZwTsV9+wGftlCOZy3UF9Ip0VLP1wrRsTvfCBjLybj45ay3L3o5 F+MojQ2VPC0w/z56yD9caU+fl2pJSU7Q5fUlUfYD0PexVzDEWX4r3lGn6G5UD/zC8zNqH7fh sJxsH/TeraHbvUk8AZu4IULWzrpytR7JpOX/VRfeF65foy7GoTkBuGPx9EsbXJzZ/ygab947 O5yIAqr6bibMh7i1ZDcpnacwggU3MIIEH6ADAgECAgcCQt/N+2FTMA0GCSqGSIb3DQEBBQUA MFIxCzAJBgNVBAYTAkFUMRAwDgYDVQQKEwdFdXJvUEtJMTEwLwYDVQQDEyhFdXJvUEtJIEF1 c3RyaWFuIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA4MDIyODE1MTgwNVoXDTEzMDIy ODE1MTgwNVowgb0xLTArBgNVBAMTJEV1cm9QS0kgSUFJSyBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEmMCQGA1UEChMdR3JheiBVbml2ZXJzaXR5IG9mIFRlY2hub2xvZ3kxSDBGBgNVBAsT P0luc3RpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21t dW5pY2F0aW9uczENMAsGA1UEBxMER3JhejELMAkGA1UEBhMCQVQwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCVatVA1TczvPSG2IZoIPtEBXNgZSdUx58syuOEoZs9HOc0MocB 2ko3jIDfB9YIP7bLEag1yjrlO8GxfkBCiTQvnfNDEIMvetuwJmHSgaTxJ3PRlOWDJMi/IbNe X1yq2sOYyszpbK5/jm6JAl/XbYNmNuiPxx2PR3iVZBL4v38sF7o0x/ale5P7RmW4KXq36Mpc /KaAW4cMrDUAGNqcc9EIwkTAx1moGt8u7v/CTgWIilXbhB1BBBjp+Cy9ukBX+HnwimWlAcKF DTqmwFmgJA+QlCEQYHs0o2ylWF+41N8MivLlYqvqQlpOFqWStBpKr8lxkcjpFRzFry2ORWlK 16+bAgMBAAGjggGkMIIBoDAOBgNVHQ8BAf8EBAMCAcYwDwYDVR0TAQH/BAUwAwEB/zAdBgNV HQ4EFgQUOXTH3cjx+wpwPQ7KfUUCrKGb154wVgYDVR0gBE8wTTBLBgwrBgEEAZUSAQIBAQEw OzA5BggrBgEFBQcCARYtaHR0cDovL2V1cm9wa2kuaWFpay5hdC9jYS9ldXJvcGtpLWF0L2Nw cy8xLjEvMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jYS5pYWlrLnR1Z3Jhei5hdC9jYXBz by9jcmxzL0V1cm9QS0lBdXN0cmlhbi5jcmwwgZoGCCsGAQUFBwEBBIGNMIGKMEIGCCsGAQUF BzABhjZodHRwOi8vY2EuaWFpay50dWdyYXouYXQvY2Fwc28vT0NTUD9jYT1FdXJvUEtJQXVz dHJpYW4wRAYIKwYBBQUHMAKGOGh0dHA6Ly9jYS5pYWlrLnR1Z3Jhei5hdC9jYXBzby9jZXJ0 cy9FdXJvUEtJQXVzdHJpYW4uY2VyMB8GA1UdIwQYMBaAFHQp2FGvwjyYp9f/MY9A91DoBwHo MA0GCSqGSIb3DQEBBQUAA4IBAQCmsYc+Rdrfd3sV8jqDipRkd/BGEwGFiWydTmEMRimyr2Sm qNVX4khjAEyLcVjyYK+Fc+XREwOttYcKQHFKaRZRDby0RvniwP3LX1Du3xXnEHij9oB6A2aE Tg1ouAnCikXQQ4C3eBfM9vaK9VR0k/akaqKzTTPBl8ao7TmOfTTdIBrVSoPYjeXR/qm1A34n Pb0gR5sBMEZEcZgDN2oKSDsrK2bHp7AG36R/AtnGyW4j1hI5hR35VCmAToz4dbUKhZjDFJU+ FgmANAWh0+AetShQ7qpS6IyHXxdDGYW/7SHbwWsi4pmRnRm/xaYLVCo3zRJDwaXq3JlKOh2V if4IFzAgMIIFgDCCBGigAwIBAgIHA0DrJxk2fDANBgkqhkiG9w0BAQUFADCBvTEtMCsGA1UE AxMkRXVyb1BLSSBJQUlLIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSYwJAYDVQQKEx1HcmF6 IFVuaXZlcnNpdHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/SW5zdGl0dXRlIGZvciBBcHBs aWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMQ0wCwYDVQQH EwRHcmF6MQswCQYDVQQGEwJBVDAeFw0wODAyMjgxNTQ0MTdaFw0xMzAyMjgxNTQ0MTdaMIGs MRwwGgYDVQQDExNFdXJvUEtJIElBSUsgU2lnIENBMSYwJAYDVQQKEx1HcmF6IFVuaXZlcnNp dHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/SW5zdGl0dXRlIGZvciBBcHBsaWVkIEluZm9y bWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMQ0wCwYDVQQHEwRHcmF6MQsw CQYDVQQGEwJBVDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALBs2U2/lTXnomXh gNULWkAXS507A6UtmsbrAIXXK7XIWgyjbKiYASrdej0LPKGuFtxbZ+A/e1cSV8yrCWsB+4s8 jZwL+xbWeXIGcaKarv0npeXSqX0UZl7DM5mVID+FwG1T73qjmIGvE6i5qDnNEv0siGeit7m0 AH3dF2uckq6eKuozAvchlJOQk27PqaPRFCS5APiCNBrB9AUShjXMHso1wC1raxlsGDc/yneC 2Z4OOBZLkswPIMu0qUwVfGVR7u3WFLEP3cPXw8lWb1Ka8GzGLBivt4PRz+wyibDfWx/i/Snh TzfEuB4y1PFjvsFQ3o3am2zHpqvy1WPfUsxRLQ0CAwEAAaOCAZIwggGOMA4GA1UdDwEB/wQE AwIBxjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSu7lUGF3pTERMYq6TOHHEJGoMU8zBQ BgNVHSAESTBHMEUGDCsGAQQBlRIBAgMBATA1MDMGCCsGAQUFBwIBFidodHRwOi8vZXVyb3Br aS5pYWlrLmF0L2NhL2lhaWsvY3BzLzEuMy8wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2Nh LmlhaWsudHVncmF6LmF0L2NhcHNvL2NybHMvRXVyb1BLSUlBSUsuY3JsMIGSBggrBgEFBQcB AQSBhTCBgjA+BggrBgEFBQcwAYYyaHR0cDovL2NhLmlhaWsudHVncmF6LmF0L2NhcHNvL09D U1A/Y2E9RXVyb1BLSUlBSUswQAYIKwYBBQUHMAKGNGh0dHA6Ly9jYS5pYWlrLnR1Z3Jhei5h dC9jYXBzby9jZXJ0cy9FdXJvUEtJSUFJSy5jZXIwHwYDVR0jBBgwFoAUOXTH3cjx+wpwPQ7K fUUCrKGb154wDQYJKoZIhvcNAQEFBQADggEBAAgys3wJ2CixcC8KuuO3a9k8u0nT0+PafLR9 wMQMWsz7xDTLNxiTJKnLvdFw86D+CH+nXxRweo/KDVYT56q5rfKs45I6mZDV+z/wecNX3odW MuY5a6j0g/RR4Qz/wokfeUzff5Yi6Hh1P9ce0u3/EHAHancJI3FxoZpLU5qNWZNo+fI6nluO BmdJCWZgCR9ijucmFubnu4EbWlyhiH2e0H2taU6zWvW/83yqbEO0BhDKVWWVtWvlF/ptBZQE JzAD1q5XJobPNQ/IANfs5ZcfuC1+Pm6FEG0cMVnDCGlRoA57oTIFaODWQPr4gxMy11/MYe9V ufBih5AU1z6V4IwJ5SYwggXDMIIEq6ADAgECAgcCt7JxAZECMA0GCSqGSIb3DQEBBQUAMIGs MRwwGgYDVQQDExNFdXJvUEtJIElBSUsgRW5jIENBMSYwJAYDVQQKEx1HcmF6IFVuaXZlcnNp dHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/SW5zdGl0dXRlIGZvciBBcHBsaWVkIEluZm9y bWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMQ0wCwYDVQQHEwRHcmF6MQsw CQYDVQQGEwJBVDAeFw0wODEwMDkxMzE1MTFaFw0xMTEwMDkxMzE1MTFaMIHMMQ4wDAYDVQQq EwVNYXJpbzESMBAGA1UEBBMJTGFtYmVyZ2VyMRgwFgYDVQQDEw9NYXJpbyBMYW1iZXJnZXIx JjAkBgNVBAoTHUdyYXogVW5pdmVyc2l0eSBvZiBUZWNobm9sb2d5MUgwRgYDVQQLEz9JbnN0 aXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNh dGlvbnMxDTALBgNVBAcTBEdyYXoxCzAJBgNVBAYTAkFUMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsAEYp6QK5iuCN25DG85wAaSB6JIlss/1V38dELOWmH4c1pvvWT6skfIf I3cCWOFn0mk8PmLTh3ZA2U4LOFZ18ys9Z+EdLQNyvYjUlG35x+C4rqzPGAjOw9RkUsgT4Jms m76mnZiElpDueESmlEtPBzLsVCAR9mIsIj9rr3jfJCUBTNAb4IueFQ0quIMtOt8GPMag/PJz sYAY84iNIIeknZfViEcnqKCBGQQqet/mtjKrSBW+4bNLLPoMQT6Touz4QyPcgUTiLpzQmEob 6akPlC5rTk8z0PXD5AOCdDDpDE++a4Q7P0CsK0JPp9L6X3mP2HD4QKZbzokgjt1wg90aUwID AQABo4IBxjCCAcIwDgYDVR0PAQH/BAQDAgQwMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFAMh FVlX/xzQijlPKqkaezIcsYpwMFAGA1UdIARJMEcwRQYMKwYBBAGVEgECAwEBMDUwMwYIKwYB BQUHAgEWJ2h0dHA6Ly9ldXJvcGtpLmlhaWsuYXQvY2EvaWFpay9jcHMvMS4zLzBIBgNVHR8E QTA/MD2gO6A5hjdodHRwOi8vY2EuaWFpay50dWdyYXouYXQvY2Fwc28vY3Jscy9FdXJvUEtJ SUFJS19FbmMuY3JsMIGaBggrBgEFBQcBAQSBjTCBijBCBggrBgEFBQcwAYY2aHR0cDovL2Nh LmlhaWsudHVncmF6LmF0L2NhcHNvL09DU1A/Y2E9RXVyb1BLSUlBSUtfRW5jMEQGCCsGAQUF BzAChjhodHRwOi8vY2EuaWFpay50dWdyYXouYXQvY2Fwc28vY2VydHMvRXVyb1BLSUlBSUtf RW5jLmNlcjApBgNVHREEIjAggR5tYXJpby5sYW1iZXJnZXJAaWFpay50dWdyYXouYXQwHwYD VR0jBBgwFoAU3UP298kNEZZgTQSlVkIYEiSm2uowDQYJKoZIhvcNAQEFBQADggEBAHS4U++C +a8Npppu6pMGrmKaxzFvajn27K4SMCox2qg4esMFdlUe2zw/xfsogMROxcV36AMvbEwv5xtQ JxbKVytMU3sgTUYw091jhu4U727MPW1ewBQIKtFKadLLfdGDq2QbMbgjnjgAGdbMASJCpnhD 98Wz6T5JKvhbPx+cLJKwBnrOpiOnmp9c8RxzibhzuW5TmnhmZv98T0hlrfi+dip27Bs3MmTp hEM5F6Q8mM/tnHxaHXKXjloEBn5BHmIAySpqMjNO5flm8EAqZSSyJsJ31JBL4Qb0K9CC3ukE q4pR6Wt6ktoM7e1xHXMXFOWhfQRdGsQVYaMPN339OO29jU8wggXDMIIEq6ADAgECAgcD52Dp ra4YMA0GCSqGSIb3DQEBBQUAMIGsMRwwGgYDVQQDExNFdXJvUEtJIElBSUsgU2lnIENBMSYw JAYDVQQKEx1HcmF6IFVuaXZlcnNpdHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/SW5zdGl0 dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRp b25zMQ0wCwYDVQQHEwRHcmF6MQswCQYDVQQGEwJBVDAeFw0wODEwMDkxMzE4MTdaFw0xMTEw MDkxMzE4MTdaMIHMMQ4wDAYDVQQqEwVNYXJpbzESMBAGA1UEBBMJTGFtYmVyZ2VyMRgwFgYD VQQDEw9NYXJpbyBMYW1iZXJnZXIxJjAkBgNVBAoTHUdyYXogVW5pdmVyc2l0eSBvZiBUZWNo bm9sb2d5MUgwRgYDVQQLEz9JbnN0aXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJv Y2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxDTALBgNVBAcTBEdyYXoxCzAJBgNVBAYTAkFU MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArXp61ZReU1zzY54H1WekQXkAJHDj k8a2U5/mjG9SJPdTn1PI8rGTPwVS4F+Hwct19q4alUysZzKRBGOQW7Nn7VNi3tEez5S06LsG w+C+HA53LC2ND8f08KJspTTssCN1OAB+GEAxX9N6zym8X28CLlDXCKPNSSfOLNOgS1E5RyZz Dgnk+lu/M+gVzksLf0lHh+LY0HSxwaXepvZ6IJ3rs2tP3LAiMtnbgUW6QyOzh4w3wTjcYrT3 zQ4nXB09907RHHqWhFXjVBUPi2wbuyLy1z/aAmFOmibqYbNDhEJpgaI8L8tyzSWuNSpBCooi dPgh8R3GnnpmVtu98KLjLORx2wIDAQABo4IBxjCCAcIwDgYDVR0PAQH/BAQDAgbAMAwGA1Ud EwEB/wQCMAAwHQYDVR0OBBYEFP+XIGf36p7zoW93Fkzs75shJPYKMFAGA1UdIARJMEcwRQYM KwYBBAGVEgECAwEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly9ldXJvcGtpLmlhaWsuYXQvY2Ev aWFpay9jcHMvMS4zLzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY2EuaWFpay50dWdyYXou YXQvY2Fwc28vY3Jscy9FdXJvUEtJSUFJS19TaWcuY3JsMIGaBggrBgEFBQcBAQSBjTCBijBC BggrBgEFBQcwAYY2aHR0cDovL2NhLmlhaWsudHVncmF6LmF0L2NhcHNvL09DU1A/Y2E9RXVy b1BLSUlBSUtfU2lnMEQGCCsGAQUFBzAChjhodHRwOi8vY2EuaWFpay50dWdyYXouYXQvY2Fw c28vY2VydHMvRXVyb1BLSUlBSUtfU2lnLmNlcjApBgNVHREEIjAggR5tYXJpby5sYW1iZXJn ZXJAaWFpay50dWdyYXouYXQwHwYDVR0jBBgwFoAUru5VBhd6UxETGKukzhxxCRqDFPMwDQYJ KoZIhvcNAQEFBQADggEBAIcejurfNYvKKaMp7POp7lic7pIiGdmk4xpnjjyhJxn+9A48yW+n PTlqhdwGtYiWovcUWGC03tEe25eA6PoaQajE/lmU2N8108aOg7u7tfV1iaXnbsIpnvZD9XJB LWOSzEg1vH34iQNR4YyX+sRY8SSHCO1/pmG8At1PT14iCsHSwvdy2/49/VvPKWP7A5RkpEcl 44b5AgiEkSBqHqVr4aAUG564QfRHHFuDhEITUwCWtam3nh7VSapIjmX2NBhSVpTTOqUaZQ/L aJ9PZQ7a9FGdJVdtz2p1/C2i/1ihj2w9kzWJ6be3pH2L7Tkba4mMAGHEPL2HLO/Em8F0akIV aVsxggQvMIIEKwIBATCBuDCBrDEcMBoGA1UEAxMTRXVyb1BLSSBJQUlLIFNpZyBDQTEmMCQG A1UEChMdR3JheiBVbml2ZXJzaXR5IG9mIFRlY2hub2xvZ3kxSDBGBgNVBAsTP0luc3RpdHV0 ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9u czENMAsGA1UEBxMER3JhejELMAkGA1UEBhMCQVQCBwPnYOmtrhgwCQYFKw4DAhoFAKCCAksw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgxMjAzMTIyOTM0 WjAjBgkqhkiG9w0BCQQxFgQUpxaykmDMl7pwqIWYkqODXVzHjcQwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwgckGCSsGAQQBgjcQBDGBuzCBuDCBrDEcMBoGA1UEAxMTRXVyb1BL SSBJQUlLIEVuYyBDQTEmMCQGA1UEChMdR3JheiBVbml2ZXJzaXR5IG9mIFRlY2hub2xvZ3kx SDBGBgNVBAsTP0luc3RpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5n IGFuZCBDb21tdW5pY2F0aW9uczENMAsGA1UEBxMER3JhejELMAkGA1UEBhMCQVQCBwK3snEB kQIwgcsGCyqGSIb3DQEJEAILMYG7oIG4MIGsMRwwGgYDVQQDExNFdXJvUEtJIElBSUsgRW5j IENBMSYwJAYDVQQKEx1HcmF6IFVuaXZlcnNpdHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/ SW5zdGl0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11 bmljYXRpb25zMQ0wCwYDVQQHEwRHcmF6MQswCQYDVQQGEwJBVAIHAreycQGRAjANBgkqhkiG 9w0BAQEFAASCAQAunNswHgNj9u0D1cQP0+8eusPAQmDAfRF5AuRYbcdDnkHwUb2gRUIZYlAU 4AEwSO4xM0VJmvo1T1zILdU/kLobm6le+2GSSOYoKlFn6W0lku2yUg3aKfxYglY7lbr7vfQB hdNFLyKLuT5km8e1SW2DUK4tQ5S0a0/LYScvX6X89YtUPYpTSr+W8SmwueppgDs2gN1beFZb Dn1vYXj/2Hv4RALD5OJbTZeFr+CT+T8bAfsQSDM6d+73aUBznmAjFN0g/a3nkgyD9O368nWR rGKNhxNlVbYBkpiezesIV4bSRhAkmY99JSoUcM7kGdc50gB5Rxtb9A1XkmO6bEZkkp/tAAAA AAAA --------------ms080401000203080109000508-- From hash-forum@nist.gov Wed Dec 3 05:10:38 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB3DAWOQ019497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Dec 2008 05:10:33 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB3D9AOt001253; Wed, 3 Dec 2008 08:09:15 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB3D8i5e030833; Wed, 3 Dec 2008 08:08:44 -0500 Date: Wed, 3 Dec 2008 08:08:44 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Ivica Nikolic" To: Multiple recipients of list Subject: Free-start attacks on Nash X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/alternative; boundary="----=_Part_3244_27384187.1228309071558" MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 03 Dec 2008 05:10:33 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 258 ------=_Part_3244_27384187.1228309071558 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, we found free-start attacks on NaSHA. The paper is available online: http://ehash.iaik.tugraz.at/uploads/3/33/Free-start_attacks_on_Nasha.pdf The free-start collision attack requires about 2^{32} computations for all digests. The free-start preimage attack requires about 2^{n/2} for NaSHA-n. Best regards, Ivica Nikolic and Dmitry Khovratovich Laboratory of Algorithms, Cryptography and Security, University of Luxembourg ------=_Part_3244_27384187.1228309071558 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

we found free-start attacks on NaSHA. The paper is available online:
The free-start collision attack requires about 2^{32} computations for all digests. 
The free-start preimage attack requires about 2^{n/2} for NaSHA-n. 

Best regards,
Ivica Nikolic and Dmitry Khovratovich
Laboratory of Algorithms, Cryptography and Security,
University of Luxembourg
------=_Part_3244_27384187.1228309071558-- From hash-forum@nist.gov Wed Dec 3 07:20:24 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB3FKIrl000792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Dec 2008 07:20:20 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB3FILRx023953; Wed, 3 Dec 2008 10:18:26 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB3FGkHv031467; Wed, 3 Dec 2008 10:16:46 -0500 Date: Wed, 3 Dec 2008 10:16:46 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Paul Hoffman To: Multiple recipients of list Subject: On "fixes" to attacks X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: text/plain; charset="us-ascii" X-To: hash-forum@nist.gov Mime-Version: 1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 03 Dec 2008 07:20:20 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 259 Greetings again. The messages whose content is basically "after my submission was successfully attacked, I could see that I should have used " are probably not all that useful. It seems likely that NIST will have many (possibly too many) good, non-attacked proposals for a first round of review by the cryptographic community. We would be better off concentrating on those remaining proposals rather than that group plus the repaired proposals. It seems like we are already going to have focus issues; why make them worse? --Paul Hoffman, Director --VPN Consortium From hash-forum@nist.gov Wed Dec 3 08:56:03 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB3Gtvog012493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Dec 2008 08:55:58 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB3Gsrc0023984; Wed, 3 Dec 2008 11:54:58 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB3GrpJx001795; Wed, 3 Dec 2008 11:53:51 -0500 Date: Wed, 3 Dec 2008 11:53:51 -0500 Message-Id: <7731938b0812030850h60283530y9f4a0efd3ec7fab3@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Peter Maxwell" To: Multiple recipients of list Subject: Re: On "fixes" to attacks X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 In-Reply-To: X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 03 Dec 2008 08:55:58 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 260 Hmmm, not exactly sure what you are getting at Paul, but I'll argue the point anyway... Imagine, if you will, that during the AES process Rijndael had been flawed in a major but easily fixable manner. In that artificial situation, and with the benefit of hindsight that we currently have, would you still of insisted on it being discarded? Do major software companies sell products that are absolutely correct first time out, of course not - there's always patches, and always a process of evolution. Even SHA-1 was released quickly after SHA-0 to correct a problem - should SHA-1 have been discarded at that point and the whole thing started from scratch... I'm guessing not because the basic design idea was subsequently used in the SHA-224/256/384/512 family. So why should the available options in this situation be prematurely narrowed? NIST hasn't even published the "complete and proper" submissions yet. Personally, I think the nature of any break/attack/fix would hold enough significance for the community at large to easily determine good candidate algorithms from poor ones without any loss of focus. It's probably an inconsequential argument anyway as I think NIST had said it was going to make an announcement on this issue in the near future (I may have misread a previous post). Out of interest, why do you think there's going to be a lack of focus? I certaintly haven't seen any indication of that so far. Best wishes, Peter 2008/12/3 Paul Hoffman : > > Greetings again. The messages whose content is basically "after my submission was successfully attacked, I could see that I should have used " are probably not all that useful. It seems likely that NIST will have many (possibly too many) good, non-attacked proposals for a first round of review by the cryptographic community. We would be better off concentrating on those remaining proposals rather than that group plus the repaired proposals. It seems like we are already going to have focus issues; why make them worse? > > --Paul Hoffman, Director > --VPN Consortium > > From hash-forum@nist.gov Wed Dec 3 09:37:44 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB3Hbd0g018194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Dec 2008 09:37:40 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB3HaQIl019953; Wed, 3 Dec 2008 12:36:31 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB3Ha2Zx022885; Wed, 3 Dec 2008 12:36:02 -0500 Date: Wed, 3 Dec 2008 12:36:02 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Paul Hoffman To: Multiple recipients of list Subject: Re: On "fixes" to attacks X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: text/plain; charset="us-ascii" X-To: hash-forum@nist.gov References: <7731938b0812030850h60283530y9f4a0efd3ec7fab3@mail.gmail.com> In-Reply-To: <7731938b0812030850h60283530y9f4a0efd3ec7fab3@mail.gmail.com> Mime-Version: 1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 03 Dec 2008 09:37:40 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 261 At 11:53 AM -0500 12/3/08, Peter Maxwell wrote: >Imagine, if you will, that during the AES process Rijndael had been >flawed in a major but easily fixable manner. In that artificial >situation, and with the benefit of hindsight that we currently have, >would you still of insisted on it being discarded? Yes. There were other good candidates at the time. For the SHA3 competition, we will probably have many more good first-round candidates. >Do major software companies sell products that are absolutely correct >first time out, of course not - there's always patches, and always a >process of evolution. ..which is, of course, painful for buyers. > Even SHA-1 was released quickly after SHA-0 to >correct a problem - should SHA-1 have been discarded at that point and >the whole thing started from scratch... Bad straw-man, given that there was no competition involved. If you want to create a different method of determining the best possible hash function for everyone to use, that's fine. However, this list is about the NIST hash competition. >So why should the available options in this situation be prematurely >narrowed? It shouldn't. OTOH, you shouldn't have used the word "prematurely" in the sentence. Are you saying that NIST should *never* narrow the candidates if the original proposers can come up with fixes after attacks? If not, where do you set the end date for fixes, and why should we use your end date instead of NIST's? >NIST hasn't even published the "complete and proper" >submissions yet. Geez, it has only been a month. What is the rush? We're talking about a government bureaucracy with a zillion other things it is supposed to do at the same time. >Personally, I think the nature of any >break/attack/fix would hold enough significance for the community at >large to easily determine good candidate algorithms from poor ones >without any loss of focus. I'm not a cryptographer (but I sometimes play one in the press), but I can do simple math. Having 50 proposals (that include broken-but-fixed ones) will have about 25% less focus than having 40 proposals. >Out of interest, why do you think there's going to be a lack of focus? See my math above. --Paul Hoffman, Director --VPN Consortium From hash-forum@nist.gov Wed Dec 3 10:19:24 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB3IJJo7023522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Dec 2008 10:19:20 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB3IIPvR004336; Wed, 3 Dec 2008 13:18:31 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB3IHEAK009534; Wed, 3 Dec 2008 13:17:14 -0500 Date: Wed, 3 Dec 2008 13:17:14 -0500 Message-Id: <4936CA19.30503@larc.usp.br> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Paulo S. L. M. Barreto" To: Multiple recipients of list Subject: Re: On "fixes" to attacks X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 In-Reply-To: References: <7731938b0812030850h60283530y9f4a0efd3ec7fab3@mail.gmail.com> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 262 Paul Hoffman wrote: > At 11:53 AM -0500 12/3/08, Peter Maxwell wrote: >> Imagine, if you will, that during the AES process Rijndael had been >> flawed in a major but easily fixable manner. In that artificial >> situation, and with the benefit of hindsight that we currently have, >> would you still of insisted on it being discarded? > > Yes. There were other good candidates at the time. For the SHA3 competition, we will probably have many more good first-round candidates. Besides, keep in mind that this scenario is, as you point out, artificial -- one of the reasons Rijndael made it to the second round and then became the AES is that it was *not* flawed. Perhaps a better analogy would be with any of the AES candidates that did not make it to the second round, say, DFC, LOKI97 or MAGENTA (see e.g. DOI:10.1007/b72329)? Paulo. From hash-forum@nist.gov Wed Dec 3 11:14:26 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB3JELEB030275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Dec 2008 11:14:22 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB3JD64P029010; Wed, 3 Dec 2008 14:13:12 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB3JCTtf024980; Wed, 3 Dec 2008 14:12:29 -0500 Date: Wed, 3 Dec 2008 14:12:29 -0500 Message-Id: <898039814.7559221228330720548.JavaMail.root@mail3.gatech.edu> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: David Bauer To: Multiple recipients of list Subject: Re: On "fixes" to attacks X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Zimbra 5.0.10_GA_2638.RHEL5_64 (zclient/5.0.10_GA_2638.RHEL5_64) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 In-Reply-To: <4936CA19.30503@larc.usp.br> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 03 Dec 2008 11:14:22 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 263 > Perhaps a better analogy would be with any of the AES candidates that did not > make it to the second round, say, DFC, LOKI97 or MAGENTA (see e.g. > DOI:10.1007/b72329)? As an alternative, consider looking at those that did make it to the second round. Per Gladman's analysis [1], the five finalist were the four fastest ciphers plus Serpent. Serpent was widely regarded as having an extremely large safety margin, making it a somewhat special case. Biham argued [2] that Serpent was actually the fastest algorithm based on using the mimimum number of secure rounds for each cipher. (Being an author of Serpent, Biham's analysis can be assumed to be somewhat biased, of course.) Per Biham's analysis, the five finalist were the four fastest ciphers (at a normalized security level), plus RC6 (the fastest by far according to original specifications). Thus, the five finalists were the five fastest ciphers. Therefore, I can argue by comparison with the AES candidates that fixed versions of Edon-R, Enrupt, etc should be chosen ahead of significantly slower, but unmodified entries. David Bauer [1] http://jya.com/bg/gladman.pdf [2] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.42.6516 From hash-forum@nist.gov Wed Dec 3 11:43:28 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB3JhMxZ001354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Dec 2008 11:43:24 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB3JgIfA025258; Wed, 3 Dec 2008 14:42:24 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB3JfQS1018238; Wed, 3 Dec 2008 14:41:26 -0500 Date: Wed, 3 Dec 2008 14:41:26 -0500 Message-Id: <4936E0B9.6010100@larc.usp.br> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Paulo S. L. M. Barreto" To: Multiple recipients of list Subject: Re: On "fixes" to attacks X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 In-Reply-To: <898039814.7559221228330720548.JavaMail.root@mail3.gatech.edu> References: <898039814.7559221228330720548.JavaMail.root@mail3.gatech.edu> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 03 Dec 2008 11:43:24 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 264 David Bauer wrote: >> Perhaps a better analogy would be with any of the AES candidates that did not >> make it to the second round, say, DFC, LOKI97 or MAGENTA (see e.g. >> DOI:10.1007/b72329)? > > As an alternative, consider looking at those that did make it to the second round. > Per Gladman's analysis [1], the five finalist were the four fastest ciphers plus Serpent. > Serpent was widely regarded as having an extremely large safety margin, making it a somewhat special case. > Biham argued [2] that Serpent was actually the fastest algorithm based on using the mimimum number of secure rounds for each cipher. (Being an author of Serpent, Biham's analysis can be assumed to be somewhat biased, of course.) > Per Biham's analysis, the five finalist were the four fastest ciphers (at a normalized security level), plus RC6 (the fastest by far according to original specifications). > > Thus, the five finalists were the five fastest ciphers. > Therefore, I can argue by comparison with the AES candidates that fixed versions of Edon-R, Enrupt, etc should be chosen ahead of significantly slower, but unmodified entries. That's an interesting sophism. Were we to follow it at face value, how about a "fixed version of MD4"? Paulo. From hash-forum@nist.gov Wed Dec 3 12:24:37 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB3KOWMM006360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Dec 2008 12:24:33 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB3KNdDD025015; Wed, 3 Dec 2008 15:23:44 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB3KMwtq004837; Wed, 3 Dec 2008 15:22:58 -0500 Date: Wed, 3 Dec 2008 15:22:58 -0500 Message-Id: <7731938b0812031214l11a53ac5g304a9d8271331ff0@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Peter Maxwell" To: Multiple recipients of list Subject: Re: On "fixes" to attacks X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <7731938b0812030850h60283530y9f4a0efd3ec7fab3@mail.gmail.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 In-Reply-To: X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 03 Dec 2008 12:24:33 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 265 2008/12/3 Paul Hoffman : > > At 11:53 AM -0500 12/3/08, Peter Maxwell wrote: >>Imagine, if you will, that during the AES process Rijndael had been >>flawed in a major but easily fixable manner. In that artificial >>situation, and with the benefit of hindsight that we currently have, >>would you still of insisted on it being discarded? > > Yes. There were other good candidates at the time. For the SHA3 competition, we will probably have many more good first-round candidates. Fair enough, I kinda walked into that one ;-) > >>Do major software companies sell products that are absolutely correct >>first time out, of course not - there's always patches, and always a >>process of evolution. > > ..which is, of course, painful for buyers. I totally agree, it is painful, but there is a tacit recognition that its going to happen; people aren't perfect and they make mistakes. A lot of the papers I've read in cryptography have small mistakes in places, whether that be simple spelling mistakes, notational ambiguities, or similar - we don't deride the authors for that, do we? .... ok, maybe a wee bit, but the person's work isn't completely discounted. There's a long time between now and when the next round choices need to be made, it doesn't have to be absolutely right first time - but it does have to get that way. Personally, I would have thought it would be a good idea to allow submitters to make modifications in light of new attacks, or even use ideas from other algorithms. The objective isn't to try and rate the submissions or submitters, its to find a good (and ideally the best available) algorithm. > >> Even SHA-1 was released quickly after SHA-0 to >>correct a problem - should SHA-1 have been discarded at that point and >>the whole thing started from scratch... > > Bad straw-man, given that there was no competition involved. > > If you want to create a different method of determining the best possible hash function for everyone to use, that's fine. However, this list is about the NIST hash competition. That's not the point I was making - if the NSA (I'm assuming from what I've read that this is where SHA-0 came from) who are meant to be quite good at this sort of stuff can realise it made a mistake in the design of SHA-0, and fix it with SHA-1, then there's a pretty good chance of other people/groups being falable too. It doesn't mean that SHA-1 was necessarily a bad algorithm (for that time at least) because its immediate predecessor had an error in it. Yes, it is a competition, but I would suggest that a very harsh application of "survival of the fitest" may not return an optimal result. It will give you a competition winning algorithm, not necessarily the best algorithm for purpose which are two entirely different requirements. I totally agree that if an algorithm is particularly poor, then there's no point in trying to tweak it, and its generally not too difficult to determine if an algorithm falls into that category (i.e if its a specific "woops" then fine, but if there has to be a lot of though of how to fix it - bin it). If something is built on solid foundations and there was a mistake, then I can't see why you'd have a problem with it remaining in the running. If people don't like it, they'll ignore it and it will fall by the way-side all on its own. Given your stance I'm assuming you'd say that Skein should be disqualified as well, because of the error in the reference implementation - it is the competition rules after all? > >>So why should the available options in this situation be prematurely >>narrowed? > > It shouldn't. OTOH, you shouldn't have used the word "prematurely" in the sentence. Ouch, why not then? > > Are you saying that NIST should *never* narrow the candidates if the original proposers can come up with fixes after attacks? If not, where do you set the end date for fixes, and why should we use your end date instead of NIST's? On the contrary I'm assuming that NIST will narrow the candidates. The competition is effectively being run as a public consultation, so given an algorithm that is broken and subsequently fixed, the amount of public interest in the fix would likely determine the outcome. If nobody's bothered then it's probably best being left out, if there's still a lot of interest then why should it not be considered? NIST can essentially afford to take its time before choosing the next round candidates, there's probably a lot of benefit in waiting and seeing what still attracts interest further down the line. > >>NIST hasn't even published the "complete and proper" >>submissions yet. > > Geez, it has only been a month. What is the rush? We're talking about a government bureaucracy with a zillion other things it is supposed to do at the same time. Eh, that was my point: NIST hasn't published the "complete and proper" submission list and we're having an argument about whether candidate submissions should be discounted before knowing what is to be accepted. > >>Personally, I think the nature of any >>break/attack/fix would hold enough significance for the community at >>large to easily determine good candidate algorithms from poor ones >>without any loss of focus. > > I'm not a cryptographer (but I sometimes play one in the press), but I can do simple math. Having 50 proposals (that include broken-but-fixed ones) will have about 25% less focus than having 40 proposals. That's assuming that any efforts to analyse the algorithms will be uniformally distributed, which I doubt would be the case. > >>Out of interest, why do you think there's going to be a lack of focus? > > See my math above. > > --Paul Hoffman, Director > --VPN Consortium > > From hash-forum@nist.gov Wed Dec 3 12:52:18 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB3KqB2c009499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Dec 2008 12:52:14 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB3KpISL024495; Wed, 3 Dec 2008 15:51:22 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB3KoarZ027521; Wed, 3 Dec 2008 15:50:36 -0500 Date: Wed, 3 Dec 2008 15:50:36 -0500 Message-Id: <7731938b0812031245r3def6b7t410e655de5a2fb4@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Peter Maxwell" To: Multiple recipients of list Subject: Re: On "fixes" to attacks X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <7731938b0812030850h60283530y9f4a0efd3ec7fab3@mail.gmail.com> <4936CA19.30503@larc.usp.br> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 In-Reply-To: <4936CA19.30503@larc.usp.br> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 03 Dec 2008 12:52:14 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 266 2008/12/3 Paulo S. L. M. Barreto : > > Paul Hoffman wrote: >> At 11:53 AM -0500 12/3/08, Peter Maxwell wrote: >>> Imagine, if you will, that during the AES process Rijndael had been >>> flawed in a major but easily fixable manner. In that artificial >>> situation, and with the benefit of hindsight that we currently have, >>> would you still of insisted on it being discarded? >> >> Yes. There were other good candidates at the time. For the SHA3 competition, we will probably have many more good first-round candidates. > > Besides, keep in mind that this scenario is, as you point out, artificial -- one > of the reasons Rijndael made it to the second round and then became the AES is > that it was *not* flawed. > > Perhaps a better analogy would be with any of the AES candidates that did not > make it to the second round, say, DFC, LOKI97 or MAGENTA (see e.g. > DOI:10.1007/b72329)? > > Paulo. > > Good point, however which out of DFC, LOKI97 or MAGENTA had good theoretical arguments or analysis to back them up? Rijndael had a pretty convincing security argument, as did Twofish. If I may be so bold as to use Whirlpool as an example; I'm assuming before publishing the correction to the MDS matrix that you didn't think of just binning the whole algorithm? I certainly wouldn't have discarded it, its a good algorithm and is designed from what I can tell is very sound reasoning - so much so that I used the main principles in my own submission. I know this is different circumstances, its a competition, but there is an added benefit in a competition in that small errors can (and generally are) picked up very quickly - so why not use that property rather than discard it? I'm not saying that everything that is broken should continue, rather that if its a small/simple/obvious error that is easy to fix (and with a level of confidence in the fix) then it probably should be allowed. Best wishes, Peter From hash-forum@nist.gov Wed Dec 3 13:06:46 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB3L6fdr011220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Dec 2008 13:06:42 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB3L5KeT027142; Wed, 3 Dec 2008 16:05:26 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB3L4xUp024997; Wed, 3 Dec 2008 16:04:59 -0500 Date: Wed, 3 Dec 2008 16:04:59 -0500 Message-Id: <802BDE9B-E379-4EFB-825F-039BDA4984A7@zooko.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: zooko To: Multiple recipients of list Subject: Re: On "fixes" to attacks X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: <898039814.7559221228330720548.JavaMail.root@mail3.gatech.edu> In-Reply-To: <898039814.7559221228330720548.JavaMail.root@mail3.gatech.edu> Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 03 Dec 2008 13:06:42 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 267 It could be that increasing the number of rounds (as proposed by the Enrupt author, for example) should be treated differently from other alterations. Likewise, CubeHash as proposed -- CubeHash8/1 -- is way too slow to be interesting to me as a secure hash function to use for my purposes, but CubeHash itself is nice and very simple, and NIST should consider standardizing a faster variant of CubeHash, such as CubeHash8/8. Likewise, I would be perfectly happy with NIST standardizing a variant of Enrupt such as Enrupt/8, even though the original proposal suggested Enrupt/4. NIST should certainly tune the security/performance trade-off parameters -- the parameters the original authors proposed should be treated as a recommendation from a single source, not as definitive. That includes parameters such as Enrupt's number of rounds or CubeHash's "b" parameter (or CubeHash's number of rounds), but NIST should not consider fixes or tweaks to algorithms. Regards, Zooko From hash-forum@nist.gov Wed Dec 3 13:28:00 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB3LRt1m013778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Dec 2008 13:27:56 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB3LQn9c001789; Wed, 3 Dec 2008 16:26:54 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB3LQEhg002686; Wed, 3 Dec 2008 16:26:14 -0500 Date: Wed, 3 Dec 2008 16:26:14 -0500 Message-Id: <4936F6D1.5050308@larc.usp.br> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Paulo S. L. M. Barreto" To: Multiple recipients of list Subject: Re: On "fixes" to attacks X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 In-Reply-To: <7731938b0812031245r3def6b7t410e655de5a2fb4@mail.gmail.com> References: <7731938b0812030850h60283530y9f4a0efd3ec7fab3@mail.gmail.com> <4936CA19.30503@larc.usp.br> <7731938b0812031245r3def6b7t410e655de5a2fb4@mail.gmail.com> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 03 Dec 2008 13:27:56 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 268 Peter Maxwell wrote: > 2008/12/3 Paulo S. L. M. Barreto : >> Paul Hoffman wrote: >>> At 11:53 AM -0500 12/3/08, Peter Maxwell wrote: >>>> Imagine, if you will, that during the AES process Rijndael had been >>>> flawed in a major but easily fixable manner. In that artificial >>>> situation, and with the benefit of hindsight that we currently have, >>>> would you still of insisted on it being discarded? >>> Yes. There were other good candidates at the time. For the SHA3 competition, we will probably have many more good first-round candidates. >> Besides, keep in mind that this scenario is, as you point out, artificial -- one >> of the reasons Rijndael made it to the second round and then became the AES is >> that it was *not* flawed. >> >> Perhaps a better analogy would be with any of the AES candidates that did not >> make it to the second round, say, DFC, LOKI97 or MAGENTA (see e.g. >> DOI:10.1007/b72329)? >> >> Paulo. >> >> > > Good point, however which out of DFC, LOKI97 or MAGENTA had good > theoretical arguments or analysis to back them up? Rijndael had a > pretty convincing security argument, as did Twofish. Have a look at the DFC paper. I think that qualifies as "good theoretical arguments", whether or not they look "pretty convincing". > If I may be so bold as to use Whirlpool as an example; I'm assuming > before publishing the correction to the MDS matrix that you didn't > think of just binning the whole algorithm? I certainly wouldn't have > discarded it, its a good algorithm and is designed from what I can > tell is very sound reasoning - so much so that I used the main > principles in my own submission. I was expecting something along these lines sooner or later :) Well, may I quote Paul Hoffman? (1) "Bad straw-man, given that there was no competition involved," something I myself regreted at the time (yet there seemed to be no need for a new hash function at the time, except perhaps for a very high security level). (2) "this list is about the NIST hash competition," and Whirlpool is not one of the candidates. There's much more to gain or lose now, and many more candidates to choose from. > I know this is different circumstances, its a competition, but there > is an added benefit in a competition in that small errors can (and > generally are) picked up very quickly - so why not use that property > rather than discard it? I'm not saying that everything that is broken > should continue, rather that if its a small/simple/obvious error that > is easy to fix (and with a level of confidence in the fix) then it > probably should be allowed. The short answer may be that the AES needed no fix. It's remained stable and secure for ten years. Why not setting such a high standard as a goal for SHA-3? Cheers, Paulo. From hash-forum@nist.gov Wed Dec 3 13:28:07 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB3LS2SF013799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Dec 2008 13:28:03 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB3LQx7D029004; Wed, 3 Dec 2008 16:27:03 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB3LQn9I003803; Wed, 3 Dec 2008 16:26:49 -0500 Date: Wed, 3 Dec 2008 16:26:49 -0500 Message-Id: <4936F875.2010608@larc.usp.br> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Paulo S. L. M. Barreto" To: Multiple recipients of list Subject: Re: On "fixes" to attacks X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 In-Reply-To: <802BDE9B-E379-4EFB-825F-039BDA4984A7@zooko.com> References: <898039814.7559221228330720548.JavaMail.root@mail3.gatech.edu> <802BDE9B-E379-4EFB-825F-039BDA4984A7@zooko.com> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 03 Dec 2008 13:28:03 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 269 zooko wrote: > > It could be that increasing the number of rounds (as proposed by the > Enrupt author, for example) should be treated differently from other > alterations. > > Likewise, CubeHash as proposed -- CubeHash8/1 -- is way too slow to be > interesting to me as a secure hash function to use for my purposes, but > CubeHash itself is nice and very simple, and NIST should consider > standardizing a faster variant of CubeHash, such as CubeHash8/8. > > Likewise, I would be perfectly happy with NIST standardizing a variant > of Enrupt such as Enrupt/8, even though the original proposal suggested > Enrupt/4. > > NIST should certainly tune the security/performance trade-off parameters > -- the parameters the original authors proposed should be treated as a > recommendation from a single source, not as definitive. That includes > parameters such as Enrupt's number of rounds or CubeHash's "b" parameter > (or CubeHash's number of rounds), but NIST should not consider fixes or > tweaks to algorithms. Then NIST would have to explain very, very, very clearly why they adopted criteria so different from those of the AES competition (I'm not saying it's not possible -- I'm just saying they'll face yet another challenge, perhaps more difficult than when they had to write down the rationale for their choice of the AES). Paulo. From hash-forum@nist.gov Wed Dec 3 13:55:39 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB3LtYuR016500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Dec 2008 13:55:35 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB3LsfwS018069; Wed, 3 Dec 2008 16:54:49 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB3LrlLn025477; Wed, 3 Dec 2008 16:53:47 -0500 Date: Wed, 3 Dec 2008 16:53:47 -0500 Message-Id: <568019096.7622661228340423735.JavaMail.root@mail3.gatech.edu> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: David Bauer To: Multiple recipients of list Subject: Re: On "fixes" to attacks X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Zimbra 5.0.10_GA_2638.RHEL5_64 (zclient/5.0.10_GA_2638.RHEL5_64) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 In-Reply-To: <4936E0B9.6010100@larc.usp.br> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 03 Dec 2008 13:55:35 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 270 > That's an interesting sophism. Were we to follow it at face value, > how about a "fixed version of MD4"? Certainly, although since the "fixes" would include increasing the output size and state size (with no already defined way of doing so), it would be hard to call it just a fix. Additionally, given the 18 years of advances since MD4 was released, I hope that more improvements could be done than simple fixes. By comparison, the attacks on SHA-3 candidate algorithms so far have been on algorithms that have been released for days and weeks. I'm not aware of any great improvements to the state of the art (either attacking or defending) in that time. Currently, I do not believe any member of the SHA-2 family is actually threatened (suspect, due to their design heritage maybe, but not threatened). Thus, I consider them to be the reserve algorithms that the new SHA-3 candidates should exceed. (Triple-DES could be considered the reserve algorithm for the AES competition.) Skimming throuh the original request for candidates by NIST, I see that "significantly improved efficiency" compared to the SHA-2 family is one of the expectations; I believe this will knock out the great majority of the submissions. David Bauer From hash-forum@nist.gov Wed Dec 3 17:26:27 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB41QLY2005975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Dec 2008 17:26:22 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB41K5JC023539; Wed, 3 Dec 2008 20:20:08 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB41JfAT005066; Wed, 3 Dec 2008 20:19:41 -0500 Date: Wed, 3 Dec 2008 20:19:41 -0500 Message-Id: <20081204012151.92973.qmail@cr.yp.to> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "D. J. Bernstein" To: Multiple recipients of list Subject: Re: On "fixes" to attacks X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas In-Reply-To: <4936F875.2010608@larc.usp.br> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 03 Dec 2008 17:26:23 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 271 Speaking of CubeHash, the 2008.11 prize has been awarded, and I'm offering a new 2008.12 prize. See http://cubehash.cr.yp.to/prizes.html. I hope that other SHA-3 submitters start offering prizes too; as my web page comments, cryptanalysts are doing a huge amount of work for the community and deserve more gratitude than they're getting today. Meanwhile, an eBASH update: http://bench.cr.yp.to/results-hash.html now has measurements of BLAKE-32, BLAKE-64, BMW-256, BMW-512, CubeHash8/1 et al., Edon-R-256, Edon-R-512, Groestl-256, Groestl-512, MD6-256, and MD6-512 across a huge number of machines. > > NIST should certainly tune the security/performance trade-off parameters > NIST would have to explain very, very, very clearly why they adopted > criteria so different from those of the AES competition NIST already explicitly stated in the SHA-3 submission requirements that submitters could specify tunable parameters, allowing NIST to choose the security/performance tradeoff: The submitted algorithm may include a tunable security parameter, such as the number of rounds, which would allow the selection of a range of possible security/performance tradeoffs. ... The tunable parameter may be used to produce weakened versions of the submitted algorithm for analysis, and permit NIST to select a different security/performance tradeoff than originally specified by the submitter. Given the context I'd guess that NIST will also consider _strengthened_ parameter choices. However, even if they're only considering weakened parameter choices, they're looking at an entire security/performance curve, not just one point on the curve. Long ago, when NIST called for AES submissions, they mentioned variable key sizes and variable block sizes as interesting types of flexibility, but they didn't even think of variability of the number of rounds. They later received many requests for increased numbers of rounds (especially for Rijndael and RC6) but gave four reasons for sticking to the original submissions: (1) some algorithms didn't even have clear definitions, let alone security analyses, for larger numbers of rounds; (2) it was hard to redo performance analyses; (3) the _public_ couldn't agree on the best round counts; and (4) the _submitters_ didn't want to change their round counts. For SHA-3 the picture is quite different. NIST has allowed variable numbers of rounds from the beginning---matching the community's clear consensus on the value of this type of flexibility. Adding parameters won't require retroactively modifying submissions. We also have much better performance-analysis tools. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago From hash-forum@nist.gov Wed Dec 3 20:17:51 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB44HjgC021290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Dec 2008 20:17:46 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB44FdLR015128; Wed, 3 Dec 2008 23:15:45 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB44EJhU014593; Wed, 3 Dec 2008 23:14:19 -0500 Date: Wed, 3 Dec 2008 23:14:19 -0500 Message-Id: <493756bc.2075420a.4fd4.0225@mx.google.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Danilo Gligoroski" To: Multiple recipients of list Subject: RE: On "fixes" to attacks X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Microsoft Office Outlook 12.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 In-Reply-To: <7731938b0812031245r3def6b7t410e655de5a2fb4@mail.gmail.com> References: <7731938b0812030850h60283530y9f4a0efd3ec7fab3@mail.gmail.com> <4936CA19.30503@larc.usp.br> <7731938b0812031245r3def6b7t410e655de5a2fb4@mail.gmail.com> X-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 03 Dec 2008 20:17:47 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 272 Peter Maxwell wrote: >I know this is different circumstances, its a competition, but there >is an added benefit in a competition in that small errors can (and >generally are) picked up very quickly - so why not use that property >rather than discard it? I'm not saying that everything that is broken >should continue, rather that if its a small/simple/obvious error that >is easy to fix (and with a level of confidence in the fix) then it >probably should be allowed. I agree, and I think that NIST has already anticipated the possibility of tweaking (but in a very specific way). Probably based on the experience (and influenced) by the SHA-0 designers, NIST added one interesting possibility for tweaking of some of the submitted SHA-3 candidates. They say: During the course of the Round 1 evaluations, it is conceivable that some small deficiencies may be identified in even some of the most promising candidates. Therefore, for the Round 2 evaluations, small modifications to the submitted algorithms will be permitted for either security or efficiency purposes. Submitters may submit minor changes (no substantial redesigns), along with a supporting explanation/justification that must be received by NIST prior to the beginning of Round 2. (Submitters will be notified by NIST of the exact deadline.) NIST will determine whether or not the proposed modification would significantly affect the design of the algorithm, requiring a major re-evaluation; if such is the case, the modification will not be accepted. If modifications are submitted, new reference and optimized implementations and written descriptions shall be provided by the start of Round 2. This will allow a public review of the modified algorithms during the entire course of the Round 2 evaluation. Danilo! From hash-forum@nist.gov Thu Dec 4 04:35:32 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB4CZRog004031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Dec 2008 04:35:28 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB4CKKNc000753; Thu, 4 Dec 2008 07:20:26 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB4CIEG7000733; Thu, 4 Dec 2008 07:18:14 -0500 Date: Thu, 4 Dec 2008 07:18:14 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Jean-Philippe Aumasson" To: Multiple recipients of list Subject: Improved CubeHash analysis X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 04 Dec 2008 04:35:28 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, URI_HEX shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 273 Dear all, We have improved our differential technique to detect nonrandomness over the CubeHash transform: we now reach 10 rounds, against 8 rounds previously. This doesn't seem to affect the security of CubeHash (the submitted versions make 80 finalization rounds). The revised paper is available here: http://www.131002.net/data/papers/AMNP08.pdf Best, JP From hash-forum@nist.gov Thu Dec 4 05:12:15 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB4DC9oo008687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Dec 2008 05:12:10 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB4DAxGc021997; Thu, 4 Dec 2008 08:11:04 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB4DAKO7008985; Thu, 4 Dec 2008 08:10:20 -0500 Date: Thu, 4 Dec 2008 08:10:20 -0500 Message-Id: <007301c95610$ffe3e280$8d9295c2@staff.ii.edu.mk> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Smile Markovski" To: Multiple recipients of list Subject: RE: Free-start attacks on Nash X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas In-Reply-To: X-Mailer: Microsoft Outlook, Build 10.0.2616 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0074_01C95619.61A84A80" MIME-Version: 1.0 X-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 04 Dec 2008 05:12:11 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,HTML_MESSAGE, RATWARE_MS_HASH,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 274 This is a multi-part message in MIME format. ------=_NextPart_000_0074_01C95619.61A84A80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Ivica and Dmitry, a natural question to you is why you are not supplying a concrete example of a free-start collision, 2^{32} computations can be easily done on a PC? I think you owe to the folks such an example. Regards, S. Markovski _______________________ PS. Sorry for possible multiple mail. ******************************** Prof. Smile Markovski Institute of Informatics, Faculty of Sciences Arhimedova 5, p.f. 162 Skopje, Macedonia Phones: office +389 2 3 249 750, cellular +389 70 58 91 91 Fax: +389 2 3 162 078 -----Original Message----- From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Ivica Nikolic Sent: Wednesday, December 03, 2008 2:09 PM To: Multiple recipients of list Subject: Free-start attacks on Nash Hi, we found free-start attacks on NaSHA. The paper is available online: http://ehash.iaik.tugraz.at/uploads/3/33/Free-start_attacks_on_Nasha.pdf The free-start collision attack requires about 2^{32} computations for all digests. The free-start preimage attack requires about 2^{n/2} for NaSHA-n. Best regards, Ivica Nikolic and Dmitry Khovratovich Laboratory of Algorithms, Cryptography and Security, University of Luxembourg ------=_NextPart_000_0074_01C95619.61A84A80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ivica and = Dmitry,

 

a natural question to you is why = you are not supplying a concrete example of a free-start collision, 2^{32} = computations can be easily done on a PC? I think you owe to the folks such an example. =

 

 

Regards,

 

S. Markovski

_______________________

PS. Sorry for possible multiple mail.

 

********************************

Prof. Smile Markovski=

Institute of Informatics= , Faculty of Sciences

Arhimedova 5, p.f. 162

Skopje= , Macedonia

Phones: office +389 2 3 249 750, cellular +389 70 58 = 91 91

Fax: +389 2 3 162 078

 

---= --Original Message-----
From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On = Behalf Of Ivica Nikolic
Sent: = Wed= nesday, December 03, 2008 2:0= 9 PM To: Multiple recipients = of list
Subject: Free-start = attacks on Nash

 

Hi,

 

we found = free-start attacks on NaSHA. The paper is available = online:

The free-start = collision attack requires about 2^{32} computations for all = digests. 

The free-start = preimage attack requires about 2^{n/2} for = NaSHA-n. 

 

Best = regards,
Ivica Nikolic and Dmitry Khovratovich
Laboratory of Algorithms, Cryptography and Security,
University of Luxembourg

------=_NextPart_000_0074_01C95619.61A84A80-- From hash-forum@nist.gov Thu Dec 4 06:15:25 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB4EFJ2U015133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Dec 2008 06:15:21 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB4E61QZ003172; Thu, 4 Dec 2008 09:06:06 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB4E5Aav023901; Thu, 4 Dec 2008 09:05:10 -0500 Date: Thu, 4 Dec 2008 09:05:10 -0500 Message-Id: <20081204140231.GA9601@titan.cry.pto> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Thomas Pornin To: Multiple recipients of list Subject: Re: On "fixes" to attacks X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas In-Reply-To: <7731938b0812031654j2533ddb8h6f4205230daa4129@mail.gmail.com> Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 References: <7731938b0812030850h60283530y9f4a0efd3ec7fab3@mail.gmail.com> <4936CA19.30503@larc.usp.br> <7731938b0812031245r3def6b7t410e655de5a2fb4@mail.gmail.com> <4936F6D1.5050308@larc.usp.br> <7731938b0812031654j2533ddb8h6f4205230daa4129@mail.gmail.com> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 04 Dec 2008 06:15:21 -0800 (PST) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 275 On Wed, Dec 03, 2008 at 08:05:02PM -0500, Peter Maxwell wrote: > Cheers, have just had a look - I'd read some material on Vaudenay's > decorrelation theory previously but not in any real detail and hadn't > realised it was connected with the DFC cipher. I'd noticed the > reference in wikipedia to Knudsen & Rijmen's paper, was that the > reason it didn't get selected as a finalist? Beyond some considerations on performance, and a few theoretical weaknesses on a couple of submissions, the selection process from AES round 1 to round 2 was mostly a matter of feelings, which cannot be described in full rationality. DFC was quite fast, but it included an arithmetic operation (with a modular reduction) which was difficult to implement and test properly, especially on 8-bit systems (smartcards...) and dedicated circuitry (a bit like RC6, but worse). When implemented, it was not slow, but still the implementation process was generally feeled to be painfull. Thus, cryptographers at large did not feel "comfortable enough" with DFC that they could feel with the other algorithms. In the end, there was room for only five algorithms in round 2. At that point, there were more than five good-looking candidates. That was quite refreshing: it meant that the problem of designing a secure symmetric block cipher was mostly "solved" and that the AES would be a strong and efficient algorithm (rather than the "least broken and ugly which could be found", which was feared at one time). But it also meant that quite good algorithms would necessarily be "rejected" as well (there is _one_ AES). I like to believe that DFC was such a "good" algorithm. --Thomas Pornin From hash-forum@nist.gov Thu Dec 4 10:42:59 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB4IgsbP016720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Dec 2008 10:42:55 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB4IfbfW017112; Thu, 4 Dec 2008 13:41:48 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB4Idbfo003351; Thu, 4 Dec 2008 13:39:37 -0500 Date: Thu, 4 Dec 2008 13:39:37 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Jean-Philippe Aumasson" To: Multiple recipients of list Subject: Collision for CubeHash2/120-512 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/mixed; boundary="----=_Part_10579_23760743.1228415398622" MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 04 Dec 2008 10:42:55 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, URI_HEX shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 276 ------=_Part_10579_23760743.1228415398622 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline [ This is NOT a break of CubeHash as submitted to NIST ] The following 2880-bit messages collide through CubeHash2/120-512: First message: 43CACBA20E63FF78D505D9F9850EE62C9B45B188AE22E9FEC4FEE220E5C3A9AE6F06868CD0A1122AE38B386F1358C0FBC3746E574BEB5D6E09399B4084D4D787E6C820BFE6615F68C8EA490686609E2A65833582C4806EB0C21B78F45F76346A689B52D3D1F6CF5311DE4ED0B365DDB1576907DC0326A2EB2737D5297D036CF400AE27132751CFBF88DDFECF810CEB4AAD133BDBD21D7334CE9C9FC977CA46B5AE61BFF61618B1ED193268667B0ADDD220AFDE2A416090293996BAB0E62CEAC10B60B87AAC0E088B9199D029288D878180034668C6BB9DE64CA89DCE4C284AD41BF38414D3E4D27A5DF41A428842CCDEF0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132B33435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F6061626364656667 Second message: 43CACBA20E63FF78D505D9F9850EE62C9B45B188AE22E9FEC4FEE220E5C3A9AE6F06868CD0A1122AE38B386F1358C0FBC3746E574BEB5D6E09399B4084D4D787E6C820BFE6615F68C8EA490686609E2A65833582C4806EB0C21B78F45F76346A689B52D3D1F6CF5311DE4ED0B365DDB1576907DC0326A2EB2737D7597D036CF400AE27132751CFBF88DDFECFC10CEB4A2D133BDB921D7334CA9C9FC877CA46B5AA61BFF61618B1ED193268667B0ADDD2208FDE2A416090293990B8E0E62CEAC10B60B87AAC0E088B9199D029E88D87810003466806BB9DE64CA89DCE30284AD41BF38414D7E4D27A5DF41A428862CCDEF0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F6061626364656667 The common digest is: C48C99A0D37E1EB2AC7C42EDF4EDEC7AB73B7689506856CA458770096FC4A38B19016DCA3834F1F5805B3E47F3C38C705B4A25F5C2801D41A15CDF9E3603C61A (I attached a C program to verify the collision.) This collision was found using simple differential techniques, similar to those presented in http://www.131002.net/data/papers/AMNP08.pdf No particular computation effort was necessary. In comparison the standard collision attack costs about 2^32 transforms. Recall that CubeHash2/120-512 has r=2 (2 rounds per transform, 20 rounds to initialize and 20 rounds to finalize), b=120 (message blocks are xored with 120 of the 128 state bytes), h=512 (digest bitlength). ------=_Part_10579_23760743.1228415398622 Content-Type: application/octet-stream; name=hash.c Content-Transfer-Encoding: base64 X-Attachment-Id: f_fobqkx6r0 Content-Disposition: attachment; filename=hash.c I2RlZmluZSBDVUJFSEFTSF9ST1VORFMgMgojZGVmaW5lIENVQkVIQVNIX0JMT0NLQllURVMgMTIw CiNpbmNsdWRlIDxzdGRpby5oPgojaW5jbHVkZSAiaGFzaC5oIgoKI2RlZmluZSBST1RBVEUoYSxi KSAoKChhKSA8PCAoYikpIHwgKChhKSA+PiAoMzIgLSBiKSkpCgpzdGF0aWMgdm9pZCB0cmFuc2Zv cm0oaGFzaFN0YXRlICpzdGF0ZSkKewogIGludCBpOwogIGludCByOwogIG15dWludDMyIHlbMTZd OwoKICBmb3IgKHIgPSAwO3IgPCBDVUJFSEFTSF9ST1VORFM7KytyKSB7CiAgICBmb3IgKGkgPSAw O2kgPCAxNjsrK2kpIHN0YXRlLT54W2kgKyAxNl0gKz0gc3RhdGUtPnhbaV07CiAgICBmb3IgKGkg PSAwO2kgPCAxNjsrK2kpIHlbaSBeIDhdID0gc3RhdGUtPnhbaV07CiAgICBmb3IgKGkgPSAwO2kg PCAxNjsrK2kpIHN0YXRlLT54W2ldID0gUk9UQVRFKHlbaV0sNyk7CiAgICBmb3IgKGkgPSAwO2kg PCAxNjsrK2kpIHN0YXRlLT54W2ldIF49IHN0YXRlLT54W2kgKyAxNl07CiAgICBmb3IgKGkgPSAw O2kgPCAxNjsrK2kpIHlbaSBeIDJdID0gc3RhdGUtPnhbaSArIDE2XTsKICAgIGZvciAoaSA9IDA7 aSA8IDE2OysraSkgc3RhdGUtPnhbaSArIDE2XSA9IHlbaV07CiAgICBmb3IgKGkgPSAwO2kgPCAx NjsrK2kpIHN0YXRlLT54W2kgKyAxNl0gKz0gc3RhdGUtPnhbaV07CiAgICBmb3IgKGkgPSAwO2kg PCAxNjsrK2kpIHlbaSBeIDRdID0gc3RhdGUtPnhbaV07CiAgICBmb3IgKGkgPSAwO2kgPCAxNjsr K2kpIHN0YXRlLT54W2ldID0gUk9UQVRFKHlbaV0sMTEpOwogICAgZm9yIChpID0gMDtpIDwgMTY7 KytpKSBzdGF0ZS0+eFtpXSBePSBzdGF0ZS0+eFtpICsgMTZdOwogICAgZm9yIChpID0gMDtpIDwg MTY7KytpKSB5W2kgXiAxXSA9IHN0YXRlLT54W2kgKyAxNl07CiAgICBmb3IgKGkgPSAwO2kgPCAx NjsrK2kpIHN0YXRlLT54W2kgKyAxNl0gPSB5W2ldOwogIH0KfQoKSGFzaFJldHVybiBJbml0KGhh c2hTdGF0ZSAqc3RhdGUsIGludCBoYXNoYml0bGVuKQp7CiAgaW50IGk7CiAgaW50IGo7CgogIGlm IChoYXNoYml0bGVuIDwgOCkgcmV0dXJuIEJBRF9IQVNIQklUTEVOOwogIGlmIChoYXNoYml0bGVu ID4gNTEyKSByZXR1cm4gQkFEX0hBU0hCSVRMRU47CiAgaWYgKGhhc2hiaXRsZW4gIT0gOCAqICho YXNoYml0bGVuIC8gOCkpIHJldHVybiBCQURfSEFTSEJJVExFTjsKCiAgc3RhdGUtPmhhc2hiaXRs ZW4gPSBoYXNoYml0bGVuOwogIGZvciAoaSA9IDA7aSA8IDMyOysraSkgc3RhdGUtPnhbaV0gPSAw OwogIHN0YXRlLT54WzBdID0gaGFzaGJpdGxlbiAvIDg7CiAgc3RhdGUtPnhbMV0gPSBDVUJFSEFT SF9CTE9DS0JZVEVTOwogIHN0YXRlLT54WzJdID0gQ1VCRUhBU0hfUk9VTkRTOwogIGZvciAoaSA9 IDA7aSA8IDEwOysraSkgdHJhbnNmb3JtKHN0YXRlKTsKICBzdGF0ZS0+cG9zID0gMDsKCiAgcmV0 dXJuIFNVQ0NFU1M7Cn0KCkhhc2hSZXR1cm4gVXBkYXRlKGhhc2hTdGF0ZSAqc3RhdGUsIGNvbnN0 IEJpdFNlcXVlbmNlICpkYXRhLAogICAgICAgICAgICAgICAgICBEYXRhTGVuZ3RoIGRhdGFiaXRs ZW4pCnsKICAvKiBjYWxsZXIgcHJvbWlzZXMgdXMgdGhhdCBwcmV2aW91cyBkYXRhIGhhZCBpbnRl Z3JhbCBudW1iZXIgb2YgYnl0ZXMgKi8KICAvKiBzbyBzdGF0ZS0+cG9zIGlzIGEgbXVsdGlwbGUg b2YgOCAqLwoKICB3aGlsZSAoZGF0YWJpdGxlbiA+PSA4KSB7CiAgICBteXVpbnQzMiB1ID0gKmRh dGE7CiAgICB1IDw8PSA4ICogKChzdGF0ZS0+cG9zIC8gOCkgJSA0KTsKICAgIHN0YXRlLT54W3N0 YXRlLT5wb3MgLyAzMl0gXj0gdTsKCiAgICBkYXRhICs9IDE7CiAgICBkYXRhYml0bGVuIC09IDg7 CiAgICBzdGF0ZS0+cG9zICs9IDg7CiAgICBpZiAoc3RhdGUtPnBvcyA9PSA4ICogQ1VCRUhBU0hf QkxPQ0tCWVRFUykgewogICAgICB0cmFuc2Zvcm0oc3RhdGUpOwogICAgICBzdGF0ZS0+cG9zID0g MDsKICAgIH0KICB9CiAgaWYgKGRhdGFiaXRsZW4gPiAwKSB7CiAgICBteXVpbnQzMiB1ID0gKmRh dGE7CiAgICB1IDw8PSA4ICogKChzdGF0ZS0+cG9zIC8gOCkgJSA0KTsKICAgIHN0YXRlLT54W3N0 YXRlLT5wb3MgLyAzMl0gXj0gdTsKICAgIHN0YXRlLT5wb3MgKz0gZGF0YWJpdGxlbjsKICB9CiAg cmV0dXJuIFNVQ0NFU1M7Cn0KCkhhc2hSZXR1cm4gRmluYWwoaGFzaFN0YXRlICpzdGF0ZSwgQml0 U2VxdWVuY2UgKmhhc2h2YWwpCnsKICBpbnQgaTsKICBteXVpbnQzMiB1OwoKICB1ID0gKDEyOCA+ PiAoc3RhdGUtPnBvcyAlIDgpKTsKICB1IDw8PSA4ICogKChzdGF0ZS0+cG9zIC8gOCkgJSA0KTsK ICBzdGF0ZS0+eFtzdGF0ZS0+cG9zIC8gMzJdIF49IHU7CiAgdHJhbnNmb3JtKHN0YXRlKTsKICBz dGF0ZS0+eFszMV0gXj0gMTsKICBmb3IgKGkgPSAwO2kgPCAxMDsrK2kpIHRyYW5zZm9ybShzdGF0 ZSk7CiAgZm9yIChpID0gMDtpIDwgc3RhdGUtPmhhc2hiaXRsZW4gLyA4OysraSkgaGFzaHZhbFtp XSA9IHN0YXRlLT54W2kgLyA0XSA+PiAoOCAqIChpICUgNCkpOwoKICByZXR1cm4gU1VDQ0VTUzsK fQoKSGFzaFJldHVybiBIYXNoKGludCBoYXNoYml0bGVuLCBjb25zdCBCaXRTZXF1ZW5jZSAqZGF0 YSwKICAgICAgICAgICAgICAgIERhdGFMZW5ndGggZGF0YWJpdGxlbiwgQml0U2VxdWVuY2UgKmhh c2h2YWwpCnsKICBoYXNoU3RhdGUgc3RhdGU7CiAgaWYgKEluaXQoJnN0YXRlLGhhc2hiaXRsZW4p ICE9IFNVQ0NFU1MpIHJldHVybiBCQURfSEFTSEJJVExFTjsKICBVcGRhdGUoJnN0YXRlLGRhdGEs ZGF0YWJpdGxlbik7CiAgcmV0dXJuIEZpbmFsKCZzdGF0ZSxoYXNodmFsKTsKfQoKCmludCBtYWlu KCkgewoKICBteXVpbnQzMiBtZXNzMVs2MF0sbWVzczJbNjBdOwogIEJpdFNlcXVlbmNlIGRhdGEx WzM2MF0sZGF0YTJbMzYwXTsKCiAgQml0U2VxdWVuY2UgaGFzaDFbNjRdLCBoYXNoMls2NF07CgoK CiAgbWVzczFbIDBdID0gMHhBMkNCQ0E0MzsJbWVzczFbIDFdID0gMHg3OEZGNjMwRTsJbWVzczFb IDJdID0gMHhGOUQ5MDVENTsJbWVzczFbIDNdID0gMHgyQ0U2MEU4NTsKICBtZXNzMVsgNF0gPSAw eDg4QjE0NTlCOwltZXNzMVsgNV0gPSAweEZFRTkyMkFFOwltZXNzMVsgNl0gPSAweDIwRTJGRUM0 OwltZXNzMVsgN10gPSAweEFFQTlDM0U1OwogIG1lc3MxWyA4XSA9IDB4OEM4NjA2NkY7CW1lc3Mx WyA5XSA9IDB4MkExMkExRDA7CW1lc3MxWzEwXSA9IDB4NkYzODhCRTM7CW1lc3MxWzExXSA9IDB4 RkJDMDU4MTM7CiAgbWVzczFbMTJdID0gMHg1NzZFNzRDMzsJbWVzczFbMTNdID0gMHg2RTVERUI0 QjsJbWVzczFbMTRdID0gMHg0MDlCMzkwOTsJbWVzczFbMTVdID0gMHg4N0Q3RDQ4NDsKICBtZXNz MVsxNl0gPSAweEJGMjBDOEU2OwltZXNzMVsxN10gPSAweDY4NUY2MUU2OwltZXNzMVsxOF0gPSAw eDA2NDlFQUM4OwltZXNzMVsxOV0gPSAweDJBOUU2MDg2OwogIG1lc3MxWzIwXSA9IDB4ODIzNTgz NjU7CW1lc3MxWzIxXSA9IDB4QjA2RTgwQzQ7CW1lc3MxWzIyXSA9IDB4RjQ3ODFCQzI7CW1lc3Mx WzIzXSA9IDB4NkEzNDc2NUY7CiAgbWVzczFbMjRdID0gMHhEMzUyOUI2ODsJbWVzczFbMjVdID0g MHg1M0NGRjZEMTsJbWVzczFbMjZdID0gMHhEMDRFREUxMTsJbWVzczFbMjddID0gMHhCMURENjVC MzsKICBtZXNzMVsyOF0gPSAweERDMDc2OTU3OwltZXNzMVsyOV0gPSAweEVCQTIyNjAzOwogIG1l c3MxWzMwXSA9IDB4MjlENTM3Mjc7CW1lc3MxWzMxXSA9IDB4RjQ2QzAzN0Q7CW1lc3MxWzMyXSA9 IDB4MTMyN0FFMDA7CW1lc3MxWzMzXSA9IDB4QkZDRjUxMjc7CiAgbWVzczFbMzRdID0gMHhDRkZF REQ4ODsJbWVzczFbMzVdID0gMHg0QUVCMEM4MTsJbWVzczFbMzZdID0gMHhEQjNCMTNBRDsJbWVz czFbMzddID0gMHgzNDczMUREMjsKICBtZXNzMVszOF0gPSAweEM5OUY5Q0NFOwltZXNzMVszOV0g PSAweEI1NDZDQTc3OwltZXNzMVs0MF0gPSAweEY2QkY2MUFFOwltZXNzMVs0MV0gPSAweEVEQjEx ODE2OwogIG1lc3MxWzQyXSA9IDB4NjY2ODMyMTk7CW1lc3MxWzQzXSA9IDB4RDJERDBBN0I7CW1l c3MxWzQ0XSA9IDB4MkFERUFGMjA7CW1lc3MxWzQ1XSA9IDB4Mjk5MDYwNDE7CiAgbWVzczFbNDZd ID0gMHhCMEJBOTYzOTsJbWVzczFbNDddID0gMHhDMUVBMkNFNjsJbWVzczFbNDhdID0gMHg3QUI4 NjAwQjsJbWVzczFbNDldID0gMHg4QjA4MEVBQzsKICBtZXNzMVs1MF0gPSAweDI5RDA5OTkxOwlt ZXNzMVs1MV0gPSAweDgxODc4RDI4OwltZXNzMVs1Ml0gPSAweDY4NDYwMzgwOwltZXNzMVs1M10g PSAweEU2OURCQkM2OwogIG1lc3MxWzU0XSA9IDB4Q0U5REE4NEM7CW1lc3MxWzU1XSA9IDB4RDQ0 QTI4NEM7CW1lc3MxWzU2XSA9IDB4MTQ4NEYzMUI7CW1lc3MxWzU3XSA9IDB4N0FEMkU0RDM7CiAg bWVzczFbNThdID0gMHg0MjFBRjQ1RDsJbWVzczFbNTldID0gMHhERUNDNDI4ODsKCiAgbWVzczJb IDBdID0gMHhBMkNCQ0E0MzsJbWVzczJbIDFdID0gMHg3OEZGNjMwRTsJbWVzczJbIDJdID0gMHhG OUQ5MDVENTsJbWVzczJbIDNdID0gMHgyQ0U2MEU4NTsKICBtZXNzMlsgNF0gPSAweDg4QjE0NTlC OwltZXNzMlsgNV0gPSAweEZFRTkyMkFFOwltZXNzMlsgNl0gPSAweDIwRTJGRUM0OwltZXNzMlsg N10gPSAweEFFQTlDM0U1OwogIG1lc3MyWyA4XSA9IDB4OEM4NjA2NkY7CW1lc3MyWyA5XSA9IDB4 MkExMkExRDA7CW1lc3MyWzEwXSA9IDB4NkYzODhCRTM7CW1lc3MyWzExXSA9IDB4RkJDMDU4MTM7 CiAgbWVzczJbMTJdID0gMHg1NzZFNzRDMzsJbWVzczJbMTNdID0gMHg2RTVERUI0QjsJbWVzczJb MTRdID0gMHg0MDlCMzkwOTsJbWVzczJbMTVdID0gMHg4N0Q3RDQ4NDsKICBtZXNzMlsxNl0gPSAw eEJGMjBDOEU2OwltZXNzMlsxN10gPSAweDY4NUY2MUU2OwltZXNzMlsxOF0gPSAweDA2NDlFQUM4 OwltZXNzMlsxOV0gPSAweDJBOUU2MDg2OwogIG1lc3MyWzIwXSA9IDB4ODIzNTgzNjU7CW1lc3My WzIxXSA9IDB4QjA2RTgwQzQ7CW1lc3MyWzIyXSA9IDB4RjQ3ODFCQzI7CW1lc3MyWzIzXSA9IDB4 NkEzNDc2NUY7CiAgbWVzczJbMjRdID0gMHhEMzUyOUI2ODsJbWVzczJbMjVdID0gMHg1M0NGRjZE MTsJbWVzczJbMjZdID0gMHhEMDRFREUxMTsJbWVzczJbMjddID0gMHhCMURENjVCMzsKICBtZXNz MlsyOF0gPSAweERDMDc2OTU3OwltZXNzMlsyOV0gPSAweEVCQTIyNjAzOwogIG1lc3MyWzMwXSA9 IDB4NTlENzM3Mjc7CW1lc3MyWzMxXSA9IDB4RjQ2QzAzN0Q7CW1lc3MyWzMyXSA9IDB4MTMyN0FF MDA7CW1lc3MyWzMzXSA9IDB4QkZDRjUxMjc7CiAgbWVzczJbMzRdID0gMHhDRkZFREQ4ODsJbWVz czJbMzVdID0gMHg0QUVCMENDMTsJbWVzczJbMzZdID0gMHhEQjNCMTMyRDsJbWVzczJbMzddID0g MHgzNDczMUQ5MjsKICBtZXNzMlszOF0gPSAweEM4OUY5Q0NBOwltZXNzMlszOV0gPSAweEI1NDZD QTc3OwltZXNzMls0MF0gPSAweEY2QkY2MUFBOwltZXNzMls0MV0gPSAweEVEQjExODE2OwogIG1l c3MyWzQyXSA9IDB4NjY2ODMyMTk7CW1lc3MyWzQzXSA9IDB4RDJERDBBN0I7CW1lc3MyWzQ0XSA9 IDB4MkFERThGMjA7CW1lc3MyWzQ1XSA9IDB4Mjk5MDYwNDE7CiAgbWVzczJbNDZdID0gMHhFMEI4 OTAzOTsJbWVzczJbNDddID0gMHhDMUVBMkNFNjsJbWVzczJbNDhdID0gMHg3QUI4NjAwQjsJbWVz czJbNDldID0gMHg4QjA4MEVBQzsKICBtZXNzMls1MF0gPSAweDI5RDA5OTkxOwltZXNzMls1MV0g PSAweDgxODc4REU4OwltZXNzMls1Ml0gPSAweDY4NDYwMzAwOwltZXNzMls1M10gPSAweEU2OURC QjA2OwogIG1lc3MyWzU0XSA9IDB4Q0U5REE4NEM7CW1lc3MyWzU1XSA9IDB4RDQ0QTI4MzA7CW1l c3MyWzU2XSA9IDB4MTQ4NEYzMUI7CW1lc3MyWzU3XSA9IDB4N0FEMkU0RDc7CiAgbWVzczJbNThd ID0gMHg0MjFBRjQ1RDsJbWVzczJbNTldID0gMHhERUNDNjI4ODsKCiAgaW50IGk7CiNkZWZpbmUg VTMyVE84X0JFKHAsIHYpCQkJCVwKICBkbyB7CQkJCQkJXAogICAgKHApWzBdID0gKEJpdFNlcXVl bmNlKSgodikgPj4gIDApOwkJXAogICAgKHApWzFdID0gKEJpdFNlcXVlbmNlKSgodikgPj4gIDgp OwkJXAogICAgKHApWzJdID0gKEJpdFNlcXVlbmNlKSgodikgPj4gMTYpOwkJXAogICAgKHApWzNd ID0gKEJpdFNlcXVlbmNlKSgodikgPj4gMjQpOwkJXAogIH0gd2hpbGUgKDApCgogIGZvcihpPTA7 aTw2MDsrK2kpewogICAgVTMyVE84X0JFKGRhdGExKyBpKjQsIG1lc3MxW2ldKTsKICAgIFUzMlRP OF9CRShkYXRhMisgaSo0LCBtZXNzMltpXSk7IAogIH0KCiAgZm9yKGk9MjQwO2k8MzYwO2krKyl7 CiAgICBkYXRhMVtpXT1pOwogICAgZGF0YTJbaV09aTsKICB9CiAgZGF0YTFbMzA3XSBePSAweDgw OwoKICBwcmludGYoIlxubWVzc2FnZSAxOlxuXG4iKTsKICBmb3IoaT0wO2k8MzYwOysraSkKICAg IHByaW50ZigiJTAyWCIsZGF0YTFbaV0pOwogIHByaW50ZigiXG5cbm1lc3NhZ2UgMjpcblxuIik7 CiAgZm9yKGk9MDtpPDM2MDsrK2kpCiAgICBwcmludGYoIiUwMlgiLGRhdGEyW2ldKTsKICBwcmlu dGYoIlxuIik7CiAgCiAgSGFzaCggNTEyLCBkYXRhMSwgOTAqMzIsIGhhc2gxICk7CiAgSGFzaCgg NTEyLCBkYXRhMiwgOTAqMzIsIGhhc2gyICk7CgogIHByaW50ZigiXG5kaWdlc3Q6XG5cbiIpOwoK ICBmb3IoaT0wO2k8NjQ7KytpKSAgCiAgICBwcmludGYoIiUwMlgiLGhhc2gxW2ldKTsKICBwcmlu dGYoIlxuIik7CiAgZm9yKGk9MDtpPDY0OysraSkgIAogICAgcHJpbnRmKCIlMDJYIixoYXNoMltp XSk7CiAgcHJpbnRmKCJcbiIpOwoKICBmb3IoaT0wO2k8NjQ7KytpKSAgCiAgICBpZiAoaGFzaDFb aV0gIT0gaGFzaDJbaV0pewogICAgICBwcmludGYoIlxuZGlmZmVyZW50IGRpZ2VzdHMhXG5cbiIp OwogICAgfQogIHByaW50ZigiXG5zYW1lIGRpZ2VzdHMhXG5cbiIpOwogICAgIAogIAogIHJldHVy biAwOwp9Cg== ------=_Part_10579_23760743.1228415398622 Content-Type: application/octet-stream; name=hash.h Content-Transfer-Encoding: base64 X-Attachment-Id: f_fobqlgus1 Content-Disposition: attachment; filename=hash.h I2lmbmRlZiBjdWJlaGFzaF9oCiNkZWZpbmUgY3ViZWhhc2hfaAoKdHlwZWRlZiB1bnNpZ25lZCBj aGFyIEJpdFNlcXVlbmNlOwp0eXBlZGVmIHVuc2lnbmVkIGxvbmcgbG9uZyBEYXRhTGVuZ3RoOwp0 eXBlZGVmIGVudW0geyBTVUNDRVNTID0gMCwgRkFJTCA9IDEsIEJBRF9IQVNIQklUTEVOID0gMiB9 IEhhc2hSZXR1cm47Cgp0eXBlZGVmIHVuc2lnbmVkIGludCBteXVpbnQzMjsgLyogbXVzdCBiZSBl eGFjdGx5IDMyIGJpdHMgKi8KCnR5cGVkZWYgc3RydWN0IHsKICBpbnQgaGFzaGJpdGxlbjsKICBp bnQgcG9zOyAvKiBudW1iZXIgb2YgYml0cyByZWFkIGludG8geCBmcm9tIGN1cnJlbnQgYmxvY2sg Ki8KICBteXVpbnQzMiB4WzMyXTsKfSBoYXNoU3RhdGU7CgpIYXNoUmV0dXJuIEluaXQoaGFzaFN0 YXRlICpzdGF0ZSwgaW50IGhhc2hiaXRsZW4pOwoKSGFzaFJldHVybiBVcGRhdGUoaGFzaFN0YXRl ICpzdGF0ZSwgY29uc3QgQml0U2VxdWVuY2UgKmRhdGEsCiAgICAgICAgICAgICAgICAgIERhdGFM ZW5ndGggZGF0YWJpdGxlbik7CgpIYXNoUmV0dXJuIEZpbmFsKGhhc2hTdGF0ZSAqc3RhdGUsIEJp dFNlcXVlbmNlICpoYXNodmFsKTsKCkhhc2hSZXR1cm4gSGFzaChpbnQgaGFzaGJpdGxlbiwgY29u c3QgQml0U2VxdWVuY2UgKmRhdGEsCiAgICAgICAgICAgICAgICBEYXRhTGVuZ3RoIGRhdGFiaXRs ZW4sIEJpdFNlcXVlbmNlICpoYXNodmFsKTsKCiNlbmRpZgo= ------=_Part_10579_23760743.1228415398622-- From hash-forum@nist.gov Thu Dec 4 12:47:48 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB4Klg7S030942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Dec 2008 12:47:44 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB4KkgLD028181; Thu, 4 Dec 2008 15:46:47 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB4Kjf3C032060; Thu, 4 Dec 2008 15:45:41 -0500 Date: Thu, 4 Dec 2008 15:45:41 -0500 Message-Id: <49383F11.1040900@nist.gov> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Sara Caswell To: Multiple recipients of list Subject: NIST announces First SHA-3 Candidate Conference X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1 MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 04 Dec 2008 12:47:44 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-5.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, MIME_HTML_ONLY,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk $Forwarded X-UID: 277
NIST is pleased to announce plans for the First SHA-3 Candidate Conference to be held February 25-28, 2009 in Leuven, Belgium.  Complete details on the Conference can be found at http://www.nist.gov/hash-competition. 

First round candidates will be posted shortly. From hash-forum@nist.gov Thu Dec 4 13:15:25 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB4LFKlD001415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Dec 2008 13:15:21 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB4LEKOI017938; Thu, 4 Dec 2008 16:14:25 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB4LDpEd023849; Thu, 4 Dec 2008 16:13:51 -0500 Date: Thu, 4 Dec 2008 16:13:51 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Dmitry Khovratovich" To: Multiple recipients of list Subject: Re: Improved CubeHash analysis X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: Content-Type: multipart/alternative; boundary="----=_Part_9371_30768868.1228424802349" MIME-Version: 1.0 In-Reply-To: X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 04 Dec 2008 13:15:21 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED,URI_HEX shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 278 ------=_Part_9371_30768868.1228424802349 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Is it possible to find a message block to be injected such that the internal state after the 10-rounds transform has some non-trivial properties (say, the first byte =0)? If so, one can run a faster MITM attack. On Thu, Dec 4, 2008 at 3:18 PM, Jean-Philippe Aumasson < jeanphilippe.aumasson@gmail.com> wrote: > > Dear all, > > We have improved our differential technique to detect nonrandomness > over the CubeHash transform: we now reach 10 rounds, against 8 rounds > previously. > > This doesn't seem to affect the security of CubeHash (the submitted > versions make 80 finalization rounds). > > The revised paper is available here: > http://www.131002.net/data/papers/AMNP08.pdf > > > Best, > JP > > -- Best regards, Dmitry Khovratovich University of Luxembourg, Laboratory of Algorithms, Cryptography and Security, + 352 46 66 44 5478 ------=_Part_9371_30768868.1228424802349 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Is it possible to find a message block to be injected such that the internal state after the 10-rounds transform has some non-trivial properties (say, the first byte =0)?

If so, one can run a faster MITM attack.

On Thu, Dec 4, 2008 at 3:18 PM, Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com> wrote:

Dear all,

We have improved our differential technique to detect nonrandomness
over the CubeHash transform: we now reach 10 rounds, against 8 rounds
previously.

This doesn't seem to affect the security of CubeHash (the submitted
versions make 80 finalization rounds).

The revised paper is available here:
http://www.131002.net/data/papers/AMNP08.pdf


Best,
JP




--
Best regards,
Dmitry Khovratovich

University of Luxembourg,
Laboratory of Algorithms, Cryptography and Security,
+ 352 46 66 44 5478
------=_Part_9371_30768868.1228424802349-- From hash-forum@nist.gov Thu Dec 4 17:06:49 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB516iOt026658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Dec 2008 17:06:45 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB515cjv009975; Thu, 4 Dec 2008 20:05:43 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB514hHx021240; Thu, 4 Dec 2008 20:04:43 -0500 Date: Thu, 4 Dec 2008 20:04:43 -0500 Message-Id: <20081205010025.93058.qmail@cr.yp.to> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "D. J. Bernstein" To: Multiple recipients of list Subject: Re: Collision for CubeHash2/120-512 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas In-Reply-To: X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 04 Dec 2008 17:06:45 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 279 Thanks! People who want to hash at 0.4 cycles/byte will have to switch from CubeHash2/120 to CubeHash1/60. :-) Do you think you can use the same techniques to obtain fast collisions in, e.g., CubeHash1/104? ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago From hash-forum@nist.gov Thu Dec 4 15:44:59 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB4Nisoq017711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Dec 2008 15:44:55 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB4Ni5xp018600; Thu, 4 Dec 2008 18:44:09 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB4Ngo8w027053; Thu, 4 Dec 2008 18:42:50 -0500 Date: Thu, 4 Dec 2008 18:42:50 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Jean-Philippe Aumasson" To: Multiple recipients of list Subject: Re: Improved CubeHash analysis X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 In-Reply-To: X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 04 Dec 2008 15:44:56 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.2 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED,URI_HEX shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 280 On Thu, Dec 4, 2008 at 10:13 PM, Dmitry Khovratovich wrote: > Is it possible to find a message block to be injected such that the internal > state after the 10-rounds transform has some non-trivial properties (say, > the first byte =0)? > Seems difficult. The best we could get on the 10-round transform is detecting biases when a large fraction of the input is fixed, and 32 bits are varying. > If so, one can run a faster MITM attack. > > On Thu, Dec 4, 2008 at 3:18 PM, Jean-Philippe Aumasson > wrote: >> >> Dear all, >> >> We have improved our differential technique to detect nonrandomness >> over the CubeHash transform: we now reach 10 rounds, against 8 rounds >> previously. >> >> This doesn't seem to affect the security of CubeHash (the submitted >> versions make 80 finalization rounds). >> >> The revised paper is available here: >> http://www.131002.net/data/papers/AMNP08.pdf >> >> >> Best, >> JP >> > > > > -- > Best regards, > Dmitry Khovratovich > > University of Luxembourg, > Laboratory of Algorithms, Cryptography and Security, > + 352 46 66 44 5478 > From hash-forum@nist.gov Fri Dec 5 00:06:50 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB586jod030454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 Dec 2008 00:06:46 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB585OXP019953; Fri, 5 Dec 2008 03:05:28 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB583n0f009467; Fri, 5 Dec 2008 03:03:49 -0500 Date: Fri, 5 Dec 2008 03:03:49 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Jean-Philippe Aumasson" To: Multiple recipients of list Subject: On Vortex' security X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 05 Dec 2008 00:06:47 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, URI_HEX shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 281 Dear all, The following note reports some results on the Vortex hash function(s): http://www.131002.net/data/papers/AD08.pdf Best, JP and Orr From hash-forum@nist.gov Fri Dec 5 00:47:25 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB58lKoL001002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 Dec 2008 00:47:21 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB58jso0019029; Fri, 5 Dec 2008 03:45:59 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB58jall023005; Fri, 5 Dec 2008 03:45:36 -0500 Date: Fri, 5 Dec 2008 03:45:36 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Jean-Philippe Aumasson" To: Multiple recipients of list Subject: Re: Collision for CubeHash2/120-512 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <20081205010025.93058.qmail@cr.yp.to> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 In-Reply-To: <20081205010025.93058.qmail@cr.yp.to> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 05 Dec 2008 00:47:21 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 282 Seems that a same method finds collisions on CubeHash1/106. This is because one can reach the difference 0x80000000 in x7 (and zero difference in other xi's) after one round, by putting nonzero differences only in the first 106 bytes. On CubeHash2, I just found that another differential gives collisions for CubeHash2/114: instead of reaching a difference in x16, one reaches a difference in x17, which only requires nonzero input difference in the first 114 bytes (instead of 120 bytes with x16) On Fri, Dec 5, 2008 at 2:04 AM, D. J. Bernstein wrote: > > Thanks! People who want to hash at 0.4 cycles/byte will have to switch > from CubeHash2/120 to CubeHash1/60. :-) Do you think you can use the > same techniques to obtain fast collisions in, e.g., CubeHash1/104? > > ---D. J. Bernstein > Research Professor, Computer Science, University of Illinois at Chicago > > From koc@letters.cs.ucsb.edu Sat Dec 6 12:01:40 2008 -0800 Return-Path: Received: from localhost by uxc with LMTP for ; Sat, 06 Dec 2008 12:01:42 -0800 Received: from uxc.isc.ucsb.edu with LMTP by uxc (2.0.6/sieved-2-0-build-559) for ; Sat, 6 Dec 2008 12:01:42 -0800 Received: from smtp.sa.ucsb.edu (safw1173e.sa.ucsb.edu [128.111.173.2]) by uxc.isc.ucsb.edu (Switch-3.1.8/Switch-3.1.7) with ESMTP id mB6K1fLu011349 for ; Sat, 6 Dec 2008 12:01:41 -0800 (PST) Received: from sa44 (10.4.44.1) by smtprelay.sa.ucsb.edu (10.4.17.2) with Microsoft SMTP Server id 8.1.291.1; Sat, 6 Dec 2008 12:01:40 -0800 thread-index: AclX3XQqwh9YvhbEQkayaZEUySym1w== Thread-Topic: CMPSCCS 130H, 08771 Submitted to Registrar From: To: CC: Subject: CMPSCCS 130H, 08771 Submitted to Registrar Date: Sat, 6 Dec 2008 12:01:40 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft CDO for Windows 2000 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 X-Scanned-By: MIMEDefang 2.58 on 128.111.125.200 Status: RO X-Status: X-Keywords: NonJunk X-UID: 283 Cetin Koc, You have successfully submitted grades for CMPSCCS 130H ADV TOPICS CMPSC Enroll Code: 08771 Meeting Times: T 6:00- 9:00 494 143 Fall 2008 You will not be receiving a Course Report for this course. You can login again at anytime if you wish to review the grades that were submitted to the Registrar. There are courses for which you are the 'instructor in charge', that have not been submitted and thus require your attention. You can login to eGrades ( www.egrades.sa.ucsb.edu ) to view each course and its status and submit grades for those courses that have not yet been completed. The last day to submit grades for this period is: 12/17/2008 Regards eGrades The Office of the Registrar From hash-forum@nist.gov Sun Dec 7 13:40:23 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB7LeHIw012457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 7 Dec 2008 13:40:18 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB7KMsu8014945; Sun, 7 Dec 2008 15:22:58 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB7KL9M3022752; Sun, 7 Dec 2008 15:21:10 -0500 Date: Sun, 7 Dec 2008 15:21:09 -0500 Message-Id: <493C2D62.1070604@ugd.edu.mk> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Aleksandra Mileva To: Multiple recipients of list Subject: About free-start collision on NaSHA X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8"; format=flowed MIME-Version: 1.0 X-To: Multiple recipients of list X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: Delayed for 01:16:09 by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sun, 07 Dec 2008 13:40:19 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 284 Dear Ivica and Dmitry, we could not follow the arguments given in your attack against our NIST SHA-3 proposal NaSHA. Since your attack is of complexity 2^{32}, you should need no more than 1 hour for performing the attack on 1GHz PC. We are expecting of you, soon to present example of free-collision attack. If you, or someone else, cannot supply such an example, then you should announce that you withdraw your paper. Regards, S. Markovski and A. Mileva From hash-forum@nist.gov Tue Dec 9 15:43:20 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mB9NhE5u027149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Dec 2008 15:43:16 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB9Ng8Zs014859; Tue, 9 Dec 2008 18:42:12 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB9Nflnp032141; Tue, 9 Dec 2008 18:41:47 -0500 Date: Tue, 9 Dec 2008 18:41:47 -0500 Message-Id: <20081209233657.04b13941@gamma> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Brandon Enright To: Multiple recipients of list Subject: Re: Engineering comparison of the SHA-3 candidates X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=US-ASCII Mime-Version: 1.0 X-Mailer: Claws Mail 3.6.1 (GTK+ 2.12.11; x86_64-pc-linux-gnu) References: <888E37A2001E364CBC4F28FA7660A2E65E26A86F26@NA-EXMSG-C102.redmond.corp.microsoft.com> In-Reply-To: <888E37A2001E364CBC4F28FA7660A2E65E26A86F26@NA-EXMSG-C102.redmond.corp.microsoft.com> X-Cc: niels@microsoft.com, bmenrigh@ucsd.edu X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: Delayed for 00:33:29 by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 09 Dec 2008 15:43:16 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: $Forwarded X-UID: 285 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 9 Dec 2008 17:59:26 -0500 Niels Ferguson wrote: > The Skein team has been working on an engineering comparison of the > SHA-3 candidate algorithms. Our results are available at > > http://www.skein-hash.info/sha3-engineering > Hi Niels, I look forward to looking at this page more. I noticed you have Spectral Hash listed as broken because of the near collisions work I did. The authors of Spectral Hash found a couple serious implementation flaws in their release code that I tested with and claim that although the code is broken, the algorithm is not. It isn't clear to me where the bounds of this competition lie in regards to major implementation flaws but Spectral Hash (the algorithm) may not be broken even if Spectral Hash (the implementation) is. Brandon -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkk/AR8ACgkQqaGPzAsl94I9YgCgmCdOJYfd0SeJJhBf01uIUKgI eg4Anivz3W3MiiGEOIaHDh+/JMzoP1fg =gUK1 -----END PGP SIGNATURE----- From hash-forum@nist.gov Tue Dec 9 16:30:36 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBA0UUbV031831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Dec 2008 16:30:32 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB9N1Rsu028065; Tue, 9 Dec 2008 18:01:34 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB9MxQCM014665; Tue, 9 Dec 2008 17:59:26 -0500 Date: Tue, 9 Dec 2008 17:59:26 -0500 Message-Id: <888E37A2001E364CBC4F28FA7660A2E65E26A86F26@NA-EXMSG-C102.redmond.corp.microsoft.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Niels Ferguson To: Multiple recipients of list Subject: Engineering comparison of the SHA-3 candidates X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_888E37A2001E364CBC4F28FA7660A2E65E26A86F26NAEXMSGC102re_" X-To: "hash-forum@nist.gov" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 09 Dec 2008 16:30:32 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 286 --_000_888E37A2001E364CBC4F28FA7660A2E65E26A86F26NAEXMSGC102re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The Skein team has been working on an engineering comparison of the SHA-3 c= andidate algorithms. Our results are available at http://www.skein-hash.info/sha3-engineering This is essentially our rating of the competitors, and we'll use this to ta= rget our analysis efforts on those algorithms that have the best engineerin= g properties. So far we've only done a first ordering based mostly on speed. The current = top 5 algorithms are: Edon-R Blue Midnight Wish Skein SHAMATA Sarmal which all run in less than 10 cycles/byte. We're planning to keep this page up to date as we develop more results. Cheers! Niels Ferguson --_000_888E37A2001E364CBC4F28FA7660A2E65E26A86F26NAEXMSGC102re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The Skein team has been working on an engineering comparison of the SHA-3 candi= date algorithms. Our results are available at

 

http://www.skein-hash.= info/sha3-engineering

 

This is essentially our rating of the competitors, and we'll use this to target = our analysis efforts on those algorithms that have the best engineering propert= ies.

 

So far we've only done a first ordering based mostly on speed. The current top= 5 algorithms are:

 

Edon-R

Blue Midnight Wish

Skein

SHAMATA

Sarmal

 

which all run in less than 10 cycles/byte.

 

We're planning to keep this page up to date as we develop more results.

 

 

Cheers!

 

Niels Ferguson

 

--_000_888E37A2001E364CBC4F28FA7660A2E65E26A86F26NAEXMSGC102re_-- From hash-forum@nist.gov Tue Dec 9 16:30:36 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBA0UUbV031831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Dec 2008 16:30:32 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mB9N1Rsu028065; Tue, 9 Dec 2008 18:01:34 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mB9MxQCM014665; Tue, 9 Dec 2008 17:59:26 -0500 Date: Tue, 9 Dec 2008 17:59:26 -0500 Message-Id: <888E37A2001E364CBC4F28FA7660A2E65E26A86F26@NA-EXMSG-C102.redmond.corp.microsoft.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Niels Ferguson To: Multiple recipients of list Subject: Engineering comparison of the SHA-3 candidates X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_888E37A2001E364CBC4F28FA7660A2E65E26A86F26NAEXMSGC102re_" X-To: "hash-forum@nist.gov" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 09 Dec 2008 16:30:32 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 287 --_000_888E37A2001E364CBC4F28FA7660A2E65E26A86F26NAEXMSGC102re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The Skein team has been working on an engineering comparison of the SHA-3 c= andidate algorithms. Our results are available at http://www.skein-hash.info/sha3-engineering This is essentially our rating of the competitors, and we'll use this to ta= rget our analysis efforts on those algorithms that have the best engineerin= g properties. So far we've only done a first ordering based mostly on speed. The current = top 5 algorithms are: Edon-R Blue Midnight Wish Skein SHAMATA Sarmal which all run in less than 10 cycles/byte. We're planning to keep this page up to date as we develop more results. Cheers! Niels Ferguson --_000_888E37A2001E364CBC4F28FA7660A2E65E26A86F26NAEXMSGC102re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The Skein team has been working on an engineering comparison of the SHA-3 candi= date algorithms. Our results are available at

 

http://www.skein-hash.= info/sha3-engineering

 

This is essentially our rating of the competitors, and we'll use this to target = our analysis efforts on those algorithms that have the best engineering propert= ies.

 

So far we've only done a first ordering based mostly on speed. The current top= 5 algorithms are:

 

Edon-R

Blue Midnight Wish

Skein

SHAMATA

Sarmal

 

which all run in less than 10 cycles/byte.

 

We're planning to keep this page up to date as we develop more results.

 

 

Cheers!

 

Niels Ferguson

 

--_000_888E37A2001E364CBC4F28FA7660A2E65E26A86F26NAEXMSGC102re_-- From hash-forum@nist.gov Tue Dec 9 17:45:11 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBA1j56d007366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Dec 2008 17:45:07 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBA1i0kS011691; Tue, 9 Dec 2008 20:44:05 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBA1gpkx006310; Tue, 9 Dec 2008 20:42:51 -0500 Date: Tue, 9 Dec 2008 20:42:51 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Adam Montville To: Multiple recipients of list Subject: Re: Engineering comparison of the SHA-3 candidates X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.929.2) References: <888E37A2001E364CBC4F28FA7660A2E65E26A86F26@NA-EXMSG-C102.redmond.corp.microsoft.com> <20081209233657.04b13941@gamma> In-reply-to: <20081209233657.04b13941@gamma> X-To: hash-forum@nist.gov Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 09 Dec 2008 17:45:07 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 288 On Dec 9, 2008, at 3:41 PM, Brandon Enright wrote: > > > It isn't clear to me where the bounds of this competition lie in > regards to major implementation flaws but Spectral Hash (the > algorithm) > may not be broken even if Spectral Hash (the implementation) is. > This may have already been (exhaustively?) discussed on this list, but it would seem to me that the competition is about finding candidate algorithms, not candidate reference implementations. Therefore, entrants should be judged based on the submitted algorithm more than on the submitted reference implementation. While it is true that a reference implementation is exactly that, it's also arguable that most reference implementations are not necessarily destined for production, but are intended instead to be instructional. A flawed reference implementation is unfortunate, but should not necessarily preclude an entry from the competition. Adam From hash-forum@nist.gov Tue Dec 9 18:39:24 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBA2dJuh013206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Dec 2008 18:39:20 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBA2cOXk002957; Tue, 9 Dec 2008 21:38:30 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBA2bQ5Z013822; Tue, 9 Dec 2008 21:37:26 -0500 Date: Tue, 9 Dec 2008 21:37:26 -0500 Message-Id: <59478074-53C6-4DA3-8DED-E47D54E7A332@uni-weimar.de> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Michael Gorski To: Multiple recipients of list Subject: X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.929.2) X-Cc: Michael Gorski Mime-Version: 1.0 (Apple Message framework v929.2) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 09 Dec 2008 18:39:20 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,MISSING_SUBJECT, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 289 Hi, Ewan Fleischmann, Christian Forler and myself have published a classification of the SHA-3 candidates. We will update the paper at least once a week. You can find it on the SHA-3 Zoo page: http://ehash.iaik.tugraz.at/wiki/The_SHA-3_Zoo or if you follow this link: http://www.uni-weimar.de/cms/fileadmin/medien/medsicherheit/Research/SHA3/Classification_of_the_SHA-3_Candidates.pdf Regards, Michael ------------------------------------------------------- Michael Gorski Bauhaus-University Weimar, Germany michael.gorski@uni-weimar.de From hash-forum@nist.gov Tue Dec 9 19:40:57 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBA3epDT018621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Dec 2008 19:40:52 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBA3WCDc016080; Tue, 9 Dec 2008 22:32:17 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBA3VfKd022412; Tue, 9 Dec 2008 22:31:41 -0500 Date: Tue, 9 Dec 2008 22:31:41 -0500 Message-Id: <104515.64745.qm@web36407.mail.mud.yahoo.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Peter To: Multiple recipients of list Subject: Re:Classification of the SHA-3 candidates X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/alternative; boundary="0-466805348-1228879677=:64745" MIME-Version: 1.0 In-Reply-To: <59478074-53C6-4DA3-8DED-E47D54E7A332@uni-weimar.de> X-To: hash-forum@nist.gov X-Mailer: YahooMailWebService/0.7.260.1 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 09 Dec 2008 19:40:52 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-4.1 required=5.0 tests=AWL,BAYES_00, FORGED_YAHOO_RCVD,HTML_MESSAGE,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 290 --0-466805348-1228879677=:64745 Content-Type: text/plain; charset=us-ascii I believe there may be a mistake in the paper (in the second link). It lists Ponic (my algorithm) at 7.2 - 3.2 cycles per byte, and therefore in your "A" class. The best results I got were far far slower, certainly in the "E" class, at over 81 cycles per byte. Perhaps you mistook the commas in my figures for decimal points? Or have others run benchmarks on my algorithm and gotten better results? (P.S. I have improved from the speed given in the specification, and the laughable 3,000-3,500 cycles/byte speed listed is far out of date anyway.) --- On Tue, 12/9/08, Michael Gorski wrote: From: Michael Gorski Subject: To: "Multiple recipients of list" Date: Tuesday, December 9, 2008, 9:37 PM Hi, Ewan Fleischmann, Christian Forler and myself have published a classification of the SHA-3 candidates. We will update the paper at least once a week. You can find it on the SHA-3 Zoo page: http://ehash.iaik.tugraz.at/wiki/The_SHA-3_Zoo or if you follow this link: http://www.uni-weimar.de/cms/fileadmin/medien/medsicherheit/Research/SHA3/Classification_of_the_SHA-3_Candidates.pdf Regards, Michael ------------------------------------------------------- Michael Gorski Bauhaus-University Weimar, Germany michael.gorski@uni-weimar.de --0-466805348-1228879677=:64745 Content-Type: text/html; charset=us-ascii
I believe there may be a mistake in the paper (in the second link). It lists Ponic (my algorithm) at 7.2 - 3.2 cycles per byte, and therefore in your "A" class. The best results I got were far far slower, certainly in the "E" class, at over 81 cycles per byte. Perhaps you mistook the commas in my figures for decimal points? Or have others run benchmarks on my algorithm and gotten better results?

(P.S. I have improved from the speed given in the specification, and the laughable 3,000-3,500 cycles/byte speed listed is far out of date anyway.)

--- On Tue, 12/9/08, Michael Gorski <michael.gorski@uni-weimar.de> wrote:
From: Michael Gorski <michael.gorski@uni-weimar.de>
Subject:
To: "Multiple recipients of list" <hash-forum@nist.gov>
Date: Tuesday, December 9, 2008, 9:37 PM

Hi,

Ewan Fleischmann, Christian Forler and myself have published a classification
of the SHA-3 candidates. We will update the paper at least once a week.

You can find it on the SHA-3 Zoo page:

http://ehash.iaik.tugraz.at/wiki/The_SHA-3_Zoo

or if you follow this
 link:

http://www.uni-weimar.de/cms/fileadmin/medien/medsicherheit/Research/SHA3/Classification_of_the_SHA-3_Candidates.pdf


Regards,
Michael

-------------------------------------------------------

Michael Gorski
Bauhaus-University Weimar, Germany
michael.gorski@uni-weimar.de

--0-466805348-1228879677=:64745-- From hash-forum@nist.gov Tue Dec 9 20:14:01 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBA4DsOj021567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Dec 2008 20:13:55 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBA4Cvga027529; Tue, 9 Dec 2008 23:13:01 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBA4CHlN004031; Tue, 9 Dec 2008 23:12:17 -0500 Date: Tue, 9 Dec 2008 23:12:17 -0500 Message-Id: <493F3F79.60706@mit.edu> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Ronald L. Rivest" To: Multiple recipients of list Subject: Re: Engineering comparison of the SHA-3 candidates X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: <888E37A2001E364CBC4F28FA7660A2E65E26A86F26@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <888E37A2001E364CBC4F28FA7660A2E65E26A86F26@NA-EXMSG-C102.redmond.corp.microsoft.com> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 09 Dec 2008 20:13:55 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 291 Nice "looking under the lamppost" chart... Of course, each designer gets to pick his own lamppost(s) ... :-) (even if one is focussed on engineering...) My first lamppost would shine light on those designs that take advantage of the forthcoming flood of multicore processors, rather than the proposed 64-bit unicore lamppost (you may not be even able to buy 64-bit unicore processors soon!). Probably most of the tree-based designs will be able to saturate memory bandwidth with a reasonable number of cores. The sequential (e.g. Merkle-Damgard) designs will be stuck in low gear with no way to speed up... My second lamppost would be for submitted designs that offer reasonable security proofs for their mode of operation and for their compression function. While some of "proof-less" designs (i.e. designs submitted without much in the way of proofs) may turn out to be secure, the burden should be (or should have been) on the designers first of all to supply the relevant proofs. Your lampposts may vary... Cheers, Ron On 12/9/2008 6:01 PM, Niels Ferguson wrote: > The Skein team has been working on an engineering comparison of the > SHA-3 candidate algorithms. Our results are available at > > > > http://www.skein-hash.info/sha3-engineering > > > > This is essentially our rating of the competitors, and we'll use this to > target our analysis efforts on those algorithms that have the best > engineering properties. > > > > So far we've only done a first ordering based mostly on speed. The > current top 5 algorithms are: > > > > Edon-R > > Blue Midnight Wish > > Skein > > SHAMATA > > Sarmal > > > > which all run in less than 10 cycles/byte. > > > > We're planning to keep this page up to date as we develop more results. > > > > > > Cheers! > > > > Niels Ferguson > > > -- Ronald L. Rivest Room 32-G692, Stata Center, MIT, Cambridge MA 02139 Tel 617-253-5880, Email From hash-forum@nist.gov Tue Dec 9 23:09:18 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBA79DIt005392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Dec 2008 23:09:14 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBA7881w012268; Wed, 10 Dec 2008 02:08:10 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBA76rMG020592; Wed, 10 Dec 2008 02:06:54 -0500 Date: Wed, 10 Dec 2008 02:06:53 -0500 Message-Id: <20081210070838.34969.qmail@cr.yp.to> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "D. J. Bernstein" To: Multiple recipients of list Subject: Re: Engineering comparison of the SHA-3 candidates X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas In-Reply-To: <888E37A2001E364CBC4F28FA7660A2E65E26A86F26@NA-EXMSG-C102.redmond.corp.microsoft.com> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 09 Dec 2008 23:09:14 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 292 Niels Ferguson writes: > So far we've only done a first ordering based mostly on speed. Speed of what, exactly? Let's try three illustrative examples from your "engineering comparison": * You rate your own Skein-512 as "good": 6.1 cycles/byte (on a Core 2 in 64-bit mode), apparently in 200 bytes of RAM. * You rate MD6-256 as "fair": 28 cycles/byte using "memory >700 B". * You rate CubeHash---I guess you mean CubeHash8/1---as "poor"; 160 cycles/byte, 128 bytes of RAM. Now let's see what happens when we vary the tunable security parameter specified in the submissions: * Skein-512: Your submission says that there's some sort of attack on "25 of 72" rounds. This means that the minimal unbroken variant has 26 rounds, presumably running at 2.2 cycles/byte. * MD6-256: The documentation reports an attack by Aumasson on 18 out of 104 rounds. This means that the minimal unbroken variant has 19 rounds, presumably running at 5.1 cycles/byte. * CubeHash: Aumasson reports that he has found collisions in CubeHash1/106 and CubeHash2/114. The minimal unbroken variant is CubeHash1/105, presumably running at 0.2 cycles/byte. One can reasonably object to the comparison between 2.2 cycles/byte and 0.2 cycles/byte. Surely collisions will be found in CubeHash1/105 and many other functions, increasing the minimal unbroken cycle counts. Furthermore, the 25-round attack on Skein doesn't appear to be a real collision attack; any reasonable definition of "break" will allow Skein to survive with fewer rounds, if attacks _don't_ improve. On the other hand, 10x is quite a lot of ground to make up! It seems entirely possible that, after careful analysis, we'll see that CubeHash and MD6 and many other families of SHA-3 submissions are achieving security at higher speed than Skein---exactly the opposite of what your "engineering comparison" suggests. Ronald L. Rivest writes: > My first lamppost would shine light on those designs that > take advantage of the forthcoming flood of multicore processors What's an example of a design that _can't_ take advantage of multicore processors? Here's what my submission said: "The advantage of a tree is that it allows very long messages to be split across several processor cores--- but the applications that care can achieve the same benefit by building a tree on top of CubeHash, the same way that they have traditionally built a tree on top of SHA-256. (Similar comments apply to incremental hashing etc.)" Wikipedia says "Tiger tree hashes are used in the Gnutella, Gnutella2, and Direct Connect P2P file sharing protocols and in file sharing applications such as Phex, BearShare, LimeWire, Shareaza, DC++ and Valknut." Tiger wasn't designed to take advantage of multiple cores, but this doesn't pose any problems for applications. > My second lamppost would be for submitted designs that > offer reasonable security proofs for their mode of operation > and for their compression function. While some of "proof-less" > designs (i.e. designs submitted without much in the way of proofs) > may turn out to be secure, the burden should be (or should have been) > on the designers first of all to supply the relevant proofs. There's a counterargument that I'd like to quote here for the record: "Provable security" can be a helpful guide to cryptanalysis, allowing cryptanalysts to focus their energies on the potentially breakable components of a hash function. For example, most hash functions are built as modes of operation of compression functions; a sufficiently powerful security proof for a mode of operation lets cryptanalysts focus on the compression function, confident that the mode per se has no problems. Building confidence in the hash function then boils down to building confidence in the compression function, hopefully a simpler task. CubeHash takes a different approach to building confidence: the entire hash function is very simple and easy to understand, in fact simpler than most compression functions. CubeHash is not built from a lower-level primitive, so there are no reduction proofs, but I don't see this as a disadvantage; the real question is not how much work the cryptanalyst can skip, but how much work the cryptanalyst still has to do. An extremely complicated function with a mountain of proofs is probably better for the cryptanalyst than an extremely complicated function with no proofs at all, but surely much worse than a simple function. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago From hash-forum@nist.gov Wed Dec 10 06:52:21 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBAEqG2x023222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Dec 2008 06:52:17 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBAEg7pB022424; Wed, 10 Dec 2008 09:42:12 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBAEeXXq021920; Wed, 10 Dec 2008 09:40:33 -0500 Date: Wed, 10 Dec 2008 09:40:33 -0500 Message-Id: <20081210142957.GA20826@titan.cry.pto> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Thomas Pornin To: Multiple recipients of list Subject: Re: Engineering comparison of the SHA-3 candidates X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas In-Reply-To: <493F3F79.60706@mit.edu> Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 References: <888E37A2001E364CBC4F28FA7660A2E65E26A86F26@NA-EXMSG-C102.redmond.corp.microsoft.com> <493F3F79.60706@mit.edu> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 10 Dec 2008 06:52:17 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 293 On Tue, Dec 09, 2008 at 11:12:17PM -0500, Ronald L. Rivest wrote: > My first lamppost would shine light on those designs that > take advantage of the forthcoming flood of multicore > processors, rather than the proposed 64-bit unicore lamppost > (you may not be even able to buy 64-bit unicore processors soon!). I don't think that there is an issue about performance of hash functions on PC (or similar systems), unless you get to the really slow functions such as Whirlpool. A single core system, using a not-so-fast function (e.g. SHA-256), will hash data faster than what the network or harddisk may eat. Rather, if there is a performance issue, then it is more related to L1 cache size than cycles-per-byte. That's an often overlooked issue: we do not hash data only for the sake of it. Data is hashed as part of a wider process, and the hash function is only a part of the code which is touched by the processor in the critical execution path. This means that the hash function must share the number 1 scarce resource, that is the L1 caches. Usual benchmarks do not take this into account, they run the function "alone". In a practical situation, the function code and the function data should not use more than a fraction of the data and code L1 caches. For the data cache, this includes the size of the function state, but also the constant tables, if its implementation is table-driven. A "modern" PC will offer about 64 KB of data cache and about as much of code cache, but a good function should use no more (and preferably much less) than, say, 10 or 12 KB of each. In my view, under my own lampost if you prefer, these cache issues are much more plausible candidates for performance problems on nowadays PC than raw cycles per byte counts in ideal benchmark conditions. Yet the PC is not a good example of a platform where hash functions have performance issues. Researchers use benchmark on what they have, i.e. workstations (mostly x86 running Windows, Linux or MacOS, but some Sparc users may still strive somewhere). But some other architectures are more "industrially significant". I am thinking about cell phones, network and WiFi routers, MP3 players, digital cameras... all those devices which have severe operational limitations (including power consumption or size), some of which being involved in cryptography all day long. These systems use primarily ARM and MiPS processors. They have a single core each(*). They are clocked at a few dozen or hundred megahertz at most. Those systems have real performance issues with cryptography. And, guess what, it turns out that the biggest performance killer on those systems is cache overflow. I own a Linksys router which I have reflashed with OpenWRT (a Linux variant) so that I could bench hash function implementations. I believe it is quite representative of the class of hardware I am talking about. It features a MiPS core clocked at 200 MHz. The L1 cache for code does not exceed 8 KB; this means that any hash function which code exceeds that size will suffer heavy penalties even in ideal benchmark conditions. E.g. a SHA-256 implementation with full loop unrolling (a common implementation design) will hash about 1.8 MB/s on that system. By using only partial unrolling, which fortunately is feasible with SHA-256, bandwidth goes up to almost 3 MB/s. And that is still not very fast. What these figures show is that there exist plateforms which are widely used, and which need fast cryptographic functions, and these systems are NOT the everyday multi-core x86 PC. And what matters most for performance on such systems is whether the function may be implemented within the restrained cache sizes that these platform provide, rather than the cycles per bytes which are achieved on huge systems with plenty of cache dedicated to the sole function. (The RadioGatun function, for instance, is really not easy to implement with only partial unrolling. The hardware I am talking about is also quite bad at arithmetic operations on words beyond 32 bits, hence SHA-512 and other 64-bit functions are very slow on such systems.) --Thomas Pornin (*) At least some of the iPod models feature two ARM cores. From hash-forum@nist.gov Wed Dec 10 07:38:29 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBAFcOGs028071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Dec 2008 07:38:25 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBAFaxab006474; Wed, 10 Dec 2008 10:37:05 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBAFaS57012546; Wed, 10 Dec 2008 10:36:28 -0500 Date: Wed, 10 Dec 2008 10:36:28 -0500 Message-Id: <493FE1D1.90101@mit.edu> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Ronald L. Rivest" To: Multiple recipients of list Subject: [Fwd: Re: Engineering comparison of the SHA-3 candidates] X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 10 Dec 2008 07:38:25 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 294 Dan Bernstein says, "The real question is not how much work the cryptanalyst can skip, but how much work the cryptanalyst still has to do." In my classes, work not done gets no points; only completed work gets points. At the end of the day, the SHA-3 candidates should be judged on what has been done. Of course, I agree with your support for simpler schemes, as simplicity tends to make analysis and proofs easier. Cheers, Ron -------- Original Message -------- Subject: Re: Engineering comparison of the SHA-3 candidates Date: Wed, 10 Dec 2008 02:08:03 -0500 From: D. J. Bernstein Reply-To: hash-forum@nist.gov To: Multiple recipients of list Niels Ferguson writes: > So far we've only done a first ordering based mostly on speed. Speed of what, exactly? Let's try three illustrative examples from your "engineering comparison": * You rate your own Skein-512 as "good": 6.1 cycles/byte (on a Core 2 in 64-bit mode), apparently in 200 bytes of RAM. * You rate MD6-256 as "fair": 28 cycles/byte using "memory >700 B". * You rate CubeHash---I guess you mean CubeHash8/1---as "poor"; 160 cycles/byte, 128 bytes of RAM. Now let's see what happens when we vary the tunable security parameter specified in the submissions: * Skein-512: Your submission says that there's some sort of attack on "25 of 72" rounds. This means that the minimal unbroken variant has 26 rounds, presumably running at 2.2 cycles/byte. * MD6-256: The documentation reports an attack by Aumasson on 18 out of 104 rounds. This means that the minimal unbroken variant has 19 rounds, presumably running at 5.1 cycles/byte. * CubeHash: Aumasson reports that he has found collisions in CubeHash1/106 and CubeHash2/114. The minimal unbroken variant is CubeHash1/105, presumably running at 0.2 cycles/byte. One can reasonably object to the comparison between 2.2 cycles/byte and 0.2 cycles/byte. Surely collisions will be found in CubeHash1/105 and many other functions, increasing the minimal unbroken cycle counts. Furthermore, the 25-round attack on Skein doesn't appear to be a real collision attack; any reasonable definition of "break" will allow Skein to survive with fewer rounds, if attacks _don't_ improve. On the other hand, 10x is quite a lot of ground to make up! It seems entirely possible that, after careful analysis, we'll see that CubeHash and MD6 and many other families of SHA-3 submissions are achieving security at higher speed than Skein---exactly the opposite of what your "engineering comparison" suggests. Ronald L. Rivest writes: > My first lamppost would shine light on those designs that > take advantage of the forthcoming flood of multicore processors What's an example of a design that _can't_ take advantage of multicore processors? Here's what my submission said: "The advantage of a tree is that it allows very long messages to be split across several processor cores--- but the applications that care can achieve the same benefit by building a tree on top of CubeHash, the same way that they have traditionally built a tree on top of SHA-256. (Similar comments apply to incremental hashing etc.)" Wikipedia says "Tiger tree hashes are used in the Gnutella, Gnutella2, and Direct Connect P2P file sharing protocols and in file sharing applications such as Phex, BearShare, LimeWire, Shareaza, DC++ and Valknut." Tiger wasn't designed to take advantage of multiple cores, but this doesn't pose any problems for applications. > My second lamppost would be for submitted designs that > offer reasonable security proofs for their mode of operation > and for their compression function. While some of "proof-less" > designs (i.e. designs submitted without much in the way of proofs) > may turn out to be secure, the burden should be (or should have been) > on the designers first of all to supply the relevant proofs. There's a counterargument that I'd like to quote here for the record: "Provable security" can be a helpful guide to cryptanalysis, allowing cryptanalysts to focus their energies on the potentially breakable components of a hash function. For example, most hash functions are built as modes of operation of compression functions; a sufficiently powerful security proof for a mode of operation lets cryptanalysts focus on the compression function, confident that the mode per se has no problems. Building confidence in the hash function then boils down to building confidence in the compression function, hopefully a simpler task. CubeHash takes a different approach to building confidence: the entire hash function is very simple and easy to understand, in fact simpler than most compression functions. CubeHash is not built from a lower-level primitive, so there are no reduction proofs, but I don't see this as a disadvantage; the real question is not how much work the cryptanalyst can skip, but how much work the cryptanalyst still has to do. An extremely complicated function with a mountain of proofs is probably better for the cryptanalyst than an extremely complicated function with no proofs at all, but surely much worse than a simple function. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago -- Ronald L. Rivest Room 32-G692, Stata Center, MIT, Cambridge MA 02139 Tel 617-253-5880, Email From hash-forum@nist.gov Wed Dec 10 10:09:13 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBAI97pY015622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Dec 2008 10:09:08 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBAI82YJ029578; Wed, 10 Dec 2008 13:08:06 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBAI6F0L031867; Wed, 10 Dec 2008 13:06:15 -0500 Date: Wed, 10 Dec 2008 13:06:15 -0500 Message-Id: <8106B4D6-F26E-465E-9D03-ACFEB71B6922@zooko.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: zooko To: Multiple recipients of list Subject: the importance of 32-bit CPUs (was: Engineering comparison of the SHA-3 candidates) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: <888E37A2001E364CBC4F28FA7660A2E65E26A86F26@NA-EXMSG-C102.redmond.corp.microsoft.com> <493F3F79.60706@mit.edu> <20081210142957.GA20826@titan.cry.pto> In-Reply-To: <20081210142957.GA20826@titan.cry.pto> Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 10 Dec 2008 10:09:09 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED,WHOIS_NETSOLPR shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 295 Thanks for writing the engineering comparison page, Niels Ferguson & company. Thanks for the thoughtful post on embedded systems, Thomas Porrin. I recently blogged some notes on the topic. Here is the blog entry I wrote. For context, I am not a submitter of a SHA-3 candidate, but am participating on this list as a user of secure hash functions who hopes that SHA-3 will satisfy my projects' needs. I use secure hash functions a lot, both for cryptography and for integrity checking and identification of bulk data in my secure peer-to-peer filesystem. --- blog entry, 2008-11-26: SHA-3 benchmarks and the importance of 32- bit CPUs This morning I perused the current benchmark results [1] for the SHA-3 contest; (Note that only a few of the SHA-3 candidates have yet been benchmarked -- the vast majority of them have yet to appear on these graphs.) Here are the graphs on a powerful modern 64-bit Intel chip [2]: edonr512 and bmw512 are actually about as efficient as MD5 -- hooray! But here are the graphs on a 32-bit PowerPC [3]: not so encouraging. Here are the graphs on a 64-bit PowerPC [4]: also not so encouraging. 64-bit PPC is the architecture used in the Sony Playstation 3 and the Microsoft Xbox 360. 32-bit PPC is the architecture used in the Nintendo Wii, which is currently out-selling the other two consoles *combined*. There is a tendency among programmers, who mainly work on PCs, to think of 32-bit architectures as the past and 64-bit as the future. However, if you look at the numbers, it appears that 32-bit chips are becoming more and more common, not less and less. In 2008, about 300 million PCs were shipped [5]. I guesstimate that about half of those, including the new, fast-growing segment of "netbooks" such as OLPC XO and Asus EEE PC, were 32-bit. In the same year, *billions* of 32-bit embedded devices were shipped. The ARM architecture alone shipped 3 billion units in 2008, and other architectures such as MIPS and 32-bit x86 shipped uncounted billions of embedded units. Many of the newest and fastest-growing products such as the iPhone are 32-bit. Rather than dying out, 32-bit CPUs are getting smaller, cheaper, lower-power, and becoming more and more common and important. Back in 1997, during the AES contest, a smart fellow accurately predicted "The lesson of the past 20 years of computing seems to be that while the high end always gets better, the low end never goes away. We're still programming tiny 8-bit microprocessors; instead of being used in desktop computers, they're in cellular phones, automobiles, electrical meters, and smart cards. These processors will be around for a long time to come, in Dick-Tracy-like wristwatch communicators, small affixable processors, [...] and who knows what else (nanotechnology?)." The same appears to be true of the 32-bit architectures. (Other references: that were used in the writing of this article: http://news.cnet.com/8301-13924_3-10076795-64.html , http:// news.cnet.com/8301-10784_3-9902716-7.html , http://landley.net/ols/ ols2007/platforms.txt , http://arstechnica.com/news.ars/post/20081017- september-npd-numbers-star-wars-trumps-flagging-us-economy.html , http://www.shacknews.com/onearticle.x/55644 .) Regards, Zooko [1] http://bench.cr.yp.to/results-hash.html [2] http://bench.cr.yp.to/graph-hash/amd64-nmiv003.png [3] http://bench.cr.yp.to/graph-hash/ppc32-nmi0042.png [4] http://bench.cr.yp.to/graph-hash/ppc64-nmi0055.png [5] http://news.cnet.com/8301-10784_3-9902716-7.html --- http://allmydata.org -- Tahoe, the Least-Authority Filesystem http://allmydata.com -- back up all your files for $10/month From hash-forum@nist.gov Wed Dec 10 10:53:41 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBAIrWJV021189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Dec 2008 10:53:35 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBAIo6hU022130; Wed, 10 Dec 2008 13:50:50 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBAImosb024587; Wed, 10 Dec 2008 13:48:50 -0500 Date: Wed, 10 Dec 2008 13:48:50 -0500 Message-Id: <49400E39.4090702@nist.gov> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Bill Burr To: Multiple recipients of list Subject: SHA-3 First Round Submissions. X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/alternative; boundary="------------000906070503040103070604" MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 10 Dec 2008 10:53:35 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 296 This is a multi-part message in MIME format. --------------000906070503040103070604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit NIST received 64 SHA-3 candidate hash function submissions. Overall, NIST is very pleased with the obvious high quality of many of the submissions, as well as the general range of designs. NIST has accepted 51 first round candidates as meeting our minimum acceptance criteria. They are now posted on the NIST website: . To make an "official" comment on one of the algorithms please use the "submit comments" link on this page for the appropriate algorithm. Such comments will also be forwarded to hash-forum@nist.gov. Continue to post general comments about the competition at hash-forum@nist.gov. We will review these first round candidates at the first SHA-3 Candidate Conference on February 25-28, 2009 at Leuven. During the summer of 2009 we plan to select about 15 second round candidates for more focused review at the Second SHA-3 Candidate Conference, tentatively scheduled for August, 2010. Following that second conference we expect to select about 5 third round candidates (or "finalists"). At our third conference we will review the finalists and select a winner shortly thereafter. At each stage we will do our best to explain our choices. The Federal Register announcement specified minimum acceptability requirements for "complete and proper submissions." These requirements included provisions for reference and optimized C code implementations, known answer tests, a written specification and required intellectual property statements. We asked for reference code and optimized 32 and 64-bit code. Some submissions did not include optimized implementations, so we will use the performance results from the reference implementations in our future deliberations. Some submissions were rejected because C code was not provided. NIST specified a specific API for the C code, and a few submissions did not use that API: these submissions were also rejected. In some cases, we made a number of minor corrections to the submitted code (largely in the include statements) in order to allow it to compile and run, but made no major repairs. NIST attempted to verify that the submitted C programs gave outputs that corresponded to the submitted known answer test results when compiled and run on our reference platform. In several cases there were discrepancies between the known answer test results NIST got on our reference platform, and the known answer test results provided by the submitters. NIST will notify those submitters, and these discrepancies must be resolved in a timely manner if the submission is to be eligible to become a second round candidate. We also asked for documentation, including a complete specification of the algorithms, known answer test results, a performance analysis on different platforms and a security analysis. The quality of the submitted documentation varied greatly. For the security and performance analyses, we were very liberal in what we accepted. We had difficulty determining that the algorithm specifications were complete in some cases. In some of these cases necessary information, such as initial values or padding rules, were omitted from otherwise well-written specifications, but we were able to easily determine this information from the code; these specifications were considered acceptable, since independent implementers can find what they need and the specification can be easily fixed. Some written specifications were incomprehensible without a careful examination of the C code; the more extreme cases were rejected. Inevitably, there were cases between the two extremes. There were several submissions which we accepted that required us to rely more on the programming code for clear understanding than we liked. We expect that the algorithms selected as the SHA-3 finalists will have specifications that will allow independent implementers to program or design hardware that will produce results that match those provided by the submitters for the known answer tests. In the AES competition, Brian Gladman and others provided independent implementations of all the finalists. Marginal, hard to follow specifications may affect whether a submission is selected for the second round. We reviewed the intellectual property statements for all of the submissions. While there remain minor issues in some of the statements, we believe that all the accepted submissions include IP statements that allow us to continue the evaluation process for those submissions for now. However, any IP statement issues must be fully resolved before a candidate can progress to be a second round candidate. Many of the accepted submissions have been posted on the SHA-3 Zoo site for some time, and a number have been analyzed and are claimed to be "broken." In some cases, the submitters have conceded the break. In other cases, the submitters concede the break, but claim that it can be fixed with trivial changes (e.g. by adding a few rounds). In still other cases, it appears that the breaks are fundamental and cannot be fixed without extensive modifications. NIST does not want to spend time in the upcoming SHA-3 conference on accepted, but broken algorithms, unless the break is disputed, or the fix is truly trivial. On the other hand, there has been considerable discussion about what is considered to be a break, and we expect to continue that discussion in Leuven. We also expect to discuss allowing submitters to use their "tunable parameter" to make changes to their algorithm before the second round candidates are chosen. We will continue to consider submissions where there is a dispute about whether the submission is in fact broken until we can make a determination about the facts of the case. Regards, Bill Burr -- William E. Burr Manager, Security Technology Group NIST 100 Bureau Dr., MS 8931 Gaithersburg, MD. 20899 Bldg. 222, Rm B362 Tel: 301-975-2914 Fax: 301-975-8670 --------------000906070503040103070604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

NIST received 64 SHA-3 candidate hash function submissions.  Overall, NIST is very pleased with the obvious high quality of many of the submissions, as well as the general range of designs.  NIST has accepted 51 first round candidates as meeting our minimum acceptance criteria.  They are now posted on the NIST website: <http://csrc.nist.gov/groups/ST/hash/sha-3/Round1/submissions_rnd1.html>. To make an "official" comment on one of the algorithms please use the "submit comments" link on this page for the appropriate algorithm.  Such comments will also be forwarded to hash-forum@nist.gov.  Continue to post general comments about the competition at hash-forum@nist.gov.


We will review these first round candidates at the first SHA-3 Candidate Conference on February 25-28, 2009 at Leuven.  During the summer of 2009 we plan to select about 15 second round candidates for more focused review at the Second SHA-3 Candidate Conference, tentatively scheduled for August, 2010.  Following that second conference we expect to select about 5 third round candidates (or “finalists”).  At our third conference we will review the finalists and select a winner shortly thereafter.  At each stage we will do our best to explain our choices.

The Federal Register announcement specified minimum acceptability requirements for “complete and proper submissions.”  These requirements included provisions for reference and optimized C code implementations, known answer tests, a written specification and required intellectual property statements.   

We asked for reference code and optimized 32 and 64-bit code. Some submissions did not include optimized implementations, so we will use the performance results from the reference implementations in our future deliberations.  Some submissions were rejected because C code was not provided.  NIST specified a specific API for the C code, and a few submissions did not use that API: these submissions were also rejected.  In some cases, we made a number of minor corrections to the submitted code (largely in the include statements) in order to allow it to compile and run, but made no major repairs.   

NIST attempted to verify that the submitted C programs gave outputs that corresponded to the submitted known answer test results when compiled and run on our reference platform.  In several cases there were discrepancies between the known answer test results NIST got on our reference platform, and the known answer test results provided by the submitters.  NIST will notify those submitters, and these discrepancies must be resolved in a timely manner if the submission is to be eligible to become a second round candidate.

We also asked for documentation, including a complete specification of the algorithms, known answer test results, a performance analysis on different platforms and a security analysis.  The quality of the submitted documentation varied greatly.  For the security and performance analyses, we were very liberal in what we accepted.  We had difficulty determining that the algorithm specifications were complete in some cases.  In some of these cases necessary information, such as initial values or padding rules, were omitted from otherwise well-written specifications, but we were able to easily determine this information from the code; these specifications were considered acceptable, since independent implementers can find what they need and the specification can be easily fixed.  Some written specifications were incomprehensible without a careful examination of the C code; the more extreme cases were rejected.  Inevitably, there were cases between the two extremes. There were several submissions which we accepted that  required us to rely more on the programming code for clear understanding than we liked.

We expect that the algorithms selected as the SHA-3 finalists will have specifications that will allow independent implementers to program or design hardware that will produce results that match those provided by the submitters for the known answer tests.  In the AES competition, Brian Gladman and others provided independent implementations of all the finalists.  Marginal, hard to follow specifications may affect whether a submission is selected for the second round. 

We reviewed the intellectual property statements for all of the submissions. While there remain minor issues in some of the statements, we believe that all the accepted submissions include IP statements that allow us to continue the evaluation process for those submissions for now.  However, any IP statement issues must be fully resolved before a candidate can progress to be a second round candidate.

Many of the accepted submissions have been posted on the SHA-3 Zoo site for some time, and a number have been analyzed and are claimed to be “broken.”  In some cases, the submitters have conceded the break. In other cases, the submitters concede the break, but claim that it can be fixed with trivial changes (e.g. by adding a few rounds). In still other cases, it appears that the breaks are fundamental and cannot be fixed without extensive modifications.  NIST does not want to spend time in the upcoming SHA-3 conference on accepted, but broken algorithms, unless the break is disputed, or the fix is truly trivial.  On the other hand, there has been considerable discussion about what is considered to be a break, and we expect to continue that discussion in Leuven.  We also expect to discuss allowing submitters to use their “tunable parameter” to make changes to their algorithm before the second round candidates are chosen. 

We will continue to consider submissions where there is a dispute about whether the submission is in fact broken until we can make a determination about the facts of the case.

Regards,

Bill Burr
 
-- 
William E. Burr
Manager, Security Technology Group
NIST
100 Bureau Dr., MS 8931
Gaithersburg, MD. 20899
Bldg. 222, Rm B362
Tel: 301-975-2914
Fax: 301-975-8670
--------------000906070503040103070604-- From hash-forum@nist.gov Wed Dec 10 12:28:03 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBAKRtHH000495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Dec 2008 12:27:57 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBAKQYlU031526; Wed, 10 Dec 2008 15:26:41 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBAKPMwN029367; Wed, 10 Dec 2008 15:25:22 -0500 Date: Wed, 10 Dec 2008 15:25:22 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Bob Hattersley" To: Multiple recipients of list Subject: RE: SHA-3 First Round Submissions. X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas In-Reply-To: <49400E39.4090702@nist.gov> X-Mailer: Microsoft Office Outlook 11 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C95B04.6029D1C0" MIME-Version: 1.0 References: <49400E39.4090702@nist.gov> X-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 10 Dec 2008 12:27:57 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 297 This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C95B04.6029D1C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have two questions: Will NIST let the accepted submitters know (perhaps privately) what specific problems they found with the quality of documentation or code, so that these can be improved for everyone's benefit? I have succeeded in cutting the number of cycles per byte by 40% on the 32-bit platform by coding the main loop in inline assembler. Is NIST interested in implementations other than pure C, how will they be taken into account, and what is the process for submitting such additional implementations? Thanks, Bob Hattersley (Waterfall) Opta Consulting Ltd. _____ From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Bill Burr Sent: 10 December 2008 18:49 To: Multiple recipients of list Subject: SHA-3 First Round Submissions. NIST received 64 SHA-3 candidate hash function submissions. Overall, NIST is very pleased with the obvious high quality of many of the submissions, as well as the general range of designs. NIST has accepted 51 first round candidates as meeting our minimum acceptance criteria. They are now posted on the NIST website: . To make an "official" comment on one of the algorithms please use the "submit comments" link on this page for the appropriate algorithm. Such comments will also be forwarded to hash-forum@nist.gov. Continue to post general comments about the competition at hash-forum@nist.gov. We will review these first round candidates at the first SHA-3 Candidate Conference on February 25-28, 2009 at Leuven. During the summer of 2009 we plan to select about 15 second round candidates for more focused review at the Second SHA-3 Candidate Conference, tentatively scheduled for August, 2010. Following that second conference we expect to select about 5 third round candidates (or "finalists"). At our third conference we will review the finalists and select a winner shortly thereafter. At each stage we will do our best to explain our choices. The Federal Register announcement specified minimum acceptability requirements for "complete and proper submissions." These requirements included provisions for reference and optimized C code implementations, known answer tests, a written specification and required intellectual property statements. We asked for reference code and optimized 32 and 64-bit code. Some submissions did not include optimized implementations, so we will use the performance results from the reference implementations in our future deliberations. Some submissions were rejected because C code was not provided. NIST specified a specific API for the C code, and a few submissions did not use that API: these submissions were also rejected. In some cases, we made a number of minor corrections to the submitted code (largely in the include statements) in order to allow it to compile and run, but made no major repairs. NIST attempted to verify that the submitted C programs gave outputs that corresponded to the submitted known answer test results when compiled and run on our reference platform. In several cases there were discrepancies between the known answer test results NIST got on our reference platform, and the known answer test results provided by the submitters. NIST will notify those submitters, and these discrepancies must be resolved in a timely manner if the submission is to be eligible to become a second round candidate. We also asked for documentation, including a complete specification of the algorithms, known answer test results, a performance analysis on different platforms and a security analysis. The quality of the submitted documentation varied greatly. For the security and performance analyses, we were very liberal in what we accepted. We had difficulty determining that the algorithm specifications were complete in some cases. In some of these cases necessary information, such as initial values or padding rules, were omitted from otherwise well-written specifications, but we were able to easily determine this information from the code; these specifications were considered acceptable, since independent implementers can find what they need and the specification can be easily fixed. Some written specifications were incomprehensible without a careful examination of the C code; the more extreme cases were rejected. Inevitably, there were cases between the two extremes. There were several submissions which we accepted that required us to rely more on the programming code for clear understanding than we liked. We expect that the algorithms selected as the SHA-3 finalists will have specifications that will allow independent implementers to program or design hardware that will produce results that match those provided by the submitters for the known answer tests. In the AES competition, Brian Gladman and others provided independent implementations of all the finalists. Marginal, hard to follow specifications may affect whether a submission is selected for the second round. We reviewed the intellectual property statements for all of the submissions. While there remain minor issues in some of the statements, we believe that all the accepted submissions include IP statements that allow us to continue the evaluation process for those submissions for now. However, any IP statement issues must be fully resolved before a candidate can progress to be a second round candidate. Many of the accepted submissions have been posted on the SHA-3 Zoo site for some time, and a number have been analyzed and are claimed to be "broken." In some cases, the submitters have conceded the break. In other cases, the submitters concede the break, but claim that it can be fixed with trivial changes (e.g. by adding a few rounds). In still other cases, it appears that the breaks are fundamental and cannot be fixed without extensive modifications. NIST does not want to spend time in the upcoming SHA-3 conference on accepted, but broken algorithms, unless the break is disputed, or the fix is truly trivial. On the other hand, there has been considerable discussion about what is considered to be a break, and we expect to continue that discussion in Leuven. We also expect to discuss allowing submitters to use their "tunable parameter" to make changes to their algorithm before the second round candidates are chosen. We will continue to consider submissions where there is a dispute about whether the submission is in fact broken until we can make a determination about the facts of the case. Regards, Bill Burr -- William E. Burr Manager, Security Technology Group NIST 100 Bureau Dr., MS 8931 Gaithersburg, MD. 20899 Bldg. 222, Rm B362 Tel: 301-975-2914 Fax: 301-975-8670 ------=_NextPart_000_000D_01C95B04.6029D1C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I have two questions:
 
Will NIST let the accepted = submitters know=20 (perhaps privately) what specific problems they found with the quality = of=20 documentation or code, so that these can be improved for everyone's=20 benefit?
 
I have succeeded in cutting the number of = cycles per=20 byte by 40% on the 32-bit platform by coding the main loop in inline=20 assembler.  Is NIST interested in implementations other than = pure C,=20 how will they be taken into account, and what is the process for = submitting such=20 additional implementations?
 
Thanks,
 
Bob Hattersley = (Waterfall)
Opta Consulting Ltd.
 
From: hash-forum@nist.gov=20 [mailto:hash-forum@nist.gov] On Behalf Of Bill = Burr
Sent: 10=20 December 2008 18:49
To: Multiple recipients of = list
Subject:=20 SHA-3 First Round Submissions.

NIST received 64 SHA-3 candidate hash function=20 submissions.  Overall, NIST is very pleased with the = obvious=20 high quality of many of the submissions, as well as the general range of = designs.  NIST has accepted 51 first round candidates = as=20 meeting our minimum acceptance criteria.  They are now = posted=20 on the NIST website: <http://csrc.nist.gov/groups/ST/hash/sha-3/Round1/submissions_r= nd1.html>. To make an = "official" comment=20 on one of the algorithms please use the "submit comments" link on this = page for=20 the appropriate algorithm.  Such comments will also be forwarded to = hash-forum@nist.gov.  = Continue to=20 post general comments about the competition at hash-forum@nist.gov.


We will review these first round = candidates at=20 the first SHA-3 Candidate Conference on February 25-28, 2009 at = Leuven.  During the summer of = 2009 we=20 plan to select about 15 second round candidates for more focused review = at the=20 Second SHA-3 Candidate Conference, tentatively scheduled for August, = 2010.=20  Following that second conference we expect to select = about 5=20 third round candidates (or “finalists”).  = At our third=20 conference we will review the finalists and select a winner shortly=20 thereafter.  At each stage we will do our best to = explain our=20 choices.

The Federal Register announcement specified minimum = acceptability requirements for “complete and proper = submissions.” =20 These requirements included provisions for reference and = optimized C code=20 implementations, known answer tests, a written specification and = required=20 intellectual property statements.    =

We asked for reference code and optimized 32 and = 64-bit code.=20 Some submissions did not include optimized implementations, so we will = use the=20 performance results from the reference implementations in our future=20 deliberations.  Some submissions were rejected because = C code=20 was not provided.  NIST specified a specific API for = the C=20 code, and a few submissions did not use that API: these submissions were = also=20 rejected.  In some cases, we made a number of minor=20 corrections to the submitted code (largely in the include statements) in = order=20 to allow it to compile and run, but made no major repairs. =20  

NIST attempted to verify that the submitted C = programs gave=20 outputs that corresponded to the submitted known answer test results = when=20 compiled and run on our reference platform.  In = several cases=20 there were discrepancies between the known answer test results NIST got = on our=20 reference platform, and the known answer test results provided by the=20 submitters.  NIST will notify those submitters, and = these=20 discrepancies must be resolved in a timely manner if the submission is = to be=20 eligible to become a second round candidate.

We also asked for documentation, including a = complete=20 specification of the algorithms, known answer test results, a = performance=20 analysis on different platforms and a security analysis.  = The=20 quality of the submitted documentation varied greatly.  = For=20 the security and performance analyses, we were very liberal in what we=20 accepted.  We had difficulty determining that the = algorithm=20 specifications were complete in some cases.  In some = of these=20 cases necessary information, such as initial values or padding rules, = were=20 omitted from otherwise well-written specifications, but we were able to = easily=20 determine this information from the code; these specifications were = considered=20 acceptable, since independent implementers can find what they need and = the=20 specification can be easily fixed.  Some written=20 specifications were incomprehensible without a careful examination of = the C=20 code; the more extreme cases were rejected.  = Inevitably, there=20 were cases between the two extremes. There were several submissions = which we=20 accepted that  required us to rely more on the = programming=20 code for clear understanding than we liked.

We expect that the algorithms selected as the SHA-3 = finalists=20 will have specifications that will allow independent implementers to = program or=20 design hardware that will produce results that match those provided by = the=20 submitters for the known answer tests.  In the AES=20 competition, Brian Gladman and others provided independent = implementations of=20 all the finalists.  Marginal, hard to follow = specifications=20 may affect whether a submission is selected for the second=20 round. 

We reviewed the intellectual property statements = for all of=20 the submissions. While there remain minor issues in some of the = statements, we=20 believe that all the accepted submissions include IP statements that = allow us to=20 continue the evaluation process for those submissions for now.=20  However, any IP statement issues must be fully = resolved=20 before a candidate can progress to be a second round candidate. =

Many of the accepted submissions have been posted = on the=20 SHA-3 Zoo site for some time, and a number have been analyzed and are = claimed to=20 be “broken.”  In some cases, the = submitters have conceded the=20 break. In other cases, the submitters concede the break, but claim that = it can=20 be fixed with trivial changes (e.g. by adding a few rounds). In still = other=20 cases, it appears that the breaks are fundamental and cannot be fixed = without=20 extensive modifications.  NIST does not want to spend = time in=20 the upcoming SHA-3 conference on accepted, but broken algorithms, unless = the=20 break is disputed, or the fix is truly trivial.  On = the other=20 hand, there has been considerable discussion about what is considered to = be a=20 break, and we expect to continue that discussion in Leuven.  We also expect to = discuss=20 allowing submitters to use their “tunable parameter” to make = changes to their=20 algorithm before the second round candidates are=20 chosen. 

We will = continue to=20 consider submissions where there is a dispute about whether the = submission is in=20 fact broken until we can make a determination about the facts of the=20 case.

Regards,

Bill Burr
--=20
William E. Burr
Manager, Security Technology Group
NIST
100 Bureau Dr., MS 8931
Gaithersburg, MD. 20899
Bldg. 222, Rm B362
Tel: 301-975-2914
Fax: 301-975-8670
------=_NextPart_000_000D_01C95B04.6029D1C0-- From hash-forum@nist.gov Wed Dec 10 12:44:50 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBAKiho7002299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Dec 2008 12:44:44 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBAKePVi014078; Wed, 10 Dec 2008 15:40:32 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBAKe4GZ026633; Wed, 10 Dec 2008 15:40:04 -0500 Date: Wed, 10 Dec 2008 15:40:04 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Daniel Penazzi" To: Multiple recipients of list Subject: Re: Engineering comparison of the SHA-3 candidates X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <888E37A2001E364CBC4F28FA7660A2E65E26A86F26@NA-EXMSG-C102.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="----=_Part_255_3159618.1228940727395" MIME-Version: 1.0 In-Reply-To: <888E37A2001E364CBC4F28FA7660A2E65E26A86F26@NA-EXMSG-C102.redmond.corp.microsoft.com> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 10 Dec 2008 12:44:44 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 298 ------=_Part_255_3159618.1228940727395 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear Mr. Ferguson. Greetings from the south! I am one of the creators of TIB3. I appreciate that you consider us a "good" algorithm (thanks!) but I found a printing error in your page: you list our algorithm with the same speed on 32 bits and 64 bits platform (13/17.7 clocks per byte). This is the speed on 32 bit platforms, but on 64 bits is 7.68 clocks per byte for TIB3-256 and 6.24 clocks per byte for TIB3-512 on the NIST target platform, as can be seen in our submission. (In our submission we measured on clocks per bit instead of clocks per byte. This was somewhat stupid, I admit). Well, I only let you know because you said to write to you if we found any gross error, and since you used the 64 bit speed to rank the top 5, we would be above both SHAMATA and Sarmal, (but below Skein512.) By the way, I like Skein very much. (though I like for the moment TIB3 better :) Good luck with the competition, although, as Obama said about Sarah Palin "not too much luck". Happy holidays, Daniel Penazzi On 12/9/08, Niels Ferguson wrote: > > The Skein team has been working on an engineering comparison of the SHA-3 > candidate algorithms. Our results are available at > > > > http://www.skein-hash.info/sha3-engineering > > > > This is essentially our rating of the competitors, and we'll use this to > target our analysis efforts on those algorithms that have the best > engineering properties. > > > > So far we've only done a first ordering based mostly on speed. The current > top 5 algorithms are: > > > > Edon-R > > Blue Midnight Wish > > Skein > > SHAMATA > > Sarmal > > > > which all run in less than 10 cycles/byte. > > > > We're planning to keep this page up to date as we develop more results. > > > > > > Cheers! > > > > Niels Ferguson > > > ------=_Part_255_3159618.1228940727395 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear Mr. Ferguson.
Greetings from the south!

I am one of the creators of TIB3. I appreciate that you consider us a "good" algorithm
(thanks!) but I found a printing error in your page: you list our algorithm with the same speed
on 32 bits and 64 bits platform (13/17.7 clocks per byte).
This is the speed on 32 bit platforms, but on 64 bits is 7.68 clocks per byte for TIB3-256 and
6.24 clocks per byte for TIB3-512 on the NIST target platform, as can be seen in our submission.
 (In our submission we measured on clocks per bit instead
of clocks per byte. This was somewhat stupid, I admit).

Well, I only let you know because you said to write to you if we found any gross error, and since you used the 64 bit speed to rank the top 5, we would be above both SHAMATA and Sarmal, (but below Skein512.)

By the way, I like Skein very much. (though I like for the moment TIB3 better :)

Good luck with the competition, although, as Obama said about Sarah Palin "not too much luck".

Happy holidays,

Daniel Penazzi




On 12/9/08, Niels Ferguson <niels@microsoft.com> wrote:

The Skein team has been working on an engineering comparison of the SHA-3 candidate algorithms. Our results are available at

 

http://www.skein-hash.info/sha3-engineering

 

This is essentially our rating of the competitors, and we'll use this to target our analysis efforts on those algorithms that have the best engineering properties.

 

So far we've only done a first ordering based mostly on speed. The current top 5 algorithms are:

 

Edon-R

Blue Midnight Wish

Skein

SHAMATA

Sarmal

 

which all run in less than 10 cycles/byte.

 

We're planning to keep this page up to date as we develop more results.

 

 

Cheers!

 

Niels Ferguson

 


------=_Part_255_3159618.1228940727395-- From hash-forum@nist.gov Wed Dec 10 12:55:13 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBAKt7dC003495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Dec 2008 12:55:09 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBAKsFmr008596; Wed, 10 Dec 2008 15:54:20 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBAKrq7M023117; Wed, 10 Dec 2008 15:53:52 -0500 Date: Wed, 10 Dec 2008 15:53:52 -0500 Message-Id: <20081210205159.3B3882594@courageux.concentric.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Colin B To: Multiple recipients of list Subject: Re: Engineering comparison of the SHA-3 candidates X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 In-Reply-To: <888E37A2001E364CBC4F28FA7660A2E65E26A86F26@NA-EXMSG-C102.redmond.corp.microsoft.com> <493F3F79.60706@mit.edu> X-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 10 Dec 2008 12:55:09 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 299 My lamppost is down at the other end of the street where even a MIPS or an ARM core is uneconomic. As Thomas says, my world is not going away and any algorithm chosen must run in my world. For me, performance on multi-core platforms is irrelevant. Regards, Colin. ---- wrote: > > > On Tue, Dec 09, 2008 at 11:12:17PM -0500, Ronald L. Rivest wrote: > > My first lamppost would shine light on those designs that > > take advantage of the forthcoming flood of multicore > > processors, rather than the proposed 64-bit unicore lamppost > > (you may not be even able to buy 64-bit unicore processors soon!). > > I don't think that there is an issue about performance of hash functions > on PC (or similar systems), unless you get to the really slow functions > such as Whirlpool. A single core system, using a not-so-fast function > (e.g. SHA-256), will hash data faster than what the network or harddisk > may eat. Rather, if there is a performance issue, then it is more > related to L1 cache size than cycles-per-byte. > > That's an often overlooked issue: we do not hash data only for the sake > of it. Data is hashed as part of a wider process, and the hash function > is only a part of the code which is touched by the processor in the > critical execution path. This means that the hash function must share > the number 1 scarce resource, that is the L1 caches. Usual benchmarks do > not take this into account, they run the function "alone". In a > practical situation, the function code and the function data should not > use more than a fraction of the data and code L1 caches. For the data > cache, this includes the size of the function state, but also the > constant tables, if its implementation is table-driven. > > A "modern" PC will offer about 64 KB of data cache and about as much of > code cache, but a good function should use no more (and preferably much > less) than, say, 10 or 12 KB of each. In my view, under my own lampost > if you prefer, these cache issues are much more plausible candidates for > performance problems on nowadays PC than raw cycles per byte counts in > ideal benchmark conditions. > > > Yet the PC is not a good example of a platform where hash functions have > performance issues. Researchers use benchmark on what they have, i.e. > workstations (mostly x86 running Windows, Linux or MacOS, but some Sparc > users may still strive somewhere). But some other architectures are more > "industrially significant". I am thinking about cell phones, network and > WiFi routers, MP3 players, digital cameras... all those devices which > have severe operational limitations (including power consumption or > size), some of which being involved in cryptography all day long. These > systems use primarily ARM and MiPS processors. They have a single core > each(*). They are clocked at a few dozen or hundred megahertz at most. > Those systems have real performance issues with cryptography. And, guess > what, it turns out that the biggest performance killer on those systems > is cache overflow. > > I own a Linksys router which I have reflashed with OpenWRT (a Linux > variant) so that I could bench hash function implementations. I believe > it is quite representative of the class of hardware I am talking about. > It features a MiPS core clocked at 200 MHz. The L1 cache for code does > not exceed 8 KB; this means that any hash function which code exceeds > that size will suffer heavy penalties even in ideal benchmark > conditions. E.g. a SHA-256 implementation with full loop unrolling (a > common implementation design) will hash about 1.8 MB/s on that system. > By using only partial unrolling, which fortunately is feasible with > SHA-256, bandwidth goes up to almost 3 MB/s. And that is still not very > fast. > > What these figures show is that there exist plateforms which are widely > used, and which need fast cryptographic functions, and these systems are > NOT the everyday multi-core x86 PC. And what matters most for > performance on such systems is whether the function may be implemented > within the restrained cache sizes that these platform provide, rather > than the cycles per bytes which are achieved on huge systems with plenty > of cache dedicated to the sole function. > > (The RadioGatun function, for instance, is really not easy to implement > with only partial unrolling. The hardware I am talking about is also > quite bad at arithmetic operations on words beyond 32 bits, hence > SHA-512 and other 64-bit functions are very slow on such systems.) > > > --Thomas Pornin > > (*) At least some of the iPod models feature two ARM cores. > > From hash-forum@nist.gov Wed Dec 10 13:24:26 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBALOJSK006739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Dec 2008 13:24:20 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBALMKBK003562; Wed, 10 Dec 2008 16:22:26 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBALLQQH014397; Wed, 10 Dec 2008 16:21:26 -0500 Date: Wed, 10 Dec 2008 16:21:26 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Greg Rose To: Multiple recipients of list Subject: OFFICIAL COMMENT: BOOLE X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-function@nist.gov Content-Transfer-Encoding: 7bit X-Cc: hash-forum@nist.gov Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 10 Dec 2008 13:24:20 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-5.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED,SUBJ_ALL_CAPS shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 300 Boole should be considered broken. While it might be fixable, I don't intend to waste NIST's, and the community's, time on examining it further. I have been exceptionally pleased with the quality of the analysis to date, and hope to continue to contribute to the project as a whole. Greg Rose (submitter). From hash-forum@nist.gov Wed Dec 10 14:20:27 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBAMKKt8013942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Dec 2008 14:20:23 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBAMJHPh031116; Wed, 10 Dec 2008 17:19:22 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBAMH0TS031244; Wed, 10 Dec 2008 17:17:00 -0500 Date: Wed, 10 Dec 2008 17:17:00 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Dmitry Khovratovich" To: Multiple recipients of list Subject: StreamHash X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/alternative; boundary="----=_Part_1436_23294947.1228947119946" MIME-Version: 1.0 X-To: "Multiple recipients of list" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 10 Dec 2008 14:20:24 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 301 ------=_Part_1436_23294947.1228947119946 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, the Streamhash compression function seems to process each word of the internal state (consists of 32-bit words) separately: s_i <- f(s_i, message_byte). If so one can follow Joux and find multicollisions for all the words, and then find a full collision among them. -- Best regards, Dmitry Khovratovich, Ivica Nikolic University of Luxembourg, Laboratory of Algorithmics, Cryptography and Security, + 352 46 66 44 5478 ------=_Part_1436_23294947.1228947119946 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all,

the Streamhash compression function seems to process each word of the internal state (consists of 32-bit words) separately: s_i <- f(s_i, message_byte). If so one can follow Joux and find multicollisions for all the words, and then find a full collision among them.

--
Best regards,
Dmitry Khovratovich, Ivica Nikolic

University of Luxembourg,
Laboratory of Algorithmics, Cryptography and Security,
+ 352 46 66 44 5478
------=_Part_1436_23294947.1228947119946-- From hash-forum@nist.gov Wed Dec 10 14:38:11 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBAMbTap015752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Dec 2008 14:37:32 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBAMZlCr016542; Wed, 10 Dec 2008 17:35:55 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBAMWqGv031701; Wed, 10 Dec 2008 17:32:52 -0500 Date: Wed, 10 Dec 2008 17:32:52 -0500 Message-Id: <494041BC.8000703@esat.kuleuven.be> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Nicky Mouha To: Multiple recipients of list Subject: Collision for Khichidi-1 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 10 Dec 2008 14:37:32 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 302 Hi, I've found a collision for Khichidi-1 by hand calculation: http://www.nickymouha.be/software-en.html Kind regards, Nicky Mouha ESAT/COSIC, Katholieke Universiteit Leuven Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm From hash-forum@nist.gov Wed Dec 10 15:04:39 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBAN4XGc018856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Dec 2008 15:04:34 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBAN3c7w001110; Wed, 10 Dec 2008 18:03:41 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBAN2bru025130; Wed, 10 Dec 2008 18:02:37 -0500 Date: Wed, 10 Dec 2008 18:02:37 -0500 Message-Id: <6D6A5EEF6EF605499E6E4A4A8C3FEFF6028DE40BB11D@WINEXCHANGE1.win.dtu.dk> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Praveen Gauravaram To: Multiple recipients of list Subject: RE: Collision for Khichidi-1 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" In-Reply-To: <494041BC.8000703@esat.kuleuven.be> References: <494041BC.8000703@esat.kuleuven.be> X-To: "hash-forum@nist.gov" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 10 Dec 2008 15:04:34 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 303 Hi Nicky, I found the same, quite trivial. Even second preimages as well. It uses CBC mode for hashing. It is very trivial to break. Praveen Praveen ________________________________________ From: hash-forum@nist.gov [hash-forum@nist.gov] On Behalf Of Nicky Mouha [Nicky.Mouha@esat.kuleuven.be] Sent: Wednesday, December 10, 2008 11:32 PM To: Multiple recipients of list Subject: Collision for Khichidi-1 Hi, I've found a collision for Khichidi-1 by hand calculation: http://www.nickymouha.be/software-en.html Kind regards, Nicky Mouha ESAT/COSIC, Katholieke Universiteit Leuven Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm From hash-forum@nist.gov Wed Dec 10 16:02:01 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBB01tcW025353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Dec 2008 16:01:57 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBB00nZG000821; Wed, 10 Dec 2008 19:00:54 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBANxCFF007961; Wed, 10 Dec 2008 18:59:12 -0500 Date: Wed, 10 Dec 2008 18:59:12 -0500 Message-Id: <20081210235315.2482.qmail@cr.yp.to> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "D. J. Bernstein" To: Multiple recipients of list Subject: Re: SHA-3 First Round Submissions. X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas In-Reply-To: X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 10 Dec 2008 16:01:57 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk $Forwarded X-UID: 304 Bob Hattersley writes: > I have succeeded in cutting the number of cycles per byte by 40% on the > 32-bit platform by coding the main loop in inline assembler. Is NIST > interested in implementations other than pure C, how will they be taken into > account, and what is the process for submitting such additional > implementations? I don't know what NIST is interested in, but the eBASH (ECRYPT Benchmarking of All Submitted Hashes) project is interested in measuring the performance that hash-function users will see. If you send eBASH several different implementations of your hash function, then the benchmarking tools will measure all of the implementations, and---like the users who care about speed---will choose the fastest implementation. For example, the most recent groestl256 results shown in http://bench.cr.yp.to/results-hash.html are the best results from two different groestl256 implementations. In total there are, at this point, 49 different implementations of 28 hash functions in 14 families, and you're free to contribute more! See http://bench.cr.yp.to/call-hash.html for the API. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago From hash-forum@nist.gov Thu Dec 11 01:25:39 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBB9PXIl018433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 Dec 2008 01:25:34 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBB9O1uL026396; Thu, 11 Dec 2008 04:24:06 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBB9MQb7009091; Thu, 11 Dec 2008 04:22:26 -0500 Date: Thu, 11 Dec 2008 04:22:26 -0500 Message-Id: <888E37A2001E364CBC4F28FA7660A2E65E26A65824@NA-EXMSG-C102.redmond.corp.microsoft.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Niels Ferguson To: Multiple recipients of list Subject: Using multi-core capabilities in the hash function X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-To: "hash-forum@nist.gov" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 11 Dec 2008 01:25:34 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 305 Already most new machines are multi-core. But that does not mean that the hash function gets to use multiple cores. The first problem is a software problem: the crypto libraries live at the very lowest layers of the software stack. At that layer you cannot start a new thread, perform thread signaling, etc. There are several reasons for this. First, quite a bit of crypto is done while holding some locks that you also need to schedule CPUs. For example, in Windows the IPsec processing of a received IP packet is done at a software interrupt (dispatch) level for performance reasons. When running at that interrupt level you cannot start a thread or even signal another thread to wake up. Another situation is the boot process: the crypto libraries are used long before the kernel is running, so there are no threads. Of course, we could create different crypto libraries for the different environments, but that has a quite significant cost in terms of development, testing, maintenance, FIPS certification, etc. The second problem is that we are now optimizing for power consumption, as power will the be limiting factor in future CPUs. (Battery life is already a major limiting factor for laptops.) A function that performs 30 cycles/byte work spread over 5 cores will run at 6 cycle-times/byte, but it will consume power for 30 cycles/byte. And if we want to do things like checking the integrity of every byte read off the disk, we have to process a huge amount of data. The third problem is the bandwidth on the interconnection bus. Applications try to keep data local to the core the thread is running on. OSes have various NUMA-aware optimizations and APIs that support that. If the hash function splits the work over multiple cores then the data has to be transferred from the local memory or memory cache to the remote core. This can impose a significant load on the interconnect bus, which is a critical system resource. There are probably other obstacles as well. I have not yet done a full analysis of this problem space. Some of the problems can be alleviated, but at first glance this would require major changes to multiple APIs throughout the software layers. As these are public APIs, and they need to maintain backward compatibility, they are immensely expensive to change. My team is responsible for the crypto libraries in the Windows operating system. At the moment the infrastructure does not support a hash function that uses multiple threads, and it is unlikely that such support will be available in the next few releases. There are of course applications where using the parallelism might be useful. I had a look and we can use some of the extension flexibility in the existing Windows crypto infrastructure to let applications compute the individual pieces of a parallelizable hash function. But the application is then responsible for combining the pieces in the right way. This is both error-prone, and requires separate FIPS validation if you want to sell the application to the federal government, so most applications will not go down this path. If the hash function is fast enough then none of the parallelism support is necessary, which eliminates all the problems I've mentioned. Cheers! Niels ________________________________________ From: hash-forum@nist.gov [hash-forum@nist.gov] On Behalf Of Ronald L. Rivest [rivest@mit.edu] Sent: Tuesday, December 09, 2008 8:12 PM To: Multiple recipients of list Subject: Re: Engineering comparison of the SHA-3 candidates Nice "looking under the lamppost" chart... Of course, each designer gets to pick his own lamppost(s) ... :-) (even if one is focussed on engineering...) My first lamppost would shine light on those designs that take advantage of the forthcoming flood of multicore processors, rather than the proposed 64-bit unicore lamppost (you may not be even able to buy 64-bit unicore processors soon!). Probably most of the tree-based designs will be able to saturate memory bandwidth with a reasonable number of cores. The sequential (e.g. Merkle-Damgard) designs will be stuck in low gear with no way to speed up... My second lamppost would be for submitted designs that offer reasonable security proofs for their mode of operation and for their compression function. While some of "proof-less" designs (i.e. designs submitted without much in the way of proofs) may turn out to be secure, the burden should be (or should have been) on the designers first of all to supply the relevant proofs. Your lampposts may vary... Cheers, Ron On 12/9/2008 6:01 PM, Niels Ferguson wrote: > The Skein team has been working on an engineering comparison of the > SHA-3 candidate algorithms. Our results are available at > > > > http://www.skein-hash.info/sha3-engineering > > > > This is essentially our rating of the competitors, and we'll use this to > target our analysis efforts on those algorithms that have the best > engineering properties. > > > > So far we've only done a first ordering based mostly on speed. The > current top 5 algorithms are: > > > > Edon-R > > Blue Midnight Wish > > Skein > > SHAMATA > > Sarmal > > > > which all run in less than 10 cycles/byte. > > > > We're planning to keep this page up to date as we develop more results. > > > > > > Cheers! > > > > Niels Ferguson > > > -- Ronald L. Rivest Room 32-G692, Stata Center, MIT, Cambridge MA 02139 Tel 617-253-5880, Email From hash-forum@nist.gov Thu Dec 11 01:35:36 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBB9ZV0x019528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 Dec 2008 01:35:32 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBB9OBuw022796; Thu, 11 Dec 2008 04:24:16 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBB9NvE3012898; Thu, 11 Dec 2008 04:23:57 -0500 Date: Thu, 11 Dec 2008 04:23:57 -0500 Message-Id: <888E37A2001E364CBC4F28FA7660A2E65E26A65825@NA-EXMSG-C102.redmond.corp.microsoft.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Niels Ferguson To: Multiple recipients of list Subject: RE: Engineering comparison of the SHA-3 candidates X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" In-Reply-To: <20081210070838.34969.qmail@cr.yp.to> References: <888E37A2001E364CBC4F28FA7660A2E65E26A86F26@NA-EXMSG-C102.redmond.corp.microsoft.com>,<20081210070838.34969.qmail@cr.yp.to> X-To: "hash-forum@nist.gov" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 11 Dec 2008 01:35:32 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 306 As we wrote, our comparison is based on our opinion of the desirable properties that a hash function should have. Of course Skein scores well; it was designed with the same criteria in mind. MD6's 'fair' rating is due to the large amount of memory it needs. This is impractical on smart cards. I know that many smart cards now have 1 kB of memory, but that is being used for many things and the hash function can't lay claim to 70% of all the memory. We used the recommended parameter sets for each algorithm. If you believe that CubeHash should be used with different parameters I believe you should have put that in the submission, or at least make concrete proposals very soon. A very slow algorithm is not going to attract much attention and analysis. It is one thing to change speed/security tradeoff by a few tens of percent; changing it by several orders of magnitude is very different. Cheers! Niels ________________________________________ From: hash-forum@nist.gov [hash-forum@nist.gov] On Behalf Of D. J. Bernstein [djb@cr.yp.to] Sent: Tuesday, December 09, 2008 11:06 PM To: Multiple recipients of list Subject: Re: Engineering comparison of the SHA-3 candidates Niels Ferguson writes: > So far we've only done a first ordering based mostly on speed. Speed of what, exactly? Let's try three illustrative examples from your "engineering comparison": * You rate your own Skein-512 as "good": 6.1 cycles/byte (on a Core 2 in 64-bit mode), apparently in 200 bytes of RAM. * You rate MD6-256 as "fair": 28 cycles/byte using "memory >700 B". * You rate CubeHash---I guess you mean CubeHash8/1---as "poor"; 160 cycles/byte, 128 bytes of RAM. Now let's see what happens when we vary the tunable security parameter specified in the submissions: * Skein-512: Your submission says that there's some sort of attack on "25 of 72" rounds. This means that the minimal unbroken variant has 26 rounds, presumably running at 2.2 cycles/byte. * MD6-256: The documentation reports an attack by Aumasson on 18 out of 104 rounds. This means that the minimal unbroken variant has 19 rounds, presumably running at 5.1 cycles/byte. * CubeHash: Aumasson reports that he has found collisions in CubeHash1/106 and CubeHash2/114. The minimal unbroken variant is CubeHash1/105, presumably running at 0.2 cycles/byte. One can reasonably object to the comparison between 2.2 cycles/byte and 0.2 cycles/byte. Surely collisions will be found in CubeHash1/105 and many other functions, increasing the minimal unbroken cycle counts. Furthermore, the 25-round attack on Skein doesn't appear to be a real collision attack; any reasonable definition of "break" will allow Skein to survive with fewer rounds, if attacks _don't_ improve. On the other hand, 10x is quite a lot of ground to make up! It seems entirely possible that, after careful analysis, we'll see that CubeHash and MD6 and many other families of SHA-3 submissions are achieving security at higher speed than Skein---exactly the opposite of what your "engineering comparison" suggests. Ronald L. Rivest writes: > My first lamppost would shine light on those designs that > take advantage of the forthcoming flood of multicore processors What's an example of a design that _can't_ take advantage of multicore processors? Here's what my submission said: "The advantage of a tree is that it allows very long messages to be split across several processor cores--- but the applications that care can achieve the same benefit by building a tree on top of CubeHash, the same way that they have traditionally built a tree on top of SHA-256. (Similar comments apply to incremental hashing etc.)" Wikipedia says "Tiger tree hashes are used in the Gnutella, Gnutella2, and Direct Connect P2P file sharing protocols and in file sharing applications such as Phex, BearShare, LimeWire, Shareaza, DC++ and Valknut." Tiger wasn't designed to take advantage of multiple cores, but this doesn't pose any problems for applications. > My second lamppost would be for submitted designs that > offer reasonable security proofs for their mode of operation > and for their compression function. While some of "proof-less" > designs (i.e. designs submitted without much in the way of proofs) > may turn out to be secure, the burden should be (or should have been) > on the designers first of all to supply the relevant proofs. There's a counterargument that I'd like to quote here for the record: "Provable security" can be a helpful guide to cryptanalysis, allowing cryptanalysts to focus their energies on the potentially breakable components of a hash function. For example, most hash functions are built as modes of operation of compression functions; a sufficiently powerful security proof for a mode of operation lets cryptanalysts focus on the compression function, confident that the mode per se has no problems. Building confidence in the hash function then boils down to building confidence in the compression function, hopefully a simpler task. CubeHash takes a different approach to building confidence: the entire hash function is very simple and easy to understand, in fact simpler than most compression functions. CubeHash is not built from a lower-level primitive, so there are no reduction proofs, but I don't see this as a disadvantage; the real question is not how much work the cryptanalyst can skip, but how much work the cryptanalyst still has to do. An extremely complicated function with a mountain of proofs is probably better for the cryptanalyst than an extremely complicated function with no proofs at all, but surely much worse than a simple function. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago From hash-forum@nist.gov Thu Dec 11 01:38:59 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBB9csjT019831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 Dec 2008 01:38:55 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBB9bgCq031798; Thu, 11 Dec 2008 04:37:48 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBB9bO3n005519; Thu, 11 Dec 2008 04:37:24 -0500 Date: Thu, 11 Dec 2008 04:37:24 -0500 Message-Id: <888E37A2001E364CBC4F28FA7660A2E65E26A65826@NA-EXMSG-C102.redmond.corp.microsoft.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Niels Ferguson To: Multiple recipients of list Subject: RE: Engineering comparison of the SHA-3 candidates X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_888E37A2001E364CBC4F28FA7660A2E65E26A65826NAEXMSGC102re_" In-Reply-To: References: <888E37A2001E364CBC4F28FA7660A2E65E26A86F26@NA-EXMSG-C102.redmond.corp.microsoft.com>, X-To: "hash-forum@nist.gov" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 11 Dec 2008 01:38:55 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 307 --_000_888E37A2001E364CBC4F28FA7660A2E65E26A65826NAEXMSGC102re_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you. I fixed that. Cheers! Niels ________________________________ From: hash-forum@nist.gov [hash-forum@nist.gov] On Behalf Of Daniel Penazzi= [danielpenazzi@gmail.com] Sent: Wednesday, December 10, 2008 12:40 PM To: Multiple recipients of list Subject: Re: Engineering comparison of the SHA-3 candidates Dear Mr. Ferguson. Greetings from the south! I am one of the creators of TIB3. I appreciate that you consider us a "good= " algorithm (thanks!) but I found a printing error in your page: you list our algorithm= with the same speed on 32 bits and 64 bits platform (13/17.7 clocks per byte). This is the speed on 32 bit platforms, but on 64 bits is 7.68 clocks per by= te for TIB3-256 and 6.24 clocks per byte for TIB3-512 on the NIST target platform, as can be se= en in our submission. (In our submission we measured on clocks per bit instead of clocks per byte. This was somewhat stupid, I admit). Well, I only let you know because you said to write to you if we found any = gross error, and since you used the 64 bit speed to rank the top 5, we woul= d be above both SHAMATA and Sarmal, (but below Skein512.) By the way, I like Skein very much. (though I like for the moment TIB3 bett= er :) Good luck with the competition, although, as Obama said about Sarah Palin "= not too much luck". Happy holidays, Daniel Penazzi On 12/9/08, Niels Ferguson = > wrote: The Skein team has been working on an engineering comparison of the SHA-3 c= andidate algorithms. Our results are available at http://www.skein-hash.info/sha3-engineering This is essentially our rating of the competitors, and we'll use this to ta= rget our analysis efforts on those algorithms that have the best engineerin= g properties. So far we've only done a first ordering based mostly on speed. The current = top 5 algorithms are: Edon-R Blue Midnight Wish Skein SHAMATA Sarmal which all run in less than 10 cycles/byte. We're planning to keep this page up to date as we develop more results. Cheers! Niels Ferguson --_000_888E37A2001E364CBC4F28FA7660A2E65E26A65826NAEXMSGC102re_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thank y= ou. I fixed that.
 
Cheers!
 
Niels
From: hash-forum@nist.gov [hash-for= um@nist.gov] On Behalf Of Daniel Penazzi [danielpenazzi@gmail.com]
Sent: Wednesday, December 10, 2008 12:40 PM
To: Multiple recipients of list
Subject: Re: Engineering comparison of the SHA-3 candidates

Dear Mr. Ferguson.
Greetings from the south!

I am one of the creators of TIB3. I appreciate that you consider us a "= ;good" algorithm
(thanks!) but I found a printing error in your page: you list our algorithm= with the same speed
on 32 bits and 64 bits platform (13/17.7 clocks per byte).
This is the speed on 32 bit platforms, but on 64 bits is 7.68 clocks per by= te for TIB3-256 and
6.24 clocks per byte for TIB3-512 on the NIST target platform, as can be se= en in our submission.
 (In our submission we measured on clocks per bit instead
of clocks per byte. This was somewhat stupid, I admit).

Well, I only let you know because you said to write to you if we found any = gross error, and since you used the 64 bit speed to rank the top 5, we woul= d be above both SHAMATA and Sarmal, (but below Skein512.)

By the way, I like Skein very much. (though I like for the moment TIB3 bett= er :)

Good luck with the competition, although, as Obama said about Sarah Palin &= quot;not too much luck".

Happy holidays,

Daniel Penazzi




On 12/9/08, = Niels Ferguson <niels@microso= ft.com> wrote:

The Skein team has been working on an en= gineering comparison of the SHA-3 candidate algorithms. Our results are ava= ilable at

<= /span> 

http://www.skein-hash.info/sha3-engineeri= ng

<= /span> 

This is essentially our rating of the co= mpetitors, and we'll use this to target our analysis efforts on those algor= ithms that have the best engineering properties.

<= /span> 

So far we've only done a first ordering = based mostly on speed. The current top 5 algorithms are:

<= /span> 

Edon-R

Blue Midnight Wish

Skein

SHAMATA

Sarmal

<= /span> 

which all run in less than 10 cycles/byt= e.

<= /span> 

We're planning to keep this page up to d= ate as we develop more results.

<= /span> 

<= /span> 

Cheers!

<= /span> 

Niels Ferguson

 


--_000_888E37A2001E364CBC4F28FA7660A2E65E26A65826NAEXMSGC102re_-- From hash-forum@nist.gov Thu Dec 11 07:51:46 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBBFpep7031222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 Dec 2008 07:51:42 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBBFhM8O022262; Thu, 11 Dec 2008 10:43:29 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBBFfaLF032214; Thu, 11 Dec 2008 10:41:36 -0500 Date: Thu, 11 Dec 2008 10:41:36 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Dmitry Khovratovich" To: Multiple recipients of list Subject: Re: StreamHash X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: Content-Type: multipart/alternative; boundary="----=_Part_10424_15033023.1229009890067" MIME-Version: 1.0 In-Reply-To: X-To: "Multiple recipients of list" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 11 Dec 2008 07:51:42 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 308 ------=_Part_10424_15033023.1229009890067 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline A paper with a more detailed explanation is available http://lj.streamclub.ru/papers/hash/streamhash.pdf On Wed, Dec 10, 2008 at 11:17 PM, Dmitry Khovratovich < khovratovich@gmail.com> wrote: > Hi all, > > the Streamhash compression function seems to process each word of the > internal state (consists of 32-bit words) separately: s_i <- f(s_i, > message_byte). If so one can follow Joux and find multicollisions for all > the words, and then find a full collision among them. > > -- > Best regards, > Dmitry Khovratovich, Ivica Nikolic > > University of Luxembourg, > Laboratory of Algorithmics, Cryptography and Security, > + 352 46 66 44 5478 > -- Dmitry, Ivica. ------=_Part_10424_15033023.1229009890067 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline A paper with a more detailed explanation is available http://lj.streamclub.ru/papers/hash/streamhash.pdf

On Wed, Dec 10, 2008 at 11:17 PM, Dmitry Khovratovich <khovratovich@gmail.com> wrote:
Hi all,

the Streamhash compression function seems to process each word of the internal state (consists of 32-bit words) separately: s_i <- f(s_i, message_byte). If so one can follow Joux and find multicollisions for all the words, and then find a full collision among them.

--
Best regards,
Dmitry Khovratovich, Ivica Nikolic

University of Luxembourg,
Laboratory of Algorithmics, Cryptography and Security,
+ 352 46 66 44 5478



--
Dmitry, Ivica.
------=_Part_10424_15033023.1229009890067-- From hash-forum@nist.gov Thu Dec 11 08:39:59 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBBGdrRn005665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 Dec 2008 08:39:55 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBBGcX2Z027970; Thu, 11 Dec 2008 11:38:40 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBBGbq93021101; Thu, 11 Dec 2008 11:37:52 -0500 Date: Thu, 11 Dec 2008 11:37:52 -0500 Message-Id: <20081211173535.dm9hcc11q8gw44ow@webmail.uib.no> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Tor.Bjorstad@ii.uib.no To: Multiple recipients of list Subject: Re: StreamHash X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" MIME-Version: 1.0 In-Reply-To: References: X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 11 Dec 2008 08:39:55 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 309 Quoting Dmitry Khovratovich : > A paper with a more detailed explanation is available > http://lj.streamclub.ru/papers/hash/streamhash.pdf I think StreamHash appears to be broken. This is what I get: Let input be an array of 62 zero bytes. The following test vector matches the written spec: Hash (256, input, 1, test); test = f1 be c9 cd 78 07 2b ae d9 db f5 0f 3a bd 0f 5a fb 3b 3d dc 19 68 7a f9 2e 5a 01 c9 a4 ef f9 4f The following strings collide: Hash (256, input, 22*8, output1); output1 = 73 e9 a6 40 d5 72 12 0b 23 c2 cf 86 1c 3f 45 a9 d6 98 ec 67 4d 02 f3 cc de 56 bc 8d b2 69 82 77 Hash (256, input, 62*8, output2); output2 = 73 e9 a6 40 d5 72 12 0b 23 c2 cf 86 1c 3f 45 a9 d6 98 ec 67 4d 02 f3 cc de 56 bc 8d b2 69 82 77 output1 xor output2 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 It seems we get into an internal state cycle that repeats every 40 bytes. Do you agree? Cheers, Tor E. Bjørstad -- Tor E. Bjørstad - PhD student, Dept. of Informatics, UiB, Norway Mail: tor.bjorstad@ii.uib.no - Web: http://www.ii.uib.no/~tor/ From hash-forum@nist.gov Thu Dec 11 17:30:59 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBC1Uqat020607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 Dec 2008 17:30:53 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBC12YgG020634; Thu, 11 Dec 2008 20:02:35 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBC10g2q009634; Thu, 11 Dec 2008 20:00:42 -0500 Date: Thu, 11 Dec 2008 20:00:42 -0500 Message-Id: <5574ACE4ACD88E45A7026FA0E350334B039F09@cleopatra.spyrus.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Robert Jueneman" To: Multiple recipients of list Subject: Using multi-core capabilities in the hash function X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit X-To: References: <888E37A2001E364CBC4F28FA7660A2E65E26A65824@NA-EXMSG-C102.redmond.corp.microsoft.com> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 11 Dec 2008 17:30:54 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 310 Nice analysis, Neils, both from the smart card and OS CPU perspective. Of course, we (SPYRUS) have a significant interest in both ends of the hardware spectrum. Bob -----Original Message----- From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Niels Ferguson Sent: Thursday, December 11, 2008 1:22 AM To: Multiple recipients of list Subject: [SPAM] - Using multi-core capabilities in the hash function - Found word(s) list error in the Text body Already most new machines are multi-core. But that does not mean that the hash function gets to use multiple cores. The first problem is a software problem: the crypto libraries live at the very lowest layers of the software stack. At that layer you cannot start a new thread, perform thread signaling, etc. There are several reasons for this. First, quite a bit of crypto is done while holding some locks that you also need to schedule CPUs. For example, in Windows the IPsec processing of a received IP packet is done at a software interrupt (dispatch) level for performance reasons. When running at that interrupt level you cannot start a thread or even signal another thread to wake up. Another situation is the boot process: the crypto libraries are used long before the kernel is running, so there are no threads. Of course, we could create different crypto libraries for the different environments, but that has a quite significant cost in terms of development, testing, maintenance, FIPS certification, etc. The second problem is that we are now optimizing for power consumption, as power will the be limiting factor in future CPUs. (Battery life is already a major limiting factor for laptops.) A function that performs 30 cycles/byte work spread over 5 cores will run at 6 cycle-times/byte, but it will consume power for 30 cycles/byte. And if we want to do things like checking the integrity of every byte read off the disk, we have to process a huge amount of data. The third problem is the bandwidth on the interconnection bus. Applications try to keep data local to the core the thread is running on. OSes have various NUMA-aware optimizations and APIs that support that. If the hash function splits the work over multiple cores then the data has to be transferred from the local memory or memory cache to the remote core. This can impose a significant load on the interconnect bus, which is a critical system resource. There are probably other obstacles as well. I have not yet done a full analysis of this problem space. Some of the problems can be alleviated, but at first glance this would require major changes to multiple APIs throughout the software layers. As these are public APIs, and they need to maintain backward compatibility, they are immensely expensive to change. My team is responsible for the crypto libraries in the Windows operating system. At the moment the infrastructure does not support a hash function that uses multiple threads, and it is unlikely that such support will be available in the next few releases. There are of course applications where using the parallelism might be useful. I had a look and we can use some of the extension flexibility in the existing Windows crypto infrastructure to let applications compute the individual pieces of a parallelizable hash function. But the application is then responsible for combining the pieces in the right way. This is both error-prone, and requires separate FIPS validation if you want to sell the application to the federal government, so most applications will not go down this path. If the hash function is fast enough then none of the parallelism support is necessary, which eliminates all the problems I've mentioned. Cheers! Niels ________________________________________ From: hash-forum@nist.gov [hash-forum@nist.gov] On Behalf Of Ronald L. Rivest [rivest@mit.edu] Sent: Tuesday, December 09, 2008 8:12 PM To: Multiple recipients of list Subject: Re: Engineering comparison of the SHA-3 candidates Nice "looking under the lamppost" chart... Of course, each designer gets to pick his own lamppost(s) ... :-) (even if one is focussed on engineering...) My first lamppost would shine light on those designs that take advantage of the forthcoming flood of multicore processors, rather than the proposed 64-bit unicore lamppost (you may not be even able to buy 64-bit unicore processors soon!). Probably most of the tree-based designs will be able to saturate memory bandwidth with a reasonable number of cores. The sequential (e.g. Merkle-Damgard) designs will be stuck in low gear with no way to speed up... My second lamppost would be for submitted designs that offer reasonable security proofs for their mode of operation and for their compression function. While some of "proof-less" designs (i.e. designs submitted without much in the way of proofs) may turn out to be secure, the burden should be (or should have been) on the designers first of all to supply the relevant proofs. Your lampposts may vary... Cheers, Ron On 12/9/2008 6:01 PM, Niels Ferguson wrote: > The Skein team has been working on an engineering comparison of the > SHA-3 candidate algorithms. Our results are available at > > > > http://www.skein-hash.info/sha3-engineering > > > > This is essentially our rating of the competitors, and we'll use this to > target our analysis efforts on those algorithms that have the best > engineering properties. > > > > So far we've only done a first ordering based mostly on speed. The > current top 5 algorithms are: > > > > Edon-R > > Blue Midnight Wish > > Skein > > SHAMATA > > Sarmal > > > > which all run in less than 10 cycles/byte. > > > > We're planning to keep this page up to date as we develop more results. > > > > > > Cheers! > > > > Niels Ferguson > > > -- Ronald L. Rivest Room 32-G692, Stata Center, MIT, Cambridge MA 02139 Tel 617-253-5880, Email From hash-forum@nist.gov Thu Dec 11 23:07:39 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBC77W7t019226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 Dec 2008 23:07:34 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBC75obN031144; Fri, 12 Dec 2008 02:05:54 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBC74G6l005124; Fri, 12 Dec 2008 02:04:16 -0500 Date: Fri, 12 Dec 2008 02:04:16 -0500 Message-Id: <200812121450263120358@gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "catmaniii" To: Multiple recipients of list Subject: Cryptanalysis of the Hash Function LUX-256 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/mixed; boundary="=====001_Dragon662276615844_=====" Mime-Version: 1.0 X-To: "hash-forum" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 11 Dec 2008 23:07:35 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 311 This is a multi-part message in MIME format. --=====001_Dragon662276615844_===== Content-Type: multipart/alternative; boundary="=====003_Dragon662276615844_=====" --=====003_Dragon662276615844_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Hi all, We have found some non-random properties of LUX due to the weakness of origin shift vector (0,1,3,4). We also give reduced blank round collision attack, free-start collision attack and free-start preimage attack on LUX-256. The two collision attacks are trivial. The free-start preimage attack has complexity of about 2^80 and requires negligible memory. Best regards, Shuang Wu State Key Laboratory of Information Security, Chinese Academy of Sciences. 2008-12-12 --=====003_Dragon662276615844_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 7bit
Hi all,
 
We have found some non-random properties of LUX due to the
weakness of origin shift vector (0,1,3,4). We also give reduced blank
round collision attack, free-start collision attack and free-start
preimage attack on LUX-256. The two collision attacks are trivial.
The free-start preimage attack has complexity of about 2^80 and
requires negligible memory.
 
 
Best regards,
Shuang Wu
 
State Key Laboratory of Information Security,
Chinese Academy of Sciences.
2008-12-12
--=====003_Dragon662276615844_=====-- --=====001_Dragon662276615844_===== Content-Type: application/octet-stream; name="Cryptanalysis of the Hash Function LUX-256.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Cryptanalysis of the Hash Function LUX-256.pdf" JVBERi0xLjQKOSAwIG9iago8PAovVHlwZS9Gb250Ci9TdWJ0eXBlL1R5cGUxCi9OYW1lL0YxCi9G b250RGVzY3JpcHRvciA4IDAgUgovQmFzZUZvbnQvWFRJTUVIK0NNQlgxMgovRmlyc3RDaGFyIDMz Ci9MYXN0Q2hhciAxOTYKL1dpZHRoc1szNDMgNTgxIDkzOCA1NjMgOTM4IDg3NSAzMTMgNDM4IDQz OCA1NjMgODc1IDMxMyAzNzUgMzEzIDU2MyA1NjMgNTYzIDU2MyA1NjMKNTYzIDU2MyA1NjMgNTYz IDU2MyA1NjMgMzEzIDMxMyAzNDMgODc1IDUzMSA1MzEgODc1IDg1MCA4MDAgODEzIDg2MiA3Mzgg NzA3IDg4NCA4ODAKNDE5IDU4MSA4ODEgNjc2IDEwNjcgODgwIDg0NSA3NjkgODQ1IDgzOSA2MjUg NzgyIDg2NSA4NTAgMTE2MiA4NTAgODUwIDY4OCAzMTMgNTgxCjMxMyA1NjMgMzEzIDMxMyA1NDcg NjI1IDUwMCA2MjUgNTEzIDM0NCA1NjMgNjI1IDMxMyAzNDQgNTk0IDMxMyA5MzggNjI1IDU2MyA2 MjUgNTk0CjQ1OSA0NDQgNDM4IDYyNSA1OTQgODEzIDU5NCA1OTQgNTAwIDU2MyAxMTI1IDU2MyA1 NjMgNTYzIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDY3NiA5MzggODc1IDc4NyA3NTAgODgwIDgxMyA4NzUgODEzIDg3NQow IDAgODEzIDY1NiA2MjUgNjI1IDkzOCA5MzggMzEzIDM0NCA1NjMgNTYzIDU2MyA1NjMgNTYzIDg1 MCA1MDAgNTc0IDgxMyA4NzUgNTYzIDEwMTkKMTE0NCA4NzUgMzEzIDU2M10KPj4KZW5kb2JqCjEy IDAgb2JqCjw8Ci9UeXBlL0ZvbnQKL1N1YnR5cGUvVHlwZTEKL05hbWUvRjIKL0ZvbnREZXNjcmlw dG9yIDExIDAgUgovQmFzZUZvbnQvWlVNVkdUK0NNUjEwCi9GaXJzdENoYXIgMzMKL0xhc3RDaGFy IDE5NgovV2lkdGhzWzI3OCA1MDAgODMzIDUwMCA4MzMgNzc4IDI3OCAzODkgMzg5IDUwMCA3Nzgg Mjc4IDMzMyAyNzggNTAwIDUwMCA1MDAgNTAwIDUwMAo1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAy NzggMjc4IDI3OCA3NzggNDcyIDQ3MiA3NzggNzUwIDcwOCA3MjIgNzY0IDY4MSA2NTMgNzg1IDc1 MAozNjEgNTE0IDc3OCA2MjUgOTE3IDc1MCA3NzggNjgxIDc3OCA3MzYgNTU2IDcyMiA3NTAgNzUw IDEwMjggNzUwIDc1MCA2MTEgMjc4IDUwMAoyNzggNTAwIDI3OCAyNzggNTAwIDU1NiA0NDQgNTU2 IDQ0NCAzMDYgNTAwIDU1NiAyNzggMzA2IDUyOCAyNzggODMzIDU1NiA1MDAgNTU2IDUyOAozOTIg Mzk0IDM4OSA1NTYgNTI4IDcyMiA1MjggNTI4IDQ0NCA1MDAgMTAwMCA1MDAgNTAwIDUwMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCA2MjUgODMzIDc3OCA2OTQgNjY3IDc1MCA3MjIgNzc4IDcyMiA3NzgKMCAwIDcyMiA1ODMg NTU2IDU1NiA4MzMgODMzIDI3OCAzMDYgNTAwIDUwMCA1MDAgNTAwIDUwMCA3NTAgNDQ0IDUwMCA3 MjIgNzc4IDUwMCA5MDMKMTAxNCA3NzggMjc4IDUwMF0KPj4KZW5kb2JqCjE1IDAgb2JqCjw8Ci9U eXBlL0ZvbnQKL1N1YnR5cGUvVHlwZTEKL05hbWUvRjMKL0ZvbnREZXNjcmlwdG9yIDE0IDAgUgov QmFzZUZvbnQvWkNCV1BLK0NNUjkKL0ZpcnN0Q2hhciAzMwovTGFzdENoYXIgMTk2Ci9XaWR0aHNb Mjg1IDUxNCA4NTYgNTE0IDg1NiA3OTkgMjg1IDQwMCA0MDAgNTE0IDc5OSAyODUgMzQzIDI4NSA1 MTQgNTE0IDUxNCA1MTQgNTE0CjUxNCA1MTQgNTE0IDUxNCA1MTQgNTE0IDI4NSAyODUgMjg1IDc5 OSA0ODUgNDg1IDc5OSA3NzEgNzI4IDc0MiA3ODUgNjk5IDY3MSA4MDYgNzcxCjM3MSA1MjggNzk5 IDY0MiA5NDIgNzcxIDc5OSA2OTkgNzk5IDc1NiA1NzEgNzQyIDc3MSA3NzEgMTA1NiA3NzEgNzcx IDYyOCAyODUgNTE0CjI4NSA1MTQgMjg1IDI4NSA1MTQgNTcxIDQ1NyA1NzEgNDU3IDMxNCA1MTQg NTcxIDI4NSAzMTQgNTQyIDI4NSA4NTYgNTcxIDUxNCA1NzEgNTQyCjQwMiA0MDUgNDAwIDU3MSA1 NDIgNzQyIDU0MiA1NDIgNDU3IDUxNCAxMDI4IDUxNCA1MTQgNTE0IDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDY0MiA4NTYg Nzk5IDcxNCA2ODUgNzcxIDc0MiA3OTkgNzQyIDc5OQowIDAgNzQyIDYwMCA1NzEgNTcxIDg1NiA4 NTYgMjg1IDMxNCA1MTQgNTE0IDUxNCA1MTQgNTE0IDc3MSA0NTcgNTE0IDc0MiA3OTkgNTE0IDky OAoxMDQyIDc5OSAyODUgNTE0XQo+PgplbmRvYmoKMTggMCBvYmoKPDwKL1R5cGUvRm9udAovU3Vi dHlwZS9UeXBlMQovTmFtZS9GNAovRm9udERlc2NyaXB0b3IgMTcgMCBSCi9CYXNlRm9udC9YQkpE U0IrQ01CWDkKL0ZpcnN0Q2hhciAzMwovTGFzdENoYXIgMTk2Ci9XaWR0aHNbMzYwIDYxOCA5ODYg NTkyIDk4NiA5MjAgMzI5IDQ2MCA0NjAgNTkyIDkyMCAzMjkgMzk0IDMyOSA1OTIgNTkyIDU5MiA1 OTIgNTkyCjU5MiA1OTIgNTkyIDU5MiA1OTIgNTkyIDMyOSAzMjkgMzYwIDkyMCA1NTkgNTU5IDky MCA4OTMgODQxIDg1NSA5MDcgNzc3IDc0NCA5MzAgOTI0CjQ0NiA2MTEgOTI2IDcxMSAxMTIyIDky NCA4ODkgODA4IDg4OSA4ODcgNjU3IDgyMyA5MDkgODkzIDEyMjIgODkzIDg5MyA3MjMgMzI5IDYx OAozMjkgNTkyIDMyOSAzMjkgNTc1IDY1NyA1MjYgNjU3IDU0MyAzNjIgNTkyIDY1NyAzMjkgMzYy IDYyNSAzMjkgOTg2IDY1NyA1OTIgNjU3IDYyNQo0ODggNDY3IDQ2MCA2NTcgNjI1IDg1NSA2MjUg NjI1IDUyNiA1OTIgMTE4MyA1OTIgNTkyIDU5MiAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA3MTEgOTg2IDkyMCA4MjcgNzg5 IDkyNCA4NTUgOTIwIDg1NSA5MjAKMCAwIDg1NSA2OTAgNjU3IDY1NyA5ODYgOTg2IDMyOSAzNjIg NTkyIDU5MiA1OTIgNTkyIDU5MiA4OTMgNTI2IDYxNyA4NTUgOTIwIDU5MiAxMDcxCjEyMDIgOTIw IDMyOSA1OTJdCj4+CmVuZG9iagoyMSAwIG9iago8PAovVHlwZS9Gb250Ci9TdWJ0eXBlL1R5cGUx Ci9OYW1lL0Y1Ci9Gb250RGVzY3JpcHRvciAyMCAwIFIKL0Jhc2VGb250L1RXVENJWitDTVI2Ci9G aXJzdENoYXIgMzMKL0xhc3RDaGFyIDE5NgovV2lkdGhzWzM1MiA2MTEgMTAwMCA2MTEgMTAwMCA5 MzUgMzUyIDQ4MSA0ODEgNjExIDkzNSAzNTIgNDE3IDM1MiA2MTEgNjExIDYxMSA2MTEKNjExIDYx MSA2MTEgNjExIDYxMSA2MTEgNjExIDM1MiAzNTIgMzUyIDkzNSA1NzkgNTc5IDkzNSA4OTYgODUx IDg3MCA5MTYgODE5IDc4NiA5NDIKODk2IDQ0MyA2MjQgOTI5IDc1NCAxMDkxIDg5NiA5MzUgODE5 IDkzNSA4ODMgNjc2IDg3MCA4OTYgODk2IDEyMjAgODk2IDg5NiA3NDEgMzUyCjYxMSAzNTIgNjEx IDM1MiAzNTIgNjExIDY3NiA1NDYgNjc2IDU0NiAzODQgNjExIDY3NiAzNTIgMzg0IDY0NCAzNTIg MTAwMCA2NzYgNjExCjY3NiA2NDQgNDgxIDQ4OCA0ODEgNjc2IDY0NCA4NzAgNjQ0IDY0NCA1NDYg NjExIDEyMjIgNjExIDYxMSA2MTEgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNzU0IDEwMDAgOTM1IDgzMSA4MDYgODk2IDg3 MCA5MzUKODcwIDkzNSAwIDAgODcwIDczNiA3MDQgNzA0IDEwNTYgMTA1NiAzNTIgMzg0IDYxMSA2 MTEgNjExIDYxMSA2MTEgODk2IDU0NiA2MTEgODcwCjkzNSA2MTEgMTA3OCAxMjA3IDkzNSAzNTIg NjExXQo+PgplbmRvYmoKMjQgMCBvYmoKPDwKL1R5cGUvRm9udAovU3VidHlwZS9UeXBlMQovTmFt ZS9GNgovRm9udERlc2NyaXB0b3IgMjMgMCBSCi9CYXNlRm9udC9WWU1RU1ErQ01CWDEwCi9GaXJz dENoYXIgMzMKL0xhc3RDaGFyIDE5NgovV2lkdGhzWzM1MCA2MDMgOTU4IDU3NSA5NTggODk0IDMx OSA0NDcgNDQ3IDU3NSA4OTQgMzE5IDM4MyAzMTkgNTc1IDU3NSA1NzUgNTc1IDU3NQo1NzUgNTc1 IDU3NSA1NzUgNTc1IDU3NSAzMTkgMzE5IDM1MCA4OTQgNTQzIDU0MyA4OTQgODY5IDgxOCA4MzEg ODgyIDc1NiA3MjQgOTA0IDkwMAo0MzYgNTk0IDkwMSA2OTIgMTA5MiA5MDAgODY0IDc4NiA4NjQg ODYyIDYzOSA4MDAgODg1IDg2OSAxMTg5IDg2OSA4NjkgNzAzIDMxOSA2MDMKMzE5IDU3NSAzMTkg MzE5IDU1OSA2MzkgNTExIDYzOSA1MjcgMzUxIDU3NSA2MzkgMzE5IDM1MSA2MDcgMzE5IDk1OCA2 MzkgNTc1IDYzOSA2MDcKNDc0IDQ1NCA0NDcgNjM5IDYwNyA4MzEgNjA3IDYwNyA1MTEgNTc1IDEx NTAgNTc1IDU3NSA1NzUgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNjkyIDk1OCA4OTQgODA2IDc2NyA5MDAgODMxIDg5NCA4 MzEgODk0CjAgMCA4MzEgNjcxIDYzOSA2MzkgOTU4IDk1OCAzMTkgMzUxIDU3NSA1NzUgNTc1IDU3 NSA1NzUgODY5IDUxMSA1OTcgODMxIDg5NCA1NzUgMTA0MgoxMTY5IDg5NCAzMTkgNTc1XQo+Pgpl bmRvYmoKMjcgMCBvYmoKPDwKL1R5cGUvRm9udAovU3VidHlwZS9UeXBlMQovTmFtZS9GOAovRm9u dERlc2NyaXB0b3IgMjYgMCBSCi9CYXNlRm9udC9SR0JDVk4rQ01NSTEwCi9GaXJzdENoYXIgMzMK L0xhc3RDaGFyIDE5NgovV2lkdGhzWzYyMiA0NjYgNTkxIDgyOCA1MTcgMzYzIDY1NCAxMDAwIDEw MDAgMTAwMCAxMDAwIDI3OCAyNzggNTAwIDUwMCA1MDAgNTAwIDUwMAo1MDAgNTAwIDUwMCA1MDAg NTAwIDUwMCA1MDAgMjc4IDI3OCA3NzggNTAwIDc3OCA1MDAgNTMxIDc1MCA3NTkgNzE1IDgyOCA3 MzggNjQzIDc4Ngo4MzEgNDQwIDU1NSA4NDkgNjgxIDk3MCA4MDMgNzYzIDY0MiA3OTEgNzU5IDYx MyA1ODQgNjgzIDU4MyA5NDQgODI4IDU4MSA2ODMgMzg5IDM4OQozODkgMTAwMCAxMDAwIDQxNyA1 MjkgNDI5IDQzMyA1MjAgNDY2IDQ5MCA0NzcgNTc2IDM0NSA0MTIgNTIxIDI5OCA4NzggNjAwIDQ4 NSA1MDMKNDQ2IDQ1MSA0NjkgMzYxIDU3MiA0ODUgNzE2IDU3MiA0OTAgNDY1IDMyMiAzODQgNjM2 IDUwMCAyNzggMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgNjE1IDgzMyA3NjMgNjk0IDc0MiA4MzEgNzgwIDU4MyA2NjcgNjEy CjAgMCA3NzIgNjQwIDU2NiA1MTggNDQ0IDQwNiA0MzggNDk3IDQ2OSAzNTQgNTc2IDU4MyA2MDMg NDk0IDQzOCA1NzAgNTE3IDU3MSA0MzcgNTQwCjU5NiA2MjYgNjUxIDI3OF0KPj4KZW5kb2JqCjMw IDAgb2JqCjw8Ci9UeXBlL0ZvbnQKL1N1YnR5cGUvVHlwZTEKL05hbWUvRjkKL0ZvbnREZXNjcmlw dG9yIDI5IDAgUgovQmFzZUZvbnQvUFRJVUtZK0NNUjcKL0ZpcnN0Q2hhciAzMwovTGFzdENoYXIg MTk2Ci9XaWR0aHNbMzIzIDU2OSA5MzggNTY5IDkzOCA4NzcgMzIzIDQ0NiA0NDYgNTY5IDg3NyAz MjMgMzg1IDMyMyA1NjkgNTY5IDU2OSA1NjkgNTY5CjU2OSA1NjkgNTY5IDU2OSA1NjkgNTY5IDMy MyAzMjMgMzIzIDg3NyA1MzkgNTM5IDg3NyA4NDMgNzk5IDgxNSA4NjAgNzY4IDczNyA4ODQgODQz CjQxMyA1ODMgODc0IDcwNiAxMDI4IDg0MyA4NzcgNzY4IDg3NyA4MjkgNjMxIDgxNSA4NDMgODQz IDExNTEgODQzIDg0MyA2OTIgMzIzIDU2OQozMjMgNTY5IDMyMyAzMjMgNTY5IDYzMSA1MDggNjMx IDUwOCAzNTQgNTY5IDYzMSAzMjMgMzU0IDYwMCAzMjMgOTM4IDYzMSA1NjkgNjMxIDYwMAo0NDYg NDUzIDQ0NiA2MzEgNjAwIDgxNSA2MDAgNjAwIDUwOCA1NjkgMTEzOSA1NjkgNTY5IDU2OSAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCA3MDYgOTM4IDg3NyA3ODIgNzU0IDg0MyA4MTUgODc3IDgxNSA4NzcKMCAwIDgxNSA2Nzgg NjQ3IDY0NyA5NzAgOTcwIDMyMyAzNTQgNTY5IDU2OSA1NjkgNTY5IDU2OSA4NDMgNTA4IDU2OSA4 MTUgODc3IDU2OSAxMDE0CjExMzcgODc3IDMyMyA1NjldCj4+CmVuZG9iagozMyAwIG9iago8PAov VHlwZS9Gb250Ci9TdWJ0eXBlL1R5cGUxCi9OYW1lL0YxMAovRm9udERlc2NyaXB0b3IgMzIgMCBS Ci9CYXNlRm9udC9SSE1QRkgrQ01NSTcKL0ZpcnN0Q2hhciAzMwovTGFzdENoYXIgMTk2Ci9XaWR0 aHNbNzIwIDU0MCA2OTAgOTUwIDU5MyA0MzkgNzUxIDExMzkgMTEzOSAxMTM5IDExMzkgMzM5IDMz OSA1ODUgNTg1IDU4NSA1ODUgNTg1CjU4NSA1ODUgNTg1IDU4NSA1ODUgNTg1IDU4NSAzMzkgMzM5 IDg5MyA1ODUgODkzIDU4NSA2MTAgODU5IDg2MyA4MTkgOTM0IDgzOSA3MjUgODg5CjkzNiA1MDYg NjMyIDk2MCA3ODQgMTA4OSA5MDUgODY5IDcyNyA5MDAgODYxIDcwMSA2NzUgNzc4IDY3NSAxMDc0 IDkzNyA2NzIgNzc4IDQ2Mgo0NjIgNDYyIDExMzkgMTEzOSA0NzggNjIwIDUwMiA1MTEgNTk1IDU0 MiA1NTcgNTU3IDY2OSA0MDQgNDczIDYwNyAzNjEgMTAxNCA3MDYgNTY0CjU4OSA1MjQgNTMwIDUz OSA0MzIgNjc1IDU3MSA4MjYgNjQ4IDU3OSA1NDYgMzk5IDQ0MiA3MzAgNTg1IDMzOSAwIDAgMCAw IDAgMCAwIDAgMAowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCA2OTQgOTU0IDg2OSA3OTggODQ0IDkzNiA4ODYgNjc4IDc3MAo3MTcgMCAwIDg4MCA3NDMgNjQ4 IDYwMCA1MTkgNDc2IDUyMCA1ODkgNTQ0IDQyMyA2NjkgNjc4IDY5NSA1NzMgNTIwIDY2OCA1OTMg NjYyIDUyNwo2MzMgNjg3IDcxNCA3NTYgMzM5XQo+PgplbmRvYmoKMzUgMCBvYmoKPDwKL0ZpbHRl clsvRmxhdGVEZWNvZGVdCi9MZW5ndGggMjI4MQo+PgpzdHJlYW0KeNqdGF1z47bxvb+Cb6FmJBwJ AiDpTh9851ziJk07tTvtjO0HWIQkzlGkCpJ2nF/fXSxIkaHiu+mLQOwuFvu9CwURi6JgH7jlh+Dj /YfPcRALlggV3O+CVDKey2AjE5bmWXB/8xB+sm+nTte6emvLdrVJUhE2O1xl2B0Mffyo2wN9fV7l POzrbVc2NRH//K//bLhUq6f7v374zIOc5SrBq1TKZJIGm0SwLKar7g4rnoa9rvdwNOHhv1cZMFtt 8jwPb0y93/cNIhK4BRAGyRAFZAnsqpLOJQTo6cYkyOBGp9yGZyxLE1gjlvkbO92hDoKHP5k3/EjC n/UzQZyaALitd409aq8SIO7Mtrdlh8K+rTIVrgl8W7dd2fUDw+H4XbNzpK8rnofaGpQrUJylmQg2 ccRymZOhD2VtWn/4eqsLc6QbABCfuW1LU29N67hwwQRXMy43ZovnshCUgF9jiV9Cp3kUZWQXMbFL DOcjmQUbwRnPlONz/dx2Vm875i76/t6FysSYcZIzxcF/cQqx4o6Ap1cbkaUhxgmuGpcsrM0r7Q8u TBC0G0MEd23/fCy7zhRE1jUE/uX27v47z+rux+tN4kSBLZPxXOltczyRuuAAYMtgk8TgEFw5xClK hJCTRroczLImwCuaytD3runrgj7b5uiBdVNvrK6L5ug52GZg0ZXGs0Xn4EVoAZQx8tJRkBU98BIx J8VwPThA4m/XX8DvLaGQk1ttuS9r+m4PJUSQO/DiDmy7xjLCQajL0HGLQ121DZHtyxevF9JYU/Rb Z1zYPFe6/jITkkxoSXmRxmDNqipb8k7KQ911eovsvqwJv7PGbNpO2+4r9ITWxJcvzp2sKY+bC7Lo PWZBJgZWKbLCvUtAUNjXFEbQe1eGAHxOs4YwE8kQf5as9fztcNKWL6WuGO1Ghk7iCwJ6JbjKSAkn MO6mAnPlIp4QGKGV+XUoGg7pokZBTaBUbXrPklOGykCyPM1csmU5lAsVJCyLSIIsWpQ3kI/HMRTU kchZHjla89++tMbLUpt9BdH1XFEp2sQ5FOU8nWl4NMfGvmFwzQqAOtfvFESK4DqechYl3J3yNTQH J2BW2KJdlH0podwnYE+kv6J6TXUBv4a6sKbtqTVFM6ZfkojLBKOb13QddLQYNJGuuIF4qcjBLBzs QrUtXkHJ4wLrQxKB7zFaIkhTKkkTdaftCtgoiWyg7kETGQtekqqQGqMKC9OW+xpTDXfPQ/mG79uX cqvp85fyCyKaqsRQfORKrTA7tmvqoNcQJkT4sbRvPdAqCGegfPEEzquIv4GiaR3/NPzp0CDTF6s7 Ii5doB8e4qcxftEmZIDXQ+mi9EB91okP1pzUYbR157vtUIfxm+qwQ/uim56L7mXLpSkECjoAhwpF 4eUyTEQpZJI1+rh51q0rUFGGEHBEbw1tXUGElZoLfLjmAmtRPkIJMNbUqElH7HYWAwXRf7v5HTtG e7jZDnEvWC6EN4ykjMFreQYNwLwgW2N1hYDIC0pILy2HIYRCF4FDZLZXtP+nLspmr7u+fhBPa4L9 A3nCLHXUD3KA/WDLutCH6kE9rWeuIom+r21/6h74E8ovubecTGZ2AvhgQcC4QkwUTmREb7UHQhUo 284TuC6H6HPdaj3gdKrKgSEEwlIwNHDC+VmOtd/3Y2jBDusfrhVMa52HmV87U/uqzJPJ3Y5DHIKH CprlZlhCUvQD4mhMtynrDTTTzQXxjmVRVK4qqwkPRoC7QeaWKvHgUCzKNa2jv/G8a6yTeu66TDp0 7iuicl0dcb7aFgR+7ilOL6RhW/5mKK2GDKQBeO+hmGHaUjomYzo6w0P+TQIAwWQY5NX5/NT1dx2B /Czoa6aGoK5MZYqvZazgkqlM+ox1MkrpZyg/Wkpf/ADe2L2uQaOCwM7zsO6gOLva9Npie5UCx2c/ SwOaz5nQk0K6Urq15elM6AZgOen9f5TDI3sOlya0FGW77VtyMohOrgL4bLqDvZ/usvN0x6kEIfI8 deBuck0WCoJRw50gl3EpgUCIsKSqha0HxaP5jAs5TJ7wNRlecDtLUWRBlyGG9tPxCsGTyWR2nKgH tjNzRpcNiVGj5oFKfnJdoN5WfeuVnffeaNZ1ue+6NzPPQkMbnpOTl+I7DVjGOYvzeGjA7oQb5lxu uqmOlmnifficnTnBuJNkwwjycTGhgPxKZR79F+ClePgYLrjE8FRO5JxLHigY2YTLISYljlRM5GTN aMEBHm/QDs8UfwYDQcFY8kKLQhpOmMXfyuzq6sp9pRfYwusxjeds5cIaGYP0OlM8rryNXbU5G3vb UFedySRTV+rIRJ8uGVoI+W2GFnMuM0PHPP6/DP3pkqGlyL5q6PSinS+wy9ncbenCBr/j9rhiS/0j J/4s0OLonUgrF7fgXwDwaHYTvlDj22BxUw6WTueWnt8U8/cvUkxGyUQfemDFeZjwzbNrTDyi3gmP A0ao2xrGRxyzEPeyghKvqx5rLyJ3zTJ/YwHXSPleAnPBPfpb9Zyfj+LB4KMGvxnbMBLytqbV6HHU AQL/gkaEHpWmLsU5vKzg1TNt/mQOmEiPMELQizfK4XneuP4zjjx+4sVVF4VrrkBGE9lcqSRiscje LUiKvCemeTLt+xD9KjhT/IHtYp6+m43vX3JORqJgpNz1rnMDBSgH0wl9XLBMipZRZJnUOweQJ+vN ZrDJr/1skEr3Np72tM6N/+AdOXhWhrGilf4acZ/Ol25egc0gWjyMJ5do1yPBgv+xsctT8No/wYN/ 2XXPVytJkQblZRJpSgxnHcaRr4mapFM4c/XWTdtqeIV2y+rMIwWNTnyzK5MLvQEa+sSV0MgX4YLN 9N1UE+mQyS7Op2qc9ZQ0TuIsTtupVgEOMixKspkd3VSR+VkvyfLhXwb4GosMI5K/D/dkPotbgsNs g8HW4bCWhb0haE+jW1nRdhQSvsdXDjBy2sBq6qbfHxht8PW2dHnr/4WGuaqn8bMYAeM8qs+zmFMN 19oPYUPpwQHN09B/E4AbH/f0D8FrPaf7XO7HJ0Q8PAj+9D+wpjNWCmVuZHN0cmVhbQplbmRvYmoK MzcgMCBvYmoKPDwKL0YxIDkgMCBSCi9GMiAxMiAwIFIKL0YzIDE1IDAgUgovRjQgMTggMCBSCi9G NSAyMSAwIFIKL0Y2IDI0IDAgUgovRjggMjcgMCBSCi9GOSAzMCAwIFIKL0YxMCAzMyAwIFIKPj4K ZW5kb2JqCjYgMCBvYmoKPDwKL1Byb2NTZXRbL1BERiAvVGV4dCAvSW1hZ2VDXQovRm9udCAzNyAw IFIKPj4KZW5kb2JqCjQwIDAgb2JqCjw8Ci9MZW5ndGggNzMKL0ZpbHRlci9GbGF0ZURlY29kZQov TmFtZS9JbTEKL1R5cGUvWE9iamVjdAovU3VidHlwZS9Gb3JtCi9CQm94WzAgMCAyMzg0IDMzNzBd Ci9Gb3JtVHlwZSAxCi9NYXRyaXhbMSAwIDAgMSAwIDBdCi9SZXNvdXJjZXM8PAovUHJvY1NldFsv UERGIC9JbWFnZUNdCi9FeHRHU3RhdGUgNDEgMCBSCi9YT2JqZWN0IDQyIDAgUgo+Pgo+PgpzdHJl YW0KeJwrVDDQMzKyNDcyVDAAQWROci6XfpC5QnoxV6GCoaGRqZ6lBVjc0MDEXM/QFMjSNdAzAAJD CxNDiGoLBZd8rkAgBAAVLBG6CmVuZHN0cmVhbQplbmRvYmoKNDEgMCBvYmoKPDwKL1I3IDQzIDAg Ugo+PgplbmRvYmoKNDIgMCBvYmoKPDwKL1I4IDQ0IDAgUgo+PgplbmRvYmoKNDMgMCBvYmoKPDwK L1R5cGUvRXh0R1N0YXRlCi9PUE0gMQo+PgplbmRvYmoKNDQgMCBvYmoKPDwKL1N1YnR5cGUvSW1h Z2UKL0NvbG9yU3BhY2UvRGV2aWNlUkdCCi9XaWR0aCA2NTcKL0hlaWdodCA2MTEKL0JpdHNQZXJD b21wb25lbnQgOAovRmlsdGVyL0ZsYXRlRGVjb2RlCi9EZWNvZGVQYXJtczw8Ci9QcmVkaWN0b3Ig MTUKL0NvbHVtbnMgNjU3Ci9Db2xvcnMgMwo+PgovTGVuZ3RoIDI3MzE0Cj4+CnN0cmVhbQp4nO2d f2wb533/Lz+WKkMa21lXOEOxpN8Nm5QGldUCs1ygc9wOsLW1kwSsk4ius7WltYQNkLQmkAW0sNV1 k4Wkk4R2kNKloL1go4x0ENUgszKgCzOgkNwNk9QmtTqstTpgC1cUNR1kDdE46fdjPfHj85G8O/Ko u/fz3Pv1hyGTvDfvx+c+7+d9z5G85Wc/+5lDCCGEEHhuoWcTQgghRmCkZxcKhYceeijptSCEwMHm QNzYVw9GevahQ4eef/75pNeCEAIHmwNxY189GOnZ9g2dCCFNQZpDZ2dnS0tL0itCILCvHoz0bPuG ToSQpiDNIZfL7d27N+kVIRDYVw9GerZ9QydCSFNYXV3dt28fmwNR2FcPRnq2fUMnQkhTyGQy09PT bA5EYV89GOnZ9g2dSL388z//c+WDv/ALv9De3h7/yhAc2ByEK1euXLx48Rvf+IZ+pKOj4/3vf/+u XbsSXKtEsK8ejPRs+4ZOpC7kPDxw4EDVpz760Y+OjIx86EMfinmVCAhsDs8888zv/u7vVn3qy1/+ 8ic/+cmY1ydZ7KsHIz3bvqETqQsJ2R/+8Iflj1wu9853vlM9+L3vfe9Tn/qU+vvrX/86bTudpLw5 fPazn/385z+v/tZnx//93//94z/+4/z8vJO+U8O+ejDSs+0bOpG60J79gx/84Jd/+Zf14z/84Q8f fvhhyRmStr/2ta8lt4IkMdLcHHTC/sxnPvPII494roRvbGyIo6ftKpR99WCkZ9s3dCJ1UcuzHVfb qnyKpIHUNof/+q//uu+++5xtw/7zP//zWi+7cuVKqma17asHIz3bvqETqQsfz/Z5iqSB1DaHv/mb v1FzQ6x8N/bVg5Gebd/QidRFGM/+3//9Xz3VTdJDapvDLbfcIv8ODg7Ozc0lvS5A2FcPRnq2fUMn Uhc+nj00NDQ/P//4449/+tOfTmjtSJKksznoC+Nf+9rXPvrRjya9OkDYVw9GerZ9QydSF9qzV1ZW fumXfkk9WC6Xn3rqqc9//vPSs5588kmG7HSSzuagP/24vr7OryhwY189GOnZ9g2dSF1oz67Kd7/7 3V/7tV+Lc30IDulsDryNoxb21YORnm3f0InUhb9nO6n87giiSGdzoGfXwr56MNKz7Rs6kbqo1aH+ 4z/+45lnnnnkkUcc2nZaSWdzoGfXwr56MNKz7Rs6kbrw71Bf+MIXlG3z1vEUks7moOez0/Y1Z4HY Vw9GerZ9QydSF/6eLWn713/91x32r1SSzuag7xvn5SUP9tWDkZ5t39CJ1IW/Z+v+Rc9OIaltDurz 2fzWXg/21YORnm3f0InURcicvbKy0tnZmcD6keRIbXNYWFiQbXc4VL0Z++rBSM+2b+hE6sLfs/VP G5VKpVR9tTJxUtwcrly5snv3bvV3rU9py4nzwx/+sL+/P95VSxL76sFIz7Zv6ETqoup3qgiXL1/+ 6le/qgybXwiVTtLcHNy/K5/L5d73vvepLyoQn/7+979/9uzZFH5FoH31YKRn2zd0InUR+PlsaVip ChNEk/Lm4H9qyCj2S1/6Uqo+DGZfPRjp2fYNnUhd6LvMPAwODh48ePADH/hAqroSccPmIKlanFvN bWvk1PjYxz6Wwnlu++rBSM+2b+hECGkKbA4aMe9yuSx/pHkIa189GOnZ9g2dCCFNgc2BuLGvHoz0 bPuGToSQpsDmQNzYVw9GerZ9QydCSFNgcyBu7KsHIz3bvqETIaQpsDkQN/bVg5Gebd/QiRDSFNgc iBv76sFIz7Zv6EQIaQpsDsSNffVgpGfbN3QihDQFNgfixr56MNKz7Rs6EUKaApsDcWNfPRjp2fYN nQghTYHNgbixrx6M9Gz7hk6EkKbA5kDc2FcPRnq2fUMnQkhTYHMgbuyrByM9276hEyGkKbA5EDf2 1YORnr1r165XXnklisJdd9316quvmq6we/fuUqkURWHPnj2XL182XQHhWCAosB4Ud95552uvvRZF AeFoRle44447fvrTnza8OMKhbIrIAw888NJLL0VcDRyM9OxbbrnlM5/5zO23396wwqltoqwDiMLm 5mYUhdbWVjsUEI4FggLCsUhWYWNjo6+vD+FYIChE2ZOJH8qmiKh6MNHmamGqZz/yyCMyDm1YAeSM Yo9ulgLCsUBQQDgWySp8+tOffvbZZxGOBYICPVvVg4k2VwtTPZs522GPdikgHAsEBYRjwZyNo0DP Zs6GgDlbKyR+UoEoIBwLBAWEY8GcjaNAz2bOhoA5WyskflKBKCAcCwQFhGPBnI2jQM9mzoaAOVsr JH5SgSggHAsEBYRjwZyNo0DPZs6GgDlbKyR+UoEoIBwLBAWEY8GcjaNAz2bOhoA5WyskflKBKCAc CwQFhGPBnI2jQM+2NmdvfaXr3Q8vq4ceef5njz3ku5Dr1UeevHT+j+/f0VWshDlbKyR+UoEoIBwL BAWEY8GcjaNAz7Y2ZxceveXQ49cfC/Lhm14c7PDNhzlbKyR+UoEoIBwLBAWEY8GcjaNAz7Y2Z79l w0eOHFleXvY37bdCtpjm448/nphnM2c77NEuBYRjgaCAcCyYs3EU6Nm25+xHnn/eOXTI14mvW3bw K3cO5mytkPhJBaKAcCwQFBCOBXM2jgI92/acLQb8O8/e4mfFoV+4kzBna4XETyoQBYRjgaCAcCyY s3EU6Nn25+yfPea8dZm86vVx9brt57YeTdKzmbMd9miXAsKxQFBAOBbM2TgK9OwU5OzHHnrr6nc1 03ZZ9v2FRD2bOdthj3YpIBwLBAWEY8GcjaNAz05Dzn7IqWXaeip726WT9WzmbIc92qWAcCwQFBCO BXM2jgI9OxU5+8bnr2/245stO2HPZs522KNdCgjHAkEB4VgwZ+Mo0LPTkbOr/D/cS2Jbaebs6wqJ n1QgCgjHAkEB4VgwZ+Mo0LNTkrNrP+C6Xs6cjaCQ+EkFooBwLBAUEI4FczaOAj07NTn7xresKJOu MsVdY5E4PPyOO+54/fXXoyjcdtttb7zxhukKMmq5evUqFRCOBYICwrFAUEA4FggKt95665tvvtnw 4giHsikid99995UrVyKuBg41Pfsm03Zunsp2P5+EZ6+uru7bt6+lpaXWC9797nc///zz999/f8Nv IVE+4tAsukKqiH7IrAehJhEU/EslhuZgBCnZzEAC68E4anu2K1uPbb678jJ4gtfGM5nM9PT03r17 a72Anm0cbDGBINQkgoJ/qcTQHIwgJZsZSGA9GIePZ9/0Y19OhTsn6NnM2fbBFhMIQk0iKDBnhyEl mxlIqnL2zaZd8WntykW2X/5gDB7OnG0fbDGBINQkggJzdhhSspmBpCtn33i82leZJujZzNn2wRYT CEJNIigwZ4chJZsZSMpytt8TzNk7rpAq2GICQahJBAXm7DCkZDMDsTZnNwXm7OYqpAq2mEAQahJB gTk7DCnZzECszdlNIamcPT8/f+zYMfdRqazX8fHxkydPhj9yCL0pVbDFBIJQkwgKzNlhSMlmBsKc 7UdSOXtgYGD37t1yYPQLPPWaz+cnJibW1tbCvwVCb0oVbDGBINQkggJzdhhSspmBMGf7kVTOLhaL HR0d58+fl2OjHnHXa7lcbmtrm5ubO3LkSPi3QOhNqYItJhCEmkRQYM4OQ0o2MxDmbD8SnM+emZl5 7rnnxLbVf931evr06QsXLiwuLtb1Fgi9KVWwxQSCUJMICszZYUjJZgbCnO1HgveNS5g+cODAyZMn e3p6HFe9SgSXkL22tlZv7SL0plTBFhMIQk0iKDBnhyElmxkIczYEVYdOhUJBDs+lS5fkcV2vlVPd IUHoTamCLSYQhJpEUGDODkNKNjMQ5mwIag2dent729vbT506peq1VCp1dXUpF6/3LRB6U6pgiwkE oSYRFJizw5CSzQyEORuCWkMnfSX80KFDUq9ytI4ePTo4ONjAWyD0plTBFhMIQk0iKDBnhyElmxkI czYEPkMndcfZ+vr68ePHz507V9fnu9wg9KZUwRYTCEJNIigwZ4chJZsZCHM2BD5DJ/XJLgnc8reU bGdnZ2NvgdCbUgVbTCAINYmgwJwdhpRsZiDM2RD4D53y+Xxvb29PT0+9n+9yg9CbUgVbTCAINYmg wJwdhpRsZiB25uz3vOc93/nOd6KoPPDAAy+99FKz1imQqkMnSdji1ktLSxKy5QXve9/73vnOd3Z3 d4t57969u963QOhNqYItJhCEmkRQYM4OQ0o2MxA7c7acRadOnYqiIovH6U+VQ6fl5eWhoaHOzk4x aXlc3YNWKpXEwguFwsmTJ48dO1bXWyD0plTBFhMIQk0iKDBnhyElmxmInTnbOM92D53EmEdHRyVb Z7NZfWDcfaHqCwJB6E2pgi0mEISaRFBgzg5DSjYzEObs6iSVs8WPJVIPDw97YnRlX5AgPjExkcvl QhYxQm9KFWwxgSDUJIICc3YYUrKZgTBnV6e5nr2wsLC0tHTy5MnW1taqL9BDp4GBgYMHD1Ze967a FwqFgti21HGYdUDoTamCLSYQhJpEUGDODkNKNjMQ5uzqND1nz8zMiL+KGYtzV95BpoZO6+vrs7Oz +ndB3NTqC+Pj47t27Tpx4kTgCiD0plTBFhMIQk0iKDBnhyElmxkIc3Z1duLaeLFYFNvO5/Ni257v MpOhk0Twjo6OlZWVqgejVl9QPyWSy+VqJfhAhfDQs+uCLSYQhJpEUGDODkNKNjMQ5uzq7Nx8toTp oaEh+UPGSvoLUmToJH/LU9lstupSPn3h9OnTV65cmZyc9H9fhN6UKthiAkGoSQQF5uwwpGQzA2HO rs5O34O2sLAwOjr60EMPqb0vQ6e//Mu//KM/+iP1y5uV+PQFcfqBgYHA7zRF6E2pgi0mEISaRFBo es7e2tqyr/B4QimYs6sTw33jpVJpamrqzJkzw8PD//7v/y6m+8wzz9S6xO3TF8rl8p49e1577TX/ t0PoTamCLSYQhJpEUKgrZ3d0dMh/Zbhfa3FpCPKI9BObopjDE+o6zNnVibh4vdx7770/+tGPXn/9 9YYVArsGQm9KFWwxgSDUJIJCXTk7n89PTEysrKzoRzyLj4+PS87O5XJRVgkQnlAK5uzqxPP5bNn7 o6Oju3fvvvXWW7/97W//y7/8S62K9O8LYboGQm9KFWwxgSDUJIJCvfPZXV1dhw8fHhkZqVxc3FqC +MWLF23KYQqeUArm7OrstGcXi0Vxa/Fs2fs9PT3yx8mTJ+WRI0eOVH29T1/Y3Nzs7e2Vs9T/HRF6 U6pgiwkEoSYRFOqdz15fXxfb1le/3YtLK9i/f3+YD38aB08oBXN2dXbOs8vl8szMzOzs7PHjx+XU Urtehk7/7//9vzfffLPW7d8+feHMmTMvvPBCrRvOwyiEhJ5dF2wxgSDUJIJCA/eNy/heOsnc3Jx7 cfUjBTJ8t6mha3hCKZizq7NDni0nlZxsra2tstPdxSdDpz179kjglrFz1fPNpy/IyPro0aO1bjgP oxASenZdsMUEglCTCAoN3DdeKpXa2trOnz8vT6nFpYkfOHDg5MmTga3AUHhCKZizq9N0z97c3BS3 3traEreuvACuhk7z8/NOjdvfavUF9a2oYe43QehNqYItJhCEmkRQaOzz2dIuzp49u7KyohbP5/PP Pfdc1W9RtAOeUArm7Oo017PldBoaGhoeHq41z6SGTs723SWTk5P6u1Y0VftCsVg8dOiQnLRhfk4b oTelCraYQBBqEkGh4c9nd3R0SFdRvxXU29urYneUNUGGJ5SCObs6Tc/Z4q8+IyM9dJI4Ln9Xfhdp ZV8QQXnlyZMn3Z/U9AGhN6UKtphAEGoSQaHh70GT9i1WLX/IKF8Wl5dFWQ1weEIpmLOrk+DvZ8vf Esr7+vrcodzTFyS4j4+Pz83NhTTsSoUGoGfXBVtMIAg1iaAQ5XvQBgYGzpw5Ix3cvi9R8cATSsGc XZ2kfj9b/bdcLk9MTMixOXr06JEjR+Rx1RdKpdLy8vLS0pK8IJvNhrkkrkHoTamCLSYQhJpEUGg4 Zzvb19tk8cnJSf1xbVvhCaWwM2fv2rXrlVdeiaJy9913X7lypVnrFEjVoVOhUDh79qyYtJyW6hEx abHw7u7u/v7+et8CoTelCraYQBBqEkGhsZy9ubmp7jvb2tq666673vGOd8jLZJRv65Q2TyiFnTk7 +EVg9hM4dELoLGg7DRy2mEAQahJBod6cra7DiWH39PQcPnz4zJkz8uCxY8fW19dllC8NXV5f10U4 I+AJpbAzZwe/CMx+AodOCJ0FbaeBwxYTCEJNIijUlbMlXg8MDHR3d+v7XdQ8oJ4NFAufmpqq+plS o+EJpWDOhoA52z7YYgJBqEkEhfA5W5K0+lyJ+wK4x7Od6x8qGR4etun7VXhCKZizIWDOtg+2mEAQ ahJB4e1vf/uDDz44NzdXdSpaN4dyuXzgwIHKD4JWerazbdtdXV3nz5+3prnzhFIwZ0PAnG0fbDGB INQkgoKUyic+8YkvfvGLx44dO3nypGcqWjeH8fHxXbt2VX4vU1XPdur5kkQj4AmlYM6GgDnbPthi AkGoSQQFVSpi1eLKYrSTk5ODg4P6WdUc1DT22tpa5eK1PNsJ/WMERsATSsGcDQFztn2wxQSCUJMI Cu5SWV9fHxoakj+kIajvMA78MQIfzw75o39GwBNKwZwNAXO2fbDFBIJQkwgKlaUiaXt0dPTIkSOS ube2tqQ5HDp0SLu4Bx/PlmVlwUuXLkVZPRB4QimYsyFgzrYPtphAEGoSQaFqqZRKpampKYnX9913 3/Lycnt7u3SJqp+6liQt/x48eLCq+MTEhB2nLU8oRUpzdkdHx/r6egxrQwghEfnTP/3Ts2fPfupT n7rrrrsqn6Vnp4qU5mw0mLPtgy0mEISaRFCoWipbW1ujo6MSLd71rnc9/fTTXV1d2Wy26ofBfK6N S1gX8cuXL0dZPRB4QilSmrPR4Hy2fbDFBIJQkwgKnlJRX006Pz8/NjY2MjIiti3NYWhoSJL0sWPH Khf38exCoSBSIh5l9UDgCaVgzoaAOds+2GICQahJBAV3qai7zx566CHdEFRzEOeenZ09f/585eI+ ni1O397e7v7kmLnwhFIwZ0PAnG0fbDGBINQkgoIqlVKpJG4t/0pHFs/Wz+rm0NXVNTw8XPkt4rU8 e3NzU/r7ysqKHZmMJ5SCORsC5mz7YIsJBKEmERTuu+++D37wg88++6zn21QUujkUi8VDhw6JB3vu Hq/l2QcOHKj18TAT4QmlYM6GgDnbPthiAkGoSQSFt7/97b//+7//hS98oepHudzN4cyZM88991w2 m3X3iqqeLZFdXiODgCgrBgVPKAVzNgTM2fbBFhMIQk0iKPiXiqc5zMzMnD17dm5uTgdoj2erbzl9 6KGHbDJshyfUdZizIWDOtg+2mEAQahJBwb9UKpuDcmV5sLu7+8iRI9qz19fXxc4LhYLb0a2BJ5SC ORsC5mz7YIsJBKEmERTqytma+fn5paWl5eVl/Yi08qNHjw4ODtrU0DU8oRTM2RAwZ9sHW0wgCDWJ oFBvzq5EErYsXnU63Bp4QimYsyFgzrYPtphAEGoSQaGxnO3m0KFDJ0+edH9CzD54QimYsyFgzrYP tphAEGoSQSF6zqZnpwfmbAiYs+2DLSYQhJpEUGDODgNPKAVzNgTM2fbBFhMIQk0iKDBnh4EnlII5 GwLmbPtgiwkEoSYRFJizw8ATSsGcDQFztn2wxQSCUJMICszZYeAJpWDOhoA52z7YYgJBqEkEBebs MPCEUjBnQ8CcbR9sMYEg1CSCAnN2GHhCKZizIWDOtg+2mEAQahJBgTk7DDyhFMzZEDBn2wdbTCAI NYmgwJwdBp5QCuZsCJiz7YMtJhCEmkRQYM4OA08oBXM2BMzZ9sEWEwhCTSIoMGeHgSeUgjkbAuZs +2CLCQShJhEUmLPDwBNKwZwNAXO2fbDFBIJQkwgKzNlh4AmlYM6GgDnbPthiAkGoSQQF5uww8IRS MGdDwJxtH2wxgSDUJIICc3YYeEIpmLMhYM62D7aYQBBqEkGBObuSra0tzw6p3EuVr0kDzNkQMGfb Bz07EISaRFCoN2f39vaKQ8uD+pFKzza9s3d0dExOTh45ckQ/4tlLxWKxra3t5ZdftilxhoE5GwLm bPuQppPNZt2NlXhAqEkEhXpz9vz8/NLS0vnz5/UjnmKTF5w9e3ZlZSXKWiVLPp+fmJiQTdDm5NlL MnBpb28/depUUmuYFKaPxiox0leYs+3DvsuVTQehJhEUGpjPFpOW6urp6alUKJVKEkDF0U0fL3Z1 dR0+fHhkZET9172Nsk/Esy9dumRT3AwJczYEzNn2Qc8OBKEmERQamM8uFAoDAwMXL15UvdutMDo6 Kv/KIlFWCYH19XWx7bW1NbXt7m30DFlSBXM2BMzZ9kHPDgShJhEUGrtvXILmwYMHVQzVCh6fMx33 +ENv4/z8/Llz5+TvpNcuGZizIWDOtg96diAINYmg0Nh941tbWxI3JWrLU1pBqq6vr29wcDDK+uBQ LBZlG9V1frWNu3fvlkcWFxdNv/LfMMzZEDBn2wc9OxCEmkRQaPjz2RJDS6VSNptVChKyJyYmJGRH WRk0ZmZmlpaWZOvUNs7OzjpWXPlvGOZsCJiz7YOeHQhCTSIoNPz57HK5LMtKDO3t7ZV/peQsuPWs EjV7LQMU2Q/yrwxKJG0nvVKJwZwNAXO2fdCzA0GoSQSFKN+DNj8//8QTT0ja7uzsFCebm5uLsiaY FAoFMSr5Q4zq+PHj1lz5bwzmbAiYs+2Dnh0IQk0iKET8HjSJoevr62LYam47yprA0tvbm8/nxass u/LfAMzZEDBn2wc9OxCEmkRQiPh94xJDpdikj+uPMttHsVhUe6mzszPpdUkY5mwImLPtg54dCEJN Iij4e/Y999xz+fLlKPrEJvbs2fOd73yHOTthmLPtg54dCEJNIij4e7bov/baazblKhIF++rBSF9h zrYPenYgCDWJoBDo2S+//LJNuYpEwb56MNJXmLPtg54dCEJNIigwZ5Pw2FcPRvoKc7Z90LMDQahJ BIV05+ytr3S9+6u/d+n8H9+f9JqYgX31YKSvMGfbBz07EISaRFCwMWcXHr3l0OPqz0ee/9ljD9V+ ZU3Pdklc48iT9PVrmFkPfhjpK/4nrYPRWejZdUHPDgShJhEUAj370qVLPs0Bj2tu++J1iy082vW9 P/FxW1/Pdq77/baB+7t/SgK7gfUQgJ2+gtBZ6Nl1Qc8OBKEmERQCPduw864+8wzn2TePA5rwtsZi Xj0EYeT2MGfbBz07EISaRFCwMmdXhGKPpWpHVo8//3tfPfTw8rUnjtwI6J6c/ZZle9x7e/kHH3Ee f3z5+lu9JXHtmYffevDG2lR/1BwMrIcA7PQVhM5Cz64LenYgCDWJoGBbznZcxnizV9bybHnpWy/c /t+D23975rNvSN1k2jdkb34Dl1DtF5mIkfXgi5Hbw5xtH/TsQBBqEkHBupx9nbdcV8Ve/5x9w0X1 E5XXxh93Gftbi1T/s/JCuSw+1Sr/da5ZuWPy7WwG10MN7PQVhM5Cz64LenYgCDWJoGBhzr6Bzrv3 R/Psm66V62Uc18IVnv3w8k1rcv2ie5VrACZheD1UwcjtYc62D3p2IAg1iaBgbc7e5rqVfvjroTz7 xjVtH8++/p9LrVPv3hx76yHfnF17vUwL3KbXQyV2+gpCZ6Fn1wU9OxCEmkRQsCxnXzNDbaSuyWfX NLR7Dlv9fT0Ee+41c26+dezBGxZ+fbb7kRqv8L6+6moa6tlm1UMgRm4Pc7Z90LMDQahJBAX7crb7 9jHXd6HcePiR55+XM0Tn7M2xa/+9/pT7I9kuUc+lbPX0TQ9eX6LKfePXl6+xZgZhYj34Y6evIHQW enZd0LMDQahJBAXLcnZMmJqTo2JfPRi5PczZ9kHPDgShJhEU7MvZMZBWy7awHuz0FYTOQs+uC3p2 IAg1iaDAnF0/qbVsC+vByO1hzrYPenYgCDWJoMCcTcJjXz3Y6SsInYWeXRf07EAQahJBwd+zb7/9 9jfeeCOKPrGJ22677erVq0mvRTMx0leYs+2Dnh0IQk0iKDBnk/DYVw92+gpCZ6Fn1wU9OxCEmkRQ 4Hw2CY999WDk9jBn2wc9OxCEmkRQYM4m4bGvHuz0FYTOQs+uC3p2IAg1iaDAnE3CY189GLk9zNn2 Qc8OBKEmERRsz9lhP5fl+RozUhXz68GLnb6C0Fno2XVBzw4EoSYRFOzK2a5vB6386cyKV+rfwfZ8 TXltUZdwKjGtHoIxcnuYs+2Dnh0IQk0iKFiUs2+y4cKjXd/7k8pfzq7+Yv0L1+pFtX5tu3K5tGFU PYTCTl9B6Cz07LqgZweCUJMICvbk7OruHOraeJWf5Kzl2Sn+EjTHrHoIh5Hbw5xtH/TsQBBqEkHB spz9uPfKtbLY53/vq4fUr2xdf/6G9d506fuRJ5988eEbv8e1Pbu9dZNne4L2Tb/fpcRvdvWKQL+t db9rMYMuthtVD6Gw01cQOgs9uy7o2YEg1CSCgj0523EZqOeHrW/6hWyn0ljD52y/38nWY4b7XcsX Hu16Vp77nfPbr3lL6k++Z2hWN6weQmDk9jBn2wc9OxCEmkRQsChnX+et4Kx8utJ/1cR1nZ6tg7j7 vvKKy+TuFK2ekJf89a+MOYee/Z3rA4Vrt7ptp2zHwFlxI+vBFzt9BaGz0LPrgp4dCEJNIihYlbNv oBPw/TUyc2M5++bL7zdPdDuu289d5vzXv3L+MefRW66Z9v2uu9OrXBIwAGProSZGbg9ztn3QswNB qEkEBQtz9jbXfffDX2+mZ988PV0zZ+tE/TvPqrvXC9dM+1LrVMUHygy7o83ceqiFnb6C0Fno2XVB zw4EoSYRFKzJ2Td/xFpbq9Ngzr4xTe1z33jlfLa+22x7dR585HHn+kXxoc0Hnccd72fAzfNsU+oh JEZuD3O2fdCzA0GoSQSFtra2xcXF1tbWWvoG5Sr3xPOR6lk4lGd7vhXt5vvGq9145nnPGy9bdt+m fuN/NRdCx6x6CIOdvoLQWejZdUHPDgShJhEU/EuF5x1xY189GLk9zNn2Qc8OBKEmERQCPduyXEWi YF892OkrCJ2Fnl0X9OxAEGoSQYE5m4THvnowcnuYs+2Dnh0IQk0iKDBnk/DYVw92+gpCZ6Fn1wU9 OxCEmkRQ8C+V22+//Y033oiiT2zitttuu3r1atJr0UyM9BXmbPugZweCUJMICszZJDz21YOdvoLQ WejZdUHPDgShJhEUOJ9NwmNfPRi5PczZ9kHPDgShJhEUmLNJeOyrBzt9BaGz0LPrgp4dCEJNIigw Z9eJYd9c1lzsqwcjt4c52z7o2YEg1CSCgok5+6Yf7qr2jPv7xl4M/p6xm39BO+A3O9Lu2YD1EAU7 fQWhs9Cz64KeHQhCTSIomJizt634yJFlx2ud135p88Ujy8sPhvfsLc/PYhbUT3A95LtAmj0bsB6i YOT2MGfbBz07EISaRFAwNWc7zz8v617xS5hf/b0nH3z4YSf071tW/JxmIGn3bMB6iIKdvoLQWejZ dUHPDgShJhEUTM3ZYrS/82zFb3ds//zljUdd/npT5NZO7W/Z+jeur/FIpabvD5Bsjl377U21+LVl nesX4G9c0q/2soe8bwz1+9qY9RAFI7eHOds+6NmBINQkgoK5OVvZYIUPO49W9WzXhfKtm37lulZm rvLzXY94fxDMz7MfXn7LnG+efff+/rZ+WY2fHMMCsx6iYKevIHQWenZd0LMDQahJBAWDc/ZN7nZt Krv12l+FWp59Yx5cz3f7uGPVn+e8pnt/SM++8fjNYd71v8rFtzfB8UyxA4FZD1EwcnuYs+2Dnh0I Qk0iKJics28E5Q9//aaL4DU82xNsvVm6xns4N5bdHNthz3Y/s31xHOrKOGo9RMFOX0HoLPTsuqBn B4JQkwgKRufs66775JMvPnzNTx+6+UmPKd64R01fUK9t2snkbM/kOtxVcsx6iIKR28OcbR/07EAQ ahJBweyc7VR8JLumZ9+w54rb0R4/8mTFBer7K+ez1TLV58jvvx6NK+a8bfNswHqIgp2+gtBZ6Nl1 Qc8OBKEmERQMz9lOxYewq3t2LQd2HM/t4e6r0e7vWjnijuYeo338rQX1p8+iebZT7W0xwKyHKBi5 PczZ9kHPDgShJhEUTMzZJCnsqwc7fQWhs9Cz64KeHQhCTSIomJizSVLYVw9Gbg9ztn3QswNBqEkE BeZsEh776sFOX0HoLPRsH06fPt3T09Pa2qofqWzEla9JOQg1iaDAnE3CY189GLk9zNmmMzMzs7S0 JAdRP+JpxOvr611dXRcvXty9e3cyq4gHQk0iKPh79m233fbmm29G0Sc2ceutt37ve99jzkYHobPQ s/3p6OiQzitJWv3X04gPHDhw9OjRwcHBxNYPD4SaRFDgNEoYAoMNMRQjfYU52wIKhUImk7l06VJL S4tzcyPO5/MTExNra2sJryIYCDWJoODv2dIcstksHZ2erbCvHuz0FYTOQs8OpLe3t729/dSpU46r EZfLZTnNcrmcTadZU0CoSQQF5uww0LNtxUhfYc62g2Kx2NbWJnlaDqVuxGLhGxsbi4uLSa8dHAg1 iaDg79l0dAU9W2FfPdjpKwidhZ4dhtOnT1+4cEEcWp1ara2t4uIXL17cu3dv0qsGB0JNIijY14V3 Anq2rRjpK8zZ1lAul8Wk5+bmpqampBHPzs7qq+XEA0JNIigwZ4eBnq2wrx7s9BWEzkLPDom646yl peXw4cNPPPGEviuNeECoSQQF+7rwTkDPthUjfYU52zK6urqWl5fFqnO5nP70F/GAUJMICszZYaBn K+yrBzt9BaGz0LPDs76+fuDAgc7OTve3rBAPCDWJoGBfF94J6Nm2YqSvMGfbQblczufzS0tLxWLx X//1X9va2t71rnd1d3dL1ObXn1WCUJMICszZYaBnK+yrBzt9BaGz0LP9WV5eHhoakmwtJr137145 taTFlEolsfBCoSCn2bFjx5JeRywQahJBwb4uvBPQs23FSF9hzjYaMebR0VHJ1tlsVn+my727qr6A INQkggJzdhjo2Qr76sFOX0HoLPTsqogfy1k0PDzsidGVu0uC+MTERC6XY99RINQkgoJ9XXgnoGfb ipG+wpxtLgMDAwcPHqy87l11dxUKBbHtwBvTNjc35WXHjx+3u48j1CSCAnN2GOjZCvvqwU5fQegs 9OxKJDrPzs6eP3++8qlau2t8fHzXrl0nTpyoKiipXdz6zJkzclqOjIw0eXXBQKhJBAX7uvBOQM+2 FSN9hTnbRNRXnq2srFSdoq61u2SpAwcO5HK51tZWz1Pz8/Pi6P39/dLB0zDtjVCTCArM2WGgZyvs qwc7fQWhs9CzPUgafuGFF7LZbNVnfXbX6dOnr1y5Mjk5qR8pFAqjo6O7d++enp7et2/fjqwuHgg1 iaBgXxfeCejZtmKkrzBnm0hvb+/Ro0drfc2Zz+5aX18fGBhQP6ddLBaHhoZWV1fFrSVh7+Dq4oFQ kwgKzNlhoGcr7KsHO30FobPQsz20tbUtLi5WXuJW+Oyucrm8Z8+ey5cvS+CenZ0dHh4+ceJECr+T HKEmERTs68I7AT3bVoz0FeZsE3nb297205/+tOHF9+7dKyFbLD8NU9dVKRQKEY3KDoX19XU592t9 U57/s+lhdXX14sWL9Gz7Rnh2+gqC49KzPfiPtPx3lzy7trY2OjoqHVnOwPTMYbtRXxVHBSmDo0eP prMGwpPJZFZWVujZ9mGkrzBnm0hXV9fw8PCRI0eqPuuzuzY3N3t7eyU0yN8LCwvSsnt6elJyr7gb hJpEUOB8dhh4bVxhXz3Y6SsInYWe7aHy9m83PrvLc8N5uVxWn8lWE9s7tbp4INQkgoJ9XXgnoGfb ipG+wpxtIltbWxK119bWqt4+5rO7qt5wLmpDQ0Py7/T0dK3sbhkINYmgwJwdBnq2wr56sNNXEDoL PbuSU6dO6X891NpdCwsLS0tLuVyuquDy8vLo6Kg0JnHuWnekWwNCTSIo2NeFdwJ6tq0Y6SvM2YZS Lpclak9OTnZ2dnqeqrq7isWiNOiVlRX/24DVZ8DE1+3u4wg1iaDAnB0GerbCvnqw01cQOgs9uyqb m5uZTKbyu0grd5cYtrwy5PkmL7b+ljSEmkRQsK8L7wT0bFsx0leYs41mdXV1aGior6/PfQeZZ3fl 8/nx8fG5uTm2Zg1CTSIoMGeHgZ6tsK8e7PQVhM5Cz/ZB3fst5n306NEjR45IRFa7q1QqLS8vLy0t yQuy2Sy/GcMNQk0iKNjXhXcCeratGOkrzNl2UCgUzp49KyZdLBbVI2LSYuHd3d1p+y7xMCDUJIIC c3YY6NkK++rBTl9B6Cz07LoYGBg4ePDgsWPHkl4RXBBqEkHBvi68E9CzbcVIX2HOtg96diAINYmg wJwdBnq2wr56sNNXEDoLPbsu6NmBINQkgoJ9XXgnoGfbipG+wpxtH/TsQBBqEkGBOTsM9GyFffVg p68gdBZ6dl3QswNBqEkEBfu68E5Az7YVI32FOds+6NmBINQkggJzdhjo2Qr76sFOX0HoLPTsuqBn B4JQkwgK9nXhnYCebStG+gpztn3QswNBqEkEBebsMNCzFfbVg52+gtBZ6Nl1Qc8OBKEmERTs68I7 AT3bVoz0FeZs+6BnB4JQkwgKzNlhoGcr7KsHO30FobPQs+uCnh0IQk0iKNjXhXcCeratGOkrzNn2 kclkDh8+TM/2AaEmERSYs8NAz1bYVw92+gpCZ6Fn14V9p1bTQahJBAWWShjo2bZipK8wZ9sHG3Eg CDWJoMCcHQZ6tsK+erDTVxA6Cz27Luw7tZoOQk0iKLBUKimVSp4fm6/07K2tLVq4BRjpK8zZ9sFG HAhCTSIoMGdXIls9PDzc09OjH/E0yWKx2NHRsba2tnfv3mRWMSHsqwc7fQWhs9Cz68K+U6vpINQk ggJLpZJ8Pj8+Pi6W3NLSoh7xePbQ0JA8NT09ndgqkiZhpK8wZ9sHG3EgCDWJoMCcXZXe3t79+/ef OHFC/dfdJNfX17u6ui5evOi5fp4G7KsHO30FobPQs+vCvlOr6SDUJIICS6UqW1tbHR0dYszq6rfb s2WPdXd3j4yMJLyKpBkY6SvM2aZz6tSpwcFB99RaZSNeWFiQ/6Zt+s0HhJpEUGDOrsX4+Lg4dy6X c1xNMp/PT0xMrK2tJb12yWBfPdjpKwidhZ7tg3j2xsbG4uKifsRzaqX5al4tEGoSQcG+LtwsyuWy WLV4tuwc5dky5NWPJL12pDkY6SvM2aajmot4dmdnp3rE04gPHDhw/Phxfi2aG4SaRFBgzvZBp2rV JM+cOeMZHKcN++rBTl9B6Cz0bH8WFhampqb0JTv3qSWN5oknnlhZWUly/fBAqEkEBfu6cHNRs9ez s7MSr9XFKk4w2YSRvsKcbQcdHR3Dw8MqTOtGXCqV2trazp8/v2/fvqRXEAuEmkRQYM72R80rlctl 6ZBi3qdOnUp6jZLEvnqw01cQOgs9O5DV1dXe3t5Lly61tLTocdjo6Kg8xQ+SVoJQkwgK9nXhpiMn 0czMjMRrdXIlvTqkmRjpK8zZ1iCe3draOjk5qY6phGzeelYLhJpEUGDODkRdrJqbm3N/M1o6sa8e 7PQVhM5Czw5DsViU5iImfeDAAfHsTCbDW89qgVCTCAr+Xfg973nPd77znSj6wl133fXqq6+arnDH HXf89Kc/bXjxPXv2XL58OcoKRFdoish73/vejY2NiKuBg5G+wpxtE6Ojo1tbW+vr6+LWS0tLvPWs Fgg1iaDg79miL2O+iD+GcWobCxQ2NzcbXry1tTXK4k1RiC7yh3/4h9/85jdtasV2+gpCZ6Fnh0R9 7qtUKsnfYti89awWCDWJoBDo2dHvugJxXHp2s1bDplZspK9Yk7OjX8eLfgEN4QrYz//8z//kJz+J ooBwKTK6wgMPPPDSSy/VetaUqt5pBebs8Ar0bOZsM0DoLGEUomeCiKelg3FmisIHP/jBL3zhC3ff fXfDCggtMrqCT82YUtU7rcCcHV6Bnu0wZyNgTc6mZ2uFjY2Nt73tbVEUEFokPTsGBebs8Ar0bOZs M0DoLPTsmBUQWiQ9OwYF5uzwCvRshzkbAeZsDT1bKyC0SHp2DArM2eEV6NnM2WaA0Fno2TErILRI enYMCszZ4RXo2Q5zNgLM2Rp6tlZAaJH07BgUmLPDK9CzmbPNAKGz0LNjVkBokfTsGBSYs8Mr0LMd 5mwEmLM19GytgNAi6dkxKDBnh1egZzNnmwFCZ6Fnx6yA0CLp2TEoMGeHV6BnO8zZCDBna+jZWgGh RdKzY1Bgzg6vQM9mzjYDhM5Cz45ZAaFF0rNjUGDODq9Az3aYsxFgztbQs7UCQoukZ8egwJwdXoGe zZxtBgidhZ4dswJCi6Rnx6DAnB1egZ7tMGcjwJytoWdrBYQWSc+OQYE5O7wCPZs52wwQOgs9O2YF hBZJz45BgTk7vAI922HORoA5W0PP1goILZKeHYMCc3Z4BXo2c7YZIHQWenbMCggtkp4dg4K/Z+/a teuVV16Joi/cdtttb7zxhukKEXf17bfffvXq1SgrEF2hKSJSEqVSKeJq4GCkZzNna+jZWgHBcenZ MSj4e7b/szMzM5LCd+/eHWUFTCGwT9qB/2b614OJGOnZgSB0ljAK0TNB9ME4wmg6ugJCrImucPfd d1+5cqXWs6ZU9U4rROnCKbExRUo2NiWbqTHSs63J2UasBhVAFBJfARCFKDk7Vf09JRvLnG0DCJ2F nk2F5iokvgIgCszZIUnJxqZkMzVGejZzNhVSqJD4CoAoMGeHJCUby5xtAwidhZ5NheYqJL4CIArM 2SFJycamZDM1Rno2czYVUqiQ+AqAKDBnhyQlG8ucbQMInYWeTYXmKiS+AiAKzNkhScnGpmQzNUZ6 NnM2FVKokPgKgCgwZ4ckJRvLnG0DCJ2Fnk2F5iokvgIgCszZIbFyY0+dOnXixImWlhb9SOVmjo+P S4W4X2MTRno2czYVUqiQ+AqAKDBnh8TKjc1kMrJFk5OT+hHPZubz+YmJibW1NfVf5mwzQOgs9Gwq NFch8RUAUWDODomVG1ssFtva2sSS9Xa5N7NcLst/c7mcTSbtwUjPZs6mQgoVEl8BEAXm7JDYurGn T5++cOHC4uKi+q97M0+dOrWxsaGfcpizTQGhs9CzqdBchcRXAESBOTsktm6shGmJ2nNzc0eOHHFc m6ki+MWLF/fu3Zv0Ou4gRno2czYVUqiQ+AqAKDBnh8TijXVPWuvNzGQy7e3tJ06ccL+SOdsMEDoL PZsKzVVIfAVAFJizQ2L3xkoZdHd3j4yMqM2UkC2eLSHb1tvFNUZ6NnM2FVKokPgKgCgwZ4fE7o1d X1/v6uqSqH3gwAHZzN7eXjnuPT09npcxZ5sBQmehZ1OhuQqJrwCIAnN2SKzf2NHRUWf7Onl/f79Y +Pnz55Neozgw0rOZs6mQQoXEVwBEgTk7JNZvbLFY7OjoKJVKLS0tsqX79u2rfA1zthkgdBZ6NhWa q5D4CoAoMGeHJA0bOzMzI2l7ZGRkeno66XWJCSM9mzmbCilUSHwFQBT279//gQ98oFaPZs7W2L2x W1tb+Xx+aWnp3/7t3+67775f/MVfPHjwYH9/f2trq/tlzNlmgNBZ6NlUaK5C4iuAoCC56h/+4R+e eeaZ3bt3N7C43TbmweKNPX369NmzZ48cOdLd3f2Vr3zltttuO3bsWKFQOHfuXE9Pj8VfNu4Y6tnM 2VRIoULiK5CsQrlcHhgY2Lt3r/9VUOZsjZUbWywWpQz27dunjfnUqVP6X2fbzsW5c7mcCtzM2WZg dG9CWw0qgCgkvgIJKmxtbWUymeHh4f7+/ijvbqWN1cK+jZUy6OrqkkGb+gY0hcezhc3NTakWeZlN Vq0x0rOZs6mQQoXEVyAphUKhMDo6ms1mq94Y7IE5W2PKxq6vr0t0rvrpag9VD26lZzvX3X1tbU3+ Zc42AEN7E+ZqUAFEIfEVSERhZmZmaWlpcXGxsQlsD6bYWFMwaGOXl5eHhoZaW1slHHtuItOcOXPm hRdekKGb5/Gqnu1sXyS/cuWK+1c77cBIz2bOpkIKFRJfgZgVQk5ge2DO1pi1sXK4ZXw2NTV17Ngx OYKeIVqxWJQju7KyUjl0q+XZIiiLXL169bHHHmPORses3gS+GlQAUUh8BeJUaNYEtgezbCwiJm6s ePP4+LjEbrHtwcFB/fj8/PzGxsbc3FzlIrU827E0ahvp2czZVEihQuIrEJuCtGxp3CEnsD0wZ2vM 3djV1dXR0VEJymLSnZ2d8khvb+/Ro0erTnj7ePb6+voHP/jBZ555hjkbHVN6kxGrQQUQhcRXIB4F ab4XLlzI5XJNmcD2YK6NNYDpG7uwsCDOLXY7PT0tQ7HFxcWqU90+ni2uv2fPntdee22H1zRWjPRs 5mwqpFAh8RVoisLP/dzPXb16NYoCSRstLS1vvPHG66+/3tjiYhbM2egg9CZ6NhWaq5D4CjRFoRab m5sDAwNjY2OBH/iJEh9Nj551YfrGqs/4iWHPzc319vbW2hafnO3sZMUmhZHbw5xNhRQqJL4CTVGo Sj6fn5qaymaztT7n48b/9Od8tsbcjS0Wi+LW4tnT09PqJsSurq7h4WH3V6lofDxbBoLvf//7n332 WeZsdBB6Ez2bCs1VSHwFmqJQiXTbjY0NMeyQE9jM2SExcWPL5fLp06dnZ2cHBwfdXxvuY8w+T9X6 SLfRGOnZzNlUSKFC4ivQFAU3pVJpYGCgvb291oXNqjBnh8S4jc3n80NDQ52dnRKvPautvittbW2t cikfz+7t7f3P//zPL37xi8zZ6CD0Jno2FZqrkPgKNEVBE34C2wNzdkgM2lix5NHR0WKx6PkucTdi 5zK8c39oW1HLs5eXlyWvnz9/vvmrmyhGejZzNhVSqJD4CjRFQVHXBLYH5uyQmLKxYtjqqI2MjPi8 rFwud3R0iAd7tqiqZ8uL29raVlZWMpkMv2/cABB6Ez2bCs1VSHwFmqIgjI+PS8gOP4HtgTk7JPZt bKFQkOJZXFzcu3evfrDSs9W33h48eLAylFuAkZ7NnE2FFCokvgLRFUqlUm9v7+HDh0+cONGwCHN2 SKzcWPUdeZOTk/oSusez1cz38ePHlWHz97PNIPHe1BQFkNWgAohC4isQUUE10+i/asycHRJbN7ZY LEohyXZ1d3eLc2vPlgI7e/bs6upqY3MupmCkZzNnUyGFComvQBSFhYWF2dnZXC4X3UKYs0Ni98bO z88vLS1J7NaP7Nu37+jRoxKv9SfEHOZsUzC6u6GtBhVAFBJfAaUgNlDvUn/913/94x//eGxs7I47 7ti9e3cDv/zhhjk7JOnZ2B36qh9MjNxU5mwqpFAh8RUQBgYGtra2wr/+6tWrL7744jve8Y53vetd 6pHV1dVLly657yGqF+bskKRnY30KmznbDBC6Gz2bCs1VSHwF6qXqBHZ0I2HODkl6NpY5Gx3mbCqk UCHxFaiLWhPYO+3ZzNma9Gwsc7bxIHQ3ejYVmquQ+AqEpFwuj4+PF4vFbDbrvhtIwZwdG+nZWOZs dJizqZBChcRXIAxi1ZlMpru7u9Z3WjFnx0Z6NpY523gQuhs9mwrNVUh8BQJZXV0dGhqam5vr7Oys 9Rrm7NhIz8YyZ6PDnE2FFCokvgL+zM/Pnzt3LpfL+d8TzpwdG+nZWOZs40HobvRsKjRXIfEVqEW5 XB4dHZU/pqenKyewPTBnx0Z6NpY5Gx3mbCqkUCHxFaiKmsDu6+sL+XsMzNmxkZ6NZc42HoTuRs+m QnMVEl+BSsJMYHtgzo6N9GwsczY6zNlUSKFCU1aggW8edbN371796wshJ7A9MGfHRno2ljnbeBJv r01RAFkNKoAoRF+B3t7eUqkURWF9ff3ixYu7d+8OP4HtgTk7NtKzsczZ6DBnUyGFCgiNSU69p556 6rOf/Wz4CexKBebseEjPxjJnG0/i7bUpCiCrQQUQBQTPvvfee++5556vfOUr4SewPTBnx0Z6Nhbh 1IgNIzeVOZsKKVRIvDHNzMyMj49fuHDhve99b8MizNmxkZ6NZc42nsTba1MUQFaDCiAKCXp2uVwe GBjYu3dvPp9PMCVHV0iPjTlp2tjEh7NxYuSmMmdTIYUKSTWmra2tTCYzPDzc39+frOOGUWDO1qRn Y5mzjSfx9toUBZDVoAKIQiKeXSgURkdHs9nsvn37nKRTcnSF9NiYk5qNLZVKsqWXL19OekViwkjP Zs6mQgoV4vfsmZmZpaWlxcXF3bt3q0fwPZs5W5OSjd3a2pKDfunSparPMmebQeLttSkKIKtBBRCF OD1bT2BPT0+7H8f37J1+d4NIycb6e7Z9GOnZzNlUSKFCbJ7tnsD2PIXv2czZmpRsLHO2DSTeXpui ALIaVABR2LNnT8RvMVtcXOzp6fF/TT6fn5iY0BPYHvA9e6ff3SBSsrHM2QbAnE2FdCpE4dSpU/pf n9dsbGyIYesJbA/4ns2crUnJxjJn2wBCe6VnU6HpClHw92xJ8AMDA+3t7f6mju/ZO/3uBpGSjWXO NgCpxVwu5/PtiQjtlZ5NhaYrRMHHszc3N8Wwx8bGAq+c43s2c7YmJRvLnG0DCO2Vnk2FpitEoZZn 5/P5qampbDarf2TTB3zP3ul3N4iUbCxztgFILUqL8Rk6IbRXejYVmq4QhaqeHTiB7QHfs5mzNSnZ WOZsG0Bor/RsKjRdIQoezw45ge0B37N3+t0NIiUby5xtAIFDJ4T2Ss+mQtMVouD27PAT2B7wPZs5 W5OSjWXOtgGE9krPpkLTFaKgPXthYWF2djbkBLYHfM/e6Xc3iJRsLHO2ATBnUyGdClFQnn3lypVi sTg3NxdyAtsDvmczZ2tSsrHM2TaA0F7p2VRoukIUTpw4ce7cueHh4ZGRkYZF8D17p9/dIFKysczZ BsCcTYV0KjTM+vp6V1fX4cOHz5w5E0UH37OZszUp2VjmbBtAaK/0bCo0XaEx1AT2/v37d+/eXddd 4pXge/ZOv7tBpGRjmbMNgDmbCulUaIDR0dFisZjNZk+fPu0Efd94IPiezZytScnGMmfbAEJ7pWdT oekKdVEqlXp7e7u7u9UEdpjfCAkE37N3+t0NIiUby5xtAMzZVDBUIeJ4f3p6uupPZFayvr4+MDAg r9fvmBLPZs7WpGRjmbNtAKRB07Op4EZ8NMoPYJ89e/a+++4LY7pqAjuXy7n7dUo8e6ff3SBSsrHM 2QbAnE0FExUiEsZ0y+Xy6OiojAyy2WxLS0u9iweC79nM2ZqUbCxztg0gNGh6NhWaS6DpFovFTCbT 19c3ODjYwOJhwPfsnX53g0jJxjJnGwBzNhVMVIiIv+murq4ODQ3Nzc3V+l35lHg2c7YmJRvLnG0D CA2ank2F5uJjuvPz8+fOncvlcnv37m1g8fDge/ZOv7tBpGRjmbMNgDmbCiYqRKSq6aoJbGf7lnLP BHaYxesF37OZszUp2VjmbBtAaND0bCo0l0rT9Z/ADly8AfA9e6ff3SBSsrHM2QbAnE0FExUi4jHd wAls/8UbA9+zmbM1bW1ti4uLDfziqlkwZ9sAQoOmZ1OhubhNN8wEts/iDYPv2Tv97gZhn11VhTnb AJizqWCiQkSU3Z44cULidUtLS+AEdtXFrfds5mwNPduxcScY6dmBIDRoejYVmovYbalUunDhwvHj x48dO9bA4k4KPHun390g7LOrqjBnGwBzNhVMVIiI+PRzzz13/vz5kF857iElns2craFnOzbuBCM9 OxCEBk3PpkITmZmZmZ2d7evrUz+p2QAp8eydfneDsM+uqsKcbQDM2VQwUaExyuXywMDA3r17d+3a 5UQw3ZR4NnO2hp7t2LgTjPTsQBAaND2bCtGRfpTJZIaHh/v7+yOabko8e6ff3SDss6uqMGcbAHM2 FUxUqJdCoTA6OprNZtUENj07jAJztoae7di4E4z07EAQGjQ9mwpRmJmZWVpaWlxc3L17t3qEnh1d gZ5tH8zZBsCcTYX4Ffbs2VMqlRpevKWlRdwizHeW6Qns6elp9+P07DAKzNkaerZj404w0rMDQWjx 9GzLFCIiNnzw4MHAz1Vvbm5mMpmxsbH+/n7PU/Ts6Ar0bPsoFAoTExNyWJNekZgw0rOZs6kQv0JE wnh2Pp+fmprKZrNVvyOanh1GgTlbQ892bNwJRnp2IAgtnp5tmUJEAj1b3HRjY0MMW09gV77AoWcz Z4fGPruqCnO2ATBnUyF+hYj4eHapVJJn29vb/Q2Vnh1GgTlbQ892bNwJRnp2IAgtnp5tmUJEann2 5uamPDU2NtbT0+OvQM+OrkDPtg/mbANgzqZC/AoRqerZ/hPYHujZYRSYszX0bMfGnWCkZweC0OLp 2ZYpRKTSswMnsD3Qs6Mr0LPtgznbAJizqRC/QkTcnh1yAtsDPTuMAnO2hp7t2LgTjPTsQBBaPD3b MoWIaM8OP4HtgZ4dXYGebR/M2QbAnE2F+BUiojy7paVlamoql8uFmcD2QM8Oo8CcraFnOzbuBCM9 OxCEFk/PtkwhIuLZ//M//3PPPfdks1lx7gYU6NnRFejZ9sGcbQDM2VSIXyEKpVKpra1N6vbv//7v GxahZ4dRYM7W0LMdG3eCkZ4dCEKLp2dbptAw6+vr6jc/+vr6Ar9v3Ad6dnQFerZ9MGcbAHM2FeJX aIyFhYXZ2dlcLidtJcxvhPhAzw6jwJytoWc7Nu4EIz07EIQWT8+2TKEBRkdHi8WimsAO+btePtCz oyvQs+2DOdsAmLOpEL9CXZRKpd7e3u7u7pGREfUIPTseBeZsDT3bsXEnGOnZgSC0eHq2ZQrhURPY 09PT7k5Bz0ZQoGfbB3O2ATBnU6EBhShndUtLS2dnZ5hXzs/Pnz17NpfLeYyBnh2PAnO2hp7t2LgT jPTsQEBMgp6NoyCWubW11fDiEp3Pnz/vb9vlcnl0dFT+kIRd+QlsejaCAj3bPpizDUA649GjR/ft 21frBQgmQc+GUohIYPsrFouZTKavr29wcLDqC+jZ8Sj4Nwd6tn34e3agWRiHkZ4toUfOOp9fQ0Iw CXo2lEJE/Nvf6urq0NDQ3NycTxCnZ8ej4N8c6Nn24e/ZgWZhHEZ6NnM2FWLGp/3Nz8+fO3cul8vt 3bvXR4GeHY8Cc7aGnu0wZ4PAnE2FmKna/vwnsD3Qs+NRYM7W0LMd5mwQmLOpEDOV7S9wAtsDPTse BeZsDT3bYc4GgTmbCjHjaX9hJrA90LPjUWDO1tCzHeZsEJizqRAz7vYXcgLbAz07HgXmbA0922HO BoE5mwoxo9qfpGqxXim8MBPYHujZ8SgwZ2vo2Q5zNgjM2VSIGWl/x48fn52dHR4e7u/vb0CBnh2P AnO2hp7tMGeDwJxNhZjp6Oh49dVXn3766YZPfnp2PArM2Rp6tsOcDQJzNhXiZGZmRprCU0899ZGP fKRhEXp2PArSHA4fPnzkyJEdeneDoGc7QfVgIkZ6NnM2FeKhXC6L1+7du1dKLmL7o2fHoyBHau82 O/TuBkHPdoLqwUSM9GzmbCrEwNbWViaTURPY0dsfPTsehdOnT0tnYM526Nnb+NeDiRjp2czZVNhp pBHI0DCbzaqhIT1bge/Zm5ub0hmYsx169jb+9WAiRno2czYVdpSZmZmlpaXFxUU9LqRnK/A9mzlb Q892mLNBYM6mwg5RKpXEXKW6pqen3Y/TsxX4ns2craFnO8zZIDBnU2EnkNNbnHVsbKynp8fzFD1b ge/ZzNkaerbDnA0CczYVmk4+n5+amspms62trZXP0rMV+J7NnK2hZzvM2SAwZ1OhuYiTbWxsiGHX GgjSsxX4ns2crUmJZ8to++zZs4uLi1WfZc6GgDk7bQp33nln+F/QqkSWnZycrPqUmsBub2/3NzN6 tgLfs925amhoSI67u1FULivHZW5urt5vjzeClHj2mTNnXnjhBRlwV32WORsC5uy0KciJVywWG1tW FhwfH7906VJV2VoT2B7o2Qp8z3bnqkwmI83afTuhZ1mJaBMTE2traw2vDDL0bIc5GwTm7LQpRGFr a0uaV6Vn+09ge6BnK/A9252rZLjW1tYmL9bje/ey5XJZ/pvL5Wx1NXq2w5wNAnN22hSiUNWzAyew PdCzFfie7clV8t8LFy7oyU73srIrvvvd74pnN7wm4NCzHeZsEJiz06YQBY9nh5zA9kDPVuB7tidX SZiWqD09Pa2mP/SyKoJfvHjRpgTmgZ7tMGeDwJydNoUouD1bRnvindLIAiewPdCzFfieXZmr8vn8 +Pj42tpaS0uLXra3t3f//v0nTpxoeDXwoWc7zNkgMGenTSEK2rMXFhZmZ2dzuVwDhkHPVuB7dtVc 1dXVdfjw4ZGREbWslMTQ0JBy8YZXAx96tsOcDQJzdtoUoqA8W4J1sViUE7uxNk3PVuB7dtVcJaN8 OYIXL148cOCALCshu4FrLcZBz3aYs0Fgzk6bQhS+9a1v7d+/f3JyUmJWwyL0bAW+Z9fKVTLQL5VK hUJBrFqGcbW+gsMm6NkOczYIzNlpU2gYGd59/OMf//GPf/zyyy9H0aFnK/A9u1auEsNua2uTf1ta WtbW1tLwVWj0bIc5GwTm7LQpNIaawH7sscc+8YlPVP1OlfDQsxX4nu2Tq+bn54eGhk6cOFHrS/Es g57tMGeDwJydNoUGkCJRE9jyb9XvVKkLerYC37P9c1VXV9fi4qLdt55p6NkOczYIzNlpU6iLUqnU 29vb3d2tJrBrfQ9aXdCzFfieXZmryuVyPp9fWlqS0Zs829raKi+Q8ujp6Qn5jTqGQs92mLNBYM5O m0J4VldXh4aGpqendauiZzdlcQW+Z3ty1fLystRDZ2enmLQ0bjmOsqyM6sTCC4WCHNMoRwQcerbD nA0Cc3baFEIyPz9/7tw5OXvdDZ2e3ZTFFfierXOVGLOeH9Exy12KVV9gE/RshzkbBObstCkEUi6X pSrkD0nYntlKenZTFlfge7bKVRKs5ZANDw97dnhlKUoQn5iYaOybdsChZzvM2SAwZ6dNwR+JSplM pq+vb3BwsPJZenZTFlfge7bKVePj41X3dtVSLBQKYtui6f++ksvlZYcPHzbFAOjZDnM2CMzZZilI kxXjbHhxOeV8PlCrJrDn5uYkWlV9AT27KYsr8D1bctXVq1e/8Y1vnD9/vvLZWsUsHr9r1y6frx+f mZkRw5bDJ2WQ1J1rW1/pevdXf+/S+T++P9zr6dkOczYIzNlmKUTEp/WoCexcLuczjqZnN2VxBb5n b2xsfPSjH/3mN79ZtSRqFXO5XD5w4IAUUuWPqefzeQkJ8vj09HSYn1rfOejZVWHONgDmbLMUIlK1 9fhMYHugZzdlcQW+Z3/sYx+7cuXKP/3TP1V91qeYJZDJgu6vW5FsoG5SkxqrM6gVHr3l0OPqz0ee /9ljD23/dc1zH152bn742oObY5dap956Sr/c/epHnr/xgmsceTKMc9OzHeZsEJizzVKISGXr8Z/A 9kDPbsriCnzP/q3f+q0/+IM/qLWffYpZ/U7r2tqas11gExMTCwsLctDr/5r6bbd98C3vLTza9b0/ EYO96UHl6dv2rKz5uglfe9y5/rA3UzNnV4U52wCYs81SiIin9QROYHugZzdlcQW+Z7/zne/8i7/4 i09+8pNVn/Up5nK5vGfPnsuXL8/MzExNTTU+dV3VWisevO7O99/8hDw81Sr/c65ZuXNznKZnV4U5 2wCYs81SiIi79Ug/PXfu3OLiYviBMz27KYsr8D37jjvueP311xsWF1kpmPu3qWvBGzdV6Kzsfrri QXVNvJpnX3+dvjjuvoxOz66AOdsAmLPNUoiIaj2SqsX25Nybnp6ua3F6dlMWV+B79j333CMVIv2h 6rP+xSzPrqysSHuRRj85OVnXHWdSn2/dVxE1Z3sM/8aS9OyqMGcbAHO2WQoRkdZz/Pjx2dnZ4eHh /v7+ehenZzdlcQW+Z//mb/7m0NBQJpOp+qxPMYtP9/b2Xrx40dn+PML4+Pjg4ODY2Fj9l8dDzme/ +GQVIw7y7BsSwdCzHeZsEJizzVKISEdHx6uvvvr000/7HHEf6NlNWVyB79mSqHbt2nXu3Lmqz/oU s6f1l0olse18Pi+pvf6RYtX7xl0P3rjzu4ZnO9VeqxV437gL5mwDYM42SyEK6rssnnrqqY985CON KdCzm7K4At+zv/71r0s+/va3v131E4A+xSwhW5JAT0+P+8HV1VVJCCIlzt3YkDFB6NkOczYIzNlm KTRGuVxWE9gyRIvSeujZTVlcge/ZkqtefPHFX/3VX626pbWKeWFhYWlpKZfLVdVUl8qT/RK0BqBn O8zZIDBnm6XQAGK0mUxGTWBHbD307KYsrsD3bMlVd955p+znycnJyk8DVi3mYrEox3dlZcWnpehL 5fLWyX4bWnjo2Q5zNgjM2WYp1EuhUJBDLCehOsT0bAU9O4yCylXyrIz5Kr+LtLKY1ffzhDy4ZhkA PdthzgaBOdsshbqQc+y5555bXFzUx5eeraBnh1HQtqq+e6evr8/9yx+eYpbcLOl5bm7OSmOjZzum DbPCYKRnM2ebpRCSUqkkxibByP2dzw49+zr07DAK7lxVLpcnJibEvKVdyCPSuFUxS6UtLy8vLS3J C6TXGzRFXRf0bIc5GwTmbLMUwiDDYXG1sbExz427Dj37OvTsMAqVuapQKJw9e1ZMulgsqkfkBdLE u7u7G/i4v0HQsx3mbBCYs81SCCSfz09NTclZV/XuHnq2gp4dRsE/VyX+ZQNxQs92mLNBYM6OWUFa ZMOLy2Hy/2CruMjGxobPJUp6toKeHUbBP1fRs+2DOdsAmLPjVBCzEdtreHEZYEmHrXqw1AR2e3u7 v5HQsxX07DAKzNkaerbDnA0Cc3bMqxGFWo3DZwI7pEJI6NlNWVyB79nM2Rp6tsOcDQJzdsyrEYWq jcN/AjuMQnjo2U1ZXIHv2czZmpR4tn9hM2dDwJwd82pEobJxBE5gByrUBT27KYsr8D2bOVtDz3aY s0Fgzo55NaLgbhylUqm3t1esqy7noGcr6NlhFJizNdFLzgiYsw2AOTvm1YiCdjs5atJEpqen63U+ eraCnh1GgTlbQ892mLNBYM6OeTWioNyuWCzOzs7mcrkGmjU9W0HPDqPAnK2hZzvM2SAwZ8e8GlEQ t3vHO95x++23Z7PZqj9pHEaBnu3Qs8MpMGdr6NkOczYIzNkxr0bDlEol6bAf//jHv/SlLzUsQs9W 0LPDKDBna+jZDnM2CMzZMa9GY6gJbPmjgTlsN/RsBT07jAJztoae7TBng8CcHfNqNMDCwoKawJbG EdHt6NkKenYYBeZsDT3bYc4GgTk75tWoFxlUFYtFNYEd3e3o2Qp6dhgF5mwNPdthzgaBOTvm1QiP WHUmk+nu7h4ZGVGP0LMV9Ox4FJizNfRshzkbBObsmFcjJKurq0NDQ57Za3q2gp4djwJztoae7TBn g8CcHfNqhGF+fv7cuXO5XM5zetCzFfTseBSYszX0bIc5GwTm7JhXw59yuSyjKGf7/vDKT2DTsxX0 7HgUmLM19GyHORsE5uyYV8MHNYHd19c3ODhY9QX0bAU9Ox4F5mwNPdthzgaBObsuBTGbhheXnazv JqtETWDPzc11dnbWeg09W0HPjkeBOVtDz3aYs0Fgzg7PmTNnxLQaXvzs2bPZbLaqV9WawPZAz1bQ s+NRYM7W0LMd5mwQmLNjo6pX+U9gh1GIvg7hoWc3ZXEFvmczZ2vo2Q5zNgjM2bFR6VWBE9iBCtHX oS7o2U1ZXIHv2czZGnq2w5wNAnN2bHi8qlAoyIDJfwLbXyH6OtQLPbspiyvwPZs5W0PPdpizQWDO jg23V83MzCwtLQVOYPsoRF+HBqBnN2VxBb5nM2dr6NkOczYIzNmxobxKUrWc/2LV09PTjSnQs+nZ 8SgwZ2vo2Q5zNgjM2bEhXnX8+PHZ2dnh4eH+/v7GFOjZDj07LgXmbA0922HOBoE5OzY6OjpeffXV p59+2meE5A89W0HPjkeBOVtDz3aYs0Fgzo6HmZmZiYmJp5566iMf+UjDIvRsBT07HgXmbA0922HO BoE5e6cpl8tqAlt2dbKOG12Bnt2UxRX4ns2craFnO8zZIDBn7yhicplMRk1gJ+640RXo2U1ZXIHv 2czZGnq2w5wNAnP2zrG8vDw+Pp7NZtWQKHHHja5Az27K4gp8z2bO1tCzHeZsEJizdwip+wsXLuRy OT0eStxxoyvQs5uyuALfs5mzNfRshzkbBObsplMqleQMb29v95R+4o4bXYGe3ZTFFfiezZytoWc7 zNkgMGc3FylrOb3HxsZ6eno8TyXuuNEV6NlNWVyB79nM2Rp6tsOcDQJzdhPJ5/NTU1PZbLa1tbXy 2cQdN7oCPbspiyvwPZs5W0PPdpizQWDObhZS6BsbG2LYtQZAiTtudAV6dlMWV+B7NnO2hp7tMGeD wJwdnVoT2B4Sd9zoCvTspiyuwPds5mwNPdthzgYhPTl7z549DX9pqNDa2jo3N1f5uM8EtofEHTe6 Aj27KYsr8D2bOVtDz3aYs0FIT87e2qaxZYvF4vj4eKVX+U9ge0jccaMr0LObsrgC37OZszX0bIc5 G4T05OwoVPUqcXEpYp8JbA+JO250BXp2UxZX4Hs2c7aGnu0wZ4OQnpwdBY9XlUql3t7ew4cPnzhx IrxI4o4bXYGe3ZTFFfiezZytSYlnS4S77777RkZGqj7LnA0Bc3YY3F4loxw5gaenp+t1ncQdN7oC PbspiyvwPZs5W5MSz/bfTOZsCJizw6C9amFhYXZ2NpfLNdAoE3fc6Ar07KYsrsD3bOZsDT3bYc4G gTk7DMqrenp6isViNpttaWlpQCRxx42uQM9uyuIKfM9mztbQsx3mbBCYs8PwrW99a//+/ZOTk7Vm esKQuONGV6BnN2VxBb5nM2dr6NkOczYIzNmByLDm4x//+I9//OOXX345ik7ijhtdgZ7dlMUV+J7N nK2hZzvM2SAwZ/ujJrAfe+yxT3ziE4l7VeIK9OymLK7A92zmbA0922HOBoE52wfZOWoCW/5F8KrE FejZTVlcge/ZzNkaerbDnA0Cc3ZVxKR7e3v7+vrUBDaIVyWuALIf6NnxKDBna+jZDnM2CMzZlayu rg4NDc3NzXV2dqpHQLwqcQWQ/UDPjkeBOVtDz3aYs0FgzvYwPz9/7ty5XC7nHk6CeFXiCiD7gZ4d jwJztoae7TBng8CcrSmXy7I35I/p6WnPJ7BBvCpxBZD9QM+OR4E5W0PPdpizQWDOVhSLxUwm09fX Nzg4WPksiFclrgCyH+jZ8SgwZ2vo2Q5zNgim5GzpLFEUJDfryelKKiewPYB4VeIKIPuBnh2PAnO2 hp7tMGeDYETOloGFrGcUBXHlixcvVu1NVSewPYB4VeIKIPuBnh2PAnO2hp7tMGeDYETOjk7V3uQz ge0BxKsSVwDZD/TseBSYszX0bIc5GwQjcnZ0KnuT2I8UaK0JbA8gXpW4Ash+oGfHo8CcraFnO8zZ IKQzZxcKBdlwnwlsDyBelbgCyH6gZ8ejwJytoWc7zNkgpDBnz8zMLC0tLS4u+my1BxCvSlwBZD/Q s+NRYM7W0LMd5mwQUpWzpdqkKOXf6enpuhYH8arEFUD2Az07HgXmbA0922HOBiE9Ofupp5569NFH h4eH+/v7610cxKsSVwDZD/TseBSYszX0bIc5G4SU5Ox77733nnvu+bu/+zufLfUBxKsSVwDZD/Ts eBSYszX0bIc5G4Q05OyZmZnx8fELFy68973vbUwBxKsSVwDZD/TseBSYszX0bIc5GwS7c3a5XFYT 2Pl8Pkp3A/GqxBVA9gM9Ox4F5mwNPdthzgbB4pwtBpPJZNQEdsTuBuJViSuA7Ad6djwKzNkaerbD nA2CrTlbgvXExEQ2m1WbRs9uigLIfqBnx6PAnK2hZzvM2SBYmbOlmW5sbIhh6+2iZzdFAWQ/0LPj UWDO1tCzHeZsECzL2aVSScquvb3d00/p2U1RANkP9Ox4FJizNfRshzkbBJtytgwDpebGxsZ6eno8 T9Gzm6IAsh/o2fEoMGdr6NkOczYI1uTsfD4/NTWVzWZbW1srn6VnN0UBZD/Qs+NRYM7W0LMd5mwQ 7MjZlRPYHujZTVEA2Q/07HgUmLM19GyHORsE03N2rQlsD/TspiiA7Ad6djwKzNkaerbDnA2C0Tnb ZwLbAz27KQog+4GeHY8Cc7aGnu0wZ4MQQ86+8847Q/5MdS2kUHK5XEtLi/vBhYWF2dnZWhPYHujZ TVEA2Q/07HgUmLM19GyHORuEGHK2jM6KxWIUhUwms7Ky4u4sMtQQzbm5uZC/gU3PbooCyH6gZ8ej wJytoWc7zNkgxJCzo+PuLKVSqbe3t7u7e2RkpDGFBgDxqsQVQPYDPTseBeZsDT3bYc4GIYacHR3d WWRtpaqmp6fr7fj07KYogOwHenY8CszZGnq2w5wNgkE5e3V1dXZ2NpfLNdCk6NlNUQDZD/TseBSY szX0bIc5GwRTcvaHPvShn/zkJ9ls1nMnWngFenZ0BZD9QM+OR4E5W5MSz/Y/N5mzIcDP2aVS6d57 73300Uc/97nPNSxCz26KAsh+oGfHo8CcraFnO8zZIIDnbDWBXSwWPfeN1ws9uykKIPuBnh2PAnO2 hp7tMGeDgJyz1Sewc7mcVFKy3Q3EqxJXANkP9Ox4FJizNfRshzkbBMycXS6XZTBRKpXUBHbi3Q3E qxJXANkP9Ox4FJizNfRshzkbBMCcXSwWM5lMX1/f4OCgeiTx7gbiVYkrgOwHenY8CszZGnq2w5wN AlrOXl1dHRoampubc3/daeLdDcSrElcA2Q/07HgUmLM19GyHORsEqJw9Pz9/7ty5XC7nKYvEuxuI VyWuALIf6NnxKDBna+jZDnM2CCA5W01gyx/T09OVn8BOvLuBeFXiCiD7gZ4djwJztoae7TBng4CQ sysnsD0k3t1AvCpxBZD9QM+OR4E5W0PPdpizQUg8Z1edwPaQeHcD8arEFUD2Az07HgXmbA0922HO BiHZnF1rAttD4t0NxKsSVwDZD/TseBSYszX0bIc5G4Skcrb/BLaHxLsbiFclrgCyH+jZ8SgwZ2vo 2Q5zNgiJ5Gxp/ZlMRt631gS2h8S7G4hXJa4Ash/o2fEoMGdr6NkOczYIYXK2nNVR3kLGZa2trfq/ hUJBBgrZbNZnoOAh8e4G4lWJK4DsB3p2PArM2Zrx8fFdu3adOHEi6RXZWZizDSAwZ0t/lE4d5S1W V1dfe+019ffMzMzS0tLi4qLPKKGSxLsbiFclrgCyH+jZ8SgwZ2uacsTxYc42gMCcHR11bpfLZWm1 Mkabnp6uVyHx7gbiVYkrgOwHenY8CszZGnq2w5wNQmDOjo6c29LlM5nM8PBwf39/AwqJdzcQr0pc AWQ/0LPjUWDO1tCzHeZsEOLJ2XKk65rA9pB4dwPxqsQVQPYDPTseBeZsDT3bYc4GYadz9szMjLzF 5cuXowwLEu9uIF6VuALIfqBnx6PAnK2hZzvM2SDsXM7WE9hi2xH3TOLdDcSrElcA2Q/07HgUmLM1 9GyHORuEHcrZcnQzmczY2Fh/f3/0czvx7gbiVYkrgOwHenY8CszZGnq2w5wNwk7k7Hw+PzU1lc1m 1cey6dmKxB03ugLIfqBnx6PAnK2hZzvM2SA0PWdLWW9sbIhh63EAPVuRuONGVwDZD/TseBSYszX0 bIc5G4Qm5uxSqSTNtL293VPZ9GxF4o4bXQFkP9Cz41FgztbQsx3mbBCalbPlcEonHRsb6+np8TxF z1Yk7rjRFUD2Az07HgXmbA0922HOBqEpOdszge2Bnq1I3HGjK4DsB3p2PArM2Rp6tsOcDUL0nF05 ge2Bnq1I3HGjK4DsB3p2PArM2Rp6tsOcDUKUnF1rAtsDPVuRuONGVwDZD/TseBSYszX0bIc5G4SG c7bPBLYHerYicceNrgCyH+jZ8SgwZ2vo2Q5zNgiN5eyFhYWpqalcLld1AtsDPVuRuONGVwDZD/Ts eBSYszX0bIc5G4QGcrYsUiwWs9lsS0tLmNfTsxWJO250BZD9QM+OR4E5W0PPdpizQagrZ5dKpd7e 3u7u7pGRkfBvQc9WJO640RVA9gM9Ox4F5mwNPdthzgYhfM4Wd5deOT09XW+3pWcrEnfc6Aog+4Ge HY8Cc7aGnu0wZ4MQMmcvLCzMzs7mcrkGGgQ9W5G440ZXANkP9Ox4FJizNfRshzkbhMCcLWOr//7v //7Rj34UfgLbAz1bkbjjRlcA2Q/07HgUmLM19GyHORuEwJx91113/dmf/dnnPve5ht+Cnq1I3HGj K4DsB3p2PArM2Rp6tsOcDUJgzpbzuVAoROkL9GxF4o4bXQFkP9Cz41FgztakxLM7Ojqy2WwtO2DO hiAwZ0fvC/RsReKOG10BZD/Qs+NRYM7WpMSzo9SDiRhZwYE5m57twHhV4gog+4GeHY8Cc7aGnu0w Z4PAnB0GEK9KXAFkP9Cz41FgztbQsx3mbBCYs8MA4lWJK4DsB3p2PArM2Rp6tsOcDQJzdhhAvCpx BZD9QM+OR4E5W0PPdpizQWDODgOIVyWuALIf6NnxKDBna+jZDnM2CJ6cXSqVPJm78ihWvsYfEz1b dot7HFPVqzyv8SBjUs+PnlV6lbxGVqnWN9UAKjSwH2QRGZi79SvXQV6ze5taCp5nKz3bX6FYLMoK uJ+tbMHyGvk3ZIZIiWczZ2vo2Q5zNgienN3R0TE3N9fZ2alf4DmK0tra2tpefvnlWl2+q6srm826 j6vn3C6Xy9K1RbOWgnRk6enuuqmspEwmMz09Xat6IirIoET2w/nz57VdVXpVPp+fmppaWVmpugJC b2+v+Ir7x1Q8XiV7Ut5FFGqdIYkryJGS/Sb7QZdH5X4oFAqyt32StxSY/Cu7utY6yLuoqquVvKVR /uAHP5Ci0o9UerYoTE5O1koAMzMzL7zwwuLiolvTubkFy1rJiVA1uy8sLEhJDA4O+ix+5swZ+dcn +ide1Q0ouHOV7IT+/n63WqVnV77GGqz0bClaOV7uPlxZD3JMe3p61GuYsyHw5GyxoomJibW1Nf0C z1GU015e7G7BHqSsNzY23P3Rc27Lgb9w4YL7BR4qX+BZBym12dlZ90o2XWF+fv65557TCh6vEpuR gYvYjE/5yo6V4Yu8hW6gHq+qNDNABdkPZ8+e1UOTSs8WsxRBOatrKahhgdv4PetQaageKocOHs/2 rGRVBc/x8rTgyrJ3I1stm3Dx4kW9Gz2LV25jJQhVXa+CO1dJIR0+fNg9/vOc16urqzJGlNpo7BuO wbHSs+V4tbe3uzfKUw+eY8qcDUHlfLYcJDk5dapwH0XlAf6npeqwuVxON2X3ua1iujQFnwt6lR3W vQ6VHXwnFJyb3cjjVYHDDoXsW3kvWQ31X7dXVboprILsh7GxMZWfPPtB7HZpaUl2rP9+kJfJAEh2 eOU6qHoQu/Vcw/fg8RK3Z0sCFoXAo6lcWd5Ila67BVdWbCXj4+Oy7fIa9V9PBw8c+jgYVV2vgjtX VVaLx7PddWI6suFiTv5XVuQ1siui3FSROOrscw9GPZ7tOabM2RBU3jcugyk5OaW7qQPpPopyCIeH hwPL1JNa3Od2JpMRqcnJyTAKusO618FjQjunIGNMWVspaFFwe1WYYYfCYydur5K/w/wMOYKCe6zt 2Q+B4VIhe/vAgQN6AOReh5D1IIjC8ePHVe25PTvk0XRuToruFlx5ZajqJkgJyWvUtJF7cWVmUieB N3kgVHVdCp5c5RmauM9rGVQ98cQTPpc6zELqXOrNPUDxeHblpRdDkS367ne/qwej7nqYn58/d+6c e0TOnA1B1fvG3SenPooLCwtTU1M+V97cuP1An9uFQkF6dMirZ+4Oq9dBikaUA6NhsxRkbdvb20+c OOH2qvA249zcy7RX+V+JBVTQm+zeD0NDQ3Ic/cOlZnl5WV6vBkB6Heq6muq+xqM9O+SlAoUcemnE qs/qFlwZNWrhrn93B5fN6evrc2cyHxCqOryCJ1d5Rmn6vA554cosxsfHZbyrRzAez5a63b9/v3SG hNauaXgGo7oeql6+Ys6GoOrns90HTB1FOZPdhzaMrA4f+twOnPusVFBNRFdS5U1VO6qgG7q6b04M o4FJO319SXmV7MDAK7FoCvrSgrNtUbL54cOlRrc57dn1Xk3VowTt2ZWTrP7IYFRqO5vN6hZcOaXn g1i+DHDFnvXidQ19HIyqDq9Qmavc0xz6vA5/qcMgPAMRt2e7B6CJrmNzcA9GdT1Une5hzoag1uez 9YURdRQlqLnn88KgO6w6t0POfXrWzdmuG7UO0mvcl/XiUVBT16KgvKqBSTsdEOVf8apCoRB4JRZQ oXI/HD9+PGS4VOjLiZLaZR1klaTA6rqaqnKeHEdpMWIw0j7qPZo6VUjblf/KuCH8hR/HtRtlb8h/ ZfxR10BWgVDVIRUqc5V7mkOd156pNJuodWWlruxhBHrSU9WDjGtlDFd5TJmzIfD5HjRVmnJ6Sy6R Q1jv5I2+kib/vvzyyyHnPt3ouC/vLv9Ke/X5PM8OKajbdmQ/SFMTt/a/P7kWMnyRPSwZXXxOjdDr bXCJK6j9IHtAupjsDf/7k2uh7uSSwpB1kLpq4GqquslcNkQiu6yJ/637VVGNuLu7W/6WQWS9zVeN RHft2iV/yx8y9KlrIOtgVHVIhaq5SqfMO++8UzpeXRHfOPRdFNqzG8ge+OjBqFSFbJocXzlBKkfk zNkQ+HwPmroO7Gx/0URfX18DkzfqSpqc5OqUDjn36VGQM0QavTRW+beuaNgshXw+L0Ws/m5s0k4N X6TcpVdKC2jgEyMICtH3g4q5znZFScZtoB6c7aGkbIsoyFizgaPpbDdiUZCVaW1trbf5qmkCsTfZ k2L/jd2FhFDVYRRq5So1zSEjMFmqrqkB4/BcWREbayB7GMHAwIBUspS0BG5JJlWPKXM2BP7fNy4D cDmK8oLGJm/UlTR5C6mGkDfIVCIniSjIGjZ8l2Z0BTlvZeQhZ2zDk3bSImV4JO/e8AdYERTUfpDY 4f6Gk7qQcpKiilIPhULh0KFDsv5yNBv7CjApBikJ+UPWoYHmq3ajrIBk04bzJUJVByrUylVqmkMG fzLo8fkyHDtQ8wjqysqVK1echrIHPmowqv6WQUnV6R7mbAj8v29cDqS6WanhyRtp8dLo5cSua+7T jerRJ0+ebPgLDaIr1HV/ci2iT4MlrtCU/aDv5GpYoa5b96sS5hPVtVBf3OZsW37DdyEhVHWggk+u kpAtz0ohNXapwyCkB0rFqg65uroasfiRkQMqh9VnRM6cDcGv/MqvfP/734+icNddd7366qumK6iL xlEU9uzZc/nyZdMVEI4FggLrQXHnnXe+9tprURQQjmZ0hYggHMqmiDzwwAMvvfRSxNXAwUjPvuWW WyTxRBk5ntomyjqAKGxubkZRaG1ttUMB4VggKCAci2QVvvzlL//VX/1VrT0pLiheGCgCcjSjK7S1 tTV8USHxQ9kUEVUPJtpcLUz17BMnTkT5oCHIGcUe3SwFhGOBoIBwLJJV+P73v//bv/3bCMcCQeFv //Zvf+M3fqOxxRM/lE0RUfVgos3VwlTPZs522KNdCgjHAkEB4Vgg5+yQgBzNZOsh8UPZFBHmbAiY s7VC4icViALCsUBQQDgWzNk4CvRs5mwImLO1QuInFYgCwrFAUEA4FszZOAr0bOZsCJiztULiJxWI AsKxQFBAOBbM2TgK9GzmbAiYs7VC4icViALCsUBQQDgWzNk4CvRs5mwImLO1QuInFYgCwrFAUEA4 FszZOAr0bOZsCJiztULiJxWIAsKxQFBAOBbM2TgK9GzmbAiYs7VC4icViALCsUBQQDgWzNk4CvRs 5mwIxLMRzgcEhcRPKhAFhGOBoIBwLBAUEI4FggI9WymYaHO1oGebrZD4SQWigHAsEBQQjgWCAsKx QFCgZzv0bATo2Voh8ZMKRAHhWCAoIBwLBAWEY4GgQM926NkI0LO1QuInFYgCwrFAUEA4FggKCMcC QYGe7dCzEaBna4XETyoQBYRjgaCAcCwQFBCOBYICPduhZyNAz9YKiZ9UIAoIxwJBAeFYICggHAsE BXq2Q89GgJ6tFRI/qUAUEI4FggLCsUBQQDgWCAr0bIeejQA9WyskflKBKCAcCwQFhGOBoIBwLBAU 6NkOPRsBerZWSPykAlFAOBYICgjHAkEB4VggKNCzHXo2Art27XrllVeiKNx2221vvPGG6Qq33377 1atXqYBwLBAUEI4FggLCsUBQuPXWW998882GF0c4lE0REb8olUoRVwMHIz2bEEIISSH0bEIIIcQM /j84/GMECmVuZHN0cmVhbQplbmRvYmoKNDcgMCBvYmoKPDwKL1R5cGUvRm9udAovU3VidHlwZS9U eXBlMQovTmFtZS9GMTEKL0ZvbnREZXNjcmlwdG9yIDQ2IDAgUgovQmFzZUZvbnQvSEtSRkpGK0NN U1kxMAovRmlyc3RDaGFyIDMzCi9MYXN0Q2hhciAxOTYKL1dpZHRoc1sxMDAwIDUwMCA1MDAgMTAw MCAxMDAwIDEwMDAgNzc4IDEwMDAgMTAwMCA2MTEgNjExIDEwMDAgMTAwMCAxMDAwIDc3OCAyNzUK MTAwMCA2NjcgNjY3IDg4OSA4ODkgMCAwIDU1NiA1NTYgNjY3IDUwMCA3MjIgNzIyIDc3OCA3Nzgg NjExIDc5OCA2NTcgNTI3IDc3MSA1MjgKNzE5IDU5NSA4NDUgNTQ1IDY3OCA3NjIgNjkwIDEyMDEg ODIwIDc5NiA2OTYgODE3IDg0OCA2MDYgNTQ1IDYyNiA2MTMgOTg4IDcxMyA2NjgKNzI1IDY2NyA2 NjcgNjY3IDY2NyA2NjcgNjExIDYxMSA0NDQgNDQ0IDQ0NCA0NDQgNTAwIDUwMCAzODkgMzg5IDI3 OCA1MDAgNTAwIDYxMSA1MDAKMjc4IDgzMyA3NTAgODMzIDQxNyA2NjcgNjY3IDc3OCA3NzggNDQ0 IDQ0NCA0NDQgNjExIDc3OCA3NzggNzc4IDc3OCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA3NzggMjc4IDc3OCA1MDAgNzc4 IDUwMCA3NzggNzc4Cjc3OCA3NzggMCAwIDc3OCA3NzggNzc4IDEwMDAgNTAwIDUwMCA3NzggNzc4 IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4Cjc3OCAxMDAwIDEwMDAgNzc4IDc3 OCAxMDAwIDc3OF0KPj4KZW5kb2JqCjQ4IDAgb2JqCjw8Ci9GaWx0ZXJbL0ZsYXRlRGVjb2RlXQov TGVuZ3RoIDExMjIKPj4Kc3RyZWFtCnjazVZZb9tGEH7vr9hHCgjXex8I8lBfRYoWQWsFKRD3gZYo mYlEuiIV2/++sztLiTKV2D1Q9GmXO7NzfDPzLQmjjJElicsP5HR6cimJo94YMl0QI6g1muTCUuc1 mZ5/zMQkl9yK7Op2Ily2LeolHCiRfZg4nW0nOWfCZudlvVxumyCR2WWQlEEvyj7g56p6cvP36Y8n l2rv2wvKHMmloFxGz5fVkoINbzNOUXsQqWSwIywqXnVFV6Lt93eTXPhsvjt4hwflpuiqpsazZoGB /vT+t2CXXEzJHwCIF5KbYJPtPzg3IRwwoakQZLYmJ2/XnJw35JeInSAe4pAhImupZR4SkJZKZWJk 01sIQwhAb3tz+tiV7av0eVstul+bCcBz34YjnhX1PGxk9nP1cNastuu6Rd0mZOD6DNJhsUmGv7+4 ylfV52CppGhpZ9xk9zG/nCvqlYKVU68xsmjVDnDRLts0AcgWP2aPs1U1Wz3iV9ekNSQUdavlbXDa hU+L0YfzRbNa7fIKkjZEg7IvIaRy1jUbFF1nDOvq9igKJ6jmfWVfo3yAsqJKuCTlo9uQp+Mvuiv/ wV11PaGYwRUmdhMrFNN+QMQl0zBJIkGOk7Rty1Bip7KqxrXvCvwaFxoOsS1gsy66TfWA+96S3lk6 aJqv2opNA5tQxRAmO4ivLdZBrkCxxTVahxWajKbdfH4G9rqiTsUXMEeHzpKJ+TwZKXCZ9ddMf+1I 8ZWnWqoE88OoCJoa30vFNwtYzEeXOaNKiyRn497BDYpnR+oveW/cKEwJhmKUgaTG9U7OUOyJod6q yBGUCw6gUwV5xDiONZrxZK+RgH+7wPU+TnpqMsGoYPZpk42CAg5zO7K8FpqPnBpqVJ/ddTYyIKmz Oonb18DJxmTrMcDwaKhe7XoCo8E4Eges87JuIiczYLS6xMNNs428wcSoh4I48jTIgKdf4cn9bbkZ 5wcYAOo+eT4SGKdW9+lVLZoqcJEiv6k69LMu27ZYJnCFUdBth+DeALUF1pyFInwOl5D5Rp2oKVd9 PO0oHkuVtEn6ZlwtNiDAUxRD6+3kjjLd3/70aXRdwwTpwwY8HALn7QEUNpE6c1mbHlI4+zLRMLqr bXhUJDOhBrnQBvVmRY1aSHzp9v2m6roySaoaD++Aqpp81kTFeTJetIixs1R7fgDx4P0InqUIvxPQ HptxopJK3WfaHWlpz3ctkQoL9mQqoktFhBc5/QI8ec45hxefGZID7wOkHGv5hj2rrgVVSuAfzMTJ LL52kEcFd2GjcCQgkC7nuJmPeeSQmf/lmeVsz0hpaAeUVI08AdDcDigJZhv5h1Nj3UGkF3GeIacF VuxbSGkG9GVeghTX/x1QT297ynYDw/rMuacm/BYOfqj+UuYKhtjJF2Ru/8+Jo+tm291tu7F1Qc1u PNvRSwjkarHr0Ar3Y65yVDFJ9jrP5fC3nHAoiRs4eYaQj7/pQyfy2JNuh2kkLD2wn7PPjc93fwLC HUY4CmVuZHN0cmVhbQplbmRvYmoKNDkgMCBvYmoKPDwKL0YzIDE1IDAgUgovRjQgMTggMCBSCi9G MiAxMiAwIFIKL0Y4IDI3IDAgUgovRjkgMzAgMCBSCi9GMTEgNDcgMCBSCi9GMTAgMzMgMCBSCj4+ CmVuZG9iago1MCAwIG9iago8PAovSW0xIDQwIDAgUgo+PgplbmRvYmoKMzkgMCBvYmoKPDwKL1By b2NTZXRbL1BERiAvVGV4dCAvSW1hZ2VDXQovRm9udCA0OSAwIFIKL1hPYmplY3QgNTAgMCBSCj4+ CmVuZG9iago1NSAwIG9iago8PAovVHlwZS9Gb250Ci9TdWJ0eXBlL1R5cGUxCi9OYW1lL0YxMgov Rm9udERlc2NyaXB0b3IgNTQgMCBSCi9CYXNlRm9udC9CUkdRRk0rQ01TWTcKL0ZpcnN0Q2hhciAz MwovTGFzdENoYXIgMTk2Ci9XaWR0aHNbMTEzOSA1ODUgNTg1IDExMzkgMTEzOSAxMTM5IDg5MyAx MTM5IDExMzkgNzA4IDcwOCAxMTM5IDExMzkgMTEzOSA4OTMgMzI5CjExMzkgNzcwIDc3MCAxMDE2 IDEwMTYgMCAwIDY0NyA2NDcgNzcwIDU4NSA4MzEgODMxIDg5MyA4OTMgNzA4IDkxOCA3NTMgNjIw IDg4OSA2MTYKODE4IDY4OSA5NzkgNjQ3IDc4MiA4NzIgNzkyIDEzNDMgOTM2IDkwNiA4MDkgOTM2 IDk4MSA3MDIgNjQ4IDcxOCA3MjAgMTEzNSA4MTkgNzY0CjgyMyA3NzAgNzcwIDc3MCA3NzAgNzcw IDcwOCA3MDggNTI0IDUyNCA1MjQgNTI0IDU4NSA1ODUgNDYyIDQ2MiAzMzkgNTg1IDU4NSA3MDgg NTg1CjMzOSA5MzggODU5IDk1NCA0OTQgNzcwIDc3MCA4OTMgODkzIDUyNCA1MjQgNTI0IDcwOCA4 OTMgODkzIDg5MyA4OTMgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgODkzIDMzOSA4OTMgNTg1IDg5MyA1ODUgODkzIDg5Mwo4 OTMgODkzIDAgMCA4OTMgODkzIDg5MyAxMTM5IDU4NSA1ODUgODkzIDg5MyA4OTMgODkzIDg5MyA4 OTMgODkzIDg5MyA4OTMgODkzIDg5Mwo4OTMgMTEzOSAxMTM5IDg5MyA4OTMgMTEzOSA4OTNdCj4+ CmVuZG9iago1OCAwIG9iago8PAovVHlwZS9Gb250Ci9TdWJ0eXBlL1R5cGUxCi9OYW1lL0YxMwov Rm9udERlc2NyaXB0b3IgNTcgMCBSCi9CYXNlRm9udC9JRVpEUU0rQ01NSTUKL0ZpcnN0Q2hhciAz MwovTGFzdENoYXIgMTk2Ci9XaWR0aHNbODg2IDY3NSA4NTUgMTE0NSA3MjYgNTc4IDkxOCAxMzYx IDEzNjEgMTM2MSAxMzYxIDQ1OCA0NTggNzM2IDczNiA3MzYgNzM2CjczNiA3MzYgNzM2IDczNiA3 MzYgNzM2IDczNiA3MzYgNDU4IDQ1OCAxMDgzIDczNiAxMDgzIDczNiA3NDkgMTAzNiAxMDM3IDk5 NiAxMTEwCjEwMDcgODY3IDEwNjQgMTExMCA2MjcgNzczIDExMzkgOTU2IDEyODQgMTA3NiAxMDQ4 IDg3NSAxMDgyIDEwMzAgODU2IDgzMiA5NDQgODI4CjEyNzkgMTExMyA4MjQgOTQzIDU5NyA1OTcg NTk3IDEzNjEgMTM2MSA1OTcgNzc0IDYzMyA2NDkgNzQwIDY3NyA2ODQgNzAxIDgyOCA1MzQgNTg4 Cjc1OCA0ODAgMTIyOCA4ODEgNzAzIDc0MCA2NTkgNjcxIDY3MCA1NjQgODQ2IDcyMiAxMDA5IDc5 MiA3MzEgNjg5IDUzNCA1NTMgODg5IDczNgo0NTggMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgODMzIDExNTMgMTA0OAo5Njcg MTAxOCAxMTEwIDEwNjUgODQwIDk0NCA4OTMgMCAwIDEwNjEgOTEzIDc5MSA3NDcgNjU0IDYxNCA2 NjcgNzQ0IDY3NyA1NTAgODI4IDg0MAo4NTAgNzEyIDY2NyA4MzEgNzI2IDgxNSA2ODIgNzkyIDg0 MiA4NjUgOTMxIDQ1OF0KPj4KZW5kb2JqCjYxIDAgb2JqCjw8Ci9UeXBlL0ZvbnQKL1N1YnR5cGUv VHlwZTEKL05hbWUvRjE0Ci9Gb250RGVzY3JpcHRvciA2MCAwIFIKL0Jhc2VGb250L1BRR1ZaWitk c3JvbTEwCi9GaXJzdENoYXIgNDkKL0xhc3RDaGFyIDEwNwovV2lkdGhzWzYxMSAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCA4MzMgNzY0IDcyMiA3OTIgNzM2IDcwOCA3ODUgODMzIDQ0NCA1 OTcKODMzIDY4MSAxMDAwIDgzMyA3NzggNzM2IDc3OCA3OTIgNTU2IDc1MCA4MDYgODA2IDEwODMg ODYxIDgwNiA3NTAgMCAwIDAgMCAwIDAgODMzCjAgMCAwIDAgMCAwIDY1NiAwIDAgNjI4XQo+Pgpl bmRvYmoKNjQgMCBvYmoKPDwKL1R5cGUvRm9udAovU3VidHlwZS9UeXBlMQovTmFtZS9GMTUKL0Zv bnREZXNjcmlwdG9yIDYzIDAgUgovQmFzZUZvbnQvWlpIRU5BK0NNUjUKL0ZpcnN0Q2hhciAzMwov TGFzdENoYXIgMTk2Ci9XaWR0aHNbNDAzIDY4MSAxMDk3IDY4MSAxMDk3IDEwMjggNDAzIDU0MiA1 NDIgNjgxIDEwMjggNDAzIDQ3MiA0MDMgNjgxIDY4MSA2ODEgNjgxCjY4MSA2ODEgNjgxIDY4MSA2 ODEgNjgxIDY4MSA0MDMgNDAzIDEwMjggMTAyOCAxMDI4IDY0NiAxMDI4IDk4MSA5MzUgOTU4IDEw MDQgOTAwCjg2NSAxMDMzIDk4MSA0OTQgNjkyIDEwMTUgODMxIDExODkgOTgxIDEwMjggOTAwIDEw MjggOTY5IDc1MCA5NTggOTgxIDk4MSAxMzI4IDk4MQo5ODEgODE5IDQwMyA2ODEgNDAzIDY4MSA0 MDMgNDAzIDY4MSA3NTAgNjExIDc1MCA2MTEgNDM4IDY4MSA3NTAgNDAzIDQzOCA3MTUgNDAzIDEw OTcKNzUwIDY4MSA3NTAgNzE1IDU0MiA1NDkgNTQyIDc1MCA3MTUgOTU4IDcxNSA3MTUgNjExIDY4 MSAxMzYxIDY4MSA2ODEgNjgxIDAgMCAwIDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDgzMSAxMDk3IDEwMjggOTExIDg4OSA5ODEKOTU4 IDEwMjggOTU4IDEwMjggMCAwIDk1OCA2ODEgNjgxIDQwMyA0MDMgNjQ2IDQwMyA0MzggNjgxIDY4 MSA2ODEgNjgxIDY4MSA5ODEgNjExCjY4MSA5NTggMTAyOCA2ODEgMTE3OCAxMzE3IDEwMjggNDAz IDY4MV0KPj4KZW5kb2JqCjY3IDAgb2JqCjw8Ci9UeXBlL0ZvbnQKL1N1YnR5cGUvVHlwZTEKL05h bWUvRjE2Ci9Gb250RGVzY3JpcHRvciA2NiAwIFIKL0Jhc2VGb250L1BYU0RaTitDTVRJMTAKL0Zp cnN0Q2hhciAzMwovTGFzdENoYXIgMTk2Ci9XaWR0aHNbMzA3IDUxNCA4MTggNzY5IDgxOCA3Njcg MzA3IDQwOSA0MDkgNTExIDc2NyAzMDcgMzU4IDMwNyA1MTEgNTExIDUxMSA1MTEgNTExCjUxMSA1 MTEgNTExIDUxMSA1MTEgNTExIDMwNyAzMDcgMzA3IDc2NyA1MTEgNTExIDc2NyA3NDMgNzA0IDcx NiA3NTUgNjc4IDY1MyA3NzQgNzQzCjM4NiA1MjUgNzY5IDYyNyA4OTcgNzQzIDc2NyA2NzggNzY3 IDcyOSA1NjIgNzE2IDc0MyA3NDMgOTk5IDc0MyA3NDMgNjEzIDMwNyA1MTQgMzA3CjUxMSAzMDcg MzA3IDUxMSA0NjAgNDYwIDUxMSA0NjAgMzA3IDQ2MCA1MTEgMzA3IDMwNyA0NjAgMjU2IDgxOCA1 NjIgNTExIDUxMSA0NjAgNDIyCjQwOSAzMzIgNTM3IDQ2MCA2NjQgNDY0IDQ4NiA0MDkgNTExIDEw MjIgNTExIDUxMSA1MTEgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNjI3IDgxOCA3NjcgNjkyIDY2NCA3NDMgNzE2IDc2NyA3 MTYgNzY3IDAgMAo3MTYgNjEzIDU2MiA1ODggODgyIDg5NCAzMDcgMzMyIDUxMSA1MTEgNTExIDUx MSA1MTEgODMxIDQ2MCA1MzcgNzE2IDcxNiA1MTEgODgzIDk4NQo3NjcgMjU2IDUxMV0KPj4KZW5k b2JqCjY4IDAgb2JqCjw8Ci9GaWx0ZXJbL0ZsYXRlRGVjb2RlXQovTGVuZ3RoIDI5NDAKPj4Kc3Ry ZWFtCnjazVtbk9u2FX7vr1DfqLGF4H6Jxw/rxm7SJI3H2aaZqftAr7grTXTZkFrb++97APACEiCl 3ZU9fSJFgsDBuX7nHGiGEcazm5m7/H326vKbN2ymkZFydnk9I9ogKvVsQRXSRswuv/tP9rfy/vaQ 7/LNfbWu5gvGaba/tleWHVaFf/B9Xq38ozdzLbK73dVhvd/5dz/96/cFFRJ+CCIyNv/v5T++eUNm hCAjhF10QahEAjNYVSADV7sqmy8IoTz75363KPPdcr+FCZTI3pb7W7ijWVEe1kXlHzp64Nos5ZaQ MwPbYnYF7DbEuPFTI2In5yZ7WxXLPXyqefauWUOz7Lt1dVjvbu7W1aoo/SO3AgwLVpi9vnTso906 kiIlBWwIcySIW+yn4uDJ0d0wopCgAqiyA773r4NZgDNamPr1t9HXAgnG67e/1twk3WuN2qnfU86i zw1ipPn85/hzwoDyZvG/xqTDDln99l1MOUaSNR9/mAPTM6sgmNSaAjcrrylwd91pCfwCxtobnIEc /JNNinPcIExlvcKbFAFCqEnWiS+5d53ae+4vtRZbzVlQQxAoLGhKbQXwTcOP5zDcqOwT6F4R0aBA N5TqbyEkAvRON+x5mdghgffNHq6jzzkymtRvcbS2fUvrty8S33LabJ/EK4dT39Sv6Uwio3j3miFJ RKO6PFpCI8HpbNGNcv4IeOW1y+isAp1xT5y9woNtUVX5TVE9j6WJKaJqYEgDefJGWaKFQJL5etdf a71bH9b5ppYwZwgk4QUs3STVIT/Yz1ntTuDqtR5urNZHsjawUT2lcEbSkEDWeGS4AW27cc6L8XY1 q5U62x9WsVNgCBs57pEo4qRZKkUqAa+i6KhZKqQas0IjrlPBGGyAX5wgLH0MuJyD583/mAPRdldS BbFE6iyv/MN8538Xn/Pt7aZIiJpJxDGZEjWmZNJqsFZfzGrUtNXQvtWYcaNRUsd7kwhbR9ONGpGf aqNCWtX0Ef7ISf7QSf6QM3qVAX9owJ8WGgxVm4T8QV6rLp0lObW6dXZTlIvOeXMqe857vS12c3D5 1v0o1gKSZYck4GKf8UCHYcB16YENd1ECHnRYh3cRcsgz+BwQhB4Pg+DmW4X+YOm693Tly4/2V1FW eXkfh0cTBJeL1KwUs87hOGYwZhChpufo8toZXe83m71d71P17YjZEyJgUstLrcDfeoD22nHcktmx dQjpBEekoeX1729r1cCd8Cl3Rs2RAtO1o26tN8RePy0iBIdTS/x7gIM8e3ER0qgTNFKAdbDfmqvR imAlGsxEwD50aEihwoKeaVCZRTfoPcNsDojOhjxit60SJkQx7FZ8JR8zyQLwFJSJUO96LOAuUNjd qVNYoBIsiHyTQESI1jctVOfBhvIGeNbZ8c8xytCQA4g+vgunUMhwGjrBSU4wgojXhR8TjBAQ8uQX YEQPsDT09Z1xQyAgEMI9L36JfCPslYHbA09Wp3k4pTfSzLoR77N4D7AFFaQbNNZcyIga5Xs/jyeQ sPmG5277U6h7ElmMkcePkacH5On09y9SptNFpxNYTFIsVidw+MFbGHKYnMrhGPtBwmXIgMU6rQA/ gh8VKT5BYoW5fpiaTNqeAFPAPsFexssB48XJOnWR8gNcedwgQ9FCvPF4wzHVBS2EhQrDQSB9+Fyw WTeilS0Nx5A2iHVsCSahiI2wJRVDqVSwnKe5LA53ZYwcGAZla6Da8kgZg2qBMOZubDodpXCHzTgO gRSLhCkK56xGOJt7+4tnVza8r/YVxHn31gMi+ybfbPxNA4Mq/3Ob3946MNUOj6jiNlyy8SwZtKfN Vg77RL4AmeF44qUCg0Jx1oaINq1BREszJIyYxFDeFXRcYkz0uGR/J7dNMOQxWo+mOeAI2tz/uZ/n 02oNU8ts5RNFn0XK7K4qlv4ur5/k/lIVV6VLseHbP+yHxb3/8npfJos1UpKTPAvyc15+spPu67S1 zK82RWzeQiHWpmOTbpePRzbvdvnT3O7ANBeME+d6QkF2YIX08i0izelbIBPBmZ8tOC8YoVle2ryH sGxZvKdC7ZwmwM/D3l99ESF2BZoiLeXXCtSe1EQmSyVwljwomh2nQ6dZ9gLinZRpK5e4jUBz5Mm9 8AxsMzzLzPUhVeIzpiuixoxkprHiZXEoyu165+rgsEJnzj5RVRgG9xPV2qggs5Xe3CHVvS1dlvZx vXTChjdO2La0MpkvEqaBXWY0YfRxtDNwmPjCVXdlU0mLlnCDtrbmA48q/3PV0HlzV1T1bYpxRIPb b+u3y0T5UPNBUly7X4GYrQEEbPrzrijvfcoeVtVu1p7YXV3Gc8w8VtKCnAOM1aOAf9uSlpuM+slk 8yuv53T8kGMsN+DEzQC6mCFymfR9zhC7ATasH03OmTRIUA8sLiZVgtuseoCs6JA+G37H8hKJBIsM dACZ+DHIJAd+GXAItgJWSDPa8WUKYjJtS+k+v9sm8ztgypfL9eVXq5cNq/Ah8G2q8JO6ASopOJ/K Dxp5rSJhQZbME+qqx+Nc7XPjqQiwzXYuo6CpR+P+9FwqnIs+ba4eXeycm+TnnEyckWPyjBxTx+HP KaUFZ3C/pAzOtJ27Iyq8TUQVxfXJKRrHGmj2buWH65hmE/R0XiUQvObqNEJXsc8aGts6MQEj4yIa 1DoHMlonPLFuo/EzkuzVatGXoZPQS3vRYL51EbnuYtl8MKpYg5PumnQpFWiYScfcLeGobVmfoef5 KE9Nn/Ate8K3/AnfiidUoeVJna6ekbEWT9eVDacc5Ki9gXFz4fWr2FRNczSYAh8pgnAAuRzT6SKI VeQxBwHgQ7c6emVhHiekTaPcj3xX92g4wU3L2v4ARL8+rOoxJWDe0mFk+3NT7G4OK+RHvXP7seDd vvo4FwKs5S5BqQQXYfoeopcc6dYPumoNTFbdbjzUhkhPILcSut/38u2Zvcew2rOU0YXF585qP9n3 +zJO1DRMwtkp3kqE1k373koG1VPkV79swPqrve93b4oGW/cbar2EHDNkiBr1vHV86zfbwwzZIvfj XS6uGMLMd7cdeaojj9uzUywbJVHBXVuVSscGeVqd9rcEDtOEPAqI/ZYK35Q/sHhxPG5q6yD0KZEv T+yOSvmo3cVlXQj3+HGQ9So1FzNH50oE5GU0lT0qwo4WvR4OmaYq52k1og+j4nlCmiEVJ0iTnFGa 5IzSJOeTJvm/kObxaAu5oHXqIbrtNx8o75ejYjwmUFsfV6nWDjFiqj4XAphJ3RFjObItk/OwKUcF SYTKDqfzSSR0lVpB0JM38SFxrIWqUzbBkpvQ/U2MHwYMBMGfKIirxB4YIY8WhE4LYpmQN9FyugWr EGUhinjpEwWear/z9hRUkSJXC3YqR6a7M4+KcOqB3fyjMVdQ2BIjCdDtLik4zY/CaUjXEGOTcBrw dovETuPTk5oe1PjGl726Qq+9qRb+CO/e1mI/22es7oq54Tt/vXj9q79xh5Z7E1zlm6u7TV73LcOP 2iHFn3fhe9d4cTeb+gwpJ4CBae9oVQsMea/bwPXgMFivJmxb0KAbSpEw2ySia2cD+FV0ZhsP3nnr VNtBQHQDD04b4a19V9ISrWoO6mZ3JqvybeEf5ZV/4hmgLdeQv7tsBm89VF8Cx0r/6rbG7ve7/dYe qnUPXS3A3mytWO42hzVkJ1d5g5dtigLSH5zMqxKNUoTbg7WfE8YkIeB1VVA9ooOLbsizSb90fAme XIKfcwn22F2w/hI9nTC4YeMzEAylGUHRSb2Fhe7cHicgSCpf+qr/xUGyfbWu/wOgef1xe6hJ9jtN woD+CYORqTXQJ3rC9q+uF/nyY747uLyZCe0PYMI1+POJ9nkbjM8P/vemmAsM6nmI0z3NgpMX5Gj4 SwME1i/vHDnvThK9ENqWTJqjqyFXwFHywdFVz7+//A/2FQtUCmVuZHN0cmVhbQplbmRvYmoKNjkg MCBvYmoKPDwKL0YzIDE1IDAgUgovRjEgOSAwIFIKL0Y2IDI0IDAgUgovRjIgMTIgMCBSCi9GOCAy NyAwIFIKL0YxMSA0NyAwIFIKL0YxMiA1NSAwIFIKL0Y5IDMwIDAgUgovRjEwIDMzIDAgUgovRjEz IDU4IDAgUgovRjE0IDYxIDAgUgovRjE1IDY0IDAgUgovRjE2IDY3IDAgUgo+PgplbmRvYmoKNTIg MCBvYmoKPDwKL1Byb2NTZXRbL1BERiAvVGV4dCAvSW1hZ2VDXQovRm9udCA2OSAwIFIKPj4KZW5k b2JqCjc0IDAgb2JqCjw8Ci9UeXBlL0ZvbnQKL1N1YnR5cGUvVHlwZTEKL05hbWUvRjE3Ci9Gb250 RGVzY3JpcHRvciA3MyAwIFIKL0Jhc2VGb250L0NCQkZUTitDTUJYVEkxMAovRmlyc3RDaGFyIDMz Ci9MYXN0Q2hhciAxOTYKL1dpZHRoc1szODYgNjIxIDk0NCA4NjkgOTQ0IDg4NiAzNTYgNDczIDQ3 MyA1OTEgODg2IDM1NiA0MTQgMzU2IDU5MSA1OTEgNTkxIDU5MSA1OTEKNTkxIDU5MSA1OTEgNTkx IDU5MSA1OTEgMzU2IDM1NiAzODYgODg2IDU5MSA1OTEgODg2IDg2NiA4MTcgODI3IDg3NiA3NTcg NzI3IDg5NSA4OTYKNDcyIDYxMSA4OTUgNjk4IDEwNzMgODk2IDg1NSA3ODcgODU1IDg1OSA2NTAg Nzk2IDg4MSA4NjYgMTE2MCA4NjYgODY2IDcwOSAzNTYgNjIxCjM1NiA1OTEgMzU2IDM1NiA1OTEg NTMyIDUzMiA1OTEgNTMyIDQwMCA1MzIgNTkxIDM1NiAzNTYgNTMyIDI5NyA5NDQgNjUwIDU5MSA1 OTEgNTMyCjUwMiA0ODcgMzg1IDYyMSA1MzIgNzY4IDU2MSA1NjIgNDkxIDU5MSAxMTgyIDU5MSA1 OTEgNTkxIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDY5OCA5NDQgODg2IDgwNyA3NjggODk2IDgyNyA4ODYgODI3IDg4Ngow IDAgODI3IDc1NiA2NzQgNzA0IDEwNDUgMTA1OSAzNTYgMzg1IDU5MSA1OTEgNTkxIDU5MSA1OTEg OTQ5IDUzMiA2NjUgODI3IDgyNyA1OTEKMTAyMyAxMTQxIDg4NiAyOTcgNTkxXQo+PgplbmRvYmoK NzcgMCBvYmoKPDwKL1R5cGUvRm9udAovU3VidHlwZS9UeXBlMQovTmFtZS9GMTgKL0ZvbnREZXNj cmlwdG9yIDc2IDAgUgovQmFzZUZvbnQvRlRVVFJNK0NNRVgxMAovRmlyc3RDaGFyIDMzCi9MYXN0 Q2hhciAxOTYKL1dpZHRoc1s3OTIgNTgzIDU4MyA2MzkgNjM5IDYzOSA2MzkgODA2IDgwNiA4MDYg ODA2IDEyNzggMTI3OCA4MTEgODExIDg3NSA4NzUgNjY3CjY2NyA2NjcgNjY3IDY2NyA2NjcgODg5 IDg4OSA4ODkgODg5IDg4OSA4ODkgODg5IDY2NyA4NzUgODc1IDg3NSA4NzUgNjExIDYxMSA4MzMg MTExMQo0NzIgNTU2IDExMTEgMTUxMSAxMTExIDE1MTEgMTExMSAxNTExIDEwNTYgOTQ0IDQ3MiA4 MzMgODMzIDgzMyA4MzMgODMzIDE0NDQgMTI3OAo1NTYgMTExMSAxMTExIDExMTEgMTExMSAxMTEx IDk0NCAxMjc4IDU1NiAxMDAwIDE0NDQgNTU2IDEwMDAgMTQ0NCA0NzIgNDcyIDUyOCA1MjgKNTI4 IDUyOCA2NjcgNjY3IDEwMDAgMTAwMCAxMDAwIDEwMDAgMTA1NiAxMDU2IDEwNTYgNzc4IDY2NyA2 NjcgNDUwIDQ1MCA0NTAgNDUwIDc3OAo3NzggMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNDU4IDQ1OCA0MTcKNDE3IDQ3MiA0 NzIgNDcyIDQ3MiA1ODMgNTgzIDAgMCA0NzIgNDcyIDMzMyA1NTYgNTc4IDU3OCA1OTcgNTk3IDcz NiA3MzYgNTI4IDUyOCA1ODMKNTgzIDU4MyA1ODMgNzUwIDc1MCA3NTAgNzUwIDEwNDQgMTA0NCA3 OTIgNzc4XQo+PgplbmRvYmoKNzggMCBvYmoKPDwKL0ZpbHRlclsvRmxhdGVEZWNvZGVdCi9MZW5n dGggMjYzMAo+PgpzdHJlYW0KeNrtXNlyG8cVfc9XzOOgIrR7X+JSVWTZzFLZqsSUnLL8AJIgiRQI KASgxV+f28ts6J7BDDAEFcUvBAbT613OPbcXZhhhnN1l7uMP2XeX31ywTCMjZXZ5m0mKlBTZlCqk jcguv/8p55MpI4rmb+4nVOe72eoOfuA0fzvRIt9NpgRTlX8/X93d7db2Dcsv7Ju5LefevfWPy8Ve zZ8v//zNBZGZgc6Z7RxDvwIZzFy//3icCJKv3Z9bZEtnP1y68dbrGIaMJtlUMKSMdhX/fvVhsd5t lp9fQHdC5R/v5yvfma7qKYY049ClrXHlX9Paa4Q5C29fTkAcKsfxgIlA3KhQLPR2u360X3Q+8x8w C5zPVjfrB/ss89vd6nq7WK/824sX0cimRiIWdECN9LJIDFApE3r+KYxMVa+tGnV4/cOPoTrBmURG cVeAg/55xpHSypV6b4eN81snaNAEdEC8AfwR9Mjzb1+FRgRUsiK387ffVDbFyISB4sRAieAZaIny ujRJaI20SPPfkVzslNQghf1sPzU8usKmmjyTCIMeCUVceGOTYTh1PXDEQMRTCnM0rtC/YjHC1LHW UIggSnypRdQdRZoUyniJo4kRghTX7kOIdnXrPW2TtGi+i+pKpHnx9l0edQ+OoApHuI9nKGBw2ZSA akR9eo0GAB+yqsS3YC9SptoiGBEwy7i1PWEVhv1bEk0GmhBa1Hp7N/HafumVTVqVzimSQp1V6WZP 6XRP6aqudBo6orUhwygo/CXED/gd5STqSCJKZehIJwyHMmWnVbQRnCPRW/C/Ht0V1iRkGywrMFgM ciRYI8WoK/02hcPUAhkb4tbkMA5TIfLF1n7KfLHxz9v7uf/h2gHyxj1xCC3+17/880f7+WKv8Hq3 fb/b+h8/zJa7edlopFBjJSMG+ZlJuRmvA2mtPkdcmqwq0XQzk/YyX5SkGlPHtUXHHBgbszE+ZmNi RJHJMQemIsvbbwwQMfIQa3yFbXouNWWaANcC6gQYZAIGvXm/BL+JfJQhIfpECF7HwgYcICp5bYiL 1dZyRSNzPb2ynmq/braPQBFjzwIsYcb0c6xZangUuG08vmQEa6jjKm4M0Azo6TGNXScbY+aoxm7i xgySJKUG2mxMDjIUp5fX69VmcTN/9PwdfnDoaL/8dfHp9Xq5e1j5x/V7C61zx9tnluNuvKURaZls 09Is7lq6bNuK7E2jMqItUkPkEFH86+n2PpD8tSPaN/7Jt65L+LbfHXxHJH05mcJolzEp4wQxzPZG QeqsqhgD9XHpNg4JQCYKu03huWXROKg14dS0YHwkWZd21lXl4I6vy46oW4yZnzBfcUJdGWuqXvku Nqf6nF4kGCHgLxicdXoMFlGLzjZLIgoJJiribX+DFFap5k+Q0SmfIP0+Gj2gALg4cElDfP6KnUGZ HDP41DjHpPwserV+FBIuEgrTUIglC4tm4aLFqlKiMNsrXFWKhMS1Y8LcJtWystk9Cb2OJfQ6ltCr RGYICSYjFpu0KJhpahROkxSSu7CEcLKadIea3iQSLalZd5wSveKU6ABw1cx9otUDyG+IiyqVjXxK dSYN7w49ICCqHYUHfkFcoc9xQxx0cqghDjlOs6FfUg1JlqQRumEHmoOZCcTYOFbWzMg4mFdlZC+T AxCAHecysQFWciCDrqsDBtrUxlVKG1SlSNOgbmweWe/nOtUPgxT0xH6EY8hVPzcpsRF9xHz2dC8h vxvN+FJpc7n8isFnsE+bA1dR+Wb9EHMlS1NUEb66HX3g+s3nFMcstTWwsV9SjWFJEo01qV6zNeQl 8Xbu2dv97MM8EbKJBG1Dy5CYUB15qQnqa4vE9pEOCcRi7ECcjK2MADCRyPCK2bRHzSlF2LDjwyaP MU1/5WFTnOBNjbDZI2qK546aPAYu/TRREyNM5SF/1O3+OCC5//8Kh6S5m4BBXgyMXolDcFEHP5CD UA20yIn3lM5IpSARxn4RfLa6SSnfLpxZOIboEeC4WlhuZHFCKisno47NP8q6NaBrpOx2HBrkYw7A IfFwSJ8LDvnoq120fU2pFQ71SHDYBw3FADTsAkOWYhTPAIayDoYxFuIeRFX02E5M7pBRmBuvx7uc HnZkxhRiQbYXEyVzv/0edq3ndnHtPzu3qhdbLIhJ0NJkSWpdEQyq3OYp9uUDi/MbMiv/o39YXu+W s+08BinsNu96cYVPJY+dMul5qCqsptYkBeuT5eAnqbVrXq7izTbF+mFYN1x/3CTXjAzYFyHOj1hI DYbGPPY/RULYARICmuF6eFRyHsV9VKJ9+IUYyPd1TdaJiJOg7nSP5/dclYslIkCmqi+vp41tA4vf AuzW9NunJalFUbtp5HoKik1HQ3+QpJ9oO8x4vJWMRoYDozOmjnRUxIDov+BCe6lWiCoguZJCy7L3 UfkLf/L8RQCtUc0tlm4e+wQy102Zd0uMP7fEuEGYiIbbHs/IdbfEdJ1uHSevUTLkoZSwgbIU/L0n XMWcaEQE1+0IHu/BATXhptwbmkIGklN7olGpnJtU3LTF6150sEmL73FL1k1KpnKbwCRKi7c03iuz Z/8MbRrnoYFEJxyRUqR1AJayjVY1Tp+Gr1Z5VdbMpD0eqSeLR2o48056+oFoRA9FI3UoGpGnx4rz RCNxrmjEnjB+q8MSk32iEe8TjcgR60NpifHnk9hY8agf0nTlvRwDloQU7bS8lw7Me2u7F3VLkEDN IR3HiFEz8irBidyZfR1oFY4LxwZlj6qrrLE+2GOZMt7KaUv1xlyePDUAjrCuQHqs5/GzLCyoIxcW etLSlEXopkXImkV0MiblrYSnCWMBJte+VOJIGUNYkOYZq9g6ehgaOZul/Zr6n5NsyZG3sL4a6tCa +ouxN+OOktgZFku+BLIlMSK+lz9twwHg3eNqU57W9V/c4XD4vLJULD7zAryLuUilAfR5H8yNFAOh vnx9kLaMt+/c0zZaEKz7TO11CugFFX3RrTtBOx9mdKqSn6jKL2OF7/gDal37fuDHgtWGEe5LJahG /brUPGU2utpkO47TPwNgdeKOgTnpsOO+jpMuwDBrBPjo25e68/al7Jfh9L9bc/iGSNvtSzXcndO3 L3n37Uv/mDhtD+STFfIojza2XsOANJiofldBwtnAv60/+uCR3F7ezH1ICXdPZvFlpymzV9+NO68i mOxvESp9H7f99rVwt6/1KLevVcfta9b/9rUe7/Z1yhS6XFQwkEaYx8f7xXW417N4eL9czMtNdtUY sFCswQJeTUDfNx8Spm/X2/WZbrs35d15AOQYw/pyrvU/m2HFEIwRL/8dQjJJrzOMX/+bwkn/TaEB 7bUeGWT+nEdKaNn7GOO6e/v98xJVFEGCe8lv1gkUgVxCuBudVSrYjSKqp5aj0GlZLAO5m3AI8gA0 PMwSS3SWmWl7Bo3T9stS1J1wq8rcxrOu8/5xpjslojLqPTMExlBN+86b0zuqcALT7c1P0Wtg+ssC OdslPb/t7628cU7q/+vhd8E9fvNfu/YpRwplbmRzdHJlYW0KZW5kb2JqCjc5IDAgb2JqCjw8Ci9G MyAxNSAwIFIKL0YxNiA2NyAwIFIKL0Y4IDI3IDAgUgovRjIgMTIgMCBSCi9GMTcgNzQgMCBSCi9G MTAgMzMgMCBSCi9GMTUgNjQgMCBSCi9GMTEgNDcgMCBSCi9GOSAzMCAwIFIKL0YxOCA3NyAwIFIK L0YxMiA1NSAwIFIKPj4KZW5kb2JqCjcxIDAgb2JqCjw8Ci9Qcm9jU2V0Wy9QREYgL1RleHQgL0lt YWdlQ10KL0ZvbnQgNzkgMCBSCj4+CmVuZG9iago4MiAwIG9iago8PAovTGVuZ3RoIDY4Ci9GaWx0 ZXIvRmxhdGVEZWNvZGUKL05hbWUvSW0yCi9UeXBlL1hPYmplY3QKL1N1YnR5cGUvRm9ybQovQkJv eFswIDAgMjM4NCAzMzcwXQovRm9ybVR5cGUgMQovTWF0cml4WzEgMCAwIDEgMCAwXQovUmVzb3Vy Y2VzPDwKL1Byb2NTZXRbL1BERiAvSW1hZ2VCXQovRXh0R1N0YXRlIDgzIDAgUgovWE9iamVjdCA4 NCAwIFIKPj4KPj4Kc3RyZWFtCnicK1Qw0DMysjQ3MlQwAEFkTnIul36QuUJ6MVehgrGBsZ6xiTlY 3MzQWM/UFKzaAAgMLQygai0UXPK5AoEQAPIKEVQKZW5kc3RyZWFtCmVuZG9iago4MyAwIG9iago8 PAovUjcgODUgMCBSCj4+CmVuZG9iago4NCAwIG9iago8PAovUjggODYgMCBSCj4+CmVuZG9iago4 NSAwIG9iago8PAovVHlwZS9FeHRHU3RhdGUKL09QTSAxCj4+CmVuZG9iago4NiAwIG9iago8PAov U3VidHlwZS9JbWFnZQovQ29sb3JTcGFjZS9EZXZpY2VHcmF5Ci9XaWR0aCAxNzcKL0hlaWdodCAz NTgKL0JpdHNQZXJDb21wb25lbnQgOAovRmlsdGVyL0ZsYXRlRGVjb2RlCi9EZWNvZGVQYXJtczw8 Ci9QcmVkaWN0b3IgMTUKL0NvbHVtbnMgMTc3Cj4+Ci9MZW5ndGggOTk0Cj4+CnN0cmVhbQp4nO3c O29TQRCG4WMuwpG4BGjSukugCRWiczooUyEqajpKqEJ+AfALTAcd6SgjqpShgYQu6dJwRyKIq8DO ke1ZoWXnG8Uneaex9LGeeTBrwypeWr+qhlULcXghji/E8dVc8cVX9tfOvbXZ+TeJJqnQkyXD+fX+ 4564tWTXLCde/+SfSSr0ZP9ciFiSIdbqEPsHlGSItTrE/gElGWKtDrF/QEmGWKsrFp/5aNeczsyy F/oafug/jsuHS/KSyBsilmSItTrE/gHyhoglGWKtDrF/gLwhYkmGWKsrFnMGYVcgRoxYqkPsHyBv iFiSIdbqEPsHyBsilmRZYs4g7ArEiBFLdYj9A+QNEUsyxFodYv8AeUPEkixLfPa9XXP8W16WDI99 Fzecftd/TP4WFbWw1I1pjLguxHUhrqtJ4p3NbjUQ727NytsHiDcXNqYH4nvbPXn7iF1xq32/L966 tDEj7x4h3plbm/0rXrx8R9895J334PnTP+KVu+ttffMQ8W6nd7WzOjPX6wY0j/l0W1le76w+ev04 onfQ5/GV6w97iwFvuypM/OJaNXPzdkjrqL/zbjyZXwt421Vx4p3Os25M5z2x/E566kcZ3Ek3hRix XYMYsV2DGLFdgxixXYMYsV0z2eKpXbvm1CebTdB3sRr3GiNGjBgxYqkOsX9ASYZYq0PsH1CSIdbq isWcQdgViBEjluoQ+weUZIi1OsT+ASUZYq3uEIn5Fz27AjFixFIdYv+AkgyxVofYP6AkQ6zVIfYP KMmyxKn/ZYob3ppCXBfiuhDX1SQxN7zHKmJXcMN7tELeedzwHqmYTzdueA9XkJgb3kMVJd6fG94n P9ssdes7+QOTqS95T9be8M48+7merD2ZIkZcPBQx4tQAxIhtM8SIbTPEiG2z/RCnvot14qvNUseN qu14sva7WBP9GiNGjBgxYtsMMWLbDDFi2wzxwRRzBmFXIEaM2DZDjNg2Q4zYNkOM2DZDzBnEFLsC caIZYsS2GWLEthlixLYZYsS2GeIccepO+tEfNkteIU8tPPIz78ncSS8vxHUhrgtxXQFi7qSPVcSu 4E76aIW887iTPlIxn27cSR+uIDF30ocqSjw5d9JTWTJM3Ul3Nbzwsv/43+e8RJa90New9GSKGLFj AGLE0gyxVofYMQAxYmmGWKsrFud+FyuVZS90NWwPDjXNfY0RI0aMGLFUh9gxADFiaYZYqztEYs4g 7ArEiBFLdYgdAxAjlmaItTrEjgGIOYNIswO6KxAjRowYsVSH2DEAMWJphlirKxbn3klPZdkLXQ3H /1+s5hTi+EIcX4jjq3ni34fJLrUKZW5kc3RyZWFtCmVuZG9iago4NyAwIG9iago8PAovRmlsdGVy Wy9GbGF0ZURlY29kZV0KL0xlbmd0aCAyMTg5Cj4+CnN0cmVhbQp42sUZyZLbuPWer9AtVKUFk1hI IHNIZew4cSqVScqdcarSOaApqJtlipS5uNP5+ryHB4ikJbt7LLtyEcCH5e0btEpZmq7uVn744+rH 6xevxUozk+er690q04bxXK82vGDaqNX1q38lL7vHw2AbWz/2Vb/eCMmTdoejSIZ7R4A/2f6eQK/X WiVjUw5V29DaX/7xzw1XOXyoTCVq/e/rP6/+cO0x85UBzAIxFwUrUrPaKMEKowlx7WxXP661SK7W G5WK6SqVygSJUalKmnYggKXhrl1vuE7wt0i2tOfQu2276Wyzbfe0axdoZPR5jZzgpGyb3pXjUH1c w3Hnqd1kkhkpYcyYUSSVB1xuuy1KJAdikNk8DxKByT1JJFfJx7UC2urR0aeXHYyTWPxuvA5Q6iRs K1032Hhr52qLxPZXtPhwX5VrDscI+b2rD7SxHTua2O3Gk54GonNPNPHU9bZ7hG0cFNjiKJNt1Q9V czdWnmgATNTBx65DqQmuUMQIiIL0i5Oy4euhGsINbVM/xpmj0x9G1wUYIJ6TRzIl4QkBcrVl7Rh9 vFtr7qUieFLahoBbJFzI6Uhv92E23AMnYbUN98G2jqYfUW4gAqJYBFsW3rYY0vTidT5ZJdAnBFNp 5ukTjK+BXmmSt8O4RU60pPM6+gJM3t5Xu4HWfl4blbhyaLvPWH3OWZErNLAczF94LD95HRoNOozE kr4AFKzufU+ft97SXWnHHpEbg1R0YeqdFUZLw39d14aFJu6NW8guPJ2ExttX4e0LPqv9oa5cH0/Z geSkF3KamdlbWp/zyXItYBeu3iQnxwXThQzLllazFA4ZgMKygpiUAwYmjfR7qhMEgomsWE07btYo mhx5jY7V1sRmjyvKS4HrgvSGW0tblyP5Ga2gZnHhDMGZyFlW6F9Ospm2cKYzE274TXaKImVKqxlL P4DtgWffniLTYDvyaWT6CWT5KbLyLDJhvgtn21NkhuWZ+OXI+BeQRcvYVh1YPKYXnjAyiTdR8d0W wwXuGloC3XBV/IeSAZcZg9D4SeRCV5KpSQ5de1u7/RV97X1cf7z1ucgRzNLQuAea9BQvcDr3Q1pq x3pL8+mOLE127dgEOFKIY+cOtS0DjpskPXUyEIVRRRDVDyeSkkzyaCKnSoMMqPkXz8abxVecjXjl zZqRlCF8M54uc+51CG4Y7oNkcB6iIH00ITGEcAeQqol5wdHSJGX2RDGSGfBjWXjkf0V9CcNDBonB kk+kGAH6fk9lA62MFIsjbpj0gx3ClMIwkD+CceWuOxEbzzTLRBTNy1PTzlgho+mDMbvqGOAQu6Xr d2Nd02xbIaLRp75gyZJpkS1kbHcD2r7MMbd2ztG0Q3tDC4fiw3rLA+DELH4Rs3QuTHbObW+tzyTv CXJbU3E2wQRVFye854alWTSaH09557OMQsXEJwGayaPNvTx3XKoouqq54Xk6uqYM5Z5IC5aLpYe3 43AYMa1DRj/Y7jQFKgV1Qr7EOAtTBQNuZoFMnNCkGXjuLFAFTSDCAcX1sKaqFgFRHzi3foylJwDa rroj48o/yezybGDICsU0sPn1gSF71llxwVmJYRuZ25IBuZ7R9+vqLnhZnvBg1kUKfrNUHziplyEm f8VD0ldLn/CAQxcs1PU9QXwZgGMTztz6mD44uopugMCE5gOQWC7jzj1cYu/CsSpg6F0ow21NN5Ay Q/Epp2ZMgs1o6MUkhyBkPBvALfCdmSLhYf+seRMQ36MBvprzhV3Y3zxfJvA1b+KmUh+AoX4H8E/R iuRU0sKGn9dQ1y5K2g/QSxpILBlWcOn0wdMUUjOSnzMlV+V+9eLNnq9etau/fy7eStBcLnUM9kjw LIrkGDEQ0h7IBrpYrIEdnI0iGbSxRV4so8jCKRUkxJlXZupclIUYPG05F2wgEBv1bNcvTnAUn7i+ b3OQK1v7it+i6z/2xP08XPlNZMzo+CFG8c/FqE2mC6CKL1zjSwSrz8YqAyqddqChSJUmdqBx3/Zh tghdElqnYypRWbA2v83nDJjE4IXzRTkER21PcO/MefLQEDhuj6EA54LRiFmbWvicpcWynFjGxnki l9RfTolbxv7ShP7yiqB0VCCDecz61KMaekoYurEcQiKGbLqB/N8NtNw4223Ktq4r9NL+TLu+bztH lakDlWdl5Xw3g0Wrh/pMjJOph6k+bg7dLla4x6bedb8ObQ82lfge0aBKBgpOAH6osEqgvqjsnO3d vP5VMe5n2aye5OCsPAacGyiLT8wEc3iM7/zEzKgsFFDiE7sFP5cTQWfTllgcSsFSZRbafIfvROGZ gLjxLwC2fk/ln6UysfVJfF4OHmXm3xXmMpvXj2ABLr5zABD6TfbkS1bGoK/3xP2+CU8QXGtMMTGA ee94JDC1myYq89gY4Nq85sR2pOppi7OxT8dd0deKpJ13sLMrQfcqvEXhgWjxuHSsonEhJrXNmfcv 4iiYImZhIO1dePbRcDlKHpY6B8ZfeZH1YYlaGO+79NR1RacfYs0MA3kPTHpwj+MjFww772totPdh q++g/NaQnrhe1PZ+7c1A4zB2n/jYsa7DF7OM3jVgxo9vKAC0NOHxNQtmmoYJkX8BTJdvchCjIDf1 u3CGhAITCAnbKookpwAYKPCLfbWNQl+SaeN7qg5521CX+lua35wpzAo5lQNf7tj4/6nby2/WV8TT Ofq5AO7Fsy7il1SWF5xVTzMgv5sGjlK8gIHiW2ngIilecHZuQvxrNPBNmpNvpAF+iQbEN9fA8wKA 18DsyUYs4tY5pvSzu82L6LrApUgp3KBSxDmlQPH63S3jQr9mxMC76SkfP31FYHwS3dPMlxIm1gjT nwr98LtwQ/j/hRtMuW5L20NtCus9/Rfib21p0TY95XRqEjeFhgbJnHkxxVLqwwi4/D9xVE/96n8G DQxbCmVuZHN0cmVhbQplbmRvYmoKODggMCBvYmoKPDwKL0YzIDE1IDAgUgovRjIgMTIgMCBSCi9G NiAyNCAwIFIKL0Y4IDI3IDAgUgovRjEwIDMzIDAgUgovRjkgMzAgMCBSCi9GNCAxOCAwIFIKL0Yx MSA0NyAwIFIKPj4KZW5kb2JqCjg5IDAgb2JqCjw8Ci9JbTIgODIgMCBSCj4+CmVuZG9iago4MSAw IG9iago8PAovUHJvY1NldFsvUERGIC9UZXh0IC9JbWFnZUNdCi9Gb250IDg4IDAgUgovWE9iamVj dCA4OSAwIFIKPj4KZW5kb2JqCjkyIDAgb2JqCjw8Ci9MZW5ndGggNjkKL0ZpbHRlci9GbGF0ZURl Y29kZQovTmFtZS9JbTMKL1R5cGUvWE9iamVjdAovU3VidHlwZS9Gb3JtCi9CQm94WzAgMCAyMzg0 IDMzNzBdCi9Gb3JtVHlwZSAxCi9NYXRyaXhbMSAwIDAgMSAwIDBdCi9SZXNvdXJjZXM8PAovUHJv Y1NldFsvUERGIC9JbWFnZUNdCi9FeHRHU3RhdGUgOTMgMCBSCi9YT2JqZWN0IDk0IDAgUgo+Pgo+ PgpzdHJlYW0KeJwrVDDQMzKyNDcyVDAAQWROci6XfpC5QnoxV6GCoZGZsZ6BJVjc1NJSz8LYAqzc AATMTIwgii0UXPK5AoEQAAZdEZ4KZW5kc3RyZWFtCmVuZG9iago5MyAwIG9iago8PAovUjcgOTUg MCBSCj4+CmVuZG9iago5NCAwIG9iago8PAovUjggOTYgMCBSCj4+CmVuZG9iago5NSAwIG9iago8 PAovVHlwZS9FeHRHU3RhdGUKL09QTSAxCj4+CmVuZG9iago5NiAwIG9iago8PAovU3VidHlwZS9J bWFnZQovQ29sb3JTcGFjZS9EZXZpY2VSR0IKL1dpZHRoIDczNwovSGVpZ2h0IDM1MAovQml0c1Bl ckNvbXBvbmVudCA4Ci9GaWx0ZXIvRmxhdGVEZWNvZGUKL0RlY29kZVBhcm1zPDwKL1ByZWRpY3Rv ciAxNQovQ29sdW1ucyA3MzcKL0NvbG9ycyAzCj4+Ci9MZW5ndGggMTEyNDkKPj4Kc3RyZWFtCnic 7Z1PbJXXua8XTQLbqv9AUqmeBetOgJyBPWnCKPYoWHcQLF0pYUSjcybRHQSkUwVG4FETnSOZDK7a SucIMqhMpCuZDK5MRoaqEnRkV7oJZHAVR6oUt1KC/1XeISS5X3EOMZ+3Dd+7Fmut317PM6hi03et 9137Ye2fPxvY8/333zsAAACAzNhDRgEAAIAMIaN0FVeuXPnwww8XFxdv37596NChwcHBV1999fjx 461WK3VrkC9oA01ZWlra1OYvf/lL9eHPfvazTWcOHjyYujXIF8NVQ0bpEqqX/I033th8yatrYmxs bG5urrpHKiGqX/rNb37z0ksvpe4RsgNtwMDVq1fPnj1buVFpc/ny5eozv/zlLytnqs+//fbb1X+n bhCyw3zVkFEexeJ/jg/9y9WHP3fsPz6b/eeDSdrpyDvvvPPBBx9sfZn37Pnxld2UY3R09Ne//nW6 HktCwRmHNrmhoE273a7SSeXGxYsXq/eb6jPnz59/8L/Vr7755pvVG8/09PT+/fuTdloMCtr4XDVk lEfRyYB/8K9z3//baPRuOlDdDn/961+npqa2Pi7basDW/1tlSfQGyyN7ZxzaZIiCNlUE+fnPf76Z SDbZmlE2uXLlyrvvvnvjxo3YzZVJ9tp4XjVklEexacDW1/var/aM/XsmCiwsLFS3xtzcXO37edsN qBgfH3/rrbeOHTsWscEiydsZhzZ5kr02N2/ePH36dC18bM8oFdWXxS+//DLf9IlB3tr4XzVklEex 3YAfHEj/OK3dbo+NjVXBc3h4uPZLHQ1YWlqq/v/VFcNj2CdLxs44tMkWTW06ZpTKmer9ZnZ2dvP7 QfAEyVibIFcNGeVRdDBg81PpDbh06dL169cvXry4/Zc6GlBRfRn0/PPPnzp16sl3VzAZO+PQJlvy 1ubKlSvvv//+zMxM7fMdM4rDmWhkrE2Qq4aM8ih2epKWwYO0EydOvPrqq6+//vr2X9rJgMuXL3/4 4YfT09NPvruCydgZhzbZkrc2Z8+eHRgYOHPmTO3zO2UUnIlExtoEuWrIKI8i45+aHhkZqSLq9sdo bmcDbt++PTExcevWrSffXcFk7IxDm2zJW5udfixpp4yCM5HIWJsgVw0Z5VHs9FPTHjH19OnTCwsL Xl3d5w9/+MN3331nKORFf7Jk7EzFH//4x3v37hkK0ebJ0o3a4MwTJ2NtgrxDkVEexY4/kWR3YPE+ /q2dPHnyo48+OnTo0PZf2imlLi0tVdn2iy++8N8ddiRjZ9z9Pz46MzODNtmRtzZnz56dmpra/hdt 7fQcBWcikbE2Qd6hyCiPopMBO302Mrv8odCdDNjpB98gJBk749AmW/LWZqefgd0po+BMJDLWJshV Q0Z5FI9lwGZs3fJNwNrztyfz7cELFy58/vnn1Rc3239pJwN2ulAgJBk749AmW/LWZqc/o7GTGzgT iYy1CXLVkFEexS5P0u6/ru4fv/5Pc58denfof/+PhwzY8uGTYZe/hKCjAe12++jRo9PT0x0fvkEw MnbGoU22aGrTMYvs8hdjQGAy1ibIVUNGeRQ7/kTSw8mz9pLHujh2+gN+HQ3Y6U8PQmDydsahTZ5k r03HRykdM8o777yzsrLCv/QUg7y18b9qyCiPoqMB25+MdTDgx6on+l3BEydOvPLKK7W/dnq7Adeu XasM4B/RiEH2zji0yRAFbcbGxt5+++2tP2GwPaMsLi5W/7dbt27V/vpzeCJkr43nVUNGCcTOsfS+ DO7J/Xn15eXlSoLBwcGpqakHf4VwZcCdO3c2P2y325OTk5UBs7Oz/HXmGZHOGYc2uiTVpsofb7zx RvWW8+CL3Sqd3Lx5s/pyeVOSS5cuvfvuu9XXzXyXJy9k36HIKIHY7dHZP7456J7w1zebV8Nrr702 Ojpa3Q4HDhy4ffv2F198UV0fH3zwQfV5ntVnR2pnHNooklqbzXeUypBKj8qZq1evvvfee7///e// 9re/ffTRR61Wa+tbEeRCam3MVw0ZJRCpDXD3f0Dpt7/97fXr1xcWFqroum/fvqNHj7700ksnT57k px1zJANnHNrIkYc21Ve91VtL5Uz1HlN9eOTIkV/84hevvPJKx7/4HNKTgTa2q4aMEoiHDahe8//z 3394yRc3f6w67p9THxoampubO3jwYMQ9oSGZOePQRgK0AQOZafP4zpBRvPnhj3k94Mc/73V1yycO xm2KWyNrsnTGoU3moA0YyFIbMkrpcGuAAbQBA2gDTSGjlA63BhhAGzCANtAUMkrpcGuAAbQBA2gD TSGjlA63BhhAGzCANtAUMkpZXL169fbt21v/SdKaAdX/YWFhgb/rAraCNmAAbaApPs6QUbqBpaWl w4cP37p168E/3bTVgM1/qGlqamp0dDRhk5AbaAMG0Aaa4uMMGaVLOH/+/J///OeZmZnND7cacOHC hevXrz/4JYAHoA0YQBtoitkZMkqXUEXR6lWfnp7ejKIPDKgC7MjIyPz8/PZ/HRsAbcAA2kBTzM6Q UbqHK1euTE5OVi+222LAG2+88fzzz9f+5XSAB6ANGEAbaIrNGTJKVzE2Nvbqq6+eOnVq04Dl5eWJ iQn+kXTYHbQBA2gDTTE4Q0bpKhYWFsbHx6ugevTo0cqA6uU/d+7c8ePHU/cFWYM2YABtoCkGZ8go 3cbp06fd/adqJ0+e/NOf/jQ7O5u6IxAAbcAA2kBTmjpDRuk2Nn8EaXl5udVqVUF1eHg4dUcgANqA AbSBpjR1hozShVy4cKHKqqdOnZqamkrdC8iANmAAbaApjZwho3Qn4+PjMzMz/PAaNAJtwADaQFMe 35mHMsrIyMjCwoJ51+eee+7LL7/Uqu3t7V1fX7fVem7tU9vX17e2tmarPXLkyMcff2yr7YiPNj6H 4FmuWJtw6+Hh4c0/NBiKVNqInr/oyGG14R0q5taZXDUPZZQ9e7weq/iUK9Ym3LqqPXfunK12cnIy 7MOzMs+fkT0RHUSxbdGRg6+meP6MTEZRHZmMknBrRvZHdBDFtkVHDr6a4vkzMhlFdWQySsKtGdkf 0UEU2xYdOfhqiufPyGQU1ZHJKAm3ZmR/RAdRbFt05OCrKZ4/I5NRVEcmoyTcmpH9ER1EsW3RkYOv pnj+jExGUR2ZjJJwa0b2R3QQxbZFRw6+muL5MzIZRXVkMkrCrRnZH9FBFNsWHTn4aornz8hkFNWR ySgJt2Zkf0QHUWxbdOTgqymePyOTUVRHJqMk3JqR/REdRLFt0ZGDr6Z4/oxMRlEdmYyScGtG9kd0 EMW2RUcOvpri+TMyGUV1ZDJKwq0Z2R/RQRTbFh05+GqK58/IZBTVkckoCbdmZH9EB1FsW3Tk4Ksp nj8jk1FURyajJNyakf0RHUSxbdGRg6+meP6MTEZRHZmMknBrRvZHdBDFtkVHDr6a4vkzMhlFdWQy SsKtGdkf0UEU2xYdOfhqiufPyGQU1ZHJKAm3ZmR/RAdRbFt05OCrKZ4/I5NRVEcmoyTcmpH9ER1E sW3RkYOvpnj+jPzQBwMDA6urq7Z1K/r7+83lqWp7e3vX19dttZ5bJ6xdWVmx1XbERxufQTzLFWs9 y1utVrvdNtdubGzYajuSShuUi7x1wNuGd6iYW2fyDsVzFEb2hfOPVuu/NY/fUE5o67CrKZ4/I5NR GNkXzj9arf/WZBSUE9o67GqK58/IZBRG9oXzj1brvzUZBeWEtg67muL5MzIZhZF94fyj1fpvTUZB OaGtw66meP6MTEZhZF84/2i1/luTUVBOaOuwqymePyOTURjZF84/Wq3/1mQUlBPaOuxqiufPyGQU RvaF849W6781GQXlhLYOu5ri+TMyGYWRfeH8o9X6b01GQTmhrcOupnj+jExGYWRfOP9otf5bk1FQ TmjrsKspnj8jk1EY2RfOP1qt/9ZkFJQT2jrsaornz8hkFEb2hfOPVuu/NRkF5YS2Drua4vkzMhmF kX3h/KPV+m9NRkE5oa3DrqZ4/oxMRmFkXzj/aLX+W5NRUE5o67CrKZ4/I5NRGNkXzj9arf/WZBSU E9o67GqK58/IZBRG9oXzj1brvzUZBeWEtg67muL5MzIZhZF94fyj1fpvTUZBOaGtw66meP6MTEZh ZF84/2i1/luTUVBOaOuwqymePyM/9MHAwMDq6qpt3Yr+/n5zeara3t7e9fV1W63n1glrV1ZWbLUd 8dHGZxDPcsXahFt3jTa6559q5Far1W63zbUbGxvmrWvwDhVz60yuGp6jMLIvnH+02oRbd402BZ6/ /8iZPH7jtVPZmu/1ZFGbcGvebNJuzcj+iA6i2DYZxb9csTbh1mSULGoTbs2bTdqtGdkf0UEU2yaj +Jcr1ibcmoySRW3CrXmzSbs1I/sjOohi22QU/3LF2oRbk1GyqE24NW82abdmZH9EB1Fsm4ziX65Y m3BrMkoWtQm35s0m7daM7I/oIIptk1H8yxVrE25NRsmiNuHWvNmk3ZqR/REdRLFtMop/uWJtwq3J KFnUJtyaN5u0WzOyP6KDKLZNRvEvV6xNuDUZJYvahFvzZpN2a0b2R3QQxbbJKP7lirUJtyajZFGb cGvebNJuzcj+iA6i2DYZxb9csTbh1mSULGoTbs2bTdqtGdkf0UEU2yaj+Jcr1ibcmoySRW3CrXmz Sbs1I/sjOohi22QU/3LF2oRbk1GyqE24NW82abdmZH9EB1Fsm4ziX65Ym3BrMkoWtQm35s0m7daM 7I/oIIptk1H8yxVrE25NRsmiNuHWvNmk3ZqR/REdRLFtMop/uWJtwq3JKFnUJtyaN5u0WzOyP6KD KLZNRvEvV6xNuDUZJYvahFvzZpN2a0b2R3QQxbbJKP7lirUJt35SGWVgYGB1ddW2bkV/f7+5PFVt b2/v+vq6rdZz64S1KysrttqO+GjjM4hnuWJtwq27Rhvd8xcdOaA2vEPF3NqnttVqtdttc+3GxsaD D3mOwsi+cP7RahNu3TXaFHj+oiMHX03x/HVHDvXsjYzCyL5w/tFqE27dNdoUeP6iIwdfTfH8dUcm o6SvTbh1PrdG2mYUz7DAkbNqpsDzFx05+GqK5687MhklfW3CrfO5NdI2o3iGBY6cVTMFnr/oyMFX Uzx/3ZHJKOlrE26dz62RthnFMyxw5KyaKfD8RUcOvpri+euOTEZJX5tw63xujbTNKJ5hgSNn1UyB 5y86cvDVFM9fd2QySvrahFvnc2ukbUbxDAscOatmCjx/0ZGDr6Z4/rojk1HS1ybcOp9bI20zimdY 4MhZNVPg+YuOHHw1xfPXHZmMkr424db53Bppm1E8wwJHzqqZAs9fdOTgqymev+7IZJT0tQm3zufW SNuM4hkWOHJWzRR4/qIjB19N8fx1RyajpK9NuHU+t0baZhTPsMCRs2qmwPMXHTn4aornrzsyGSV9 bcKt87k10jajeIYFjpxVMwWev+jIwVdTPH/dkcko6WsTbp3PrZG2GcUzLHDkrJop8PxFRw6+muL5 645MRklfm3DrfG6NtM0onmGBI2fVTIHnLzpy8NUUz193ZDJK+tqEW+dza6RtRvEMCxw5q2YKPH/R kYOvpnj+uiOTUdLXJtw6n1sjbTOKZ1jgyFk1U+D5i44cfDXF89cdmYySvjbh1vncGmmbUTzDAkfO qpkCz1905OCrKZ6/7shPJKMcOHBgeXnZtm7FM888880332jVPvXUU99++62t1nPrVLX79++/c+eO rbYjPtr4DOJZ7lP79NNP37t3L/6+nuVo41nrWZ5Km4Qjh9WGd6iYW6dqu7+/f2Vl5cGHgb82kmNs bKyKe6Ojo6kbASXQBgygDTQFZ8gopRsABtAGDKANNAVnyCilGwAG0AYMoA00BWfIKKUbAAbQBgyg DTQFZ8gopRsABtAGDKANNAVnyCilGwAG0AYMoA00BWfKyihLS0u3b9/e+nrXDGi324uLi4cOHUrS HuQJ2oABtIGm4Mx2ysoo1ctfveS3bt3av3//5mdqBpw/f/7zzz+/ePFishYhP9AGDKANNAVntlNW Rql48803W63W1NTU5odbDajy6cjISOXH4OBgyhYhP9AGDKANNAVnahSXUZaWlg4fPnzjxo3Nx2Vb DZiYmHjxxRfPnDmTuEXID7QBA2gDTcGZGsVllIoLFy5cv359ZmbGbTHgypUrZ8+enZ+frzJs6gYh R9AGDKANNAVntlJiRmm320NDQxcvXjx27Fj1H3Nzc4ODg1V0rT5T8o9Pw+6gDRhAG2gKzmylxIxS UWXSycnJKpNuGnDp0qVPP/10eno6dV+QNWgDBtAGmoIzDyg0o1QcPXr0tddee++996pwOjExUdoP IoENtAEDaANNwZlNys0oCwsL4+Pj1X9UL/zJkydPnTqVuiMQAG3AANpAU3Bmk3IzSsWJEycuX748 PDx848aN0n4QCcygDRhAG2gKzrjCM8rS0tLQ0NDs7GyBP4gEZtAGDKANNAVnXC2jjIyMLCwsmNd6 7rnnvvzyS63anp6ejY0NW63n1j61fX19a2trttojR458/PHHttqOvPDCC5988omt9tlnn/3qq6/M W6c6//7+/tXV1fj7epb71FZfzM3Pz9tqO+Jz26T6veP8jE2lTULlwmoj+g7lo5zoO1RAZx7KKHv2 eD1W8SlXrE24dVV77tw5W+3k5GTYh2cJm1HURle54NrI/d5xfsaKvnb5aCM6CDekTy0ZRXVkMorT 1EZXOTKKI6PE3TrsaorKcUOSUVRHJqM4TW10lSOjODJK3K3DrqaoHDckGUV1ZDKK09RGVzkyiiOj xN067GqKynFDklFURyajOE1tdJUjozgyStytw66mqBw3JBlFdWQyitPURlc5Moojo8TdOuxqispx Q5JRVEcmozhNbXSVI6M4MkrcrcOupqgcNyQZRXVkMorT1EZXOTKKI6PE3TrsaorKcUOSUVRHJqM4 TW10lSOjODJK3K3DrqaoHDckGUV1ZDKK09RGVzkyiiOjxN067GqKynFDklFURyajOE1tdJUjozgy Stytw66mqBw3JBlFdWQyitPURlc5Moojo8TdOuxqispxQ5JRVEcmozhNbXSVI6M4MkrcrcOupqgc NyQZRXVkMorT1EZXOTKKI6PE3TrsaorKcUOSUVRHJqM4TW10lSOjODJK3K3DrqaoHDckGUV1ZDKK 09RGVzkyiiOjxN067GqKynFDklFURyajOE1tdJUjozgyStytw66mqBw35EMfDAwMrK6u2tat6O/v N5enqu3t7V1fX7fVem7tU9tqtdrttrl2Y2PDVtuRnp4eczN9fX1ra2vmrRWV86lNuHVVu7KyYqvt iM9tk+r3jvMztkzlAmoj+g7lo5zoO1RAZ3iOojoyz1Gcpja6yvEcxfEcJe7WYVdTVI4bkoyiOjIZ xWlqo6scGcWRUeJuHXY1ReW4IckoqiOTUZymNrrKkVEcGSXu1mFXU1SOG5KMojoyGcVpaqOrHBnF kVHibh12NUXluCHJKKojk1Gcpja6ypFRHBkl7tZhV1NUjhuSjKI6MhnFaWqjqxwZxZFR4m4ddjVF 5bghySiqI5NRnKY2usqRURwZJe7WYVdTVI4bkoyiOjIZxWlqo6scGcWRUeJuHXY1ReW4IckoqiOT UZymNrrKkVEcGSXu1mFXU1SOG5KMojoyGcVpaqOrHBnFkVHibh12NUXluCHJKKojk1Gcpja6ypFR HBkl7tZhV1NUjhuSjKI6MhnFaWqjqxwZxZFR4m4ddjVF5bghySiqI5NRnKY2usqRURwZJe7WYVdT VI4bkoyiOjIZxWlqo6scGcWRUeJuHXY1ReW4IckoqiOTUZymNrrKkVEcGSXu1mFXU1SOG5KMojoy GcVpaqOrHBnFkVHibh12NUXluCHJKKojk1Gcpja6ypFRHBkl7tZhV1NUjhvyoQ8GBgZWV1dt61b0 9/eby1PV9vb2rq+v22o9t/apbbVa7XbbXLuxsWGr7UhPT4+5mb6+vrW1NfPWisr51CbcuqpdWVmx 1XbE57ZJ9XvH+RlbpnIBtRF9h/JRTvQdKqAzPEdRHZnnKE5TG13leI7ieI4Sd+uwqykqxw1JRlEd mYziNLXRVY6M4sgocbcOu5qictyQZBTVkckoTlMbXeXIKI6MEnfrsKspKscNSUZRHZmM4jS10VWO jOLIKHG3DruaonLckGQU1ZHJKE5TG13lyCiOjBJ367CrKSrHDUlGUR2ZjOI0tdFVjoziyChxtw67 mqJy3JBkFNWRyShOUxtd5cgojowSd+uwqykqxw1JRlEdmYziNLXRVY6M4sgocbcOu5qictyQZBTV kckoTlMbXeXIKI6MEnfrsKspKscNSUZRHZmM4jS10VWOjOLIKHG3DruaonLckGQU1ZHJKE5TG13l yCiOjBJ367CrKSrHDUlGUR2ZjOI0tdFVjoziyChxtw67mqJy3JBkFNWRyShOUxtd5cgojowSd+uw qykqxw1JRlEdmYziNLXRVY6M4sgocbcOu5qictyQZBTVkckoTlMbXeXIKI6MEnfrsKspKscNSUZR HZmM4jS10VWOjOLIKHG3DruaonLckA99MDAwsLq6alu3or+/31yeqra3t3d9fd1W67m1T22r1Wq3 2+bajY0NW21Henp6zM309fWtra2Zt1ZUzqc24dZV7crKiq22Iz63TarfO87P2DKVC6iN6DuUj3Ki 71ABneE5iurIPEdxmtroKsdzFMdzlLhbh11NUTluSDKK6shkFKepja5yZBRHRom7ddjVFJXjhiSj qI5MRnGa2ugqR0ZxZJS4W4ddTVE5bkgyiurIZBSnqY2ucmQUR0aJu3XY1RSV44Yko6iOTEZxmtro KkdGcWSUuFuHXU1ROW5IMorqyGQUp6mNrnJkFEdGibt12NUUleOGJKOojkxGcZra6CpHRnFklLhb h11NUTluSDKK6shkFKepja5yZBRHRom7ddjVFJXjhiSjqI5MRnGa2ugqR0ZxZJS4W4ddTVE5bkgy iurIZBSnqY2ucmQUR0aJu3XY1RSV44Yko6iOTEZxmtroKkdGcWSUuFuHXU1ROW5IMorqyGQUp6mN rnJkFEdGibt12NUUleOGJKOojkxGcZra6CpHRnFklLhbh11NUTluSDKK6shkFKepja5yZBRHRom7 ddjVFJXjhiSjqI5MRnGa2ugqR0ZxZJS4W4ddTVE5bkgyiurIZBSnqY2ucmQUR0aJu3XY1RSV44Yk o6iOTEZxmtroKkdGcWSUuFuHXU1ROW7Ihz44cODA8vKybd2KZ5555ptvvtGqfeqpp7799ltbrefW qdru7+9fWVmx1XZkYGBgdXXVVutzCJ7lPrVPP/30vXv34u/rWe5Tu3///jt37thqO+Jz24j+lk+l TULlwmoj+g7lo5zoO1RAZwJ/bSTH2NhYlXBHR0dTNwJKoA0YQBtoCs6QUUo3AAygDRhAG2gKzpBR SjcADKANGEAbaArOkFFKNwAMoA0YQBtoCs6QUUo3AAygDRhAG2gKzpBRSjcADKANGEAbaArOlJVR lpaWbt++vfX1rhnQbrcXFxcPHTqUpD3IE7QBA2gDTcGZ7ZSVUaqXv3rJb926tX///s3P1Aw4f/78 559/fvHixWQtQn6gDRhAG2gKzmynrIxS8eabb7Zarampqc0PtxpQ5dORkZHKj8HBwZQtQn6gDRhA G2gKztQoLqMsLS0dPnz4xo0bm4/LthowMTHx4osvnjlzJnGLkB9oAwbQBpqCMzWKyygVFy5cuH79 +szMjNtiwJUrV86ePTs/P19l2NQNQo6gDRhAG2gKzmylxIzSbreHhoYuXrx47Nix6j/m5uYGBwer 6Fp9puQfn4bdQRswgDbQFJzZSokZpaLKpJOTk1Um3TTg0qVLn3766fT0dOq+IGvQBgygDTQFZx5Q aEapOHr06Guvvfbee+9V4XRiYqK0H0QCG2gDBtAGmoIzm5SbURYWFsbHx6v/qF74kydPnjp1KnVH IADagAG0gabgzCblZpSKEydOXL58eXh4+MaNG6X9IBKYQRswgDbQFJxxhWeUpaWloaGh2dnZAn8Q CcygDRhAG2gKzrhaRnnhhRc++eQT81rPPvvsV199Zavt6+tbW1uz1fb29q6vr9tqe3p6NjY2bLUV zz333Jdffhm/1ue4jhw58vHHH9tqO+Kjjc9r59Ip99Of/vTvf/+7rdanZ5dOueqLufn5eVttR0ZG RhYWFmy1qX7vOD9jfbZOdUM6P2PDauPjjNO8rvfu3Xv37l1brdN8U669Qz2UUfbs2XPu3DnbuhWT k5PmpzI+W1f7+tT6PEmq2vYZOdVxhX14luq1cygnUptVM/63XJKXXvd3WUBtPFdTVI4bkoyi+oZB RnEoJ1KbVTNkFEN5JtqQUQzlcm2TUeq1BUpPRnEoF7E2q2bIKIbyTLQhoxjK5domo9RrC5SejOJQ LmJtVs2QUQzlmWhDRjGUy7VNRqnXFig9GcWhXMTarJohoxjKM9GGjGIol2ubjFKvLVB6MopDuYi1 WTVDRjGUZ6INGcVQLtc2GaVeW6D0ZBSHchFrs2qGjGIoz0QbMoqhXK5tMkq9tkDpySgO5SLWZtUM GcVQnok2ZBRDuVzbZJR6bYHSk1EcykWszaoZMoqhPBNtyCiGcrm2ySj12gKlJ6M4lItYm1UzZBRD eSbakFEM5XJtk1HqtQVKT0ZxKBexNqtmyCiG8ky0IaMYyuXaJqPUawuUnoziUC5ibVbNkFEM5Zlo Q0YxlMu1TUap1xYoPRnFoVzE2qyaIaMYyjPRhoxiKJdrm4xSry1QejKKQ7mItVk1Q0YxlGeiDRnF UC7XNhmlXlug9GQUh3IRa7NqhoxiKM9EGzKKoVyubTJKvbZA6ckoDuUi1mbVDBnFUJ6JNmQUQ7lc 22SUem2B0pNRHMpFrM2qGTKKoTwTbcgohnK5tnfLKD09Pe1227ZuRV9f39ramq221WqZt963b9/X X39tq+3t7V1fX7fVVvT396+ursav9TmuqnZjY8NW2xEfbXxeO6epnE/PLp1yVe3KyoqttiMDAwNy v3dcupc+la7Or+2w2vg44zSv67179969e9dW6zSVq71D8RxF9YtanqM4lBOpzaoZnqMYyjPRhuco hnK5tvleT722QOnJKA7lItZm1QwZxVCeiTZkFEO5XNtklHptgdKTURzKRazNqhkyiqE8E23IKIZy ubbJKPXaAqUnoziUi1ibVTNkFEN5JtqQUQzlcm2TUeq1BUpPRnEoF7E2q2bIKIbyTLQhoxjK5dom o9RrC5SejOJQLmJtVs2QUQzlmWhDRjGUy7VNRqnXFig9GcWhXMTarJohoxjKM9GGjGIol2ubjFKv LVB6MopDuYi1WTVDRjGUZ6INGcVQLtc2GaVeW6D0ZBSHchFrs2qGjGIoz0QbMoqhXK5tMkq9tkDp ySgO5SLWZtUMGcVQnok2ZBRDuVzbZJR6bYHSk1EcykWszaoZMoqhPBNtyCiGcrm2ySj12gKlJ6M4 lItYm1UzZBRDeSbakFEM5XJtk1HqtQVKT0ZxKBexNqtmyCiG8ky0IaMYyuXaJqPUawuUnoziUC5i bVbNkFEM5ZloQ0YxlMu1TUap1xYoPRnFoVzE2qyaIaMYyjPRhoxiKJdrm4xSry1QejKKQ7mItVk1 Q0YxlGeiDRnFUC7XNhmlXlug9GQUh3IRa7NqhoxiKM9EGzKKoVyu7d0ySk9PT7vdtq1b0dfXt7a2 ZqtttVrmrfft2/f111/bant7e9fX1221Ff39/aurq/FrfY6rqt3Y2LDVdsRHG5/Xzmkq59OzS6dc VbuysmKr7cjAwIDc7x2X7qVPpavzazusNj7OOM3reu/evXfv3rXVOk3lau9QPEdR/aKW5ygO5URq s2qG5yiG8ky04TmKoVyubb7XU68tUHoyikO5iLVZNUNGMZRnog0ZxVAu1zYZpV5boPRkFIdyEWuz aoaMYijPRBsyiqFcrm0ySr22QOnJKA7lItZm1QwZxVCeiTZkFEO5XNtklHptgdKTURzKRazNqhky iqE8E23IKIZyubbJKPXaAqUnoziUi1ibVTNkFEN5JtqQUQzlcm2TUeq1BUpPRnEoF7E2q2bIKIby TLQhoxjK5domo9RrC5SejOJQLmJtVs2QUQzlmWhDRjGUy7VNRqnXFig9GcWhXMTarJohoxjKM9GG jGIol2ubjFKvLVB6MopDuYi1WTVDRjGUZ6INGcVQLtc2GaVeW6D0ZBSHchFrs2qGjGIoz0QbMoqh XK5tMkq9tkDpySgO5SLWZtUMGcVQnok2ZBRDuVzbZJR6bYHSk1EcykWszaoZMoqhPBNtyCiGcrm2 ySj12gKlJ6M4lItYm1UzZBRDeSbakFEM5XJtk1HqtQVKT0ZxKBexNqtmyCiG8ky0IaMYyuXaJqPU awuUnoziUC5ibVbNkFEM5ZloQ0YxlMu1TUap1xYoPRnFoVzE2qyaIaMYyjPRhoxiKJdre7eM0tPT 0263betW9PX1ra2t2WpbrZZ563379n399de22t7e3vX1dVttRX9//+rqavxan+Oqajc2Nmy1HfHR xue1c5rK+fTs0ilX1a6srNhqOzIwMCD3e8ele+lT6er82g6rjY8zTvO63rt37927d221TlO52jsU z1FUv6jlOYpDOZHarJrhOYqhPBNteI5iKJdrm+/11GsLlJ6M4lAuYm1WzZBRDOWZaENGMZTLtU1G qdcWKD0ZxaFcxNqsmiGjGMoz0YaMYiiXa5uMUq8tUHoyikO5iLVZNUNGMZRnog0ZxVAu1zYZpV5b oPRkFIdyEWuzaoaMYijPRBsyiqFcrm0ySr22QOnJKA7lItZm1QwZxVCeiTZkFEO5XNtklHptgdKT URzKRazNqhkyiqE8E23IKIZyubbJKPXaAqUnoziUi1ibVTNkFEN5JtqQUQzlcm2TUeq1BUpPRnEo F7E2q2bIKIbyTLQhoxjK5domo9RrC5SejOJQLmJtVs2QUQzlmWhDRjGUy7VNRqnXFig9GcWhXMTa rJohoxjKM9GGjGIol2ubjFKvLVB6MopDuYi1WTVDRjGUZ6INGcVQLtc2GaVeW6D0ZBSHchFrs2qG jGIoz0QbMoqhXK5tMkq9tkDpySgO5SLWZtUMGcVQnok2ZBRDuVzbZJR6bYHSk1EcykWszaoZMoqh PBNtyCiGcrm2ySj12gKlJ6M4lItYm1UzZBRDeSbakFEM5XJtk1HqtQVKT0ZxKBexNqtmyCiG8ky0 IaMYyuXa3i2jDAwMrK6u2tateOaZZ7755htb7VNPPfXtt9/Gr3366afv3btnq3V+I6c6rv7+/pWV FVttR3y08RnEaSrn07NnuU/t/v3779y5Y6vtyIEDB5aXl221qV53z3JFXV1O2vg44zSv65/85Cff ffedrdZpKld7hwr8tVFutNvtw4cP37hxY3BwMHUvIAPagAG0gabgzCPp8oxy9uzZd9555/jx4zMz M6l7ARnQBgygDTQFZx5JN2eUxcXFkZGR6j9ardb09PTo6GjqjkAAtAEDaANNwZnHoZszysTExIsv vvi73/3urbfeev/99+fn51N3BAKgDRhAG2gKzjwOXZtRrl27duLEic8+++zw4cNzc3OnT59++eWX T506lbovyBq0AQNoA03BmcekazPKyMjIuXPnjh8/PjQ0VBmwvLxchVZ+NAl2B23AANpAU3DmMenO jHLhwoUPP/yweuGr/9404ODBg1VQrT6cmppK3R1kCtqAAbSBpuDM49OFGWVpaamKqLOzs8PDw26L AVVQPXz48IPPA2wFbcAA2kBTcKYRXZhRamn0gQHu4fQKsBW0AQNoA03BmUZ0W0ZZWFgYHx+fn59/ 8F29rQa4Ld8FTNYi5AfagAG0gabgTFO6LaNcu3at3W4fO3bswWdqBty8eXNxcfH1119P0x9kCdqA AbSBpuBMU7oto2ynZgDA44A2YABtoCk4sztkFIAOoA0YQBtoCs7sDhkFoANoAwbQBpqCM7tDRgHo ANqAAbSBpuDM7pBRADqANmAAbaApOLM7ZBSADqANGEAbaArO7A4ZBaADaAMG0AaagjO7Q0YB6ADa gAG0gabgzO6QUQA6gDZgAG2gKTizO2QUgA6gDRhAG2gKzuwOGQWgA2gDBtAGmoIzu0NGAegA2oAB tIGm4MzukFEAOoA2YABtoCk4sztkFIAOoA0YQBtoCs7sDhkFoANoAwbQBpqCM7tDRgHoANqAAbSB puDM7pBRADqANmAAbaApOLM7ZBSADqANGEAbaArO7A4ZBaADaAMG0AaagjO7Q0YB6ADagAG0gabg zO50f0a5efPm8PBwq9VK3QgogTZgAG2gKTizO92fUQAAAEARMgoAAADkCBkFAAAAcoSMAgAAADlC RgEAAIAcIaMAAABAjnRjRrn2qz1j/77l43+d+/7fRlM1AxLgDBhAGzCANk3osoyy+J/jQ/9ydfvn kQB2AmfAANqAAbRpTFdllP+Kpw+/3v/4rMMA6AjOgAG0AQNoY6CLMsoPCZVACo8NzoABtAEDaGOi ezLKZkTl9YfHB2fAANqAAbSx0TUZZTOjHvuPz2b/+WDqXkADnAEDaAMG0MZI12QUQio0BWfAANqA AbQxQkaBYsEZMIA2YABtjHRNRtl8koYB8PjgDBhAGzCANka6JqMQU6ExOAMG0AYMoI2N7skoPyiw +88k/fgX/PGzS4AzYAJtwADamOiijPLjX+G3/W/I+b/3X+9rvxr/f//z/uv+4+cS9Qp5gDNgAG3A ANpY6KaMsvNfNLw9k/JX+8EmOAMG0AYMoE1zuiuj3Kf+DzZ1+A7gfVP+CQHgB3AGDKANGECbRnRh RtmNB3bwzT54THAGDKANGECbbRSWUf6L+zHVYQE8PjgDBtAGDKDNAwrNKHy7D5qDM2AAbcAA2vxA SRmliqb/67/Nbr7m/Ng0PA44AwbQBgygTSdKyigP/VA13+6DxwFnwADagAG06UBRGQUAAABkIKMA AABAjpBRAAAAIEf+P00hUQIKZW5kc3RyZWFtCmVuZG9iago5NyAwIG9iago8PAovRmlsdGVyWy9G bGF0ZURlY29kZV0KL0xlbmd0aCAxNjY3Cj4+CnN0cmVhbQp42r1YS3PbNhC+91ewN2rGQogngXhy SOu4cZtO0sRNMlP1wEi0xKlEuiRlx/31XWDBl0jJ7kzbiwgCC2D3291vlwoiEkXBOnCPH4Lvrp9d 8kATo1RwfRMoRmIlgzmLiTYyuL74LVSzOacxCz9sZkyH+yRfw4Rg4aeZluF+NqcRi8OLNF+v94Vd 4eGlXUmtnFv7hK/b7GDn79c/PrsU3d1UEy1YMOeMUO6uvszWBA4xccgJivdU5RGMaBA5yat8wVS0 T/NlincUN31d0tWXZDljJvwDV9/ezubwlpZJnRW535Hjjrf7+nZf49x9Vm/8bJmtMy/xYZPdeIGP 7vhlXZRWv+DVdfBnQElkDLeaRe04VoRpgJUJImSw3AXPrnY8uCiCX5wHVGDAGD70gCEC7LPWccIB BipM+P3Vx/m795dwuRbhRVbVAOo+qzZpaac4mg3PN79+njOpGqXsHWx8BwcMBVWIoN0Z8bDeWAQj EVbeShjezcCNaKWTySp8AqQq3EBEpCs7wcK6wA0JPvL0HgWL3B9qAS32/ti/0rI4w6G/lYdVXe6X 9b708s4eeII97dXWpigAPIiRGKIAw3YL65KGeVHjwO2E5xpUAu3trw5XOFcm+arY5WlVEZy4yvFZ b5xpkoUVmAuhcYbz9w4AO47AhOaualPY+Xucf7BgFHt8SbzErbs8XWbJFs9dOZ/NJ4zwfrQaKY7u UA0wMJGs0AtllZQPfqr0a+vszl6eWisUa/aIEGJ2YzfVKOa8o5zb4nBTVH53lmc16qcs/kntd9/N pAyT7b4Vq+o0WQ00x9BxUPMmdGCwA2STdXqGbzgrwmWS40TjLhiuuhBGoSZw3epNWexwlOAqOs4v 7nPnInIkyOOYxJEJbKYQIZBQ3qQ18oju5IB2lNCeR17jcu8YygnVxi8/H+1WRAMd4eoHXKW0W4Yc 5n51wQQfXw4JCDyLEj+P91NBdLP87Xi3IFFLge/HqlNI82b5C0bibC6ojypBwTeJBd5ONXDivMs3 Ow2A48x2CjoJ5mvhb7icUkA/gp08jh1gE2v27xufuICBMqOI0GqQg018CcZaQM7w9R5yM/VDzwaC 0XCb7bIpYKC8Cjr0KxvoDmXBL7+YMB1UaoG7GW2H3S0w0ehyu9pcfT6xV7Am2un45v7mNS4bcJSJ RbfKiaKIF2dj0xikE6DaCVnasbB1TmC22m4f7IjDGfMvWU1w+nrj18s0qSAYnaeYdTVjA08h5+iG czQ6oinn8O5pGkbtvZxDyf96u02y3BUsuwvYriRj/1nyEPEwNtkgNCPZeMCmyOgASHxqTgVnFLX+ LbbbtpDwuDOpSnZ+tEoXTMaWp4u8wqmsBUcTxuJhPUx9KnNmWydqawpUPweunQIQXDlMy2wHRcNX CFslb/C5zO4WvrpDmXAHqV6dgK1tcVjM5rel39Zjc2z2QNAS+kTNOMbxvMfxPVIa4cskUS1xTjIP pV32g262ZnI2KqNw4Ut8uMpv1aj83a1bqudHSgylkrAIgl1AvES+aX311Rf9HrhOvV6TJ4VtcVG7 V5/f+TSMukRjNuIp5FustZMCj3gp1klBGCoquvpCxwcpFxwocevaN+QTcAbQL1DUHCLdt4CvockU 4fnLvrV6ylrDobQyj+3oStBKGx2AgyCDevHfpxmgBw3BOu+EFtDdzSTg7uwAAOMJ4mMR4CZPMh87 yXzxaeZjfeY7BYGMNJHG9KNvAAHcBY6SrrN4AgR6AoJxTSFUypZS5nFHPIeRE3PH0WpQWXtxA0bE fFhY+0fExAjW566TSIBPpBRO+KcJJCSJjfoPkBDHiysnsuXeF5N9haTqZHGl/1OIHSmuqldcG+yH 7UEDPnwrywjD8O3oQPAjfHrOKbSYom/OUGFlgk5iEY61Bu/EsiOZccm3X5ON1YvZ+AAFfm3Mdp4d szlp43HM5UBQjTePqSceU08fqKen959P+azrl54AMZ2COH4Cwv/YhEOE6VMRHn/jGBIZ+gjE4wjQ 0xFwDlVEqYYLhnmpIjaw4iSxCBucCNpqrBMgL58cVC+nSE7ErNfKet9CWcY8dKhaPaBVk3G/1vXc D9slDzqJFjzWl6GUj8DrHcIIP0ifU62GhG8u21q6z5W03pfj5sj+q2Magls98h+QNBExDIv5p5nm 2Ciz9j8F3zb5T3fXPqmmfTq82EAcmgPMzSHkLlnkkWRxud4J2G+upvn65m+TIvL6CmVuZHN0cmVh bQplbmRvYmoKOTggMCBvYmoKPDwKL0YzIDE1IDAgUgovRjQgMTggMCBSCi9GNiAyNCAwIFIKL0Yy IDEyIDAgUgovRjggMjcgMCBSCi9GMTEgNDcgMCBSCi9GOSAzMCAwIFIKL0YxMCAzMyAwIFIKL0Yx MiA1NSAwIFIKL0YxMyA1OCAwIFIKPj4KZW5kb2JqCjk5IDAgb2JqCjw8Ci9JbTMgOTIgMCBSCj4+ CmVuZG9iago5MSAwIG9iago8PAovUHJvY1NldFsvUERGIC9UZXh0IC9JbWFnZUNdCi9Gb250IDk4 IDAgUgovWE9iamVjdCA5OSAwIFIKPj4KZW5kb2JqCjEwNCAwIG9iago8PAovVHlwZS9Gb250Ci9T dWJ0eXBlL1R5cGUxCi9OYW1lL0YxOQovRm9udERlc2NyaXB0b3IgMTAzIDAgUgovQmFzZUZvbnQv WEVPWkdRK0NNVFQ5Ci9GaXJzdENoYXIgMzMKL0xhc3RDaGFyIDE5NgovV2lkdGhzWzUyNSA1MjUg NTI1IDUyNSA1MjUgNTI1IDUyNSA1MjUgNTI1IDUyNSA1MjUgNTI1IDUyNSA1MjUgNTI1IDUyNSA1 MjUgNTI1IDUyNQo1MjUgNTI1IDUyNSA1MjUgNTI1IDUyNSA1MjUgNTI1IDUyNSA1MjUgNTI1IDUy NSA1MjUgNTI1IDUyNSA1MjUgNTI1IDUyNSA1MjUgNTI1IDUyNQo1MjUgNTI1IDUyNSA1MjUgNTI1 IDUyNSA1MjUgNTI1IDUyNSA1MjUgNTI1IDUyNSA1MjUgNTI1IDUyNSA1MjUgNTI1IDUyNSA1MjUg NTI1IDUyNQo1MjUgNTI1IDUyNSA1MjUgNTI1IDUyNSA1MjUgNTI1IDUyNSA1MjUgNTI1IDUyNSA1 MjUgNTI1IDUyNSA1MjUgNTI1IDUyNSA1MjUgNTI1IDUyNQo1MjUgNTI1IDUyNSA1MjUgNTI1IDUy NSA1MjUgNTI1IDUyNSA1MjUgNTI1IDUyNSA1MjUgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTI1IDUyNSA1MjUgNTI1IDUy NSA1MjUgNTI1IDUyNSA1MjUgNTI1IDAgMCA1MjUKNTI1IDUyNSA1MjUgNTI1IDUyNSA1MjUgNTI1 IDUyNSA1MjUgNTI1IDUyNSA1MjUgNTI1IDUyNSA1MjUgNTI1IDUyNSA1MjUgNTI1IDUyNSA1MjUK NTI1IDUyNV0KPj4KZW5kb2JqCjEwNyAwIG9iago8PAovVHlwZS9Gb250Ci9TdWJ0eXBlL1R5cGUx Ci9OYW1lL0YyMAovRm9udERlc2NyaXB0b3IgMTA2IDAgUgovQmFzZUZvbnQvWkZDWURSK0NNU1k5 Ci9GaXJzdENoYXIgMzMKL0xhc3RDaGFyIDE5NgovV2lkdGhzWzEwMjggNTE0IDUxNCAxMDI4IDEw MjggMTAyOCA3OTkgMTAyOCAxMDI4IDYyOCA2MjggMTAyOCAxMDI4IDEwMjggNzk5IDI3OQoxMDI4 IDY4NSA2ODUgOTE0IDkxNCAwIDAgNTcxIDU3MSA2ODUgNTE0IDc0MiA3NDIgNzk5IDc5OSA2Mjgg ODIxIDY3NCA1NDMgNzk0IDU0Mgo3MzYgNjExIDg3MSA1NjMgNjk3IDc4MiA3MDggMTIyOSA4NDIg ODE2IDcxNyA4MzkgODc0IDYyMiA1NjMgNjQyIDYzMiAxMDE3IDczMiA2ODUKNzQyIDY4NSA2ODUg Njg1IDY4NSA2ODUgNjI4IDYyOCA0NTcgNDU3IDQ1NyA0NTcgNTE0IDUxNCA0MDAgNDAwIDI4NSA1 MTQgNTE0IDYyOCA1MTQKMjg1IDg1NiA3NzEgODU2IDQyOCA2ODUgNjg1IDc5OSA3OTkgNDU3IDQ1 NyA0NTcgNjI4IDc5OSA3OTkgNzk5IDc5OSAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA3OTkgMjg1IDc5OSA1MTQgNzk5IDUx NCA3OTkgNzk5Cjc5OSA3OTkgMCAwIDc5OSA3OTkgNzk5IDEwMjggNTE0IDUxNCA3OTkgNzk5IDc5 OSA3OTkgNzk5IDc5OSA3OTkgNzk5IDc5OSA3OTkgNzk5Cjc5OSAxMDI4IDEwMjggNzk5IDc5OSAx MDI4IDc5OV0KPj4KZW5kb2JqCjExMCAwIG9iago8PAovVHlwZS9Gb250Ci9TdWJ0eXBlL1R5cGUx Ci9OYW1lL0YyMQovRm9udERlc2NyaXB0b3IgMTA5IDAgUgovQmFzZUZvbnQvREhYTlNZK0NNTUk5 Ci9GaXJzdENoYXIgMzMKL0xhc3RDaGFyIDE5NgovV2lkdGhzWzYzOSA0NzcgNjA5IDg1MyA1Mjkg Mzc0IDY3MSAxMDI4IDEwMjggMTAyOCAxMDI4IDI4NSAyODUgNTE0IDUxNCA1MTQgNTE0IDUxNAo1 MTQgNTE0IDUxNCA1MTQgNTE0IDUxNCA1MTQgMjg1IDI4NSA3OTkgNTE0IDc5OSA1MTQgNTQ0IDc3 MSA3NzggNzM0IDg0OCA3NTYgNjU2IDgwNQo4NTAgNDQ5IDU2NiA4NzAgNjk5IDk5MyA4MjIgNzgy IDY1NiA4MTEgNzc4IDYyOCA2MDAgNjk5IDU5OSA5NzEgODQ5IDU5NyA2OTkgNDAwIDQwMAo0MDAg MTAyOCAxMDI4IDQyNCA1NDQgNDQwIDQ0NSA1MzMgNDc4IDQ5OSA0OTAgNTkyIDM1MiA0MjAgNTM1 IDMwNyA5MDUgNjIwIDQ5OCA1MTYKNDU5IDQ2NCA0NzkgMzcxIDU5MSA0OTkgNzM3IDU4MyA1MDYg NDc4IDMzNCAzOTIgNjUzIDUxNCAyODUgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNjI4IDg1NiA3ODIgNzE0IDc2MSA4NTAg Nzk5IDYwMCA2ODUgNjMxCjAgMCA3OTIgNjU5IDU3OSA1MzEgNDU2IDQxNiA0NTEgNTEzIDQ4MSAz NjQgNTkyIDYwMCA2MTkgNTA3IDQ1MSA1ODggNTI5IDU4OCA0NTIgNTU2CjYxMiA2NDEgNjcxIDI4 NV0KPj4KZW5kb2JqCjExMSAwIG9iago8PAovRmlsdGVyWy9GbGF0ZURlY29kZV0KL0xlbmd0aCAz NjI5Cj4+CnN0cmVhbQp42s1cWXMbNxJ+31/BPIWs8iC4D6dSu4kSJ9nKblJr7SZVSR5oiRLpSKRL pKz432/jmAFAAEPqsB0/mORMT3+NvtBoYDTBCOPJ5cR9fDv56vSzF2yikZFycnoxIdogKvWkowpp IyanX/86Pbl592Y3X8+v3m1X21nHOJ1uLuwnm+6WC3/hu/l26S+9mGkxvV2f7Vabtb/3w39/6aiQ 8EMQMVWz30//Ofnm1CHTiQFk5pCJQBTLSSc4opw45C/P386omi5utvObd/a5z17o+ARXSJEJ9pT+ LqETiYzi9rZCXNGJQET5YfzoSUykkEiwnsFv05IDQ4Tw/j7ltGBAEQO1BYKZG1hHKMKETDrQH6Pu DklHrCsjlhIRIx3ttsDgSCrginiwBg5ykshIIcrkJJL8xjDzVKl+KVIsyIorKEZTGLAknoWSusaB 25FFqmeFTQAEvAcfORZSH4t6/FhIMhZBKjhuMDQdzOvXBY4ABxEBp8LDA+Fjnj4spY2QA5GhNCKC ZO6aqJ4hrXpvXRZwAsFn6UZpOCEuTaL5z2cdkbLCimBEbIoo7JgzU0fzynyCPo5XJhd7ykHyp2Qm nlBj8gk1pgov3h+kz3N5IEgkOe3zoA1YmD5Un3ATXhQjw/Rexm248NGZkDbHHVLySEQZUABW94io dHpwIWUDWDZCHENqR1jr0YCjbpoqzZQiBTsdjdWIRwvFjoFSSV46AEUfCaWPh2IjGnxqLP4BscSH s5b8cNZqZZKI9dfJJOTxmYRgqPskzWtJUheodC6NtOgLyXll7qZSenn5wcmbBztWqhVO9VESvKoo jEIVfUgC9VgB+mrprCIAs9XaB1PBecUIRNdUQNsSHOXg+1Kkte1YGcdbqwFA0CyVgopyPvBfHj21 mXh7NDgIh0WR+jDBQT56cJCPHRzkowcH+SsEB3nPwSGOrsVGg4MKeNDPHN9fOGqG3VwCcYOMCCis uoYlSqYNio5SWjEegQCDVfVYCB2orPdbDF/4iRnLUipKkTTsvlKNhtWYVOp9SlWPNfIwqehjpRqP P1lINep1QiDts/t8HRiSBFAoxIRTP+trICpFrV+jlOt2GfWkuSvF6GD0EtvQxpBEyBE4oxrKccoS H2iI6Ycsy+aTXTNaF4A5jatg4YIXUAmYPROiqD+dqo8xnqjvotJFMv2oVOVxNbRARx8t1dURA1Uw yZLMKAv5aPRc17b9BTIYKvZ0nZreIMFVpuvYiN1nR+vazr2VMXbQW+9fbBTeSuU9vLWe+2StU5oP WQrnrTRT4GjUG1j6CO/cN4vd7Y1t0TMG7N3H4mq78N/iTd5nOJkMUcAqjhM/1DAN/nSzeQP0ZLrZ rkLvX/MpRalIRKYZTSNhzKSjWMNovTpP3X6CUNOz1dvuzc1FNz9/O1/v5pfusvb7DvCZbCnoqduU gGfmO//7ajETeDrf7srQNQYRQdsdXYXI4LTgaGUVk5YGtCwNYlNX7vHIth0o7ScY3hfwMnUNp9vI xesQdEuQgtkCcjdikgWtzwSo3P130dS1YU4umFuAKfOu/+Ort6vN7fbq3TOvvbvlYl1GuJ12eO6m 2UyHea+NfpYrxwPictMPOKBdbG68seb+48aZbH2+uba/5fQi7iDB3RflRkMnOZSCNjUoiDKvi4p8 qq9ofw1yqfpexTe/hKcJTrZ3IJ3AtANAoZYDr6w2RmS6TURKRqnF39iBY58vQXqJNHfzpwrG/m4G 2W76eb+hJYJPWSD7DUaMkQm7RaV/gjY0tg0hQ3lqltoOSGqW19WdHHUvy/9uP7X/qWGdV4sPSIlO o3Zj7agA0Y2FRJfwmBUc7IJSJDCstRLoMlFoBSxu8VRH5OeLDzKgVG+0UXUmXIJZKjIHy99DaI5b qUWB52KbxQWkc+FTy8+1VEJhKpei6VA26YnoUJzowWfTVALSxUTCmZiuduFzaz+l35G2F878JBB+ 2YnDfoaJA3nin8PdWyArIknCGo4f12H8qlCecsq4Z7/KtV5LXrZA0+K+63vH7Pnz5+6bqrCF7KZI zrZWpti56Fgh89W3qBqZ1HoA2exHST9DDyuThAeUJLA65nnhesA+JxX7EEoeZJ+T2tAF1/dsAO2Z 56RmHkijKVf5SBFNykwd36DJSxPTK3W3geCRbHq+WG92NpAkD9EHF1/d/gZhtrjZls0VmDpoHjdZ hMOKWIl9++us88+xyA2bJSSoWPqZCXlhXm68dKu1/x2k5JCGIEcsbPF0uVqvV+tLm1QknW5X6zN/ qyg7qF2yuzZT9L5txdHJMHl+US7mCaJc7emApE/jYQ3yupyZ03MFBxRgqy2jp3er3dJ/8wd24MvZ crPyY7TVs1G+tDYmUkDp7Q/e9EzC9eX87cKTzv2F85W3teNmFUemC8/TKtxSbNZX5fEdqmGFOPQ0 RlOoyBJKWStHmmehVOZQvqi8g3a3XJ0tveCrbaUHDfPTIM34eu0esmaLMHfIKusLMcEa0xwd0JCX +d+bO3BOjGF5s/t067/ufNl89kdiXHv9jbsO6zEwxfxyHgppYOKmQfvgMpiwartKm4q6xcgxzeG6 cuR9DRlG/f0uGJQRWLnoYFBf/d6trmYdCAz/M0ih+4O2I4RkaNOUve2HDF9gwOpmu/M/Nre7N7fh +6t3uzLgiYTF1lACHr0hkxVmHMskr1byAawgdOzjClWqxyBN+spnvvXybpebu7X/ugqfpzMlp/NX V2HsxIau1JCNwxDvgg7OwSEIJtNPg3rtwhizPF7+WFuPs4s1rzpYh72dX93GlXixWDSIMzE6DAl5 kQx+7W7zePjQroakbYdBrYiFX3Kdzmwq8iMyECzhqeTIIqwpKO1hvw7+DAUohYBYza/8GcSf7M+5 y4Lwy68+4cvJ9//rfvrPC39y0Z021MlpQ1vvYgSRNbmDxZcBS9tluQQ8QyfXE0aJ634Ml64mLyv0 CkwvgDzjwA1x5K6cNsn5S6hNNbbn0qSdQ/wi/2Zz6yfCTCCt4JtJAYYrewAURwAKdYUBk2QAIaKh Ihro4KYhaUin2FCYQAnGE+x4ZQzbUCi77od9so8dtd5jZ3bosat2kDm5v1Kn1hTsoDOzAbmGIqpq NlgsUKIsEUwjNG/BlxaLzFMjNplr0K3zici8g3+Q/KhofSNtmw3omRlb6JZIcjmG3rTQgJTpvEeq KJ3BQFVGHy7V6Q0sYWUeW0BvO53jRjIYFgcq354rrRS5R8ONcB+slHI/ZKaubaYBPrFcGz6aKYE/ 1k4DVKb3HqqqdyZ5Rh8uVemhXgfPYZmdgF4E+jIHUoShDIDnKKLMz0avrubrP7q2tRKM1IBNjN5a KUZHHmytCJ8ZsAU/WCuDP85aESrTvhjTvqLZhNVfqtPbnmSW+Sy5oeSAsQhDwtDEWLRtrAEiNV8T YrBVAgEZ7sG26tEz67XQo6ky9ONM1SNlmu+RKpqHtbEyGX24VKen2jX9rnMWtm1Qz38ECdur47YG CGU2Qm0rRfbRcG32UIQhKckh9lHpA/vEMiPsje/XH2AfNTewz5TZs68qk+/Rh0t1ertgNNnkY+kl a0wP8TmJWDhzHJIab5sggqRWaYIMkZKAHCoVyEikDPCZ1VrwMVTa8E1zDVCZ+nuoqvqVyeag/lKd XmDwGpqZC+iNYQfMxRV4dTYHiba5IkhqwSbIYK4E5BGVXYTPLNiCj+ZqwZO2uQaoTP09VEX9xL27 ktKHS3V6SREjmbWAnAlywFoCVo40nYSIbFtrwIj2G8GIRBEjq+/KhQxTbrd9WBH3BxxStrD279uh ve75gfmrlzsxfFvuhCjKXZWWcNcUPygtScVtOkgvZGZvNmZvOzdd5xzspTq9YuCy+dQH9ArrAw6i gJXyByB872espowgqc80QSCcqeE5SFZTHvYQBbTK9qgUq2ifu/3/oP2SGdzGauAl7aEOy0rSCitY mQ0d6nFvG5SQOWBLCZZIOPOlSmi6G60MXeKKvFBb8AeOvO6fw7Ayh+uHVXU4DWDXOQt7qU6vBUQb zxxUcYTlofJAE3euIXHQkTo6gkSfHQEBB+Xa5CCxkP47/Eu+FUpW9qBDVHLFqxhwZdGp2j41yJ24 WVtuS+S2KlO5qyLu+dRwBCxhZqAE7F2lH2fdQwYhE4tHIasWp3v04dIwqMrGuaCQAsJB+h9c/31X aUIjiSvzCM52+KR73Vly3zh9WTmZRl17vYtEbuNfEjL9pMSEBb2pzAY0PSHASXkQOn8DVmbv2IYz CZXtWgf3ALSkFd9hhJk89p277H2nOiLMdprpw5jq4Lt37xnz2JfwRiDVPSFZ/ZWpyttdeP8USwQ6 re0QuJOP6TvmHbW7j373jhozvfbn+9Zbf6e9hZVtsUC4SVk6WLbHwvRw8Hs5X18uAsJuU/vbA0by B/hrCij8HmWkmV/sYBx+wwtW08KdWI47MqtdOKq3WIejjrul3/S6vVz6Wy/9h9vY3vz5bNi/CQfp Ljz5tb/+r9WfTl2bq9vrtb9kt89Aje5UYb9vKMK+kfB7v+VZPM2gsLMdL44039v9yTbFDTX5pnjl xDQFH8Ms6aBjd8ZPhCbZV/01+9KEyi/BolP5rcF/VMAVUfa0rCEhN9iz9hpP3TuG9pMMnz1q3Goc bpYPpcQiJy4fqhCX8P1D5YlfezbGTLh/FyB2r3MNnZQaOik19GXlQKB9p9L+EQitxYGj1uRJzaRH zPRJ7VwapuNvYHTWIVV2AhvXdN+6lg9YIU3lk2o9PxUAVUKi9L9EZNRfNVLF30LRjZOSj5jA1fgE bl8FsI2HzoDe2DFo8jFoVnHsicFMy2vTodHxt74+minK92W47fWZpwgMKMP/9n/IHxtlCmVuZHN0 cmVhbQplbmRvYmoKMTEyIDAgb2JqCjw8Ci9GMyAxNSAwIFIKL0YyIDEyIDAgUgovRjggMjcgMCBS Ci9GMTIgNTUgMCBSCi9GOSAzMCAwIFIKL0YxMSA0NyAwIFIKL0YxOCA3NyAwIFIKL0Y2IDI0IDAg UgovRjE2IDY3IDAgUgovRjE3IDc0IDAgUgovRjEwIDMzIDAgUgovRjE1IDY0IDAgUgovRjQgMTgg MCBSCi9GMTkgMTA0IDAgUgovRjIwIDEwNyAwIFIKL0YyMSAxMTAgMCBSCj4+CmVuZG9iagoxMDEg MCBvYmoKPDwKL1Byb2NTZXRbL1BERiAvVGV4dCAvSW1hZ2VDXQovRm9udCAxMTIgMCBSCj4+CmVu ZG9iagoxMTUgMCBvYmoKPDwKL0ZpbHRlclsvRmxhdGVEZWNvZGVdCi9MZW5ndGggMjUzMwo+Pgpz dHJlYW0KeNrtWllz47gRfs+vUJ5CVYlY3Ee2UpWZ2Z0ctZVs1Tg1m9rZB0qibca06IiUvf73aRw8 JFCUHHu8s6m8SCTQQDe6vz4AYoYRxrOrmfv70+ztxVfv2UwjI+Xs4nImKVJSzFKqkDZidvHNj4me p4womny4nlOd7LLNFTRwmnyca5Hs5inBVCXf5Jurq11le1jy3vbkls71ffSvZXEw8qeLv86+vXAS EDkzIAKzIiiFFDazVDCkjHYifICJqaFJc53bB5asi09UyHw7FxhmXs0FTXJPUmw8RSClCRCqbd34 1mrX3O3C8/KxCSSXVTlPBUnK6qHeG82Suzm0Z02Tbzeetrq0cn/1XvcCUykQJmyGnayWnycZLkoi IkmgQH6mj9f5JpqLcUS6qZa+mw50gzBve/8A0yiVkJgZEYiD5jzZwunZ6h0pRWcpIcgIb1m3SsZk kq3v822dbR/tq0pus5u89o/NQ+VJ/r3Lt0Xbmm3W/mFlDZCVq12ZgTIPpaWYIYLbZX9KgqRksFyk lQj9PFKGRlq0vZnvNaBJo7jtFYgCZlMCa/XLwdEEHHE16wm+jgUACqrPEmAZCcARVacFkOa5EsjQ uxqRgMFUL6ACdZYA6xEbED2mAnpcBZ/mMWAtDHiHV4e3gE3VuXrqcUyNhBW1OJZuiIsAJHHoFCqp s6aoLx8jSTRFAjMYCchh3IvLYn0QioiSnTdzCn5G6YhqCIjN1CQ+1bRuFAgiB7oJLo1lLBWlSBr2 VKnGQStOS6U+p1TnA/kMqehzpXoqusdyVps2CYH4HVD5UDTXHpB3Lk9VS5dLlkVZNI++A5IJ/OuE oFPJkFCDhCFu4u8c2Jt4NQoRI+M0hPsVgdNwymBhEqKCy6yx9lLq1pv2RKBCMpeEJL+NeYLlDIl5 0p6nT30MSXLMtAIJCR7dkwTbthnjkN9/w25g1hQjQWGBEmGtJwM3aEKxEDdTIuURlgQm1OY0Tznk SX4BnnQ8PTyFpX4iSzaWEIYsu3wwgKnPBz2jizhlGKQ5GWLG1iQRWgxivIeLpDEroMDy8zlEx5IO gx3m/PM4xBPYDayGT/rCKEbGmGkgI+czI6/JjL4ms8+Fe+mLzp4G+VTyMfep5Dq7zxdh2GClKYHq Bytbj4CMbJjOQGzIHCJURG/bNgFC6f0miZjyue2PsZdopAisD6oyos+oJSfreT4Ex54rQsaW1K4C Q7AkZ/A5o2w/woeIwOZlSvNjq8H8CasZr1HEmNb2YC7IjAvEWE9xYPZ3sdnfxWZ/E4HaFhTAH4Cr 20gVRSjICaQvS6QYKe0UJd2uNhI/TEABuJi9DHDpBG6xLRc1tnsD/0+6/5Zrv4XuOuNBE8TxoCGx bLcmh+zbQbGBNaJ0xn01+yIm3tsQYWQYGdjYldQjKDOavKiV9ISVXrz4G0ACoisG6tQAtunBUgbW jIQEL1QuhPVWPJWS5RNyyVDZNliKGQeVYf0SFp/a1FAIUxjTcBI3klwCV0IPXHwIIvBxCNsKBHlu OOWvFE7F8XDKHRR5t14Zx0XsTr5SYk2tTkS2AdGR+MggdPfK60IBG4MlOx4nYGOswDOgLDZUHAi/ n8uZNHvCj7s8hATAxaj4el98PhD/Wa4rp2vVlMO+YOi5L1ITH3VAUCgz+hVhwA9hoMwEDGznM2Gg nweDKfFpkPBoquw6nyD+wMiBIdS9kvfbtkNDQ0FN23gwElRgK+ZCCoim2QkdsHEd7IfBfVf+1RXJ +wkfFPvZA+FEJLkc2Tmb9sBejQxXqq0zJ4fykdRukFRkD6OTU8hnc49rq9eI278MWOUZYBXPBqsY Aetk4aNAQ+bJh7kL/95UjvDk0S7VChHmk8jfqgc/+CFs5/0Htk34sJG77532xX4gyZpFpCjDoK6D mE05uJ1X+vdj+632i9OPQVNqEF5h8e1J/bc/fB+fUsDcGObmMIvHxaq4Hz0ttNkVH0Te4UTD0Atq TRn2juEOKdzxnnKR3vb/eZ4SkXzdbk9EcAl/AmZAEKgOjJFD89O9o3GNFeDeUD728ZQcfDxt1/+v +GMvaEc/6fvsT/Zf+1cd6vQJ0DEGG/Vw6PBwXawC7Irbu7LI60VsL7xn7TdzQM36fuTo34C21a/d apOHC1820tVxndH/FaTHn+Kw+954qJthxELq//b7IuyHRyLVwXUNjQSPFEVHjTm667KK8DdcJuvx 7jrCyQ+uTDMkQj1WVyPRkXN3QDn86D8dIvVZcOHPgctBiDxUIoO1GQb2M1SfE/Zus5/HRNBC2z0s p8cP9igQzXqSyxH1OZPhL1JvUOf2bjZEKUYYVtTr7yp8PaMKxysk2u3k8Stmzy8vklieZNqx7cNL e/ZBjc+thftJfj90fhoXzpwq2DJ4Vf1zru3tPtCnFsnKFcxaQsFsi2WtXLHsm4pL/1/mmytX0sNz Fdr8nSMgv83rOrvKw4i6HVHXLV3LgFE/YFk0C9/yMKfKleggxybP14HDpnwMVgZVcb63j6w2lh7L ZFvt3MU6eFzaQ7wkv6y2rk8F2WxPmW1ufJujrxe+va4OCNuLU/lmFeawdyNtT0dSZvZipO2CBfim kfuNDBPYurawfjv2DagDz0NRln6iTdWEm4c2zLgQ3B+Lb/NVDg4UVMVocrlz41h7tXNXF9UGnQKA tHfXPLj/svETVdt1vvWPTeX/7Xnjz6Hp2lkT2Nxtq2WZ3y58e2c1RpJVtSvXnihbr8M42/9g779W nujWGwZoWnsAlbdHK4f/z0oYJmFzDGMf66MY2MHeLuUKd5yU5cSlCZy4IskdiOPu0Fq6DqK2Z1lW Di8rO+6mRp7EqsT+V2DvrSf0E2/XC99jncExBYIwVbbtBZHdkjtB4pO6ftHsALWsvW+78C+t8rm9 UJt5WQfq79VuoeMegrg3wRob+/roh1hpUAhEs1YctxliCvZP7YEFSEp58q4qy8IiCsYqAVEeoq4T ASx5Y2VSPGk7v/vHDykA8Aj02roDag6Ehefy5u4OtOaEa8DNNbd3GDnHdir7QJLrrPYPHvL2nq3t v/JW879rT7HqRbWv27wu6iYDF0a+4e/Om+2T82L7sO/otsVNrOyFyNhehRfURQuW3BbrdemiAQd8 bRv/5AIi/IdAwZPlLty3jgoRaks+Grz/3UiZqRkb3OyEuYrmd3Vgszvgt6q8cNuqXHj57A7YAvHa vy634ABhtAPQdVbVvsuvaELUlAAyhBF72ng78j0Yd0da9m6FIcmHwodQQ/pAYXBIM/ZOuI3urnuw AE/jNQg93TV0++LvT7cX2m1LiMTwtHQgbwKPIrA4uioKBbDudgGnDWBI6+1OkODSKTVgRy33r4fv Bz2a3BTB04PFrE9vi/siC6G7w27dRu7f/AcybRxECmVuZHN0cmVhbQplbmRvYmoKMTE2IDAgb2Jq Cjw8Ci9GMyAxNSAwIFIKL0YxNiA2NyAwIFIKL0Y4IDI3IDAgUgovRjIgMTIgMCBSCi9GMTEgNDcg MCBSCi9GOSAzMCAwIFIKL0YxMCAzMyAwIFIKL0YxMiA1NSAwIFIKL0YxOCA3NyAwIFIKL0YxNyA3 NCAwIFIKL0YxNSA2NCAwIFIKL0YxIDkgMCBSCj4+CmVuZG9iagoxMTQgMCBvYmoKPDwKL1Byb2NT ZXRbL1BERiAvVGV4dCAvSW1hZ2VDXQovRm9udCAxMTYgMCBSCj4+CmVuZG9iagoxMTkgMCBvYmoK PDwKL0ZpbHRlclsvRmxhdGVEZWNvZGVdCi9MZW5ndGggMzA0MAo+PgpzdHJlYW0KeNrFm91v47gR wN/7V/jRBmKe+CWSKPpwu9dtryjQopuiBbp90CZKYqxjBbZ8wd5f3yGHn5ZoO9fbNi+mRiPOcPjj cGQzi4Y0zeJx4T7+sHh3+90HvtDEtO3i9mFBtSGs1Ys1U0Qbubj94V/L9/uvL2O367ZfD5vDas0F Ww4P9pMvx6ceBX/sDk8o+rDScnnc3Y2bYYf3/vz3f66ZbOFCUrk0q3/f/um7DyLZXOuGCC7BJiO0 Vc7m7croZfd5a7s3fMkIPpV5KhrCmFw0Tv2HzSew0O/73Yrp5bjptmj6r/ayG5/w6mHYY+Nv/f3x rr9Hh99tu90XLx+OOy99P2y3m4MdAxhe/P4W4sWNXrwuKBhWEiLUUnBg8bzgvCHSRMF28XGqqxjh yoBy/rRAZTsD1GRTICD0IFi3hjSGuvHtnWOnnihNBFV570FS9s6arPeoknoXGFxGk5omFG5icJ8n ho0gihWGg6RumHEOfb7J8LtTw0wrwlQezyipG+YNzAsX1xhm3vD7U8NxjqPhfNZFfdYl+PZcPG4l s9qaE8XbnBHQVkrNQyIVDsquHaGd100VkNR1hkzoejKrSTub56ojpiVM88KRNfyt1pLJeqs2sdF2 PtU121ZHSXnOdm0eo518aiYRyabGQIJ6Lp63klltI4Eznk+kFoTCZJ2dSEOJblo3BlqdyNR1nNqy 65xoCk62VBZd2zRZXc6p94jCGcdBmzWl4+vpsoKOGuWXVTBediSJodxrrGd6oOADY6kLNddF29LY hZt/cS1xcdCJwXpI01NFSK9z6QKS0ZEEWXJkDjJWanvJrDZtWiIkzZkEdWHYeSZpAzm75W4QrApl 1nnGad75KZVK0LLzEMNZLLP+M1Kr/afHTvqHKaggSCmkZZEYRH5mUNREM/MGFN9EYhpnDmdtkmLy y8d5ZfZLlnJ6gqVZetoi/XnJvDaF+qXROWtWXQtTKXfAfcrsc4JI5obx2ZZk63oazEzkEAYTU4KS fg5V1aX0XHTpcmq7HrBAxX8P2Jv21hSFArlaFBJgWRSu5CtaKoiZzE9CRsPbiCr0vWhenxlAvqiV rD5r1AXEmCRa6YyxM1kt2UjYJRtTxpJ+wueMT+m55NMcEgZsiysps6UYyzad+b2UnuWLwshakzrJ c1iVrDj2DLb62BNZxdivQyuaKlBh51DhJ8nLi+b1oSFZUb1ZfdmKC2hxu2fKDC1eRyvZyGkLNqZo Jf2ctqpPUSnzaX1dabWWSp2ji56l663b41VZKw6+wK02+MRWOfir2IqmClYm85KzosrvAIJoXl9C 1VhujNAwEMJ5tKKShs5xgx+O48txPLc1Rhs5bcHGFK2onsNWdSkpJZfWsywwTiS8YDW/sPySv1r5 dQmvEIACuFoAEl2nAbiCrmCpgGUyMwkWRk62UJTMa7ccaC/ZAnWmzAW2pCH+az6P1pkdMdlItCUb U7aSfsLtjE9JKfqU7T8ziEHaF+INiPHTsmkeMf62+uvS3hijkDFXj0IibBqFS4BFSwUyk/nJmRG8 rLq8aF5fQR1oZMEY6LewzM8zpijhjc4hO7M3JiM5d8HIFLKkn3NXdSo9l5zKq5wpEpzBPNA3VGD0 YgXGLldgOq/AqmzFwRe41Qaf2JoZ/CW4oqkClsm85LAoIwp9L5rX1xLCXNZdoG+MuACXZrAgiwwm 6nAlIzlvxtQKr6Sf81Z1Kj2XnCpK6Bm6FLxI6/91CXbykjAPVxx8wVtt8AmumcFfgiuaKmAxdVha Aqmt0PeieX2jCC++/bLqXF4qvGA+G8ZytmSdrWgj0ZZsTNGK6gmaMy6lx5JL05ezk+8nFGkU/8Ul 2K/0DVgVrxCADLh6ABJdMwG4RFewVMAymZkcFtkUv/EE0aw+azSMWBV0gb5qLpRerJGEF7tiW4Ur s5HzpppK6ZXp58BVfUrPRZ/Wc1+kT4GAolbp//OXYDXEUhQK6mpRiIzNROECYslSwYw6x4wu9YNo Xp81QH1RerHGkKa9UHox2DEUVzlkqg5ZMpK4S0amkCX9xM8Zp6JS5tQsZXOYtURo9U2LsHmE4hgz qupjTEozY5RnKgBzxpmESHQmo2ZmgnJqGCtqsCCa1+dQFmpWUAb6gvELlMGbWFO+Reo6ZclIDl4w MqUs6efg5U6VP/9IIuzPS7lT130XdeFlsG3mumCqyEPTXwhScmzpas1tadeyGWgZrP72DdC2Aphq m9oakEQKfkWVl8JbMF8LL9OaUCpOw1uLDTsfG/WtYsPrayiOt1gTE/zyNSF1UT0EUYhPu4A3dfsD 3MOiZUS1dgcBtCXHKgVcW9nfUEx27EiLeOxI83jsSM8cO3ITMDXAG9wkrYEfd6s1a/VyfLLHs2zr 0PvjV/bidcXUsrdttXzdbLdeudt+wVb3GT61Xbihmx4bn9FD23Tnjw4EL358iIp7r9qFxm7wvfS7 4fj4lHdkB9TYb+uh1G/TqSbrMrzwRC+hfdftsNF3h832qxcOu8O4P97Z/pWGyxAod/e5Pxy6x965 CHc/9r6r25Vm/hwZU+2SodQdBLN6OFaQ3GcHyFo8QJb7i5y/dOMTqUyMwt1+zQUk/hYn5tUFyMGq kyYsHCUmJyKyrgyhsaT6Hbr3aTnpBpDnZtKNWbTEQPcWFcKh+l9TIvwybSZ9CCLUIin8duIKKLDg ytzjJu6z3/DZTytYGzArT509fQiYDDsLhRWlabvr8d5mh3fwZCJzb9JqfxhR+tlS9nXsCV7+w9Lh 9OTyzt56Gmy8l8PBPxz6x/y5pg0kD3d2IUERTDd4KBI+vWlql+HgFjYIPaB4w8E+7P2tccBPXIdT YKiC/KSmv9oVyHAZmHp92uBYoFdqlu7IJth82ffru257d9x2Y+8tP+yH56k5Joky7ByhUIwFdwj2 9K6HNdVjlDjk6wZ//4xLHWNCxemMgeRxwHEf8BImEJx3MYGrz0dUn3oJSVgImR/YK9cjbN1h/7vB vkKK4ZQDS3ad/7RyAXeSQ/+Tu793Z0dB/TD2L96n4M3jQLBhUyCnMqRAK+pCw9MJd7mnhpvwm2ik xudW3nKfBa2PbeZjiz6q5CNIsqRnlV+6zf6ATTzaCirusC0TKEUh+IYfu77zgqIjHp4W7umZxAdT QHBIf9m5UbbL52HvW2EocNcN5QbFKdrydCQgGUI/W1gXKHI+3W92j75bv1TxplvWNCxrENixrO+K 3fI0WW/2l5K1gJ1fKnlyhPjOmziMzu2vh9wFGVxos8wC0tJdSAUTYCUnLNabU2BpA4k7FETdw9jv TyKVgiuX90cvRDIzp37u98M0ZMihgp1FsyJKw37zaBVF0ywPT5uHEZu4FO7GYW8NGuOTSuuSCly+ gBE7o5v7HgXHg32QWtLs85iAOgwl3LZu2tuDjfGh91Y2I8HGx+HGSx5QL8Ljuu7xZof3dv3rzHR7 5znnmfP2mhW+wyVuI6C3s4HiwoXsBkVYQtlWN46dG8UXvMbKKT3Gl9th9+gmiYuQ0L/4Y+pZRQhe 2pPqrS8FmS8FP6yMWO77fg2Q7a3fsBFdW/tJKO4bgcWlq8VkCphtY/lkG27UNr22uKUxeGfe7DZ4 Pt5e/LSSctltj/3NaTdN6IalKgzaeRUG+g/ZEPB2qsrsbVdnSfcvAGSmAHRlmo0llGk8HPeHS44f mJZ4+DcDLooyTYVz/jCn11RmUlC3Lbl/L8BSWeP2yExjt8dxtPGyA9V6+Wzbxzubsp5QE2tFUD10 z77V+Yf3obC3eqFstnIs7G0zRobgdSg9nA84mj0WH7Yrv2ChSBKixHx4dqHQxUbqmDW44rkJ4TJp ru0FzLVwc02wg+99jrEPWPuvdqwD3guVub3ZbX0HMxZjYsfVCk8+Qr66mZlq8GnnV1LUZrCLFNsw SAavNfrF6cfC4zbDeeYdDMgVWCDELx7OKDz2/m6HN7IZuQCOsu+ZCM7324PNFcwwl6vsZ1wz0A55 79Fd08AMC+mJmTI9OZ0B5R1q2vTmGi7xOwOb8QnfzkDLJysr9+970PLJql1+wS5dsqohNM1fvMxf EIrf/AfK2chbCmVuZHN0cmVhbQplbmRvYmoKMTIwIDAgb2JqCjw8Ci9GMyAxNSAwIFIKL0Y0IDE4 IDAgUgovRjE5IDEwNCAwIFIKL0YyMCAxMDcgMCBSCi9GMjEgMTEwIDAgUgovRjYgMjQgMCBSCi9G MiAxMiAwIFIKL0Y4IDI3IDAgUgovRjkgMzAgMCBSCj4+CmVuZG9iagoxMTggMCBvYmoKPDwKL1By b2NTZXRbL1BERiAvVGV4dCAvSW1hZ2VDXQovRm9udCAxMjAgMCBSCj4+CmVuZG9iagoxMjUgMCBv YmoKPDwKL1R5cGUvRm9udAovU3VidHlwZS9UeXBlMQovTmFtZS9GMjIKL0ZvbnREZXNjcmlwdG9y IDEyNCAwIFIKL0Jhc2VGb250L0NQR1RDSitDTU1JQjEwCi9GaXJzdENoYXIgMzMKL0xhc3RDaGFy IDE5NgovV2lkdGhzWzcxOCA1MjkgNjkyIDk3NSA2MTIgNDI0IDc0NyAxMTUwIDExNTAgMTE1MCAx MTUwIDMxOSAzMTkgNTc1IDU3NSA1NzUgNTc1IDU3NQo1NzUgNTc1IDU3NSA1NzUgNTc1IDU3NSA1 NzUgMzE5IDMxOSA4OTQgNTc1IDg5NCA1NzUgNjI4IDg2OSA4NjYgODE3IDkzOCA4MTAgNjg5IDg4 Nwo5ODIgNTExIDYzMSA5NzEgNzU2IDExNDIgOTUwIDgzNyA3MjMgODY5IDg3MiA2OTMgNjM3IDgw MCA2NzggMTA5MyA5NDcgNjc1IDc3MyA0NDcKNDQ3IDQ0NyAxMTUwIDExNTAgNDc0IDYzMyA1MjEg NTEzIDYxMCA1NTQgNTY4IDU0NSA2NjggNDA1IDQ3MSA2MDQgMzQ4IDEwMzIgNzEzIDU4NQo2MDEg NTQyIDUyOSA1MzEgNDE1IDY4MSA1NjcgODMxIDY1OSA1OTAgNTU1IDM5NCA0MzkgNzQwIDU3NSAz MTkgMCAwIDAgMCAwIDAgMCAwIDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgNjU3IDk1OCA4NjcgODA2IDg0MSA5ODIgODg1IDY3MSA3NjcKNzE0IDAgMCA4 NzkgNzYxIDY2MCA1OTAgNTIyIDQ4MyA1MDggNjAwIDU2MiA0MTIgNjY4IDY3MSA3MDggNTc3IDUw OCA2ODIgNjEyIDY4NiA1MjEKNjMxIDcxMiA3MTggNzU4IDMxOV0KPj4KZW5kb2JqCjEyOCAwIG9i ago8PAovVHlwZS9Gb250Ci9TdWJ0eXBlL1R5cGUxCi9OYW1lL0YyMwovRm9udERlc2NyaXB0b3Ig MTI3IDAgUgovQmFzZUZvbnQvRlhQT1BCK0NNQlg3Ci9GaXJzdENoYXIgMzMKL0xhc3RDaGFyIDE5 NgovV2lkdGhzWzM5NyA2NjggMTA3MyA2NDcgMTA3MyAxMDAyIDM2MyA1MDUgNTA1IDY0NyAxMDAy IDM2MyA0MzQgMzYzIDY0NyA2NDcgNjQ3IDY0Nwo2NDcgNjQ3IDY0NyA2NDcgNjQ3IDY0NyA2NDcg MzYzIDM2MyAzOTcgMTAwMiA2MTIgNjEyIDEwMDIgOTY4IDkxNCA5MzEgOTg1IDg0NCA4MDkKMTAx MiAxMDAyIDQ3OSA2NjUgMTAwMyA3NzMgMTIxNSAxMDAyIDk2OCA4NzkgOTY4IDk2MCA3MTggODk3 IDk4NSA5NjggMTMyMyA5NjggOTY4Cjc4OSAzNjQgNjY4IDM2NCA2NDcgMzYzIDM2MyA2MjkgNzE4 IDU3NiA3MTggNTkyIDM5OSA2NDcgNzE4IDM2MyAzOTkgNjgzIDM2MyAxMDczCjcxOCA2NDcgNzE4 IDY4MyA1MzUgNTEyIDUwNSA3MTggNjgzIDkzMSA2ODMgNjgzIDU3NiA2NDcgMTI5NCA2NDcgNjQ3 IDY0NyAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCA3NzMgMTA3MyAxMDAyIDg5NyA4NjAgMTAwMgo5MzEgMTAwMiA5MzEgMTAw MiAwIDAgOTMxIDc2MiA3MjYgNzI2IDEwODkgMTA4OSAzNjMgMzk5IDY0NyA2NDcgNjQ3IDY0NyA2 NDcgOTY4IDU3Ngo2NjkgOTMxIDEwMDIgNjQ3IDExNjMgMTMwNSAxMDAyIDM2MyA2NDddCj4+CmVu ZG9iagoxMjkgMCBvYmoKPDwKL0ZpbHRlclsvRmxhdGVEZWNvZGVdCi9MZW5ndGggMzM5OAo+Pgpz dHJlYW0KeNrtW91v47gRf+9f4b7JaMwTv8krCrS71xRbtIcDNsUV6PZBcZREXdtKbXlz+993+CGR NCXH2dVd+9AnU9ToN8OZ4XA4pBclKsvFw8L+/Gnx5uaba7pQSAuxuLlfCIKk4IsVkUhpvrj57h8F LpcrIrgq3j8uiSqO1e5huaKMFD8uFS+OyxUuiSy+q3cPD8fWvKHFtXlTGzr77kf3uGlOvvznzZ+/ uWaBucSICAzMCcJCWuY3S62K6nZTw4eaFhS5jyKJWYkI4YvSkn/XfCBc1Pt6Z0TtmmrjGP5gHqvu 0T3dt3vXADlZsa/r1fuu2nemDxdv282mOTTtznBa/PEGFEW1WjwvMHCSXC1WAsQki+2C0hJxPXRs Fu9zWkkQlRqI46+ZIzaqxzqMBDNQOnSshEalxnZA+/a4u8skkQoxLGP0vidFJ2WEPpAEdOa0SXAg UwjDS6fNbcZYMyRJwrjvmWZMKAXMVzF+c8qYKImIjPU59EwzpiXYhbJLGBPP+O0p48HGA+PY6mza 6hxk2yafm55RakWRpCL2EaCWUo47CZduUKpEjCkrdTnpIAE6cpkeOrNqoI7sHAsSqy18FQQxk88p OBaZI42pV/BqlRtAg2TMvwcEmSNgEFXoAQJAVpywocVNK8cFA4GQJ8CjXjUMPPazKQsYGsl5MvBE ktWkEw18Yr/IzBH5haY8pvY9o9Sag5PT2IsUQxg85awXaYxUKVycn/SiAD34VQqd+AUIKTBPoHu/ GI0lAX3wqDPoQG1QT9DlmNcJgYPLRNYZa015xiBc8JVp4cJXXy7clOsMggRnCIKMOQNJqX3PKDUu BWIcx74D5EyT876DSwjsgtpBkEnnicAjf4rBT71HMpyCj83dwVki/MijJoXXAhFFU/zVl/tH4B67 zBT3IXSc4T7lAIFTbNOe06hNRRI8fM84NYbUo1SxBxhyxfREpgLiY2K+Y4gTO4zbTbX7uJoOIhGL 2DV6FrldA31s6kmRBsMGkb7GrgP3xNRT3INhJ7lP2nXglFgq00swlYLMXSb0vmucnmhwtSS9MPSk nMovIFMhwnwHkVa65Q0hNG3XgB9MHfBzuwb6YOppeUz2qBl5UZ5gpgE/MuY0vkkSlZQv4gdlD/iJ /sk5/dOTmei7xumhwUmykBt6LiZW8oGImrDstmztsXs6ducmY2AS27Fnkhst0Md2nBRqmIyRUF8z Gwf2iZmn2IfZOM1+0rwDq8RcmWZic8l0O9h3jdNz8Lc00EJDwxp4fjYyBeD05dk4wMem7uFzuw7k saWnpAlz8bw0wUg9fGLJKfgwFc/DB0X38Inqs8EG1RN0EmhdzyDMAmOkwXGiQohJOEvmIjpfwlSH fcf1UpOkbCBZ8cO+brbVg6lTSF78YUlx0XXV2vx+dBTtzr37y9/+voryYZsBwR5Im3QgKsBgiBHc 6eD7tmvWFpkU3WPV9S3fdeiqzjePT8sVUcXd0NG6jnpfdY0TAPru3S8I4hrNwf/ulkQWn5b2g665 3dTIvXjnv3g27y0yLh6rQOzeVptNkMyMrjSh0SkURvFpyTnQHOuD00NjxZHF7dHVbFyWrIIqJOzf Sh3vzBNNATRX/fau2t0ZNOFRRfHkLSPNcE+RBeTfksTFhlNkBeHcIx8coFe3COqWxb+Oh8513jo1 37f7OiGXPha7TlvNOVjdrLAoEZbEq0hEo8DUfw2N4Wtor6vN+rgB5p7oft9uB/K+ddzvDsOnvq91 v17GUw473xiMi0mxNu1H+A5+2kN9NUJR7UZsPIgIRBQ4Vhbo47Mtv+3vDq7bCkR7GaDR7Bpfq6Ms +Il5JJ6YFQ9154jvzcw7+JkHz09+5h3QxJSSsBqAH62IgCDEmasrGtaMi+Lf4I9uajAuYSZcucZD 88kOdueoHqvDo2uBdMxKZwm5URIRoBn7YGQ1X9/V6+audu3u0TeicRmgxkMP7/t50PsHg1jLEu1a +FIW2+qjtwQrwR+P+9r1O6gy+Jxpm8ltfuufqnW3+ewenm0UsS0jvkey9q1c6RS5LjPzT8n29baN 577pm5zEFNJbIej0XCOwk6DRLLaDp7DkSimS0W+MAzAtXZxhWvXTyXYOzm1e2L3IlWs7pQDFoQZb 79Z1JiKWkLPrk0CjFwJpyaz/IEXpwlU1hnIbrBY4QJgGBO1A8+ucC2zW+OVM8Ncz+fbbb3MQDPtr WPrKeaQUv4QqZOY0GjGiYh6N94K7etU7UAmpgUqia1fvt83ORE9GwUeMR3927coufP7BBkRGtV0n za9fztIhmAMSStIx4HJsEI55kw2CImrys0CCHP83duYa/se9azztW1iLt+7BhSho+Dlsu4KgtrGv N369N09+anjNYAoJlyJpYDHDt0G6thGPyuJDkU9l2PQzdYHZRFSVXkHyBfN7JSDR0rafZsAcYRCI ICZdvvNbyLOEGGEBwcIcEAUeOPAgX8QD5ohtyRFuBCKwjrmJX2BE8jwPMs3jw7J35rtMHqIgCL/O cgkvBlxiV71yrJ4fa7v2QHPEXyDvVoL931/+x/0FlsVqc3DtIYKE/MfCE8iYGcFJ0HA5kcnAQmZj iCFt50zbI2RB/bnQSDCBrV7vG4/ZMDmSJvVBTLPYI1XikUIvAoXXWA6FIc0WKgbDY2Ayxwq2zlEJ QUonqGJOEeXYDEzAjPUIbC9+55eeJJ9BGPa7BJyhpNHUMqm6RNzXQ970fRzEkGmXQNR3/T4blQJP kwsCfoCdcasR6xEhzpvPZOLxcC4AwV8IImMQMgqiXgdC5wBhc4DwOUDEHNaRGchKQ6xhhqgE33XH 77cZEENE8vO+okCaSJgLMPAMGGQGDDoDBpsBg8+AIWbAGHMSCCQ29gUnWY8AUYxfdBLMImkuAMFz gJA5QOgcIGwOED4HiJgDZCKgEJr4yt1IZMLKOx2fXHyoE4ZfioFnwCAzYNAZMNgMGHwGDDEDhsyz H4Y4XjCOKMVRyp/mPm/z3Odtnvv84YUSPdXm6qHjcr1UtHD1WMWKQ7325XbFC9g1X7nWUD8Fko+7 1m267VPnNlKGqOob63rfVY0H6Xf0B/fot/Tpvj3b9EmF6HC17TGvUZxm2XmNwmSSJE4ERvaWWCOl +Ku5xMm0vfboAH6D8xJhibiKV5orr+XW13poCcGDJpuTQdVEF9XhcNzaanLZl5zLuMBraPrNTJmU n+HFfbvZOEsdXMeA8FR1Xb3fIff0fV8HNjQx9+fGHosY3vvPvtG6X3OvZUShsKVCnLDX1iMjjZmL rIhye8CHuPPm58fGVfVdWb0XixYP9c4cD9WuzP401NXtMVGo0rPRDZ99HIZLiSsUDzXk8wV5BluU /qLvdbM/dKasgGWxBzdrt7ZWjdXpWUTufyV4mMRphTlSl0IlF2erGwo2qnF1Y7SCAnMdk68ooYwx saM1de3MBWC7zchcpZOkckoZjYoAt1atI0qF/eZrd+dndqvIDfX7PuaZh95rTNucJtnGtnUHmM39 Z1954OasNpnbh9bNZhMGTdm2syeKlPt5xd35iCi829rzkWx82F3efFU5PtGwurDMcpWfPiKM8cWc SVaymuKsIGrwiLM7TTR6cTNY2ICzt0eWkfLck5vtwh6u5DMMFtVTZY0Xu/lEiL9EfnP7nYz4ppXL j4EXh2rru+zJrH/lq1QU6aHoP1mlQu755rHx55GVPak3B5Uuhq1hnW0O3cH5T4iD+9oHvCdA9eeN 31yLMAJIH2AtIn72gSeYCwNMFz8YerdovesvKscJhbSaSw+6aRzBFCRGI84oIA0ClQotgkrPJCy8 NJ845b4zE65Ubiiu+e7K/YazPumXCdN7MjNPTkNguSGXxyt8sU9r5F2a9CegOW+kCb04VuHx2nYa qmC47oAYGn9tflq3m+PW6+v0QgUr/UFR2VdPoQH5X9sfZZpzfkXSo8zhVJ9S/w8Pdwx+uMrzWXPJ 0/wpBnICr4T/djUv3wytmF2BX670vIxDNLugGEBelseUoF/cKIqRTd7JZgISlfl2E6fXTBjktRTS Zzctxmq5sPrBpJmzlkvOWL8kxrvLoqT+Fw+/+WWP4WX+0Rni/KMR4px9/1FuImX+fMVAi1TMY6Lk uLxEmuLIRh8IGxMC1h38c1bcVWyl95khYQ1QfQx84bDl8nL9dIz8sMynnBmoSDdhXyXn7YgQJoCU 0xIwpDieT4L1iAR02AOMSgCBohTzSXA3ml2e6gCnuSUEvvlmw7lsQpqbm/3msh5JsglkpAyftWef 9VyNHIkqgictIREVLL01dFqUgH3hpBohZtA+n3UFl1IUG5fhrP0Nu9Le0cqSd4JKxr9iby7t9eLo 7opNY809rke3O9oNvO3vzVKR/h+wJS+YyV5L+59aWnjB7e7JNeym3l0F27o+By9DloxhRyUZT+/t tfYGTLdvzfdKJTsreDT/mM2qdQLigfgFdlBmxEoX79vNp6GA5pMt02/Or/tqmy4eIJ96cs3KVcmS u2r2y9aT2huFqi/p6LT2A4QjN0cJ7Mw57z3vZw1wV37+/eo/J1f/bAplbmRzdHJlYW0KZW5kb2Jq CjEzMCAwIG9iago8PAovRjMgMTUgMCBSCi9GNCAxOCAwIFIKL0YxOSAxMDQgMCBSCi9GMjAgMTA3 IDAgUgovRjIxIDExMCAwIFIKL0YxIDkgMCBSCi9GMiAxMiAwIFIKL0Y4IDI3IDAgUgovRjkgMzAg MCBSCi9GMTEgNDcgMCBSCi9GMTAgMzMgMCBSCi9GMTggNzcgMCBSCi9GNiAyNCAwIFIKL0YyMiAx MjUgMCBSCi9GMjMgMTI4IDAgUgo+PgplbmRvYmoKMTIyIDAgb2JqCjw8Ci9Qcm9jU2V0Wy9QREYg L1RleHQgL0ltYWdlQ10KL0ZvbnQgMTMwIDAgUgo+PgplbmRvYmoKMTM1IDAgb2JqCjw8Ci9UeXBl L0ZvbnQKL1N1YnR5cGUvVHlwZTEKL05hbWUvRjI0Ci9Gb250RGVzY3JpcHRvciAxMzQgMCBSCi9C YXNlRm9udC9BS0FUSUIrQ01NSUI3Ci9GaXJzdENoYXIgMzMKL0xhc3RDaGFyIDE5NgovV2lkdGhz WzgxNCA1OTUgNzkxIDExMDEgNjgwIDQ5MyA4NDIgMTI5NCAxMjk0IDEyOTQgMTI5NCAzNzEgMzcx IDY1NSA2NTUgNjU1IDY1NQo2NTUgNjU1IDY1NSA2NTUgNjU1IDY1NSA2NTUgNjU1IDM3MSAzNzEg MTAxMCA2NTUgMTAxMCA2NTUgNzAxIDk3NiA5NjkgOTIwIDEwNDIgOTAzCjc1OSA5ODggMTA4NyA1 NjAgNzAxIDEwNzkgODUyIDEyNjQgMTA1MSA5MzggODAyIDk3NCA5NjkgNzc2IDcxOSA4OTQgNzYz IDEyMjQgMTA1Mwo3NTkgODY1IDUxMyA1MTMgNTEzIDEyOTQgMTI5NCA1MjYgNzIyIDU4NiA1ODQg Njg3IDYyNSA2MzIgNjE5IDc1OSA0NjggNTIxIDY4OCA0MDQKMTE3OCA4MjMgNjU3IDY4NyA2MTIg NjA2IDU5NSA0ODggNzg3IDY1MSA5NDQgNzM3IDY3NyA2MzMgNDY4IDQ4NiA4MzAgNjU1IDM3MSAw IDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCA3MjMgMTA4MSA5NzIgOTA1IDk0MgoxMDg3IDk5MCA3NjIgODY4IDgxNyAwIDAgOTg2 IDg2NCA3MzggNjY3IDU4OSA1NDggNTg1IDY5MCA2MjkgNDc1IDc1OSA3NjIgNzk4IDY0OQo1ODUg NzgwIDY4MCA3NzIgNjA5IDcyMiA3OTkgODA3IDg2NCAzNzFdCj4+CmVuZG9iagoxMzYgMCBvYmoK PDwKL0ZpbHRlclsvRmxhdGVEZWNvZGVdCi9MZW5ndGggMzI3OQo+PgpzdHJlYW0KeNrlW92P27gR f+9f4UcvEPP4LRJFgTZp015RHApkDy3Q9EHxaneFeK2tLWeT/74zHEmmLFrWrr2HO+TFpvghkjPD md9wRjPOOJ/dzcLfX2dvr394r2aOeWtn17cz4TyT1s0WMmPOm9n1n/8zf7f59ljn63z1bVturxZK y3l1i/9qXt8XVPG3fHtPVe+vnJnv1su6rNbU9o+f/72QxsID52IuxNV/r//+w3s38zCpwkkXQlpm uIJZDfPwj7N+oG5y380y69SMh9aP88FbFHOZbpqXg8GaKSHbwVdvBqOpwF8+tWmabwaDDRPOdFMz oINS8w/lellQ8elK2nkoy3m+3e4eihtqqO/zGku6oTNU3ZVfrmQ2L9b0eE9kh9KXK6Pn+WrXvOe2 Wq0q7Pm0pfZlsanzshn2mNd1sVkHKswWmjMDy18IwbwhlsN8G3yTEfOncrXCkpx/ulpIN2+q1xVV LoHLME29yW/Kluc46r5cFdRjW62+lOs7qs+pTi1ovZsy/0T9+Lz43y5vXyDnd5tq90jFIGwG97Tb hBXzZq02rLUdtwXKyszMr++ROljabQsqwL6BxEA5WP6mRvLKTAObQyNtKxDrK9XUFf0v89Vyt8rr YsBwyS0TopWITwlpk51ADGXNMCOOCmrGuGmH5uubwWDhWObVqLDZprUjCB7bQIfmPw8EAqHLt9+o 5hEkqWD0NhudTKkt80rOQGyY4yQchskrYID283/iKGCO0/Mf4U/Of1w0C4o3JIEYrlnSu6ZdwZHy cFyh3TGnNBwhK+j1kqSSMwv6ZwEnzxOfVaj/y3VQWfHZlCyzKL7KMGWy0LdZmJYGFwac/ZEekAD4 /1BtQrMF+X14XJVLYPINo7br+2bkQ/l1Wa12D2t6rB5J/jeNlGLdbbWhQt0Oqu/LzU0zYFc/7uqE xIJor5sjXm4b8RCxLjJMWzFbGNA6Mozg3VsyZhTR6W1bBzozy/pVlqmM5vrjQIBAfkQ2k7AcQaNy 6uL3LAEOgzlYCKa93vOkr7M1yzJYo+BhrdExiN6Dx+D0eyQ0xu9ZJt6DyvvkerTvvecmsS88HMP3 xMTXYIn8TIMskR0SCdK/G5L+3ZD0fxocTpABDaYAjpKjF/1hOD9swAg7A4vIG0t4NvPlCPO5RKnm c66af9H9x4JLs3aNw0EjnYeDEp2H07eDhhxyDPSLBioqexkWCdGjv1ci4tFHqZNi4p24KJcOjqiL uXQWGJpwvkXCgulstu/w8SqB2jI4cn3ccBZyKhKLsMp1yCmxAsOckRNWoKdR6jZhTr0ZWwDw32Xn k6BdwF3KnouDBcRiCDAE5r/cWRixrxLeiNTGvk8BHw5QEcitG+emPwqKgJLWHOUDeCXajaEiz5T2 R6nomOZZ0xp8GMXnqyrY82D6sUYgTBxANSCw1X3wEh0koAiYiT12SZ4jC2Zp3+UNzQUAeYmQ854W kwe4DfX5altRaXtPAH5NPQi7Q4fHBoesb8qvVFUjiGZURvQS8JPQoKKM78kmgG7TOgnaIbAeCGMG lJIvZqHU2QgLtRLjLDRdhxQLjWunXubBtfQttaC0d07gAXBtufpGbsVtA7ZCH6DnNyrvvRJ4aNxY 3/NBOPkgb5qxDZJbONA5qk/Wp+CSAegDBycsTRsFEDOs6Ka8/YYVEid5oKabclMsa1igk4jRcdi/ sFxQxwd83W5b09NHaTLcQPOKckPv6PyuakVttLm62O6HbbY1o6d3Ue8hHo2GKighqD1kjhZgc48f 7QwslT4qF6hA3NjRlubE0ZZ2RC5Up97pFCHVi3VFx1qCkGyHkgpqr3P3m+0IHgNOG3jc2b8yodWN l5GFTG/74Dj053DgFj1rjqnk6U+TGTE+jQJ4HRt7RkT8eQ2SUO/WoCBJVodbBN9Oa9mf3Pfn7uF2 lZCcTOto7qCdYfID7QxsTGjnhfQKAFgfg4xpaRtBNfAwM3DhF2jCfby6mHoKCq1O+v3gxRKkqOVw amtOK+ijMxWDfdfzB4Q88OUP3BUTk48npF/Atvc9YrNifaMooQDHAQoZj/QkPHQ6CrVFcICx9u2u 6dvqtf2boHK3DQyxrdaEqtuiuPmUL/GO5TM2uUNfma6ZDJwH3b9mqsgL7unK4BbX7AgayUBgwD8D zvNAfHzN+xI0HeppcLq7NUs9cn/jJPPejpp1HQmMSIktd2TWqcvtpnoYagAF1t9NQA/2CHsH0zyV 9X0V+IO3GevHthjuyPDOothu87uCHvJg+PCaomVQNv/MiDYfiuWiAQoGRNSLHmOq9c0bcsDay0mZ +Yie0CSI/1iIYAUOScAKIcH6C/9CXDFuPwB0dqjjyIWZG4GGcMi4jy7MYAM/VbjpJ9o0XjqGXd5V +YpK4RoNCVDRP524fH1XJE64Z1xkpyzNnsFozk3iXg9VheqJQvJe8RBCx1MFX2bCTKDzwJmIZkpR FVUyy8Ltzl5s7lKTInn38PforNARncl9T6DuUIyYOzTbz0CnWTbmYHgz5mBIznjXYVyK4OQAho5V seYCTma+RmzG1R4vQvW6QHWK/VGasPXTJuBSrAqK2YKrFWIFWPOxVRK9pXGwAqpvpfouiGxXPhxN FxntWPBobSc7oicUvDtEsKhhEAcv3qSYIH0JOXBpOTcjG2qPFG+COXhDrZnEIFIkkClygTroLtib DReJDQPg7eiS3DAW5JSDfZkNT+Xg6NiPV2Rf8/b+OUUgDZzk+iLidLYo3iU5k5mTnFHHEfFklTTg TEu+lGoCGJ7J510U9CCoOwIBEATKCEUmb046z/jlM8uUx81j/HrM+7jAtrOT2z6FB5VyAapjX3Cm VRtQvc/3oT+qqcOtCv5UVBE5/RhhRac/FZXRNoB1vHTkWiTufPXwztdNv5mXKoBOvPS1hzfK0T15 8hJUCLTDEtZleupX9ByF7h7rpDp7pvqOdrHATIKwpiYSx4eERFPqXbi0dIk7Sz28s3QvCrHYKSEW eXFGRiEWtw+xAJKcHmLBzpNDLNh5PMRi9yGWuPOJEAvA9aP3yi/g0ZEYiz0RY5EXZdMwDAqHhrvz Yxe3ibsPl2XkvJsjqr2LsZj+/b7o63Y39dheIvYx9cxHO4U9crABo1YMlBOAw706TwVTLEzFRU+R vTZPxPfDE/Hr54k+AkSOxCJ/+zyRvxWeqO+HJ2oyT8RgNVoz3kO6L7aXGG6VYB5dyLwS1l0eb0pm AM4e4s0DbElZX7GoFSlGY1x4okP2XFc5BpcZsyHHp48uD3FOAvBhYJrC5E68DuTU52X1nA853WtD TvscyGl+xZDTTIOc6jUhZ3axdBnfP0duPF50KbV9Vqq0fuF1eLRVfgJu0tUN6mx53I4CI0xrR/Ur M+S18ebrM8RMZ4gYY4iaxhDzizBEfh8Mkb8ZhqjvgyFqOkNeFWYeT/fTDiymaL7FqVZf2rh65ppM JgWGPQTw4f+uqJsKygnw+5jwlsaETHlsyMPnJBhNrsJXGZTBhF32aUiDCJfkTHFxVr5OxrhXp3Np nDwvZQdzaWwvLaily5pKIdcha3MdqOmhgfwWg4zpFAmiMBSKr/myTn7zk4i7e8mE0WNpW/ZE5lUm xxK3utyYRHIObMJ2yS1nxyUOk3LkaFJOu6tk4ob/ZWIa/JyFyyOJpNMDIobjlzumOeuY/EdSssop V+Yg7WYQVPLgsLRH4e1grQ4E1UZE6FKqtPc9JKBTik5yN54XRd7Ssyc3qakPvAALBytSslPjhyIW IdXJ9cl7jXT8UUwJPwLHjTvIiOh0QTL3eix7VqsTR1VfKor3vPw5ezR/Lhj+A4E//DrNhJzhhQKa NtbPMHX067TmGzUyUk61SbL08OlKCTQ/9BQSquCfzBUUNsVDXq4xNWPwhZuUmFNw+Imb7n/iFt9G lcOv4ML3bvY537sZC/ZdkHvzE6WKw0qF3KfACQp/ZvvwJ7bSR6VC9fqFcr7GfjXVpMREoUhOFpMo zfLEDdvpGLcBv/18AVWJcyH9BHsgJmXxHXy/eHLy4bYD5QkqifbrajGQvfhKQTPhD4L/8fk7XFw5 vAGdsNBD2/OmExr6cFmIUVuykB5OpegDm7fDxZJe10xaGS8WpCfSGE7s05C0GGzHMtkhuEYMwJLp cLK88EeNEibrolGyzc1i0LWgOR7yz+0xgadqHQqmw6pDhsA51vpVGPKyvORUzrDisdh9CoC02Vij G818mz80pXxLm++a4o/Qob75CB0aOtDPqOU9Zo2nEmOFBwq4voH/hSTBnJIEdK50JAlteplWsCgf 7sT5wYcfiKsoQRqsc7UOn54o3YP6AzkBzeMuKybZOYBTTQCcYXvtlyq450HeduMZQqn7xlnvP7tR Mq5elZ8j8tX35baFtL/7P2JVVzwKZW5kc3RyZWFtCmVuZG9iagoxMzcgMCBvYmoKPDwKL0YzIDE1 IDAgUgovRjggMjcgMCBSCi9GMiAxMiAwIFIKL0Y2IDI0IDAgUgovRjIyIDEyNSAwIFIKL0YyMyAx MjggMCBSCi9GMTggNzcgMCBSCi9GOSAzMCAwIFIKL0YxMSA0NyAwIFIKL0YxMCAzMyAwIFIKL0Yy NCAxMzUgMCBSCi9GMTIgNTUgMCBSCj4+CmVuZG9iagoxMzIgMCBvYmoKPDwKL1Byb2NTZXRbL1BE RiAvVGV4dCAvSW1hZ2VDXQovRm9udCAxMzcgMCBSCj4+CmVuZG9iagoxNDAgMCBvYmoKPDwKL0Zp bHRlclsvRmxhdGVEZWNvZGVdCi9MZW5ndGggMjg5OAo+PgpzdHJlYW0KeNrNWt2P28YRf+9fobdQ 6GnD/ea2CNLaqYsUBRo0V7hAnAeeREmEKVIhqdhO//nO7OxKpEjfne2z26f93p2dmd98LLlIWZou dgtf/HXx7PbrF3KRMWfM4na7MIJZoxcrYVnm9OL2u58SLpYrYXSW/Lhfiiw55fVuuZJKJC+XmU5O yxVPhU2+K+rd7tTgiExe4EiB8/zYS2pW5dXKn2//tvjLrSdBLByQIJEEa5lN3WKlJbMu8yTAfjJp WlhsXdI2p3qDa79+kV1WKcsMN4vUzy9peLCpZk7H0d/DfbRM+A3sl6XJmyWQWNDe67xan6q8Lyb7 W2DRef/nNMzThWHOKj/OMikXEojQQxLcZYZgGXeRBD6hkCsmLV+sLlts2+YwoUMoln4EHUP+Mp7K 4Tlvyn7fnHriRlkfYzUHNvvKtig2d/ka+fSa+NQ3XngrwTlTqV2soHSattsVsF6luJ5K2Nvv6evb KWeRIBtutJ/eSDMoV3CO+3jOKqhddvgGr+WSV8mEFq6ZDhvlc5QIYwe8barlSideF2HRyjABevt+ ErMrEofnpkxnBmZpp/ycPwJ0jEnupkRkgA758US4B4jQUyLWs0RI90WJ2EyJcHC8ejpxiHvE8Wo5 PV6yzA6Pv51sAxRYM0QaIxC8RHNWUL0GbFFtU74S2hRtUa+D+eH8speTCAOiWE24lrHsbN7eo7jm UzGkrRhgKFoAKXELHiyA8WN3YGDRpE5kK9kjqVQfQOWQSxzcl3OLyxbA0qmOUeUBOqT3J0+g3GJW uaWfgy5ISm9piYwBlSugw2bAD5C8JD+YRhq4ZVrSDZ/FPnBxNht3GXApdIc/TXkFGOZ2IUBsPPui ajUkArDNlIKAA1ijzD1kRLM8YxEVwezTyADumSyQwR9Bx3qODsnFp+mvZ4eQH0DHZk4sPPsYHI2t sBF6oTSTpKh8RvOeTzXv+VTz/jxFAVAGKAD7mUV/PEeABvgJA1GqfBrdF/eofooxLkQ6qQwlP5fx 1EuAcx6cLhpONuPJ00UzO0+Pj4smHFIZE2KhgIvSPI2IRoY0ZU7ygYxeCTVHBHMZ/1xSAp9jMjkS 0xzP5pg+gyztU5zhyvvt3bPpbTOWavukLL9GhfriqBgJ3TLhHuES9BWLhmym8YfZfLWHGNpAy5RU Y4HKWV/PbZSWV8+VEGLmOI4Cs+8/D9nJ5VipxBOf9znVaCaHjmk815AWG+Hn/tjM3EkxrvSjwspn cxorZfQi38xszlkq/4chKzAY0rVh2jeRFFLIP2uAA1SkqR5QMRuRArC5yR4TkurPF5KqmKNIozBH Ef5VxMhkjZk8dh4a9EeQqWzfTdN4IEKKK60fpYxe6+EifEgpREyzpALA+OQucISIOkOgWTmmMXw0 Z5PF1fSOaNcwnTNAwSM04eOpzx6i3j6S+pEKGW8PL+S/X4XcJ+ty9pAum/9jXQb58KEu35ekHvLX y9ksNbiDp05Tx5bJBT6qUcIMhKqk3xeUFXb5IdTyjoZ25a+eZoSjFMk+7/Y08OtS6ySvTgWjw8zA vUGgmKbgToUDHabzNFNL4IVyyfPmcKyKt2W/lGnyDt/FBL7RQSmBkBLPzVSS932+XkqevH7A3wiA mjUUmjyD7ZSyF6MB2mLXeV829Q2OZOeXV5y1z5fCwD1gZujx7437vN75BxLo4NLQuruy76gGAqZy X1BlwCFcMuCLb0erhvVTF9bctSd68L2KLLdNu0YBcOvPkTwDpemJLOpui0Ne1vSsDU2ki9HEH8ua 1gbasLJu6q5Yn/pAInaa8+MoTvD8aNpNR9t5OUD33//1b+oY8WhKb1tUnruwXMD97jzbix43fePX IFdwpMjjJbDVAIHtDdWjRHx/Xb2jGr1RCWDVsW3u8ruyKv2uYRjpxFLM2EQFFm70UviwXTdzPsrh I/PgaRw/BkyvcpEHvU4bw4wVIyZ1fXFEGTmZ3HrBOAWCiSCgS+GgZ75TEQQugiC8gcOM2C8m1+EW AMaHj7TxUkPeWOaUuPgLea+/0DM5LISgQ57gq7bN5sgxTKdiQE2WTlksmEQAXybR6z/csy1+OZVt EblABWL5bbGhRlf+FjhJz/vAeTCixl0Z3OLQtO/IoL3Zl2ccgSErg32ri11V7sq7iuzYPR+HhLVe sXDj71H/tEHSsKiLN1ixSbcvtz31EeLWvVcbaOOBWIIN2NBkRDj2gAo1ODliVIABGQJLm2tg2QAs mOihjrtFVOP0M6pvBm3C7wo8llNqpKA+2BIuBU0tq4qq+fHosYi95aGs8jb0D1RSZM5/yQkjVFTN Bf1hzRTCsNBDGAZnIQyaZj4IwkLN5wpTBMORAwQDIRMEa5YJPYtgGREMlb7p84qqAzAbD2bQr/7U 1h0N04cudLMNdQRpUmMGPE4yOfrgwsUsfBQX46d+4uQiUo6JZqqZ5YgyiDYVxXIGHbFQ4IjrdXXq QMsecLFSa/8U7zW/ji7GI4i75Jgf6T5o0bHj/HXz2n/4hWWNw33b+ABkc1p7SMNATqs9lrDyuvTm AGqbEhSz3p1KH3vA1OJtPLI8FLRf8Hd5VRXxfXIQkUiZwvVjsL0uf13FKI36h8I+ttvZ73n6nCeE OKHpinoFmtOXebUCt2+820fCZHIElPsgRCUtmLXmQPXtqV4jrF8tsa3J4uHAIbBjELHQjL6gw+ry lxMaRNwcFTliGckaU1+Uh3wXo7gzWhmp5TnHgjrlWKCXXR69ECruPu//MAnpCGsrDil0RrHWf95n Lh2YS/yo7DJv33GuDycA0WQEbZrUTU+VnPp3FLCFsI2GfvjnCxqsPW7DZCh2xKvRZBQpLLih1sDW 4wZk36ByBh5OOvsTbNxFy2QylK7xUWC0CeOYJw+hMpl6rA5Nffy2QpXNhiI1tBe4qzeLDTEaXFMI v/3vBd3INmzDoAx2fSbIhhAl5Bc2APshkSghWGrsRSSapxjRU+VaBti3bqqq9BYCmhxMZQdQzH2c icPF23Vx7KnurStNCqDG3rsqr1+Hfv8TxWXb1Qxv6ShlAjKwsm2LYgWHtj21ByT5eaDhPqtaYxys jIpxMA5SjA6Vrm9PazDJoYm+B0vPBKygXmJ5l3fFZoaupg5C79siP4RPaLB7FyR4wVlHwiUPXH8V NCT331nX/XlhdBznu3g9GLDXi35LJZD5NPLXEMoIdZG/Mpbkr0DtB/K3yYb6LtYEW0P6sB3Fj9t4 8WPnWF7XWwwN0pTNP1yMlx6HGhISx0O520dbr7ybgVymDYMRwFgvDxBx+Igq/P7jAss1nze0eJo3 tOZiaHFV+Eh6RSW4zAjqI1wTrf85SQsjgO6i6ME5rODg1aHcbKqYao/sOXvA8+oUhCzo2H8cKWUP yoJBVVUcuqew1Zo7ZlJ6DvIBjnDIWoiLfWB4iWudHce1LsS1UJJJhwljO3JDo+csD2dSbgdTcyoo fMYj64J6zv8HYeO3om0Q3Djjpbfshn7auQbp9gyvA9VikH8GXLCuXf/tU+BJKwjU6HEu/l8hMuNj nkE0n1GakFkIjXuq+NgXypOPXUJGAPM2xQ7Q040nIaBCAGExepo8fjlIeDkf/5/lhklf/ESsh1+q Rr9nSeEGb2ybU+v1GA+k/CKzc8BhNPJ9F//MkrDjSCSY5xfke/N64GI9dnN0hqHD50LmDN1LyOgH 92GPmXcdGrgG73DLNUyCMYg4Kxogx0vxAJLUF93TqIOxLOXigiKJGWGPv/ZRlXJWqHm91BifoPh3 xQ01KW7AzBBisK+6WA+LMEuhWoA+NjIyvH58anGmGLk2PysF+dBz/9uc45fXsUsCiN3kRqEyb+5w 9nWYin2k17iuDPv/JH8OOzYztIFL+jaw+Hf/BZg/KzMKZW5kc3RyZWFtCmVuZG9iagoxNDEgMCBv YmoKPDwKL0YzIDE1IDAgUgovRjIgMTIgMCBSCi9GOCAyNyAwIFIKL0YxMCAzMyAwIFIKL0Y5IDMw IDAgUgovRjExIDQ3IDAgUgovRjE4IDc3IDAgUgovRjEyIDU1IDAgUgovRjYgMjQgMCBSCi9GMSA5 IDAgUgovRjE2IDY3IDAgUgo+PgplbmRvYmoKMTM5IDAgb2JqCjw8Ci9Qcm9jU2V0Wy9QREYgL1Rl eHQgL0ltYWdlQ10KL0ZvbnQgMTQxIDAgUgo+PgplbmRvYmoKMTQ2IDAgb2JqCjw8Ci9UeXBlL0Zv bnQKL1N1YnR5cGUvVHlwZTEKL05hbWUvRjI1Ci9Gb250RGVzY3JpcHRvciAxNDUgMCBSCi9CYXNl Rm9udC9HWUpDVEQrQ01USTkKL0ZpcnN0Q2hhciAzMwovTGFzdENoYXIgMTk2Ci9XaWR0aHNbMzE1 IDUyOCA4NDAgNzg2IDg0MCA3ODcgMzE1IDQyMCA0MjAgNTI1IDc4NyAzMTUgMzY3IDMxNSA1MjUg NTI1IDUyNSA1MjUgNTI1CjUyNSA1MjUgNTI1IDUyNSA1MjUgNTI1IDMxNSAzMTUgMzE1IDc4NyA1 MjUgNTI1IDc4NyA3NjMgNzIzIDczNSA3NzUgNjk2IDY3MCA3OTQgNzYzCjM5NiA1MzkgNzg5IDY0 NCA5MjAgNzYzIDc4NyA2OTYgNzg3IDc0OSA1NzcgNzM1IDc2MyA3NjMgMTAyNSA3NjMgNzYzIDYz MCAzMTUgNTI4CjMxNSA1MjUgMzE1IDMxNSA1MjUgNDcyIDQ3MiA1MjUgNDcyIDMxNSA0NzIgNTI1 IDMxNSAzMTUgNDcyIDI2MiA4NDAgNTc3IDUyNSA1MjUgNDcyCjQzMyA0MjAgMzQxIDU1MSA0NzIg NjgyIDQ3NCA0OTggNDIwIDUyNSAxMDQ5IDUyNSA1MjUgNTI1IDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDY0NCA4NDAgNzg3 IDcxMSA2ODIgNzYzIDczNSA3ODcgNzM1IDc4NwowIDAgNzM1IDYzMCA1NzcgNjAzIDkwNSA5MTgg MzE1IDM0MSA1MjUgNTI1IDUyNSA1MjUgNTI1IDg1MSA0NzIgNTUxIDczNSA3MzUgNTI1IDkwNgox MDExIDc4NyAyNjIgNTI1XQo+PgplbmRvYmoKMTQ3IDAgb2JqCjw8Ci9MZW5ndGggNzIKL0ZpbHRl ci9GbGF0ZURlY29kZQovTmFtZS9JbTQKL1R5cGUvWE9iamVjdAovU3VidHlwZS9Gb3JtCi9CQm94 WzAgMCAyMzg0IDMzNzBdCi9Gb3JtVHlwZSAxCi9NYXRyaXhbMSAwIDAgMSAwIDBdCi9SZXNvdXJj ZXM8PAovUHJvY1NldFsvUERGIC9JbWFnZUNdCi9FeHRHU3RhdGUgMTQ4IDAgUgovWE9iamVjdCAx NDkgMCBSCj4+Cj4+CnN0cmVhbQp4nCtUMNAzMrI0NzJUMABBZE5yLpd+kLlCejFXoYKppaGekTlE 3NDAwlLP0hLI0jXQMwACI3MTQ4hqCwWXfK5AIAQAF2oRywplbmRzdHJlYW0KZW5kb2JqCjE0OCAw IG9iago8PAovUjcgMTUwIDAgUgo+PgplbmRvYmoKMTQ5IDAgb2JqCjw8Ci9SOCAxNTEgMCBSCj4+ CmVuZG9iagoxNTAgMCBvYmoKPDwKL1R5cGUvRXh0R1N0YXRlCi9PUE0gMQo+PgplbmRvYmoKMTUx IDAgb2JqCjw8Ci9TdWJ0eXBlL0ltYWdlCi9Db2xvclNwYWNlL0RldmljZVJHQgovV2lkdGggMzQ1 Ci9IZWlnaHQgNjM2Ci9CaXRzUGVyQ29tcG9uZW50IDgKL0ZpbHRlci9GbGF0ZURlY29kZQovRGVj b2RlUGFybXM8PAovUHJlZGljdG9yIDE1Ci9Db2x1bW5zIDM0NQovQ29sb3JzIDMKPj4KL0xlbmd0 aCAxMTUyMwo+PgpzdHJlYW0KeJztnTuOHdfVhYuALEckbXgCMpgo6MCegRpKKDDtGfydGEovoTEY Yko4ac+AKSElQnMGdsBAiSBOwLBFRrIF6O/7qPfZVWfXrVN1VvW3EpK37/3u4V51Vp967ge//vpr gRC693pAFiCEiioL/vznP//zn/9cezAa+sMf/vCvf/1r7VEgNI/+9Kc//eMf/yiqLHjwgAVCrKgV 2pKq7ZkscItaoS2JLJguaoW2JLJguqgV2pLIgumiVmhLIgumi1qhLYksmC5qhbYksmC6qBXakraX Be/+/sUfv//q168/S/5N+rVCqNbCWbCfqNfflv/a3SaYsmTBhvTm+YPLF8e/JtlYUEMrZEE5Ufc+ v7358Zv/+yTZV6QVWZBUh98bF2UC3P3r5ZNvSIOEWjEL9mHw10+rLKh/BTw9BUTz59UHDy/eXFxf H967a2wqxwXH7ubm7TVZoK/99lCwFlhQK68LSrODf7ey4PLFMS32r7262v+t8fHDz5dZT5IFCbXc 8g6dtOLxgqc3zTVBY4VQbgaFuS7ovPhJc7thH2ETam8SaAGtti5oLQE7xt/98/UzRxY030gWbEPs IiyudfcRyhnMugB1xcJgaa187LC5l987XlAfDzjuWuwGDyIcP954Z7L/RCmyIKl65xH+UvyNaEio NbOglQCNIwn1TK7PDtzeFpf7/YZwFjTOQtTvTPafKEUWpFbz8BLXF6TW9q47XE7UCm1JZMF0USu0 JZEF00Wt0JZEFkwXtUJbElkwXdQKbUlkwXRRK7QlkQXTRa3QlkQWTBe1QlsSWTBd1AptSWTBdFEr tCWRBdNFrdCW1M2C3/72t//973/XHpWGPvroo19++WXtUSA0jz7++OOff/65YF0wQelqBRnyimSy wC1pvyFDtshkgVvSfkOGbJHJArek/YYM2SKTBW5J+w0ZskUmC9yS9hsyZItMFrgl7TdkyBaZLHBL 2m/IkC0yWeBWRK1Oj2R96mwbKb0lQVYnkwVujdZqcqsG6S0JsjqZLHBrtFaT231Ib0mQ1clkgVuD tTI6R85APksj5HrUc4+5JrsbHUjPq6XJdbvywmsiWTBdm1sXNHrX+HdvRshf/PBl2S7P2ydxgzM2 Fbna4qbsnpIF07W1LHhzVovayDFP2Eg3N2OTkRuN5ib0nCMLpmuDWVAvL/dyreaHx9zcZfLuJWxt xqYj10HLumBZebKgnGdx0yCDdUHz1aiRj6VMf+djDvJ52ho53H/SXWeywK34LLjz6OWTbw6do6MW busfLygVP/K4lKmbJ89DPk9bI9/VuddWeEKdyQK34rOgOnT27u/Pv/v861yzILCUL6JHHnlWZbfb vSiODbNnIZ+lzZFb/h3PIkyoM1ngVnytZLKgp3QzliyYndw6SLD/x6urH7958pIsSK/4WjXWaYc/ 5yN75SXHjzwfcrw2Rm7t45XB8Im/zmSBW55a+W5MyGkbjR15TuRYbY7cPBVU1dVdZ7LArc1tSZAh kwWTJO03ZMgWmSxwS9pvyJAtMlnglrTfkCFbZLLALWm/IUO2yGSBW9J+Q4ZskckCt6T9hgzZIpMF bkn7DRmyRSYL3LqrVSLyw4cPP3z4ABnykuRHjx799NNPBVkwQdLZDxmyRSYL3JL2GzJki0wWuCXt N2TIFpkscEvab8iQLTJZ4Ja035AhW2SywC1pvyFDtshkgVvSfkOGbJHJArek/YYM2SKTBW5J+21r YleHQfLkThGj5LO0UfK53b3JAre2uyWRBcLk87t7kwVubXJLIgvUyed36yIL3FrN73TdkPc6bEu3 V68uD18R3e9sPAv8zOgxT9Rq5Dm6IYc0T3dvssCtlbakdN2Qa/6L04ZUPmT/3Gc3T2RGj3mi1nNw hm7IllgXrKB1tqTk3ZAnfkH8PoJ30FvLgpm6IVsiC1bQalmQrBty+QWNbSnUos9PnsiMHvNErZYF c3RDtkQWrKAM1gURr8eTQ6CU64LinvZZDndDns3BFsYTDGTBdK1/vKDSvkFWcVUUo70anccLQt81 dcwd5pc/3Nc+y8Fl0XwOtppaxzE7ZLLArQzOIxSN3yxRfVvjsuD1s9vi8rgnMtt5hC7zHvdWDXRD Pr0+h4PtpUBkN98WmSxwK7NtdK4smCgv+d5mQbAb8uG/n8JBsmARZbaNimXBve2zHOyGfPoHWSCq jLbR+uTCyJo+ozHf3z7LoW7IKRyMZnbIZIFbm9tGIUMmCyZJ2m/IkC0yWeCWtN+QIVvkNFkQ2jMa eO+066WGP3g8geO+USNC0n5DhmyR58+CwyS8qA5aHGJh6BhGgiw4nbH56vs/Tr9j1pa035AhW+TZ s6A/Q6vzJ80fHV/88dO/dq6eOVydUr18ypCYD0YNZRZJ+w0ZskWeOwtCF7KXc/Jdb0rv39e7f6V/ l2vMBwMiCyBDjifPnQWh+de4KSUmC4J3s5AFkCHLZUHvrhbnuqB/l+t4FgQf+ZMuC+YFVlLs0gtZ nZyuz3J/Albx0N/tZ10AGXIu5PnPI3ROHOz/+bb7lKvjr/Hjm+zjBVWIxHwwPBKyADLkSHKS6wvC N9c2f7C7vS0uT3dzn148BsBh/t5cXF+375wd/6D5/YX7oZsjkvYbMmSLnNt1h4l+l88pab8hQ7bI ZIFb0n5DhmyRyQK3pP2GDNki55YFApL2GzJki0wWuCXtN2TIFpkscEvab8hx5HN7Fs8usiBHSfsN OYZ8fs/i2UUW5ChpvyHHkM/vQTS7yIIcFVur+oqn2GudpLckU/46RJHz7lk8u0bIc/TgJgvciqtV 4yatqiXAPOQpWo88pQ4R5Nx7Fs+usWrM0IObLHArqlaTtqYNZsEZ14sMkbPvWTy7hsgz9eAmC9wi CxzkdFmQd8/i2TWSBXP04CYL3CILHORAHd7M0Gc52LO4BJ/fhaUedTQzkjxZ0euCxovOapAFbnG8 wEPu1uFvxV9m6LMc7Flc/Wys3P51QayF6x8v6P8ouhpkgVuxtXK2snKQ/VqT3K5DMU9vVatncd2w 8Zwxd7MgghlJnqzo8whFa3vzVIMscGubM3Yp8ix9lu2exVG/wJ1jdpz/yKfOB/mqQRa4lZnfYuRZ +iwbPYuH9hymjjmW6Sf75Ce7q0EWuJWT34rkWfosBzpzNZbJs/Usjmd6yV5NyFxvNcgCt/LxGzLk GclkgVvSfkOGbJHJArek/YYM2SKTBW5J+w0ZskUmC9yS9hsyZItMFrgl7TdkyBaZLHBL2m/IkC0y WeCWtN+QIVtkssCtB/RZhrwhcro+y9uXdPZDhmyRyQK3pP2GDNkikwVuSfsNGbJFJgvckvYbMmSL TBa4Je03ZMgWmSxwS9pvyJAtMlnglrTfkCFbZLLALWm/IUO2yGSBW9J+r0ee3sPD1n3shhwnR7XJ gunKxm8t8vxZcD+7IceJLFhE2fitRZ4/C8S6Gy1KJgsWUTZ+K5CrR3Dubm7eXs+XBfe3G/KQJlWb LJiuDc7YVORW06S7Xftpff4sqa0L5umGbGtitcmC6drcjE1G7rU0udf7CDN1QzY1tdpkwXRtbcam Iyfe+vWyYI5uyKamVpssmK6tzdh05PBvqjn6LB90P7shm2JdsLy2NmMTkus92ONRrbvp/+UPX8zQ Z7mkd7shPy++zrcD6mA35LGRu44XVNUmC9JqczM2JblaGO9ub4vL189+ffZ6lj7LJ3aZBceviT04 n8F5hKJcF8WOPGrMvWqTBWm1wRm7IHmWPssme/7eqj5NJY+PnGuQc1R+W5ISeZY+yyPssfflU41S KaoRK7JguvLbkrTIs/RZbqlaemd97DCk+JGTBTkqny0JMuQZyWSBW9J+Q4ZskckCt6T9hgzZIpMF bkn7DRmyRSYL3JL2GzJki0wWuCXtN2TIFpkscEvab8iQLTJZ4Ja035AhW+TTH48fP37//n2Kb9qe 0nW8/eijj3755RfIkJckf/zxxz///HPBumCCpLMfMmSLTBa4Je03ZMgWmSxwS9pvyJAtMlnglrTf kCFbZLLALWm/IUO2yGSBW9J+Q4ZskckCt6T9hgzZIpMFbkn7DRmyRSYL3BqtVePhddYzfMLPt1tr S4p9TmDovWuRz9H2yLPUmSxwq1Wr6smz1XRvPJl+4CH1QfOW2JIGBxyjzsiXIM8tbXKyOpMFbtW1 2nvw6qp8Kvfx+b5NX4Ya+4TCIPmWNDbgKLVHnpycQMLklHUmC9xqZ0HXhLLOY42AQ59dZEuyBlyN aqwRcBviJ9stPILkBBImj9a51anNMNGoM1ngVqNWx8I3N+5WmQcb/gV+mH4bHR5wZCPg1shjyaeu CEPNgwzy/FImjzp4LODwWiFcZ7LArXatyt93pwhuVXkwCwJuLbKN2gOObc7Z+lEU2fpwLHlmiZPt Ojca0w32qAvXmSxwK1Srgz3FnTdPXuaeBfaAYxsBD8/YcCkC3cMCIgviyaE61/UbXheQBTMpXKvT 2vfZ63AW9JsLr5sFoQGHo2tk5LHkwM6HnzyTNkLu17mZuHVVY+tMFrhV1aq5DCu39qK5O9zce+s1 F17heMHYgAP78qMjjyLXnzhsrRe3v9ZN1EbI6aqhSB6vc+/kVHydyQK3AntuRX3Itlnm6u+BhqKr nEcYG3B/KV+MjTyO3DiLsNu9KPbb62hNdGdsSnJsnaufx9eZLHBruFbBHbWAH6tcXxA94EqjI1+F fKY2Rq7q3Cp4eSXCk5exdSYL3BqpVWgG9JsLr3bdYdyAmz8cHvk65PO0NXJZ59YOavniJ9F1Jgvc 8tyP0HyteWOC0P0IIyNfi3yOtkcua9c8FVRdaBRbZ7LAre1tSZAhF2TBBEn7DRmyRSYL3JL2GzJk i0wWuCXtN2TIFpkscEvab8iQLTJZ4Ja035AhW2SywC1pvyFDtshkgVvSfkOGbJHJArfuapWInK6D M2TIlh49evTTTz8VZMEESWc/ZMgWmSxwS9pvyJAtMlnglrTfkCFbZLLALWm/IUO2yGSBW9J+Q4Zs kckCt6T9hgzZIpMFbkn7DRmyRSYL3JL2GzJki0wWuDVaK/osG58JPnTd/HLpebUwmT7L66hVK/os d8Y8xDcbMAS34+3N2HnI9FnOR3Wt6LPcGfMI36iHEQbaMzYRmT7LWamdBfRZ7mTBAP+QBbdXry4P X7HrPrG3+akueVYJk+mznJUataLPcmfM4/wXp+2z/QsuVCfhGZuQTJ/lnNSuFX2WO2MeKIj1BeHv Up6xScn0Wc5GoVrRZznwnl5B2vWol7ZkwQTyfemzbJ2Ky0LhWo30We4Hg0qf5ZGRm2MOFIR1wazk 2D7LsQ4ukwWtlo/Wr5vWu13HRZdVVav4PsuHhmHFVVEc+9kV7R/2yYnGPKHP8ujIm2OO4b+oV7bN 1zleEEWe0Gc53sHlsiBwgMrQ4NJ6fQX23IqRPsunN5e9LcuPCvRZ/mxs5OGjJ2H+YVO9LS6PeyKc R5hCdvdZPvw1ysHls6B5ALl/Eqt/Kq7ei239328urq/L46kxZ8Lm03Ct7EVN2w+RPsunt9gjHx3z OJ/rC84jD/dZPl2NFOHg4lnQGmL4JFb7N0l/BdtcapqQdBqplTmGlh8qfZZP77BHPj7mMT7XHZ5L HuyzfPpHhINrHC9oNoANHUuqX+4usqv/cvtwdNSZsNnkuR+h8dJpcXNcyejcjzA2cs/9CL4fbm3G piQP9VmOdnD5fYTGysA4iWVlQfm/6GVB1Jmw2bS9LQky5GKVLKj/ZV+fPnVdsISk/YYM2SKvui4w zilEHC/orBZGTkzMK2m/IUO2yGscL2iu4kMnsayzXDvrdHT4TFgqSfsNGbJFzvO6w6wl7TdkyBaZ LHBL2m/IkC0yWeCWtN+QIVtkssAtab8hQ7bIZIFbD+izDHlDZPosT5d09kOGbJHJArek/YYM2SKr ZEFG9zFL+w0ZskU+PwtOF/p0L/E5vhx4cMU0kQWQIStkwavi6bcXrdsD93P37dNvi6uZ5i9ZABmy QhZ8/9Vtcdm7o7B+7TSTP/8u9Bzs+griam1hPL/kdG9j9UXtm5yOTzc5fuTJyyMg8PiT4tzLlKX9 hgzZIs+VBa1nXPZeaj22fZ8G+7lalDco109rO/SBeTd4P5KVBeXTTZr7Jq1HIjTf8Oqc5Yq035Ah W+TZsqBxJ3H5gMZ3oXuP97Py7dNql6K/9h+5T9leFwQekDKcINNKp+03ZMgWeb4s+Gxg2nan4uG5 7oHHgxb9V7rPLxHIgjetrmH0WR7+Cp5rNAN5FgdnzILekYNgFuz/WuyKF2+veilRDVVoXVAd2aDP cvMdnq/geYc+cjIH58yC7unFQBaU+//1Uxq9xwvq3f3jt+26TzdZMAvaPQHps7zXhK8wwkB7xiYi p3Rw1iw4hsFFv1VI4zxCv01C99mMY88vqX66u71bg5SPfFwrC+iz3M+CyK9o2k1/hDjyaHlbj/+k z3JiNWr1hj7LvTFHf0X5a82qk/CMTUgeLS99lhdUu1blrzn6LLffEPEVYWBozDNLnGyX9x19lpeV ufXTZ7n3tsBXkAXzkEPl7R7Ht9YFZMFMCtfqzWCf5XKatVrcSfRZHhv50Jgjv4IsmEbul7d5kKp3 Ee+og2SBW1Wt3sX3WT6p3kVe5XjB2IDfPDdvITNH3hmz4ys4XuAnj5R36DKDcQfJArcCe25FTJ/l w9tfPvkm0O6uT0405pEBm0+Xt0ceXrsOfEX4tBHnESLJw+Vt+dc6ixDhIFng1nCt7B21ZjCvdH1B SBGnWIdGHjNmri9ISu5d+ftZ+WqjiXGEg2SBWyO1Cm/43e19tesO+3LO1PHrDp1fwXWH55IbF+eG +izHOkgWuOW5H+Gk3sVTMvcjjI6c+xFyIJdFbJ4KOu0ixDtIFri1vS0JMuSCLJggab8hQ7bIZIFb 0n5DhmyRyQK3pP2GDNkikwVuSfsNGbJFJgvckvYbMmSLTBa4Je03ZMgWmSxwS9pvyJAtMlng1gP6 LEPeEJk+y9Mlnf2QIVtkssAtab8hQ7bIZIFb0n5DhmyRyQK3pP2GDNkikwVuSfsNGbJFJgvckvYb MmSLTBa4Je03ZMgWmSxwS9pvyJAtMlng1mitGg+OeUOfZYPf7IvLc43OIg+Wd/y9ZMF0tWpFn+XO mGP59uP4+mOeW8Jkf3k76lebLJiuulb0We6M2cFvvMxzkCPJP95MKW9HvWqTBdPVzgL6LHeyII6/ u7l5ez28fFKdsWmzwF/ejnrVJgumq1Er+ix3xuxosnz3xl3dTIm+STHk20nl7ahbbbJgutq1os9y Z8yDXYDbrTzKf9BPMZ48obwddX9EFkxXqFb0WQ68Z7DJMllwDtlV3o7IgvkUrhV9ljsKdwFmXTAT Oba8pX91rpMF86mq1ZQ+y8+Lr08mqPVZNkbeHHM8/7jS5XiBi/zjzVNveb/84dhRteMMxwtmUmDf uxjts3yM5+FlwYJ7m8aAQ32WR0YePnpi8avdkN3tbXF5OgDOeYRY8o/e8j57feqp+u7vz7/7/Ove 8qE1ZrLAreFaxbYRVeqzXAyMfHTM43yuLziDPFzeqr9ynQVcXzCjRmo1ZM7dzw5LNqU+y9WbwiMf H/MYn+sOzyIPlre0bWjDIwumy3M/wknV0rmxstO4H2F05FPvRxj/4aZmbEryWHmbd8RwP8Ks2tiW BBkyWTBR0n5DhmyRyQK3pP2GDNkikwVuSfsNGbJFJgvckvYbMmSLTBa4Je03ZMgWmSxwS9pvyJAt MlnglrTfkCFb5NMfjx8/fv/+fYpv2p4ePXqUqFaQIa9Cps/yRElnP2TIFpkscEvab8iQLTJZ4Ja0 35AhW2SywC1pvyFDtshkgVvSfkOGbJHJArek/YYM2SKTBW5J+w0ZskUmC9yS9hsyZItMFrgl7Tdk yBaZLHBL2m/IkC0yWeCWtN+QIVtkssAtab+XJtcNE4yGbJPJZwhykEwWuCXt97Lk6vH8Qy2ZJpHP EuQgmSxwS9rvtchxHVmmkCcIcpBMFrgl7ffC5EBPtpnI5whykEwWuCXt96Lkxo5Ba10w2Is+inye IAfJZIFb0n4vSq7n/GF9cFH2AH5ZXBXFsbvfRPJ5ghwkkwVuSfu9LLlxFmG3e1FUzbvqTp9TyWcJ cpBMFrgl7XceZLIgRzJZ4Ja033mQyYIcyWSBW9J+r08+Nf4tRs8rZDTm+0EmC9yS9hsyZItMFrgl 7TdkyBaZLHBL2m/IkC0yWeCWtN+QIVtkssAtab8hQ7bIZIFb0n5DhmyRyQK3pP2GDNkikwVuSfsN GbJFJgvcuqtVIvLDhw8/fPgAGfKSZPosT5d09kOGbJHJArek/YYM2SKTBW5J+w0ZskUmC9yS9hsy ZItMFrgl7TdkyBaZLHBL2m/IkC0yWeCWtN+QIVtkssAtab8hQ7bIZIFb0n4vS457+PkU8lmCHCST BW5J+70smSxQIpMFbkn7vSyZLFAikwVuSfs9pLqbwdOb6Ak8ngW3V68uD1h6qOVNJgvckvbbltXw 7Bzy4ZnHp2DZQ19dORYJG61zvmSywC1pv021lvOOMIjfR/C2Wt5mnTMmkwVuSfttqm5bcFLkit5x vODuX6+fkQXZkskCt6T9NjX1MN+UdQF9lrMkkwVuSfttq3G8YDZy83hByf+EPsuZkskCt6T9HlJ9 HqGIP+g/lgWvn90Wl8e9jxpJP8UcyWSBW9J+50EmC3IkkwVuSfudB5ksyJFMFrgl7ff6ZPos50om C9yS9hsyZItMFrgl7TdkyBaZLHBL2m/IkC1ymixoXsQ2dp/L5HvZhj5YD8Bxm02kpP2GDNkiz58F h7PUF9VhocOsHDpKlCAL3jz/4ocvDz9w3xATIWm/IUO2yLNnQX+GVteeNn90fPHHT//aubrlcHVK 9fIpQ2I+aAzHe0NMhKT9hgzZIs+dBaG5V07ld70p3b84PXiXa8wHDZ31NI2wpP2GDNkiz50FoblX Tt8iLgv6d7PEfDCoBKsCcb8hQ7bICbKgd4eLc13Qv8t1PAuCj+SZeLfNmB7QZxnyhsjp+iz3f1tX U7K/259wXbD/1rezn0PYSzr7IUO2yPOfR+icOGjMyfqg/vHX+PFN9vGCKkRiPtgbQ5ogKMT9hgzZ Iie5vsC8+bX6we72trg8PeTm9OIxAA4T/Obi+rp9l+v4B62v7w7hfEn7DRmyRc7tusMEx/3nlrTf kCFbZLLALWm/IUO2yGSBW9J+Q4ZskXPLAgFJ+w0ZskUmC9yS9hsyZItMFrjlqdXpfsnImyWltyTI 6mSywK34WtEpCLIQmSxwK75W3gOh0lsSZHUyWeBWXK2aFzzFPk9FeksyVVfCd83XNquRMZkscIt1 gYfcuEGsfsTMLOTpghwkkwVukQUO8hnXi2ywGnmTyQK3yAIHmSzQIZMFbpEFDnKwBPRZzpJMFrhF FnjIveMFn39Hn+U8yWSBW2SBjxxomkY/xRzJZIFb0n7nQSYLciSTBW5J+50HmSzIkUwWuCXt9/pk +iznSiYL3JL2GzJki0wWuCXtN2TIFpkscEvab8iQLTJZ4Ja035AhW2SywC1pvyFDtshkgVvSfkOG bJHJArek/YYM2SKTBW5J+w0ZskUmC9x6QJ9lyBsip+uzvH1JZz9kyBaZLHBL2m/IkC0yWeCWtN+Q IVtkssAtab8hQ7bIZIFb0n5DhmyRyQK3pP2GDNkikwVuSfsNGbJFJgvckvYbMmSLTBa4Je33emRv o9kcxny/yGSBW9J+r0cmC3InkwVuSfu9HpksyJ1MFrgl7ffS5KrJ8u7m5u01WZCcXD9atohs8E0W TNf6fsuQW02T7rZRV9P1zVVjAXLVncexCiMLpmttv3XIrQ2SfYT05Lsa/6X422Ep0PhrLJkscGuz W9Ls5FYPObIgPbmuMeuCRbTZLWl2srUuoM9yInJ1dKYY7UQTIJMFbm12S5qfXB8vOG6l++3zk7/T ZzkV+a7er585ll5tMlng1ma3pBTk6rD27va2uCw3VPopJiI3FwZxZxHIgnO0tt8bIJMFSci9fbJX V5xTTKqtbkkLksmCJOTGKVzHsVqyYLq2uiUtRKbPckJy80qjyF0EsuAMre03ZMhJyGSBW9J+Q4Zs kckCt6T9hgzZIpMFbkn7DRmyRSYL3JL2GzJki0wWuCXtN2TIFpkscEvab8iQLTJZ4Ja035AhW+TT H48fP37//n2Kb9qeHj16lKhWkCGvQqbP8kRJZz9kyBaZLHBL2m/IkC0yWeCWtN+QIVtkssAtab8h Q7bIZIFb0n5DhmyRyQK3pP2GDNkikwVuSfsNGbJFJgvckvYbMmSLTBa4Je33wmTPg3m7791eNTIn kwVuSfudkFw9X6t6uJazPUonDLSrIUgmC9yS9jsVufnU3TfPv/jhS19Pv6PaYSBcDU0yWeCWtN+p yKF535ra9ZP77UeetiHC1dAkkwVuSfudjHzcQ2jO8+bMLpcKned2d9VqrqZcDUkyWeCWtN8pyeWv /tPxgnDXxMEdh9YPxauhRyYL3JL2Oz35kAjFXRw8ednpslw19zL3EsiCNclkgVvSfi9BPu0GPHtd ZUFjx6A13btLB7JgTTJZ4Ja034nId5P4L8XfjpO6nPhFHQD1nD+sDy7K1svdhsscL1iTTBa4Je13 MnJjJ6C8vqAxsxtnEXa7F0Xj7EKzsSLnEVYlkwVuSfu9JDni+oJ2FnB9wapkssAtab8XJY+HQSsL uO5wXTJZ4Ja03wuTh+5H6DZc5n6ElclkgVvSfkOGbJHJArek/YYM2SKTBW5J+w0ZskUmC9yS9hsy ZItMFrgl7TdkyBaZLHBL2m/IkC0yWeCWtN+QIVtkssAtab8hQ7bIZIFbd7VKRH748OGHDx8gQ16S TJ/l6ZLOfsiQLTJZ4Ja035AhW2SywC1pvyFDtshkgVvSfkOGbJHJArek/YYM2SKTBW5J+w0ZskUm C9yS9hsyZItMFrgl7TdkyBaZLHBL2u9VyIPdls0fbrUa2ZLJArek/U5O9ndbtsJgC9WQIpMFbkn7 nZY8rduyEQby1VAjkwVuSfudluzotlwtG8yFg3w11MhkgVvSficmj3VbjmultuyYIZMFUyXtd3qy 3W25NeWbYRBeGGyiGkpkssAtab+XIoe6LdcNEU4q1w9kQRbkPLPgtNU09ikzkrTfy5GD3ZYDuwIF WZAJeZksaDTeLIrW7qT17pE+fGtK2u+k5JFuy83jBS1xvCAL8nJZEDiAZMj8/ZGHpP1OTB7uttz5 pTC8i7CBaoiRl8+C5jno/kmm5sZyfKXey2xtXTcX19flEevgmapkkvZ7eTLXF6iQF8+CVhSETzK1 Dz33V5iHdKhnvXWmKpWk/V6BzHWHIuQ1jhdU09g4yVS/3N5bKN9RtF41z1SlkrTfq5C5H0GCvPw+ QmNlYJxksrKg3Gx6WRA+U5VK0n5DhmyRV8iC+l/GQcIz1gVLSNpvyJAt8qrrAuOcQsTxgs5qYeTE xLyS9hsyZIu8xvGC5io+dJLJOgu1q0OhvRIInqlKJmm/IUO2yHled5i1pP2GDNkikwVuSfsNGbJF JgvckvYbMmSLTBa4Je03ZMgWmSxw6wF9liFviEyf5emSzn7IkC0yWeCWtN+QIVtklSzI6D5mab8h Q7bI52fB6UKf7iU+x5frh96deWkgWQAZskIWvCqefnvRuj1wP3ffPv22uJpp/pIFkCErZMH3X90W l707CuvXTjP58++arTTKyV1fQVytLYznl5zubay+qH2T0/HpJsePPHl5BAQef1Kce5mytN+QIVvk ubKg+YzL/kvVBC7vS9rP1aK8QbncfTh12nk3eD+SlQXl002a+yatRyI03/DqnOWKtN+QIVvk2bKg cSdx+QjMd6F7j/ez8u3Tapeiv/YfuU/ZXhcEHpAynCDTSqftN2TIFnm+LPhsYNp2p+Lhyfn9Rxsd NPL8ErJAktx4elH1wPu7fbbvzccdZTDm+0aeMQt6Rw6CWbD/a7ErXry96qXEUawL1MmDrZY7j8S2 n322lWrokOfMgu7pxUAW9J+a7z1eUO/uH79t1326CVmwKnms1XIr6gfDYAvVkCLPmgXHMLhonA3o n0fot0moTxo0H5hvP7+k+unu9m4NctiWyIJsyEOtlnsPvC+GrNhCNaTIKtcdZiRpv9OT3wy2Wu7s Ag5dNrKJaiiRyQK3pP1ehGy3WrYOB322+pghkwV+Sfu9IDnUapksyJhMFrgl7fei5De9VstkQcZk ssAtab9Tk8daLXO8IF8yWeCWtN/pySOtluNb3m2iGkpkssAtab9XIZtTnusLciKTBW5J+70O2QgD rjvMikwWuCXt91rk0LQfjoL1x3zfyGSBW9J+Q4ZskckCt6T9hgzZIpMFbkn7DRmyRSYL3JL2GzJk i0wWuCXtN2TIFpkscEvab8iQLTJZ4Ja035AhW2SywC1pvyFDtshkgVsP6LMMeUNk+ixPl3T2Q4Zs kckCt6T9hgzZIpMFbkn7DRmyRSYL3JL2GzJki0wWuCXtN2TIFpkscEvab8iQLTJZ4Ja035AhW2Sy wC1pvyFDtshkgVvSfq9CHnyAkfnDrVYjWzJZ4Ja038nJg02Wg7LCYAvVkCKTBW5J+52WPNZkOSwj DOSroUYmC9yS9jsteajJcvmPU0/tol45GGkhXw01MlnglrTficnDTZarPimd2R/unqRfDTEyWeCW tN/pyXaT5UZ/tWarNWthsIlqKJHJArek/V6KHGqyXE/5zuQnC7IgkwVuSfu9HLnfZLnRabG1G0EW 5EEmC9yS9jspeaTJsnklAccLsiCTBW5J+52YPNxkubkwqK8/4DxCJmSywC1pv5cnVzO9NeXbVyJw fUEOZLLALWm/VyCXGdDYW2itBbjuMBMyWeCWtN+rkMvZ3rzSqNpF4H6EXMhkgVvSfkOGbJHJArek /YYM2SKTBW5J+w0ZskUmC9yS9hsyZItMFrgl7TdkyBaZLHBL2m/IkC0yWeCWtN+QIVtkssAtab8h Q7bIpz8eP378/v37FN+0PT169ChRrSBDXoVMn+WJks5+yJAtMlnglrTfkCFbZLLALWm/IUO2yGSB W9J+Q4ZskckCt6T9hgzZIpMFbkn7DRmyRSYL3JL2GzJki0wWuCXtN2TIFpkscEvab8iQLTJZ4Ja0 35AhW2SywC1pvyFDtshkgVvSfi9NrlsitDolzUA+Q5CDZLLALWm/lyW/ef7FD1+WPRDqB6LPQD5L kINkssAtab/XIhu9kWYgTxDkIJkscEva74XJra5pzr2E7VUjczJZ4Ja034uSGzsG9bqgbJhS91Oc QD5PkINkssAtab8XJddtVQ/rg4vmuqA+lDCFfJ4gB8lkgVvSfi9LbpxF2O1eFI1WaXc/efnkm8Fd hs1VI3cyWeCWtN95kMcXBVPJUYIcJJMFbkn7nQHZbKZ6NjlWkINkssAtab9XJzfOLIycV8hnzPeE TBa4Je03ZMgWmSxwS9pvyJAtMlnglrTfkCFbZLLALWm/IUO2yGSBW9J+Q4ZskckCt6T9hgzZIpMF bkn7DRmyRSYL3JL2GzJki0wWuHVXq0Tkhw8ffvjwATLkJcn0WZ4u6eyHDNkikwVuSfsNGbJFJgvc kvYbMmSLTBa4Je03ZMgWmSxwS9pvyJAtMlnglrTfkCFbZLLALWm/IUO2yGSBW9J+Q4ZskckCt6T9 XpZcPwh5bvJZghwkkwVuSfu9LJksUCKTBW5J+70smSxQIpMFbkn7vSz5kAW3V68uD087pYda3mSy wC1pv5clH/qlnZql7R+A/OrKsUjYXDVyJ5MFbkn7vSy5tY/gbbW8uWrkTiYL3JL2e1ly+3hBbJOU GPJZghwkkwVuSfu9LDm0Lnj2mj7LeZLJArek/V6W3Dxe0GjAfvwRfZYzI5MFbkn7vSz5sFdwW1we FgKt8wj0Wc6PTBa4Je13HmT6LOdIJgvckvY7AzJ9ljMlkwVuSfu9Opk+y9mSyQK3pP2GDNkikwVu SfsNGbJFJgvckvYbMmSLnCYLDueVT38fu6Zk8r1sAx9s7JSOXtLilrTfkCFb5Pmz4DAPL6rDQodY GDpKlCAL6lNW+29/O3MaSPsNGbJFnj0L+jO0uiel+aPjiz9++tfy9/fpsPLhhFP18ilDYj4YPZyz Je03ZMgWee4sCN2MVs7Hd70pvX9f7/6V/l2uMR80R+O6TzZG0n5DhmyR586C0AQtp28RlwX9u1xj PtgbRv+615kk7TdkyBY5QRY070ApX/OsC/p3uY5nQX2wsH2ssHPwYhY9oM8y5A2R0/VZ7v+2ruKh v9ufbF0wNJ5zJZ39kCFb5PnPI3ROHDSO5Nd778df48c32ccLqhCJ+WB7BNUF76F1ypmS9hsyZIuc 5PqCxun93p2q5QmC2+LyNGFPLx4D4DDBby6ur9t7++MftL6f6wsgQ44i53bdYYJzgHNL2m/IkC0y WeCWtN+QIVtkssAtab8hQ7bIuWWBgKT9hgzZIpMFbkn7DRmyRSYL3JL2GzJki0wWuCXtN2TIFpks cEvab8iQLTJZ4Ja03yuQ6yu/fDeKbbMaGZPJArek/V6c3LgIPKorQjx5uiAHyWSBW9J+L00+43qR DVYjbzJZ4Ja030uTyQIdMlnglrTfS5PDt7DTZzlHMlnglrTfi5Ot4wX0Wc6OTBa4Je33CuT6AfmN 8wj0Wc6PTBa4Je13HmT6LOdIJgvckvY7AzJ9ljMlkwVuSfu9Opk+y9mSyQK3pP2GDNkikwVuSfsN GbJFJgvckvYbMmSLTBa4Je03ZMgWmSxwS9pvyJAtMlnglrTfkCFbZLLALWm/IUO2yGSBW9J+Q4Zs kckCtx7QZxnyhsjp+ixvX9LZDxmyRSYL3JL2GzJki0wWuCXtN2TIFpkscEvab8iQLTJZ4Ja035Ah W2SywC1pvyFDtshkgVvSfkOGbJHJArek/YYM2SKTBW5J+70eef9Ao++/cjRRy2DM94tMFrgl7fd6 ZLIgdzJZ4Ja03+uRyYLcyWSBW9J+L02uHnW6u7l5e00W5EwmC9yS9ntZcqtp0oPLF66m65urRu5k ssAtab8XJbd2C9hHyJ1MFrgl7fei5FZjVbIgdzJZ4Ja034uSg+uCgj7LmZLJArek/V6WXB8vOB5D bBwvoM9ydmSywC1pv5cmV02Wd7e3xWXdR5E+y/mRyQK3pP3Og0yf5RzJZIFb0n5nQKbPcqZkssAt ab9XJ9NnOVsyWeCWtN+QIVtkssAtab8hQ7bIZIFb0n5DhmyRyQK3pP2GDNkikwVuSfsNGbJFJgvc kvYbMmSLTBa4Je03ZMgWmSxwS9pvyJAt8umP3//+9//5z39SfNP29Jvf/OZ///sfZMjbIP/ud7/7 97//XVRZgBC65yILEEJ7kQUIob3+HzLlRAIKZW5kc3RyZWFtCmVuZG9iagoxNTIgMCBvYmoKPDwK L0ZpbHRlclsvRmxhdGVEZWNvZGVdCi9MZW5ndGggMTI3NAo+PgpzdHJlYW0KeNqFVsly4zYQvecr eBuwSoSwECCRm7zO4nEcS5NKVZwDLcESyxSpkJQznq9PAw3akqWJL8TWBLrf69dAxChj0TLyzWV0 MhtfyCinRuto9hDx3FCh8ygRGc2NimZnf5HT9nnTF3VRPXdlFycyFaR5cK0k/crixMeiW+HURZwr sq3nfdnUuHb17c9EKA0DxjjhMv579nl8wSPOqVHKnZpwoaliEo5V1EDrjr21D7a19dx2+MOOlwwM JZWp8YacOoPofPY2mCylhsOmWUZ5mnnbT0/lvIghOkOuy8dY5KSpStfcCa3jNNdkPsLlSWW/Y++k bJ+3aOs+T94gJ0W9wPWzddm3z9DPGfmyQpu26LFTzmNhyIpiDEK9eicg1gxiZd6xACAz5OEVPDcq 1mX1jH0A8gAKzhRNuQ67jDwSiZSccm4AVwYQ535JMJaPkJBuew8u93YRSGxwOpApyfTjJJHYnTfr jYuM2L70Tvn9uQBAIUmAQZZq3P49EoyhXHFvO7UFRCdMSn77cG3LaoSDL0Xb9TasXDerYR6BNopc bT13MPXR1j9sfQRUniuayzTAcV7fxkKTbzcziEYIskKQhdwFGUbdJlaCWPeZl3dCZfNYSVIMAe8D nioqcvV/gJu3gBexyMhTrCBpyqq4r4Joij5IwezAJangw+6rvt/8Oh7but1uegpcjIEaOT7wKYGo pZZ7hMj3COECfFZoPKSwlBpTOBtS2GAK52SFq54MKbNBSW7OKylDJZlBSYrMj/GjIT4xpOvbyqJD ZYF2h7rDlNcQZfrCgPdhQBs8G9DOXtD2HAkNpS3bo+gYAQCh0OkbAlzi0LIoH2m/XbbFD1r04+2m aopFNzZjcz8+R4o2i4dDcqBUpVzskZO+S04qKdcol8ttuXAS5Zqc2LZv6nKEo8+N05HkGTkr7NrW YfqrIyyDZLeVm1Dkxg2t7W3bjXAGWYQfL8uqsh3+94er3LijJpOuQ9rtsdKVAwMvKrt1uikWZePa ZdFv66CKwWy3DPmUycl9rDixVZ+AJwlUuDiBsXNXmkGlcqcUHqQAT2kmdzKAc5cBOnQPMwCm2XG9 Za8bBbZbF4uPg9aNfbRNTZt2eUR1gqVUs/06qN5lVitgFm9WJDA1eSAQ+54c1zlti3KJ3SnF9kto T6tis/mJvnLDQ0AXsbunuh7QZYhrWS8d1AwPUYBV17cvxa9YoyXcuk6Zvj4643/LfhUqf9h/V0U3 7pTJ9eTr5ACi1JWYoZpRrHqf6vBQmJ5/MEOFfMICsl370uheCZlAs+GpcXV9Og3Gm2LpcxZmNUsA WJyebloIz7YjXOLG5EhGouCxwPbLo36XpxxeDfhouIKLyd3Aity6oxjUyNppY7voUHSwcrpqy64v vXzA4NaGogkF8R4v0Da4xoYiCn9N70SWtTb8NA27z1bNujt6vQmVw/UmAqAzf2FLSS4h8EWxqnDk 9YMCDOa7bA2aOnxVSU21yX5KFugr+wlbqTJyly3xypbcZUuaRGXH2XK771GiIwOOSeeYFjQDxSRC MCpN6v2bbDZO1JCqi/I7hpLukKgpF1B44FpmHLU2i520sBYYGSrwfrIyuJqGZD1tPMV921To78lz b8Pr1z9xmxYHXxv3JCELfDcUr8/eG+DBDhH9E7lrRXtlspc+Tw08eyE/c+BHR/N1NP60TqOzJvr9 l/8AFCfp/wplbmRzdHJlYW0KZW5kb2JqCjE1MyAwIG9iago8PAovRjMgMTUgMCBSCi9GMSA5IDAg UgovRjI1IDE0NiAwIFIKL0YxOSAxMDQgMCBSCi9GNiAyNCAwIFIKL0Y0IDE4IDAgUgo+PgplbmRv YmoKMTU0IDAgb2JqCjw8Ci9JbTQgMTQ3IDAgUgo+PgplbmRvYmoKMTQzIDAgb2JqCjw8Ci9Qcm9j U2V0Wy9QREYgL1RleHQgL0ltYWdlQ10KL0ZvbnQgMTUzIDAgUgovWE9iamVjdCAxNTQgMCBSCj4+ CmVuZG9iago4IDAgb2JqCjw8Ci9UeXBlL0ZvbnREZXNjcmlwdG9yCi9DYXBIZWlnaHQgODUwCi9B c2NlbnQgODUwCi9EZXNjZW50IC0yMDAKL0ZvbnRCQm94Wy01MyAtMjUxIDExMzkgNzUwXQovRm9u dE5hbWUvWFRJTUVIK0NNQlgxMgovSXRhbGljQW5nbGUgMAovU3RlbVYgMTA5Ci9Gb250RmlsZSA3 IDAgUgovRmxhZ3MgNAo+PgplbmRvYmoKNyAwIG9iago8PAovRmlsdGVyWy9GbGF0ZURlY29kZV0K L0xlbmd0aDEgMTMzMwovTGVuZ3RoMiA2OTE0Ci9MZW5ndGgzIDUzMwovTGVuZ3RoIDc3MzkKPj4K c3RyZWFtCnja7ZhVVFsL164phBZ3aPHgLgGCu0txLQ5JcIJLcHeHUiju1hYvUqDFHYo7La6l0AKF QuHP3t//7fZ8/7k549ydcZKbPHPN9b5v5porIwkTnZYulwzUxRqm6AL35AJxg0SBcuqyRiA+IIib F4uJSc4dZuVp7wKXt/KEiQJBIiIgoIyXLZCPFwgSFOUXEAULYGExAeVcXBHu9rZ2nkBWOba/uoSA Ms4wd3uIFRyobuVpB3NGikCsnIC6LhB7mCeCGwiUcXIC6vx1igdQB+YBc/eGQbmxsEAgINQe4gm0 htnaw7F4/gqlArdxAQr9qwz1cv33IW+YuwcyF5AVmZMNiEwJdYE7IYBQmA0Wj4YL0g2GzPJ/HOt/ k+o/xRW9nJw0rJz/kv97UP/juJWzvRPivztcnF29PGHuQHUXKMwd/p+thrB/hZN1cfofNiqeVk72 EBm4rRMMyPuvkr2Hor0vDKpl7wmxA9pYOXnA/q7D4ND/jIAc298BeIz0VNQVlDn++5L+66iWlT3c Uw/h+o/uX+1/M+g3I8fjbu8LNOHl5uUFIRuRz3+/MvsPNwU4xAVqD0cuBVgQaOXuboXAQm4HksBA fxDQHg6F+QJhvsjIPNxwF0/kKUDkTAKBNi7uWH9dTwEwkMcO4WoHg/9V/1dJBMjjAof9w2BeII+n j8tvBiHZzh32RwcfkMfGxcv9d4EfWbD3/qNDAMjjgXxH/2ZBpK3MbxIC8sj9JmEgj/w/JIR0V/xN SCfl34S0UflNgkCep78JqaLxDwkjVbR+E1JF5zchVXR/EzKZ/m9Cqhj9Q8gN5rH6Tcg5Qf4hEC/S AvoHIqcE+wP/GtEfiPS0/QOR47H7A5EZ7P9ApK3jH4jM5PQHImM4/0YQMgb8D0TGcPkDkTFc/0Ck r/sfiPT1+AORA/X8A5ExvH4jH1IZ8Tf+z/WXlXXx9edCbgEXH3JbQCB+EaAQmDfwf23Uh9u7ecFU 5JELxssrJCjydxXi5e4Og3v+/XmDvLX+zTb2yBsRBvOFQbByckntH1hwUnNcWJ5/mKM3bB+f18Lq LPuSBb4sJJscOsV2QudecIiOdNQ6X8T9eaSV8OKKlVYqpj5IXSzlw6V5LwJB8WqVjN1mtMNk80L0 deIe1xRxszEqz/sTWEKbhUkjRyHY3xwdf+0btNDTteusn4787c3cYFDXEvSVMUfX8GLjdtzOOxRR yJyCj1oaR57FZd1D+IQc1Jj4CaKOjzjQOYw/8k7/uzSXfvBMk7LjXgrh1MX7N6a0SvDdU/P66ZEj 5myj+gwdwheNRLcTs1HB4smdaNgLpIv3y9TjCmqPNfwoXjQX7Lnu+qBq5+XlMMxTfIhgnNNnZE8o TFB58x0lwyy7Lbsid08Z8Mbx1y7DuSK/mzwPjKHscoJ8SKQC4wMTMTf9QObQ2Ottg5AdcrfYj9dJ wbgWz83BIq6NaZO6WHZjBnVoZp/eA514PbuOHomsdhS7l++y3fgdcppUtO/g+D8te/7JF4gDZntx LLkD/URf8E7P42J/rH7sge5BxWZ25WFxjv3UW/r608lbIzYiZa/MR0uEWqMPtYkwXVcLPMWOvspf vkn7OdHvbZSdG39Ka2lFagkQsf5gb07ZGoiJh79cA8uDGQLjbLAP3nyN27Fwa+3wFlFHsNluUy6i isGDEySyo+d2nuq+53jHF2mSAfVoUubv9I2WuNoe3LW7v2eqfpdYSpLsqZaHzjg/GhbK6M+rM2Zm 8/2s46rMQapJ8dDIf7GLl8lbZ+Iz2Druy6dFVjHjacp4kpDXjItZL7CGirYk9cS3t/qS83fp+ick 4w54r1IeUEIwbIZjLC3tlg4YMo8uKBtXgArotxKYs64Ug2hF6mnv7lg6PQkbIZVJ/JUHlajGvbR0 exL9HPxiqYnYRK79yh6lKfRcAAqbz+TMRF3OnDHP45Jdu9FSSOA7mNSnwJoXtuZJ9g/o4V+0iMwE e+i6koFQT1l5NeJTPovYnOQicxISwhyFa+APiV4VF+fPa/JPip7QIChVylhtBvOEPDO67oMp5WUI O0pvOW7cET/ZhH/mbK578wBnXUPFNT6jybmFct8URD9QYG0pzNk+paWNWE/jcrJZuLzPLE3jbxBx ziVvNSHmuYDFis4UUa/EbNvfUh/P0ZhIvf5FI6mVqiyyvjM3/VYqfL/iuTD/100Vdl6QJt9m50uv ZPbOSgLvJydXUWci6CcTbFuFzMFlDyvc3YYytN6OygH30ro2W0ewnL4CQ+ljqAfKNpxKMNNbwILL Bvh7H8Ym4ZaDb2VfiPfcXqZgcshf40dL1SqmYC8quGTFSeafQX48Kbe8zD36utvJZJ1+dBPnd+NG LpnFfHCoPcKlClAI2l3h8mYXj5XHjDIShLxNnwwfNCYrJKJs9WjkjSilF1iCkNztaxqIXy0tgATd FoVtLFpkoHh2cTNJgYtvO766H99zF1ngNQ4wjFhqvHb0SRI0gergmOWuir8XYU27VfbIcuW93V+2 sA17izIN1XpxX+qQZKoSfvaoTZiWBRSST5xyj4vL1T7ywIqfNmlv9ocmq/cMFvQ4bpj68CTrR0V4 fJdQbBLL9cyXLksY4SOpG3Uz35cV1RC3yz39idQ7XOvZOUQwR+S6IYeub+iHQmdFAwt3kzx/LVTe 7p26CU29GgUve+pMRmAJwcErXLg1N9lxXr/grDJgoiwqmM9fe5BB99kUqajLEOuqmx2ClTXp0XoD ZAdRSpU5+aHO21iJzeTCwF8MlLDIMhszsWspZeTCkXjAXHsVsrDVUMpZzC7bU9VPytMpTZVMIZD6 bHRkX1pLd/R7VKMbKnlBjJ7gpz4tCFUwRkC1ybZJE3dXaNwzhWMcuGkW53Yv/ZE/vsOi6/JM78eT oDCbUr1b5UoDudQ0yzwSUBdVO+XNcSupIuwgQNUMEMAqj4nTiEYxyv2w1vhBC/VNBM1J06EHrx1W +2FvYKtjLmpeILbtD+NPUtVk5Y7GrD9bL55NgtvwY3/5LyqcoTFVua6qRA5IHPR/2T+Hbzh0tJVn OIcwCnOOXmtt4DWL+ilZ8PqYOTw+3fyCj5KvkaOWfFjL16KhKdO7sUYiz1pJC+2q9w4cRJUrFgxE 6EDCE8xBXI1DDBdpgxTT5s0BabJXrlavS/Xw3xPStu180D9oCyGyG2dAS9/raCg2dKk7SCOWrReW rVCaMFN3AluRC9R3+308CAyVGd7EaOEYHK+ezn+keUbFMDz5dRr23sQzi39HjTBsFuZYT/XQNhb4 6mn3yGyKj2w92kS2zeZ0p6ZrJYN66RmITQDgq0uYGsCHcAu1PlQ2M7qOIh9TG37NJGep7zR2azVa ZpDOrMXdvmWmUtLVHvD6pbW7WQRiwSTw8+blSTWAF9HMjOdhdMn5ll5hI5C3G+45Y/xO0LOcbx7v AHPr8xHcmWil+9Gj52sMwpD5GWxiA6WD/BjpTXpoSTg+x2MzfdWNt2wDgckY+6sekk1bOxes0rrt O4vqAyFDAB1SVkJ5wiNMosEfGEuV0CAbEMn7vOmN8wEUgiMFwIrPJ9rncScdnJ+K/WDjhD6QL/6Y LnELXmXNO8rcjzKSidmDyCTCacKL3myha4bC2mnKjKJlR3+WJAidNY2iZq6T0W2nXT3uFa98xkMW 5M9mYRcv4u1ZPiMWEpmiVYznR/mOVNq2RYogilsjk2mvyP+zQyUbyzrkLDJ4ftH7Jp6FIqTSMF/0 ijJiRUAh4fo+vNuEGdoVGV1vt6WLa1KxoAShF94R/f5TPqZ096xf51VwVchFvpkuojBK2/5WIxST yIFm5PmpRpWsCDwnunmdTRVFoWdlXGEldop1KjOo8mcohpXesxjSPtgvbfcYSnQDPgkxhmnxeU4t LJnOQzOv3BYCwIrTG6WCq6/2r6bvxvzdssNjhu8e4nN80LRAC9u6LUO8+FmZdUkZQ/0pKyiMxBzh oT7axrOmWLhJP4zH4/d6pFyHRjpgt8ma85Nl1Jh6mC6tXIty4hBe85VnU9ZLaw9fdpBCfrs/9jwz 3Dbv3XzDFP2aSlsvlxE3eiU4kSj0vX7NohRa5Hhzf3YqzjuzFm9hmrtwhiC0Ru5oDuzDCkueRNZe UabvJ/slxXfPO5aUXT6v7iDenBHUdpL5UF7gEBU5fENwLG0B0dAM1gG37TRKyxVd29pGjOqVy65L kofmPFzwQ+WkhzrU75wIoTtV3+/YRUB5nt0dYhPXM7Wy58+6Cy4RxqANFttc4/UHZQT54CE8bP/C 5wJNp4KLtUlUTBx2LWzhjUVl4wIXAs8fZwTNXynwLIVU7kjmMofl4PK+OYyYN8luw+Kib6ZImue5 JU150Edo8cSQW5In75v44K+BjOlndH6OdMdvqPhFAaunPzUlpGXo9/NFvpzfGn+VTiVSqQcN4l9+ xcRvwivx141+5BjtmP/4JHIpnFpuUed7DC3haR9pNUcFHvv9UNQIzTen+Y1ulKIaPwym2zbHZbCf 48BUVVHuWBVZAW7UlNcp/zF+d9lqD+tnON87w9J3t4xeSWfmXbe2zG51lTTo1A0OQkPPF705QQam j9prTnIfzr7JjIc2dDeVe2UXWCrSvllyknJE41k7Lc1en+/CphHK4LUfUf0CluZa78PqYB+n/rhe F0pQPyou8CuPifDk4vohHiaFgSbrgUHpPZ9XmHsKhhsjgfBUU7Ky0PJiAXvm3KgIIWPqqpIB5QO/ bB25kh/LkSSl7cMnfGJUlG8yd4z7ygXqljtMA8+w+M1kLqYkdE41yHBVXvPYmdq5Fqig1VxgXLPN 6E80apKdZy/0bLC42QJ5tME/9IzSnIEsxHITDiuf6s5yK1p1XdLqyDJRk/xP4LIKy9xnGpxCa4vF 6LeQtxYcHNlU8n0F78dMYjpHrTfCaPuyRLMA6Bh2+XZ4EUdWgeOZnuT6zazyWegc2XxlNpDoO6Yx CrPuVLC/sv0SN5r89DhmtTp805bg5W49rbo6q19sGtvVeJNBoleYca95YgjzfOLRFyirHqk8fwgv cfxKYcNo2Bo2yrnF4YC1bnq68JQKCiN72RjmPkbByW2CTL7e7vSiowtGuY4lnqAS6+qsDSPGRZ+C bhMp5Y863A/s1uYeV/ZFlenDXWgzz2lYMUiDjKVemxWe1YVIPXGzqu5uDqMz+uF4haFjkz8Vv6YS +BlwiG+Y/DMExVa1jTXqezrhL8mP0UeECvENCg8VBehNjTk1mVn2FGsITEIzgMHMw+TtQpEacInG 5mYN/HFsVbwVQvEcjJoOzK3tNqIm+7blk/c8/tEVID+AYV9y8PMgwJMImcuRl4x17/pcqii8HyYY cud0OCnakeW+Adxo5Sl3OqmXmks5SOp1rdVv4mdOKHV4/GJ3GcWuwqfehvg/HHffKvVzP9Znynux y48JTnhbz+wZTmuMh6655xMGM3xY01QI9em50vGZf48VFkNhsW+8gwe+BXHKBJK1dfdWPpikxLZN ZY2Sikivj85/9RKThDWL7w6dIxYN8CTFKcNtFVsa8tnDFD1nW4+NxLrcYsjXlLweAbyWh14fUVKj TvFTDw2hP5ze0U7AvxbPdn1DsRB1Cy4dDFnSjQkWDm2Va17usTNy0d9n43MsBq9n5q1/+mabckgQ VLzKEgkYDY+tDzB+VTqWsSNQ7z+x4OoL0nQtdFrF6+8qI3clW4qixpRd68oWPrWuEZbQ85XweDol pOb2DieDZbV2DabgN2peRELz8wEdudfeplXJl7ct088co6wqoJosYTi3Y5leIdmnRp8RSk2hAgup 8l5Hd1GxfCtnd3I1RtjHmW4ftPxLO34+HWngDH2ixrhP7bfy41YMFv1xhulq6jipNZRjTJpMYQ69 /xGjF+xDpag1lEdM+00c/cbdLdcKaPo8rvBaqh2kROWsRE7hMcpb7iD0jnvq+COpFqCFAecNmHK3 7/7+9WM6wfRhFMajU0Cktjfh2CzA9VgGSzzPlEl4WZUYAa68qqZ57xWLWbOcER5M6ywlVtK83Z23 ayHf64a54mOgDThrywHVS8wOtQPOzRtt+2yvDh5b24H3HahomklxXmDvlFUofNwitr6t9vVpcovg CKyDMGQ0+ykCouDYXpXmKG7m4VNsS691s9ouZiir+3rzMOonQhl/TKaN4ZftqblARzx/fRVZAhjs hrGCqCodf43KLEh+DxwVIDTMzhXyNAd+CL0OAH5r+NIhnBl3U6+CNoFOKn5RhvX6NrrZuelS7tRy dJHmAmWNke/JFEM1xwiCyrQst6+7AuBMES/gZ/qLP7bcoYOxa/7Yc0A5EIMu8/zZ+IaYr4doIHMR 72XIS5SEdYqvzLfik8NWASWzmNrGTifFlY6Yw3PZNLURWfCpoeSjZblZNEmTWokEzKPXDHOyLq/E CXywdq5XKIhXbjZ5bFl+zoZnd5PjaRxYqxXQ+KOvdVFOGrCYURl3KCW9EZHaOgEYHEzLEAYzlYQ+ bslmoNQTllhE750DWe6SCij6hOJMfBLtB6cpEtxki3x5PHShq9HDIKAJxr6g90svQDU1zZtaeKt1 OfJrQPT6o2FIaqRyBPCJwigcHrEt66om1ym0oxUcRdGXhz8bNtHRFLih7uq1NRqXV7Hy0xkIxYJ+ 90Vg1DswCup0bXi9LB9iCVfieA//3herwaGjnlmyQFQAF5KSqMXUibFewQ1C7D1Lt1cA72KYblet PQ26i8xiE9D9woS9dUUr1YMfg31xE1AmoyE/XfLinIfCLkbXmw4D725vnF83oZ271L/715n4ivPH qtFS3e5qSP1e1uaGDEZU1v4Ty3d+uJpbDHHC6Fw8n8jepbxv6CTaU3F/TLlFdsfQ/BH+7YV+CsIm ZCnvIDrtagi4MZKIKTLpmBHOV7+/Z1cb9Ux1QoWifAf1vnCxnq0MNQBPYJskMpW6c1c3aXUkQalS p0hsutbwnNmk7d5nEVK61Zsm9GGzVktkiSEFKtUGFZvHs92ADq98+m42jS1OifpMZwISHvE00I1b PZayO94wHsNSlnzlbU+1AdbkvRTjm1wFXbqYRspzLcQox7fExi6G0JT95RJAxiztcBxqLFGu67pu SnTVxJlLAJZXkhvwlwTw8iVYo2NZgZLISQaw35m67QKm9eI2fBWybcJx2TRDTqg6Nri5xsc89AaN NTPovOFTl+++0EbsM8uIqpLKyHuACY5fKF4Zp/x2w6UcgaldckK2PmU8uuVSq9mIcZIjQf/1XGll 3pEdY9i+sACd+BO6EbThkvBtKXPC5i9Oy8gfksAvvo6nLBzoTy36fEqu5HMBRdV2n8BwMpS5ffm0 LZBC/08HQ9djCFlC/hQKaoRFNS/DVIiQVED1D+cCrYgBE2l1gRPQN1G+hKbtHHTmRFYrn9Qk/a0H J4aMeF3M06rHb6tMnAd8om0ymb0552J9m+zRzkwN1ku9s6W0L2sK94ohcZY+VvL1nbROpEwr0Uk8 ucGuLY6vtbPoCp3HYssempZk57y4Hk1xNdR/KjWnvPwwLSMxX2VLlB00N7sqLXEdUZJHxSMgXUnJ GnBz1oXn4vU56eao4DBuA/Ddx6xnuLm12UC9ulkF5RvowY1+/m41GliS/Ste8bzoHnxk1EXmrOGq pULVVNamcaTU9hfJ1UStY638U5qBr6u8ew6vPAKjXvgH77dN0FN5rKKKph0ZN+a5erC9sqWsRTsT KKKWTm4q43xkwVP8rBrjCms+d3tDmnpI5TMGvusxF3r8tY2ffnv/QWTDsM7NHgLcGdXM9WuzBHd5 BjPPLoS7dQ4bOw5LGUfUsTrFN1rFICjPZZvGg+487gxfIgNX7Mo7/Di08sN+15A2Ayx2PkqeVh2C ejuFHfm5UYzgySzR7UvgS6sDyfcDfjiDBe1Tlh6dFC+bKVU+9kc02mfK90sTMzjenDPHdJQERoYG pRoO0ymef3JUHKb1CDTbhjgw9lTd/2y+kZhMn00lxMDc2fbaDwHohRI2pzatvjafmyYzjh4DcRL0 i3wxwtWNmcsfYMJWfdUlw+wOyaHMmJqP2mJU3gxDfXrxGlvq4+fUg7xlPAvrHSP5WEmXJi4yeW/R 9HCU3tEXH6daLYlxlYu5KZ3DLPjGpvQLanyGJJO2V73afGs48r/FXWMMiWoqYYDu6kQ08SpPKyfI Wkd1GtY/5ye+2rpDiRjgLGdgfABZZXlXM5pCVA3e/06C2w0tIgYFHPX98Ih7E1bItbSWIIUiP0B7 OfajA6DmLaAzQMV3JVbUC9AwwMZeUMtGAbSHhbgztgwb8zuqOWCZ7H00fDgWoz/2Gufwxx7+ALUl fKicmuCBcruyXI9B2228Y/oJdSy+xjbBY+2zGcH1ayry7oqSc9pR9VKsJS7zHv0Zy00eYuqtoW6m iIhQ2iXo7CtKbGjd1IOJLvu8vfi9G8obaeP8nkyrkTaNL2XNIT86vREmNbSh7+OVUF9WvedAN/6e LkT84JxUr0+Wl6b2lqpX2z5vWc5lmIRGP21YeJCtoOiejToygAiSuGnKxcdBRWrc+KiXSuH4qSMG xZIbq97cM95OuS8311dO7YhXJTe5KIOPuqEnDRvO7EzGhJWdV0GypSlD84FPy9tJJUypLIW/x1pu TQeG+VKOq+FvLrShGFEkzzF4nF+2RXdebtf3m5kscjZBvtm+64sl+R4UKzoVPtSkO24noDAEUnkl dnrqLb1k9PkkqtCdN+2Az2cS5z7nYe05w8zIVqjaOS1R4E6fq/Xagsf4BA5vaMPQcYH8Tz0A//xj 226b53O4LRNl9T26BhLT49IbxBySBFoymprWktcmSa1hwvjEsxmaskc4mOrhk8Xhl1x+s8+UV+HG MfuQoZoOloh1/Ixq4+y2uwjqNXzZ9A7VXqAChU675aA7XHbHT1XnAfAE3jsKLtIOkGj1oVVQYGuS jeAssA1znU5OTMYjVzXHJNn4+BBUXMd9o0cw+bxhXvuUO4LYvWi3eodWCZeCmS6GJcCHm87p+6R3 hmfhvPxItGnq0XjIzoyYvm6ksALxUwFlyZey9+N8jvfFDr+Cxm6DsENatPfOg/jFDxR0fxSaTXie hLDpQ1Heai5HPu2Xyd1KNbJo0o73EqJQBmjZrG0xVgRN4cdiOrxw4HOtLe6MFv22W1Oas1Gr2xEe LiRS/NQbi6j4uQ7cstWtf8T0tEhrOBK4XLckDDgeDwGpdtpq8NBT00XGx/R/FzQJWzVEPRktzovn LQ6r5J63flK1TTIWGngQXnetuKLKPvX8sc4YzpOy+HNPzKuCZDEywx6sFM++EDkRFioFA19q25kq hJXW+1tIR+324aF2usvAdjmDQ6shoWpaIrHiGDc0wzLqLfuyww1G+LUMfR3d3g7LuQj/L+tg1QyT arlqR0ebCtpn/TZgwMOGzwvLqthNszUHHBJp8dimh6NrY9i5YRdDo+BvuEbd4lEILdIXP92WNAkR ErSYT9Crb5rlI5MrMsHiao7skdjgXx+5lCqvbPGI7Ucak7zNr7nW2eQkjRpKnLgzJ0tZTxwkdKWu E41yU0a/RVg8FShisCkuN0MnywZX3pdoiJ3OU9GZN04EfXdte4eeKG9mKydx5xaIIWUjXMW5wr45 T6U2ZFAjGPz4LipBrLNAgLlLRPyiOKldqLyfkM1ooCog8Hm2mBgC9S7Tw3tNwcs8V8D1ipl7ncdA 4sX5aWM4rkfAgKdxubE4j3rPoVmRTroOD0G+YD1IauNL9M1OYTR9zyt5LGMpFJ9MY72WlLIknJrm wGHJrbLTPn9fQoaNaCVAO6bOTXafXtaN1MeIUbKf1k7VWesLnvI+L1WDFp8+g1kLQoYTL4K1O4c1 GiMkj+ysDLljV4NAB+TTFfxp6oOvmjndEMUfPvZqYYOOEjPfRjx+f1oljEn/s94SJh71OolTTHjr FSR9LIfpOPR5iLvz+TeGud5JGrNfyTqYjnstaZcagc7yMOLFx+OFRy31RnimFMJBjw86ZKiTEKFX yqvnkXNDXyJVozgwaM+v+CtIAgwng1vL7q76RZP6r54v57j5w+C5zLWGEowrsqv2b038Cqa6ugA6 g2NK9EvHQCaIJX4OiJO6uZmZ9jE5Q1tPwo04bZcvKw1VpM4jG7VHgNYlxrs8XSK8JufLs6wK58kq YcanQAuqTddI5xcz5XR1H1L1Ue7/+ps9wP39Crd3C27cDnRMhCTIJ87CVQN81F70LIqJmHhybg8x LRtc+pb9UkJ0ZuVH7mo8kyiBFECFuC05X222Am9WMo28dw75lWe0FYxSk6W+4J0XUKr2WMUaz0kf 4/lLKQsqfebIY3yPMhUNzeKXDWT9vP+XD6z/L/D/hADECWbl7unibOXuiIX1XyakU5MKZW5kc3Ry ZWFtCmVuZG9iagoxMSAwIG9iago8PAovVHlwZS9Gb250RGVzY3JpcHRvcgovQ2FwSGVpZ2h0IDg1 MAovQXNjZW50IDg1MAovRGVzY2VudCAtMjAwCi9Gb250QkJveFstMjUxIC0yNTAgMTAwOSA5Njld Ci9Gb250TmFtZS9aVU1WR1QrQ01SMTAKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDY5Ci9Gb250Rmls ZSAxMCAwIFIKL0ZsYWdzIDQKPj4KZW5kb2JqCjEwIDAgb2JqCjw8Ci9GaWx0ZXJbL0ZsYXRlRGVj b2RlXQovTGVuZ3RoMSAxOTQ5Ci9MZW5ndGgyIDE0NDk4Ci9MZW5ndGgzIDUzMwovTGVuZ3RoIDE1 NTkwCj4+CnN0cmVhbQp42u23ZVDc37r9iXtw18bd3d3dCW6NuzsECe7uDsHdggYP7h4cAoTgrtO/ c+89yT3/eTM176YGqK7+PN+n91p7bemCklRFnVHU3NEUKOXo4MbIysTKBxBXVGNlAbAysbCIIVBS irsATdysHR0kTNyAfABWXl42gBTQFPQG9MfHycHHyYaAQAkQd3TydrG2tHID0IjT/tPFDRC1B7pY m5k4ABRN3KyA9qBBzEzsAOqOZtZAN28mAEDUzg6g9s9HXAFqQFegiwfQnAkBgZUVYG5t5gYwBVpa OyAw/+NK1sHCEcD9X2Vzd6f/eeQBdHEF+QLQ/MspLQDk09zRwc4bYA60QGBWcgTpAUFu/h8b+7/x 9Z+DS7nb2SmZ2P8z/D9Z/R+PTeyt7bz/u8HR3sndDegCUHQ0B7o4/GerNvC/vCkCza3d7f/zqayb iZ21maiDpR0QwPJfJWtXKWsvoLmKtZuZFcDCxM4V+K860MH8P02AkvuXBWZdTUUtaQ36/1rW/3qo YmLt4Kbh7fTvYf/p/hez/mFQPC7WXgA9FlC+rKBG0O//vDP4DzFJBzNHc2sHSwAbJxfAxMXFxBsB tINAxAnwZQVYO5gDvQBAL5BjZiYHRzfQRwCgUPwBFo4uCP+sKCs3B4DZ4l/F/2ZOEFv/xVwgtvuL uf/p/6uBhw3AbGIGCvrfJXZeALOzuyMo+n8l/D9lDhYAs5OJC9DBDmjxV5X1v6v/0cwOKtu5u/4p gHyaOdrbm/ypgJxaeTtZAR3+lEBmnUCyjuZ/SjwAZh+gi+OfAsido8Mft5wgW26ef55zggy5WbkA /+oAzdDC0d3lT4H9n4w8/uoAmXMFLdi/GWTNFejxlzPQ4jAD/9cMOUFBOlj/bYTnnxnaOf75EBfI CtDZ3eRP/Fzs/0QLdP3nWvhTBKmJ/iGQktgfAqmI/yGQhMQfAiUh+W/iBuUg9YdA0tJ/CJSAzB8C mZD9QyB1+T8EUlf4QyB1xT8EUlf6QyB15X8TD0hd5Q+B9NT+EEhP/Q+Bstb4QyB1zT8E0tP+QyA9 nT8E0vv4b+IFzc/UxcTMFuj2v7YjL/u/6/97Q4JuL+Y/e48XNLTpHwINbfbnRLCA5mL+F/6zin/h P7vpLwQJWv6FoNlZ/YWg6f111lhA6dr8hSBPtn8hyNRfJ5UF5Mr+D4JuIGaHvxDkyvEvBLly+gv/ 2Wd/IciVy1/4z/b+C0Gu3P5CkCv3vxDkyuMvBLny/INsIFdefyHIlfdfCHLl8y/8P29YMTFHL19G NtBxBb2w/JM6L4CXi9f/f3dqOliDzousBOiYs7Bwg1b3n6qZuwvownH719ca6Pr+H7awBl32QKAX 0AwhSF1VkeaUZg2bBduoioomeP6lPOJTsIAm95ud4FrcQXv6jl899e2I8HqLLYIf5QsneovR0XX1 8/tEoBwPY3DmRPy8v8CJ7Fr3WFKoz4UWoojSPRpH/fVqJsdLLqKSMQCtY7pdq184NV5Al7kH+UHH n0TbLTyHTUn1pZEmok2ZAktlWYS4I2HhurzOTDVDjCxk7FvrpIT9+vgq1nr2e0SokpeC7T1PBuSq JCISqbsNuCuMpF+A6bc562uYbg6IXYvNF35D/6hYZr2LN/sfIjOuiVvKNXLGuBu7WfTx1vS0VxB8 fsgWm3Er+piXD7KklpyBquVHCkOrTChnip+mA7tiDxiZfFucxSB5kx/7Ylh1v27Gdsm5MoXuiM33 HGBpJyKjT0YV+0lmGdoGqlnfJnhVFfdIiRbiD8YimuqHUDbF9cUp5BkG/k630VJZzQ1GU5bIzilU UPqu7USWWpyVfJ58h5vZfgJTnzTw7QDycJ9ru+KJTNsukqVKcLQfxSC4NefHw7ti9VOORs9icaVQ aQPtW1qPGY14R2tXYiuWDn6GQYstMfiY8Zn1WNK0Plzw6SHT2vwOzAonRwSZCAqiRR0wnu7AYSY+ GgxVGxcWLNu1Cv3LNOaYnfOFAJ3MENjjEplFHZacmfu78YfsamHoKQ5MRivL8tRPQ+w4to3XaK5c lsRMEmZR6dgBTBXmSqwn2P01tAkn7EMi4NujWA72R1U2iiLlGL5F7tepkW9Fu+vBWjXfIJceJyCD uEsC4heshx6jDAWwuuWmROZFwKMJ3/2JV6rqq7VbWor6EVRTfdMG1X+3rR3UvSaW2CfHbxeym4ER hSr+Fie/PLNnAac7waunKFVj1YRW1w/boPo6Tww/hAxED6L1mMsYPP4AJjFgetjL12RaonGWvEk5 pSGKmtCfl+s+irRrEyoiv7rJd4YsnIQ/FP4Iq00folE6gG14EhBNX7LHHkTKdm/cjJ+AZB3XNOca fYJQ51ObVqpzEW1SOzKypEcT2embGYT0fqZXmPUdZQpN3Hfnx8tFV6klogZ/mkQ5YTjVzDcw3e4O Rwek+7FK1lRwvy9YeFiEDIhQD8TOfjCJrXwex43qtFNUlG1o476PueSn9C2nUeft34qbyWpMfAVL FtLCXiUmSAvfDLFEsfmadj5KgS8JBGQEEXlKSYt7TiU/YEJdayM8L66/eWp/hk706bA2ywhweGEU znzSOq01J9POUNMKTJhI2D+3d3SeDQt2Amh47pKCR3HrfxHQphdOZ1D9NPtZfGocKiE3dNrD2a2p b/TUupc4f6sLZeR3+qnliteJ4troWCnZ63Ay4z1pO/4Dd5VWi/SCd5Io6weLpMT46Sgp3CyvJbOo Gr9mKcZwt1PX2VBYYOp3BUS5YPZJjqtVZsdH5RSiV53cc4afCYvjpB871NljXEPHrb7heKMjWPUW IWYKxkBiZAR02DBVMqBNr/AcVsp8ybPfvH7aKaz36kkPx4Rw0rRJ23XRjbmskXpWS44EcwXXqB1G 0VAQlL304DG5lZcqboPEanboUR1krjoJL2XPm6I3p4aVxY11LQhA5rE4z6qtSHtKqpIQgHuOCv3w m+qr1bFCv8C3u7RoFIGAeOW+obGZ+2K2n4+aND7TFGHqOb5AZh/a1f3afoQ4CL7fu7YLIybdnCZU +ZXDr7pAkvdHUpLYK0CmYo09qm7SorfCVaWaLan4CBZiaWhRS/pdBgXkKovrOIytVnb1o0GBvBhE NwV0Vmz3/O+oiqNs6ojreq8v+Jq+I+Lf6IjBXs9fIZEgmT5tsooVwvT93unK1TIX6ToVM6bVP5lc lJ/ZNbLNXXkaJJHkn3DF8dw5rK7j/oITi9ZD8HvJChfrevEslgLR77hBebpuEYrUkWqDhvoZxURH 1KFROXrZxKHzLdnLOYJiwkEVwyheJi9Ls+BBxDgqs5ipZp+ShPr982kgm+L3Fo5lDEOWq1MC++Tl 9cQ01W1hli/BV1sl2vOwl56q6nTLyGZ0UGUChaWwLzY3sKxUPeDUK9ZuzVQ3ke+mpQJ4n1+hopbN NRbod2yMjVHReRt4Os3CgYMO9TD3Dz9Yybl74BZ40F1ezrvd2hpP4aPFzYA6NiHUpAVo/PSXK+pP 0TD0Z0X6VcPwGdOKPM1ZwvLj3KQZhWnff9lfjR9kfQyL2kWHJMxafu4YODo+3JTcGFMj4bs2oWH2 FRqCHW2qm8btsIzrZEbrI8wdGHxl5Rgq3rJ1VHA/zdCwGLyFDg3EdP9ObBBS1usuw70G8Xhk9evD ssPgPGE08Spn9Zjrzni2aFInQphwigvNAIxSfBJfIvvZ9yEGUwdaq9xF5RL2DicqrucVP4NPg1de 2OEhKrlGYlojPmH66SWxuJsOOwt+fuzHNWQByxCXABZu1p6ya2gDDxGps3kbmBEdzQoaOAVtV+yo jrDN8kkPPy+ExJ8ih9sR48kLfDKJkpAQpJvIBIw9qUo3mB1a8fyE6rS3Lz3H1JXkLFlzTKiPHNl2 NT8LEmazU4xF9Dfbsy9NfBlofW5NU3TIjQhiUm+7JBh/NSmWziGiHVsYT+Xpz2aFVmrc0KM6jvr5 QUHXj3dRZKrMlw+oLyUu+xawjoqM3vCRIb245ewpUCf+MPUrcHPnNZs7SE+Rtdes/e74KnPy2pgf 1RWbmMy4WE8C/LUGKX8u4IK3nW4JQwr92XSo86mCd7M3My/f6mDwUKET1q2i8PNPUQ4TyM9G5/UR dRruktOeZmsw5mkZZp4t4edj+nlbZKcYs5WOMgJyCD/eeI1C1BV9D2gMbQD+6l8qjH9HHndT1413 F/EzZnh8WZmeoM1MWCTd9pgOCV/E1IZz5rYjVclOPcGaeHHxCiPB3AyBa2NCw02+YA+N6Po9c/Vw cuFK1Zs+4OL28TTyAZ0wrcRQsGFYUDoWwb709jBEluecsIQgEYXyCzO1297Y8WVCbg/pWRyYEHW7 gnhT/q50+04qj3k8hT2bunaRFJdeNj3GhtXk8r5i5oqdOSWw4YXbnkkdTKbRx0+i9RMOHrQi3/ec zlsL3Z+OaLteBDFQKK6S8iMpDeJMdnw6ne3j5xwGrF6jM0S2VL2BMrr6/PP2MyS89RwHXFUbFmy/ RHhexrYlhcKaelYGFkwR6IrWupFWWRKO24/NBxMHavf1PjIpNTAzCEn5ES82d4XsjU4lB84lQUhw Yws5ld08xGjS96ZghIWPX/ePELcN7NTHlINzXwgtNsptdvbGATHwIk2vpts82bNnodApMvqwosNk zbPzQ+8PsFGmgwNIx9sJhwuWBz6+bk+0MzVxlL8VYGzguQvaFcJYxgd7q5kNiOe/dYWHJxaej376 xnZs+3xCKlvKau4TEH0sgRH7FpNq5T1p+/QZmQNjROH6rOm7j2Wa+jYT+Mg8Ge55iiOeois1c2YU OpMr5zf4kbO0z2sLghgSruCvX4SrSZ30DwR2GoI3MX095BvTPyBFVNYZdPfE3KtZcjTAM4fu07Jo zgCdpD1YJY94HXGxdap0KcOvVCm+wXs0ebJFfLRGfuPy+XrUW3xyEYOBGhgU8Y02QF5yWmgUk+68 QKmB54OzNadVW+cqyWbAM1KPnba+EZ9mdgMyYln+vWOsWTtUFRsWg3HBp8pyshTFxameOM5yWosX 2pp6PrlMuEQpboTF68nM3mQbItnSokmgvPlmN2sf1mm27v2lVTOOZxIgRash7xpe2xhV6RmPyVer 9BwfQ2or4RspwsLumL5dilwplP5GNjzR2YBE5bba+Z3NZBTWrKOtrYtnBpG7Ev/GONUNIiOckjct sp44rxWzAbqpJMvVOBvrgHQQZR0vegRyT9VRixtsg/PUs/HD4lD8+Ptr5G0i1M/PYjj33868DQsL c5OO0o6iEDsowJLAmJGYgFS18zzVKJ01l0usfdt75mUXD7vonu0NtuJS0t/qTdTFor1KIaDv0fAh xoMPiJEfonrCjDuo6mwpdtmbA+vUkvgn3RegB3HSkbxYv5Y22k1/y3IpU7pWX62bprQV2LkhbJyY e48LEnwD2ve2StaJ3LhPvettTAWJVdbcuVQmQqRmTLd9mSIEPiYtPCdWfvzxHVEtuIFW9uDGVXvS t8B3oLb5xtImeeuhEcmNVxRmEQt94xHmXFBtTb+PDE6k9bG+GzpKwrnS1KjquUj4popAQvPtl/et pxP/z7pUcLRdhDCMW1VsBWGCQlOo2iYKqztfvX7aANhuGXoSA0/tzhefnWBkqMrWSCgFQzdwTqew TSScwN2J6aUzgFrotPmgHJn44tVN8nIKr2TmurjOIMWbtuiQQWBaNHrdqOTr+JNz3aMy8s3lQRhg wF6QISmzeTvPzyFvoFetOLOPhyg9TOkuk0jdAuZmUAMe+6F86XDI7mjSnkFe+dDWN+8gIsSJ8bLH Ol7Jusr4pZIfNlTsQ7R8ZWawVPR6F/tLzaR/wd1kOlIqgLNqw2xaP4TmAsKOGoGeGNoxmPd54Jqo TpnRxX6tDN9/a60zyAZh+/OPpd5ptAT/abzdwTfRl+9BCUkZ4egp8df9GzIond8Y4t6/4vdLiAj4 svpgshclSSrdRBnNUNoAOw2w91pD+AzRwZ4YZ9VUxOw5NmSPBAnwZwhZqgtql7aQBF1bm4VQnFnq WN10l5ze373IqIhu/EZ9trLvcj1jvTpmsFIpAUUpJ9yagDCyoQMI/J5zAUq4CwkKKiSVyOUx1+eT 7YMoqwxmldqbTvCo7Nq+xYHDw3ncQzEAtFAHLP8MRRGO9VW42oUuWUiMoY+StSraZRDMXOmhQ2E1 hUjIHPfaWVCGkZvx4qjg/DVU5QT5xFBJq2F55iEFYXX6agzDYefdLHEG9pBszdFNJEooETu3tEbU pTDzx8qqJtQGFpif+mnHzyV7Y0oifOlirxC1RaRLCJ6WhvtdSDwSAgQe6Li72xdcFD2O5r9jIYTJ fW4XnM97zQISTiLKwc51mAvKjNP8+/UIUzs3AZtlJmScdKpxMIzp2/zIe/Fzn1k/lWbta6MNiPeJ 5C95sNQgdXmWX5Xy1CKyDeuGv8EECgoxFx94bnCWJ3k/HpkIErfTyz7gamnyXIdwuA0kWai2peUq Gv1kbJztF4s3BPZPcEzGGMWzjwntkM+RQv2Qn1tc9Q9HYa7LSDOb2Di0TLVXVLx5zzEmG1rYVRLP m54WC/3m5/4R1kDqwdYHyibBoYvNIwvNPIvKQ9/1UJkDa33zwfBXWu4sG3I/2BOa9pKtL4oNS5tI 9XeGoj4N2QEoa22zQ1UcPb6k+3xC7fNUhU2bbujVyza24AeyGlUo2IXRe6zD8aWbMk8IiRBZxty9 xfVVsgdqJ/IH65G95taY9h8uYjc+6w5T/M3wjD1glyj4vuB4jVeGhYZwS2WDThOBWvbIyylNsBAL I6wtA63xaHHfw4QwNGSEPAtq2tZyh9/d7avM7H3bLL+BU9E5e6FT/fyYcCCOG730k+6b/2e7DBM8 4MeXHubPq+P5s1thp5j19gXDF8zZbKHPdJKszXyL8pU8Y3PqXmYKV6+vs7eG9P2VkJkjol3z7wVB HuJq8FkFiqq5QQHTq5KeJ/Cx2I3sEUmJ9360KsPju+pgaKZ9UqYtm2jcBaM1fhwFXr+N+30CW/3s k3NqYCpaAlRdhNfchEVIKj/npSoRpeEsjh6YK4FL53rdDnGdXF5ZOHxqHNnYRSk634eBmFt+2Mo1 /mxa70/p/uaJczxm8BGaJ0oicK9+b6PIbKrEylR+A+VXeWWu5O9QsnPenPQPGgzUUVIUDqtBfhdU KnrynoNtvBevZwscw9ZWqkLj/EGb1+bJgUJCd8v4VOoiEZFWucQj4d/Bz4Jr0PNjBm9iqJm19N0/ 3HQYGYBnErvJpEjT2sQ+J+C555OSlERHqsqkrgH4MvDx5ydIyPzjutNSPG2I+/UuhWZGhbIq887P /fjS4R4/NvWa6Lp8Ch2jJkvN9WSpbMhgxU3FvPKWLruQQW5JbhnqlD/RoAVfyh9IHqqRWc3Rdn2E ynCDWH3sunbIM/MbSMHr1vLNX6diPYeDwZikgDjIX4YXNHEpSnJgslfdhi6wDYYSyqAGd0XjhCRx JFnXgqpn+rLov2ZxXrrhgE9YXEABnTn+wMdCL64qFrZItay0W992vb7+2BdQVjPrzNKZIhgQnkr1 FT2VXsq0zjLaUKdKbvTJIPWq8n3GI4gbEnvIXfY0Kknwxz3wmBrak7+uPwPol1NunCahotAbHg8Y nswHo8KyQuZsnvUg/67L4VGJpucVbww3CP4yqQxXYBE4wdzSHs3xxSPeOZ/Sdygy3mo4Hiv/9XcG xNn2ABrKwJPRx/6yGXvXKR7M3GC12/31n9ZiJDgchzVQ1bx5Scg8O1+HhG6tuh7m8DuTxfWW7Zsi XUQ4nJMSto5wa24cByN3eAoqOdbSF+JvzMbRHWuUzfJvL21LA4p+RbTOKmxloKkYX4zpHjqQKToU i9hRLXZ6dg2QmuTLgI1lhOSSf0quH6+X6GVRCLkVqHPnKEUxUtkmHlpUTgZbIqKWxxzBqCh3C+tR 55ioQBhD97ZBTOIGwFshSOZJv1S5WKcFVExyGEpQ66Zz2ZR5jOBl6en6eHnVhRY9ktw1feFGAGrn 1ysEWYq28DYvqlh2UzwyrkI+xbd3Ai9QqkQCA4ZNmXZl0eHqUrj4J2EkqHcpdd63KpCHls/J9Fcy +VZL5STC+JSgApLrKfgaP0HBKtmxjcZwYbSk8LwJ3UIvGMhh6r18q7q/VxcDN51bxjGvU4qsga9D 4CA/uDEMf+lkz3PbP915HfkASeYl63vWE33VvoUhQ3TpYtgG62Zh7sH5ML8NJ8IykXZ/pGQFnmNV PdegT0wiKuVM3t/pL2MBKJHaXM4FtiP+hhHPH1QLNCEYjDIrvkm8WSPzyYuB+4IFRhj7SFBnQ/jD RUlTLhTv6ok3ljaaW2jQCOHDnpAPrx00P8H2sYF0Vy3nZ699fcfX4CrbOpQLFy6/8adVpmmLQS8/ BfohjyOKSLkZ0Y9xzK75UhCa6sURIgu2Pwvz20Ug7eHRWmSCDYLuNrgjqHDpEavPaQsUNmybrQ5U tHS+nrajt3u5Gtjtf/dI40vlzcS9+Cau6ChsCpULluI2zHIb2dTHo/f8A0nH1RBqgP7+qDX9OFLr /hfDq1eK0WWVpUMHMJfnohS1BEsGL5Qr72J8c31Qt/wbinf3ps4Xp3XhxvUuyoz87VQbIo88xPr8 kLI97TYTSLNuFS+qZVZdwgMIjyTR0VEKQwGukq8lEU8+9VNcjTA0Z8Sbs5SW/Njyxw4BI6bpymt5 pk1RPjUkLbZd1ZTgYFZBGlTCZ5kiYrRwmGoGqlqbQhhSs2Uo327hP/o9hgYeIWRXGPAHGlsBarW5 Dl2SMIM/XNGW/MzvozHRcV7nM8rxbDS8Upw/X1bo4LvSnt6s/uUXpFmwj/1+VBGYAObeag2gakNk 4xBkd9lcE4QFFKIXyTGuBcVKhDVRIq/R+2XUgxNdoyh5n5hi+LG7k784Farz7XvP5atemkPPs4uo CPmmaLMo3riXizQ7Me7SJqcyE0tdq/hw6DIdetRC2hzRBGl/3HwNkjhIV+vczeKBtu5XOyWAk2qr kwmeCvbiWquYm10K36u7qG7fTf5kKoGzB5EF67knEa5nk+abW58/VWUD6JShBnBmixllISl4NhBt a9bzMye6vbfe6Q2GHz5S0cykl8BGFUKj2mwiuGWmqbnDjBmrVh17zPgDV8pjjYLT1LC/AwWXYUbm PGE72e1JK3ZUduVcYkrJOtHzJEWu+de/77LZ8kMZZfggAeC5K1zMjlGpKyNt++50BsLscw/StaON uN81i9KYC9heq14+lZ6BI32lXAkkqUUfgNgcohTwDQ00xBqFHo9ELeUDT63xrXC6QlrDB9Mkps99 STUSn6KokD7lK2QZtqIJ5FiHUJDkNY9RZpreAuulF3B1kHoTq/k9Uu//cYWwldq5xSPzOrgK81u5 VkDZo9OvF7bUxWHN/Y+OWpoIRk9mlsg6W2eILbLeHBRXaUTMafVl+BR+I3zU0uX9zrMTmMqGpUEO e8xckyhNWgbl3zp50gfKWlNyzEvJyXoLTKCeTKgZYBnWyAOoWwcdxbonLFnbXViCp+y/rl+fCqdv 1snkr1yh+dOfbfRjkNlPqywS+zrKzGIFEPqwWd3dXcXC1hh9dMqMszHkZFVqqY6SYpSL/3JcGVoM jcU2AGMRklINAHyR/wV51Z9qLe6/d/pCDfa8qjJxlgWE5M98vSuf1nk8GIssDJKe9HeTqBGI6ZoO dTknSyLe4p1KsA95h4hiJZnK4IhH5xbzwXW8GxvN5+wMhlAFnH4l5Pvhm5gY2H45dZVw7NOfFDL/ avVA9OkndlpANnJELMRl1SjZSxkAi21GgD0ol6s1IIrDYkYupjh4SemXcmdAP392yLPHSGnoIyXN r1RX+N4PJC7OKwzdjXAeFr9XmPyUk9wuQxkcOYgvFyMON2yaGt1rOT+kAa8zfBCZ0AnXVRoJCOur gmvY8tY4PhsRQud6e6r1kLgW21tQcEPCCdBAaMEybj2leYFxRulKH9c14cqe+1QTnPvdyNfXHp5B NQ+8izFYi41HDN+qhXqWaUTyR6iNz0mYBqfu8maRwiegB7x/63TZ5fsIgcyOBp0MdmdJk1v5lWna Br/fYRriZvSe41QfJnDjk1HDy1ep5/OqhuM12dQQm7xuWA+vAzvGs6IyIZzMM6lCxZFubb7c2Cg4 q7d5pKEURelE4xoPNpNfKQMCc+UfmS4suI1NoLXGKHeYasJgfXJj6GbH3WP3fPVQcaZ8SMVDhq3O 9TktsNyhaNK4Bd/xKdQi8vowU3OC1faKtgxLh0oLqqZ3Bb/vbS7dIsd9HTWFG8xR4hUedap9rZXQ n1RttTMez0YtZUm1aS5+fbbZHs55sbjcp/bKzYi+VV/C+SUy+PuOSWeVT064SLd63yuV3D6jU9Cc Bv7pEp++RbouiL1e5V1POX9YEGerYTRHyxbFjnCXSDlZFhJd7602ZO+8pN2vrFUXzzO0dVUsblmr FWlqrSgTIEgrbXkB1J5+5amE9te0disxsChHETbqZ4j3NHxAFy80VoObp0H8TsPTOyPAYBQ8AbFv eO7OR6cNcPBvCD57Ocu2c512/P1BasyhrBRdtuWAuVvR/we+dnTKz4Cp7t3KSkJjAl7qcB3FQ6Kz /ObxWU0Y/Gcsw4TBHtkyjjdJ89Obh/jQDQrtdXHtWSQsT97Mb2JRCXLl3K6uqFjSYNP2bYYsuRra v/rf7YiacIE95dwoBOl5ckbSZjTqUI+qHvYpDDCl5V0CO2MoVXsVpEytt2jc27Un9kViu0GEtoVf p8uPjNfEo8fy23G7TROjvTlhmO3azZGJ9I0p/eCc7kbSfxc2RP66WtBIORbPDFNq6CXBznZuyBXG EBqDhA2HWORAEiQ8m6LzQKkMng3xlic6JNRuTJ7yoRH5maipgE+xnrBgWHU8kPdyAa/YmDu+RdHX ttlaGgOb7zUiR2x8AVHtjKcnJymi5M4n0zJpQr8f1+5vQcnBmO4615fBw7tfEVUvJ41qeundGxdu /s39HCVlKWw4rPXY2+IgBd0jS3gnK8Unb8iceA8h+rjnzHeOs+13MtKJkv4nC1o0cORWSMIJt71I nRfa0JzLCooh9paAzYxCwTcXcpmoEUcFpt0nowxMRJkEfM/ie6SCoK8Wn3kDshcW7eVKDCJekCxw Ed6XMjivMtVzFBCmSz3MLJlHUJ4K98RSSrcmlzjuINIa1tNQTjWud3AZJqcgNXCT329G8N7b4nbd PXg/+L+1pTeqtEq5rbTrURTnIOiO6jqbQvKJymXUTWdx0YReP4jwnF9VRNaddBv6LB2pqKil2KyE 65TNT4ci374p8o3L5mH/+hWziavHdkQdSYO3doCdt2Jy3vY5d2nl1ybawD7WxIxECVsjPAdnwJwm SjXkspjvPPcZVcvzLKRjacVRwCFFDoIIJFagOhC2fzEODq6YRu/4So59CuciD7vlS7/j1gm0bvuj rKAhf7dQjfcqBsWEBCknRgpGtqHQ75yW7tzBsyhsa1+vnO+1Wo6xKR7kqeCnSpSf/SvM2SlNDxlm THnF3lzWuJEwcqyqMDFYe1TIvyogNfx65XZ268pKrPka/CVP+cY7XpdfRKURosehMhmAIm7NaPLD q6ecKm0epqoR+jgT3EnAQ1Wetz39YBjsfg/u88cz8lluTQe8deYqXGKdBe50YMaM++xrJSKLqA0N CW6KaRGzLuNSIaNbt39jq1dhkH1yRlOQIZ9ko5pODiNdYCPbm1wrQcPDMU3AdW93m6RcwHYxXAQM JT1aTuXYChTJqSlbLP9P3IH4ivH7if2wM9YQ0YMKyo82WUT6g9y0etrG2DysVCFxPNHv6li4Z12h 8AxZPZwr/oL9PtMBfBNjOmIpqM2j6zIfozcPWCvmL5j0ZNxmzup+XGcJAMyieYxId++cSLxCv2Ya Q/HIFiBeJO4Rp3aETmjfWR37DV1969BefhGT9WDmHfX56dtpJ9I2HxCwMhjzE5gUtzNrj9/C9ijT bLWsKD8zxClkQ4I4BljpjzmMDH3wfH/7TOL7OmsFaFWD1KqiJVpvOVEzWM94g/kc4o15Ng/Oc6tk G6f7HNGPYtNcoB6vaE1XWKncOvh0NS6wrE3UXcG1heXZczV2EkcE7fohJ/x6f6/RuCICrytG+BAO uZA8M+fFUX1f3P0Ej/FqfCAO7Ys+y8WTgqwjAP2nnhN41bpqASxGgnnNjtb0+1hm+IQeBEldj9UG LMLZKzGqpsveGzllL43g2HUW3S8bUzposoT1t/AHpkZZ3Dlaa1ZMrKdkfC9s11bZWSV4dP66zyh8 2CLx4i/7gTGLEI1aKmWBouToByk9Wfr9SZVe+XapPKotu2FMxCIoUzAfzSh0s0uDf9NPYvVCjcH5 CKfKEP5SyKyvgYd9THORbJytOnTBqpx3aNmxqs5C34Md1Vhfsalv49Awnl9FAts/5Sn/kLY0I2r/ sOjiVvELLqRXmmoqE+IInyir94D/K1R7/lXxlvDXnG6bQAX/ywrWKzFH1Q+ZstL6k5Dfi67tpmr5 CrvmVm7lX3NsHhPG6lVayj5V8TmeoOZXhDWQx8H5YN4m4pnlpfbgPNWsYttsehc0OO66wZ8PhBiL yKQ7155QNGLoSxVcj+aolbaG3qY8kISqO7BTackJ1yED0dPr+YVIWA1wmYWtivhSv47kF+Wmr6lu u9O/OUzuTNF9dYBwFHijc91YJolMLAW+/WSVzQf2MHDM/jisJpNM2osQ6pAQpcCODfkqSVlTm+X+ ueRibZnoJXr77CG4cLHyIhuqHoY7XPSjiJPP1yQZAS2z9y6soeJTR7wWeRUNqPVdS97Db83cXBbS kpS+N/6zOXQSyZRf9OnNe2124I9Len6RNva2qGfvZ63stKAg4a3KlVXMObeTh88eZ7i+CjIcTa9F EWzzBfNug3MbfOmoqJKerbv2wBt64VvYKxfd9mVxfHlZt/q+gELQee8Sct1VP80xXvQc5rI2TMtx GSQlfUqoQBN1wjlAlLFoV65zkQQjBH8+2U6b4rmsVUXksbugfDCEkC7/2fd4OlWP5V3+2gyLA+rT E1TXfoRw3FL6nlFRxSpWeSSWJfi3WR55vk582oT54QpRoYcF9vafRjLadx7YeBt4t1/hRgO7ftJL W3J00CfHZxvG6A4/VByNI/aIalK8LUyJqDqr6EXC96NuyzgyDU/hnZZo08X4t/qtuVM8VB13Hj3W T4HpZwTA8pg0hZVhzel2vbGktQucBaDu2UQHLRnAI+6XV+1CyOMWdmPke796v/6gjQ756Vi/V8eH j0f00QCcprMKoP4W/bMGA3Pp4rYm+JpM39bae3hq4OeqKpdcmNmVFC83LpIGgwItDbXcgZ+IfyFT 8FD0azbf/QrMrCQmkutV2/UBa1XG17EzEigK/uy0O4S0lk49yfqoyiKPIKS6dwz76YGmHXvlc/oy aSnhz41S4IYjLB9O01DUSgCVs7qPfRZIcTvbCCRYTWqVRZXU8LuMlGdU7579j9/vUk14XQ9/3SAE WQ+BRaHoK7o/YauE3SiYoqdILEd2N1iUflTfueJ3rpGSS89JdLGo5zqnY/aBo05+59a61a+V9+EJ XxF4+qEU456LLykuqXD48Iw9Wa6Kua+PxdXAFEIl31gP8+pN7jtsTAdwlN4MKd37mq38wRb37Hd3 SqR4+e8MARZ6P6VApzptalrGT9MEBcUuS+N99QkqWZScd3QfGxr6QxED+wMHJuqrj/X1fW9znqfr 6Lep+M0rU/HSu9/FpA0c1Tnui50LRcUt+rXzSqLl9hiy4rWuOb4F84CBMXt5QrzvrXEdu6CBOe7W 91FzlHZzfJ7KCPYJNT/xlLzOxDiBiBAbyOnAPFAqLv5QA5Vh+VldLxNYHm0xb0VOb8zNMXuoD2VJ gXciOlPKwSHz+igryUm9f5NzYoA/tugJqBrENTu4iKwnOgAE4Dsos8p9rD110pPwbHucIlcvzPeu NxmJezrHxWiV4kNw/mzSyV2nWIklux0pfYtezLe3mNa7VZ3zQeoKnci4jQdWvBnWjl4nlqEnFY6b dhdCt5B4f0mEm3YsVJt4BeYXLPqn8lfqVs7TH4FU6en4qBtCKjcZ4syYq1HWs1fBhgHPtfiS5ndZ emMtkJ6K0pgWnmhmKxrWTsMzTNFPGIQN7W5PuE1YJ9vwRzP+cRLeRgL2CY2/1sUYXSB0UGnv2PFo b5hmtugXZsGiUmSch4qjtttIiasd1VwNmkLON0vLpq8N3iQ1FUoZOmReqgSR9lUcXJ4BBQGStHZ0 v6cZ+C23ZfjmajG/x2DmjZpa97plpMWPVRAsfy/9HmUZuJAwMvyyR9RSVvEW71Uu4xI+Z3GikZ2M f1KG8TLt99Q5ssdbYNFWGWgoydCSH6draEx2isKsmB5GEF0dNYiIlIQN9FZVA26eEqoZn1vOvKm/ g19KUXVUaaQGcwXQoxqvt/n++LEAi/NhHjIT4hrtUax2gmzGi5NI6SWlprm9cAMP9jcAoIaMNILz QznhS8LQREblUJ+9eLSqJcPuqKAitY16bStahDwOAc7Qo4OMTR56312QyXzR/Y4YJOIgG1E1Il/3 GhhcvMBDB5YUrYxkff4CVo3egGjFl3zB1uXskfeGJuLsUd/Yb71qTdiqJPoClOurDu+tuccfWRAL RjayN0yvIYXn43pPYxuHpnJHOu6DjuHmfq6QmyZ26UCwxk0F4WO6OjYsCQqqdsS4kfT366icIm/k 4XeeG50f6Z0NNSwVbD2vlNAuiJZMTGZVchL9Di+W78cTWxTrBiJB0MHeudj1SnbjKQbxGDGNNYz3 seWIIkauwN+zssdDTbKIX7q5JU3/us3O36HmpcZBgqESTHgSEIzY/9nNtRfGCfP87NmvPs/Ffs9b TfqxOUeQjdavYdR5duShyfd64+Vk4/eXdHljDTKa9navMuE0B7Exu1G0SZ4L+rqup9D1X0GpnRJO LNLjElPn2QLqABs30czGzm7OZ3lDhtuE+TDQt7cCa193vWttiSW+I51qsTXLGBzxxk9CImjVWyfx GZ6Sg3BvN1Lm25Tr5nzKgwHNMIuOeXcspHb31CIHupS0Og/H+5mCjNEE5WtzzXO5veFiDdO0Ua5F 8trWzuvb+yVdKduAcuuooBpYzgHfzQ88PDkzWm2KDQm0C5fJgmKSOuoSWnD4wsTYogDJPV0jYP6i VAOkC5VNU2HNnKsMwgCaggh6bNhF6fbcIIMJtsRH5w+F4Igi5trYc5DoMh6UL3MqlkrkmaU/+rca fdQeKSe6qK7xNBluaMYvmHu1XByhkrSMmDfj4F+Ny94cjV7COiy7wYhqekmN++nsiqIOGgYbyOEv jtNvqp1zjasNxLwb5EQiMPpC1PhNhL9QJPsp3Q8cF11nTYL3SdoMRWVMZ7TDN9IneqYRlbc4NV1a LrYSKjBMxFLCP/KooHrCEzkYuS9Zhn/c/t4lDdUNI2GsK1at1GHIEkU49IRtn2Dv5omzNTRiusMG /bs4+rDN0sz0A1LI6NO0iD0qm6hLXWN+xk6Lmb7euJNjPWKZsMXXFu0gnCrIgp31p57WnQ36ZgJb hALhBhFdv9F58E6R7UV+mB5ISz0LwY5NvpfKC/WTHLpSkdkdxWfEy080ZNQBIV8OB1My7Y+bhsRE VgriKm8WVA6ZWGB1+xcVy6/bXu2MhcqZMizjRcE5zH7ST4us+LGMP0ehSpE3QCegFDSV3De4WdwM e7hw0p7IqCM0bEIRzxagzz56og3ACjPdPiXX5g/rEj/gBjY3MRrKCqc1lySTwL3G4XbVwE2noHu6 e6rvbpZHQicGXUsq/8yv0p25ZyGgndQUSgxSNAer+a2/K9VfyA0pplgpgqbA5tGdDkEqQCLLAmiW TTuFUviC6KhjJsXYjM2hyGxQ4x+xd4t6vj52Y+37o2139McXctc3fIwFKNcqlWGR16iwQqBI0IsR roafmI+Y8Tu9lG1Ft7fdEW4ivwEedCcmh4MUUqqkga6ewk751MWdOI+t5+MceR5nXxXzw4xvtnjp luHIUHoR9WHySz4ljvlCOarMAVvCnC+KBUY07fETkQ/RDT3CRAicX9SZBF9JjgCi+qiZVqaPx6PS iTRcMmL5WYHJVWGMOM84DozFl89a6w9S5JZXE+R5Txb6Q9QF7Yb3fmcUmiVJh0c67ckKavxf03Cm XOZOksxVyaBVdN/ff2LvsYgMy4dZ8DVf+Glij29S0tEYOOl22QsmuYXjnx/HdvahiXUZbpno+F+t o611ZNOmeKWIDMOPdv4g/rRy+uQ2ol/vXoLZescYELnoDuFR+8i4qo3k0dAlhRfcIm4LNIt8WfPp fB5lFC5kgGDz9oLAu52g0f2woMNmzszCdQBMd/I1x9AcnvjENAkF1yxLmj71/nW8Q1lQgU1DHv5K snmIpdScgrORy2P9jJHnScF2+WVrNH4LDUauQbjXZCOyY2MEiYPZOnUt2n71e2WBcGWd2aYtHISJ eJ/O5BvCLl91ZW9N1O7MleshKaG9Jn0pX+hsBy2291wo5HLKmwveskYq4/ea1Ooba/96O950toTu aYpKlu+qp2vv337d8daMCGfa4eiHyUnwCWYJWNxZ3OtSzLR6kttR3hi3kQf0DH0stk0UiwbmKHke s8vxyP/KZNB/aHueIrhiy/qWk9pWGOxQqMmgZ5D0i/YiZTllG3WU8SWENr95R8RzVcWzDG7Y2sxK M7lCAw51e/958Lzxs4U6XVCqpHnJyw81xd53YfXoV8FulwPVcXXAnLrXsrdnpaR4vwdp7YN9LfDc 9wu04zAK60CYFMv2XvDIsNjjLYbo/ULeY3SXC9nWwDB08Mc7cYDyjxTrKR2O0pofjlSeENc4PoiZ 7lprER5BitBFo9nWnDEwKX2yuF3NHSihn/yDw7XWtsvhh18Edf3AZKcyT9p3uKA8lfrCU1gvU2sD 4Mk+ZNxCuaXdTUrN8ImP+9eglMNDjMKcHrmxO4i6S1CUmDTBEI358n6aeznSsGEhfU9ChtZhMD65 JZGtNqrc+1zqW7tMkdmuni7a59RmrEdWkYqkD2uKF3HpOaxiy7eg3MlP1Hy69UO+g8mdbhZb3/K5 pa/KqL1rEbjQtpJvMYbkS5b+pkOOjMqO3qBKdDZGtqRTaYjUGJfv3jNqDUkfxGrtcVKI59CsUYP8 mD4GDp3uVpfN/aHafpAQLoC7gpBlWObghQXqXmqLSDakzHCIHdaq7xiR63MvQx1gnCi1O/57t3mf CoVCCE8ZgRjUowiTviM3JvvpO18kX6FSkuNDiEX8mUKZGOzvddas5GaBb35D3iNNjF0EbZafye03 7uAJuyxkX1AeaTSyELkIbRHFRL4P3aUHTEFGPvmcNLmv3LTn59B5PcvKU7ccsC2JCbnxfcCDBDPe z9ppTQ3X47s+LxiO8czJe3SAamjEWTe9Ri2I3jkVn/iYWTI3I4DDbyyY/7t0ERyDd5RwGlfh4g2f 3HzrUvQ88lk/ShQ1845ZAoGiaSYCXH46924hAIATxACbQRt+KOpv2ZTIRRszAE8mrcWM7xBFUpyJ CFeYHfAd9L/bt07nnYP5RMsnEzgWmKMkm8gM0YXXayIWf2qRy8ULXJIj12C0oxsisN/jOgGyNlfn jnOF+vi/zayqM08uFJJ1naloFPVUaYUQpdHaOVPJflsXOGSoF9QiMxFerXAcQSTQERhy4aqrKdIM wl4XIbRlx3MPf82Eg3sf+Zn2rkBZAoF2O5Taz7f2G9rVuCxC2w/G3aq9fyob5iZXFIdx9df5CaPz WoxqEc32h9URq3fm36gHi847eXX8iK/InjvpUIbsZbdcYnQFVOOfrGF59U+2e38sU+2Ycefulp7O TEI5H6QKIZZPsnSkbfLSfWmMFHI7x1Qty7SQEga+erZDElCn3VMkL/aEJNIB7KbywO+ocX0TfKXz tDP2uPPBJHJZGCZE6NMxlY897QoGWmYeqLnkHuwW3rZ2W1JVN5JwxdVqq4u4m7H9R4kUmzSO5wC4 eMuJfoys1qpNdaRRVgilRJ59riffRza/2RqOoBbN8fgmCAvkz61YRLu6k/pV+ELOIfqZXksEVkmD PT7mSVqfKZYQlhJ0r3pQVZXIyu1LcoORvCybLIbucXOkZrXP0SwvkAPAqHeoF7Yo8+Qi1wu4vQlc wFCawRQsdcQ1tvI/jTWLV/NVA5HISkoqUJ6VxxJFpiUCwwLDnrAPcjDhs4Ccwc7DiWB4U7cWvJwQ 2BzsWSqBzkphLnpNwRMSgRtHjOuDvN9/tQ/szRBG5Hhcl0nEjHXJ9jljQY5EtoZHuMc7+ZKRR9/W sx6cHZiZm9BPpyLkfolk2HbfXhi8Hs9NZzlLZkOGYOzG/IRra5mjLy84kGp+UbYbx4QFX5FOzKvq u3szlPed+SVFLg99f7vUFV6R84oH3pQjCrqg6qjNF9+hmW+JlBe/WSiXy0hzwS41YmUSgdzxvAus qJJHgAi1PUv364CygBAdTtgKT7/LklFbrR1OzuU8I0MnxBdGXzLvLJLtICI6lNfQ3vK1puGrvNP8 Lzbu5Uwh0O403efXJ8IEwXOZKcvQuz/F24/gKxGBEbcfqQOBfYkVJMiTcbFSHfY/A258wS4otk89 fD3VBV7bjYmGH9sQj+aT1SbZ9IameWJToglumkpS6qMNWZp07EPwxddJT8FClP32WuskpFTHlRuV lUJOCBStNN0DFnZPnEY/8pp/xsYLLYDN76iuVOV8w3oJCcDlSq8QAb8Ydarki+2jsr9TzVkvWBRV xVcncNv5JBmKzdGCwBgRS54pG8NhVqgOualfWdeWSLjPKFyfMfJm1Vsu9uOy35alehSX09IqFLJn H+GyyArOvUAyS/fUWmwk57FBJrTJa6ciUiCRR9yq0s7uIQDJOADGJYvs10QvEhGz8tRsyQDx1jWa YiYO1udmvo2A2thAS8RtlVY8wQ8FF/zNZKcNF4gVuY8el8pECY5D4TVZV2ZrsxsMTVtwbFcaStUP KoRlUaesPrF4Ej+caS/pohAYCmWdtljy3kXzwWWvTVGr4uxWBSiRtbs2FLk8i6PX2DSm7mNZhn0P XvGnLdU4+nMiQLccU1ba14H6X4/npIOhPZDcS2ATzHcutB++EruVfZskYi/93F+8XGwYA6WPNJpm BDt8JAgXj+4U6/MhdMcEtYLO9SiYK6If1lN/h1EoahH5rYSUHi+KU8E0/ffECtzIYSm6TSjc0dbB 93gunsrF0mRwvnoj+PLP0yKnpFowAb+1cxwiExwO9Gad1A3BoDpj8KhtAqULW35gq6ghUB1Uk7Lz MhHu1n78RI6wehtewV6sHoZhphjfzO/D3u/LOKZ2K2SBnxVZOMLYhPNOImxQERYWRSwET/t9UtLF lKk+gZWamImt+9jQ2ol5vtRiBtVFYBT3lBAxHj7WVndD1U0WN5xo6tyCqiaUIAR/HeqmZUpC9EP5 l8n0bk+Tk0RurqMxAci3IYwkvV7htzIEx+ZNPGJEAawoosQBhimsmUe36Cs5S+QGIrDRBtgxLUnf WP6vdzkbjiy8v3/A0sVqqHqNHoNHxQ36p2h6VM9DIMY3FTRJ0XrJ/9ibE1nYxcB2qfeZZL8sM39k 67l214qWEZ4iY3lm3DYUIVvPMJ2iLQ7yv95RdiKGaDecfRLzemA9vw0ZaGIhb5RS4co9ZBO96EEw jBn7FcEjUWCdu4SZJajGlTckrlrEq42UK5cIreCijmn34sk/nH75KDjJ/TNN82WUEb8hM0TMNxLZ qZ8gjkawpMVx3P8DBRkpMekNk0K8pjDq58SdqN3Z76fGaQ5gpwsk2hBh9Tu3/l4L+4iuZ8YnKgsa 9oYvkEx90YBwznxHXwXgkM16D6WJTsUOETwnhTo/1dfTG4JLF/OTaE/nHq5fHj1tGnnKAzXGYjD5 exAaIatQJ2C3TTsJN6i6QGyVFb7Dj4+s2RWSWJCttooj1O8LIu1ws7Q4xTlGFoxDd/AGF4NaSiGW 1RbDHQ307IyQ+wpKgVAcRBgRwWWBZ+qN+W40TUyXU4e2rqQUT1HnYpIT3ucVEikGUwYMJ35NIZu3 j2IXXigwWQZHY5/EitoWkqgYgrI2Ak4BJrK42qMwuKPmYKpthYkE5uRgGN8FhfHXTOhdKmRsH7sd dH5m0D2WSfbqAmjIGmbFVovE1LoGSohFxZW/K/NqlFQehtQoWRd7NlvqihiM+tMJp97gdhyO+wi/ 7n64d1c4pz9O2pGDhblVlSnKqx7CI3a0t1LTbo4RnC+yDTi4JeyQYktKi2M+xIZguFk711dv4UJT DMrgnhN6OyaWfJSl1ckIYuy2IevDJbXjPbUpMaYl1m1JGDOcSYjZh+HNM3L3XviafsPE7LbmGKHh 1ZvyJXXRWb9YGVNrgcP/sFNnTuhaw3ixqww3HfeyslsaZTOHTN/MNbJdz5xsV7yQRQtnUjPyN1Sm ue9J0IdymnEgPCuh8HBAThMMrfbkeObScNsibp/FBI5wgiYFja4aqam63Xr49zw2EsWzbUTwp8dD cGqJb7nLt2QBjcVg0pMbX/jDCLQgRjDINrziKYKabUrVqOhsIdFkQ0jl8MgL9DqCxVydTZQzwoQK SRXuFclmdSyFYRHOfFZWE/H950zwbwMJUtT0qFsk7r03+hf80X9L2w66TRFYXAc6AY1hH4pcRgoE MEeL3FdvUfMxOz+fAS1r5tgYZsBGyWxglgIwA9sKtHZ3DMD1vgJuShfbyon3pRl7anDqDB8ZDu7l wnEhpXcWIM8sx2mG2l8StqBYpZcq1nBgsTSdGBF29rJYLWiVogQFjLYe2zNlFimV8H6x5dQZvO1L QJslDAaCguytNERk+X/5g/D/D/D/iQHM7IAmLm6O9iYutggI/xcAJPAWCmVuZHN0cmVhbQplbmRv YmoKMTQgMCBvYmoKPDwKL1R5cGUvRm9udERlc2NyaXB0b3IKL0NhcEhlaWdodCA4NTAKL0FzY2Vu dCA4NTAKL0Rlc2NlbnQgLTIwMAovRm9udEJCb3hbLTM5IC0yNTAgMTAzNiA3NTBdCi9Gb250TmFt ZS9aQ0JXUEsrQ01SOQovSXRhbGljQW5nbGUgMAovU3RlbVYgNzQKL0ZvbnRGaWxlIDEzIDAgUgov RmxhZ3MgNAo+PgplbmRvYmoKMTMgMCBvYmoKPDwKL0ZpbHRlclsvRmxhdGVEZWNvZGVdCi9MZW5n dGgxIDE3NzUKL0xlbmd0aDIgMTE4ODQKL0xlbmd0aDMgNTMzCi9MZW5ndGggMTI4OTkKPj4Kc3Ry ZWFtCnja7bVVWFzdtmiLu7tTaHB3l+AOAYJrAYW7u0PQYMHdPbg7QYIGl+AECe5+6l9775Wcdc7L /e7b/W7VS7U+pLfRZx+zaChUNZjFzR1MgdIO9q7M7CzsAgBJJXV+ADsLGxINjaQz0MQV5GD/3sQV KABg5+dnB4i7WQI42ADsPAKc/ALc/EhINABJB0cvZ5CllSuATpL+n1m8AHE7oDPIzMQeoGTiagW0 A29iZmIL0HAwAwFdvVgAAHFbW4D6P0tcAOpAF6CzO9CcBQmJnR1gDjJzBZgCLUH2SKz/KMnZWzgA eP8rbO7m+D9D7kBnF7AXgA7sSQ8AW5o72Nt6AcyBFkisyg7gbECwy/9jrf+L1X9uLu1ma6tsYvfP 9uAy/R+jJnYgW6//Hnewc3RzBToDlBzMgc72/zlVG/hfakpAc5Cb3X+Oyrma2ILMxO0tbYEAtv8K gVykQZ5Ac1WQq5kVwMLE1gX4rzjQ3vw/JcBl+5cCq66khLaqAuO/Huh/jamagOxdP3g5/nvXfyb/ i9n/MLg4ziBPgB4bCxsbO3gi+Ps/vwz+I5eUvZmDOcge3BLcPAATZ2cTLyRwb4CJG+DDDgDZmwM9 AUBPsDAri72DK3gJAFwTP4CFgzPSP0+TnZcLwGrxr+B/MzeYQX8xD5ht/zAfB4DVxAxc1j8hcE+y OrjYmrhY/TvGyQ9gdXJzABf/XzX+nzAXOJmZg52dyZ8IOJ2Vl6MV0P5PCJzREbzQwfxPiA/A6g10 dvgTAO/vYP/HgZsNwOrq8WecG6zkauUM/GsG2NvCwc35T4Dzn4O6/zUDLOcCrvq/GazmAnT/ywxc YVbg/3Ygbl4Aqz3oLxEe8CLxPwReIPGHwJMl/xD4TO//EPhAUv8mXvBxpP8Q+DAyfwh8ENk/BD6F 3B8CH0H+D4FdFP4Q2EXxD4FdlP4Q2EX5D4FdVP5NfGAX1T8Ezq7+h8DZNf4QOPuHPwTOrvmHwNm1 /hA4u/YfAmf/+G8CvyRY//QHP3jM9A+Bzcz+NB4bWM38LwTX6a+2ZPvnif+FYFfLvxAsa/UXgm3/ 6no2sITNXwi2+OsOsIE17P4gO1jD/i/85zr8hWANx78QrOH0F4I1nP/Cf3ruLwRXzfUvBFu5/YVg K/e/EGzl8QfBfxGsnn8h2MrrLwRbef8L/89Xl4SEg6cPM/gKM3OA7xW4cDzgVmLz+98natqDnNyA cu/BV4+NjZef419RMzdnZ6C967/+K8Cvxf9hCxD4JQoEegLNkDKzcEGQRkykjDfG173zlNrtEwuq SF3FJ1+4b/PwpkbOkW1hWRatI8JsVK+XUB+PVWPS7unIRSPr/ZUEE3pvDQe8vIiq1vAYLMY79bZv BKpjfzHPYDfpQrH2nAJj2oz0GhjzuH0MYdHXL83zXB27L4YoCJuf5r/5dy+bV+kydo8uNexG73VA CJjNS3kofGbMNrqtg7OflDTXxSbwquPA9rML5gx71bwSY9YM+NEoa6W3DjiGnf/Vj2XCsSOgU4oP h7h2HUFkACWUc+PHabp8uVgk1gHqAXKaYxjhXU+fcwc/VJ0Iw353l83E23mMfm+c/AOCr87++0kB 6PKobSYj/dsD/8OHeICtrpQ34TtkxuBBQUTSZ00X6bgKEW95jnsYusQlQwUC9PFxtsTZQLQPI36h k1nVVqCmio5umWsUK68vSbOM7uopW/s5nBUwn/yXPxUFTo4lXh3fn4W9ZvC7J6TStukOJaNqPNRR 4i7Jvw/xKTCc0Z9EVVUh5VQF6qgIjlB/gBVzS/w+jjk1Z25QgpqKgpx0EVE35YOhKdnbgh5Va0Cr YAtlL7AvXXUhlQIF9duFjgJzZx9yinFim2nn5HaVSs08SAKdVpP1WobZ9QvmpYcVLozq9PTxzrfc 9Jz0pt5LlpoOrGWP4PquxK/5twzu4jSy1Rq96+Kk8gi95079/QRmy9UtutIUgSLjof0dVHqmyMCo 0K9Lm4Nm/nSYnfGoMLZR3LXfIMW3vi73C67SkLIpcHo+3n/+NJ0aXgEt9oRSvyY7mnqWqIF+7mnh UE3pzR11g2ysbknBLAA87oPMiPudAc+fB+UlQwS5paqPD4zBgEav4bh0fRkZ8VBA/QA3EJo/42i1 Vtevra/FuqZL4W6cWZ3BRGMoYS1JU/TMpvGtgZX7rmO0QhXbiI2S0/iRtQfyc3L9bJYhQ1HUazj6 VpmXYfklYvTnEalOVUoYp0on4pKtGPltzAskfCZjdhSM1+yHI5LXseLXzWcsONF42UuQ5k1gbtx5 do8b7rdTHpJfsnQf8dWn8bK6BMLgkyK0kofUgq01AuJdbOlQEDGsJYqT8bk/V1Euhfho4jkeOni2 4IRLeHLdsA9IXXJW7uIKTGnATwx3Pd1oR3aeB1thHQlTIm0xiwk6hQ2s9c1iXrz+6sQqqYPdPY59 yym6itzJth61GkNofunioOjFoJjTzOC3k1DEacdLgeyW9F/atMzcwtTLUU5vmHeRz0HdjWAGYqVZ P2gxQ/n67rnuXU2PYW57E39DrP0QaNXr8XL7Ac/y99vCsj4cH4n6LK8uIaBEm70SyfddOoMbbTbv XceIKsHWj6XpnI9P1PGiC3v5lJ0aKyYH8AcUTQKoNFoHWWcPZsO4LYaDdmkP3dWCKiCK95FvKKCp OPWn97WDn0EzlJAxjo76JSUdLZdxUctlu3xX57EYp6ZOrSq7JXOhh/sLIV8PT+npxz7z6B4uFC5A QJBFv/+YTY3KgPyqgdQS3lbVSnPbyjhfPD49C61F1RlW/q5tOvp+17+27nk3Nl42N8gqkhhG/H54 PaYLxfsbs1DQ51rNOk3ppWNLdf+S9BLQHYsIWxyHESc7Aa+TRqTJ1u0BL2Xk02rTeMZmofZz+ZlN M7sbNGVi0zuSTXkr7SH4SuO1ckn2+ojOqaGgGGBBB3R/OQTiRyMyoQE4Y5nA0vIn+cTqb2jRDz0z 1PKIog9F/oxSUHHqC5k85BJXSM37+mGwX0n1j8ptGqBXnMN+MYbdPidwI2QbkUkuvOsvz5cMcdhT 3oJSo2UaNHk3VSiLJxWoTG8v5Kl/8REF2efVMWk8TpBm5M3F3ScE7S4mr5AsSQBdNgxiHFG+4Z4d wsIiiHRv3DiG9ZQIQhhrapYkdZAAtOFBHiSFlhGWjIYh9JKg8TmKsmaM94d7IVrkarugyjpQMMx7 2f6I3zj+hNVYEl6ozjry7EvMsxMBetHvB7GEohwEc+yJZAgk/4j9QbTT3uIfD20LbbuDqcxtjfyY vLWGDfXxC8/mwiSp8L8cjkuZJAnEvZqJUkSt109kO02nLPJxIYVomMiBclIijuOGvZzPL4weW59V Rbyz+k6y5qI3len0zBEWja1QagcUbDewZj/T/jScPRl0xw5/lMvxKE4mcdLDXzvBR/LG7EQDwTP+ ZsJM3d7cF3rmZ7SDhrEOm6lM2ZZzniaPRIccB/iiHMuSufXkcG9fIWvJGI3Y25mt3fp3JJp0a22g 6XM1GcfIfeYxFp+Be9VZflNjNdNHnxzS0goaL0XBcsOJZw2sEiPwh2KLABSui6XM6ODlxSFn9jFA +yuk7/GJRbqQ0mUA2/Aw9gE2/hEHO6B6/JVJK6KIy0slVDU11jkx9W8Epp3oAs3PqdAjtsvkqXPT D4LFR8b6qxrV41K36UcZo8DdRm1dtW+ZbXh6pbbrVCbERdN7CZJcXEFQNuRWzfAVbuaoy1ZN/Dty znDV+wWS+0yM/N6yGuqQjnXKc3FMwc/Lx8XU70iEgdBNdV4iexbFgufYEA/BFEce6QuKH51bf2es 3/5s1U2Bosy63e/qtoNy7MnKQJTJP8N4INSQesqCJGHSy4B0f/ptOEL6i8KGRR+j4+AirG3lrIFs DETJ/6yg1afTtqQFdbnGnzlNNVdynivehHLhRVAEayLJYpFkdyG7sPTDm+rJEO9wULkp8eEmdke7 M91lC5vTtU3xq5T+lrtdQJ1jVy2ZPtJYmkftS7Ox4Kz9U+vpu4Vjl7bJQRMt9tl6UxjZnqov1PN+ 2tiF7nGEcepDA3PJN9mqu9hlQ1Y+Tjct6UWcQ9O77VjCSt+aeEvRN5M/Lw3xr7YFZDGPdy8D6xc7 YKCvdO4oLyTHyeRiQiRvp+Vw6ZRXw45jRzJOEONEUXWNz0W2UzhmV427HkzvIrLtTkzl4fambwda Ub4KrftqM5lgTmra/ypk6n3xkgoh8RsxwsziU7JmnyGxBVExUf58h62NP887bjiQ+JbzQ1OGFO2J WshVW/mUJjUFM4yZ8chL7pBfJ/TOwubXJ9VNEFPqWQwxLFSG15XpdtRP49ZOliut5eaVX9uzBu4l 35c+A5Ky0Sh163Skkj9E5jJKxvBZkCZ9nJ+36nNRtDY5vqc3rM98UqZlHTXds+lRdfz947lc+vr6 DaRKRfjaC6rbsqslMzDFxMlo7H7HNqVp8dw9w1aqqk66Ry9kqUpQxYp/HIM34Dwp09SUPVsZz4kI d2ws5THHZgpwn7Df1IM4tK3cHbfp6J1efySY9qf7iqkUlxUCzajIqeUfxCmWtyttVC1/WDAITOVC /tr3gnpvjkJylhd+2TWxJS7oU4+oAUWnxnaICjxsbxckR135lPEoQfoS3zuVHvHorSybdnSCbuCg VewGOzUi+iVCDgaCS0nHyudnspmlGuAGW/2zP+QKFeZLLHI9S3Nnz/R+sHc/FDuih5fKyQty8tC+ NEL3qxZ3DUID4Y/mpMckz4SNzBseivyTtYwLKu71aQ7oMgoDoX2lQJRgOC1X+eUc0Y8kAZiAtj7E jf2FvvPSVY7RCv6fRBgJtynixy8dGEFFMpOGVig0SFaFsAOrCnHGHZAdNfQ6fp1i4+rXB2u4k1k9 s/io7CJ+QBhO1Eo14zdAgZFWWng/fjSSQVYKnp2O2XbSFaJX7g+PkeEvWENECbNYPPIet6ZXnJiQ Mg62rV6NM5Np1k6G+rh2syVT/asjGd2vke4I2CE34W1mSm3SJm0QKmJ+JT21949Jrm8QlgKyxEdN LKi46jIXiD1Qg5lBgtHfNTihB8V0pFMIqpS7m6ltNw/46HaYoMOcDY3GRudKyrBZeNJfY/E2fSsO ggpWwrUN2b31PtGdu2qRai+kouLu8PPn8Dr6uhPvUVf/XJnCRFF0j4HEDQjKZeJjdsY6bkelZN7Q IZNTnPeqqzRtoXE1hxcPUqHQJE4qb/dFJL6AJy1/8HoWEZTVMfHOXHiW3dL6sO+29pafEtb6kizU dMJtM4Doej1qShIOwV4zG0Mr8OwnAnVGeRl3QT51c5Iv5manwZC1X0xzTC48sTWsBEv40rU/Zkgr pNdNT+vvCMD+hiAzEJF9dlcgC8U8LO581TGaDSVxMtyHgHhNADxYMRm3OkzB5V7E1e6JBVa1S+8b qphpWNlW+q4FPnqRk5rqbkmowJdPTyV6wNDe935fU0oeiswnzazHQPe+GkavK1RMBmrMj+T4/haO C+pb3Z7K3B6azzjx5pnxXjtcKiFqUZeAhnA/LbBKURHSRQrQ1wmbJvdU62ypU1pEO0fKumQrstwf gS0k5Eh5r+4+YKiLJ+WTXy8UoBHmq9Vepbd6eUWZvkR1kqTzSVuVIrJcO8xGzUD69VxykLitdio4 /Ef31naCnfiJl/awT2viDvPNg2ux0F4tzlIer6EyFCSIHcEUR7jBuIjOWySfxuKx8/UsFWNYQzCK KJ4LG3HK2lr60C8vk7UTOmoMj1AVaCHoP+GCcm19DONZwhA7jeC4B6laIaLvt61W/+ChxBgQehLj cfw2SI9B7KPym3h0qrsBEUrS/0vFa6eTq8qKnkR0+vUafMDPdCkTxfHsNdh8kTZ9jqh8YCbPVR5m aPZUsi5OD4xm/B5sVl/FBqTiq9ETLFXYLErfIPdwDfZNMr7B8w5WOBe09ajLaURUzpXHi4P3OTzt 9GLxvHhIzBLmfA5pAQfQFCN59QQugEwZyEj0kz64lBDXS27Q1cid4pPY7pwheqVp38lIyUzkzcSk 38Q+6iBvBLQRL9++bho29KD99nPJJPuZDcUSLDyODQcmVeVanPZpS9sodTeGBAZvIkSt1QfjriWZ REcC1QYdRK75rl2hQ1gjTbQQjOS9SzW8oXJ3+TtPIqHJkC3tjKt2LTKCyjyVy8haSjGe4qi8r6Ij eygQrYuN489ql/wcErQcShDIcLmopXqJCTUFGzB8TRA4GsqfmELTPdwru0k1gisjGYqYvQR/KxTp RiuK+q3Qr8/O/SRu69WSr0Ke15PAKlTXkoR6T4u2hiXH4FoeMDBYQNm04rnx9pAIeEvWH2rbFBjT H0Doda56nXzCjk18txqTBL9O6OPL8TnaABWuDdO8Pdt8ReRG8Whhl7F8uMYy1w/mnKkaPnEsJES2 KdaUrJpf/pZakGGdzDwxnH44XHASgyEy2/ugpIvGJ8upNc3n1yZXGzF8iMGLolnalsT6U7tcYtbQ p8V2Ui9VBFhyiraYwlXPmlbWctaeOyvc8BchVMAgpipmMcXqOxLczrr78Le8dekyRH29TMZXNtPP xzR2DkkCe30reFaXSw4e+bfk54DqhLf7fhUFzLE7REc59tjHZMvWgaReFUFa1pwvV/kshd9V7H2U onYUuuTsKgDRxFo0KU0k27x9zPMZ9kVnsp6k6TW5UEIJX4x6RIguuGSyfFoITFvoT12UPN8DJ3sj N5xLGRDXXfTq+mlYkcQUvxXQuHN8Flp0mO+pJ7MKxJYPbRm6+eXWX/GDT4my2oPuRn2YEtVR6L0U hNPeUwmmCAxxgHS34CqP/k+2ma1WekjCVvNf87ftRFz66GzB8fPM5lEBbgzz3KqFTi9iPAPT6Sod VI8u4gkRixJyQsm0Ojjx6jYAJ97azsWAltrSgonXSv6CyOMYZFNIopiNCszGvoS6K2MS7FG2KYQm M0V+71ZbNvhDL308GdffY1R+tvKGT59WaTIcRXflS2rHK69qm/odHI+0pqBWRtfMLpLNp8OvCPvc L1LFPryfDWkInXSeRLP303cJ1JhqSw687ehwkMlipS6ZkVpS2GVydobJ1rXTuNZ7xtxD/vB+dRAl hGdE9gLzzFGLYt91a27QhFAoQ/eTm/b9pouq6ZgpCqjZbPcXWryjdFREpxtTym0KNNFDrNVC7dia L4HQbzlZupwuxMWbHjqZ5sTfkczTuo0cn/Az3gHoHqB5+kNv6LFdt/iYU+hb+QsjBnR5wgSOI35q BLNO8gQxaylXwWT3qfk634LYpcj1ptLYPuPDZlE+IcfxVXFzevP8VDc8Gp3g3sXk+9A4H6Mchpu7 gH2uc/ihzvm5WOaeCS2pe6t0xkJ4jEANfoqHC8Vp2XmMfKDVrfDe05DTZ2jCQy9EOjfIM8YzVCSx GuJKEwNf3/BZtop/bzbZrIXCviK9ErFFb+uK494Vklce6uWozHXYL/lIh09W3inahCNgKZMiq0AV DqvdbHfjZTBmwNV+64RWuICPL83hPCTazw8hq46y0TLBOVshZRdWa8tAoXKRyJYXB9vMR1qSFtVn +cA1S2kSeuBqMMqeZjDqKGZnSY1ya5jb7djqp+A7plaEon4WSlKcRQC5RfLt+SWyaWwjs59YghJp QgM3pJLzb7fxU2Xhw4hiZxpsmkv3r4UOKMXbFeV1unAO0m3+Og8MMCtI36grBtRmJIAQjaiFVrwQ N0kOprVNuKQoMWipPM1SvKklGzUReAXR3zvxlAmjfKMcL3d3fnub8XsTH+I7mWYAepmy/M0RzDl/ svg87AnsIO5/r4iBPNcP15aeKG80UHDcQXIr68YQK43FdhlPEBXD4jLYLnsCzIbVoCMiV1LhM7Jz VSetYfHUlI4KIPgYYZ994D3/pVLAguA1tKm4R+WLPkcHjy0gyayZy7wkqorvnX7PCUD+guAY9nv8 jMO87F08yw4am3DNXjjnI8kwuX637idGhUfTtB3hiXu6pUDmjg3s22Jk3V7jI3uu1KW0HZEWmlO2 Gagw6VBb3+r59PfHKKf+ckttGLxtmJTh2az+OjWZe+fxGO3I/tkUpTFDcJGld1CzB3eXBhC9NMgP Mm6B2Fzbb21XMcO7oVKJVeGIfSbHd/TbsKKnvHiGT4YDI+yNYTYb1zwyPjSyBpM4OTor1GnHD/JJ fZt454wq3MkcJxYxyO10ebMYeWHo5iBHaL17OjxOakuhLIzvX+v81dteQonDsAKZgsVOnQfPN808 2LCZLNwVSiHQvWQEx8eqvW4S3UqD3jgQCxNhSnpy5+DqppW9Wcx5GpR4OluJ2WcAWW6mE9YLHWoh WI2xdM0V5C7Ib2tMVCO/YXJ7H3rfFhshJIu4GXm87+xtsDZiIeE/K3+Xe8rHKsjrUglYWrXdjGgZ i6Ezbo2MF2BrCFthZGOzclDdKGSC8LBV4aL/Idiwvi2blPAr5Cn7dFhYbmrEQRwwEc9alZPzGr+4 6Rt3+vBowPdAEUcPcbv08E6puJgCfyxgBGUP3lbQ5kaCjm+MkD6NyeLpq88Y6YWfTJj4CCLSYbwG gTg7xVHaRl3MBOHEpLfugtnx5u/O6++j+D2FhbzoqRmsKnCwH8mCJfjMDmp1W888Q6WzjqNH86TU ahlVWtI2xNhv8jkXexleM5E+QvOlcTNJtcp8IVwefSfDV7KfDFo3CUG39LDQ53yU3hUfXVIpHGt8 UpfwZV7TRMORVnK1JCAxtaqFvPtQWqeQo1TrEf71cMCvi1XoOL0n/uF4g9XFYudArWnmdnr7nQMl zz0iX55PjlQXxJC9DOm3S8aDZQ3R2u4D1Hvpb0fHztOWADIcoDJLjfidpivGiXauWUoNWT9J7L3O tKiBzYQaE4Tj/sovlxYe6o11X4zqfTIHU26jKCxU8t8L5a9GdgD5AgeK5fbiSJflyOiXkkFtJjpb EdM5C4+RyAJbEaKIs7Da0JfOPfT1ob2HiwyItaXF2iiJDeH1pU7mvvtehC9KCojEN2L4r21uRFQJ p7ABFBfku01LnFGYHjQ5pkIRHOmjKflrAfp8KNKnfhB7E9DwaLrThyZ9mnhet0ofjZ93NOzTRZlH Q2pNZph/Lc0zvT4njy9xfMW1F1N7ibw+UFoX1a0hqG2Ra5iSaZfUU3uXUWZRDWMU/dn7fGkvR9aW P/ou6FVQMjC20oOhDPmSW1DKnOs1RG2LLALk2XR2GPtx0RU3riwtcuE1DO5ZY3nPC/nmYUnxB4Kg 23tKQQTcXdcM155CMz5AYF8oqSNRMQb/VZeozz4VxKa9pe+Vsmf0DLyT6GhDno5I6Nts8gAcunBy pYaiHu+6RX0yeai89/gsbqMONTSNFm7fLP9JRraJdgd3iVSSsAHysajWXE0EDv8AhIsuaLUX9Maa noZZEXe4QtmGAmHi1DWd1uTAcoDfhZH4svouQko12FJ+xMWY97cLmYYjA8yVDcv3tsZvLr9cy0eK autMqR3zFX/DCItMwZB/jd5x+jCIJXD+K2W+mWHGDf+9P2tp41zt2OKc9pJjejcU9xLvyCt22tGC 9LRUPyT6sSBSeZpQ1QjyV+eslrG7FL53nb5mAoRp1pc3sNauyFUZTbpu6F9rMY1z2Yi0C5aS7pB9 Bv2hL9r6MUzpQgjPrp3OHU7cuVtHUl69l2khnJWEOV+G0rkRawubEUbTqCSVGLd60UDA1ApROnUf s4QQNX03Gt+xmiqfThR4hoEe5dxzql+YIo4kidaUDPLiceJ4kWsos2VW19DjpJKXYWYo6+wrn3d4 nyuC5o0KHXLQYUr2FvDqb1xUH2B1Okb2hWtx81tPCJOkEh46LW9nJytbes7zmWUwimwCtuIcx+86 zEe+8xpttLAepDF+tPJbTtkb+m6H6/saEggh91N1qfRTBdN+JaMjqIdCRf6e8CvU56DNWKyDPM7w 965Wkz7Ry9JmEbrcGpTm/lHaUF+vevA7qfl2vvs2BaJ6dgO3EiPZ/N5q+T523OK7qU/zffocTTFS hUKALsJuio9SY+lpNjFKpjrnxoukkRFDss3UG392fSANbw/tqSbBqcaBbWYDzUbw5UdjM2tFMG9D XQd8qj+XhCxTl0tuaFe2p6E6pKmNxeR2SyI+IgNB5BQaahYCc89GSSXBnJ56cBXtkNjz+41e6t+k h4zbQ6mHC4Mn0HgqoUaXgb0f6I0QNH9C9vaxklOKRhQOGq0nwlC0kWyFx0lf/SbNgbZ7Pc6kgnB4 XNm9mEKb45RINrS8cIT2DXSbZTzF4iGPSxjI5A+jcsmlsy7b2dQnrjr64c935yNGpTl2DhqCIXDD iufuIdnI4JNdJaG2QiN/f5HwYrVz7fBS9JvhYwQ8jO4P857sNJ5WIH6DZvZL8iU3xwqJXSa1mNdm X6Ylz8THOxKhmKNeR16U83w/nN+Ry1oTYzTanx3zeSCCO99PiRRnNXLnUrcnGKHwcnsewHXWsU2c 8zcGSZIF1AnC0KnT1HfeKCmoozXxGOE88OEgnDx/z8N3hASuCHyyvXIuNqxNLv2AU5gSDiV65CMk 4m3txPMr2onCzKih77wIURljmGQ3Hn58+iQ3MfqsM2Th8iYlNT1QNSIggLoGmEAwg3M06gJUNuZ7 W2q7Ufl9Trg7Z4W5e1cK1xaOUgvbqEFfUGTYxW5Fr6br9cWae+MarvhYP/EVI2yMmup6QmkKmsXX kTNirZrityvc4RJPCGI12tMqtvOVSp+BA2NTHknaWLxaRgv2o3e1yxUeGXD05tsDThFzxhmzgpW9 eQByY8LmmqkUhDvafKZSwKvDBk5Vs8karhXfcv45RJwIjxnUU09xHCoi+WYmidgykvKUNxwvWsTh Yv2P+NDcGSl6r4/LnrTin5Rg2XtSrfcs2Eds0ffypAlszh+BPXoTwnrjUIS3n5pDvPzdPCu1ZZlS ULcopw+K3OtV043NUg3zLz6QLfp+mT8URhdaO7n1yBaokretd4FJ1dD6NMVd1MJ/6KvS78i5YLvG DfFOK1em9xcSNdQZqplCA4mFYcoEHP7vNG4ISfOgWtdPM5iVX3NAaBRU5RWrorUvlw/qMLq+MaS+ +6obQLdXzmkyAWwXv+3cTIL3JSHljzoSqfNusxVLHFDWiFCKIY+bcRINI364H5dXn4lb9b8vqHCQ 3vXMzPKFCiVu1jNsierCZYOiuwXai84P6t+wyWaNi6l06yg9vMXfY+djqNkLbMZSEkRnMVim28z1 q6ViDjAQ4XzTc88l5JtjS9EFELX8kJpyaBP9EZhlm9Wls2NtCGSnxRbHh0ji5oPvewqnB555Ta7K QOUVGYZz8EpN3lVYWKtNT4OwxkNXEHssiDhFXHQF3Oa5uV51KxaJPAHx7WMTjVrlxc2Aj4ODGG04 /OcUqYakAiALQwrSYoSM4f44SZYp9gjdEZedYOVFuooODUHHB9a5HIzc+2YbXFQMLBr5vs0C+OTW Tc4v79J8qHee7HYSNfGXIAqq23Wvd9Ta7r5OctLcGbwhCotqBeRC1eQ8+bd9kMEzkx9LuJrAc/ft /PCVXcDY8pNu8KLCzW2VoeahEAXTN17+tCb0s86Ah73hkmvGlhrM4plj5BSz6UJCUcLXL4Wg5f7h b5R4gI2d+rad7Q/TSvaPR4qUFFdKFMT1iodfG8daFCSXjd03yOKDc5c+DzlQ4DC5Bk2Yp8GFDVtC FYAyIFiCRmm5kESbyHCiVwco5e7L7+2Iu/JlccfjBymc911OdkeNVSCFbsY7tNVJFSHdanG3Go2j PJSx5IcED4D57wVVck141+GjN7DIbwhr/dENDezigp+mmzmdrFTXE4yFm+dvzJO3mZrMtNmZt5bX Ic7qjJmCbdMgkOE1hWNdz06ys0HohMW0BPREGqRo7WXDD867otZ0WbP99E6E4zKfZRWHPdN6UR1D ymgkRBVrcJofkPpgO4IyMEoBBJT2GM0fWrzxzKYi17N+LPkaKgwW3uy7S4dOTdNItVmTMiFmCla3 GpsfHgaZP9XgvSves2fhPh7c4eMv0HFCKXBBdWjdpd9nxVC5Rjs4FOuT+y6wXkSgzlvVBEwugTU8 cKUJWyenKSvdVrBA7+rvVsl+lMpKzsoOZXG+F/LOxdHpu2GIORk23vhyHovwc528+D6QfviCBOjM JJxc9vMuY1DB+6xqLOJduP+SVL/JrnnzCi8NLkaoKEl2S2MzTXwhyXACTo/YR42Nsgfadun+DEl4 T+mDRDxRwY/a/qnkX9ZkG7KARzMoDirQ0oNhscqanTsT6drrBEhwOyHz7U6EcS0rsCuYLXNvo+1O rMrCMcCoATzFlZgoy9lJ6o9rskQjNHmjG3w9rArhNz4f8Z/0/egHEZh/sMbsNRaUjgu35Z9/fGNj TqDIb9oakwmLtxqbTecbS8uG683kc7u6F1EsDY1PCu/bz/rV+4nN+Mya365ULem7A6eB/MFuUh1N DY5Wb8UMezXMxehc111Jr1pg4L4Lra16E4FyKoGUOfndGwmgulT9Rfw1c0IVM3cIvYTxNMeSZQ0d n3ftID7WfHnDSVQTA+bzxypDnV8eRDVmU/jfZzwpUFHmVe8u2PbQgbEGAu8KxSrdpxTnNZ5niNXj j94/Jxc+ZTIlve/JOBI9WESPgH+fY0k9gj5qKb7PhLmcw8HlBxspSK+R27KkolXW+k7PyF/75Wz1 CXp75h3sOFSjRyVCgqWx3/1gOZS7zksLAtdDVsfMB0PazFOd4/es/k/6NpW1NGJ7TK2lvcfMKzQo 1YHWTa3H0vv+M1+/+fl/wSamW2tZWt/ZjuA4WSIuVWJ/nvlxiWaKXYXP7kycXcNEZwbVv9r3XuUV Yl2ex7AUelS8/7cO2SxnzfEzDkfvYDuiBRkco30sfo1sMZHmIE+wQ6pkBdKsEt4Cx/narCilNYWh qp42QjCjGaZowDGVOHnqz528hwYcjph6iRPBpKiHdfeHRHhODLpiyza9PBjNcTzzp1cRgfLKORr0 a6NnRbpJXm7SMblH1SEb+LG9EG3xMw5h5vDd3SlMfKRaFwU9xodSuUhts1MStNL+qvRXggqHdM4D ex324Y8duL8Ix9eRpjiLE+E7yTlU2NLLZ1+pRik1rWLhHIHNz7x4g123XrwYMYlwoFrmnkIZ7VuR PNga4judgZHL5gcfZa7PKn1sWidSryKKJViO+SleeH4lCoNRE2p6iogz2XpkmFjD3HH+dZxnsIWm PXQOk1dJzGVyqTS4MGSSW7LKP3cn4NhhOZF9ouPjFd5S9n8caJ3Fz8sYr0saocZNOsK0NNVNe4wk nbLFh6nytYZOuPdHt9OyUAdKrdN/j7dTko93Wp9P2lK9bJtWuqAwxUTqQHyJ6CecP/VSfcoTGThn 3e39HaMhcoQevDgybx8daiGpkMkx3Ds4OgqvW+o6/92TmXcX/r1A1ZPOcWzz5uCHkQp2Q67CnQeK gXIidZ+tj83AUlEOs4+F/SvrA0uUYxM2SjTz5e179H3xeDSM9R1JOJp0hPcwP0PZNxoNWTx8/Rku gxHOLgKHV3h4xEW+SrCOVjpmuYZu9qcXOQTBitDy6quFmM6dL/OcB0VPBr+t44p5Tp+K7EZMGJ6/ 9ppBFXJ8ItIaRnCfMJO9Lmh+adTpUIC9pmZJJ9exiW28l4LAtX/1elC3YNCoW6aa/vya/8pg4Or5 olzxkcUzGHex9oNox44aLocJk8t32Oc21M0xJ+gyol2ryCB/8muJx0dis/44WrKfVNjNxnJE0mTB Z3nxfO6PVCW/0Jt1ytBtjr8QbLis908i+wbBng07rilhpgn7Tbd7R7bJsB+ku3ZC93zRu6hcf4gJ 7LBm8pxRKw/frx59CCJBPGgZee7NzN4I62q/wTGcjGlGNHpnTpsakylAz4EHynUCkWlj5YZtm5ef Omclcpdpv6EJTh7fCXKaSTCE2BCe+CocqddNfMwbsjMnYyN7tz5PiVth1jgzb5ftHHuyUiqLH2Fe 8B1Bd1jrY0DmzHZ6i7jr248oVUKplFClWFs3sk5WR8XWPNHTcBrUL3xnp/5U+IjdWRLJqyH2JSY/ cQ58y8yCMfj46nHM40dr9LmXAjcasU8RrcoqiuJPdxk6vuVakJXuuT7qZs+Xh7Hr1gt3ZOP7VV00 da1o4MxFjDr3Qf0as9oG9XMXVvMz75nTU12e5+UlHSPYE0aruYcjppxDW1Oy8L2hjWWS1vSvPOzl UEMuztEa9PV4VHBCCVAWDnzHHP+ibVHIo0w3qjX6+1P4c7hzmV9E3ZmLLQOUc57IbwASPv8MBa/S fWYO07BhHHG9aTQcc8rhmOmNlD3xG9JvkW5+NezTuGiRK7mW7+d0tUap+oFlKwcrbFNVMP2xqwbN 6Bcq6x/2XUjLP+cVM7eJJGf/WIwao4C8TfMi88eE6zL+cpVm11+jP3qH7xjlNuKhPv2TwfqtrE10 iUcar/2XmQyaIhlX9jf5Gx6rQHMLeYTrzwvqKT9caBJWD6M2oRVuPdqZoO+85g41M2XlVucWezU0 oGvbvvjW7Ml+x7ks8VgyFKdmzZI6blgA/rwKp3+ZNQ6GlTspEesefOjw0s6OlJPJCCwKfXI6S9kt XFAK1ix51yyFG4vYM10LWTG2Px2Q3e6WZ7IIFBOV8N9jK0PKHDe1AdA/lO3yUc7GNSOIa848lpRY rR4UCXRPjTASwfC64W+5ryUrvCu3QvnWsPrjR15iFT+cnJ+lfqw6p84r9swK8pHuFxPdwkJ2Z+vC KZILwXFNC5J1J5Sn9muE95Kbra4LnxWWv6h94axmug/77nwDcjnGaLVg9VaPaJB7hM48+WhGxvDF TicudmBSb65qmFz7Yiq7DOp4SIXIPCcPfYYE5K8FGcPDFaujUyj0tLhiafEhMt6GPu9GFHrw87dV 3n0U5Y0LzYsuSQsiwSF+vGMfpdP429DtjoRgjh9KSZAtPvYYRlV4pjk4iRgrDFhhRr0gHYUfnFwN PdJ6jBwJivGoLHnpk6Tx7LHfYOZm3TOFUrtE4UfIiahQCdRbVB9gPlzm91b4DQnY8y9qbDXYX72s LHBZylovdyFyVZVxH4ccICfWjCCzQRp8Ak3h1mQ8ttQhio46UGX47CXtrzwAMTS1gJ1vowx2ZkbV 6qkWibFkXzePgPtqD2Oyzt5aTl1Wp+X96rPre4f+c7BV/CYe7E7DSRBU5kdU7vC4kJO8uTZftrXh 12rgInyEpEDPwSjup5udqaKnqooP+K+4aCcbj5ZdMW0c6tpofUwsiDdm6qXB52d9AhsGUColI7oR JkdGQ6BUoZ+C5Am8Wx2msvofdh/KmbDwRhaHuNyXE8LW6PNJ9qPg0VJpf5BVFhxz2DTDvI0KDHiZ ZMytGbEt74rlSfJ/w42/Ivrqw+Mo6eTQ/dLhXHVyJkpUnz896d6JDGOLq498v9ScLyG43hSVhkfJ 7jWDbGBeIkjei8vvbqEd5FzQBc9z3STeTEVjE5uJmS7cQdtVrCnyftknYPXKVfJ+t+mNzDkTVrNa k+BsRIA498NgZr6q/gLTJNcYUZTDVyKX8ER5CGxeDhs+Qdeb8PEKy7pfzkZQ+HJ2IyKgfb77YDfY tDg/ONOjoYHHfiN+VwcyeGVkGrwieLmAFR4tjLvLs7uWWss7CbYMV78umLf0kaRX2Wc5Sn/Pksg1 sRNGFodA+4W16OI4pwgCAXHS74fbULcMQbhinzoYQ+UquEPrRgyOfbNFAu2IbHOaBfKD+gwoYJ2n vOet4C0NyBCLr2U5SC0LS+DazKUs8o7945kira8KtFGv9XOnwhzs7bPdqbI8nUUevzEcoqjC2nEA 4NT4rb59jF1Xcx0IpLJFIXFb2+aQjgTkplbSdfOdb3uM+pYViIGwAI3cJcFa/nsSI74S1GX0Faxr lRq5RI8oZnDCVkUT5y4WvcN3lCJylElVQkxEMwsECcVe8US1pqiH1Akl3MLi4ljVvqAodt2N4Cxh Bot0WbNX+dMqIOsRE4TTl60W7K6QTa9JxetVAXM/Bv+V+/RuQsY6U4mVwBcUPslPzNbIEThxgAjG wpi09qXC2cNwbeF7SW2VuiglkzmN7HPNgYGKiTCdj/CdjvV2gzWgl8aWiDZi3Kk9yIxRdU+lJstv 1yNmMyLEmU+SUX3SZ4Hjn83QVs4kg+2A50kTK/drozubAZ01Zo3vw7PoVaxPBKIcDPzRvAdkeqfQ NZMHorWNPhsLRRDzVRRRG0V8CeF2M2fldP+Cteif0ii1nqxZiBhQsbNLzIGJOgvX0E1RncwgFTAk Pom9uwQNfLE2o9edQvgYMO7GFwbqchg7CI3s8EJLU9lt8EWViyCdbv50HljRTjTUYCwHT4o7+J4j X0+JmW62Xpd9lx6NVj+6dVgJeTdTglEfumLORqLe0lJpPWPcPTQ1hjSbsHa3knj68UUhNRj9wbaT 9vGeVN2yge0MpmeFxqhDVnGXk2z6Wufd+keL+gAQ/nspiuHl+KPN9fII4diGcesCtwbavEUpwdl5 LbRLUH6GYHPr5W6X4kwUZ5J3nEbo9QfttYg8iyQHpJjVm4wE4B4kqV34nubZgCmQiJqdCFKXS/w4 2H9nt0ZjzDeChw2Zvx+nzlO4OHlkNU5qW6G59sj4AWRsVzwXsG7NbCKmcCQuTS54SfVpeTG4u3O/ VNmzSGz31tmOC2XXI09/41WWzsdtU5BbDL3aAs0Z7+JnQuURd3UprKc0r4RjJDz+JNebXc7QWTf6 C57TRcUCzUCR6OOM4ohiWRZGNs7aD9Jp/kWxnZmUr6zHoTDvyBT8mFllL29wfPdCFd65+xRZUOXG nbBzxXSXZ+MT4wO01tQE+uJ4uMt8xMllrrEpelq68k6KnN8wMTTHjPtk1KTOqIH3ut2YyuWDYV9/ akaIPV9Zul4a0yGjjC1tVmXO/RCKTm9UxwqFM3t5bVEp358PklgntJub145vlUxLoSWXyy7FSbXv sjMKGt3MoMlOWRTv9Ekn9QKVcrWtq6xpmieM9+sh7lZ0X8XPdYflqgXXvBb7PE8U9aM1DUcgL5Jp np0RDGBdKGpH+16T+h/lueyGnY44Bxf5xiF2QZrteBZlLHf2UW5SZCyh8lMKZn9ibn5JjlEWEF2j wCcK9RdibgdpS95tpjWk9PeNfPpeVWKULMaKqxIiVkXtVbMgtjSCn4KJmy4Db9CcVpvCy03PYCCo XKhagUKwjTLAx1CPBmycoXpyvsK3fQerbVig3IhGcdwvsYQ9kjoa6x0pfM8uVM32//KD9P9v8P+J DcxsgSbOrg52Js42SEj/C4n9hM8KZW5kc3RyZWFtCmVuZG9iagoxNyAwIG9iago8PAovVHlwZS9G b250RGVzY3JpcHRvcgovQ2FwSGVpZ2h0IDg1MAovQXNjZW50IDg1MAovRGVzY2VudCAtMjAwCi9G b250QkJveFstNTggLTI1MCAxMTk1IDc1MF0KL0ZvbnROYW1lL1hCSkRTQitDTUJYOQovSXRhbGlj QW5nbGUgMAovU3RlbVYgMTE3Ci9Gb250RmlsZSAxNiAwIFIKL0ZsYWdzIDQKPj4KZW5kb2JqCjE2 IDAgb2JqCjw8Ci9GaWx0ZXJbL0ZsYXRlRGVjb2RlXQovTGVuZ3RoMSAxMDIxCi9MZW5ndGgyIDM1 ODEKL0xlbmd0aDMgNTMzCi9MZW5ndGggNDI4MAo+PgpzdHJlYW0KeNrtlnk8VH+4xxGlsVOWbAeR fWYwdtllCZMlEjEYGWZhjGXsWbMvpbKv2RMh2VJEVMi+lKQGZZctEneq++vX/f3uP/d1/7uve84/ 5/18P+d5Puf5Pud1jrAA3FxK0xnniNTDYQlSUGmoMqBtrGWtBEClISBhYW08EkFA4bA6CAJSGYAq KUEBTe+rgAwEgMory8ory8BAIGFAG+dBxKOuuhIAUW2xHyoFQBODxKOcEFjAGEFwRWLISZwQaMAc 54RCEojSAKCJRgNmP27xAsyQXki8D9JZGgSCQgFnlBMBcEReRWFB4B+eDLAuOEDhV9jZ2+OvJR8k 3ovsCxAl+xQDyC6dcVg0EXBGuoDAJjhyNSTZy//Y1n/j6p/J9bzRaBME5kf6H3361zICg0IT/1OA w3h4E5B4wBjnjMRj/ym1Qv7ypoVD/6uKAQGBRjlpYq+ikQDkVwjlpYfyQzrDUQQnV8AFgfZC/owj sc7/tEDu2k8DYGstQx1zLYlfG/prEY5AYQkWRI/faX+ofzL0byY3B4/yAy5DpCEQKFlIPv+6svtH MV2sE84ZhSWPBEweQODxCCKIPBtkggEBUACFdUb6AUg/smOwNBZHIN8CkFsSBLjg8KAfuyknD4A9 yFuCc/4R/xVSAsA4LPI3wyAAmOCL+5uhZHbFI/9QyABgF5w3/ndAHgaANX+TAjmB3m9SlAPAFr+J PBJgxN+kCIAd/yayEaffBCU/Pxj5B8oC4Kt/ILkk6g8kZ0L/jVByUfwfSBZ7/YHkJhB+4r83UksL 5xcgBVMEpGTIjYBClWCAAgwS9F+FlliUpzfSQIfcKwhEQV7hZ9TJG49HYgk/XxzykPzFLijySCGR fkgnUGbWSRSlvSSvxJbD5pMRQaum3lE4qPXu8h3Ydh57f/caHZpGeswtOtIdvjnOsLcIj7/9VZRf /XpNsLFK8pPtKx1E4qnKt+ziLi9bLn/YUr6XMC81wFZvQwVuW0HGN9pfrpXIgwVcoWGa+uKcR/B4 vN4pwPXw28jz4McTzpU2Eo97xmtJsbPNFMpOI7q+RqkS2fbb1UexfdrONmycxGoZtiBMmGzkgeWG hpRlyFCdvvt8MsvAVluVLf857NzalZrBF4si6dY1N81Ybtey7vcNR4WoJrUeoRs7OX44ydura8Rh 4n/qdn3uvMecL9WF7OxModFTTyJOj9gPTxUY9K/Vu+cqH35+/U7AluquuPtzT8tD9/gm21Fn90Ko sGFnbB8SdCtI5YwQ9FEAZg1j0zjOVPF5t6+SmS0TcVr/xFRue9qy1kB9L0s76XEFNA7Y4ilov3HU alZOuaFl7VM0iIH1neneS3Tt99ZJfR7wywiNBLVk6QyZY3Ti2703OAqVtYoUrZ6eqN3soLBdvUm5 3t40NJcCHztxmbhrm7W3Uwh74DunbVNL2C6cT2Q1fEpCWLLsaN9Ddo75aShHHGGuNKC6Y88cMqRK YeB49rwBesh8sEpcn5qF3k0LpLg0O/IA1vnROirvTpCoCYLZLACpwi3p2iW/qgWT5wS9eJOmr726 OVEq7FrC9jCsk/CRiah+XHnV2xbJyOjp3f6RLSpNQCp3IWC4PtS27HhkjVxXy8n8jL33bbVHnZxe nBV2ba/UvVSc2wFe1FFBnFbRpW0wM76tJx9pG959Ils/0/WAs9XAk73MXJv1wnTr8T1e6W10ZOPt CrB7ICb7OLpOCaqQu+sHzqO3V209Si1ixx7Dv2/qQsqD+CKHIjrES5VNTGMqiauJPiuvI+Af9XBN W6aRMqYgU+pWilftUjIkNknzgfPUKueO6MArDSPU1nWTZ4X4DCRYhvMoWDpG5zaCRWSW29CHSlSj BmJtj/ZolQU19lfVvRSVeqpXFnhtwDACrMqz4f2kxR073t5jkJu7XnGmwwWLQ4rt8W+b8/tV3Ys/ 3wjSkV1wiSnls2Dm1P7kRe9AA95+i/Z+eeu+wj0du7VKg6+35yMxq06l8C6Hi2mIS/A6GxeTqxpO ZSkn+vkYP7y3Iw5iQxav9dUfL9jYS7h5HF29JPKtmc02/K455WyVWZnb6Enx2IiSwfK1Bh+3ja5g GxNlB79KHqz7zEi1H/28rX4br07jSYzymtOZN+uJ3PrAu6t2Xq+wEdr8nQw+SwtDGxXo5hLxRwMZ 8cN2YqzqYlfAShleDqNd707xI0XlofXBudQ2hd9gMQsVZS9N6VS7/ThlwMv6Y2ztTYwTlxDRvX3z I8+trPsziz5IgSb3a26bCvsLl36M/Xhz+hSmnaTa/v2S2AqqWdw3Vup1b2CZbDO8NJlHoXhtk0OI h6snpDTBnxbOsrGrfgAMtj6uxz/ppXWq+sqQOihkvlYe3p34qGHsxNbWInokQ+ROacJn5JLQOmM+ 8uXz0RPCcpWMKKOy9BAxesUPV1zYvpSl3ggPoGAsCbv/2T5K2X/Q/WnmiGrx+/jxMIbAks9JNGu0 sSrLMOJ5iCUDqdhU5+CpfieaS9Qveibx+fc3goiBlEhHOm/+Y9EUId27+cqJgEVnpp3ByyYmrFcf ca917PBBRrYBlWNPg0IGZwt247HdKuZc1N5NsWtHE+8eiWz04H2NK9J9+qIXwV4DylzoS8gr9Bvs I7GhTJLYIeK0+rOy9fXR0uG5F0kufRmM+lSkKb3YgSsT+f3nsr2eao8N5ct+aJUZTjvILg1RnRh6 A1LEuYnTSwtrXeh2eWSmITB9XPGrWfg6LOeUquSUx149pYHVtE5FCMuAZXJq96WoBHBHRkPHvGln 5dse8Qs5zisJRMDEdQ4z468icT2uq72nu2ImjPg8S0aSuhDo4Rh8N0kcyaUt2q+UZdXlXFK0l9gC FaTaNmpz0o/YWtvgprJo+Ho1dFSdBV+Zl1IfltJsONHeOojIc6hSXc8MFoJ5xtvE3jZPbIw4naKn oxSwx7NrZiXXVLK5FBH+yt0izfBb6Jogk9T+bAuNmulMmhL5UxJlGiJowlqe1nyshXPMYukNXZf6 iaFImfX4qalY3ZpZW1JAksdi+/v6YiErLbvGqSklkdQtEbTfvsb1M+YCQt7cPrQUVXxSqFoqeeMk m2kcjWZg7OYqlPDcNZtokB7h9jTeNdZNF3PacMFbxBot/i52qYJZ92nOF858E6PxnKtK2wosoXjp 6mbbt6SVlv1wycdZcMcSWcuqzxhVlWMXV0bLeeV3YrYhJ5Vy0GGGch8whlFqGyJMjy2bEGqHXdoj SfdOVT8YY5+70FAcEmEaxbC7JxjxlSnOq6/zw71O6TTnc2dzDD5OGlBmeqtjHqtbZUSd9FQRAC6F ekrOdHcK0XtaC4bdomob3JPsmIGqgd1fO4YDD6kX0xnfNzjUAVKYPUz8w0SOgxJJ/fs6fP3UQ76a YwjRVCjuAUfnt2C64f2pFvNxtfrmmwIJG4Fo8QCdME6esRR1RrMr+Yu2wRkChW2F0kYvhjt8J6+w yLzsvpwVVlYiVQZXziH5c1HGt1NGpsbj0y9GUsbwpXheYR9L8z4Q9DCraL13xW9j+czRExTX6Q4d 9kBgSjftczdYdD9cm9aykMi8c84drBwySGeuYSE4jj6837PH+rpRzHjWF/fd51JOlF+xjZc8LGwe GHNhqdQ870g97tgY37lVGPG2rqiuA5s7sKZqlrI89Zmhy/875MZqDOmsfV6kohQJyzBYBMPaoHau L7dbm5byyGRyjHo8ZwaFm6ivwEPj5mRH9uhJ12Aexq9EdUbX6tEmqWpsWTt3prNy1aZ8rhZDPbSd 6Kg3x6UbF16pSa6Xj1Gmnb86Gbuz9fr8/aQl2/IYvh2diTNMHXgWfoOL1lGfu9K37eY0DXqCNqc9 o2c9bX0zvXiV8Ik92g/7uAh8btsUVlU2wSSPZrsHrs2HTix+Qbjoa7Hj1qy+AvwbPEnJ9EafEMkX jzNbh++YfIQpc2jQSYSnwA2wHXG3O45Jnwmql+q/uAQxi1qxk36ylCoQ5hIxGOhxH7Wzpq75BLGs ZF3/hoYVfsxwgEBrOL44WoToh4g1No6o3b6EOPb5U9xuwnq4SxSqszgmsVNuMpuHMeC8EMTJnZEh ntvx5phK9YTUhxQj5v14CvFS87OtQvNcLLqH9Q/pxmtdjZhG4ALvUtiTvU+BS16QjMqSbqXo56I2 KIZjsUYT/ZMr55lfXzIJVyR9sa/cLulzsBhvdAO1CAkVOJy1Uqk41wx7bS/BFDL58gPlwQAyNLSm bS6U/6gqvXcwLwHgeV87rbin3UPNXlCGAL/7WhdYHqd4Kwvnp85ivMgsWehjpRxThDcMP2zA6Pt5 pc4shj1mCj3zfm4PPgF2HT7MyMoUSjxSqLvLcK1EtmVaqMbDgfvtV+DiaxCpcZ6CNUCvSnXh0UGN Uc7eudyhCx7OrI8qhWSQ1BXaXGlLy27VVhUgbscadewCtyXrF8/EGSiW9MCDEx68MXxNZNtrR2q/ ichSy0NQKnq6FHVIybjifY/nbuL5y/mr8zA5/8/W32VlKHXq9kcLMpQynzWZYm+UfDm4zyNsRtdA Z54detCSaLp776CFLSDMreL07EX/xWQ593vBkFsfbD499wfTNuom1aokfIS3YRyW3PbfkDYQw3dt PM6qX2+e31hitZR9Jd8WuVWYQai7cCOCNL6FYg/Ac+3zRBxX5QjYnJfuI6aWP5nhhrxYZwyicfW+ tYQ1eGz4jbB+MdB+93lglP8FLtQZod5KBW/2+DL12boqAcUX/HHg/cvPkg4s+vWlpn3muLSPg/IM Li+l6NtzJ1vo06qEv+ymNPb1ivCUSFSUa5Od8zsjlnJvnmo8vLm6TOh1gbpuDv7Z8Kphsf3+92Jv uveVNPYXrFMmyzXK8p7tYS7D/Wlsfd5sqk19HVO82mSb2hcR0w4BRNntGPBSjVXPfClSNjWV54fd IRgfybbMdTPe4lIZt3Zuhi6fGmKIeFD6fVGBtIOi9LeKQ4WtwAn1ntDCXRqjGRuTlPbAgsUbb1u5 0HzyjoL5XXPvezFPJ7wdCkWfNUzqjjWOLC7xfpEv2agD3y4OSGdqu/HmazUBwmXDHSQSXZpGvGQs vF/nk6yUeGwlZu5hnvPBU4XQRyjX8W30WlnpodPqeYrkAqUe59O9dNmvOIrzW6Iyc29KfppOkJQe Dmb1kcmib+NToAq88KWHX57ob7zBErJ/5JwY1cczUtsmcwkM8YV0DlvNolTGuwUSqylsqfdjjuZd kVTYIVYkWj7Rlo0rM+ISAjpDJZletBbl5M4cLZhQs+9TM5K+D8P0sX/j8rXeQT9eOK2opreiZnCl tyvJ31jmgqUSv2hfRRf70grpaHQZ6/Ka3jBi9KCic0JxrxC6flhFEb+3UxS2bC53JI5GOMmrgJdD ljI6a5XJXLN7613+iiJlR1329A6Cb0GiRU/f3YIhLM7pMGqmeVsgUPNrGOS77xzsmuSmfEbyDJFr 4DRLp6iKXYJemm7eTcq3TYL8pcaj77WarKJN7rTxiXFWl6RHx5dn64ScShN4YvMpUkNohQJM7ziM uMw5M8LShRLxjrqkN9y5svVEjr/brCyn3Gh3xyibRsFT/Ek79yhFc0LzktXrlK1k38Mvll8odF/e fcgqV0VJ/gUPKKGA0/VDNiOnheHW4k8/hlMyb/mY0yItOYBHHBNiFEw+u3q+NNPH1qH9djKM5b66 A1MYda70dGpB2fqq4BNwyP/yAP1/gv8TCZzQSASegMMg8O4g0H8A4zaXhwplbmRzdHJlYW0KZW5k b2JqCjIwIDAgb2JqCjw8Ci9UeXBlL0ZvbnREZXNjcmlwdG9yCi9DYXBIZWlnaHQgODUwCi9Bc2Nl bnQgODUwCi9EZXNjZW50IC0yMDAKL0ZvbnRCQm94Wy0yMCAtMjUwIDExOTMgNzUwXQovRm9udE5h bWUvVFdUQ0laK0NNUjYKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDgzCi9Gb250RmlsZSAxOSAwIFIK L0ZsYWdzIDQKPj4KZW5kb2JqCjE5IDAgb2JqCjw8Ci9GaWx0ZXJbL0ZsYXRlRGVjb2RlXQovTGVu Z3RoMSA3ODAKL0xlbmd0aDIgMTM3OAovTGVuZ3RoMyA1MzMKL0xlbmd0aCAxOTU1Cj4+CnN0cmVh bQp42u1SfTxUex6+FNW4iitJbvlRRNO8YYpR3ibyckcy1Yi8jJmDk5lzpjNnmKGQUoSuUnnbSsWW jd6km9f04iJWySqpJAY3d0MoXVR7aNv9rLv/7Gf/28+e88/5Pt/n93yf8/y+JkZeXIqjEA2GXFAE pzCoDBZgc7zXAAaVTjIxYWMQH4dRZAMfh1iAYWPDAI6yUGBBB4w1LEsbFt2CRDIBbFSiwODQMByY sc2nWGuBoxjCYAEfARw+HgaJCREBXwS4qACGcAUVAEeRCHhPHZECb0gKYRGQkEoiMRhACAtwEAyF wgiJNmXJDQlBwdovsFAm+dqKgDAp4QuYET7NAeFSiCIiBRBCISSaJ0pMgwgv/7Gtf+NqpriLTCTy 5Iun5ImYftfli2GR4u99VCyR4RAGOKgQwpCZVB70xRoHEsIy8cyuG84XwQJHJFQEAfoXCJa6wHJI 6AXjgjAQwhdJoWkcQoQzTRCxTVugbeFtYbv5kqcv9EvPiw8j+BaF5B+qU+TpmvHPmggHg+XAj06l 0xkEkXi/fvnPmOWMCFAhjBArwVwD+BjGV5CI3SAqJohmABgRQnIAyQnDNCqC4sQRQGSyB4SgGGnq Nq2sAS0KwtApdBogVGhfgplCfv9fTk6oPJpC7B/FgkkMYthYgrVM+p5/JW5F4F0yyG0DYNLp9LXW NtOoQIZhEIJPLxKR2dc6BCYShiA5JCDl/EEXVglcvZT8Lmi0utWYV/bnx16kyvw3mcz3uYse1A1p iNSoT3YeTAj3Gm3THP/VKyXjg5mhfeLVGI5tWvX7gLsKxZLC54tWhTRU+HW9YxWl9lGadUp8VWm3 BqCU0kC/YnIuMzpAbcGLYWEuLql6W2Okf2OitTam6qmw0JdcVd9WrDzUU/4NS9DqHOlxlHwy8P0V daSJLfTVWay4YqGzRxxvmfBp64gDZWtsy3XXMJ9reSW5jVSD0a683D5X13W2D/yVu2tMSawTuwsl 58/5JZawdfWXzl5+XX1HFNv8YHpK+JsiW6xIcOdIMuIL9JxjND0rgMcsQ/ufb6/fc35l1LEylcNZ mcUvEuO085/cA25JIwvSko9zbdv381xuSC/u6udBuc2b2F6SmI11KwVq1xJ0Gl6Va1aaZnN35bS7 9KwJ838pv6/icqPULkJ120+c9JOezJI+zHroh6PmqR+bEz/10zu5AxMNJTSgHUlmXbJ5F7c1o/z2 L+WyPJcmFQf66PDQ6OlTJ6jKM6ruOFqwao3ZM2+JlLxFad/z13HvTd/FBDbKD0f2BmVa7nwcq2y8 P2RigbW+VBzwGP3JqiHbZ3srr61C+2anqtGvt6kZHR6GLkjRvry6Y5J0QUXB7Nla+ZTtVKsBh8aY gPGjai6le/8EHdc562GQcMfozEG/4Ic3T/HOhVkYxLHzrxzrXJsRlMd+bJFEXlgk1m9vTJHPs2AX hfaem9uDhIc5UnvTrmoWInqSg1tyNTdPHo/2mn9TRbYLGfRYfWbwQMRCKGfAnizVfx2Nvlw2uT96 pKlbF8WG9Ta3Hw68kZSk36vIBC0d6k5PtnWeRC9tGkpt6WhnSG+NlmuPHZlXv+e5WlLU2Lx+/ey0 yYEUZe25236L9b51rOZ0tUxcGHE6UeB3eFlqtzRHb6X9j6sTXi/k72CMa7bTjXvvmc2KrJ1Ue6Jn cBnT5/J3fubd0S01rjkUU9T0+a2xkfg3a175jtGPFZI8cpBntSnoSqAPJ4lODBomDat51GyMD8Af rZqvepp/lu396JSggmPa5Krat1gNGTy5Orv1Lw773Zz1VNe9brosaSq+nI/XlSdH7suYs0qntNnO xfpsTV4/0tD4ZvZ3FMPP2yo6Hl5rDChIjO/8oNIL3d23sHfWs6v5trVdBXU+D5LHOjS49wfSV4gH a3zn/tzOrH/UEvcq+5OH3cduY1njksz3ebUmybQFz/YCXYr3m8IPJfFH1lXMsxoZedLukJWpDXpf VGngwVG0gvFHB48zqMI4EVPRsb3rKbe/T7d7zsPLbzVaj20ySI9QXjAr+7RIljVx3HpJpO69DGyu v4Z3jY7P/cxIG/43WktKciI7bW3ce/Iz3fba8IadPTLnFrZPxqdltR2O2fZLeYn9smeYCCg5sSfs 7A3M6l2dHIp/hMlm0SPRn0bSPtgnk0MlWvqLVpofGOlpNt8mVm4cHf++0rNgdypnjjv1bvb3ZVHW bfyQyj+KrzBXjHv0Bay/sWLZC5t6TYoWtP+hSW29qnn/48RYCf/bCdW7Gy6lt0xqKSkT3ZZUp5rG QwbLtzbAFOzpvXNBglxKFuUVTy18/ZhFUoBbcID/+ku6uCGXnf8DzZN1s77DmRNRvdk2wlQE/1bX rJx16mTblds+F5jG6iXJ1mfcR66vuBjkvuqi2dujWQXewbVj3ECBLMMqxxCP3X0zjhW+mxubVbq/ HJ9/vTv1ua+p+sXHbi8OzFamweDiXp+zDN0Eu1nno0iVS+sG+hd2RuQh9VokT2zYytO9Ku80kAXA ei/fbLxjV60Zb3/EUlw2lG6UH05Glxtp6A2+7NgxSZYfSLG/0xp7y1Maz7pbnC0fpP+XD+n/Av8T AgIRxMdwVMzHwkmkvwFJVQqZCmVuZHN0cmVhbQplbmRvYmoKMjMgMCBvYmoKPDwKL1R5cGUvRm9u dERlc2NyaXB0b3IKL0NhcEhlaWdodCA4NTAKL0FzY2VudCA4NTAKL0Rlc2NlbnQgLTIwMAovRm9u dEJCb3hbLTMwMSAtMjUwIDExNjQgOTQ2XQovRm9udE5hbWUvVllNUVNRK0NNQlgxMAovSXRhbGlj QW5nbGUgMAovU3RlbVYgMTE0Ci9Gb250RmlsZSAyMiAwIFIKL0ZsYWdzIDQKPj4KZW5kb2JqCjIy IDAgb2JqCjw8Ci9GaWx0ZXJbL0ZsYXRlRGVjb2RlXQovTGVuZ3RoMSAxNDY1Ci9MZW5ndGgyIDk3 NTAKL0xlbmd0aDMgNTMzCi9MZW5ndGggMTA2MzAKPj4Kc3RyZWFtCnja7bRVWJzPtu6LE1yChgAN QYO7u7trgABNow0NTWOB4A7BCZrgEFyCBCcQNLgHdwnuDrv/c+41k7PWuTnPudvP7q8vvt+oUeN9 a1TVR0+jqcMmZQWxBMlDnGBsXOxcwgAZNWlDLk4AFzsnpzQmPb0MFGQBs4M4yVrAQMIALiEhboA8 yBL+Av8L8/EKc/JjYtIDZCDOXlA7G1sYgEmG+Z8sAYCUIwhqB7RwAqhZwGxBjvAiQAswQAcCtAPB vNgBACkwGKD9zxRXgDbIFQR1B1mxY2JycQGs7IAwgCXIxs4Jk+MfW0pO1hCAwL/DVm7O/zXkDoK6 wn0BmP7llBkA92kFcQJ7AaxA1pgc6hC4Hgju5v+zsf8XX/+9uLwbGKxu4fhP+X8163+MWzjagb3+ dwbE0dkNBoIC1CBWIKjTf081AP3bnDQE/D9klGAWYDuglJMNGATg/HfIzlXezhNkpWkHA9oCrC3A rqB/xUFOVv/dArxx/zLAoW+kpqWjxfK/t/Xfo5oWdk4wXS/n/9T9J/1fzPWH4e2B2nkC3nDC+8sF T4Q///Vm+t/U5JyAECs7JxsANx8/wAIKtfDChJ8gOPEBvLkAdk5WIE8AyBNumYPdCQKDTwHAe/Ie YA2BYv6zo1wCfAAOa7t/gv9iXjjaejnbgpz+hPgBHM7wfYNY/QkJATggTqD/MB8ngAPmAfnDXHC2 hYL+yuCGy0DcoH8CPP/ouv+VwQvgcIUv+r+YH+5E6g/BTUj/IQEAh8wfEgRwyP4huDe5/5AA3Jn8 H4KLKv0huILKH4IrqP6HBOHzNP8Q3L32H4JX0flD8Cp6fwheRf8PwZ0Z/ofgF4DD4g/Bxyz/ENw1 8D/ExQmXt/oL4f0E/YX/NPMvhPux+QvhjbT9C+H+7P5CuAmHvxDuAvwXwm04/kH4qeVw+gvhNiB/ IdyG818I14X+hXBd178Q3hjYXwi34fYXwnU9/iA3XNfzL4Trev2F8PXCr52F679X+T9vn7Q0xNOb jQfeNTZu+NGEa/MChHj53/8/M/Wc7FzcQEqy8NPLySkAP0T/RIFuUCjICfavLx5c47/Y2g7+IQCB PEFATH8dLTWmfaY5Ek6St6UMTIET90XhAYGiegKPYLG5mM1vKas+VYwXvRLzdQ6YPvT3fIR1b3fO yu6eBv2UBdkC0wZjJ96L/laaax1ICH53rI8lqX5FwFt19iuN9/4Tlro5gKBx5Jt+p0RyrKgxRxvu teF7agNYWCa3utZ9DVN4gwYdseaMJFVj3ORZUSVQK1WaNmjge/2QrOP8z1/E8xlP4cHqnqoOV4Kp yL/ksLBp3OwRXdHkWfXFtPa3IIOZQWQy+xXUR99zudegGt4VG0wVyCXzyV3IOnLfzdJoH5VWT0f6 /V+5khiwtRigqc/1V81HPC9YmzRLWU2PlzEZiVzu46sLUdxWYSaSn47oPb3+wW0WpL8Lq+DsWkuB eTT9zhMjom7wv0jU2lG5D+/zFlampF+1bRzj1dOwN3zu2Ts+vf+lDAPFpKtg5SD0ROG5BIYk87qi yF7fy4etNOkRK7NcHEwWKy3Jwc6bn8piH7NUML2GeJhrJZdHLph0kyQhYqMf/FVDl8mpDF5xQKiD lq04T4lWJAqkWKiez4qad7+2i+rPCzAiL5SyrPQOKpaPrUhG7/mp99t/OdrO8a6LGWwthDTjG5ET oMnAyEQQUBZKd/lmd+ntVw5UcO+iT4urdTEpaV3Ea94jB1kyl540sbwvL+4zrvDOgl/T5GbiKs29 /Jn3froRwIg0r4UVRYBRdt7puzPt3tpKUroacaacYaHD3uAh5546vKJPJvi7lE1IqBtD+K6GuOkH z1h8tGuGpb4dWjNN2JlACM2d9jY2WbjTi5y3OjnXOXba0aeLU6oA/udP4Vvkp+BMzc6ub9/6bL9E 3lYvBEO3689uEnIsoMKiGCihxj7S3AHmVIfxZ9q0P4qoeQWETpD2ZIiMFTZuu1qtnVQJlOOMNC1i flIsMN/gObWNzXK/3apjJ/oShpuhUhW+GdJLEa8kShhsjE8usK4g3L1bQXfVZXjsaITjTraaMxWk FmZJvX4hwwIy25scsCiqwlnCLJL0Au9Eyoz1JHN8YC0U46xfaJqvmlt+Towpy0hkY9qm9RQUy66w tzMke/K7p+INeA8LvRL5YiICcsOXk1oCNOPx5felIvxAvP7iUeL+C52ZVN6qMwEvrtIUR846bS1f 7dXpefoKtT1Xlu3ETGinyg4+1csU49g905mNBHaE9ezosgrjJDOq2EjAyWMyLzEPeolxr7SCEUz8 WWVcY8sATEFAm7bQiX2R4kFahKIbK3tT1vZIri+OPxcbcaPg1C9rfYW1lJOnZ9YN1lQD6vmEWkmp WF+eM4RiyWL5jc0K/HhYgP/0KP817ZV+Y1EgycJBnhuVhLXzr4owUi4YAWp/OnIt5xHCylcNjYUK zZkeCF8g8QFobHXJLCHk8NmF6ZLv8UC2ql/HPiejB8NlVTVf511H4sV528KLR2YLItw34qTPvuIT lko+EPGvIX+E0PuKsmZ2ezZ5THcYWlDetRFduOkk8FLDSAxAmF3DtCZ4c7DteqNI6RufGwquw8iL B5yz9hF0qe4lEwcl+gjWcBktcawHJs8px5HQTBUtdAfdxOSb+6t2B7I8BgukzKzeflbbzg302Aae D+9mwtXqFofwHcOSn5F2+gSjioYhQ74qd9g9NfuqyuhE1+6MNMQEzG0JCj0XkLrKPRDydkDA9Dx3 fGZ5TMxZnqyYoklmGIr6hamznyfTj82Yp/MZE1goWfkUn2iqzAfbVu13WtfVaUOV1mH9rMhg0NzT wyufOa3w348G6qnOKec8Tx/8A17jhraP0JeKlinh6OPyl3+iiy3WDiU3It8oXCuQCRFqxjnpVPo2 UUuZxsl4wH3KoniMPwl0fyrfLQjuGc+kaj6haxpVpDgx01QLbCHVHlYxtk759Wqu3/EF3xO7t9ir 0vr5JSoBx0CFJCOfqGyEk4oBq4ZirB+3DA0wNiXRZjQZfTfc3Entnl87YyuZ3AooKCHiQWI0lxvP FHUwNolNPenytC9EJTMtHc2l2Yj0D7GmP51tO/vlaVhHXmn9fmpjmCt2uFXuOgz5seuQUV0oFvJd +IKds3CgxceeyCgWFpikPBQAMl5hKvb4vWpnPPz2BEUtCmLfp0uJ0Y1IEF+SXzNEcWWHTg6MMPbJ C+FGqAIT5joQCh1VJriO0P9iGwuqBkaRN/oFgLeWEsVubOenz4gVg1aZANN+6xC9pEpiYcm4zyGE nJt5Y1zc9+7sUhI/MyzeewNwTH3EDJ55EqkEHX83kToFFyOtavGHH5Zi3NpettcI6l+ophgP4Ttn 001neC7ndvEeIOMF6aNWWjZPZe+7ByysZq5f0D7Qr4VtWRnO4gi39OTSI0qYqtQoZ5zmvyShBI9z GymsVaKIvOw0P36Kj8nLkCUxFnAfJHeiSttDTLmr4VYJFNF5bJQRPnVhUyH+dnxbKxLwU11FWJ/X Hd/xB21aflLiSNYwtMNClZ5wcTJOA/QR0raTsJr8SoBAPKfrGuW3iJJh6rjamte3IKQrkR8U8gLm hwZr6SQOI0JeJlKXe5GpmIdRW0KzImaKhdWFGO7Pd1GM2mNrVlrE5/dKP6vYmdlS6dJvfK3tXslh 5uHrbMyqPbKZyAssN3JEURBC75fpxmqDOeq84kS06OxsPCX69aiJp9BqM/iIOcl/+TjXW3oIHSa/ E+cvxHE2LD724/41VMTXgKijDG5vR+XsK0KYAs7P4ooHVRvmQpr0tqcMkugsXz8jnDZWWOEVonjy d78NF2EO0K45aMGZCMidWsgMfyWHEfKdg6VQe1Ji101yuYx1+rkpcJ7MYadF1Fz2nApT19dLgsXc 8+GSnqp+tEYZKSq0yr329PQqjuNUeJGhVE+S6yCaJtpQTvEDloSWCOiScCphlDsP+MwY+3WTFXhe hGgc35/iMiDQ1ss+hxwLAdB0YjPiy/qJvy/kAoXLdX0o/4Gytwq2sfo9k8Va0yAYAVHXREOCgbC6 DHeEv8te2FSl13lfEleVuD1TmWcz0Md2whWHpgIJisLnYgK4zu0d+kJRnH0+mA8e/gY8NT2c3Rpv Eoy8myDb6YelhxqC4u2ePXGXZqkOf5+xBJUVeFC0/NRBmH6V5F8VzJ1EF8ofWlZLSamJGeNTWyPG 0rXfAoAC2/mj9IermMKNK5w2AnpZvoSfDOlR+wXYxZknezoe0iy3xcDID63jAdNuxiKPky+O2OZ2 Uv06R6MiYKX0En2Xmzh8E8HSYhFTRz5Z+4ydmM6B1mRaC2+CAxiXW/bCX7vFq+sDE1DV3G9CLYoX GYY40xaTxhw6MX/aSxIRDCg8qvA4isbsAEq4rLSGx5gX13YbVkPCxmuORsoQCRF/mxgNcgrqnzC8 K6rjbwO+r1gbBQmQX94qNUPTSwl4PV2sZId4z0ypvCx5rlG3TD0Bv7pa89lZM5T513SdOV300so8 pINfFsTi3C6qP/dJYqD/nq6SplBkZWxLCOOSCzj+5V22ayqAAKWv0zQdB704m8lCC5WJdcylOM2K vfcugn3lfS5PWCdFrd5HUDX0qaY1SxH9GeFIuYbxDrbAa4fUnhRnmrUSVOMLOvmL76XTn7/fKQ90 rHxHl0rOf8oszu+PM/UvHK0xHEf9AEw+4mjWTTkLv05t1zkjkBFpz8K7tNc4JGGx8w9d0Fbnwk/7 MrKR0WRzncAQYJHhX/DZtkcUNm/kSkyPyetjFDvDPLoDCMfbypkg4gd35r6JrBqYo65C353/cE5q OUcGECvKbHuKszUuZBE9KF5491q2gy609QFfcQtMJRZi32G3BU2GfogkMniQcdhSfC7mEpXsQxOx uBZC+zn1J9XE4QVTcPB7U32TX+wW3z4GLqEckDXQFplUO7EEFOW5+7IHTurjpCYCtg0YMH51/BKE dJdemPmgYtuSkxagzkes38WFaI7mUiViurlp4S3coAt8/mAC8cadenL4YkJevVQ7PnbPEqYgovzz UIJHEDqmSZPFPCVR+GPvKUM9X8scZUEBOcHObLmZZky//ba/ZJPoC7mo4EikSbG9z7f8zxmxF2Ej EzayGFvPu6ZkfAxLZ7XwdoYvZbuPOyxIgJYvl+MYZZLXOWi/vMRjMHFOeP9pL/1mhgiN71ugx3r5 AsCYuqx2fNF90Isfx6ci01ljgmELSliz62TlbMnei38kysZjWVIthdxuNb977CSjf/DI6fT+Yz/P rSODkDtk4lb2iMBEAryqowMVCowc/K555yriKShedIFKKB3ikb1LAD7uX1c73e/lQ/6Wir790Enm kaDrw3vjRuEa5GRpG3GaRk3kdYZUs+zunO5sKHSUJXRp0/5iEvGlt8gNq+1XmWINzoQT33W5k5FA o+2PnEzOSMxlykNmM1I0ajV29nXCJPHkJYmHNvT+uNFMeaM//XxMoYEoVru2CyUBMbih8ea7eRyv pz8mYRjyPVYH3vfqXrYkhZfczjZPtRX0gs/CEoWWKkgcLuVTnzDFG8fmK8ZtF/1z05PbeKg1Oa4I vHcRnFqtlR/sroNLKKt/n/nT330AhTREBDXQnxxR4x1R8K+1tvySEZ45PlrDpp6kSUydeL4zq2b0 TitGBLbKnI7F7GTwPYpr4OI9hoKn42cGL4QYC+tC6s6296j0LK8QoGolcQEig/Vu6srRiI8+Zyej DyFVOomfP/DS54QLvQorKPnw+OHhKI7+gv0ktfgyQCNIHcN7mIbHmVTWkpAqJf+bJGPFdT1tVN5V QZzk/EMo1CAYAspBvzDfQUfHirTK2xyWlsTN2buyHHAXNDOoKaPSlpo10ErNztas8VnwfuuCJdLK T1fCpB0/Yx/iZNoTIrzqMnNks45No3ExQ8J+7HRWJY7h7kB79LmdK3vdVHRAmW0+31zhSvx02JE1 WG7QNI0YfMkxzUGE7n3LKVSGWk3PXMafsrs1jTaYDG6QGjcbjKoAmcoM9V6+uB1ik20Yau670zGJ 8lK/SWyvVjf1lovoQB05dTsQGGJVuGNl6l0BrTNu9joPEH0I+kwl6swi3+FrZux9AuIEjvTNtlIQ 8/sVSMDYEfU2oZ+Os1QOOnXMBV0QXq1vNNXB5C54EUN53ZtrLEEBQ+re3VnKEDI2AiHad/ZD9ZRN pJPPICTtv/DbOFJgkZ5fSBPddvkSHmMa0r5/8x4l9ZRDpOz87txSg5SPnu0ZZWgqLf7wqhirCWFE MWxVZuU6iBE7Vq8ggeuh0rH67IaAy1i+/H5Agp+tc2JchIZ+GutMy/kRn4A78ptYrJDBb/OhGf+X vId0nm127NlLlwjLLLcmqLuNSc3PTkyMH1GNxSBsMguyaidQBpB9AWIs4WwqxPfKkOBi81RBwIMV qP4yjFEmMWsBT2hfRvcg697m3BHvsz0GY7Pa5JyhWW3QiLdt2++D+mxUWl27xUPY+FYQxgcPHkn/ F0uVpeaVTUzuhdJAC0o5lNyatvicJN8XDsUEY9+4wiz8kIhKzINJY29aS2btKC58TX9CqcxiHZkC ulrm5ffNaRV6fqkM5rww4uOZxz+iUUvWjgVYvxqFXbX1yt0RrEW+tw6UtA88X9uJxMPmhcVOaIGM 7Aolbd/pAvNMkUZof33M6J7X7oFsutmvvbl9/duesv3b3mvDnhYGoGEqMohLeNWDzdA85DAxxolA Y2yphY2k9i6zNRZLLHWOL5lLjRNoMHqmNYlBKreSwIBcfnmwzsyxQ3Zui0Hm3LsnX76on9xQsi6M O4UugT/o8lAm6HKHTW0d1qekRGj8szzgyAcPZcUswsc+IxbAayHkXsfHzLSZGLQ7/A4KeGDPGcRU o76SooymYADnbuNgjIeIUHjWq/upxanF7NHrjR2lA/zW6Z97rLu7STJ2gM5WFI4gabU2r1ahIv62 CH7tz/HKx20L8/i0Y+zrOvK9ccsMfWtl60SQBamKK8dJ3cmif2pqmXcX7+jzdH2lKhLMsylcQ4qQ REe+d2BZ8RiZvo/KMF/buon2maIWwHYeOnxJaHpo/vzZF3lhhN5Tc5dt7ynrbobSH+tGnixPD2KH pJsCXlCCtdVeLK/Fu7lQc+GzkpC3yXrDLOLPZiL15HesUKjQpVhKPfNXzMQT6oKkC+pchpKZNWnO 2u2Pat/1YM5ItW9tZ/OcZH6JimrEyH1EMqFdkexTMWun0xYkokqfTYv5fD4Ke/lzgQCdoRdQEe8t KPZ740cwk0rt9PJIGRrR89ljt/XWgA30KykhE5K8a7G0EkI6MsPg/ggf56KWBsbWM/KK8iiMUykc gs36iaixq0JkbkTytDw/iYiEKt3m1/iyExRk/biTGgpYZ6WokWLMx3ZzrLcNRJ9LFDg+MpJSclRj oumKGjKQfArFIdnCFJTe41HCfT/bjxmK7eFe5vfauhwgxbM3+MXfhK+OxcKiIaqctbeQ7Mu3pTH5 pmAx9JG8TUgUbfB+9xrKhCfhe2JLnuqADhwnMc4LpjrHY6p3CjnGrQ2ZJLvOfJ7pb/mXDpjsx9+i cRwVYny3uf3wgs3gJ32P1PnDZh2lOUXhXBh2ulHjb16MA8aGB1R9BjlO7C3S3YE6U2YJLuB3XyVo cO1NospyAnJXxRzx8o0nftywyhtBz7t6T+TEjbcgt+2oZXz9sn4g4HtjIGtil8642FDd9YCUaxXb pYlvnTBMNRLFWtE3p76xyNNHAT1vV7zHg41/ML4hFGuL96pm/EWYj43d6qeS92UOTLiWh03i2upe qfIo54PbeAaGdziMwRLzYHVvJL+6rot3YDF69SpysdzmVrGPxtRAdmfy4WtjGgr9AX2bxtvhkYxg 5YngIwRB3hZxUnZ1LkGenYCvRQgm/vTsuyn3Dp1B6ae5nbarXDKIIi3DFK/JtvgfsvbNl5gGQM9O cwUu+Z4OcE41FqO9q6OopTfnCScjVcvJE6V1wgMUVtyKpwa/GEPqB5+Xfeeoyz/fObumpgdPqI46 lstfl0UXSv1UdDGPIgxjTN06rkLobUmw0hzI0294D3zkakrbTFkAG5KwF19blRu93B994ASPsrhG VUbx/MBDCixI7a9Rczz1jjA5syQ1Snc+LCARj9GzIkOO503d5i9997aFLxRTRNGc9UowHsegnPiM Us+snrFVW+r61oPNmX6ycV13KS1btQHKtpShsy6f83JBptQwdgacsFMtSmyO5S/q9LuCb2emijiu LLP5ajHTCKuz+64gKE4ITa3slVqTZ+bPmE47bTK3J8at4SAXYFduAzKtdbhfl5chQELmaxvWIdCG 9WW2fxpVVH719XmsbJ53SU7zEb6UzjZCW8z+VAYY/zmw7FVp8WnUJrSzNVI5frOUJwanVK7a9hEB xlwisNfkOYxLdAJSveQRE3DymHUlS2KfG8Gv57+529KQuHpKAVMaGmXWHpX+shes9sRB79zsckhZ uVNxrFonBDelmsrcdxMd0LQNzAZyeWA7z2W8NCxKeMvJG2vNQ5dAEmLpEdmzaoR6fUCPcKMuJCNk qppXP4Qn+CsxuJjGVdo4/QIM80q0lMCZ/zTk8JGZbiOsM0bD5h0xBN1RXjD5xcIAwizQsV3yRqgg Cs3yXa8VgcHsd1H+XytV0WWWBrgkfZ0CVfknYMtkQ5kH4/gfVhvlG7BSy4h39vrleppslDwdeWr+ TR0k55Oa4seeNo3fpAjZcD8ZpYUaTFqTGI7wL8UwT/ZlxbUZk6RLVLqWHdx7me3IBOjyAc7sDFD6 3dS0b5uFgWMq+ICQDDQhy3ey6ECDeI8fiIqk1zLolm2CcXlHciepz2m2qqQxaGzsbl1VwwJaZcj5 KUSb85HPYFpSWhveMnjT+aIpCZ3BEu2LE034SwA3e1Ngtf2aS4Yq1JO2syE3WuqLDPjL8sKZYAXO rvOm1NsNOepF6SERTUoQl3I94oVRXkoj0Xz4ZTGjk4bAIIqYXhIhma/IgAofDZQh75LzJdpVj04p eWYHS6QxOBWgFUIjrSsIqOeaE1INTuNt8cVSE35bmBiFawDCmmcHNlnGfKo2WrGXEt++O8xysAe+ gsZxbHVIyyW4z1JQ11tvpbZ/w680ii0NRmcZ/KTlRAhephi/tS1q6kYXPqivLPLgpFAqiLDHHSJ+ URT9fYInpoWBIp3GSjLtrZvyKKAKl5sJlY2P0SLtpLS7oheh5r1AneO98ApPV6sK7oXERDZERLPH UiBzLjyktq0fO3if5+qCzDMkkDo62QGDYVcgNoUfsRQTJYGQD0QXYiU2EMYNcbZDLNFbafcX6m4r NHEtnRD0h/XxA5MrkhmCEIswB7pn0/ncKelYGOO6XtjVM8aGFhel36wXaJAdydJLWLrM0gM1egwt NLU5C3Skg33U6o0UoYKCak2cJGDSEqLC0SngTkRu+g/Jxfc1pjZCjdaduBF8n246VCXC2uY+Aais fXbQUHL3CnBmPruU+dqNomjzg5Fjji/yvA95U3W3qS0VoxE76uS36OYE3Bj1viLNXuYXDpgiYBix GTdkGpwJN1AjzG5Y3KSMouNoI2cYUNsMJNehKFyplwPdvojSFZNF+wo0hCuQKKsNFbqwp0tRANtn RewlQiYcCRUSc41smPuULaKAio1CmcN7wV2DLti9sM/P7RWLxq3S/cnevj9nB79Eka12GWauCBpB rfSe7B5TQBEMg0WYzOwILZgiEIlrvF3mhOjHTgzZOi47vEs1qDMjHSJf0siZYXrov22hUCQp2Rm9 DIlaBjrNZ1MpAj44g8qpQqawjmd6p8FrbX6NqnzNCwqk35ITlC4xXapo1YiwX0YVhCsBTBuDquXV L7X0rHir7+No5KgbvS/V7w2tXMmeN7QO0PEgnWnHTKC33PLjXXsfrUeh5hF2Z6m8UCOUKzM6jyq0 nOsXCtWUkNLKlukBTj8Gal+cvHw4MU2wVZx+uz9FcN3Ieh48bOtt4caZkbXhRMhPoNlW87JXzimH mwey7fcTjfjTIsOOYqHLh/se0jTenPQLxn5Ll1M2z2vrQ0v7wVDCY6O4Fb2OaYW7W3PDoMWkpPUQ F+mVjmOtCFyleanyft8Jw82pLLSsofj1n96DNeQqSPvTAci3Cbx5nm4KL3E0KEBogNebhYxR0u2T URQ4hvLNdCwedZd6xoXQmkO1jZKwOfTZSMUqdUTGMG++iIGyZ/Q/C/Af1LMjTHT9jWK0Iu4Vbug6 tZSm6qvNsQpkUElJRgBJk521OPTNSshVM7x3kA/XfX5HMsp3Lb1t6aVG7O/IkMPfJr4rMQ86gUBi oanJb6P6og1xqHnlVAI7n5eT4avaAZG2W3Dqjyy3Hh1wyar56auycxaUZmVjX78vP9cqNNBO7BQM iR7UVOQXoySJ+q5ho/1wKd2GoYK0YNrKzK1rnuDdSUr6Ks82gPXVyvGAaQQVRp6oMazSKnKxa8dD D3+9lg2V/dm0ynL53K5ySq8RAb475sjxuI3n0sK7NOs31LFma1FY3O3BM4oGvdYTjeuH/Vv0WPHm WJV4d6jetxa3RTbSehCSrt+x4ATZjGXRazPMp/1mJZ10U9rq85IDnrMeBIEmQm9iAodwmw3hjwVF zHMOAzkHSW2QmCGqiCtihpZDFNBnLiKMIOzUS9KU1+Z9Tpmr76nCNZFoeq0wxvuef8qg4uEgBTee pWDNfMmcSX5iO3fW5PsSOFjTHacKWWWydVVi+Jr2vpZLv3L9bPaC6Rl2BL9//9UB0eDpj7O66FQN xo+zs+P1zpP+r7o72KhlgH2OOT7U9TXr1u3hZiPM/D8wexOlWJ59ucesVs7oO6+1n2ic0j9O5BmW 7A6GGuQNWEe+TJvqWiJwuwXgxpfXVaHTgPNGQqmSnHoMSY9ZCBO9usc5SPpiEMbpZsjY+siJkz8F nBpKbfcOUy/JMfwmUdu/GWV3eWSpfoui6sNMNkaMkn9AaZAtY9y+2kE5FVp30BS+R+hdV25E2FcE DnQpoHD/doN0pcSORkWDXnH5a27ro0g8uT7MQxObGnfdeX/AAElxWUF1HX0UK3Pc3gd03/fR4jkt qfgztOrqovQ8A3L6RPLYIsrfLRhviJvnOO+PZWE/AkoGB669ExYM1K1wq6kDlNaY+dnAVqqIU4CG VfGhJQXKpC1d0T3ExTzcsN23AqPOpEKD1n7iIjHkaLmb+h+NFDxuPS/6BIg3MlblrOOySBUzqh07 rhO/WHyWxmWrpbSj2fPBFd8mUBaxIqD9NEnHq5xgCEiCtb7+joPfil3lGcx/O16vO1QX+doqiAdN 3VNsnSW4YXZfW6XkjbmYOh0W0CmocvbXxHnHbP5lDY+pkK8lL8aZY5nmdviK5NHT7k4ca8yK8ba1 1GvHAb1HntUY1mOfSEOA1+lcwaXUW97khvC9RMqTPRMct+AMe6OfSJGEmnmpS8Welf1mmauUvso/ d7i/YWeErWQxT5SkxMUQgyjs3NCoxtIDaxaTSlRUiaKMkQ+xs3/Il8GEQj/WvZY7UrUBCVTsI3ve Sysa1WdVGBix7AtXPDxHjzGJ6T/JyFuC6mrpUg8Mx4bJnBcRsn6SR7Zubdcz1nP06Uz9no1a5zLj Fko2UI+NmlGUjhlC5rha9dE76ob3sIT1x/jcqub8D8MHoefeSx58G6qcVjVWaZSewd30eSfkzwiM PRTw+UnCipcEeXckObkkJGLCO0Z2WFrmy+bo4yoJR8o3kIwFxiQu833w0bCRTFJ/TwHLeb9ZUUKY vnwAR9tPAw6RUeu56Bpm/a3dhIh9hNHCuGf7FzI/ztJ5oikoerFV0zwQDz3N5aObYRVNYo3e99m4 j3TkcI1hjLm8GlCKSHIRELRFj1uo11vD7K3ciY/acF9lmMOoNvGdxE7EE5E/QELxfou5IKZxuBgW ktfAn/ICSYJ09nEFZSe2N7FJEuv3ZmUJQmHcSuyHFxUPBgZkyzbmL4PFxoxmiKdqg+W1ZjiK9sMp phg2mJEYyHVJgRgky2VRS+REGk/L39JpTL0y8QdpLPIdfX60eeELr7BldW0i7N9IvVGbr8Mrugov NBZ9GGhnIDlAw3yVGVIzd7SgA6XHr2NkeRGb6S+/YqmEhy9V77N6vcD1aNC8cRv9IlUH/2dsdrJm dVgmzuonVkNKBMmkBW4RYMn8QBcWABvRM99P6Ia2MY/3uaIzoufWXkDimLJBi0Um3euX1x8wD/2s 6syQq0qktEGcUTdD87d0Hdw+sn4fngJTmh21aGxhj4OdE5+8s9yxuFb9orVtK2dHIMUvDlyp2IuD Jyu7+hWTNyrmKDs4iEkdumckEgRavDLvidmNYxB65yt/e+fXzkJuD+oTouwHqL/yVoLQFH0+MVTr 9GtOH2lyikcetYTsGy//7A3x9VVqTUzZ3o6wi/o9pUDxDr20dIZrg+j256qNwzOR7RrF2Lpiu/CC 18ZpRVGK1BDRUD5J6ckpld699LXJ18EkbczLyBerykToZ21xkPh+WU9QRL7K6YciNmpR88gZfxbS pUWsMeVb1Qr6TW+Lj/bYbKa7wUw2eQzQbtMISqGzedPhJFW23MQDCL380quSVOYzFP9WMx95nF1r r+B9B1w9ZSkbo6mBxwL6p7mgO3se2qZvIQXyM2G/1KW7EEO6jY5K7pZYs4kcAiUcRlRWbEK4nyV9 tLyMbFJ4GP5tdEANTYsV3a3tkIhhJPCFZQIHOyeXjC3nMO81MfAreXQdS/kD45HKBHlh9LLqs5aJ MobIwjm5uxjP7h6bmpRX7D/tpJgv5AsYpn+2p57/IfUU9x1vd0HMRygy4btsd4TR8iJ3FGQC0kc9 NwxlnGmmSFczShtduh/D2o2G4L0lW8lTcmO09zHbewaUF3L98vB1G4VrkbnaFUGAFK2Tkc3mkKDc 0SIlNSv+uvaU+OdbXkxhIDFBgCAfuuHvhHVq0a1IYLQI1RcFcFInwo/gxNZlmsldWncHpfgng1TB d2EhOBOJH7zpWvw2nbCcavaYNLhGbAaiPhOOuxja1Awsyrz51Y3YwoiLUJ/H2Wu5K3rlnaToRHmX lg4Lxak2rCHO9ihx6jL+SBrnyI03OhuTvNCAWfOrOFSYnby7lOn8nb1XTIxhoIKZN79nIgBTLbH3 09JTX41whXZH1PGC/fpZ2wQjVxHQHdBu9QAlH+mWa1Gj+eKpzRLKcPBMW7r9/sIxL7hXH4+p6W5J 3YKlfgF9BJn+UMfy3fC8lpGkHXU1Vt0eKrWWtsu21knsWAtPl3hH6wSwrjU92vfuwyDJVglDDP8W od/eK4zCjiNmjqv8jQA54nH83LCIc8vTB6/NH1jFXNtvMeqngqkaxFoEpIW50x+1cPp4FfQbQ6p/ AFK7rZCLszmXryiMwvuqxBlivmVujQxZ9+FCg5cHq/ZLTmcd6A+jUMG2fVJvKI0nDn2xw+jXdjxv TQtV54mr8fCyPjwuGwadEhotpWQ0XPu8edMt+JJ4xUmeOFdK6VKQWardgzLxFWR8ehdnGev8hwGM h+9awSUtfL3oXJ+DEOAedR4Jzh/4BE6NUuZCT5BqUn06l9Vv+tyXyexC2JwtqynM7eaOUOvTTNf7 qK/UmosRKLNxHk2qySV36qroBmi/B/aIkTDI9rQfyhl70GIam+DolQ/1A6kjv6ReemDO9W8RTrlF AEp0wxCSzy9YW0hqRdILW+++Ngo/mtppzhHbYQ52aK4fy0I5l5MDVisdZzvqk6RA4RLiPebjQqfY z+YUMyubfJehLME062nOshJ+TF9f3hRlT7KWtSjgRWnSOKB/BWZaLzMyuL23CMypxmt+NjaZkqJ0 wfj2xwzdXmyi90p9ODfd4Zpu3pLxVKgUg+/ZGzXH6ZCMs8rhttliSJZin9DrbUUHaeTVdhd+JO8p vRshRbFrzlD0TrZ5dlzFyEszQGzFa6ruRzYU+oE7jckpWkKB4O+vDobq73bVHbkM5XTS+dZPRoaw A26bg2M6qIf328WX/GFCObMyaI6p38Ld04ez9Kfy49ufHkewiic5X2bWbY6joCW2uuu0fFjjYGX4 qvamNktFj0kmFUHsgjeoiyDdBae8HXaa9nnHOJU6q7fBT4L0lWCnYI5ZUgbnjIJ9QLjzrCSJmWUW 0jY9rnrien7j6GPz2N06nqtl7cAOlg/URc6qNjUKQrVnDrg2feL8//nD/L8F/o8oAASDLKAwiKMF 1AET838BYQr/4AplbmRzdHJlYW0KZW5kb2JqCjI2IDAgb2JqCjw8Ci9UeXBlL0ZvbnREZXNjcmlw dG9yCi9DYXBIZWlnaHQgODUwCi9Bc2NlbnQgODUwCi9EZXNjZW50IC0yMDAKL0ZvbnRCQm94Wy0z MiAtMjUwIDEwNDggNzUwXQovRm9udE5hbWUvUkdCQ1ZOK0NNTUkxMAovSXRhbGljQW5nbGUgLTE0 LjA0Ci9TdGVtViA3MgovRm9udEZpbGUgMjUgMCBSCi9GbGFncyA2OAo+PgplbmRvYmoKMjUgMCBv YmoKPDwKL0ZpbHRlclsvRmxhdGVEZWNvZGVdCi9MZW5ndGgxIDEzMDEKL0xlbmd0aDIgODQyNQov TGVuZ3RoMyA1MzMKL0xlbmd0aCA5MjU5Cj4+CnN0cmVhbQp42u2WVVSca7Pn0eDu3rgFGtfg7u4u jTuNu4bgBA3u1kBwd4IEAgR3hwSCu5PD3t85J3u+Mzez5m7WdN+8v3pK/k9Vvb2allJVg0XM0tkc JO3sBGZhZ2UXAEgoKcmxswFen9nYkGlpJdxAZmBbZydJMzBIAMDOz88DkPdwAHBwAth4Bbg5Bbh5 kZFpARLOLj5uttY2YACDBONfXrwAMUeQm62FmRNAyQxsA3J8TWJh5gDQcLawBYF9WAEAMQcHgPpf Ie4AdZA7yM0TZMmKjMzODrC0tQADzEHWtk7IwL9kyTlZOQN4/2W29HD5ryNPkJv7qy4Aw99KGQGv Oi2dnRx8AJYgK2SgsvNrPdCrmv9jYf8bXf+eXNrDwUHZzPGv9H8363+cmznaOvj8p4ezo4sHGOQG UHK2BLk5/burDuhf4pRAlrYejv9+Kgc2c7C1EHOydgABWNi5WNm4/mW3dZe29QZZqtqCLWwAVmYO 7qC/7SAny39X8tq/v3UA1WXEJbSVmf9zuv86VTWzdQJr+riAAGx/3P9m9j/82iU3W2+AARsrGxv7 q+Pr97+ejP6tmpSThbOlrZM1gIObB2Dm5mbmg/y6SK/EDfBjB9g6WYK8ASDvV8lAVidn8GsI4LU1 AQArZzfkvwbLzsMPAKra2P5l/ZeBlwsANHNwsTH7h4kbADQHgf9p4QMAQS7utg7OTux/rHzsAODr eP/hyMkJADo7gqz/WLhfI11el8HZ8o/pVYKFs6PjHyee14Jif4gHABT/Q7wAoMR/Ey8bACj9hzgA QNk/9JpF4Q+9xin9N/G9xqn+odc49T/0KlrjD71W1/5vet1l4B+d/K+XMf9Df93jTzfYXktY/gNf mwP6B76WtPoHvta0/ge+DsHmH/h6k3+MiO21kOMffN0toNM/8NXZ/R/4qh/8Bzlenb3/ga+qfP6B r6p8/8b/udPi4s7efiycHAAWDm62vyTyvXaYLeB/ddRysnX1AMlJArjZ+Hg5+bj/tlp4uLmBnMB/ /5q8vi//xVa2r68YCOQNskAO5vIJhfCLL7Ft2pahocmyk7kZh6GRej4WsGLLOmVkZ4D7m+jPPupQ ebvQX0m6zIbTveVB3Vjb4NHRENDpwL9lk+3peGoRAMGFQ2uKPY/wVi/JjzxOw7AKj5zjzTZ2+AXh 8SVQfTPLOP1p05U30SDptFu+Sj8/jkcTwad8fZ0c8ntZ4mIaNaE2utC3HtrAS6kOrep5nPMHBkGs NJ4Grl0jfdfCMraGQr53tZA3HG4yWvHdXHT3s9QKVhbmoWjOYvrHd04umj7S8grsKLpcsQri/PxR L1cfDe/DxQU+g14qzn5IM6YKTqq2ES3ZLGVNRdyxY9d7ZH/B8lTOWrcO0hk80R/UkowzCSkw11uf 2iK5wsrR2IcglMNsJKIJsBh+I7XxnM42zv3d8ln4jguqNgkV4b1ArPaDH3ldu7ipRC3qV6PuVScc h47OhhsPpDSVPAbynpAXA+gQql83DvJh4e/3WQmdoEyT4RhkK2BPG6Qzmxvh0q0rV1IH4BA35uKi Ma/GqPDjjpYuTzAxEBozixU/4mRZZQ9gtwOIaDQPqT26zcNr6UA5aQppNaGzKawewfRPF+9oj6Gx 9C/8f16gvzCFMjeHQ6kAaATkvh5wQj9RtiLi9XIObLfrnmosU+rM0TSkXjT4dhYIDhVesYbKt+y6 viGwR3Ost35sSa0C0+qyXOysakVy2VQAEMS7/LTeyt5N6nZScgnOtOn3FIheivAOXd7GoEWraR76 U5gf6YVanwuHEwtbEtBZJOuPNIMWQaIz+GtHO4y9iHDZxuD6AD2Yt1p48FkDrckudZ12+NlRMQ20 my3iofNnGiVoxTDKU7uc9MQckFiCWVILZrHJPOFxky2a5duasoloCzg/Gl2qZDS1gNv2ygfb6amg gOSJLpn1Vk34BcA6SuNqjTtxPH1Xh5P9Thx+TMDnO7yqJ44JHndwT95SLPJeO8m3lfAlBUMCgc6P t1PxRKUJloU0xMj4/JhxX+yj4X5NeZq3dPwWEspMnUv2zNARfBiSc1+Ni4nLsxlkQcVhJzoqfvgJ 9NCY9hwhgOLgqgjjXejl7T3v3C+H08ESHE9XM4RiAdzxPCDacXi5ebsfMVtWMB/XYiXLYXE12zIh rssDiEWwVjZdFtJvzTNn30+3rtxlvmFPdUiOlJceYvWti8K/lfPsHUFIpBoLiiwnO9IPgLl9tlPZ kLQrpoIXvgiAX4+IXtbBIfQakQ3NKA42bJxcXSp9sBe3W/ctqxkLKNfAOX+Di8K7iClYv9kmb9qo lUDZ0mAtI58/JZKrwU9IJSYOyf8wd1NC/eUkvH3phNdySmL66y2XehHcreFCDGlVx8YTslXk2Rjt 6Nn618gkvdgcOm1dMlQRy4JPRf3AESHmYdWExuzyOytHI4lf5UnhnOhvs8W/r6d25H2byG+glDvB l6TrSVqv4k7k3N99VJSE9ew4QN8LMiyOfnsQAaaQNp+t/1qT8ZbfJyTRUakBagM2WrbIUoKMwde4 yrnI28VORftX1u7DNsT6G9it5UO3BUcaj3hmu6t6FkxwgjNfEvzCg9e0PWFTr0aXgAqueeN+lDUC JLc2t0rmSfu45/z+CEOzLi8Hk6oVLrw/qjzvXFB31JadmmupSvPOJ3LDzYCRRdCJl7X1IFfn9NrE Dmh3Rh07y4MWlt1xsIWCUQCLL4y1IkjM/vxtjRWX5A1Ljd/ESL2zJaxWOAsLlMzKZSYe++FXrZti CALXIX0aQRh1inRsGuLn/FxxSAZM/KKC+RRpCfRvXovV+5lAEfFhOtUsmubf8/66uQE/LpHYHNC+ 984hGBCuFidzp60FTs5rXs62E7OxT/PP+XYeTDORrj0zBOmSxuEIfnu5FPKAlqqbgaaeaPnG0zTd A04Qv7UMqSeLIoSmral0FTBBZdGa2+m2urCKWDWclWE8x/jSZk4dUKgNB8f1iUHmpqSMnQYmjxXO FZWfEyaLvVV4pcAR9B5HCmECtu40ALIW4SfFJyLpuB012nJnuW7jcxx0ApZe+20faoQdsyO7gbvM d0qiZjkgJYnwsmoTfr0XbYIljOjtHjfREmf2FgQCxgyPQyprB94ceiXDuhjmZO3i/uz8GDe2Hqj0 wzWR8cDPlgw+S6o5Uafa1pzZ4cmpQm8SdkjCp9G/j/vg6+6boQQVyq44Uapic9hq7akQLyDzpMO4 J+YpWnZ69zE71+hDN/OXxoM6bBY8J6xSEm2uDrtgMXAUtUMUVR+QGRGRMclDeOAzDm3nSeHYLTaB 70Tj5O5ckCbcanp+MvcV5lyFwMynD4mpYYiINANtTLg0mjgOH3KEwEv31JVkH/vr3o0wGAT5fVce GJr2EMi+fJByCI7NWvOU/56URu26fj5gEunhqiLpOd7bz9FOxYfLX3z/eyNMh1ZUcb0pc2i5dFbA 4VT5rqinyyULJmZlYKChIgQnrYQlPSBgOwtpurMPc7yPdWNdgSeQsBLJvjVUarF1s03lxIgzLoek +olrgqkpwFx4JjuJiXoL8wjVp4pmo5m33teIXP+FovKdCHUXwA+TBBmLkt6orc7iPjsiKaSLVO/K HzwBJXU2dnlfsSnMs7b8AaaFnHJxiRDKBsnq+ely5KY0WJe3Dq6jAzNwjFey1oHOk+qCmqAdKF6Q 8On56KyxBxGov4L0vu4yfXzwac4bsEUilpYsILf5q246br7PvPUn+Clvl1G+ZXDelzqgvIGM31IU E69Ibe9bnM/V2XOWS58i/IlbotOOWMXGT0HfQ64LI7N78Rlnc1aoC/huBosVQUzltQuA//fxvCXP 6/FP8MMQs0f3Ot57ajMWSBdSmWeOQYsXCt1nU1eR/b4eMwwpkSscC3+hQYRpI4PEJEBrUitdxyDq YPzIS/helS8Za93dERQxsdWLPpdxPs9gNMO4X4rR5LaGWA2u7E+hdqyG9lmFz7lD+oZxkoOm2KEN RNfH4/L0vxhGusaK2oWFe6WMnnoyw9iSuYHcS+VoIxXD/V98EMSZZnpghHq6oozynHrd0WUGRgWC 56/2UJ+7z+bUH3oigovfPj3R0bWUtWALAjt97i1o2+CwBeJuvjNSxvn/Qk0JGwPIR5VbRKc6jsGH qyShK+NoDVZ1YH+FuQetdhcV6h9a+HnBqcnQlbbS4tXgFabRuYRrI6BpSQp1m2+3aEqGtSU/nzrt 9/Yf1fKmhWcU2USBAluQx3oVGFalOeFE6iXXuekATF7SFTOTHJsC3cjlQjGfRY+mja0wNl/u0rkI pJOHBzN0dfygacfs6DIe17RFcu7lbHdikde/FEp5LmU/MkiQFsVJAiMmYVGE8z4M+RhaDUSRwfhY hn4pN3FRfOTqZaNUeaMA/6UVbi8cXbH8hJaSYL5UPWNcgu0tH4wSxcgRUdjH8Sw1PQAbRZWZi2Rc ftf6zPG2coPxaubiqL1oq9haUMv5xzCp6mQLciV+YN3eYf/R+yHNn/Nvye0wRR6Hxbh/DE0YW3he hgRrbJ4PEqM8pH46bpy/Eh5jODMLhgc0Qg77dVHYLgp/TF9Ju+xct3cXDmTPWOVdu8Zpyn/rOn6D UpuW8DGmJgAocJP5uUHovmky9BdiMkZgEPTgIAg68nSWxaa31rSTLITtpbQWO3qKe+FZj6RrYVyq en5KtjB02GoL9Uz4wfWQ9pK6nFEelQtK8NNQs7+slFxD8JgcrhIytWuZ8wmN98rBEdnXzScuj5ZK p2UBykASjSVRea4woWjVvTYobxYf6hO0L0YU77n2TEXFlpL249zJbGaGCOdjay2pgQirBYxqR2lW rq6dHNbRVMfKxokqjD+xs7AaeTssyGblIse0eb5tqeiEf/J5wQDShcq1UnnvQENnnbtSNJKSAOyN 8+GUTXVmYaLSHAnXgKvKDrgJt5n67NRO+bsPuuq0u76Z3ohuLc9dntnyxImPcXzIsmxVSEQExFDR vX4tTDm1Pw2h9bAtDnWNO1y4wFIBb0VjmQRo5bzeUEdjjbs4fnmfsCC6DPpQWIDrDh0/0tpHkfGU 1Dj1Od1zLZ6zdyte1SMNN9cftxPbYCW2++KFUvdHNl3pD5tYisR9FSCka538a9kGxDH7e66JH7i+ WJTaSmr6ZytWrgsRKxDrKveT7fI04LRxjySvtlTlRWD5rNxbZm8TVprz+fp0YnAw1f3z5j0vT3bP BZYUynbHvq32MOpVW7AuOKhEBjVXtU+82sGE8SpIxZaU3Uh2XdUwihzFCUmbSOUkuSYQ76Oyw44b O4QeHbE4l0pFDVrcakEWUm8zCCEnFZa5+rKPOlEh0lSxDJJTFXKZtp+avlfvUNOMOZbcZUnKR2e4 hcrAiXpMMF0s79wUXFe9kJWHmQt6IY8PEuTl2ERiDgpwRDQpGYqJaI0R2JVIlvE2hz16bj1C+lWb t/8ItesXV4Z8uWYTIiCrEsnqZKZATA0Nfd5AtsGbR0okkK/IhF5wFA1BNN+it0xLGJ41pj7Voa7E 4WUfBijjMLnvxoakFc71frILg8kkqfiYbi34VTYU4ULwFI9Zo+/xIK6t1FQ5Ykk5TMFhVorZflJN OJmmBXmx8gLoO2y/yN516m6r7CJetOzPFSbXqx0LLZ6gMKJBQzYUiSOP4rrclfk+Bc5q921fdXCf YeFjBE/wt80z1DPFkoARlXlDqEW5CSwx4c023gestjnf+SSYxF+qwek7DHJrgvfnzuLUPdSFrkre aN4jRAVn29qXp0EU+AzMDSIv8gufd268b6DDgGYtQzYudVumQES1oYm+ol7eOlPu5pWwAHZ44qb+ QusCVlNNzxb4ZvSWjQSdAmuM+V/IqXULz0UvXMguwtsNdk+yjiZk4p8T1OJX/SH383swVIecmsOn ZX6qXrdkLqrGjuzUIpH4KoPyT20VUAk7VJgjqFO991XD8Nd4hwtQVN/uP5fIlzHwmY55QYAs1tYM 2Fz5cT61180UNYUc1qzRB9f6F81IE6SiodAhHJOTP95Mnv9QzAaM8rAON+ZSsTsk9phVRaTWurq7 yKIinZbWAfniYsakfpPTpAqMFnBAmdjbSRITVcYKm2qsT3YhK7zUf6h3RHAj6XuqpzjSqmO8LGNV 5/DYMrM/xAs6LXFo7GVSYPgZl/Io1YG0a+DRh8epv90ew1xNeKINzck8lvG47Hh9NZz+/gbtO80N kcjLhahEgo6gofB6sBaU7O3bFnXVHIKWbakC8y9NvUlOIyIVIeODQhe75PHoJuutscWQlsqh91Ct 72e7b9NuatwUgA+52f1MSU3Gz3lFlupxELgLz7CJb46jxQv71LcWLB8VrstTR5ials756LBKFr+w Jt+bKGM/ecDJGwF56W0G3xxjOT2Ol6jEOS+qmr1LfJONPz3Jqi2c8hsxC/dppXpLT3F0OlJz/eH9 9F4YYhUw/NOEVfiHJ1dTrdLED6k7JcLKAUYDlKf41t5fzweMx38XYGCL5XXsKWnj2OAOj2HOhjf+ CAvC9NHcWCIocWspRVGa90e3iruGpB3ljjC0v3sjKn2+ekd2T/+cN+NRh5rlIQU7h08mfdaUOOx9 UOVoUJJy/0ELp7ZhaEwOrNLjBSbXzsFh9nwX+RBg0s12MgGagnmzDjdMA3XZ00AV1ZnW/bzNx/Ut ILaI3ML1aTGuP2aUTicB5P3DoRlPfkvd2taPrSZ0/S5jJetI0typ5denEfRnNqNLterjcvPv44+Y xLqjzU/ZAMFwX+IsPsLU0sKEHaQCEVoJu4Mu6qQ8TVxlISfKhglX2Niu3KpGn9uHH9EnbbUiZHJr NjzSoLoYe6spns763lER6bSX99WbfA3LvKsvmY0B49U9ntnQNyaQnmGU0iVwb63INS+TXY9kw+/C ffF9gJrU0Bv853FPDTy2KlmfKeUfS95le0/GyzRa47MM74AQ6iwkQ0xpYSyMtGtgD8eUm3oKzzfK tKciKlyRGjh2vcZL5lPksbOLK1ZZpQ8Kv9maspjr+oSJXGpkURlSsNylCLn4CK/699lXaMFMsFTf H2ueF9Bg4Eqcb0i524K1P4l6OpCLsTF4M4Vh7Tq5Qa/lYKrKw3JkiCasDJA3xDTMhZTzs6/B+mtR 3VOTChksKJJOn4Hwqjbrknyn8I1Bd1drqJhSPuPPjerFon7bnUhs8T3wfaZqSrZhFdApI5UYCoaI B3XI4R91qe3N7/rrb+fPZvgAIj9Emkza8LUvDuKtQvPfob17rDbuJqOW9ij5nKkNiyQjEK+HDmf+ 20Ry83WGuYufS5d3LYoXP7uyj/pUTHnGleHjIUPCA0spY9OLIoMtr6J+stO10wozxyERbPx4VEZL 4PnNgzAeGp5wBUloWYQU+vHiecYAFi9bC4R1yYYTtCn0SI0uEL+vTrJot11/V9cZp4ucdbSzM2Es K+wieKwBDNG4jXkVbP3aT0/qR1l2cAlcUkqUCisxy/tCB/F2GQ7bKV/BRQt87tUH/c5H+eLoItbn AOndcI4f/RDpkuL10pE3iBDqL7UM0KvsX8iZS5RVtnJXec/vq63c7ff5PUmiN+tSh1JXBkzJ6HsW iOP0o/KMz4bLx3ibXhQrpO1m3uqSKh4xInLYWz2wruCm+KZx4i+ZI8OlrgJCd114xMhSLZEMM06z Hplx1W3SPMUa0jtyWYipiwLORu9UAyUT38tKOdPINbPIM5OgHm4zU5Cc+12CRzzz6W+ypmp1cCez JReVb4cIjjc4wElK4OC0n0SwIB2u1Ff4xWWoJJ84KoYvx2Brczk0RQH0Ce6hz3JP4VFcFJla0gxR W1hzAdv89ycYFPUQGGRhwkvFxrJ+DiWHQt5EyZ0qXnb86jvmhPXTj3D2mninSGFf0TqhBmTg1D5V OZJqVXqR3Lzn/nXG/JbFc9F/iui4+rYwlstfWp0s/8YsZflhYsrE0DFzuDXy0+Osxu6EUO5T0E+d EMPn1UWBVP2SVP+kpdECn91I8ce9lMzKpsoylg/TNPorZtcYJRvpKgHTLEu2tdzEdqIy3FSD3Y8c X/GNPTSwyNCOu/jZdBj1BjN9RgzO8IkfsTcerEsy1yAcuYdGsWX+TgxYl64d9PLrdllwRMDuEzdL 7LLgjZgbYqsTlOoZE4qmMN6Ii17/TtXgPNfbZl8y6B5zbk4Hc5Q5OtfmYcF3xeW0u0Vj0unv2ncS pd/gEJTp79Gkzi23E2XBA+76yirITLCKpXpgH8PZ4QSzFPhaUy+XTTNXHTV4gSKjQ1jHuLmh2rX1 EvNPA3zHHbuR7Hcy3bEIIZm5Xnio+tygX2pkeYZbUioSlEMT9SvBufSEdVvWC5ffmZ3cZkiFHBfN eoTQfclWw6Qn2LJ07BAqxkvJr0TZIpWA6B9KeUJanVQM9pe2bFt37ke1gj++oGTVhW9wcvllAiQY zhuETPSvXzhFiDo7u995t94cfTJUPEq7xDSoLZaj02qWofgqhr1Yp2NaS6t8KQsMdEoX8c+AmTwi SEnzF0TH6tKdT12OqUBWPSwKg/jUjR/Q0cHmmSn7ijydyo9lYuX558Fjb9OnfCl/6v6ZSRcWaw1q C95eISWkRZJ2kmcqp7q4LKd2vKWt4SvyWdncLLEYt9FpOS5duvWu7OCV7tpDFTs33LJVq+Avwvzp K3O3dzfh5ZWihnC5xh7EcknYG89njCvpM8JAK1wtstQ+qPmVdcOEF5/X3E9PW3N09jLTXRUHHtym Flco/oIzIiLStB9vBX/htTfI9NRTIhRjG8OsXcppoOCS5MF3bTIskVDBXpOAObrYgBfHOEk+ZxJG 8yljEJ3Bpaqp2CY81Fy2RTA2cCGBvprupNEkFC2VlVTOehKJMdvLtT1RIHkl/a2V3BUirPRAgbT+ V1wofDL7ulAlw4MpFh035zjiuQZ00+LgXiju0CwF/ZHRpmhrnQylielS2Rf8VAl3CHwvqzP3z9zw Xw+hD6yQE2iI8beslXySXoSkFvFzbh/HXP7CQAKzxwmclxQo68/FN9+0+56iZn23iL8pr5B3Z6lC VciODsmbvBODpgPcaOT3//DNochpc4O2H7LWVY1Q5jzOyigAPHRitiWSHXkHTryQhEvW5hp4HGZ+ TD5MFe6okTLC470e2OJun8Py9SAynzUW+enA3YDyjVjoZWDDNnSAg2eBkAD+cy5GclMUVcZGgMg+ Y1A4AXu/3dSICQfnTRuEtb4RFi2TtmuK9BzlAaCuTaqkVZejBj+Ein2WGhshcj9NL9/WcFG9TxQb RP1T0VFwfl3chNjjWNnq6bLHgJmrN7o0thG3sg406oBSz8XNjt+oIS9p6hO7bZPuvy2XKl99lvBj udVsGRq5y0OCeKQVdXVPTe+rX/RAqwVbaxE4kFphCw8q/X670HXPwN8dO6umXwVGMbrXtlwmKyiY NdXfbzDXjYe7K8iYgp9bKCZCQb81waCid68SEFZoIUpFv2140C1tHyKhS14/7Y6c0V9LSpoMbw5M ZFEzzHiSI7qgRJx6juvxF0nlvWPtFIVRFI56gPXotMe+N0nPdjhQ59YaKi7KIYVwaMNf5ZN+YIQ/ x6Dge0cylabMUEaQUsAMDUk0XkbATdgTzBP83u2besckeJZ1FnRuf9dXONtBKvyhwbszh2uB+UpW 95mioCHSdSf6nG+YsUduHWPRg4fgUXGPgQY7FTyxx5cpwLp2JLlxC2jNUf99XV4C/3YDsCX/gbCb AVlP9jA+At6eUKA+iPQcnghTVljzu+3Sr1uIwh6rWUd+S3330grOpwoxnqTPeMSMLz90qdSaLKsK 31VDtn++HZnBP8Zpr2dPiGclUI5JUeanGHNhxCCKDbYVmcJ+G0i40fik6YCOKf9SihP1LsTknaKg T0TP7h5J1VdlvsdFKJkSjRP6YAT8G8W46IY2IT3Ep9MlqWlRIbXwD1vJdPINDuK0h4HLlWg+/olr af6ityJR12qwx9Y9gahi+p8opuhqPPgQ3j7nW4WF7AyqLjIU4Je4ww4MDDmp0HDgQaBrPxGOukIN b0bycrd9rc+bj1WTsXrDgYFGdz26OMsdqhdEINFaWyCwPMPuT26r6RpOfYwT0u9hZ5TZC/B8zuaY kZmTl0mprm+bcd54+m6OGL44hia0L9zqUknCkrQ5K3njMz1rUV211bDH7dXloaeQUNmv0aYsb4Mh kE3B2bV88mMjs9F5PTfePJpe3Thd+FDqifKkGpN8kRqwIVqd3w4VbohBhdedsG4kXMYoDbKNaMNg I55obuk4n5iryCv/Ss+/tLPE1xtH3aXo1Xn5HnEmm7yL0iw2Akmy+inuuKAn0ke921VZeWYAj3Em 0MbJYvbj2vuXiOV4VqlgSDlPRjo6N3om0/F0bWfh11m0D+iEhbJ2XjHiichhS/2Nx+uPpl1CC+0/ hO3DjM7l4Bu+viWO/b0mIKB26P/RiXvLKEW6xSwHj2uRHJ0bOoPOx0yF2JjASkLCbMMm0YjnEf3g 9a/oJA+StC4SebY0lK8olS/HxUf59rALisEmlta7D7p6bVL7anI+F/Mjika1UEEA8Ces798Xkfli sDDIBXXsEVq6ZAq8gvhLmzHP9TSavHFHliN3yUKIPpTKHAeRfC3YfIfk0xeb2Gsfx140d31LQI3K NW5hSmqtQY8S2aTgQZcOtUYoQyf0KPFWrfWCmq4hyeL3Kme/0ZRwUxQQYWFv2kW/z1Iek0GL6jfC WD+MCe842cjOtIepk1+0gmIU7IboaLwOrh3zkz62INJ7DAfyQ0U07AEjmMAPU9TDtKuvEgP9HpoH osEzwSf2+4mr0+6HDmS/8h1/LZvhQhvoee2+EYT2VrNTlbWWAdP0qOl56LzTHJCXrmiT/XCQ2f1L ILLN4sjy4P2CR8TBPrclN1uNxGEVAqmeN4Y4G06rawcV/7VBvWtJly3DaFz34puRw5qGOdGRhRus Jsf47/vqtmu4EvDqAhNSP+Urhh2Ui3+9lT6hTRmHuSL7Vl2RvJXtKeN00+4QAFaeiNeN+M2pPP9+ C33kt9Uc+Tg8hqXpTOd+vSbaCZAGLKwlFuwcg9gE2ZHmUbwCzdzafk7iD2cz+8bca6dhdWln/gZt aXSgJCwrED1wYr98RsOoX5v1KrEOI7tGDaOtC52SUmSNe/VaOIrQzmstFiZ1fXtfs5Fln6uHnntJ RaCKd9ojbGYjbQp58wLLLas/1SbvgUIErnbF4zzy0DslUVWqS7jUvhrP9qnh2X5bETLkUhj2xnHD f4Rnn6iPyYRCx008fCps8h2RlvImt8KoS/gqo5z7R+zHeNs27Spf/kqlhtqe0VWMx/cfUiv91+hX /TB4sNxd90iedUGWIQ4XgyOWXL7ZU87JXrtprjNoYmRq9FPLgkz244KmOd4LqJlDCkxCzWT41NNv 3kChJoEHyLU0pkTD5d9+QZeyEKB8WEC5I0bkfO7HOF2z0cZjRuqQ+GAxyw31hLQgX7LaiJy9RlNz FIIAqnlS2FdKCFUeWnKz1m0R9sZlCh3Nb76QvzkEi7rRX19ccpOoEro1ECA3Egvx7XjsfRNdOxj0 stjei+daSqZP9TBVs+1Forp/oyqLnaSWSFyUwbBbrlOb4BYDQ4iEgtCWDPjl7trnmr52e1aVHdHI VDQwEvLt7EW+vUrOsVBHM3lAb6ruWF7sS4SGAFH6SvDmgbf5SZxKfYgJxxsc/atY8Zw4zn0zCsGL 4p9p8M3h9g1cwOKytEs8WPaG+I/v558eG8k8JOB/QXQM4etdIhJ/WR8z3BMLP7KXrKaH4d1oWXEm ThLHJBtfElB+CdiKRt/M1ZpHShZqbmS7/AnT2XU9Fy8Na/3T3ITfbpz6hUEULudd2VKDSd/GhLc9 qfoVas6wZUtUxhrI8iKHWdgjEfItTBmrkIX2yxpTsUHJD3ocupgKDugHVzH6fRZ813xYmITkj59v hpvagFbb1PcJET/Tn1sgkwbLE4/uPlybSpx+gZyooK8hCCp9U0YBkF5TQT/yGY983uE+cSGQ7Fgc Sn/XQjmIjtJU0ydQmqJOIWpkoqyct9/E9iw/3y3Ao+VwcTBBkTrC163zJdw01kYKlAURzVgzgxVl WBEuDTGsWhGpOMiCgnWk4H5xiJAbFBasT6YFYxwx6Av+1vv8rF+7UHpkorwaygQenn1jPF46U/R9 Mh2Kr3DqS0HbbzGxoGaODE/zAqyp2HbY3tTPmp/gusAvWJi1KQb5YcLPspctcDlKY5UG7XotN7IX TKMygwgR659Saq7B2oYYCTuJwyiw8zP356etHysI9xyvwJSqH8meg7Z/Mi7b9EfmT/3Gu3eUUxKV hRSeryDuXIqFaO2vYaKYvm+5ONiKp6h850eShTrF9n/5Qf7/Cf6fSGDhADJzAzs7mrnZIyP/By0z WD0KZW5kc3RyZWFtCmVuZG9iagoyOSAwIG9iago8PAovVHlwZS9Gb250RGVzY3JpcHRvcgovQ2Fw SGVpZ2h0IDg1MAovQXNjZW50IDg1MAovRGVzY2VudCAtMjAwCi9Gb250QkJveFstMjcgLTI1MCAx MTIyIDc1MF0KL0ZvbnROYW1lL1BUSVVLWStDTVI3Ci9JdGFsaWNBbmdsZSAwCi9TdGVtViA3OQov Rm9udEZpbGUgMjggMCBSCi9GbGFncyA0Cj4+CmVuZG9iagoyOCAwIG9iago8PAovRmlsdGVyWy9G bGF0ZURlY29kZV0KL0xlbmd0aDEgOTk1Ci9MZW5ndGgyIDMxNzgKL0xlbmd0aDMgNTMzCi9MZW5n dGggMzg3OQo+PgpzdHJlYW0KeNrtV3k8VP3bFhIzyFKWtBwT2WKMfUmyJ8Yu+zCZMwxjZoyxTCGJ UKaSrI9QoccWDZI9YrJEyhIlWRMqZCe809PveXp+z+/95/28/72f95x/znXd9/e6r3Pf9/njSIpb 2crrYYjnQGMigSKPUEBoAQZIG3UAoaAIkZQ0IINoCo5IMERTQC0AoamJAPQCvQAlRQChpqWsqaWE gEAkAQMiiUrGeXlTAGkDmR9Z6oCeH0jGeaIJABJN8Qb9mCKeaDxgS/TEgRSqAgDo4fGAzY8jAYAN GACSg0CMAgSCQAAYnCcFOAd64QgQ+A9LpgQsEVD/SWMCSX+GgkByANMXIM30KQMwXWKIBDwVwIBY CNyCyKwGMr38j239N67+KW4ciMdboP1+yDPb9B9RtB8OT/1XnOhHCqSAZABJxIBkwj9THcCf1pAg Bhfo98+oKQWNx3nqEbzwIKD4k8IFGONCQIwVjuLpDWDR+ADwDx4kYP5pgtm2PyzArexM7c2c5P4Y 6M+YFRpHoNhRSX+p/kj+AyN+YWZzyLgQwEVRQVERwUxk3n8+uf2jlhHBk4jBEZgroaoGoMlkNBXC 3A0mUgUuIAAcAQOGAGAI0zBcgUCkMI8AzJ6EAVgiGfJjmiqKAJyEJoMEPIil/Aj9ZBH/Yn9O7y9a mUnjAwN+ERoA/DxIJv4iNAE4kQD+hVWZ8pTgX3FVpjDFmwz+LUMJgGOJgeRfBLMIFhf0twwVAB7A 7MZfWJWJwSCQ8ItRA+DgvzlVVQfgBNzfjKgxC4P+gcxd+8H857j09YkhF+SV1AF5JaZnBEJJCVBX VQz790R7As4/EDQ1ZL6WoqK65s8BegaSmY2i/PF9MFfhT4zFMRcHBENAT8hvGftxu9yPH5Jb9lh6 2gdzqO7st4LU5X5JVV3JFnrZOg/F71Z44xMT7Wu1NMCzMWsVn7ImfUQ39lE4Uvvm0xXUMyr1QNGQ kCy2o9ZlbFmrmDYl/0qwwpkV3vAVjK9ydymTy1a9gNq99/03TDaFVL/QIi76eLPveXj9IKbIWa6+ baBs4upkDYuWZ59RsNktuTvuK6UchC4DjLOgCLVUSTDML1I5ett+8ZS8/cWe8tPeTqfImQTYUj0v J8PKtfrKDapV4vLZx2YRtDd8s4l+Wq0nHS5XrE76qWk5ZR/LRaerhok3T12YEThMN+NiDTtQnLj/ +ocEmVPTB18vUGFljtFxxobBAQHQR+nrU+y2o5U01JCAtpRWSmpCf99HiaX7sYtx4YKlRuNmFmPL E99RaX6qphgWPob/8L5X16Anelgmw4rYYJO/ba7Sb8OOcpKW4y6+LOit4A496Pilk/+WiJAOkXBW 8sWTyHcX/LjuOoKcnzowsvxN6cYJqDPJY5F7MuiisMamcY/ymBxb1i3Y53j3Qs9JM1QU0ky4Hb6j zshQ83sj2y0DazTnUlpBdZ/UF20UTlZ4VyzfOZPfyP2pRCPnoc1YWbCEC3Q0Pbi/TW3Klru5u5LG 3Zx/LHVDmrRh923A6qS8cFkfnL5dw/WNXsItK3KLLbNeNO8mV0za747jPcmIOpzkXbtX6A+aInvO vPXtkyt+DxnS3TM2uICS6ljdvpbavAdwvcQvvpEw4vRtPRG23a+rmt72NuXhs8vzXt9Ouo0jrD/t hcQWWm3feDuRO5zY+BA+lI22KiMb7+Pmjek4KpnHc9RUSHa8KHGfxdfDWGeBOD5bka3tK4+nzll3 SBa3efV0V12cHKOOCgmrFcLK262hyQb6GlpRPHM9N5IfSPP6NKpM0Cgce3YUQtiFzgj1BqteQT4x wtfrK0solJWbrBYbIhvxm7jCw9YuJ1Sp859MTl/ak/bm22Wdx1NEn4E2CVv4DefNl4OadmaVb60O RfOPk24u5vpxbDaeN30WoO/LGLSITI9v2EmXZG3bPxapNTPFqzkPzc+67nE7W2K8OZpNlkMY12/b +eg8x8Bn+KlQs1vCXiLWNskm3VXf0ONJmOdZ2W/SH7QvdkefZRA5vxQ2hZDav7PML0ReT7yVIDSc O6+xuS6t/ol9KKMgvG3Qy981hdEXDHUSbLbWea25jHqnQ5DipUUSfc0u1eqUKb5Qy/C8rjXq9Sg2 rVN7br3cX3T2NYfI8M3xJ6p05cthueqKJ8wcz/bxGndtNhWYGGbON8iU+fLN8aw5ovqd27WOVz0Q g7LLgpz7JyULzWMj2M3nj1ffo9zeObWT4AuPqucpLer2GD2eXRpxaJYU2BK2kavnpldmceRDzANG e8fdd49knravHHjXHjMme6lVp3Oao9asXEp/HK9XYzzSEt41VDPsRj/3NW13F11hzW0d4xh8PK7N 2I2YKyEmfv24jemXq1GFjsqM1gJS1lzcZ73+Ixnf21z9WAzluMW39EG2eXPNcm5dMkFebMha9gEd JpNVIs1iig0TXxm9lzrxlmSZ+8gzfKWS21FRrqf6Mb9fAMRp7eDQNfYbnSiH18bQyvH64SxeLYEF 3ymVb1dccgIO9mnzOh+C7brr/yXNsQBBA7DNXcUMJf4DeDG5PLHT0A1r3fsmVxuOlSIsYMdav6W/ hx+E8W2NvJ951rfTflS/JJ+Evv9bfIe+hP2w5hlWQRNQT9SChRdrWVoDG+mh0I+XcK3r+jrXXmgv OVlstyjFgjfUhUR0xKzGQ3YdUae1ILh8k6V8EikQI1IUNHL0nNpS5wfvq8ppPq+sbaJu5hR7jcd5 T8TrnrHOSGlQCLYycA/67al61ZK+xrAgwfsNmR/XNPHd5VnmLsYdPZRD7dcObo4jsbkgN/7Icnal 662BbRxVpqLtxD7L8kN34Z9nfWSWe6uEKWfNglYfx11Qqmwfjn9e/8WxpJ9qklBDUm4pV0JFKR+/ TWg+ywNVbtppSH3eUP3ycLP1/NTGUPEA95fIEy6Y0C1fx7LgnYdaAasC75FO1cd2Vl8M1K8d8kTV zud2kmt1eU8jDfh0D5Lq9u7sheXZPp1ezb/Iq+XVdGMHL8fXxmqUpld9ZjGa+hXB8FkZuNvU7zvw +Vr363u2ma6uVQoK1vi8R6+w0zLaH4du12vq3jvWYyRY6by/9AqhdyGRd45rNdUN4TZz6oX0uMqi 0uRjP+TlF703+Ct+bz+rfiBNezaVJorAdWPXLCHVmIjCvpv3rjcOfhwdtGygky1+d3TZIe+/JAZI uaLdzPqR4AlWF3rO5YpQiO5HASVIHe0jx1YlkU1uDT5xKSS17tX87+q58oYOvsZLV0uUU7xOOVHc G/EL2tDec3W1BUVCLmL5xUm58bPTJdKQvitrOwg5rOb08LuaajsDXU6dN8EqO7nZHOqorgmhB6Vv iKErwS0m5ienD7p+TGf3fum0v/b7RGHlQM5S456arZL4aBkRv2oJB3Mn+mbMTUuuBQbPYqv7971f InTvm6Ogg1eOWptVVIRlJvEme1opBkegbLk8WXjXSknPeinrM0l2wjkfPMT8MKEzHWCXndv0kuB6 /Xoz/VW/44BeAtTzddHl+l2T68t1r0/2kbZCNM+cIndR29M4pAWPHJ+KrajiWkPNoruKqX2/vXli femdzlo2f2Xic1+V3VOTCBFRaiHDHGuTUFh1XaD0aNc62zrrdi28Yn7IvoAws3Eq5eHuJ+JXshUa yuMTCQtvY4yM3dSsaq1DOqoS7Q+qTAhhL4zyFT7i2OpZiqkeZqgIslldMeUX/Zpxbd7Hf96sPo4c 2rGSVNDznmhbd19YLf3t7dgerCvtqRDK4SyZ1v8MG9OEivv49UNuT54QZiv1UV0Jr+Cwz8MWDlR+ +ccFcTySW7zSfmNO5FhS4dwFbXQMXw4HaTpKgG7WifE6552pz5pECZzJXJ9ls9r/AbkQ3AdGFy04 WtJg7vscvk8vZIjZJzGKMaUm7CwjTtBiXuP7/fDiDofB8jxqbdEdjbZ73GvOQUZ3QIWlqK6erTxI ZNPAged5y94exQ3Cbp2pi29bHV/Kvp3MdTPW5pCa8PdXTD7Sq1unKVuq7TJjKFibpqdzvv444cgF Ejoz6XmU+wDRsfTevRBc9uN7QwExOxweBuoRh4lTH+n6sYURli3zqTYd527qmujltoUpu1oStwO8 oooa+x2W6YLIgQXl+Q+CIrmONgfN43dr1oR+yr2RU3XSwOil0q78l5vC/rVLs+HFhzdqqg538HkE ha6QKb8bu85sbrTmtHhxHeheErAKFcjYF4VVk26gya0gxSjL7lf51RHTKcWBQhk8sBiWG/mZ5jFY qYuM23QRaPwljx55HwItYR3p9gyKGatcnqheaxBRzC2WpqHuq5WN6JoWafSdFN1edLEUEJfQzLEW M7W4s1d8Ya3TL7GXwOnG/lLcJUuNXSfkKThS5b4V+uIyRzmvRizM2HlFUtwqM9bncAJC/6odDMot a4QtczCcr4RyyNBgcycceD75ViukMt4SPwQ3tnuwPjfNCn9Z2HMT22psKng0mH8vhc2897Zmwyx7 p9GXpMpYlyE728AuTIjM2jWNSM4WwwKD5N0aFJ3I2jvRS1OkE3dltqKkBtICFgg215I/DM4+tNQ7 v2NmJC8vEhiJlEDWlzifOxvh+DA8PguYsIjxkGKLvKbAqfn5QIftPW1xt2vsPmwXoUeDgl8fc4lt eaCRAvAIy2JtASQ+7p29al6q3MdxvpxIsfpaUfUafSnpaAUW6uYo5YHE0CvP2hH09VaqVr1CvsGZ mwXRTf69yjTmX0L61ZJ4m6xY1WQ+kpzBwoLBJ6evoy0OAgW7dinPEiRVT/cGPuFyxY+VvJqBKtag NZ84rF5cv57At1G8gfpmm7fH4HK3hky4KGPJp+QYjxih0sseXiukI84xWWrD/RRQx1bI1G7XkzO4 Rg1PIDmxqEW2tQj2GvrpFr72pRG7ifGveyIXl0AH4VLI1fMn9g5uePA+e9hRDVe5nTEwZ8kVHvr5 +ypFKWLihYEGu73o4uw+cIq1/iImaIi2KyZr5bvHHWrcrasj6ZjPKNWgdD25mtbdu5ZTA30+8Zho PyxnLHaPZ4XscMSIPR5D0psNY/f2lCDXUzCj9EKew4fr5nURKimlqy0e71gNSbQ5eWezTdVUyh6I ke1FfLmYZO1ciP/IhoTcUI4JR7BvG4lTEskoPytIocy3mmao0J6n8I4y8hfljZLudir+Ly/I/wv8 nxDwxINoMoXohyb7QiD/BWXL168KZW5kc3RyZWFtCmVuZG9iagozMiAwIG9iago8PAovVHlwZS9G b250RGVzY3JpcHRvcgovQ2FwSGVpZ2h0IDg1MAovQXNjZW50IDg1MAovRGVzY2VudCAtMjAwCi9G b250QkJveFswIC0yNTAgMTE3MSA3NTBdCi9Gb250TmFtZS9SSE1QRkgrQ01NSTcKL0l0YWxpY0Fu Z2xlIC0xNC4wNAovU3RlbVYgODEKL0ZvbnRGaWxlIDMxIDAgUgovRmxhZ3MgNjgKPj4KZW5kb2Jq CjMxIDAgb2JqCjw8Ci9GaWx0ZXJbL0ZsYXRlRGVjb2RlXQovTGVuZ3RoMSAxMDA1Ci9MZW5ndGgy IDQ1MTEKL0xlbmd0aDMgNTMzCi9MZW5ndGggNTIwNwo+PgpzdHJlYW0KeNrtlmc4XGu7x0P0FiFK oi2ihWBGGwTRInqi9zIYZhgzjNGjl4gQJXgliN5DdNFr9BIlogTREkSJ3uNMss/e2We/58u5zrdz nbXWh+d3P3f5r/u513UtLvaHugLytmhrmDIahRUAC4KlAEVNTVUIgFuCQGRcXIoYGBSLQKOUoFiY FACWlBQH1NyQgLAIAIJIiYngHjIyLkAR7eyFQdjDsQCv4q2fXhBA3gmGQdhAUYAmFAuHOeGS2ECR gC7aBgHDegkCgDwSCej8DHEFdGCuMIw7zFaQjAwMBmwRNljAGmaPQJEJ/VSlirJDA5A/zLZuzn9u ucMwrjhdAO8vpbcAnE5bNArpBdjC7MiEtNC4ejCcmv+xsP9G1z+TK7shkVpQp5/pf/bq37ahTgik 1386oJ2c3bAwDKCJtoVhUP90NYT9oU0TZotwc/rnrioWikTYyKPskTBAACwqCBL9w45wVUZ4wmwf IrA2cMAOinSF/bLDULb/VIJr3y8dQjoqmg+VVfj/ONs/Nh9CESisnpczDAD99v7F4N+M6xEG4QmY ggRBIDDOEXf/uTL/R7F7KBu0LQJlDwiLiQNQDAbqRQbCpRIWEwN8wAACZQvzBGCeOMVCgig0FhcC 4DrjC9ihMWQ/j1VMEhCyQTs5QX+af1nExQAh+b8IIgwIqfwmCCCk+ZtwsQ/+Igmcp85vEgGEdH+T KCCk9xdJ/qz5F+HGCBCy/Rvi8tj9DXFyEH9DCUAI+RtxgyuE/hviYp3/hriymL8hLtb9F/77eSko oD19QICAsBiue2AIGICIgXz/q5s+CuHiBlNVAsRAEhAR3Ov+tNq4YTAwFPbXZ4KbhD/ZDoEbHhjM E2ZDFiDqFVQkqTAJ+ozIo6RUAbNgLIIpmd1PMwRpVFBJKUnYtiqe73GGHJ7OPHtKzmMh3LfFKeZm 5sQNdaUM6+kPQSrN9Wc1UjCCEDw9+fNuSPGkWvfpCL6gbPc23VhlvY8/nUQ0Rz80aesrvDFtsEIJ tZT/iWd8gI4zVEJrf/954MWU4s4IRXRpRKZ3OZ6ph2YZ5evzAZEvVxgilel0rzlU8jR+nKLRVU/3 LJbxJLj2/ApeY+EX1RdEBFlSBWsXTaZ6T5a7ei5Skz8zkXCQCHcwF3aq0FfdaSDxXqpmH6lUZy+x uOu/NFNqZm/SvEhIvbmU142tNyy/WGbPfWwxc37O2BXI1dxrQupdLM4yqbmHvoaP5FpLCox/kpxw iYa0z5l0sFhdK13UdY2GyttPlEVLktvL5v55RQZnW6LVa9I926dg6apnQSohEkKcgyQjG51hcVK9 gzR4rQ7E2byXeSPf1yof6sGoV03ZMvoTvzdjCoNkngV/7Ix0ux2Uo+EmuMHPikhdnWYE8Qid7uy9 QPYLoBdKeHiSkhK4tu7Yl75Pvhg8VM0nXD6EeXLwp6hFkJaBn2Q41CjPbHm6ba8fyRpEq8oEXWCS C1lJRKfXQVnm0qo9ZRQWLDGdi92nrr77gxW3UhOv1CQKH7NxeehWjixq3dXLRPokkAae+i/NLoLN q2XdSjkrRxnr1iNep8wyop1g7r7b01nanLyPBANMO62yMnkwZEsnpP4sbtRY+Zb009rNVl99+pPL tY8Naua8u7aOuzLF1dMQrB/6EAIXxzMBXdDVjg/jRAxBFTyg24TS8wOkdUSE3w6hQ8muhJzzL7R8 TwoMvFJ1BN/JmPRleot1jAR5QT1cnj8bNHpXZKeWTsHUsVUnQPdQ4X7uM6nvx43GGXytE+5K7HNb 5ie0p5tG++tjs980ptJWVaQ5XpbHW5XqG5eKdck4hh9khcxSCZwslYWjY5c5Ji6VFsutLfvDCWJ+ ZGduFBzte6/dUKSzV18yftJ2S8R6rpHcPCbnZl5N6mdNtE/aSVrazs5hhq2FI+p6Sni3Ij5J3hxb dLik+0ulijh+xlty1kYCp8+qzUncxbar8bcaTTLGxd2hcI7XcvF+RmOquxxQxa3R8CPqaRpif7P6 ifGhTbLRLU7uxpHktqH9LWPPcFqNAzkBH8gQaQPQTfshgI8ByOW8e8C5oZHNhRrSplwEEcD4uKWr r1dJ7UBSdw3e1iPHxQIi7lY5Or+ehkB4bfeM9pHOOvQ5wq2OV+22I5a5OK8FY0f2OLLHJK2yjlrt tiSKzPqvy3JuVgQdXP3yND+31kFsQt3clXROY4yL7cZwosB2n/N2DjIIE8HG8016619gV+J/KfON wcsy5qTNo9VFvrV3tDC2vMPCSgQKHo92LnKLv6z3f9avxpljdqcyeNaVNWJLLss3KhQ4qPswdqtU xpLpRtt9oies3FbI8O7juXvMT41cLvtGWS1w4V8udmHuLa5yaL5qvEE4kBo6x/3KT+KJAaYgeyXr o3tODVRw6KUv85TgAPZ2AdFdjb0fyl4fKFtOUwk46V8HSIMjuJEgkoyUuXmrVkWNB+oCzu4G20vd AWVr+toMVVaPMVsy21QC+td5Lp62NeOt1X8FJ15iimTA/Gg+9WfziERUe/l4yNF9tbUh4YS9aHJ6 JengZh923uh0RcFhKsXjq8yPl9qW1pLvnKctSrw4pYNFoj6wuuvBVNVYEJeQfGGDj7elFTGh6+Zz Yql1dI6Put9+0NECn/avzBQcHtdoMlfTzDQt32B2P3gdayVZ82nyUzeVxwvKp5dpUO3aZd/Z1/1Y evRqwU3azz+WB1qK62lYkCGoeCrqEEIq1W/vaPcScVcTBwuAy84/AsfMr2J290KEmGSzSwQBn34y zuTzyndTzY7XOGnAh0LYzdvFymvOSC6q8x8CLNqeJxn3Ooc+Mx+gEc+CfrQBpDqhYODqtKWkK3j+ aFq0lTxXgpTSqrnfjF8HbTkkvG8TqtBKA5+m76Ps0DydlqGs0DKkrhzhTPNN5F3wF/9hLDR5E041 ujJ3myLtO91iViSde3EjbMd6KTUky2WEUTOJv+tUm28ySmc+22cBxfFpHJy5EMu5A3umepZOoRFr b4v4ZExHpA+er3M57Agk3MTa+2EaFp+QUvR+6t69hlHjnGtv5Ci5QhdN4k2rWWH4flBYMsl5+hVx KjS/8ptXyR1OsZFmG6cjxqJ4bA+R7qnvFkNk20vpJqM+3dBSsGL45jp/DdmdNzmTrPI3P+4z3N87 bmkVXdNXK4/TMjQKet309NZ1Twx1pRhvPbCXQo9yUb7oPyxFDBIS4x0fhdkMqNaZo3oENsBk6h/b dVZ/rM3i2aMeirrQdHIc71JNNiM8lx6m5pLkVNWctyqsPH5wqUxdFb51ef8s6T7/jWtWLG/ESLqO A89YSYJyQhqCKxju1mWxF/JRlzQ1UvMmDE9LrJpXQGVv10gN0h0PH/vJi3c6sPBZkV+5LCc5oSFv MV5Ilk/XSUnzZZ/mMCF1NE8mstBIRUGtwS2KtJY9NlhYF6YKHm+ixHY1txe/A1cMPaoze1MyuuQq sG6impMhDQGFVsBHSFyy0o/2lHOT0zLf8MzWD2mGihhNr7HbnKVf9e533YvafoRdbbXLW+5c/F4F rW29n18gvnLBf6x3ZYRgOIm5+Ieyg81Gx4BFI/9MFzWYaGZ6NOWZExREL/impmnszmu/Pcn5dtki rZJomLSWWuC9YSCLwGzdu0oLEIPI7Ix2OpYulJO/T2eqXvqWeGpHd48UaR+9Lfpi7X0hZ6/JyrWL 5NEFDbqJm6ZWukHCV4IILI1zdCa/ishgqEH6Q0Tgy9eafIL8VU/aVl883SVGk5zc23zpYeqq7lo5 dylnUwbluCEl3JoxnLFjIM3dah3PoCOR88bhpUwY2FTwW0FnBFUTPF8aKanJgIXonh7M5ff0Xuh8 XTE066NkRcUHbPXoase9LKwyEAXwreuL1nbyyoTvGoXmPK6OcRgLy/CJV8WbWF9rMPaQpA69GjCw EHGtl+oHW7nEjqs7Ub2ONE1L/IcT18p6oHm0b6/pKhKjpk+4XBVFQtnIV1o4MAY0lBQKM8Q8Qry9 a4dOxJ/SpGlGqfnit8vjXU6uS9F5fXS1oXU4/Vj/UwXPikQvUYQyzbKUEbpalsPuuisiwX57gAvP fQY5q6UugZxQHBqQQMc1xpeQJxrk3yD/xOadDZkBgU2yjO1m+NXhLvAHVYvPhPKSR/W1R8kJSYlt 3EM+3V6iwWPl2PKoOJhVZbKRvXHGuFrwnX+KDE3rRzyHd+SVRsKrnM1pUymfCEWm/Rgnl1CMrtHf sJeBJbKhLGq9FNcNFZ7Hy8dW9dykLnYoHbcsfRH8wL4tvgL2XSz0U6rOhtcz+GcVfdb294z+doHj 9hSoCa+6q7IqTaI5D7LXlR1OXhAMiUYq6BNbQ7frqn0liVjwi/l1aD7MP0C1T789nM6VY08Er7BN DYPKxWko9BqD4YEyrA8YeWm7A4TnzANZNAyM/coV+0pleoyG4Ft1jwZTR8KqSwOt1aJ1Oi5BrpKw Yu2YNynoVD7l61it6O8XKRS1HG5GsUBay9OpDWgINQsFFdIt4vRa1lcJohlNd/71NrC362Y0163M Ji69W0kzCVI0BIy00UVMcwsfMx+CxN5AbmsyxLUms47fl2jeH5556xhNMVlT4HOVtqAgvZDQgAHG xaJb77I601MTSG3WKTwmNPohUGKyNqw4ZcSm5GYKt4EJVg7DSjFXUr6MnHq3x8RrOxudKcdW1X7b Yv+b34xZlmTGOD7+IuHWNB/mMFQJPFGrGB/CWvXZXYylqOfz1vtyVqZjFZ9G6urSjmRkVByJmZTw bmnejbZCRMBrDhhoTFW3b+H0DdGXx0eejZ7Z2TuesjE+IWl4HEbbsPwG/poyT7lBkdEVWQ+DZjxM JDMWnoSoaKKa6jgSfVX6vMkpvMD5iv9rlxHNXkUDpRD5Ax+a0dmaYbWgu2xhJrsR7kxTz8N8p/B3 FCxfwE8QhqpyzXcGGnWdDqPo+OC87DFac24cVG02uzFDJwV0++JF55ovfUfND4eNYp1Y9CTovQUV PJniKQ7GwfffARKHphWuNzq57C0bswmfwp6HQ/H41ElVINkUmncYLS18uO/ZHlG+YWVivRXZZr2q eSd59ViKchv/ReiOtYwnmNow+ezRs5ZjLlWX2WTzd1b0kT1Gn1t37Vg94kt71lW7XlLge/Y/oDV7 wIV2YYxJIF7V5STDhlZXUEYeS1BbDDdcj5o6SH60e2PediGSOscOdXJrdPR5NalXI2VA0p4JT1NV Y9IXyAJrf3Wlfd7cbcaNJ0df56koJQMCQB33ajPd6LWX8w6MoitJORUXYu5eI+oMiXhVequ72/2e f1l8sJxLYX1I1mPFZkuourd1FtthtO5Q0HOFVFmSnoZeaBdRX76d3qnYsgpG5r7amZGtqzlfTbg2 mJWt/N3eQjiBblx/LNEZEloSph6dr0w5mE93onRiyew305lX/444NvqtW28RXMiv0mFh/sL3+qvn 3/m0KlRUR9bpHYNUUu2pPCvOHZYBsXa36Mybry7HwhvvPvIriaECeAKpGayDp9xfcSXI5XMRB4u9 rXgaIYQ8Tc/eiJTdHYdtlqkwCX5uNzIvKinWt4BvSiexiMaXoVS8DSeJNoxLHqSWOESIRxqG0B6L qtAeL5ZfukOeDssdqxCGK/uhYxBGTKRBDnvjJ2mRkPvRFFoaHRk8+Cd62rKPWu0MZnoYXFOEtDIx WfeNjKme9S+YytnT9VEmRYJE++sl+SC1J2rKCbXaDtceEMsbjY+7fFSG+BdJ0pPkaTDpPGyDTK5P PoklwzdElv8w2ukljungGjTxqHaZ5OK+FiULpcGfUxpXCqG3tN0hZYKC8Sx82zWQkZcqDXJRn1nY /OKKK+8tv35mFfCpZFlK3v9kPgRj3h4fxpZEWUvt/TF1OdG1zHFe246NVp52usTXWGfc/V5QRtqh +4al8fyE4yhk2JaompXZYJa3h7nx2lRV6MK9lwy6PDMjw++U3QzNHDJ7RaKOWiYyeFV7pHONPR5f +IrsiNp0xSRfJ4fzIjS5XjF5b6rSRXjk+Dkd51sUDR8l6LRnKqsGd74JkG1p500xn4YR71FBbqoM ChbJYqwXV94x5F52x7fGvJ7Co/4+GJ06wucaQo6n2/HhfJl21ximHNoYNyjExd0dNzTdFO7+0Tuj lOH6mXyL89xqSMRE+Y33ml+oP5q7jF0QEi5IEDJeWdaxJOZ4N4DmdvkafQYOnwm4MqinHT3gegNG YKcfL0oxMLQ0M3nECZfiYuhLmGLrS011ZIGSUNkqi0/s8Sy3sj9klY/zNn+77k9iMiAjl0UT0uO1 i0pPoD0jEGn4SF9+8Cm2lZ2i+KScu2EiW1/e2j/nZdhD/Wbth07TukV76gvJw5sT3gLTqONYePNj KSh293Lyc3Obj5tutORy41TU81Lfq5menKUuI2wey42EbNIfUiGJNrQadNJGPgsnsd8943+5Tp5B GHgeLwQv79GSXhF3DzcRNSXP3B00lVv/HEBHz/weMztCnVtXv36gAloNW1oRIqG8aRpwVP31m78y AY0JY6mn/8MWLh265rmtdunFto0gb+LDy08hStmmL+CuZaNGGiwQkjN4VK59gp6h1pfcS2j+hlfY Ej/Woe0U2jexOacUSbJE+JJjCpEbX3KoUgQmnzOU6veJmHNXt3im9UXa065bkX7QSuDRAj9eMspU z9ZZGPvAOla5jvs5o48Qa+ocJhFyIs4ue+RtxGNZiYV2EzuqnCO0dMh1makfnHiY7JkRqYJ5Wu5r +BWcYBNCzvkCN6YREC/9F44blbQuKJ4vZlff5+U9kpfIk7oqy7YNAn1xPjZKvnWpW0MpJIRNUWz1 ramI12WNqsZGTZsHg1ESu445ekM37uONmzxtpKQKUrrzdSZWqotmTnB6hWxTiWl4Y2iuELipf0Dl TnheG7qZWmilv+ipFftIBnxgKx3XWHmaEpGUiL60JBAL+l9eZP+f4P9EAhskDIrBop2gGEcysv8A WLpPBAplbmRzdHJlYW0KZW5kb2JqCjQ2IDAgb2JqCjw8Ci9UeXBlL0ZvbnREZXNjcmlwdG9yCi9D YXBIZWlnaHQgODUwCi9Bc2NlbnQgODUwCi9EZXNjZW50IC0yMDAKL0ZvbnRCQm94Wy0yOSAtOTYw IDExMTYgNzc1XQovRm9udE5hbWUvSEtSRkpGK0NNU1kxMAovSXRhbGljQW5nbGUgLTE0LjAzNQov U3RlbVYgODUKL0ZvbnRGaWxlIDQ1IDAgUgovRmxhZ3MgNjgKPj4KZW5kb2JqCjQ1IDAgb2JqCjw8 Ci9GaWx0ZXJbL0ZsYXRlRGVjb2RlXQovTGVuZ3RoMSAxMDU1Ci9MZW5ndGgyIDI1MzcKL0xlbmd0 aDMgNTMzCi9MZW5ndGggMzI3Mgo+PgpzdHJlYW0KeNrtl2dYU+m2xwVEIdItyKCwRSAoJQkxhD4G MPReRVpIdiCQRhK6gHRhKIogKqICAoJKEUG6lBGQpgNIGYaigIoivQii3NjGM5775T7323nOzpe9 /mu9a/3etdb+EJlDFtaKGALNHcTSqCxFhBJCHdA1tT6JgAMIJThERkaXAeJYJBpVD8cC1QGEmhoC wPh6AAgUAEerK8PVUWgIRAbQpdEDGSQPTxYgp3vkcxQawFBABgmPowKmOJYnSGEnwePIgDUNTwJZ gUoAgCGTAavPR5iAFcgEGX4gQQkCQSAAAgnPAtxBDxIVAvsMZUgl0gD0V5ngS//u8gMZTDYXIMfm PAKwKQk0KjkQIIBECMyMxq4Gsln+z1j/C9XPybG+ZLIZjvI5/ZdG/ZsfRyGRA79F0Ch0XxbIAExp BJBB/TnUHvwKZwoSSL6Un72GLByZhMdQPcggoIg4pgRHor46SEwsKQAkWJBYeE+AiCMzwS86SCX8 jMJu3xcQmIGxFdYIK/9ttF+9FjgSlWUTSAcB+I/wLzbih81uE4MUAJyCK8HhCHYg+/f9zfmnaieo eBqBRPUAlFEqAI7BwAVC2FvEtlBAMAIgUQlgAAAGsJFhSlQai30EYPcmBCDSGJDPc0WoIAAYhUT1 ZX7Wv0nKAIzOHhiNgAep7D6ChH/xIdnhvmQWic4G+KGqATA8iYEng3Tyv2ZSPQbAPD7vMjuJjy97 5H971FAAjE1L8yeDRNbfMhL5Tf26P99lFByAgWSQwqb5obEh2U3CfRnUd1FFBYDp/G2h2VTmP0rC 2SfcGTg8+I+SCDjym/zPmgg4O5c7jvFF+PcB6+jQAoIVldUARTUVdr8RCBUAjUaF/DPQlkry8QUN 9dgXgMNVlb8OHO/LYLAv8uXLYi/Pd5tIYt8DBANAPCTj6l4Sh6vCQfkVt+WGZ1L21W3dQyVXoI73 EGJmTyIuWHFH0MzSnbu7W+UVlrLOXu4clRxCPc0M1+Alt1Rqjpkfrsrjvy952e8OUhn/mOevua46 kyjOd9tyqKxYvCnP9T7H5Zx4u5sYBY1dxRtvfYLnR69/CIpye6jv6LG/pFXTXvjEU9k0hp81Nzz7 w1xL2yrdKiDJg6vGZTINGburXVJYfRBt8Sy9UmdwiKyjkQXVGlFeyjU6f1Tv1y69tea8T2p2JYUS AUZFLZvjiUV8fn9mQrSr7avi3ZFD0/PN84Kd3gpeGdnqS3Evx7bMPjWPcvdDyd6TonTNKR50mMxF geV3kfczOCqZS3lq3duW7KQyCP43wi/8OqdRKSCfuZW/ZutRumHKzPCHJXqY2fkea3lUs/AEZ82o B0qjGGuFDvUJhyh1Y+GdkJiKQURCXvILhfgFDZsBe9pku2PQ+jaX3E6z4cCG28Qk8xnjMMdr5fOT DWe7wpM6zd8aH5/5reeS+CLSjVVhossZ2+Ghg+2ttwwL0DeZvVVPyUGWdSrepHTrpaWb8TZxaSdG 7vQt4TCVHd+3f/qUMtMdKxV3XWhi/ZM32mS18x1xbX7Famqkz3FRzqaF4as16q28XHobGGS47PhT RnB0D1iykgsU/9Y7QnWarW6PEL6OrZiPgAicxJo1haRrG0SgY4VojIs7vOI668oPyzU2EbVznDXK 3BqbZmpSbJH3hYtG1tG20CSXqG5BjPq5GGQLhZi4dVbGelTwpF8V0We7zArRz6REXEgptKaZ78LS jHhpFwp7UtqZcHiwOldnK86s4e3+36XEypburBu/ugImJHbC+Nwr4niyqz4ZeaOdeEh1qTb1XCc2 fRL5Hv/GuRW35X7wzaudo9XTl5JCis7w3nOVPpGcFXluZOmKtzJSgAPNcjBSfbXnflspjxDmWtOF dCedNKdpYt7aQx6pDNrv2jKSa68PcDcGJi6dShrTb7gTu1387ppmdlhYk8weSVv/niqZcK8M6cWJ 7Oz6EHNVNNTCan97uNf76r1gpje0ct99mw9qOSg6GW2yg6sSmYKSXs9yXXn4CoZ+20jULcMaWScL n4uyPZ0VnfQAEnQns/kcvz0/Cs5UzneKkeU1m9uuLjoZu6pZKi47oynE0S60LWWI0h6tUNsNxiyd tjTDW4mxXj/iEyq4N9Ms7GaJde+lc0bFrJh+Gpsaik179ioyOew59yHRhaeiTkPP08VEUrXkONPU Zt9eQspK/PVec2OXRg9pCY2N04rsbgpsoM4bCb6THqIcN+BsbDmkqfEyvvVaspHejYW20mmV1b6c Vp/HipHJpRI9xcpkyz0lxN64XiJqLrQZa28+SXG1lLBDvLGuW3mZd6tGcP3AwSTYMfuyiUexA4pi ffqtz4ZDBZPmq1oOCNP7UJZn6yc6M7tW8pyiFgU79mp7qvm324Rri9R2j5R1Q2V4wx+pb9GmepZP GfNGbCuArW63t9p729VBemCVAS9fo0dl5riOu+rbx2R0uh7c7V0cKpF0T+KNcjVisuoaZOKPwmZx t+iJFu5Zg1H10BIF5+BUu+NXlD9wJzAntCS8fP8S4SW9OeByMdhxj13n3ZqAt5UB7YoPUnfWDRe5 /HmGWO/J28MRUTsyGt3btnN5PHlqi3Yo/rTcsAhM9qTBHxKyrC6fUBHJQS+wKG8PSl20Xufq6Y3h tLRiaYuhj4D2CYZ6TKlba+BFY0ZJi7DWww67Tho698wtxO/loac9hfR43ty4adJbKfC4ETgQJcsr XX53YoKfaK6725FRHOPCI9IHvs4fr4Iaoo5Ami1kawyv9uBlU3jCjnptVnJquG5H1TX5vIp4CPZr 3x0nz1jeZjyzgFQ00XU3hlZkj/ySfwoXqIu9er4iU4LmPvB75hm7/Koah/VVqHjlJUxD1q4Rc0oo 9P1sOP/tyvtTXmO4mX7aSvblsyIV2DjcvN20gsQvFqx9N/0tlINYPreWNvc/f9T6OvFNkAklGOUk BTuvF85ppBma2d8brxXdpUlzth941LazFXMrSfRD2+P1oalfzjWkPmxJeZnzNPzgQv6ty58irtN7 E7SWo1ZzkpNnNl44K06u1Ymhx9Sixi4ylrr88w1yPPIu7HCw23ZUPrT3TgP+zaxHKoW/lltl0MKH e1tT2+lMefnj79qyO3YrCOUrLkfvtoZILv5BJ2wNpxUAyciZnpFq89iEgdbTw8laTA23vuv6/nei +/UxA8mbq+LdZUNMB+1kApe763jLFf1aKUtO/foCyyge72Duqt944ilPupFnyr3uZhgv0H1QEkJn SsfUu7c21SjBhk2+Cfeu7sNlSuvZHy5OflBQZCo3aRTQUJ/3nrYYKb2dv2EjJ/FFjC0GX17Y7hUo LQnVg1YMjNmHd+Svwaexl3znUhhuXSrJF0dPtp/HeyQcShdjMPVcNqbI07maxUs3yrCH1XYgGc6b l1p0Jw8u+UbrWPVEhofZ9xcSZVaCUsc59nGldnBBYx/GD41qQnKLB7VcRMxcRXI6BsxmMIi9NzxI hiq1q2UXTMcaHBlXbIJdlkyq7p3VdZwU6rxQievADFFWzL0buWgxtOTbs3xttoURAlDxeN4Xuilb 3qf9gvv3KYUWHknZs6KqA4mpqmzVPLLDobyQZ1OWuhuQenbVvsCCSQSHegG+PXV91lohHCF9H/o/ wm4eL+jXAVf4o9IrxLaVFd/DnvPcdVHEyaINNVRb+37OSG8yK3AYpcQflpjd1hnSs2BRc/kjXSd5 L98cj6Nxq+nWZBamdQYbyORF1XzUMXgE5wrSifPgfOZpD1l+HhQsji4phgbqnD/fk+kZ0Abj25pY qotkwnZggzklBWMWMeONKVHjhMRohP9gjE1Z2YezykefgJrUuE8LtkHArly683gi2cC9ZP5qfDX/ n0L7X9xXuHLKcdC6yqQsJN3RxVU0eiqz9nC1mFhPebyja4G8xMkV1cFHU3oFixmdXLvHs3Q1FGM2 ns5GLxPJqm2agxObPJfdb+x75VVaa+O+IvYSeq3Spq3Pc6OiR7j/CJgi+nrG6YGlUlN4ncL5o9hL T6Lydt15XDb+Pu91042pntVI4abzlXai4YjZyw63+OX9y8TL5bpyL/DvtK48HHllejDgpppVTYGd gJTsZirOV533sNXAJpP3ZriqXDTsphM9/nJ3Wtk5dJzkg2rp+wrvW4/XRT44WLRzuLimuPCe6ltD /PAR9xODv1rI44TJRcEd3X3VeqIcufsLkMYpjdq2/OJ5Ar0hFr9kjD3vkG4YFIB6fXLwhxjeOrNA Nq96M3xMdEd3FtW8wW9xJKFR4GDuu/WxISBMsE1Jp2OfocVHDI1LOMnhIvS4AebYqzzBj5c0n2IU 5JrKujWkT/1VVvpanFZXkG3/vsQD9+sc/P/5QP6b4D8iAft/E47BolFwDG8I5H8AnrqvawplbmRz dHJlYW0KZW5kb2JqCjU0IDAgb2JqCjw8Ci9UeXBlL0ZvbnREZXNjcmlwdG9yCi9DYXBIZWlnaHQg ODUwCi9Bc2NlbnQgODUwCi9EZXNjZW50IC0yMDAKL0ZvbnRCQm94Wy0xNSAtOTUxIDEyNTIgNzgy XQovRm9udE5hbWUvQlJHUUZNK0NNU1k3Ci9JdGFsaWNBbmdsZSAtMTQuMDM1Ci9TdGVtViA5Mwov Rm9udEZpbGUgNTMgMCBSCi9GbGFncyA2OAo+PgplbmRvYmoKNTMgMCBvYmoKPDwKL0ZpbHRlclsv RmxhdGVEZWNvZGVdCi9MZW5ndGgxIDkwNAovTGVuZ3RoMiAxNDQ5Ci9MZW5ndGgzIDUzMwovTGVu Z3RoIDIxMDcKPj4Kc3RyZWFtCnja7VV7OFTrHpa21MiUW261fbK12ZiZNYxBKLcRNW4lRaoxs7Ay s5bm4pItjuzQLpKSojqUu6YOuUWxCal2lOR+KaVc0mXb1LQ3Z2F3Oqd9/jnP+e88Z61/1u993+/3 vev9fc/z6Wq7bTWy4WB+MANDhUYQCbIAdsytO+kAIlEIurp2fJglRDDUniWELQBkbg4BG1EAgGiA QregQhY0KoGgC+yw4HA+EhAoBHp2+nMqOrDhwXyEzUIBkyUMhHl4EzaLC7ZibAQWhpMAsOFygcfc EgHwgAUwPwTmkAgECAIchC0EfnAAghLIc56cUH8M0Bdgjij4ExUC8wW4L6CH+9QHuEsOhnLDAQf2 J5BdMHw3GPfyH9v6N66+bM4QcbkuLN5c+7mc/kSzeAg3/A8BxgsWCWE+YGIcmI9+KfWCF7wxYQ4i 4n3JOglZXIRtgwZwYWAEmZAoxrQFAhEwkDCY44YI2YHAn8UVwPM4jHK+tIKnN2+EbOvh6M5gGiwM doF0YyGocFt4MAwon9XzNfS5xkPiI2HAh0KiUCBciL+fvny/2MwBZWMcBA0AVJopYPH5rHACBW9F pdFABAQQlAOHATgMd0wmoZgQXwLwaCKBP8YnzE0VMoUAmYegIsEc/gdEBeRgfFwYhw2jeIww5584 Y1wu4gqRYNzAZ9QEkFkCXIoIgvDZBv6DMcbluCksdOE4fIJNzPAd+Age0SeEbg7IrvPVn7O0tcXC Iozwo29kToMARKVRAd2MGvmvQk8U2S+CnewBjUKhmEH0eZQt4vPxX5g/w/icPtX+CD5bGA6D2YT0 DBVk0R7DNQa/7p2sbV/rdf32/a6rZ7/1LobUXVpiUjxkYjCX07737zcZGP6SGX/mXr9WF6313F/W L+M2VlgOuOpU5shf0zoTUmRMZTcv7X39840tsdKvpC6iwjg2c+mFR96TF49sv2RjuF7uimRsf8Sb /gsfD8TurXH0DlC72mTppeDQuu4UP2SrDCXr4+vG29PW6Uhk72L3EJrUU0umKjEv66HoslyQzrIo aUm0pRbjQ9HKGaLH93aaCn+rzCbGbUq9l6M6Y627c29sUL36ncDKSsolX98V9UE0QxO7Qiw0peSY YVTlrWWF4dGj7bsvJAUdapKKfyDhRa1V7k7QeyaXauz8kP+gtOeckmd2ePG+Y0Xab7SHUjo66fm+ Y8dGSJ1qeRVyaRMZfUcsvS5HouV5ZLvRnHEP4utcCklE7N3stCe4KuubLDXSOP1tZkNvIjhNkVWR pnfn1Cx+lBYTEDoxNnhceWxGJk/wtYbt6t/crRwfC4a6mNF7fJcEzmbBg6mGpbnezildFWFnhodr xzNn1zlb1se/SvmRa0SKsNkoYbPVr7QvdiOLJIetPmgqnq9r3B2i4ubk62eYWCg78cq9QPL6wpXY Ylb2aNnhr1rNdYesToTsGHKN6NeTZycQBxqllBg3h9tAi++pyK/uMaXbxYvS5eWyiafGYTO9RFsT j9w7HbV9kOaKPosLJ8tcd1GxK553pNyUzMXVuRYRDTKynKSU6zyVCmMfKFCJHt2658b7tt6jpvo+ 5RoPezJGA5zfjEx1m8mTDnRFC8KnF4ktOk+uU92yqXyWV+Q5GCSHrWbvyA1W3KzQrTL2Mrb31YyO X0etbqUfy1nM2ne2s0fv+L70mL3KhlYG1WnjQ1MfTd8+NODpf9dYTnocPmbNrD9KH1bbbbCcIWke brmaPPBO9HWIykikIIOq9XxN344nhwYqylYWH+93sHQs2ZjaFVXt3/7Li0XvBfnfNJ5anlreNNtp OqqTdMB0da5LsWKxjV/GekmYr4uJ09UOlaDC0WBsaZn0yfhvK3XYVWvv9Ric3Vt5+vdVDeJ83z1x uofr9hVEUsce11rfVc8ffrKB/0PyNZnm+IaJkrNPoo3FJbO33n58v8b6dL7Wms2Vm3zOnFhX1bys VDd5LP5En1qz+e48qTY9jVqtIvn+HVH9ik8WmedFn1CPGdVzEGP24hhZpcMrO7dkZocF0Q6+vIvG xUwnQqWMXd+jhCViQqHeu6oI7v5H5Te37VpiAaX8cC/sO/WfmAP5TStsFbubHAxkh5WeeQx2C8s9 tzdGaYjv9tDOltD60A3MYuOVAjlaZ8Rln5+8Ntnv1DzmY1YfJN7y6x1e4tscePx+3QqOdNJOxQee L8qfevZpcAoeGQ/JkSiNkdOpg41SDYnpKas1XI+LHzmf31L70tb1nLVVKT19M+Z3l1nQ2rukwma6 b039e4lN5MjiIzWitvHeMrU8gb8EGZCu3zh7MCbYT4bcENjRr7B2V8mp9GMtE2UWRedveNY1q28z JbYZdho7rtdwJyoNRYPbRml+M7dM25SaDme9Uzd7YDhkkBBeFPd7vaVcKEUSMBDXMDV1tDChTwZz ePyC9eLIxENyZFauUcfRm5mKhFiZHxn69Z4uphJGAXDKmFmRkajaHqpP8Gxt0/MCmtutkiuqSjfE 3SIespe6bPLXrDD7lgAF+2tPYwaNvFdaucloNm37bVw1+1nxKu0b6YU7zD/61KBT76cKuCPPT14c 1mwz0dPWVnW8/vSDW7zU8jpHCGrhJTU21K3G1s4mSz9NVp6cdg9dtWu/FTuitNV7UvZgydKcGXTy YmjapFSzYYJs9M/Pb8RYqaN8aRNRpE6VQnnUeUJSyVDiE+/i0ufVWiUvquXdLmGZaS7biQ0CP1lJ osmdjVdGNm5ur+kRRlVj2TXKDNn4uwdlPBXZL0tnGtJuX97dK5/AAMoD+8vw6++/ewj/b/A/0YDN hVl8IcZj8YMIhL8DlFFXYQplbmRzdHJlYW0KZW5kb2JqCjU3IDAgb2JqCjw8Ci9UeXBlL0ZvbnRE ZXNjcmlwdG9yCi9DYXBIZWlnaHQgODUwCi9Bc2NlbnQgODUwCi9EZXNjZW50IC0yMDAKL0ZvbnRC Qm94WzM3IC0yNTAgMTM0OSA3NTBdCi9Gb250TmFtZS9JRVpEUU0rQ01NSTUKL0l0YWxpY0FuZ2xl IC0xNC4wNAovU3RlbVYgOTAKL0ZvbnRGaWxlIDU2IDAgUgovRmxhZ3MgNjgKPj4KZW5kb2JqCjU2 IDAgb2JqCjw8Ci9GaWx0ZXJbL0ZsYXRlRGVjb2RlXQovTGVuZ3RoMSA3NzAKL0xlbmd0aDIgMTMy OQovTGVuZ3RoMyA1MzMKL0xlbmd0aCAxOTA1Cj4+CnN0cmVhbQp42u2SezzU6R7HNyH9RBKdJDzu g5gZjDFTcdxjyUSdEbWMmd+MX83MjzGjGZdcshaxIuHUSy4h93ux1m1Xpcil1aYlClm57faK1hbq DE6vfR17/jmv8995nd/zz/N8v5/n87yfz/PT1aR4GtswUH/YEeXyjfEmeDKwc3NzJgDxFIeDdHXt eDCNj6BcexofJgM8iWQBbAQsgDMFOEuyKZ6Mx0GQLrBDA0U8hBXABxg7gzUVEdhwYB5Cp3GBG40f AHPEJnQaG3iidATmi0wAsGGzgcfalmDgAQfDvBCYYQJBeDxgIHQ+8IdZCBfCrlE5c5koIG6UGYLA T60QmBcs5gKYdVIDIOZkoFy2CDBgJoQ9iorPg8U0/zHYv+HabO4oYLOP0jhr9mtZ/alN4yBs0T8F KCdQwId5wA1lwDzuZikV3mBzgxmIgLO568ynsRG6DZfFhoEx3twEZ75RR4IdESHMoCB8egBg0tjB 8Hod5jI2k4jjW+fAOjt42x9zM9p4240mhYZw+cdFgTDA/aFeX+P/WIsz4iFC4IMzweHwYqF4fJqd 3nSYA5eOMhAuC5gSLACNx6OJIJzYypRAAGF4gHAZsBDAQjEx1oSL8sVbgDiZCMBEedDas5IsAdZ/ rQT9+Q62tqgwzIwIjE0JYkszcxIgEnAR/6o7wUWCBLCzPSDgLIlmlht3ogt4PJjLX/93xPF8WjMR caIwLITpUJS5KKaMZPsT7gVyU07uCF5dV8v8x7/YjCXXFX2d+EjC1mAyOlRhKuNm8oHIcA1KhupV aqmfa06MWpt32hWVsHtMPCs54sB5jRTNY707DH7tddSXClzE7T9doWoZ72Q6ebhC6nnHWQl5HrtQ sKQhWfam/rqGGsdQpuAcnFRSkLI/qVfJEgvZArVJLkbzFyP51OK9NQ2eTxXmdDBDk8oHmVXMdFsV oNPaxyen+DMKE2XJxdrHIGfqo6a6sUY8wQITb0XCOqcxgoolNIaP0MOqoOYFRcmaWqXFpL8vuiwJ tbWRQV6lu3OrZ16bl5NTm8E37p5yJwtbPQMbR6RTJww1m7LlTh5Y+JZSctWqZ++TO7tc6/vm7mRK DV0anK+RJ2PezRZcdsrNxv9yP+NN/tcZ237Ktk11mdlz/NSeMYuW/gbfl3G0cdfQ69e0ySEC1xAZ rf7iJOoXMpVW1jJqYctRc65by3MvwssM/pLGg1PhOv5vZonHf3b6Pj0Lk3JgXnYgv7mwAxtVpFHE ijImsssH3MbeUY1VydXZKEGfMuwSkhKXYVnMp8ZfLZT4UlK/Xl4x/W6T2c81AtPaRwd9KVPKMe8O l2qrx50U8vJLAhRDl3da6IaG9KrXHmW7G6yMl/7mib3V9zx2aOtrssM3yiCHNZDVeWfpRrU/kaJ7 6asC4bOi2NrrxQ1vgV/TNMkOmd8/d8/h0e6HN84ZJnewOalnT30BO7hCexPNSL4DQ6wKCD9SdibW fCTqdYt8Xn6RyVwH/ulFK4srHkN5dwUlKa/sLhyP07vtM/W9y9QsTTlHKYvX9zR8ib0vXPlUUFyn n7xXN62xe8fpmSy9RNI0pg29S/py5ibdCPPd7OGYlwMftDy0F/U4RjSnCfvSHx7Hu1yWKX0m3FJV JH0hQXdiUn6qdMl6u2zlyupR84YrPWlPD6W7pRak78Q+ODGoP+MziO6Iotboac7NbneqLhxRGO6+ a0AdyUyOqO5MZ0Krj6cd6wZXVIu2b1u2Fpwpk5Run2qezNdOqRsz2TbefnMRnv6MyjAOtDevlKW2 ON6fSS0zJHerKJv42inzwqeVco9glROVHrT4VAe94Jy8t6hjv6Xi2mgkad9n14nvlVJkxw9ejivV 2T0haEne428N24hC7z+ejjUEOLNQTN4ZpcAPmbr3DfyI9u97H16Qfbfio/qtf+PI6xWK9r6uac9y rV3yZsymN15JKs6doHhgoOsWCA1Ku3ZIpT2daK2mGRCNC/ZFF2t3L6q7K+f3YMt7t3QnFohYtFuD M624aR0z02bTrScICztrRz8mzDv06uY3lOy8prk7pvTks4nEPdJnVpmYNpNEjVnVh5QQqVX5ymrp 1d9rlOlxrfRBo5wn7YM1Lbc7D1ffoP01PWv0fbqegpfC3144YMvqjX50rVGPDU6Sc4fdNKOEu149 my9xl9AJE0XaN/u1J1hGtkSMNOuVZ4NsiF02Fvv54yh+h4+j/Q9N0cvAsLv2baOfn17Cr33nqxgW NaPRvv4yZpDUpAcYCtVXOn+oRXLIGc9Ouyn9Urv9t0ZP/FMrlZ6uM+XFw9ld8amYOyny5WbDAQvR 3h9WuoY9xokqs4q5hh87HiMB0c8/FDXt3aZXcVbW7kmCf//ulxfVPiJP6qocWzJf39aOFowvEOrO C0YDmr3h/q/envuOTvUzwh1UdNLTTxvVT3lFCHq0Ranf23r0tKycE7rjVGhuzucjeVKRrIwGheg4 r+GPIke/YqinK/T3XVrvDTNfoKlJlw5RpBIVOoM8g7Fu9d64//KD/m/wP2FAZ8M0Hh/l0HhnIegf sOfZzAplbmRzdHJlYW0KZW5kb2JqCjYwIDAgb2JqCjw8Ci9UeXBlL0ZvbnREZXNjcmlwdG9yCi9D YXBIZWlnaHQgODUwCi9Bc2NlbnQgODUwCi9EZXNjZW50IC0yMDAKL0ZvbnRCQm94Wy0zMSAtMTMg MTA0NiA5MDJdCi9Gb250TmFtZS9QUUdWWlorZHNyb20xMAovSXRhbGljQW5nbGUgMAovU3RlbVYg ODAKL0ZvbnRGaWxlIDU5IDAgUgovRmxhZ3MgNAo+PgplbmRvYmoKNTkgMCBvYmoKPDwKL0ZpbHRl clsvRmxhdGVEZWNvZGVdCi9MZW5ndGgxIDcyNgovTGVuZ3RoMiA3ODAKL0xlbmd0aDMgNTMyCi9M ZW5ndGggMTMyMAo+PgpzdHJlYW0KeNrtUmtQE1cUri2DNhUKSAWmY7mKKAwk2QQSBnxFwCAOCCJC iVJZNjdhS7IbNpsmMQHEUhFBEW0dGJ6iM1YrIK9iBlsVQRQoZRQQVIQ6lSL4KFUEUbQJj5mWdvqn /zq999f5zne/851zrvPS0K3M9WIyFgpJgmZyWIgPECspUs5BAIIYQ4TD4HgAMY7RIBZKcYLBNhED CQkJOPxpXKxSzOY+g5QSJwngMvPWFVAQFZOETAvEUMJgbyZpHIPAJQASkEJpKAYSYy0QDGnUJAti cVqOGtW0QBFPUygG3UEcTSt82Gy1Ws3ClCyVikXI2ElxKKGGBHuGxAZz6whVMtlmVG6sNNPMXwio HJdp/5ESCXFpHA1cwqBUJUOpuelAGpXh2HpCKoMAmYZwpRDXQHEoTmNxQILKlHAa30aIISXDCRhK KnHaNB8mB0Hm5MLjcCyegEol4E2nICGea9o4oinL7NAtAREikdvspmal8AQVDPSftWOih2sVEHCm 41AUnwGmCGCaEYzSFK4B2xHTvhCjran7hyD6b1z4+pIaoGN6cIydeAAO4skH3gg3cQ5zA4GRYpyQ AsDl8QFKUaiWgRjdcHk8oOMA3Ni6BkCNcVhsFkHSJk8KFZ0IJCTFMH0qLwSwhSaI8SddTEVRkKCn /p5xSLOxBDduAkINxBg9XSS2KvXTnLxc+qxd0ZVW/4/rggyF/AUKd80eJ+np8UNRKbV++VW183uL L47lPmtc0r82MnPMTNdy4nnjipNtrt2G/QFb7aN5P52bXPvYcr/D0fDfBJ0ivrLQ2SDo46wZt1QH 13MfaluEo8plZo7sUpud6g0/uiy5el/ae8Tx58xo/WLzaNsR4tr1ZxdygB3V471Pe7LGZd7rwsZV 3hNJetb3S89nHk3tsv2B2LUpolt6u2Og1cuhOyFlcVDim4l+70PBY7ud+jfm3OXy7wz08cN2DT+J cTR/tOnUt7kbXqWuudYrDLGrfjv/C9dYv8duY8nvvjNB+6xO51GB1xG1+wmrcw/a7+cm4RGYvnr3 rzfHJfG7Gu6ldF+rrZx8KLrttScBJud7NDostd6eVZF1K1JxxpI2lH0damGbbVEiFfOru+puBPKK Ky3sx8PcCnYsK4v8wNrm0pDGOfz57r03zFPrc5bbPYrKcPfLyEl6SAx99zQm5tG8SQfRlqyG0WzP rK6gg8NC0TH9AbvWg6Wxe0baiSc327lD6ftS1i2sENRMVgW4TmS/eN138YGZtd4y/fR4c4+ZnytS 5za41YvTdHlb4Re50pwFl4IfvE/n+iRavSqKUkRd7pp46dnhawUwxsgLd6f17VaLnPPsL41kjAWP flKknr+y6e7hpyV7Ezmb2r6qSQiaJ5TrmuOb7wr53fsGb57hd35j3qt4b2hg0P4tQVla3j3VymOr x8o70xJb+ZOCErmNAXkSzm5q0HmsO97csrbnbHOyoJg5mdOxYFEBU318uLwfJhx5rj4SUh4Ska+7 /qzMiXF257psV0ZlW/qOuvmqrtjO3kEqI8xhNECfX1vdR42uLLmT9tHh9leZPUE9peewAuaVOLjw 6S96G8OHVY7qkMwKRX7Dl/XairyymmVXi156ERbFJ9/Un+KObeuoOD+4HPZ93jTpmZdxR+QLFRcm Nur35ltt5Dk7E7dyZb3lLVfTrCujqjiIMyu1LYY5kKwzyBMKWQUrGoaxygMHUwXVRbZkKfu29RqR v79FlxD5l4fxv8B/QgCTQZSiSTlKxTN+B/Ug4fwKZW5kc3RyZWFtCmVuZG9iago2MyAwIG9iago8 PAovVHlwZS9Gb250RGVzY3JpcHRvcgovQ2FwSGVpZ2h0IDg1MAovQXNjZW50IDg1MAovRGVzY2Vu dCAtMjAwCi9Gb250QkJveFstMzQxIC0yNTAgMTMwNCA5NjVdCi9Gb250TmFtZS9aWkhFTkErQ01S NQovSXRhbGljQW5nbGUgMAovU3RlbVYgODkKL0ZvbnRGaWxlIDYyIDAgUgovRmxhZ3MgNAo+Pgpl bmRvYmoKNjIgMCBvYmoKPDwKL0ZpbHRlclsvRmxhdGVEZWNvZGVdCi9MZW5ndGgxIDgwMQovTGVu Z3RoMiAxNTY0Ci9MZW5ndGgzIDUzMwovTGVuZ3RoIDIxNTUKPj4Kc3RyZWFtCnja7VJ7OFTrHs5U ZEi5HlRaasY1c2Nyr4yhKBqXtltozKxhMTOr5uISgynlFpJ6ItRux9Yml8pt2JFLJVGScitFO9ut nUimbXadwWmf57TPP+c5/53nrLX++H7v+/ve37ve70PrUjxM7OhwEOgIs3kmeAzeCrB3cScCeAwO R0Ki0fYckMqDYDaZygOtALylJQFwBIOkC+lnRSRa4QhIJBqwhw9HcaDgEB5gYG+42GUO2LFADkSj sgEXKi8EZElFaFQm4AHTIJAXhQEAOyYTcF/cwgXcQS7ICQfpGCQSjwfoEI0HBIHBEBuJXTTlxGbA gPkyTOcf/kqFgxyu1BdgsOTUEJD6pMNsZhRABxlIrCssnQdK3fzHxv6Nr2/FHflMpiuVtSgvjeov LJUFMaP+wcOsw3weyAFcYDrIYX/b6gUuW3MB6RCf9S3rxKMyIZodO5gJArhlCOI6QpEgnQLxaCEA g8rkgks4yKZ/a0Ia3JIFrK/vHgdXO+OlQ13mKFSIzfOMOvyn6mLzUo3/Zy0NhwNFAn44abp4aaP0 /bry/2aWA5sG0yF2MEAgbgeoHA41ComTShGIRCAaD0BsOhgJgJFSw1gMG+ZJtwDSTAQAA+YgF8/T zALAHgU58CK6DFgCWJgN/llLVbHLQS0if/1PEgmOjDYxNcMDJgSidLIpzgyw3E4U/GvnATZ0hA86 kQEiDoczt7BYQml8Dgdk85buljTErzUDkkYOgpEgDRnv4eZiMGUwoIHTCCzRMzj2RFKUJDxmc8D8 M9N2IP1N7fnhmAr9uXs7B6vCkDFoCVGlKnBs9trCl444ZwuTYzkdGU8ENhNOA7fazyQcnf5OYZfr vLJZxWx/jpkkX8H1EKAselT7XfPOcxk2vtgGJbG3YLMXLzGP4OomuWGQVLMfpU7p3aUjOt0zW1RO c8smbTne3lTdSWYNPuhXH8z9kpTgGrkvbN4ie2W/g4KiLj9UhivrEBMb1NQNzcreMkOMMIYk1gGC lDSs3/Rn1otdXdzMl/tLnQ9pPh+5YJwBGRvOIKxilBhD6X0H1d6LnXSDiXFuRWP77vRj1v3mfERo i13QI1P0xLm7E93YndqSSPEtrXGdvI6ziLEWFsqp6csJZMpHZbC45XOWKuGFwQhVtGH128cZ5AmB 99XZwLGErGrn0rDfW75XDVKXYPddHd90+I6MErxLdfSZNfnjworywd7OyoA71/u5sMNDSYoMqlY9 O2ayb0PDWvLQoEnAbNTWm0/dSqovP5QUncy412ih9k4QHaY9OgY9iCg2fN2voFLxfOfHqbM+W6qS cxuxKuP6+D0szPutiu6p4t5XZfKl4YQryQwf2pDT43e24M97djh7RZ+JObsuQEUZqnP/6MU8EbUj sDfOm9aa9MZv6A//VLRa1AHT4vomTJybkBmrlvC+1a74AqPweYR6elQn40x3jigg3vtmQIQ2xOmu mtz4rLs+/bj/dm32NcXT92XLLnfyW+2MVC2fq1l+2uGTyVVuBMr3G7fVFxYEwfyZlN09PgfNP8jk f4jvt/Dhq2eSqOlbxunTWn1CtK4SZmYTWDe3olSMMIxG/Vb/YdyGepS680RYV0/g8NGz8dlKYkvK rdrJmTVt5yZbi1SxcmBN0wVTTL34yv0SUNaKNJz3U4/tlO2vJQVhF/xRC1nP1G9f5oTWvN5onl4S ob7G28Mvc7tRxYgoZGj4jlXhjftbU2Rk2h5VqHK7Mty3XiIYmx3pDClV66zDPCu0UNvbfnce52E6 38ReqZVAnraw2iwujkSlsWQJQo3u8Y0q6xLQF9+aNmTZe/QjjOYWCpyMmpr3Hzi4fnWwIKt0eLfo J7gio6uZ0VaUXOnZl3SaktCmV6azTmiiNlGdnL/zR/5mdAu1dJuhSFT65Prdj+35/q6XVoquk3Hx zv5NIa33U/ONNDlwoodpjbVw+gbCZVZ+XXmz4S3ReSMtpkMjwWNH8AlEhBXecpRDF8drD69lxjhg GfxALtjZgfR7cG0v5sdd8LgRnZ5rV2RIT6vSjU3QrHzcpXyVXFCop3gKJVhbRrH+0L2n7W2oYJ7u md/w6rFcwLtTHiBNtrVlujDv0QfJgsjsdli04lgGyYrp5dvjUqZnYM3I0pBrJ18cCu82+GQkmj+p 7xRHeEV3nn+FN0nRKgotUspuCHsaa7LqpgXL4bz8+nO62iTiozKzqS5arWxVzYovcYP+YXsvrk4F eFd0cpIQUJluxYp367cLekkDWa0aKyn3EhxmZ+q7nTGnjg9WVaIsjwfsrWuMb88izbmb9ZkUOd5V R0vIaNvmtPByOlwXYeNJ8I460mKgvyn+/YxL2WWvScP+9ZdaXzcrWL0M99RHq4TY/0LzjAc++Tw4 QrXV0Lgb2tEIIGPKgrhf7ADehR5Fux2JJ/M+vbmNQJ0s7ZI9UBZH8kJP3XDxws8Ha2aJFcNJj865 u41MDnrghHNy84zc6qteIWSEnLKNUsYf20oK40kIc801V7dsqguXE8Sm1f6W0D1ZEDxsuCFxytd1 MDWg23p8PKk0T94h+eFTSClZZmZiVsFz7vSh2OA5UqX9hCh5H6Vy1Qm9VfVDR5kztoSkQZ9fzaBt aTflb+b6FQtDJhiNKIJG6QBpgJ1+rG1h1H/DwkDMK51orPhQ34uL2Sgbhds/iyP/5rtxnnLtipjS 2JCh807+5UCOa/n97JJT9ih9X7/MpMFcyVai9Uqtuu6aGfGlzFSdQnPN4s26jk+Lq0WqiQVyWMRx Ru8Iok6OTPE62fI7jc5qzFEbCPrUEeo4/Dbp+8kfDIVen3dvGe1wTBTeO9238Qfj6f7Oaw9BXYVf 1j4L6qsYzcP9lw/y/wL/EwI0Jkjl8GAWlROGRP4dWPRqPwplbmRzdHJlYW0KZW5kb2JqCjY2IDAg b2JqCjw8Ci9UeXBlL0ZvbnREZXNjcmlwdG9yCi9DYXBIZWlnaHQgODUwCi9Bc2NlbnQgODUwCi9E ZXNjZW50IC0yMDAKL0ZvbnRCQm94Wy0xNjMgLTI1MCAxMTQ2IDk2OV0KL0ZvbnROYW1lL1BYU0Ra TitDTVRJMTAKL0l0YWxpY0FuZ2xlIC0xNC4wNAovU3RlbVYgNjgKL0ZvbnRGaWxlIDY1IDAgUgov RmxhZ3MgNjgKPj4KZW5kb2JqCjY1IDAgb2JqCjw8Ci9GaWx0ZXJbL0ZsYXRlRGVjb2RlXQovTGVu Z3RoMSAxNDk0Ci9MZW5ndGgyIDExMzE3Ci9MZW5ndGgzIDUzMwovTGVuZ3RoIDEyMjIzCj4+CnN0 cmVhbQp42u22VVRdzbaoiwd3CRKYuENwd3d3lwlM3N0lQHDX4O4anOAa3N3dg0vgsv6990rOOvfl tvt22pljPoyvV1XvX+tVY7RBTqyoQi9kamcMFLezdaZnYmDiBojIqUoxfQYwMXz+LAxPTi7iCDRy BtnZiho5A7kBTFxczABxoPH7zfufm42dm4kdHp4cIGJn7+EIMrdwBlCJUP9rFgdAyAboCDIxsgXI GTlbAG3ek5gYWQNU7ExAQGcPBgBAyNoaoPyvJU4AZaAT0NEVaMoAD8/EBDAFmTgDjIHmIFt4xn9p Sdma2QE4/its6mL/P0OuQEendy8A1T+m1IB3T1M7W2sPgCnQDJ5R3u69HvDd5v+z2P+L138mF3ex tpY3svlX+n+a9b+NG9mArD3+e4adjb2LM9ARIGdnCnS0/c+pGsD/kpMDmoJcbP5zVMrZyBpkImRr bg0E0DOxMnxm/a84yEkc5A40VQQ5m1gAzIysnYD/xIG2pv9p8t6/fzwYFTVVRLXlaf97d/9rVNEI ZOus6mEPBHz+M/0fZvrD711yBLkDdD6/t5npfeL79T93ev9RTczWxM4UZGsOYGZjBxg5Ohp5wL8f pHdiA3gxAUC2pkB3AND9XZmRwdbO+X0J4L01PgAzO0f4f20sEwcrgNHsn+B/M9s7g/7NLFwARgcX u/dm/tOz/wmzvq8ysbOxMfoTeV9n4WFvAbT9E2IHMNq/L7Qz/RN6T2dnC/w3s30GMDq72f1hln9V d/1rwnshp/dW/JvfcwL/FxV2DgCjyL+J4z2h+B96Tyf1h97Xyv6h93Vyf4gTwCj/h941Ff5NnO85 Ff/Qe06VP/Tup/qH3pug9ofeK2j8ofcKmv+m92eC8U/zuN7HjP/Qe3WTPzvy+b286V/I9N6Bv5D5 vWN/4bud+V/4rmfxF777gf7Cdwmrv/DdwvovfNew+YPvJ5jR9i9817D7C9817P/Cdw2Hv/Bdw/Ev fNdw+gvf98X5L3y3cvkL361c/8J3K7c/yPxu5f4Xvlt5/IP/+zMpLGzn7kXPxM4CoGd+P3fvUuwA LnYun/91ppotyMEFKCX6fjQ/f+Zk5vwnauLi6Ai0df7ndfj+wP8Pm4He3xFAoDvQBN5fRUmO6pRq GfsztkE5BVXgzNs0JEWiFyrQNEOFv/Fop+Rr6Guqx8ei0CQEijuJ+c2IK7lU/qnZkhFC+pKlkEdR hhbs2+9nMCkV3ixbO5Y8N4YzsrsG2EyhqCmjUFfRnOGyNxVYnCe4khho0wo7nV7HBflOyBGSTK9a 80vjDOJoVsaZXnmP4/yjeTc83caFOW4j+FSBBTS/x3tvmnT0TDbbo/WGlTVcbaILzCszW2+89lE8 XPx/nlkE1xfF2A8TKWz4/wY7i+M6uPFf5XatdqzMEBEKdULYqHqV/bE3eDZSTRYP9dv+M1oCgzYv Zad4hE85aDk3qu07i3bz2u+BD8kE3hCalCZPMN9E1Hly3aAg0sQmhF9qM+8jlTaQ+xaVYG1Euss5 D4EX7F8M3rhhawjaa+xbJRPuJekHA9In+Vh8lZF9Ihd5mis83+SuzZVurmjKjmltHA270imOQoeh wPg/kPq095XsHurOkGcLzozc6jrTtQlWItVCyQIKrkiKBLwCPiXqPIHMiMPH5WATTaePl+7ODBsD aoQw52b1UzopC13ZsOQzgk1/5Wx8XA7Rb8SPMZ2BlkFgCDYmgtD+4Dpld9YSVsBHb9pLabGGapWt ine4/7WrzSlty05OJse5DoseXj5D54X4R84c03YAcO/jW5fqmvzkgvzIh2+Ag2R7oez4TZ7R19Nr NTkzrOS7X1noOLBQU9rkSHF+r54RtjGFnyUIl7wKTQM004EjGEZx1Ffblm/7PYyInKookTu+z7ZZ GYaNeNqZDWIKC4OPjIyJHFjJoeVaKGwt4oWiccVOmfGgzatnyVrqAILAs3ocgg4l6FdgLMh55atP KaOCyKqfFTsoANPmyzQ7Rk591DejuJXsY3DHo8BRgn5kTkbQMj6HN/6RoF9YXrFRox1XsHmOxrXe xy6CXrdNmI904YRDEI7bDNy6DqRjlKdjQ07xpb/veBpQIJpMM19ULhJ4gR+dZZsz22Y5gpBva+ci wL57td8I23TvX2jyIEjPVHU4Ewpc3lNXURJBAnBrDyj8RX4T6+zFPk6QLWOWomAHVY+WgFlf6Kkz 90gSteMvksiHK6+3eYsl53HsKWp3i3yEUx8hMuQ/tR9ryOcnkM11lodNRDxw3xZPCKbezAq+XUKh IqFkAHnSyvczDMiZx0jNlWN4o2qLe3kr1DWmNauYUyRox2IaCNswQtBXqqTppBGmOMtC+OUIe0+h eW6LKwkyXz+X3b1mSNlY0g79aLIXnLYtExGHew3vfnvh8w9oNmMLbE6Io/X2Vt9z4SNdZbzQ5b7I SaO+l4DvWE07femTTVRXBs/N+PryZp3aMeRr6QH26H8MBvg9WNme8pamEeGfxrzilWHpzkxCpZZT +MUp6pHNb+YVqzn+Y8eR4KpbME3USgobe3lAj6t01eskafFlPhxKfeTiHN5BkQrYxGYEm/MA8She dvTKg0wNa37a3Q2pg0PPTFSp+Yft5brQS/KSOURcGmOwQYeNLI+LCcgjOuTGfcvcmZxqIkH3b1lD 5Cx2NW+tIu2b12HbmCENzEftIZXqQtwX3H2xbBP9M3itIC9FlZD1rhk71+DsfkV0IwvA7vRp96Y2 dmkwZ6mZsonoapvfXL4awx1e7SiA0ly6XEvQedVLbsM7QI265XSDK1dyUS0RCd6wbPG+YBQ/EhPi x0M5fzcSbITNcKMvlHfT1nczsVSbgWEnO3vPCayi0E3piNmA8IIELrFnN2VGPLlfhaYev+VznV0d NpnFYlunXU1WmSv34k41coVkMJg7+VfV53dUJxK7FxJKOzdNrUF9mGcksQZCvE9Oj9T4OZPtp0lW KFgv1E9eij2IP3Zgsr+IZE+LiSt3EX/kYwGeNOeb0LN8DZmm/ZE2u235cHu0MWs6PEH2rJV3Oxm5 DwK4BgcpwUhhU5UHCrDo80FqXRzz0dZnQW9qnP7+wRgEVYMY2bh8vaTjuHf/kMHTFr9rJliVnU6Y iaDFpdTTN1wYabGKZqqLUk7Nw8MQPuE+4yJ2AbvCGSrGWfbFynHkEIzfEsYrI2b4gVX92GvJ23oC /BP4WWCRvdrvSk2xV6wmtp3SBOvhk5pGGNWJHSrut7qfN5gdHmWU9rxrha88+9SQWOzBhvtpuQBx DcZLdCca+TH3qZ+WosroJFynvjS0A7PCHkj36vasX3jmlTUmiBlCAwmh1V6+NyznbN967kDReIkz 36gnpHHDXhJotnCCLKmFkks31GhaSdxxE2WDx+DN5Ou03ON2Gug+D/rLkUW/Cv7IK7O8wvhqY8Iz escsx9o7w/E0Bk8Jpk67mY67lUFQXKUllIPWSXoF4YwwoMd1ybwYJRDj8ZptjF9PqbyU1aaGZdr8 3BDm8HJ/vqtynKyLzf5Iz49dTmzSgIcLFTokdSiesj/NfoRPmc9yidayKp1KVUNBUY0v5CHYsa5p wnIEw2x2uvhwHT1NcMP28fTep7h9mAsZmm8tW5C8jXqn/CucAxaEPQ+6iTQaJ5ZBFRNLcgRfMcVr POrMh1+GOTcrMDm4JpNilrYI5WPpy+oIse5nUuARsycqcA6fEayFf6L2VZ2dgnS31zNGVb2JdHjv PT08rX0ZipMS5t0raWTQFK/cvFLeupjRGMKuKhnu3hAe0qdKW2x5YbmfYeKvdBKRP5+IwbKqMx3K jsifWScJPlKigX7HZv4aq0Mz5L5sJh/2cOQY+tpz4C4XTHoavJ8YSGMI4R/f51BDHFQdThDf0V9b QPStFpKx8O4CACYuPDygrmzivq4CK5SmeCHtIhOIFEaJIlQG5NI8uy4gSN2xzqApDwt0A2MgQkLI 3l9R1W4P8p2kDbYfJ3Z5CIZz624qtQuNOO01gUcj28DN4IpVefYp/JlEaPRDK96U3jkxhaz9qChP xUpSrIYLpEXzyD54F+cVgn922QxChGrjKMwqpTeLXscgHTAHVsdYi06RiJ6vFa4NqiE3ZV8Etc0y oxbGdTahsP28GJXw4/Gos5BhcRITxdvt49EXDHO9AR93ptiQpbYVDT5S+7Z3lBKkgOK0fDG8SyLj 3jiAT1dOv2MW5Mpk9iGYlKPFsAM8rZIS5nBo/ydmkP+jg1lzQOpxu19z+MgC2yXTEEW4hve1Ea7i vauCExhV7KeWI1Q25lAshIQzpSYSOCi5c3m4JZ66ocWiFQZMlPrafluio9cn0UBNcesLyYOJHdMf zNOHHiTFpwssxNVwoUWkh5e6fA+t2zxPDuVU622Kk7gyR/rUw83qvoKPk7aMmVsEwchfIU7Vf8kn 4CSjDGHP1XusBML2HocsG6fl1L+pG0K/Wqlv4bNrGDW4yyi7ZVyc6tY2oAorprraU1TDsfYzLxQK 3i3C8oR8JH2UYV0idfgsKMJguwvO6MknbPEpEGzMohpUSgV/G97ithVZHE9H1nXt/lOeqgYykme8 LRfbz2PXiPOStmRoi3oWv3fztxWuVCv2N3Ij7RNOtVwt1Mo66m0ERtL48pBTMilhQVnqCwSigAHC 101N9kH6AXDlWzobettToWrmnDgOORGNTxYrHrWEobMDUwdwEKuUOolFMiS0gbmtsB+YM9z5VBRC 4fM/SN01fXG1gTmfWR/LyHd9WXqOuEAVwng730OZwB7InvXX3H3rlHKCJZ/P42AcVI1Kizz8fUiV tcb68zugK73vyojseVDLpkitq+cUosTmaTqLSsjEjhZ86tlbZE8C2ahCPBel5hWUBJpXLUG2faHG p02FYsPD1UyyxGwizlR1fp3Cvk3m1osMnRUg8ZQ2vNj9gsO3espfd4ji5lmYg/R8VlEaAvhoZfzB mu2IGnzBOZOCdcQ/Y3KQP9T13BbMpaM9remOWTzFPaHUxdwGbhznCxOk7jNlOe/BoNYsHhRCJJ61 DXDNx0M2V3ge3Gk+PNNF+qMAqlRuQ/dkXZcSItzPLa6qsDwyVdZt3+DvHUa/s6vPOOKz8WA7ncNi toOi/S9rTnmrsF/DYYXkpvN64S0hGdqW8nQ/3aKMkDZdUO/lCuLK1Q7fDMzp/thLBeEKDthDeIcz OWaNfotyJeVWQKITGlC+Bb042/80O2Dcoe3o7w1Hb4okVRN4HegHNQ13JMmLJad+rRYtetnSvbj+ JQTFZENOcchf9vaST5KfWTQ21Tw7w+STfB+m2v/td2f2tscnGDHBUQ7QRPVGJ+9zmZPe5fpg2Dy/ sr+FnmaJ9lHVeMSYt3U+uVY29BqwYMtjt7oup0bJy5LMvhCDGOUp5nIXv3uNOOG1tOD2ulfX0EIL Bya75SVevydJ5yHsVLffbEmXUGwQunMnoC86TLX9/jed4PVO8clLAiFTuC3Z9A0cGmPpCISbOnbh uB6FrJZsW7v9/Mf6+yMh2U7xSi3dBpe9wmVp9ma824zRWIrymrb6n0AEupM6jYaTzCJvZyVybO5F WXhVMP4razjll5WlY0qMW2vuLUUpTj3L2cmh+VdCGqpKEzOo6h3wjWuDLwnQhq2Q5OEXQ1R7ooqW fAaKGu0m+n2TUlKZyqF6Lun1ChZhwLWraHHCECHS9QR+Mn+o3v4FZEesjQmxKCrTR+wnRr8o/YoT LvMw+4Y0aooLGp4aeB/ixOIfecaiBzRrthUmzTuRalNZLCulTffnVToLcmnZG0t0cFp3kf18D37r H2DtWKCZVli+vuYpphIvU7Lwrm+DpXdyB6pnWc8hEX+q4txsASci8u0iEK+EpRP88la8JN2OUYq8 D3tXx1eET6xCezFKBQauWXaCmXhmPWONcqTxBfeDsKrs7c9ZhPPJQXCRszS4Or8+K2zcShFZdBb9 U7ZFgE7RJ2pvRZIwyXAif2b/DZT2lNFA5U1AA0YtWzVS/CzuFO9z7BAqgK/GlM/LIDN9D2Ixe2ok YwvDM73RsCaNZMWXmmqYkTuMuIcYYllFxw1pXDjRCiuU+osH/lAcrchHRdpL+A6HCr7nLXnk9y+1 3diXyt0vQSGU6Nz6A5efxgA58B2GcjnGRnJBiYauZ4lZCoRXk6rGYyUyLiZaSOlss8qp9QWqQomR 46nn15Qk2bK5GSe5/Fw+lQZPxQyKhK8NTzrF3xS7Tt9gGsLLqsK+0UlGVSvFid7PAdPVks8vYmgV oxuI9WGQZ3hdJk3le2u5IhfGEiJnhsC3Hu71d3+YYZHTF/bA1nC1wP5AOmfC4NnaBp6bHm//CktW VMQDdmRnxN5KHRZK5cm3ahHoSzvA+nLKObI5qn87bflZ9amtnIMGmq1eg9IAY+77MAb6nYd40FB5 ZnDcw6R7mvnbseJDQkHFKRVirvNXUIXUiLqEhVeX7WNAK40V62lpxN0mIutRfkw4OO9nvfaQABr+ wcLXPFYo/QaJpqP26xtHvfuI7PP7vBPU+YVTgMeTdOVQLjRm2jTL6WL7Ym40pjQ2UtLqQGPPuW6s CQFdj3Flll08afEUepmAINQP6ckSCw50684rIgC+gj3F81ck+sRYoRfsZbC05G0b8lyHjDm5Jy23 SnGkRJxBV/Y8MIjABz3VTzP8SKIvsJC+QdyT+BButBcbERTH8uuXmE4B5aT0aTJkzFuxBnaEJ9HW AGUE7YGiZZgz9fa0fAL90+lgCEL2lcJMhI6dhjny7nxOFYcZFJ8oOz+QBaOWtsTknmAINjj12dN2 HvTu3tRWxB5P80q1OXHodGDfcgTdkkWnbW5UrdU6du4acwAiXIPtCK2StzUceOYWVJB91rXko5hs ImGQSx+2ySXzKDkjm2zyEZH6I7pmSU3jKo9fpHpMnbxsjg3EUPCg6bd48aaQa7VwCkUR/hjlyVqN upGTNg5SoiLoLO/ByIQuh6bOGAdDXrqlNvowwhtKnU0GHJJvsj0RH4KJiY5uvcpX5CVYhnAR9nkE H8fV3Y831mdyTVGtcb7MA3+lnD+SsdRryPRT3Cbwi7tL8ccM9aePpG8Eqxy7bC2l1LHIOkEAP3wT hz4XWfu+UnRuiRF1zCoQw/Adh/DqR+mvYTEOscFKG34wHx9Zn2Y7McttErelWu3bjHTrmFv2jJup kaRH8DG0phR8BW3hGEScKOf4pOiss2zzWIHZe44gcXevRSw4017wZQgUKvjeV5e2kU8tfotKxYt8 x4uvw8/fiU0mZsevR4O0VOaRyDb7uo4iz1pk52fVdcwyCRoNqRd34SymDsgCwtYbLlATuWN1Rxhi j9MtgjjAVnsnR5zszfi+4so9M8u7InB5NYMPpC6YikVmNizlhqiJzOt+FAiUbFaKxmcD2DHSnn7c qNMYvIjT4YC2qvd8iA+tqtSwr3YOvOjakzDQep6rTOxl9Bhlafr5NkW5IBbs5tdrnR2KcYutKlSw We6p3GtESPkhLb+4yyIcDP83OFdqD+1PuVgJOVmPIOrPUtJi0Eu+nUvwHR7fmZDKiiA/r2n2mYYn Hh4cUG+ndBuL4ap/qHKL0Lsh+qiGrH1ft2zA0dXaPF0BYag/k7z78our4hugxr0EXsF1BO9G2Ge0 3KJ6YNpOfKuRzsRXxVJHrcA0STOm1YDXLYmJKb62S4+QMIcv9EOQokHDtVsAZh4NEnXLG/eSnhGN 7ggFutNSowWI9/PDYSPTQWzep5bkD3BLP6QpomshCrtxdNq5Qxl3DgNR+3DfpA4Xny3bxHweG2Bh 2sbEIz0dRI9Kik09Eo8npVSeTqtJaWt1Jb74BzzJYweLdsgz5sTgIQ2Gq2zhwamdQCaSwIj67iaB 3L9ihXBvl9Z+/sXSMCcamzHoSOZxflS8xUPa4oCr5izcDeAnV7VKKEdzEL3tSiUsS2ToX4hyx4rF kh0pFBm+WRvYg572hxOavFYXV3aFPaiUPI8l0/51vEEXoh69yGA0RbD28UjyI/tPa4ug7sMtTFr7 9DIZNYHmOaDrsetdtXfBs8ldBD4ClkCAKS3o82TPBdPgHqQP/2Pm7qurIMDbwaoy+XiI+HNMjoWh x7egQPUFFk4Ghh27zeR18Pwe8+XEbTQc1bf8oM6ZoifWsYWR0uv4wITCAyao1I+6fiMEuv5aPT2p ZcSha+PSyTvtmLCwpqYRNs1ZqybjWiTZYAwoSTrcs+DgdTSZQH5kSNbeopytCXpaRGNbkhpE1kbB cL/prkGLLUxTHNLW4KP2nGe8Jviphpf9u93WpdCvh44Zt1eGy7BppHLXNx3l44FpLsofyHjRU2KL LpPAQ9x0SlSPvlzPYKnlIh3NvHmaIL/R2c7B2ehORRIWYbrk8b9/jy9tSMb2NY/m3Wjn7AfqOXOD gqz9qqNLRByTkMynM0HIn504ZFwcZ5v8R0M+ia71uPpRdc184RB1qscpjzktrOiBcsu98fOf8SOu 0+wUZd8u+MBhxlcKRs7qaRZzdf6do8qrneqTks0qbQpkCjQstHK1NatXN8R2qsJzlJvXxVf8wJMa TTpXchHR/I8m3bpMu9zepJkEZBOPmlkiFL7hWj1z6cRbri9MfB/QnojW7TZJ7K0dkPQ4tCgkIupF F8dKhMP2bmawo/HNo9kY6Z8JxJjdcgi+2ICFl4s2z6+pCy7gSxCX+2OtWyw2agcXafFdfuj2JXB4 9UrLkw6Js9+5MoMKzZM9c81DAtWEB2krUHRBjIfuxuWu4O7mKGlGoPjm4JuC/Ok5uiV8fB9FN5V5 3+CB9H68mEuEld/xYW9K4S+SSYM0yDjNR2NgK2llvlPMrPMywH7sdhq8iCZ/YCHn+c3p/ESsVl0K yNLK97aStghDBkk086C78eyjtPgugaJ1UBj1gw/ginI9/PsQOdM0V/33PDjJxZDBHhaOPbKz3Pem RbxJBB5FOtn1qDLMq9sePsyk24nDWZYPFPCMdyR/QAm+muXqmg8feqKMvo1tnDmBho4y+0yZy1bi lII/V1YEFyuJKI7UPu4rHj6eLVa4IL3jvZv5/GsRSJDe/QM9tNpMCdrcOjj3DLSFZ/lUw4q70TMB vvFrGbWlN+7Z57vaysnziJc3oSnmhaaNtBtLsdQgBtYGpTvTQij5VoltsuDqTUyTSbDkCw/6srVn OjEMn7zEL1bxRCjdPKDG7PRK8zxib2k6OPbKKIal6ofDgN9g7SgGFD1NlSzQ64W/+GBviXZF1xuP 0GXnrgSIYbN7WhnueU5/PS09T1w+DdROx4Ryo/oy8N8k/VjCb6AtB/fPVK3vglOSWywfG33knxDG QfMaFxPgTMeLJ+M0+mKveHtoi0i2Cj4utu3oiVHp6VK+JyyuIj2OkmGV2RhCfhjn4rkgfzHlXH/k o3m1pVi6FydNZrgC0q6HjvsuRLI25O8frsyHTPQNiDEgOyWAlvdD8M3xZXaDp/spV/tD9a9FxqYF qUs+dZVS6CB/s7we6RA/+Yml9TvyMrhZPQ8GnWtxqBnEMYeymCiDyNrVl6dAmpYH/dTbDIlrczZM NuWDfoBVrAi9OSQpSqCpuRnaAbb7bjFzx/z1a+l2+EXGo+aFMyy4gJLkCVWMsC9zMdyQL75x9Gwd U/NrxryeYZug5W7LfkCw2NTrTqR7/pIMzGJCRK2KulW7piWNbv7inaW3WKD8Xf901i06TY2MW8JQ aNCAp+WAFN3eNevUMf9vrF30sW+CvFEpuBW2l+gMbE2UNwaoLUMzY5hp9bG/Q7NLO14uNYZ+C3d7 4KNLpDNqXBkwcIUvYgxnxLH6FolkHmoARq7Otw9+4Bo3/lq3DEC1PELyoP7SclyLhQqVBCa8K9W5 udCQfXpqznufwCxbg8ZFQ/4ppIIon45L50eJhxxmtRHNbDJYYPdvD1tbZzlC0dhh1HWnbpO0KLKE AfJ2pbCARHX1rVsHnPZm12Xk6qGIalFbSXK+sIwQdwrZKwsRO5rgEODp6dp5aQPBWkyC8naLke6v 4MKkNmy++6UBXc3ARlvUK3C19btpKDa2NkpNtjIvNJj8AE8u2mIia+3x9gJFqKgDI/+eYd5xfTdE rmYYKM1GCWgRVVacnfFDXPFfz37i4nQS+2KwvcyhkdM9qcMqvPujKjKyZtp96WdtL6IuijewCo8D X45JajrGQiKlfDrNOLYIy3atkze9oIVP0J2peK/jd8+XXsDAySQ80a7vtnkPqjMaXXJrDP0mZvfD CLIdA8YMvWWvJhK6tDBEM+l9zhDZLCPXSCQ6O2Vpyf2cwFwZFmsnpnNojz5dC+WO2LFDenKVeMJ2 SJRPPjCgH8nyISsGvub121x/XdSTQpkkv/HFoJTd5lT/UOuuM1e1X3RLIy2RctzmUgfyE9Ma8MUf nh2OClAdVH1W6wKDjAnZft7AMaHHmN31ZR5MriKZRcVBfGxvIiVfDNW2Vj3M2PGO94IkQv7ZWaEr gpVWyYcngUEAgRGozUwAi9Fl6TOyJ5P3azVJhejw5M4oQ/l51cFsp72P23jTxNq4HK/f/n5FHYpO ryTrlfsXI7CMprVUCWodvB4zJa1oMLKxyfmryG+4Ihv9Wf5Z7lt1yvqynVBEVHRGugbplNwNVyuC eLM7fH56MEsyYNWm4uVkiXS4Sdn07o9LM5Iq1K7C7djmqrVg8GJJtYEvyYS5QUqiLOeWNMNR3sXD VJ8JO9kpUNXlvI6xjas8eld1FDudSpY3DLqAzjj2D66zP1h9tz4J9HXhNly434f61YYVDEcz1cJp yqiLTHOEgyEu+2QrKM4IQE6mYebWjHhcitCLfyEKzhCa4nISOlTnRAN5U7jZVaEj21rAmzMlePAD NWCdDgNuYYgDUnQHA/b0zz+EIOAkSKxspbWZPzCms4+RK0ZohQ1stJdEHiflC4wkyYdrPl0E9jQg V9EHZUUXks6bebjr2iH8/B7+vOSYaOHlt4+cE2iIfsu2oZc1fkvzDcYt2bsiUZnHfDEdHZ1maXMv qbYrKWbrMYn1yYYnXCWZ2DIg4+j3dRjuNy8Kno8w83q3lSr+1Mosp73flRxx+1bIxMwwDSxgZh8a T7xjvFInX1TCJOxx6eIjqYAHuyjodXwKO0LTnGbITL1Cp1tSmNo6jIFwSq/Ycvi9x4rNmgeRYTyx zfs73j54EIrAGeF2MOWQE/kQdZ8Dy3ycare2KQyhi+VUbgUCxkTQouJbgVIbvqYO6YY6fggukTJJ PlO+EmSEnKwwo8Jxsk21nq39bxBouPLV2GZRqmbxueICE0q9GarCcdnWBOxox82fkpRwozd9gPtp 6VE0UKpyMU/9YwfY0IrC+QKqtL0aXGIVWDzcoSh5m1ai0yPzEXFAi0A4V8lgQ9Si5PQlzwsnNMGs isovP0UIOrqUaGNVeZmm7MhguEEqwI09QlyaJA542tBdCg/Kj/S2RSQHV8pxJdeNADbZ3/o4mcQf DT+2zaAsUuNCGgiW4wa6xB7P3Dw4Yg4uWSFIJlyEwh+JdNVG47JbprxNmLa1c+jE8R5Nc7a2lEgH lsF/vNZgCBjQPifLc+8iWmUqTLKCqHEb6nI1LGv+vPYNIvG0qQkPrjstElEp2Byg//Pcr1e7UZxh 6MldCzdQXDVtDATZ18SNcdFvqHJ0xEmM/UFrSmnDiJAd+tMcQfnDgCGq/KmmA1NvLSiaAPIJMXzk rfVIzJxL+li/quE2PtzSjxCzZSRkeG9gBeVRxaqz2demtZ6hjXBNQf1q8mblm0JBvIv2FPHnHUcY ygU7AbJvti8MrevF7kyhhuBbWC0MvDFpZOY6cvalmWxvX46v6VP7G3/kg+8kz5acBy/ImIgrrRQx zCQ1N0CNrJLKdCGK9H1i/zblzkcqkfkJETGcTQFE9ikUy6uuulBqsmVscenxrIuBDqhtCL0Q0fJi jCOyDJ7cLm6k4Yo4516Mnte9Fg/wkLTO2ohwJ8RjRkOFEQo1JDq+3/AaHdYWrT6Z/jwj6kdC/XEZ l3omvFW9g2OgF29bysS4ZvuHekhBhumaVAxbl5/2owC3wDSXovaCLTvp0SlOlTNQWjYLlRxSGFSP 1gGTFo+qSALNMlZmfR/qqWolvNiQYDI5jdmY8CG+/pbgF72dNLqGfQAiYmeVjOfhvoiI8Z7cbfOp v0oD0wqZo3BPwNeuc01haZx5jsiqoyoWK7uquqgwXPfzBSnEqi/Z0r2RBRg90CiYHXpPKFTasEL6 d2iM9XyRAiqrqfSA/dG2wNcP8/YPEp9y1T++jBLA7pt8T21xoUjKIFDkNwYRxEE5uiLSTpkd3U+R E3tFogbY6QFEMCKqmKmN7Wy6W01NJGJ/UrhMTG8ZXAp/mQ+AjPx6fPRwfVSmrnN25gn7rU1S+Pve MjPabJAzCpu66Uda9imtrNha2KhI7zCfn2BOXFDedXFJcPQlck+4II/lpXTmvaUUnKfVX8UUM/xi 8e5sRv2IQU4d5tJNDGx+iw+qjjYxKNTZHuxnUxUpYzakROAGiRRO433OFHgj1jn4bHO7rYV+PHl9 7agrmYMm/Ep4rvPI/Qc+oCFh6YEk+J+W07LibMOP0nQk/h6y1vDiMUQlX7cQfgw/soUN8eoWlLCL gXA18xi9EOYNoKfCKMoSSBOeP+FdfjLn5+r2tuVIaRfSN+/NrUGcS4+SKhIjsbMjSl60aoIraoxo 36v4dNSs16hB1E+OkDV4jM0V8LQIbpZYdAOHTGDU1LYv/go+gvjkxity7TUDMSDZW814uFkuG8sz goHR8AQ7oe+Ih7Uoqju6F3h6FLJcc9Pe55N3Gd3crfOZl58r4bK+t2LWa3EwNXkddDqBKnNRXJ3V I8B2sZyjPvSVC/mmOkvcULA7SMaZytrtfsa6AE09/arr/NV+LkzuOcSuADCSbI1jGqyqkxlmI/dR 61m0N5G6xoMuyjkBB+s3J/It+kXPGvS1uhtH71vqs2981og+v8m8k5DKMin9RHKS/p26u5ZXkZ3q IShIc5hnPSenGkXreQ1e4Rs0bF90eEVH5I+j2JDGXcvJc5kGwq++bBfSzO4d/FoVx1EZX4MeOUkT uKk1BkoAQ6frbBZ3nbtK2Vn5vuxIqmdL6oTcXnXXzmsVajiKjD7lfELE9Lm6Yz8Lu08PYlZ2OtHs Yd9c6EtwerYQieIM4AkaQvXmk49Yzk5w4bIsEhZG7fIyrZXUz2cv2le3cxA0lObCHACXIp2nrCQQ hdoHeQc0qWSMp18E9m/LQgal1gO6UzWHBjaWGvF5oPzwCR/7j1Hg5QoDJpUxnInFW+839Bch+rJV 6ubtNo7gg8GwJLqGU3XqT6LscA3r1m3ZHcPt45xPzRRqi51xBG8LdKYl8NN19wcrMJCPDdOVllgI StRlxTPvAQhKmAJ4DlcOGqflKyhftyG+fnzOtkt1GdBhPg/QDGd+NbVg4pU0aggGxDjAff7iuVct oB9IGYC3TMpK8DFmCekav5hInzQ2Y1Ri/acjd0/WpmKYuYVFGaacJfGZyeLRGaqx/HxDJwO8fuoJ jf1dqxPTVVUsVgiZ8JZEHASoL16OHY3ESKL3nFl5C893eNA21rqjfxeWHPcKB3yUWdfaeei0bPWA kVVClfH16fdUWJ/5Y9lmPobkjEhUaAvGmsA4Jlt8yTruDgwir64WarawCc4q09h3xcqNuz1PLFRc V94rG8yfZmNeBzJXpoWNnki1gX7GXzjIYQKTeTe0mHbZS8iURUXlfvEV0pxsHNupl7p8SohbWLFE qdBq8PUpwniG8NDPvDBciMwOvZUI5Qfrggu/2p9gjrqvpXD01suiZXKueHr15DNu4ebIHt5UQDol tVioh3Cuf4wl1xvaVUhmNP2wVNBjHx6a2brXguHA1YfevrG7oOjU4vtpKOIy8yd+j4ThelVqEKSG 67NBvIJqSK8nsMgcWiZ6jJK1iJCO36dKKhgRYqmiTEx9+go1/Qb0SDt6hILGizV7s0IyB25YRQVT /uCkiSBflRumEMLvUxphiCNDAcmq1stCxFS0L8kesptNfSbxI2fjMl0x55k6/Hp1Fje5M6jF3m4O ugxO/baAfvIMhH8W/6S/rc6p1Voi1nX05RwMvFmoEo9gpFOLhaud4JgyNfZnyGjN6UCCW4X/CBLT 6jF6u1NrGXJHOUIxF4KIY4XcWWtgh1dIq8TCGBrGY5QJ6/aFIZX/ujO0fTGcdROcZiC/tjtcqlIj SVvvM9wJXVj3liI911g9Zpw1vfXS91c+mJav+z4CUzoJNga8gdzp+rtvX38TM/EJX/Ht9bnavVgb iuuXudKiDxtd3Yl7r+VncRzC7n2R12gJ/E2dD86GeR4wmyUD1IUf4kik/LXYitC4UCNAUSh4jwGB 6ckM/3KHzlA4EaLUH+STom+Do8pC6FgfmoZa5Zp0wPkS3Dxb+W2tBFOS0qpJbo4dEnuD4zpPQ9My OYiKeEuZ4AlHO+NsyYnl+t75FIXhBmPDTJtO8Mu3k2iouXv5U6xGFcOcENaskdL4uYJd5RiFVMdU mZXMma1+M3DDl/5WASzK0ZDVH6n7QxQE5BXITm655EUeofwqgjn44YgjEPXwD5s04Ee1OVAV36Pg 6m4EZIqbPRDM3ZTjV4drruYhjvA8fX3OkUZ/BJQ6IXAd/OD0tgj2TwgscWrrs8/38ay1JUj7NjK0 KCvNbgrBKO+QOw4q4N35rtwKZ3sUogMX9duWmfPL/NOtfjVMEB+TNueqWpnXJBO87I1NvD/knkZA 0JWG7VRx9HrWK9EcFx/GVKKFbmrlIospWCjh4iveyEbrCsEefbDItEaEQDvdzfYO80QFTlyXqZkA x0NzwuhKNRr60ef09w9j0zpjpCtlpPRv+4cHuR8cv6MMhn3S/tyN+2lT2STv4dkEe729PZh4uaYB DKd047A+gUOVZKTfKWf9OzMu4TJzIzhFiRyH4xhY4HgLGEsvAGTFoMbDQW6NmckhaqjzKgs6uU4y 9v1Z9j3V4U3xzAfUQK6CHVBGp9xrhI1j0dhb4ZOEO3UcbN88p8FsRrp3eHyArJ527OYCJ5HB4ofh KIXEGPWd39RTNgdNBjZTj+OMJBUm+zpc7FkLnOGA2F3j3qHFXJyyY/9RKTE7K8X3uxBCmX2U8gVu +JlwA14EqalS8cUtSbXVTFsJycjohkNa3oWqgvpZ1LC42zdpjgnSZot2bYwYvcnvCxIOvunXOTWp xcySHMz45OiNDgZapVgG9m/EmFAp54TlW0m4fLI02qOaMsIHv337rkP3sVC66atVfYnlxRcGaNom fHD6ZW8UkdyvyzmH+KzDnFRq5Ckek8APHo35Jfl4eDu7i9SvFSU6Bt1Pbmg9gZo+c+Nz7AT+3zJs FPR6dMNejWEfJPkNieugCeMOz11FcTuaYaAnRxRX2K/QxPQUH3MTw8QgLk3ERG8ORNqm+O6K+MRD IZ3BXiqtPjjmSvVlnWwJEWoUX2RVkdFlzBtJGaDVu1W0dFnoZUNB1sFWRMWCeeOt3U5hY0MZ1W0/ s4Q7UEhkTtO1pNw8UB9v3E1uPT1fraa4bURNmQTZTRVeB/GbMMlyv4X8fiHEK3AlfEUM2+7nGsYr /PWV+cJP5PHAqXLH7Y6kxwujxMtB6M0gY6UIf5WLTdxNUVJTEa+N9WLlcnnONwFF5ooBuiokxrvX 3S797ZDtsCxSVe8ukNu9ew9iyFMAd2KXzkpntGYInkwrPPLgJDsl6vJovVoLZ5RRvTgKirQ7jt86 35PaNQZlWBtvHr+VKFLwF40j0XmYTkPR2Hnba/oJDbt0IHgDGSZXddC5CQN+qOB63kE/lC6Rzhn1 TP0dgq2mqU/ohxsbKRTtEnKknzeyNNt1IUf2vJnRglOGLsNjEiCNx3Ltvrq7Lz+XmEusROsaFVmM B8c91oQhamsdrGhiMMy5bCobCA8SUXLQc2IcMnYM8KFjx77a7CCH5NiJOMxlGTJdBTb1Oi51COFS puvQIovgIJX4PuzF3lZNQnFtN8tZtzMDC78lZBB0F07eM5XAF9abhyRldMTC86Tbt/+Qij6LUkAm owhEQkbdWRZJaEVMwkIAQESuubEUIzLPLJFqQNEVwC0MruBVW8l4RkGqoAXiw4kRGmvfqbnJ9DS5 PO4HWyPJrf6sLdiAY7KHPcSCmPd08PfHmY7y7bmXCLbiK/jpNqHKLsPa+EmqL2pxLDYjpDD4ORnn hcmquPmXgzfAVgyTSYiMOJkGqy4Mcmr5sD9Dv0LcCnqrBMmjDJ9BPtsRQtr3EnHcLphsOjsueqCd NZpHr26Mc+O4CyMPwfLr0cGFxJTpCmRbLh777viS6DZjbDReXJ5zlfGC02beqmcvswFd/MEYEfjn /58/+P+b4P+IBCbWQCNHZzsbI0crePj/BxRsN3kKZW5kc3RyZWFtCmVuZG9iago3MyAwIG9iago8 PAovVHlwZS9Gb250RGVzY3JpcHRvcgovQ2FwSGVpZ2h0IDg1MAovQXNjZW50IDg1MAovRGVzY2Vu dCAtMjAwCi9Gb250QkJveFstMjkgLTI1MCAxMjc0IDc1NF0KL0ZvbnROYW1lL0NCQkZUTitDTUJY VEkxMAovSXRhbGljQW5nbGUgLTE0LjA0Ci9TdGVtViAxMDcKL0ZvbnRGaWxlIDcyIDAgUgovRmxh Z3MgNjgKPj4KZW5kb2JqCjcyIDAgb2JqCjw8Ci9GaWx0ZXJbL0ZsYXRlRGVjb2RlXQovTGVuZ3Ro MSA4NDYKL0xlbmd0aDIgMjMwMwovTGVuZ3RoMyA1MzMKL0xlbmd0aCAyOTE4Cj4+CnN0cmVhbQp4 2u1TaTiUjRouu7GFSERvsvvMZhj7vkS2iNAJk3kxGjOaGcMkTKTFKLK02JOtlKjsYuRDEtmVkKWE QoWhhDPV931dp+/8Odf5d67zvn/e+3nu53nu636eV3GPk4uGKZZ4FLQiEigaCChCDzC3N3M/aIOA AwgoHKKoaE4CMRQckWCBoYB6AEJXFwGYhvgDCB0AgdZDaetpwiEQRcCcGEwj4fwDKICKueo3Fhow DQJJOF8MAbDHUALAIHYTXwwecCH64kAKDQoApng84PythAw4g2SQRAWxUAgEgQCwOF8KcBT0xxEg sG+ybAh+RAD9I4wNCf4zRQVJZLYuQIWtUxVgq8QSCXgagAX9IDAHInsayNbyH8v6N6p+bW4Vgsc7 YIK+tf/Dqr8xMEE4PO0PDjEoOIQCkgB7IhYkEX6lHgJ/yDMj4v82yIaCweN8TQn+eBDQQKCgcNSP OI5shQsDsU44im8A4IfBk8HvcZCA/VUH273vKmDmZmZWBx3U/9rtj7wTBkegHKQFgwD8Z8F3jPiJ 2T6RcGHAYTgUDkewiez3z68jv8yzJPgSsTiCP4DU0gYwJBKGBmGfERtpAeEIAEfAgmEAGMYWDYMS iBR2CcC2JgLwI5Ig3xarrQXATL+FfiBdAGb5F9KBAzCnn0gHgLn/hRBwdhL7E7JvE0b9Dv9uh5kZ MSxcA6kLaCC12NqQaBSA1kJF/CvRlYA7HgLaWABacDgcjf5hhm8IiQQSKN/PkG31n9gPx94OCIaB vpD0DAncVu/fZNWXfZaY/fKHajrfxOS36eoabVXmfRApuDsvQsVWbjhza96VQVJdUbO5zsUgZvfE 7ynWJtbC/NtZXmu86NJYGfVC8Zs5AtpdEQV15apAdXnWhnsoiuOEgRfod6sXuUGs6+w2DeOIVtM/ NSAVFqJkeOxhzv461uuzIvN3fD5y1Rp4Uv22jYiWFNge2xYuwGWenXuOEd+UhKyNWcF51pz6oCTY r8DIwma8vHnJrmpgkDxA+9pkZZS+vJ0ZHudRe5Cuvly9JB/PYAQmL7cT7N7PLc7ZyVj2aRdm8nAX H873l1m6nuQ0wB+uUT7H5XngVG4Hn5Zq9xgqvjKvDduXF3jVx8xgj8r0RsGjjd4d0CaFhDadhicZ gJFVij5qYdGlwGlf3gl/SQTaPx0wdj3Vb+p+PAvR1de79v7wXYv66o+hoxp0g6zNwobz0g+DjeiH b8hsSzO+ZXynsqe04riXhaKWsvHtIebxVDox6e35zABZWLbfqCSk7ekT8oE53PFEaiBmted6rfjd yf6ZLawDPlRqwZR2xCmiLKjjJBgqUGn5OxWSr9tQ7u0dwOOetWdzZ4vnHjdvHbFsokDm29UrZ336 MpmKWLQkciSdlEjPmSJ/aRG+c8jiJJ/sLOdiKblLBrVV22pm1KQi29r1kgcvZN+Zj1fLafnS/rPv llT8d02kYW5cKh/WIAXbiXND/QrAcjfOI133cZcYQwoXgiGjtFdbPGtecqiX1iiaziV2RkWLH133 Ca7/R9eQQ91LysGa+7boOAl7pqtH8uJvQvwqwxst6xn1m35Qz09casp3g1nDww2ynWbB8otyJgZJ IguG9dJFHlOjrqehsj1thTKRLc/T0557MdsXagwNeZhgTVK7g4T1gHhpua42imVQhnOzv6xSY+eA oIQ+UamoXvWBoFYLx/nEbW2IlSzBKq9ghTZLm7MvijbHoopLk6T6BbOa76N3nHBpfVafKiRoJqx2 S6+SxBB9FvG7GtXmiWGxYXud+dkWbm6J9gQPjfjkZBdZUcepIWrgTK8jqr+bz+rlo4hG/RJezQvO N3PWIjSG5snLLGstpTlL3spJ/bTdLwwrHg6llRNWe3w4AWxDjiTr00xImb4+qkQkE1RZkRx9duPW m9y6xG56TxxnW3hA/ewIS1JA8+xaqJR/0+pXfjeG4KHZlNFwlfgiIRdzDSHshtNYhadJq6FNs9wn E8eYD2iKX2eeX1/gyb2hhsGlsa2GG5QGVd7KkIxbz22B6YzH5uZJ9wQXqlTOhF5fdcrQ7U46gVev Nqo8rTUl4wUxM/Pw3CWkeaP6SiDM+JrUTe/sYYuRzRrqxla8u2eDikLJCja4Zi/V6surB+p3lT0m qtBOIyMNAiY41XKOZ8mOepbj6gy1aX/HCvHkLqvcsLr1jGsdPFrxpJF3zuPz+U/kXYOQOZw1N7mS 1BTjRVChFvRZz+CKddWKyr0BNLfrqnRdeGawPvncdjX0msHOAsWMnjLVqTQhhfUam9vD71Vet7TW mpYKVZgMlSXnMOLwLQUDBs0ntm8reNlOjD/HMxcY9Jac18qqmSU4TE9ceMVjO/ihQXREYGLvV+tt tKgoToESbbrO6P4iH4Dn816lZoeuK49X9zznV4VnB75HfgjhOxg6Ma0kkUCnUTXAlaFFycXwfJsL 3PRphKTwvoQYmE1WS8JLYZ/ZsgfbqOeVmTGD+1XcTfbLN8FrT36pttJWNHq4g6hZ9bnkc/6802WX PGgU4fyiR2Nzg8CtIN2jY/NZHh2F7D+3qGPs0il937KpDitMj6P1xku8Xmc1yb3dRQ9d+rynl3VN 6pD064FpY+jlQfN8fAZhlOPqb55TDs7UVePkN7xHYDvEdgUUGwx1l9nZdtDHu3ZF7j+conxGRu0C ks7BjL9/b4dxT6mp6BnbCWbL+KwxReTBwxmuPRpqJfyLk6rYt+DO1WJOjsgtErucJyQen1s7Pp0I K6gp387bJRZ6cafFsxeNgvyyD6vetF6c0KKQXj+XmRyAqUezRKcYZdO7gdxcT6XJ2xI00dvROk81 xaaAlI5ox1cGSvYfr+rcL948n90Z5XyDb7ep9sz8xa2joywz6pPBgWyVSvrS1wfE2Xr1a8nRCUYM BYWA3uiBsfae0j37zucf4FBdl0pYD3Tz3SLZqf1m8E2La/WzL/hGj8dVexPr+Xtvp9v43Iv9RLcK WIFKc1farzpwZAmnRqkOnBqKExqJJMvEJOh2JQVk9/TolgEi+44V6XHtqlNLXdays18Z+eAYs5RS sVD+8b4wasS1cI5WOSQ5Flu8GqRhirQZrTXQdhKzPl7GpF4xRyTGjHFaNw4UrYcsmBTKIcFmhX7N WW+HuOIeztq0FMbMUeNLNAd3a83ayfk+R395t/u5zHefu7s+vRPPDfSTm85M8apXXCLVuxLjMnbk ruHrlh9fPGMr5tv2Dx9UKFpQHz6Aw/qpOJmtEz8H7nSY1hSMGfTYHK5d6hauCM8RbuQ4LRWkitHn O+B+MjnROXtMT+Qzui31DtPinr1wM6En2m8u1vkisPLIHxsj8TFlvH/nIc3FJpPGu90PFuTq7r2Z fcQCn8baRWqbph14nFowCMUbM/e3fLCTS1qGKCEZgpGXb7TqVPkoFEbBfZGu1x66HayIyPYu7ujd tF/LKihQ1h/SESz73LV55VDg6a0zLZBHw62Zt4QzfIu2MQpE66teX3bkc37UiE1G2Cb3uTsiI+n1 Dhk8quVCuunnXoGKAlMi4/FhPVP6j9W6z73yFhVp1kTAOKXNaCKC68oS9xwuspA+3HAUnLzaVSjV VE4+lj7cFIzhn42HJ3pFBKS681pDbyhk5V1XEDxMka826d5XG3YT7nIubG+RkfxRxRdpW5TtBPqP jUKnQhffbxmTR3k9qkXz3El5eqe3Vizl9E2X9iPC0iRvJ+ZTgi/Z20ksebvw4qQzeMwwNc5zddy8 q/rJBX/9hcOQWbdYgXqBKMGrNIKd6yQXop8s3W0Txz3s1V1XFYtZO1vC++Iy3s6QkcO1IjobI5fa N3/ScrXPmaWQxji75DbiP8ZvbCjyUU+Tm0F4v+P1mVfegZ6esMZx+H/5QP7f4H+igS8exJAoxCAM 6RgE8k/bBuTeCmVuZHN0cmVhbQplbmRvYmoKNzYgMCBvYmoKPDwKL1R5cGUvRm9udERlc2NyaXB0 b3IKL0NhcEhlaWdodCA4NTAKL0FzY2VudCA4NTAKL0Rlc2NlbnQgLTIwMAovRm9udEJCb3hbLTI0 IC0yOTYwIDE0NTQgNzcyXQovRm9udE5hbWUvRlRVVFJNK0NNRVgxMAovSXRhbGljQW5nbGUgMAov U3RlbVYgNDcKL0ZvbnRGaWxlIDc1IDAgUgovRmxhZ3MgNAo+PgplbmRvYmoKNzUgMCBvYmoKPDwK L0ZpbHRlclsvRmxhdGVEZWNvZGVdCi9MZW5ndGgxIDEwMzYKL0xlbmd0aDIgMjQzNQovTGVuZ3Ro MyA1MzQKL0xlbmd0aCAzMTA2Cj4+CnN0cmVhbQp42u1TaTyUexsWM2EoayKpR5bss2TMkH2LQsiS FgzzYGoWxohJlkIoRsXY1xZlS+II2bKWkq2FZClKlhM5NAl5hzonp/N+eX/vt/f3Ps+X576u+7rv 67nv/19O2vqQqgGe4gaaUsg0VaQaUgswsjQ5jEQASDUEAiYnZ0QFcTQChWyMo4FaAFJTEwXs9yMC qD0ACqmFQmmpY2EwOcCI4k2nEjy9aICCkeJqFgYwIIFUgjuODFjiaF4giV3EHUcEDlHcCSCNrgYA BkQiYLsq8QVsQV+QegrEq8FgSCSAJ7jTADfQk0CGwVddmZM9KADmO4z38/6TOgVSfdm+AIVVo4oA 2yaeQibSATzoAYNbUdjtQLaZ/9jXv7H1a3FTPyLRCkdaLb82qn/wOBKBSP+RQSF5+9FAKmBJwYNU 8q+pjuB3c5YgnuBH+pU1p+GIBHcDsicRBBDfIYKvKSEAxFsTaO5egAeO6Auu4SAZ/6sJ9uTWLMBN 7eztbC2Vf6z1O2uNI5BpdnTvv+qupq/FyJ8xe0BUQgBwFMEeMJKdyH7//Dr+SzcTsjsFTyB7Aii0 BoCjUnF0GPsEsSM0EIgECGQ8GACAAWzLcDUyhcaWAOypBAEeFCpsdaVIDSQA98ZRQTIR9KC5ETxX 6R8M6geztsa/UdhfROupX1U/OXXsOhXN+yeuuV6yjtBQX9+G9hNH/63HOkJjnYD943/hmPWCdQR2 tTWVgvdzp+EJvt5EHH2N+udCDQ0pAYGqKHVAFaWpwR6wOlodwGBQQX/PtCcTfPxAc2MAjUAgMBj1 NdTdj8ruTFu7RezT8mfsQWCfLRAMAN1hoer0cwWahn2IYcLNTZvMkFI+l76qimgdRmJZHkx7xulx 9VhMWwsovrEzYveD+/s3KpmhCzEBFo2pveGikFFs2XNVzQ2jp6VGWVesBEpfzRmaX/arKtlFHiIo mTv4ZkUpfIBembNuft6g9PBiR22S2WcpcVktsbnrpiE8VgzlUfJcSPN2rbMpI+258IWmRV8mqeCi R1j3Fnf/0JhSa3lu3VBbPadrmyRcOtKynh78ukRyMPcw5CqQLazEPo+V9eReGXsBh9Q23eOXnvar vVsh7KasTRsnvFTV7pJ8KeiWkJdezCemWB1k+b6SeEsRESaFd3SRmSvamD3qjDwqpSkrVBtL8n2U HJA1ezj7tHYM4IhyDLexCLfnqOvK80HyLwk9275NLKjGZUa4BTZgFYlyIdumcCmFZbx3KdmnJXbi tvip6wb7jQ7uetBt4LSzlBIR9Plr/EYeP4Elfrs58wQP5Z0cn/T5WLYTsWErTY/9r16qVk1J3vYu VWKrWdWxwJy87sN63SLJJsqU+V4taFZwUbsay3h8YFfNQmsGJG3GC/0hoFHZH2xJG2DMDZZNnFmZ 64i3uz6wkhs9mCgl5i97ubW4JmRl0FCfG9/CYFq9a7K/4UV3OpfWWCpxVzRookBDwUMlFNE8DJ/g dU2ttcoXfru1Wuuz76dqjZtcmSV6bY8Nxb8JNF9bMFG1GjJ9crnfs1z22WyPH+dillCxZU7MdT4c bwjzmZEixs7zd5Hmx4edm/XcKnQXrFVa7YuN61AVgRfG/5j90s9SLbhUWFzVrrCpPH/l9vIKyXlF 3iOt0EEBxoS6jnRuFa3CgmmbrRTqYl7v3LISrJvXd+TEYq0OgwDNJx2SOklqq8gENJ6Yq4As0uvG jo4/9AZ1spYFWXlQxPJxyCeVqWGpzL3+4UtlhSk+XXLIYEtS8Y4ukVZmM5HiaHpEMCLeYE4wWiwB GJq8fdO7aXn0iVBhbafotbeTxN/FEqYRdVMHQ4/hZRR0ZI2TXFzcCs0qzgp9PEa/ecIKXwBPiOp/ /1aqnq/NCNLY30nJ3VQ2EPXWy/vOxd7Q8qATT0Uk7dPrUjKT/5A4sQ/F1yQ8WN7SlgKJaFcvT+1o mb36m3pnTtcyyXnSWWqw9tDdnUeP8+hq+HNjlXvFH+TdHrU++oqc7ncmR1hkJkcFzNSfaG/afzJy /rFYG03+BvO5pfNByIcArA9PdZytTDwIT6JAq76Onqki693gQllH1SSsVI0pVjl8g5wOjyKWq3Th Gnkbz+ye70nhDNptjBq+7T0aV/fN7jwlxwllUtkjlKwxcKdILW2wU2ExpYTKeK+71FcuHOrkp8d5 6aP0nuYsTdmB3SuHLXV8sr7WZ+ccbw88TxP4AFkcQo5Mc4mH0Gtd99EGxzucXgbItGQJIOBHcqOm bjHv8VT1KioaSwl0t+Difot+Y+WN2BWCvaa+MM+b0R2R/Sbs0eeWQts9O56yjhtBOWaYx79Zc2R2 F81i5r0IOYGz2le1S6DCpaVBjjNmPTyyc5GlAdKCDp3ICTpn5P4vfckAJs7i24LfGCVt76LFSMwY K7aKH2JS060vjcqVvf8ezhoJmkdjFbZ/NvZ/0//NDuPfy3fikP4RCuSNbfMHuEHRhbrKyahQX6XN DWhItdZFPm7KsN4X7mYpLcWXrRdu6zlY1Wa+Ln90QJL6teGc9IF0y4p2+QdnH3tIUCvNWbz6OvTW /P6OiqHSIEawhOyBqnQnI+WoQtkpmw82kLMrkjycJ+rVMoOnj+x/e18LLqGrzgFc4XSbKQYbEw+J 5IZE39flZbQkLLederYFa2PPUQEX558t2VpwDHnTjczM3j4sqXE23sRFMDFEkjvpQLse6dWy1N7a if4KdPJYPbSpzBHboIYl2Os2ijEfqZje0vPtmSo89qIEegrq31Q/2lMfs7n702RkMUcKqIwfGHg3 rE07Z1Egp6fXPIXytZm2jIZdSJdsuHxnKimuY3KkZPOQI6I/dyvKvn/qNHqGvqw14PX0tdjrExy+ i6Hk3GWTdi5e3vjyJ05Ns5hF3Qr/8HlRGZgVVImHTo3eZCbX6gqNOdiffcV0w+xdalrjwcZrR8ds Gsdf6ddYf0HKhcRNVyu30O+G06kc588ZQFyEi4K+5Jl3RH/dV78Xy5gYOVqR/xTtbM2feSlMLNZc 4lL3wBOmePtVrxuBsjLjNP7QhnzhD4wFqhdR6d6LYwWYHXGlcpUvVKFhm17t5dbqulyfsj9uS2rC SlP57ucZw5n7eFhZxEfbbOykt5qTI5hd93ojTtksDenYGUc0wE0WDHjkvm3jG+uh1ElncZ61Dxmo tvNCRRIzXdXapFk6L8mDfSoyvDxOol4dkdDNA09VpwoktJWud41nq1m068AjlTFbZ8vxn9DJhflb JuSzVZeWBOVvucSEhARqboy8oxc3+1BsS5D1hh1lZpCKg8aJZbvBZ1WNjoJv92zbw2F75qW1bn74 7ReXukiVF8r0a+cq+FI5G9GP+rW33TEsqC6rNIq7MTBP7brPYSpy2Rm58+C8q0xiTrO/jrwrlzra Tmj7yBvPbfGiREX1wL2qdX0fBWy4Uen5sONg5AsxRjcDGmI6dT04uzdcKLNKLVV28phesWveosfD lYVXTQX+ogkTyxhOQZ2sJYn0obeTpWKKoRfSz+uBctqwc+W469u5eq3Rb25w8I1o2CBOFV0UiP+0 kzA1c89QuS9tu0Uffz6rsbczQ6jHcdt7CQcJBlwGfS1xQqVhLPX962zpeyAlFXrlcD8D3J0dO1i8 a5oPObHy1S6pUrL1Kh8n1fK0j8K9Q+8kMG3Vg5iirhxr6vvAhDCGhWZNCWOHE4vZ0OwenXY1VqAu jGfe/E6R7ufjjDuCJnYzLINLzO3fDud3NDlcfPjQp76dPr6lRvnDLfEWAXBKJen23dO57zrNOIfh aWlvA15J8kTeuE71Htuy3JNrdH+I3yFHHPfgjFkw7JGgeNsLkdBcni7/d7DJHqSzZPSTifMvBpfG qKNf2ipFBW1qaq7Ui11MPGPh0BfmVHbnCGdhS1CL48lUaKXv9MB52Eap8omKK8NV3ujWAidAPp8S HJMS7aquFGTQ4xRl/RQwyWItKl5AW/KZHPlYGnJZmiKxlJz87n55GDZzoLFiTgH/0hgSfA2SaXfT sG/8wAYemcuZ00nOGY+P5VmEvZuEzjzZmhm8yOR5UPq5xvZQxoh5bEcP94Y4PvFS5YobTLWjhfFS ucMeXObpMI/WDfwWBaxo204fYQcFVsaZRAYuHglD/JfP/wv8bxRwJ4I4Ko1CwlFPwmD/AgJLcCMK ZW5kc3RyZWFtCmVuZG9iagoxMDMgMCBvYmoKPDwKL1R5cGUvRm9udERlc2NyaXB0b3IKL0NhcEhl aWdodCA4NTAKL0FzY2VudCA4NTAKL0Rlc2NlbnQgLTIwMAovRm9udEJCb3hbLTYgLTIzMyA1NDIg Njk4XQovRm9udE5hbWUvWEVPWkdRK0NNVFQ5Ci9JdGFsaWNBbmdsZSAwCi9TdGVtViA3NAovRm9u dEZpbGUgMTAyIDAgUgovRmxhZ3MgNAo+PgplbmRvYmoKMTAyIDAgb2JqCjw8Ci9GaWx0ZXJbL0Zs YXRlRGVjb2RlXQovTGVuZ3RoMSAxMzYzCi9MZW5ndGgyIDY1MTIKL0xlbmd0aDMgNTMzCi9MZW5n dGggNzM1Nwo+PgpzdHJlYW0KeNrtlGVYlO3X7gElpJEOZZR26O4upTukhmGAkWEGBoYGpZFO6W6R VEDJoZVOAaU7BZRSiT0+z/4/up93f9nH/vYe7z1f7t95rWut817ruobtnq4Bj4IdwhaiioC78wjw CkgClLQMDSUAArz8hGxsSkgIyB2KgCuD3CGSAAEJCQGAAsoBIMgPEBCVFBaVFBQmJGQDKCFcvJFQ B0d3AKcS168oMYCCMwQJBYPgAC2QuyPEGZMEDIIBDBBgKMTdmxcAUIDBAPq/trgB9CFuEKQHxI6X kFBAAGAHBbsDbCEOUDgh3y9PD+H2CIDY37IdyuU/Sx4QpBvGF4AT45MLgHFph4DDvAF2EHtCPm0E phoE4+X/2db/xdW/k6uiYDBtkPOv9L/69F+WQc5QmPf/DkA4u6DcIUiAFsIOgoT/O9QE8rc3LYgd FOX879WH7iAYFKwAd4BBAPx/S1A3VagXxE4X6g52BLgjUZC/ZAjc7t8eMG37ywGfqYqOuZoe8O+J /r2oC4LC3Q29Xf7J+iv6Lxb4zZjuIKFegMf8vPz8AphAzO8/b5b/KqYCByPsoHDMmRARBYCQSJA3 IeZwYEgE4CsAgMLtIF4AiBfGMB8vHOGO2QLA9MQfYI9AEv4ap7AIgM/R28URAv+l/y2JAvhcMGNC 2P2WxAB8bjCQm+NvRRzA5wNBIn4LEgA+BBzyD4vwA/jcPX+viwhg2BEJ+SNCEMBnj0AhfwtCGAHq 8UeEMKYspg//MMasG8TjD6+Yb+b7e4z/KBircOifRjBOwQgY4vcmUUwdVxTE7dfF+i1iciv8JszX qPxDYhin6v+QOGa7wT+EOdR8oN+EKWb7mzBZwP+QAD+mJXZ/IKYjkD/wVzv+QEwVhz8Q0wrHPxDj FvoHYkw4/YEYF7A/EGPD+TcKYGzA/0CMDcQfiLHh8gdi6iL/wF8T+AMx7Xf/AzE2UL9REJPK5y/8 r/dDURHh5csjCuARFBLCzFkQ03Fx//8zzAgOxUzpoTLmKPHziwv9fT3AKCQSAnf/6+8Ic/P+w/ZQ zDWFQLwgYMLMLGootjX3HeCJzTF66r5J09BHXcLW4v00kdM8mpH3h0QwXN7pJ+GhTrrHMyQ/dnWj U885meUiagO0pOLRp1Zd3t4Mr+ZoHtgPtDxeOZGsjNnkGaOsN8fha/8CiX5n/fg1ME/E1wqXbP6r XZ67S9tRzz36hp9TfQFts3avzIFtH2Zer0WuN2NJgqdUPDUSgdnWpzV48GElO3NKOu8aQUp/5yCh 0Cujb/I8Rk8n3qg7rUFSMikizpzPgjQpzZ++DupeZiRZ3DJu+Kai36/eqWEyH6L+o9Oke1au9v7y vbgJp/S66ezKtyX2lAcUNzI3vWhKCz56MS99zNrrshWsCs9HVi+lGDyIfnpMNP/IeqRh8DLOrQfJ Qiu8ZJPloPSFApsM4h1EJOr3EC+jY9LEBj0c07ERANxFtjlzepMbBjBq1LNCGs3UxlnTg1g4zLmF CZmo0Eqcg1wiPbIrSLk7GyI+XHepwuRgVBRqvrJ57rhA/qKOgxsVgloOwfjLAzh9L6/LidxSDbze LbRMnL5sYC8EtT1z7CWdJwKulTYfHxQwdYritwewGXf4mrFM11zccLbecZc2+tp8xhsJSn/8Ucb1 Zl7o23nz4Fl8N4+iqjjim2F4zTkhvfI9PIQpry3VR6o/7q5+3CWdib59OzC6XFYepCZf6qfs5M2D k2ysiP3I0qgplfS7/9DUW4nTe3n6YwTmd+0DQROvcDj6wtxY97eCTTMl1sf0vflvDZgT7DrQF2mN MoLUVpWcPtcFUQ/LcBXWLvYBZxXPB4Q83ixzXxuUJs2KCMN2H1wIcw4lUfa67tFTsHHTLwhTG6dn VLvTvtQN/VRotUlpcNnZNyPbufCpovZtZvragH4QdVb7G3NORIzTt4qFuYG53Wpocu1TxiV/8kPi JrWvP09hZDZxnOxE9S3Sza2NLc37WYIsogVf174b5lmqe0/Meqxgh0TOhTaCuwy3sAOKGNLTegDT AM/7Rr056wktorrr98M2zggyPgouSFxnyp+xnW8sAd2fc817v71g5PX1oL/18jCXWY6wJzmiZjxw styCbTiYUJ/lI12J8LHrmVjzvbsaNz/WxoT5jYxBtanDzMw7J3qmDy4mPWVa3ypqBrpTHRKxG5iF unadzLqyu+Zt1RtdvP9e3fMsq+8LSGDDdnUCD04nQ+RAkR+B94ZdMVNZn2Hi66pcsbDM5Uj+vIzb 2dzd8qpeRGTOQq2zgkGwlvmY8EC6yQ8RPKKIMCmV13zWRCF02VYmQUDcDBru+rXxG7jF1dsyh4lz e2H2dTxrPQuI+zpocFVVXlZq2QMV6LWXjI+HT9eXqJI1yifMvI8dmF7kyGwNvMYn4wdlutdhCYv0 0tTCqoNhUD3iEcrYCwN1zl2+xfah6cNejarLLg8fdTYBn5jzUFw5V0ULLaemjtnnQSG8TCTJJRSq ZGqCoMckObGRY+ZR2CFjMjeUtO7n5XEvPh32V7Sr8K4vOar7UspR16IXyuyrJ600NpmkGNeSYTfZ PN1ifxbyiOlzSrfz5COqj2oNgx+05jSS+ilGD/UCDdKNU5IycgjFbET0gU2rNeN+THd9LQX8RxRV n7jMop8GzNEnscUYsqWqRAekq5sDtFjN+e6zLthuEc59n0nVvSvRWH8qxWLJutz6ZZ3pVPkBrQdL WrZTk9fTZyfhBVm3MnDQr2gAjeD+LslGs0NShzOBRAKVbCLA2sxGws3jFQ51mERYbLxCmrh214gd h4SLbjMrWbHcxTuZp9Mt4U7xjV4H1QEvhQ49CH2ewZ5mA8akPG8L7Ci+YNQlp0A6uJh7HCtxm/w6 LPZi+zve2wSTnGjISj96akdWOosA5d8ShMg/LzfaEdWYlqt4FnFf8qeqHOF1RSP5CaIuhLTt8MOK nP/yUg4/0/YQ643R2bHHISMFRBFYqq/niS4pltf2PEOyh36M5zZ2JtCKD6R757lWcOFrzKq6NyYF Gp9bcUgd0u+uzJvjxRunqLhTCTNUh5tzNOHPbz3tTj8pO7q9LpKMEzl8J0sjO0/z6/OurfTJR4lq gJxVdXoArYdqDj395TDlzsWCwBO60RjZ8bDumR6R59y9BiYzL++UjCaMvSOEXrZxVFEXs5jd17Uk WYVZTqTF+wduKDPsj4SDFQLuTvmSKJK9UWrnFNK4GETyihNT2zywCY8ESPr3cJ7+JFhFR7Sv0eNd vXdeY1hiDLyj0Md2ABGf0gBGfUZL2m6o9g59ecVws9fspKWrJtpuOd8ggf0zN1aoBe7P4JSVHTCN wTl3nfyF6KCtn1HBSFBu1VpKaHn2bPL4h74MPcWuD1aF16KL5AnWd9I9xVOc/HrZ6alSLZIbbPdm Rvoyu2DIJzkaeceX8ThnxQwrO6e0lViojI4QvDbqxBZQu66x5MQrsil8H2o8DUq/Xun+1lzI2pe5 JhT+DNUs2fySSSZwtyfzyPi8PoiNAtcvN/hwWAQtuGgUqIzG873kLeCUg4juBi1aDT+7E1Il4L1w lSnKrlISBg1xAzSO7nPX3pJ8//Gi1Ff6DmTnDbCeGnmbDUBOfopuaOv9eWsVN5eWV3zJi3haiuWi 6lUJ6cIbRRFJdFaDX88iQrPrHT3NJzGVqNYjSI5mU+f1mrUfu243jrGJ2VC8I4fswrLTLl979id0 +ZqDuZLVOc3GeR+B4Yu4Jy0DqsqfgLlvTj3E3jVR/GgVDOfAFh0hFfZ8RkETFcZVsS64slZKtNbQ 0sHfWqZHgB8mtqLdSzBf1B9gRD75/TaDR1RmtqGddG57JdcGDz+/NJCkfKIvGSjROmPUW44bPlkt rMvC7ZCl19S43lwjbk9C5Ifw36iU7C5RBI3TW+0mqjnGkRHi9umtVXLx1/L/uO08pLHNeVqaMkCJ xzeLNPvGh0Z9lckgxheMEDgHCg85tKfh+4tavrnd06+/CThIjKFibtgxnRvULvOmRrk6VjVj1U6d Bcv2Zju0zto2UBrfVSe3Pl9K2dXo2wFHIwtNmpUf3PnMfaWHMmte/hR/PdFzc248Z1RrdT3NEvpE uvhZ1JUnHX2LYEZh4qq/ZkaZgbpYKlVbwJ7LRexUl4y2g90qiVW0OQyrYa+AXfVEPXSERiK5nRaL m3hutf7duOWkLrvI/tezrCfwYzmfib6bUuIqksbKDVGr1aaPpON8RkyCjrdNBQfeop+ofmKRcBOl +hnqkFcjjv/WfHpnlMO9LwXrcNCmu5b3PVij1qcluHYl21skUSso70yqS70rVS5dYU826yETFUtL Ag1sPvDzhzDOouXq9UnOvTDDVJNiFdUXbmzdvu3VQC9XB0Bj0ycVnKIE27162BOdQgc/xrvqJ8aC 2iRHjjs6P1lbxskdcRW/7gskJtFASI+ajF2bz+e9ko/75URm3i3PF35viNdC51ITvRHcXLM0VQ16 sXf9QmyCrY1pXVmyoDwWtDqjtBU1FfDCGufZT+zjmnkr0LRTQkgcCDW02KdurmrlePzoXg6P+eTD bE5jz6e20lNf1uKAKXWZKTpMomiOiia+1NySqgOI6jJB/0vIWeXruQbH1CQeNZq6ToTpzzOcJPeI dy9U+tLuuQ6ahUxv0s8Uiah/lyBnf9sZ2l/YzCJzNhtrWMhMZPtu7THimR5ZZIWi9+s90AsVHJr1 /OE4j9UT43B++bWE+d2ynLlDAaM3WLT720ZceYrg294D9QW8iWWl9waxjErEjxPH7LLgnwYUD+3t W46fTdqstB6PZMD6CR/RX6NYzwrlrVrurQTOCL/PXNcouu38wN/jBlYrcaD15jpzAvHrOjoNkoze Hab7ThRvxaXieRVTfRM+bT1bJt1PZQOXAQopi7xp51n0KGJKf9wtLJFLAs8AsU1TcPTtdD0DMkXj VBjbQ0KYR6E7+GBlThvdVyTcUew+khmZy08NTrQVrLmz3JxLbBJoQ6kY4Rwdc4Wkh+gqbBSuJpU3 rK6+aJI1dAXv/vzQ1Zkl1WLRGvdVOFeiYjAvWlyUhrix8Z0YVSe5hsxsgC0S7+7UqtfMQfdwphx1 pQW4arsz1sInaZIWnLjeoUPSt+vkS+/4WEktUnM1yXk+9ipAvVNIiCVKNzMHx0tlyPB6an3BTbCN UGJXdsax7kO25ek0Ywjtw1cZjfnQJn/zkg/uRkQz8lankBhsYlM0UDMKdDzx8Pu0W/VOZc51HA7L U975I8UYt8SmraE7IWvCkqY8ykd68ajTQ1YF5ye95ZPiIt1xNDqsk7eO9rK5Bq0iPMUiUtc4GPpM jAmi5DeL1eLIagfpOopDDCZ8o4490O7e6Za18WeNNQg6lPdAy7fX97M2u+InahNXHTiXjrGvKJhy oCNKEj3AMj1iGi0hNzei8R+z573k5xylXmv6ZpdQOWLW5QlUqtdJkOtZuT0LMRfg7iZQv7/LZWns Z7aSBWlfdMFLpklp7trbhM1+upn8Skf36GmTEdjItiiwvCuJzFDakpT7XFjmWeMkZbphJr22gyO7 RU28UbfqiP4cKz57WvZI1/b34vufLSe9PaXqN6DGLK1+wGVwIG87DjzFlhFmpbZXuZ4aWRUAbTBJ tSBc/DLRxWYfD1A16u00EkEUE4n86GeQgGbJJ2tQV1mabPEkv6TckuZK3MkdnVKnV2nUvrrTlLen vGXbYr6SHLjYtuMDs6glPTu7CIi4U0F1xvumPiZtMSb2Bt8S+XE75YrlgizH1OmlGvjeirZC3+R1 OtdsOF0mPm3edu/C9GDgWClF+McSGYdPaXdIVz45UnsKmikovWh41xfXaBx7AB5D8VGbb72XnyFf eGDeRl9sENnGfflj9o7iW//14P37Q3Tz1EzCoSf3pHjam16rkMEmPfcV0zjHGVuxvPt+XvoROHD7 y34r7T6PWemAc0u4vcNHvzvPDvCZw2taCxr0Iw3wIEt9ea9SF+rTti+smq8ZqBWnYqm2M8o1c825 fc/Fl+yxRCEpVdjspKTFbufiQI3H6oGbD+7bC71gW4ajGbbu7biqAnbLHjev4G+deqKL0aU9BmcR QRGaT0EGRjryY+b9eUSNSDkLsaUI01eV/KfigRmUwPQgfIY4CpsbHqqPZ95GpOJ6/uCo3p0BhrjR Mdk+udJ3WqdCWzvaWFVQ2aS9lxJgk6nk5IhaTviAALVfflM85cr/WE6wbyc4is42jgb5bGOJtnZ8 /xI7DJJ8abV/pi9mx6SXhcIGnqUvVbl4M8TFHrXPUxTzlgvnPgfpzBOZtL0pL8BufTWayMdYYTHS xNAZZoad7VAQDM7iTLbYmu16HBkeds7NTI2urbY4GsAyiXC9ycpuBPc+5hX3eVrE8IQrmip1lKcW gdaMpvIbqOCvnyxaz79OXe7ptkoChYWTOtKL0kwF4js2Qt7Mb898H5oZmUl+tnT0RK0jF3frY1rS ex2NZkkUaqkkhk+yg/+Dl2R7uYNvcMrgJ63IytSLm5egfKZehh8XujqHiSsxpo/EBrVfGN4oF/Q3 V9/b1PhRpQHvB/PdGLT2QlJhdxnozy5Mdo3EjBmMpDFDZs4H3Kiy7W0GZCqcJA/z/cVvuCSJwyLn O7aSHz8hanuMKwavmn01qnVLieJ2qsC2xqFgraPPo/7I0EPMxTDAXmEYgpQ/BHpJmMiV7Awp6dHl DpPUcHCNoz/s7y2Y/OQTe85COzBgjNVM6j5iZkmr7XzqmW5Ivdf2VeT9LbFSzs7cbymTP+kFj3+q XFWyrCDmdFGcNblMT37c5o1sak7rPIiyhH8wGtPudzsbks90TBo0ITHwV2PfqogKdR+WM/JqMHkA M94mmDJwk1XQzbIg1y5MczFm7r2obvHMeyrHGtD75ocJP02D4KqTdz/R3IuL4569/vztSoJCp2AT 6iXVdxqbmfxjO1u1s17ke8xnb61zZ7hwtHaV07khdTykE49NteBLKDF0QkYtIXH6Wqd+S5adY74u t2wvDrfi9bjqa00pZsKh69o6ReYd3q+yVKMDjSymAkVOIs2h2Sl5uhD299OTJvIjYhp6wfho5TGc 6dcrnEvg4SbltNKJLL92UMGHTY1R8Z2YexPRNPFjraKh2PmpUOY+epvJAR0ZOPOCzTt6Q8pRyn4B ssgPOOHE/T8Wix7XRDMSOTJFltZE5Dz21bda+moaD6gSouhOekhBIPh8SxhFSitu56qfQ+rqReVj UwzdV2t+uHIlDEgtqc31Ylh9mHnEC+ZAS1N94zjd8o8nwSbjtb91IxWd0ujEiheyQMD1tkk+uZaK 8/rpoRgCK9jcnUGQkLpMYjDQo9jbNKKqHJL+RTi7YvSmjCebVUHc5dtaLsocI/eWUWQJE/AZmCkJ i/6VGfAEebMqIkNfsjHmkx9FSU36N5Ihd+o0Eu1A/CcjwzO9liUuVG2pOvROwVxq4au9cT+axR3X XjUO2NpZfk46+ZCcdciymJhWK0sYoRnVG/ruBvG9BKCS5UIEeVU6v32CHs/s4RO88+o5INMjIqYm W2WfFq4x87B2w3zwZWymchp1hwSwnP8ZI8mJr0/PjvqcmJmTTDERx/EY0+OOfH2Xcytnw7sBsMXs 6RVnIZM6ITnjPYXxGKKyfDNGVo3TPq+fIXdcWuWrhg60fMIjDd1s+/Q8NYpMLtu1yifvseL2FxZ6 UgobSq8Mr/QTLCiJzBmird82pKbJmxjpatU/QO1syoyts71XvHVk/lkuTUftE2iSQVMwCH0Z/oG9 JrAF5Nr5EE8xecHp4cHOGHvVCSlfkkRrD3FCqTBI5eFZ1bj5S81Zwp3Dr/nM50o8SpbEhXQPrkq3 YBY2jFvfOB+7TWQYIrAcdYiaXOAVH3h16+2MCEvFSidR4+TWqidAVrRld+f2dpjBkPW+X7sl9KPk 4iKLIdBQPa3m4uv4shXo49gS/svhDEA0XeZV7+oWsQ0XKjVKRyxq3G32hZCpVRmuRHz8e3kb523U ZK90kb6bFm9tbw3xfg1njQHjRJzD0C5LBEotU6ysfyNlnH6P0PxVy+6bhRejafQv48cJzA3miApV ox+VpR44PL2uHq3TpXvtONVGEde97CRJaRkmVR+5M5gLIyXEIaGxLbolpDZ2Hqghr/Ycqp+WCvjk 6MlV12fQx+OWpNrKlCmEWORAVRMdPDiEdRlVQDdmiQuEFB+7SmuHVbNYcIiY3hvY4G0hp3ZEUedJ +VyxnjxPQc5QsOhIBTlF3Zopa9Yqrq4cnUdvWW4UmNDRvd+gCxNS8qeki/EeiHv4/QBejo+zTuBC 0qupd8GEZ1XGw+HyDF7neXQWCcUdg5+IXMk2fabf8iPOlayImQeRorLSIzN3R0YNx0Sc6Ds2i3aJ o3FF78Bffbw7nJ38SWeTlqMZ3z/koJvxlvkVa7eUTnVCpLvtzBusLPVY264l1hsXxru1PJL3K/H2 Q2K7OegfyjWy43G+9PymBzQ2fRLtcxzvL0VLZWbrADtOjIZlKtpNyr9WJLW1iNZNOytjZnVrDgms 0GJePCPuo+1x/ijN/+JpV5ZkB44Rf3GkHTTAO7o7+eF7RSC9kDW99E57iiWJa/eDVy5Tom9buowD Rvlf35cRSTHQOSYsHTKXnbihdTw++aldN7Xz24ARbIRx+WSjTcyG9JocaJ98QaeX8Q434vtG2KPN UWNy+VXE0cXkYNjuT+vPIopkwc4pkmUhmsN21QnydYb60KnBWIc6MJ9fxKMQsxWfCx2CTjWRStzI U9inyNihfFbrWNMv0nyQp3uA0ArNqxHbBA11gY0V9xjxPUFlV9sIx+xtRT3kAfkcXcmYHZmQ4WRs 4+eUqF2h1INg0EFoTb7+bIEbmdBD2qBQPcQNipFYSCxx6WrefLdRyMuE7zjWxQmFWU6nIABXj1Ot 6lII7u1IXKubAT+l2o1caRsuiEGNtlp2WJJyVlCceN4xdgfYJesKWxG+hmuSNQNyG1lpUyxl2PNa gTCft7j43f3wB6ffHfK18IdSzm49bwQdYHPcGzhPiie2WclI7epXmZzLkhh3WkBddfPsG+XCcwhi hosEZ8dc/fUq0tsJeOLeRZdFxjyQ4dTr2gKwffgx7ZDOGz4joFTevvyJJYl76n1iRbD1D78CHTKP 8MPIaTVm685B2johM4VTSclC9W6bPLegny8Fv3OHel3nvuXnTTtF/2C5YXsmvFqwDpui638zLA9a 7OnNvGvP+/qmiuyIL3Gckl+uxgcx1MNj2RqU/oJ8wCD/SMoHYWqL7HYaNSwz6dkExWj5XNYsrL29 k+Fkykh4VD8+vv3XzeGYs4XPqEIuge7QIdKGKhVrvOq5eeBErCh2186pch/9F0KaFdydelLUznmL 9qTr2QTDFkzPFTspY2pvYcoCXZkst3a9+Wh/RIcdPa19GpqWNePJW+fzc/2lWv5GaLKzJSRJa+5o 7glj2BGplooTVR+HiilcU9tdodUgH9qx2ME7qrdVKiVQRR7FinWwmmzVPCerE24vbzqaFa6Vv9xD 7zKh2SI6AVf06QYeWSpwebAE0iaCE6zXvguUXXm1LoLc4iDFns4mqwDu4r5Qko8RRPerGlm9m2Kl /JZUlcXYDR7tZTl1knuCE7zPuZ85bQUI+I5Kp53GSUUN3h5ZIJXsSZY7cJaOHMa5wNVB7oMdo7gW mojFHA/Rcn3h55Ctt4NOsZFy+wMso5Iyd3gbLpgPpahYwUaSWYWbllnQm2o+PKlmb2L6ppQ8Hj0S M8EbRhAnmSX17pKzcMk3NwZG8HXaJNOdM8w0bq7rs+XN8nAhBmj4kJcs/VPOiRsZBvz/nw/h/yT4 b5EADIOAkO4IZxDSiZDwfwGvXc9YCmVuZHN0cmVhbQplbmRvYmoKMTA2IDAgb2JqCjw8Ci9UeXBl L0ZvbnREZXNjcmlwdG9yCi9DYXBIZWlnaHQgODUwCi9Bc2NlbnQgODUwCi9EZXNjZW50IC0yMDAK L0ZvbnRCQm94Wy0zMCAtOTU4IDExNDYgNzc3XQovRm9udE5hbWUvWkZDWURSK0NNU1k5Ci9JdGFs aWNBbmdsZSAtMTQuMDM1Ci9TdGVtViA4NwovRm9udEZpbGUgMTA1IDAgUgovRmxhZ3MgNjgKPj4K ZW5kb2JqCjEwNSAwIG9iago8PAovRmlsdGVyWy9GbGF0ZURlY29kZV0KL0xlbmd0aDEgNzc1Ci9M ZW5ndGgyIDY0MAovTGVuZ3RoMyA1MzMKL0xlbmd0aCAxMjA1Cj4+CnN0cmVhbQp42lNVDAjWdUzJ T0p1y88r0TXUM7RScPYNjrRUMNQz4FJVdS5KTSzJzM9zSSxJtVIwtLQ0VHAsTVcwNFUwMLcyMrIy MufiUlVwzi+oLMpMzyhR0HDWBKkyV3DMTS3KTE7MU/BNLMlIzQUakpyYoxCcn5yZWlKpp6DgmJOj EATSUqwQlFqcWlSWmqLHxWVoqJCSmVyikJSanpnHpQ9yk2deWr6COUQ4pbQAJlWWWlQMdJeCBtCd mgpAV6bk5+VUKqSkpnHp++UDbUsFuoVkZ2FxFbrhbqU5OX6JuSDjQeGEIZ2Ym5lTCVWQn1tQWpJa pOCbn5JalIeuNDwV4jbf1JTM0lx0Wc+SxJzMZMe89JxUBV1DEz0DY1OIRGaxW2ZFakpAZklyhkJa Yk5xKlg8NS8F3SnA0AM7RD/KzTnSJUgbErEQyYDEzLySkMqCVAUDhGow3xDBBwZSUWaFQrSBnoGB IVAhEMJYsWiWueYl56dk5qUrGJmaKSQWFSVWchkAjTIyNVWoNlTIzEtJrVBIrQC6WF8vL78EqEUB GDS1Cmn5RVygWDU1UtAH2pUI9i5QhgvTK05O+RXVusYGCrqWphYKhoYmZgrm5ua1qApD8zILS1M9 XRRMDQwMLAwtwaLJpUVFqXkl4CQEDCYYPy0TaFdqakVqMtfsOaKZjPE6stpfE74cuKoUvuvEuZsb ZqlHbTKU9DvfNDmItSnfb3rsuXPHtXU+L+yYeeae/E3TC3MbrTlzju2wue+vvHMZ7xb5mWVrjI2S T3LceX92r08L01uGxXkl7cm+HPOvRH1Z3BW2xFHHmnv9r9eF1R/uzf9d1ZKw3z0qXWLDcZtwQdcL alOLyoJZDRb9fn/sxLeCoIq+dObdcU+mGrdzn5IXtLphHnB1+g6nGzdznKwXqtveSX7t/Nl/Jd9y K2Wvz/E3N/lt95dMypuocr/q9KSkOSeqdX7IeHVuKnFvyN3sPPnuBwfNiEe33nF7fxb9uYpLLeDS Q7lHnf/XnXS4sF6M//mnKYIHj0RkXlxjff7ROt/lKkohE6Z+/DP/TUJSp2G+QF7hLK9Hf13ftfXf /VDV8HKZ2m7ns39XzT2r0N3xd+Z6hU31c7NjbmXZr+iNOn+uO+715o4Q8543h/ffOqoW6C/98rfG uqROiV1TtOxYt/dY/W/o+SK29C3jPg0mw+1RVe940jaETBfe923z6YMdz1R3NS54HPNRbd1qk8br x/YfvmfQcC67I5DVL2/6N3Eu5Y1hbnej2xgM90pEplQx7Os+rcVmsWCV8VnzXCUZ08Rb3/6fmud4 QHymcGrzQ5GjT3lXrDtasHdfZdQRlm1en6cc1JxnJJy0KVnF98Zfvs7Q95/9GVwPnryf7v/+Fe8s Dk019cCbyaX/Zq+VFuPNNWfgSjjm17NXWufN90NVrn9VzXWlNTkzcrbZKSqoiwiwfbs+ZVVnW0xv eeothylC6dqP2jLT1/tdLz7j/0pGm2VHzpGGRfbyGsWxJc1OT/r7j4Wdudwz5/vulvTJaXseLnWZ 3aE240iNVac6t/L8Gb9u/3p4+cGtFR9YS34ZUAi4Rg0YFgYk56QmFpXk5yYWZXNxAQCN9p4wCmVu ZHN0cmVhbQplbmRvYmoKMTA5IDAgb2JqCjw8Ci9UeXBlL0ZvbnREZXNjcmlwdG9yCi9DYXBIZWln aHQgODUwCi9Bc2NlbnQgODUwCi9EZXNjZW50IC0yMDAKL0ZvbnRCQm94Wy0yOSAtMjUwIDEwNzUg NzUwXQovRm9udE5hbWUvREhYTlNZK0NNTUk5Ci9JdGFsaWNBbmdsZSAtMTQuMDQKL1N0ZW1WIDc0 Ci9Gb250RmlsZSAxMDggMCBSCi9GbGFncyA2OAo+PgplbmRvYmoKMTA4IDAgb2JqCjw8Ci9GaWx0 ZXJbL0ZsYXRlRGVjb2RlXQovTGVuZ3RoMSA5NjcKL0xlbmd0aDIgMzY1NAovTGVuZ3RoMyA1MzMK L0xlbmd0aCA0MzQyCj4+CnN0cmVhbQp42u1TaTyUb9tGlgyyTpJw2xr7zJBs2Zcs2ddCGjODYcyM MSNrska2kCWyZEshZMtS9qWSraxZsxSiiMj6qJ7/+1+e98v7e7+9v/e+v1zHcR7XcR33eV63ML+J uaQ6Cu+I1sHjSJJwKbgioGloqKcAHC1hMJCwsCYRjSBh8DgtBAmtCMAVFM4D+mQsIC0DwOQUZWUU ZWVBIGFAE0/wIWKcXUiAiKboT5UcoO6OJmKQCBxgiCC5oN2PTJAILGCOR2LQJB8pAFDHYgGzn1s8 ATO0J5rohUZJgUBwOIDCIEmAI9oZgwNBf6bSwznhAbnfNIpM+KPkhSZ6HuUCRH4lFQWOcqLwOKwP gEI7gaBG+KPz0Edp/sfB/ptc/zTXIWOxRgj3n/Y/e/UfZYQ7BuvzbwHenUAmoYmAIR6FJuL+KbVG /85miEZhyO7/rOqREFgMUh3njEUDkvBzUrBzv3mMpw7GG40ywZCQLoATAuuJ/sWjcah/Jjlq368c UC1dGyPzy+K/Z/u7aILA4EgWPgQ0APtT/QvD/8RHPSJivAFbmBQMBj8SHr1/rOz/cZg2DolHYXDO gLTseQBBJCJ8QLAjK2lZWcAPDmBwKLQ3gPY+SgyVwuFJR1uAo84EAE54IujnWOFy5wAoAktwQfzk /03JAlBHNOmvzHkA6oxwd/8rJQdAUWjs31TyABRN8MRg8Tj4X1gFAOr7Nzd52JHubwQcgB5dir9R R/bemP/C548CaPyJjoqaf2phRye4/4L/OQcNDby3n6S0AiApLXvUF9jRt8nJwgL+LrTEYTzIaD0t QBYmLycj/3veSDKRiMaRfv0ARzP+Azthjq4FGu2NRoJunvMJLlLQGIVNYx4yMenCeYhXQ5jOeO0+ kGLTxaXeTyW1VEG+JlgLeBMgG1qEd6FnJc4zTk1Mnbc2V7SuP7kF022s36tRRFOHUlqo73fJlYzq d+0OUEmpdK2B31XW+wWC5eMEuhGpXz66PM/qqdDCzRWOQ4begIXC5I02NxODDsc01wcY48pu5/g+ pbS9bljOVLz/RmaBmTNaB2zO4VoJeT48xmZukO1douxNzZHIlLc9ePvFvvZ71nSWZbWMkZSECziC hY+OvoHME2V442LsgXAW3VYSlVz9k7mtauODQkVy4EPOQUbpVAWR+MahE+eyrcqGqHhy99OjKBu9 y54qty0p0dKAmYCngT+WHISFnFi4RoNz5vyHW3jnX2WOCnjzb/d5cCkEfHCRb+bxk21YaVOhPHl2 lmJbKHNEZ7iq+3kklSXjGOfEGvsUOq5cNcjRhYXdywXpbbTTLDLN+yNlJg8GF9vp+jaqu/J5eJAe VNWFquUJxN0Uxp/ge5nFSlVzCdGtjZPiXvm6ABncYvaMS1Zkd0LRtPM2Cr6iu5FiDYKynjJ3S5gP 6+V57tB4Pju/P8U8mgZmlPjA4UIiq8soj4auyoZIee5azbzuPo/gM2ZLwa5njdoMVDeNqyN/gLuc EremyttUXU5COr9CqE7nFnLG664F3R81iLjzqBg5znvbZd2i2hjPeUGZana5SW6Mhk6Ns6ucfdHY SPJspfOXjOwbpcNL/uHTwqVm7T3LIZdNF25Q5caU8mZioga4kpvpeEMPA19c/z7xow//SPzk5+XX 03IMdqPvTPrW77iy2JX8UOkDNQT2StzD+YPnzChwsgpM92p72+8Jr2ldAkZbZ/ZEWaR7sx4N3lxq bkhCnhtT4L4FIvsrrbrmTtM8pY8YufLuNEpNLOXsLA3fB8CPzJ8nl3j6+qUR7n5N6wbdFtcnGe3J H54kSkpMab2Qq2yeEbVFBMZ+v1DU4X87MUpM4MTqQ+OV3XPOXv0Rlp9r7cajMqqLavwP7yoSHnue kEBHCQcWtRx8WFXRU/mqfqlGsMIEe5Gsxra5JehLRS9/k1PfR2p+J4osMaPb2vW6DZHz6P4TVsL7 nUuj2YQrVgIu6n1IWiftaWDXJeggMcvq7S4P5r7aJ73LbLpJtd/KpC2Bxmth13w9pUiZ8PELa8xK V2hs2wNwLnmaHjrKzcSpGxIhr3NbihX5Je5zvlGyUSs0OthuWMc6x5I3v5gGDutGXmD73H+mnufV Zg9OgAn/hJnjPHv3McGmqOMlynVsC4DNRb+vItOzftBTttu36LwE3OyrqJRPORXSSr3ie293LGM0 aXFrWDNLh32Pefqyy/eLftA9OKEfcy+RiKm8KMbt/41ttI3gMFlL4v+UxVC64HQJZ5X0bTxSyP1Z bcoZjxRo5xqFl20vg9mYGMXJVXAnvUrlS6m3rYbhIfkbTOn2SxKgb/z2qx/KjlFwtBbo01ZkErTr ip8TWaHvRKDxQM5Uw8Fb9tTvUNDeyb2AnXsraWmxBZ3MtFd9KQP2LYZBZ+tMy0fQIdPi75eH7TuE LF3gjHeADXc5bjvu1ISxHc634V942AqiwN+vfYTMeFvZ7vJ8u6pQFz/SLrfPjLiVSuFEKAonpegF MixehxVOCdqKlo/ys4ZytsSIlt/a/j5Cl2cWvzlC2Ur0oM2fmAm8Bew0n8D4xnh6h4A3uuLat64O fy13VRB71e1lN7bf5KYWujQsoJ/bIJCiknXNkMmfv3udy2rwTQuv/qOoU54wnYSWt+tR40aiFTJn KfRY17Z5dGbqozfOFahfGbKGacHtPllqtCrZ9JSxRYjtKLXqJ25OJhPN2+F697rsRDTDDYn2ebwV cl2UYbxPBs3h4+BpeMtMNpSmo21JvKlravNWzNDxBJ/xpivUhYWfzRIrziZXqNb2dDTeqRoS0y6j mF8YKA/zq7SSrs8UXo/FyumyYA/WWkYUI+o6qMc/CDKE+aPvZCOES++rKl+9bCrzABnCS1Gsp3uu zijzezphQqLzOXgixlRFP4i7oXqIIbcRo2SedZ3PMJ0iPGVGW97lbIwpbXrDhOCn97sTMwnIRzEQ iW/jNvlP4Z+SHFfLwZoiSMjblNBShOtnCsbemixmGOcBqGNWzKvH3X1IzpfYv6l8l9D9tY6zgyOq +x6jc2qy32cgy6rAfrNz1HKUf9rBUahY5WOaqdvK6pfMtbsDZ5YWnQ+Y18bFKzfOeu89Bkv20l1u mIAdWxUtpGPw9mPGzit6WAR9NabVbKPHkntinwfaPF4X2bY+t3FxhUpP7NkE+ypH0VBx9UNSdNYz L4hJAItGyUJcsFFq2JNs5oPH2OqAcbd5Bm1hHlDgko2GY8/pTmE3tmM4Ckeuyg4tv/wRO7VB48st 8DJqHkq/w6C5rfcTMhwtrdZZVskW2DIrgersQsahdz8Mo4HjMleDbvd1+H+ymmLJuDQYQI3e9sPa lCt3fim2LXMecOvrVc5moQcE4muqpKxSly4aOO55ZHFiEjZE7Ubke3s0U8WgBtbBMMMzTrcUIOk5 1wrezr3zaKMgBNjROJaMOT0ITxPYt8dQTxbGmP2wMjz93fZt8GnuWOE5x+PBap0KXkUJSnvX2cVb HYLZqZ1dC/pv5n1/iPPW1WwYl6j3ne6jjOb8qOvRtLr+qlt7bI8TWzh6tzEz+DBUt7LUX00k3LGp XLGNJZKK9MaUJnR57lno7Y6kZtsbpafHrmmc3uMr+mqVn9dcj2Atlzk5uxtoUO7tYl34UHKCMuRp 5Zlvfvd1LzMbpLat7BifDC6+AU2WH9I9oF8IibwrxSsnFvEoEGF8xlbrgQxP5uyg4IFylaMbDSF8 cUZy9JGXbPOYPkKe76Mn/1xvNqrti2GTTklZ5Rv/AMlsCwiN8npq6JDKfuuCUMprtP/L8Oupju4+ qiGPo63WhTRCZYR3+KnuTvrN1bZwFRBGEGbzYCe1LA2r/uW1xUtng7Un9owMmJPrN+yXUOphak6L bmSKwnQayhtzcnjsyN1EGbVzNp8iYkmGNKa0m+w08h01Tmeey7k2NGE4whtxC32myS6pSUYeKUaj +cZJyTtpgpidBWxkw2zX1qcPcEmjZdoTo6fUefak3xR4RSYHSB1sKS9MED9gB1nqQeaq67T3lrqy XrEWtZ+qmhv5/IMpNJS8PdD3lu6m+9t++rSq9HlayNPDy1NM0yFBd9IM7hVHHMuq1X0onu7IWtnC pdRaLUDhU9p6n1bNRp4Y4CMmUvq5mqPk6+S3FxEVM3Z1xQ+3f3C59hTSMn1A9/uD35VFs3OEOrrA FzgbnuYcB3P80Im5VbJPrkzhD5+RJu+6X2dq41uMMTGzd3bo5H/RcNVDRHQsTVOFPMCypVDyOmw+ cj+85pBUYVEQ0VstRLPuMb3M5W8fON84f35aCVvGek3lZZn3pjpHkirjTAkfmPwC0loaq6EWUMWC zRKYlzEGDVVd4pkJGNalWnXZCqyI4TyOfRgpZJsffKVUIW2z/JnJ/BNacq+a4ifqttsMV240yzIG cSmBLE8K82ZxEzIFd5d6r2UbcjGMqNFw8IMUk3UNulATEWmF7c9v0nu08Q2pPI5zdxbq11jszlik cwgozi0YmOccz0llQHeqcz4Yeh9mx3gsLOCwKUmdP10V4iaRQMk2314zOuKow+Rpc0+vqCu/2UxM hWGyLrjGMr5RVHK0RSK2ueh2kDV6gOviQ8h9YQ6zezMucC+K4CfKYU0vIlyRbYUZCWKor9JSJdqT ccZQ/Z11EQ4Zi2CZ6wO9DO96ZPIzPE0o1l753mWizDBIiabi+8w5Y4N9texDmcMpChKkzWaK3+k5 3jT0QYNsm6DRJpPdXzsu0gcZziLsusxPVI0HEfJmPzvbTmMmOUji/PaCFyeH9hR/OEg5jl1dRDtG 9PLzUjpRdixfG8E3zShnNgSARalvWhlH7vcTXyQgctGE57cg+8+UciqT2VQH914xQo7zDBi9u7I9 YaY84fsOe6hwRhH1pRTbDFDd3oWYrroF3bXoUkreEo8X/wSU+3QPqeSOjby0kufOIScQlDXs45fb ugUPajw0iHvgzc4HHBS+QRQVFAMouOAsDZ3OwMx8p2u7TEUHpDRb6kRiHs44bYZwcUps8GBpcbTs eiifMf0IVb+91Z03k5lzthQXjWbpaDzm1vmuBURd7WvgPGEosvVZ3viKw1gwc+rZngruTF+HKNaL d6pWnmrcXYygN16Si9+lv+n6hT+t8V7Yp/72FPKUEZA3FyPa+i1qTl4dImNFdwhz+uiudCppBiVP 7eHzyrC7pd6C4kGtUxIwwJfvXExbpy/V9kWV0is0rbVPIHz5kojBVaLCQkQo5IROZ6f5hFPldZu8 dqNozwQp46wH7UPyTFmXkZb5++JOr+8aFVVT50zXcmX6Ken7IUy/jTz3n5h0T7+leLr1gqlDdGes sPBuo2S184kUOTYZw/PpFSY8vGp9G8JxKNcz101DQDxval7GUftzIxa0hNq/gITVYpe0wPwJG7SH ITtumYeC3+eq7ONYDjcfaobtjtRwH2Ro+czGqFsjCT0LJUGDc0bxdRDr8BOI4/MNU+u7qs2sAvb4 6HGqM+I6Z1JDff0fIFckH10Ck3dfXinKePZgpX/Y7Gmfa2dN6TMM+x6DXObj+UModM+Ei8oEnZPj CKeiRepCO+J0Rhm1i0LCqWqXYGOxViXhgsv+L19ofH3sXni23MbF6Xz+9nGs3WoUmCdyl7L3mkDb 1v3Huf4RWaUpOhvnlZQtVwsUIB+LkbwnG9a98U8FauhH3S7kMUM+4VVjso+3+AuY1EY6duHJj8GT Tr2OdV2TbTOzu1G2oVOaqICVFUjKBtIjd9y1hlSJDQcfsxZH1q6iciqsjZ55U3hLB6ws1LCsl+9c palnQ8L+lw/o/w3+TxggsWgEkYR3RxDdQKB/AXOzrlQKZW5kc3RyZWFtCmVuZG9iagoxMjQgMCBv YmoKPDwKL1R5cGUvRm9udERlc2NyaXB0b3IKL0NhcEhlaWdodCA4NTAKL0FzY2VudCA4NTAKL0Rl c2NlbnQgLTIwMAovRm9udEJCb3hbLTE1IC0yNTAgMTIxNiA3NTBdCi9Gb250TmFtZS9DUEdUQ0or Q01NSUIxMAovSXRhbGljQW5nbGUgLTE0LjA0Ci9TdGVtViAxMTMKL0ZvbnRGaWxlIDEyMyAwIFIK L0ZsYWdzIDY4Cj4+CmVuZG9iagoxMjMgMCBvYmoKPDwKL0ZpbHRlclsvRmxhdGVEZWNvZGVdCi9M ZW5ndGgxIDc3NQovTGVuZ3RoMiAxMTgwCi9MZW5ndGgzIDUzMwovTGVuZ3RoIDE3NTUKPj4Kc3Ry ZWFtCnja7ZJrVBPXGoYRoXoigYJAdYGyQRARCAmQEC6CSZASaBAIFjlcdEwmZHQySYcBEhCsGrS1 KiLi5bR6QGlBNAhiRa4iVk+soiBWykVAsVVEFC3lYlA7QF1d1fPnrP7rOjN/5vv2u9/vmXdvB9tw oStHLF8HB8kxwpVBY/gAnkDA5zLogCzodIqDAw+HIQKRY4EQAfsAhrc3C4Qko8DdA9C9fJiePqSI 4gB4coUKRxKlBFjCc5pUeQGODMYREYQBAURIYRlpIoJQIJSLEJhQ0QDgoCiInNySBCLhJBhPgcU0 CoXBAGJERIB1cCKCUdwmufiYRA68ptviZMWbpRQYTyK5wJIpUidAcorlGKoCYlhCcQuTk/NgkuZ/ BvsvXG+bByWjaBgkm7SfTusdASRDUNXvErlMkUzAOBDIxTCOvS2NhqfpuHL0nTl8AkIREQdLRGHg yvCk0T2n+0hSEKKExeEIIZICCYQmwVN9GBO/zUHGN0Xhxgv/MIoX4vzmdKeXwyEEI6JUChjQ/9BP 1Yw/ajIlHFGCWDqNTmeQQvJ98xX/1rgVmEguRrBE4M5kAQjHIRWFvEhkxQTpDIBgYlgJYCXJ7EbD 5AS5BZDJZACJHKdMHizLi+ScbFHe/QsuV65Md2Uwgas7k/R0Z7CAF5Oe8WfhKgz5JBnmBwImne3l 4e0+1RUl4ziMEVPXh0zoTS1ByFBhWAmLKJ96qrac8Oa203uRIio1mLEAT9hKtU7RFdDMgrGDXx0k Gr91HNobbadUOA4HKm6pF7uwjHru9LCihT7RNZaj9ODzNROVPrCBekYU56XWS9MeotXd1Kf5a59Z 3DpTk77Jgp1tdw06+PSBtO7f1ysCsfvFXY63myzss9hhv/6au/l1B+/5TaPssh1H007PiE0VlFNP vmzy+Nnkg51BFkLz9Wcc69o6zISh+UrNMqWB+Z4+cXV9aFZu7M6vUlc3dt4Twn6fO9s0Xs43ndl7 blWAOr1i1+6VTR/710dczVgzO/WUk/3hs5YsKLti4QBaE1bYKd3UltkSLSi+Mt7qG0Nr6Nul2snf AeJOOLhlui3o3HIs28MmJ10decr0dJW/54Wnq57oxT3k7Kpt1h0WBBRfZe++YmOp3cafqwnQ7qf6 cYPC61pcBGcMchNflB64vHZIz3bUrH9AJKm8TjisGXHGvdFC9+0bU181XWJv5W7cc+Hi6/Rb2Icu j75soz01tupbX+MTXnReHh9kcnRic9Ba854jd+8KYbGL64Pt7/UULe9lnnme7URVnau2/Km2IKD9 4kDmt8vfO+liPXSe5euL9C9SpeVVwhaz2Hv/Ezfq0bFxVsfuluKW7nb9UXXKR7KRieaXS2Yv+0z7 Eae0BHVxsSrXnz/8qqQyod9gmLGyoao7Yb/hSntcs41rPtOCHaUnRcvSDLPa7UpDrRxKcVrXhpBX hsy1E/+6Agpu6nb9w/aSyz5pq6D6y0FuXzF9O7cV2jZI8eWN7Cns+qZm6Vgdkl0x86W0Rzh4qXe+ 2Q29jFbromDrh4H1ZqsV+rdKdCDk0+QJ2Zjczv4wdEdtnDmWtK6Nxhx++Lg3MK+U8yRO/3bJC42X +XzmtrTtCl17/6NPHmT45cYJ3zeUzDxSteHYFqslodz8eydDWufZDDldn7vv4sKUfacfDGd4fjef QmtIuMpLDS29XrFikYn0eGLVvK195epm+oV5yxQZNi4dWbe7D+SG2/t3Mw7Fpy7yo929V2YkfGJk 8sgocqMCM+XGjOfkHvmnqnkgbMx1VGdCeNb72jurTaypT9YXHN8Jfsnrr1pmZlXeex+UnPJ8fNHs 8/r8A0c/e117WLsmrzJy+OMFmzcVaQ7Z9s4x/u7qkWfseKPBpsSQHLbpjtw7VDdBRPtTOw4jLqsr fGT2XUVDfqP/XFXUoaHOOu/Sa+bBZ8ee9Y3Y+SwNcTo6brzX2r+4PCFCPNDAXWNQGeMnK6g3H9hS Rhibhn6Rxte0KW8rYMrCYPVPjRMg3DDGMoe/otCv5mRy576mtPtGVCReRNM2VIjVbcZz7G27aseF 5wYOzZZE8jjtAll5xoWxoLkeVE308dTo+MsP0d0rxpfCZ2cV/mInvjbPr/L7WKi5drnb+ImI99NM f6y6gTvHr70idOiu/sBRJ6GjDqsbqhNzOJ1di26UHfMfy8l9XtGSkOkFfb1YEuBcv36/dQ/Ktmam GeWZJOsFUwdD+vwfx8R8HZcwZ0+85WXOtWN2Ua8EkBhbbHqwhsJyH4v9YvkMjdaeOwPnj3/v+s1I hOzs6VBlwA8/jyx9cY8DztN1wxXPcIL+Fx/K/w3+FgYiFIZwQi6D8A0Uym9/OZrNCmVuZHN0cmVh bQplbmRvYmoKMTI3IDAgb2JqCjw8Ci9UeXBlL0ZvbnREZXNjcmlwdG9yCi9DYXBIZWlnaHQgODUw Ci9Bc2NlbnQgODUwCi9EZXNjZW50IC0yMDAKL0ZvbnRCQm94Wy01NSAtMjUwIDEyODkgNzUxXQov Rm9udE5hbWUvRlhQT1BCK0NNQlg3Ci9JdGFsaWNBbmdsZSAwCi9TdGVtViAxMjcKL0ZvbnRGaWxl IDEyNiAwIFIKL0ZsYWdzIDQKPj4KZW5kb2JqCjEyNiAwIG9iago8PAovRmlsdGVyWy9GbGF0ZURl Y29kZV0KL0xlbmd0aDEgNzk2Ci9MZW5ndGgyIDE1MTIKL0xlbmd0aDMgNTMzCi9MZW5ndGggMjEw Mwo+PgpzdHJlYW0KeNrtUns4VPsadr+MbI2QXclyqdQYZjCUdmFkhI3JnWEyZtaMYWYNc8mMS+3a W0WSRNluKWwplIbSxaUtKVO5p8RO5ZrcctmOSZ3B6ezn1PnnPOe/85y1/lnv973f+73r/f026eE9 kXYUVgiIY0FcJNoEbQ3Yu2L9rAC0CQq2aZM9GyRx6SxoD4kLWgPoHTvQgB2PBpihALSltTnG2mIH DLYJsGdFCNh0WigXMLLfusSyAuyYIJtOJkGAK4kbCjIlImQSA/BkkekgV2ACAHYMBuCxNMIBPEAO yD4AUkxgMDQaoNDJXCAEpNEhmOmSJyeIygKsVsoUXsSX1gGQzZH4AowkPrcCEpcUFsQQABSQCjN1 Y0m2gRIv/7Gtf+Pqa3Ecj8FwIzGX5Jdy+qZNYtIZgn8QWMwIHhdkA64sCsiGvqb6givesCzGN1uc uCQGnWwH0RgggFop0Tk4Oh+k4OlccihAJTE44HIdhChfW5CktmzAFOeHd8djESsHutLEk+gQ10sQ 8U/ZJfYyRv+FJeGw6XyAgDJBodASouT98hX01TIHiMyi0CHJlcBYAiQ2mySASe6GBGGAGDRAhygg HwD5EsemJhCLKxkBJJHEAVQWG7Z0mhY7AFMWBC4VlzEGBZhyo1h/YbQEh7LBFca3/4nFsvgxSMky pJlkFG22fQdghUHH/SvRG6JH8kCnPRJ1FMrKErNcJfPYbBDiLt8rSYZfMJUuSRwE+SAZlpWtSZfe b6yDmA2eqevU97395BkeVl04loGZy9NqfjipwpA36Qo7Fh+On3muujCKTzo3b6Rrc7z8oOvOlLo5 Yr1AsK6kR2sbVXSX8GbWuvTkELJ1TWWAjGntOJh0az9BiMjDxBDl1Xo/UPK4ETVTDXrf3xB3Nh6s eUEpCUDUPHou7E8cuCNlTe50iHJJReTsn7umAD21pwSs0RZcM1sTxzxiHv/Je9oW6X2ovWJv+FAK vHW2tixQ1xEanCSWtzWNbv7VrzzNA36ufByZMzBrEWL32svXXaPAE4E5G392IhpYjSwNSeM1B4EO 8R1NJaG3Y0w/rF9tnXF1d26dbpm2ktzmm7tCRmxkjZ5G8Ya1M/7wi2sRN48kWBQmitcV9CZB71vP cHrbgwuHA3tdeAhTxOU1FYlG+hp5PmZtyaeJj5QM9T6f0qOO2DaqG/vZGBAWlU8llqjp3MkMIchU H8+gU92m4qlKCVmFys9Gk59SAz5aFPj3Erx6ouBzk85GRzQm+j2ViQZZU9nt4RFGHQzFi1X34hyQ 8eR3x/PvEokXM3OLi97+cph2PsEmNyzjB5G3ek1HSeHxY2c8aNKCcJumOnHIXDa1JTR5rO/Tor/a 3RGv60/arjyS5qQoRhvPzS3EqV7vqbh2dvcu8STidU9xU6vcdFtaeusZK/HnXi5x7dahut/sFttr sfWqkT4RwtJ+9706Anzk1HV3d9lXszmna3NoJxyCu7eUHmGcfzj/JNPcbK8IUKwogeUiA+Ucueru G9/88N1uqQBnrdctogu+5z5iF3gih+vuzYlJMzrDfeTjlX9Ll3PA4eoNg7kz6T4/fkzsCkjLvh/1 ftJGHn5LJYzrcxPVrBy103vP3Pu1xRcEkW6Ob0bh2OdShDajqwv5vPEu8XpFAsqghnx0+qeAcfmK 2ENW3yV2rIYrHD32YCEWAe9A5G98nDT/wCihXqx7KttY1PPEUKuTrnCgZkBzArDc9qdCYhJfXevS 9+Pd+30I9OKahTsPnJ30nZiYGJIdkx+IbRtSai66PTM9Phg86shr+rAadFnl45+ZPMbSqLTN4rj7 vnwFcnQ3krLRYUkyo5HjZtvy6/tj52ZUH6PstHdP/u76u4mm7MjLxmjl+mcqDYdlPRhBj3H8KWOX vC6Po/g9sWZC/Uvd4vDJ9pTTDIPP0pih7nLyjURkWr6G+akqKwWDzXVmfVNVqdeD/OsWisbemXP2 N/jhPMYuSJ18eEIs6mzBtc6zbt2fIHJkC6aekqS8xMDljGQLXPlJZV6T74c+k5HWhMYFHasPv1b3 FGjAp43zUktVHG03Tl9qxxfp1b3d1Y+5ub3PYKr/olm0d/FYOmLn/ZxRO+iVT5LwtPNtr+6yXKd3 +wLj1v38U3HFA0PjKEbaxbU3t4UryA2qyaeIno1i/wzaU8qGjtAShbYvixrVPIFB7ts7Bz2qP2oU jVwtaKvLcz6BscgAE+zN2z49qY0Pf7w3c0AYLZfS2nQVJuUpjCMUDkAtnIFxnuFzT9XTFMSW/vUv +KN6l/LuW2dWb8/uHIq4q9Oc755lWNSu80bIvOUeaIRK7jrW8lou6J5W6UuheNMqIqxBL1dpY8yJ A71xyIf72rYKK1iTGePdSf46E4ZyxrfCOqEu/f7tuCJrrPxw9UuwMqwMqb8zNmlaxi3LVrq1SR0q 8H+7VqbKo8zL8X3x/RYHF97RuOlotw3M4Yb8BKxCkOqAyj6bkX6U9gKtx9InCiEaiqiIvWIN31Cg D49s7jrcY7Grr4d3ETk8QtPLKVY8h6n8w+Wg+kPRheFj/u8M9hXpT8udfJpOLAmcnbyyhmCvHqt9 XnPen3mPZjPwvD91t6x73s8T9azuyelfXCpCt/RyUqvQZP1cExU9vcH0/vU/DgYblg2lvXNUoipJ u2ouaiud+c2gq9WSJqiiyqTdFZaEfLzR4MxfROBUzqZufuDbHjwArF3lzVBUrW9e1TFweC6lst4y 4a28i6j2kFrAC58N5K2XyZoTJF1+Y/pJ7SgiXGV+UXF1sS7qv3xg/xf4nxAgM0ASm8tiktjhMNjf AZ5wX8sKZW5kc3RyZWFtCmVuZG9iagoxMzQgMCBvYmoKPDwKL1R5cGUvRm9udERlc2NyaXB0b3IK L0NhcEhlaWdodCA4NTAKL0FzY2VudCA4NTAKL0Rlc2NlbnQgLTIwMAovRm9udEJCb3hbMCAtMjUw IDEyOTQgNzUwXQovRm9udE5hbWUvQUtBVElCK0NNTUlCNwovSXRhbGljQW5nbGUgLTE0LjAzNQov U3RlbVYgNjMKL0ZvbnRGaWxlIDEzMyAwIFIKL0ZsYWdzIDY4Cj4+CmVuZG9iagoxMzMgMCBvYmoK PDwKL0ZpbHRlclsvRmxhdGVEZWNvZGVdCi9MZW5ndGgxIDgzNAovTGVuZ3RoMiAyNDc4Ci9MZW5n dGgzIDUzMwovTGVuZ3RoIDMxMDMKPj4Kc3RyZWFtCnja7VJXVFOJFkXEgQnNNqIhwtUBFTAhAUKo 0kMz0kHQYEJyCcEUSAKEjg4dB2miIsFCEVQEAzhAAIGhKSNVQBQEEURFKdIUBV7UmTVrZt7PW+/v rXfvzz3n7LPPPvse5T32TnATMtMLxDIZHDgKgdIDzHA4a1MMgEQKIyQSoqxsxgKJHCqTYU7kgHoA SldXG7AJoAEaQgxGTxOth0ZCIMqAGZPuF8ABWQCOSQZZDMBbSMgGgkAWCJBBNpXCAMmAVzBgzmQQ aWTAAgHYMgI4PoivnX7BLCrFhwMcMFP5wo8BTOggi0oiMgAckeMD0oXjSUQa4MQkUUFOMAIATGg0 wPFLCxtwBNkgKxAkIyAQFAogU0kcwAukUBkQ9S8rWTO8mQDmW5oc4PdHKRBksYUbAQd+31IFEO5I ZjJowUKx3hD1I0zhRFCo5z+W9m+U/Z0cG0CjHSHSv9B/tfofdSKdSgv+HfFXV/8OdQO/iTNl0v4x xppDpFFJJgwKDQTgKC0EUhP9rUBlY6lckGxP5ZB8AG8ijQ1+zYMM8t+FCA38KkPdxNbE2dpU7ffT +Fa1J1IZHOdgPxBA/gn/GqP+jIUmsahc4BgSIXRaCBS+f3zh/zbNgkFikqkMCqCB1gaILBYxGIIU Ummg0UAoCqAyyCAXALlCyeoIBpMjbAGEzoQL74wF+fJnUUg0oE79koP8cwtTUyY3FAnANdBCSg1d LQCDRob/FebCoPoHgNbmABqpg9HU0f2aJQWwWCCD8/V8hP78EXtThZ6CIBckQaK0gk/f1DUdRI5S r0tLW6F2R0g61r/z5mb4tZIkjY/WKDmmVqiltX2s0x444bWZVrzL3nTZJ8xqJaRzxGz1++qXR6sy 1lhPQq0+WIkGHgREshCtKyeuT4gScnmXdbxUZ3FJ9ZdSoTCqkVh1T4/RpwW7zlRDZR8xLcth19na 3Ll03Zj2Jwtuh/O2BF+uHPI8veT0wmBD/fEQ00KZ6Doe2ck/Zt7kxKeTg3UnDrM1apYfR4RqZjso 1tbZGpND/HS32fD17dTyXrhW+NaXxJqIS0Rbx4krntD8YHg4uWLAbX/Wu4sqU9ox7B18RXN18a4W 17Vr4u6HiwcTMu4U/3DKmDp8c3WlQb8tpVs/Xl5/8dilnFMN2H44JZUVu5J+5T1G42yQ1NQG0kYb hO07fAZ0uqqT3QA9/zS48VYW3qCif/jkmPxVh+dGxfsgB/tCxzu7Jp3Cbidf+PGwyNiWnoJrFh7L pdXdsTJ5eGNrI/Okvo3De/pHzPbVQTKv7n2wNzl6xzGSVezww9/Mdh4kLCr2CtjuH6VXedo/RUeN fqfpjW06O6AV/QyrNtByLyVaZ/uRs+ppdRVPpcYzuh4ZexAi0zIGytJOgcurWBOpjvHsI5VTk3kP kdda3h9aCQyZfRDZcachNMpDOwdyJGaz8U8n7v9Iw9F2SAy2Hn+gmvryZid+r7bjqy43vdkI1U3A MAahY9Sr/Y5wYWK+WpXiQLtQlRBgvEUyayHU2Bb36zn6exfFt/FPQtFTnbetKghFzJVyRd8YJ75O 2M0UAWV3TiPRzYSPnSqYvGGYZSuhxtL82PFh2b3mVUlDa6j+WiKBYOIzgQxstk/1Wnu01GSm9nl1 XRJJSVLgOwe0AEV3520w3E4+TLHurmfP7QcP44cjX55vqAmRHUMUZF+9s6u47ZMfjW9xip8XMcns ezidJ/Gi+4rl43TF2v0bhis19NfejLmwZ6mx/XFT+bz2bR8apSsbYezAfp+Xw/ci55XvAO479H4p 0l3SPbZ9iVf05PK1LXb2F28k0KLtuu/M1aT1nK2Rvtk4Z5XqugD/8b1kYlw41Fva3nW9f9Rwp9Vc qTlfsDc1LJ0lIYGbj5dQyczYhIUV7Li8B3vNPpo7abGOt4zTzzagq3LC+ju1Ziot6LCg0RuxBGtM ioZz+Gg26DtOa5jAH/W5sXVQo+qYURIyP96D1vNTsYF8l3YKxeY09rxtYtxLnMVSoCXKkJ4dLw7g C+/XaW1r8m38rOarkHdMwZwXnpu4r1S0lOK1uXPM1bvCa+ZiDRSq1DNmnn65Hf36eK2+IyQ5QBTZ J/pWsxBKSHhdASPdctsesy6Ffn01FjPna6Q/Wmsd/+beg1Z4dIIOFxC9XXckCj2t9BwtYyBm1atE kiu3NXBT382LP7wd41Xb/vQ7niD0eZHoaQFw68px6O7phJ95ElsfLTMhHYe0w+TKxfvFrUWImyA/ +DgXuLi61Ii+awifXJCuDWlFB/OcJVWih5cF9hhJ0SsowbTzY4/noxhLnsX31K5B3CljCeP8Lbdu y+ejSB3GuXbpZzxgFWUDEp8WoOOzn+PumntnHkCMrBlMEBM6mqMejiufP/ejfarVx6SDEqn0El0l 394crxQI702rrKxOf4Q31a4Wwj7gvliQEFvVv3hBxs9kGpOQB3NPkhPxjXm+8/ABDBWqRX420/1h 2CwlP/ICT+NB/lmoAWqOiZVdnK7PsjzeQvns2rvuYnI2rOWRoZkWTva3+gG68i1j6lZ9oNVHkNhZ 4/9qrezuvIaDGhhQIpgPezjooF7djE4ugmWNV8vnSCZ070xciMtOfv25S2miZcM+Wp/cz4cWELXa +1TCRHpFriddsBmOGrqo80yHp3vSmcQy95gstVmLOPZG1Pm90aiB1xrNLuqqKa5lEcyMm7welLCw 8bHkr6sDu3a9GMGWW9OrmtbT5Xq7i/YrE3FP+c/yhlpm5SujT5dlDVRGNBgu3wXbfbi5q/D81LJe dQGQp476eNos8801h6AgVXiczsUh+TAUARTsF3xOnZ85N+1CqD1kaErSNhg5rghzNThXLSZvybte b7c92HUJqte6AJejNF6TdbfHy0L4rPuJZfXPLUqHYa3IRsuEvFcN8z3Fse/zH42YYqsuOzgHLQzY haQ4Zu56GAjs2r1wh/5L4v0iH0q6qsLuys9DAyFKXdNDs7iisUUreJWNN2w0/NDIyWvPFTkx+iqv MckWAPxhWpw7f1GuQZfT0GSN9YPDX7BfvE9CHGH4EjXGrsAn8S4/6yDPF1c1TzPivm/hP93QgX0r eFnOr1tykbr7y5LgSW7Msr+76khJ9p5tosmBEi7JfQMlmy4OLSflEvzLI7eXGDZGVYdCzdPuLsKs 9viOv7ySTxxKn7nZtpTzy1g5Qxl+bGo/LAoanynbcVhs972MZVLLTPFdUZ7/8iZiotIGicHNqvdI niJ7Lt2P0AvTg7ko6HGTmuZznNgdjdRBaTvWwGaES/tx/5oHwGxc9hYeOrMZ20TqSlOlH1i5HzBC kSlkFCa1ERFD9iNtjWwl58ISHAHP/Y3SVXZUxUkdKx5dMDIeU9HHmnsw7jA+mLOxVD2aGOZKFJDe BhHn1FWrXdzq9G7ez1mMtImkFpKaWafnnHK5C8M3KnBKGctgXqW9QviTHzy3VO3qXauxWXSRQqw6 W8Vug+kEPZbenqUg68nt9YYpDGK2sS0dPzU3FWZ3Wkrr8u26zQfnXXe3iYjNO0PmV4+q7sT7ePLz CPTxfSKpxKmYW6+N41JaN//c03noulzfZZe3nqLL0Kay22dDY9qRH5lT+3sh32FY5lAqOiN4X5Gx mUUlQou+Uy3E/7Zcjd4S+33PGxm4wI55sKeRgt64Xm3f7n1wuBNHytN0De+ZNVpRc3yzNWYsSz+l ZyAzQPvSRvdJk6xnBpJ3muQbVy+UxJobyehQpDI6NfeW9smxisWkDhLxaUSVPuf7uuQRWBXfXdTO XfycSFttQpnYoQn91aoCvC7DyGD7juLsI54FUutq6x2GdRpcGJi6tSnzsSADP1xk5mvsnaup5TSC 8/egJObZLaNHPOotzUr9nz5y4N6mzgexztD15YN6Ba1n2l1tN6qxbx7C7Nif6jhxGsS/s8t9xfD4 9WIfHirncWmPsgY+4iLL8lHvDauy5Md9/oS0sDNc70eTzXfyr+yXyUKpzPwQ3W46w51wO4cpLKdG lniGzYxmrmCzmIGvzmhbasl8JNrVnq8ZKsC6fid2/TyhYqICUCKkMSQOLG9z9Mno/u16Z3lNkMJc xrtUrdV8g1JO85OA0k/P2qpAJgFdHh9RHhe4kYb8Lx/I/wn+JwhINJDI4jDpRNZJCORfdetGuApl bmRzdHJlYW0KZW5kb2JqCjE0NSAwIG9iago8PAovVHlwZS9Gb250RGVzY3JpcHRvcgovQ2FwSGVp Z2h0IDg1MAovQXNjZW50IDg1MAovRGVzY2VudCAtMjAwCi9Gb250QkJveFstMzUgLTI1MCAxMTQ4 IDc1MF0KL0ZvbnROYW1lL0dZSkNURCtDTVRJOQovSXRhbGljQW5nbGUgLTE0LjA0Ci9TdGVtViA3 MAovRm9udEZpbGUgMTQ0IDAgUgovRmxhZ3MgNjgKPj4KZW5kb2JqCjE0NCAwIG9iago8PAovRmls dGVyWy9GbGF0ZURlY29kZV0KL0xlbmd0aDEgMTI5OQovTGVuZ3RoMiA4NzAyCi9MZW5ndGgzIDUz MwovTGVuZ3RoIDk1MjEKPj4Kc3RyZWFtCnja7ZdlVFzr1qUDBIfgboU7FO7uhODuUgUUUrgHd3d3 CSQkuAUNGtyCBQ/uLsFpzrn93Zy+X//p0f96dO0/9ax37Tnnu/beNWrTUqpqsEqAHMzBsg5QV1YO Ng5BgNQ7TQUBAAcbEIWWVsoZbOYKcYBKm7mCBQEcAgIcAAk3KwAHP4CTQxDILwjkQ0GhBUg5OHo5 Q6ysXQEMUox/dfEBJOzBzhALMyjgnZmrNdj+RcTCzA6g4WABAbt6sQEAEnZ2APW/TnEBqINdwM7u YBAbCgoHBwAEsXAFmIOtIFAU9r8yKUAtHQB8/yqD3Bz/a8kd7OzykgvA8JKTEfCSEuQAtfMCgMCW KOzKDi9u4Jcs/8ex/jep/lNc1s3OTtnM/i/5v+b035bN7CF2Xv+zwcHe0c0V7Ax45wACO0P/s1UH /K9s78AgiJv9f64quJrZQSwkoFZ2YAArBzcbkPtfdYiLLMQTDFKFuFpYAyzN7FzAf9fBUNB/JnkZ 3t852OX0FKU0pZn/dV3/tahqBoG6ano5ggHAP91/M8cffpmRM8QTYABkAwI5Xhpfjv/6ZvQfZjJQ CwcQBGoF4OThBZg5O5t5oQBfpDh5eAA+HAAIFAT2BIA9XxKzs0EdXF9OAbxMxhdg6eCM8tdF5eDj AbBbQv4q/s3c3AB2Cwd7e7M/lZcGay9HazD03yXel5LEH+IDsEv9IQEAu8y/iQ8IYJf9QxwvI/lD nAB2+T/EC2BX+kMvmu/+ED+AXfnfxP+iqfqHXlTU/9BLfM0/9JJT6w+9qOj+m15uSfY/mxR4WTP/ Qy97sPg3cQBfDEH/wJddgP+BLwEs/4FcAHarf+BLIOt/4EsiyD/wxdbuH/jia/8HOV58of/AF1+H f+CLr+M/8MXI+R/4YuTyD3yZrus/8GXzbv/AF1+PP8j5YuT1N/73+1pS0sHTh5WLB8DKyQP8y5Uf wMcD9P1fG7WgECc3sII0gAcIBPJz8v1dtXBzdgZDXf/+OXl5Zv6LLSEvjxkY7Am2QMnOwYPAmLCQ MV+ZXnbOUOm0jG0FfxgUEBCFoUes90OjKPFlUCRfyoUpSZ9zbvvYJ8UfZ985ud6bIicu9wYZ99r4 HpGvOpSEuQznUwEq74RvaVsDI6C5Ie9J14Mb1lvYGGxZPsX55NA2NinhCRvEJBQ4S+jpRidi217w tu16MxzjuML07HWrsL67JeYyVmWpoi2mD+prqfyiiOiYniTO1uDfEP2WwFM6tBma6DxQzs9XbXW0 sjFez1+aR4G850c+jUYjEYLPsRaqs7tVxDlkrP6jS0paSn48GDQAXQepdWxZLPn3iwT2MvyaDaRf bzFRzyUisztufHXOcIx1M3AyDd+FjSUuMvPppMTzqoV1l1ywhpiAs+JSYeNzYKxDidJxDK3G3DXP V1SornCwyj0vxbceWHSvVxMoJpxqZ4To0r+NtUk9ySAFRctpH3RQiIZiq0mY17VKKwiCz4gb7PfP 1B9h2qJBbKaUVTCZcUvujYVJ+a35JY/EUqiP0qAGMTdEE8t+ugc4/27h0yyC+AfThHiPn/u5+15d 6xTD+jaZyvpxht9nGQkTV91TF3WLVseFBgs9I7pT9cbi+ZZ5Oit5Vi52F0p/zrhe6lTzGz/iY3XK N4+5C4h9K0B4pJ6THN+BMeUx2dOArWH8SNPvpZi76Scr6L8k+ejcvCD2uWfbKIE2arDrsJ1Xswau JMLJJO8NKFsH19bTpjjz+7PAhXmgBULhry/BJQPcmHDorm/w8LWDd6WuU70OCWl6IDxHcvBp7ApK 4rivgEJ6CLhbCx+XNB4XkMQGNLd4Hmbc6qJKREQMFflnbKs+0d3n+c9mr1UxqzIoqCIkLyybvKoj 1I8mLGhUYcjnujo7PMCdTdGnmlg510O0a64hi0wmDAVozMfwjqGgbsgdVZEre7wHCinCk4uUVaqJ j+XewUSFQaob1CBQonczSgXm+xSXCEPhHgmrk0uEX8wZYp5vFKYLJYdJifvuCirhTwU2Rg+hK1rx xXcH1VPHzYFbZo+7kblGys8/zVAoa44z0ZGD7d2G/KNWtcf4YVtl7rLepCjcpx8RcV1YQ6h9HbKj S3eW52tJurcEr6AM3UtRmxT8kDIKakvv+nAKShbgXlxXvijEyZ1NxW2loAVEOAYaCrigY6rvcAA6 XXN0G2192yZASZcSZgk2fGKQT41Nz51ZN9rNK8jmorWeo2L5pFCwpQkPv7glc1b+XtTbTRS+lrnM kKGkOkOjPHBkUDZb0kmJnQQ5MXy3GEmx7COf6+I3JZsr4pBHuhwWlHkEV/0to1yKtlOaWSXHVKaS be1pzt0+PYTfAFKszvCnuYziYSN+J+X9B1SEHNxSi9L2SiZKKJJwmCXFCGxBgZe3FxNmYvEIzEZy Xw/ZhXypWdBYUeppFUIpvuK9ccwhhT8yd4z0uzDq2mR9EnbSIVbjdiOzDCx3lmATgqyGlKb9zq4I 9LxL10cXzvurwo9LmzZhnrD9FSspFYumGDeiZi7cFPPYrZX4o6SHtOp4Yw9NjYrz9J93bS5jDPUf OkHFM7uSpAQ1NNQMv9qOYmI2c5Fjm18Xe9udzejG98s41WrnDaU1sFMisalwLnnCOMzWTeF7Cbv4 MhrE7Jj3z7aLo7rHXeiI7LUk5M5Y0XW5fgRcDQolMxg/k9Gfk3CQrppNummuve3mGNMa2hH89jXa TBWSIo6PrKHRWJlN0PvBKAzvyBFKs3A0dtTOTvXz1X5ghxbvV+rjsepsz3cKTdpb3QcCcQ0ENYyb p9fhJrum/V+MkfBp2cuZL/UNbkc8/cne4311rgpUjVVneQ+D5s7ajq9QWfz7y1qTMgpdj943S7Ew JiLfjelSYubDLYqPZ1wS8bDhiMCdJ0FDk8rcngFvndxae5dl3RACvjHVnYc2Hzrng2nurH4h9u5A 1V9439ALWcrlQbaRfXFS562Sr1Lam0qs8JdF7UgiLVfqwqMlDxL1yhrS5rDoN6Koi+AUTcPmOiEP fDZ2Lk2jiBdq4Xcjsg9d+DtgY4h81DLFL5037Lii3XMldM7xQdeJSiWW2nx88sPAuTeeDOc4FQYP vPxzStNZlIpKDKQb+bfHSlkG5GztBM/ZJEHKbBitwjIejJV8r24DqjpQ63YtI+i14Oep48fvXMh4 r0XjQobPgi4QjHiSB5iaEfUXBdRKSwkEIFe49Te5mcWfo9eQRTJAb4uazqffbpiwBAOTI2th9KAf 5PFITO04KVLt9gxiYEC4yOaJrHp4d8EDsjY3ysWmNREptLNbNJn14NjWrHfe0aOf39MpNGpVm+q9 Y+dZZ97diZTbgnwt5JfCtUGWbj52M0y5Blo0T5+Ikfl2CehW9BhWV1DZRo6OxrzSJVJldUtYmI8K Qbdwx/mRApPK1psJX6295RNXv5SdH1OBtvzqdT5fDY6gyf0VKtZnfQhzgGq+GFwix0JVO3dZPfYr jWhVuoHy4LNDa9kBjTPRClBaCGwqOfKPyC2nSoNKolir4IxYeZjkSALeNiNGYQoEa//RHa2kkaXt OB5dWwVirpAFtLQ1lAsxW+uPOO1U1hpk7gMxxDRzZUknYb43iPoIxb391ukEesO7+Zz5+Ofy+iUy egg+/jP8yqyDp1qKB6qeoQj2T0mjnt/tVkyHfktRxwLvrJzU897g+KCVCHNQ1pNLv1aOtFU/Q9Xl CdmybdAQN7cAQRJf4YSAoiZ1pJILBDKgHlLk9HyNMBw+oMQFP284T/M8cY5bDBlzyp0WU5VCOOCS yaTisZJNzLW6LBId3Ao6w15NxWqif9lyOBJ6cd8vtITmehmk705eZu/fau3bcvyaj7wIQmfclmvO GzJYCWJo/jlpLSqk0VGlly0icLnyfa6K3+ACDb6lViNTw6LbTObGr35hXuNmdwWrGD14199GUYDh joqGB7lYMrjQu1veRuX8bPPhlzp4y8IA3o8m5yvXKxcsyFBMd5cEKYkgHJyG0F0ufss2V7fZ0vB6 L3N9FTUl0pKSPLS4GDiXSdB/sSWDNz2pWfeE5mZgjX/IOfqNP5tyIsIyz+BNBblUIJ+Tl0YzxsI9 5a801ynjKy+5t7I5bQVB6LLIO/QJTPf1qcyUghvthDFep5dZQWhvyWwBH2mOyLWqnXrIewmlCFN4 cMSAQfBlCWpdsAiVqf73atc12is/Jlar8D9sHm4q35pP55W1RxhRcY63eRaZGJgdOaM/Z3I0pbj4 25MtBpbtyb1F0TVJvf7A6I8mAk6PwDmyG+71jUH3U3f04kjPbCwlVjJapphsauKSPfZu6tok3Wct spKGjsFUMYPEBu/V55vzsqhSubdTnjOEssucPYQWUDIfIqSycUqAFZnm692CQ7SlEvrE4YEPn34Z s+LvDMfhlrRbTC11Z6yzzAxxbFzCb9y+78CDMjAKVVkU7bJLrsBKbTnKX3PPD0nLuw+e+h35sjDe hbyLEH841DcS1GCYiuZtkD7NN0koKZZqdknDTC3H7xDBgKt4l9Fr7BAQPhbgOJ5FiO0OGTp6e7Hm 385LTU8ZeaqLQMMk2cyrUJBQgI8c34TbQPlBxWBrYZyL03Xrk7CMEPb+D+W10NPnpMUq9nFutOK0 5WLRjPwRulv/B9u5jBKbQt2y946KEu338vS4PRzepXMWgdxJRe61of0D5BNfrH7q2Bsgcqn/dBh0 x5o8zS0wFMqM5161sPNaJuVjYxfWUG3av9gDk9zciUzwXSTKJux68vJuwnifEB9xdkQRL+IX9bzO nDhSzHO1Xn2GZkMXCwW3u978kg7c2lTn+1hNGMrDVmoPB/zspo2LUHAmqdB5zSWTauqJHGrZhO15 nT8Se009rtV3MiP4VNPGEdtyCvwcdRaehkw3bNVJrIkmRYP5WnHYTcuy6lMLVWDou+9LmJcJ/YSE TgJum22RtlnZKZh3IQmiXqREtIL7YO9JtapMg3E6MWQS6ion6qhis46uLlzfngn9Zhds5CZSfQee dCZrhxGNbBEr3yVZ4sbvo2EquLjZ+rd9zhV+nkRyOjVTC8SUdvyzUvIPe2R0VyzrWXPhs03lbngX SUuKurEiPY5qiNGg48Agxqb0Dp1D1ym1GcWZybiStUmE4Y7G832+PU27QX/UZ1w9UweEz8yT9dvW 2i38N4uRcdiDot2w3XavxVEEbiThz+7Q5oC0zeNEhhwpa+ziQILIZu8SmrjdXEQIuXR1zXaySt4X 2oSo7fy0+zK+tpkDxyC6+YQXgcu2feqo66XZhU5lO4O9CiwkIVFMkYCYmARf3ctTUgPcSUM6P4bf dbRf1L/zLmtVvk+krHtaMeRJDk+SDveJ+93JXh+dia34lvgLl3wOM2TPcJwd+L0Mpxx7CLO3MqD1 zn2OkR+kTY7ftflYsxNQBZoc6XONSQsjrNiuqoPzfL5EMHhFiCQ2t5iyiXHGwWrfKSGpF59RmOZ6 Mma4L5rvFZ5IWhnZqyPiFjTKfnVu+sZafCt2bE0582LERolZ3LTJffG2hUnL/8pe+UmVRf3mnnGp CawoJfWYINtqe8mD6es0jNFIjsSRFzCPblRSHexPUcmwiFMu6anQijyo1Fjy8Vxcn0Fign3kqP5N PXkCjyb6iWULltLcbMzxqeA0VXxNqMlNNP8d8LNudzbID16YK2Az4AKYDyAnqQ4W0Smg0XYVZ6td kc69vFhXQVKTvBJ6Rc3Dc6DXuKf/OQtJMy1p3OzMm9BeG8lHYb4pZtyDi8Epalvj0x5VjBGd8XiY 33c2UTpgo0BdGOFoEUhIrHZlFdXE7YtJWeFPJsvwj8pZkFUrY2p79WWFEkq3mXDaui2wDHtBKg3l 1IeVnMJbmuOub1/P5HrAOle9BdmGt2cj6w19OvKqdPa8Nvt3JMAl+yFhWsS9OdkK1LzlS2G0lImv skRnDXJgC5qJgwTpgBgS/vz2BGB+YD38fSkqckJ+5YM5XxJwX4L+16vhn72hitiSi4QPyf3SP+WC qbhglLK6cM3Y04yI0KY12BFtl1oSEqqYe8NF1uMkmIa/Nt/v4etzzH1sQZHLxJdwaKLQaQvEKNXo TbJNLaeX/6ANH07xoRtQ1Tw2JVfH+yueGsgwe8dFoBsv7Pp7HYuBdLFZBKlPT9aKIryWrKGIIYvO sc6ftFWCzF5JkaO7s2Je/lwx7dLZ8t1NaD38Yz2lPjPp1Dz7sg9JecC0gysDZSLajyGxnFupB30i F5U0rTr50vUiaMbv9DJJoeegcU1v+Ba+ZDeuqx4nARy4wy6JGi6d+PWDxZB6chqdz/rDWtnKX52k M/EcuLFH3m3SDgq1e1ENCDoMEVDwnd8Pmk86s7D4wWctRnGjAn6Rls86nzdEfPjqE+f2FYmaUJmL Tj3USgnmbjxXN912f8nxlNCKzUXeNHi9+jWT9AaxlBCbhAw0ktws6EKWwQQqxqsmQjgS0fxa4BO+ npcGCNDezev1DQ5NDyTOqgO0H8qPVwrs5lwRo/2dmjfnm62oG6EhWZiAq2OVZKV+BX5XUE9lHXCz HpPIrlxwkJaCiX58yKfnc2TS+ogDrsvwLdIdCj38Xj+lrgLY1bWMY2ZL9HnWRV9lMO4gJ9mkjGnz 23JwC4I+XlXT9oxhIHnHKE5eYZoZfaWTukAjNWjbWa0PIvadkbUHMX7VFaBzlSkseL5WHVcT53hz Klbf2+P3AZLjax84NxPH3Ek8GfRZU7Xx5T1AcqrUq4S7d2bLJCsEtIFduUyvfbTdr2mnucmEUrCd YEZooMYiOmZgg5CPSO6a+e4VWu+nMpHfatyybp+M6gobX8k+u8YlNG0TtOCQev+yJdRZX7Z+Ndxi KCqxzRgthFxvrC3VDH976xWwazRncvr2vUG5iZNC8eXK8YM89RfP6rWE1R92diq+s3WfspbypHkU cckmCA40gvfNU752Hv/CoiQgk0rokedDtvjQIZ+YkJxI7+/N1A43mYwF33tocCEatyhv6f+k5QwH lkIQCSzEC5XhrBKTsrwrVFUlwiQoLPtOKTXUExpjK5SbhgrJFFqFcwizgRtdYxkrQSjS9XjbTu1+ WGHDoMs3Lfb7m3+pyirk2IRFy5VzspPHffHuLIegrwv9Ik5jwb/Eq8fB3xsRb4LzlylZQtaK7xCI +8uOu+71d631SAQrFAxc/LXMTyTqJLBPjLBWsW1T2ExpJaI/JqJYV56/EYjeSVLMoPaI069Ag9XH YGPR9IWr/J177APTCRquE/hMVlcztxE8fJuH79Aqq14lPrgiv4dbiDsxahkqbKRtKwBuvo5Z6zec le+9ckfwxiN53vrq/uSTdpjxoRgNfnGqBZH+/q1Tb+XBuLMdj+Hetmwg3/SxwNH+dwNVruVNkRtS DlSWNk7maAWz63C57SQ4nUrk2DdhjNjO2KEfuTMeeRHE+OUw4h+W0WlsByI93TEpZBovK4Zkq9JE ENYM3gei8HPP5LeReXYp4e7QeLQcFM6hcF/1KO+NiWCpKJIitPu6zhRxKjbMQJecm4YZBTa/+zZ0 YtY2JjU0xmsijhZbf2YeqBohsfZPw/ZfOjaJqiiRxZq+bteIMMwhEKWC8OENI0AJJ1LqOOZkBt3f k5vrXMoPmOQHOXJT5DGSHveSYE+IL0ndbalyYYrfdG+XN8zAtUXUkjDz0c103XveJFrwalvSmLQq XixgJSCQnbRqV6GrjpJWs3jxwOZ2AQtOpXsn32BxxKM51UtYLtdbFjC1t22EIrAgXM1aV3Lb957Y rULbQFJZE0QsmRmfjYN+yff5qN/CBi5Y+tEqkepyNEpcq70rs8P9VVk6LwRWxkhbd77CuQztQ+J8 ei2ZYeoqydQVGLtaM6YnHvlGo8yXEuj8fbSJsMEScu2hrhHi7fYB2mEC0RTF7PN4tAAq9cNU4nCj VidYYJ0pXBkr0+3O5hJA6jooaqLQfwum/YwfnzRNfXdmSu8UgiiR2OEwb01mPRnEKdT9QeZNb2JH vu388+U2/uwp5erzHcPUnX7UpADsDIrpjPKRgavTPopOFIJKUjnua7ZRHuy3Rgz77vKXrgAimRGz NiWU1w4txCN2UXQc5cBTw9xNiLhNwm4PyzEuqm3J027Wjj5E4jK58pGfgghomkLmZiDvetRc5mCv LahWqTSMN+K7yGqA9bjm3mvnG6CIgULxJWNxFFivdLY9RaLXSG/ZM/pICvslyJMww8tBiTUzEHX1 17mhxeTeZF0WWqLOiaF3mZYSSc+szfDW20SUudM6LvwqqHYLI/44TK+HJG4I4Vv67T1f8FQxOVhg 5zbFVMcWarof93hW0pbCRZDmKNMZ7g/IubREejs73mdMdLXgTYVg/qlx6bFB4fi7VO+PfDuN9Eub welQz8e8BEfBn/cjVDqrhXeO9CM6GVo6fhyk2mGvleyHT7JiIlQcjLq2ahS9HfZxHGoYYU3hjoNZ Tff4GBqaQ6cg16KaX/IW+nByD99UurzJI7Uqz1657oliDSuZzl7CBMgToL5J+CLtdwLw2dAujv6e V2q63o1KUYyiYKHhZQPKCtilNbfr4tRyqAnmKZVAJLV5AN2yTtqLr84G0eUrKszymnRNURQDH8Tt DSqdyjtx+4OK+6T5fKqKlRwWX+2TrWPgUVpkOJUB6VEqzQu3RRWP7rjPoNVv6fbuP7e6Q+ianngR OKcvYXRcxs/ub0BO26On+z5Qdgqf85Btc36Er/wlQ70hAdhyukWH6KJPCiGrWIRF+h+SZ3U00HEQ dQX2BiOWUhjfOh7XmxMzxL4H+eP0RAuPXAj49evRej318DU2jPyw5Hz3Rmr7zWQs1T3iG7cNEp62 DN7xm86017mDn1g2BJcGamMyDPGJfT3j1hQCxL1ndtrnwbWHy2A1tP7dD4zXSR8AwCjaJAEStrjm wo2Dk7v7dcoNllrSNitxlK7XKGYL/GJzFh8to0EqAuRYHdOzvx3ZbwskcHv2DR8mnvd8BDxBtZIj wjP0HP5aG/PkYwxTlA6Hwux8mIk1qwsMlye/8Np5XAjh+voviWD0jzmn64WXUM9uGzWlO0ThuEqk SI5m3RKu2abpfBcTIie9pUnQIo6eWgdgF+51N5JLZjCodr4dSmuErAlRktGTkgNlvcONGx5HN8QD G4q/m9LdULlkCTah8Z5TV3pNECNaCaj6MKhlpSv8uIoBCAZTsDA9+NoBt+7qXY6vy0Yg7R5YGWe6 R8V3H6YlDZl1cESG3i1jkDKNtNahNCELnCmpYvILpBcfhdcsqytAVinTQ6NMbakWMo8EY1P1BH5g FFVc/xj0ZiQR2nzcYCy6wltSEpYiJkRsQPyht6i1fba33zF/O3YgIT/DFHdEtyQebIBR70YIi3Oh ZtJHg7NCYjwKCE43TDP5vu41Dtz44fHDeckUXwxto1IsBJxBgDWKZRRtMZr+o/a5tcbmoYf7PuJx okUUDb9igg7MYIYqaWpV+jppk63NBlWN3bKr7RzZu0RM80sqY2ZIWYhxm1L0tAJo+5uJg0OariPJ r1VXnCTaAHmB3gGpmROi3B8np6YNoyjocK6/Y38Nzt+87uQfEdwIRNM70+C6nT9OJBRwzxBT+VRN NF7kFLBa2GgKO7fym8KVZYCtUF2PLi6P8fNyl0umTlLO/JxG0sFo9QnXfjnFqTPC+KaU1VOKBoJd 2GIFywZ1jFnBLVw1ffDHQ15V8vDUKuftkjTG1AZWygU5RT5skQ8U9NU/uNRTJr4t4G9xRi2YjCMf UnxTaTWwSFTecLdji1CbvxxfYvQYdTCNYoisAzwpEfNsX9wxlJJzaDvmllsLTVXltZGArJ+K3laq r9IDpd9C0FtPJ0pbYDI/crsGfGpakO8+OKt5fKQcsuWx1JcQyb2I17pyqsDI2C46UOKofQO7361I vlbLJzVAC/IWyqbFWsGXiLhm7AVKjnPuC5w3vUbyzRRFPndmJCdK/kBJznqT/6U47rFLMj/ndEEF xFxtiGbxEedUgTAaYwIuE2fwgvju+cu+hpCtsG6WLMfUIBZSafGPSnpSPjUHyVXx6qNzsfB22BYH kjLHwFRSDrYk3WgxwmfFLnYVN0cbFfVwWzFRE9EnmDIYCRHN1K37B0Y9+KuoBj1DfW115Zvb85tl XCttZslinevXbDJVtasovjQznq3ntfNue3ru6gd2OrARHhLpXNkkoVwbciBYIh11D+e3clE0DY/s SdlN4gu94F1lVUaXnx/fauzhS5mriqjqehQtjvjrkZUzgwBXrcltXG1hcNtBkW7tfYnbr1xTLbik 22k0B8WTwRgWi/aE95WXsCLitQNXOIYuc+O8RzuWizYCdB9E0b2G4Fg74+48AKB1X8FWIuezTo8n MYQMiyNdorW1uR+CllZDgYA4AcM6iWEyfdPFobohi4lbT3JTueM99LvvNyArKxnzBZ594JkTxaeq jLKPhKnJn+Cn6l4rLxbIillcvfnthdsfh7Uq63HViGr3gMY8DJcmnEMyKc66Cx4lgTM2DtVdjEAb PGC6F8AVH1c4jNqBjuBoSpcdE+fqCTrie+QREO8aRBIMbjDELvSgpSsY02IHT/64O5o8Y5l/rHFC A9OiXV5LcWIdnpkfycj5puNcOjRfScafKgr9hF/u85XcVA70vTgztWkt4OqgZ8tJMCrgVMXDdYph kAmXJkyJ8+5P0xfRxojHENjpgct5ZmK+IJqVvA4LI3AJVz6QqlxLZ4tA5cHHq5e+fvljyD0xdWLL SSNgTdwv4a/MdIAWduk1sXsGE6oJ16A1++WjunbfrkAQop7r06opFtz2K30jBBT36MdbrctRGHkE l3zWFdW6InU9hUhUtjJZybgHcXF4HkOuY51WXyIW4kwXofOCBy65sxqUyq1vfKjE3h9UERq/MERx mO74PosziviFhqZbX8N89r7XlZ3I9akLCGEmou7rR+0vdzU6pI//gcuFwLnjNRnxet4WeP/hQlpn q7wAVcey5VdkkNJUvJ0RbvfykUm3Xl3vB+kiZYPR77bYK2OqUtzdTvBfrnfvRAnFX0kXZhe24qJc QQa1yI4e/eRr0w8uFVn51PZ/f9IVTHVYCzlGnaiyoSTsnow6eXL5XPSxPrB5XkwtvNv7lsvO3X+i uKe1KxMphaVYq4PZWljY7AR08WvRR0GcJ5jSDJnbn2RggFrBpn/Z2JwHjpu8gSom5Pxn+tba0Axj LXexzEcMZ4nuBO7mSkHZQHslDVNBD4vHU3wqCT4sZx/9ROqWRooJ+hnZZp/A0YQaEEe57hT8xWs8 8o0vpKEPnAXWP9Q7QiBlh5aAkIGnTy2qfj/N5Xf9T0yjO45UzfQb0gHG4zm8D8vteDFZfeKDNXiv 6y+fsKULhODnwHdCWOsK0g0dN4wHe3IK5JEEWFxyXEaz4okY0Zm2ZUPSHkAqpeA+35+1kf1AIp92 5LkavNOB6RK/deprW1a/bzgCJ1gdK2vZVRZLEV2Bcw35NwEMatykk2hG0HV//Z88YhRxEnZZtzq7 gijhCs7LtNOgrGhB7JFRuDAeTrbV5RkWM/8ciaIFNqSfInuv7PlJs5kGLlCdjE4NlGJpuXK8kotI PCShAsZCJGizuXTgrf1DaLmTHg+nEzRKAkkz5HoD4rOP92lRPQCB1WTTKi5UwdklLdM9jpj60wix anuYxIlCBaKf3B65ySzpVaiseNk3dWjtvhMs4iD3Cdc79y9F0Hk372eZTs6MgnIeXHn/QdHp21Yk 2Wdp2KEthCmgXo+CeatXcQuOd9omMYfCQy1jsJZKJ92wVqU8E0+hU62Vd/+60fe1IwyhjaVP2lrC 0fOWWjNy6PwSAgGXZo53VvC9dj+Uf64i01vBekYNOj5OdlLXJT0gDgInnn9+/IqdEwgre5Gqxs4t OXlg6jxFrqlP98Azbd1K4NGFKHR7FvwdMzKu8VcpT9LW3s/3QuWxSVzNLOqer3FsI25EjprGeszg or5V3xB9y+GQ3OidrsUc3C/Q6uswnLlCuU5WmVG08q/YGosTWvgeCyZCn4oxv7OT3hODhG3NuDrT sq8X2NonxX6sxlTY8bXagla3/dwh4Bz95g287e1knAbvhY0bF7tyLZH1jORdbxthZrjNSJ9QlDU3 MRkTaHByRVGvFrylk09Si8FPLQevOY+ARzYTtMheEUtHL6vHfNRcWpcBipkGM3rSGPltFU1SOpv2 yukvfVKv9zq2H7dGYVIT+/k9IKuDiWCO5iz1pMVhmigHH5q8EyZV/5V74+3QNMHXJ89xuAE5olM2 bYvJgHlgGQ+eMhWMuAVOYUi7mhGKJ+ONPNOUYiy3apUJW93ufmRy0bUIKDtwjHxmoqbD6seVDRdX UK2l0YlRaMKPZldc/jb1mI034V7Idmn+fmg250/PEyHNU87GSPSErg9oBbRKA+xhDWisrskIV3up x7NRn6kYssTSGonnLavSxH3k7wzv8PuyFwrK9V0i/TvLjVDzPsgHqxJQPv4upCDYCuuInRXy+Rw2 4XZPTG9TFfspLipg21Zb750udW3ksG4FJ6ZHSg7c9LcbU3tZdArTtTPaBS6nsbaS2mEqIjxhJ3C+ A3lHuqCAKmW2hx0XQQ0ikt4FoVGQZOXPajxwiQeE7EtsQBWnLolXp3v1uM3okBxqBlZVfrOF0o1B fnF7o0tDhn7U5m5hCGnZtp9zTu8w1oDw4IyL7NHJgvf0deMdGZb+V2ivH3OwkTB8FVf6s0oQ8P/y g/L/Bf6fELCwA5s5uzrYmznboqD8D0POu9UKZW5kc3RyZWFtCmVuZG9iagoxIDAgb2JqCjw8Ci9D cmVhdG9yKCBUZVggb3V0cHV0IDIwMDguMTIuMTE6MTIyNikKL1Byb2R1Y2VyKERWSVBERk14IFwo MjAwMzExMTZcKSwgQ29weXJpZ2h0IFwyNTEgMjAwMiBieSBKaW4tSHdhbiBDaG8gYW5kIFNodW5z YWt1IEhpcmF0YSwgQ29weXJpZ2h0IFwyNTEgMTk5OCwgMTk5OSBieSBNYXJrIEEuIFdpY2tzKQov Q3JlYXRpb25EYXRlKEQ6MjAwODEyMTExMjI3MDQrMDAnMDAnKQo+PgplbmRvYmoKNSAwIG9iago8 PAovVHlwZS9QYWdlCi9SZXNvdXJjZXMgNiAwIFIKL0NvbnRlbnRzWzM0IDAgUiA0IDAgUiAzNSAw IFIgMzYgMCBSXQovUGFyZW50IDE1NSAwIFIKPj4KZW5kb2JqCjM4IDAgb2JqCjw8Ci9UeXBlL1Bh Z2UKL1Jlc291cmNlcyAzOSAwIFIKL0NvbnRlbnRzWzM0IDAgUiA0IDAgUiA0OCAwIFIgMzYgMCBS XQovUGFyZW50IDE1NSAwIFIKPj4KZW5kb2JqCjUxIDAgb2JqCjw8Ci9UeXBlL1BhZ2UKL1Jlc291 cmNlcyA1MiAwIFIKL0NvbnRlbnRzWzM0IDAgUiA0IDAgUiA2OCAwIFIgMzYgMCBSXQovUGFyZW50 IDE1NSAwIFIKPj4KZW5kb2JqCjE1NSAwIG9iago8PAovVHlwZS9QYWdlcwovQ291bnQgMwovS2lk c1s1IDAgUiAzOCAwIFIgNTEgMCBSXQovUGFyZW50IDMgMCBSCj4+CmVuZG9iago3MCAwIG9iago8 PAovVHlwZS9QYWdlCi9SZXNvdXJjZXMgNzEgMCBSCi9Db250ZW50c1szNCAwIFIgNCAwIFIgNzgg MCBSIDM2IDAgUl0KL1BhcmVudCAxNTYgMCBSCj4+CmVuZG9iago4MCAwIG9iago8PAovVHlwZS9Q YWdlCi9SZXNvdXJjZXMgODEgMCBSCi9Db250ZW50c1szNCAwIFIgNCAwIFIgODcgMCBSIDM2IDAg Ul0KL1BhcmVudCAxNTYgMCBSCj4+CmVuZG9iago5MCAwIG9iago8PAovVHlwZS9QYWdlCi9SZXNv dXJjZXMgOTEgMCBSCi9Db250ZW50c1szNCAwIFIgNCAwIFIgOTcgMCBSIDM2IDAgUl0KL1BhcmVu dCAxNTYgMCBSCj4+CmVuZG9iagoxNTYgMCBvYmoKPDwKL1R5cGUvUGFnZXMKL0NvdW50IDMKL0tp ZHNbNzAgMCBSIDgwIDAgUiA5MCAwIFJdCi9QYXJlbnQgMyAwIFIKPj4KZW5kb2JqCjEwMCAwIG9i ago8PAovVHlwZS9QYWdlCi9SZXNvdXJjZXMgMTAxIDAgUgovQ29udGVudHNbMzQgMCBSIDQgMCBS IDExMSAwIFIgMzYgMCBSXQovUGFyZW50IDE1NyAwIFIKPj4KZW5kb2JqCjExMyAwIG9iago8PAov VHlwZS9QYWdlCi9SZXNvdXJjZXMgMTE0IDAgUgovQ29udGVudHNbMzQgMCBSIDQgMCBSIDExNSAw IFIgMzYgMCBSXQovUGFyZW50IDE1NyAwIFIKPj4KZW5kb2JqCjExNyAwIG9iago8PAovVHlwZS9Q YWdlCi9SZXNvdXJjZXMgMTE4IDAgUgovQ29udGVudHNbMzQgMCBSIDQgMCBSIDExOSAwIFIgMzYg MCBSXQovUGFyZW50IDE1NyAwIFIKPj4KZW5kb2JqCjE1NyAwIG9iago8PAovVHlwZS9QYWdlcwov Q291bnQgMwovS2lkc1sxMDAgMCBSIDExMyAwIFIgMTE3IDAgUl0KL1BhcmVudCAzIDAgUgo+Pgpl bmRvYmoKMTIxIDAgb2JqCjw8Ci9UeXBlL1BhZ2UKL1Jlc291cmNlcyAxMjIgMCBSCi9Db250ZW50 c1szNCAwIFIgNCAwIFIgMTI5IDAgUiAzNiAwIFJdCi9QYXJlbnQgMTU4IDAgUgo+PgplbmRvYmoK MTMxIDAgb2JqCjw8Ci9UeXBlL1BhZ2UKL1Jlc291cmNlcyAxMzIgMCBSCi9Db250ZW50c1szNCAw IFIgNCAwIFIgMTM2IDAgUiAzNiAwIFJdCi9QYXJlbnQgMTU4IDAgUgo+PgplbmRvYmoKMTM4IDAg b2JqCjw8Ci9UeXBlL1BhZ2UKL1Jlc291cmNlcyAxMzkgMCBSCi9Db250ZW50c1szNCAwIFIgNCAw IFIgMTQwIDAgUiAzNiAwIFJdCi9QYXJlbnQgMTU4IDAgUgo+PgplbmRvYmoKMTQyIDAgb2JqCjw8 Ci9UeXBlL1BhZ2UKL1Jlc291cmNlcyAxNDMgMCBSCi9Db250ZW50c1szNCAwIFIgNCAwIFIgMTUy IDAgUiAzNiAwIFJdCi9QYXJlbnQgMTU4IDAgUgo+PgplbmRvYmoKMTU4IDAgb2JqCjw8Ci9UeXBl L1BhZ2VzCi9Db3VudCA0Ci9LaWRzWzEyMSAwIFIgMTMxIDAgUiAxMzggMCBSIDE0MiAwIFJdCi9Q YXJlbnQgMyAwIFIKPj4KZW5kb2JqCjMgMCBvYmoKPDwKL1R5cGUvUGFnZXMKL0NvdW50IDEzCi9L aWRzWzE1NSAwIFIgMTU2IDAgUiAxNTcgMCBSIDE1OCAwIFJdCi9NZWRpYUJveFswIDAgNTk1LjI3 IDg0MS44Ml0KPj4KZW5kb2JqCjM0IDAgb2JqCjw8Ci9MZW5ndGggMQo+PgpzdHJlYW0KCmVuZHN0 cmVhbQplbmRvYmoKMzYgMCBvYmoKPDwKL0xlbmd0aCAxCj4+CnN0cmVhbQoKZW5kc3RyZWFtCmVu ZG9iago0IDAgb2JqCjw8Ci9MZW5ndGggMjEKPj4Kc3RyZWFtCjEgMCAwIDEgNzIgNzY5LjgyIGNt CmVuZHN0cmVhbQplbmRvYmoKMTU5IDAgb2JqCjw8Cj4+CmVuZG9iagoxNjAgMCBvYmoKW10KZW5k b2JqCjE2MSAwIG9iago8PAo+PgplbmRvYmoKMiAwIG9iago8PAovVHlwZS9DYXRhbG9nCi9QYWdl cyAzIDAgUgovT3V0bGluZXMgMTU5IDAgUgovVGhyZWFkcyAxNjAgMCBSCi9OYW1lcyAxNjEgMCBS Cj4+CmVuZG9iagp4cmVmCjAgMTYyCjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAwMDI0NDg1OSAwMDAw MCBuIAowMDAwMjQ3MTc5IDAwMDAwIG4gCjAwMDAyNDY4MzIgMDAwMDAgbiAKMDAwMDI0NzA0MyAw MDAwMCBuIAowMDAwMjQ1MDkxIDAwMDAwIG4gCjAwMDAwMDkwNzAgMDAwMDAgbiAKMDAwMDEwNzg2 OCAwMDAwMCBuIAowMDAwMTA3NjgxIDAwMDAwIG4gCjAwMDAwMDAwMDkgMDAwMDAgbiAKMDAwMDEx NTkwOSAwMDAwMCBuIAowMDAwMTE1NzIxIDAwMDAwIG4gCjAwMDAwMDA3MzkgMDAwMDAgbiAKMDAw MDEzMTgwMiAwMDAwMCBuIAowMDAwMTMxNjE2IDAwMDAwIG4gCjAwMDAwMDE0NjggMDAwMDAgbiAK MDAwMDE0NTAwNiAwMDAwMCBuIAowMDAwMTQ0ODE4IDAwMDAwIG4gCjAwMDAwMDIxOTYgMDAwMDAg biAKMDAwMDE0OTU4NyAwMDAwMCBuIAowMDAwMTQ5NDAxIDAwMDAwIG4gCjAwMDAwMDI5MjcgMDAw MDAgbiAKMDAwMDE1MTg0NiAwMDAwMCBuIAowMDAwMTUxNjU2IDAwMDAwIG4gCjAwMDAwMDM2NjMg MDAwMDAgbiAKMDAwMDE2Mjc4NiAwMDAwMCBuIAowMDAwMTYyNTkyIDAwMDAwIG4gCjAwMDAwMDQz OTUgMDAwMDAgbiAKMDAwMDE3MjM0NiAwMDAwMCBuIAowMDAwMTcyMTYwIDAwMDAwIG4gCjAwMDAw MDUxMjggMDAwMDAgbiAKMDAwMDE3NjUzMCAwMDAwMCBuIAowMDAwMTc2MzM5IDAwMDAwIG4gCjAw MDAwMDU4NTggMDAwMDAgbiAKMDAwMDI0Njk0MyAwMDAwMCBuIAowMDAwMDA2NTk0IDAwMDAwIG4g CjAwMDAyNDY5OTMgMDAwMDAgbiAKMDAwMDAwODk0OSAwMDAwMCBuIAowMDAwMjQ1MTk0IDAwMDAw IG4gCjAwMDAwMzkxNDQgMDAwMDAgbiAKMDAwMDAwOTEzMyAwMDAwMCBuIAowMDAwMDA5NDQxIDAw MDAwIG4gCjAwMDAwMDk0NzQgMDAwMDAgbiAKMDAwMDAwOTUwNyAwMDAwMCBuIAowMDAwMDA5NTUy IDAwMDAwIG4gCjAwMDAxODIwNDcgMDAwMDAgbiAKMDAwMDE4MTg1MiAwMDAwMCBuIAowMDAwMDM3 MDc0IDAwMDAwIG4gCjAwMDAwMzc4MTMgMDAwMDAgbiAKMDAwMDAzOTAwOSAwMDAwMCBuIAowMDAw MDM5MTEwIDAwMDAwIG4gCjAwMDAyNDUyOTkgMDAwMDAgbiAKMDAwMDA0NTcxMSAwMDAwMCBuIAow MDAwMTg1NjI4IDAwMDAwIG4gCjAwMDAxODU0MzQgMDAwMDAgbiAKMDAwMDAzOTIyNCAwMDAwMCBu IAowMDAwMTg4MDQxIDAwMDAwIG4gCjAwMDAxODc4NDkgMDAwMDAgbiAKMDAwMDAzOTk2NSAwMDAw MCBuIAowMDAwMTkwMjQ4IDAwMDAwIG4gCjAwMDAxOTAwNjAgMDAwMDAgbiAKMDAwMDA0MDcyMyAw MDAwMCBuIAowMDAwMTkxODY4IDAwMDAwIG4gCjAwMDAxOTE2ODEgMDAwMDAgbiAKMDAwMDA0MTA0 NiAwMDAwMCBuIAowMDAwMTk0MzMyIDAwMDAwIG4gCjAwMDAxOTQxMzcgMDAwMDAgbiAKMDAwMDA0 MTc5NyAwMDAwMCBuIAowMDAwMDQyNTI2IDAwMDAwIG4gCjAwMDAwNDU1NDAgMDAwMDAgbiAKMDAw MDI0NTQ4OSAwMDAwMCBuIAowMDAwMDUwMTI1IDAwMDAwIG4gCjAwMDAyMDY4NjkgMDAwMDAgbiAK MDAwMDIwNjY3MiAwMDAwMCBuIAowMDAwMDQ1Nzc1IDAwMDAwIG4gCjAwMDAyMTAwOTAgMDAwMDAg biAKMDAwMDIwOTkwMSAwMDAwMCBuIAowMDAwMDQ2NTEyIDAwMDAwIG4gCjAwMDAwNDcyNzEgMDAw MDAgbiAKMDAwMDA0OTk3NSAwMDAwMCBuIAowMDAwMjQ1NTk0IDAwMDAwIG4gCjAwMDAwNTQyMDMg MDAwMDAgbiAKMDAwMDA1MDE4OSAwMDAwMCBuIAowMDAwMDUwNDkyIDAwMDAwIG4gCjAwMDAwNTA1 MjUgMDAwMDAgbiAKMDAwMDA1MDU1OCAwMDAwMCBuIAowMDAwMDUwNjAzIDAwMDAwIG4gCjAwMDAw NTE3OTQgMDAwMDAgbiAKMDAwMDA1NDA1NyAwMDAwMCBuIAowMDAwMDU0MTY5IDAwMDAwIG4gCjAw MDAyNDU2OTkgMDAwMDAgbiAKMDAwMDA2ODA2NiAwMDAwMCBuIAowMDAwMDU0MjgzIDAwMDAwIG4g CjAwMDAwNTQ1ODcgMDAwMDAgbiAKMDAwMDA1NDYyMCAwMDAwMCBuIAowMDAwMDU0NjUzIDAwMDAw IG4gCjAwMDAwNTQ2OTggMDAwMDAgbiAKMDAwMDA2NjE1NSAwMDAwMCBuIAowMDAwMDY3ODk2IDAw MDAwIG4gCjAwMDAwNjgwMzIgMDAwMDAgbiAKMDAwMDI0NTg5MCAwMDAwMCBuIAowMDAwMDc0MjY3 IDAwMDAwIG4gCjAwMDAyMTM0OTggMDAwMDAgbiAKMDAwMDIxMzMxMSAwMDAwMCBuIAowMDAwMDY4 MTQ2IDAwMDAwIG4gCjAwMDAyMjExNjcgMDAwMDAgbiAKMDAwMDIyMDk3MSAwMDAwMCBuIAowMDAw MDY4ODc1IDAwMDAwIG4gCjAwMDAyMjI2ODEgMDAwMDAgbiAKMDAwMDIyMjQ4NiAwMDAwMCBuIAow MDAwMDY5NjE2IDAwMDAwIG4gCjAwMDAwNzAzNTEgMDAwMDAgbiAKMDAwMDA3NDA1NSAwMDAwMCBu IAowMDAwMjQ1OTk4IDAwMDAwIG4gCjAwMDAwNzcxMDIgMDAwMDAgbiAKMDAwMDA3NDMzMyAwMDAw MCBuIAowMDAwMDc2OTQxIDAwMDAwIG4gCjAwMDAyNDYxMDYgMDAwMDAgbiAKMDAwMDA4MDQxMSAw MDAwMCBuIAowMDAwMDc3MTY4IDAwMDAwIG4gCjAwMDAwODAyODMgMDAwMDAgbiAKMDAwMDI0NjMw MyAwMDAwMCBuIAowMDAwMDg1NjQ0IDAwMDAwIG4gCjAwMDAyMjczMzYgMDAwMDAgbiAKMDAwMDIy NzEzOCAwMDAwMCBuIAowMDAwMDgwNDc3IDAwMDAwIG4gCjAwMDAyMjkzOTYgMDAwMDAgbiAKMDAw MDIyOTIwNiAwMDAwMCBuIAowMDAwMDgxMjE3IDAwMDAwIG4gCjAwMDAwODE5NzEgMDAwMDAgbiAK MDAwMDA4NTQ0NCAwMDAwMCBuIAowMDAwMjQ2NDExIDAwMDAwIG4gCjAwMDAwODk5NzggMDAwMDAg biAKMDAwMDIzMTgwOSAwMDAwMCBuIAowMDAwMjMxNjE0IDAwMDAwIG4gCjAwMDAwODU3MTAgMDAw MDAgbiAKMDAwMDA4NjQ1OSAwMDAwMCBuIAowMDAwMDg5ODEzIDAwMDAwIG4gCjAwMDAyNDY1MTkg MDAwMDAgbiAKMDAwMDA5MzE2NSAwMDAwMCBuIAowMDAwMDkwMDQ0IDAwMDAwIG4gCjAwMDAwOTMw MTcgMDAwMDAgbiAKMDAwMDI0NjYyNyAwMDAwMCBuIAowMDAwMTA3NTk4IDAwMDAwIG4gCjAwMDAy MzUyMjIgMDAwMDAgbiAKMDAwMDIzNTAyNyAwMDAwMCBuIAowMDAwMDkzMjMxIDAwMDAwIG4gCjAw MDAwOTM5NjMgMDAwMDAgbiAKMDAwMDA5NDI3MyAwMDAwMCBuIAowMDAwMDk0MzA4IDAwMDAwIG4g CjAwMDAwOTQzNDMgMDAwMDAgbiAKMDAwMDA5NDM4OSAwMDAwMCBuIAowMDAwMTA2MTIxIDAwMDAw IG4gCjAwMDAxMDc0NzAgMDAwMDAgbiAKMDAwMDEwNzU2MiAwMDAwMCBuIAowMDAwMjQ1NDA0IDAw MDAwIG4gCjAwMDAyNDU4MDQgMDAwMDAgbiAKMDAwMDI0NjIxNCAwMDAwMCBuIAowMDAwMjQ2NzM1 IDAwMDAwIG4gCjAwMDAyNDcxMTMgMDAwMDAgbiAKMDAwMDI0NzEzNiAwMDAwMCBuIAowMDAwMjQ3 MTU2IDAwMDAwIG4gCnRyYWlsZXIKPDwKL1NpemUgMTYyCi9Sb290IDIgMCBSCi9JbmZvIDEgMCBS Cj4+CnN0YXJ0eHJlZgoyNDcyNzcKJSVFT0YK --=====001_Dragon662276615844_=====-- From hash-forum@nist.gov Fri Dec 12 02:46:09 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBCAk4rM010359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Dec 2008 02:46:05 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBCAEjwD018344; Fri, 12 Dec 2008 05:14:47 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBCADOCO020386; Fri, 12 Dec 2008 05:13:24 -0500 Date: Fri, 12 Dec 2008 05:13:24 -0500 Message-Id: <200812121806211564877@gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "catmaniii" To: Multiple recipients of list Subject: Correction of minor error in "Cryptanalysis of the Hash Function LUX-256" X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/alternative; boundary="=====003_Dragon818348807033_=====" Mime-Version: 1.0 X-To: "hash-forum" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 12 Dec 2008 02:46:06 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 312 This is a multi-part message in MIME format. --=====003_Dragon818348807033_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit We have made a mistake in drawing a figure of state update operation of one round in LUX. -- The AddConstant operation should be right after MixColumn. But this minor error won't affect our results. Best regards, Shuang Wu State Key Laboratory of Information Security, Institue of Software Chinese Academy of Sciences. 2008-12-12 --=====003_Dragon818348807033_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 7bit
We have made a mistake in drawing a figure of state update
operation of one round in LUX.
 
  -- The AddConstant operation should be right after MixColumn.
 
But this minor error won't affect our results.
 
Best regards,
Shuang Wu
 
State Key Laboratory of Information Security, Institue of Software
Chinese Academy of Sciences.
2008-12-12
 --=====003_Dragon818348807033_=====-- From hash-forum@nist.gov Fri Dec 12 08:03:54 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBCG3l1E017614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Dec 2008 08:03:48 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBCG1iO1016786; Fri, 12 Dec 2008 11:01:51 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBCFxulS013603; Fri, 12 Dec 2008 10:59:56 -0500 Date: Fri, 12 Dec 2008 10:59:56 -0500 Message-Id: <494288D7.7060108@iaik.tugraz.at> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: =?ISO-8859-15?Q?Martin_Schl=E4ffer?= To: Multiple recipients of list Subject: cryptanalysis of Twister X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080405070504050303090305" MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 12 Dec 2008 08:03:48 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 313 This is a cryptographically signed message in MIME format. --------------ms080405070504050303090305 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Hi all, we have found an attack to construct pseudo-collisions for=20 Twister-{224,256,384,512} with a complexity of about 2^26.5 compression=20 function evaluations. The attack can be extended to a theoretical=20 collision attack on the hash function Twister-512 with a complexity of=20 about 2^231.5 with different time-memory tradeoffs. More details can be found in the pdf file, which has been uploaded to=20 http://ehash.iaik.tugraz.at/uploads/d/dd/Twister_attack.pdf Best Regards, Martin Schl=E4ffer --------------ms080405070504050303090305 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIbEDCC BLMwggOboAMCAQICARYwDQYJKoZIhvcNAQEFBQAwQTEQMA4GA1UEChMHRXVyb1BLSTEtMCsG A1UEAxMkRXVyb1BLSSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTIyODA5 NTA1MloXDTEwMTIzMTExNTkwMFowUjELMAkGA1UEBhMCQVQxEDAOBgNVBAoTB0V1cm9QS0kx MTAvBgNVBAMTKEV1cm9QS0kgQXVzdHJpYW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1hZUNUa0lyv5ttAn7ZRyfI4zO+Bc2fmTi lpAIBfJ/2yqfdHKCd/r2czeCme85S298uhCrDtKZXQp6wZpxGsZrZw5n8mrXVVy6HUTFTyKa pz/4W3vS0f3fKljpUioJ9lBUwQyARDcNzCP63+Iv9OqrHgb4QoSfmDlrX5KmaGDaEgoNYbkY wFDn0b81I16j8mXDDECtQM/ZsxzjkHZz1ks3jl/q9EW1OxdD6ytgsePXzfmfWjdwsB8KyjXI UNpLMBzPK3qTjwevGUQjfCCJ1hC26t2G9BWPcHUUw0/4gCL/jGDLUAmMWo1z1H/gyk9VrTsU uP3HZ7fElMpfqmIqyr69AgMBAAGjggGjMIIBnzBMBglghkgBhvhCAQ0EPxY9SXNzdWVkIHVu ZGVyIHBvbGljeToKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzBk BggrBgEFBQcBAQRYMFYwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwLmV1cm9wa2kub3JnOjgw MjYwKgYIKwYBBQUHMAKGHmh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdDA7BgNVHR8E NDAyMDCgLqAshipodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3JsL2NybC5kZXIw TgYDVR0gBEcwRTBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93d3cuZXVy b3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzAdBgNVHQ4EFgQUdCnYUa/CPJin1/8xj0D3UOgH AegwHwYDVR0jBBgwFoAUjNyLsaVKkOdOiHMYPJ3VXn7kss0wDAYDVR0TBAUwAwEB/zAOBgNV HQ8BAf8EBAMCAfYwDQYJKoZIhvcNAQEFBQADggEBALvbHv34QJkgCzJ92trxCWkGmeahGFQ8 ZQCFlgeaAI5d2B8K9XVJ7IduoETxq+evWfDaiUBHahQ6c2oC9uhuqI4pzJpsEJimYpccHRBA 85S5spyfLfpboY1lSGraFxZwTsV9+wGftlCOZy3UF9Ip0VLP1wrRsTvfCBjLybj45ay3L3o5 F+MojQ2VPC0w/z56yD9caU+fl2pJSU7Q5fUlUfYD0PexVzDEWX4r3lGn6G5UD/zC8zNqH7fh sJxsH/TeraHbvUk8AZu4IULWzrpytR7JpOX/VRfeF65foy7GoTkBuGPx9EsbXJzZ/ygab947 O5yIAqr6bibMh7i1ZDcpnacwggU3MIIEH6ADAgECAgcCQt/N+2FTMA0GCSqGSIb3DQEBBQUA MFIxCzAJBgNVBAYTAkFUMRAwDgYDVQQKEwdFdXJvUEtJMTEwLwYDVQQDEyhFdXJvUEtJIEF1 c3RyaWFuIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA4MDIyODE1MTgwNVoXDTEzMDIy ODE1MTgwNVowgb0xLTArBgNVBAMTJEV1cm9QS0kgSUFJSyBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEmMCQGA1UEChMdR3JheiBVbml2ZXJzaXR5IG9mIFRlY2hub2xvZ3kxSDBGBgNVBAsT P0luc3RpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21t dW5pY2F0aW9uczENMAsGA1UEBxMER3JhejELMAkGA1UEBhMCQVQwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCVatVA1TczvPSG2IZoIPtEBXNgZSdUx58syuOEoZs9HOc0MocB 2ko3jIDfB9YIP7bLEag1yjrlO8GxfkBCiTQvnfNDEIMvetuwJmHSgaTxJ3PRlOWDJMi/IbNe X1yq2sOYyszpbK5/jm6JAl/XbYNmNuiPxx2PR3iVZBL4v38sF7o0x/ale5P7RmW4KXq36Mpc /KaAW4cMrDUAGNqcc9EIwkTAx1moGt8u7v/CTgWIilXbhB1BBBjp+Cy9ukBX+HnwimWlAcKF DTqmwFmgJA+QlCEQYHs0o2ylWF+41N8MivLlYqvqQlpOFqWStBpKr8lxkcjpFRzFry2ORWlK 16+bAgMBAAGjggGkMIIBoDAOBgNVHQ8BAf8EBAMCAcYwDwYDVR0TAQH/BAUwAwEB/zAdBgNV HQ4EFgQUOXTH3cjx+wpwPQ7KfUUCrKGb154wVgYDVR0gBE8wTTBLBgwrBgEEAZUSAQIBAQEw OzA5BggrBgEFBQcCARYtaHR0cDovL2V1cm9wa2kuaWFpay5hdC9jYS9ldXJvcGtpLWF0L2Nw cy8xLjEvMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jYS5pYWlrLnR1Z3Jhei5hdC9jYXBz by9jcmxzL0V1cm9QS0lBdXN0cmlhbi5jcmwwgZoGCCsGAQUFBwEBBIGNMIGKMEIGCCsGAQUF BzABhjZodHRwOi8vY2EuaWFpay50dWdyYXouYXQvY2Fwc28vT0NTUD9jYT1FdXJvUEtJQXVz dHJpYW4wRAYIKwYBBQUHMAKGOGh0dHA6Ly9jYS5pYWlrLnR1Z3Jhei5hdC9jYXBzby9jZXJ0 cy9FdXJvUEtJQXVzdHJpYW4uY2VyMB8GA1UdIwQYMBaAFHQp2FGvwjyYp9f/MY9A91DoBwHo MA0GCSqGSIb3DQEBBQUAA4IBAQCmsYc+Rdrfd3sV8jqDipRkd/BGEwGFiWydTmEMRimyr2Sm qNVX4khjAEyLcVjyYK+Fc+XREwOttYcKQHFKaRZRDby0RvniwP3LX1Du3xXnEHij9oB6A2aE Tg1ouAnCikXQQ4C3eBfM9vaK9VR0k/akaqKzTTPBl8ao7TmOfTTdIBrVSoPYjeXR/qm1A34n Pb0gR5sBMEZEcZgDN2oKSDsrK2bHp7AG36R/AtnGyW4j1hI5hR35VCmAToz4dbUKhZjDFJU+ FgmANAWh0+AetShQ7qpS6IyHXxdDGYW/7SHbwWsi4pmRnRm/xaYLVCo3zRJDwaXq3JlKOh2V if4IFzAgMIIFgDCCBGigAwIBAgIHA0DrJxk2fDANBgkqhkiG9w0BAQUFADCBvTEtMCsGA1UE AxMkRXVyb1BLSSBJQUlLIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSYwJAYDVQQKEx1HcmF6 IFVuaXZlcnNpdHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/SW5zdGl0dXRlIGZvciBBcHBs aWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMQ0wCwYDVQQH EwRHcmF6MQswCQYDVQQGEwJBVDAeFw0wODAyMjgxNTQ0MTdaFw0xMzAyMjgxNTQ0MTdaMIGs MRwwGgYDVQQDExNFdXJvUEtJIElBSUsgU2lnIENBMSYwJAYDVQQKEx1HcmF6IFVuaXZlcnNp dHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/SW5zdGl0dXRlIGZvciBBcHBsaWVkIEluZm9y bWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMQ0wCwYDVQQHEwRHcmF6MQsw CQYDVQQGEwJBVDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALBs2U2/lTXnomXh gNULWkAXS507A6UtmsbrAIXXK7XIWgyjbKiYASrdej0LPKGuFtxbZ+A/e1cSV8yrCWsB+4s8 jZwL+xbWeXIGcaKarv0npeXSqX0UZl7DM5mVID+FwG1T73qjmIGvE6i5qDnNEv0siGeit7m0 AH3dF2uckq6eKuozAvchlJOQk27PqaPRFCS5APiCNBrB9AUShjXMHso1wC1raxlsGDc/yneC 2Z4OOBZLkswPIMu0qUwVfGVR7u3WFLEP3cPXw8lWb1Ka8GzGLBivt4PRz+wyibDfWx/i/Snh TzfEuB4y1PFjvsFQ3o3am2zHpqvy1WPfUsxRLQ0CAwEAAaOCAZIwggGOMA4GA1UdDwEB/wQE AwIBxjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSu7lUGF3pTERMYq6TOHHEJGoMU8zBQ BgNVHSAESTBHMEUGDCsGAQQBlRIBAgMBATA1MDMGCCsGAQUFBwIBFidodHRwOi8vZXVyb3Br aS5pYWlrLmF0L2NhL2lhaWsvY3BzLzEuMy8wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2Nh LmlhaWsudHVncmF6LmF0L2NhcHNvL2NybHMvRXVyb1BLSUlBSUsuY3JsMIGSBggrBgEFBQcB AQSBhTCBgjA+BggrBgEFBQcwAYYyaHR0cDovL2NhLmlhaWsudHVncmF6LmF0L2NhcHNvL09D U1A/Y2E9RXVyb1BLSUlBSUswQAYIKwYBBQUHMAKGNGh0dHA6Ly9jYS5pYWlrLnR1Z3Jhei5h dC9jYXBzby9jZXJ0cy9FdXJvUEtJSUFJSy5jZXIwHwYDVR0jBBgwFoAUOXTH3cjx+wpwPQ7K fUUCrKGb154wDQYJKoZIhvcNAQEFBQADggEBAAgys3wJ2CixcC8KuuO3a9k8u0nT0+PafLR9 wMQMWsz7xDTLNxiTJKnLvdFw86D+CH+nXxRweo/KDVYT56q5rfKs45I6mZDV+z/wecNX3odW MuY5a6j0g/RR4Qz/wokfeUzff5Yi6Hh1P9ce0u3/EHAHancJI3FxoZpLU5qNWZNo+fI6nluO BmdJCWZgCR9ijucmFubnu4EbWlyhiH2e0H2taU6zWvW/83yqbEO0BhDKVWWVtWvlF/ptBZQE JzAD1q5XJobPNQ/IANfs5ZcfuC1+Pm6FEG0cMVnDCGlRoA57oTIFaODWQPr4gxMy11/MYe9V ufBih5AU1z6V4IwJ5SYwggXJMIIEsaADAgECAgcDAK1qvxKLMA0GCSqGSIb3DQEBBQUAMIGs MRwwGgYDVQQDExNFdXJvUEtJIElBSUsgRW5jIENBMSYwJAYDVQQKEx1HcmF6IFVuaXZlcnNp dHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/SW5zdGl0dXRlIGZvciBBcHBsaWVkIEluZm9y bWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMQ0wCwYDVQQHEwRHcmF6MQsw CQYDVQQGEwJBVDAeFw0wODEwMDcxNzQwMThaFw0xMTEwMDcxNzQwMThaMIHQMQ8wDQYDVQQq EwZNYXJ0aW4xEzARBgNVBAQMClNjaGzDpGZmZXIxGjAYBgNVBAMMEU1hcnRpbiBTY2hsw6Rm ZmVyMSYwJAYDVQQKEx1HcmF6IFVuaXZlcnNpdHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/ SW5zdGl0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11 bmljYXRpb25zMQ0wCwYDVQQHEwRHcmF6MQswCQYDVQQGEwJBVDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAOJQuKfmW0nN4oYRLNQd8IARYTrZ7xYC2E1CXTA8ruvZNqgmDjjY Yb31crA23mku3iUEiwEPZkuYlrTWRfxMZqNfDiEiMnQSpGoEt6OkMysOJqUbcr2KFxU61RYV EFV47KpQODvSDJMJM7+w42j1sOOR7s774pVYi7TTyw02h2q4h00ANSaWfYVNEEuZ6LDe+IGl YCcPkEPY/wf8tolxk2FhofovqkmbowfUd33ltNr4pA5NVcjcXiAlHT1TWHP9Y5fBlOPtSmZz jhETQLZ04mzC54Fro20GrkC4gdfdx/gbfwFMxhs5gpi9VI13X+odzNXlnAdNQ5t6CThfvxlz 1JsCAwEAAaOCAcgwggHEMA4GA1UdDwEB/wQEAwIEMDAMBgNVHRMBAf8EAjAAMB0GA1UdDgQW BBSx9MiM/Nw02QE9n1EplP/rqwC/1DBQBgNVHSAESTBHMEUGDCsGAQQBlRIBAgMBATA1MDMG CCsGAQUFBwIBFidodHRwOi8vZXVyb3BraS5pYWlrLmF0L2NhL2lhaWsvY3BzLzEuMy8wSAYD VR0fBEEwPzA9oDugOYY3aHR0cDovL2NhLmlhaWsudHVncmF6LmF0L2NhcHNvL2NybHMvRXVy b1BLSUlBSUtfRW5jLmNybDCBmgYIKwYBBQUHAQEEgY0wgYowQgYIKwYBBQUHMAGGNmh0dHA6 Ly9jYS5pYWlrLnR1Z3Jhei5hdC9jYXBzby9PQ1NQP2NhPUV1cm9QS0lJQUlLX0VuYzBEBggr BgEFBQcwAoY4aHR0cDovL2NhLmlhaWsudHVncmF6LmF0L2NhcHNvL2NlcnRzL0V1cm9QS0lJ QUlLX0VuYy5jZXIwKwYDVR0RBCQwIoEgbWFydGluLnNjaGxhZWZmZXJAaWFpay50dWdyYXou YXQwHwYDVR0jBBgwFoAU3UP298kNEZZgTQSlVkIYEiSm2uowDQYJKoZIhvcNAQEFBQADggEB ADuQrAi8V7RqDsYffIq3SdpAIDE8+qOFbEtN6wXp8m3cex5IahtW80ubRgcfKk3CweywWiD4 EXXnjgfCEB+YnrhAe0QuaS8bZ9pneaF8X6l9sZx2jpWuMB2XtYaEz7gs9XyB1npLOcLShkif JGW/H6P2iiD55yq/GAKx3Qxs4rsdz/duzdadcmJSqKvqGPlwSHEJP7t249SIwtxkNhEwnnXZ uNtCWzMF6C41xs+JbqaNFCbSCMLMsut5JL5KaEIqIdmX8SqUgLlFCl67I+xshxYlIgphQbDX w1iSXpXWYk5dF5oYqXa3wT7IULRf5ZBAFqj177XN9ITqK4iNgcBsyOUwggXJMIIEsaADAgEC AgcDUdAh4zGXMA0GCSqGSIb3DQEBBQUAMIGsMRwwGgYDVQQDExNFdXJvUEtJIElBSUsgU2ln IENBMSYwJAYDVQQKEx1HcmF6IFVuaXZlcnNpdHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/ SW5zdGl0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11 bmljYXRpb25zMQ0wCwYDVQQHEwRHcmF6MQswCQYDVQQGEwJBVDAeFw0wODEwMDcxNzQ2MTVa Fw0xMTEwMDcxNzQ2MTVaMIHQMQ8wDQYDVQQqEwZNYXJ0aW4xEzARBgNVBAQMClNjaGzDpGZm ZXIxGjAYBgNVBAMMEU1hcnRpbiBTY2hsw6RmZmVyMSYwJAYDVQQKEx1HcmF6IFVuaXZlcnNp dHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/SW5zdGl0dXRlIGZvciBBcHBsaWVkIEluZm9y bWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMQ0wCwYDVQQHEwRHcmF6MQsw CQYDVQQGEwJBVDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALam7BWLO3AmmIP2 TyKPAwMgtFV+BO0pnAH4LFGn7hsISDmPOyQnwOayzZIe52EAuxGzd1WB0aGQwVnViEBjRFwB vB2wi9neXzVYNuCQfC1o08RTS2UBVMNjr5RtkLqo9+ST1LlTeGhrsBccUMbPGpKFO+T2yl/y 2RV8M0N5ahMINo7uSWRHZ/rKO4JC+9QHUebmvGhvBevDxX41BkfgtNKPWCyXE+ZlOxmRvYEF WDnm7ntjuyFzshNGtE7iNOu3pttwsfNpK1549qD7cZb9V5RS8FSWw4wYGtLpfNDYuDVYiJLD fqYUXPSPfEIM2W8/HaHA5u19IGgHzVo1rdqpr1sCAwEAAaOCAcgwggHEMA4GA1UdDwEB/wQE AwIGwDAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBT0LqYC5aKGOecwt+JXWgDeIAfAhjBQBgNV HSAESTBHMEUGDCsGAQQBlRIBAgMBATA1MDMGCCsGAQUFBwIBFidodHRwOi8vZXVyb3BraS5p YWlrLmF0L2NhL2lhaWsvY3BzLzEuMy8wSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NhLmlh aWsudHVncmF6LmF0L2NhcHNvL2NybHMvRXVyb1BLSUlBSUtfU2lnLmNybDCBmgYIKwYBBQUH AQEEgY0wgYowQgYIKwYBBQUHMAGGNmh0dHA6Ly9jYS5pYWlrLnR1Z3Jhei5hdC9jYXBzby9P Q1NQP2NhPUV1cm9QS0lJQUlLX1NpZzBEBggrBgEFBQcwAoY4aHR0cDovL2NhLmlhaWsudHVn cmF6LmF0L2NhcHNvL2NlcnRzL0V1cm9QS0lJQUlLX1NpZy5jZXIwKwYDVR0RBCQwIoEgbWFy dGluLnNjaGxhZWZmZXJAaWFpay50dWdyYXouYXQwHwYDVR0jBBgwFoAUru5VBhd6UxETGKuk zhxxCRqDFPMwDQYJKoZIhvcNAQEFBQADggEBAK3lES8Ob0WLsEYKPlBfOpTsJ1JrVFxvMpP/ eJubeSmQGcXuOMU1mcUF3Pquuv1Uk/BcIXLXmLZCuwBAAzrXUYxnvUpO47oG6RZXTjipwayw pnjs34ik3vf9pyAW8u6BFtZNHK+MoFqNH+Oo/LLwkh1AeAt9umErGYJUCtLyghEVr4vQmRC1 0LT/ZJUXycb5ij/nXCRxrJf8S3tVtVTDuegf+6nQcRiqE5ps4gL7BUFRnpyGdgnyK/fpxQqN TDI9HMMk8MuepIQgaltrKjvmcvcBsK3L2CvcTNGn7spVVvsmTJrX8hYHPK79/XgHatQqnAaK naYDyjvCdJ28hxxliegxggQ8MIIEOAIBATCBuDCBrDEcMBoGA1UEAxMTRXVyb1BLSSBJQUlL IFNpZyBDQTEmMCQGA1UEChMdR3JheiBVbml2ZXJzaXR5IG9mIFRlY2hub2xvZ3kxSDBGBgNV BAsTP0luc3RpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBD b21tdW5pY2F0aW9uczENMAsGA1UEBxMER3JhejELMAkGA1UEBhMCQVQCBwNR0CHjMZcwCQYF Kw4DAhoFAKCCAlgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MDgxMjEyMTU1MjU1WjAjBgkqhkiG9w0BCQQxFgQUrgTc740h/TyFVF2beeQ61f9XgxEwXwYJ KoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHJBgkrBgEEAYI3EAQx gbswgbgwgawxHDAaBgNVBAMTE0V1cm9QS0kgSUFJSyBFbmMgQ0ExJjAkBgNVBAoTHUdyYXog VW5pdmVyc2l0eSBvZiBUZWNobm9sb2d5MUgwRgYDVQQLEz9JbnN0aXR1dGUgZm9yIEFwcGxp ZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxDTALBgNVBAcT BEdyYXoxCzAJBgNVBAYTAkFUAgcDAK1qvxKLMIHLBgsqhkiG9w0BCRACCzGBu6CBuDCBrDEc MBoGA1UEAxMTRXVyb1BLSSBJQUlLIEVuYyBDQTEmMCQGA1UEChMdR3JheiBVbml2ZXJzaXR5 IG9mIFRlY2hub2xvZ3kxSDBGBgNVBAsTP0luc3RpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1h dGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczENMAsGA1UEBxMER3JhejELMAkG A1UEBhMCQVQCBwMArWq/EoswDQYJKoZIhvcNAQEBBQAEggEAN7Mxh2aY62huauu+ZZ5rYkYc rycaQWF90JnuTbCIZsgU79l227unFODHGgWaorzstokd57/mJ0Q4c/hwZGdu7tAc2++KdlWo 2Rc5s8dVj5duX0YYA/6McHKP2+fxbAaKkwR/CdM5XbZYxxhcZ7Dn5yNyEo4HDQ/0BWkukJQp z5R+IvL+2rLUgIDgsCM3ku1MFtVGJyyVG7e97FvSxFe5QFSKQv/+FqTKrFvzx1QPzf94KKCw y4Bg64IAAzoAjy9pNZip0j3X0fA/bhNNB9J2pF/LGdW3sP2eUAmYpmhGd/KlmJH0PUignA2I cmI7o/iPR38dmf3gsJ/KYQbTQ6+BQQAAAAAAAA== --------------ms080405070504050303090305-- From hash-forum@nist.gov Fri Dec 12 11:00:59 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBCJ0rWO010050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Dec 2008 11:00:54 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBCIxZ2V028963; Fri, 12 Dec 2008 13:59:39 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBCIwaUG026370; Fri, 12 Dec 2008 13:58:36 -0500 Date: Fri, 12 Dec 2008 13:58:36 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Ivica Nikolic" To: Multiple recipients of list Subject: Re: Cryptanalysis of the Hash Function LUX-256 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <200812121450263120358@gmail.com> Content-Type: multipart/alternative; boundary="----=_Part_8701_28906839.1229107706910" MIME-Version: 1.0 In-Reply-To: <200812121450263120358@gmail.com> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 12 Dec 2008 11:00:55 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 314 ------=_Part_8701_28906839.1229107706910 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear Shuang Wu, the date of this publication is of course impressive (Dec-3), while the submission appeared on the NIST web-site on Dec-9. As far as I know we did not share the details of our submission with your team. Still it is nice to know that someone is so motivated to study our function. Technical comments: the observation about simple 1-round relation between consecutive 32-bit words of the 256-bit digest is valid and steams from the bug in the output phase function, which gradually constructs the final digest 32-bits at a time instead of outputting it in one shot. A trivial fix would be to output the whole 256-bit core immediately after the blank rounds. We can increase the number of blank rounds from 16 to 20 and to drop all the 8 output phase rounds. This would speed up the final phase of LUX by 4 rounds. We believe that the free-start collision and free-start preimage observations are irrelevant, since they would apply to any P-sponge function and are trivially found due to invertibility of P-sponge constructions. Free-start for 768-bit value is a bit much to ask for. Best regards, Alex, Ivica, Dmitry. On Fri, Dec 12, 2008 at 8:04 AM, catmaniii wrote: > Hi all, > > We have found some non-random properties of LUX due to the > weakness of origin shift vector (0,1,3,4). We also give reduced blank > round collision attack, free-start collision attack and free-start > preimage attack on LUX-256. The two collision attacks are trivial. > The free-start preimage attack has complexity of about 2^80 and > requires negligible memory. > > > ------------------------------ > Best regards, > Shuang Wu > > State Key Laboratory of Information Security, > Chinese Academy of Sciences. > 2008-12-12 > ------=_Part_8701_28906839.1229107706910 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear Shuang Wu,

the date of this publication is of course impressive (Dec-3), while the submission appeared on the NIST web-site on Dec-9. As far as I know we did not share the details of our submission with your team.
Still it is nice to know that someone is so motivated to study our function.

Technical comments:

the observation about simple 1-round relation between consecutive 32-bit words of the 256-bit digest is valid and steams from the bug in the output phase function, which gradually constructs the final digest 32-bits at a time instead of outputting it in one shot.

A trivial fix would be to output the whole 256-bit core immediately after the blank rounds. We can increase the number of blank rounds from 16 to 20 and to drop all the 8 output phase rounds. This would speed up the final phase of LUX by 4 rounds.

We believe that the  free-start collision and free-start preimage observations are irrelevant, since they would apply to any P-sponge function and are trivially found due to invertibility of P-sponge constructions. Free-start for 768-bit value is a bit much to ask for.

Best regards,
Alex, Ivica, Dmitry.

On Fri, Dec 12, 2008 at 8:04 AM, catmaniii <catmaniii@gmail.com> wrote:
Hi all,
 
We have found some non-random properties of LUX due to the
weakness of origin shift vector (0,1,3,4). We also give reduced blank
round collision attack, free-start collision attack and free-start
preimage attack on LUX-256. The two collision attacks are trivial.
The free-start preimage attack has complexity of about 2^80 and
requires negligible memory.
 
 
Best regards,
Shuang Wu
 
State Key Laboratory of Information Security,
Chinese Academy of Sciences.
2008-12-12


------=_Part_8701_28906839.1229107706910-- From hash-forum@nist.gov Fri Dec 12 13:18:42 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBCLIaLK029072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Dec 2008 13:18:38 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBCLHLEW003117; Fri, 12 Dec 2008 16:17:26 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBCLG0ff010458; Fri, 12 Dec 2008 16:16:00 -0500 Date: Fri, 12 Dec 2008 16:16:00 -0500 Message-Id: <4942d43f.2183420a.0acc.fffffdc4@mx.google.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Danilo Gligoroski" To: Multiple recipients of list Subject: To NIST: Request for clarification X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Microsoft Office Outlook 12.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0038_01C95CA7.02319EF0" MIME-Version: 1.0 In-Reply-To: <49400E39.4090702@nist.gov> References: <49400E39.4090702@nist.gov> X-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 12 Dec 2008 13:18:38 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 315 This is a multipart message in MIME format. ------=_NextPart_000_0038_01C95CA7.02319EF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear NIST, I want from you one clarification. In the call for the hash competition, in the part 4.A iii, you say: Additional security requirements of the hash functions In addition to the specific requirements mentioned above, NIST expects the SHA-3 algorithm of message digest size n to meet the following security requirements at a minimum. These requirements are believed to be satisfiable by fairly standard hash algorithm constructions; any result that shows that the candidate algorithm does not meet these requirements will be considered to be a serious attack. Collision resistance of approximately n/2 bits, Preimage resistance of approximately n bits, Second-preimage resistance of approximately n-k bits for any message shorter than 2^k bits, Resistance to length-extension attacks, and . ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ My question is how strong should be the resistance to length-extension attacks? For other resistances you are very specific and you are expressing the resistance in exact number of bits, but for length-extension attack you are not so precise. For example, many of the hash candidates that have double or wide pipe constructions (with the width at least 2n) has resistance of at least n bits. That is something that I would naturally expect from a hash function, but since you are not very specific about this matter please clarify this issue. All other colleagues that have some opinion on this issue are also welcome to comment. Regards, Danilo Gligoroski! ------=_NextPart_000_0038_01C95CA7.02319EF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear NIST,

 

I want from you one clarification.

In the call for the hash competition, in the part 4.A = iii, you say:

 

<Quote>

 

Additional security requirements of the hash functions

 

In addition to the = specific requirements mentioned above, NIST expects the SHA-3 algorithm of = message digest size n to meet the following security requirements at a = minimum. These requirements are believed to be satisfiable by fairly standard = hash algorithm constructions; any result that shows that the candidate = algorithm does not meet these requirements will be considered to be a serious = attack.

. Collision resistance of approximately n/2 bits,

. Preimage resistance of approximately n bits,

. Second-preimage resistance of approximately n-k bits for any message shorter than = 2^k bits,

. Resistance to length-extension attacks, and …

           = ;         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=

</Quote>

 

My question is how strong should be the resistance to length-extension attacks?

For other resistances you are very specific and you are = expressing the resistance in exact number of bits, but for length-extension attack = you are not so precise.

 

For example, many of the hash candidates that have double = or wide pipe constructions (with the width at least 2n) has resistance of = at least n bits. That is something that I would naturally expect from a hash = function, but since you are not very specific about this matter please clarify = this issue.

All other colleagues that have some opinion on this issue = are also welcome to comment.

 

Regards,

Danilo Gligoroski!

 

------=_NextPart_000_0038_01C95CA7.02319EF0-- From hash-forum@nist.gov Fri Dec 12 13:47:09 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBCLl4JD031873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Dec 2008 13:47:05 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBCLjxCF025289; Fri, 12 Dec 2008 16:46:03 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBCLjWNn005052; Fri, 12 Dec 2008 16:45:32 -0500 Date: Fri, 12 Dec 2008 16:45:32 -0500 Message-Id: <4942da30.02bb420a.14aa.0c48@mx.google.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Danilo Gligoroski" To: Multiple recipients of list Subject: OFFICIAL COMMENT: Cheetah X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Microsoft Office Outlook 12.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0040_01C95CAA.8CBECCC0" MIME-Version: 1.0 X-Cc: X-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 12 Dec 2008 13:47:06 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 316 This is a multipart message in MIME format. ------=_NextPart_000_0040_01C95CAA.8CBECCC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cheetah hash function is not resistant against length-extension attack. The mechanism in Cheetah to protect against length-extension attack is the permutation of the chaining value before the last invocation of the compression function. However, the initial chaining value of Cheetah is a zero vector of 256 or 512 bits. That means that every hashing of short messages that have length less than 959 bits will suffer from the trivial length-extension attack because the permutation of the initial zero vector is known to the attacker. Best regards, Danilo Gligoroski ------=_NextPart_000_0040_01C95CAA.8CBECCC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Cheetah hash function is not = resistant against length-extension attack.

 

The mechanism in Cheetah to = protect against length-extension attack is the permutation of the chaining value before = the last invocation of the compression function. However, the initial = chaining value of Cheetah is a zero vector of 256 or 512 bits. That means that = every hashing of short messages that have length less than 959 bits will = suffer from the trivial length-extension attack because the permutation of the = initial zero vector is known to the attacker.

 

Best = regards,

Danilo = Gligoroski

 

------=_NextPart_000_0040_01C95CAA.8CBECCC0-- From hash-forum@nist.gov Fri Dec 12 14:31:13 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBCMV7oP004235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Dec 2008 14:31:09 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBCMU0kV014796; Fri, 12 Dec 2008 17:30:04 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBCMRGe9023617; Fri, 12 Dec 2008 17:27:16 -0500 Date: Fri, 12 Dec 2008 17:27:16 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Ivica Nikolic" To: Multiple recipients of list Subject: Second preimage attack on Abacus X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/alternative; boundary="----=_Part_11311_25726405.1229120307715" MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 12 Dec 2008 14:31:09 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 317 ------=_Part_11311_25726405.1229120307715 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, we found a second preimage attack on Abacus. The attack requires 2^{172} computations and negligible memory for all digests. The details are available at: http://lj.streamclub.ru/papers/hash/abacus.pdf Best regards, Ivica Nikolic and Dmitry Khovratovich Laboratory of Algorithms, Cryptography and Security, University of Luxembourg ------=_Part_11311_25726405.1229120307715 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

we found a second preimage attack on Abacus. The attack requires 2^{172} computations and negligible memory for all digests.
The details are available at:

Best regards,
Ivica Nikolic and Dmitry Khovratovich 

Laboratory of Algorithms, Cryptography and Security,
University of Luxembourg
------=_Part_11311_25726405.1229120307715-- From hash-forum@nist.gov Fri Dec 12 19:19:47 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBD3JghH028055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Dec 2008 19:19:43 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBD3GTlQ011639; Fri, 12 Dec 2008 22:18:35 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBD3CnVo019669; Fri, 12 Dec 2008 22:12:49 -0500 Date: Fri, 12 Dec 2008 22:12:49 -0500 Message-Id: <494323F1.1030502@mit.edu> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: David Wilson To: Multiple recipients of list Subject: regarding etiquette X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 12 Dec 2008 19:19:44 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 318 Hi, Is there a consensus opinion regarding the etiquette of going about publicizing attacks on SHA-3 candidates? So far, when I have come up with an attack, I have contacted the authors first and asked them to respond before I made the attack public. I feel this is not only polite, but gives us a chance to first iron out any details privately (if I have misunderstood their algorithm, if they have a buggy reference implementation, etc.). However, I recognize that there is certainly a desire to publish one's results first. Also, from a practical perspective, earlier publications have the potential to reduce duplicate work. (If a function is broken but the break is not publicized for a day or two, others might expend time working on the same function.) What are people's thoughts on this? [I admittedly bring this up for somewhat selfish reasons--late Wednesday evening I came up with an attack on Abacus similar to the one just sent out, and have been emailing back and forth with the author since then.] Regards, David A. Wilson From hash-forum@nist.gov Fri Dec 12 21:36:28 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBD5aNjc004115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Dec 2008 21:36:24 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBD5XJLE025968; Sat, 13 Dec 2008 00:35:23 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBD5UVYo022986; Sat, 13 Dec 2008 00:30:31 -0500 Date: Sat, 13 Dec 2008 00:30:31 -0500 Message-Id: <052264A5-8664-4DDF-A196-DAEBF3A8E563@cryptolib.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Sean O'Neil" To: Multiple recipients of list Subject: Re: regarding etiquette X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: <494323F1.1030502@mit.edu> In-Reply-To: <494323F1.1030502@mit.edu> Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 12 Dec 2008 21:36:24 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 319 On 13 Dec 2008, at 04:12, David Wilson wrote: > Is there a consensus opinion regarding the etiquette of going about > publicizing attacks on SHA-3 candidates? Dear David, There is no etiquette, unfortunately. You are dealing mostly with people whose focus is on their academic career alone. The sad reality is that nobody cares about ethics in cryptology. People are far too happy to steal each other's work and if they come up with an attack, it gets published either as soon as possible (before someone else does it) or at the worst possible moment, causing as much damage (both academically and reputation wise) as possible, while at the same time trying to attract as much publicity as possible. Pleas like yours are generally left ignored. Several people including myself have written about this unhealthy competition problem in cryptology, but the situation is not going to change any time soon. I only hope that the practice of publishing pseudo-attacks (or as DJB calls them, crackpot attacks) rushing to declare algorithms as "broken" will discontinue. Too many algorithms got labelled as "broken" either by attacks with total time*memory complexity clearly far beyond the generic parallel brute-force, TMDTO or MITM, and algorithms with tunable parameters by attacks breaking only one of the variants. > So far, when I have come up with an attack, I have contacted the > authors first and asked them to respond before I made the attack > public. That is the most decent and honourable thing to do. Unfortunately, almost nobody does that. You have my voice asking all the attackers to have the decency to contact the authors before publishing their attacks. As an example, my previous design VEST got hammered at the worst possible moment thanks to a small typo that had creeped into its smallest simplest component. A number of good algorithms could have been saved. The world can benefit a lot more from one good secure algorithm than from a whole lot of broken ones... > I feel this is not only polite, but gives us a chance to first iron > out any details privately (if I have misunderstood their algorithm, > if they have a buggy reference implementation, etc.). Absolutely right. > Also, from a practical perspective, earlier publications have the > potential to reduce duplicate work. Oh, that is highly unlikely to happen. A lot of people are looking at the same functions at the same time and continue looking at them even after they got broken. Even if your results are similar to the attack published just before yours, there is a good chance that even the slightest difference in your attack can contribute to further understanding of security of the algorithm and can potentially be used in other attacks. I can only speak for myself, but IMHO even if complexity of your attack is higher than the previously published attacks, it is still interesting and something new can be learned from it or something old can be reminded to us. 33 years of publications in cryptology cannot compare with thousands of years of publications in other sciences, so every publication counts. Best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. From hash-forum@nist.gov Fri Dec 12 22:32:59 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBD6Wsx6007569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Dec 2008 22:32:55 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBD6Vg4K018516; Sat, 13 Dec 2008 01:31:47 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBD6QxFp001013; Sat, 13 Dec 2008 01:26:59 -0500 Date: Sat, 13 Dec 2008 01:26:59 -0500 Message-Id: <77E8A818-5279-4A62-B253-0FECF60F4596@cryptolib.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Sean O'Neil" To: Multiple recipients of list Subject: Narrow-pipe designs X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 12 Dec 2008 22:32:55 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 320 A number of people are asking a good question: Can someone please publish a paper listing all the narrow-pipe hashes as broken by design, so we could all focus on the good ones with 2x and slightly larger states? <2x is vulnerable by design, >=2x up to 2.5x (or possibly up to 3x) is the optimal choice, but all the >=4x monsters and some of the designs such as Crunch or FSB with their reference code requiring MEGABYTES (!!!) of tables to function are certainly gone too far. With all due respect to their authors, I wouldn't bother looking at those as a total waste of time. Personally, the hash functions with 4x and larger states make me wanna puke, but technically, they would simply never fit in 128 or 256 bytes of RAM of the [yes, very] popular 8-bit microcontrollers that may want to use some of it for other purposes than merely storing the entire hash state with no room left for a single variable. Best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. From hash-forum@nist.gov Fri Dec 12 23:29:06 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBD7T1Lu011330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Dec 2008 23:29:02 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBD7Pttu028267; Sat, 13 Dec 2008 02:27:59 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBD7NLcw012296; Sat, 13 Dec 2008 02:23:21 -0500 Date: Sat, 13 Dec 2008 02:23:21 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Sean O'Neil" To: Multiple recipients of list Subject: Cheetah.zip X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 12 Dec 2008 23:29:02 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 321 http://csrc.nist.gov/groups/ST/hash/sha-3/Round1/documents/ Cheetah.zip is the only archive without the root directory. Can the person responsible for it please repack it moving its contents to Cheetah/ for consistency? Anyone who tried to unpack all the archives at once must have hit it. A few archives also have their directory names different from their archive names. It's a small thing, but such small inconsistencies slow down automated analysis demanding manual intervention. It would be best if they all matched the names of the hash functions. Thanks! Best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. From hash-forum@nist.gov Sat Dec 13 00:25:11 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBD8P652015754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 13 Dec 2008 00:25:07 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBD8M60t013782; Sat, 13 Dec 2008 03:24:12 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBD8JUiT021653; Sat, 13 Dec 2008 03:19:30 -0500 Date: Sat, 13 Dec 2008 03:19:30 -0500 Message-Id: <3891D3C5-E01C-4840-A8D1-EB54BF62E89C@cryptolib.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Sean O'Neil" To: Multiple recipients of list Subject: Re: Cheetah.zip X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 13 Dec 2008 00:25:07 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 322 > http://csrc.nist.gov/groups/ST/hash/sha-3/Round1/documents/ > Cheetah.zip is the only archive without the root directory. Also, Fugue.zip contains gzipped tar balls instead of directories, Hamsi.zip has a directory and an archive with its reference implementation in it and it is not clear which one of the two we are to use as their contents are slightly different, Spectral_Hash.zip directory names are all cut to 8 letters and capitalized, and A half of the archives have spaces instead of the underscores and some of them have odd capitalizations that may cause problems for unix users. Everyone will have to rename them all by hand... Don't shoot! Best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. From hash-forum@nist.gov Sat Dec 13 04:39:20 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBDCdC9T007319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 13 Dec 2008 04:39:15 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBDCRhvj010371; Sat, 13 Dec 2008 07:30:06 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBDCNY58006801; Sat, 13 Dec 2008 07:23:35 -0500 Date: Sat, 13 Dec 2008 07:23:34 -0500 Message-Id: <79B77C4C1E604E45967DBEA02EF6ED94@BobsDell> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Bob Hattersley" To: Multiple recipients of list Subject: RE: Narrow-pipe designs X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas In-Reply-To: <77E8A818-5279-4A62-B253-0FECF60F4596@cryptolib.com> X-Mailer: Microsoft Office Outlook 11 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 References: <77E8A818-5279-4A62-B253-0FECF60F4596@cryptolib.com> X-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 13 Dec 2008 04:39:16 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 323 A somewhat intemperate post perhaps, but there's an interesting question in there. Waterfall would be a 6x design in this classification and therefore a "monster". (Since I have no desire to make anyone ill, I recommend that sensitive souls should avoid any further contact with it.) I worked under the (possibly invalid) assumption that 512 bytes of RAM (and 2kB of program storage) was a reasonable target. 1kB RAM seems to be widely used today, and memory doesn't seem to be getting more expensive. Most microcontrollers are not used in situations where cryptography has any relevance. But what is the general opinion? Perhaps more important - what is NIST's view? Bob Hattersley (Waterfall) -----Original Message----- From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Sean O'Neil Sent: 13 December 2008 06:27 To: Multiple recipients of list Subject: Narrow-pipe designs A number of people are asking a good question: Can someone please publish a paper listing all the narrow-pipe hashes as broken by design, so we could all focus on the good ones with 2x and slightly larger states? <2x is vulnerable by design, >=2x up to 2.5x (or possibly up to 3x) is the optimal choice, but all the >=4x monsters and some of the designs such as Crunch or FSB with their reference code requiring MEGABYTES (!!!) of tables to function are certainly gone too far. With all due respect to their authors, I wouldn't bother looking at those as a total waste of time. Personally, the hash functions with 4x and larger states make me wanna puke, but technically, they would simply never fit in 128 or 256 bytes of RAM of the [yes, very] popular 8-bit microcontrollers that may want to use some of it for other purposes than merely storing the entire hash state with no room left for a single variable. Best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. From hash-forum@nist.gov Sat Dec 13 07:13:54 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBDFDn2C021297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 13 Dec 2008 07:13:50 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBDFALH2010018; Sat, 13 Dec 2008 10:12:25 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBDF7TUM001247; Sat, 13 Dec 2008 10:07:29 -0500 Date: Sat, 13 Dec 2008 10:07:29 -0500 Message-Id: <10D7F486-0C2D-4AC3-89B0-1F044005E455@mac.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Adam Montville To: Multiple recipients of list Subject: Re: Narrow-pipe designs X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.929.2) References: <77E8A818-5279-4A62-B253-0FECF60F4596@cryptolib.com> <79B77C4C1E604E45967DBEA02EF6ED94@BobsDell> In-reply-to: <79B77C4C1E604E45967DBEA02EF6ED94@BobsDell> X-To: hash-forum@nist.gov Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 13 Dec 2008 07:13:50 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 324 On Dec 13, 2008, at 4:23 AM, Bob Hattersley wrote: > > A somewhat intemperate post perhaps, but there's an interesting > question in > there. Waterfall would be a 6x design in this classification and > therefore > a "monster". (Since I have no desire to make anyone ill, I > recommend that > sensitive souls should avoid any further contact with it.) I worked > under > the (possibly invalid) assumption that 512 bytes of RAM (and 2kB of > program > storage) was a reasonable target. 1kB RAM seems to be widely used > today, > and memory doesn't seem to be getting more expensive. Most > microcontrollers > are not used in situations where cryptography has any relevance. It seems to me that device connectivity is on the rise, whether such connectivity is performed via RF scanning on an intermittent basis or via an always-on Internet connection. Further, it seems that "small" devices are increasing their use of stored information. It seems that, as time passes, the relevance of cryptographic application in this area will increase - the assertion being that where communication channels exist and/or storage of information is required, there is cryptographic relevance. Looking to the future, what if there exists an optimal submission for 8-bit environments which is sub-optimal for 16-/32-/64-bit environments and another submission which is sub-optimal for 8-bit environments which excels in the 16-/32-/64-bit environments? For that matter, should any (at least theoretical) consideration be made for the possibility of 128-bit environments (if we're looking at longevity over one hundred years, this may not be unlikely)? > > > But what is the general opinion? Perhaps more important - what is > NIST's > view? I would hope that NIST's view would reflect the needs and experience of the industry. > > > Bob Hattersley (Waterfall) > > -----Original Message----- > From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of > Sean > O'Neil > Sent: 13 December 2008 06:27 > To: Multiple recipients of list > Subject: Narrow-pipe designs > > > A number of people are asking a good question: > > Can someone please publish a paper listing all the narrow-pipe > hashes as > broken by design, so we could all focus on the good ones with 2x and > slightly larger states? > > <2x is vulnerable by design, >=2x up to 2.5x (or possibly up to 3x) > is the > optimal choice, but all the >=4x monsters and some of the designs > such as > Crunch or FSB with their reference code requiring MEGABYTES (!!!) of > tables > to function are certainly gone too far. > With all due respect to their authors, I wouldn't bother looking at > those as > a total waste of time. > > Personally, the hash functions with 4x and larger states make me > wanna puke, > but technically, they would simply never fit in 128 or > 256 bytes of RAM of the [yes, very] popular 8-bit microcontrollers > that may > want to use some of it for other purposes than merely storing the > entire > hash state with no room left for a single variable. > > Best regards, > Sean O'Neil > http://www.enrupt.com/ - Raising the bar. > > > From hash-forum@nist.gov Sat Dec 13 07:56:11 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBDFu5vQ024511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 13 Dec 2008 07:56:07 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBDFrChw027693; Sat, 13 Dec 2008 10:55:16 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBDFoeYC021150; Sat, 13 Dec 2008 10:50:40 -0500 Date: Sat, 13 Dec 2008 10:50:40 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Sean O'Neil" To: Multiple recipients of list Subject: Re: Narrow-pipe designs X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: <77E8A818-5279-4A62-B253-0FECF60F4596@cryptolib.com> <79B77C4C1E604E45967DBEA02EF6ED94@BobsDell> In-Reply-To: <79B77C4C1E604E45967DBEA02EF6ED94@BobsDell> Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 13 Dec 2008 07:56:07 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 325 On 13 Dec 2008, at 13:23, Bob Hattersley wrote: > Most microcontrollers are not used in situations where cryptography > has any relevance. Putting my weak stomach incapable of digesting 6x hashes aside, this argument is invalid. A lot smaller devices are and will continue to be used in situations where cryptography is essential. Lacking proper algorithms, the companies are forced to invent their own. In the end, the whole world suffers with billions of tiny microchips responsible for different aspects of its security. Standardise monsters and the industry will continue responding with the likes of Mifare: http:// www.computerworlduk.com/technology/mobile-wireless/apps-rfid/news/ index.cfm?newsid=8035 while we can choose a good fast algorithm that fits in a smaller area and consumes less power. We don't want to leave the users of billions of 8-bit microcontrollers without a choice. What is the problem? Let's give them something they can all use. Because we can. [Yes, we can!] It's not like we have 4-bit or even 7-bit microcontrollers to worry about... Best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. PS: I'm sorry, Bob, but 6x does not have my vote. From hash-forum@nist.gov Sat Dec 13 08:08:05 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBDG80HE025528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 13 Dec 2008 08:08:01 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBDG76oB018405; Sat, 13 Dec 2008 11:07:10 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBDG6hj3019828; Sat, 13 Dec 2008 11:06:43 -0500 Date: Sat, 13 Dec 2008 11:06:43 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: zooko To: Multiple recipients of list Subject: Re: Narrow-pipe designs X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: <77E8A818-5279-4A62-B253-0FECF60F4596@cryptolib.com> <79B77C4C1E604E45967DBEA02EF6ED94@BobsDell> In-Reply-To: <79B77C4C1E604E45967DBEA02EF6ED94@BobsDell> Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 13 Dec 2008 08:08:01 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 326 Dear Bob Hattersley: Thank you for posting a warning label for people with extra-wide-pipe- induced nausea. You asked for opinions, and my opinion is that SHA-3 needs to be as widely applicable as possible (without sacrificing security). One of the major advantages of standards is that people from separate fields of endeavour can come together to cooperate and find that they are already familiar with some of the same tools. If SHA-3 can't be implemented in limited RAM, or if it requires special hardware to perform adequately, or if it uses too much power for certain deployments, then this excludes the people from some of those fields from this benefit. (This is why I would favor a candidate which is acceptably efficient in all the applications that we can think of over one that is brilliantly efficient in some usage but inefficient in others.) SHA-3 ought to be a secure and widely applicable hash function, but it will not be the best hash function for all uses, it won't be the last hash function invented, nor the only hash function that people use. If your Waterfall design does not become SHA-3, then it, along with the other 53 published designs that didn't become SHA-3 will still be valuable for us to learn from and potentially useful. Regards, Zooko --- http://allmydata.org -- Tahoe, the Least-Authority Filesystem http://allmydata.com -- back up all your files for $10/month From hash-forum@nist.gov Sat Dec 13 08:48:45 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBDGmeLa028602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 13 Dec 2008 08:48:41 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBDGltpF024262; Sat, 13 Dec 2008 11:47:56 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBDGlJED001595; Sat, 13 Dec 2008 11:47:19 -0500 Date: Sat, 13 Dec 2008 11:47:19 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Paul Hoffman To: Multiple recipients of list Subject: Re: regarding etiquette X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: text/plain; charset="us-ascii" X-To: hash-forum@nist.gov References: <494323F1.1030502@mit.edu> <052264A5-8664-4DDF-A196-DAEBF3A8E563@cryptolib.com> In-Reply-To: <052264A5-8664-4DDF-A196-DAEBF3A8E563@cryptolib.com> Mime-Version: 1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 13 Dec 2008 08:48:42 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 327 At 12:30 AM -0500 12/13/08, Sean O'Neil wrote: >There is no etiquette, unfortunately. That may be true for you, but not for other researchers. > You are dealing mostly with people whose focus is on their academic career alone. Can you back up that "mostly" statement with facts? So far, we have seen many counter-examples on this list, and some off-list discussions as well. You don't need to be a mathematician to know that there is a huge difference between "many" and "most". >The sad reality is that nobody cares about ethics in cryptology. I guess I and many of my colleagues, as well as many others on this list, are nobodies, then. So be it. A different view would be that there is a wide variety of etiquettes of going about publicizing attacks on SHA-3 candidates. Etiquette comes from ethics. Some people will form their ethics of publishing attacks based on a desire for understanding; others based on a desire to help the cryptographic community become wiser; others based on a desire to help the end uses of the chosen hash function; others based on advancing themselves personally or in their career; others on the satisfaction of trashing the authors of the attacked proposal. Still others will base their ethics by watching others and trying to figure out what the group's ethics is; those folks will clearly be at a loss. Translating any of those ethics into etiquette is up to the individual. --Paul Hoffman, Director --VPN Consortium From hash-forum@nist.gov Sat Dec 13 09:10:33 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBDHASBB030725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 13 Dec 2008 09:10:29 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBDH24B3019355; Sat, 13 Dec 2008 12:02:07 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBDH1dcd029657; Sat, 13 Dec 2008 12:01:39 -0500 Date: Sat, 13 Dec 2008 12:01:39 -0500 Message-Id: <20081213180045.15342cc1jwcxshts@webmail.tugraz.at> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Christian Rechberger To: Multiple recipients of list Subject: Re: Narrow-pipe designs X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit X-Organization: Graz University of Technology Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" MIME-Version: 1.0 In-Reply-To: <10D7F486-0C2D-4AC3-89B0-1F044005E455@mac.com> References: <77E8A818-5279-4A62-B253-0FECF60F4596@cryptolib.com> <79B77C4C1E604E45967DBEA02EF6ED94@BobsDell> <10D7F486-0C2D-4AC3-89B0-1F044005E455@mac.com> X-To: hash-forum@nist.gov, Adam Montville X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 13 Dec 2008 09:10:30 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 328 Quoting Adam Montville : [snip] > Looking to the future, what if there exists an optimal submission > for 8-bit environments which is sub-optimal for 16-/32-/64-bit > environments and another submission which is sub-optimal for 8-bit > environments which excels in the 16-/32-/64-bit environments? For Predictions, especially about the future, seem difficult ;-) Clearly, it seems a desirable SHA-3 should be flexible enough to be implementable with all kinds of register sizes without penalties because some operations assume a particular wordsize. > that matter, should any (at least theoretical) consideration be made > for the possibility of 128-bit environments (if we're looking at > longevity over one hundred years, this may not be unlikely)? Even today, this does not stop at 64-bits. Current SSE2 register sizes are already 128 bits. And 256-bit register sizes are on the horizon (e.g. Intel AVX [1], but there are probably other examples as well). Cheers, Christian [1] http://software.intel.com/en-us/articles/intel-avx-new-frontiers-in-performance-improvements-and-energy-efficiency From hash-forum@nist.gov Sat Dec 13 10:08:40 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBDI8Z62003431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 13 Dec 2008 10:08:36 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBDHvxQf020699; Sat, 13 Dec 2008 12:58:01 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBDHvMkc008375; Sat, 13 Dec 2008 12:57:22 -0500 Date: Sat, 13 Dec 2008 12:57:22 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Sean O'Neil" To: Multiple recipients of list Subject: Re: cryptanalysis of Twister X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed References: <494288D7.7060108@iaik.tugraz.at> In-Reply-To: <494288D7.7060108@iaik.tugraz.at> Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 13 Dec 2008 10:08:36 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 329 On 12 Dec 2008, at 16:59, Martin Schläffer wrote: > The attack can be extended to a theoretical collision attack on the > hash function Twister-512 with a complexity of about 2^231.5 with > different time-memory tradeoffs. You mean with complexity of about 2^231.5 operations multiplied by 2^172.7 memory? Wouldn't those 2^160 circuits find a collision in 2^96 time for any hash? It is so tempting to omit that annoying memory requirement, isn't it? And then before you know it, the hash is declared "broken". I am not saying that the cryptanalysis itself is not valuable or that pseudo-collisions in 2^26.5 operations is not a potentially serious threat. I just find it increasingly annoying having to check every single paper for the fine print to see if it is actually cheaper than the brute-force or other generic attacks or if the authors "forgot" to mention memory the size of our galaxy. And a lot of people just read the announcement and trust the experts. They see 2^231.5 < 2^256, they assume that it's broken and the word spreads... Best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. From hash-forum@nist.gov Sat Dec 13 10:42:11 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBDIg6Ue006386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 13 Dec 2008 10:42:07 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBDId7Gl009133; Sat, 13 Dec 2008 13:39:09 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBDIcOfx024409; Sat, 13 Dec 2008 13:38:24 -0500 Date: Sat, 13 Dec 2008 13:38:24 -0500 Message-Id: <7731938b0812131027h2efea241maa721714db1aa2cd@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Peter Maxwell" To: Multiple recipients of list Subject: Re: regarding etiquette X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <494323F1.1030502@mit.edu> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 In-Reply-To: <494323F1.1030502@mit.edu> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 13 Dec 2008 10:42:08 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 330 Hi David, Personally I agree with your approach, I think it would be good manners to contact the relevant authors first - like you said, even if only to check the details are correct. I'd also guess that this sort of "face-paced" situation will dissipate somewhat in the comming months with the weaker algorithms having been picked-off first. Regards, Peter Maxwell 2008/12/13 David Wilson : > > Hi, > > Is there a consensus opinion regarding the etiquette of going about > publicizing attacks on SHA-3 candidates? > > So far, when I have come up with an attack, I have contacted the authors > first and asked them to respond before I made the attack public. I feel > this is not only polite, but gives us a chance to first iron out any details > privately (if I have misunderstood their algorithm, if they have a buggy > reference implementation, etc.). > > However, I recognize that there is certainly a desire to publish one's > results first. Also, from a practical perspective, earlier publications > have the potential to reduce duplicate work. (If a function is broken but > the break is not publicized for a day or two, others might expend time > working on the same function.) > > What are people's thoughts on this? > > [I admittedly bring this up for somewhat selfish reasons--late Wednesday > evening I came up with an attack on Abacus similar to the one just sent out, > and have been emailing back and forth with the author since then.] > > Regards, > David A. Wilson > > From hash-forum@nist.gov Sat Dec 13 09:31:06 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBDHV1NO032178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 13 Dec 2008 09:31:02 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBDHUFBf010065; Sat, 13 Dec 2008 12:30:18 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBDHTlAt020058; Sat, 13 Dec 2008 12:29:47 -0500 Date: Sat, 13 Dec 2008 12:29:47 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Sean O'Neil" To: Multiple recipients of list Subject: Re: regarding etiquette X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed References: <494323F1.1030502@mit.edu> <052264A5-8664-4DDF-A196-DAEBF3A8E563@cryptolib.com> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 13 Dec 2008 09:31:02 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 331 On 13 Dec 2008, at 17:47, Paul Hoffman wrote: > That may be true for you, but not for other researchers. It is easy to get that impression when your own work gets stolen. I guess this paper would be more palatable for you than my whinging: http://www.ams.org/notices/200708/tx070800972p.pdf "Drama and conflict are inherent in cryptography, which, in fact, can be defined as the science of transmitting and managing information in the presence of an adversary. The “spy vs. spy” mentality of constant competition and rivalry extends to the disciplinary culture of the field. This can get to be excessive — and even childish at times — but it also explains in part why it can be so much fun to do research in cryptography." – Neil Koblitz Best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. From hash-forum@nist.gov Sat Dec 13 09:23:42 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBDHNau4031602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 13 Dec 2008 09:23:37 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBDHG4QN032301; Sat, 13 Dec 2008 12:16:08 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBDHFdGj024530; Sat, 13 Dec 2008 12:15:39 -0500 Date: Sat, 13 Dec 2008 12:15:39 -0500 Message-Id: <20081213180626.189520fyt1sg6k68@webmail.tugraz.at> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Christian Rechberger To: Multiple recipients of list Subject: Re: cryptanalysis of Twister X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Organization: Graz University of Technology Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" MIME-Version: 1.0 In-Reply-To: <494288D7.7060108@iaik.tugraz.at> References: <494288D7.7060108@iaik.tugraz.at> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 13 Dec 2008 09:23:38 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 332 Quoting Martin Schläffer : > Hi all, > > we have found an attack to construct pseudo-collisions for > Twister-{224,256,384,512} with a complexity of about 2^26.5 > compression function evaluations. The attack can be extended to a > theoretical collision attack on the hash function Twister-512 with a > complexity of about 2^231.5 with different time-memory tradeoffs. > > More details can be found in the pdf file, which has been uploaded > to http://ehash.iaik.tugraz.at/uploads/d/dd/Twister_attack.pdf > For the record: The authors of Twister have been informed and acknowledged this note _before_ we put it online. -Christian From hash-forum@nist.gov Sat Dec 13 11:07:22 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBDJ7H0g008445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 13 Dec 2008 11:07:18 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBDJ6Rra009931; Sat, 13 Dec 2008 14:06:31 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBDJ5mni011729; Sat, 13 Dec 2008 14:05:48 -0500 Date: Sat, 13 Dec 2008 14:05:48 -0500 Message-Id: <7731938b0812131100u3c580ad7ra2e8e38aec4a2d6e@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Peter Maxwell" To: Multiple recipients of list Subject: Re: regarding etiquette X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <494323F1.1030502@mit.edu> <7731938b0812131027h2efea241maa721714db1aa2cd@mail.gmail.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 In-Reply-To: <7731938b0812131027h2efea241maa721714db1aa2cd@mail.gmail.com> X-To: "Multiple recipients of list" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 13 Dec 2008 11:07:18 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 333 That should have read "fast-paced"... 2008/12/13 Peter Maxwell : > > Hi David, > > Personally I agree with your approach, I think it would be good > manners to contact the relevant authors first - like you said, even if > only to check the details are correct. I'd also guess that this sort > of "face-paced" situation will dissipate somewhat in the comming > months with the weaker algorithms having been picked-off first. > > Regards, > > Peter Maxwell > > > > > > > 2008/12/13 David Wilson : >> >> Hi, >> >> Is there a consensus opinion regarding the etiquette of going about >> publicizing attacks on SHA-3 candidates? >> >> So far, when I have come up with an attack, I have contacted the authors >> first and asked them to respond before I made the attack public. I feel >> this is not only polite, but gives us a chance to first iron out any details >> privately (if I have misunderstood their algorithm, if they have a buggy >> reference implementation, etc.). >> >> However, I recognize that there is certainly a desire to publish one's >> results first. Also, from a practical perspective, earlier publications >> have the potential to reduce duplicate work. (If a function is broken but >> the break is not publicized for a day or two, others might expend time >> working on the same function.) >> >> What are people's thoughts on this? >> >> [I admittedly bring this up for somewhat selfish reasons--late Wednesday >> evening I came up with an attack on Abacus similar to the one just sent out, >> and have been emailing back and forth with the author since then.] >> >> Regards, >> David A. Wilson >> >> > > From hash-forum@nist.gov Sat Dec 13 11:23:22 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBDJNHVp009701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 13 Dec 2008 11:23:19 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBDJLHrn018670; Sat, 13 Dec 2008 14:22:24 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBDJJpfq007018; Sat, 13 Dec 2008 14:19:51 -0500 Date: Sat, 13 Dec 2008 14:19:51 -0500 Message-Id: <93B90010EA4D4981985FE1DA669EA8FE@CraigLaptop> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Craig" To: Multiple recipients of list Subject: eHash/SHA-3 Zoo X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Microsoft Windows Mail 6.0.6001.18000 Content-Transfer-Encoding: 7bit Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original MIME-Version: 1.0 In-Reply-To: <7731938b0812131100u3c580ad7ra2e8e38aec4a2d6e@mail.gmail.com> References: <494323F1.1030502@mit.edu> <7731938b0812131027h2efea241maa721714db1aa2cd@mail.gmail.com> <7731938b0812131100u3c580ad7ra2e8e38aec4a2d6e@mail.gmail.com> X-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 13 Dec 2008 11:23:19 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, STOX_REPLY_TYPE shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: Junk X-UID: 334 As an party interested in potentially submitting some observations on Blender (after disscussion with the author), what steps are required to submit a paper to the SHA-3 Zoo? I seem to be unable to register. Is there anyone in particular that I should contact? Many thanks, and apologies if I am missing the obvious, Craig Newbold From hash-forum@nist.gov Sat Dec 13 12:21:45 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBDKLee1014521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 13 Dec 2008 12:21:41 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBDKFdP0006785; Sat, 13 Dec 2008 15:15:41 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBDKEsVI016682; Sat, 13 Dec 2008 15:14:54 -0500 Date: Sat, 13 Dec 2008 15:14:54 -0500 Message-Id: <20081213210115.87767h46rbok44nk@webmail.tugraz.at> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Christian Rechberger To: Multiple recipients of list Subject: Re: eHash/SHA-3 Zoo X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Organization: Graz University of Technology Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" MIME-Version: 1.0 In-Reply-To: <93B90010EA4D4981985FE1DA669EA8FE@CraigLaptop> References: <494323F1.1030502@mit.edu> <7731938b0812131027h2efea241maa721714db1aa2cd@mail.gmail.com> <7731938b0812131100u3c580ad7ra2e8e38aec4a2d6e@mail.gmail.com> <93B90010EA4D4981985FE1DA669EA8FE@CraigLaptop> X-To: hash-forum@nist.gov, Craig X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 13 Dec 2008 12:21:42 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 335 Quoting Craig : > > As an party interested in potentially submitting some observations > on Blender (after disscussion with the author), what steps are > required to submit a paper to the SHA-3 Zoo? I seem to be unable to > register. > > Is there anyone in particular that I should contact? Dear Craig, at the moment, editing the SHA-3 zoo is restricted to interested parties within ECRYPT for various reasons (with a single exception being the editor of the "hash function lounge"). People sent us their results via sha3zoo@iaik.tugraz.at. One of the editors is usually taking care of your input very quickly. Thanks for your hint that this is not clear. (This was also pointed out to us by private mail). We shall make this more clear asap. Cheers, Christian From hash-forum@nist.gov Sat Dec 13 15:13:54 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBDNDmFx026568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 13 Dec 2008 15:13:49 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBDNChH4020445; Sat, 13 Dec 2008 18:12:45 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBDNAjA5001302; Sat, 13 Dec 2008 18:10:45 -0500 Date: Sat, 13 Dec 2008 18:10:45 -0500 Message-Id: <494440B6.1050009@mit.edu> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Ronald L. Rivest" To: Multiple recipients of list Subject: Re: Submissions, compiled X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: References: MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 13 Dec 2008 15:13:49 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 336 Hi Sean -- Thanks for compiling these tables; they are very interesting. In the case of MD6, our "reference implementation" (which is identical to our "optimized" implementations) was written with a bit broader vision than merely just being the "simplest most readable implementation of the hash function". It is really intended to be the most *useful* implementation of MD6. That means that not only does it contain extensive internal comments, but it also contains explicit support for those who wish to experiment with variations of MD6. There are portions of the code that illustrate how MD6 variants can be easily defined, say in terms of 8, 16, or 32-bit words instead of the default 64-bits words. (Someone might want an 8-bit variant for a particular smart-card application, say, although the standard 64-bit version can easily be simulated on an 8-bit machine.) Or, someone may find some of the variants interesting for security analysis, as they embody the same principles as the proposed MD6. These variations correspond to the section in our documentation on flexibility and variations of MD6. These portions of the reference code don't generate any object code unless you set some of the compile-time switches to nonstandard values. The variants are not part of the MD6 proposed standard. But they do make the MD6 source code somewhat longer than a minimal stripped-down version would be. Just FYI... Cheers, Ron Rivest On 12/13/2008 4:09 PM, Sean O'Neil wrote: > > After some struggle fighting off numerous warnings and compilation > errors in some of the submissions, a simple size comparison of the > submitted reference source code and Release binary code compiled with > MSVC 2005 with default settings can be found at: > > http://www.sha3.org/source_size.html > http://www.sha3.org/binary_size.html > > A reference source code is expected to be the simplest most readable > implementation of the hash function. These results demonstrate the > potential minimum complexity and code/memory cost the implementers will > have to deal with. > > Best regards, > Sean O'Neil > http://www.enrupt.com/ - Raising the bar. > > > > -- Ronald L. Rivest Room 32-G692, Stata Center, MIT, Cambridge MA 02139 Tel 617-253-5880, Email From hash-forum@nist.gov Sat Dec 13 20:23:48 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBE4Nhs7015811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 13 Dec 2008 20:23:44 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBE4MrEj031095; Sat, 13 Dec 2008 23:22:55 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBE4LGSc018957; Sat, 13 Dec 2008 23:21:16 -0500 Date: Sat, 13 Dec 2008 23:21:16 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Sean O'Neil" To: Multiple recipients of list Subject: Re: Submissions, compiled X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: <494440B6.1050009@mit.edu> In-Reply-To: <494440B6.1050009@mit.edu> Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 13 Dec 2008 20:23:44 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 337 On 14 Dec 2008, at 00:10, Ronald L. Rivest wrote: > It is really intended to be the most *useful* implementation of MD6. Dear Ronald, Yes, you are right. I should have been more clear. This is the case for several functions. MD6, Skein and other functions that include additional functionality in their sources of course appear larger, but the compiled code is smaller (as opposed to Edon-R for example, with its 3 times smaller source but a 12 times larger binary than MD6). Of course all those additional functions of MD6 are optimized out of the binary. The size of the source does not reflect the quality of the function, but merely the amount of C code people will have to deal with while studying it or trying to implement it, even if they only need a small portion of it. In comparison, EnRUPT reference source also supports randomization, keying and all the different sizes, parallelizations and security/performance trade-offs (setting _ER_s_ for example to state->H or _ER_P_ to 4 is trivial), and although the [small] additional API is not included, EnRUPT2s function can also be used as it is as an authenticated/unauthenticated stream cipher... but all this additional functionality has no effect on the size of the source. [I'm not promoting it here, it's just the only comparative example I can use since it is the only function I know well.] The size of the binary, on contrary, reflects the actual size of the implementation or roughly just how much the applications will "suffer" and how small the reference source _could_ be... MD6 is proudly in the top half there. This comparison of course cannot even hint on what the "smallest source" or "minimal code" implementations would be. Since I had to compile them all anyway to perform automated analysis of all the algorithms, I just wanted to save everyone some time having to compile all the hashes themselves just to have a *rough* comparison between their sizes as a starting point to distinguish between the unfortunate functions taking tens of kilobytes or even MEGABYTES just to hash a block and the small simple 1-2K algorithms. We can all agree that everyone tried to present their own functions in the best possible light. With best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. From hash-forum@nist.gov Sun Dec 14 08:43:14 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBEGh6VQ022266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 14 Dec 2008 08:43:09 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBEGgIsU002413; Sun, 14 Dec 2008 11:42:23 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBEGg3bT001795; Sun, 14 Dec 2008 11:42:03 -0500 Date: Sun, 14 Dec 2008 11:42:03 -0500 Message-Id: <6c997f340db2d739fdefe5e1e94721a7@www3.mail.volny.cz> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: v.klima@volny.cz To: Multiple recipients of list Subject: =?iso-8859-2?Q?OFFICIAL_COMMENT:DynamicSHA2?= X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Mailer: Volny.cz Webmail2 2.115 X-Cc: hash-forum@nist.gov X-To: hash-function@nist.gov MIME-Version: 1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sun, 14 Dec 2008 08:43:10 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 338 Dynamic SHA2 is vulnerable to generic attacks. According to security requirements (part 4.A iii) of the hash functions NIST expects the SHA-3 algorithm should be resistent to length-extension attacks. Length-extension attack is not correctly understood and described in paragraph 6.1 of submitted Dynamic SHA2 documentations. As a consequence, Dynamic SHA2 (with 256-bit and 512-bit outputs) function (h) is trivially vulnerable to length-extension attacks. Given h(m) and len(m) but not m, the attacker easily creates m' (with correct padding) and calculates h (m || m') simply from h(m) and m'. Moreover, in the function's design there are no precautions against other generic attacks (multi-collisions etc.). Best regards, Vlastimil Klima From hash-forum@nist.gov Sun Dec 14 08:43:15 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBEGh631022267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 14 Dec 2008 08:43:09 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBEGg5ak004120; Sun, 14 Dec 2008 11:42:08 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBEGecIX031704; Sun, 14 Dec 2008 11:40:38 -0500 Date: Sun, 14 Dec 2008 11:40:38 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: v.klima@volny.cz To: Multiple recipients of list Subject: =?iso-8859-2?Q?OFFICIAL_COMMENT:DynamicSHA?= X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Mailer: Volny.cz Webmail2 2.115 X-Cc: hash-forum@nist.gov X-To: hash-function@nist.gov MIME-Version: 1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sun, 14 Dec 2008 08:43:10 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 339 Dynamic SHA is vulnerable to generic attacks. According to security requirements (part 4.A iii) of the hash functions NIST expects the SHA-3 algorithm should be resistent to length-extension attacks. Length-extension attack is not correctly understood and described in paragraph 6.1 of submitted Dynamic SHA documentations. As a consequence, Dynamic SHA (with 256-bit and 512-bit outputs) function (h) is trivially vulnerable to length-extension attacks. Given h(m) and len(m) but not m, the attacker easily creates m' (with correct padding) and calculates h (m || m') simply from h(m) and m'. Moreover, in the function's design there are no precautions against other generic attacks (multi-collisions etc.). Best regards, Vlastimil Klima From hash-forum@nist.gov Sun Dec 14 09:31:09 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBEHV3fC026239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 14 Dec 2008 09:31:04 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBEHMkqd016383; Sun, 14 Dec 2008 12:22:49 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBEHMI9q015481; Sun, 14 Dec 2008 12:22:18 -0500 Date: Sun, 14 Dec 2008 12:22:18 -0500 Message-Id: <957181.63261.qm@web36401.mail.mud.yahoo.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Peter To: Multiple recipients of list Subject: Re: Submissions, compiled X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/alternative; boundary="0-450221849-1229275239=:63261" MIME-Version: 1.0 X-To: hash-forum@nist.gov X-Mailer: YahooMailWebService/0.7.260.1 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sun, 14 Dec 2008 09:31:04 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-4.2 required=5.0 tests=AWL,BAYES_00, FORGED_YAHOO_RCVD,HTML_MESSAGE,RCVD_IN_DNSWL_MED,WEIRD_PORT shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 340 --0-450221849-1229275239=:63261 Content-Type: text/plain; charset=us-ascii Very interesting list. I must agree that code size isn't a very informative measure of complexity. For example, the most recent Ponic source (Disclaimer: It is my algorithm.) is 17013 bytes long. The initial size of the source code would indicate a simple algorithm (Certainly in the upper half of accepted algorithms.), but once compiled (gcc 4.2.4 with -O3) the executable was 12614 bytes (In the lower half of accepted algorithms.). The reason for this rather low ratio is sparse commenting, and a bear bones feature set. While Ponic may be somewhat of an exception, it should be noted that source code size to compiled size ratio is a more useful measure of programmer commenting/extra features than of algorithm complexity. To that end I have made such a table which is availible at: http://toothbrush.dyndns.org:50007/sourcesizeovercompiledsize.txt My hosting is terrible (and shuts off from 23.45 to 4.00) so if anyone else could host it somewhere else, I would be most appreciative. (P.S. If -O1 is used the compiled object is 11206 bytes.) --- On Sat, 12/13/08, Sean O'Neil wrote: From: Sean O'Neil Subject: Submissions, compiled To: "Multiple recipients of list" Date: Saturday, December 13, 2008, 4:09 PM After some struggle fighting off numerous warnings and compilation errors in some of the submissions, a simple size comparison of the submitted reference source code and Release binary code compiled with MSVC 2005 with default settings can be found at: http://www.sha3.org/source_size.html http://www.sha3.org/binary_size.html A reference source code is expected to be the simplest most readable implementation of the hash function. These results demonstrate the potential minimum complexity and code/memory cost the implementers will have to deal with. Best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. --0-450221849-1229275239=:63261 Content-Type: text/html; charset=us-ascii
Very interesting list. I must agree that code size isn't a very informative measure of complexity. For example, the most recent Ponic source (Disclaimer: It is my algorithm.) is 17013 bytes long. The initial size of the source code would indicate a simple algorithm (Certainly in the upper half of accepted algorithms.), but once compiled (gcc 4.2.4 with -O3) the executable was 12614 bytes (In the lower half of accepted algorithms.). The reason for this rather low ratio is sparse commenting, and a bear bones feature set. While Ponic may be somewhat of an exception, it should be noted that source code size to compiled size ratio is a more useful measure of programmer commenting/extra features than of algorithm complexity. To that end I have made such a table which is availible at: http://toothbrush.dyndns.org:50007/sourcesizeovercompiledsize.txt

My hosting is terrible (and shuts off from 23.45 to 4.00) so if anyone else could host it somewhere else, I would be most appreciative.

(P.S. If -O1 is used the compiled object is 11206 bytes.)
--- On Sat, 12/13/08, Sean O'Neil <sean@cryptolib.com> wrote:
From: Sean O'Neil <sean@cryptolib.com>
Subject: Submissions, compiled
To: "Multiple recipients of list" <hash-forum@nist.gov>
Date: Saturday, December 13, 2008, 4:09 PM

After some struggle fighting off numerous warnings and compilation errors in
some of the submissions, a simple size comparison of the submitted reference
source code and Release binary code compiled with MSVC 2005 with default
settings can be found at:

http://www.sha3.org/source_size.html
http://www.sha3.org/binary_size.html

A reference source code is expected to be the simplest most readable
implementation of the hash function. These results demonstrate the potential
minimum complexity and code/memory cost the implementers will have to deal with.

Best regards,
Sean

 O'Neil
http://www.enrupt.com/ - Raising the bar.



--0-450221849-1229275239=:63261-- From hash-forum@nist.gov Sun Dec 14 11:25:41 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBEJPawr002524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 14 Dec 2008 11:25:37 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBEJOTDU020907; Sun, 14 Dec 2008 14:24:32 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBEJNb53024964; Sun, 14 Dec 2008 14:23:37 -0500 Date: Sun, 14 Dec 2008 14:23:37 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Sean O'Neil" To: Multiple recipients of list Subject: Re: Submissions, compiled X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: <957181.63261.qm@web36401.mail.mud.yahoo.com> In-Reply-To: <957181.63261.qm@web36401.mail.mud.yahoo.com> Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sun, 14 Dec 2008 11:25:37 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 341 On 14 Dec 2008, at 18:22, Peter wrote: > For example, the most recent Ponic source (Disclaimer: It is my > algorithm.) is 17013 bytes long. I did not include Ponic, Maraca or NKS2D because they are not on http://csrc.nist.gov/groups/ST/hash/sha-3/Round1/ submissions_rnd1.html, but if anyone wants, I can add them and any other hash functions that comply with the SHA-3 API for comparison. With best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. From hash-forum@nist.gov Sun Dec 14 12:19:42 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBEKJbJH006882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 14 Dec 2008 12:19:38 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBEKInNQ026374; Sun, 14 Dec 2008 15:18:52 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBEKI7Ha001128; Sun, 14 Dec 2008 15:18:07 -0500 Date: Sun, 14 Dec 2008 15:18:07 -0500 Message-Id: <4945676C.3050307@nist.gov> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Bill Burr To: Multiple recipients of list Subject: Re: Narrow-pipe designs X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: <79B77C4C1E604E45967DBEA02EF6ED94@BobsDell> References: <77E8A818-5279-4A62-B253-0FECF60F4596@cryptolib.com> <79B77C4C1E604E45967DBEA02EF6ED94@BobsDell> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sun, 14 Dec 2008 12:19:38 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 342 Bob, We're trying to listen to what everybody says, before forming NIST's opinion about the relative importance of micro-controllers with limited memory, versus 1001 other trade-offs. It's just too soon for us to do that. In the end, we're going to want something that is a good substitute for the SHA-2s in all of their major applications, but is significantly better than SHA-2 in some significant respects. Unless the SHA-2s be "significantly" broken it's going to be very hard to force products to change to SHA-3, or even implement SHA-3, if SHA-3 has few significant practical advantages. To steal a phrase from Bruce Schneier's talk at the final AES conference, we're probably going to pick a SHA-3 that doesn't "suck at anything," or at least anything apparently very significant. And to pick a SHA-3 that is better than SHA-2 at several things. I think we did about that when we selected Rijndael to be the AES, although TDES was easier to improve on than the SHA2's are. The SHA-2s, I think, set a reasonably high bar. It's worth remembering, in this respect, however, that TDES is not without its virtues: it's pretty efficient in hardware. I'll point one other related trade-off I think I see here. The SHA-2s give us two different pipe widths. Is it better to do this, or have one compromise pipe width for all 4 output sizes, that perhaps is a little narrower than ideal for the 512-bit output? At this point it's not clear to me (as distinct from the rest of the folks in my group, who I haven't discussed this with very much at this point) that we often ask low-end micro controllers to generate collision free hashes. I suppose that there will always be applications for low end processors with very little RAM, but will those often require collision free hashes? And we seem to get more and more powerful processors with more and more memory into smaller and smaller packages. It also seems to me that there are more efficient ways to address MACs in micro controllers, than HMAC. So, if HMAC be the main application for hash functions in micro controllers, then maybe low end micro controllers would not be a major concern for SHA-3. But I remain open to arguments to the contrary. And I'm pretty sure we'll wind up with several second round candidate algorithms with narrow-pipe designs, as well as several wider pipe designs. Regards, Bill Burr Bob Hattersley wrote: > A somewhat intemperate post perhaps, but there's an interesting question in > there. Waterfall would be a 6x design in this classification and therefore > a "monster". (Since I have no desire to make anyone ill, I recommend that > sensitive souls should avoid any further contact with it.) I worked under > the (possibly invalid) assumption that 512 bytes of RAM (and 2kB of program > storage) was a reasonable target. 1kB RAM seems to be widely used today, > and memory doesn't seem to be getting more expensive. Most microcontrollers > are not used in situations where cryptography has any relevance. > > But what is the general opinion? Perhaps more important - what is NIST's > view? > > Bob Hattersley (Waterfall) > > -----Original Message----- > From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Sean > O'Neil > Sent: 13 December 2008 06:27 > To: Multiple recipients of list > Subject: Narrow-pipe designs > > > A number of people are asking a good question: > > Can someone please publish a paper listing all the narrow-pipe hashes as > broken by design, so we could all focus on the good ones with 2x and > slightly larger states? > > <2x is vulnerable by design, >=2x up to 2.5x (or possibly up to 3x) is the > optimal choice, but all the >=4x monsters and some of the designs such as > Crunch or FSB with their reference code requiring MEGABYTES (!!!) of tables > to function are certainly gone too far. > With all due respect to their authors, I wouldn't bother looking at those as > a total waste of time. > > Personally, the hash functions with 4x and larger states make me wanna puke, > but technically, they would simply never fit in 128 or > 256 bytes of RAM of the [yes, very] popular 8-bit microcontrollers that may > want to use some of it for other purposes than merely storing the entire > hash state with no room left for a single variable. > > Best regards, > Sean O'Neil > http://www.enrupt.com/ - Raising the bar. > > > > -- William E. Burr Manager, Security Technology Group NIST 100 Bureau Dr., MS 8931 Gaithersburg, MD. 20899 Bldg. 222, Rm B362 Tel: 301-975-2914 Fax: 301-975-8670 From hash-forum@nist.gov Sun Dec 14 13:27:46 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBELReNH011648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 14 Dec 2008 13:27:41 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBELQjlX019901; Sun, 14 Dec 2008 16:26:47 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBELPvbF003224; Sun, 14 Dec 2008 16:25:57 -0500 Date: Sun, 14 Dec 2008 16:25:57 -0500 Message-Id: <4945774B.3010002@nist.gov> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Bill Burr To: Multiple recipients of list Subject: Re: regarding etiquette X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=windows-1252; format=flowed In-Reply-To: References: <494323F1.1030502@mit.edu> <052264A5-8664-4DDF-A196-DAEBF3A8E563@cryptolib.com> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sun, 14 Dec 2008 13:27:42 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 343 I have occasion to quote this particular text quite often. I, or we at NIST, all too often wind up in the no-man's land between cryptographers (or academic computer scientists) and others (for example voting officials), and are left to say, "Don't take this too personally, they're just as mean to each other, and to us (NIST), as they are to you." Colonel Pickering treats Eliza like a duchess, and Henry Higgins treats a duchess like a flower girl. So they're both the same, they both treat everyone alike. But we find Colonel Pickering easier to live with. I'd prefer that people here were a little gentler with each other, in the hope, I suppose, that they would be a little gentler with us. But we do our best to grow very thick skins. It's my observation, however, as someone who came to cryptography very late in his life, that many academic cryptographers, while often sharp with each other and extraordinarily competitive, are often meticulous about giving proper credit, I suppose because it's so important to them. There is a lot of room for misunderstanding when academic computer scientists and cryptographers interact with others as they do with themselves. At its worst, both sides wind up impugning the motivations of each other. At least within this community let's try and remember that nearly all of us are from time to time mistaken in our beliefs, but most of us are well intended. So lets give each other the benefit of the doubt, try to maintain civility and try to refrain from bringing old feuds in here. I don't have any particular rules for the proper etiquette here. But try to remember that in an open competition like this, some of the participants are not well versed in the norms of the community; some are in well over their heads but don't know it. There is some low hanging fruit here, and there is relatively little credit to be earned by being the first to notice what will be obvious to the first experienced reviewer. And there are also a fair number of submissions by one or two capable people, who didn't have that much time, and have missed something that may be obvious to the right reader, or to the authors if they had had the time to think of it. To me there is much more credit to be gained by someone who adds a couple of rounds to the best attack on something that has been looked at a lot, than by breaking a weak submission. Regards, Bill Burr Sean O'Neil wrote: > > On 13 Dec 2008, at 17:47, Paul Hoffman wrote: > >> That may be true for you, but not for other researchers. > > It is easy to get that impression when your own work gets stolen. I > guess this paper would be more palatable for you than my whinging: > > http://www.ams.org/notices/200708/tx070800972p.pdf > > "Drama and conflict are inherent in cryptography, which, in fact, can > be defined as the science of transmitting and managing information in > the presence of an adversary. The “spy vs. spy” mentality of constant > competition and rivalry extends to the disciplinary culture of the > field. This can get to be excessive — and even childish at times — but > it also explains in part why it can be so much fun to do research in > cryptography." – Neil Koblitz > > Best regards, > Sean O'Neil > http://www.enrupt.com/ - Raising the bar. > > > -- William E. Burr Manager, Security Technology Group NIST 100 Bureau Dr., MS 8931 Gaithersburg, MD. 20899 Bldg. 222, Rm B362 Tel: 301-975-2914 Fax: 301-975-8670 From hash-forum@nist.gov Sun Dec 14 13:32:10 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBELW5wk012012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 14 Dec 2008 13:32:06 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBELQs3a019928; Sun, 14 Dec 2008 16:26:59 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBELQdNQ004300; Sun, 14 Dec 2008 16:26:39 -0500 Date: Sun, 14 Dec 2008 16:26:39 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "John Wilkinson" To: Multiple recipients of list Subject: Re: Narrow-pipe designs X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <77E8A818-5279-4A62-B253-0FECF60F4596@cryptolib.com> <79B77C4C1E604E45967DBEA02EF6ED94@BobsDell> <4945676C.3050307@nist.gov> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 In-Reply-To: <4945676C.3050307@nist.gov> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sun, 14 Dec 2008 13:32:06 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 344 I'd like to echo Bill's concerns that we (the community) don't seem to have a very clear view of what low-end (<32-bit) embedded applications really require collision resistant hashing. I asked earlier for some example of an embedded application requiring collision resistance rather than preimage resistance or a MAC, and I got no answer. Anyone? On Sun, Dec 14, 2008 at 3:18 PM, Bill Burr wrote: > > Bob, > > We're trying to listen to what everybody says, before forming NIST's opinion > about the relative importance of micro-controllers with limited memory, > versus 1001 other trade-offs. It's just too soon for us to do that. > > In the end, we're going to want something that is a good substitute for the > SHA-2s in all of their major applications, but is significantly better than > SHA-2 in some significant respects. Unless the SHA-2s be "significantly" > broken it's going to be very hard to force products to change to SHA-3, or > even implement SHA-3, if SHA-3 has few significant practical advantages. > > To steal a phrase from Bruce Schneier's talk at the final AES conference, > we're probably going to pick a SHA-3 that doesn't "suck at anything," or at > least anything apparently very significant. And to pick a SHA-3 that is > better than SHA-2 at several things. I think we did about that when we > selected Rijndael to be the AES, although TDES was easier to improve on than > the SHA2's are. The SHA-2s, I think, set a reasonably high bar. It's worth > remembering, in this respect, however, that TDES is not without its virtues: > it's pretty efficient in hardware. > I'll point one other related trade-off I think I see here. The SHA-2s give > us two different pipe widths. Is it better to do this, or have one > compromise pipe width for all 4 output sizes, that perhaps is a little > narrower than ideal for the 512-bit output? > At this point it's not clear to me (as distinct from the rest of the folks > in my group, who I haven't discussed this with very much at this point) > that we often ask low-end micro controllers to generate collision free > hashes. I suppose that there will always be applications for low end > processors with very little RAM, but will those often require collision free > hashes? And we seem to get more and more powerful processors with more and > more memory into smaller and smaller packages. It also seems to me that > there are more efficient ways to address MACs in micro controllers, than > HMAC. So, if HMAC be the main application for hash functions in micro > controllers, then maybe low end micro controllers would not be a major > concern for SHA-3. But I remain open to arguments to the contrary. And I'm > pretty sure we'll wind up with several second round candidate algorithms > with narrow-pipe designs, as well as several wider pipe designs. > > Regards, > > Bill Burr > > > > > > Bob Hattersley wrote: >> >> A somewhat intemperate post perhaps, but there's an interesting question >> in >> there. Waterfall would be a 6x design in this classification and >> therefore >> a "monster". (Since I have no desire to make anyone ill, I recommend that >> sensitive souls should avoid any further contact with it.) I worked under >> the (possibly invalid) assumption that 512 bytes of RAM (and 2kB of >> program >> storage) was a reasonable target. 1kB RAM seems to be widely used today, >> and memory doesn't seem to be getting more expensive. Most >> microcontrollers >> are not used in situations where cryptography has any relevance. >> >> But what is the general opinion? Perhaps more important - what is NIST's >> view? >> >> Bob Hattersley (Waterfall) >> >> -----Original Message----- >> From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Sean >> O'Neil >> Sent: 13 December 2008 06:27 >> To: Multiple recipients of list >> Subject: Narrow-pipe designs >> >> >> A number of people are asking a good question: >> >> Can someone please publish a paper listing all the narrow-pipe hashes as >> broken by design, so we could all focus on the good ones with 2x and >> slightly larger states? >> >> <2x is vulnerable by design, >=2x up to 2.5x (or possibly up to 3x) is the >> optimal choice, but all the >=4x monsters and some of the designs such as >> Crunch or FSB with their reference code requiring MEGABYTES (!!!) of >> tables >> to function are certainly gone too far. With all due respect to their >> authors, I wouldn't bother looking at those as >> a total waste of time. >> >> Personally, the hash functions with 4x and larger states make me wanna >> puke, >> but technically, they would simply never fit in 128 or >> 256 bytes of RAM of the [yes, very] popular 8-bit microcontrollers that >> may >> want to use some of it for other purposes than merely storing the entire >> hash state with no room left for a single variable. >> >> Best regards, >> Sean O'Neil >> http://www.enrupt.com/ - Raising the bar. >> >> >> >> > > -- > William E. Burr > Manager, Security Technology Group > NIST > 100 Bureau Dr., MS 8931 > Gaithersburg, MD. 20899 > Bldg. 222, Rm B362 > Tel: 301-975-2914 > Fax: 301-975-8670 > > > > From hash-forum@nist.gov Sun Dec 14 13:55:42 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBELtYks013658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 14 Dec 2008 13:55:35 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBELsVrb003559; Sun, 14 Dec 2008 16:54:36 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBELs42W025735; Sun, 14 Dec 2008 16:54:04 -0500 Date: Sun, 14 Dec 2008 16:54:04 -0500 Message-Id: <49457E1F.9070401@nist.gov> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Bill Burr To: Multiple recipients of list Subject: Re: SHA-3 First Round Submissions. X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/alternative; boundary="------------050508000509050006060200" In-Reply-To: References: <49400E39.4090702@nist.gov> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sun, 14 Dec 2008 13:55:35 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk $Forwarded X-UID: 345 This is a multi-part message in MIME format. --------------050508000509050006060200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Larry Bassham, who has been compiling and running the code provided with the SHA-3 submissions, will contact the submitters where he has a problem with the code, and attempt to resolve any problems. We don't plan at this time to do the same thing with the specifications. There were a number of very well written, highly professional submissions, and we expect that many of the second round candidates will come from such submissions. But we're not trying to pick the best written specification here; we're trying to pick the best hash algorithm. We're also mindful that many submitters are not writing in their native language, and we're running an algorithm competition, not selecting papers for journal publication. We're not going to try to bring all 51 first round candidates to some consistent editorial level. The real proof of the pudding on the specifications is the ability to independently implement the algorithm and get the right outputs. We're not going to have time to try that for all the submissions before we select the second round candidates. Where we find documentation problems that present real problems to us, we may consult with the submitters to get a revised specification that clarifies some point we're having problems with. Still, in a competition of this sort, a clear, well written specification is going to be an advantage. When two submissions seem otherwise to be roughly comparable, and we have to choose between them, but one is very clearly written, and the other is a bit confusing, the writing could tip the scale. At the next stage, we're going to pick about 15 submissions that we like best, that interest us. We intend that the 15 second round candidates should all have good specifications, so if we ask for specification clarifications or edits, that may be a sign of interest. We're not likely to ask for clarifications and editing on a specification for an algorithm that seems generally uninteresting to us. We intend to consider all the data we have available to us to make the second round selection. That includes the eBASH performance data. If implementers (or others) want to add some improved code they may do so, but the sooner, the better (we can't promise to compile and run everything we get before we make the selections for the next round if it comes in too late). We do not intend to make our second round selections primarily on the basis of performance data, so minor code tuning may not have a big payback at this point. But, if a major feature of a proposal is how efficient an algorithm is with some vector instruction set, or on a lightweight processor, or something like that, some additional measured performance data might be useful. If an algorithm appears to have inferior performance on some significant platform, data that shows it actually pretty good if well implemented could also help. Additional implementations may be provided to Larry Bassham < lbassham@nist.gov>. These, and the updates he requests from submitters, will be put on the "submissions" page. Regards, Bill Burr Bob Hattersley wrote: > I have two questions: > > Will NIST let the accepted submitters know (perhaps privately) what > specific problems they found with the quality of documentation or > code, so that these can be improved for everyone's benefit? > > I have succeeded in cutting the number of cycles per byte by 40% on > the 32-bit platform by coding the main loop in inline assembler. Is > NIST interested in implementations other than pure C, how will they be > taken into account, and what is the process for submitting such > additional implementations? > > Thanks, > > Bob Hattersley (Waterfall) > Opta Consulting Ltd. > > ------------------------------------------------------------------------ > *From:* hash-forum@nist.gov [mailto:hash-forum@nist.gov] *On Behalf Of > *Bill Burr > *Sent:* 10 December 2008 18:49 > *To:* Multiple recipients of list > *Subject:* SHA-3 First Round Submissions. > > NIST received 64 SHA-3 candidate hash function submissions. Overall, > NIST is very pleased with the obvious high quality of many of the > submissions, as well as the general range of designs. NIST has > accepted 51 first round candidates as meeting our minimum acceptance > criteria. They are now posted on the NIST website: > . > To make an "official" comment on one of the algorithms please use the > "submit comments" link on this page for the appropriate algorithm. > Such comments will also be forwarded to hash-forum@nist.gov. Continue > to post general comments about the competition at hash-forum@nist.gov. > > > We will review these first round candidates at the first SHA-3 > Candidate Conference on February 25-28, 2009 at Leuven. During the > summer of 2009 we plan to select about 15 second round candidates for > more focused review at the Second SHA-3 Candidate Conference, > tentatively scheduled for August, 2010. Following that second > conference we expect to select about 5 third round candidates (or > "finalists"). At our third conference we will review the finalists > and select a winner shortly thereafter. At each stage we will do our > best to explain our choices. > > The Federal Register announcement specified minimum acceptability > requirements for "complete and proper submissions." These > requirements included provisions for reference and optimized C code > implementations, known answer tests, a written specification and > required intellectual property statements. > > We asked for reference code and optimized 32 and 64-bit code. Some > submissions did not include optimized implementations, so we will use > the performance results from the reference implementations in our > future deliberations. Some submissions were rejected because C code > was not provided. NIST specified a specific API for the C code, and a > few submissions did not use that API: these submissions were also > rejected. In some cases, we made a number of minor corrections to the > submitted code (largely in the include statements) in order to allow > it to compile and run, but made no major repairs. > > NIST attempted to verify that the submitted C programs gave outputs > that corresponded to the submitted known answer test results when > compiled and run on our reference platform. In several cases there > were discrepancies between the known answer test results NIST got on > our reference platform, and the known answer test results provided by > the submitters. NIST will notify those submitters, and these > discrepancies must be resolved in a timely manner if the submission is > to be eligible to become a second round candidate. > > We also asked for documentation, including a complete specification of > the algorithms, known answer test results, a performance analysis on > different platforms and a security analysis. The quality of the > submitted documentation varied greatly. For the security and > performance analyses, we were very liberal in what we accepted. We > had difficulty determining that the algorithm specifications were > complete in some cases. In some of these cases necessary information, > such as initial values or padding rules, were omitted from otherwise > well-written specifications, but we were able to easily determine this > information from the code; these specifications were considered > acceptable, since independent implementers can find what they need and > the specification can be easily fixed. Some written specifications > were incomprehensible without a careful examination of the C code; the > more extreme cases were rejected. Inevitably, there were cases > between the two extremes. There were several submissions which we > accepted that required us to rely more on the programming code for > clear understanding than we liked. > > We expect that the algorithms selected as the SHA-3 finalists will > have specifications that will allow independent implementers to > program or design hardware that will produce results that match those > provided by the submitters for the known answer tests. In the AES > competition, Brian Gladman and others provided independent > implementations of all the finalists. Marginal, hard to follow > specifications may affect whether a submission is selected for the > second round. > > We reviewed the intellectual property statements for all of the > submissions. While there remain minor issues in some of the > statements, we believe that all the accepted submissions include IP > statements that allow us to continue the evaluation process for those > submissions for now. However, any IP statement issues must be fully > resolved before a candidate can progress to be a second round candidate. > > Many of the accepted submissions have been posted on the SHA-3 Zoo > site for some time, and a number have been analyzed and are claimed to > be "broken." In some cases, the submitters have conceded the break. > In other cases, the submitters concede the break, but claim that it > can be fixed with trivial changes (e.g. by adding a few rounds). In > still other cases, it appears that the breaks are fundamental and > cannot be fixed without extensive modifications. NIST does not want > to spend time in the upcoming SHA-3 conference on accepted, but broken > algorithms, unless the break is disputed, or the fix is truly > trivial. On the other hand, there has been considerable discussion > about what is considered to be a break, and we expect to continue that > discussion in Leuven. We also expect to discuss allowing submitters > to use their "tunable parameter" to make changes to their algorithm > before the second round candidates are chosen. > > We will continue to consider submissions where there is a dispute > about whether the submission is in fact broken until we can make a > determination about the facts of the case. > > Regards, > > Bill Burr > -- > William E. Burr > Manager, Security Technology Group > NIST > 100 Bureau Dr., MS 8931 > Gaithersburg, MD. 20899 > Bldg. 222, Rm B362 > Tel: 301-975-2914 > Fax: 301-975-8670 > -- William E. Burr Manager, Security Technology Group NIST 100 Bureau Dr., MS 8931 Gaithersburg, MD. 20899 Bldg. 222, Rm B362 Tel: 301-975-2914 Fax: 301-975-8670 --------------050508000509050006060200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Larry Bassham, who has been compiling and running the code provided with the SHA-3 submissions, will contact the submitters where he has a problem with the code, and attempt to resolve any problems.

We don’t plan at this time to do the same thing with the specifications.  There were a number of very well written, highly professional submissions, and we expect that many of the second round candidates will come from such submissions.  But we’re not trying to pick the best written specification here; we’re trying to pick the best hash algorithm.  We’re also mindful that many submitters are not writing in their native language, and we’re running an algorithm competition, not selecting papers for journal publication. 

We’re not going to try to bring all 51 first round candidates to some consistent editorial level.  The real proof of the pudding on the specifications is the ability to independently implement the algorithm and get the right outputs.  We’re not going to have time to try that for all the submissions before we select the second round candidates.  Where we find documentation problems that present real problems to us, we may consult with the submitters to get a revised specification that clarifies some point we’re having problems with.

Still, in a competition of this sort, a clear, well written specification is going to be an advantage. When two submissions seem otherwise to be roughly comparable, and we have to choose between them, but one is very clearly written, and the other is a bit confusing, the writing could tip the scale. 

At the next stage, we’re going to pick about 15 submissions that we like best, that interest us.  We intend that the 15 second round candidates should all have good specifications, so if we ask for specification clarifications or edits, that may be a sign of interest.  We’re not likely to ask for clarifications and editing on a specification for an algorithm that seems generally uninteresting to us.

We intend to consider all the data we have available to us to make the second round selection.  That includes the eBASH performance data.  If implementers (or others) want to add some improved code they may do so, but the sooner, the better (we can’t promise to compile and run everything we get before we make the selections for the next round if it comes in too late).  We do not intend to make our second round selections primarily on the basis of performance data, so minor code tuning may not have a big payback at this point.  But, if a major feature of a proposal is how efficient an algorithm is with some vector instruction set, or on a lightweight processor, or something like that, some additional measured performance data might be useful.    If an algorithm appears to have inferior performance on some significant platform, data that shows it actually pretty good if well implemented could also help.

Additional implementations may be provided to Larry Bassham < lbassham@nist.gov>.  These, and the updates he requests from submitters, will be put on the “submissions” page.

Regards,

Bill Burr

Bob Hattersley wrote:
I have two questions:
 
Will NIST let the accepted submitters know (perhaps privately) what specific problems they found with the quality of documentation or code, so that these can be improved for everyone's benefit?
 
I have succeeded in cutting the number of cycles per byte by 40% on the 32-bit platform by coding the main loop in inline assembler.  Is NIST interested in implementations other than pure C, how will they be taken into account, and what is the process for submitting such additional implementations?
 
Thanks,
 
Bob Hattersley (Waterfall)
Opta Consulting Ltd.
 
From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Bill Burr
Sent: 10 December 2008 18:49
To: Multiple recipients of list
Subject: SHA-3 First Round Submissions.

NIST received 64 SHA-3 candidate hash function submissions.  Overall, NIST is very pleased with the obvious high quality of many of the submissions, as well as the general range of designs.  NIST has accepted 51 first round candidates as meeting our minimum acceptance criteria.  They are now posted on the NIST website: <http://csrc.nist.gov/groups/ST/hash/sha-3/Round1/submissions_rnd1.html>. To make an "official" comment on one of the algorithms please use the "submit comments" link on this page for the appropriate algorithm.  Such comments will also be forwarded to hash-forum@nist.gov.  Continue to post general comments about the competition at hash-forum@nist.gov.


We will review these first round candidates at the first SHA-3 Candidate Conference on February 25-28, 2009 at Leuven.  During the summer of 2009 we plan to select about 15 second round candidates for more focused review at the Second SHA-3 Candidate Conference, tentatively scheduled for August, 2010.  Following that second conference we expect to select about 5 third round candidates (or “finalists”).  At our third conference we will review the finalists and select a winner shortly thereafter.  At each stage we will do our best to explain our choices.

The Federal Register announcement specified minimum acceptability requirements for “complete and proper submissions.”  These requirements included provisions for reference and optimized C code implementations, known answer tests, a written specification and required intellectual property statements.   

We asked for reference code and optimized 32 and 64-bit code. Some submissions did not include optimized implementations, so we will use the performance results from the reference implementations in our future deliberations.  Some submissions were rejected because C code was not provided.  NIST specified a specific API for the C code, and a few submissions did not use that API: these submissions were also rejected.  In some cases, we made a number of minor corrections to the submitted code (largely in the include statements) in order to allow it to compile and run, but made no major repairs.   

NIST attempted to verify that the submitted C programs gave outputs that corresponded to the submitted known answer test results when compiled and run on our reference platform.  In several cases there were discrepancies between the known answer test results NIST got on our reference platform, and the known answer test results provided by the submitters.  NIST will notify those submitters, and these discrepancies must be resolved in a timely manner if the submission is to be eligible to become a second round candidate.

We also asked for documentation, including a complete specification of the algorithms, known answer test results, a performance analysis on different platforms and a security analysis.  The quality of the submitted documentation varied greatly.  For the security and performance analyses, we were very liberal in what we accepted.  We had difficulty determining that the algorithm specifications were complete in some cases.  In some of these cases necessary information, such as initial values or padding rules, were omitted from otherwise well-written specifications, but we were able to easily determine this information from the code; these specifications were considered acceptable, since independent implementers can find what they need and the specification can be easily fixed.  Some written specifications were incomprehensible without a careful examination of the C code; the more extreme cases were rejected.  Inevitably, there were cases between the two extremes. There were several submissions which we accepted that  required us to rely more on the programming code for clear understanding than we liked.

We expect that the algorithms selected as the SHA-3 finalists will have specifications that will allow independent implementers to program or design hardware that will produce results that match those provided by the submitters for the known answer tests.  In the AES competition, Brian Gladman and others provided independent implementations of all the finalists.  Marginal, hard to follow specifications may affect whether a submission is selected for the second round. 

We reviewed the intellectual property statements for all of the submissions. While there remain minor issues in some of the statements, we believe that all the accepted submissions include IP statements that allow us to continue the evaluation process for those submissions for now.  However, any IP statement issues must be fully resolved before a candidate can progress to be a second round candidate.

Many of the accepted submissions have been posted on the SHA-3 Zoo site for some time, and a number have been analyzed and are claimed to be “broken.”  In some cases, the submitters have conceded the break. In other cases, the submitters concede the break, but claim that it can be fixed with trivial changes (e.g. by adding a few rounds). In still other cases, it appears that the breaks are fundamental and cannot be fixed without extensive modifications.  NIST does not want to spend time in the upcoming SHA-3 conference on accepted, but broken algorithms, unless the break is disputed, or the fix is truly trivial.  On the other hand, there has been considerable discussion about what is considered to be a break, and we expect to continue that discussion in Leuven.  We also expect to discuss allowing submitters to use their “tunable parameter” to make changes to their algorithm before the second round candidates are chosen. 

We will continue to consider submissions where there is a dispute about whether the submission is in fact broken until we can make a determination about the facts of the case.

Regards,

Bill Burr
 
-- 
William E. Burr
Manager, Security Technology Group
NIST
100 Bureau Dr., MS 8931
Gaithersburg, MD. 20899
Bldg. 222, Rm B362
Tel: 301-975-2914
Fax: 301-975-8670
  

-- 
William E. Burr
Manager, Security Technology Group
NIST
100 Bureau Dr., MS 8931
Gaithersburg, MD. 20899
Bldg. 222, Rm B362
Tel: 301-975-2914
Fax: 301-975-8670
--------------050508000509050006060200-- From hash-forum@nist.gov Sun Dec 14 14:08:56 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBEM8qCB014647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 14 Dec 2008 14:08:53 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBEM82Zu027374; Sun, 14 Dec 2008 17:08:04 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBEM7m3t020472; Sun, 14 Dec 2008 17:07:48 -0500 Date: Sun, 14 Dec 2008 17:07:48 -0500 Message-Id: <200812142301.57461.Michal.Trojnara@mobi-com.net> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Michal Trojnara To: Multiple recipients of list Subject: Re: StreamHash X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; boundary="nextPart2269187.1aiivXoJGJ"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 In-Reply-To: <20081211173535.dm9hcc11q8gw44ow@webmail.uib.no> References: <20081211173535.dm9hcc11q8gw44ow@webmail.uib.no> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sun, 14 Dec 2008 14:08:53 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 346 --nextPart2269187.1aiivXoJGJ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Tor E. Bj=C3=B8rstad wrote: > It seems we get into an internal state cycle that > repeats every 40 bytes. Do you agree? I do. I hereby declare the version of StreamHash submitted for the SHA-3=20 competition as broken. I hope NIST will eventually allow for some corrections. According to my=20 initial tests this issue can be trivially fixed. Best regards, Michal Trojnara --nextPart2269187.1aiivXoJGJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBJRYJV/NU+nXTHMtERAt5DAKClKzPgFlh+4K86OW9o7BUi/502GQCg0lSc XjlVCpvPit3aaxr84TAq4Jo= =UNA2 -----END PGP SIGNATURE----- --nextPart2269187.1aiivXoJGJ-- From hash-forum@nist.gov Sun Dec 14 17:45:25 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBF1jJgi030200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 14 Dec 2008 17:45:21 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBF1iJNo016990; Sun, 14 Dec 2008 20:44:21 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBF1ghN2015963; Sun, 14 Dec 2008 20:42:43 -0500 Date: Sun, 14 Dec 2008 20:42:43 -0500 Message-Id: <888E37A2001E364CBC4F28FA7660A2E65E26A65829@NA-EXMSG-C102.redmond.corp.microsoft.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Niels Ferguson To: Multiple recipients of list Subject: OFFICIAL COMMENT: Vortex - simple correlation on some of the output bits X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_888E37A2001E364CBC4F28FA7660A2E65E26A65829NAEXMSGC102re_" X-CC: "hash-forum@nist.gov" X-To: "hash-function@nist.gov" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sun, 14 Dec 2008 17:45:21 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 347 --_000_888E37A2001E364CBC4F28FA7660A2E65E26A65829NAEXMSGC102re_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think I found a simple correlation on some of the output bits of Vortex. The hash result is the output of the V function. I'll use the notation of F= igure 4 in the Vortex documentation, and use X[0] to refer to the least sig= nificant bit of word X. new_B0 and new_A0 are two of the output words of the function V. new_B0[0] is a function of three bits B1[0], B0[0], and A0[0]. new_A0[0] is a function of three bits B0[0], A1[0], and A0[0]. These two functions share inputs and are correlated. new_B0[0] =3D new_A0[0= ] with probability 5/8. This leads to a trivially detectable output bias, a= nd makes the hash function unsuitable for many applications, including key = derivation and Hash_DRBG from SP800-90. Let's rename the four input bits to A, B, C, and D, and the two output bits= to X and Y. We have: X =3D (A & D) ^ B Y =3D (B & C) ^ D If A=3D0 then X =3D B and Y =3D ^ D so both output bits a= re uncorrelated and unbiased. If C=3D0 the same applies. But if A=3DC=3D1 we have X =3D D ^ B Y =3D B ^ D and thus X =3D Y So 3/4 of the time the two output bits are unrelated, and 1/4 of the time t= hey are the same, which leads to X=3DY for 5/8 of all inputs. I haven't verified this experimentally, but the submitters of Vortex agreed= with this analysis. Cheers! Niels --_000_888E37A2001E364CBC4F28FA7660A2E65E26A65829NAEXMSGC102re_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I think I f= ound a simple correlation on some of the output bits of Vortex.

 

The hash result is the output of the V fu= nction. I'll use the notation of Figure 4 in the Vortex documentation,= and use X[0] to refer to the least significant bit of word X.

 

new_B0 and new_A0 are two of the output w= ords of the function V.

new_B0[0] is a function of three bit= s B1[0], B0[0], and A0[0].

new_A0[0] is a function of three bits B0[= 0], A1[0], and A0[0].

 

These two functions share inputs and are = correlated. new_B0[0] =3D new_A0[0] with probability 5/8. This leads to a t= rivially detectable output bias, and makes the hash function unsuitable for many applications, including key derivati= on and Hash_DRBG from SP800-90.

 

Let's rename the four input bits to A, B,= C, and D, and the two output bits to X and Y. We have:

 

X =3D (A & D) ^ B

Y =3D (B & C) ^ D

 

If A=3D0 then X =3D B and Y =3D <some = expression> ^ D so both output bits are uncorrelated and unbiased.

If C=3D0 the same applies.<= /p>

 

But if A=3DC=3D1 we have

X =3D D ^ B

Y =3D B ^ D

and thus

X =3D Y

 

So 3/4 of the time the two output bits ar= e unrelated, and 1/4 of the time they are the same, which leads to X=3DY fo= r 5/8 of all inputs.

 

I haven't verified this experimentally, b= ut the submitters of Vortex agreed with this analysis.

 

 

Cheers!

 

Niels

--_000_888E37A2001E364CBC4F28FA7660A2E65E26A65829NAEXMSGC102re_-- From hash-forum@nist.gov Sun Dec 14 19:06:26 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBF36KwZ004380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 14 Dec 2008 19:06:21 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBF35SpW022579; Sun, 14 Dec 2008 22:05:31 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBF34nsv014389; Sun, 14 Dec 2008 22:04:49 -0500 Date: Sun, 14 Dec 2008 22:04:49 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "=?iso-8859-1?Q?emmanuel.volte@aliceadsl.fr?=" To: Multiple recipients of list Subject: =?iso-8859-1?Q?Re:Submissions,_compiled?= X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit X-To: "=?iso-8859-1?Q?hash-forum?=" Content-Type: text/plain; charset=iso-8859-1 MIME-Version: 1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sun, 14 Dec 2008 19:06:22 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 348 Hi, you can find here : http://www.voltee.com/crunch/Small_code_implementation/ A version of crunch_256 with a size of about 10KB. The constants are calculated on the fly. Of course we can do the same for crunch_512 etc. Best regards, Emmanuel Volte ---------- Initial Header ----------- >From : hash-forum@nist.gov To : Multiple recipients of list Cc : Date : Sat, 13 Dec 2008 16:09:35 -0500 Subject : Submissions, compiled After some struggle fighting off numerous warnings and compilation errors in some of the submissions, a simple size comparison of the submitted reference source code and Release binary code compiled with MSVC 2005 with default settings can be found at: http://www.sha3.org/source_size.html http://www.sha3.org/binary_size.html A reference source code is expected to be the simplest most readable implementation of the hash function. These results demonstrate the potential minimum complexity and code/memory cost the implementers will have to deal with. Best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. ---------------------- ALICE N°1 de la RELATION CLIENT 2008*-------------------- Découvrez vite l'offre exclusive ALICE BOX! En cliquant ici http://abonnement.aliceadsl.fr Offre soumise à conditions.*Source : TNS SOFRES / BEARING POINT. Secteur Fournisseur d.Accès Internet From hash-forum@nist.gov Sun Dec 14 20:24:15 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBF4OAaJ009937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 14 Dec 2008 20:24:11 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBF4DUUI010144; Sun, 14 Dec 2008 23:13:33 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBF4CbhU015843; Sun, 14 Dec 2008 23:12:37 -0500 Date: Sun, 14 Dec 2008 23:12:37 -0500 Message-Id: <3C21DCCC-A47A-436D-B97A-D166DAC233DA@cryptolib.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Sean O'Neil" To: Multiple recipients of list Subject: Re: Submissions, compiled X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sun, 14 Dec 2008 20:24:11 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 349 On 15 Dec 2008, at 04:04, emmanuel.volte@aliceadsl.fr wrote: > http://www.voltee.com/crunch/Small_code_implementation/ > A version of crunch_256 with a size of about 10KB. > The constants are calculated on the fly. So, the speed of which implementation is advertised in the paper as ~170 to ~1000 CPB then? The reasonably small slower one? Or is that the speed one gets with a megabyte large table? With best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. From hash-forum@nist.gov Sun Dec 14 21:08:56 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBF58nWv013478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 14 Dec 2008 21:08:51 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBF57t7q024957; Mon, 15 Dec 2008 00:07:57 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBF571pl024812; Mon, 15 Dec 2008 00:07:01 -0500 Date: Mon, 15 Dec 2008 00:07:01 -0500 Message-Id: <4945E48D.2080407@mit.edu> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Ronald L. Rivest" To: Multiple recipients of list Subject: Thoughts on SHA-3 potential applications, esp. for small devices (LONG) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: <4945676C.3050307@nist.gov> References: <77E8A818-5279-4A62-B253-0FECF60F4596@cryptolib.com> <79B77C4C1E604E45967DBEA02EF6ED94@BobsDell> <4945676C.3050307@nist.gov> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sun, 14 Dec 2008 21:08:51 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 350 Hi Bill -- I appreciate your thoughtful essays... There are indeed a lot of dimensions and tradeoffs to consider for the SHA-3 competition. If we think about why one wants a hash standard, four reasons come to mind (in no particular order): (1) A standard promotes and facilitates _interoperability_ between products produced by different organizations. (2) A standard will have been thoroughly evaluated for cryptographic strength. (3) A standard will be accompanied by a multitude of well-engineered and tested implementations for various platforms. (4) A standard, by being a standard, facilitates decision-making by organizations that are too risk-averse and non-technical to make a decision in the absence of a standard. For a hash function, I suspect that the main use for interoperability between products of different organizations will probably continue to be as a component of digital signatures. I do wonder, as you do, what the real needs will be for cryptographic primitives on various platforms, as time goes forward. The future, as usual, is not always predictable. The needs of very small devices are perhaps the most interesting question to consider. Devices that are already sufficiently powerful to compute public-key digital signatures are presumably going to be big enough to easily accommodate any sort of reasonable hash function as well. I think that devices that are too small to perform a public-key digital signature will frequently nonetheless have a requirement to authenticate themselves---to perform a MAC. (As you said.) But the requirements for MAC's are different (and in many ways simpler) than those for hash functions. We care about forgery rather than collision resistance, MAC outputs can be shorter than hash function outputs, etc. I feel it would be a bit strange to let the hash function competition be driven by the expectation that, for small devices, there is a need to utilize the SHA-3 hash function to produce MAC's. If the world is going to be filled up with tiny devices that need to authenticate themselves, then there is a clear need for an appropriate MAC standard. The SHA-3 competition was not set up to produce such a standard; it merely noted that suitability for use in HMAC was a SHA-3 requirement. It would probably be a mistake for the world to conclude that NIST feels that all small devices should be using HMAC as an authentication technology, when there are likely to be much better alternatives for small devices. (Perhaps down the road NIST would enjoy running a "nano-MAC" standards competition!) I also suspect that in the world of very small devices, almost all system designs will be proprietary and closed. Think for example of mass transit card systems or building access cards. There is no need for small devices in these systems to work "outside the system". The need for interoperability through an open standard is not wanted (indeed, it may be very much undesired). Thus, for very small devices the need for a standard in order to support interoperability may be small or absent. Of course, there may be exceptions, and who knows what future systems will need. But I find it hard to think of applications for hashing for very small devices where: -- the device is too small for public-key operations -- the hash function is not being used for a MAC To see why, note that abstractly, a hash value is often used as a "proxy" for the value being hashed. Its shorter length may be better suited for computation (as for a digital signature) or for communication (e.g. for the hash of a message being transmitted by a different channel, or at a different time). But very small devices don't have more than one communication channel, and they don't have much storage, so applications that send a hash value from a small device, so that it can later send the real message, seem dubious (it requires storage). Applications that send the hash so that the real message can be sent via another channel may also be rare, since the device doesn't have more than one channel. It isn't very clear to me what utility a "hash value as a proxy for a message" philosophy has for very small devices. Finally, a hash value can be appended to a message for transmission, but if one merely wants redundancy it can be done in better ways. (Keyed redundancy is different, but that is what a MAC gives.) I suspect that the world will indeed be filled with lots of fascinating small electronic devices, but I think that if they do crypto, it will almost certainly be MAC's or digital signatures. It is unlikely to be unkeyed hash function application. Perhaps I've overlooked something important, but I'm far from persuaded that the SHA-3 standard will be very relevant for very small devices, until you get up to size where the device is capable of performing public-key digital signatures. Then it will become relevant. But at that point, we've got fairly substantial resources already devoted to doing crypto, and one should be considering the digital signature operation as a whole; the hash function implementation may be a small piece of that whole. And of course, Moore's Law hasn't quite died yet, and transistors continue to shrink. For small devices, at some point the cost of bonding and packaging them should greatly exceed the cost of producing the chip. (Perhaps we are there already...) Perhaps others on this list have thoughts on how SHA-3 might be useful on very small devices... These are good discussions to have, and I appreciate your bringing these topics up in the hash-forum list. I agree with many of the points you brought up. Cheers, Ron Rivest On 12/14/2008 3:18 PM, Bill Burr wrote: > > Bob, > > We're trying to listen to what everybody says, before forming NIST's > opinion about the relative importance of micro-controllers with limited > memory, versus 1001 other trade-offs. It's just too soon for us to do > that. > > In the end, we're going to want something that is a good substitute for > the SHA-2s in all of their major applications, but is significantly > better than SHA-2 in some significant respects. Unless the SHA-2s be > "significantly" broken it's going to be very hard to force products to > change to SHA-3, or even implement SHA-3, if SHA-3 has few significant > practical advantages. > > To steal a phrase from Bruce Schneier's talk at the final AES > conference, we're probably going to pick a SHA-3 that doesn't "suck at > anything," or at least anything apparently very significant. And to > pick a SHA-3 that is better than SHA-2 at several things. I think we > did about that when we selected Rijndael to be the AES, although TDES > was easier to improve on than the SHA2's are. The SHA-2s, I think, set a > reasonably high bar. It's worth remembering, in this respect, however, > that TDES is not without its virtues: it's pretty efficient in hardware. > I'll point one other related trade-off I think I see here. The SHA-2s > give us two different pipe widths. Is it better to do this, or have one > compromise pipe width for all 4 output sizes, that perhaps is a little > narrower than ideal for the 512-bit output? > At this point it's not clear to me (as distinct from the rest of the > folks in my group, who I haven't discussed this with very much at this > point) that we often ask low-end micro controllers to generate > collision free hashes. I suppose that there will always be applications > for low end processors with very little RAM, but will those often > require collision free hashes? And we seem to get more and more > powerful processors with more and more memory into smaller and smaller > packages. It also seems to me that there are more efficient ways to > address MACs in micro controllers, than HMAC. So, if HMAC be the main > application for hash functions in micro controllers, then maybe low end > micro controllers would not be a major concern for SHA-3. But I remain > open to arguments to the contrary. And I'm pretty sure we'll wind up > with several second round candidate algorithms with narrow-pipe designs, > as well as several wider pipe designs. > > Regards, > > Bill Burr > > > > > > Bob Hattersley wrote: >> A somewhat intemperate post perhaps, but there's an interesting >> question in >> there. Waterfall would be a 6x design in this classification and >> therefore >> a "monster". (Since I have no desire to make anyone ill, I recommend >> that >> sensitive souls should avoid any further contact with it.) I worked >> under >> the (possibly invalid) assumption that 512 bytes of RAM (and 2kB of >> program >> storage) was a reasonable target. 1kB RAM seems to be widely used today, >> and memory doesn't seem to be getting more expensive. Most >> microcontrollers >> are not used in situations where cryptography has any relevance. >> >> But what is the general opinion? Perhaps more important - what is NIST's >> view? >> >> Bob Hattersley (Waterfall) >> >> -----Original Message----- >> From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Sean >> O'Neil >> Sent: 13 December 2008 06:27 >> To: Multiple recipients of list >> Subject: Narrow-pipe designs >> >> >> A number of people are asking a good question: >> >> Can someone please publish a paper listing all the narrow-pipe hashes as >> broken by design, so we could all focus on the good ones with 2x and >> slightly larger states? >> >> <2x is vulnerable by design, >=2x up to 2.5x (or possibly up to 3x) is >> the >> optimal choice, but all the >=4x monsters and some of the designs such as >> Crunch or FSB with their reference code requiring MEGABYTES (!!!) of >> tables >> to function are certainly gone too far. With all due respect to their >> authors, I wouldn't bother looking at those as >> a total waste of time. >> >> Personally, the hash functions with 4x and larger states make me wanna >> puke, >> but technically, they would simply never fit in 128 or >> 256 bytes of RAM of the [yes, very] popular 8-bit microcontrollers >> that may >> want to use some of it for other purposes than merely storing the entire >> hash state with no room left for a single variable. >> >> Best regards, >> Sean O'Neil >> http://www.enrupt.com/ - Raising the bar. >> >> >> >> > -- Ronald L. Rivest Room 32-G692, Stata Center, MIT, Cambridge MA 02139 Tel 617-253-5880, Email From hash-forum@nist.gov Sun Dec 14 23:50:55 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBF7ooAB026979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 14 Dec 2008 23:50:51 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBF7nm1I012659; Mon, 15 Dec 2008 02:49:51 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBF7mrT3015798; Mon, 15 Dec 2008 02:48:53 -0500 Date: Mon, 15 Dec 2008 02:48:53 -0500 Message-Id: <20081215073634.GA28920@titan.cry.pto> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Thomas Pornin To: Multiple recipients of list Subject: Re: Thoughts on SHA-3 potential applications, esp. for small devices (LONG) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas In-Reply-To: <4945E48D.2080407@mit.edu> Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 References: <77E8A818-5279-4A62-B253-0FECF60F4596@cryptolib.com> <79B77C4C1E604E45967DBEA02EF6ED94@BobsDell> <4945676C.3050307@nist.gov> <4945E48D.2080407@mit.edu> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sun, 14 Dec 2008 23:50:52 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 351 On Mon, Dec 15, 2008 at 12:07:01AM -0500, Ronald L. Rivest wrote: > Perhaps others on this list have thoughts on how SHA-3 might > be useful on very small devices... The code size may be relevant. A small smartcard will have, say, about 256 or 512 bytes of RAM and 8 kilobytes of ROM. Clearly such a RAM size is very small, but ROM size is very limited as well, because you have to cram all the device functionality in it. Code factoring becomes essential. A generic-purpose hash function is good for that: for instance, if you need a MAC _and_ a PRNG, then you just need one hash function implementation. A collision-resistant hash function with a large output is overkill for both MAC and PRNG, but it works for both and this reuses code. In other words, industry just loves one-size-fits-all components. On a related note, I once had to implement SSL/TLS within hard code size constraints. TLS internally uses a PRF which is based on both MD5 and SHA-1, so I had to put both in my code, and this had a non-negligeable impact on the overall code size (each hash function amounted to about 10% of the resulting binary size). Note that a TLS client only needs to perform public-key operations (signature verifications on the server certificate, and pre-master key encryption); in a controlled environment, you may arrange for all public keys to be RSA with exponent 3. RSA public key operations with exponent 3 can be implemented with little CPU power and code size. --Thomas Pornin From hash-forum@nist.gov Mon Dec 15 09:56:44 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBFAJnIx009188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 02:19:49 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBFAIwHk030502; Mon, 15 Dec 2008 05:19:02 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBFAIonu019040; Mon, 15 Dec 2008 05:18:50 -0500 Date: Mon, 15 Dec 2008 05:18:50 -0500 Message-Id: <689cf6ae0812150209q60d8194dq544a8c163259259f@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "?? ?" To: Multiple recipients of list Subject: Re: OFFICIAL COMMENT:DynamicSHA X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 In-Reply-To: X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 02:19:50 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 352 Hi! I write the documentation too hurriedly. I make a mistake at "Length-extension attack ". If I can change it , I will change it. Because it is hard to find the collision of Dynamic SHA , I use no precautions against other generic attacks (multi-collisions etc.). If I know it is most important and it is not enough, I will some precautions against other generic attacks (multi-collisions etc.). such as message length. Regards Xu ZiJie 2008/12/15, v.klima@volny.cz : > > Dynamic SHA is vulnerable to generic attacks. > > According to security requirements (part 4.A iii) of the hash functions > NIST expects the SHA-3 algorithm should be resistent to length-extension > attacks. > > Length-extension attack is not correctly understood and described in > paragraph 6.1 of submitted Dynamic SHA documentations. > > As a consequence, Dynamic SHA (with 256-bit and 512-bit outputs) function > (h) is trivially vulnerable to length-extension attacks. Given h(m) > and len(m) but not m, the attacker easily creates m' (with correct padding) > and calculates h (m || m') simply from h(m) and m'. > > Moreover, in the function's design there are no precautions against other > generic attacks (multi-collisions etc.). > > Best regards, > Vlastimil Klima > > > > > > From hash-forum@nist.gov Mon Dec 15 09:56:44 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBFAJkxX009181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 02:19:47 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBFAIwHu030502; Mon, 15 Dec 2008 05:19:05 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBFAIZLj018995; Mon, 15 Dec 2008 05:18:35 -0500 Date: Mon, 15 Dec 2008 05:18:35 -0500 Message-Id: <689cf6ae0812150208v14bfe65dg1e5490849e0717f@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "?? ?" To: Multiple recipients of list Subject: Re: OFFICIAL COMMENT:DynamicSHA2 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <6c997f340db2d739fdefe5e1e94721a7@www3.mail.volny.cz> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 In-Reply-To: <6c997f340db2d739fdefe5e1e94721a7@www3.mail.volny.cz> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 02:19:48 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 353 Hi! I write the documentation too hurriedly. I make a mistake at "Length-extension attack ". If I can change it , I will change it. Because it is hard to find the collision of Dynamic SHA2 , I use no precautions against other generic attacks (multi-collisions etc.). If I know it is most important and it is not enough, I will some precautions against other generic attacks (multi-collisions etc.). such as message length. Regards Xu ZiJie 2008/12/15, v.klima@volny.cz : > > Dynamic SHA2 is vulnerable to generic attacks. > > According to security requirements (part 4.A iii) of the hash functions > NIST expects the SHA-3 algorithm should be resistent to length-extension > attacks. > > Length-extension attack is not correctly understood and described in > paragraph 6.1 of submitted Dynamic SHA2 documentations. > > As a consequence, Dynamic SHA2 (with 256-bit and 512-bit outputs) function > (h) is trivially vulnerable to length-extension attacks. Given h(m) > and len(m) but not m, the attacker easily creates m' (with correct padding) > and calculates h (m || m') simply from h(m) and m'. > > Moreover, in the function's design there are no precautions against other > generic attacks (multi-collisions etc.). > > Best regards, > Vlastimil Klima > > > > > > > > > > From hash-forum@nist.gov Mon Dec 15 09:56:52 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBFA6BmV007894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 02:06:12 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBFA58Fq012268; Mon, 15 Dec 2008 05:05:10 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBFA3ufY022335; Mon, 15 Dec 2008 05:03:56 -0500 Date: Mon, 15 Dec 2008 05:03:56 -0500 Message-Id: <20081215100903.52177.qmail@cr.yp.to> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "D. J. Bernstein" To: Multiple recipients of list Subject: Re: Engineering comparison of the SHA-3 candidates X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas In-Reply-To: <888E37A2001E364CBC4F28FA7660A2E65E26A65825@NA-EXMSG-C102.redmond.corp.microsoft.com> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 02:06:12 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: X-UID: 354 Niels Ferguson writes: > We used the recommended parameter sets for each algorithm. Then you're ignoring the rules of the SHA-3 competition. Here's what NIST said in the SHA-3 submission requirements: The submitted algorithm may include a tunable security parameter, such as the number of rounds, which would allow the selection of a range of possible security/performance tradeoffs. ... The tunable parameter may be used to produce weakened versions of the submitted algorithm for analysis, and permit NIST to select a different security/performance tradeoff than originally specified by the submitter. You've been misrepresenting this "range of possible security/performance tradeoffs" by compressing the range to a single recommended point for each submission. For example, your table includes only CubeHash8/1 (incorrectly labelled "CubeHash"), and ignores all of the other members of the CubeHash family. You should expand the table to accurately report the entire range of security/performance tradeoffs submitted to NIST. > It is one thing to change speed/security tradeoff by a few tens of > percent; changing it by several orders of magnitude is very different. I agree that it's very different. Your method of misrepresenting the submissions has a relatively small effect on aggressively designed submissions with small security margins and limited ranges of tunable security parameters; it has a much larger effect on conservatively designed submissions. > If you believe that CubeHash should be used with different parameters > I believe you should have put that in the submission Perhaps you should read the submission! It already includes reference implementations and test vectors for 28 different choices of the tunable security parameter r/b: * Most conservative: CubeHash8/1. * ~2x faster: CubeHash8/2, CubeHash4/1. * ~4x faster: CubeHash8/4, CubeHash4/2, CubeHash2/1. * ~8x faster: CubeHash8/8, CubeHash4/4, CubeHash2/2, CubeHash1/1. * ~16x faster: CubeHash8/16, CubeHash4/8, CubeHash2/4, CubeHash1/2. * ~32x faster: CubeHash8/32, CubeHash4/16, CubeHash2/8, CubeHash1/4. * ~64x faster: CubeHash8/64, CubeHash4/32, CubeHash2/16, CubeHash1/8. * ~128x faster: CubeHash4/64, CubeHash2/32, CubeHash1/16. * ~256x faster: CubeHash2/64, CubeHash1/32. * ~512x faster: CubeHash1/64. I haven't written optimized code for (e.g) CubeHash2/16 yet, but I'm sure that it will be faster than Skein-512 on the reference platform. Calling it "too slow" is silly. Of course, you're free to argue that CubeHash2/16 is worse than Skein-512 for some other reason. As for how CubeHash "should be used," here's what the submission says: Parameter recommendations. I recommend CubeHash8/1-224, CubeHash8/1-256, CubeHash8/1-384, and CubeHash8/1-512; i.e., r=8 and b=1, independent of the message-digest size. ... Justification for recommending CubeHash8/1: For most applications of hash functions, speed simply doesn't matter. High-volume network protection with HMAC is sometimes cited as an exception, but anyone who really cares about speed shouldn't be using HMAC anyway; other MACs are faster and inspire more confidence. What about the occasional applications where hashing speed _does_ matter? If, after third-party cryptanalysis, the community is convinced that much faster CubeHashr/b choices are perfectly safe, then I expect those choices to be considered in speed-oriented applications. For the same reason, I expect NIST to scientifically compare the speeds of different hash-function families by comparing the speeds of the fastest unbroken members of those families---rather than biasing the comparison according to the speculative initial recommendations of the hash-function designers. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago From hash-forum@nist.gov Mon Dec 15 09:57:21 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBFCaptw028870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 04:36:53 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBFCZK8I027361; Mon, 15 Dec 2008 07:35:25 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBFCZEfL027251; Mon, 15 Dec 2008 07:35:14 -0500 Date: Mon, 15 Dec 2008 07:35:14 -0500 Message-Id: <49464d35.1403d00a.2d75.5332@mx.google.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Danilo Gligoroski" To: Multiple recipients of list Subject: OFFICIAL COMMENT: EDON-R X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Microsoft Office Outlook 12.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C95EB8.E2338370" MIME-Version: 1.0 X-Cc: X-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 04:36:53 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-5.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED,SUBJ_ALL_CAPS shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 355 This is a multipart message in MIME format. ------=_NextPart_000_000D_01C95EB8.E2338370 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Hi, A new optimized C version of Edon-R hash function can be downloaded from: http://people.item.ntnu.no/~danilog/Hash/Additional_Implementations_edonr_De c2008.zip With Intel C++ v11.0.061 for Windows it achieves the following speeds: 32-bit environment Edon-R performance in Cycles/Byte with different message lengths in BYTES 1 10 100 1000 10000 100000 MD Size: 224 1801.00 182.50 33.13 7.22 6.43 6.46 MD Size: 256 565.00 56.50 10.21 6.67 6.44 6.46 MD Size: 384 1465.00 147.70 14.89 11.59 10.24 10.01 MD Size: 512 1489.00 148.90 15.01 11.68 10.22 10.01 64-bit environment Edon-R performance in Cycles/Byte with different message lengths in BYTES 1 10 100 1000 10000 100000 MD Size: 224 1441.00 144.10 24.25 4.92 4.56 4.41 MD Size: 256 481.00 45.70 7.69 4.81 4.57 4.30 MD Size: 384 529.00 49.30 4.93 2.44 2.26 2.29 MD Size: 512 493.00 49.30 5.05 2.50 2.29 2.29 Regards, Danilo Gligoroski ------=_NextPart_000_000D_01C95EB8.E2338370 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

Hi,

 

A new optimized C version of Edon-R hash function can be downloaded from: =

http://people.item.ntnu.no/~danilog/Hash/Additional= _Implementations_edonr_Dec2008.zip

 

 

With Intel C++ v11.0.061 for Windows it achieves the following = speeds:

 

32-bit environment

Edon-R performance in Cycles/Byte with different message lengths in = BYTES

 

=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A 1=9A=9A=9A=9A=9A=9A 10=9A=9A=9A=9A=9A 100=9A=9A=9A 1000=9A=9A=9A = 10000=9A=9A 100000

MD Size: 224=9A=9A=9A=9A=9A=9A 1801.00=9A 182.50=9A=9A 33.13=9A=9A=9A = 7.22=9A=9A=9A 6.43=9A=9A=9A 6.46

MD Size: 256=9A=9A=9A=9A=9A=9A=9A 565.00=9A=9A 56.50=9A=9A 10.21=9A=9A=9A = 6.67=9A=9A=9A 6.44=9A=9A=9A 6.46

MD Size: 384=9A=9A=9A=9A=9A=9A 1465.00=9A 147.70=9A=9A 14.89=9A=9A 11.59=9A=9A = 10.24=9A=9A 10.01

MD Size: 512=9A=9A=9A=9A=9A=9A 1489.00=9A 148.90=9A=9A 15.01=9A=9A 11.68=9A=9A = 10.22=9A=9A 10.01

 

64-bit environment

Edon-R performance in Cycles/Byte with different message lengths in = BYTES

 

=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A 1=9A=9A=9A=9A=9A=9A 10=9A=9A=9A=9A=9A 100=9A=9A=9A 1000=9A=9A=9A = 10000=9A=9A 100000

MD Size: 224=9A=9A=9A=9A=9A=9A 1441.00=9A 144.10=9A=9A 24.25=9A=9A=9A = 4.92=9A=9A=9A 4.56=9A=9A=9A 4.41

MD Size: 256=9A=9A=9A=9A=9A=9A=9A 481.00=9A=9A 45.70=9A=9A=9A 7.69=9A=9A=9A = 4.81=9A=9A=9A 4.57=9A=9A=9A 4.30

MD Size: 384=9A=9A=9A=9A=9A=9A=9A 529.00=9A=9A 49.30=9A=9A=9A 4.93=9A=9A=9A = 2.44=9A=9A=9A 2.26=9A=9A=9A 2.29

MD Size: 512=9A=9A=9A=9A=9A=9A=9A 493.00=9A=9A 49.30=9A=9A=9A 5.05=9A=9A=9A = 2.50=9A=9A=9A 2.29=9A=9A=9A 2.29

 

Regards,

Danilo Gligoroski

 

------=_NextPart_000_000D_01C95EB8.E2338370-- From hash-forum@nist.gov Mon Dec 15 09:57:21 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBFCapWQ028869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 04:36:53 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBFCZK8S027361; Mon, 15 Dec 2008 07:35:27 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBFCYIEL025729; Mon, 15 Dec 2008 07:34:18 -0500 Date: Mon, 15 Dec 2008 07:34:18 -0500 Message-Id: <49464d02.0707d00a.3738.575a@mx.google.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Danilo Gligoroski" To: Multiple recipients of list Subject: OFFICIAL COMMENT:Blue Midnight Wish X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Microsoft Office Outlook 12.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C95EB8.C389C830" MIME-Version: 1.0 X-Cc: X-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 04:36:53 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 356 This is a multipart message in MIME format. ------=_NextPart_000_0008_01C95EB8.C389C830 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, A new optimized C version of Blue Midnight Wish hash function can be downloaded from: http://people.item.ntnu.no/~danilog/Hash/Additional_Implementations_bmw_Dec2 008.zip With Intel C++ v11.0.061 for Windows it achieves the following speeds: 32-bit environment BlueMidnightWish performance in Cycles/Byte with different message lengths in BYTES 1 10 100 1000 10000 100000 MD Size: 224 697.00 66.10 11.89 8.05 7.70 7.62 MD Size: 256 697.00 70.90 12.97 8.72 7.73 7.64 MD Size: 384 1801.00 181.30 18.13 16.90 13.00 12.61 MD Size: 512 1813.00 181.30 18.49 16.90 12.99 12.61 64-bit environment BlueMidnightWish performance in Cycles/Byte with different message lengths in BYTES 1 10 100 1000 10000 100000 MD Size: 224 2041.00 204.10 11.29 7.69 7.37 7.32 MD Size: 256 637.00 63.70 11.29 7.71 7.37 7.32 MD Size: 384 649.00 64.90 6.49 3.90 3.68 3.63 MD Size: 512 697.00 64.90 6.49 3.90 3.68 3.63 Regards, Danilo Gligoroski ------=_NextPart_000_0008_01C95EB8.C389C830 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

A new optimized C version of Blue Midnight Wish hash function can be = downloaded from:

http://people.item.ntnu.no/~danilog/Hash/Additional_I= mplementations_bmw_Dec2008.zip

 

 

With Intel C++ v11.0.061 for Windows it achieves the following = speeds:

 

32-bit environment

BlueMidnightWish performance in Cycles/Byte with different message lengths in = BYTES

 

           &= nbsp;          1       10      100    1000    10000   = 100000

MD Size: 224        697.00   66.10   11.89    8.05    7.70    7.62

MD Size: 256        697.00   70.90   12.97    8.72    7.73    7.64

MD Size: 384       1801.00  181.30   18.13   16.90   13.00   = 12.61

MD Size: 512       1813.00  181.30   18.49   16.90   12.99   = 12.61

 

64-bit environment

BlueMidnightWish performance in Cycles/Byte with different message lengths in = BYTES

 

           &= nbsp;          1       10      100    1000    10000   = 100000

MD Size: 224       2041.00  204.10   11.29    7.69    7.37    = 7.32

MD Size: 256        637.00   63.70   11.29    7.71    7.37    7.32

MD Size: 384        649.00   64.90    6.49    3.90    3.68    3.63

MD Size: 512        697.00   64.90    6.49    3.90    3.68    3.63

 

Regards,

Danilo Gligoroski

 

------=_NextPart_000_0008_01C95EB8.C389C830-- From hash-forum@nist.gov Mon Dec 15 09:57:20 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBFEiYnl013851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 06:44:36 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBFEgHgY004339; Mon, 15 Dec 2008 09:42:23 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBFEdnIj027421; Mon, 15 Dec 2008 09:39:49 -0500 Date: Mon, 15 Dec 2008 09:39:49 -0500 Message-Id: <470029.8374.qm@web36405.mail.mud.yahoo.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Peter To: Multiple recipients of list Subject: Re: Thoughts on SHA-3 potential applications, esp. for small devices (LONG) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/alternative; boundary="0-1215232539-1229351625=:8374" MIME-Version: 1.0 In-Reply-To: <20081215073634.GA28920@titan.cry.pto> X-To: hash-forum@nist.gov X-Mailer: YahooMailWebService/0.7.260.1 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 06:44:37 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-4.2 required=5.0 tests=AWL,BAYES_00, FORGED_YAHOO_RCVD,HTML_MESSAGE,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 357 --0-1215232539-1229351625=:8374 Content-Type: text/plain; charset=us-ascii I think this is a very good point. Having algorithm that can also be put to other uses (such as PRNG, as mentioned, or a cipher.) should be considered a big plus. I have tried to implement minimal cryptography libraries, and have found it to be quite useful to have a multi-purpose algorithm. For example, EnRUPT (to choose the first such algorithm I can think of.) seems to be highly multi-purpose, and I think that this sort of flexibility should factor in heavily. After all, in real applications an algorithm is often bundled with other algorithms in a library of some sort. Let us say we are building a crypto lib, and need to decide between two hash algorithms; (A) and (B). If hash algorithm (A) takes up 3KiB, and hash algorithm (B) takes up 2KiB, our initial reaction (assuming all other factors are equal) is to take (B). But what if (A) can replace our 2KiB cipher as well? Then (A) suddenly looks a lot more inviting. While in isolation (B) may be better, one must remember that algorithms are rarely used in isolation. --Peter Schmidt-Nielsen (P.S. As someone obsessed with making tiny crypto libraries, I do have a bias.) --- On Mon, 12/15/08, Thomas Pornin wrote: From: Thomas Pornin Subject: Re: Thoughts on SHA-3 potential applications, esp. for small devices (LONG) To: "Multiple recipients of list" Date: Monday, December 15, 2008, 2:48 AM On Mon, Dec 15, 2008 at 12:07:01AM -0500, Ronald L. Rivest wrote: > Perhaps others on this list have thoughts on how SHA-3 might > be useful on very small devices... The code size may be relevant. A small smartcard will have, say, about 256 or 512 bytes of RAM and 8 kilobytes of ROM. Clearly such a RAM size is very small, but ROM size is very limited as well, because you have to cram all the device functionality in it. Code factoring becomes essential. A generic-purpose hash function is good for that: for instance, if you need a MAC _and_ a PRNG, then you just need one hash function implementation. A collision-resistant hash function with a large output is overkill for both MAC and PRNG, but it works for both and this reuses code. In other words, industry just loves one-size-fits-all components. On a related note, I once had to implement SSL/TLS within hard code size constraints. TLS internally uses a PRF which is based on both MD5 and SHA-1, so I had to put both in my code, and this had a non-negligeable impact on the overall code size (each hash function amounted to about 10% of the resulting binary size). Note that a TLS client only needs to perform public-key operations (signature verifications on the server certificate, and pre-master key encryption); in a controlled environment, you may arrange for all public keys to be RSA with exponent 3. RSA public key operations with exponent 3 can be implemented with little CPU power and code size. --Thomas Pornin --0-1215232539-1229351625=:8374 Content-Type: text/html; charset=us-ascii
I think this is a very good point. Having algorithm that can also be put to other uses (such as PRNG, as mentioned, or a cipher.) should be considered a big plus. I have tried to implement minimal cryptography libraries, and have found it to be quite useful to have a multi-purpose algorithm. For example, EnRUPT (to choose the first such algorithm I can think of.) seems to be highly multi-purpose, and I think that this sort of flexibility should factor in heavily. After all, in real applications an algorithm is often bundled with other algorithms in a library of some sort. Let us say we are building a crypto lib, and need to decide between two hash algorithms; (A) and (B). If hash algorithm (A) takes up 3KiB, and hash algorithm (B) takes up 2KiB, our initial reaction (assuming all other factors are equal) is to take (B). But what if (A) can replace our 2KiB cipher as well? Then (A) suddenly looks a lot more inviting. While in isolation (B) may be better, one must remember that algorithms are rarely used in isolation.

--Peter Schmidt-Nielsen

(P.S. As someone obsessed with making tiny crypto libraries, I do have a bias.)

--- On Mon, 12/15/08, Thomas Pornin <thomas.pornin@cryptolog.com> wrote:
From: Thomas Pornin <thomas.pornin@cryptolog.com>
Subject: Re: Thoughts on SHA-3 potential applications, esp. for small devices (LONG)
To: "Multiple recipients of list" <hash-forum@nist.gov>
Date: Monday, December 15, 2008, 2:48 AM

On Mon, Dec 15, 2008 at 12:07:01AM -0500, Ronald L. Rivest wrote:
> Perhaps others on this list have thoughts on how SHA-3 might
> be useful on very small devices...

The code size may be
 relevant. A small smartcard will have, say, about
256 or 512 bytes of RAM and 8 kilobytes of ROM. Clearly such a RAM size
is very small, but ROM size is very limited as well, because you have to
cram all the device functionality in it. Code factoring becomes
essential. A generic-purpose hash function is good for that: for
instance, if you need a MAC _and_ a PRNG, then you just need one hash
function implementation. A collision-resistant hash function with a
large output is overkill for both MAC and PRNG, but it works for both
and this reuses code.

In other words, industry just loves one-size-fits-all components.

On a related note, I once had to implement SSL/TLS within hard code size
constraints. TLS internally uses a PRF which is based on both MD5 and
SHA-1, so I had to put both in my code, and this had a non-negligeable
impact on the overall code size (each hash function amounted to about
10% of the
 resulting binary size). Note that a TLS client only needs to
perform public-key operations (signature verifications on the server
certificate, and pre-master key encryption); in a controlled
environment, you may arrange for all public keys to be RSA with exponent
3. RSA public key operations with exponent 3 can be implemented with
little CPU power and code size.


	--Thomas Pornin


--0-1215232539-1229351625=:8374-- From hash-forum@nist.gov Mon Dec 15 09:56:44 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBFGPGbL025870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 08:25:18 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBFGMtiZ007720; Mon, 15 Dec 2008 11:23:00 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBFGM7bD015121; Mon, 15 Dec 2008 11:22:07 -0500 Date: Mon, 15 Dec 2008 11:22:07 -0500 Message-Id: <49468121.1010304@reikon.us> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Thomas Dixon To: Multiple recipients of list Subject: Re: Thoughts on SHA-3 potential applications, esp. for small devices (LONG) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 In-Reply-To: <2a9a3e6a0812150730v573a9474l2f2b04be0b18a51b@mail.gmail.com> References: <20081215073634.GA28920@titan.cry.pto> <470029.8374.qm@web36405.mail.mud.yahoo.com> <2a9a3e6a0812150730v573a9474l2f2b04be0b18a51b@mail.gmail.com> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 08:25:18 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 358 Chen Ke-Fei Lin wrote: > On Mon, Dec 15, 2008 at 3:39 PM, Peter > wrote: > > .. For example, EnRUPT (to choose the first such algorithm I can > think of.) seems to be highly multi-purpose, and I think that > this sort of flexibility should factor in heavily. ... > > > > Dear Peter, > > HA HA, why you thinking for an example that is broken? > > C. K. F. Lin > "It is incorrect to call EnRUPT or EnRUPT/s broken in general as there is no structural flaw exploited in the recent collision attack. Only EnRUPT/4 is broken so far. After a detailed study of this attack, we can recommend the following variants: EnRUPT64x2-224/8, /s/=H=8 EnRUPT64x2-256/8, /s/=H=8 EnRUPT64x2-384/12, /s/=H=12 EnRUPT64x2-512/16, /s/=H=16" Quoted from EnRUPT.com Regards, Tom From hash-forum@nist.gov Mon Dec 15 09:56:44 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBFGWY2C027127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 08:32:36 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBFGN7dZ007796; Mon, 15 Dec 2008 11:23:11 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBFGMoi2017461; Mon, 15 Dec 2008 11:22:50 -0500 Date: Mon, 15 Dec 2008 11:22:50 -0500 Message-Id: <39F8FBA1-3E07-4BCF-9CC1-8F2B11D21F5E@zooko.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: zooko To: Multiple recipients of list Subject: EnRUPT/s is not broken X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: <20081215073634.GA28920@titan.cry.pto> <470029.8374.qm@web36405.mail.mud.yahoo.com> <2a9a3e6a0812150730v573a9474l2f2b04be0b18a51b@mail.gmail.com> In-Reply-To: <2a9a3e6a0812150730v573a9474l2f2b04be0b18a51b@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 08:32:37 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 359 On Dec 15, 2008, at 8:38 AM, Chen Ke-Fei Lin wrote: > On Mon, Dec 15, 2008 at 3:39 PM, Peter wrote: > .. For example, EnRUPT (to choose the first such algorithm I can > think of.) seems to be highly multi-purpose, and I think that this > sort of flexibility should factor in heavily. ... .. > HA HA, why you thinking for an example that is broken? It is up to NIST whether to include EnRUPT/s in subsequent rounds of SHA-3, but whether they do or not, it is incorrect to say that the EnRUPT algorithm itself is broken. EnRUPT with s=4 is broken, as is Skein with rounds=25 and CubeHash2/120. None of these three algorithms have known structural flaws that would make us think they would be unsafe when used with a number of rounds sufficiently larger than the breakable rounds. Disclosure: while I'm not the submitter of any SHA-3 candidate, I do have my biases. These three algorithms named are my three favorites of the candidates that I've examined so far. In addition, I have personal acquaintance and affection in varying degrees for the authors of these three. Regards, Zooko --- http://allmydata.org -- Tahoe, the Least-Authority Filesystem http://allmydata.com -- back up all your files for $10/month From hash-forum@nist.gov Mon Dec 15 09:56:48 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBFFeh3Y020341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 07:40:45 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBFFdENT013049; Mon, 15 Dec 2008 10:39:18 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBFFcgHH021172; Mon, 15 Dec 2008 10:38:42 -0500 Date: Mon, 15 Dec 2008 10:38:42 -0500 Message-Id: <2a9a3e6a0812150730v573a9474l2f2b04be0b18a51b@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Chen Ke-Fei Lin" To: Multiple recipients of list Subject: Re: Thoughts on SHA-3 potential applications, esp. for small devices (LONG) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <20081215073634.GA28920@titan.cry.pto> <470029.8374.qm@web36405.mail.mud.yahoo.com> Content-Type: multipart/alternative; boundary="----=_Part_31064_27025778.1229355002258" MIME-Version: 1.0 In-Reply-To: <470029.8374.qm@web36405.mail.mud.yahoo.com> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 07:40:46 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 360 ------=_Part_31064_27025778.1229355002258 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, Dec 15, 2008 at 3:39 PM, Peter wrote: > ... For example, EnRUPT (to choose the first such algorithm I can think > of.) seems to be highly multi-purpose, and I think that this sort of > flexibility should factor in heavily. ... > Dear Peter, HA HA, why you thinking for an example that is broken? C. K. F. Lin ------=_Part_31064_27025778.1229355002258 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, Dec 15, 2008 at 3:39 PM, Peter <paperclip000@yahoo.com> wrote:
.. For example, EnRUPT (to choose the first such algorithm I can think of.) seems to be highly multi-purpose, and I think that this sort of flexibility should factor in heavily. ...


Dear Peter,

HA HA, why you thinking for an example that is broken?

C. K. F. Lin

------=_Part_31064_27025778.1229355002258-- From hash-forum@nist.gov Mon Dec 15 09:56:49 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBFFIpHW016564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 07:18:53 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBFFBNif017990; Mon, 15 Dec 2008 10:11:30 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBFFAlTr027662; Mon, 15 Dec 2008 10:10:47 -0500 Date: Mon, 15 Dec 2008 10:10:47 -0500 Message-Id: <49467203.8090204@connotech.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Thierry Moreau To: Multiple recipients of list Subject: Re: Thoughts on SHA-3 potential applications, esp. for small devices (LONG) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed In-Reply-To: <4945E48D.2080407@mit.edu> References: <77E8A818-5279-4A62-B253-0FECF60F4596@cryptolib.com> <79B77C4C1E604E45967DBEA02EF6ED94@BobsDell> <4945676C.3050307@nist.gov> <4945E48D.2080407@mit.edu> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 07:18:53 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 361 I agree with the points made by Bill and Ronald. Ronald L. Rivest wrote: > > Perhaps others on this list have thoughts on how SHA-3 might > be useful on very small devices... > Here is some very anecdotical feedback from my limited experience in embedded systems and applied cryptography. I encountered a cryptographic application device using 8 bit microcontroller technology (or was it 16 bit, my memory may not be that trustworthy). The device was field-reprogrammable, and it used a MAC with a family secret key to verify the application download message (there was a kind of isolation for the secret key and download verification code). That was already a "high end" low-end microcontroller product. Nowadays (a new design ready for production when the SHA-3 standard will be available), this field-reprogramming capability would be signature-based. But chances are that the processor would be 32 bits anyway, with significant emphasis put on power consumption management (so that the product family can have battery-operated models). RFID electronic travel documents off-load the signature verification to the terminal where the traveler identity is verified -- no crypto there, not even a (short range radio) link encryption key. This is a 21th century design. From this experience, 32 bits appears as the minimum CPU width that should count for the SHA-3 competition. Moreover, the limited power budget of battery-operated devices imposes an algorithm performance requirement similar to the generic one. Thanks everyone for your participation in this fascinating competition, and thanks to NIST for managing this process. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com From hash-forum@nist.gov Mon Dec 15 09:57:21 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBFGP7Xr025828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 08:25:09 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBFGMtij007720; Mon, 15 Dec 2008 11:23:02 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBFGMktS017339; Mon, 15 Dec 2008 11:22:46 -0500 Date: Mon, 15 Dec 2008 11:22:46 -0500 Message-Id: <051B5A02-38C0-4B65-9F66-D4F82BBAE10F@mac.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Jeff Johnson To: Multiple recipients of list Subject: ASN.1 oids for SHA-3 submissions and PKCS1 RSA signatures? X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.930.3) Content-type: multipart/signed; boundary=Apple-Mail-94--205168015; micalg=sha1; protocol="application/pkcs7-signature" X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 08:25:09 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.3 required=5.0 tests=AWL,BAYES_00, MIME_HEADER_CTYPE_ONLY,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 362 --Apple-Mail-94--205168015 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Could (and more generally should) ASN.1 oids be defined for the SHA-3 candidate submissions for use by PKCS1 RSA digital signature padding? Some private oid in the hierarchy will certainly suffice for my insanities. But perhaps a interim/temporary oid definition is better than littering an already arcane hash algorithm name space, since the final SHA-3 choices will take a year or more to identify. 73 de Jeff --Apple-Mail-94--205168015 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuDCCBLUw ggQeoAMCAQICDwCkcgABAAK4E2vcIBaxtDANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQGEwJERTEc MBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RDZW50ZXIgQ2xh c3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBMMSBDQSBWSTAeFw0w ODEyMDIxMzU0MDVaFw0wOTEyMDMxMzU0MDVaMEIxCzAJBgNVBAYTAlVTMRUwEwYDVQQDEwxKZWZm IEpvaG5zb24xHDAaBgkqhkiG9w0BCQEWDW4zbnBxQG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDSrLrIMdg0i0KwjX6UOio7t8uErnKtkxSheOOd/colSfjfIvmE9RpefvAY 9frPMhGNMv4UiwwFV8WE3zm5aSz1hdkjTykpfhVTHUOUA8wJYIrLqP7T/sV/BgYUqbTFlTFp+eIh 0H5JBTVTvLwpurS5UrcTqMcmx8+kKKF0uPnLdUlBGfCDC9CImlRPhWIEs9+B1dPdPpKhuJFmpLCV Tp+4ugEqNVGuADz9huUxhw/jUm4bEibt0hMsZoNgB2lSASGCk7qbGqMcU36744rnV4ee6VV6p8Zz QtUgELId6gBTTgFn2z5P2HiB45kOPvzJkA73E5Wce/aqDNNGGaVN0LrFAgMBAAGjggHtMIIB6TCB lwYIKwYBBQUHAQEEgYowgYcwUQYIKwYBBQUHMAKGRWh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUv Y2VydHNlcnZpY2VzL2NhY2VydHMvdGNfY2xhc3MxX0wxX0NBX1ZJLmNydDAyBggrBgEFBQcwAYYm aHR0cDovL29jc3AuVkkudGNjbGFzczEudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUTpv1svvd amvcSgevybtk/xZLJp8wDAYDVR0TAQH/BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAG CCsGAQUFBwIBFiRodHRwOi8vd3d3LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/ BAQDAgTwMB0GA1UdDgQWBBS6REy96I26Zac5uz2NN06zJmQ/pTBUBgNVHR8ETTBLMEmgR6BFhkNo dHRwOi8vY3JsLlZJLnRjY2xhc3MxLnRydXN0Y2VudGVyLmRlL2NybC92Mi90Y19jbGFzczFfTDFf Q0FfVkkuY3JsMDMGA1UdJQQsMCoGCCsGAQUFBwMCBggrBgEFBQcDBAYIKwYBBQUHAwcGCisGAQQB gjcUAgIwGAYDVR0RBBEwD4ENbjNucHFAbWFjLmNvbTANBgkqhkiG9w0BAQUFAAOBgQBj7zOyIzVA K053Y937PH4zbUqgMvPU3YkGfZlkc+au4x8diMZPTTO9ry+xg5ljQ9oXtxjow6V0KDqM04zwF48P bYB43UiRI0YcPyYcTl6qP/jvNmMiisQqLTdsdWArePWLfKjMVyCPpcqVn89uYh5n2v0H5YrSrlbV 19ofNK1I0zCCBM8wggQ4oAMCAQICDwCUsAABAAJijbUfbuxyZDANBgkqhkiG9w0BAQUFADCBvDEL MAkGA1UEBhMCREUxEDAOBgNVBAgTB0hhbWJ1cmcxEDAOBgNVBAcTB0hhbWJ1cmcxOjA4BgNVBAoT MVRDIFRydXN0Q2VudGVyIGZvciBTZWN1cml0eSBpbiBEYXRhIE5ldHdvcmtzIEdtYkgxIjAgBgNV BAsTGVRDIFRydXN0Q2VudGVyIENsYXNzIDEgQ0ExKTAnBgkqhkiG9w0BCQEWGmNlcnRpZmljYXRl QHRydXN0Y2VudGVyLmRlMB4XDTA4MDcxODExMzg1NFoXDTEwMTIzMTIyNTk1OVowfDELMAkGA1UE BhMCREUxHDAaBgNVBAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2Vu dGVyIENsYXNzIDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0Eg VkkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJQFP39OlsR+FrO6sIC5tx+k3aTjsL4oCLrs rd2Z9nVMzrHxnvShlmxLhgElFThIoRzo7gr1mZbx2/Gu3X51SEBNTkP3bV2U0jn9yxGo97oYWA/+ cRUKEEsxfvbPX5DL992EupcEptQAVutm32so3dGi+nqe2mFXwx8wpDAnCkDRAgMBAAGjggIQMIIC DDCBjgYIKwYBBQUHAQEEgYEwfzBMBggrBgEFBQcwAoZAaHR0cDovL3d3dy50cnVzdGNlbnRlci5k ZS9jZXJ0c2VydmljZXMvY2FjZXJ0cy90Y19jbGFzc18xX2NhLmNydDAvBggrBgEFBQcwAYYjaHR0 cDovL29jc3AudGNjbGFzczEudHJ1c3RjZW50ZXIuZGUwDwYDVR0TAQH/BAUwAwEB/zBKBgNVHSAE QzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3LnRydXN0Y2VudGVyLmRl L2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgGGMB0GA1UdDgQWBBROm/Wy+91qa9xKB6/Ju2T/Fksm nzCB7AYDVR0fBIHkMIHhMIHeoIHboIHYhjtodHRwOi8vY3JsLnRjY2xhc3MxLnRydXN0Y2VudGVy LmRlL2NybC92Mi90Y19jbGFzc18xX2NhLmNybIaBmGxkYXA6Ly93d3cudHJ1c3RjZW50ZXIuZGUv Q049VEMlMjBUcnVzdENlbnRlciUyMENsYXNzJTIwMSUyMENBLE89VEMlMjBUcnVzdENlbnRlciUy MEFHLG91PXJvb3RjZXJ0cyxkYz10cnVzdGNlbnRlcixkYz1kZT9jZXJ0aWZpY2F0ZVJldm9jYXRp b25MaXN0P2Jhc2U/MA0GCSqGSIb3DQEBBQUAA4GBAG4ApLln3RLqDiymjdk8SFs8S6acQryrkZB/ DJ2QH6n+6LYqEjirh+/Zj8uweQL6p6d9g/dl4S1wpIGCVC33AdcM8qer/Cn0qcQ6bdduesfTcdQv 5uZlSsyEdKNa44DVtOh3IkTLtFdcDiY4tQFriM7kVC5Xuhyfxo58V1vOM8r+MIIFKDCCAxCgAwIB AgIDA+KXMA0GCSqGSIb3DQEBBQUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA3MDgwNjE2MDkyN1oXDTA5MDgwNTE2 MDkyN1owODEYMBYGA1UEAxMPQ0FjZXJ0IFdvVCBVc2VyMRwwGgYJKoZIhvcNAQkBFg1uM25wcUBt YWMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsQPDTZmNHMe8kH5hFgRyhXFD kD9qKPH01fz64dCN2PyRLj2Azgry3JBbbTSi5Tflm7V79ACnFevJ7fNIssewbdFnt9j2a6LXvD1G bKuzRqfZjgQAE16gYzlo39HZlS8srogeZk9jWTtpFrBr2BanIlimgLsMRlMJ5ikWp4CD9rTWn1fK Olr9l+UOIxhBlHGSlFc6nxFfH9kbcklxY6Qm3M8fWvuC41rRxxiAQegOmtzHGxNLk/fSQkgNzW+w EphZX3gTHajsKBlWlQvf4Ju0hYSLhiF6D2QJQUiXHBnpREqwvem2QWSJu0foCCpR8a2j81jZVuJy 4RO5OqwXdBpwTQIDAQABo4H5MIH2MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdl dCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5D QWNlcnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29j c3AuY2FjZXJ0Lm9yZzAYBgNVHREEETAPgQ1uM25wcUBtYWMuY29tMA0GCSqGSIb3DQEBBQUAA4IC AQCDQm1D9xoQMqNHySTk0yvn7IFg5uiBP5RrZAtD7g3Kb8vJ36snaYrGrLXorQQn3BzVAzkWXHE0 NaM5eLyNTxerG88XU0BCPQD/mqA0B/857tuO5TDYo9JatC276m4hAOxIcgPOuwjyFHkpZ1DMbWNG a5WyiqNynRJ6m4RHj3Ix5xZkM50p5cFn9CLArkyeWsgagVzVYpPk0GuAUiZoE+hAW7oS/OeH7xCI F6IlztL/GeV8sbit9eUlw0C0aJMXdAcnE9Q/udCdGWPDBF15NAbwARBKr8cbyAoNvxptsQ0h9M+1 W6Q0suoPUULWyueGDgzm/6V9Yktf9QyF72dEiiwJ+as/DXfNR4a7kjpV5aFcirwUWMZDXCEAqM3f fYhpvCme+rM3w9UlN4oGi53Odcdm321XhsFdiS3EytB44ny3gsyt7c8XUbcRxIfdSP542xROhUYC JTPYejMUcu29ntVSm/oLPn4TwWPNmxN5wOwypOvK6//X2NpHTDzybrIj6eseu+m3Sy+yDcLDKIkS 7V9RxNvaN+bgom7NHWZyzUNlluznoWqRAIBUoAUdcSQsN9/cNtxJ9rpDhm3RQN5DgkAXKUgC+wXz /jR7vRlcD1qXn/RYzKJUQG6PaVGLl77vtQf1amPrTpSZJ+yBLmnBisguuQ0rKGEKPUYPCCg+3tgD TzGCA0IwggM+AgEBMIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBH bWJIMSUwIwYDVQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBU cnVzdENlbnRlciBDbGFzcyAxIEwxIENBIFZJAg8ApHIAAQACuBNr3CAWsbQwCQYFKw4DAhoFAKCC AYcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgxMjE1MTYxMzM5 WjAjBgkqhkiG9w0BCQQxFgQUk3EGdAQZZmxDb9Q1g0dnNQMkWcYwgZEGCSsGAQQBgjcQBDGBgzCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAg BgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRA Y2FjZXJ0Lm9yZwIDA+KXMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENB MR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDA+KXMA0GCSqG SIb3DQEBAQUABIIBAEfJ6p7/8CdFPf+3vkVPf/vHnZmm6kMI1aHWJzCH5posJtGHC7G+QUO1Lbwh LQVPpLqdjUAxhSCkgfcQ0LinfTT/bvOTu4GKpxhpuwq+/QWCqS2/YBm/tXI36ouOXeFXi5MbKgo9 12mE4A6+VudX//tMsnt/Vj7gfoCKov/T/QUZI6WcmAnMTXu5fHe8sCFkO9wQFWlnd4SxoLwEaq8P QoWc2R1kFQhvrqSza7HBwfSVAQkjok3tJyMnxwIiCrUB9PwfwsTAvmtGB4BZBgT+LJjeLpJtxy4I JL5kcvPm9U3nVMXRq6Si80L57lG3EogbsLsztAqYmUkxFG+mvYcQBEcAAAAAAAA= --Apple-Mail-94--205168015-- From hash-forum@nist.gov Mon Dec 15 09:57:22 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBFFuQnN022185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 07:56:27 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBFFsYs4011094; Mon, 15 Dec 2008 10:54:40 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBFFsSKe021543; Mon, 15 Dec 2008 10:54:28 -0500 Date: Mon, 15 Dec 2008 10:54:28 -0500 Message-Id: <49467D01.8040806@nist.gov> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Bill Burr To: Multiple recipients of list Subject: Re: Thoughts on SHA-3 potential applications, esp. for small devices (LONG) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/alternative; boundary="------------090806060709020407070306" In-Reply-To: <470029.8374.qm@web36405.mail.mud.yahoo.com> References: <470029.8374.qm@web36405.mail.mud.yahoo.com> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 07:56:28 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 363 This is a multi-part message in MIME format. --------------090806060709020407070306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I haven't thought too much about this, yet, but obviously some of the proposals are pretty much stream ciphers, and at least one fairly explicitly gives us a new wide-block cipher, while others use the AES round function or at least the s-boxes. It's not immediately clear to me that we need a standard wide block cipher, but I have people here who are interested in this and some outside people have been bugging us. I'm not sure if picking a collision resistant hash function is the right way to back into either a stream cipher or a wide block cipher standard. There is a case to be made for reusing the AES round function, I think, and another case to be made that is putting too many eggs in one basket. Regards, Bill Peter wrote: > I think this is a very good point. Having algorithm that can also be > put to other uses (such as PRNG, as mentioned, or a cipher.) should be > considered a big plus. I have tried to implement minimal cryptography > libraries, and have found it to be quite useful to have a > multi-purpose algorithm. For example, EnRUPT (to choose the first such > algorithm I can think of.) seems to be highly multi-purpose, and I > think that this sort of flexibility should factor in heavily. After > all, in real applications an algorithm is often bundled with other > algorithms in a library of some sort. Let us say we are building a > crypto lib, and need to decide between two hash algorithms; (A) and > (B). If hash algorithm (A) takes up 3KiB, and hash algorithm (B) takes > up 2KiB, our initial reaction (assuming all other factors are equal) > is to take (B). But what if (A) can replace our 2KiB cipher as well? > Then (A) suddenly looks a lot more inviting. While in isolation (B) > may be better, one must remember that algorithms are rarely used in > isolation. > > --Peter Schmidt-Nielsen > > (P.S. As someone obsessed with making tiny crypto libraries, I do have > a bias.) > > --- On *Mon, 12/15/08, Thomas Pornin //* > wrote: > > From: Thomas Pornin > Subject: Re: Thoughts on SHA-3 potential applications, esp. for > small devices (LONG) > To: "Multiple recipients of list" > Date: Monday, December 15, 2008, 2:48 AM > > On Mon, Dec 15, 2008 at 12:07:01AM -0500, Ronald L. Rivest wrote: > > Perhaps others on this list have thoughts on how SHA-3 might > > be useful on very small devices... > > The code size may be > relevant. A small smartcard will have, say, about > 256 or 512 bytes of RAM and 8 kilobytes of ROM. Clearly such a RAM size > is very small, but ROM size is very limited as well, because you have to > cram all the device functionality in it. Code factoring becomes > essential. A generic-purpose hash function is good for that: for > instance, if you need a MAC _and_ a PRNG, then you just need one hash > function implementation. A collision-resistant hash function with a > large output is overkill for both MAC and PRNG, but it works for both > and this reuses code. > > In other words, industry just loves one-size-fits-all components. > > On a related note, I once had to implement SSL/TLS within hard code size > constraints. TLS internally uses a PRF which is based on both MD5 and > SHA-1, so I had to put both in my code, and this had a non-negligeable > impact on the overall code size (each hash function amounted to about > 10% of the > resulting binary size). Note that a TLS client only needs to > perform public-key operations (signature verifications on the server > certificate, and pre-master key encryption); in a controlled > environment, you may arrange for all public keys to be RSA with exponent > 3. RSA public key operations with exponent 3 can be implemented with > little CPU power and code size. > > > --Thomas Pornin > > > > -- William E. Burr Manager, Security Technology Group NIST 100 Bureau Dr., MS 8931 Gaithersburg, MD. 20899 Bldg. 222, Rm B362 Tel: 301-975-2914 Fax: 301-975-8670 --------------090806060709020407070306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I haven't thought too much about this, yet, but obviously some of the proposals are pretty much stream ciphers, and at least one fairly explicitly gives us a new wide-block cipher, while others use the AES round function or at least the s-boxes.  It's not immediately clear to me that we need a standard wide block cipher, but I have people here who are interested in this and some outside people have been bugging us.  I'm not sure if picking a collision resistant hash function is the right way to back into either a stream cipher or a wide block cipher standard.  There is a case to be made for reusing the AES round function, I think, and another case to be made that is putting too many eggs in one basket.

Regards,

Bill

Peter wrote:
I think this is a very good point. Having algorithm that can also be put to other uses (such as PRNG, as mentioned, or a cipher.) should be considered a big plus. I have tried to implement minimal cryptography libraries, and have found it to be quite useful to have a multi-purpose algorithm. For example, EnRUPT (to choose the first such algorithm I can think of.) seems to be highly multi-purpose, and I think that this sort of flexibility should factor in heavily. After all, in real applications an algorithm is often bundled with other algorithms in a library of some sort. Let us say we are building a crypto lib, and need to decide between two hash algorithms; (A) and (B). If hash algorithm (A) takes up 3KiB, and hash algorithm (B) takes up 2KiB, our initial reaction (assuming all other factors are equal) is to take (B). But what if (A) can replace our 2KiB cipher as well? Then (A) suddenly looks a lot more inviting. While in isolation (B) may be better, one must remember that algorithms are rarely used in isolation.

--Peter Schmidt-Nielsen

(P.S. As someone obsessed with making tiny crypto libraries, I do have a bias.)

--- On Mon, 12/15/08, Thomas Pornin <thomas.pornin@cryptolog.com> wrote:
From: Thomas Pornin <thomas.pornin@cryptolog.com>
Subject: Re: Thoughts on SHA-3 potential applications, esp. for small devices (LONG)
To: "Multiple recipients of list" <hash-forum@nist.gov>
Date: Monday, December 15, 2008, 2:48 AM

On Mon, Dec 15, 2008 at 12:07:01AM -0500, Ronald L. Rivest wrote:
> Perhaps others on this list have thoughts on how SHA-3 might
> be useful on very small devices...

The code size may be
 relevant. A small smartcard will have, say, about
256 or 512 bytes of RAM and 8 kilobytes of ROM. Clearly such a RAM size
is very small, but ROM size is very limited as well, because you have to
cram all the device functionality in it. Code factoring becomes
essential. A generic-purpose hash function is good for that: for
instance, if you need a MAC _and_ a PRNG, then you just need one hash
function implementation. A collision-resistant hash function with a
large output is overkill for both MAC and PRNG, but it works for both
and this reuses code.

In other words, industry just loves one-size-fits-all components.

On a related note, I once had to implement SSL/TLS within hard code size
constraints. TLS internally uses a PRF which is based on both MD5 and
SHA-1, so I had to put both in my code, and this had a non-negligeable
impact on the overall code size (each hash function amounted to about
10% of the
 resulting binary size). Note that a TLS client only needs to
perform public-key operations (signature verifications on the server
certificate, and pre-master key encryption); in a controlled
environment, you may arrange for all public keys to be RSA with exponent
3. RSA public key operations with exponent 3 can be implemented with
little CPU power and code size.


	--Thomas Pornin

          


-- 
William E. Burr
Manager, Security Technology Group
NIST
100 Bureau Dr., MS 8931
Gaithersburg, MD. 20899
Bldg. 222, Rm B362
Tel: 301-975-2914
Fax: 301-975-8670
--------------090806060709020407070306-- From hash-forum@nist.gov Mon Dec 15 09:57:46 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBFFu299022115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 07:56:04 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBFFsPNq011016; Mon, 15 Dec 2008 10:54:29 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBFFrbGx019767; Mon, 15 Dec 2008 10:53:37 -0500 Date: Mon, 15 Dec 2008 10:53:37 -0500 Message-Id: <49467AB0.1070505@nist.gov> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Bill Burr To: Multiple recipients of list Subject: Re: Engineering comparison of the SHA-3 candidates X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/alternative; boundary="------------020302060904060309050605" In-Reply-To: <20081215100903.52177.qmail@cr.yp.to> References: <20081215100903.52177.qmail@cr.yp.to> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 07:56:05 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 364 This is a multi-part message in MIME format. --------------020302060904060309050605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dan, There is one obvious difficulty here. We'll get performance data sooner than we get data on attacks (save, of course, for the easily broken algorithms). All we can really know about security margins early on is that an algorithm is in fact broken, or, perhaps, that it relies on some "tried and true" primitive - say the AES round function, which may lend some confidence. In fact I'll go so far as to say that until we get to the final round, we won't be particularly confident that we know about how many rounds people are going to be able to analyze. That makes it a bit hard to normalize performance by some notion of safety margin. That's why I don't want to put a lot of emphasis in selecting the second round candidates. Maybe a few submissions are just so slow that can tell that we just couldn't live with them. Maybe some use so much memory that we'll also know early on that we can't live with them either. I'm more concerned at this point with reducing the population of candidates to a number the community can study more intensely, while preserving most of the "genetic diversity," than selecting the 15 apparently fastest algorithms. But in the end, performance matters. This kind of cryptography isn't all that hard, I think, if we ignore performance. Maybe even I could design a secure collision resistant hash function if I could have enough memory and cycles per byte. So, while it may be that performance isn't a huge problem in most applications for collision resistant hashes on desktop computers, we're still looking for a pretty efficient trade-off of memory, cycles and gates. And maybe parallelizability as well (of course there are plenty of ways to skin this particular cat). When Larry ran CubeHash he said, "boy that's a slow one." I had read the paper so I wasn't surprised. There is a certain risk in your strategy - first impressions can stick with people. I think we can say something similar for MD6, there are some fairly conservative choices there also. But we are not going to make second round selections mainly on early performance data before we have any good sense of how secure the algorithms are. For me at least, the most appealing submissions are the ones where I can see a clear design philosophy and understand the engineering trade-offs. I have to depend on other people here for a sense of how hard it may be to analyze the algorithms, I'm no cryptanalyst. I'm glad to see Niel's analysis, and others that gather and compare data, even if there may be a certain propaganda element to some of them. I have to try to preserve a certain neutrality, and I'm hoping we'll see more comparisons from observers who have no particular dog in this fight. Certainly in the AES competition we got a fair amount of that, and Brian Gladman's code was particularly helpful, I thought. Regards, Bill D. J. Bernstein wrote: > Niels Ferguson writes: > >> We used the recommended parameter sets for each algorithm. >> > > Then you're ignoring the rules of the SHA-3 competition. Here's what > NIST said in the SHA-3 submission requirements: > > The submitted algorithm may include a tunable security parameter, > such as the number of rounds, which would allow the selection of a > range of possible security/performance tradeoffs. ... The tunable > parameter may be used to produce weakened versions of the submitted > algorithm for analysis, and permit NIST to select a different > security/performance tradeoff than originally specified by the > submitter. > > You've been misrepresenting this "range of possible security/performance > tradeoffs" by compressing the range to a single recommended point for > each submission. For example, your table includes only CubeHash8/1 > (incorrectly labelled "CubeHash"), and ignores all of the other members > of the CubeHash family. You should expand the table to accurately report > the entire range of security/performance tradeoffs submitted to NIST. > > >> It is one thing to change speed/security tradeoff by a few tens of >> percent; changing it by several orders of magnitude is very different. >> > > I agree that it's very different. Your method of misrepresenting the > submissions has a relatively small effect on aggressively designed > submissions with small security margins and limited ranges of tunable > security parameters; it has a much larger effect on conservatively > designed submissions. > > >> If you believe that CubeHash should be used with different parameters >> I believe you should have put that in the submission >> > > Perhaps you should read the submission! It already includes reference > implementations and test vectors for 28 different choices of the tunable > security parameter r/b: > > * Most conservative: CubeHash8/1. > * ~2x faster: CubeHash8/2, CubeHash4/1. > * ~4x faster: CubeHash8/4, CubeHash4/2, CubeHash2/1. > * ~8x faster: CubeHash8/8, CubeHash4/4, CubeHash2/2, CubeHash1/1. > * ~16x faster: CubeHash8/16, CubeHash4/8, CubeHash2/4, CubeHash1/2. > * ~32x faster: CubeHash8/32, CubeHash4/16, CubeHash2/8, CubeHash1/4. > * ~64x faster: CubeHash8/64, CubeHash4/32, CubeHash2/16, CubeHash1/8. > * ~128x faster: CubeHash4/64, CubeHash2/32, CubeHash1/16. > * ~256x faster: CubeHash2/64, CubeHash1/32. > * ~512x faster: CubeHash1/64. > > I haven't written optimized code for (e.g) CubeHash2/16 yet, but I'm > sure that it will be faster than Skein-512 on the reference platform. > Calling it "too slow" is silly. Of course, you're free to argue that > CubeHash2/16 is worse than Skein-512 for some other reason. > > As for how CubeHash "should be used," here's what the submission says: > > Parameter recommendations. I recommend CubeHash8/1-224, > CubeHash8/1-256, CubeHash8/1-384, and CubeHash8/1-512; i.e., r=8 > and b=1, independent of the message-digest size. ... > > Justification for recommending CubeHash8/1: For most applications of > hash functions, speed simply doesn't matter. High-volume network > protection with HMAC is sometimes cited as an exception, but anyone > who really cares about speed shouldn't be using HMAC anyway; other > MACs are faster and inspire more confidence. > > What about the occasional applications where hashing speed _does_ > matter? If, after third-party cryptanalysis, the community is > convinced that much faster CubeHashr/b choices are perfectly safe, > then I expect those choices to be considered in speed-oriented > applications. For the same reason, I expect NIST to scientifically > compare the speeds of different hash-function families by comparing > the speeds of the fastest unbroken members of those families---rather > than biasing the comparison according to the speculative initial > recommendations of the hash-function designers. > > ---D. J. Bernstein > Research Professor, Computer Science, University of Illinois at Chicago > > -- William E. Burr Manager, Security Technology Group NIST 100 Bureau Dr., MS 8931 Gaithersburg, MD. 20899 Bldg. 222, Rm B362 Tel: 301-975-2914 Fax: 301-975-8670 --------------020302060904060309050605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dan,

There is one obvious difficulty here.  We'll get performance data sooner than we get data on attacks (save, of course, for the easily broken algorithms).  All we can really know about security margins early on is that an algorithm is in fact broken, or, perhaps, that it relies on some "tried and true" primitive - say the AES round function, which may lend some confidence.  In fact I'll go so far as to say that until we get to the final round, we won't be particularly confident that we know about how many rounds people are going to be able to analyze.  That makes it a bit hard to normalize performance by some notion of safety margin.

That's why I don't want to put a lot of emphasis in selecting the second round candidates.  Maybe a few submissions are just so slow that can tell that we just couldn't live with them.  Maybe some use so much memory that we'll also know early on that we can't live with them either.  I'm more concerned at this point with reducing the population of candidates to a number the community can study more intensely, while preserving most of the "genetic diversity," than selecting the 15 apparently fastest algorithms.

But in the end, performance matters.  This kind of cryptography isn't all that hard, I think, if we ignore performance.  Maybe even I could design a secure collision resistant hash function if I could have enough memory and cycles per byte.  So, while it may be that performance isn't a huge problem in most applications for collision resistant hashes on desktop computers, we're still looking for a pretty efficient trade-off of memory, cycles and gates.  And maybe parallelizability as well (of course there are plenty of ways to skin this particular cat).

When Larry ran CubeHash he said, "boy that's a slow one."  I had read the paper so I wasn't surprised.  There is a certain risk in your strategy - first impressions can stick with people.  I think we can say something similar for MD6, there are some fairly conservative choices there also.  But we are not going to make second round selections mainly on early performance data before we have any good sense of how secure the algorithms are.  For me at least, the most appealing submissions are the ones where I can see a clear design philosophy and understand the engineering trade-offs.  I have to depend on other people here for a sense of how hard it may be to analyze the algorithms, I'm no cryptanalyst. 

I'm glad to see Niel's analysis, and others that gather and compare data, even if there may be a certain propaganda element to some of them.  I have to try to preserve a certain neutrality, and I'm hoping we'll see more comparisons from observers who have no particular dog in this fight.  Certainly in the AES competition we got a fair amount of that, and Brian Gladman's code was particularly helpful, I thought.

Regards,

Bill


D. J. Bernstein wrote: 
Niels Ferguson writes:
  
We used the recommended parameter sets for each algorithm. 
    

Then you're ignoring the rules of the SHA-3 competition. Here's what
NIST said in the SHA-3 submission requirements:

   The submitted algorithm may include a tunable security parameter,
   such as the number of rounds, which would allow the selection of a
   range of possible security/performance tradeoffs. ... The tunable
   parameter may be used to produce weakened versions of the submitted
   algorithm for analysis, and permit NIST to select a different
   security/performance tradeoff than originally specified by the
   submitter.

You've been misrepresenting this "range of possible security/performance
tradeoffs" by compressing the range to a single recommended point for
each submission. For example, your table includes only CubeHash8/1
(incorrectly labelled "CubeHash"), and ignores all of the other members
of the CubeHash family. You should expand the table to accurately report
the entire range of security/performance tradeoffs submitted to NIST.

  
It is one thing to change speed/security tradeoff by a few tens of
percent; changing it by several orders of magnitude is very different.
    

I agree that it's very different. Your method of misrepresenting the
submissions has a relatively small effect on aggressively designed
submissions with small security margins and limited ranges of tunable
security parameters; it has a much larger effect on conservatively
designed submissions.

  
If you believe that CubeHash should be used with different parameters
I believe you should have put that in the submission
    

Perhaps you should read the submission! It already includes reference
implementations and test vectors for 28 different choices of the tunable
security parameter r/b:

   * Most conservative: CubeHash8/1.
   * ~2x faster: CubeHash8/2, CubeHash4/1.
   * ~4x faster: CubeHash8/4, CubeHash4/2, CubeHash2/1.
   * ~8x faster: CubeHash8/8, CubeHash4/4, CubeHash2/2, CubeHash1/1.
   * ~16x faster: CubeHash8/16, CubeHash4/8, CubeHash2/4, CubeHash1/2.
   * ~32x faster: CubeHash8/32, CubeHash4/16, CubeHash2/8, CubeHash1/4.
   * ~64x faster: CubeHash8/64, CubeHash4/32, CubeHash2/16, CubeHash1/8.
   * ~128x faster: CubeHash4/64, CubeHash2/32, CubeHash1/16.
   * ~256x faster: CubeHash2/64, CubeHash1/32.
   * ~512x faster: CubeHash1/64.

I haven't written optimized code for (e.g) CubeHash2/16 yet, but I'm
sure that it will be faster than Skein-512 on the reference platform.
Calling it "too slow" is silly. Of course, you're free to argue that
CubeHash2/16 is worse than Skein-512 for some other reason.

As for how CubeHash "should be used," here's what the submission says:

   Parameter recommendations. I recommend CubeHash8/1-224,
   CubeHash8/1-256, CubeHash8/1-384, and CubeHash8/1-512; i.e., r=8
   and b=1, independent of the message-digest size. ...
   
   Justification for recommending CubeHash8/1: For most applications of
   hash functions, speed simply doesn't matter. High-volume network
   protection with HMAC is sometimes cited as an exception, but anyone
   who really cares about speed shouldn't be using HMAC anyway; other
   MACs are faster and inspire more confidence.

   What about the occasional applications where hashing speed _does_
   matter? If, after third-party cryptanalysis, the community is
   convinced that much faster CubeHashr/b choices are perfectly safe,
   then I expect those choices to be considered in speed-oriented
   applications. For the same reason, I expect NIST to scientifically
   compare the speeds of different hash-function families by comparing
   the speeds of the fastest unbroken members of those families---rather
   than biasing the comparison according to the speculative initial
   recommendations of the hash-function designers.

---D. J. Bernstein
   Research Professor, Computer Science, University of Illinois at Chicago

  

-- 
William E. Burr
Manager, Security Technology Group
NIST
100 Bureau Dr., MS 8931
Gaithersburg, MD. 20899
Bldg. 222, Rm B362
Tel: 301-975-2914
Fax: 301-975-8670
--------------020302060904060309050605-- From hash-forum@nist.gov Mon Dec 15 09:56:41 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBFGkq1Q029324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 08:50:22 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBFGbjkQ005653; Mon, 15 Dec 2008 11:37:52 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBFGbbIU014210; Mon, 15 Dec 2008 11:37:37 -0500 Date: Mon, 15 Dec 2008 11:37:37 -0500 Message-Id: <49468774.8060503@nist.gov> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Sara Caswell To: Multiple recipients of list Subject: Re: Cheetah.zip X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: <3891D3C5-E01C-4840-A8D1-EB54BF62E89C@cryptolib.com> References: <3891D3C5-E01C-4840-A8D1-EB54BF62E89C@cryptolib.com> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 08:50:23 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.1 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 365 The Cheetah.zip file has been updated to include the "Cheetah" root directory. As far as the files listed below (and others that may not be listed), we chose to leave the information inside the directories just as the submitters had provided us. -Sara Sean O'Neil wrote: > >> http://csrc.nist.gov/groups/ST/hash/sha-3/Round1/documents/Cheetah.zip >> is the only archive without the root directory. > > Also, > Fugue.zip contains gzipped tar balls instead of directories, > Hamsi.zip has a directory and an archive with its reference > implementation in it and it is not clear which one of the two we are > to use as their contents are slightly different, > Spectral_Hash.zip directory names are all cut to 8 letters and > capitalized, and > A half of the archives have spaces instead of the underscores and some > of them have odd capitalizations that may cause problems for unix > users. Everyone will have to rename them all by hand... Don't shoot! > > Best regards, > Sean O'Neil > http://www.enrupt.com/ - Raising the bar. > > From hash-forum@nist.gov Mon Dec 15 09:56:42 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBFGd5aG028125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 09:19:00 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBFGbZ5M004476; Mon, 15 Dec 2008 11:37:42 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBFGbGKJ013466; Mon, 15 Dec 2008 11:37:16 -0500 Date: Mon, 15 Dec 2008 11:37:16 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Sean O'Neil" To: Multiple recipients of list Subject: Re: Thoughts on SHA-3 potential applications, esp. for small devices (LONG) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: <20081215073634.GA28920@titan.cry.pto> <470029.8374.qm@web36405.mail.mud.yahoo.com> <2a9a3e6a0812150730v573a9474l2f2b04be0b18a51b@mail.gmail.com> In-Reply-To: <2a9a3e6a0812150730v573a9474l2f2b04be0b18a51b@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 09:19:01 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 366 On 15 Dec 2008, at 16:38, Chen Ke-Fei Lin wrote: > HA HA, why you thinking for an example that is broken? > > C. K. F. Lin Dear Chen, I must insist yet again that 'it' meaning 'EnRUPT' is *not* broken, only 'EnRUPT64x2/4' variant that uses 8 rounds between inputs is (and so far only vulnerable to collision searches, not preimage attacks). EnRUPT was submitted with a tunable speed/performance parameter and it is currently advised to cryptanalyse s=H variants, not s=4. Just like it is incorrect to call CubeHash broken in general just because one of its low-round variants is. Peter was using the example of EnRUPT because of its flexibility as a multi-purpose algorithm suitable for minimal area/RAM/ROM applications. Public cryptanalysis will reveal what parameters are best for all its security/performance trade-offs. With best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. From hash-forum@nist.gov Mon Dec 15 09:56:43 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBFHLZJf032661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 09:21:37 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBFHKKaK004940; Mon, 15 Dec 2008 12:20:28 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBFHK5Z0003928; Mon, 15 Dec 2008 12:20:05 -0500 Date: Mon, 15 Dec 2008 12:20:05 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Paul Hoffman To: Multiple recipients of list Subject: Re: ASN.1 oids for SHA-3 submissions and PKCS1 RSA signatures? X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: text/plain; charset="us-ascii" X-To: hash-forum@nist.gov References: <051B5A02-38C0-4B65-9F66-D4F82BBAE10F@mac.com> In-Reply-To: <051B5A02-38C0-4B65-9F66-D4F82BBAE10F@mac.com> Mime-Version: 1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 09:21:37 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 367 At 11:22 AM -0500 12/15/08, Jeff Johnson wrote: >Could (and more generally should) ASN.1 oids be defined for >the SHA-3 candidate submissions for use by PKCS1 RSA digital signature padding? > >Some private oid in the hierarchy will certainly suffice for my insanities. > >But perhaps a interim/temporary oid definition is better than littering an >already arcane hash algorithm name space, since the final SHA-3 choices >will take a year or more to identify. For what do you need even temporary OIDs? Why would you be using any of the candidates in protocols before significant analysis has been done on them? --Paul Hoffman, Director --VPN Consortium From hash-forum@nist.gov Mon Dec 15 09:57:45 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBFHLWZq032637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 09:21:34 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBFHK00s004834; Mon, 15 Dec 2008 12:20:05 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBFHIqfA001799; Mon, 15 Dec 2008 12:18:52 -0500 Date: Mon, 15 Dec 2008 12:18:52 -0500 Message-Id: <5574ACE4ACD88E45A7026FA0E350334B039F53@cleopatra.spyrus.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Robert Jueneman" To: Multiple recipients of list Subject: RE: Thoughts on SHA-3 potential applications, esp. for small devices (LONG) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit X-To: References: <77E8A818-5279-4A62-B253-0FECF60F4596@cryptolib.com> <79B77C4C1E604E45967DBEA02EF6ED94@BobsDell> <4945676C.3050307@nist.gov> <4945E48D.2080407@mit.edu> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 09:21:35 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 368 Ron and Bill, I don't have a dog in this fight, but I'd like to comment on the size issue, since SPYRUS is involved in both the low-cost, low-power, bandwidth-constrained smartcard end of the spectrum and the relatively unconstrained HSM and/or host-based processing system at the other. For interoperability, it is essential that we have an efficient algorithm that can run in both spaces. I also agree with the need for multi-purpose algorithms -- we were the first and perhaps still one of the few organizations to use HASH_DRBG from SP 800-90 for random number generation. (Somehow, using AES to generate keys to be used for AES seemed like putting too many eggs in one basket, especially when you think about SPA and DPA attacks.) With regard to hashing vs. digital signatures on a chip, the issue is more likely going to be bandwidth rather than processing power, as smart cards normally support only the IOS 7816 interface -- maybe 100 kbps at best. Our smart cards have no difficultly computing ECDSA, EC-DH, and ECMQV for P-256, P-384, and P-521, and the code size constraint isn't much of a limitation -- the code will fit comfortably into ROM or EEPROM, as required. But don't expect it to be done in a millisecond. In that regard, it is important to remember that although Moore's Law predicts ever-increasing transistor density, and that generally translates into increased speed and what I will call agility (parallelism, redundant implementations, etc.), there is one thing that Moore's law does NOT provide, and that is the increased power required to operate these devices. I'm certainly not a semi-conductor physicist, but I don't recall reading anything about reducing the power required to flip a bit in a transistor. And the faster you want to do that, the more electrical power it takes. So when you start talking about nano-processors, that is likely to be the limiting factor. And where that shows up in today's market is with respect very low cost, very low power RFID chips. In that market, I expect that a keyed hash will continue to be very important as an alternative to the slower digital signatures of comparable strength. Maybe not HMAC -- no disrespect to Hugo, but I would like to see a keyed MAC algorithm devised that is less computationally intensive -- but surely something along those lines. On the other hand, if we aren't talking about creating hashes and digital signatures that will be sufficiently robust to resist cryptanalytic attacks for hundreds of years or more, but only need to survive a couple of years against modest attacker resources, then a 512-bit algorithm may be overkill, and 128-bits may even be sufficient. I guess I'm arguing for algorithms with "knobs" that can be used to easily tune the performance characteristics as required, while still providing interoperability. Regards, Bob Robert R. Jueneman Chief Scientist SPYYRUS, Inc. -----Original Message----- From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Ronald L. Rivest Sent: Sunday, December 14, 2008 9:07 PM To: Multiple recipients of list Subject: Thoughts on SHA-3 potential applications, esp. for small devices (LONG) Hi Bill -- I appreciate your thoughtful essays... There are indeed a lot of dimensions and tradeoffs to consider for the SHA-3 competition. If we think about why one wants a hash standard, four reasons come to mind (in no particular order): (1) A standard promotes and facilitates _interoperability_ between products produced by different organizations. (2) A standard will have been thoroughly evaluated for cryptographic strength. (3) A standard will be accompanied by a multitude of well-engineered and tested implementations for various platforms. (4) A standard, by being a standard, facilitates decision-making by organizations that are too risk-averse and non-technical to make a decision in the absence of a standard. For a hash function, I suspect that the main use for interoperability between products of different organizations will probably continue to be as a component of digital signatures. I do wonder, as you do, what the real needs will be for cryptographic primitives on various platforms, as time goes forward. The future, as usual, is not always predictable. The needs of very small devices are perhaps the most interesting question to consider. Devices that are already sufficiently powerful to compute public-key digital signatures are presumably going to be big enough to easily accommodate any sort of reasonable hash function as well. I think that devices that are too small to perform a public-key digital signature will frequently nonetheless have a requirement to authenticate themselves---to perform a MAC. (As you said.) But the requirements for MAC's are different (and in many ways simpler) than those for hash functions. We care about forgery rather than collision resistance, MAC outputs can be shorter than hash function outputs, etc. I feel it would be a bit strange to let the hash function competition be driven by the expectation that, for small devices, there is a need to utilize the SHA-3 hash function to produce MAC's. If the world is going to be filled up with tiny devices that need to authenticate themselves, then there is a clear need for an appropriate MAC standard. The SHA-3 competition was not set up to produce such a standard; it merely noted that suitability for use in HMAC was a SHA-3 requirement. It would probably be a mistake for the world to conclude that NIST feels that all small devices should be using HMAC as an authentication technology, when there are likely to be much better alternatives for small devices. (Perhaps down the road NIST would enjoy running a "nano-MAC" standards competition!) I also suspect that in the world of very small devices, almost all system designs will be proprietary and closed. Think for example of mass transit card systems or building access cards. There is no need for small devices in these systems to work "outside the system". The need for interoperability through an open standard is not wanted (indeed, it may be very much undesired). Thus, for very small devices the need for a standard in order to support interoperability may be small or absent. Of course, there may be exceptions, and who knows what future systems will need. But I find it hard to think of applications for hashing for very small devices where: -- the device is too small for public-key operations -- the hash function is not being used for a MAC To see why, note that abstractly, a hash value is often used as a "proxy" for the value being hashed. Its shorter length may be better suited for computation (as for a digital signature) or for communication (e.g. for the hash of a message being transmitted by a different channel, or at a different time). But very small devices don't have more than one communication channel, and they don't have much storage, so applications that send a hash value from a small device, so that it can later send the real message, seem dubious (it requires storage). Applications that send the hash so that the real message can be sent via another channel may also be rare, since the device doesn't have more than one channel. It isn't very clear to me what utility a "hash value as a proxy for a message" philosophy has for very small devices. Finally, a hash value can be appended to a message for transmission, but if one merely wants redundancy it can be done in better ways. (Keyed redundancy is different, but that is what a MAC gives.) I suspect that the world will indeed be filled with lots of fascinating small electronic devices, but I think that if they do crypto, it will almost certainly be MAC's or digital signatures. It is unlikely to be unkeyed hash function application. Perhaps I've overlooked something important, but I'm far from persuaded that the SHA-3 standard will be very relevant for very small devices, until you get up to size where the device is capable of performing public-key digital signatures. Then it will become relevant. But at that point, we've got fairly substantial resources already devoted to doing crypto, and one should be considering the digital signature operation as a whole; the hash function implementation may be a small piece of that whole. And of course, Moore's Law hasn't quite died yet, and transistors continue to shrink. For small devices, at some point the cost of bonding and packaging them should greatly exceed the cost of producing the chip. (Perhaps we are there already...) Perhaps others on this list have thoughts on how SHA-3 might be useful on very small devices... These are good discussions to have, and I appreciate your bringing these topics up in the hash-forum list. I agree with many of the points you brought up. Cheers, Ron Rivest On 12/14/2008 3:18 PM, Bill Burr wrote: > > Bob, > > We're trying to listen to what everybody says, before forming NIST's > opinion about the relative importance of micro-controllers with limited > memory, versus 1001 other trade-offs. It's just too soon for us to do > that. > > In the end, we're going to want something that is a good substitute for > the SHA-2s in all of their major applications, but is significantly > better than SHA-2 in some significant respects. Unless the SHA-2s be > "significantly" broken it's going to be very hard to force products to > change to SHA-3, or even implement SHA-3, if SHA-3 has few significant > practical advantages. > > To steal a phrase from Bruce Schneier's talk at the final AES > conference, we're probably going to pick a SHA-3 that doesn't "suck at > anything," or at least anything apparently very significant. And to > pick a SHA-3 that is better than SHA-2 at several things. I think we > did about that when we selected Rijndael to be the AES, although TDES > was easier to improve on than the SHA2's are. The SHA-2s, I think, set a > reasonably high bar. It's worth remembering, in this respect, however, > that TDES is not without its virtues: it's pretty efficient in hardware. > I'll point one other related trade-off I think I see here. The SHA-2s > give us two different pipe widths. Is it better to do this, or have one > compromise pipe width for all 4 output sizes, that perhaps is a little > narrower than ideal for the 512-bit output? > At this point it's not clear to me (as distinct from the rest of the > folks in my group, who I haven't discussed this with very much at this > point) that we often ask low-end micro controllers to generate > collision free hashes. I suppose that there will always be applications > for low end processors with very little RAM, but will those often > require collision free hashes? And we seem to get more and more > powerful processors with more and more memory into smaller and smaller > packages. It also seems to me that there are more efficient ways to > address MACs in micro controllers, than HMAC. So, if HMAC be the main > application for hash functions in micro controllers, then maybe low end > micro controllers would not be a major concern for SHA-3. But I remain > open to arguments to the contrary. And I'm pretty sure we'll wind up > with several second round candidate algorithms with narrow-pipe designs, > as well as several wider pipe designs. > > Regards, > > Bill Burr > > > > > > Bob Hattersley wrote: >> A somewhat intemperate post perhaps, but there's an interesting >> question in >> there. Waterfall would be a 6x design in this classification and >> therefore >> a "monster". (Since I have no desire to make anyone ill, I recommend >> that >> sensitive souls should avoid any further contact with it.) I worked >> under >> the (possibly invalid) assumption that 512 bytes of RAM (and 2kB of >> program >> storage) was a reasonable target. 1kB RAM seems to be widely used today, >> and memory doesn't seem to be getting more expensive. Most >> microcontrollers >> are not used in situations where cryptography has any relevance. >> >> But what is the general opinion? Perhaps more important - what is NIST's >> view? >> >> Bob Hattersley (Waterfall) >> >> -----Original Message----- >> From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Sean >> O'Neil >> Sent: 13 December 2008 06:27 >> To: Multiple recipients of list >> Subject: Narrow-pipe designs >> >> >> A number of people are asking a good question: >> >> Can someone please publish a paper listing all the narrow-pipe hashes as >> broken by design, so we could all focus on the good ones with 2x and >> slightly larger states? >> >> <2x is vulnerable by design, >=2x up to 2.5x (or possibly up to 3x) is >> the >> optimal choice, but all the >=4x monsters and some of the designs such as >> Crunch or FSB with their reference code requiring MEGABYTES (!!!) of >> tables >> to function are certainly gone too far. With all due respect to their >> authors, I wouldn't bother looking at those as >> a total waste of time. >> >> Personally, the hash functions with 4x and larger states make me wanna >> puke, >> but technically, they would simply never fit in 128 or >> 256 bytes of RAM of the [yes, very] popular 8-bit microcontrollers >> that may >> want to use some of it for other purposes than merely storing the entire >> hash state with no room left for a single variable. >> >> Best regards, >> Sean O'Neil >> http://www.enrupt.com/ - Raising the bar. >> >> >> >> > -- Ronald L. Rivest Room 32-G692, Stata Center, MIT, Cambridge MA 02139 Tel 617-253-5880, Email From hash-forum@nist.gov Mon Dec 15 09:51:11 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBFHp30F008935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 09:51:05 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBFHn7mx016855; Mon, 15 Dec 2008 12:49:17 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBFHlbHi026367; Mon, 15 Dec 2008 12:47:37 -0500 Date: Mon, 15 Dec 2008 12:47:37 -0500 Message-Id: <494696CD.2070803@mit.edu> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Ronald L. Rivest" To: Multiple recipients of list Subject: Scaling laws, and power usage X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: <5574ACE4ACD88E45A7026FA0E350334B039F53@cleopatra.spyrus.com> References: <77E8A818-5279-4A62-B253-0FECF60F4596@cryptolib.com> <79B77C4C1E604E45967DBEA02EF6ED94@BobsDell> <4945676C.3050307@nist.gov> <4945E48D.2080407@mit.edu> <5574ACE4ACD88E45A7026FA0E350334B039F53@cleopatra.spyrus.com> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 09:51:06 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 369 Hi Bob -- Good comments! With respect to scaling however, my understanding is that scaling *can* improve power usage. If you decrease dimensions by a factor of two in both x and y dimensions, then all capacitances decrease by a factor of four, and power usage improves, since it takes less current to change the state of a capacitor. This is assuming you don't also change the clock rate or voltage. If you increase the frequency by a factor of four, you get the same current draw, but to increase frequency you need to increase voltage inside the chip to get things to happen faster. So power usage tends to go up. Scaling is complicated, but the increased freedom of using smaller features on a chip can yield improved power usage, if you don't muck with the clock rate and/or voltage at the same time... (The above analysis is quite simplistic and naive; for the truth someone with stronger VLSI expertise should advise us...) Cheers, Ron On 12/15/2008 12:19 PM, Robert Jueneman wrote: > Ron and Bill, > > I don't have a dog in this fight, but I'd like to comment on the size > issue, since SPYRUS is involved in both the low-cost, low-power, > bandwidth-constrained smartcard end of the spectrum and the relatively > unconstrained HSM and/or host-based processing system at the other. > > For interoperability, it is essential that we have an efficient > algorithm that can run in both spaces. > > I also agree with the need for multi-purpose algorithms -- we were the > first and perhaps still one of the few organizations to use HASH_DRBG > from SP 800-90 for random number generation. (Somehow, using AES to > generate keys to be used for AES seemed like putting too many eggs in > one basket, especially when you think about SPA and DPA attacks.) > > With regard to hashing vs. digital signatures on a chip, the issue is > more likely going to be bandwidth rather than processing power, as smart > cards normally support only the IOS 7816 interface -- maybe 100 kbps at > best. Our smart cards have no difficultly computing ECDSA, EC-DH, and > ECMQV for P-256, P-384, and P-521, and the code size constraint isn't > much of a limitation -- the code will fit comfortably into ROM or > EEPROM, as required. But don't expect it to be done in a millisecond. > > In that regard, it is important to remember that although Moore's Law > predicts ever-increasing transistor density, and that generally > translates into increased speed and what I will call agility > (parallelism, redundant implementations, etc.), there is one thing that > Moore's law does NOT provide, and that is the increased power required > to operate these devices. I'm certainly not a semi-conductor physicist, > but I don't recall reading anything about reducing the power required to > flip a bit in a transistor. And the faster you want to do that, the > more electrical power it takes. > > So when you start talking about nano-processors, that is likely to be > the limiting factor. And where that shows up in today's market is with > respect very low cost, very low power RFID chips. > > In that market, I expect that a keyed hash will continue to be very > important as an alternative to the slower digital signatures of > comparable strength. Maybe not HMAC -- no disrespect to Hugo, but I > would like to see a keyed MAC algorithm devised that is less > computationally intensive -- but surely something along those lines. > > On the other hand, if we aren't talking about creating hashes and > digital signatures that will be sufficiently robust to resist > cryptanalytic attacks for hundreds of years or more, but only need to > survive a couple of years against modest attacker resources, then a > 512-bit algorithm may be overkill, and 128-bits may even be sufficient. > > I guess I'm arguing for algorithms with "knobs" that can be used to > easily tune the performance characteristics as required, while still > providing interoperability. > > Regards, > > Bob > > Robert R. Jueneman > Chief Scientist > SPYYRUS, Inc. > > -----Original Message----- > From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of > Ronald L. Rivest > Sent: Sunday, December 14, 2008 9:07 PM > To: Multiple recipients of list > Subject: Thoughts on SHA-3 potential applications, esp. for small > devices (LONG) > > > Hi Bill -- > > I appreciate your thoughtful essays... > > There are indeed a lot of dimensions and tradeoffs to > consider for the SHA-3 competition. > > If we think about why one wants a hash standard, four > reasons come to mind (in no particular order): > > (1) A standard promotes and facilitates _interoperability_ > between products produced by different organizations. > > (2) A standard will have been thoroughly evaluated for > cryptographic strength. > > (3) A standard will be accompanied by a multitude of > well-engineered and tested implementations for various > platforms. > > (4) A standard, by being a standard, facilitates decision-making > by organizations that are too risk-averse and non-technical > to make a decision in the absence of a standard. > > For a hash function, I suspect that the main use for interoperability > between products of different organizations will probably continue > to be as a component of digital signatures. > > I do wonder, as you do, what the real needs will be for cryptographic > primitives on various platforms, as time goes forward. The future, > as usual, is not always predictable. > > The needs of very small devices are perhaps the most interesting > question to consider. > > Devices that are already sufficiently powerful to compute public-key > digital signatures are presumably going to be big enough to easily > accommodate any sort of reasonable hash function as well. > > I think that devices that are too small to perform a public-key > digital signature will frequently nonetheless have a requirement > to authenticate themselves---to perform a MAC. (As you said.) > > But the requirements for MAC's are different (and in many ways > simpler) than those for hash functions. We care about forgery > rather than collision resistance, MAC outputs can be shorter than > hash function outputs, etc. I feel it would be a bit strange to > let the hash function competition be driven by the expectation > that, for small devices, there is a need to utilize the SHA-3 > hash function to produce MAC's. > > If the world is going to be filled up with tiny devices that > need to authenticate themselves, then there is a clear need for > an appropriate MAC standard. The SHA-3 competition was not set up > to produce such a standard; it merely noted that suitability for > use in HMAC was a SHA-3 requirement. It would probably be a > mistake for the world to conclude that NIST feels that all small > devices should be using HMAC as an authentication technology, > when there are likely to be much better alternatives for small > devices. (Perhaps down the road NIST would enjoy running a > "nano-MAC" standards competition!) > > I also suspect that in the world of very small devices, almost > all system designs will be proprietary and closed. Think for > example of mass transit card systems or building access cards. > There is no need for small devices in these systems to work > "outside the system". The need for interoperability through > an open standard is not wanted (indeed, it may be very much > undesired). Thus, for very small devices the need for a standard > in order to support interoperability may be small or absent. > > Of course, there may be exceptions, and who knows what future > systems will need. > > But I find it hard to think of applications for hashing for > very small devices where: > -- the device is too small for public-key operations > -- the hash function is not being used for a MAC > > To see why, note that abstractly, a hash value is often used as > a "proxy" for the value being hashed. Its shorter length may be > better suited for computation (as for a digital signature) or > for communication (e.g. for the hash of a message being transmitted > by a different channel, or at a different time). > > But very small devices don't have more than one communication channel, > and they don't have much storage, so applications that send a hash > value from a small device, so that it can later send the real message, > seem dubious (it requires storage). Applications that send the hash > so that the real message can be sent via another channel may also be > rare, since the device doesn't have more than one channel. > > It isn't very clear to me what utility a "hash value as a proxy > for a message" philosophy has for very small devices. > > Finally, a hash value can be appended to a message for transmission, > but if one merely wants redundancy it can be done in better ways. > (Keyed redundancy is different, but that is what a MAC gives.) > > I suspect that the world will indeed be filled with lots of > fascinating small electronic devices, but I think that if they > do crypto, it will almost certainly be MAC's or digital signatures. > It is unlikely to be unkeyed hash function application. > > Perhaps I've overlooked something important, but I'm far from > persuaded that the SHA-3 standard will be very relevant for > very small devices, until you get up to size where the device > is capable of performing public-key digital signatures. Then > it will become relevant. But at that point, we've got fairly > substantial resources already devoted to doing crypto, and one > should be considering the digital signature operation as a whole; > the hash function implementation may be a small piece of that whole. > > And of course, Moore's Law hasn't quite died yet, and transistors > continue to shrink. For small devices, at some point the cost of > bonding and packaging them should greatly exceed the cost of > producing the chip. (Perhaps we are there already...) > > Perhaps others on this list have thoughts on how SHA-3 might > be useful on very small devices... > > These are good discussions to have, and I appreciate your > bringing these topics up in the hash-forum list. I agree > with many of the points you brought up. > > > Cheers, > Ron Rivest > > > On 12/14/2008 3:18 PM, Bill Burr wrote: >> Bob, >> >> We're trying to listen to what everybody says, before forming NIST's >> opinion about the relative importance of micro-controllers with > limited >> memory, versus 1001 other trade-offs. It's just too soon for us to do > >> that. >> >> In the end, we're going to want something that is a good substitute > for >> the SHA-2s in all of their major applications, but is significantly >> better than SHA-2 in some significant respects. Unless the SHA-2s be >> "significantly" broken it's going to be very hard to force products to > >> change to SHA-3, or even implement SHA-3, if SHA-3 has few significant > >> practical advantages. >> >> To steal a phrase from Bruce Schneier's talk at the final AES >> conference, we're probably going to pick a SHA-3 that doesn't "suck at > >> anything," or at least anything apparently very significant. And to >> pick a SHA-3 that is better than SHA-2 at several things. I think we >> did about that when we selected Rijndael to be the AES, although TDES >> was easier to improve on than the SHA2's are. The SHA-2s, I think, set > a >> reasonably high bar. It's worth remembering, in this respect, > however, >> that TDES is not without its virtues: it's pretty efficient in > hardware. >> I'll point one other related trade-off I think I see here. The SHA-2s > >> give us two different pipe widths. Is it better to do this, or have > one >> compromise pipe width for all 4 output sizes, that perhaps is a little > >> narrower than ideal for the 512-bit output? >> At this point it's not clear to me (as distinct from the rest of the >> folks in my group, who I haven't discussed this with very much at this > >> point) that we often ask low-end micro controllers to generate >> collision free hashes. I suppose that there will always be > applications >> for low end processors with very little RAM, but will those often >> require collision free hashes? And we seem to get more and more >> powerful processors with more and more memory into smaller and smaller > >> packages. It also seems to me that there are more efficient ways to >> address MACs in micro controllers, than HMAC. So, if HMAC be the main > >> application for hash functions in micro controllers, then maybe low > end >> micro controllers would not be a major concern for SHA-3. But I > remain >> open to arguments to the contrary. And I'm pretty sure we'll wind up >> with several second round candidate algorithms with narrow-pipe > designs, >> as well as several wider pipe designs. >> >> Regards, >> >> Bill Burr >> >> >> >> >> >> Bob Hattersley wrote: >>> A somewhat intemperate post perhaps, but there's an interesting >>> question in >>> there. Waterfall would be a 6x design in this classification and >>> therefore >>> a "monster". (Since I have no desire to make anyone ill, I recommend > >>> that >>> sensitive souls should avoid any further contact with it.) I worked >>> under >>> the (possibly invalid) assumption that 512 bytes of RAM (and 2kB of >>> program >>> storage) was a reasonable target. 1kB RAM seems to be widely used > today, >>> and memory doesn't seem to be getting more expensive. Most >>> microcontrollers >>> are not used in situations where cryptography has any relevance. >>> >>> But what is the general opinion? Perhaps more important - what is > NIST's >>> view? >>> >>> Bob Hattersley (Waterfall) >>> >>> -----Original Message----- >>> From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of > Sean >>> O'Neil >>> Sent: 13 December 2008 06:27 >>> To: Multiple recipients of list >>> Subject: Narrow-pipe designs >>> >>> >>> A number of people are asking a good question: >>> >>> Can someone please publish a paper listing all the narrow-pipe hashes > as >>> broken by design, so we could all focus on the good ones with 2x and >>> slightly larger states? >>> >>> <2x is vulnerable by design, >=2x up to 2.5x (or possibly up to 3x) > is >>> the >>> optimal choice, but all the >=4x monsters and some of the designs > such as >>> Crunch or FSB with their reference code requiring MEGABYTES (!!!) of >>> tables >>> to function are certainly gone too far. With all due respect to > their >>> authors, I wouldn't bother looking at those as >>> a total waste of time. >>> >>> Personally, the hash functions with 4x and larger states make me > wanna >>> puke, >>> but technically, they would simply never fit in 128 or >>> 256 bytes of RAM of the [yes, very] popular 8-bit microcontrollers >>> that may >>> want to use some of it for other purposes than merely storing the > entire >>> hash state with no room left for a single variable. >>> >>> Best regards, >>> Sean O'Neil >>> http://www.enrupt.com/ - Raising the bar. >>> >>> >>> >>> > -- Ronald L. Rivest Room 32-G692, Stata Center, MIT, Cambridge MA 02139 Tel 617-253-5880, Email From hash-forum@nist.gov Mon Dec 15 09:51:40 2008 Return-Path: Received: from stamps.cs.ucsb.edu (stamps.cs.ucsb.edu [128.111.41.14]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBFHdxGK006516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 15 Dec 2008 09:51:36 -0800 Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by stamps.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBFHZIBu012036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 09:35:20 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBFHY7Hm013855; Mon, 15 Dec 2008 12:34:14 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBFHXj1v031698; Mon, 15 Dec 2008 12:33:45 -0500 Date: Mon, 15 Dec 2008 12:33:45 -0500 Message-Id: <60667906-51C8-49A5-B143-89D82FB89EB5@mac.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Jeff Johnson To: Multiple recipients of list Subject: Re: ASN.1 oids for SHA-3 submissions and PKCS1 RSA signatures? X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.930.3) References: <051B5A02-38C0-4B65-9F66-D4F82BBAE10F@mac.com> Content-type: multipart/signed; boundary=Apple-Mail-95--200581952; micalg=sha1; protocol="application/pkcs7-signature" In-reply-to: X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 09:51:36 -0800 (PST) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (stamps.cs.ucsb.edu [128.111.41.14]); Mon, 15 Dec 2008 09:35:21 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on stamps X-Virus-Status: Clean X-Spam-Status: No, score=-4.2 required=5.0 tests=AWL,BAYES_00, MIME_HEADER_CTYPE_ONLY shortcircuit=no autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 370 --Apple-Mail-95--200581952 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Dec 15, 2008, at 12:20 PM, Paul Hoffman wrote: > > At 11:22 AM -0500 12/15/08, Jeff Johnson wrote: >> Could (and more generally should) ASN.1 oids be defined for >> the SHA-3 candidate submissions for use by PKCS1 RSA digital >> signature padding? >> >> Some private oid in the hierarchy will certainly suffice for my >> insanities. >> >> But perhaps a interim/temporary oid definition is better than >> littering an >> already arcane hash algorithm name space, since the final SHA-3 >> choices >> will take a year or more to identify. > > For what do you need even temporary OIDs? Why would you be using any > of the candidates in protocols before significant analysis has been > done on them? > Please note "insanities", and that any oid will "work" for my purposes. My usage cases atm are with RSA and smartcard development, not with analysis. Perhaps off-topic here ... But the politics of getting *some* OID defined in implementations are glacially slow afaict. I merely attempted to suggest that an early, preemptive, conventional definition of ASN.1 oids would improve rate of SHA-3 implementation adoption, not the quality of the analysis, or of the hashes themselves. 73 de Jeff --Apple-Mail-95--200581952 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuDCCBLUw ggQeoAMCAQICDwCkcgABAAK4E2vcIBaxtDANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQGEwJERTEc MBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RDZW50ZXIgQ2xh c3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBMMSBDQSBWSTAeFw0w ODEyMDIxMzU0MDVaFw0wOTEyMDMxMzU0MDVaMEIxCzAJBgNVBAYTAlVTMRUwEwYDVQQDEwxKZWZm IEpvaG5zb24xHDAaBgkqhkiG9w0BCQEWDW4zbnBxQG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDSrLrIMdg0i0KwjX6UOio7t8uErnKtkxSheOOd/colSfjfIvmE9RpefvAY 9frPMhGNMv4UiwwFV8WE3zm5aSz1hdkjTykpfhVTHUOUA8wJYIrLqP7T/sV/BgYUqbTFlTFp+eIh 0H5JBTVTvLwpurS5UrcTqMcmx8+kKKF0uPnLdUlBGfCDC9CImlRPhWIEs9+B1dPdPpKhuJFmpLCV Tp+4ugEqNVGuADz9huUxhw/jUm4bEibt0hMsZoNgB2lSASGCk7qbGqMcU36744rnV4ee6VV6p8Zz QtUgELId6gBTTgFn2z5P2HiB45kOPvzJkA73E5Wce/aqDNNGGaVN0LrFAgMBAAGjggHtMIIB6TCB lwYIKwYBBQUHAQEEgYowgYcwUQYIKwYBBQUHMAKGRWh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUv Y2VydHNlcnZpY2VzL2NhY2VydHMvdGNfY2xhc3MxX0wxX0NBX1ZJLmNydDAyBggrBgEFBQcwAYYm aHR0cDovL29jc3AuVkkudGNjbGFzczEudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUTpv1svvd amvcSgevybtk/xZLJp8wDAYDVR0TAQH/BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAG CCsGAQUFBwIBFiRodHRwOi8vd3d3LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/ BAQDAgTwMB0GA1UdDgQWBBS6REy96I26Zac5uz2NN06zJmQ/pTBUBgNVHR8ETTBLMEmgR6BFhkNo dHRwOi8vY3JsLlZJLnRjY2xhc3MxLnRydXN0Y2VudGVyLmRlL2NybC92Mi90Y19jbGFzczFfTDFf Q0FfVkkuY3JsMDMGA1UdJQQsMCoGCCsGAQUFBwMCBggrBgEFBQcDBAYIKwYBBQUHAwcGCisGAQQB gjcUAgIwGAYDVR0RBBEwD4ENbjNucHFAbWFjLmNvbTANBgkqhkiG9w0BAQUFAAOBgQBj7zOyIzVA K053Y937PH4zbUqgMvPU3YkGfZlkc+au4x8diMZPTTO9ry+xg5ljQ9oXtxjow6V0KDqM04zwF48P bYB43UiRI0YcPyYcTl6qP/jvNmMiisQqLTdsdWArePWLfKjMVyCPpcqVn89uYh5n2v0H5YrSrlbV 19ofNK1I0zCCBM8wggQ4oAMCAQICDwCUsAABAAJijbUfbuxyZDANBgkqhkiG9w0BAQUFADCBvDEL MAkGA1UEBhMCREUxEDAOBgNVBAgTB0hhbWJ1cmcxEDAOBgNVBAcTB0hhbWJ1cmcxOjA4BgNVBAoT MVRDIFRydXN0Q2VudGVyIGZvciBTZWN1cml0eSBpbiBEYXRhIE5ldHdvcmtzIEdtYkgxIjAgBgNV BAsTGVRDIFRydXN0Q2VudGVyIENsYXNzIDEgQ0ExKTAnBgkqhkiG9w0BCQEWGmNlcnRpZmljYXRl QHRydXN0Y2VudGVyLmRlMB4XDTA4MDcxODExMzg1NFoXDTEwMTIzMTIyNTk1OVowfDELMAkGA1UE BhMCREUxHDAaBgNVBAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2Vu dGVyIENsYXNzIDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0Eg VkkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJQFP39OlsR+FrO6sIC5tx+k3aTjsL4oCLrs rd2Z9nVMzrHxnvShlmxLhgElFThIoRzo7gr1mZbx2/Gu3X51SEBNTkP3bV2U0jn9yxGo97oYWA/+ cRUKEEsxfvbPX5DL992EupcEptQAVutm32so3dGi+nqe2mFXwx8wpDAnCkDRAgMBAAGjggIQMIIC DDCBjgYIKwYBBQUHAQEEgYEwfzBMBggrBgEFBQcwAoZAaHR0cDovL3d3dy50cnVzdGNlbnRlci5k ZS9jZXJ0c2VydmljZXMvY2FjZXJ0cy90Y19jbGFzc18xX2NhLmNydDAvBggrBgEFBQcwAYYjaHR0 cDovL29jc3AudGNjbGFzczEudHJ1c3RjZW50ZXIuZGUwDwYDVR0TAQH/BAUwAwEB/zBKBgNVHSAE QzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3LnRydXN0Y2VudGVyLmRl L2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgGGMB0GA1UdDgQWBBROm/Wy+91qa9xKB6/Ju2T/Fksm nzCB7AYDVR0fBIHkMIHhMIHeoIHboIHYhjtodHRwOi8vY3JsLnRjY2xhc3MxLnRydXN0Y2VudGVy LmRlL2NybC92Mi90Y19jbGFzc18xX2NhLmNybIaBmGxkYXA6Ly93d3cudHJ1c3RjZW50ZXIuZGUv Q049VEMlMjBUcnVzdENlbnRlciUyMENsYXNzJTIwMSUyMENBLE89VEMlMjBUcnVzdENlbnRlciUy MEFHLG91PXJvb3RjZXJ0cyxkYz10cnVzdGNlbnRlcixkYz1kZT9jZXJ0aWZpY2F0ZVJldm9jYXRp b25MaXN0P2Jhc2U/MA0GCSqGSIb3DQEBBQUAA4GBAG4ApLln3RLqDiymjdk8SFs8S6acQryrkZB/ DJ2QH6n+6LYqEjirh+/Zj8uweQL6p6d9g/dl4S1wpIGCVC33AdcM8qer/Cn0qcQ6bdduesfTcdQv 5uZlSsyEdKNa44DVtOh3IkTLtFdcDiY4tQFriM7kVC5Xuhyfxo58V1vOM8r+MIIFKDCCAxCgAwIB AgIDA+KXMA0GCSqGSIb3DQEBBQUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA3MDgwNjE2MDkyN1oXDTA5MDgwNTE2 MDkyN1owODEYMBYGA1UEAxMPQ0FjZXJ0IFdvVCBVc2VyMRwwGgYJKoZIhvcNAQkBFg1uM25wcUBt YWMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsQPDTZmNHMe8kH5hFgRyhXFD kD9qKPH01fz64dCN2PyRLj2Azgry3JBbbTSi5Tflm7V79ACnFevJ7fNIssewbdFnt9j2a6LXvD1G bKuzRqfZjgQAE16gYzlo39HZlS8srogeZk9jWTtpFrBr2BanIlimgLsMRlMJ5ikWp4CD9rTWn1fK Olr9l+UOIxhBlHGSlFc6nxFfH9kbcklxY6Qm3M8fWvuC41rRxxiAQegOmtzHGxNLk/fSQkgNzW+w EphZX3gTHajsKBlWlQvf4Ju0hYSLhiF6D2QJQUiXHBnpREqwvem2QWSJu0foCCpR8a2j81jZVuJy 4RO5OqwXdBpwTQIDAQABo4H5MIH2MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdl dCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5D QWNlcnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29j c3AuY2FjZXJ0Lm9yZzAYBgNVHREEETAPgQ1uM25wcUBtYWMuY29tMA0GCSqGSIb3DQEBBQUAA4IC AQCDQm1D9xoQMqNHySTk0yvn7IFg5uiBP5RrZAtD7g3Kb8vJ36snaYrGrLXorQQn3BzVAzkWXHE0 NaM5eLyNTxerG88XU0BCPQD/mqA0B/857tuO5TDYo9JatC276m4hAOxIcgPOuwjyFHkpZ1DMbWNG a5WyiqNynRJ6m4RHj3Ix5xZkM50p5cFn9CLArkyeWsgagVzVYpPk0GuAUiZoE+hAW7oS/OeH7xCI F6IlztL/GeV8sbit9eUlw0C0aJMXdAcnE9Q/udCdGWPDBF15NAbwARBKr8cbyAoNvxptsQ0h9M+1 W6Q0suoPUULWyueGDgzm/6V9Yktf9QyF72dEiiwJ+as/DXfNR4a7kjpV5aFcirwUWMZDXCEAqM3f fYhpvCme+rM3w9UlN4oGi53Odcdm321XhsFdiS3EytB44ny3gsyt7c8XUbcRxIfdSP542xROhUYC JTPYejMUcu29ntVSm/oLPn4TwWPNmxN5wOwypOvK6//X2NpHTDzybrIj6eseu+m3Sy+yDcLDKIkS 7V9RxNvaN+bgom7NHWZyzUNlluznoWqRAIBUoAUdcSQsN9/cNtxJ9rpDhm3RQN5DgkAXKUgC+wXz /jR7vRlcD1qXn/RYzKJUQG6PaVGLl77vtQf1amPrTpSZJ+yBLmnBisguuQ0rKGEKPUYPCCg+3tgD TzGCA0IwggM+AgEBMIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBH bWJIMSUwIwYDVQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBU cnVzdENlbnRlciBDbGFzcyAxIEwxIENBIFZJAg8ApHIAAQACuBNr3CAWsbQwCQYFKw4DAhoFAKCC AYcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgxMjE1MTczMDA1 WjAjBgkqhkiG9w0BCQQxFgQUw58YzJDeYq1yL+sIO0kbjBRylWkwgZEGCSsGAQQBgjcQBDGBgzCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAg BgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRA Y2FjZXJ0Lm9yZwIDA+KXMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENB MR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDA+KXMA0GCSqG SIb3DQEBAQUABIIBAJ68yAkniN5jCSOq02H++VDLLDYbsbBY+XQJco343egJHEkadzARZPUQHpI3 su5gbl24EIpoaLPfMr5aXNf8Bcl6i2fNTgCHBGJAFlM2J3JZXMMY6VhXioxuyvh1AkddJ87lhaIp Us4XTi78duumu8GQ7v4NeNWea4l2ObfRduPsfNTJJ2eSH5xRUpeCjlhWFf7tjH7iuyrwm+fvPHEc 8ShkLuFpLvmKcaJQ+UFi1vx++ChG41Lld8s2AMDa9WeQLquO3sHtTl9ZPfnMj6zeQ+hOOJ1PWF4A kYaqZlVRdDWRzMK3+zWeiZ9+09hbtoDWY5u/yXQLiQDhkGTwQKM2vIEAAAAAAAA= --Apple-Mail-95--200581952-- From hash-forum@NIST.GOV Mon Dec 15 10:47:10 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBFIl328018512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 10:47:05 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBFIjB11021644; Mon, 15 Dec 2008 13:45:20 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBFIj0BD013182; Mon, 15 Dec 2008 13:45:00 -0500 Date: Mon, 15 Dec 2008 13:45:00 -0500 Message-Id: <888E37A2001E364CBC4F28FA7660A2E65E26A6582B@NA-EXMSG-C102.redmond.corp.microsoft.com> Errors-To: sara@NIST.GOV Reply-To: hash-forum@NIST.GOV Originator: hash-forum@nist.gov Sender: hash-forum@NIST.GOV Precedence: bulk From: Niels Ferguson To: Multiple recipients of list Subject: RE: Engineering comparison of the SHA-3 candidates X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" In-Reply-To: <20081215100903.52177.qmail@cr.yp.to> References: <888E37A2001E364CBC4F28FA7660A2E65E26A65825@NA-EXMSG-C102.redmond.corp.microsoft.com>,<20081215100903.52177.qmail@cr.yp.to> X-To: "hash-forum@nist.gov" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 10:47:06 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 371 Hi Dan, Nice to hear from you. I think we disagree on the intention of the recommended parameter values that NIST asked for. We interpreted that as NIST asking the designers to put a stake in the ground and say: This is a particular function that we believe is both secure and fast enough to make a good standard. I believe this is a very important requirement as it allows reasonable comparisons of algorithms without having to do in-depth cryptanalysis of each of the 51 candidates. Your recommended parameters for CubeHash make a particular choice in the speed/security trade-off, which is what I used in our table. If you want to update your recomended parameter choices I would love to hear them. In the AES contest NIST allowed minor tweaks to the algorithm in round 2, and I expect changes like this to be certainly considered minor tweaks. I also have to disagree on your claim that performance is not important for most applications. Part of my job here is to review the usage of cryptography in Microsoft products and to provide recommendations. We encounter quite a bit of resistance when we ask people to switch from SHA-1 to SHA-256, and for a good fraction of the cases the performance loss is a problem. A lot of applications and protocols were designed in the MD4/MD5 era when hashing was increadibly cheap. Changing the algorithm to a new hash function can already be quite involved; changing the application or protocol to use different primitives (e.g. MAC) can require major re-engineering of the whole product, which is too expensive. One of the primary reasons why people use HMAC is that it is a FIPS-approved MAC algorithms. There are faster MAC algorithms in the literature, but if you can't get FIPS-approval then you can't sell your product to a significant number of big customers, so everybody choses the 'safe' route and uses FIPS-approved algorithms where possible. Cheers! Niels ________________________________________ From: hash-forum@nist.gov [hash-forum@nist.gov] On Behalf Of D. J. Bernstein [djb@cr.yp.to] Sent: Monday, December 15, 2008 2:03 AM To: Multiple recipients of list Subject: Re: Engineering comparison of the SHA-3 candidates Niels Ferguson writes: > We used the recommended parameter sets for each algorithm. Then you're ignoring the rules of the SHA-3 competition. Here's what NIST said in the SHA-3 submission requirements: The submitted algorithm may include a tunable security parameter, such as the number of rounds, which would allow the selection of a range of possible security/performance tradeoffs. ... The tunable parameter may be used to produce weakened versions of the submitted algorithm for analysis, and permit NIST to select a different security/performance tradeoff than originally specified by the submitter. You've been misrepresenting this "range of possible security/performance tradeoffs" by compressing the range to a single recommended point for each submission. For example, your table includes only CubeHash8/1 (incorrectly labelled "CubeHash"), and ignores all of the other members of the CubeHash family. You should expand the table to accurately report the entire range of security/performance tradeoffs submitted to NIST. > It is one thing to change speed/security tradeoff by a few tens of > percent; changing it by several orders of magnitude is very different. I agree that it's very different. Your method of misrepresenting the submissions has a relatively small effect on aggressively designed submissions with small security margins and limited ranges of tunable security parameters; it has a much larger effect on conservatively designed submissions. > If you believe that CubeHash should be used with different parameters > I believe you should have put that in the submission Perhaps you should read the submission! It already includes reference implementations and test vectors for 28 different choices of the tunable security parameter r/b: * Most conservative: CubeHash8/1. * ~2x faster: CubeHash8/2, CubeHash4/1. * ~4x faster: CubeHash8/4, CubeHash4/2, CubeHash2/1. * ~8x faster: CubeHash8/8, CubeHash4/4, CubeHash2/2, CubeHash1/1. * ~16x faster: CubeHash8/16, CubeHash4/8, CubeHash2/4, CubeHash1/2. * ~32x faster: CubeHash8/32, CubeHash4/16, CubeHash2/8, CubeHash1/4. * ~64x faster: CubeHash8/64, CubeHash4/32, CubeHash2/16, CubeHash1/8. * ~128x faster: CubeHash4/64, CubeHash2/32, CubeHash1/16. * ~256x faster: CubeHash2/64, CubeHash1/32. * ~512x faster: CubeHash1/64. I haven't written optimized code for (e.g) CubeHash2/16 yet, but I'm sure that it will be faster than Skein-512 on the reference platform. Calling it "too slow" is silly. Of course, you're free to argue that CubeHash2/16 is worse than Skein-512 for some other reason. As for how CubeHash "should be used," here's what the submission says: Parameter recommendations. I recommend CubeHash8/1-224, CubeHash8/1-256, CubeHash8/1-384, and CubeHash8/1-512; i.e., r=8 and b=1, independent of the message-digest size. ... Justification for recommending CubeHash8/1: For most applications of hash functions, speed simply doesn't matter. High-volume network protection with HMAC is sometimes cited as an exception, but anyone who really cares about speed shouldn't be using HMAC anyway; other MACs are faster and inspire more confidence. What about the occasional applications where hashing speed _does_ matter? If, after third-party cryptanalysis, the community is convinced that much faster CubeHashr/b choices are perfectly safe, then I expect those choices to be considered in speed-oriented applications. For the same reason, I expect NIST to scientifically compare the speeds of different hash-function families by comparing the speeds of the fastest unbroken members of those families---rather than biasing the comparison according to the speculative initial recommendations of the hash-function designers. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago From hash-forum@nist.gov Mon Dec 15 10:47:14 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBFIl6YE018525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 10:47:08 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBFIinfx025535; Mon, 15 Dec 2008 13:44:54 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBFIhXto010549; Mon, 15 Dec 2008 13:43:33 -0500 Date: Mon, 15 Dec 2008 13:43:33 -0500 Message-Id: <2a9a3e6a0812151036p1e44befj5aa92ae5a433ed2b@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Chen Ke-Fei Lin" To: Multiple recipients of list Subject: Re: Thoughts on SHA-3 potential applications, esp. for small devices (LONG) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <20081215073634.GA28920@titan.cry.pto> <470029.8374.qm@web36405.mail.mud.yahoo.com> <2a9a3e6a0812150730v573a9474l2f2b04be0b18a51b@mail.gmail.com> Content-Type: multipart/alternative; boundary="----=_Part_33648_15413364.1229366170091" MIME-Version: 1.0 In-Reply-To: X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 10:47:09 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 372 ------=_Part_33648_15413364.1229366170091 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, Dec 15, 2008 at 5:22 PM, Thomas Dixon wrote: > "It is incorrect to call EnRUPT or EnRUPT/s broken in general as there > is no structural flaw exploited in the recent collision attack. Only > EnRUPT/4 is broken so far. After a detailed study of this attack, we > can recommend the following variants: > > EnRUPT64x2-224/8, /s/=H=8 > EnRUPT64x2-256/8, /s/=H=8 > EnRUPT64x2-384/12, /s/=H=12 > EnRUPT64x2-512/16, /s/=H=16" > > Regards, > Tom On Mon, Dec 15, 2008 at 5:37 PM, Sean O'Neil wrote: > > Dear Chen, > I must insist yet again that 'it' meaning 'EnRUPT' is *not* broken, only > 'EnRUPT64x2/4' variant that uses 8 rounds between inputs is (and so far only > vulnerable to collision searches, not preimage attacks). EnRUPT was > submitted with a tunable speed/performance parameter and it is currently > advised to cryptanalyse s=H variants, not s=4. Just like it is incorrect to > call CubeHash broken in general just because one of its low-round variants > is. > Hi Tom, Peter, Sean, Zoooko, ..., I am sorry to call EnRUPT broken - but SHA-3 Zoo call EnRUPT broken. In your documentation you say - "Security parameter, s>=4 is recommended." So s=4 is one your recommended parameters. But now you say: UUUPS, it is broken. No, my recommended parameter is also s=8, s=12, ..... For me your recommendation is "NOT PRECISE". Maybe s=8 is secure, but I don't have many trust now in EnRUPT. NIST wanted ONE recomended parameter, not INFINITE many recommended parameter. INFINITE many paremeters = unbreakable moving target proposal = useless hash C. K. F. Lin ------=_Part_33648_15413364.1229366170091 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, Dec 15, 2008 at 5:22 PM, Thomas Dixon <reikon@reikon.us> wrote:
"It is incorrect to call EnRUPT or EnRUPT/s broken in general as there
is no structural flaw exploited in the recent collision attack. Only
EnRUPT/4 is broken so far. After a detailed study of this attack, we
can recommend the following variants:

EnRUPT64x2-224/8, /s/=H=8
EnRUPT64x2-256/8, /s/=H=8
EnRUPT64x2-384/12, /s/=H=12
EnRUPT64x2-512/16, /s/=H=16"

Regards,
Tom
 
On Mon, Dec 15, 2008 at 5:37 PM, Sean O'Neil <sean@cryptolib.com> wrote:

Dear Chen,
I must insist yet again that 'it' meaning 'EnRUPT' is *not* broken, only 'EnRUPT64x2/4' variant that uses 8 rounds between inputs is (and so far only vulnerable to collision searches, not preimage attacks). EnRUPT was submitted with a tunable speed/performance parameter and it is currently advised to cryptanalyse s=H variants, not s=4. Just like it is incorrect to call CubeHash broken in general just because one of its low-round variants is.




Hi Tom, Peter, Sean, Zoooko, ...,

I am sorry to call EnRUPT broken - but SHA-3 Zoo call EnRUPT broken.

In your documentation you say - "Security parameter, s>=4 is recommended."
So s=4 is one your recommended parameters.

But now you say: UUUPS, it is broken. No, my recommended parameter is also s=8, s=12, .....
For me your recommendation is "NOT PRECISE". Maybe s=8 is secure, but I don't have
many trust now in EnRUPT.

NIST wanted ONE recomended parameter, not INFINITE many recommended
parameter.

INFINITE many paremeters = unbreakable moving target proposal = useless hash

C. K. F. Lin

------=_Part_33648_15413364.1229366170091-- From hash-forum@nist.gov Mon Dec 15 11:01:12 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBFJ13hB020878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 11:01:06 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBFIxIQZ001304; Mon, 15 Dec 2008 13:59:27 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBFIwcmi008789; Mon, 15 Dec 2008 13:58:38 -0500 Date: Mon, 15 Dec 2008 13:58:38 -0500 Message-Id: <4946A89E.4010908@nist.gov> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Bill Burr To: Multiple recipients of list Subject: Re: Scaling laws, and power usage X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: <494696CD.2070803@mit.edu> References: <77E8A818-5279-4A62-B253-0FECF60F4596@cryptolib.com> <79B77C4C1E604E45967DBEA02EF6ED94@BobsDell> <4945676C.3050307@nist.gov> <4945E48D.2080407@mit.edu> <5574ACE4ACD88E45A7026FA0E350334B039F53@cleopatra.spyrus.com> <494696CD.2070803@mit.edu> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 11:01:07 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 373 Ron & Bob, I don't claim any particular VLSI expertise, but my understanding is that transistors only consume much power when they are actually switching, that is P=I*V, and when a transistor is in the either the on or the off state, either I or V is close to zero. So when you crank up the clock you almost always increase poser consumption. Moreover you are charging and discharging capacitors more, and that means current is flowing, and current flowing tends to mean power is being consumed. Also smaller transistors generally means lower voltages, and smaller currents, while power is proportional to both V^2 and I^2. In principle I think you naturally reduce power consumption per computation as you shrink dimensions, but of course, you increase overall power consumption as you increase clock rates. Of course, as soon as you have to drive an external lead off the chip, you're back to dealing with higher voltages, and more current. We know that power consumption per unit of computation has gone down greatly as we've crammed more and more gates into less and less area. I just bought a little netbook with an Intel Atom processor. It has a 1.6 GHz clock, and burns very little power, yet it's surely computationally more powerful than the early Pentiums of not so long ago, which ran hot enough to fry eggs. Maybe reducing power consumption hasn't kept pace with the exponent of Moore's Law for semiconductors, but if power consumption is pretty much the limiting factor today, then our ability to limit power consumption (or to carry the heat away) must be largely the limiting factor in Moore's Law, at least if you think of Moore's law in terms of computing power per Dollar, I think. Regards, Bill Ronald L. Rivest wrote: > > Hi Bob -- > > Good comments! > > With respect to scaling however, my understanding is > that scaling *can* improve power usage. If you > decrease dimensions by a factor of two in both x and > y dimensions, then all capacitances decrease by a factor > of four, and power usage improves, since it takes less > current to change the state of a capacitor. This is > assuming you don't also change the clock rate or voltage. If > you increase the frequency by a factor of four, you get > the same current draw, but to increase frequency you > need to increase voltage inside the chip to get things > to happen faster. So power usage tends to go up. > Scaling is complicated, but the increased freedom of > using smaller features on a chip can yield improved > power usage, if you don't muck with the clock rate and/or > voltage at the same time... > > (The above analysis is quite simplistic and naive; for the > truth someone with stronger VLSI expertise should advise > us...) > > Cheers, > Ron > > On 12/15/2008 12:19 PM, Robert Jueneman wrote: >> Ron and Bill, >> >> I don't have a dog in this fight, but I'd like to comment on the size >> issue, since SPYRUS is involved in both the low-cost, low-power, >> bandwidth-constrained smartcard end of the spectrum and the relatively >> unconstrained HSM and/or host-based processing system at the other. >> >> For interoperability, it is essential that we have an efficient >> algorithm that can run in both spaces. >> >> I also agree with the need for multi-purpose algorithms -- we were the >> first and perhaps still one of the few organizations to use HASH_DRBG >> from SP 800-90 for random number generation. (Somehow, using AES to >> generate keys to be used for AES seemed like putting too many eggs in >> one basket, especially when you think about SPA and DPA attacks.) >> >> With regard to hashing vs. digital signatures on a chip, the issue is >> more likely going to be bandwidth rather than processing power, as smart >> cards normally support only the IOS 7816 interface -- maybe 100 kbps at >> best. Our smart cards have no difficultly computing ECDSA, EC-DH, and >> ECMQV for P-256, P-384, and P-521, and the code size constraint isn't >> much of a limitation -- the code will fit comfortably into ROM or >> EEPROM, as required. But don't expect it to be done in a millisecond. >> >> In that regard, it is important to remember that although Moore's Law >> predicts ever-increasing transistor density, and that generally >> translates into increased speed and what I will call agility >> (parallelism, redundant implementations, etc.), there is one thing that >> Moore's law does NOT provide, and that is the increased power required >> to operate these devices. I'm certainly not a semi-conductor physicist, >> but I don't recall reading anything about reducing the power required to >> flip a bit in a transistor. And the faster you want to do that, the >> more electrical power it takes. >> >> So when you start talking about nano-processors, that is likely to be >> the limiting factor. And where that shows up in today's market is with >> respect very low cost, very low power RFID chips. >> >> In that market, I expect that a keyed hash will continue to be very >> important as an alternative to the slower digital signatures of >> comparable strength. Maybe not HMAC -- no disrespect to Hugo, but I >> would like to see a keyed MAC algorithm devised that is less >> computationally intensive -- but surely something along those lines. >> >> On the other hand, if we aren't talking about creating hashes and >> digital signatures that will be sufficiently robust to resist >> cryptanalytic attacks for hundreds of years or more, but only need to >> survive a couple of years against modest attacker resources, then a >> 512-bit algorithm may be overkill, and 128-bits may even be sufficient. >> >> I guess I'm arguing for algorithms with "knobs" that can be used to >> easily tune the performance characteristics as required, while still >> providing interoperability. >> >> Regards, >> >> Bob >> >> Robert R. Jueneman >> Chief Scientist >> SPYYRUS, Inc. >> >> -----Original Message----- >> From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of >> Ronald L. Rivest >> Sent: Sunday, December 14, 2008 9:07 PM >> To: Multiple recipients of list >> Subject: Thoughts on SHA-3 potential applications, esp. for small >> devices (LONG) >> >> >> Hi Bill -- >> >> I appreciate your thoughtful essays... >> >> There are indeed a lot of dimensions and tradeoffs to >> consider for the SHA-3 competition. >> >> If we think about why one wants a hash standard, four >> reasons come to mind (in no particular order): >> >> (1) A standard promotes and facilitates _interoperability_ >> between products produced by different organizations. >> >> (2) A standard will have been thoroughly evaluated for >> cryptographic strength. >> >> (3) A standard will be accompanied by a multitude of >> well-engineered and tested implementations for various >> platforms. >> >> (4) A standard, by being a standard, facilitates decision-making >> by organizations that are too risk-averse and non-technical >> to make a decision in the absence of a standard. >> >> For a hash function, I suspect that the main use for interoperability >> between products of different organizations will probably continue >> to be as a component of digital signatures. >> >> I do wonder, as you do, what the real needs will be for cryptographic >> primitives on various platforms, as time goes forward. The future, >> as usual, is not always predictable. >> >> The needs of very small devices are perhaps the most interesting >> question to consider. >> >> Devices that are already sufficiently powerful to compute public-key >> digital signatures are presumably going to be big enough to easily >> accommodate any sort of reasonable hash function as well. >> >> I think that devices that are too small to perform a public-key >> digital signature will frequently nonetheless have a requirement >> to authenticate themselves---to perform a MAC. (As you said.) >> >> But the requirements for MAC's are different (and in many ways >> simpler) than those for hash functions. We care about forgery >> rather than collision resistance, MAC outputs can be shorter than >> hash function outputs, etc. I feel it would be a bit strange to >> let the hash function competition be driven by the expectation >> that, for small devices, there is a need to utilize the SHA-3 >> hash function to produce MAC's. >> >> If the world is going to be filled up with tiny devices that >> need to authenticate themselves, then there is a clear need for >> an appropriate MAC standard. The SHA-3 competition was not set up >> to produce such a standard; it merely noted that suitability for >> use in HMAC was a SHA-3 requirement. It would probably be a >> mistake for the world to conclude that NIST feels that all small >> devices should be using HMAC as an authentication technology, >> when there are likely to be much better alternatives for small >> devices. (Perhaps down the road NIST would enjoy running a >> "nano-MAC" standards competition!) >> >> I also suspect that in the world of very small devices, almost >> all system designs will be proprietary and closed. Think for >> example of mass transit card systems or building access cards. >> There is no need for small devices in these systems to work >> "outside the system". The need for interoperability through >> an open standard is not wanted (indeed, it may be very much >> undesired). Thus, for very small devices the need for a standard >> in order to support interoperability may be small or absent. >> >> Of course, there may be exceptions, and who knows what future >> systems will need. >> >> But I find it hard to think of applications for hashing for >> very small devices where: >> -- the device is too small for public-key operations >> -- the hash function is not being used for a MAC >> >> To see why, note that abstractly, a hash value is often used as >> a "proxy" for the value being hashed. Its shorter length may be >> better suited for computation (as for a digital signature) or >> for communication (e.g. for the hash of a message being transmitted >> by a different channel, or at a different time). >> >> But very small devices don't have more than one communication channel, >> and they don't have much storage, so applications that send a hash >> value from a small device, so that it can later send the real message, >> seem dubious (it requires storage). Applications that send the hash >> so that the real message can be sent via another channel may also be >> rare, since the device doesn't have more than one channel. >> >> It isn't very clear to me what utility a "hash value as a proxy >> for a message" philosophy has for very small devices. >> >> Finally, a hash value can be appended to a message for transmission, >> but if one merely wants redundancy it can be done in better ways. >> (Keyed redundancy is different, but that is what a MAC gives.) >> >> I suspect that the world will indeed be filled with lots of >> fascinating small electronic devices, but I think that if they >> do crypto, it will almost certainly be MAC's or digital signatures. >> It is unlikely to be unkeyed hash function application. >> >> Perhaps I've overlooked something important, but I'm far from >> persuaded that the SHA-3 standard will be very relevant for >> very small devices, until you get up to size where the device >> is capable of performing public-key digital signatures. Then >> it will become relevant. But at that point, we've got fairly >> substantial resources already devoted to doing crypto, and one >> should be considering the digital signature operation as a whole; >> the hash function implementation may be a small piece of that whole. >> >> And of course, Moore's Law hasn't quite died yet, and transistors >> continue to shrink. For small devices, at some point the cost of >> bonding and packaging them should greatly exceed the cost of >> producing the chip. (Perhaps we are there already...) >> >> Perhaps others on this list have thoughts on how SHA-3 might >> be useful on very small devices... >> >> These are good discussions to have, and I appreciate your >> bringing these topics up in the hash-forum list. I agree >> with many of the points you brought up. >> >> >> Cheers, >> Ron Rivest >> >> >> On 12/14/2008 3:18 PM, Bill Burr wrote: >>> Bob, >>> >>> We're trying to listen to what everybody says, before forming NIST's >>> opinion about the relative importance of micro-controllers with >> limited >>> memory, versus 1001 other trade-offs. It's just too soon for us to do >> >>> that. >>> >>> In the end, we're going to want something that is a good substitute >> for >>> the SHA-2s in all of their major applications, but is significantly >>> better than SHA-2 in some significant respects. Unless the SHA-2s >>> be "significantly" broken it's going to be very hard to force >>> products to >> >>> change to SHA-3, or even implement SHA-3, if SHA-3 has few significant >> >>> practical advantages. >>> >>> To steal a phrase from Bruce Schneier's talk at the final AES >>> conference, we're probably going to pick a SHA-3 that doesn't "suck at >> >>> anything," or at least anything apparently very significant. And to >>> pick a SHA-3 that is better than SHA-2 at several things. I think >>> we did about that when we selected Rijndael to be the AES, although >>> TDES was easier to improve on than the SHA2's are. The SHA-2s, I >>> think, set >> a >>> reasonably high bar. It's worth remembering, in this respect, >> however, >>> that TDES is not without its virtues: it's pretty efficient in >> hardware. >>> I'll point one other related trade-off I think I see here. The SHA-2s >> >>> give us two different pipe widths. Is it better to do this, or have >> one >>> compromise pipe width for all 4 output sizes, that perhaps is a little >> >>> narrower than ideal for the 512-bit output? >>> At this point it's not clear to me (as distinct from the rest of the >>> folks in my group, who I haven't discussed this with very much at this >> >>> point) that we often ask low-end micro controllers to generate >>> collision free hashes. I suppose that there will always be >> applications >>> for low end processors with very little RAM, but will those often >>> require collision free hashes? And we seem to get more and more >>> powerful processors with more and more memory into smaller and smaller >> >>> packages. It also seems to me that there are more efficient ways to >>> address MACs in micro controllers, than HMAC. So, if HMAC be the main >> >>> application for hash functions in micro controllers, then maybe low >> end >>> micro controllers would not be a major concern for SHA-3. But I >> remain >>> open to arguments to the contrary. And I'm pretty sure we'll wind >>> up with several second round candidate algorithms with narrow-pipe >> designs, >>> as well as several wider pipe designs. >>> >>> Regards, >>> >>> Bill Burr >>> >>> >>> >>> >>> >>> Bob Hattersley wrote: >>>> A somewhat intemperate post perhaps, but there's an interesting >>>> question in >>>> there. Waterfall would be a 6x design in this classification and >>>> therefore >>>> a "monster". (Since I have no desire to make anyone ill, I recommend >> >>>> that >>>> sensitive souls should avoid any further contact with it.) I >>>> worked under >>>> the (possibly invalid) assumption that 512 bytes of RAM (and 2kB of >>>> program >>>> storage) was a reasonable target. 1kB RAM seems to be widely used >> today, >>>> and memory doesn't seem to be getting more expensive. Most >>>> microcontrollers >>>> are not used in situations where cryptography has any relevance. >>>> >>>> But what is the general opinion? Perhaps more important - what is >> NIST's >>>> view? >>>> >>>> Bob Hattersley (Waterfall) >>>> >>>> -----Original Message----- >>>> From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of >> Sean >>>> O'Neil >>>> Sent: 13 December 2008 06:27 >>>> To: Multiple recipients of list >>>> Subject: Narrow-pipe designs >>>> >>>> >>>> A number of people are asking a good question: >>>> >>>> Can someone please publish a paper listing all the narrow-pipe hashes >> as >>>> broken by design, so we could all focus on the good ones with 2x and >>>> slightly larger states? >>>> >>>> <2x is vulnerable by design, >=2x up to 2.5x (or possibly up to 3x) >> is >>>> the >>>> optimal choice, but all the >=4x monsters and some of the designs >> such as >>>> Crunch or FSB with their reference code requiring MEGABYTES (!!!) >>>> of tables >>>> to function are certainly gone too far. With all due respect to >> their >>>> authors, I wouldn't bother looking at those as >>>> a total waste of time. >>>> >>>> Personally, the hash functions with 4x and larger states make me >> wanna >>>> puke, >>>> but technically, they would simply never fit in 128 or >>>> 256 bytes of RAM of the [yes, very] popular 8-bit microcontrollers >>>> that may >>>> want to use some of it for other purposes than merely storing the >> entire >>>> hash state with no room left for a single variable. >>>> >>>> Best regards, >>>> Sean O'Neil >>>> http://www.enrupt.com/ - Raising the bar. >>>> >>>> >>>> >>>> >> > -- William E. Burr Manager, Security Technology Group NIST 100 Bureau Dr., MS 8931 Gaithersburg, MD. 20899 Bldg. 222, Rm B362 Tel: 301-975-2914 Fax: 301-975-8670 From hash-forum@nist.gov Mon Dec 15 11:42:32 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBFJgQji028399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 11:42:28 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBFJeTcg008882; Mon, 15 Dec 2008 14:40:34 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBFJdltk026710; Mon, 15 Dec 2008 14:39:47 -0500 Date: Mon, 15 Dec 2008 14:39:47 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Sean O'Neil" To: Multiple recipients of list Subject: Re: Thoughts on SHA-3 potential applications, esp. for small devices (LONG) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.753.1) X-To: hash-forum@nist.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed References: <20081215073634.GA28920@titan.cry.pto> <470029.8374.qm@web36405.mail.mud.yahoo.com> <2a9a3e6a0812150730v573a9474l2f2b04be0b18a51b@mail.gmail.com> <2a9a3e6a0812151036p1e44befj5aa92ae5a433ed2b@mail.gmail.com> In-Reply-To: <2a9a3e6a0812151036p1e44befj5aa92ae5a433ed2b@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 11:42:28 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 374 On 15 Dec 2008, at 19:43, Chen Ke-Fei Lin wrote: > INFINITE many paremeters = unbreakable moving target proposal = > useless hash Dear Chen, This argument would apply only if the hash at question was actually being modified with an "infinite" number of parameters. It is not. The structure is fixed, it does not need any changes and is not going to change, so there is no moving target. There are not infinitely many parameters in EnRUPT, but only four: state size, word size, parallelization level and the security parameter determining the number of rounds. The recommendation for the included security parameter naturally changes in time as more cryptanalytic results become available. For EnRUPT the recommended number of rounds may go up, for CubeHash it may go down. That is the whole purpose of the security parameter. The future specification will change accordingly, it is not something to worry about. No one is stopping the attacker from determining how many rounds can or cannot be broken by his attack. If the attacker is not diligent enough to determine the range of applicability of his attack and rushes to publish his results with an unfair generalisation, it does not make the algorithm in general broken or "useless", even if it is labelled as such by you or on the SHA-3 Zoo page or on wikipedia relying on it as a reference. Ultimately, it is up to NIST to decide what they can or cannot trust. In the case of EnRUPT, the attacker was kind enough to check and admit that his attack does not apply to the higher values of s, although the SHA-3 Zoo keepers choose to ignore it. As new attacks are discovered-applied-published, we will all know just how fast or how slow all such parameterised algorithms should be. With best regards, Sean O'Neil http://www.enrupt.com/ - Raising the bar. From hash-forum@nist.gov Mon Dec 15 12:24:55 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBFKOnq5004988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 12:24:51 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBFKNKD4002566; Mon, 15 Dec 2008 15:23:28 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBFKLVOe013673; Mon, 15 Dec 2008 15:21:31 -0500 Date: Mon, 15 Dec 2008 15:21:31 -0500 Message-Id: <2a9a3e6a0812151214i69d7c4av74d2143bee02f442@mail.gmail.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Chen Ke-Fei Lin" To: Multiple recipients of list Subject: Re: Thoughts on SHA-3 potential applications, esp. for small devices (LONG) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas References: <20081215073634.GA28920@titan.cry.pto> <470029.8374.qm@web36405.mail.mud.yahoo.com> <2a9a3e6a0812150730v573a9474l2f2b04be0b18a51b@mail.gmail.com> <2a9a3e6a0812151036p1e44befj5aa92ae5a433ed2b@mail.gmail.com> Content-Type: multipart/alternative; boundary="----=_Part_34834_22518091.1229372098216" MIME-Version: 1.0 In-Reply-To: X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 12:24:51 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 375 ------=_Part_34834_22518091.1229372098216 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, Dec 15, 2008 at 8:39 PM, Sean O'Neil wrote: > > On 15 Dec 2008, at 19:43, Chen Ke-Fei Lin wrote: > > INFINITE many paremeters = unbreakable moving target proposal = useless >> hash >> > > Dear Chen, > > This argument would apply only if the hash at question was actually being > modified with an "infinite" number of parameters. It is not. Dear Sean, OK - I stop discussion here. For me your claiming: "Security parameter, s>=4 is recommended." means s=4, s=5, ..., s=10,000,000, ... For you it means just: s=4, s=8, s=12. Regards, C. K. F. Lin ------=_Part_34834_22518091.1229372098216 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, Dec 15, 2008 at 8:39 PM, Sean O'Neil <sean@cryptolib.com> wrote:

On 15 Dec 2008, at 19:43, Chen Ke-Fei Lin wrote:

INFINITE many paremeters = unbreakable moving target proposal = useless hash

Dear Chen,

This argument would apply only if the hash at question was actually being modified with an "infinite" number of parameters. It is not.

Dear Sean,

OK - I stop discussion here.
For me your claiming: "Security parameter, s>=4 is recommended." means s=4, s=5, ..., s=10,000,000, ...
For you it means just: s=4, s=8, s=12.


Regards,
C. K. F. Lin

------=_Part_34834_22518091.1229372098216-- From hash-forum@nist.gov Mon Dec 15 14:45:21 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBFMjDqG026570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 14:45:15 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBFMi7U8020011; Mon, 15 Dec 2008 17:44:11 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBFMg1Qa002893; Mon, 15 Dec 2008 17:42:01 -0500 Date: Mon, 15 Dec 2008 17:42:01 -0500 Message-Id: <4946DC7E.4020000@xs4all.nl> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Maarten Bodewes To: Multiple recipients of list Subject: Re: Thoughts on SHA-3 potential applications, esp. for small devices (LONG) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 In-Reply-To: <49467203.8090204@connotech.com> References: <77E8A818-5279-4A62-B253-0FECF60F4596@cryptolib.com> <79B77C4C1E604E45967DBEA02EF6ED94@BobsDell> <4945676C.3050307@nist.gov> <4945E48D.2080407@mit.edu> <49467203.8090204@connotech.com> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 14:45:15 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 376 Thierry Moreau wrote: > > RFID electronic travel documents off-load the signature verification to > the terminal where the traveler identity is verified -- no crypto there, > not even a (short range radio) link encryption key. This is a 21th > century design. > > From this experience, 32 bits appears as the minimum CPU width that > should count for the SHA-3 competition. Moreover, the limited power > budget of battery-operated devices imposes an algorithm performance > requirement similar to the generic one. > Sorry, that is rather wrong. The current ePassports (eMRTD's) using the Basic Access Control use SHA-1 for key derivation. Basic Access Control is optional, but I haven't seen a single implementation yet that does not perform BAC. Furthermore, they also use SHA-1 for the less used Active Authentication signature, which is used to prove that the chip itself is genuine. The required signature over the data on the ePassport is called Passive Authentication (for a good reason) and is indeed verified by the inspection system. Currently there is a European version of Extended Access Control that uses card verifiable certificates (RSA or ECDSA), using either SHA-1 or SHA-2. As far as I know, most if not all chips used for this are still (power efficient) 8-bit processors doing hashes in software. You can even opt for RSA-PSS in this scheme, requiring even more hashing. I know of RSA-PSS implementations on smart cards, so even if the main hash is calculated outside of the smart card, you'll still need to do some hashing. It does not do to declare the embedded and Smart Card industry out of scope for SHA-3. As a security minded developer and (protocol) designer I'm strongly in favor of hash methods that can be used in a flexible way. Hash methods that do not use great amounts of random access memory and that don't have a wide internal data path are much preferred. If the hash can run as well on 8 bit as 64 bit, then this is much preferred. If it is easy to implement in hardware this is much preferred. If a proposed SHA-3 is hard to implement on small systems in hardware and software then an alternative hash method should be considered. All said, security must come first, since a standardized but broken algorithm is costly on any architecture. But I'll leave that to the mathematically well endowed persons on this list... Regards, Maarten From hash-forum@nist.gov Mon Dec 15 16:20:39 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBG0KWkH004719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 16:20:33 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBG0JPvH008295; Mon, 15 Dec 2008 19:19:29 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBG0IVo2030296; Mon, 15 Dec 2008 19:18:31 -0500 Date: Mon, 15 Dec 2008 19:18:31 -0500 Message-Id: <4946F208.1000702@ellipticsemi.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Mike Borza To: Multiple recipients of list Subject: Re: Scaling laws, and power usage X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 In-Reply-To: <4946A89E.4010908@nist.gov> References: <77E8A818-5279-4A62-B253-0FECF60F4596@cryptolib.com> <79B77C4C1E604E45967DBEA02EF6ED94@BobsDell> <4945676C.3050307@nist.gov> <4945E48D.2080407@mit.edu> <5574ACE4ACD88E45A7026FA0E350334B039F53@cleopatra.spyrus.com> <494696CD.2070803@mit.edu> <4946A89E.4010908@nist.gov> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 16:20:34 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 377 This is an area that I have some experience in. The discussion so far is mostly correct, to first order. I don't want this to degrade into a discussion of semiconductor physics so I'll state a highly simplified model for the components of power consumption here, then try to relate that back to the main point in Robert's original post. Power dissipation in CMOS circuit technology (the most common technology at this time, and likely to be so for some time to come) consists of two parts: static and dynamic power. Static power dissipation has for the past several years been largely irrelevant (and is often approximated as zero, as Ron has done); however, as feature sizes continue to scale down static power dissipation becomes an increasingly large fraction of total power dissipation. Dynamic power dissipation is the component most people think about in CMOS circuits, and it is f*C*V^2, where f is the switching (clock) frequency, C is the load capacitance that a gate "sees", and V is the supply voltage. C itself is ideally the capacitance on adjacent cell(s), which is proportional to the square of the feature size, and so does scale down with the square of linewidth reduction with advancing technology. Thus, we've been accustomed to gaining exponential increases in circuit (functional) density with reductions in minimum feature size; simplistically this effect is responsible for Moore's law. However, we're now running into some fundamental physical limits: we haven't hit them yet but we're going to soon enough. Supply voltages now are unable to scale down as quickly as linewidth. Also, as I mentioned static power dissipation due to gate leakage and other effects is an increasing proportion of total consumption and doesn't scale as quickly. Finally, while capacitance ideally scales down in each new technology node, the interconnect between circuit elements is not following that trend at the same rate, resulting in more dissipation than predicted by simple technology scaling. This is why power dissipation has not kept pace with logic density. Ultimate computing capacity is limited by the power density that the substrate can sustain. This in turn limits the maximum frequency and density that circuits can be designed for and therefore the maximum throughput (or minimum area). What does this mean for selecting a hash algorithm? First, it is axiomatic that the algorithm ultimately selected must have sufficient security. Without that, there is no reason to implement it, and its efficiency doesn't matter. After that, it should be the most cost effective implementation that satisfies the security requirements. Simplistically, the cost of an implementation (in either dollars or watts) is proportional to the product of its implementation area and the speed that it operates at. What I think Robert, and certainly people like me, would hope to find as a result of this competition is that the cost can be extremely low to justify use of the algorithm in very small implementations. Costly implementation will have large area requirements (for example large intermediate states or static table spaces), or those that produce very small amounts of output per clock cycle. An algorithm that can be predictably tuned in terms of the amount of security provided, the amount of space required, or the speed at which it generates its output will be the most flexible and useful in trading these aspects off, and therefore applicable across a range of applications. While I appreciate the importance of efficient software implementations that run in large CPU environments, most of the people I'm involved with don't deploy their solutions in those environments. They have performance and cost constraints that simply don't fit. As Robert noted, the devices they develop often interoperate with those large software environments. User credentials are an example: these may take the form of smartcards or wirelessly powered RFID tags that authenticate their holders to central servers. Individual users may be able to tolerate modest performance, but a server simultaneously authenticating thousands of those users needs to be capable of accomplishing that in a reasonable time. To give a concrete example, AES is very flexible in its definition and range of implementation possibilities. It has scalable security that imposes a modest penalty to scale up the security. The smallest hardware implementations are about 4K gates running at about 0.1 bits per cycle. Small software implementations fit in a few hundreds bytes of code, and it runs acceptably in 8 bit processors, which are still today shockingly popular in new designs. From there, it is possible today to scale the same algorithm up to a single implementation capable of 128 bits per cycle at, say, 500 MHz in about 300K gates. That's a range from a few 10's or 100's of kilobits per second to about 64 gigabits per second, and all at a security level of at least 128 bits. Instantaneous power consumption to accomplish this ranges from microwatts to a few watts, which as Bill notes is well down from what it was just a few years ago. Neither of those extrema has a place in a CPU today nor for the forseeable future. But note that we'll bottom out the gains we can make in traditional semiconductor technology in the next fewyears. Any replacement technologies will face similar ultimate limits, some at admittedly much higher levels of performance, smaller volume requirements or lower power consumption. This is the kind of flexibility I would like to see in the ultimate hash competition selection. Best regards, Mike Borza On 15/12/08 01:58 PM, Bill Burr wrote: > > Ron & Bob, > > I don't claim any particular VLSI expertise, but my understanding is > that transistors only consume much power when they are actually > switching, that is P=I*V, and when a transistor is in the either the > on or the off state, either I or V is close to zero. So when you > crank up the clock you almost always increase poser consumption. > Moreover you are charging and discharging capacitors more, and that > means current is flowing, and current flowing tends to mean power is > being consumed. Also smaller transistors generally means lower > voltages, and smaller currents, while power is proportional to both > V^2 and I^2. In principle I think you naturally reduce power > consumption per computation as you shrink dimensions, but of course, > you increase overall power consumption as you increase clock rates. > > Of course, as soon as you have to drive an external lead off the chip, > you're back to dealing with higher voltages, and more current. > > We know that power consumption per unit of computation has gone down > greatly as we've crammed more and more gates into less and less > area. I just bought a little netbook with an Intel Atom processor. > It has a 1.6 GHz clock, and burns very little power, yet it's surely > computationally more powerful than the early Pentiums of not so long > ago, which ran hot enough to fry eggs. Maybe reducing power > consumption hasn't kept pace with the exponent of Moore's Law for > semiconductors, but if power consumption is pretty much the limiting > factor today, then our ability to limit power consumption (or to carry > the heat away) must be largely the limiting factor in Moore's Law, at > least if you think of Moore's law in terms of computing power per > Dollar, I think. > > Regards, > > Bill > > Ronald L. Rivest wrote: >> >> Hi Bob -- >> >> Good comments! >> >> With respect to scaling however, my understanding is >> that scaling *can* improve power usage. If you >> decrease dimensions by a factor of two in both x and >> y dimensions, then all capacitances decrease by a factor >> of four, and power usage improves, since it takes less >> current to change the state of a capacitor. This is >> assuming you don't also change the clock rate or voltage. If >> you increase the frequency by a factor of four, you get >> the same current draw, but to increase frequency you >> need to increase voltage inside the chip to get things >> to happen faster. So power usage tends to go up. >> Scaling is complicated, but the increased freedom of >> using smaller features on a chip can yield improved >> power usage, if you don't muck with the clock rate and/or >> voltage at the same time... >> >> (The above analysis is quite simplistic and naive; for the >> truth someone with stronger VLSI expertise should advise >> us...) >> >> Cheers, >> Ron >> >> On 12/15/2008 12:19 PM, Robert Jueneman wrote: >>> Ron and Bill, >>> >>> I don't have a dog in this fight, but I'd like to comment on the size >>> issue, since SPYRUS is involved in both the low-cost, low-power, >>> bandwidth-constrained smartcard end of the spectrum and the relatively >>> unconstrained HSM and/or host-based processing system at the other. >>> >>> For interoperability, it is essential that we have an efficient >>> algorithm that can run in both spaces. >>> >>> I also agree with the need for multi-purpose algorithms -- we were the >>> first and perhaps still one of the few organizations to use HASH_DRBG >>> from SP 800-90 for random number generation. (Somehow, using AES to >>> generate keys to be used for AES seemed like putting too many eggs in >>> one basket, especially when you think about SPA and DPA attacks.) >>> >>> With regard to hashing vs. digital signatures on a chip, the issue is >>> more likely going to be bandwidth rather than processing power, as >>> smart >>> cards normally support only the IOS 7816 interface -- maybe 100 kbps at >>> best. Our smart cards have no difficultly computing ECDSA, EC-DH, and >>> ECMQV for P-256, P-384, and P-521, and the code size constraint isn't >>> much of a limitation -- the code will fit comfortably into ROM or >>> EEPROM, as required. But don't expect it to be done in a millisecond. >>> >>> In that regard, it is important to remember that although Moore's Law >>> predicts ever-increasing transistor density, and that generally >>> translates into increased speed and what I will call agility >>> (parallelism, redundant implementations, etc.), there is one thing that >>> Moore's law does NOT provide, and that is the increased power required >>> to operate these devices. I'm certainly not a semi-conductor >>> physicist, >>> but I don't recall reading anything about reducing the power >>> required to >>> flip a bit in a transistor. And the faster you want to do that, the >>> more electrical power it takes. >>> >>> So when you start talking about nano-processors, that is likely to be >>> the limiting factor. And where that shows up in today's market is with >>> respect very low cost, very low power RFID chips. >>> >>> In that market, I expect that a keyed hash will continue to be very >>> important as an alternative to the slower digital signatures of >>> comparable strength. Maybe not HMAC -- no disrespect to Hugo, but I >>> would like to see a keyed MAC algorithm devised that is less >>> computationally intensive -- but surely something along those lines. >>> >>> On the other hand, if we aren't talking about creating hashes and >>> digital signatures that will be sufficiently robust to resist >>> cryptanalytic attacks for hundreds of years or more, but only need to >>> survive a couple of years against modest attacker resources, then a >>> 512-bit algorithm may be overkill, and 128-bits may even be sufficient. >>> >>> I guess I'm arguing for algorithms with "knobs" that can be used to >>> easily tune the performance characteristics as required, while still >>> providing interoperability. >>> >>> Regards, >>> >>> Bob >>> >>> Robert R. Jueneman >>> Chief Scientist >>> SPYYRUS, Inc. >>> >>> -----Original Message----- >>> From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of >>> Ronald L. Rivest >>> Sent: Sunday, December 14, 2008 9:07 PM >>> To: Multiple recipients of list >>> Subject: Thoughts on SHA-3 potential applications, esp. for small >>> devices (LONG) >>> >>> >>> Hi Bill -- >>> >>> I appreciate your thoughtful essays... >>> >>> There are indeed a lot of dimensions and tradeoffs to >>> consider for the SHA-3 competition. >>> >>> If we think about why one wants a hash standard, four >>> reasons come to mind (in no particular order): >>> >>> (1) A standard promotes and facilitates _interoperability_ >>> between products produced by different organizations. >>> >>> (2) A standard will have been thoroughly evaluated for >>> cryptographic strength. >>> >>> (3) A standard will be accompanied by a multitude of >>> well-engineered and tested implementations for various >>> platforms. >>> >>> (4) A standard, by being a standard, facilitates decision-making >>> by organizations that are too risk-averse and non-technical >>> to make a decision in the absence of a standard. >>> >>> For a hash function, I suspect that the main use for interoperability >>> between products of different organizations will probably continue >>> to be as a component of digital signatures. >>> >>> I do wonder, as you do, what the real needs will be for cryptographic >>> primitives on various platforms, as time goes forward. The future, >>> as usual, is not always predictable. >>> >>> The needs of very small devices are perhaps the most interesting >>> question to consider. >>> >>> Devices that are already sufficiently powerful to compute public-key >>> digital signatures are presumably going to be big enough to easily >>> accommodate any sort of reasonable hash function as well. >>> >>> I think that devices that are too small to perform a public-key >>> digital signature will frequently nonetheless have a requirement >>> to authenticate themselves---to perform a MAC. (As you said.) >>> >>> But the requirements for MAC's are different (and in many ways >>> simpler) than those for hash functions. We care about forgery >>> rather than collision resistance, MAC outputs can be shorter than >>> hash function outputs, etc. I feel it would be a bit strange to >>> let the hash function competition be driven by the expectation >>> that, for small devices, there is a need to utilize the SHA-3 >>> hash function to produce MAC's. >>> >>> If the world is going to be filled up with tiny devices that >>> need to authenticate themselves, then there is a clear need for >>> an appropriate MAC standard. The SHA-3 competition was not set up >>> to produce such a standard; it merely noted that suitability for >>> use in HMAC was a SHA-3 requirement. It would probably be a >>> mistake for the world to conclude that NIST feels that all small >>> devices should be using HMAC as an authentication technology, >>> when there are likely to be much better alternatives for small >>> devices. (Perhaps down the road NIST would enjoy running a >>> "nano-MAC" standards competition!) >>> >>> I also suspect that in the world of very small devices, almost >>> all system designs will be proprietary and closed. Think for >>> example of mass transit card systems or building access cards. >>> There is no need for small devices in these systems to work >>> "outside the system". The need for interoperability through >>> an open standard is not wanted (indeed, it may be very much >>> undesired). Thus, for very small devices the need for a standard >>> in order to support interoperability may be small or absent. >>> >>> Of course, there may be exceptions, and who knows what future >>> systems will need. >>> >>> But I find it hard to think of applications for hashing for >>> very small devices where: >>> -- the device is too small for public-key operations >>> -- the hash function is not being used for a MAC >>> >>> To see why, note that abstractly, a hash value is often used as >>> a "proxy" for the value being hashed. Its shorter length may be >>> better suited for computation (as for a digital signature) or >>> for communication (e.g. for the hash of a message being transmitted >>> by a different channel, or at a different time). >>> >>> But very small devices don't have more than one communication channel, >>> and they don't have much storage, so applications that send a hash >>> value from a small device, so that it can later send the real message, >>> seem dubious (it requires storage). Applications that send the hash >>> so that the real message can be sent via another channel may also be >>> rare, since the device doesn't have more than one channel. >>> >>> It isn't very clear to me what utility a "hash value as a proxy >>> for a message" philosophy has for very small devices. >>> >>> Finally, a hash value can be appended to a message for transmission, >>> but if one merely wants redundancy it can be done in better ways. >>> (Keyed redundancy is different, but that is what a MAC gives.) >>> >>> I suspect that the world will indeed be filled with lots of >>> fascinating small electronic devices, but I think that if they >>> do crypto, it will almost certainly be MAC's or digital signatures. >>> It is unlikely to be unkeyed hash function application. >>> >>> Perhaps I've overlooked something important, but I'm far from >>> persuaded that the SHA-3 standard will be very relevant for >>> very small devices, until you get up to size where the device >>> is capable of performing public-key digital signatures. Then >>> it will become relevant. But at that point, we've got fairly >>> substantial resources already devoted to doing crypto, and one >>> should be considering the digital signature operation as a whole; >>> the hash function implementation may be a small piece of that whole. >>> >>> And of course, Moore's Law hasn't quite died yet, and transistors >>> continue to shrink. For small devices, at some point the cost of >>> bonding and packaging them should greatly exceed the cost of >>> producing the chip. (Perhaps we are there already...) >>> >>> Perhaps others on this list have thoughts on how SHA-3 might >>> be useful on very small devices... >>> >>> These are good discussions to have, and I appreciate your >>> bringing these topics up in the hash-forum list. I agree >>> with many of the points you brought up. >>> >>> >>> Cheers, >>> Ron Rivest >>> >>> >>> On 12/14/2008 3:18 PM, Bill Burr wrote: >>>> Bob, >>>> >>>> We're trying to listen to what everybody says, before forming >>>> NIST's opinion about the relative importance of micro-controllers with >>> limited >>>> memory, versus 1001 other trade-offs. It's just too soon for us to do >>> >>>> that. >>>> >>>> In the end, we're going to want something that is a good substitute >>> for >>>> the SHA-2s in all of their major applications, but is significantly >>>> better than SHA-2 in some significant respects. Unless the SHA-2s >>>> be "significantly" broken it's going to be very hard to force >>>> products to >>> >>>> change to SHA-3, or even implement SHA-3, if SHA-3 has few significant >>> >>>> practical advantages. >>>> >>>> To steal a phrase from Bruce Schneier's talk at the final AES >>>> conference, we're probably going to pick a SHA-3 that doesn't "suck at >>> >>>> anything," or at least anything apparently very significant. And >>>> to pick a SHA-3 that is better than SHA-2 at several things. I >>>> think we did about that when we selected Rijndael to be the AES, >>>> although TDES was easier to improve on than the SHA2's are. The >>>> SHA-2s, I think, set >>> a >>>> reasonably high bar. It's worth remembering, in this respect, >>> however, >>>> that TDES is not without its virtues: it's pretty efficient in >>> hardware. >>>> I'll point one other related trade-off I think I see here. The SHA-2s >>> >>>> give us two different pipe widths. Is it better to do this, or have >>> one >>>> compromise pipe width for all 4 output sizes, that perhaps is a little >>> >>>> narrower than ideal for the 512-bit output? >>>> At this point it's not clear to me (as distinct from the rest of >>>> the folks in my group, who I haven't discussed this with very much >>>> at this >>> >>>> point) that we often ask low-end micro controllers to generate >>>> collision free hashes. I suppose that there will always be >>> applications >>>> for low end processors with very little RAM, but will those often >>>> require collision free hashes? And we seem to get more and more >>>> powerful processors with more and more memory into smaller and smaller >>> >>>> packages. It also seems to me that there are more efficient ways >>>> to address MACs in micro controllers, than HMAC. So, if HMAC be >>>> the main >>> >>>> application for hash functions in micro controllers, then maybe low >>> end >>>> micro controllers would not be a major concern for SHA-3. But I >>> remain >>>> open to arguments to the contrary. And I'm pretty sure we'll wind >>>> up with several second round candidate algorithms with narrow-pipe >>> designs, >>>> as well as several wider pipe designs. >>>> >>>> Regards, >>>> >>>> Bill Burr >>>> >>>> >>>> >>>> >>>> >>>> Bob Hattersley wrote: >>>>> A somewhat intemperate post perhaps, but there's an interesting >>>>> question in >>>>> there. Waterfall would be a 6x design in this classification and >>>>> therefore >>>>> a "monster". (Since I have no desire to make anyone ill, I recommend >>> >>>>> that >>>>> sensitive souls should avoid any further contact with it.) I >>>>> worked under >>>>> the (possibly invalid) assumption that 512 bytes of RAM (and 2kB >>>>> of program >>>>> storage) was a reasonable target. 1kB RAM seems to be widely used >>> today, >>>>> and memory doesn't seem to be getting more expensive. Most >>>>> microcontrollers >>>>> are not used in situations where cryptography has any relevance. >>>>> >>>>> But what is the general opinion? Perhaps more important - what is >>> NIST's >>>>> view? >>>>> >>>>> Bob Hattersley (Waterfall) >>>>> >>>>> -----Original Message----- >>>>> From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of >>> Sean >>>>> O'Neil >>>>> Sent: 13 December 2008 06:27 >>>>> To: Multiple recipients of list >>>>> Subject: Narrow-pipe designs >>>>> >>>>> >>>>> A number of people are asking a good question: >>>>> >>>>> Can someone please publish a paper listing all the narrow-pipe hashes >>> as >>>>> broken by design, so we could all focus on the good ones with 2x and >>>>> slightly larger states? >>>>> >>>>> <2x is vulnerable by design, >=2x up to 2.5x (or possibly up to 3x) >>> is >>>>> the >>>>> optimal choice, but all the >=4x monsters and some of the designs >>> such as >>>>> Crunch or FSB with their reference code requiring MEGABYTES (!!!) >>>>> of tables >>>>> to function are certainly gone too far. With all due respect to >>> their >>>>> authors, I wouldn't bother looking at those as >>>>> a total waste of time. >>>>> >>>>> Personally, the hash functions with 4x and larger states make me >>> wanna >>>>> puke, >>>>> but technically, they would simply never fit in 128 or >>>>> 256 bytes of RAM of the [yes, very] popular 8-bit microcontrollers >>>>> that may >>>>> want to use some of it for other purposes than merely storing the >>> entire >>>>> hash state with no room left for a single variable. >>>>> >>>>> Best regards, >>>>> Sean O'Neil >>>>> http://www.enrupt.com/ - Raising the bar. >>>>> >>>>> >>>>> >>>>> >>> >> > From hash-forum@nist.gov Mon Dec 15 17:31:32 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBG1VROi015107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 17:31:28 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBG1RVpC002695; Mon, 15 Dec 2008 20:27:33 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBG1QgtJ031897; Mon, 15 Dec 2008 20:26:42 -0500 Date: Mon, 15 Dec 2008 20:26:42 -0500 Message-Id: <314F196C-B476-48DD-9884-ADE25F2957BD@qualcomm.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Greg Rose To: Multiple recipients of list Subject: Re: regarding etiquette X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Apple Mail (2.929.2) References: <494323F1.1030502@mit.edu> Mime-Version: 1.0 (Apple Message framework v929.2) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes In-Reply-To: <494323F1.1030502@mit.edu> X-To: "hash-forum@nist.gov" X-Cc: Greg Rose X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 17:31:28 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 378 On Dec 12, 2008, at 7:12 PM, David Wilson wrote: > Is there a consensus opinion regarding the etiquette of going about > publicizing attacks on SHA-3 candidates? For three reasons, I think the attackers should inform the authors before going public (if they don't hear back, of course they should then go ahead). 1. Sometimes the attack is just plain wrong. (We got one of our best papers out of figuring out why a plausible-looking attack didn't work. But the attack paper had already been accepted, and the published version looked very lame when it finally came out.) 2. Sometimes the attack needs "tweaking", and who better to know how to tweak it? 3. While I try very hard to be egoless in these things, it can still be a shock to meet a friend and hear "sorry about Algorithm X being broken". (Of course, I have lots of broken algorithms, any time I stray from stream ciphers, and even then...) Some people do, and some don't. Ivica's attack on Boole was handled perfectly, in my opinion; we had a few rounds of clarification and correction. Anyway, that is what I like to have done to me, so that is what I do too. Greg. From hash-forum@nist.gov Mon Dec 15 17:56:14 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBG1u7cP017406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 17:56:08 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBG1t8YI023395; Mon, 15 Dec 2008 20:55:13 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBG1sKC4021003; Mon, 15 Dec 2008 20:54:20 -0500 Date: Mon, 15 Dec 2008 20:54:20 -0500 Message-Id: <5574ACE4ACD88E45A7026FA0E350334B039F71@cleopatra.spyrus.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Robert Jueneman" To: Multiple recipients of list Subject: RE: Scaling laws, and power usage X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit X-To: References: <77E8A818-5279-4A62-B253-0FECF60F4596@cryptolib.com> <79B77C4C1E604E45967DBEA02EF6ED94@BobsDell> <4945676C.3050307@nist.gov> <4945E48D.2080407@mit.edu> <5574ACE4ACD88E45A7026FA0E350334B039F53@cleopatra.spyrus.com> <494696CD.2070803@mit.edu> <4946A89E.4010908@nist.gov> <4946F208.1000702@ellipticsemi.com> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 17:56:08 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 379 Thanks to all, and especially Mike, for elucidating some of these issues much more clearly, and probably correctly, than I could have ever done. (The only circuits I ever designed involved triodes, but that experience is no longer relevant!) The conclusion, I think, is that size and power consumption are very important for a very considerable portion of the space in which SHA-3 will be used. And Neils has made a pretty good argument why this is important for even the large host processors as well, for the foreseeable future (whatever that may be, in terms of operating system design.) So although I am one that likes to think about hash functions, digital signatures, encryption, and RNGs being resilient enough to resist attacks for at least another 100 years, and hopefully longer, these issues of efficiency and scalability are also important, and hence my desire for the parametric "knobs" on the algorithms. Bob -----Original Message----- From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Mike Borza Sent: Monday, December 15, 2008 4:19 PM To: Multiple recipients of list Subject: Re: Scaling laws, and power usage This is an area that I have some experience in. The discussion so far is mostly correct, to first order. I don't want this to degrade into a discussion of semiconductor physics so I'll state a highly simplified model for the components of power consumption here, then try to relate that back to the main point in Robert's original post. Power dissipation in CMOS circuit technology (the most common technology at this time, and likely to be so for some time to come) consists of two parts: static and dynamic power. Static power dissipation has for the past several years been largely irrelevant (and is often approximated as zero, as Ron has done); however, as feature sizes continue to scale down static power dissipation becomes an increasingly large fraction of total power dissipation. Dynamic power dissipation is the component most people think about in CMOS circuits, and it is f*C*V^2, where f is the switching (clock) frequency, C is the load capacitance that a gate "sees", and V is the supply voltage. C itself is ideally the capacitance on adjacent cell(s), which is proportional to the square of the feature size, and so does scale down with the square of linewidth reduction with advancing technology. Thus, we've been accustomed to gaining exponential increases in circuit (functional) density with reductions in minimum feature size; simplistically this effect is responsible for Moore's law. However, we're now running into some fundamental physical limits: we haven't hit them yet but we're going to soon enough. Supply voltages now are unable to scale down as quickly as linewidth. Also, as I mentioned static power dissipation due to gate leakage and other effects is an increasing proportion of total consumption and doesn't scale as quickly. Finally, while capacitance ideally scales down in each new technology node, the interconnect between circuit elements is not following that trend at the same rate, resulting in more dissipation than predicted by simple technology scaling. This is why power dissipation has not kept pace with logic density. Ultimate computing capacity is limited by the power density that the substrate can sustain. This in turn limits the maximum frequency and density that circuits can be designed for and therefore the maximum throughput (or minimum area). What does this mean for selecting a hash algorithm? First, it is axiomatic that the algorithm ultimately selected must have sufficient security. Without that, there is no reason to implement it, and its efficiency doesn't matter. After that, it should be the most cost effective implementation that satisfies the security requirements. Simplistically, the cost of an implementation (in either dollars or watts) is proportional to the product of its implementation area and the speed that it operates at. What I think Robert, and certainly people like me, would hope to find as a result of this competition is that the cost can be extremely low to justify use of the algorithm in very small implementations. Costly implementation will have large area requirements (for example large intermediate states or static table spaces), or those that produce very small amounts of output per clock cycle. An algorithm that can be predictably tuned in terms of the amount of security provided, the amount of space required, or the speed at which it generates its output will be the most flexible and useful in trading these aspects off, and therefore applicable across a range of applications. While I appreciate the importance of efficient software implementations that run in large CPU environments, most of the people I'm involved with don't deploy their solutions in those environments. They have performance and cost constraints that simply don't fit. As Robert noted, the devices they develop often interoperate with those large software environments. User credentials are an example: these may take the form of smartcards or wirelessly powered RFID tags that authenticate their holders to central servers. Individual users may be able to tolerate modest performance, but a server simultaneously authenticating thousands of those users needs to be capable of accomplishing that in a reasonable time. To give a concrete example, AES is very flexible in its definition and range of implementation possibilities. It has scalable security that imposes a modest penalty to scale up the security. The smallest hardware implementations are about 4K gates running at about 0.1 bits per cycle. Small software implementations fit in a few hundreds bytes of code, and it runs acceptably in 8 bit processors, which are still today shockingly popular in new designs. From there, it is possible today to scale the same algorithm up to a single implementation capable of 128 bits per cycle at, say, 500 MHz in about 300K gates. That's a range from a few 10's or 100's of kilobits per second to about 64 gigabits per second, and all at a security level of at least 128 bits. Instantaneous power consumption to accomplish this ranges from microwatts to a few watts, which as Bill notes is well down from what it was just a few years ago. Neither of those extrema has a place in a CPU today nor for the forseeable future. But note that we'll bottom out the gains we can make in traditional semiconductor technology in the next fewyears. Any replacement technologies will face similar ultimate limits, some at admittedly much higher levels of performance, smaller volume requirements or lower power consumption. This is the kind of flexibility I would like to see in the ultimate hash competition selection. Best regards, Mike Borza On 15/12/08 01:58 PM, Bill Burr wrote: > > Ron & Bob, > > I don't claim any particular VLSI expertise, but my understanding is > that transistors only consume much power when they are actually > switching, that is P=I*V, and when a transistor is in the either the > on or the off state, either I or V is close to zero. So when you > crank up the clock you almost always increase poser consumption. > Moreover you are charging and discharging capacitors more, and that > means current is flowing, and current flowing tends to mean power is > being consumed. Also smaller transistors generally means lower > voltages, and smaller currents, while power is proportional to both > V^2 and I^2. In principle I think you naturally reduce power > consumption per computation as you shrink dimensions, but of course, > you increase overall power consumption as you increase clock rates. > > Of course, as soon as you have to drive an external lead off the chip, > you're back to dealing with higher voltages, and more current. > > We know that power consumption per unit of computation has gone down > greatly as we've crammed more and more gates into less and less > area. I just bought a little netbook with an Intel Atom processor. > It has a 1.6 GHz clock, and burns very little power, yet it's surely > computationally more powerful than the early Pentiums of not so long > ago, which ran hot enough to fry eggs. Maybe reducing power > consumption hasn't kept pace with the exponent of Moore's Law for > semiconductors, but if power consumption is pretty much the limiting > factor today, then our ability to limit power consumption (or to carry > the heat away) must be largely the limiting factor in Moore's Law, at > least if you think of Moore's law in terms of computing power per > Dollar, I think. > > Regards, > > Bill > > Ronald L. Rivest wrote: >> >> Hi Bob -- >> >> Good comments! >> >> With respect to scaling however, my understanding is >> that scaling *can* improve power usage. If you >> decrease dimensions by a factor of two in both x and >> y dimensions, then all capacitances decrease by a factor >> of four, and power usage improves, since it takes less >> current to change the state of a capacitor. This is >> assuming you don't also change the clock rate or voltage. If >> you increase the frequency by a factor of four, you get >> the same current draw, but to increase frequency you >> need to increase voltage inside the chip to get things >> to happen faster. So power usage tends to go up. >> Scaling is complicated, but the increased freedom of >> using smaller features on a chip can yield improved >> power usage, if you don't muck with the clock rate and/or >> voltage at the same time... >> >> (The above analysis is quite simplistic and naive; for the >> truth someone with stronger VLSI expertise should advise >> us...) >> >> Cheers, >> Ron >> >> On 12/15/2008 12:19 PM, Robert Jueneman wrote: >>> Ron and Bill, >>> >>> I don't have a dog in this fight, but I'd like to comment on the size >>> issue, since SPYRUS is involved in both the low-cost, low-power, >>> bandwidth-constrained smartcard end of the spectrum and the relatively >>> unconstrained HSM and/or host-based processing system at the other. >>> >>> For interoperability, it is essential that we have an efficient >>> algorithm that can run in both spaces. >>> >>> I also agree with the need for multi-purpose algorithms -- we were the >>> first and perhaps still one of the few organizations to use HASH_DRBG >>> from SP 800-90 for random number generation. (Somehow, using AES to >>> generate keys to be used for AES seemed like putting too many eggs in >>> one basket, especially when you think about SPA and DPA attacks.) >>> >>> With regard to hashing vs. digital signatures on a chip, the issue is >>> more likely going to be bandwidth rather than processing power, as >>> smart >>> cards normally support only the IOS 7816 interface -- maybe 100 kbps at >>> best. Our smart cards have no difficultly computing ECDSA, EC-DH, and >>> ECMQV for P-256, P-384, and P-521, and the code size constraint isn't >>> much of a limitation -- the code will fit comfortably into ROM or >>> EEPROM, as required. But don't expect it to be done in a millisecond. >>> >>> In that regard, it is important to remember that although Moore's Law >>> predicts ever-increasing transistor density, and that generally >>> translates into increased speed and what I will call agility >>> (parallelism, redundant implementations, etc.), there is one thing that >>> Moore's law does NOT provide, and that is the increased power required >>> to operate these devices. I'm certainly not a semi-conductor >>> physicist, >>> but I don't recall reading anything about reducing the power >>> required to >>> flip a bit in a transistor. And the faster you want to do that, the >>> more electrical power it takes. >>> >>> So when you start talking about nano-processors, that is likely to be >>> the limiting factor. And where that shows up in today's market is with >>> respect very low cost, very low power RFID chips. >>> >>> In that market, I expect that a keyed hash will continue to be very >>> important as an alternative to the slower digital signatures of >>> comparable strength. Maybe not HMAC -- no disrespect to Hugo, but I >>> would like to see a keyed MAC algorithm devised that is less >>> computationally intensive -- but surely something along those lines. >>> >>> On the other hand, if we aren't talking about creating hashes and >>> digital signatures that will be sufficiently robust to resist >>> cryptanalytic attacks for hundreds of years or more, but only need to >>> survive a couple of years against modest attacker resources, then a >>> 512-bit algorithm may be overkill, and 128-bits may even be sufficient. >>> >>> I guess I'm arguing for algorithms with "knobs" that can be used to >>> easily tune the performance characteristics as required, while still >>> providing interoperability. >>> >>> Regards, >>> >>> Bob >>> >>> Robert R. Jueneman >>> Chief Scientist >>> SPYYRUS, Inc. >>> >>> -----Original Message----- >>> From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of >>> Ronald L. Rivest >>> Sent: Sunday, December 14, 2008 9:07 PM >>> To: Multiple recipients of list >>> Subject: Thoughts on SHA-3 potential applications, esp. for small >>> devices (LONG) >>> >>> >>> Hi Bill -- >>> >>> I appreciate your thoughtful essays... >>> >>> There are indeed a lot of dimensions and tradeoffs to >>> consider for the SHA-3 competition. >>> >>> If we think about why one wants a hash standard, four >>> reasons come to mind (in no particular order): >>> >>> (1) A standard promotes and facilitates _interoperability_ >>> between products produced by different organizations. >>> >>> (2) A standard will have been thoroughly evaluated for >>> cryptographic strength. >>> >>> (3) A standard will be accompanied by a multitude of >>> well-engineered and tested implementations for various >>> platforms. >>> >>> (4) A standard, by being a standard, facilitates decision-making >>> by organizations that are too risk-averse and non-technical >>> to make a decision in the absence of a standard. >>> >>> For a hash function, I suspect that the main use for interoperability >>> between products of different organizations will probably continue >>> to be as a component of digital signatures. >>> >>> I do wonder, as you do, what the real needs will be for cryptographic >>> primitives on various platforms, as time goes forward. The future, >>> as usual, is not always predictable. >>> >>> The needs of very small devices are perhaps the most interesting >>> question to consider. >>> >>> Devices that are already sufficiently powerful to compute public-key >>> digital signatures are presumably going to be big enough to easily >>> accommodate any sort of reasonable hash function as well. >>> >>> I think that devices that are too small to perform a public-key >>> digital signature will frequently nonetheless have a requirement >>> to authenticate themselves---to perform a MAC. (As you said.) >>> >>> But the requirements for MAC's are different (and in many ways >>> simpler) than those for hash functions. We care about forgery >>> rather than collision resistance, MAC outputs can be shorter than >>> hash function outputs, etc. I feel it would be a bit strange to >>> let the hash function competition be driven by the expectation >>> that, for small devices, there is a need to utilize the SHA-3 >>> hash function to produce MAC's. >>> >>> If the world is going to be filled up with tiny devices that >>> need to authenticate themselves, then there is a clear need for >>> an appropriate MAC standard. The SHA-3 competition was not set up >>> to produce such a standard; it merely noted that suitability for >>> use in HMAC was a SHA-3 requirement. It would probably be a >>> mistake for the world to conclude that NIST feels that all small >>> devices should be using HMAC as an authentication technology, >>> when there are likely to be much better alternatives for small >>> devices. (Perhaps down the road NIST would enjoy running a >>> "nano-MAC" standards competition!) >>> >>> I also suspect that in the world of very small devices, almost >>> all system designs will be proprietary and closed. Think for >>> example of mass transit card systems or building access cards. >>> There is no need for small devices in these systems to work >>> "outside the system". The need for interoperability through >>> an open standard is not wanted (indeed, it may be very much >>> undesired). Thus, for very small devices the need for a standard >>> in order to support interoperability may be small or absent. >>> >>> Of course, there may be exceptions, and who knows what future >>> systems will need. >>> >>> But I find it hard to think of applications for hashing for >>> very small devices where: >>> -- the device is too small for public-key operations >>> -- the hash function is not being used for a MAC >>> >>> To see why, note that abstractly, a hash value is often used as >>> a "proxy" for the value being hashed. Its shorter length may be >>> better suited for computation (as for a digital signature) or >>> for communication (e.g. for the hash of a message being transmitted >>> by a different channel, or at a different time). >>> >>> But very small devices don't have more than one communication channel, >>> and they don't have much storage, so applications that send a hash >>> value from a small device, so that it can later send the real message, >>> seem dubious (it requires storage). Applications that send the hash >>> so that the real message can be sent via another channel may also be >>> rare, since the device doesn't have more than one channel. >>> >>> It isn't very clear to me what utility a "hash value as a proxy >>> for a message" philosophy has for very small devices. >>> >>> Finally, a hash value can be appended to a message for transmission, >>> but if one merely wants redundancy it can be done in better ways. >>> (Keyed redundancy is different, but that is what a MAC gives.) >>> >>> I suspect that the world will indeed be filled with lots of >>> fascinating small electronic devices, but I think that if they >>> do crypto, it will almost certainly be MAC's or digital signatures. >>> It is unlikely to be unkeyed hash function application. >>> >>> Perhaps I've overlooked something important, but I'm far from >>> persuaded that the SHA-3 standard will be very relevant for >>> very small devices, until you get up to size where the device >>> is capable of performing public-key digital signatures. Then >>> it will become relevant. But at that point, we've got fairly >>> substantial resources already devoted to doing crypto, and one >>> should be considering the digital signature operation as a whole; >>> the hash function implementation may be a small piece of that whole. >>> >>> And of course, Moore's Law hasn't quite died yet, and transistors >>> continue to shrink. For small devices, at some point the cost of >>> bonding and packaging them should greatly exceed the cost of >>> producing the chip. (Perhaps we are there already...) >>> >>> Perhaps others on this list have thoughts on how SHA-3 might >>> be useful on very small devices... >>> >>> These are good discussions to have, and I appreciate your >>> bringing these topics up in the hash-forum list. I agree >>> with many of the points you brought up. >>> >>> >>> Cheers, >>> Ron Rivest >>> >>> >>> On 12/14/2008 3:18 PM, Bill Burr wrote: >>>> Bob, >>>> >>>> We're trying to listen to what everybody says, before forming >>>> NIST's opinion about the relative importance of micro-controllers with >>> limited >>>> memory, versus 1001 other trade-offs. It's just too soon for us to do >>> >>>> that. >>>> >>>> In the end, we're going to want something that is a good substitute >>> for >>>> the SHA-2s in all of their major applications, but is significantly >>>> better than SHA-2 in some significant respects. Unless the SHA-2s >>>> be "significantly" broken it's going to be very hard to force >>>> products to >>> >>>> change to SHA-3, or even implement SHA-3, if SHA-3 has few significant >>> >>>> practical advantages. >>>> >>>> To steal a phrase from Bruce Schneier's talk at the final AES >>>> conference, we're probably going to pick a SHA-3 that doesn't "suck at >>> >>>> anything," or at least anything apparently very significant. And >>>> to pick a SHA-3 that is better than SHA-2 at several things. I >>>> think we did about that when we selected Rijndael to be the AES, >>>> although TDES was easier to improve on than the SHA2's are. The >>>> SHA-2s, I think, set >>> a >>>> reasonably high bar. It's worth remembering, in this respect, >>> however, >>>> that TDES is not without its virtues: it's pretty efficient in >>> hardware. >>>> I'll point one other related trade-off I think I see here. The SHA-2s >>> >>>> give us two different pipe widths. Is it better to do this, or have >>> one >>>> compromise pipe width for all 4 output sizes, that perhaps is a little >>> >>>> narrower than ideal for the 512-bit output? >>>> At this point it's not clear to me (as distinct from the rest of >>>> the folks in my group, who I haven't discussed this with very much >>>> at this >>> >>>> point) that we often ask low-end micro controllers to generate >>>> collision free hashes. I suppose that there will always be >>> applications >>>> for low end processors with very little RAM, but will those often >>>> require collision free hashes? And we seem to get more and more >>>> powerful processors with more and more memory into smaller and smaller >>> >>>> packages. It also seems to me that there are more efficient ways >>>> to address MACs in micro controllers, than HMAC. So, if HMAC be >>>> the main >>> >>>> application for hash functions in micro controllers, then maybe low >>> end >>>> micro controllers would not be a major concern for SHA-3. But I >>> remain >>>> open to arguments to the contrary. And I'm pretty sure we'll wind >>>> up with several second round candidate algorithms with narrow-pipe >>> designs, >>>> as well as several wider pipe designs. >>>> >>>> Regards, >>>> >>>> Bill Burr >>>> >>>> >>>> >>>> >>>> >>>> Bob Hattersley wrote: >>>>> A somewhat intemperate post perhaps, but there's an interesting >>>>> question in >>>>> there. Waterfall would be a 6x design in this classification and >>>>> therefore >>>>> a "monster". (Since I have no desire to make anyone ill, I recommend >>> >>>>> that >>>>> sensitive souls should avoid any further contact with it.) I >>>>> worked under >>>>> the (possibly invalid) assumption that 512 bytes of RAM (and 2kB >>>>> of program >>>>> storage) was a reasonable target. 1kB RAM seems to be widely used >>> today, >>>>> and memory doesn't seem to be getting more expensive. Most >>>>> microcontrollers >>>>> are not used in situations where cryptography has any relevance. >>>>> >>>>> But what is the general opinion? Perhaps more important - what is >>> NIST's >>>>> view? >>>>> >>>>> Bob Hattersley (Waterfall) >>>>> >>>>> -----Original Message----- >>>>> From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of >>> Sean >>>>> O'Neil >>>>> Sent: 13 December 2008 06:27 >>>>> To: Multiple recipients of list >>>>> Subject: Narrow-pipe designs >>>>> >>>>> >>>>> A number of people are asking a good question: >>>>> >>>>> Can someone please publish a paper listing all the narrow-pipe hashes >>> as >>>>> broken by design, so we could all focus on the good ones with 2x and >>>>> slightly larger states? >>>>> >>>>> <2x is vulnerable by design, >=2x up to 2.5x (or possibly up to 3x) >>> is >>>>> the >>>>> optimal choice, but all the >=4x monsters and some of the designs >>> such as >>>>> Crunch or FSB with their reference code requiring MEGABYTES (!!!) >>>>> of tables >>>>> to function are certainly gone too far. With all due respect to >>> their >>>>> authors, I wouldn't bother looking at those as >>>>> a total waste of time. >>>>> >>>>> Personally, the hash functions with 4x and larger states make me >>> wanna >>>>> puke, >>>>> but technically, they would simply never fit in 128 or >>>>> 256 bytes of RAM of the [yes, very] popular 8-bit microcontrollers >>>>> that may >>>>> want to use some of it for other purposes than merely storing the >>> entire >>>>> hash state with no room left for a single variable. >>>>> >>>>> Best regards, >>>>> Sean O'Neil >>>>> http://www.enrupt.com/ - Raising the bar. >>>>> >>>>> >>>>> >>>>> >>> >> > From hash-forum@nist.gov Mon Dec 15 18:23:15 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBG2NAF7020786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 18:23:11 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBG2MInw028945; Mon, 15 Dec 2008 21:22:22 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBG2LxMX008329; Mon, 15 Dec 2008 21:21:59 -0500 Date: Mon, 15 Dec 2008 21:21:59 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Paul Hoffman To: Multiple recipients of list Subject: RE: Scaling laws, and power usage X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: text/plain; charset="us-ascii" X-To: hash-forum@nist.gov References: <77E8A818-5279-4A62-B253-0FECF60F4596@cryptolib.com> <79B77C4C1E604E45967DBEA02EF6ED94@BobsDell> <4945676C.3050307@nist.gov> <4945E48D.2080407@mit.edu> <5574ACE4ACD88E45A7026FA0E350334B039F53@cleopatra.spyrus.com> <494696CD.2070803@mit.edu> <4946A89E.4010908@nist.gov> <4946F208.1000702@ellipticsemi.com> <5574ACE4ACD88E45A7026FA0E350334B039F71@cleopatra.spyrus.com> In-Reply-To: <5574ACE4ACD88E45A7026FA0E350334B039F71@cleopatra.spyrus.com> Mime-Version: 1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 18:23:12 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 380 At 8:54 PM -0500 12/15/08, Robert Jueneman wrote: >So although I am one that likes to think about hash functions, digital >signatures, encryption, and RNGs being resilient enough to resist >attacks for at least another 100 years, and hopefully longer, these >issues of efficiency and scalability are also important, and hence my >desire for the parametric "knobs" on the algorithms. Note that "knobs" imply a few things: - That we and NIST have evaluated the function at all combination of knob settings. - That we can elucidate the equivalent symmetric key strength of the various combinations of settings so that users who must have a strength of, for example, 128 bits know that a particular combination will get that for them. - If any combination of knobs produces a silly state, we are all sure to see it in the wild, possibly in less than a year after SHA-3 is finished, and that the company that made that setting will blame us, and the press will probably agree. - Going back to the OIDs question, there either needs to be a separate identifier for each combination of knobs, or every system that uses SHA-3 in a signature or even an HMAC will need to understand a more modern ASN.1. These are all arguments for a small number of suites of settings, not knobs. SHA-3 can have underlying knobs that no one touches in public, just as SHA-2 does with "number of rounds", but the definition of SHA-3 should have only suites. Documentation for cryptography that has "only touch the knobs if you know what you are doing" has a long history of failure cases in the real world. --Paul Hoffman, Director --VPN Consortium From hash-forum@nist.gov Mon Dec 15 18:50:49 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBG2ohoD024748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 18:50:45 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBG2o2cF008452; Mon, 15 Dec 2008 21:50:06 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBG2nGxr028153; Mon, 15 Dec 2008 21:49:16 -0500 Date: Mon, 15 Dec 2008 21:49:16 -0500 Message-Id: <494715AB.4000808@connotech.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Thierry Moreau To: Multiple recipients of list Subject: Re: Thoughts on SHA-3 potential applications, esp. for small devices (LONG) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed In-Reply-To: <4946DC7E.4020000@xs4all.nl> References: <77E8A818-5279-4A62-B253-0FECF60F4596@cryptolib.com> <79B77C4C1E604E45967DBEA02EF6ED94@BobsDell> <4945676C.3050307@nist.gov> <4945E48D.2080407@mit.edu> <49467203.8090204@connotech.com> <4946DC7E.4020000@xs4all.nl> MIME-Version: 1.0 X-CC: maarten.bodewes@xs4all.nl X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 18:50:45 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 381 Maarten Bodewes wrote: > Thierry Moreau wrote: > >>RFID electronic travel documents off-load the signature verification to >>the terminal where the traveler identity is verified -- no crypto there, >>not even a (short range radio) link encryption key. This is a 21th >>century design. >> >>[...] > > > Sorry, that is rather wrong. The current ePassports (eMRTD's) using the > Basic Access Control use SHA-1 for key derivation. Basic Access Control > is optional, but I haven't seen a single implementation yet that does > not perform BAC. Furthermore, they also use SHA-1 for the less used > Active Authentication signature, which is used to prove that the chip > itself is genuine. The required signature over the data on the ePassport > is called Passive Authentication (for a good reason) and is indeed > verified by the inspection system. > > Currently there is a European version of Extended Access Control that > uses card verifiable certificates (RSA or ECDSA), using either SHA-1 or > SHA-2. As far as I know, most if not all chips used for this are still > (power efficient) 8-bit processors doing hashes in software. You can > even opt for RSA-PSS in this scheme, requiring even more hashing. I know > of RSA-PSS implementations on smart cards, so even if the main hash is > calculated outside of the smart card, you'll still need to do some hashing. > Yes, you are right and I stand corrected on these facts. But the eMRTD's basic access control requires the terminal (inspection station) to have access to the device's unique symmetric keys, for session key derivation based on SHA-1. From this requirement, even if every implementations has the capability to encrypt the link, the actual usage (e.g. a Mexican citizen boarding a plane at a Middle East airline check-in counter) will often fall back to the plaintext radio link. So, as an (crypto-educated) user, it is uncertain whether the basic access control capability is reassuring at all (i.e. it is not used when most needed). As far as the NIST SHA-3 competition arbitration is concerned, this discussion should highlight the two distinct questions: a) are the low-end *applications* requiring SHA-3 support? b) is it necessary to preserve the low-end *implementations* SHA-1 capability when pushing for a migration to SHA-3? My general feeling is that *implementations* may be designed with SHA-x capability, but the *applications* are seldom benefiting from it. Culprits: power consumption, communications bandwidth, protocol latencies, application-wide key management, unrelated vulnerabilities to side channel eavesdropping, operating costs due to service calls. I don't want to win a point in this discussion - your view is obviously very signeficant. The eMRTD case may be a good example, as you pointed out. My reference is a bit outdated: International Civil Aviation Organization, "PKI for Machine Readable Travel Documents offering ICC Read-Only Access", Version - 1.1, October 01, 2004, (Machine Readable Travel Documents - Technical Report) > > All said, security must come first, since a standardized but broken > algorithm is costly on any architecture. But I'll leave that to the > mathematically well endowed persons on this list... > Agreed. > Regards, > Maarten > Regards, - Thierry Moreau From hash-forum@nist.gov Mon Dec 15 19:04:40 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBG34ZRq026765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 19:04:36 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBG33gG0014380; Mon, 15 Dec 2008 22:03:47 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBG33GhU022945; Mon, 15 Dec 2008 22:03:16 -0500 Date: Mon, 15 Dec 2008 22:03:16 -0500 Message-Id: <5574ACE4ACD88E45A7026FA0E350334B039F75@cleopatra.spyrus.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Robert Jueneman" To: Multiple recipients of list Subject: RE: Scaling laws, and power usage X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit X-To: References: <77E8A818-5279-4A62-B253-0FECF60F4596@cryptolib.com> <79B77C4C1E604E45967DBEA02EF6ED94@BobsDell> <4945676C.3050307@nist.gov> <4945E48D.2080407@mit.edu> <5574ACE4ACD88E45A7026FA0E350334B039F53@cleopatra.spyrus.com> <494696CD.2070803@mit.edu> <4946A89E.4010908@nist.gov> <4946F208.1000702@ellipticsemi.com> <5574ACE4ACD88E45A7026FA0E350334B039F71@cleopatra.spyrus.com> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 19:04:36 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 382 Paul makes an excellent point. And I have sometimes criticized NIST, as well as the IETF, for apparently believing that "the nice thing about standards is that there are so many to choose from." In retrospect, the original NIST publication of an extremely wide set of ECC curve types (prime, binary, and Koblitz) and an even wider selection of key sizes had the effect of significantly retarding, rather than advancing the adoption of ECC technology. Similarly, AES-128 and AES-256 were seen as valuable, and AES-192 has been virtually ignored, as it is not sufficiently fast enough nor secure enough to be worth adopting. So although I believe that "knobs" may be necessary in the algorithm design phases, I agree with Paul that a FEW well chosen suite of parameters rather than a plethora of arbitrary combinations is desirable when we come to the end-game. Bob -----Original Message----- From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Paul Hoffman Sent: Monday, December 15, 2008 6:22 PM To: Multiple recipients of list Subject: RE: Scaling laws, and power usage At 8:54 PM -0500 12/15/08, Robert Jueneman wrote: >So although I am one that likes to think about hash functions, digital >signatures, encryption, and RNGs being resilient enough to resist >attacks for at least another 100 years, and hopefully longer, these >issues of efficiency and scalability are also important, and hence my >desire for the parametric "knobs" on the algorithms. Note that "knobs" imply a few things: - That we and NIST have evaluated the function at all combination of knob settings. - That we can elucidate the equivalent symmetric key strength of the various combinations of settings so that users who must have a strength of, for example, 128 bits know that a particular combination will get that for them. - If any combination of knobs produces a silly state, we are all sure to see it in the wild, possibly in less than a year after SHA-3 is finished, and that the company that made that setting will blame us, and the press will probably agree. - Going back to the OIDs question, there either needs to be a separate identifier for each combination of knobs, or every system that uses SHA-3 in a signature or even an HMAC will need to understand a more modern ASN.1. These are all arguments for a small number of suites of settings, not knobs. SHA-3 can have underlying knobs that no one touches in public, just as SHA-2 does with "number of rounds", but the definition of SHA-3 should have only suites. Documentation for cryptography that has "only touch the knobs if you know what you are doing" has a long history of failure cases in the real world. --Paul Hoffman, Director --VPN Consortium From hash-forum@nist.gov Mon Dec 15 23:48:58 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBG7mpVf026407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 23:48:52 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBG7lIxZ026715; Tue, 16 Dec 2008 02:47:22 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBG7jZGQ007432; Tue, 16 Dec 2008 02:45:35 -0500 Date: Tue, 16 Dec 2008 02:45:35 -0500 Message-Id: <000001c95f51$13b97240$3b2c56c0$@org> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "John Washburn" To: Multiple recipients of list Subject: RE: Scaling laws, and power usage X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Mailer: Microsoft Office Outlook 12.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 In-Reply-To: <5574ACE4ACD88E45A7026FA0E350334B039F71@cleopatra.spyrus.com> References: <77E8A818-5279-4A62-B253-0FECF60F4596@cryptolib.com> <79B77C4C1E604E45967DBEA02EF6ED94@BobsDell> <4945676C.3050307@nist.gov> <4945E48D.2080407@mit.edu> <5574ACE4ACD88E45A7026FA0E350334B039F53@cleopatra.spyrus.com> <494696CD.2070803@mit.edu> <4946A89E.4010908@nist.gov> <4946F208.1000702@ellipticsemi.com> <5574ACE4ACD88E45A7026FA0E350334B039F71@cleopatra.spyrus.com> X-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 23:48:53 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 383 RE: Ultimate computing capacity is limited by the power density that the substrate can sustain. Is then diamond substrate likely in the near future? Diamond can be doped to be either an n or p semiconductor and Apollo diamonds (http://www.apollodiamond.com/) is making diamond disks by continuous vapor deposition (CVD). The impediment seems to be the size of the diamond crystal which can be grown at a single time. Apollo is not to the point of producing 90 mm diameter tubes which are half a meter in length as silicon ingots are. They seem to be getting close though. -----Original Message----- From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Robert Jueneman Sent: Monday, December 15, 2008 7:54 PM To: Multiple recipients of list Subject: RE: Scaling laws, and power usage Thanks to all, and especially Mike, for elucidating some of these issues much more clearly, and probably correctly, than I could have ever done. (The only circuits I ever designed involved triodes, but that experience is no longer relevant!) The conclusion, I think, is that size and power consumption are very important for a very considerable portion of the space in which SHA-3 will be used. And Neils has made a pretty good argument why this is important for even the large host processors as well, for the foreseeable future (whatever that may be, in terms of operating system design.) So although I am one that likes to think about hash functions, digital signatures, encryption, and RNGs being resilient enough to resist attacks for at least another 100 years, and hopefully longer, these issues of efficiency and scalability are also important, and hence my desire for the parametric "knobs" on the algorithms. Bob -----Original Message----- From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Mike Borza Sent: Monday, December 15, 2008 4:19 PM To: Multiple recipients of list Subject: Re: Scaling laws, and power usage This is an area that I have some experience in. The discussion so far is mostly correct, to first order. I don't want this to degrade into a discussion of semiconductor physics so I'll state a highly simplified model for the components of power consumption here, then try to relate that back to the main point in Robert's original post. Power dissipation in CMOS circuit technology (the most common technology at this time, and likely to be so for some time to come) consists of two parts: static and dynamic power. Static power dissipation has for the past several years been largely irrelevant (and is often approximated as zero, as Ron has done); however, as feature sizes continue to scale down static power dissipation becomes an increasingly large fraction of total power dissipation. Dynamic power dissipation is the component most people think about in CMOS circuits, and it is f*C*V^2, where f is the switching (clock) frequency, C is the load capacitance that a gate "sees", and V is the supply voltage. C itself is ideally the capacitance on adjacent cell(s), which is proportional to the square of the feature size, and so does scale down with the square of linewidth reduction with advancing technology. Thus, we've been accustomed to gaining exponential increases in circuit (functional) density with reductions in minimum feature size; simplistically this effect is responsible for Moore's law. However, we're now running into some fundamental physical limits: we haven't hit them yet but we're going to soon enough. Supply voltages now are unable to scale down as quickly as linewidth. Also, as I mentioned static power dissipation due to gate leakage and other effects is an increasing proportion of total consumption and doesn't scale as quickly. Finally, while capacitance ideally scales down in each new technology node, the interconnect between circuit elements is not following that trend at the same rate, resulting in more dissipation than predicted by simple technology scaling. This is why power dissipation has not kept pace with logic density. Ultimate computing capacity is limited by the power density that the substrate can sustain. This in turn limits the maximum frequency and density that circuits can be designed for and therefore the maximum throughput (or minimum area). What does this mean for selecting a hash algorithm? First, it is axiomatic that the algorithm ultimately selected must have sufficient security. Without that, there is no reason to implement it, and its efficiency doesn't matter. After that, it should be the most cost effective implementation that satisfies the security requirements. Simplistically, the cost of an implementation (in either dollars or watts) is proportional to the product of its implementation area and the speed that it operates at. What I think Robert, and certainly people like me, would hope to find as a result of this competition is that the cost can be extremely low to justify use of the algorithm in very small implementations. Costly implementation will have large area requirements (for example large intermediate states or static table spaces), or those that produce very small amounts of output per clock cycle. An algorithm that can be predictably tuned in terms of the amount of security provided, the amount of space required, or the speed at which it generates its output will be the most flexible and useful in trading these aspects off, and therefore applicable across a range of applications. While I appreciate the importance of efficient software implementations that run in large CPU environments, most of the people I'm involved with don't deploy their solutions in those environments. They have performance and cost constraints that simply don't fit. As Robert noted, the devices they develop often interoperate with those large software environments. User credentials are an example: these may take the form of smartcards or wirelessly powered RFID tags that authenticate their holders to central servers. Individual users may be able to tolerate modest performance, but a server simultaneously authenticating thousands of those users needs to be capable of accomplishing that in a reasonable time. To give a concrete example, AES is very flexible in its definition and range of implementation possibilities. It has scalable security that imposes a modest penalty to scale up the security. The smallest hardware implementations are about 4K gates running at about 0.1 bits per cycle. Small software implementations fit in a few hundreds bytes of code, and it runs acceptably in 8 bit processors, which are still today shockingly popular in new designs. From there, it is possible today to scale the same algorithm up to a single implementation capable of 128 bits per cycle at, say, 500 MHz in about 300K gates. That's a range from a few 10's or 100's of kilobits per second to about 64 gigabits per second, and all at a security level of at least 128 bits. Instantaneous power consumption to accomplish this ranges from microwatts to a few watts, which as Bill notes is well down from what it was just a few years ago. Neither of those extrema has a place in a CPU today nor for the forseeable future. But note that we'll bottom out the gains we can make in traditional semiconductor technology in the next fewyears. Any replacement technologies will face similar ultimate limits, some at admittedly much higher levels of performance, smaller volume requirements or lower power consumption. This is the kind of flexibility I would like to see in the ultimate hash competition selection. Best regards, Mike Borza On 15/12/08 01:58 PM, Bill Burr wrote: > > Ron & Bob, > > I don't claim any particular VLSI expertise, but my understanding is > that transistors only consume much power when they are actually > switching, that is P=I*V, and when a transistor is in the either the > on or the off state, either I or V is close to zero. So when you > crank up the clock you almost always increase poser consumption. > Moreover you are charging and discharging capacitors more, and that > means current is flowing, and current flowing tends to mean power is > being consumed. Also smaller transistors generally means lower > voltages, and smaller currents, while power is proportional to both > V^2 and I^2. In principle I think you naturally reduce power > consumption per computation as you shrink dimensions, but of course, > you increase overall power consumption as you increase clock rates. > > Of course, as soon as you have to drive an external lead off the chip, > you're back to dealing with higher voltages, and more current. > > We know that power consumption per unit of computation has gone down > greatly as we've crammed more and more gates into less and less > area. I just bought a little netbook with an Intel Atom processor. > It has a 1.6 GHz clock, and burns very little power, yet it's surely > computationally more powerful than the early Pentiums of not so long > ago, which ran hot enough to fry eggs. Maybe reducing power > consumption hasn't kept pace with the exponent of Moore's Law for > semiconductors, but if power consumption is pretty much the limiting > factor today, then our ability to limit power consumption (or to carry > the heat away) must be largely the limiting factor in Moore's Law, at > least if you think of Moore's law in terms of computing power per > Dollar, I think. > > Regards, > > Bill > > Ronald L. Rivest wrote: >> >> Hi Bob -- >> >> Good comments! >> >> With respect to scaling however, my understanding is >> that scaling *can* improve power usage. If you >> decrease dimensions by a factor of two in both x and >> y dimensions, then all capacitances decrease by a factor >> of four, and power usage improves, since it takes less >> current to change the state of a capacitor. This is >> assuming you don't also change the clock rate or voltage. If >> you increase the frequency by a factor of four, you get >> the same current draw, but to increase frequency you >> need to increase voltage inside the chip to get things >> to happen faster. So power usage tends to go up. >> Scaling is complicated, but the increased freedom of >> using smaller features on a chip can yield improved >> power usage, if you don't muck with the clock rate and/or >> voltage at the same time... >> >> (The above analysis is quite simplistic and naive; for the >> truth someone with stronger VLSI expertise should advise >> us...) >> >> Cheers, >> Ron >> >> On 12/15/2008 12:19 PM, Robert Jueneman wrote: >>> Ron and Bill, >>> >>> I don't have a dog in this fight, but I'd like to comment on the size >>> issue, since SPYRUS is involved in both the low-cost, low-power, >>> bandwidth-constrained smartcard end of the spectrum and the relatively >>> unconstrained HSM and/or host-based processing system at the other. >>> >>> For interoperability, it is essential that we have an efficient >>> algorithm that can run in both spaces. >>> >>> I also agree with the need for multi-purpose algorithms -- we were the >>> first and perhaps still one of the few organizations to use HASH_DRBG >>> from SP 800-90 for random number generation. (Somehow, using AES to >>> generate keys to be used for AES seemed like putting too many eggs in >>> one basket, especially when you think about SPA and DPA attacks.) >>> >>> With regard to hashing vs. digital signatures on a chip, the issue is >>> more likely going to be bandwidth rather than processing power, as >>> smart >>> cards normally support only the IOS 7816 interface -- maybe 100 kbps at >>> best. Our smart cards have no difficultly computing ECDSA, EC-DH, and >>> ECMQV for P-256, P-384, and P-521, and the code size constraint isn't >>> much of a limitation -- the code will fit comfortably into ROM or >>> EEPROM, as required. But don't expect it to be done in a millisecond. >>> >>> In that regard, it is important to remember that although Moore's Law >>> predicts ever-increasing transistor density, and that generally >>> translates into increased speed and what I will call agility >>> (parallelism, redundant implementations, etc.), there is one thing that >>> Moore's law does NOT provide, and that is the increased power required >>> to operate these devices. I'm certainly not a semi-conductor >>> physicist, >>> but I don't recall reading anything about reducing the power >>> required to >>> flip a bit in a transistor. And the faster you want to do that, the >>> more electrical power it takes. >>> >>> So when you start talking about nano-processors, that is likely to be >>> the limiting factor. And where that shows up in today's market is with >>> respect very low cost, very low power RFID chips. >>> >>> In that market, I expect that a keyed hash will continue to be very >>> important as an alternative to the slower digital signatures of >>> comparable strength. Maybe not HMAC -- no disrespect to Hugo, but I >>> would like to see a keyed MAC algorithm devised that is less >>> computationally intensive -- but surely something along those lines. >>> >>> On the other hand, if we aren't talking about creating hashes and >>> digital signatures that will be sufficiently robust to resist >>> cryptanalytic attacks for hundreds of years or more, but only need to >>> survive a couple of years against modest attacker resources, then a >>> 512-bit algorithm may be overkill, and 128-bits may even be sufficient. >>> >>> I guess I'm arguing for algorithms with "knobs" that can be used to >>> easily tune the performance characteristics as required, while still >>> providing interoperability. >>> >>> Regards, >>> >>> Bob >>> >>> Robert R. Jueneman >>> Chief Scientist >>> SPYYRUS, Inc. >>> >>> -----Original Message----- >>> From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of >>> Ronald L. Rivest >>> Sent: Sunday, December 14, 2008 9:07 PM >>> To: Multiple recipients of list >>> Subject: Thoughts on SHA-3 potential applications, esp. for small >>> devices (LONG) >>> >>> >>> Hi Bill -- >>> >>> I appreciate your thoughtful essays... >>> >>> There are indeed a lot of dimensions and tradeoffs to >>> consider for the SHA-3 competition. >>> >>> If we think about why one wants a hash standard, four >>> reasons come to mind (in no particular order): >>> >>> (1) A standard promotes and facilitates _interoperability_ >>> between products produced by different organizations. >>> >>> (2) A standard will have been thoroughly evaluated for >>> cryptographic strength. >>> >>> (3) A standard will be accompanied by a multitude of >>> well-engineered and tested implementations for various >>> platforms. >>> >>> (4) A standard, by being a standard, facilitates decision-making >>> by organizations that are too risk-averse and non-technical >>> to make a decision in the absence of a standard. >>> >>> For a hash function, I suspect that the main use for interoperability >>> between products of different organizations will probably continue >>> to be as a component of digital signatures. >>> >>> I do wonder, as you do, what the real needs will be for cryptographic >>> primitives on various platforms, as time goes forward. The future, >>> as usual, is not always predictable. >>> >>> The needs of very small devices are perhaps the most interesting >>> question to consider. >>> >>> Devices that are already sufficiently powerful to compute public-key >>> digital signatures are presumably going to be big enough to easily >>> accommodate any sort of reasonable hash function as well. >>> >>> I think that devices that are too small to perform a public-key >>> digital signature will frequently nonetheless have a requirement >>> to authenticate themselves---to perform a MAC. (As you said.) >>> >>> But the requirements for MAC's are different (and in many ways >>> simpler) than those for hash functions. We care about forgery >>> rather than collision resistance, MAC outputs can be shorter than >>> hash function outputs, etc. I feel it would be a bit strange to >>> let the hash function competition be driven by the expectation >>> that, for small devices, there is a need to utilize the SHA-3 >>> hash function to produce MAC's. >>> >>> If the world is going to be filled up with tiny devices that >>> need to authenticate themselves, then there is a clear need for >>> an appropriate MAC standard. The SHA-3 competition was not set up >>> to produce such a standard; it merely noted that suitability for >>> use in HMAC was a SHA-3 requirement. It would probably be a >>> mistake for the world to conclude that NIST feels that all small >>> devices should be using HMAC as an authentication technology, >>> when there are likely to be much better alternatives for small >>> devices. (Perhaps down the road NIST would enjoy running a >>> "nano-MAC" standards competition!) >>> >>> I also suspect that in the world of very small devices, almost >>> all system designs will be proprietary and closed. Think for >>> example of mass transit card systems or building access cards. >>> There is no need for small devices in these systems to work >>> "outside the system". The need for interoperability through >>> an open standard is not wanted (indeed, it may be very much >>> undesired). Thus, for very small devices the need for a standard >>> in order to support interoperability may be small or absent. >>> >>> Of course, there may be exceptions, and who knows what future >>> systems will need. >>> >>> But I find it hard to think of applications for hashing for >>> very small devices where: >>> -- the device is too small for public-key operations >>> -- the hash function is not being used for a MAC >>> >>> To see why, note that abstractly, a hash value is often used as >>> a "proxy" for the value being hashed. Its shorter length may be >>> better suited for computation (as for a digital signature) or >>> for communication (e.g. for the hash of a message being transmitted >>> by a different channel, or at a different time). >>> >>> But very small devices don't have more than one communication channel, >>> and they don't have much storage, so applications that send a hash >>> value from a small device, so that it can later send the real message, >>> seem dubious (it requires storage). Applications that send the hash >>> so that the real message can be sent via another channel may also be >>> rare, since the device doesn't have more than one channel. >>> >>> It isn't very clear to me what utility a "hash value as a proxy >>> for a message" philosophy has for very small devices. >>> >>> Finally, a hash value can be appended to a message for transmission, >>> but if one merely wants redundancy it can be done in better ways. >>> (Keyed redundancy is different, but that is what a MAC gives.) >>> >>> I suspect that the world will indeed be filled with lots of >>> fascinating small electronic devices, but I think that if they >>> do crypto, it will almost certainly be MAC's or digital signatures. >>> It is unlikely to be unkeyed hash function application. >>> >>> Perhaps I've overlooked something important, but I'm far from >>> persuaded that the SHA-3 standard will be very relevant for >>> very small devices, until you get up to size where the device >>> is capable of performing public-key digital signatures. Then >>> it will become relevant. But at that point, we've got fairly >>> substantial resources already devoted to doing crypto, and one >>> should be considering the digital signature operation as a whole; >>> the hash function implementation may be a small piece of that whole. >>> >>> And of course, Moore's Law hasn't quite died yet, and transistors >>> continue to shrink. For small devices, at some point the cost of >>> bonding and packaging them should greatly exceed the cost of >>> producing the chip. (Perhaps we are there already...) >>> >>> Perhaps others on this list have thoughts on how SHA-3 might >>> be useful on very small devices... >>> >>> These are good discussions to have, and I appreciate your >>> bringing these topics up in the hash-forum list. I agree >>> with many of the points you brought up. >>> >>> >>> Cheers, >>> Ron Rivest >>> >>> >>> On 12/14/2008 3:18 PM, Bill Burr wrote: >>>> Bob, >>>> >>>> We're trying to listen to what everybody says, before forming >>>> NIST's opinion about the relative importance of micro-controllers with >>> limited >>>> memory, versus 1001 other trade-offs. It's just too soon for us to do >>> >>>> that. >>>> >>>> In the end, we're going to want something that is a good substitute >>> for >>>> the SHA-2s in all of their major applications, but is significantly >>>> better than SHA-2 in some significant respects. Unless the SHA-2s >>>> be "significantly" broken it's going to be very hard to force >>>> products to >>> >>>> change to SHA-3, or even implement SHA-3, if SHA-3 has few significant >>> >>>> practical advantages. >>>> >>>> To steal a phrase from Bruce Schneier's talk at the final AES >>>> conference, we're probably going to pick a SHA-3 that doesn't "suck at >>> >>>> anything," or at least anything apparently very significant. And >>>> to pick a SHA-3 that is better than SHA-2 at several things. I >>>> think we did about that when we selected Rijndael to be the AES, >>>> although TDES was easier to improve on than the SHA2's are. The >>>> SHA-2s, I think, set >>> a >>>> reasonably high bar. It's worth remembering, in this respect, >>> however, >>>> that TDES is not without its virtues: it's pretty efficient in >>> hardware. >>>> I'll point one other related trade-off I think I see here. The SHA-2s >>> >>>> give us two different pipe widths. Is it better to do this, or have >>> one >>>> compromise pipe width for all 4 output sizes, that perhaps is a little >>> >>>> narrower than ideal for the 512-bit output? >>>> At this point it's not clear to me (as distinct from the rest of >>>> the folks in my group, who I haven't discussed this with very much >>>> at this >>> >>>> point) that we often ask low-end micro controllers to generate >>>> collision free hashes. I suppose that there will always be >>> applications >>>> for low end processors with very little RAM, but will those often >>>> require collision free hashes? And we seem to get more and more >>>> powerful processors with more and more memory into smaller and smaller >>> >>>> packages. It also seems to me that there are more efficient ways >>>> to address MACs in micro controllers, than HMAC. So, if HMAC be >>>> the main >>> >>>> application for hash functions in micro controllers, then maybe low >>> end >>>> micro controllers would not be a major concern for SHA-3. But I >>> remain >>>> open to arguments to the contrary. And I'm pretty sure we'll wind >>>> up with several second round candidate algorithms with narrow-pipe >>> designs, >>>> as well as several wider pipe designs. >>>> >>>> Regards, >>>> >>>> Bill Burr >>>> >>>> >>>> >>>> >>>> >>>> Bob Hattersley wrote: >>>>> A somewhat intemperate post perhaps, but there's an interesting >>>>> question in >>>>> there. Waterfall would be a 6x design in this classification and >>>>> therefore >>>>> a "monster". (Since I have no desire to make anyone ill, I recommend >>> >>>>> that >>>>> sensitive souls should avoid any further contact with it.) I >>>>> worked under >>>>> the (possibly invalid) assumption that 512 bytes of RAM (and 2kB >>>>> of program >>>>> storage) was a reasonable target. 1kB RAM seems to be widely used >>> today, >>>>> and memory doesn't seem to be getting more expensive. Most >>>>> microcontrollers >>>>> are not used in situations where cryptography has any relevance. >>>>> >>>>> But what is the general opinion? Perhaps more important - what is >>> NIST's >>>>> view? >>>>> >>>>> Bob Hattersley (Waterfall) >>>>> >>>>> -----Original Message----- >>>>> From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of >>> Sean >>>>> O'Neil >>>>> Sent: 13 December 2008 06:27 >>>>> To: Multiple recipients of list >>>>> Subject: Narrow-pipe designs >>>>> >>>>> >>>>> A number of people are asking a good question: >>>>> >>>>> Can someone please publish a paper listing all the narrow-pipe hashes >>> as >>>>> broken by design, so we could all focus on the good ones with 2x and >>>>> slightly larger states? >>>>> >>>>> <2x is vulnerable by design, >=2x up to 2.5x (or possibly up to 3x) >>> is >>>>> the >>>>> optimal choice, but all the >=4x monsters and some of the designs >>> such as >>>>> Crunch or FSB with their reference code requiring MEGABYTES (!!!) >>>>> of tables >>>>> to function are certainly gone too far. With all due respect to >>> their >>>>> authors, I wouldn't bother looking at those as >>>>> a total waste of time. >>>>> >>>>> Personally, the hash functions with 4x and larger states make me >>> wanna >>>>> puke, >>>>> but technically, they would simply never fit in 128 or >>>>> 256 bytes of RAM of the [yes, very] popular 8-bit microcontrollers >>>>> that may >>>>> want to use some of it for other purposes than merely storing the >>> entire >>>>> hash state with no room left for a single variable. >>>>> >>>>> Best regards, >>>>> Sean O'Neil >>>>> http://www.enrupt.com/ - Raising the bar. >>>>> >>>>> >>>>> >>>>> >>> >> > No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.9.18/1850 - Release Date: 12/15/2008 5:04 PM From hash-forum@nist.gov Mon Dec 15 23:58:59 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBG7ws3H027818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Dec 2008 23:58:55 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBG7lP54008854; Tue, 16 Dec 2008 02:47:29 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBG7lDDu010131; Tue, 16 Dec 2008 02:47:13 -0500 Date: Tue, 16 Dec 2008 02:47:13 -0500 Message-Id: <20081216075000.75654.qmail@cr.yp.to> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "D. J. Bernstein" To: Multiple recipients of list Subject: How will NIST handle the tunable security parameter? X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas In-Reply-To: <49467AB0.1070505@nist.gov> X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 15 Dec 2008 23:58:55 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 384 Bill Burr writes: > Maybe a few submissions are just so slow that can tell that we just > couldn't live with them. MD6-512, with the full 168 rounds recommended in the MD6 submission, runs at a whopping 52 cycles/byte on the 64-bit reference platform, vastly slower than SHA-512. Suppose that this cost turns out to be above your tolerance level. It's easy to imagine how this could happen: you said that NIST expects "significantly improved efficiency" compared to SHA-2; maybe you'll accept Niels's argument that parallelizability doesn't adequately compensate for poor single-core performance; or maybe you'll have some other reason for deciding that MD6-512-168 is too slow. Yes or no: Will you then throw away the _entire_ MD6 submission? In the submission requirements you said that submissions were allowed to have a tunable security parameter to "allow the selection of a range of possible security/performance tradeoffs." The MD6 submission does this, offering a wide range of security/performance tradeoffs. The 168 rounds recommended for MD6-512 are almost _ten times as many rounds_ as have been broken---after tons of cryptanalysis, probably more than any of the other candidates so far. If you decide to throw away MD6 on the basis of the performance of the recommended number of rounds, are you going to throw away all of the reduced-round variants too, ignoring their speed? If NIST had set clear performance requirements at the beginning then the MD6 designers could, and obviously would, have limited their round counts accordingly. Instead NIST allowed, and even seemed to encourage, more flexibility; MD6 supports a wide range of security/performance tradeoffs, including much more conservative possibilities than (e.g.) Skein. Is NIST going to retroactively punish MD6 for this flexibility? > we're still looking for a pretty efficient trade-off > of memory, cycles and gates Naturally. If the most efficient unbroken member of the MD6 family is still too slow (or too big) for many users, while another unbroken hash function meets those users' performance requirements, then MD6 probably isn't the best choice for a standard. But maybe the situation is exactly reversed! Maybe MD6 offers the best security/performance tradeoff out of all the submissions. Maybe 24-round MD6, running at a quite reasonable 7 cycles/byte, will remain untouched while every other fast hash function is broken. I think that there's a noticeable risk that ignoring reduced-round MD6 means ignoring the best submitted SHA-3 candidate---and a quite large risk that ignoring _all_ of the reduced-round candidates, as Niels is doing, means ignoring the best submitted SHA-3 candidate. I hope that NIST isn't so sloppy. > In fact I'll go so far as to say that until we get to the final round, > we won't be particularly confident that we know about how many rounds > people are going to be able to analyze. That makes it a bit hard to > normalize performance by some notion of safety margin. I'm not talking about any sort of abstract normalization. Real-world Core 2 benchmarks will show that (for example) 24-round MD6 runs at about the same speed as Skein. The question is whether NIST is going to use Rivest's conservative recommendation of 168-round MD6 as an excuse to disregard 24-round MD6. I agree that comparing nonzero confidence levels isn't easy. This is true whether we're talking about 24-round MD6, Skein, 168-round MD6, or something else. > When Larry ran CubeHash he said, "boy that's a slow one." There are two big problems here: * Larry is benchmarking only the most conservative function, namely CubeHash8/1, and completely ignoring the implementations of CubeHash8/2, CubeHash8/4, etc. that were also included in the submission. * Larry is benchmarking code that was forced to be written in an extremely conservative way to avoid the risk of compilation failures---NIST is using an unpublished test framework on a proprietary platform, making tests difficult for everyone else. Since CubeHash offers an extremely wide range of security/performance tradeoffs, and can benefit tremendously in speed from widely available vector instructions, both of these problems are quite severe; it's hardly a surprise that Larry hasn't seen how fast CubeHash can be. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago From hash-forum@nist.gov Tue Dec 16 01:36:53 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBG9al8e012689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 16 Dec 2008 01:36:49 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBG9ZRpT022488; Tue, 16 Dec 2008 04:35:31 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBG9YgdF024483; Tue, 16 Dec 2008 04:34:42 -0500 Date: Tue, 16 Dec 2008 04:34:42 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Stefan.Lucks@uni-weimar.de To: Multiple recipients of list Subject: Re: How will NIST handle the tunable security parameter? X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: TEXT/PLAIN; charset=US-ASCII MIME-Version: 1.0 References: <20081216075000.75654.qmail@cr.yp.to> In-Reply-To: <20081216075000.75654.qmail@cr.yp.to> X-To: Multiple recipients of list X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 16 Dec 2008 01:36:49 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 385 On Tue, 16 Dec 2008, D. J. Bernstein wrote: > [...] I think that there's a > noticeable risk that ignoring reduced-round MD6 means ignoring the best > submitted SHA-3 candidate---and a quite large risk that ignoring _all_ > of the reduced-round candidates, as Niels is doing, means ignoring the > best submitted SHA-3 candidate. I hope that NIST isn't so sloppy. Not considering reduced-rounds candidates isn't sloppy, it is reasonable! The particular choice of defaults for the security parameters reflects the designers' confidence into their creations. How could the general public gain confidence into a version of a hash function, if the designers of that hash function don't have that confidence? Of course, NIST could (theoretically) select a SHA-3 standard with lower(*) security parameters than recommended by the designers. But such a choice would undermine the credibility of SHA-3 from the beginning! At the third AES conference, *all* the finalist's designers where explicitely asked if they would change their proposed number of rounds. None of them did. (I remember people in the audience, who actually made the request to increase the number of rounds for Rijndael, and others, who actually asked for Serpent with a reduced number of rounds.) I anticipate NIST to allow the designers of SHA-3 candidates to change the security parameters at some point of time. Perhaps, unlike the case of the AES, some SHA-3 candidate designers will take that chance. But as great as tweakable security parameters for symmetric crypto primitives are, defining their defaults is part of the design, and it is the desingers's duty. So long Stefan ------- (*) By "lower" I mean "less secure and faster". This doesn't need to reflect the numerical value of a security parameter. CubeHash, e.g., has two security parameters, the number r of rounds and the number b of bytes to be mixed in every r rounds. "Lower" could imply smaller r or larger b, or any change of r and b to improve the currently poor performance of CubeHash. -- ------ Stefan Lucks -- Bauhaus-University Weimar -- Germany ------ Stefan dot Lucks at uni minus weimar dot de ------ I love the taste of Cryptanalysis in the morning! ------ From hash-forum@nist.gov Tue Dec 16 03:53:00 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBGBqtLk000362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 16 Dec 2008 03:52:56 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBGBpKBD031864; Tue, 16 Dec 2008 06:51:24 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBGBnqYj023165; Tue, 16 Dec 2008 06:49:52 -0500 Date: Tue, 16 Dec 2008 06:49:52 -0500 Message-Id: <0F627D67EE858D44BD1CEFEA67183F18072CE931@CNSCNEVS03.ap.sony.com> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: "Li, Ji" To: Multiple recipients of list Subject: Collision attack on NaSHA-512 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-To: References: <0F627D67EE858D44BD1CEFEA67183F180717BDBD@CNSCNEVS03.ap.sony.com> Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C95F74.098EAAC0" MIME-Version: 1.0 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 16 Dec 2008 03:52:56 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED,TRACKER_ID shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 386 This is a multi-part message in MIME format. ------_=_NextPart_001_01C95F74.098EAAC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, =20 1. We have found a collision attack on NaSHA-(512,k,6) with complexity of 2^192. The document will appear later. =20 2. The same method can be used to construct free-start collision on any version of NaSHA-(m,k,6) with trivial complexity.=20 =20 3. We find a mistype on the reference code, which is not consistent with specification. In line 460 of Nasha.C: =20 (In the function: HashReturn Nasha512_Update(hashState512 *state, const BitSequence *data, DataLength databitlen)) (line 460) ---- while (len>(Nasha512_BLOCK_SIZE*8)){ Should be while (len>=3D(Nasha512_BLOCK_SIZE*8)){ =20 Thanks for kindly comments and discussion from Prof. Smile Markovski. =20 P.S. example for free start collision =20 NaSHA-(256,2,6): M0: (length: 512 bits) ffffffff0000000000000080ffffffff0514ff7fffffff7fffffffff0000000000000080 ffffffff000000000000000000000000000000000000000000000000 =20 IV0: 0x7fffffff7fff1405, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x00000000ffffffff, 0x80000000ffff1405, 0x0000000000000000, 0x0000000000000000, =20 M1: (length: 512 bits) 000000000000000000000080ffffffff0514ff7fffffff7f000000000000000000000080 ffffffffffffffff0000000000000000000000000000000000000000 IV1: 0x7fffffff8000ebfa, 0x0000000000000000, 0x0000000000000000, 0x00000000ffffffff, 0x0000000000000000, 0x80000000ffff1405, 0x0000000000000000, 0x0000000000000000, Free-start collision digest is ( NaSHA-(256,2,6)(M0,IV0) =3D NaSHA-(256,2,6)(M1,IV1) ): d96e238f061ced9ab4fc687c33875efd29ec5def0dc7173e61c852b21967f58b =20 NaSHA-(512,2,6): M0: (length: 1024bits) 000000000000000000000080ffffffff0514ff7fffffff7f0000000000000000ffffffff 00000000000000000000000000000000000000000000000000000000 00000080ffffffffffffffff000000000000000000000000ffffffff0000000000000000 00000000ffffffff000000000514ff7fffffff7f00000080ffffffff =20 IV0: 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x00000000ffffffff, 0xffffffff80000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x00000000ffffffff, 0xffffffff80000000, 0x7fffffff8000ebfa, 0xffffffff80000000, 0x00000000ffffffff, 0xffffffff80000000, 0x7fffffff7fff1405, 0x00000000ffffffff, =20 M1: (length: 1024 bits) ffffffff0000000000000080ffffffff0514ff7fffffff7f000000000000000000000000 0000000000000000000000000000000000000000ffffffff00000000 00000080ffffffff00000000000000000000000000000000000000000000000000000000 000000000000000000000000faeb0080ffffff7f00000080ffffffff =20 IV1: 0x00000000ffffffff, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0xffffffff80000000, 0x0000000000000000, 0x0000000000000000, 0x00000000ffffffff, 0x0000000000000000, 0xffffffff80000000, 0x7fffffff7fff1405, 0xffffffff80000000, 0x0000000000000000, 0xffffffff80000000, 0x7fffffff8000ebfa, 0x0000000000000000, =20 Free-start collision digest is ( NaSHA-(512,2,6)(M0,IV0) =3D NaSHA-(512,2,6)(M1,IV1) ): 9401156aaa365b353fb7b3fd8a7d4ca944f4ba788c7fcfadbe1411e4adcbebd9 ecb7ecf86528134a30c639fb083ec658782d9fbfe730051e15458227e96c3dcf =20 We get the digest of NaSHA-(512,2,6) by correcting this mistype in the reference implementation. With the unrevised implementation, free start collision can be got by following message pair with the same IVs.=20 M0: (length: 1024+64bits) 000000000000000000000080ffffffff0514ff7fffffff7f0000000000000000ffffffff 00000000000000000000000000000000000000000000000000000000 00000080ffffffffffffffff000000000000000000000000ffffffff0000000000000000 00000000ffffffff000000000514ff7fffffff7f00000080ffffffff0000000000000000 =20 M1: (length: 1024 +64bits) ffffffff0000000000000080ffffffff0514ff7fffffff7f000000000000000000000000 0000000000000000000000000000000000000000ffffffff00000000 00000080ffffffff00000000000000000000000000000000000000000000000000000000 000000000000000000000000faeb0080ffffff7f00000080ffffffff0000000000000000 =20 =20 Li Ji, Xu Liangyu and Guan Xu Sony China Research Laboratory, Sony (China) Limited =20 ------_=_NextPart_001_01C95F74.098EAAC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

1. We have found a collision attack on = NaSHA-(512,k,6) with complexity of 2^192.

The document = will appear later.

 

2. The same method can be used to construct = free-start collision on any version of NaSHA-(m,k,6) with trivial complexity. =

 

3. We find a mistype on the reference code, = which is not consistent with specification.

In line 460 of Nasha.C:   =

        =  (In the function: HashReturn Nasha512_Update(hashState512 *state, = const BitSequence *data, DataLength databitlen))

(line 460) ---- while (len>(Nasha512_BLOCK_SIZE*8)){

Should be      while (len>=3D(Nasha512_BLOCK_SIZE*8)){

 

Thanks for kindly comments and discussion from = Prof. Smile Markovski.

 

P.S.  example for free start = collision

 

NaSHA-(256,2,6):

M0: (length: 512 = bits)

ffffffff0000000000000080ffffffff0514ff7fffffff7f= ffffffff0000000000000080ffffffff00000000000000000000000000000000000000000= 0000000

 

IV0:

0x7fffffff7fff1405, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000,

0x00000000ffffffff, 0x80000000ffff1405, 0x0000000000000000, 0x0000000000000000,

 

M1: (length: 512 = bits)

000000000000000000000080ffffffff0514ff7fffffff7f= 000000000000000000000080ffffffffffffffff000000000000000000000000000000000= 0000000

IV1:

0x7fffffff8000ebfa, 0x0000000000000000, 0x0000000000000000, 0x00000000ffffffff,

0x0000000000000000, 0x80000000ffff1405, 0x0000000000000000, 0x0000000000000000,

Free-start collision digest is ( = NaSHA-(256,2,6)(M0,IV0) =3D NaSHA-(256,2,6)(M1,IV1) ):

d96e238f061ced9ab4fc687c33875efd29ec5def0dc7173e= 61c852b21967f58b

 

NaSHA-(512,2,6):

M0: (length: = 1024bits)

000000000000000000000080ffffffff0514ff7fffffff7f= 0000000000000000ffffffff0000000000000000000000000000000000000000000000000= 0000000

00000080ffffffffffffffff000000000000000000000000= ffffffff000000000000000000000000ffffffff000000000514ff7fffffff7f00000080f= fffffff

 

IV0:

0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x00000000ffffffff,

0xffffffff80000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000,

0x00000000ffffffff, 0xffffffff80000000, 0x7fffffff8000ebfa, 0xffffffff80000000,

0x00000000ffffffff, 0xffffffff80000000, 0x7fffffff7fff1405, 0x00000000ffffffff,

 

M1: (length: 1024 = bits)

ffffffff0000000000000080ffffffff0514ff7fffffff7f= 0000000000000000000000000000000000000000000000000000000000000000ffffffff0= 0000000

00000080ffffffff00000000000000000000000000000000= 000000000000000000000000000000000000000000000000faeb0080ffffff7f00000080f= fffffff

 

IV1:

0x00000000ffffffff, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000,

0xffffffff80000000, 0x0000000000000000, 0x0000000000000000, 0x00000000ffffffff,

0x0000000000000000, 0xffffffff80000000, 0x7fffffff7fff1405, 0xffffffff80000000,

0x0000000000000000, 0xffffffff80000000, 0x7fffffff8000ebfa, 0x0000000000000000,

 

Free-start collision digest is ( NaSHA-(512,2,6)(M0,IV0) =3D NaSHA-(512,2,6)(M1,IV1) = ):

9401156aaa365b353fb7b3fd8a7d4ca944f4ba788c7fcfad= be1411e4adcbebd9

ecb7ecf86528134a30c639fb083ec658782d9fbfe730051e= 15458227e96c3dcf

 

We get the digest of NaSHA-(512,2,6) by = correcting this mistype in the reference implementation.

With the unrevised implementation, free start = collision can be got by following message pair with the same IVs. =

M0: (length: = 1024+64bits)

000000000000000000000080ffffffff0514ff7fffffff7f= 0000000000000000ffffffff0000000000000000000000000000000000000000000000000= 0000000

00000080ffffffffffffffff000000000000000000000000= ffffffff000000000000000000000000ffffffff000000000514ff7fffffff7f00000080f= fffffff0000000000000000

 

M1: (length: 1024 = +64bits)

ffffffff0000000000000080ffffffff0514ff7fffffff7f= 0000000000000000000000000000000000000000000000000000000000000000ffffffff0= 0000000

00000080ffffffff00000000000000000000000000000000= 000000000000000000000000000000000000000000000000faeb0080ffffff7f00000080f= fffffff0000000000000000

 

 

Li Ji, Xu Liangyu and Guan = Xu

Sony China Research = Laboratory, Sony = (China) = Limited

 

------_=_NextPart_001_01C95F74.098EAAC0-- From hash-forum@nist.gov Tue Dec 16 05:22:08 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBGDLwNk015798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 16 Dec 2008 05:22:00 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBGD96IT012745; Tue, 16 Dec 2008 08:09:11 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBGD89F9013658; Tue, 16 Dec 2008 08:08:09 -0500 Date: Tue, 16 Dec 2008 08:08:09 -0500 Message-Id: Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: yaser esmaeilei To: Multiple recipients of list Subject: OFFICIAL COMMENT: Tangle X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas MIME-Version: 1.0 X-CC: X-To: Content-Type: multipart/mixed; boundary="_03008e4c-c9c1-449e-9e5b-fa660d708205_" X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 16 Dec 2008 05:22:01 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=0.9 required=5.0 tests=BAYES_00,FORGED_HOTMAIL_RCVD2, HTML_EXTRA_CLOSE,HTML_MESSAGE,HTML_OBFUSCATE_20_30,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 387 --_03008e4c-c9c1-449e-9e5b-fa660d708205_ Content-Type: multipart/alternative; boundary="_b2a1db6b-9a2a-47df-9a8b-da2d35223b4e_" --_b2a1db6b-9a2a-47df-9a8b-da2d35223b4e_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: 8bit Hi, I've had some observations on Tangle which can be utilized in the future. Best regards, Yaser Esmaeili Sharif University of Technology, Iran _________________________________________________________________ Connect to the next generation of MSN Messenger  http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline --_b2a1db6b-9a2a-47df-9a8b-da2d35223b4e_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: 8bit Hi,

I've had some observations on Tangle which can be utilized in the future.

Best regards,
Yaser Esmaeili
Sharif University of Technology, Iran
Connect to the next generation of MSN Messenger  Get it now! --_b2a1db6b-9a2a-47df-9a8b-da2d35223b4e_-- --_03008e4c-c9c1-449e-9e5b-fa660d708205_ Content-Type: text/html Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Tangle_Observation.pdf" JVBERi0xLjQNJeLjz9MNCjE5IDAgb2JqIDw8L0xpbmVhcml6ZWQgMS9MIDg4NjU5L08gMjEvRSA2 NjExMS9OIDMvVCA4ODIzMi9IIFsgNzc2IDI1MF0+Pg1lbmRvYmoNICAgICAgICAgICAgICAgICAg DQp4cmVmDQoxOSAyNA0KMDAwMDAwMDAxNiAwMDAwMCBuDQowMDAwMDAxMDI2IDAwMDAwIG4NCjAw MDAwMDExMDYgMDAwMDAgbg0KMDAwMDAwMTI5MSAwMDAwMCBuDQowMDAwMDAxMzk3IDAwMDAwIG4N CjAwMDAwMDE5NTIgMDAwMDAgbg0KMDAwMDAwMjM2NiAwMDAwMCBuDQowMDAwMDAyNjMyIDAwMDAw IG4NCjAwMDAwMDI4ODAgMDAwMDAgbg0KMDAwMDAwMjk1NiAwMDAwMCBuDQowMDAwMDAzNjI3IDAw MDAwIG4NCjAwMDAwMDM3NjYgMDAwMDAgbg0KMDAwMDAwNDA2NSAwMDAwMCBuDQowMDAwMDA0NzA1 IDAwMDAwIG4NCjAwMDAwMDUxODkgMDAwMDAgbg0KMDAwMDAwNTY4NCAwMDAwMCBuDQowMDAwMDA2 MzA3IDAwMDAwIG4NCjAwMDAwMDY4MTcgMDAwMDAgbg0KMDAwMDAwNzMxNyAwMDAwMCBuDQowMDAw MDA3ODA2IDAwMDAwIG4NCjAwMDAwMjE0MzkgMDAwMDAgbg0KMDAwMDAyMTcwNCAwMDAwMCBuDQow MDAwMDIxOTA1IDAwMDAwIG4NCjAwMDAwMDA3NzYgMDAwMDAgbg0KdHJhaWxlcg0KPDwvU2l6ZSA0 My9QcmV2IDg4MjIxL1Jvb3QgMjAgMCBSL0luZm8gMTggMCBSL0lEWzw1NDc0NDc3RUVGQkQ3REEy OTY2RkM5NjhFRTlBRjY5NT48MzZDRUIxNTIxNzQxNjE0Q0I2MEFFNDUyNjVBQ0QyQjc+XT4+DQpz dGFydHhyZWYNCjANCiUlRU9GDQogICAgICAgICAgICAgDQo0MiAwIG9iajw8L0xlbmd0aCAxNjQv RmlsdGVyL0ZsYXRlRGVjb2RlL0kgMTgxL0wgMTY1L1MgOTA+PnN0cmVhbQ0KeNpiYGBgBqIIBlYg KccgwIAAAgwsQFEWBo6JDL/OmzYyMOxrgMpMEXCVXJ1xqmQnS1Lf9QUMDIwSHWCpDiClZNEAUQ0E 3AyMtkxAWhSIJcAiSkBTpzN4MHEy1jC8YLjGoMVUy5DJyMkUx3iI8SyTL+MdxkuMx03lGZ4zLF/T wxDHwMDlDbGSj4HRQxBIg4yzBmIhBsawHUCaEYhfAwQYAJoYIasNCmVuZHN0cmVhbQ1lbmRvYmoN MjAgMCBvYmo8PC9NZXRhZGF0YSAxNyAwIFIvUGFnZXMgMTYgMCBSL1R5cGUvQ2F0YWxvZy9QYWdl TGFiZWxzIDE0IDAgUj4+DWVuZG9iag0yMSAwIG9iajw8L0Nyb3BCb3hbMCAwIDU5NS4yMiA4NDJd L1BhcmVudCAxNiAwIFIvQ29udGVudHNbMjggMCBSIDMxIDAgUiAzMiAwIFIgMzMgMCBSIDM0IDAg UiAzNSAwIFIgMzYgMCBSIDM3IDAgUl0vUm90YXRlIDAvTWVkaWFCb3hbMCAwIDU5NS4yMiA4NDJd L1Jlc291cmNlcyAyMiAwIFIvVHlwZS9QYWdlPj4NZW5kb2JqDTIyIDAgb2JqPDwvRm9udDw8L1RU MSAyOSAwIFIvVFQyIDIzIDAgUi9UVDQgMjQgMCBSPj4vUHJvY1NldFsvUERGL1RleHRdL0V4dEdT dGF0ZTw8L0dTMSAyNyAwIFI+Pj4+DWVuZG9iag0yMyAwIG9iajw8L1N1YnR5cGUvVHJ1ZVR5cGUv Rm9udERlc2NyaXB0b3IgMjUgMCBSL0xhc3RDaGFyIDE1MC9XaWR0aHNbMjUwIDAgNDA4IDAgMCAw IDc3OCAxODAgMzMzIDMzMyAwIDU2NCAyNTAgMzMzIDI1MCAyNzggNTAwIDUwMCA1MDAgNTAwIDUw MCA1MDAgNTAwIDUwMCA1MDAgNTAwIDI3OCAyNzggMCA1NjQgNTY0IDQ0NCA5MjEgNzIyIDY2NyA2 NjcgMCA2MTEgNTU2IDcyMiA3MjIgMzMzIDAgNzIyIDYxMSA4ODkgNzIyIDcyMiAwIDAgNjY3IDU1 NiA2MTEgMCAwIDk0NCA3MjIgNzIyIDYxMSAzMzMgMCAzMzMgMCAwIDAgNDQ0IDUwMCA0NDQgNTAw IDQ0NCAzMzMgNTAwIDUwMCAyNzggMjc4IDUwMCAyNzggNzc4IDUwMCA1MDAgNTAwIDUwMCAzMzMg Mzg5IDI3OCA1MDAgNTAwIDcyMiA1MDAgNTAwIDQ0NCAwIDAgMCAwIDAgMCAwIDAgMCAwIDEwMDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1MDBdL0Jhc2VGb250L0pQR0xCRytUaW1l c05ld1JvbWFuUFNNVC9GaXJzdENoYXIgMzIvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL1R5cGUv Rm9udD4+DWVuZG9iag0yNCAwIG9iajw8L1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0b3Ig MjYgMCBSL0xhc3RDaGFyIDExOC9XaWR0aHNbMjUwIDAgMCAwIDAgMCAwIDAgMCAzMzMgMCAwIDAg MCAyNTAgMCA1MDAgNTAwIDUwMCA1MDAgMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDMzMyAzMzMgMCA1 NzAgMCAwIDAgNzIyIDAgMCAwIDAgMCAwIDAgMzg5IDAgMCAwIDAgNzIyIDAgMCAwIDcyMiA1NTYg NjY3IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDUwMCA1NTYgNDQ0IDU1NiA0NDQgMzMzIDUwMCAw IDI3OCAwIDU1NiAyNzggODMzIDU1NiA1MDAgNTU2IDAgNDQ0IDM4OSAzMzMgNTU2IDUwMF0vQmFz ZUZvbnQvVGltZXNOZXdSb21hblBTLUJvbGRNVC9GaXJzdENoYXIgMzIvRW5jb2RpbmcvV2luQW5z aUVuY29kaW5nL1R5cGUvRm9udD4+DWVuZG9iag0yNSAwIG9iajw8L1N0ZW1WIDgyL0ZvbnROYW1l L0pQR0xCRytUaW1lc05ld1JvbWFuUFNNVC9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udEZpbGUyIDQx IDAgUi9Gb250V2VpZ2h0IDQwMC9GbGFncyAzNC9EZXNjZW50IC0yMTYvRm9udEJCb3hbLTU2OCAt MzA3IDIwMDAgMTAwN10vQXNjZW50IDg5MS9Gb250RmFtaWx5KFRpbWVzIE5ldyBSb21hbikvQ2Fw SGVpZ2h0IDY1Ni9YSGVpZ2h0IC01NDYvVHlwZS9Gb250RGVzY3JpcHRvci9JdGFsaWNBbmdsZSAw Pj4NZW5kb2JqDTI2IDAgb2JqPDwvU3RlbVYgMTM2L0ZvbnROYW1lL1RpbWVzTmV3Um9tYW5QUy1C b2xkTVQvRm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRXZWlnaHQgNzAwL0ZsYWdzIDM0L0Rlc2NlbnQg LTIxNi9Gb250QkJveFstNTU4IC0zMDcgMjAwMCAxMDI2XS9Bc2NlbnQgODkxL0ZvbnRGYW1pbHko VGltZXMgTmV3IFJvbWFuKS9DYXBIZWlnaHQgNjU2L1hIZWlnaHQgLTU0Ni9UeXBlL0ZvbnREZXNj cmlwdG9yL0l0YWxpY0FuZ2xlIDA+Pg1lbmRvYmoNMjcgMCBvYmo8PC9PUE0gMS9PUCBmYWxzZS9v cCBmYWxzZS9UeXBlL0V4dEdTdGF0ZS9TQSBmYWxzZS9TTSAwLjAyPj4NZW5kb2JqDTI4IDAgb2Jq PDwvTGVuZ3RoIDYwMi9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImEk1tv4jAQhd/zK+bR kYprO87tbbsXdbtS+0Kkaov6YIIBb2kcOUlR++t37ATKdhetEGCQ5zvnzEwur+ccNl30uYouq0oA h2odcQEMX/gly5IWkBRUSJZA9Rwx2OC7qv3HPiIQV78izmhZjBXhJEpJS0hKyoqxiHB/Dfly4ifH gnASWJdAnma0FJMMZYzlXmfmj7wIanP7rMEuO+1eVG9s04FtoFLNZqeDkQxtFiXMOOUpE1B9/cvq vzIKjIcmcpHRXJ7Ii6O8P+6jBfmpUBq+dc9xQVQ8y4g2OwNztdNb1RiIH6sfviCVo4VgwLs/mliQ V4+g2iMoQjzg02b6YXa0jiWebDyTZPxzhL63LqUyCfTsGO9jshnPacLScEv6W8cLE4OdAHy65D1o ElrFKdw0vbOrofZt/sBn7+RQk4V4lPEsHTNOEzEdKNiqbgvroRlBrbOt7fQKlq9wtXtRLqRDv0WR 4jAORHkgymwk6rcLuK2vB+M0qGYFD8p3R2CjGJXEKVhc3T6w4hFUD/1WT5OYuH/M4uCWy1KO7Lub eQXfvc0v1lMlaZGKs+2N95xQuLPI7VX9BNbBXqunRnedTwZLrRtwurWux1CdhbVyvndoAtMHF1O3 goHZYa29bqta7S6QBxvzorHYi6dEx36DyLk1329NvYVaNagNQ4/r84bKpgmx13FCczKg/Zz0g9MU Tj2kZx6IM1vxcf2JoPC/B/D8kuRj20Ui+Bj/Pi5P0q4sNLaHpTPN5gBc6a52pg2L44c+dOO2FDQX p9tSTGhRBp/wW4ABAPGrOLwNCmVuZHN0cmVhbQ1lbmRvYmoNMjkgMCBvYmo8PC9TdWJ0eXBlL1R5 cGUwL0Rlc2NlbmRhbnRGb250c1s0MCAwIFJdL0Jhc2VGb250L0pQR0tOSCtUaW1lc05ld1JvbWFu UFNNVC9Ub1VuaWNvZGUgMzAgMCBSL0VuY29kaW5nL0lkZW50aXR5LUgvVHlwZS9Gb250Pj4NZW5k b2JqDTMwIDAgb2JqPDwvTGVuZ3RoIDIzMC9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIlU kM1OxSAQhfc8xSw1LqB4YzRp2Fw3XfgTW91TGCqJBTKli769UOs1LoDMmflmDsPP3WMXfAb+StH0 mMH5YAmXuJJBGHHyARoJ1pt8RPttZp2AF7jfloxzF1yEtmX8rSSXTBtcDUNzI66Bv5BF8mEqykm+ fxSlX1P6whlDBgFKgUXH+PlJp2c9I/Ad/BOHLSHIPW6O2dHikrRB0mFCaIW4d6o8jRsVYLD/80z+ UKMzn5rYb7WUd0KxA2rF7cNJscIeVbVL/eHFlVmJiuF9DbutasgHvGwqxVRn18O+BRgAnFRuXAoN CmVuZHN0cmVhbQ1lbmRvYmoNMzEgMCBvYmo8PC9MZW5ndGggNTcxL0ZpbHRlci9GbGF0ZURlY29k ZT4+c3RyZWFtDQpIiZRUTW/bMAy9+1fwFnmrNUm2ZatoBxQYUGCYd6mBBUtycBI1UdDYQewl2B/Z 760o22mcBgN6sfVBPj4+UpwQDc1aQ11s/ZRKov2A0YhAWTVFY6qyhqJcQv23vZ1XL/agBn+Wf/cC ntJExBBwymPIv3kM8gV+jt6EbP2EpojGqSAlIuklmBImD9lvls5oC/ElzyPgkD97+SePUcZYhBjk Zx/91s83aCVaq4hGMTAXC41TNA765dEjMJ4Sc7OZ+nAPY3RNqEqtAwO34CqiQkAspSXOQsi3Z5yJ QQdGRZIKsKBpohKMRDZ4zoWDsT+urBLSgtjMWAdyYh70SyQz0XRFIUNKXCSOVPaelFCCxh/khFFC lz2xyEN+IbNI6YCfYxU68xmgNZaOycvSEejU7mrC3L10Irir9iA66S+c10Nd/9nusFwX1YqH1VIu LQuIftgj8EM3kI18STl5Eym4UMxtuLKbfwNjd3R/6iPexhSCOikG7XjH+PP864Abo/IquVjxjly1 f8/tc9f5IqWCn8t3rRsnBP0HZLNzqOw/afAIdf5QGi5y3JZk1FU5sp1wvcr9e+vyZrLP+5evaEJM s4aFfX9mqfemXLkR8ahLvS8aq8uT1ks8nZJHx5sn2HFvYsoeVKoW9MnmuNtXC1238wThinl1sF9s HjtbIrLzbTIE2+gGjrofMQ75TGcRhmGLacqDrhuzKho7wY4VLNaFKZHVodibYv6ia8vPvcDxyI+p snnP4FWAAQBBvyeZDQplbmRzdHJlYW0NZW5kb2JqDTMyIDAgb2JqPDwvTGVuZ3RoIDQxNS9GaWx0 ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImMlM9OwzAMxu99Ct+Wos5K0vxpQL1x4twDEuNQ2Bib CpMYYk/Ae+Mm3dplXcWpVmP7l8/+lOohEQUqBxyq+4Qj59xB9UqRlE5AdUieWP25hMdFCgtWN/sd fL+v4CMt0LJNOheYs+WyWcFP/bWpX5rVnhLrPaTP1UMyD60pSehT+7xtPz+Gh4S97Zpmd9h8rm8B 0mqbVDcJ91fwp6dfVCDEqVb4u7Ftye9g3aZYdAWJ4OADQWQNSgq0HvMxYIe+M9FWCelr6CNkjs5Q SY5yUDIg+rJylJY7tOoc15NikMrRnoNYBr/ZWF/LQ+qYDDYzUWNraGkXCrjtB27DSMdFOH1NQQxy DvkISPYgGZwDGTzOUo2KLRjPOFmjJCeFMIPOJNSs0AOT9Fw8Ln8s8jtRwau0bhOI29K2hmgbx45w 6BTkxqD+tyXo5lRRdHkDR7RIN2EIJdHIc9iEIQyamCP8BK8bQ9PQpsXoiFJw1BNqVLexcnR6kssL YM+KUJIbFLGedrmdJUYBZCba4aSiyIb0QGEuLxSF9wv+BBgA5aQBfA0KZW5kc3RyZWFtDWVuZG9i ag0zMyAwIG9iajw8L0xlbmd0aCA0MjYvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJnFRN T4NAEL3zK+ZWsHQys1/sHnozJpp4UQ4mtgejqG1qa7RJ/QP+b3eXEixQo4YEhuXtezM78yBkVgzl LrlNYQqXMEsXOZOcZTBu3pjrt1FmkNN6yfWWROGXpvCUzcuLpEBngfwVA+UsSpDGoCaSUL4kBOV9 uO2S1GTlMmER0f6hSaBk5zzcIu3haQ4BNZEKpYEJI2soT5MJBQRHrn0U6rgZZTpmRXmd09nVQFKs GQVILbDoJ8WHSbHWKAJYoWjAXlCEDV7nKaA77MbvUH36HrNxKEyPOdY02Uc+nzEMaViNNKBRlyA6 QtYh/VNIkEJ7VEgeCgmyaPtCXrtRCqHfFyfIt6YvpyiMy6/KEsqPxJ86IzxUDnVGdZi1DcP2vwMr FPLRA9MdocIiDxyYbg9MN1KjAS1nfpiCjrsk0dAUkG21bNOcKdw0Form48LbV7fuG+zqbXq9yeFu tYLNI0Qj2mjEZUsYwlm6nFLO+WegR4j2LE++Jx41w1KgdnuLm+ZXdb6G7XMF6+pjC+/b6jWHXQX3 m/X74qF6i5/Ot9VbNocvAQYALs8EWw0KZW5kc3RyZWFtDWVuZG9iag0zNCAwIG9iajw8L0xlbmd0 aCA1NTQvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJnFPLbtswELzrK/bUUIXE8CXJTqBD kiZAg6IHg0ACxD2oruy4tS3HUh79gP53lysqlgwfil7sFbk7s7M7tLeBTLjQCQiwnwLBhRAp2JmL Ujy1r8EDK5pltYFi8wOu35pdMaPPKfv84Xoa0vGkesbfm+dNexV+s7dB7HFjyWXisGMCz1rIKZvc YPF2V83Kui5raKpF2TyWO8IrttvVb8DPdTjiCQPExA/MLl+W1XMNL8VuWXxfYVlRw7xararX5WZx 1hLbj4EgBY6JQWh/BqfWGpBg53Tp2tAug32tmvLMJ6g2QXHdDaNt2LQwX8oGJnmmYDkHW2wWqzJW ynCCj9uid6VUlziGuAsR4lcuUSVMThXOLtepn90uF3QcS3ecSTx2mEdU+N4lIbNu/kN9iqemt0tF qcg8FCl5qnsL1/tWdbuec7g/CRMc/ZTJSCBLDvc+jOAPRP3rbH+duesmFxHchWMu2QktJOPjEbIJ oEBn2CMohYul4a77OqlPqSgb/3SW8lSB0t0m1kFnolnfTwwbuHOlQyojBJX/E5cRBmc34HpgKNZp GfHxUS3GSD4eimH6ANYkLvO/JaRjKj8u4ZArG/bf2ibWam9NenhDy0ieJD3LSOOfv9EpkeB60aOH r0S+26xLTzrrXDlvKJZfRVD7sI5g68NtBE8+fDqHCx9eRHDpw8sIHo8aB5/bCAVKwzMy6tpPQRyY Bmc1wqXIlCufB38FGABMpBjiDQplbmRzdHJlYW0NZW5kb2JqDTM1IDAgb2JqPDwvTGVuZ3RoIDQ0 MS9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImMU8tq3EAQvOsr+pSVwqjT0/OSWHSwHR+S 84ANcU6BYBICfkG+IP+dnpbiHWnXYdFBDVNVXdNdQ0hkIX9r2um+yz+ahOMAJJ8WzluMHth6TEQO 8q+GFEwFa1mR8nM+YIyCi8j/cEg+QP7dtAbudyekI6FbK4sVNxR5Up6NmyZxQOe3Tf7nfrAovNM9 juWHEe3mDgqEgvuQswdp9V0keAxCyR/n9l4dy21dVNt7eJrsQuGZwmh9RSF+pdhC+SKcq10X0LfT lYHnpXw28LCUDwa6r/lz03NCl6CXe4Wi1qucW+S0KnKPu87j2E6Pe7hYygsDl0t5qQspcutx2WGe LxGO9QCWbaynZUdGuTAToz9rGUxBpnCsvhVmmtdQCb+RIGaHHNeK1XrTRtfZkrfz/XqPNJytHlij VssrEDU9vXUY7GFvc6by+9lDUORd++nd9V23SRvL+6uio8lpf068Dpi8UlflSwPR14nYw22JUpAu bEi6THC7lAb+gKmP0+E4leOXyRu46WQt7anYuCQewSaH7jg1fvPGUsQonpPHoRoqpYPhpDwxcHO8 ExntTH+7F/wVYACq8vlXDQplbmRzdHJlYW0NZW5kb2JqDTM2IDAgb2JqPDwvTGVuZ3RoIDQzMS9G aWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImUk8tK5UAQhvd5itrZgZyyq/rOIQsvuHApgVl4 XAkiguBl4RP43lYqrTHJHJghmx9S9dXtb2Kw8hGDtx6jB0oes7UOhufm1nTw2cGfNmMxJ+3dcN0k LFkzVHhPWKLkOHQ1x6R2eGpoxvowRv7GWrTWJhjum923/GgM9FJIUlcVYpnS5wp2zLSas66Vlv0b GP/vHMOOkAIMl1NtHgnmYG6uDq2GnA6DZMLw0DBSEdh3pHZp3nquUTxFEQbBTWHaDdowNnRr9nBx 0gZk01908F7lewcvVb508Frl6x7Oqjzr4LzK8w4e/7ZqxwFlEAoFw7wI2QEvd+C4oJNhIo39/+yb dJD+cbth52XmDfh+C/YRaQPWsY32vCVHi9kvyZLr8nxAyqsiMWPO/9N9JozxSI0tPhdMGzpzvaFP eboi7EFPMPtCJklhbYxphrfeHXfHj91GvM8Lk/jZJH42iVeTaPkdJ3QxzO6d3ourPFUjTxzl5YVW R6mcHKXymKMoZ3WKPNC0fVpuuTkqLK1IcEL+p8OwDWqXNX0NZluQluAjdmJ2yHFJXJ8avgQYAAt9 +agNCmVuZHN0cmVhbQ1lbmRvYmoNMzcgMCBvYmo8PC9MZW5ndGggNDIwL0ZpbHRlci9GbGF0ZURl Y29kZT4+c3RyZWFtDQpIiZRTy07DQAy85yt8ogmkxt53BOVEkQBxW6lIlAtIFQ9xQ+IL+AW+F2fT sGybS5VDrF3PzthjswKSjxUozaiBjUdFpCF+VIREDPG5qhcvTXyrPHYhZadAGYMUBGDR/wPokBAc egTn161C+RXPp0SEPnHOGi3DnJEtxMvxOB5PRkmYTfB1fX20XDfp5jRGAyJ4Uyl0xgqxvJSLeF9o 2qapMY11zupVPVfzMfyqHuozuJ81Fq3QaGpJeBZwP8YtfENbJPh/Cb5P+FwwuxZWTYdcz5rHeLPT RMMGHXSEdq+F1EuoBV820iiHTiBqK3OAkM/afQKKkNW+acZSQh9C6BR6VRCmdkr5LQzmyeSQy+Yl GWGYg9VsXwSTRq3Au8nB4a7kZ7Yodz4UczlZ8NUElzYYSq5cq9ph0gGD2WPizMTDWKzr5LqWoJGq u95v1/v9d7wdgNsJy5WhvluT1Y8WdJPLsyMs6xplNXACd7PGoRIJr628kwZyNaFCS618kAgto8Ou EJEMg59x+XjYKh5W6px483RR7Bvltdwu8zJW8CvAAAEN6ZoNCmVuZHN0cmVhbQ1lbmRvYmoNMzgg MCBvYmo8PC9MZW5ndGggMTM1NDgvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aDEgMzA1NTI+PnN0 cmVhbQ0KSInUVnlcU8cWnpuEsJewKULAy1ZZAsyNsq+CoCgQhLAIagkxQBBImgSRpUoi4kIFRMBC VRCRrTxRwWpFAVdEwSoitWCtLQi4gvKK+BR4Nyxt9b3X/vde353f/c09Z86ZOXPPd74ZgAAAlEA6 IAK3ZYHey4cebhPhmnYAtHMZgVZ0itBiGACdtbgumL1JhI7SesS43ACA7NUofnT8pQpdfAbDNADI WHRccpSp7ikNAAIpABBexXBYG74N190GQBKK+9vE4Aq1YbUxAEyP47JRTLxo8wn3eddxuQtfzySO x2YBymrcN5iEy7R41ma+MkI5hvvj5gBNYMVzvlPqxtfnQ3y9Dr6Aw++3yy8HwOMdACrquA0y3aQ9 0E7Few0w/WgLoUSbR5Y3y1yR+VoZkSWUSrQjcNVaAoJgH0ElstzMCEFGBsAIsoI5GSEhElsCQioN gP6Q9jsNtUwvnQqcphsDRAIh4IE4wAEi/HWRNoi+Px+J8mCB8LO+mlvMbKQ/60V7NLdUonEOSgjS 15hAWbmg0+5zyRrq0XXCTzTX3T8ClX+NEyHh4YgPYQuhLpkYRFJQnxfMEXADudEJKFOQKBShfhxR Ek+wEZsPNaUGiuofzRnQUO8EtiVGg2YzA4a/eXLjOWigiBXP5yZEo4EcwSYum4MG8HgibAmkz1ib +zFQH++l7t4+3sw16FIPD09/pucyGmrCNrW3Rd9fA+rNV7a3hdYYHU4/YfOV4RKIQVv6Ymt7a/uw v/4GxCW//+eIDCCK9+D/fRdBLAZ3LNGRmDSahaWYeoJ8slLxtKpySE/gvcS+tsVmJ7vG5MOXjD7O nZRXutWrE/ZNx+DYzhMHW3YYP/0slCKM3XzjU82Jq6Fjpl+Fri8kTVhEqoaKqdc/zb9rEGp1t11D JsPmbH5Ng+/Kxy8cDf4WXLRF/0BcZsvK5ftjGyps7r6Tt7jTYP8lgYgD+gNIEPG4WEEfuaS25qlt UaVkG7R31aubhw8t61fcfKh8y2ilrEDv5zXD7Rl9u/J9ev1Yw/Xlb72c/ZcolvCDx7LNts6/+Yjd nMyVFVoeLzDZ/cvzmurOdR0K1ynyOTfr60wKLyebZuTdnzob7b6iIpfS38waPxD4aN9toev4xEFG Rm3Q7QlVNhtKSAQoIW4sJRIQAoEilxK/lhe5j3H28oTHTxpaB/8fQYxjlk63ex/ENr+CuHQuPoV/ iW92Z4r/cWeO0H7GgM7kCOKFKC8KTRRyUJYIjRGJ+EIHK6ukpCTLTbizEHe2ZPPirQR8ljRQiGGL oLHUmaiu98e7hxLE4EMcSxAVgOsVCBIEAS0prB1PT1YS2Trm2qwH6ac1dUuzcp0bF+VlaNg/3X7T NI8ctaKcyNgzxKgcqVt/22pB696Xpw6l7tW/+Xiqz2/kXV1B6Bm2xUD2mKlWBz/b/9Lzwka33ibj Ifeg7rHtr8iDWUVUbJSo0uVzwMjsvo5OjmT0+HClb59G5cOc7taYi6zQakHXOFzB+N6Kx0a/33Vd knpx1TmTK+KYwQGJW62XQ+kbV5sOn0ame1gKJ3Uyo791ObP2G+dn6a3ary8vFovbzArebl3vsCNX o7fdMvHV8MYB5+qIJnekhlETXuVqgJWoab4RHtaTZJHMn3gRfOJzFvpbFqwy20zOEDnvzaEtx6ZL 6Yj4DBSfgm5kOZzRZWRkcXjigIFwToZIppE0KXhOeGwh//2kSDVWQhFLlCiE8nhSdNXxIgBwmfQT JTlDaZ4VIzJXIJnjngg+NTSDJnMTE5B51D/KNlSXzmJMUoIKcy5EOagoVaqQSEQCueXfsIDFKIMd QdPq+cVIJaBe6Wn9uejtFw2f53gpf6vt2zSaloJCulZMVl4jvWhk3xlHTfKiVBcCGZTr52WoK1z5 4pFbyBUZ46G6OtXY6keONx4bjuWbrnMLGj0aePCajYM9R04oLKd31tU2t8o4TXk+uzTUY3T7JvuY fOXbn3X6JpYqxBbiLKCGn2L/mGEBFXABZDk57VS97TLGfvaj24ckwMfMoelMIRh48PjJAm50jEiK chSzxyvSl8sW8IS8KBHqwRPwLTE9SJ0x1nx/hCdgibi8BEwfLpwpDK3fxqUMgC5NFMXwBFxR8uzR hGEQ2s5WNR1i9MXYrPg/iOjPirSacP4Cf8DxlZ+OScn+zevhk7LqPcafjE8W+Bw5PXmwDHVJW132 ZVlOBH3jbfcNyS9qN7Uxe149PZBJzSnJiKq/sjEl0rBb1+mBCpI3VHi52SKquDjm46JbDrRmpVOh H1/wGlRwsSukVZvYVz3z3ubel6HSWBwXxKqVpB2OsEjyeVzUsMGx2J+KyRlplFQP7jXXGnD+gq0R ESrDKdG1DdjxunI4n3BV505zkGf9rvRmh2fMfL9jE5Up8SK/Oq32QnkTfRCSG8G1bVylJusUPBX+ tjxKQa6iUxwcMvy14/p54iRSz1jTsfSCyeMdW7srtQVrna6fG5E7YgDrydvb6tEk9e0/zhZpFRQf heIyKfoRkrgYivenU8Jv8Ye5gkOGq7donPTNnrpxWPDfz5/kTzBOlOawYEixZc/ofi3r52cQo3tJ qqNrI+glhxRvuMjs3ZnT5jCg/2okZB/tVOnya5HD775rd3QMq7ZhcieN4l3b2mseyKT9gO1xLqHw Yxsn1Rha3JZ3tzz6VMNQxpPI1LqaBdfMbY0tmjiH1XYbq7CPvGZS3+i3dWuOBtQmeNBlJyTzxx9F xymvHjv/MqD1/OBl+A7F5HfqFphq+97VJRx9mf6Q2BD+9xM/XAt5wfFuDWB+3UA0UZvK7R6Ry9ly Zv+Vr2xp/Sn9VUl9m0rBrVjXC502ux8uVauyjtWJ7bX+qYtK6q/yJF0LW2yX4EtVjjytUPb5nbtM V68OalAFv1fNYce+xJLKzlKcFdrwu8GJ2btBrGIRowU8qFHtuudWXNU08JegBYjzAE4LdnOHvTWG 4RfYGRGKKzDFaYInkdUJQYH/pL7M46Fa/zg+m6GxFxImoxFZfpwZhIksY5ctg5RiMmKuxlgmfiSN qShNL6SUNaOL3ChhamSpK+I2WW5auJTlIloQ3ZusvzO0uC2v33+/36vzzznP832ec57nPJ/v+/v9 4tYA0oKGyBqUFzkiCIy5DPA7UoCEoFN4jfD2AAqNHkL5uDLU91b2vW0KEuevtokFVJa3obDSQgHj Phg0BGHflWgBUgPzNU3EBTQRWaJJ/lFZ905RQEL/7CJBsX5K9yDNEOs09YA9NH91vhGmr6zaNMTp Ib2KgzFsL3fjd8jJuGkYvYkrr2QTbLnGziGkepwYgTbb0sJ3zVa8UtTZ5aBmxm3kJ6cP2E/SOkfT tz4Tapso9DAs1fVrYZItOfYkB0n5G45daRnATtsDlMqO6qfXL4vluPAitsgTfqlMZJcdL3NyUXaW 5uoxe8UJFLpVk36tQ1pWTSH6vRDW2U8j+b7m5NHMjNJL3ajQg4/1LVIKbuxr8lFEX9STyCLBFczO p/DuPzdFMIhKye+MhytK7GKCNSX2QsnGkSHzW88LO8q8gdrMy0L6bP9wGRQaZG6EQeEXWdBN4P9Q /VZ8hf8YiJFCrvpQfspCwUwAClnKN9ESCDmEjIZPleL1Fr2x6lzvQ++G7uk0iOtvAtZ9miADQ4it R0HcIQfAUpUIsViRUEBtAMmlHAYKXUQIAXDw9i2YWe8YyLQ4PJdzyy4q6gq7a3hdo1elQm1llS+M Y/2Tsff7KvXsfznlzuUPGiUZUTZY9lbparbdeIy891LzVp/CsdhuNxHTtxs6Ht6mHY+XtfKlHKE0 FJ/RTupOMXSQvDHykJwcGdnftXFR9ejZUwhP0hmOEmErq2asIJGtxHaM9uXaz+zBUwnKpNIDTr2U 54BJN8Xeana2QckybDjP1HosGHKhxLL2pnSF5+Dso3zN+E5l53yPOvXk0ML8/YqLpCRWTbxjIefa vpjitUV85G3bl4UVozhZd1NNxK3FCLuek+rEOf+RMdXEXXWbfx/B/YXv2tMbHXMTKKEmOMyypW8p niJ5AywhSRBm75ZhhiILSxMhgkt/5c8SEpQ4Pwo0BPTDAwZ4AwAwMNA3EtBPD4SfAVjuCJpAPOd/ vRH899wI/p2X/dc06peMWuNL8upvtUxFt5nFRukU8bm/s8XrCYwnady+PEcz7z2t1i6Z0Rpv7O8r 2I551ItsXY2Z9pgc8+3ou5deAzxb2NGsjm8/RhqZSJWqntKqWzcEzxJNQE+VGbN586Jokwi1Ei+t exr5siks2YGoi+bb4Sdz6kNvKo/q/z1lcNrZ48j0H8B1zDMvJHenJfKZN3+yt7BW1jZs3UbsAz49 a11070+73kQKRWvM3fG8l2wlcswjid8saePowWenRzkkjhRbIJsWxUeDvPzD71C9KolteALQozj6 iKimGb1wtntDoOpvuu36fw7Putkn8EzaN/o+fpULJycWB5k3TQ/Ah9uEltMoFtQc/CMmS0eFlhT4 +XIh8U0UfmZKcPNdN8xEpW5H3vUrh/eolfMSt2sA8cUCOxYRzwHic5nf5A6H8fP/g5dfJxgOgqUq I4iABWCWZ5q3JcH4Q0nnH75fh/bxPUuVV2gwVdCrGxpOpxzwZ0ToCtxF4C2gp+iAhi+8fAmJBtj5 NaS50Z6Jp2IyMTNFFa3zRYTmm0PP/4bPuncXZRTnZW3Ohr9k2Sqp1Mrwnwear2qSS4V5tBItK1sU d5dN4RGmq4fQRcJFyRfjrD0iFdPPplInnhpN2Z0YDzW/0c31YN6GN+hc39SDYkk0Ef+MsdvNQ544 bb4/pLFnOnNctE4FxdYlcF8XtYYlBmH7KwblD/FsoQVaDTv45Sf2+853aDfQedhy8UWTSWlrxuQq ZIb8U/rtBKj8arSW3FXP8QA9zotA57eOrMujkj3QmV6/w/tsd/O1Q+8fdO5C8kLYYgt711u+T4vN v4zKbcdKXXE6qJ5KV6sLmik0u4B92ZxTnYhjCWFBLCrDwAo3nvvDgO8f8BZDiiwfKww81bz4CUDm U8zcBMUJw8GjBscJIumH018Fx4khUR+GwKAIcPWfW6I4CWClVRZU7aeJCNxqhNQssmx9g8ZrlFzV eanpO0wcELdiuBguFAjJs2JaQkgQKoQGCYBEQDAQZ/AeBd63Q+hgHxkSAj7bgM8hEAb45Alaw8Fx 1KUeDEQPogMBIABHjan6QexRUVFfiJ0RHUoPDCeHBkV/mTYiWFAIGcM4s9i2q49Tbbp64hAb5X1E LCsOq2z5ntDSK/7A5qrlrblYDRWKEUby9F8F3uOs49EBxoqBEmLGFT7YgkwlvucC13WKt76hVMXU usRxMhc+Ddv6uoGwdrh8OuaEz0AS1G4LqjoiOGHBjt2X0vaqc5Aa7GX+otbkaum4P2/sSl9kTLvQ uS4d1mJX5kvFkMdo19im2N79fsdNa6JyTnnmZ8xHE/8dsG9KpezUDu65vHb063BK664m0w7DY3U/ 61zgoaWutdpnHZoqGC+TPaKZTwuDY4rPZb37LZLWl9OXisweLyVd6AwJc095uNj4OKFnPtb5LUPj 9aVy8uaLTxrj1N51cFiwbQALZvf55JA4FswY7DJYUnoFCD6c8hInQdXKeQaEUwXqwpDCD0QwMM4B jCh6eDBuLSC7LFuJjwO0MfYh/jo4bUBz2YD9PJNKAxXKINNCBRJ1DwiPpPoHLOENpw/gl0drObtg ttlbWNpvsyd5YyyIRGtXkrWVtsAVQJz+8xswKZEYmg99b5rLzYZ5Yr+MfM4XOvcG5FcKWvRTQxgK 6vmTRQgnKcgRcADOCI/DGeL1dn6l53M9ti3dv5b7OdRHMlWrVbO/oSc7gsaw7NuBihnf6rq2Boau m8ampwtPHOqr7lJ9iNDttR1/mY36Fo+nzibtTX3V7+e52WaELjTereK4l/XqbljgHJiCHrpm3ytc w/StYq4yOYgrX2/kYublWQftl3TJ3rnrV4tH1eT0iWbIbFPeswvjW5zimM83uum9MEZv3SlfiuJ3 TpcNlkgwUyidkj67461y0pXSRC6f7J+cATRF8oIVFnyKXQcM/8N1lUBFcWXR+/6v6lZc4oZN1JGG FkSB4IIbGiVCI4q4L+BoBOMC6iia6ERjggkxeADXY1xmXMeDGxltTDS4ZERPdEaNUePuRNGJxiWj cRyT4xy1/1w6mRkzfU9Vv6p6v97977+6r+pKsL/r7vSohBbfTY1zrz9S9uT7zy6cKxnVaE3FqvR1 beIPrNlZseNA56ubvG9lTCu8NcX3yfHcBq3zW3VIDZqxraC034yEO/XOHRs9bVDGunE7xz3p8LfV lViSU9U/9Pdb5wGiO8hi2ID9O7s9DyN++tfrMV41EFsph7Yt9moLmF04N6BMqFG9S586ZSoS4TZP 7RJ/irR3hsm+RIgxpvqqvZBbX4Rya6aXoSlgrnO7we22vw/HTILHP9Fc0w3p/MefNyACy7EOLfBA 2uIQKtEHm/AKBmAZeuEkdqAuZslxWPAgGVsQIaFQ1BsXV3MVLmEk1eYmriEKabgqDXgfL/LQGF3M He7TMN/soVcQPzK2Y69MlsGIo52qYiSakReZSrgQZU6Yizxag5vSwpQjlda3qI+WyMcSNMBEHDNP ybQFP1Y2yxy5gzBkodiKt4rMJHTFLpyTNFrpmGVfrLkLkzlqo7ik0lSZW/iTJdTEfLyH+WS8E5Xq JZ1kr6c2RuJlqmk2r76FS9JQ2upE09L0NKt4djMeqmh1RDvJIxq9MRoLsIHZOI8b+EFqSQdZI2XE ablvXyS3NH5KzcZcMt/EsR9hj7SVtsqlXMyWC60wlNcWoZTxP8YpSZNMqZSDutRu4+9hGplgc4tr 2BoZZLiO33k38Eja0IcRdLh+w2puvWG3e/YuZzgWq3EKp8njKvP+Ax5La+K6ekflm+Fmi7kZqJVQ dMZAjGAPmMle8Qeu6iF8jn/IE1WTnietw/Zs+4FZytxGoie596f3YN67mKu0ExXEec6yvrg5i87S TwbJBFkky6VCLskl5VBhapq6q336uP7a6mjbJoF3aozmjOvBcORwBd5htpdyvltwGEclWCIlljM6 z/E/qq4qmdioTqqrep5eZD21P/Bf83/nf2KK4GSV9WIeZmAbs/C9NCaHVjJRXpdvyHyx+kTX1fW0 R3fQr+ghOlPP18v0X/SX1nSrzLps97az7TJntn+K/7RJM+8zFwIHebVEDOLRifUzntU0ifzyiOmY g3dRhIWsl6VYjzLO+wCO4hyu4O9cAUgYOecy+m9YdfNkIbFKPpKDcliOynX5sRoqnIhSHVUPlaRS 1AQ1j1imTqnz6rZupl/T+XousVbv1pcsWJZl7HZEql1sb3Ycd0Y5U51janzx9N6z1s8yn131w9/E /2v/cv9B/y0zzMwi/wjEsofPQSFZrmINlhLbWIm7cQRf4EKA60NRYrPiQ8TDaojhqvWQXtKbSJeB xFBiuIwgsmWM5BD5MlfekwJ5XxbIhwGs5NxKZavsJj6VvcQ5qZJv5a48VCxipVnNEaqlilNdONMk 1Uv1V4OICWoqkaemq5lcoc3qY7VHndcNdYSO1dl6ml6lt+tD+qz+l6WsGCvO6mYNsyZYBdZJ67R1 0Xpih9peO8deax9yNHXEO4Y6JjpWOnY4bjueOh3OAc4xzjnOs05TI4Jq9WfOexee/8U5TsrrdiPr TVXF5yJE59mFMpQZc6gherJeqL+yx8sD7ZbLUqRz9SSzUaeox3qqDFMHJFyH2gl6PEpgpExdV4/U LStYhqg7EmUtkU/VVJ2kHAFdPWMFWwX2bUBdQIJ6WyrVYV2gC8xnSLDXSpW9Vp2G27qmGqKKT3Wh WsFBX6pcVYwMK95+glzmfav9JvPdXc2X1vqstRY3tUf9Ux7IcqrGCeljtVCvqi5SRsV9Js1xT6Yh Tz5EouyTK1IBkS16s/RVtblaPlVHOglwQofJWR2EzGqOEqmCZYB6oIbq/Y5T7C9ClfgKs0VLG9bO f35+vhOOxzLVkprmpZqckXYIwQrq/SP//mrFti/axayzDTqG75dtMEodRwKfjZtEBj5AO+xlDc5H G7USc8xcGUvdT6d+KlTIRMRJLaqli9zy2S8aq3Bq4WhGfUz9P0bVT5P7+K24+WRVIsqqvlJiealM WdTfYmIsRvFoNZY6dtln0F9cgOX2r2WVf41X2XO+Yfwm6EZ+I7DBiiFrN5V5Gkes9qeyLyaS4XFR eJucu/M5H2ClUnmXm4mcYS57VF/2xKPINSuQxLUbZApMMUabDWYkJmCw2UL9nWl2oiMK7Uw1zI62 4qmxR+Vz9qO/SjF1OxWXqUcREoK7xHby727vQ5F1gdrZw5SYcwhmPsKZoTHsojf4dn6feUvVlWjv 76fKTYrOY4eqwkCz2YRKEHLMZCrvfpQ6bWrPXDS3S1m7SOw5dEhij+4vd+ua0KVzp44d4tvzlSvu pdiY6NatolpGRrTwhIe5Q5v/qlnTJi+GuBo3atigfr0X6tapXSuoZg2nw7a0EsR4PSlZbl9kls+K 9KSmxlYfe7J5Ivu5E1k+N0+l/NLH584KuLl/6ZlIz/H/55n4k2fifz2lnrsbusXGuL0et+9Essdd ISMGZtBekOzJdPvuBez0gL04YNehHRbGAW5vSE6y2ydZbq8vZWZOkTcrmbcrrxWU5EkaFxQbg/Kg WjRr0fK5PHnl4uouAUO5vAnlCjXqkJSviSfZ63vRk1zNwKcjvNljfQMGZniTm4aFZcbG+CTpNc8Y Hzw9fS9EB1yQFAjjcyT5nIEw7tzq2aDYXR5TWVRSUQ9jsqJrj/WMzR6Z4dPZmdUx6kczbrLPNftG yP8OefMGSRmFz19tqou8Ibnuf7NeNbBRXEd49u3e3oVgfNjmz2fIHcvZ8h/mpzacKeaCfReDaYix MXeu0xxgIsBtQsVPhBoFo4ifHKEtaRsRRBBCbYpwG9aGtDaVkFGFUFpRWlUGJaFtSkpb2gQiBK0g krffvL29nA9aaFXE53kz8+a9efNm3uwxm0zu8puHm2OZ2gD/jcexhimC0UQyio1fRQibWvzYS+yI x0xlBzb08zn4TPbp1hgRliTW+81HjIXG2uT6BC6mMGnSsq2BvsLC8ID1IRVG/MnWmBEwF/iM+MqG ot4CSi7bemJS2D9ppKayotc71g5r75jc1GB0TuZgTVonR3I6j5qWpeOqsEfGIqSD6V/thycxA2ea y3/WzKXk6rmYhn9xBVZmJ+5jnflIfSLprYXcy/amK+g1/MnbhPs3Pvl4pGRlSqIHvbeJh5wl6USD 3hmb5eVmWRkniLseNwof6yRfXVmxpV+YxgavHwTho6cQ25Xx2ioEPxDg693TH6ZVYMzu5pjN+2mV r4/CVeVxUyRYM+hoxi1nTbejSZsnDOTxSfRronGmpzj9P9c7Pj+yttZUxv8H9Rpb39RiNDW3x/yR ZCIV26bWEZytn5vWpUaKrUDATS2ISC0ykHrL2mMswH9XMGpE1iUaUWrw0cyvj6k+EbdHwqfKpZC/ HemVmYmN5rW0oC7zv7Pf7UECS4nij5reRKP9Nz4qEHhIo37rU7aS5HOz1JnM2vKR/LwR/Aj3RidV OKwVi6bW9mRy1AhdFI9VMhk1/NFkIrmy3+peZfi9RnJAjamx5IZIwrn+fuvUHp8ZfTWOQ6xVapHa ghb2Gsru5t6wsrulPTbgJfLvbo31CUXUJxbGe6dBFxvw432WUsFSFjLjZwb9DVXRJzxyvm8gTNQt tZoUSH51v0JS5nFkCq3uF7bM68gEZJotC0sZ/+OXor41lpkDsrDilfIDgMgdGI7QCi99tmm42Csl mf/0pB5SingkHOALW22gHfiZGQS+qh+jRj2EU3ydmqFrBaZDvk97mYKY/xz4FtB9IkT803Qx8ClQ AbQAfmAVEAOWAC8CzZhrAt/kNRyoe6nD/RVa6TpHXlcbTQUWY2xoH1GZtpECGDcyj/1mq5OpDOOp 0JW6J2PuOesq6zFvqpzXBruN1A19HfhHgTz3XvKB5gL5kBdinaPsM2iTeobPat3AeAv8WITxZ6BR +NoAugTypRjPB3Jg80URslZjPBbj+YjNWIxHAxHY3WEbzM+Bj53QF4AXPBf75oD6eC7WLFUvKT7l AL6pLlGv1koF0I+RwLn5zM6Z2H/26d8gyv5lwvZPgn0Vn/t2D0QW1qiz5V1tT531oDhPG9TD1k2M Db2AIgz3JZqC830MhLROmuSebP0VPi5ynaRq8B5gogSveZB2qrcoDF25/jryppPqxEwoqq274hs0 WQ/SEzgv4k0l8D3OuYdcmIZ5LdK+k6ZoV6kQ4zDDQ/TndJwQG9x9E2g94n7dQ9YnWKOegXUGgDOw n4D9qzgGfO9K23AP5l6D7gVgI3JkEjAB+j0yh2HD9tjncd7DvgfyyhwEOPeAWQ5S9+PgUQcy/sck xgMTgDkA7/s68DPgSeC7PAfrjsf8KfDjJc4Zzk3OD84Nmf/IJ5mzfI8bERvOMbtmfiCepd1AAVCB HyU7UyjDXFkvfI/sM9cCr825xTnjUOiL7bxXbvA5OacyqOGqkHvLGuTcyqClnPtM1bA8Q6kYpBrO WTvWDpU+RLgeuSYc6vjD9SlrBFTtonyOHd+7Q51YpOlhCkK3xPUePaHNpBXqWeR/B8ZPgc5BfA7J GryhfY/+JHaQcA9SBe6Sa/eNLLqf4R5S1mO9QcSyWDtPb0g6JKZqQ4rL1WNdc/WIl2w440yaDWXQ 1jFlZOr+W/n/AnHR1UPPYvw315BlaUP0Gs5K7r8rMwC/QyHvA7qBMk+5st/TpfS7l5MXeXMLeF4L 4/drmOZog7RAGyfrLgj5cqxdpXXRPNip+KX2irqcjug99AV1CPeIvcRFepnB64NuSOdRds7dm0uS Ovl6H8o1kONQWVMh6/eyrkLWH2RNhqxhm1KIewO/z7I/kHybxzr5ms7LN6lYvZ2Rn1l5mpGf82Dn zc7LDDqGaaq35Dh1Cpvx3Gv4/PJ9bJP1JN856Pqc+dk0bX+M+sUx6wP5Dp+ndqeugZlAEPqfp94R vMO4b+6Ze60O/QWrQ11sdeCcP9F3gd60TogSqzfdU4M0K/WWFTq9lOPkOk9F6T4apKWp9yzI/VQ7 ih5u99F82T//QhNdN+XbNkv6y3XINViFd68Effwf1l0tj55TXyFSUZcsR440s07z0Dj1j3hzF9Mm 9ZD1W3WffIMi6jDF1XLUMGwRs4kuQUWuBmqCDcn1eA4oy9h/XUN+8lvQCB535bzLfPf6XcoBSlzX 8R61Yc4xedagfMf30zSOg7TdjL6CtdzllKcJKk/NCUqbr+F7QcYDb2BGLFK9uY7X1JfJnM2VNrOt u548CjFcb1EN9g/KvRqp1hOiYlebdV1+V+TRk+o5mqE20mMYF8q834UeVYp+2Yj+CKgfAcPITa/N y14tqXVH9vttsp+PdlXRCvk9wTqdpuilNJ2hGdAlqFJ9C+s8j7y6i/HbliW/D35HY3lvyKOp7xP+ ThCyXn4Du3epkmuMfZD9hv05gHy7QI9xT3QfQQxHcQ0qCuJdlOqDeeAF6Lcy8O2UrMimSkC8R21S 10ofitPiuDhtdfF3oPo+PaN+H/d3nAJqO/r3WfTGeejhixGrX1NM/RXGUyE/BGzBt98mytVyqVO9 gnmzoNsAu/NY4wj0jJ2wuQz6Ns1Xf0Hr1EF8H1zhbwQKaJtBnwYaqF75EXWJO9Sl16Anz7PelOsz NllfljiCvnklZZuC9NXB/Xzeim+7+/grfc30k328j3+8Bq8r7TBH0yiXyLoMBG063Cz2Ug9wWLyP uV+ircpR65RykKLKVeBgCj+mRkl7gWbUWLXyIjBdq6afAtsxrgA9DRy3eToAfADswNpnQE/o+KnA EAuRz6CQHQL2A790dJngve4nz4TLZ50awb+DXgMot3CGWyN1cs/tVIP9arT51imGeg09BNC3UYF7 CxWoJZBPgV0W7/LhnXuHpj3InwdBuUAzZAxthB/mjA8Lrl3uz/+v9R4WuN9twNPSh+t4j2UO0Rjl onUZtE25iL69GW8pAL4SfL4TT+eeIP+OlGfdH3KFVLL+mS3P5rPv9UG8OEHPZMLJg3Q+vEZ1DG0B 5gPZvOddqmPoZ6E7ey+v/fABaMc3ygH2CTlYci+vL6UShpgGXwvZBjUHpPkLeFcBnivtc9AvAVm7 gDiJXgyk9dV484GMuNZwXNUDtt65n39xX+2xTV13+Jx7rq9tzI2NCRQSwklwDAkxTTBj4eHVdhqg eagJg/HIpDrjUSQeShis1bSkgW1ssJUlKwwotCSlZKuWZDHXhJrHRqRprVq1kEnTNk0ahI1pf0zT 0gdMbAnZd46vQzCgNF33z2x9v+/8Hudxzz33nN9JvpfU94PxhdQrQA3y2SukCLwKHE7yyPo294v7 1vzKxHof0cVe8peUmHvfxL1vA9/Ko9r8fwK+nXeBt4G3/td9UYK1CrgAmaMuJcu0hcg91xBcV4fe I2QwHTwZ5wK+vMF+lH+D8gagAOU3YTsG3g/GVjN4F/ZhnCMMfFLNQP5OyH4AbdytT9Qdug08n2hj 6CIh//69id2J+oMvAsvhQ2Y2eBZ4A/gZUIo6yXZ+CH0n+JfQVyTaGkR56AbwXaACOJrgwe8Bwm9H H78T+chD7qGfKT/q/vFJ2bxnBJL8wB1iPLz0E/F9d47k+x+Lk3eJh7CcB3P82qjxPOqOcx9j/dhH A7m0R+SUIo8WuawF+bPIH0dY3NuekjzZbCfJTnEGitxZ5K+WBciZE/e8glH3wWXJc2P03ko/JicB F5Bp8jbE3MFd5wrOJif21Ft4vtMC8mwT5xqA8V6V/t8OXxYx4PehZ4FvJc+05N76wB47xpn2Wevj PSM/xZnqNxFJwaPsSSwyUSaQehaPF2Od3Z/6LH/EGT36nP5v9eQ5n8RYeekDecAY+ljtjVdPzTvG rafkJUk9FQ/4U9deMp/JIBkjSPnuxgtxt1B77uX+yTGkfscj31vyjtCEM3UUsA/k4czKB05hvygC sgA38BJsL9gGid/WRfzQe4BzsP0dvEn4wK30IDa328ND0L8J3aW+L2PXmdg01npOXbciP5f5IeZM 7oMtYvykEFgKuIEzwI7kuxZ3T/T9V+USIeKeq9YM31KvACk54Ji8kOwEuqA7oTsvkNXDvexGbNky fygOLnhcspGX7z8vHEbGDP/P2Q2lk8whHIbrxtRM6blmlJSYhc8vShRic+f5r4cnsGvkH4DCrrHr mHRZK5b3uH8grMNA2QvYqSnhpI39kUQBhYTYH2K5s/2tl9l78L/L3iGbZLV3DH2SHw2+zd4kbsLZ OdZjenpiaZP8JLwLRwolvZB9QD8wAKikjv2ENAHNQDegEickBwqBKmFhHawD42xHfSdkIVAHNAMq Wc1+Cvs2IdkbbCuZhbovssNkCvj77JDk0+AM8CnYZ4Jfgy641dRPgIX/uGl/GfpU8DGTj8KeCT4C XfCPTP05LGtRb7fJbWyXMZO7wjPhzwaKAIbSYZQOY+oOQyOQlH2LbZc9nQH7wTsSjOlqNHI88h01 xh6b7m/DlDZi6hsxc42YuUaiwtWQjGlIxMxjDYhpQEwDYhowK0VsF/rbJZIFSBeQDTDM+y7Mu7BH IXuBPmn/NmQL0CY09jzmMR+jOsC2Gnkci2xLbHHIH7zInsVUh9izselZ/uZ7mn2CWIjgNJOdInaz 9G6O2ScK6+ZYRlaCEbUtnMY2km8ACrbGjSQX+BxQCqhso5FbyC+wp8kOGwml8SaliTWpTRa1qJS6 LzM/qUYmzYmbzSMBBOTzSIAW19rr7XvszGXPthfZQ/Zqu6WONbFmxjgrZEFWxSLMEh/uNaxLFoBC K7QlC1ocbY6oo9fR57BEtV6tT+vXBjRLtlakhbRqrVar1/ZoLVqbZm/RWqxKraPescfBXI5sR5Ej 5Kh2WLiVtoX3sQ14TALpAuqBFkDFHEdgz2bPABG8jQim4hnYCSSB5gL6UO4HW6A5EedEnBNWJ6xO WAmk8FQDtUC96dVGPMk6In5AeABcC1garGmY237IAVECyqHp0HRoOqL6lEGM0AWZDVQDTNr6Aawa yKSvyPTXApr0D8iYpC8k6iqDoa/M6c2n0Xzalk9b8mkoEAz7Q7Mg3G53xBPxRvIi7Wqdp85bl1fX rlZ5qrxVeVXtatAT9Abzgu1qoafQW5hX2K5yD/fyPN6uNld2V16uvFqpRirrKpsqWTFeXcwoKPJL nuUV3GNMz/AXO8NLlW48TgSyFbgOMMIhC4EgUAeoSjckV7pg7YK1i1QBEcCCGl1ie4Hkpk/YW6VP lIRfuc/P8OCdxpIFVeFybLkRoBVgaLsT/k4ZnSh1S3sUsl/aq8z4NmnnkMk6DBtcjdzmavD51ZAg EAHqAQu5ytaS6wBahuRAPdANqKwG/7VsrdKFf6fSyXwhff4UTqZOJYS4J9lcYZcyEWtAx+Eq5DEp D0gZlDI3lFau3y7Xf1Guf6dcn4OCkkfCcByWMifkCOtnw3pVWM8P62jtMZJDdGWKlJqQ9G9SPi2l L5Seo9/J0T/K0T/I0V/N0Xfm6F/IEfVm4NvVlXQpHULSI1KWSzk75OD6W1xfy/Virod1epKid1Ii 5UwpM4WkH551ljqJ/SL9kJSiJWoE8nlcIZLosBEIg+4agRWgISNwEvQvI3CIX6J3qDzS6G0j9yYP T6Ef0zJV6B+Z/AEtIx3gAfAW8I9JgHrBp43AXhH/Ouofh36KzLKJ+NdItazXSsuk/VWz3iuGbwN6 PWH4vo5ejxOf7PWo4bsJ6yHDdwD0kuHbDmo2vGKAW43AXB6eRLeQXEXEbiReRYyk0uzxKbS8Hbwi UXmZ4RO1SkUHcfqk4ZkPmiNGeYl6SLXsjhse+ZBZxCObmEE8ctCZxCs5jTrl4HUyS7LN8OxFK9pZ 703+z8BF8eDkFnUaJ/mfL+H51kD9Ey0zOvivz4vpMvhVX5x6z/Ernov8V7lxusbgvb64DY7LvrhC e/gZTHIUsQo9x7t9W3iXR3rbPfDiVbcG5vETnhr+she6wff6LolhkB144jVwr/c9wSsDHXy5N07h DgXQWWgCX+L5Kl8M86I4LYt18Pm5cTGUIrTRcY7PRY+zPXIoXyq+oCwkVvq1kM+627rBusa60rrU usA6z5ptzbLOsKbb3DaXLc020TbBZrNpNtWm2IgtPT7cHyog+ArTNZcgTRVSlWWXIiSE2PUValPw 7UQnswqlYlUJjborSMXqkmhxQUXcOvzF6KKCiqit+svrzlD6g/XQosr+OCWr12GBCtO+zKj7yXXn CaWF+w5mCm7Yd3D9eloR7d1IKjZkR2+vwnNMWFkTtXhKppGpzwWnBd1PTFq8vPQhotaUBfd+0wpG /6ZlRY9UrPoPu9Ub29ZVxc+9791nx7Hj57hZHdKu13bTDrn5U6djjfa0OolN2npJQ5Iyu2q2vCYv jZU/Tv3sVq3oUgnQWEF0CPFhH1AnKqUbU6iTMJQWaZ3KPsA+MME0QFMFH8YnWFSphD/amsC5z6/p JlWgDvgAejf53XPuOeeec9655/m+TPn7W7PluGD+vjWbLncP8KOZq/QEzaeSV+mMINnMVXKGnkj1 Czk5k8xumEGEzqAZaIIIsyWICDOIkCXL7EnLDNs0kkouRCIVoxvkgDDC9rlhGR2v+NqOIdBXnyBo Rh+G7Zav7fRhYYb9UHHm/7gzLxC/5czvBcvZFmG00NiIJrsahcnCY41osND4mKV+9Z462lhJJwuN VpxGkrXiEHLP5pGKDXaBbUPdaBP7Tw6j8wGMyZJ+c3QkZURTw9GUgRguf/3keKh87hjnC6M3hYKX pR3Dx0bGBdWN8s2okSyPRpN8QR+5j3pEqPVocgFGUoOZhZGEkVzUE3oqqiezS3OzXelPxHp+I1bX 7H2czQpnXSLWXPo+6rRQz4lYaRErLWLNJeasWOn+TpLuyyy4oTPbdbRCl2i1B9+H4YZwtvMhdeYJ 6+V4PBx6tuGaDHhtVceyZW+0s+xDCFVTR1OHUOHbKVQ1KPbbqtCzj4cbrpGXbZWK4kC0E2IQSuWS G/+maRYFSqUYzsVSyJIV8aUND6TLn//CkUxZK2upcmI4mSXiOEr26Mok1Ova2xrNa7PaBe2idkVj pVIWxbXXI29H6DORfGQ2ciFyMXIlogjF0cyPEtrFyK2IVMJuIkUcqaQVs4QU/8WyWDLFAAxgIirh YqVYV6YjAiP4tUvwy7wJgogoog0xgGDwE5zfQbyP+BNChi/j/G3EJcSSkEhNUlMqlEuKiNmY+NEJ SfGl1kfje5eR6mMVOnCkQlO9Fap1xENIF/e1eTr8+OFN4BrObyHeQ/wB8SGCSXEpbjkvVbo2a4IZ I5g+4KIoJjNWJDFkiCh30YzFQEA0OJ4AmsbIJ/seiFkCLAUeCBI0sqSm2FYS9J4h/gZvAWBbxNcy uKBngZIf09fxM9VFry8Ck5fp6z+UwOMSzGsE6t0Ku456ChL5LFSRCfI0hGLqX7Q1rVdd1XrWNNiH vHoHp92t4UA40IgT2SLDHS69cSfB4CPg8htYifr123KadUOQbE7srapLbR393N7abtdlr0SA+agM zCu5gopXcqtVXqna7/FKNX6PjwbUKh+tDSo+Knm9y9LOhBc/hnz4CeVy1dYGhWAz3i1Elv1sG2th EpMoVQMBt7tK6Ko9nupqf43XJ83TZdqd2AlkXjYZU1zztRAMqoF5t1JVlfC85KHgUT3cg8+OvGeZ tic2V8/XmH7vfKsv4XvJJ/m+pPpTmzK/tR6/fnUotKKurq0ODQ1pqqauqHfn1ZV6dTW0Ai1aiyZk a2LS9mktlt3d9XOsOXZWfdNvj92tZCgWDAfbpHBd2EI0GH40HAzX0yO/7Ps5+cr6Uy/Q9rVL7/T9 Yv0sufyttZ9KcVq39sen1785tLZCg0OkgCcLcQD5NpvAk1Xgg0TXfnaGnWcvMpmF1No9VEzSrurA HnlXVWBPo3Ra+ZryV0X20gZKPeQz5Aw5T/5GWDVrYBmsI8MvC1imP0s8pLBNioJrpsgRiW6SJCor koKqRXCzZcoSdZRI+AUmXebyjHxOlvxyQqbyMllM+Bm8sE1pUfLKrHJBYbjpg0TdNkYOsSvsd+wW k88hQxlzu+oDte0tQycKorBYwSEkgfZ27K6VfSt2wdxYMaSh2HPus2+KkuGwmnqojbSRnYTE6XCE PnFrfWL9IJv48DuHpd/fwWa/O046cPDpQN5z4MCBAwf/C6C3HThw4MCBAwcOHDhw4MCBAwcOHDi4 P8AP13CWQIx1axa8C36DKwKVMUt+ZfMShOhhm5eRn7J5Bfmv2rwLJul3hRe5CiWtUpXNU6iR2m1e Qnm3zcvIn7J5BfnLyBPkMR/p1zaP+cjvCt4v/I+xeRiE0zADBoyBDiNIObyCGIRxi++BPEwjirYV hy5cFZAXs47ynGXBUTKJ+5uRS1py/d/01LKRGYcB1ExCacPGRNkBpJV4u6Ed/1qhyebilrQDd0wi 7cc9xzGHorWrH/2ZiAKcxHkUY+RgypJx6EV6yrLJo0xH/z+w8hfZjaJOyAowgbI8VuvTPxlHqYE5 5TBq0cpFZMJxLWyKttfD+NQc+qz9HHZY8XpwPoSxx6wnFBmKfQZ6Na3cx21vzYOnZ4wxfcTgr/DB cYP35KfzRRTxrnxhJl/Qi7n8NJ+ZHGnmSb2o/wujFuGMD+QnS0Ji8gPTuG93e3trE07xZt4xOcn7 c8fHiybvN0yjcNIYPdjXne7dHxvMTRlmr3GqPz+lT/cN9Aw+qNwScJRwS/QyHyzoo8aUXpjg+bF/ mjQvGMdzZtEoGKM8N82LaHp4gPfpRb6DD/bwQ2NjzVyfHuXGpGmcGkezZjiIxe6GNLbBfoh9rDEq bXGvKfrwYHpQ328dYgmLL9riQXf/t+2d1/r/8LXG6lTOWNSuhFqxehJX3fCU/TQi7xw+jYHnVbI0 laz2I59CjznsIRG/kkElpx12dY5hrfIYBQfeQMp5uA0aFtSFN46KB/dFAPaWP4i3B7VuKLxpXjQv vfqMX/uzu95tXVnfe3/rDUGvvvvaIx8V176hgrsGl+L+su60fwgwAAaPRN4KDQplbmRzdHJlYW0N ZW5kb2JqDTM5IDAgb2JqPDwvU3RlbVYgODIvRm9udE5hbWUvSlBHS05IK1RpbWVzTmV3Um9tYW5Q U01UL0ZvbnRTdHJldGNoL05vcm1hbC9Gb250RmlsZTIgMzggMCBSL0ZvbnRXZWlnaHQgNDAwL0Zs YWdzIDYvRGVzY2VudCAtMjE2L0ZvbnRCQm94Wy01NjggLTMwNyAyMDAwIDEwMDddL0FzY2VudCA4 OTEvRm9udEZhbWlseShUaW1lcyBOZXcgUm9tYW4pL0NhcEhlaWdodCA2NTYvWEhlaWdodCAtNTQ2 L1R5cGUvRm9udERlc2NyaXB0b3IvSXRhbGljQW5nbGUgMD4+DWVuZG9iag00MCAwIG9iajw8L1N1 YnR5cGUvQ0lERm9udFR5cGUyL0ZvbnREZXNjcmlwdG9yIDM5IDAgUi9CYXNlRm9udC9KUEdLTkgr VGltZXNOZXdSb21hblBTTVQvV1sxNDNbNTQ4XTUwN1s2NDNdXS9DSURTeXN0ZW1JbmZvPDwvU3Vw cGxlbWVudCAwL09yZGVyaW5nKElkZW50aXR5KS9SZWdpc3RyeShBZG9iZSk+Pi9EVyAxMDAwL1R5 cGUvRm9udD4+DWVuZG9iag00MSAwIG9iajw8L0xlbmd0aCA0NDEyMS9GaWx0ZXIvRmxhdGVEZWNv ZGUvTGVuZ3RoMSA3MDgxNj4+c3RyZWFtDQpIidRWeVwT1xa+k4SwieyKEHTYKkuAmyggO4IgKBCE sAhqCTGQICFpEmStkoi4IIsIWKgCIspSnqhgtaKCK6JgAZFnwVpbVhUFpUV8CnQi2Fbfe+1/b5n7 m+Ws95w53zkzAAEAzAepAA/CVwV4rR5+tEOEcUYA0M6hBVhSVYTmowDopGC8ICaXwc9UjwAAUazB LjXMrSJ0nNwjxuRdAMjeiORHca8e18U8GhwCgEiJikmMXLKvLBKAAAhAsR+bxdj8bZjuDoBosDF/ 1myMoTaqNgGASTtGG7K5ooRTrgtuYfTP2P7GMTwmAz8QcAGAF6kYTeYyEvhKiMoJzN4T00djGVxW oB15I0CUErD92vg8oQjLAwtNKUQq5wtY/P4VeeUArCIBoKwulbxb0jvQTsbuGuDdoS2EEm0eUd40 3TP9lRIiiyuVaIdjrA04BKHMh/OIcrMSnIwMgOFEBTMiQkAkNjiEUOoP/SD5DxxS2eJUEnB4t2gg AggBD8QAFhBhp5N0QfRDfwSVh4uEn/dVt9OzkP6M561RnFKJxgUowUlPI5zKmkWdK/ZJ1pOObRR+ qrnxwVGo9FucCAELR1xMWQJ1ifhAgoL6giCWgBPAiYpF6YI4oQj1ZYnieYItlIVQU6qgqD7/vQIZ 9YplWlDI0HRWYPC7JYfLQgNEDC6fExuFBrAEWzlMFurP44koyyF1VtvMl4Z6e6109fL2oq9HV7q5 ufvR3VeRUWOmia0N+uEecPFCJVsbaEWhwndH6EIluBxSoA11mZWtlW3o/34C4pI/vnNEBuDFmdh7 34MTi8FdC3SMnUI2txCTThFPVyieVVUK7gm4H9fXssz0dNeEfNjy8cc50/Lz2nt1Qr9pG5rYfepw 0y6jp5+HqAijE25/pjl1I2TC5KuQTQWEKfMI1RAx6dZneff0QyzvtWrIpFmfz6uu91nz+Lm9/t+C CrfpHYpJb1qz+mB0/XHre2/lze/W236Jw2OA/ggSeCwuRuB8p+TmXLVtqipZ+q1ddepmYcOr+hUT isu3jVfIChb/tH60Na1vT553ry9jtK78jYej33LFEn7QRJbp9oV3BpiNiRxZocXJfOO9vzyrrurc 2KZwS0U++05drXHBtUSTtNwHM+ejXD2P56j0NzImDwUMHOgQOk9OHaal1QR2TKkymVBCwEEJfksp HofgcCpySdwNvIgDtPPXptx+1NA6/P8IYgyzVOqKD0Fs/RuIS9/Hp/BP8c1lpvhvM7OHtrMKVDpL wBWivEg0TshCGSKULRLxhXaWlvHx8RZbMWMhZmzB5HEtBXyGNFBIoSyFRlJjvPriP88eShD9j3Es QZQBxlfASRAENCUxdj09XYFn6phpMx6mntXULc3IcWxYmpumYft05x2TXGKkZzmeljlMqxir3dRh uah5/4szxcn79e48nunzHXtbmx9yjmk+mDVhotXGz/K7+qygwaX3ktGwa2D3xM6XxKGMQhJlHK/c 5X3I0PSBjk62ZPzkaIVPn0bFo+zuZvYVRkiVoGsSetK+s+Qx0e/23JIkX1l7wfi6mD00KHGp8bAr fe1s3ebdQHcNTWIlT6f1N6+m13zjOJLarP3q2jKxuMU0/832TXa7cjR6Wy3iXo5uGXSsCr/kilTT qsMqnfUpJWqar4VHFksyCGZPPHDe3Owlfhb5a00TiGkix/3Z5NWUd610VHwOis9AF6IcNtFlZGQx eGKAgfA9DZF0Q2lRsJrwmEL+h0WRciyFIoYoTgjlsaLoqmNNAOAq6SNKcITSOiuGp3si6ZPuCOYa mkLj945xyALSn1Ubqku9GBHmQYX3Jng5qChlKhMIeByx6V9MAfNxGjOcrNXzi6Gyf928p3UXonZe MXiW7aH0rbbPpfGUJBRStdgZuQ3UwrED5+w1iUuTnXBEUK6Xm6aucP2LAZfg6zJGw7W1qtFVA/a3 HxtM5JlsdAkcPxZw+Ka1nS1LTigsp3bW1jQ2yzjMuI9cHe4x7LjDPCFf8eYnnb6plQrRBdgUUMO+ Yv+YnQLK4DLIcHDYrdrhNMEc+cHl4yHAp5hBk9lG0Hfj8RMFnCi2SIpylGKLdaQPhyngCXmRItSN J+BbUBZD0qyy5ocSnoAh4vBiKXpwyWxjaP0ul04AdGWciM0TcESJc58mCgVCm7mupkIKdRlljvwv RPRXTVqFu3iZP2j/0lfHuORgwib4pKwq0+jTyel876Nnpw+XoU4p68q+LMsOp27pcN2c+Lxmawu9 5+XTQ+mk7JK0yLrrW5IiDLp1HR4qI7nDBdcazSOLitifFLbbkRvnnQn55LLHkILTigJylbFt5YjX Dte+NOWGophARo0k5Ui4ebz348L6zfZFfiSKnKFGSdXQfjOtQccvmBrhITKsEl0b/12vKkbzcDd0 7jYGutftSW20G6Hn+Z6YqkjiinxrtVoL5I31QHBOOMemYa2arEPQTNib8kgFueOd4qDg0a/tNy0Q xxN6Ji6dSM2fPtm2vbtCW7DB4daFMbmj+rCOuLOlDo1X3/nDXJNWQvExKC6Toh8hiIug+GCqSlg7 f5QjKDZYt03jtE/WzO0jgv98/SR/gXG8tIb5w4pNmeMHtayenUMM78erjm8Ip5YUK952ktm/O7vF blDv5VjwAfKZ0tU3I0bf/r3V3j60yprOmTbkOre0Vj+USfmekulYosKPbphWo2lxmt62u/WphqK0 JxHJtdWLbprZGJlfYh1R22ukzDz6ik56rdfSrTnuXxPrRpWdkiycHIiKUVo3cfGFf/PFoWvwLUqR 362bb6Ltc08Xd+xF6iN8fdjPp76/Gfyc5dXsT/+6Hm+sNpPTPSaXve3cwetf2ZD7k/or4/u2loL2 aOfLndZ7H61Uq7SK1onutfqxi0Tor3Qn3AxdtiLWh6QUcVahbN/de3RnjzZS4HF+r5rdrgNxJRWd pdhUaMH+DU7N/RtEKxbSmsDDatWu+y5Fv1Jf7vFQbW0cnzuNexkpJqMRDV72HhST+7gLySClmIyY I8Zl4iVpTEU50wddlGtGBzlRwhS51BFxmlxOunAochBdEJ2TQs4eujhdPu9/7/u2/9l7rWetvdfa 6/d8n+c5Vzf0f4EFAOIAhAXDD8HeAAShBHahCcQXgBLzgEdhliHc3cBlgJyoIb4M60mPCIRiLhv6 jiwgLeoUWya22Z8RzAphfFgZ9lsr+9Y2RYnzF9skAqoL21i52MKA4j4UNERhfxPVAqIG4UuaSIlo Ij5Pk7yDOLdOCUBa/+QcRal+Undv8Hqi0+Qd3uDsxdlGhL6KWtMgv4f2PA7Btj3fTd6iIO9KMnwZ V1bBo9gKjJxDaPWgJCV4uqVFuClL6UJhZ5eDupmgUZic1m8/Edw5kmb6CN02XuC+vkTXt4VDt+Tb 0xxkFK84dh1PB7ba7mFUdFQ/vHxeMtulMmKDIuXnikRe6eFSJxcVZzmBHqdXisJgWTXp1zocz6wp wL9BE519Scm3NScOZqSXnOvGhu69r2+Rkn9lV5O3Ev6snnQmDbnS7HRK5e0nJig2VTn5tdFQebFd TJCm9E443SgyZNb0tJij/Eu4zSwO1mf7u8sAeoCzBgFHnuXC10L/Q+1r8RX5fSBGFrPkffmJg0OZ ABw2n2/ipVEKKHmSd5XS5Ra90eocr32vB2/pNEjprwVWfJwgj0BJrsLC3GB7oFKVCrNYlFDAbQCZ +RwGDp9DoQEkdPsazKy39GdY7J/JvmYXFXWB1zW0otGzYmVtRZUPgm/9g5HXmyqNrH855czkDRgm GTJWW/ZW6Wq2XbmPufVM81rfykOx3a7iJq9Wd9y9Hnw4HmflwzjAaCg6oZ3UnbLeQebK8F16cmTk 4641c2oHTx5FedBO8JUpptya0fxEnjLPMdpHYP92B5lJUaGV7HHqZTwBjLsZ9lbT0w3KlmFDuSbW o0GwM8WWtVflyj0Gpu/lacZ3qjjnuddpJIcW5O1WmqMlcWviHQv4l3bFFC0vFGKu2z4rKB8BcW4m mqhrcxF2PT9qUGf8hkfVErfVrfttGPyT3LWjNzrmKlDMTHCY5sldUzpK8wK4aBkIZq8XYIali8lR YaJLf/HPQotKnO8FGiL6kQEDsgEAGBjoG4ropwfBzwAqd0RNIJ7/394I+VtuhPzGy/5jGvVzeq3R OUWNV1omEhvNYqN0CoWC33hS9RT2g+OCvlxHM68drdYuGdGkl/a3V9qOuteLmy4lTLlPjPp09N1K qwEevdvSrEFuP0QbHk+VrZ7UqlsxiMyUSMBPlhrxKmcl8MYR6sWeWrdIebgULq4/6qz5ZuSP2fWh V1VG9P+aNDjm7H5g6nfgMuGRJ0aw1RLzyEs40VtQi7MNW7GGeEfIylwR3fvDtpeR6GjSzA2PW8lW 4ofck4TNMjaO7kJeWpRD4nCRBaZpTmok0NMv/AbTs4LaRqYAPUoj96jqmtHvTnavDlD7Vbdd/4+h aVf7hErj9jU+95/nIOmJRYHmTVP9yKE29EIaxYWbQ3/EeP6o8DIiP18oJL6Kwk9MCWq+6UoYr9Dt yL18Yf8O9bLKxM0kIL5IZCei4vlAfA7nq9zhs3/6X/DyywTDQbRUFRQVsADMck1yNyQYvS/p/MJ3 6wR/eM985RUaxBT16oaGsxh7/NgRuiJ3EXkL5Ck6kOEzL59HogFxdhltZqRn/KGkfMzbwvLW2UJK 89XBJ38hp926C9OLcjPXZSGfcW2VVWvlhU8CzJc0KaQi3FuplhUtSttLJ8kok6WD+EKxwuSzcdbu kUppJ1OZ4w8NJ+2OjIWaX+kWuHOuIxt0Lq/twXKlm6h/xNhtr8QcOWa+O6SxZypjTKJOFcvTpQhe FLaGJQYSH5cPKO6rtIXnazVsEZYd2e0z26HdwKoklknNGU/IWbMnlmDSFR+yrifAFZfitRQueoz5 6/GfBji/cuSeH5Hpgb/t9d2/y3a7UDv09l7nLkxlCE/y3c5Vlm+Ox+adx+a0E2UvOO3VSGWp1wW+ LTA7Q3zWnF2dCHLRRAiLKgiowo0XfDfg+we8JTHiC8eKgE41N34ckP8YM9fCQTEkdNTQOFEkfX/6 S5CgJAb7fggCjoJW/6klAUoDi604SLUfJ6LApSjZaUzpqgbSC6xC1WnZqRscEIhbNFwSDAVCcq04 ljAajAkLhvnDImAEmDN0j4Lum2EsqI8OC4GebaDnEBgbevKArOHQOOZ8DwGmB9OBATCAr85Rey/2 qKioz8TOjg5lBYTTQwOjP08bUVw4jE5gn5hr29bHrzZZOr6Ph/U6IJkZR1SxfENp6ZW6Y3PR8tpM LEmVYUiQOfZnvtcY93C0v5FSgLSkUbk3MT9DWejxTrBpsnJVQ4mqiXWx40QOcgph+qKBsnyobCrm iHd/EtxuA7Y6IijhnR2vL6XteecAM8jT/Gmt8cWSMb/K0Qt9kTHt6FNdOty5roxnSiH38Ztim2J7 d/seNqmJyj7qkZc+G039t/+uSdXSo1sEp3Lb8S/CGa3bmkw61h+q+0nnTCVe9lKrfea+yfyxUtwB zbzgMCSh6FTm618jg/uy+1IxWWMltDOdIWFuKXfnGu8n9MzGOr9ik16cK6OvO/ugMU79dQefi9gI cBF2n04OA3IRRlCXwbzSyyHwgSrznIRUq+DhH84UqYtAC98TwSY4+7OjWOFB4HIAtyBb6Q8DtAn2 IX46oDaguWAgfprJDIYUyqYHh4ok6uYfHsn085/HG6gPkBdGazm7EDbaW1jab7SneREsqFTrTTRr K22RK0A4/ec3ELLiMcHerJ3HXa42zFIfyytmf6ZzL0BxsaAlPjbE4JCeP1rQoIwoRwAB0JAMguvJ elu/0POpHtuW7l/KfB3qIzlq1WpZX9GTHYU0hHvVX/7Wp7qurYGt60pa+/DdA4f6qptMbyp8c23H n2YjPkVjqdNJO1OfP/b1WGczzEKPdas67uQ+vxkWMAOloPsu2feK1XB8qjhLjPeCZasMXcw8Perg j2VcsrZu+8XiXjU9bbwZNt2U++jM2AanOM6TNa56T43wplsVS7DCzqnSgWJpTgqjU+ZvrqsFvKYr C/9r73PujaD1iihGbnIlIo8miFcoqeRGiHg/EkMl6pFgCC1Tqg1NlS/xHvWY8RxfvNLhRkvj0RG+ MoMqSrymhJZ6dKgx2s9MuHv+3Hbma+f+3zl3nXPWPvtfa6/zr3NGjJybsm5l898FlBbfePTv+KiA jROb+kZs7/9Vx6tBvi57MyITW347Jc618Vhp9XefXKxcOLLRuvI1GRviEw6t212+61Cna1s8b2ZO nX97svejk3kNogpat08LnL6jsKTv9MS79SpPjJo6MHPD2N1jq9t/tbYCy3Kr+oX8Yfs8QHR7WQob sH9vt+Nh+I//eiPGqQZiK+XQtsVebQGz5s/xKxMCanYZUyZPQRJc5qm90Jcq7ZyhciAJYoypuWov 5tYHIdya6xVoBpgb3G5yu+PrzTET4fZNMNd1Qzr/6acNCMdKbEBLPJQ2OIIK9MYWvIz+WIGeOI1d eA4z5SQsuJGCbQiXECjqTTBXcw0uYwTV5hauIxLpuCYNeB8P8tEYnc1d7tOxwOyjVyA/MnZiv0yS QYijnaZiJJozLzEVCEakOWUu8WgdbklLU4Y0Wt+gPlqhAMvQABNwwjwl05b8WNkqs+UuQpGNYivB KjIT0QV7UCnptDIw075Uaw8mcdRmCZYKU2Vu48+WUBML8A4WkPFuVKgXdbK9kdoYgZeopjm8+iYu S0Npo5NMK9PDrOHZrXikotUx7SSPaPTCKCzCJmbjAm7ie6kt7WWdlBJn5YF9idzS+Sk1C3PIfAvH foB90kbaqGAVzGwFozWG8NoSlHD+D3FG0iVLKuSwLrHjfd1NIxNkbnMNo5BJhhv4nXcTjyWePpxB h+nXrRbW63bbZ3MZ4RisxRmcJY9rzPv3eCJRxA31tioww8w2c8tfKyHohAEYzh4wg73ij1zVI/gU /5BqVYuep62j9iz7oVnO3EagB7n3o/cg3ruYq7Qb5cQFRllfXIyik/SVgTJelshKKZfLclk5VKia qu5prz6pv7Q62LZJ5J0aowXndWMYcrkCbzPbyxnvNhzFcQmSCIllRBc4/gfVRaUQm9VpdU3P00us p/Z7vuu+b33VpghOVllP5mE6djAL30ljcmgtE+Q1+ZrMl6qP9HO6nnbr9vplPVhn6QV6hf6r/tya ZpVaV+xedo5d6szxTfadNenmXeZC4CCvVohBAjqyfsaxmiaSXz4xDbMxF0VYzHpZjo0oZdyHcByV uIq/cwUgoeScx9l/w6qbJ4uJNfKBHJajclxuyA81UGFEpOqguqtklarGq3nECnVGXVB3dHP9qi7Q c4j1eq++bMGyLGO3JdLsYnur46Qz0pnmHB3w2dP7z6KeZT275oOvqe/XvpW+w77bZqiZSf7hiGUP n435ZLmGNVhC7GAl7sUxfIaLfq6PRInNim8iblZDDFetu/SUXkSGDCCGEMNkOJEjoyWXKJA58o4U yruySN73YzVjK5Htspf4WPYTlVIl38g9eaRYxEqzmsNVKxWnOjPSZNVT9VMDifFqCpGvpqkZXKGt 6kO1T13QDXW4jtU5eqpeo3fqI/q8/pelrBgrzupqDbXGW4XWaeusdcmqtkNsj51rr7ePOJo5EhxD HBMcqx27HHccT50OZ3/naOds53mnCQinWv2Fce/Bz39xjtPymt3IekNV8bloovPt+TKEGXOowXqS Xqy/sMfJQ+2SK1Kk8/REs1mnqid6igxVhyRMh9iJehwWwkipuqEeq9tWkAxWdyXSWiYfqyk6WTn8 unrOCrIK7TuAuohE9ZZUqKO6UBeaT5Bor5cqe706C5d1XTVEFZ/q+WoVB32u8lQxMq0Euxp5zPt2 +w3mu5taIFH6vLUet7Rb/VMeykqqxinpbbVUr6jOUkrFfSYtcF+mIl/eR5IckKtSDpFteqv0UXW4 Wl5VVzoKcEqHynkdiKwajhKhgqS/eqiG6IOOM+wvQpX4ArNESzxr578/H98Jx2GFakVN81BNzklb NMEq6v1j38EaxbYv2cWss006hu+X8RipTiKRz8YtIhPvoS32swYXIF6txmwzR8ZQ9zOonwrlMgFx UptqGUxuBewXjVUYtXAUZ31C/T9B1U+XB/ituPhkVSDSqrmy0PJQmbKpv8XEGIzk0Vosd+yxz6Gf BAOWy7eeVf4lXmHP+ZrzN0VX8huOTVYMWbuozFM5Yq0vjX0xiQxPisJb5NyNz3l/K43Ku9JMYIR5 7FF92BOPI8+sQjLXbqApNMUYZTaZERiPQWYb9XeG2Y0OmG9nqaF2tJVAjT0un7If/U2KqdtpuEI9 CpcmuEfsJP9u9gEUWRepnd3NQlOJIOYjjBkazS56k2/nD5i3NF2Bdr6+qsyk6nx2qCoMMFtNiAQi 10yi8h5EidOm9sxBC7uEtYukHkMGJ3Xv9lLXLomdO3Xs0D6hHV+54l6MjYmOah3ZKiK8pTss1BXS 4lfNmzV9oUlw40YNG9Sv9/xzdevUDqwV4HTYllaCGI87Ndvljcj2WhHutLTYmmN3Dk/k/OxEttfF U6m/9PG6sv1url96JtFz3P95Jv3omfQ/T6nn6oqusTEuj9vlPZXidpXL8AGZtBeluLNc3vt+O8Nv L/XbdWmHhnKAy9MkN8XllWyXx5s6I7fIk53C25XVDkx2J48NjI1BWWBtmrVpeYPd+WUS3E38hgr2 JJYpBNQlKW9Td4rH+4I7pYaBV4d7csZ4+w/I9KQ0Cw3Nio3xSvKr7tFeuHt4n4/2uyDZP43Xkex1 +qdx5dVEg2JXWUxF0cLyehidHV1njHtMzohMr/4P61UDG8V1hGff7u1dCMbnH/58htyxnC3/YX7K z5liLth3MZiGGBtz5zrNGUwEuE2o+Iloo2AU8ZMjtCVtI4IIQqhNEW7D2iStTSVkVCGUVjStKoOS 0DYloS1tAhGCVhDJ22/e3h7ngxZaFfF53sy8eW/evJk3ex1x3iOvAvvWm+O/8fGEOywWz6+L7crU +tRkZMI6P7PJ5C6/ebgplqkN8N94HGuYIhhNJKPY+GWEsLHZj73EjnjMVHZgQz+fg89kn26NEWFJ Yr3ffMhYZKxNrk/gYoqSJi3fGugrKgoPWB9SUcSfbIkZAXOhz4h31Bf3FlJy+dYTE8P+iSM1VZW9 3jw7rL1jclOD0TmZgzVpnRzJ6TxqXJ6Oq8IeGYuRDqZ/tR+exAycaR7/WTOPkqvnYRr+xRVYmZ24 j3XmQ3WJpLcGci/bm66g1/AnbxLu3/j0k5GSjpRED3pvEg85S9KJBr0zNisqzPJyThB3HW4UPtZK fnZV5ZZ+YRobvH4QhI+eQGw74jXVCH4gwNe7pz9Mq8CY3U0xm/fTKl8fhasr4qZIsGbQ0YxdwZpu R5M2TxjI47fQr4nGmp6S9P9c77iCyNoaUxn3H9RrbH1js9HY1BbzR5KJVGwbW0Zwtn5eWpcaKbYC ATe1ICK12EDqLW+LsQD/XcGoEVmXaECpwUezoC6m+kTcHgmfKpdC/ranV2YmNprX0oK6zP/OfrcH CSwlij9qehMN9t/4qEDgAY36rc/YSpI7ZqkzmTUVI/n5I/gR7o1OqnBYKxGNLW3J5KgRuigeq2Qy avijyUSyo9/qXmX4vUZyQI2pseSGSMK5/n7r5B6fGX05jkOsVWqQ2oIW9RrK7qbesLK7uS024CXy 726J9QlF1CUWxXunQhcb8ON9llLBUhYy42cG/Q1V0Sc8cr5vIEzULbWaFEh+db9CUuZxZAqt7he2 zOvIBGSaLQtLGf/jl6KuJZaZA7Kw4lXyA4DIHRiO0Eovfb5puMQrJZn/9KQeUop5JBzgC1utpx34 mRkEvqofowY9hFN8nZqgawGmQb5Pe5GCmP8M+GbQfSJE/NN0CfAZUAk0A35gFRADlgLPA02YawLf 4jUcqHup3f0V6nCdJa+rlaYASzA2tI+oXNtIAYwbmMd+s9RJVI7xFOjK3JMw96x1mfWYN0XOa4Xd RuqGvhb8w0C+ey/5QHOBAsiLsM5R9hm0UT3NZ7WuYbwFfizG+HPQKHytB10K+TKMFwA5sPmiCFmr Mc7DeAFik4fxaCACu1tsg/k58LET+kLwgudi3xxQH8/FmmXqBcWnHMA31QXq1VqoEPoxEjg3n9k5 E/vPPv0bRNm/TNj+SbCv4o5vd0FkYY06S97V9tRZD4pztEE9bF3H2NALKcJwX6DJON8nQEjrpInu SdZf4eNi11s0G7wHmCDBax6kneoNCkNXob+KvOmkWjEDitnWbfFNmqQH6TGcF/GmUvge59xDLkzF vGZp30mTtctUhHGY4SH6czpOiA3uvhG0DnG/6iHrU6xRx8A6A8Bp2I/H/tUcA753pXW4B3OvQPcc sBE5MhEYD/0emcOwYXvs8yjvYd8DeWUOApx7wEwHqftx8LADGf9jEuOA8cBcgPd9Ffg58DjwPZ6D dcdh/mT48QLnDOcm5wfnhsx/5JPMWb7HjYgN55hdMz8UT9NuoBCoxI+SnSmUY66sF75H9plrgdfm 3OKccSj0JXbeK9f4nJxTGdRwVcq9ZQ1ybmXQMs59pmpYnqFMDNIczlk71g6VPkS4HrkmHOr4w/Up awRU7aICjh3fu0OdWKTpYQpCt9T1Hj2mzaCV6hnkfzvGT4DORXwOyRq8pn2fPhY7SLgHqRJ3ybX7 Whbdz3APKeux3iBiWaKdo9ckHRJTtCHF5eqxrrh6xAs2nHEmzYYyaOuYMjJ1/638f4E47+qhpzH+ m2vIsrQhegVnJffflemA36GQ9wHdQLmnQtnv6VL63SvIi7y5ATyrhfH7NUxztUFaqI2VdReEfAXW rta6aD7sVPxSe0ldQUf0HvqCOoR7xF7iPL3I4PVBN6TzKDvn7s4lSZ18vQflGshxqKypkPUHWVch 64+yJkPWsE0pxL2B32fZH0i+zXlOvqbz8nUqUW9m5GdWnmbk53zYebPzMoOOYZrqLTlOncJmHPca Pr98H1tlPcl3Dro+Z342Tdsfo35xzPpAvsPnqM2pa2AGEIT+F6l3BO8w7pt75l6rXX/OaleXWO04 50/1XaDXrROi1OpN99QgzUy9ZUVOL+U4uc5RcbqPBmlZ6j0Lcj/VjqKH2320QPbPv9AE13X5ts2U /nIdcg1W490rRR//h3Vby6dn1JeIVNQly5EjTazTPDRW/RPe3CW0ST1k/U7dJ9+giDpMcbUCNQxb xGyCS1Cxq54aYUNyPZ4DyjL2X9eQn/wWNIDHXTnvMt+9fptygFLXVbxHrZhzTJ41KN/x/TSV4yBt N6OvYC13BeVrgipSc4LS5mv4XpDxwBuYEYtUb67lNfXlMmdzpc0s67Ynn0IM1xs0B/sH5V4NVOMJ UYmr1boqvyvy6XH1LE1XG+gRjItk3u9CjypDv2xAfwTUj4Bh5KbX5mWvltS6Jfv9NtnPR7uqaaX8 nmCdTpP1MprG0AzoElSlvoF1nkVe3cb4TcuS3we/pzzeG/Jo6vuEvxOErJffwu4dquIaYx9kv2F/ DiDf3qVHuCe6jyCGo7gGFQXxLk71wXzwAvTbGfhOSlZsUyUg3qNWqWuhD8UpcVycsrr4O1B9n55S f4D7O04BtQ39+wx643z08CWI1W8opv4a4ymQHwK24NtvE+VqudSpXsK8mdBtgN05rHEEesZO2FwE fZMWqL+kdeogvg8u8TcCBbTNoE8C9VSn/Ji6xC3q0uegJ8+3XpfrMzZZX5Y4gr55KWWbgvTVwb18 3opvu3v4K33N9JN9vId/vAavK+0wR9Mol8i6CARtOtwk9lIPcFi8j7lfoq3KUeukcpCiymXgYAo/ oQZJe4Em1Nhs5XlgmjabfgZsx7gS9BRw3ObpAPABsANrnwY9oeOnAkMsQj6DQnYI2A/8ytFlgve6 lzwTLp91cgT/NnoNoNzAGW6M1Mk9t9Mc7DdHW2CdZKhX0EMAfRsVurdQoVoK+WTYZfEuH965t2nq /fy5H5R3abqMoY3wg5zxQcG1y/35/7XegwL3uw14UvpwFe+xzCEao5y3LoK2KufRtzfjLQXAV4Ev cOLp3BPk35XyrPtDrpBK1j+z5dl89r3ejxcn6KlMOHmQzodXqJahLcR8IJv3vEO1DP0MdGfu5rUf 3Qdt+EY5wD4hB0vv5vVlVMoQU+FrEdug5oB/cV/twVFddfice+7e3WW52WUJVBLCSdgsJGRpwiIN hdXcTUNpHtMEQR5xpos8ygyUSRC045g0oKKgxcSChYIlKRLtmMQsdwldHkpmHNtppwWccdRxRgiK 4x+OY/oAB02I3zl7bwhLmTS1/uPsfL/v/B7nseeex++M6pdxrgIiVtbXcV8Ccu8CymncxcCofxHO fGDMvD4i5pUdTfnt72N/l/Tvg/EZ6iWgHvnsJVICXgmO2jy6vq3z4p41vyK13kd1cZb8JS3m7p64 uzewVx7U5v8TsHfeAt4AXv9f90UJ1irgA2SOupQs0xYh91xN8FwdfpuQoUzwVNwL2HlDAyj/BuUN QBHKr8F2BLwPjKNm6A7sI7hHGPi4moX8nZB9ANq405iqO3wLeDbVxvB5Qv79ewu7UvWHngcehw+Z 2dBp4FXgZ0AF6tjtfB/6DvAvoS9PtTWE8vB14NtANXA4xUPfAYTfjT5+J/KRD3mHfqL8oPfHR2Xr nRGx+b43xER46Ufie94c9vcfj+23xIewnAdr/NqY8TzojXMPY/24xwK5dEDklCKPFrmsA/mzyB9H WbzbnpA81WrHZq+4A0XuLPJXx0LkzKl3XtGY9+Ay+94Ye7bSD8hxwAdkW7wNMbfx1rmEu8mLM/Um /t9JAXm3iXsNwHgvS/9vRy6KGPA70HPAN+07zT5b7ztjx7nTPml9onfkx7hTwxZiaXiQ3cZiC5UC 6XfxRDHe3f2x7/IH3NFj7+n/VrfveRvj5aX35QHj6OO1N1E9Pe+YsJ6Wl9h6Ou7zp689O5/JIlmj SNt3E4V4W6h9d3N/ewzp+3h0v9lvhBbcqWOAc6AAd1YhcALnRQmQA/iBF2B7zjVEwq4eEobeB5yB 7e/gTcIHbqcHcLjdGhmG/nXoPvUdGbvWwqbx1nP6uhX5ucwPMWfyHGwT4yfFwFLAD5wCttvfWrw9 0fdflQuEiHeuWj9yU70EpOWA4/IisgPoge6F7j1HVo30s+uJZcvCRhJc9LBks6AwfFY4zKyZ4Z+z 60o3mUs4DNfM6dnSc9UsL7cKjyxOFRLz5oevRSexq+QfgMKusmuYdFkrUfBweDCqw0DZczipKeGk g/2RxAGFGOwPifw54faL7G3432Jvkk2y2pumPiWMBt9grxE/4ewM67M8fYmMKWES3YkrhZJ+yCvA ADAIqKSB/YS0AK1AL6ASLyQHioFaYWFdrAvj7ER9L2Qx0AC0AipZxX4K+zYh2atsK5mNus+zQ2Qa +LvsoOST4CzwCdhngV+BLrjd0o+Bhf+oZX8J+nTwEYsPw54NfhG64B9Y+lewrEW9XRZ3sJ3mLO6L zoI/FygBGEqHUDqEqTsEjUBS9g32jOzpFDgM3p5iTFezmReQ36g58dCMcAemtBlT34yZa8bMNRMV riY7pikVM581IaYJMU2IacKslLCd6G+nSBYgfUAuwDDvOzHvwh6H7AeuSPs3IduADqGxZzGPhRjV frbVLOBYZFsSjxrhsvPsaUy1wZ5OzMgJt97V3JPEQgRnWOwVsZuld3PCPVlYNyeyclKMqG3RDLaR fA1QcDRuJPnAp4EKQGUbzfxifo49Sba7iJHBW5QW1qK2ONSSCuq/yMKkDpk0J342n0QQUMhjEVq6 3t3o3u1mPneuu8RtuOvcjgbWwloZ46yYlbFaFmOO5Ei/6VyyEGQs15YsbPN0eOKefs8VjyOu9WtX tAFtUHPkaiWaodVp67VGbbfWpnVo7jatzams9zR6dnuYz5PrKfEYnjqPgztpR3Qv24C/SSB9QCPQ BqiY4xjsuewpIIavEcNUPAU7gSTQfMAVlAfADmhexHkR54XVC6sXVgIpPHXAeqDR8mqjHruOiB8U HgDPApYBawbmdgByUJSAKmg6NB2ajqgryhBG6IPMBeoAJm0DAFYNpO0rsfzrAU36B2WM7TNEXWXI +OLc/kIaL6QdhbStkBqRsmjYmA3h9/tjgVgwVhDrVBsCDcGGgoZOtTZQG6wtqO1UywJlwbKCsk61 OFAcLC4o7lR5gAd5Ae9UW2t6ay7WXK5RYzUNNS01rBSfLmEWlYQlzw4K7jNnZIVLvdGlSi/+Tgyy HbgGMMIhi4EyoAFQlV5IrvTA2gNrD6kFYoADNXrE8QLJLZ+wt0ufKAm/co+f4Y93m0sW1karcOTG gHaAoe1u+LtldKrUK+1xyAFpr7XiO6SdQ9p1GA64ennM1WP71ZMyIAY0Ag5yma0h1wC0DMmBRqAX UFk9fmvYGqUHv26lm4UMfcE0TqZPJ4T4p7h8UZ8yGWtAx+Uq5BEp90tZJmW+kVGl36rSf1Glf6tK n4uCUkCicBySMs/wRPXTUb02qhdGdbT2EMkjujJNSk1I+jcpn5QyZGTm6bfz9Pfz9Hfz9Jfz9B15 +mfyRL2Z2Lu6kimlR0j6opRVUs4xPFx/netruF7K9ahOj1P0TsqlnCVltpD0vdPeCi9xn6fvkQq0 RM1IIU8qRBIdMSNR0B0zshw0bEaOg/5lRg7yC/Q2lVcavWXm3+DRafQDWqkK/X2L36WVpAs8CN4C /jGJ0CD4pBnZI+J/hPpHoZ8gs10i/hVSJ+u100ppf9mq90MztAG9HjNDX0WvR0lI9nrYDN2A9aAZ 2g96wQw9A2o1g2KAW83IPB6dQreQfEXEbiRBRYykxurxCbT8DHh5qvIyMyRqVYgOkvQxM7AANFeM 8gINkDrZHTcD8k/mkIBsYiYJyEFnk6DkDOqVg9fJbMkuM7AHrWingzf4PyPnxR8nN6nXPM7/fAH/ bzXUP9FKs4v/+qyYLpNfDiVp8Ay/FDjPf5WfpKtN3h9KuuC4GEoqtI+fwiTHEavQM7w3tIX3BKS3 MwAvPnV7ZD4/FqjnLwWhm3xP6IIYBtmOf7wa7nWhz/KaSBd/PJikcBsRdGZM4ksCX+KPwrw4SSsT XXxBflIMpQRtdJ3h89DjnIAcyudLzymLiJN+2Qg5dzk3OFc7VziXOhc65ztznTnOmc5Ml9/lc2W4 JrsmuVwuzaW6FBdxZSZHBowigl2YqfkEaaqQqiz7FCEhxKmvUJeCvROfyqqV6pXlNO6vJtWryuOl RdVJ58jn4ouLquOuui+sPUXp99ZBiyv7kpSsWosFKkx7s+P+x9aeJZQW7z2QLbhp74F162h1vH8j qd6QG7+1Ev9j0or6uCNQ/qn/sF71sU1dV/ze++zn+COOHccfLzZgP8c2ifPpxA5JTPyS2FAwiRJC V5thcEhC+BAJwXE7AjRpGZ2ajQa2iaEJNdXG0m5Iw8YMDLSlgnZllSbQtk5bh7QvNFXboq5rBNNK nJ37HAHV+GfSru455/qe37vn+p5z7jsPGZ4NmALFrdqmNcEnsPgSdz9qJvfjzbQsdTLcG0n9aFk0 5aGDxWXRcGptr3VL5DIZJSOh4GWyj4po5DIeJ6OhjXQejwejD2GIJ/sAhvxUUFgG8RSGeJwRYRtE GIQpHwqmeT4Puo7XURCEz3URNJRfqwxMwFrdVACMLEdl4lplZDmFQTzkFyt6fDEVwkXiYkUqJC5m oaC0wwGQSgeFpBsdAEg7GkX12UdquyO/nShyiHYcOCrawfgRZmUeA1GwhCEFgHH/P9tg+/8Axpm+ OwP9oUF7KG4PDQLFU19/dqcpNbndak0P3KEKa4pxxrf376SybzB1xz4YTA3Yg9Z0X/8T1P1U3WcP plF/aFMk3S8MBs/3CX0he18wmpmd6Ah/wdbLD211TDxhsQm6WAe1NRt+gjpM1bPUVpjaClNbs8Ks aCu8sR2HuyPpAtQe7diSlxmiVEA+xM22aLtBs69VTI4Wm+l58xUJgteW0h1NqeztqUIgqqpqq2qj KshOqlLDdNGSyvR8i818Bb+xpNLAtNbejtzIFNoVfNgTicQYpWTSDXwsaRLnxiBpbb3h1JqezZGU P+UPpYR4MIqpO5JLrSMiaK75b/nJiH/CP+2f8Z/zS5PJKEwXX+Nv8WQbP8JP8NP8DH+OZ6liS+Si 4J/hP+GZJEQTHoMWCoo2kyCh059jyQRtCAwkgPLm3El3R6SNR/1Q7WKozKuQDsgOVA/UCyRFN4D/ EujPQJ8BSdAR4N8C+j5Qhs4wVUxVyLQrSC1G3fTSMTGeTK3XsyoLsm9HXvZuzstQV1762zwmkOcD 9Yq2Iii8MboC/AOgj4D+CvRvICnjYTzi4sl81EYTKOHGsH0EP8YoS7jHsBsGmB73WMLtRpRogIMH AOrGX4x7hBNJBEcBDgEBIHE2QR9LUvkICHewBSGphVbLSIY60wRfJW9DmSoj184jqSRL3r7AIIWM Dn6CEVfASq+BniAGlyM53oO3IpNbc8+/4O/SzPs7F/woAGPNA2B1tTatTesAhi0S9MDKvPNAkKLP kVXyDjx/lLGTN6V7oB4pRacvZbmb3H0Vo8ou/itjdzSIsqq2AWcXP85UeBtQdvGmsAwGnAlY6Spg 91VYpjKqiMJyVD3kK0RZvCkjY0rVIM+XMCjLeC8UFiokahgIhtJSo1axV3LDuBdpsfao2fJt2+5x uN7vxRbuzWmLm2ryDAUW/AG6cTcejS3dIPsx43J6G3z1HoO+RMbYmMd+EMFnIKuq3U26ptz2RoO3 qrK51MfYcdkBjgs0N9c93Z/7HV45Xik0t9S5Xsn9lp5xePGP0s/hf9eh1WgdjgpOFP5DmGjCmFXL zUqrQW22cm3s2ooRM5T59SPt42ZW4sFhWrGXGBqoFCrVxQ3lQr2rNtzh2i6LW+Llcc/g6n2esdUf WVWqQreObfW0lVtUhaSCZbN4g8C3WkpaWy2MpLK6qrZGhustFWylu1XXJpfXnULkFJQ6Wabnwqo1 dkaeJROCUrP2lsGgUdZBdGRxbQaFnOxbUKi14vcRh8rJTy9ZAivCRmNpYRYfEXTcCid2vhD3Yu/V lvTIin0rCJRAVYI56N/GjXAT3DQ3w53jrnG3uN9zn3AKjlsPb40jGdumzeCCrvlY59x8jPb9moWu 0GDwL52a+Tna70Eg0XjSzGnmAnPzoiw2NmGgr6mr3Yc172JwG3SRND+rq8XgNTQaw7H9o9imZ1ki MxjqPb5GI8vaeadL5OC+RifwxrwXWZnB6PM2uJwuhw+k086z+hKDzknRMICnJXp85pne1HD0G2tD 8RKH48zejT8cOPT+6A+u//gfNfzz2w8/d/JEdmIqtdxQnnvx0MFo+zNR/udf3bH6KwemkoEks8sh C+SuT+3sDa8zH3spunv46dT4gU9f2Hl09dnNa44N7X5t25/e/MXx6jKzVNlycstTWw801x1Y4C7M HgzN9u35nocWSj0QU6UQMyrUI5gV6snlQz4lTQQVTYSs8qbyN8qPlRIVzYFLLKMGx8hpAggKlUq+ l5ks3HSG5ugcRHiXhh4wCnTSKMf7IcB1jwf0qz5jQ1VVixjEKw+6IW5rHSdo3ELVlVtPDklfQTrU LNhPal/XkpdUL2uJ4pRci05hHVRzCvkbar6bxexkyaat1GBsbsEvehC8V1eLwC1Y73Q5iVeDGqlz 9CXG5YQc+s7g8dPYc+/gq1220vWHcyOODTtO4KlfYR9eHK4I/j138r1fn5t6/buwh2rYw5fEPTQJ ZeWSioKnpAwY18ImdFD9yRWwAStbywosw07qI2f+exM4pvMajIZivQbJvD5fMTi+mlSfGpw+nbt1 /+BMp40LH5IOVIR3fDP33Ie5D3J42BH6G97z3oepqVm6Awc6Jvmy5AZSohmhtIbUMNYCq1xSg6xS K1ujHEEjSjYOJwC3fQ+SMS6kAKmE144LERghVAAjOdNzUalEcSmWvgWT8I6lnHFdwvECXHCVVWYZ l1AqjYO5q1ZSSwQoK28TqZVgskUVyZ/s6HwMbti7MVQzd1dzN6bxL6XM/MLdWP6oHVqb16at19r0 Ni0x5tT4n914Pqc6hj/biD/NFW3MFVKvDufOwqfsTWREvYIrSqLGdw2M3BjnbnOMHCOZRFJUUIwu FgsqpaS5SL9CP6ln9FlcAZ8WRduKSBFnOg2HDDd/rHMhBtfn3N3iJshJYxM9aTyq8/rE1LLzsqXM y6fc8NCoXCZTOopL6prDvvah6dzZSn66W1coL5E319etSWwbStPd9eJJEiFGuDUDgpVIJ5cN+Cak mH4+pBgGEQ3uxnF8HL+Gb2MWLqqG/zBd7bFNXXf4/M59+fp1bd/E9nVs5974kcRpnABOIMhNTkpp y6t0ZS2FNkvwqhJG25AU2KBDeYgufUBJp1K2wRJ3rF1fU5umpCZM6oa6B+ofTNqmqdomIpZOsC4a mkoZA8J+55KWRvLxybF15fN9v+/7fb9jZEDkpoLO0cE5b5jF1XYFHWFYR6VrV2joEH/yC9dnoIec RG7qWJQw2SUwlS1tUllbU6cKY+rbKlWfcvMe4fu8F2XC77agMWX/+hs3AdLA2rPZ9vaT9pptYPy5 wvUZ2ooVKpB7mUqkjyo3N2NhckI9VCijFH82eqoLlVrJykyhUegStglFYVqQhRPwc/qRWIKe8TO2 Wj/jgObb8sOSbXW8KUECaOtc+T3wqfT8/+6X3sBnkZXXzwnvS93ER5Jk6t1NDhOnz3clqZy/eTyR EmgsoEZImqUpS3eli+nptJj282NvJ+kh/eQAKWIGMlJTEEdo59lEo+jo/XzN7Lxslu1iqyGZSFYl qUxBACorqWhFrCJeIch6Wku50mEjZFDZEv0FUilHClDmxV3QjbskmAWocOAS8JUXiOHExe6sfMnY r0xmUM8FuCGHgv4yighXpxf7QrZ1N/u5N9slRFfu276x68h3Dz/9h8LJwcc+XN7S27w9nm1MttQu vb3prhwdPQdr720f+/Xc2/+amzz4ya8uzZ0bP7ip7y1oOXf4iUbr1nVzR5CjCyg4GRELkkOsjIW7 wsXwdFgkYRamO8n3CPW267AF2jHdFEkV5hy+d+A+gQT/l2iwhQTxhMB/mBc0jaoUJNXhpgKZgkv4 9RUs4PVqzN/UqPVrI1pREzUjNEWTMDMPbl1+jQ9Vm7fZ9XPBtJCLs1fhYl2dLd3eDj21yF8WDIbK raZW2sQB4Pe/ACstPf/QHO1aEnQqqUjqNvG3L18Z7lsSp6kUjS3YTf/6YsaMV/I6vAXv+CbeMQ7d bEgJu1pC4eituTDDxeCLFg8Ga5W8skJ5XZGZ+aC40fFgaGN4q2O7f3vgiOvH3h/633K95T0lnQr9 Lvxx6OPwtHlZvBwqL4eYaEgV5UbQCMXCihpyhV2xnHGn8UzogKmEDUpDEcNtyB7BoJIcDvGuoosY E7qZqrIyd9uACmpJWMTcPilywAAeDKgxJSxC4PZPAHXHS7CfeYh8dq3eqffo/bqol0BhOsNLRYjJ zAFT6DKLJjWNE3AZdeYBxso6aQ/tpwfoB/Q0PUP/TR3UqJyC52/W80z+RkV3rEFZ+biwZq919GLY 6x2X6bKvP/D+ARU+UE+rlHT0bqib4RZmM4O5gvpufOW9PcZ+Az/f4M0P+6Q9H3pRktDb14GM8SBd B4LVRMiNBKEkmudbqqxQxVrY3LxYeLPz6jRsAnP08YfH0inj9OFX/ta48tXLrVB4dP0dEZDmrqTg NvjB64Ov7ug9/ps/jmze/JNjcxeW+BbwwWUdqvx+5HMhrD5OnNen33W3qDwK5t0t7epy5x2uVVXi aRVqa5fUslxX7nRuOnfJqZActKv9id3ZN5LHk1PZU9kziTOpv2T/WXU+5V7hqC3BvomaGh8p0ZmJ 3zdCY0nIHRMkXxCCJRg7FmN1DblYCZZN+Dy1NSegm5QRlf6due5BDuiIzQEyOfGOG9wlGMHz+oF6 OlJfrKf1eH6sU+nHu5foJ8zJclDM/TJHMcdD6/tM/0CnurGIG865Lwmy2ZnljQ2XGZwl0HrqZvva ZjtmeTS3Pag52xBPOzVRrrISVtJKWaIspbzptBPNpUGsL0Bcw53lqi6AU83KjQWo9MS42/jy8xNS ZhD/bI31kV4MP8225yBPQZssa75JhVB83H3sXIjiS3AdcmaV7qXje4+uv21qz8C27899+sw3Gywj 4v9OKJV55FAiUln30t3m2rG7BrsOd4srnzn4rbUbXxxdMPnkO4Ov3V4du8Uhtcmu0UfXrloSq2mP O7+xd+3m/le5h5uo1uPIrhOnoT+zmqAHNLLcwzSBaZBxQ7mChguCKskgul0eIro9ouz2oKqiLKA4 yhTF4RBERXY7SKUHPCfgCM5vLhhjHglk1SHLDkl0u8UTsAL14oBHmEtVNQHGhLcFKpTgEgtDmy0v DbrQr6Y1QZOZAorh/YqGevM2Q3kUEG7/4eOTXltLAyYPnsuv9eX9LX5bMMPZOnE+mmuaho7Wh2mk tw/KE/4EZhJYhG8gHJ985dpJuuPxV+aS8Nnzcz+CRwaEoav76MvXOrl/FbDed0mriQVxtuynIgQ2 xLfE+6V+uT+2T9wfU5pok3WfcJ+53toa3Sntig7TZyPPRo8Kr6nFxHRCIwnQfP6AXh4MOcqw8woc Kr9pYcsVTStSERWUsCjh6diEaVr6FDpJWNAZYgpnCT1rWZjKpqCVVMCdxwaUIq9juIh1nACW6ErQ BArk8qSPFi2w+EOYajJf0Ud9RtUUHITzNmIzHWjzvg6Ojl3aM19OMnZBo+tzlxl2ZOskhIvwf24Y DfP0QR/tM4dgiA6ZMjoONxr0mWUPPcBcW8WewMPxbdK2mNSxAUOWYikir2BZ/krGmi9erN1qEHbd Pde9AdTDT63f+7Undu3uySYi1Q2r1uwYH33usV+AKK1+Y7J69OnS1smB6sXrFkbrfFZuvP/JPy2t V6jGq/MB5GIcqzNMashVltmh7nR+2zukfpw6n5JlAfYIu8XdwadCYt5RI0tCwqgxZMHsxCiL3jFp 4miY1jCc7Z8IE4mHkwnNAwgu4xyxgCtCMixDWaYrU8xMZ8SMcQN3/IjoPt3UG3Wmj+hFXdGN2psR 5SoGzpn5jGJbBRo6ooozJB8Qb2L5nkuukKkNIfrHLdGUGohF41Eq+1OedEpNoEP4KgrE8uIu6UwX IBowC6TKjQv5IqNw07AtA8q9gvKFr/OM4s8Fks2LgM+JXyCO5i+8tPdnR7cmR1547v9UVw9UU9cd vvfd+5I8kkcCAfKPQBJ4iSGRBENAIJOXqAgTBbGiVhDQKRTx2NROxT81UjvqnxZnO0+3bi3dhNZ6 3MQ/mKLHzp3q6sbpcds5s26nG/Wo1Z6xc3YO8+xoA/u9lxxrCe/d+/LeSW7u9/2+7/uNd+4eP9Rx +SjW/m9TYjxzUU2gbuWBV/c4V7JdAt/wy98fWD9x+sPDH7acxdZRXDu9KrGgf3n7lxHf8bdOPrJB FdTP3CFDUAVqdOUjRGcmzuot89j4zITogYlJhVlSxEWQyLfzg/wf8HXmc/w5M8HDlmI1RrzIE4al kCjfEM2EySKEoYRnxUVB9jZWwKC4jYHmcfzT0UE1Vps07BhzHxHmK1GDqI6KtJEOUpZeYu4hTWrf pW7qjizXU5KDenSTnmQ+7U/f80mKvNyL7IuK/ex+BU0RFxzyBdhHSOAQX+0Q45Suz5ib06Hn8U+m D0X9zwSsbL3z0WV61VLcrgYhRLuBbweBbybkRAG8UxxbDa1dID9Q5NoS2OmIqWOamDlm6RNizoOB E8Yh8/vCWc058wXnRdfVtKvqm3yOEqVhBc+YOVcObzALvJC+GB/GL/OvpJ9A6VWoEi9Gi3HdrDa8 xtUS6Ebd+Dmm09nt6grswrtd27y7AwN0gI0pY6q+jL7MgayBnLfoMdWbGccy384Zdp5ynQrE6ajq gfprzYP0B64Hc9xKnnNVogo8dw67QIU0ZheVTzqDnMUV7Gxp0PPWMAe6zgHzpcMPcx1osQ4FxSAj BtuDg8GJIA0WXIIbBGqgCGogzW8QDUcMxGAqHcP/TgmLFM+nZFGZvDOVTOgS4bHUdQHJ53h8eY6M HKrKFuxsAcRxpXUd9mYVrUPFmeCIDgoWmSfFcU/O7HXIlzE7SfUU1yV/lMQmKqHm/LZlU+YYkr2P S3pPKEtxXWK+XiENKbfEB95rHT9x/NOek6cr6v82cqWnuReX7BC3bdwYC5aULW98bXNPn3MRc3L/ YPP+j8+8UP/OpleXbowO/LG3Y+uzI3/t2dPw3PZtDaVdvumvaoba9729c2VtRTdo0DKohA+AEwbk whoxsMt1i73puOWiXbSX3aPayW3X7OB79dtth1Qv69M41YCbqVKxLqPdZWRJnkCRkh3D65ERi+dc jeBsoEwi5xO2CJCcUZ4ETzoLGnX4nMGAeKOkQGasvYAydZm2TJIZxxtAjdyiO+YmorvdPeiecFM3 ljTMDo+JaR+nMWmmWd/JM5PJQJNIqn51Spx0UwCVrPtytJTxKrIUqjI0Tp2Q6yxw5vP2dciqldom Fcxs6jzonTLg5OCEpyVJAkr2BEOwrCyzPKn85akww4A6YQmgJEKyNPX0TfzJ/Yu9A+Mbd117f/vR f1x77zITyIz0Lln9o9XhtuKXcgXmh7jwNxu+uHDm0ImDJx/fnu7d18181Le048sdg+/8ZXuzF1A4 PXMHHyGnQY8MKDJCTHEsiFa+s+yIaRCaPxEpNSDoWjGbiFzpkezBbCb7EhbAN/6MUVI9puTsLbeU uNWD5yQpJTFK/9Qc24vD4WI4vL5wRBrJafkSjoQ+kpxFJGd6ffokjpMRWE8BWi9a7MKVjM6ya9pP HIyGt+izdZxm1KiR1pUVJ0vF/DzRqIZIxeVzDFdm0VVq7fn2mJ3YP7WYCrt3ysAtSUB7ABEUVSdg lT7dHRknGSoc/c6CSbBMJrzUmD7xXbiLzanFr+2MckqlWsjMKqlcXBbpHCAjYnLt4qNHXsdAo57n srjKQEnN1rbOEfg1Av47bSFbQQGVaPeIQhknrlG2gbZRhl4m9fAAIS4wBTQTE6sqodWIIaYRToPo BppALFIoWJZhdBjfwNiPRTyICcI6bMMEt3BKSglBLapVayUcQnJqe9gKsUyeourWqCeUCEG8S4RK /CDV8kug5Y+vSwfZ2jTVBF8toIt0NX0TQQ4V04zIoGA8pIIwKeVXI6pSsiLHl7IY+XweeessZ+CL 4ZeIagWbpSCMgmWS1xzCWYhQ+NQxEkEKEjlDbBQUcgESEcvcAiO6BbmYwQtEj4hxNd6C9+IYppil jBY3YEa6HsDvYroFYy32wVttcHeMWQ7i+R9xlgJS5G9hXxgRtaMjsElUBx/nR41geeh52LZvd6MV /qKhyW/kIRRCvtbopNmUSJiNMOgmJyGiGeVI+2Qi+Zqkjzgo/dPVj8fJu9900FLmteniZnwUH1sz XSTxs2XmLqliNyEHKkb3z3MqrZ9hJPue6w+W+vzV/gZ/m383d4gb0gyZf2XhnCoNn050OYS151Os TdenKVhKdEqG2InTu1eP9XE8ej6txgTAxkmTaCkQ3Wroy5DTqxz5pxVrrdja79Rtzrnn9cfx5gtO 0eb1exnvRYZHPjCc8rP2nz9r9HhAlu6BEkGmj0py5JPY/jAEubQVJxtfQwWSsMtIRSlZpsyGXJXG IqiNvBVxZqUVawxpVqzKhRNKqhIoEtR0FBdAt/uUPzypmKQ4QUxVKJ8u9mtuZcmSUGH/upU/CBXb ixb+bvizjtrwmh+Hs1PVj8WXht6I9s7be6zJL/TkFpYs/3701ztWbar7WdfxA1Nhn1RTvrC03x3T NUov+zqKoGfwF2L3MBoO/ytMIEjk6kzZuY2mFbnbcpRYh2bdR1+HJ5ofLqSrGoezh3NuNFNbo22Z ranNSO3IhqGzbaBdaAPTae1HtBcdRI/DZEQVjkQCEdTQVBIJM4iqqbmoIRxg6HwLipOIyOnm4Xld aD6eD1cXItoaJ4oocy8CuU3IQhadr99XlldjiJNlYpmypri0LK2pk84tKVnRrK4pqjafsln8FtFC LObmirnaulgdU/eBvtLm8DtER6ODOkwrmuP4FgC41hjH5a94PEslkwG1WgoElvKABGTiLqqeSgCy gO/d6upJ3X9bE613ZbtJug48pLver0sPyZBWLVhc/j3Wv6i2pnZhLVFUVYYqGYXXyQnZTpuQIRT+ n+yqgW3iPMPf993Zd86P77Pjv9zZd/45/4Cd2ORsEtyMXPgrAdKkg7QJxYIOWhCtWBwCpe0yoqlr CFoVBhMrMCgVjQartXZJQxwYrENsGiDUoVaIsk1QtgYYCao2WvHTuPvuzNimnXPfm3vtO9nf+7zv 8zyhCBHJ877V1A0W1zZ5gDFOewBbVdoNHRJB4qZh4PLwJI5Ct1DJ46CWUz3AHCafWJie2w0X1S3x AEOC8YCSKNMNbD6nfleluxitAY7EEVg2jeuG4CGtaUjSRlL0f47p04uyRDvq6kAmC6l/iw5rKonk gJ9GdpuVVrygQkHA55dRCluBUkNbCR0+ZEdjMVprdYdUy2hS9OFDCGAJXg29mxrdUW/T+Z2DhY+P Xi90Xz8HOz+BDDzSnV5eCBUu3C6su3YX/ubBR7D5l4e+7l/SbP3J0LzHN5z42cZn5nZg36nFzdnW xx6PpXt/5K1rok4Wsle3yN7YTrhw6F3o3/dlIXl3vLDtt5Boi8LtQu4zuP8uZOEZCN8tjI6NFva8 s7Cx7pnh9VvX/xiuyy6dP39DRUv373a0N7S0j654a82cJwjCMQCG98lEcQMJuX6F9LlrhZKIRA8g vgZ4JEjcje0kdQ04ycmQs4S6pjpZ5BYpjnU7PEDqJHMUQchyiAXxBk2YnP/j+XhcwweZdrcnYLx4 4J6+06cxOWdoyGTNHFeOS0ST1Ooz2rkKzFt4QXC7PEZf/psPh4IpLQwn2pN6jFbrcWhaMe0NFdO8 WEw79fSQXQ/qT3FFspwrJQ+fxS3iFuAmscXXwT2N22zt4npuLV4nbsa9dJ95O9eH+6z94jZpH7cP 77HsE8e4MXyCHxPPcWfxHzxnxT9xl/At7ga+Id7j7uJ7nntizMQtFpBE/AvZJOARRbfJXCKYHG6n 4GARI7B2i02wbxE57MWi2+23YJul0wItmDOb8+iMakGiDSFR8gwS2tA3Lg9H1DIWc5Td4WBZE+vO w/uqiSP3oEGzasmjxHCLCMU8mlDNXtXcav7CTJl/7n1hu841lTzpWRePiX6f1KQheZH1TqYeT9X3 maujBo1nMmZCNH2GntNRF8CTEH/4/2sf7jldz9STP02ZZB51CuzKdECfjmun3ZciwK6FCnQULzTB UoqoI1P/XOF/7DuFtrZKZTb8SwBempVZOnXzyVmRDeMT8PcXW8JSnAkGOVdiF73iwZvbnjQEg3S1 L7YSliN56s+aR/MDQI8TZyqCKKhDPWpiOVgu9oNtYr+yh98fzvG58E3+7+Hr8bI68Er4ZWVvzR5l UP6Fcom/FL4UKaHTeXR9mFs7M62hwu1PalH9q92ZVFRfjCyVYrJGDUTIIniS8+R5wX7+U3hRvqx8 HmRoGQbLazBlNwq8TXTIjog9UV0zX16UfBq2Vy4P70YWDHC6DS6XV6U7073pg2mWT/A1rYBwKS+L kco4bUSU6BRblG3yXvlThfGm1XRrejVaTa0yrDKuYlYlNhs38huFTrFb3hh+JfKa8XXhdXFA6U2f jV+O35Lvy5UdLCcJJp8fS4LDF1BkomViIBWVZMo/rS6mUNX+SCplckyLOJ0OVB3RkLIjBEMa7NMp PczRQu9wQ2NSuxyeu0CPqo3kl6x0wxIx4UbuNjoq1cVmaG/g+SmrSh+kCfccpK/SFK0lS8otSUBD Lw3pPLygBmPGigrUFivjOG0tLyern2CZw6iN82qX3IFZ6V/DC8AHnoUuosoJkUSj9c2TBDtTRAVm snPbx8AMquqmoIfJDjKO6zWEdk3qAOsqGhpy6tLhoV6wFJVCNKoTS2M8GYi4RMjwQqWAjMaQTIyW Eoq4QgqMMzMUGBBDCpWEMxQqLExTYMJQrYCgx68AsYZKKRACQgD1/2V2otN1X0rmfldXF+jKPjKs gFggWLSmxoAvpdSQQW7RVHkg5SNyQ8sHHfqE1/UIYyn6VN0ZMdTQGwue7b3y+VSv0hZ0esLNClr0 zurdB7439Wpw5aydu544dWxNa3d25ORTpwZmtwvoA3HOih8+N9YWnBnool78vi8WdMmjLz3/Nscw DT9ofumw48F3hUNbWnYuow1EfYJF33xm4MisliFS55jEOIyjOBWXdnN7xEPcIetRbtRayork28Me 6lX7Fscb1HbHfmo3n6OOU6Yyykwjz0KqgzLEWWyRicaAhhEkQHiMqI3FR717DRE3BfPoyogl+j6G OE81jgyUv1WOyvNUXI3bTCgHIIQ1OPeeBUqWBguy8CoBoKne64KcS3Ihlw4PV1NwzWrd+0QzXc1E TmS+6soSQZHVVGH2TubOeMPkxB0ycojGwGf08nrtgrGMCfKh0pAjaBRMVaDMTha20lAFS5zlVQA8 qlzRpXZlM7AioG+6RtNaDWqdRjrgDWt8LGvCUKtcLX1BkmaPv913uWfz5JuvnX1Zer7wxfHCe2Pb j8KGE7sGplsFG19qeKGgfHS0v/DJlXzhHzuyh20jh+8f+/ocXHZ8oaNCSGg7T8Q3/QGZTgqcqTao qbXul9z7EkdcucTxxNUU+1Rlp7GT2cpuNfUae5kBdsBkkiXB4/MHJSHqC7AqJs3C+sxmySSwjNZk Pi3D+BCSjALjxgKCAcKGHgUMRqtBFa5CVXn0MRlcsSj5eYMe4Ybb7WFNOZY15hqYrQwCDGZaGIo8 a1xt1Z+1uToXi0pVcXLri3zOS/j1CtF+S1tTnamDKSoFsN7GWG9jrNcJ+4NymXavrCdlXkvKB5JX x2Af0KiF7Hb9lLaQCmYm72T+NvVVNJOZJI2qdewE4RcSCjrRkMYlRk/zZ3hyAuAvo/Bh1PqXNBTx AT6tHoolEAqTsvksNtJEWtVIjiq22X/6TKss+Q/m4PTucNIYDJrN1m+3FS7iSN34xnWJ2Y2RTQ9u JRJRr5OXlyVoOxe2KzWR5/5FePnHNnGecfx93zvb5x93PjuJfeYSn++Mf8WJfSSOIcQhF0IIK2vJ 1gDN1qhEpJQNEE4GBYo6Mq0aK0NbpBU2qjVC6jppUzqFH6Uu6yDbukpVh8a0raxSp+UPtIEoG6Ns dAI7e97XyYBK1eS8P+699/LH832ez/M8NlK+Es3sqiQ310eTle4vJIKR7IpnK1OxoGxt5ka/Fk7G Kpe29dd5qaI6KKqBos248UQyW8Jha2lsJO/kna7pLPf99Nn02+n3ud+nr/JXXXf4Oy5n0Va0HwCN x23j9u+AxoLD5WwkDt3jKeG4JQqqo0FTg7phB1HpScqm2iVG8rCmxvVouinpEjy8jYDUYP5gM4rG UVJOkiRVOpZIxEkgKCTSySmUwihlpqxUMcWnJux2zYHXOfB5B3bQQiGDJKakxESTmJKSEW5gSjaw wwamZMNkZng+DCmOmZC3hkbHClAzjJYvg4Sg3t+H/ieejxb0FLrA3Kp65YUVJIR4A5ZjH5UMRMyQ aNRXGwROtrbW3UfJBf3gPX759vp1YiyGE72rbosuaByXlM+aA3FFdGngFNw/xeii3ie/DKJdW7uz 0rbuoVhlw1N6yK/EYksiz3Dbq/vKe08MJqlea4B9PwH25fCQNeDiV2dIKLEoSWRFDpFI3spvyu8V ikoxtLdxQpkITSvTIXdz9mn3QTen5DOL+vPF/GH+VX42z3u4b7hn8twaAXRRPjL8VLVojtHwFKMh PgX1yFqrZ8mLTUFFMezJJk5KGk6c1sIeavkwM3LYTo0cNny+fv+En3j96/wE+WX/Af+cn/fzVA2/ vzR3+TS95i+Rjy23q9Afx964FieQlm9YMv03cZm+j3+mbeTQvFbATIizbJpJxVQDra53XacqyQvc nE+LuUjaIQuxZCKVaExwdg+kRa/u68ARTfY50q5mJEZhkiNSB3Im7M3YHZOa0QMtUWMVqGkWozQR UqyCihFa8FW56qPJrU2vg2Rnr/NBVmSQhcBlXQ+7wl8F2Qf2nauUD44e/Wh87eFurfvzRAw90lD7 ldnnK3t+c2zDlpNH3n1o385lNTUqB8AdOP653Rde/ccvKzNH4jH8zS1dejyei+2oDK9Yfvfnt0/9 8Fdf2qik6qKtoHwUOpSXIFJ78Z5qf/J6n0WNhmKluX+/RhWJ5Upzdy0/3eaY7+eYRLkauGDV0OMa bDDtDBYvRmnuisUCxmAXjUXdMvQ1DTCaYGRhZJAHZieMLhgF6HjcnWjx4kwnydS7COrKsj7nArQ3 H37IJpyl2WnmQpquf07PLDHTqjVa7Dved7Fvto+v6Zust/L9sCXgcW7dMDS1XjdymprRjV5NXaEb RFNderRGU1U9ComjWY+2aWqnHgULRBcvVld0drrdLpJpbq6vVwV/jUEsA//FwBHDNIrGceOiMWvY jRKJWIvkvk19M31cpA/39caMtv7cphzJTa4e/kBJPyzfGgMYFOTRMQaDcuFezwC/KgoWaiRoBIbS mJb/92KbuQH4wSeDX/90HMx/gl8hTwMH0qZJVjF4AwiaTLP8pvloPFQ+xF4tKf9sHhHwhvSCEaGs uISf21oFQ1DuHrl75B4l8EuVzfcxY9t91ygzWhEie8FzNPQLa6fOsrDOXEe3km0hfdg3khc0leiG oql+3QhpKtajTk316VG/D0AtKCFCvSYkUC8J8fTTkOEsCuPCrMDNCdgU+oVNAveEMCNcFDiBp9cE 5oFCae7j0/Rb2FSsBlYADEeK+rg+q3Om3q9v0rkZ/aJOqCiPgBIM0xD0o2PzrGaArqpA59in2HVB CbL3E6YDozKTxh7gKd3ffYHtqYWg67L9CSzUQ6at0n7pnES2I3wA7Sb7pafNfW3P5M+7zorCDoT9 fG8GzJUn68mTZJw8b02QY9Yp8bR0tvVszx/FSy2i3405idiJreVb6GDLJJrCx6XftQhuqBkRsXk0 Z1hsRDGcdXY51zkPo7dz76ObOa/THXKbuI20Wiut/t4f4ZfJK9YZcsY1vfIC+gBdxH8g73HX0DV8 A//LdcNzU1QCrYFcrsXMDeBj6AXxaMuRnPOEnVLB0rNeI1wI966qQ3UmkUzEJZRASFXsipCKq4mO BKGuXv41m2hvMUqTXXu2XFCtdrvoUO00I+hGVlOTulHo7lQLNp5XbV6WITRNTejRjtxytQMjZEhi rSSJ3QiVyDvWgJmrNc0cwmKu29Zrou4cv1zExON2OR0OqSidl4gUd/AORyAQmlIKHR3JZKJz+fJU Kj6VUIJBu92WIDah8F1eMs0sP27DRRu2lcgyy2OJ/SIZF/G0iMUS+Y/VlPWy7O9l3PIymnkNSEzU weYTE/O/8OSq3jdxgTVloYWmbKEMgAJgDFozFvEyZJcuubotF+R7v+oDWGgoC7aCPwzjoJRJPyu/ BYtCVwXJkI9mIJvQ5YGHQYDH2NAoGh3recxyZlubu7Mrm3v4ocGhdM/jj1muvBIQu1yR2vaW0tzs GbndkqV2DFw+KbUjODnJnmZOyvRp5gQsVSRB5hqkDQDUIzgQCEJQsO4rgf8vfnz5pWgpa9romUQc dgcZwbf2/3Rjef/y1pq2ShMLl0z53H1htDKTbdKU2t04tUJtbNHwzaY1Wz8beI3cqHj3D0JhmlCU eA7/trL2gcrFUKoUskYqwzXbsfzFZDgYhUoo0LW69g2IuhTUnq9D1EXQtKXKSMYRFMGWsZE8RfaQ Q5FjkR9H3oh4sFHC37ZapZH8evJ4mACXON0ILFV9nYZLU2U9GtEiyEQW4tDf6n0yqY8SToCw205K 5C0rGwgyTwkypwgyTwkaTqeLuYqLnbqYq7gm9eGhe4Vitea4dYsW+dchVi4PtbdXc8EY5AIc5O4z MDNlfD4dsHo+zx/Vd935a+uGWF194uFWsmX7xojsafn65h98dSve46hMxJZFdnHbDkSawB6N1r67 U49qdbWZ3VUW2W+CVUz8jnXFq2AJCUEpJCa9KW8jbzr8nbgzO6jsxFuVHdl9yvfwi9l3/0t2tcZG cZ3R+91Z78P7mpnd9c7ueh8z+/Z4d8f7wmMbPBWNgUJqpCDA1C6JqCiNaPwIcXkIAYFksVOFRn2E UAlQmqRGuCIBTExCi9OWSFVShR9VRNtIUKlUhGQLPyhpg73uvbOYJO1Kc+83M6vR7nznnO8c4S/C DfhEsNsFEhONSo/ClIWyskxgmpSkkFAYo9CgeL2MjNLkrBN1eFWh5Csp3fne/Ba0E40KO3zblHE0 JjyjvIReVE6g15Tj+dfz73v/IMzkP/L+Wbicr3pvCjd91/J30efez5T4cljh7cltgD7v2tzj3u2+ d4VLyofCh8p14briIEphEaVIOOAXpayuImSmm8Uoq+cAUVcQaikRuJHgQ+ATBCofS5ScWxG8Sk7I QY78dq/f5/Nii9mMkKIkU2blW2SO+XJZKRIRj4uvi3RuXBON4lEtD3nA9BF21hlxckQLjrbpA4X0 kk75h2lyo0UXp+ZqpKH3yV0f9oTSnFoxZ+UGSmkzoTQthC9mP5lGw4TBA5SwgRzrtnVDfWFVQeBU geVVZBZU7/T85Smv6lXcKqGnjOpHHwygAVHn5VdZSc0kwJem15duA9MzdycQX63UUsraWJPbsfIR 2Aufwt9hb25drKk5vjo3N6OsizbN/cvw1Ozo7nBLPF6MjDCjG1LBZPzeXw366ez4gxvj954jc27+ +vxNkh5WoSS8o60c54E/BIC13tIhDHwQQxJnXO2u7a7D+CqexyaXJPEsdWOSSN2YxNC+Rt20r1Ge 5wBjiZfcPC8Rhr6sOZOT0GixAA74zbyF0fth4x/huAirsBrLsETOznKkOaS4c5byjhbnKPXYo2mi bhrbXdLSEEnD8fS1NE673PQRHlFUJJiRiHPVnaoeFyQaHBp1D+tLPfbyAmuJlhPe0nYPj8h36QVS /4N6u+56r6vVSr3NiEQ8VW+xie0iuW6AynPKwvv4NHQjle9F3+A3og38IHqc38n/HE7A2zDFvwef A38LA00JfYjkwGECifMIz0+cCfHdmPyHM0TNSdy5cY6ASmtWaXn6/hbQt3M+lfgpWl7RnLzKN/Eq Zj3k8KnEpl85bVXJYy7Xt39PuVWscQuaT0Vf/1BUoQGGgKr4FQcU/V+UJaj0B2CIWUwRA1colmKz TwcSvQRYFEidizuDnQ2rZk2MYwEq98YMX5/99QPgnHqo1WVBWM+d20nutKEAekNre5GfMJ1oPMEa fgA7TBU4aDIsNdtTiPGkjBahK8zkGIwYlokwCqMxDcyKIO2vv7sUCWpBHOS6WEvEgp2WsAVbVjR/ Z5PeQJL4qg+zw/JdWuhZTw93eQg449aEP+FKOGxcBgVAyIDbRKqmBlKxjfYM+DBZeLMng7wGjx7t HrwseR8hMJksHItEui4qe8nL4lia2HiOTSZwFcywv7az9kntRm3/Rxc/O/fE2PPfP3PxP2NPkIA2 WPtT7b3aFngeumDp+2+sqEzULtTOnjkILfA16D95kEiSnsy2EFalUBFj7XRMoBCN66OlIgH/TOJS 9FKGWRH7ZQYLYW92c4yxgCWeiC9D62EQD8Z2wS78ZPjJyKi0PT4OlcjhzEk4GX8zcSEzH/MYIwfg h7EDySOxV+EV/FrsVOZi5opyKzOfsfOoCfyYT/kVf1tHtkPZHPterrHFjJubwRMOOEUJxVMBRKy9 Q4w20ZwV1XBrPBaTMLiJrY9N4gg2taRfNdHmeOnPNbGm1aZHTcyPTMdN2IQCk83FaXhBc+ZTwWAz djocxMSaeZE6kvUlumkP9ZaQeErEvUSSsTjFlkErD5Uvl5ly0awPXrP+Hsz64DVLTR6dxR79okef u56jpcfO6+ZsYfTqk5cdoMlMlpcSguWYzMcBfav2fZHTqlW2SmzZSE6mHs3nZ6sLfgx41S/cN2By hW3Y/fs2RSBQas60haLheCaaK0BbiCxZqbWAojElki8AktkuHTX79sEIsVYjuuCfR3HiwmzUhd0+ 7VZT1KW5dbqS8vYUqyqskxAU6rwkYi/LogjGqJRI/r/kU67mm5o8bqOJujbIEwzqVkwyNWyp/axW KkTsIbY5sao09/aCdYB/XvnjoV+cBOHR8cHZxa5my28vHdvfsQnvxAC10b1hYiDaw9uYrbTqPvHU 7ulEbdez6234JzDx9J5jLppu9s7/zdBAuNuO12k+/qet4AQntjLIaUihdIPcC73YwnVMQ492udxe 9jMBw0Zho2+jf2PA2GBvcKCWmQ7DNus2+zbHqHMoNBQeyg0pY+ZnrRV7xXHAWZEnDBMFlrcX7EV7 KVgIFoMlMsBxxhAJRcLpdKawBJbgboPiU0JKWBEXFxeXltuXt6yxrrWvY9em18rBMIRxoBAuBcpr hDW+Nf6+fH+hv9hf6i9vWORgrNa0yxpIR62Rjs600jHCj7jGYodNh3MvKRO5mdQ7Le/KMx23O9zf NLcH0CAOnIIPAMMeAHgLTTMrNXvpSFtzIDgYDoRCbwXplaLviLuFYMzmcNtsDtnW4jAkLPpmjMIc 8V+pNiaaclvwJGghqQgQTkBiGqIam+MucvgqBxHuFHeVY7hpXHkzPBmSWcJo+oXwsSxczN7KzmeZ rLaspGU/ICcMykaySnYma8hegB6kQg8IdbgPDMjDROxG7lTnaBYZUXNyXfkIumk0A+5+2HDUU8an dwikq8ST0moA2GFS6yJZjikmVyphbbUUUNqZKEDMRRaTQk4bM7YCstpa5STbUgCnI90S56MFZM4Z KeZlSqb6UldMgn6C/QGaVjZZN9u/y26SaVoBMlHRMNI9kM0qOFWD4lQLilMfTn3ARbM4Khk9NH2E MAF4VKIORzKaolwhhOswTyZiiUSpWC7kqfiWFzEn4/zAZP+Wg/KSj3/z3MpbFzqL4d/5fUFTPO5f P7V19wuLOpK1V3686tqvtu5o9/rFRqLHcuX4t/f8l/Hyj43aPOO4X5/PP85Hzue73A/74vP5craT y519kITzheZ8gw1EUBtYpCUpKUj8WFhghNIyKKXLH3QpXaV1lG1QaSsT4kfQpBaS0Rv8sWwtW/lj EtOEtP01mBBD2qZRiVWCkmTP6wsMddI0O36f16+dV7rX7/f7fJ71vcv6Dm3fdWz9u3/m/FXFQr8/ +v3Nh4eXbu9QPnrprYGjf+hKpi2883uhwvgAnDlNfOpWhtEwOdwyrIyhMXKsZUxhrUw181zmuP9H 8jn/GZkhUYsSwxWFxmH3zDKJLJEmhRCbqZOzboRDecKNN1XFEEzXT7xPUFD0mq7Ecp7PcZ6lcZ7P cVo8ls4r2B+b8H8QiqBsUk4qlHKZNInYwt9dHrtgzPO/GMw+rW6F0kMAZLk/gg1PAYPlu/AEF/lQ Jyxw/rawolGQeF+GcPkuuB4/ukNgvplbAVlPuCZcw8wKiBLJ6vgbZL/gQ14ZyGQj1E9DOh9Jf33g l8AD1tyvMByc2mR2rmV0wb9u/tcDrZXln99/DAJUsCmycyPqxasqL9xiDsGqOj7lAkmuHBi8xKFy mx4N131/wVBDGmSKs2WKF0meJSyrCpu4WhXmrsMxi6ySLbtJjl7CBNkAxwQCNu0wYlMi4gThkjFE sVwnxAkcUxDdu9Dp5rqstdwQNcid5WidzrMdvBk0I6bUJrebRqmbdqROezW9iunj18gD9CAzyA4F BoOD0qA9UNpBb2V28qPSqDy2bB+1j97H7Avs5w8GD0r75UOp/erL1uvUW+ybqTesN+wjpaPMCf6d yDuJE9Jx+Zj5A+uYfY49z53nz0vn5KnU+Zaz1jQzzX4YqEsz9m/tB+wD/lHLA3XtqLXNHi0d4aiy vFPZnf5mgdrGbGNHOV8fty69xuyzqCH5a9Z629fP9LPDvI9iiACYWypmtafa0iXG4bkLNF5Ot4UQ eyqyzaUoPtxYWVlkGR7xrGOIJK5fqiMrhLmr+Fi0CceR3Q4ulWKhtE2B2ykKS9BIJiJSVI6YVpts ikGYxVB02XBKZdmpL4xPy3xArS/sdqM2y6hBntdkeFuWUimFCwQ8+JZTMJCyWlhWw9WZbZVohsFP UnYJbksR0TBNxxEJkg8EWJbhen5Cny7BN7vodpXw9q14wdULdqddmii9XfI9V9pU2lwa925ulu6V 2NJd9q/cBl7+ucRfJlVCQg9d3g32B68HfcGzlZ46+Y3pzNibkM8/G/nH7aRwOyHM3ffQID935wkN LFZ0k/5ifrLp0McQE0912MUOttF8HowUk8H/bhmhaQULJ9QHQ14R2DiIEQKzJXgldsKoaQLwK7hR bWjSCZGvei9gFBhCzWCAkOuzCP70RsnX3LBJFDEMvXE+NYgaNpntYg51fUmJ5ue/YwJ9/q51flch GP1yD/os0VXuQPwtUwV2iiSTkTZSaC13FhCFyI6WmP6Mf11O78we/vyKb8ujH1PbX4vruVzO1rKv zTHk5IvPL9UjS0SWhqG2Zd+eS5N/e9WOm2xTDqs6BBT7Pqi66utoqHomTDEJGTQ9Q1eWmzksbkEP Z4gipSfLpE4mWZqFyqpaxVsQq3tWePRE4MKBMFqS5PQK2k98K+MX0wBOblPIsYSoI9TcvFvz1fDG +F4627mP2B9+RRvPv1J4VzuRPYPOCFOZKW0qe6YwZV3JXsld0S+XL1U/Ea7KV9VPnNnaDfGG+oC/ V0uJlqCKmtqaN4uW9Yxgi7bak+k27PxqAuC4ptbs2vUa9ZsCeqnwqvV6/ohFrcwPBYcyPi6bzMZ6 q7U+aaVBi9Eiai1uy5zOnC5SiwrUKKnmtoX1IhkmMkVKzuGlkCVaYvFSyHpZxzL0JLgY8CKMLAqx r6haqJBRLUELC5pYJVBBrNICI9OSCrMYBRNEWK3Ijh9Rsj8pJuSkruFZreVyuaAJgoYKUYQK4Jwi FluvakVV1SpmwgTlNUhzymXYQKSUTNK0nx2tomqeQAB2KrLRRrQZjaMP0Cy6ie6hAKqTD93QKvWr 6lbVpy4ltJMaqdXJjy65tR8+Ftb9EQCQ2yP/gWs4PWdp4IenpKZFSf1f8nm6DcEBGiJGIHddhJUB YWApoT0rBy9ZqE2zen1AGDiv7chsze+2NtcwceQREIenstB2Y0eZbE+AwLLCEoesL9x1I0Enm+Cd IlzZNTFHt2N4fPZSzNHMmEPBbrsYc6KY1nknIYj44T2XF50CKzqaKjplmORiyDEaQawv/BGC2gj5 RuiFcCHkPCkkHx9eeZn3fgUBDSZ5SK7dy7tBvKBnH6JBy0/GliOk6wZIHI/GI5HGW40RnIh9q1D2 wMvDc5crqWaZY+w787cLYve6+fSyXO/4GuTO/2vX8S3k3v4e+/qn7ZFgqLgG3XJau4c3kP+cf3Zm kz+XQzyXi8Tj4dVo4/yxitGstvtyOb8gDT6PjqHJ97bAna+Yyq2ev4ZK3WZzs9AcRjAUij+7A+se SgT/FOi+iG7M+Akk2liW56pdrv1C4oVkv011xA/GD+gHjO/Gjxh00p+kScJuZppN1e63/X4//Aqz maQyhIpaGdNoNXNF2/4Kcu31aJAZVgbNfnsvvZfZa+5tH7cn0AR9mDlsTrRP2O+1n0KnyJP2xy03 Wm7a6uv0JDNp+hBDyqiBYWldldOEWZSJBpApiRZZadUT8TjAZRS2P8OyWB6aYcKdmdDjlsnYrMkY esKfFhBBpNMKBrh4rL7wcAZTGnTuz2BQwx035PGX5rIc6cEbjH3o8dvPVAOvgrikSzVswzX6jXFj wnjbYIw6eXzawqJJAr3nJWCyFVLCIzOPwZ7oBhsBviapBrxDbKQfqE0XBZR/SiKNfsN8Zip6xSBh a3lpZ88ejN3oRZT3qlE/tlEQAjJxpsFNAm/hoMM0At7QF4IelSOPzEeQl10gC32BA/G2/K/co2d9 19GfJGnrhhXzv0jpGzr+zXXVxzZ1XfF77/vys5/j5+8Xx47fs/PMh5M4iePEL5j5tQmFEPIhhYRm k4vbMdBgXZOwodGpqzO+RGlZpmqbVrUCVW3VlkmkNEAQncgmNvYViSE07Y/B+CNDWjdPTAoVE9jZ uc90qiblvXvfzX3P59zzO7/zO5VFqgurrz6Z2upLkL7G1PBG3IDtuUhXF9Sa1vFnK5Xqzz4XifgJ kt3VEbfrenNz0zPVAfz2M63h5nqKshAo8Q8BZW5M5j2mF3vp+T7nDXVmXVm5j9vqOsoed14UL7ku yaKOh9AmPGTfxT4nFL3fYqeFSe9R9pBQ8n6APrC/67yCFvAV+4LT55IBfRzD8G6OdwD9xUS7D/SP KNvsGMEqbcoY00zb7I64240IwXGAjGhT+Tbe5E/xLB9KefPeYS/jdXeoMpZP2uo93oPaPhDjyaGV wZXC8pBcuFuQaXAHKzS+lZx811PryyC8x1qTEFIEcbZWviC+k9MQrnkkQyiAec75DPvC6oOPfEYt KFiD9ifIaBmsxWpi/I1HR0hz6XhGMx/OMburQ994Nu1PhLltD/nJM3z1pzr7p9TEi3gUTvL96l5S 5PYhAc2YiiliJIgMyyUYIgt8AvJXDAZDDJVeZoapKTCGauh4d0ZmVGaSKTFsiZllyGkGM8c4fg7j EVIkBMo5dLDtH2s3vmw5P5UbBGdBZ02DxUObvtZ39/MzqOQsdFNHsebW/HCRYnULXqjexrHqXgEP /+dNsHOg+nXCWHYeNptM8bRIiiIGS3khgZHMsQnCePIQITAXYzLHczVj6WA2grGcyk1yJY4tcbMc Oc1h7lgbNF0EgZ2f4Hakoe2Q4JaphcGamWDZkEwtLXzB1JqlUwUvmJmBawDs3AJ23ub2PagO87vg i/2rZeY4cxZ1oI1Mf037mGrepEyQNylr+BuEVt3mcJAx3ervdCSla/XEQ8bSAboFnm/P06YuTYnF T+kkbe1NG4I1Ci2t1DNVhFda06iRXdfc1imZInxUMiMRenfDv6SF1ZtmI90kSezLClasVcXaoch6 o5BrZlGqnC+Dji14jBQtRUupCg3IzeQSTsGDVZ4WF28lk1flm0vtbclkg/mCI/xKmnhGu7BHjRql /PviBTvjSXpeQi+lj6ITjhMZPuIJ9Mj5Up4Vw9u4bfwmdVNsW4+ZPx6x2esEFcX68YC939GfGeju 7enfuMOxx3FEPGw/7HBtDxwKkGh+Z54UbWnUmWtd19J5GVoPCUlQkEVDWuswJOp7qCcjg64nVNwX JUa1hgMSK+WAw/5srnMYw8pO5QWFSSkvK0T5HlA49bgtZ+YIuD3ZUmohLRk4twXmKdPNOloXW3BL UUdppyR1dsLBP4II8GPpy3gPakI6/cU6A+lRvaTP6qyp39NJSce6TDfpl0kvQNMPmIsa/gW8x2xs SBntgllnqMKIUBIYWcD3BDwiYKH3S73fVJJDMkXZdHKwvFJOypUkhVyuknzceMifFYAkVirLBbk8 lS9Pg5xKuo1a9qRqvH6OkTCwehliVcuf3oPm5syGcJzzdme7soQXbXYb4bWYGiN8xmGoyB3xhpHH 64o6wzgW38AZYZS1dao40+nwhOUwrovBrYfPhSndgxFA+XCDv+T69etnZmagakD1wFPTiCqvvMfS LElkUVM7eNpKZZJsDRfqjG61jiogWkVUqtYdoJxUhxGEK0zRHnIYdghl91o62mG0wyjCKBro/yTS BPipgzCIxxKZTiqCoLTEYwLvD/pqa13pjmAgGPC7fYEALUfdfrq+xk0lEYindAfZ/FpT18ad321c 9/t/7hjN6wmSSuipuVMvDm0Ie+xBlyz5c5O723vwT5qH+8az2w4/767//t7e9r7vjDcd3x2LNfe0 dnS2jM+uiz6ZPFL97aENPsGZy/6473VcyNU3F40tOxEiqw9Xl5lL3EkUQE34Ri3zP2rkaAbLNJc5 n4QUO81eBQB811IQEoUZXbImNM8lut9J90uSEkQsEb20V3L7TBG2+fyoQRcd2gQRUB7yNn8rWbYU gpWnt5KL8q8haaFletx5gLxBDHwC3qPv0HcbOS6hIwVohB9TCEUvNefBPH2Gyb8u0iVJSuhuixAg 8RfpbOnx7y3Rn6M92UE5gd/hL/DnhU+jUDF6nYUuNfFt5gB7lDnGvsecsQmbBdxj861xPuFt9PUp QQmxDQEka/h/lrRHKRsXgZfPcgz3DykAFNwkSbJzxDnpnHWyJbjNORnklJ2qsw2mi87rTsEJ2X8x l3EW9V8OWIlEk8eqL5A4lcJ02bJ0Ou8OGvfLj/B9KzXW1quMQ0ioTKOKQ3YljOoVhxS2wVOU1VRc 72gIowjfoKKa1qFJCJOZGQA8YBwU08QEBpgF/D6hhi2qbmLCGj3tdlPQdT3GJN5w5I3Xbrx94szI u+MuVQmvr8PelvTzxlfeemtXJrOWfHbp339c+VGpp4c5/+aWkByfrKyt/KUj/Zsrcz9v8EGdewow tBWqh4bvn7Ox+PP6QUK8RDHBSxQjvFUD+IDuEoWiNqkRDY7kPMWTFgHGn/f6yBhMfneBVpRIOwMU D/SdLOSvli2gLF2lCPHEKY3uX9/SieI0ekHnDo6EvdvZUW6U3y483fB0WNjDHeBKqKTNN/xKva7e QX/jxG68GY8rY+Gd8aJSDB9QpsOveE56Z92zynv4HXI2/jH+Bb4mXKv/u205/Km6ghWebPXs8JyI nlBL8Xtxwa3iT1bvIBWuKBAGiiBKwG2Ai6JW0gjSZE3VRjTq16x2WpvTFrXr2h3tnubUdkf+6sKu awFdFCK0q/IZdDCzHgOcdGh/iEp4WPqBRKSUjNqQiYpoEs2iObSI7iCRLhD04f7QoRAZCeFTIRxa wJLpucdjxMt8TcVxfG+s9xL5IbKANT01WC5MT1WmCstTFqySyXy5PGVR97LncYrZRyNfjeyPMK9H gI+nJiA3stkszoJIoLBBQNn/pbpqYJu47vh7d+e780fO57PvYuOvM4kdJ/7MsAOGQK44JNQ0S4Aw BVw3EaB1kzqRRAWtVSuyUYZCKzlCKm2qjcBGP8akkYXQGqQVT6W0sEaLtolRJgqbqm0ay5RtaKqE UvZ/z2Gotu7+7929d/feu9//9/u9mndz57zAe+86cyZZzmFiT2TCjNVfyDXCwzGA2Ahs9xpWMtkM oliDchM11oTtXDVuYwvhG4d++DeMZ4/8vDW+LuCwNjRs2Lt+66nx3V9fncFPnv8A87dvYKncE0lF 1APBQGH3qdP388nnYPadDz7nTMBQQZRgtixjK5IyCLKaeTcFlVgDGAUb0v0aJSzNqhNachA86TYC NJ22hqtfGBSSupv00H0X2T8jPxFqqPmDCqEu2WmYJWaH04XC8OHicZY6DsJcKTjwssO4Bf6iSsEJ HuMhfW1ToBfSrSxLuvqG/djwD/kZf9AKj7FqlMM0jhAWjNBFos7Z7XBmyB1dTyWbaRs6OX4Hz6eS lNXmYjVyi1XnYjFCF7dKpbmOBWA2IDjIjQso9aB6rrs7kyIpsjGWzAylXuBeMB3lxlJnU9WUYKTG UgxKaS1qbIdph9gfOy4ImwWsp1Zbui3fsLzOvd1yMiVUU4sxRteRHroIaLeCCm5q13v1p/RvWp7R n9en0JR+RrggXGmxRkRnk+0xJeDsVP1N2mO+gL8zCN2sXFylqxaM43g8yFqDyBqy6cRgKOqQNqad 1digNqEx2t3mPh7Gei6azJD4XneWzyfzB2v8CC5jabQE/pX8wM0COS4QepQpPyL5EU2uiMQ4sSkc EZt1FOPgFBXCOm4xxSkx4holltYQhAO+R/DoSAn0GdS5JsQKCHH2ETPW5Lje1JB1JJn/Y5j5KD9W OH7niw+e6wWGXBGrw46EPaR5E9YvF5N8+57UwKbi9DPFp7vW3//wQ9zd89MfUaK8f+tUt8/RMHIV 3+gczvV+6+NrfwBEPwF8uZ2dRi7kZ19cRnRU1EDvbHaAIJJokChhSmraQFgHamAQkuEEC0W5khQM h8MBJWT1hh0CEmSBEcht0lug7ArtBK7y4DrtAYVr75Fs4FqtVkoMxEEDggiqSqUShTXIcWqu+kiM /eoYOgl0xOqUndjaIGpvFMlLjEYCYVnQhWmBRcIQGMeTAicc437MzXAseZUAUyOZGCFwdrmCAZgn KcJsAfZkthAkjVySpGDgqxIem5snKl66XCrFvkbHCiMlcDc8yqC75BlCQ67rrMmj+8Cm+XKa4csF yags+UJGDBKJCFKIRTP08vaWZMbLe8wDzqe0wfpd7uIKAbNmXjCLNpP6OD/OvMIfsR2VD/t/wvzM fd75e+ZT+035HvMf1qkMCUPiMMxu3Pwr4WP7ogBKJ9S9xLBmkic85EmhzdzFdJt7g/1Mv3k3M8qM O8c9k87T5tOWinjePG35iPkrc8d2z+IS5wXYtM4LzAiJZO0mYNGmBV54kXOhtKaSoTqVnDKoHlSn 1Nsqp6re33EYvuA8CAhHLKqThBvGZiVH1vhJLyZfRPhE1KLenF3D+7SDWlljtXsu15iI0+KEyKTF snhbZGXREGEm4rR4R+TFM5LKoXGCKzZuKGnJkPokFkmypEvsooQlMhIzrKWUD+SXnQtsAXqWRoht GSlBWACfLxOhGSWQio064BOB196ngtcmG1JQHpAesgUtoTVr0EgJ5wdmeYQZZmQn3RyQH3XkF5AA b7M25GxGIlcHh0gUJ5oTaoFwxIy3VvPW7i3XLLWapVYz05ohmXOq7Ml5dEeuDg5KBV9x6Tt37nTy 9cQHra5fVjCFKFg4BOoFdMDfxHv3Htl1OBFUr73+5t1/vfvGlaUj+B2T7NnTtv0Qs+6TZ5/d813X +J8w/vQuFn59Zu1A4xrje+CHehFinze9gmKMuJzd4QTVq4RBZCdhkMT2xrAs8ViUmrFI6liBtf67 oZAElRSa+lSkJJ7Ikxk0ySI2hgP1CNmb7RXsnVF4EaU6FqpytWNuQV6oiVKV2OnL8hXyv0w2vg9l 6QKy0z4Iuhr+Zr4RniQ2Y5qImCcZiKmvpsO4YVhpNtLrUL9J/bUkJeIPJegWOcHr5+aIbyXpuOFl fVKdjLCdbKdts+cwe9hmeoPDqcTB0AQ/IUyJU+YT8gnHdMIs88BTgy2DMcYnSrMB8dhKPBsQKqxo BBsCU4FLASbgaAzX41ifjOV0S7Pi4EXBIgPAK3jbuTJseCvMf2dwS6yCZaMu2owVu0M+ZrfjRgLW c0NDGRrXrq3Fjo5abGyl0dB8ocyEhAnEB6VhqSrNS7zkiV9keVaoOahSDZQ9CwBdurNth/CX0uej oEIdIEZLo+0dS7CzhYWg+qOEm1xaJKxGwlrUh5pcjT68rDpEahAcYJIcLkDaKjWUBbi1ZR0N2VWw BaR7QOqYaoYJdn7qKhW/5Qtv2L50qzm60TMzM3B+5NsDazOB+lWFYDCSNHz/YJ9YemtsZbyxMdq5 m9m1uX38/f2diTWBbOg7Tmfr09c3bgb4ofVfdrF/BE++Dj2OdrKvGd9XtL7XIpNtLErIReZAy4Ht DGrhk/y2l3WuY3Vvcd/q/ZHhYpkrmw7Vv+QuZ49uOLSpvOUHva/Wv+qe7K1wF0yz9bPuq5mrW6rF +eKd4mLRu0JXV8lZV1uwaHpbLLR1eJHGtoUKXuTJKw7ZLtXZrBaz2el0mcWxMFbClQefzSqgQ2Hy OVy2DhINq2LtmAqfDV8Ks+EKPnF+IDYGmy1oatSRtspU6GzoUogNLfehEbqEoK3hnijgggFXCwZc KsRJ6hT6XNhVwaLh3CfigyIUHPAYMctP5nG+wrYaNk/BkvLgPs+Yh/H8kvkt4iG5elA73LLwgmcr 3hqP23veZ9OgdwE451APmzaCchrvS5fTU2k27Sb6mraRlEhnc0l2rB/3k7nVQbZC4dqs7KKFz2ZJ EygsGpY6SKT+cDCKoxSD9Ssy5SjujQ5Hq9H5KBeVSEu4dW+WpDwU/mkohDCi+/ViumgUT8Kam4qk q89qyxSl8vEu3CWTTl2tuobt2rD2GyD7yoN/G47/cV39sW2cZfi+O/scX23fnd065593F5/t2Ffb SWo7duLOlzTpumRNszZp2o602TpADKSklvihglgGQoCEVsM0EO1EIyHQBP+0JbQZMBGqqOIfd+Wf ij+YVkZVMa0WFXQVGk3K+362t2pO7rv33vv53T3P+zwvnud3oTHw02f0r7FvWb6fVkm1v4+b5thp jjCcxLEcvspAJE/XcFUOb482GYMrOEfuC8ee/R35GvR1wsXvK6b5AGkBtbxZ26RB06zdlsxTD+iG WcPqb56SboN3g4ZWarZFYfMOSkRVataw652HFR4PB4NKrL6tv6uzoBO1+00wZSZm4u/GIVND4slg bqHi4EJwDf+Ucacn54bGjUI40q0QeyI+0L+rP9/P8SOJA4lsPJ04HJ8Jk/BwNMxMFvZrzCipasxu ezXMTGf2h5mD5oxGxpS9YTKbnAuTw3ORoRAcHhpmnu6f0MjkRKFosXs0qONP2CphMpV7JswcSj2j MePde8IMVRCpYuLjdQbK9o9/aSA+/khtHsXuFJU2S8hKgNGC5C1nARAXvbR/OkoSYECxCoDuYCVw gA7F2j0Uj86zm/7RPdhWFfLQTBUH6VmkBw6g8lXIJxOEf3wLtgszxxor3164ano43s6J5ldLG78Y e3KnqveFl67vnl988fX//ek7k9vkguNE3iyTHRMvjOWnn35+fNfWf3N9Qy+8tfrrXfmzfydTqVeP fm/DsvPO7qBg5/ctLV/enihvlzWHjbM73UsHT5380dxAUVHio86Tar8aO85+9yunfzY3Wjt9/tjo w5d3HYn3GU+8tC/v99tA9Bk3FKf/QDdXZM+0tTFSspC4kiALVAgFxcBtJYgbCjRrlBMQ3LJoh6d4 EKRKAtVSxURCzxeSGaLbXC52VqfX0DMKXiOz9uijVcxC8GAVd2Q6HIPgriVSUabXyxDowkYEkFov LHFYemFJMnkQXrFgOeHcQpFJypGdNgfAOpfDXhBU9+5dAGW7H6SmVdq4NiBtmK1MAxrEjcd6wyN5 L1KyQEe4YzIPF8VLykmByq9AJVegsiwoNKXQlEJTilIaJDpN6zSt07QOs7lHqw0E/17FHRA8vIL7 MpnSYFu1qWi34waaLpgFtJENmfIKQByyciUrXRBKC+CbxbiYWC7VS7YLpfXSjRJn8mS6tFBawpRV IlqXkorKa5xoyT2ZVDQ50SOkotJETE9FE2ucx8rGCsnsSD5aGCNassjQWYKtkmVJCCiGsy6QCwIR hSXhvPC2YBOwSMUzjG5k1cx0ZiGzlLEtZ+oZ9kKGgGJl1jM3MrbMwuAvoTuUHqChRGe52VqDLiMT YS4VuVymjSG+fFoqtgfD9i4+HkqE7YEwcXQFHRGUZyAtFehTNWaeQPEyUaJRj5GGqNX+tlYPgljT 5pB30NYQsgODxU4SOkayf/FbI1NLIZ9H6LO2nthhDQicOtbX/+LEjvLeraHdse2KqAZ35DzEa39l 8/nT44c/Y/1q6w9zmhI2jGRCmiJjPz6eyx/YCh/PqobhE0qHud2t7pEBW16BwQF82cb0sE+1GPMm Y4AQRBDOXjeFu1tXEMm6gsjWfQrnBAWhtRyCWxT4TuwCcTcE1y/j0U630qn4ELy32qbbrQ7dbv6W sk1bAwZ0H9AX9ZdAhnsWgcMLPOGpk0VHfgUvwPfwPnCDN6GoN+ald1qtJICsNQIloGaaG4ixDhPc GuWATke8zurkZDsYGWkFVmBwkJ+1eMLwKzyLN2UYTe9x+HB6D6wwnul0GjE35YObRdi7KR9wZi0+ KEh8yh/IXGlRyIg9xoFWjwnP/k6j2pin/UibCoG6QRaMJaNurBj3DLtmTBushYOBgjkwkKfr0lBr nelrrWNxuraygWAeCOKb6HGnol6gRTIwokX1MVfA5avDVMoM0+Ny+LxC3UmcZdTgS3sKuLLEaoH7 osvlDrgNxTLLCuaCxaF8XSHTCllQlpS6sqLcU+zKpdiln1M64GM3kQMgvc2WTQXlhalJbTLQKcEP oD5PaoD1gbbtBB3xfYxrCutkB9ep9PBwOl0Z/magf2Rrz55syOmIBsO9HrLd/gruqKTTw1v6pna4 DEAOVmbJc6/t1AKiscSwj05u7SVn7GcAtSmy0a7z23p9tAnyqfj97q9igaZBG563OvD8q+Vr4bOF bQHTbnXt0RY9BYK79BQI/kZPUfEUJ56iMnwqiXh19UIC7FPKH7ouMblmI4fV+majDUvT7ADTvAa9 y+XXg4QPEBPfdHWw4DYvQfmzzGmzbr7heSOyYvIabCybnASZGyYX7OpNaiPJaO9YAKfEz/qCznQg pKVcDv8a8VhuiWFcDrizeN5HfGvk81Yl3frM1pMFLmt2dwfh+7ZQa6Oo7aKoNVS1rhFRIwvainZP 4zQND9HWHn0IHSMcoF1Km3/R8ZubU/epE6vsl9CKVaak8c+O3dl/H74+mC3Qp2q1xbMLfCO0SvHW rB2VoECWZWqlvGaZodigRVIKRz1iJB4W1TCJekLockinfwGZgAbmU4BpR9i++Hd9Cje9ZqViAjyW /7zy7JF+PRiSn9OVrP8T9Jyhu9NmZUt7+LkPbo/GYgNux1x87ofsD35i6hRBhJEZxuaCujfI/bGN HzNI5T9AR82FEJDpSOgIGUSAH0fwBv+kGMHAMlsmoZjMqqRtD2y0UPLUMGSp/mf9CK5sxydkOz4h i5UULwDBliXRlERk1ZYQuoPxXnojtOy/B7eQYAqAPW+RuoXiIJMIuOijuQCSl50uN4U3995FgYcv ZDbNtonYNNfX19HqPmYjzPVrUDUBn0BdpkVdrElvimW1zHp5icD/q87XhPq2uuuceFY+5z2rni// RhDKgXLwhHRCPqF+SVqUF9VzrPODaFNll50ve65x18T32ffFpvwvb1dVripVtaRVy3vFmvBlsSvH piUtriVy5RIpSY4d0iw5KM1otpg0R+bEO9KHkv0peZ961XlV+Idg73b6JTWiquPsqMhvk0WfO+iK iFGPyh/iZm2H7EelGXnGxwfESCSqHmJt7bKfKyoU00TihGQB3tE3XMT1deCGwAeSLhfcuu1uXNTd wEu/Q+s4mmZaxyH4iNbxbLZc+sTXUFuDfqYBAkQtTTe1NCFrVhIJK3t9PimgBqOBLFiVZI/AOqMC OpVkrJjMjRT+z3bZxbZtXXGcl6JEWqRFypZISbYk2qJs03T0YZtWFLs1VSd2EkmJm0aOFUCZMRjo gH3ZAfqxNUWNAUWxYQi8vuxhD+ketj1O6dLOBZbNKLIABVbMwDYM2UOxhwJt0mQLhmIrtkTZOZei 42AjzMvD+2VSPOd/fic1c5TJMyLojqGnIzph9TSwYYGwEUJYojN6up9wo6wcVJRYsMQw2g6569Ri 0u9EMRgAz4/HY0GxIG1J7H2J7El/ldgNaVdipbymXYmRWCJdJmVAG8bI55mckmvndnN7Of9yjmzl tnNsbu1weYe8/Iuhn36DhvbmxRYENtDlKeXiP9H8vAXEs485czg0PxfHV8aiCBxHmZt7I5SLWaFX lRtvCF2DgQmxbgZQ7hFl123fwLEbPN+E3+fixc3NFtO6SFr0YDaZTShW3mMUCJsI1CvpMai84Ew6 4HhjcpnFPCWWRbyEy7J76XEvElyugrqgs3ou2yQgHWGsWezpkVF7KBoI8Hw/rWkw48xgsUIw/2gu V5UOgtXp2yclYWiEXD7z9cpnn315uGDEn+4sjAyMdT6J5+qd3GImKsohPREdDxPFf/nBxp+O9klS JMnqOpubvdX58ytD+VDQMEi0X5siz3f2modjxDDCojb0rO+ZK0sD4QwqzVNAWDIoTZT8wOMrDfCC 8lVEChCeUM0gVDMI1QwiIWajbIBxh1YYkodQEoIWCgYYH72DayT/dRAHAU6e6QeBEPsjVCEiUehA CZjEQoJ4FYOFNYNy80DVMNpPKSkSobkGljEMTyjoEBoshCYRfCgXeiRXvKjhQo8kaeoT4D8PMeJy zi+3tV3tvubTkF7mF6fx6hwpz04T7e3e9ZlljTjasrambWjb2lswkZfMFH9ymJipwGgmMtpb6U9F jsIj8YEgQ4xeqbuNRLHFnp3elsiyRNakDWlbeku6L/mlt9UD2OLi+/zcY1BpkU2Cakc55Uk28Tzj lfj0Umd+PpcIpWOJsTAJ+y//p7JyOEk5xOf8aMmlZ5pFAgXfz5lzvj90s4jWpNVm08FvpYXppw03 agVP7wv4QfHzYY8j4zcuWHSWVSwterMWvVnY4wzhrMXKUoXOq1BHqVBHqdQi+N9q3rqal19q3gZg /NuJ49xaELepWXS5RZdbJfiAjogdJQWXwf0fHRHXlQZxY7i/46Rxaoml4yzuUQrTPcJ0j7COOZDu oRdootx59L67hz6Oe8D9XxwRp+psd/wB+Cjso6vx/OSx4whU+tLZhoNz8g1yuvHNxmsNX2MlsFSM ZSdEfm7CzyNz3MtjRmu1AKwe7uLhJbR94nrC7Lo6tODvFr3epFWCte/5c7A97C7yfv5sY4WPFZfC 1OPDOkfTiBVAN7don1Wq0LsKvavU4D3uUOfX9VX4nb6goUENnAXGP+hoqbRawxyPnTUvgsD4go7W as3VbuCE91sFnpye8AoMfecP5+dRlMF7273Vs6u/YRYffcocgzMPZ+HRp+8kYvFYLHbYPZoDzuA0 v9f8u+rbAhdvrgFuWr1ku0l0QTdTsR32wbXhkpkqguGIwzUztXRyOGymtB1f6FrGMlOFHV/vtUzF TC2C4TydaYzWK2dTjaOCWao7ZXNMYPjs0so5/DDZCSko8gHOzy8tFgsxLdgE+lTCxlBBJxt6W2f1 HWI7csnMWcbhQolslNoltoR9av1cxajV0vXlOrtV366zTF2ps3WI63cj6nR9bbW5w56HnPVabIes v06RtEukUIeA8fBj9zJ3CtkUghyPefpXpwmMIg/8uEw39i1aewGORoYNSe7NZkYMaWiQhOThUHYQ JEGZs1woZVoWASZtEsgXwKCq5rZqNBzRXLmY8nLJKCgGpBztsY7sd/MB/v9XPlNkeb3v0FemVi5F n79cPbE5pPYGZ57qzPXPDmlBbmB0xf5qjWWjRxY7xVpZ9A9NnJ6xnzsUL1Y7s/OTCcq5ozKJWOzd dXlkfP1LL1erjSOXOi+u6GraMDQlE14m39vIOfZx0epUL+SgE7LSGegrOsmJUid6fmbAMAZmG+TC Dyc8HpYYxvcvULIpdl/JbKpkBcrDRdqGBFnNoCTk8C6TNEyBSpJA9UCgeiCoBi5TEzigShjnqidP YHxEVQmMvzkjOF1lknRxkm6UpFskzRhuYVJwNj1ANl1Eo4YrciZqWxBXmMwgaxRQSHqKtDIrTvb+ GhKiAucwnFkcMWRjkk9MsFRL8nnIiXfvKgDI4CJPovEB/VBQQLBB1diXjQt5FaMYf5pAo0ht+gBF d3/ZEGj2FKhSCFQ1BJXFLpV2qQJ2qao9zSTpzCTtSNLBJH1R7DU9uTBRTHCGadrTj6HUpdL9nJuH 10IyLVMyRZw/YjvjtmBj/BfsZXvN3rC3bf8hjjjU3oK7th1o23s227bJGnTs2r6koJopeccnO+Fh 00wZJ4cFMxU6mUmaqQwIhJPLFEfHK4VU8eggk5mcom9sZDKyHApqqsFvC6QtEFnYEK4Ivxc4YYe9 7gyYU0ljPG0um2vmhsltmdtm2/QxpmKyJubxHgh4c20aQh3SNo1yiPGH7tWjUgzocnk/lGkg98Xi vgCXjfu0QeIPxPwJL4whilub8Me0CDAARvL/BHCXBSEiD3Y+hoApUv3xm9Wv6WpILD7Tme13poJc pf7Si2IIAzGyWJTTXhzee7+6Mnep861z6figYYyOyKfJS69ufqeTbKlJiLSldXL2J8cTGGcsiPbH vvcgzmQmyUrdSBsEDKREJ1Gcc2s6RRShTXAYOziIhtOPnRydxmlZQVSyjJsZqf9+SB0XuMvz0x4c x3kJXDyAPpXgItTjIpJCCU6h+MZRDkCT41KSlE6hY9FUhM4FuYj+E9jYOda3FSU/U99Vf0s+6LmR vNUT6PskSI73HFPPRV8n3+/5rnxrgE87kzaXXgC3u5ImN6MfJFgnTU4I3tP0cfjRLeD/0+CKHNnD dplb4za4ba7NBbi7kgODjnQFSpyF1EI1Zp1SPr9o1e+1kOmq7bHnqu3lZ89flVInrqa5E2fOr15n pEe7DAdn+tEupsCF1V8xCd8kwzER3+Rt5fbAgVvIDs3uC4ETzZBkXzY0wmYHR4LZwEhYjuhMkiR0 ovaAFePB6u9VdDLggyYqajoT90PjFiD7B6QNgrwJXkcWVp3wC+wLgW8H/0t22ce4Td5x3I+dxImT 2I7zco6T+uXy4iR2krvk7lr3GAm0A9oC16nSdqENPUoFGu24u3SMttBexKDlZdOdxETXFfUqbSDE xG6c6Lh2KruNE2MqR7upY9r+2PZHVa2DDAlVaF3pdb/HSYqm/WE/j2znyc/2x9/f97uf3S/sjTwm PhZ312sQhCD8VD1xPmDFYAvDQ3/Ta+GVaoBoCfgMuVyJXj09ODA01NPrcoVDAmYSOgdJnD+46zvn ps7tf/jAB1sGd90++9QDB795JzV3/PDcE180X3nhjYNXH7+tcvzJ91f+euLdK98bg9Bx4+rKRuo0 sKYTFtnbYS07XMWqWmJyeGBcGCVGDEYJlcoGbQ0OqhHbnIG4vtX1a7buqhgiv23sqIwhOFiXdBq0 tQdHDrAfhRQ7VHPRuq3ChK3CBAI6QWHBubVswbVbcrEttIuL/HsgrEWb2K60niJKN744iUEsMZhJ EU8ZZngtVGdzG7Q1Mqi2e4ALF/Wvasw2aypclXGxOoGiLBTjxdXgAvCbrvBtZURtxQTxPN8Wz2UD U32QGca0WvwGfiv/XMBxyETDZmV4k7nVfCTwiLnHvS+wz3za/Qp92X3V4+8bHi3XBnYPOKrDqOim MlkhCLYqeqg3COZKTxC6NqLLxHpSMDKUo8APIVwJSeOaoiJb6leYGYYcY5rMHEMxH6tkcAE9XI2p 6mZtQiObGiI0Xvu5tqid15za2NrfbOqEmVt4WxUbLRxoWnBbjUCPxXcUkWJ57H9sotXiIO13pwbS vnRfapAuqajoh13ZM6Sifm9BJYib6IJQTjbqxGQdEKRS5TB2OphD2uZQ7xqYcmT1lwHJ2RZMsECD HaNDIil95/TI89smn514feNQptRjbVpRo6v1YJhPyGIKDXjYb23ZeevXtlVH+4pJymp8tO+B3U9f aB2bCnP5lcv3l+VUCkW8/TupHbU+kZ1aeX08sXb03odO/WHyXlEAlon1KxsdBLC8ijDQhQ7LUtqW ynQ4goewC9EyshFGLM4kAWwiWNuHsLYPgaN/t7UUJv8+iZFmnZhgNxDL06tcnCwkUqIrWxO8NNvm BpAB593q2INlY9Emtg3NYiyHJTSWwxzGcphBiZPkr/MUytuWWxX1zXmymm/mf5I5kXf0SX1aJbfG GOGrUlUbyd1ljHKbpZq8Wbsvt90Y53dIO7Tx3JP8pDQlT2pTxjPS942XuZekl+WXtB/mjhuvRV6V fhp/wzgVeQcq+IvxiXHNyKn5Pak9mengkeCR0GKe3hJEvW42K9N6L8rKLj0REzlZoRJSFuHbSqRW iTTtYmMxQlFYjF2RUNAMIsdQE80hCrnxXaCP0/18eHOY/FX4XPjTMBXm8dHwOnPdlK3ExmTjntZ1 o47bM/6IMI+3tCrXMY+C1enNYjIT7En2pFUiE4RdKpJQkR7Kqm32sM0GPQT41hhEAysguslayWYN KyEIIWH779VUmz1QRABviNolljeulIJrVoXErc9ueOb3KPSuNZZeO/hdfWdl4sSP9wxvo+auPTRa iqdSvNcC67t75LOzl1FKVePJ60X0M+jX7/z61GKZAOfrB7zeBrIy6GSHq0zO1kiX0hPQbXOqiwoK 2GT9T/JVur5W6TpSBatRACOmhDB9im1hFTvx2hcinhIj0V8CdCKRBuzYEX1cn9IpPUOLPgrEahkn 3Bbk2/9zpfzSe10n2u3vCbxcGn477pnykB5YQHRBpbZQBuwEi2v8jy2UMPmnHULx5G18TlFy2S/N JKxPFCvLy/WbHjJWHYf4xpXIElclq9xTDrqaQ9tzSMEqZ+fFQwldV29Ly/p6gvHmAiGVRw6x6UEe i/chX42iCBoS4XYXqrqQq6DkUI4IJBVFUVFTnVFJQuUhIS6q51WnOpZ99VEbrpsZr3FxsmGTxbca rXqgneUsoit44HEb4O+gcYaxuYPWCbx0UlfHz3VDWsfRobv37Ft910Ay8Y2wEM73Bf2337pi3NEb ZZz+hKToDApTcx9+uM7Uh74ayt6/suFuHcxbMmLnqQdPfCWODRzwsvPGRfKPwEu/Y6DDi162eSlX sTsjkYjfPxLx+0ZcTHLrPnxc17iu/HC4kZbwea6fduuc5hAMJ9rnRLudyJkqIoRydPRxGT0oIzml SmhMmpBISfASlaV6HTxQEUYY6tBMKxgR8H3LF5b5C+1OepOOksbpbkcuIgsFJ5nrp9vLRIVNTrTL +YSTdKZy9HoZ7ZS/LZNySvAiXOFnVQnTwnHlkuRm7RSjC3jQ9XKp0zGX2uMSeKh6HW/80lK9wi8J FpyAojA6WY8ZNUlBKFS9lpnxWmKo5rsvfYz/QdLJ0EyGyY6VJ8rNsosrLyC1ehjk8qz/LLuUXEr9 KfFR8s/mJcelxKXkZdMrVMy6+Wj+gDmNpslpqhluSs1YM/5cfrrg5xBHMpTH54oz5vu9v0u441Qk JMQjq6LZmHnUc5Q5pr6YeDHpFQx/xtxojpS3l/dm95qH2NcSc+V/UJfivqy7XybOkDJSUBGRaAEZ 88SZwgKSqoGcKEfPxGRJkRAvqfDk8MnomQg+2SsIyYTf6+B0e3DK6LdEoZjrJwj8UKWD0ai4QN1R DUWK+MGSHwgICee0v2mfapS2QIWq3gkOjXET3AxHcQtoqBrVpWhBcSO3OaujMX1Cb+qUqvfppH4a qUQJqW9u6n4c97QaV+xwdL2+bnT+hobqNasIvnL+BoIpeIPWRTgPrQvHpot823LhHbhSBnJa0u8N +f3ew2zBYA/wSzWR4D+50qo3EN+60mrP7WkborcKqsc/QBg1W9Pjmayi8gEXrQS0OHJl3XH4hOU4 QWeccdQVdpy94L881+jP+c8D1zKOeg01CPhU4WB0Fs2Ss9Ss90f+mfCMNBObiR/tPZKYzfvAHhto ErcCuMxbTBSTL5jHksdMZ72GTXMgo0YtTyZqoSpjkbDFIELMM5aEk0SUsQpwyLQ3j+XjZaHCqngH FnI+ZtlD1EqCKZgPWon24IPhF0HLFIPttYT2WpwAfyH8l+9qjY3jKqNzZ1/z2PXOYx/z2Mesd+fF rned2Bt3rag7oXGchIaYAk0NGKcNkUgFUhwUIkQilh80jlRoWvKDtICjSJAiJOq8HLtWGqeqUCQw sQSJ2h+mCFkolbxRQKGqoOvw3bvrNP3DynO/O7N3772ee77vnANLSLWSIeHf3POiURgWrfmECKwT wRPc86QIrBOBMXApIrmo4v/7wLsZJeVKzHeYLJlIJtt1i6iovNiHVRWIKqtALABWYtin0idz1pGv bXvayI6/8oerh7/0rVw8GcnlUr98bmjPs2t/7el57fubdvWJghT2vbF246fP7+x5zHHLw/vOHjud 4TQ0/OJPvlAb+vrJwdqeiZ8lo10K1LDYg3/Sm/3XKR21OjXMTHsS1LC0hwsUH1Ywe4XjMgrIpCsT IpNBNxHCkzHzEbOA30UY/0bmmVI0EfPPIv0ChYLAZK2lxUrznQ6HLYPar3y6PqnJMKahBGnjj/Th PO5cInJqvaNiPRfDvYM84qM6ih+IoR0xRJbzAIqwNq+jADEHAQbTXICwYAA2eJdMgXdK+A86/7lC rIScTn3Cf8WlRewJW0tjYwvCovDOGBAM2Tkcqz5HRWADW8K1cTRO0/X0afG0ei1+LTGr3lFDU2l0 QkO7w7sj4+HxyL+VQFCJK7biS8QVVfMh3MT0M8gX7+3s1tdL0ygYruJNJ27G3ycaa39M/yPFz6JV r2QAeZYr6ek0naYQ8vsDhdiIjBoyomRBnpYX5CX5b3JQ3pv67Yl1a9DC2b5ZGLsP2qEJdWIzVW+t YOoUmvDVCgL6pIg629ALYp9o/kNFDMa+eF4kmmqgjyguqyrmq5uANwfQztu3+5zc46Kdb2wtP/OZ lwe+05N0/dfX/ryt9bvRx13nuX194/vob+YSB7Zb+zEz0g9WfC3fKcqkezuoStgeRg/TkeW84eBb 46EeMjIdh7niycRYamSgJqXwOGkdbtK6F4XO/ct4oFRYt55dihnkjS4lmC518SEGcvgytp4MR1WW i4twom0Jv9rG4WKRhIXl4qM6ak/IY/YyBxkfw/EGr3QVzCTM2p6S72hiDmMHEVAhQ/PjO41ILI3D zzSJYSyDIM8IEmNqWLDbfxHsSVgf4q9wh2BPkmyrgz0Rt9AIi3BDmgUMxDqAkAgx0IOLmFGryMau wrAxP0zb/n5+IDtobM9uNwIaI+/GzjO3O2PaecZGW0IZZqvBm2lmFg15MkeZJlAS/n+6OJ7j+ZyB tX8XNY1QFB1EU+gm8qNZ+qpnSqpWkKQR+aRMN6CZln0YdEYHdgA66+0ffFqnARUB/AB9FMZbvQ3E Jt75Q6UG1CHoqaiYimopShB1IZ0CGydsBrYADzBGgBgjljIZyFfXcQi6LVTNddAJd3bVty+aS2Tt rrW7Pd89OrRropQa2I62jNaL3/5c7Su+U61bU8MpMT/xduOzoy820OktG3Vktl5rjGx6kg59foA2 AaMiYLQJGDXo622MzrAspUnB2FuAJxEuAy7a9/fzFJSwZnN1tV4BRqjAAXSwskHhWJ1h2e4c/I6P JfD5xuSgSPyfKAVp8gTy2yAdA8+zWPzkTyI6trK8KCyTY2WlL3LPKF9VfVDj3r3AV7sxCz0br8bU mJZnu7mcaEgFxVANbZCtcYNSTamqg9pOZge7lRtShtQd2gHm58xp9hfaq/pU92+o15lfsWfVs9rr +lvMZXaGm1GuqG9q8/pC9y3lQ+5D5b9azxSL8CoXN+7tJ7G4oR0zbjsOD7ejbbdjPt+Ookii56mp /mj3UeoQOkQfDBw1fhj4kfhSNzvI9HP9Sk3/fXAh964WmuROKMdV34C0XaFlJZaRKd3IUBInZiAL XvBKrKYaiqr2slyMZTld0wosAz0mFAz4/QxIMlkC2UQFNZVXZhHQ0ziHBK7ATXEz3F+4AHeM1TGI BS9YOcPMMX+C7D3Gqoe1eaRTBsXCfqNSP4v3raZJvLCxisOVcJViF8AuzaJrM0I3anS33waMwnEm KvfncGFVhSIY3ftjuF5oLeUfKmBeua81cTykNNvWhGAdV9fjbTl1PFBWSKcIuqqJhIVHW2AUUO0T 64qAQL+IDoG+ucwZiUgditedKxDZAuhlMAugUjgIHifXGANkClyozUhYTIyOyrl4W0jIMqgGG2RF NRcPggNCeWRZtmWL6I2U7cZv3U4yfHc/KvbH8qm1eXdtLuFkxY2+U6Zl5HvXgnTksXQXG+VN0y9m tn181xfYVBFYBrIl8mAlcAmypeRb7GSLlcuIXXRpFldeirUUxu+Y2WA0iGFer1cqyZrQWoLPwiM5 M0dZwJ5bcd1TUsRSkBZ8EiQI024Vi/VTDpn8eyVUog6byOQPO8jh27OXSj25XLkHpw7USrxWfaw+ JiyPkcVE4jrIW9XPS2UM0lS9mrDBYIqmbZTHywfYg+UPzA+cj8yPnDAecEGuknE39Gx/rlx2v7Ep rapZPS+U/ZyVtkpWzfpy8lzynHLOYnhzoDBg76aeRLtCO5jhwjZ7l7PLnQw1hIb4Y3PSmXQb5VeF U3iwOS/MmXPOtfIN84bznvmes1TOUgF/KBj3J1kzZLNO0K0mnxCeEEcCT4WeVp5yT/AvCZPKCfVE ftKctBrl5HH2heRxyxdhR9ER4Yjoh5yA0zRNDoUgK4SkmBGMfC5jUG4pQ0W5rkw0q2YyWUiqi4xj A5ke8zzFLBhMiGFDBdeJua4DaDDtXoaNMQwL6kSNFzgzxnFmvlDoVdSYoqiulVeVJAf5x8E5zKNV SKIMWr2YRVER3wlUF2gTYEFByGYNg6LxQ0SVYAgkqTKPnqdMikG/9qKOB5stFBze+Di6nwNPdf7S ArXfzc8ixot7emVERWdUdFW9qb4PVe+VQgXSW79iRE0kwKHjVOTD/eY8EiiLikOGhz2uMm4hz2pY tAUC6RJ7zK4wb0KaMyCnOINyUMO559AO5n74qXMmhAuDPuKihosoV3AN13On3QV3yQ25e3seqqbm /eLYhKo1WytgeiY6uQ2PtP/RXXaxbVtXHL+XpCyRovghi6QoWbJofVmmvqIvm55W0WjSJE1iu0PT Ndm0ZOi2JEDRxEbTJt0MFxg6r+iDBwxdi74Y68OKrNjaxJnjIhiaFs5jhjx0QRYsyB6ctMDiLQvc oFhteedS8pqsC4l7z7mXovh1z+/8D0zA4eByCKQUaSTYSaiHiJ5q1InEqnf2tr/SrrMg+tsUEIAC nk0ceO6fMf8fGL7euyVP3VN3gDGBm0CKSVJCNE3CipQU4BukMJkH2004EbG0+0yAmDtnNCtJjOKM TittdJCtTY6uNjjShBNtbGyCpDPGcbrNER9+GdLw0sVKMK3W8dkd0YDn8keBtIWNb2daf8rcbH2e bF2LDNWBJ0y0pze7/i/8u5m6JtDJJK1J8YCyfhd/WYt1R6lk0ndk7e/UzvVzNLWz7COaMYwQ/SkQ Zoi+29GMfIoLVlJMDsFfFYAzZ3PdEjUEzgLKReU2aAoFQpkLTucUuAQ29ox/G4dnfbPCrDyTmqlc 8V7RrqWvlVkxn+KS3gQ/yR333iq5e4bz4v4ak2+4GlJDHko1+q1KcXind0wakx+L7kzt7t9VsYef 0p9Kjg8fd097p6VpeVqd1l53z0lz8jvB86mo4BIlURazvVKv3JvNcBmtMMxJw3vZ/bXxYaajFBJw 3yeH8BB5kBcKuJBPVYIcg/LkGaL5SMTK54etTaAVCo0GeRKHaBfaPXmmt1MQm5qqpiuVKufl+TLI D7dbT1WqlXI16Z9VCzKWqyBLVT4ypY9HcbSQPBqfjlPx2TiO68l83irn7mYy6fI4vO2pKq66XO6k 7nYnqslAtZrk1XS6WOYD5TIPXz7I8lo5ndS9Q4VUkKP5irsq9uCeXvgShTz5DJDAZZlk5TyTw7lc NBrheJCYfziqYjWfXMTCfEzHOuEqL1Vt/X39b/odnSETJBvr56kaKiM3PnSmmk8DD+ZRGZfPUx8h Cw1Te+aNSxCa5r3myuqKtG42zYkVqGfasdfczLYgNZ1OqjeJkHIKGxJ6Qt6cEabagUYcHPRbU4Xg bWm5Sd7xsvOi/Vaz0IQZyRlKP7kNntsj1YX6jCDVp5aWiFnyLLnBeGB2H0TgZLNJUvUEmoDg+wB5 IaY4ywulyTnW0mJRfwP8z+bBKqRIZXvkhs8OS40gmYUBsXa3JjRctt/bcAehqxFvmEgRsJl+kfzb nQXRSsZEkvCvnhEtNwlk0SqBWfDBAZ8zY4t+KxUjTYY5mZwHktERCWf8bSO3JUPYZ0nwAmRomu23 JEm0ZGhZW7G621RQ28ZPUqFihWBkdytWzaNY/cWAlYEme1SLdf5MtTK2DE2xSqTBlTVydWjk9NPy V2x5cEP/M8YPHHAw5OgXVdMGCXg29Yu7W1U1xaiWyGw6TdDkjElZOkh0Thi/lzHiXnVk146+FK5t SWzZO7X85A6rNZ7Tu+2f/XJrLtf6cyKc2n/h948/8U0AU48WLEl9hw8/E1IigKVg3+Q7rcWTW+hE IiBoWnNp6TtyME0lEq5A5MWNtWcHIVb41mP0KpCpRPV1yATq1Byg0Yk0TkegYgiSQjRAwCQ7rkxc ynEp4pYct7S4WUyYK+Zt2BuFS81NZHVIEWVNFAnI1EslXEJ+wEP8JXINMRAoI1Qp/1f0XG8uQV3o sIHUV1uK70u7nnz6jyi88QXSN+6gEICek4Zg2xe232UlWF6C+XqG6q7k1R/Ufup6pYtiWZffo3tC rBkIpdiEPxFKmUO45q+Gt/sPs4e5I/qPQs+ED2dPeE5yJ/UXQ8+HT2Rf5V7V30Rvsm+EfmWeR5cr N7vioElMMzswwGFHqetE3mdLHXmf8sT0UKg4wAXgB1nTdIS9OQCnDIRYhvNkweqgNDzxjsRPE2AI cLfpQtyKiBVNC+lELYRnOXyDu8NRB7lj3D85mptqsGPsAZZmp6CwFeyIeUWMYTE2F6NisweyuJBt ZKmsXq6cMn4DVao5Ckp9z3JzYnl9tbkKmXR9dNsPt95CjT3ry2YbJ+RDOPjw3Je5wRK0PDRRf5Wc 8QRBg/kwKe5ocaecrVZq5ZLmVLKDOOUkXR6/q+Ryxo1LstvTZ+KBZH+Q1Vuv1d574hu7B4uG1c9F tydGWudEQ5e0MqzhdCS9rVXC/870+1mvD8R60BAaa8+98vOt2YGyKj6yb46a783HeYmH1ZuBvPos rF4Fn7ILfg8TZOaYOd+ccIpZZNxzGvZpx31bauPoaXFcocOMJnSL32O+Jd5gLovuzqrsx7Sm0iIl uPhdLvxjFx53HXRRriLftVXEz4v4gHhUpMQixaHGOkDS6QiR2xWuBaUtuidJI0oUeRdxwi65XGe5 qJcRRDFBMwGaZmgvxYiYFzQfuQoz7sKuoo/vkg6IWCxiihPPU48gATHUI3aWxvk5eKz8uA8Xfbbv mI/2hQpaQxvTaI3Pe6uIwpSuar9up5DR1Yk9q8ujUvMeLIDV5rIEO+SR9cm6023eI7lNaFC7zUwt BbG0AjL3845x0I8mTSjSHO4LG5dtFihPF6FjyIL1gSPaZJRQLXFx468LqsX0B4h7dSFgMcf8xP3F gt9iggpxP1tQwBUd97T4IDSBiPswbVSx0UdWTXzQULBRIsCjv+tdu0odbH3y/Xp3mOnvotH6W3j0 yC5N8mK99WmCHtDjpcdbybVP4tnYIfjs6NbGsjuEPkZepKE4esM+FkvaSQrZXbztD9rRqN/f5Q3b hv1o1bAb1TnjhkGJxpgxCw5z1PjQ2DBo46oIWv3RqkJ+oNxQKFEZU2bBYY4qHyobCq1cpW325eFq L4QjNcbeYKlZ0rFfJG5e78hrc93pN00nkRPBvEJiJ1lSlUAnNoyH+HhvwR7J50dGqL9Ad79jf+wM 853j91lQlRv/wBcZmRLgXUQ+QBSdtjmEQi58iNm+A27u5qh0DxX2kLswqgYjf3mdieOLO1F7e+Hr DT/3YKPfRohJQfstQq5sp60h1PUWtFWE3Lv/w265xUZVhHH83+72JtgtbS1tsWQE3JSWbi/R1paW SGkpvWx32Z62WGj00D3bXdnds+6epYIxNiREJUSJGmNi4MGoAS8kmvhgH3zgkfhkxPBIQmKMT8ZE Y2Kk/uecQ6tGaaj6onM2v5lvvvPdZs5MZslnQOl3QNmXwIa3gXtPAeWvARUC2ES7ynNANfU1TWQJ 2PyCQy3HdTMs9yrQ8AEgHgK2HwJ2fOHgp0+jBjSNA7to3/KeQzvjdnTyungF6Pwc6PpmlR7a9TH/ nuur9F8G9r8LDG8ERqbILYfRi78nxLke/BrQBoDpGmDmR2D2JHC0EjD6gfmfgCd7gDTryiwC+RHg 6Y+BZ7YCz34LLNLvlAU8/wjw4kvA2Q7g5SeAV68AbxwB3qwHztco1sOF2r8grFAoFAqFQqFQKBQK hUKhUCgUCoViPaAQBZBPNTxSKqgnxVjz8aCIbdk9Gzai3FexqbKq+r6azbV19Vvub9gK8cC27Tse 9KNxZ1PzLgRa29o7gIc7u4Ce3b19e/AoXQcG9w8dGB4ZHQuOh8IHIxPa5NT0ocdmDh+ZXU3y/h+z frR2Yf/U48U5toI/r91vw07sxj4MIwQNhzGLkziN10WV8C8vuxZ+NKMPgxhFBNO00Fctlm/+2Y8e W25cuHHa/QZ3fjxrWviwtGJ3a8WnBNc5up3huYKvXNmD2sJJV/ZSTrlyMeXbFZUgWXhe7gxvmYzp KXPlArR5S1y5EOXeLlf2UD/oyl7KeVcupvyOK7Me7zUp+2T8WNGHXM8TyMBAjCs2x17gEtEQt+Ug TKSJ5VoJfgUTWcqy1alP2BaCmiT9A5QGbL3+NyO1rlQmMME3SeRXbHLUDbN38rWjm782tLhSh63d S48k+wh95lmDZXtFGC9HsjjONsocCaRsncA4+wXbxqROZ/zLdv2yuijfSV0Wx6gzuVrrn5mg1mBN CWa17FpkJYJjaWO5USc5a4Gw7S+4V2W+INsQc8fsGcoKpZ/BqDm79rgbLaCdyBgxfc4Ql4QWN0TQ TJsWVWKfmc2YWd1KmGmRSc4FxIBu6WsYtcpgYsJM5qUmJ4bT9Gvv7m5rYdMREHuTSRFJzMetnIgY OSN73IiOhIfG+oeatUTKyI0bCxEzpafDE0HtbvW2QlAjbNVFoWX1qJHSs8eEGbtj0SJrzCdylpE1 oiKRFhZNJydEWLeEX2hBEYrFAkJPR4WRzBkLcZoF/ucHYYRbbQhj6Gfb/Jtj4RyK1SMRZg1Bvo/Y WzjPyPJQ3K33v23/Hz3W/NbOLOVOyPOtHI1xNMQrz5mNrDvB2RjcfXn7jVPVAcqDjJjgBSnzOxU4 Nfnd1TnKtTKZhQ9voOIz+B693B4lvGUquA2ngKKrvireHs7/Ft5vS4vaU4/7en8orSu1r6y3bjZc kf2n1z5p/Nn65WwFSss5lHeWfaf9KsAAfa02oAoNCmVuZHN0cmVhbQ1lbmRvYmoNMSAwIG9iajw8 L0Nyb3BCb3hbMCAwIDU5NS4yMiA4NDJdL1BhcmVudCAxNiAwIFIvQ29udGVudHMgMyAwIFIvUm90 YXRlIDAvTWVkaWFCb3hbMCAwIDU5NS4yMiA4NDJdL1Jlc291cmNlcyAyIDAgUi9UeXBlL1BhZ2U+ Pg1lbmRvYmoNMiAwIG9iajw8L0NvbG9yU3BhY2U8PC9DczYgMTIgMCBSPj4vRm9udDw8L1RUMSAy OSAwIFIvVFQyIDIzIDAgUi9UVDQgMjQgMCBSL1RUNSAxMSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4 dF0vRXh0R1N0YXRlPDwvR1MxIDI3IDAgUj4+Pj4NZW5kb2JqDTMgMCBvYmo8PC9MZW5ndGggNjE4 Ni9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIm8V9tyG7kRfddX4Gk1jEYw0LjboVOSsk7t buXFqyq5SswDJVMSs1qRFpXY+wH+BX/vNoAZzgwGw4sip1wyRyKm+3Sj+/TpV//4lZPb1cHp+cGr 83MgnJzfHHAgDP/hh3SOWiIsBckEOf/9gJFb/Dm/9v99PijI6PzfB5xRZ+Mb4QmcpI4IR5mNLxUQ jq2tOkaMstTpyiZljIE3WkyK9+8mo2AV4cgIByiX+OL53+NJGU4+jpWtjkF9jHEVzx2Hg8JDvCze kLPDkaKqIGNyMXKUF4ejf53/fGBq1OGBW6ASYRkqW7CEbWLlXHfD4Bin1L1QuH/luHryAI6CW5t1 C9xQpbf4NV2/AI5q6Pr1xy99hGclWflwoRivSrKsHpcl+VQ9fnpDTqrHk5KcVo+nJbnL4ZNMUdvN S8G6cCTD4AbSUIzv/OHEJgDVSa7D4dQwaKq7hosAs29RMmqGslik9yalxaLeA6/mVNmdrev+7Xjz qikLFXvnDUkK/VhwqoUix5yC6NZ7LAUseveiRa80NYhVAjVsqPpsUvXaUoPZkJICe2bVc8eptVv8 uqTqmaBOdvyuI74+aGIPTUC+1anldZ6MqDhk7eOvjN9cve2kk2FhqhbXmHVU/tGHVbWXK8ZkRUJo +LaqnSjoO2FWp06MaV+ZXAcgYwC/Xi2+TIqzwyqEyrqg0u5lvTF+WQRziuri7Vs7GSW4RUOw/vR2 o6JjVKFRrjNW9X5WXcuqxop9+xbkZOTHgTd8DNbfIfYGxyuK70hTFdv8iVxPH8jVjKzuFp9nH8nT 3fTJ35S3M16Rqz/I9d1isZo/3OJXMzJdLh8Xy8f59GlGJsW3GnldLJgQp/YvF86rm5TChZtE7JNi Rm8puZ899WpS0sx9bvVRu5Axcqz2BD0mSO0CPiU5QXEIG2iRrejibXOcQQTECLZmxO0OjAy80XYA gw5MoOi97FtNleza54P2HQtjdy8HzlLRtZ8MLMWACu5cxy4yhj91LCQVOpSv6vZRMX34mFQGjoFO /W3FhiyNaosYrigfAMdx6nI84WdqS3elDBcKKgHD9P71xJHb/RhsI+IJIqmDDkghiQbSmtFZ2SP0 Z6EyOAp1F5VIUFnsfvv/S5Sfa6aLCNLJZ8KUThFBgwjWZMC+WEYno9LT3EMlAGUjAGUjAGUQgBW5 4qTmTXEet5kmDvTi9BCtv+urIxzUfuwZxrG+W2oujnFIi1CEJsVGsa1QavGfEV9ciNCpbfON+Pp0 mNj3Wwd07YeDZc406kDWRd4rBgWB6Fr2YsJ1tPrufcasF4C2n5BeLky4+D1SgZVpErzLw6NUgAJ+ b6BnuCdAL/148ioNtzaRX05Qj3rxn839kEyTKNMyCcuotNMXUGkVu746W2lyvcKvPYzV9QOeqU/k FgZALldDRQXJviWY7hUtuR1mhczVCVBUwMZM9rxi4QvdL2Xs8qN6bVsP/yr88GoIH6gzdfwZOGb3 4LHoWBq8P9i7PB795e4rZGufO4sjE/c/pVvrUPYq8SY50Tj8dW+TwOokSc8xPA14HD9Y9yqTBabI 3qPnLzfgrW6IlJG4X1u6HkP+uuqeUVB1ArcJ5QZqvWyhzDw5CkUhsKtHmDEXKzG3eyFf7xWCnz/q 5UI4boZXM7uqCL51SwpLTzxDh/e7cjKiJNYUl1Q61V4jmsDDCdbVaJE2kZB/+uFHv4pEv7Lmq742 L34bi1p3Qn2Mixa6VN9cFm/Ih7hITQrBS4Z+xuRD/VySr6TsHDCtAybM+jEHVEgXI1Q3WSaXGLYm WuF0HCJySPSiBC83CCoObMItOuii3ylSsfD6Xi41+MnVcRnnLPlaVvcnvMpKlIqN3X6RYQeO6gqJ F6+JQp/ssJ2TbkUZht9pVKbmGUF7+RFez3mrg+5JDE5xmeu4DOBoDFh5wuquDbVGeP8uU5ESWqUm w8nHsWZpRfrCbs6p2I1gnKor8swXnPGBnpVkFX8ZrypFaRpFaYKivJs9zvDYItQeJlHatnlXm1cV X/0+svjibHTspQe5Xjx8nD/NFw8rEr+YewYTxe3dE7makcf5avbwmtwsHiuxiorTpTlp1A2rQph9 mXproljez16T+U2NHCNa4g/nUSOTu7z08ddBNDcdzb2RJqXEnVVztxbyXZbkOZa8SYlMrUdgZvyA FlQOgOrjMbGw2oBymSoILqCvMLm56Spw6YBMHtpp6ClQgcmz8vumQigVo8sAy2Iy2ov9XjZkkw25 zga5mT9M7+//qEkHp74VKt2PZDXCHJex4k7iipSZuQBUIFgkIxRRMtmRUsWAxIvCTzPl9ZncaUfS gXba5pu6WKY7kgyqvmN/eEdCGrdyyDTYlMsstbZjevu6hBeD+2MvN7204F6r5F5pcX6OdCzjwpjZ l2w81jXMdXW91sp6XWoWJplfmDwF6IFsDQw9UNqzWc997b1yjo5/yXnErGSunrc8rpL7ByuDIu3d f687hdilPcMF2zVcWCvSv2G6Tkq/q+hioDGEloFedmoMoS0Fu08FCIP8P1S8n5K8+E3H6B37QjiI h1u1JRN7DkfIns3gdZrMNQMkSonbwH67p0ICvpEAXvabQaIMkZuaQWSaQeU1p/XyeEszJFcsnaTm 5Uqz2iMFil+eyHpo1r24gMR6PS3JAlXB42fUHK87ayoipIpxp6tlFbtWp6tJdkHlllMNRCEb9ZVw n0Kt87pZOd6S3fgtbmtYc/iJZYXd5hG0UhOXWGh1JDSDDWS10MYQc7oCpOftPMQYWYoTBHja6uCs tPqmrOFv1dXkUgXS+CE9kCoOdai4AzDTXgxjFtqkioZkksV9k4I3AXpjUnjSluAM8k3qlTeKi1eK 6w1JdPsx6hiUx4molY0r1PC9rbKr4dMdZS3iXVvEu0bEu0bEuyDiV3MvmFUxv58+kqeFl8dk+Tj7 73zxnxWZfVneTx+mQaaXXk5Pb6fzh0qRRywZ8C1ldVkEr7oR4LXw5LBRiiNz4TxTuBzKXaU4CiLA OkK57L6bFlfYMzAAq48Ij6Ey6CDaX4wzFLuZTGwW45g+0C+Wi4BVRQO5uYjzYwBhFpw2Xr700tLU jop9WpLp/WpB5k9kviLLxWo1v7qfYdFMn7KZktZQIzfXTDpSnfLjepc8yefPntxoRnJU0mZXugQj ZzLQGory5690HH3ZIZd5sudeo3bdvnQ7caNwNAzkoT8khd8F2oBi9LVqDk+ecipiOfHMw4vIVg1g 4QdzMsO3a13dZFtnxK6iNuPIif0ducaRaxyNjlEdFX2tEjwOjF0cLnwnsSJQrAzXI7hU4rKkGL+3 UpGgArNvKt4EpBQiEGCvev8XpSJRqYjhvhU7KxWpIgMmLb1fUrxm3JiTCKhNdsZr835OaMVaWLCm xVrhr+d/ackZ1Ms//fAj4unqGC/5W3cb+rH4bSwg1S5ctApdNIUuaunywXeSQjcCSoZ+xuRD/VyS r6TsHDCtA8YfeBpzkCWuJw7bPrud4KaFOQO+QdwlC50EHaQ5QEfe9YSXFzgXmVvCZOt9XeIAM9B1 WdXu15JUd+XtNXcVgNhYhxc5+sd9TKBJ1BKQmzgmoVquQn0yi/vulqDfZbyJqJLa3lqtmvgSOJlk 3xdvfFW0PinC7SMNFiOM3Pl71/7e13+uCuGXnKCUXtEPZKC+iCQNoLBkoQetQVYDG5Ej8s/DEepP BDEv0VAozYsMDoHh8v1giNCwu9zGUTKb/+S97HYjx40ofJ+n4FW2nekWWPwVs/AGs4MskNtNgFkg vmnbPeNGvFaP1Z7ZPMC891aRUouiSFk9P75YuGfdZpVKh6e+QyKJfahbQfDuOl1Bpwvcm4FAwbgE 7kXnAb/+krEAUcdbzDsZ5ZeJB4zzS3juCpQSUXwxQ3gxfXQxfXAxUWwxfWzxk0bVAktWNp0N/cYe ZZt2d0O5xseaQ7fBTyElJBxwlUpmoDvYgK7fU5o55RrJ5oONwY6Ysq7s25NgoygLKdzSz5GYWUBi 1HwR5YWWFb7nfHuZgONtaNTZSZn0yXXOHqFp5kpwQ9dsUvOZhGMq+zIzkUoTeGb7y+eb8DzJVODE qbXrOXUu32TWFwYcbea1kwk45puN6ax4owxeqcXxRlEozGlIqSUaAuUqpwo1S/kmDDUuXJiNWyYh VZQQWOsllB/JNOmg4DKdhRKfCARyeCq43xNzM0iRUOBOES8zAiEsrq+iKtLGJH6tLAq5yFgEyt7P cUYUSW4QRNUvNBHJnff1gihcEhokbiMznslmWMtUiXc7yW+f17jSMpFUnJ9I69PQxRBIr/rkayZF 8D67s6tA/xSSMDaqckbg3aDEtIwW9nzsdURiChlvSuYryVOXCmsb1+MQA7537kVyobyZbzE816RP RcgyavOrYy8YPK00KFCLUy9YPEckMzxzJILryqrZkUASpwTIytbTsmIo63WN6JlA7QbwvaKUUFBC jtE2lEK+lTN8iznIRFSLmzikRIc5IbvETPAriTecl/a7mQ7V4EAoRUV/07EGdhAaeOXL1vmyeBFI ZrNl02iEo0FkH5XtS8rem5HhKZKkFiTFoJLn4kjs+iB61/fJQGMCvGTt6XzdvwEHLOM+Jq1hbfja JuZ6kPTJd//v6+aPq9WbH5LzJbHPOecPoqEI2+ngp5/qq4vJyegww8nPHypHh2o8FEzmVHPeqXZ0 qsNThbq6uLpYd6FI4qWo/aUApdMlIVS/JLbvt3sKV0d2s31g1zvW3jWfdrcBb7tgx67/z27umqbd P7z34Wx7ODw2h8f99rhDD0iUg+5u5Jlx1t8F2fdWW69mtJar1a56X7H73TFZ7IrW//klTk9/kn7S /Eai/SidW06Z45NFZb3nIS7YzsBWctx1vKjAYxagZ3VffvZ8wJP1+HxRPB+CiZ91vqAvjwtAsYDQ lajPLCBDao0LpIsR3Y1iRnTsAE8njvJsjUiZiEJU4JYIL4V+8DlwriurPVakXdmhqyBZEtR4YLj/ vqAlioO5NxG15AJmpi3JoSXZt8TXk0F9SVdCikpk9B3HAVMJ8XJzEtpMrlySW7GP9KJlW/JmwP+o OcOYQh7naZY1h+O+eWgr8lXi9TU7dCvtsGYfuo8fCEm86YIiBBnMgzxHdcTMZUcZ7f53zxb7+y2W any1w+Pu4755alm7u6GK6MjvqJQJMOJPB7xxkFm4uLbCqz7gNwH6rIUPHz7RQBA3zXjP0VtAy+2/ rMLzZRMrGjJpTaIqXYnmEnkq/K7FMISeqJ4JaHpBQAt/tpGKtvppvKsMeSIsyxqNIIPA6Q3iiqxG 1rh6c+FVLwqvoHHPTkvGk3kFExjkFcanUeX8cCQsS6+mmF7B8Qp3fbbBXG8CL4qeDAWgH4oVPdtt 79uGuGHfskPTtvvr+12ghuycJFqDyvQxotdxK1IpUu2SMfElIqL2dXFQ0igEpqJ40t6sCI9TEo9a Ih4FNYad2aGIOrlYAi3hpWailCGKKMxk0ppW4WmS3roafmln7cU4DBvz0kgWjbKWstBLjQFdTJSl kfSmucZ761ypu9TFvG7MsI78llgNspleaQlVjfMylAcLqnEpVmGqxHkZ+vEt7DjnNLr21zXb1rQj Y8hnJg3lJQI1r4pHg0qOrmsKU9/1YQVHSailHQnwsDzq6JRmT8GWNvLMayeSgdm3LhNsFfhd+N6D qD2CFQYhOUtacoZwLG4pPH+/YPwnMk5PI6+JsGCVpjRZQSb9zd/v6R1Dc75a/QNT5us1+5kK1ZlC CAFnF3JDITcUutigL1Co/Xkd4PLTvt39vav4pjXspqUpVZqDI1Zrbx7+ssGUhaPMpNFVTiKuJoV4 G56+ign+GC8ORGh++jb+tsJ/OPopkfVq30UkGs7eR3Kh44U6Pa0IWHnZjTXnEQq8b2db7ESc9qmQ XcdtdkbhRVwYHP6rE23WTowk88kPCnT/oBhKuI1TySpRM1jp9+NohmeOROC6oAs0M5LQUWwnsrJ1 ZiZVWDBA4KgjTg7//z9/6z9x/zsV/5InqSVsw6vVv/76T+y78wvVx0ejIgX4q7v636U0F6NbgdtS RrciTab/Xf3IfqNrp7GMNGuOdS7Zb/3nNfvM1qMv2OgL1geyS1CYbd9imoJVnq9w1aLnoIJEYbQq DS7EV6hQTtj8TIR9m0EFjAPm3JJG+KwUl+wk/nnNOmYAgvzTK/KN1EGvb3MC55KQStS6MoLSXrKe 0o0J3mYE5jyIvr70oYku/J/nqvUPnZbUUCk1LhlrWJPFjxlJdJL89ZeMIrF4pDV/AVePl5ankiRl D98LHeJVUKKX5JsfLgw955s1a+njZbtmB//hsGYf/IcPP7J2//sFUsZqf799ZMfGaw+HCOm6obOh 3zZo+uzwuPu4b55a1u5ujvvmYc327+h8v30u2QH/w7Dlz9sAOd94Brpbk/7y0qEdMOCwqqrq8UHA mvn9mU0dQmovDuQ1XtJoIlGhJPm20A79bp4kzELehjJvC7wQxQanvVk+6S2OYrAoiqFhVlpNa8Yz eQUmSYEYaqmDlxmL1LpCxWZbzHZntfeiZDDQoxaACoNZs+1927D9ke1bdmjadn99v0MBbY+F2Bry 0KyARCEUPTurNB49MzAwxXkBMrom7apKZGQkph6I6VUoXMcTD8Q62i2RERgqVqjZZbM6hQh0r6Rw XkQKFmlobiROVbY0kbQxwQWRyaSxUOET7SfynHxiE4oS2+wcJh7jY9uLzEFY8FepMIiJwzh/zb9O GlJYorZRzWEaE2eBqh5V/B5jIOgUqjQGk9CuRFuGsVA3w2KmQlwk2S0TqJSMiXphour3tO739Ci5 mUkZNfz58ipwep9SjqpgYAsLGV+KNToh5eEdxqluJpsoRMNRqshGFOQjlJzkJ45MJQK4DshqsKmB VPMB7ttkN8c9sUUtlfVLRqPMqLmvSmyC196d4+LRhRWLI5sAPKhOpnZuZEPIrwu9dN6WLBdalbWa VhVDVS9s5M+EbDcYYdBoxhSohkrIuLCIcXFT2yLjsiWQi0TQc+5wiSPSxZfZAcVSzB3gtQNeWymd fdYKSCn+8JhzxRznggOPKbjG6oWci4TiyZMr/DELdNIuM985zBXc79dsf1PMFbVfH3Fr8RJahrnC Gg/Lac1ZzBXOVE4tmspCzJ0bi8QbKvMd5hkcr9Z0Lj3lAobTL6RcY8PBM/JJrrlC4nbL5PMNBtVj eEE/RQLPd5dy93CzN/1HfOJBW9P9QMiCj1C7YiqYoK90VW38ZnkuPy0ZVx550XpxE+XbmnZkDO6h aUNzqAsOTbJYIN0E3BDlftdHFkIT1i3tSEqS0agjeuF6ePfavz028/KFrSsYVxxeu00K1qLyXjsU /JZPLznaakmHK5tCLb4PO24mPHPnH+HTCGoryGCtP/FMqk1vV4K1fldOCmHWOLuQGwq5odDFBh1h Ffg2RldfsUBp6DiQ1u/9A9leDP6RxTjnVWL1KW6k2gAetGHprbwE1EpbSTVqqSxcUEDLM27uq6CW CJ6sKS4e3VO5GGrB4EF1MrWz8R7jaaGXzr1lamWa+GVU1XdXBUE4NLqU5jpakcJ1tPL6/njXPL2/ I45jzdPx8ITreNvesY/b+6ddy7aPO3a7C9xpaUHxlAyl0N1Zh93D7e6WNQ/+sHf7x/aI/PkRr+2n 5vG2Zc07dpdZ9JpLUqWBXK7ZF7YoGDEkm/ICdZ2LWNW5yNVqf8nXsP68NlcX645Gbu53RNiEIm1D zG1Xuwt8b3LVjyQ8wO2fjFfJbsIwFLz3K3yECqIszsa9h5564Qec4JKIyEaxA+XvO7YTQK4rcYui p/E2M++NJEJq0nZMHDlBNRsGoqa2I0ztgmejZYbICubi7v4ezmt+tCzNiJnQGhq8c2BODab5hRZw Qc9bANi1hw3p09Jc3H/oLgLgEvGwj0u0WAG6QmIJHCc0+MS+pVjIJMv9sWcT1EFSu/IgeEo98LSM 4up1cJq68jB47oEjZ9op6UVwuIAtD4N7c3MCZiRFADxyEXRbmFbzsHP7c//+NBvgK6ty935fjY17 w21Drpy0TFiiKnazrHbyTaOc+k3JYCzSIIwc+hF5EczWrD0ZHyANh3zPo8TAzg8b0kALAJ8LnFT6 NXaZrY6dXmKkXSkwyUJR1ZJRGziEnMTBBFv+cx4kpKg7iPHK2UlwpSLyKcjdeOqnnVcLVjGz93vS 08jt0a89JHnsL9xurljJdYw2bk1Ms36ACU3jI+0CNuCP2+UT1JeN4uOF6V4KNb/Mx/7tV4ABACJj xiMKDQplbmRzdHJlYW0NZW5kb2JqDTQgMCBvYmo8PC9MZW5ndGggNzE4Ny9GaWx0ZXIvRmxhdGVE ZWNvZGUvTGVuZ3RoMSAxMTI2OD4+c3RyZWFtDQpIidxXCVRTZxZ+WSGJbE3QGYfqD0gVSMJLMCib GkLA50CCSYhIrWMSHiSajbzHVlQgKoJWS11wpaK2ooJ1KS7TM3Xw6LhQobhVdNxGxqnWpVp3AZ3/ wSho68w5c87MmTPvnf+8d+//3ft//3/vzX1BaAiCDEBKEQYyLlGLJV8sapkMNccRRCBQayOkc+9f d8H3K1CnN+WTIOxQ5zwE8R+NICxmtjPH9hA9lIsgg+Og7JNjLcqu0mW+QJAQiKetNOOGrD9tm4Ij SDj0h0SZocJHxChDkKEpUB5mtpGFBWnYGCg7EYTeZXWYDMOkw6QIMrwQ2rtthkInncGqg/YNEA/s BhvOKTCNRZARXRD/hdOFO2f7HID+g6wIwoA8EFrPTT0Rfjd8CpCei/8QdfPvsTlh5ePLH3vRPOi1 bv5VqLpEp9Ek3ugAtmfvDJ3FQtBpbG44m8akuUfRacxaDZqGCvtpAjYMKQ1A4npuNWJECMSBWBEc IeEYQ90oeN0f03dJ/fxrLdyupXHnkuufx8kP1bp9xqJuehMcoXQBv7LxxILrdYe+lh1Zs6iieWiz Vv8J6vWKK40JKZV9KhmKvstmpDO5/IF63GXRWnLsQOfKI0igwskCh2uGZBDqTwF4fO+XACHA7Cax RIiG9U4E91labDjQkgab02LPAVrclW8x4UDjcJCSkai0Fx2uUoMUTJ6ApWC6yUCuUCjTdMpEIRhh Co0eBV5fAx0yyCt6FCqTSNFRKLwyoRgtkUZK/iH+72+gbF3/M6exEEbZInjulfSyMuSUGNw1zxSK xGUBO9m76nh7/bwmnde253UciwzbdfoR5/2R929UPecMaPvzbzJ/3/L9o4qdNU3zQ27OyvAlphd+ k+vffTjjUWh9xtRqZrfI6JdRFtCcu+xMUEbEmeMC1tyor5ZtbUydcONObNA2/arZgWut5U0TkldM b9wUdaaLIzrVGL2GzoBJ/UZKMCCvGL+181hjTt4o7Sw+s+VBQ1EXq2t5fG7wlvARlz/i45XPhfNp H2euNjb71ZU+2LtfsPeEftUMT6Py8IbPz8tKWEGXXCJmOatuJmfgUoHi7uOBqd95LF7ja814zpWt aK5cd5npXBs2y7D4wHVe7urNR7KNCfHLlwVJVwZVLniW5Tns4clnMH9b4Iii+yNf+60+r7gd2JmU MbeyOamiKuSOYNr/XxI3SIajIb2Oh/xzGi93ynvrTv8tii/Ph/uz8/FDfagJD74nZidxlx0n0bKa n6X0QhiF+VRK1xtuN25bVJVcdaHRb6rlArfEWMWWtLS+qPgk6SwWs+zGafbYmm0bCjNvPe0yKdX7 eHb0xw1R9SLO5XuO4fVeE6exZOqSVp26ba8woZ3Xtmjf1Bd7Sts6qhtLgrAEX+uplTto+o0HvxWv i3lQsjlj09kg/NpH9YVr/3AuOcH8vmhW9246jfELCW2b1rnqd59ZvjxV7Aw3Bg9JBBO3B/sfIelP sZ+GD57SUJ4r8wx/9PGlK7urry+s+20HcXQ8p2bH+YXn/Zc0M65xQvTs71WfJX9+YlLS6dH6h4Et B9+LFYVIW9dc/eO45B/abcn515rQjT6lrSXtsbNrny4Pk4T7PzsquH1xx410uTNJJJyNujmb4PCp ZdBpdLpvUXa1fc6Otj20d+w1TY14bn/GdJjQhl849bdHKBKV9AY87FVGKBw2G+4yWQxWoHVkkwUG Fw7S8oxWC2HGXQRQyHtScjQ6UhKFoq9SkhKlkbJoWXQm6qZ98B8nIUlCE3uN4gsKCsT50JCAhmKT wxYBO7CDsJAOV1GEIk1LreFwOcXAWAQ0eLZYSOW1OEWXSOVylGQMGtfrR5ZoybGQcEEsESisBoIA kUAEUi0ml4OAFPp46A1WS5aBtDjsIF8q4aEcyp7Np6drJXzUjxI8+dxJBsIMS4902CW+qHfvUXho 8Cybw54lGYIGUBqGwL/PvQJydLh63L6c571lHh4weLOK3DQvBOo96W4aDWmsOvne5qy/3fQ/+MJW LFdznzrCclvFv9JukkZdOW3+i6wbe6e9ugv/VisA+5nHPnx4zGlbduv4l9vD0NXSjJl7tswIyVnV dLXgB9a1HzuqH2/j/XrTF3FznVefOKaoZzl8NMoF/mfxC7GA1RG/3roixpsXwr8d+A1YHP2hcQ7r WPDgLk1NQ01K9dk4VUa8u/gOR6bfbW5KUG6IlWzsbF/emX5EuHnjwVB164OldxlDi+/5x2x5sjVt DstmvLuQXzH6XEeAN3GAPe6rEQdvtizJPbI/e9d6XdB3vJyZT+YXVTZkc7dOfNbtCuwq/+Dwgwne tzIMwaltO2OyrvA/nXp0ni1l4PZ4D1jIG92si6ibda4nOu/ymXQUQXnUqw+TyaCzatGyCkqiMctK 0dmlvsXVfz2h6DavvD/6uD32J557vem/UEhuFr0RfhWigRQTJo32gjkIFaDUl1/fl91ABt2jFIHR hhAuk41C8uxxqJsZ1Q/DpUzdzGCoHlobWjrcTJJOIiYi4l8Uxno3Y1+Zm9GoM1sIYMJdpCXbYjKQ OLD0FAyVbDhBVY0Lz8ZduN2EC4HBngUsJAHyCAgjAEG6LCbSWsQl8ozTcRMJSIcQkGYc9B3CK79U vaS5DCaSaoiwNZG4DbeTYARkEsqFNAkKIBGjcJF8g8VqMFopJq9769sAMJAx3LdtNJZirRTZoBuI A3AFkQvPzcMJkhj3Os7h4kLoS+DrMRUCqSw6EobRADukPB+HilRHnp00QFZ6C14ghCEE0SPRkZHc dK0c4pxFLkuOmaSapCQ6OuoNdwDIrVagoRAE/CEiYE/Gs8RAodTo5JiKO0mu0chVOkypBYmYVpEi x1KViUCuSuzXh1OwVAy2YTGXQqswVXIM0I1XgnStEqiT4Cum7XGHJWEKuU4JoKjVaTCFLmUy0KYn TFAqdECnpky4eqUGg3+sVP3wmFoF0jRyhQ5TKKEddJCqVOkgbWoJTKtN/zvzVR4WxZHFX1V1z+Cg oiAeYLQVEVDDDh54oESO4ZBTRlBEXYZTFBjlCgiYcUQXUDk8E0QRzyUYhSQomihCVtQVV1eMa4ia iAouq34k8TZM5w0KuOzu9+1f+22/6Zmp6npV7/d7R1XjeoJT4DwPvwC0RdZlpLILgeDp4+/t+dZm xQL/AIVSKfSgQhJ8XbwDXfWz9PTK0G4fRYCLBza7UPoFCG6e83z16m7430nwd0IbXQK9nQIE/8AA fz+lYkLnIvM9vb0FX795MmdFJ0neik4FFz9fpWJuIBrv6eQ9AVV8Ped5Br3V6TLWD1EFCK5OPk7u CqWtoFQoZHqc+v1CP4erAkd5K5FpFzXmfjy6TB3VOxajYxKxLERGCPHqeH1YRcVERijfJIJTEmZG WDImkCwyFfU7gztFFZscKSQuVWEcxKuThLBIIVyNjyI6J1ElCqrw8OSENxkYpU6I68wZWcqb7QZH YKTqLfB0spXts9dM/m/SvKs/Vh2tto2OiZKvOaqvJAK35pBcI9dIDEPXe5D1LxRESgh2WEsMsKrw PFbQwcP/4/xIkjyseySVB8lNB/eqh3I8rBCzWV2dVomdzMb07MTdNUWIjVGF2QqxSZgL/3y6hM5L PvidSmfOGcglWO3w0+vcoz+pbfPemxbYlLRog2XdQaE9tvqLdLf03SWrTq6UeJgaRzYstnkx1yFn ZeWTQdNSm/KPGGrsCxZ77DgL02TKmtlTxVwTqzhwn/zcw9s24ef6xtUdrurR+X/dXHJ366NWES7U PU4Y/l0xiz9WG54+MdXVYfe63NdZ66da27YenDbV8eSvv2gt7LTcaKzBIxC6PPl/sH/8m8NgX4nB G1Ioz8OeNYflw7pZ6sPs3t1YODxj9LQM7XptO/KRPYqcnTE3gP9D4sQGn4rqi23PDsef63dM7v/O 8L52zvLZe4ZqBoMS0iAOwkANsSBAFP7GQ1LpGM1ofTS9Daa4rkNNZzQlJSRHJqWtiPxdryMNpyWw 8JzJuWWtu3JUP54c8aigQlZVbO74sNRpiFtUZH3e+bXHtYud83MfFlya9eOcdZ+vGnb0p+LD7FXw 6eK4u0lXmptcfoqwrkl96bdsy5DjPv0u3csN27T8swG7Ri+V/jBoWFrOmOBHVllhFsNSkyk3rcRr tlnN3xRBjta+Q6XvhVvFLxy37e+LXqXv+jJhRGbZoWfKgTuftmzUNuaU1I5aZdTcdjtmQeikIi96 2uPTj/dnr3/gcFvnt/Nqa9O55thx106FflW/9FqRlcr6fGaj6l5h0GXTWGPP0HskzjPR5JNdoSZ3 Dlg0rqpPF6pNVh0cKkJKTkNL4Z2LwXnN2pkX8g9l6y6eTL8/6cZ461ItuYKnuoYeX0jstOQUdp3Q B9ma6v/791dqCqcGFjW5PBr12m1BVs6f3bILLB8PCu0VqMHyoe/GqWF3Q0owTLuf8HZG+lcPOzm+ a8jtpkyavPBfwrStsKDftb2yytVbxOcm24y8egfVGo0ifXVcSNwU5/SU7+7fWPHSdKBXYfD1hsxa MdrPMfFpxs2oKdLlkYpB/c3hI/HVqaIym+KUlqo08cjMzO8XbXvyWJNYMrCsj1nmhgujsiauGVR7 +b6Q1dQ2MTsk7c4N0bxsa6GjNjfEcvOtfU/lxs6lq0f7ZfXx+PWk/U6Hrz9t9G3ZWJ6oL2qEu0QK gAfgi/hJ2LR888v2QBQ17st4nlAilVBeCr0uH3W8Gma3C+0iv1HnRiYZGJI6TfdTfjHY8d4wEu/h bCuYA4h33t73dMHiI345WOiWiTetjHDwl2/vN5cKLGEJ2MAcqIN2OE3GgT+cEa9AOCygH8L72J8P x+EM3AZXiAAKZiQDBLEYNsJYWAt7YDpnJlaBNzwwMILBMAZmEDVIwBSiYTe5CZ7ghXM4gDvkQAJ+ z8X+52QaPiEgg8W4+lbYCafhL/ADDMMZbeE6uv65+BW4YEUJh3Q4Abd5Z34DmEAhHIIyqIX7xJbs J23ssVglNoj/QC0bsAN7CMHqEwaboRTHHYKL1ILtE83EdPGP4nkYjtaXI+paOItrPSMCCSLh9CBL 070S48Vy5KEv2ozWozghGl9IggM48jq8Jn1QtFSgH9Bw3UBxCEhhJFa48WhfIFa81ZANmxBFEZTA UXhAPiBLySXymPajGlrD+0t9pb59ajq+Fd3FZ7hGXxiF1s6H5ZCKmpthC2xHzVJc608o7dBB7IkD cSSeJIDkk/XkAHlBx9Pv6WvWnxmxCSyYhbIM1sxeGvAdfroduiuiv5iKXBLkXIaedEGc82ARrIBE +BAyQIPW5aEUIHvlKBXIZw3KN3AL7qK0wAN4iDHHI0YZGYciR3Egs8kcEkh+T6JJItlBjpFqcpqc JW3kCZ1M7el06kcDaDRdQZNoAa2glbSG3qO/oJUzmIIlso9YOatj59lV1sQBN4dTcTFcMreVq+C+ 5dq5J5yOB94CxZZX8Xs69uq8dCHiWNFBDBM3iQUoD5DjEYhmLFghHn/0ajjuKNGIagWsRElD7tYh ou2wG7nTs3cMquFrjNI69G89XIEmxHcLmuE5vERy9PhMySjyPrFDfmcRd5SF6KcUkkE0JI8UIc+V pArlDLmJKHWIMIgG0yU0hWbQTXQH3UlP0DP0OnpCZBL0xFDmzrzYfBbClrAktp19zD5hu1kJq2Zn WD1HuRmcP5fAreUKuL3cUe4c18jd5OW8A5+LUsFX8af4FomxxFwyWaKUVEslBmkGrQY6+ALOQSVU 9c59kk0GkEr4jLQyjmloA11ADel1ouUuEyv0wEwCfB7utj+jhe+Rq3Qqmc/CyULkT0uiSAjsYsPZ XjYHGvh4omT+JAKU3A74lf8GVHwu/ZxRPpd1kJe0HJZCHl3eUSYGk/6gJPvpQYyYTJgJNpwZXKfT uRPEktrQGukRUg2OUgmbzmYYGGFrP7uLZioNjEgbqH5jvFqDm7iu8Ll3V9q15MdKfskWRisW2bHX wtiQ+KXaK0syBIHjF1Ti0Up+UJs+oEOg41ISUsYlFcGjTGboTNuZZjpMmppOe2VDR2Yo9b/+yi9m 2k7bHxBC2h+lyWQcd5pi1HPXsrFTptOVvnvOPY97zp57795d4X3cP/dxbw3Sd/CZ8CH5i/QSZrci /AptzkMXufbEAT+3xGmCbKHXyP6Viyt/FH6U+wmpou8DrDhWgjSEK+5gbpbegY/gB0/+Jd6DO/TP cBCfGqPmzvkE99638ElzCB7TItxPQ/gcOWV0d3d9IdDZ0d7W+vzuXS3NO5t2+Bv1hvrn6mp927Vt XtWztWaLu7rKVVlRXlbqdCglxUWFdluBLFktIr61QmNE602orDbBxFpt714/72tJFCQ3CBJMRVHv ZhumJkwzdbOlgZbHP2dprFoa65ZEUQMQ8DeqEU1l74U1NUsOD8SQvxLW4ip7ZPIHTF6sNTtF2PF6 0UONuCbCKiMJNcJ6z06kIokwjpex20JaaNzmb4SMzY6sHTlWqZ3KkMouYjK0MtKRoSAXYVasWgtH WJUW5ikwwRdJjrH+gVgk7PZ64/5GRkKj2ggDrYeV6KYJhMwwzBpikhlGneS3A5fVTONi6o2sAiMJ vXBMG0sejTEhGecxHDrGDbPKb3/getrFwZ2h2KWNWreQirgmVd5NpS6p7O2B2Eatl7fxOI6BvtTX m0j1Yug3sIrRIRWj0el4jJFpDKnyO+F3tXp/41qESxInVFag9WgTqRMJnJvqFIPBKe9cdbWxkLsH 1RE1NRzTvKzbrcWT4S2ZMkgNTs1XGWrVZo2/MaM4VgubKS7JM4VFG5nxdZ3Jmeaciw6uV5bwjLQX cUUwdVTFTGIa3lMbb8bbIDXahmZ4xQl6sTGckUlWEEqklA4u5/7M4lM0NfUp4ArQHv19sySZl1h9 yqfAWb5O1tca6td4puusoYEvESmEc4o5dpn95/2NZ7M0qJ1SVCRYPujH2ibjHU1Yfq+XT/DlrAEj 2GEXBmKrfRVG3HNgNOlxRhNcs7imKT/INRfWNOvuCQ1X8g08vwDKmVy7/i9RKkojEx2MVPwP9fiq PjqkRQcOx9RIKpGvbXR4U29V37auy3OsNBQT3DTPUbdganFRHl035p1YIRN9+Leai3osK8m4Kk0J UXuZkti72sZtXu//6ZTNfcy9TPLULZ8m69A39zs39TelV5gSMGGxlkaHD6dSto064EWT7U+6sD30 5PrjHfLLZhk3XnfE9/BU5ddngK92iFn4wHIDkiKATxyDAess7LG2w17hInSgbhjhR92bqPOh/Tfy 9E3ansuhfB/iY0QjYgihIkYQccR+xHcQA7QdfoG4jL4B7s+pcAVinLf8Dsosh2AbUqf4EKrFB1Bn dcNe8S5oKKvF+LsshdCHvM9yHsqkGu6T+xv291t9aPMPzOE01Iq3oQ19Oy3TUIG570Fdm6UeeqxH Md4DqMBxfmb9KzmBdJ8ljDLIfSSC8CccexjzmEL0CksQQd8XRR32CPvw/u6Cn/4UQkgjqC9HNIs/ xnvS4Tnkef6tyMeRTqJNH/rqqN+D9Qxirv3CJ3AEaROOe0T4A9wlP4RrSH+P9rvFZSgln5lxAwRn C31ewFqB1QoLVivZifSfiGX5ENRLDyGK4x9bo8IuOM5rhyf8ZL6mU+h/HOMEhV/CiXyNObbzWDLA h+Jd2i5D7greu2q9inN+HvxYmy9JD8l3sVZ9Jq5CEukBDhyvDdGK6Myjw3KD2BB21A9hf591EEY5 JA+0oO8OjDXM1wbqdmKeJvL578/nb1LMswnrGlzzt+6DBvTRBScMbQCsYwnfN5bwO8ek5Br6nEH/ LtqM30Hn6TurgJDgzL0lOOmxVQoa8q+ZFH3JNdgSLAcnrcNfLa2Fk6QCd8eXzfYls+022ybe0qa5 Jo8nS3fMvc1J41xNPZLthv1+tae5zukJ1PF+pdH5tXrPvdkqz33E9boWz+uBFs9FRBPiLPa5Xd1s vedk3cmvn/zeyUtiK1RU4Cw7HbKRJQ9+fbCsoKygNZ0lvzXapfRvpPS8lP6KlB6T0l+U0r1S+gUp vUNK61LaJ6W3S2WyU1bkYrlQtsmybJVFmcogl2Vz9wydb/4yq8KJVeStaPIK5S3f6PgkoESm+HXH SoUojQ71sDY9mpVyg6xVjzKp/0gsQ8hMHKWMvp4lMBzLkhwXTbv5qb0AhOSmr7jzNB4nUbY4CtER lS0PaVliwweVReshzBmF6HCPCyrOdru6nV2O9t7wM5pEvtWfXi594xXtn7oNHnKGf3yRl+clz1sS lw6hNG1K01yaNqWuGnY1OhRjszVx1sKZXE2czAdvGuf4e0BCi4wjEuzy2QkXuzCiqhnjZv4FoTYx MjrBaXKc3dTGw8zQwmomeO4Z6nNcHdTCGTgXGY5lzhnj4bmgEYxoyXB8AfrISKZhZlO476+FW4AG MvLfI2bJCB+ygUfsm3lGxBmu7uMRZ3jEGR6xz+gzI0Ymh3pItD+WkaEnjoePSeep3YZTlXB74z0V yqkuc946va5X3LdEIO+CHc/iQnyvK0JwlT/oD3IVLhiuKuavfHmV65VOr/sWeTevUlDs0HpAP6N/ 7jrNL3BFJsMcmMlCbpFemHN6WvQ4P2coP4Lw6w+3MU5ap7HVKo2izCKOCmCzWkYFgVYXSOIogSq5 vs2l9ylLgQMrgT5lOXBAWQlAd2AlwNG80+vwOnzY4NqGx6qw+NiwwL/xxFnEkSF3H7+zvgp2qAQN rs+3yu7q2/RVKKFuKKBbDEWocdVsbdJe1aihndKolqWn51TVewttyql7TrBDlrqN4sJbNTHV7XXX VMdct5woummt2u7tNtM6sLK89CigBJaWH0H3ynJAWTr2TUxMWUG+eWdoymgglYrs1KHYVqiTMhG5 CoqcQyrRSZEdm1JLuQ6VBBteOcKb14gCXhUcZivsBm0b/IfdqgltIojCb7ZJiRaMEXu0zvrTS0na pqdQkZYu1IoLJdm7nU13k8A0G3a3hVyspx486D1QGhCEiifPHjz24FFEVJSeBMGbniRTv9msOdpD D17cx8z73jffmzfLvmR38jItlImZhYWCOWkWrhfM7CO1oT6qD0qwAzbNbrK+q3pqoHrMHyjm/3rC PrnsizJddcN4BuEG60M0zQ6UUO8HzFe9gdJiVmTH6qpQ19hnPJTyfxvZm39g+jpPD0bfaLvDf2nS v5Q8oiHOAD9O8Tjwvu72zDlEil6kmNEUe55igy6woxSPgX+X4gzwjxSP05Rxyel2PF/UPX7InabH 7aAdxKD4ShB2glDEraDNO7Je4paIxSmiWb0ZrwVyWzMRX2sjb75SmStiKpf4spS82mo044hXvcgL d7zNu+urtmXN1LpbbiBt5+8hOdSlDnnkk6A6PKdDDIeaCbYpoDZGnKo4rSAKgfUswLcSBQcjkV8C shJenHGn2dHJONWwIml7pInArcEP681TBTZHxRSVE3YZGRK+ipwGzhAnWVXsF2GEtIN5E+/sdVrF 2SzYDOp0aYvcpJqN+lrdQF2J84WnaM+yOuzO16iVTbrRoIu4/yWg79l8wuh14yF92zvq38/f+pm7 kkvop3deLWr/8t7b45MTdTv3NTeBcOJP5/8WYADJHY2ECg0KZW5kc3RyZWFtDWVuZG9iag01IDAg b2JqPDwvU3RlbVYgMC9Gb250TmFtZS9KUEdNREQrU3ltYm9sTVQvRm9udFN0cmV0Y2gvTm9ybWFs L0ZvbnRGaWxlMiA0IDAgUi9Gb250V2VpZ2h0IDQwMC9GbGFncyA0L0Rlc2NlbnQgLTIxOS9Gb250 QkJveFswIC0yMjAgMTExMyAxMDA1XS9Bc2NlbnQgMTAwNS9Gb250RmFtaWx5KFN5bWJvbCkvQ2Fw SGVpZ2h0IDAvVHlwZS9Gb250RGVzY3JpcHRvci9JdGFsaWNBbmdsZSAwPj4NZW5kb2JqDTYgMCBv Ymo8PC9TdWJ0eXBlL0NJREZvbnRUeXBlMi9Gb250RGVzY3JpcHRvciA1IDAgUi9CYXNlRm9udC9K UEdNREQrU3ltYm9sTVQvV1sxMzRbNzY4XV0vQ0lEU3lzdGVtSW5mbzw8L1N1cHBsZW1lbnQgMC9P cmRlcmluZyhJZGVudGl0eSkvUmVnaXN0cnkoQWRvYmUpPj4vRFcgMTAwMC9UeXBlL0ZvbnQ+Pg1l bmRvYmoNNyAwIG9iajw8L0xlbmd0aCAyMTkvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJ VFA9T8QwDN3zKzxyYkgv4hBIVZdj6cCHaGHPJW6JdHUiNx3670mi9hCDbfnZT+/Z8ty+tOQiyA/2 psMIgyPLOPuFDcIFR0dwVGCdiVtXspl0AJnI3TpHnFoaPNS1kJ9pOEde4a7vT/fVAeQ7W2RHY0Ie 1Nd3QrolhCtOSBEqaBqwOAh5ftXhTU8IshD/wH4NCKr0x03bW5yDNsiaRoS6qp4em70g2f/znXUZ zI9msW8r9XxqRNre8MzLN918mIU5WSyHFyPZgiO8/Sb4kNVyiF8BBgDpX2qZCg0KZW5kc3RyZWFt DWVuZG9iag04IDAgb2JqPDwvQ3JvcEJveFswIDAgNTk1LjIyIDg0Ml0vUGFyZW50IDE2IDAgUi9D b250ZW50cyAxMCAwIFIvUm90YXRlIDAvTWVkaWFCb3hbMCAwIDU5NS4yMiA4NDJdL1Jlc291cmNl cyA5IDAgUi9UeXBlL1BhZ2U+Pg1lbmRvYmoNOSAwIG9iajw8L0NvbG9yU3BhY2U8PC9DczYgMTIg MCBSPj4vRm9udDw8L1RUMiAyMyAwIFIvVFQ0IDI0IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0XS9F eHRHU3RhdGU8PC9HUzEgMjcgMCBSPj4+Pg1lbmRvYmoNMTAgMCBvYmo8PC9MZW5ndGggNDc2L0Zp bHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiYxSW2+bMBR+51cc9Qmk5GAbzGXSHrJbtkndQ+Kn Nn1wiSGsqYkwrFp/fY0hJNI0qULGRpzvcj6fcL2lUBnvk/BCIRhQEKVHGRD72C3Oc8wgypDFJALx 7BGo7BLF8HrxfAjEb48SzLMR4U4sjzGHKEeSjSA/cmUza04g5RnmycSJhJBkIF2ej5Z6dTTNAuoO CqnhUUHR6K7WvdpD2bTQHRT0p5NqoW16vTfQlCCkro4Kdr7CCl3V5mNG7Pf4Y8l4sgt2AYJzTWBJ kXIQX/5pyCYRj0mMRYkrGqzxi0vu6iOEjSpVq3ShDJzR7BodD2iHsa3PQver2zuSPYyIzyaBwgBB GqWMDzujPHU7j3MwhfZijKwkmZ3Ejsp6y11c9/5GllIdYXX8I1v1GjyIn+6yEmQT6qK9eLcqwSS9 EuWzKB9F17L9C7fFuq9bBVLvYaW7RtcN3MnnIMPIbwKC3G/l7Ifygf7aEtJ0cnXzXlvUjtb/s/CF HY5pGL5Lc3DdLlmKUXZ15wMwvWTyrddFVzf6ZjEOR2UTZ1N0y3Px0DJs+8ehN+7XxlgAdA38+rEV C2CEZAiHrjt9CEN1sMpYy/oJu75q5SvKLnypn+pwdIbgIvkqvDcBBgB9itnCCg0KZW5kc3RyZWFt DWVuZG9iag0xMSAwIG9iajw8L1N1YnR5cGUvVHlwZTAvRGVzY2VuZGFudEZvbnRzWzYgMCBSXS9C YXNlRm9udC9KUEdNREQrU3ltYm9sTVQvVG9Vbmljb2RlIDcgMCBSL0VuY29kaW5nL0lkZW50aXR5 LUgvVHlwZS9Gb250Pj4NZW5kb2JqDTEyIDAgb2JqWy9JQ0NCYXNlZCAxMyAwIFJdDWVuZG9iag0x MyAwIG9iajw8L0xlbmd0aCAyNTc1L0ZpbHRlci9GbGF0ZURlY29kZS9OIDMvQWx0ZXJuYXRlL0Rl dmljZVJHQj4+c3RyZWFtDQpIiZyWeVRTdxbHf2/JnpCVsMNjDVuAsAaQNWxhkR0EUQhJCAESQkjY BUFEBRRFRISqlTLWbXRGT0WdLq5jrQ7WferSA/Uw6ug4tBbXjp0XOEedTmem0+8f7/c593fv793f vfed8wCgJ6WqtdUwCwCN1qDPSozFFhUUYqQJAAMKIAIRADJ5rS4tOyEH4JLGS7Ba3An8i55eB5Bp vSJMysAw8P+JLdfpDQBAGTgHKJS1cpw7ca6qN+hM9hmceaWVJoZRE+vxBHG2NLFqnr3nfOY52sQK jVaBsylnnUKjMPFpnFfXGZU4I6k4d9WplfU4X8XZpcqoUeP83BSrUcpqAUDpJrtBKS/H2Q9nuj4n S4LzAgDIdNU7XPoOG5QNBtOlJNW6Rr1aVW7A3OUemCg0VIwlKeurlAaDMEMmr5TpFZikWqOTaRsB mL/znDim2mJ4kYNFocHBQn8f0TuF+q+bv1Cm3s7Tk8y5nkH8C29tP+dXPQqAeBavzfq3ttItAIyv BMDy5luby/sAMPG+Hb74zn34pnkpNxh0Yb6+9fX1Pmql3MdU0Df6nw6/QO+8z8d03JvyYHHKMpmx yoCZ6iavrqo26rFanUyuxIQ/HeJfHfjzeXhnKcuUeqUWj8jDp0ytVeHt1irUBnW1FlNr/1MTf2XY TzQ/17i4Y68Br9gHsC7yAPK3CwDl0gBStA3fgd70LZWSBzLwNd/h3vzczwn691PhPtOjVq2ai5Nk 5WByo75ufs/0WQICoAIm4AErYA+cgTsQAn8QAsJBNIgHySAd5IACsBTIQTnQAD2oBy2gHXSBHrAe bALDYDsYA7vBfnAQjIOPwQnwR3AefAmugVtgEkyDh2AGPAWvIAgiQQyIC1lBDpAr5AX5Q2IoEoqH UqEsqAAqgVSQFjJCLdAKqAfqh4ahHdBu6PfQUegEdA66BH0FTUEPoO+glzAC02EebAe7wb6wGI6B U+AceAmsgmvgJrgTXgcPwaPwPvgwfAI+D1+DJ+GH8CwCEBrCRxwRISJGJEg6UoiUIXqkFelGBpFR ZD9yDDmLXEEmkUfIC5SIclEMFaLhaBKai8rRGrQV7UWH0V3oYfQ0egWdQmfQ1wQGwZbgRQgjSAmL CCpCPaGLMEjYSfiIcIZwjTBNeEokEvlEATGEmEQsIFYQm4m9xK3EA8TjxEvEu8RZEolkRfIiRZDS STKSgdRF2kLaR/qMdJk0TXpOppEdyP7kBHIhWUvuIA+S95A/JV8m3yO/orAorpQwSjpFQWmk9FHG KMcoFynTlFdUNlVAjaDmUCuo7dQh6n7qGept6hMajeZEC6Vl0tS05bQh2u9on9OmaC/oHLonXUIv ohvp6+gf0o/Tv6I/YTAYboxoRiHDwFjH2M04xfia8dyMa+ZjJjVTmLWZjZgdNrts9phJYboyY5hL mU3MQeYh5kXmIxaF5caSsGSsVtYI6yjrBmuWzWWL2OlsDbuXvYd9jn2fQ+K4ceI5Ck4n5wPOKc5d LsJ15kq4cu4K7hj3DHeaR+QJeFJeBa+H91veBG/GnGMeaJ5n3mA+Yv6J+SQf4bvxpfwqfh//IP86 /6WFnUWMhdJijcV+i8sWzyxtLKMtlZbdlgcsr1m+tMKs4q0qrTZYjVvdsUatPa0zreutt1mfsX5k w7MJt5HbdNsctLlpC9t62mbZNtt+YHvBdtbO3i7RTme3xe6U3SN7vn20fYX9gP2n9g8cuA6RDmqH AYfPHP6KmWMxWBU2hJ3GZhxtHZMcjY47HCccXzkJnHKdOpwOON1xpjqLncucB5xPOs+4OLikubS4 7HW56UpxFbuWu252Pev6zE3glu+2ym3c7b7AUiAVNAn2Cm67M9yj3GvcR92vehA9xB6VHls9vvSE PYM8yz1HPC96wV7BXmqvrV6XvAneod5a71HvG0K6MEZYJ9wrnPLh+6T6dPiM+zz2dfEt9N3ge9b3 tV+QX5XfmN8tEUeULOoQHRN95+/pL/cf8b8awAhICGgLOBLwbaBXoDJwW+Cfg7hBaUGrgk4G/SM4 JFgfvD/4QYhLSEnIeyE3xDxxhrhX/HkoITQ2tC3049AXYcFhhrCDYX8PF4ZXhu8Jv79AsEC5YGzB 3QinCFnEjojJSCyyJPL9yMkoxyhZ1GjUN9HO0YrondH3YjxiKmL2xTyO9YvVx34U+0wSJlkmOR6H xCXGdcdNxHPic+OH479OcEpQJexNmEkMSmxOPJ5ESEpJ2pB0Q2onlUt3S2eSQ5KXJZ9Ooadkpwyn fJPqmapPPZYGpyWnbUy7vdB1oXbheDpIl6ZvTL+TIcioyfhDJjEzI3Mk8y9ZoqyWrLPZ3Ozi7D3Z T3Nic/pybuW65xpzT+Yx84ryduc9y4/L78+fXOS7aNmi8wXWBeqCI4WkwrzCnYWzi+MXb1o8XRRU 1FV0fYlgScOSc0utl1Yt/aSYWSwrPlRCKMkv2VPygyxdNiqbLZWWvlc6I5fIN8sfKqIVA4oHyghl v/JeWURZf9l9VYRqo+pBeVT5YPkjtUQ9rP62Iqlie8WzyvTKDyt/rMqvOqAha0o0R7UcbaX2dLV9 dUP1JZ2Xrks3WRNWs6lmRp+i31kL1S6pPWLg4T9TF4zuxpXGqbrIupG65/V59Yca2A3ahguNno1r Gu81JTT9phltljefbHFsaW+ZWhazbEcr1FraerLNua2zbXp54vJd7dT2yvY/dfh19Hd8vyJ/xbFO u87lnXdXJq7c22XWpe+6sSp81fbV6Gr16ok1AWu2rHndrej+osevZ7Dnh1557xdrRWuH1v64rmzd RF9w37b1xPXa9dc3RG3Y1c/ub+q/uzFt4+EBbKB74PtNxZvODQYObt9M3WzcPDmU+k8ApAFb/pi4 mSSZkJn8mmia1ZtCm6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMel OKWpphqmi6b9p26n4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHW skuywrM4s660JbSctRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/ er/1wHDA7MFnwePCX8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01 zbXONs62zzfPuNA50LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724Dc BdyK3RDdlt4c3qLfKd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl 63Dr++yG7RHtnO4o7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf6 5/t3/Af8mP0p/br+S/7c/23//wIMAPeE8/sKDQplbmRzdHJlYW0NZW5kb2JqDTE0IDAgb2JqPDwv TnVtc1swIDE1IDAgUl0+Pg1lbmRvYmoNMTUgMCBvYmo8PC9TL0Q+Pg1lbmRvYmoNMTYgMCBvYmo8 PC9Db3VudCAzL1R5cGUvUGFnZXMvS2lkc1syMSAwIFIgMSAwIFIgOCAwIFJdPj4NZW5kb2JqDTE3 IDAgb2JqPDwvU3VidHlwZS9YTUwvTGVuZ3RoIDM1NTEvVHlwZS9NZXRhZGF0YT4+c3RyZWFtDQo8 P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/Pgo8eDp4 bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSIzLjEtNzAxIj4KICAgPHJk ZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgt bnMjIj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1s bnM6cGRmPSJodHRwOi8vbnMuYWRvYmUuY29tL3BkZi8xLjMvIj4KICAgICAgICAgPHBkZjpQcm9k dWNlcj5BY3JvYmF0IERpc3RpbGxlciA3LjAgKFdpbmRvd3MpPC9wZGY6UHJvZHVjZXI+CiAgICAg IDwvcmRmOkRlc2NyaXB0aW9uPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgog ICAgICAgICAgICB4bWxuczp4YXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iPgogICAg ICAgICA8eGFwOkNyZWF0ZURhdGU+MjAwOC0xMi0xNlQxMDowOTo1NiswMzozMDwveGFwOkNyZWF0 ZURhdGU+CiAgICAgICAgIDx4YXA6Q3JlYXRvclRvb2w+UFNjcmlwdDUuZGxsIFZlcnNpb24gNS4y LjI8L3hhcDpDcmVhdG9yVG9vbD4KICAgICAgICAgPHhhcDpNb2RpZnlEYXRlPjIwMDgtMTItMTZU MTA6MDk6NTYrMDM6MzA8L3hhcDpNb2RpZnlEYXRlPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4K ICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6ZGM9 Imh0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIj4KICAgICAgICAgPGRjOmZvcm1hdD5h cHBsaWNhdGlvbi9wZGY8L2RjOmZvcm1hdD4KICAgICAgICAgPGRjOmNyZWF0b3I+CiAgICAgICAg ICAgIDxyZGY6U2VxPgogICAgICAgICAgICAgICA8cmRmOmxpPmVzbWFlZWxpPC9yZGY6bGk+CiAg ICAgICAgICAgIDwvcmRmOlNlcT4KICAgICAgICAgPC9kYzpjcmVhdG9yPgogICAgICAgICA8ZGM6 dGl0bGU+CiAgICAgICAgICAgIDxyZGY6QWx0PgogICAgICAgICAgICAgICA8cmRmOmxpIHhtbDps YW5nPSJ4LWRlZmF1bHQiPk1pY3Jvc29mdCBXb3JkIC0gVGFuZ2xlX09ic2VydmF0aW9uLmRvYzwv cmRmOmxpPgogICAgICAgICAgICA8L3JkZjpBbHQ+CiAgICAgICAgIDwvZGM6dGl0bGU+CiAgICAg IDwvcmRmOkRlc2NyaXB0aW9uPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgog ICAgICAgICAgICB4bWxuczp4YXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyI+ CiAgICAgICAgIDx4YXBNTTpEb2N1bWVudElEPnV1aWQ6ZWM4ZTc1ZDQtZTE3YS00ZWI3LThmZTYt MjEwMTA5NjBmNTljPC94YXBNTTpEb2N1bWVudElEPgogICAgICAgICA8eGFwTU06SW5zdGFuY2VJ RD51dWlkOmUyYjE2ODZmLWUyNmEtNDlmZi05MmFhLTJiMmQ2YjZjYjE5NTwveGFwTU06SW5zdGFu Y2VJRD4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgIDwvcmRmOlJERj4KPC94OnhtcG1ldGE+ CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAKPD94 cGFja2V0IGVuZD0idyI/Pg0KZW5kc3RyZWFtDWVuZG9iag0xOCAwIG9iajw8L0NyZWF0aW9uRGF0 ZShEOjIwMDgxMjE2MTAwOTU2KzAzJzMwJykvQXV0aG9yKGVzbWFlZWxpKS9DcmVhdG9yKFBTY3Jp cHQ1LmRsbCBWZXJzaW9uIDUuMi4yKS9Qcm9kdWNlcihBY3JvYmF0IERpc3RpbGxlciA3LjAgXChX aW5kb3dzXCkpL01vZERhdGUoRDoyMDA4MTIxNjEwMDk1NiswMyczMCcpL1RpdGxlKE1pY3Jvc29m dCBXb3JkIC0gVGFuZ2xlX09ic2VydmF0aW9uLmRvYyk+Pg1lbmRvYmoNeHJlZg0KMCAxOQ0KMDAw MDAwMDAwMCA2NTUzNSBmDQowMDAwMDY2MTExIDAwMDAwIG4NCjAwMDAwNjYyNDMgMDAwMDAgbg0K MDAwMDA2NjM4NSAwMDAwMCBuDQowMDAwMDcyNjQwIDAwMDAwIG4NCjAwMDAwNzk5MTAgMDAwMDAg bg0KMDAwMDA4MDEzNyAwMDAwMCBuDQowMDAwMDgwMzE5IDAwMDAwIG4NCjAwMDAwODA2MDYgMDAw MDAgbg0KMDAwMDA4MDczOSAwMDAwMCBuDQowMDAwMDgwODU5IDAwMDAwIG4NCjAwMDAwODE0MDQg MDAwMDAgbg0KMDAwMDA4MTUzMiAwMDAwMCBuDQowMDAwMDgxNTY2IDAwMDAwIG4NCjAwMDAwODQy MzUgMDAwMDAgbg0KMDAwMDA4NDI3MCAwMDAwMCBuDQowMDAwMDg0Mjk0IDAwMDAwIG4NCjAwMDAw ODQzNTggMDAwMDAgbg0KMDAwMDA4Nzk4NiAwMDAwMCBuDQp0cmFpbGVyDQo8PC9TaXplIDE5Pj4N CnN0YXJ0eHJlZg0KMTE2DQolJUVPRg0K --_03008e4c-c9c1-449e-9e5b-fa660d708205_-- From hash-forum@nist.gov Tue Dec 16 08:27:21 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBGGRFIT010691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 16 Dec 2008 08:27:17 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBGGQUJd031900; Tue, 16 Dec 2008 11:26:33 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBGGQ4E4032191; Tue, 16 Dec 2008 11:26:04 -0500 Date: Tue, 16 Dec 2008 11:26:04 -0500 Message-Id: <4947D371.2030600@dccia.ua.es> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: =?ISO-8859-1?Q?Rafael_=C1lvarez?= To: Multiple recipients of list Subject: Re: OFFICIAL COMMENT: Tangle X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed In-Reply-To: <4947BD79.5010001@win.dtu.dk> References: <4947BD79.5010001@win.dtu.dk> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 16 Dec 2008 08:27:17 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 388 Hi, I just wanted to add that Søren was kind enough to contact me before posting. Best regards, Rafael Alvarez. Søren Steffen Thomsen wrote: > Hi, > I have found practical collisions in Tangle-n for all supported digest > sizes n. > > As an example, the following is a collision in Tangle-256 (messages are > written byte-by-byte, without padding): > Message 1: > c8190000000000000000000000000000000000000000000000000000000000000000000000000000 > Hash of message 1: > f710be651ab67737a58ac452056bbf13e62abed071943617dadbf25c2dea710b > Message 2: > c8190080000000800000000000000000000000000000000000000000000000000000008000000080 > Hash of message 2: > f710be651ab67737a58ac452056bbf13e62abed071943617dadbf25c2dea710b > XOR of hashes: > 0000000000000000000000000000000000000000000000000000000000000000 > > A description of the attack can be downloaded from > http://www.mat.dtu.dk/people/S.Thomsen/tangle/tangle-coll.pdf. > > Best regards, > Søren Thomsen. > > From hash-forum@nist.gov Tue Dec 16 08:27:32 2008 Return-Path: Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBGGRM11010726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 16 Dec 2008 08:27:25 -0800 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBGGQUJf031900; Tue, 16 Dec 2008 11:26:34 -0500 Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBGGQM53000738; Tue, 16 Dec 2008 11:26:22 -0500 Date: Tue, 16 Dec 2008 11:26:22 -0500 Message-Id: <4947D414.9020302@nist.gov> Errors-To: sara@nist.gov Reply-To: hash-forum@nist.gov Originator: hash-forum@nist.gov Sender: hash-forum@nist.gov Precedence: bulk From: Bill Burr To: Multiple recipients of list Subject: Re: How will NIST handle the tunable security parameter? X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: multipart/alternative; boundary="------------070105090803010209010600" In-Reply-To: <20081216075000.75654.qmail@cr.yp.to> References: <20081216075000.75654.qmail@cr.yp.to> MIME-Version: 1.0 X-To: hash-forum@nist.gov X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: hash-forum@nist.gov X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 16 Dec 2008 08:27:27 -0800 (PST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters X-Virus-Status: Clean X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu Status: RO X-Status: X-Keywords: NonJunk X-UID: 389 This is a multi-part message in MIME format. --------------070105090803010209010600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dan, My comments are in-line below. D. J. Bernstein wrote: > Bill Burr writes: > >> Maybe a few submissions are just so slow that can tell that we just >> couldn't live with them. >> > > MD6-512, with the full 168 rounds recommended in the MD6 submission, > runs at a whopping 52 cycles/byte on the 64-bit reference platform, > vastly slower than SHA-512. > > Suppose that this cost turns out to be above your tolerance level. It's > easy to imagine how this could happen: you said that NIST expects > "significantly improved efficiency" compared to SHA-2; maybe you'll > accept Niels's argument that parallelizability doesn't adequately > compensate for poor single-core performance; or maybe you'll have some > other reason for deciding that MD6-512-168 is too slow. > > Yes or no: Will you then throw away the _entire_ MD6 submission? > I don't think I should respond to this sort of question at this point, it's too soon. Arguably the parallelizability of MD6 does give an advantage over SHA2. We haven't (yet) accepted Niel's argument about parallelizability. We may or we may not. At any rate MD6 was not at all the algorithm I had in mind when I made that remark; I think that MD6 is far from the slowest submission. > In the submission requirements you said that submissions were allowed to > have a tunable security parameter to "allow the selection of a range of > possible security/performance tradeoffs." The MD6 submission does this, > offering a wide range of security/performance tradeoffs. The 168 rounds > recommended for MD6-512 are almost _ten times as many rounds_ as have > been broken---after tons of cryptanalysis, probably more than any of the > other candidates so far. If you decide to throw away MD6 on the basis of > the performance of the recommended number of rounds, are you going to > throw away all of the reduced-round variants too, ignoring their speed? > There are obviously arguments both ways. RC6 had a rather low margin and we didn't pick it to be the AES - the biggest reason was probably the multiply instruction, its performance on low end processors, and the obvious side channel problems, rather than the security margin. On the other hand it turns out that multiply instructions aren't the only way to get timing side channels, so we aren't quite perfect:-) Now Ron is back with something that has a bigger margin. Moreover, Stefan makes a reasonable argument that: "The particular choice of defaults for the security parameters reflects the designers' confidence into their creations. How could the general public gain confidence into a version of a hash function, if the designers of that hash function don't have that confidence?" With the AES we followed logic something like that. We're not committing to follow the same logic this time around. Nor are we committing to follow different logic. In addition to giving NIST something to (possibly) play with to tune the selected strength/speed trade off of the candidates, it gives analysts a straightforward way to create versions of candidates that they can attack. It may turn out that we pick the final winner more than anything on performance grounds. As I think I've said already, this kind of cryptography is much easier, and not very interesting, if performance is no issue. But we're not going to make our second round selections mainly on the basis of early performance data, with no consideration for security margins. That's as far as I'll go at this point. > If NIST had set clear performance requirements at the beginning then > the MD6 designers could, and obviously would, have limited their round > counts accordingly. Instead NIST allowed, and even seemed to encourage, > more flexibility; MD6 supports a wide range of security/performance > tradeoffs, including much more conservative possibilities than (e.g.) > Skein. Is NIST going to retroactively punish MD6 for this flexibility? > > >> we're still looking for a pretty efficient trade-off >> of memory, cycles and gates >> > > Naturally. If the most efficient unbroken member of the MD6 family is > still too slow (or too big) for many users, while another unbroken hash > function meets those users' performance requirements, then MD6 probably > isn't the best choice for a standard. > > But maybe the situation is exactly reversed! Maybe MD6 offers the best > security/performance tradeoff out of all the submissions. Maybe 24-round > MD6, running at a quite reasonable 7 cycles/byte, will remain untouched > while every other fast hash function is broken. I think that there's a > noticeable risk that ignoring reduced-round MD6 means ignoring the best > submitted SHA-3 candidate---and a quite large risk that ignoring _all_ > of the reduced-round candidates, as Niels is doing, means ignoring the > best submitted SHA-3 candidate. I hope that NIST isn't so sloppy. > > Neils probably observed that the winner in the AES competition was tuned more for performance than a large security margin, and had one trick, changing the number of rounds with the key size, that none of the other finalists incorporated. Neils has a dog in this fight, and may have an interest in presenting the data in a way that favors Skein. You're prodigiously productive, and are collecting performance data, please feel free to present your own data normalized as you think it should be, and I promise you we'll give the same attention to it that we give to Neil's table. >> In fact I'll go so far as to say that until we get to the final round, >> we won't be particularly confident that we know about how many rounds >> people are going to be able to analyze. That makes it a bit hard to >> normalize performance by some notion of safety margin. >> > > I'm not talking about any sort of abstract normalization. Real-world > Core 2 benchmarks will show that (for example) 24-round MD6 runs at > about the same speed as Skein. The question is whether NIST is going to > use Rivest's conservative recommendation of 168-round MD6 as an excuse > to disregard 24-round MD6. > > I agree that comparing nonzero confidence levels isn't easy. This is > true whether we're talking about 24-round MD6, Skein, 168-round MD6, > or something else. > > >> When Larry ran CubeHash he said, "boy that's a slow one." >> > > There are two big problems here: > > * Larry is benchmarking only the most conservative function, namely > CubeHash8/1, and completely ignoring the implementations of > CubeHash8/2, CubeHash8/4, etc. that were also included in the > submission. > > * Larry is benchmarking code that was forced to be written in an > extremely conservative way to avoid the risk of compilation > failures---NIST is using an unpublished test framework on a > proprietary platform, making tests difficult for everyone else. > > Since CubeHash offers an extremely wide range of security/performance > tradeoffs, and can benefit tremendously in speed from widely available > vector instructions, both of these problems are quite severe; it's > hardly a surprise that Larry hasn't seen how fast CubeHash can be. > I know that - but I think it's also fair to point out that Larry's platform is pretty representative of what a great deal of the commercial world uses today, even if you want to label it "proprietary." In any comparison of Skein, MD6 and CubeHash at the moment seems to me to be that all 3, if I remember correctly (and these things run together a bit in my mind at this point) rely on a simple core set of operations for their security, but are embedded in somewhat different structures. And its those operations and the larger structures where the interest lies at the moment, not the speed of the default version. For example, if we decide that a large block cipher is an easy structure to test, and maybe something we need anyhow, then that would be an advantage for Skein. I have a gut feeling that we may well find out that the speed of the three isn't really very different. But Neils can present the data his way, and you can do it yours, and Ron is capable of making his own case very effectively. And we'll do our best to pay attention to all of you. Neils has put a lot of data together and that is useful. You can play the same game and so can Ron, if you wish. > ---D. J. Bernstein > Research Professor, Computer Science, University of Illinois at Chicago > > -- William E. Burr Manager, Security Technology Group NIST 100 Bureau Dr., MS 8931 Gaithersburg, MD. 20899 Bldg. 222, Rm B362 Tel: 301-975-2914 Fax: 301-975-8670 --------------070105090803010209010600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dan,

My comments are in-line below.

D. J. Bernstein wrote: 
Bill Burr writes:
  
Maybe a few submissions are just so slow that can tell that we just
couldn't live with them.
    

MD6-512, with the full 168 rounds recommended in the MD6 submission,
runs at a whopping 52 cycles/byte on the 64-bit reference platform,
vastly slower than SHA-512.

Suppose that this cost turns out to be above your tolerance level. It's
easy to imagine how this could happen: you said that NIST expects
"significantly improved efficiency" compared to SHA-2; maybe you'll
accept Niels's argument that parallelizability doesn't adequately
compensate for poor single-core performance; or maybe you'll have some
other reason for deciding that MD6-512-168 is too slow.

Yes or no: Will you then throw away the _entire_ MD6 submission?
I don't think I should respond to this sort of question at this point, it's too soon.  Arguably the parallelizability of MD6 does give an advantage over SHA2.  We haven't (yet) accepted Niel's argument about parallelizability.  We may or we may not.  At any rate MD6 was not at all the algorithm I had in mind when I made that remark; I think that MD6 is far from the slowest submission.
In the submission requirements you said that submissions were allowed to
have a tunable security parameter to "allow the selection of a range of
possible security/performance tradeoffs." The MD6 submission does this,
offering a wide range of security/performance tradeoffs. The 168 rounds
recommended for MD6-512 are almost _ten times as many rounds_ as have
been broken---after tons of cryptanalysis, probably more than any of the
other candidates so far. If you decide to throw away MD6 on the basis of
the performance of the recommended number of rounds, are you going to
throw away all of the reduced-round variants too, ignoring their speed?
There are obviously arguments both ways.  RC6 had a rather low margin and we didn't pick it to be the AES - the biggest reason was probably the multiply instruction, its performance on low end processors, and the obvious side channel problems, rather than the security margin.  On the other hand it turns out that multiply instructions aren't the only way to get timing side channels, so we aren't quite perfect:-)  Now Ron is back with something that has a bigger margin.  Moreover, Stefan makes a reasonable argument that:

"The particular choice of defaults for the security parameters reflects the designers' confidence into their creations. How could the general public gain confidence into a version of a hash function, if the designers of that hash function don't have that confidence?"

With the AES we followed logic something like that.  We're not committing to follow the same logic this time around.  Nor are we committing to follow different logic. In addition to giving NIST something to (possibly) play with to tune the selected strength/speed trade off of the candidates, it gives analysts a straightforward way to create versions of candidates that they can attack.

It may turn out that we pick the final winner more than anything on performance grounds.  As I think I've said already, this kind of cryptography is much easier, and not very interesting, if performance is no issue.  But we're not going to make our second round selections mainly on the basis of early performance data, with no consideration for security margins.  That's as far as I'll go at this point.
If NIST had set clear performance requirements at the beginning then
the MD6 designers could, and obviously would, have limited their round
counts accordingly. Instead NIST allowed, and even seemed to encourage,
more flexibility; MD6 supports a wide range of security/performance
tradeoffs, including much more conservative possibilities than (e.g.)
Skein. Is NIST going to retroactively punish MD6 for this flexibility?

  
we're still looking for a pretty efficient trade-off
of memory, cycles and gates
    

Naturally. If the most efficient unbroken member of the MD6 family is
still too slow (or too big) for many users, while another unbroken hash
function meets those users' performance requirements, then MD6 probably
isn't the best choice for a standard.

But maybe the situation is exactly reversed! Maybe MD6 offers the best
security/performance tradeoff out of all the submissions. Maybe 24-round
MD6, running at a quite reasonable 7 cycles/byte, will remain untouched
while every other fast hash function is broken. I think that there's a
noticeable risk that ignoring reduced-round MD6 means ignoring the best
submitted SHA-3 candidate---and a quite large risk that ignoring _all_ 
of the reduced-round candidates, as Niels is doing, means ignoring the
best submitted SHA-3 candidate. I hope that NIST isn't so sloppy.
Neils probably observed that the winner in the AES competition was tuned more for performance than a large security margin, and had one trick, changing the number of rounds with the key size, that none of the other finalists incorporated.  Neils has a dog in this fight, and may have an interest in presenting the data in a way that favors Skein.  You're prodigiously productive, and are collecting performance data, please feel free to present your own data normalized as you think it should be, and I promise you we'll give the same attention to it that we give to Neil's table.

  

    
In fact I'll go so far as to say that until we get to the final round,
we won't be particularly confident that we know about how many rounds
people are going to be able to analyze.  That makes it a bit hard to
normalize performance by some notion of safety margin.
    

  

  

I'm not talking about any sort of abstract normalization. Real-world
Core 2 benchmarks will show that (for example) 24-round MD6 runs at
about the same speed as Skein. The question is whether NIST is going to
use Rivest's conservative recommendation of 168-round MD6 as an excuse
to disregard 24-round MD6.

I agree that comparing nonzero confidence levels isn't easy. This is
true whether we're talking about 24-round MD6, Skein, 168-round MD6,
or something else.

  

  

    
When Larry ran CubeHash he said, "boy that's a slow one."
    

  

  

There are two big problems here:

   * Larry is benchmarking only the most conservative function, namely
     CubeHash8/1, and completely ignoring the implementations of
     CubeHash8/2, CubeHash8/4, etc. that were also included in the
     submission.

   * Larry is benchmarking code that was forced to be written in an
     extremely conservative way to avoid the risk of compilation
     failures---NIST is using an unpublished test framework on a
     proprietary platform, making tests difficult for everyone else.

Since CubeHash offers an extremely wide range of security/performance
tradeoffs, and can benefit tremendously in speed from widely available
vector instructions, both of these problems are quite severe; it's
hardly a surprise that Larry hasn't seen how fast CubeHash can be.
  



I know that - but I think it's also fair to point out that Larry's
platform is pretty representative of what a great deal of the
commercial world uses today, even if you want to label it
"proprietary." 



In any comparison of Skein, MD6 and CubeHash at the moment seems to me
to be that all 3, if I remember correctly (and these things run
together a bit in my mind at this point)  rely on a simple core set of
operations for their security, but are embedded in somewhat different
structures.  And its those operations and the larger structures where
the interest lies at the moment, not the speed of the default version. 
For example, if we decide that a large block cipher is an easy
structure to test, and maybe something we need anyhow, then that would
be an advantage for Skein.  I have a gut feeling that we may well find
out that the speed of the three isn't really very different.  But Neils
can present the data his way, and you can do it yours, and Ron is
capable of making his own case very effectively.  And we'll do our best
to pay attention to all of you.  Neils has put a lot of data together
and that is useful.  You can play the same game and so can Ron, if you
wish.





  
---D. J. Bernstein
   Research Professor, Computer Science, University of Illinois at Chicago

  






-- 
William E. Burr
Manager, Security Technology Group
NIST
100 Bureau Dr., MS 8931
Gaithersburg, MD. 20899
Bldg. 222, Rm B362
Tel: 301-975-2914
Fax: 301-975-8670





--------------070105090803010209010600--


From hash-forum@nist.gov  Tue Dec 16 08:45:21 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBGGjCbn013554
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Tue, 16 Dec 2008 08:45:14 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBGGiKUk026373;
	Tue, 16 Dec 2008 11:44:24 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBGGhwLp005024;
	Tue, 16 Dec 2008 11:43:59 -0500
Date: Tue, 16 Dec 2008 11:43:58 -0500
Message-Id: <5574ACE4ACD88E45A7026FA0E350334B039F82@cleopatra.spyrus.com>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "Robert Jueneman" 
To: Multiple recipients of list 
Subject: RE: Scaling laws, and power usage
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Transfer-Encoding: 8bit
X-To: 
References: <77E8A818-5279-4A62-B253-0FECF60F4596@cryptolib.com>	<79B77C4C1E604E45967DBEA02EF6ED94@BobsDell>	<4945676C.3050307@nist.gov> <4945E48D.2080407@mit.edu> <5574ACE4ACD88E45A7026FA0E350334B039F53@cleopatra.spyrus.com> <494696CD.2070803@mit.edu> <4946A89E.4010908@nist.gov> <4946F208.1000702@ellipticsemi.com> <5574ACE4ACD88E45A7026FA0E350334B039F71@cleopatra.spyrus.com> <000001c95f51$13b97240$3b2c56c0$@org>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 16 Dec 2008 08:45:15 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 390


In the case of a contactless device, where the power has to be sucked
out of the air, I would suggest that the power density of the substrate
is of modest if any consideration.  Instead, the available power is
going to be constrained by the size of the device, and particularly the
antenna, and the transmitting power (and receiving sensitivity) of the
base of the interfacing system.

Bob

-----Original Message-----
From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of John
Washburn
Sent: Monday, December 15, 2008 11:46 PM
To: Multiple recipients of list
Subject: RE: Scaling laws, and power usage


RE: Ultimate computing capacity is limited by the power density that the
substrate can sustain.

Is then diamond substrate likely in the near future?

Diamond can be doped to be either an n or p semiconductor and Apollo
diamonds (http://www.apollodiamond.com/) is making diamond disks by
continuous vapor deposition (CVD).  The impediment seems to be the size
of
the diamond crystal which can be grown at a single time.  Apollo is not
to
the point of producing 90 mm diameter tubes which are half a meter in
length
as silicon ingots are.  They seem to be getting close though.


-----Original Message-----
From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of
Robert
Jueneman
Sent: Monday, December 15, 2008 7:54 PM
To: Multiple recipients of list
Subject: RE: Scaling laws, and power usage


Thanks to all, and especially Mike, for elucidating some of these issues
much more clearly, and probably correctly, than I could have ever done.
(The only circuits I ever designed involved triodes, but that experience
is no longer relevant!)

The conclusion, I think, is that size and power consumption are very
important for a very considerable portion of the space in which SHA-3
will be used.  And Neils has made a pretty good argument why this is
important for even the large host processors as well, for the
foreseeable future (whatever that may be, in terms of operating system
design.)

So although I am one that likes to think about hash functions, digital
signatures, encryption, and RNGs being resilient enough to resist
attacks for at least another 100 years, and hopefully longer, these
issues of efficiency and scalability are also important, and hence my
desire for the parametric "knobs" on the algorithms.

Bob


-----Original Message-----
From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Mike
Borza
Sent: Monday, December 15, 2008 4:19 PM
To: Multiple recipients of list
Subject: Re: Scaling laws, and power usage


This is an area that I have some experience in.  The discussion so far
is mostly correct, to first order.  I don't want this to degrade into a
discussion of semiconductor physics so I'll state a highly simplified
model for the components of power consumption here, then try to relate
that back to the main point in Robert's original post.

Power dissipation in CMOS circuit technology (the most common technology
at this time, and likely to be so for some time to come) consists of two
parts: static and dynamic power.  Static power dissipation has for the
past several years been largely irrelevant (and is often approximated as
zero, as Ron has done); however, as feature sizes continue to scale down
static power dissipation becomes an increasingly large fraction of total
power dissipation.  Dynamic power dissipation is the component most
people think about in CMOS circuits, and it is f*C*V^2, where f is the
switching (clock) frequency, C is the load capacitance that a gate
"sees", and V is the supply voltage.  C itself is ideally the
capacitance on adjacent cell(s), which is proportional to the square of
the feature size, and so does scale down with the square of linewidth
reduction with advancing technology.  Thus, we've been accustomed to
gaining exponential increases in circuit (functional) density with
reductions in minimum feature size; simplistically this effect is
responsible for Moore's law. 

However, we're now running into some fundamental physical limits: we
haven't hit them yet but we're going to soon enough.  Supply voltages
now are unable to scale down as quickly as linewidth.  Also, as I
mentioned static power dissipation due to gate leakage and other effects
is an increasing proportion of total consumption and doesn't scale as
quickly.  Finally, while capacitance ideally scales down in each new
technology node, the interconnect between circuit elements is not
following that trend at the same rate, resulting in more dissipation
than predicted by simple technology scaling.  This is why power
dissipation has not kept pace with logic density.  Ultimate computing
capacity is limited by the power density that the substrate can sustain.
This in turn limits the maximum frequency and density that circuits can
be designed for and therefore the maximum throughput (or minimum area).

What does this mean for selecting a hash algorithm?  First, it is
axiomatic that the algorithm ultimately selected must have sufficient
security.  Without that, there is no reason to implement it, and its
efficiency doesn't matter.  After that, it should be the most cost
effective implementation that satisfies the security requirements. 
Simplistically, the cost of an implementation (in either dollars or
watts) is proportional to the product of its implementation area and the
speed that it operates at.  What I think Robert, and certainly people
like me, would hope to find as a result of this competition is that the
cost can be extremely low to justify use of the algorithm in very small
implementations.  Costly implementation will have large area
requirements (for example large intermediate states or static table
spaces), or those that produce very small amounts of output per clock
cycle.  An algorithm that can be predictably tuned in terms of the
amount of security provided, the amount of space required, or the speed
at which it generates its output will be the most flexible and useful in
trading these aspects off, and therefore applicable across a range of
applications.

While I appreciate the importance of efficient software implementations
that run in large CPU environments, most of the people I'm involved with
don't deploy their solutions in those environments.  They have
performance and cost constraints that simply don't fit.  As Robert
noted, the devices they develop often interoperate with those large
software environments.  User credentials are an example: these may take
the form of smartcards or wirelessly powered RFID tags that authenticate
their holders to central servers.  Individual users may be able to
tolerate modest performance, but a server simultaneously authenticating
thousands of those users needs to be capable of accomplishing that in a
reasonable time.

To give a concrete example, AES is very flexible in its definition and
range of implementation possibilities.  It has scalable security that
imposes a modest penalty to scale up the security.  The smallest
hardware implementations are about 4K gates running at about 0.1 bits
per cycle.  Small software implementations fit in a few hundreds bytes
of code, and it runs acceptably in 8 bit processors, which are still
today shockingly popular in new designs.  From there, it is possible
today to scale the same algorithm up to a single implementation capable
of 128 bits per cycle at, say, 500 MHz in about 300K gates.  That's a
range from a few 10's or 100's of kilobits per second to about 64
gigabits per second, and all at a security level of at least 128 bits. 
Instantaneous power consumption to accomplish this ranges from
microwatts to a few watts, which as Bill notes is well down from what it
was just a few years ago.  Neither of those extrema has a place in a CPU
today nor for the forseeable future.  But note that we'll bottom out the
gains we can make in traditional semiconductor technology in the next
fewyears.  Any replacement technologies will face similar ultimate
limits, some at admittedly much higher levels of performance, smaller
volume requirements or lower power consumption.

This is the kind of flexibility I would like to see in the ultimate hash
competition selection.

Best regards,
Mike Borza

On 15/12/08 01:58 PM, Bill Burr wrote:
>
> Ron & Bob,
>
> I don't claim any particular VLSI expertise, but my understanding is
> that transistors only consume much power when they are actually
> switching, that is P=I*V, and when a transistor is in the either the
> on or the off state, either I or V is close to zero.  So when you
> crank up the clock you almost always increase poser consumption. 
> Moreover you are charging and discharging capacitors more, and that
> means current is flowing, and current flowing tends to mean power is
> being consumed.    Also smaller transistors generally means lower
> voltages, and smaller currents, while power is proportional to both
> V^2 and I^2.  In principle I think you naturally  reduce power
> consumption per  computation as you shrink dimensions, but of course,
> you increase overall power consumption as you increase clock rates.
>
> Of course, as soon as you have to drive an external lead off the chip,
> you're back to dealing with higher voltages, and more current.
>
> We know that power consumption per unit of computation has gone down
> greatly as we've crammed more and more gates into less and less
> area.   I just bought a little netbook with an Intel Atom processor. 
> It has a 1.6 GHz clock, and burns very little power, yet it's surely
> computationally more powerful than the early Pentiums of not so long
> ago, which ran hot enough to fry eggs.  Maybe reducing power
> consumption hasn't kept pace with the exponent of Moore's Law for
> semiconductors, but if power consumption is pretty much the limiting
> factor today, then our ability to limit power consumption (or to carry
> the heat away) must be largely the limiting factor in Moore's Law, at
> least if you think of Moore's law in terms of computing power per
> Dollar, I think.
>
> Regards,
>
> Bill
>
> Ronald L. Rivest wrote:
>>
>> Hi Bob --
>>
>> Good comments!
>>
>> With respect to scaling however, my understanding is
>> that scaling *can* improve power usage.  If you
>> decrease dimensions by a factor of two in both x and
>> y dimensions, then all capacitances decrease by a factor
>> of four, and power usage improves, since it takes less
>> current to change the state of a capacitor.  This is
>> assuming you don't also change the clock rate or voltage.  If
>> you increase the frequency by a factor of four, you get
>> the same current draw, but to increase frequency you
>> need to increase voltage inside the chip to get things
>> to happen faster.  So power usage tends to go up.
>> Scaling is complicated, but the increased freedom of
>> using smaller features on a chip can yield improved
>> power usage, if you don't muck with the clock rate and/or
>> voltage at the same time...
>>
>> (The above analysis is quite simplistic and naive; for the
>> truth someone with stronger VLSI expertise should advise
>> us...)
>>
>> Cheers,
>> Ron
>>
>> On 12/15/2008 12:19 PM, Robert Jueneman wrote:
>>> Ron and Bill,
>>>
>>> I don't have a dog in this fight, but I'd like to comment on the
size
>>> issue, since SPYRUS is involved in both the low-cost, low-power,
>>> bandwidth-constrained smartcard end of the spectrum and the
relatively
>>> unconstrained HSM and/or host-based processing system at the other.
>>>
>>> For interoperability, it is essential that we have an efficient
>>> algorithm that can run in both spaces.
>>>
>>> I also agree with the need for multi-purpose algorithms -- we were
the
>>> first and perhaps still one of the few organizations to use
HASH_DRBG
>>> from SP 800-90 for random number generation.  (Somehow, using AES to
>>> generate keys to be used for AES seemed like putting too many eggs
in
>>> one basket, especially when you think about SPA and DPA attacks.)
>>>
>>> With regard to hashing vs. digital signatures on a chip, the issue
is
>>> more likely going to be bandwidth rather than processing power, as
>>> smart
>>> cards normally support only the IOS 7816 interface -- maybe 100 kbps
at
>>> best.  Our smart cards have no difficultly computing ECDSA, EC-DH,
and
>>> ECMQV for P-256, P-384, and P-521, and the code size constraint
isn't
>>> much of a limitation -- the code will fit comfortably into ROM or
>>> EEPROM, as required.  But don't expect it to be done in a
millisecond.
>>>
>>> In that regard, it is important to remember that although Moore's
Law
>>> predicts ever-increasing transistor density, and that generally
>>> translates into increased speed and what I will call agility
>>> (parallelism, redundant implementations, etc.), there is one thing
that
>>> Moore's law does NOT provide, and that is the increased power
required
>>> to operate these devices.  I'm certainly not a semi-conductor
>>> physicist,
>>> but I don't recall reading anything about reducing the power
>>> required to
>>> flip a bit in a transistor.  And the faster you want to do that, the
>>> more electrical power it takes.
>>>
>>> So when you start talking about nano-processors, that is likely to
be
>>> the limiting factor.  And where that shows up in today's market is
with
>>> respect very low cost, very low power RFID chips.
>>>
>>> In that market, I expect that a keyed hash will continue to be very
>>> important as an alternative to the slower digital signatures of
>>> comparable strength.  Maybe not HMAC -- no disrespect to Hugo, but I
>>> would like to see a keyed MAC algorithm devised that is less
>>> computationally intensive -- but surely something along those lines.
>>>
>>> On the other hand, if we aren't talking about creating hashes and
>>> digital signatures that will be sufficiently robust to resist
>>> cryptanalytic attacks for hundreds of years or more, but only need
to
>>> survive a couple of years against modest attacker resources, then a
>>> 512-bit algorithm may be overkill, and 128-bits may even be
sufficient.
>>>
>>> I guess I'm arguing for algorithms with "knobs" that can be used to
>>> easily tune the performance characteristics as required, while still
>>> providing interoperability.
>>>
>>> Regards,
>>>
>>> Bob
>>>
>>> Robert R. Jueneman
>>> Chief Scientist
>>> SPYYRUS, Inc.
>>>
>>> -----Original Message-----
>>> From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of
>>> Ronald L. Rivest
>>> Sent: Sunday, December 14, 2008 9:07 PM
>>> To: Multiple recipients of list
>>> Subject: Thoughts on SHA-3 potential applications, esp. for small
>>> devices (LONG)
>>>
>>>
>>> Hi Bill --
>>>
>>> I appreciate your thoughtful essays...
>>>
>>> There are indeed a lot of dimensions and tradeoffs to
>>> consider for the SHA-3 competition.
>>>
>>> If we think about why one wants a hash standard, four
>>> reasons come to mind (in no particular order):
>>>
>>>    (1) A standard promotes and facilitates _interoperability_
>>>        between products produced by different organizations.
>>>
>>>    (2) A standard will have been thoroughly evaluated for
>>>        cryptographic strength.
>>>
>>>    (3) A standard will be accompanied by a multitude of
>>>        well-engineered and tested implementations for various
>>>        platforms.
>>>
>>>    (4) A standard, by being a standard, facilitates decision-making
>>>        by organizations that are too risk-averse and non-technical
>>>        to make a decision in the absence of a standard.
>>>
>>> For a hash function, I suspect that the main use for
interoperability
>>> between products of different organizations will probably continue
>>> to be as a component of digital signatures.
>>>
>>> I do wonder, as you do, what the real needs will be for
cryptographic
>>> primitives on various platforms, as time goes forward.  The future,
>>> as usual, is not always predictable.
>>>
>>> The needs of very small devices are perhaps the most interesting
>>> question to consider.
>>>
>>> Devices that are already sufficiently powerful to compute public-key
>>> digital signatures are presumably going to be big enough to easily
>>> accommodate any sort of reasonable hash function as well.
>>>
>>> I think that devices that are too small to perform a public-key
>>> digital signature will frequently nonetheless have a requirement
>>> to authenticate themselves---to perform a MAC.  (As you said.)
>>>
>>> But the requirements for MAC's are different (and in many ways
>>> simpler) than those for hash functions.  We care about forgery
>>> rather than collision resistance, MAC outputs can be shorter than
>>> hash function outputs, etc.  I feel it would be a bit strange to
>>> let the hash function competition be driven by the expectation
>>> that, for small devices, there is a need to utilize the SHA-3
>>> hash function to produce MAC's.
>>>
>>> If the world is going to be filled up with tiny devices that
>>> need to authenticate themselves, then there is a clear need for
>>> an appropriate MAC standard.  The SHA-3 competition was not set up
>>> to produce such a standard; it merely noted that suitability for
>>> use in HMAC was a SHA-3 requirement.  It would probably be a
>>> mistake for the world to conclude that NIST feels that all small
>>> devices should be using HMAC as an authentication technology,
>>> when there are likely to be much better alternatives for small
>>> devices.  (Perhaps down the road NIST would enjoy running a
>>> "nano-MAC" standards competition!)
>>>
>>> I also suspect that in the world of very small devices, almost
>>> all system designs will be proprietary and closed.  Think for
>>> example of mass transit card systems or building access cards.
>>> There is no need for small devices in these systems to work
>>> "outside the system".  The need for interoperability through
>>> an open standard is not wanted (indeed, it may be very much
>>> undesired).  Thus, for very small devices the need for a standard
>>> in order to support interoperability may be small or absent.
>>>
>>> Of course, there may be exceptions, and who knows what future
>>> systems will need.
>>>
>>> But I find it hard to think of applications for hashing for
>>> very small devices where:
>>>     -- the device is too small for public-key operations
>>>     -- the hash function is not being used for a MAC
>>>
>>> To see why, note that abstractly, a hash value is often used as
>>> a "proxy" for the value being hashed.  Its shorter length may be
>>> better suited for computation (as for a digital signature) or
>>> for communication (e.g. for the hash of a message being transmitted
>>> by a different channel, or at a different time).
>>>
>>> But very small devices don't have more than one communication
channel,
>>> and they don't have much storage, so applications that send a hash
>>> value from a small device, so that it can later send the real
message,
>>> seem dubious (it requires storage).  Applications that send the hash
>>> so that the real message can be sent via another channel may also be
>>> rare, since the device doesn't have more than one channel.
>>>
>>> It isn't very clear to me what utility a "hash value as a proxy
>>> for a message" philosophy has for very small devices.
>>>
>>> Finally, a hash value can be appended to a message for transmission,
>>> but if one merely wants redundancy it can be done in better ways.
>>> (Keyed redundancy is different, but that is what a MAC gives.)
>>>
>>> I suspect that the world will indeed be filled with lots of
>>> fascinating small electronic devices, but I think that if they
>>> do crypto, it will almost certainly be MAC's or digital signatures.
>>> It is unlikely to be unkeyed hash function application.
>>>
>>> Perhaps I've overlooked something important, but I'm far from
>>> persuaded that the SHA-3 standard will be very relevant for
>>> very small devices, until you get up to size where the device
>>> is capable of performing public-key digital signatures.  Then
>>> it will become relevant.  But at that point, we've got fairly
>>> substantial resources already devoted to doing crypto, and one
>>> should be considering the digital signature operation as a whole;
>>> the hash function implementation may be a small piece of that whole.
>>>
>>> And of course, Moore's Law hasn't quite died yet, and transistors
>>> continue to shrink.  For small devices, at some point the cost of
>>> bonding and packaging them should greatly exceed the cost of
>>> producing the chip.  (Perhaps we are there already...)
>>>
>>> Perhaps others on this list have thoughts on how SHA-3 might
>>> be useful on very small devices...
>>>
>>> These are good discussions to have, and I appreciate your
>>> bringing these topics up in the hash-forum list.  I agree
>>> with many of the points you brought up.
>>>
>>>
>>> Cheers,
>>> Ron Rivest
>>>
>>>
>>> On 12/14/2008 3:18 PM, Bill Burr wrote:
>>>> Bob,
>>>>
>>>> We're trying to listen to what everybody says, before forming
>>>> NIST's opinion about the relative importance of micro-controllers
with
>>> limited
>>>> memory, versus 1001 other trade-offs.  It's just too soon for us to
do
>>>
>>>> that.
>>>>
>>>> In the end, we're going to want something that is a good substitute
>>> for
>>>> the SHA-2s in all of their major applications, but is significantly
>>>> better than SHA-2 in some significant respects.  Unless the SHA-2s
>>>> be "significantly" broken it's going to be very hard to force
>>>> products to
>>>
>>>> change to SHA-3, or even implement SHA-3, if SHA-3 has few
significant
>>>
>>>> practical advantages.
>>>>
>>>> To steal a phrase from Bruce Schneier's talk at the final AES
>>>> conference, we're probably going to pick a SHA-3 that doesn't "suck
at
>>>
>>>> anything," or at least anything apparently very significant.  And
>>>> to pick a SHA-3 that is better than SHA-2 at several things.  I
>>>> think we did about that when we selected Rijndael to be the AES,
>>>> although TDES was easier to improve on than the SHA2's are. The
>>>> SHA-2s, I think, set
>>> a
>>>> reasonably high bar.   It's worth remembering, in this respect,
>>> however,
>>>> that TDES is not without its virtues: it's pretty efficient in
>>> hardware.
>>>> I'll point one other related trade-off I think I see here.  The
SHA-2s
>>>
>>>> give us two different pipe widths.  Is it better to do this, or
have
>>> one
>>>> compromise pipe width for all 4 output sizes, that perhaps is a
little
>>>
>>>> narrower than ideal for the 512-bit output?
>>>> At this point it's not clear to me (as distinct from the rest of
>>>> the folks in my group, who I haven't discussed this with very much
>>>> at this
>>>
>>>> point)  that we often ask low-end micro controllers to generate
>>>> collision free hashes.  I suppose that there will always be
>>> applications
>>>> for low end processors with very little RAM, but will those often
>>>> require collision free hashes?  And we seem to get more and more
>>>> powerful processors with more and more memory into smaller and
smaller
>>>
>>>> packages.  It also seems to me that there are more efficient ways
>>>> to address MACs in micro controllers, than HMAC.  So, if HMAC be
>>>> the main
>>>
>>>> application for hash functions in micro controllers, then maybe low
>>> end
>>>> micro controllers would not be a major concern for SHA-3.  But I
>>> remain
>>>> open to arguments to the contrary.  And I'm pretty sure we'll wind
>>>> up with several second round candidate algorithms with narrow-pipe
>>> designs,
>>>> as well as several wider pipe designs.
>>>>
>>>> Regards,
>>>>
>>>> Bill Burr
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Bob Hattersley wrote:
>>>>> A somewhat intemperate post perhaps, but there's an interesting
>>>>> question in
>>>>> there.  Waterfall would be a 6x design in this classification and
>>>>> therefore
>>>>> a "monster".  (Since I have no desire to make anyone ill, I
recommend
>>>
>>>>> that
>>>>> sensitive souls should avoid any further contact with it.)  I
>>>>> worked under
>>>>> the (possibly invalid) assumption that 512 bytes of RAM (and 2kB
>>>>> of program
>>>>> storage) was a reasonable target.  1kB RAM seems to be widely used
>>> today,
>>>>> and memory doesn't seem to be getting more expensive.  Most
>>>>> microcontrollers
>>>>> are not used in situations where cryptography has any relevance.
>>>>>
>>>>> But what is the general opinion?  Perhaps more important - what is
>>> NIST's
>>>>> view?
>>>>>
>>>>> Bob Hattersley (Waterfall)
>>>>>
>>>>> -----Original Message-----
>>>>> From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf
Of
>>> Sean
>>>>> O'Neil
>>>>> Sent: 13 December 2008 06:27
>>>>> To: Multiple recipients of list
>>>>> Subject: Narrow-pipe designs
>>>>>
>>>>>
>>>>> A number of people are asking a good question:
>>>>>
>>>>> Can someone please publish a paper listing all the narrow-pipe
hashes
>>> as
>>>>> broken by design, so we could all focus on the good ones with 2x
and
>>>>> slightly larger states?
>>>>>
>>>>> <2x is vulnerable by design, >=2x up to 2.5x (or possibly up to
3x)
>>> is
>>>>> the
>>>>> optimal choice, but all the >=4x monsters and some of the designs
>>> such as
>>>>> Crunch or FSB with their reference code requiring MEGABYTES (!!!)
>>>>> of tables
>>>>> to function are certainly gone too far.  With all due respect to
>>> their
>>>>> authors, I wouldn't bother looking at those as
>>>>> a total waste of time.
>>>>>
>>>>> Personally, the hash functions with 4x and larger states make me
>>> wanna
>>>>> puke,
>>>>> but technically, they would simply never fit in 128 or
>>>>> 256 bytes of RAM of the [yes, very] popular 8-bit microcontrollers
>>>>> that may
>>>>> want to use some of it for other purposes than merely storing the
>>> entire
>>>>> hash state with no room left for a single variable.
>>>>>
>>>>> Best regards,
>>>>> Sean O'Neil
>>>>> http://www.enrupt.com/ - Raising the bar.
>>>>>
>>>>>
>>>>>
>>>>>   
>>>
>>
>



No virus found in this incoming message.
Checked by AVG - http://www.avg.com 
Version: 8.0.176 / Virus Database: 270.9.18/1850 - Release Date:
12/15/2008
5:04 PM




From hash-forum@nist.gov  Tue Dec 16 06:13:02 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBGECukT023627
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Tue, 16 Dec 2008 06:12:57 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBGE4FQl016620;
	Tue, 16 Dec 2008 09:04:18 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBGE3QJW026634;
	Tue, 16 Dec 2008 09:03:26 -0500
Date: Tue, 16 Dec 2008 09:03:26 -0500
Message-Id: <4947B27D.6030907@nist.gov>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: Sara Caswell 
To: Multiple recipients of list 
Subject: Re: Submissions, compiled
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
In-Reply-To: 
References: 
MIME-Version: 1.0
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 16 Dec 2008 06:12:57 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.2 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 391


On behalf of Orr Dunkelman:

ahm ahm...

If someone is using the AES' S-box, I think it would be easier to
understand a huge "table" of 256 entries (or today, when we all know how
to use 5 tables of 256 entries of 32 bits each), then to compute the
S-box as a field operation and multiplication by a linear matrix.

Actually, a reference implementation should be optimized for
readability, and not for memory consumption. I am sure that anything
which uses AES can take a much smaller foot print in memory (you can
implement AES in 3.4 Kgates, of which 2.0 Kgates are memory, so we're
talking about 1.4 Kgates for control and logic).

aha! and btw, we put comments for almost every line. Despite the
fact that we're using a Feistel construction, and the AES round
function. Does this mean SHAvite-3 is complex? or just that we try to
follow good coding practice as promoted at
http://www.ecrypt.eu.org/stream/phorum/read.php?1,1223

Best regards,
Orr.


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Sean O'Neil wrote:
>
> After some struggle fighting off numerous warnings and compilation 
> errors in some of the submissions, a simple size comparison of the 
> submitted reference source code and Release binary code compiled with 
> MSVC 2005 with default settings can be found at:
>
> http://www.sha3.org/source_size.html
> http://www.sha3.org/binary_size.html
>
> A reference source code is expected to be the simplest most readable 
> implementation of the hash function. These results demonstrate the 
> potential minimum complexity and code/memory cost the implementers 
> will have to deal with.
>
> Best regards,
> Sean O'Neil
> http://www.enrupt.com/ - Raising the bar.
>
>


From hash-forum@nist.gov  Tue Dec 16 06:35:07 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBGEZ07W027148
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Tue, 16 Dec 2008 06:35:02 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBGEXDFn031298;
	Tue, 16 Dec 2008 09:33:20 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBGEWUZD020566;
	Tue, 16 Dec 2008 09:32:30 -0500
Date: Tue, 16 Dec 2008 09:32:30 -0500
Message-Id: 
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: zooko 
To: Multiple recipients of list 
Subject: Re: How will NIST handle the tunable security parameter?
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Mailer: Apple Mail (2.753.1)
X-To: hash-forum@nist.gov
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
References: <20081216075000.75654.qmail@cr.yp.to> 
In-Reply-To: 
Mime-Version: 1.0 (Apple Message framework v753.1)
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 16 Dec 2008 06:35:03 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 392


On Dec 16, 2008, at 2:34 AM, Stefan.Lucks@uni-weimar.de wrote:

> The particular choice of defaults for the security parameters  
> reflects the designers' confidence into their creations. How could  
> the general public gain confidence into a version of a hash  
> function, if the designers of that hash function don't have that  
> confidence?

I guess when a design is new, then if we want to estimate its  
strength we should use the designer's opinion, but once it has been  
widely studied, then we have a more reliable way to estimate its  
strength: the knowledge collectively developed by analyzing it,  
especially as crystalized in real attacks and other quantitative  
measurements.  At that point, we need not depend as strongly on the  
original opinion of the original designer.

By the way, I'm not accomplished at cryptanalysis, but Skein looks  
great to me.  I like the simple core function, the way that tweaks  
are used to separate some potential issues from others, the 64-bit  
efficiency with the recommended parameters, the height-bounded Merkle  
Tree construction, and the small amount of state required.  I'm a bit  
disappointed at the 32-bit efficiency with the recommended parameters  
because, as I've mentioned, I anticipate 32-bit environments being an  
interesting target for me in the future, but maybe if Skein is  
successful in the contest then something could be done about that.

Regards,

Zooko
---
http://allmydata.org -- Tahoe, the Least-Authority Filesystem
http://allmydata.com -- back up all your files for $10/month

From hash-forum@nist.gov  Tue Dec 16 06:49:06 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBGEn03K028882
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Tue, 16 Dec 2008 06:49:01 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBGElYGI018667;
	Tue, 16 Dec 2008 09:47:41 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBGEkrdV017308;
	Tue, 16 Dec 2008 09:46:53 -0500
Date: Tue, 16 Dec 2008 09:46:53 -0500
Message-Id: <4947BD79.5010001@win.dtu.dk>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: =?ISO-8859-1?Q?S=F8ren_Steffen_Thomsen?= 
To: Multiple recipients of list 
Subject: OFFICIAL COMMENT: Tangle
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="ISO-8859-1"
MIME-Version: 1.0
X-CC: 
X-To: 
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 16 Dec 2008 06:49:02 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 393


Hi,
I have found practical collisions in Tangle-n for all supported digest
sizes n.

As an example, the following is a collision in Tangle-256 (messages are
written byte-by-byte, without padding):
Message 1:
c8190000000000000000000000000000000000000000000000000000000000000000000000000000
Hash of message 1:
f710be651ab67737a58ac452056bbf13e62abed071943617dadbf25c2dea710b
Message 2:
c8190080000000800000000000000000000000000000000000000000000000000000008000000080
Hash of message 2:
f710be651ab67737a58ac452056bbf13e62abed071943617dadbf25c2dea710b
XOR of hashes:
0000000000000000000000000000000000000000000000000000000000000000

A description of the attack can be downloaded from
http://www.mat.dtu.dk/people/S.Thomsen/tangle/tangle-coll.pdf.

Best regards,
Søren Thomsen.

-- 
Søren Steffen Thomsen
PH.D. student
DTU Mathematics
-------------------------------
Technical University of Denmark
Department of Mathematics
Matematiktorvet 303S
Building 303S
2800  Kgs. Lyngby
Direct +45 4525 3010
Mobile +45 2290 5443
S.Thomsen@mat.dtu.dk
www.mat.dtu.dk/

From hash-forum@nist.gov  Tue Dec 16 09:29:02 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBGHSsMo022724
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Tue, 16 Dec 2008 09:28:57 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBGHSBn4013475;
	Tue, 16 Dec 2008 12:28:13 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBGHRgr2028947;
	Tue, 16 Dec 2008 12:27:42 -0500
Date: Tue, 16 Dec 2008 12:27:42 -0500
Message-Id: <20081216121512.98842mlo86zr0un4@webmail.nist.gov>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "John Kelsey" 
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed"
MIME-Version: 1.0
In-Reply-To: <49467AB0.1070505@nist.gov>
References: <20081215100903.52177.qmail@cr.yp.to> <49467AB0.1070505@nist.gov>
X-Cc: "Multiple recipients of list" 
X-To: hash-forum@nist.gov, "Bill Burr" 
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 16 Dec 2008 09:28:58 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 394


Just a couple of meandering thoughts about the security parameter:

It seems to me that there are two important issues being discussed  
here, w.r.t. the tunable parameters in the algorithms.  The tunable  
parameters involve a tradeoff between performance and security. You  
can see the recommended tunable parameters as encoding two pieces of  
information:

a.  The designer's understanding of the security of his own algorithm

b.  The designer's preferred tradeoff between security and  
performance, in particular how much overdesign he thinks is  
appropriate.  (If your best known attack is 10 rounds, do you  
recommend 12 rounds, or 20, or 40?)

The designer's recommended parameter can basically go wrong in two ways:

First Issue:  What if you've set the parameters too low, so that you  
get attacked?

Now, I understand the desire to want to be able to tweak the  
parameters toward more security when you see an attack.  But honestly,  
we're trying to evaluate 51 submissions!  If the response to an attack  
is always "I can add some rounds to make it secure," then no  
algorithms will ever be removed from the competition by cryptanalysis.  
  Once you allow tweaking of parameters and algorithms to overcome an  
attack, you can always recover from attacks.  Even the hashes  
vulnerable to length-extension attacks or similar stuff can be tweaked  
to be resistant, usually with minimal effort.  How does this ever end?  
  The result of this would be that we divide cryptanalysis effort  
among 51 algorithms until NIST does the first cut and narrows them  
down to 15 or so, which means that the most promising algorithms don't  
get as much analysis, so that we can keep adding rounds to attacks  
that have already been published.

Imagine applying this to the AES process.  Instead of getting several  
of the designs knocked off by attacks, we would have had none knocked  
off.  Cryptanalysis would have been only about forcing changes in the  
parameters.  I have a hard time seeing that this would have led to a  
better outcome.  (I'll admit that I think the AES process did a pretty  
good job of selecting finalists and a winner--I was one of the  
submitters of a finalist, and now I work for NIST, so take my opinion  
here with as many grains of salt as you like.)

In terms of evaluating the security of an algorithm, your choices are  
basically cryptanalysis and the intuition of the reviewers after  
reading the documentation.  If we don't ever remove algorithms because  
of cryptanalysis (because we just let the designers change  
parameters), then either we remove algorithms on the basis of our  
intuition, or we don't remove algorithms from consideration for  
security problems, only for performance problems.  (And see below!) I  
just can't see this working out.  It needs to be possible for  
submissions to be broken and removed from the competition, even when  
it wouldn't be hard to fix them.

One good justification for this is that we expect the designer to have  
seriously thought about the security of their algorithm, and to have  
worked out the best likely attacks, in the months during which they  
were writing their submission, with far more precision and detail than  
outsiders will be able to get in a month or so of looking at them.  If  
the submission gets broken at the recommended parameter set,  
especially early in the competition, this undermines confidence that  
the designer understood the security of his own design.  (Of course,  
some attacks exploit a small oversight that doesn't indicate a broader  
problem with the designer's analysis of his own design--there are no  
perfect mechanisms for selecting finalists or a winner available to us.)

Second Issue: What if you've set the parameters too high, so that you  
get smoked on all the performance measurements?

This seems like a pretty different situation, to me.  For one thing,  
performance is easy to measure (much easier than security), so if you  
have a design that allows trading off security margin for performance,  
you can kind-of do it later, and you can have confidence that you  
understand at least the performance gain.

For another, while it probably makes sense to remove algorithms where  
the designer didn't understand their security, it doesn't make sense  
to remove algorithms whose designers just wanted a different  
performance/security tradeoff.  That doesn't cast any doubt on the  
ultimate soundness of the algorithm, it's just an engineering tradeoff.

The downside of this is that it benefits algorithms that have chosen  
very conservative parameters, because they're unlikely to be broken  
and removed from the competition, but they may be permitted to tweak  
their parameters toward more performance later.

As an attacker, I like having a meaningful target.  It's sort-of  
disspiriting to be attacking a cipher with 32 rounds, and the best  
attack you've got can get through 10.  If the target were 12 or 14  
rounds, I might keep digging till I got through the extra rounds.

For cryptanalysts, I think a couple performance points might be  
interesting to look at, outside of the stated parameters from the  
designer:

a.  Approximately equal performance to SHA256 on the reference platform.

b.  Approximately equal performance to some of the fastest of the  
currently-unbroken designs on the reference platform.

Those aren't going to look like breaks of an algorithm, but they give  
you a meaningful target to shoot for--if you break a variant of MD6  
with small enough number of rounds that it would be one of the fastest  
unbroken algorithms, you've accomplished something ineresting, even if  
it doesn't break the algorithm.  (I'm using MD6 as an example because  
it's visible, not because I have any notion of how to attack it.)

--John Kelsey, NIST


From hash-forum@nist.gov  Tue Dec 16 09:45:43 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBGHjY8L026162
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Tue, 16 Dec 2008 09:45:36 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBGHicfo025746;
	Tue, 16 Dec 2008 12:44:39 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBGHiMOI032028;
	Tue, 16 Dec 2008 12:44:22 -0500
Date: Tue, 16 Dec 2008 12:44:22 -0500
Message-Id: <20081216184041.18113egf6gyq54ig@webmail.tugraz.at>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: Christian Rechberger 
To: Multiple recipients of list 
Subject: RE: Scaling laws, and power usage
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Transfer-Encoding: 8bit
X-Organization: Graz University of Technology
Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed"
MIME-Version: 1.0
In-Reply-To: <5574ACE4ACD88E45A7026FA0E350334B039F82@cleopatra.spyrus.com>
References: <77E8A818-5279-4A62-B253-0FECF60F4596@cryptolib.com> <79B77C4C1E604E45967DBEA02EF6ED94@BobsDell> <4945676C.3050307@nist.gov> <4945E48D.2080407@mit.edu> <5574ACE4ACD88E45A7026FA0E350334B039F53@cleopatra.spyrus.com> <494696CD.2070803@mit.edu> <4946A89E.4010908@nist.gov> <4946F208.1000702@ellipticsemi.com> <5574ACE4ACD88E45A7026FA0E350334B039F71@cleopatra.spyrus.com> <000001c95f51$13b97240$3b2c56c0$@org> <5574ACE4ACD88E45A7026FA0E350334B039F82@cleopatra.spyrus.com>
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 16 Dec 2008 09:45:37 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 395


Quoting Robert Jueneman :

>
> In the case of a contactless device, where the power has to be sucked
> out of the air, I would suggest that the power density of the substrate
> is of modest if any consideration.  Instead, the available power is
> going to be constrained by the size of the device, and particularly the
> antenna, and the transmitting power (and receiving sensitivity) of the
> base of the interfacing system.

On the use-case you draw here: passively powered circuits.

 From what I have learned while working with colleagues that know much  
more about VLSI design than I do, is that it is not so much about the  
size of the device (i.e. the size of circuit that implements some  
functionality). Rather, it is about the mean current consumption of  
your circuit, that is not allowed to exceed the available energy in  
the capacitors. There is of course some correlation between those two  
measures, but it's not the same.

The 3.4 kGates implementation of AES, that is frequently quoted, is  
actually not optimized for a low gate-count, but having the "minimal  
mean current consumption" in mind. The flexibility of the AES when it  
comes to implementation choices and trade-offs comes very handy of  
course.

Let me restate a question asked earlier that was somewhat lost in this  
discussion: Is there an actual need for collision-resistant primitives  
in such extremely constrained settings? Interoperability needs were  
mentioned. If there is none or little need today, could there be one  
in (say) 15 years time?

-Christian




> -----Original Message-----
> From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of John
> Washburn
> Sent: Monday, December 15, 2008 11:46 PM
> To: Multiple recipients of list
> Subject: RE: Scaling laws, and power usage
>
>
> RE: Ultimate computing capacity is limited by the power density that the
> substrate can sustain.
>
> Is then diamond substrate likely in the near future?
>
> Diamond can be doped to be either an n or p semiconductor and Apollo
> diamonds (http://www.apollodiamond.com/) is making diamond disks by
> continuous vapor deposition (CVD).  The impediment seems to be the size
> of
> the diamond crystal which can be grown at a single time.  Apollo is not
> to
> the point of producing 90 mm diameter tubes which are half a meter in
> length
> as silicon ingots are.  They seem to be getting close though.
>
>
> -----Original Message-----
> From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of
> Robert
> Jueneman
> Sent: Monday, December 15, 2008 7:54 PM
> To: Multiple recipients of list
> Subject: RE: Scaling laws, and power usage
>
>
> Thanks to all, and especially Mike, for elucidating some of these issues
> much more clearly, and probably correctly, than I could have ever done.
> (The only circuits I ever designed involved triodes, but that experience
> is no longer relevant!)
>
> The conclusion, I think, is that size and power consumption are very
> important for a very considerable portion of the space in which SHA-3
> will be used.  And Neils has made a pretty good argument why this is
> important for even the large host processors as well, for the
> foreseeable future (whatever that may be, in terms of operating system
> design.)
>
> So although I am one that likes to think about hash functions, digital
> signatures, encryption, and RNGs being resilient enough to resist
> attacks for at least another 100 years, and hopefully longer, these
> issues of efficiency and scalability are also important, and hence my
> desire for the parametric "knobs" on the algorithms.
>
> Bob
>
>
> -----Original Message-----
> From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of Mike
> Borza
> Sent: Monday, December 15, 2008 4:19 PM
> To: Multiple recipients of list
> Subject: Re: Scaling laws, and power usage
>
>
> This is an area that I have some experience in.  The discussion so far
> is mostly correct, to first order.  I don't want this to degrade into a
> discussion of semiconductor physics so I'll state a highly simplified
> model for the components of power consumption here, then try to relate
> that back to the main point in Robert's original post.
>
> Power dissipation in CMOS circuit technology (the most common technology
> at this time, and likely to be so for some time to come) consists of two
> parts: static and dynamic power.  Static power dissipation has for the
> past several years been largely irrelevant (and is often approximated as
> zero, as Ron has done); however, as feature sizes continue to scale down
> static power dissipation becomes an increasingly large fraction of total
> power dissipation.  Dynamic power dissipation is the component most
> people think about in CMOS circuits, and it is f*C*V^2, where f is the
> switching (clock) frequency, C is the load capacitance that a gate
> "sees", and V is the supply voltage.  C itself is ideally the
> capacitance on adjacent cell(s), which is proportional to the square of
> the feature size, and so does scale down with the square of linewidth
> reduction with advancing technology.  Thus, we've been accustomed to
> gaining exponential increases in circuit (functional) density with
> reductions in minimum feature size; simplistically this effect is
> responsible for Moore's law.
>
> However, we're now running into some fundamental physical limits: we
> haven't hit them yet but we're going to soon enough.  Supply voltages
> now are unable to scale down as quickly as linewidth.  Also, as I
> mentioned static power dissipation due to gate leakage and other effects
> is an increasing proportion of total consumption and doesn't scale as
> quickly.  Finally, while capacitance ideally scales down in each new
> technology node, the interconnect between circuit elements is not
> following that trend at the same rate, resulting in more dissipation
> than predicted by simple technology scaling.  This is why power
> dissipation has not kept pace with logic density.  Ultimate computing
> capacity is limited by the power density that the substrate can sustain.
> This in turn limits the maximum frequency and density that circuits can
> be designed for and therefore the maximum throughput (or minimum area).
>
> What does this mean for selecting a hash algorithm?  First, it is
> axiomatic that the algorithm ultimately selected must have sufficient
> security.  Without that, there is no reason to implement it, and its
> efficiency doesn't matter.  After that, it should be the most cost
> effective implementation that satisfies the security requirements.
> Simplistically, the cost of an implementation (in either dollars or
> watts) is proportional to the product of its implementation area and the
> speed that it operates at.  What I think Robert, and certainly people
> like me, would hope to find as a result of this competition is that the
> cost can be extremely low to justify use of the algorithm in very small
> implementations.  Costly implementation will have large area
> requirements (for example large intermediate states or static table
> spaces), or those that produce very small amounts of output per clock
> cycle.  An algorithm that can be predictably tuned in terms of the
> amount of security provided, the amount of space required, or the speed
> at which it generates its output will be the most flexible and useful in
> trading these aspects off, and therefore applicable across a range of
> applications.
>
> While I appreciate the importance of efficient software implementations
> that run in large CPU environments, most of the people I'm involved with
> don't deploy their solutions in those environments.  They have
> performance and cost constraints that simply don't fit.  As Robert
> noted, the devices they develop often interoperate with those large
> software environments.  User credentials are an example: these may take
> the form of smartcards or wirelessly powered RFID tags that authenticate
> their holders to central servers.  Individual users may be able to
> tolerate modest performance, but a server simultaneously authenticating
> thousands of those users needs to be capable of accomplishing that in a
> reasonable time.
>
> To give a concrete example, AES is very flexible in its definition and
> range of implementation possibilities.  It has scalable security that
> imposes a modest penalty to scale up the security.  The smallest
> hardware implementations are about 4K gates running at about 0.1 bits
> per cycle.  Small software implementations fit in a few hundreds bytes
> of code, and it runs acceptably in 8 bit processors, which are still
> today shockingly popular in new designs.  From there, it is possible
> today to scale the same algorithm up to a single implementation capable
> of 128 bits per cycle at, say, 500 MHz in about 300K gates.  That's a
> range from a few 10's or 100's of kilobits per second to about 64
> gigabits per second, and all at a security level of at least 128 bits.
> Instantaneous power consumption to accomplish this ranges from
> microwatts to a few watts, which as Bill notes is well down from what it
> was just a few years ago.  Neither of those extrema has a place in a CPU
> today nor for the forseeable future.  But note that we'll bottom out the
> gains we can make in traditional semiconductor technology in the next
> fewyears.  Any replacement technologies will face similar ultimate
> limits, some at admittedly much higher levels of performance, smaller
> volume requirements or lower power consumption.
>
> This is the kind of flexibility I would like to see in the ultimate hash
> competition selection.
>
> Best regards,
> Mike Borza
>
> On 15/12/08 01:58 PM, Bill Burr wrote:
>>
>> Ron & Bob,
>>
>> I don't claim any particular VLSI expertise, but my understanding is
>> that transistors only consume much power when they are actually
>> switching, that is P=I*V, and when a transistor is in the either the
>> on or the off state, either I or V is close to zero.  So when you
>> crank up the clock you almost always increase poser consumption.
>> Moreover you are charging and discharging capacitors more, and that
>> means current is flowing, and current flowing tends to mean power is
>> being consumed.    Also smaller transistors generally means lower
>> voltages, and smaller currents, while power is proportional to both
>> V^2 and I^2.  In principle I think you naturally  reduce power
>> consumption per  computation as you shrink dimensions, but of course,
>> you increase overall power consumption as you increase clock rates.
>>
>> Of course, as soon as you have to drive an external lead off the chip,
>> you're back to dealing with higher voltages, and more current.
>>
>> We know that power consumption per unit of computation has gone down
>> greatly as we've crammed more and more gates into less and less
>> area.   I just bought a little netbook with an Intel Atom processor.
>> It has a 1.6 GHz clock, and burns very little power, yet it's surely
>> computationally more powerful than the early Pentiums of not so long
>> ago, which ran hot enough to fry eggs.  Maybe reducing power
>> consumption hasn't kept pace with the exponent of Moore's Law for
>> semiconductors, but if power consumption is pretty much the limiting
>> factor today, then our ability to limit power consumption (or to carry
>> the heat away) must be largely the limiting factor in Moore's Law, at
>> least if you think of Moore's law in terms of computing power per
>> Dollar, I think.
>>
>> Regards,
>>
>> Bill
>>
>> Ronald L. Rivest wrote:
>>>
>>> Hi Bob --
>>>
>>> Good comments!
>>>
>>> With respect to scaling however, my understanding is
>>> that scaling *can* improve power usage.  If you
>>> decrease dimensions by a factor of two in both x and
>>> y dimensions, then all capacitances decrease by a factor
>>> of four, and power usage improves, since it takes less
>>> current to change the state of a capacitor.  This is
>>> assuming you don't also change the clock rate or voltage.  If
>>> you increase the frequency by a factor of four, you get
>>> the same current draw, but to increase frequency you
>>> need to increase voltage inside the chip to get things
>>> to happen faster.  So power usage tends to go up.
>>> Scaling is complicated, but the increased freedom of
>>> using smaller features on a chip can yield improved
>>> power usage, if you don't muck with the clock rate and/or
>>> voltage at the same time...
>>>
>>> (The above analysis is quite simplistic and naive; for the
>>> truth someone with stronger VLSI expertise should advise
>>> us...)
>>>
>>> Cheers,
>>> Ron
>>>
>>> On 12/15/2008 12:19 PM, Robert Jueneman wrote:
>>>> Ron and Bill,
>>>>
>>>> I don't have a dog in this fight, but I'd like to comment on the
> size
>>>> issue, since SPYRUS is involved in both the low-cost, low-power,
>>>> bandwidth-constrained smartcard end of the spectrum and the
> relatively
>>>> unconstrained HSM and/or host-based processing system at the other.
>>>>
>>>> For interoperability, it is essential that we have an efficient
>>>> algorithm that can run in both spaces.
>>>>
>>>> I also agree with the need for multi-purpose algorithms -- we were
> the
>>>> first and perhaps still one of the few organizations to use
> HASH_DRBG
>>>> from SP 800-90 for random number generation.  (Somehow, using AES to
>>>> generate keys to be used for AES seemed like putting too many eggs
> in
>>>> one basket, especially when you think about SPA and DPA attacks.)
>>>>
>>>> With regard to hashing vs. digital signatures on a chip, the issue
> is
>>>> more likely going to be bandwidth rather than processing power, as
>>>> smart
>>>> cards normally support only the IOS 7816 interface -- maybe 100 kbps
> at
>>>> best.  Our smart cards have no difficultly computing ECDSA, EC-DH,
> and
>>>> ECMQV for P-256, P-384, and P-521, and the code size constraint
> isn't
>>>> much of a limitation -- the code will fit comfortably into ROM or
>>>> EEPROM, as required.  But don't expect it to be done in a
> millisecond.
>>>>
>>>> In that regard, it is important to remember that although Moore's
> Law
>>>> predicts ever-increasing transistor density, and that generally
>>>> translates into increased speed and what I will call agility
>>>> (parallelism, redundant implementations, etc.), there is one thing
> that
>>>> Moore's law does NOT provide, and that is the increased power
> required
>>>> to operate these devices.  I'm certainly not a semi-conductor
>>>> physicist,
>>>> but I don't recall reading anything about reducing the power
>>>> required to
>>>> flip a bit in a transistor.  And the faster you want to do that, the
>>>> more electrical power it takes.
>>>>
>>>> So when you start talking about nano-processors, that is likely to
> be
>>>> the limiting factor.  And where that shows up in today's market is
> with
>>>> respect very low cost, very low power RFID chips.
>>>>
>>>> In that market, I expect that a keyed hash will continue to be very
>>>> important as an alternative to the slower digital signatures of
>>>> comparable strength.  Maybe not HMAC -- no disrespect to Hugo, but I
>>>> would like to see a keyed MAC algorithm devised that is less
>>>> computationally intensive -- but surely something along those lines.
>>>>
>>>> On the other hand, if we aren't talking about creating hashes and
>>>> digital signatures that will be sufficiently robust to resist
>>>> cryptanalytic attacks for hundreds of years or more, but only need
> to
>>>> survive a couple of years against modest attacker resources, then a
>>>> 512-bit algorithm may be overkill, and 128-bits may even be
> sufficient.
>>>>
>>>> I guess I'm arguing for algorithms with "knobs" that can be used to
>>>> easily tune the performance characteristics as required, while still
>>>> providing interoperability.
>>>>
>>>> Regards,
>>>>
>>>> Bob
>>>>
>>>> Robert R. Jueneman
>>>> Chief Scientist
>>>> SPYYRUS, Inc.
>>>>
>>>> -----Original Message-----
>>>> From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of
>>>> Ronald L. Rivest
>>>> Sent: Sunday, December 14, 2008 9:07 PM
>>>> To: Multiple recipients of list
>>>> Subject: Thoughts on SHA-3 potential applications, esp. for small
>>>> devices (LONG)
>>>>
>>>>
>>>> Hi Bill --
>>>>
>>>> I appreciate your thoughtful essays...
>>>>
>>>> There are indeed a lot of dimensions and tradeoffs to
>>>> consider for the SHA-3 competition.
>>>>
>>>> If we think about why one wants a hash standard, four
>>>> reasons come to mind (in no particular order):
>>>>
>>>>    (1) A standard promotes and facilitates _interoperability_
>>>>        between products produced by different organizations.
>>>>
>>>>    (2) A standard will have been thoroughly evaluated for
>>>>        cryptographic strength.
>>>>
>>>>    (3) A standard will be accompanied by a multitude of
>>>>        well-engineered and tested implementations for various
>>>>        platforms.
>>>>
>>>>    (4) A standard, by being a standard, facilitates decision-making
>>>>        by organizations that are too risk-averse and non-technical
>>>>        to make a decision in the absence of a standard.
>>>>
>>>> For a hash function, I suspect that the main use for
> interoperability
>>>> between products of different organizations will probably continue
>>>> to be as a component of digital signatures.
>>>>
>>>> I do wonder, as you do, what the real needs will be for
> cryptographic
>>>> primitives on various platforms, as time goes forward.  The future,
>>>> as usual, is not always predictable.
>>>>
>>>> The needs of very small devices are perhaps the most interesting
>>>> question to consider.
>>>>
>>>> Devices that are already sufficiently powerful to compute public-key
>>>> digital signatures are presumably going to be big enough to easily
>>>> accommodate any sort of reasonable hash function as well.
>>>>
>>>> I think that devices that are too small to perform a public-key
>>>> digital signature will frequently nonetheless have a requirement
>>>> to authenticate themselves---to perform a MAC.  (As you said.)
>>>>
>>>> But the requirements for MAC's are different (and in many ways
>>>> simpler) than those for hash functions.  We care about forgery
>>>> rather than collision resistance, MAC outputs can be shorter than
>>>> hash function outputs, etc.  I feel it would be a bit strange to
>>>> let the hash function competition be driven by the expectation
>>>> that, for small devices, there is a need to utilize the SHA-3
>>>> hash function to produce MAC's.
>>>>
>>>> If the world is going to be filled up with tiny devices that
>>>> need to authenticate themselves, then there is a clear need for
>>>> an appropriate MAC standard.  The SHA-3 competition was not set up
>>>> to produce such a standard; it merely noted that suitability for
>>>> use in HMAC was a SHA-3 requirement.  It would probably be a
>>>> mistake for the world to conclude that NIST feels that all small
>>>> devices should be using HMAC as an authentication technology,
>>>> when there are likely to be much better alternatives for small
>>>> devices.  (Perhaps down the road NIST would enjoy running a
>>>> "nano-MAC" standards competition!)
>>>>
>>>> I also suspect that in the world of very small devices, almost
>>>> all system designs will be proprietary and closed.  Think for
>>>> example of mass transit card systems or building access cards.
>>>> There is no need for small devices in these systems to work
>>>> "outside the system".  The need for interoperability through
>>>> an open standard is not wanted (indeed, it may be very much
>>>> undesired).  Thus, for very small devices the need for a standard
>>>> in order to support interoperability may be small or absent.
>>>>
>>>> Of course, there may be exceptions, and who knows what future
>>>> systems will need.
>>>>
>>>> But I find it hard to think of applications for hashing for
>>>> very small devices where:
>>>>     -- the device is too small for public-key operations
>>>>     -- the hash function is not being used for a MAC
>>>>
>>>> To see why, note that abstractly, a hash value is often used as
>>>> a "proxy" for the value being hashed.  Its shorter length may be
>>>> better suited for computation (as for a digital signature) or
>>>> for communication (e.g. for the hash of a message being transmitted
>>>> by a different channel, or at a different time).
>>>>
>>>> But very small devices don't have more than one communication
> channel,
>>>> and they don't have much storage, so applications that send a hash
>>>> value from a small device, so that it can later send the real
> message,
>>>> seem dubious (it requires storage).  Applications that send the hash
>>>> so that the real message can be sent via another channel may also be
>>>> rare, since the device doesn't have more than one channel.
>>>>
>>>> It isn't very clear to me what utility a "hash value as a proxy
>>>> for a message" philosophy has for very small devices.
>>>>
>>>> Finally, a hash value can be appended to a message for transmission,
>>>> but if one merely wants redundancy it can be done in better ways.
>>>> (Keyed redundancy is different, but that is what a MAC gives.)
>>>>
>>>> I suspect that the world will indeed be filled with lots of
>>>> fascinating small electronic devices, but I think that if they
>>>> do crypto, it will almost certainly be MAC's or digital signatures.
>>>> It is unlikely to be unkeyed hash function application.
>>>>
>>>> Perhaps I've overlooked something important, but I'm far from
>>>> persuaded that the SHA-3 standard will be very relevant for
>>>> very small devices, until you get up to size where the device
>>>> is capable of performing public-key digital signatures.  Then
>>>> it will become relevant.  But at that point, we've got fairly
>>>> substantial resources already devoted to doing crypto, and one
>>>> should be considering the digital signature operation as a whole;
>>>> the hash function implementation may be a small piece of that whole.
>>>>
>>>> And of course, Moore's Law hasn't quite died yet, and transistors
>>>> continue to shrink.  For small devices, at some point the cost of
>>>> bonding and packaging them should greatly exceed the cost of
>>>> producing the chip.  (Perhaps we are there already...)
>>>>
>>>> Perhaps others on this list have thoughts on how SHA-3 might
>>>> be useful on very small devices...
>>>>
>>>> These are good discussions to have, and I appreciate your
>>>> bringing these topics up in the hash-forum list.  I agree
>>>> with many of the points you brought up.
>>>>
>>>>
>>>> Cheers,
>>>> Ron Rivest
>>>>
>>>>
>>>> On 12/14/2008 3:18 PM, Bill Burr wrote:
>>>>> Bob,
>>>>>
>>>>> We're trying to listen to what everybody says, before forming
>>>>> NIST's opinion about the relative importance of micro-controllers
> with
>>>> limited
>>>>> memory, versus 1001 other trade-offs.  It's just too soon for us to
> do
>>>>
>>>>> that.
>>>>>
>>>>> In the end, we're going to want something that is a good substitute
>>>> for
>>>>> the SHA-2s in all of their major applications, but is significantly
>>>>> better than SHA-2 in some significant respects.  Unless the SHA-2s
>>>>> be "significantly" broken it's going to be very hard to force
>>>>> products to
>>>>
>>>>> change to SHA-3, or even implement SHA-3, if SHA-3 has few
> significant
>>>>
>>>>> practical advantages.
>>>>>
>>>>> To steal a phrase from Bruce Schneier's talk at the final AES
>>>>> conference, we're probably going to pick a SHA-3 that doesn't "suck
> at
>>>>
>>>>> anything," or at least anything apparently very significant.  And
>>>>> to pick a SHA-3 that is better than SHA-2 at several things.  I
>>>>> think we did about that when we selected Rijndael to be the AES,
>>>>> although TDES was easier to improve on than the SHA2's are. The
>>>>> SHA-2s, I think, set
>>>> a
>>>>> reasonably high bar.   It's worth remembering, in this respect,
>>>> however,
>>>>> that TDES is not without its virtues: it's pretty efficient in
>>>> hardware.
>>>>> I'll point one other related trade-off I think I see here.  The
> SHA-2s
>>>>
>>>>> give us two different pipe widths.  Is it better to do this, or
> have
>>>> one
>>>>> compromise pipe width for all 4 output sizes, that perhaps is a
> little
>>>>
>>>>> narrower than ideal for the 512-bit output?
>>>>> At this point it's not clear to me (as distinct from the rest of
>>>>> the folks in my group, who I haven't discussed this with very much
>>>>> at this
>>>>
>>>>> point)  that we often ask low-end micro controllers to generate
>>>>> collision free hashes.  I suppose that there will always be
>>>> applications
>>>>> for low end processors with very little RAM, but will those often
>>>>> require collision free hashes?  And we seem to get more and more
>>>>> powerful processors with more and more memory into smaller and
> smaller
>>>>
>>>>> packages.  It also seems to me that there are more efficient ways
>>>>> to address MACs in micro controllers, than HMAC.  So, if HMAC be
>>>>> the main
>>>>
>>>>> application for hash functions in micro controllers, then maybe low
>>>> end
>>>>> micro controllers would not be a major concern for SHA-3.  But I
>>>> remain
>>>>> open to arguments to the contrary.  And I'm pretty sure we'll wind
>>>>> up with several second round candidate algorithms with narrow-pipe
>>>> designs,
>>>>> as well as several wider pipe designs.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Bill Burr
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Bob Hattersley wrote:
>>>>>> A somewhat intemperate post perhaps, but there's an interesting
>>>>>> question in
>>>>>> there.  Waterfall would be a 6x design in this classification and
>>>>>> therefore
>>>>>> a "monster".  (Since I have no desire to make anyone ill, I
> recommend
>>>>
>>>>>> that
>>>>>> sensitive souls should avoid any further contact with it.)  I
>>>>>> worked under
>>>>>> the (possibly invalid) assumption that 512 bytes of RAM (and 2kB
>>>>>> of program
>>>>>> storage) was a reasonable target.  1kB RAM seems to be widely used
>>>> today,
>>>>>> and memory doesn't seem to be getting more expensive.  Most
>>>>>> microcontrollers
>>>>>> are not used in situations where cryptography has any relevance.
>>>>>>
>>>>>> But what is the general opinion?  Perhaps more important - what is
>>>> NIST's
>>>>>> view?
>>>>>>
>>>>>> Bob Hattersley (Waterfall)
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf
> Of
>>>> Sean
>>>>>> O'Neil
>>>>>> Sent: 13 December 2008 06:27
>>>>>> To: Multiple recipients of list
>>>>>> Subject: Narrow-pipe designs
>>>>>>
>>>>>>
>>>>>> A number of people are asking a good question:
>>>>>>
>>>>>> Can someone please publish a paper listing all the narrow-pipe
> hashes
>>>> as
>>>>>> broken by design, so we could all focus on the good ones with 2x
> and
>>>>>> slightly larger states?
>>>>>>
>>>>>> <2x is vulnerable by design, >=2x up to 2.5x (or possibly up to
> 3x)
>>>> is
>>>>>> the
>>>>>> optimal choice, but all the >=4x monsters and some of the designs
>>>> such as
>>>>>> Crunch or FSB with their reference code requiring MEGABYTES (!!!)
>>>>>> of tables
>>>>>> to function are certainly gone too far.  With all due respect to
>>>> their
>>>>>> authors, I wouldn't bother looking at those as
>>>>>> a total waste of time.
>>>>>>
>>>>>> Personally, the hash functions with 4x and larger states make me
>>>> wanna
>>>>>> puke,
>>>>>> but technically, they would simply never fit in 128 or
>>>>>> 256 bytes of RAM of the [yes, very] popular 8-bit microcontrollers
>>>>>> that may
>>>>>> want to use some of it for other purposes than merely storing the
>>>> entire
>>>>>> hash state with no room left for a single variable.
>>>>>>
>>>>>> Best regards,
>>>>>> Sean O'Neil
>>>>>> http://www.enrupt.com/ - Raising the bar.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.176 / Virus Database: 270.9.18/1850 - Release Date:
> 12/15/2008
> 5:04 PM
>
>
>
>
>




From hash-forum@nist.gov  Tue Dec 16 09:59:51 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBGHxixs027645
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Tue, 16 Dec 2008 09:59:47 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBGHx7Or013852;
	Tue, 16 Dec 2008 12:59:09 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBGHwlJt028519;
	Tue, 16 Dec 2008 12:58:47 -0500
Date: Tue, 16 Dec 2008 12:58:47 -0500
Message-Id: 
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: Stefan.Lucks@uni-weimar.de
To: Multiple recipients of list 
Subject: Re: How will NIST handle the tunable security parameter?
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: TEXT/PLAIN; charset=US-ASCII
MIME-Version: 1.0
References: <20081216075000.75654.qmail@cr.yp.to>  
In-Reply-To: 
X-To: Multiple recipients of list 
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 16 Dec 2008 09:59:47 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 396


On Tue, 16 Dec 2008, zooko wrote:

> By the way, I'm not accomplished at cryptanalysis, but Skein looks great to
> me.  I like the simple core function, the way that tweaks are used to separate
> some potential issues from others, the 64-bit efficiency with the recommended
> parameters, the height-bounded Merkle Tree construction, and the small amount
> of state required.  

Thank you!

> I'm a bit disappointed at the 32-bit efficiency with the
> recommended parameters because, as I've mentioned, I anticipate 32-bit
> environments being an interesting target for me in the future, but maybe if
> Skein is successful in the contest then something could be done about that.

I anticipate Skein to perform quite well on most 32-bit architectures with 
a reasonably large register file. The well-known 32-bit Intel-architecture 
has a bit too few registers. Remember, Skein just uses 64-bit addition, 
64-bit xor, and 64-bit rotation. The first two can be implemented using 
just two 32-bit operations. Implementing 64-bit rotations on 32-bit 
machines isn't too costly, as well.

So long

Stefan

-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------


From hash-forum@NIST.GOV  Tue Dec 16 10:42:32 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBGIgOSq003225
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Tue, 16 Dec 2008 10:42:26 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBGIfdtT006625;
	Tue, 16 Dec 2008 13:41:40 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBGIfMgi017440;
	Tue, 16 Dec 2008 13:41:22 -0500
Date: Tue, 16 Dec 2008 13:41:22 -0500
Message-Id: <5574ACE4ACD88E45A7026FA0E350334B039F8A@cleopatra.spyrus.com>
Errors-To: sara@NIST.GOV
Reply-To: hash-forum@NIST.GOV
Originator: hash-forum@nist.gov
Sender: hash-forum@NIST.GOV
Precedence: bulk
From: "Robert Jueneman" 
To: Multiple recipients of list 
Subject: RE: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Transfer-Encoding: 8bit
X-To: 
References: <20081215100903.52177.qmail@cr.yp.to> <49467AB0.1070505@nist.gov> <20081216121512.98842mlo86zr0un4@webmail.nist.gov>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 16 Dec 2008 10:42:26 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: Junk            
X-UID: 397


Hi, John, 

When I was talking about tuning algorithms for performance vs. security,
I had in mind two different scenarios.

In scenario 1, the strength of the algorithm only needs to be such as to
last for the next decade or so.  Such a case would be a certificate that
is used to authenticate a user's computer logon credentials, when that
certificate is going to expire in three years in any case.  SHA-1 is
probably in that category today, although that may not be the case
forever. This class of algorithm/parameters may also suffice for RFID
and similar applications, like fare-cards and toll collections, at least
for the expected life of such systems.

In scenario 2, the strength of the algorithm should be such that we
believe it will last "forever," at least based on our current level of
understanding.  Continuing the digital signature example, this would be
for public documents that may be of interest for hundreds or even
thousands of years.  For such cases, robustness that would require
exhausting "the number of atoms in the universe" or "the entire output
of the Sun for a million years" may not be too great (assuming that
those hash functions don't have to be carried out in a microsecond on an
8-bit processor!)

Now I'll admit that this approach only allows two possibilities -- one
sublime, and one ridiculous, depending on your market.  So maybe we need
a "1, 2, 3, infinity" approach, where "infinity" represents the best we
can imagine without being completely ridiculous, and the lower end
numbers represent the current best guess in terms of decades of
resistance for some reasonably well-defined adversarial threat.

NIST currently has guidelines for key sizes that come in three flavors
-- good until 2010, good until 2030, and "beyond 2030".

I would like to see guidelines along the lines of 10, 20, 50 100, and
"forever" -- at least 500 years from now.

There is absolutely no point in signing a logon certificate that expires
in three years with a 500-year algorithm, but on the other hand, we
shouldn't be signing important public documents with algorithms that
might be breakable in 20 years.

>From that perspective, NIST could provide a real service by coming to
some consensus about the threat model.  How much time-memory tradeoffs,
etc., do we expect to be available, even at the highly sophisticated
nation-state level, in the next 10, 20, 50, and 100 years?

If we could answer that question, which really shouldn't be that hard,
then the designers would have a common ground for their evaluations of
how much overkill to build in to their algorithms.

Bob


-----Original Message-----
From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Behalf Of John
Kelsey
Sent: Tuesday, December 16, 2008 9:26 AM
To: Multiple recipients of list
Subject: Re: Engineering comparison of the SHA-3 candidates


Just a couple of meandering thoughts about the security parameter:

It seems to me that there are two important issues being discussed  
here, w.r.t. the tunable parameters in the algorithms.  The tunable  
parameters involve a tradeoff between performance and security. You  
can see the recommended tunable parameters as encoding two pieces of  
information:

a.  The designer's understanding of the security of his own algorithm

b.  The designer's preferred tradeoff between security and  
performance, in particular how much overdesign he thinks is  
appropriate.  (If your best known attack is 10 rounds, do you  
recommend 12 rounds, or 20, or 40?)

The designer's recommended parameter can basically go wrong in two ways:

First Issue:  What if you've set the parameters too low, so that you  
get attacked?

Now, I understand the desire to want to be able to tweak the  
parameters toward more security when you see an attack.  But honestly,  
we're trying to evaluate 51 submissions!  If the response to an attack  
is always "I can add some rounds to make it secure," then no  
algorithms will ever be removed from the competition by cryptanalysis.  
  Once you allow tweaking of parameters and algorithms to overcome an  
attack, you can always recover from attacks.  Even the hashes  
vulnerable to length-extension attacks or similar stuff can be tweaked  
to be resistant, usually with minimal effort.  How does this ever end?  
  The result of this would be that we divide cryptanalysis effort  
among 51 algorithms until NIST does the first cut and narrows them  
down to 15 or so, which means that the most promising algorithms don't  
get as much analysis, so that we can keep adding rounds to attacks  
that have already been published.

Imagine applying this to the AES process.  Instead of getting several  
of the designs knocked off by attacks, we would have had none knocked  
off.  Cryptanalysis would have been only about forcing changes in the  
parameters.  I have a hard time seeing that this would have led to a  
better outcome.  (I'll admit that I think the AES process did a pretty  
good job of selecting finalists and a winner--I was one of the  
submitters of a finalist, and now I work for NIST, so take my opinion  
here with as many grains of salt as you like.)

In terms of evaluating the security of an algorithm, your choices are  
basically cryptanalysis and the intuition of the reviewers after  
reading the documentation.  If we don't ever remove algorithms because  
of cryptanalysis (because we just let the designers change  
parameters), then either we remove algorithms on the basis of our  
intuition, or we don't remove algorithms from consideration for  
security problems, only for performance problems.  (And see below!) I  
just can't see this working out.  It needs to be possible for  
submissions to be broken and removed from the competition, even when  
it wouldn't be hard to fix them.

One good justification for this is that we expect the designer to have  
seriously thought about the security of their algorithm, and to have  
worked out the best likely attacks, in the months during which they  
were writing their submission, with far more precision and detail than  
outsiders will be able to get in a month or so of looking at them.  If  
the submission gets broken at the recommended parameter set,  
especially early in the competition, this undermines confidence that  
the designer understood the security of his own design.  (Of course,  
some attacks exploit a small oversight that doesn't indicate a broader  
problem with the designer's analysis of his own design--there are no  
perfect mechanisms for selecting finalists or a winner available to us.)

Second Issue: What if you've set the parameters too high, so that you  
get smoked on all the performance measurements?

This seems like a pretty different situation, to me.  For one thing,  
performance is easy to measure (much easier than security), so if you  
have a design that allows trading off security margin for performance,  
you can kind-of do it later, and you can have confidence that you  
understand at least the performance gain.

For another, while it probably makes sense to remove algorithms where  
the designer didn't understand their security, it doesn't make sense  
to remove algorithms whose designers just wanted a different  
performance/security tradeoff.  That doesn't cast any doubt on the  
ultimate soundness of the algorithm, it's just an engineering tradeoff.

The downside of this is that it benefits algorithms that have chosen  
very conservative parameters, because they're unlikely to be broken  
and removed from the competition, but they may be permitted to tweak  
their parameters toward more performance later.

As an attacker, I like having a meaningful target.  It's sort-of  
disspiriting to be attacking a cipher with 32 rounds, and the best  
attack you've got can get through 10.  If the target were 12 or 14  
rounds, I might keep digging till I got through the extra rounds.

For cryptanalysts, I think a couple performance points might be  
interesting to look at, outside of the stated parameters from the  
designer:

a.  Approximately equal performance to SHA256 on the reference platform.

b.  Approximately equal performance to some of the fastest of the  
currently-unbroken designs on the reference platform.

Those aren't going to look like breaks of an algorithm, but they give  
you a meaningful target to shoot for--if you break a variant of MD6  
with small enough number of rounds that it would be one of the fastest  
unbroken algorithms, you've accomplished something ineresting, even if  
it doesn't break the algorithm.  (I'm using MD6 as an example because  
it's visible, not because I have any notion of how to attack it.)

--John Kelsey, NIST




From hash-forum@nist.gov  Tue Dec 16 12:20:26 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBGKKIlp017858
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Tue, 16 Dec 2008 12:20:20 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBGKJfib016105;
	Tue, 16 Dec 2008 15:19:44 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBGKJP8M022090;
	Tue, 16 Dec 2008 15:19:25 -0500
Date: Tue, 16 Dec 2008 15:19:25 -0500
Message-Id: <94031609-D501-4220-B2DB-3339D3905955@zooko.com>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: zooko 
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Mailer: Apple Mail (2.753.1)
X-To: hash-forum@nist.gov
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
References: <20081215100903.52177.qmail@cr.yp.to> <49467AB0.1070505@nist.gov> <20081216121512.98842mlo86zr0un4@webmail.nist.gov>
In-Reply-To: <20081216121512.98842mlo86zr0un4@webmail.nist.gov>
Mime-Version: 1.0 (Apple Message framework v753.1)
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 16 Dec 2008 12:20:20 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 398


On Dec 16, 2008, at 10:26 AM, John Kelsey wrote:

> But honestly, we're trying to evaluate 51 submissions!  If the  
> response to an attack is always "I can add some rounds to make it  
> secure," then no algorithms will ever be removed from the  
> competition by cryptanalysis.

This is an important point.  The goal is to find a good algorithm  
with limited resources, and excluding weak candidates from further  
consideration is necessary for that goal.

Practically speaking, the only one at issue so far is EnRUPT, right?   
The other algorithms which have been attacked are either not improved  
simply by adding rounds (Boole), or would, after that kind of  
improvement, clearly land below the '"Good" algorithms" section of  
Niels's "Engineering Comparison" table [1].

However, EnRUPT64x2/H would still land in the '"Good" algorithms"  
section of Niels's table.  Its efficiency in CPU cycles is about in  
the middle of that group.  It requires minimal RAM and can be can be  
realized very efficiently in 8-bit, FPGA, and ASIC.  Its design is  
very simple, and it offers many of the "features" that Niels's table  
mentions such as PRNG, stream cipher, and MAC.

Now, I don't think that EnRUPT64x2/H is the leading candidate at this  
point, but it might be in the top 15.

When the time comes for NIST to name 15 algorithms to proceed to the  
next stage, if that set consists almost entirely of algorithms which  
are better than EnRUPT64x2/H in some way, then that would be great.   
If it contains algorithms which, compared to EnRUPT64x2/H, require  
more CPU cycles, RAM, and time, are more expensive to implement in  
hardware, and are more likely to be insecure, then that would be  
disappointing.

Regards,

Zooko

[1] http://skein-hash.info/sha3-engineering
---
http://allmydata.org -- Tahoe, the Least-Authority Filesystem
http://allmydata.com -- back up all your files for $10/month

From hash-forum@nist.gov  Tue Dec 16 15:24:32 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBGNOOIL005697
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Tue, 16 Dec 2008 15:24:25 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBGNNZnX023416;
	Tue, 16 Dec 2008 18:23:36 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBGNNFQm032165;
	Tue, 16 Dec 2008 18:23:15 -0500
Date: Tue, 16 Dec 2008 18:23:15 -0500
Message-Id: 
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "Rade Vuckovac" 
To: Multiple recipients of list 
Subject: Re: SHA-3 First Round Submissions.
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
References: <49400E39.4090702@nist.gov>  <49457E1F.9070401@nist.gov>
Content-Type: multipart/mixed;  boundary="----=_Part_63385_735360.1229469659705"
MIME-Version: 1.0
In-Reply-To: <49457E1F.9070401@nist.gov>
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 16 Dec 2008 15:24:26 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,GMD_PDF_HORIZ,
	HTML_MESSAGE,RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 399


------=_Part_63385_735360.1229469659705
Content-Type: multipart/alternative; 
	boundary="----=_Part_63386_3389234.1229469659705"

------=_Part_63386_3389234.1229469659705
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Statements like "we're not trying to pick the best written specification
here; we're trying to pick the best hash algorithm" and "we're running an
algorithm competition, not selecting papers for journal publication" are not
in accord with way of how 13 submissions are rejected (64-51).

To illustrate the issue there is a submission (see attached) which received
this reasoning for rejection "Your submission had a number of deficiencies.
However, the main reason for rejection is that we could not understand key
elements of your submission. More specifically, we could not understand the
relation between the various references to chaotic systems and the purported
security of your design".

The submission in question certainly looks like crackpot job, but also may
provide interesting reading and constructive approach to random oracle issue
(which majority if not all submissions do not). But that is beside the point
because above rejection reasoning are based on the form not on the
substance, apparently.

Regards

Rade





On Mon, Dec 15, 2008 at 7:54 AM, Bill Burr  wrote:

> Larry Bassham, who has been compiling and running the code provided with
> the SHA-3 submissions, will contact the submitters where he has a problem
> with the code, and attempt to resolve any problems.
>
> We don't plan at this time to do the same thing with the specifications.
> There were a number of very well written, highly professional submissions,
> and we expect that many of the second round candidates will come from such
> submissions.  But we're not trying to pick the best written specification
> here; we're trying to pick the best hash algorithm.  We're also mindful that
> many submitters are not writing in their native language, and we're running
> an algorithm competition, not selecting papers for journal publication.
>
> We're not going to try to bring all 51 first round candidates to some
> consistent editorial level.  The real proof of the pudding on the
> specifications is the ability to independently implement the algorithm and
> get the right outputs.  We're not going to have time to try that for all the
> submissions before we select the second round candidates.  Where we find
> documentation problems that present real problems to us, we may consult with
> the submitters to get a revised specification that clarifies some point
> we're having problems with.
>
> Still, in a competition of this sort, a clear, well written specification
> is going to be an advantage. When two submissions seem otherwise to be
> roughly comparable, and we have to choose between them, but one is very
> clearly written, and the other is a bit confusing, the writing could tip the
> scale.
>
> At the next stage, we're going to pick about 15 submissions that we like
> best, that interest us.  We intend that the 15 second round candidates
> should all have good specifications, so if we ask for specification
> clarifications or edits, that may be a sign of interest.  We're not likely
> to ask for clarifications and editing on a specification for an algorithm
> that seems generally uninteresting to us.
>
> We intend to consider all the data we have available to us to make the
> second round selection.  That includes the eBASH performance data.  If
> implementers (or others) want to add some improved code they may do so, but
> the sooner, the better (we can't promise to compile and run everything we
> get before we make the selections for the next round if it comes in too
> late).  We do not intend to make our second round selections primarily on
> the basis of performance data, so minor code tuning may not have a big
> payback at this point.  But, if a major feature of a proposal is how
> efficient an algorithm is with some vector instruction set, or on a
> lightweight processor, or something like that, some additional measured
> performance data might be useful.    If an algorithm appears to have
> inferior performance on some significant platform, data that shows it
> actually pretty good if well implemented could also help.
>
> Additional implementations may be provided to Larry Bassham <
> lbassham@nist.gov>.  These, and the updates he requests from submitters,
> will be put on the "submissions" page.
>
> Regards,
>
> Bill Burr
>
>
> Bob Hattersley wrote:
>
> I have two questions:
>
> Will NIST let the accepted submitters know (perhaps privately) what
> specific problems they found with the quality of documentation or code, so
> that these can be improved for everyone's benefit?
>
> I have succeeded in cutting the number of cycles per byte by 40% on the
> 32-bit platform by coding the main loop in inline assembler.  Is NIST
> interested in implementations other than pure C, how will they be taken into
> account, and what is the process for submitting such additional
> implementations?
>
> Thanks,
>
> Bob Hattersley (Waterfall)
> Opta Consulting Ltd.
>
>  ------------------------------
> *From:* hash-forum@nist.gov [mailto:hash-forum@nist.gov]
> *On Behalf Of *Bill Burr
> *Sent:* 10 December 2008 18:49
> *To:* Multiple recipients of list
> *Subject:* SHA-3 First Round Submissions.
>
> NIST received 64 SHA-3 candidate hash function submissions.  Overall, NIST
> is very pleased with the obvious high quality of many of the submissions, as
> well as the general range of designs.  NIST has accepted 51 first round
> candidates as meeting our minimum acceptance criteria.  They are now
> posted on the NIST website:
> .
> To make an "official" comment on one of the algorithms please use the
> "submit comments" link on this page for the appropriate algorithm.  Such
> comments will also be forwarded to hash-forum@nist.gov.  Continue to post
> general comments about the competition at hash-forum@nist.gov.
>
>
> We will review these first round candidates at the first SHA-3 Candidate
> Conference on February 25-28, 2009 at Leuven.  During the summer of 2009
> we plan to select about 15 second round candidates for more focused review
> at the Second SHA-3 Candidate Conference, tentatively scheduled for August,
> 2010.  Following that second conference we expect to select about 5 third
> round candidates (or "finalists").  At our third conference we will review
> the finalists and select a winner shortly thereafter.  At each stage we
> will do our best to explain our choices.
>
> The Federal Register announcement specified minimum acceptability
> requirements for "complete and proper submissions."  These requirements
> included provisions for reference and optimized C code implementations,
> known answer tests, a written specification and required intellectual
> property statements.
>
> We asked for reference code and optimized 32 and 64-bit code. Some
> submissions did not include optimized implementations, so we will use the
> performance results from the reference implementations in our future
> deliberations.  Some submissions were rejected because C code was not
> provided.  NIST specified a specific API for the C code, and a few
> submissions did not use that API: these submissions were also rejected.  In
> some cases, we made a number of minor corrections to the submitted code
> (largely in the include statements) in order to allow it to compile and run,
> but made no major repairs.
>
> NIST attempted to verify that the submitted C programs gave outputs that
> corresponded to the submitted known answer test results when compiled and
> run on our reference platform.  In several cases there were discrepancies
> between the known answer test results NIST got on our reference platform,
> and the known answer test results provided by the submitters.  NIST will
> notify those submitters, and these discrepancies must be resolved in a
> timely manner if the submission is to be eligible to become a second round
> candidate.
>
> We also asked for documentation, including a complete specification of the
> algorithms, known answer test results, a performance analysis on different
> platforms and a security analysis.  The quality of the submitted
> documentation varied greatly.  For the security and performance analyses,
> we were very liberal in what we accepted.  We had difficulty determining
> that the algorithm specifications were complete in some cases.  In some of
> these cases necessary information, such as initial values or padding rules,
> were omitted from otherwise well-written specifications, but we were able to
> easily determine this information from the code; these specifications were
> considered acceptable, since independent implementers can find what they
> need and the specification can be easily fixed.  Some written
> specifications were incomprehensible without a careful examination of the C
> code; the more extreme cases were rejected.  Inevitably, there were cases
> between the two extremes. There were several submissions which we accepted
> that  required us to rely more on the programming code for clear
> understanding than we liked.
>
> We expect that the algorithms selected as the SHA-3 finalists will have
> specifications that will allow independent implementers to program or design
> hardware that will produce results that match those provided by the
> submitters for the known answer tests.  In the AES competition, Brian
> Gladman and others provided independent implementations of all the
> finalists.  Marginal, hard to follow specifications may affect whether a
> submission is selected for the second round.
>
> We reviewed the intellectual property statements for all of the
> submissions. While there remain minor issues in some of the statements, we
> believe that all the accepted submissions include IP statements that allow
> us to continue the evaluation process for those submissions for now.  However,
> any IP statement issues must be fully resolved before a candidate can
> progress to be a second round candidate.
>
> Many of the accepted submissions have been posted on the SHA-3 Zoo site for
> some time, and a number have been analyzed and are claimed to be "broken."
> In some cases, the submitters have conceded the break. In other cases, the
> submitters concede the break, but claim that it can be fixed with trivial
> changes (e.g. by adding a few rounds). In still other cases, it appears that
> the breaks are fundamental and cannot be fixed without extensive
> modifications.  NIST does not want to spend time in the upcoming SHA-3
> conference on accepted, but broken algorithms, unless the break is disputed,
> or the fix is truly trivial.  On the other hand, there has been
> considerable discussion about what is considered to be a break, and we
> expect to continue that discussion in Leuven.  We also expect to discuss
> allowing submitters to use their "tunable parameter" to make changes to
> their algorithm before the second round candidates are chosen.
> We will continue to consider submissions where there is a dispute about
> whether the submission is in fact broken until we can make a determination
> about the facts of the case.
>
> Regards,
>
> Bill Burr
>
> --
> William E. Burr
> Manager, Security Technology Group
> NIST
> 100 Bureau Dr., MS 8931
> Gaithersburg, MD. 20899
> Bldg. 222, Rm B362
> Tel: 301-975-2914
> Fax: 301-975-8670
>
>
>
> --
> William E. Burr
> Manager, Security Technology Group
> NIST
> 100 Bureau Dr., MS 8931
> Gaithersburg, MD. 20899
> Bldg. 222, Rm B362
> Tel: 301-975-2914
> Fax: 301-975-8670
>
>

------=_Part_63386_3389234.1229469659705
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


Statements like "we're not trying to pick the best written specif=
ication here; we're trying to pick the best hash algorithm" and "=
we're running an algorithm competition, not selecting papers for journal pu=
blication" are not in accord with way of how 13 submissions are reject=
ed (64-51).



 


To illustrate the issue there is a submission (see attached)=
 which received this reasoning for rejection "Your submission had a number of deficiencies. However, the =
main reason for rejection is that we could not understand key elements of y=
our submission. More specifically, we could not understand the relation bet=
ween the various references to chaotic systems and the purported security o=
f your design".



 


The submission in question certainl=
y looks like crackpot job, but also may provide interesting reading and con=
structive approach to random oracle issue (which majority if not all submis=
sions do not). But that is beside the point because above rejection reasoni=
ng are based on the form not on the substance, apparently. 



 


Regards


 


Rade


 


 


 






On Mon, Dec 15, 2008 at 7:54 AM, Bill Burr <william.burr@nist=
gov> wrote:




Larry Bassham, who has been compi=
ling and running the code provided with the SHA-3 submissions, will contact=
 the submitters where he has a problem with the code, and attempt to resolv=
e any problems.


We don't plan at this time to do the same thing with the specifications=
  There were a number of very well written, highly professional submi=
ssions, and we expect that many of the second round candidates will come fr=
om such submissions.  But we're not trying to pick the best written sp=
ecification here; we're trying to pick the best hash algorithm.  We're=
 also mindful that many submitters are not writing in their native language=
, and we're running an algorithm competition, not selecting papers for jour=
nal publication.  


We're not going to try to bring all 51 first round candidates to some c=
onsistent editorial level.  The real proof of the pudding on the speci=
fications is the ability to independently implement the algorithm and get t=
he right outputs.  We're not going to have time to try that for all th=
e submissions before we select the second round candidates.  Where we =
find documentation problems that present real problems to us, we may consul=
t with the submitters to get a revised specification that clarifies some po=
int we're having problems with.


Still, in a competition of this sort, a clear, well written specificati=
on is going to be an advantage. When two submissions seem otherwise to be r=
oughly comparable, and we have to choose between them, but one is very clea=
rly written, and the other is a bit confusing, the writing could tip the sc=
ale.  


At the next stage, we're going to pick about 15 submissions that we lik=
e best, that interest us.  We intend that the 15 second round candidat=
es should all have good specifications, so if we ask for specification clar=
ifications or edits, that may be a sign of interest.  We're not likely=
 to ask for clarifications and editing on a specification for an algorithm =
that seems generally uninteresting to us.


We intend to consider all the data we have available to us to make the =
second round selection.  That includes the eBASH performance data.&nbs=
p; If implementers (or others) want to add some improved code they may do s=
o, but the sooner, the better (we can't promise to compile and run everythi=
ng we get before we make the selections for the next round if it comes in t=
oo late).  We do not intend to make our second round selections primar=
ily on the basis of performance data, so minor code tuning may not have a b=
ig payback at this point.  But, if a major feature of a proposal is ho=
w efficient an algorithm is with some vector instruction set, or on a light=
weight processor, or something like that, some additional measured performa=
nce data might be useful.    If an algorithm appears to have=
 inferior performance on some significant platform, data that shows it actu=
ally pretty good if well implemented could also help.


Additional implementations may be provided to Larry Bassham < lbassham@nist.gov>.=
  These, and the updates he requests from submitters, will be put on t=
he "submissions" page.


Regards,

Bill Burr=20







Bob Hattersley wrote:=20



I have two questions:


 


Will NIST let the accepted submitters know (perhaps =
privately) what specific problems they found with the quality of documentat=
ion or code, so that these can be improved for everyone's benefit?



 


I have succeeded in cutting the number of cycles per byte by 4=
0% on the 32-bit platform by coding the main loop in inline assembler. =
; Is NIST interested in implementations other than pure C, how will th=
ey be taken into account, and what is the process for submitting such addit=
ional implementations?



 


Thanks,


 


Bob Hattersley (Waterfall)


Opta Consulting Ltd.


 





From: hash-forum@nist.gov [mailto:hash-forum@nist.gov] On Be=
half Of Bill Burr

Sent: 10 December 2008 18:49
To: Multiple recipients of li=
st
Subject: SHA-3 First Round Submissions.



NIST received 64 SHA-3 candidate hash function submissions.  =
Overall, NIST is very pleased with the obvious high quality of many =
of the submissions, as well as the general range of designs.  NIST has accepted 51 first round candidates as meeting our minimum acc=
eptance criteria.  They are now posted on the NIST websit=
e: <http://csrc.nist.gov/groups/ST/hash/sha-3/R=
ound1/submissions_rnd1.html>. To make an "official" commen=
t on one of the algorithms please use the "submit comments" link =
on this page for the appropriate algorithm.  Such comments will also b=
e forwarded to has=
h-forum@nist.gov.  Continue to post general comments about the com=
petition at hash-f=
orum@nist.gov.





We will review these first round candidates at the first SHA-3 Candi=
date Conference on February 25-28, 2009 at Leuven.  Durin=
g the summer of 2009 we plan to select about 15 second round candidates for=
 more focused review at the Second SHA-3 Candidate Conference, tentatively =
scheduled for August, 2010.  Following that second confer=
ence we expect to select about 5 third round candidates (or "finalists").  At our third conference we will review the finalists and =
select a winner shortly thereafter.  At each stage we wil=
l do our best to explain our choices.



The Federal Register announcement specified minimum acceptability requir=
ements for "complete and proper submissions."  These requ=
irements included provisions for reference and optimized C code implementat=
ions, known answer tests, a written specification and required intellectual=
 property statements.    



We asked for reference code and optimized 32 and 64-bit code. Some submi=
ssions did not include optimized implementations, so we will use the perfor=
mance results from the reference implementations in our future deliberation=
s.  Some submissions were rejected because C code was not=
 provided.  NIST specified a specific API for the C code,=
 and a few submissions did not use that API: these submissions were also re=
jected.  In some cases, we made a number of minor correct=
ions to the submitted code (largely in the include statements) in order to =
allow it to compile and run, but made no major repairs.  =
 



NIST attempted to verify that the submitted C programs gave outputs that=
 corresponded to the submitted known answer test results when compiled and =
run on our reference platform.  In several cases there we=
re discrepancies between the known answer test results NIST got on our refe=
rence platform, and the known answer test results provided by the submitter=
s.  NIST will notify those submitters, and these discrepa=
ncies must be resolved in a timely manner if the submission is to be eligib=
le to become a second round candidate.



We also asked for documentation, including a complete specification of t=
he algorithms, known answer test results, a performance analysis on differe=
nt platforms and a security analysis.  The quality of the=
 submitted documentation varied greatly.  For the securit=
y and performance analyses, we were very liberal in what we accepted.=
  We had difficulty determining that the algorithm specificatio=
ns were complete in some cases.  In some of these cases n=
ecessary information, such as initial values or padding rules, were omitted=
 from otherwise well-written specifications, but we were able to easily det=
ermine this information from the code; these specifications were considered=
 acceptable, since independent implementers can find what they need and the=
 specification can be easily fixed.  Some written specifi=
cations were incomprehensible without a careful examination of the C code; =
the more extreme cases were rejected.  Inevitably, there =
were cases between the two extremes. There were several submissions which w=
e accepted that  required us to rely more on the programm=
ing code for clear understanding than we liked.



We expect that the algorithms selected as the SHA-3 finalists will have =
specifications that will allow independent implementers to program or desig=
n hardware that will produce results that match those provided by the submi=
tters for the known answer tests.  In the AES competition=
, Brian Gladman and others provided independent implementations of all the =
finalists.  Marginal, hard to follow specifications may a=
ffect whether a submission is selected for the second round. 



We reviewed the intellectual property statements for all of the submissi=
ons. While there remain minor issues in some of the statements, we believe =
that all the accepted submissions include IP statements that allow us to co=
ntinue the evaluation process for those submissions for now.  However, any IP statement issues must be fully resolved before a candi=
date can progress to be a second round candidate. 



Many of the accepted submissions have been posted on the SHA-3 Zoo site =
for some time, and a number have been analyzed and are claimed to be "broke=
n."  In some cases, the submitters have conceded the brea=
k. In other cases, the submitters concede the break, but claim that it can =
be fixed with trivial changes (e.g. by adding a few rounds). In still other=
 cases, it appears that the breaks are fundamental and cannot be fixed with=
out extensive modifications.  NIST does not want to spend=
 time in the upcoming SHA-3 conference on accepted, but broken algorithms, =
unless the break is disputed, or the fix is truly trivial.  On the other hand, there has been considerable discussion about what is =
considered to be a break, and we expect to continue that discussion in Leuv=
en.  We also expect to discuss allowing submitters to use=
 their "tunable parameter" to make changes to their algorithm before the se=
cond round candidates are chosen. 

We =
will continue to consider submissions where there is a dispute about whethe=
r the submission is in fact broken until we can make a determination about =
the facts of the case.


Regards,

Bill Burr
--=20
William E. Burr
Manager, Security Technology Group
NIST
100 Bureau Dr., MS 8931
Gaithersburg, MD. 20899
Bldg. 222, Rm B362
Tel: 301-975-2914
Fax: 301-975-8670
  

--=20
William E. Burr
Manager, Security Technology Group
NIST
100 Bureau Dr., MS 8931
Gaithersburg, MD. 20899
Bldg. 222, Rm B362
Tel: 301-975-2914
Fax: 301-975-8670




------=_Part_63386_3389234.1229469659705--

------=_Part_63385_735360.1229469659705
Content-Type: text/richtext; name=shahaha.h
Content-Transfer-Encoding: base64
X-Attachment-Id: f_fot60hxm0
Content-Disposition: attachment; filename=shahaha.h

e1xydGYxXGFuc2lcZGVmZjBcZGVmdGFiNzIwe1xmb250dGJse1xmMFxmbW9kZXJuIENvdXJpZXIg
TmV3O319DQp7XGNvbG9ydGJsXHJlZDBcZ3JlZW4xMjhcYmx1ZTA7XHJlZDBcZ3JlZW4wXGJsdWUw
O1xyZWQyNTVcZ3JlZW4yNTVcYmx1ZTI1NTtccmVkMjU1XGdyZWVuMjU1XGJsdWUyNTU7XHJlZDE3
OFxncmVlbjE4MFxibHVlMTkxO1xyZWQxMjhcZ3JlZW4wXGJsdWUxMjg7fQ0Ke1xpbmZve1xjb21t
ZW50IEdlbmVyYXRlZCBieSB0aGUgU3luRWRpdCBSVEYgZXhwb3J0ZXJ9DQp7XHRpdGxlIFVudGl0
bGVkfX0NCg0KXGRlZmxhbmcxMDMzXHBhcmRccGxhaW5cZjBcZnMyMCBcY2YwICNpbmNsdWRlIDxz
dGRpbnQuaD4NClxwYXIgDQpccGFyIFxjZjFcYiB0eXBlZGVmXGIwXGNiMiAgXGNiM1xiIHVuc2ln
bmVkXGIwXGNiMiAgXGNiM1xiIGNoYXJcYjBcY2IyICBcY2IzIEJpdFNlcXVlbmNlOw0KXHBhciBc
YiB0eXBlZGVmXGIwXGNiMiAgXGNiM1xiIHVuc2lnbmVkXGIwXGNiMiAgXGNiM1xiIGxvbmdcYjBc
Y2IyICBcY2IzXGIgbG9uZ1xiMFxjYjIgIFxjYjMgRGF0YUxlbmd0aDtcY2IyICAgXGNiM1xjZjRc
aSAvLyBhIHR5cGljYWwgNjQtYml0IHZhbHVlIA0KXHBhciBcaTBcY2YxXGIgdHlwZWRlZlxiMFxj
YjIgIFxjYjNcYiBlbnVtXGIwXGNiMiAgXGNiMyBce1xjYjIgIFxjYjMgU1VDQ0VTU1xjYjIgIFxj
YjMgPVxjYjIgIFxjYjNcY2Y1IDBcY2YxICxcY2IyICBcY2IzIEZBSUxcY2IyICBcY2IzID1cY2Iy
ICBcY2IzXGNmNSAxXGNmMSAsXGNiMiAgXGNiMyBCQURfSEFTSEJJVExFTlxjYjIgIFxjYjMgPVxj
YjIgIFxjYjNcY2Y1IDJcY2IyXGNmMSAgXGNiMyBcfVxjYjIgIFxjYjMgSGFzaFJldHVybjtcY2Iy
ICANClxwYXIgDQpccGFyIFxjYjNcYiB0eXBlZGVmXGIwXGNiMiAgXGNiM1xiIHN0cnVjdFxiMFxj
YjIgIA0KXHBhciBcY2IzIFx7XGNiMiAgIA0KXHBhciAgICBcY2IzIHVpbnQxNl90XGNiMiAgXGNi
MyBoYXNoYml0bGVuOw0KXHBhciBcY2IyICAgIFxjYjMgdWludDhfdFxjYjIgIFxjYjMgcm91bmRz
Ow0KXHBhciBcY2IyICAgIFxjYjMgdWludDhfdFxjYjIgIFxjYjMgbWl4ZXI7DQpccGFyIFxjYjIg
ICAgXGNiMyB1aW50OF90XGNiMiAgXGNiMyBjYXJyeTsNClxwYXIgXGNiMiAgICBcY2IzIHVpbnQ4
X3RcY2IyICBcY2IzIGJpdGZsYWc7DQpccGFyIFxjYjIgICAgXGNiMyB1aW50OF90XGNiMiAgXGNi
MyBzdGF0ZVtcY2Y1IDU3NlxjZjEgXTsNClxwYXIgXGNiMiAgICBcY2IzIHVpbnQxNl90XGNiMiAg
XGNiMyBwb3M7XGNiMiAgICANClxwYXIgXGNiMyBcfQ0KXHBhciBoYXNoU3RhdGU7XGNiMiAgDQpc
cGFyIA0KXHBhciBcY2IzIEhhc2hSZXR1cm5cY2IyICBcY2IzIEluaXQoaGFzaFN0YXRlXGNiMiAg
XGNiMyAqc3RhdGUsXGNiMiAgXGNiM1xiIGludFxiMFxjYjIgIFxjYjMgaGFzaGJpdGxlbik7XGNi
MiAgDQpccGFyIA0KXHBhciBcY2IzIEhhc2hSZXR1cm5cY2IyICBcY2IzIFVwZGF0ZShoYXNoU3Rh
dGVcY2IyICBcY2IzICpzdGF0ZSxcY2IyICBcY2IzXGIgY29uc3RcYjBcY2IyICBcY2IzIEJpdFNl
cXVlbmNlXGNiMiAgXGNiMyAqZGF0YSxcY2IyICANClxwYXIgICAgICAgXGNiMyBEYXRhTGVuZ3Ro
XGNiMiAgXGNiMyBkYXRhYml0bGVuKTtcY2IyICANClxwYXIgICAgICAgDQpccGFyIFxjYjMgSGFz
aFJldHVyblxjYjIgIFxjYjMgRmluYWwoaGFzaFN0YXRlXGNiMiAgXGNiMyAqc3RhdGUsXGNiMiAg
XGNiMyBCaXRTZXF1ZW5jZVxjYjIgIFxjYjMgKmhhc2h2YWwpO1xjYjIgIA0KXHBhciANClxwYXIg
XGNiMyBIYXNoUmV0dXJuXGNiMiAgXGNiMyBIYXNoKFxiIGludFxiMFxjYjIgIFxjYjMgaGFzaGJp
dGxlbixcY2IyICBcY2IzXGIgY29uc3RcYjBcY2IyICBcY2IzIEJpdFNlcXVlbmNlXGNiMiAgXGNi
MyAqZGF0YSxcY2IyICANClxwYXIgICAgIFxjYjMgRGF0YUxlbmd0aFxjYjIgIFxjYjMgZGF0YWJp
dGxlbixcY2IyICBcY2IzIEJpdFNlcXVlbmNlXGNiMiAgXGNiMyAqaGFzaHZhbCk7DQpccGFyIFxj
YjIgICAgIA0KXHBhciBcY2IzIEhhc2hSZXR1cm5cY2IyICBcY2IzIGV2b2x2ZShoYXNoU3RhdGVc
Y2IyICBcY2IzICpzdGF0ZSk7DQpccGFyIFxjYjIgICAgIA0KXHBhciBcY2IzIEhhc2hSZXR1cm5c
Y2IyICBcY2IzIEluaXQoaGFzaFN0YXRlXGNiMiAgXGNiMyAqc3RhdGUsXGNiMiAgXGNiM1xiIGlu
dFxiMFxjYjIgIFxjYjMgaGFzaGJpdGxlbikNClxwYXIgXHsNClxwYXIgXGNiMiAgICAgXGNiM1xi
IGludFxiMFxjYjIgIFxjYjMgaTsNClxwYXIgXGNiMiAgICAgDQpccGFyICAgICBcY2IzIHN0YXRl
LT5oYXNoYml0bGVuXGNiMiAgXGNiMyA9XGNiMiAgXGNiMyBoYXNoYml0bGVuOw0KXHBhciBcY2Iy
ICAgICBcY2IzIHN0YXRlLT5yb3VuZHNcY2IyICBcY2IzID1cY2IyICBcY2IzXGNmNSA0XGNmMSA7
DQpccGFyIFxjYjIgICAgIFxjYjMgc3RhdGUtPm1peGVyXGNiMiAgXGNiMyA9XGNiMiAgXGNiM1xj
ZjUgODVcY2YxIDtcY2IyICBcY2IzXGNmNFxpIC8vMDEwMTAxMDENClxwYXIgXGkwXGNiMlxjZjEg
ICAgIFxjYjMgc3RhdGUtPmNhcnJ5XGNiMiAgXGNiMyA9XGNiMiAgXGNiM1xjZjUgMFxjZjEgOw0K
XHBhciBcY2IyICAgICBcY2IzIHN0YXRlLT5wb3NcY2IyICBcY2IzID1cY2IyICBcY2IzXGNmNSA2
NFxjZjEgOw0KXHBhciBcY2IyICAgICBcY2IzIHN0YXRlLT5iaXRmbGFnXGNiMiAgXGNiMyA9XGNi
MiAgXGNiM1xjZjUgMFxjZjEgOw0KXHBhciBcY2IyICAgICAgICAgICAgDQpccGFyICAgICBcY2Iz
XGIgZm9yXGIwIChpXGNiMiAgXGNiMyA9XGNiMiAgXGNiM1xjZjUgMFxjZjEgO1xjYjIgIFxjYjMg
aVxjYjIgIFxjYjMgPFxjYjIgIFxjYjNcY2Y1IDU3NlxjZjEgO1xjYjIgIFxjYjMgaSsrKQ0KXHBh
ciBcY2IyICAgICAgICAgXGNiMyBzdGF0ZS0+c3RhdGVbaV1cY2IyICBcY2IzID1cY2IyICBcY2Iz
XGNmNSAwXGNmMSA7DQpccGFyIFxjYjIgICAgIA0KXHBhciAgICAgXGNiM1xiIHJldHVyblxiMFxj
YjIgIFxjYjMgU1VDQ0VTUztcY2IyICAgICAgICAgDQpccGFyIFxjYjMgXH0NClxwYXIgXGNiMiAg
DQpccGFyIFxjYjMgSGFzaFJldHVyblxjYjIgIFxjYjMgVXBkYXRlKGhhc2hTdGF0ZVxjYjIgIFxj
YjMgKnN0YXRlLFxjYjIgIFxjYjNcYiBjb25zdFxiMFxjYjIgIFxjYjMgQml0U2VxdWVuY2VcY2Iy
ICBcY2IzICpkYXRhLFxjYjIgIA0KXHBhciAgICAgICBcY2IzIERhdGFMZW5ndGhcY2IyICBcY2Iz
IGRhdGFiaXRsZW4pDQpccGFyIFx7DQpccGFyIFxjYjIgICAgIFxjYjMgdWludDY0X3RcY2IyICBc
Y2IzIGksXGNiMiAgXGNiMyBqLFxjYjIgIFxjYjMgcmVwZWF0LFxjYjIgIFxjYjMgZGF0YWJ5dGVs
ZW47DQpccGFyIFxjYjIgICAgIFxjYjNcYiBpbnRcYjBcY2IyICBcY2IzIGssXGNiMiAgXGNiMyBw
cmUsXGNiMiAgXGNiMyBwb3N0LFxjYjIgIFxjYjMgZGlmZjsNClxwYXIgXGNiMiAgICAgDQpccGFy
ICAgICBcY2IzXGIgaWZcYjAgKHN0YXRlXGNiMiAgXGNiMyAtPlxjYjIgIFxjYjMgcG9zXGNiMiAg
XGNiMyA9PVxjYjIgIFxjYjNcY2Y1IDU3NlxjZjEgKQ0KXHBhciBcY2IyICAgICBcY2IzIFx7DQpc
cGFyIFxjYjIgICAgICAgICBcY2IzIGV2b2x2ZShzdGF0ZSk7DQpccGFyIFxjYjIgICAgICAgICBc
Y2IzIHN0YXRlXGNiMiAgXGNiMyAtPlxjYjIgIFxjYjMgcG9zXGNiMiAgXGNiMyA9XGNiMiAgXGNi
M1xjZjUgNjRcY2YxIDsNClxwYXIgXGNiMiAgICAgXGNiMyBcfQ0KXHBhciBcY2IyICAgICANClxw
YXIgICAgIFxjYjMgZGF0YWJ5dGVsZW5cY2IyICBcY2IzID1cY2IyICBcY2IzIGRhdGFiaXRsZW5c
Y2IyICBcY2IzIC9cY2IyICBcY2IzXGNmNSA4XGNmMSA7DQpccGFyIFxjYjIgICAgIFxjYjNcYiBp
ZlxiMCAoZGF0YWJpdGxlblxjYjIgIFxjYjMgJVxjYjIgIFxjYjNcY2Y1IDhcY2IyXGNmMSAgXGNi
MyAhPVxjZjUgMFxjZjEgKQ0KXHBhciBcY2IyICAgICBcY2IzIFx7DQpccGFyIFxjYjIgICAgICAg
ICBcY2IzIHN0YXRlLT5iaXRmbGFnXGNiMiAgXGNiMyA9XGNiMiAgXGNiMyBkYXRhYml0bGVuXGNi
MiAgXGNiMyAlXGNiMiAgXGNiM1xjZjUgOFxjZjEgOw0KXHBhciBcY2IyICAgICAgICAgXGNiMyBk
YXRhYnl0ZWxlbisrOw0KXHBhciBcY2IyICAgICBcY2IzIFx9DQpccGFyIFxjYjIgICAgICAgICAN
ClxwYXIgICAgIFxjYjMgZGlmZlxjYjIgIFxjYjMgPVxjYjIgIFxjYjNcY2Y1IDU3NlxjYjJcY2Yx
ICBcY2IzIC1cY2IyICBcY2IzIHN0YXRlLT5wb3M7DQpccGFyIFxjYjIgICAgIA0KXHBhciAgICAg
XGNiM1xiIGlmXGIwIChkYXRhYnl0ZWxlblxjYjIgIFxjYjMgPD1cY2IyICBcY2IzIGRpZmYpDQpc
cGFyIFxjYjIgICAgIFxjYjMgXHsNClxwYXIgXGNiMiAgICAgICAgIFxjYjMgcHJlXGNiMiAgXGNi
MyA9XGNiMiAgXGNiMyBkYXRhYnl0ZWxlbjsNClxwYXIgXGNiMiAgICAgICAgIFxjYjMgcG9zdFxj
YjIgIFxjYjMgPVxjYjIgIFxjYjNcY2Y1IDBcY2YxIDsNClxwYXIgXGNiMiAgICAgICAgIFxjYjMg
cmVwZWF0XGNiMiAgXGNiMyA9XGNiMiAgXGNiM1xjZjUgMFxjZjEgOw0KXHBhciBcY2IyICAgICBc
Y2IzIFx9DQpccGFyIFxjYjIgICAgIFxjYjNcYiBlbHNlDQpccGFyIFxiMFxjYjIgICAgIFxjYjMg
XHsNClxwYXIgXGNiMiAgICAgICAgIFxjYjMgcHJlXGNiMiAgXGNiMyA9XGNiMiAgXGNiMyBkaWZm
Ow0KXHBhciBcY2IyICAgICAgICAgXGNiMyBwb3N0XGNiMiAgXGNiMyA9XGNiMiAgXGNiMyAoZGF0
YWJ5dGVsZW5cY2IyICBcY2IzIC1cY2IyICBcY2IzIHByZSlcY2IyICBcY2IzICVcY2IyICBcY2Iz
XGNmNSA1MTJcY2YxIDsNClxwYXIgXGNiMiAgICAgICAgIFxjYjMgcmVwZWF0XGNiMiAgXGNiMyA9
XGNiMiAgXGNiMyAoZGF0YWJ5dGVsZW5cY2IyICBcY2IzIC1cY2IyICBcY2IzIHByZSlcY2IyICBc
Y2IzIC9cY2IyICBcY2IzXGNmNSA1MTJcY2YxIDsNClxwYXIgXGNiMiAgICAgXGNiMyBcfQ0KXHBh
ciBcY2IyICAgICAgICAgDQpccGFyICAgICBcY2IzXGIgZm9yXGIwIChpXGNiMiAgXGNiMyA9XGNi
MiAgXGNiM1xjZjUgMFxjZjEgO1xjYjIgIFxjYjMgaVxjYjIgIFxjYjMgPFxjYjIgIFxjYjMgcHJl
O1xjYjIgIFxjYjMgaSsrLFxjYjIgIFxjYjMgc3RhdGUtPnBvcysrKQ0KXHBhciBcY2IyICAgICBc
Y2IzIFx7DQpccGFyIFxjYjIgICAgICAgICBcY2IzIHN0YXRlXGNiMiAgXGNiMyAtPlxjYjIgIFxj
YjMgc3RhdGVbc3RhdGVcY2IyICBcY2IzIC0+XGNiMiAgXGNiMyBwb3NdXGNiMiAgXGNiMyA9XGNi
MiAgXGNiMyBkYXRhW2ldOw0KXHBhciBcY2IyICAgICBcY2IzIFx9DQpccGFyIFxjYjIgICAgIA0K
XHBhciAgICAgXGNiM1xiIGlmXGIwIChyZXBlYXRcY2IyICBcY2IzID5cY2IyICBcY2IzXGNmNSAw
XGNmMSApDQpccGFyIFxjYjIgICAgIFxjYjMgXHsNClxwYXIgXGNiMiAgICAgICAgIFxjYjNcYiBm
b3JcYjAgKGpcY2IyICBcY2IzID1cY2IyICBcY2IzXGNmNSAwXGNmMSA7XGNiMiAgXGNiMyBqXGNi
MiAgXGNiMyA8XGNiMiAgXGNiMyByZXBlYXQ7XGNiMiAgXGNiMyBqKyspDQpccGFyIFxjYjIgICAg
ICAgICBcY2IzIFx7DQpccGFyIFxjYjIgICAgICAgICAgICAgXGNiMyBldm9sdmUoc3RhdGUpOw0K
XHBhciBcY2IyICAgICAgICAgICAgIFxjYjMgc3RhdGVcY2IyICBcY2IzIC0+XGNiMiAgXGNiMyBw
b3NcY2IyICBcY2IzID1cY2IyICBcY2IzXGNmNSA2NFxjZjEgOw0KXHBhciBcY2IyICAgICAgICAg
ICAgIFxjYjNcYiBmb3JcYjAgKGtcY2IyICBcY2IzID1cY2IyICBcY2IzXGNmNSAwXGNmMSA7XGNi
MiAgXGNiMyBrXGNiMiAgXGNiMyA8XGNiMiAgXGNiM1xjZjUgNTEyXGNmMSA7XGNiMiAgXGNiMyBr
KyssXGNiMiAgXGNiMyBpKyssXGNiMiAgXGNiMyBzdGF0ZS0+cG9zXGNiMiAgXGNiMyArKykNClxw
YXIgXGNiMiAgICAgICAgICAgICBcY2IzIFx7DQpccGFyIFxjYjIgICAgICAgICAgICAgICAgIFxj
YjMgc3RhdGVcY2IyICBcY2IzIC0+XGNiMiAgXGNiMyBzdGF0ZVtzdGF0ZVxjYjIgIFxjYjMgLT5c
Y2IyICBcY2IzIHBvc11cY2IyICBcY2IzID1cY2IyICBcY2IzIGRhdGFbaV07DQpccGFyIFxjYjIg
ICAgICAgICAgICAgXGNiMyBcfQ0KXHBhciBcY2IyICAgICAgICAgXGNiMyBcfQ0KXHBhciBcY2Iy
ICAgICBcY2IzIFx9DQpccGFyIFxjYjIgICAgIA0KXHBhciAgICAgXGNiM1xiIGlmXGIwIChwb3N0
XGNiMiAgXGNiMyA+XGNiMiAgXGNiM1xjZjUgMFxjZjEgKQ0KXHBhciBcY2IyICAgICBcY2IzIFx7
DQpccGFyIFxjYjIgICAgICAgICBcY2IzIGV2b2x2ZShzdGF0ZSk7DQpccGFyIFxjYjIgICAgICAg
ICBcY2IzIHN0YXRlXGNiMiAgXGNiMyAtPlxjYjIgIFxjYjMgcG9zXGNiMiAgXGNiMyA9XGNiMiAg
XGNiM1xjZjUgNjRcY2YxIDsNClxwYXIgXGNiMiAgICAgICAgIFxjYjNcYiBmb3JcYjAgKGpcY2Iy
ICBcY2IzID1cY2IyICBcY2IzXGNmNSAwXGNmMSA7XGNiMiAgXGNiMyBqXGNiMiAgXGNiMyA8XGNi
MiAgXGNiMyBwb3N0O1xjYjIgIFxjYjMgaisrLFxjYjIgIFxjYjMgaSsrLFxjYjIgIFxjYjMgc3Rh
dGUtPnBvcysrKQ0KXHBhciBcY2IyICAgICAgICAgXGNiMyBcew0KXHBhciBcY2IyICAgICAgICAg
ICAgIFxjYjMgc3RhdGVcY2IyICBcY2IzIC0+XGNiMiAgXGNiMyBzdGF0ZVtzdGF0ZVxjYjIgIFxj
YjMgLT5cY2IyICBcY2IzIHBvc11cY2IyICBcY2IzID1cY2IyICBcY2IzIGRhdGFbaV07DQpccGFy
IFxjYjIgICAgICAgICBcY2IzIFx9DQpccGFyIFxjYjIgICAgIFxjYjMgXH0NClxwYXIgXGNiMiAg
ICAgICAgIA0KXHBhciAgICAgXGNiM1xiIHJldHVyblxiMFxjYjIgIFxjYjMgU1VDQ0VTUzsNClxw
YXIgXH0NClxwYXIgDQpccGFyIEhhc2hSZXR1cm5cY2IyICBcY2IzIEZpbmFsKGhhc2hTdGF0ZVxj
YjIgIFxjYjMgKnN0YXRlLFxjYjIgIFxjYjMgQml0U2VxdWVuY2VcY2IyICBcY2IzICpoYXNodmFs
KQ0KXHBhciBcew0KXHBhciBcY2IyICAgICBcY2IzXGIgaW50XGIwXGNiMiAgXGNiMyBpOw0KXHBh
ciBcY2IyICAgICANClxwYXIgICAgIFxjYjMgc3RhdGUtPnN0YXRlW1xjZjUgMFxjZjEgXVxjYjIg
IFxjYjMgXj1cY2IyICBcY2IzIHN0YXRlLT5iaXRmbGFnOw0KXHBhciBcY2IyICAgICBcY2IzIHN0
YXRlLT5zdGF0ZVtcY2Y1IDFcY2YxIF1cY2IyICBcY2IzIF49XGNiMiAgXGNiMyBzdGF0ZS0+cG9z
XGNiMiAgXGNiMyAvXGNiMiAgXGNiM1xjZjUgOFxjZjEgOw0KXHBhciBcY2IyICAgICBcY2IzIHN0
YXRlLT5zdGF0ZVtcY2Y1IDJcY2YxIF1cY2IyICBcY2IzIF49XGNiMiAgXGNiMyBzdGF0ZS0+cG9z
XGNiMiAgXGNiMyAlXGNiMiAgXGNiM1xjZjUgOFxjZjEgOw0KXHBhciBcY2IyICAgICANClxwYXIg
ICAgIFxjYjMgZXZvbHZlKHN0YXRlKTsNClxwYXIgXGNiMiAgICAgDQpccGFyICAgICBcY2IzXGIg
Zm9yXGIwIChpXGNiMiAgXGNiMyA9XGNiMiAgXGNiM1xjZjUgMFxjZjEgO1xjYjIgIFxjYjMgaVxj
YjIgIFxjYjMgPFxjYjIgIFxjYjMgKHN0YXRlLT5oYXNoYml0bGVuXGNiMiAgXGNiMyAvXGNiMiAg
XGNiM1xjZjUgOFxjZjEgKTtcY2IyICBcY2IzIGkrKykNClxwYXIgXGNiMiAgICAgXGNiMyBcew0K
XHBhciBcY2IyICAgICAgICAgXGNiMyB1aW50OF90XGNiMiAgXGNiMyBvdXRcY2IyICBcY2IzID1c
Y2IyICBcY2IzIHN0YXRlLT5zdGF0ZVtpXTsNClxwYXIgXGNiMiAgICAgICAgIFxjYjNcYiBjb25z
dFxiMFxjYjIgIFxjYjMgdWludDhfdFxjYjIgIFxjYjMgaW5cY2IyICBcY2IzID1cY2IyICBcY2Iz
IHN0YXRlLT5zdGF0ZVsoaVxjYjIgIFxjYjMgK1xjYjIgIFxjYjNcY2Y1IDFcY2YxICldOw0KXHBh
ciBcY2IyICAgICAgICAgXGNiM1xiIGNvbnN0XGIwXGNiMiAgXGNiMyB1aW50OF90XGNiMiAgXGNi
MyBhXGNiMiAgIFxjYjMgPVxjYjIgIFxjYjMgc3RhdGUtPnN0YXRlWyhpXGNiMiAgXGNiMyArXGNi
MiAgXGNiM1xjZjUgMlxjZjEgKV07DQpccGFyIFxjYjIgICAgICAgICBcY2IzXGIgY29uc3RcYjBc
Y2IyICBcY2IzIHVpbnQ4X3RcY2IyICBcY2IzIGJcY2IyICAgXGNiMyA9XGNiMiAgXGNiMyBzdGF0
ZS0+c3RhdGVbKGlcY2IyICBcY2IzICtcY2IyICBcY2IzXGNmNSAzXGNmMSApXTsNClxwYXIgXGNi
MiAgICAgICAgICAgICANClxwYXIgICAgICAgICBcY2IzXGIgaWZcYjBcY2IyICBcY2IzIChhXGNi
MiAgXGNiMyA+XGNiMiAgXGNiMyBiKQ0KXHBhciBcY2IyIAkgICAgICAgIFxjYjMgc3RhdGUtPmNh
cnJ5XGNiMiAgXGNiMyBePVxjYjIgIFxjYjMgaW47DQpccGFyIFxjYjIgICAgICAgICBcY2IzXGIg
ZWxzZQ0KXHBhciBcYjBcY2IyIAkgICAgICAgIFxjYjMgc3RhdGUtPmNhcnJ5XGNiMiAgXGNiMyBe
PVxjYjIgIFxjYjMgfmluOw0KXHBhciBcY2IyICAgICAgICAgICAgICAgIA0KXHBhciAgICAgICAg
IFxjYjMgc3RhdGUtPnN0YXRlW2ldXGNiMiAgXGNiMyA9XGNiMiAgXGNiMyAob3V0XGNiMiAgXGNi
MyBePVxjYjIgIFxjYjMgc3RhdGUtPmNhcnJ5KTsNClxwYXIgXGNiMiAgICAgICAgIFxjYjMgc3Rh
dGUtPmNhcnJ5XGNiMiAgXGNiMyArPVxjYjIgIFxjYjMgc3RhdGUtPm1peGVyOw0KXHBhciBcY2Iy
ICAgICAgICAgDQpccGFyICAgICAgICAgXGNiMyBoYXNodmFsW2ldXGNiMiAgXGNiMyA9XGNiMiAg
XGNiMyBzdGF0ZS0+c3RhdGVbaV07XGNiMiAgICAgDQpccGFyICAgICBcY2IzIFx9DQpccGFyIFxj
YjIgICAgIA0KXHBhciAgICAgXGNiM1xiIHJldHVyblxiMFxjYjIgIFxjYjMgU1VDQ0VTUztcY2Iy
ICANClxwYXIgXGNiMyBcfQ0KXHBhciANClxwYXIgSGFzaFJldHVyblxjYjIgIFxjYjMgSGFzaChc
YiBpbnRcYjBcY2IyICBcY2IzIGhhc2hiaXRsZW4sXGNiMiAgXGNiM1xiIGNvbnN0XGIwXGNiMiAg
XGNiMyBCaXRTZXF1ZW5jZVxjYjIgIFxjYjMgKmRhdGEsDQpccGFyIFxjYjIgICAgIFxjYjMgRGF0
YUxlbmd0aFxjYjIgIFxjYjMgZGF0YWJpdGxlbixcY2IyICBcY2IzIEJpdFNlcXVlbmNlXGNiMiAg
XGNiMyAqaGFzaHZhbCkNClxwYXIgXHsNClxwYXIgXGNiMiAgICAgXGNiMyBoYXNoU3RhdGVcY2Iy
ICBcY2IzIHN0YXRlOw0KXHBhciBcY2IyICAgICAgIA0KXHBhciAgICAgXGNiMyBJbml0KCZzdGF0
ZSxcY2IyICBcY2IzIGhhc2hiaXRsZW4pOw0KXHBhciBcY2IyICAgICAgICAgDQpccGFyICAgICBc
Y2IzIFVwZGF0ZSgmc3RhdGUsXGNiMiAgXGNiMyBkYXRhLFxjYjIgIFxjYjMgZGF0YWJpdGxlbik7
DQpccGFyIFxjYjIgICAgIA0KXHBhciAgICAgXGNiMyBGaW5hbCgmc3RhdGUsXGNiMiAgXGNiMyBo
YXNodmFsKTsNClxwYXIgXH0NClxwYXIgDQpccGFyIEhhc2hSZXR1cm5cY2IyICBcY2IzIGV2b2x2
ZShoYXNoU3RhdGVcY2IyICBcY2IzICpzdGF0ZSkNClxwYXIgXHsNClxwYXIgXGNiMiAgICAgXGNi
M1xiIGludFxiMFxjYjIgIFxjYjMgaSxcY2IyICBcY2IzIGo7DQpccGFyIFxjYjIgICAgIA0KXHBh
ciAgICAgXGNiM1xiIGZvclxiMCAoalxjYjIgIFxjYjMgPVxjYjIgIFxjYjNcY2Y1IDBcY2YxIDtc
Y2IyICBcY2IzIGpcY2IyICBcY2IzIDxcY2IyICBcY2IzIHN0YXRlLT5yb3VuZHM7XGNiMiAgXGNi
MyBqKyspDQpccGFyIFxjYjIgICAgIFxjYjMgXHsNClxwYXIgXGNiMiAgICAgICAgIFxjYjNcYiBm
b3JcYjAgKGlcY2IyICBcY2IzID1cY2IyICBcY2IzXGNmNSAwXGNmMSA7XGNiMiAgXGNiMyBpXGNi
MiAgXGNiMyA8XGNiMiAgXGNiM1xjZjUgNTc2XGNmMSA7XGNiMiAgXGNiMyBpKyspDQpccGFyIFxj
YjIgICAgICAgICBcY2IzIFx7DQpccGFyIFxjYjIgICAgICAgICAgICBcY2IzIHVpbnQ4X3RcY2Iy
ICBcY2IzIG91dFxjYjIgIFxjYjMgPVxjYjIgIFxjYjMgc3RhdGUtPnN0YXRlW2ldOw0KXHBhciBc
Y2IyICAgICAgICAgICAgIFxjYjNcYiBjb25zdFxiMFxjYjIgIFxjYjMgdWludDhfdFxjYjIgIFxj
YjMgaW5cY2IyICBcY2IzID1cY2IyICBcY2IzIHN0YXRlLT5zdGF0ZVsoaVxjYjIgIFxjYjMgK1xj
YjIgIFxjYjNcY2Y1IDFcY2YxIClcY2IyICBcY2IzICVcY2IyICBcY2IzXGNmNSA1NzZcY2YxIF07
DQpccGFyIFxjYjIgICAgICAgICAgICAgXGNiM1xiIGNvbnN0XGIwXGNiMiAgXGNiMyB1aW50OF90
XGNiMiAgXGNiMyBhXGNiMiAgIFxjYjMgPVxjYjIgIFxjYjMgc3RhdGUtPnN0YXRlWyhpXGNiMiAg
XGNiMyArXGNiMiAgXGNiM1xjZjUgMlxjZjEgKVxjYjIgIFxjYjMgJVxjYjIgIFxjYjNcY2Y1IDU3
NlxjZjEgXTsNClxwYXIgXGNiMiAgICAgICAgICAgICBcY2IzXGIgY29uc3RcYjBcY2IyICBcY2Iz
IHVpbnQ4X3RcY2IyICBcY2IzIGJcY2IyICAgXGNiMyA9XGNiMiAgXGNiMyBzdGF0ZS0+c3RhdGVb
KGlcY2IyICBcY2IzICtcY2IyICBcY2IzXGNmNSAzXGNmMSApXGNiMiAgXGNiMyAlXGNiMiAgXGNi
M1xjZjUgNTc2XGNmMSBdOw0KXHBhciBcY2IyICAgICAgICAgICAgIA0KXHBhciAgICAgICAgICAg
ICBcY2IzXGIgaWZcYjBcY2IyICBcY2IzIChhXGNiMiAgXGNiMyA+XGNiMiAgXGNiMyBiKQ0KXHBh
ciBcY2IyIAkgICAgICAgICAgIFxjYjMgc3RhdGUtPmNhcnJ5XGNiMiAgXGNiMyBePVxjYjIgIFxj
YjMgaW47DQpccGFyIFxjYjIgICAgICAgICAgICAgXGNiM1xiIGVsc2UNClxwYXIgXGIwXGNiMiAJ
ICAgICAgICAgICBcY2IzIHN0YXRlLT5jYXJyeVxjYjIgIFxjYjMgXj1cY2IyICBcY2IzIH5pbjsN
ClxwYXIgXGNiMiAgICAgICAgICAgICAgICANClxwYXIgICAgICAgICAgICAgXGNiMyBzdGF0ZS0+
c3RhdGVbaV1cY2IyICBcY2IzID1cY2IyICBcY2IzIChvdXRcY2IyICBcY2IzIF49XGNiMiAgXGNi
MyBzdGF0ZS0+Y2FycnkpOw0KXHBhciBcY2IyICAgICAgICAgICAgIFxjYjMgc3RhdGUtPmNhcnJ5
XGNiMiAgXGNiMyArPVxjYjIgIFxjYjMgc3RhdGUtPm1peGVyOw0KXHBhciBcY2IyICAgICAgICAg
XGNiMyBcfQ0KXHBhciBcY2IyICAgICBcY2IzIFx9DQpccGFyIFx9DQpccGFyIA0KXHBhciB9
------=_Part_63385_735360.1229469659705
Content-Type: application/pdf; name=shahaha_submission.pdf
Content-Transfer-Encoding: base64
X-Attachment-Id: f_fot611da1
Content-Disposition: attachment; filename=shahaha_submission.pdf

JVBERi0xLjIKJcDIzNINCjEgMCBvYmoKPDwKL1RpdGxlIChzaGFoYWhhX3N1Ym1pc3Npb24uZG9j
KQovQXV0aG9yIChGZXJkaW5hbmQpCi9DcmVhdG9yIChwZGZGYWN0b3J5IFBybyB3d3cucGRmZmFj
dG9yeS5jb20pCi9Qcm9kdWNlciAocGRmRmFjdG9yeSBQcm8gMy4wMiBcKFdpbmRvd3MgWFAgUHJv
ZmVzc2lvbmFsXCkpCi9DcmVhdGlvbkRhdGUgKEQ6MjAwODEyMTcwODEzMDYrMTAnMDAnKQo+Pgpl
bmRvYmoKNCAwIG9iago8PAovRmlsdGVyIC9GbGF0ZURlY29kZQovTGVuZ3RoIDUgMCBSCj4+CnN0
cmVhbQ0KSIntV9tuG8kRfddXzEsAKTZHc+OQUtYG7Mjy+iHIwmYCBNbugiZFmxuK0nKpyyJIvj1z
6elbVXXXkEOZxgp+kTl9q6pT55x6PTo4Po+DOAqjYTCaHQySYJDHYZQFo7PgMDgKRr8cREEvScN+
ov10fJ6oPUmYZ0FUfu0VPw0GgzwYTYLDV/Vm7ZeFOK78+3P1d7Ehyar/Xzerh1k2rH5ZzbXl62a5
+v5FnpDmeX3IlTgkTqr/BnDTh5vmt7jf79fLLsHVkzk8ewbCmU+sGMbgwcZyNGLjdUvs/ZF2trl6
6g+3+SlNmp9u4aqb5hyZkht/dXixgti04iMPlweceR8wcYQGEaH2Xbqfth5zK6fnaylCqFqh7JZk
WPZDfWRiRhtKBMIqvyaWiotjFB/aS/9ubbjjoH2FbjIScAkrdN8wgcYeNVPU5FEH9A6FtLrrRgte
viPOE/FZUECzegnDmRDVigxk2xyEZEQV5DnxZPWstfksyUTpiZ1lcIa8dbwRPSZZmuZkttbaCV/A
+Vc48PTUaTQbi1W/OSAEswr5kr7MdZe1SWJ1TORVu5eVKsgLY7hoQdPx1AEjp2ZoZyzplECoedmI
FhAUdnZHif+jkmKFbOsXkgK7pKCixPXXINo1AQmsujZAq79/ta64hTmetzjTn9o6WVP6Gi04Ti3b
QxQrgCnrWlgUgbKAjFOxejAVIKg/zQEhEWEaN0/5XotQmSolVG58OCTSxoNSCGmM4yQ8yZXczbx4
Xiyw16pg7inKoFqG9FJOBodV55XKVQfk6UptvYh1KeN6jYRwhQIbECepP2siXrdTwUiiOQAxThzJ
8JKjXjeMYhuOhTKJPFas+J0nzwjsdqG0m4KP8RgX0qAXHiPppbkP+j0sFaSXQQ2f+NjK8AEjCtNP
oPoWzbOJV1aUGN2o8rJcB8v546wXSkIu5o/ysWdBVejhsM7miMqTV9753Y/RkW2VOLZay0hr8CBv
abqA4zK15LQcHOi2IRL6id967ZLUzhiru/726q03TCkZFokaIGEwvAkK/8z0daueJsyaOpqEMSMQ
FswoHzYXIAOYY5bxORaYE4yWaEzpcb3RFv9VPa5JznuZCXn9v35QYdncxTF4wP2wRhqnNFMCgvh+
ckS9Masp8wqUpX4pdNfIfS6TjVtDGLdmflmjmKk2RuVecfJiW85bTgEW4Bjpqj1eTp6Kzjv0iKKt
vkVS1ZZmyTqMnYSFGnjtWoosGYy3gZDZstCOFYjetFjGa0YgE2vIueKfs6mHp3WJr/+64kJGfksD
6B1sun+C+h1rG/7tkAhX53C1CUC17hgFdHuq41hHpOFIvLkGResRoRVo/ajj8ySIy2iD0cw2zza1
UQxBuBANHCu9PdYqxc132QAKlpToAHgZDWUTnnHLjb7jtIk/tuNPhmX8h7H8nldYmR30wygLsrAv
9SiJBuIpa3hYVvRq0GuWMwLhWBudSNEWuTiEqXyHcBPbFV4cXhxdHME1p1R9ED2kqHYBj2XgGmoG
xsxOibEbESUyj7RuMvkotzMhXuJzZx5kbGR43QD44ot/AaPDvbtJFi1u80p+9Xc/TtybP9FwQ1rP
U0273XBeuoEVhAWcUCKN9JLqatGUmM3oi5+euZJlJQfNXWTmzeoI3ii2B3lUTfZav9NKIO3pIR0Z
8yVCceqZCMctyGdq6UZGUqYntZnPwzFi40lYrDHGrc0cEM0T9uhzTcMhQitjyHPilufD5RRKcrVS
SnI3UqyQqzj2H/qCKcSE58y2khv3h8P65JEJV2mrIDOTVSJnCDNPyPSBkrx7EEFlCI44CEIeCDAx
9NRu320h+1ikZRp5SDoAFobRp79v93nHt3/dxz897ulxW28XP/TiOCx6vpSwQqfEBOllbkigPIbb
1hUQMSPUaI8WfrbUyI9mSEST5SKHt1QPRNUSVTrE6IgIPlMRSIv9Qh6biUp+R4tW3zo+1r5xZxfL
g6vsb+HB/TLaTRpVkl7i+KqzFCc7mjgQH1lf+W5JFtoaUttaK2Nkm4Ew5kS+CfsNXtNJa3mM/amX
CzbtJNT+sebFBwsgLexffcDOrJ/asSv718L3+wmdpwJ0kLcgcQvVmhKucy3zy8/oUzCNqt+1ovNo
k2G+JbhUXBk/XyZAjKyIT0sAPP+Y4xxc7ho0Kvpf2Es2w789zpkheEYnJrfoOUEpvfNxjCMc5sxG
wCJ1CEp52saurl0eJ6RsE3h7TKXwKyDGDd1IYOMgrPyg5qpe27XVMDhIq9AMfQJHRKM/loCafdi1
eNLa87W01FQMTUcRyM/Nt9mkTI4r2wprR6DbQFQ5SuoXdYaS2omPNlDRrq2ZWWQ6iAfYfFKY4mLS
UYNOMVs9HhUyvAWnYVzs5RlbPYVThz+ngOOd/3wPfmq/R2s/OuFtjBE961AKhgwASzzVNdW7rC+w
RSAx4Pr0xHZkLT17e4vibn9puu2G10TKb4JZON9IhNGWU1mcmFmkTTsqATQJ7IPBMCC2AHl24NBp
OfikR0TiZEGlZUl4klditgEHPg2nZ82S4/M4yKv0zg76YZQFWdjPlUlYTeWquHxvvaw4oSfXdROV
ejoaWf2ai0N1RwORcxKnZvkUphboiWowvTjSFxzB80/JngTKAr38lRXuJ3edV+4640Rtn270yJqu
EzhE5mQmQyT9ARHpLoyUIYWKthMO7ryChnMmNU/ZVWzvlzvzdA9bW98OmcxoZYTQ1YMmaBp6+ite
We8kLTowe7Zlam/q3PNQGm9T3wW9x6uxdhNpHbSbRsaEvXUnu86QHgSiBVNrcHf71tbyKt5TiFwh
a704DSuR9NsfAXTEUnmfJbsbEtdjzLnfSrOHZLP7XLQ9De3CRRvtTHvmGjFtHTLDEHcrIRk/Tw1G
bs3k610xZd7ttIN32oGQmhboau6E9tyhHAQBT9sH0LxaacV2r5ZFtlBhGhWsDZ0OuYXqte+i+rxf
EZqc8w9pUwVoAGzjfa33MjXlOYw3HEW7mOi4nTplHuZxFvZhLt6CuRCwuEZPbvVqn8ZvgRJyTmvM
EtIpQJGNDX4/ZysPmnWWl9uFDnZkwjjdwqBFO32Uuq7n1gl6A6OY8xrHTdqPEAsOLFvR5gSPFuxi
0QFTQRDk77h7gM7r50E8uCaKUBJyUrj3YUnIejHf7Ap/O6A9ZZe1Q1bgRTpHK8IHAwhiBh0dpFaf
woT2dBfzfRuqsDlJwfg9XVnAL3VpVlS34+C/I+q2sYu8OGS3gj8RadJs+gCjHkvP4OHw+mF/5lO1
xyx5vMrFkXI/cVguqN1POqyj+4/+uelFUC2TV5yfCTOgIReFvu8Mdc1z745fQJL+ApPAjlLRX5rn
9QUzN8UL1KFvgq/ui59euFk3gkExEwFDiwaZMCLfbaTGsItIFBp568GoX9ISi7l/lMhN5gaa1i5l
z0COnnnaqT2S8O5reZr9mdWdCLxaohpVKRJfL/AVGqKN7PvrMydXNIhCIV3f2B9Y2MoJhGAhwaDl
lTvETEdV3ifEbfdZVO6Whobl8hCpFCuGWpF+5kuTg5cYY5aX7zuj3kjjXB2bLzlMufad+5EsQPX3
j51q8F4gzzb7nvmCW0qEp2hwO5EdaahWj/uZ7oMNjJub6OGRTozBzLb2tw5479paf8R8nl+fntF1
j6EoXxx5dftPLsHL4fqn1vzWWhMdWH0p2SOh6fgmKT1am2xiTtFOVNVJtCu3bEPr5IH2LX9qx31v
RxIhn3bWi19RJrdtzs5VMX1SxXaf4bv3+700davyzLwFVxLg1Uq7CzwN3kgAmdc0D6I9gsc+mG9N
AsbajpXk/zTNtV+KHaJmv1PgSMSCn16g4fvHF6S3e8Ujymomwz0qX2uRvQThLVzkrvY9AXqPAV0s
yfNB/cv/SIjz8L3X6vVHULdHHbecXUKfa6jpR0KU68t/9AoranQjXajBUFD9jRh6yoTH+UC8/yfe
9R2lZockIYwG1c7fnhV9fPB3z9PNFc/Uy9uOc52Ea9z8EmDkSm/QBwn4E9sl2BnYM5xF6bBO03+3
eAvrNPS3+qfj8ySIywoFo1n5PUmFRZTf06C8a3bQ62dBbzCsqOwsqEpfX/iDfIIo+1nzxqgu+nmT
ffFdp8iJgohZKQGYy7G1eW0vmKKnlzwmWOy+gUNs0Dt54hf8ufL7jX3jjIrXGM6seInLr/F8GH0L
IjUrQSfz2j5gTWwAqTIjkd8Xjsre2YVyRPab597rZXNyFMTB6nOQZFmJ2UhAUZb6vknJydAsfvPC
EC9mT909I6rbXTXL5+VoRUPs7Oasq+qHNyORhfdvg6j6V6QjCvvBfZDkSZmUop0HRQ9fFbPNIMyy
5v+Lgw8H9Qaxs0pkpPadhMNy8aAkgOqFq8tg9n+3Cp8QZW5kc3RyZWFtCmVuZG9iago1IDAgb2Jq
CjMyNzYKZW5kb2JqCjYgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAzIDAgUgovTWVkaWFC
b3ggWzAgMCA1OTUgODQyXQovUmVzb3VyY2VzCjw8Ci9Qcm9jU2V0IFsvUERGL1RleHRdCi9Gb250
Cjw8Ci9GMSA3IDAgUgovRjIgOCAwIFIKL0YzIDkgMCBSCj4+Cj4+Ci9Db250ZW50cyA0IDAgUgov
QW5ub3RzIDEwIDAgUgo+PgplbmRvYmoKMTAgMCBvYmoKWzExIDAgUiAxMyAwIFJdCmVuZG9iagox
MSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzI2Mi4wOCAyMi44
NiAzNjcuNDQgOS4wNl0KL0EgMTIgMCBSCi9Cb3JkZXIgWzAgMCAwXQovSCAvSQo+PgplbmRvYmoK
MTIgMCBvYmoKPDwKL1MgL1VSSQovVVJJIChodHRwOi8vd3d3LnBkZmZhY3RvcnkuY29tKQo+Pgpl
bmRvYmoKMTMgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsyNjIu
MDggMjAuNjQgMzY5LjM2IDkuMzZdCi9BIDE0IDAgUgovQm9yZGVyIFswIDAgMF0KL0ggL0kKPj4K
ZW5kb2JqCjE0IDAgb2JqCjw8Ci9TIC9VUkkKL1VSSSAoaHR0cDovL3d3dy5wZGZmYWN0b3J5LmNv
bSkKPj4KZW5kb2JqCjE1IDAgb2JqCjw8Ci9GaWx0ZXIgL0ZsYXRlRGVjb2RlCi9MZW5ndGggMTYg
MCBSCj4+CnN0cmVhbQ0KSIntV9ly29gRnWd+BR6lKgvCQoJgJpMqL2Nbmdjj2KrMi14kajEj0NTI
lCz/i//Fn+I/SQXLBe7Sy22AtD2TiHoRgLv0cvr06UeHo/2nSRBHYZQHh+ejaRJMsygs/38S7AS7
weG/R1Gwl6RhUr/ai8J4kufl//Ng55X6XP1/3PxfnjIeN1+vwddyc5Jm2bh+tQQbzowNa/j1uj0j
TeI4qd+9V6vUY9Dd0lyxumVOUWu6JdPpNKvfLM7aJfrdB8O0vzTX7D+NddTKEKXTMAEROlSnq8ve
tifHk8kkMZ0GLkAn6TOODetEn82IdKmxLLAC0sUj9wU+zhJl5sK49B04ct25OXMDofa/M/afkmFz
PlMerF1gEDusEKNBslDjT2Rj4CROeKCewJivaSC4h7hpsc2aG4bcdH6maWYUKZY5LHwqGh9tQx4g
6V9jEUXjhdniLLJ443wl37j9bGCxdmvALTwb0vqeU85GZy1qcmSYC7OD5A8JrKemYREMCbxV6HMC
Gm5t8rBG2YLPKFoX0D+jUqRW0NSpQ9+HXbu+G6ddU2FcAWcWuod5CYuBIoCQv4cAAiBPLHq1gAvy
BsskSgicU/0KbZLXBNBRl3FOHN5F3Z4GeJkvvzlMXSEyVdJpr6SFSB1mRplRBT0bOadDpI0IuVXn
usCQqD6uEOAgWedxqzcsKY8mNn/CGIAzjJShhYfn+G4LikCHsIX64Vb449vHASfzrdc8ZlbrVr+G
mMbgIMdaRR6k6oFZkVzcVDzTuLRsYzu2vusFlfLmrse0vf5W2R9VJL/Jqh1bZN9gcyJXGsWftjTq
/492gJOuvR/J1HOFAp08Xi/ok/504dszt7w0DjzQxdNG9A3FwEjBOXvITg9TsOiBTn3PK+OeGyfU
cPYqmBSKOki/ysOGsSjqNnZj6J6xIEkncMHRLhEIzdAfbG6BYqAz2DM9IZckbsNhx8FjySJsZsQI
v4/4oi7mylM+22BauV83ZMX2se3eO2G2MG3VHKCnHFLPLog7icnnivYDKYILZs7RJlASFQLbQHIB
z0GZwhkdECMFlCFs/FwL+oNwfmQYY9ELOtEidUQVHh4QKWYuROWBAsUSAXS8roh80LWGT6IopcHJ
ZojekpeYKFwYvULyJnoYpk9VB9LkEHoL91eKXbSVHeOn03A8rijfStwtYZ9bKWYtW0kSOegSHhv9
G+IE9XxKRQW0UJfFSXKi3D0ljDclq7H8kgz/z4ej34M4D6Lyr8lDPIvDck0Wz8o+PF8Gjw6C/d+C
0sL958EkCvYfvXoc5MH+4zfB/utnj4KDJ6P/3P/uf/e/+9/97/53/7v/3f/+iL/P6x/Ub/25e/P8
0xfnc/uROcdaUu5br9ftOZ/Vf9Xbz/Yu5Hb3xs9rbY9688l8oU/98um5Y2r5ptvsnFN+Ir2qDqo/
fvm0rvdQ56j3Xz59Qo/qYllbVv3UVu149UI/oYEGYRvyMz34vodYkW8DPOiUH8zfFgy7/3293+jn
g+Cfo0eHoySa1aNkkoZJHhw+CZx51RpI5+2rctSsnldwpDUm2ivwtUBmXGPDHdiwWLc7xnn94qNa
4tqoDDoxTrsBp62JzXGWqP1rY//bdn8+VpcfkxugPWmWNSvOoVPGJReOA63RyThNm9XXZMzsS+EN
5Z40idWi95Tv3anHXXai3N4FE27fXP9/yuf2inZDnf2OP+wYWy3LhWW7eReDhAWyGgkwvB1bBJxw
SwJaguQAuUtDc03H1z06nWEJYgKKgNHBg3rskmxXa/3/0U4faLtFp2ChfIjTaUVae/Gkdu5J4DIA
emYaO0E3XNgzP38wzd61oxi2mN+Lk3CWVZd3ZbBXkuiktqfZO+5ssQvVG8+GCt6dUmBgy5i+BCTe
S/WdYW9RQwmcogRAlRyTtzkLhps+JoQqFoAUzgmz9KEvHj7jTb91EGLYGNN8edDd1HHBvwA77Bsb
LkE0zoTNURQg0CabIF8RZ8LOwiIFL3vNNAJlsaDbxQXnqZUVKocxlkP9ebJZJQsanadTtxwaz5x7
EmHOYYL9rRqcgTKiuKTw2269mS+QUBrOLIgD7GhDADt0T0gTrlfpVlCKZ037V/RmBBxX6Lc+zHpq
e/iAdNGpUUurkNLcBf3/il72RhgS47JXHgIiHnjaBaBhlgDdOlAaGmmgeBslpksGPVZzQpnJ7c0Q
t2AitCHnZRowNZAsrb9dDLnIvmX7UpqZ+ajSQqIJK5RunIEoglA++MeODZLiEtkAHAMPDSD7RZZI
lEtw3HkCmgmeFVofCavc0R04gi+YoEGG7CUEqhPyPLe9ckBueMW4BSE3zoG5ePmEqBL3t6mt1RIX
VoEWZqLCiUyub0n6PND4cOz088Am0wjRNL1qookj2sC2MOuRY8TgacnwllLCqNrQB530ooNJTM0R
0PItzBH4bON4MJYXz8CZC6PXDjnkmNNHVcPeNzcMQTl/EMV4RadVzYWIhoiTnBiK5ckSIAMiG1UJ
Yv39DmzwAJQqIbZvC8lxKINQdQiYtnHZwwKey1LiM7y87diH3kaAT43KXEhpS8ckmrcMoPaWHELO
eEdSA4dsmirpJM7PaMsgsthqXrAl0BWWp1DdKqf9XTsRvMHuhwZb+UUtFHWqK7jaLAiEyKAy6aEp
+wHR6mR42jQCBDJP5LfT4lCugtWpNp3qFpSEs4zuQWBwYblOL3/m9RITNcZ1BXqAHUrjhMvBLdKJ
syMxvQyCZRu0fadHNHBxhEY3m+wlaTipZYGaU7gMQ87gYABroiAy6TQSw0kzbzfwijNhImy5vqLD
vcl0Qk2qBoYgi6BWcDQqqE4D5VtxCW3WNDFCl1DcDnBSoCS3MgjCeYDuTCvs4iYckXNYSLq6qfKx
0rqki1OtuKND4asJ9Fh/9X3XNMRR7KyOjM/GV5scB2WGJLduHOE7Qj9FqlcfJUlqbDgg+nyvnnPL
G2W0dT1Zgobp5zc7PDrD1gxCtQb3NBSN/SEb2TLAaB5egL94+AwYW2ZnTG5sF70B+bPPffXm15de
BvmHK750s7MD6Rdw5qIfiYu1iHveOd0a/HPnQ3fMS21cC4rXpteP4ZZf3vQ6mMkLhJCmGUbZ/Dic
B5FN9MxiDYkE330lgeJtHZHdNrTkpNoGvES5LdVeHHVxZ/SlY/6Meb9c94h0QQOCmzlIf1YoMSEz
FWhzFH//RuDJM2P54+AQPt8PAdRokA2UJm390QmRpLrpiJ4cIQ1tI3gySm9DeK4NU98yUAXs05+f
IJlszE89RBQavDTxgUY0nbjIQlouGnAk1cwt3BzVnHcLE1iAZjNw7rN1hXaaKoUheBDwvK3RNmoQ
UMHiFOWp4JNebBjZn0I6/lsfSDwdEPIbMTfaMDCi6LFjdS6ZI0hBy9jkyyzXzJZLoa/oUNpLCLry
huKLJgcXzmooFXWjZ6kBs7sNh9mpUOGh5iN6QpQIPIH0gQqYoqxjsKEYCgMhrh78WUiNYrDTU+jA
gqf1CyKmCODp0qLNxrP9dmtm+rlZR0rAEUziPLpz6ymB5UUsX8lBKzcBMHjjzdHO1TXhrq/YF8gq
pMS7mYOjOg/UisWS9NgmelYAD4Rkb3Hrp5IhLR+gA/TvBp839BE++Wh6ti/sCf6qwDCjjlhhGVHI
3HUMCCli645/ydF0c0PPdshMWz7IypiHoh6XZb0ikkvlUoZSGp9DRzAGCkvjziuCx/mMYEofxo2t
M+kAB4m4R9viZ5QbBBRC0fAVSHNNHWwbSDSTux55dDuhXzE1HH0DfSrMeF6DOAjFdkNjPfQC2h8h
0SOV49U4hi3eSmRGXVQJ4WWPFJBrLsrVLNniHlh9Di+KK95YiqNg8xdwFKh/d0UatyH5wJQd6sel
PGR0TwjRmqlPyfPmzkNhk/DKjr7p2M4Mqe2gAuZqHzcnos6ryuoCGCYdCfyS3KdAh52KRv4bqFRW
U0Cc928bRP+ligWZLlBqRzOJ8LB/AoT0KWhtPbq2dIJ1SFOK9Tu+6k+MpTfgbBSsKMABd+kr4LFL
GVakldK3+L6S9uBVIzIJocAtizJDM7U69yWDQpJbTVxhIOpPIrK3MCM2518QSefYfoHkhCgT5GAg
D1ze9TceMI5CmegpbpQzXCB8bxVCD3UWNjbU1JxcvqDcUDJpkC6CLWWtu1QSzjI93Wx1ZEQd9atV
WfUyvFPARYUTyD68yGP5eEGljBl4ONGxdiCxIsLkHbAkVWtsOsP8cJFXIiZJw0krbLTVv4Dq7PDv
n0iPdi6PdsUI8imaBsg3aJwsmCxgFOZoekQSjpsHpY1yY+e1HZGTP/yK+v8DYT3jAhzKEX/Ctwba
+bA6Jt3bOMsaSegJIv9EQ4s69lYYSZ+m9Vr34qGRv8duX6K2b8oP/pywtGp0RDQAoBlZG4jKWhlL
yYnCISFBZUkaLkQGZSOqpfHmqsPCSDWSmTzTmdK79FSjlUga1m2l7AaTOFH9QACxzvynROM0bC3Q
JSL1jcKOEvNJmmXN6nPqOGM/nCRFdLZ9oS9orgTSETMpBsVmBx2uFREBnwqD1rnS2ixbiowFhmDa
ALR2BCpXFFWINHGcTdSrn7pjxmoA+Ctll7JiYlgRJ4Km7BAyplMkU46rHC2pAStkk6h+tVlEx/1v
dOAmsRPxbx/kBwEWI5KV76RRMwCk3YuNb9/CVdAito4OjEua06h5TdScMcqS2H1KHmkx4iAJ4Wvt
Nj5U6jgy7DHm/p+ouXaoxfHffETHXe+4Q6fBNw6IWnvvCQHdAyqFZyRUfSHxvAQ3iiaIyGgyUBv6
uns/QsW5jexr309AHZPGYG3SL6BCutxzpVIOZTXsJ2r1+cpbCysY0rnFUcPVNhomtGMl4SyrWpaJ
YX8b0E6cetgLVU8wshzRvBhCNJcgDp5BcK+7uNvxRAKDpXFGO25FavlRkkV8/76m+reRPy3DQQNn
kTFo5tCWPCAS4x9F0TJxZz0PjTk8SLfpObED0Tb+yuS70nvaX0DbaEhDyhv1HDRv9p/GQVY3jfO6
RvNwWsvKHf05rgxT35NpmI+N79WrUojmklfR0I2ysyadHHZ5FuJBUtxIfnrxHrXJZSOD2iDVmaXZ
XQKEKNWVYVUWflcoCEvYDasEjEkcg2Hj1UGSue0Xj6aq1c6d0HbDtmSQGzeteboV5DQLniisdAzn
EorbkjIwKuk9Gda+/nHsyQCLxOuSyQTGp2j5Xcgv3kCm+Qt27twa6iM6VXsA0Ticn0QtF7rMDRno
LYBfot7cYqCXjPAJKHVBnFACRsoCg5UWt2WbqrWtT1245gzRG+AK/8iD6UgaL2vi4s2lkZl3TwdZ
Mwqvz2SGCUD/kFP///sNNGHR45AB/RBNQ5oQZRuaGD7a0evbkn21QQOQKVLXfoNQOcC47fKOTvbQ
SHOLOp7hqAzdwNUi4/y361kCGYqqRFGYSerEa1IT0zm9ymURir8LT389QcyeszG84QIm8X2FeIpn
XwZiTl0UQkzaEdUdKglnWduieDLwN1CEDR3G1b79KFQJ9i406JKWY7dzGGPlOaKsyOYpKWVAC70H
SlFcobUN9e+ifeHnw/J7FE6TJIiD64tgmobjcZBMp+EsCcZpEpQ2Xp8F56M4+HuQBy/qtcEHtS4t
RU25bjmythWjSTTBntXyYmTtLkbvR48OR/tP4yCeVS8Ozyubyr/SnjiqXyWzcYvN2vpfWuenIGIq
qC1dR5mdl7yNju6FKiKXbfqTbkkTs0mYNs9Bc0oc5ZUZT9pTyxv7P5qmHDiWOBPrlfP5xkjrGnOz
Kp3MHsyc1d3VLXyTxMaVYcwFHkkjTG4k72Cwdwm4JRWc4jSpuuw4jcJJFqR5WJpeg059nsZVVpcj
a3WFqlJS5/C5WV7YuxXKLGCVHyflXg2r563hqd36kIBqb9/i8VFfV1i2hiYWj7qL+NzBrz7E+HVX
5ya0k5hEqwuw7pbXTC262p7DmR2bU5CKMxK8TI1fG8grJW+YB0mm0NQ8xrNpBZrCftQP0bh+KHGp
nub1ypIZja+RtVE/NWuj7tLCfM4CdVD1kHfXqKe5Ya76aG7rjqzWTSs2jWd5VQaNX7W5qiyScWx8
L5z1xei8qoskq2sniaftlBpN2ub7omstXfIeGkh9hmcBgYM679apEOOswv5kFcQC22bgp7l4/+lY
t5GSGlr8WsVa99q2/apCMqF2abv0ALh0hxyzaxj700dljNHTsjLebjW1NqdBXK/ZG48nYZYHe0nZ
MetE1KXWBP1VV3sqC0/aiERNET9tzVbfTR1qyFy7dpScPDt2Nq/dBafo6RUsVLV9aMMU29MfdeJb
3Nzu+5V74znlLyLc557LV3g8bCZ1PbUzQQdz5R6wJjaAUNmedN8LJrO3bqIYz9577l29a0+Omgat
+CpSUOxS/aENySy3k99aGOLJ3NN3nxPZ3V42K/MyNKMhdnZ71tKQKmUUXj8LOtVQCpRS/CZZUpN8
JWQqxk2zhlGb52L0RskMtTNudta6WW2dVZweR3WTqI2s5M5/AdRneQBlbmRzdHJlYW0KZW5kb2Jq
CjE2IDAgb2JqCjQ4NzEKZW5kb2JqCjE3IDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9QYXJlbnQgMyAw
IFIKL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1Jlc291cmNlcwo8PAovUHJvY1NldCBbL1BERi9U
ZXh0L0ltYWdlQ10KL0ZvbnQKPDwKL0YxIDcgMCBSCi9GMiA4IDAgUgovRjMgOSAwIFIKL0Y0IDE4
IDAgUgo+Pgo+PgovQ29udGVudHMgMTUgMCBSCi9Bbm5vdHMgMTkgMCBSCj4+CmVuZG9iagoxOSAw
IG9iagpbMjAgMCBSIDIyIDAgUl0KZW5kb2JqCjIwIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3Vi
dHlwZSAvTGluawovUmVjdCBbMjYyLjA4IDIyLjg2IDM2Ny40NCA5LjA2XQovQSAyMSAwIFIKL0Jv
cmRlciBbMCAwIDBdCi9IIC9JCj4+CmVuZG9iagoyMSAwIG9iago8PAovUyAvVVJJCi9VUkkgKGh0
dHA6Ly93d3cucGRmZmFjdG9yeS5jb20pCj4+CmVuZG9iagoyMiAwIG9iago8PAovVHlwZSAvQW5u
b3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzI2Mi4wOCAyMC42NCAzNjkuMzYgOS4zNl0KL0EgMjMg
MCBSCi9Cb3JkZXIgWzAgMCAwXQovSCAvSQo+PgplbmRvYmoKMjMgMCBvYmoKPDwKL1MgL1VSSQov
VVJJIChodHRwOi8vd3d3LnBkZmZhY3RvcnkuY29tKQo+PgplbmRvYmoKMjQgMCBvYmoKPDwKL0Zp
bHRlciAvRmxhdGVEZWNvZGUKL0xlbmd0aCAyNSAwIFIKPj4Kc3RyZWFtDQpIie1XTW8bRxK981fM
Ucaao5meTwaLBeSNrRiBF4FNBHvQhZZEmRtS1MqUFOfXZ3qme6an61V3k6LtHAIDMsnqqq6PV6+q
X80np2/SKE3ipI7my0kloqpM4ySP5j9GJ9GLaP6/5oAYDiTRVGRxIVq5aOXTJE6b75fRSdx+T9rP
r7rPSGSrRYZsrmVJned1+9MnZWn45dphYKFPV1VVtr+sDemN1hR5+31LbN+vjOM7zhtpISvLzsjG
0LgQQgxKqXLwM3YYhWQrmY6YUa3cfix2riv0T1eBfnU2l/TKJe9XWhRFZ/WSHgK+3LKK7ecvGoyp
DUZRSzC2Nc2ycgQ+BBnqVn9oYdz34Kpib+N6jPKIKr1z3nLjLcAiAL4dcB2lKIVS2BkKn6h4g8KB
Jn3YHpk1W+oWXtF+vnuwwvtIe9kBL2DxCufLMLih9hZed8ctoI0O8LvnPfr/A5sew6sd9cqPtM+H
BAvNYlcc/voNv/SjZNfncQzPbGbbtDO9X0TBGKZNS6DZUcXtFXVjMY4GsRtXUl2/pbfk787Ow+tn
ZQjNmrC62yGp7xyXBVSLnXsPlAF2vPf7Naluy2nazJB+hLSyR460QZOjkUzZmR0nbPnvaOiLXVhk
fH9mgrk9HtDVa515tSjchptA11qdQDrfm0pHN5mLypU7sx/d2kv27n1ZJ6RXCejaz4I5SvilS4cn
YNNyxs+m3xztqSx9IZU6tUv16M2EY4+y+Uc1zx3Hz35Sd+XQrPrvPOUblL3z2rx0kAAYE9y0ol48
l+72ysajd5cw11LK0jsXF7I7VfDc+9yHN14VcHsEiUc5H0aDiGelnA3qdXfiGJ2DOrsOOTeMjZ2H
h3GUDuLcK5OQydiRZV1vAdkzGeSJVGPiiW9a/xLoHzj4ufG7G+dsV3iXHtfzdm1l9SGIAzrxxQsr
5Jit8fi16+FTs1+3fHE8PHTgFDSYyTvqbyAED1ohj8OQQ5LOvJW+6626mQcRgXb+dR9Pf82vRk5K
y8BLfqAXSUJz847G9ROp9h/hl4jUyoEwnc3HinHPrCKLi3brVgBnAa9UqipOcknD7Z4+pOZn4nuP
B/X9CzFgXfUVr8ZdlRZ1XRtA3WsVUj6Vcd25dPKWxctxd7DnpvH1fFKWEiRllcV5Y0Nmqf1zfx0t
pawSWtaEV5SGMM2bN1rNaEph4zGjKoQcU4yqFNas5qyKs5LTbIR1zqlmVR5zgUpZzV6aF6n8GatK
4YxNUiFq+ZlNr0x92Rpof05T2YGj9GKpziAjVVnCUpUILNSxYqkOB0tfzScSLoWQOVCdSd9a7bep
RVCj5xBB9YloDB6PMdQ1pXXOcGGWkpbOSqwwxJCYBo7XmWXKd2Yn4zoTaurOxKoGrtjOZDQHzPGd
iVUHQPKdiTUNtPKdiVUNKLOdmc9cnYmlOoOMVGUJS1UisFDHiqU6HCxVnZknz+tMQTszbTJx7M6s
Z3xnVoJ0ZprmaqchN3WNnhyvGZv0ss3YybhmhJq6GbGqASW2GRnNAWZ8M2LVAYN8M2JNA6B8M2JV
A71sM2ZVXNY9spusWULBlKUVcVXBRg0psapLBs3qimGzhpSYVeXEVlU1GauDlFpVpYZmVaWx1UFI
jGoUQKMaBNiqISVmNUKgWQ0QbNaQErMN9SVN06fR/U0k4dAczcTANZ/ohr1jHpDDkR9OT+mL7Ynu
/E/cKcA/w85/qY7kdZZ1Svf4DcN4t/NfYT4i3EvNVolFPnamU74hlw+JEfRdUwpldcdYxY+f/i23
oJY2jAdmcqQ3M9squFpkZdlZXVKrizWGxRhFg6unenJ06Ht/HiXtvwaGzRSOnjowNoAVcoRuJiKv
4+b24af15MOkU1G6LYQTrVnK02nTJzkFe3uLNJibeO+fnurt2SlPRSbHYntg2Alec89TCrRROVbk
0IYWduGwRKqvnSaoGyrxQOytjNNXgbbHAGBxbzmE0Knc+rg1vHg8yAtnYDcPjI/gFlhJOxLrFtDE
IdF7dHCah7vXayPErYtmHcj8obvr9E0RpfJkNG8Gd91gPW+L0yyNF6Ks1JlsOJO3U6c9oC2khoWs
3U7oAs0kY8yRJAt0v86sbdRRGU81wQk/p0OKZtzeLj1y94habdhI2El1xdw4nL50OOGngRiAZipR
09R9Jo6Fmj4HPxPU9K06HvPeyo4A8kc40XgTZyJkL2oZD19itP16i4qDwMD1gr2nbb1hmm15f0/y
v/ha+XcAq9lm/yLAkh7Xde3pRLpndiP4bq/k3155q7uyqvsYTnNHdNrFKBpAB47f79gjVAPcR7eq
jWXso5uv4cIUMEHs7I+2gxV7qv38W/C2M4p4HMO15Sk/Ovi5dAhRWe9N9EKxqzgkAQHNu7T9ZXif
vCC6o/2m/7U4Xc38aROtfAgV4qssd/1tlpjb97zY9DACfDVlasLY13+fBjzstdV+FlYYhSErmbvA
+8GzDAeT7ksPzTmmBI0tLcJH0gjRvrIFPwPbzxcn7ipfvOB176hqyFR4XoVIQ5vBn4FgApgviKdI
r6rvN7QEbiY6CAWm/VPDwEfmLjCTPM+EAx+fvg3Ks0XDx2cX2tJfOH18mop4VkpGN8kaxuxgXIBd
MF4GYOz4vIEl8tbDHnBJgksZHsZwQAUNXzZbh9fuwcWmrg0A0IVA0X5i9wOdUP6Ez4Cb3w3qGyVj
RePbUICgR6N1D9wyg98q/AprEWfS7kGi3ncPmlqXP6KB/S3WnDQtcsuXPJhNj7WipPaOUn+VqefK
ycv+DlWuwAAGD2ZmQH+dgdR+nvb6ed1Z/Nc3nERjZBhubZndDiQdzBAbDAGs92xaM8Sgt7812wwr
27sfGQ/QWkdm7ygrriUMv025jiiNGDlSGe76r6UteDjnNl8khjAZ4iyU7j+sXneQbWzKEurlOUXf
TwQOf3DcotxNjUsKknSTCOw3qPu0MGEikdSscuPASKAWwqoqTnK5/1kA+5nE2A9cTVHEwLe7GiKl
6aZakd2wNZEGI9TVfn64Uz6Vcd25dPKWYuFXDtNgXdv34oPT+Ho+KUsJl7wo4uaGNkvtn/vraCll
ldCyJryiNIRp3rIL1pTC5ldGVQhJt4yqFNas5qyKs5LTbIR1zqlmVR5zgUpZzV6aF2mcc6pSOGOT
VIhafmbTK1Of5/K/9uc0lZ04Si+W6gwyUpUlLFWJwEIdK5bqcLD01Xwi4ZK1uSQ77tk52THwSpsR
VJ+IJqnHYwy1dlXWOZMba9LSWS0EUiCrcLffHa8zu07CndnJuM6EmrozsWqPK6SqOpPR1JiDmqoz
saoGJNLUnYk1e7QiVd2ZWLWHMpNemfpMuDoTS3UGGanKEpaqRGChjhVLdThYqjpTiOd1pqCdmfat
crzOzGCjqcaqSGdWaZa6O7My18HjdWaW8p3ZybjOhJq6M7FqjyukqjqT0dSYg5qqM7GqBiTS1J2J
NXu0IlXdmVi1hzKTXpl6kfQYb86YknQmUY+L0sm4ogCbWgSN6nphq7pewKoWQauqlIxRVUpkVImw
UVVlbFVVGRhVEmhT1x/b1PUHRrUIWtXQwFY1NIBVLYJWG/5rNKI0ur+JWiAkcZkPhEPfsrudRSF3
5MgPp6f0efdEF/8n7hTgnWHxv1RH8jrLOqV7/JBhvNv5rzBfEm7+3CqxyMfOdMo3zDNThizo46YU
yuqOsYpfQP2DbkEtbZwP3bvem5ltFVwtsrLsrC6p1cXGysyVcU+Zn+oB0YHt/XmUtP8a1CVxET21
2EsagOZybG4mosibKIyf1pMPk05F6baITbRmHc/KKK2FVCLgbq/RFnuA64em0pqKltC6FWDI8qW/
4GxtwBvWyjsx2n69NY5ecZaGYRwxEKf2xwrdrl8gGUgBRLGy/xE3IPKI4te+mKRM3/KJ2liEnvAZ
sJ0YJ45jklVIw61cFYScc+UtiRnVLXdceVSYjXhwsZMjFzrhaK0nMX4oGFDR1PcmlJfdlWZYmEPP
NQkFRnlHba8peQ9NO/AsH8aQ8Z547ZECYnUw+IrMrSE5D4wbgZzH5fwxvFdGh3Y6uf0UmKZCDoC/
15a/1xbX2gK2EL18ZFUWZ4laPppVYGb+ZC0fSkHIl1PabeXMzqENybeCBKdNYUrb2j3qukvMPJSA
SINRKnjuhBy3lVU710Bx0AKaGj0EVjzR0fF90KIRxLMkMO94oKDkk3PRIIQSzH+MlL+ls+5DXwWd
0Dlzka0z4qyf6MVnxsXTjCVvnaP3bg5a8qUIYojRNjxeUvjdUQf8C0HGei/4kFHZ8aZj/I6qmsNt
AE06/9ROy0L99M9QUIY08y2/sGSJF7n9u2g0vDyr5Dp0RwDMj/w8xjoaR9qiZGF5Ri8Rbx3WvGX1
L0Fgx/BM57DtlHNt2BPB1BwhAr1wVIbhSxXxdie+gV7tuWVzXRow9nwmj/tuDH71USTXLNkaQIf2
aSYD3rKUxlY0RpPLATSeN43bz8EPXULj+J0SGqKDLmnHuBaHi5N+FpNt1lv4w2hjOPHu7Nyc11Yu
Hg2ZuHjBNiLXE7eWPbZW7mS6tnwOsPsuj6CwG3o/i0V/jGQZIKXDeHzoU+pdd4IA438IuG/qJ10q
4lmp3hs0tftQ8Zrmfh3CZWEb+gjKZjHXZtoDyuYaqd+Qja33K80ZwmvQOwXNefdmCZvTv42CtYUW
0sCHhYb4O21bQRgGHWitZDz7rfrS+AYm2r8O4Qecq++wiDnNMnnxvSyCR2ooiWyXSK7mY1F+rY4/
aNH3bEckt6D51Yk7B2E7uhY8avffBnd80kj8e2HDNhDUGyE04mc/tC6R3tXOPaDwPNtGl+DEIk1L
swhvoj7IU8N8P4JVg30JqafVX7Hp77/3IwvbTYNwjlSmIy+lPU3YW3YYMcC9i19uHFNhaH1uXfdF
EpJQdvO0Ibxlirx/D4N315jAQmrGMw2tk4MHfQQ+uggBDK2UhyHHPZYe96IlH3hGZTTXNFFLyJ6Y
PyU5+Qmc8v10+kZEqaxtNF8+x0oWyQQtJ9Mij6a1jLR/23QB/tLPCRXxjzqxSQeqNzoDSm6WzlhI
zBnd5KDTvV5Yyjv7wBW0LuuoFnuNK5GOHpWsxU/Y3V5+Z9+45OIdc844XubyLc7HeJLYkY4rwSdz
axvYMQokVTZ7pmaf48o+2oVyRPbZc+/2VltOojS6v4lEnktkJ5rudan7JXBWj4uvPYxxMafD3Uum
userpnSvhBWNkW1tq2Pu13OVhffnURIX0VMkSiFz0fR61bTuZpKVVZzn+vt68qFVSFqF4fgsruWZ
SrZ768/9dbT8Exzyj/NlbmRzdHJlYW0KZW5kb2JqCjI1IDAgb2JqCjM5NjAKZW5kb2JqCjI2IDAg
b2JqCjw8Ci9UeXBlIC9QYWdlCi9QYXJlbnQgMyAwIFIKL01lZGlhQm94IFswIDAgNTk1IDg0Ml0K
L1Jlc291cmNlcwo8PAovUHJvY1NldCBbL1BERi9UZXh0XQovRm9udAo8PAovRjEgNyAwIFIKL0Yy
IDggMCBSCi9GMyA5IDAgUgovRjUgMjcgMCBSCj4+Cj4+Ci9Db250ZW50cyAyNCAwIFIKL0Fubm90
cyAyOCAwIFIKPj4KZW5kb2JqCjI4IDAgb2JqClsyOSAwIFIgMzEgMCBSIDMzIDAgUiAzNSAwIFIg
MzcgMCBSXQplbmRvYmoKMjkgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9S
ZWN0IFs3MiA2MzcuMzAxMjggMjQ4LjY0IDYyNS43MTkzNl0KL0EgMzAgMCBSCi9Cb3JkZXIgWzAg
MCAwXQovSCAvSQo+PgplbmRvYmoKMzAgMCBvYmoKPDwKL1MgL1VSSQovVVJJIChodHRwOi8vd3d3
LmVjcnlwdC5ldS5vcmcvc3RyZWFtL3BlcmYvYWxwaGEvKQo+PgplbmRvYmoKMzEgMCBvYmoKPDwK
L1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs3MiA0MTkuNjIxMjggMjU0LjE2IDQw
OC4wMzkzNl0KL0EgMzIgMCBSCi9Cb3JkZXIgWzAgMCAwXQovSCAvSQo+PgplbmRvYmoKMzIgMCBv
YmoKPDwKL1MgL1VSSQovVVJJIChodHRwOi8vd3d3LmVjcnlwdC5ldS5vcmcvc3RyZWFtL3BlcmYv
YW1kNjQvKQo+PgplbmRvYmoKMzMgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5r
Ci9SZWN0IFs3MiAzODMuMzgxMjggMjIzLjkyIDM3MS43OTkzNl0KL0EgMzQgMCBSCi9Cb3JkZXIg
WzAgMCAwXQovSCAvSQo+PgplbmRvYmoKMzQgMCBvYmoKPDwKL1MgL1VSSQovVVJJIChodHRwOi8v
d3d3LmVjcnlwdC5ldS5vcmcvc3RyZWFtL3BlcmYvKQo+PgplbmRvYmoKMzUgMCBvYmoKPDwKL1R5
cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsyNjIuMDggMjIuODYgMzY3LjQ0IDkuMDZd
Ci9BIDM2IDAgUgovQm9yZGVyIFswIDAgMF0KL0ggL0kKPj4KZW5kb2JqCjM2IDAgb2JqCjw8Ci9T
IC9VUkkKL1VSSSAoaHR0cDovL3d3dy5wZGZmYWN0b3J5LmNvbSkKPj4KZW5kb2JqCjM3IDAgb2Jq
Cjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMjYyLjA4IDIwLjY0IDM2OS4z
NiA5LjM2XQovQSAzOCAwIFIKL0JvcmRlciBbMCAwIDBdCi9IIC9JCj4+CmVuZG9iagozOCAwIG9i
ago8PAovUyAvVVJJCi9VUkkgKGh0dHA6Ly93d3cucGRmZmFjdG9yeS5jb20pCj4+CmVuZG9iagoz
OSAwIG9iago8PAovRmlsdGVyIC9GbGF0ZURlY29kZQovTGVuZ3RoIDQwIDAgUgo+PgpzdHJlYW0N
CkiJ5VfLcltJct3zK254RUUIl8DFk+2FQ+0ZTsieljo0jPaGGxAgSFrgQ2xQVHvhbzdwX/XIk4+6
BKmWJ7QQAVRlVWWePOfkz6cHRydFNujn/Vl2ujqYFtl00s+3f/8lO8zeZKf/fdDPesUwL6qvTsuv
ervlo9H2q0V2eFWt8r65qL8ZFOXHJszu7783+4tR+fnO++2y+W0wKeqfr0nsBYq93TMsmhXnzH3w
pafT6cQ7Klh0u2QO688G9Ve/X3kPmLPn2H+WXraUXtbeiHlZlGPvldVJRycDB4Oq5v0RA4Ndjcaz
WbX/tD6wLtlVW8XxeFzweAjqvPGueNXGGw6rBzy0qTiOQ7pnzL0QXN0a0K14gC4lYIQ5Dt648GI8
gh1cWUgrNB9v2zOCS1ouJgIWlOeChL7hWzG+Xv35ksRYNyvqAv0Bk+5t2LS3bb968rJaV40mLD4S
YiD3i/yeRaAh28NCy7ZL7VxO2h1/j7ibKPRBf6gNxvTLZ3vPAt7mkIouGGfG51kxLzdcd0Q3xl3H
vOKcNC3FowUSrwUj0Fygs6P2iK8SISCxbhfRKV9TaEklP6+2z4Re2D0xroaDlmFadRts1W0nbpCS
SGN4+cHE2ZUToHbhI9yd5jAnqdydJpeUS2iA4WRSxViBTuNbebEhr04GjFnCqQdA+i0DAYtNIGXv
9tbD2CEDzD4/HYgtGu68AyVVyFMhhc28vTtwemIDADSkZGTte+QENewPixrg/0Kppal4jPPADxn8
n3oLj80s/CeR08J4Keu8seRfAWRGwyPDo1SuXHtAP6WhSaAf4vihoLbnr0V5kc6WSxgmVx8AFCq3
WLUQA9ENdOOWNmuxU8W1owjZQCUS3tsuibO0TiR5JsxzHf9WEABxbIT1TKJmPozFLSWn1covkfTn
HDFL3qTnxetxFNuC7T+EMl+hWrCP/wrJFeSiffkHWfla3+J1X+AMsVEq/z47/PKIX2a3w47sVbui
PNkp2n/69wcP3ID0k25xL/hNfeM6ekTuHVCcvYl/9fl9NNoRfJme2ayShL97u++Ys91qgQFcRtoL
Bj5C5AhOUwx96hy8Q2vIYYqgCbMrHtri6QTA8DpKgbGRpNUiarvnT2R3mhre2na4XTcPvbcpirV+
HgMm4R0Q7r2FkIQnIfYAGs0qOnEqiIc83m8if2puEnnHmuewraL1k4jzoxfwgTkO+1nQqAk4/wVs
6uJpdYLGI8qlTI/U8Z4dcvUJlOPjL75avmGQFdeTI7Wl040iP5681GDw7CTWn//w314UBccEKqfj
Pr1k0gdpjp8WBDpJmXcu2NeFne9NeQyxmEYzYo4EVUowY4I4a/ydqH3cINBhWCJ4cRq2sJfOlCXW
fzTsDcBIRk6Z7p13IvCROmOhI91oeLyYgb7I3HTHg4CZZM67CAXsqTigOJNeb0BeE6eVTpZ3L2YR
uyYAaiglVqLnjALxwsTU79sruFGpGOb9clQ69L/a7Yqmp1NjKgX/aTaw8dtCXHo7KBCZ7pRbs8XL
DZ9wycJozSHhiKJZ7XRnLJ/o+5GNVmWOox9WxVU6iAIBV9F1cmwKu+LsRIjPmEhp8nRVjzpak1Kr
MHq5sBJTXJqg9PNoyXkHZuBGTWAHYgG2Ip7VWk6nUir+Q3gFEd8UoPEDaXhizeT2J1bE2HPIW7jh
aZiXqhEI+zepRzghEUT2EtzA4CNExmSJN7rfP4FBEM0UJAKEleZ2n1qpaE/++Et0Ts5i9JnGQ+0K
kLNYK1IGxgSrSQYHIhaS2TC5KN2g6DiEOQ65KFFaE+dFAFNuvlUYgQ6YHVT+TzRVQNPKKxPybBxO
6ij3zBtdT10wx3ZAVcAniMuq1W+J1nQqiwmH9uFTpSFF+nQmws6asFtqKQOSUQz9Nf8Y7/Zr3PaO
y3/vcjbf4QbpFO8L0GegTROetAGKEpLBtu5p6gytA9gQS36VoUt4cQ9iIktdg2Sjs2nwNhgx5ulD
y37mWtaLAnkyTbn78EOImS00x3fMvHscicYzuTaPJIc30Qo0hjBXTRwmEWHsgaq9mL6EjUY7DXtN
ftSdYidnpM52TYA2An2xrqO0/XneVWer3HFou+SDQEJnRTFhEdXc4ueouZewnBZ9rAO8sD5Csx3V
qvzwuQN61tcogF5mcoTHCnAe9TIRN+U5/0wD3v7Z7VPfazbT2MqPTFCPq/hfIP8zu8mRYmexaiF7
wUcurSYf54q+UVcY22qn7oNm05Olnuu1E5oiP56UQhNykjzxMHfVp0z/FIO5qIJxy024Dn1DcLzY
gfS+AMKEBFjFSeIaTZe2dSuGeb80CIf+V+Oi8gwuM6cWla5tOugtCFLAVIgAOCQs/NTeM5VLtGYR
AdsGppCxFTpyN4CTDmONYQAMJ0h/vViyfjAPYcAFqwobVNlOJkGZwm7skQkHem8zuP09YIpJbxPA
w33Cs2L9iMYaypNunISmnr2mT8O3nCam+K9zkGvwhFfnL5NsO6zf0PKZOrvKAcgaJ/BJ7gWJde7l
sCGVU6ZTHUqwHfKQu6cWxWCNiZ/sMYiFRAUUg+s1ogdg0yTa/Sk6uTr66GScDXYbs9PVwWC21f3K
B5wVk2m9YOgWjPLxZFf61igcnQy87cN8NKp+NhW0E/Xq44jLy16URnYIt/LujgrbybbTeQ+NTTQT
Dq5svmK34d/wX7H/4LOjzAY+E7I/3y7teQmpWKyaTuQENwxv8368/PuboFYSNJCzZOSPBz+34To1
Y9VPZ4c2FVh4ex4fOiaARYdzyQLmk6TA5FjRkNZS+dkbFWem0VSaNaDeOIysGWTyjCXK/6AeCgMo
fXmkN+FOqX+/Y9KnOlKQb+oLEKXRVQgpzxgfgkrKjxmGP+dAins7Ld66rf3I8eGg/XlSlmB1MM77
o6wMUMt10Z/WGNvQWKMtBrNes7wzoAtyjWK0+6MJ3OwIzi6XtmfvTWKR7IFyx/gE0hx0jm+MTRyi
a1hDs/fRgXf8fp9WdVp3yH8rA/erhS2hWaXmJE4kNG6aFgL69xswchpdBiYvtz752qndRlm2hnqI
6nHOqWi03HQpJdeWEc9HwYWl9IpJ4QTxpeuuWVRpfOPgXf79rcN7m/b/TO8fOEAuWe0gU38z6pdk
3mq5nk8xh9fcDrIClZ0uij1EuOp/AH23BEfMhUWMEacJQI3mAcXAVKV53/ZQG+83ipyYUvLsxX1B
+erZrErbqWpxLiAaTHOmolIbuUZ3Kz6557gyQT8B0e4gwzbP8L3dQvpUxJUVs2LsQu75I5qKCEtE
AhDmLjIiAXsf8VEkQ2mIofGiwSQNuQD6cdvFLwL10adYaGCYwl4as22hxYThku9sA7JAcaU+abmO
tzBIh/+sTGwyaYGtg2kBvltydjfM2WqD0RiQUNixJtE2KW7evAcQ9l30mzAXsa1zbbwT++qvapbX
aHWy82ybNnFACB7rF5zK3bpNNpFTQUKhzzPRJOJW1QIjOHafS+hmyb2KDpxTkH2oZv05vvOgJbNJ
ee/VwbAY5sUsKwmv5rOiP63ztaHcNyqHkGY5rxhROpZRtiAYjU4NmPfX8GtG3EiGrd44LKb5pJzk
tpkvsyhv43iZ5CFMdYdZlYEPcVWy8bANDdWRb6Lc5tH1mpRV+dod42ly4XDZz3pbJFe/BxPbB++0
nrtegzM8hgRLll4EM4kq4h1SZXtUmz83XkLZ7ifJY2BSfhVKRO8xLJqvmuZxxV7C1IHctLX4hC/f
HHHrZ/rOmgrvISfctcNjyHMXqCiKfqGQ5d8/QQQHJFqBtT/ywBzh12X5rCiGNJPveFTccwVmKeGR
q6RIS6pUGowklY+22KtHFB/41YBaGK8R1F23dsPCbu3m+kuouFFtu6G3WZs0k2sWOMCiFUF37yPZ
qgMDhqYdZZ74qhAjUP59xVUo2WcRC+q1kz7NRs2HO436lY2pyIx6Nm8XkbV5sQQFQa55OognRc6H
sW5yy4ETeYVfAzZ8dZlHe4oCDwmdeZAyaQz9apSV+gkPynNhdwfnt7Iy2Br80mW+IJGnI4PRJ1cS
bpzzGIkbj7QkEdilT2Cvxe4ILxa3F7K2QYn93lAmpDldZJFdMUFrErNjfihglFnGNKwgPFenXAI6
EQKb+eKcT0gXdGrqBdGqKsbzRcjOZ1iiTRa1qtQPYUpzGnArfiNvw1nrTvrZIHu4zHYUX+THk3KY
uKKnb6LT78mSn46OmjWxEQuGjiduVXWzHp8MN37yo0iYAl/KMaOR5granM+n78eWlPCO/hc0RMQt
V3SJTwrU5R1xNYjwrZlIBHc6rMTnVlEvGYYBab9fVv3419MaZp/+lvXLfzu85ePsKZsWWTEd55Ni
UMyym4NiPMuDr9YH/ziottR7a6y2O/ujbDCb7DaVFP9wka0Ofj49aI9pI5Zrdtg+e1N3ZL2vVwzz
cfXTezjb9fwE/+qe36TwE111YrMMCQb/hsUKp1SUmNZ4RVjWxAGCYHl4bACboj0d/Yrb9I60cmyh
u7YFY3nJPimNbNm/0X5OqDuYswweD/uRlPFGFMrvM2pZjYAyqwXNM6fvXXi3/KwEvAN1JupCMtvo
3SmnHLqJ+w4P2tPUccGHoUhQeSgg1mcTfOOeeoNhXooHJd6YFeL0hLyLeNPr79jIqGxA49E3E2oT
elNk8YWCPq4fLbYb5QGbcDh9pLFkBMr8mQ6ADhqeorf9J0qu170W4bSIbQg8TN8PS3k7ZHc4aVFj
GYMEaOx+gdgPQULnWrD6zwlIgVmVV0HSAIZUJ+gXFXCvlIGbYJLHp1txCKijCKeHUDepGbL42GJd
0qS1cWnPqMLPdyV4tOJOGSOd5pyBvOzDOVOYgxjsCHSDorKE+DJKTEXBIoNVzO8gfG3uPnBnDwfN
kqc6Sv0aylZrPsl0tLQNGs+b714CpaF/1igrzp7OwRzPXvEibCBeGcc1k0ePYHn/OaLhVt/LDdeB
4hGbwoQFYMJ6C16Ejb6iHGiU2NMQhFXCkcx+aUglWpw1biYz2ZVnT5wR+Tf341kkuLNGspJZ7ijJ
HwhoWz6nRMz31h16gZDP9Zw7Rcpx7r/1PY3wG5+Zs8NB+enoZJBNyvSsDorBNJ/MslE+njSNUvSn
9cmbdvlgd6Pd+tHu/16z3KAoHFu7aaiOUNC7jXZ/kLPqXgmuVW5pr0WJK6rN0oKRgMU2viw8kFrG
HHZuY2XZQfile9OFBxnkO/u0YFguVlRR06GnI0SisKB9BAw4cW0pZDos95NnaqzjMNU7vylcVwcs
xkW+7cxW1A6Xjy6fqmeuP1+q0sApX2y6rZZ/TqvGY6gO+RZNrwbBE/VWabHYiUE6R/z1rNTrgvJK
ncSppKXz5WlkQR8qWT6om97SFfd73G0B+fK2wn49UdlhvwM86mPmazyspsuOD9P6+1qh5RyYsHcC
XL//APpinWBUEyAdHadJeTZSOYTvy/OkRPGdwRbblKXWsTFy4R/8o2gE5knOVtY3feSVXWhvkCXO
MBDM8JZizWAY0p+3iPXJEU3oikoLkGJHcnhQuWM2q+B2GtZVcE02j2IxsGocPQxNHgNMirabaMU5
fwsdTaK4h/yDhi4HYM5pI2VkHrbegC1mCgplkicffvPlo+14x67PZZfhoHn7k3ePK8Kpc3oi5BRt
XoIapD6CZh6PU0sufSzszikG5jSIj5rPSkCfqL9FZJINyi+OTgbZpDQdq4PpOJ+NslE+njTZKPrT
+q2bdvVgl4Pd8tHu/16zfD/DXAda0sqcxjB0JtmopwLqnnNP9l7TSo1DNur5BbW2a3yl8u+zwyRB
lV/BnFyf9EajSRt3sfB2EIi7sjIXtFQvMdG58B+8aL1zfBQxXZKfD98hjGmAGnh6iUsq6a9vZMT5
Rkxhl05nynDPBAjSaKJhACu4r845ZmMpG1f0+cJQtKwPmB7nx4XTHBN7sdn6jM6LMYmkVa1ozAHV
aux1O+lmCBs48YUVVIDzSv0boMW33r9H8UxI5UeLpC5ewPQpRsNkTWxtFk9P5d9g9GsnME/xZE6K
AZdH9yzKz76JKUZF7kxMA9nAuJRLW+PC06LLWHdqlBJoU1yW6U3YAjb7GGktMCgYVOXfl8Kd0qmh
ww6yAvUUXSTNEOsOFQTopRUUmlwdgfx2W9vvjP3U82tcH1CMZvmW9loRwzaCddS+iaSDL2fijOSG
dQAydYqn6M7UNZG1hlvCIBgJgFgKTBzX3QZ5YCuxbX0Lhp95VIDP9jauP19aTQgJIJlr7P8IplrP
zQ6ciu0GDX8d3S8NwYI8Azy6r57AvmQDr5TqXm5drpPIqMpVEmaKdQff+E4w9TKdSnih2UQPiZ0I
rcfHNnfDyaQKwnlUFahBwsGgiBKuqo0ytpnySipbsV1aAKhWj2CHYEIZsWhutdOq0egZE5ehRVyZ
Ab10JHtW4ePrRLilNbmlx22i5AkAo62SztbBaJVOf2aFhkxzhYHisZreM/3wgpL6QNEQDY0ohcMi
frj8LG0OgE1AD1EZI6QL3bUoQlDF68WIiBK2NBXA1yuC6L6XrBh6it4bbV/Ia9hnd3AA4I2IKGXd
ZDvQxmBCf0EQEFyFyGWBeSO07NJSmDUYmdK8aA5Gs4+AVBOlNSRUX6PKecrSznE8XGmmaNzWjsxN
AwjIIji5oCl+4tH+5ZF7saYPprnSZF7R9KOMIqmdjfqIvK78+7OMgKhmOSjaf3Xj8v1ICkGGx2nS
HLAQCqwNE7g2LKUYXSsVGZKRUJT2cHWd1xIlvJM1pkXRwRvm+d+Y0O4+73zW5YiIMMj/e0wT7VDk
8WWwDDNpH9JUmm11nI4hrIlWsO6Oy3mxeW/HCcVWveEeZsuVZc5kPHEqxS8kwqzMBUHLfRBARLUa
TGLivCO8Zc0nNT43kaCEZINHSqNK8sil8gLyrZqreAGiAWb7lq8HLRpoo1dgI9JvyerK+oK7FfN7
3Cn19HqOM5k2vW6TMJvNwrzUAf7ggQ96MGFwfYvdKodSd0Ta8AO9f5MMNAvp/kIexiJggN5vKvVV
1Dph5iTQEEpzHc+1gAAEg6LKandMR/YUJpk2oGsvUijveSFXoIjG9oox+sO0V+4n+d8tGqnaZi/g
l0f+SkQIBFCZpEfvB5rel2N1K/y7OEoXnneVMb2l6gjhJy+aqZ6sEbmxv5J6pBeZhDhWIbxf51uz
apyvZfuEY5tUJy3ATG6Orp4nuCMdwb6H4bGOBu6bP8toEHBxwpSn9wA7NihQelgy2/W5Smg6l1+e
am+QmbfJABHd1zD459xhQupu/FTf38sNdXvJJVa7QCADAKJ1AM5mYi17ZHOU2r/SAOgsp1cwYF6F
WMnTIRCIMKuRWC1hIfDJ0Ip+rs49Ohlmu4usDnrjUdabHOe7xJazxjZUufLXNhv1WX9pHtCvTjpp
zq5/9wnFy0iI6WbqmUebN/GCJYy+e3mdrYZai0Ewp7ARr/B129/v4xNX3HuBei+Uw+9wPgJiIS8N
K8En8y4OsGE2kFSFL2l/XwuV/RoXSnjZ78q5d7dN5H42yB4us2I02gbafqqg2Ja6lbPjWVj85oY5
LmbPnb1iqru/au6uN4EVzVHsJlblUP96Wmfh09+yfj7OnrJiUuxyMejn02KW3RwMJ9N8NGo+rw/+
UW7olxvc8uN8tlszzbdryvs8XGSr/wNt8llDZW5kc3RyZWFtCmVuZG9iago0MCAwIG9iago1NzI2
CmVuZG9iago0MSAwIG9iago8PAovVHlwZSAvUGFnZQovUGFyZW50IDMgMCBSCi9NZWRpYUJveCBb
MCAwIDU5NSA4NDJdCi9SZXNvdXJjZXMKPDwKL1Byb2NTZXQgWy9QREYvVGV4dF0KL0ZvbnQKPDwK
L0YxIDcgMCBSCi9GMiA4IDAgUgovRjMgOSAwIFIKL0Y1IDI3IDAgUgo+Pgo+PgovQ29udGVudHMg
MzkgMCBSCi9Bbm5vdHMgNDIgMCBSCj4+CmVuZG9iago0MiAwIG9iagpbNDMgMCBSIDQ1IDAgUiA0
NyAwIFJdCmVuZG9iago0MyAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1Jl
Y3QgWzcyIDI4NS43MDEyOCAyNTguNzIgMjc0LjExOTM2XQovQSA0NCAwIFIKL0JvcmRlciBbMCAw
IDBdCi9IIC9JCj4+CmVuZG9iago0NCAwIG9iago8PAovUyAvVVJJCi9VUkkgKGh0dHA6Ly93d3ct
Y3NlLnVjc2QuZWR1L35taWhpci9wYXBlcnMvZ2IucGRmKQo+PgplbmRvYmoKNDUgMCBvYmoKPDwK
L1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsyNjIuMDggMjIuODYgMzY3LjQ0IDku
MDZdCi9BIDQ2IDAgUgovQm9yZGVyIFswIDAgMF0KL0ggL0kKPj4KZW5kb2JqCjQ2IDAgb2JqCjw8
Ci9TIC9VUkkKL1VSSSAoaHR0cDovL3d3dy5wZGZmYWN0b3J5LmNvbSkKPj4KZW5kb2JqCjQ3IDAg
b2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMjYyLjA4IDIwLjY0IDM2
OS4zNiA5LjM2XQovQSA0OCAwIFIKL0JvcmRlciBbMCAwIDBdCi9IIC9JCj4+CmVuZG9iago0OCAw
IG9iago8PAovUyAvVVJJCi9VUkkgKGh0dHA6Ly93d3cucGRmZmFjdG9yeS5jb20pCj4+CmVuZG9i
ago0OSAwIG9iago8PAovRmlsdGVyIC9GbGF0ZURlY29kZQovTGVuZ3RoIDUwIDAgUgo+PgpzdHJl
YW0NCkiJ3VfbchvHtX3nV6CSVIUsCUPMDRg4lVQltpi4Kj52jnjKL3yBSICiBYo0BZCSv/4AMz3T
3fs+AEnRKb2AmpnufVl7rbX/cXpwfJIO0lEyqgani4NJNpiMR8nm93eDUZKWVbX5eT44/HQ0OP3l
YDhKiubvL+3foypNs+CVzf9MJpNx/T+r9qW0LMvmpTl66Zo/yf05YN+of6/xLefugKyo/3xPnbc9
rnDZzNoj8kyLAV0S3UAc6WK4wdW54gPXMn/mRviX/sIE6LJ8h+ow55OExQLtJHLG4fPtmQdn3vMH
FFWeN6ndkZXFqOlqccWXNTiQBEU6zlzFVvhYGjn1749qTLsgeU6UXKi5i+sjunyF07vCNVguLYUm
ixTNswkPIohm/AwoJzfdODs0tMofbs3bHXbPjcnmBQ2zEBCwafXvS/n+W75gRAA7VtXEUcR1feBt
inreNnaY5km2lT/HU5jC8xQlBukPlj9GhG+o1wD3PzdUu0zi2Aa5UKdJgMTtmu+LoeTdFcdKkIjv
8Y16QMRsZ/l43FxxdhSHkASU0Jb/RAjrjr/Xvb1WWmsBvUIJr+mZ1KDMEYlJYlj9DYFvorKIAuZU
tQgvBGYNzgGf5YWqAD/gQ0IP9y0v19F49/QhHIsQ03eBG2UmCIl/lzsHCTl8FKGQwDHthD4LxgDP
l4gpILx7d3fEdhYJQpy8cQQ7Qlr00jfFdcVpciBsmynYX3i1sCSdk/0hnT1BFDywZn0Wod8FZEkB
4jdI0uFFRCk6NBI/ces5R3JhJzSdAoOy9PNyqlOJgS+tp1BGLuN6vsdXrLguCUFIruCGqx8ggrDr
c7ZccZegyyT2SpL7PtCjnZZVVQWF9Dd8sdTaZHCu+ZOQMfOs8aNR/fWlFg6zuqX0pgsIYBKOZvue
k2ArXJ9egbdTr1FZMh1TIhXjPp9qsqKwKVtiwYjEjd4Em20EtapXrOa/jk+yQbot0uB0sX2eT5Jx
/XwYBvCtGuJyGQQ0ayfbj8lvXMOwxkV3REtDaNh+waMczl2wOrXP1+iLu3lbhDQqQjZOqq4IYGUR
KZ8DtjArP4cc9wEdED69NXIVIZsEXbk1R+XgVZe2hmedd2W3ZSYWyZBxdEpIPyYYYiczFT3q2MwP
W5kUhcORZ/xTThhlhg29tDiJuIVLDANCQX5Ty2/ap6Kbf5njaq+CdNYmYDwm2SOOjPiekYY1kyi8
ztQX9wa/GUTAeqHd6Ova+LdbiqQ4agcSElUTOw9+AbIZJ89x3zOl3Qm36CNN6M1mgcQVWX3CNhsM
aAAbCrwtCf5bnZcQmARHzrTrzHxJ2EsCJypfvu6yLMv2qwcGtv0XFmgIqBmlQOQnyPvVNNlmgP2q
YmtiOcQuDV/eC4A+Q3puSGODuA4jIJ3mIOYJGGb2un0l++XQ9eOQUMgSS+ErDd7N4w9MASCy/G76
QH1hobI8U22BKjV8rxt8HZ8UfonI8iyptgP2XRtmtGOUyahonlKNiVdOtn7p7wVy5I5B9klD4J6N
woj6PywHdo19saWXFOXs8GkU312V5ZOkKgKRGYY3vbUcO6NKRRIWHuugjzPc7Ydd8DC7Jop4xGm/
S/RGaNZLmQLYFh/9FyZ62qQDzIdoNfoCSrYNtuSdZXiJveAvT1tVow/6dc0filjC15idcFeUBVlS
TmTXuDrgjXdSlKoF3cXDub/vCasOX5ErrDtN68RZBQ8SqFY2nsGDBCTvtoLt/7pSSzvw9ziKq66V
Eodz2fHjMQ+3nO0pToC+7kyaxYCvL/YgT1ZCObbnZhDFRtJb6h31qmkMJHPwYKyl+/uCT5IIWRTM
F9EJQaa3ZZoKRzZfxBtSkW+NYrsE+aD/GZx+tuHTC9Q8j9COoJZxhK854uxSesNn6S+CJh4T2Rwf
A2ebg21aVm7P+0eQ8QwH8d4VL9gfq2677M5N3MF5Nk42GjTMyqT1377bP9OGK+SLWRDMBx4v/OZD
2nfoLRVQxxvPLoBmcVeVydjVzl0WVbZMRh6UbWl5+H9PKD9xaVpssMpfWqBu9vAqUi/moF68YcKC
IKOXYEWTrSe8gN3VGaqDPUv7jVt8IRgK32524TzOcM/SLJlkrmsNVx2ZB5/fTZZcl01DuGtTLkAH
SBe5DWpDLs0bf+DrTSyNuE3um1u+AL2WRPg9kFRskFSnprojqha9ORE4BSLDSwtqVlwE7vyc5NjN
AYVToFfggxQcSDJgpGGn8RXshiBVCcot240Oc7/Mz5lixAoib28ulGw02TqS7eZQZg0b70a/cCQ4
4tM5i1AXbpmwwI8aM2ChXqrb1Ouqt4ofkFs+rgiLzNrXTcGnHtn0hr1FwwEmZAoxeHzDJkmQVho/
SgiB+lcPJ0JUvLcPQLjWhlLvoABzMhUdAwo7LFG6vFryukJrF+wM49A8D6kW5EeBew0y8hwmYhhm
+dNjeQmqBL3thHeRLV63urQ9t7aqBLWBsSR4WbQQV+xrO9FZjB+2IYoHoinDR/1jd1cb3ynR2B/j
o5OuolmZZF1BEQ7AKAIc4LHkUf0Go7pJd7NRvAp2itxvn4ftFkmtiaaOiBsEdgRXiDewFSDYqSXB
G1QjwpPpkt7XPzYXfqvOAOt3jIbMv/Tbo+n5Y9vYb+xs77HxA4ENQy+ucfFWV0IpDFbMl8Ns4FiP
hAHAOuvmgy8mjmSDkNoi0kk3ae7ZFx7kCxZW2iKAuAIwGaTuoOv7OOZ3fXSZkCuW4hJVNPsZTqLY
N77awPJY9xnGkbnI8mm7ajaSfvincjTiKq4vfwRVe2JfqQWVNEOhVFYVVzgQ+shggHGHidacHWKB
/bc4ZMQCFD4mHGanBIrbc+vOtAKplWG8R8hvsHkmrFOZJPm4+dT36E1wy+fbLuSpBZ2AbG1+MWoV
xYuCv+BdEucI7xkEQY/Sa4EMe1EU9eidxp9ZrceL0HxhTr7ybutheK7XNxSeDwqD8nPYRQvE1NWv
R9vgMDTn33LG1qQJj0Xskl1dogC5saOslefumRCOf+uKQoIv5qWMrXucEC0pvddRcABwLKxQrhgw
UIwPXuWkOx2X7r/O8mwCXsrqv7cb3rhG7Gb/y/IkqwZFUo7dmufeLavu3W4bHG8vH7bv+n0xXCiz
ZNzuk3/EJ5TJprCjSJBgkzJKl5saQM2ruoIWTpV9zk3RRjjhOoQ2h+6alEx384lPNyGI5meK/bx4
UO6ztWOTaTKuaj9WOoUOPrxmkGSj5gCsn3BQ5FBI4vP6aWz9U3Ci7kS+uh3gxAvZPihehIfFlVii
AHspLUsq0LsBKd6pFTvB2ySF/mSuBkFHZmJBV9IO0SEfywOxggKPEDvu6JAfmIEw1Ydv3ipuHmGL
wlpwNkvxm7jvOpqYQe9RBWQkRHj+V/rqbs/oJAXOenjCnAtBtdnYQ4Isw69lIvIn4QyXRIp62V5b
OI+ddeZjFxKJhB6T7rk+bb94wApDDqliaU3bgBIXmQhiBqyn9e/LHnSkTVrTHEFZTKnSq9xnPjHI
QVidxProm0IiTPjZof+8nYC3xCVkUUfBCOlsqRugsFTK9ofp2lSmXURK1xUf6U+gFmf5OHcf+dnj
phUm/GLFApAeRFZP6eerilwJDZg7Ji/GC8YF0nRsr5JbxO/JJJxh0ThYza0+Sh9jYmkS+yCkAWXK
zHejsvnszwM5XazAkHqFHYXltSTk1aMOTVmZjKstmlhCTsA5NEHrWDavHj9j9QdnfGDeAAaZHsgL
/nja8cfVKgo3e/77/xAjgayLCY3Q+tkQSArfhVKFNX5ODDuz5klEZVQHQlGCIxWr2tNS0V6HYA84
O5TKq9yoIk83/AShRg2g3AYFgm+Z9lFmpDtvKSSPauZf+u2l2wJ/xDdNcMcn5SDdpjA4XRykVT3e
01paD8+y8cS9k/t3imRD4aP6hfaENDgh35JD/biJLvduvaiaIr0CJUg5Wepi/TvTMrBhEMsCdh5X
bB+BbCrYoo6k9tHumG/Mx+BZ4J3XJwZPhHAGaGC9Qhftlaxgl+oYD1Hf/2YgapDFV8u7SdrvrqGb
NrAsRS4UOGT+HgWFrIMs3ePelSSc576l5DjpCTAVmybLwMj2wcaVkRJT+iZjgiAj7ItC5rld44qt
yEZTJcgz1XxY+3CLQtZjiptwg8uMV7dA6/qaFD01sx+RXA4WetaNh20G7g3uEgFrVI4ZT7nRQdsh
j0OMDWpquS1Th4/74r7XULmSfqFhHKUrVfcSCfTeFgsuCBKCLM0W8bPcOWbYzXC7oy2sMEv0Rib2
qP7tN1wvGj9wOYSmmyyLusQ0dx6BKSLs6nDrV9OsPnF/v9pzIntIiTSkoncEH8Fd0aLphPlpv3Jt
PT4pfD3KaTJy9Th8i8tVdk8jwofNQiJI+tim0emIJfXW7pzl2QS8lHWxjWsAb/pc46Dutmtm82pZ
4TTqb4btu1E4H7FIX4NseORSYIA9wYnmaXvTA8FzlNZPwchhmLKaMEM0orM/KTuKU1d2O/d4HcdP
UrPPltJt5uCc0TkPqlchBvWJIxdO95CwO3zzdl07kwHJgPkoeUwSDPH6ZoZbYAPc/pNk6fHNos0l
ILDxePvYQGBkzO9x4638rIEaYaG58dc1LjK5DJLYQJLQzPUt/oLYaxWtl/08G1NQAtID0SE7BZGo
y8Q89DxzOxpiXoMlRbMgDAJlj5gCfGRC1DWHv3EeJ0XsW4ztjAmYHs4LRin0yZFC7uNsSCIlgEmu
uyGT7+RbzrLMWRcqxfaVTMcFt5K5vy/cJ5M0ybZMnybb774b+ChSYxRgHGjWHtHPdlwrRf6hAyAo
eAlKcm/sMVog9S40X5PYhqbmWWqkGRygMIVbX16REb/8ZUonk5YPQ6a6Nx746ORIiPruCDx/Ajmg
x4ggU11T18LX/RSi9y7x9IqmXkmRDzqkqJA9crX/QpeCUKSnM83eznW3o3BBI4IgCKudTbJEsNrF
ZjHpuED2YUJmsmvqBUpcfexmd2k7cQ62PPsRhUyFPfhPCmwl1MUstO6mbDJJstqtbA+vMYDNdlCT
0MK9t1XA7ToggFsd3MIrOM/g1pW9zAT53LJfR2NL9BkZXWotIW7kNKSn6ZGt98xSzNWO4rgnZ3WB
cBviI/E+EdSz8j5ZfE50r7i+knViJZPsjk5yPZxCfMONkGqHs2vLEC1RsEtb1xABsSubzAprYkZR
5erfv675npvDd2Z/uCnbMCuTzGbPScjkmQgZtr+fcQUhum/5tHS6xXHBVSMiCUKMDPMgjKYEzh5W
87xPDWg5vOuLjgFXEYwHqITivK7jQ1inHhmQ3mqmk5RoDM/FyoWT6NW7vxjjGkAEANehg5FS8b5s
pDScvILY3Z6gH2iOpCJj4tgBRtS85FNt64zcC4kNVNHequw/StSh+17Lk4pR4/w+SOSWtZ0WNFNB
gya1CNwuHWWtclEgyyDdSwEgAuKk2pE+ZJ929ygCMWa8dMH18VZmuR2du7hjEPEpfXIPTSbwiiwT
lu/mirMsy3gb8RzkRpVbZTZUEE0jzw4JkebqaVsCff6cH/BtfRuGcrQ7HVp00BB77MQxNDjrfrMg
K4zxS24cT7oP/P58kaxT5CKxIECMWjBnE5JMwj1fWu+UkJkmRYcn2w9PR7DIwohSZ6NQmT//qyC3
iwUEFdbsAbyuqBoQ/c0fULqX/sp1XbmCVl31MAWDoUVY89X/OvXkbHFaVq6+p5QfYKLBQ6EQLYU5
6CNw85lC35BXxKiPXo2n6hMfkvvqHX5jedWtci2paYmuLGHTJA0nmgIAu7AiewY7qthEMgcbCh7V
ru65XBCa8yjca4hzfwZG0H9ur8ogYU/zugM3K5UIS+nBKm8oOqnTZIJ98EoN6klJ/TVDQX7upGZz
IV9zRcJ2CzKLonaQYXXhMOmvCjEcp34rNsW2qqonizvSMGzE/wStH76D38epdawmqlMAa4IiYsVk
tXDJ52oyv5639GGPsuNruUfnRY6UVqMlBQPBWwRnsbsIFvMp5fy7XQNDUvA91BLm7V+H4AhABMhp
/lOhQJ0USoV3qj28qWHasLnCRZParFP8FZdfBMhvGK4mnAAKub/FU9ZYm8XjR+PZnBTarsLA99pe
2TXkWfcKgUs1n0PAIm1feRBoqEPkUohmP9V2NfuaRbIuX/hI5C4AbGm8sbMgL7XNx9hYXtsrrzv9
YgIJhdjdQJ2CUJpzjk+KQbpt5eB0cZBXk2RzwGgrIs73H5+k/nmRVM3DvUFK6rhO8wwpTeK7d6ln
07GUYA8XTD7NNvHXKptV2xroRgdCCN834tV43wULoB2CFQGFdlC/rvH9V/ZDFKs3iodA8rjUSir4
BlwEzADusBuydYJlYxmFQLcyj7EIKfnjEQPTI7tTrmY7+R/2o+uXpK71b7+XwAM7PM35ckFbGTL7
rqvi44oTrh27b13qNMtbS56QrsVaQRTc4gN2DJsZd26rNEzwSyo73uvQwY9qMHQVQvO0C2zkieE8
MOL+JpQjkpAYZdYlTxddRJ8YVFrC0Zxcc7FE5XV5dmcnfNpV1Zx8apVIylxDevfxLoU2QpZnRYJK
mjRQBvExNWmXpJlZ1hcOiTruusMlMC5x3flceeE0Gpv27QWXmUzTNMljZlpxHRVrSfm4PbdYZofA
U+pDn5FXRZaEdUsSGk0m+ZGWK6qTTVmJRbDI6mWHXQTLZFQ0T/3gJJ4u2gqcQoy5jIpskmSBsEX5
LJdBcJ3RChYyKWFhrKTRt/hI1s3qPgZH6s5/rXKl4HUNxC1RbjhaH3aZnRlfq0tL+SXt60tC+sgE
o2DblKIPkKh3B/w9ePsCQOSeL6vBfVltjLQ2grSxoPRZ7lYgPU4LY9sbz7FMvYLtzD928RTO47wK
Hqc6cpQ1hd9LGqCxLl7ST1rE2WFnVUQiEWskjKN56iWit7UKAId3IBvfwllGhOpQecFmFs/z3nSk
bD2EBI9HybSvAv/OyYpFisBf0BdYBItS166hS+oYQGLI43EcJ90IM1XXU8PWFQainHkuWF8i97ND
hR4ZtYClQYMTfMAsMPxgkULeBxHhsH9+dPY4O5KJ+h3RM1S/fssAC2iEOG2wdFZQhE7zBQrkJbuO
E7ng8ZDl43Fz8WLBv0XbP9yVlh58F7qwRB+2i43ygTNxs1J64Q4Zj2vp3H7UCAVB0fEBuplcMOHD
dkaOwnsfDZcWJrQ6WZZHTC4CwFXXFa4ZuwFCXOfI5S2f9l/e+vefYj1MlKyTpWcUQoni/KR1Sflg
+z+Lg2FZDIZVmUxbZ7hBRf3mT93l7qTv2pNGTXonbSjueZhfl4s7rEOzK41nJmDHuxcuyNO3abp5
bok7S+Np5k58T4fbPb+FNy64fInF51y5/IauRwQTlGncCb6YN/CAFfMBKhXQmvb5UujsPWyUkNkn
5d6bj+3Jo0E6uLscZEWxteatJe9a/dCWZFrFzW8jTOhmDv3dC6a7j9fNYb1sUB1NqLPbs5pF8c2p
q8L//nMwqv9tyjFKysHDIBtn26JstpZJVg2uD/LxJCmK9u/lwduD5gP3ZV3Ikf9umlTblyfJ5uU6
wrv5YPH/NFyUXGVuZHN0cmVhbQplbmRvYmoKNTAgMCBvYmoKNTY0OQplbmRvYmoKNTEgMCBvYmoK
PDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAzIDAgUgovTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUmVz
b3VyY2VzCjw8Ci9Qcm9jU2V0IFsvUERGL1RleHRdCi9Gb250Cjw8Ci9GMSsxIDUyIDAgUgovRjEg
NyAwIFIKL0YyIDggMCBSCi9GMyA5IDAgUgovRjQgMTggMCBSCi9GNSAyNyAwIFIKPj4KPj4KL0Nv
bnRlbnRzIDQ5IDAgUgovQW5ub3RzIDUzIDAgUgo+PgplbmRvYmoKNTMgMCBvYmoKWzU0IDAgUiA1
NiAwIFJdCmVuZG9iago1NCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1Jl
Y3QgWzI2Mi4wOCAyMi44NiAzNjcuNDQgOS4wNl0KL0EgNTUgMCBSCi9Cb3JkZXIgWzAgMCAwXQov
SCAvSQo+PgplbmRvYmoKNTUgMCBvYmoKPDwKL1MgL1VSSQovVVJJIChodHRwOi8vd3d3LnBkZmZh
Y3RvcnkuY29tKQo+PgplbmRvYmoKNTYgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9M
aW5rCi9SZWN0IFsyNjIuMDggMjAuNjQgMzY5LjM2IDkuMzZdCi9BIDU3IDAgUgovQm9yZGVyIFsw
IDAgMF0KL0ggL0kKPj4KZW5kb2JqCjU3IDAgb2JqCjw8Ci9TIC9VUkkKL1VSSSAoaHR0cDovL3d3
dy5wZGZmYWN0b3J5LmNvbSkKPj4KZW5kb2JqCjU4IDAgb2JqCjw8Ci9GaWx0ZXIgL0ZsYXRlRGVj
b2RlCi9MZW5ndGggNTkgMCBSCj4+CnN0cmVhbQ0KSIndV8luG0kSvfMr6ihjzFJtpIo+DNBe1PAM
3B7bGvRhNAeJIimNSVNWk17+fmrPzFgyooqU22gYMKiqyshY33vx/GJ0ep4EcRRGeXCxHJ0lwdk0
CovfL4OT4Elw8b9RFIyTNEy4R+Pi6NnZ2TS4mAcnv3yq3hfPkqx6sG2+L3/v2ndRnmV59ei2fm09
WTw0j+Kk+jvAX4ArvllXXHXv0um0fr3Bt963Nju/1wvqVjqMpeTgHB7u4wKKC7kU5XHz6A/Lq+/+
1ztPGqlUARso2M7tO+7MGB6qfv9OJ9bOA5Fq4/WDptj168skSfQBgRuKM2nSPtozTpYhTiaTxMon
20Gp5Vn0rH57eh6byatnKsrameoc+oBu37G3O73V3HzbBTSDvjZf1EMbh7nrubGurZpTi2V3SZpO
3dQay1fIkraEcTiZOiUk7mnc7VE/Nwm1F2lE56exfs33ApUfN4NOBerrVnzEjm9UQzjWPQWdYwev
iGupe2FLD0iL05h2q18BG194uCGAef9ANYYbN1EZG3BUnXLVheE2HOpIPjB8D11CZzA6I/E0ab7C
sH7FtvHlyYuuxIaw8dxePnGRLGSzmuf1LRfWLbd8yfz9fEh/unmXmquHH1Q2CUe9ZSOQWUMktQbo
9FachLNpxw2QzWAf1acf9prMws5re9OL2xzboSmp4e1G/HzufO/nUg+0AFpXxGDMrtggkJ3azRt/
8cxrTmuwLSkfwskx9D7vvFbiLO7a3R1RolO7t3zJQpx2Q17oQNlGbpE+oGDgy7fFxAV2JM1UmRq/
78sIdPfZ4oF895/7HORlar2dMQkxnvz2zw8Yvv+rHjVQqEOnjQcxYNDoU81wosoK8zZk3OykPmP7
5dXF6HNwlgTF3WUoWRqX7yfVVw+L4Db4PfhUfNE8j4p/s1mYZ/WROCzszzfB6d0mDl5ug3ejd8Hn
4PnFaBJVBhqjzm3TafloGk0qe2HW/FfctSzfFXabd1kWlxeZt5MoL0mRPVqYnWRVQarH00m5eNgv
01npL3ln8467k7HbviUNF2moDEdhDga0q4EjOF7xSGNAvEOWNS9J0gQ2AsBMoHms7WbLdDHH/b2k
JQXETRPTm0MIlKesvsCRBpCSMzpwDDqRgzbW/NAGTIzFUpcap9rZPGc8J2GCokukiZsvngoJQpuZ
vVJ8pA8bRNlJ0S7wGZ7ZPM1nW5h7rkF7De+ayNeertpxpShmyj3kmw+4za0sF/AiYYRqN4VjdKBv
hMhb60shw4z3bhUtHnV2VTY7ztZFDelrAozYj6+BE4TSU/Seq9mEeyXbIs3zuc8zDpW+8of8MsNI
wYJpGqJJY9csVtLEIMjeghIAAIdfY0CTssje2E9wNYe+iP2O+5nEA1Q0cXtlFV4bCID2/qkzu9Ji
aDXQQmYRhqo4QwrcD6zIVnbcIFmFhQpElSpAcy+UoAS6J2IJLiVKtOFZD00KF+O8EHGxq1Jc5Nl1
SsAYSRVq51eFiH9Z8MFph5oLl9UU5gjtbh0WG9ynqdhDxA5hcomGy2qgVjl1vNdPRJnAbroTSS9w
+mFKyjNyhCindIiryKBZE8bbwwgIzQfhsLzXkaluCfOYfAbz0B8z+jcNmRTkiDjjh1Ia8FrmCuhi
28gHZFeCY+ZKO8D7e/KloNF8ktdNjMT1Qhq9lLhzbbTDabr4ssxXC3JJGkZZiXIn9qOJBXyvWSem
bh7TBKaGQSmqlWDjubvotG+TcHvXhj1ijZcTawcnTfbIJYU1yATg61kHcNpUpyAgDM/G5JpLqWTF
XiWgTGGIT1QubF6ZxPRAqA1yWsX/9YFvOG93PGg1afpOdxdMoyov/SOHHafht+r35z3vBd/Gc3KW
JOQCURkf33CB1iZfeHtSP+ni0uaus86QEhqCUAMq4f0Jh7MeWvefoeOhdheWNDJNRtnZhb/teKfT
2xoxB8Bs0M5kV18eDgq9oA94HggokMqrAHuHAOFMilsusI9UnJeYFRatBFDzBzUj3d8GszCx+dhP
PaewukQMlyceY6jUsBkIfBZKLyyDrPiDA13HteIDG3e2s7zO5N/5j28Y73/WeNuVTokTZIurdse/
fmIptiTbyrjkIVM0Mi5QUPh7sL4UmkG1kdgaHapj9muE4gQhmoXJkGASzqYlC2rLcU8AJQieoicO
jsdo+dQtOoS64LxQ6Q/6lo4yHoEBnPxcPnGdD2vvT8+TIC6vDy6Wo1keFjMelcVqg6sfjZM0nCRN
EY0XL0gvxnY0WDbO1/ir/R/KCF3bbQixCSGqfE3yxlfTDO97wEjt0wPXLv4mNi6vqHYhewPGyDcY
C3QoKjQqOBXGk7dvyKu1s7JCVR7UxR6Fh9wScZSS2AzArbtCWAAG4PbY3IXL46KxOXHFxEx2EhsA
IoglnVl6GG77FJjv3g1vBqxnDK1dH7lDhH2KXNOsjwRwv2FSzK4/qjlyJCIY25ApgTF47oMxlDJK
NcqkLHSYCW6Nja45o6TU2neuczA1x33d1bZxg16fatZMkoTIhRE3BdeUVAPkrwKLSCd9I26X/Z4v
Rn+NgMaVQB6S3+j2fpxMsBNwP7C+mOqIpYnR5is9L8t4LAM9nUYZVKxE+/lvAwp7QE4xXPLxCjxN
UOECT/MdDyKYVdiK0+uIh8nWjAmE5S59ctucEjur36nZDbO8ju9v4HjMn/ZklemO9R0+cmWdIKBq
p8q/AyIK6qWAwvKZ6vjjUfO1dXgrC9UQUUQJBnEb47/9rb/H7rQNZ2wITf6U6FosHSipoIBnoloM
VnqgBFG63+yccRiAFoGeaL0yNikMoqU/oBtTmZ0R3zMqBdwe+UjUoKqoKwncIQJaFG2aov4zLfrV
U1d5pe3Vtm1E11zUds0WfDrFVdQDH9YrsnrEvoY/EpugTgPpAZl8JEnILiXzylIGEdHAKRAoWSUp
LCDBHd1PvpKLkUDbx5G8HJeSPCRew2woW86a10NuXKKjjIqw7u48H0mV83Q2kr8ABU0X2/W5pWyR
WA6nDi1h/KannCR5Cry3bNgsHrT/UbVzUqcqtryaEQy2Ql9rVQR5RuBnXnoOmAeheYkqmdK+71zo
Ynj7ho4SgS/p4apPpXikkkWycUuz8PqksrCb7VgbB5XhMM91+604ETuQ9q0YGCe4ENz4IEbBs761
wWwBTYttgRGGwA5lWS8k3pHV6dHyMAimawg4w7l3bNiDKSCsuS5kqmiu/4V3SG4X/Q7BU+cxBeag
hXah2qw0EsAkbMPjZ/P3dz4XrL6TA6sNfPS3NYU6GnbyVGbNQBDoWRQPBjndqsIJoEEL4z1ffyca
tx8ozKFVAuoCQU7JHOOCrgpL+EydDqk3VV5B37rlIXUh1OMen+ZX+gJTA8WQi7YXAGrBPjlYCqZx
m4qveJh7wzEpFvqLfhm62vRZHS+CtoYwe4+2BcV3mpkzjGlhaxvDOTiyR+4PFFeq5UweK2Ha6XVI
v3Bp1yHj60d/yrsxwV3uSp5H3yvpUQUZJ2oiM3NPbumJJy4cqDRobzCViien1gO/PIQsh9AJobfW
d54KM2BsSCEJZ9OSFU4uTzozXcZ/BS5eFjsRwnRB76zJDCgEEbH1KDJlDm0sTy+fkOBXJCBJw4lF
i8/F0dhxS6hA6sLmwYH3EMij+qC76Bnfkap68iwndC4ZYX//PZspWmJ+nBA280h9JeMSA+yDVR/T
K5g3qFzjziDmi9ROoI8U/PITOUgCLVJrGJXEvaj6TW8PokUSt5xP3gxCx8EDYtmYo7r2oiJZ9Iic
MEQlsqz4TR8OxV/H1luYoylHrHKpi5MUNJ5ZGsTWp1owtQ2f+pvJ3iI41K/fft57hoK9nkiejZ73
Jjt+tgVzKi8BrKq/5XNvmnNuXXrL3EChmTjVPxghD9xfWZX3hR/6LEdJaGjjO92ruqwdMlzsaoBm
TSM6/Enm/eKvOCg2uHd5SsNgwHZJFwYJHkS4vsJ6dbqWQqw8qZvZAiryA0L/cgK/+Xuliw9WlpRM
hK4kVg+udMRuNLavOVf2MYbouLAi4RtaHF1Qdm9wE0EsBFBQMOhMugcmRLXu/Jgpg44qul63rOnv
YZURrrGFgJ4uxmzuqgd/C+PuQdm0W+aT7OoRm9zYeL6lyjNoUOo4bpjPTVX+oYcJOldq9cRoussk
SfTNAiWVAgGr3x+V9gZJNPcMCRM3OKkLpriG07ZUHpnliUQyggN2nCOq9AuACa+Jwjzz0rljcr02
K00aVsRit5h32Fb8Jz4U2HCh+4Sobxo4NLK7gCXxa75JmqC8fctjJk94iBpYBcQKdL2cJ2+TmWdg
wbzKksINBqw6OvGvEIhjndHwsyknjsWe473e8RezBLVm3OiJN5CbBcVpG9ir0sX3gLH6jKt6R+GX
JwwoNbz0pLsZVSXP6+8vKPxXrT1USsmx+0zkcEEV381yn3sRJtAU2qOYWJ0pCto5+9QmzqZKECSd
Gv15JRIWJ4WId2Sn4b8knE27zYrvcmf4fliBdKoTIiQoJ4VtZjaPV1g4wLpQLd3hvsa8eWdq6tNt
OJY0+flnMexaMikkWW402WuWcTwk5nSJn5Y9WkjsQiZpKx5Kq99Go7MSR1C9fBl5GtItvZRcxp2o
QvmNXKcFH5oKFWXVBzTIgU2g7Gk/WIO7v3jVAS+40JT7N0xKAfPz0YBoksSPxYtYjv+pvChhqF6a
PjpktqVJpCHoQoUEQBZ73yfvFo7129QwS1p9b6+wK5brhqyfgLo5jAoDm4bKkF+aJBmxdILJynkU
Zdaj0/M0KM0vR+NJFozP8iqiRnHVXvyrS33j1svWragO/rwNtXlv121u8uimpUnc4goc3sEPbkjr
ZXM21NEBSmznmbd4S7vbvb+HNy65eAlEnAuXb+l8VL+/c5G6leCTuYUGdswBlCo3ku792lPZL7BQ
nsj+EO7ddpo/CuLgYRUkWVYYKkVW1Ypdqb+2KZnlbvFbD0O6mGNz95Kp7vGqWbo3JSsaUrZbW/W0
v7posvD+1yCq/hXpiMJJ8DVIpkmZlDgKz4qx3ozS6VmYZe3f69GHUX2gOVklMjLnZmFefnxWYkLl
4cMiWI7eBf8HNpaOh2VuZHN0cmVhbQplbmRvYmoKNTkgMCBvYmoKMzgwMgplbmRvYmoKNjAgMCBv
YmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAzIDAgUgovTWVkaWFCb3ggWzAgMCA1OTUgODQyXQov
UmVzb3VyY2VzCjw8Ci9Qcm9jU2V0IFsvUERGL1RleHQvSW1hZ2VDL0ltYWdlSV0KL0ZvbnQKPDwK
L0YxIDcgMCBSCi9GMiA4IDAgUgovRjMgOSAwIFIKPj4KL1hPYmplY3QKPDwKL2ltMSA2MSAwIFIK
Pj4KPj4KL0NvbnRlbnRzIDU4IDAgUgovQW5ub3RzIDY1IDAgUgo+PgplbmRvYmoKNjEgMCBvYmoK
PDwKL1R5cGUgL1hPYmplY3QKL1N1YnR5cGUgL0ltYWdlCi9OYW1lIC9pbTEKL1dpZHRoIDcyMAov
SGVpZ2h0IDE2NwovQml0c1BlckNvbXBvbmVudCAxCi9Db2xvclNwYWNlIFsvSW5kZXhlZCAvRGV2
aWNlUkdCIDEgNjMgMCBSXQovRmlsdGVyIC9GbGF0ZURlY29kZQovTGVuZ3RoIDYyIDAgUgo+Pgpz
dHJlYW0NCkiJ7dWxDcIwFEXRjygoGYFRGA02g03CBtAFKZjHs0lQUCJEgUVzT4EdYt/qS5EAAAAA
AAAAAAAAAACAL+xjc4z1JZbSNRa3CEVs5Wc/3SN2463f5tVXlFcf9FXJP6dY+dBbQgc1jc6turmy
VMqd0qvsv3xFeR3Kvu+yD8mVlPyOMmXKlClT/mm53ncQ+KCMzlMemV6Zosm2TF9vNFueuplEnvRh
m8e8VyZ/sqVMmTJlypT/U673HQQAADU9AA9DAmplbmRzdHJlYW0KZW5kb2JqCjYyIDAgb2JqCjE5
MwplbmRvYmoKNjMgMCBvYmoKPDwKL0ZpbHRlciAvQTg1Ci9MZW5ndGggNjQgMCBSCj4+CnN0cmVh
bQ0KISEhJCFzOE5+Pg0KZW5kc3RyZWFtCmVuZG9iago2NCAwIG9iagoxMAplbmRvYmoKNjUgMCBv
YmoKWzY2IDAgUiA2OCAwIFJdCmVuZG9iago2NiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5
cGUgL0xpbmsKL1JlY3QgWzI2Mi4wOCAyMi44NiAzNjcuNDQgOS4wNl0KL0EgNjcgMCBSCi9Cb3Jk
ZXIgWzAgMCAwXQovSCAvSQo+PgplbmRvYmoKNjcgMCBvYmoKPDwKL1MgL1VSSQovVVJJIChodHRw
Oi8vd3d3LnBkZmZhY3RvcnkuY29tKQo+PgplbmRvYmoKNjggMCBvYmoKPDwKL1R5cGUgL0Fubm90
Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsyNjIuMDggMjAuNjQgMzY5LjM2IDkuMzZdCi9BIDY5IDAg
UgovQm9yZGVyIFswIDAgMF0KL0ggL0kKPj4KZW5kb2JqCjY5IDAgb2JqCjw8Ci9TIC9VUkkKL1VS
SSAoaHR0cDovL3d3dy5wZGZmYWN0b3J5LmNvbSkKPj4KZW5kb2JqCjcwIDAgb2JqCjw8Ci9GaWx0
ZXIgL0ZsYXRlRGVjb2RlCi9MZW5ndGggNzEgMCBSCj4+CnN0cmVhbQ0KSInNV8l200gU3fsrtISF
FakkyzLdGwKE7mbKId70OWwgjh03ThyCnQBf35pqfEOVHCfhZKO4ql69esO99x1OBwdHaZQmcVJG
0/lgLKJxkcZJHk1fRk+ip9H0v0ESDUUWi9L46eBI6DPt+kg066JZHyZxWv1/Gj2JOxP192H7jS3l
0q7hi8hjkUdJbba2NyrLstk77cxUi/W/5+rG0WjUWj6zL4rkjkyk3U/fjbsRA5+9V3wOM2B5UD8s
z0tjQ32mEN0tK8PkQi53a2vlUJYVzS/X0MByA5yqrhyPx+2JCyc1EdixlDuS0gmUc6b5nlGBRw0g
t3RuL+xgX5L5NG5FcptK+7f0jTpWWKhck750Nt8j5zWpsSYIw93WLz0c5ROgSwCroZ75QW8Epdh8
b6nDzfeVc5LazZXkiu5ut16scuqX7Hbp0xMqPGhGkF7MJqyTbl5wBz89RaOC5Rn2DBXHC9JGa2Dm
WIjpML0gscn2BQsi2tLftoHxQ9OA1EqHsT+9ILxadbFtuWaYVjxX840NNW5/3k97sTW3BL7/6nU9
rKRR99OfDLSlTqb749mmh0vqHacmuV6G3Oln/1Cqd9EE1gCNSDQ/JbavXH2isXJ1CALF1wy4oo4i
LUWhikPUJBXto1X85LcTFW0p4x7Is5TFBxTU+yIQmZEfWLahaDTfi4laMwSu1roJbJdA+Ia+8ax4
StSzX3l52tOLDkiNM0p6Q/jpggKU8yz1tKXIpvWaXZ05jpgN8ENNa6mIJ4Uam2Ak4cO9xWCAs+PC
FnE+5AqigzZhJN58f+VrYw0b+JY4QSsEDRJQeCDDnBMm00+OBOP25oMjEaX1tmg6rxMpKjlSaj0i
cMBqvg8dgyaNS+OpNt7qnUQVSVm2L5kShY8Js75lhA46EL16sIuXPlBCcziJHE4YHwF+9aPQB6o4
2MbdaVSxcwzw7vlrHmhvjMuTe0P1HR3K6MriRz5dz1RBq0OvDKPGgCR75KO6RpXXv8fAyJR4Eyqb
ZCmccPTF9ahMgjskIjHNiqK1PF8Tppm+tW/lahmOO1BZAQxt8/gUx0blFVpDkCB6VFXq3BipyBjY
gL7TwBMwfuZ5h8n66bc0vuIqgeJFXn1z+LulXQBq2QuWAIQChBicX51SIeTEkjZpbEIqcNWPcgCy
MRp8jXjshcp2t24oMh6UdH00BjeLlOxiEJ29vJBU32SEkWVTr6JYZ+3+JERmHPibwFj93is6GzIi
9NDGsiWQBlXngTtslW15ZJRwOINznYBLe1QXB7Qdml6l+Q3K6iEmdKlWeczJgzb1mpm27R6ffHhP
TGVScL8FN5+56ccijWMc5Ae16Q8KrhX1/QXkyCv1JGXmvXbOljZdEF7AI29Owg1zdPIOwgknlZ2X
A55uswzGgLWJzgu6hH1IaZQelkpWPCG9S5aDAiykkTtRZEyZqhiryTKRSkN7cxhSSaulW6H7wqfm
ewtjpMAKIDzREZRq4IdFqr5Mv/x8t5NcDpxtIKIjKAB4xcOSrFcQRo3wXMAgMsLdLtAAYcGxwrP2
3MHRKErrndF0PkjLqBPSVV1XAF6Muz2Z3pPHoyJKmg3SQmpYaPR3IhX4btNmcocHEua/+DWC4cBX
vh0pyencRRPST5yRjF7HhiK/1rTxzBASS8KIAWywGoZ1OVQJnYjHLYeU3xog/7DouGJZ6QlkJAnC
YtDBtLA77ZFTMKH65qczvIBaXyQ30Gr6C/98Eua6cKJaMTQ5WyxyTlv4hqVOldDw63UFCw5yh1OW
sWNs5AOxDXE7clUOX+MqE0TufbejeR4QeJd0mJLn2sk3kGxcqqX1T38eDGgqnJZZiQrlAiqR+icY
segmzKOUcUAIqGltVo9YWSwkWqsTt+HgZPKn3000WgZtwU0k83tGGGTCO6W92i/TwKhhJdrP+TOv
8zSj59Vlj8vogupcmzC5vqmRLr1zgdIUjQWYI9uAIgIzTRjnQUsW/nlAcxNaFVlclI9bFRlNMzPw
rkAgQLVYa3MBSU8ZBSTqALJX63X/L4jXsxjHQAKUgkBUsgBs7DbbIWigCSKineSrlYLQaRft6xvH
c8h+S1BV/ZR+YkfkzlKE8u0SVsESHNggzAALasWYUlH8tbfaDmJmPjKfL6jycp2jy7ddKpVXKhxv
AvLIypJQzOdTG3QJpzVuYCeoTJNDksJ/YeB/dcFQZHGS1/htMrQefGLD/0PHpLFUINwg8jq6khs0
aT+ns/bNeSqC1EzIGOJlkumqiUDEmfmzQmkNL7wnRp/tqjruF/EtmCEpOazUCaJ/higWMYmrs0OR
702wyMCfwEq7MNy7gslb0SoCcDNawBJ6KGVW9c/+Hqruf228ao2zpo8Er9BjmGRGo2OVmi0BJPPo
ngTRot2a468BSOofKPrrBlq7khV/Ba5aYakhCeqC4w4v31DNvKFyi49s59AJE22uZ0yIEaD0qibX
EVQBEbqFmqoQ3SIfP6frUYcMGUJ7vChA6zDTKsSXlfOGLVqR+9N6/xDpdJkRjU+vRtzYrp67yTIe
ukW4VrbmMBXxpGgUDxO2NQZqFDigU2YAfmaTENWnVQyNaCwskEJElxHeXf20j/9Ojx7wiR+aKPcu
B445cH3MFOkMdU0zFo2GFyVg+pc0BSM1vddEP4LKvSOJIIOqh+D8tGqxDiaEdNmQA0ogh/ij74Pa
AN3Ui0WtF//aPckOoCNkzQ8UvkGH1ZVmzZrqbBEYMptqN4aFcwYV7qPGSYZfA0eoinFVB2cDn524
FvKPBysy4dLVmA5hWbZpnGI5gNLF0z8+HU6BYiZ8gAZ3hCntoGVMdPefhbDwtJdoidXQaktIxGRA
8yTMhn/205OsxlR6txgVIegQ9vQ9I2sQ7XX2rgh7uCieaVWMCL8gGKbILDEijiThwXjN15fIY3kB
dEd1grcJ36qXhLH9I0OAxvFyUZvAB+zdsnfnPnyfxoZX0sIh2zqLPoUW0Adst6LF9PsNAExvY+/Q
5CPiSSHJZw+6PoQjXaukMPKLGJjBUPjBRozciDGPLwQaaRfuMDKdEXFBOMDBi26ZlO8kZZxDP5dY
pfLTAuiTh0XcoN69B6nvF4Ge+kRLnh+1Oie3MC21Q5MA+cB1xMaNxZrOfqygRGRx0ujYzsuDoyJK
0+a3ebM+iceFsd7+VHv6e/10cJRF9ePmg+Eoj4bjcSzKDiErUG4efayi2EXopQxK0qbtSMa0Wzdx
6lQjvEmXVaDas2ogSlxKkBtmqPU6X50kUEibWmVIWjzH3VXrV+6Nc+q9CGedei5f4/Gwyh+81M4E
Hcy1a2BDHAChckY/ub5iMnvjJop52XfPvetLaTmJ0uh6EYk8rwxV/7WlqFKt9NiktJMvPYzxZA71
3XMiu/vLZu1egWY0xmxLW+1Y8mraReHj6yhp/qpwJPEouo1EIeqgpEk8rpr0YpAV4zjP5f+rwcmg
PdCdbAKZ6HOTuKw3Nx3eeHh9Fs3/B8umgsVlbmRzdHJlYW0KZW5kb2JqCjcxIDAgb2JqCjI2MDYK
ZW5kb2JqCjcyIDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9QYXJlbnQgMyAwIFIKL01lZGlhQm94IFsw
IDAgNTk1IDg0Ml0KL1Jlc291cmNlcwo8PAovUHJvY1NldCBbL1BERi9UZXh0XQovRm9udAo8PAov
RjEgNyAwIFIKL0YyIDggMCBSCi9GMyA5IDAgUgovRjUgMjcgMCBSCi9GNiA3MyAwIFIKPj4KPj4K
L0NvbnRlbnRzIDcwIDAgUgovQW5ub3RzIDc0IDAgUgo+PgplbmRvYmoKNzQgMCBvYmoKWzc1IDAg
UiA3NyAwIFJdCmVuZG9iago3NSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsK
L1JlY3QgWzI2Mi4wOCAyMi44NiAzNjcuNDQgOS4wNl0KL0EgNzYgMCBSCi9Cb3JkZXIgWzAgMCAw
XQovSCAvSQo+PgplbmRvYmoKNzYgMCBvYmoKPDwKL1MgL1VSSQovVVJJIChodHRwOi8vd3d3LnBk
ZmZhY3RvcnkuY29tKQo+PgplbmRvYmoKNzcgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBl
IC9MaW5rCi9SZWN0IFsyNjIuMDggMjAuNjQgMzY5LjM2IDkuMzZdCi9BIDc4IDAgUgovQm9yZGVy
IFswIDAgMF0KL0ggL0kKPj4KZW5kb2JqCjc4IDAgb2JqCjw8Ci9TIC9VUkkKL1VSSSAoaHR0cDov
L3d3dy5wZGZmYWN0b3J5LmNvbSkKPj4KZW5kb2JqCjc5IDAgb2JqCjw8Ci9GaWx0ZXIgL0ZsYXRl
RGVjb2RlCi9MZW5ndGggODAgMCBSCj4+CnN0cmVhbQ0KSInVV21v4kYQ/p5fMVK/cHfY2ItZG3GN
lFySJlJUVQf3qZxOLhjw1THUmKRRdP+9s/au8cusTa+pqhIJYe/MM888Mzu7uZydDW5csC3T8mC2
OnMZuNw2RwxmV2DgWwdfL6A3GOw3vvgzN29g9hWdONg2LgsnzsES9j2QayVACyxzhMvJGgy0M5hr
2hl474cwXkSHZQDv9+kyjFNzc577W2AgNPMqkF4FMgfMDQUHNEyfd8EyWDUZOKzGrgSliB/ifbiO
gyXh7XV7LzZ+0vRkjvK8DNNp8MchiBfBhIAxbMbLKf+HmUTbeN2Wyfd7Xvmpfx/E63QzAQUzLtXU
5GPkZ7oWF9/OWNTXU96DAfiAsoQLPwLuGL+FKTz60SGAtvYwmGO9mq5BfHhoy+8Fpp8+fLieTuFH
2cVZ24tvpOIq7S3Z4ZKiQu/DzcXdPek6UiFsnevlxdWX24vp7eXd7P76ZxLEthUKo1HgG9z6+83H
ID0ksaqQMRzmjely/V58rS24T5PDIm36DguKkhR2hYiZj6jeCwA1NQAOOFJs/iWFDeaFDRMF8URv
6aFhsj3Ey33FSAYpGT2EfwZJB9DCT5LnDhtktIr8dYfVPvXT4FeinpZSdOTyakVt1WqfJTaOF602
uy3mW1VQpvyNICaUnApGE1Lz0ivZEMeWgrs4TOdHBHibpdYnGoJZqleRZbMfivxKhZ2/KVqWMVap
XJNnidSn3RJJnEjLLsb9Nt5TjWoR8x7eYgS/X7BzeK2v8HMcjSCM6ynViwdkx5eyugljP6KSqvAS
yzhDdXFaI4if815TozH/u5WjlC6G5T8RutYGOpn1omi0b9UleNxGj0Q/fS/ev7xpaK1eiI1cMK0G
PTFmqCaR0yiKRpYsT+P8SBZPNc0cL4FJr3yO0+cgU73j0OfgcWZyDafsAOg4ZL1RbSazKnz31afw
GAwsO/+jL9fyqmMPPQ3f7DDq4Ku5legPEAWO5wcNXZxP3GmXwhAsaHB5RGoKyU/kPmz2XHOIntbm
qy1xzS/afN4LSarFuNIyDeE95acM9Ec8ur57V+xjTapSzfwqEX6m5RydKidnbSPsNB2TbLq1XfXk
XXpSrZXBrfJ1lLqiUGz+Lwc+kc6LZtKJCxx38AIX9uFrH5JgF/hpP0d7ToP6jHyVKf57H3YJKoV7
XoQKV6vTxvqJwYl/G4pZMe9lVQLjHLKJ0z5y9PvluFVGjbLopBYfda53HeZqtxVEKZ5DxaZ7NI4a
IeieP0o7FCgonYH/Nhp8JBMxhKJYhgX0fsmh8QXLX1xJirbQHJ9v5LNaVwHF74Vak2CJenZy38Cv
Oad1gyWJjnQYz188SQOx+8Rz2IG4oekW67t6xJUuX+ngU/lqgm9pPbLfz7pMq5XQi7mtA6Qah4ZU
1UyK9ailso/1QrVktu+Iu40VsgW2aGzmOGJHW7IVi1I/KUnGXrX4iqFJF9M4xl5pqvt61RT0OFlR
k8JWWA/Zi+uZVOHjT1DsczEInoBxJkTBYefiPn7Aw881HUc9R2dTORikZyakdfQbm54wdsUQyBgm
Aaz+Aho7Bk5lbmRzdHJlYW0KZW5kb2JqCjgwIDAgb2JqCjExNzIKZW5kb2JqCjgxIDAgb2JqCjw8
Ci9UeXBlIC9QYWdlCi9QYXJlbnQgMyAwIFIKL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1Jlc291
cmNlcwo8PAovUHJvY1NldCBbL1BERi9UZXh0XQovRm9udAo8PAovRjMgOSAwIFIKL0Y2IDczIDAg
UgovRjcgODIgMCBSCi9GOCA4MyAwIFIKL0Y5IDg0IDAgUgo+Pgo+PgovQ29udGVudHMgNzkgMCBS
Ci9Bbm5vdHMgODUgMCBSCj4+CmVuZG9iago4NSAwIG9iagpbODYgMCBSIDg4IDAgUl0KZW5kb2Jq
Cjg2IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMjYyLjA4IDIy
Ljg2IDM2Ny40NCA5LjA2XQovQSA4NyAwIFIKL0JvcmRlciBbMCAwIDBdCi9IIC9JCj4+CmVuZG9i
ago4NyAwIG9iago8PAovUyAvVVJJCi9VUkkgKGh0dHA6Ly93d3cucGRmZmFjdG9yeS5jb20pCj4+
CmVuZG9iago4OCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzI2
Mi4wOCAyMC42NCAzNjkuMzYgOS4zNl0KL0EgODkgMCBSCi9Cb3JkZXIgWzAgMCAwXQovSCAvSQo+
PgplbmRvYmoKODkgMCBvYmoKPDwKL1MgL1VSSQovVVJJIChodHRwOi8vd3d3LnBkZmZhY3Rvcnku
Y29tKQo+PgplbmRvYmoKOTAgMCBvYmoKPDwKL0ZpbHRlciAvRmxhdGVEZWNvZGUKL0xlbmd0aCA5
MSAwIFIKPj4Kc3RyZWFtDQpIic1XS3PaMBC+8yu2h85AiYkt/GIScsirPXYCPYV0xiV24oQANQ6Z
TCf/vZIsGT/WQoFMpz4wlmTtfvt9uytxOm4dXnpgmT3Th3HU8gh4rtVzCIzPwaCzNp2eQhvocxuk
wa/XNJyFcxhmozhlg0PowPihZfYcMIH9Jndg+S4dUCNtP1tkS2xBTh9lmwxrQMCwLOqJTzNHfOHw
0t/AIrbYFUdisYDZImJx0i6A+oyA8m01Jvg0xCIRqya+adKRkTgmjyQjj0fyR4CozrNnlQZpaJxQ
uNEsuCszioEnxNdjlPRt7o9+X/RXkK/bPSoCK3z41jAPuS61pds4iij6OmBXAnM8t4w4pxQMScNy
sZL4fbtGV8Hzx+WJSOXjIQ8hl7HvKlWskLJMQildZq+JWf7xYpWiVA1MdY5JagY1bOxJwmUY4IYt
k+hZtihHqlzQoz2crUKoM2+QmqQanFJRjhT1I8gsi2mwzVRKvIAkF45FGhIyryEbRZYzjXvFGiGr
Rm2vDtm1IPX0iRYJUhd+XhcxmkT9rdkZwzGjgL50uweFku5287LysvzyXK0U4CbAOMlervMhtXkj
6u06vnl3F/voPiLy4QTrfltI2xwbJlEyUwCKg7V9TXUfdlT3gaqbRUrfC5JK5JXCVOnKnnC9mK3D
SZuLOumoGmYpFaj2eI9zpSCuXSkwUikwy0OPRpxXj2jy+rgjr4+UV2Rffmwq+sUjq7NKsUFRGh/t
mTry7F9+8lH1rreGzv7PSpcfH1jh2rr3vYH6ulcJWJX12M1QmfF9Xzvjnf+pizDSeQ+pJe/+bWX/
nH13Tu6Ul0mYPifzOsV53cPox9nZxWgkJXRLgFAwddzfgtX9FfcEl/E8mE3a93RmxEn5wrk5gNM4
HYW/n8P5lM6x5TX9roPYbzqPVNU3TxVZBLEMzq5rjZMtUiUTd4eL7g38HFb+c1XvvgUQ2t6s7d5Y
FWM3Q+ZW7w8dqV0LtfERPXzYfXkffDI1+qwjsX8ADj143UHP58ljsISgb1Nof89M0AmSTZwLIMw7
G1+KsVyX6cHep3JNGEvk2M72hkFlc1r94Ba1TuEQN5t4ER8Qy+XjeIvFexxuvr6seoya4hUbAize
BucLnA/+/toUaVmJZjIXVQNpw4YaVeVI8vWZQtl1VShFZKstfhdzadkEi/8ls+2ezO2i1C+SkoFf
Fl8i7OFiGhvfUYO6H6cmg+eiivYw29LWE5+4GAsWrr5CXs6s3F+AuISRQnu1R+v4iR5HXs+25XjW
Gon6Fzs5keZmHy9ty/RYE+AIkxCiv7S9cmdlbmRzdHJlYW0KZW5kb2JqCjkxIDAgb2JqCjk3OApl
bmRvYmoKOTIgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAzIDAgUgovTWVkaWFCb3ggWzAg
MCA1OTUgODQyXQovUmVzb3VyY2VzCjw8Ci9Qcm9jU2V0IFsvUERGL1RleHRdCi9Gb250Cjw8Ci9G
MyA5IDAgUgovRjcgODIgMCBSCi9GOCA4MyAwIFIKPj4KPj4KL0NvbnRlbnRzIDkwIDAgUgovQW5u
b3RzIDkzIDAgUgo+PgplbmRvYmoKOTMgMCBvYmoKWzk0IDAgUiA5NiAwIFJdCmVuZG9iago5NCAw
IG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzI2Mi4wOCAyMi44NiAz
NjcuNDQgOS4wNl0KL0EgOTUgMCBSCi9Cb3JkZXIgWzAgMCAwXQovSCAvSQo+PgplbmRvYmoKOTUg
MCBvYmoKPDwKL1MgL1VSSQovVVJJIChodHRwOi8vd3d3LnBkZmZhY3RvcnkuY29tKQo+PgplbmRv
YmoKOTYgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsyNjIuMDgg
MjAuNjQgMzY5LjM2IDkuMzZdCi9BIDk3IDAgUgovQm9yZGVyIFswIDAgMF0KL0ggL0kKPj4KZW5k
b2JqCjk3IDAgb2JqCjw8Ci9TIC9VUkkKL1VSSSAoaHR0cDovL3d3dy5wZGZmYWN0b3J5LmNvbSkK
Pj4KZW5kb2JqCjk4IDAgb2JqCjw8Ci9GaWx0ZXIgL0ZsYXRlRGVjb2RlCi9MZW5ndGggOTkgMCBS
Cj4+CnN0cmVhbQ0KSInNVt1zmkAQf/ev2Jd2SBQCJwKOTR7yYdqZPnSieapNhyhGHAMpomkmk/7t
vYO7U+AOxSHTkpkIe7e3v/3tx+35sHHSt8HQNd2B4bRhI7AtQ+sgGF6CiqUmFo9BAfx463Cx9kbK
MnZjb3TUgyMYzhs6qIahIYcoJNu2xbrJxYn0pO9sbCET9GR5GkZ0dQuJ4dDVkeLDKT1U62Ah+R89
QFunG3RqkPxhuUXFPfDhE1C46tnMXc7u/XjhBXAiOM2wENVzxMcRh/1mc3SUKqvItBIXbYu7+Cpj
BD8rP4idnzGEqxh7QzElP9/9Hz0JZ2LeTMbMOAyWcZE5Tgw36gd5m4TUpoiGLqPBkNHA0KrItkSe
1gHYheqA0b8EfH8A4PbegLdyDDKoq2aMPxUUGsODa8WFM7jnKW6lx6fNQEmFbQaTWaNOj90oeoG7
U5xrDH3bqojOWyw9KAJU8YbqOP4UgDD93COv2VyV4giPFFK/d6cZayWtMI+ryTUf/d9eVKZXskRa
2dpdpJAKrSSnu+X1W20dO/LiVRQICoNHZXB7cXE1GPRAmEtCJEXRZ+zoTWIKyOtIKULqMou4EEsu
Edi0/5bAMXvvgj/344H3a+UFYw+OJ27stlitIpTn+xIvf/WCh3gGZCcznzmCxpLVXMZ92X1CdAYk
3mnwS7JInAdfAj8eKR8T5dYWM+WJLFm6fZqQcYAfl3Ky8Xe/QWFL3PcDzEcGXkJQT+BN9TxiQ8yG
w2M6z+wKwH6VsSMN/RbMWVsyUaG51z46zQ8cneZ4dKKdJQpXwWSJRVvDj+3kc0pG1Y6W/56jn0CP
bejYVlaTm8wOeUZHeHW8SgqLPgfPemKybLRvc3qXeQ8+CPR4AsqZ5FNMmyZ6vp/U5Gyts+L/7myt
c2Ztzoomq5KLpJyLajOqY+4xG0L1MXUHSNmoaqPD4BSnVQFpOVoFrNcysRbwVZhaZSOmSP5G+bOA
0j9tcKboUhtw5Amvyfiot7Vu4rNK+MYKY1C+paRhAUoFlzSlDRIR/N2n32ydASHvY7ZGD4vYt5nq
em5OOc5vmAhPx3CQlQqe6QZkWMm3v+PEmRguX3/KW5zK/KUKrshfifFQzEfy/iLzNBsJOZlh/oBY
olCgKusJX1+URHadD1SJZ8sddsOAnayDkbZIk9S7TlORh/qZUdJ1ssFnCDVxMNWN7akkuvVFk8Cz
hBHVRGezsx4TwdWQsnBzDfxeIBfHMyALEVJwK7RxfT/irmdrpsm+F40BvUioZkKkvtHrag7ZbJPm
kCCMPJj+BW+lnY1lbmRzdHJlYW0KZW5kb2JqCjk5IDAgb2JqCjk2OAplbmRvYmoKMTAwIDAgb2Jq
Cjw8Ci9UeXBlIC9QYWdlCi9QYXJlbnQgMyAwIFIKL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1Jl
c291cmNlcwo8PAovUHJvY1NldCBbL1BERi9UZXh0XQovRm9udAo8PAovRjMgOSAwIFIKL0Y2IDcz
IDAgUgovRjcgODIgMCBSCi9GOCA4MyAwIFIKPj4KPj4KL0NvbnRlbnRzIDk4IDAgUgovQW5ub3Rz
IDEwMSAwIFIKPj4KZW5kb2JqCjEwMSAwIG9iagpbMTAyIDAgUiAxMDQgMCBSXQplbmRvYmoKMTAy
IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMjYyLjA4IDIyLjg2
IDM2Ny40NCA5LjA2XQovQSAxMDMgMCBSCi9Cb3JkZXIgWzAgMCAwXQovSCAvSQo+PgplbmRvYmoK
MTAzIDAgb2JqCjw8Ci9TIC9VUkkKL1VSSSAoaHR0cDovL3d3dy5wZGZmYWN0b3J5LmNvbSkKPj4K
ZW5kb2JqCjEwNCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzI2
Mi4wOCAyMC42NCAzNjkuMzYgOS4zNl0KL0EgMTA1IDAgUgovQm9yZGVyIFswIDAgMF0KL0ggL0kK
Pj4KZW5kb2JqCjEwNSAwIG9iago8PAovUyAvVVJJCi9VUkkgKGh0dHA6Ly93d3cucGRmZmFjdG9y
eS5jb20pCj4+CmVuZG9iago3IDAgb2JqCjw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UcnVlVHlw
ZQovTmFtZSAvRjEKL0Jhc2VGb250IC9UaW1lc05ld1JvbWFuCi9GaXJzdENoYXIgMzIKL0xhc3RD
aGFyIDI1NQovV2lkdGhzIFsyNTAgMzMzIDQwOCA1MDAgNTAwIDgzMyA3NzggMTgwIDMzMyAzMzMg
NTAwIDU2NCAyNTAgMzMzIDI1MCAyNzgKNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1
MDAgNTAwIDI3OCAyNzggNTY0IDU2NCA1NjQgNDQ0CjkyMSA3MjIgNjY3IDY2NyA3MjIgNjExIDU1
NiA3MjIgNzIyIDMzMyAzODkgNzIyIDYxMSA4ODkgNzIyIDcyMgo1NTYgNzIyIDY2NyA1NTYgNjEx
IDcyMiA3MjIgOTQ0IDcyMiA3MjIgNjExIDMzMyAyNzggMzMzIDQ2OSA1MDAKMzMzIDQ0NCA1MDAg
NDQ0IDUwMCA0NDQgMzMzIDUwMCA1MDAgMjc4IDI3OCA1MDAgMjc4IDc3OCA1MDAgNTAwCjUwMCA1
MDAgMzMzIDM4OSAyNzggNTAwIDUwMCA3MjIgNTAwIDUwMCA0NDQgNDgwIDIwMCA0ODAgNTQxIDc3
OAo1MDAgNzc4IDMzMyA1MDAgNDQ0IDEwMDAgNTAwIDUwMCAzMzMgMTAwMCA1NTYgMzMzIDg4OSA3
NzggNjExIDc3OAo3NzggMzMzIDMzMyA0NDQgNDQ0IDM1MCA1MDAgMTAwMCAzMzMgOTgwIDM4OSAz
MzMgNzIyIDc3OCA0NDQgNzIyCjI1MCAzMzMgNTAwIDUwMCA1MDAgNTAwIDIwMCA1MDAgMzMzIDc2
MCAyNzYgNTAwIDU2NCAzMzMgNzYwIDUwMAo0MDAgNTQ5IDMwMCAzMDAgMzMzIDU3NiA0NTMgMjUw
IDMzMyAzMDAgMzEwIDUwMCA3NTAgNzUwIDc1MCA0NDQKNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIg
ODg5IDY2NyA2MTEgNjExIDYxMSA2MTEgMzMzIDMzMyAzMzMgMzMzCjcyMiA3MjIgNzIyIDcyMiA3
MjIgNzIyIDcyMiA1NjQgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNTU2IDUwMAo0NDQgNDQ0IDQ0
NCA0NDQgNDQ0IDQ0NCA2NjcgNDQ0IDQ0NCA0NDQgNDQ0IDQ0NCAyNzggMjc4IDI3OCAyNzgKNTAw
IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDU0OSA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAg
NTAwXQovRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZwovRm9udERlc2NyaXB0b3IgMTA2IDAgUgo+
PgplbmRvYmoKMTA2IDAgb2JqCjw8Ci9UeXBlIC9Gb250RGVzY3JpcHRvcgovRm9udE5hbWUgL1Rp
bWVzTmV3Um9tYW4KL0ZsYWdzIDM0Ci9Gb250QkJveCBbLTU2OCAtMzA3IDIwMDAgMTAwN10KL1N0
ZW1WIDkwCi9JdGFsaWNBbmdsZSAwCi9DYXBIZWlnaHQgODkxCi9Bc2NlbnQgODkxCi9EZXNjZW50
IC0yMTYKPj4KZW5kb2JqCjUyIDAgb2JqCjw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UcnVlVHlw
ZQovTmFtZSAvRjErMQovQmFzZUZvbnQgL0FaRlJBSitUaW1lc05ld1JvbWFuCi9Ub1VuaWNvZGUg
MTA3IDAgUgovRmlyc3RDaGFyIDMyCi9MYXN0Q2hhciAzNQovV2lkdGhzIFs1MDAgNTAwIDMzMyA1
NDldCi9Gb250RGVzY3JpcHRvciAxMDggMCBSCj4+CmVuZG9iagoxMDggMCBvYmoKPDwKL1R5cGUg
L0ZvbnREZXNjcmlwdG9yCi9Gb250TmFtZSAvQVpGUkFKK1RpbWVzTmV3Um9tYW4KL0ZsYWdzIDYK
L0ZvbnRCQm94IFstNTY4IC0zMDcgMjAwMCAxMDA3XQovU3RlbVYgMTY2Ci9JdGFsaWNBbmdsZSAw
Ci9DYXBIZWlnaHQgODkxCi9Bc2NlbnQgODkxCi9EZXNjZW50IC0yMTYKL0ZvbnRGaWxlMiAxMDkg
MCBSCj4+CmVuZG9iagoxMDcgMCBvYmoKPDwKL0ZpbHRlciAvRmxhdGVEZWNvZGUKL0xlbmd0aCAx
MTAgMCBSCj4+CnN0cmVhbQ0KSIl1UMtqwzAQvOsr9tjQg2wlLT0YQagJuNC02Dn1pkhrVxA9kGWK
/76SY1IK7UHLLLszOxr63NSN1RHoe3Cywwi9tirg6KYgEc44aAslA6VlXLulSiM8oYnczWNE09je
kaoitE3DMYYZ7uj+49DuX+5P2uB4xK/WGWE3QN+CwqDt8P9GN3l/QYM2QkE4B4V9OvUq/FEYBPon
7WfpNHsEtvTl6tUpHL2QGIQdECpW8FS2HNCq3zOyuzLOvfwUgVw3i/Kh5AmXGRePh4xZxqyuM95m
NbZ74iTprcysnBKCm2s5hZA+tMS42MwGtcVb0t757Ce/b0Vegg5lbmRzdHJlYW0KZW5kb2JqCjEx
MCAwIG9iagoyNDgKZW5kb2JqCjEwOSAwIG9iago8PAovRmlsdGVyIC9GbGF0ZURlY29kZQovTGVu
Z3RoIDExMSAwIFIKL0xlbmd0aDEgMTEyIDAgUgo+PgpzdHJlYW0NCkiJ1Xd7eFTVufe71tpzyWUy
k5AbCcmeZGdCYBITwi2ElEwuEy7hEiDATCpmhhBuggkkQaFAsErFgMJRqtgqwVouR7TsTISGSw/R
VnvUWvC0WvWzgEestS2VKnLqETLnt3YGkD4+X7/veb5/vlnz3t+13net9e619yJGRLG0mQR5mlYF
WxWzSIbmV0QsoWltu/Pz/PfuBX+eyPLKktalq36+PwM9og4SmUctXbluySbr/c1E9veJlL5lzcHF
fzanjCdK3IUxxi2DIuHT2DWQMR7lLFvVfo89jq5AvgQ5dWVLU1AcYa8TJVkhx60K3tNq3uj4CeRU
yM67gquaE277z27IJchhY2tLW/svv/zLeqLkPthLWtc0t14o2fVjyBjPPgQ6RnI+ckbEzPRPf1wo
pn/u9f/zz/QwYDqpgGFiF6UThT8AXAD8cWBa+KrpTtIGVoTPC7l6z0eAyEWPUTfl0CU2il6ifppG
+6mC6mgXTabTdJjiaB32TSGNqukguZhKnGoohZnoCXqXbqc19BGdpzyqpbMsAeN4qZWSaUL4E+Ba
2ho+Bq9oqqKf0HG2ks2lQvBTeD5zI/KOcD+lUF74jfA7kJ6ij1hOuIemgPsDxdNw6qR/oQRaQa+F
ryLTHFpEB9gG9gllUYC2KWOUrvCdNJGO0FusFtwMWmd6J+oIrUSvZ1gK6w+fC39M/6YwasZI36Wt
yDhE/fw2UWXaS07KpW/RTArC+h16lw1ho4QnPDxcGX4C2gP0GXfzV4QFebhpKjXSQ/Q0VuNtukBf
sBg2lj3FDqG9yf5qege51VIHrcez9RRW7wA9R8fYKDaKp/AUrFYKjaB5sO2gfYjfS2dYLfOzfvai
2GcqGigPJ4aTwh+HwzSSfMiwm15EjMusCD6IILJFu5KptJuKr92LGS6mJ+kMvYk8zmLdv6C/s5Fo
H/BNvDO8IHww/BFysZJKJTSbGqiF1tLd9CPs6kv0C/ob+4pHwfO08rJpvelS+BGsbS5VIvdZ8J6L
sbdhl0LUh/Y2ZhnPnJhFCZvJ5rClbAd7jPWxd9m73Myz+Gr+J6GL18X7yjiTKVyKkZIpE3E1WkDL
sAObsNqPYL4H6WV6lSWxXFaAGb2N/lf4RF6N9gw/zc+KLWKHctX0vYHzA38e+CrcRRZU2WSsQwc9
i1X4lCUjhxFsBWtjHyLznfwFESccQhNjRYWoF36xVewS/y5+raxRDinvmaaagqZDluDAXQNvhmvD
95M8JczIazjl0xgaj/pZgmq6E/m1oq2hDXQvddHDqJdHaC8dwrxP0av0Fv2e/oIdIJaFnJcj+ipU
3Rb2MNoT7Dn2InuZvco+YFdk49loeXwcL+dVvIYv5VvQdvEz/G3+RzFMNIlOsRltjzgq3lVIUZSw
qRhtimmb6YD5dUueZYplkfVXVy9eG3nNf+3sAA2kDXx74LGBFwc+Ds8Pr0P+Liqg25DpA8jyCdTg
PrRnUYlH6RWc3b8zcv2McWZCxacyDdWQj10rZ5PZVLQZbDbaPLQFrAEtyBaxZWidbDP7LruP3c8e
Yt832m7MbR/7V3YU7afsONpb7Bz7A/sT+4yjiLlANbv4cF7IJ2CmVXwyn8XnoC3lLWitfA1fix06
wHv5Mf62GCJcokAExWrxhPiJeEn8VnypcCVfKVTKlPnKUuU+5bTypvKO8pVJNXlNy0x7TC+Z081j
zPPMK8y7zYfNfzRftZgtdZZFlg2W31rCVhdOq19i3kduOfIKzadZmylRuYefw3ORKlpND7B5WDEz
rxcrxcPiP0xL2CXhZO+xLrFc3Bl+RtTwv4sWNp+fYtlCNZWKJbSdwuwQ/4Bf5h8rSayef8LylH9h
P+Utooob7xXTb5Qk5T7TH/EO+R2V8o2sn78s7hP3hX9GpaY97JxpD3+TnMp5PoTO4al+gD+OTr/m
y/k28iljTF/Rcqz7v5ruwXpP4lvZSPFbZQ99JDT+ObvEHsOp8QabpuTwO/gEdggn7jWWSRfZampl
3ycPO8F+z/qIsYPiAJvOY7FbOrex8Xj1vSGy2G9FNPlljiyXJ7E6fonPEyfNZ8RYxnBK/AetZ4IV
oXau/wboLjwBu/hwnGlenCa/YcWUSo/jvL88cFKe2KZ3TNtQZ0+LfJpDRbSQv06leDY+QvPR96iY
jqMGt1IR300bwpvZYpz7M3B+cupjK6iQxeC0TEFunXhfJPNsnIWNiPp3nP+v4dSvZX+lu5kTT1Y/
5SnSsl3x4mQK4PzdhraYFkJ6kh4xHzH9hmaxFHxpOAf2oMrfpzvwzvkQ8dOoDPk10NNKPrJ24mRe
jR5PDkwhD9r36HXGaSNynoTnvE6ZgpP3sfAKzHA53lHT8U58lZaHH6cq7N2c8H3hbdQYfjp8Oy2l
ueGDOH/XhkM0jh4w+fl8k1sZgzP2VfYLvI/+F9uGc3sKvYfzyMVS6U9o+HahSaYT1KX8DmdneXh7
+C1KwnpkY4UW4S16gVbRX7FuU0Q/jR6YyXvCNaIVb6hzNDt8IKyyaFoWXomT9yTts5hw9mymTNM+
1C55KufVe8onfatsYumEkvHjxo4ZXTyqqPC2gnz3yBF5w3NdOVp2llPNzBiWnjY0NSU5cUhCvMMe
Z4uNiY6yWswmRXBG+V6tJuDUcwO6kqtNmVIgZS0IRfBrioDuhKrmVh/dGTDcnLd6euC55B88PYOe
nhuezOEso7KCfKdXc+pvVGvOPtYw2wf+oWrN79QvGvwMg99p8DbwWVno4PSmLqt26izg9Oo1a5d1
eQPVGK4nJrpKq2qOLsinnugYsDHg9BSttYelTGIGw1O8pT2crDYkpadp1V59qFYtM9CFyxtcrNfN
9nmr07Oy/AX5Oqtq0hbppFXqdrfhQlVGGN1cpVuMMM7lcja0zdmT39+1vc9BiwLu2MXa4uDtPl0E
/TJGvBtxq/WU9RdSb4oYPKHK98DXremiy5u63CnFrq4HnPre2b6vW7Mk9vsxhs5dNYGuGgTejiWs
netELL7F79PZFgR0ynnIOQ3OrlnzSk1ghVOP0iq1ZV0rAtiYtC6d5qzLCqWleY6Fz1Oa19lV79Oy
9PJ0zR+sHtaTSF1z1vUO9TiH3mopyO9xxA8ua0+cPcLE2r7ONN+wGZzhLrnaOTfWlcmMtKkoB93Z
5EQmPg1zKpGouYS6mkrghp+foZe+GPuxXI+qCnQ5SqF3yP66yeXQnF1fEPZfu/iXWzXBiMbscnxB
kpVVcqPQYL/O6263PnKkLBBLFXYUOU4y5LEF+Wv7uK61OpwgWD6qw9oG/aWFWPysLLm92/o8tAiC
vnm2b1B20qL0EHkK3X6dB6Sl/7olaZ60bL5uudE9oKGOXzDuJEm6NffG3+5IHuJdVqqz5P+NuXnQ
XjtXq53d4HN6uwKRta2tv0UatJfcsEU4NmjAguuKCys1VUPpzWnwSQX+JleN5l0emIJHDTnqQ6p8
Ip37BzmeLoyhUL+33xhZCr5YOZbiMhv1v7jPYkUBGxrmrNEdgSmD2B+dlfV/2KkvfEn2MsjNbpE5
6aXuW+WJt8i3pBfbJZCwkstr6xu6uqJvsdXgsOrqqtGcNV2BrmBfePMizenQuo4Jn/B1tXoD17e/
L3x8W7pes92PSSxjpShtTpU9Gts6u8fDts5t8B1z4Fq6td4X4oxXBSr9PTmw+Y45cT4bWi61UikF
pxTwfsNTEeJWwz/9mIdos2FVDIUhN/UxMnTW6zpGTX18UOe4ruPQKYM6j6GTP3lSVNX7vl4DxoPl
L0BN4fbgDV8Qx0x38VwS+B6w4A38axjyPcMEt6uqCsQ61cPqKfVTVVGJprjxRec8xp/HK9LN3AtX
rxk7FoGNUcRhslMGj+3hMqJnWGKs2eHg82Jj7XaJbTZgR0wMcJrSF778gjRKxjNEKhXDTUlxWWMc
LnzQl18sv8gK3W73GxK53xhVlN5jNgaOknbplyY7p9ts5nlpSmKspImxDrvdjDBSiMXglzwxklWU
zNhYNTM+YUJh/IRCtwPjuR1vuI0gGNjjTdicxA4kH03GJ3rULzLejTInfBzNpkR5kxckbWHbox60
v5tuUT3FYxW1yrZwXLfKXkl6NY17VDbVej2bBITr97gTYspnKcyjsDMS1ykBpVXZqeiKWflLrAdG
T2x3LI+tyqyqTXXPdFxe455xcSGW0V2r582txYunoSc2c2qPqkzFk/gzisVVVwGo4f6SkhJ/le8k
pYli7FKiKP7E8Un618SLjov+yISq1nnGsYwEV1wudw3LjXaZc+PtiU7KYGlOlhwFLtUCbojN4WTp
AigpJsVJQ01AcqmZ+8bvXraGITf3araQVfk88R28w7w+en3c+oR7kjtSO4ZZF/oX0kI8wZ6oYY74
CemAJCx6T8wEORLKjxWnJCclms1a9vDcsWPGjUvJNpuTEhNGF+MDZXgupzOb7lx7uvP0+qUbfzV3
7J2V3d8Nblo+WRze88Dh71zdvG/b85u+vLuifM+Gfx84u/fnl7cH8DFNM5VEfr/pLtSrhTo8Iz1R
jAuTxaQojNnxXLwlzBYL592CCfNuS7nCd4tyikpJSTOdZE+Tgo9Nxp72xFH5LHgMtUbtyqq/I9Xt
nnl54YzL165cm+ltrv7DDMfVj/CnwjVlDtmuLTQoymfCqCK2cMhooTHAzhPvZ7HvnHgv23TXwH7W
MLAf2WWyeGWy4sA343h6yTNqpHDZR6outxItrBaTPVq1aiZ3mki1JNnT1FQtyR0bFa8MdY51FViZ
bUTemLF9YvhR5wZXxrAxruNiOBXw/3pBscWOGQp9SNkQBeIpjWc0pjy+O/58vIin3YwN2+3IYJsz
zmTwnRl7M3hRhieDU4Yjw5khMsZNyNs9YkTsbpu3pP5sqttx5WKZ46Lj8kJZc5KlwoWXMcHLF4Gv
SCQ5Fp+QgpnSwoVstNy73OG5WrbZok3io7GfsmEDhxim4d9kUoa5xbbFty0792RFTXCIW5m4usR9
27ITwYmZrtol0bfaSqVt+YlFpdKmxG16NPPbngUBf0eVLbNupMMaGGjtfFT9drlUVdvUupF2K64A
8oWI8yr92S+PNNrLvrAOtRoXlR99mPGSpMfeOpL3Vfu17Q6yxkGMMvyNCw+RJWvASwsc9FX7QK6D
bliu/8zXGYXIK4E/i4pbTJkRtcb87CC/fXAseH+Gm8VaVCInBxXSfNz7XrMPQW4c1mjaFBmf4WS8
HovD2x7hFXDJEd6MW5ArwgtScaMQxBSZeybNi/Cc4qgtwivQ3xvhzbg/dEd4gVvMi/XLVzW3OWc2
3+2c07IqeNec5qUdK4Nr/kFriJAMoW7ujPrWxUtqgk3tLWvWOevWtJQ6/8Gf6nEhWoWLWxuuUDNB
7wadQy3QBXFFnAPNUuqglZDW/BPfm9ZB201LHa5FM2BvxcVuCa5vQWqidljX0DqMUAfagoua85+M
b6yz8QtnYaBv+hk7jXvfHDpHB6JaFi9aGWzqaG8+TvXhfvFBr9db7OkDdd9m0FDeiOJj0hBKG1b8
M/EBf46Gy1NZnAslpxuWs6HKyggzrmSQ6R1ZUHyuIlqcpU8BXJwV53DVM3r15t1WfKnCBgUTm8jO
GHZ8r/g96QBOHvFeb05ucfcp8SvYXxOvYg6y26shW3wxBvyl+CklkCqOiiMRy5HeuPhiqmgTD6Fg
+oHPAM4DLgEUahEHqBOwA3AYgMIDVgGFgFlSIw6JQ8hznyxW4EJAC2AHQKF68Sz0d0osDooVKDdV
bBe7cHVVxTbxqEF/DJoG+iPoM0Gfhixpd0T+Iai0/yCifwJyMujuCH0c+nTQxyBL+v2IvFZ0GP3a
I3SvaAtlqo6KTNidgCKAALcL3C4s3S55NAAzcZ9YaUTqAS0GXTVIsVwbQ1masUcbe1OGFu/Fkm7E
0m/Eym3Eym2U71yx4brPhkGfArEBPhvgswE+G7AqRaIN8dpkqQE7AE4hH8/zwJcMvQ7cDzhj6O8H
3gnYKyVxN9ZxBLJ6UKwI5akosqW9EzzF5SfEEiy1RyzpHZpRvOOmFBUtCxE0LkLt0rfZsDb3RsVK
bXNvWsYghdedFXGiib4D4Pg+aKIcwBhANUARTaGcQvW4mEmrrOSJUzt5p+hUOk1KUTVLOIVvijoc
qSoliAIqg8MItbGMjQ9EtUZtjhKOKGdUUZQnqi7K1CI6xQ4hVFEoysUs0ShM+AgKWUpHy2+hyebS
0Ttj9sboMf0xZ2JMurnffMZ83nzJbHKai8wec505YG41bzbvNO81R+0077TwQExrzOYY4YhxxhTF
eGLqYkyqhe2t2CIWyYMR2AFoBewEKFjjRuid4g5AI3ajEUtxhzy5gQmSA3AG/HlQEyQ7/Ozws0Nr
h9YOLQFLSx0gAGiNWM03LNf7SP9L0gIYDmsctHFY2/PAlyQHmAbJBskGyQavM/wqMnQAOwF1AGHo
zgNQNcDXbUURewBgNuyXDJ/rNo/sy696gsP7RzB9BNs7gu0cwTxl5RXFnmyghISERq3R1ZjXuE9p
0VpcLXkt+5RZ2izXrLxZ+5RyrdxVnle+TynUCl2FeYX7FFVTXWqeuk/ZMf3w9FPTT09XGqe3TO+c
LsZj63pD7qJig2a7JD0SGppWPN5eMZEfxnQagbsB5wB4UwEXAsoBLQCFHwZWcUUoBJQDZgEaASb0
eF4eL8BqxCb13YZNctLOb7ELTPy5UOnoWRXTcOQ2AroBAmM/B/tzhvcgd9jQ68DnDf2siP9eQ68C
X+8jcMA1GMdcAx6/BioHNAJaASY6LRbQOQBGBlYBrYDDAEU0oC0QC/jzaM/x50S+xzYqSaXkZLxK
EuKtjgoHj0UN2NhBA+828IMGLjdwjidumu3KNNu/TbN9b5ptOBieRxUw7DJwliemwvZChW1WhW1E
hQ2jpVAW2XiSgc0Ssz8beKaB8z2JWbYvs2yfZ9n+lmV7Ksu2Osv2rSzZbxieXRtPNHCMxOwxA08z
cK4nRrW9otoWqLbxqq3CxvYwRKdKA2caOF1i9tkL9mo7RZ1gn1E1RmKhshEq7p0GYeFQWQXIQKhs
Msi1UNkekP8OlT2qnmRfMuOVxq6Eci6oFUnsMpuqSPnzCP0bm0qHQC+BLgXdT2XMBfrjUNm90v8Z
9P8B5B9RtlX6P011Rr9uNtXQPxXp92QofxGi/jCUvw5Rf0D5RtTHQ/kXoH00lP8gyCOh/JUgO0Iu
meCKUNlItSKeLaUcLn2byMVlJtMjEadg5JWgkwc7e0P5sle1DNDHqkLaKJDhMsuTTKM6I5wa0oxJ
ZuDrUA4xjDQj6XRyGTSO2Y3kbZRtUGtIuxejmF9wXVD/q+yEnDh9weyhPeqHJzG/+RD/k00NHVLf
PCaXK6Sezu9jrqPqr7UT6ss5fWx+SO3P77PCcCq/j7Mjag8WWYcvZ0fVw/lL1ec1w7pPgxVb3V1W
oP5Qa1CfcEEOqffmn5Rp0CrMeD7M/vxJ6vSyQ2qNq4/B7ClDME+0WqqtUSdAXdLHpvYeUkfl9MlU
ijDGoaPqSETM1YxU5o0/zseShXV48i3tlkWW+ZbZlomW0ZYCi9OSYRlmSbQmWB3WOGusNdpqtZqt
ipVbyZrYFz7vcctv4kSz8RluViRWDN7BJeaDn8ycWTmeHX2IqOW1cyuZnlBLtfWV+nh3bZ8lPEcv
cdfq1rpv+3oYe9gPSedb+xjV+1CgUrUlXU+o8h3Dra9wy0Ppkm7Y8hAuprV6fxPVLnLqV+ZiHtGz
G3STVplKyWvLU8sTJsVPqKn+BhSIYPfNX6r767/UDP2x2rk+/dkMv14smXCGv1afPNd5u+8YX81b
vNXHeKskft8xtp6v9s6Rera+2n/DjbJ5K9yoTBLp1kvZ0o2yWa/hNt1wQ5lme6t7srMHnV5iU6UT
yuclw2np4Fg5CIGx6iSBG8+kHGOsHJ4p3VAPg4PZvz5YLDG7MZg9lozBhkmnHpcLLvku6dIz3gWH
Htd4w3zopllzDabjJ5cRx8X8RhzGbvrkDfqgCiI+3Aof9//LX3Pl/4Uz6w2+v7jJ26x5A5q3GRDQ
t61dlqpvXuR09ix+XxqcusgNLGpaJmmwWX9fa67WF2vVzp5g0zeYm6Q5qFX3UJO33tfT5GmuDgU9
Qa8WrPb37u+sqr0l1oM3YlV1fsNgnXKwKhlrf+03mGuleb+MVStj1cpY+z37jVi1cypZbZ2vx0qV
/qrbB2kvj4nG8xBIz/JXJjtaJxkPx8Ss1E3pxxXCayvG7ddjtUrdBpCmgoqCCmnC0ylNcVDbI6bU
TROz0o+zgxGTA+p4rZLclOpdXn3j39bW1i6ho8MN3N6Rauja8dBmza3Va2Y3+PQyvcyrewLVfia3
oyPyq/J5HKfKTpfxlrLOsh1l3WWHy0wdHX6oE05ln87mjdkt2Z3ZO7K7sw9nm6Xhdt9RT1l39qfZ
ogPVxNrx81YbMTtA8Zdie0eb/BECtAEGw7k73FW+imxqwtcuw5d5AQ0BaIDRgLkAE/0c+DeADwGf
AxS6D/hRwDOAXqkRBaLAm7q8Wkb0u+WhkyqKe4vGFpf0gQaXDNK5DYPUO3OQllUUp4KGykdHV9jx
4c3oOPBrgPcAfwL8N8AkikWxMXjHYNX626jNzZA+QWiXqM3dztxgmFzu9ja3myTIAscOwNXNbq17
Ym0dhKXAhoDAydC2yW4dkt50/B9SykZoZW5kc3RyZWFtCmVuZG9iagoxMTEgMCBvYmoKNjQ4Mgpl
bmRvYmoKMTEyIDAgb2JqCjk3MzIKZW5kb2JqCjggMCBvYmoKPDwKL1R5cGUgL0ZvbnQKL1N1YnR5
cGUgL1RydWVUeXBlCi9OYW1lIC9GMgovQmFzZUZvbnQgL1RpbWVzTmV3Um9tYW4sQm9sZAovRmly
c3RDaGFyIDMyCi9MYXN0Q2hhciAyNTUKL1dpZHRocyBbMjUwIDMzMyA1NTUgNTAwIDUwMCAxMDAw
IDgzMyAyNzggMzMzIDMzMyA1MDAgNTcwIDI1MCAzMzMgMjUwIDI3OAo1MDAgNTAwIDUwMCA1MDAg
NTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgMzMzIDMzMyA1NzAgNTcwIDU3MCA1MDAKOTMwIDcyMiA2
NjcgNzIyIDcyMiA2NjcgNjExIDc3OCA3NzggMzg5IDUwMCA3NzggNjY3IDk0NCA3MjIgNzc4CjYx
MSA3NzggNzIyIDU1NiA2NjcgNzIyIDcyMiAxMDAwIDcyMiA3MjIgNjY3IDMzMyAyNzggMzMzIDU4
MSA1MDAKMzMzIDUwMCA1NTYgNDQ0IDU1NiA0NDQgMzMzIDUwMCA1NTYgMjc4IDMzMyA1NTYgMjc4
IDgzMyA1NTYgNTAwCjU1NiA1NTYgNDQ0IDM4OSAzMzMgNTU2IDUwMCA3MjIgNTAwIDUwMCA0NDQg
Mzk0IDIyMCAzOTQgNTIwIDc3OAo1MDAgNzc4IDMzMyA1MDAgNTAwIDEwMDAgNTAwIDUwMCAzMzMg
MTAwMCA1NTYgMzMzIDEwMDAgNzc4IDY2NyA3NzgKNzc4IDMzMyAzMzMgNTAwIDUwMCAzNTAgNTAw
IDEwMDAgMzMzIDEwMDAgMzg5IDMzMyA3MjIgNzc4IDQ0NCA3MjIKMjUwIDMzMyA1MDAgNTAwIDUw
MCA1MDAgMjIwIDUwMCAzMzMgNzQ3IDMwMCA1MDAgNTcwIDMzMyA3NDcgNTAwCjQwMCA1NDkgMzAw
IDMwMCAzMzMgNTc2IDU0MCAyNTAgMzMzIDMwMCAzMzAgNTAwIDc1MCA3NTAgNzUwIDUwMAo3MjIg
NzIyIDcyMiA3MjIgNzIyIDcyMiAxMDAwIDcyMiA2NjcgNjY3IDY2NyA2NjcgMzg5IDM4OSAzODkg
Mzg5CjcyMiA3MjIgNzc4IDc3OCA3NzggNzc4IDc3OCA1NzAgNzc4IDcyMiA3MjIgNzIyIDcyMiA3
MjIgNjExIDU1Ngo1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA3MjIgNDQ0IDQ0NCA0NDQgNDQ0IDQ0
NCAyNzggMjc4IDI3OCAyNzgKNTAwIDU1NiA1MDAgNTAwIDUwMCA1MDAgNTAwIDU0OSA1MDAgNTU2
IDU1NiA1NTYgNTU2IDUwMCA1NTYgNTAwXQovRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZwovRm9u
dERlc2NyaXB0b3IgMTEzIDAgUgo+PgplbmRvYmoKMTEzIDAgb2JqCjw8Ci9UeXBlIC9Gb250RGVz
Y3JpcHRvcgovRm9udE5hbWUgL1RpbWVzTmV3Um9tYW4sQm9sZAovRmxhZ3MgMzQKL0ZvbnRCQm94
IFstNTU4IC0zMDcgMjAwMCAxMDI2XQovU3RlbVYgMTEwCi9JdGFsaWNBbmdsZSAwCi9DYXBIZWln
aHQgODkxCi9Bc2NlbnQgODkxCi9EZXNjZW50IC0yMTYKPj4KZW5kb2JqCjkgMCBvYmoKPDwKL1R5
cGUgL0ZvbnQKL1N1YnR5cGUgL1RydWVUeXBlCi9OYW1lIC9GMwovQmFzZUZvbnQgL0FyaWFsCi9G
aXJzdENoYXIgMzIKL0xhc3RDaGFyIDI1NQovV2lkdGhzIFsyNzggMjc4IDM1NSA1NTYgNTU2IDg4
OSA2NjcgMTkxIDMzMyAzMzMgMzg5IDU4NCAyNzggMzMzIDI3OCAyNzgKNTU2IDU1NiA1NTYgNTU2
IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDI3OCAyNzggNTg0IDU4NCA1ODQgNTU2CjEwMTUgNjY3
IDY2NyA3MjIgNzIyIDY2NyA2MTEgNzc4IDcyMiAyNzggNTAwIDY2NyA1NTYgODMzIDcyMiA3NzgK
NjY3IDc3OCA3MjIgNjY3IDYxMSA3MjIgNjY3IDk0NCA2NjcgNjY3IDYxMSAyNzggMjc4IDI3OCA0
NjkgNTU2CjMzMyA1NTYgNTU2IDUwMCA1NTYgNTU2IDI3OCA1NTYgNTU2IDIyMiAyMjIgNTAwIDIy
MiA4MzMgNTU2IDU1Ngo1NTYgNTU2IDMzMyA1MDAgMjc4IDU1NiA1MDAgNzIyIDUwMCA1MDAgNTAw
IDMzNCAyNjAgMzM0IDU4NCA3NTAKNTU2IDc1MCAyMjIgNTU2IDMzMyAxMDAwIDU1NiA1NTYgMzMz
IDEwMDAgNjY3IDMzMyAxMDAwIDc1MCA2MTEgNzUwCjc1MCAyMjIgMjIyIDMzMyAzMzMgMzUwIDU1
NiAxMDAwIDMzMyAxMDAwIDUwMCAzMzMgOTQ0IDc1MCA1MDAgNjY3CjI3OCAzMzMgNTU2IDU1NiA1
NTYgNTU2IDI2MCA1NTYgMzMzIDczNyAzNzAgNTU2IDU4NCAzMzMgNzM3IDU1Mgo0MDAgNTQ5IDMz
MyAzMzMgMzMzIDU3NiA1MzcgMjc4IDMzMyAzMzMgMzY1IDU1NiA4MzQgODM0IDgzNCA2MTEKNjY3
IDY2NyA2NjcgNjY3IDY2NyA2NjcgMTAwMCA3MjIgNjY3IDY2NyA2NjcgNjY3IDI3OCAyNzggMjc4
IDI3OAo3MjIgNzIyIDc3OCA3NzggNzc4IDc3OCA3NzggNTg0IDc3OCA3MjIgNzIyIDcyMiA3MjIg
NjY3IDY2NyA2MTEKNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgODg5IDUwMCA1NTYgNTU2IDU1NiA1
NTYgMjc4IDI3OCAyNzggMjc4CjU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NDkgNjExIDU1
NiA1NTYgNTU2IDU1NiA1MDAgNTU2IDUwMF0KL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcKL0Zv
bnREZXNjcmlwdG9yIDExNCAwIFIKPj4KZW5kb2JqCjExNCAwIG9iago8PAovVHlwZSAvRm9udERl
c2NyaXB0b3IKL0ZvbnROYW1lIC9BcmlhbAovRmxhZ3MgMzIKL0ZvbnRCQm94IFstNjY1IC0zMjUg
MjAwMCAxMDA2XQovU3RlbVYgOTUKL0l0YWxpY0FuZ2xlIDAKL0NhcEhlaWdodCA5MDUKL0FzY2Vu
dCA5MDUKL0Rlc2NlbnQgLTIxMgo+PgplbmRvYmoKMTggMCBvYmoKPDwKL1R5cGUgL0ZvbnQKL1N1
YnR5cGUgL1RydWVUeXBlCi9OYW1lIC9GNAovQmFzZUZvbnQgL1RpbWVzTmV3Um9tYW4sSXRhbGlj
Ci9GaXJzdENoYXIgMzIKL0xhc3RDaGFyIDI1NQovV2lkdGhzIFsyNTAgMzMzIDQyMCA1MDAgNTAw
IDgzMyA3NzggMjE0IDMzMyAzMzMgNTAwIDY3NSAyNTAgMzMzIDI1MCAyNzgKNTAwIDUwMCA1MDAg
NTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDMzMyAzMzMgNjc1IDY3NSA2NzUgNTAwCjkyMCA2
MTEgNjExIDY2NyA3MjIgNjExIDYxMSA3MjIgNzIyIDMzMyA0NDQgNjY3IDU1NiA4MzMgNjY3IDcy
Mgo2MTEgNzIyIDYxMSA1MDAgNTU2IDcyMiA2MTEgODMzIDYxMSA1NTYgNTU2IDM4OSAyNzggMzg5
IDQyMiA1MDAKMzMzIDUwMCA1MDAgNDQ0IDUwMCA0NDQgMjc4IDUwMCA1MDAgMjc4IDI3OCA0NDQg
Mjc4IDcyMiA1MDAgNTAwCjUwMCA1MDAgMzg5IDM4OSAyNzggNTAwIDQ0NCA2NjcgNDQ0IDQ0NCAz
ODkgNDAwIDI3NSA0MDAgNTQxIDc3OAo1MDAgNzc4IDMzMyA1MDAgNTU2IDg4OSA1MDAgNTAwIDMz
MyAxMDAwIDUwMCAzMzMgOTQ0IDc3OCA1NTYgNzc4Cjc3OCAzMzMgMzMzIDU1NiA1NTYgMzUwIDUw
MCA4ODkgMzMzIDk4MCAzODkgMzMzIDY2NyA3NzggMzg5IDU1NgoyNTAgMzg5IDUwMCA1MDAgNTAw
IDUwMCAyNzUgNTAwIDMzMyA3NjAgMjc2IDUwMCA2NzUgMzMzIDc2MCA1MDAKNDAwIDU0OSAzMDAg
MzAwIDMzMyA1NzYgNTIzIDI1MCAzMzMgMzAwIDMxMCA1MDAgNzUwIDc1MCA3NTAgNTAwCjYxMSA2
MTEgNjExIDYxMSA2MTEgNjExIDg4OSA2NjcgNjExIDYxMSA2MTEgNjExIDMzMyAzMzMgMzMzIDMz
Mwo3MjIgNjY3IDcyMiA3MjIgNzIyIDcyMiA3MjIgNjc1IDcyMiA3MjIgNzIyIDcyMiA3MjIgNTU2
IDYxMSA1MDAKNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNjY3IDQ0NCA0NDQgNDQ0IDQ0NCA0NDQg
Mjc4IDI3OCAyNzggMjc4CjUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1NDkgNTAwIDUwMCA1
MDAgNTAwIDUwMCA0NDQgNTAwIDQ0NF0KL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcKL0ZvbnRE
ZXNjcmlwdG9yIDExNSAwIFIKPj4KZW5kb2JqCjExNSAwIG9iago8PAovVHlwZSAvRm9udERlc2Ny
aXB0b3IKL0ZvbnROYW1lIC9UaW1lc05ld1JvbWFuLEl0YWxpYwovRmxhZ3MgOTgKL0ZvbnRCQm94
IFstNDk4IC0zMDcgMTEyMCAxMDIzXQovU3RlbVYgMTA3Ci9JdGFsaWNBbmdsZSAtMTYKL0NhcEhl
aWdodCA4OTEKL0FzY2VudCA4OTEKL0Rlc2NlbnQgLTIxNgo+PgplbmRvYmoKMjcgMCBvYmoKPDwK
L1R5cGUgL0ZvbnQKL1N1YnR5cGUgL1RydWVUeXBlCi9OYW1lIC9GNQovQmFzZUZvbnQgL1N5bWJv
bAovRmlyc3RDaGFyIDMyCi9MYXN0Q2hhciAyNTUKL1dpZHRocyBbMjUwIDMzMyA3MTMgNTAwIDU0
OSA4MzMgNzc4IDQzOSAzMzMgMzMzIDUwMCA1NDkgMjUwIDU0OSAyNTAgMjc4CjUwMCA1MDAgNTAw
IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAyNzggMjc4IDU0OSA1NDkgNTQ5IDQ0NAo1NDkg
NzIyIDY2NyA3MjIgNjEyIDYxMSA3NjMgNjAzIDcyMiAzMzMgNjMxIDcyMiA2ODYgODg5IDcyMiA3
MjIKNzY4IDc0MSA1NTYgNTkyIDYxMSA2OTAgNDM5IDc2OCA2NDUgNzk1IDYxMSAzMzMgODYzIDMz
MyA2NTggNTAwCjUwMCA2MzEgNTQ5IDU0OSA0OTQgNDM5IDUyMSA0MTEgNjAzIDMyOSA2MDMgNTQ5
IDU0OSA1NzYgNTIxIDU0OQo1NDkgNTIxIDU0OSA2MDMgNDM5IDU3NiA3MTMgNjg2IDQ5MyA2ODYg
NDk0IDQ4MCAyMDAgNDgwIDU0OSA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2
MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjIwIDI0NyA1NDkgMTY3
IDcxMyA1MDAgNzUzIDc1MyA3NTMgNzUzIDEwNDIgOTg3IDYwMyA5ODcgNjAzCjQwMCA1NDkgNDEx
IDU0OSA1NDkgNzEzIDQ5NCA0NjAgNTQ5IDU0OSA1NDkgNTQ5IDEwMDAgNjAzIDEwMDAgNjU4Cjgy
MyA2ODYgNzk1IDk4NyA3NjggNzY4IDgyMyA3NjggNzY4IDcxMyA3MTMgNzEzIDcxMyA3MTMgNzEz
IDcxMwo3NjggNzEzIDc5MCA3OTAgODkwIDgyMyA1NDkgMjUwIDcxMyA2MDMgNjAzIDEwNDIgOTg3
IDYwMyA5ODcgNjAzCjQ5NCAzMjkgNzkwIDc5MCA3ODYgNzEzIDM4NCAzODQgMzg0IDM4NCAzODQg
Mzg0IDQ5NCA0OTQgNDk0IDQ5NAo2MDAgMzI5IDI3NCA2ODYgNjg2IDY4NiAzODQgMzg0IDM4NCAz
ODQgMzg0IDM4NCA0OTQgNDk0IDQ5NCA2MDBdCi9Gb250RGVzY3JpcHRvciAxMTYgMCBSCj4+CmVu
ZG9iagoxMTYgMCBvYmoKPDwKL1R5cGUgL0ZvbnREZXNjcmlwdG9yCi9Gb250TmFtZSAvU3ltYm9s
Ci9GbGFncyA2Ci9Gb250QkJveCBbMCAtMjIwIDExMTMgMTAwNV0KL1N0ZW1WIDgzCi9JdGFsaWNB
bmdsZSAwCi9DYXBIZWlnaHQgMTAwNQovQXNjZW50IDEwMDUKL0Rlc2NlbnQgLTIyMAo+PgplbmRv
YmoKNzMgMCBvYmoKPDwKL1R5cGUgL0ZvbnQKL1N1YnR5cGUgL1RydWVUeXBlCi9OYW1lIC9GNgov
QmFzZUZvbnQgL0NlbnR1cnlHb3RoaWMsQm9sZAovRmlyc3RDaGFyIDMyCi9MYXN0Q2hhciAyNTUK
L1dpZHRocyBbMjgwIDI4MCAzNjAgNjAwIDU2MCA4NjAgNjgwIDIyMCAzODAgMzgwIDQ0MCA2MDAg
MjgwIDQyMCAyODAgNDYwCjU2MCA1NjAgNTYwIDU2MCA1NjAgNTYwIDU2MCA1NjAgNTYwIDU2MCAy
ODAgMjgwIDYwMCA2MDAgNjAwIDU2MAo3NDAgNzQwIDU4MCA3ODAgNzAwIDUyMCA0ODAgODQwIDY4
MCAyODAgNDgwIDYyMCA0NDAgOTAwIDc0MCA4NDAKNTYwIDg0MCA1ODAgNTIwIDQyMCA2NDAgNzAw
IDkwMCA2ODAgNjIwIDUwMCAzMjAgNjQwIDMyMCA2MDAgNTAwCjQyMCA2NjAgNjYwIDY0MCA2NjAg
NjQwIDI4MCA2NjAgNjAwIDI0MCAyNjAgNTgwIDI0MCA5NDAgNjAwIDY0MAo2NjAgNjYwIDMyMCA0
NDAgMzAwIDYwMCA1NjAgODAwIDU2MCA1ODAgNDYwIDM0MCA2MDAgMzQwIDYwMCA3NTAKNTYwIDc1
MCAyODAgNTYwIDQ4MCAxMDAwIDU2MCA1NjAgNTQwIDEyODAgNTIwIDI0MCAxMDYwIDc1MCA1MDAg
NzUwCjc1MCAyODAgMjgwIDQ4MCA0ODAgNjAwIDUwMCAxMDAwIDQ4MCAxMDAwIDQ0MCAyNDAgMTA4
MCA3NTAgNDYwIDYyMAoyODAgMjgwIDU2MCA1NjAgNjAwIDU2MCA2MDAgNTYwIDUwMCA3NDAgMzYw
IDQ2MCA2MDAgNDIwIDc0MCA1MDAKNDAwIDU0OSAzMzYgMzM2IDQyMCA1NzYgNjAwIDMzMyAzNDAg
MzM2IDM2MCA0NjAgODQwIDg0MCA4NDAgNTYwCjc0MCA3NDAgNzQwIDc0MCA3NDAgNzQwIDkwMCA3
ODAgNTIwIDUyMCA1MjAgNTIwIDI4MCAyODAgMjgwIDI4MAo3NDIgNzQwIDg0MCA4NDAgODQwIDg0
MCA4NDAgNjAwIDg0MCA2NDAgNjQwIDY0MCA2NDAgNjIwIDU2MCA2MDAKNjYwIDY2MCA2NjAgNjYw
IDY2MCA2NjAgMTA4MCA2NDAgNjQwIDY0MCA2NDAgNjQwIDI0MCAyNDAgMjQwIDI0MAo2NDAgNjAw
IDY0MCA2NDAgNjQwIDY0MCA2NDAgNTQ5IDY2MCA2MDAgNjAwIDYwMCA2MDAgNTgwIDY2MCA1ODBd
Ci9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nCi9Gb250RGVzY3JpcHRvciAxMTcgMCBSCj4+CmVu
ZG9iagoxMTcgMCBvYmoKPDwKL1R5cGUgL0ZvbnREZXNjcmlwdG9yCi9Gb250TmFtZSAvQ2VudHVy
eUdvdGhpYyxCb2xkCi9GbGFncyAzMgovRm9udEJCb3ggWy0xMTUgLTMwNyAxMjYwIDExMjJdCi9T
dGVtViAxMTAKL0l0YWxpY0FuZ2xlIDAKL0NhcEhlaWdodCA5OTIKL0FzY2VudCA5OTIKL0Rlc2Nl
bnQgLTIyMAo+PgplbmRvYmoKODIgMCBvYmoKPDwKL1R5cGUgL0ZvbnQKL1N1YnR5cGUgL1RydWVU
eXBlCi9OYW1lIC9GNwovQmFzZUZvbnQgL0NvdXJpZXJOZXcKL0ZpcnN0Q2hhciAzMgovTGFzdENo
YXIgMjU1Ci9XaWR0aHMgWzYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2
MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw
IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAg
NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2
MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw
CjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg
NjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2
MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw
IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg
NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2
MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAw
IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDBd
Ci9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nCi9Gb250RGVzY3JpcHRvciAxMTggMCBSCj4+CmVu
ZG9iagoxMTggMCBvYmoKPDwKL1R5cGUgL0ZvbnREZXNjcmlwdG9yCi9Gb250TmFtZSAvQ291cmll
ck5ldwovRmxhZ3MgMzUKL0ZvbnRCQm94IFstMjEgLTY4MCA2MzggMTAyMV0KL1N0ZW1WIDMwMAov
SXRhbGljQW5nbGUgMAovQ2FwSGVpZ2h0IDgzMwovQXNjZW50IDgzMwovRGVzY2VudCAtMzAwCj4+
CmVuZG9iago4MyAwIG9iago8PAovVHlwZSAvRm9udAovU3VidHlwZSAvVHJ1ZVR5cGUKL05hbWUg
L0Y4Ci9CYXNlRm9udCAvQ291cmllck5ldyxCb2xkCi9GaXJzdENoYXIgMzIKL0xhc3RDaGFyIDI1
NQovV2lkdGhzIFs2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw
IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg
NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2
MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAw
IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAg
NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2
MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw
MCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw
IDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg
NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2
MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAw
IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAg
NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwXQovRW5j
b2RpbmcgL1dpbkFuc2lFbmNvZGluZwovRm9udERlc2NyaXB0b3IgMTE5IDAgUgo+PgplbmRvYmoK
MTE5IDAgb2JqCjw8Ci9UeXBlIC9Gb250RGVzY3JpcHRvcgovRm9udE5hbWUgL0NvdXJpZXJOZXcs
Qm9sZAovRmxhZ3MgMzUKL0ZvbnRCQm94IFstNDYgLTcxMCA3MDIgMTIyMV0KL1N0ZW1WIDMwMAov
SXRhbGljQW5nbGUgMAovQ2FwSGVpZ2h0IDgzMwovQXNjZW50IDgzMwovRGVzY2VudCAtMzAwCj4+
CmVuZG9iago4NCAwIG9iago8PAovVHlwZSAvRm9udAovU3VidHlwZSAvVHJ1ZVR5cGUKL05hbWUg
L0Y5Ci9CYXNlRm9udCAvQ291cmllck5ldyxJdGFsaWMKL0ZpcnN0Q2hhciAzMgovTGFzdENoYXIg
MjU1Ci9XaWR0aHMgWzYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg
NjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2
MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw
IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAg
NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2
MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw
IDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg
NjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2
MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw
IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg
NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2
MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDBdCi9F
bmNvZGluZyAvV2luQW5zaUVuY29kaW5nCi9Gb250RGVzY3JpcHRvciAxMjAgMCBSCj4+CmVuZG9i
agoxMjAgMCBvYmoKPDwKL1R5cGUgL0ZvbnREZXNjcmlwdG9yCi9Gb250TmFtZSAvQ291cmllck5l
dyxJdGFsaWMKL0ZsYWdzIDk5Ci9Gb250QkJveCBbLTY3IC0yNzQgODAwIDEwMDBdCi9TdGVtViAz
MDAKL0l0YWxpY0FuZ2xlIC0xMgovQ2FwSGVpZ2h0IDgzMwovQXNjZW50IDgzMwovRGVzY2VudCAt
MzAwCj4+CmVuZG9iagozIDAgb2JqCjw8Ci9UeXBlIC9QYWdlcwovQ291bnQgMTAKL0tpZHMgWzYg
MCBSIDE3IDAgUiAyNiAwIFIgNDEgMCBSIDUxIDAgUiA2MCAwIFIgNzIgMCBSIDgxIDAgUgo5MiAw
IFIgMTAwIDAgUl0KPj4KZW5kb2JqCjIgMCBvYmoKPDwKL1R5cGUgL0NhdGFsb2cKL1BhZ2VzIDMg
MCBSCi9WaWV3ZXJQcmVmZXJlbmNlcyAxMjEgMCBSCj4+CmVuZG9iagoxMjEgMCBvYmoKPDwKL1R5
cGUgL1ZpZXdlclByZWZlcmVuY2VzCj4+CmVuZG9iagp4cmVmCjAgMTIyCjAwMDAwMDAwMDAgNjU1
MzUgZg0KMDAwMDAwMDAxNiAwMDAwMCBuDQowMDAwMDYwMjE0IDAwMDAwIG4NCjAwMDAwNjAwOTIg
MDAwMDAgbg0KMDAwMDAwMDIzNCAwMDAwMCBuDQowMDAwMDAzNTg0IDAwMDAwIG4NCjAwMDAwMDM2
MDQgMDAwMDAgbg0KMDAwMDA0MTQ1NiAwMDAwMCBuDQowMDAwMDUwMDc0IDAwMDAwIG4NCjAwMDAw
NTEzNDMgMDAwMDAgbg0KMDAwMDAwMzc4NiAwMDAwMCBuDQowMDAwMDAzODE4IDAwMDAwIG4NCjAw
MDAwMDM5MzMgMDAwMDAgbg0KMDAwMDAwMzk5NiAwMDAwMCBuDQowMDAwMDA0MTExIDAwMDAwIG4N
CjAwMDAwMDQxNzQgMDAwMDAgbg0KMDAwMDAwOTEyMSAwMDAwMCBuDQowMDAwMDA5MTQyIDAwMDAw
IG4NCjAwMDAwNTI1ODQgMDAwMDAgbg0KMDAwMDAwOTM0NCAwMDAwMCBuDQowMDAwMDA5Mzc2IDAw
MDAwIG4NCjAwMDAwMDk0OTEgMDAwMDAgbg0KMDAwMDAwOTU1NCAwMDAwMCBuDQowMDAwMDA5NjY5
IDAwMDAwIG4NCjAwMDAwMDk3MzIgMDAwMDAgbg0KMDAwMDAxMzc2OCAwMDAwMCBuDQowMDAwMDEz
Nzg5IDAwMDAwIG4NCjAwMDAwNTM4NTMgMDAwMDAgbg0KMDAwMDAxMzk4NCAwMDAwMCBuDQowMDAw
MDE0MDM3IDAwMDAwIG4NCjAwMDAwMTQxNTcgMDAwMDAgbg0KMDAwMDAxNDIzOCAwMDAwMCBuDQow
MDAwMDE0MzU4IDAwMDAwIG4NCjAwMDAwMTQ0MzkgMDAwMDAgbg0KMDAwMDAxNDU1OSAwMDAwMCBu
DQowMDAwMDE0NjM0IDAwMDAwIG4NCjAwMDAwMTQ3NDkgMDAwMDAgbg0KMDAwMDAxNDgxMiAwMDAw
MCBuDQowMDAwMDE0OTI3IDAwMDAwIG4NCjAwMDAwMTQ5OTAgMDAwMDAgbg0KMDAwMDAyMDc5MiAw
MDAwMCBuDQowMDAwMDIwODEzIDAwMDAwIG4NCjAwMDAwMjEwMDggMDAwMDAgbg0KMDAwMDAyMTA0
NyAwMDAwMCBuDQowMDAwMDIxMTY3IDAwMDAwIG4NCjAwMDAwMjEyNDkgMDAwMDAgbg0KMDAwMDAy
MTM2NCAwMDAwMCBuDQowMDAwMDIxNDI3IDAwMDAwIG4NCjAwMDAwMjE1NDIgMDAwMDAgbg0KMDAw
MDAyMTYwNSAwMDAwMCBuDQowMDAwMDI3MzMwIDAwMDAwIG4NCjAwMDAwMjczNTEgMDAwMDAgbg0K
MDAwMDA0MjcwOSAwMDAwMCBuDQowMDAwMDI3NTcwIDAwMDAwIG4NCjAwMDAwMjc2MDIgMDAwMDAg
bg0KMDAwMDAyNzcxNyAwMDAwMCBuDQowMDAwMDI3NzgwIDAwMDAwIG4NCjAwMDAwMjc4OTUgMDAw
MDAgbg0KMDAwMDAyNzk1OCAwMDAwMCBuDQowMDAwMDMxODM2IDAwMDAwIG4NCjAwMDAwMzE4NTcg
MDAwMDAgbg0KMDAwMDAzMjA4MiAwMDAwMCBuDQowMDAwMDMyNDc5IDAwMDAwIG4NCjAwMDAwMzI0
OTkgMDAwMDAgbg0KMDAwMDAzMjU3OSAwMDAwMCBuDQowMDAwMDMyNTk4IDAwMDAwIG4NCjAwMDAw
MzI2MzAgMDAwMDAgbg0KMDAwMDAzMjc0NSAwMDAwMCBuDQowMDAwMDMyODA4IDAwMDAwIG4NCjAw
MDAwMzI5MjMgMDAwMDAgbg0KMDAwMDAzMjk4NiAwMDAwMCBuDQowMDAwMDM1NjY4IDAwMDAwIG4N
CjAwMDAwMzU2ODkgMDAwMDAgbg0KMDAwMDA1NTA2NSAwMDAwMCBuDQowMDAwMDM1ODk1IDAwMDAw
IG4NCjAwMDAwMzU5MjcgMDAwMDAgbg0KMDAwMDAzNjA0MiAwMDAwMCBuDQowMDAwMDM2MTA1IDAw
MDAwIG4NCjAwMDAwMzYyMjAgMDAwMDAgbg0KMDAwMDAzNjI4MyAwMDAwMCBuDQowMDAwMDM3NTMx
IDAwMDAwIG4NCjAwMDAwMzc1NTIgMDAwMDAgbg0KMDAwMDA1NjMzNCAwMDAwMCBuDQowMDAwMDU3
NTc4IDAwMDAwIG4NCjAwMDAwNTg4MzIgMDAwMDAgbg0KMDAwMDAzNzc2MCAwMDAwMCBuDQowMDAw
MDM3NzkyIDAwMDAwIG4NCjAwMDAwMzc5MDcgMDAwMDAgbg0KMDAwMDAzNzk3MCAwMDAwMCBuDQow
MDAwMDM4MDg1IDAwMDAwIG4NCjAwMDAwMzgxNDggMDAwMDAgbg0KMDAwMDAzOTIwMiAwMDAwMCBu
DQowMDAwMDM5MjIyIDAwMDAwIG4NCjAwMDAwMzk0MDggMDAwMDAgbg0KMDAwMDAzOTQ0MCAwMDAw
MCBuDQowMDAwMDM5NTU1IDAwMDAwIG4NCjAwMDAwMzk2MTggMDAwMDAgbg0KMDAwMDAzOTczMyAw
MDAwMCBuDQowMDAwMDM5Nzk2IDAwMDAwIG4NCjAwMDAwNDA4NDAgMDAwMDAgbg0KMDAwMDA0MDg2
MCAwMDAwMCBuDQowMDAwMDQxMDU5IDAwMDAwIG4NCjAwMDAwNDEwOTQgMDAwMDAgbg0KMDAwMDA0
MTIxMSAwMDAwMCBuDQowMDAwMDQxMjc1IDAwMDAwIG4NCjAwMDAwNDEzOTIgMDAwMDAgbg0KMDAw
MDA0MjUzMSAwMDAwMCBuDQowMDAwMDQzMTA2IDAwMDAwIG4NCjAwMDAwNDI5MDIgMDAwMDAgbg0K
MDAwMDA0MzQ1MyAwMDAwMCBuDQowMDAwMDQzNDMyIDAwMDAwIG4NCjAwMDAwNTAwMzAgMDAwMDAg
bg0KMDAwMDA1MDA1MiAwMDAwMCBuDQowMDAwMDUxMTU5IDAwMDAwIG4NCjAwMDAwNTI0MTQgMDAw
MDAgbg0KMDAwMDA1MzY2NSAwMDAwMCBuDQowMDAwMDU0ODk2IDAwMDAwIG4NCjAwMDAwNTYxNTAg
MDAwMDAgbg0KMDAwMDA1NzQwNCAwMDAwMCBuDQowMDAwMDU4NjUzIDAwMDAwIG4NCjAwMDAwNTk5
MDkgMDAwMDAgbg0KMDAwMDA2MDI5MCAwMDAwMCBuDQp0cmFpbGVyCjw8Ci9TaXplIDEyMgovSW5m
byAxIDAgUgovUm9vdCAyIDAgUgovSUQgWzwwOEU1NUU1RjBGNEU3RDQzN0NCQ0IxNThGOUNFOUJB
QT48MDhFNTVFNUYwRjRFN0Q0MzdDQkNCMTU4RjlDRTlCQUE+XQo+PgpzdGFydHhyZWYKNjAzMzgK
JSVFT0YK
------=_Part_63385_735360.1229469659705--

From hash-forum@nist.gov  Tue Dec 16 22:52:03 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBH6pvHs012895
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Tue, 16 Dec 2008 22:51:58 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBH6pFdx007831;
	Wed, 17 Dec 2008 01:51:15 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBH6p67d013680;
	Wed, 17 Dec 2008 01:51:06 -0500
Date: Wed, 17 Dec 2008 01:51:06 -0500
Message-Id: <4948A0FA.1080907@mit.edu>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "Ronald L. Rivest" 
To: Multiple recipients of list 
Subject: Re: Demonstrating attacks
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
In-Reply-To: <20081216235332.565109yp044r3kjw@webmail.nist.gov>
References: <20081216235332.565109yp044r3kjw@webmail.nist.gov>
MIME-Version: 1.0
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 16 Dec 2008 22:51:59 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 400


Hi John --

This does seem reasonable.

Particularly for the preimage attacks, which only need a random
target.

For the second-preimage attacks, there could be issues, such as
those you suggest, where the attack only works on certain classes
of messages.  One possible concern with your proposal here is
that the messages are all short.

Here is a proposal in the same spirit that may address some of these
concerns.  It goes a bit further in trying to accommodate such
issues.  Maybe it is overkill...

Suppose the attacker wants to demonstrate second-preimage attacks
on a hash function
    h: {0,1}^* --> {0,1}^n

With this proposal, the attacker must now specify:

    -- a length m of messages which he asserts he can perform
       second-preimage attacks on h

    -- An  m x n matrix A and a length m vector b over GF(2)
       of the attackers choice.  (Here m >= n .)
       These specify the "space" S that the attacker claims he
       can perform his attack, via:

           S = { y | y = Ax + b  for x in {0,1}^n }

       The matrix A must have full column rank n.
       Thus, S has 2**n elements.  But it could include
       very long messages (if m is big), could
       have some image positions fixed constants and others
       variable, could be a set of ASCII messages, etc...
       (Math in GF(2).)

       The adversary's actual "challenge set" C will be a sparse
       subset of S, using a Fiat-Shamir-like approach.

    -- The actual set C of challenge messages will be determined
       as follows.  C will have size 2**64, as in your proposal,
       but will be a subset of S.

       Let  denote the 64-bit representation of an integer i,
       0 <= i < 2**64.

       Let  represent the representation of A as a bit-string
       of length mn (a_11, a_12, ..., a_1n, ..., a_mn).

       Let  be a length-m representation of the vector b.

       For a 64-bit integer i, let

           x_i = h(  ||  ||  )

       The input to h here has length 64 + mn + m , the output x_i
       has length n.

       So, { x_i } is a set of 2**64 "pseudo-random" length-n vectors.

       Then let

           y_i = A x_i + b

       be a length-m message determined from x_i, A, and b.  The
       message y_i will be a member of S, and no two y_i's will be
       equal.

       Thus  C = { y_i }  is a pseudo-random subset of S of size 2**64.

To demonstrate a successful attack, the adversary must find an i and
a z_i != y_i such that

       h( y_i ) = h( z_i )

z_i is of course a demonstrated second preimage for the challenge
message y_i , where y_i has the "special structure" that makes
his attack work (i.e., it is an element of S).

So, the above proposal is offered in the same spirit as yours,
but attempts to handle issues of special message formats needed
for the attack...

Cheers,
Ron







    --




On 12/17/2008 12:02 AM, John Kelsey wrote:
> 
> Several people have demonstrated attacks on submitted hash functions.  
> If you want to demonstrate a collision, pseudocollision, or 
> near-collision (or near-pseudocollision) attack, you can do that pretty 
> trivially.  You just produce the pair of inputs that collides or almost 
> collides.
> 
> However, demonstrating preimage, pseudopreimage, second-preimage, or 
> near-preimage attacks is a bit less straightforward.  I can trivially 
> compute Y = hash(X) and then reveal that X is the preimage of Y.  It 
> would be nice for people to be able to demonstrate preimage type attacks 
> (perhaps on reduced-round versions of the hash function) in a way that's 
> pretty clearly not cooked.  (Note that second preimage attacks yield 
> collisions, and in most cases, you would also expect preimage attacks to 
> yield collisions.  But this is a more impressive result, so if you want 
> to demonstrate your best result on some reduced-round hash function, 
> it's nice to be able to show that you really have managed to carry out 
> the computation.)
> 
> Here's an approach that might work to demonstrate a preimage attack:
> 
> a.  If you have a preimage attack that works for all images (for any Y 
> you give me, I can produce an X such that hash(X) = Y), then some 
> natural targets include the stated IV of the hash function (assuming it 
> has one), the all-zero hash output, and the all-one hash output.  Any of 
> those demonstrates that you have a preimage attack that works for nearly 
> all images.
> 
> b.  If you have a preimage attack that works for a reasonable subset of 
> images chosen at random, then we can define a natural set of targets:
> 
> (i)  Let string(j) = the 64-bit hex representation of unsigned 64-bit 
> integer j, with leading zeros so that it's always 16 bytes long, in ASCII.
> 
> (ii) Let "0"||string(j) = the 64-bit hex representation as above, with 
> one more leading zero
> 
> (iii)Let target[j] = hash(string(j)) XOR hash("0"||string(j))
> 
> This is probably a bit cumbersome, but it gives an attacker a mechanism 
> for generating up to 2^{64} targets for a preimage attack, with targets 
> for which nobody should know a preimage.  If you have an attack with 
> which you can find a preimage on K rounds of some hash function, you can 
> demonstrate it with one of these 2^{64} targets.  The expected 
> difficulty of finding such a preimage on a 256-bit hash ought to be 
> about 2^{192} computations, so there's no concern about anyone finding 
> one of these by brute force.
> 
> This can also be used to demonstrate pseudopreimages (given Y, find H,M 
> such that Compress(H,M) = Y) in Damgaard-Merkle and related hash 
> function constructions.
> 
> Second preimage attacks require target messages.  If you want to 
> demonstrate a second preimage attack, I propose using the above sequence 
> of target hashes (defined for the hash function in question) as a source 
> of random target messages.  If you can find a second preimage of any 
> sequence of hash outputs that appears in that 2^{64} sequence and 
> publish it, I think that demonstrates that you have an attack that works 
> on randomly chosen target messages.  I'm not sure what to propose for an 
> attack that is supposed to work only on some special subset of target 
> messages, such as ASCII text or very low-Hamming-weight strings, but 
> maybe this won't be all that common a problem.  (You have a huge set of 
> possible messages, but the possible brute-force attacks are far too 
> expensive for anyone to carry out for this competition.)
> 
> Comments?  Does this seem sensible?  Is there some better way to come up 
> with these target images and target messages for demonstrating 
> preimage/second preimage attacks?
> 
> --John Kelsey, NIST
> 
> 
> 
> 

-- 
     Ronald L. Rivest
     Room 32-G692, Stata Center, MIT, Cambridge MA 02139
     Tel 617-253-5880, Email 

From hash-forum@nist.gov  Wed Dec 17 01:35:27 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBH9ZK1G030259
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Dec 2008 01:35:21 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBH9Yqkp026572;
	Wed, 17 Dec 2008 04:34:53 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBH9Yb1D004698;
	Wed, 17 Dec 2008 04:34:37 -0500
Date: Wed, 17 Dec 2008 04:34:37 -0500
Message-Id: <4948C4F1.5090407@iaik.tugraz.at>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: Christian Rechberger 
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
In-Reply-To: <20081217075847.40461.qmail@cr.yp.to>
References: <20081217075847.40461.qmail@cr.yp.to>
MIME-Version: 1.0
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 17 Dec 2008 01:35:22 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 401


D. J. Bernstein wrote:
> John Kelsey writes:
>> If the response to an attack is always "I can add some rounds to make
>> it secure," then no algorithms will ever be removed from the
>> competition by cryptanalysis.
> 
> Let's think about this for a minute.
[snip]

> What I'm advocating for SHA-3 is that we sort submissions according to
> the efficiency of their fastest unbroken variants (which are what
> cryptanalysts want to look at anyway), and then concentrate on the most
> efficient submissions---let's say within a factor of 2 of the current
> leader. The effort will be spread somewhat by differing notions of
> "efficiency" but will still be much more focused than the cryptanalysis
> of AES candidates.
> 
> A new attack that breaks more rounds of a hash function will naturally
> bump that hash function down the list, maybe out of the factor-of-2
> bracket. Of course, if a non-tunable hash function is broken, or if the
> maximum number of rounds of a tunable hash function is broken, then the
> hash function is bumped completely off the list. This already seems to
> have happened to quite a few of the SHA-3 submissions.

Hi Dan,
I like the idea of simplifying choices for cryptanalytic targets.
However, you advocate a quite simple view on the nature of the 
speed/security/confidence part of the SHA-3 competition. This is not 
only because some proposals have tweakable security parameters that 
behave differently to a round number, and some have more than one of 
these parameters.

At least two issues seem to speak against this view:

1)
Cryptanalysts will not only look at the hash function as a whole, but 
are likely to consider simpler building blocks like compression 
functions, or permutations (as this can greatly simplify analysis).

How to rank and compare known-key distinguisher, related-key-boomerang 
attacks on some underlying block cipher, nonrandom properties of 
underlying permutations, or various forms of (pseudo)/(near)/collisions 
and (2nd)-preimage attacks on some compression functions to results 
obtained on the actual hash function? All on variants reduced to a 
different number of rounds to make it interesting.

It happened already on this list: A practical collision attack on a 
proposal for a particular number of rounds was directly compared to some 
related-key attack on some block cipher for a particular number of 
rounds (that is used as a building block for a compression function, 
which in turn is used for another proposal).

This kind of view tends to favor constructions without explicit 
lower-level building blocks that can and will be analyzed. How to take 
this into account in such a simple ranking?

2)
Some proposals have very useful bounds on properties like differential 
and linear probabilities that give rise to concrete recommendations for 
tweakable security parameters that rule our classes of attacks. These 
bounds are certainly not the end of the story for other classes of 
attacks, but they establish some level of confidence.

Many of the others proposals don't have such a property, i.e. for those 
there is no way to rule out classes of attacks that have been 
successfully applied to hash functions in the past. This may hence make 
it harder to get confidence in.
Note that SHA-2 is one of these, and the missing long-term confidence in 
it (despite several years of cryptanalysis resulting in practical 
collision attacks on only 24 out of their 64/80 rounds) is part of the 
reason for the SHA-3 competition in the first place.


To sum up: a simple ranking according to fastest unbroken rounds can be 
misleading. Rankings will have their use, but their limitations should 
be clear. I second NIST's view and approach expressed on this list which 
tries to take into account the more complex nature of this competition.


Cheers,
  Christian

-- 
Christian Rechberger 
Krypto Group - IAIK - TU Graz, Inffeldgasse 16a, A-8010 Graz, Austria
http://www.iaik.tugraz.at/content/research/krypto/
phone: +43 (0)316 873 5534  ---  fax: +43 (0)316 873 5594


From hash-forum@nist.gov  Wed Dec 17 02:29:40 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBHATZ77001790
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Dec 2008 02:29:36 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBHASx9V019160;
	Wed, 17 Dec 2008 05:29:01 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBHASq0A011920;
	Wed, 17 Dec 2008 05:28:52 -0500
Date: Wed, 17 Dec 2008 05:28:52 -0500
Message-Id: <0F627D67EE858D44BD1CEFEA67183F1807328D46@CNSCNEVS03.ap.sony.com>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "Li, Ji" 
To: Multiple recipients of list 
Subject: Re: Collision attack on NaSHA-512
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-To: 
References: <0F627D67EE858D44BD1CEFEA67183F180717BDBD@CNSCNEVS03.ap.sony.com> <0F627D67EE858D44BD1CEFEA67183F18072CE931@CNSCNEVS03.ap.sony.com>
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C96030.93A62CA6"
MIME-Version: 1.0
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 17 Dec 2008 02:29:36 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-5.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 402


This is a multi-part message in MIME format.

------_=_NextPart_001_01C96030.93A62CA6
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

=20

         The details about collision attack on NaSHA-512:

 http://eprint.iacr.org/2008/519

=20

Best Regards,

Li Ji, Xu Liangyu and Guan Xu

=20

Security Technology Research Department

Sony China Research Laboratory,  Sony (China) Limited


------_=_NextPart_001_01C96030.93A62CA6
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable





















------_=_NextPart_001_01C96030.93A62CA6--

From hash-forum@nist.gov  Wed Dec 17 03:10:02 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBHB9ucl005183
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Dec 2008 03:09:57 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBHB8Y5H019042;
	Wed, 17 Dec 2008 06:08:35 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBHB8IuI022896;
	Wed, 17 Dec 2008 06:08:18 -0500
Date: Wed, 17 Dec 2008 06:08:18 -0500
Message-Id: <72CF8F2B2766084DBD7AEAFCAE4A3B790969D755@frsnprexc1.usr.ingenico.loc>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "Thomas PEYRIN" 
To: Multiple recipients of list 
Subject: RE: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Transfer-Encoding: 8bit
X-To: 
References: <20081217075847.40461.qmail@cr.yp.to>
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 17 Dec 2008 03:09:57 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 403


Tunable parameters seem a hot topic! The problem here is that we have two different groups (the ones that thought we can tune the parameters and the ones that gave precise parameter sets) and depending on the NIST choice, one group might see the decision as unfair. This situation arises because some points are left blurry (intentionally or not), and I would say that only clear and precise "rules" can lead to a good result.

Personally, I think the parameter sets given by the designers are really important, and I tend to agree with John. Comparing the fastest unbroken schemes seems dangerous to me, and there are some issues:

1) What does "broken" mean? Collision attacks? Preimage attacks? Non-random properties? Since it is hard for the competition participants to agree on the possibility of changing the parameters, I can imagine the situation when we will be discussing about attacks! Clearly, this will result to schemes with only the minimum security requirements. Keeping the possibility of changing the scheme puts the competition is the "blurry" state I think we should avoid. That leads to my second point:

2) The security requirements from the NIST are indeed blurry: multicollision resistant, etc. Obviously, if I can tune the parameters, I will not care at all about this kind of vulnerabilities. I'll just take the weakest possible and unbroken variant. The problem here is that *we don't give any credit to the design philosophy*. We (the designers of Echo) chose to build a multicollision resistant hash function because we felt it is a desirable property. The price to pay is obviously a double internal state. However, this can't be changed anymore by just playing with the number of rounds. If we only care about the fastest unbroken variant, we might have considered setting the internal state size as a parameter as well. Thus, I think that for some proposals changing the number of rounds make little sense. Asking for a generic building block that can be easily tuned (and used as hash proposal) is really different from asking for a complete hash function.

3) Some patches are more than just an increase of the number of rounds. Yet, some parameters might change the state size, the number of message inserted, etc. Patching a scheme after an attack is a little bit like running away from the attacker. But do the designers fully know where they are going when patching? When several different patches are possible to avoid the attack, why choosing one and not the others? In the end of the process, the scheme might look quite different from what the designers expected in the beginning.

4) The more your scheme is analysed, the more precise will be the number of round for the scheme to be secure. Thus, if a lot of people analyzed your scheme, you have less chance to be selected (because maybe some other non popular proposals will keep their claims of a very low number of rounds). This is less true if the designers fixed a precise parameter set, because more analysis just shows that you had a good opinion about your function limits and therefore gives more credit to your proposal (unless your scheme is broken of course).


Thomas.



-----Message d'origine-----
De : hash-forum@nist.gov [mailto:hash-forum@nist.gov] De la part de D. J. Bernstein
Envoyé : mercredi 17 décembre 2008 08:58
À : Multiple recipients of list
Objet : Re: Engineering comparison of the SHA-3 candidates


John Kelsey writes:
> If the response to an attack is always "I can add some rounds to make
> it secure," then no algorithms will ever be removed from the
> competition by cryptanalysis.

Let's think about this for a minute.

There were fifteen AES competitors. Five of them were broken, but five
more were removed in the first round without being broken, and none of
the remaining five were broken. Almost all of the cryptanalysis was on
reduced-round versions. Of course, the occasional complete breaks did
allow cryptanalysts to stop looking at some ciphers, but most ciphers
survived, and cryptanalytic effort was spread haphazardly among all of
the ciphers---including ciphers that, in retrospect, were clearly too
slow to be of interest. This was essentially your nightmare scenario!

I predict that the number of unbroken SHA-3 submissions will be much
larger than the number of unbroken AES submissions. Yes, quite a few of
the 51 submissions will be broken, but you're kidding yourself if you
think that algorithms "removed from the competition by cryptanalysis"
will be enough to seriously focus the remaining cryptanalytic effort.

What I'm advocating for SHA-3 is that we sort submissions according to
the efficiency of their fastest unbroken variants (which are what
cryptanalysts want to look at anyway), and then concentrate on the most
efficient submissions---let's say within a factor of 2 of the current
leader. The effort will be spread somewhat by differing notions of
"efficiency" but will still be much more focused than the cryptanalysis
of AES candidates.

A new attack that breaks more rounds of a hash function will naturally
bump that hash function down the list, maybe out of the factor-of-2
bracket. Of course, if a non-tunable hash function is broken, or if the
maximum number of rounds of a tunable hash function is broken, then the
hash function is bumped completely off the list. This already seems to
have happened to quite a few of the SHA-3 submissions.

The list of most efficient submissions will, I expect, stabilize quite
soon. Cryptanalysis will continue to have an effect but the effect will
become less and less noticeable. We'll be confident that the long-term
leaders, the survivors of focused cryptanalysis, achieve security more
efficiently than any of the other functions. (I'm not saying that this
will necessarily predict the SHA-3 winner. For example, FSB claims a
fundamental security advantage from being provably as secure as
well-known problems; maybe this will trump performance considerations.)

This sorting has a critical advantage over the sorting advocated by the
Skein team: namely, I'm systematically talking about the _smallest_
unbroken number of rounds, while the Skein team focuses on the _full_
number of rounds. Serious cryptanalysis usually changes the smallest
unbroken number of rounds but almost never breaks the full number of
rounds. This means that the Skein team's table will be quite static,
will be almost completely useless in tracking cryptanalytic progress,
will be completely useless in evaluating security margins, and won't
give us even the slightest idea which hash-function submission achieves
security at the highest speed.

> As an attacker, I like having a meaningful target.  It's sort-of
> disspiriting to be attacking a cipher with 32 rounds, and the best
> attack you've got can get through 10.  If the target were 12 or 14
> rounds, I might keep digging till I got through the extra rounds.

An explicit list of fastest unbroken variants rewards cryptanalysts for
making changes in the list. MD6 is quite conservative, I agree, but the
_fastest unbroken variant of MD6_ is a nearby target begging for
cryptanalysis. Analogy: modern papers on AES cryptanalysis advertise
their effect on reduced-round AES; the authors don't seem to be
discouraged by how far they are from full AES.

> For cryptanalysts, I think a couple performance points might be
> interesting to look at, outside of the stated parameters from the
> designer:
> a.  Approximately equal performance to SHA256 on the reference platform.
> b.  Approximately equal performance to some of the fastest of the
> currently-unbroken designs on the reference platform.

These are interesting targets to shoot for, certainly, but overall
you're setting the bar too high. AES analogy: the leading cryptanalytic
results against Serpent were against reduced-round versions considerably
faster than Rijndael; asking cryptanalysts to break a reduced-round
version of Serpent having "approximately equal performance" to Rijndael
would have been asking too much.

> You can see the recommended tunable parameters as encoding two pieces
> of information:
> a.  The designer's understanding of the security of his own algorithm
> b.  The designer's preferred tradeoff between security and performance

John, how exactly do you expect a single tunable parameter, such as the
MD6-512 round count, to communicate two separate quantitative pieces of
information?

The call for submissions said that the tunable parameter allows "the
selection of a range of possible security/performance tradeoffs" and
that the submission document had to specify "a recommended value" for   
this parameter. The recommendation of 168 rounds for MD6-512 is Rivest's
recommended tradeoff between security and performance.

I don't see how you get the idea that this 168-round figure encodes
Rivest's "understanding of the security of his own algorithm." There   
are certainly some security analyses in the MD6 documentation, but if
you simply look at the 168 then you can't tell whether the limit of the
MD6 attacks is 5 rounds, or 18 rounds, or 167 rounds.

Stefan similarly claims, without any justification, that Rivest doesn't
have "confidence" in reduced-round variants of MD6. Stefan says that   
choosing reduced-round variants of MD6---an option clearly allowed in 
the SHA-3 Federal Register Notice---would "undermine the credibility of
SHA-3." I find this to be completely ridiculous.

---D. J. Bernstein
   Research Professor, Computer Science, University of Illinois at Chicago


 
About Ingenico: Ingenico is the world’s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams.
 This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
 P Please consider the environment before printing this e-mail
 
 


From hash-forum@nist.gov  Wed Dec 17 03:22:54 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBHBMmPf006152
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Dec 2008 03:22:49 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBHBMLOh026053;
	Wed, 17 Dec 2008 06:22:22 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBHBMCUM016201;
	Wed, 17 Dec 2008 06:22:12 -0500
Date: Wed, 17 Dec 2008 06:22:12 -0500
Message-Id: 
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: Jonathan Katz 
To: Multiple recipients of list 
Subject: Re: Demonstrating attacks
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
MIME-Version: 1.0
References: <20081216235332.565109yp044r3kjw@webmail.nist.gov>
In-Reply-To: <20081216235332.565109yp044r3kjw@webmail.nist.gov>
X-To: Multiple recipients of list 
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 17 Dec 2008 03:22:49 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 404


If someone has a "real" attack (i.e., one that runs in realistic time + 
memory, as in the case of attacks finding explicit collisions), why could 
they not just code up their attack so that anyone can run it on any inputs 
of their choice?

On Wed, 17 Dec 2008, John Kelsey wrote:

>
> Several people have demonstrated attacks on submitted hash functions.  If you 
> want to demonstrate a collision, pseudocollision, or near-collision (or 
> near-pseudocollision) attack, you can do that pretty trivially.  You just 
> produce the pair of inputs that collides or almost collides.
>
> However, demonstrating preimage, pseudopreimage, second-preimage, or 
> near-preimage attacks is a bit less straightforward.  I can trivially compute 
> Y = hash(X) and then reveal that X is the preimage of Y.  It would be nice 
> for people to be able to demonstrate preimage type attacks (perhaps on 
> reduced-round versions of the hash function) in a way that's pretty clearly 
> not cooked.  (Note that second preimage attacks yield collisions, and in most 
> cases, you would also expect preimage attacks to yield collisions.  But this 
> is a more impressive result, so if you want to demonstrate your best result 
> on some reduced-round hash function, it's nice to be able to show that you 
> really have managed to carry out the computation.)
>
> Here's an approach that might work to demonstrate a preimage attack:
>
> a.  If you have a preimage attack that works for all images (for any Y you 
> give me, I can produce an X such that hash(X) = Y), then some natural targets 
> include the stated IV of the hash function (assuming it has one), the 
> all-zero hash output, and the all-one hash output.  Any of those demonstrates 
> that you have a preimage attack that works for nearly all images.
>
> b.  If you have a preimage attack that works for a reasonable subset of 
> images chosen at random, then we can define a natural set of targets:
>
> (i)  Let string(j) = the 64-bit hex representation of unsigned 64-bit integer 
> j, with leading zeros so that it's always 16 bytes long, in ASCII.
>
> (ii) Let "0"||string(j) = the 64-bit hex representation as above, with one 
> more leading zero
>
> (iii)Let target[j] = hash(string(j)) XOR hash("0"||string(j))
>
> This is probably a bit cumbersome, but it gives an attacker a mechanism for 
> generating up to 2^{64} targets for a preimage attack, with targets for which 
> nobody should know a preimage.  If you have an attack with which you can find 
> a preimage on K rounds of some hash function, you can demonstrate it with one 
> of these 2^{64} targets.  The expected difficulty of finding such a preimage 
> on a 256-bit hash ought to be about 2^{192} computations, so there's no 
> concern about anyone finding one of these by brute force.
>
> This can also be used to demonstrate pseudopreimages (given Y, find H,M such 
> that Compress(H,M) = Y) in Damgaard-Merkle and related hash function 
> constructions.
>
> Second preimage attacks require target messages.  If you want to demonstrate 
> a second preimage attack, I propose using the above sequence of target hashes 
> (defined for the hash function in question) as a source of random target 
> messages.  If you can find a second preimage of any sequence of hash outputs 
> that appears in that 2^{64} sequence and publish it, I think that 
> demonstrates that you have an attack that works on randomly chosen target 
> messages.  I'm not sure what to propose for an attack that is supposed to 
> work only on some special subset of target messages, such as ASCII text or 
> very low-Hamming-weight strings, but maybe this won't be all that common a 
> problem.  (You have a huge set of possible messages, but the possible 
> brute-force attacks are far too expensive for anyone to carry out for this 
> competition.)
>
> Comments?  Does this seem sensible?  Is there some better way to come up with 
> these target images and target messages for demonstrating preimage/second 
> preimage attacks?
>
> --John Kelsey, NIST
>

From hash-forum@nist.gov  Tue Dec 16 21:03:28 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBH53Mrv004015
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Tue, 16 Dec 2008 21:03:24 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBH52qfh029478;
	Wed, 17 Dec 2008 00:02:54 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBH52d9h001496;
	Wed, 17 Dec 2008 00:02:39 -0500
Date: Wed, 17 Dec 2008 00:02:39 -0500
Message-Id: <20081216235332.565109yp044r3kjw@webmail.nist.gov>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "John Kelsey" 
To: Multiple recipients of list 
Subject: Demonstrating attacks
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed"
MIME-Version: 1.0
X-To: "Multiple recipients of list" 
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 16 Dec 2008 21:03:24 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords:                 
X-UID: 405


Several people have demonstrated attacks on submitted hash functions.   
If you want to demonstrate a collision, pseudocollision, or  
near-collision (or near-pseudocollision) attack, you can do that  
pretty trivially.  You just produce the pair of inputs that collides  
or almost collides.

However, demonstrating preimage, pseudopreimage, second-preimage, or  
near-preimage attacks is a bit less straightforward.  I can trivially  
compute Y = hash(X) and then reveal that X is the preimage of Y.  It  
would be nice for people to be able to demonstrate preimage type  
attacks (perhaps on reduced-round versions of the hash function) in a  
way that's pretty clearly not cooked.  (Note that second preimage  
attacks yield collisions, and in most cases, you would also expect  
preimage attacks to yield collisions.  But this is a more impressive  
result, so if you want to demonstrate your best result on some  
reduced-round hash function, it's nice to be able to show that you  
really have managed to carry out the computation.)

Here's an approach that might work to demonstrate a preimage attack:

a.  If you have a preimage attack that works for all images (for any Y  
you give me, I can produce an X such that hash(X) = Y), then some  
natural targets include the stated IV of the hash function (assuming  
it has one), the all-zero hash output, and the all-one hash output.   
Any of those demonstrates that you have a preimage attack that works  
for nearly all images.

b.  If you have a preimage attack that works for a reasonable subset  
of images chosen at random, then we can define a natural set of targets:

(i)  Let string(j) = the 64-bit hex representation of unsigned 64-bit  
integer j, with leading zeros so that it's always 16 bytes long, in  
ASCII.

(ii) Let "0"||string(j) = the 64-bit hex representation as above, with  
one more leading zero

(iii)Let target[j] = hash(string(j)) XOR hash("0"||string(j))

This is probably a bit cumbersome, but it gives an attacker a  
mechanism for generating up to 2^{64} targets for a preimage attack,  
with targets for which nobody should know a preimage.  If you have an  
attack with which you can find a preimage on K rounds of some hash  
function, you can demonstrate it with one of these 2^{64} targets.   
The expected difficulty of finding such a preimage on a 256-bit hash  
ought to be about 2^{192} computations, so there's no concern about  
anyone finding one of these by brute force.

This can also be used to demonstrate pseudopreimages (given Y, find  
H,M such that Compress(H,M) = Y) in Damgaard-Merkle and related hash  
function constructions.

Second preimage attacks require target messages.  If you want to  
demonstrate a second preimage attack, I propose using the above  
sequence of target hashes (defined for the hash function in question)  
as a source of random target messages.  If you can find a second  
preimage of any sequence of hash outputs that appears in that 2^{64}  
sequence and publish it, I think that demonstrates that you have an  
attack that works on randomly chosen target messages.  I'm not sure  
what to propose for an attack that is supposed to work only on some  
special subset of target messages, such as ASCII text or very  
low-Hamming-weight strings, but maybe this won't be all that common a  
problem.  (You have a huge set of possible messages, but the possible  
brute-force attacks are far too expensive for anyone to carry out for  
this competition.)

Comments?  Does this seem sensible?  Is there some better way to come  
up with these target images and target messages for demonstrating  
preimage/second preimage attacks?

--John Kelsey, NIST


From hash-forum@nist.gov  Wed Dec 17 03:50:45 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBHBoc13008119
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Dec 2008 03:50:39 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBHBnqtl008528;
	Wed, 17 Dec 2008 06:49:52 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBHBnb7v004687;
	Wed, 17 Dec 2008 06:49:37 -0500
Date: Wed, 17 Dec 2008 06:49:37 -0500
Message-Id: <72CF8F2B2766084DBD7AEAFCAE4A3B790969D7DE@frsnprexc1.usr.ingenico.loc>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "Thomas PEYRIN" 
To: Multiple recipients of list 
Subject: Slide attacks on LUX
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-To: 
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9603C.F8D91036"
MIME-Version: 1.0
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 17 Dec 2008 03:50:40 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_MED,URIBL_GREY shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 406


This is a multi-part message in MIME format.

------_=_NextPart_001_01C9603C.F8D91036
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi all,

=20

Here is a remark on the 256-bit version of LUX when a salt is used: by
using slide attacks on hash functions (the general idea of the attack
can be found here:
http://thomas.peyrin.googlepages.com/Gorski-Lucks-Peyrin-Asiacrypt2008.p
df ), one can, without any computation (except for actually computing
the outputs):

=20

1) differentiate the hash function from a random oracle

2) generate two strongly related outputs

=20

This only works when the salt size is equal to 31 modulo 32. Thus, I
fully agree that this observation is not really useful in practice, and
I leave it up to you to judge if this is a real vulnerability. Note that
the LUX designers already validated this analysis.

=20

=20

For the interested readers, it works as follows:

=20

In LUX, two padding are used: the "10" padding and the length padding.
In the case of 256-bit output, the length padding will fit in two
message blocs and I denote them L1 and L2. Thus the padded message is=20

=20

M || 1 ...0 || L1 || L2 .

=20

For now, we assume there is no "10" padding (we assume that the message
length is always a multiple of the message block length). I will choose
two messages M and M':=20

=20

 1st message with padding: M || L1 || L2

2nd message with padding: M' || L1' || L2'

=20

I'll force the condition that M' =3D M || L1. Note that M' is one =
message
block bigger, so L1' || L2' =3D (L1 || L2) + 32 (4 times 8 bits per
message block). Then, we have=20

=20

1st message with padding: M || L1 || L2

2nd message with padding: M || L1 || L1' || L2'=20

=20

Now, we add two more conditions: L2' =3D 0 and L2 =3D L1'.  This is =
possible
in the following case:

=20

L1 =3D 11111111 11111111 11111111 11011111

L2 =3D 11111111 11111111 11111111 11100000

=20

L1'=3D 11111111 11111111 11111111 11100000

L2'=3D 00000000 00000000 00000000 00000000

=20

Finally, we have:=20

=20

1st message with padding: M || L1 || L2

2nd message with padding: M || L1 || L2 || 0=20

=20

One can see that exactly the same message blocks will be treated, except
that for the second message M' we have a "0" message block to add. This
has the effect that the "0" block will behave as a blank round (in which
no message is incorporated) and (M,M') is a slid pair of message : their
respective outputs are just one blank round away. That is, if the output
for M is (H0,H1,H2,H3,H4,H5,H6,H7), then the output for M' will be
(H1,H2,H3,H4,H5,H6,H7,R)  where R is some random 32-bit value.=20

=20

To conclude, with no computation cost, one can differentiate the hash
function from a random oracle or generate strongly correlated output
pairs. Now, if I want to reintroduce the "01" padding and keep the
attack working, I can use the salt: if the length of the salt is equal
to 31 modulo 32, then I can adapt the attack to take care of the "10"
padding. Note that the length padding only codes the real message length
and don't consider the salt length.=20

=20

=20

Let's say that we have a salt S of size 31 bit and two messages M and M'
of size 0 modulo 32, such that (as before):

=20

L1 =3D 11111111 11111111 11111111 11011111

L2 =3D 11111111 11111111 11111111 11100000

=20

L1'=3D 11111111 11111111 11111111 11100000

L2'=3D 00000000 00000000 00000000 00000000

=20

We indeed have L2 and L2' =3D 0 modulo 32.

=20

1st message with padding:  S || M || "10" padding || L1 || L2=20

2nd message with padding: S || M' || "10" padding || L1' || L2'=20

=20

The 10 padding will be just a 1 for both messages (because of the 31-bit
salt), thus we have=20

=20

1st message with padding:  S || M || 1 || L1 || L2=20

2nd message with padding: S || M' || 1 || L1' || L2'=20

=20

Now we say that M'=3D M || 1 || 11111111 11111111 11111111 1101111
(that is M, the "1" bit from the "10" padding, and the length L1 without
the very last bit). Thus, when M' will be "01" padded, we get=20

=20

M' || "01" padding =3D M || 1 || 11111111 11111111 11111111 1101111 || 1 =
=3D
M || 1 || L1

=20

Now, the reasoning is the same as before:

=20

1st message with padding: S || M || 1 || L1 || L2

2nd message with padding: S || M || 1 || L1 || L1' || L2'

=20

And since L2 =3D L1' and L2' =3D 0, we finally have=20

=20

1st message with padding: S || M || 1 || L1 || L2

2nd message with padding: S || M || 1 || L1 || L2 || 0=20

=20

And the slide attack applies.

=20

Cheers,

=20

Thomas.

=20

=20


=20
About Ingenico: Ingenico is the world=E2=80=99s leading provider of =
payment solutions, with over 15 million terminals deployed across the =
globe. Delivering the very latest secure electronic payment =
technologies, transaction management and the widest range of value added =
services, Ingenico is shaping the future direction of the payment =
solutions market. Leveraging on its global presence and local expertise, =
Ingenico is reinforcing its leadership by taking banks and businesses =
beyond payment through offering comprehensive solutions, a true source =
of differentiation and new revenues streams.
 This message may contain confidential and/or privileged information. If =
you are not the addressee or authorized to receive this for the =
addressee, you must not use, copy, disclose or take any action based on =
this message or any information herein. If you have received this =
message in error, please advise the sender immediately by reply e-mail =
and delete this message. Thank you for your cooperation.
 P Please consider the environment before printing this e-mail
=20
=20

------_=_NextPart_001_01C9603C.F8D91036
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable







Notice








Hi all,



 



Here is a remark on the 256-bit version of LUX =
when a
salt is used: by using slide attacks on hash functions (the general idea =
of the
attack can be found here: http://thomas.peyrin.googlepages.com/Gorski-Lucks-Pe=
yrin-Asiacrypt2008.pdf
), one can, without any computation (except for actually computing the =
outputs):



 



1) differentiate the hash function from a =
random
oracle



2) generate two strongly related =
outputs



 



This only works =
when the salt size is
equal to 31 modulo 32. Thus, I =
fully agree
that this observation is not really useful in practice, and I leave it =
up to
you to judge if this is a real vulnerability. Note that the LUX =
designers
already validated this analysis.



 



 



For the interested readers, it =
works as follows:



 



In LUX, two padding are used: the =
“10”
padding and the length padding. In the case of 256-bit output, the =
length
padding will fit in two message blocs and I denote them L1 and L2. Thus =
the
padded message is 



 



M || 1 …0 || L1 || L2 =




 



For now, we assume there is no =
“10”
padding (we assume that the message length is always a multiple of the =
message
block length). I will choose two messages M and M’: =




 



 1st message with padding: M || L1 || =
L2



2nd message with padding: M’ || =
L1’ || L2’



 



I’ll force the condition that M’ =
=3D M ||
L1. Note that M’ is one message block bigger, so L1’ || =
L2’ =3D
(L1 || L2) + 32 (4 times 8 bits per message block). Then, we have =




 



1st message with padding: M || L1 || =
L2



2nd message with padding: M || L1 || L1’ =
||
L2’ 



 



Now, we add two more conditions: L2’ =3D =
0 and L2
=3D L1’.  This is possible in the following =
case:



 



L1 =3D 11111111 11111111 11111111 =
11011111



L2 =3D 11111111 11111111 11111111 =
11100000



 



L1’=3D 11111111 11111111 11111111 =
11100000



L2’=3D 00000000 00000000 00000000 =
00000000



 



Finally, we have: 



 



1st message with padding: M || L1 || =
L2



2nd message with padding: M || L1 || L2 || 0 =




 



One can see that exactly the same message =
blocks will
be treated, except that for the second message M’ we have a
“0” message block to add. This has the effect that the
“0” block will behave as a blank round (in which no message =
is
incorporated) and (M,M’) is a slid pair of message : their =
respective
outputs are just one blank round away. That is, if the output for M is
(H0,H1,H2,H3,H4,H5,H6,H7), then the output for M’ will be
(H1,H2,H3,H4,H5,H6,H7,R)  where R is some random 32-bit value. =




 



To conclude, with no computation cost, one can =
differentiate
the hash function from a random oracle or generate strongly correlated =
output
pairs. Now, if I want to reintroduce the “01” padding and =
keep the
attack working, I can use the salt: if the length of the salt is equal =
to 31
modulo 32, then I can adapt the attack to take care of the =
“10”
padding. Note that the length padding only codes the real message length =
and don’t
consider the salt length. 



 



 



Let’s say that we have a salt S of size =
31 bit
and two messages M and M’ of size 0 modulo 32, such that (as =
before):



 



L1 =3D 11111111 11111111 11111111 =
11011111



L2 =3D 11111111 11111111 11111111 =
11100000



 



L1’=3D 11111111 11111111 11111111 =
11100000



L2’=3D 00000000 00000000 00000000 =
00000000



 



We indeed have L2 and L2’ =3D 0 modulo =
32.



 



1st message with padding:  S || M ||
“10” padding || L1 || L2 



2nd message with padding: S || M’ || =
“10”
padding || L1’ || L2’ 



 



The 10 padding will be just a 1 for both =
messages
(because of the 31-bit salt), thus we have 



 



1st message with padding:  S || M || 1 || =
L1 ||
L2 



2nd message with padding: S || M’ || 1 =
||
L1’ || L2’ 



 



Now we say that M’=3D M || =
1 || 11111111
11111111 11111111 1101111    (that is M, the =
“1” bit
from the “10” padding, and the length L1 without the very =
last
bit). Thus, when M’ will be “01” padded, we get =




 



M’ || “01” =
padding =3D M || 1 || 11111111
11111111 11111111 1101111 || 1 =3D M || =
1 || L1



 



Now, the reasoning is the same =
as before:



 



1st message with padding: S || M || 1 || L1 || =
L2



2nd message with padding: S || M || 1 || L1 ||
L1’ || L2’



 



And since L2 =3D L1’ and L2’ =3D =
0, we finally
have 



 



1st message with padding: S || M || 1 || L1 || =
L2



2nd message with padding: S || M || 1 || L1 || =
L2 ||
0 



 



And the slide attack =
applies.



 



Cheers,



 



Thomas.



 



 








 




About =
Ingenico: Ingenico is the world=E2=80=99s =
leading provider of payment solutions, with over 15 million terminals =
deployed across the globe. Delivering =
the very latest secure electronic payment technologies, transaction =
management and the widest range of value added services, Ingenico is =
shaping the future direction of the payment solutions market. Leveraging =
on its global presence and local expertise, Ingenico is reinforcing its =
leadership by taking banks and businesses beyond payment through =
offering comprehensive solutions, a true source of differentiation and =
new revenues streams.


 This message may contain =
confidential and/or privileged information. If you are not the addressee =
or authorized to receive this for the addressee, you must not use, copy, =
disclose or take any action based on this message or any information =
herein. If you have received this message in error, please advise the =
sender immediately by reply e-mail and delete this message. Thank you =
for your cooperation.


 P Please consider the environment before printing =
this e-mail


 




 


------_=_NextPart_001_01C9603C.F8D91036--

From hash-forum@nist.gov  Wed Dec 17 04:31:56 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBHCVpb7015471
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Dec 2008 04:31:52 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBHCVC9u011791;
	Wed, 17 Dec 2008 07:31:13 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBHCV5xT020658;
	Wed, 17 Dec 2008 07:31:05 -0500
Date: Wed, 17 Dec 2008 07:31:05 -0500
Message-Id: 
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: Stefan.Lucks@uni-weimar.de
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: TEXT/PLAIN; charset=US-ASCII
MIME-Version: 1.0
References: <20081217075847.40461.qmail@cr.yp.to>
In-Reply-To: <20081217075847.40461.qmail@cr.yp.to>
X-To: Multiple recipients of list 
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 17 Dec 2008 04:31:52 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 407


On Wed, 17 Dec 2008, D. J. Bernstein wrote:

> This sorting has a critical advantage over the sorting advocated by the
> Skein team: namely, I'm systematically talking about the _smallest_
> unbroken number of rounds, while the Skein team focuses on the _full_
> number of rounds.

What really counts is the performace of a hash function if it becomes 
SHA-3. Then, the number of rounds (or rather, the values for all tunable 
security parameters) ought to be large enough to gain confidence that even 
further improvements of cryptanalysis will not break SHA-3. I anticipate 
that this will not be the "_smallest_ unbroken number of rounds".

Actually, the main issue is "confidence". 

It is not determined just by the smallest unbroken number of rounds, 
perhaps multiplied by some deliberate security margin. It is also 
determined by 
  - design philosophy,
  - structural properties,
  - provable security results,
  - provable resistance to certain cryptanalytic techniques, 
  - ...

I won't repeat the excellent points Christian and Thomas made in this 
thread. But an obvious consequence is that two different hash functions 
may require different security margins to gain the same level of 
confidence, if one has supplementary security properties and the other one 
doesn't. This is actually comparable to the AES process: Apart from a 
relatively small security margin, Rijndael did benefit from its 
"wide-trail" proofs of security against differential and linear 
cryptanalysis.

Your aproach to measure the efficiency of the smallest unbroken variant 
abstracts away from such security properties. It also puts all hash 
functions without tunable security parameters into an artificial 
disadvantage.

So the final SHA-3 will require some choices for the security parameter.
At the current point of time, the best (well, the only) estimate for that 
parameters are the designers' defaults.

> Stefan similarly claims, without any justification, that Rivest doesn't
> have "confidence" in reduced-round variants of MD6. 

I didn't claim that. Please try not to misrepresent my writing!

Firstly, the MD6 team isn't just "Rivest", it is a group of 15 persons.

Secondly, my claim is that the designers' choice of default values 
reflects the confidence they have into their own creation. 

This is general, not just with respect to MD6. And, what else should the 
designers' choice of default values for the security parameters indicate? 
The number of cups of coffee they drank when writing the final submission 
documents? 

Actually, MD6 has the interesting property of provable security against 
certain types of differential attacks (the authors of MD6 called them 
"standard differential attacks"). Your mileage may vary, but I consider 
this as an amazing result. The MD6 team made a good selling point here!

Performance-wise, the MD6 team pays an extremely high prize for that 
selling point, though: As I seem to understand their approach, they needed 
such many rounds because their lower bound on the differential attacker's 
workload would otherwise remain below the work for a birthday attack. 

Thus, reduced-round variants of MD6 would have to abandon the claim of 
provable security against differential attacks. (Members of the MD6 team: 
Please correct me if I misunderstood you!)

> Stefan says that choosing reduced-round variants of MD6---an option 
> clearly allowed in the SHA-3 Federal Register Notice---would "undermine 
> the credibility of SHA-3." I find this to be completely ridiculous.

Imagine that the designers of MD6 -- or of any other hash function -- 
recommend a certain number of rounds, and the final standard ignores the 
recommendation. Instead, that hash function is standardised at a reduced 
number of rounds. Wouldn't that be ridiculous?

If the designers decided to change their recommendation during the SHA-3 
process, that would be another cup of tea, of course. Also, it would not 
constitute a credibility issue, if the specified number of rounds exceeded 
the designers' own recommendation.

So long

Stefan




-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------


From hash-forum@nist.gov  Wed Dec 17 05:54:47 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBHDsgaD023380
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Dec 2008 05:54:43 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBHDsHBv028407;
	Wed, 17 Dec 2008 08:54:19 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBHDrl1I023108;
	Wed, 17 Dec 2008 08:53:47 -0500
Date: Wed, 17 Dec 2008 08:53:47 -0500
Message-Id: <494901EA.6000204@Strombergson.com>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: =?UTF-8?B?Sm9hY2hpbSBTdHLDtm1iZXJnc29u?= 
To: Multiple recipients of list 
Subject: Implementation of the Keccak hash function in FPGA devices
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
MIME-Version: 1.0
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 17 Dec 2008 05:54:43 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 408


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aloha!

I have done some experiments at implementing the two different hardware
reference implementations of the SHA-3 candidate hash function Keccak
provided by the Keccak authors.

The results and some notes from the experiment is documented in a short
article which can be found here:

http://www.strombergson.com/files/Keccak_in_FPGAs.pdf

Hopefully the results can be an addition to the ECRYPT SHA-3 Hardware
implementations page:

http://ehash.iaik.tugraz.at/wiki/SHA-3_Hardware_Implementations

One thing I started thinking about when working with the Keccak hardware
implementations is if there shouldn't be a common top level interface
(port wise) for hash candidate hardware implementations? This would make
it easier to integrate and test candidates in real hardware and to
automate building for FPGAs and ASICs (at least make it easier).

What do you think?
Any comments on the paper greatly appreciated, I'm quite new at this.

- --
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
Kryptoblog - IT-säkerhet på svenska
http://www.strombergson.com/kryptoblog
========================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklJAekACgkQZoPr8HT30QEt3ACgkQSi6f/ms1r25qcvFPeoPkem
vSEAoKnQRXM0qaRfVyVkisge5iAtVpR4
=arxm
-----END PGP SIGNATURE-----

From hash-forum@nist.gov  Wed Dec 17 06:08:54 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBHE8nne025123
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Dec 2008 06:08:50 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBHE8Ef1019164;
	Wed, 17 Dec 2008 09:08:19 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBHE7xO0020533;
	Wed, 17 Dec 2008 09:07:59 -0500
Date: Wed, 17 Dec 2008 09:07:59 -0500
Message-Id: <7.0.1.0.2.20081217085912.02420ce0@nist.gov>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: Rene Peralta 
To: Multiple recipients of list 
Subject: Re: cryptanalysis of Twister
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Mime-Version: 1.0
References: <494288D7.7060108@iaik.tugraz.at> 
In-Reply-To: 
X-Cc: rene peralta 
X-To: hash-forum@nist.gov, Multiple recipients of list 
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 17 Dec 2008 06:08:50 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 409



Hi Sean,

You and others have made this argument regarding several posted
attacks. If I understand correctly, what you are saying is that a
collision attack for which TIME*MEMORY is greater than 2^(n/2)
is worse that some well-known generic attack. A similar argument
has been made on this list regarding pre-image attacks.

Can you point me to a reference to this generic attack? Also, any
references to a rationale for use of a TIME*MEMORY metric in this
context would be greatly appreciated.

Thanks in advance, Rene.

P.S. I am aware of standard time-memory tradeoff techniques, but I
don't see the connection to the unqualified use of a TIME*MEMORY
metric.

At 12:57 PM 12/13/2008, Sean O'Neil wrote:

>On 12 Dec 2008, at 16:59, Martin Schläffer wrote:
>
>>The attack can be extended to a theoretical collision attack on the
>>hash function Twister-512 with a complexity of about 2^231.5 with
>>different time-memory tradeoffs.
>
>You mean with complexity of about 2^231.5 operations multiplied by
>2^172.7 memory? Wouldn't those 2^160 circuits find a collision in
>2^96 time for any hash? It is so tempting to omit that annoying
>memory requirement, isn't it? And then before you know it, the hash
>is declared "broken". I am not saying that the cryptanalysis itself
>is not valuable or that pseudo-collisions in 2^26.5 operations is not
>a potentially serious threat. I just find it increasingly annoying
>having to check every single paper for the fine print to see if it is
>actually cheaper than the brute-force or other generic attacks or if
>the authors "forgot" to mention memory the size of our galaxy. And a
>lot of people just read the announcement and trust the experts. They
>see 2^231.5 < 2^256, they assume that it's broken and the word
>spreads...
>
>Best regards,
>Sean O'Neil
>http://www.enrupt.com/ - Raising the bar.
>
>




From hash-forum@nist.gov  Wed Dec 17 07:05:49 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBHF5gQ2030991
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Dec 2008 07:05:43 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBHF59Qm006408;
	Wed, 17 Dec 2008 10:05:14 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBHF4mDM008365;
	Wed, 17 Dec 2008 10:04:48 -0500
Date: Wed, 17 Dec 2008 10:04:48 -0500
Message-Id: <493562.48430.qm@web36407.mail.mud.yahoo.com>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: Peter 
To: Multiple recipients of list 
Subject: Re: cryptanalysis of Twister
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: multipart/alternative; boundary="0-937216851-1229525382=:48430"
MIME-Version: 1.0
In-Reply-To: <7.0.1.0.2.20081217085912.02420ce0@nist.gov>
X-To: hash-forum@nist.gov
X-Mailer: YahooMailWebService/0.7.260.1
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 17 Dec 2008 07:05:45 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-4.3 required=5.0 tests=AWL,BAYES_00,
	FORGED_YAHOO_RCVD,HTML_MESSAGE,RCVD_IN_DNSWL_MED shortcircuit=no
	autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 410


--0-937216851-1229525382=:48430
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I believe O'Neil is referring to a "birthday attack". Correct me if I am wr=
ong, but I was under the impression that a birthday attack takes 2^n/2 time=
 at 2^0 memory, and 2^0 time at 2^n/2. I believe the trade off is 2^x time =
and 2^y memory where x+y =3D n/2.

--Peter

--- On Wed, 12/17/08, Rene Peralta  wrote:
From: Rene Peralta 
Subject: Re: cryptanalysis of Twister
To: "Multiple recipients of list" 
Date: Wednesday, December 17, 2008, 9:07 AM


Hi Sean,

You and others have made this argument regarding several posted
attacks. If I understand correctly, what you are saying is that a
collision attack for which TIME*MEMORY is greater than 2^(n/2)
is worse that some well-known generic attack. A similar argument
has been made on this list regarding pre-image attacks.

Can you point me to a reference to this generic attack? Also, any
references to a rationale for use of a TIME*MEMORY metric in this
context would be greatly appreciated.

Thanks in advance, Rene.

P.S. I am aware of standard time-memory tradeoff techniques, but I
don't see the connection to the unqualified use of a TIME*MEMORY
metric.

At 12:57 PM 12/13/2008, Sean O'Neil wrote:

>On 12 Dec 2008, at 16:59, Martin Schl=E4ffer wrote:
>
>>The attack can be extended to a theoretical collision attack on the
>>hash function Twister-512 with a complexity of about 2^231.5 with
>>different time-memory tradeoffs.
>
>You mean with complexity of about 2^231.5 operations multiplied by
>2^172.7 memory? Wouldn't those 2^160 circuits find a collision in
>2^96 time for any hash? It is so tempting to omit that annoying
>memory requirement, isn't it? And then before you know it, the hash
>is declared "broken". I am not saying that the cryptanalysis
itself
>is not valuable or that pseudo-collisions in 2^26.5 operations is not
>a potentially serious threat. I just find it increasingly annoying
>having to check every single paper for the fine print to see if it is
>actually cheaper than the brute-force or other generic attacks or if
>the authors "forgot" to mention memory the size of our galaxy.
And a
>lot of people just read the announcement and trust the experts. They
>see 2^231.5 < 2^256, they assume that it's broken and the word
>spreads...
>
>Best regards,
>Sean O'Neil
>http://www.enrupt.com/ - Raising the bar.
>
>




=0A=0A=0A      
--0-937216851-1229525382=:48430
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


=0A=0A      
--0-937216851-1229525382=:48430--

From hash-forum@nist.gov  Wed Dec 17 07:34:34 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBHFYQ0s001479
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Dec 2008 07:34:28 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBHFXoUh025622;
	Wed, 17 Dec 2008 10:33:55 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBHFXWpu003975;
	Wed, 17 Dec 2008 10:33:32 -0500
Date: Wed, 17 Dec 2008 10:33:32 -0500
Message-Id: 
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: Jonathan Katz 
To: Multiple recipients of list 
Subject: Re: cryptanalysis of Twister
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-851401618-1229527894=:7833"
MIME-Version: 1.0
References: <493562.48430.qm@web36407.mail.mud.yahoo.com>
In-Reply-To: <493562.48430.qm@web36407.mail.mud.yahoo.com>
X-To: Multiple recipients of list 
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 17 Dec 2008 07:34:28 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 411


  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---559023410-851401618-1229527894=:7833
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

The "textbook" birthday attack requires time *and* space 2^{n/2}.

There is a modified birthday attack that takes time 2^{n/2} and O(1)=20
space. I don't have the original reference (perhaps Pollard?), but it is=20
described starting on page 132 of the textbook "Introduction to Modern=20
Cryptography" by myself and Lindell.

I don't see how there can be a generic collision attack with time better=20
than 2^{n/2}. (Actually, I believe 2^{n/2} is a lower bound for finding=20
collisions in a random function.)

On Wed, 17 Dec 2008, Peter wrote:

> I believe O'Neil is referring to a "birthday attack". Correct me if I am =
wrong, but I was under the impression that a birthday attack takes 2^n/2 ti=
me at 2^0 memory, and 2^0 time at 2^n/2. I believe the trade off is 2^x tim=
e and 2^y memory where x+y =3D n/2.
>
> --Peter
>
> --- On Wed, 12/17/08, Rene Peralta  wrote:
> From: Rene Peralta 
> Subject: Re: cryptanalysis of Twister
> To: "Multiple recipients of list" 
> Date: Wednesday, December 17, 2008, 9:07 AM
>
>
> Hi Sean,
>
> You and others have made this argument regarding several posted
> attacks. If I understand correctly, what you are saying is that a
> collision attack for which TIME*MEMORY is greater than 2^(n/2)
> is worse that some well-known generic attack. A similar argument
> has been made on this list regarding pre-image attacks.
>
> Can you point me to a reference to this generic attack? Also, any
> references to a rationale for use of a TIME*MEMORY metric in this
> context would be greatly appreciated.
>
> Thanks in advance, Rene.
>
> P.S. I am aware of standard time-memory tradeoff techniques, but I
> don't see the connection to the unqualified use of a TIME*MEMORY
> metric.
>
> At 12:57 PM 12/13/2008, Sean O'Neil wrote:
>
>> On 12 Dec 2008, at 16:59, Martin Schl=E4ffer wrote:
>>
>>> The attack can be extended to a theoretical collision attack on the
>>> hash function Twister-512 with a complexity of about 2^231.5 with
>>> different time-memory tradeoffs.
>>
>> You mean with complexity of about 2^231.5 operations multiplied by
>> 2^172.7 memory? Wouldn't those 2^160 circuits find a collision in
>> 2^96 time for any hash? It is so tempting to omit that annoying
>> memory requirement, isn't it? And then before you know it, the hash
>> is declared "broken". I am not saying that the cryptanalysis
> itself
>> is not valuable or that pseudo-collisions in 2^26.5 operations is not
>> a potentially serious threat. I just find it increasingly annoying
>> having to check every single paper for the fine print to see if it is
>> actually cheaper than the brute-force or other generic attacks or if
>> the authors "forgot" to mention memory the size of our galaxy.
> And a
>> lot of people just read the announcement and trust the experts. They
>> see 2^231.5 < 2^256, they assume that it's broken and the word
>> spreads...
>>
>> Best regards,
>> Sean O'Neil
>> http://www.enrupt.com/ - Raising the bar.
>>
>>
>
>
>
>
>
---559023410-851401618-1229527894=:7833--

From hash-forum@nist.gov  Wed Dec 17 08:02:18 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBHG2Cs3005717
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Dec 2008 08:02:13 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBHG1flr003972;
	Wed, 17 Dec 2008 11:01:44 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBHG1TSr000546;
	Wed, 17 Dec 2008 11:01:29 -0500
Date: Wed, 17 Dec 2008 11:01:29 -0500
Message-Id: <7bb08a5f0812170747l6d81ea6bjda62d65dbcfed826@mail.gmail.com>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "Jason Martin" 
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
References: <20081217075847.40461.qmail@cr.yp.to> 
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1
MIME-Version: 1.0
In-Reply-To: 
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 17 Dec 2008 08:02:13 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 412


I seems to me that it is up to the algorithm designer to specify a
firm recommended value for all tunable security parameters.  This
places the onus of "first cryptanalysis" directly on the designer, and
it provides a fixed target for future analysis.  I have skimmed about
half of the submissions, and I noticed that some authors provide
explicit computations demonstrating what security values are required
to obtain resistance to attacks such as differential cryptanalysis
while others just make vague arguments.  To me, there is much greater
value in a submission where the author has performed a good deal of
security analysis and placed a "stake in the ground" with respect to
the performance/security trade-off.

I am, of course, biased.  For my own submission, ESSENCE, I
deliberately went with a simply design so that I could explicitly
write down and analyze the Boolean functions and calculate the number
of steps (rounds) required.

I also think that it is premature to rank the algorithms by
performance in all but the most general sense.  At this stage of the
game, we wouldn't be comparing the "algorithms" as much as the
"implementations".  For example, in my own case, I didn't have time to
write both a 32-bit and 64-bit optimized version of the algorithm.
So, I only wrote a 64-bit optimized version (the 32-bit version is
just the reference code).  This is reflected in the rankings done by
Fleischmann, Forler, and Gorski where the 32-bit versions gets an "E"
while the 64-bit version gets a "B".  That difference has much more to
do with the implementation than the algorithm.  I suspect that many
other submissions also have sub-optimal implementations.  If we select
round-2 candidates based purely on a "fastest un-broken version"
scheme, then we may be choosing "implementations" rather than
"algorithms".

--jason

Jason Worth Martin
Asst. Professor of Mathematics
http://www.math.jmu.edu/~martin



On Wed, Dec 17, 2008 at 7:30 AM,   wrote:
>
> On Wed, 17 Dec 2008, D. J. Bernstein wrote:
>
>> This sorting has a critical advantage over the sorting advocated by the
>> Skein team: namely, I'm systematically talking about the _smallest_
>> unbroken number of rounds, while the Skein team focuses on the _full_
>> number of rounds.
>
> What really counts is the performace of a hash function if it becomes
> SHA-3. Then, the number of rounds (or rather, the values for all tunable
> security parameters) ought to be large enough to gain confidence that even
> further improvements of cryptanalysis will not break SHA-3. I anticipate
> that this will not be the "_smallest_ unbroken number of rounds".
>
> Actually, the main issue is "confidence".
>
> It is not determined just by the smallest unbroken number of rounds,
> perhaps multiplied by some deliberate security margin. It is also
> determined by
>  - design philosophy,
>  - structural properties,
>  - provable security results,
>  - provable resistance to certain cryptanalytic techniques,
>  - ...
>
> I won't repeat the excellent points Christian and Thomas made in this
> thread. But an obvious consequence is that two different hash functions
> may require different security margins to gain the same level of
> confidence, if one has supplementary security properties and the other one
> doesn't. This is actually comparable to the AES process: Apart from a
> relatively small security margin, Rijndael did benefit from its
> "wide-trail" proofs of security against differential and linear
> cryptanalysis.
>
> Your aproach to measure the efficiency of the smallest unbroken variant
> abstracts away from such security properties. It also puts all hash
> functions without tunable security parameters into an artificial
> disadvantage.
>
> So the final SHA-3 will require some choices for the security parameter.
> At the current point of time, the best (well, the only) estimate for that
> parameters are the designers' defaults.
>
>> Stefan similarly claims, without any justification, that Rivest doesn't
>> have "confidence" in reduced-round variants of MD6.
>
> I didn't claim that. Please try not to misrepresent my writing!
>
> Firstly, the MD6 team isn't just "Rivest", it is a group of 15 persons.
>
> Secondly, my claim is that the designers' choice of default values
> reflects the confidence they have into their own creation.
>
> This is general, not just with respect to MD6. And, what else should the
> designers' choice of default values for the security parameters indicate?
> The number of cups of coffee they drank when writing the final submission
> documents?
>
> Actually, MD6 has the interesting property of provable security against
> certain types of differential attacks (the authors of MD6 called them
> "standard differential attacks"). Your mileage may vary, but I consider
> this as an amazing result. The MD6 team made a good selling point here!
>
> Performance-wise, the MD6 team pays an extremely high prize for that
> selling point, though: As I seem to understand their approach, they needed
> such many rounds because their lower bound on the differential attacker's
> workload would otherwise remain below the work for a birthday attack.
>
> Thus, reduced-round variants of MD6 would have to abandon the claim of
> provable security against differential attacks. (Members of the MD6 team:
> Please correct me if I misunderstood you!)
>
>> Stefan says that choosing reduced-round variants of MD6---an option
>> clearly allowed in the SHA-3 Federal Register Notice---would "undermine
>> the credibility of SHA-3." I find this to be completely ridiculous.
>
> Imagine that the designers of MD6 -- or of any other hash function --
> recommend a certain number of rounds, and the final standard ignores the
> recommendation. Instead, that hash function is standardised at a reduced
> number of rounds. Wouldn't that be ridiculous?
>
> If the designers decided to change their recommendation during the SHA-3
> process, that would be another cup of tea, of course. Also, it would not
> constitute a credibility issue, if the specified number of rounds exceeded
> the designers' own recommendation.
>
> So long
>
> Stefan
>
>
>
>
> --
> ------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
>               Stefan dot Lucks at uni minus weimar dot de
> ------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------
>
>
>

From hash-forum@nist.gov  Wed Dec 17 08:30:34 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBHGUSel012478
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Dec 2008 08:30:30 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBHGU116026308;
	Wed, 17 Dec 2008 11:30:04 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBHGTkch026966;
	Wed, 17 Dec 2008 11:29:46 -0500
Date: Wed, 17 Dec 2008 11:29:46 -0500
Message-Id: <49492644.5070305@csc.kth.se>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: =?ISO-8859-1?Q?Douglas_Wikstr=F6m?= 
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
In-Reply-To: 
References: <20081217075847.40461.qmail@cr.yp.to> 
MIME-Version: 1.0
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 17 Dec 2008 08:30:30 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 413


Dear all,

I am not a member of the MD6-team, and an outsider to the competition, 
but I take the liberty to add something to what Stefan Lucks said.

> Thus, reduced-round variants of MD6 would have to abandon the claim of 
> provable security against differential attacks. (Members of the MD6 team: 
> Please correct me if I misunderstood you!)

But, the structural property would still be there. One can argue that 
even with fewer rounds, differential attacks would be an unlikely path 
to walk as an attacker, since the analysis is unlikely to be tight 
(MD6-team should correct me if their analysis is tight).

This type of heuristic argument is often used when choosing security 
parameters even for "provably secure" constructions, where the proper 
choices of security parameters would be unreasonably large.

It does not really say anything from a strict mathematical point of view 
of course, but I believe Stefan agrees that it is still a very nice 
feature, and the whole game here is rather non-strict... :-)

Furthermore, it would be great to be *able* to turn the knob all the way 
on the final SHA-3 to "now it is provably secure against differential 
attacks", even if that meant a somewhat slower hashfunction.



Regards,

Douglas Wikström
CSC KTH Stockholm

From hash-forum@nist.gov  Wed Dec 17 09:13:52 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBHHDkkb024783
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Dec 2008 09:13:48 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBHHD84s011085;
	Wed, 17 Dec 2008 12:13:10 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBHHD09X018601;
	Wed, 17 Dec 2008 12:13:00 -0500
Date: Wed, 17 Dec 2008 12:13:00 -0500
Message-Id: <7.0.1.0.2.20081217114130.05d85568@nist.gov>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: Rene Peralta 
To: Multiple recipients of list 
Subject: Re: cryptanalysis of Twister
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Mime-Version: 1.0
References: <493562.48430.qm@web36407.mail.mud.yahoo.com> 
In-Reply-To: 
X-Cc: rene peralta 
X-To: hash-forum@nist.gov, Multiple recipients of list 
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 17 Dec 2008 09:13:48 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 414



I've taken a brief look at the Bernstein Paper 
(2005 version, apparently unpublished).
I need some time to properly digest the ideas. It appears that
the proposed complexity metric would dismiss a collision attack that took, say,
2^(.3n) time and 2^(.3n) space. The attack would 
be called "worse than a generic attack"
because  2^(.3n) * 2^(.3n) = 2^(.6n) which is greater than 2^(.5n).

This is a non-standard complexity metric. But I 
will look into the merits of the argument.
It appears the TIME*MEMORY metric is justified by 
equating MEMORY with PROCESSORS.
So a machine that uses 1 processor, 2^(.3n) time, and 2^(.3n) memory would be
roughly equivalent to a parallel machine with 
2^(.3n) processors. Such a machine
would in fact find collisions in less than 2^(.3n) time.

My initial reaction is that there is an 
interesting point being made here. But I would not
go so far as to simply dismiss all collision 
attacks for which MEMORY * TIME is greater
than 2^(n/2) or preimage attacks for which MEMORY * TIME is greater than 2^n.


Regards, Rene.




At 10:33 AM 12/17/2008, Jonathan Katz wrote:
>The "textbook" birthday attack requires time *and* space 2^{n/2}.
>
>There is a modified birthday attack that takes 
>time 2^{n/2} and O(1) space. I don't have the 
>original reference (perhaps Pollard?), but it is 
>described starting on page 132 of the textbook 
>"Introduction to Modern Cryptography" by myself and Lindell.
>
>I don't see how there can be a generic collision 
>attack with time better than 2^{n/2}. (Actually, 
>I believe 2^{n/2} is a lower bound for finding 
>collisions in a random function.)
>
>On Wed, 17 Dec 2008, Peter wrote:
>
>>I believe O'Neil is referring to a "birthday 
>>attack". Correct me if I am wrong, but I was 
>>under the impression that a birthday attack 
>>takes 2^n/2 time at 2^0 memory, and 2^0 time at 
>>2^n/2. I believe the trade off is 2^x time and 2^y memory where x+y = n/2.
>>
>>--Peter
>>
>>--- On Wed, 12/17/08, Rene Peralta  wrote:
>>From: Rene Peralta 
>>Subject: Re: cryptanalysis of Twister
>>To: "Multiple recipients of list" 
>>Date: Wednesday, December 17, 2008, 9:07 AM
>>
>>
>>Hi Sean,
>>
>>You and others have made this argument regarding several posted
>>attacks. If I understand correctly, what you are saying is that a
>>collision attack for which TIME*MEMORY is greater than 2^(n/2)
>>is worse that some well-known generic attack. A similar argument
>>has been made on this list regarding pre-image attacks.
>>
>>Can you point me to a reference to this generic attack? Also, any
>>references to a rationale for use of a TIME*MEMORY metric in this
>>context would be greatly appreciated.
>>
>>Thanks in advance, Rene.
>>
>>P.S. I am aware of standard time-memory tradeoff techniques, but I
>>don't see the connection to the unqualified use of a TIME*MEMORY
>>metric.
>>
>>At 12:57 PM 12/13/2008, Sean O'Neil wrote:
>>
>>>On 12 Dec 2008, at 16:59, Martin Schläffer wrote:
>>>
>>>>The attack can be extended to a theoretical collision attack on the
>>>>hash function Twister-512 with a complexity of about 2^231.5 with
>>>>different time-memory tradeoffs.
>>>
>>>You mean with complexity of about 2^231.5 operations multiplied by
>>>2^172.7 memory? Wouldn't those 2^160 circuits find a collision in
>>>2^96 time for any hash? It is so tempting to omit that annoying
>>>memory requirement, isn't it? And then before you know it, the hash
>>>is declared "broken". I am not saying that the cryptanalysis
>>itself
>>>is not valuable or that pseudo-collisions in 2^26.5 operations is not
>>>a potentially serious threat. I just find it increasingly annoying
>>>having to check every single paper for the fine print to see if it is
>>>actually cheaper than the brute-force or other generic attacks or if
>>>the authors "forgot" to mention memory the size of our galaxy.
>>And a
>>>lot of people just read the announcement and trust the experts. They
>>>see 2^231.5 < 2^256, they assume that it's broken and the word
>>>spreads...
>>>
>>>Best regards,
>>>Sean O'Neil
>>>http://www.enrupt.com/ - Raising the bar.
>>>
>>
>>
>>
>>




From hash-forum@nist.gov  Wed Dec 17 09:55:55 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBHHtoxT002110
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Dec 2008 09:55:51 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBHHtJAM020322;
	Wed, 17 Dec 2008 12:55:22 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBHHt1Cm006214;
	Wed, 17 Dec 2008 12:55:01 -0500
Date: Wed, 17 Dec 2008 12:55:01 -0500
Message-Id: <20081217175156.GA7604@titan.cry.pto>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: Thomas Pornin 
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
In-Reply-To: <20081217075847.40461.qmail@cr.yp.to>
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
References: <20081216121512.98842mlo86zr0un4@webmail.nist.gov> <20081217075847.40461.qmail@cr.yp.to>
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 17 Dec 2008 09:55:51 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 415


On Wed, Dec 17, 2008 at 02:58:24AM -0500, D. J. Bernstein wrote:
> What I'm advocating for SHA-3 is that we sort submissions according to
> the efficiency of their fastest unbroken variants (which are what
> cryptanalysts want to look at anyway), and then concentrate on the
> most efficient submissions---let's say within a factor of 2 of the
> current leader.

There might be a slight difficulty here. Even assuming that we have
"optimized enough" implementations to make speed measures meaningful,
such measures will be specific to the used platform. Relative
performance of hash functions may vary quite greatly when using a
distinct architecture. Even if we concentrate on the "reference
platform" (which may not be a good idea, depending on how significant we
consider embedded systems with MiPS and ARM cores), then we have _two_
architectures, with the i386 and amd64 modes. This is relevant to the
comparison of two distinct algorithms, but also when deciding which
variant of an algorithm is the fastest, when the algorithm has several
tunable parameters which impact performance (e.g. CubeHash). The set of
parameters which is "the fastest unbroken" on a given platform may be
quite different on another.

Of course we can get rough ideas of relative performance (e.g. Whirlpool
is quite slower than SHA-1 on all architectures), but a "factor of 2"
requires a precision of definition and measure which does not seem to be
easily attainable. At least, so I think.


	--Thomas Pornin

From hash-forum@nist.gov  Wed Dec 17 10:09:59 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBHI9sm9008041
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Dec 2008 10:09:55 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBHI9JCT024592;
	Wed, 17 Dec 2008 13:09:21 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBHI9ABO002967;
	Wed, 17 Dec 2008 13:09:11 -0500
Date: Wed, 17 Dec 2008 13:09:10 -0500
Message-Id: 
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "Dmitry Khovratovich" 
To: Multiple recipients of list 
Subject: Re: cryptanalysis of Twister
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
References: <493562.48430.qm@web36407.mail.mud.yahoo.com>  <7.0.1.0.2.20081217114130.05d85568@nist.gov>
Content-Type: multipart/alternative;  boundary="----=_Part_13797_11575488.1229536959035"
MIME-Version: 1.0
In-Reply-To: <7.0.1.0.2.20081217114130.05d85568@nist.gov>
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 17 Dec 2008 10:09:55 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 416


------=_Part_13797_11575488.1229536959035
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

There is a difference between time and computations.

On Wed, Dec 17, 2008 at 10:41 PM, Rene Peralta  wrote:

>
>
> I've taken a brief look at the Bernstein Paper (2005 version, apparently
> unpublished).
> I need some time to properly digest the ideas. It appears that
> the proposed complexity metric would dismiss a collision attack that took=
,
> say,
> 2^(.3n) time and 2^(.3n) space. The attack would be called "worse than a
> generic attack"
> because  2^(.3n) * 2^(.3n) =3D 2^(.6n) which is greater than 2^(.5n).
>
> This is a non-standard complexity metric. But I will look into the merits
> of the argument.
> It appears the TIME*MEMORY metric is justified by equating MEMORY with
> PROCESSORS.
> So a machine that uses 1 processor, 2^(.3n) time, and 2^(.3n) memory woul=
d
> be
> roughly equivalent to a parallel machine with 2^(.3n) processors. Such a
> machine
> would in fact find collisions in less than 2^(.3n) time.
>
> My initial reaction is that there is an interesting point being made here=
.
> But I would not
> go so far as to simply dismiss all collision attacks for which MEMORY *
> TIME is greater
> than 2^(n/2) or preimage attacks for which MEMORY * TIME is greater than
> 2^n.
>
>
> Regards, Rene.
>
>
>
>
>
> At 10:33 AM 12/17/2008, Jonathan Katz wrote:
>
>> The "textbook" birthday attack requires time *and* space 2^{n/2}.
>>
>> There is a modified birthday attack that takes time 2^{n/2} and O(1)
>> space. I don't have the original reference (perhaps Pollard?), but it is
>> described starting on page 132 of the textbook "Introduction to Modern
>> Cryptography" by myself and Lindell.
>>
>> I don't see how there can be a generic collision attack with time better
>> than 2^{n/2}. (Actually, I believe 2^{n/2} is a lower bound for finding
>> collisions in a random function.)
>>
>> On Wed, 17 Dec 2008, Peter wrote:
>>
>>  I believe O'Neil is referring to a "birthday attack". Correct me if I a=
m
>>> wrong, but I was under the impression that a birthday attack takes 2^n/=
2
>>> time at 2^0 memory, and 2^0 time at 2^n/2. I believe the trade off is 2=
^x
>>> time and 2^y memory where x+y =3D n/2.
>>>
>>> --Peter
>>>
>>> --- On Wed, 12/17/08, Rene Peralta  wrote:
>>> From: Rene Peralta 
>>> Subject: Re: cryptanalysis of Twister
>>> To: "Multiple recipients of list" 
>>> Date: Wednesday, December 17, 2008, 9:07 AM
>>>
>>>
>>> Hi Sean,
>>>
>>> You and others have made this argument regarding several posted
>>> attacks. If I understand correctly, what you are saying is that a
>>> collision attack for which TIME*MEMORY is greater than 2^(n/2)
>>> is worse that some well-known generic attack. A similar argument
>>> has been made on this list regarding pre-image attacks.
>>>
>>> Can you point me to a reference to this generic attack? Also, any
>>> references to a rationale for use of a TIME*MEMORY metric in this
>>> context would be greatly appreciated.
>>>
>>> Thanks in advance, Rene.
>>>
>>> P.S. I am aware of standard time-memory tradeoff techniques, but I
>>> don't see the connection to the unqualified use of a TIME*MEMORY
>>> metric.
>>>
>>> At 12:57 PM 12/13/2008, Sean O'Neil wrote:
>>>
>>>  On 12 Dec 2008, at 16:59, Martin Schl=E4ffer wrote:
>>>>
>>>>  The attack can be extended to a theoretical collision attack on the
>>>>> hash function Twister-512 with a complexity of about 2^231.5 with
>>>>> different time-memory tradeoffs.
>>>>>
>>>>
>>>> You mean with complexity of about 2^231.5 operations multiplied by
>>>> 2^172.7 memory? Wouldn't those 2^160 circuits find a collision in
>>>> 2^96 time for any hash? It is so tempting to omit that annoying
>>>> memory requirement, isn't it? And then before you know it, the hash
>>>> is declared "broken". I am not saying that the cryptanalysis
>>>>
>>> itself
>>>
>>>> is not valuable or that pseudo-collisions in 2^26.5 operations is not
>>>> a potentially serious threat. I just find it increasingly annoying
>>>> having to check every single paper for the fine print to see if it is
>>>> actually cheaper than the brute-force or other generic attacks or if
>>>> the authors "forgot" to mention memory the size of our galaxy.
>>>>
>>> And a
>>>
>>>> lot of people just read the announcement and trust the experts. They
>>>> see 2^231.5 < 2^256, they assume that it's broken and the word
>>>> spreads...
>>>>
>>>> Best regards,
>>>> Sean O'Neil
>>>> http://www.enrupt.com/ - Raising the bar.
>>>>
>>>>
>>>
>>>
>>>
>>>
>
>
>
>


--=20
Best regards,
Dmitry Khovratovich

University of Luxembourg,
Laboratory of Algorithmics, Cryptography and Security,
+ 352 46 66 44 5478

------=_Part_13797_11575488.1229536959035
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

There is a difference between time and computations. 

On Wed, Dec 17, 2008 at 10:41 PM, Rene Peralta <peralta@nist.gov> =
wrote:






I've taken a brief look at the Bernstein Paper (2005 version, apparentl=
y unpublished).

I need some time to properly digest the ideas. It appears that

the proposed complexity metric would dismiss a collision attack that took, =
say,

2^(.3n) time and 2^(.3n) space. The attack would be called "worse than=
 a generic attack"

because  2^(.3n) * 2^(.3n) =3D 2^(.6n) which is greater than 2^(.5n).<=
br>


This is a non-standard complexity metric. But I will look into the merits o=
f the argument.

It appears the TIME*MEMORY metric is justified by equating MEMORY with PROC=
ESSORS.

So a machine that uses 1 processor, 2^(.3n) time, and 2^(.3n) memory would =
be

roughly equivalent to a parallel machine with 2^(.3n) processors. Such a ma=
chine

would in fact find collisions in less than 2^(.3n) time.



My initial reaction is that there is an interesting point being made here. =
But I would not

go so far as to simply dismiss all collision attacks for which MEMORY * TIM=
E is greater

than 2^(n/2) or preimage attacks for which MEMORY * TIME is greater than 2^=
n.





Regards, Rene.










At 10:33 AM 12/17/2008, Jonathan Katz wrote:



The "textbook" birthday attack requires time *and* space 2^{n/2}.=




There is a modified birthday attack that takes time 2^{n/2} and O(1) space.=
 I don't have the original reference (perhaps Pollard?), but it is desc=
ribed starting on page 132 of the textbook "Introduction to Modern Cry=
ptography" by myself and Lindell.




I don't see how there can be a generic collision attack with time bette=
r than 2^{n/2}. (Actually, I believe 2^{n/2} is a lower bound for finding c=
ollisions in a random function.)



On Wed, 17 Dec 2008, Peter wrote:





I believe O'Neil is referring to a "birthday attack". Correct=
 me if I am wrong, but I was under the impression that a birthday attack ta=
kes 2^n/2 time at 2^0 memory, and 2^0 time at 2^n/2. I believe the trade of=
f is 2^x time and 2^y memory where x+y =3D n/2.




--Peter



--- On Wed, 12/17/08, Rene Peralta <peralta@nist.gov> wrote:

From: Rene Peralta <peralta@nist.gov>

Subject: Re: cryptanalysis of Twister

To: "Multiple recipients of list" <hash-forum@nist.gov>

Date: Wednesday, December 17, 2008, 9:07 AM





Hi Sean,



You and others have made this argument regarding several posted

attacks. If I understand correctly, what you are saying is that a

collision attack for which TIME*MEMORY is greater than 2^(n/2)

is worse that some well-known generic attack. A similar argument

has been made on this list regarding pre-image attacks.



Can you point me to a reference to this generic attack? Also, any

references to a rationale for use of a TIME*MEMORY metric in this

context would be greatly appreciated.



Thanks in advance, Rene.



P.S. I am aware of standard time-memory tradeoff techniques, but I

don't see the connection to the unqualified use of a TIME*MEMORY

metric.



At 12:57 PM 12/13/2008, Sean O'Neil wrote:





On 12 Dec 2008, at 16:59, Martin Schl=E4ffer wrote:





The attack can be extended to a theoretical collision attack on the

hash function Twister-512 with a complexity of about 2^231.5 with

different time-memory tradeoffs.





You mean with complexity of about 2^231.5 operations multiplied by

2^172.7 memory? Wouldn't those 2^160 circuits find a collision in

2^96 time for any hash? It is so tempting to omit that annoying

memory requirement, isn't it? And then before you know it, the hash

is declared "broken". I am not saying that the cryptanalysis



itself



is not valuable or that pseudo-collisions in 2^26.5 operations is not

a potentially serious threat. I just find it increasingly annoying

having to check every single paper for the fine print to see if it is

actually cheaper than the brute-force or other generic attacks or if

the authors "forgot" to mention memory the size of our galaxy.


And a



lot of people just read the announcement and trust the experts. They

see 2^231.5 < 2^256, they assume that it's broken and the word

spreads...



Best regards,

Sean O'Neil

http://www.enrupt.com/=
 - Raising the bar.



























-- 
Best regard=
s, 
Dmitry Khovratovich

University of Luxembourg,
Laboratory o=
f Algorithmics, Cryptography and Security,
+ 352 46 66 44 5478




------=_Part_13797_11575488.1229536959035--

From hash-forum@nist.gov  Wed Dec 17 10:24:18 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBHIOCLU013879
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Dec 2008 10:24:14 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBHINX9o022551;
	Wed, 17 Dec 2008 13:23:35 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBHIND4o032241;
	Wed, 17 Dec 2008 13:23:13 -0500
Date: Wed, 17 Dec 2008 13:23:13 -0500
Message-Id: <1E2D47D2-8747-479B-91AE-A66217D92492@cryptolib.com>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "Sean O'Neil" 
To: Multiple recipients of list 
Subject: Re: cryptanalysis of Twister
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Mailer: Apple Mail (2.753.1)
X-To: hash-forum@nist.gov
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
References: <493562.48430.qm@web36407.mail.mud.yahoo.com>  <7.0.1.0.2.20081217114130.05d85568@nist.gov>
In-Reply-To: <7.0.1.0.2.20081217114130.05d85568@nist.gov>
Mime-Version: 1.0 (Apple Message framework v753.1)
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 17 Dec 2008 10:24:14 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 417


On 17 Dec 2008, at 18:11, Rene Peralta wrote:

> My initial reaction is that there is an interesting point being  
> made here. But I would not
> go so far as to simply dismiss all collision attacks for which  
> MEMORY * TIME is greater
> than 2^(n/2) or preimage attacks for which MEMORY * TIME is greater  
> than 2^n.


Yes, you are correct. Such attacks give us a good insight into all  
potential optimizations. They should not be dismissed even if they  
are more costly than the brute-force or other generic attacks, and  
even if they don't work. My only concern is that such heavy memory  
requirements are often omitted from notes and even abstracts as  
insignificant, one has to dig through the paper to find them.

I guess it all goes back to the early *memoryless* differential and  
linear attacks, when everyone's focus was entirely on time alone as  
the measure of attack complexity. So it is still often accepted as  
such while mistakenly or even consciously disregarding the memory cost.

With best regards,
Sean O'Neil
http://www.enrupt.com/ - Raising the bar.


From hash-forum@nist.gov  Wed Dec 17 11:06:17 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBHJ6BLa028984
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Dec 2008 11:06:12 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBHJ5VLu028372;
	Wed, 17 Dec 2008 14:05:34 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBHJ5JTd021555;
	Wed, 17 Dec 2008 14:05:19 -0500
Date: Wed, 17 Dec 2008 14:05:19 -0500
Message-Id: <20081217135303.19903orjvmpzlfv3@webmail.nist.gov>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: peralta@nist.gov
To: Multiple recipients of list 
Subject: Re: cryptanalysis of Twister
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed"
MIME-Version: 1.0
In-Reply-To: <7.0.1.0.2.20081217114130.05d85568@nist.gov>
References: <493562.48430.qm@web36407.mail.mud.yahoo.com>  <7.0.1.0.2.20081217114130.05d85568@nist.gov>
X-Cc: hash-forum@nist.gov, "rene peralta" 
X-To: "Rene Peralta" 
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 17 Dec 2008 11:06:12 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 418



Apologies, I hadn't realized that the link to the Bernstein
paper was not sent to the whole list. Here it is

http://cr.yp.to/snuffle/bruteforce-20050425.pdf


Regards, Rene.


Quoting "Rene Peralta" :

>
> I've taken a brief look at the Bernstein Paper (2005 version,  
> apparently unpublished).
> I need some time to properly digest the ideas. It appears that
> the proposed complexity metric would dismiss a collision attack that  
> took, say,
> 2^(.3n) time and 2^(.3n) space. The attack would be called "worse  
> than a generic attack"
> because  2^(.3n) * 2^(.3n) = 2^(.6n) which is greater than 2^(.5n).
>
> This is a non-standard complexity metric. But I will look into the  
> merits of the argument.
> It appears the TIME*MEMORY metric is justified by equating MEMORY  
> with PROCESSORS.
> So a machine that uses 1 processor, 2^(.3n) time, and 2^(.3n) memory would be
> roughly equivalent to a parallel machine with 2^(.3n) processors.  
> Such a machine
> would in fact find collisions in less than 2^(.3n) time.
>
> My initial reaction is that there is an interesting point being made  
> here. But I would not
> go so far as to simply dismiss all collision attacks for which  
> MEMORY * TIME is greater
> than 2^(n/2) or preimage attacks for which MEMORY * TIME is greater than 2^n.
>
>
> Regards, Rene.
>
>
>
>
> At 10:33 AM 12/17/2008, Jonathan Katz wrote:
>> The "textbook" birthday attack requires time *and* space 2^{n/2}.
>>
>> There is a modified birthday attack that takes time 2^{n/2} and  
>> O(1) space. I don't have the original reference (perhaps Pollard?),  
>> but it is described starting on page 132 of the textbook  
>> "Introduction to Modern Cryptography" by myself and Lindell.
>>
>> I don't see how there can be a generic collision attack with time  
>> better than 2^{n/2}. (Actually, I believe 2^{n/2} is a lower bound  
>> for finding collisions in a random function.)
>>
>> On Wed, 17 Dec 2008, Peter wrote:
>>
>>> I believe O'Neil is referring to a "birthday attack". Correct me  
>>> if I am wrong, but I was under the impression that a birthday  
>>> attack takes 2^n/2 time at 2^0 memory, and 2^0 time at 2^n/2. I  
>>> believe the trade off is 2^x time and 2^y memory where x+y = n/2.
>>>
>>> --Peter
>>>
>>> --- On Wed, 12/17/08, Rene Peralta  wrote:
>>> From: Rene Peralta 
>>> Subject: Re: cryptanalysis of Twister
>>> To: "Multiple recipients of list" 
>>> Date: Wednesday, December 17, 2008, 9:07 AM
>>>
>>>
>>> Hi Sean,
>>>
>>> You and others have made this argument regarding several posted
>>> attacks. If I understand correctly, what you are saying is that a
>>> collision attack for which TIME*MEMORY is greater than 2^(n/2)
>>> is worse that some well-known generic attack. A similar argument
>>> has been made on this list regarding pre-image attacks.
>>>
>>> Can you point me to a reference to this generic attack? Also, any
>>> references to a rationale for use of a TIME*MEMORY metric in this
>>> context would be greatly appreciated.
>>>
>>> Thanks in advance, Rene.
>>>
>>> P.S. I am aware of standard time-memory tradeoff techniques, but I
>>> don't see the connection to the unqualified use of a TIME*MEMORY
>>> metric.
>>>
>>> At 12:57 PM 12/13/2008, Sean O'Neil wrote:
>>>
>>>> On 12 Dec 2008, at 16:59, Martin Schläffer wrote:
>>>>
>>>>> The attack can be extended to a theoretical collision attack on the
>>>>> hash function Twister-512 with a complexity of about 2^231.5 with
>>>>> different time-memory tradeoffs.
>>>>
>>>> You mean with complexity of about 2^231.5 operations multiplied by
>>>> 2^172.7 memory? Wouldn't those 2^160 circuits find a collision in
>>>> 2^96 time for any hash? It is so tempting to omit that annoying
>>>> memory requirement, isn't it? And then before you know it, the hash
>>>> is declared "broken". I am not saying that the cryptanalysis
>>> itself
>>>> is not valuable or that pseudo-collisions in 2^26.5 operations is not
>>>> a potentially serious threat. I just find it increasingly annoying
>>>> having to check every single paper for the fine print to see if it is
>>>> actually cheaper than the brute-force or other generic attacks or if
>>>> the authors "forgot" to mention memory the size of our galaxy.
>>> And a
>>>> lot of people just read the announcement and trust the experts. They
>>>> see 2^231.5 < 2^256, they assume that it's broken and the word
>>>> spreads...
>>>>
>>>> Best regards,
>>>> Sean O'Neil
>>>> http://www.enrupt.com/ - Raising the bar.
>>>>
>>>
>>>
>>>
>>>
>
>
>



From hash-forum@nist.gov  Wed Dec 17 11:47:57 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBHJlpuc006360
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Dec 2008 11:47:52 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBHJlMqG028700;
	Wed, 17 Dec 2008 14:47:23 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBHJlBGw009656;
	Wed, 17 Dec 2008 14:47:11 -0500
Date: Wed, 17 Dec 2008 14:47:11 -0500
Message-Id: 
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: Stefan.Lucks@uni-weimar.de
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: MULTIPART/MIXED; BOUNDARY="8323584-1746290707-1229543725=:27412"
MIME-Version: 1.0
References: <20081217075847.40461.qmail@cr.yp.to>  <49492644.5070305@csc.kth.se>
In-Reply-To: <49492644.5070305@csc.kth.se>
X-To: Multiple recipients of list 
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 17 Dec 2008 11:47:52 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 419


  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323584-1746290707-1229543725=:27412
Content-Type: TEXT/PLAIN; charset=UTF-8
Content-Transfer-Encoding: 8BIT

I wrote:

> > Thus, reduced-round variants of MD6 would have to abandon the claim of
> > provable security against differential attacks. (Members of the MD6 team:
> > Please correct me if I misunderstood you!)

Douglas Wikström wrote:

> But, the structural property would still be there. One can argue that even
> with fewer rounds, differential attacks would be an unlikely path to walk as
> an attacker, since the analysis is unlikely to be tight (MD6-team should
> correct me if their analysis is tight).

In Figure 6.5 of the MD6 submission document, there is a table with number 
of rounds and lower bounds for the work of differential attacks. (And with 
some other information.)

The table starts at 50 rounds, and goes up to 168 rounds. For 168 rounds, 
the workload for a "differential style collision attack" is 2^260. For 50 
rounds, the bound is 2^52. As you can see, the lower bound is roughly 
exponential in the number of rounds. 

Dan suggested "24-round MD6, running at a quite reasonable 7 cycles/byte". 
I agree with him that 7 cycles/byte would be quite reasonable.

But when I try to extrapolite the results from the table for 24 rounds, 
the bound on the workload becomes more or less negligible. I bet, the 
bound is well below 2^{24}. Even if the analysis happens to be quite 
un-tight (looks plausible), what is the conclusion for 24 rounds of MD6?

This doesn't mean there is actually an attack on 24 rounds. But my 
conclusion is that you cannot get any assurance of resistance against 
theoretical or even practical collision attacks from that result.

So long

Stefan

-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------
--8323584-1746290707-1229543725=:27412--

From hash-forum@nist.gov  Wed Dec 17 12:30:11 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBHKU53j016303
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Dec 2008 12:30:06 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBHKTQ5c029960;
	Wed, 17 Dec 2008 15:29:29 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBHKT5gZ031351;
	Wed, 17 Dec 2008 15:29:05 -0500
Date: Wed, 17 Dec 2008 15:29:05 -0500
Message-Id: 
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "Ivica Nikolic" 
To: Multiple recipients of list 
Subject: Re: Slide attacks on LUX
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
References: <72CF8F2B2766084DBD7AEAFCAE4A3B790969D7DE@frsnprexc1.usr.ingenico.loc>
Content-Type: multipart/alternative;  boundary="----=_Part_12527_20034561.1229545457398"
MIME-Version: 1.0
In-Reply-To: <72CF8F2B2766084DBD7AEAFCAE4A3B790969D7DE@frsnprexc1.usr.ingenico.loc>
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 17 Dec 2008 12:30:06 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_MED,URIBL_GREY shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 420


------=_Part_12527_20034561.1229545457398
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Dear Thomas,


Yes, it is a nice observation.

However, we would like to emphasize that the salt length is fixed by design
to 128 bits for LUX-224 and LUX-256, and 256-bits to LUX-384 and LUX-512
(both are 0 mod 32).
Thus it is not possible to use variable salt sizes in order to mount the
length extension slide attack.


Best regards,
Ivica, Alex, Dmitry



On Wed, Dec 17, 2008 at 12:49 PM, Thomas PEYRIN
wrote:

>   Hi all,
>
>
>
> Here is a remark on the 256-bit version of LUX when a salt is used: by
> using slide attacks on hash functions (the general idea of the attack can=
 be
> found here:
> http://thomas.peyrin.googlepages.com/Gorski-Lucks-Peyrin-Asiacrypt2008.pd=
f), one can, without any computation (except for actually computing the
> outputs):
>
>
>
> 1) differentiate the hash function from a random oracle
>
> 2) generate two strongly related outputs
>
>
>
> *This only works when the salt size is equal to 31 modulo 32*. Thus, I
> fully agree that this observation is not really useful in practice, and I
> leave it up to you to judge if this is a real vulnerability. Note that th=
e
> LUX designers already validated this analysis.
>
>
>
>
>
> For the interested readers, it works as follows:
>
>
>
> In LUX, two padding are used: the "10" padding and the length padding. In
> the case of 256-bit output, the length padding will fit in two message bl=
ocs
> and I denote them L1 and L2. Thus the padded message is
>
>
>
> M || 1 =850 || L1 || L2
>
>
>
> For now, we assume there is no "10" padding (we assume that the message
> length is always a multiple of the message block length). I will choose t=
wo
> messages M and M':
>
>
>
>  1st message with padding: M || L1 || L2
>
> 2nd message with padding: M' || L1' || L2'
>
>
>
> I'll force the condition that M' =3D M || L1. Note that M' is one message
> block bigger, so L1' || L2' =3D (L1 || L2) + 32 (4 times 8 bits per messa=
ge
> block). Then, we have
>
>
>
> 1st message with padding: M || L1 || L2
>
> 2nd message with padding: M || L1 || L1' || L2'
>
>
>
> Now, we add two more conditions: L2' =3D 0 and L2 =3D L1'.  This is possi=
ble in
> the following case:
>
>
>
> L1 =3D 11111111 11111111 11111111 11011111
>
> L2 =3D 11111111 11111111 11111111 11100000
>
>
>
> L1'=3D 11111111 11111111 11111111 11100000
>
> L2'=3D 00000000 00000000 00000000 00000000
>
>
>
> Finally, we have:
>
>
>
> 1st message with padding: M || L1 || L2
>
> 2nd message with padding: M || L1 || L2 || 0
>
>
>
> One can see that exactly the same message blocks will be treated, except
> that for the second message M' we have a "0" message block to add. This h=
as
> the effect that the "0" block will behave as a blank round (in which no
> message is incorporated) and (M,M') is a slid pair of message : their
> respective outputs are just one blank round away. That is, if the output =
for
> M is (H0,H1,H2,H3,H4,H5,H6,H7), then the output for M' will be
> (H1,H2,H3,H4,H5,H6,H7,R)  where R is some random 32-bit value.
>
>
>
> To conclude, with no computation cost, one can differentiate the hash
> function from a random oracle or generate strongly correlated output pair=
s.
> Now, if I want to reintroduce the "01" padding and keep the attack workin=
g,
> I can use the salt: if the length of the salt is equal to 31 modulo 32, t=
hen
> I can adapt the attack to take care of the "10" padding. Note that the
> length padding only codes the real message length and don't consider the
> salt length.
>
>
>
>
>
> Let's say that we have a salt S of size 31 bit and two messages M and M' =
of
> size 0 modulo 32, such that (as before):
>
>
>
> L1 =3D 11111111 11111111 11111111 11011111
>
> L2 =3D 11111111 11111111 11111111 11100000
>
>
>
> L1'=3D 11111111 11111111 11111111 11100000
>
> L2'=3D 00000000 00000000 00000000 00000000
>
>
>
> We indeed have L2 and L2' =3D 0 modulo 32.
>
>
>
> 1st message with padding:  S || M || "10" padding || L1 || L2
>
> 2nd message with padding: S || M' || "10" padding || L1' || L2'
>
>
>
> The 10 padding will be just a 1 for both messages (because of the 31-bit
> salt), thus we have
>
>
>
> 1st message with padding:  S || M || 1 || L1 || L2
>
> 2nd message with padding: S || M' || 1 || L1' || L2'
>
>
>
> Now we say that M'=3D M || 1 || 11111111 11111111 11111111 1101111    (th=
at
> is M, the "1" bit from the "10" padding, and the length L1 without the ve=
ry
> last bit). Thus, when M' will be "01" padded, we get
>
>
>
> M' || "01" padding =3D M || 1 || 11111111 11111111 11111111 1101111 || 1 =
=3D M
> || 1 || L1
>
>
>
> Now, the reasoning is the same as before:
>
>
>
> 1st message with padding: S || M || 1 || L1 || L2
>
> 2nd message with padding: S || M || 1 || L1 || L1' || L2'
>
>
>
> And since L2 =3D L1' and L2' =3D 0, we finally have
>
>
>
> 1st message with padding: S || M || 1 || L1 || L2
>
> 2nd message with padding: S || M || 1 || L1 || L2 || 0
>
>
>
> And the slide attack applies.
>
>
>
> Cheers,
>
>
>
> Thomas.
>
>
>
>
>
>
> *About Ingenico**: Ingenico is the world's leading provider of payment
> solutions, with over 15 million terminals deployed across the globe. **De=
livering
> the very latest secure electronic payment technologies, transaction
> management and the widest range of value added services, Ingenico is shap=
ing
> the future direction of the payment solutions market. Leveraging on its
> global presence and local expertise, Ingenico is reinforcing its leadersh=
ip
> by taking banks and businesses beyond payment through offering comprehens=
ive
> solutions, a true source of differentiation and new revenues streams**.*
>
>  This message may contain confidential and/or privileged information. If
> you are not the addressee or authorized to receive this for the addressee=
,
> you must not use, copy, disclose or take any action based on this message=
 or
> any information herein. If you have received this message in error, pleas=
e
> advise the sender immediately by reply e-mail and delete this message. Th=
ank
> you for your cooperation.
>
>  P Please consider the environment before printing this e-mail
>
> **
>
> **
>



--=20
---------------------------------------------------------------
Ivica Nikolic
Laboratory of Algorithms, Cryptography and Security,
University of Luxembourg,
6, rue Richard Coudenhove-Kalergi,
L-1359 Luxembourg-Kirchberg
Luxembourg
Tel:  +352 46 66 44 5490

------=_Part_12527_20034561.1229545457398
Content-Type: text/html; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Dear Thomas,


Yes, it is a nice observation.

However, we =
would like to emphasize that the salt length is fixed by design to 128 bits=
 for LUX-224 and LUX-256, and 256-bits to LUX-384 and LUX-512 (both are 0 m=
od 32). 

Thus it is not possible to use variable salt sizes in order to mount t=
he length extension slide attack. 

 =

Best regards,
Ivica, Alex, Dmitry





On Wed, Dec 17, 2008 at 12:49 PM, Thomas PEYRIN =
<Thomas.=
PEYRIN@ingenico.com> wrote:
Hi all,



 



Here is a remark on the 256-bit version of LUX wh=
en a
salt is used: by using slide attacks on hash functions (the general idea of=
 the
attack can be found here: =
http://thomas.peyrin.googlepages.com/Gorski-Lucks-Peyrin-Asiacrypt2008.pdf<=
/a>
), one can, without any computation (except for actually computing the outp=
uts):



 



1) differentiate the hash function from a random
oracle



2) generate two strongly related outputs



 



This only works when the salt size i=
s
equal to 31 modulo 32. Thus, I fully=
 agree
that this observation is not really useful in practice, and I leave it up t=
o
you to judge if this is a real vulnerability. Note that the LUX designers
already validated this analysis.



 



 



For the interested readers, it works as follows:



 



In LUX, two padding are used: the "10"
padding and the length padding. In the case of 256-bit output, the length
padding will fit in two message blocs and I denote them L1 and L2. Thus the
padded message is 



 <=
/p>


M || 1 =850 || L1 || L2 



 <=
/p>


For now, we assume there is no "10"
padding (we assume that the message length is always a multiple of the mess=
age
block length). I will choose two messages M and M': 



 <=
/p>


 1st message with padding: M || L1 || L2



2nd message with padding: M' || L1' || L2'=




 <=
/p>


I'll force the condition that M' =3D M ||
L1. Note that M' is one message block bigger, so L1' || L2' =3D
(L1 || L2) + 32 (4 times 8 bits per message block). Then, we have 



 <=
/p>


1st message with padding: M || L1 || L2



2nd message with padding: M || L1 || L1' ||
L2' 



 <=
/p>


Now, we add two more conditions: L2' =3D 0 and L2
=3D L1'.  This is possible in the following case:



 <=
/p>


L1 =3D 11111111 11111111 11111111 11011111=




L2 =3D 11111111 11111111 11111111 11100000=




 <=
/p>


L1'=3D 11111111 11111111 11111111 11100000=




L2'=3D 00000000 00000000 00000000 00000000=




 <=
/p>


Finally, we have: 



 <=
/p>


1st message with padding: M || L1 || L2



2nd message with padding: M || L1 || L2 || 0 



 <=
/p>


One can see that exactly the same message blocks =
will
be treated, except that for the second message M' we have a
"0" message block to add. This has the effect that the
"0" block will behave as a blank round (in which no message is
incorporated) and (M,M') is a slid pair of message : their respective
outputs are just one blank round away. That is, if the output for M is
(H0,H1,H2,H3,H4,H5,H6,H7), then the output for M' will be
(H1,H2,H3,H4,H5,H6,H7,R)  where R is some random 32-bit value. =




 <=
/p>


To conclude, with no computation cost, one can di=
fferentiate
the hash function from a random oracle or generate strongly correlated outp=
ut
pairs. Now, if I want to reintroduce the "01" padding and keep the
attack working, I can use the salt: if the length of the salt is equal to 3=
1
modulo 32, then I can adapt the attack to take care of the "10"
padding. Note that the length padding only codes the real message length an=
d don't
consider the salt length. 



 



 



Let's say that we have a salt S of size 31 bit
and two messages M and M' of size 0 modulo 32, such that (as before):



 <=
/p>


L1 =3D 11111111 11111111 11111111 11011111=




L2 =3D 11111111 11111111 11111111 11100000=




 <=
/p>


L1'=3D 11111111 11111111 11111111 11100000=




L2'=3D 00000000 00000000 00000000 00000000=




 <=
/p>


We indeed have L2 and L2' =3D 0 modulo 32.=




 <=
/p>


1st message with padding:  S || M ||
"10" padding || L1 || L2 



2nd message with padding: S || M' || "10"
padding || L1' || L2' 



 <=
/p>


The 10 padding will be just a 1 for both messages
(because of the 31-bit salt), thus we have 



 <=
/p>


1st message with padding:  S || M || 1 || L1=
 ||
L2 



2nd message with padding: S || M' || 1 ||
L1' || L2' 



 



Now we say that M'=3D M || 1 || 11111111
11111111 11111111 1101111    (that is M, the "1" bit
from the "10" padding, and the length L1 without the very last
bit). Thus, when M' will be "01" padded, we get 



 <=
/p>


M' || "01" padding =3D M || 1 || 11111111
11111111 11111111 1101111 || 1 =3D M || =
1 || L1



 



Now, the reasoning is the same as before:



 



1st message with padding: S || M || 1 || L1 || L2=




2nd message with padding: S || M || 1 || L1 ||
L1' || L2'



 <=
/p>


And since L2 =3D L1' and L2' =3D 0, we finally
have 



 



1st message with padding: S || M || 1 || L1 || L2=




2nd message with padding: S || M || 1 || L1 || L2=
 ||
0 



 <=
/p>


And the slide attack applies.



 



Cheers,



 



Thomas.



 



 








 




About Ingenico=
: Ingenico is the world's leading provider of payment solutions, with over =
15 million terminals deployed across the globe. Delivering the very latest secur=
e electronic payment technologies, transaction management and the widest ra=
nge of value added services, Ingenico is shaping the future direction of th=
e payment solutions market. Leveraging on its global presence and local exp=
ertise, Ingenico is reinforcing its leadership by taking banks and business=
es beyond payment through offering comprehensive solutions, a true source o=
f differentiation and new revenues streams.



 This =
message may contain confidential and/or privileged information. If you are =
not the addressee or authorized to receive this for the addressee, you must=
 not use, copy, disclose or take any action based on this message or any in=
formation herein. If you have received this message in error, please advise=
 the sender immediately by reply e-mail and delete this message. Thank you =
for your cooperation.



 P Please consider the environment before printing this e=
-mail




 




 




-- 
-----------------------=
----------------------------------------
Ivica Nikolic 
Laboratory of=
 Algorithms, Cryptography and Security,
University of Luxembourg, 

6, rue Richard Coudenhove-Kalergi,
L-1359 Luxembourg-Kirchberg
Luxemb=
ourg
Tel:  +352 46 66 44 5490


------=_Part_12527_20034561.1229545457398--

From hash-forum@nist.gov  Wed Dec 17 12:30:06 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBHKTxEc016257
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Dec 2008 12:30:01 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBHKTQ5a029960;
	Wed, 17 Dec 2008 15:29:28 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBHKTHRB031686;
	Wed, 17 Dec 2008 15:29:17 -0500
Date: Wed, 17 Dec 2008 15:29:17 -0500
Message-Id: <7731938b0812171225g7439801dx417579c696dbaf98@mail.gmail.com>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "Peter Maxwell" 
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
References: <20081216121512.98842mlo86zr0un4@webmail.nist.gov> <20081217075847.40461.qmail@cr.yp.to> <20081217175156.GA7604@titan.cry.pto>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1
MIME-Version: 1.0
In-Reply-To: <20081217175156.GA7604@titan.cry.pto>
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 17 Dec 2008 12:30:01 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 421


Hi,

Going against the prevailing wind here, I think Daniel's approach is
sound; it does make sense to measure performance of the fastest
unbroken version of a hash.  Its a natural approach in may areas of
life - say for (a trivial) example, buying orange juice from the local
shop, you may have an idea of which brands you like but you're quite
likely to work out how much orange juice you get for your pound.  We
measure fuel efficiency of cars, the cost per unit of electricity,
broadband bandwidth for the price, etc.  They are all benefit/cost
type calculations.  Why should this be any different?  It doesn't say
there aren't other considerations, but the amount of security for cpu
cycles is going to be a pretty major factor.

Here's some suggestions of overcoming the difficulties raised in the
previous posts:

i) Some algorithms have more than one tunable parameter so how do we
work with that?  Well if we take the whole parameter set an then rank
each element from that set as an individual algorithm then if its
broke its dropped off the list.  The ones that stay on the list will
give a good yard stick or relative performance.

ii) Implementation issues.  Yes, some implementations are going to be
a lot more optimised than others but unless an implementation is
*really* badly coded we're not going to expect more than a 30%
difference over a heavily optimised version.  Secondly, NIST seems to
be suggesting that they'll consider new optimised versions - so if its
a big concern for a submitter then there's always that avenue open to
create a more optimised implementation.

iii) Finite vs asymptopic behaviour; the perfomance of a hash will
likely show different behaviour over small message sizes as compared
to its asymptopic performance.  There's several approaches possible
here - we could graph it and visually compare, fit a curve or even
integrate under the curve.  That way we have a scalar and can use if
for convenient well-ordered ranking.

iv) Different platforms.  This is probably the most thorny issue.
However, for all the talk of 8-bit processors and limited
environments, I don't see a plethora of sample implementations,
figures or "this will just not fly" arguments... just a thought.  The
standard i386/x64 measurements should be good enough for just now.

v) RAM and static memory usage.  Perhaps collate this seperately, it
doesn't seem sensible to try and combine this with the performance
data as for smaller environments where memory matters it is probably
quantised.

vi) What attacks count?  Well if there's a reasonable attack, i.e.
anything not completely trivial, then that version would probably not
be touched with a barge-pole so we can just look at the next secure
level up from that and go from there.


Peter Maxwell





2008/12/17 Thomas Pornin :
>
> On Wed, Dec 17, 2008 at 02:58:24AM -0500, D. J. Bernstein wrote:
>> What I'm advocating for SHA-3 is that we sort submissions according to
>> the efficiency of their fastest unbroken variants (which are what
>> cryptanalysts want to look at anyway), and then concentrate on the
>> most efficient submissions---let's say within a factor of 2 of the
>> current leader.
>
> There might be a slight difficulty here. Even assuming that we have
> "optimized enough" implementations to make speed measures meaningful,
> such measures will be specific to the used platform. Relative
> performance of hash functions may vary quite greatly when using a
> distinct architecture. Even if we concentrate on the "reference
> platform" (which may not be a good idea, depending on how significant we
> consider embedded systems with MiPS and ARM cores), then we have _two_
> architectures, with the i386 and amd64 modes. This is relevant to the
> comparison of two distinct algorithms, but also when deciding which
> variant of an algorithm is the fastest, when the algorithm has several
> tunable parameters which impact performance (e.g. CubeHash). The set of
> parameters which is "the fastest unbroken" on a given platform may be
> quite different on another.
>
> Of course we can get rough ideas of relative performance (e.g. Whirlpool
> is quite slower than SHA-1 on all architectures), but a "factor of 2"
> requires a precision of definition and measure which does not seem to be
> easily attainable. At least, so I think.
>
>
>        --Thomas Pornin
>
>

From hash-forum@nist.gov  Wed Dec 17 12:44:04 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBHKhvl8019545
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Dec 2008 12:43:59 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBHKhNh6009977;
	Wed, 17 Dec 2008 15:43:27 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBHKhCqD028361;
	Wed, 17 Dec 2008 15:43:12 -0500
Date: Wed, 17 Dec 2008 15:43:12 -0500
Message-Id: 
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: Stefan.Lucks@uni-weimar.de
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-ID: 
Content-Type: TEXT/PLAIN; charset=US-ASCII
MIME-Version: 1.0
References: <20081217075847.40461.qmail@cr.yp.to>  <49492644.5070305@csc.kth.se> 
In-Reply-To: 
X-To: Multiple recipients of list 
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 17 Dec 2008 12:44:00 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 422


I wrote

> This doesn't mean there is actually an attack on 24 rounds. But my 
> conclusion is that you cannot get any assurance of resistance against 
> theoretical or even practical collision attacks from that result.

For MD6 reduced to 24 rounds, that is.

Stefan


-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------


From hash-forum@nist.gov  Wed Dec 17 14:08:51 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBHM8jdW005057
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Dec 2008 14:08:46 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBHM8FFq009603;
	Wed, 17 Dec 2008 17:08:17 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBHM84hR007093;
	Wed, 17 Dec 2008 17:08:04 -0500
Date: Wed, 17 Dec 2008 17:08:04 -0500
Message-Id: <4949774c.0c07560a.54e9.ffffaaa0@mx.google.com>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "Danilo Gligoroski" 
To: Multiple recipients of list 
Subject: RE: cryptanalysis of Twister
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Mailer: Microsoft Office Outlook 12.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
In-Reply-To: <7.0.1.0.2.20081217114130.05d85568@nist.gov>
References: <493562.48430.qm@web36407.mail.mud.yahoo.com>  <7.0.1.0.2.20081217114130.05d85568@nist.gov>
X-To: 
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 17 Dec 2008 14:08:46 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 423


Rene Peralta wrote:

> My initial reaction is that there is an interesting 
> point being made here. But I would not go so far as 
> to simply dismiss all collision attacks for which 
> MEMORY * TIME is greater than 2^(n/2) or preimage 
> attacks for which MEMORY * TIME is greater than 2^n.
>
> Regards, Rene.


Yes. This is normal scientific approach - not to easily dismiss
any new idea, any new attack. I think that almost everybody on 
this forum shares this view. The problems start when we want to 
be more precise.

Namely, if the attack has MEMORY * TIME greater than 2^n, and we 
want to consider that the attack has still value and it can be 
considered as a better attack than brute force attack, 
how much greater than 2^n the MEMORY * TIME can be? 

2^(n+\epsilon), where \epsilon is very close to zero?

2^(n+const), where const is bigger than 1?

2^(const * n) where const>1?

2^(const * n) where const>4/3?

???

Regards,
Danilo Gligoroski



From hash-forum@nist.gov  Wed Dec 17 14:36:37 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBHMaWwk011675
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Dec 2008 14:36:33 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBHMa9M5030491;
	Wed, 17 Dec 2008 17:36:10 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBHMZnHU028925;
	Wed, 17 Dec 2008 17:35:49 -0500
Date: Wed, 17 Dec 2008 17:35:49 -0500
Message-Id: <49497BB1.7080901@csc.kth.se>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: =?UTF-8?B?RG91Z2xhcyBXaWtzdHLDtm0=?= 
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8; format=flowed
In-Reply-To: 
References: <20081217075847.40461.qmail@cr.yp.to>  <49492644.5070305@csc.kth.se> 
MIME-Version: 1.0
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 17 Dec 2008 14:36:33 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 424



> Dan suggested "24-round MD6, running at a quite reasonable 7 cycles/byte". 
> I agree with him that 7 cycles/byte would be quite reasonable.
> 
> But when I try to extrapolite the results from the table for 24 rounds, 
> the bound on the workload becomes more or less negligible. I bet, the 
> bound is well below 2^{24}. Even if the analysis happens to be quite 
> un-tight (looks plausible), what is the conclusion for 24 rounds of MD6?
 >
> This doesn't mean there is actually an attack on 24 rounds. But my 
> conclusion is that you cannot get any assurance of resistance against 
> theoretical or even practical collision attacks from that result.

24 may be stretching it, but provable security for larger number of 
rounds sounds like a "good" handwaving argument, but I am not an expert 
on hash functions, so this may well be naive :-)


Best regards,

Douglas Wikström

From hash-forum@nist.gov  Wed Dec 17 15:45:26 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBHNjLfo026040
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Dec 2008 15:45:22 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBHNiptq030640;
	Wed, 17 Dec 2008 18:44:52 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBHNibGM002535;
	Wed, 17 Dec 2008 18:44:37 -0500
Date: Wed, 17 Dec 2008 18:44:37 -0500
Message-Id: <49498E19.2070907@iaik.tugraz.at>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: =?ISO-8859-1?Q?Martin_Schl=E4ffer?= 
To: Multiple recipients of list 
Subject: Re: cryptanalysis of Twister
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060500000209060204040103"
In-Reply-To: 
References: <493562.48430.qm@web36407.mail.mud.yahoo.com>  <7.0.1.0.2.20081217114130.05d85568@nist.gov> 
MIME-Version: 1.0
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 17 Dec 2008 15:45:22 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 425


This is a cryptographically signed message in MIME format.

--------------ms060500000209060204040103
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Dmitry Khovratovich wrote:
> There is a difference between time and computations.

To be more precise (and continue the example):

An attack which takes 2^(.3n) time on 2^(.3n) parallel machines needs
together 2^(.6n) hash function *computations* and is thus, worse than a
generic attack.

However, an attack which needs 2^(.3n) hash function computations but
2^(.3n) memory is (in some sense) better than a generic attack, since
there is no generic attack for all hash functions with only 2^(.3n) hash
function computations.

It is of course a weaker attack than time*memory=2^(.3n). But still an
attack which does not apply to SHA-2 and can show a possible weakness in
a SHA-3 candidate.

Regards,
Martin

--------------ms060500000209060204040103
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIbEDCC
BLMwggOboAMCAQICARYwDQYJKoZIhvcNAQEFBQAwQTEQMA4GA1UEChMHRXVyb1BLSTEtMCsG
A1UEAxMkRXVyb1BLSSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTIyODA5
NTA1MloXDTEwMTIzMTExNTkwMFowUjELMAkGA1UEBhMCQVQxEDAOBgNVBAoTB0V1cm9QS0kx
MTAvBgNVBAMTKEV1cm9QS0kgQXVzdHJpYW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1hZUNUa0lyv5ttAn7ZRyfI4zO+Bc2fmTi
lpAIBfJ/2yqfdHKCd/r2czeCme85S298uhCrDtKZXQp6wZpxGsZrZw5n8mrXVVy6HUTFTyKa
pz/4W3vS0f3fKljpUioJ9lBUwQyARDcNzCP63+Iv9OqrHgb4QoSfmDlrX5KmaGDaEgoNYbkY
wFDn0b81I16j8mXDDECtQM/ZsxzjkHZz1ks3jl/q9EW1OxdD6ytgsePXzfmfWjdwsB8KyjXI
UNpLMBzPK3qTjwevGUQjfCCJ1hC26t2G9BWPcHUUw0/4gCL/jGDLUAmMWo1z1H/gyk9VrTsU
uP3HZ7fElMpfqmIqyr69AgMBAAGjggGjMIIBnzBMBglghkgBhvhCAQ0EPxY9SXNzdWVkIHVu
ZGVyIHBvbGljeToKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzBk
BggrBgEFBQcBAQRYMFYwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwLmV1cm9wa2kub3JnOjgw
MjYwKgYIKwYBBQUHMAKGHmh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdDA7BgNVHR8E
NDAyMDCgLqAshipodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3JsL2NybC5kZXIw
TgYDVR0gBEcwRTBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93d3cuZXVy
b3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzAdBgNVHQ4EFgQUdCnYUa/CPJin1/8xj0D3UOgH
AegwHwYDVR0jBBgwFoAUjNyLsaVKkOdOiHMYPJ3VXn7kss0wDAYDVR0TBAUwAwEB/zAOBgNV
HQ8BAf8EBAMCAfYwDQYJKoZIhvcNAQEFBQADggEBALvbHv34QJkgCzJ92trxCWkGmeahGFQ8
ZQCFlgeaAI5d2B8K9XVJ7IduoETxq+evWfDaiUBHahQ6c2oC9uhuqI4pzJpsEJimYpccHRBA
85S5spyfLfpboY1lSGraFxZwTsV9+wGftlCOZy3UF9Ip0VLP1wrRsTvfCBjLybj45ay3L3o5
F+MojQ2VPC0w/z56yD9caU+fl2pJSU7Q5fUlUfYD0PexVzDEWX4r3lGn6G5UD/zC8zNqH7fh
sJxsH/TeraHbvUk8AZu4IULWzrpytR7JpOX/VRfeF65foy7GoTkBuGPx9EsbXJzZ/ygab947
O5yIAqr6bibMh7i1ZDcpnacwggU3MIIEH6ADAgECAgcCQt/N+2FTMA0GCSqGSIb3DQEBBQUA
MFIxCzAJBgNVBAYTAkFUMRAwDgYDVQQKEwdFdXJvUEtJMTEwLwYDVQQDEyhFdXJvUEtJIEF1
c3RyaWFuIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA4MDIyODE1MTgwNVoXDTEzMDIy
ODE1MTgwNVowgb0xLTArBgNVBAMTJEV1cm9QS0kgSUFJSyBDZXJ0aWZpY2F0aW9uIEF1dGhv
cml0eTEmMCQGA1UEChMdR3JheiBVbml2ZXJzaXR5IG9mIFRlY2hub2xvZ3kxSDBGBgNVBAsT
P0luc3RpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21t
dW5pY2F0aW9uczENMAsGA1UEBxMER3JhejELMAkGA1UEBhMCQVQwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQCVatVA1TczvPSG2IZoIPtEBXNgZSdUx58syuOEoZs9HOc0MocB
2ko3jIDfB9YIP7bLEag1yjrlO8GxfkBCiTQvnfNDEIMvetuwJmHSgaTxJ3PRlOWDJMi/IbNe
X1yq2sOYyszpbK5/jm6JAl/XbYNmNuiPxx2PR3iVZBL4v38sF7o0x/ale5P7RmW4KXq36Mpc
/KaAW4cMrDUAGNqcc9EIwkTAx1moGt8u7v/CTgWIilXbhB1BBBjp+Cy9ukBX+HnwimWlAcKF
DTqmwFmgJA+QlCEQYHs0o2ylWF+41N8MivLlYqvqQlpOFqWStBpKr8lxkcjpFRzFry2ORWlK
16+bAgMBAAGjggGkMIIBoDAOBgNVHQ8BAf8EBAMCAcYwDwYDVR0TAQH/BAUwAwEB/zAdBgNV
HQ4EFgQUOXTH3cjx+wpwPQ7KfUUCrKGb154wVgYDVR0gBE8wTTBLBgwrBgEEAZUSAQIBAQEw
OzA5BggrBgEFBQcCARYtaHR0cDovL2V1cm9wa2kuaWFpay5hdC9jYS9ldXJvcGtpLWF0L2Nw
cy8xLjEvMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jYS5pYWlrLnR1Z3Jhei5hdC9jYXBz
by9jcmxzL0V1cm9QS0lBdXN0cmlhbi5jcmwwgZoGCCsGAQUFBwEBBIGNMIGKMEIGCCsGAQUF
BzABhjZodHRwOi8vY2EuaWFpay50dWdyYXouYXQvY2Fwc28vT0NTUD9jYT1FdXJvUEtJQXVz
dHJpYW4wRAYIKwYBBQUHMAKGOGh0dHA6Ly9jYS5pYWlrLnR1Z3Jhei5hdC9jYXBzby9jZXJ0
cy9FdXJvUEtJQXVzdHJpYW4uY2VyMB8GA1UdIwQYMBaAFHQp2FGvwjyYp9f/MY9A91DoBwHo
MA0GCSqGSIb3DQEBBQUAA4IBAQCmsYc+Rdrfd3sV8jqDipRkd/BGEwGFiWydTmEMRimyr2Sm
qNVX4khjAEyLcVjyYK+Fc+XREwOttYcKQHFKaRZRDby0RvniwP3LX1Du3xXnEHij9oB6A2aE
Tg1ouAnCikXQQ4C3eBfM9vaK9VR0k/akaqKzTTPBl8ao7TmOfTTdIBrVSoPYjeXR/qm1A34n
Pb0gR5sBMEZEcZgDN2oKSDsrK2bHp7AG36R/AtnGyW4j1hI5hR35VCmAToz4dbUKhZjDFJU+
FgmANAWh0+AetShQ7qpS6IyHXxdDGYW/7SHbwWsi4pmRnRm/xaYLVCo3zRJDwaXq3JlKOh2V
if4IFzAgMIIFgDCCBGigAwIBAgIHA0DrJxk2fDANBgkqhkiG9w0BAQUFADCBvTEtMCsGA1UE
AxMkRXVyb1BLSSBJQUlLIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSYwJAYDVQQKEx1HcmF6
IFVuaXZlcnNpdHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/SW5zdGl0dXRlIGZvciBBcHBs
aWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMQ0wCwYDVQQH
EwRHcmF6MQswCQYDVQQGEwJBVDAeFw0wODAyMjgxNTQ0MTdaFw0xMzAyMjgxNTQ0MTdaMIGs
MRwwGgYDVQQDExNFdXJvUEtJIElBSUsgU2lnIENBMSYwJAYDVQQKEx1HcmF6IFVuaXZlcnNp
dHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/SW5zdGl0dXRlIGZvciBBcHBsaWVkIEluZm9y
bWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMQ0wCwYDVQQHEwRHcmF6MQsw
CQYDVQQGEwJBVDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALBs2U2/lTXnomXh
gNULWkAXS507A6UtmsbrAIXXK7XIWgyjbKiYASrdej0LPKGuFtxbZ+A/e1cSV8yrCWsB+4s8
jZwL+xbWeXIGcaKarv0npeXSqX0UZl7DM5mVID+FwG1T73qjmIGvE6i5qDnNEv0siGeit7m0
AH3dF2uckq6eKuozAvchlJOQk27PqaPRFCS5APiCNBrB9AUShjXMHso1wC1raxlsGDc/yneC
2Z4OOBZLkswPIMu0qUwVfGVR7u3WFLEP3cPXw8lWb1Ka8GzGLBivt4PRz+wyibDfWx/i/Snh
TzfEuB4y1PFjvsFQ3o3am2zHpqvy1WPfUsxRLQ0CAwEAAaOCAZIwggGOMA4GA1UdDwEB/wQE
AwIBxjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSu7lUGF3pTERMYq6TOHHEJGoMU8zBQ
BgNVHSAESTBHMEUGDCsGAQQBlRIBAgMBATA1MDMGCCsGAQUFBwIBFidodHRwOi8vZXVyb3Br
aS5pYWlrLmF0L2NhL2lhaWsvY3BzLzEuMy8wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2Nh
LmlhaWsudHVncmF6LmF0L2NhcHNvL2NybHMvRXVyb1BLSUlBSUsuY3JsMIGSBggrBgEFBQcB
AQSBhTCBgjA+BggrBgEFBQcwAYYyaHR0cDovL2NhLmlhaWsudHVncmF6LmF0L2NhcHNvL09D
U1A/Y2E9RXVyb1BLSUlBSUswQAYIKwYBBQUHMAKGNGh0dHA6Ly9jYS5pYWlrLnR1Z3Jhei5h
dC9jYXBzby9jZXJ0cy9FdXJvUEtJSUFJSy5jZXIwHwYDVR0jBBgwFoAUOXTH3cjx+wpwPQ7K
fUUCrKGb154wDQYJKoZIhvcNAQEFBQADggEBAAgys3wJ2CixcC8KuuO3a9k8u0nT0+PafLR9
wMQMWsz7xDTLNxiTJKnLvdFw86D+CH+nXxRweo/KDVYT56q5rfKs45I6mZDV+z/wecNX3odW
MuY5a6j0g/RR4Qz/wokfeUzff5Yi6Hh1P9ce0u3/EHAHancJI3FxoZpLU5qNWZNo+fI6nluO
BmdJCWZgCR9ijucmFubnu4EbWlyhiH2e0H2taU6zWvW/83yqbEO0BhDKVWWVtWvlF/ptBZQE
JzAD1q5XJobPNQ/IANfs5ZcfuC1+Pm6FEG0cMVnDCGlRoA57oTIFaODWQPr4gxMy11/MYe9V
ufBih5AU1z6V4IwJ5SYwggXJMIIEsaADAgECAgcDAK1qvxKLMA0GCSqGSIb3DQEBBQUAMIGs
MRwwGgYDVQQDExNFdXJvUEtJIElBSUsgRW5jIENBMSYwJAYDVQQKEx1HcmF6IFVuaXZlcnNp
dHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/SW5zdGl0dXRlIGZvciBBcHBsaWVkIEluZm9y
bWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMQ0wCwYDVQQHEwRHcmF6MQsw
CQYDVQQGEwJBVDAeFw0wODEwMDcxNzQwMThaFw0xMTEwMDcxNzQwMThaMIHQMQ8wDQYDVQQq
EwZNYXJ0aW4xEzARBgNVBAQMClNjaGzDpGZmZXIxGjAYBgNVBAMMEU1hcnRpbiBTY2hsw6Rm
ZmVyMSYwJAYDVQQKEx1HcmF6IFVuaXZlcnNpdHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/
SW5zdGl0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11
bmljYXRpb25zMQ0wCwYDVQQHEwRHcmF6MQswCQYDVQQGEwJBVDCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAOJQuKfmW0nN4oYRLNQd8IARYTrZ7xYC2E1CXTA8ruvZNqgmDjjY
Yb31crA23mku3iUEiwEPZkuYlrTWRfxMZqNfDiEiMnQSpGoEt6OkMysOJqUbcr2KFxU61RYV
EFV47KpQODvSDJMJM7+w42j1sOOR7s774pVYi7TTyw02h2q4h00ANSaWfYVNEEuZ6LDe+IGl
YCcPkEPY/wf8tolxk2FhofovqkmbowfUd33ltNr4pA5NVcjcXiAlHT1TWHP9Y5fBlOPtSmZz
jhETQLZ04mzC54Fro20GrkC4gdfdx/gbfwFMxhs5gpi9VI13X+odzNXlnAdNQ5t6CThfvxlz
1JsCAwEAAaOCAcgwggHEMA4GA1UdDwEB/wQEAwIEMDAMBgNVHRMBAf8EAjAAMB0GA1UdDgQW
BBSx9MiM/Nw02QE9n1EplP/rqwC/1DBQBgNVHSAESTBHMEUGDCsGAQQBlRIBAgMBATA1MDMG
CCsGAQUFBwIBFidodHRwOi8vZXVyb3BraS5pYWlrLmF0L2NhL2lhaWsvY3BzLzEuMy8wSAYD
VR0fBEEwPzA9oDugOYY3aHR0cDovL2NhLmlhaWsudHVncmF6LmF0L2NhcHNvL2NybHMvRXVy
b1BLSUlBSUtfRW5jLmNybDCBmgYIKwYBBQUHAQEEgY0wgYowQgYIKwYBBQUHMAGGNmh0dHA6
Ly9jYS5pYWlrLnR1Z3Jhei5hdC9jYXBzby9PQ1NQP2NhPUV1cm9QS0lJQUlLX0VuYzBEBggr
BgEFBQcwAoY4aHR0cDovL2NhLmlhaWsudHVncmF6LmF0L2NhcHNvL2NlcnRzL0V1cm9QS0lJ
QUlLX0VuYy5jZXIwKwYDVR0RBCQwIoEgbWFydGluLnNjaGxhZWZmZXJAaWFpay50dWdyYXou
YXQwHwYDVR0jBBgwFoAU3UP298kNEZZgTQSlVkIYEiSm2uowDQYJKoZIhvcNAQEFBQADggEB
ADuQrAi8V7RqDsYffIq3SdpAIDE8+qOFbEtN6wXp8m3cex5IahtW80ubRgcfKk3CweywWiD4
EXXnjgfCEB+YnrhAe0QuaS8bZ9pneaF8X6l9sZx2jpWuMB2XtYaEz7gs9XyB1npLOcLShkif
JGW/H6P2iiD55yq/GAKx3Qxs4rsdz/duzdadcmJSqKvqGPlwSHEJP7t249SIwtxkNhEwnnXZ
uNtCWzMF6C41xs+JbqaNFCbSCMLMsut5JL5KaEIqIdmX8SqUgLlFCl67I+xshxYlIgphQbDX
w1iSXpXWYk5dF5oYqXa3wT7IULRf5ZBAFqj177XN9ITqK4iNgcBsyOUwggXJMIIEsaADAgEC
AgcDUdAh4zGXMA0GCSqGSIb3DQEBBQUAMIGsMRwwGgYDVQQDExNFdXJvUEtJIElBSUsgU2ln
IENBMSYwJAYDVQQKEx1HcmF6IFVuaXZlcnNpdHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/
SW5zdGl0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11
bmljYXRpb25zMQ0wCwYDVQQHEwRHcmF6MQswCQYDVQQGEwJBVDAeFw0wODEwMDcxNzQ2MTVa
Fw0xMTEwMDcxNzQ2MTVaMIHQMQ8wDQYDVQQqEwZNYXJ0aW4xEzARBgNVBAQMClNjaGzDpGZm
ZXIxGjAYBgNVBAMMEU1hcnRpbiBTY2hsw6RmZmVyMSYwJAYDVQQKEx1HcmF6IFVuaXZlcnNp
dHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/SW5zdGl0dXRlIGZvciBBcHBsaWVkIEluZm9y
bWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMQ0wCwYDVQQHEwRHcmF6MQsw
CQYDVQQGEwJBVDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALam7BWLO3AmmIP2
TyKPAwMgtFV+BO0pnAH4LFGn7hsISDmPOyQnwOayzZIe52EAuxGzd1WB0aGQwVnViEBjRFwB
vB2wi9neXzVYNuCQfC1o08RTS2UBVMNjr5RtkLqo9+ST1LlTeGhrsBccUMbPGpKFO+T2yl/y
2RV8M0N5ahMINo7uSWRHZ/rKO4JC+9QHUebmvGhvBevDxX41BkfgtNKPWCyXE+ZlOxmRvYEF
WDnm7ntjuyFzshNGtE7iNOu3pttwsfNpK1549qD7cZb9V5RS8FSWw4wYGtLpfNDYuDVYiJLD
fqYUXPSPfEIM2W8/HaHA5u19IGgHzVo1rdqpr1sCAwEAAaOCAcgwggHEMA4GA1UdDwEB/wQE
AwIGwDAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBT0LqYC5aKGOecwt+JXWgDeIAfAhjBQBgNV
HSAESTBHMEUGDCsGAQQBlRIBAgMBATA1MDMGCCsGAQUFBwIBFidodHRwOi8vZXVyb3BraS5p
YWlrLmF0L2NhL2lhaWsvY3BzLzEuMy8wSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NhLmlh
aWsudHVncmF6LmF0L2NhcHNvL2NybHMvRXVyb1BLSUlBSUtfU2lnLmNybDCBmgYIKwYBBQUH
AQEEgY0wgYowQgYIKwYBBQUHMAGGNmh0dHA6Ly9jYS5pYWlrLnR1Z3Jhei5hdC9jYXBzby9P
Q1NQP2NhPUV1cm9QS0lJQUlLX1NpZzBEBggrBgEFBQcwAoY4aHR0cDovL2NhLmlhaWsudHVn
cmF6LmF0L2NhcHNvL2NlcnRzL0V1cm9QS0lJQUlLX1NpZy5jZXIwKwYDVR0RBCQwIoEgbWFy
dGluLnNjaGxhZWZmZXJAaWFpay50dWdyYXouYXQwHwYDVR0jBBgwFoAUru5VBhd6UxETGKuk
zhxxCRqDFPMwDQYJKoZIhvcNAQEFBQADggEBAK3lES8Ob0WLsEYKPlBfOpTsJ1JrVFxvMpP/
eJubeSmQGcXuOMU1mcUF3Pquuv1Uk/BcIXLXmLZCuwBAAzrXUYxnvUpO47oG6RZXTjipwayw
pnjs34ik3vf9pyAW8u6BFtZNHK+MoFqNH+Oo/LLwkh1AeAt9umErGYJUCtLyghEVr4vQmRC1
0LT/ZJUXycb5ij/nXCRxrJf8S3tVtVTDuegf+6nQcRiqE5ps4gL7BUFRnpyGdgnyK/fpxQqN
TDI9HMMk8MuepIQgaltrKjvmcvcBsK3L2CvcTNGn7spVVvsmTJrX8hYHPK79/XgHatQqnAaK
naYDyjvCdJ28hxxliegxggQ8MIIEOAIBATCBuDCBrDEcMBoGA1UEAxMTRXVyb1BLSSBJQUlL
IFNpZyBDQTEmMCQGA1UEChMdR3JheiBVbml2ZXJzaXR5IG9mIFRlY2hub2xvZ3kxSDBGBgNV
BAsTP0luc3RpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBD
b21tdW5pY2F0aW9uczENMAsGA1UEBxMER3JhejELMAkGA1UEBhMCQVQCBwNR0CHjMZcwCQYF
Kw4DAhoFAKCCAlgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN
MDgxMjE3MjM0MTEzWjAjBgkqhkiG9w0BCQQxFgQU108XyelZLzQVt3HEHrDHMylYZB0wXwYJ
KoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA
MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHJBgkrBgEEAYI3EAQx
gbswgbgwgawxHDAaBgNVBAMTE0V1cm9QS0kgSUFJSyBFbmMgQ0ExJjAkBgNVBAoTHUdyYXog
VW5pdmVyc2l0eSBvZiBUZWNobm9sb2d5MUgwRgYDVQQLEz9JbnN0aXR1dGUgZm9yIEFwcGxp
ZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxDTALBgNVBAcT
BEdyYXoxCzAJBgNVBAYTAkFUAgcDAK1qvxKLMIHLBgsqhkiG9w0BCRACCzGBu6CBuDCBrDEc
MBoGA1UEAxMTRXVyb1BLSSBJQUlLIEVuYyBDQTEmMCQGA1UEChMdR3JheiBVbml2ZXJzaXR5
IG9mIFRlY2hub2xvZ3kxSDBGBgNVBAsTP0luc3RpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1h
dGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczENMAsGA1UEBxMER3JhejELMAkG
A1UEBhMCQVQCBwMArWq/EoswDQYJKoZIhvcNAQEBBQAEggEAoiLOngkHqzK4Fjj/+OITRpx+
YSIobaLhhfRhboLZd/3kEjL6Rh4l8QRUOUwIhrn5UsUs88aE94X2Uoxq7cm3RD2rD30SuYh+
qf+53dy6GM7SOshbhmUthQ4SE5jT2bm8GSLkxEd8Ifd28VYgKgsKmFoZOiyc5XDedN1/nw71
QE9bVBcGpWFHT4ytjLRQI4L9KU7v01p8SWkJByuPCHqJRqazg9dTfJk6I4UgIyPp5DG4CLj+
iuZh8VPAQRFfS5dVURH13ymQyW1wd6An/FMS+2NHK5wJvJOATRyjcBbArMg56RKEDFPhcFSW
vFN6PR+vhoBxsWKDRJfi5BZliCt3wQAAAAAAAA==
--------------ms060500000209060204040103--

From hash-forum@nist.gov  Wed Dec 17 17:23:33 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBI1NR2n019848
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Dec 2008 17:23:29 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBI1KA8n009987;
	Wed, 17 Dec 2008 20:20:10 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBI1JqVa024716;
	Wed, 17 Dec 2008 20:19:52 -0500
Date: Wed, 17 Dec 2008 20:19:52 -0500
Message-Id: <346c1ee6c1e5b07155d0669106ae7c8e.squirrel@webmail.ics.mq.edu.au>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: scontini@ics.mq.edu.au
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;charset=iso-8859-1
MIME-Version: 1.0
X-To: hash-forum@nist.gov
References: <20081217075847.40461.qmail@cr.yp.to>
In-Reply-To: <20081217075847.40461.qmail@cr.yp.to>
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 17 Dec 2008 17:23:29 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 426


Dan Bernstein writes:

> What I'm advocating for SHA-3 is that we sort submissions according to
> the efficiency of their fastest unbroken variants (which are what
> cryptanalysts want to look at anyway), and then concentrate on the most
> efficient submissions---let's say within a factor of 2 of the current
> leader.


That sounds reasonable if your goal was to come up with the fastest
algorithm that nobody knows how to break.  On the other hand, some have
decided that the burden is upon them to mathematically prove their design
has properties that make it resistant to the types of attacks that
have succeeded against other hash functions.  This is a change of
paradigm: switching from "nobody knows how to break it" to "I can
prove that these types of attacks will not work".  I personally find
the latter designs much more intriguing (including MD6 and Fugue, but
let's also not overlook SWIFFTX which has an asymptotic security reduction).
I strongly recommend against making decisions on what goes to the next
round based upon the fastest unbroken variants only (FWIW, I have not
looked at how the mentioned algorithms compare in djb's recommended metric).
Unfortunately, it is very hard to find an objective set of rules
that everybody will be happy with.

Note that Rijndael not only has great engineering properties, but it
also came with mathematical proofs of some type of resistance to
differential and linear attacks.  What a wonderful AES we have!

Scott



From hash-forum@nist.gov  Wed Dec 17 18:04:20 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBI24EcZ027654
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Dec 2008 18:04:15 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBI20sRK009694;
	Wed, 17 Dec 2008 21:00:55 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBI20hJ4005763;
	Wed, 17 Dec 2008 21:00:43 -0500
Date: Wed, 17 Dec 2008 21:00:43 -0500
Message-Id: <39c307da0812171758m388173e1l9e27306d6ac9c0ca@mail.gmail.com>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "Souradyuti Paul" 
To: Multiple recipients of list 
Subject: Re: cryptanalysis of Twister
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
References: <493562.48430.qm@web36407.mail.mud.yahoo.com> 
Content-Type: multipart/alternative;  boundary="----=_Part_12532_5156275.1229565518590"
MIME-Version: 1.0
In-Reply-To: 
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 17 Dec 2008 18:04:15 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 427


------=_Part_12532_5156275.1229565518590
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Jonathan,

Actually, it is of pivotal importance to be aware of generic trade-off
attacks in order to evaluate the merits of an algorithm-specific attack.
If the complexities of an algorithm-specific-attack lies on any trade-off
curve or "above", it is probably not significant as it is no better than a
generic attack. In that regard, the Pollard rho technique for finding
collision turns out to be interesting.

1. Is that a generic collision finding attack? By "generic" I mean that it
works for ANY hash function. Note that there is a difference between "ANY"
(or ALL) and "a randomly chosen hash function from a set of all hash
functions" (or a random oracle). I know of a Pollard-rho-based algorithm
which finds collision with T=3D2^{n/2} and M=3D1, that considers the hash
function to be a randomly chosen one. There exist hash functions for which
it fails to find a collision with the same complexities (that is,
with T=3D2^{n/2} and M=3D1). (I shall try to elaborate on the issue after a
short while.)

2. On the other hand, there is a GENERIC collision finding attack whose
complexities are related by the trade-off curve TM=3D2^n where
2^n>T>2^{n/2}. This works for ANY hash function.


3. Coming back to Pollard rho.

The Pollard-rho-based algorithm (that I know of) to find a collision is as
follows (details are excluded). It is a straight forward application of the
Pollard-rho technique.

1. Take a randomly chosen input to the hash function. Store the output.
2. Feed the output again as input to the hash function (pad the output with
a random string so that it's size equals the input size). The output forms
the least significant bits of the next input.
3. Do the above step for two runs: one is running twice as fast as the
other. Call the faster one HARE and the slower one TORTOISE.
4. Store the values of the current outputs for those two runs.
5. Stop when there is a collision on the outputs of the two runs.
6. To find the colliding inputs (1) start from the initial point and (2)
advance the TORTOISE.

Now I try to construct a counter-example where the above algorithm is unabl=
e
find a collision with T=3D2^{n/2} and M=3D1. If I'm right then it is not a
generic attack like the one referred to in point 2.

Suppose that the input and the output size of the hash function are m+n
bits and n bits. The hash value =3DLOW (n)+ 1 mod 2^n.  LOW(n) is the decim=
al
representation of the least significant n bits of the input.

 Now note that, on ANY chosen input as the starting point, the Pollard-rho
finds collision after cycling through 2^n steps. Therefore, for this
particular hash function, Pollard rho works with T=3D2^{n} and M=3D1. In
contrast, the attack mentioned in point 2 works for ALL hash functions
including this one with T=3D2^{n/2} and M=3D2^{n/2}.

I'm having a feeling that, for any Pollard-rho based collision finding
algorithm one designs, it may be able to find a hash function which cannot
be attacked by it (this is certainly a strong statement; Maybe I'm just
woefully wrong!!)

It is possible that there exists a different algorithm based on Pollard-rho
which works for ALL hash functions with T=3D2^{n/2} and M=3D1.

If you know of such algorithm please let me know.

Thanks,
Soura

Dr. Souradyuti Paul

Computer Security Division,
National Inst. of Standards and Technology,
Department of Commerce, Govt. of the US,
100 Bureau Drive, Stop 8930,
Gaithersburg, Maryland, 20899-8930,
The United States.
Tel No. +1-301-975-3195
Fax No.+1-301-975-8670

Web: http://www.esat.kuleuven.be/~psourady

On Wed, Dec 17, 2008 at 10:33 AM, Jonathan Katz  wrote:

> The "textbook" birthday attack requires time *and* space 2^{n/2}.
>
> There is a modified birthday attack that takes time 2^{n/2} and O(1) spac=
e.
> I don't have the original reference (perhaps Pollard?), but it is describ=
ed
> starting on page 132 of the textbook "Introduction to Modern Cryptography=
"
> by myself and Lindell.
>
> I don't see how there can be a generic collision attack with time better
> than 2^{n/2}. (Actually, I believe 2^{n/2} is a lower bound for finding
> collisions in a random function.)
>
>
> On Wed, 17 Dec 2008, Peter wrote:
>
> I believe O'Neil is referring to a "birthday attack". Correct me if I am
>> wrong, but I was under the impression that a birthday attack takes 2^n/2
>> time at 2^0 memory, and 2^0 time at 2^n/2. I believe the trade off is 2^=
x
>> time and 2^y memory where x+y =3D n/2.
>>
>> --Peter
>>
>> --- On Wed, 12/17/08, Rene Peralta  wrote:
>> From: Rene Peralta 
>> Subject: Re: cryptanalysis of Twister
>> To: "Multiple recipients of list" 
>> Date: Wednesday, December 17, 2008, 9:07 AM
>>
>>
>> Hi Sean,
>>
>> You and others have made this argument regarding several posted
>> attacks. If I understand correctly, what you are saying is that a
>> collision attack for which TIME*MEMORY is greater than 2^(n/2)
>> is worse that some well-known generic attack. A similar argument
>> has been made on this list regarding pre-image attacks.
>>
>> Can you point me to a reference to this generic attack? Also, any
>> references to a rationale for use of a TIME*MEMORY metric in this
>> context would be greatly appreciated.
>>
>> Thanks in advance, Rene.
>>
>> P.S. I am aware of standard time-memory tradeoff techniques, but I
>> don't see the connection to the unqualified use of a TIME*MEMORY
>> metric.
>>
>> At 12:57 PM 12/13/2008, Sean O'Neil wrote:
>>
>> On 12 Dec 2008, at 16:59, Martin Schl=E4ffer wrote:
>>>
>>> The attack can be extended to a theoretical collision attack on the
>>>> hash function Twister-512 with a complexity of about 2^231.5 with
>>>> different time-memory tradeoffs.
>>>>
>>>
>>> You mean with complexity of about 2^231.5 operations multiplied by
>>> 2^172.7 memory? Wouldn't those 2^160 circuits find a collision in
>>> 2^96 time for any hash? It is so tempting to omit that annoying
>>> memory requirement, isn't it? And then before you know it, the hash
>>> is declared "broken". I am not saying that the cryptanalysis
>>>
>> itself
>>
>>> is not valuable or that pseudo-collisions in 2^26.5 operations is not
>>> a potentially serious threat. I just find it increasingly annoying
>>> having to check every single paper for the fine print to see if it is
>>> actually cheaper than the brute-force or other generic attacks or if
>>> the authors "forgot" to mention memory the size of our galaxy.
>>>
>> And a
>>
>>> lot of people just read the announcement and trust the experts. They
>>> see 2^231.5 < 2^256, they assume that it's broken and the word
>>> spreads...
>>>
>>> Best regards,
>>> Sean O'Neil
>>> http://www.enrupt.com/ - Raising the bar.
>>>
>>>
>>>
>>
>>
>>
>>


--=20
*****************************************
******************************************

------=_Part_12532_5156275.1229565518590
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


Hi Jonathan,


 


Actually, it is of pivotal importance to be aware of generic trade-off=
 attacks in order to evaluate the merits of an algorithm-specific=
 attack. If the complexities of an algorithm-specific-attack lies=
 on any trade-off curve or "above", it is probably not =
significant as it is no better than a generic attack. In that regard, =
the Pollard rho technique for finding collision turns out to be i=
nteresting. 



 


1. Is that a generic collision finding attack? By "generic" =
I mean that it works for ANY hash function. Note that there is a difference=
 between "ANY" (or ALL) and "a randomly chosen hash fun=
ction from a set of all hash functions" (or a random oracle).&nbs=
p;I know of a Pollard-rho-based algorithm which finds collision with T=
=3D2^{n/2} and M=3D1, that considers the hash function to be a ra=
ndomly chosen one. There exist hash functions for which it fails to&nb=
sp;find a collision with the same complexities (that is, with T=3D2^{n=
/2} and M=3D1). (I shall try to elaborate on the issue after a short w=
hile.)



 


2. On the other hand, there is a GENERIC collision finding attack=
 whose complexities are related by the trade-off curve TM=3D2^n where =
2^n>T>2^{n/2}. This works for ANY hash function. 


 


     


3. Coming back to Pollard rho. 


 


The Pollard-rho-based algorithm (that I know of) to find a collision i=
s as follows (details are excluded). It is a straight forward applicat=
ion of the Pollard-rho technique. 


 


1. Take a randomly chosen input to the hash function. Store the output=



2. Feed the output again as input to the hash function (pad =
the output with a random string so that it's size equals the =
input size). The output forms the least significant bits of the next input.=



3. Do the above step for two runs: one is running twice as f=
ast as the other. Call the faster one HARE and the slow=
er one TORTOISE. 


4. Store the values of the current outputs for those two runs.


5. Stop when there is a collision on the outputs of the two runs.

6. To find the colliding inputs (1) start from the initial p=
oint and (2) advance the TORTOISE.  


 


Now I try to construct a counter-example where the above alg=
orithm is unable find a collision with T=3D2^{n/2} and M=3D1. If =
I'm right then it is not a generic attack like the one referred to in p=
oint 2. 


 


Suppose that the input and the output size of the hash function&n=
bsp;are m+n bits and n bits. The hash value =3DLOW (n)+ 1 mod 2^n.&nbs=
p; LOW(n) is the decimal representation of the least significant n bit=
s of the input.        



 


 Now note that, on ANY chosen input as the starting poi=
nt, the Pollard-rho finds collision after cycling through 2^n steps. Theref=
ore, for this particular hash function, Pollard rho works with T=3D2^{n} an=
d M=3D1. In contrast, the attack mentioned in point 2 works for A=
LL hash functions including this one with T=3D2^{n/2} and M=3D2^{n/2}.=
 



 


I'm having a feeling that, for any Pollard-rho based collisio=
n finding algorithm one designs, it may be able to find a ha=
sh function which cannot be attacked by it (this is certainly a strong stat=
ement; Maybe I'm just woefully wrong!!)



 


It is possible that there exists a different algorithm based=
 on Pollard-rho which works for ALL hash functions with T=3D2^{n/2} an=
d M=3D1.  


 


If you know of such algorithm please let me know.


 


Thanks,


Soura


 



 


On Wed, Dec 17, 2008 at 10:33 AM, Jonathan Katz =
<jkatz@cs.umd.edu> wrote:


The "textbook" birthda=
y attack requires time *and* space 2^{n/2}.

There is a modified birt=
hday attack that takes time 2^{n/2} and O(1) space. I don't have the or=
iginal reference (perhaps Pollard?), but it is described starting on page 1=
32 of the textbook "Introduction to Modern Cryptography" by mysel=
f and Lindell.


I don't see how there can be a generic collision attack with time b=
etter than 2^{n/2}. (Actually, I believe 2^{n/2} is a lower bound for findi=
ng collisions in a random function.)=20







On Wed, 17 Dec 2008, Peter wrote:



I believe O'Neil is referrin=
g to a "birthday attack". Correct me if I am wrong, but I was und=
er the impression that a birthday attack takes 2^n/2 time at 2^0 memory, an=
d 2^0 time at 2^n/2. I believe the trade off is 2^x time and 2^y memory whe=
re x+y =3D n/2.


--Peter

--- On Wed, 12/17/08, Rene Peralta <peralta@nist.gov> wrote:
Fro=
m: Rene Peralta <p=
eralta@nist.gov>

Subject: Re: cryptanalysis of Twister
To: "Multiple recipients of l=
ist" <hash=
-forum@nist.gov>
Date: Wednesday, December 17, 2008, 9:07 AM
<=
br>

Hi Sean,

You and others have made this argument regarding severa=
l posted
attacks. If I understand correctly, what you are saying is that=
 a
collision attack for which TIME*MEMORY is greater than 2^(n/2)

is worse that some well-known generic attack. A similar argument
has bee=
n made on this list regarding pre-image attacks.

Can you point me to=
 a reference to this generic attack? Also, any
references to a rationale=
 for use of a TIME*MEMORY metric in this

context would be greatly appreciated.

Thanks in advance, Rene.
P.S. I am aware of standard time-memory tradeoff techniques, but I
don=
't see the connection to the unqualified use of a TIME*MEMORY
metric=



At 12:57 PM 12/13/2008, Sean O'Neil wrote:



On 12 Dec 2008, at 16:59, Martin=
 Schl=E4ffer wrote:



The attack can be extended to a =
theoretical collision attack on the
hash function Twister-512 with a com=
plexity of about 2^231.5 with

different time-memory tradeoffs.

You mean with complexi=
ty of about 2^231.5 operations multiplied by
2^172.7 memory? Wouldn'=
t those 2^160 circuits find a collision in
2^96 time for any hash? It is=
 so tempting to omit that annoying

memory requirement, isn't it? And then before you know it, the hash
=
is declared "broken". I am not saying that the cryptanalysis
<=
/blockquote>itself


is not valuable or that pseudo-c=
ollisions in 2^26.5 operations is not
a potentially serious threat. I ju=
st find it increasingly annoying

having to check every single paper for the fine print to see if it is
ac=
tually cheaper than the brute-force or other generic attacks or if
the a=
uthors "forgot" to mention memory the size of our galaxy.


And a


lot of people just read the anno=
uncement and trust the experts. They
see 2^231.5 < 2^256, they assume=
 that it's broken and the word

spreads...

Best regards,
Sean O'Neil
http://www.enrupt.com/ - Raising the ba=
r.











-- 
************************************=
*****
******************************************


------=_Part_12532_5156275.1229565518590--

From hash-forum@nist.gov  Wed Dec 17 18:18:19 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBI2IDTf030708
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Dec 2008 18:18:14 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBI2EptQ002492;
	Wed, 17 Dec 2008 21:14:51 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBI2Ebiq000680;
	Wed, 17 Dec 2008 21:14:37 -0500
Date: Wed, 17 Dec 2008 21:14:37 -0500
Message-Id: <39c307da0812171812t563ced42p6652be9f2d586398@mail.gmail.com>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "Souradyuti Paul" 
To: Multiple recipients of list 
Subject: Re: cryptanalysis of Twister
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
References: <493562.48430.qm@web36407.mail.mud.yahoo.com> 
Content-Type: multipart/alternative;  boundary="----=_Part_12606_3728199.1229566326061"
MIME-Version: 1.0
In-Reply-To: 
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 17 Dec 2008 18:18:14 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 428


------=_Part_12606_3728199.1229566326061
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Jonathan,

Actually, it is of pivotal importance to be aware of generic trade-off
attacks in order to evaluate the merits of an algorithm-specific attack. If
the complexities of an algorithm-specific-attack lie on any trade-off curve
or "above", it is probably not significant as it is no better than a generi=
c
attack. In that regard, the Pollard rho technique for finding collision
turns out to be interesting.

1. Is that a generic collision finding attack? By "generic" I mean that it
works for ANY hash function. Note that there is a difference between "ANY"
(or ALL) and "a randomly chosen hash function from a set of all hash
functions" (or a random oracle). I know of a Pollard-rho-based algorithm
which finds collision with T=3D2^{n/2} and M=3D1, that considers the hash
function to be a randomly chosen one. There exist hash functions for which
it fails to find a collision with the same complexities (that is, with
T=3D2^{n/2} and M=3D1). (I shall try to elaborate on the issue after a shor=
t
while.)

2. On the other hand, there is a GENERIC collision finding attack whose
complexities are related by the trade-off curve TM=3D2^n where 2^n>T>2^{n/2=
}.
This works for ANY hash function.


3. Coming back to Pollard rho.

The Pollard-rho-based algorithm (that I know of) to find a collision is as
follows (details are excluded). It is a straight forward application of the
Pollard-rho technique.

1. Take a randomly chosen input to the hash function. Store the output.
2. Feed the output again as input to the hash function (pad the output with
a random string so that it's size equals the input size). The output forms
the least significant bits of the next input.
3. Do the above step for two runs: one is running twice as fast as the
other. Call the faster one HARE and the slower one TORTOISE.
4. Store the values of the current outputs for those two runs.
5. Stop when there is a collision on the outputs of the two runs.
6. To find the colliding inputs (1) start from the initial point and (2)
advance the TORTOISE.

Now I try to construct a counter-example where the above algorithm is unabl=
e
find a collision with T=3D2^{n/2} and M=3D1. If I'm right then it is not a
generic attack like the one referred to in point 2.

Suppose that the input and the output size of the hash function are m+n bit=
s
and n bits. The hash value =3DLOW (n)+ 1 mod 2^n.  LOW(n) is the decimal
representation of the least significant n bits of the input.

 Now note that, on ANY chosen input as the starting point, the Pollard-rho
finds collision after cycling through 2^n steps. Therefore, for this
particular hash function, Pollard rho works with T=3D2^{n} and M=3D1. In
contrast, the attack mentioned in point 2 works for ALL hash functions
including this one with T=3D2^{n/2} and M=3D2^{n/2}.

I'm having a feeling that, for any Pollard-rho based collision finding
algorithm one designs, it may be able to find a hash function which cannot
be attacked by it (this is certainly a strong statement; Maybe I'm just
woefully wrong!!)

It is possible that there exists a different algorithm based on Pollard-rho
which works for ALL hash functions with T=3D2^{n/2} and M=3D1.

If you know of such algorithm please let me know.

Thanks,
Soura

Dr. Souradyuti Paul

Computer Security Division,
National Inst. of Standards and Technology,
Department of Commerce, Govt. of the US,
100 Bureau Drive, Stop 8930,
Gaithersburg, Maryland, 20899-8930,
The United States.
Tel No. +1-301-975-3195
Fax No.+1-301-975-8670

Web: http://www.esat.kuleuven.be/~psourady

- Hide quoted text -

On Wed, Dec 17, 2008 at 10:33 AM, Jonathan Katz  wrote:

The "textbook" birthday attack requires time *and* space 2^{n/2}.

There is a modified birthday attack that takes time 2^{n/2} and O(1) space.
I don't have the original reference (perhaps Pollard?), but it is described
starting on page 132 of the textbook "Introduction to Modern Cryptography"
by myself and Lindell.

I don't see how there can be a generic collision attack with time better
than 2^{n/2}. (Actually, I believe 2^{n/2} is a lower bound for finding
collisions in a random function.)


On Wed, 17 Dec 2008, Peter wrote:


I believe O'Neil is referring to a "birthday attack". Correct me if I am
wrong, but I was under the impression that a birthday attack takes 2^n/2
time at 2^0 memory, and 2^0 time at 2^n/2. I believe the trade off is 2^x
time and 2^y memory where x+y =3D n/2.

--Peter

--- On Wed, 12/17/08, Rene Peralta  wrote:
From: Rene Peralta 
Subject: Re: cryptanalysis of Twister
To: "Multiple recipients of list" 
Date: Wednesday, December 17, 2008, 9:07 AM


Hi Sean,

You and others have made this argument regarding several posted
attacks. If I understand correctly, what you are saying is that a
collision attack for which TIME*MEMORY is greater than 2^(n/2)
is worse that some well-known generic attack. A similar argument
has been made on this list regarding pre-image attacks.

Can you point me to a reference to this generic attack? Also, any
references to a rationale for use of a TIME*MEMORY metric in this
context would be greatly appreciated.

Thanks in advance, Rene.

P.S. I am aware of standard time-memory tradeoff techniques, but I
don't see the connection to the unqualified use of a TIME*MEMORY
metric.

At 12:57 PM 12/13/2008, Sean O'Neil wrote:


On 12 Dec 2008, at 16:59, Martin Schl=E4ffer wrote:


The attack can be extended to a theoretical collision attack on the
hash function Twister-512 with a complexity of about 2^231.5 with
different time-memory tradeoffs.


You mean with complexity of about 2^231.5 operations multiplied by
2^172.7 memory? Wouldn't those 2^160 circuits find a collision in
2^96 time for any hash? It is so tempting to omit that annoying
memory requirement, isn't it? And then before you know it, the hash
is declared "broken". I am not saying that the cryptanalysis

itself

is not valuable or that pseudo-collisions in 2^26.5 operations is not
a potentially serious threat. I just find it increasingly annoying
having to check every single paper for the fine print to see if it is
actually cheaper than the brute-force or other generic attacks or if
the authors "forgot" to mention memory the size of our galaxy.

And a

lot of people just read the announcement and trust the experts. They
see 2^231.5 < 2^256, they assume that it's broken and the word
spreads...

On Wed, Dec 17, 2008 at 10:33 AM, Jonathan Katz  wrote:

> The "textbook" birthday attack requires time *and* space 2^{n/2}.
>
> There is a modified birthday attack that takes time 2^{n/2} and O(1) spac=
e.
> I don't have the original reference (perhaps Pollard?), but it is describ=
ed
> starting on page 132 of the textbook "Introduction to Modern Cryptography=
"
> by myself and Lindell.
>
> I don't see how there can be a generic collision attack with time better
> than 2^{n/2}. (Actually, I believe 2^{n/2} is a lower bound for finding
> collisions in a random function.)
>
>
> On Wed, 17 Dec 2008, Peter wrote:
>
> I believe O'Neil is referring to a "birthday attack". Correct me if I am
>> wrong, but I was under the impression that a birthday attack takes 2^n/2
>> time at 2^0 memory, and 2^0 time at 2^n/2. I believe the trade off is 2^=
x
>> time and 2^y memory where x+y =3D n/2.
>>
>> --Peter
>>
>> --- On Wed, 12/17/08, Rene Peralta  wrote:
>> From: Rene Peralta 
>> Subject: Re: cryptanalysis of Twister
>> To: "Multiple recipients of list" 
>> Date: Wednesday, December 17, 2008, 9:07 AM
>>
>>
>> Hi Sean,
>>
>> You and others have made this argument regarding several posted
>> attacks. If I understand correctly, what you are saying is that a
>> collision attack for which TIME*MEMORY is greater than 2^(n/2)
>> is worse that some well-known generic attack. A similar argument
>> has been made on this list regarding pre-image attacks.
>>
>> Can you point me to a reference to this generic attack? Also, any
>> references to a rationale for use of a TIME*MEMORY metric in this
>> context would be greatly appreciated.
>>
>> Thanks in advance, Rene.
>>
>> P.S. I am aware of standard time-memory tradeoff techniques, but I
>> don't see the connection to the unqualified use of a TIME*MEMORY
>> metric.
>>
>> At 12:57 PM 12/13/2008, Sean O'Neil wrote:
>>
>> On 12 Dec 2008, at 16:59, Martin Schl=E4ffer wrote:
>>>
>>> The attack can be extended to a theoretical collision attack on the
>>>> hash function Twister-512 with a complexity of about 2^231.5 with
>>>> different time-memory tradeoffs.
>>>>
>>>
>>> You mean with complexity of about 2^231.5 operations multiplied by
>>> 2^172.7 memory? Wouldn't those 2^160 circuits find a collision in
>>> 2^96 time for any hash? It is so tempting to omit that annoying
>>> memory requirement, isn't it? And then before you know it, the hash
>>> is declared "broken". I am not saying that the cryptanalysis
>>>
>> itself
>>
>>> is not valuable or that pseudo-collisions in 2^26.5 operations is not
>>> a potentially serious threat. I just find it increasingly annoying
>>> having to check every single paper for the fine print to see if it is
>>> actually cheaper than the brute-force or other generic attacks or if
>>> the authors "forgot" to mention memory the size of our galaxy.
>>>
>> And a
>>
>>> lot of people just read the announcement and trust the experts. They
>>> see 2^231.5 < 2^256, they assume that it's broken and the word
>>> spreads...
>>>
>>> Best regards,
>>> Sean O'Neil
>>> http://www.enrupt.com/ - Raising the bar.
>>>
>>>
>>>
>>
>>
>>
>>


--=20
*****************************************
Dr. Souradyuti Paul

Computer Security Division,
National Inst. of Standards and Technology,
Department of Commerce, Govt. of the US,
100 Bureau Drive, Stop 8930,
Gaithersburg, Maryland, 20899-8930,
The United States.
Tel No. +1-301-975-3195
Fax No.+1-301-975-8670

Web: http://www.esat.kuleuven.be/~psourady
******************************************

------=_Part_12606_3728199.1229566326061
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


Hi Jonathan,
 
Actually, it is of pivotal importance to be aw=
are of generic trade-off attacks in order to evaluate the merits of an algo=
rithm-specific attack. If the complexities of an algorithm-specific-attack =
lie on any trade-off curve or "above", it is probably not signifi=
cant as it is no better than a generic attack. In that regard, the Pollard =
rho technique for finding collision turns out to be interesting. 

 
1. Is that a generic collision finding attack? By "generic&q=
uot; I mean that it works for ANY hash function. Note that there is a diffe=
rence between "ANY" (or ALL) and "a randomly chosen hash fun=
ction from a set of all hash functions" (or a random oracle). I know o=
f a Pollard-rho-based algorithm which finds collision with T=3D2^{n/2} and =
M=3D1, that considers the hash function to be a randomly chosen one. There =
exist hash functions for which it fails to find a collision with the same c=
omplexities (that is, with T=3D2^{n/2} and M=3D1). (I shall try to elaborat=
e on the issue after a short while.)

 
2. On the other hand, there is a GENERIC collision finding attack=
 whose complexities are related by the trade-off curve TM=3D2^n where 2^n&g=
t;T>2^{n/2}. This works for ANY hash function. 
 
  =
;   
3. Coming back to Pollard rho. 

 
The Pollard-rho-based algorithm (that I know of) to find a collis=
ion is as follows (details are excluded). It is a straight forward applicat=
ion of the Pollard-rho technique. 
 
1. Take a randomly chosen i=
nput to the hash function. Store the output.

2. Feed the output again as input to the hash function (pad the output with=
 a random string so that it's size equals the input size). The output f=
orms the least significant bits of the next input.
3. Do the above step =
for two runs: one is running twice as fast as the other. Call the faster on=
e HARE and the slower one TORTOISE. 

4. Store the values of the current outputs for those two runs.
5. Stop w=
hen there is a collision on the outputs of the two runs.
6. To find the =
colliding inputs (1) start from the initial point and (2) advance the TORTO=
ISE.  

 
Now I try to construct a counter-example where the above algorith=
m is unable find a collision with T=3D2^{n/2} and M=3D1. If I'm right t=
hen it is not a generic attack like the one referred to in point 2. 
&nb=
sp;
Suppose that the input and the output size of the hash function are =
m+n bits and n bits. The hash value =3DLOW (n)+ 1 mod 2^n.  LOW(n) is =
the decimal representation of the least significant n bits of the input.&nb=
sp;       

 
 Now note that, on ANY chosen input as the starting point, t=
he Pollard-rho finds collision after cycling through 2^n steps. Therefore, =
for this particular hash function, Pollard rho works with T=3D2^{n} and M=
=3D1. In contrast, the attack mentioned in point 2 works for ALL hash funct=
ions including this one with T=3D2^{n/2} and M=3D2^{n/2}. 

 
I'm having a feeling that, for any Pollard-rho based collisio=
n finding algorithm one designs, it may be able to find a hash function whi=
ch cannot be attacked by it (this is certainly a strong statement; Maybe I&=
#39;m just woefully wrong!!)

 
It is possible that there exists a different algorithm based on P=
ollard-rho which works for ALL hash functions with T=3D2^{n/2} and M=3D1.&n=
bsp; 
 
If you know of such algorithm please let me know.
&nb=
sp;
Thanks,
Soura

 
Dr. Souradyuti Paul


Computer Security Division,
National Inst. of Standards and Technolog=
y,
Department of Commerce, Govt. of the US,
100 Bureau Drive, Stop 89=
30,
Gaithersburg, Maryland, 20899-8930,
The United States. 
Tel No=
 +1-301-975-3195

Fax No.+1-301-975-8670


Web: http://www.esat.k=
uleuven.be/~psourady


- Hide quoted text -
 
On Wed, Dec 17, 2008 at 10:33 AM, Jona=
than Katz <jkatz@cs.umd.edu> =
wrote:


The "textbook" birthday attack requires time *and* space 2^{n/=
2}.


There is a modified birthday attack that takes time 2^{n/2} and O(1) spa=
ce. I don't have the original reference (perhaps Pollard?), but it is d=
escribed starting on page 132 of the textbook "Introduction to Modern =
Cryptography" by myself and Lindell.



I don't see how there can be a generic collision attack with time be=
tter than 2^{n/2}. (Actually, I believe 2^{n/2} is a lower bound for findin=
g collisions in a random function.) 



On Wed, 17 Dec 2008, Peter wrote:



I believe O'Neil is referring to a "birthday attack". =
Correct me if I am wrong, but I was under the impression that a birthday at=
tack takes 2^n/2 time at 2^0 memory, and 2^0 time at 2^n/2. I believe the t=
rade off is 2^x time and 2^y memory where x+y =3D n/2.



--Peter


--- On Wed, 12/17/08, Rene Peralta <peralta@nist.gov> wrote:
From: Rene Peralta <peralta@nist.gov>
Subject: Re: cryptanalysi=
s of Twister

To: "Multiple recipients of list" <hash-forum@nist.gov>
Date: Wednesday, December 17, 20=
08, 9:07 AM



Hi Sean,


You and others have made this argument regarding several posted
attac=
ks. If I understand correctly, what you are saying is that a
collision a=
ttack for which TIME*MEMORY is greater than 2^(n/2)
is worse that some w=
ell-known generic attack. A similar argument

has been made on this list regarding pre-image attacks.


Can you point me to a reference to this generic attack? Also, any
ref=
erences to a rationale for use of a TIME*MEMORY metric in this
context w=
ould be greatly appreciated.


Thanks in advance, Rene.


P.S. I am aware of standard time-memory tradeoff techniques, but I
do=
n't see the connection to the unqualified use of a TIME*MEMORY
metri=
c.


At 12:57 PM 12/13/2008, Sean O'Neil wrote:



On 12 Dec 2008, at 16:59, Martin Schl=E4ffer wrote:



The attack can be extended to a theoretical collision attack on the<=
br>hash function Twister-512 with a complexity of about 2^231.5 with
dif=
ferent time-memory tradeoffs.



You mean with complexity of about 2^231.5 operations multiplied by2^172.7 memory? Wouldn't those 2^160 circuits find a collision in
=
2^96 time for any hash? It is so tempting to omit that annoying
memory r=
equirement, isn't it? And then before you know it, the hash

is declared "broken". I am not saying that the cryptanalysis


itself


is not valuable or that pseudo-collisions in 2^26.5 operations is nota potentially serious threat. I just find it increasingly annoying
havi=
ng to check every single paper for the fine print to see if it is
actual=
ly cheaper than the brute-force or other generic attacks or if

the authors "forgot" to mention memory the size of our galaxy.

And a


lot of people just read the announcement and trust the experts. They
=
see 2^231.5 < 2^256, they assume that it's broken and the word
sp=
reads...



On Wed, Dec 17, 2008 at 10:33 AM, Jonathan Katz =
<jkatz@cs.umd.edu<=
/a>> wrote:


The "textbook" birthda=
y attack requires time *and* space 2^{n/2}.

There is a modified birt=
hday attack that takes time 2^{n/2} and O(1) space. I don't have the or=
iginal reference (perhaps Pollard?), but it is described starting on page 1=
32 of the textbook "Introduction to Modern Cryptography" by mysel=
f and Lindell.


I don't see how there can be a generic collision attack with time b=
etter than 2^{n/2}. (Actually, I believe 2^{n/2} is a lower bound for findi=
ng collisions in a random function.)=20







On Wed, 17 Dec 2008, Peter wrote:



I believe O'Neil is referrin=
g to a "birthday attack". Correct me if I am wrong, but I was und=
er the impression that a birthday attack takes 2^n/2 time at 2^0 memory, an=
d 2^0 time at 2^n/2. I believe the trade off is 2^x time and 2^y memory whe=
re x+y =3D n/2.


--Peter

--- On Wed, 12/17/08, Rene Peralta <peralta@nist.gov> wrote:
Fro=
m: Rene Peralta <p=
eralta@nist.gov>

Subject: Re: cryptanalysis of Twister
To: "Multiple recipients of l=
ist" <hash=
-forum@nist.gov>
Date: Wednesday, December 17, 2008, 9:07 AM
<=
br>

Hi Sean,

You and others have made this argument regarding severa=
l posted
attacks. If I understand correctly, what you are saying is that=
 a
collision attack for which TIME*MEMORY is greater than 2^(n/2)

is worse that some well-known generic attack. A similar argument
has bee=
n made on this list regarding pre-image attacks.

Can you point me to=
 a reference to this generic attack? Also, any
references to a rationale=
 for use of a TIME*MEMORY metric in this

context would be greatly appreciated.

Thanks in advance, Rene.
P.S. I am aware of standard time-memory tradeoff techniques, but I
don=
't see the connection to the unqualified use of a TIME*MEMORY
metric=



At 12:57 PM 12/13/2008, Sean O'Neil wrote:



On 12 Dec 2008, at 16:59, Martin=
 Schl=E4ffer wrote:



The attack can be extended to a =
theoretical collision attack on the
hash function Twister-512 with a com=
plexity of about 2^231.5 with

different time-memory tradeoffs.

You mean with complexi=
ty of about 2^231.5 operations multiplied by
2^172.7 memory? Wouldn'=
t those 2^160 circuits find a collision in
2^96 time for any hash? It is=
 so tempting to omit that annoying

memory requirement, isn't it? And then before you know it, the hash
=
is declared "broken". I am not saying that the cryptanalysis
<=
/blockquote>itself


is not valuable or that pseudo-c=
ollisions in 2^26.5 operations is not
a potentially serious threat. I ju=
st find it increasingly annoying

having to check every single paper for the fine print to see if it is
ac=
tually cheaper than the brute-force or other generic attacks or if
the a=
uthors "forgot" to mention memory the size of our galaxy.


And a


lot of people just read the anno=
uncement and trust the experts. They
see 2^231.5 < 2^256, they assume=
 that it's broken and the word

spreads...

Best regards,
Sean O'Neil
http://www.enrupt.com/ - Raising the ba=
r.











-- 
************************************=
*****
Dr. Souradyuti Paul

Computer Security Division,
National=
 Inst. of Standards and Technology,
Department of Commerce, Govt. of the=
 US,

100 Bureau Drive, Stop 8930,
Gaithersburg, Maryland, 20899-8930,
The =
United States. 
Tel No. +1-301-975-3195
Fax No.+1-301-975-8670
Web: http://www.esat.kul=
euven.be/~psourady

******************************************


------=_Part_12606_3728199.1229566326061--

From hash-forum@nist.gov  Wed Dec 17 20:18:14 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBI4I9wj024765
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Dec 2008 20:18:10 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBI4HXJG011182;
	Wed, 17 Dec 2008 23:17:34 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBI4HMxG010051;
	Wed, 17 Dec 2008 23:17:22 -0500
Date: Wed, 17 Dec 2008 23:17:22 -0500
Message-Id: <01C7BB4C-5F17-4147-B728-5F48974A152C@cryptolib.com>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "Sean O'Neil" 
To: Multiple recipients of list 
Subject: Re: cryptanalysis of Twister
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Mailer: Apple Mail (2.753.1)
X-To: hash-forum@nist.gov
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
References: <493562.48430.qm@web36407.mail.mud.yahoo.com>  <39c307da0812171812t563ced42p6652be9f2d586398@mail.gmail.com>
In-Reply-To: <39c307da0812171812t563ced42p6652be9f2d586398@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v753.1)
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 17 Dec 2008 20:18:10 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 429


On 18 Dec 2008, at 03:14, Souradyuti Paul wrote:

> In contrast, the attack mentioned in point 2 works for ALL hash  
> functions including this one with T=2^{n/2} and M=2^{n/2}.


That is not a correct example. Pollard rho algorithm will only fail  
to find a solution for a bijective function with a guaranteed long  
period. The example you provided is such a function, and as such it  
actually has no collisions for a fixed set of m bits. Neither  
algorithm will find them for a fixed m. You must spread the output  
across the m and the n input bits randomly instead of fixing the m  
bits, in which case it will no longer be a bijective 'x+1 mod 2^n'  
function and Pollard rho will find those collisions in 2^{n/2} time.  
All the hash functions submitted to the SHA-3 competition are such  
"pseudorandom" functions without guaranteed long periods, so the  
success probability of Pollard rho algorithm for all of them is the  
same as of the generic look-up table search.

With best regards,
Sean O'Neil
http://www.enrupt.com/ - Raising the bar.


From hash-forum@nist.gov  Wed Dec 17 23:41:48 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBI7fhI5030742
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Dec 2008 23:41:44 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBI7f7Y8013543;
	Thu, 18 Dec 2008 02:41:08 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBI7etsu010212;
	Thu, 18 Dec 2008 02:40:55 -0500
Date: Thu, 18 Dec 2008 02:40:55 -0500
Message-Id: 
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: yaser esmaeilei 
To: Multiple recipients of list 
Subject: RE: Results on Tangle
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
MIME-Version: 1.0
References: <4948BDFB.4070804@win.dtu.dk>
In-Reply-To: <4948BDFB.4070804@win.dtu.dk>
X-CC: hash-function , hash-forum 
X-To: 
Content-Type: multipart/alternative; boundary="_a47ddf1d-41b5-4c2d-9187-4f0e5fa0c33e_"
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 17 Dec 2008 23:41:44 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,
	FORGED_HOTMAIL_RCVD2,HTML_MESSAGE,RCVD_IN_DNSWL_MED shortcircuit=no
	autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 430


--_a47ddf1d-41b5-4c2d-9187-4f0e5fa0c33e_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Dear S=F8ren=2C

I saw your paper entitled by "Untangled". It is completely true about the s=
imilar observations. However=2C I think that it can be used for a 2nd preim=
age attack on Tangle in special cases.=20

Kind regards=2C
Yaser

> Date: Wed=2C 17 Dec 2008 09:53:15 +0100
> From: ssth@win.dtu.dk
> To: yaser_esmaeilei@hotmail.com
> Subject: Results on Tangle
>=20
> Dear Yaser=2C
>=20
> I did not see your posting in the NIST hash-forum until after I had
> submitted my own public comment. The reason was that=2C unfortunately=2C
> your posting ended up in my spam filter. I am sorry about that=2C it seem=
s
> that we made similar observations=2C only I was able to use it to find
> collisions.
>=20
> Best regards=2C
> S=F8ren.
>=20
> --=20
> S=F8ren Steffen Thomsen
> PH.D. student
> DTU Mathematics
> -------------------------------
> Technical University of Denmark
> Department of Mathematics
> Matematiktorvet 303S
> Building 303S
> 2800  Kgs. Lyngby
> Direct +45 4525 3010
> Mobile +45 2290 5443
> S.Thomsen@mat.dtu.dk
> www.mat.dtu.dk/

_________________________________________________________________
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=3Dwindows+vista&mkt=3Den-US&form=3DQBR=
E=

--_a47ddf1d-41b5-4c2d-9187-4f0e5fa0c33e_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






Dear S=F8ren=2C

I saw your paper entitled by "Untangled". It =
is completely true about the similar observations. However=2C I think that =
it can be used for a 2nd preimage attack on Tangle in special cases. 
Kind regards=2C
Yaser

>=3B Date: Wed=2C 17 Dec 2008 09:53:15 =
+0100
>=3B From: ssth@win.dtu.dk
>=3B To: yaser_esmaeilei@hotmail=
com
>=3B Subject: Results on Tangle
>=3B 
>=3B Dear Yaser=
=2C
>=3B 
>=3B I did not see your posting in the NIST hash-forum =
until after I had
>=3B submitted my own public comment. The reason was=
 that=2C unfortunately=2C
>=3B your posting ended up in my spam filter=
 I am sorry about that=2C it seems
>=3B that we made similar observat=
ions=2C only I was able to use it to find
>=3B collisions.
>=3B <=
br>>=3B Best regards=2C
>=3B S=F8ren.
>=3B 
>=3B -- 
&g=
t=3B S=F8ren Steffen Thomsen
>=3B PH.D. student
>=3B DTU Mathemat=
ics
>=3B -------------------------------
>=3B Technical Universit=
y of Denmark
>=3B Department of Mathematics
>=3B Matematiktorvet =
303S
>=3B Building 303S
>=3B 2800  Kgs. Lyngby
>=3B Direct +=
45 4525 3010
>=3B Mobile +45 2290 5443
>=3B S.Thomsen@mat.dtu.dk<=
br>>=3B www.mat.dtu.dk/

Discover the new Windows Vista Learn more!
=

--_a47ddf1d-41b5-4c2d-9187-4f0e5fa0c33e_--

From hash-forum@nist.gov  Thu Dec 18 02:11:22 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBIABHiw013703
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Thu, 18 Dec 2008 02:11:18 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBIAAU3V009793;
	Thu, 18 Dec 2008 05:10:33 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBIAACQ8006199;
	Thu, 18 Dec 2008 05:10:12 -0500
Date: Thu, 18 Dec 2008 05:10:12 -0500
Message-Id: <87ocz9pzlk.fsf@mocca.josefsson.org>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: Simon Josefsson 
To: Multiple recipients of list 
Subject: Re: ASN.1 oids for SHA-3 submissions and PKCS1 RSA signatures?
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
In-Reply-To: <60667906-51C8-49A5-B143-89D82FB89EB5@mac.com> (Jeff Johnson's message of "Mon, 15 Dec 2008 12:33:45 -0500")
References: <051B5A02-38C0-4B65-9F66-D4F82BBAE10F@mac.com>  <60667906-51C8-49A5-B143-89D82FB89EB5@mac.com>
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 18 Dec 2008 02:11:18 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 431


Jeff Johnson  writes:

> On Dec 15, 2008, at 12:20 PM, Paul Hoffman wrote:
>
>>
>> At 11:22 AM -0500 12/15/08, Jeff Johnson wrote:
>>> Could (and more generally should) ASN.1 oids be defined for
>>> the SHA-3 candidate submissions for use by PKCS1 RSA digital
>>> signature padding?
>>>
>>> Some private oid in the hierarchy will certainly suffice for my
>>> insanities.
>>>
>>> But perhaps a interim/temporary oid definition is better than
>>> littering an
>>> already arcane hash algorithm name space, since the final SHA-3 
>>> choices
>>> will take a year or more to identify.
>>
>> For what do you need even temporary OIDs? Why would you be using any
>> of the candidates in protocols before significant analysis has been
>> done on them?
>>
>
> Please note "insanities", and that any oid will "work" for my purposes.

I've had similar thoughts, and when the process continues, I will want
to conduct tests with real-world applications.  Having an OID allocated
will be required at that point.  I've allocated a OID for SHA-3
candidate testing that I will use myself:

1.3.6.1.4.1.11591.4.3

Feel free to use the OID for your own SHA-3 tests.  I guarantee it won't
be allocated for any other purpose.

I considered allocating an OID for each candidate, which could be useful
to allow systematic tests of all candidates in the same software without
modifications between test runs.  However, then the problem becomes
which parameters should be associated with each hash?  Rather than
specifying OIDs for each hash variant, the hash could also require that
applications transfer some hash meta-data that embeds this information.
This application-transferred data may be required for some SHA-3
candidates already -- I haven't reviewed them all whether they use
application-specific initialization vectors, or similar, which where
discussed some time ago.

/Simon

From hash-forum@nist.gov  Thu Dec 18 06:03:55 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBIE3mZB005798
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Thu, 18 Dec 2008 06:03:49 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBIE2kHk020834;
	Thu, 18 Dec 2008 09:02:48 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBIE2UxU009753;
	Thu, 18 Dec 2008 09:02:30 -0500
Date: Thu, 18 Dec 2008 09:02:30 -0500
Message-Id: <6CA78BA8-77B1-4879-9588-C9D810251C01@nist.gov>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: Tim Polk 
To: Multiple recipients of list 
Subject: Re: ASN.1 oids for SHA-3 submissions and PKCS1 RSA signatures?
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Mailer: Apple Mail (2.753.1)
X-To: hash-forum@nist.gov
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Mime-Version: 1.0 (Apple Message framework v753.1)
References: <051B5A02-38C0-4B65-9F66-D4F82BBAE10F@mac.com>  <60667906-51C8-49A5-B143-89D82FB89EB5@mac.com>
In-Reply-To: <60667906-51C8-49A5-B143-89D82FB89EB5@mac.com>
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 18 Dec 2008 06:03:50 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-7.6 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 432


Jeff,

NIST does not intend to assign OIDs for all the candidate algorithms  
at this point.  It would probably be better
to use a private oid specifically allocated for testing to support  
any development work you wish to do at this point.

Substituting permanent oids in the future should not be difficult, as  
long as you don't box yourself in by presuming
the size of the encoded oid will be consistent with the test oid.   
(You might laugh, but stranger things have been
witnessed!)

You do have a point about this being a gating factor for deployment  
at some stage, but until we narrow the field
that is probably a feature.  We will need to think carefully about  
the "right time" - I am unsure if that is when we
narrow the field to approximately five, or when we make a selection.   
Either way, we have some time to sort this out!

In the meantime, there is a set of 80 oids that were set aside to  
support PKI testing.   These oids are supposed
to be used in X.509 certificates to represent certificate policies,  
but I guess they could be used in a lab environment
for any purpose.


> csor-test-policies OBJECT IDENTIFIER ::= { 2 16 840 1 101 3 2 1 48 }
>
> -- test policy OIDs
>
> test1 OBJECT IDENTIFIER ::= { csor-test-policies 1 }
> test2 OBJECT IDENTIFIER ::= { csor-test-policies 2 }
> test3 OBJECT IDENTIFIER; ::= { csor-test-policies 3 }
> test4 OBJECT IDENTIFIER ::= { csor-test-policies 4 }
> test5 OBJECT IDENTIFIER ::= { csor-test-policies 5 }
> test6 OBJECT IDENTIFIER ::= { csor-test-policies 6 }
> test7 OBJECT IDENTIFIER ::= { csor-test-policies 7 }
> test8 OBJECT IDENTIFIER ::= { csor-test-policies 8 }
> test9 OBJECT IDENTIFIER ::= { csor-test-policies 9 }
> test10 OBJECT IDENTIFIER ::= { csor-test-policies 10 }
>
> .  .   .
>
> test78 OBJECT IDENTIFIER ::= { csor-test-policies 78}
> test79 OBJECT IDENTIFIER ::= { csor-test-policies 79 }
> test80 OBJECT IDENTIFIER ::= { csor-test-policies 80 ]
>
>


Please don't publish them in any specifications or conference papers,  
though.  Any mappings you use internally
should stay that way to preclude having them hijacked for de facto  
adoption.  It should be sufficient to note that
you used oids from this arc to support testing, without publishing a  
mapping.

Hope that helps.

Tim Polk

On Dec 15, 2008, at 12:34 PM, Jeff Johnson wrote:


>
> On Dec 15, 2008, at 12:20 PM, Paul Hoffman wrote:
>
>
>>
>> At 11:22 AM -0500 12/15/08, Jeff Johnson wrote:
>>
>>> Could (and more generally should) ASN.1 oids be defined for
>>> the SHA-3 candidate submissions for use by PKCS1 RSA digital  
>>> signature padding?
>>>
>>> Some private oid in the hierarchy will certainly suffice for my  
>>> insanities.
>>>
>>> But perhaps a interim/temporary oid definition is better than  
>>> littering an
>>> already arcane hash algorithm name space, since the final SHA-3  
>>> choices
>>> will take a year or more to identify.
>>>
>>
>> For what do you need even temporary OIDs? Why would you be using  
>> any of the candidates in protocols before significant analysis has  
>> been done on them?
>>
>>
>
> Please note "insanities", and that any oid will "work" for my  
> purposes.
> My usage cases atm are with RSA and smartcard development,
> not with analysis. Perhaps off-topic here ...
>
> But the politics of getting *some* OID defined in implementations
> are glacially slow afaict. I merely attempted to suggest that
> an early, preemptive, conventional definition of ASN.1 oids would  
> improve
> rate of SHA-3 implementation adoption, not the quality of the  
> analysis,
> or of the hashes themselves.
>
> 73 de Jeff
>


From hash-forum@nist.gov  Thu Dec 18 14:41:43 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBIMfZIv000300
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Thu, 18 Dec 2008 14:41:37 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBIMf79h003686;
	Thu, 18 Dec 2008 17:41:08 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBIMer7r009924;
	Thu, 18 Dec 2008 17:40:54 -0500
Date: Thu, 18 Dec 2008 17:40:53 -0500
Message-Id: 
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: Charanjit Jutla 
To: Multiple recipients of list 
Subject: OFFICIAL COMMENT: Fugue
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: text/plain; charset="US-ASCII"
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
MIME-Version: 1.0
X-Cc: hash-forum@nist.gov
X-To: hash-function@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Thu, 18 Dec 2008 14:41:37 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 433


1.  We have updated figures for Fugue-256's performance on X86-64.

     An optimized ANSI C implementation (with NIST API included) runs at
 60 Mbytes/sec on a 2GHZ machine (E5335), i.e. 33 cycles/byte. Brian 
Gladman's 
 highly optimized  SHA-256 runs at 84 MB/sec on the same machine. Our
 implementation would be  25% faster if the L1 cache was twice as large. 
On 128 bit platforms, we expect  100% speed improvement. The submitted 
code
(which is not optimized) also runs at 55 MB/sec. We are not yet submitting 
the new
optimized code, but will change the numbers (according to 55 MB/sec impl) 
in the
PDF document being  re-submitted to NIST.

2. There were lots of typos in the PDF document submitted to NIST, 
including some
minor technical issues in the security proofs sections, in particular 
section 10. They
have all been fixed and will be resubmitted in the fresh PDF document. 
There is 
NO CHANGE in the SPECIFICATION section (not even a typo). While it is 
being updated
at NIST, if you are reading the document you should read the one on IBM's 
website:
 
http://domino.research.ibm.com/comm/research_projects.nsf/pages/fugue.index.html

Thanks,

Charanjit Jutla

From hash-forum@nist.gov  Fri Dec 19 04:13:30 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBJCDPYW012238
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Fri, 19 Dec 2008 04:13:26 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBJCCto2010549;
	Fri, 19 Dec 2008 07:12:56 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBJCCkfe015686;
	Fri, 19 Dec 2008 07:12:46 -0500
Date: Fri, 19 Dec 2008 07:12:46 -0500
Message-Id: 
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: v.klima@volny.cz
To: Multiple recipients of list 
Subject: =?iso-8859-2?Q?OFFICIAL_COMMENT:_Blender?=
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: multipart/mixed; boundary="=_0b64b6134f298a7ae7c20aab7b291609"
X-Mailer: Volny.cz Webmail2 2.117
X-Cc: hash-forum@nist.gov
X-To: hash-function@nist.gov
MIME-Version: 1.0
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 19 Dec 2008 04:13:26 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 434


--=_0b64b6134f298a7ae7c20aab7b291609
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi all,
in the enclosed paper we describe a near-collision attack (225/256 bits)on
BLENDER-256. It is also available on http://cryptography.hyperlink.cz/BMW/near_collision_blender.pdf

Best regards,
Vlastimil Klima


--=_0b64b6134f298a7ae7c20aab7b291609
Content-Type: application/pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="near_collision_blender.pdf"

JVBERi0xLjQNJeLjz9MNCjg5IDAgb2JqIDw8L0xpbmVhcml6ZWQgMS9MIDE3
ODg1L08gOTEvRSA3OTYxL04gMi9UIDE2MDU4L0ggWyA2MTYgMjMxXT4+DWVu
ZG9iag0gICAgICAgICAgICAgICAgICAgDQp4cmVmDQo4OSAxNg0KMDAwMDAw
MDAxNiAwMDAwMCBuDQowMDAwMDAxMDE3IDAwMDAwIG4NCjAwMDAwMDEyNzMg
MDAwMDAgbg0KMDAwMDAwMTUzNiAwMDAwMCBuDQowMDAwMDAxNTYwIDAwMDAw
IG4NCjAwMDAwMDE3MTAgMDAwMDAgbg0KMDAwMDAwMjA5OCAwMDAwMCBuDQow
MDAwMDAyNTY2IDAwMDAwIG4NCjAwMDAwMDI2MDEgMDAwMDAgbg0KMDAwMDAw
MjgzNCAwMDAwMCBuDQowMDAwMDAyOTEwIDAwMDAwIG4NCjAwMDAwMDQ5ODUg
MDAwMDAgbg0KMDAwMDAwNzY1NSAwMDAwMCBuDQowMDAwMDA3NzIxIDAwMDAw
IG4NCjAwMDAwMDA4NDcgMDAwMDAgbg0KMDAwMDAwMDYxNiAwMDAwMCBuDQp0
cmFpbGVyDQo8PC9TaXplIDEwNS9QcmV2IDE2MDQ3L1hSZWZTdG0gODQ3L1Jv
b3QgOTAgMCBSL0luZm8gMTMgMCBSL0lEWzw5RjI1MEQzOEMyM0M4MDlDMjgx
MzhCMjYxMzM0OEIxQz48RkZCNzgzNEZEMDU2QkQ0RkE1N0EzMTRENEY4OUQ0
NDQ+XT4+DQpzdGFydHhyZWYNCjANCiUlRU9GDQoNCjEwNCAwIG9iajw8L0xl
bmd0aCAxMzgvQyAxMzAvRmlsdGVyL0ZsYXRlRGVjb2RlL0kgMTU1L0wgMTE0
L1MgNjQ+PnN0cmVhbQ0KeNpiYGBgZmBgEWJgYWBg/cjAy4AAvEAxEOSYsLCC
gaETJJRSf3XeASDdwcDA1tEAEgYCoE4VZSDNA8QCYBEJBh6+DwzsD3OkD3Dz
Cpg0WIUxLbjBvKGa5UIVWJ6TgUHrB5BmAmIrIOZgYFADiTMCDQOJszGw/Luj
BXYCg80WiASjCECAAQC2gBgGDQplbmRzdHJlYW0NZW5kb2JqDTEwMyAwIG9i
ajw8L0xlbmd0aCAyMi9GaWx0ZXIvRmxhdGVEZWNvZGUvV1sxIDEgMV0vSW5k
ZXhbMTQgNzVdL0RlY29kZVBhcm1zPDwvQ29sdW1ucyAzL1ByZWRpY3RvciAx
Mj4+L1NpemUgODkvVHlwZS9YUmVmPj5zdHJlYW0NCnjaYmLiYGBiYGAcxYQx
QIABAJBgAOsNCmVuZHN0cmVhbQ1lbmRvYmoNOTAgMCBvYmo8PC9NYXJrSW5m
bzw8L0xldHRlcnNwYWNlRmxhZ3MgMC9NYXJrZWQgdHJ1ZT4+L01ldGFkYXRh
IDEyIDAgUi9QaWVjZUluZm88PC9NYXJrZWRQREY8PC9MYXN0TW9kaWZpZWQo
RDoyMDA4MTIxOTEzMDEwMCk+Pj4+L1BhZ2VzIDExIDAgUi9QYWdlTGF5b3V0
L09uZUNvbHVtbi9TdHJ1Y3RUcmVlUm9vdCAxNCAwIFIvVHlwZS9DYXRhbG9n
L0xhc3RNb2RpZmllZChEOjIwMDgxMjE5MTMwMTAwKS9QYWdlTGFiZWxzIDkg
MCBSPj4NZW5kb2JqDTkxIDAgb2JqPDwvQ3JvcEJveFswIDAgNTk1LjIyIDg0
Ml0vQW5ub3RzIDkyIDAgUi9QYXJlbnQgMTEgMCBSL1N0cnVjdFBhcmVudHMg
MC9Db250ZW50cyA5OSAwIFIvUm90YXRlIDAvTWVkaWFCb3hbMCAwIDU5NS4y
MiA4NDJdL1Jlc291cmNlczw8L0NvbG9yU3BhY2U8PC9DUzAgOTYgMCBSPj4v
Rm9udDw8L1RUMCA5NCAwIFIvVFQxIDk1IDAgUj4+L1Byb2NTZXRbL1BERi9U
ZXh0XS9FeHRHU3RhdGU8PC9HUzAgOTggMCBSPj4+Pi9UeXBlL1BhZ2U+Pg1l
bmRvYmoNOTIgMCBvYmpbOTMgMCBSXQ1lbmRvYmoNOTMgMCBvYmo8PC9SZWN0
WzcwLjg2IDcwOC4yMjcgMjYyLjgyOCA3MjUuMjcxXS9TdWJ0eXBlL0xpbmsv
QlM8PC9TL1MvVyAwL1R5cGUvQm9yZGVyPj4vQSAxMDEgMCBSL0gvSS9TdHJ1
Y3RQYXJlbnQgMS9Cb3JkZXJbMCAwIDBdL1R5cGUvQW5ub3Q+Pg1lbmRvYmoN
OTQgMCBvYmo8PC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDEw
MiAwIFIvTGFzdENoYXIgMTIwL1dpZHRoc1s2MDAgMCAwIDAgMCAwIDAgMCAw
IDAgMCAwIDAgNjAwIDAgMCAwIDAgNjAwIDAgMCA2MDAgNjAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgNjAwIDYwMCAwIDYwMCA2MDAgMCAwIDAgMCAwIDAgNjAw
IDAgNjAwIDAgMCAwIDYwMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg
NjAwIDAgNjAwIDAgNjAwIDAgMCAwIDYwMCAwIDYwMCA2MDAgNjAwIDYwMCA2
MDAgNjAwIDAgNjAwIDYwMCA2MDAgMCAwIDAgNjAwXS9CYXNlRm9udC9Db3Vy
aWVyTmV3UFMtQm9sZE1UL0ZpcnN0Q2hhciAzMi9FbmNvZGluZy9XaW5BbnNp
RW5jb2RpbmcvVHlwZS9Gb250Pj4NZW5kb2JqDTk1IDAgb2JqPDwvU3VidHlw
ZS9UcnVlVHlwZS9Gb250RGVzY3JpcHRvciA5NyAwIFIvTGFzdENoYXIgMTIy
L1dpZHRoc1s2MDAgMCA2MDAgMCAwIDAgMCAwIDYwMCA2MDAgMCAwIDYwMCA2
MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw
MCA2MDAgNjAwIDAgMCA2MDAgMCAwIDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2
MDAgMCA2MDAgNjAwIDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgMCA2MDAg
NjAwIDYwMCAwIDYwMCA2MDAgNjAwIDAgMCA2MDAgMCA2MDAgMCAwIDAgNjAw
IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgMCA2MDAgNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw
IDYwMCA2MDBdL0Jhc2VGb250L0NvdXJpZXJOZXdQU01UL0ZpcnN0Q2hhciAz
Mi9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvVHlwZS9Gb250Pj4NZW5kb2Jq
DTk2IDAgb2JqWy9JQ0NCYXNlZCAxMDAgMCBSXQ1lbmRvYmoNOTcgMCBvYmo8
PC9TdGVtViA0Mi9Gb250TmFtZS9Db3VyaWVyTmV3UFNNVC9Gb250U3RyZXRj
aC9Ob3JtYWwvRm9udFdlaWdodCA0MDAvRmxhZ3MgMzQvRGVzY2VudCAtMzAw
L0ZvbnRCQm94Wy0yMSAtNjgwIDYzOCAxMDIxXS9Bc2NlbnQgODMyL0ZvbnRG
YW1pbHkoQ291cmllciBOZXcpL0NhcEhlaWdodCA1NzgvWEhlaWdodCAtNTc4
L1R5cGUvRm9udERlc2NyaXB0b3IvSXRhbGljQW5nbGUgMD4+DWVuZG9iag05
OCAwIG9iajw8L09QTSAxL09QIGZhbHNlL29wIGZhbHNlL1R5cGUvRXh0R1N0
YXRlL1NBIGZhbHNlL1NNIDAuMDI+Pg1lbmRvYmoNOTkgMCBvYmo8PC9MZW5n
dGggMjAwNS9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImcV9uO2zgS
fTfQ/1DIU2fgpkndFQwG8HUm2M1isWNsHuJ+kGXa0rQsaSQ5Hefrt3iTpW7Z
2U43YNMUeVhV51SxNPmzjHL49dfJp/nHBVD47bfZYg4jCocRgxRGk9//xHE9
mq1Hk/WaAoP1fvRACaUUhzHuWD/jB6xrYFR8fxdTFTALv6n48ikJPPA9RlhA
bVgfR/dTyHlUPcRFlqV1WuQQNU0UPwGOZv9c/mux/M+D5Xrv13+NluvR8hPa
o0Fcn7gBWL5NPGDEgoqP9qNJzwVmXOhZTIWtF5tsxyHOC6Oge97k3y2g1Qdk
CpBhCDScHGkDnZBQ7weA9lsAbZ/4FvVvAjqDgJIkZkvHh7Etj9gBk9D/zaK6
SY9pBv/I0mM0hv5ZvQi75rjJHLUR1woYoI7z/8sl5hLq6BglTVN+mEzi6lw2
xaGKyuRMknPJqyzNn0j8fUADzCJWACxEZOIYCVyC4XUl3DOH3ggFtYlPf8Cb
/wbevNAiDguDm4DBz/HmBYzQAH8K7M8cntMsgx2v4yrdckh4xSG6nmBJVCew
P+Vxk17SDZ43d2mTSEMpPGBW2Ai/GN1jGj5s0waKU1OeGvjCHgmsk7Q2gDt+
LPK6qaKG14ienSEpnqEpgH8rswItKXIuUde/jO6fefSU87qGNIcm4cLm9JBD
scdfCNm3bB+hGs8ErgUvHAzeDY49x8fcZNZNShj9SU5sl/gBU3m6Rt+Mrx/g
c8Jz/AlxUhQ1l45nPD9gtKXjHI64LDrggqji+1OWncdiuQnaMc0xL79zeFdG
u12aH8awR8LloIyqGgcQ5TuIypLn4vm7HmgUx0Ulpjd3ghaDanhXsilFxAl8
zKE+xQmq5zk6K0OxKrRQ26xAxpGosipinOM72G7uzrjcoNbHCKWYn45bXgnv
quKU72rY3DtmKNS5eU+uhp+9IcfcUBQAWxN6FfIt9dv1Q8IcS9H4UamUf4uO
ZcY1hZrBfVp1IvMscqdDbIgImDW1JKbZ3CUXOmseFzgp0qLdVUdHDl+j7MTH
sMUsEw9F0tVJUTW8Im2WlhVHyjHTbAvpNJC2JVP0GXmu4fMX+jgmZPz5i80e
YV8Vx64cxnCSghnQkkG7oinDeX2du+F77UZGujZW3cBhtzPyJ28317KIS21P
gq+KqpcViqday71GwjxJ2Fiuup5pnai/iA+mhczUKJN51BXORS94bymWNveY
HahcPHNzV2/et6gX+iz/EZDri0D26MO2QMloJ2pRibkERNat4BF26X7PK1le
N3dNR3THAg8XtTbdp3GUN1Jdm3v8wOKAeioLkZtYHsSmOIlyDBGCmDi8k+tD
K9jcmdwVqN3Tw97pRsC7EzeoOjPUIp7H/GI9RqBz8SAT4uJB/dJHKUKlZMya
JkLoOOHxU3061qZ6Yk58TYtTrSMrdsTFKdvpo5Ax3PXqXovEIkEOogjir6va
fauqHcfGptK73Usw7+dU7diMBI7X3jO14auWYsEsLaMDXsY7c8fKCr4vTpWp
wOKSxgsmiRo4pF/FPhSLoVR0DXDpGmSFStJDIoC30TbN0uasiDvlRdnIiwkr
XJVGmViCDdxRHJZv7nb6WuiR+qIpQRNtKtLmpLoH0bYUDd8WxROq07Jc4H+f
EFmWUlnKsB0RCtRpOBTX4SbtBl126JMg8MMLXS/ecxQdyg8aSD+WOrOvGTHc
2N0ywncJdvnebc0Mtzw/1Izt2filWlF9k4zhD9FsRdmhqJDjoywuptczRXKX
oqya+up70XCrdMtLF0tyELi3X7eGW4Afe+ngC6ETKDc/aRfYuL2LP1w98C0N
gm2FJKSh6jkS/u066lve8mwWENcLFf1TF5kAy4GFCysbAh9WLnh4oa0gmGEB
gJkNLoPZAmZLWDkwozATDSh4VDzyGKxEqDFJ6HygoZ+DP4P5DMIl2CsIfcC3
HncBqxXMHMC72LVgxWBqCRV7DixtOW/DfA7zEOgC5h7MHURHRb1K8MAR2yga
7sPMB3w9w1cgcRgTnTWeZIfgi5c3mC5h6osDfBcW+E6JMxiTqTjGWSC6Hby2
HVdPbYG1QKstEQTXhXAq7BXHMFjOYTUT4bJ9YaM3hSkatAB7Ic5mc1gG4MwR
3aHtLeY6wpwQDbHAWgJ64K2QFghXovVYSPNxOcqSzsCdXuV7uE0Z5tvyGAlt
phJhm+ZRdb4upOEL6AqwS4kbMlXMGGWYMlSEXg5wsRmIGfzHR2KCyQGOqF4s
Z6h6RvX10ONZLBALQX7KbWo71YgSSJ4uD5OrgTIzMGd0oTXJEkav1kBMTQHV
z/pnqEdMIyrzKe1canIFVe4z5b42SZvPtGnKDzUCpp9pz3qIcrtyVv1pj4xF
VFrUuk9NQFVEgGqL+jZeXKN9RBNZqhkBplcDaz3T214iStc0kmKfds9X5Bln
jQx09PWpA+zr/ewSPuWZgqYK2kRNCUxG3wS9736ffRVYrUejFRUZJRqtJxMH
RlthKKsHItsNFjOGtOnQBp12/NBmmDi0iEMJOtzKDScos32CiR/oBL1kiBpo
+1lHNLQzo/lUZBkVs74wezwa0pUjHRnostDKwGi+5+wL0vVqrSdm9KjDrxXa
at4s1llEtQ5ukN5RKNP2Kz0xk2lU66G1w9Qw9kr82iKt4rZQmRCzq+X2zQ1k
QInn+/7rpuZ/AgwAW6iOOA0KZW5kc3RyZWFtDWVuZG9iag0xMDAgMCBvYmo8
PC9MZW5ndGggMjU3NS9GaWx0ZXIvRmxhdGVEZWNvZGUvTiAzL0FsdGVybmF0
ZS9EZXZpY2VSR0I+PnN0cmVhbQ0KSImclnlUU3cWx39vyZ6QlbDDYw1bgLAG
kDVsYZEdBFEISQgBEkJI2AVBRAUURUSEqpUy1m10Rk9FnS6uY60O1n3q0gP1
MOroOLQW146dFzhHnU5nptPvH+/3Ofd37+/d3733nfMAoCelqrXVMAsAjdag
z0qMxRYVFGKkCQADCiACEQAyea0uLTshB+CSxkuwWtwJ/IueXgeQab0iTMrA
MPD/iS3X6Q0AQBk4ByiUtXKcO3GuqjfoTPYZnHmllSaGURPr8QRxtjSxap69
53zmOdrECo1WgbMpZ51CozDxaZxX1xmVOCOpOHfVqZX1OF/F2aXKqFHj/NwU
q1HKagFA6Sa7QSkvx9kPZ7o+J0uC8wIAyHTVO1z6DhuUDQbTpSTVuka9WlVu
wNzlHpgoNFSMJSnrq5QGgzBDJq+U6RWYpFqjk2kbAZi/85w4ptpieJGDRaHB
wUJ/H9E7hfqvm79Qpt7O05PMuZ5B/AtvbT/nVz0KgHgWr836t7bSLQCMrwTA
8uZbm8v7ADDxvh2++M59+KZ5KTcYdGG+vvX19T5qpdzHVNA3+p8Ov0DvvM/H
dNyb8mBxyjKZscqAmeomr66qNuqxWp1MrsSEPx3iXx3483l4ZynLlHqlFo/I
w6dMrVXh7dYq1AZ1tRZTa/9TE39l2E80P9e4uGOvAa/YB7Au8gDytwsA5dIA
UrQN34He9C2Vkgcy8DXf4d783M8J+vdT4T7To1atmouTZOVgcqO+bn7P9FkC
AqACJuABK2APnIE7EAJ/EALCQTSIB8kgHeSAArAUyEE50AA9qActoB10gR6w
HmwCw2A7GAO7wX5wEIyDj8EJ8EdwHnwJroFbYBJMg4dgBjwFryAIIkEMiAtZ
QQ6QK+QF+UNiKBKKh1KhLKgAKoFUkBYyQi3QCqgH6oeGoR3Qbuj30FHoBHQO
ugR9BU1BD6DvoJcwAtNhHmwHu8G+sBiOgVPgHHgJrIJr4Ca4E14HD8Gj8D74
MHwCPg9fgyfhh/AsAhAawkccESEiRiRIOlKIlCF6pBXpRgaRUWQ/cgw5i1xB
JpFHyAuUiHJRDBWi4WgSmovK0Rq0Fe1Fh9Fd6GH0NHoFnUJn0NcEBsGW4EUI
I0gJiwgqQj2hizBI2En4iHCGcI0wTXhKJBL5RAExhJhELCBWEJuJvcStxAPE
48RLxLvEWRKJZEXyIkWQ0kkykoHURdpC2kf6jHSZNE16TqaRHcj+5ARyIVlL
7iAPkveQPyVfJt8jv6KwKK6UMEo6RUFppPRRxijHKBcp05RXVDZVQI2g5lAr
qO3UIep+6hnqbeoTGo3mRAulZdLUtOW0IdrvaJ/Tpmgv6By6J11CL6Ib6evo
H9KP07+iP2EwGG6MaEYhw8BYx9jNOMX4mvHcjGvmYyY1U5i1mY2YHTa7bPaY
SWG6MmOYS5lNzEHmIeZF5iMWheXGkrBkrFbWCOso6wZrls1li9jpbA27l72H
fY59n0PiuHHiOQpOJ+cDzinOXS7CdeZKuHLuCu4Y9wx3mkfkCXhSXgWvh/db
3gRvxpxjHmieZ95gPmL+ifkkH+G78aX8Kn4f/yD/Ov+lhZ1FjIXSYo3FfovL
Fs8sbSyjLZWW3ZYHLK9ZvrTCrOKtKq02WI1b3bFGrT2tM63rrbdZn7F+ZMOz
CbeR23TbHLS5aQvbetpm2TbbfmB7wXbWzt4u0U5nt8XulN0je759tH2F/YD9
p/YPHLgOkQ5qhwGHzxz+ipljMVgVNoSdxmYcbR2THI2OOxwnHF85CZxynTqc
DjjdcaY6i53LnAecTzrPuDi4pLm0uOx1uelKcRW7lrtudj3r+sxN4Jbvtspt
3O2+wFIgFTQJ9gpuuzPco9xr3Efdr3oQPcQelR5bPb70hD2DPMs9RzwvesFe
wV5qr61el7wJ3qHeWu9R7xtCujBGWCfcK5zy4fuk+nT4jPs89nXxLfTd4HvW
97VfkF+V35jfLRFHlCzqEB0Tfefv6S/3H/G/GsAISAhoCzgS8G2gV6AycFvg
n4O4QWlBq4JOBv0jOCRYH7w/+EGIS0hJyHshN8Q8cYa4V/x5KCE0NrQt9OPQ
F2HBYYawg2F/DxeGV4bvCb+/QLBAuWBswd0IpwhZxI6IyUgssiTy/cjJKMco
WdRo1DfRztGK6J3R92I8Yipi9sU8jvWL1cd+FPtMEiZZJjkeh8QlxnXHTcRz
4nPjh+O/TnBKUCXsTZhJDEpsTjyeREhKSdqQdENqJ5VLd0tnkkOSlyWfTqGn
ZKcMp3yT6pmqTz2WBqclp21Mu73QdaF24Xg6SJemb0y/kyHIqMn4QyYxMyNz
JPMvWaKslqyz2dzs4uw92U9zYnP6cm7luucac0/mMfOK8nbnPcuPy+/Pn1zk
u2jZovMF1gXqgiOFpMK8wp2Fs4vjF29aPF0UVNRVdH2JYEnDknNLrZdWLf2k
mFksKz5UQijJL9lT8oMsXTYqmy2Vlr5XOiOXyDfLHyqiFQOKB8oIZb/yXllE
WX/ZfVWEaqPqQXlU+WD5I7VEPaz+tiKpYnvFs8r0yg8rf6zKrzqgIWtKNEe1
HG2l9nS1fXVD9SWdl65LN1kTVrOpZkafot9ZC9UuqT1i4OE/UxeM7saVxqm6
yLqRuuf1efWHGtgN2oYLjZ6NaxrvNSU0/aYZbZY3n2xxbGlvmVoWs2xHK9Ra
2nqyzbmts216eeLyXe3U9sr2P3X4dfR3fL8if8WxTrvO5Z13Vyau3Ntl1qXv
urEqfNX21ehq9eqJNQFrtqx53a3o/qLHr2ew54deee8Xa0Vrh9b+uK5s3URf
cN+29cT12vXXN0Rt2NXP7m/qv7sxbePhAWyge+D7TcWbzg0GDm7fTN1s3Dw5
lPpPAKQBW/6YuJkkmZCZ/JpomtWbQpuvnByciZz3nWSd0p5Anq6fHZ+Ln/qg
aaDYoUehtqImopajBqN2o+akVqTHpTilqaYapoum/adup+CoUqjEqTepqaoc
qo+rAqt1q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx1rJLssKzOLOutCW0
nLUTtYq2AbZ5tvC3aLfguFm40blKucK6O7q1uy67p7whvJu9Fb2Pvgq+hL7/
v3q/9cBwwOzBZ8Hjwl/C28NYw9TEUcTOxUvFyMZGxsPHQce/yD3IvMk6ybnK
OMq3yzbLtsw1zLXNNc21zjbOts83z7jQOdC60TzRvtI/0sHTRNPG1EnUy9VO
1dHWVdbY11zX4Nhk2OjZbNnx2nba+9uA3AXcit0Q3ZbeHN6i3ynfr+A24L3h
ROHM4lPi2+Nj4+vkc+T85YTmDeaW5x/nqegy6LzpRunQ6lvq5etw6/vshu0R
7ZzuKO6070DvzPBY8OXxcvH/8ozzGfOn9DT0wvVQ9d72bfb794r4Gfio+Tj5
x/pX+uf7d/wH/Jj9Kf26/kv+3P9t//8CDAD3hPP7Cg0KZW5kc3RyZWFtDWVu
ZG9iag0xMDEgMCBvYmo8PC9VUkkoaHR0cDovL2NyeXB0b2dyYXBoeS5oeXBl
cmxpbmsuY3ovKS9TL1VSST4+DWVuZG9iag0xMDIgMCBvYmo8PC9TdGVtViAx
MDAvRm9udE5hbWUvQ291cmllck5ld1BTLUJvbGRNVC9Gb250U3RyZXRjaC9O
b3JtYWwvRm9udFdlaWdodCA3MDAvRmxhZ3MgMzQvRGVzY2VudCAtMzAwL0Zv
bnRCQm94Wy00NiAtNzEwIDcwMiAxMjIxXS9Bc2NlbnQgODMyL0ZvbnRGYW1p
bHkoQ291cmllciBOZXcpL0NhcEhlaWdodCA1OTMvWEhlaWdodCAtNTYyL1R5
cGUvRm9udERlc2NyaXB0b3IvSXRhbGljQW5nbGUgMD4+DWVuZG9iag0xIDAg
b2JqPDwvQ3JvcEJveFswIDAgNTk1LjIyIDg0Ml0vQW5ub3RzIDIgMCBSL1Bh
cmVudCAxMSAwIFIvU3RydWN0UGFyZW50cyAyL0NvbnRlbnRzIDMgMCBSL1Jv
dGF0ZSAwL01lZGlhQm94WzAgMCA1OTUuMjIgODQyXS9SZXNvdXJjZXM8PC9D
b2xvclNwYWNlPDwvQ1MwIDk2IDAgUj4+L0ZvbnQ8PC9UVDAgOTUgMCBSPj4v
UHJvY1NldFsvUERGL1RleHRdL0V4dEdTdGF0ZTw8L0dTMCA5OCAwIFI+Pj4+
L1R5cGUvUGFnZT4+DWVuZG9iag0yIDAgb2JqWzUgMCBSIDcgMCBSXQ1lbmRv
YmoNMyAwIG9iajw8L0xlbmd0aCAxMTc1L0ZpbHRlci9GbGF0ZURlY29kZT4+
c3RyZWFtDQpIiZyXXXPaRhSG75nJfziXSSdenbNfWnmSzICApjN1krF10Zm6
FxgEqDUfI4m69q/vrj4wBglbwQaW1e573pXOs0fyfsCnT95V+NsQEL58GQxD
6CEsegQJ9Lxfb2w76w2inhdFCATRvHeBDJEERFM7I3qwHxBlQOi+n1xXan8w
5LaJVctHZjT4mjPN0c5c9d5fxVk2WcTA4TPkyxjmSZrlEHANd0mewWYO1QiC
D9HfvVHUG11Za96zXartvnCHzldLfEWMG/SL+G2qvFH1YM0t2rIYQYX24PfR
t+Ho+oIrfVsvlG4/fG6LKRpjtgTihmlNqgi0jP9jl22qsosq+UxwCgrVgEBw
4AMIAxsO+kMIbHJwGIxhrED4QAa0D4MRSB8UQhjCuA8mgAEHFQINoY/gh3D7
bjQszCFcECOrGQ1775W0MWFgV61g5ENgYNh6iVWHJehAMi1t/rgl3CXrSfrY
emp0F10jmNCivLI2y9G+CYpPl/P2w/25OWVfdYhcT3mwaOxnuZc9Nc5Z9ItV
LF7lIDfMNohKaSxDIJSzrSLuB1PpxI0p4h8olrNKI1QqFtaeXdtG4ajyWMTA
Sqk8RC8Uy4VQcayMVgyu13hg/9ks1faL8G5Oy7Xwu2KshbGoSX0WY/NzGGuu
mc9VO8bcYdwWNOiSVqSYMBaGiuPWXCXsooqSoVSm5BiBj4H3C4419IOCY3Tg
jjUIfcCxAsUhHMI4AGMKjk3BMVUch1DnghJuTxiEIGSBbwBD3mq9eYtutq4M
Wc60egu/1LxLtwjbLzRlumDNb5m1Lu8b+KU6t/GYXzzhd49kNa1uvMIv1vzS
Cb9U80sVioAN/OIRv3SGX6z5pTrafo/Cml884ZdqfiuPVCk2XY/mCnYGYsWl
Bc1XZyGm5hL2KsWKBJNSB+eKMfzx/RpaCW8z1KUgKeSM0BevE96lHMkAma/9
8ibGZZJF2l09QFn8o6vUrkfU/Vh3HvWXg4v27TukPeH2BqkaSvUI0Wq9efdu
sa7txm2MfBPhzRt4i7DSzKAJ9iUaSyIO0djXuLJBJ436UEOJ3ivWx5oUTxp0
3OiqeGztdEyjYj3tRPp0/qmPdsSbi9sZxCURkwrl+dvt5ur2KuISkVnTJQZf
J6tVsl7AQ5wslrl7dnBPFLNkPo/TeD2NL0G03mLyzo8RwhhmhC1BZ9f1k88R
wveZDKisVtdxtYCsNUyXRwdbXRmp6ib/T/oLws19soZBOpnd7RyL1Xb4Efrw
I91sN1k8g2/xA4wnq+T+0Z3XMH3c5ptFOtkukyl8nWTL23f7jaN/v9ikSb5c
ZR+Bq3wJ36f55i5O7S9E83IJN9vJ+nkV+33eC+0D5zQrrQNk0/WbFibtfq+r
TFvm+fbS8+KlNceSSfIPy3fW8BOb5N5ue7+ZzDJPeSr2BvfxehanbDubH1qr
Je02C+4qI5Mc0rg3PzbdpRYIYWuBeelwmqVTtk6ynC02/3qLdLPbZt5N5Dnj
XracXAjverNbz8ibbaa7VbzOs73np2Tb4JkHzqu0TB2YPkiWfZ1BWLw93bn9
kihO0/1/AQYApGFzRg0KZW5kc3RyZWFtDWVuZG9iag00IDAgb2JqPDwvVVJJ
KGh0dHA6Ly9laGFzaC5pYWlrLnR1Z3Jhei5hdC91cGxvYWRzLzUvNWUvQmxl
bmRlci5wZGYpL1MvVVJJPj4NZW5kb2JqDTUgMCBvYmo8PC9SZWN0WzcwLjg2
IDMzNi42NDcgMzgyLjgwOCAzNTMuNjkxXS9TdWJ0eXBlL0xpbmsvQlM8PC9T
L1MvVyAwL1R5cGUvQm9yZGVyPj4vQSA0IDAgUi9IL0kvU3RydWN0UGFyZW50
IDMvQm9yZGVyWzAgMCAwXS9UeXBlL0Fubm90Pj4NZW5kb2JqDTYgMCBvYmo8
PC9VUkkoaHR0cDovL2NzcmMubmlzdC5nb3YvZ3JvdXBzL1NUL2hhc2gvc2hh
LTMvUm91bmQxL2RvY3VtZW50cy9CbGVuZGVyLnppcCkvUy9VUkk+Pg1lbmRv
YmoNNyAwIG9iajw8L1JlY3RbNzAuODYgMzI1LjM2NyA0OTAuNzkgMzQyLjQx
MV0vU3VidHlwZS9MaW5rL0JTPDwvUy9TL1cgMC9UeXBlL0JvcmRlcj4+L0Eg
NiAwIFIvSC9JL1N0cnVjdFBhcmVudCA0L0JvcmRlclswIDAgMF0vVHlwZS9B
bm5vdD4+DWVuZG9iag04IDAgb2JqPDwvRmlyc3QgNTkxL0xlbmd0aCAxMTc2
L0ZpbHRlci9GbGF0ZURlY29kZS9OIDc1L1R5cGUvT2JqU3RtPj5zdHJlYW0N
Cnja1JZLTyNHEMe/Skvcd/rdXdLKEo+gEFhYYaIcEIcBZokDzFiz49WST59/
T9nYZHlsHZCSg13ucfWv3mUbr7QyQeWoTFQ+J2WSCt4qk1UipwwpIq0slHQI
yhplrIeEgtNZWWi4ZJT1yngDGQBzTlngQoYELzo8z+DqqCxB+qgceIkgwcve
KwcewZYrFqNTzsOkTsrBlA5GOVzVFJRLcMFBD6YN+PhoLYx4uGjhh4cph3AQ
gHWBlIcLXnsFE9Z7nMHzhDN4AZc9eCHjDF6Ec1CxMXkVwEvwB6ZtijiDlzXO
4OWAM3iZcAaPAA8ltIwzXNZwPmTIwoGrSJiKGjJZFRGKhdFoISmrEqqDkzDh
XMYZIXokISI1PuFcUoAkR/AC3iJ40TiVwIuAI2SXdFBAuwRnE3iJkoJpl8FN
4GX4lcAjJDOBRxl6GSlD3hJC1riUNVKHeHNJIZzIFilEPZFibxFUSRECUxmp
dUgS2sU71AP94j2SDtd9QAN9/FgdlnbS6rT6XPdNO5z1TVNa6+mT4+b7cNg8
qFCddnfNp3pe2q6onD3Mm2o69IurUe+064bJpFDPYQIKJXOjcCz8KELiU2AR
WSwfLu/RKJC4URgWDEsMSwxLTElMSUxJTElMyUzJTMlMyUzJTMlMyUxxrOJY
xbGKYxW3VGFDjg05NuTZkGdDnimeKZ4pnimeKZ4pnimeKYEpgSmBKYEpYZlB
pli+Z5ffjcyL6jOGe6zOtJo2V1yQ48X913Nd1kTRNGVRjDfLqhgDKLti9KEs
i4IZrx20d7O2mf5Zo8z7s5tF31R7fTffreer48liKCrVdF631XRx+fWqn82H
1XHe9JsPzk628drFa3+U6JzZbdMtVl+jzXa679Xe7Ft13PX39V31ufqlvW67
ocEDvO2jwdan39vrpl9bB/WgYA+q/b6+b0bME9d/Rbf2A4x037Z23dbO3pbV
3fVt/fejd3x/MjmPnI2VeLaL6b/dxRfjHIaRgY8nl38pcjzYN4rMen5Pdn47
nUxK3/Bgom+OZu0tsvB/mQPHmjZuzsEYvqWN8MMq+meD52F6DJ6vh43r6fXr
7t/Xt8vvbHl2uJypMplhqcX9Peqh+a6a7S9D0yv9QY9TsH03u8H8DHU/VCfV
Uf1QZuSPfjbM2ptP3XVTHfVnl3xxp/nS9c3jzQPMRDuMR0zOxmmErc8c4DJl
xX27dOzFIVnFlFYxhXJtFc96FlcJGvWLS3vNVdfXw6xrx5StNR8je6q12911
/Tl8LH4q80Ff/JBO80o6D5ftULwzPxmUMyuyL9fovYPSzwSlf4znqdkNXSPQ
tQJdJ9D1At0g0I0C3STQzQJdktRCVDhJ5YykdEZSOyMpnpFUz0jKZyT1M5IC
GkkFraSCVjR7kgpaSQWtKM/06r4Mj1/TT+7LqDcGO+Tn1iW9077My9+f8m+2
/O7mt6y/vQpJsgtJsgxJsuFIsuJIsuNIsuRItOVItOZItOdItOhItOlItOpI
tOtItOxItO1ItO5ItO9ItPBItPFItPJe0BbV0opqaUW1tG/X8n3+JMYX//n+
I8AA6hzPYw0KZW5kc3RyZWFtDWVuZG9iag05IDAgb2JqPDwvTnVtc1swIDEw
IDAgUl0+Pg1lbmRvYmoNMTAgMCBvYmo8PC9TL0Q+Pg1lbmRvYmoNMTEgMCBv
Ymo8PC9Db3VudCAyL1R5cGUvUGFnZXMvS2lkc1s5MSAwIFIgMSAwIFJdPj4N
ZW5kb2JqDTEyIDAgb2JqPDwvU3VidHlwZS9YTUwvTGVuZ3RoIDQzNDcvVHlw
ZS9NZXRhZGF0YT4+c3RyZWFtDQo8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9
Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/Pgo8eDp4bXBtZXRhIHhtbG5z
Ong9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSIzLjEtNzAxIj4KICAgPHJk
ZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIy
LXJkZi1zeW50YXgtbnMjIj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6
YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6cGRmPSJodHRwOi8vbnMuYWRv
YmUuY29tL3BkZi8xLjMvIj4KICAgICAgICAgPHBkZjpQcm9kdWNlcj5BY3Jv
YmF0IERpc3RpbGxlciA3LjAgKFdpbmRvd3MpPC9wZGY6UHJvZHVjZXI+CiAg
ICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICAgICA8cmRmOkRlc2NyaXB0aW9u
IHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczpwZGZ4PSJodHRwOi8v
bnMuYWRvYmUuY29tL3BkZngvMS4zLyI+CiAgICAgICAgIDxwZGZ4OkNvbXBh
bnk+Vks8L3BkZng6Q29tcGFueT4KICAgICAgICAgPHBkZng6U291cmNlTW9k
aWZpZWQ+RDoyMDA4MTIxOTEyMDAzNTwvcGRmeDpTb3VyY2VNb2RpZmllZD4K
ICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgICAgIDxyZGY6RGVzY3JpcHRp
b24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5zOnhhcD0iaHR0cDov
L25zLmFkb2JlLmNvbS94YXAvMS4wLyI+CiAgICAgICAgIDx4YXA6Q3JlYXRv
clRvb2w+QWNyb2JhdCBQREZNYWtlciA3LjAgcHJvIFdvcmQ8L3hhcDpDcmVh
dG9yVG9vbD4KICAgICAgICAgPHhhcDpNb2RpZnlEYXRlPjIwMDgtMTItMTlU
MTM6MDErMDE6MDA8L3hhcDpNb2RpZnlEYXRlPgogICAgICAgICA8eGFwOkNy
ZWF0ZURhdGU+MjAwOC0xMi0xOVQxMzowMDo1OCswMTowMDwveGFwOkNyZWF0
ZURhdGU+CiAgICAgICAgIDx4YXA6TWV0YWRhdGFEYXRlPjIwMDgtMTItMTlU
MTM6MDErMDE6MDA8L3hhcDpNZXRhZGF0YURhdGU+CiAgICAgIDwvcmRmOkRl
c2NyaXB0aW9uPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0i
IgogICAgICAgICAgICB4bWxuczp4YXBNTT0iaHR0cDovL25zLmFkb2JlLmNv
bS94YXAvMS4wL21tLyI+CiAgICAgICAgIDx4YXBNTTpEb2N1bWVudElEPnV1
aWQ6OTJlNWRhNWYtMmEyNC00ZTM3LTkxZTktNzQzZmU1NDUwODRiPC94YXBN
TTpEb2N1bWVudElEPgogICAgICAgICA8eGFwTU06SW5zdGFuY2VJRD51dWlk
OmIzMGFmY2I5LTEzMzgtNDg1Yi05ODY3LTM2MDVjOTZiMjBkZTwveGFwTU06
SW5zdGFuY2VJRD4KICAgICAgICAgPHhhcE1NOlZlcnNpb25JRD4KICAgICAg
ICAgICAgPHJkZjpTZXE+CiAgICAgICAgICAgICAgIDxyZGY6bGk+NDwvcmRm
OmxpPgogICAgICAgICAgICA8L3JkZjpTZXE+CiAgICAgICAgIDwveGFwTU06
VmVyc2lvbklEPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgPHJk
ZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6
ZGM9Imh0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIj4KICAgICAg
ICAgPGRjOmZvcm1hdD5hcHBsaWNhdGlvbi9wZGY8L2RjOmZvcm1hdD4KICAg
ICAgICAgPGRjOnRpdGxlPgogICAgICAgICAgICA8cmRmOkFsdD4KICAgICAg
ICAgICAgICAgPHJkZjpsaSB4bWw6bGFuZz0ieC1kZWZhdWx0Ij5BIG5lYXIt
Y29sbGlzaW9uIGF0dGFjayBvbiBCTEVOREVSLTI1NjwvcmRmOmxpPgogICAg
ICAgICAgICA8L3JkZjpBbHQ+CiAgICAgICAgIDwvZGM6dGl0bGU+CiAgICAg
ICAgIDxkYzpjcmVhdG9yPgogICAgICAgICAgICA8cmRmOlNlcT4KICAgICAg
ICAgICAgICAgPHJkZjpsaT5WSzwvcmRmOmxpPgogICAgICAgICAgICA8L3Jk
ZjpTZXE+CiAgICAgICAgIDwvZGM6Y3JlYXRvcj4KICAgICAgICAgPGRjOnN1
YmplY3Q+CiAgICAgICAgICAgIDxyZGY6U2VxPgogICAgICAgICAgICAgICA8
cmRmOmxpLz4KICAgICAgICAgICAgPC9yZGY6U2VxPgogICAgICAgICA8L2Rj
OnN1YmplY3Q+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICAgICA8cmRm
OkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczpw
aG90b3Nob3A9Imh0dHA6Ly9ucy5hZG9iZS5jb20vcGhvdG9zaG9wLzEuMC8i
PgogICAgICAgICA8cGhvdG9zaG9wOmhlYWRsaW5lPgogICAgICAgICAgICA8
cmRmOlNlcT4KICAgICAgICAgICAgICAgPHJkZjpsaS8+CiAgICAgICAgICAg
IDwvcmRmOlNlcT4KICAgICAgICAgPC9waG90b3Nob3A6aGVhZGxpbmU+CiAg
ICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICA8L3JkZjpSREY+CjwveDp4bXBt
ZXRhPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK
ICAgICAgICAgICAgICAgICAgICAgICAgICAgCjw/eHBhY2tldCBlbmQ9Inci
Pz4NCmVuZHN0cmVhbQ1lbmRvYmoNMTMgMCBvYmo8PC9DcmVhdGlvbkRhdGUo
RDoyMDA4MTIxOTEzMDA1OCswMScwMCcpL0F1dGhvcihWSykvQ3JlYXRvcihB
Y3JvYmF0IFBERk1ha2VyIDcuMCBwcm8gV29yZCkvUHJvZHVjZXIoQWNyb2Jh
dCBEaXN0aWxsZXIgNy4wIFwoV2luZG93c1wpKS9Nb2REYXRlKEQ6MjAwODEy
MTkxMzAxMDArMDEnMDAnKS9Db21wYW55KFZLKS9Tb3VyY2VNb2RpZmllZChE
OjIwMDgxMjE5MTIwMDM1KS9UaXRsZShBIG5lYXItY29sbGlzaW9uIGF0dGFj
ayBvbiBCTEVOREVSLTI1Nik+Pg1lbmRvYmoNeHJlZg0KMCA4OQ0KMDAwMDAw
MDAwMCA2NTUzNSBmDQowMDAwMDA3OTYxIDAwMDAwIG4NCjAwMDAwMDgyMTAg
MDAwMDAgbg0KMDAwMDAwODIzOCAwMDAwMCBuDQowMDAwMDA5NDgyIDAwMDAw
IG4NCjAwMDAwMDk1NjUgMDAwMDAgbg0KMDAwMDAwOTcxMiAwMDAwMCBuDQow
MDAwMDA5ODEzIDAwMDAwIG4NCjAwMDAwMDk5NTkgMDAwMDAgbg0KMDAwMDAx
MTIzMSAwMDAwMCBuDQowMDAwMDExMjY1IDAwMDAwIG4NCjAwMDAwMTEyODkg
MDAwMDAgbg0KMDAwMDAxMTM0NyAwMDAwMCBuDQowMDAwMDE1NzcxIDAwMDAw
IG4NCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow
MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw
MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg
NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1
IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow
MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw
MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg
NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1
IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow
MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw
MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg
NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1
IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow
MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw
MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg
NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1
IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow
MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw
MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg
NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1
IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow
MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw
MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg
NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1
IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow
MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw
MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg
NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1
IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow
MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw
MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg
NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1
IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow
MDAwMDAwMDAwIDY1NTM1IGYNCnRyYWlsZXINCjw8L1NpemUgODk+Pg0Kc3Rh
cnR4cmVmDQoxMTYNCiUlRU9GDQo=

--=_0b64b6134f298a7ae7c20aab7b291609--

From hash-forum@nist.gov  Fri Dec 19 03:19:18 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBJBJCHZ003833
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Fri, 19 Dec 2008 03:19:14 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBJBIcpB000797;
	Fri, 19 Dec 2008 06:18:40 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBJBIJB4009264;
	Fri, 19 Dec 2008 06:18:19 -0500
Date: Fri, 19 Dec 2008 06:18:19 -0500
Message-Id: <0F627D67EE858D44BD1CEFEA67183F18073D552B@CNSCNEVS03.ap.sony.com>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "Xu, Liangyu" 
To: Multiple recipients of list 
Subject: Semi-free start collision attack on Blender
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-To: 
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C961CA.F6F2D1A0"
MIME-Version: 1.0
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 19 Dec 2008 03:19:14 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_MED,TRACKER_ID shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 435


This is a multi-part message in MIME format.

------_=_NextPart_001_01C961CA.F6F2D1A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear all,

=20

We have found a semi-free start collision attack on Blender (all
variants). The complexity of the attack is trivial so we can find=20

real message pairs colliding with a specified initial values (other than
the initial values the designer gives).=20

  Following is an example of such a semi-free start collision message
pairs. (For Blender-256)

The specified initial values:

a0=3Da1=3Da2=3Da3=3Da4=3Da5=3Da6=3Da7=3D0x00000000

Message 1:

00000000 00000000 00000000 00000000 00000000 ffffffff=20

Message 2:

00000000 00000000 00000000 00000000 ffffffff 00000000

Semi-free start collision hash digest:

f50b433f415f9700f50b433f415f9700f50b433f415f9700750b42fe04206f79

=20

The details of the attack will soon be available on e-print. Any comment
is welcome.

=20

Best Regards,

XU Liangyu=20

Security Technology Research Department

Sony China Research Laboratory, Sony (China) Limited

=20


------_=_NextPart_001_01C961CA.F6F2D1A0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



















Dear all,



 



We have found a =
semi-free
start collision attack on Blender (all variants). The complexity of the =
attack is
trivial so we can find 



real message pairs colliding with a specified =
initial
values (other than the initial values the designer gives). =




  Following is an example of such a =
semi-free
start collision message pairs. (For =
Blender-256)



The specified initial =
values:



a0=3Da1=3Da2=3Da3=3Da4=3Da5=3Da6=3Da7=3D0x0000=
0000



Message =
1:



00000000
00000000 00000000 00000000 00000000 ffffffff =




Message =
2:



00000000
00000000 00000000 00000000 ffffffff 00000000



Semi-free
start collision hash digest:



f50b433f415f9700f50b433f415f9700f50b433f415f97=
00750b42fe04206f79



 



The details of =
the attack will
soon be available on e-print. Any comment is =
welcome.



 



Best Regards,



XU Liangyu 



Security
Technology Research Department



Sony China Research Laboratory, Sony =
(China)
Limited



 









------_=_NextPart_001_01C961CA.F6F2D1A0--

From hash-forum@nist.gov  Sat Dec 20 03:03:12 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBKB36Rq021061
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Sat, 20 Dec 2008 03:03:07 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBKB1Pmo025089;
	Sat, 20 Dec 2008 06:01:28 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBKB185C026281;
	Sat, 20 Dec 2008 06:01:09 -0500
Date: Sat, 20 Dec 2008 06:01:08 -0500
Message-Id: <20081220110335.11357.qmail@cr.yp.to>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "D. J. Bernstein" 
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
In-Reply-To: <346c1ee6c1e5b07155d0669106ae7c8e.squirrel@webmail.ics.mq.edu.au> <7731938b0812171225g7439801dx417579c696dbaf98@mail.gmail.com>  <20081217175156.GA7604@titan.cry.pto> <49492644.5070305@csc.kth.se> <7bb08a5f0812170747l6d81ea6bjda62d65dbcfed826@mail.gmail.com> 
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 20 Dec 2008 03:03:08 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 436


Several issues here: "provable security"; confidence in reduced-round
ciphers; the fairness of tunability; the value of self-cryptanalysis;
implementation quality; the definition of "unbroken"; multicollision
resistance; what is tunable; and cryptanalytic popularity.

Stefan.Lucks@uni-weimar.de writes:
  [ regarding "provable security": ]
> Actually, MD6 has the interesting property of provable security against 
> certain types of differential attacks (the authors of MD6 called them 
> "standard differential attacks"). Your mileage may vary, but I consider 
> this as an amazing result. The MD6 team made a good selling point here!

How can you be amazed by this? Don't you remember DFC, one of the AES
candidates? Let's go back to the NIST report:

   One candidate, DFC, offered a form of evidence called "provable"
   security. This does not refer to an absolute proof of security, but
   rather to proofs that the "decorrelation module" in the round
   function makes DFC secure against some forms of attack, under a
   certain mathematical model.

This is exactly what MD6 is claiming now: namely, provable security that
a certain class of attacks, in a certain model, doesn't work.

NIST went on to comment on the obvious problem, namely that there can be
(and sometimes are) attacks _outside_ the class covered by the proof:

   The value of provable security is called into question by [26], in
   which differential attacks outside the framework of the model are
   applied to decorrelated ciphers in general and reduced versions of
   DFC in particular. The submitters of DFC acknowledge in Ref. [4] that
   a decorrelation design "has to be heuristically secure without the
   decorrelation modules," and that "provable security is not a panacea
   outside its domain of applicability." Nevertheless, the submitters
   maintain that "decorrelation properties provide an additional level
   of security," and that provable security "provides added value to new
   designs."

The rather embarrassing presence of attacks against "provably secure"
reduced-round versions of DFC counteracted the amazement that some
people might have initially felt upon seeing the "proofs." Of course,
rejecting an extra security argument doesn't mean rejecting a cipher,
but DFC was kicked out of the AES competition for performance reasons.

A few of the SHA-3 submissions claim a stronger form of "provable
security": for example, _any_ preimage attack against FSB implies an
algorithm for a well-known decoding task that has already been studied
in previous papers. The problem is that there could be better decoding
algorithms (and in fact I've recently coauthored a paper improving the
state-of-the-art decoding algorithms), and better attacks against FSB.
See the Koblitz--Menezes papers for many more examples of how this
stronger type of "provable security" can fail, often quite horribly.

  [ regarding confidence in reduced-round ciphers: ]
> D. J. Bernstein wrote:
> > Stefan similarly claims, without any justification, that Rivest doesn't
> > have "confidence" in reduced-round variants of MD6. 
> I didn't claim that. Please try not to misrepresent my writing!

Let's review what was actually said:

   * The SHA-3 submission rules specifically allow NIST to use tunable
     parameters to "select a different security/performance tradeoff
     than originally specified by the submitter." For example, if NIST
     decides that full MD6 is too slow and unnecessarily conservative,
     it could still select (e.g.) 24-round MD6 as SHA-3.

   * Niels said bad things about the performance of (e.g.) MD6, but
     ignored the performance of (e.g.) 24-round MD6.

   * I said "I think that there's a noticeable risk that ignoring
     reduced-round MD6 means ignoring the best submitted SHA-3
     candidate---and a quite large risk that ignoring _all_ of the
     reduced-round candidates, as Niels is doing, means ignoring the
     best submitted SHA-3 candidate. I hope that NIST isn't so sloppy."

   * You said that ignoring reduced-round candidates is "reasonable!
     The particular choice of defaults for the security parameters
     reflects the designers' confidence into their creations. How could
     the general public gain confidence into a version of a hash
     function, if the designers of that hash function don't have that
     confidence?" You continued by saying that selecting reduced-round
     candidates would "undermine the credibility of SHA-3."

You were clearly arguing against considering 24-round MD6 as SHA-3. Your
argument was that 24-round MD6 lacks "credibility" and would not have
public "confidence" because Rivest doesn't have "confidence" in it. If
you're now withdrawing your claim regarding Rivest's confidence, then
what exactly is your argument against 24-round MD6?

> Imagine that the designers of MD6 -- or of any other hash function -- 
> recommend a certain number of rounds, and the final standard ignores the 
> recommendation. Instead, that hash function is standardised at a reduced 
> number of rounds. Wouldn't that be ridiculous?

No. NIST said that it expects better performance than SHA-2, but many
submitters have advocated sacrificing performance to gain confidence,
while other submitters have advocated the opposite. NIST would be 
changing the recommended number of rounds because it makes a different
judgment regarding the relative importance of security and performance
for SHA-3---exactly as envisioned in the call for submissions. For
example, NIST could decide that full-round MD6 is unnecessarily
conservative and could reduce the number of rounds to 24.

  [ regarding the fairness of tunability: ]
> It also puts all hash functions without tunable security parameters
> into an artificial disadvantage.

Many people (for example, Rivest) publicly advocated tunable security
parameters during the preliminary discussions of the SHA-3 competition.
The call for submissions didn't _mandate_ tunable parameters but quite
clearly pointed out that they are beneficial for cryptanalysts and give
extra flexibility to NIST. All submitters had ample opportunity to add
tunable security parameters; submitters who chose not to do this have
nobody to blame but themselves.

Jason Martin writes:
  [ regarding the value of self-cryptanalysis: ]
> To me, there is much greater value in a submission where the author
> has performed a good deal of security analysis and placed a "stake in
> the ground" with respect to the performance/security trade-off.

Every AES submission ended up with third-party attacks that went beyond
the best attacks originally described by the designers. Security was
judged by the final attacks, not by the obsolete original attacks. Some
of the original cryptanalysis was useful as a head start for subsequent
cryptanalysis, but in the long term this benefit was negligible.

  [ regarding implementation quality: ]
> For example, in my own case, I didn't have time to
> write both a 32-bit and 64-bit optimized version of the algorithm.
> So, I only wrote a 64-bit optimized version (the 32-bit version is
> just the reference code).

Or maybe your algorithm can't actually run well on 32-bit machines. If
you want to prove that better speeds are possible, go ahead and write a
better implementation, or find someone else to do it for you. As the
months go by, if you keep claiming that you can achieve much better
speeds but you don't actually prove it by publishing the implementation,
people will start assuming that your claims are bogus.

Thomas Pornin writes:
> D. J. Bernstein wrote:
> > What I'm advocating for SHA-3 is that we sort submissions according to
> > the efficiency of their fastest unbroken variants (which are what
> > cryptanalysts want to look at anyway), and then concentrate on the
> > most efficient submissions---let's say within a factor of 2 of the
> > current leader.
> There might be a slight difficulty here. Even assuming that we have
> "optimized enough" implementations to make speed measures meaningful,
> such measures will be specific to the used platform.

My very next sentence was "The effort will be spread somewhat by
differing notions of 'efficiency' but will still be much more focused
than the cryptanalysis of AES candidates."

The eBASH results already show many differences, although also many
correlations, between (e.g.) 32-bit PowerPC G4 efficiency and 64-bit
Core 2 efficiency. Smaller CPUs, FPGAs, and ASICs will all have
different performance pictures. I fully expect that some cryptanalysts
will focus on the hashes offering the best 64-bit speeds while others
will focus on the hashes offering the best hardware speeds.

Real-world performance is inherently complicated. We won't be able to
escape this complication; performance is certainly going to play a role
in the SHA-3 decision.

> but a "factor of 2" requires a precision of definition and measure
> which does not seem to be easily attainable.

Let me put it this way. If you're a hash-function designer, and you
can't show us even _one_ interesting platform where the _fastest_
unbroken variant of your hash function is within a factor of 2 of
other unbroken candidates, then you're going to have an awfully
difficult time convincing anyone that your function should be chosen as
SHA-3. Why should cryptanalysts waste time looking at such functions?

I think the Skein team has been saying essentially the same thing---
with one critical difference, namely that they're comparing only the
performance of _full_ round counts. For example, they're refusing to
report the quite reasonable performance of 24-round MD6, even though 
the submission requirements clearly allow NIST to select 24-round MD6.

Christian Rechberger writes:
  [ regarding the definition of "unbroken": ]
> How to rank and compare known-key distinguisher, related-key-boomerang
> attacks on some underlying block cipher, nonrandom properties of
> underlying permutations, or various forms of (pseudo)/(near)/collisions
> and (2nd)-preimage attacks on some compression functions to results
> obtained on the actual hash function?

Read the submission requirements! SHA-3 has to resist collisions,
preimages, second preimages, length-extension attacks, and the same for
truncations; it has to be secure inside FIPS 186-2, SP 800-56A, FIPS
198, and SP 800-90; NIST can add important applications to this list if
that's necessary for comparing submissions.

An attack "on some underlying block cipher" etc. is typically _not_ an
attack recognized by the rules and should be disregarded unless it can
be converted into an attack recognized by the rules. We've already been
flooded with ridiculous announcements of "free-start collision attacks"
on various sponge-like SHA-3 submissions; these "attacks" say nothing at
all about the actual security of those submissions.

If N-round MD6 hasn't been "broken" by a type of attack recognized in
the rules, then N-round MD6 is a possibility for SHA-3. The smallest
such N is the next target for cryptanalysis, and the speed of N-round
MD6 is the best information we have regarding the security/performance
tradeoff of MD6. This doesn't mean that anyone wants to _standardize_
the smallest possible N as SHA-3; we always leave a security margin!

Thomas Peyrin writes:
  [ regarding the definition of "unbroken": ]
> What does "broken" mean? Collision attacks? Preimage attacks?
> Non-random properties?

Same answer as above. NIST already answered this question in the rules
(after extensive discussion over the past two years), so I'm surprised
to see people asking the question again.

  [ regarding multicollision resistance: ]
> The problem here is that *we don't give any credit to the design
> philosophy*. We (the designers of Echo) chose to build a
> multicollision resistant hash function because we felt it is a
> desirable property.

NIST did say that extra resistance to multicollision attacks would be
viewed positively. But they continued by saying "However, this could
also have performance implications. Submitters should be prepared to
argue for their overall security/performance trade-offs."

I can imagine extra multicollision resistance etc. being viewed as an
adequate justification for _some_ loss of efficiency---but losing a
factor of 10 would be crazy, and I'm pretty sure that the community
won't even accept a factor of 3. If we think this through in advance,
and settle on the maximum slowdown that we'll tolerate, then we can
avoid wasting time cryptanalyzing submissions that clearly won't win.

  [ regarding what is tunable: ]
> Some patches are more than just an increase of the number of rounds.

NIST didn't say that the tunable security parameter had to be a simple
round count. Submissions vary in the breadth of their parameter space.
But we can still keep track of which parameters have been broken, and
then measure the implementations of the unbroken parameters to identify
the fastest functions. Of course, unimplemented parameter choices can't
be considered; NIST has consistently required implementations.

  [ regarding cryptanalytic popularity: ]
> Thus, if a lot of people analyzed your scheme, you have less chance to
> be selected (because maybe some other non popular proposals will keep
> their claims of a very low number of rounds).

You're saying that a "non popular" submission might escape cryptanalysis
and win on performance grounds---and then turn out to be breakable. This
is exactly why our limited cryptanalytic resources should be focused on
the efficient submissions, rather than being spread around haphazardly.

---D. J. Bernstein 
   Research Professor, Computer Science, University of Illinois at Chicago

From hash-forum@nist.gov  Sat Dec 20 03:56:26 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBKBuLAT024849
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Sat, 20 Dec 2008 03:56:22 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBKBtvqS008124;
	Sat, 20 Dec 2008 06:55:57 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBKBtgho003175;
	Sat, 20 Dec 2008 06:55:42 -0500
Date: Sat, 20 Dec 2008 06:55:42 -0500
Message-Id: 
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "Bob Hattersley" 
To: Multiple recipients of list 
Subject: OFFICIAL COMMENT: Waterfall is broken
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Mailer: Microsoft Office Outlook 11
Content-Type: multipart/alternative; boundary="----=_NextPart_000_007F_01C96298.AF47A930"
MIME-Version: 1.0
X-To: 
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 20 Dec 2008 03:56:22 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 437


This is a multi-part message in MIME format.

------=_NextPart_000_007F_01C96298.AF47A930
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Scott Fluhrer of Cisco has found a 2^70 collision attack on Waterfall.  His
paper is available on ePrint.  I hereby withdraw from the competition.
 
I realise that I failed to think clearly about collision attacks at all.  I
believe the first and second preimage resistance is unaffected, but the
collision weakness is fundamental - I can't see any way of patching it up.
So you will be spared any embarrassing attempts to tune numbers of rounds
etc..  I don't think there is much useful to be dragged from the wreckage
except perhaps the message "don't try this".
 
Bob Hattersley
 

 

 

 

 

 

 

 

------=_NextPart_000_007F_01C96298.AF47A930
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







Scott =
Fluhrer of=20
Cisco has found a 2^70 collision attack on Waterfall.  His =
paper is=20
available on ePrint.  I hereby withdraw from the=20
competition.


 


I =
realise that I=20
failed to think clearly about collision attacks at all.  I believe =
the=20
first and second preimage resistance is unaffected, but the collision =
weakness=20
is fundamental - I can't see any way of patching it up.  So you =
will be=20
spared any embarrassing attempts to tune numbers of rounds =
etc..  I=20
don't think there is much useful to be dragged from the wreckage =
except=20
perhaps the message "don't try this".


 


Bob=20
Hattersley


 




 


 


 


 


 


 


 


------=_NextPart_000_007F_01C96298.AF47A930--


From hash-forum@nist.gov  Sat Dec 20 04:10:16 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBKCAB3b030023
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Sat, 20 Dec 2008 04:10:12 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBKC9p7W012224;
	Sat, 20 Dec 2008 07:09:51 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBKC9ciu030341;
	Sat, 20 Dec 2008 07:09:39 -0500
Date: Sat, 20 Dec 2008 07:09:38 -0500
Message-Id: <20081220130252.11516t8qu1tsonwg@webmail.tugraz.at>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: Christian Rechberger 
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Transfer-Encoding: 8bit
X-Organization: Graz University of Technology
Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed"
MIME-Version: 1.0
In-Reply-To: <20081220110335.11357.qmail@cr.yp.to>
References: <20081220110335.11357.qmail@cr.yp.to>
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 20 Dec 2008 04:10:12 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 438


Quoting "D. J. Bernstein" :
> Jason Martin writes:
>   [ regarding the value of self-cryptanalysis: ]
>> To me, there is much greater value in a submission where the author
>> has performed a good deal of security analysis and placed a "stake in
>> the ground" with respect to the performance/security trade-off.
>
> Every AES submission ended up with third-party attacks that went beyond
> the best attacks originally described by the designers. Security was
> judged by the final attacks, not by the obsolete original attacks. Some
> of the original cryptanalysis was useful as a head start for subsequent
> cryptanalysis, but in the long term this benefit was negligible.

As a counter example consider AES-128, probably the most relevant AES  
in practice. Now consider attacks on the block cipher that do not  
assume related keys, arguably the most relevant model. (*)
The original proposal described an attack (based on Integrals) on 6  
rounds. Now, more than 10 years later, is there any attack capable of  
doing more rounds? Not that I would be aware of.


Let's compare two hypothetical candidates from a 2011 point of view:
Candidate #1: has an attack at an early stage for a number of rounds.  
Despite documented efforts until 2011, no significant improvements are  
found.
Candidate #2: Every year until 2011, cryptanalysts add and improve  
their attacks to cover significantly more rounds.

Your proposal to simply choose the fastest unbroken variant (+add some  
some security margin) does not exactly inspire great confidence in  
such a situation.
Not for the final SHA-3, nor for choosing finalists at an earlier  
stage. I'm afraid matters are not so simple.


-Christian


(*) There is a lot of very interesting work on AES variants with  
longer keys and in other models (and performance improvements on the  
6-round attack), that I do not want to dismiss here, but focusing on  
the most relevant settings makes my point more clear.




From hash-forum@nist.gov  Sat Dec 20 09:08:05 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBKH81ts023860
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Sat, 20 Dec 2008 09:08:02 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBKH7baE032712;
	Sat, 20 Dec 2008 12:07:38 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBKH7Kmt027728;
	Sat, 20 Dec 2008 12:07:20 -0500
Date: Sat, 20 Dec 2008 12:07:20 -0500
Message-Id: <20081220170537.22633.qmail@cr.yp.to>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "D. J. Bernstein" 
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
In-Reply-To: <20081220130252.11516t8qu1tsonwg@webmail.tugraz.at>
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 20 Dec 2008 09:08:02 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 439


Christian Rechberger writes:
> Your proposal to simply choose the fastest unbroken variant (+add some
> some security margin)

That is _not_ what I'm advocating; it's not even close. Please take the
time to read and understand the previous messages before you respond.

---D. J. Bernstein 
   Research Professor, Computer Science, University of Illinois at Chicago

From hash-forum@nist.gov  Sat Dec 20 09:35:14 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBKHZ8RD026323
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Sat, 20 Dec 2008 09:35:10 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBKHYi78004644;
	Sat, 20 Dec 2008 12:34:44 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBKHYYtV016452;
	Sat, 20 Dec 2008 12:34:34 -0500
Date: Sat, 20 Dec 2008 12:34:34 -0500
Message-Id: <7bb08a5f0812200920o51d7a47bo925ec424f39ddd62@mail.gmail.com>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "Jason Martin" 
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
References: <20081220110335.11357.qmail@cr.yp.to> <20081220130252.11516t8qu1tsonwg@webmail.tugraz.at>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1
MIME-Version: 1.0
In-Reply-To: <20081220130252.11516t8qu1tsonwg@webmail.tugraz.at>
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 20 Dec 2008 09:35:10 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 440


[ regarding implementation quality: ]
>> Jason Martin wrote:
>> For example, in my own case, I didn't have time to
>> write both a 32-bit and 64-bit optimized version of the algorithm.
>> So, I only wrote a 64-bit optimized version (the 32-bit version is
>> just the reference code).
>
>D. J. Bernstein wrote:
>Or maybe your algorithm can't actually run well on 32-bit machines. If
>you want to prove that better speeds are possible, go ahead and write a
>better implementation, or find someone else to do it for you. As the
>months go by, if you keep claiming that you can achieve much better
>speeds but you don't actually prove it by publishing the implementation,
>people will start assuming that your claims are bogus.

Prof. Bernstein makes a valid point in that I should write a 32-bit
optimized version of ESSENCE.  However, that takes significant time
and effort, and it isn't clear to me that it will be worth that time
and effort for the first round.  For example, Bill Burr indicated
that:

      "We do not intend to make our second round selections
       primarily on the basis of performance data, so minor code
       tuning may not have a big payback at this point.  But, if
       a major feature of a proposal is how efficient an
       algorithm is with some vector instruction set, or on a
       lightweight processor, or something like that, some
       additional measured performance data might be useful."

I already wrote the 64-bit assembly code to demonstrate that ESSENCE
makes use of vector instructions.  I also included OpenMP C code to
demonstrate that ESSENCE makes use of multiple cores (this is all in
the "Additional Implementations" section of the ESSENCE submission).
So, I see little to be gained in the first round by repeating that
multi-month effort for a 32-bit version.

Unless I receive some indication from NIST that ESSENCE will only be a
viable contender for the second round if I write a 32-bit optimized
version, there is no incentive for me to work on that now.  (If
someone else wants to write it for me, that would be wonderful, but I
won't hold my breath waiting for volunteers.)  If ESSENCE does make it
to the second round, then I will write a 32-bit optimized version.  At
the moment, I think that my time is better spent analyzing the other
submissions.  (Besides, if someone comes up with a successful attack
on ESSENCE in the next couple months, then I won't need to worry about
writing any more implementations of it.)

Perhaps during or after the Leuven conference NIST can provide all the
submitters with a more precise criteria of how the second round
choices will be made and exactly how performance data will factor in
those decisions.

The point of my original post was not to debate the shortcomings of my
own submission but rather to use it as an example that
"implementations can have a huge impact on performance."  That is one
of the main reasons I disagree with the "fastest unbroken variant"
philosophy for choosing the second round candidates.  I feel that we
should be spending our time analyzing the mathematical and structural
merits of the various submissions rather than tweaking code and round
parameters.



--jason

Jason Worth Martin
Asst. Professor of Mathematics
http://www.math.jmu.edu/~martin

From hash-forum@nist.gov  Sat Dec 20 09:49:08 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBKHn2CJ027383
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Sat, 20 Dec 2008 09:49:03 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBKHmTMr011939;
	Sat, 20 Dec 2008 12:48:30 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBKHmIb2011243;
	Sat, 20 Dec 2008 12:48:18 -0500
Date: Sat, 20 Dec 2008 12:48:18 -0500
Message-Id: <72CF8F2B2766084DBD7AEAFCAE4A3B7909736B15@frsnprexc1.usr.ingenico.loc>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "Thomas PEYRIN" 
To: Multiple recipients of list 
Subject: RE: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-To: 
References: <20081220110335.11357.qmail@cr.yp.to>
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C962C9.A81D88DB"
MIME-Version: 1.0
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 20 Dec 2008 09:49:03 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords:                 
X-UID: 441


This is a multi-part message in MIME format.

------_=_NextPart_001_01C962C9.A81D88DB
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

  [ regarding cryptanalytic popularity: ]

> Thus, if a lot of people analyzed your scheme, you have less chance to

> be selected (because maybe some other non popular proposals will keep

> their claims of a very low number of rounds).

=20

You're saying that a "non popular" submission might escape cryptanalysis

and win on performance grounds---and then turn out to be breakable. This

is exactly why our limited cryptanalytic resources should be focused on

the efficient submissions, rather than being spread around haphazardly.

=20

That's exactly my point: since we have not so many cryptanalysis effort
to spend, let's spare a lot of effort with realistic number of rounds
claims by the designers. As Christian pointed out, I can see two
situations:

=20

A)    The current fastest unbroken scheme keeps being broken regularly.
And when the final decision time comes, we choose the fastest unbroken
scheme(s) at this time.

=20

B)    Much before the final decision, no one finds any new attack for
the current fastest unbroken schemes. Thus the "ranking" for the best
schemes stays more or less the same.=20

=20

Since the NIST competition is only a few years long and there are many
proposals, I expect situation A to happen. One can clearly understand
that this situation is problematic since our view on the selected
scheme(s) won't be fully set. Now, if designers give realistic claims,
situation A has much less probability to happen and we will converge
more quickly to situation B, with no more new cryptanalysis results on
the fastest unbroken schemes.

=20

We're not trying to find the best hash proposal here, we're trying to
find the best hash proposal *in only a rather short period of time*!

=20

Thus, to reformulate: I don't agree that "our limited cryptanalytic
resources should be focused on the efficient submissions", I would say
"cryptanalytic resources should be focused on the efficient submissions
for a secure number of rounds claimed by the designers".

=20

Thomas.

=20


=20
About Ingenico: Ingenico is the world=E2=80=99s leading provider of =
payment solutions, with over 15 million terminals deployed across the =
globe. Delivering the very latest secure electronic payment =
technologies, transaction management and the widest range of value added =
services, Ingenico is shaping the future direction of the payment =
solutions market. Leveraging on its global presence and local expertise, =
Ingenico is reinforcing its leadership by taking banks and businesses =
beyond payment through offering comprehensive solutions, a true source =
of differentiation and new revenues streams.
 This message may contain confidential and/or privileged information. If =
you are not the addressee or authorized to receive this for the =
addressee, you must not use, copy, disclose or take any action based on =
this message or any information herein. If you have received this =
message in error, please advise the sender immediately by reply e-mail =
and delete this message. Thank you for your cooperation.
 P Please consider the environment before printing this e-mail
=20
=20

------_=_NextPart_001_01C962C9.A81D88DB
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable







Notice








  [ =
regarding cryptanalytic popularity: ]



> =
Thus, if a lot of people analyzed your scheme,
you have less chance to



> be =
selected (because maybe some other non popular
proposals will keep



> =
their claims of a very low number of =
rounds).



 



You're =
saying that a "non popular"
submission might escape cryptanalysis



and win =
on performance grounds---and then turn out to
be breakable. This



is =
exactly why our limited cryptanalytic resources
should be focused on



the =
efficient submissions, rather than being spread
around haphazardly.



 


That’s exactly my point:
since we have not so many cryptanalysis effort to spend, let’s =
spare a
lot of effort with realistic number of rounds claims by the designers. =
As
Christian pointed out, I can see two =
situations:



 


A)   
The current fastest unbroken scheme =
keeps being
broken regularly. And when the final decision time comes, we choose the =
fastest
unbroken scheme(s) at this time.



 


B)   
Much before the final decision, no =
one finds any
new attack for the current fastest unbroken schemes. Thus the =
“ranking”
for the best schemes stays more or less the same. =




 


Since =
the NIST competition is only
a few years long and there are many proposals, I expect situation A to =
happen. One
can clearly understand that this situation is problematic since our view =
on the
selected scheme(s) won’t be fully set. Now, if designers give =
realistic
claims, situation A has much less probability to happen and we will =
converge
more quickly to situation B, with no more new cryptanalysis results on =
the
fastest unbroken schemes.



 


We’re not trying to find
the best hash proposal here, we’re trying to find the best hash =
proposal *in only a rather short =
period of time*!



 


Thus, =
to reformulate: I don’t
agree that “our limited =
cryptanalytic
resources should be focused on the efficient submissions”, I would =
say “cryptanalytic
resources should be focused on the efficient submissions for a secure =
number of
rounds claimed by the designers”.



 


Thomas.


 








 




About =
Ingenico: Ingenico is the world=E2=80=99s =
leading provider of payment solutions, with over 15 million terminals =
deployed across the globe. Delivering =
the very latest secure electronic payment technologies, transaction =
management and the widest range of value added services, Ingenico is =
shaping the future direction of the payment solutions market. Leveraging =
on its global presence and local expertise, Ingenico is reinforcing its =
leadership by taking banks and businesses beyond payment through =
offering comprehensive solutions, a true source of differentiation and =
new revenues streams.


 This message may contain =
confidential and/or privileged information. If you are not the addressee =
or authorized to receive this for the addressee, you must not use, copy, =
disclose or take any action based on this message or any information =
herein. If you have received this message in error, please advise the =
sender immediately by reply e-mail and delete this message. Thank you =
for your cooperation.


 P Please consider the environment before printing =
this e-mail


 




 


------_=_NextPart_001_01C962C9.A81D88DB--

From hash-forum@nist.gov  Sat Dec 20 10:02:41 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBKI2avw029067
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Sat, 20 Dec 2008 10:02:37 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBKI2EFe009190;
	Sat, 20 Dec 2008 13:02:15 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBKI230d004284;
	Sat, 20 Dec 2008 13:02:03 -0500
Date: Sat, 20 Dec 2008 13:02:03 -0500
Message-Id: <20081220185644.64577um0burnf6jk@webmail.tugraz.at>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: Christian Rechberger 
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Organization: Graz University of Technology
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed"
MIME-Version: 1.0
In-Reply-To: <20081220170537.22633.qmail@cr.yp.to>
References: <20081220170537.22633.qmail@cr.yp.to>
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 20 Dec 2008 10:02:37 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords:                 
X-UID: 442


Quoting "D. J. Bernstein" :

>
> Christian Rechberger writes:
>> Your proposal to simply choose the fastest unbroken variant (+add some
>> some security margin)
>
> That is _not_ what I'm advocating; it's not even close. Please take the

Bad rephrasing from my side, sorry about that. Still, my point remains  
(which I share with many others as I have noticed): There are many  
aspects in addition to "fastest unbroken variant" to consider when
* choosing "interesting" candidates for cryptanalysis
* scaling down the number of candidates from 51 to e.g. 15 and less

-Christian



From hash-forum@nist.gov  Sat Dec 20 17:41:27 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBL1fMdS030484
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Sat, 20 Dec 2008 17:41:23 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBL1euQp030719;
	Sat, 20 Dec 2008 20:40:56 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBL1ehtt019880;
	Sat, 20 Dec 2008 20:40:43 -0500
Date: Sat, 20 Dec 2008 20:40:43 -0500
Message-Id: 
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: Richard Outerbridge 
To: Multiple recipients of list 
Subject: Re: OFFICIAL COMMENT: Waterfall is broken
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Mailer: Apple Mail (2.930.3)
References: 
Mime-Version: 1.0 (Apple Message framework v930.3)
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
In-Reply-To: 
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 20 Dec 2008 17:41:24 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 443


On Dec 20, 2008, at 06:55, Bob Hattersley wrote:

> Scott Fluhrer of Cisco has found a 2^70 collision attack on  
> Waterfall.  His paper is available on ePrint.  I hereby withdraw  
> from the competition.
>
> I realise that I failed to think clearly about collision attacks at  
> all.  I believe the first and second preimage resistance is  
> unaffected, but the collision weakness is fundamental - I can't see  
> any way of patching it up.  So you will be spared any embarrassing  
> attempts to tune numbers of rounds etc..  I don't think there is  
> much useful to be dragged from the wreckage except perhaps the  
> message "don't try this".
>
> Bob Hattersley

Hey, thanks for trying.

Richard


From hash-forum@nist.gov  Sat Dec 20 20:24:08 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBL4O2jP008543
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Sat, 20 Dec 2008 20:24:03 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBL4NJhJ011152;
	Sat, 20 Dec 2008 23:23:19 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBL4MwL1010605;
	Sat, 20 Dec 2008 23:22:59 -0500
Date: Sat, 20 Dec 2008 23:22:58 -0500
Message-Id: <000001c96322$9ef19480$dcd4bd80$@org>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "John Washburn" 
To: Multiple recipients of list 
Subject: OFFICIAL COMMENT: WaMM is Withdrawn
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Mailer: Microsoft Office Outlook 12.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
In-Reply-To: 
References:  
X-To: 
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sat, 20 Dec 2008 20:24:03 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 444


WaMM is withdrawn from the competition.

While I have a relatively simple fix for the boneheaded XOR mixing I
introduced at the last minute, it is not sufficient to continue with WaMM.

My July version used full vector multiplication of the message vector with
the state matrix.  This created excellent blending of every bit in the
incoming message block with every bit of the state matrix, but this was an
order of magnitude slower than the SHA-512 implementation running on the
same machines.

I have used the analogy to my family and non-technical friends, that this is
similar to showing up to a NASCAR race with a car that tops out at 20 to 22
miles per hour.  Yes, you get around the track, but a reasonable question is
why are you on the track in the first place?

The simple XOR-ing of the message bits with a row of the state matrix
brought the speed to parity with SHA-512, but as David Wilson pointed out,
the change gutted the second pre-image resistance of WaMM to nothing.

Substituting: 
  WaMM(MessageByte[j], StateMatrix[iRow][j]) + WaMM(StateMatrix[iRow][j],
MessageByte[j])
for
  MessageByte[j] XOR StateMatrix[iRow][j]
blocks Wilson's second pre-image attack with only a slight performance hit.
(Still slower than SHA-512 though which is not good)

This small change fixes the pre-image attack because there is 35% chance
there is no MessageByte which solves
WaMM(MessageByte[j], StateMatrix[iRow][j]) + WaMM(StateMatrix[iRow][j],
MessageByte[j]) = C
For a fixed C and fixed StateMatrix[iRow][j].

This "solution" though skews the possible values which could be in any byte
of the State Matrix.  Any given byte of the state matrix is no longer
uniformly distributed from 0x00 to 0xFF.  This effect is similar to the
distribution of quadratic residues when multiplying mod 256.  My "residue"
issue is not as severe as that of quadratic residues, but similar.  The
distribution of possible values calculated for the State Matrix are not
uniformly distributed.

Unfortunately, anything which makes the state matrix more like a random pool
slows the performance dramatically.  I am between Scylla and Charibdis;
Speed or Security.

The only way out of the box is to drop my use of matrix multiplication as
the primary mixing operator.

That change though means WaMM is not (Wa)shburn (M)atrix (M)ultiplication.
I don't see how any "tweak" small enough to be allowed by the NIST will
overcome this design decision and still produce a hash of reasonable speed.

Please consider WaMM as withdrawn.







From hash-forum@nist.gov  Sun Dec 21 02:28:40 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBLASZbw030457
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Sun, 21 Dec 2008 02:28:36 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBLAS51v006461;
	Sun, 21 Dec 2008 05:28:06 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBLARsx8007680;
	Sun, 21 Dec 2008 05:27:55 -0500
Date: Sun, 21 Dec 2008 05:27:54 -0500
Message-Id: <5cc2d6892c2d864c1e4d296182126b4b.squirrel@webmail.ics.mq.edu.au>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: scontini@ics.mq.edu.au
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;charset=iso-8859-1
MIME-Version: 1.0
X-To: hash-forum@nist.gov
References: <20081220110335.11357.qmail@cr.yp.to>
In-Reply-To: <20081220110335.11357.qmail@cr.yp.to>
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sun, 21 Dec 2008 02:28:37 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 445


Dan Bernstein writes:

> Let me put it this way. If you're a hash-function designer, and you
> can't show us even _one_ interesting platform where the _fastest_
> unbroken variant of your hash function is within a factor of 2 of
> other unbroken candidates, then you're going to have an awfully
> difficult time convincing anyone that your function should be chosen as
> SHA-3. Why should cryptanalysts waste time looking at such functions?
>


For about 10 years, nobody had any idea how to attack SHA1.  Suddenly,
a few people (most notably Wang) were brave enough and clever enough to
attack it, and find that it has fundamental weaknesses in it.
"Nobody knows how to attack it" in some short period of time does
not imply that it is secure.  Given that the goal is to select SHA3 in
only 4 years, why should we believe some submission that is fast by this
metric will be secure for the next 10+ years?

If we accept your argument, it is feasible that some complex, hard to
analyse design appears (for the time being) to be far superior to other
candidates -- even if the design itself had no security justification
whatsoever.  It makes me feel like we would be repeating the course we
took with SHA1 (trusting something because we have so far failed to
attack it, even though it comes with no security justification).

The number one priority should be security.  Designs with proofs
(such as resistance to differential and linear attacks or security
reductions from well studied seemingly hard problems) that have reasonable
engineering properties are more desirable (in my view) than very fast
algorithms without proofs or convincing security justification --
provided that no flaws are found in the algorithms or proofs.  So yes,
I personally would prefer such a design even if it were 3 or 4 times
slower than the fastest candidate by your suggested metric.

Scott



From hash-forum@nist.gov  Sun Dec 21 22:15:33 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBM6FSnT018278
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Sun, 21 Dec 2008 22:15:29 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBM6EqNC011612;
	Mon, 22 Dec 2008 01:14:53 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBM6EXuY020875;
	Mon, 22 Dec 2008 01:14:33 -0500
Date: Mon, 22 Dec 2008 01:14:33 -0500
Message-Id: <0F627D67EE858D44BD1CEFEA67183F180743E4A3@CNSCNEVS03.ap.sony.com>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "Xu, Liangyu" 
To: Multiple recipients of list 
Subject: Re: Semi-free start collision attack on Blender
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-To: 
References: <0F627D67EE858D44BD1CEFEA67183F18073D552B@CNSCNEVS03.ap.sony.com>
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C963FB.6E4E0695"
MIME-Version: 1.0
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Sun, 21 Dec 2008 22:15:29 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-4.2 required=5.0 tests=AWL,BAYES_00,
	HTML_FONT_FACE_BAD,HTML_MESSAGE,RCVD_IN_DNSWL_MED,TRACKER_ID shortcircuit=no
	autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 446


This is a multi-part message in MIME format.

------_=_NextPart_001_01C963FB.6E4E0695
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable

Dear all,

=20

The paper about Semi-free start collision attack on Blender is now =
available on e-print: http://eprint.iacr.org/2008/532 .

=20

Best,

XU Liangyu=20

________________________________

=B7=A2=BC=FE=C8=CB: hash-forum@NIST.GOV [mailto:hash-forum@NIST.GOV] =
=B4=FA=B1=ED Xu, Liangyu
=B7=A2=CB=CD=CA=B1=BC=E4: 2008=C4=EA12=D4=C219=C8=D5 19:17
=CA=D5=BC=FE=C8=CB: Multiple recipients of list
=D6=F7=CC=E2: Semi-free start collision attack on Blender

=20

Dear all,

=20

We have found a semi-free start collision attack on Blender (all =
variants). The complexity of the attack is trivial so we can find=20

real message pairs colliding with a specified initial values (other than =
the initial values the designer gives).=20

  Following is an example of such a semi-free start collision message =
pairs. (For Blender-256)

The specified initial values:

a0=3Da1=3Da2=3Da3=3Da4=3Da5=3Da6=3Da7=3D0x00000000

Message 1:

00000000 00000000 00000000 00000000 00000000 ffffffff=20

Message 2:

00000000 00000000 00000000 00000000 ffffffff 00000000

Semi-free start collision hash digest:

f50b433f415f9700f50b433f415f9700f50b433f415f9700750b42fe04206f79

=20

The details of the attack will soon be available on e-print. Any comment =
is welcome.

=20

Best Regards,

XU Liangyu=20

Security Technology Research Department

Sony China Research Laboratory, Sony (China) Limited

=20


------_=_NextPart_001_01C963FB.6E4E0695
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable





















Dear =
all,



 <=
/span>



The paper about Semi-free start collision attack on Blender =
is now
available on e-print: http://eprint.iacr.org/2008/532<=
/a>




 



Best,






XU Liangyu =






















=B7=A2=BC=FE=
=C8=CB: =
hash-forum@NIST.GOV
[mailto:hash-forum@NIST.GOV] =B4=FA=B1=ED=
 Xu, =
Liangyu

=B7=A2=CB=CD=CA=B1=BC=E4: 2008=C4=EA12=D4=C219=C8=D5 19:17

=CA=D5=BC=FE=C8=CB: Multiple recipients =
of list

=D6=F7=CC=E2: Semi-free start collision attack on =
Blender






 



Dear all,



 



We have found a =
semi-free
start collision attack on Blender (all variants). The complexity of the =
attack
is trivial so we can find 



real message pairs colliding with a specified =
initial
values (other than the initial values the designer gives). =




  Following is an example of such a =
semi-free
start collision message pairs. (For =
Blender-256)



The specified initial =
values:



a0=3Da1=3Da2=3Da3=3Da4=3Da5=3Da6=3Da7=3D0x0000=
0000



Message =
1:



00000000
00000000 00000000 00000000 00000000 ffffffff =




Message =
2:



00000000 00000000
00000000 00000000 ffffffff 00000000



Semi-free
start collision hash digest:



f50b433f415f9700f50b433f415f9700f50b433f415f97=
00750b42fe04206f79



 



The details of =
the attack
will soon be available on e-print. Any comment is =
welcome.



 



Best Regards,



XU Liangyu 



Security
Technology Research Department



Sony China Research Laboratory, Sony =
(China)
Limited



 












------_=_NextPart_001_01C963FB.6E4E0695--

From hash-forum@nist.gov  Mon Dec 22 00:17:37 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBM8HWVx028915
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Mon, 22 Dec 2008 00:17:33 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBM8GsIc029566;
	Mon, 22 Dec 2008 03:16:54 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBM8Gh0X031165;
	Mon, 22 Dec 2008 03:16:43 -0500
Date: Mon, 22 Dec 2008 03:16:43 -0500
Message-Id: 
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "Jean-Philippe Aumasson" 
To: Multiple recipients of list 
Subject: Light implementation of BLAKE-32
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1
MIME-Version: 1.0
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 22 Dec 2008 00:17:33 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.3 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_DNSWL_MED,URI_HEX shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 447


I've published a new portable C implementation of BLAKE-32, which aims
to simplify the task of cryptanalysts (not to break speed records),
at:
http://www.131002.net/blake/blake32_light.c

The code for BLAKE-32 is less than 200 lines long, a test program is given.

Similar implementations will appear soon for BLAKE-28, -48-, and -64.

From hash-forum@nist.gov  Mon Dec 22 03:00:53 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBMB0mQv013590
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Mon, 22 Dec 2008 03:00:49 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBMB08Q7025777;
	Mon, 22 Dec 2008 06:00:11 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBMAxmPk016817;
	Mon, 22 Dec 2008 05:59:48 -0500
Date: Mon, 22 Dec 2008 05:59:48 -0500
Message-Id: 
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: Stefan.Lucks@uni-weimar.de
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: TEXT/PLAIN; charset=US-ASCII
MIME-Version: 1.0
References: <20081220110335.11357.qmail@cr.yp.to>
In-Reply-To: <20081220110335.11357.qmail@cr.yp.to>
X-To: Multiple recipients of list 
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 22 Dec 2008 03:00:49 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 448


On Sat, 20 Dec 2008, D. J. Bernstein wrote:

> Stefan.Lucks@uni-weimar.de writes:
>   [ regarding "provable security": ]
> > Actually, MD6 has the interesting property of provable security against 
> > certain types of differential attacks (the authors of MD6 called them 
> > "standard differential attacks"). Your mileage may vary, but I consider 
> > this as an amazing result. The MD6 team made a good selling point here!
> 
> How can you be amazed by this? 

As you quoted my writing: "Your mileage may vary." And yes, I remember the 
DFC fiasco. The same could happen to MD6, but it doesn't need to.

> > D. J. Bernstein wrote:
> > > Stefan similarly claims, without any justification, that Rivest doesn't
> > > have "confidence" in reduced-round variants of MD6. 
> > I didn't claim that. Please try not to misrepresent my writing!

[...]

>    * You said that ignoring reduced-round candidates is "reasonable!
>      The particular choice of defaults for the security parameters
>      reflects the designers' confidence into their creations. How could
>      the general public gain confidence into a version of a hash
>      function, if the designers of that hash function don't have that
>      confidence?" You continued by saying that selecting reduced-round
>      candidates would "undermine the credibility of SHA-3."

> If you're now withdrawing your claim regarding Rivest's confidence, then 
> what exactly is your argument against 24-round MD6?

Which part of "Please try not to misrepresent my writing!" is unclear to 
you? I didn't withdraw any claim I made before. 

And I didn't single out "Rivest" - I would consider this rather impolite 
to the other members of the MD6 team.  Please stop paraphrasing my writing 
such that it looks as if I had been so impolite!

Obviously the designers of MD6 are confident in 168 rounds (for 512-bit 
hashes), and they don't make any claims for reduced-round versions (for 
512-bit hashes, again). I have a lot of respect for their work, and I 
won't second-guess how they would consider reduced-round versions -- 
especially drastically reduced ones, with less than half the number of 
originally proposed rounds.

In any case, I am not against considering 24 rounds - or whatever number 
of rounds - of MD6, if its authors suggest that. But only then.

Dan, will you withdraw CubeHash, and adopt 24 rounds of MD6 as your 
proposal?

> > Imagine that the designers of MD6 -- or of any other hash function -- 
> > recommend a certain number of rounds, and the final standard ignores the 
> > recommendation. Instead, that hash function is standardised at a reduced 
> > number of rounds. Wouldn't that be ridiculous?
> 
> No. NIST said that [...]

Surprise, surprise! I agree with you that *technically* the rules would 
allow NIST to choose a reduced-round version against the authors' 
recommendations. But I would expect that to become a PR-desaster, and I am 
very confident that the NIST knows well enough to avoid that.

> Jason Martin writes:
>   [ regarding the value of self-cryptanalysis: ]
> > To me, there is much greater value in a submission where the author
> > has performed a good deal of security analysis and placed a "stake in
> > the ground" with respect to the performance/security trade-off.
> 
> Every AES submission ended up with third-party attacks that went beyond
> the best attacks originally described by the designers. Security was
> judged by the final attacks, not by the obsolete original attacks. Some
> of the original cryptanalysis was useful as a head start for subsequent
> cryptanalysis, but in the long term this benefit was negligible.

Sorry, Dan, you really miss the point here! 

Any security judgement does, of course, take into acount the best attack 
at that very point of time. But denouncing the attacks in the designers' 
original papers as "obsolete" is absurd for a couple of reasons:

Firstly, the cryptanalysis done by the authors shows how well they 
understand the security issues of their primitive. Typically, the 
designers have spent months with analysing the primitive, or preliminary 
variants of it. (I can confirm that we did this for Skein.) Thus, at least 
at the beginning, the designers ougth to understand the security issues of 
their primitives much better than anybody else. This doesn't contradict 
the expectation that some people will find some better attacs at some 
point of time. 

Secondly, while it is true that attacks always get better, and this was 
definitively true for the AES candidates, the attacks documented by the 
designers are an important landmark. As it turned out during the AES 
competition, the better candidates, especially all that became finalists, 
where about as secure as estimated by their designers. Better attacks than 
those described by the designers where found, but the improvements where 
limited.

Thirdly, most attacks where actually built by improving the attacks 
documented by the designers. E.g., the first attack against Rijndael, that 
doesn't somehow built upon the "Square" attack described by the Rijndael 
designers, was the algebraic attack by by Courtois and Pieprzyk, published 
at Asiacrpt 2002 -- a few years after Rijndael was chosen as the AES. As 
it turned out later, that attack didn't even work as advertised.

> Christian Rechberger writes:
>   [ regarding the definition of "unbroken": ]
> > How to rank and compare known-key distinguisher, related-key-boomerang
> > attacks on some underlying block cipher, nonrandom properties of
> > underlying permutations, or various forms of (pseudo)/(near)/collisions
> > and (2nd)-preimage attacks on some compression functions to results
> > obtained on the actual hash function?
> 
> Read the submission requirements! 

[Listing the usual standard attacks]

Resistance against "nonstandard" attacks is an important part of what is 
needed to built up confidence. I would prefer a hash function with the 
best attack at 70 from 100 rounds, over one where the best standard 
attacks is at 30 from 100 rounds, but with some unusual nonstandard 
weakness (some distinguishining property or whatever) at 90 from 100 
rounds. 

> An attack "on some underlying block cipher" etc. is typically _not_ an
> attack recognized by the rules and should be disregarded unless it can
> be converted into an attack recognized by the rules. 

You repeat yourself: "... recognised by the rules ... recognised by the 
rules." Cryptography is in part an art, and in part a science. It can't be 
done just mechanically, by applying some given set of rules.

Nonstandard attacks, such as as those against the underlying block cipher, 
don't immediately disqualify a candidate. But:
  (a) They are often usuful as an intermediate step 
      to find improved standad attacks.
  (b) In any case, the are very useful to understand 
      the securit of a candidate, and its limits ...

Technically, nonstandard attacks tell us as much about the security of a 
candidate (with its full number of rounds) as attacks on a reduced number 
of rounds.

So long

Stefan

-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------


From hash-forum@nist.gov  Mon Dec 22 04:24:16 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBMCOAXo025032
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Mon, 22 Dec 2008 04:24:11 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBMCNVYM019521;
	Mon, 22 Dec 2008 07:23:31 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBMCNHYN016961;
	Mon, 22 Dec 2008 07:23:17 -0500
Date: Mon, 22 Dec 2008 07:23:17 -0500
Message-Id: <20081222122433.35341.qmail@cr.yp.to>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "D. J. Bernstein" 
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
In-Reply-To: <5cc2d6892c2d864c1e4d296182126b4b.squirrel@webmail.ics.mq.edu.au> <72CF8F2B2766084DBD7AEAFCAE4A3B7909736B15@frsnprexc1.usr.ingenico.loc> <7bb08a5f0812200920o51d7a47bo925ec424f39ddd62@mail.gmail.com> <20081220185644.64577um0burnf6jk@webmail.tugraz.at> 
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 22 Dec 2008 04:24:11 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords:                 
X-UID: 449


Jason Martin writes:
> Perhaps during or after the Leuven conference NIST can provide all the
> submitters with a more precise criteria of how the second round
> choices will be made and exactly how performance data will factor in
> those decisions.

NIST has said that this will be a "major topic" in Leuven, meaning that
it still doesn't plan to have made up its mind at that point. On the
bright side, I think we're facing more than 10 reasonable choices of
SHA-3, and having some choices randomly eliminated by unpredictable
rules isn't going to stop us from settling on a good standard.

Christian Rechberger writes:
> There are many
> aspects in addition to "fastest unbroken variant" to consider when
> * choosing "interesting" candidates for cryptanalysis
> * scaling down the number of candidates from 51 to e.g. 15 and less

Of course there are. I've already given several examples, ranging from
FSB to extra multicollision resistance.

However, if every variant of your SuperProvableHash below 15 cycles/byte
has been broken (despite all the hype regarding SuperProvability), while
ConventionalHash at 5 cycles/byte resists years of focused cryptanalysis,
then users will see scaled-up ConventionalHash at 15 cycles/byte as a
confidence-inspiring choice for SHA-3, certainly much better than the
edge-of-disaster SuperProvableHash at 15 cycles/byte.

Yes, there are different performance measures. If you can show that
SuperProvableHash is competitive in (e.g.) ASIC performance, great! But
if you can't---if avoiding attacks on SuperProvableHash costs three
times as much in every important performance measure as avoiding attacks
on ConventionalHash---then I don't see how SuperProvableHash can win,
and I don't see why cryptanalysts should waste time looking at it. I
think that 2x is a reasonable cutoff.

Scott Contini writes:
> For about 10 years, nobody had any idea how to attack SHA1.

For about 10 years, cryptanalysts were focusing on block ciphers, with
only occasional glances at hash functions. The first SHA-1 paper jumped
to a 53-round attack, and the second paper jumped to a full 80-round
attack. It's indisputably important to have enough cryptanalytic time
spent on the eventual SHA-3---which is why we're talking about ways to
avoid having cryptanalytic time wasted on hashes that clearly won't win.

> Designs with proofs (such as resistance to differential and linear
> attacks or security reductions from well studied seemingly hard
> problems) that have reasonable engineering properties are more
> desirable (in my view) than very fast algorithms without proofs or
> convincing security justification

Gee, why does this sound familiar? Let's go back to the videotape of the 
DFC announcement from ten years ago:

   So far, real-life encryption algorithms used to have an
   empirical-based security: they were designed from an intricate
   substitution-permutation network and believed to be secure until
   someone published an attack on them. ... [We have] recently developed
   a technique for making new encryption algorithms with a provable
   security against any iterated attacks of a fixed order (e.g. of order
   2). ... Provable security is an important added value for
   cryptographic algorithms and is currently a hot topic in
   international conferences.

You complain about "trusting something because we have so far failed to
attack it." The DFC designers were saying the same thing, and offering
"provable security" as a solution. They proved security of 6-round DFC,
recommended 8-round DFC, and said that adding more rounds would not be
"meaningful."

You say that tolerably fast designs with proofs are "more desirable"
than really fast designs without proofs. That's what the DFC designers
were saying too: provable security is an "important added value." For
example, 6-round DFC had this "important added value," and according to
you is "more desirable" than (e.g.) 16-round Serpent.

Knudsen and Rijmen then broke the "provably secure" 6-round DFC. What an
embarrassment for "provable security"! What a perfect illustration of
the importance of cryptanalysis!

The ultimate reason for confidence in SHA-3 will be that we have tried,
and failed, to attack it. Some types of attacks will be explored quite
thoroughly, and maybe formalized as theorems showing that those types of
attacks can't work, but this merely means that future cryptanalysts will
have to try different types of attacks.

> it is feasible that some complex, hard to
> analyse design appears (for the time being) to be far superior

As a designer I generally aim for simplicity---but maybe I shouldn't;
maybe a more complex design provides better security for the same
performance. Whether the leaders are simple or complex, we need to
ensure that enough cryptanalytic time is spent on them, eliminating the
breakable designs and building confidence in the remaining designs.

Thomas Peyrin writes:
> I don't agree that "our limited cryptanalytic
> resources should be focused on the efficient submissions", I would say
> "cryptanalytic resources should be focused on the efficient submissions
> for a secure number of rounds claimed by the designers".

Let me see if I understand what you're saying. Full 168-round MD6 is
rather inefficient, so (like Niels) you want cryptanalysts to focus on
faster submissions, ignoring MD6?

If that's what you mean, I wholeheartedly disagree. I support the idea
of focusing cryptanalysis, and I support the use of performance as a
focusing mechanism, but I object to the idea of mindlessly disregarding
reduced-round members of the MD6 family---especially after the rules
specifically allowed tunable parameters. Yes, Rivest recommended quite
conservative round counts, but that's not a legitimate excuse for
ignoring smaller round counts. Reduced-round MD6 appears to achieve
security at reasonably high speed; in the short term it is a natural
cryptanalytic target, and in the long term it might be the best SHA-3
candidate. 

Similarly, I find it silly to disregard cryptanalytic results on MD6
merely because they don't break full-round MD6. For example, someone
breaking _twice as many rounds_ of reduced-round MD6 is having a huge
effect on the MD6 security margin and taking a big step forwards in MD6
cryptanalysis, even though the attack doesn't affect full-round MD6.

If you meant something else, you'll need to explain more clearly.

Stefan Lucks writes:
> In any case, I am not against considering 24 rounds - or whatever
> number of rounds - of MD6, if its authors suggest that. But only then.

The submission says "The round parameter r is exposed in the MD6 API, so
it may be explicitly varied by the user. This is done since
reduced-round versions of MD6 may be of interest for security analysis,
or for applications with tight timing constraints and reduced security
requirements. Or, one could increase r above the default to accommodate
various levels of paranoia. ... Arguably, the current need to consider a
new hash function standard might have seemed unnecessary if the API for
the prior standards had included a variable number of rounds. ...
Perhaps after further study, the default number of rounds for MD6 could
be justifiably and significantly reduced."

This is clearly a tunable security parameter allowing adjustment of the
security/performance tradeoff, exactly as allowed by the rules. Are you
still refusing to consider reduced-round MD6? Is the submission text not
a sufficiently clear "suggestion" for you? What sort of text would
qualify as a "suggestion" in your mind?

> the cryptanalysis done by the authors shows how well they
> understand the security issues of their primitive.

There's no point in discussing the extent to which this is true. NIST is
running a competition for the best hash function, not for the position
of cryptanalyst-in-chief. 

It's nice to hear that you've put lots of work into cryptanalyzing Skein
and your pre-Skein rejects, but I'm sure that subsequent third-party
cryptanalysis will produce better attacks, as it did for every AES
candidate---in some cases quite dramatically.

> Resistance against "nonstandard" attacks is an important part of what is
> needed to built up confidence.

No. The obvious counterexample, once again, is the flood of ridiculous
announcements of "free-start collision attacks" on various sponge-like
SHA-3 submissions.

---D. J. Bernstein 
   Research Professor, Computer Science, University of Illinois at Chicago

From hash-forum@nist.gov  Mon Dec 22 05:05:19 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBMD5EVO028911
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Mon, 22 Dec 2008 05:05:15 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBMD4eik019740;
	Mon, 22 Dec 2008 08:04:41 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBMD4TVj002994;
	Mon, 22 Dec 2008 08:04:29 -0500
Date: Mon, 22 Dec 2008 08:04:29 -0500
Message-Id: <7731938b0812220502q27053904mf096ed5337e949f3@mail.gmail.com>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "Peter Maxwell" 
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
References: <5cc2d6892c2d864c1e4d296182126b4b.squirrel@webmail.ics.mq.edu.au> <72CF8F2B2766084DBD7AEAFCAE4A3B7909736B15@frsnprexc1.usr.ingenico.loc> <7bb08a5f0812200920o51d7a47bo925ec424f39ddd62@mail.gmail.com> <20081220185644.64577um0burnf6jk@webmail.tugraz.at>  <20081222122433.35341.qmail@cr.yp.to>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1
MIME-Version: 1.0
In-Reply-To: <20081222122433.35341.qmail@cr.yp.to>
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 22 Dec 2008 05:05:15 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 450


Comments inline...

>
> Gee, why does this sound familiar? Let's go back to the videotape of the
> DFC announcement from ten years ago:
>
>   So far, real-life encryption algorithms used to have an
>   empirical-based security: they were designed from an intricate
>   substitution-permutation network and believed to be secure until
>   someone published an attack on them. ... [We have] recently developed
>   a technique for making new encryption algorithms with a provable
>   security against any iterated attacks of a fixed order (e.g. of order
>   2). ... Provable security is an important added value for
>   cryptographic algorithms and is currently a hot topic in
>   international conferences.
>
> You complain about "trusting something because we have so far failed to
> attack it." The DFC designers were saying the same thing, and offering
> "provable security" as a solution. They proved security of 6-round DFC,
> recommended 8-round DFC, and said that adding more rounds would not be
> "meaningful."
>
> You say that tolerably fast designs with proofs are "more desirable"
> than really fast designs without proofs. That's what the DFC designers
> were saying too: provable security is an "important added value." For
> example, 6-round DFC had this "important added value," and according to
> you is "more desirable" than (e.g.) 16-round Serpent.
>
> Knudsen and Rijmen then broke the "provably secure" 6-round DFC. What an
> embarrassment for "provable security"! What a perfect illustration of
> the importance of cryptanalysis!
>
> The ultimate reason for confidence in SHA-3 will be that we have tried,
> and failed, to attack it. Some types of attacks will be explored quite
> thoroughly, and maybe formalized as theorems showing that those types of
> attacks can't work, but this merely means that future cryptanalysts will
> have to try different types of attacks.
>

I'm definitely in agreement here.  One has to be very careful when
handling security "proofs" as they generally only prove some property
and not that the construction is in every sense "secure".  The
derivations used to justify the security of Rijndael were quite
instructive as they proved not only preferential properties about
differential/linear trails, but also that there are certain unwanted
properties that are impossible to eliminate (with regards to their
definitions of differential and linear trails).  Their analysis was
also very focused and didn't make any claims outside the derivations.
So what can we say about the security of AES now?  Well, the main
thing is that nobody has publicly been able to break it, which is
probably about as good as it gets.  How do we practically tell in a
short time whether an algorithm is likely to survive another decade or
two of analysis... we strip it right down and find out what we can
analyse and break.  We can then look at how much more difficult
another round or small parameter change makes the analysis and build
it up from there.  So Daniel's approach seems pretty sensible to me,
that way we can see how much "bang-for-our-buck" we get as concerns
performance/security.





>
> It's nice to hear that you've put lots of work into cryptanalyzing Skein
> and your pre-Skein rejects, but I'm sure that subsequent third-party
> cryptanalysis will produce better attacks, as it did for every AES
> candidate---in some cases quite dramatically.
>
>> Resistance against "nonstandard" attacks is an important part of what is
>> needed to built up confidence.
>
> No. The obvious counterexample, once again, is the flood of ridiculous
> announcements of "free-start collision attacks" on various sponge-like
> SHA-3 submissions.

I also agree here.  If there is a serious attack on a algorithm (which
there have been quite a few so far in a very short space of time),
then fantastic, however this "free-start" nonsense really isn't doing
anybody much good.  A "nonstandard" attack doesn't really mean
anything if the attack threatens the security of the algorithm in a
very real way (at least a certain selection of parameters) - it has
the same effect as a "standard" attack, viz the algorithm with those
parameters is rejected and either new parameters selected or the
algorithm is binned.



Best wishes,

Peter Maxwell

From hash-forum@nist.gov  Mon Dec 22 06:15:16 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBMEF9X7003176
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Mon, 22 Dec 2008 06:15:11 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBMEECcK015927;
	Mon, 22 Dec 2008 09:14:15 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBMEE2Mu018816;
	Mon, 22 Dec 2008 09:14:02 -0500
Date: Mon, 22 Dec 2008 09:14:02 -0500
Message-Id: <72CF8F2B2766084DBD7AEAFCAE4A3B7909795CBC@frsnprexc1.usr.ingenico.loc>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "Thomas PEYRIN" 
To: Multiple recipients of list 
Subject: RE: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-To: 
References: <20081222122433.35341.qmail@cr.yp.to>
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9643E.DAEFFD45"
MIME-Version: 1.0
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 22 Dec 2008 06:15:11 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 451


This is a multi-part message in MIME format.

------_=_NextPart_001_01C9643E.DAEFFD45
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

=20

-----Message d'origine-----
De : hash-forum@nist.gov [mailto:hash-forum@nist.gov] De la part de D. =
J. Bernstein
Envoy=C3=A9 : lundi 22 d=C3=A9cembre 2008 13:22
=C3=80 : Multiple recipients of list
Objet : Re: Engineering comparison of the SHA-3 candidates

=20

Thomas Peyrin writes:

> I don't agree that "our limited cryptanalytic

> resources should be focused on the efficient submissions", I would say

> "cryptanalytic resources should be focused on the efficient =
submissions

> for a secure number of rounds claimed by the designers".

=20

Let me see if I understand what you're saying. Full 168-round MD6 is

rather inefficient, so (like Niels) you want cryptanalysts to focus on

faster submissions, ignoring MD6?

=20

If that's what you mean, I wholeheartedly disagree. I support the idea

of focusing cryptanalysis, and I support the use of performance as a

focusing mechanism, but I object to the idea of mindlessly disregarding

reduced-round members of the MD6 family---especially after the rules

specifically allowed tunable parameters. Yes, Rivest recommended quite

conservative round counts, but that's not a legitimate excuse for

ignoring smaller round counts. Reduced-round MD6 appears to achieve

security at reasonably high speed; in the short term it is a natural

cryptanalytic target, and in the long term it might be the best SHA-3

candidate.=20

=20

Similarly, I find it silly to disregard cryptanalytic results on MD6

merely because they don't break full-round MD6. For example, someone

breaking _twice as many rounds_ of reduced-round MD6 is having a huge

effect on the MD6 security margin and taking a big step forwards in MD6

cryptanalysis, even though the attack doesn't affect full-round MD6.

=20

If you meant something else, you'll need to explain more clearly.

=20

=20

I was talking about the question: what is the best "way" to do the =
competition regarding security claims and tunable parameters. This is =
now useless as the competition already begun and as everybody can see, =
designers submitted different schemes with different security claims =
policies. Now, the world isn't black and white only, I don't think it =
will be fair to forget about MD6 because the full version is =
conservative and slow, but I don't think neither it would be fair to =
analyse the "fastest and unbroken" versions of the schemes only. I think =
we should aim for a tradeoff between "design philosophy" and "fastest =
unbroken parameters".=20

=20

Thomas.

=20


=20
About Ingenico: Ingenico is the world=E2=80=99s leading provider of =
payment solutions, with over 15 million terminals deployed across the =
globe. Delivering the very latest secure electronic payment =
technologies, transaction management and the widest range of value added =
services, Ingenico is shaping the future direction of the payment =
solutions market. Leveraging on its global presence and local expertise, =
Ingenico is reinforcing its leadership by taking banks and businesses =
beyond payment through offering comprehensive solutions, a true source =
of differentiation and new revenues streams.
 This message may contain confidential and/or privileged information. If =
you are not the addressee or authorized to receive this for the =
addressee, you must not use, copy, disclose or take any action based on =
this message or any information herein. If you have received this =
message in error, please advise the sender immediately by reply e-mail =
and delete this message. Thank you for your cooperation.
 P Please consider the environment before printing this e-mail
=20
=20

------_=_NextPart_001_01C9643E.DAEFFD45
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable









Notice








 



-----Message d'origine-----

De : hash-forum@nist.gov
[mailto:hash-forum@nist.gov] De la
part de D. J. Bernstein

Envoy=C3=A9 : lundi 22 d=C3=A9cembre 2008 13:22

=C3=80 : Multiple recipients of list

Objet : Re: Engineering comparison of the SHA-3 =
candidates



 



Thomas =
Peyrin writes:



> I =
don't agree that "our limited
cryptanalytic



> =
resources should be focused on the efficient
submissions", I would say



> =
"cryptanalytic resources should be focused
on the efficient submissions



> for =
a secure number of rounds claimed by the
designers".



 



Let me =
see if I understand what you're saying. Full
168-round MD6 is



rather =
inefficient, so (like Niels) you want
cryptanalysts to focus on



faster =
submissions, ignoring MD6?



 



If that's =
what you mean, I wholeheartedly disagree. I
support the idea



of =
focusing cryptanalysis, and I support the use of
performance as a



focusing =
mechanism, but I object to the idea of
mindlessly disregarding



reduced-round members of the MD6 =
family---especially
after the rules



specifically allowed tunable parameters. Yes, =
Rivest
recommended quite



conservative round counts, but that's not a =
legitimate
excuse for



ignoring =
smaller round counts. Reduced-round MD6
appears to achieve



security =
at reasonably high speed; in the short term
it is a natural



cryptanalytic target, and in the long term it =
might be
the best SHA-3



candidate. 



 



Similarly, I find it silly to disregard =
cryptanalytic
results on MD6



merely =
because they don't break full-round MD6. For
example, someone



breaking =
_twice as many rounds_ of reduced-round MD6
is having a huge



effect on =
the MD6 security margin and taking a big
step forwards in MD6



cryptanalysis, even though the attack doesn't =
affect
full-round MD6.



 



If you =
meant something else, you'll need to explain
more clearly.



 


 


I was =
talking about the question:
what is the best “way” to do the competition regarding =
security
claims and tunable parameters. This is now useless as the competition =
already
begun and as everybody can see, designers submitted different schemes =
with
different security claims policies. Now, the world isn’t black and =
white
only, I don’t think it will be fair to forget about MD6 because =
the full
version is conservative and slow, but I don’t think neither it =
would be
fair to analyse the “fastest and unbroken” versions of the =
schemes
only. I think we should aim for a tradeoff between “design =
philosophy”
and “fastest unbroken parameters”. 



 



Thomas.



 







 




About =
Ingenico: Ingenico is the world=E2=80=99s =
leading provider of payment solutions, with over 15 million terminals =
deployed across the globe. Delivering =
the very latest secure electronic payment technologies, transaction =
management and the widest range of value added services, Ingenico is =
shaping the future direction of the payment solutions market. Leveraging =
on its global presence and local expertise, Ingenico is reinforcing its =
leadership by taking banks and businesses beyond payment through =
offering comprehensive solutions, a true source of differentiation and =
new revenues streams.


 This message may contain =
confidential and/or privileged information. If you are not the addressee =
or authorized to receive this for the addressee, you must not use, copy, =
disclose or take any action based on this message or any information =
herein. If you have received this message in error, please advise the =
sender immediately by reply e-mail and delete this message. Thank you =
for your cooperation.


 P Please consider the environment before printing =
this e-mail


 




 


------_=_NextPart_001_01C9643E.DAEFFD45--

From hash-forum@nist.gov  Mon Dec 22 06:29:05 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBMESxiV004467
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Mon, 22 Dec 2008 06:29:00 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBMESQ8Y031349;
	Mon, 22 Dec 2008 09:28:27 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBMES7TN016761;
	Mon, 22 Dec 2008 09:28:07 -0500
Date: Mon, 22 Dec 2008 09:28:07 -0500
Message-Id: 
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: Charanjit Jutla 
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: text/plain; charset="US-ASCII"
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
MIME-Version: 1.0
In-Reply-To: <20081222122433.35341.qmail@cr.yp.to>
X-Cc: Multiple recipients of list 
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 22 Dec 2008 06:29:00 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 452


[Dan Bernstein writes:]
> However, if every variant of your SuperProvableHash below 15 cycles/byte
> has been broken (despite all the hype regarding SuperProvability), while
> ConventionalHash at 5 cycles/byte resists years of focused 
cryptanalysis,
> then users will see scaled-up ConventionalHash at 15 cycles/byte as a
> confidence-inspiring choice for SHA-3, certainly much better than the
> edge-of-disaster SuperProvableHash at 15 cycles/byte.
> 
> Yes, there are different performance measures. If you can show that
> SuperProvableHash is competitive in (e.g.) ASIC performance, great! But
> if you can't---if avoiding attacks on SuperProvableHash costs three
> times as much in every important performance measure as avoiding attacks
> on ConventionalHash---then I don't see how SuperProvableHash can win,
> and I don't see why cryptanalysts should waste time looking at it. I
> think that 2x is a reasonable cutoff.

One can also spin this argument the other way.  If you are not 10X times 
faster,
while providing no justification of why your hash function is secure, then 
I do not see
why people should waste time on this proposal. Ok, that maybe a bit of a 
stretch,
but here is a more realistic look at how things stand in this discussion:

1. While DFC was broken, it cannot be called an embarrassment. For one 
thing, as soon as
   you prove certain things under assumptions, the cryptanalysts get 
excited about what could 
   be wrong with the assumptions...and sure enough KR managed to hone in 
on the wrong aspects
   of the assumptions.

2. DFC is an example of a theoretical construct, with lipstick on, and 
being passed as a real world
   cipher. The designer of DFC, for whom I have great respect, is not well 
known as a practical cipher
   designer, and many a smart people have made bad calls on assumptions. 
Same can not be said for MD6,
   whose designers include ...

3. Scott Contini makes the right point that we need to look at why we are 
in this competition in the 
   first place. SHA-1 was broken because it had some bad differential 
properties. It has been amply demonstrated
   how to defend against these attacks without much change in design 
philosophy (just using slightly better codes
   ...and this has been done in MD6 and some other designs). Now per se, 
it doesn't prove anything against some
   new kinds of attacks (say algebraic, or in case of MD6...what is beyond 
their simple differential resistance proof).
   But at the very least we know what is defended, and what the 
assumptions are. This is a great help for
   cryptanalysts, as they can now focus on the assumptions, and/or other 
kinds of attacks. 

   I think the "polite" thing to do for all submitters is to AT THE LEAST 
provide justification (make whatever
   assumptions you want to make) as to why simple differential attacks 
would not work against user SuperFastHash.
   You still have 6 months to do this, and if you pass thru round 1, you 
have 1 year. Otherwise I do not
   see why good cryptanalytic minds should waste their time on these 
SuperFastHash, knowing that the ciphers maybe
   providing security against "simple differential attacks" by obscurity. 
Just because a cipher is easy to describe,
   and uses only carry bits as non-linearity, it doesn't mean it makes the 
task of the cryptanalysts easier. What makes
   his task easier is if you write down your assumptions, and then prove 
something about it. The "simple differential 
   attacks" doomed SHA-1, so please show how you defend against it. We 
will worry about other things later. Once that
   is out of the way, we can focus on the assumptions, and other algebraic 
attacks...or what have you.

-Charanjit

> 
> Scott Contini writes:
> > For about 10 years, nobody had any idea how to attack SHA1.
> 
> For about 10 years, cryptanalysts were focusing on block ciphers, with
> only occasional glances at hash functions. The first SHA-1 paper jumped
> to a 53-round attack, and the second paper jumped to a full 80-round
> attack. It's indisputably important to have enough cryptanalytic time
> spent on the eventual SHA-3---which is why we're talking about ways to
> avoid having cryptanalytic time wasted on hashes that clearly won't win.
> 
> > Designs with proofs (such as resistance to differential and linear
> > attacks or security reductions from well studied seemingly hard
> > problems) that have reasonable engineering properties are more
> > desirable (in my view) than very fast algorithms without proofs or
> > convincing security justification
> 
> Gee, why does this sound familiar? Let's go back to the videotape of the 

> DFC announcement from ten years ago:
> 
>    So far, real-life encryption algorithms used to have an
>    empirical-based security: they were designed from an intricate
>    substitution-permutation network and believed to be secure until
>    someone published an attack on them. ... [We have] recently developed
>    a technique for making new encryption algorithms with a provable
>    security against any iterated attacks of a fixed order (e.g. of order
>    2). ... Provable security is an important added value for
>    cryptographic algorithms and is currently a hot topic in
>    international conferences.
> 
> You complain about "trusting something because we have so far failed to
> attack it." The DFC designers were saying the same thing, and offering
> "provable security" as a solution. They proved security of 6-round DFC,
> recommended 8-round DFC, and said that adding more rounds would not be
> "meaningful."
> 
> You say that tolerably fast designs with proofs are "more desirable"
> than really fast designs without proofs. That's what the DFC designers
> were saying too: provable security is an "important added value." For
> example, 6-round DFC had this "important added value," and according to
> you is "more desirable" than (e.g.) 16-round Serpent.
> 
> Knudsen and Rijmen then broke the "provably secure" 6-round DFC. What an
> embarrassment for "provable security"! What a perfect illustration of
> the importance of cryptanalysis!
> 
> The ultimate reason for confidence in SHA-3 will be that we have tried,
> and failed, to attack it. Some types of attacks will be explored quite
> thoroughly, and maybe formalized as theorems showing that those types of
> attacks can't work, but this merely means that future cryptanalysts will
> have to try different types of attacks.
> 
> > it is feasible that some complex, hard to
> > analyse design appears (for the time being) to be far superior
> 
> As a designer I generally aim for simplicity---but maybe I shouldn't;
> maybe a more complex design provides better security for the same
> performance. Whether the leaders are simple or complex, we need to
> ensure that enough cryptanalytic time is spent on them, eliminating the
> breakable designs and building confidence in the remaining designs.
> 
> Thomas Peyrin writes:
> > I don't agree that "our limited cryptanalytic
> > resources should be focused on the efficient submissions", I would say
> > "cryptanalytic resources should be focused on the efficient 
submissions
> > for a secure number of rounds claimed by the designers".
> 
> Let me see if I understand what you're saying. Full 168-round MD6 is
> rather inefficient, so (like Niels) you want cryptanalysts to focus on
> faster submissions, ignoring MD6?
> 
> If that's what you mean, I wholeheartedly disagree. I support the idea
> of focusing cryptanalysis, and I support the use of performance as a
> focusing mechanism, but I object to the idea of mindlessly disregarding
> reduced-round members of the MD6 family---especially after the rules
> specifically allowed tunable parameters. Yes, Rivest recommended quite
> conservative round counts, but that's not a legitimate excuse for
> ignoring smaller round counts. Reduced-round MD6 appears to achieve
> security at reasonably high speed; in the short term it is a natural
> cryptanalytic target, and in the long term it might be the best SHA-3
> candidate. 
> 
> Similarly, I find it silly to disregard cryptanalytic results on MD6
> merely because they don't break full-round MD6. For example, someone
> breaking _twice as many rounds_ of reduced-round MD6 is having a huge
> effect on the MD6 security margin and taking a big step forwards in MD6
> cryptanalysis, even though the attack doesn't affect full-round MD6.
> 
> If you meant something else, you'll need to explain more clearly.
> 
> Stefan Lucks writes:
> > In any case, I am not against considering 24 rounds - or whatever
> > number of rounds - of MD6, if its authors suggest that. But only then.
> 
> The submission says "The round parameter r is exposed in the MD6 API, so
> it may be explicitly varied by the user. This is done since
> reduced-round versions of MD6 may be of interest for security analysis,
> or for applications with tight timing constraints and reduced security
> requirements. Or, one could increase r above the default to accommodate
> various levels of paranoia. ... Arguably, the current need to consider a
> new hash function standard might have seemed unnecessary if the API for
> the prior standards had included a variable number of rounds. ...
> Perhaps after further study, the default number of rounds for MD6 could
> be justifiably and significantly reduced."
> 
> This is clearly a tunable security parameter allowing adjustment of the
> security/performance tradeoff, exactly as allowed by the rules. Are you
> still refusing to consider reduced-round MD6? Is the submission text not
> a sufficiently clear "suggestion" for you? What sort of text would
> qualify as a "suggestion" in your mind?
> 
> > the cryptanalysis done by the authors shows how well they
> > understand the security issues of their primitive.
> 
> There's no point in discussing the extent to which this is true. NIST is
> running a competition for the best hash function, not for the position
> of cryptanalyst-in-chief. 
> 
> It's nice to hear that you've put lots of work into cryptanalyzing Skein
> and your pre-Skein rejects, but I'm sure that subsequent third-party
> cryptanalysis will produce better attacks, as it did for every AES
> candidate---in some cases quite dramatically.
> 
> > Resistance against "nonstandard" attacks is an important part of what 
is
> > needed to built up confidence.
> 
> No. The obvious counterexample, once again, is the flood of ridiculous
> announcements of "free-start collision attacks" on various sponge-like
> SHA-3 submissions.
> 
> ---D. J. Bernstein 
>    Research Professor, Computer Science, University of Illinois at 
Chicago
> 


From hash-forum@nist.gov  Mon Dec 22 06:43:00 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBMEgtvF005520
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Mon, 22 Dec 2008 06:42:56 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBMEgQYH008663;
	Mon, 22 Dec 2008 09:42:29 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBMEg8kl011925;
	Mon, 22 Dec 2008 09:42:08 -0500
Date: Mon, 22 Dec 2008 09:42:08 -0500
Message-Id: 
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: Stefan.Lucks@uni-weimar.de
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: TEXT/PLAIN; charset=US-ASCII
MIME-Version: 1.0
References: <20081222122433.35341.qmail@cr.yp.to>
In-Reply-To: <20081222122433.35341.qmail@cr.yp.to>
X-To: Multiple recipients of list 
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 22 Dec 2008 06:42:56 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 453


On Mon, 22 Dec 2008, D. J. Bernstein wrote:

> Stefan Lucks writes:
> > In any case, I am not against considering 24 rounds - or whatever
> > number of rounds - of MD6, if its authors suggest that. But only then.
> 
> The submission says "The round parameter r is exposed in the MD6 API, so
> it may be explicitly varied by the user. This is done since
> reduced-round versions of MD6 may be of interest for security analysis,
> or for applications with tight timing constraints and reduced security
> requirements. Or, one could increase r above the default to accommodate
> various levels of paranoia. ... Arguably, the current need to consider a
> new hash function standard might have seemed unnecessary if the API for
> the prior standards had included a variable number of rounds. ...
> Perhaps after further study, the default number of rounds for MD6 could
> be justifiably and significantly reduced."
> 
> This is clearly a tunable security parameter allowing adjustment of the
> security/performance tradeoff, exactly as allowed by the rules. Are you
> still refusing to consider reduced-round MD6? Is the submission text not
> a sufficiently clear "suggestion" for you? 

Not at all!

> What sort of text would qualify as a "suggestion" in your mind?

I expect a clear statement, which number of rounds is recommended for a 
certain hash size or for certain security requirements. This is the point, 
where the cryptanalyst can claim "I have broken MD6" , and this is 
precisely what I mean by stressing that designers' recommendation reflects 
the confidence in their construction. The MD6 document actually provides 
such a recommendation. 

I don't see any reason to override their recommendation -- even if their 
API provides a way to do so.

You didn't answer my question: Are you going to abandon CubeHash, and to 
propose MD6 reduced to 24 rounds? 

> > Resistance against "nonstandard" attacks is an important part of what is
> > needed to built up confidence.
> 
> No. The obvious counterexample, once again, is the flood of ridiculous
> announcements of "free-start collision attacks" on various sponge-like
> SHA-3 submissions.

Actually, I find these attacks really interesting! Your mileage clearly 
varies. ;-)

So long

Stefan


-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------


From hash-forum@nist.gov  Mon Dec 22 10:11:06 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBMIB11v028091
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Mon, 22 Dec 2008 10:11:02 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBMIAQ3O024263;
	Mon, 22 Dec 2008 13:10:28 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBMIACVp016196;
	Mon, 22 Dec 2008 13:10:12 -0500
Date: Mon, 22 Dec 2008 13:10:12 -0500
Message-Id: 
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: Stefan.Lucks@uni-weimar.de
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: TEXT/PLAIN; charset=US-ASCII
MIME-Version: 1.0
References: <20081222122433.35341.qmail@cr.yp.to>  
In-Reply-To: 
X-To: Multiple recipients of list 
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 22 Dec 2008 10:11:03 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords:                 
X-UID: 454


On Mon, 22 Dec 2008, Paul Hoffman wrote:

> That expectation is not in line with what NIST asked for in its call for 
> submissions. *You* might expect that, but unless NIST adds a request for 
> such a statement, it is not reasonable to expect submitters to make one.

Well, NIST explicitely asked for the reference implementations to support 
their API. The NIST API assumes fixed security parameters. That means, 
NIST did actually force all submitters to make some default choices for 
their tunable parameters. If these default choices aren't deliberate (and 
that would hardly count as an advertising point in favour of a hash 
functions), they are the submitters recommendations.


So long

Stefan

-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------


From hash-forum@nist.gov  Mon Dec 22 11:22:21 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBMJMEVn003807
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Mon, 22 Dec 2008 11:22:16 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBMJLhmI031653;
	Mon, 22 Dec 2008 14:21:43 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBMJLL63028439;
	Mon, 22 Dec 2008 14:21:21 -0500
Date: Mon, 22 Dec 2008 14:21:21 -0500
Message-Id: 
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: Paul Hoffman 
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: text/plain; charset="us-ascii"
X-To: hash-forum@nist.gov
References: <20081222122433.35341.qmail@cr.yp.to>   
In-Reply-To:  
Mime-Version: 1.0
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 22 Dec 2008 11:22:16 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 455


At 1:08 PM -0500 12/22/08, Stefan.Lucks@uni-weimar.de wrote:
>On Mon, 22 Dec 2008, Paul Hoffman wrote:
>
>> That expectation is not in line with what NIST asked for in its call for
>> submissions. *You* might expect that, but unless NIST adds a request for
>> such a statement, it is not reasonable to expect submitters to make one.
>
>Well, NIST explicitely asked for the reference implementations to support
>their API. The NIST API assumes fixed security parameters. That means,
>NIST did actually force all submitters to make some default choices for
>their tunable parameters. If these default choices aren't deliberate (and
>that would hardly count as an advertising point in favour of a hash
>functions), they are the submitters recommendations.

You have conflated two separate parts of the submission. I propose that you let NIST say what they were / are thinking instead of putting this assumption on them. You could be right, of course, but I certainly didn't interpret that linkage from the submission instructions.

--Paul Hoffman, Director
--VPN Consortium

From hash-forum@nist.gov  Mon Dec 22 07:52:49 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBMFqhP7012048
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Mon, 22 Dec 2008 07:52:45 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBMFq3FQ015707;
	Mon, 22 Dec 2008 10:52:06 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBMFpoRq027015;
	Mon, 22 Dec 2008 10:51:50 -0500
Date: Mon, 22 Dec 2008 10:51:50 -0500
Message-Id: 
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: Paul Hoffman 
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: text/plain; charset="us-ascii"
X-To: hash-forum@nist.gov
References: <20081222122433.35341.qmail@cr.yp.to> 
In-Reply-To:  
Mime-Version: 1.0
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 22 Dec 2008 07:52:46 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords:                 
X-UID: 456


At 9:41 AM -0500 12/22/08, Stefan.Lucks@uni-weimar.de wrote:
>I expect a clear statement, which number of rounds is recommended for a
>certain hash size or for certain security requirements.

That expectation is not in line with what NIST asked for in its call for submissions. *You* might expect that, but unless NIST adds a request for such a statement, it is not reasonable to expect submitters to make one.

--Paul Hoffman, Director
--VPN Consortium

From hash-forum@nist.gov  Mon Dec 22 12:17:47 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBMKHfCs009824
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Mon, 22 Dec 2008 12:17:43 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBMKGxmD004122;
	Mon, 22 Dec 2008 15:17:02 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBMKGoa0011266;
	Mon, 22 Dec 2008 15:16:50 -0500
Date: Mon, 22 Dec 2008 15:16:50 -0500
Message-Id: <20081222201034.17001.qmail@cr.yp.to>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "D. J. Bernstein" 
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
In-Reply-To:  
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 22 Dec 2008 12:17:43 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 457


Stefan.Lucks@uni-weimar.de writes:
> I don't see any reason to override their recommendation -- even if their 
> API provides a way to do so.

Let me get this straight. You're saying that

   * the only way for the MD6 designers to "suggest" 24-round MD6 is to
     _recommend_ 24-round MD6 and _stop recommending_ 168-round MD6;
   * the MD6 designers have not "suggested" 24-round MD6 according to
     this definition;
   * the MD6 designers therefore have not expressed confidence in
     24-round MD6;
   * the general public therefore will have no way to gain confidence in
     24-round MD6; and
   * choosing 24-round MD6 as SHA-3 would therefore "undermine the
     credibility of SHA-3."

Did I get that right? I'm sorry that you feel I've been putting words in
your mouth, but I'm trying my best to understand your argument for
refusing to consider the merits of 24-round MD6.

For comparison, what NIST's rules actually say is that submissions can
specify a tunable security parameter, allowing "selection of a range of
possible security/performance tradeoffs"; and that the parameter can be
used to select a different tradeoff for SHA-3. For example, MD6 has a
tunable round count, and NIST could select (e.g.) 24-round MD6 as SHA-3.
It's clear that you're opposed to this flexibility; it's not clear why.

Charanjit Jutla writes:
  [ advocating DFC-style security proofs: ]
> I think the "polite" thing to do for all submitters is to AT THE LEAST 
> provide justification (make whatever assumptions you want to make) as
> to why simple differential attacks would not work
  [ ... ]
> If you are not 10X times faster, while providing no justification of
> why your hash function is secure, then I do not see why people should
> waste time on this proposal.

Read the rules! NIST said that it expects SHA-3 to be suitable for HMAC,
DSA, etc., and to resist collisions, preimages, etc. with "significantly
improved efficiency" compared to SHA-2. NIST didn't ask for a DFC-style
security proof. If you want a competition that prioritizes DFC-style
security proofs, go ahead and run one, but please don't confuse it with
the SHA-3 competition.

I'll be the first to agree that most users _don't_ need fast hashing.
However, there are some users subject to real-world hash performance
constraints, and it's clear that SHA-3 will have to make those users
happy. It's much more difficult to find users who are refusing to use
primitives without DFC-style security proofs.

I'm not saying that DFC-style security proofs are a complete waste of
time. However, it's clearly possible for a submission without such
proofs to survive in the SHA-3 competition.

---D. J. Bernstein 
   Research Professor, Computer Science, University of Illinois at Chicago

From hash-forum@nist.gov  Mon Dec 22 14:07:58 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBMM7pa0021041
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Mon, 22 Dec 2008 14:07:52 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBMM72QZ013234;
	Mon, 22 Dec 2008 17:07:05 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBMM6ljM005620;
	Mon, 22 Dec 2008 17:06:48 -0500
Date: Mon, 22 Dec 2008 17:06:47 -0500
Message-Id: <707897D2-12A4-406B-8EA3-07ACDEF92CEE@zooko.com>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: zooko 
To: Multiple recipients of list 
Subject: will SHA-3 replace the current standard secure hash algorithm -- MD5?
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Mailer: Apple Mail (2.753.1)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
X-To: hash-forum@nist.gov
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v753.1)
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 22 Dec 2008 14:07:53 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-5.8 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_DNSWL_MED,WHOIS_MYPRIVREG shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 458


Folks:

Below, I re-post a letter that I wrote to this list last February.  I  
think that this letter, which some of you may not have seen, casts  
light on why we have different assumptions about valid security/ 
performance trade-offs.  It is because secure hashes are used today  
for more than just their original purpose.

Since I wrote this letter, I did some more snooping around, and I  
learned that the situation is even more extreme than I thought -- for  
some areas of endeavour, MD5 is actually the standard secure hash  
algorithm in 2008.

I chatted with a couple of friends who are information security  
consultants -- they get paid big bucks by household-name corporations  
to audit source code and systems for security flaws.  I asked them  
what kinds of secure hash functions they see used in the wild.  They  
answered that MD5 was the most common, occasionally SHA-1, in large  
part because it is a default value on the Java Cryptography  
Extensions, and they have never seen any other secure hash functions  
in client systems.

I chatted with a friend who works at the Internet Archive -- all  
files stored at the Internet Archive are identified by their MD5 hashes.

I noticed that there was a new release of the Haskell compiler GHC.   
One of the new features is that it uses MD5 to identify code modules.

I learned more about the "computer forensics" field.  MD5 appears to  
be the standard mechanism to identify files in that field.  I read  
discussion forums in which computer forensics practitioners asked  
each other whether the cryptographic attacks on MD5 that they had  
heard about meant that they needed to change their practice.  The  
consensus seemed to be that they could continue using MD5 for now.

Finally, I was intrigued to see that NIST, of all organizations, uses  
and recommends the use of MD5 (in addition to SHA-1), as part of its  
"National Software Reference Library", which supports digital  
forensics.  This document explaining why NIST believes that this is  
safe is fascinating:

http://www.nsrl.nist.gov/Documents/analysis/draft-060530.pdf


The wide gap between the performance needs of using a secure hash  
function for public key cryptography versus using it for bulk data  
identification and integrity checking (which is what I use it for at  
my day job), make me wonder if SHA-3 should include variants or  
officially recommended tuning parameters so that people identifying  
large files can use a SHA-3 which is at least as fast as MD5 or  
Tiger, while people who are signing thousand-year documents can use a  
SHA-3 which is more expensive but safer.  (By the way, I tend to  
think that HMAC shouldn't be weighted heavily as a use case for SHA-3  
simply because people should stop using HMAC and start using Carter- 
Wegman MACs instead such as Poly1305 or VMAC.)


Regards,

Zooko O'Whielacronx

------- begin appended message re-post
From: zooko
Date: February 5, 2008 12:15:53 PM MST
To: Multiple recipients of list
Subject: bulk data use cases -- SHA-256 is too slow
Folks:

Cryptographic hash functions were invented for hashing small variable- 
length strings, such as human-readable text documents, public keys,  
or certificates, into tiny fixed-length strings in order to sign  
them. When considering such usage, the inputs to the hash function  
are short -- often only hundreds or thousands of bytes, rarely as  
much as a million bytes. Also, the computational cost of the hash  
function is likely to be swamped by the computational cost of the  
public key operation.

Later, hash functions were pressed into service in MACs as  
exemplified by HMAC. In that usage, the inputs to the hash function  
tend to be small -- typically hundreds of bytes in a network packet.  
Also, the network is often the limiting factor on performance, in  
which case the time to compute the MAC is not the performance  
bottleneck.

I would like to draw your attention to another way that cryptographic  
hash functions have been pressed into service -- as core security  
mechanisms in a myriad of bulk data systems. Examples include local  
filesystems (e.g. ZFS [1]), decentralized filesystems (e.g. a project  
that I hack on: allmydata.org [2]), p2p file-sharing tools (e.g.  
BitTorrent [3], Bitzi [4]), decentralized revision control tools  
(e.g. monotone [5], git [6], mercurial [7], darcs [8]), intrusion  
detection systems (e.g. Samhain [9]), and software package tools  
(e.g. Microsoft CLR strong names [10], Python setuptools [11], Debian  
control files [12], Ubuntu system-integrity-check [13]).

Commonly in this third category of uses the size of the data being  
hashed can be large -- millions, billions or even trillions of bytes  
at once -- and there is no public key operation or network delay to  
hide the cost of the hash function. The hash function typically sits  
squarely on the critical path of certain operations, and the speed of  
the hash function is the limiting factor for the speed of those  
operations.

Something else common about these applications are that the designers  
are cryptographically unsophisticated, compared to designers in the  
earlier two use cases. It is not uncommon within those communities  
for the designers to believe that hash collisions are not a problem  
as long as second pre-image attacks are impossible, or to believe  
that the natural redundancy and structure of their formats protect  
them ("only meaningless files can have hash collisions", they say).

A consequence of these conditions is that raw speed of a hash  
function is very important for adoption in these systems. If you  
browse the references I've given above, you'll find that SHA-1,  
Tiger, and MD5 (!!) are commonly used, and SHA-256 is rare. In fact,  
of all the examples listed above, SHA-256 is used only in my own  
project -- allmydata.org. It is available in ZFS, but it is never  
turned on because it is too slow compared to the alternative non- 
cryptographic checksum.

I should emphasize that this is not just a matter of legacy -- it is  
not just that these older hash functions have been "grandfathered  
in". Legacy is certainly a very important part of it, but newly  
designed and deployed systems often use SHA-1. Linus Torvalds chose  
to use SHA-1 in his newly designed "git" decentralized revision  
control tool, *after* the original 2005-02-15 Wang et al. attack was  
announced, and roundly mocked people who suggested that he choose a  
more secure alternative [6]. I recently plead with the developers of  
the "darcs" revision control tool that they should not use SHA-1 for  
their new, backwards-incompatible design. (The issue currently hangs  
on whether I can find a sufficiently fast implementation of SHA-256  
or Tiger with Haskell bindings.)

Because of my exposure to these systems, I was surprised to see a few  
comments recently on this mailing list that SHA-256 is fast enough.  
My surprise abated when I decided that the commentors are coming from  
a background where the first two use cases -- public key signatures  
and MACs -- are common, and they may not be aware that SHA-256 is  
potentially too slow for some other use cases.

Regards,

Zooko O'Whielacronx

[1] http://www.solarisinternals.com/wiki/index.php/ 
ZFS_Evil_Tuning_Guide#Tuning_ZFS_Checksums
[2] http://allmydata.org
[3] http://en.wikipedia.org/wiki/BitTorrent_%28protocol%29
[4] http://bitzi.com/developer/bitprint
[5] http://www.venge.net/mtn-wiki/FutureCryptography
[6] http://www.gelato.unsw.edu.au/archives/git/0506/5299.html
[7] http://www.selenic.com/pipermail/mercurial/2005-August/003832.html
[8] http://www.nabble.com/announcing-darcs-2.0.0pre3- 
tt15027931.html#a15048993
[9] http://la-samhna.de/samhain/manual/hash-function.html
[10] http://blogs.msdn.com/shawnfa/archive/2005/02/28/382027.aspx
[11] http://peak.telecommunity.com/DevCenter/setuptools
[12] http://www.debian.org/doc/debian-policy/ch-controlfields.html#s- 
f-Files
[13] https://wiki.ubuntu.com/IntegrityCheck


From hash-forum@nist.gov  Mon Dec 22 15:02:29 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBMN2O3U026007
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Mon, 22 Dec 2008 15:02:25 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBMN1rv0023326;
	Mon, 22 Dec 2008 18:01:54 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBMN1gNF016769;
	Mon, 22 Dec 2008 18:01:42 -0500
Date: Mon, 22 Dec 2008 18:01:42 -0500
Message-Id: 
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: scontini@ics.mq.edu.au
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;charset=iso-8859-1
MIME-Version: 1.0
X-To: hash-forum@nist.gov
References: <20081222122433.35341.qmail@cr.yp.to>
In-Reply-To: <20081222122433.35341.qmail@cr.yp.to>
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 22 Dec 2008 15:02:25 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 459


Dan Bernstein writes:
> > Knudsen and Rijmen then broke the "provably secure" 6-round DFC. What an
> > embarrassment for "provable security"! What a perfect illustration of
> > the importance of cryptanalysis!
> >
>

Yes, and note that I also said "provided that no flaws are found in the
algorithms or proofs."

>
> "Contini writes:
> > For about 10 years, nobody had any idea how to attack SHA1.
>
> For about 10 years, cryptanalysts were focusing on block ciphers, with

The lack of publications should not imply that people were not looking at
it.  I had a look at it and I know others who have as well.  The problem
was the complexity of analysing the darn thing!

> only occasional glances at hash functions. The first SHA-1 paper jumped
> to a 53-round attack, and the second paper jumped to a full 80-round
> attack. It's indisputably important to have enough cryptanalytic time
> spent on the eventual SHA-3---which is why we're talking about ways to
> avoid having cryptanalytic time wasted on hashes that clearly won't win.
>

That's right: we're both discussing ways of whittling down the number
of candidates, but from different viewpoints.

>
> The ultimate reason for confidence in SHA-3 will be that we have tried,
> and failed, to attack it.

That's exactly where I disagree with you.  Failing to attack it is only
one measure in the strength of the algorithm.  There are others and
NIST made this clear:

    "Other consideration factors in addition to the evaluation factors
    mentioned above, the quality of the security arguments/proofs,
    the clarity of the documentation of the algorithm, the quality of
    the analysis on the algorithm performed by the submitters, the
    simplicity of the algorithm, and the confidence of NIST and the
    cryptographic community in the algorithm's long-term security may
    all be considered."

This is exactly the problem I have with your criteria.  You have
suggested one criteria that you recommend as being more important
all others.  I am not saying your criteria is irrelevant, I am just
saying that you are putting far too much weight on it.


> Some types of attacks will be explored quite
> thoroughly, and maybe formalized as theorems showing that those types of
> attacks can't work, but this merely means that future cryptanalysts will
> have to try different types of attacks.
>
> > it is feasible that some complex, hard to
> > analyse design appears (for the time being) to be far superior
>
> As a designer I generally aim for simplicity---but maybe I shouldn't;

I agree that simplicity is also one criteria that should be considered!
I strongly oppose strength based upon complexity of analysis (i.e. the
SHA1 design philosophy).

Scott




From hash-forum@nist.gov  Mon Dec 22 16:24:19 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBN0ODid001020
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Mon, 22 Dec 2008 16:24:14 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBN0NdWH026226;
	Mon, 22 Dec 2008 19:23:40 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBN0NIbv012211;
	Mon, 22 Dec 2008 19:23:18 -0500
Date: Mon, 22 Dec 2008 19:23:18 -0500
Message-Id: <49502DA6.3010404@xs4all.nl>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: Maarten Bodewes 
To: Multiple recipients of list 
Subject: Re: will SHA-3 replace the current standard secure hash algorithm -- MD5?
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
In-Reply-To: <707897D2-12A4-406B-8EA3-07ACDEF92CEE@zooko.com>
References: <707897D2-12A4-406B-8EA3-07ACDEF92CEE@zooko.com>
MIME-Version: 1.0
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Mon, 22 Dec 2008 16:24:14 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 460


zooko wrote:
> 
> Below, I re-post a letter that I wrote to this list last February.  I
> think that this letter, which some of you may not have seen, casts light
> on why we have different assumptions about valid security/performance
> trade-offs.  It is because secure hashes are used today for more than
> just their original purpose.
> 
> Since I wrote this letter, I did some more snooping around, and I
> learned that the situation is even more extreme than I thought -- for
> some areas of endeavour, MD5 is actually the standard secure hash
> algorithm in 2008.
> 
> I chatted with a couple of friends who are information security
> consultants -- they get paid big bucks by household-name corporations to
> audit source code and systems for security flaws.  I asked them what
> kinds of secure hash functions they see used in the wild.  They answered
> that MD5 was the most common, occasionally SHA-1, in large part because
> it is a default value on the Java Cryptography Extensions, and they have
> never seen any other secure hash functions in client systems.
> 

There is no such thing:

http://java.sun.com/j2se/1.5.0/docs/api/java/security/MessageDigest.html

I don't see any parameter-less "factory methods" that return a default
here. And I've been working with Java since version 1.0 . Maybe it is
default in some web frameworks, but certainly not in Java itself.

> I chatted with a friend who works at the Internet Archive -- all files
> stored at the Internet Archive are identified by their MD5 hashes.
> 
> I noticed that there was a new release of the Haskell compiler GHC.  One
> of the new features is that it uses MD5 to identify code modules.
> 
> I learned more about the "computer forensics" field.  MD5 appears to be
> the standard mechanism to identify files in that field.  I read
> discussion forums in which computer forensics practitioners asked each
> other whether the cryptographic attacks on MD5 that they had heard about
> meant that they needed to change their practice.  The consensus seemed
> to be that they could continue using MD5 for now.
> 
> Finally, I was intrigued to see that NIST, of all organizations, uses
> and recommends the use of MD5 (in addition to SHA-1), as part of its
> "National Software Reference Library", which supports digital
> forensics.  This document explaining why NIST believes that this is safe
> is fascinating:
> 
> http://www.nsrl.nist.gov/Documents/analysis/draft-060530.pdf
> 
MD 5 as identification within a closed system is not bad by itself.
Could be better, but you'll still have to search for MD5 collisions, the
likeliness of one just popping up is small enough. As long as there is
no 3rd party that can confuse things, MD5 may be a fine tool for the
job. It is the same for most key derivation and password protection that
is out in the wild.

Of course, even here it would be easier to just say: we use a secure
hash method and be done with it, but as long as it is identified and
understood not to be a problem, then using any hash method can be
defended. I skipped to the conclusions of the paper:

The conclusions of this paper are:
• There are no file signature collisions in the NSRL for either MD5 or
SHA-1.
• There was no detectable bias introduced by hashing files, and so the
probability of future collisions is negligible.
• Although there are methods to attack the underlying hash algorithms,
they are not relevant to the NSRL.

Sounds fine by me.

> 
> The wide gap between the performance needs of using a secure hash
> function for public key cryptography versus using it for bulk data
> identification and integrity checking (which is what I use it for at my
> day job), make me wonder if SHA-3 should include variants or officially
> recommended tuning parameters so that people identifying large files can
> use a SHA-3 which is at least as fast as MD5 or Tiger, while people who
> are signing thousand-year documents can use a SHA-3 which is more
> expensive but safer.  (By the way, I tend to think that HMAC shouldn't
> be weighted heavily as a use case for SHA-3 simply because people should
> stop using HMAC and start using Carter-Wegman MACs instead such as
> Poly1305 or VMAC.)
> 
> 
That's an interesting idea especially with the current discussions on
the tunable parameters. I wonder though with the current difficulties
due to the number of hash methods that this idea will gain momentum. If
it does gain momentum, I would not go for a parameter for the hash, no
cryptographic library will expect one. Rather go for a special name,
such as SHA-3-LITE (or something less popular). I'm afraid that such a
thing will not happen though, or only after a new SHA-3 has been chosen.

All in all, as a developer, I'm especially worried by some people that
argue that we don't need a fast hash algorithm. Especially for
validation of files, we don't need encryption, we need hashes and
signatures. I hope your post will do something to convince everyone that
we do need fast and rather secure hash algorithms (even if you take
current and future CPU speeds into account).

Regards,
Maarten

PS. I hope these discussions between developers are not distracting too
much from the crypto-analysis that needs to be taken, but these are
valid points that are also interesting for the current discussions.

=== cut the original text that explains that fast hashes such as MD5 are
used and needed ===

From hash-forum@nist.gov  Tue Dec 23 07:40:41 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBNFeaSY030863
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Tue, 23 Dec 2008 07:40:37 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBNFdxuN011362;
	Tue, 23 Dec 2008 10:40:00 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBNFdZfV030876;
	Tue, 23 Dec 2008 10:39:35 -0500
Date: Tue, 23 Dec 2008 10:39:35 -0500
Message-Id: 
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: Stefan.Lucks@uni-weimar.de
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: TEXT/PLAIN; charset=US-ASCII
MIME-Version: 1.0
References: <20081222201034.17001.qmail@cr.yp.to>
In-Reply-To: <20081222201034.17001.qmail@cr.yp.to>
X-To: Multiple recipients of list 
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 23 Dec 2008 07:40:37 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords:                 
X-UID: 461


On Mon, 22 Dec 2008, D. J. Bernstein wrote:

> Let me get this straight. You're saying that
> 
>    * the only way for the MD6 designers to "suggest" 24-round MD6 is to
>      _recommend_ 24-round MD6 and _stop recommending_ 168-round MD6;
>    * the MD6 designers have not "suggested" 24-round MD6 according to
>      this definition;
>    * the MD6 designers therefore have not expressed confidence in
>      24-round MD6;

Up to this point, you have summarised what I wrote.

>    * the general public therefore will have no way to gain confidence in
>      24-round MD6; and

This is not what I wrote. 

At the current point of time, we have no reason to be confident in 24 
rounds of MD6. In the long run, we will learn more about the security of 
the SHA-3 submissions (hopefully!). And then, the submitters will be 
allowed to propose tweaks, and adjusting the tunable parameters is an 
obvious tweak. And the public may follow them with gaining confidence.

>    * choosing 24-round MD6 as SHA-3 would therefore "undermine the
>      credibility of SHA-3."

No, but choosing 24 round MD6 *against* *the* *submitters* 
*recommendation* as SHA-3 would undermine credibility. Do you really 
dispute that? 

Same for any other candidate, of course. Can you imagine NIST to choose 
some SHA-3 candidate ... and then to reduces the number of rounds without 
the submitters' consent? Nice headlines for the press ... 

> Did I get that right? I'm sorry that you feel I've been putting words in
> your mouth, but I'm trying my best to understand your argument for
> refusing to consider the merits of 24-round MD6.

The main topic of this thread is our engineering-based comparison of SHA-3 
submissions, right? 

You suggest to use variants below the submitters recommendations 
(essentially the fastest unbroken variant) for such a comparison. This is, 
what I refuse. 

Whatever candidate is chosen, the choice of its tunable parameters (if 
there are any) will not be the one of the fastest unbroken variant, but 
something a bit slower. The number of additional rounds needed for a 
reasonable amount of assurance and confidence greatly depends on 
perception and design philosophy (the size of the internal state, the 
usage of an established and well-understodd design, the existence of 
security proofs, the simplicit of the hash function, ...).

Let me stress that: We have something like

  (time for hashing) = (fastest unbroken variant) + (something).

An ideal peformance comparison would compare (fastest unbroken variant) + 
(something), but we don't know the final (something). In fact, (something) 
greatly depends on the submission itself. 

The best (no, the only) estimate we have is to use the submitters defaults 
to compute the (time for hashing), based on their defaults for the tunable 
security parameters. Any performance comparison based on deliberately 
changing the tunable paramters is badly flawed, IMHO. 

This is, where we seem to disagree so much.

In short, I am not against 24 rounds of MD6, but I definitively refuse to 
consider it for a performance comparison of SHA-3 candidates. Full MD6 is 
a SHA-3 candidate, 24 rounds of MD6 isn't.

> For comparison, what NIST's rules actually say is that submissions can
> specify a tunable security parameter, allowing "selection of a range of
> possible security/performance tradeoffs"; and that the parameter can be
> used to select a different tradeoff for SHA-3. For example, MD6 has a
> tunable round count, and NIST could select (e.g.) 24-round MD6 as SHA-3.
> It's clear that you're opposed to this flexibility; it's not clear why.

I am not at all opposed to flexibility, or to the existence of tunable 
parameters -- I like that. I only refuse to use (or, as I would put it, to 
abuse) these parameters to tune performance comparisons. 

BTW, I find it irritating, that you are so eager at proposing (or at least 
discussing) 24 rounds of MD6, as you have submitted a SHA-3 candidate of 
your own, and that isn't MD6.

There are 15 persons in the MD6 team. So far, none of them has proposed to 
use MD6 reduced to 24 rounds. I am sure, they know why: it would turn 
their proof of security against certain types of differential 
cryptanalysis into dust.

So long, and enjoy the holidays!

Stefan

-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------


From hash-forum@nist.gov  Tue Dec 23 09:19:25 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBNHJKsb030958
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Tue, 23 Dec 2008 09:19:21 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBNHIiM6007878;
	Tue, 23 Dec 2008 12:18:47 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBNHIWf0005413;
	Tue, 23 Dec 2008 12:18:32 -0500
Date: Tue, 23 Dec 2008 12:18:32 -0500
Message-Id: 
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: Paul Hoffman 
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: text/plain; charset="us-ascii"
X-To: hash-forum@nist.gov
References: <20081222201034.17001.qmail@cr.yp.to> 
In-Reply-To:  
Mime-Version: 1.0
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 23 Dec 2008 09:19:22 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 462


At 10:37 AM -0500 12/23/08, Stefan.Lucks@uni-weimar.de wrote:
>You suggest to use variants below the submitters recommendations
>(essentially the fastest unbroken variant) for such a comparison.

I fully disagree that Dan suggested that. Earlier, you asked Dan not to put words in your mouth; I propose that you give him the same respect. (Yes, that's a general note for all of us here.)

The basic disagreement is whether or not NIST meant that the single variant that was coded in the sample code should be the recommendation of the submitter. NIST has not clarified that. Until they do, it would be silly for either side to assert with much confidence that they are right.

--Paul Hoffman, Director
--VPN Consortium

From hash-forum@nist.gov  Tue Dec 23 09:49:19 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBNHnD4t008550
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Tue, 23 Dec 2008 09:49:15 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBNHmfmI012334;
	Tue, 23 Dec 2008 12:48:42 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBNHmQGs032406;
	Tue, 23 Dec 2008 12:48:26 -0500
Date: Tue, 23 Dec 2008 12:48:26 -0500
Message-Id: 
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: Stefan.Lucks@uni-weimar.de
To: Multiple recipients of list 
Subject: Re: Engineering comparison of the SHA-3 candidates
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: TEXT/PLAIN; charset=US-ASCII
MIME-Version: 1.0
References: <20081222201034.17001.qmail@cr.yp.to>  
In-Reply-To: 
X-To: Multiple recipients of list 
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 23 Dec 2008 09:49:15 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 463


> At 10:37 AM -0500 12/23/08, Stefan.Lucks@uni-weimar.de wrote:
> >You suggest to use variants below the submitters recommendations
> >(essentially the fastest unbroken variant) for such a comparison.
> 
> I fully disagree that Dan suggested that. Earlier, you asked Dan not to 
> put words in your mouth; I propose that you give him the same respect. 
> (Yes, that's a general note for all of us here.)

Quoting Dan Bernstein (Date: Wed, 17 Dec 2008 02:58:24 -0500): 
  "What I'm advocating for SHA-3 is that we sort 
   submissions according to the efficiency of 
   their fastest unbroken variants [...]". 

So long

Stefan

-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------


From hash-forum@nist.gov  Tue Dec 23 10:46:29 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBNIkLRK025218
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Tue, 23 Dec 2008 10:46:23 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBNIiqni025582;
	Tue, 23 Dec 2008 13:44:54 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBNIicrB016626;
	Tue, 23 Dec 2008 13:44:38 -0500
Date: Tue, 23 Dec 2008 13:44:38 -0500
Message-Id: 
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "Jonathan Day" 
To: Multiple recipients of list 
Subject: Re: will SHA-3 replace the current standard secure hash algorithm -- MD5?
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
References: <707897D2-12A4-406B-8EA3-07ACDEF92CEE@zooko.com> <49502DA6.3010404@xs4all.nl>
Content-Type: multipart/alternative;  boundary="----=_Part_67612_18935050.1230057031253"
MIME-Version: 1.0
In-Reply-To: <49502DA6.3010404@xs4all.nl>
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 23 Dec 2008 10:46:24 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 464


------=_Part_67612_18935050.1230057031253
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Mon, Dec 22, 2008 at 4:22 PM, Maarten Bodewes
wrote:

> MD 5 as identification within a closed system is not bad by itself.
> Could be better, but you'll still have to search for MD5 collisions, the
> likeliness of one just popping up is small enough. As long as there is
> no 3rd party that can confuse things, MD5 may be a fine tool for the
> job. It is the same for most key derivation and password protection that
> is out in the wild.
>
> Of course, even here it would be easier to just say: we use a secure
> hash method and be done with it, but as long as it is identified and
> understood not to be a problem, then using any hash method can be
> defended. I skipped to the conclusions of the paper:
>

I'll argue the PHB Conundrum, which is that if you say that algorithm X is
safe at some level, the Dilbertesque Pointy-Haired Bosses will assume
algorithm X must be safe for levels for which it is inappropriate. Even if
it is completely safe for some uses, it seems... wiser to avoid
misunderstandings, even if that means going further than you actually need
to at this time. Judicious over-engineering has its place.

All in all, as a developer, I'm especially worried by some people that
> argue that we don't need a fast hash algorithm. Especially for
> validation of files, we don't need encryption, we need hashes and
> signatures. I hope your post will do something to convince everyone that
> we do need fast and rather secure hash algorithms (even if you take
> current and future CPU speeds into account).
>

Speeding up crypto involves not just a good selection of algorithm but also
smarter coding - and I'm as guilty on the coding side as anyone. At some
level of detail, all hash functions must ultimately become a sequential
series of steps. At some other level of detail, some (but not necessarily
all) will have components of steps that can be parallelized. If there is any
line in the algorithm that can be re-written as the output of two functions
combined by an operator, where the cost saved by performing the operations
in parallel exceed the added costs involved in running an extra operation,
then pulling the results together, you can parallelize that line
efficiently. Some compilers can do that for you, some CPUs can do that for
you, mileage varies.

In the same way NIST's encryption mode contest had multiple categories, it
might be good if SHA-3 had two categories. You might keep SHA-3 for the best
overall cryptographic hash, and then have a SHA-3P for the SHA-3 finallist
that remained unbroken and exhibited the greatest opportunity for
instruction-level or function-level parallelization, regardless of whether
it was best overall on those criteria not relating to safety or performance.
Or if NIST doesn't want to burden itself with the complexity of making such
a judgement as part of the contest, maybe there could be an unofficial but
generally recognized SHA-3P within both the cryptographic and developer
communities, if it remains the view that there's a need. (If by the time we
reach the final round, all the algorithms are good at low-level
parallelization and/or are fast enough anyway, the need for such a
distinction would evaporate.)

Regards,
> Maarten
>
> PS. I hope these discussions between developers are not distracting too
> much from the crypto-analysis that needs to be taken, but these are
> valid points that are also interesting for the current discussions.


This is not a high-volume list and this thread is low-volume even within
that. What you posted needed to be posted and was both interesting and (I
believe) very useful.  If it became a more high-volume discussion, I'd
advocate moving it off this list and onto something specifically for it, but
I can't imagine that happening.

(Quoted post snipped to only include content specifically replied to. Full
context not included to avoid clutter. In the event of ambiguity
accidentally introduced by quoting the material, the original post should be
referred to.)

------=_Part_67612_18935050.1230057031253
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Mon, Dec 22, 2008 at 4:22 PM, Maarten Bodewes <maarten.bodewes@xs4all.nl> wrote:

MD 5 as identification within a closed system is not bad by itself.

Could be better, but you'll still have to search for MD5 collisions, the

likeliness of one just popping up is small enough. As long as there is

no 3rd party that can confuse things, MD5 may be a fine tool for the

job. It is the same for most key derivation and password protection that

is out in the wild.



Of course, even here it would be easier to just say: we use a secure

hash method and be done with it, but as long as it is identified and

understood not to be a problem, then using any hash method can be

defended. I skipped to the conclusions of the paper:



I'll argue the PHB Conundrum, which is that if you say that algorithm X is safe at some level, the Dilbertesque Pointy-Haired Bosses will assume algorithm X must be safe for levels for which it is inappropriate. Even if it is completely safe for some uses, it seems... wiser to avoid misunderstandings, even if that means going further than you actually need to at this time. Judicious over-engineering has its place.



All in all, as a developer, I'm especially worried by some people that

argue that we don't need a fast hash algorithm. Especially for

validation of files, we don't need encryption, we need hashes and

signatures. I hope your post will do something to convince everyone that

we do need fast and rather secure hash algorithms (even if you take

current and future CPU speeds into account).



Speeding up crypto involves not just a good selection of algorithm but also smarter coding - and I'm as guilty on the coding side as anyone. At some level of detail, all hash functions must ultimately become a sequential series of steps. At some other level of detail, some (but not necessarily all) will have components of steps that can be parallelized. If there is any line in the algorithm that can be re-written as the output of two functions combined by an operator, where the cost saved by performing the operations in parallel exceed the added costs involved in running an extra operation, then pulling the results together, you can parallelize that line efficiently. Some compilers can do that for you, some CPUs can do that for you, mileage varies.


In the same way NIST's encryption mode contest had multiple categories, it might be good if SHA-3 had two categories. You might keep SHA-3 for the best overall cryptographic hash, and then have a SHA-3P for the SHA-3 finallist that remained unbroken and exhibited the greatest opportunity for instruction-level or function-level parallelization, regardless of whether it was best overall on those criteria not relating to safety or performance. Or if NIST doesn't want to burden itself with the complexity of making such a judgement as part of the contest, maybe there could be an unofficial but generally recognized SHA-3P within both the cryptographic and developer communities, if it remains the view that there's a need. (If by the time we reach the final round, all the algorithms are good at low-level parallelization and/or are fast enough anyway, the need for such a distinction would evaporate.)



Regards,

Maarten



PS. I hope these discussions between developers are not distracting too

much from the crypto-analysis that needs to be taken, but these are

valid points that are also interesting for the current discussions.

This is not a high-volume list and this thread is low-volume even within that. What you posted needed to be posted and was both interesting and (I believe) very useful.  If it became a more high-volume discussion, I'd advocate moving it off this list and onto something specifically for it, but I can't imagine that happening.


(Quoted post snipped to only include content specifically replied to. Full context not included to avoid clutter. In the event of ambiguity accidentally introduced by quoting the material, the original post should be referred to.)


------=_Part_67612_18935050.1230057031253--

From hash-forum@nist.gov  Tue Dec 23 13:31:39 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBNLVWXH031620
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Tue, 23 Dec 2008 13:31:34 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBNLUaNj025176;
	Tue, 23 Dec 2008 16:30:37 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBNLUMt8027587;
	Tue, 23 Dec 2008 16:30:23 -0500
Date: Tue, 23 Dec 2008 16:30:22 -0500
Message-Id: <7731938b0812231317x1db34d37m1ba610ee50cb1874@mail.gmail.com>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "Peter Maxwell" 
To: Multiple recipients of list 
Subject: Re: will SHA-3 replace the current standard secure hash algorithm -- MD5?
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
References: <707897D2-12A4-406B-8EA3-07ACDEF92CEE@zooko.com> <49502DA6.3010404@xs4all.nl> 
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1
MIME-Version: 1.0
In-Reply-To: 
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Tue, 23 Dec 2008 13:31:34 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 465


2008/12/23 Jonathan Day :

>
> In the same way NIST's encryption mode contest had multiple categories, it
> might be good if SHA-3 had two categories. You might keep SHA-3 for the best
> overall cryptographic hash, and then have a SHA-3P for the SHA-3 finallist
> that remained unbroken and exhibited the greatest opportunity for
> instruction-level or function-level parallelization, regardless of whether
> it was best overall on those criteria not relating to safety or performance.
> Or if NIST doesn't want to burden itself with the complexity of making such
> a judgement as part of the contest, maybe there could be an unofficial but
> generally recognized SHA-3P within both the cryptographic and developer
> communities, if it remains the view that there's a need. (If by the time we
> reach the final round, all the algorithms are good at low-level
> parallelization and/or are fast enough anyway, the need for such a
> distinction would evaporate.)
>

While having a performance version of SHA-3 (with possibly slightly
reduced security) would likely be useful, I would doubt that it would
ever happen as I'd guess that the cost of creating a standardisation
and compliance framework for essentially two different implementations
would be too costly (its already difficult enough to get a FIPS
certification on a product).

You've definitely got a point with the developer community (or open
source community at large) as demand usually dictates what gets
produced, however it may be easier to use a hash tree for most
applications which would give implicit parallelism rather than trying
to fine tune the core algorithm.  A lot of the submissions have
support for tree hashing already, for those that don't its not too
difficult to define a secure tree construction.

Best wishes,

Peter Maxwell

From hash-forum@nist.gov  Wed Dec 24 00:46:08 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBO8k3AH021362
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 24 Dec 2008 00:46:04 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBO8jZ8j005187;
	Wed, 24 Dec 2008 03:45:35 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBO8jAkp003433;
	Wed, 24 Dec 2008 03:45:11 -0500
Date: Wed, 24 Dec 2008 03:45:10 -0500
Message-Id: <2EEF05B9E61549C7BAB722C449AC6B96@weidai.com>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "Wei Dai" 
To: Multiple recipients of list 
Subject: collisions for CubeHash1/57 and CubeHash2/89
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Mailer: Microsoft Windows Live Mail 12.0.1606
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; format=flowed; charset="gb2312"; reply-type=original
MIME-Version: 1.0
X-To: "hash-forum" 
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 24 Dec 2008 00:46:04 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	STOX_REPLY_TYPE shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 466


I found collisions for CubeHash1/57-512 and CubeHash2/89-512. For details 
please see http://www.cryptopp.com/sha3/cubehash.pdf. (I would have just 
posted the details here, but Prof. Bernstein insisted on a PDF to qualify 
for his prize. :)
 


From hash-forum@nist.gov  Wed Dec 24 01:13:23 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBO9DIgs030723
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 24 Dec 2008 01:13:19 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBO9Cf7B010935;
	Wed, 24 Dec 2008 04:12:42 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBO9CWg4022358;
	Wed, 24 Dec 2008 04:12:32 -0500
Date: Wed, 24 Dec 2008 04:12:32 -0500
Message-Id: 
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "Jean-Philippe Aumasson" 
To: Multiple recipients of list 
Subject: Re: collisions for CubeHash1/57 and CubeHash2/89
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
References: <2EEF05B9E61549C7BAB722C449AC6B96@weidai.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1
MIME-Version: 1.0
In-Reply-To: <2EEF05B9E61549C7BAB722C449AC6B96@weidai.com>
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Wed, 24 Dec 2008 01:13:19 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 467


BTW: we've just updated our "Inside the Hypercube" paper with
- an exhaustive description of the symmetry classes
- collisions for CubeHash1 and CubeHash2

See
http://eprint.iacr.org/2008/486


On Wed, Dec 24, 2008 at 9:43 AM, Wei Dai  wrote:
>
> I found collisions for CubeHash1/57-512 and CubeHash2/89-512. For details
> please see http://www.cryptopp.com/sha3/cubehash.pdf. (I would have just
> posted the details here, but Prof. Bernstein insisted on a PDF to qualify
> for his prize. :)
>
>
>
>

From hash-forum@nist.gov  Fri Dec 26 13:05:16 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBQL5BRZ028862
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Fri, 26 Dec 2008 13:05:12 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBQL4hU2015134;
	Fri, 26 Dec 2008 16:04:43 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBQL4VTT025165;
	Fri, 26 Dec 2008 16:04:31 -0500
Date: Fri, 26 Dec 2008 16:04:31 -0500
Message-Id: <20081226215933.14303ntd48pg9o00@webmail.tugraz.at>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: Christian Rechberger 
To: Multiple recipients of list 
Subject: Re: collisions for CubeHash1/57 and CubeHash2/89
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Transfer-Encoding: 8bit
X-Organization: Graz University of Technology
Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed"
MIME-Version: 1.0
In-Reply-To: <9E2F799196B14417BC786C700E69CFB8@weidai.com>
References: <2EEF05B9E61549C7BAB722C449AC6B96@weidai.com> <9E2F799196B14417BC786C700E69CFB8@weidai.com>
X-To: hash-forum@nist.gov
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 26 Dec 2008 13:05:12 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
	shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords: NonJunk         
X-UID: 468


Quoting Wei Dai :

>
> I've updated my paper with a collision for CubeHash1/45.
>
> Also, I have a question for the forum. The way I've found these collisions
> was to consider a linear approximation of CubeHash with additions replaced
> by XORs, and look for an input difference that lead to zero differences in
> state bytes b to 127. Then this holds in the actual CubeHash with sufficient
> probability if the weight of the input difference is small. I've been doing
> this manually, but it occurs to me that the problem can be formulated as
> finding a sparse solution to an underdetermined system of linear equations
> over GF(2). Does anyone know of an algorithm for this problem?

Most likely, your problem can also be formulated as finding a  
low-weight codeword in a linear code. There is interesting work done  
on this in the 80s and 90s, see e.g.

   author    = {Jacques Stern},
   title     = {{A method for finding codewords of small weight}},
   booktitle = {Coding Theory and Applications},
   year      = {1988},
   pages     = {106-113},

or

   author = {Jeffrey S. Leon},
   title = {{A probabilistic algorithm for computing minimum weights  
of large error-correcting codes}},
   journal = {IEEE Transactions on Information Theory},
   year = {1988},
   volume = {34},
   number = {5},
   pages = {1354--1359},

or

   author = {Anne Canteaut and Florent Chabaud},
   title = {{A New Algorithm for Finding Minimum-Weight Words in a  
Linear Code: Application to McEliece's Cryptosystem and to  
Narrow-Sense BCH Codes of Length 511}},
   journal = {IEEE Transactions on Information Theory},
   year = {1998},
   volume = {44},
   number = {1},
   pages = {367--378},

This list is surely not exhaustive.
In addition to analyzing McEliece's and related cryptosystems, there  
are many other cryptanalytic applications. As an example, the first  
shortcut collision attacks on reduced SHA-1 were based on these  
techniques.


Best regards,
  Christian



From hash-forum@nist.gov  Fri Dec 26 12:47:26 2008
Return-Path: 
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
	by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id mBQKlLY4026455
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Fri, 26 Dec 2008 12:47:22 -0800
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
	by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBQKAHUp026425;
	Fri, 26 Dec 2008 15:10:18 -0500
Received: from emailha1.nist.gov (localhost.localdomain [127.0.0.1])
	by postmark.nist.gov (8.13.1/8.13.1) with SMTP id mBQKA2Mm017027;
	Fri, 26 Dec 2008 15:10:03 -0500
Date: Fri, 26 Dec 2008 15:10:02 -0500
Message-Id: <9E2F799196B14417BC786C700E69CFB8@weidai.com>
Errors-To: sara@nist.gov
Reply-To: hash-forum@nist.gov
Originator: hash-forum@nist.gov
Sender: hash-forum@nist.gov
Precedence: bulk
From: "Wei Dai" 
To: Multiple recipients of list 
Subject: Re: collisions for CubeHash1/57 and CubeHash2/89
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Mailer: Microsoft Windows Live Mail 12.0.1606
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; format=flowed; charset="gb2312"; reply-type=response
MIME-Version: 1.0
References: <2EEF05B9E61549C7BAB722C449AC6B96@weidai.com>
X-To: 
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: hash-forum@nist.gov
X-Greylist: Delayed for 00:36:26 by milter-greylist-4.0a6 (letters.cs.ucsb.edu [128.111.41.13]); Fri, 26 Dec 2008 12:47:23 -0800 (PST)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on letters
X-Virus-Status: Clean
X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_DNSWL_MED shortcircuit=no autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on letters.cs.ucsb.edu
Status: RO
X-Status: 
X-Keywords:                 
X-UID: 469


I've updated my paper with a collision for CubeHash1/45.

Also, I have a question for the forum. The way I've found these collisions
was to consider a linear approximation of CubeHash with additions replaced
by XORs, and look for an input difference that lead to zero differences in
state bytes b to 127. Then this holds in the actual CubeHash with sufficient
probability if the weight of the input difference is small. I've been doing
this manually, but it occurs to me that the problem can be formulated as
finding a sparse solution to an underdetermined system of linear equations
over GF(2). Does anyone know of an algorithm for this problem?

--------------------------------------------------
From: "Wei Dai" 
Sent: Wednesday, December 24, 2008 12:43 AM
To: "Multiple recipients of list" 
Subject: collisions for CubeHash1/57 and CubeHash2/89

>
> I found collisions for CubeHash1/57-512 and CubeHash2/89-512. For details 
> please see http://www.cryptopp.com/sha3/cubehash.pdf. (I would have just 
> posted the details here, but Prof. Bernstein insisted on a PDF to qualify 
> for his prize. :)
>
>
>
> 


I believe O'Neil is referring to a "birthday =
attack". Correct me if I am wrong, but I was under the impression that a bi=
rthday attack takes 2^n/2 time at 2^0 memory, and 2^0 time at 2^n/2. I beli=
eve the trade off is 2^x time and 2^y memory where x+y =3D n/2.

--Pe=
ter

--- On Wed, 12/17/08, Rene Peralta <peralta@nist.gov>=
; wrote:
From: Rene Peralta <peralta=
@nist.gov>
Subject: Re: cryptanalysis of Twister
To: "Multiple rec=
ipients of list" <hash-forum@nist.gov>
Date: Wednesday, December 1=
7, 2008, 9:07 AM


Hi Sean,

You and others have made t=
his argument regarding several posted
attacks. If I understand correctly=
, what you are saying is that a
collision attack for which TIME*MEMORY i=
s
 greater than 2^(n/2)
is worse that some well-known generic attack. A si=
milar argument
has been made on this list regarding pre-image attacks.
Can you point me to a reference to this generic attack? Also, any
=
references to a rationale for use of a TIME*MEMORY metric in this
contex=
t would be greatly appreciated.

Thanks in advance, Rene.

P.S.=
 I am aware of standard time-memory tradeoff techniques, but I
don't see=
 the connection to the unqualified use of a TIME*MEMORY
metric.

A=
t 12:57 PM 12/13/2008, Sean O'Neil wrote:

>On 12 Dec 2008, at 16:=
59, Martin Schl=E4ffer wrote:
>
>>The attack can be extended=
 to a theoretical collision attack on the
>>hash function Twister-=
512 with a complexity of about 2^231.5 with
>>different time-memor=
y tradeoffs.
>
>You mean with complexity of about 2^231.5 opera=
tions multiplied by
>2^172.7 memory? Wouldn't those 2^160
 circuits find a collision in
>2^96 time for any hash? It is so tempt=
ing to omit that annoying
>memory requirement, isn't it? And then bef=
ore you know it, the hash
>is declared "broken". I am not saying that=
 the cryptanalysis
itself
>is not valuable or that pseudo-collisio=
ns in 2^26.5 operations is not
>a potentially serious threat. I just =
find it increasingly annoying
>having to check every single paper for=
 the fine print to see if it is
>actually cheaper than the brute-forc=
e or other generic attacks or if
>the authors "forgot" to mention mem=
ory the size of our galaxy.
And a
>lot of people just read the ann=
ouncement and trust the experts. They
>see 2^231.5 < 2^256, they a=
ssume that it's broken and the word
>spreads...
>
>Best r=
egards,
>Sean O'Neil
>http://www.enrupt.com/ - Raising the
 bar.
>
>







Hi =
all,



 <=
/span>



   =
      The details about
collision attack on NaSHA-512:



 http://eprint.iacr.org/2008/519<=
/a>



 <=
/span>






Best =
Regards,



Li Ji, Xu Liangyu and =
Guan Xu



 
=



Security Technology =
Research
Department



Sony =
China
Research Laboratory,  Sony (China) =
Limited