Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.albasani.net!rt.uk.eu.org!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.004 X-Spam-Evidence: '*H*': 0.99; '*S*': 0.00; 'subject:error': 0.03; 'subject:not': 0.03; 'broken': 0.04; 'binary': 0.07; 'detect': 0.07; 'truncated': 0.09; 'cc:addr:python-list': 0.11; 'changes': 0.15; 'arbitrarily': 0.16; 'attempted': 0.16; 'different,': 0.16; 'does,': 0.16; 'effect.': 0.16; 'expecting': 0.16; 'files)': 0.16; 'from:addr:rosuav': 0.16; 'from:name:chris angelico': 0.16; 'md5': 0.16; 'subject:key': 0.16; 'subject:when': 0.16; 'substitution': 0.16; 'usable': 0.16; 'prevent': 0.16; 'sat,': 0.16; 'wrote:': 0.18; 'trying': 0.19; 'file,': 0.19; 'server,': 0.19; 'aug': 0.22; 'hack': 0.22; 'cc:addr:python.org': 0.22; 'aspect': 0.24; 'instead.': 0.24; 'proxy': 0.24; 'tells': 0.24; 'cc:2**0': 0.24; 'downloaded': 0.26; 'certain': 0.27; 'header:In-Reply-To:1': 0.27; 'am,': 0.29; 'errors': 0.30; 'message-id:@mail.gmail.com': 0.30; 'that.': 0.31; 'changed.': 0.31; "d'aprano": 0.31; 'relies': 0.31; 'safely': 0.31; 'steven': 0.31; 'file': 0.32; 'there.': 0.32; 'probably': 0.32; 'quite': 0.32; 'actual': 0.34; 'could': 0.34; 'requirement': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'there': 0.35; 'passwords': 0.36; 'should': 0.36; 'easily': 0.37; 'being': 0.38; 'mine': 0.38; 'somebody': 0.38; 'files': 0.38; 'issue': 0.38; 'anything': 0.39; 'does': 0.39; 'though,': 0.39; 'sure': 0.39; 'either': 0.39; 'even': 0.60; 'skip:u 10': 0.60; 'worry': 0.60; 'simple': 0.61; "you're": 0.61; 'first': 0.61; 'happen': 0.63; 'became': 0.64; 'sum': 0.64; 'different': 0.65; 'between': 0.67; 'carefully': 0.74; 'obvious': 0.74; 'transfer': 0.82; 'collision': 0.84; 'crafted': 0.84; 'capture': 0.91; 'involved.': 0.91; 'to:none': 0.92 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=4msfQwo3xp1KFStzByxycxxdR4TL90TsF+fsglFZwOw=; b=exJpKQtN/NiflXmTId8V6BzwmgqEZnOO0W8a7mUkUK/ZeUoK/KYJVVCpcI/GrmZxDc i2GRrMvFaLl0aIDE8L2WlZwyV+EZDBIST+1nhzdEWUsPLYvQluwlX9miv+R7ua5OfVpz ZS60qJgusKWmXlCqM/wxr+Ja96xiYnnZCIDNAK4LNM+gPbqNCYTqKJbiqCtBTLVPzurl ITQlFXmOEWXrakTH+h+wRKCPaoxPTV+baBgVFakSjp3WWnGpx76ishAFLadDw1jQX4WX XHkA5ZygkVMFLOWDyk7UVQW6p2qlOXOXUK+OKkACTpetGeCJ61tgawJYLa5EMbQ8ssen T+gQ== MIME-Version: 1.0 X-Received: by 10.43.96.65 with SMTP id cf1mr11941899icc.26.1406945607135; Fri, 01 Aug 2014 19:13:27 -0700 (PDT) In-Reply-To: <53dc433b$0$29979$c3e8da3$5496439d@news.astraweb.com> References: <53db11c1$0$29986$c3e8da3$5496439d@news.astraweb.com> <53db96bc$0$29986$c3e8da3$5496439d@news.astraweb.com> <87vbqcnrrh.fsf@elektro.pacujo.net> <53dc433b$0$29979$c3e8da3$5496439d@news.astraweb.com> Date: Sat, 2 Aug 2014 12:13:27 +1000 Subject: Re: Dict when defining not returning multi value key error From: Chris Angelico Cc: "python-list@python.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 35 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1406945609 news.xs4all.nl 2882 [2001:888:2000:d::a6]:42963 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:75511 On Sat, Aug 2, 2014 at 11:47 AM, Steven D'Aprano wrote: > - It relies on the checksum being unpredictable, to prevent substitution > attacks: you're expecting object x with checksum a, but somebody > substitutes object y with checksum a instead. Note that this requirement is only an issue when there are actual attacks involved. In many cases, hashing is used to detect either errors in transfer (eg truncated files) or meaningfully different files (eg MP3s of different songs). A collision between those won't be the result of someone deliberately crafting a file with the right checksum; it'll happen only by chance, so md5sum can be safely used there. But if you're trying to use this to prove that a file was downloaded correctly, you do need to worry about that. If I say that you can download the binary of my program from , and that the MD5 checksum is 123456...DEF, then someone could do a DNS hack (cache poisoning, proxy interference, whatever) to capture your attempted download, and send you instead to his own server, where he has a carefully crafted binary that does everything mine does, plus it tells him all your passwords - and it has arbitrary junk buried in it to make sure the MD5 sum matches. So an MD5 checksum is broken for anything from the internet, but is quite usable for certain specific cases. There is one aspect of the unpredictability that's important even in the simple cases, though, and that's the avalanche effect. If anything changes in the file, the whole hash should completely and arbitrarily change. That means you don't need to stare at the whole hash, trying to see if that 8 became a 0; any change to the file will probably make the first few digits visibly different, so it's easily obvious that the hash has changed. ChrisA