Sure, but a majority of end-users wants to protect personal emails from being snooped upon by corporate firewalls/filtering systems, not by a Big Brother with an access to a transcontinetal fiber.
There is a big difference between generic paranoia and a fear of a job loss:)
Think average Joe, not geekmail crowd. Taking a familiar device (a phone), plugging it into a familiar socket in a familiar fashion, and then operating it in a familiar way without even knowing anything about Internet, VoIP and other cool (but unappealing to regular folks) things. This is extremely viable idea that opens huge consumer market with a simple and clear message -
no-cost-long-distance-calls
Sure, technology-wise it's nothing new, but packaging and marketing are novel and I bet we'll see much more devices of this sort surfacing in coming months. It's a NEXT BIG THING.
As others pointed out, the idea is neat, but not practical.
True peer-to-peer anonymity requires some sort of proxying and the simpliest and the most generic way to implement it is overlay networks. They however come at pretty steep per-packet overhead price - think Gnutella without direct downloads.
Alternately quasi-anonymity may be obtained with peer-to-group communications similar to what freenet's doing and what another poster suggested below with his multi-source downloads idea.
.. But tomorrow, a new coder will add something that modifies the preconditions and suddenly that pointer can indeed be NULL.
That's what assert() exists for. And 'preconditions' you are referring to are actually 'invariants', so if "suddenly that pointer can indeed be NULL" it means that someone broke a fundmental design assumption and should not be tweaking the code anyway.
And for those who haven't seen this trick before, a nice habit to get into is to write your checks like so:..
I found this trick pretty annoying. First of all any decent compiler can catch this with a warning. Second, if you are in fact misplacing == with = so often that you need a special habit for fighting it, then perhaps you should look at what you type:) There are plenty C language constructions that can ruin your code with a single misplaced character:
"xFF" vs "\xFF"
comma operator; for instance, f(param) vs f,(param)
misplaced structure initializers
etc, etc
It does not mean the programmer need to guard against all these too, it just means that the code must be proofread as it's being written, which is a reasonable thing to expect from a professional developer.
Microsoft is already doing this. One of the guys I used to work with in the security realm is now at Microsoft, checking for exploitable code & paths in Palladium. I expect he'll to see this & prevent it in any Trusted system release.
From what I heard and read typical MS development team has a 1:2 ratio of developers and testers, meaning that developers are given tight deadlines and are essentially forced to release untested code. If QA happened to catch bugs - good, if not - they go into the production.
From what you're saying it sounds they now add another layer of 'code auditors', which further clean up after- or in parallel with- the QA. Sounds arguably stupid, but I guess given their huge codebase they dont have much choice.
Sure, in the scope of this particular project and in the context of their skillset and development practices.
Don't Use Binary Protocols for Application Development
Bah, I'm speachless. Yeah, right. Better yet convert data to PNG images and pass those along - it will allow you to debug networking layer with a web browser... Ever heard of protocol layering or data marshalling ?
With all due respect, it looks like Mr.Baranowski either learnt wrong lessons or likes to summarize things beyond reasonable limits.
> If you are a great coder, have good business sense, and good people skills and money takes a back seat to other things....then the GPL can be a good thing.
Or perhaps you may want to use SleepyCat license, which makes a bit more business sense than GPL in many cases.
Don't mix VPNs in. The thread is about nuking TCP connections and unless you mean SSH or PPP by VPN, the issue is irrelevant. Moreover, even with TCP-based VPNs it is easy to write a proggy that will add IP/port pair of authenticated VPN peers into the list of 'dont drop' connections.
However it is vulnerable to man-in-the-middle attacks, which renders it pretty much useless as a mean of any serious protection. The reason Trillian supports it only for ICQ/AIM is because the protocol allows announcing extra client 'capabilities'. Trillian messenger uses this feature to notify peers that they are capable of 'trillian encryption'. Note that this is done via AOL servers, which may at some point decide not to propagate this 'unauthorized' capability and Trillian's encryption will suddenly stop working.
New AIM encryption is not much better either - * their backend is essentially their CA * the clients can be forced to relay messages through the server and these two combined mean that the backend is in the perfect position to launch m-n-m at will.
The transparency of the encryption is two-edged sword - on one hand it certainly provides no-hassle protection, but on other it can trick a user into false sense of security, if the former does not really understand underlying protection principles.
You will be able to make good money from BT if you package the technology in such a way that commercial interests can use it.
What makes you sure it is that simple "package the technology in such a way that commercial interests can use it" ? This is the biggest challenge for any open source (or even closed source for that matter) project.
BitTorrent has got a momentum, but in order to turn it into a commercial success it needs much more than an elegance of the solution and a general interest from a non-paying crowd.
Remember OpenCola (aka SwarmCast) ? It was almost exactly what BitTorrent is in the beginning, yet they evolved into knowledge management, which implies that there was no money in distributed content distribution as-is.
However, there are companies that are present in the subject area. Bycast, for example. But all of them specialize on the very narrow market segments, and that seems to be the only way to get the business off the ground.
Well, you implied you were using built-in Windows VPN, which is a standard IPsec, which is an IP layer protocol. If it happens to run over TCP, it's - as some purists may say - not a VPN and it's definetly not a native Windows component.
I haven't yet spotted any cryptographic "reviews" of this yet, but it certainly looks like an appealing platform to work with.
Appealing or not, but according to the document bundled with source distribution their key exchange takes 8 messages to complete. SSL does it with 4 packets (with multiple messages per packet), IKE - with 3 (in aggressive mode).
They also seem to impose extra load on CPU with unneccessary crypto operations (step 1 and 2), derive keys in funky way, do not provide (or do not document) rekeying mechanisms, do not provide a replay protection, etc, etc.
With all due respect, this stuff needs a major facelift and a cleanup.
Hehe.. I have a friend who got carsick from playing DOOM because of that screen swaying accompanying any forward motion. I dont think he made it past first level:)
I'll say it again if you want: unless the NSA have developed a different attack on AES or a new factoring algorithm, they can't crack anything that you and I can't.
Yup. The keyword is "unless". And unless you are an NSA employee, the "unless" will remain a dominating factor in all speculations about what they can and cannot break.
Sure, but none that can be used when strangers meet for the first time.
If they are total strangers, nothing will help them to authenticate each other. If you are referring to using PKI or SET to establish initial trust via CA paradigm, sure it's an option, but (a) the parties are not exactly 'strangers' anymore (b) I'll say it again if you want: this type of an authentication is just one out of many including essentially any non-cert based authentication schemes (usually over DH-protected channel) - look at CIPE, preshared secret IKE, CHAP, etc.
Next time before you flame someone, please try to understand what they are saying, or the laugh might be on you.
And I'm perfectly aware, that there are faster ways to factor.
Exactly the point. Unlike with symmetric encryption where all but the brute force methods are basically impractical (linear and differential in DES case, for instance), factoring problem has a number of fast non-bruteforce algorithms. And what's more important they all are recent developments. Their young age means there is a good chance for unnamed agency not only to got them developed earlier, but also to already have a faster not-yet-public algorithms in its possession.
That is part of the reason why people use at least four times as many bits for assymetric encryption than for symmetric encryptions.
Yeah, it's a good rule of thumb. It's nothing more though, key bits count in symmetric ciphers and pubkey algorithms are not related as the underlying algorithm ideas are different.
If you don't think that is secure, you should tell us what the time complexity of the fastests known factoring algorithm is.
The only widely used encryption algo that the NSA can crack is 56bit DES
Feel free to believe in this yourself, but please do not 'clear some things up' this way for other people. Everything that you've said is on the must be prefaced with It is commonly believed in my circles in block letters.
WTF is a 'brute force for public key encryption' ? Did you ever heard that assymetric key recovery is essentially a factoring challenge, which is never solved with brute forcing ?
The DES/NSA statement is simply hillarious. I guess it needless to say that unless you're an NSA insider, your words worth nothing.
And, dude, pubke encryption is not 'the only one that allows authentication'. It is in fact used for this purpose in some architectures, but there are plenty authentication schemes that do just fine and rely on other cyrptographic means.
I hope you're right, though it is unlikely. They are basically saying 'we are watching you' and this makes many people uncomfortable at least.
Quite obviously the next step for p2p swapping networks would be to add an anonymity. There are many ways to do it - to create virtual network like X-bone does or to convert indivdual nodes to the proxies or something else. And as pipes are getting fatter, an overhead of overlaying custom p2p topologies over Internet will no longer create any performance or scalability issues. The technology is not a rocket sience, it's already here and once end-users are diverted away from existing p2p networks - watch them switch to new ones. That's basics of the evolution:)
.. data is as secure in one or the other
on
SSH or IPSec?
·
· Score: 3, Informative
There are few aspects of SSH vs. IPsec that you seem to be missing:
* first of all, IPsec can go through NAT, no problem. There is a couple of IETF drafts that - define just that IPsec NAT Traversal. Drafts are in their 5th revision, and Cisco, SSH, Nortel and some other manifacturers already support NAT-T and are quite interoperable with each other. Keep in mind though that it's UDP based, and that's the way it must be, because...
* TCP-based VPNs (and SSH/SSL tunneling in particular) are prone to a trivial DoS attacks, which severely depricates their robustness. I put a quick paper together that provides a bit more details on the subject.
* keep also in mind that tunneling over SSH leads to TCP-over-TCP encapsulation, which is considered by many 'a bad idea' in general due to the induced TCP retransmission problems.
* you may also consider that SSH comes with a higher average per-packet overhead (due to TCP ACKs), which may require more frequent re-keying when compared to IPsec, which in turn may bring overall VPN performance down.
The bottom line is I would not recommend SSH over IPsec unless it's a time-critical project.. or you dont have a budget for a decent IPsec client:)
This is a very important part that is often overlooked as demonstrated by the following example:
The University of North Carolina has finally found a network server that, although missing for four years, hasn't missed a packet in all that time. Try as they might, university administrators couldn't find the server. Working with Novell Inc. (stock: NOVL), IT workers tracked it down by meticulously following cable until they literally ran into a wall. The server had been mistakenly sealed behind drywall by maintenance workers.
Slashdot Mirror
Sure, but a majority of end-users wants to protect personal emails from being snooped upon by corporate firewalls/filtering systems, not by a Big Brother with an access to a transcontinetal fiber.
:)
There is a big difference between generic paranoia and a fear of a job loss
Geek mail is another service-based option;
handles Hotmail and Yahoo accounts among other things.
Think average Joe, not geekmail crowd. Taking a familiar device (a phone), plugging it into a familiar socket in a familiar fashion, and then operating it in a familiar way without even knowing anything about Internet, VoIP and other cool (but unappealing to regular folks) things. This is extremely viable idea that opens huge consumer market with a simple and clear message -
no-cost-long-distance-calls
Sure, technology-wise it's nothing new, but packaging and marketing are novel and I bet we'll see much more devices of this sort surfacing in coming months. It's a NEXT BIG THING.
To quote their press release:
To obtain high-resolution photos of HoloTouch in action, visit http://www.holotouch.com/pressroom.htm.
Perhaps my English is not that good, but doesn't this mean there is a working prototype ?
Or did they actually mean to say 'hi-res images of HoloTouch in imaginery action' ?
As others pointed out, the idea is neat, but not practical.
True peer-to-peer anonymity requires some sort of proxying and the simpliest and the most generic way to implement it is overlay networks. They however come at pretty steep per-packet overhead price - think Gnutella without direct downloads.
Alternately quasi-anonymity may be obtained with peer-to-group communications similar to what freenet's doing and what another poster suggested below with his multi-source downloads idea.
.. But tomorrow, a new coder will add something that modifies the preconditions and suddenly that pointer can indeed be NULL.
:) There are plenty C language constructions that can ruin your code with a single misplaced character:
That's what assert() exists for. And 'preconditions' you are referring to are actually 'invariants', so if "suddenly that pointer can indeed be NULL" it means that someone broke a fundmental design assumption and should not be tweaking the code anyway.
And for those who haven't seen this trick before, a nice habit to get into is to write your checks like so:..
I found this trick pretty annoying. First of all any decent compiler can catch this with a warning. Second, if you are in fact misplacing == with = so often that you need a special habit for fighting it, then perhaps you should look at what you type
"xFF" vs "\xFF"
comma operator; for instance, f(param) vs f,(param)
misplaced structure initializers
etc, etc
It does not mean the programmer need to guard against all these too, it just means that the code must be proofread as it's being written, which is a reasonable thing to expect from a professional developer.
Microsoft is already doing this. One of the guys I used to work with in the security realm is now at Microsoft, checking for exploitable code & paths in Palladium. I expect he'll to see this & prevent it in any Trusted system release.
From what I heard and read typical MS development team has a 1:2 ratio of developers and testers, meaning that developers are given tight deadlines and are essentially forced to release untested code. If QA happened to catch bugs - good, if not - they go into the production.
From what you're saying it sounds they now add another layer of 'code auditors', which further clean up after- or in parallel with- the QA. Sounds arguably stupid, but I guess given their huge codebase they dont have much choice.
C/C++ is no longer a viable development language
... Ever heard of protocol layering or data marshalling ?
Sure, in the scope of this particular project and in the context of their skillset and development practices.
Don't Use Binary Protocols for Application Development
Bah, I'm speachless. Yeah, right. Better yet convert data to PNG images and pass those along - it will allow you to debug networking layer with a web browser
With all due respect, it looks like Mr.Baranowski either learnt wrong lessons or likes to summarize things beyond reasonable limits.
> As Cypher once said...
He didn't say it yet if you know what I mean.
> If you are a great coder, have good business sense, and good people skills and money takes a back seat to other things....then the GPL can be a good thing.
Or perhaps you may want to use SleepyCat license, which makes a bit more business sense than GPL in many cases.
Don't mix VPNs in. The thread is about nuking TCP connections and unless you mean SSH or PPP by VPN, the issue is irrelevant. Moreover, even with TCP-based VPNs it is easy to write a proggy that will add IP/port pair of authenticated VPN peers into the list of 'dont drop' connections.
100% agree
However it is vulnerable to man-in-the-middle attacks, which renders it pretty much useless as a mean of any serious protection. The reason Trillian supports it only for ICQ/AIM is because the protocol allows announcing extra client 'capabilities'. Trillian messenger uses this feature to notify peers that they are capable of 'trillian encryption'. Note that this is done via AOL servers, which may at some point decide not to propagate this 'unauthorized' capability and Trillian's encryption will suddenly stop working.
New AIM encryption is not much better either -
* their backend is essentially their CA
* the clients can be forced to relay messages through the server
and these two combined mean that the backend is in the perfect position to launch m-n-m at will.
The transparency of the encryption is two-edged sword - on one hand it certainly provides no-hassle protection, but on other it can trick a user into false sense of security, if the former does not really understand underlying protection principles.
You will be able to make good money from BT if you package the technology in such a way that commercial interests can use it.
What makes you sure it is that simple "package the technology in such a way that commercial interests can use it" ? This is the biggest challenge for any open source (or even closed source for that matter) project.
BitTorrent has got a momentum, but in order to turn it into a commercial success it needs much more than an elegance of the solution and a general interest from a non-paying crowd.
Remember OpenCola (aka SwarmCast) ? It was almost exactly what BitTorrent is in the beginning, yet they evolved into knowledge management, which implies that there was no money in distributed content distribution as-is.
However, there are companies that are present in the subject area. Bycast, for example. But all of them specialize on the very narrow market segments, and that seems to be the only way to get the business off the ground.
2c
Well, you implied you were using built-in Windows VPN, which is a standard IPsec, which is an IP layer protocol. If it happens to run over TCP, it's - as some purists may say - not a VPN and it's definetly not a native Windows component.
:)
Still nitpicking
What's that you run anyways ?
...forward one TCP port (yes, only one) from your firewall to desktop, and that's it forever.
:)
That's "one IP protocol", not "one TCP port".
Just nitpicking
I haven't yet spotted any cryptographic "reviews" of this yet, but it certainly looks like an appealing platform to work with.
Appealing or not, but according to the document bundled with source distribution their key exchange takes 8 messages to complete. SSL does it with 4 packets (with multiple messages per packet), IKE - with 3 (in aggressive mode).
They also seem to impose extra load on CPU with unneccessary crypto operations (step 1 and 2), derive keys in funky way, do not provide (or do not document) rekeying mechanisms, do not provide a replay protection, etc, etc.
With all due respect, this stuff needs a major facelift and a cleanup.
You won't need to physically swipe it, simply waving it over a reader is good enough.
DON'T OVERWAVE
DOOM. Nightmares ..
.. I have a friend who got carsick from playing DOOM because of that screen swaying accompanying any forward motion. I dont think he made it past first level :)
Hehe
> The DES/NSA statement is simply hillarious.
I'll say it again if you want: unless the NSA have developed a different attack on AES or a new factoring algorithm, they can't crack anything that you and I can't.
Yup. The keyword is "unless". And unless you are an NSA employee, the "unless" will remain a dominating factor in all speculations about what they can and cannot break.
Sure, but none that can be used when strangers meet for the first time.
If they are total strangers, nothing will help them to authenticate each other. If you are referring to using PKI or SET to establish initial trust via CA paradigm, sure it's an option, but
(a) the parties are not exactly 'strangers' anymore
(b) I'll say it again if you want: this type of an authentication is just one out of many including essentially any non-cert based authentication schemes (usually over DH-protected channel) - look at CIPE, preshared secret IKE, CHAP, etc.
Next time before you flame someone, please try to understand what they are saying, or the laugh might be on you.
Same to you, bud, same to you.
And I'm perfectly aware, that there are faster ways to factor.
Exactly the point. Unlike with symmetric encryption where all but the brute force methods are basically impractical (linear and differential in DES case, for instance), factoring problem has a number of fast non-bruteforce algorithms. And what's more important they all are recent developments. Their young age means there is a good chance for unnamed agency not only to got them developed earlier, but also to already have a faster not-yet-public algorithms in its possession.
That is part of the reason why people use at least four times as many bits for assymetric encryption than for symmetric encryptions.
Yeah, it's a good rule of thumb. It's nothing more though, key bits count in symmetric ciphers and pubkey algorithms are not related as the underlying algorithm ideas are different.
If you don't think that is secure, you should tell us what the time complexity of the fastests known factoring algorithm is.
Well, since you've asked it's -
O(exp(sqrt(ln(n)*ln(ln(n))))) for MPQS
O(exp(c*(ln(n)^1/3*ln(ln(n)^2/3))) for NFS.
Both are far from being O(exp(n)), btw.
The only widely used encryption algo that the NSA can crack is 56bit DES
Feel free to believe in this yourself, but please do not 'clear some things up' this way for other people. Everything that you've said is on the must be prefaced with It is commonly believed in my circles in block letters.
WTF is a 'brute force for public key encryption' ? Did you ever heard that assymetric key recovery is essentially a factoring challenge, which is never solved with brute forcing ?
The DES/NSA statement is simply hillarious. I guess it needless to say that unless you're an NSA insider, your words worth nothing.
And, dude, pubke encryption is not 'the only one that allows authentication'. It is in fact used for this purpose in some architectures, but there are plenty authentication schemes that do just fine and rely on other cyrptographic means.
The RIAA is doing this out of utter desparation.
:)
I hope you're right, though it is unlikely. They are basically saying 'we are watching you' and this makes many people uncomfortable at least.
Quite obviously the next step for p2p swapping networks would be to add an anonymity. There are many ways to do it - to create virtual network like X-bone does or to convert indivdual nodes to the proxies or something else. And as pipes are getting fatter, an overhead of overlaying custom p2p topologies over Internet will no longer create any performance or scalability issues. The technology is not a rocket sience, it's already here and once end-users are diverted away from existing p2p networks - watch them switch to new ones. That's basics of the evolution
There are few aspects of SSH vs. IPsec that you seem to be missing:
...
.. or you dont have a budget for a decent IPsec client :)
* first of all, IPsec can go through NAT, no problem. There is a couple of IETF drafts that - define just that IPsec NAT Traversal. Drafts are in their 5th revision, and Cisco, SSH, Nortel and some other manifacturers already support NAT-T and are quite interoperable with each other. Keep in mind though that it's UDP based, and that's the way it must be, because
* TCP-based VPNs (and SSH/SSL tunneling in particular) are prone to a trivial DoS attacks, which severely depricates their robustness. I put a quick paper together that provides a bit more details on the subject.
* keep also in mind that tunneling over SSH leads to TCP-over-TCP encapsulation, which is considered by many 'a bad idea' in general due to the induced TCP retransmission problems.
* you may also consider that SSH comes with a higher average per-packet overhead (due to TCP ACKs), which may require more frequent re-keying when compared to IPsec, which in turn may bring overall VPN performance down.
The bottom line is I would not recommend SSH over IPsec unless it's a time-critical project
: .. cut the lan/wan/internet lines ..
:
This is a very important part that is often overlooked as demonstrated by the following example
The University of North Carolina has finally found a network server that, although missing for four years, hasn't missed a packet in all that time. Try as they might, university administrators couldn't find the server. Working with Novell Inc. (stock: NOVL), IT workers tracked it down by meticulously following cable until they literally ran into a wall. The server had been mistakenly sealed behind drywall by maintenance workers.