-4

If I was given an encrypted key (presumably a private key) and it was only 64-bits in len, how would one go about decrypting it without the password?

In addition to cracking it, I am trying to learn about the key's properties, encryption type, etc.. however, I'm having no luck. My first instinct is to use a hexeditor, but i can't see how that would help.

Any starting points would be appreciated.

closed as unclear what you're asking by Xander, Anders, ThoriumBR, S.L. Barth, techraf Sep 19 '16 at 22:06

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • I don't understand your question. What have you got? A 64bit ciphertext, i.e. 8 bytes ciphertext? AFAIK you can't do much with so little data. There are too many "message, key" pairs that end up producing the same ciphertext so either you have some serious clues about the contents, or you are out of luck. You need much more data to check whether you found the right key. – Bakuriu Sep 19 '16 at 16:14
1

A key that length is most likely not an asymmetric key (even elliptic curve keys are usually longer than that, though I suppose it could be one). It's probably a symmetric key for an algorithm like DES (which technically only uses 56 bits of key material; the last byte is a checksum that most implementations ignore and is trivial to fix up if needed).

If it is encrypted, though, it really doesn't matter what type of key it is; there is absolutely no way to tell. With symmetric encryption (which is what you'd use to encrypt a key), without the decryption key, any given ciphertext can decrypt to any given plaintext. Moreover, unless you have some way to verify the key, you have no idea when you've hit the right one. With DES keys, the checksum byte (if it was correct beforehand) can tell you if you have the decryption wrong, but not if you have it right; 1/256 of the wrong decryptions will pass the checksum anyhow, while only 1/(72 quadrillion) is actually the right decryption.

Now, if you have some way to actually verify the key, like a cryptographic hash of it, or something to decrypt with that key and the cryptographic hash of the plaintext, you might be able to brute-force a DES key. It'll be slow without specialized hardware - probably weeks of constant computation - though specialized hardware can do it in a day or so if the verify function is fast enough. However, that's making some serious assumptions (like that it's a DES key, not some other kind of 64-bit key) and if it's actually a 64-bit key (not a 56-bit key plus checksum), your search space is 256 times as big; without dedicated hardware, you'd be looking at years of work to brute-force such a key.

Just checking: why do you expect that this is an encrypted key? 64 bits is so short that I would not by default expect it to be a key at all, much less an encrypted one. Even 64 bytes would be a very, very short public key (512 bits), completely insecure (though within the range you might use for a practice problem) if it were for an algorithm like RSA.

In any case, there's no inherent way to tell what type of key something is. Especially for symmetric keys, where literally any value of the right length is a valid key for any algorithm that uses the key size in question.

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