quote:
Originally posted by raceprouk
the password is stored encrypted itself.
The password isn't stored at all.
quote:
Originally posted by muratyilmaz
You are right, plus need first a few bytes to correction password is correct or not. It s mean all logs may have same first few byte so this bytes can tell to coder password encryption even password.
am I right?
No
As said, the password itself is the encryption key. This means that every file encrypted with a different password has different "starting"
[*] bytes as the "checksum"
[*] is obviously encrypted too.
You can not reverse engineer the encrypted bytes to catch the password, in any way.
In fact, the password is not stored in the file at all; it is just used as the key to decrypt (thus doesn't need to be stored anywhere anyways).
The only way you
could decrypt a encrypted log succesfully without knowing the password is by applying a brute force attack to the file. And that can take, without exagrating, thousands of years
[**].
--
[*]Raceprouk, the special 'checksum' bytes aren't located at the beginning of each file. And the 'checksum' isn't a checksum but a specific word as you can read in one of the threads about the log format.
What Plus! does to check if a password is correct or not is decrypting that encrypted word with the given password and if that specific word isn't what it should be, it knows the password wasn't correct. Again, the password is not stored in the file itself, nor the length, nor any other thing to know even the slightest thing or get the slightest hint about the password.
[**]To have an idea:
If a password has a maximum length of 10 characters (note that the password can actually be far longer than that) and can contain all printeable characters, you have 60.510.544.115.717.378.340 possible passwords. Say an average computer can process roughly 35.000.000 passwords per second (which would be relative fast though), it would still take you more than 55.000 years!
/ 
