Re: Customer data encryption (asynchronous vs synchronous)

ok, I have time for another comment.

From what I read only using an asymmetric cipher would be very slow.

The question is whether you need to the speed enough to warrant that extra code. The extra code increases development time, the probability of a bug, the probability of a security bug, debugging time and maintenance time.

From the customer's perspective: No. The tool will only be used on rare occasion, and the few seconds lost on those occasions won't matter.

From your perspective: Maybe. Will you be receiving data from many customers at the same time? often? From what you said, it doesn't like it.

Since you have to do it anyway, start with trying just the asymetric portion. If your needs aren't satisfied, then add the symetric bit.

Comment on Re: Customer data encryption (asynchronous vs synchronous)

Replies are listed 'Best First'.
Re^2: Customer data encryption by derby (Abbot) on Feb 25, 2007 at 12:34 UTC
From what I read only using an asymmetric cipher would be very slow. Most public key implementations do symmetric encryption of the payload with a session key. Only the encryption of the session key is asymmetric. I'd like to see some attribution (and benchmarks) for the "slowness." From what I've seen (which of course is limited), it's the generation of the session key which can be slow - but that's normally a problem with ill configured systems. So whether you go public key to begin with or the home-grown re-implementation , you're going to have the same slowness issue (generating a session key), unless you always use the same session key and in that case, why bother at all. -derby	[reply]
Re^2: Customer data encryption (asynchronous vs synchronous) by 0xbeef (Hermit) on Feb 25, 2007 at 13:47 UTC
The problem really is my lack of benchmark data, so I included the size of the output in my post in case someone knows. If the slowdown is unacceptable, e.g. >10mins at the customer side, I'd then rather opt for the symmetric solution. Niel	[reply]


P is for Practical
	PerlMonks