Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 5 May 2012 03:09:04 +0300
From: Milen Rangelov <gat3way@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: New RAR OpenCL kernel

Well, there are two cases here, a PPM block or a LZ block. The PPM case
would very quickly give you an error if stream is invallid and unpack29
would switch back to the pure LZSS case. Then for Lempel-Ziv  it's highly
unlikely that you'd get the same result from rar_decode_number()  several
times at a row unless the stream is bad. The key point here being "several"
and that's where  my concerns are.

On Sat, May 5, 2012 at 2:45 AM, magnum <john.magnum@...hmail.com> wrote:

> On 05/04/2012 08:19 PM, Milen Rangelov wrote:
> > OK, my tests are all successful until now. Speed is relatively the same,
> > doesn't matter whether the compressed file is a 4KB text file, or a 50MB
> > avi movie :) Unfortunately there is still overhead as compared to the HE
> > case, speed being somewhat 20% slower. I am still not 100% whether this
> > would hold true in all cases and if I am wrong, it might happen that for
> > some archives we can get false negatives.
> >
> > I am not yet 100% convinced I am correct yet though. The approach is
> based
> > on 2 assumptions, first one can easily be proved, the second one is
> related
> > to the LZ algorithm and I cannot yet prove what I check is safe and can't
> > occur in a valid LZ stream.
>
> This is good news Milen, just what I hoped for. I am SURE there are such
> short-cuts because cRARk runs full speed no matter what you throw at it.
> Please do share your findings, you know I would.
>
> magnum
>
>

Content of type "text/html" skipped

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