View Single Post
Old 08-31-2009, 01:10 PM   #20
bkilian
Zealot
bkilian can name that song in three notesbkilian can name that song in three notesbkilian can name that song in three notesbkilian can name that song in three notesbkilian can name that song in three notesbkilian can name that song in three notesbkilian can name that song in three notesbkilian can name that song in three notesbkilian can name that song in three notesbkilian can name that song in three notesbkilian can name that song in three notes
 
Posts: 131
Karma: 24870
Join Date: Oct 2006
Device: Sony PRS/505
Quote:
Originally Posted by hacker View Post
"After eReader has created and stored the hash, it uses it as a key to decrypt the protected e-books (which are, to my knowledge, encrypted with the DES-X algorithm)."
If its a one-way hash, there is no "decryption" involved. You simply take the password/key/code that is entered, encode it with your known seed + hash, and compare it with the stored value. If it matches, access is granted. If it does not match, access is denied. This is how the standard Unix (and Linux) usernameassword login authentication is handled.

If there is a key of some sort, which is used to encrypt and decrypt the book, and that is stored somewhere in the application or the book itself, then the whole process of encryption is irrelevant, and can be easily bypassed, using any one of dozens of different techniques to bypass the check for the proper code (witness the thousand of Palm applications that have been breached because they use this method of "securing" their application).

Regarding entering the credit-card-as-key every time, I think what was meant was that the value you enter the first time, has to be encoded, encrypted, or stored somewhere within the book metadata, so that it can be checked and verified every time you launch the reader to read the book. The mention that the credit card value is not stored anywhere is completely false, if this is how their application works.

If you have to enter the key every time you open the book, then it would appear that they aren't storing the key anywhere. If you don't have to enter the key every time, then it is stored, somewhere, in some format, which is queried and used to authorize reading of the book.
It _is_ a one way hash, and there _is_ decryption taking place.
The way eReader encryption works is quite simple. It is stored as a Palm DB file, and each section is zipped and then encrypted with a standard DES encryption. The key used is a one way hash of your name and credit card number. The only security they use is obscurity, they're hoping people don't work out exactly what the hashing algorithm is. Unfortunately (for them) it's not that difficult. I wrote a c# tool for decrypting my books with very little hassle (for research purposes, of course). The DMCA disallows me from distributing my code, but you can find other tools if you know where to look.
bkilian is offline   Reply With Quote