1

Suppose that I am developing a service (DocBot) to aid the transfer of large mail attachments. Instead of attaching documents to her messages directly, Alice appends the hash of each document, and separately sends the hash to DocBot, which requests the full document if it does not recognise the hash.

When Bob receives the message, he asks DocBot for the the original document associated with the hash. For the sake of argument, DocBot does not require any additional information from Bob – if anyone knows the hash, that is taken as proof that they are authorised to see the original document.

My question is: assuming that the hashing scheme is sufficiently collision and pre-image resistant, and that no one can intercept Alice's messages to Bob, what new vulnerabilities are introduced by this scheme? That is, does DocBot create ways for a malicious user to learn information they shouldn't, or interfere with other people's communications?

Improve this question

2 Answers 2

Reset to default
2

DocBot would allow a malicious user to learn information (read documents) if DocBot is not designed to prevent brute force attacks.

Specifically, if knowing the hash is all the proof that is needed, then iterating a stream of hashes could, in principle, give up Alice's documents.

Improve this answer
3
  • True, but if the hash is, say, 512 bits long, and there are only a thousand trillion documents, then it would take more than 10^139 attempts to guess an existing hash, so it's unlikely the universe would last long enough for this to work...
    – bobtato
    Commented Dec 7, 2017 at 14:22
  • Indeed, blank brute force is unlikely if crypto is implemented properly. But I imagine a hashed dictionary attack or common document titles (names, ID numbers, typical contract titles) that sort of thing may be an attack vector.
    – count_zero
    Commented Dec 7, 2017 at 14:53
  • 1
    The hash is of the document itself, not its title, so you'd have to already know the exact content of the whole document in order to retrieve it. This actually IS a weakness, since an attacker could e.g. detect if a specific document had been leaked; one solution would be for Alice to add a random salt to documents before hashing them.
    – bobtato
    Commented Dec 7, 2017 at 15:05
1

The first vulnerability is that anyone with a set of documents can find out whether or not those documents are already in DocBot.

The second, related vulnerability is that anyone with a template of a form document can find similar form documents with, essentially, a dictionary search.

For instance, I have or find one example of a valid mortgage PDF:

Mortgage: Mr. Weakpasswords, 123 Anti Ln, $183,300.  blah, blah, blah.

Now, I take that PDF, and simply change the text fields, looking for other documents using some things I know and guessing at some I don't, then submitting the hash to see if my guess exists - for instance:

Mortgage: Mr. Bobtato, 987 DocBot St, $1.  blah, blah, blah.

No, no matching document.

Mortgage: Mr. Bobtato, 987 DocBot St, $2.  blah, blah, blah.

No, no matching document. Try again.

Mortgage: Mr. Bobtato, 987 DocBot St, $312,767.  blah, blah, blah.

Hah! Now I know how much your mortgage is!

Hey, what if I had another PDF:

Bank of WeakPasswords: Mr. Bobtato, your PIN has been changed.  Your PIN is now 1234.

You see the problem.

Depending on the legal status of DocBot and licensing compatibility, you may want to look into the Tahoe-LAFS secure distributed file system; they've dealt with many of these issues in far greater detail than your question implies.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .