17

There are a number of considerations here, I'll try to lay them out one at a time for ease of following: What must the site do with the data? Oftentimes, we ask web sites to do things on our behalf when we are not actually visiting them. For example, I may want crypto.SE to email me when there are responses to this post. The site could not do that ...


8

Adi Shamir's secret database of all primes is to cryptography venues what the Dahu is to French summer camps. For why, see the answers to this related question. The three other future work items in the quoted presentation are in the same vein (Breaking RSA-1024 with Fermat factoring; Breaking RSA-1024 using $1024 = 2*2*2*2*2*2*2*2*2*2$; Breaking RSA-1024 ...


6

My question is where (along with encrypted data? somewhere else?) [...] should I store the MAC in database? In theory you can store the MAC wherever you want, as long as you store it and get the association right between MAC and ciphertext. Practically however it's smartest to append the tag to the cipher text. This minimizes the chances that you screw up ...


6

The mode of operation does not just matter; it defines the properties of the IV! The mode of operation is the part that specifies the size of the IV, the contents of the IV as well as the impact of abusing the IV. AES is a block cipher; by itself it only allows the key and a single message block as input; AES itself doesn't specify or know about any IV. For ...


5

Unfortunately, without some additional assumptions about the strings (e.g. that the first 8 bytes are unique), there is no way to reduce the chance of collision below the usual chance levels. If you need unique 64-bit ids, the options are: Do a database lookup when generating keys and pick another key if it is already in use (you state that you want to ...


4

Reading your message, we (in ZeroDB) realize that we need to add some things to our documentation. Provides authenticity and secrecy (most important) That one we do have now provides integrity over the whole database (no silent dropping of data) We pretty much have it at the level ZODB we base on has (ACID-compliant) leaks as less information to ...


4

You can simply handle password verification on login and escrow independently: Store a salted password hash (e.g. bcrypt) together with its salt. You can use this to verify logins, just like what you'd use if you had no escrow. Also store the password encrypted with asymmetric encryption (e.g. RSA-OAEP, ECIES). Since these are randomized, they are not ...


4

If you use a deterministic encryption algorithm (so that you can actually verify passwords without the private key) it basically works like a backdoored hash. An attacker will be able to use a brute force or dictionary attack normally. One obvious problem with any reversible encryption is that it reveals (at least something about) the password length. (E.g. ...


4

This is a really bad (and somewhat pointless) idea (if you do it on your own), because it provides less security than standard hashing and should only be considered if password escrow is a necessary feature. If you don't need the password escrow (= recover the password using the heavily secured airgapped private key) you can simply password-hash the password ...


4

I'll start with the usual reminder: Please don't roll your own crypto, chances are you're getting it wrong. For password databases, KDBX (KeePass' format) usually is a good example which you strongly should consider using. For an analysis of some format, also see "On The Security of Password Manager Database Formats" by Gasti and Rasmussen (PDF). For ...


4

Furthermore, is using AES-CBC this way any safer than using AES-ECB? Yes, using CBC mode is (almost?) always safer than using ECB mode. Is using zero IVs with AES-CBC safe[...]? No it is not safe, because if you re-use a key with that construction you will leak the common prefix between messages, at block granularity. That is if you have three messages ...


4

I want to say don't use SSNs like usernames for practical and ethical reasons. Yet I hope that if you switch to normal username/passwords you won't remove the (weak) password protection on encrypted SSNs that you already have. There also may be legal requirements surround SSN storage, but I know nothing about that. Definitely don't use SSNs because you ...


3

Important note: as long as the data on the server (name of platform) is encrypted and the decryption key safely stored elsewhere according to protocols established, it does not matter (from an access to the data perspective) if the account on the server is hacked. In that case the real protection for the data is the encryption, not the server itself, ...


3

If I understand your question correctly, you want to generate a short value $v(T)$ from a table $T$ such that if $T_1$ and $T_2$ have the same size and the same elements in each corresponding cell, then $v(T_1) = v(T_2)$, and if the tables have different sizes or different elements then $v(T_1) \ne v(T_2)$. What you need for that is two ingredients: A ...


3

What you describe is a digital signature, which works using methods very similar to the one you suggest. Examples include elgamal-signature and RSA signature schemes (the second of which I would recommend you read). Digital signatures allow you to provide a public signature that 'proves' you provided the message. As the author, you would produce database $m$...


3

This short calculation might address some of your concerns: Lets assume we are talking about 10^15 datasets of 4KB. That's about 3.6 Exabytes of data and 10^15 hashes. From the table at: https://en.wikipedia.org/wiki/Birthday_attack we get that given 4.8 10^29 hashes are needed in order for the possiblity of a brithday attack to reach 10^-18 when using a ...


3

The hypothesis it's assumed data items are completely random in their hash values for all practical purposes is unrealistic (it is very easy to build data items which hash values are even). Fortunately, we can do with: preparation of the dataset involved computing no more than $N$ hashes the hash used is a cryptographically secure $M$-bit hash the user ...


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 ...


2

Take a look at the SSARES system. According to the abstract, Our solution encrypts email (the headers, body, and attachments) as it arrives on the server using public–key encryption. SSARES uses a combination of Identity Based Encryption and Bloom Filters to create a searchable index. This index reveals little information about search keywords and queries, ...


2

Some points towards an answer: Why HMAC-SHA3? HMAC and its security proofs have been devised for Merkle-Damgård hashes, and SHA3 is not one. HMAC-SHA256 would be fine (Updated per comment: the Keccak submission does endorse its use with HMAC, using a block size parameters of 576 (resp. 832, 1088, 1152) bits for the hash with output of 512 (resp 384, 256, ...


2

The way the iterations work is that it roughly increases your security (in bits) by $\log_2(iterations)$. So you would still need $\frac{\log{2}}{\log{97}}\cdot (256 - \log_2(10000)) \approx 37$ characters in your password to have 256-bits of security. Think of it this way, if you have $2^{256}$ possible keys, that is an astronomically large number. Much ...


2

I'm looking forward to reading other answers -- a structure with these properties would be very useful for plausibly deniable encryption. Perhaps something like this might be adequate: // untested pseudocode initialize(): global_current_index = 0 global_array = [] for each word in a dictionary of plausible words: set( word, ...


2

This answer builds on the answer supplied by @otus. There is also an important worry about whether the main solution works at all as advertised. I am posting it now to make clearer to @otus a question I asked in a comment. I will eventually either delete it or substantially revise it. First off, let me emphasize that if the table is going to be used to ...


2

The following is the main contributor reply: The latest released version of CryptDB no longer supports the LIKE operation. Feel free to contribute to CryptDB and extend it to support this operation. You can find an older implementation (disabled) in the code, which we did not have the chance to port to the latest system.


2

Simply hashing the account ID will not prevent people from associating the account because they can just hash the ID themselves assuming they know the ID and have access to the table. If the data is so sensitive, you need to encrypt the entire table regardless of how you hide the ID. As I don't know your intentions, it's possible to associate an account ...


2

You seem to be inventing your own ad-hoc protocol, without authenticated encryption, and using old algorithms with known security weaknesses such as small block size. I strongly suggest you use a high level modern library such as libsodium and use its crypto_box function for authenticated encryption, as well as Argon for password key derivation to protect ...


2

I will address you first rewritten version of the text, and highlight the part that I think needs improvement: Important note: as long as the data on the server (name of platform) is encrypted and the decryption key safely stored elsewhere according to protocols established, it does not matter from a data confidentiality perspective if the account is ...


2

Do not use the SSN as a username!! Like FutureSecurity I cannot speak for the legal liabilities and respective requirements for handling SSNs. The following advice is general and may or may not apply to legal storage of an SSN. If your server doesn't need to know, then it doesn't need to store the [encrypted] SSN. To login you should be using client-side ...


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