As I understand it, the idea of the acsm file is to give information to ADE so that it can pass your public key to Adobe (or whoever is hosting the ebook) which will take the key, encrypt the book, then download it to ADE.

The acsm file is an XML file, and contains the url of the ebook. I purchased a book looked at the acsm file (which never went near ADE as it is not installed), and downloaded the epub file mentioned in the acsm from the site I bought the book from. I was expecting that the book wouldn't have been at the download location until the key was sent, but it was.

So this epub book isn't encrypted with my key, as I don't have one. It is encrypted of course, but with what?

I think the mechanism of encryption is a bit different than you describe. There is one encryption key for each differnt book (same content = same key). What the Adobe server does, when ADE downloads the book, is to insert the key for the book in it. Since it would be stupid to just give everyone the key without protection, the key itself is encrypted with your personal key.

Adobe puts encrypted keys for all your registered devices in the encrypted book and the registered ADEs then are able to first decrypt the key and afterwards decrypt the book.

The ACSM is only a link, all important information for the encryption of the key and the information which keys have to be inserted in the book come from ADE.

Ahh, ok. So what I have is the encrypted book, but without an encrypted (with my key) decryption key, because I did not pass my keys to Adobe for them to encrypt the decryption keys and insert into the book.

I think Sunlite has the answer here, this sort of nested key system is quite common. Also note that if you simply download the epub from the link provided inside the ACSM it will lack a rights.xml file inside the META-INF directory. Since this contains the key needed to decrypt it, ADE can't open the epub.

Ahh-ha! That makes sense - if the whole book was encrypted with the customer's key, each download would have to wait on encrypting a big file. As Charleski describes it, only the relatively short (1024 bits? whatever...) payload-key needs to be encrypted for each customer.

Ahh-ha! That makes sense - if the whole book was encrypted with the customer's key, each download would have to wait on encrypting a big file. As Charleski describes it, only the relatively short (1024 bits? whatever...) payload-key needs to be encrypted for each customer.