# Tag Info

17

You may want to consider using the Web Cryptography API for client-side cryptography in the web browser. Then, you can create a keypair using the webcrypto api, and store the CryptoKey object, containing the user's private key, with the .extractable property set to false, using Indexed DB storage. This way the private key can only be used for decrypting ...

7

Specifically, why should hash functions not be used for data clearing? I take it you mean that we would overwrite the storage with output produced by feeding its sensitive contents to a hash function. The problem then is that this output, being a function of the data you're overwriting, therefore provides information about that input. In particular, it ...

7

I do not know of any approaches in context of proofs or retrievability (PoRs)/provable data possession (PDP) that use homomorphic encryption. However, many of those schemes employ homomorphic (linear) authenticators/tags for the metadata such that the proofs delivered by the server can be of constant size, i.e., by aggregating single tags. Now to some ...

7

All the parameters you've mentioned can be public. Furthermore, only the salt, IV and ciphertext cannot simply be guessed. The IV is generally easy to retrieve once the key is known, so the making the IV secret doesn't make sense. In CBC mode and many other modes you may just not get the first plaintext block if the IV is completely absent, but the rest of ...

6

Not sure if hash trees miss some of your requirements, but many of requirements you have could be satisfied with hash trees. Note: The scheme described below is essentially "Merkle Hash Tree-based Storage Enforcing Scheme (MHT-SE)[Golle et al. 2002]". So my question is, if we relax the requirement of being able to perform an unbounded number of ...

6

Given a vector $[S_0 S_1 x_1, S_0 S_1 x_2, ...]$, it is quite easy to recover $S_0 S_1$ (by computing the GCD of the various elements). With that information, the attacker can then recover the values $x_1, x_2, ...$, and so yes, a semihonest adversary could easily recover the $X_{reg}$ values.

6

It's common for encryption algorithm specs to specify a hard limit of how much data you should encrypt with the same key. For example, consider the AES-XTS encryption algorithm, which was designed specifically for full-disk encryption: The IEEE specification recommends that the length of a "data unit" (e.g., disk sector or block) encrypted with a single ...

6

GPG's AES-256 symmetric encryption is believed to be as secure as it is difficult to guess the passphrase or compromise the machine used to perform encryption and decryption. Guessing the passphrase should be harder if one uses gpg --s2k-mode 3 --s2k-count 65011712 --s2k-digest-algo SHA512 --s2k-cipher-algo AES256 or equivalently puts in the gpg.conf ...

5

Loading and using encrypted firmware usually requires one of the following conditions to be met: You have a security (co-)processor and the processor is trusted to follow the instructions given by that (co-)processor You have a trusted processor and some tamper-resistant storage Scenario 1 You have a security (co-)processor and the processor is trusted to ...

5

Storing passwords in such a way as to allow comparison against portions of the hashed password is by definition less secure than traditional cryptographic hashing. As a rule, this is simply never done. On the other hand, you could safely make comparisons of portions of your new password (for which you necessarily have the plain text) against the entirety of ...

5

It could enable a key exchange based off of symmetric primitives alone. For example, suppose I can provide to you a program that will allow you to perform AES-256 encryption of a single plaintext block. I could send you this program, you could perform your encryption and send me the result, and due to the whitebox nature of the algorithm, only I can decrypt ...

4

About the best you can do is have a master public/private key pair where the public key is stored on your server and the private key is stored offline. When you generate a new private key, encrypt it with the master public key and store that in the database. That way, if a password is ever lost, you can recover the user's private key by using the master ...

4

Specifically, why should hash functions not be used for data clearing? Several reasons, the main being that there is no need to use one. If you were thinking about reading the data from the device in chunks, running it through a hash function of equal size, Luis' answer points out why that is a bad idea from a security perspective. It is also slow, as it ...

4

Elaborate their claims / point me to some source where I can get an overview of the concepts to eradicate my suspicion This answer will focus on this part of the question: elaborating on the listed claims. All data is encrypted, including Entry names, Category definitions and the data itself. As long as that doesn't impede functionality such as ...

3

