How The Telcos And The Government Are About To Boost The Encryption Market
what say ye? a stirring amidst the complacent masses? http://techdirt.com/articles/20060621/1251235.shtml """ here's lots of news today about the (not particularly surprising) revelations that AT&T may have helped monitor internet traffic for the NSA. It's interesting to note, with this news, the side story that AT&T also just revamped their privacy policy, allowing them to more freely share whatever data they collect with government officials. However, rather than discuss those two issues (which are being discussed widely), a more interesting question is whether or not this, along with the ongoing debates around net neutrality, will actually lead more people to simply encrypt their internet traffic. It certainly could open up quite the business opportunity for firms providing encrypted VPN systems that basically scramble all your data so your ISP can't snoop and can't prioritize (or downgrade) the traffic. """ poor chumps who buy the proprietary snake oil; true security requires visibility, and alas there's not a big market for decentralized open source security/privacy infrastructure (a paying market that is). [sometimes virtue is its own reward. and sometimes it at least gets you beers and whiskey.]
On Wed, Jun 21, 2006 at 07:26:54PM -0700, coderman wrote:
lead more people to simply encrypt their internet traffic. It
Ah, if it only would be "simply". Interoperability requires the same method on both ends, and session setup latency better be invisible. No such animal yet.
certainly could open up quite the business opportunity for firms providing encrypted VPN systems that basically scramble all your data so your ISP can't snoop and can't prioritize (or downgrade) the traffic.
That's precisely what I'm gearing up to do. Server-side embedding shared secret into OpenVPN, connecting to customer's own vserver. What I don't yet know (but need to find out) whether by being mediator I'm technically an ISP, or not. If I am, I've got the data retention liability albatross around my neck.
poor chumps who buy the proprietary snake oil; true security requires visibility, and alas there's not a big market for decentralized open source security/privacy infrastructure (a paying market that is).
[sometimes virtue is its own reward. and sometimes it at least gets you beers and whiskey.] -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
On 6/22/06, Eugen Leitl
... Server-side embedding shared secret into OpenVPN, connecting to customer's own vserver.
What I don't yet know (but need to find out) whether by being mediator I'm technically an ISP, or not. If I am, I've got the data retention liability albatross around my neck.
is there a way to offload the critical (key secrecy) parts to a trusted third party / external location so that retention would be effectively pointless? (that is to say, within the jurisdiction of data retention let them archive all the blackened traffic they want until the heat death of the universe...)
On Thu, Jun 22, 2006 at 03:18:08PM -0700, coderman wrote:
is there a way to offload the critical (key secrecy) parts to a trusted third party / external location so that retention would be effectively pointless?
Excellent idea, thanks. Outsourcing secret management to a different organisation sounds just the ticket.
(that is to say, within the jurisdiction of data retention let them archive all the blackened traffic they want until the heat death of the universe...)
-- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
participants (2)
-
coderman -
Eugen Leitl