According to their FAQ - yes. But since they use closed protocol, it is not worth a penny. They can be calling XOR masking an 'unrivaled privacy' for all I know.
They can't claim security unless it's verifiable, and it cannot be verifiable unless it's open. And even if it's open, the implementation can be flawed either accidently or intentionally (!).
So the best bet for an average paranoid is to consider calls going in plaintext unless proved otherwise.
IIRC the key to a naturally-looking ray-traced skin (or any natural material for that matter) is twofold -
* selecting a proper BRDF (bidirectional reflectance distribution function), which is very hard to get right even for a simple things like milk or paper
* accounting for a surface translucency, ie the fact that the ray hitting the surface not only gets reflected or diffused back into the air, but also partially absorbed by the surface itself. See here for details (sample renderings included).
Similarly to the what parent post said, both are very CPU-intensive problems, so you can go either with a brain-pleasing still picture of railgun bearer or an actual gameplay:) The choice is yours.
Scroll Lock is used by modern Linksys and Belkin KVMs to either switch between the machines (for 2-node KVMs) or to enter KVM console mode. And it's certainly a better choice compared to the older Ctrl-Ctrl switching sequence.
CapsLock on other hand is not only useless, it occupies valuable real estate under a left pinky. So, let's stay on the subject, shall we ?:)
The funny part is that eventhough in 99% of the cases XML is indeed transparent to the user it is still selected over binary formats (DER, TLV, whatever) because it's ASCII !
Having talked to religious XML zealots in a past, I gathered that they either were simply not aware of the alternatives or were 'afraid' of the binary formats due to the nature of their programming environments (VB & co). Duh.
The trend among content-filtering firewalls is to filter SSL sessions by splitting them in two - one from the client to the firewall and another from the firewall to the server. If the session cannot be split, it's rejected.
Eventhough it's client-friendly man-in-the-middle attack, which defeats the whole purpose of SSL, there is a demand for this functionality.
--
The way it works is the client installs extra root CA certificate, and the firewall is given its own CA-enabled certificate derived from the former. Whenever it sees SSL connection coming from the client, it accepts its on behalf of the server, handshakes with the server, then replicates server's certificate signing with its own key and proceeds handshaking with the client. And the client accepts this forged peer's certificate, because it traces back to 'trusted' firewall CA. Pure magic.
You'd be surprised to learn that average (antivirus) file scanner is capable of unwrapping and checking tar/gz/rar/ace/.. files up to ten levels deep. Some most advnaced ones do that in a pass-through mode, ie without buffering entire file. And only most primitive scanners rely on file extension when it comes to determining file content.
In other words zipping.mp3 4 times and then rar'ing it will not help. Renaming resulting archive back into.mp3 will help even less.
As others pointed out, trusted p2p networks is a next logical evolution step. If properly implemented, it should last a while.
Search feature sounds pretty much like what M2 client has: Search your M2 e-mails for almost anything. A search "sticks" and becomes an access point, so that you can easily refer to it in the future.
I realize that M2 is not free and not web-based, but still it makes Gmail's searching much less of a novelty than someone;) may want it to appear.
The point is that GMail is unique due to the combination of features it has to offer, which among other things include kick-ass UI, search and storage space.
There is RFC 2385 titled Protection of BGP Sessions via the TCP MD5 Signature Option. In the first paragraph of its Introduction section it says - The primary motivation for this option is to allow BGP to protect itself against the introduction of spoofed TCP segments into the connection stream. Of particular concern are TCP resets.
The date of publishing - August 1998, which makes it about 6 years old.
However the proposed option was primarily meant as a quick BGP fixup, which should've got depricated as soon as IPsec got RFC'ed and deployed. It did went standard few months later, but IPsec implementations enjoyed full share of cross-vendor compatibility problems.
With time Authenticated Header (AH) IPsec protocol didn't see much use or acceptance and IPsec slowly evolved (and keeps evolving) into confidentiality rather than authentication layer.
Besides it's an IP security after all, while the RST spoofing is a TCP problem. And one can quite rightfully percieve authenticating TCP with IPsec as an overkill.
Anyhow, long story short - it's a known and rather old problem with handful of existing and equally unattractive solutions. Perhaps this time around it will be addressed better due to the amount of the publicity it's aimed to get.
You are assumed to have a cell phone. Phone's location can be triangulated with a precision of up to a meter or so.
Cell company providing this information back to the owner of the phone _most likely_ will not break any privacy laws of whatever the country is, so it should be rather trivial for them to provide the service if there's a demand. They already geo-position 911 calls, so the technology is there.
KAME project comes to mind, and its IKE key manager racoon in particular. It may not be the most up-to-date IKE implementation, but it's certainly one of the cleanest and well-designed ones compared to other major OpenSource IPsec projects.
Both habeas and bonded-sender are the stupidiest antispam ideas only beaten by this marvel. How can one expect spammers in non-US countries to abide US copyright rules is beyond me.. especially given that a half of the spam is sent from spoofed emails using hijacked machines or through open relays.
I poked around similar idea few months ago. The only difference is that instead of port knocking I used ping knocking, which used varying sizes of ICMP pings as an opening sequence. It worked really well, plus unlike TCP/UDP knocking it was simplier to use and had less problems with restrictive firewalls and traffic scanners - ping x.x.x.x -c 1 -s 233 ping x.x.x.x -c 1 -s 122 ping x.x.x.x -c 1 -s 627 ssh x.x.x.x
Required couple of hours of netfilter hacking, but that's a fair price for an obfuscated port-scan protection.:)
If you are assuming that knocking sequence is static, then - yeah, it's prone to sniffing and I agree with you on all items you listed. You also assume that the knock is equivalent to the password in canonical authentication scheme, ie there's no username and it's the same for everyone.
However it is trivial to extend the knock to include an analog of a username and to make the password portion dependent on it. Say, first 4 ports knocked comprise user ID, and next 4 make up an authentication part.
This clearly enables all existing one-way authentication schemes ranging from simple one-time/discardable passwords to those based on hardware tokens.
I think the idea certainly has a potential, but it's hardly suitable for open solutions in its present form.
Slashdot Mirror
According to their FAQ - yes. But since they use closed protocol, it is not worth a penny. They can be calling XOR masking an 'unrivaled privacy' for all I know.
They can't claim security unless it's verifiable, and it cannot be verifiable unless it's open. And even if it's open, the implementation can be flawed either accidently or intentionally (!).
So the best bet for an average paranoid is to consider calls going in plaintext unless proved otherwise.
Then how about JUGDERDEMIDIYN GURRAGCHA, who is not only first Mongolian cosmonaut, but is also named way beyond 'dramatically'.
In fact, here is a complete list of all 436 cosmo-/astronauts. Choose your favourite
All the time
IIRC the key to a naturally-looking ray-traced skin (or any natural material for that matter) is twofold -
* selecting a proper BRDF (bidirectional reflectance distribution function), which is very hard to get right even for a simple things like milk or paper
* accounting for a surface translucency, ie the fact that the ray hitting the surface not only gets reflected or diffused back into the air, but also partially absorbed by the surface itself. See here for details (sample renderings included).
Similarly to the what parent post said, both are very CPU-intensive problems, so you can go either with a brain-pleasing still picture of railgun bearer or an actual gameplay
Scroll Lock is used by modern Linksys and Belkin KVMs to either switch between the machines (for 2-node KVMs) or to enter KVM console mode. And it's certainly a better choice compared to the older Ctrl-Ctrl switching sequence.
CapsLock on other hand is not only useless, it occupies valuable real estate under a left pinky. So, let's stay on the subject, shall we ?
If it is going to suck up all my money and keys...
At least you'll know where to find them.
Elecrotux seems more appropriate :)
You've gotta be kidding
The funny part is that eventhough in 99% of the cases XML is indeed transparent to the user it is still selected over binary formats (DER, TLV, whatever) because it's ASCII !
Having talked to religious XML zealots in a past, I gathered that they either were simply not aware of the alternatives or were 'afraid' of the binary formats due to the nature of their programming environments (VB & co). Duh.
Internet Problem Solving Contest????
I bet Al Gor's people are behind this contest
Security lab posted first 100 lines of ipv6_discovery_test.c and ipv6_tcp.c. Aside from a somewhat clumsy type names, the code is clean.
That'll use up their toner :)
Yeah, that's assuming there is a toner to use up.
Ie it's not the pentium box with a fax-modem and huge harddrive on other end as every normal computer telephony company would have.
Alan Turing is mysteriously missing from the list as well.
The trend among content-filtering firewalls is to filter SSL sessions by splitting them in two - one from the client to the firewall and another from the firewall to the server. If the session cannot be split, it's rejected.
Eventhough it's client-friendly man-in-the-middle attack, which defeats the whole purpose of SSL, there is a demand for this functionality.
--
The way it works is the client installs extra root CA certificate, and the firewall is given its own CA-enabled certificate derived from the former. Whenever it sees SSL connection coming from the client, it accepts its on behalf of the server, handshakes with the server, then replicates server's certificate signing with its own key and proceeds handshaking with the client. And the client accepts this forged peer's certificate, because it traces back to 'trusted' firewall CA. Pure magic.
You'd be surprised to learn that average (antivirus) file scanner is capable of unwrapping and checking tar/gz/rar/ace/.. files up to ten levels deep. Some most advnaced ones do that in a pass-through mode, ie without buffering entire file. And only most primitive scanners rely on file extension when it comes to determining file content.
.mp3 4 times and then rar'ing it will not help. Renaming resulting archive back into .mp3 will help even less.
In other words zipping
As others pointed out, trusted p2p networks is a next logical evolution step. If properly implemented, it should last a while.
Search feature sounds pretty much like what M2 client has:
Search your M2 e-mails for almost anything. A search "sticks" and becomes an access point, so that you can easily refer to it in the future.
I realize that M2 is not free and not web-based, but still it makes Gmail's searching much less of a novelty than someone
The point is that GMail is unique due to the combination of features it has to offer, which among other things include kick-ass UI, search and storage space.
There is RFC 2385 titled Protection of BGP Sessions via the TCP MD5 Signature Option. In the first paragraph of its Introduction section it says -
The primary motivation for this option is to allow BGP to protect itself against the introduction of spoofed TCP segments into the connection stream. Of particular concern are TCP resets.
The date of publishing - August 1998, which makes it about 6 years old.
However the proposed option was primarily meant as a quick BGP fixup, which should've got depricated as soon as IPsec got RFC'ed and deployed. It did went standard few months later, but IPsec implementations enjoyed full share of cross-vendor compatibility problems.
With time Authenticated Header (AH) IPsec protocol didn't see much use or acceptance and IPsec slowly evolved (and keeps evolving) into confidentiality rather than authentication layer.
Besides it's an IP security after all, while the RST spoofing is a TCP problem. And one can quite rightfully percieve authenticating TCP with IPsec as an overkill.
Anyhow, long story short - it's a known and rather old problem with handful of existing and equally unattractive solutions. Perhaps this time around it will be addressed better due to the amount of the publicity it's aimed to get.
who cares as long as the costume is made from 100% natural jar-jar skin ;)
You are assumed to have a cell phone. Phone's location can be triangulated with a precision of up to a meter or so.
Cell company providing this information back to the owner of the phone _most likely_ will not break any privacy laws of whatever the country is, so it should be rather trivial for them to provide the service if there's a demand. They already geo-position 911 calls, so the technology is there.
8K ? Pfft .. My old trusty Casio GFX calculator had a space of 422 bytes for holding scripts ! And I still managed to make it draw a rotating 3D cube.
... when you run untrusted binaries.
ps. Seriously, I really doubt Soviets would've not audited the source code had they have it at hand.
KAME project comes to mind, and its IKE key manager racoon in particular. It may not be the most up-to-date IKE implementation, but it's certainly one of the cleanest and well-designed ones compared to other major OpenSource IPsec projects.
Both habeas and bonded-sender are the stupidiest antispam ideas only beaten by this marvel. How can one expect spammers in non-US countries to abide US copyright rules is beyond me .. especially given that a half of the spam is sent from spoofed emails using hijacked machines or through open relays.
I poked around similar idea few months ago. The only difference is that instead of port knocking I used ping knocking, which used varying sizes of ICMP pings as an opening sequence. It worked really well, plus unlike TCP/UDP knocking it was simplier to use and had less problems with restrictive firewalls and traffic scanners -
:)
ping x.x.x.x -c 1 -s 233
ping x.x.x.x -c 1 -s 122
ping x.x.x.x -c 1 -s 627
ssh x.x.x.x
Required couple of hours of netfilter hacking, but that's a fair price for an obfuscated port-scan protection.
If you are assuming that knocking sequence is static, then - yeah, it's prone to sniffing and I agree with you on all items you listed. You also assume that the knock is equivalent to the password in canonical authentication scheme, ie there's no username and it's the same for everyone.
However it is trivial to extend the knock to include an analog of a username and to make the password portion dependent on it. Say, first 4 ports knocked comprise user ID, and next 4 make up an authentication part.
This clearly enables all existing one-way authentication schemes ranging from simple one-time/discardable passwords to those based on hardware tokens.
I think the idea certainly has a potential, but it's hardly suitable for open solutions in its present form.