New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vulnerability in bigfile.py #13

Closed
sybrenstuvel opened this Issue Dec 7, 2012 · 2 comments

Comments

Projects
None yet
2 participants
@sybrenstuvel
Copy link
Owner

sybrenstuvel commented Dec 7, 2012

Originally reported by: Sergio Lerner (Bitbucket: Sergio_Demian_Lerner, GitHub: Sergio_Demian_Lerner)


There is a security vulnerability in decrypt/encrypt_bigfile(infile, outfile, pub_key). Depending on the way decrypt_bigfile() is called, it may be possible to do a Bleichenbacher attack.

First note that:

  1. decrypt/encrypt_bigfile() does not implement Authenticated encryption (http://en.wikipedia.org/wiki/Authenticated_encryption) nor uses MACs to verify messages before decrypting public key encrypted messages.
  2. decrypt/encrypt_bigfile() does not use hybrid encryption (it uses plain RSA) and has no method for chaining, so block reordering is possible.

We'll force decrypt_bigfile() to implements a perfect Bleichenbacher oracle. The infile (a message) is broken into blocks, and each block is independently encrypted using RSA. That means that an attacker can reorder blocks within a message and still create a valid message. Also the attacker can construct a new message by mixing blocks from other captured messages.

Attack:

  1. We take a message with several blocks, or duplicate blocks from a single block message.
  2. We modify the first block according to Bleichenbacher attack
  3. We add many copies of the another block (unmodified) afterwards, e.g. 50 blocks.

If the PKCS#1 1.5 padding of the first block is incorrect, then the function decrypt_bigfile() will fail fast. If the padding is correct then the remaining blocks will be checked and that will take additional externally measurable time.

I found a way to implement this attack and break the Bitmessage protocol (Bitmessage.org) which uses decrypt_bigfile(). See http://bitslog.wordpress.com/


@sybrenstuvel

This comment has been minimized.

Copy link
Owner

sybrenstuvel commented Sep 4, 2015

Original comment by Sybren Stüvel (Bitbucket: sybren, GitHub: sybrenstuvel):


If you can help me fix this, please let me know. Otherwise I'll just add a note to the functions about their insecure nature.

@mgh

This comment has been minimized.

Copy link

mgh commented Dec 2, 2016

This attack is based on timing. It seems like this could be fixed by attempting to decrypt all blocks even if one raises an error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment