26
No, it is not a good idea to hash phone numbers. There are only a limited number of phone numbers, so it is pretty easy for an adversary to try and hash all of them. Then you can simply compare the hash of each with the stored hash. Generally you don't have to deal with all telephone numbers, only a subsection of phone numbers anyway (for a specific country ...
10
It is always a bad idea to hash data that has a limited set of length or characters.
A phone number in Germany for example has normally no more than 12 digits.
The first digit is always a 0 and the vast majority of numbers is longer as 3 digits, as those are normally reserved for emergency services.
This effectively leaves us with 10^11-10^3 possible ...
6
In the general sense, The problem is known as the small input space on the hash functions, and in short simple hashing won't be secure.
If you hash data ( here a phone number) and an attacker tries to find an input value that matches the hash value is called the pre-image attack. In a secure Cryptographic hash functions pre-image attack requires $\mathcal{O}(...
6
As an alternative, you can salt the phone numbers to avoid pre-calculation attacks.
A known salt will help against an adversary who has already done a hash of all possible phone numbers but just adds one order of magnitude of work (the adversary just has to recalculate all the hashs with the salted phone numbers).
If you can keep the salt private raises the ...
4
For an encryption scheme to satisfy the standard notion of security (IND-CPA), its encryption algorithm must be randomised. Therefore $\textsf{Encrypt}$ has access to random coins, denoted here by $\theta$. It is usually implicit in the syntax of $\textsf{Encrypt}$
$$c\leftarrow\textsf{Encrypt}(pk,m),$$ but it can be made explicit as
$$c=\textsf{Encrypt}(pk,...
4
Would there be any additional benefit to this scheme?
Not really; password hashing is storing the hashed password in this form:
$$H( \text{password}, \text{salt} )$$
where $H$ is some hard-to-compute hash function. What you are suggesting is to replace this with:
$$H( \text{password}, D( \text{password}, \text{encrypted_salt}) )$$
(where $D$ is the ...
3
This is a based on the page Blobby the multi-factor encryption engine as retrieved 2020-06-30T14:24Z from the Tor URL in the question.
The claimed novelty for this encryption scheme (per that page and the question) is the combination of a nearly-arbitrary sized password and an arbitrary sized key. But there is no novelty there. A password-based key ...
2
The thing that makes subtle crypto almost entirely useless is the lack of key management. Although you seem to use the primitives in the correct way, the key management is not specified at all in your question.
If, for instance, you cannot trust the TLS connection, then what chance is there that the public key used for encryption is trusted? About none. ...
1
I'm somewhat new at this, so there might be a better way to solve this, but this is how I solved it. If I understand right, the extra parameter given is written as:
$$\mathtt{}({e}_{1} \oplus k) \oplus ({e}_{2} \oplus k) = e_{3} \oplus k$$
(that is, the decoded contents of e1 xor'd with the decoded contents of e2 is equal to the decoded contents of e3)
The ...
Only top voted, non community-wiki answers of a minimum length are eligible
