Asymmetric Keys
Can someone please validate that I'm on the right track with this line of thought?
I need to generate a private/public key pair using a user's PIN number.
So, I think I need to do the following.
1) Generate a private/public key pair from a PIN number (how, I don't know, as the current generatator uses a random seed).
2) Store the public key but throw away the private key (temporarily).
3) Encrypt data using the stored public key.
4) Later, when the user signs on again, the PIN number will be entered and I'll regenerate the private key dynamically from that PIN number. (I don't want to be able to regenerate the private key from the stored public key in step #2, however).
5) Decrypt data originally stored with the public key using the private key for display to the user.
Am I on the right track? Is this even possible? If so, can someone outline sligntly more detailed pseudocode for me so I know how to proceed? If not, is there another way to achieve my goal?
Message was edited by:
rpalm01
[1074 byte] By [
rpalm01a] at [2007-11-26 14:34:31]
# 1
Since, given the 'seed', one can generate the public and private key you are not really making use of public key encryption. Sounds like all you need is symetric Password/Passphase Base Encryption (PBE).
# 2
Thanks for the quick reply!
My goal is to encrypt data without storing (anywhere), using, or having access to the PIN, however. (Obviously, the user would have to enter it on the web page to be able to see their data...but I'm not going to keep it anywhere in my software or data respository.)
If I use the Password/Passphrase Base Encryption (PBE) will I be able to do that?
# 3
> My goal is to encrypt data without storing
> (anywhere), using, or having access to the PIN,
> however. (Obviously, the user would have to enter it
> on the web page to be able to see their data...but
> I'm not going to keep it anywhere in my software or
> data respository.)
Where is the decryption done? On the server or on the client?
>
> If I use the Password/Passphrase Base Encryption
> (PBE) will I be able to do that?
Depends on the answer to the above.
# 4
Well, this might make more sense if I explain the real problem I'm trying to solve. I need to be able to scan documents and encrypt them using a "public" type key. These documents (files) will reside in a repository on my system.I don't want to be able to decrypt them, ever.However, I'll have a web site the "client" signs in to where they enter their PIN, in addition to standard user/password security information. Then, the document (file) reader can regenerate the user's private key from the PIN and decrypt the document (file) appropriately.
But, I guess this assumes that I won't be able to decrypt the document with the "public" key I'm storing. That's why I thought I needed an asymmetric ciper solution.
Can you tell I'm confused?
# 5
Oh, and all of this will be happening on the server side. I'm going to use the standard HTTPS stuff to secure the web tcp/ip communications. (Which generates its own set of internal private/public keys. I think.)
# 6
> Well, this might make more sense if I explain the
> real problem I'm trying to solve. I need to be able
> to scan documents and encrypt them using a "public"
> type key.
Sounds insecure. If you scan them on your system then your client cannot be sure that you have not created an unencrypted copy.
> These documents (files) will reside in a
> repository on my system.I don't want to be able to
> decrypt them, ever.
Good. Except that you don't need to decrypt the documents since you had access to the unencrpted document when you scannned it so it is insecure as far as you client is concerned.
> However, I'll have a web site
> the "client" signs in to where they enter their PIN,
Once again it is insecure as far as the client is concerned. He sends the PIN to you so you then know the PIN.
> in addition to standard user/password security
> information. Then, the document (file) reader can
> regenerate the user's private key from the PIN and
> decrypt the document (file) appropriately.
Now as far as the client is concerned it is really really insecure since given the PIN you can regenerate the private key and decrypt the document.
>
> But, I guess this assumes that I won't be able to
> decrypt the document with the "public" key I'm
> storing. That's why I thought I needed an asymmetric
> ciper solution.
While ever the decryption takes place on your machine this solution is insecure as far as your clients are concerned. Once you have access to the PIN you have access to both the public and private keys.
A tenet of public key encryption is that only the owner of the private key ever has access to the private key. Since you are expecting to regenerate the private key from the PIN you have access to the private key hence as far as you clients are concerned your system is insecure.
>
> Can you tell I'm confused?
Yes.
Your system is insecure regardless of the encryption method use.
# 7
Well, yes, you're right. It doesn't match up with the "normal" public/private security encryption contract. But, it does solve several problems for me internally.
1) We don't have access to the PIN (and therefore the private key) except programmatically.
2) Unauthorized or rogue users can't "copy" the files off the NAS/repository (to a USB drive, for example) and take them with them to look at them, because they wouldn't know the user's PIN to be able to generate their private key.
3) Client's can't "accidentally" get access to another client's documents because their PIN and/or private key won't match up to allow proper decryption of documents/files on the repository even if there was a bug that created an improper file reference.
As you can tell, I'm really more concerned about the security of the files on the repository than I am about meeting the letter of the law of the security encryption contract. Maybe that's akin to putting a square peg into a round hole. But I think it would work, at least to solve my main problem.
# 8
> 2) Unauthorized or rogue users can't "copy" the files
> off the NAS/repository (to a USB drive, for example)
> and take them with them to look at them, because they
> wouldn't know the user's PIN to be able to generate
> their private key.
You get this security from a user/password system without any encryption.
> 3) Client's can't "accidentally" get access to
> another client's documents because their PIN and/or
> private key won't match up to allow proper decryption
> of documents/files on the repository even if there
> was a bug that created an improper file reference.
You get this security from a user/password system using the password in PBE to encrypt the files.
# 9
I think I hear your point...I'm making this too complicated. I'll just use the PBE encryption to secure the user's files and worry about access to the file system via server/data center security rather this complex mess I'm trying to create.Thanks for being so patient!
