>>the relative merits of CKE for *finally*
>>convincing the US government to allow strong encryption (64 bit for now in
>>software) as long as an "escrow" feature is present.
> As I understand it, the idea of commercial key escrow is
>that you might someday want to recover encrypted data, and
>therefore you escrow the key with your corporate escrow agent,
>so that it can be recovered as necessary.
> Now, with firewall-to-firewall encryption, in which
>the encryption is being applied to *IP* *PACKETS* can you think
>of anything more useless than an escrowed packet?
> Suppose I FTP a file to my office in Europe - it is
>transparently encrypted in transit - are we to imagine a
>scenario in which someday I will want to recover my file by
>reassembling it from encrypted IP packets? Huh? Does anyone
>on this list archive their *PACKETS* for future recovery?
> I'm sure this brain damage isn't TIS' idea, they're
>working under some pretty wacky regulations. Your tax dollars
>at work, eh what?
I missed the jist of the original message, but a device that supports a key
escrow function can be used for interception of communications and/or
stored data. If one is using an FTP encryption program, then data
recovery keys will be needed to recover data at the FTP server or client
machine (since data is encrypted). For the firewall-to-firewall encryption
scenario, the data recovery component (DRC) may be a machine that
intercepts (in real-time) the traffic and then decrypts the data (recovers
the data). The interception of encrypted data makes sense for this type of
communication since the data is not really stored on the firewall (it is
wrapped/unwrapped quickly). [the intercepted packet may be copied and then
All of this assumes that the technologies would be developed/enhanced to
support this scenario (e.g., encrypted data has data recovery field, etc.).
The other issue is that the DRC would have to sitting in the right place
to intercept this traffic since IP packets often take different routes. At
some point, if all the firewall vendors support a common IP-level
encryption standard (e.g., IPsec, S/WAN) then this may provide an opening
to a common key escrow capability for firewall-to-firewall encryption.
This is a guess. Whether this all makes sense is a different topic....