Is there any reason why I should not store a public key as the Column
Qualifier and an encrypted value as the Value in a record? The idea is
that my scan would return a set of encrypted values which would be
unencrypted by the application using a private key. This is only works
for simple data but it does allow each record to have a different
encryption key pair.

One thing to consider is that there's probably some data leakage by having
the encrypted data associated with a plainly visible key. Other than that,
it sounds like a neat and reasonable thing to try out! Let us know how it
works.

Adam
On Aug 14, 2012 9:47 AM, "David Medinets" <[EMAIL PROTECTED]> wrote:

> Is there any reason why I should not store a public key as the Column
> Qualifier and an encrypted value as the Value in a record? The idea is
> that my scan would return a set of encrypted values which would be
> unencrypted by the application using a private key. This is only works
> for simple data but it does allow each record to have a different
> encryption key pair.
>

My thinking on this topic was a little muddled. I went back to an old
encrypted email project of mine.

# generate private and public keys for andy
openssl genrsa -out andy.pem 2048
openssl rsa -in andy.pem -pubout > andy.pub

#encrypt and decrypt
openssl rsautl -encrypt -pubin -inkey andy.pub < my-message.txt >
my-encrypted-message.txt
openssl rsautl -decrypt -inkey andy.pem < my-encrypted-message.txt <
my-decrypted-message.txt

After encryption, the public key is no longer needed.

> On Aug 14, 2012 9:47 AM, "David Medinets" <[EMAIL PROTECTED]> wrote:
>
>> Is there any reason why I should not store a public key as the Column
>> Qualifier and an encrypted value as the Value in a record? The idea is
>> that my scan would return a set of encrypted values which would be
>> unencrypted by the application using a private key. This is only works
>> for simple data but it does allow each record to have a different
>> encryption key pair.
>>

I agree, while it -seems- like a reasonable thing to do, you could just as
easily use a uuid for the key. I would argue, as a result, that you should
because the uuid has no cryptographic properties that you can mistakenly
rely on and wind up producing an insecure system.

Using the public key as the key opens you to attacks in your protocol
(although perhaps not in the encryption algorithm you're using). For
example, everyone who can read a value can also overwrite the values they
read with whatever message they want. This is probably not what you want,
even if it doesn't present an obvious and immediate risk.

Perhaps what you are looking for is both encryption and signature? Both can
be implemented using common public key algorithms.
On Aug 16, 2012 9:43 PM, "David Medinets" <[EMAIL PROTECTED]> wrote:

> My thinking on this topic was a little muddled. I went back to an old
> encrypted email project of mine.
>
> # generate private and public keys for andy
> openssl genrsa -out andy.pem 2048
> openssl rsa -in andy.pem -pubout > andy.pub
>
> #encrypt and decrypt
> openssl rsautl -encrypt -pubin -inkey andy.pub < my-message.txt >
> my-encrypted-message.txt
> openssl rsautl -decrypt -inkey andy.pem < my-encrypted-message.txt <
> my-decrypted-message.txt
>
> After encryption, the public key is no longer needed.
>
> > On Aug 14, 2012 9:47 AM, "David Medinets" <[EMAIL PROTECTED]>
> wrote:
> >
> >> Is there any reason why I should not store a public key as the Column
> >> Qualifier and an encrypted value as the Value in a record? The idea is
> >> that my scan would return a set of encrypted values which would be
> >> unencrypted by the application using a private key. This is only works
> >> for simple data but it does allow each record to have a different
> >> encryption key pair.
> >>
>