# Tag Info

13

The best you can hope for is the following: You derive the password into a "big enough" (e.g. 128 bits) secret key $K$ with a Key Derivation Function like PBKDF2. There are some details to be aware of (see below). You use the secret key $K$ as seed for a Pseudorandom Number Generator. The PRNG is deterministic (same seed implies same output sequence) and ...

8

You were doing fine up to the point where you wrote "JavaScript". Of course, JavaScript as a language is not fundamentally unusable for crypto (although, as a high-level scripting language, any crypto primitives implemented in JavaScript are likely to be rather slow and hard to secure against side channel attacks). However, when you write "JavaScript", I ...

7

Yes, it's trivial. You encrypt each item with its own random key. You then need only encrypt the key to each album for Bob and Carol. A typical way to do this is to publish an encrypted per-user keyring -- one for Bob and one for Carol. Bob and Carol can each decrypt their keyrings to get the keys to all the objects they are supposed to access. The reverse ...

6

Yes, this is possible (conditionally). It sounds like you want Format Preserving Encryption. FPE works by encrypting from an arbitrary domain $X$ onto $X$. Consequentially, if plaintext $M \in X$ is encrypted to ciphertext $C \in X$, any decryption of $C$ - even with the wrong key - will yield a decrypted message inside of $X$. Thus an attacker doesn't know ...

4

A common approach is to encrypt the private key with a symmetric key derived from a pass phrase. This will be as secure as the chosen pass phrase. I'd suggest sticking with this approach; its conventionality makes it "simpler" than a solution that hasn't been studied well.

3

Your problem, the way I read it, could be described as follows: You are currently using password encryption for protecting the confidentiality of files on a known format. You have concerns regarding the long term confidentiality of those files, given that you don't know what computers will be able to do in the future. Ideally, you want the confidentiality to ...

3

The usual solution to this problem would be to use separate session keys for each file (or album), and then encrypt these session keys separately with the long-term keys of the intended recipients. You could use asymmetric encryption (RSA or other public-key encryption schemes) for the second step, then Alice would only need to know the public keys of Bob ...

2

First, as a bit of general advice: Designing a secure cryptographic system is hard. Experts with decades of experience still make mistakes. Depending on your intended audience, you may be better served by looking for an established system that meets your needs rather than trying to design an implement something from scratch. To answer your specific question ...

2

Getting data from user A to user B securely generally works via asymmetric encryption. Encrypt the data with B's public key and store the result on the server. B then retrieves the encrypted data and decrypts it using his private key. This assumes the server does not store the private key, or at least stores it in a form that can only be decrypted by the ...

2

It sounds like you're trying to set up a "host-proof" system. ( How can one share information using the 'host-proof' paradigm? ; Encryption scheme for social-network-like data sharing data via untrusted server? ; host-proof etc. ). Sounds like a fascinating problem. I'm assuming you're trying to set things up so that no data is stored on the client ...

1

Its of course doable. Please be referred to this paper for more details.

1

Yes, you can use PBKDF to derive keys for asymmetric encryption too. This is most convenient with encryption schemes such as ElGamal, IES or their elliptic curve variants, where a private key is simply a random number chosen from a given interval. In principle, you could do the same with RSA too, but the key generation process is more cumbersome. You ...

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