[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-recutils] Feature Request: Confidential Fields
From: |
Sven Wick |
Subject: |
Re: [bug-recutils] Feature Request: Confidential Fields |
Date: |
Thu, 25 Aug 2011 16:33:35 +0200 |
User-agent: |
RoundCube Webmail/0.2.2 |
> How would recfix recognize non-encrypted values?
Well, we could recognize encrypted values
with a prefix. See explanation below...
> How that would work?
> We would need to distribute the encryption key
in the recfile, somehow, right?
Hm, yeah, I haven't thought about distributing
the encryption key.
I think we can't really make this bulletproof encryption.
It's more like hiding some data from the average joe.
So maybe just XOR-ing the data is simple
and fast enough.
I am still juggling around with some ideas
and am sure that I miss something.
So, how about the following concept?
Here we even can omit the password:
%rec: Customer
%type: Phone re /[0-9]{8}/
%confidential: Phone /encryption/Phone.key
%confidential: Address /encryption/shared.key
Id: 0
Phone: encrypted-x67984328098
Address: encrypted-z4378vccvx
Id: 1
Phone: +49 721 123456789
Address: Hell
%rec: Password
%confidential: Password /encryption/shared.key
Id: 0
Password: encrypted-XHG453FF
Id: 1
Password: MySecret
Like this we can use seperate keys
or share a key for multiple %rec.
Getting data
------------
* From the record descriptor
we know which fields are confidential
and from which file to get the key
for reversing the XOR.
* If a confidential value starts
with the prefix "encrypted-"
we know it was encrypted (XOR-ed) :-)
The remainder of the value is our data
XOR-ed with the key from the keyfile.
recsel then tries to open the keyfile,
gets the key, strips the prefix
and XORs the encrypted data with the key
to get our original value.
* If a confidential value doesn't
have a prefix, just output the data.
This is then a job for recfix.
* We could use filesystem permissions
to give read permissions only to specific system users or groups.
If recsel can't get the keyfile
due to file permissions or something else,
don't try decrypt - just output the current value.
Adding data
-----------
* As usual but for confidential fields
use the key from the keyfile
and XOR it with the data.
Append a prefix to the now encrypted data
and save it as value.
If the keyfile can't be accessed
throw a constraint error
because without the key,
we can't make it confidential.
Fixing data
-----------
* recfix checks the value of
confidential fields
whether it has a prefix or not.
If it has no prefix, then it is un-encrypted data
and recfix then XORs/encrypts it
with the key from the corresponding keyfile
Pitfalls
--------
* Changing keys
When data initially was encrypted
with some key and this key changes,
new data will be XOR-ed with
the new key.
Old data then can't be recovered anymore
and is lost.
But this is the always the case
when losing a key.
This is the responsibilty of the user
taking care and using his keys carefully.
Now we can just give the main recfile
to someone else
and without the keyfiles
he won't see any confidential data
but is able to see all the other entries.
On Thu, 25 Aug 2011 11:02:58 +0200, address@hidden (Jose E. Marchesi)
wrote:
> Hi Sven.
>
> Here is my idea:
> A field which holds a hashed password or maybe a list of hashed
> passwords:
> [...]
> A type to flag fields as 'confidential':
>
> Sounds like an useful facility. I like the idea, but I would use a
> different way to mark fields as confidential:
>
> %rec: Customer
> %password: HASHEDPASSWORD
> %type: Phone re /[0-9]{8}/
> %confidential: Phone
>
> This way, introducing a new %confidential special field, Phone can still
> have a type. The hash in %password is used for all confidential fields
> in the given record set.
>
> Another issue is which encryption/decryption algorithm to use, and which
> algorithm to use to generate the passwords. I was thinking on applying
> something similar to what is used in PDF files: symetric AES
> encryption. But I am not an expert in that field.
>
> 2) Insertion should be done via recins
> and then stored as encrypted text.
>
> This way, entries can be done
> without knowing the password
>
> Only getting the data needs a password.
>
> How that would work? We would need to distribute the encryption key in
> the recfile, somehow, right?
>
> 3) If insertions is done via a text editor,
> recfix could encrypt it afterwards.
>
> How would recfix recognize non-encrypted values?