Re: Report of collision-generation with MD5

From: Neo-Vortex (root_at_Neo-Vortex.Ath.Cx)
Date: 08/26/04

  • Next message: Jan Grant: "Re: Report of collision-generation with MD5" 
    Date: Thu, 26 Aug 2004 18:53:52 +1000 (EST)
To: Peter Jeremy <PeterJeremy@optushome.com.au>

    On Thu, 26 Aug 2004, Peter Jeremy wrote:

    > On Wed, 2004-Aug-25 13:16:40 -0700, Brooks Davis wrote:
    > >On Wed, Aug 25, 2004 at 09:51:50PM +0200, guy@device.dyndns.org wrote:
    > >> I _believe_ answer is "no", because i _think_ the FreeBSD ports system also
    > >> verify the size of the archive(s) (cat /usr/ports/any/any/distinfo to see
    > >> what made me think that).
    >
    > I don't believe the size adds much security.
    it makes it harder for the person, it limits them in what they can do, it
    also picks up files whos download was interupted...

    > >Paranoia might suggest adding support for multiple hashes which would
    > >vastly increase the difficulty of finding a collision
    >
    > I'd agree with this. Identifying suitable hashes is a more difficult task.
    sha-1? rmd160?

    > >Hmm, one thing to think about might be making sure the various archive
    > >formats are hard to pad with junk. I think the stream based ones need
    > >to allow zero pading at the end to support tapes, but it would be
    > >intresting to see if other junk can end up in pading sections without
    > >the archiver noticing. If so, that would be a good thing to find a way
    > >to detect.
    >
    > tar uses one (or two) blocks of NULs to mark logical EOF - anything
    > beyond that is ignored. gzip ignores (but warns) about padding after
    > its expected EOF. I'm not sure about bzip2. I suspect it would be
    > possibly to include arbitrary padding inside a ZIP file, though
    > probably not at the end. This would make it relatively easy to pad a
    > trojan'd file to any desired size.
    here is where the size thing comes in... if they have to add padding then
    it makes it harder (because of warnings, etc)
    _______________________________________________
    freebsd-security@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-security
    To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"

  • Next message: Jan Grant: "Re: Report of collision-generation with MD5"

    Relevant Pages

    • Re: problem with DES (Data Encryption Standard)
      ... > This is why I say the user must pad the data. ... > whose value is the number of padding chars used. ... This isn't a great practice when working with binary data -- any binary data a multiple of the block length that happens to end with the byte 0x01, for example, will be corrupted. ... Another suggestion on this thread was to pad with 0xFF -- such a scheme is also not reversible and would corrupt binary data. ...
      (comp.lang.tcl)
    • Re: Congrats India
      ... batsmen in his 90s padding up to the bowling anyway! ... the pad and the batsman is given out lbw then one can hardly say that using ... Whatever the merits of the lbw, Tendulkar made an error of judgement. ...
      (rec.sport.cricket)
    • Re: [PATCH] 2.6.x BSD Process Accounting w/High UID
      ... > We might, however, put the magic into the implicit padding ... none of this matters much if the format ... Regarding the existing struct though... ... // hppa might pad this ...
      (Linux-Kernel)
    • Re: Testing iso downloads?
      ... The cure that has worked for me is to pad the .iso with zero blocks. ... I've enclosed a script that I call "isopad". ... this adds and removes padding to your .iso file in-place. ...
      (Fedora)
    • Re: problem with DES (Data Encryption Standard)
      ... It appears that DES automatically pads it with "\0" for you by default. ... This is why I say the user must pad the data. ... The crypto algorithm ... By padding the block on behalf ...
      (comp.lang.tcl)