Shoutbox

I think, but don't quote me on it, that the first few bytes of the file, if correctly decrypted, are a kind of 'checksum'. I don't know the encrypted format in any detail, but that's how I guess Plus! can tell the right password.

race,

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?

If that's true you should be abled to do an analytical attack, but it could still take years and it's very difficult

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!

Uhm, I have an idea maybe it'll help.

Don't all chat logs start as:
.--------------------------------------------------------------------.
| Session Start: Datte of the conversation                                   |
| Participants:                                                      |

If we then can learn the encryption algorithm (which, I assume, only Patchou knows), we may find some possible values for the domain of the function. I mean; the data decrypted is known, and the encrypted part is known. Can't we find something with it? I know there won't be one result for this. But I've been thinking of catching something with these.

quote:

---

Originally posted by CookieRevised
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.

---

Hence why I used 'checksum' in inverted commas ;P

quote:

---

Originally posted by CookieRevised
The password isn't stored at all.

---

But you don't have to keep re-entering the password when new logs are created. I did find a value called 'LogEncryptionDataEx', which may not strictly be the password, but would be used to not require re-entering the password? Much like DataP is used for the Preferences Lock.

quote:

---

Originally posted by can16358p
Uhm, I have an idea maybe it'll help.

Don't all chat logs start as:
.--------------------------------------------------------------------.
| Session Start: Datte of the conversation                                   |
| Participants:                                                      |

If we then can learn the encryption algorithm (which, I assume, only Patchou knows), we may find some possible values for the domain of the function. I mean; the data decrypted is known, and the encrypted part is known. Can't we find something with it? I know there won't be one result for this. But I've been thinking of catching something with these.

---

Logs don't neccesairly begin with that though, normally they do... but you can't be 100% sure if you have a log in your hands from someone else. Logs are just a bunch of characters, it doesn't matter what they contain. So to base your reverse engeneering on that is applying guesswork...

Anyways...
The encryption/decryption method is known, it isn't a secret. But without the password (as the key) you can do absolutely nothing with encrypted text/logs.

Also, as you said so yourself: the encrypted text is different each time (because the password was different), so what or how are you going to "catch" anything? With extremly basic "encryptions" (mind the quotes) where the encryption key is always the same you _could_ find something out, but reverse engineering encryptions (even if the encryption itself is dead easy) which use keys is as good as impossible.

So, no it isn't possible.... Moreover, what would the purpose be to "catch" anything? To know how the encryption method works? As said, that isn't a secret and is already know. But even knowing the encryption method, you can not decrypt anything without the proper encryption key (which is what the password is used for).

---------------------------------------------

It is absolutely NOT possible to recover encrypted log files WITHOUT the exact correct password.

It is abdolutely NOT possible to strip/catch/extract anything from the encrypted logs files in a way you would get even the smallest hint of the password; the password is NOT even stored!

No matter what things or ideas people might come up with: it is NOT possible...

---------------------------------------------

quote:

---

Originally posted by raceprouk

quote:

---

Originally posted by CookieRevised
The password isn't stored at all.

---

But you don't have to keep re-entering the password when new logs are created. I did find a value called 'LogEncryptionDataEx', which may not strictly be the password, but would be used to not require re-entering the password? Much like DataP is used for the Preferences Lock.

---

That doesn't have anything to do with this (except for the fact that the password _may_ be stored there, but that will not help at all):

We are obviously talking about (not) stored stuff in the log files itself to "break" the encryption. The registry wont help you at all in this, even if the password was stored unencrypted!!

People wanting to "recover" an encrypted log obviously haven't the (old) password stored in the registry (anymore), otherwise they wouldn't have the problem in the first place as Plus! would be able to open the log.

Ok. i see, logs are not decrypt.

So, when i logged in msn messenger(same time plus!), it ask me password. right? then i need to enter my password. This mean plus knows my password then check it my entering keys. Plus saves password to anywhere?

No, it doesnt. See CookieRevised's reply..

quote:

---

Originally posted by CookieRevised
except for the fact that the password _may_ be stored there

---

Hence why I said the key isn't strictly the password, like DataP. However, my guess is the value is used so the user doesn't have to keep re-entering the password.