* Glynn Clements wrote on Tue, May 28, 2002 at 03:51 +0100: > Steffen Dettmer wrote: > > > > One possible solution, assuming you need to write the data but not read it > > > until later is to encrypt it, generate a public/private keypair using > > > pgp/gnupg, load the public key onto the server with your app, have it write > > > the files after encrypting the data. Thus you can retrieve the data (ftp, > > > www, whatever) and then decrypt it at your leisure and use it. > > > > I don't think that this makes things secure. If the web server > > runs as nobody, the CGI script must be executable for nobody. The > > secret key must be reable for nobody. > > No; only the *public* key needs to reside on the server, and that > doesn't need to be secure. That's the whole point of "public key" > cryptosystems. You can protect the data against unauthorized readers, yes, but you cannot protect from faked data injections, since everyone could use that key. So you don't know what parts of the data are correct, and which might have been replaced by an attacker (replacing is also possible, since all users use nobody permissions! and of course the attacker can overwrite or erase the data). So you would need to sign that to make sure it's not injected by unauthorized source. In most cases encryption with pub keys without encryption makes not much sense, since you still cannot trust the data (but it's private - even the faked data is protected). You know that the data can be read only by you, but you don't know who claimed that this is valid stuff! The replay attacks are easily possible as well. I wouldn't call this "secure"... oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
This archive was generated by hypermail 2b30 : Wed May 29 2002 - 11:43:35 PDT