How to decrypt multiple blocks in one text file
linux at codehelp.co.uk
Fri Oct 17 19:34:05 CEST 2003
On Friday 17 Oct 2003 11:27 am, Hanno Mueller wrote:
> I'm collecting personal data from a web form. Since I don't want to
> store it in cleartext, I use gpg to encrypt each dataset the moment I
> receive it and put the encrypted text in a database.
> As an example, let's store the three datasets "1,bla,test1"
> "2,blubb,test2" and "3,blob,test3" as encrypted text in the database.
> So now I have several blocks of encrypted data. However, the result file
> after decryption should be a single text file like this:
> Since all datasets are to be collected in such a single file, anyway, I
> thought it might be possible to decrypt a single text file with many
I'm using similar authentication processes but can there really be a need for
one single file? It's very inefficient by the time you have more than 20
users - it's not indexed, finding user 5 still means reading the entire file
into memory. You've got a database backend, why not create a second table?
create table webformtable (id int(10) not null primary key auto_increment,
reference in(10) not null,
One record per user, use reference to link to another table where other
details of that user are stored and query using:
select content from webformtable,datatable where datatable.id = reference and
reference = $variable;
However, if you trust the server enough to receive and encrypt the data in the
first place, you might as well store the data as cleartext above the
public_html/ folder (out of reach of any inquisitive browser) and let the
security of the server be your protection. After all, if I was to crack the
server, I could delete the encrypted content or insert new values (the public
key must be present for you to encrypt so I can use the same key to encrypt
malicious or random data). With the server cracked, your authentication is
lost and the need to protect the dataset (which sound awfully like
username/password combos) is lost too - you can't protect data on the server
once the server itself is compromised without encrypting all sensitive data,
not just the identification strings for authentication.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Url : /pipermail/attachments/20031017/9d9f7d09/attachment.bin
More information about the Gnupg-users