Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
Accumulo >> mail # dev >> Storing Public Key As Column Qualifier

David Medinets 2012-08-14, 13:46
Adam Fuchs 2012-08-14, 13:52
David Medinets 2012-08-17, 01:43
Copy link to this message
Re: Storing Public Key As Column Qualifier
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.
> >>