With your constraints, there is no way to safely store keys, and this is from a hardware perspective. If they exist in memory, there is pretty much a way to get them out. If you have a way to update the firmware, I can get something in there to get the keys out. It would have cost less than a penny to add a hardware core if you had a custom IC. (I go over ...

3

The requirements for storing public keys and private keys are quite different. Public keys need to be in a trust store in order to be able to trust them. Care should be taken that an attacker cannot replace them or trick the system into using a different trust store. Public keys - as the name implies - do not have to be confidential. The requirements for ...

3

We can divide the applications into several categories according to the security notions related to white-box cryptography. Unbreakability: means protecting against key extraction in the worst case attacking model where an adversary fully controls the running environment. The mobile payment(e.g. HCE), digital contents distribution and soft-keyboard-typed ...

3

See Theorem 6, page 38-39.. Also, this lower bound ignores any ability of the "RAM" to perform computation. Typically, there are two application scenarios for ORAM: 1) A literal processor communicating along a literal CPU bus to a literal stick of RAM 2) A client communicating over the internet to a cloud server In the latter case, it makes sense for the ...

3

It is related to Cloud storage in the sense that you don't have to trust the server you put your data on. Usually, the access control is done via authentication. This requires the server to be trusted. However in the case of Cloud storage, you don't know anything about the server hosting the data, so being able to do access control with the encryption ...

3

When you change your password you are required enter your both old password and new password in clear text, so they can be compared against each other for similarities. Once this test passes, you encrypt the old password and check it against its stored hash etc.

3

Your suggestion to split the password, in extreme case into characters, and hash the small chunks is similar to concept of fuzzy hashing. It is, however, not true that this allows an attacker to trivially reconstruct the password. Salt and Pepper may prevent dictionary attacks. But you could also save the password as usual, and then if the user types in ...

3

Crypto.SE is not the ideal place for this question, but I will answer this. Android keychain only stores keys and certs. You will have to manage security of activation status by your own. If the data is sensitive DO NOT store it in the SQLite database in plain text. I can recommend two methods: Method 1: Encrypt data and store encrypted data in the SQLite ...

3

Given a scenario, e.g. my Dropbox was hacked, and the hacker has access to my EncFS encrypted texts, and probably the history of it as well. Is that what was mentioned as "two or more snapshots" and "different times"? Whether it applies depends on how the storage system would work. As far as I can tell, EncFS itself has no backup/versioning capability. ...

3

To answer the question we first need to take a quick look at how XTS encrypts data: $$C=E_{k_1}(P\oplus(E_{k_2}(n)\otimes\alpha^i))\oplus(E_{k_2}(n)\otimes\alpha^i)$$ With $\oplus$ denoting bitwise XOR, $n$ denoting the sector index, $i$ denoting the block index within the sector. $\alpha$ is a polynomial in the $GF(2^{128})$ and is exponentiated ...

3

Reffering to the question provided by me: "Where and how to store private keys in web applications for private messaging with web browsers?" which means that I want to find a bullet proof mechanism to permanently store and protect public keys in web-browser for end-to-end encrypted messaging without needing more than: web-browser HTTPS support javascript ...

3

I read that something like this might be insecure as hashes become less secure the more often you hash them again. While this is technically true, you shouldn't worry about it. This paper has precise bounds on how bad it is to iterate a random function and with the iteration count $r<10$ as you are worrying right now this is a non-issue for security. ...

3

The key is stored physically anyway in the hardware, so access is still possible The assumption is that it is practically impossible to read the keys that reside (permanently or temporarily) inside the HSM. They will be present in usable form, and used, only inside the HSM, and it is the HSM's job to protect these keys (including enforcing restrictions ...

2

Are there any scheme to increase ORAM storage with time while maintaining oblivious? I found this paper that addresses the issue of obliviously resizing: Moataz, Tarik, Travis Mayberry, Erik-Oliver Blass, and Agnes Hui Chan. "Resizable tree-based oblivious RAM." In Financial Cryptography and Data Security, pp. 147-167. Springer Berlin Heidelberg, 2015. I ...

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