how do passwords work?

newbie here. so consider this paradox: let's say you have a pass protected rar file. now the password should be stored somewhere in the file to compare against the inputted password. so if it's there how come you cant just extract it?

>>40
It's difficult to tell whether you're just misinformed or just trying to stir up trouble. In any case, joke's on you: AdvanceCOMP uses the Deflate implementation from 7-Zip.

It'd have been more effective to mention KZIP, an unbeaten USA-made Deflate implementation (it's quite slow however). In any case there's no way any implementation of Deflate is ever going to beat LZMA, not even in specially crafted data. I could see how it could beat the block sorting compressors in some cases though.

It's difficult to tell whether you're just misinformed or just trying to stir up trouble. In any case, joke's on you: AdvanceCOMP uses the Deflate implementation from 7-Zip.
that doesn't change the fact that deflate usually beats your precious lzma. i don't give a shit about your country and its penile deficiencies.

In any case there's no way any implementation of Deflate is ever going to beat LZMA, not even in specially crafted data. I could see how it could beat the block sorting compressors in some cases though.
out of about 50 files (mostly c code and elf binaries) that i've tried it on, advancecomp's implementation of deflate beats lzma on all of them except one.

>>38
The only way to compress PRNG output that comes to my mind is to discover the seed used to generate the bytes - but it's not a compression then, it's a hack.

Please, explain to me, what's the difference between PRNG output and true random data? How can one tell apart them, if he does not know the algorithm used to produce it?

>>43
Speaking as someone with some NSA cryptologic experience I can assure you that it is most definitely possible to differentiate random from pseudo-random, and pseudo-random from encrypted data for that matter.

I can't delve further into this topic, but maybe someone else can.

>>44
I can't delve further into this topic
Why is that?

>>45
Because he's full of shit.

>>43
http://www.lavarnd.org/what/nist-test.html#medium

>>42
I don't think you know what are you talking about. You trolled me into testing this, I used C source files and compressed each one individually (worst case for lzma, which is designed for large amounts of data). For Deflate I used advancecomp at maximum settings. Deflate did win in some tiny files (<4KB compressed), but overall lzma was 7% smaller.

Once we use solid compression (I concatenated all the files together), lzma was leading by 28%.

I don't know why I bother - several distros and package systems have already switched to lzma, with more on the way. It's widely used on installers on other platforms too. Many embedded devices use it (my router does for example). Even friggin' WinZIP added it in a desperate attempt to remain relevant. The only reasons to use deflate are grossly underpowered hardware, or compatibility.

Next in /prog/: >>42 insists deflate is better than lzma, this time testing the common use case of compressing mp3 and jpeg files.

>>43
[i]You[i] are a hack.

http://www.iro.umontreal.ca/~simardr/testu01/tu01.html (read the paper)
http://www.phy.duke.edu/~rgb/General/dieharder.php

>>46
Ever hear of a security clearance, asshole?

I don't know how much of what I know is public-domain knowledge and how much is classified, and I'd rather not risk losing my clearance, much less life imprisonment or death.

>>48
i'm not sure if you're just trolling or what, but i'm looking at a .tar.gz and a .tar.lzma both compressed from the same tar file (one with gzip then advdef -z4, the other with lzma -9), and the .tar.lzma is about 400KB larger.

>>51
Please post that file, I'd like to take a look.