[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


* 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)
> 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
> %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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]