0
$\begingroup$

I am a novice cyber security student and thought of a way to generate a random cryptographic key.

The algorithm works as follows:

  • Get the size (in bytes) of every file in a directory (drills down into each folder to only get files)
  • Concatenate each byte sizes together, EX: A file length of 2 bytes and a file length of 4 bytes would would make "24"
  • This creates a string thousands of digits (I've done up to 10,000,000 digits long)
  • If the user needs an extra long key, hash each individual character using SHA-256
  • Take the final string (millions of bytes) hash it down to two 64 byte hashes and combine them to make a 128 byte or 256 byte based on user selection.

Some reasons I chose this method include the randomization of the string created since it's very unlikely that two people would have the exact same drive structure, and the size of the bytes hashed to make the key grows very rapidly since most files are several hundred bytes or more.

I guess this isn't a very direct question, but does this algorithm sound useful/secure? What are some ways I could improve on this algorithm?

$\endgroup$

closed as off-topic by e-sushi May 31 '17 at 0:10

This question appears to be off-topic. The users who voted to close gave this specific reason:

If this question can be reworded to fit the rules in the help center, please edit the question.

  • $\begingroup$ this is one of the key-creating methods that's very clever, but still not as good as /urandom/... $\endgroup$ – dandavis Jun 1 '17 at 4:08
  • $\begingroup$ Do you think it could be improved on by using similar noise to increase the entropy? By maybe using a random number of drives and files, and then pulling data from network packets, and other sources pulled from /dev/random? Instead of passing it a seed, hashing the huge number into a length of 128 or 256 bytes and making that the key? $\endgroup$ – CS2020 Jun 1 '17 at 13:55
  • $\begingroup$ my concerns: there's really no reason to have a hash input many times greater than the output. Hashes are not deigned to provide this type of provable protection. There's a stiff limit on the number of keys on low-activity systems, and much/most of the deterministic key source can recreated should the device be compromised. It would be safer to feed your accumulated data into the system pool, and pull from the system pool. if you don't have a system pool, you could setup a fortuna instance and feed that your entropy. bottom line: "launder" your above entropy with a CSPRNG for the win. $\endgroup$ – dandavis Jun 1 '17 at 20:21
1
$\begingroup$

Useful: No. Secure: No.

The most pertinent part of your question is the title which I'd slightly correct to "Key generation algorithm based on file lengths in a drive". It is here at the start that you've made invalid assumptions. There are others later on too though.

A random cryptographic key is essentially entropy, which you can read as uncertainty. So from a high level, key = entropy = uncertainty. The file structure on a typical machine is fairly well specified, whether it's a proper *nix machine or one of those other ones. If the machine is newly created (especially as a virtual image or embedded), the file layout may be identical between machine instances. So any key derived from the file system (lengths or contents thereof) will be highly predicable. There for insecure. You have confused complexity with uncertainty. The file system is certainly complex, but think of all of those free AOL CDs that ended up as coasters. If you had run your algorithm across the newly installed AOL directory, all of the generated keys would be identical across any machine you'd just installed on. All of you 10 million digit concatenations would have been identical, or very nearly identical.

The second error is the key length. As a security student, you'll come across typical acceptable key sizes. No one will even require more than 256 bits of key security. There are mathematical proofs of this limit. Your attempt at creating an extra long key is meaningless. A lot of cryptographic primitives are designed around the 256 bit size. What were you attempting to use a 10 million byte key for, as there is no legitimate function to absorb such a key? [You're not thinking one time pad are you?]

With respect, you're probably quite new to cryptography on the basis of this question. There is no effective improvement that can be made to this algorithm without a much more extensive understanding of the nature of a cryptographic key and it's relationship to entropy.

You are though ultimately correct in realising that a key can be generated from the chaotic churn inside a modern computer environment. Chaos principles can be applied to a file system and there is true entropy but it requires a much greater understanding of the principles before you can extract it safely.

$\endgroup$
  • $\begingroup$ This is very true, I guess I was thinking of my algorithm running on a users daily machine, or a machine that has been used and has a modified file structure. One thing I guess I didn't make clear- The 10 million byte size was only used for hashing down to a 128 or 256 byte size, only using the complexity of the 10 million bytes to make a unique key of 128 or 256 bytes. This was an idea I had and the first actual attempt (coding or theory) I've made about cryptography so thank you for your input! $\endgroup$ – CS2020 May 31 '17 at 13:08
  • 1
    $\begingroup$ @user8032968 I may have underestimated your ability then. Yes you can do this and that's what I was alluding to in my final paragraph. There is sufficient churn within a PCs file system to extract 256 secure bits, especially if you include user generated files. But you could do cat /dev/random | hexdump instead for a one off key. $\endgroup$ – Paul Uszak May 31 '17 at 13:29

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