[delphizip] Re: Password checking
- From: "R. Peters" <russellpeters@xxxxxxxxxxx>
- To: <delphizip@xxxxxxxxxxxxx>
- Date: Mon, 12 May 2003 08:28:39 +1000
I seem to remember that the reason that they went to an 8 bit check is that
the algorithm used was developed as a quick check to see if it was
worthwhile to attempt decrypting and inflating.
Unfortunately when the character set was widened the original 16bit check
was prone to rejecting the correct password whereas the 8bit check only let
it unsuccessfully try decrypting a bit more often.
The 'key' check only lets you in the door - it does not open the safe (if it
did you would only have to leave out checking the key and you'd have the
data)
- Russell Peters
----- Original Message -----
From: "James Turner" <james.d.h.turner@xxxxxxxxxxxx>
To: <delphizip@xxxxxxxxxxxxx>
Sent: Sunday, May 11, 2003 10:33 PM
Subject: [delphizip] Re: Password checking
>
> I would have to look closely to be sure, but I think if a password were
> accepted incorrectly, then the result would be garbage output, indeed, the
> inflate code may well crash completely - this was my primary concern when
I
> reworked the password code. It may even be possible to implement a 32-bit
> password check.
>
> I'm busy putting the finishing touches to the core of my new project -
> ENVY - a non-visual lightweight application framework for Windows/Delphi.
If
> anyone is interested in beta testing ow would like more information,
contact
> me directly via envy@xxxxxxxxx (It'll be a couple of weeks before its
ready
> for testing.)
>
> I'll be returning to the inflate code in a few weeks time so I'll look at
> the password checking in greater detail then. In the mean-time, perhaps
> someone would like to throw some code together to see what happens when an
> incorrect password is accepted (by the 8bit version). My guess is,
something
> will go splat.
>
> James Turner
> SKARO.NET
>
> PS
> If the encryption block produced by zip versions 1 and 2 are identical,
why
> should there be any difference in the password validation check carried
out
> on that encryption block? Answer : there shouldn't be any difference!! So,
> perhaps the real question is this : are the encryption blocks created by
zip
> versions 1 and 2 identical or not.
>
> PPS
> Unless it has been changed recently, the ZipDLL code always uses a data
> descriptor with password protected files. This means that it is difficult
to
> touch (change the date of ) a file without inflating it (for which the
> password is needed).
>
>
> ----- Original Message -----
> From: "R. Peters" <russellpeters@xxxxxxxxxxx>
> To: <delphizip@xxxxxxxxxxxxx>
> Sent: Sunday, May 11, 2003 7:30 AM
> Subject: [delphizip] Re: Password checking
>
>
> >
> > I have checked the UnzDll code and depending upon a define 'ZIP10' it
can
> > be 16 or 8 bit.
> > At present this is not defined so is 8 bit.
> > Setting it to 16 bit probably would not gain much - they would only go
to
> a
> > utility that used the weaker check!
> > I can unload a copy with 16 bit checking if desired.
> > - Russell Peters
> > ----- Original Message -----
> > From: "James Turner" <james.d.h.turner@xxxxxxxxxxxx>
> > To: <delphizip@xxxxxxxxxxxxx>
> > Sent: Saturday, May 10, 2003 3:07 AM
> > Subject: [delphizip] Password checking
> >
> >
> > >
> > >
> > > Irrespective of specifications, the algorythm is definitive and the
> > > algorythm appears to support a16bit integrity check rather than an
8bit
> > > integrity check for passwords.
> > >
> > > I may be mistaken, but if the algorythm does indeed support 16 bit
> checks
> > > then it seems sensible to me that 16bit checks should indeed be used
> > rather
> > > than 8bit.
> > >
> > > The password checking code is extremely twisted and I doubt there are
> more
> > > than a few dozen people on the planet that actually understand it (and
I
> > am
> > > certainly not one of them) but it is not always necessary to
understand
> > how
> > > a piece of computer code works, but rather you simply need to
understand
> > > what it does. My analysis of what the code does (not how or why it
does
> > it)
> > > lead me to use 16 bit checks rather than 8bit.
> > >
> > > James Turner
> > > SKARO.NET
> > >
> > > ----- Original Message -----
> > > From: "markus stephany" <delphizip@xxxxxxxxx>
> > > To: <delphizip@xxxxxxxxxxxxx>
> > > Sent: Friday, May 09, 2003 4:51 PM
> > > Subject: [delphizip] Re: Memory leak in Inflate.c in Unzip.dll
> > >
> > >
> > > >
> > > > well, i am not a math guru...
> > > >
> > > > but... in the pkzip specs i found the following:
> > > >
> > >
> ----------------------------------------------------------------------
> > > > After the header is decrypted, the last 1 or 2 bytes in Buffer
> > > > should be the high-order word/byte of the CRC for the file being
> > > > decrypted, stored in Intel low-byte/high-byte order. Versions of
> > > > PKZIP prior to 2.0 used a 2 byte CRC check; a 1 byte CRC check is
> > > > used on versions after 2.0. This can be used to test if the password
> > > > supplied is correct or not.
> > >
> ----------------------------------------------------------------------
> > > >
> > > > since in pkzip 2.0 only ONE byte (the last key byte) seems to be
used
> > > > for crc checking, is it really correct to check against the last TWO
> > > > key bytes?
> > > >
> > > >
> > > >
> > >
> > > -----------
> > > To unsubscribe from this list, send an empty e-mail
> > > message to:
> > > delphizip-request@xxxxxxxxxxxxx
> > > and put the word unsubscribe in the subject.
> > >
> >
> >
> > -----------
> > To unsubscribe from this list, send an empty e-mail
> > message to:
> > delphizip-request@xxxxxxxxxxxxx
> > and put the word unsubscribe in the subject.
>
> -----------
> To unsubscribe from this list, send an empty e-mail
> message to:
> delphizip-request@xxxxxxxxxxxxx
> and put the word unsubscribe in the subject.
-----------
To unsubscribe from this list, send an empty e-mail
message to:
delphizip-request@xxxxxxxxxxxxx
and put the word unsubscribe in the subject.
Other related posts:
