3

I don't understand why: $$\sum_{y\in T}(\Pr[Z=y]-\Pr[Y=y]) = \sum _{y \notin T}(\Pr[Y=y]-\Pr[Z=y])$$ Well the domain is partitioned into $T$ and its complement. So the sum over the full domain of the difference of the two probability distributions is zero. $$\sum_{y\in T}(\Pr[Z=y]-\Pr[Y=y]) +\sum _{y \notin T}(\Pr[Z=y]-\Pr[Y=y])=0,$$ but now you can just ...


1

What differential privacy guarantees is that the query output communicates at most $\varepsilon$ bits of information about any individual (row). I now comment on each setting outlined in your question: Independently repeated queries constitute several distinct releases. There is a straight-forward composition theorem (See e.g. Sect 3.5) that follows ...


1

A) Don't hash Email. Store it as plain text or don't store at all. If hashed, then looking up will be impossible. One would need to iterate through every single record in the database. On average 50% records need to be tested each time. In case there are 1 000 000 users, for every login case the application will need to check on average 500 000 records. ...


1

One $n$-bit ECDSA private key can be found from the public key with about $2^{n/2+1}$ group operations, by Pollard's rho, which is relatively easily distributed. Nothing more costly is worth consideration. For $n=128$, this is $2^{65}$ field operations and would be feasible with a large effort. This is why people use at least $\approx160$-bit ECDSA, and more ...


1

3 things to note: 1: a constant salt no longer functions as a salt 2: a constant secret salt is just an addition to the password 3: your suspicions about the method of cryptography employed to secure the DB in your example are well founded, simply, it is not good. Luckily for you, that is not how it is actually done. With Spring Boot, you run the ...


1

Answering my own question. I believe it is possible. We can use the scheme by Boneh et al. described here. It uses pairing-based cryptography to be able to create a searchable, asymmetric, tagging scheme. In this scheme, queries are made through a trapdoor of the real key that we want to search, making it impossible for the set holder to retrieve ...


1

Just keep all user-associated information encrypted using the user's password. Be sure to use a secure password-based key-derivation function (PBKDF2 seems to come to mind but personally I prefer Argon2) because passwords make terrible encryption keys. Here is an example of how it might be done: User generates random encryption key (master key or MK) on the ...


Only top voted, non community-wiki answers of a minimum length are eligible