1

Alice bought 1 Bitcoin and encrypted her wallet.dat in Bitcoin Core.

Samantha, Alice's friend, notices the Bitcoin price skyrocketing and, while Alice is in the bathroom, steals Alice's wallet.dat as well as important.txt and goes home.

There she discovers that it's passphrase-protected, so she cannot transfer the coin away to her own wallet.

Alice opens important.txt and discovers this:

Never delete the following!!!
Bitcoin passphrase: "ck3C83jcdldkj3isDkj2m3Db3ducMJm3wb3kdkxckDksk2kw54956848dkDkdkewj54t" + first_pet_nickname + house_number_for_second_temporary_house + guy_in_first_grade_i_had_a_crush_on + favorite_brand_of_cakes (all lowercase letters)

In other words, Alice has written down part of the passphrase with the rest being things that Samantha possibly could guess or brute-force.

My question is: assuming that she can't just guess the unknown parts, and has to brute-force it, does the sheer length of the known part pose any kind of extra hurdle?

That is, has the passphrase just turned into simply first_pet_nickname + house_number_for_second_temporary_house + guy_in_first_grade_i_had_a_crush_on + favorite_brand_of_cakes? Since the first string is known, does that mean it "doesn't exist" as far as brute-force time/resources needed? Or will this add significantly to the slowness of the brute-forcing because it has to do different (more complex) calculations with the long string as compared to without it?

1

What you're describing is a (partial) known plaintext attack. This worked when attacking a shared key cryptosystem like Enigma (see the "Wetter" message start situation they found) where knowing the state at one point help determine the state later. This doesn't work for cryptographic hash functions like where you turn a password into data for a key. The reason why is that in a cryptographic hash (e.g. PBKDF2) it is designed such that all the output depends on all the input, and changing one bit anywhere changes multiple output bits.

TL;DR: You're out of luck cryptanalytically. But linguistically you might have a path to a quicker solution. In your example if you knew the specific structure, you could make a list for candidate words/phrases and try every permutation. It would still be faster than raw brute force but possibly still longer than practical. Or hypothetically, lacking knowledge of a password structure but knowing it's natural language, you could build a probabilistic language model and have it just start generating text to try. Theoretically it's faster than brute force. Realistically you may still die of old age before it finishes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.