Where is the AES key stored?

[LeDav1]

Describe the problem/question

Hi everyone,
I'm trying to understand where is the AES key stored. I initially thought that the key was in the url:
https://example.com/paste_id#key
But got confused looking at encryption format wiki :

Process data

If paste_password is an empty string:
paste_passphrase = random(32) # 32 bytes
if a paste_password has been specified:
paste_passphrase = random(32) + paste_password

Key derivation (PBKDF2)

kdf_key = PBKDF2_HMAC_SHA256(kdf_keysize, kdf_salt, paste_password)

If only paste_password is used to generate the AES key, what is the usage of paste_passphrase?

Did you use the FAQ section?

• Yes, I have read the FAQ and I found no solution/answer there.

What you did?

I'm trying see how easy would it be for an attacker to decrypt an intercepted GET request, but having a hard time doing so

What happens

No response

What should happen

No response

Additional information

No response

Server address

No response

Server OS

No response

Webserver

No response

PrivateBin version

No response

Browser and version

No response

Local operating system and version

No response

Issue reproducibility

No, I cannot reproduce it on https://privatebin.net.

[elrido]

Here are some additional resources that will help in your analysis:

• As a high level starting point, have a look at this How does it work? diagram
• We created a threat model which contains data flow diagrams and lists our security assumptions
• We modeled the protocol using Verifpal - you can use that as a starting point, add your own assumptions or attack vectors and validate that the confidentiality of paste, key and optional password still holds true

You are on the right track, the key is indeed the bit in the URL after the hash. This is what ensures that the key is not sent to the server in the GET request by the browser and the key never gets communicated to the server (de- and encryption occurs only client side, the server does never learn the key).

But AES needs a 256 bit key and ours is only 32 bits of random data, generated by the pastes creator (thats the random(32) part you found mentioned in the encryption wiki).

Adding the optional password makes it longer, bit it may still be below 256 bits or now too long. Also, passwords, given that humans need to be able to type them on a keyboard, do not provide much entropy.

This is why key derivation (in the form of the PBKDF2 algorithm, at this time) is used to take this key and optional password of varying length and turn it into a 256 bit sequence in such a way that changing even one bit in the input will greatly change the output key. This derived key is what gets used to en- and decrypt the paste.

And because none of the pieces (key from hash and password) are sent to the server, observing the traffic from and to a privatebin server should not leak the key, but it does of course leak meta data, like which sender created the paste and when and which recipients accessed it.

The flaws lie in how people share the pastes with each other. In practice that will often be an insecure channel, or even be done in public. Privatebin will in that case give the server operator plausible deniability that they didn't know what was stored on their servers. But it may not protect the paste from being leaked or read by third parties that gained access to the link and password, if there is one.

If you just want to use a pastebin service and publish content to the public, this is not an issue. If you do want a paste to remain private, though, you must ensure the URL and password is transmitted to the recipient in a secure manner and you use a server instance that you trust not to add malicious code to their site (hence our nudge to host your own instance).