Can I test/determine all decryption types on an unkown filetype. I do have the password

Question

I have a file that's nearly 200Mb. It was reportedly packed/encrypted with Kruptos 2. But it has a .~enc extension. The header of the file is pure gibberish. Running file says it's data running mimetype says it's an application/octet-stream. The only thing that looks like a way to identify the file is at the end of the file. It looks like it may be a checksum. Here's what I gathered from the hex editor at the end of the file.

786D4532D08A6A06F14D78EA11C648AC6615C025727D1294AA08F43862CBE529©9AA799BC68761F45F3360FEE03D88665©none©F75C7BCC8FB7E449636AE9E3CB81BC8018FCBF307DE1A881765C0A1CBCB65339©193971605©11©3©0©2©32©0© 202©<tkk>

My other hex editor shows the copyright symbols as dots

786D4532D08A6A06F14D78EA11C648AC6615C025727D1294AA08F43862CBE529.9AA799BC68761F45F3360FEE03D88665.none.F75C7BCC8FB7E449636AE9E3CB81BC8018FCBF307DE1A881765C0A1CBCB65339.193971605.11.3.0.2.32.0. 202.<tkk>

Is there a way I can run a decrypt command with trying all the available encryption types using the password I have? Or at least identify how this file was made and what it is?

One odd thing, I ran df -T myfile.~enc and it says ext4 type filesystem. I tried to mount it but that didn't work. So maybe that's just a fluke.

Oh, maybe the file name would be a hint. It's 021405631868CFACCB0C965D0AF04738ABDCB012CEEAC9C583B2A49CDFEE75BE296b.~enc

Answer 1

stackexchange. This question can't be answered by security experts; you need to contact the person who generated the encrypted file and/or learn how to use Kruptos 2. This site isn't for supporting how to use specific applications like Kruptos 2. The extension of .~enc tells little by itself. enc is a common extension for encrypted files, but ~enc doesn't seem to be a common convention; though as users are always free to rename files. And possibly you have a case where the original file was blah.~ and became blah.~enc when it just appended enc to the file. I'm not familiar with Kruptos 2.

The file utility saying data just indicates that the file seems to have binary data (that is not an executable), as opposed to ASCII or unicode plaintext. The mimetype application/octet-stream is simply stating that it is a stream of bytes (octets) and that there's no meta-data it can infer about what created it.

df -T file doesn't tell you anything relevant -- it just states that the file is stored on a partition that is ext4 (df doesn't tell you anything about the specific file, it only tells you about the partition that the file is being stored on).

Hexeditors only show printable ASCII characters in the right hand column showing the decoded text. They generally show unprintable letters as a period (.), though your first hexeditor seems to be attempting to encode the symbols in iso-8859-1 (latin-1), which means the byte displayed as a copyright symbol is really an A9 in hex (See: iso-8859-1 (latin-1) codepage layout.

There are an unlimited number of ways to encrypt a file, so you can't just try all of them. There's an infinite number of ways you can generate a key from a password (e.g., the first 128-bits of iterated 5000 rounds of a SHA-256 hash function combined using the IV as a salt), many types of encryption algorithms (AES, Serpent, Blowfish, Threefish, DES, RC5, CAST, Salsa -- and this is just for symmetric ciphers; there's also a variety of asymmetric encryption algorithms), and many tweakable settings for each type of method (key size, rounds, block size, block cipher mode (CBC, OFB, CFB, CTR, etc), where to store the IV, how to encode the data, etc.