Let's say $p$ is the pool of files in a folder. And $k$ is the files in the pool that are "key files" for authenticating in a service.

Note: The order of the key files matter.

Then we have $c$ which is the character set of our passphrase. And $l$ is the length of our passphrase.

For each possible passphrase we also have to add the additional possibilities of the key files.

$t$ is the total possibilities of all the passphrase and the key files.

The formula I believe to be right is:

$t$ = $c^{l*(p^k)}$

And we get all the possible passphrase and key files.

We will assume this passphrase is a PIN, with 10 digits allowed, and with a length of 4. And we have a folder with 4 files, 2 of them are key files.

$p$ = 4, $k$ = 2. $c$ = 10, $l$ = 4.

$10^{4*(4^2)}$ = 1e+64 possibilities.

I have some questions about this.

  • If $p$ is very large, is it making this kind of authentication of knowing and having something because only I know which files in $p$ are $k$?
  • Is my math correct?
  • What reasons are there for websites to not implement key files?
  • Would it be good to implement in a website?
  • Is this good authentication?

It looks like this when we're storing the data: passphrase_hash(passphrase . keyfile1_hash . keyfile2_hash).

This requires knowing which files of $p$ is $k$, which ORDER $k$ goes in, in possession of $p$, and to know the passphrase.

Note:: $p$ is at least the value of $k$. If there is ONLY 1 of $p$ and $k$ then it's not knowing something. It's only having something.


This is to be used in a website. Each user has a passphrase, and some key files. The key files' contents are hashed to represent as it. Each of the key file hashed get appended/suffixed to the password/passphrase, all of these going directly into the password hashing function.

password_hash(password . keyfile2_hash . keyfile1_hash)

That is how it is stored. When they go to authenticate as themselves, they must select the files in the website's form, then they submit it along with their password/passphrase.

However, the math I did was a more general scope about the key files themselves, and how many more possibilities they add (the more there are, the more secure). Remember, the order of the key files matters. So they must upload the right key files, in the right order. Otherwise when we go to validate the hash ...

password_verify(password . keyfile1_hash . keyfile2_hash)

It will fail. They didn't upload them in the right order. The hash will output COMPLETELY different even though they are using the same key files.

Hopefully that clears things up.

  • 1
    $\begingroup$ Welcome to CSE ! Your question as it stands now is unclear. We do not know the context, what the passphrase protects, and the role of the key files w.r.t. the other files. We need to assume that the key files are passphrase-protected. We need to understand $p$, $k$ and $t$ are number of things, which is missing in their definition. Most importantly, it's unclear what is to be counted in "total (number of) possibilities of all the passphrase and the key files". I find it strange that $p-k$ (the number of non-key files) is not in the formulas. $\endgroup$ – fgrieu Mar 7 '19 at 12:58
  • $\begingroup$ Hi dear new user; if you need to merge accounts please have a look here $\endgroup$ – Maarten Bodewes Mar 7 '19 at 23:13

Your Answer

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

Browse other questions tagged or ask your own question.