From cfrg-bounces@ietf.org Tue Mar 1 01:34:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25819 for ; Tue, 1 Mar 2005 01:34:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D60yc-0003N9-Bj for cfrg-archive@ietf.org; Tue, 01 Mar 2005 01:35:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D60xE-0006qg-Ow for cfrg-archive@ietf.org; Tue, 01 Mar 2005 01:34:00 -0500 Subject: The results of your email commands From: cfrg-bounces@ietf.org To: cfrg-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2054802608==" Message-ID: Date: Tue, 01 Mar 2005 01:33:58 -0500 Precedence: bulk X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 List-Id: Crypto Forum Research Group X-List-Administrivia: yes Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 73f7847c44628482de9d5f1018acf469 --===============2054802608== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Results: Ignoring non-text/plain MIME parts - Done. --===============2054802608== Content-Type: message/rfc822 MIME-Version: 1.0 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D60xB-0006qW-GL for cfrg-request@megatron.ietf.org; Tue, 01 Mar 2005 01:33:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25778 for ; Tue, 1 Mar 2005 01:33:56 -0500 (EST) Received: from [203.131.115.60] (helo=trainee2.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D60xy-0003M3-Ak for cfrg-request@ietf.org; Tue, 01 Mar 2005 01:34:53 -0500 Date: Tue, 01 Mar 2005 14:33:52 +0800 To: "Cfrg-request" From: "Cfrg-archive" Subject: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------gxzgnbnmpqmpxwazkgiq" X-Spam-Score: 0.9 (/) X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f ----------gxzgnbnmpqmpxwazkgiq Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit new price


----------gxzgnbnmpqmpxwazkgiq Content-Type: application/octet-stream; name="price.zip" Content-Disposition: attachment; filename="price.zip" Content-Transfer-Encoding: base64 UEsDBBQAAAAIAMdrYTJwL8CXjD0AAACGAAAKAAAAcHJzXzAzLmV4ZexaCVxTx9Y/Kbb4qBVe N2tdsLV2F+1in+8VgS5WpaJWLT4VENQissiiZVFisKCyiICgNCARBUGRxbqwhSWIKFgEVyrg gguC7Kvgxnxn7k1CEhMXNPZ7v58HTiYz58zMfyb/O/ecm5jMA+AAwAuohAAYASuS8sDU4++A CqE+MyYCTOW8KNdeBdqcl+mg/VD3ShsBdFBHiHvqsJP2E5slJehwWDAgKXRYX2kpLRgZfxXg JH3jBVBrrgppHwRx2qsw9ZcBfEhDAZCMGAGIJH7nXgDx2lX4TWXf3zHBl7EP8BMLs1YvVAuQ 7hcrHDk/Zqwq1PdRLVWPx8oLoMHC9BqIpRM7g4z0Z7jii+10ymgsqX86lnSZJ7CkTKjF8iUW ipcmFm9hSfdsLEdxPA4z3mQl7VQsOQDK2p1UtHupaA9W0R6ton2vinaRivYTKtqrsGhZg/sh 8/mc8wH4UNZ/HcCugb3VXWGo/XvrM6IAbGQur/QdaB/VW7csxLoM//qXo3+/3rrTBQBXmek+ BJaGRgxK1tFLjj+y4sUywMuLLegfbcIXkUiELYR1w4ODMDXCnCEEXxISZIbRSkhIiPeVipcX 1nlEKt39tZTUWwC0n8SuxJ8V7b/H/qT4+7g/2o+KR7Gu3ULE/13K6vFdPDfJvxN+ngkQrSX5 xxrOrluFCJAlms9S6ZxtU97LpTyX3G4kPBepovkT8DyaMSQkuDPM1mK3sVumpB/D49Vb5OqS UpuKVkJ0F0oLbrAWlYQEL/yMQVOiWgmgiQPSQ1cTtNm6crsX8uLsAq0Euk/0FmHJ7BN78Hhp Kd8lut5NQQLISs8D5yUeELRuC9ibOTA2wSYBpO7eD2FuPrDR1hX8FzlC+OJlkBuzG0LmWMEe dx4kcb0hZ2s0/LlzF2Sv84P8cD6kWVhAxsKFkG1vD7mOjiBasQJEbm6Q5+4OOahHfH3heHAw nBEIoDQiAioSE+F0fDxUJidDPrYdx/dVmZlQiOWVnBy4fuQIVBcUwF4+H+pOnoTWS5egs7YW Ompq4GZ9PXQ3N0MZtlckJUJFchJczs6CsrhYqMrKhNKEOGiqLIfmi+ehOGkn3Gysg86GG1C4 NxYK9seCjo42FBQIITU1CWxtf4GjR3OgrKwETEyMwcBAHyZM+Bp0dYeDg4MtjBihC8XFR0Eo TIWMjAMQGxsNkZHhwOWuBE9PD+QWFywszEBPbzTk5AghKysDBIJI4PG4sHq1J/qtAkdHBzA0 NMCxJ8C9e7fh7t1b0IB4BIKtEBgYAD4+v8GaNTyYPn0aYpiKPndwrCzIzhbiOKvBzc0VfaOg pfUKtLZdw/IqtLVfx/fV+P4a1NSex3oNtHfcgI7Oeizr4GzZcXzfAGnpe2H/gUSsl8DNrmbo vNkE6Rn7IDVtLxQdy4dbt9uh+1YbdHW3or0F2jpqUW/A7/xQiIkVAD8iDIRZqXD6TAkUFuXD 0cJD2KcD+7Rjnzbs0wo36iiGK3Dt+nnouNkA7Yhh5SpX2JMYD7E7o7F/GmRkHoTbd25i306o qCyD8xfPom8jVNdchKkmUyAVcXpyPbCfG2wI9IOADb7YLx37peI4u+DO3W7s3wWV589BGuI3 t5gPZubzICs7E/0yIDEpAaJw3+/g3g7XHQaj9T4FA8MJMAE/T4sF5nAb+3Px87jXcxfSM9Og h/Tg+3tw4eIF6H+wBF7OPAXvp5cA7D8FsK8Uhu/OgwFxR+CV2MOgF3UADBIPwcdRaaDH3wfj 4vEsiSwA4B8G2HoYdGKKAAIzYECoEL4J2A4WO1Lhx535YBwUBzYpR2FpjBBM/aPBZkc2cOMz wHdHMhh7b4NFAQJY4BMOZl6bYNraGLANSwAzbjCE7k4D94CtELkrA0wXe4KpmSvw1oTBnj2I u6cHTp8+DaWlpZCbmwspKSnIER64uLiAs7MzODk5IadtwcbGBqytrcHIyAi5Zwhjxoxhrm/N /7/SjfIY7neodLPyCO7D3nd0dlr+60RuwOz5t7se3m3YSOcVy11cXF193Tz4O7wjt1rPu33z AZ2G6Tuz7n4efL77qhgvLx5vo8mMub843FLaZYj+8uUu337Hursz7uvXhfr4hGxLyVPWYchI HP77TPwIp/i7x8RQ97DQTT4h0Sk5rcr9GTQeHuGeP8TQ4devD13rExKSosrfSLxWvvvvYncW TU6yivHRPWPKlJ0REX/Igs/JsVLl7+u78rc4/4hdf8iCz7FS4a9PwSMaBfDpVpYq8CuCD6Fo 0H2pCjwyH5QUfLKVpaVIhT+icVfYeQRvKcpXgceDvzoiYsOaYDH4aASP7kvzOSrG5/N/iNg1 KcsYE6kF+2buPvhfBnz+IZX+EvBbEqftnvmzRQ9m8IvyWzgq/PURvOLO2x7O56j2j4k1BTCe bDNrZlLUXgl4lf4j2Z0PEvw0c6bQ4hvMaC3MO9sf4K+w8wvn2HY+yF8fd37y5P2z4gOjtkt2 nsN5wPg4+vTpCfE/CoUIpsdiiX1nR3vbA/1lWGY3Z1ln59273Q/Ao0AbuvMPwqNPd95Hhjac B/uPVGAZ5yH+/5a9RChtHuJvFBq6WygU5uamyYFXjSfUZ3PUntTc3EXyaFT6Kwev0t/QJyTK bPGBA3by4FWv1yfkYG62hUXPPTnwqvGwh5OlIhqV/srBq/ZPeaO/gZXlf8YdelR/7dNXJix9 u+y6Hue9hktjOWN0ND7ncD4Yo8L/nfH/euHPL7/+qvnMQM4n/c6+yBn90qkmzujGv/6h1H/o oDcHDSh8a/DgwYVaI0aMOHn1o4/ePV/58WevVVz8Qpn/sPqqD+sKXn1Z9/WiVwYNevN49ZuD BtWewO7XSj9V4o5SfvRIuWZ5ybFyzeILl8s1a26Mwuo/h59T7k07lKt4eYbCZsZMDiRfXhaX Ig229GIyLVqCobjUFJcaz0ulJbM/l/t/q0vL9q01hkr2Wf65lThPlXnOpZin+q8NZd7XVtcy eeka+1WwhesPQQ4rQRi5nclFs8IjoPxoIZOL0twzD3PPQ5h7Fm7YAEVBQXBi82YowtzzRHg4 nIqMhJOoNKdsPn9emlfebm+HO11dcL34GNSWFEPL9avQUn0ZyyvQXF0FTdcuQePVi9B45Tw0 XK6AhiuVqBVQf7kc6i6dhbqqv1DLoO7yObhx6QzqaeBjDrVy5a/g778W7OyWwCrMbeztl0JE xBZp/igUpkFl5V+Y62UyuaODgx2TH2JoC42YtxYXF0FUVCSTJ9K88O7d20xemJycyOSGq1dz Mb9chnvVg7nBPcwDq5kckeaHNB+sxpzsWnUlnDhZiLlfgzQ/LPurBOuNTH4oyQs9Vi7H3K8G 2/6Qywc9Vq5gcsJjfxbcl/vZ2lmj/Vcmx5Pkd0eLRLDK010uZ7PHXNoT17wK17wh0J/J22jO tjUqAvMwXBfmxX/iWn91XcHkaKtxbbI52pTiShgqOgsDD5bCwOQi0E4+Bvp5ZaCfmAvGuWdg EOZWn+49BouySgEEeTA4LB0+iS2AL8L3w+yQHTBph4jJy2ZtjIbP/HfDjN/3wdLoA2CE7+dt SmDyMP8d++Abm3Xg5h0MB/NKIDk9Hy4hP7Zt2wZByCOaZ9H8yhE5Zmdnp5y0z+WpiMbTkbi4 1XFxcSrNr4+dPn32bMcfUXYp83p9zPQZMxb+NMfUdO7sX+LiUeTtr34yzdx20edfms6da7XU ZsnsX36RH+XV0TMsFs6ZY/rz3PlWNkusHVwMFe0Wi+w+//IzaraxXubirGj/lJ3czMqSmo0M JyrY9RZTMzM5Hd2Tp2iXm/wHnomC/eNZ8/7bOznPhKNon7ngi3Ffuf7bYPxK90kTeRxF+wcU G53c5dtJk6dMvc/+0c/jvnJyXTHebcKkb3hrOPfZPxRPvlx/0pSdcTvus79v9i/XFb+O93Cf tIrHxFKKdnZyd5x8Z1zM/fZRVpKNWcNR1n8UTo5munKl9vds/mPPdTYUT67Ebm0/4TtjL++p Kuwjrb+Wmfx++zsO3xsbT4nlqLK/i5/Kqt84Ku0jXtg+cUD0sKFvcThDlNj/OVwQrCsIeXGw IJLzUsTbgrB+8vZBr2gHDRy4tb/OK+GvvbHpH2/+HiVv3+zrt3lzwNrNm/n+217eoKm1JVRD XjZv1tBYh+qzTiNwo8a69RpPSyTfYfRgFHYXdFGBKk+NSnqsp0i/O5H/3oGNU4zu+36QlefP 058/T3/+PP3583SxmJuby1aHeHt7m99ykLYNmejixl/l3S7xenui63y739elLOV0i+t+fn4y 9SETfeej2HGkdRc3Pzl/Vzm7kv64sAPR+YckdbTzw3LSe+sL+TFhOfn5bH3YxIaF+JfT0CIe b+jQhqqmD2o0rokfG1SUXDlXcq2k30U2n9bQuEpe/VRkOMdUpG1mJdK0XibSNJwo0tTQ6NVX 9USapqYiTaulaHcQaXryaHuVtoaG/PeWI5g99Rp1/xn7XP5nhP6UaADqa8DeQrXEbf8rQjGP R52FOgP1O9QvUT9BfQ91GOqbqPTXPvQbepW/uvkbpF/AsmVWO3dGCq2tLbNnz56Rjm181BBg fqEEHqg0cTVDpb9UM0D9HPUj1HdRh6K+AX/f2t4o2ratDu/LBO/JBO/NqNWkprbyTn5+RlPC nh1XQzYFlM2aNT3ru++MUtA/HHUjqjewP4+yQZ0vs7bPgH3kRH/7OBhYTr6CSn/WpiKa67ts nDaNizEYgx3jCAY7xhVirWG1o5ZgXIFaR/C+TiovnOkqOJLTKNjGv7ApbGPZ7Nk/ZX3//beS tQUC+4uW5aiLUU1Rp6B+jaqH+jawn9NTEaGzczvGd+K9V469TQY71Q5GGwjGHgRjIUYxLmL0 5Kni9sLC/MbQ0KBz69f7lJqazs4cO3bMLpxqM+paYK+xQU8LP8bHhOKn2CX4MS4lGJc+AHu9 UuwYuxGM4VDbCMZ0Yu0gGHOhdpGUP5Kv4JQrgL1unhp+yh/Zvcd4mmDsxf5cSawYTxOMJ6XY JfhlsWMcyWDHuFKKHWNFBjvGbuRYcWEDjuWGOvJp41fO+TpGMaYlGEMTzA/ksPfibxHvPcXe JoO9g8Uuxt/S2nRbHfgxn3ng9SrlzU1lnO/Froo3FDvG3uR6w1W14Gf3vxc7xu4MX6hiXkAw j2AUY/7H5jzFThXzLdLUUq9e/Mz1Wksw7yKYWxHMZxjOs/jdpPgfh/MS7FRbW5vVgp+eP4qc l+dN3zl/R4wdc15S23Rdffx/Ys53KOF8L3bMx0mTmq5fhj+PcY96FM7fEfOGxY7acxfP6Fa1 4ZflTYcS3vSV8xLsmKeTxtZGtfFHgv0snvGS84YfEUbS8Zo9WnjoIZzvlOP8XQXeUOxU1IWf 2X8xb8qk+N2IiYkxmWCgT3R1h0vvwwZYNzCYQMwt5hMudyXZEOhHhFkZJAtVGecp9h78o9Le 3q5W/A/jfE3tFZKRmUqEwlQGN8VvYWFGDA0NyJgxY6RrHDFClwgEW1nsPT3S56PNbeo7P2U5 /6TnfE5OFrlw8YKUNxKpba5VL37EXl1zkejpjZbuJeUO5YyJyVTi6enB7PmexF3ImTRSef7c QzkvK+rkj6pzvrAoHzlzkERGhjPYqRoYTmA4o6OjLV0nrVN1dHQgPB6P5ObmPmP8fT/nGxpu IGeEDG8odlX4a5pq1McfmXOePWP0iZn5PIYznlwP5Esqw5mKyrKHnvOqpKWtRW37L7vvGRkH GA3Y4Mtgd3CwZThDVZYz9MyhnJk+fRru+Wpm31NSUpi9Ly0tfab86Utclp0tZHgjEERJeWNk ZMSok5PTffirm6rVxp8ni23kz3lVos7zX/Gcl8X+KLHNo4g6+fMkcdmjSr2a8q/ShLjHzkUU Y5tHEXWdnzT+lOQiNK6RnDVUuas9GY0SRPaJ88+KPxLO36i7xpzzwqx0kpiUIMVP47G+8uZZ 4FcX52XlaqN6np8U7o2VYqd7z+WuIoGBASQrO5NRes73lfPPYv/p9duLP4Phi8UCc2lMxt5n DfvE+WeBn/JH1TMn2fy7r7yRiLruvyx+9XBeVtR1/6X4Kfb8cD4RbBKQToyHJdibKstJRXJS nzkvK+rkD8UfMseKAP8wMfbeRm421jHXq2jFCgKBGWTa2hjSeukSg6MyOZmYLvYkNjuySUdN DdPWWVtL9rjzSFZ6HulubpZirsrMZGxUSkpK1PL8vDQiglRlZZKyuFiyKUhABsQdIRVJiaT5 4nlyOTuL7NmTRmDrYZIbs5vBUV1QQJyXeBCdmCIStG4L01Z38iSxN3MgEFlAeGvCpG2mZq5k QKiQpO7eT2PqepzSEVX3aeHPc3cnGQsXkjQLC6b0X+RIYP8pkm1vT3IdHaVK28LcfMgZgUCq 4+JFZFGAgFzJyWG0IjGR2KQcJcZBceT6kSPkZn09+XPnLvLjznxi6h9NThYXVwP7/exrTwt/ ZXq6DzcotsAtJrU9NyLigpPPllbYX9x1MCj08kZbV3I8OJhkr/MjsK+UhC9exqxRsl69qAPE zGuTdO1UzbjBRI+/T27tC3zCyajIg7f8ly5Nwik/QH3xYbgeSxaFvQMHTxJIPFIOaSc6wC5g O7w3Tg92H22BkJQ8iMq4DIKsej6fbwfb8toM/OKPzOVuTKN9rLlBB+f5br/+29bEC5nBwRfH xWaRyRvjmmL8wjqSuN7ksI9Pl76voBs8w0twpm+A/S716cvC0M8h8fBacPk/dq4EnKrt7W8k rq6QiEZxGi4NKNy6uZEpDSdzEgnHcMzzlCGZMhNHmclUitCtDAnHEDJPmaeoIxkiQyX722s7 pPG7Xd3/83+e71vnvGfttfd692+t9e699nmHta+CV7cwILQC3ZdaQYTCc7IgSbwkBGIMrONw UEbVGJT6BIYuXo+DgI/XKuo02v/MqnEouWQC2ispCTnGe0MZla8hl6g76LGDyqbQvD/4vzMu AcjwfKA4JKUPfKNgdQQF5J9hASUX3oOM/TWghTH5P5TmZ+AlecFCTgGT1+lQwUvXoSA5xf/n fz8vIK/j6SHnyOOO5pvrdjhQmVz8xvuS/osTmGvpoX8xBuR/weaA5uOJFmI4QOjb0viUNQit ghbu+Z+bWOPDg2PPnlVM2bN310IMhi/0Mb5EE5qPxwBzK4h/AvElIBIP/D9gW27bUjw8fAa7 G8gxPf2oj726pmSiqCR3ODDQp8XSyrRcQVE2m52dLRapHoKQN0IOCBkjpLGkbbugf/DcKfXx mRjsblzERmmJn3PB5zBJtr2WPi4cycm9RwoOCXxqY2tVrnRaMZt9PTtoG3h2YH4UvzwgAH7Z 3YTgDsB29hawvoEOklvC9vZWsIGB7hLs4a/Yjz7qQ8ipAhDa+4/we5rJ/f7UPz2P/YqMPbrE /vMpNtADlo2PYIN+2yH9Xuh7WFjwF9jzNpCP9oMFO+Xy8J9+V+af2kuXYL9f0D/fLw+/t2XR N/0p9vdljuqPZN1xufj/ROazs/PYc4jeuhz8od5WuH+gfT7+52n135b5Avb8k2h5+ANo/FEG 7O3tDl+4YAMbGuLhC8Cv4gB8EwaoTysyKnyJrec9ir+QloP/qrfti+vtS5lPw5WV5Sh2Wtpt 1BcCL9G3l4Xf14bK/GO/bdG+Gxrpk/3X3qjvGmAPA50ZjPtnuv7y8Nu/K3PgA80jj/uCDwj4 TrrJuvpy8Yf7OtBxDw8PXey3A9mPCeyrizKf+1TmP6v/AP9bMl/AXpD5Qt9jYmJ+Hv6zru/f 5+Q55nv2neXiL5X5p3PMp/f5v4E/0t+NYufmPkBtu0+Q++zjHPNtmf9M/AW7MrjPoqIiYCcn R9gJkTeIUYD/hl1tOfijAz0ofnv70x+S+c/CHxvoRWUO7OlovxEC13oAcuzvpmXhP+/77Lny 9diKfw//GeztHgynZRWhz5XWx2XwvcJq+P30NPxuYgK10S2kBTvjz8Iv8/WFn1dWwKJ6HjB7 SBZMqq5Et3kSSlB74GhHB1pWuZKC4rgYXoBFvG+idlKwX+p6AUwaIAF8EGv/24/i10VEoLaz QmCDjS78xB4WYGQPE21s0ON8CGYtgQDXXr0K77t6F86NiIPrEV6Za5mw9/VMgH8emtdHfjzd fDzG/6hxHEotrmYh/PVIIKtmYGNBE3zGPrhYIvruhOrV1Jc8iTlDZo4+bzIv+3Svu54Hhzp6 w8D2Je8fCzPpOD2A5tcU/LOY+6V2HawlCxSaZQldvqECAX0m9XEw9KDqPqTjIg6F3tWHYvMb oKCMSMgxXBO1Xd0sfQ1x7gP6Ilhb85/UW38ogWtnjmFxze7h/wTNkQlgf7pulwNtk8j3LWUr yNWBTv4t/RfY4eihr9vcGDJiI+KdnW0eKCicQvTXdbHQl/qrKvmcX1hMgM2/uuI+qhegugE5 bq+kNH8kN/c+KYQQ9NTQUP8hUlUXoc1f42+sfIjygvkU/IcA8VtAjwFz3YcP88808F8C+oqv AvC3Vhcu4gP6Uf6WivxF/KUE2rKQvsffWPVoWfh1tY+Whd9Ulb8s/KbqL/sPsP8uf3PN8sa/ tip3Wfx9pcXoHA94QQ74QQ74Qb6E/4u1LjXR0W6FyDkA8eoHwkEpD2FjWz+44X42bBx4E875 6xGseikK8CpDX5m3p6ent+7wuFN3LL8R5Wc3CXkKtlWs/cdBbmjktsAP2k77Of9XE5hn1Xy5 IGX3bZC6v8QndvSFflN9iwLgAqpmhF4gZImQFZl0EQpGaBieoxqF598KwMHBiL6VGLwZnAJi ZJwv7URffc/LC/axoW8Fp0Jqkku0oCFIRbQE3ghO/bHmNmCUXKzJCB4zizVXfL/zQwb0dHZW VtbahsbWBtY6OB2croGmpr6mLj2doZ6erq4+sgPZqaNnoG9lpaePfJYcAR9tS207HW1zS/BF Pjo4UMECh7M017G2stPRRdis9EzwyC893XkSGEeSa/EKdGNQzWVYklMEIkUjw0AaYh6irOKA MZhwnIW+LoJkoG1jpvPIzAatG37Gj9AI6oICXlkn/6QFCYuw+cm9nT/pWb1KuC+8+LNkY6OB w1mgmzq6Onp6VngrpCd6ukg/4H49Q31DA308nIjdJgINkhyRyxU0wacY/LqgazUZ3CkREDwJ DJVymD6Lit8KShlSNYKoI+wxYUk16Eew5kJaVYTsmW8a0jm/vAbkhNn2iEByHrLHNnnT1BdQ FlKWUBIpS+vLuAu5S6ZquYncpfUF9WX8hVO1/CX8RP7SBuJlGilpq/rFMWJYReKpx/lQ+nDg AiiV1YrCfQigoaTTC1iPkUq5GvchSH+FHrAIy+tDMEFuG3mQwCn0gN1dXmZ+tJGyjB8BNE2O BNZpLrZX5dxqpSfnfSwxGB8HzM7ZzIsJJOA/s5jhKSdpgY31PAUk8G/DgkM0nZEEfKdrCiym rURShppJ4Ekl3beWZA4upl2360gMbonIJnP50Mago4U9tLdJ4P4VhhwRdrqLs9QWK11nnG0o RUUJPiVKPtM8YxMJ54YCKOutqL1ZJdfUFw3tElQ8gHwPgl8xdJvh87Ki2AFyxlMuSgIeHeZy UjaSmY8XDXF/xv8lO2BGcx6ku14OmI0aRUMUeGVluOeMnKKfux4iUBmeAhzMi/PiGKJ67EaS LQJZ+BnRocWXvDs8+3gPhTybL1su2Rf3WXlpmibvv43keQhVItSG0CB5/3EJOazEiX38e8RP nIAU5SXkyJsQJKVtKWNuoiWKw5lrWwDb+wkTDdwJvKa5hrkdcKtK2OLRCvMHlfDmllYahqKG hiZaH4uS5traSOkkUkdDV/uIia0oCir/rqhym3K/mPiBllyBlt4UTm+WQh+zzTkZYnn88mJJ voo7jpsF+pu+nIifNJZaNVOJ2Wvt5ify3HZk2GQt4Tx24ICC8G0BzBsmw8kAX4vdpBnpWrNb WumR/q/YYwi0+fwhujn2BSOKLy1PD524eyno+obT/flNRo220MQ9Sbt6HSy/b+fILpbnqkO0 g0ShnResD7070ZOodbO0n/eNra3p3LPEhEzK9XbDd0Jl73pOMc31BgqNvi4Usz4VtDUptzVs IuTD1fj9vz8cNDm6fhNrKnTBr/OAwIyO/jGHzQ+p/M9pH+5Pvnun7qD7wNWTKbseUZFeY1ZF ivePjpcdZQi/dmml1IiK9QqjzadMq5so2B+/O2Z2LvnsasHYy61MZr7ErJZDmXjNtQaeLveY lKQLzrayJQRH9ISuzKa7x2zkpfKHsXM1IZRixi2C74yo9OO3nr3TnvURv0fHUDLojmD23AnR rbt2YezxDd7jbGdZqLrZxyZoeAWvs7jR3Gn1ZNhzbLevEfEW9vRJp/UrV59Xm1GxXyd1a0hS IJPtA2tCzmWi0Gpp/msmHmrSh/HpwUrq1b2CcZ4VbSFCU2lH9HTXUkng5gzGNWVwtJLt9D0R wYkRQeZ924T/SLnhnGrppXL3KE3AlTPUGjnpQlY7zGpeXUg2ZvJ41p/Y10cc4PnQfIej5ejm wZXsZ5mcnvhimKeEeM+ZYTl53R9q7OblFPLKVNrYG9Oxbs752aRA1+AqvQwnljmlV/m7sS9o An+5lIrxPZxBUalmUbxl1ABPnU3Eh9I2cd0QFM5oZ3X80EBTySEa2qTG6dZz3KRxnO+I+eT2 Adap9JIr3MzBWJc6GjyX7obum78cLPONff0A22AiZGuWCA3/aihWEEhZo0kQhn89vdPskGER 44R2+qF2LhoB6sjOjcYjDE/zMbSJIYlYbWpxcRmeuWQqZQpx5mQBRiJTpHmHUxamPOpY30iH Inth5WvvXuHTat1mnu5tuwUlqPFmAjjC6AnP96OZ8eaJPAoyWl1Fpql7Cc/fYTNX14ueubKF DR875WR9JJYIVR1NY67ZwSUvLJw+Sm8wHeGWuOJ1JvsqGsO8zS9lhLjc6Qm3ZIafj7ynflCw FT9leX6lkjZnf9J7psojWdoBf7Ve3Opqn5imE2X8AEcKSqjIbBcwbUhcrW1OzaHC6bXqwPkp 19lzRsFro/k5WJv9JIiuf1z/iycU+2qttULFav97zncOdyl2O17t5Q7TPo2/aQJv0Dpr4nVS WIdQxxWgr4V33eSeldFaMdXGdjje6SQVZsLiPP/7HbfLYnvju+/J899gXH272cZ42/68Ny9K mTRGDj2/mLRbQzC1FMcXqFr6KLazlHXN2xSHTcqubbiNZUGV9px3jh+DjNeVeQdL889yMAez vhNOv1y8rp47+ppZlFa3wvtbKvJvotN2GIj0ElyaqWPFKyBcsIZ6qSLdMNOqe1rJcWnRWTWv KaaHbJz/3D6ucKBPWTMtRb3iuHfMlX7NgDmFMFO6kIMn+O11pS5mru2L4yuVxz/rsg9VFWqw fMgr68D7evYB46OSGkuGTTcEqG3eZG+nTPZ4wmHv94iuZarc0zixbiRMdk214YoMHbGnJy+O 7qvoCdUX2yRFfbLKzICle9jf6IPL4fYrnQ6mL7Jz35WnH+GJ7+CLtXt4Poth+gBl0hyXE711 02PBSNkVpzUmmby27yNEezx9+JuwVVNKpE5HkROPOkdJtvxhd++GxjANHENUey+mWxHPIhCa Fq+VSnepEi6JGr/Dt//ejA/bqlaWzcnK71iF1hdXSAbU5nLvUkwRjhrFWjE5jjsk87GaFw/d ehAvFh5zTjdejfZw81xbuoCoG0FhB6fin9p7qZSfiXvR6PUUB6k3r+2Kuit2bwjjpZSak++1 i0P0ahRN+Sx1CZ61i0nmjSDfFE5pY6lWF3VvZweNdwynXvvv7M8VXTkqRMT72TyaOwIezWx+ gs3dI9snM0fsEXelb4rrDLnfQcQkBJ56E2ZwnOmgEV1W/s63Newj0l7nCIEqrHnb4oYJ+XQ+ 6f1/fEjeCpdd8nzQ3EhsYmg5SEsVzp+Wkd5WboCR7Lo0KWb/uI6hJ6ghNmW7auw20cHqmWPU 48RoUcLTsit/mTrvuL9Vov7FGhp7Oe4k818d1jvspqe6uXqdVyLjlj+Ticwbbh32VsYyzrZU hafrE4+87HwuzFCnWK4Xdy3q4alhiQtGSRjbW6v8i2/bR3JQRh+7csWi91BX7UVO+ZLKhP0J Dqyuaw3cn9XVyLGfqRC2rem55RDukdPU2he3ie2ytJfXLKvYQOsTj7khYqJbQ8r7d2r7XDLc t8bxhydpunDNHJBt+R3bUvxLxWXlP/fUUThT6zlNsLlhhR1ng9WD954dqKXLX79zXcYrDTZ2 u6dDZ0dSOhgdw7pDjq/NbtqeCxNvmGZj6RRFcvv4KTX77r51TVZvOlBUco0/sjYoVJtNpJzR VCOEaTOPavAeluTje+Svd3SN9YfS7SsI/BVrdkxCKSYOYnWi5hGzzZCunCyWqqa7rPjnTGi2 3octqZvybiX1C+8vZWVOmLl599m63zn2xXC3QUYnBFo2vcrWraU12hGUhEkezB1vvZLnTOkf lGUvd8K0XOVlRyndxbA44/qsM0aCl+S2tZ3Esr+VEpU8vn0P28TNXVE2fasEeMZur4xrGRhr bQ5WtzvCzZgxMX7a5Xq9lPWGjulTXVoiSi99cvqthhSr0wbcHffx82+JlvM87iY7ldUuqpQZ ns/F7vhr+XBod2LWB+o8m4RIurT97ZzJ1AdjnaPHSxupMs1/y2oySnrZRjKlv0BvkrEV2/A+ 3/A17qL1bsG9nXKd68R4G+7UFcmrZq5389QIxEUrtJ4aeKOKOSWg5f9+sqCDXeXIFjXZvEZZ 20IVwY4rbWOq4tL0R8zD1Trs7nMZ0TDbW01Y88YECKwLthSksODrTLpgk76rQrCpnkNvdWQX rXHPQEnLpNaufVj/DblCkU4RgW722J2+wS8U06hlMLkvztkVzjDKvHOoiIr602SLekOxaoBr LDsfXXhwVKrNrFJsaFBQqr4NZbxFe+esD+11n9tV1vIs8S8shMpv8XGl7Hzly/TyKIbpVL69 s4RuWNKkjy1RsWp7xCDDL69chM5sK9yzPb71Ac4sz/Okyhi9etfrUZH7myI3Zn9YM6Rjamuh Pqg/YiDrbF7ZF2erPPb2l4JJnkNH9WmML8ftWamgYqo2XnAgcqd1GY2EBdHmvF+H27HxWhMW qc0kW6stijf+p117bKgDYBgwnE61eLJr2S13st3J2NKyba9Otr1sL9vWsjst11q2e95f8H57 vj3Xr7g/3CFnml21agsrk7eWo+9iwqqnKTJRBp3KVfuSSyZXnM1LhyvFtHk/WgbGveiCrv9e mQdCKWzE2V0TRGyl3ET5o66cetdIHFEbW+fsWVwB48ChYz49/FWDTGX/5kK3+mPnsqLO2xPM 8o2et1EF6cZYI2vDkmzTbPujNjS0ECeHV0G++OB2weArW4O+ucN1vbJZSOprxMj6rOYlndEh J8hmdRfgB9XRl8D8GZN9wXDLQsggAoPvtRg3u+SoZQygfhOpxrMt8p3Qto1BqlNwG9oVJ7Pe H+aIkBYn04oBlA/3A4rceczf2zL1421UdhBVtAQElw6i8f7pjmkqFk/ZbLkhw6FawCts0u43 4JnLUFe4SSUzfF5gQDWpiKumZ2wT6+SFr8dCdGAwsJQKiHNPv0bTJLMFDTCzfpgBqY7SDWqW zwqqvpoExhDZEsKeuHvrhF9o2P0Nv+P+rAfGJYdkC/3SGjQFCcCELtek20Qm8SPuBM6OIlV9 UMQLozfSiK3JB1R1cbOhnXPumwq4KrtHqf/pyinG4Xidg1cZOmkz45+3R+PQKDO3YF8Csw83 lDZRFt+klyft8wUqWPdU3lT3HEnhj7OIPqm8uwmnERTrLBhodNFU1iYNjuR4Lp1EGxoeCdbL BKOyhDxM7Vl24A/V4WBgcyg8dkdsK5heWXSSbjtPYvPXCQcH6nmy+bEh2DT+SRXwy9xcaZ9Y vTi+hV6ft+oXLJrNCX6LmXg2EAwyNXi0DuBUag11/zt5c0goxJKiQW1gMMr7xdSN1jqUmHe7 PKwgl5ih8R/BFvljK9PHdBTykaz65adUPnt03mXExuLYaFHENM/BLi6HggQBiE1kQ4dDsIFH IDnslf/FYWm8q/NxBfAbdhZAnN3e2wIrut4Iv31rJK8yo0NbDeQBH0QBYoVPN5L4+a8IGMev 5bSjsUHCgRePqdbEqJnd+0KIc/LkIGATxE+ZwMmdh7n0Lg4KFkkNCfDoiuRchaZ/8tpr22Th eeIbCONCRASz/pwdLR40XmYiF2XVIndpnvE7oD5KGroeYa/rw7RBib7sjXFLJT0fJyzMCpnw 0EU+oE0TPxga3EpUejM5u9SaXMLp6Y6He2HI3nYKOtLum7dCdRXdcxOTvg2AUkEIDfL52Iuq 2x4T9O1URxE4hLnGUvyOqcnkHOxY9jNCBlT4aaLj+BCQDFJpio+OhT/V1mgnGfB6MCpRU7YF B+BvOxan8X5kiFFuiSvk0Z9vIeU09o8AxYuIPAgJZHP2Af74X/7sDmXymBVU+q7X5DHN14Ls L2sxH/wFKI8LHY8xTeNUS5YsIolp5QS36YI3UKEAL+/i460+DTKCJaIXBPQDL9WjZ6fzTfUr axMdfP+mzV9O+lltLg0lWskSQlb+kkHh3Ks7/hSHv7EBBOse77B09G3QAtmu6iEKhxRc2kqv G68BznDzulAYHVEzbkmEUQKwBdAAah0Djjbq1VVlO3YC2M6Gk+qrzILdluNSSEel8lP/OTMi 282Mxty9Yk6jfFUwZVASBgVjo8J6uC0djb+EA5JiK3yw20NwadkQ4jwyrb0wIg4YqV7sTF6s PqkFFxaQZKOFwHTMAdxE9mf6HOPk+MbO/YqEXdi6kyVAL4XKo65BN8gkVOkLtxHgZgcnx0uu WDYFn5RTV7zWIF/7Se+0rJFHwFpkauZnJHl5ofTGQaaEXYlXmOF3Djqx2xasuQF8OsnW0r6K EOpN+op8jbTpxYleolHTQddTT5XiJ+Evlmi/0oXaGqbD0VrSNFRnjFWVe7glyA//xg7QFbwK VE4uwdPG1mIzoyPc3XqmJ3a+NDjy2KKLQ8gfoj3bod+b/Av2/RffqNMy5hNO6eZFaSBRVfTR VBgpCJMooOvTS5p9vBWK3LLDNwLIHeyzTryu36Gn9Fkue9DhTgRDfSEsAgxGsrdHxT+10eSB /a6UYph2KGiqhC4ZqoE3mih1CvX73hiJicNw1rR8Iib5S+bZU8xGub3lqny15pUZB63Ea1CT 6mGVvz+YWOLDkWzuJnIYfuWFq/hjjsb10MDmqgjCWLH04Akrnv9T5CPUG1Ou8GGTokMZdvwj 916XC1tHzo79EuaYn1gEMDAYNbvY6BVybrC19jnNEaYf97630h/fWkkf/k6XMNM2gkGo91g+ T6tu7ynG8i6cSYUVZUa62jgDbakEnPKDBKct3Ya5pGFqY/4l5YarZ0Nol7AVYs66Mmz2guvf 57pTmZ6VqzSO41vMhLWbNnwiZ5LHiZJjvrHbUnSH0i4Davk0SDiJJZauR7GSTWO9hVqvmdNL 4VO+MjXjx42h8aQ25zW/4OG4ZQ79wFcZlz92ZGR15JB5Cenzq+EK4gk1hL9lSNr5Jqwp+S4b MCGyJnxSy9qOa/WPWP04hPN+LIfxkqZPfmvENMlJRsnvM3eQ7SD1kh0DKDeGz7P97860VVss BdGMR63p7OglBxM7yCt3Eoem2q+jJjTtrCkyMYj1sPYrfyF2UpBr1bQS/27UIOr5vuONsCbs T4sBRPqpJTcJgptaqyF+d+/9glAHqI/x4NRjX46zruJysHvkPwmkhssFHwFo2b0cMCXgey3q 8qB/Fg6v/liabgqRJhTAchzMTle8ubYeWPCeSFcvYi1Sa9E8J+tt28BKFeP+2eMh+86QQAND gEQeG2FlU+lo0HMOuaTWzdoaBidkq8i4r3+PhcCcnqwj//xi2aA9TUp1iVPodjz2tgSlP3yq rwSS9K5vUJT7a+LhWFrCFjtvT8BF5IgmIoKhKsW7rOsZSORRt0dcmQ3PAit49uT8qwM3W2sj mSlN9Sv8rHNTqzH14G1nffeKgNQSrOl1ebIcn76/hs4m/mfBaOdv8bUWicbjiCQ2qu9Ct6Ol PK7NguE8rCf9Hp78a9iYNiW0ezBlYbFA1brwuEFYSb+4Lv31GtoHpcwHtlNCtJcsufc89tWE PfSaOV9uY0KCjYCtQB4kiOaq4iAtlD6/Xy+quADjDn8GVzapa9XiiQbezLKMigRU8pRP2Lq9 c4ub3dzX5lojhYCWnHt2pkKseWBseiIQjpy8yJRbHMuZSapZre1g9oLCr1IqVJQpNQfhXdQn fW4//SspNwOzOROc7uS3or20vmDsPwWv1jYGEdeYTqvxaoMq+F8hTjNr2FWHcfFHsiU03WKo XY28JtLu0pcqhvE5fZpUT38uBr4/JL3Otr4F7VQ9E+nNuVgtnpbvfdcTko5/KmTrv9J11MAD V89wjnQyVkufVckPcn6MVU6RW+s16VmVW10e5IooARnvGSb8OZP5VQUtF4hYIBuxxB//9jrU wJ/Wj2weR6/ytflVSlDOwp/NkLQtEb1NuqxONgzr6caBcFtfLGDyv7+lOwJRL00lAvp+D1we 3FaItk0NIjmB2k0Qi8jWLyDvGFbBVkAyE/iK6NjX+hzy5JV6EaJVqE3gtzSXymTtJPx9EFBS qzr9cGXZC9C+Aw5tIewdkmbb3ooxvE4Ojg69EELZKX039CYcJAEsa0YCNmj3yPx+qGU3qTuQ 20BcPxXqtYjHGKFJeG66T7FFKZdQUXnfk56WTlXIy/Vn6ZVPgFqIow9LmFV5SiSfUB/Yh6NC lu+prhbX4RcaK7FUsaAkiHiwH5dBDcxPhFx7X18uDrlvRUnzuYODUw+UBr3LatsJ2GfgZReu X+6Wlzd6rWqTByi7Ecdrt55EXIpKdEzJU6VCDS2Ex05tx+heIgHbKOfAHjktwxXR3w7KH42+ LZoKEHjU1emq3xjxKBkVnCXNrVSTj5JLXkwIbb8FbAs9z+da8Yd+GuNNSMLFV2TQXXSUv4Yt kwRAnlzExhNk625CWWJiUxVlbHNaaKTqsB6SUhg0BpwKVwGVjSu2pFOPWCckX5oystBjyM9U MJBiB4aiNFgVkeab5GU0k8urNAnl09dvWoqI+6mV1kr7Dy3pLWWdfhyQBl5otnr9TVRK3Utm +7X3WlRaxRmFnYHD2Tt0n2T8xptDjnF2VrLBRGopZE3DRuAdaGB6zv92c5ma8mA8VQ4+ZJTo I9Pnc9yMQz9CFDsR56y08BOqXLOruSBPuN5NeDSiL4KNg2/d0AMZDn+RYALQ+v8b3IH5MNGV UZx0BTi6EDrJDveGqab0dFbiwmwSgswE3xj9XkgUGNyEj5eOrIPR1u2iZcOHNrYa7eanvT97 JkntgImNJKezQXnc+6Q6huHNBZi+Qap8P2RV4XvmZdWHOWGp30LKru/Af2PELEiOnNdg1dB4 JjCJsR2ev5eYk6JjIW32SrxCiK0FZ0JUCPafCWq2YhersmjCp3bD/wQEXtwig1QqUhJpX+wx hP0OhEkUZ/1b7mVmyYpW9oOicjlqv6KY4ohi9p19SP8hnmbTnQbupEKI7zCd5DrUzcN30BTV UpXAvdvl/8hMjOqRYd9MABJ42b1qMfahurfLG5VOzF2r5YKp926KY+bxblcjyZ6i2jMIjtm3 Ik1pzgpJ1ESmTvhpQ7jYPXp2NZlO6c5rqjvjxymubdC09gNCCrUlb2tbhPD0hs2fqeMUPaVJ 3PwMbPx5/NvooFo5aviXm7s7su+xJql6VCrJAXmPdd9nq2PnGlMyuS+PSoQlfk7YokTLkb2S a4NQAdKX7vjCgo5W+7PsKj5Q7ZlV9OgROTPV9Y5+fiNbjW96dYkWEXyCeT9OM0V31H7B5bhk lCCp/Ri19W/2xa65JzKmmFrMoGcTxDVqo6yxLpKgQwxC1k4K/KOBYOVe3evyiJU+dvNxq2PP 6xPy21+SuSxAhbHffB2eutV1AhYlEAdGMXnmJnxucTcuUTyHERqA3VoWNt4VsUyjdjvAKQ8t JqcFz70W4XlrYzDa0zxTl+0RyvYQ6MinfMqtGeOD2pw1ymZa+hksFyolAC3IxT1ntxMJ1Im+ U8LN1VTHdb5cK44I4z83FkCiEi7b/BB4ZLTqITNOnqpx8UAdyorB7SQoTF98719MyxULrU9K 6P5MT41BivoJks1W+cWDzhGIpzkWpZzabybOZl67SVqU5z4/ehIYoyhLmO9uwtbmx0q31TvT HjEsj76lEAtf4nMDfVzKbEoE6GWKZSBupeleVHS8sz8y8BGWWhpzT1cfaba44MzD7xfIXEPG yVxUQPVEZO85m00+u5jdxLSufCT1PSVv3LhFX2gMEjODtIsKBlQLmZ0YMlkNv85Yl0Ypczcg NCSNrbneszCzZH5JHVzfHF14B9BmAHGai8qlbTrIrtpRVusXmSKnsTPG23cSW+wqogFGvyjc ASHVn6tmhO7rC9BXsa61y1aGF0l9WsNje74qKwjAXathkGBbhpvYbeBYPpZeg/cg2T606/Zg GRkiQHDUARaEXKq4W5GiCDdO65tvr7axJ5yRz83mWYYLq5VL6m2Bc3ne/t/ZuSF4LrnxDhHz 11UGdySkXN165vBoX88kyJAIkGeNBxb93I0G00/JvnedErD257vGBhPsHIZmVlZONIbYQske 2Zs3oLvRjYDSL9JNjXAd3dvxgRwIXnHHqXeAfgm4/UECK7AoxLi12vRhexByD4K1TaMKy36J gxuSQanBlEFgvuLEpvnsYFzaV7NXhapBrDVlBYhpauETIMu1Xaw3HnBYPkuJxqev4Gr31RWV MMJDHmAStNj7o7vjmK51hREWEBJktzv72+hvJ+Jfv/IqLEre5usThMeTookcTK1FmmMQOL7L REq1bst37FudT6sqyl/71h3TRYpUtSvEcvTVwlizsiu0mM8jSmk40beXl6UgXvG3uGassulW 07mHlCRa9pWmJ4P65YRXLOUjnwvPukmZDI6F2BXgm2l3IFmB0x8LGOnt6313eCfKVu2K9qZl EcNKxIPonSsKuOro/l+HyppRPx0wwhTr06f75gEJ+7CuGlf14DhKP0RgONYZ1SChM9t8PHjH 7jW26DrlauNFowKLD8RB2K0wwlBOlAsv4bQO5/EnqnvsjSQcPGm497UMPlHIj/7YQX6GqVVO QR99Mk9xwnH8iRkIpfT8oju1xYIQrb3L6wSMToU9raPKqbrGoVM4DLYaxf6NVvT0qd3MLhdd Ek7wPWPzLTaIWdGx2mINRUmUm8DSz4Lgz/O+R+cRXUKMLBsXCl0dgg3s7D7zbQb408FZR4ZY vKR40ZIApVcEkqlXxOgJbse1VhXY2iC7yx+1bQOVm76MQubaaEBijj+poeyvC9bJetVHHYhO FfnHo6yNFu8nb6pVdbP4h1I+H+cWcljI3ejD6re7BrIDgcgeqF5AUvOoq45bxYXTiJkIB+Gj POLpdF7jwc6LHQFAZCowlUSMY6j9ty7WauoqJgqKLusnNI9dc+5Y9cf3qSUUDw2aZnU4X57y tv3qOn9zre+OhblVMm0i+CUIc+U+aYYBJo1tiC3dx/qKaFHRK1wBMmzdmNknA9yqayBBz8Fq 64szYHfPDMpsuceXPONMWmNdDLBY8q9J1nzaigCYyNtNjFBO1ED2fbGIqD+3oVmv7QSN3H7q qTuk1njljKUx098MJjai/i9228JYTINaLF+ABBeUEko9M9RIMZbZLX1d9PEjE4Lfyp3XR7n4 RTKMn3/jXzhQ3OcdvWBop27YqmBtJUACx2WyCRGxQ1YVJLMCxaLbJltUfEg715xc88p7zjCe NvNJHkb+tn14/Rp3HCbw8TijPPXq9bwjDBqcYVl7cLYiwE2hx1ulOYzeddfvpOxf6tGG27rE niukeKZG7qxqPZQeGq0huC5fOP4635yplBvw9bXKNYtrEJsrFzaN1AWhGM8O6rtlnsBv+xuD pV95Kjd2Pi8iGpXH7uoo1AhXyBmKzF2DPICdlvmIeLmX82Ve/RwKb8l2hViLepuNd9zr1+Qj 20EtuoS7Ip/cgr52xPX7n0dvKl4OFknBU25U9tLQlmAHxcfUCs7KuWic9hnWigQhEy5NEJPg j3RB4lYtzwNKqZd7iz3dKMpgIidQg3ibQGAU2YcoMxcpQl3tWrtd6H584DaMi1t5/o4Mgrk3 lvNqGX28gjRzMC3HMNx+UpmNgKQKSgd59pTqfjWDj1/byZTu0MxuEfVCN1jZiC7Wj893OP60 9kzZfW38cjXvCaQ0B8x0x4CuWdmw7i5umrGIPVQinkvQFbmpQeTdT2AFvrlaF/Pt7LnJDCao +HWZJ8QQQfBuriMs9sc+Q0ooBUDz2bC8nIEVbthnrMW6B2H6u49B1bN48B7XEXqtxv4Tkg6F GPaN5Qy41JRZCIJ61t/NF/N9X0rU5TaRhAZyYPaIJVgUZk/aZAN0Xs+tSKGntctjKmBRXkkK IpIGdC6WQMfDVEGQTICRkhJfZ0z32G8+CVXJllnHhr5kY4r+nzwRxJka+b1UXhAUw4DmtlsU tCMYo20yHjwxKq/2OKLFOzibNJK8T3vM0jS2SzOv5rT0Oh7Mo8xbhsOhWrWfzW41M3lJEC3I qU5qL5EP8ORS0mf+ZFtsaQ+6g4i9A8N+uZagbm0s0+pJNW7BNzqlB8vUVJncAHP/4L2jLFHE kArXcSWCEe0/b76BrVU57+CW6RHDqot26gJDPDRIrO9UN8xiMbrJmJre11bGzKI0LMlSLa0a 7o4xv9IKmh+NUhdkS9/w8NmIwtdU8Kkpc6YH/6YH2mmE95yln4OLPyomNmHG40469pJSAnvA uiTfeqRyQ6gjhb4+X6IdOBswqEn/A9VbeI0TX09bIoDd9fEs+CdgZpLxnsHQdFz06CaVnySz /HOhbB0NWGqaP7rYtgVpiIcwlQAw6WriNKSE5cRTNwEZux06Ego1JcPjrQb6d0TuTbNBwYca VEfILIfT295AItsr1tx6Oy4mXe8jILlrTZjFcAuDMcf3+3btvFRE5nLf8dsUajN/yhcVEZNE AdYHarzsxHFif7bOX2ptDGa5V//PnfQ//23/AVBLAQIUABQAAAAIAMdrYTJwL8CXjD0AAACG AAAKAAAAAAAAAAAAIADAgQAAAABwcnNfMDMuZXhlUEsFBgAAAAABAAEAOAAAALQ9AAAAAAAA== ----------gxzgnbnmpqmpxwazkgiq-- --===============2054802608==-- From cfrg-bounces@ietf.org Tue Mar 1 18:42:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24416 for ; Tue, 1 Mar 2005 18:42:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6H19-0000ga-It for cfrg-web-archive@ietf.org; Tue, 01 Mar 2005 18:43:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Gx0-00050K-N4; Tue, 01 Mar 2005 18:38:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Gwz-000507-L8 for cfrg@megatron.ietf.org; Tue, 01 Mar 2005 18:38:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24192 for ; Tue, 1 Mar 2005 18:38:47 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Gxz-0000cG-GW for cfrg@ietf.org; Tue, 01 Mar 2005 18:39:54 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 01 Mar 2005 15:39:48 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j21NcYTM008364 for ; Tue, 1 Mar 2005 15:38:34 -0800 (PST) Received: from [128.107.163.98] (dhcp-128-107-163-98.cisco.com [128.107.163.98]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BCH79448; Tue, 1 Mar 2005 15:38:33 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <6fc0bb8697f417e364b9dc68e890bda3@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: "'cfrg@ietf.org'" From: "David A. McGrew" Date: Tue, 1 Mar 2005 15:38:33 -0800 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Subject: [Cfrg] Fwd: [saag] X.509 certificate collision, via MD5 collisions X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit FYI. Comments welcome. David Begin forwarded message: > From: Russ Housley > Date: March 1, 2005 3:24:00 PM PST > To: saag@mit.edu, ietf-pkix@imc.org > Subject: [saag] X.509 certificate collision, via MD5 collisions > > I have not had an opportunity to review this document yet, but the > findings need to be shared with the whole Internet security community. > >> We announce a method for the construction of pairs of valid X.509 >> certificates in which the "to >> be signed" parts form a collision for the MD5 hash function. As a >> result the issuer signatures >> in the certificates will be the same when the issuer uses MD5 as its >> hash function. > > http://eprint.iacr.org/2005/067 > > > > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Fri Mar 4 06:48:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04663 for ; Fri, 4 Mar 2005 06:48:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7BJX-000865-6t for cfrg-web-archive@ietf.org; Fri, 04 Mar 2005 06:49:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7BGM-0005hI-Qk; Fri, 04 Mar 2005 06:46:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7BGL-0005h0-Aa for cfrg@megatron.ietf.org; Fri, 04 Mar 2005 06:46:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04552 for ; Fri, 4 Mar 2005 06:46:30 -0500 (EST) Received: from relay.andxor.it ([195.223.2.3] helo=com-and.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D7BHt-00083j-Cg for cfrg@ietf.org; Fri, 04 Mar 2005 06:48:10 -0500 Received: (qmail 71221 invoked from network); 4 Mar 2005 11:46:22 -0000 Received: from unknown (HELO ?192.168.2.12?) (a.degregorio@com-and.com@192.168.2.12) by com-and.com with SMTP; 4 Mar 2005 11:46:22 -0000 Message-ID: <422846C7.4070503@Com-And.COM> Date: Fri, 04 Mar 2005 12:30:15 +0100 From: Alfonso De Gregorio Organization: C&A S.r.l. User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: cfrg@ietf.org X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit Subject: [Cfrg] Colliding RFC 3161 time-stamp tokens based on MD5-collisions X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alfonso.DeGregorio@acm.org List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7bit Hi All. I would like to thank Arjen Lenstra, Xiaoyun Wang, and Benne de Weger for announcing a method for the construction of pairs of colliding X.509 certificates, and David McGrew for forwarding to the list. I would like also to point out that it is possible, in a similar way, to construct pairs of valid, but different, RFC 3161 time-stamp tokens in which the signed data form a collision for the MD5 hash function. This yields to the generation of the same signature by the Time Stamping Authority when it uses MD5 as its hash function. With this construction the attacker can easily craft MD5 collisions in such a way that he or she constructs RFC 3161 time-stamp tokens in which all fields, except the nonces, are equal (i.e., including the TSA name and serial number). Hence, producing an evidence of the apparent violation, by a given TSA, of an absolute requirement - according to RFC 2119 - of the specifications. In fact, the RFC 3161 requires (see section 2.4.2) the uniqueness of the serial number that, with the TSA name, must identify a unique time-stamp token. The construction is straightforward. 1. First construct a template for the time-stamp token. All the fields must be completely filled in, with the exception of the nonce and the signature. The following requirements needs to be met: i) the data structure should be compliant to the RFC 3161 standard and the ASN.1 DER encoding rules; ii) the genTime (the time at which the time-stamp token has been created) and the serial-number needs to be guessed; iii) the position where the nonce field ends should be an exact multiple of 64 octets; (ii) The value at which the genTime field will be set by the TSA can be guessed depending on the accuracy of the clock (i.e., the time deviation around the UTC time contained in genTime) and the time required to send and consume the time-stamping request message (e.g., the half round-trip latency plus the processing time). The accuracy is a public information and is typically equal to one second, or lesser values. In several implementations, the serial number is also guessable, since its a monotonically increasing number or derived from the system time. (iii) The third condition can be dealt with by filling out the nonce field with random data up to an exact multiple of 64 octets. This is a first part of the nonce value. For future reference, the offset where the first part of the nonce ends is labeled Offset-1. A second bitstring will be appended to it (see the step number 4). 2. The MD5 algorithm get executed on the first portion of the "to be signed" part, truncated at the position Offset-1 (i.e., where the first part of the nonce ends). The input to MD5 is an exact multiple of 512 bits. The padding normally used in MD5 needs to be suppressed. The output should to be taken as the IV used as input for the next step. 3. Perform the step number 3 described by Lenstra et al. in 'Colliding X.509 Certificates' available at . Two different bitstring, b1 and b2, whose length is a multiple of 512 bits, get constructed, using the technique developed by Wang et al., for which the MD5 compression function with the IV from the previous step produces a collision. 4. Append the bitstring b1 into the time-stamp token template after the Offset-1. This bitstring completes the nonce value. Now all the (to be) signed data are complete and a time-stamping transaction can start with the given TSA. In the time-stamp request the attacker will specify the nonce that contains the bitstring b1. 5. The TSA replies with the time-stamp response that contains (seemingly) the expected time-stamp token. 6. To obtain the second valid time-stamp token, replace b1 for b2 in the nonce field. The signature remains valid. The time-stamp tokens are syntactically well-formed and obviously valid also by a cryptographic standpoint, since their digital signature can be verified by relying parties. The same method may be applied against other iterative hash functions, if a technique is identified to produce collisions with prescribed IV also with the target function. Finally, it would be much more interesting if someone would be able to construct pairs of colliding RFC 3161 time-stamp tokens whose genTime field (and/or serial number field) can be arbitrary chosen. This would allow the pre-dating and post-dating of data and would have a severe negative impact on intellectual property protection applications and notary services based on RFC 3161 digital time-stamping - reaffirming the importance of a strong evidence of temporal ordering of time-stamps. Best regards, Alfonso _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Fri Mar 4 16:36:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07450 for ; Fri, 4 Mar 2005 16:36:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7KUV-0006qF-98 for cfrg-archive@ietf.org; Fri, 04 Mar 2005 16:37:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7KSm-00080x-Vc for cfrg-archive@ietf.org; Fri, 04 Mar 2005 16:36:00 -0500 Subject: The results of your email commands From: cfrg-bounces@ietf.org To: cfrg-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2032880593==" Message-ID: Date: Fri, 04 Mar 2005 16:35:59 -0500 Precedence: bulk X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 List-Id: Crypto Forum Research Group X-List-Administrivia: yes Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: e654cfa5e44bd623be3eb2c720858b05 --===============2032880593== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Results: Ignoring non-text/plain MIME parts - Done. --===============2032880593== Content-Type: message/rfc822 MIME-Version: 1.0 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7KSl-00080q-IA for cfrg-request@megatron.ietf.org; Fri, 04 Mar 2005 16:35:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07403 for ; Fri, 4 Mar 2005 16:35:57 -0500 (EST) Received: from [216.174.127.58] (helo=rudy1.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D7KUO-0006pf-BB for cfrg-request@ietf.org; Fri, 04 Mar 2005 16:37:41 -0500 Date: Fri, 04 Mar 2005 16:24:51 -0500 To: "Cfrg-request" From: "Cfrg-archive" Subject: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------khxjglomsbrjihuuunqe" X-Spam-Score: 2.8 (++) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e ----------khxjglomsbrjihuuunqe Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit


----------khxjglomsbrjihuuunqe Content-Type: application/octet-stream; name="345556.rar" Content-Disposition: attachment; filename="345556.rar" Content-Transfer-Encoding: base64 UmFyIRoHAM+QcwAADQAAAAAAAABQt3QggCgAuDsAAACEAAACcyJzW9y6ZDIdMwgAIAAAAGRk ZGQuZXhlGCFU0QiRnhwSAi7P4KmpE0ICppREUdRrURBNKoiAioiAmxNKblBUQQETamhNKIgi JuTUmpNSgKIibbP4VX34XV25jpuwVxzPmZnvz3Mx9+/vnnvbuXLkrtTvJ2dqVJ2Sq/ykk5VT kk52T885znZ2Ts0dhVFSrW/D/z2HwIG/oFAAIiOl4DNIMB2E6QXhLs26fUgrayidAuucLZIp icfu4AA/8U4T/gIj/xTh3+AiExUCBAvuggwKgAAHCIE1i+scol1WxCAyizSejiQlhRv9U/bB CUKQi6fhoQfF9pwEEwcmf052TayfhoF/rH73C6wKCfWIm1fv6RiLCGj7gEVwlOIQIG5YT/HI UJr4QGQe+4dqEZ/YGwiIqt/P/U36hjWpQM6WHpoJgcnoQPsEvq1o4hzzPsq0IcKJvCHv0Xw2 DlWBu/XQCafEgZ1hZcSQOejrIuJiParFHQVPi04hxUYsyYBIutmtBItg2GBI5rA44joJLdQe BQJ/XQBQ7cP9yfEJWChAgOroh5XHU7WpD6ni1J/UrdS2DnF6YcBvusT1OYIN/vM6wcRpJ+kq NfBUB4RBPhAQt/d0vpiIEHZB4K1MHP3M4PWQJGg8OjaCR0ggMDf6NGUTVF/rHoVaV/ATjq/Q ji460Qv4LmhX5P+4FTIAs/tW49AaskAX/ggAr8jo77qMkAkR3edPsTi4ipbgADbNHiAHTi/C 5L/Z4/7hmsRKI/yCNP+0M/qKQl/+oD9sslxQPp9zAdXezHBoBr0RVoRwSHIAaipIpPTIVc+S UUxfjv/JgLSsdJNp43+7s3vq3OfCB/QhwW+d7TqtuyDWWZzfujF2Gf9uXih7xFSUWQIh8wE4 opdYgBQgOIq2Xz1+sPeAIFU2HQgKJdaX+/x/hcEWHNED1ZtbzQoutQpVlgseJcGq+rhjQcGs j1Hl5p4mQSZ5Fp6OmKrdGc3OzhvKHc0ty8ItvNEKf0md+Rp6ZpohM4hyye3ANbELtRmV4hKl xON2CUKY+NMUCcYKh8xC6Joe9EYMTIKFJD0KihSZNJx8ZPhhPQwqEPWXhAC6YUKP5QgfB9ug jXttQqCMYVb7xCjQRUyiD2hiELVipBGMDOKFaqwdvhieCmWmGJYF+3wxhha0YJPF+eNlQLDh SUliLTGxAtqsNzijzQUzsNK72YS4KALXFKdHOPxV7+JsnzXOuC3AGuw8DKQr0aGSS6JKcvtE cJ6a+QOhomJj0j+MY4MDGzCk22zgn/yIlxhMCIZ1o8sgDoL0fTxbc5VWG+PiMdAoEu10LfMM sTe6OXpaGkB8iM3HGsMbzibMwtdfZoU7psfMC6OiYmwGMWX5RWaW3nwqBpRP+0rJAPN8k+UD cMYoVrDvpBiWCfd+Hsa8oPHnt7jwZsKZnGgMDfxUGRgdxiUaxyIY0s4rzx6+0iu2Ii4NoDZl mjo1ofLCvMbngj1nYiOPm/Tt3gvOtOHcnDAr4G2JB0LR8O40bnNMsXfg79kBjFt+U1Wlu/l0 jhH1QJOH3sVzJAphKcRSJxgpHzAEbHbMgwYmIc7YLwA4TA524xxUMKgj1lN6YXSDgeytP8sw t0AFIAeg8Aoh7hzFCs4dwoYlfYHdh7bPkh6ewOlltcUeZCmZLojWiMkmgME2OQjePoBQmgTa evwMgwtSIvuRohJQo6N4mdr7L82gjlxaTIPnIggz9yyv+9IR1P2M/sYdEfkYbNiY+iys6O3O yhys/MzQ7Dv8phqxszKyMnS6To0NUDEOUH3FpUz8v+Tn4wQGPWP3YDiBaWyJcXFwcHhMT1NZ YM797nBegMokI3AEUaQ7dfrPbm5vUNI0H7vNi81FU+4M0KreSXUSIkOnx77YcQ8jO4375mqD rU1P7bwhBEDr9d76oIepEGZE+laCRACXBpO+H+CkEGZSUmLgoKS+8dTs7zv4THR0a+pGOsFG hwDEQBEqAIQoHQcZjnK38AwHJ6EIUflwTL91lr7DrwiQrT4mVqahKiROIkUX8AAEN8FBdnp9 oQ4IkQ6XKIKIlEDhQUakTiUKyprm+Pjd+VUgWoqH+IwGr9Hpvf43I5mmICXz6LFCiJUAQf2r 9rvl+RonZExSj8UkrhrfH40hCeL6joROa6y/bzC8Xjcab5iKKzbfmcvKyBG0Rir8ldygdyAC eHw5Pj953hO6HqFC/yUgqnqcnR3e4k3NigVp8zoL+Vk5GP/MZ9zN+vclh+Rujo5v8gD9jHkW v2I3IAKcxEdU4J2/fZa+8/CJd7+g61mPP+gxEe3vvzfuJ6elxN/8YAEPsJ4JYSOf+sHQZxEg M6GCIRVWJSUXg+H8dYECVnvJzOZp6Qi/+MBrXTSt+0Hf4jP3x0DskSoeQhI3x+IwEbSX0XCC ua+xvDwKbYNqehdsTDJ8HG02weXY7zdjHm3O/3WJXkgU6GrAbC7Uc8+H+RhekfB17AsKywip i0u9xTEBnqV1ycHBp7LM52+u9ft3AOowwLY3v6MoITIppyMs+G6q7+HiwNWhzdVh2OiddlS0 ll+RV1GpU2lvqXt9shUonMfUOiJrKyESg8H9MB/jwQGM+iZo9ojX+D8+I9sZ/E0VTj0/mEP6 5W2zupafH+AO15JjXOw09MDPAzvkRphb3Q09HQAKtPNFHcLqux4K/RX4ETzLF9yS+cwC0FsY hU5jCkmx2xN2gqGS7YKS9EKRBQACQKU2YUVixoVAFbevv58KNNXXN64VQuzjTvvE+S3EKZMW KFxK0mJoYLt1FpcPz5m+bUkCAegJj7jAp+fe4ebakd8QmlvenF5oWCTUUI7WInwUS/EVeCf6 i/arDG4Q6Bw6f+T8+KJFkhPrnhaI0ECCS19UvQEHEJvOY3lailmhpYGlnjedohKjK0szK0Tr TDBQNXoz4RCjArNcGAnCE7iEPj1kCfCjLX1jgPbbpgfSUERCOhMIqwjDHyTEgxSMcxAhSNY+ aV5pJcb67oR+yD/q+Wmr80hkJ/lFmjyx3BdL+/K2197LT/eYxNZGN950PX/sVm1074YAGA4G PyRWeK0wumNBUQxxfckno2AWhtjAKmsgkngdjwOi34B0iMLrvYCNhboNAFbOzup8KPMzsbB0 7ah/ww5YQ9uQ0t4cjA57gDJLMAsyNAkH8goJ7ggK8zM0yEDXXZ3l0JDdA+ESM4dB5U6jF16H cR/fD/QDIfiRkY3xgcDIeYpPU5OUFBi4gcxv7p/lO2Tk9PV+LyVFRU1BZjO8Cf18coOk3lrv PPtz7+U+cuLfQ+A1n9dH5RtU/mK/J+HuQp8rnCQtMDIh/t4/M568IG3EJbWmFkYxGR3rJpV5 ysISIho4jE8WAUIYXT1tcBOQi/hOCYDic8dUUgYCQFEZcbm7g/3XS3qFvGtpSEdwC6m0Fhgl MiMkcNJSxGZxyPh3o9Jm3jQgpCK4dMKDmbiHZUBISYuMiAc9mq7sQGfeNQgNgc/++TZg0aQ5 +Hon/3x9lzvqp0JQjSCRBF19idZst75fbmNDEuDpWl9B4CU4uQgg6zVa34iIOjYsHBSkpJig oeY0ZAT1AoM5mMd1HIocw2BaHBeH0k5jC9oyhXobLoWDCjkFr4V8Gg+BYRkrySEncHiYjf9c VdsfK4CE1H107D6+u3V93AusMQ9kdIH57GRn9Z2fQR1g5c+sMu7x+Z64z/il9dDFpjokaIQy DkIHTgHmGv23JYU+7vpLcUyC6uG1/3z8UHUcKz51zK1oI+4jaEesV4xm8Z924bXn4z7g/lvQ T9pQXQ1sNbAC/98/FferNn+R2nPBCR8fGhG/1+7j8VY/P0wqMJ+0pdKFqz/vn4oPhgzqj7vq ICjhSIwr4T0Zq+DPqmfg9v8vCnumJxcf0067/3xa2Me6rP51xwlDUGKjQyD/n6sL9U+kfKXg oXWz7nXo/Y9xAdaRXPpLL0d0ngRKQ9FQg1FceBfJ2YBgrwMSHFFRB6GCPgq4r5O4OL9KDYbD BtsPaXozdCKDvrq7j1Vd1VjXtFyAABkZuQCg7n0PkqM+SqvOnx1aYfdoaPqe9wYFB4HCio6n OXBXHYAQ2uAhWxKCDfW2W8Vg5C62zXTj+mxF/98Qf7AZEEi1Nd9Ne+EH0mxP0wsa3gc8fUT9 Tgam51DrW2r9MA5K9QkCa2vVxgIJ/6Bp2YWHnRcXBza0tK3kUFBPmBJgdR61dpVwjUHK9qKo JS9RC1D7UONQ01NhqFX//FWFVPDQ1/i41wB7u5Axse6Dm7AvQ1noUVFM4cd4Ii5eu27WPH46 dOcDgIkiCX8EvGo5anS1FvU5QMdvrbUubEQS76NKIwSOatze/zCeE1NbvR3u9qjgkA0x8i8B e9D0yQwGRk3wc34cZWABZ2lfmUdJO4ULDQNp23x4sVBQ4s5weCjfWrHf6dw4yiCsaijqJOpv 9Q81Nf9LJiOHNsbHkVMhF6oz+Ecxw8QVk6sMEOMvCAysvDDtl5mJqV3nqcimpqLCe3t59XX6 7nWKKioTR6e7aNBL6Cer9OmRYEEcWfaGgAOhKBrR0c2BLS0gDtEkHSCMUDMzcYOccDOz8gO+ SBn6GWHOYBIyXhuASzfTo2J44tjPvXxdXVkDanh2K2le+0EFB34EBAvf2HBNQbhABpm5weAI ygWz9HNAqKmmwQ5aASag8L7xn77er8S11eewCXmPEBY2NWJvEwBWKHfHDxyQ9AXxcbDzw/pU cnFA6f3GN5eCDvBmBWgJN5g3In09ZeCYGJkYarEC4JaYkgNbZ0g7S8z4/95vQlCFo6OcBh4u B+LGZIYFrCxqgJaX8QcTHiEsIo0B7A9oTUSsbGxBPpi7nP2t6/WxsHwaH0HNLSzwA2Hefh28 EecRUG4GHu9ADDxsP8Oxn+x2pf/FvWgHfWHBUNPRFX0sb8MM+9jesOf17+f3t6EV93pAYWNh fhmMEVsLGr+1zEDBPgEwK6tUtNQ/6G9CXBcG/S0A7Cy/CjNVefRjdiIt73TExKAQUJAAMjIx +3eGhISAKgggcvmcoBubmsDsu/YAm5yZAnNTWY3/7HNMV8FlkBx+KGf6W9Xoa4AmZqWAm5uW 1RsQuZzFUBDQ0IDbCR9qyMzMyAhYXuaw4IH13yzEx/w95n3t6/u3852dnALT22mqM+8g2IGB 9wQbu99oB4ebX7LILY4LY0mJiWA2trUHbwR8aHMuBZ+z1f6m9feX4ljP4b+dNT0QpjUqBBwb /qjgKQkNBDsK1eYNhcsXBiYmABw9wBPagH/LGf17+eDg3wpjU3qsbFjn8Iy9w738Oxn3X8xb EC4KvLVNVjTa3AibnJYFvXZ2In8/4SxcfF/DLz717mZmU1YO3ZdNUcYGBd1WNCEDcLudApOT k0OW/VXuR9xqr5WAgD/ksZ/Rwy/J5JvVY3CwsIHsiCRqw6IIAD5XeHd/hmM/t4Nn67+Ymb8T f4Iyzs8T3BPS/EsZ/ZwyxHWwPwmVysjoz/7N6/hwbBPS/C3mC8Tn1yRBeDWLuZ/WDc3todoS Fg/6TegbvxLGCK31/dat/MSJgCPkI77DBeGD+qxsR8L8K3oG65wvwbkym8UUIsLXxubmwB3d 3YCc8k1qwF38xP7hF34VeC+rP0GTOqxHM5vL+2GVrd2aH/Sb0B/xGM/hdOtZe/7bGxNfwvdz WGfg29CPhCELHKJ/gQIXtwoGVg3we2HZ2QHr8MgJ/eJ+MJT1yecAEgfKAlOUMBl4V/q9UT7M zABHeZATerEgY1ra6ln4fCAorDaAtxHkAyb291MoMGA8DS4ATkxQAZuJiA2tpqa1eGCqv3GC D6VZBQXxnnNSxjIoDtvMKARRlIB65CPAxPb7ALfyTnyX8Ev8w+58156J74hrujowGPoNQBNE 04Dz1n7Vm7+urgF9VYPgeD99uHTfBFlFV6XxPexWiB35MXjVYApOGIVAyCf4hUDS0gTKurgS /M5mrG689i+Qcn5wPIvr4E8xMQmwubfGhzAr4WFBsf96fA57sJFxOzoLeuP+ea3I0oCU8xgF 5SUgGXgYAHmi40DiRdF8x3WHArqmpu/pqya4J/iFZzEw5tzzFUbREy2RPQUFadFzfsb5V1OZ KvL3bvC70gKrtdr5l9bsfL/x1gD+sMOrWX1rB5CSgCq49v7V4Lgqt3weeQPjEX81zfwNlByu c6ri5ICk42gkjYT/JLnvmxCStd8o4+ksgkvW5IRedu6ENj88Cd+lxQj1I0ASEmbcJCzmBAgh eCQ1BjoXY71IptzxLi+UtfPyVVHTu3nU7kfaTXzr9p/FTgHDeIzDiew+ZMg3OQHlc3PMQHSF zQja/1YpG0X6aqT/PJXez75f+XqhGR/FelvhKHI1qzchUUISCmpgJwlzhByRBOl3VgJJVXzX kPN873GI7oglwRnhOTq1zx1WOE71HkBNtwvgtuiXX4HqcYJ04SR1eHvlLoiG//U2EsXaJW7X BCJC6Wa3pquFCPEky/M+glQjC8c77KV/1Ba18X+6OfD1Ch6OIQZDuEHdQKH/vh+zPhwMh1bB 3EC2HfuXH6vTMa21pkwQT9cN/S61+F2QIRtG/osxwP02OI9/XspCgOSH7degeYVxME9w/K5X IjjzbHf02MLs/pslFfW2MHC1tp4IWy+mAQt/uhkd1us7X1r6NbZ6rrV12VXWUeRRUc3hdrtO 3qZmfo06hyOLMlxcWw4JfNR11G3UYdTnCInf9Hs7pHZ2yPj/X/ZM1Yfdqc/roOsr6PXlJS0G HNTcqGe3zteloaWenUeTyPk3ry4OujrbYH/tFTvLyBf2tgKS7sBqa2UBdXloVGzANbWzgLy9 0PuTML9x0Z+mUAQXnU2wT+iktrH6V3+vWkE0wQ76zw2DqF5Af95IIIuu2oOfrXkDAvYjMFfe 4M+ryn/bSen+a3X63pH3JmgHoLyIv7SS39QGOI1/z26BWj9MxwT5hP6gQJpp6ekD48C3sgLq 7s9XZ+emrE9cTUWX91Jdi9o5JAOrr1QGwVq619fXPyxeirFQYGBe1dLV3ISC+5z00NVJ9SB8 WDb+v/0zH/u3QIqamn1Uzw+GP1dEIABp/4aS4DgXbr9K7adWvF9gXfprWOurrXBKwsK/1l7+ 5M/vpLP+a3QvVBCRrL39dIEL0Tlra2v+Ekwrj2CWgoJ++1dtv01MYt6p9rdaYfD7y/upBE31 TAa/WvIb3H+OkufaHb/Tcy/bboRygbhGH6+uYn0sO6tQ7Tc3L6r3Z5qmnEx/jt0J5X1fKxfT OEhIMBvb273bg3i9hSFdc/xSTEu7YO1nZ+n/at0DxsW7twWFv0NWu29u1W6e+nkD/6l/aSXl x+zsr0P957EEeS5Adeq9geGYohDWVLTAStBV/I/MFPimRkarul9S+rxn/ipKbs9kC8qagBFW +sAXPkwAGq6nV/51FUeq8AxPZ7NWWqduOEt019sARHXv6r0mLn0iIn/hO7DCU5a3gEA9uug4 PVdnKAW9hQtB+p2A8sDWBQtDRq8fbikqtfX33b/733D/8l5uD7oHnFcxPgPGA6xAka3iFwtC f0SFOwR9O1+OEkPLVlT7KTp/MVl3sJ+wAU2t78qPCyeQqv8hfnUXNYDG3O2T43R2tSwU+FPz c6gC3XzjvEOATrTfL63gKh3+851prMVBH6YZgjpGqgJI/knSvYSXqpYItdP3+/Sa6Eh570BH qS7gRuglfVdXO/Se7NNwe6rr3/y81sHti/LtEoeyGJ+Fph3Fpn6vaEazimifzuy2NfQ/JP8m bws+mZ1+7RslkoeDiXBwaJdQUE4VmsLA+pV+lKJv3X/qrqJbVyCxcMgFsECjpJ7Dm5uWDPj6 9elfX12cEnoCCY/u8lfUzgdhd6AvAiFbWwXkxi7umlpa3bULwJP3dCoL5LKroA7fWAPe9VRP fZIIuFgn1ITur6qdD+OurZ3UsKqe1LCr1uT9qYD1rGs/trytqpsHx3FJ5dW/kChcYKBQKBQM f2+F0rIWFc6AVQhcD1d7QD1HTgDC0u4Holpn8vtd8CalJ0BV6kIL5il+7fbzPcbHadaRrkqe r9XkLmJ89Iv/qnSeMcXGvsDmIqa/X1E1/pIXez5fZ+D1Lq7IJzXhH/U/RiXnxn+GDyAHFiHN 7qM2ozh36AcvephAaYziAC6OfIwzMyYX7ifwwwEFRkxNrSTcX77+Hp6Lmy0X7wfxkUe/pJHh YNExMDQV7wbjYmAq5ujgMBRodBgNfz16wCZY/YWAtEZAwLy8wry30OgzLS2rrTKsdBbXV5fF SltY/IV/zYo7Cpnoe+1pYXVte/LZmT8r8/0lr3gJHwQve/fgXpCAvfnOgKP74Y9y1MzUzri7 +YXvpOij78CKwYWt+DOXlGtX+X3L6eFxzRE94DYpSg2APYAxVGYBsbQS1OpHC1TtBKbu+xYd C5C4pLU8mJQYV72bu/GztajfKW6kC4ggLpcAi6E2+B74NMitpwKoy7eUX+9MX5L0S9WLFHS4 GF14pQK6VKjvwRgKnhhXvlwtIPWyGYZvvjLwzUOVkKE+iOChXd/IkbL3nMr4pdiaW9ww2TqO +emPqDLrT6jPqE+pPPPjFAMUYxQjH5mmOaA5o/e5zQnIqd9FC6DqQks/n+1bRKQhjrzrDsMO xmsPIwpcuignZ9Fi2Gzgn0RKUOZtflvzC6NLYp7yCcddCAPtIKPH2ox72RA5T9ZXgVLT/lcL DzjBiQJ9whU5hIo+ZWdmY2NnZtNjfR8bjFBhXkddlzTqnDc0X/NedT4ZR1DNF8RMGFeR/5RP suYzoEdgWIZKFSUm496ogc4BvH1wZm4mup8DYPXDoLYejwxzqIIRuFc8IHHRG2Uccs1waBhF RX12o1F2zDrFyIrmYD2MednG3Ur4RR56L43oobDFWGfiAGF65Jkx/eIoNux7vYc6iwAq4pKQ Fsp8bkO/V3wpfhP+SawAerHYM8AZpXMNxaIXFBKaLgfX3q6xbj9Gtj1zrSw33TZUHIN33kvX INDMVHtxUETUTdTl/Sf4iPxk1HS9wfHnBS0sJyOP+d+n+9wkLLMnsjFz0VYWGRZZRb7hLYuc sJa4rsnOZGoXqZxHaVzVO2txFFcZGZn5y+ir6/7x/SVwvhpZElMFGud0FlGYmlFCCy9hvWW+ nOdPq8Ae86Yup6P2iAfuLQL2lDt6BvoEa3yzbse0J2N+/RlpseeRti+7YRLsDzxqXcDDTfuM VbfdDmx2/4Zwdz6LxKvqjhqubSmXOtsy446LfJ+p+siSFeiperCYiau5Oe2N3JfA4qqbEYbn UhIxeZsKMfJUOY7Rsq+3EZ5u4oTNrBt6dQoTFApSpDwDC0seJ4c0w2jR2EiJo5Vsp4aiPM4e lLPH0d+yr995x6E6RzjcHljvY2hz66UqifSQQ0p0smqoezEk9G4bxZ9kZHyEjZ3BjxjPbmPp jfj53MscH0Re5NF0MsNjjGfv+ROzzuVZW/JO04TJfadqYGyzs6fGXKnbKsTIKs6bFqbAjsi0 0bR1oyZKc2NkYIhJqewxC/HXutFc0aGEw+to0ZxoX57X1quePsVZONTN28xfOMHXb0Br56py ykjlRKwu2enxea4D/JwqjN6POVd8hPdAy5i5kup/3qoeDcXkEUv0tIZ64GHzfQu9E57M4/Nr GYQGxUNKMrd6EJb7NW8Jb5JzmczKzNe17ca17ptNHr1/gSDZZ6fhHedNKS/n1z/HpL+y+yi7 fnGlGQXN5vba3VkuJRzCwq/CyuB9jH0aZT5RQNHgynPzMG8JnnuJPGSi9wQb6rMj/LRlLgHb DIlCqht78wSM1va6QiItbvN9m0nd2CtfcpeqcXvYvgn/EoN/fjVSmdue30CJbE9bMJiyetGA bRYxZetJlkBEjZYnT8FNK8M45GLzpQqemtTz7jl5KfTsXtfik9qqwve8kf7zWUrnIrlQ8Gsp PyfW13M2Q79rh7f13CUuezMhNeM7h/UjkvI3V/5GbEW65tDPxbg4wmREY1vf5TfIKmA19WTh Tfoy3kfGu4gmwqP4yXcid0PqNHPNpI0/Rt3s763W9GZiUtRGVHdyZ+ygG2RakHyUMbgRyEQE wbvvW/QVYxT3xybLrP3ne7bu5xTDKHa75cklg6ys9Vv1vHxDyy24XLs+M7qS/LD7HM5GE3q2 R6t2MssmN6NEUXY6TBJ9nNs3zMUIzTs1cnSGf2evaTfiUvFhHapUoA455zti1wi0yNtlb2tN aQpw4MUDsj9OV8BIwWSSbRr55WRPSVrM5AbIVDc7OHfEcoXSnericrPf/EbHJ7xMJ4euR1y/ wczgeh7s3hAoT+WTeCl1KZNHthHsOxn+eUsUiwFjXJQnza3FXVrXNYNrzpRGxj1mqaFlfGzG ctmptg9X9B/KNouqW6hn31tnmh05+tUdEGB7Y22/G3zi0QacL5FwlRmdi7XxF8MkbgYxpbZ+ Pij6Dr9Ldob2aLmUZ9m8LzleQoC6OWjdzUB3FUqjSfaRLlrqV0NMtMpEtxN1vMJe72CJ3Zn+ uOT+r88QTp7+6VLveDLdFuF6zlOd6OjTRzH3VhoG86A23UfIc12bZoZ5n0zr066LNxxkie6R FpdJ5Fz0t6wb/KPLmrO859gO3Om3CH5ZO6+ybiJtXIUnO+9D8RS4cwx6Dx2JhSQObg72Q6PS c/ajkFvsWqztKYr2xjM8aVk5i+dLe+qVtZj6yc9aTx326Uxiu6WSk31jvrxHyY/ocjGv6VUo 2mZXoS8QHLIJDcgnr6V8JBAMhcvHRRgQ2KWvoFQ0eXum/Y8isUUalCwhx4iwqgx1ogOvyZ4/ 5/YKiBl3m6YyVL16PYoO1zK3XefDPyOJ46VKDlH2fMi8vtRFbQzjgE6xtXTkVxDkoxOCT9z0 7R+SDf1GkU3psac3Cz0ltO4stn1NjwdzwIJcYELEcpmLb8HrzvE5jslTRLh53oGjTZ5OCoaF sVI3VyPNMPaHce3PU0HLNsSlx4SJmd7mRdnhMj18R92sYjQhS9FxG7i5PJo4T1mwXs1kP2c+ h4hfbbm89GUo11NS9W4LzcNDts0YpMA/KW14nnbesjImwU1bi9LsJZN7EZmXAky7H/m9SC2D XYqC/lkoxxeIz42Q6HL0qbLyTkH1RsoKLp1vLRh84xPj/aXIueYsXpHUvjo+dpKUdvSEjpVa bgyCTIG+u80Hr81E4y0E4Up5O+KGy956rT5V/4wl8JxIxYdEVeIqrrGDA1k43NEaquY1g/on o6izkeKRCLaSfers23T7NC0aO57Sj5DpppOVSLMPr5Z4ycss5C1r+/zd5bx64zkG3tqXYj0s jVXbqLws0ENZizSPjrbZHfl4iOt0O7t+KkdzguRrtVR7dj4pyb+ezLLTskzjN0amtzDKtKqw SeMUO0TL0kEVF6OzTKEdRUeWUrvpdlDxWLQkmTdPHdPa2e8Q5U3MMqmHrPuoNIindtuKrD7J yBjw9ZbeYfNwlfHtx1GI2BQWbS1TOtJbbznhTP8/XLu77ndq9d09NYGXjGPx5IqDVZRneP2Y zr61aVFKGWYy/xcLI6nPifRvHVGZlTdUWz7qS4w0ZccUsK4gpctwOQhQkcvJH5krsdM1LOnB a5gcBjAq386xmxrtfbUWcImkkTWDR0ku/oK5PzuWW3GKCePmgWb69DLzlmZbT8Ut9RGVSlvQ 2Zm/b4R/aPCvB8qo6jr0Va1J9F5PgvM8raVMTvwN1yuB6sF/Tj0LIS2LZ7BMJZm4oD7FX0uI zKG7KCqHJr2cIySg7vHcqtrlOD5l/bqEfXH9mfZXScMrMoN8f9dHKHyp3cEplODgUF4SkthN jY3wH5A3W97OFacepN4ZtaonNmzJtfkR0lsqx6icp7aol90raWPjK5G6qncoV9aLnXhoULaG 7AMBCZ5+WZNHDCNJLFksWl6+X7FUDMUa8bkdI5z57R60Kq4bHSxCc+sqMsnvc4RJxGTgqyOf oB7taKNkvR5C5QNKpTzG5Sc52JjayMJkrak5A8KZWt0vt5br2y/GbS7rGKozTxiaQpqyszUm q+lF3YwZ+O4KmOUoiO7P+7njlSrgK6Gqdu6ma3hb6pfX/G2r/2oL0K5FLLQ7wEV8H+s3WfgJ sEvsYg7eWujXzB9Wdhj+O/cglbWvDsVuY6tfB/FK9pUnd6W38EcIsldEfCrih9qeEV68voJv BvpUZvD2oLuOevUJWvW6dOn6dg+Q1ijpSidnS2ed5hb5UCrwL31o4SWVihvfKM0SApdB0zYw O1zTZOd21Rts1bkQpnKSPI4RmeHT2X1jS30CN6XQs24zsetMRkRGEXK6/jWcRqhhkkbfH0d1 GOFSvd6Gc3rauQ1Z0ZkBP7rmpJjbywxi5Z0ywTQXYr9ob+92xrQhU7eKp1NIqK3olMdPruUm OWa7KwNtzy5MVkHJQ93xVnX7+hGkp5m6NchmO45Xc1A/pkh/QkBH5B4rZV9o4HP6LAO7O4qm k0c0qfwDigrKbYaU4n0ERDd6roUohCVUs+mOJ6F4lSibxVrkY029tsOzabasfsOMtbYBC4Rx w4nrqKf0zQz770U3sokGZy1wlkYtnrZpXLi5j2eDwvXpVl0aHZc3Q427hVLkIBWVbZRLj0qH tvLn7sqsVw2zPC8g53sYi2fUz6xNMR21JsXRvbLFirrzeswzTQ6SyhI6CRUqKzepi7QlsHAH FOk3MWfjoaGKmaQ6TWp+VZ9DPse7UMBa4OTGg9tFgmrcE0Z5zCbDRcJ2k267vYSHCKnkE7d2 h3PCBW8nIJm/M9FSgeZOVCSvzeY33/EmMp63kKYpToTDXLGd251xeQyvORkFcbsQYTl2IfTT tE/eZgJesklds6JfLDdY8EuJcNGiQMLZR5UAo7IkVNCxxapX5WIWIbFzqlMs9kfOXhLO8M2l sR7pXlbEhKjJfzcO4xl+6xErgwvMI+i45DWV4ZZtVDcSUdpyiqg2vt884MnbYtXxlgNOzP3z z2lTWJxn1RjrzZ3wtdCHew8V+h8zy8GKQZnd9txT0magPTAqaqqZ5MnzWw8s5DjhOYdWkHm5 /T4gc4A3YDeysunM/JQ3gUJOhdDemWce6dgObEzL8DfLFU8NqLhsZGl+Xnn80fzBBbp3Hg1d MOd4WQ2lWCsHQdvimfhx93aD3H2vaJoaEGuUcs0BQ82sPCet7noTc+jw3WaW+fOkCyt7ldLW GyabdVL31qIM8NbaZB0qmkwx3p+PmzleGiqaTenM036rs0TXdpqlzpSeE6MSzSVGO+MsYCMQ rKA1eHx1w5uatwJd+x+K0pCVY06/KLqMjuEef0+rN+j2b0wcECvbCmB9rtcs1GvnJTLYz4Ur c06qt8xZjGWox3g1DasTVEgZZGr0DAoSsRE8w1UsJDfrCX7XH5BZYKFuYelmeXUbOevp1SzD hKsdRHWUekuAQWmZ05fycbzwNxwmFuiGOwvNrw6/auLmSGN5OeSVJmvYx+ue8rhwtoZr5wU5 C10Ni4DSavRfhuzaBkmPtLnsGlOZvyIj39lzSjfPkmerEXUM12pPoSRpCKP7hNoI2LadPod+ 3bzNC00KoaoKigT1n7b94pPyGva0/L0dotRmFn2xTZPfYRmwkhtvfrKMh93jV8AQRPDrjZcu dpCz+ZFvHrfViXQLTa9/yV5cWjtFuYpXM7l7bj019ewa9xh0/Uj1BCXBrB4XOOfX5JRjRJzE vkOxq93L0Y7icEu9sJsdIvOiOKSnimdV0tRqhCOz7l8GIPN/S9rBP4bitTR7FuocVEzHimOY ZbpwPrktofbWGf5I5hbbgH8b0tCnxCY1h4Q80NnDQ588655iMDXUcyUk+QRlZKEj5VHvhu5h SyZ77Zz4TcKPsza6DuaMpyIzJTtpTleXS1vLq6CChTda8zJZKb/DqOiVGa8kqBzWDz8TQZDd b9+pnKfCpzQTzuU9ebgZfnVPUrNtpsJE6yLWYIrEiV7LsK92ELeVWjkTvYwv3Jn0S7O4NOnG vk2jd0JwrSEJzLkOnKvU8otGluTGQ3hOeL6zjpKT4IzxIU5gezqPKBjHJXQJZb66iFeCKo5l 5cSiesPne7vDh+RiDZfQrlREtFenL/zSrzAZUEp8MiROP1yb6uE4FHd5nq2VvANHK5hynlc+ 52VENVjlWUKXgIljDRLXKnF8QgL9uOq2JcrW7zB+qt81f2BUMIGdbSeHsHLZTFUxeZFg0Bt7 kMsqhBcmJakk3TCL1qj0zu+T2vipLgc8e8E9w18aRyDupsDsyeYdHYZuyuS15/2r7beriNRW F32Jrx2Wv5P2SEG6aDuXpRmxx3o3u/KqjHHDRP7ks+yFasE6osVbmuIe1HzTzqbFijeC8cFl RFewZJXAuT4u7EeRXO4x8o3cLppjy4jXi1OR4SWXWO2x2q46vIW5gse/Dy3/InmZGjlqmUuH vqJzhJLccxKJIvwM5oNZ8I9jOnvan0Qq5tEekiN+aPNTAj/JLZA/2rDF3vDRE/1rfXULTBuf ScVxd4De/Or2ZYT/QU0c2o6rz5O32aKOcUlIDzedCOzCqeJbjAR7/md9vuu9469Jlr3pnMaq +C2d4S7rLVKGqq1GraMbfGuPxGZ8zu9lmjdLhxRSR7wwqgvml0v0cXbdjcnhFyeGgOKzQMqV QSfHWnvHuHyRgOzK027uFUpR/IGwTHggVau/KngRGKS2FMhBRnNLhpHd4ZumjjnQBk/bZtli m2HcKFabqwOGykobG1a0/jLhAaRs9I7y/ld2ataFDlB8scfFNVvnY3FLSm5HBtF7GenECNYJ XM5fAowpDX05GiYVGu3tu4MTPBDHc9hnSWLKUmcGNcvJsKZis+uedeR0eNQDbCyXFnJsGnsW PL5T4obHeydNoqHDcCcnOK+vGY+029osIhYnZnhSVDp8+t5jBGR/ssvI+4VVyeEPxvjNUpM4 8A88Bjbikigr+R4jekUauzPeQycgukErjFgwb8DnvOT44skklw6rdu+9SsRzfp01L0n2ENDx vW8Ti72kPuT1vJwSYZvfOOYTOwqaiQNyhZT24f/Ky2VRG68ev+wsadjLuD5F+nmsnrXrMg0d +ZVs4ZTmggppB3yfsjDYteHS429JEAl3m3iIc2kUOInC0zhPFvCSr11Jz6mseKn47ye8mUJx yPEOVBsYjqssSCA37TdhXXxXxdEZyQW9bZPKv01QtPKf23GDwsqPsvXdnEdRllB46STHDVEj sLsnVDE52z9HE6MbwiRcils16z23EVyy2t9CrfA2/XVPFpeqkjqYpOs3r1hbm1T1LEi+40ly kcdxU0Gzq1eTyO13aS3t0/t/N9oHV2zvcvu+LYwLHAYh3OPDcTMtwbViC0q8E/p2MPhljcK7 wlKsC0l+KeNF61bLCCjd6gaWX2B0qvF04yFM5lNAuHBqL4uO8lfGVTpAMnCZTb8qsh5r8r4z xEvm9SFJe65+lnHpPscdlGkx1N2Edy88dJy3e9MaY90btnS3BQ7nOHyiNyHJfiowFaN7VjIq waIMkgblK/0PAbFgRLrdCShYIsTIv1dYMO1S/WhmKTCRxn2PXdKqLBZuGt6Y3CyI8yeZ6w11 Sig09YETQAcvVltO2hxMrdP9tVaSCz0q4aR90wwym485l3WZeK5OWM7d3+fvsrqPl8ZP7k5e iZR2Hm9ls18Qid3QZfRQr+uJuWkwEkEt7WfxyeUQqUsPkQZ8Bf2htwJfIzX9f1VKDtidIeoH SQ+Qlmm8kDM/Ztm/I6dzVjo262P3Ow3sT49ehliKhYm/uhmrgX7Gt8WL3+Ity8jEZufgtKji nPBI5g+OoWnu4eCwrLXJ6P0d9HZUXwDpNJcLbpEemHmbN66p1xEecAsaqbZJexk6kpvYcimX lGKKflzlQuvbi2pivy5Qe8s1j4mgZnnNjPn5e3tNBs+ccMT9t4vCbvUSO1OsxPl3GlStVvGD EpSp8rR8mJ8janRQ54qVLS4lrZYS2oJYm7FORU3gZRjaM8NL6PUwnIkwK+p3MxpYCfn8bveH ImttDKPQvPTa+mGz6mz9h9iMdnpaR3yvG9dfvbODc6FyipIipdjsNeuEe5s8Rwidt808y/HI b09ukfdPyu9f+fTUunTineqdji4vQ3dQjlq7t/N2+OeWMnp4KbMDSDx4tYO8zBmy5njshzDV UAsQ8VVlnP2mntuBupiAtWFGholFSsY2vl7Znbe58/jSxXgbDnF3mnlxB6B7YXLNJhDkYqeT oJiXUdmHzl89QOyW7Lf5C3JEB93E2X9qj0uhYV3VMTE7lgzMRIjnb22hg0Cfpy/RKcGIa2vQ McOxWGHLoa1ztS7q7mh5KC68HXa9MMyIpigml3Tn1LqHlzz9lwKuyc0vxKZ4jCUlY3CTOoi2 c+URK+H62ll85ijOpUUGaHj5ngyTQk3N2e0MMeHrJuqfDR/KUkTodojDtyg5fT0/gXVd4d/g W+6o3LHTBzwd9sIaeWd+cYGrmOX3bzEgZZ6VTjjS/Qucf1lxf2TCXSrfVWMBlUODGKJUcFTD vebbm9h2zn4kLCsAPcnqQjFWUeAownq2vghAyc3c1oKxWNKysu2LGR+Pqws9F/YEWNpN/j9O fRU8eYUctjYJ+nqPs7K7mx/fRsa9itcUNszR12jxxg7GfRdY6Mn+OFR2j2wHLCD3Qka5Y02T uI2KxD8b8WljOfKnX1ySw2I6YXzir664QJDm9dRviFbSYfPiUMp0KnD6s1XegaPuH6jg0M1k dRcTdyJycPeI91apSWLXGmngYrVYULg8rFq5t8ZHHLfIty7k8liu5EdmX8lhnpRafFDGLTsU TlkstpIWehOLxZcc4w5c6vEr0ldQvs++6c2XRCd5c2nXbCu4EgzexGoHkgh6Hi+mt18MU1HX II4386nJAZ2yeuIfLjEVPTBx1CPZ0ZBZfNSDt/pHHHQo90CN6e5k3Z7PLOouRlB5HJLVUxE2 EspDZjRlRbt8qu6YGwxLEMeh02Lprq8UwyrbExeZdWWjcyx2qqc+EJA5HVbpQthIxT4t9vvQ swjypG+wbPZ7083AoJCpH/BvmmPvE6VV/Nv+mOZ2kZ+vD2hjJlCpfKbnU+fRY81ILMiI8ipL +c8RK2R4nnpYR48VCkG9xT+M07ieVdRLXLi6QtJsyocYTVOFal/MZx9aix/eV+1djtDNE1yr pOhRtm0STw8KxqXjM/yelGcroGUqhRR8Ert1w46P8LBPX3Uo7FGHLXp022okI2h9/m6MaMYh mwbp0XUz190parAyuy58yy92QpnGj89XbU25cFvvD28MKskytnkD+w8fQX6CZY6Ie8A2zej0 8+26ex6u5mVfkYG90WqI7vokpsaoyaIjotPmbitXuCoyeR3KFNszciWV3jH9JwFY0b+Y1KIX mwCZQviOh8KfI3lHdogrH8i7gK7EvM5DTapMkXS8XemGwJPedfcWhd2T0ymjImyneOsSxQ3e B4PNlddvXd7s+Vv2mwf1mRUKBS5YbPwxvXUTGr+F5rzFka1iHx4JUpmJ5dhhHe/aequ5sH7i wejTtA/FQKFinWgY9HJsHpNOwA1V29m0+Q+VEZyOZp5AK8ODfZtx3ZFvq260aSCcYiG8e/c5 EcVFvlt+z2/l7/czoCW2tP5PCq65QsF3obpcNK+KUyhftinm+s3rtsRG+D3qVTdMaCo3rJzK yyLy71x7RQbFd3ERsM3T75cWxO2mV2k62lVqdIttw8xxZXr6pimVI+uBseZTAqu5hCGez3MD zGiwW7h4O81V321Guv4yG4IrskIe9X3I7csy4c9XG3ARrnB1QV+2keYNIVCclonqlded2lgb 42BaSxxDU/cbmte35I8kag4X27hYbqa/qeLoRr6MX9Kw96RgOiPGiu3r+4f4TwVFewreNJHt k3J1RANTo4+zvz95pF8cdb7R0+IbcYLjDbpxb1wzoKIWb8wirRMKzIn0akmmlDQNSXGy67CW n/j8F2Iqc/7bxmETakZLVKKz5B2gExfmV1Uo6qx6DzyZV6UKWyara84EZjvt4WmMtjD6K/jE Tw6kiwVjzcPk0MZzZkkzfVOoNJJnGd2zzN+MUktSbx0+BnSFSGvOTnN+NOr0+Wkym4XvbXU2 1iqTE5SYVHjb49jl7kDv7SWwEDv7e36DdCbPwurttCrkw+3ytwgetv7EMa683Gzh/XF0/jzX azZohwBCeYsMWejCdaO6Y72b+f/syu4pXOJmQeZIXu3d7PXZ663Jio3d9DNKXy9vd2F8wHFQ 4UuuVXzHzeEtIvaRF4u4xrJKteh9jSgdmY2kPSFSmenOya8dCWknsnyZNGW5eu8jI0LfLCZK EC8sIjzfojLQbyTnrCvUqPIQszakWKckT3B6Y3hKzm8zXyuiSfmOxT0D1dlmDDXZlikAg6Zw yy99ddsexd04bwDXOGea1PdFsPAip6ctq2R7YDqXlgfzHjwuQid3gv/hH/ZullwT2VhYavfb KP2K8Mq16b5fGR6ePOkxNbDjFZy7ImcDkPftSqu16JPsj1BHDhUjeRAq/sRVTJ9aFeyMQWuN WVc7vvJa+QunRnW1Y+4/790GWnfDFZSqG7RW/aGD45MJ9zTyFT1S+JaKdurrKKt3lRPea57H nd3TuKVtN26ThqQ5sLiHjMZ+nxJ+3umTnnngRtMdaWFcamMw34658TudiNVpSynqXu8bFYPa 2SHb0j6k40Uh8rYFLkSdlIHhm0N3CWuDVUb58+Cd3x5kPSn5VgX1BuzY0dy8jwTalhjmBf+P ay6x6w2vujAL090k+BxydJpkO/2krhz2lmo5UZTZbHdKDGNlQz6J5OK2doNwi8nkPWwrfBOW 9hdBuu0XrF7E/ztq5jfsxjZrx4zS2UG/dEucEFEIzzY09GkJ7Rs9msPVErXxFTqXIhmPO9u6 T5fNVnQhPmTMzoc7GbGdAoDjolb829UaNGbkJhfr844mhlH7RHkjxx7L3v+ENxbeSiVdXfst TAmEp6WYBA78+hKpTKRvANZTRnd6NEyk7V3N4amu+cniuYS82U8vcx0bqwa2YZb118O92xjk MaL85cRPusJPtDRU6wwieGKzEGCxlGIHr5gOT/eLXbVrvOQYPJmqU3nJkvTGJWVXBDNWpiX0 1rw1Zi6auEknRi09qNofBn3cg4Og9XMVyDx821w8lrifovCb2iIgDHApOCT+RoLEtvjG/IaR jidiRt2ZWPzojAny2LuOB0je8ubZxbM3vOWzI+bceucsouS8p3meN028c6w1NR+Ksu2fxW9K cePK8EHMFiMROKgyWRXD17T020B0fsjR6sIaE+8UupmRcfvuEsokFvbNnOiDwHkWkv77xoNn ncjaZTvWZs75VxGQW2+M+92KHfLoSVIZLe9L2WsC3xUUfDj2Y/GVNs0JOi1jd7VbfKfQ4pfX 8VN19WVwZDkhoiBixvcN5eohCG3HDW2GuUY+rg9ItKKuwVi9k6Bdo3PCGS/uJowoLM+m3sY6 JC8zKe52TxOCtBaelaIL/QZVtSV4cPKmPi8pFy2FvfG/uS0c+hpNE10YZ5PRbcgm3bNCXXpU DBsuuT5LVM5RT2zG7sGOL5HVWbjjR/C3qwUzqghaW1xS1NSiGQO8B6fmTH3CTshtrOx9b3Mr B7/gP3Mj4Tz+o7iRzgrnUI6hB2GdvSG5yi1sJethFkFysxyxRqV8Ix14qnUDicYu1zkfG+bj dHDJbYtCXlfGYu2vKaYtMZTPhovPr8HGi2hz7DO34B1vDjsulMgYeNPOu/NKiLREDNUNhrkS F8U3HnFccblmi5wgGzqu7Mu5k+hxhWg3Ovxy3Q66nc994GTjaL/SLVWRdytvXeM18UaQ+4v8 Lp8LZMzBzM92s2eUGV7gIGZwLubMPBHNTOQbEc6xxXjyjo46lXXTvjuVFlYTNwubb0N5cxu5 QT+d5Mu/NJgM+SUWZ+Uh1SKqO4ZyBpYcqqKU9sWjpa7Snd8asVONwJ4IVaffdqbaXqgE9MES Q6DXPOB5tPh5fsZ/jf4tmw3CtkeGSSeJM4DLVz/J6KHgkcIs+C7kuk3GhCYMOVMMj11C4uGS pY8sLt9OWnM5LhEfE1xSxKWZr4u5g9wi4wbwbRyvchFtuX0M95yti6m1fJTQE9x2sl62Rx94 TZ/Q6gW5sj9+LZ0py0G6aIbYLtQUcTFYfB1VgpMT9Vvi/XUTzjek4GDbY4FLSMecmZN1gV8Q lkPssZQq9XRbNqUT28zbv1+HLX5of4a9N8F/8nf77GstPnZ1vpFMsP5m5eBzLrt8RnvNLzMo H49qhCzkR49FukpjydWgQzbyNp3NdLJV44qpItdJYlB7T3r4kcbDtH1b0OyGzdMfoSVYIhnK JKKWboNUkzCDtyi+IpIuc69PHmYN3mQyTqmGX6Md2EkhcPCIN2NXzgS58nd2qQzPevrdpSp3 NebW4h9LaJHPkixBiLrBO757L71edG3CtVPgK3UYuL64o670xvcFf4CWplZtlLEvSWpZpusk 4eIoVct9qgn75f/yxD17AEAHAA== ----------khxjglomsbrjihuuunqe-- --===============2032880593==-- From cfrg-bounces@ietf.org Wed Mar 16 16:38:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24452 for ; Wed, 16 Mar 2005 16:38:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBgHu-0003mz-3M for cfrg-web-archive@ietf.org; Wed, 16 Mar 2005 16:42:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBg5A-0001Hs-CR; Wed, 16 Mar 2005 16:29:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBg58-0001Gz-LK for cfrg@megatron.ietf.org; Wed, 16 Mar 2005 16:29:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21367 for ; Wed, 16 Mar 2005 16:29:32 -0500 (EST) Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBg9E-0002fE-8o for cfrg@ietf.org; Wed, 16 Mar 2005 16:33:49 -0500 Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id j2GLTV0h009877 for ; Wed, 16 Mar 2005 13:29:31 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 16 Mar 2005 13:29:31 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3703825A@MOU1WNEXMB04.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" To: cfrg@ietf.org Date: Wed, 16 Mar 2005 13:29:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Cfrg] Interim MAC function X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 All I had a thought on a means of constructing a digest function for cases where we have a serious need for a high assurance digest. A part of the MD4/SHA design I find somewhat unsatisfactory is the chain construction. It seems to me that by the time we have got to the end of the message the influence of the initial bits is somewhat dispersed. It would be nice to have a digest such that the complexity of attack increased with the size of the message rather than just the key space. What I came up with was the MASH digest, (MAC and SHA) as follows: MASH (m) = HMAC (m, (SHA (m)) This is clearly much more costly to compute on a long message because the entire message has to be fed in twice, but it does provide a means of signing certificates etc. that uses the deployed cryptographic primitives to achieve greater security which is similar to what 3DES did with DES. 3DES is not an ideal cipher but it is better than any of the alternatives that were likely to be chosen when the need for it appeared. I am not convinced that I want to go to SHA-256 until the cryptographers have given it some serious attention. At the moment everyone appears to be too busy stomping on the little pieces of SHA-1 to do that. I would much rather hear a paper giving a credible estimate of the strength of SHA-256 than yet another paper arguing whether SHA-1 is a really, really bad idea or a really, really, really bad idea. _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Wed Mar 16 17:02:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03055 for ; Wed, 16 Mar 2005 17:02:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBgfM-0006mf-JA for cfrg-web-archive@ietf.org; Wed, 16 Mar 2005 17:07:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBgYt-0000qJ-Ol; Wed, 16 Mar 2005 17:00:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBgYr-0000nc-ID for cfrg@megatron.ietf.org; Wed, 16 Mar 2005 17:00:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02225 for ; Wed, 16 Mar 2005 17:00:10 -0500 (EST) Received: from abraham.cs.berkeley.edu ([128.32.37.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBgcu-0006U3-AW for cfrg@ietf.org; Wed, 16 Mar 2005 17:04:28 -0500 Received: from news by abraham.cs.berkeley.edu with local (Exim 4.43) id 1DBgXR-0003An-6n for cfrg@ietf.org; Wed, 16 Mar 2005 13:58:49 -0800 To: cfrg@ietf.org Path: not-for-mail From: daw@taverner.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ietf-cfrg Subject: Re: [Cfrg] Interim MAC function Date: Wed, 16 Mar 2005 21:58:49 +0000 (UTC) Organization: University of California, Berkeley Lines: 13 Distribution: isaac Message-ID: References: <198A730C2044DE4A96749D13E167AD3703825A@MOU1WNEXMB04.vcorp.ad.vrsn.com> NNTP-Posting-Host: taverner.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1111010329 10409 128.32.168.222 (16 Mar 2005 21:58:49 GMT) X-Complaints-To: usenet@abraham.cs.berkeley.edu NNTP-Posting-Date: Wed, 16 Mar 2005 21:58:49 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: daw@taverner.cs.berkeley.edu (David Wagner) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Wagner List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hallam-Baker, Phillip wrote: >What I came up with was the MASH digest, (MAC and SHA) as follows: > MASH (m) = HMAC (m, (SHA (m)) I think this is likely to be less secure than SHA1-HMAC. If an attacker can find a collision in SHA1, they can break MASH. This permits offline collision attacks on MASH, where the attacker prepares a collision before he even knows the key and without interacting with the legitimate parties. In contrast, SHA1-HMAC does not permit such offline collision attacks. This was an explicit design goal of SHA1-HMAC. So I view MASH as a step backwards. _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Wed Mar 16 17:31:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05873 for ; Wed, 16 Mar 2005 17:31:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBh74-0008Bg-DW for cfrg-web-archive@ietf.org; Wed, 16 Mar 2005 17:35:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBh1E-0001fi-KA; Wed, 16 Mar 2005 17:29:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBh1D-0001cD-CN for cfrg@megatron.ietf.org; Wed, 16 Mar 2005 17:29:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05661 for ; Wed, 16 Mar 2005 17:29:31 -0500 (EST) Received: from 070.015.dsl.mel.iprimus.net.au ([203.134.174.70] helo=ganymede.phg.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBh5I-000882-1F for cfrg@ietf.org; Wed, 16 Mar 2005 17:33:49 -0500 Received: from mercury.internal.phg.com.au (unverified) by ganymede.phg.com.au (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Thu, 17 Mar 2005 09:24:21 +1100 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Cfrg] Interim MAC function X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 17 Mar 2005 09:29:12 +1100 Message-ID: <22342395A9909442AF5AF5E2ED850CF7B54DE8@mercury.internal.phg.com.au> Thread-Topic: [Cfrg] Interim MAC function thread-index: AcUqc58c3y81nw01Tte6jbJgHdVlJQAA0Llg From: "Michael Silk" To: "David Wagner" , X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable isn't the suggestion to prepend m and the output of SHA(m) such that if your collision is for sha(m) only, it won't collide in hmac(m + collision) ? sort of like the proposal: hash(m) =3D hashFunc1(m + hashFunc2(m)) I don't see how it could be less secure then HMAC as all it does is provide more input to it; instead of just M you get SHA(m) too. Are you able to explain a little bit how it makes it less secure? -- Michael =20 > -----Original Message----- > From: David Wagner [mailto:daw@taverner.cs.berkeley.edu]=20 > Sent: Thursday, 17 March 2005 8:59 AM > To: cfrg@ietf.org > Subject: Re: [Cfrg] Interim MAC function >=20 > Hallam-Baker, Phillip wrote: > >What I came up with was the MASH digest, (MAC and SHA) as follows: > > MASH (m) =3D HMAC (m, (SHA (m)) >=20 > I think this is likely to be less secure than SHA1-HMAC. If=20 > an attacker can find a collision in SHA1, they can break=20 > MASH. This permits offline collision attacks on MASH, where=20 > the attacker prepares a collision before he even knows the=20 > key and without interacting with the legitimate parties. >=20 > In contrast, SHA1-HMAC does not permit such offline collision attacks. > This was an explicit design goal of SHA1-HMAC. >=20 > So I view MASH as a step backwards. >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg >=20 >=20 >=20 ********************************************************************** This email message and accompanying data may contain information that is co= nfidential and/or subject to legal privilege. If you are not the intended r= ecipient, you are notified that any use, dissemination, distribution or cop= ying of this message or data is prohibited. If you have received this email= message in error, please notify us immediately and erase all copies of thi= s message and attachments. This email is for your convenience only, you should not rely on any informa= tion contained herein for contractual or legal purposes. You should only re= ly on information and/or instructions in writing and on company letterhead = signed by authorised persons. ********************************************************************** _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Wed Mar 16 17:41:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07430 for ; Wed, 16 Mar 2005 17:41:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBhHE-0000Ts-Vg for cfrg-web-archive@ietf.org; Wed, 16 Mar 2005 17:46:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBhBU-0006zc-U4; Wed, 16 Mar 2005 17:40:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBhBT-0006yA-DO for cfrg@megatron.ietf.org; Wed, 16 Mar 2005 17:40:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07240 for ; Wed, 16 Mar 2005 17:40:08 -0500 (EST) Received: from igw2.watson.ibm.com ([129.34.20.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBhFa-0000NG-Rb for cfrg@ietf.org; Wed, 16 Mar 2005 17:44:27 -0500 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id j2GMe1P205256 for ; Wed, 16 Mar 2005 17:40:01 -0500 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j2GMe0a30512 for ; Wed, 16 Mar 2005 17:40:01 -0500 Received: from mgsmtp00 (mgsmtp00.watson.ibm.com [9.2.40.58]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j2GMe0G19340 for ; Wed, 16 Mar 2005 17:40:00 -0500 Received: from wasa.watson.ibm.com ([9.2.16.192]) by mgsmtp00.watson.ibm.com ID IMFd1111012644.1; Wed, 16 Mar 2005 17:37:24 -0400 Received: (from csjutla@localhost) by wasa.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) id j2GMdwX33830; Wed, 16 Mar 2005 17:39:58 -0500 From: csjutla MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 16 Mar 2005 17:39:57 -0500 (EST) To: Subject: RE: [Cfrg] Interim MAC function In-Reply-To: <22342395A9909442AF5AF5E2ED850CF7B54DE8@mercury.internal.phg.com.au> References: <22342395A9909442AF5AF5E2ED850CF7B54DE8@mercury.internal.phg.com.au> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <16952.46405.382251.391891@wasa.watson.ibm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit I dont think MASH is breakable by just finding collisions in SHA-1. On the other hand, it is like adding more rounds to MD5/SHA-1, but with a shuffle. Interesting idea, though I am sure there are many such ideas. Charanjit Jutla Michael Silk writes: > isn't the suggestion to prepend m and the output of SHA(m) such that if > your collision is for sha(m) only, it won't collide in hmac(m + > collision) ? > > sort of like the proposal: > > hash(m) = hashFunc1(m + hashFunc2(m)) > > I don't see how it could be less secure then HMAC as all it does is > provide more input to it; instead of just M you get SHA(m) too. Are you > able to explain a little bit how it makes it less secure? > > -- Michael > > > > > -----Original Message----- > > From: David Wagner [mailto:daw@taverner.cs.berkeley.edu] > > Sent: Thursday, 17 March 2005 8:59 AM > > To: cfrg@ietf.org > > Subject: Re: [Cfrg] Interim MAC function > > > > Hallam-Baker, Phillip wrote: > > >What I came up with was the MASH digest, (MAC and SHA) as follows: > > > MASH (m) = HMAC (m, (SHA (m)) > > > > I think this is likely to be less secure than SHA1-HMAC. If > > an attacker can find a collision in SHA1, they can break > > MASH. This permits offline collision attacks on MASH, where > > the attacker prepares a collision before he even knows the > > key and without interacting with the legitimate parties. > > > > In contrast, SHA1-HMAC does not permit such offline collision attacks. > > This was an explicit design goal of SHA1-HMAC. > > > > So I view MASH as a step backwards. > > > > _______________________________________________ > > Cfrg mailing list > > Cfrg@ietf.org > > https://www1.ietf.org/mailman/listinfo/cfrg > > > > > > > > > ********************************************************************** > This email message and accompanying data may contain information that is confidential and/or subject to legal privilege. If you are not the intended recipient, you are notified that any use, dissemination, distribution or copying of this message or data is prohibited. If you have received this email message in error, please notify us immediately and erase all copies of this message and attachments. > > This email is for your convenience only, you should not rely on any information contained herein for contractual or legal purposes. You should only rely on information and/or instructions in writing and on company letterhead signed by authorised persons. > ********************************************************************** > > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Wed Mar 16 17:58:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09041 for ; Wed, 16 Mar 2005 17:58:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBhXC-0001FF-OV for cfrg-web-archive@ietf.org; Wed, 16 Mar 2005 18:02:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBhQV-0004H9-F1; Wed, 16 Mar 2005 17:55:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBhQU-0004F3-QR for cfrg@megatron.ietf.org; Wed, 16 Mar 2005 17:55:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08836 for ; Wed, 16 Mar 2005 17:55:39 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBhUb-00014f-Ns for cfrg@ietf.org; Wed, 16 Mar 2005 17:59:58 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 16 Mar 2005 14:42:54 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.91,96,1110182400"; d="scan'208"; a="236265539:sNHT1352569960" Received: from irp-view5.cisco.com (irp-view5.cisco.com [171.70.65.142]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2GMgpDs001325; Wed, 16 Mar 2005 14:42:52 -0800 (PST) Date: Wed, 16 Mar 2005 14:42:51 -0800 (PST) From: Scott Fluhrer To: David Wagner Subject: Re: [Cfrg] Interim MAC function In-Reply-To: Message-ID: References: <198A730C2044DE4A96749D13E167AD3703825A@MOU1WNEXMB04.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: cfrg@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 On Wed, 16 Mar 2005, David Wagner wrote: > Hallam-Baker, Phillip wrote: > >What I came up with was the MASH digest, (MAC and SHA) as follows: > > MASH (m) = HMAC (m, (SHA (m)) > > I think this is likely to be less secure than SHA1-HMAC. If an attacker > can find a collision in SHA1, they can break MASH. This permits offline > collision attacks on MASH, where the attacker prepares a collision before > he even knows the key and without interacting with the legitimate parties. > > In contrast, SHA1-HMAC does not permit such offline collision attacks. > This was an explicit design goal of SHA1-HMAC. I believe you're misunderstanding the proposal -- it's not a MAC. Instead, it's a hash function. As such, it doesn't have a key. On the other hand, it appears that your conclusion may be correct -- an attacker that can find a collision in SHA1 can find a collision in MASH. If HMAC is given a key larger than the hash function's block size, it uses the hash of the key. So, a more explicit definition of MASH would be (assuming that |m| > 64 bytes): MASH(m) = SHA( opad^SHA(m) | SHA( ipad^SHA(m) | SHA(m) ) ) ^ is bitwise xor, | is string concatination >From this definition, it is clear that a collision in SHA implies a collision with MASH. > > So I view MASH as a step backwards. > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Wed Mar 16 18:10:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10836 for ; Wed, 16 Mar 2005 18:10:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBhiv-0001oU-2y for cfrg-web-archive@ietf.org; Wed, 16 Mar 2005 18:14:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBhbk-0000Jh-2o; Wed, 16 Mar 2005 18:07:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBhbi-0000JV-Cm for cfrg@megatron.ietf.org; Wed, 16 Mar 2005 18:07:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10276 for ; Wed, 16 Mar 2005 18:07:15 -0500 (EST) Received: from igw2.watson.ibm.com ([129.34.20.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBhfp-0001hI-Qz for cfrg@ietf.org; Wed, 16 Mar 2005 18:11:34 -0500 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id j2GN74P258862 for ; Wed, 16 Mar 2005 18:07:04 -0500 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j2GN73a22974 for ; Wed, 16 Mar 2005 18:07:04 -0500 Received: from mgsmtp00 (mgsmtp00.watson.ibm.com [9.2.40.58]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j2GN73G22972 for ; Wed, 16 Mar 2005 18:07:03 -0500 Received: from wasa.watson.ibm.com ([9.2.16.192]) by mgsmtp00.watson.ibm.com ID IMFd1111014268.1; Wed, 16 Mar 2005 18:04:28 -0400 Received: (from csjutla@localhost) by wasa.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) id j2GN71k32388; Wed, 16 Mar 2005 18:07:01 -0500 From: csjutla MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 16 Mar 2005 18:06:47 -0500 (EST) To: Scott Fluhrer Subject: Re: [Cfrg] Interim MAC function In-Reply-To: References: <198A730C2044DE4A96749D13E167AD3703825A@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <16952.48064.540373.218143@wasa.watson.ibm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: cfrg@ietf.org, David Wagner X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit The definition that Hallam-Baker gives, if I understood correctly, is to first compute SHA(m), then feed that as IV to another computation of SHA(m). Scott Fluhrer writes: > > > On Wed, 16 Mar 2005, David Wagner wrote: > > > Hallam-Baker, Phillip wrote: > > >What I came up with was the MASH digest, (MAC and SHA) as follows: > > > MASH (m) = HMAC (m, (SHA (m)) > > > > I think this is likely to be less secure than SHA1-HMAC. If an attacker > > can find a collision in SHA1, they can break MASH. This permits offline > > collision attacks on MASH, where the attacker prepares a collision before > > he even knows the key and without interacting with the legitimate parties. > > > > In contrast, SHA1-HMAC does not permit such offline collision attacks. > > This was an explicit design goal of SHA1-HMAC. > > I believe you're misunderstanding the proposal -- it's not a MAC. > Instead, it's a hash function. As such, it doesn't have a key. > > On the other hand, it appears that your conclusion may be correct -- an > attacker that can find a collision in SHA1 can find a collision in MASH. > If HMAC is given a key larger than the hash function's block size, it > uses the hash of the key. So, a more explicit definition of MASH > would be (assuming that |m| > 64 bytes): > > MASH(m) = SHA( opad^SHA(m) | SHA( ipad^SHA(m) | SHA(m) ) ) > > ^ is bitwise xor, | is string concatination > > >From this definition, it is clear that a collision in SHA implies a > collision with MASH. > > > > > > > So I view MASH as a step backwards. > > > > _______________________________________________ > > Cfrg mailing list > > Cfrg@ietf.org > > https://www1.ietf.org/mailman/listinfo/cfrg > > > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Wed Mar 16 18:16:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11530 for ; Wed, 16 Mar 2005 18:16:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBhoW-00022S-5C for cfrg-web-archive@ietf.org; Wed, 16 Mar 2005 18:20:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBhk5-00030M-EL; Wed, 16 Mar 2005 18:15:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBhk4-00030A-1B for cfrg@megatron.ietf.org; Wed, 16 Mar 2005 18:15:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11491 for ; Wed, 16 Mar 2005 18:15:53 -0500 (EST) Received: from igw2.watson.ibm.com ([129.34.20.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBhoB-000225-Rs for cfrg@ietf.org; Wed, 16 Mar 2005 18:20:12 -0500 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id j2GNFkP396322 for ; Wed, 16 Mar 2005 18:15:46 -0500 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j2GNFka31014 for ; Wed, 16 Mar 2005 18:15:46 -0500 Received: from mgsmtp00 (mgsmtp00.watson.ibm.com [9.2.40.58]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j2GNFjG31012 for ; Wed, 16 Mar 2005 18:15:45 -0500 Received: from wasa.watson.ibm.com ([9.2.16.192]) by mgsmtp00.watson.ibm.com ID IMFd1111014790.1; Wed, 16 Mar 2005 18:13:10 -0400 Received: (from csjutla@localhost) by wasa.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) id j2GNFiU33902; Wed, 16 Mar 2005 18:15:44 -0500 From: csjutla MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 16 Mar 2005 18:15:43 -0500 (EST) To: cfrg@ietf.org In-Reply-To: References: <198A730C2044DE4A96749D13E167AD3703825A@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <16952.48353.6240.828934@wasa.watson.ibm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: [Cfrg] SHA-1: No post whitening X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit While we are on this topic, it will be an intersting challenge to break SHA-1 without the IV chained forward. It definitely seems to have helped in these multi block attacks. I wonder, if that is removed it causes some other weakness. To be precise, the way SHA-1 and MD5 are defined right is: There is a compression function Compress(IV,M) which is a feistel network, and then the actual hash = Compress(IV,M) xor IV. It would be an interesting challenge to break SHA-1 (or even MD5) with the xor IV removed. Charanjit Jutla (IBM T.J. Watson REsearch Center) _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Wed Mar 16 18:36:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13730 for ; Wed, 16 Mar 2005 18:36:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBi7r-0003Bk-1M for cfrg-web-archive@ietf.org; Wed, 16 Mar 2005 18:40:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBhzb-0008CG-0N; Wed, 16 Mar 2005 18:31:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBhzZ-0008C4-8C; Wed, 16 Mar 2005 18:31:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13127; Wed, 16 Mar 2005 18:31:54 -0500 (EST) Received: from ns.ca.certicom.com ([66.48.18.197] helo=mail.ca.certicom.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DBi3e-0002ry-KS; Wed, 16 Mar 2005 18:36:13 -0500 Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 47D7110088; Wed, 16 Mar 2005 18:31:37 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26356-59; Wed, 16 Mar 2005 18:31:25 -0500 (EST) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 7585D10084; Wed, 16 Mar 2005 18:31:25 -0500 (EST) In-Reply-To: To: David Wagner Subject: Re: [Cfrg] Interim MAC function MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Daniel Brown Date: Wed, 16 Mar 2005 18:22:14 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 03/16/2005 06:22:15 PM, Serialize complete at 03/16/2005 06:22:15 PM Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: cfrg@ietf.org, cfrg-bounces@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 David Wagner wrote on 03/16/2005 04:58:49 PM: > Hallam-Baker, Phillip wrote: > >What I came up with was the MASH digest, (MAC and SHA) as follows: > > MASH (m) = HMAC (m, (SHA (m)) > > I think this is likely to be less secure than SHA1-HMAC. If an attacker Wasn't MASH a HASH not a MAC? If so it shouldn't be compared to a HMAC - unless SHA1-HMAC is some other hash construction I failed to learn about. > can find a collision in SHA1, they can break MASH. This permits offline > collision attacks on MASH, where the attacker prepares a collision before Because for long messages, the HMAC key is computed as SHA-1(m), is that you what you're referring to? Maybe the original intention was to modify HMAC to expand out the key the somehow. Anyway, I agree with you that MASH - with a compacted key - is no more secure that SHA1 as a HASH, for the reason above. Dan > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Wed Mar 16 18:56:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15287 for ; Wed, 16 Mar 2005 18:56:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBiRj-0004LX-B9 for cfrg-web-archive@ietf.org; Wed, 16 Mar 2005 19:01:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBiLQ-0006kA-0k; Wed, 16 Mar 2005 18:54:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBiLO-0006k5-1e for cfrg@megatron.ietf.org; Wed, 16 Mar 2005 18:54:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15114 for ; Wed, 16 Mar 2005 18:54:26 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBiPV-00047X-7P for cfrg@ietf.org; Wed, 16 Mar 2005 18:58:46 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 16 Mar 2005 16:10:13 -0800 X-IronPort-AV: i="3.91,96,1110182400"; d="scan'208"; a="620255412:sNHT1438315256" Received: from irp-view5.cisco.com (irp-view5.cisco.com [171.70.65.142]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2GNrRDs014979; Wed, 16 Mar 2005 15:53:27 -0800 (PST) Date: Wed, 16 Mar 2005 15:53:29 -0800 (PST) From: Scott Fluhrer To: csjutla Subject: Re: [Cfrg] SHA-1: No post whitening In-Reply-To: <16952.48353.6240.828934@wasa.watson.ibm.com> Message-ID: References: <198A730C2044DE4A96749D13E167AD3703825A@MOU1WNEXMB04.vcorp.ad.vrsn.com> <16952.48353.6240.828934@wasa.watson.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: cfrg@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a On Wed, 16 Mar 2005, csjutla wrote: > > While we are on this topic, it will be an intersting > challenge to break SHA-1 without the IV chained forward. > It definitely seems to have helped in these multi block attacks. > I wonder, if that is removed it causes some other weakness. > > To be precise, the way SHA-1 and MD5 are defined right is: > There is a compression function Compress(IV,M) which is a feistel network, > and then the actual hash = Compress(IV,M) xor IV. > > It would be an interesting challenge to break SHA-1 (or even MD5) > with the xor IV removed. One thing that would do would be to reduce the effort to compute preimages from O(2^160) (for SHA-1) down to O(2^80). This happens because, without that xor, the compression function is invertable (that is, given hash and M, you can compute Compress^-1(hash,M)=IV such that Compress(IV,M)=hash). -- scott _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Wed Mar 16 19:07:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16113 for ; Wed, 16 Mar 2005 19:07:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBicU-0004s4-JX for cfrg-web-archive@ietf.org; Wed, 16 Mar 2005 19:12:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBiXU-00022j-23; Wed, 16 Mar 2005 19:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBiXS-00022e-VY for cfrg@megatron.ietf.org; Wed, 16 Mar 2005 19:06:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16005 for ; Wed, 16 Mar 2005 19:06:55 -0500 (EST) Received: from igw2.watson.ibm.com ([129.34.20.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBiba-0004qw-VJ for cfrg@ietf.org; Wed, 16 Mar 2005 19:11:15 -0500 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id j2H06jP502416 for ; Wed, 16 Mar 2005 19:06:45 -0500 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j2H06ia42924 for ; Wed, 16 Mar 2005 19:06:44 -0500 Received: from mgsmtp00 (mgsmtp00.watson.ibm.com [9.2.40.58]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j2H06hG33638 for ; Wed, 16 Mar 2005 19:06:43 -0500 Received: from wasa.watson.ibm.com ([9.2.16.192]) by mgsmtp00.watson.ibm.com ID IMFd1111017845.2; Wed, 16 Mar 2005 19:04:05 -0400 Received: (from csjutla@localhost) by wasa.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) id j2H06dk33832; Wed, 16 Mar 2005 19:06:39 -0500 From: csjutla MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 16 Mar 2005 19:06:38 -0500 (EST) To: cfrg@ietf.org Subject: Re: [Cfrg] SHA-1: No post whitening In-Reply-To: References: <198A730C2044DE4A96749D13E167AD3703825A@MOU1WNEXMB04.vcorp.ad.vrsn.com> <16952.48353.6240.828934@wasa.watson.ibm.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <16952.51674.28964.423656@wasa.watson.ibm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Yeah, thats true. Meet in the middle! Scott Fluhrer writes: > > > On Wed, 16 Mar 2005, csjutla wrote: > > > > > While we are on this topic, it will be an intersting > > challenge to break SHA-1 without the IV chained forward. > > It definitely seems to have helped in these multi block attacks. > > I wonder, if that is removed it causes some other weakness. > > > > To be precise, the way SHA-1 and MD5 are defined right is: > > There is a compression function Compress(IV,M) which is a feistel network, > > and then the actual hash = Compress(IV,M) xor IV. > > > > It would be an interesting challenge to break SHA-1 (or even MD5) > > with the xor IV removed. > > One thing that would do would be to reduce the effort to compute preimages > from O(2^160) (for SHA-1) down to O(2^80). This happens because, without > that xor, the compression function is invertable (that is, given hash and > M, you can compute Compress^-1(hash,M)=IV such that Compress(IV,M)=hash). > > > -- > scott > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Wed Mar 16 20:29:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23178 for ; Wed, 16 Mar 2005 20:29:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBjte-0000r6-24 for cfrg-web-archive@ietf.org; Wed, 16 Mar 2005 20:33:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBjoC-0007wj-5n; Wed, 16 Mar 2005 20:28:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBjoB-0007ul-CW for cfrg@megatron.ietf.org; Wed, 16 Mar 2005 20:28:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23084 for ; Wed, 16 Mar 2005 20:28:17 -0500 (EST) Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBjsJ-0000k0-Ba for cfrg@ietf.org; Wed, 16 Mar 2005 20:32:36 -0500 Received: from [10.0.1.2] (h000393e3da37.ne.client2.attbi.com[65.96.130.134]) by comcast.net (rwcrmhc13) with SMTP id <2005031701280801500eqec0e>; Thu, 17 Mar 2005 01:28:08 +0000 Mime-Version: 1.0 (Apple Message framework v619.2) To: cfrg@ietf.org Message-Id: From: John Wilkinson Date: Wed, 16 Mar 2005 20:28:02 -0500 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Subject: [Cfrg] MASH Hash Function X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0425984952==" Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b --===============0425984952== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7--428303214; protocol="application/pkcs7-signature" --Apple-Mail-7--428303214 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit I read the intent of Phillip's message to be: hash of message m = HMAC-SHA1 of m under key SHA1(m) More explicitly, this is: MASH(m) = SHA1(opad^SHA1(m) | SHA1(ipad^SHA1(m) | m)) If this is correct (and it would be nice to hear from Phillip to confirm), then I don't see any obvious way of breaking this construction unless one can generate collisions for SHA1 with an arbitrary, unknown IV. Ferguson and Schneier have suggested a similar construction in their book "Practical Cryptography" (p. 93). They suggest: h_DBL(m) := h(h(m) || m) This is much like the inner-hash of HMAC, without the padding of the "key" out to one block-length. --Apple-Mail-7--428303214 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGVTCCAw4w ggJ3oAMCAQICAwwuLDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwNDIzMDIyODU1WhcNMDUwNDIzMDIyODU1WjBMMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSkwJwYJKoZIhvcNAQkBFhpqb2huX3dpbGtpbnNvbkBj b21jYXN0Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAPdXgqkcMe0fiCnYO/1R HWRjXLw2qvJ5Uy6xoItiAZXgP4JO8uhl5+A7FqBnseUq0hj84CsujF1tct3q97Y9VuzdClmY80Kj r9JzTJLXZpwSDh81lS/GEhz+fkp0/B33/QuaoHPhYqR0zK3fBt+fB7zZXw+A1YArxA5Vkb+3qNRx zQF/e6ucvs5KBCDjRDDbJPHiAM1gdparZqPUHCcDYMR4MQXOnjyHSZ99oYwI1ZwZoWjukfBneCmV zOScLxR5v/D6uQG4BbYcLMIgWiV5uybUs0+V0VXyoBj5rPmbq6PeY15p/Dl3Wd3o81zjZahvZA/H EwrG/PR7M2rNeon+DlECAwEAAaNkMGIwKwYFK2UBBAEEIjAgAgEAMBswGQIBBAQURGhMR2NNNFZq dlY3WnpNbUQ2VFkwJQYDVR0RBB4wHIEaam9obl93aWxraW5zb25AY29tY2FzdC5uZXQwDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAXCUWNjJNVnkFOz25fOQ6NDqTDoaZxxwK8RT/l9JdM EmBmQpgf+Gm4yUjLBC1memO+N4F0iy/qN/gQ7WBLLlshmjf7BZ+KM+YJbG68UKF+gBC4Vr0FM3bS xIblYNCS8AIwVwaiBi7ql3WAmka+JflmyHyxH0lyORGPHG1HJzCLyzCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDDC4sMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MDMxNzAxMjgwM1owIwYJKoZIhvcNAQkEMRYEFJxk 5teupMgpd1/lhF7I16daHxlNMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMLiwwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDC4sMA0GCSqGSIb3DQEBAQUABIIBAA0h XcWJj5pVkCKK/PfMmHWECtjrdk2r1TUbEXNAEU+nVS9078qIN/GGDfJtVJSrOiu+4TlIN7OJn6AN 8nxmm+drY4yzrayI3TErB8mm07i4o74GuXjFF//34riwP4nNCKf5Ec+njV2dZzD2Ko8XdVM/ir+z PS/K0BeI4agtgOHUqjF3FQEVj/g9hBHpbMYc94WgYFvdcSnDahhUxiV+P5fu9ILRR7fIibl91s/t qIhxN/KfsuaE/eDTDjmavmAr9/m5izIOsqEDXHz5Mo6qDH8tpmF93IKiXeOi4yu0i92R4dSYYBSL xXHXN9lmThMYhf/YK23IlRc1DSSHF2rUzOgAAAAAAAA= --Apple-Mail-7--428303214-- --===============0425984952== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg --===============0425984952==-- From cfrg-bounces@ietf.org Wed Mar 16 20:49:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24996 for ; Wed, 16 Mar 2005 20:49:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBkD5-0001ss-He for cfrg-web-archive@ietf.org; Wed, 16 Mar 2005 20:54:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBk8I-0005BE-HV; Wed, 16 Mar 2005 20:49:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBk8G-0005B8-Tm for cfrg@megatron.ietf.org; Wed, 16 Mar 2005 20:49:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24969 for ; Wed, 16 Mar 2005 20:49:03 -0500 (EST) Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBkCQ-0001sN-1m for cfrg@ietf.org; Wed, 16 Mar 2005 20:53:22 -0500 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id j2H1n2DB016872; Wed, 16 Mar 2005 20:49:02 -0500 (EST) Received: from [18.101.0.226] ([18.101.0.226]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.12.4/8.12.4) with ESMTP id j2H1ms0a023173 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 16 Mar 2005 20:48:55 -0500 (EST) In-Reply-To: <198A730C2044DE4A96749D13E167AD3703825A@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3703825A@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: From: Ken Raeburn Subject: Re: [Cfrg] Interim MAC function Date: Wed, 16 Mar 2005 17:54:35 -0500 To: "Hallam-Baker, Phillip" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: cfrg@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit On Mar 16, 2005, at 16:29, Hallam-Baker, Phillip wrote: > What I came up with was the MASH digest, (MAC and SHA) as follows: > > MASH (m) = HMAC (m, (SHA (m)) Seems like it does make it a bit more challenging; even if you find m and m' colliding under plain SHA, in this case you've got two different sets of internal state you'd have to produce collisions for with one pair of messages, one starting with nothing, and one starting with SHA(m) XOR 0x3636.... Without knowing how the current collision-finding algorithm works, I couldn't begin to guess how much harder that makes it. (Well, other approaches might be possible, but that's the obvious one building on a simple break of SHA.) I was under the impression that a lot of the strength of HMAC came from the secrecy of the key, in combination with the double-hash, but maybe I'm wrong. Haven't actually looked at the papers. > I am not convinced that I want to go to SHA-256 until the > cryptographers > have given it some serious attention. At the moment everyone appears > to be > too busy stomping on the little pieces of SHA-1 to do that. They're not that little yet, there's still more stomping to be done. :-) > I would much > rather hear a paper giving a credible estimate of the strength of > SHA-256 > than yet another paper arguing whether SHA-1 is a really, really bad > idea or > a really, really, really bad idea. I'd be interested in hearing the opinions specifically of the team that's been breaking all our other hash functions.... Ken _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Wed Mar 16 21:19:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27356 for ; Wed, 16 Mar 2005 21:19:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBkg5-0003OF-OE for cfrg-web-archive@ietf.org; Wed, 16 Mar 2005 21:24:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBka8-0005ZW-S6; Wed, 16 Mar 2005 21:17:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBka7-0005WK-7q; Wed, 16 Mar 2005 21:17:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27240; Wed, 16 Mar 2005 21:17:48 -0500 (EST) Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBkeE-0003M4-0F; Wed, 16 Mar 2005 21:22:08 -0500 Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id j2H2HYLS027956; Wed, 16 Mar 2005 18:17:45 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 16 Mar 2005 18:17:34 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3703825F@MOU1WNEXMB04.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" To: "'Daniel Brown'" , David Wagner Subject: RE: [Cfrg] Interim MAC function Date: Wed, 16 Mar 2005 18:17:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: cfrg@ietf.org, cfrg-bounces@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 > From: cfrg-bounces@ietf.org [mailto:cfrg-bounces@ietf.org] On > Behalf Of Daniel Brown > Because for long messages, the HMAC key is computed as > SHA-1(m), is that > you what you're referring to? Maybe the original intention > was to modify > HMAC to expand out the key the somehow. Anyway, I agree with > you that > MASH - with a compacted key - is no more secure that SHA1 as > a HASH, for > the reason above. The precise proposal is to use MASH (m) = HMAC (m, (SHA (m)) Where HMAC (m, k) is the HMAC of message m with key k. So the problem is to find HMAC (m1, (SHA (m1)) = HMAC (m2, (SHA (m2)) If we find SHA (m1) = SHA (m2) the attacker still has to satisfy: HMAC (m1, k) = HMAC (m2, k) Which implies that H(K XOR opad, H(K XOR ipad, m1)) = H(K XOR opad, H(K XOR ipad, m2)) It may be possible to find such a condition but I certainly do not believe that this follows as a direct result of SHA (m1) = SHA (m2) _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Wed Mar 16 21:31:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28142 for ; Wed, 16 Mar 2005 21:31:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBkrS-0003ub-0l for cfrg-web-archive@ietf.org; Wed, 16 Mar 2005 21:35:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBkk1-0000Ey-UX; Wed, 16 Mar 2005 21:28:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBkjz-0000Ee-KO for cfrg@megatron.ietf.org; Wed, 16 Mar 2005 21:28:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27918 for ; Wed, 16 Mar 2005 21:28:01 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.196]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBko6-0003kS-0I for cfrg@ietf.org; Wed, 16 Mar 2005 21:32:21 -0500 Received: by wproxy.gmail.com with SMTP id 70so2662463wra for ; Wed, 16 Mar 2005 18:27:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=nkiapu9ZJrLjCFPJ5ksGnfI5ZBHF2PYZu7711ExJ1AIqGkUdZ9pVfZVWum/xINvs7Vef2CabG7F5xIxEItgKkrPDT/VpF4YFzrxnGkKJN7bx+L4UopsuJrb5mNcTCEBHhYC9mYVsNkWYqQ/QSrdjaewqVpK5ixx+Eg0LHk+Kr5M= Received: by 10.54.18.29 with SMTP id 29mr2689688wrr; Wed, 16 Mar 2005 18:27:51 -0800 (PST) Received: by 10.54.35.54 with HTTP; Wed, 16 Mar 2005 18:27:51 -0800 (PST) Message-ID: <5e01c29a05031618277ec866ab@mail.gmail.com> Date: Thu, 17 Mar 2005 13:27:51 +1100 From: Michael Silk To: "Hallam-Baker, Phillip" Subject: Re: [Cfrg] Interim MAC function In-Reply-To: <198A730C2044DE4A96749D13E167AD3703825F@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <198A730C2044DE4A96749D13E167AD3703825F@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: Daniel Brown , cfrg@ietf.org, cfrg-bounces@ietf.org, David Wagner X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: michaelslists_at_gmail.com@ietf.org List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit But now all you have is a HMAC with a key that the attacker knows. You've just broken the purpose of HMAC - secret-keyed hashing. Have I missed something obvious here? It seems that this clarified proposal is worse then normal HMAC. -- Michael On Wed, 16 Mar 2005 18:17:31 -0800, Hallam-Baker, Phillip wrote: > > > From: cfrg-bounces@ietf.org [mailto:cfrg-bounces@ietf.org] On > > Behalf Of Daniel Brown > > > Because for long messages, the HMAC key is computed as > > SHA-1(m), is that > > you what you're referring to? Maybe the original intention > > was to modify > > HMAC to expand out the key the somehow. Anyway, I agree with > > you that > > MASH - with a compacted key - is no more secure that SHA1 as > > a HASH, for > > the reason above. > > The precise proposal is to use > > MASH (m) = HMAC (m, (SHA (m)) > > Where HMAC (m, k) is the HMAC of message m with key k. > > So the problem is to find > > HMAC (m1, (SHA (m1)) = HMAC (m2, (SHA (m2)) > > If we find SHA (m1) = SHA (m2) the attacker still has to satisfy: > > HMAC (m1, k) = HMAC (m2, k) > > Which implies that > > H(K XOR opad, H(K XOR ipad, m1)) = H(K XOR opad, H(K XOR ipad, m2)) > > It may be possible to find such a condition but I certainly do not believe > that this follows as a direct result of SHA (m1) = SHA (m2) > > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg > -- Please adjust the reply-to address. _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Wed Mar 16 21:31:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28193 for ; Wed, 16 Mar 2005 21:31:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBkrx-0003vR-8f for cfrg-web-archive@ietf.org; Wed, 16 Mar 2005 21:36:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBklK-0000QI-JM; Wed, 16 Mar 2005 21:29:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBklI-0000QA-T4 for cfrg@megatron.ietf.org; Wed, 16 Mar 2005 21:29:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28010 for ; Wed, 16 Mar 2005 21:29:22 -0500 (EST) Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBkpS-0003s2-BT for cfrg@ietf.org; Wed, 16 Mar 2005 21:33:42 -0500 Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id j2H2TN9V028521 for ; Wed, 16 Mar 2005 18:29:23 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 16 Mar 2005 18:29:23 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD37038260@MOU1WNEXMB04.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" To: cfrg@ietf.org Subject: Sorry, that's a digest, not a MAC RE: [Cfrg] Interim MAC function Date: Wed, 16 Mar 2005 18:29:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Sorry for the confusion, I was proposing a digest function, not a MAC. This is what comes of not proofreading the subject line. > -----Original Message----- > From: cfrg-bounces@ietf.org [mailto:cfrg-bounces@ietf.org] On > Behalf Of Hallam-Baker, Phillip > Sent: Wednesday, March 16, 2005 9:18 PM > To: 'Daniel Brown'; David Wagner > Cc: cfrg@ietf.org; cfrg-bounces@ietf.org > Subject: RE: [Cfrg] Interim MAC function > > > > > From: cfrg-bounces@ietf.org [mailto:cfrg-bounces@ietf.org] On > > Behalf Of Daniel Brown > > > Because for long messages, the HMAC key is computed as > > SHA-1(m), is that > > you what you're referring to? Maybe the original intention > > was to modify > > HMAC to expand out the key the somehow. Anyway, I agree with > > you that > > MASH - with a compacted key - is no more secure that SHA1 as > > a HASH, for > > the reason above. > > The precise proposal is to use > > MASH (m) = HMAC (m, (SHA (m)) > > Where HMAC (m, k) is the HMAC of message m with key k. > > So the problem is to find > > HMAC (m1, (SHA (m1)) = HMAC (m2, (SHA (m2)) > > If we find SHA (m1) = SHA (m2) the attacker still has to satisfy: > > HMAC (m1, k) = HMAC (m2, k) > > Which implies that > > H(K XOR opad, H(K XOR ipad, m1)) = H(K XOR opad, H(K XOR ipad, m2)) > > > It may be possible to find such a condition but I certainly > do not believe that this follows as a direct result of SHA > (m1) = SHA (m2) > > > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Thu Mar 17 01:46:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20384 for ; Thu, 17 Mar 2005 01:46:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBoq9-0006JP-Dp for cfrg-web-archive@ietf.org; Thu, 17 Mar 2005 01:50:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBokk-0001k5-Sf; Thu, 17 Mar 2005 01:45:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBokh-0001jX-JH for cfrg@megatron.ietf.org; Thu, 17 Mar 2005 01:45:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20275 for ; Thu, 17 Mar 2005 01:45:02 -0500 (EST) Received: from abraham.cs.berkeley.edu ([128.32.37.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBoot-0006Hq-6t for cfrg@ietf.org; Thu, 17 Mar 2005 01:49:23 -0500 Received: from news by abraham.cs.berkeley.edu with local (Exim 4.43) id 1DBojL-0001H8-Qz for cfrg@ietf.org; Wed, 16 Mar 2005 22:43:39 -0800 To: cfrg@ietf.org Path: not-for-mail From: daw@taverner.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ietf-cfrg Subject: Re: [Cfrg] Interim MAC function Date: Thu, 17 Mar 2005 06:43:39 +0000 (UTC) Organization: University of California, Berkeley Lines: 7 Distribution: isaac Message-ID: References: <198A730C2044DE4A96749D13E167AD3703825A@MOU1WNEXMB04.vcorp.ad.vrsn.com> NNTP-Posting-Host: taverner.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1111041819 3653 128.32.168.222 (17 Mar 2005 06:43:39 GMT) X-Complaints-To: usenet@abraham.cs.berkeley.edu NNTP-Posting-Date: Thu, 17 Mar 2005 06:43:39 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: daw@taverner.cs.berkeley.edu (David Wagner) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Wagner List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 I want to retract my comments. I misunderstood the proposal (I read too quickly, I guess), and my remarks were totally bogus. I apologize. I have no idea whether MASH is any better than SHA1, but I don't have any reason to think MASH is broken or is worse than SHA1. Again, my apologies for my egregious error. _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Thu Mar 17 03:45:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24884 for ; Thu, 17 Mar 2005 03:45:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBqhf-00038c-Ij for cfrg-web-archive@ietf.org; Thu, 17 Mar 2005 03:50:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBqWg-0001Fa-BL; Thu, 17 Mar 2005 03:38:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBqWd-0001FU-BY for cfrg@megatron.ietf.org; Thu, 17 Mar 2005 03:38:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23986 for ; Thu, 17 Mar 2005 03:38:37 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.196]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBqap-0002tu-0F for cfrg@ietf.org; Thu, 17 Mar 2005 03:43:00 -0500 Received: by wproxy.gmail.com with SMTP id 70so2722534wra for ; Thu, 17 Mar 2005 00:38:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=BrUXQpK6ru/XAbmJBKw1hDvxWZ9O9ntFIQwsCLzUET1fqzJHxoxw6KbLah9e9/mkPJ71/6bsbRO6Yji9gqa69Kq4ZhcuejS+RpHim0gUnsEdsFIvUoIFoLmhvqY2vAbed8s0+FRugcJ1RVNlP5ExAQ894lVcr6s0BBQJmzXvxVM= Received: by 10.54.18.29 with SMTP id 29mr2891171wrr; Thu, 17 Mar 2005 00:38:29 -0800 (PST) Received: by 10.54.35.54 with HTTP; Thu, 17 Mar 2005 00:38:29 -0800 (PST) Message-ID: <5e01c29a05031700386c3d9ed2@mail.gmail.com> Date: Thu, 17 Mar 2005 00:38:29 -0800 From: Michael Silk To: "Hallam-Baker, Phillip" Subject: Re: [Cfrg] Interim MAC function In-Reply-To: <198A730C2044DE4A96749D13E167AD3703825F@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <198A730C2044DE4A96749D13E167AD3703825F@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: cfrg@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: michaelslists@gmail.com List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit "Hallam-Baker, Phillip" Said: > Which implies that > > H(K XOR opad, H(K XOR ipad, m1)) = H(K XOR opad, H(K XOR ipad, m2)) > > It may be possible to find such a condition but I certainly do not believe > that this follows as a direct result of SHA (m1) = SHA (m2) Have you read Kaminsky's note about HMAC's resistance to the attack (http://eprint.iacr.org/2004/357)? Re your previous comment to make those two operations collide all we need to do is find a collision for H(K XOR ipad, m2) (where "," is append). (Ps, I assume "H" here is "SHA" and not another HMAC algo or something). If you know the K (which we do under your proposal) we can calculate IV = H(K XOR ipad) (padding it to meet block requirements if required) and then calculate our collision for "M" (m1 & m2) based on that IV. This IS as a direct result from the research and findings (i.e collisions from ANY IV). -- Michael On Wed, 16 Mar 2005 18:17:31 -0800, Hallam-Baker, Phillip wrote: > > > From: cfrg-bounces@ietf.org [mailto:cfrg-bounces@ietf.org] On > > Behalf Of Daniel Brown > > > Because for long messages, the HMAC key is computed as > > SHA-1(m), is that > > you what you're referring to? Maybe the original intention > > was to modify > > HMAC to expand out the key the somehow. Anyway, I agree with > > you that > > MASH - with a compacted key - is no more secure that SHA1 as > > a HASH, for > > the reason above. > > The precise proposal is to use > > MASH (m) = HMAC (m, (SHA (m)) > > Where HMAC (m, k) is the HMAC of message m with key k. > > So the problem is to find > > HMAC (m1, (SHA (m1)) = HMAC (m2, (SHA (m2)) > > If we find SHA (m1) = SHA (m2) the attacker still has to satisfy: > > HMAC (m1, k) = HMAC (m2, k) > > Which implies that > > H(K XOR opad, H(K XOR ipad, m1)) = H(K XOR opad, H(K XOR ipad, m2)) > > It may be possible to find such a condition but I certainly do not believe > that this follows as a direct result of SHA (m1) = SHA (m2) > > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Thu Mar 17 04:28:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29909 for ; Thu, 17 Mar 2005 04:28:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBrMt-0005Pu-FQ for cfrg-web-archive@ietf.org; Thu, 17 Mar 2005 04:32:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBrHs-0002rv-9U; Thu, 17 Mar 2005 04:27:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBrHc-0002qu-Ik for cfrg@megatron.ietf.org; Thu, 17 Mar 2005 04:27:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29803 for ; Thu, 17 Mar 2005 04:27:10 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.195]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBrLo-0005OX-Ql for cfrg@ietf.org; Thu, 17 Mar 2005 04:31:34 -0500 Received: by wproxy.gmail.com with SMTP id 70so2731344wra for ; Thu, 17 Mar 2005 01:27:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=BYPEkQYwMn8V09nFn6vODbdbfZweo+ji1jON9sPAAk3qjJ2rq3i76k7I4U8pqyYavovzRE3LB5SL/aa7spy6PWhBbszaF2iQ8orqEd/H4dtuK1ZOg3iU6N9b6T+xuuENlilWwJmwibMTcBqt5A3DA9Zhsiv8ubQT6LSCunW+7tU= Received: by 10.54.76.10 with SMTP id y10mr358502wra; Thu, 17 Mar 2005 01:27:02 -0800 (PST) Received: by 10.54.35.54 with HTTP; Thu, 17 Mar 2005 01:27:02 -0800 (PST) Message-ID: <5e01c29a050317012748c9aa45@mail.gmail.com> Date: Thu, 17 Mar 2005 01:27:02 -0800 From: Michael Silk To: "Hallam-Baker, Phillip" Subject: Re: [Cfrg] Interim MAC function In-Reply-To: <5e01c29a05031700386c3d9ed2@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <198A730C2044DE4A96749D13E167AD3703825F@MOU1WNEXMB04.vcorp.ad.vrsn.com> <5e01c29a05031700386c3d9ed2@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: cfrg@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: michaelslists@gmail.com List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Oh, but I guess in your proposal the key (K) is some function involving M (sha(m)), so you really can't calculate the inner collision. I guess I will retract my object on that note too, then :) -- Michael On Thu, 17 Mar 2005 00:38:29 -0800, Michael Silk wrote: > "Hallam-Baker, Phillip" Said: > > Which implies that > > > > H(K XOR opad, H(K XOR ipad, m1)) = H(K XOR opad, H(K XOR ipad, m2)) > > > > It may be possible to find such a condition but I certainly do not believe > > that this follows as a direct result of SHA (m1) = SHA (m2) > > Have you read Kaminsky's note about HMAC's resistance to the attack > (http://eprint.iacr.org/2004/357)? > > Re your previous comment to make those two operations collide all we > need to do is find a collision for H(K XOR ipad, m2) (where "," is > append). (Ps, I assume "H" here is "SHA" and not another HMAC algo or > something). > > If you know the K (which we do under your proposal) we can calculate > IV = H(K XOR ipad) (padding it to meet block requirements if required) > and then calculate our collision for "M" (m1 & m2) based on that IV. > > This IS as a direct result from the research and findings (i.e > collisions from ANY IV). > > -- Michael > > On Wed, 16 Mar 2005 18:17:31 -0800, Hallam-Baker, Phillip > wrote: > > > > > From: cfrg-bounces@ietf.org [mailto:cfrg-bounces@ietf.org] On > > > Behalf Of Daniel Brown > > > > > Because for long messages, the HMAC key is computed as > > > SHA-1(m), is that > > > you what you're referring to? Maybe the original intention > > > was to modify > > > HMAC to expand out the key the somehow. Anyway, I agree with > > > you that > > > MASH - with a compacted key - is no more secure that SHA1 as > > > a HASH, for > > > the reason above. > > > > The precise proposal is to use > > > > MASH (m) = HMAC (m, (SHA (m)) > > > > Where HMAC (m, k) is the HMAC of message m with key k. > > > > So the problem is to find > > > > HMAC (m1, (SHA (m1)) = HMAC (m2, (SHA (m2)) > > > > If we find SHA (m1) = SHA (m2) the attacker still has to satisfy: > > > > HMAC (m1, k) = HMAC (m2, k) > > > > Which implies that > > > > H(K XOR opad, H(K XOR ipad, m1)) = H(K XOR opad, H(K XOR ipad, m2)) > > > > It may be possible to find such a condition but I certainly do not believe > > that this follows as a direct result of SHA (m1) = SHA (m2) > > > > > > _______________________________________________ > > Cfrg mailing list > > Cfrg@ietf.org > > https://www1.ietf.org/mailman/listinfo/cfrg > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Thu Mar 17 09:35:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03064 for ; Thu, 17 Mar 2005 09:35:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBwAh-0001vn-MS for cfrg-web-archive@ietf.org; Thu, 17 Mar 2005 09:40:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBvzt-0003Fa-Gk; Thu, 17 Mar 2005 09:29:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBvzr-0003FV-4F for cfrg@megatron.ietf.org; Thu, 17 Mar 2005 09:29:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02274 for ; Thu, 17 Mar 2005 09:29:08 -0500 (EST) Received: from ns.ca.certicom.com ([66.48.18.197] helo=mail.ca.certicom.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DBw45-0001hJ-3Z for cfrg@ietf.org; Thu, 17 Mar 2005 09:33:34 -0500 Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 65BD410078; Thu, 17 Mar 2005 09:28:58 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28286-26; Thu, 17 Mar 2005 09:28:43 -0500 (EST) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 1D4A010089; Thu, 17 Mar 2005 09:28:43 -0500 (EST) In-Reply-To: <198A730C2044DE4A96749D13E167AD3703825F@MOU1WNEXMB04.vcorp.ad.vrsn.com> To: "Hallam-Baker, Phillip" Subject: RE: [Cfrg] Interim MAC function MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Daniel Brown Date: Thu, 17 Mar 2005 09:19:29 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 03/17/2005 09:19:31 AM, Serialize complete at 03/17/2005 09:19:31 AM Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: cfrg@ietf.org, David Wagner X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab "Hallam-Baker, Phillip" wrote on 03/16/2005 09:17:31 PM: > > > From: cfrg-bounces@ietf.org [mailto:cfrg-bounces@ietf.org] On > > Behalf Of Daniel Brown > > > Because for long messages, the HMAC key is computed as > > SHA-1(m), is that > > you what you're referring to? Maybe the original intention > > was to modify > > HMAC to expand out the key the somehow. Anyway, I agree with > > you that > > MASH - with a compacted key - is no more secure that SHA1 as > > a HASH, for > > the reason above. > > The precise proposal is to use > > MASH (m) = HMAC (m, (SHA (m)) > > Where HMAC (m, k) is the HMAC of message m with key k. Ah, I see: it makes a big difference which input is the key. In the notation I'm used to, the first input is taken as the key (perhaps since HMAC begins processing the key before the message?). Anyway, it should have occurred to me to try the other order, sorry I didn't think it through. > > So the problem is to find > > HMAC (m1, (SHA (m1)) = HMAC (m2, (SHA (m2)) > > If we find SHA (m1) = SHA (m2) the attacker still has to satisfy: > > HMAC (m1, k) = HMAC (m2, k) > > Which implies that > > H(K XOR opad, H(K XOR ipad, m1)) = H(K XOR opad, H(K XOR ipad, m2)) > > > It may be possible to find such a condition but I certainly do not believe > that this follows as a direct result of SHA (m1) = SHA (m2) > > For what little it's worth, I agree that MASH is at least as collision-resistant as SHA1: if MASH(m1) = MASH(m2), then one can find m1' and m2' such that SHA1(m1') and SHA(m2'). Would anybody hazard an estimate of how much better, if at all, the security is? (E.g. 3DES is generally estimated to have twice the security level of DES.) _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Thu Mar 17 10:07:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08113 for ; Thu, 17 Mar 2005 10:07:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBwf4-0003hK-Un for cfrg-web-archive@ietf.org; Thu, 17 Mar 2005 10:11:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBwXB-0001qp-SO; Thu, 17 Mar 2005 10:03:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBwXA-0001qk-AS for cfrg@megatron.ietf.org; Thu, 17 Mar 2005 10:03:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07195 for ; Thu, 17 Mar 2005 10:03:33 -0500 (EST) Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBwbP-0003Px-2h for cfrg@ietf.org; Thu, 17 Mar 2005 10:08:00 -0500 Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id j2HF3ND9004726; Thu, 17 Mar 2005 07:03:24 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 17 Mar 2005 07:03:23 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD37038263@MOU1WNEXMB04.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" To: "'michaelslists@gmail.com'" Subject: RE: [Cfrg] Interim MAC function Date: Thu, 17 Mar 2005 07:03:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: cfrg@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 > If you know the K (which we do under your proposal) we can > calculate IV = H(K XOR ipad) (padding it to meet block > requirements if required) and then calculate our collision > for "M" (m1 & m2) based on that IV. But k is a function of m1/m2 (k=sha1(m1)=sha1(m2)) if you change m1 or m2 you change k. _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Thu Mar 17 13:20:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02901 for ; Thu, 17 Mar 2005 13:20:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBzgH-0001mQ-H7 for cfrg-web-archive@ietf.org; Thu, 17 Mar 2005 13:25:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBzYV-0005jK-Rz; Thu, 17 Mar 2005 13:17:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBzYU-0005jF-Ce for cfrg@megatron.ietf.org; Thu, 17 Mar 2005 13:17:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02585 for ; Thu, 17 Mar 2005 13:17:06 -0500 (EST) Received: from mailgw1.technion.ac.il ([132.68.238.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBzcl-0001gM-Id for cfrg@ietf.org; Thu, 17 Mar 2005 13:21:36 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgw1.technion.ac.il (Postfix) with ESMTP id 438EDFF967 for ; Thu, 17 Mar 2005 20:17:06 +0200 (IST) (envelope-from hugo@ee.technion.ac.il) Received: from mailgw1.technion.ac.il ([127.0.0.1]) by localhost (mailgw1.technion.ac.il [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 28007-01-79 for ; Thu, 17 Mar 2005 20:17:06 +0200 (IST) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by mailgw1.technion.ac.il (Postfix) with ESMTP id 2FE5FFF930 for ; Thu, 17 Mar 2005 20:17:06 +0200 (IST) (envelope-from hugo@ee.technion.ac.il) Received: from ee.technion.ac.il (localhost [127.0.0.1]) by ee.technion.ac.il (8.12.10+Sun/8.12.2) with ESMTP id j2HIHS4A028125; Thu, 17 Mar 2005 20:17:28 +0200 (IST) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.12.10+Sun/8.12.2/Submit) with ESMTP id j2HIHNui028119; Thu, 17 Mar 2005 20:17:24 +0200 (IST) Date: Thu, 17 Mar 2005 20:17:23 +0200 (IST) From: Hugo Krawczyk To: "Hallam-Baker, Phillip" Subject: RE: [Cfrg] Interim MAC function In-Reply-To: <198A730C2044DE4A96749D13E167AD37038263@MOU1WNEXMB04.vcorp.ad.vrsn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: AAAAAQAAAAQ= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new at technion.ac.il X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: cfrg@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 It seems that the proposal was MASH(m)=HMAC-SHA1(K=SHA1(m), M=m) (i.e. HMAC-SHA1 with message m and key SHA1(m)) If we ignore the opad/ipad padding of HMAC and the length-encoding padding of SHA1 this becomes something like H(H(m)|H(H(m)|m)) (where | stands for concatenation and H is SHA1 with length padding omitted). Up to some IV replacemnt and assuming m to be a multiple of 512 bits one has that H(H(m)|m) is "close" to H(m|m). In this case we get that MASH(m) can be "approximated" by H(H(m)|H(m|m)). For the latter to be considered collision resistant one needs to assume that finding collisions between two messages m,m' and alsso between m|m and m'|m' is difficult. I would not count on it. But then again this is only an approximation. Hugo _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Thu Mar 17 14:06:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07501 for ; Thu, 17 Mar 2005 14:06:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC0Oq-00031s-Pr for cfrg-web-archive@ietf.org; Thu, 17 Mar 2005 14:11:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC0Jp-0000jJ-KC; Thu, 17 Mar 2005 14:06:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC0Jo-0000jE-My for cfrg@megatron.ietf.org; Thu, 17 Mar 2005 14:06:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07478 for ; Thu, 17 Mar 2005 14:06:02 -0500 (EST) Received: from igw2.watson.ibm.com ([129.34.20.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC0O4-000314-Vr for cfrg@ietf.org; Thu, 17 Mar 2005 14:10:31 -0500 Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id j2HJ5qP82470 for ; Thu, 17 Mar 2005 14:05:52 -0500 Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j2HJ5qm72772 for ; Thu, 17 Mar 2005 14:05:52 -0500 Received: from [127.0.0.1] (CRYPT01.watson.ibm.com [9.2.18.142]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j2HJ5pf83912 for ; Thu, 17 Mar 2005 14:05:51 -0500 Message-ID: <4239D50E.2090009@alum.mit.edu> Date: Thu, 17 Mar 2005 14:05:50 -0500 From: Shai Halevi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: cfrg@ietf.org References: <200503171702.j2HH29sV014779@alum-1.mit.edu> In-Reply-To: <200503171702.j2HH29sV014779@alum-1.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Subject: [Cfrg] Who needs collision-resistance, anyway? X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Since at present we are not really sure what construction can we trust to be collision-resistant, it seems to make sense asking whether we can live without fully collision-resistance hash functions. Signatures is one applications where full collision-resistant is *not* needed (in principle). It is well known that one can construct digital signatures from "target collision-resistant" functions, just as easily as from fully collision-resistant functions: Roughly, to sign a message m, the signer chooses a new random key k, computes h=HMAC_k(m), and then uses (say) some variant of RSA-PSS to sign the pair (k,h), and outputs also k as part of the signature. My questions are the following: * Are there signature standards that actually work this way? * Wouldn't it make sense to modify some of the standards along this line? (Yes, I know that modifying standards is always hard, but we would eventually have to replace the hash function anyway, so we might as well take this opportunity to modify also the way it is used.) * Can anyone describe a real-life application where full collision-resistance is really needed? -- Shai _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Thu Mar 17 14:14:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08933 for ; Thu, 17 Mar 2005 14:14:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC0Wg-0003OF-Ui for cfrg-web-archive@ietf.org; Thu, 17 Mar 2005 14:19:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC0RT-0001uF-Ai; Thu, 17 Mar 2005 14:13:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC0RQ-0001r4-SI for cfrg@megatron.ietf.org; Thu, 17 Mar 2005 14:13:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08524 for ; Thu, 17 Mar 2005 14:13:55 -0500 (EST) Received: from ns.ca.certicom.com ([66.48.18.197] helo=mail.ca.certicom.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DC0Vi-0003Ho-6a for cfrg@ietf.org; Thu, 17 Mar 2005 14:18:23 -0500 Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 5AF991008A; Thu, 17 Mar 2005 14:13:46 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29090-16; Thu, 17 Mar 2005 14:13:34 -0500 (EST) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 673DF10079; Thu, 17 Mar 2005 14:13:34 -0500 (EST) In-Reply-To: <4239D50E.2090009@alum.mit.edu> To: Shai Halevi Subject: Re: [Cfrg] Who needs collision-resistance, anyway? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Daniel Brown Date: Thu, 17 Mar 2005 14:04:21 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 03/17/2005 02:04:22 PM, Serialize complete at 03/17/2005 02:04:22 PM Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: cfrg@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Shai Halevi wrote on 03/17/2005 02:05:50 PM: > Since at present we are not really sure what construction can we trust > to be collision-resistant, it seems to make sense asking whether we can > live without fully collision-resistance hash functions. > > Signatures is one applications where full collision-resistant is *not* > needed (in principle). It is well known that one can construct digital > signatures from "target collision-resistant" functions, just as easily > as from fully collision-resistant functions: Roughly, to sign a message > m, the signer chooses a new random key k, computes h=HMAC_k(m), and then > uses (say) some variant of RSA-PSS to sign the pair (k,h), and outputs > also k as part of the signature. > > My questions are the following: > > * Are there signature standards that actually work this way? Yes: PV-signatures in IEEE 1363a, for example. > > * Wouldn't it make sense to modify some of the standards along this > line? (Yes, I know that modifying standards is always hard, but we > would eventually have to replace the hash function anyway, so we might > as well take this opportunity to modify also the way it is used.) > > * Can anyone describe a real-life application where full > collision-resistance is really needed? > > -- Shai > > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Thu Mar 17 15:45:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18560 for ; Thu, 17 Mar 2005 15:45:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC1w3-0005pA-4c for cfrg-web-archive@ietf.org; Thu, 17 Mar 2005 15:49:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC1pD-0006FZ-2z; Thu, 17 Mar 2005 15:42:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC1pB-0006FU-Q0 for cfrg@megatron.ietf.org; Thu, 17 Mar 2005 15:42:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18199 for ; Thu, 17 Mar 2005 15:42:30 -0500 (EST) Received: from mailgw1.technion.ac.il ([132.68.238.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC1tU-0005hl-0n for cfrg@ietf.org; Thu, 17 Mar 2005 15:47:00 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgw1.technion.ac.il (Postfix) with ESMTP id 45DDBFF921 for ; Thu, 17 Mar 2005 22:42:26 +0200 (IST) (envelope-from hugo@ee.technion.ac.il) Received: from mailgw1.technion.ac.il ([127.0.0.1]) by localhost (mailgw1.technion.ac.il [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 29125-01-75 for ; Thu, 17 Mar 2005 22:42:26 +0200 (IST) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by mailgw1.technion.ac.il (Postfix) with ESMTP id 24C49FF8A9 for ; Thu, 17 Mar 2005 22:42:26 +0200 (IST) (envelope-from hugo@ee.technion.ac.il) Received: from ee.technion.ac.il (localhost [127.0.0.1]) by ee.technion.ac.il (8.12.10+Sun/8.12.2) with ESMTP id j2HKgn4A015855 for ; Thu, 17 Mar 2005 22:42:49 +0200 (IST) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.12.10+Sun/8.12.2/Submit) with ESMTP id j2HKgnLH015851 for ; Thu, 17 Mar 2005 22:42:49 +0200 (IST) Date: Thu, 17 Mar 2005 22:42:49 +0200 (IST) From: Hugo Krawczyk To: cfrg@ietf.org Subject: Re: [Cfrg] Who needs collision-resistance, anyway? In-Reply-To: <4239D50E.2090009@alum.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: AAAAAQAAAAQ= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new at technion.ac.il X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 A concrete proposal for randomized hashing in the context of signatures is as follows: Alice sends m to Bob for signing. Bob chooses a random SHA-1 IV r and generates a digest d(m)=SHA1_r(m) (SHA1_r denotes SHA1 with IV=r). Bob computes his signature s on the concatenation of d(m)|r B returns to A the pair (s,r) as his signature on m Here the hash function does not need to be fully collision resistant (but rather what is caled in the literature "target collision resistant" or "one-way hash"). Note that B may find two msgs for which the same pair (s,r) is a valid signature but that's not a problem as long as A cannot find such pair. If at any point two msgs m,m' with the same valid signature arise then the blame is on B (in which case B should be considered the legal signer of both msgs). Hugo On Thu, 17 Mar 2005, Shai Halevi wrote: > Since at present we are not really sure what construction can we trust > to be collision-resistant, it seems to make sense asking whether we can > live without fully collision-resistance hash functions. > > Signatures is one applications where full collision-resistant is *not* > needed (in principle). It is well known that one can construct digital > signatures from "target collision-resistant" functions, just as easily > as from fully collision-resistant functions: Roughly, to sign a message > m, the signer chooses a new random key k, computes h=HMAC_k(m), and then > uses (say) some variant of RSA-PSS to sign the pair (k,h), and outputs > also k as part of the signature. > > My questions are the following: > > * Are there signature standards that actually work this way? > > * Wouldn't it make sense to modify some of the standards along this > line? (Yes, I know that modifying standards is always hard, but we > would eventually have to replace the hash function anyway, so we might > as well take this opportunity to modify also the way it is used.) > > * Can anyone describe a real-life application where full > collision-resistance is really needed? > > -- Shai > > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Thu Mar 17 17:43:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29350 for ; Thu, 17 Mar 2005 17:43:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC3mI-0000cf-HH for cfrg-web-archive@ietf.org; Thu, 17 Mar 2005 17:47:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC3hG-0003hH-Tx; Thu, 17 Mar 2005 17:42:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC3hF-0003hC-V1 for cfrg@megatron.ietf.org; Thu, 17 Mar 2005 17:42:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29324 for ; Thu, 17 Mar 2005 17:42:26 -0500 (EST) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DC3la-0000cK-1y for cfrg@ietf.org; Thu, 17 Mar 2005 17:46:58 -0500 Received: (qmail 20529 invoked by uid 0); 17 Mar 2005 22:42:17 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (63.148.158.5) by woodstock.binhost.com with SMTP; 17 Mar 2005 22:42:17 -0000 Message-Id: <6.2.0.14.2.20050317173421.065b3b20@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 17 Mar 2005 17:39:13 -0500 To: Hugo Krawczyk , cfrg@ietf.org From: Russ Housley Subject: Re: [Cfrg] Who needs collision-resistance, anyway? In-Reply-To: References: <4239D50E.2090009@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Hugo: Is this the same as the following? h = SHA1 ( salt || msg ) s = Sign ( h ) salt is a random value, and it is a full block (512 bits in the case of SHA1) msg is the message to be signed The signer needs to pass salt, msg, and s to the recipient for them to validate the signature. In this way, there is not change to SHA1 itself, but the random salt leads to the randomization of the IV prior to the processing of the msg. Russ At 03:42 PM 3/17/2005, Hugo Krawczyk wrote: >A concrete proposal for randomized hashing in the context of signatures is >as follows: > >Alice sends m to Bob for signing. >Bob chooses a random SHA-1 IV r and generates a digest d(m)=SHA1_r(m) >(SHA1_r denotes SHA1 with IV=r). >Bob computes his signature s on the concatenation of d(m)|r >B returns to A the pair (s,r) as his signature on m > >Here the hash function does not need to be fully collision resistant (but >rather what is caled in the literature "target collision resistant" or >"one-way hash"). >Note that B may find two msgs for which the same pair (s,r) is a valid >signature but that's not a problem as long as A cannot find such pair. >If at any point two msgs m,m' with the same valid signature arise then the >blame is on B (in which case B should be considered the legal signer of >both msgs). > >Hugo > > >On Thu, 17 Mar 2005, Shai Halevi wrote: > > > Since at present we are not really sure what construction can we trust > > to be collision-resistant, it seems to make sense asking whether we can > > live without fully collision-resistance hash functions. > > > > Signatures is one applications where full collision-resistant is *not* > > needed (in principle). It is well known that one can construct digital > > signatures from "target collision-resistant" functions, just as easily > > as from fully collision-resistant functions: Roughly, to sign a message > > m, the signer chooses a new random key k, computes h=HMAC_k(m), and then > > uses (say) some variant of RSA-PSS to sign the pair (k,h), and outputs > > also k as part of the signature. > > > > My questions are the following: > > > > * Are there signature standards that actually work this way? > > > > * Wouldn't it make sense to modify some of the standards along this > > line? (Yes, I know that modifying standards is always hard, but we > > would eventually have to replace the hash function anyway, so we might > > as well take this opportunity to modify also the way it is used.) > > > > * Can anyone describe a real-life application where full > > collision-resistance is really needed? > > > > -- Shai > > > > > > _______________________________________________ > > Cfrg mailing list > > Cfrg@ietf.org > > https://www1.ietf.org/mailman/listinfo/cfrg > > > > > >_______________________________________________ >Cfrg mailing list >Cfrg@ietf.org >https://www1.ietf.org/mailman/listinfo/cfrg _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Thu Mar 17 18:09:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01536 for ; Thu, 17 Mar 2005 18:09:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC4BK-00019w-Fl for cfrg-web-archive@ietf.org; Thu, 17 Mar 2005 18:13:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC45D-00088J-Lm; Thu, 17 Mar 2005 18:07:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC45C-00088E-FX for cfrg@megatron.ietf.org; Thu, 17 Mar 2005 18:07:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01297 for ; Thu, 17 Mar 2005 18:07:10 -0500 (EST) Received: from igw2.watson.ibm.com ([129.34.20.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC49U-000175-FC for cfrg@ietf.org; Thu, 17 Mar 2005 18:11:42 -0500 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id j2HN71P123318 for ; Thu, 17 Mar 2005 18:07:02 -0500 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j2HN71a63614 for ; Thu, 17 Mar 2005 18:07:01 -0500 Received: from mgsmtp00 (mgsmtp00.watson.ibm.com [9.2.40.58]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j2HN70G53018 for ; Thu, 17 Mar 2005 18:07:00 -0500 Received: from wasa.watson.ibm.com ([9.2.16.192]) by mgsmtp00.watson.ibm.com ID IMFd1111099760.1; Thu, 17 Mar 2005 17:49:20 -0400 Received: (from csjutla@localhost) by wasa.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) id j2HMpuG36334; Thu, 17 Mar 2005 17:51:56 -0500 From: csjutla MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 17 Mar 2005 17:51:55 -0500 (EST) To: Russ Housley Subject: Re: [Cfrg] Who needs collision-resistance, anyway? In-Reply-To: <6.2.0.14.2.20050317173421.065b3b20@mail.binhost.com> References: <4239D50E.2090009@alum.mit.edu> <6.2.0.14.2.20050317173421.065b3b20@mail.binhost.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <16954.2537.842667.790997@wasa.watson.ibm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Cc: cfrg@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit You forgot to sign the salt. Russ Housley writes: > Hugo: > > Is this the same as the following? > > h = SHA1 ( salt || msg ) > s = Sign ( h ) > > salt is a random value, and it is a full block > (512 bits in the case of SHA1) > > msg is the message to be signed > > The signer needs to pass salt, msg, and s to the recipient for them to > validate the signature. In this way, there is not change to SHA1 itself, > but the random salt leads to the randomization of the IV prior to the > processing of the msg. > > Russ > > > At 03:42 PM 3/17/2005, Hugo Krawczyk wrote: > >A concrete proposal for randomized hashing in the context of signatures is > >as follows: > > > >Alice sends m to Bob for signing. > >Bob chooses a random SHA-1 IV r and generates a digest d(m)=SHA1_r(m) > >(SHA1_r denotes SHA1 with IV=r). > >Bob computes his signature s on the concatenation of d(m)|r > >B returns to A the pair (s,r) as his signature on m > > > >Here the hash function does not need to be fully collision resistant (but > >rather what is caled in the literature "target collision resistant" or > >"one-way hash"). > >Note that B may find two msgs for which the same pair (s,r) is a valid > >signature but that's not a problem as long as A cannot find such pair. > >If at any point two msgs m,m' with the same valid signature arise then the > >blame is on B (in which case B should be considered the legal signer of > >both msgs). > > > >Hugo > > > > > >On Thu, 17 Mar 2005, Shai Halevi wrote: > > > > > Since at present we are not really sure what construction can we trust > > > to be collision-resistant, it seems to make sense asking whether we can > > > live without fully collision-resistance hash functions. > > > > > > Signatures is one applications where full collision-resistant is *not* > > > needed (in principle). It is well known that one can construct digital > > > signatures from "target collision-resistant" functions, just as easily > > > as from fully collision-resistant functions: Roughly, to sign a message > > > m, the signer chooses a new random key k, computes h=HMAC_k(m), and then > > > uses (say) some variant of RSA-PSS to sign the pair (k,h), and outputs > > > also k as part of the signature. > > > > > > My questions are the following: > > > > > > * Are there signature standards that actually work this way? > > > > > > * Wouldn't it make sense to modify some of the standards along this > > > line? (Yes, I know that modifying standards is always hard, but we > > > would eventually have to replace the hash function anyway, so we might > > > as well take this opportunity to modify also the way it is used.) > > > > > > * Can anyone describe a real-life application where full > > > collision-resistance is really needed? > > > > > > -- Shai > > > > > > > > > _______________________________________________ > > > Cfrg mailing list > > > Cfrg@ietf.org > > > https://www1.ietf.org/mailman/listinfo/cfrg > > > > > > > > > > >_______________________________________________ > >Cfrg mailing list > >Cfrg@ietf.org > >https://www1.ietf.org/mailman/listinfo/cfrg > > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Thu Mar 17 18:11:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01793 for ; Thu, 17 Mar 2005 18:11:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC4DU-0001Cy-I9 for cfrg-web-archive@ietf.org; Thu, 17 Mar 2005 18:15:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC46k-00006l-AG; Thu, 17 Mar 2005 18:08:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC46j-00006g-6F for cfrg@megatron.ietf.org; Thu, 17 Mar 2005 18:08:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01492 for ; Thu, 17 Mar 2005 18:08:45 -0500 (EST) Received: from mailgw4.technion.ac.il ([132.68.238.37]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC4B3-00019Z-1L for cfrg@ietf.org; Thu, 17 Mar 2005 18:13:17 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgw4.technion.ac.il (Postfix) with ESMTP id 3021DF78F5 for ; Fri, 18 Mar 2005 01:02:54 +0200 (IST) (envelope-from hugo@ee.technion.ac.il) Received: from mailgw4.technion.ac.il ([127.0.0.1]) by localhost (mailgw4.technion.ac.il [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 29824-01-51 for ; Fri, 18 Mar 2005 01:02:54 +0200 (IST) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by mailgw4.technion.ac.il (Postfix) with ESMTP id 9286AF78C0 for ; Fri, 18 Mar 2005 01:02:53 +0200 (IST) (envelope-from hugo@ee.technion.ac.il) Received: from ee.technion.ac.il (localhost [127.0.0.1]) by ee.technion.ac.il (8.12.10+Sun/8.12.2) with ESMTP id j2HN934A003132; Fri, 18 Mar 2005 01:09:03 +0200 (IST) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.12.10+Sun/8.12.2/Submit) with ESMTP id j2HN920S003127; Fri, 18 Mar 2005 01:09:02 +0200 (IST) Date: Fri, 18 Mar 2005 01:09:02 +0200 (IST) From: Hugo Krawczyk To: Russ Housley Subject: Re: [Cfrg] Who needs collision-resistance, anyway? In-Reply-To: <6.2.0.14.2.20050317173421.065b3b20@mail.binhost.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: AAAAAQAAAAQ= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new at technion.ac.il X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: cfrg@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Yes. the SHA1(salt||msg) is equivalent to SHAI_r as I described and (as in hmac) it avoids the need to "program" the IV in SHA1. Note that the length of salt may be significant since it needs to be transmitted with (and/or inside) the signature; so since we are talking about "practcal heuristics" anyway we could make salt to be 160 random bits padded with 0s. Or, at the expense of an extra SHA1 calculation, one can implement the hash as HMAC with the 160-bit "salt" as the key (as said this is somewhat more expensive but can use the same interface as hmac). Hugo On Thu, 17 Mar 2005, Russ Housley wrote: > Hugo: > > Is this the same as the following? > > h = SHA1 ( salt || msg ) > s = Sign ( h ) > > salt is a random value, and it is a full block > (512 bits in the case of SHA1) > > msg is the message to be signed > > The signer needs to pass salt, msg, and s to the recipient for them to > validate the signature.In this way, there is not change to SHA1 itself, > but the random salt leads to the randomization of the IV prior to the > processing of the msg. > > Russ > > > At 03:42 PM 3/17/2005, Hugo Krawczyk wrote: > >A concrete proposal for randomized hashing in the context of signatures is > >as follows: > > > >Alice sends m to Bob for signing. > >Bob chooses a random SHA-1 IV r and generates a digest d(m)=SHA1_r(m) > >(SHA1_r denotes SHA1 with IV=r). > >Bob computes his signature s on the concatenation of d(m)|r > >B returns to A the pair (s,r) as his signatureon m > > > >Here the hash function does not need to be fully collision resistant (but > >rather what is caled in theliterature "target collision resistant" or > >"one-way hash"). > >Note that B may find two msgs for which the same pair (s,r) is a valid > >signature but that's not a problem as long as A cannot find such pair. > >If at any point two msgs m,m' with the same valid signature arise then the > >blame is on B (in which case B should be considered the legal signer of > >both msgs). > > > >Hugo > > > > > >On Thu, 17 Mar 2005, Shai Halevi wrote: > > > > > Since at present we are not really sure what construction can we trust > > > to be collision-resistant, it seems to make sense asking whether we can > > > live without fully collision-resistance hash functions. > > > > > > Signatures is one applications where full collision-resistant is *not* > > > needed (in principle). It is well known that one can construct digital > > > signatures from "target collision-resistant" functions, just as easily > > > as from fully collision-resistant functions: Roughly, to sign a message > > > m, the signer chooses a new random key k, computes h=HMAC_k(m), and then > > > uses (say) some variant of RSA-PSS to sign the pair (k,h), and outputs > > > also k as part of the signature. > > > > > > My questions are the following: > > > > > > * Are there signature standards that actually work this way? > > > > > > *Wouldn't it make sense to modify some of the standards along this > > > line? (Yes, I know that modifying standards is always hard, but we > > > would eventually have to replace the hash function anyway, so we might > > > as well take this opportunity to modify also the way it is used.) > > > > > > * Can anyone describe a real-life application where full > > > collision-resistance is really needed? > > > > > > -- Shai > > > > > > > > > _______________________________________________ > > > Cfrg mailing list > > > Cfrg@ietf.org > > > https://www1.ietf.org/mailman/listinfo/cfrg > > > > > > > > > > >_______________________________________________ > >Cfrg mailing list > >Cfrg@ietf.org > >https://www1.ietf.org/mailman/listinfo/cfrg > > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Thu Mar 17 18:27:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03425 for ; Thu, 17 Mar 2005 18:27:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC4Tf-0001ZD-3G for cfrg-web-archive@ietf.org; Thu, 17 Mar 2005 18:32:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC4MW-0003gw-NS; Thu, 17 Mar 2005 18:25:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC4MV-0003gr-74 for cfrg@megatron.ietf.org; Thu, 17 Mar 2005 18:25:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03221 for ; Thu, 17 Mar 2005 18:25:03 -0500 (EST) Received: from stoneport.math.uic.edu ([131.193.178.160]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DC4Qo-0001V4-LA for cfrg@ietf.org; Thu, 17 Mar 2005 18:29:35 -0500 Received: (qmail 31397 invoked by uid 1016); 17 Mar 2005 23:25:33 -0000 Date: 17 Mar 2005 23:25:33 -0000 Message-ID: <20050317232533.31396.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: cfrg@ietf.org Subject: Re: [Cfrg] Who needs collision-resistance, anyway? References: <200503171702.j2HH29sV014779@alum-1.mit.edu> <4239D50E.2090009@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Shai Halevi writes: > * Wouldn't it make sense to modify some of the standards along this > line? Why _would_ it make sense? Why should anyone believe that this use of CPU time and bandwidth is more secure than using a larger hash function? Would you really be surprised if the attack techniques are extended to allow some randomness in the input? ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Thu Mar 17 18:51:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05088 for ; Thu, 17 Mar 2005 18:51:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC4qB-00021N-WD for cfrg-web-archive@ietf.org; Thu, 17 Mar 2005 18:55:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC4k9-0007id-OF; Thu, 17 Mar 2005 18:49:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC4k8-0007iY-Ec for cfrg@megatron.ietf.org; Thu, 17 Mar 2005 18:49:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04979 for ; Thu, 17 Mar 2005 18:49:29 -0500 (EST) Received: from mailgw3.technion.ac.il ([132.68.238.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC4oR-0001yd-TL for cfrg@ietf.org; Thu, 17 Mar 2005 18:54:01 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgw3.technion.ac.il (Postfix) with ESMTP id 822EC1676AD for ; Fri, 18 Mar 2005 01:49:17 +0200 (IST) (envelope-from hugo@ee.technion.ac.il) Received: from mailgw3.technion.ac.il ([127.0.0.1]) by localhost (mailgw3.technion.ac.il [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01473-01-3 for ; Fri, 18 Mar 2005 01:49:17 +0200 (IST) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by mailgw3.technion.ac.il (Postfix) with ESMTP id 612FD167680 for ; Fri, 18 Mar 2005 01:49:17 +0200 (IST) (envelope-from hugo@ee.technion.ac.il) Received: from ee.technion.ac.il (localhost [127.0.0.1]) by ee.technion.ac.il (8.12.10+Sun/8.12.2) with ESMTP id j2HNno4A008041; Fri, 18 Mar 2005 01:49:50 +0200 (IST) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.12.10+Sun/8.12.2/Submit) with ESMTP id j2HNnogf008035; Fri, 18 Mar 2005 01:49:50 +0200 (IST) Date: Fri, 18 Mar 2005 01:49:50 +0200 (IST) From: Hugo Krawczyk To: "D. J. Bernstein" Subject: Re: [Cfrg] Who needs collision-resistance, anyway? In-Reply-To: <20050317232533.31396.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: AAAAAQAAAAQ= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new at technion.ac.il X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: cfrg@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 On 17 Mar 2005, D. J. Bernstein wrote: > Shai Halevi writes: > > * Wouldn't it make sense to modify some of the standards along this > > line? > > Why _would_ it make sense? Why should anyone believe that this use of > CPU time and bandwidth is more secure than using a larger hash function? > Wouldyou really be surprised if the attack techniques are extended to > allow some randomness in the input? This is not just "some randomness in the input". The point is about WHO chooses the randomness and in what ORDER. In order to break a signature ALice needs to be able to: (1) choose m (2) receive r from Bob (3) find m' such that H_r(m)=H_r(m') (Note that Alice must choose m before seeing r and Bob chooses r independently from m!) This notion of hashing is DIFFERENT and MUCH WEAKER than collision resistance. This notion is what many books referred to as "second-mage resistance" and it's what Naor-Yung called OWH (One-way hashing) and Bellare-Rogaway call TCR (target collision resistant). Breaking SHA1 in this sense is far harder than finding collisions. Also, designing new functions with TCR as the goal should be significantly easier than designing fully collision resistant functions. Using this approach can also get as closer to proven encoding schemes for signatures such as PSS for RSA or DSS with H(m,r) (instead of H(m)). Hugo > > ---D. J. Bernstein, Associate Professor, Department of Mathematics, > Statistics, and Computer Science, University of Illinois at Chicago > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Thu Mar 17 19:32:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08364 for ; Thu, 17 Mar 2005 19:32:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC5Tf-0002x3-Fo for cfrg-web-archive@ietf.org; Thu, 17 Mar 2005 19:36:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC5NW-00078f-RU; Thu, 17 Mar 2005 19:30:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC5NV-00078Z-9t for cfrg@megatron.ietf.org; Thu, 17 Mar 2005 19:30:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08125 for ; Thu, 17 Mar 2005 19:30:09 -0500 (EST) Received: from stoneport.math.uic.edu ([131.193.178.160]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DC5Rp-0002uI-Hw for cfrg@ietf.org; Thu, 17 Mar 2005 19:34:42 -0500 Received: (qmail 14707 invoked by uid 1016); 18 Mar 2005 00:30:39 -0000 Date: 18 Mar 2005 00:30:39 -0000 Message-ID: <20050318003039.14706.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: cfrg@ietf.org Subject: Re: [Cfrg] Who needs collision-resistance, anyway? References: <20050317232533.31396.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hugo Krawczyk writes: > Breaking SHA1 in this sense is far harder than finding collisions. You'll actually be surprised when the MD5 attack techniques are extended to break randomized MD5-based signatures? You'll be embarrassed for having told people to use randomized MD5 rather than spending the same CPU cycles (not to mention bandwidth) on a larger hash function? Decades of cryptanalysis keep telling us that extra state bytes and extra rounds make the attacker's job much more difficult. Do you really have the same level of confidence in randomization? I find it difficult to believe that you thought this through before saying it, so here's a perfect chance for you to clarify your position. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago P.S. Yes, we're both talking about the same randomization: the signer prepends a random number to the message before hashing it. By the way, when you repeat Rabin's ideas, you should also give Rabin proper credit. See http://cr.yp.to/bib/entries.html#1979/rabin, page 10. _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Thu Mar 17 20:44:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13704 for ; Thu, 17 Mar 2005 20:44:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC6bl-0004UD-9d for cfrg-web-archive@ietf.org; Thu, 17 Mar 2005 20:49:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC6Tt-0002fg-6T; Thu, 17 Mar 2005 20:40:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC6Ts-0002fX-BF for cfrg@megatron.ietf.org; Thu, 17 Mar 2005 20:40:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13301 for ; Thu, 17 Mar 2005 20:40:49 -0500 (EST) Received: from mailgw1.technion.ac.il ([132.68.238.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC6YD-0004PT-0G for cfrg@ietf.org; Thu, 17 Mar 2005 20:45:21 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgw1.technion.ac.il (Postfix) with ESMTP id BA397FF8FD for ; Fri, 18 Mar 2005 03:40:47 +0200 (IST) (envelope-from hugo@ee.technion.ac.il) Received: from mailgw1.technion.ac.il ([127.0.0.1]) by localhost (mailgw1.technion.ac.il [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31275-01-73 for ; Fri, 18 Mar 2005 03:40:47 +0200 (IST) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by mailgw1.technion.ac.il (Postfix) with ESMTP id 9977FFF8D5 for ; Fri, 18 Mar 2005 03:40:47 +0200 (IST) (envelope-from hugo@ee.technion.ac.il) Received: from ee.technion.ac.il (localhost [127.0.0.1]) by ee.technion.ac.il (8.12.10+Sun/8.12.2) with ESMTP id j2I1f94A020928; Fri, 18 Mar 2005 03:41:10 +0200 (IST) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.12.10+Sun/8.12.2/Submit) with ESMTP id j2I1f9B4020924; Fri, 18 Mar 2005 03:41:09 +0200 (IST) Date: Fri, 18 Mar 2005 03:41:09 +0200 (IST) From: Hugo Krawczyk To: "D. J. Bernstein" Subject: Re: [Cfrg] Who needs collision-resistance, anyway? In-Reply-To: <20050318003039.14706.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: AAAAAQAAAAQ= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new at technion.ac.il X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: cfrg@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 On 18 Mar 2005, D. J. Bernstein wrote: > Hugo Krawczyk writes: > > Breaking SHA1 in this sense is far harder than finding collisions. > > You'll actually be surprised when the MD5 attack techniques are extended > to break randomized MD5-based signatures? You'll be embarrassed for > having told people to use randomized MD5 rather than spending the same > CPU cycles (not to mention bandwidth) on a larger hash function? I will not be embarrased at all. If these randomized techniques become part of the crypto practice I will be very satisfied. The reason is simple: not only we are raising the bar for the type of break that we need against SHA-1 (i.e. 2nd primage vs collisions) but we also raise it for ALL FUTURE DESIGNS. Indeed, if you are going to provide us with a beautiful new hash function I can already tell you that it is harder to break it when using randomness than without it (again, this is not randomness for obscuring things but for lowering the design requirements!) > > Decades of cryptanalysis keep telling us that extra state bytes and > extra rounds make the attacker's job much more difficult. Do you really > have the same level of confidence in randomization? Actually more. Should I say again that this use of randomness is not to make the finding of collisions harder but to completely change (and harden) the attacker's task? > > I find it difficult to believe that you thought this through before > saying it, so here's a perfect chance for you to clarify your position. I really appreciate giving me this (probably last) chance. You'll pardon me (well probably you won't) if I let this opportunity go by. But, how about trying to convince me that this is a bad idea using some rational arguments (hopefully free of derogatory terms and other "threats")? If you speak with reason you may even convince others. > > ---D. J. Bernstein, Associate Professor, Department of Mathematics, > Statistics, and Computer Science, University of Illinois at Chicago > > P.S. Yes, we're both talking about the same randomization: the signer > prepends a random number to the message before hashing it. By the way, > when you repeat Rabin's ideas, you should also give Rabin proper credit. > See http://cr.yp.to/bib/entries.html#1979/rabin, page 10. This is one mistake I am willing to immediately correct. (Do you know that that same year Michael Rabin was my first year's Algebra professor in the Hebrew University? As you see, I did not learn much ;) Hugo > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Thu Mar 17 22:25:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21796 for ; Thu, 17 Mar 2005 22:25:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC8Bu-0006XG-1e for cfrg-web-archive@ietf.org; Thu, 17 Mar 2005 22:30:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC860-0003cQ-51; Thu, 17 Mar 2005 22:24:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC85y-0003cL-IP for cfrg@megatron.ietf.org; Thu, 17 Mar 2005 22:24:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21596 for ; Thu, 17 Mar 2005 22:24:15 -0500 (EST) Received: from stoneport.math.uic.edu ([131.193.178.160]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DC8AL-0006Tz-9y for cfrg@ietf.org; Thu, 17 Mar 2005 22:28:49 -0500 Received: (qmail 17835 invoked by uid 1016); 18 Mar 2005 03:24:46 -0000 Date: 18 Mar 2005 03:24:46 -0000 Message-ID: <20050318032446.17834.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: cfrg@ietf.org Subject: Re: [Cfrg] Who needs collision-resistance, anyway? References: <20050318003039.14706.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Hugo Krawczyk writes: > I can already tell you that it is harder to break it when using > randomness than without it How much harder? You're not doing science if your claims aren't clear enough to be falsifiable. How thoroughly will a cryptanalyst have to shred randomized MD5 signatures before you admit that you were wrong? You're asking for something that has a very real cost in CPU time and bandwidth. Consider, for example, public-key signatures where the signer prepends 128 bits of randomness to the message before hashing it with MD5. The randomness needs to be * generated by the signer, * hashed by the signer, * transmitted through the network, and * hashed by the receiver, all of which pumps up the cost of this system to somewhere around the cost of SHA-256 or more, depending on exactly what cost metric you use. Do you seriously believe that randomized MD5 is as strong as SHA-256? You keep claiming that randomized hash-function families (UOWHFs, some people would say) are easier to design than deterministic hash-function families (CRHFs). Have you ever actually tried to design one of these objects? Exactly what aspect of the design, pray tell, is made easier by this change in standards? I've spent time on these problems. I'm now offering a $1000 reward for 256-bit collisions in my Salsa10 function. I've often considered the question of whether lowering my standards from deterministic to randomized would allow faster functions. I've never seen a way in which it would, and I've never seen anyone else point out a way. Randomization doesn't make me comfortable with a smaller state, or with a smaller number of rounds. _I_ won't be surprised when randomized MD5 signatures are broken. There are deeper problems with the whole oracle-separation philosophy lurking behind your claims. Yes, we have an oracle separation putting CRHFs above UOWHFs, but we also have an oracle separation putting public-key encryption systems above public-key signature systems---and that's completely out of whack with real-world cryptography. Building a _good_ public-key signature system---not something as bloated as hash trees---is even more difficult than building a good public-key encryption system. The recurring problem here is cost. ``Switch from MD5(m) to MD5(r,m)!'' and ``Switch from AES_k(n) to Twofish_i(RC6_j(AES_k(n)))!'' and ``Switch from Rabin-Williams signatures to hash trees!'' and ``Switch from direct use of UOWHFs to trees based on OWFs!'' all sound like perfectly good ideas if you don't pay attention to cost. But many real-world systems--- enough systems to drive cryptographic standards---simply can't afford those costs. I'm not saying that there's any loss of security from randomization. I'm saying that there's a cost, and that devoting the same resources to larger hash functions provides much more confidence than devoting them to randomization. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Thu Mar 17 22:46:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23936 for ; Thu, 17 Mar 2005 22:46:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC8W4-000754-QF for cfrg-web-archive@ietf.org; Thu, 17 Mar 2005 22:51:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC8PR-0007UK-Uo; Thu, 17 Mar 2005 22:44:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC8PQ-0007Sa-GQ for cfrg@megatron.ietf.org; Thu, 17 Mar 2005 22:44:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23432 for ; Thu, 17 Mar 2005 22:44:21 -0500 (EST) Received: from abraham.cs.berkeley.edu ([128.32.37.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC8Tn-0006zj-8U for cfrg@ietf.org; Thu, 17 Mar 2005 22:48:55 -0500 Received: from news by abraham.cs.berkeley.edu with local (Exim 4.43) id 1DC8O3-0000EE-QJ for cfrg@ietf.org; Thu, 17 Mar 2005 19:42:59 -0800 To: cfrg@ietf.org Path: not-for-mail From: daw@taverner.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ietf-cfrg Subject: Re: [Cfrg] Who needs collision-resistance, anyway? Date: Fri, 18 Mar 2005 03:42:59 +0000 (UTC) Organization: University of California, Berkeley Lines: 18 Distribution: isaac Message-ID: References: <20050318003039.14706.qmail@cr.yp.to> <20050318032446.17834.qmail@cr.yp.to> NNTP-Posting-Host: taverner.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1111117379 32086 128.32.168.222 (18 Mar 2005 03:42:59 GMT) X-Complaints-To: usenet@abraham.cs.berkeley.edu NNTP-Posting-Date: Fri, 18 Mar 2005 03:42:59 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: daw@taverner.cs.berkeley.edu (David Wagner) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Wagner List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Seems like the use of randomization (i.e., use of universal one-way hash functions) is orthogonal to the choice of hash function. No matter what hash function you choose, randomization seems like a good idea if you are going to use that hash function for public-key signatures. Moreover, these two changes occur at a different level of abstraction; we might change the specification of the signature scheme to use randomization no matter what hash function is specified, and then this change will benefit all uses of that signature scheme. If you like, you can think of randomization as a "hedge" against cryptanalysis of the collision-resistance of the underlying hash. I heard a concern that randomization has a cost. I would like to understand better what that cost is. If you are talking about performance, I would expect the performance overhead of randomization to be negligible compared to the time it takes to compute a signature. Since we are talking about using randomization in the context of public-key signatures, performance does not seem like a big deal. Am I missing something? Is there some other cost I am overlooking? _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Thu Mar 17 23:57:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29695 for ; Thu, 17 Mar 2005 23:57:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC9cX-0000CV-IF for cfrg-web-archive@ietf.org; Fri, 18 Mar 2005 00:02:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC9Wo-0001Gr-7g; Thu, 17 Mar 2005 23:56:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC9Wm-0001Gm-Hl for cfrg@megatron.ietf.org; Thu, 17 Mar 2005 23:56:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29637 for ; Thu, 17 Mar 2005 23:56:01 -0500 (EST) Received: from stoneport.math.uic.edu ([131.193.178.160]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DC9bA-0008Tj-3I for cfrg@ietf.org; Fri, 18 Mar 2005 00:00:36 -0500 Received: (qmail 19095 invoked by uid 1016); 18 Mar 2005 04:56:32 -0000 Date: 18 Mar 2005 04:56:32 -0000 Message-ID: <20050318045632.19094.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: cfrg@ietf.org Subject: Re: [Cfrg] Who needs collision-resistance, anyway? References: <20050318003039.14706.qmail@cr.yp.to> <20050318032446.17834.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Exercise for the reader: SHA-512 has been a standard for years, and is obviously vastly more difficult to break than MD5 and SHA-1. Can you explain why so few people are using it? Followup: Why would anyone choose SHA-256 rather than SHA-512? David Wagner writes: > Seems like the use of randomization (i.e., use of universal one-way > hash functions) is orthogonal to the choice of hash function. If you don't care about cost, you're free to choose any hash function you want, and then to add randomization. However, in the real world, cost limits constrain the collection of choices in a complicated way. > No matter what hash function you choose, randomization seems like a > good idea if you are going to use that hash function for public-key > signatures. If you don't care about cost, then randomization is clearly harmless, and some people speculate that it's beneficial. Whenever you see people using SHA-1(m), do you tell them to switch not just to SHA-1(r,m) but to (SHA-1(r,m),SHA-512(r,m))? After all, if you don't care about cost, then concatenating SHA-512 is clearly harmless, and one can speculate that it's beneficial---in fact, (SHA-1,SHA-512) is generally believed to be _much_ stronger than SHA-1, despite anything bad that you might have heard about concatenation. > If you like, you can think of randomization as a "hedge" against > cryptanalysis of the collision-resistance of the underlying hash. One could say the same about appending SHA-512 (although it's more like a brick wall than a hedge, if your other function is SHA-1). Or about assuming merely that SHA-512 is a OWF, and building a UOWHF by a gigantic tree of SHA-512 computations. All of this is perfectly reasonable if you don't care about cost. > If you are talking about performance, I would expect the performance > overhead of randomization to be negligible compared to the time it > takes to compute a signature. Generating random numbers isn't free. Furthermore, transmitting random numbers costs bandwidth. Furthermore, in many applications, signature _verification_ happens much more frequently than signature computation. One example you should keep in mind is DNS---a critical database of public information that, after twelve years of discussion, _still_ isn't protected against forgery. Securing DNS means having busy caches verify tens of thousands of signatures per second, and fitting those signatures into UDP packets. Do you think that it's a ``good idea'' to casually stuff more data into the hashes, and into the packets? ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Fri Mar 18 02:43:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03513 for ; Fri, 18 Mar 2005 02:43:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCCCu-0003p6-JV for cfrg-web-archive@ietf.org; Fri, 18 Mar 2005 02:47:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCC6B-0004Mr-Kw; Fri, 18 Mar 2005 02:40:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCC5u-0004I9-PB for cfrg@megatron.ietf.org; Fri, 18 Mar 2005 02:40:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03277 for ; Fri, 18 Mar 2005 02:40:29 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.192]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCCAJ-0003lP-MG for cfrg@ietf.org; Fri, 18 Mar 2005 02:45:03 -0500 Received: by wproxy.gmail.com with SMTP id 68so76962wri for ; Thu, 17 Mar 2005 23:40:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=q5vz3XQY4GNc33eY98Simj3gfeCE3ZyBUYLFCc8cgpRWn/vDuRkJoz8DB/iMaO5x/M9RiD9gKBapW7bW4uZvyRo/vPJLtuFA86QtZz82JaFvAV9YIpWcmhPRXhZ07yUQIltUoTk61Y3us+/S/uAQvhUx5Auf6x2P4ib2Not5hL4= Received: by 10.54.78.16 with SMTP id a16mr635316wrb; Thu, 17 Mar 2005 23:39:55 -0800 (PST) Received: by 10.54.35.54 with HTTP; Thu, 17 Mar 2005 23:39:55 -0800 (PST) Message-ID: <5e01c29a050317233967cdce56@mail.gmail.com> Date: Thu, 17 Mar 2005 23:39:55 -0800 From: Michael Silk To: hugo@ee.technion.ac.il Subject: Re: [Cfrg] Who needs collision-resistance, anyway? In-Reply-To: <20050318045632.19094.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <20050318003039.14706.qmail@cr.yp.to> <20050318032446.17834.qmail@cr.yp.to> <20050318045632.19094.qmail@cr.yp.to> X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: cfrg@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: michaelslists@gmail.com List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit I don't see the difference between this hashing proposal and HMAC? Except in this case you skip the XOR'ing part and you don't keep the key.. and why have you decided not to use HMAC in this case? (or have I, again, missed something obvious?) And an implementation note i'm sure we are all aware of: random numbers are really hard for most companies to get right; and probably they would (if they were allowed to) use their email, or company name, or something as the 'random' part. -- Michael On 18 Mar 2005 04:56:32 -0000, D. J. Bernstein wrote: > Exercise for the reader: SHA-512 has been a standard for years, and is > obviously vastly more difficult to break than MD5 and SHA-1. Can you > explain why so few people are using it? Followup: Why would anyone > choose SHA-256 rather than SHA-512? > > David Wagner writes: > > Seems like the use of randomization (i.e., use of universal one-way > > hash functions) is orthogonal to the choice of hash function. > > If you don't care about cost, you're free to choose any hash function > you want, and then to add randomization. However, in the real world, > cost limits constrain the collection of choices in a complicated way. > > > No matter what hash function you choose, randomization seems like a > > good idea if you are going to use that hash function for public-key > > signatures. > > If you don't care about cost, then randomization is clearly harmless, > and some people speculate that it's beneficial. > > Whenever you see people using SHA-1(m), do you tell them to switch not > just to SHA-1(r,m) but to (SHA-1(r,m),SHA-512(r,m))? After all, if you > don't care about cost, then concatenating SHA-512 is clearly harmless, > and one can speculate that it's beneficial---in fact, (SHA-1,SHA-512) is > generally believed to be _much_ stronger than SHA-1, despite anything > bad that you might have heard about concatenation. > > > If you like, you can think of randomization as a "hedge" against > > cryptanalysis of the collision-resistance of the underlying hash. > > One could say the same about appending SHA-512 (although it's more like > a brick wall than a hedge, if your other function is SHA-1). Or about > assuming merely that SHA-512 is a OWF, and building a UOWHF by a > gigantic tree of SHA-512 computations. All of this is perfectly > reasonable if you don't care about cost. > > > If you are talking about performance, I would expect the performance > > overhead of randomization to be negligible compared to the time it > > takes to compute a signature. > > Generating random numbers isn't free. Furthermore, transmitting random > numbers costs bandwidth. Furthermore, in many applications, signature > _verification_ happens much more frequently than signature computation. > > One example you should keep in mind is DNS---a critical database of > public information that, after twelve years of discussion, _still_ isn't > protected against forgery. Securing DNS means having busy caches verify > tens of thousands of signatures per second, and fitting those signatures > into UDP packets. Do you think that it's a ``good idea'' to casually > stuff more data into the hashes, and into the packets? > > ---D. J. Bernstein, Associate Professor, Department of Mathematics, > Statistics, and Computer Science, University of Illinois at Chicago > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Fri Mar 18 09:20:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10901 for ; Fri, 18 Mar 2005 09:20:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCIPc-0007Cv-UY for cfrg-web-archive@ietf.org; Fri, 18 Mar 2005 09:25:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCIK5-0004UQ-EZ; Fri, 18 Mar 2005 09:19:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCIK1-0004UL-Qw for cfrg@megatron.ietf.org; Fri, 18 Mar 2005 09:19:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10822 for ; Fri, 18 Mar 2005 09:19:27 -0500 (EST) Received: from ns.ca.certicom.com ([66.48.18.197] helo=mail.ca.certicom.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DCIOS-0007BZ-Pr for cfrg@ietf.org; Fri, 18 Mar 2005 09:24:06 -0500 Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id CC6A510089; Fri, 18 Mar 2005 09:19:18 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29965-88; Fri, 18 Mar 2005 09:19:04 -0500 (EST) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 7C85910088; Fri, 18 Mar 2005 09:19:04 -0500 (EST) In-Reply-To: To: David Wagner Subject: Re: [Cfrg] Who needs collision-resistance, anyway? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Daniel Brown Date: Fri, 18 Mar 2005 09:09:49 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 03/18/2005 09:09:51 AM, Serialize complete at 03/18/2005 09:09:51 AM Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: cfrg@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 David Wagner wrote on 03/17/2005 10:42:59 PM: > Seems like the use of randomization (i.e., use of universal one-way hash > functions) is orthogonal to the choice of hash function. No matter > what hash function you choose, randomization seems like a good idea > if you are going to use that hash function for public-key signatures. > Moreover, these two changes occur at a different level of abstraction; > we might change the specification of the signature scheme to use > randomization no matter what hash function is specified, and then this > change will benefit all uses of that signature scheme. If you like, > you can think of randomization as a "hedge" against cryptanalysis of > the collision-resistance of the underlying hash. > > I heard a concern that randomization has a cost. I would like > to understand better what that cost is. If you are talking about > performance, I would expect the performance overhead of randomization A slight advantage of computing H(m) instead of H(r|m) is that H(m) can be pre-computed. This can be merely a matter of implementation convenience, or a more significant savings if m is to be signed by many parties. Schemes like DL/ECPVSSR in IEEE 1363a, define r = g^k, where k is random. Computing k is quick (obtaining entropy for k is arguably expensive, but it may be fine to use a PRNG with enough start-up entropy). It's computing r that is the most expensive step of ElGamal-based signatures. Therefore a requirement like H(r|m) introduces a delay before hashing can be begin, which could be avoided if hashing was done in parallel to computing r = g^k. One could also just prepend m with some random value "salt", then include salt with the signature. This, however, adds to bandwidth, which may be fine in some circumstances and a nuisance in others. ElGamal-based signature schemes are already randomized, so it seems sensible to re-use randomization in the hash to save bandwidth and to benefit from the security advantages of H(r|m), however debatable those might be. By the way, the security of advantage of H(r|m) is not just that it reduces dependence on collision-resistance, it is also makes certain kinds of security proofs work, especially in the random oracle model, such as Pointcheval and Stern's "forking lemma" proof for modified DSA (see also http://www.cacr.math.uwaterloo.ca/techreports/2000/corr2000-39.pdf). On the other hand, addition of r into the hash also interferes certain other kinds of security proofs (see http://www.cacr.math.uwaterloo.ca/conferences/2001/ecc/brown.ps). > to be negligible compared to the time it takes to compute a signature. > Since we are talking about using randomization in the context of > public-key signatures, performance does not seem like a big deal. > Am I missing something? Is there some other cost I am overlooking? > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Fri Mar 18 09:24:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11199 for ; Fri, 18 Mar 2005 09:24:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCITF-0007Kt-Np for cfrg-web-archive@ietf.org; Fri, 18 Mar 2005 09:29:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCIOD-0005Q3-B4; Fri, 18 Mar 2005 09:23:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCIOC-0005Pw-9E for cfrg@megatron.ietf.org; Fri, 18 Mar 2005 09:23:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11141 for ; Fri, 18 Mar 2005 09:23:46 -0500 (EST) Received: from vms046pub.verizon.net ([206.46.252.46]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCISe-0007Jl-KE for cfrg@ietf.org; Fri, 18 Mar 2005 09:28:25 -0500 Received: from HP752c ([68.237.49.106]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IDJ009T0XBLSI10@vms046.mailsrvcs.net> for cfrg@ietf.org; Fri, 18 Mar 2005 08:23:46 -0600 (CST) Date: Fri, 18 Mar 2005 09:23:48 -0500 From: "Shai Halevi" In-reply-to: <200503180741.j2I7fjdr016758@alum-1.mit.edu> To: Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Subject: [Cfrg] Re: Who needs collision-resistance, anyway? X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit "D. J. Bernstein" wrote: > Shai Halevi writes: > > * Wouldn't it make sense to modify some of the standards along this > > line? > > Why _would_ it make sense? Why should anyone believe that this use of > CPU time and bandwidth is more secure than using a larger hash function? I can think of at least three reasons: (a) Common sense: "everybody knows" that finding a second pre-image is harder than finding collisions, and target collision resistance is essentially the same as second pre-image resistance. Also, the "brute force complexity" of breaking TCR is related to 2^n, whereas the "brute force complexity" for finding collisions is related to 2^{n/2}. (b) A significant body of cryptographic research suggesting that target collision reseitance in an easier task in principle than full collision resistance. (E.g., we have constructions of TCR fucntions from one-way functions, but we know that there are no "black-box constructions" of fully CR functions from one-way functions.) (c) The cost in bandwidth and CPU time is quite small in most environments: You have to generate and send some 20 pseudo-random bytes, which is usually much smaller than the time and bandwidth that it takes to compute and communicate the messge itself and the signature. (Granted, there will always be niche environments where this cost is significant, but I am claiming that this is not the case in general.) > Would you really be surprised if the attack techniques are extended to > allow some randomness in the input? Yes, very much so. Notice that this is an "after the fact" randomness: The attacker first supplies one message, then the randomness is drawn, and then the attacker needs to supply another message that will collide under the same randomness. -- Shai p.s. Can anyone say something about the third question from my original post: > * Can anyone describe a real-life application where full > collision-resistance is really needed? _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Fri Mar 18 10:13:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15984 for ; Fri, 18 Mar 2005 10:13:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCJF3-0000pK-6b for cfrg-web-archive@ietf.org; Fri, 18 Mar 2005 10:18:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCJ9d-0005n3-UK; Fri, 18 Mar 2005 10:12:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCJ9c-0005mq-Fz for cfrg@megatron.ietf.org; Fri, 18 Mar 2005 10:12:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15853 for ; Fri, 18 Mar 2005 10:12:46 -0500 (EST) Received: from igw2.watson.ibm.com ([129.34.20.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCJE4-0000nq-Bb for cfrg@ietf.org; Fri, 18 Mar 2005 10:17:25 -0500 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id j2IFCbP479604 for ; Fri, 18 Mar 2005 10:12:37 -0500 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j2IFCaa63840 for ; Fri, 18 Mar 2005 10:12:36 -0500 Received: from [127.0.0.1] (CRYPT01.watson.ibm.com [9.2.18.142]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j2IFCaG55194 for ; Fri, 18 Mar 2005 10:12:36 -0500 Message-ID: <423AEFE2.2020507@alum.mit.edu> Date: Fri, 18 Mar 2005 10:12:34 -0500 From: Shai Halevi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: cfrg@ietf.org References: <200503180741.j2I7fjdr016758@alum-1.mit.edu> In-Reply-To: <200503180741.j2I7fjdr016758@alum-1.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Subject: [Cfrg] Re: Who needs collision-resistance, anyway? X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Michael Silk wrote: > I don't see the difference between this hashing proposal and HMAC? > Except in this case you skip the XOR'ing part and you don't keep the > key.. and why have you decided not to use HMAC in this case? I think that Hugo's proposal was meant to save a bit on computation, since in this case maybe you don't really need HMAC. My opinion is that in general you should use HMAC whenever you need a keyed hash function, unless there is a very good reason not to do so. This is not becuase of crypto reasons, just first principles of system design: First, it is more conveneicne to have the same construct everywhere. Thay way we don't have to re-think every time whether or not this form of keying is appropriate for our particular application. More importantly, once you have a keyed hash function implemented somewhere in your system, someone will surely find other uses for it, and some of these uses may actually need HAMC. > And an implementation note i'm sure we are all aware of: random > numbers are really hard for most companies to get right; and probably > they would (if they were allowed to) use their email, or company name, > or something as the 'random' part. That's a good point, so you should really use pseudo-randomness here. You can also have the pseudo-random bits depend on the message that you want to sign (e.g., include also an HMAC key with your secret key, and compute the randomness as HMAC(message)). Or keep a 160-bit counter and compute the randomness for the next signature as HMAC(counter++). -- Shai _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Fri Mar 18 10:47:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19841 for ; Fri, 18 Mar 2005 10:47:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCJll-0002DK-CG for cfrg-web-archive@ietf.org; Fri, 18 Mar 2005 10:52:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCJei-000369-G3; Fri, 18 Mar 2005 10:44:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCJeg-000361-Ph for cfrg@megatron.ietf.org; Fri, 18 Mar 2005 10:44:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19620 for ; Fri, 18 Mar 2005 10:44:51 -0500 (EST) Received: from igw2.watson.ibm.com ([129.34.20.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCJj9-000232-Ja for cfrg@ietf.org; Fri, 18 Mar 2005 10:49:31 -0500 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id j2IFiiP227754 for ; Fri, 18 Mar 2005 10:44:44 -0500 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j2IFiia55126 for ; Fri, 18 Mar 2005 10:44:44 -0500 Received: from [127.0.0.1] (CRYPT01.watson.ibm.com [9.2.18.142]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j2IFihG33666 for ; Fri, 18 Mar 2005 10:44:43 -0500 Message-ID: <423AF76A.4030506@alum.mit.edu> Date: Fri, 18 Mar 2005 10:44:42 -0500 From: Shai Halevi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: cfrg@ietf.org References: <200503180741.j2I7fjdr016758@alum-1.mit.edu> In-Reply-To: <200503180741.j2I7fjdr016758@alum-1.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Subject: [Cfrg] Is target-collision-resistance really harder than full collision-resistance? X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit "D. J. Bernstein" wrote: > Would you really be surprised if the attack techniques are extended to > allow some randomness in the input? On second thought, the main difference seems to be that the TCR model forces the adversary to do on-line work, whereas in the model of full CR the attacker can mount the attack off-line. In particular, I will not be very surprised if we have an attack that makes 2^{60} calls to the hash routine, getting back 2^{60} different pieces of randomness, and then find collision to one of them. However, I will be very surprised if you can do the same with only 2^{40} calls. So let's say that an attack is "feasible" is it works in at most (say) 2^{50} on-line calls, 2^{70} space and 2^{90} off-line computation time. I will be very surprised if you find a TCR-type attack on SHA1 with these parameters. > I've spent time on these problems. I'm now offering a $1000 reward for > 256-bit collisions in my Salsa10 function. I only spent a bit of time on this, but I'll buy a bottle of wine to anyone that would find attack on SHA1 with the parameters from above. :) -- Shai _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Fri Mar 18 11:21:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24650 for ; Fri, 18 Mar 2005 11:21:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCKIP-00040P-Lp for cfrg-web-archive@ietf.org; Fri, 18 Mar 2005 11:25:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCKAr-0001AR-Jr; Fri, 18 Mar 2005 11:18:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCKAp-0001AF-0L for cfrg@megatron.ietf.org; Fri, 18 Mar 2005 11:18:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24378 for ; Fri, 18 Mar 2005 11:18:04 -0500 (EST) Received: from mailgw3.technion.ac.il ([132.68.238.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCKFH-0003pk-SX for cfrg@ietf.org; Fri, 18 Mar 2005 11:22:44 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgw3.technion.ac.il (Postfix) with ESMTP id 839CB167724 for ; Fri, 18 Mar 2005 18:17:49 +0200 (IST) (envelope-from hugo@ee.technion.ac.il) Received: from mailgw3.technion.ac.il ([127.0.0.1]) by localhost (mailgw3.technion.ac.il [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10276-01-3 for ; Fri, 18 Mar 2005 18:17:49 +0200 (IST) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by mailgw3.technion.ac.il (Postfix) with ESMTP id 6097416771E for ; Fri, 18 Mar 2005 18:17:49 +0200 (IST) (envelope-from hugo@ee.technion.ac.il) Received: from ee.technion.ac.il (localhost [127.0.0.1]) by ee.technion.ac.il (8.12.10+Sun/8.12.2) with ESMTP id j2IGIM4A004200; Fri, 18 Mar 2005 18:18:22 +0200 (IST) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.12.10+Sun/8.12.2/Submit) with ESMTP id j2IGIMoK004197; Fri, 18 Mar 2005 18:18:22 +0200 (IST) Date: Fri, 18 Mar 2005 18:18:22 +0200 (IST) From: Hugo Krawczyk To: Michael Silk Subject: Re: [Cfrg] Who needs collision-resistance, anyway? In-Reply-To: <5e01c29a050317233967cdce56@mail.gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: AAAAAQAAAAQ= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new at technion.ac.il X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: cfrg@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 On Thu, 17 Mar 2005, Michael Silk wrote: > I don't see the difference between this hashing proposal and HMAC? > Except in this case you skip the XOR'ing part and you don't keep the > key.. and why have you decided not to use HMAC in this case? (or have > I, again, missed something obvious?) Adding to Shai's response let me first say that I have found myself innumerable times convincing people not to use hmac, what's wrong with me? :) More seriously, let me clarify some points. (1) The proven security of HMAC (as a MAC or even PRF) is irrelevant to this application (though, one may be able to derive some relevant properties from our paper with Dodis et al from last crypto) (2) The main objection to HMAC here is its added computation. The argument against this objection is that since we are talking about computing signatures then the additional two-block hashing required by HMAC (relative to just H(r,m)) is negligible. This is even true for RSA verification with short exponent. (3) A purely heuristic advantage of HMAC is that the job of the cryptanalyst is made much harder. It now needs to find m, then receive r and now find m' such that H(r|H(r|m))= H(r|H(r,m')) so the attacker needs to be able to simultaneously control both h=H(r|m') and the resultant H(r|h). This would probably require an algortihm that fully inverts H on more or less every output (not to speak of the need to invert H in a way that the found preimage, m', be of any use to the attacker). (4) Probably the main advantage of HMAC is its availability in most systems today. You can re-use its implementation and interface. So, after all, using HMAC may be a good idea... > And an implementation note i'm sure we are all aware of: random > numbers are really hard for most companies to get right; and probably > they would (if they were allowed to) use their email, or company name, > or something as the 'random' part. I do not dismiss the problems with pseudo-random generation. But as Shai said once you get a single good key (or seed) you can generate many pseudo-random bits via a pseudo-random generator or PRF. Hopefully, heavy signers such as CAs will be able to have some good randomness generators. And even lighter cryptographic systems will need to have random generators for many other cryptographic uses (such as generating keys, nonces and the like). And, as usual, there is many ways a bad implementation will break even the best crypto. Hugo > > -- Michael > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Fri Mar 18 12:44:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02963 for ; Fri, 18 Mar 2005 12:44:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCLbB-0007W3-Kw for cfrg-web-archive@ietf.org; Fri, 18 Mar 2005 12:49:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCLUr-0002UV-K1; Fri, 18 Mar 2005 12:42:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCLUp-0002Sj-Q5 for cfrg@megatron.ietf.org; Fri, 18 Mar 2005 12:42:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02781 for ; Fri, 18 Mar 2005 12:42:48 -0500 (EST) Received: from stoneport.math.uic.edu ([131.193.178.160]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DCLZJ-0007Q8-4Q for cfrg@ietf.org; Fri, 18 Mar 2005 12:47:30 -0500 Received: (qmail 81563 invoked by uid 1016); 18 Mar 2005 17:43:17 -0000 Date: 18 Mar 2005 17:43:17 -0000 Message-ID: <20050318174317.81562.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: cfrg@ietf.org Subject: Re: [Cfrg] Who needs collision-resistance, anyway? References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Daniel Brown writes: > By the way, the security of advantage of H(r|m) is not just that it > reduces dependence on collision-resistance, it is also makes certain kinds > of security proofs work, especially in the random oracle model The randomization certainly allows ``weaker'' assumptions about, e.g., RSA. However, as Koblitz and Menezes have explained in detail, there's no reason to believe that the ``weaker'' RSA assumptions are any harder to break---i.e., that this extra cost produces any extra security. See http://eprint.iacr.org/2004/152, especially the section ``Pass on PSS.'' Katz and Wang showed a couple of years ago that, if r is generated deterministically (as proposed by Barwood and Wigley), then any length of r down to one bit allows a tight security proof under the ``weaker'' RSA assumptions. This eliminates most of the costs of relying on the ``weaker'' RSA assumptions. See http://cr.yp.to/papers.html#rwtight for a variant that covers Rabin-Williams, and a detailed discussion of several cost issues. A short r does _not_ let us rely on ``weaker'' H assumptions, namely UOWHF instead of CRHF. Systems using the ``weaker'' H assumptions have the same basic problem as non-Katz-Wang systems using the ``weaker'' RSA assumptions, such as PSS: they incur very real costs for users in exchange for a purely speculative improvement in security. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Fri Mar 18 13:02:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04549 for ; Fri, 18 Mar 2005 13:02:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCLsJ-0008DB-EV for cfrg-web-archive@ietf.org; Fri, 18 Mar 2005 13:07:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCLmY-0005y2-Ux; Fri, 18 Mar 2005 13:01:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCLmX-0005xu-KL for cfrg@megatron.ietf.org; Fri, 18 Mar 2005 13:01:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04439 for ; Fri, 18 Mar 2005 13:01:06 -0500 (EST) Received: from stoneport.math.uic.edu ([131.193.178.160]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DCLr2-00084l-4K for cfrg@ietf.org; Fri, 18 Mar 2005 13:05:48 -0500 Received: (qmail 3121 invoked by uid 1016); 18 Mar 2005 18:01:38 -0000 Date: 18 Mar 2005 18:01:38 -0000 Message-ID: <20050318180138.3120.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: cfrg@ietf.org Subject: Re: [Cfrg] Is target-collision-resistance really harder than full collision-resistance? References: <200503180741.j2I7fjdr016758@alum-1.mit.edu> <423AF76A.4030506@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Shai Halevi writes: > So let's say that an attack is "feasible" is it works in at most (say) > 2^{50} on-line calls, 2^{70} space and 2^{90} off-line computation time. > I will be very surprised if you find a TCR-type attack on SHA1 > with these parameters. Hold it---you're cheating by changing the problem! Suppose the attacker generates 2^50 messages m_1,m_2,...; the signer, in response, generates 160-bit strings r_1,r_2,...; the attacker somehow exploits the structure of SHA-1 to find (i,m') with m' different from m_1,m_2,... and with SHA-1(r_i,m') = SHA-1(r_i,m_i). This is 100% successful as an attack on a signature system using randomized SHA-1. It doesn't imply a feasible attack on TCR---there's a massive 2^50 factor in the probability ratios! You can't casually use polynomial equivalences if you're talking about constants. Will you be surprised when someone announces an attack of this type? ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Fri Mar 18 14:20:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12986 for ; Fri, 18 Mar 2005 14:20:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCN5k-0002xt-Js for cfrg-web-archive@ietf.org; Fri, 18 Mar 2005 14:25:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCMyQ-0003Y8-5R; Fri, 18 Mar 2005 14:17:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCMyO-0003Y0-74 for cfrg@megatron.ietf.org; Fri, 18 Mar 2005 14:17:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12733 for ; Fri, 18 Mar 2005 14:17:26 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCN2s-0002tl-8t for cfrg@ietf.org; Fri, 18 Mar 2005 14:22:07 -0500 Received: from phys-san-2 ([129.153.85.71]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j2IJHORv022296 for ; Fri, 18 Mar 2005 12:17:25 -0700 (MST) Received: from conversion-daemon.san-mail1.west.sun.com by san-mail1.west.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IDK00601AAXJX@san-mail1.west.sun.com> (original mail from David.Jacobson@Sun.COM) for cfrg@ietf.org; Fri, 18 Mar 2005 11:17:24 -0800 (PST) Received: from Sun.COM (sr1-usan-05.West.Sun.COM [129.153.85.35]) by san-mail1.west.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IDK007SYAX0M5@san-mail1.west.sun.com>; Fri, 18 Mar 2005 11:17:24 -0800 (PST) Date: Fri, 18 Mar 2005 11:17:24 -0800 From: david jacobson Subject: Re: [Cfrg] Who needs collision-resistance, anyway? In-reply-to: <5e01c29a050317233967cdce56@mail.gmail.com> To: michaelslists@gmail.com Message-id: <423B2944.9040601@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 References: <20050318003039.14706.qmail@cr.yp.to> <20050318032446.17834.qmail@cr.yp.to> <20050318045632.19094.qmail@cr.yp.to> <5e01c29a050317233967cdce56@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7BIT Cc: cfrg@ietf.org, hugo@ee.technion.ac.il X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David.Jacobson@Sun.COM List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7BIT Michael Silk wrote: > I don't see the difference between this hashing proposal and HMAC? > Except in this case you skip the XOR'ing part and you don't keep the > key.. and why have you decided not to use HMAC in this case? (or have > I, again, missed something obvious?) > > And an implementation note i'm sure we are all aware of: random > numbers are really hard for most companies to get right; and probably > they would (if they were allowed to) use their email, or company name, > or something as the 'random' part. > > -- Michael As to the last paragraph, I think the upcoming ANSI X9.82 standard on random number generation will help. (This discussion is getting way too heated and needs to be spun off on a tangent :-) ). Companies respond to market pressure---customers have to be asking for something, or it has to be seen as a way to differentiate the company's product from its competitors' products. Most customers don't know they need a source of quality random nubmers, those who do don't have a short name for it, and it isn't showing up as a column heading in comparisions. So it doesn't get done. When the standard comes out, the phrase will be "ANSI X9.82 compliant". Customers can ask for it. Companies can claim it. Companies will have guidance in how to do it. -- David Jacobson _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Fri Mar 18 14:39:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15466 for ; Fri, 18 Mar 2005 14:39:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCNOX-0003ms-72 for cfrg-web-archive@ietf.org; Fri, 18 Mar 2005 14:44:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCNHM-00078Q-Ax; Fri, 18 Mar 2005 14:37:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCNHK-00078L-B2 for cfrg@megatron.ietf.org; Fri, 18 Mar 2005 14:37:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15064 for ; Fri, 18 Mar 2005 14:37:00 -0500 (EST) Received: from abraham.cs.berkeley.edu ([128.32.37.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCNLp-0003hg-Kk for cfrg@ietf.org; Fri, 18 Mar 2005 14:41:41 -0500 Received: from news by abraham.cs.berkeley.edu with local (Exim 4.43) id 1DCNFx-00087g-De for cfrg@ietf.org; Fri, 18 Mar 2005 11:35:37 -0800 To: cfrg@ietf.org Path: not-for-mail From: daw@taverner.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ietf-cfrg Subject: Re: [Cfrg] Who needs collision-resistance, anyway? Date: Fri, 18 Mar 2005 19:35:37 +0000 (UTC) Organization: University of California, Berkeley Lines: 12 Distribution: isaac Message-ID: References: <20050318003039.14706.qmail@cr.yp.to> <20050318032446.17834.qmail@cr.yp.to> <20050318045632.19094.qmail@cr.yp.to> NNTP-Posting-Host: taverner.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1111174537 30870 128.32.168.222 (18 Mar 2005 19:35:37 GMT) X-Complaints-To: usenet@abraham.cs.berkeley.edu NNTP-Posting-Date: Fri, 18 Mar 2005 19:35:37 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: daw@taverner.cs.berkeley.edu (David Wagner) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Wagner List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 D. J. Bernstein wrote: >Exercise for the reader: SHA-512 has been a standard for years, and is >obviously vastly more difficult to break than MD5 and SHA-1. Can you >explain why so few people are using it? I don't know how others choose between hash functions, but I can tell you some of my reasoning, if that is relevant. I know SHA1 well; I have spent time trying to cryptanalyze SHA1; I have spoken to others who have done the same. I can't say the same for SHA-256 or SHA-512. While SHA-256 or SHA-512 may well be better, that has made me reluctant to switch to a hash function that I understand less well. However, I may well be forced to overcome my reluctance, given the recent results on SHA1. _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Fri Mar 18 14:58:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17804 for ; Fri, 18 Mar 2005 14:58:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCNgN-0004bG-4a for cfrg-web-archive@ietf.org; Fri, 18 Mar 2005 15:02:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCNYr-0001rs-NM; Fri, 18 Mar 2005 14:55:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCNYq-0001rn-LU for cfrg@megatron.ietf.org; Fri, 18 Mar 2005 14:55:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17329 for ; Fri, 18 Mar 2005 14:55:06 -0500 (EST) Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCNdL-0004Rz-4U for cfrg@ietf.org; Fri, 18 Mar 2005 14:59:48 -0500 Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id j2IJt5Qs019415 for ; Fri, 18 Mar 2005 11:55:05 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 18 Mar 2005 11:55:05 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD37250096@MOU1WNEXMB04.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" To: cfrg@ietf.org Subject: RE: [Cfrg] Who needs collision-resistance, anyway? Date: Fri, 18 Mar 2005 11:54:57 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab I think that this discussion has got somewhat off track. There are good reasons for using an HMAC type construction to create a digest that have nothing to do with the security issues with SHA1. One of the problematic aspects of RSA digital signatures is that they have the property that every signature of the same message under the same key is identical. This is not an ideal situation from the point of view of a security protocol designer, there are many cases in which the fact that a signature is identical is not ideal. I do not want the signature on a message to leak any information concerning the contents. This means that I don't have to worry about where the signature is being stored when auditing for confidentiality protection. I note that the one digital signature function that the NSA has given us has this property which is quite interesting in and of itself. _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Fri Mar 18 14:59:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18061 for ; Fri, 18 Mar 2005 14:59:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCNhu-0004eS-Pe for cfrg-web-archive@ietf.org; Fri, 18 Mar 2005 15:04:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCNcA-00024u-1E; Fri, 18 Mar 2005 14:58:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCNc9-00024p-EY for cfrg@megatron.ietf.org; Fri, 18 Mar 2005 14:58:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17857 for ; Fri, 18 Mar 2005 14:58:31 -0500 (EST) Received: from mail-lon.bigfish.com ([213.206.137.197] helo=mail11-lon-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCNgd-0004bU-J3 for cfrg@ietf.org; Fri, 18 Mar 2005 15:03:13 -0500 Received: from mail11-lon.bigfish.com (localhost.localdomain [127.0.0.1]) by mail11-lon-R.bigfish.com (Postfix) with ESMTP id 1D6B14A5D1A for ; Fri, 18 Mar 2005 19:58:24 +0000 (UCT) X-BigFish: VC Received: by mail11-lon (MessageSwitch) id 1111175903886166_8865; Fri, 18 Mar 2005 19:58:23 +0000 (UCT) Received: from sjcxch03.tbu.com (unknown [208.10.194.50]) by mail11-lon.bigfish.com (Postfix) with ESMTP id 88C3E4A5D02 for ; Fri, 18 Mar 2005 19:58:23 +0000 (UCT) Received: from cldxch02.tbu.com ([192.168.2.251]) by sjcxch03.tbu.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Mar 2005 11:58:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Cfrg] Who needs collision-resistance, anyway? Date: Fri, 18 Mar 2005 11:58:18 -0800 Message-ID: Thread-Topic: [Cfrg] Who needs collision-resistance, anyway? Thread-Index: AcUr8ibBLVPzOpXTRk+lbcNYftwr1AAAZ8NF From: "Doug Whiting" To: "David Wagner" , X-OriginalArrivalTime: 18 Mar 2005 19:58:19.0491 (UTC) FILETIME=[D4F72B30:01C52BF4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1841597318==" Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 This is a multi-part message in MIME format. --===============1841597318== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C52BF4.D49E72E9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C52BF4.D49E72E9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Also, from a performance standpoint (given implementation numbers I've = seen), SHA256 is ~2x slower than SHA1, and SHA512 is ~5x slower. So, if = hash performance is truly critical (as some have argued here) in these = applications, then that does not argue in favor of SHA256/SHA512. The = reasons for using SHA256+ must be cryptographic, not performance based. ________________________________ From: cfrg-bounces@ietf.org on behalf of David Wagner Sent: Fri 3/18/2005 11:35 AM To: cfrg@ietf.org Subject: Re: [Cfrg] Who needs collision-resistance, anyway? D. J. Bernstein wrote: >Exercise for the reader: SHA-512 has been a standard for years, and is >obviously vastly more difficult to break than MD5 and SHA-1. Can you >explain why so few people are using it? I don't know how others choose between hash functions, but I can tell = you some of my reasoning, if that is relevant. I know SHA1 well; I have = spent time trying to cryptanalyze SHA1; I have spoken to others who have done the same. I can't say the same for SHA-256 or SHA-512. While SHA-256 or SHA-512 may well be better, that has made me reluctant to switch to a hash function that I understand less well. However, I may well be forced to overcome my reluctance, given the recent results on SHA1. _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg ------_=_NextPart_001_01C52BF4.D49E72E9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: [Cfrg] Who needs collision-resistance, anyway?=0A= =0A= =0A=
=0A=
Also, from a = performance =0A= standpoint (given implementation numbers I've seen), SHA256 is ~2x = slower than =0A= SHA1, and SHA512 is ~5x slower. So, if hash performance is truly = critical (as =0A= some have argued here) in these applications, then that does not argue = in favor =0A= of SHA256/SHA512. The reasons for using SHA256+ must be cryptographic, = not =0A= performance based.
=0A=

=0A=
=0A= From: cfrg-bounces@ietf.org on = behalf of David =0A= Wagner
Sent: Fri 3/18/2005 11:35 AM
To: =0A= cfrg@ietf.org
Subject: Re: [Cfrg] Who needs = collision-resistance, =0A= anyway?

=0A=
=0A=

D. J. Bernstein wrote:
>Exercise for the reader: = SHA-512 =0A= has been a standard for years, and is
>obviously vastly more = difficult to =0A= break than MD5 and SHA-1. Can you
>explain why so few people are = using =0A= it?

I don't know how others choose between hash functions, but I = can tell =0A= you
some of my reasoning, if that is relevant.  I know SHA1 = well; I have =0A= spent
time trying to cryptanalyze SHA1; I have spoken to others who = have =0A= done
the same.  I can't say the same for SHA-256 or = SHA-512.  While =0A= SHA-256
or SHA-512 may well be better, that has made me reluctant to = switch =0A= to
a hash function that I understand less well.  However, I may = well =0A= be
forced to overcome my reluctance, given the recent results on =0A= SHA1.

_______________________________________________
Cfrg = mailing =0A= list
Cfrg@ietf.org
https://www1.ietf.or= g/mailman/listinfo/cfrg

=0A= =0A= =0A= ------_=_NextPart_001_01C52BF4.D49E72E9-- --===============1841597318== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg --===============1841597318==-- From cfrg-bounces@ietf.org Fri Mar 18 15:23:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21433 for ; Fri, 18 Mar 2005 15:23:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCO4N-0005eR-D7 for cfrg-web-archive@ietf.org; Fri, 18 Mar 2005 15:27:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCNvv-0005Tf-4K; Fri, 18 Mar 2005 15:18:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCNvt-0005Ta-NN for cfrg@megatron.ietf.org; Fri, 18 Mar 2005 15:18:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20885 for ; Fri, 18 Mar 2005 15:18:55 -0500 (EST) Received: from abraham.cs.berkeley.edu ([128.32.37.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCO0P-0005SL-68 for cfrg@ietf.org; Fri, 18 Mar 2005 15:23:37 -0500 Received: from news by abraham.cs.berkeley.edu with local (Exim 4.43) id 1DCNuV-0001f0-Q6 for cfrg@ietf.org; Fri, 18 Mar 2005 12:17:31 -0800 To: cfrg@ietf.org Path: not-for-mail From: daw@taverner.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ietf-cfrg Subject: Re: [Cfrg] Who needs collision-resistance, anyway? Date: Fri, 18 Mar 2005 20:17:31 +0000 (UTC) Organization: University of California, Berkeley Lines: 26 Distribution: isaac Message-ID: References: <198A730C2044DE4A96749D13E167AD37250096@MOU1WNEXMB04.vcorp.ad.vrsn.com> NNTP-Posting-Host: taverner.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1111177051 5433 128.32.168.222 (18 Mar 2005 20:17:31 GMT) X-Complaints-To: usenet@abraham.cs.berkeley.edu NNTP-Posting-Date: Fri, 18 Mar 2005 20:17:31 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: daw@taverner.cs.berkeley.edu (David Wagner) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Wagner List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Hallam-Baker, Phillip wrote: >One of the problematic aspects of RSA digital signatures is that they have >the property that every signature of the same message under the same key is >identical. This is not an ideal situation from the point of view of a >security protocol designer, [...] Out of curiousity, why? >I do not want the signature on a message to leak any information concerning >the contents. [...] In this case, the cleanest answer may be to sign something that doesn't leak any information about the contents, or to protect the confidentiality of the signature. For instance, sign a commitment to the message; a hash of the message; an encryption of the message. Or, encrypt the signature. (The right choice will depend on the details of the protocol.) Why do I suggest this? It is because I think it is usually unwise to rely on a signature scheme to provide anything more than what is guaranteed by the the standard definition of security of digital signatures, namely, security against chosen-message existential forgery attacks. If you want to assume something extra about the signature scheme, you are violating a layer of abstraction, so you may need to take extra precautions, and it will be easier to screw up. Usually it will be safer all around if you simply avoid breaking the abstraction boundary. _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Fri Mar 18 15:23:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21582 for ; Fri, 18 Mar 2005 15:23:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCO51-0005gB-Ig for cfrg-web-archive@ietf.org; Fri, 18 Mar 2005 15:28:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCNyc-0005w4-BO; Fri, 18 Mar 2005 15:21:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCNya-0005vY-R1 for cfrg@megatron.ietf.org; Fri, 18 Mar 2005 15:21:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21314 for ; Fri, 18 Mar 2005 15:21:42 -0500 (EST) Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCO34-0005WB-M6 for cfrg@ietf.org; Fri, 18 Mar 2005 15:26:24 -0500 Received: by machshav.com (Postfix, from userid 512) id D81F7FB262; Fri, 18 Mar 2005 15:21:35 -0500 (EST) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CCBCFFB246; Fri, 18 Mar 2005 15:21:34 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 8CF713C02A1; Fri, 18 Mar 2005 15:21:08 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: "Hallam-Baker, Phillip" Subject: Re: [Cfrg] Who needs collision-resistance, anyway? In-Reply-To: Your message of "Fri, 18 Mar 2005 11:54:57 PST." <198A730C2044DE4A96749D13E167AD37250096@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Mar 2005 15:21:07 -0500 Message-Id: <20050318202108.8CF713C02A1@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: cfrg@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 In message <198A730C2044DE4A96749D13E167AD37250096@MOU1WNEXMB04.vcorp.ad.vrsn.c om>, "Hallam-Baker, Phillip" writes: >I think that this discussion has got somewhat off track. > >There are good reasons for using an HMAC type construction to create a >digest that have nothing to do with the security issues with SHA1. > >One of the problematic aspects of RSA digital signatures is that they have >the property that every signature of the same message under the same key is >identical. This is not an ideal situation from the point of view of a >security protocol designer, there are many cases in which the fact that a >signature is identical is not ideal. Correct me if I'm wrong, but I thought that preference these days was to sign the ciphertext, not the plaintext. The presence of an IV in the encryption (or, for that matter, the use of a new key) will cause the ciphertext to vary, of course. (Yes, I know that S/MIME can do the signing and encryption in either order.) > >I do not want the signature on a message to leak any information concerning >the contents. This means that I don't have to worry about where the >signature is being stored when auditing for confidentiality protection. I hear you, and I'm not prepared to say you're wrong, though it would be nice to spend more time discussing the actual threat model. > >I note that the one digital signature function that the NSA has given us has >this property which is quite interesting in and of itself. > I wouldn't read too much into that. For one thing, they were very constrained; they really wanted a signature function that couldn't be used for secrecy. Second, the presence of the random number in DSA created a serious vulnerability: anyone who knew it could recover the secret key. --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Fri Mar 18 16:00:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01131 for ; Fri, 18 Mar 2005 16:00:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCOed-0000fn-Qg for cfrg-web-archive@ietf.org; Fri, 18 Mar 2005 16:05:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCOGA-0002hf-27; Fri, 18 Mar 2005 15:39:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCOG7-0002bL-U9 for cfrg@megatron.ietf.org; Fri, 18 Mar 2005 15:39:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24926 for ; Fri, 18 Mar 2005 15:39:49 -0500 (EST) Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCOKc-0006hL-6h for cfrg@ietf.org; Fri, 18 Mar 2005 15:44:31 -0500 Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id j2IKddOe022611; Fri, 18 Mar 2005 12:39:39 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 18 Mar 2005 12:39:39 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD37250098@MOU1WNEXMB04.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" To: "'Steven M. Bellovin'" Subject: RE: [Cfrg] Who needs collision-resistance, anyway? Date: Fri, 18 Mar 2005 12:39:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: cfrg@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a > From: Steven M. Bellovin [mailto:smb@cs.columbia.edu] > In message > <198A730C2044DE4A96749D13E167AD37250096@MOU1WNEXMB04.vcorp.ad.vrsn.c > om>, "Hallam-Baker, Phillip" writes: > Correct me if I'm wrong, but I thought that preference these days was > to sign the ciphertext, not the plaintext. The presence of an IV in > the encryption (or, for that matter, the use of a new key) will cause > the ciphertext to vary, of course. (Yes, I know that S/MIME > can do the > signing and encryption in either order.) That depends on what the security model is. Signing the ciphertext is only possible if you have end to end security. That model does not work in contexts where it is either difficult to identify the end or there is more than one end point. For example a Web Services mediated transaction can involve three, four any number of parties who have to be considered as fist class endpoints in respect to some part of the transaction I can imagine a lot of cases where signatures are going to end up stored in databases separately from the data that is signed. Signing a MAC has the interesting property that I have a signature that can only be verified if the verifyier knows the secret. This provides control over non-repudiation preventing a third party relying on data. > > > >I do not want the signature on a message to leak any information > >concerning the contents. This means that I don't have to worry about > >where the signature is being stored when auditing for > confidentiality > >protection. > > I hear you, and I'm not prepared to say you're wrong, though it would > be nice to spend more time discussing the actual threat model. > > > >I note that the one digital signature function that the NSA > has given > >us has this property which is quite interesting in and of itself. > > > I wouldn't read too much into that. For one thing, they were very > constrained; they really wanted a signature function that couldn't be > used for secrecy. Second, the presence of the random number in DSA > created a serious vulnerability: anyone who knew it could recover the > secret key. > > --Prof. Steven M. Bellovin, > http://www.cs.columbia.edu/~smb > > > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Fri Mar 18 16:39:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12164 for ; Fri, 18 Mar 2005 16:39:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCPGB-0004on-5A for cfrg-web-archive@ietf.org; Fri, 18 Mar 2005 16:43:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCPBL-0006jF-GY; Fri, 18 Mar 2005 16:38:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCPBK-0006j0-DV for cfrg@megatron.ietf.org; Fri, 18 Mar 2005 16:38:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12124 for ; Fri, 18 Mar 2005 16:38:55 -0500 (EST) Received: from igw2.watson.ibm.com ([129.34.20.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCPFp-0004nm-Nk for cfrg@ietf.org; Fri, 18 Mar 2005 16:43:39 -0500 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id j2ILclP286526 for ; Fri, 18 Mar 2005 16:38:47 -0500 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j2ILcla55100 for ; Fri, 18 Mar 2005 16:38:47 -0500 Received: from [127.0.0.1] (CRYPT01.watson.ibm.com [9.2.18.142]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j2ILckG62818 for ; Fri, 18 Mar 2005 16:38:46 -0500 Message-ID: <423B4A63.1070408@alum.mit.edu> Date: Fri, 18 Mar 2005 16:38:43 -0500 From: Shai Halevi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: cfrg@ietf.org References: <200503182100.j2IL06dr010493@alum-1.mit.edu> In-Reply-To: <200503182100.j2IL06dr010493@alum-1.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Subject: [Cfrg] Re: Is target-collision-resistance really harder than full collision-resistance? X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit "D. J. Bernstein" wrote: > Shai Halevi writes: >> So let's say that an attack is "feasible" is it works in at most (say) >> 2^{50} on-line calls, 2^{70} space and 2^{90} off-line computation time. >> I will be very surprised if you find a TCR-type attack on SHA1 >> with these parameters. > > > Hold it---you're cheating by changing the problem! I would argue that it is you who is changing the model. Regardless, changing the model is never cheating. This is what we do. > Suppose the attacker generates 250 messages m_1,m_2,...; the signer, in > response, generates 160-bit strings r_1,r_2,...; the attacker somehow > exploits the structure of SHA-1 to find (i,m') with m' different from > m_1,m_2,... and with SHA-1(r_i,m') = SHA-1(r_i,m_i). > > This is 100% successful as an attack on a signature system using > randomized SHA-1. It doesn't imply a feasible attack on TCR---there's a > massive 250 factor in the probability ratios! You can't casually use > polynomial equivalences if you're talking about constants. > > Will you be surprised when someone announces an attack of this type? I'll try to be a specific as I can: (a) Yes, I will be very surprised if someone announced such an attack within the parameters that I specified above (<= 2^50 signatures, 2^70 space, and 2^90 time). I even committed myself to buying wine in this case.. (b) I claim that if the problem with SHA1 would have only effected systems that grant more than 2^40 signatures, you would not see so much excitement about it (and you would see very little effort on the part of anyone to change the standards). And for a good reason: in most systems such an attack is not a real threat. Hence, it seems a good idea to design the next signature standards so that "these types of attacks" on their hash functions would indeed only result in theoretical attacks on the signature, not real attacks. (c) After all the brouhaha, I do not quite understand what are we arguing about. It it just that my definition from above of "feasible" attacks precludes things that DJB would consider legitimate attacks? -- Shai _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Fri Mar 18 16:45:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12618 for ; Fri, 18 Mar 2005 16:45:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCPMg-00054s-DK for cfrg-web-archive@ietf.org; Fri, 18 Mar 2005 16:50:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCPGi-0000QC-Rk; Fri, 18 Mar 2005 16:44:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCPGg-0000Q7-KU for cfrg@megatron.ietf.org; Fri, 18 Mar 2005 16:44:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12499 for ; Fri, 18 Mar 2005 16:44:27 -0500 (EST) Received: from mailgw4.technion.ac.il ([132.68.238.37]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCPLB-00052O-Ck for cfrg@ietf.org; Fri, 18 Mar 2005 16:49:11 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgw4.technion.ac.il (Postfix) with ESMTP id 90C8EF7A21 for ; Fri, 18 Mar 2005 23:38:30 +0200 (IST) (envelope-from hugo@ee.technion.ac.il) Received: from mailgw4.technion.ac.il ([127.0.0.1]) by localhost (mailgw4.technion.ac.il [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 08994-01-30 for ; Fri, 18 Mar 2005 23:38:30 +0200 (IST) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by mailgw4.technion.ac.il (Postfix) with ESMTP id 06C8AF7A1D for ; Fri, 18 Mar 2005 23:38:30 +0200 (IST) (envelope-from hugo@ee.technion.ac.il) Received: from ee.technion.ac.il (localhost [127.0.0.1]) by ee.technion.ac.il (8.12.10+Sun/8.12.2) with ESMTP id j2ILii4A012149; Fri, 18 Mar 2005 23:44:44 +0200 (IST) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.12.10+Sun/8.12.2/Submit) with ESMTP id j2ILiiDO012145; Fri, 18 Mar 2005 23:44:44 +0200 (IST) Date: Fri, 18 Mar 2005 23:44:44 +0200 (IST) From: Hugo Krawczyk To: "Hallam-Baker, Phillip" Subject: RE: [Cfrg] Who needs collision-resistance, anyway? In-Reply-To: <198A730C2044DE4A96749D13E167AD37250098@MOU1WNEXMB04.vcorp.ad.vrsn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: AAAAAQAAAAQ= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new at technion.ac.il X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: cfrg@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Phil, Using a randomized hash for a signature doesn't make the signed msg any more protected than with a regular hash. Since the "salt" is known then there is no "secret key" to protect your msg. In particular, if I have a guess of the message and you use RSA with a randomized hash I can still verify my guess. Hugo PS: Besides, I also recommend not to overload signatures with unnecessary requiremnts such as secrecy. It is difficult enough to get the signature schemes to do their essential job, so why add superflous requirements? On Fri, 18 Mar 2005, Hallam-Baker, Phillip wrote: > > > > From: Steven M. Bellovin [mailto:smb@cs.columbia.edu] > > > In message > > <198A730C2044DE4A96749D13E167AD37250096@MOU1WNEXMB04.vcorp.ad.vrsn.c > > om>, "Hallam-Baker, Phillip" writes: > > > Correct me if I'm wrong, but I thought that preference these days was > > to sign the ciphertext, not the plaintext.The presence of an IV in > > the encryption (or, for that matter, the use of a new key) will cause > > the ciphertext to vary, of course.(Yes, I know that S/MIME > > can do the > > signing and encryption in either order.) > > That depends on what the security model is. Signing the ciphertext is only > possible if you have end to end security. That model does not work in > contexts where it is either difficult to identify the end or there is more > than one end point. > > For example a Web Services mediated transaction can involve three, four any > number of parties who have to be considered as fist class endpoints in > respect to some part of the transaction > > I can imagine a lot of cases where signatures are going to end up stored in > databases separately from the data that is signed. > > Signing a MAC has the interesting property that I have a signature that can > only be verified if the verifyier knows the secret. This provides control > over non-repudiation preventing a third party relying on data. > > > > > > >I do not want the signature on a message to leak any information > > >concerning the contents. This means that I don't have to worry about > > >where the signature is being stored when auditing for > > confidentiality > > >protection. > > > > I hear you, and I'm not prepared to say you're wrong, though it would > > be nice to spend more time discussing the actual threat model. > > > > > >I note that the one digital signature function that the NSA > > has given > > >us has this property which is quite interesting in and of itself. > > > > > I wouldn't read too much into that.For one thing, they were very > > constrained; they really wanted a signature function that couldn't be > > used for secrecy.Second, the presence of the random number in DSA > > created a serious vulnerability: anyone who knew it could recover the > > secret key. > > > > --Prof. Steven M. Bellovin, > > http://www.cs.columbia.edu/~smb > > > > > > > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Fri Mar 18 18:54:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24245 for ; Fri, 18 Mar 2005 18:54:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCRMx-0001Tv-0j for cfrg-web-archive@ietf.org; Fri, 18 Mar 2005 18:59:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCRFD-0004kT-Rt; Fri, 18 Mar 2005 18:51:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCRFC-0004kL-7C for cfrg@megatron.ietf.org; Fri, 18 Mar 2005 18:51:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24017 for ; Fri, 18 Mar 2005 18:51:02 -0500 (EST) Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCRJi-0001Mw-CM for cfrg@ietf.org; Fri, 18 Mar 2005 18:55:47 -0500 Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id j2INouAA013774; Fri, 18 Mar 2005 15:50:56 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 18 Mar 2005 15:50:56 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD372500A0@MOU1WNEXMB04.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" To: "'Hugo Krawczyk'" Subject: RE: [Cfrg] Who needs collision-resistance, anyway? Date: Fri, 18 Mar 2005 15:50:43 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: cfrg@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 This is true if the MAC key is a salt is published in the sig, it is not true if the MAC key is a secret transported separately. I fail to see how you are able to determine that secrecy is a superfluous requirement in my applications when I have not told you what they are. > -----Original Message----- > From: Hugo Krawczyk [mailto:hugo@ee.technion.ac.il] > Sent: Friday, March 18, 2005 4:45 PM > To: Hallam-Baker, Phillip > Cc: cfrg@ietf.org > Subject: RE: [Cfrg] Who needs collision-resistance, anyway? > > > Phil, > > Using a randomized hash for a signature doesn't make the > signed msg any more protected than with a regular hash. Since > the "salt" is known then there is no "secret key" to protect > your msg. In particular, if I have a guess of the message and > you use RSA with a randomized hash I can still verify my guess. > > Hugo > > PS: Besides, I also recommend not to overload signatures with > unnecessary requiremnts such as secrecy. It is difficult > enough to get the signature schemes to do their essential > job, so why add superflous requirements? > > On Fri, 18 Mar 2005, Hallam-Baker, Phillip wrote: > > > > > > > > From: Steven M. Bellovin [mailto:smb@cs.columbia.edu] > > > > > In message > > > > <198A730C2044DE4A96749D13E167AD37250096@MOU1WNEXMB04.vcorp.ad.vrsn.c > > > om>, "Hallam-Baker, Phillip" writes: > > > > > Correct me if I'm wrong, but I thought that preference these days > > > was to sign the ciphertext, not the plaintext.The > presence of an IV > > > in the encryption (or, for that matter, the use of a new > key) will > > > cause the ciphertext to vary, of course.(Yes, I know that > S/MIME can > > > do the signing and encryption in either order.) > > > > That depends on what the security model is. Signing the > ciphertext is > > only possible if you have end to end security. That model does not > > work in contexts where it is either difficult to identify > the end or > > there is more than one end point. > > > > For example a Web Services mediated transaction can involve three, > > four any number of parties who have to be considered as fist class > > endpoints in respect to some part of the transaction > > > > I can imagine a lot of cases where signatures are going to end up > > stored in databases separately from the data that is signed. > > > > Signing a MAC has the interesting property that I have a signature > > that can only be verified if the verifyier knows the secret. This > > provides control over non-repudiation preventing a third > party relying > > on data. > > > > > > > > > >I do not want the signature on a message to leak any information > > > >concerning the contents. This means that I don't have to worry > > > >about where the signature is being stored when auditing for > > > confidentiality > > > >protection. > > > > > > I hear you, and I'm not prepared to say you're wrong, though it > > > would be nice to spend more time discussing the actual > threat model. > > > > > > > >I note that the one digital signature function that the NSA > > > has given > > > >us has this property which is quite interesting in and of itself. > > > > > > > I wouldn't read too much into that.For one thing, they were very > > > constrained; they really wanted a signature function that > couldn't > > > be used for secrecy.Second, the presence of the random > number in DSA > > > created a serious vulnerability: anyone who knew it could recover > > > the secret key. > > > > > > --Prof. Steven M. Bellovin, > http://www.cs.columbia.edu/~smb > > > > > > > > > > > > > > _______________________________________________ > > Cfrg mailing list > > Cfrg@ietf.org > > https://www1.ietf.org/mailman/listinfo/cfrg > > > > > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Fri Mar 18 19:19:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26456 for ; Fri, 18 Mar 2005 19:19:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCRlb-0002aK-Eh for cfrg-web-archive@ietf.org; Fri, 18 Mar 2005 19:24:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCRdh-00039R-VJ; Fri, 18 Mar 2005 19:16:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCRdf-00039J-PV for cfrg@megatron.ietf.org; Fri, 18 Mar 2005 19:16:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26313 for ; Fri, 18 Mar 2005 19:16:20 -0500 (EST) Received: from mailgw4.technion.ac.il ([132.68.238.37]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCRiC-0002Qn-RR for cfrg@ietf.org; Fri, 18 Mar 2005 19:21:05 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgw4.technion.ac.il (Postfix) with ESMTP id 3A349F7A29 for ; Sat, 19 Mar 2005 02:10:26 +0200 (IST) (envelope-from hugo@ee.technion.ac.il) Received: from mailgw4.technion.ac.il ([127.0.0.1]) by localhost (mailgw4.technion.ac.il [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10353-01 for ; Sat, 19 Mar 2005 02:10:26 +0200 (IST) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by mailgw4.technion.ac.il (Postfix) with ESMTP id 63C97F792D for ; Sat, 19 Mar 2005 02:10:25 +0200 (IST) (envelope-from hugo@ee.technion.ac.il) Received: from ee.technion.ac.il (localhost [127.0.0.1]) by ee.technion.ac.il (8.12.10+Sun/8.12.2) with ESMTP id j2J0Fp4A028817; Sat, 19 Mar 2005 02:15:51 +0200 (IST) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.12.10+Sun/8.12.2/Submit) with ESMTP id j2J0FodX028813; Sat, 19 Mar 2005 02:15:51 +0200 (IST) Date: Sat, 19 Mar 2005 02:15:50 +0200 (IST) From: Hugo Krawczyk To: "Hallam-Baker, Phillip" Subject: RE: [Cfrg] Who needs collision-resistance, anyway? In-Reply-To: <198A730C2044DE4A96749D13E167AD372500A0@MOU1WNEXMB04.vcorp.ad.vrsn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: AAAAAQAAAAQ= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new at technion.ac.il X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: cfrg@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 On Fri, 18 Mar 2005, Hallam-Baker, Phillip wrote: > This is true if the MAC key is a salt is published in the sig, it is not > true if the MAC key is a secret transported separately. > > I fail to see how you are able to determine that secrecy is a superfluous > requirement in my applications when I have nottold you what they are. I was not trying to say anything about your specific applications which I do not know and may well need secrecy. My point was, and excuse me if it came across differently, that adding secrecy to the basic requirments of signatures (as a basic cryptographic primitive) is not a good idea. Signatures are essentially about binding a document to a cryptographic key (and transitively to a signer) and not about hiding the document. Applications that need secrecy should provide it by specific and explicit means. Hugo > > > > > -----Original Message----- > > From: Hugo Krawczyk [mailto:hugo@ee.technion.ac.il] > > Sent: Friday, March 18, 2005 4:45 PM > > To: Hallam-Baker, Phillip > > Cc: cfrg@ietf.org > > Subject: RE: [Cfrg] Who needs collision-resistance, anyway? > > > > > > Phil, > > > > Using a randomized hash for a signature doesn't make the > > signed msg any more protected than with a regular hash. Since > > the "salt" is known then there is no "secret key" to protect > > your msg. In particular, if I have a guess of the message and > > you use RSA with a randomized hash I can still verify my guess. > > > > Hugo > > > > PS: Besides, I also recommend not to overload signatures with > > unnecessary requiremnts such as secrecy. It is difficult > > enough to get the signature schemes to do their essential > > job, so why add superflous requirements? > > > > On Fri, 18 Mar 2005, Hallam-Baker, Phillip wrote: > > > > > > > > > > > > From: Steven M. Bellovin [mailto:smb@cs.columbia.edu] > > > > > > > In message > > > > > > <198A730C2044DE4A96749D13E167AD37250096@MOU1WNEXMB04.vcorp.ad.vrsn.c > > > > om>, "Hallam-Baker, Phillip" writes: > > > > > > > Correct me if I'm wrong, but I thought that preference these days > > > > was to sign the ciphertext, not the plaintext.The > > presence of an IV > > > > in the encryption (or, for that matter, the use of a new > > key) will > > > > cause the ciphertext to vary, of course.(Yes, I know that > > S/MIME can > > > > do the signing and encryption in either order.) > > > > > > That depends on what the security model is. Signing the > > ciphertext is > > > only possible if you have end to end security. That model does not > > > work in contexts where it is either difficult to identify > > the end or > > > there is more than one end point. > > > > > > For example a Web Services mediated transaction can involve three, > > > four any number of parties who have to be considered as fist class > > > endpoints in respect to some part of the transaction > > > > > > I can imagine a lot of cases where signatures are going to end up > > > stored in databases separately from the data that is signed. > > > > > > Signing a MAC has the interesting property that I have a signature > > > that can only be verified if the verifyier knows the secret. This > > > provides control over non-repudiation preventing a third > > party relying > > > on data. > > > > > > > > > > > > >I do not want the signature on a message to leak any information > > > > >concerning the contents. This means that I don't have to worry > > > > >about where the signature is being stored when auditing for > > > > confidentiality > > > > >protection. > > > > > > > > I hear you, and I'm not prepared to say you're wrong, though it > > > > would be nice to spend more time discussing the actual > > threat model. > > > > > > > > > >I note that the one digital signature function that the NSA > > > > has given > > > > >us has this property which is quite interesting in and of itself. > > > > > > > > > I wouldn't read too much into that.For one thing, they were very > > > > constrained; they really wanted a signature function that > > couldn't > > > > be used for secrecy.Second, the presence of the random > > number in DSA > > > > created a serious vulnerability: anyone who knew it could recover > > > > the secret key. > > > > > > > > --Prof. Steven M. Bellovin, > > http://www.cs.columbia.edu/~smb > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Cfrg mailing list > > > Cfrg@ietf.org > > > https://www1.ietf.org/mailman/listinfo/cfrg > > > > > > > > > > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Sat Mar 19 03:26:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24206 for ; Sat, 19 Mar 2005 03:26:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCZM8-0003SM-7R for cfrg-web-archive@ietf.org; Sat, 19 Mar 2005 03:30:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCZFp-00025Q-0p; Sat, 19 Mar 2005 03:24:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCZFn-00024p-1N for cfrg@megatron.ietf.org; Sat, 19 Mar 2005 03:24:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24075 for ; Sat, 19 Mar 2005 03:24:12 -0500 (EST) Received: from abraham.cs.berkeley.edu ([128.32.37.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCZKO-0003JB-Eh for cfrg@ietf.org; Sat, 19 Mar 2005 03:29:00 -0500 Received: from news by abraham.cs.berkeley.edu with local (Exim 4.43) id 1DCZEM-0000Yh-5v for cfrg@ietf.org; Sat, 19 Mar 2005 00:22:46 -0800 To: cfrg@ietf.org Path: not-for-mail From: daw@taverner.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ietf-cfrg Subject: Re: [Cfrg] Who needs collision-resistance, anyway? Date: Sat, 19 Mar 2005 08:22:46 +0000 (UTC) Organization: University of California, Berkeley Lines: 14 Distribution: isaac Message-ID: References: <20050318003039.14706.qmail@cr.yp.to> <20050318032446.17834.qmail@cr.yp.to> <20050318045632.19094.qmail@cr.yp.to> NNTP-Posting-Host: taverner.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1111220566 1758 128.32.168.222 (19 Mar 2005 08:22:46 GMT) X-Complaints-To: usenet@abraham.cs.berkeley.edu NNTP-Posting-Date: Sat, 19 Mar 2005 08:22:46 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: daw@taverner.cs.berkeley.edu (David Wagner) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Wagner List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 D. J. Bernstein wrote: >Whenever you see people using SHA-1(m), do you tell them to switch not >just to SHA-1(r,m) but to (SHA-1(r,m),SHA-512(r,m))? After all, if you >don't care about cost, then concatenating SHA-512 is clearly harmless, [...] A minor nitpick: Concatenating hashes is not necessarily harmless. It is harmless to collision-resistance, because the concatenation is as strong as the stronger of the two components when it comes to collision-resistance. However, it might (at least in principle) be harmful to one-wayness, because the concatenation is only as strong as the weaker of the two components when it comes to one-wayness. This is tangential to your main point, but I thought I'd bring it up, as it illustrates that combining two hash functions is not an entirely trivial task. _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Sat Mar 19 03:54:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26310 for ; Sat, 19 Mar 2005 03:54:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCZnz-0004Qu-8W for cfrg-web-archive@ietf.org; Sat, 19 Mar 2005 03:59:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCZhp-0000fq-9M; Sat, 19 Mar 2005 03:53:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCZhK-0000bY-NC for cfrg@megatron.ietf.org; Sat, 19 Mar 2005 03:52:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26155 for ; Sat, 19 Mar 2005 03:52:40 -0500 (EST) Received: from abraham.cs.berkeley.edu ([128.32.37.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCZlw-0004Og-Su for cfrg@ietf.org; Sat, 19 Mar 2005 03:57:29 -0500 Received: from news by abraham.cs.berkeley.edu with local (Exim 4.43) id 1DCZfx-0001of-0b for cfrg@ietf.org; Sat, 19 Mar 2005 00:51:17 -0800 To: cfrg@ietf.org Path: not-for-mail From: daw@taverner.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ietf-cfrg Subject: Re: [Cfrg] Who needs collision-resistance, anyway? Date: Sat, 19 Mar 2005 08:51:16 +0000 (UTC) Organization: University of California, Berkeley Lines: 65 Distribution: isaac Message-ID: References: <20050318003039.14706.qmail@cr.yp.to> <20050318032446.17834.qmail@cr.yp.to> <20050318045632.19094.qmail@cr.yp.to> NNTP-Posting-Host: taverner.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1111222276 6984 128.32.168.222 (19 Mar 2005 08:51:16 GMT) X-Complaints-To: usenet@abraham.cs.berkeley.edu NNTP-Posting-Date: Sat, 19 Mar 2005 08:51:16 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: daw@taverner.cs.berkeley.edu (David Wagner) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Wagner List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 D. J. Bernstein wrote: >Generating random numbers isn't free. Furthermore, transmitting random >numbers costs bandwidth. Furthermore, in many applications, signature >_verification_ happens much more frequently than signature computation. Thanks for articulating the costs that you were concerned about. But I still don't see what the problem is. For many applications, this just doesn't sound like a big deal. Let's try to analyze the costs quantitatively. How long a salt do we need? 80 bits seems likely to be more than adequate. It will be possible to break the UOWHF/TCF properties in an online attack requiring on the order of 2^80 chosen messages, but such attacks seem totally infeasible. 80 bits may be overkill, and many applications may be able to get by with shorter applications (say, 64-bit salts), but let's go with the 80-bit figure for now. Is the bandwidth overhead significant? No, probably not. If we use 2048-bit RSA, then a 80-bit salt adds 4% overhead to signature sizes. If we use 1024-bit RSA, then a 64-bit salt adds 6% overhead to signature sizes. If we use 512-bit RSA, we're screwed anyway. Overheads of this magnitude seem unlikely to be a big deal for most applications. Of course, there are certainly some signature schemes where the overhead is much larger. For instance, if we are using 160-bit ECC with point compression in an effort to minimize signature sizes, then an 80-bit salt adds 50% overhead to signature sizes -- which is likely to be unacceptable to systems that are sensitive to signature sizes. So for some systems, randomization will be inappropriate because of its bandwidth overhead. Is the latency overhead significant? I doubt it, for most applications. The cost of hashing 80 extra bits is a few hundred cycles, which is negligible compared to the cost of signature generation. As for signature verification, `openssl speed rsa1024` says my CPU takes about a hundred thousand cycles per 1024-bit RSA signature verification operation. This means that the latency cost of randomization would be essentially negligible for these signature schemes. Of course, there may be the occasional signature scheme where the CPU cost of randomization is not entirely negligible. Perhaps the signature scheme with the fastest secure verification is 1024-bit Rabin (or variants). How fast is signature verification with such schemes? Thousands of cycles? If so, randomization would contribute a 10% overhead to the time to perform a signature verification -- non-negligible, to be sure, but whether that is a showstopper will depend on the application. Is the cost of generating random bits significant? I don't see how it could be. Just use a PRG. Any crypto implementation already needs crypto-strength (pseudo)random bits for other purposes anyway. I honestly don't see what the issue here might be. My tentative conclusion: The costs seem likely to be small for most applications. For a few applications which try to squeeze out every last cycle of CPU and every last bit of signature length -- applications where performance is of absolute paramount importance -- randomization will be inappropriate. Those applications will need to find some other defense against collision attacks on the hash function, or will need to accept the higher level of risk. However, for most applications -- applications where security is a higher priority -- randomization seems like a reasonable countermeasure to have in your toolbox. _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Sat Mar 19 04:33:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28311 for ; Sat, 19 Mar 2005 04:33:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCaPj-0005u9-60 for cfrg-web-archive@ietf.org; Sat, 19 Mar 2005 04:38:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCaJH-0001xJ-D8; Sat, 19 Mar 2005 04:31:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCaJF-0001ux-AJ for cfrg@megatron.ietf.org; Sat, 19 Mar 2005 04:31:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28236 for ; Sat, 19 Mar 2005 04:31:51 -0500 (EST) Received: from stoneport.math.uic.edu ([131.193.178.160]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DCaNr-0005sb-VZ for cfrg@ietf.org; Sat, 19 Mar 2005 04:36:40 -0500 Received: (qmail 48081 invoked by uid 1016); 19 Mar 2005 09:32:21 -0000 Date: 19 Mar 2005 09:32:21 -0000 Message-ID: <20050319093221.48080.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: cfrg@ietf.org Subject: Re: [Cfrg] Re: Is target-collision-resistance really harder than full collision-resistance? References: <200503182100.j2IL06dr010493@alum-1.mit.edu> <423B4A63.1070408@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Shai Halevi writes: > I would argue that it is you who is changing the model. Excuse me? I've consistently focused on the probability of a successful forgery in these systems. That's what users care about. In particular, forgery by hash collision is a multiple-input version of TCR. You oversimplified the problem by switching to traditional TCR---which is a single-input problem, and which therefore ignores a factor of 2^20 if there are 2^20 signed messages, a factor of 2^40 if there are 2^40 signed messages, etc. Theoreticians often gloss over this point because, hey, it's just a polynomial factor. But if you're going to make concrete predictions then you have to stop switching problems. Here, once again, is the right problem. Give messages m_1, m_2, ... to the signer, who responds with uniform random 160-bit strings r_1, r_2, ...; then find a message m' and an integer i such that m' is different from m_1, m_2, ... while SHA-1(r_i,m_i) = SHA-1(r_i,m'). Do I correctly understand that you think that this is much harder than merely finding SHA-1 collisions? Specifically, that you're offering a bottle of wine for any algorithm that does it with 2^50 messages, 2^70 bytes of storage, and 2^90 operations of comparable complexity to SHA-1? > (c) After all the brouhaha, I do not quite understand what are we > arguing about. The usual issues: cost and security. The cost issues are reasonably clear (although I see that some people are still confused). Randomization is not free. The costs of randomized MD5 and randomized SHA-1 are far above the costs of deterministic MD5 and deterministic SHA-1; they're much more like the costs of deterministic SHA-256. The security argument hasn't been settled but I think we've boiled it down to a simple question for the cryptanalysts. Two people are claiming that randomized MD5 and SHA-1 are much stronger than deterministic MD5 and SHA-1 (although nobody seems willing to claim that they're as strong as deterministic SHA-256). I think this position will be shredded by cryptanalysis of randomized MD5. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Sat Mar 19 05:24:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01963 for ; Sat, 19 Mar 2005 05:24:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCbCz-0007m2-CW for cfrg-web-archive@ietf.org; Sat, 19 Mar 2005 05:29:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCb65-0005yD-SV; Sat, 19 Mar 2005 05:22:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCb62-0005wO-4c for cfrg@megatron.ietf.org; Sat, 19 Mar 2005 05:22:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01791 for ; Sat, 19 Mar 2005 05:22:15 -0500 (EST) Received: from stoneport.math.uic.edu ([131.193.178.160]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DCbAf-0007fu-BR for cfrg@ietf.org; Sat, 19 Mar 2005 05:27:05 -0500 Received: (qmail 2535 invoked by uid 1016); 19 Mar 2005 10:22:46 -0000 Date: 19 Mar 2005 10:22:46 -0000 Message-ID: <20050319102246.2534.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: cfrg@ietf.org Subject: Re: [Cfrg] Who needs collision-resistance, anyway? References: <20050318003039.14706.qmail@cr.yp.to> <20050318032446.17834.qmail@cr.yp.to> <20050318045632.19094.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 David Wagner writes: > 80 bits seems likely to be more than adequate. Will you be surprised when 64-bit-randomized MD5 and 80-bit-randomized SHA-1 are broken? I certainly won't. > It will be possible to break the UOWHF/TCF properties > in an online attack requiring on the order of 2^80 chosen messages, > but such attacks seem totally infeasible. I wonder how many times I'm going to have to say ``TCR is the wrong problem'' before it sinks in. > If we use 1024-bit RSA, then a 64-bit salt adds 6% overhead to > signature sizes. You're drawing a completely inaccurate picture of the state of the art. 1024-bit Rabin-Williams signatures with Bleichenbacher compression take only 520 bits. Furthermore, other types of signatures are even smaller. Furthermore, as noted above, everyone else is talking about 160 bits of randomization. Similar comments apply to your discussion of verification speed. > Is the cost of generating random bits significant? I don't see how > it could be. Just use a PRG. Funny, I don't see a ``PRG'' feature in my RSA chip. Yes, we can compute MD5(r,m) where r is MD5(s,m) and s is a secret, but that's more than twice as expensive as computing MD5(m). > My tentative conclusion: The costs seem likely to be small for most > applications. It's pointless to discuss this unless you define ``small.'' Is the cost of switching to SHA-256 ``small''? How about SHA-512? If randomized MD5 is more expensive than deterministic SHA-256, and if nobody is willing to claim that it's as secure as deterministic SHA-256, then switching to randomized MD5 is obviously silly. Your response might be that we should use _randomized_ SHA-256. But if randomized SHA-256 is more expensive than deterministic SHA-512, and if nobody is willing to claim that randomized SHA-256 is as secure as deterministic SHA-512, then switching to randomized SHA-256 is obviously silly. What some people keep doing wrong in this discussion is comparing the (speculative) security of randomized MD5 to the (pathetic) security of deterministic MD5---as if those were the only two options! There are, in fact, many options at each cost level. Saying ``We think you can achieve higher security at higher cost'' is content-free; it is of no help for users choosing a system. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Sat Mar 19 23:50:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22952 for ; Sat, 19 Mar 2005 23:50:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCsTX-00056d-Cm for cfrg-web-archive@ietf.org; Sat, 19 Mar 2005 23:55:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCsMT-0001wy-RH; Sat, 19 Mar 2005 23:48:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCsMS-0001wt-0Z for cfrg@megatron.ietf.org; Sat, 19 Mar 2005 23:48:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22776 for ; Sat, 19 Mar 2005 23:48:21 -0500 (EST) Received: from vms048pub.verizon.net ([206.46.252.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCsRE-0004yo-S4 for cfrg@ietf.org; Sat, 19 Mar 2005 23:53:21 -0500 Received: from HP752c ([68.237.1.169]) by vms048.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IDM00A7MW0BACR0@vms048.mailsrvcs.net> for cfrg@ietf.org; Sat, 19 Mar 2005 22:48:12 -0600 (CST) Date: Sat, 19 Mar 2005 23:48:14 -0500 From: "Shai Halevi" In-reply-to: <200503191708.j2JH86OT001776@alum-2.mit.edu> To: Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Subject: [Cfrg] RE: Who needs collision-resistance, anyway? X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit "D. J. Bernstein" wrote (in his usual aggressive style): > Excuse me? [...] > Here, once again, is the right problem. Give messages m_1, m_2, ... to > the signer, who responds with uniform random 160-bit strings r_1, r_2, > ...; then find a message m' and an integer i such that m' is different > from m_1, m_2, ... while SHA-1(r_i,m_i) = SHA-1(r_i,m'). It is exactly in these "..." after m_2, r_2 that you are missing something. The number which is hidden in these ... is the on-line cost for the attacker. This is usually considered a much more expensive resource than off-line computation, and rightly so. (I don't know if you have ever taken the issue with people who actually try to break systems in the real world, but they would typically trade you quite a bit of off-line computation to save on every bit of interaction.) > Do I correctly understand that you think that this is much harder than > merely finding SHA-1 collisions? Specifically, that you're offering a > bottle of wine for any algorithm that does it with 2^50 messages, 2^70 > bytes of storage, and 2^90 operations of comparable complexity to SHA-1? Yes, I tried to say it as clearly as I can. And just to be even more specific, I consider an attack algorithm to be successful in the metric above if it produces a valid forged signature (or a collision) with probability at least 1/2. > > (c) After all the brouhaha, I do not quite understand what are we > > arguing about. > > The usual issues: cost and security. > > The cost issues are reasonably clear (although I see that some people > are still confused). Randomization is not free. The costs of randomized > MD5 and randomized SHA-1 are far above the costs of deterministic MD5 > and deterministic SHA-1; they're much more like the costs of > deterministic SHA-256. Yes, you keep saying this, and these confused people keep telling you that this is typically wrong. Most systems have no problem coming up with pseudo-random bits. And if push comes to shove, this is also the easiest thing to speed-up, e.g., by producing much of it off-line, or by adding a bit of hardware. It is certainly easier than speeding up your hash function, which has to depend on the message. (This is the thing about common perceptions, there are very often right on the mark :) > I wonder how many times I'm going to have to say ``TCR is the wrong > problem'' before it sinks in. I guess that it doesn't really matter how many time you say it, it just remains wrong. Using a TCR hash function for signatures has an advantage over relying on full collision-resistance, in that it shifts much of the cost from off-line computation to on-line interaction with the signer. > Funny, I don't see a ``PRG'' feature in my RSA chip. Try buying another chip? Sometimes they come with an API for (pseudo) randomness. > If randomized MD5 is more expensive than deterministic SHA-256, and if > nobody is willing to claim that it's as secure as deterministic SHA-256, > then switching to randomized MD5 is obviously silly. Wow, I actually agree with this (with the conclusion, that is, not the assertions). I would suggest switching to randomized -256. You'd find that the overhead in randomizing is dwarfed by the overhead in changing the standard yet again if/when some new cryptanalytic technique finds flaws in -256. > Your response might be that we should use _randomized_ SHA-256. But if > randomized SHA-256 is more expensive than deterministic SHA-512, and if > nobody is willing to claim that randomized SHA-256 is as secure as > deterministic SHA-512, then switching to randomized SHA-256 is obviously > silly. ok, I knew it was too good to last long. Arguing that randomized SHA-256 is more expensive than deterministic SHA-512 is a very hard sell. I don't believe it for a minute. _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Sun Mar 20 09:09:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18204 for ; Sun, 20 Mar 2005 09:09:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DD1CK-00065O-2P for cfrg-web-archive@ietf.org; Sun, 20 Mar 2005 09:14:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DD14z-0007Eb-7f; Sun, 20 Mar 2005 09:06:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DD14x-0007EV-1A for cfrg@megatron.ietf.org; Sun, 20 Mar 2005 09:06:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18078 for ; Sun, 20 Mar 2005 09:06:53 -0500 (EST) Received: from stoneport.math.uic.edu ([131.193.178.160]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DD19n-00060O-Pk for cfrg@ietf.org; Sun, 20 Mar 2005 09:11:57 -0500 Received: (qmail 1695 invoked by uid 1016); 20 Mar 2005 14:07:21 -0000 Date: 20 Mar 2005 14:07:21 -0000 Message-ID: <20050320140721.1694.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: cfrg@ietf.org Subject: Re: [Cfrg] RE: Who needs collision-resistance, anyway? References: <200503191708.j2JH86OT001776@alum-2.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Shai Halevi writes: > Arguing that randomized SHA-256 is more expensive than deterministic > SHA-512 is a very hard sell. Costs are supposed to be measured, not ``sold.'' When I'm fitting a signed message into a tiny DNS packet, I can't afford the space overhead of a big r; and PSS overhead turns out to take more cycles than SHA-512. > > I wonder how many times I'm going to have to say ``TCR is the wrong > > problem'' before it sinks in. > I guess that it doesn't really matter how many time you say it, it just > remains wrong. Using a TCR hash function for signatures Here we go again. The signature systems that you're advocating are _not_ based on TCR. You do _not_ have tight reductions between hash-collision forgeries and TCR. (It shouldn't be hard to prove that no such reductions exist.) The attacker is _not_ faced with an uncontrolled value h and the task of finding m such that MD5(m) = h. In short, TCR is the wrong problem. I'm still wondering how many times I'm going to have to say this before it sinks in. Hash-collision forgeries in your system are equivalent to a _different_ problem. That problem is, presumably, much easier than TCR, and I fully expect it to be solved for MD5. The attacker gets to maliciously choose (say) m_1,m_2,...,m_{2^40} to exploit the MD5 structure, and then find m',i such that MD5(r_i,m') matches MD5(r_i,m_i), where r_1,r_2,... are the signer's short random prefixes. At this point you've made clear that you have a different opinion regarding the difficulty of this problem. You've settled on a concrete challenge for cryptanalysts; fine. But it is simply _wrong_ for you to equate this problem with TCR. It was wrong for you to claim that a TCR challenge was relevant, and it is wrong for you to again talk about TCR as the foundation of a signature system. TCR is the wrong problem. I'm reminded of the following common argument: Blum-Blum-Shub is secure if factorization is difficult; we assume that factoring 2048-bit numbers is difficult; we conclude that 2048-bit Blum-Blum-Shub is secure. That argument is wrong. Breaking BBS could be much easier than factoring the modulus. The proven equivalence disregards huge polynomial factors. If you want to understand concrete BBS security, factorization is the wrong problem. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Sun Mar 20 16:07:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22387 for ; Sun, 20 Mar 2005 16:07:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DD7ic-0001mu-L3 for cfrg-web-archive@ietf.org; Sun, 20 Mar 2005 16:12:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DD7ae-0006Zp-5t; Sun, 20 Mar 2005 16:04:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DD7ad-0006Zk-3s for cfrg@megatron.ietf.org; Sun, 20 Mar 2005 16:04:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22103 for ; Sun, 20 Mar 2005 16:04:00 -0500 (EST) Received: from saria.randombit.net ([66.179.181.167] helo=mail.randombit.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DD7fX-0001g1-G4 for cfrg@ietf.org; Sun, 20 Mar 2005 16:09:08 -0500 Received: by mail.randombit.net (Postfix, from userid 501) id 8958B247C03A; Sun, 20 Mar 2005 14:03:49 -0700 (MST) Date: Sun, 20 Mar 2005 14:03:49 -0700 From: Jack Lloyd To: cfrg@ietf.org Subject: Re: [Cfrg] RE: Who needs collision-resistance, anyway? Message-ID: <20050320210349.GB1952@randombit.net> Mail-Followup-To: cfrg@ietf.org References: <200503191708.j2JH86OT001776@alum-2.mit.edu> <20050320140721.1694.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050320140721.1694.qmail@cr.yp.to> X-PGP-Fingerprint: 3F69 2E64 6D92 3BBE E7AE 9258 5C0F 96E8 4EC1 6D6B X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 On Sun, Mar 20, 2005 at 02:07:21PM -0000, D. J. Bernstein wrote: > Shai Halevi writes: > > Arguing that randomized SHA-256 is more expensive than deterministic > > SHA-512 is a very hard sell. > > Costs are supposed to be measured, not ``sold.'' When I'm fitting a > signed message into a tiny DNS packet, I can't afford the space overhead > of a big r; and PSS overhead turns out to take more cycles than SHA-512. And when I'm hashing 10 gigabytes of data on my x86 box, SHA-256 with 80 bits of r is several times faster than SHA-512. Costs are not universal. -Jack _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Sun Mar 20 19:03:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06464 for ; Sun, 20 Mar 2005 19:03:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDATQ-0007ES-1s for cfrg-web-archive@ietf.org; Sun, 20 Mar 2005 19:08:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDANX-0002BM-8I; Sun, 20 Mar 2005 19:02:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDANV-0002BE-SB for cfrg@megatron.ietf.org; Sun, 20 Mar 2005 19:02:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06423 for ; Sun, 20 Mar 2005 19:02:38 -0500 (EST) Received: from abraham.cs.berkeley.edu ([128.32.37.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDASQ-0007Dj-Pk for cfrg@ietf.org; Sun, 20 Mar 2005 19:07:49 -0500 Received: from news by abraham.cs.berkeley.edu with local (Exim 4.43) id 1DDAM3-0006k5-Gi for cfrg@ietf.org; Sun, 20 Mar 2005 16:01:11 -0800 To: cfrg@ietf.org Path: not-for-mail From: daw@taverner.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ietf-cfrg Subject: Re: [Cfrg] RE: Who needs collision-resistance, anyway? Date: Mon, 21 Mar 2005 00:01:11 +0000 (UTC) Organization: University of California, Berkeley Lines: 22 Distribution: isaac Message-ID: References: <200503191708.j2JH86OT001776@alum-2.mit.edu> <20050320140721.1694.qmail@cr.yp.to> NNTP-Posting-Host: taverner.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1111363271 22106 128.32.168.222 (21 Mar 2005 00:01:11 GMT) X-Complaints-To: usenet@abraham.cs.berkeley.edu NNTP-Posting-Date: Mon, 21 Mar 2005 00:01:11 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: daw@taverner.cs.berkeley.edu (David Wagner) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Wagner List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a D. J. Bernstein wrote: >In short, TCR is the wrong problem. I'm still wondering how many times >I'm going to have to say this before it sinks in. > >Hash-collision forgeries in your system are equivalent to a _different_ >problem. That problem is, presumably, much easier than TCR, and I fully >expect it to be solved for MD5. The attacker gets to maliciously choose >(say) m_1,m_2,...,m_{2^40} to exploit the MD5 structure, and then find >m',i such that MD5(r_i,m') matches MD5(r_i,m_i), where r_1,r_2,... are >the signer's short random prefixes. You've said it several times now, and I still don't understand why TCR is the wrong problem. If the attacker cannot break the single-instance TCR property with greater than \epsilon probability, then the attacker cannot break the 2^40-instance TCR property with greater than 2^40 * \epsilon probability. I wouldn't use MD5. But if you use SHA1, it may well be reasonable to hope that SHA1 is single-instance TCR-secure with \epsilon << 2^-40, i.e., that it is 2^40-instance TCR-secure. We may have to see how the latest cryptanalytic techniques work before we can form a definitive opinion, of course. _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Sun Mar 20 20:06:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11303 for ; Sun, 20 Mar 2005 20:06:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDBRw-0000js-M3 for cfrg-web-archive@ietf.org; Sun, 20 Mar 2005 20:11:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDBLq-0000g4-Tz; Sun, 20 Mar 2005 20:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDBLp-0000fq-7n for cfrg@megatron.ietf.org; Sun, 20 Mar 2005 20:05:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11246 for ; Sun, 20 Mar 2005 20:04:57 -0500 (EST) Received: from stoneport.math.uic.edu ([131.193.178.160]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DDBQl-0000j1-FK for cfrg@ietf.org; Sun, 20 Mar 2005 20:10:09 -0500 Received: (qmail 25128 invoked by uid 1016); 21 Mar 2005 01:05:24 -0000 Date: 21 Mar 2005 01:05:23 -0000 Message-ID: <20050321010523.25127.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: cfrg@ietf.org Subject: Re: [Cfrg] RE: Who needs collision-resistance, anyway? References: <200503191708.j2JH86OT001776@alum-2.mit.edu> <20050320140721.1694.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d David Wagner writes: > I wouldn't use MD5. This is a curious inconsistency. You seem to believe that randomized SHA-1 is much harder to break than deterministic SHA-1, so why don't you believe that randomized MD5 is much harder to break than deterministic MD5? Similarly, why is Halevi unwilling to offer a reward for a break in randomized MD5? Perhaps there's some magic dividing line between the 2^30ish operations used to find an MD5 collision and the 2^66ish operations used to find a SHA-1 collision. How far would the SHA-1 collision complexity have to drop before you lost confidence in randomized SHA-1, the same way that you've lost confidence in randomized MD5? > the attacker cannot break the 2^40-instance TCR property with greater > than 2^40 * \epsilon probability. 2^40 is a huge factor. (Also, 2^40-instance TCR is still not exactly the right problem---even with an n-bit prefix, why are you so sure that the n bits of output are uniform? But this is a relatively minor point.) ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Sun Mar 20 20:35:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13010 for ; Sun, 20 Mar 2005 20:35:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDBtt-0001ai-4E for cfrg-web-archive@ietf.org; Sun, 20 Mar 2005 20:40:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDBmm-0003KP-UX; Sun, 20 Mar 2005 20:32:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDBmk-0003KG-8b for cfrg@megatron.ietf.org; Sun, 20 Mar 2005 20:32:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12680 for ; Sun, 20 Mar 2005 20:32:48 -0500 (EST) Received: from abraham.cs.berkeley.edu ([128.32.37.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDBrh-0001R6-4k for cfrg@ietf.org; Sun, 20 Mar 2005 20:37:58 -0500 Received: from news by abraham.cs.berkeley.edu with local (Exim 4.43) id 1DDBlJ-0002LJ-Hr for cfrg@ietf.org; Sun, 20 Mar 2005 17:31:21 -0800 To: cfrg@ietf.org Path: not-for-mail From: daw@taverner.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ietf-cfrg Subject: Re: [Cfrg] RE: Who needs collision-resistance, anyway? Date: Mon, 21 Mar 2005 01:31:21 +0000 (UTC) Organization: University of California, Berkeley Lines: 32 Distribution: isaac Message-ID: References: <200503191708.j2JH86OT001776@alum-2.mit.edu> <20050320140721.1694.qmail@cr.yp.to> <20050321010523.25127.qmail@cr.yp.to> NNTP-Posting-Host: taverner.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1111368681 9008 128.32.168.222 (21 Mar 2005 01:31:21 GMT) X-Complaints-To: usenet@abraham.cs.berkeley.edu NNTP-Posting-Date: Mon, 21 Mar 2005 01:31:21 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: daw@taverner.cs.berkeley.edu (David Wagner) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Wagner List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f D. J. Bernstein wrote: >You seem to believe that randomized SHA-1 is much harder to break than >deterministic SHA-1, so why don't you believe that randomized MD5 is >much harder to break than deterministic MD5? [...] Perhaps there's >some magic dividing line between the 2^30ish operations used to find an >MD5 collision and the 2^66ish operations used to find a SHA-1 collision. >[...] It's not the collision complexity, per se. It is that the MD5 cryptanalysis techniques seem to have penetrated quite deeply into the structure of MD5. It is not too far off to imagine the possibility of second pre-image attacks on MD5, which would raise very serious doubt about the TCR-security of MD5. I have not seen the details of the cryptanalytic attack on SHA1, so I don't know yet whether similar comments will apply to SHA1 or not. If the latest announcement is just the first in a line of cryptanalytic results against SHA1 (as turned out to be the case with MD5), then I won't feel comfortable about SHA1, either. At the moment, I have yet to hear anything that sounds like it could endanger the security of SHA1 against second pre-image attacks, but I would prefer to defer judgement until the SHA1 attack paper is published. At the moment, the beast I know (SHA1) sounds less scary than the one I don't (SHA256). But that could change, if we had learn more bad things about SHA1, or if we learn more good things about SHA256. I certainly think it would be prudent to start a serious effort to try to come up with some hash function that has been validated as seriously as, say, AES. Whether that is an existing scheme, like SHA256, or some new one, probably matters less than the need for higher confidence in our hash functions. _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Sun Mar 20 20:57:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14839 for ; Sun, 20 Mar 2005 20:57:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDCFD-0002Ea-01 for cfrg-web-archive@ietf.org; Sun, 20 Mar 2005 21:02:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDC8y-0005b6-1x; Sun, 20 Mar 2005 20:55:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDC8w-0005aN-NC for cfrg@megatron.ietf.org; Sun, 20 Mar 2005 20:55:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14754 for ; Sun, 20 Mar 2005 20:55:45 -0500 (EST) Received: from vms044pub.verizon.net ([206.46.252.44]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDCDu-0002CI-Q0 for cfrg@ietf.org; Sun, 20 Mar 2005 21:00:55 -0500 Received: from HP752c ([68.237.72.237]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IDO00EZSIOWC0A2@vms044.mailsrvcs.net> for cfrg@ietf.org; Sun, 20 Mar 2005 19:55:45 -0600 (CST) Date: Sun, 20 Mar 2005 20:55:47 -0500 From: "Shai Halevi" In-reply-to: <200503201703.j2KH3IKO006898@alum-2.mit.edu> To: Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Subject: [Cfrg] RE: Who needs collision-resistance, anyway? X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit I am beginning to bore myself, repeating the same arguments over and over. I'll try to clarify what I say once more, and then just sign off of this exchange, letting Dan have the last word if he so chooses. > The signature systems that you're advocating are _not_ based on TCR. > You do _not_ have tight reductions between hash-collision forgeries and > TCR. (It shouldn't be hard to prove that no such reductions exist.) It is easy to prove the following theorem (Bellare-Rogaway, Crypto'97, http://www.cs.ucdavis.edu/~rogaway/papers/tcr-hash-abstract.html): If Sig is a secure signature scheme for short messages, and H is a keyed target-collision-resistant hash function, then the following algorithm is a secure signature scheme for long messages: Sig'(m): + Choose a random key for H (call it hk) + Compute h = H_{hk}(m) + Compute s = Sig(hk,k) + Output (hk,s) as the signature on m In terms of concrete security, the success probability of an attacker against the new scheme is at most eps_{Sig'} = eps_{Sig} + N * eps_{TCR} where eps_{Sig} bounds the success probability of an attacker against Sig (the original signature scheme), eps_{TCR} bounds the success probability of an attacker against the target-collision-resistance of H, and N is the number of on-line signature queries that the attacker makes in the attack. I would call the above a tight reduction, but I guess that this is a matter of opinion. > The attacker is _not_ faced with an uncontrolled value h and the task > of finding m such that MD5(m) = h. That's correct. The TCR model is this: the attacker gives you a message m, then you choose hk at random and sends it back, and then the attacker needs to find another m' such that H_{hk}(m) = h_{hk}(m'). I must add, however, that I don't believe the difference between "2nd preimage" and target-collision-resistance to be that important. In theory it is easy to get from one to the other (although I do not know how efficient would such transformation be in practice). Actually, a reasonably interesting work here would be to find a "really efficient" construction of a secure signature scheme from a hash function that is only known to be 2nd-preimage-resistant. > In short, TCR is the wrong problem. I'm still wondering how many times > I'm going to have to say this before it sinks in. > [...] > At this point you've made clear that you have a different opinion > regarding the difficulty of this problem. You've settled on a concrete > challenge for cryptanalysts; fine. But it is simply _wrong_ for you to > equate this problem with TCR. It was wrong for you to claim that a TCR > challenge was relevant, and it is wrong for you to again talk about TCR > as the foundation of a signature system. TCR is the wrong problem. See my previous mail. > I'm reminded of the following common argument: Blum-Blum-Shub is secure > if factorization is difficult; we assume that factoring 2048-bit numbers > is difficult; we conclude that 2048-bit Blum-Blum-Shub is secure. That > argument is wrong. Breaking BBS could be much easier than factoring the > modulus. The proven equivalence disregards huge polynomial factors. If > you want to understand concrete BBS security, factorization is the wrong > problem. This argument approaches the realm of religious belief. Personally, I feel that the case for "concrete security" and tight reductions is over-stated. It is often the case that the reduction tightness (or lack thereof) is more a matter of our proof techniques than anything that has to do with the security of the scheme itself. But that's just my opinion, I know that there are many who disagree. -- Shai _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Mon Mar 21 00:20:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01388 for ; Mon, 21 Mar 2005 00:20:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDFQ3-0000Ib-MT for cfrg-web-archive@ietf.org; Mon, 21 Mar 2005 00:25:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDFKK-0006jb-VR; Mon, 21 Mar 2005 00:19:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDFKJ-0006jV-A0 for cfrg@megatron.ietf.org; Mon, 21 Mar 2005 00:19:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01325 for ; Mon, 21 Mar 2005 00:19:40 -0500 (EST) Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDFPI-0000HO-6n for cfrg@ietf.org; Mon, 21 Mar 2005 00:24:53 -0500 Received: from [10.0.1.2] (h000393e3da37.ne.client2.attbi.com[65.96.130.134]) by comcast.net (sccrmhc13) with SMTP id <20050321051933016007p153e>; Mon, 21 Mar 2005 05:19:33 +0000 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: References: Message-Id: From: John Wilkinson Subject: Re: [Cfrg] RE: Who needs collision-resistance, anyway? Date: Mon, 21 Mar 2005 00:19:29 -0500 To: cfrg@ietf.org X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0549256756==" Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a --===============0549256756== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-13--68816496; protocol="application/pkcs7-signature" --Apple-Mail-13--68816496 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Most of the discussion on this list seems to be centered around creating a TCR hash function by keying SHA1 through the IV using the construction h(k || m), where k is the key (which is published, once chosen), m is the message, and || denotes concatenation. Keying through the IV is explicitly rejected in the paper [1] cited by Dr. Halevi. Also rejected is the "envelope" construction h(k || m || k). HMAC has no security guarantees if the key is not secret. It is argued in [1] that the TCR of these constructions may be just as easy (or even easier!) to break than the "any collision resistance" (ACR) of the hash function h. The constructions with security reduction arguments presented in [1] all have very long keys (much greater than the length of the hash), and the authors make a comment that the common practice of stretching a short key into a long one using a PRF is "of no apparent use in this case". (If anyone can explain why, I'd love to know.) In a signature scheme, the hash value and the key must be signed, and then the key must be sent along with the signature, effectively increasing the length of the signature at least threefold. The authors of [1] suggest that since the birthday "attack" is not applicable to TCR hash functions, new TCR hash functions with 64- or 80-bit lengths could be developed to mitigate the problem of signature length expansion. With all the caveats applied in [1] to TCR-based signature schemes, will anyone still prefer them to traditional ACR-based schemes using SHA256 or SHA512? Does anyone have an argument to make that the authors of [1] are overly pessimistic in their assessment of h(k || m) or HMAC as TCR hash functions? [1] http://www.cs.ucdavis.edu/~rogaway/papers/tcr-hash-abstract.html --Apple-Mail-13--68816496 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGVTCCAw4w ggJ3oAMCAQICAwwuLDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwNDIzMDIyODU1WhcNMDUwNDIzMDIyODU1WjBMMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSkwJwYJKoZIhvcNAQkBFhpqb2huX3dpbGtpbnNvbkBj b21jYXN0Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAPdXgqkcMe0fiCnYO/1R HWRjXLw2qvJ5Uy6xoItiAZXgP4JO8uhl5+A7FqBnseUq0hj84CsujF1tct3q97Y9VuzdClmY80Kj r9JzTJLXZpwSDh81lS/GEhz+fkp0/B33/QuaoHPhYqR0zK3fBt+fB7zZXw+A1YArxA5Vkb+3qNRx zQF/e6ucvs5KBCDjRDDbJPHiAM1gdparZqPUHCcDYMR4MQXOnjyHSZ99oYwI1ZwZoWjukfBneCmV zOScLxR5v/D6uQG4BbYcLMIgWiV5uybUs0+V0VXyoBj5rPmbq6PeY15p/Dl3Wd3o81zjZahvZA/H EwrG/PR7M2rNeon+DlECAwEAAaNkMGIwKwYFK2UBBAEEIjAgAgEAMBswGQIBBAQURGhMR2NNNFZq dlY3WnpNbUQ2VFkwJQYDVR0RBB4wHIEaam9obl93aWxraW5zb25AY29tY2FzdC5uZXQwDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAXCUWNjJNVnkFOz25fOQ6NDqTDoaZxxwK8RT/l9JdM EmBmQpgf+Gm4yUjLBC1memO+N4F0iy/qN/gQ7WBLLlshmjf7BZ+KM+YJbG68UKF+gBC4Vr0FM3bS xIblYNCS8AIwVwaiBi7ql3WAmka+JflmyHyxH0lyORGPHG1HJzCLyzCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDDC4sMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MDMyMTA1MTkyOVowIwYJKoZIhvcNAQkEMRYEFLa0 Iv4O+crMOhvszhLw3nS+P5bNMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMLiwwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDC4sMA0GCSqGSIb3DQEBAQUABIIBAM2b F0u3mstuzy/jW2Nxjyr4XknG6gRrRCHSqvBp5r+y+qURWMcRxfqw3YfWLaUPxTOSYRKeb5mWRXRG X3GbwZvDO1xNLCL3S4TGSXgNOS4KFNGNIr08c3vRavAYGB+W+ZhhipSTuYx473qxahG+jvzwhCN/ kKMsn04hrjgy5y9vuLZXgyDI+6V8/GybbXRpXQNfPdcccBQk7XYuWOehlSwcS2tmGBK/VN9W4NcA F4Xpn8sR3b6xnH1WSaLm/36TgJeefaOPhNMa0RPAoIMILMXl/brX2xF04HqPCfXJ6nhlf23CE0Fr 0RG0Xjvq2lV6fN2QBTaQvl92XVhPJnmhjT0AAAAAAAA= --Apple-Mail-13--68816496-- --===============0549256756== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg --===============0549256756==-- From cfrg-bounces@ietf.org Mon Mar 21 01:12:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04345 for ; Mon, 21 Mar 2005 01:12:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDGEm-0001dx-2q for cfrg-web-archive@ietf.org; Mon, 21 Mar 2005 01:18:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDG7w-0002Wq-VA; Mon, 21 Mar 2005 01:11:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDG7v-0002WM-8h for cfrg@megatron.ietf.org; Mon, 21 Mar 2005 01:10:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04231 for ; Mon, 21 Mar 2005 01:10:58 -0500 (EST) Received: from stoneport.math.uic.edu ([131.193.178.160]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DDGCu-0001bx-OR for cfrg@ietf.org; Mon, 21 Mar 2005 01:16:10 -0500 Received: (qmail 33817 invoked by uid 1016); 21 Mar 2005 06:11:26 -0000 Date: 21 Mar 2005 06:11:26 -0000 Message-ID: <20050321061126.33816.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: cfrg@ietf.org Subject: Re: [Cfrg] RE: Who needs collision-resistance, anyway? References: <200503201703.j2KH3IKO006898@alum-2.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Shai Halevi writes: > I would call the above a tight reduction The probability ratio is approximately N, the number of signed messages, which can easily be 2^40 or more. If a factor of 2^40 is ``tight,'' I hate to imagine a reduction that you'd call ``loose''! Everyone else calls this a ``loose'' reduction. See, e.g., Section 1.2 of ``The exact security of digital signatures'' by Bellare and Rogaway, discussing the same factor of N in the FDH reduction. Anyway, once you gave a concrete definition of feasibility (2^50 queries, 2^70 space, 2^90 operations), you were simply _wrong_ to leap from the hypothesis ``TCR is infeasible'' to the conclusion ``forging signatures is infeasible.'' It doesn't matter what strange terminology you use for referring to the extra factor 2^40; neglecting that factor was a flat-out error. This error is important because it's a fundamental misrepresentation of the security level of the signature system that you're advocating. People who are misled into looking at the wrong problem, namely TCR, are likely to be overconfident in the security of this system, and will find themselves unpleasantly surprised when the system is ripped to shreds by cryptanalysts. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Mon Mar 21 02:00:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07746 for ; Mon, 21 Mar 2005 02:00:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDGz7-0002uy-IV for cfrg-web-archive@ietf.org; Mon, 21 Mar 2005 02:05:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDGqJ-0006j8-NR; Mon, 21 Mar 2005 01:56:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDGqG-0006iy-Of for cfrg@megatron.ietf.org; Mon, 21 Mar 2005 01:56:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06943 for ; Mon, 21 Mar 2005 01:56:47 -0500 (EST) Received: from abraham.cs.berkeley.edu ([128.32.37.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDGvG-0002r6-Cs for cfrg@ietf.org; Mon, 21 Mar 2005 02:01:59 -0500 Received: from news by abraham.cs.berkeley.edu with local (Exim 4.43) id 1DDGop-0008AH-H0 for cfrg@ietf.org; Sun, 20 Mar 2005 22:55:19 -0800 To: cfrg@ietf.org Path: not-for-mail From: daw@taverner.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ietf-cfrg Subject: Re: [Cfrg] RE: Who needs collision-resistance, anyway? Date: Mon, 21 Mar 2005 06:55:19 +0000 (UTC) Organization: University of California, Berkeley Lines: 53 Distribution: isaac Message-ID: References: NNTP-Posting-Host: taverner.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1111388119 31388 128.32.168.222 (21 Mar 2005 06:55:19 GMT) X-Complaints-To: usenet@abraham.cs.berkeley.edu NNTP-Posting-Date: Mon, 21 Mar 2005 06:55:19 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: daw@taverner.cs.berkeley.edu (David Wagner) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Wagner List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 John Wilkinson wrote: >Most of the discussion on this list seems to be centered around >creating a TCR hash function by keying SHA1 through the IV using the >construction h(k || m), where k is the key (which is published, once >chosen), m is the message, and || denotes concatenation. Keying through >the IV is explicitly rejected in the paper [1] cited by Dr. Halevi. You're right. I don't understand why that construction was rejected. I'm at a loss to explain their reasoning. Here is the argument given in that paper: Suppose, for example, that one keys MD5 through its 128-bit initial chaining value, IV. Denote the resulting hash function family by MD5*. Then breaking MD5* (in the sense of violating TCR) amounts to finding collisions in an algorithm which is identical to MD5 except that it begins with a random, known IV (as opposed to the published one). It seems unlikely that this task would be harder than finding collisions in MD5 itself. It could even be easier! But this seems to confuse two distinct cryptanalytic tasks: (1) given the IV, find M, M' so that MD5*(IV,M) = MD5*(IV,M'); (2) choose M before you know the IV; then, given the IV, find M' so that MD5*(IV,M) = MD5*(IV,M'). I don't see any reason to expect these two tasks to be equivalent, and I would certainly imagine that for some hash functions, task (2) might be much harder than task (1). Indeed, task (2) is basically the TCR notion, while task (1) is just standard collision-resistance. So I don't know why they rejected MD5*. I don't know why that paper considered it unlikely that breaking MD5*'s TCR property would be any harder than breaking MD5's collision-resistance. I don't know why they rejected the envelope method, either. The paragraph discussing the envelope method seems to have made the same mistake, as far as I can tell. I'm puzzled; I confess I don't see where those comments are coming from. I definitely wouldn't recommend using MD5 for this purpose. But I'm not aware of any reason to reject SHA1(k || m) or SHA1*(k, m). It is true that there are no security guarantees that either of these constructions will be secure, but there is also no guarantee that these constructions will be insecure. There is some reason to hope that these constructions might be secure even if collisions are found in SHA1. >The constructions with security reduction arguments presented in [1] >all have very long keys (much greater than the length of the hash), and >the authors make a comment that the common practice of stretching a >short key into a long one using a PRF is "of no apparent use in this >case". (If anyone can explain why, I'd love to know.) I don't have a concrete example of what goes wrong, but this sounds plausible to me. The definition of security for a PRF makes no guarantees about the pseudorandomness of its output if the key to the PRF is made public, so using a PRF with a public key is a strange thing to do. _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Mon Mar 21 10:04:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13089 for ; Mon, 21 Mar 2005 10:04:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDOXg-00039e-Nf for cfrg-web-archive@ietf.org; Mon, 21 Mar 2005 10:10:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDOQk-0003Q2-2Z; Mon, 21 Mar 2005 10:02:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDOQi-0003Ps-1z for cfrg@megatron.ietf.org; Mon, 21 Mar 2005 10:02:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12926 for ; Mon, 21 Mar 2005 10:02:53 -0500 (EST) Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDOVm-000348-9F for cfrg@ietf.org; Mon, 21 Mar 2005 10:08:10 -0500 Received: from [10.0.1.2] (h000393e3da37.ne.client2.attbi.com[65.96.130.134]) by comcast.net (sccrmhc13) with SMTP id <20050321150245016007nnq8e>; Mon, 21 Mar 2005 15:02:45 +0000 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: References: Message-Id: <4181a576bbb6d04a3095d1d1f1062314@comcast.net> From: John Wilkinson Subject: Re: [Cfrg] RE: Who needs collision-resistance, anyway? Date: Mon, 21 Mar 2005 10:02:42 -0500 To: cfrg@ietf.org X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1337828120==" Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 --===============1337828120== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-14--33823346; protocol="application/pkcs7-signature" --Apple-Mail-14--33823346 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Mar 21, 2005, at 1:55 AM, David Wagner wrote: > You're right. I don't understand why that construction was rejected. > I'm at a loss to explain their reasoning. I couldn't understand their out-of-hand rejection either. I thought it might either be something trivial that I was overlooking, or something that someone who had intently studied the attacks on hash functions would intuit. >> The constructions with security reduction arguments presented in [1] >> all have very long keys (much greater than the length of the hash), >> and >> the authors make a comment that the common practice of stretching a >> short key into a long one using a PRF is "of no apparent use in this >> case". (If anyone can explain why, I'd love to know.) > > I don't have a concrete example of what goes wrong, but this sounds > plausible to me. The definition of security for a PRF makes no > guarantees > about the pseudorandomness of its output if the key to the PRF is made > public, so using a PRF with a public key is a strange thing to do. The thing that strikes me as odd about this reasoning is that, in any case, the TCR hash function (TCRHF) key must eventually be made public. Users are likely to generate the TCRHF key using a PRNG of some sort, such as /dev/urandom. What does it matter if you publish the state of your computer's internal PRNG after you have published its output? (Assuming you aren't foolish enough to use that same state to generate any further data you wish to keep secret.) The authors exact comment in [1] is in a footnote on page 5: "It may be worth remarking that the obvious idea for reducing key size is to let the key be a seed to a pseudorandom number generator and specify longer keys by stretching the seed to any desired length. The problem is that our keys are public (they are available to the adversary) and pseudorandom generators are of no apparent use in such a context." If the authors believe that the keys to the TCRHF must be truly random for their security reductions to hold, then that's a huge barrier to implementation. I don't know of any system that can easily generate the required amount of truly random key material. If the security reductions only require that the keys be apparently random to the attacker (such that the details of the PRNG that generated them cannot be published), then we are back to the problem of having extremely long keys, which must be signed and transmitted with every signature. While the practicality of the construction SHA1(k || m) relative to SHA256(m) could be debated, it seems unlikely that any of the constructions presented in [1] would be considered for implementation over SHA256(m) or even SHA512(m). [1] http://www.cs.ucdavis.edu/~rogaway/papers/tcr-hash-abstract.html --Apple-Mail-14--33823346 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGVTCCAw4w ggJ3oAMCAQICAwwuLDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwNDIzMDIyODU1WhcNMDUwNDIzMDIyODU1WjBMMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSkwJwYJKoZIhvcNAQkBFhpqb2huX3dpbGtpbnNvbkBj b21jYXN0Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAPdXgqkcMe0fiCnYO/1R HWRjXLw2qvJ5Uy6xoItiAZXgP4JO8uhl5+A7FqBnseUq0hj84CsujF1tct3q97Y9VuzdClmY80Kj r9JzTJLXZpwSDh81lS/GEhz+fkp0/B33/QuaoHPhYqR0zK3fBt+fB7zZXw+A1YArxA5Vkb+3qNRx zQF/e6ucvs5KBCDjRDDbJPHiAM1gdparZqPUHCcDYMR4MQXOnjyHSZ99oYwI1ZwZoWjukfBneCmV zOScLxR5v/D6uQG4BbYcLMIgWiV5uybUs0+V0VXyoBj5rPmbq6PeY15p/Dl3Wd3o81zjZahvZA/H EwrG/PR7M2rNeon+DlECAwEAAaNkMGIwKwYFK2UBBAEEIjAgAgEAMBswGQIBBAQURGhMR2NNNFZq dlY3WnpNbUQ2VFkwJQYDVR0RBB4wHIEaam9obl93aWxraW5zb25AY29tY2FzdC5uZXQwDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAXCUWNjJNVnkFOz25fOQ6NDqTDoaZxxwK8RT/l9JdM EmBmQpgf+Gm4yUjLBC1memO+N4F0iy/qN/gQ7WBLLlshmjf7BZ+KM+YJbG68UKF+gBC4Vr0FM3bS xIblYNCS8AIwVwaiBi7ql3WAmka+JflmyHyxH0lyORGPHG1HJzCLyzCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDDC4sMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MDMyMTE1MDI0M1owIwYJKoZIhvcNAQkEMRYEFCOd /SKIjDqq55jmPkXRDnF5/OEoMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMLiwwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDC4sMA0GCSqGSIb3DQEBAQUABIIBAEtN M/kihHEbg3bOdzNniTFa+m0sI7zP0iHqR0B0dNrzn7bxyguIwozbl/Ixh7dWq4wbbmerq/AfMIB4 DymnxcNq4Kkjb/DoBQ02AqjN80nSnqcxCG5c2k8WPsVsxSDw/dOo9U+djhOQa6z21utdrbWdGzwU 5R0y6J/ZxOyZkGtZpDeT858T4jJKUeOQEoIYn3zvHUZ0Y5Uzn3zbSNdhg8DP5D9uBb5FuuBfyECk LgaELVqFh3Qb+tRlbPDnVcOUprl+ApcSMvQ8U50BpJQL57QhDJcUSiR9t2adt4lS/ghUlR4BYldx zieeg2FaYUoWtrxq5l1/lUGc0dSKkqQmrE8AAAAAAAA= --Apple-Mail-14--33823346-- --===============1337828120== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg --===============1337828120==-- From cfrg-bounces@ietf.org Mon Mar 21 10:10:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14018 for ; Mon, 21 Mar 2005 10:10:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDOda-0003O3-Uw for cfrg-web-archive@ietf.org; Mon, 21 Mar 2005 10:16:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDOXj-0004Mf-Q6; Mon, 21 Mar 2005 10:10:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDOXi-0004MY-1D for cfrg@megatron.ietf.org; Mon, 21 Mar 2005 10:10:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13948 for ; Mon, 21 Mar 2005 10:10:07 -0500 (EST) Received: from igw2.watson.ibm.com ([129.34.20.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDOcm-0003NF-Lu for cfrg@ietf.org; Mon, 21 Mar 2005 10:15:25 -0500 Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id j2LFA0P302220 for ; Mon, 21 Mar 2005 10:10:00 -0500 Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j2LF9xm76944 for ; Mon, 21 Mar 2005 10:09:59 -0500 Received: from [127.0.0.1] ([9.2.18.142]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j2LF9wf76942 for ; Mon, 21 Mar 2005 10:09:58 -0500 Message-ID: <423EE3C2.5090408@alum.mit.edu> Date: Mon, 21 Mar 2005 10:09:54 -0500 From: Shai Halevi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: cfrg@ietf.org References: <200503210659.j2L6xVKt010746@alum-1.mit.edu> In-Reply-To: <200503210659.j2L6xVKt010746@alum-1.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Subject: [Cfrg] Constructions of TCR hashing from MD-type functions X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit John Wilkinson makes a very good argument, as to "why should be think that an MD-type hash function with a short key is TCR". There is a recent paper of Hong, Preneel, and Lee, that addresses that question to some extent (Higher-order universal one-way hash functions, Asiacrypt 2004, LNCS 2894, pages 201-213). Roughly, they propose a notion of "order-r universal one-way hash function", and show that if the compression function is order-r, then using the MD construction on r blocks (with the same short key everywhere) does give you a TCR hash function. The "order-r UOWHF" game is as follows: A hashing key hk is chosen at random, but is not given to the attacker. The attacker can ask r hashing queries m_1...m_r, and get the answers h_i = H_{hk}(m_i). Then you play the usual TCR game: the attacker commits to message m, gets the hashing key hk, and needs to find another m' such that H_{hk}(m)=H_{hk}(m'). -- Shai John Wilkinson wrote: > Most of the discussion on this list seems to be centered around > creating a TCR hash function by keying SHA1 through the IV using the > construction h(k || m), where k is the key (which is published, once > chosen), m is the message, and || denotes concatenation. Keying through > the IV is explicitly rejected in the paper [1] cited by Dr. Halevi. > Also rejected is the "envelope" construction h(k || m || k). HMAC has > no security guarantees if the key is not secret. It is argued in [1] > that the TCR of these constructions may be just as easy (or even > easier!) to break than the "any collision resistance" (ACR) of the hash > function h. > > The constructions with security reduction arguments presented in [1] > all have very long keys (much greater than the length of the hash), and > the authors make a comment that the common practice of stretching a > short key into a long one using a PRF is "of no apparent use in this > case". (If anyone can explain why, I'd love to know.) In a signature > scheme, the hash value and the key must be signed, and then the key > must be sent along with the signature, effectively increasing the > length of the signature at least threefold. The authors of [1] suggest > that since the birthday "attack" is not applicable to TCR hash > functions, new TCR hash functions with 64- or 80-bit lengths could be > developed to mitigate the problem of signature length expansion. > > With all the caveats applied in [1] to TCR-based signature schemes, > will anyone still prefer them to traditional ACR-based schemes using > SHA256 or SHA512? Does anyone have an argument to make that the authors > of [1] are overly pessimistic in their assessment of h(k || m) or HMAC > as TCR hash functions? > > [1] http://www.cs.ucdavis.edu/~rogaway/papers/tcr-hash-abstract.html _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Mon Mar 21 12:58:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01082 for ; Mon, 21 Mar 2005 12:58:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDRG6-0001B5-Gj for cfrg-web-archive@ietf.org; Mon, 21 Mar 2005 13:04:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDR7q-0006C3-Lr; Mon, 21 Mar 2005 12:55:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDR7p-0006Bx-9b for cfrg@megatron.ietf.org; Mon, 21 Mar 2005 12:55:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00776 for ; Mon, 21 Mar 2005 12:55:34 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDRCu-000137-UE for cfrg@ietf.org; Mon, 21 Mar 2005 13:00:54 -0500 Received: from phys-san-2 ([129.153.85.71]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j2LHtYXA009713 for ; Mon, 21 Mar 2005 10:55:34 -0700 (MST) Received: from conversion-daemon.san-mail1.west.sun.com by san-mail1.west.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IDP00C01QRL99@san-mail1.west.sun.com> (original mail from David.Jacobson@Sun.COM) for cfrg@ietf.org; Mon, 21 Mar 2005 09:55:34 -0800 (PST) Received: from Sun.COM (sr1-usan-05.West.Sun.COM [129.153.85.35]) by san-mail1.west.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IDP006R2R4M6U@san-mail1.west.sun.com>; Mon, 21 Mar 2005 09:55:34 -0800 (PST) Date: Mon, 21 Mar 2005 09:55:34 -0800 From: david jacobson Subject: Re: [Cfrg] RE: Who needs collision-resistance, anyway? In-reply-to: <4181a576bbb6d04a3095d1d1f1062314@comcast.net> To: John Wilkinson Message-id: <423F0A96.4070209@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 References: <4181a576bbb6d04a3095d1d1f1062314@comcast.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7BIT Cc: cfrg@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David.Jacobson@Sun.COM List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7BIT John Wilkinson wrote: > On Mar 21, 2005, at 1:55 AM, David Wagner wrote: > [snip] > If the authors believe that the keys to the TCRHF must be truly random > for their security reductions to hold, then that's a huge barrier to > implementation. I don't know of any system that can easily generate the > required amount of truly random key material. If the security > reductions only require that the keys be apparently random to the > attacker (such that the details of the PRNG that generated them cannot > be published), then we are back to the problem of having extremely long > keys, which must be signed and transmitted with every signature. A Broadcom 5821 chip will produce over 1 megabit per second of true random output, and this chip is several years old now. I don't believe that random number generation (yes, cryptography quality random number generation) is all that hard. > > While the practicality of the construction SHA1(k || m) relative to > SHA256(m) could be debated, it seems unlikely that any of the > constructions presented in [1] would be considered for implementation > over SHA256(m) or even SHA512(m). > > [1] http://www.cs.ucdavis.edu/~rogaway/papers/tcr-hash-abstract.html > > > ------------------------------------------------------------------------ > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg -- David Jacobson _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Mon Mar 21 13:45:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04262 for ; Mon, 21 Mar 2005 13:45:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDRz0-0002eG-Bu for cfrg-web-archive@ietf.org; Mon, 21 Mar 2005 13:50:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDRrD-0005Dg-9E; Mon, 21 Mar 2005 13:42:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDRrC-0005Db-67 for cfrg@megatron.ietf.org; Mon, 21 Mar 2005 13:42:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04110 for ; Mon, 21 Mar 2005 13:42:26 -0500 (EST) Received: from off.net ([66.96.28.3] helo=mail.off.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDRwI-0002b9-Nk for cfrg@ietf.org; Mon, 21 Mar 2005 13:47:47 -0500 Received: by mail.off.net (Postfix, from userid 948) id F02D67702AA; Mon, 21 Mar 2005 13:42:15 -0500 (EST) Received: by bitchcake.off.net (hashcash-sendmail, from uid 948); Mon, 21 Mar 2005 13:42:14 -0500 Date: Mon, 21 Mar 2005 13:42:13 -0500 From: Adam Back To: david jacobson Subject: use of hash functions _in_ CPRNGs (Re: [Cfrg] RE: Who needs collision-resistance, anyway?) Message-ID: <20050321184213.GA11213@bitchcake.off.net> References: <4181a576bbb6d04a3095d1d1f1062314@comcast.net> <423F0A96.4070209@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <423F0A96.4070209@Sun.COM> User-Agent: Mutt/1.4.1i X-Hashcash: 1:20:050321:david.jacobson@sun.com::oXK7zkQAbQ6G/lwa:1Ad8 X-Hashcash: 1:20:050321:john_wilkinson@comcast.net::WLl6gOJ2YmP0WDEi:t2/ X-Hashcash: 1:20:050321:cfrg@ietf.org::zPIW+L8xTgW0DDS+:6sjB X-Hashcash: 1:20:050321:adam@cypherspace.org::aNCcjkc1SXXmxrMq:HCZ X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Adam Back , cfrg@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Re. the comments about RNG cost (hardware or software) isn't it usual for such output to be whitened through a hash function, such as eg SHA1. (Thinking eg of the Intel RNG that Paul Kocher/Cryptography Research reviewed.) /dev/urandom implementation also involves hash functions as do many other CPRNG. This to me somewhat calls into doubts the claims that CPRNGs as suitable for creating bits for input to strengthen hash functions have negligible cost. (Of course the cost is amortized across large messages, but not all messages are large). Adam On Mon, Mar 21, 2005 at 09:55:34AM -0800, david jacobson wrote: > A Broadcom 5821 chip will produce over 1 megabit per second of true > random output, and this chip is several years old now. I don't believe > that random number generation (yes, cryptography quality random number > generation) is all that hard. _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Mon Mar 21 14:01:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05579 for ; Mon, 21 Mar 2005 14:01:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDSF8-0003Fp-2Z for cfrg-web-archive@ietf.org; Mon, 21 Mar 2005 14:07:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDS8P-0007jr-Mg; Mon, 21 Mar 2005 14:00:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDS8N-0007jm-DC for cfrg@megatron.ietf.org; Mon, 21 Mar 2005 14:00:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05452 for ; Mon, 21 Mar 2005 14:00:14 -0500 (EST) Received: from igw2.watson.ibm.com ([129.34.20.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDSDS-0003D7-7M for cfrg@ietf.org; Mon, 21 Mar 2005 14:05:32 -0500 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id j2LJ03P435944 for ; Mon, 21 Mar 2005 14:00:03 -0500 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j2LJ02a62064 for ; Mon, 21 Mar 2005 14:00:02 -0500 Received: from mgsmtp00 (mgsmtp00.watson.ibm.com [9.2.40.58]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j2LJ02G44912 for ; Mon, 21 Mar 2005 14:00:02 -0500 Received: from wasa.watson.ibm.com ([9.2.16.192]) by mgsmtp00.watson.ibm.com ID IMFd1111431434.1; Mon, 21 Mar 2005 13:57:14 -0400 Received: (from csjutla@localhost) by wasa.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) id j2LIxxk33970; Mon, 21 Mar 2005 13:59:59 -0500 From: csjutla MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 21 Mar 2005 13:59:59 -0500 (EST) To: David Wagner Subject: Re: [Cfrg] RE: Who needs collision-resistance, anyway? Newsgroups: isaac.lists.ietf-cfrg In-Reply-To: References: X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <16959.5660.613357.509942@wasa.watson.ibm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: cfrg@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Lot of confusion is arising from comparing apples and oranges. In the collision resistant model (also called ACR) the adversary is given the IV (or the key say) and then must find M and M'. Clearly, the adversary could try a random M and the magic differential to get M', and would succeed with prob say epsilon. Or, he could spend 1/eps time and actually succeed with high prob. In the TCR model, the adversary chooses M first, and then is given IV (or key) and so he again tries the magic differential to get M' and will succeed with prob epsilon. This ASSUMES that the magic differential works equally well on all IV, and there is good reason to believe this is indeed the case. Hence the rejection of MD5*. In fact, MD5 could have chosen IV in a very samrt way and fixed it for ever. And hence, a random IV may actually cause weakness. -Charanjit David Wagner writes: > John Wilkinson wrote: > >Most of the discussion on this list seems to be centered around > >creating a TCR hash function by keying SHA1 through the IV using the > >construction h(k || m), where k is the key (which is published, once > >chosen), m is the message, and || denotes concatenation. Keying through > >the IV is explicitly rejected in the paper [1] cited by Dr. Halevi. > > You're right. I don't understand why that construction was rejected. > I'm at a loss to explain their reasoning. > > Here is the argument given in that paper: > > Suppose, for example, that one keys MD5 through its 128-bit initial > chaining value, IV. Denote the resulting hash function family by > MD5*. Then breaking MD5* (in the sense of violating TCR) amounts to > finding collisions in an algorithm which is identical to MD5 except > that it begins with a random, known IV (as opposed to the published > one). It seems unlikely that this task would be harder than finding > collisions in MD5 itself. It could even be easier! > > But this seems to confuse two distinct cryptanalytic tasks: (1) given the > IV, find M, M' so that MD5*(IV,M) = MD5*(IV,M'); (2) choose M before you > know the IV; then, given the IV, find M' so that MD5*(IV,M) = MD5*(IV,M'). > I don't see any reason to expect these two tasks to be equivalent, > and I would certainly imagine that for some hash functions, task (2) > might be much harder than task (1). Indeed, task (2) is basically the > TCR notion, while task (1) is just standard collision-resistance. > > So I don't know why they rejected MD5*. I don't know why that paper > considered it unlikely that breaking MD5*'s TCR property would be > any harder than breaking MD5's collision-resistance. I don't know why > they rejected the envelope method, either. The paragraph discussing the > envelope method seems to have made the same mistake, as far as I can tell. > I'm puzzled; I confess I don't see where those comments are coming from. > > I definitely wouldn't recommend using MD5 for this purpose. But I'm > not aware of any reason to reject SHA1(k || m) or SHA1*(k, m). > > It is true that there are no security guarantees that either of these > constructions will be secure, but there is also no guarantee that these > constructions will be insecure. There is some reason to hope that these > constructions might be secure even if collisions are found in SHA1. > > >The constructions with security reduction arguments presented in [1] > >all have very long keys (much greater than the length of the hash), and > >the authors make a comment that the common practice of stretching a > >short key into a long one using a PRF is "of no apparent use in this > >case". (If anyone can explain why, I'd love to know.) > > I don't have a concrete example of what goes wrong, but this sounds > plausible to me. The definition of security for a PRF makes no guarantees > about the pseudorandomness of its output if the key to the PRF is made > public, so using a PRF with a public key is a strange thing to do. > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Mon Mar 21 15:15:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13245 for ; Mon, 21 Mar 2005 15:15:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDTNr-00066m-PT for cfrg-web-archive@ietf.org; Mon, 21 Mar 2005 15:20:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDTHI-0002nV-Ia; Mon, 21 Mar 2005 15:13:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDTHH-0002nQ-Dx for cfrg@megatron.ietf.org; Mon, 21 Mar 2005 15:13:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13073 for ; Mon, 21 Mar 2005 15:13:29 -0500 (EST) Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDTMM-00064v-Up for cfrg@ietf.org; Mon, 21 Mar 2005 15:18:49 -0500 Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id j2LKDRKI021180; Mon, 21 Mar 2005 12:13:27 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 21 Mar 2005 12:13:27 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD372500A9@MOU1WNEXMB04.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" To: "'David Wagner'" , cfrg@ietf.org Subject: RE: [Cfrg] RE: Who needs collision-resistance, anyway? Date: Mon, 21 Mar 2005 12:13:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b The h (k || m) construction was rejected I believe because of a message extension attack that had been discussed at the time. If I know h (k || m) then I can calculate h (k || m || p || x) where p is the padding appended to k || m in the digest iterator construct. This is one of the reasons why the HTTP Digest authentication mechanism uses a construction of the form: h ( h ( x) || h (y) ), to eliminate the risk of an extension attack. I wrote that construct before HMAC was written but I still think that there is a real value to effectively changing the order of the compressor function inputs so that the state chaining variables get fed into the data input slot. Now that does not say anything about whether the message extension attack was a risk in the proposed use but that is I believe the reason it was rejected. > -----Original Message----- > From: cfrg-bounces@ietf.org [mailto:cfrg-bounces@ietf.org] On > Behalf Of daw@taverner.cs.berkeley.edu > Sent: Monday, March 21, 2005 1:55 AM > To: cfrg@ietf.org > Subject: Re: [Cfrg] RE: Who needs collision-resistance, anyway? > > > John Wilkinson wrote: > >Most of the discussion on this list seems to be centered around > >creating a TCR hash function by keying SHA1 through the IV using the > >construction h(k || m), where k is the key (which is published, once > >chosen), m is the message, and || denotes concatenation. > Keying through > >the IV is explicitly rejected in the paper [1] cited by Dr. Halevi. > > You're right. I don't understand why that construction was > rejected. I'm at a loss to explain their reasoning. > > Here is the argument given in that paper: > > Suppose, for example, that one keys MD5 through its > 128-bit initial > chaining value, IV. Denote the resulting hash function family by > MD5*. Then breaking MD5* (in the sense of violating TCR) > amounts to > finding collisions in an algorithm which is identical to > MD5 except > that it begins with a random, known IV (as opposed to the > published > one). It seems unlikely that this task would be harder > than finding > collisions in MD5 itself. It could even be easier! > > But this seems to confuse two distinct cryptanalytic tasks: > (1) given the IV, find M, M' so that MD5*(IV,M) = > MD5*(IV,M'); (2) choose M before you know the IV; then, given > the IV, find M' so that MD5*(IV,M) = MD5*(IV,M'). I don't see > any reason to expect these two tasks to be equivalent, and I > would certainly imagine that for some hash functions, task > (2) might be much harder than task (1). Indeed, task (2) is > basically the TCR notion, while task (1) is just standard > collision-resistance. > > So I don't know why they rejected MD5*. I don't know why > that paper considered it unlikely that breaking MD5*'s TCR > property would be any harder than breaking MD5's > collision-resistance. I don't know why they rejected the > envelope method, either. The paragraph discussing the > envelope method seems to have made the same mistake, as far > as I can tell. I'm puzzled; I confess I don't see where those > comments are coming from. > > I definitely wouldn't recommend using MD5 for this purpose. > But I'm not aware of any reason to reject SHA1(k || m) or SHA1*(k, m). > > It is true that there are no security guarantees that either > of these constructions will be secure, but there is also no > guarantee that these constructions will be insecure. There > is some reason to hope that these constructions might be > secure even if collisions are found in SHA1. > > >The constructions with security reduction arguments presented in [1] > >all have very long keys (much greater than the length of the > hash), and > >the authors make a comment that the common practice of stretching a > >short key into a long one using a PRF is "of no apparent use in this > >case". (If anyone can explain why, I'd love to know.) > > I don't have a concrete example of what goes wrong, but this > sounds plausible to me. The definition of security for a PRF > makes no guarantees about the pseudorandomness of its output > if the key to the PRF is made public, so using a PRF with a > public key is a strange thing to do. > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Mon Mar 21 15:17:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13753 for ; Mon, 21 Mar 2005 15:17:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDTQa-0006Dd-9m for cfrg-web-archive@ietf.org; Mon, 21 Mar 2005 15:23:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDTKj-0003Ic-V5; Mon, 21 Mar 2005 15:17:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDTKj-0003IX-IE for cfrg@megatron.ietf.org; Mon, 21 Mar 2005 15:17:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13639 for ; Mon, 21 Mar 2005 15:17:03 -0500 (EST) Received: from igw2.watson.ibm.com ([129.34.20.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDTPr-0006Cm-5o for cfrg@ietf.org; Mon, 21 Mar 2005 15:22:23 -0500 Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id j2LKGtP150244 for ; Mon, 21 Mar 2005 15:16:55 -0500 Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j2LKGtm115544 for ; Mon, 21 Mar 2005 15:16:55 -0500 Received: from [127.0.0.1] (CRYPT01.watson.ibm.com [9.2.18.142]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j2LKGsf117782 for ; Mon, 21 Mar 2005 15:16:54 -0500 Message-ID: <423F2BB8.6020507@alum.mit.edu> Date: Mon, 21 Mar 2005 15:16:56 -0500 From: Shai Halevi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: cfrg@ietf.org References: <200503211709.j2LH9bx3018796@alum-2.mit.edu> In-Reply-To: <200503211709.j2LH9bx3018796@alum-2.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Subject: [Cfrg] Re: Who needs collision-resistance, anyway? X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit >>>(If anyone can explain why, I'd love to know.) >>> >>> I don't have a concrete example of what goes wrong, but this sounds >>> plausible to me. The definition of security for a PRF makes no >>> guarantees about the pseudorandomness of its output if the key to the >>> PRF is made public, so using a PRF with a public key is a strange >>> thing to do. > > The thing that strikes me as odd about this reasoning is that, in any > case, the TCR hash function (TCRHF) key must eventually be made public. > Users are likely to generate the TCRHF key using a PRNG of some sort, > such as /dev/urandom. What does it matter if you publish the state of > your computer's internal PRNG after you have published its output? > (Assuming you aren't foolish enough to use that same state to generate > any further data you wish to keep secret.) The short answer is that the proof of security just does not go through. The reason is that potentially, once you know the seed you can do things that you couldn't do before (e.g., find collisions). It does not sound likely, but we cannot prove otherwise. I know that this is a highly non-satisfying answer. If not pseudo randomness, surly there is some other property that would ensure that using the output of PRG(seed) is secure even when the attacker learns the seed. Yet we don't really know what other properties to suggest here, or how to to prove such a statement in any reasonable way. -- Shai p.s. This problem is not unique to the TCR application. There are several places where similar problems arise. For example, once you already know what message is encrypted inside the ciphertext C, why should it matter if you know also the randomness that was used to generate C? Yet there are quite a few places where our proofs brake down explicitly because of such reasons. Chalk it up to gaps in our current theory. _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Mon Mar 21 16:03:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22851 for ; Mon, 21 Mar 2005 16:03:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDU90-0001Dd-UK for cfrg-web-archive@ietf.org; Mon, 21 Mar 2005 16:09:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDTjY-0007Rc-DE; Mon, 21 Mar 2005 15:42:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDTjX-0007RX-8h for cfrg@megatron.ietf.org; Mon, 21 Mar 2005 15:42:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17295 for ; Mon, 21 Mar 2005 15:42:41 -0500 (EST) Received: from abraham.cs.berkeley.edu ([128.32.37.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDTof-0007Pc-31 for cfrg@ietf.org; Mon, 21 Mar 2005 15:48:01 -0500 Received: from news by abraham.cs.berkeley.edu with local (Exim 4.43) id 1DDTi6-0004V9-3E for cfrg@ietf.org; Mon, 21 Mar 2005 12:41:14 -0800 To: cfrg@ietf.org Path: not-for-mail From: daw@taverner.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ietf-cfrg Subject: Re: [Cfrg] RE: Who needs collision-resistance, anyway? Date: Mon, 21 Mar 2005 20:41:14 +0000 (UTC) Organization: University of California, Berkeley Lines: 37 Distribution: isaac Message-ID: References: <198A730C2044DE4A96749D13E167AD372500A9@MOU1WNEXMB04.vcorp.ad.vrsn.com> NNTP-Posting-Host: taverner.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1111437674 15778 128.32.168.222 (21 Mar 2005 20:41:14 GMT) X-Complaints-To: usenet@abraham.cs.berkeley.edu NNTP-Posting-Date: Mon, 21 Mar 2005 20:41:14 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: daw@taverner.cs.berkeley.edu (David Wagner) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Wagner List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Hallam-Baker, Phillip wrote: >The h (k || m) construction was rejected I believe because of a message >extension attack that had been discussed at the time. If I know h (k || m) >then I can calculate h (k || m || p || x) where p is the padding appended to >k || m in the digest iterator construct. I agree that h(k || m) has a length-extension property, just like h(m) does, but I'm pretty sure that's not what the paper [1] was talking about. If that is what the authors were thinking of, it's not apparent in the text of the paper. Personally, I don't think the length-extension property is sufficient reason to reject a hash. If it were, we'd have to reject MD5, SHA1, SHA-256, SHA-512, and every other MD-style hash out there. But we don't. The reason we don't is that it is not *that* hard to work around the length-extension property. You can design your protocol so that it can never get fooled by length-extension attacks (e.g., all inputs to the hash are of constant and known length). Or, you can use the hash in a way that prevents length-extension attacks (e.g., h(len(m) || m)). It's a pain in the neck, to be sure, but not an intolerable one. Perhaps what you are thinking of is that h(k || m) was rejected as a *message authentication code*. Instead, we chose HMAC, because it uses the hash function in a way that prevents length-extension attacks. However, message authentication codes are different from TCR functions, and when the IETF deliberated about how to turn a hash function into a MAC, we never considered the TCR application. Moreover, I'm pretty sure the paper [1] was not referring to length-extension attacks. So I don't see this as sufficient reason to reject SHA1* (for example). And, I don't think it is the reason that the paper was alluding to. P.S. Of course, if I were designing a new hash function, I would want to see any new design avoid length-extension properties. I do consider the length-extension property a design defect, albeit a minor one. Eliminating this defect simplifies the construction of secure protocols. _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Mon Mar 21 18:50:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14695 for ; Mon, 21 Mar 2005 18:50:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDWkv-0000AH-N4 for cfrg-web-archive@ietf.org; Mon, 21 Mar 2005 18:56:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDWe2-0003QS-3D; Mon, 21 Mar 2005 18:49:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDWe0-0003QN-Kq for cfrg@megatron.ietf.org; Mon, 21 Mar 2005 18:49:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14544 for ; Mon, 21 Mar 2005 18:49:09 -0500 (EST) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDWj9-0008WG-4h for cfrg@ietf.org; Mon, 21 Mar 2005 18:54:32 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j2LNmve2019724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Mar 2005 15:48:58 -0800 (PST) Received: from grose1.qualcomm.com (syd45.qualcomm.com [203.30.171.45]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j2LNmdLV000900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 21 Mar 2005 15:48:42 -0800 (PST) Message-Id: <6.2.1.2.2.20050321154411.04a33980@203.30.171.17> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 21 Mar 2005 15:48:06 -0800 To: csjutla From: Greg Rose Subject: Re: [Cfrg] RE: Who needs collision-resistance, anyway? In-Reply-To: <16959.5660.613357.509942@wasa.watson.ibm.com> References: <16959.5660.613357.509942@wasa.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-PMX-Version: 4.7.0.111621 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Greg Rose , cfrg@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 At 13:59 2005-03-21 -0500, you wrote: >In the TCR model, the adversary chooses M first, and then is given IV >(or key) and so he again tries the magic differential to get M' >and will succeed with prob epsilon. This ASSUMES that the magic >differential works equally well on all IV, and there is good reason to >believe this is indeed the case. I'm unaware of any such good reason. In fact Phil Hawkes' paper pretty much says the opposite. Given an IV, you can choose messages that cause the right conditions to occur, but the chances of tweaking an arbitrary message to get a collision are very small. Greg. Greg Rose INTERNET: ggr@qualcomm.com Qualcomm Incorporated VOICE: +1-858-651-5733 FAX: +1-858-651-5766 5775 Morehouse Drive http://people.qualcomm.com/ggr/ San Diego, CA 92121 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Mon Mar 21 19:05:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16056 for ; Mon, 21 Mar 2005 19:05:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDWzM-0000mU-El for cfrg-web-archive@ietf.org; Mon, 21 Mar 2005 19:11:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDWtn-000754-Mz; Mon, 21 Mar 2005 19:05:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDWtl-00074w-ON for cfrg@megatron.ietf.org; Mon, 21 Mar 2005 19:05:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15983 for ; Mon, 21 Mar 2005 19:05:26 -0500 (EST) Received: from igw2.watson.ibm.com ([129.34.20.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDWyu-0000lR-H5 for cfrg@ietf.org; Mon, 21 Mar 2005 19:10:49 -0500 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id j2M05JP71496 for ; Mon, 21 Mar 2005 19:05:19 -0500 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j2M05Ia53506 for ; Mon, 21 Mar 2005 19:05:18 -0500 Received: from mgsmtp00 (mgsmtp00.watson.ibm.com [9.2.40.58]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j2M05HG28252 for ; Mon, 21 Mar 2005 19:05:17 -0500 Received: from wasa.watson.ibm.com ([9.2.16.192]) by mgsmtp00.watson.ibm.com ID IMFd1111449750.1; Mon, 21 Mar 2005 19:02:30 -0400 Received: (from csjutla@localhost) by wasa.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) id j2M05F331872; Mon, 21 Mar 2005 19:05:15 -0500 From: csjutla MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 21 Mar 2005 19:05:05 -0500 (EST) To: Greg Rose Subject: Re: [Cfrg] RE: Who needs collision-resistance, anyway? In-Reply-To: <6.2.1.2.2.20050321154411.04a33980@203.30.171.17> References: <16959.5660.613357.509942@wasa.watson.ibm.com> <6.2.1.2.2.20050321154411.04a33980@203.30.171.17> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <16959.24422.458142.427888@wasa.watson.ibm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: cfrg@ietf.org, csjutla X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Greg Rose writes: > At 13:59 2005-03-21 -0500, you wrote: > >In the TCR model, the adversary chooses M first, and then is given IV > >(or key) and so he again tries the magic differential to get M' > >and will succeed with prob epsilon. This ASSUMES that the magic > >differential works equally well on all IV, and there is good reason to > >believe this is indeed the case. > > I'm unaware of any such good reason. In fact Phil Hawkes' paper > pretty much says the opposite. Given an > IV, you can choose messages that cause the right conditions to occur, but > the chances of tweaking an arbitrary message to get a collision are very small. This is not an arbitrary message. Note the adversary chose the first message too, so he could have chosen it from the space of problematic messages. Again, this assumes that the space of problematic messages is independent of IV. If that is not the case, then fine, the TCR is better off. Definitely for SHA-0, as shown by Chabaud and Joux 98, there is a space of problematic messages independent of IV. What the new attacks reveal, we will find out soon. Hopefully. Charanjit Jutla > > Greg. > > Greg Rose INTERNET: ggr@qualcomm.com > Qualcomm Incorporated VOICE: +1-858-651-5733 FAX: +1-858-651-5766 > 5775 Morehouse Drive http://people.qualcomm.com/ggr/ > San Diego, CA 92121 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Mon Mar 21 19:09:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16325 for ; Mon, 21 Mar 2005 19:09:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDX2w-0000qK-Lh for cfrg-web-archive@ietf.org; Mon, 21 Mar 2005 19:14:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDWwJ-0007hE-4J; Mon, 21 Mar 2005 19:08:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDWwH-0007gX-K7 for cfrg@megatron.ietf.org; Mon, 21 Mar 2005 19:08:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16214 for ; Mon, 21 Mar 2005 19:08:02 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDX1N-0000oj-8Z for cfrg@ietf.org; Mon, 21 Mar 2005 19:13:25 -0500 Received: from phys-san-2 ([129.153.85.71]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j2M07uZQ003774 for ; Mon, 21 Mar 2005 16:07:57 -0800 (PST) Received: from conversion-daemon.san-mail1.west.sun.com by san-mail1.west.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IDQ008018AM8T@san-mail1.west.sun.com> (original mail from David.Jacobson@Sun.COM) for cfrg@ietf.org; Mon, 21 Mar 2005 16:07:56 -0800 (PST) Received: from Sun.COM (sr1-usan-05.West.Sun.COM [129.153.85.35]) by san-mail1.west.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IDQ00KBV8D3PX@san-mail1.west.sun.com>; Mon, 21 Mar 2005 16:07:51 -0800 (PST) Date: Mon, 21 Mar 2005 16:07:51 -0800 From: david jacobson Subject: Re: use of hash functions _in_ CPRNGs (Re: [Cfrg] RE: Who needs collision-resistance, anyway?) In-reply-to: <20050321184213.GA11213@bitchcake.off.net> To: Adam Back Message-id: <423F61D7.8090109@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 References: <4181a576bbb6d04a3095d1d1f1062314@comcast.net> <423F0A96.4070209@Sun.COM> <20050321184213.GA11213@bitchcake.off.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: 7BIT Cc: cfrg@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David.Jacobson@Sun.COM List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: 7BIT Sure, cryptographic pseudo-random (deterministic) random number generators use hash functions or encryption. Cryptography true random number generators can also use hash functions or encryption. I was mainly discussing true random number generators. You seemed to be heading off to CPRNGs. Nevertheless, I'm going to head back to true random number generators. The main reason is that with a true RNG we won't get bogged down on the argument over wether the generator is attackable. The Broadcom 5821 is a cryptographic quality true random number generator. Actually, I don't want to talk about that as I'm under an NDA agreement, and don't know for sure what I can say and what I can't say. But a spec sheet for the slightly older 5820 is available on the Broadcom web site (registration required). So I think there could be no problem with me discussing that. The 5820 has a thermal noise generator, the output of which Broadcom claims is good enough to pass the FIPS 140-1 and FIPS 140-2 requirements for self testing. (I presume that was before FIPS 140-2 was updated to remove almost all RNG self testing requirements.) These bits are collected into chunks of 512 bits, and each chunks is run through SHA-1, resulting in 160 bits. This requires one hash for every 160 cryptographic-quality bits. One of the random number generators approved by FIPS 140-2 is that one in FIPS 186-2 appendix 3.2 with the mod q step (for DSA) elided. (Eliding the mod q step is allowed by Implemetation Guidance for FIPS PUB 140-1 and Crytpographic Module Validation Program section 8.9, if the numbers are not for use by DSA.) It uses a combination of the guts of SHA-1 combined with 160-bit arithemetic to generate random numbers. (Details below.) It has provision for additional entropy to be stirred in at each round. So, with no entropy, it is a CPRNG. Or you can add 160 bits each round and have a cryptographic quality true random number generator. The exact algorithm for one round is this. All UPPERCASE variables are 160 bits wide. So "+" is 160-bit arithmetic. The value of X is the random data that is returned to the caller. The state is kept in a variable called XKEY, which is initialized with seed matrial. XSEED is just zero in the PRNG case. XSEED = <<>>; XVAL = XKEY + XSEED; X = SHA1star(XVAL || 352ZeroBits) XKEY = (XKEY + 1 + X) mod 2**160. /* no explicit mod; carries just get lost */ SHA-1star is steps (a)-(e) of the SHA-1 spec. It is just SHA-1 but leaving out all the stuff you need for multiple blocks, fractional blocks, and making the length contribute to the hash. (This stuff about the how steps (a)-(e) differ from the whole SHA-1 is from memory; I might have it slightly wrong.) I'm quite sure full SHA-1 is just as secure. Again 1 hash for 160 bits of random data. One approved algorithm that will appear in the new ANSI X9.82 standard will just hash old state to new state. It will also have an "output function" to obfuscate the state. I think it will allow new entropy to be stirred in. I'm not sure whether the standard will call for the new entropy to be concatentated to the state, or combined with XOR. (I doubt it matters.) Other people on this list are closer to the workings of the committee on this. I'm not quite sure what the output function will be. Presuming it is also a hash, this costs two hashes for 160 bits. Bottom line, you can get cryptographic quality random numbers at a cost of about 1 hash for every hash-block-sized chunk of output. -- David Jacobson Adam Back wrote: > Re. the comments about RNG cost (hardware or software) isn't it usual > for such output to be whitened through a hash function, such as eg > SHA1. > > (Thinking eg of the Intel RNG that Paul Kocher/Cryptography Research > reviewed.) > > /dev/urandom implementation also involves hash functions as do many > other CPRNG. > > This to me somewhat calls into doubts the claims that CPRNGs as > suitable for creating bits for input to strengthen hash functions > have negligible cost. > > (Of course the cost is amortized across large messages, but not all > messages are large). > > Adam > > On Mon, Mar 21, 2005 at 09:55:34AM -0800, david jacobson wrote: > >>A Broadcom 5821 chip will produce over 1 megabit per second of true >>random output, and this chip is several years old now. I don't believe >>that random number generation (yes, cryptography quality random number >>generation) is all that hard. > > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Mon Mar 21 19:22:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17259 for ; Mon, 21 Mar 2005 19:22:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDXFt-0001Fr-PX for cfrg-web-archive@ietf.org; Mon, 21 Mar 2005 19:28:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDX9Q-0001Y1-D7; Mon, 21 Mar 2005 19:21:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDX9O-0001Xu-Ts for cfrg@megatron.ietf.org; Mon, 21 Mar 2005 19:21:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17127 for ; Mon, 21 Mar 2005 19:21:35 -0500 (EST) Received: from abraham.cs.berkeley.edu ([128.32.37.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDXEY-0001BA-Pf for cfrg@ietf.org; Mon, 21 Mar 2005 19:26:59 -0500 Received: from news by abraham.cs.berkeley.edu with local (Exim 4.43) id 1DDX7x-00064I-5z for cfrg@ietf.org; Mon, 21 Mar 2005 16:20:09 -0800 To: cfrg@ietf.org Path: not-for-mail From: daw@taverner.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ietf-cfrg Subject: Re: [Cfrg] RE: Who needs collision-resistance, anyway? Date: Tue, 22 Mar 2005 00:20:09 +0000 (UTC) Organization: University of California, Berkeley Lines: 51 Distribution: isaac Message-ID: References: <16959.5660.613357.509942@wasa.watson.ibm.com> <6.2.1.2.2.20050321154411.04a33980@203.30.171.17> NNTP-Posting-Host: taverner.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1111450809 23329 128.32.168.222 (22 Mar 2005 00:20:09 GMT) X-Complaints-To: usenet@abraham.cs.berkeley.edu NNTP-Posting-Date: Tue, 22 Mar 2005 00:20:09 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: daw@taverner.cs.berkeley.edu (David Wagner) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Wagner List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Charanjit Jutla writes: > In the TCR model, the adversary chooses M first, and then is given IV > (or key) and so he again tries the magic differential to get M' > and will succeed with prob epsilon. This ASSUMES that the magic > differential works equally well on all IV, and there is good reason to > believe this is indeed the case. > > Hence the rejection of MD5*. That assumption doesn't sound like a good one to me. After reading the paper on cryptanalysis of MD5 by Wang and Yu, it does not look to me like their attack works in this way. I think they rely crucially on knowledge of the IV. In particular, they choose a magic differential. However, their differential has a very low probability, and it only works if a whole bunch of conditions on the message bits are satisfied. Then they pick a message which satisfies these conditions. Even this still has too low a probability, so they derive some ways to start with such a message and modify it to bypass a round or two for free. See their section on multi-message modifications. To put it another way, their attack seems to succeed at breaking the collision-resistance, but they don't claim that it breaks the second preimage resistance of the hash function. If there were a magic differential that worked for all messages (and didn't require their constraints and message modification techniques), then second preimage resistance would be broken. Second preimage resistance is indeed a necessary condition for TCR security. In previous work, Dobbertin has a successful second pre-image attack on MD4. This means that there is no hope for MD4 to be TCR-secure. Reading the paper by Wang, Lai, Feng, Chen, and Yu on MD4, they say that they applied their techniques to MD4, and got a different second pre-image attack on MD4. However, their attack only works for a 2^-122 fraction of messages M. They report briefly in the conclusion that there is an improvement due to Yu, Wang, et al which improves this to 2^-72, and that for SHA-0, it is 2^-107. I don't see any other discussion of the possibility of second pre-image attacks on MD5 or SHA1 in their paper, and I don't see any discussion of the TCR property. Presumably this will require some analysis. It could well turn out that their techniques generalize to also find second pre-images and break the TCR property, but I don't think it follows trivially from the existence of collisions. Likewise, I don't think we can reject SHA1* out of hand based merely on the existence of collisions (even ones based on differential analysis). http://www.infosec.sdu.edu.cn/paper/md5-attack.pdf http://www.infosec.sdu.edu.cn/paper/md4-ripemd-attck.pdf http://www.infosec.sdu.edu.cn/people/wangxiaoyun.htm _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Mon Mar 21 19:31:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17757 for ; Mon, 21 Mar 2005 19:31:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDXOD-0001WC-C4 for cfrg-web-archive@ietf.org; Mon, 21 Mar 2005 19:36:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDXID-0003AW-LA; Mon, 21 Mar 2005 19:30:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDXIC-0003AR-3T for cfrg@megatron.ietf.org; Mon, 21 Mar 2005 19:30:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17722 for ; Mon, 21 Mar 2005 19:30:40 -0500 (EST) Received: from off.net ([66.96.28.3] helo=mail.off.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDXNL-0001SH-1O for cfrg@ietf.org; Mon, 21 Mar 2005 19:36:04 -0500 Received: by mail.off.net (Postfix, from userid 948) id 73CA3770007; Mon, 21 Mar 2005 19:30:33 -0500 (EST) Received: by bitchcake.off.net (hashcash-sendmail, from uid 948); Mon, 21 Mar 2005 19:30:25 -0500 Date: Mon, 21 Mar 2005 19:30:25 -0500 From: Adam Back To: david jacobson Subject: Re: use of hash functions _in_ CPRNGs (Re: [Cfrg] RE: Who needs collision-resistance, anyway?) Message-ID: <20050322003025.GA20901@bitchcake.off.net> References: <4181a576bbb6d04a3095d1d1f1062314@comcast.net> <423F0A96.4070209@Sun.COM> <20050321184213.GA11213@bitchcake.off.net> <423F61D7.8090109@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <423F61D7.8090109@Sun.COM> User-Agent: Mutt/1.4.1i X-Hashcash: 1:20:050322:david.jacobson@sun.com::Vpl1Opf2eyH6iZxc:m02 X-Hashcash: 1:20:050322:cfrg@ietf.org::CJi/1FbTsarnvFTJ:Rqm X-Hashcash: 1:20:050322:adam@cypherspace.org::brwAVp5rxiMxfMwL:6xZ8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: cfrg@ietf.org, Adam Back X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Yep. Coincidentally I implemented this same FIPS 186-2 RNG variant for someone needing CC certification. (SHA1 based G function, variant with no mod q step). This RNG could be considered either a CPRNG or a RNG depending on how you use it. (The way I used it it was a CPRNG, pure software). Confirms the aspect that even the hardware "true" RNGs in practice use hash functions on output. (And I guess sometimes the hash is hw also sometimes in software). Adam On Mon, Mar 21, 2005 at 04:07:51PM -0800, david jacobson wrote: > Sure, cryptographic pseudo-random (deterministic) random number > generators use hash functions or encryption. Cryptography true random > number generators can also use hash functions or encryption. > > The Broadcom 5821 is a cryptographic quality true random number > generator. Actually, I don't want to talk about that as I'm under an > NDA agreement, and don't know for sure what I can say and what I can't > say. > > But a spec sheet for the slightly older 5820 is available on the > Broadcom web site (registration required). So I think there could be no > problem with me discussing that. > > The 5820 has a thermal noise generator, the output of which Broadcom > claims is good enough to pass the FIPS 140-1 and FIPS 140-2 requirements > for self testing. (I presume that was before FIPS 140-2 was updated to > remove almost all RNG self testing requirements.) These bits are > collected into chunks of 512 bits, and each chunks is run through SHA-1, > resulting in 160 bits. > > This requires one hash for every 160 cryptographic-quality bits. > > [...] _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Fri Mar 25 03:17:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26295 for ; Fri, 25 Mar 2005 03:17:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEk6p-0006gv-2C for cfrg-web-archive@ietf.org; Fri, 25 Mar 2005 03:23:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEjz8-0006Bl-1A; Fri, 25 Mar 2005 03:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEjz6-0006Be-Al for cfrg@megatron.ietf.org; Fri, 25 Mar 2005 03:16:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26054 for ; Fri, 25 Mar 2005 03:15:58 -0500 (EST) Received: from abraham.cs.berkeley.edu ([128.32.37.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEk4w-0006dm-6B for cfrg@ietf.org; Fri, 25 Mar 2005 03:22:03 -0500 Received: from news by abraham.cs.berkeley.edu with local (Exim 4.43) id 1DEjxZ-0001NK-4M for cfrg@ietf.org; Fri, 25 Mar 2005 00:14:25 -0800 To: cfrg@ietf.org Path: not-for-mail From: daw@taverner.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ietf-cfrg Subject: Re: [Cfrg] RE: Who needs collision-resistance, anyway? Date: Fri, 25 Mar 2005 08:14:25 +0000 (UTC) Organization: University of California, Berkeley Lines: 13 Distribution: isaac Message-ID: References: <4181a576bbb6d04a3095d1d1f1062314@comcast.net> NNTP-Posting-Host: taverner.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1111738465 4964 128.32.168.222 (25 Mar 2005 08:14:25 GMT) X-Complaints-To: usenet@abraham.cs.berkeley.edu NNTP-Posting-Date: Fri, 25 Mar 2005 08:14:25 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: daw@taverner.cs.berkeley.edu (David Wagner) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Wagner List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Charanjit Jutla wrote: > Again, this assumes that the space of problematic messages > is independent of IV. If that is not the case, then fine, the TCR is > better off. Yes, what I am saying is that this does not seem to be the case for the recent attacks on MD5 and SHA1. That's as far as I can tell, anyway -- I don't entirely understand the attacks, so I could be wrong, but that is my current working understanding. It is always possible that those attacks could be extended so that the space of problematic messages is independent of IV; I don't know the attacks well enough to know how plausible this might be. _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Fri Mar 25 10:33:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07464 for ; Fri, 25 Mar 2005 10:33:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEqu2-0002zv-DZ for cfrg-web-archive@ietf.org; Fri, 25 Mar 2005 10:39:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEqn0-000309-Ay; Fri, 25 Mar 2005 10:31:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEqmz-000304-76 for cfrg@megatron.ietf.org; Fri, 25 Mar 2005 10:31:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07339 for ; Fri, 25 Mar 2005 10:31:55 -0500 (EST) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DEqsq-0002yP-I8 for cfrg@ietf.org; Fri, 25 Mar 2005 10:38:03 -0500 Received: (qmail 18124 invoked by uid 0); 25 Mar 2005 15:31:43 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.138.52) by woodstock.binhost.com with SMTP; 25 Mar 2005 15:31:43 -0000 Message-Id: <6.2.0.14.2.20050325102835.04366080@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 25 Mar 2005 10:31:44 -0500 To: "Steven M. Bellovin" From: Russ Housley Subject: Re: [Cfrg] Who needs collision-resistance, anyway? In-Reply-To: <20050318202108.8CF713C02A1@berkshire.machshav.com> References: <20050318202108.8CF713C02A1@berkshire.machshav.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: cfrg@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Steve: Signing the ciphertext is a big problem in many situations. Whenever you want to save the signed message for proof, then one needs to have a signature on the plaintext so that it can be presented to a 3rd party. Russ At 03:21 PM 3/18/2005, Steven M. Bellovin wrote: >Correct me if I'm wrong, but I thought that preference these days was >to sign the ciphertext, not the plaintext. The presence of an IV in >the encryption (or, for that matter, the use of a new key) will cause >the ciphertext to vary, of course. (Yes, I know that S/MIME can do the >signing and encryption in either order.) _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Fri Mar 25 12:49:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22691 for ; Fri, 25 Mar 2005 12:49:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEt1u-0007nJ-D4 for cfrg-web-archive@ietf.org; Fri, 25 Mar 2005 12:55:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEsv7-0008Po-EB; Fri, 25 Mar 2005 12:48:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEsv5-0008Pa-Sj for cfrg@megatron.ietf.org; Fri, 25 Mar 2005 12:48:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22648 for ; Fri, 25 Mar 2005 12:48:24 -0500 (EST) Received: from ylpvm15-ext.prodigy.net ([207.115.57.46] helo=ylpvm15.prodigy.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEt11-0007mI-Ay for cfrg@ietf.org; Fri, 25 Mar 2005 12:54:35 -0500 Received: from [192.168.0.100] (adsl-67-118-213-120.dsl.scrm01.pacbell.net [67.118.213.120]) by ylpvm15.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j2PHiQba006706 for ; Fri, 25 Mar 2005 12:44:26 -0500 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: cfrg@ietf.org From: Ted Krovetz Date: Fri, 25 Mar 2005 09:48:25 -0800 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Subject: [Cfrg] OCB Mode Internet-Draft Available X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Hello, OCB, an authenticated-encryption mode of operation from Rogaway, Bellare and Black has been revised and defined in an Internet-Draft. The new version is being called OCB 2.0. http://www.ietf.org/internet-drafts/draft-krovetz-ocb-00.txt Any comments on the draft, including verification of the test vectors, would be appreciated. There were no security reasons for the revision. The newer version is more efficient and versatile. * OCB 1.0 could not directly handle associated-data; OCB 2.0 has this capability. Associated-data refers to an unencrypted header that should be authenticated but not encrypted when one encrypts a message. Only after releasing OCB 1.0 was it realized that it was important to directly build in this capability. * The second reason for the update is that a cleaner way was found to create the sequence of internal offsets that are needed. The new method is simple and constant-time. The old method, which depended on Gray codes and the number of trailing zero bits in the representation of successive integers, was more complex to understand and to implement. OCB 2.0 was first specified in late 2003. It was named AEM (authenticated-encryption mode, or advanced encryption mode) for a short while. It was later renamed OCB 2.0 to make its lineage more clear: the differences between OCB 1.0 and OCB 2.0 are small. There is a FAQ on OCB, as well as other goodies, at http://www.cs.ucdavis.edu/~rogaway/ocb/ Thank you, Ted Krovetz Computer Science Department California State University, Sacramento _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Fri Mar 25 14:45:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03806 for ; Fri, 25 Mar 2005 14:45:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEupz-0002u8-VZ for cfrg-web-archive@ietf.org; Fri, 25 Mar 2005 14:51:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEuhx-00081M-Tz; Fri, 25 Mar 2005 14:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEuhw-00080r-AE for cfrg@megatron.ietf.org; Fri, 25 Mar 2005 14:43:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03590 for ; Fri, 25 Mar 2005 14:42:58 -0500 (EST) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DEunq-0002pI-NE for cfrg@ietf.org; Fri, 25 Mar 2005 14:49:09 -0500 Received: (qmail 13233 invoked by uid 0); 25 Mar 2005 19:42:41 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.127.8) by woodstock.binhost.com with SMTP; 25 Mar 2005 19:42:41 -0000 Message-Id: <6.2.0.14.2.20050325143508.06dd99e0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 25 Mar 2005 14:36:53 -0500 To: Ted Krovetz , cfrg@ietf.org From: Russ Housley Subject: Re: [Cfrg] OCB Mode Internet-Draft Available In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Ted: For this to proceed to publication as an RFC, an IPR statement must be submitted to the IETF Secretariat. I think the statement should come from Phil. See https://datatracker.ietf.org/public/ipr_disclosure.cgi Russ At 12:48 PM 3/25/2005, Ted Krovetz wrote: >Hello, > >OCB, an authenticated-encryption mode of operation from Rogaway, Bellare >and Black has been revised and defined in an Internet-Draft. The new >version is being called OCB 2.0. > > http://www.ietf.org/internet-drafts/draft-krovetz-ocb-00.txt > >Any comments on the draft, including verification of the test vectors, >would be appreciated. > >There were no security reasons for the revision. The newer version is more >efficient and versatile. > >* OCB 1.0 could not directly handle associated-data; OCB 2.0 has this >capability. Associated-data refers to an unencrypted header that should be >authenticated but not encrypted when one encrypts a message. Only after >releasing OCB 1.0 was it realized that it was important to directly build >in this capability. > >* The second reason for the update is that a cleaner way was found to >create the sequence of internal offsets that are needed. The new method is >simple and constant-time. The old method, which depended on Gray codes and >the number of trailing zero bits in the representation of successive >integers, was more complex to understand and to implement. > >OCB 2.0 was first specified in late 2003. It was named AEM >(authenticated-encryption mode, or advanced encryption mode) for a short >while. It was later renamed OCB 2.0 to make its lineage more clear: the >differences between OCB 1.0 and OCB 2.0 are small. > >There is a FAQ on OCB, as well as other goodies, at > > http://www.cs.ucdavis.edu/~rogaway/ocb/ > >Thank you, >Ted Krovetz >Computer Science Department >California State University, Sacramento > > >_______________________________________________ >Cfrg mailing list >Cfrg@ietf.org >https://www1.ietf.org/mailman/listinfo/cfrg > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Fri Mar 25 19:13:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03453 for ; Fri, 25 Mar 2005 19:13:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEz1I-0004Jr-I1 for cfrg-web-archive@ietf.org; Fri, 25 Mar 2005 19:19:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEysQ-0006TK-L8; Fri, 25 Mar 2005 19:10:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEysQ-0006TF-2d for cfrg@megatron.ietf.org; Fri, 25 Mar 2005 19:10:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02967 for ; Fri, 25 Mar 2005 19:10:02 -0500 (EST) Received: from stoneport.math.uic.edu ([131.193.178.160]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DEyyN-0004CM-UO for cfrg@ietf.org; Fri, 25 Mar 2005 19:16:17 -0500 Received: (qmail 73704 invoked by uid 1016); 26 Mar 2005 00:15:54 -0000 Date: 26 Mar 2005 00:15:54 -0000 Message-ID: <20050326001554.73703.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: cfrg@ietf.org Subject: Re: [Cfrg] OCB Mode Internet-Draft Available References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 The draft says that OCB is the most efficient solution available, but doesn't give any comparative timings to back this up! I'm particularly concerned about (1) the overhead for the ``fixed number of logical operations,'' (2) the overhead for small packets, (3) the overhead for expanding or loading decryption keys, and (4) the cost of rejecting forgeries---does this require decryption? There's nothing wrong with a document that defines the function without commenting on speed, but a document that makes a bold claim about ``the most efficient way known'' has to go into considerably more detail. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Fri Mar 25 23:37:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25774 for ; Fri, 25 Mar 2005 23:37:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DF39U-0004zO-HD for cfrg-web-archive@ietf.org; Fri, 25 Mar 2005 23:44:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DF31e-0005Uw-Bj; Fri, 25 Mar 2005 23:35:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DF31c-0005U3-7O for cfrg@megatron.ietf.org; Fri, 25 Mar 2005 23:35:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25470 for ; Fri, 25 Mar 2005 23:35:43 -0500 (EST) Received: from mailhost.auckland.ac.nz ([130.216.190.12] helo=smtpb.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DF37W-0004rR-95 for cfrg@ietf.org; Fri, 25 Mar 2005 23:41:59 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id BB23634514; Sat, 26 Mar 2005 16:35:31 +1200 (NZST) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18621-17; Sat, 26 Mar 2005 16:35:31 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id A0801343DF; Sat, 26 Mar 2005 16:35:31 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 79F5D37743; Sat, 26 Mar 2005 16:35:31 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DF31M-0004E0-00; Sat, 26 Mar 2005 16:35:36 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: cfrg@ietf.org, tdk@csus.edu Subject: Re: [Cfrg] OCB Mode Internet-Draft Available In-Reply-To: Message-Id: Date: Sat, 26 Mar 2005 16:35:36 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.9 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Ted Krovetz writes: >OCB, an authenticated-encryption mode of operation from Rogaway, >Bellare and Black has been revised and defined in an Internet-Draft. >The new version is being called OCB 2.0. This algorithm, *and* the ginsu knives, can be yours for a mere $100-200K in licensing fees! (Please, no patent flamewars, just pointing out that against unrestricted modes like CCM and GCM it doesn't stand much chance). Peter. _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From cfrg-bounces@ietf.org Tue Mar 29 16:00:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24617 for ; Tue, 29 Mar 2005 16:00:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGNvd-0007Tk-V0 for cfrg-web-archive@ietf.org; Tue, 29 Mar 2005 16:07:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGNlU-00045J-2V; Tue, 29 Mar 2005 15:56:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGNlS-00045E-Co for cfrg@megatron.ietf.org; Tue, 29 Mar 2005 15:56:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24191 for ; Tue, 29 Mar 2005 15:56:40 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGNsD-0007OT-O5 for cfrg@ietf.org; Tue, 29 Mar 2005 16:03:43 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 29 Mar 2005 12:55:57 -0800 X-IronPort-AV: i="3.91,131,1110182400"; d="scan'208"; a="242514337:sNHT3874658090" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2TKttDr010198; Tue, 29 Mar 2005 12:55:55 -0800 (PST) Received: from [10.32.254.211] (stealth-10-32-254-211.cisco.com [10.32.254.211]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id BDK94156; Tue, 29 Mar 2005 12:55:54 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <75a01f6f84bc119efca3e25998ef46e4@cisco.com> Content-Transfer-Encoding: 7bit From: "David A. McGrew" Date: Tue, 29 Mar 2005 12:55:54 -0800 To: "'cfrg@ietf.org'" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Subject: [Cfrg] Fwd: [saag] Attacks on Cryptographic Hashes in Internet Protocols X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: cfrg-bounces@ietf.org Errors-To: cfrg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit FYI: relevant new ID. David Begin forwarded message: > From: Paul Hoffman > Date: March 29, 2005 12:27:03 PM PST > To: saag@mit.edu > Subject: [saag] Attacks on Cryptographic Hashes in Internet Protocols > > Greetings again. Bruce Schneier and I have written a draft on the > status of hashes in protocols based on the recent attacks. The -00 > version can be found at > -00.txt>. > > Our intent is to help lay out the currently-known facts in one place > so that protocol developers can decide how to respond to the new > information. As you can see from Section 6, we do not agree on what to > do with those facts; maybe the SAAG list can help weigh the > alternatives. > > We welcome comments on the draft. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > saag mailing list > saag@mit.edu > https://jis.mit.edu/mailman/listinfo/saag > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg