Are you saying that no one paid for an assassination in BTC, or that no one who paid for an assassination in BTC got their money's worth?
Allegedly somebody did attempt it twice and got cheated both times by different people. As far as I recall the first time he was cheated by some gang of criminals and the second time he was cheated by FBI.
if BTC-denominated savings accounts ("eurobitcoins"), BTC futures, and BTC-denominated insurance policies come into play, the supply will be quite uncontrolled.
What that will make uncontrolled is promises about giving out bitcoins subject to some criteria. The actual bitcoins themselves will still be limited. The question then is, at what point people will realize that a bitcoin is worth more than a promise by somebody to give you a bitcoin.
What does it matter that Overstock is immediately converting bitcoins to USD?
Whether it is even a good idea for them to convert those bitcoin to USD is an open question. If they convert them immediately and end up with less USD than if they had received payment in USD in the first place, that just makes it a complicated (read expensive) scheme for giving some customers a discount. That is probably not a good strategy.
If they hold onto the bitcoins they receive, then that will put a cap on how much they could possibly sell through that method. That cap would also put a cap on how much they could lose on their bitcoin adventure. Additionally, doing so would take some bitcoins out of circulation. Taking bitcoins out of circulation while simultaneously providing value to the coin by providing goods you can buy with it, could potentially push the price of bitcoin upwards. If that happens they could slowly start selling some of those bitcoins at a profit.
A strategy that puts a cap on your possible losses while opening an opportunity for additional profit sounds like a good plan. But of course there are no guarantees, losses are losses, even if there is a cap on them.
I'll accept BTC as a real currency once we start seeing credible numbers that people are actually using it to buy stuff besides alpaca socks, web services, drugs and assassinations.
I don't think anybody successfully bought an assassination paid with bitcoin.
As child porn wouldn't effect the customers bottom line.
Is that the worst you can say about that analogy? How about this:
The actions of one person doesn't say anything about the company as a whole. Even if it is the CEO. If the CEO had indeed been involved in child pornography, the response from the company and its employees says more about the company, than the actions of the CEO.
But what is even more disturbing is coming up with involvement in child pornography as the worst a person can possibly do. How about murder? In my book that is worse than involvement in child pornography.
The analogy to child pornography sounds most of all like a sensationalistic statement aimed at getting attention. If you have a good point, you can get it across without resorting to such bad analogies.
Kind of hard to build a case on hearsay. Prove they received 10M, and they will be sued into nothingness. But this is "he said she said" - ain't worth shit.
Even if it can be proven that they received 10M$ and that they knowingly introduced the backdoor, it is hard to prove that the money was payment for introducing the backdoor. However, it might be sufficient to prove, that they knowingly introduced the backdoor. What payment they received for it, shouldn't affect the outcome of the case, because it is not the payment, which is hurting the customers, it is the backdoor.
Can we prove that RSA knew about the backdoor? Maybe not, but most likely it can be proven that given the knowledge RSA had, RSA should have assessed the algorithm to be most likely backdoored, at the time where they introduced it.
In cryptography it is generally accepted best practice, that any constant whose value isn't justified in some way, should be assumed to be a backdoor until proven otherwise. That is a principle, which RSA knows about. Additionally it has been public knowledge for many years that DECDRBG was relying on a constant whose value was not justified, moreover it had been formally proven, that there was a way to hide backdoor in that constant. It's like finding a smoking gun and saying we can't be sure anybody fired that gun, it could be smoking for so many other reasons.
The fact that DECDRBG uses asymmetrical primitives for a task, which is usually done with symmetrical primitives, is in itself suspect. Symmetrical primitives are usually faster, and there is a wide range of attack techniques that could be applied on asymmetrical primitives but not on symmetrical primitives. Good reasons for asymmetrical primitives is when you are working on a task, which cannot be done symmetrically. In the case of DECDRBG the introduction of a backdoor could not have been done symmetrically.
For added security, split the key into multiple parts and give it to multiple parties.
And to guard against losing the key in case one party is unavailable, you can make use of Shamir's Secret Sharing. For example you could share the key in 10 parts of which any 7 can be used to reconstruct the original key, but given only 6 parts they would be completely random with no connection to the key.
I don't trust tagged VLAN's enough to leave the tagged port open to the world, so I always keep the unsanitized public internet traffic on a separate port.
It really comes down to whether you can trust your switch. Configure the switch such that the port you connect to the outside world only has access to the one VLAN, it is supposed to have access to. The job you are trusting the switch to do is a lot simpler than what you are trusting your router to do, so there isn't much of an attack surface.
If the switch does not have the necessary configuration options to do what I described, then it is obviously not suitable for a setup as the one I described. It may still be a great switch, which could serve the inside or the outside of your router, just not both at the same time. At that point it comes down to cost, the cost of an extra port on the router may cost less than the additional cost needed to get a switch with sufficient VLAN capabilities.
If your switch does have a VLAN configuration, but you still don't trust it, that can only mean you think the switch vendor has given security so little thought, that they managed to introduce worse security holes than in the router, in spite of the switch needing to do a simpler job than the router. It is of course possible, that the switch vendor did a poor job at security. For example if the configuration interface on the switch is accessible through any port, even if that port is restricted to your external VLAN, then it shouldn't be trusted security wise. However I wouldn't expect switch vendors to do such a bad job at security.
You really only need 2 ports for a basic router. If you need more, you can use tagged VLAN's.
In that case you could do with just one port on the router. Of course with only one port you only get half the bandwidth of two ports. But if you have 1Gbit/s between router and switch chip, I doubt that is going to be a bottleneck for many private usages. The port you saved on the router of course means you'll have to use one of the ports on the switch chip for WAN instead. So you gotta ask if the extra port on the router is worth the cost compared to an extra port on the switch chip. (I know switch ports don't come in increments of one, so really the question is, did you need that last port on the switch chip?)
If you happen to base your setup on a router with a SoC that has two 1Gbit/s interfaces from the start, then you may as well put both of them to good use. One possibility, that costs a little bit extra is to just connect both of them to the switch and choose a switch with 4 more ports, than you would otherwise have done. Then you get lots of flexibility. You can configure the two connections independently on different VLANs, or you can bundle them and use tagging to have perhaps three or even more VLANs where the 2Gbit/s of bandwidth can be used for whatever VLAN currently need that sort of throughput to the router.
But if you already have a managed switch with VLAN tagging support, it might not cost much extra for a switch with a chip that can also do routing. Routing is not much more complicated than switching. It is almost as simple as just matching the destination IP against a CAM instead of matching the destination MAC against a CAM. That is something which has been implemented in hardware before. I think you can buy a complete switch with that sort of support for under 200$. Whether you can get one, where you can tinker with it as well, I don't know.
That sort of routing hardware doesn't do NAT though. So it is plausible you might run into hardware where you can get 1Gbit/s as long as you don't do NAT, but as soon as you do NAT, throughput drops to half or less.
Had the released documents only reveled domestic spying, then the NSA might have looked even worse in the eyes of Americans, but the USA might not have looked as bad to the rest of the world. It would have been a misleading image of the USA though.
It may have been illegal according to current American law for Snowden to reveal, that USA is treating every other country in the world as an enemy. But you have got to ask if it really is Snowden, who is wrong here. It could be that it is Snowden who is right, and on the other side, we have the law, the NSA, and the government who are all wrong.
I'd say it is up to the population of the USA to decide whose side they want to be on.
If the population of the USA thinks it is OK that NSA is spying on all other countries as if they were an enemy of USA, then the population should make this point very clear. In that case Snowden should never go back to the USA, but there will surely be countries of another opinion, in which Snowden can live as a free man.
If OTOH the population of the USA thinks that the NSA has gone too far, then they should also make this point very clear. If it is only the small elite in power, who consider the spying to be OK, then the population need to replace them with somebody who acts in the interest of the population. In this case it is of little importance, if the NSA acted within the law, the law need to be updated to make it absolutely clear, that this is no longer legal. And Snowden's actions should retroactively be made legal.
I don't know what the majority of the population of USA thinks about that question, but I think the world deserves to know. Does the population of USA think it is OK for USA to be spying on every other country?
Maybe they are out there, but are being VERY careful about contaminating the timeline...
A new technology being invented and not a single person doing something incredibly stupid with it? That does not sound plausible to me. The much more plausible explanation is that it is just not physically possible to use a time machine to travel to a point in time before the creation of said time machine. So if a time machine is build in 2015, then somebody from the year 2020 can travel back to 2015, but they cannot travel back to 2014.
That idea is of course entirely hypothetical. There is no way the first generation of time machines will actually be of a quality, that will last for 5 years. It will go like any other technology as it matures the the products will last longer and longer. But eventually the manufacturers will realize that building them too durable will undermine future markets. And then they will start building them such that they last just a standard-deviation or two past the warranty period.
We all know what will happen once people realize, that they just don't build time machines like that anymore. There will be an incredible traffic of people travelling back to the year 2030 or so, where the most durable time machines were build, just so they can pick up a quality time machine.
The oldest version of oui.txt I could find is dated 2010. And the allocation was made before that. Which means it has been more than three years since this was news. Anybody know how to look up more precisely, when it was allocated?
It's scheduled for widespread deployment some time between the domestic service rollout of IPv6 and the year of linux on the desktop.
Some of the IPv6 transition mechanisms are incompatible with DNSSEC. Because of the potential problems caused by that, I think it is a good idea to focus on IPv6 deployment now and start focusing on DNSSEC once you have gotten so far with IPv6 deployment, that you have resources to spare.
Additionally IPv6 can improve the security of DNS lookups, even if you are not using DNSSEC. Simply allocate an entire/64 for recursive resolvers and use a random client IP address when sending queries to authoritative servers. With that one trick you have more than doubled the amount of entropy in the request and thus made cache poisoning much harder. (DNSSEC is of course still relevant because it protects against other classes of attacks as well.)
Finally, I think DNSSEC is not entirely ready for deployment yet. I think DNSSEC need a challenge-response protocol, that can be used as counter measure against amplification attacks. For me that is just another reason to put off DNSSEC deployment a little bit longer.
Considering that IPv6 deployment is at a level that should have been reached 13 years ago, I think moving ahead with IPv6 is more urgent than deploying DNSSEC.
Even though the physical DNS servers are "anycast" and geographically diverse, the IP addresses are still the same. Threrefore, the large content delivery networks (CDNs) like Akamai and LimeLight still use the IP address of the DNS server to judge your location.
Let's get this misunderstanding sorted out. Because that sentence is indeed describing a non-existent problem. In reality anycast DNS is not part of the problem, it is part of the solution.
Anycast DNS works by having a large number of resolvers spread throughout the world with the same IP address on each of them. A request from a client to this IP will reach the closest of those resolvers. What happens next is that the resolver will query authoritative servers (unless it already has a cached result). If the request from the resolver to the authoritative server was send using the anycast IP as source IP, it would not work. The reason it would not work is, that the reply from the authoritative server would be sent to the closest resolver, which is not necessarily the same as the one, which is closest to the client. You'd have most replies end up at the wrong resolver, which would simply discard it, as it would look like a failed poisoning attempt.
In order to solve that problem you have to give each of those resolvers two IP addresses. It will have the anycast IP address (which is the same on all servers in the pool) and a unicast IP address, which is different on each of those resolvers. The client will still use the anycast IP in order to send a query to the resolver, but the resolver will then use its unicast IP when sending the request to the authoritative server. That way the reply from the authoritative server will make it back to the correct resolver.
Incidentally this also solves the geolocation problem mentioned. The authoritative servers will indeed see different IP addresses depending on which resolver in the pool the request came through. The content providers just have to figure out the geographic location of each of those resolvers, which is mostly the same they have to do for the resolvers for any ISP. Additionally providers of resolvers such as Google do have an incentive to make this easy to figure out, since that will make their resolvers provide a faster overall experience.
The above is of course slightly simplified, because any well operated resolver is dual stack. That means it need both IPv4 and IPv6 addresses. The anycast addresses can be separate pools such that each resolver has only one anycast address, which is either IPv4 or IPv6. Alternatively you can let one resolver be part of one IPv4 anycast pool and of one IPv6 anycast pool. However the unicast side of these resolvers need to be dual stack, so each resolver needs at least two unicast addresses, one IPv4 and one IPv6.
You could even assign multiple unicast addresses to each resolver. The extra addresses could be used to provide additional protection against poisoning. An attack would then have to not only guess a request ID and port number, but also the IP address. Alas that is really not feasible with IPv4 due to shortage of addresses, but for IPv6 you could easily affort a/64 for each resolver.
If you want to know the IPv6 unicast address of the resolver you are currently using, I have a special domain for that. If you look up the AAAA record for the domain mydnsv6.kasperd.net, it will actually respond with the IPv6 unicast address of the resolver you are using (or server error if the resolver has no IPv6 address). I could have made an identical service to find the IPv4 unicast address of the resolver, but I didn't have a spare IPv4 address to host the authoritative server on.
If you replace a hardware router with a PC, you have to trust
CPU
Motherboard
BIOS
Storage device
Storage controller
Network interface
Operating system
If any of the above is compromised, you are no better off than with a hardware based router.
If you by hardware router mean a device that truly forwards packets in hardware without involving any sort of CPU, then your best guarantee is the economical one. It is cheaper for the vendor to manufacture hardware without snooping capabilities than with.
Aren't those the type-of calling of sizeof and therefore needs parenthesis?
To me even asking that question is indication, that you should include parenthesis. If the author or any of the readers are unsure if parenthesis is required or not, it is better to use parenthesis more often than strictly required. In other words, you can omit the parenthesis only if you know for sure, it will work and that everybody who will read it, also understand the rules.
Of course not. After all, most cipher modes sent the IV directly on the wire. However it is only sent once the data has been encrypted. If the adversary knew the IV before you encrypted the data, the adversary could influence the content of the data based on her knowledge about the IV, and break the encryption that way. If you are using a cipher mode, which requires the IV to be random, then you must choose a random IV after the data to be encrypted has been set in stone, and no sooner than that. SSL was broken due to encrypting data in CBC mode, where the data was not yet known, when the IV was chosen.
As long as keys are never re-used it doesn't matter if the IV is predictable or not.
That depends a lot on the mode. CBC mode is vulnerable to plenty of attacks, if the IV is predictable. And what predictability means in this context has taken some people by surprise. If the end of the stream of data is not set in stone once you start encrypting, does that mean the IV is predictable? The way CBC has been used in SSL did have a weakness because of that. The cipher blocks sent across the network are used as IV for successive blocks. But once you have sent a cipher block, it is no longer unpredictable. And if the adversary can influence the next data block once he has seen the previous cipher block, CBC can be exploited.
This is the same tradeoff as when using block ciphers in counter mode.
It is true that counter mode is one of those modes, that do not require unpredictable IVs. In fact you can just use a counter to generate your IV. But if you do not choose IVs carefully, counter mode is one of the weakest modes, you can choose. If you ever reuse an IV, you have effectively reduced the encryption to a multi-time pad. CBC mode with a constant IV would be more secure than that.
The thing is, that counter mode is actually a stream cipher, which operates by generating a stream of bits, which is XORed with the message. All ciphers constructed in this way are vulnerable, if the IV is reused. That is exactly the problem with WEP.
I have seen at least one published article recommending the use of counter mode for storage encryption. It did not explicitly say you should use the sector number as IV, but it was hinting, that's what you were expected to do. Additionally using sector number as IV has been common practice in storage encryptions. Any storage encryption following that practice would be broken if an adversary was able to get the data which has existed at one logical sector number at two different points in time. Ways that could happen includes:
Wear levelling on a flash/SSD medium.
Remapped sectors on a harddrive.
Access to earlier versions due to slight difference in alignment of write head.
Encrypted data stored on an untrusted host or accessed over an untrusted communication path.
Adversary with physical access to copy the encrypted media more than once.
There is absolutely no reason that I'm aware of not to think the certificate authorities weren't compromised from the very beginning.
Even if you had compromised a CA, there would be a huge risk of being exposed the very first time you abused it. You have to send a legitimate certificate to the site owner, otherwise they would not be able to setup their https site in the first place. However a CA cannot abuse the legitimate certificate because they don't know the corresponding secret key. So in order to do any abuse, you have to forge another certificate.
Now there are two certificates each of which is definitely visible to a small set of legitimate users. If certificate pinning was widespread, then that would be enough to guarantee exposure. We just need a standard for chaining the legitimate certificates over time, such that certificate pinning can work well when the legitimate certificate is replaced with a new legitimate certificate before the old has expired. Ideally it would be designed in a way, that does not require cooperation from the CAs, because they might be afraid of losing control, if such a chaining was readily available.
It is useful and important to focus on as strong security against passive attacks as possible, even if it doesn't improve security against active attacks. Strong security against passive attacks will mean active attacks are needed in more cases, and it also means it is hard to make those active attacks well targeted. And systematic active attacks is both difficult to pull off and also easily detected. Additionally widespread deployment of cryptography, which is only resilient to passive attacks is easier, since it does not rely on key distribution.
It is just important to ensure that you still do use methods secured against active attacks, when the extra security is really needed. Additionally protocols must be designed such that an active attack is required to find out if a connection was protected against them. If you can passively tell if a connection is secured against active attacks, then passive security is practically worthless.
What reasons are there to cause one to want to generate a new key instead of reusing the old one?
For the same reasons that you would rotate passwords. It is just a precaution in case it accidentally was leaked. When changing certificate anyway there is no inconvenience to the users from replacing the key, so you might as well replace it. It would for example help a bit in case an old backup of the webserver had been leaked. The difference in security is minor though, there are much greater threats from insecure CAs.
Certificates have an expiry date. They are supposed to be changed before the expiry date is reached. On a well managed system, you'll never see a certificate which has less than a week left of its validity period. Once the certificates are changed, it should be considered best practice to rotate the server key as well, so the new certificate will always be signing a different key from the previous certificate.
It would be nice to have more information to verify the correctness of the new certificate than just the existing CA certificate chain. I would like to see a small extension to SSL where the server can tell the client that any new certificate will be signed using the current certificate. When the client is told that, it can cache the current certificate and warn the user if it sees a new certificate lacking a chain from the old to the new certificate.
I've also seen Skype work when it shouldn't - behind corporate firewalls that are supposed to be blocking traffic.
When parties on both sides of a firewall are cooperating in getting data through the firewall, there is little you can do to stop them. The solution is to limit what software gets to run on the trusted side of the firewall. If you don't want Skype on your network, then don't install it. Some corporations do use Skype as part of their work. Those corporations are happy that Skype is so easy to get working through their firewall.
The point where it gets difficult to get data through is when there are two firewalls in play, and each of them blocks traffic in opposite directions. The only reason any communication is possible at all in such a scenario is, that somebody between the two firewalls is cooperating with the parties, which want to communicate.
Up to a month ago such a comment would've been modded to -1 because historically, NSA had helped improve the security of encryption standards.
Schneier has been speculating about the possibility of an NSA planted backdoor in Dual_EC_DRBG since 2007. Which by the way took me a few attempts to find again since there are many hits if you search for NSA backdoor on his site.
As Schneier has said, the revelations about recent NSA activity has completely evaporated the goodwill NSA earned in the cryptographic community from back then.
Goodwill might be an exaggeration. Learning that NSA had improved security of DES did reduce the distrust in NSA, but it did not eliminate it. The first evidence of the Dual_EC_DRBG probably brought that distrust back to the previous level. By now I guess the trust in NSA is at an absolute low. (If it got any lower you would start trusting anything from the NSA not to be trustworthy.)
Slashdot Mirror
No need to look for another universe. Moving to another country would be sufficient.
Allegedly somebody did attempt it twice and got cheated both times by different people. As far as I recall the first time he was cheated by some gang of criminals and the second time he was cheated by FBI.
What that will make uncontrolled is promises about giving out bitcoins subject to some criteria. The actual bitcoins themselves will still be limited. The question then is, at what point people will realize that a bitcoin is worth more than a promise by somebody to give you a bitcoin.
Whether it is even a good idea for them to convert those bitcoin to USD is an open question. If they convert them immediately and end up with less USD than if they had received payment in USD in the first place, that just makes it a complicated (read expensive) scheme for giving some customers a discount. That is probably not a good strategy.
If they hold onto the bitcoins they receive, then that will put a cap on how much they could possibly sell through that method. That cap would also put a cap on how much they could lose on their bitcoin adventure. Additionally, doing so would take some bitcoins out of circulation. Taking bitcoins out of circulation while simultaneously providing value to the coin by providing goods you can buy with it, could potentially push the price of bitcoin upwards. If that happens they could slowly start selling some of those bitcoins at a profit.
A strategy that puts a cap on your possible losses while opening an opportunity for additional profit sounds like a good plan. But of course there are no guarantees, losses are losses, even if there is a cap on them.
I don't think anybody successfully bought an assassination paid with bitcoin.
Is that the worst you can say about that analogy? How about this:
The actions of one person doesn't say anything about the company as a whole. Even if it is the CEO. If the CEO had indeed been involved in child pornography, the response from the company and its employees says more about the company, than the actions of the CEO.
But what is even more disturbing is coming up with involvement in child pornography as the worst a person can possibly do. How about murder? In my book that is worse than involvement in child pornography.
The analogy to child pornography sounds most of all like a sensationalistic statement aimed at getting attention. If you have a good point, you can get it across without resorting to such bad analogies.
Even if it can be proven that they received 10M$ and that they knowingly introduced the backdoor, it is hard to prove that the money was payment for introducing the backdoor. However, it might be sufficient to prove, that they knowingly introduced the backdoor. What payment they received for it, shouldn't affect the outcome of the case, because it is not the payment, which is hurting the customers, it is the backdoor.
Can we prove that RSA knew about the backdoor? Maybe not, but most likely it can be proven that given the knowledge RSA had, RSA should have assessed the algorithm to be most likely backdoored, at the time where they introduced it.
In cryptography it is generally accepted best practice, that any constant whose value isn't justified in some way, should be assumed to be a backdoor until proven otherwise. That is a principle, which RSA knows about. Additionally it has been public knowledge for many years that DECDRBG was relying on a constant whose value was not justified, moreover it had been formally proven, that there was a way to hide backdoor in that constant. It's like finding a smoking gun and saying we can't be sure anybody fired that gun, it could be smoking for so many other reasons.
The fact that DECDRBG uses asymmetrical primitives for a task, which is usually done with symmetrical primitives, is in itself suspect. Symmetrical primitives are usually faster, and there is a wide range of attack techniques that could be applied on asymmetrical primitives but not on symmetrical primitives. Good reasons for asymmetrical primitives is when you are working on a task, which cannot be done symmetrically. In the case of DECDRBG the introduction of a backdoor could not have been done symmetrically.
And to guard against losing the key in case one party is unavailable, you can make use of Shamir's Secret Sharing. For example you could share the key in 10 parts of which any 7 can be used to reconstruct the original key, but given only 6 parts they would be completely random with no connection to the key.
It really comes down to whether you can trust your switch. Configure the switch such that the port you connect to the outside world only has access to the one VLAN, it is supposed to have access to. The job you are trusting the switch to do is a lot simpler than what you are trusting your router to do, so there isn't much of an attack surface.
If the switch does not have the necessary configuration options to do what I described, then it is obviously not suitable for a setup as the one I described. It may still be a great switch, which could serve the inside or the outside of your router, just not both at the same time. At that point it comes down to cost, the cost of an extra port on the router may cost less than the additional cost needed to get a switch with sufficient VLAN capabilities.
If your switch does have a VLAN configuration, but you still don't trust it, that can only mean you think the switch vendor has given security so little thought, that they managed to introduce worse security holes than in the router, in spite of the switch needing to do a simpler job than the router. It is of course possible, that the switch vendor did a poor job at security. For example if the configuration interface on the switch is accessible through any port, even if that port is restricted to your external VLAN, then it shouldn't be trusted security wise. However I wouldn't expect switch vendors to do such a bad job at security.
In that case you could do with just one port on the router. Of course with only one port you only get half the bandwidth of two ports. But if you have 1Gbit/s between router and switch chip, I doubt that is going to be a bottleneck for many private usages. The port you saved on the router of course means you'll have to use one of the ports on the switch chip for WAN instead. So you gotta ask if the extra port on the router is worth the cost compared to an extra port on the switch chip. (I know switch ports don't come in increments of one, so really the question is, did you need that last port on the switch chip?)
If you happen to base your setup on a router with a SoC that has two 1Gbit/s interfaces from the start, then you may as well put both of them to good use. One possibility, that costs a little bit extra is to just connect both of them to the switch and choose a switch with 4 more ports, than you would otherwise have done. Then you get lots of flexibility. You can configure the two connections independently on different VLANs, or you can bundle them and use tagging to have perhaps three or even more VLANs where the 2Gbit/s of bandwidth can be used for whatever VLAN currently need that sort of throughput to the router.
But if you already have a managed switch with VLAN tagging support, it might not cost much extra for a switch with a chip that can also do routing. Routing is not much more complicated than switching. It is almost as simple as just matching the destination IP against a CAM instead of matching the destination MAC against a CAM. That is something which has been implemented in hardware before. I think you can buy a complete switch with that sort of support for under 200$. Whether you can get one, where you can tinker with it as well, I don't know.
That sort of routing hardware doesn't do NAT though. So it is plausible you might run into hardware where you can get 1Gbit/s as long as you don't do NAT, but as soon as you do NAT, throughput drops to half or less.
Had the released documents only reveled domestic spying, then the NSA might have looked even worse in the eyes of Americans, but the USA might not have looked as bad to the rest of the world. It would have been a misleading image of the USA though.
It may have been illegal according to current American law for Snowden to reveal, that USA is treating every other country in the world as an enemy. But you have got to ask if it really is Snowden, who is wrong here. It could be that it is Snowden who is right, and on the other side, we have the law, the NSA, and the government who are all wrong.
I'd say it is up to the population of the USA to decide whose side they want to be on.
If the population of the USA thinks it is OK that NSA is spying on all other countries as if they were an enemy of USA, then the population should make this point very clear. In that case Snowden should never go back to the USA, but there will surely be countries of another opinion, in which Snowden can live as a free man.
If OTOH the population of the USA thinks that the NSA has gone too far, then they should also make this point very clear. If it is only the small elite in power, who consider the spying to be OK, then the population need to replace them with somebody who acts in the interest of the population. In this case it is of little importance, if the NSA acted within the law, the law need to be updated to make it absolutely clear, that this is no longer legal. And Snowden's actions should retroactively be made legal.
I don't know what the majority of the population of USA thinks about that question, but I think the world deserves to know. Does the population of USA think it is OK for USA to be spying on every other country?
A new technology being invented and not a single person doing something incredibly stupid with it? That does not sound plausible to me. The much more plausible explanation is that it is just not physically possible to use a time machine to travel to a point in time before the creation of said time machine. So if a time machine is build in 2015, then somebody from the year 2020 can travel back to 2015, but they cannot travel back to 2014.
That idea is of course entirely hypothetical. There is no way the first generation of time machines will actually be of a quality, that will last for 5 years. It will go like any other technology as it matures the the products will last longer and longer. But eventually the manufacturers will realize that building them too durable will undermine future markets. And then they will start building them such that they last just a standard-deviation or two past the warranty period.
We all know what will happen once people realize, that they just don't build time machines like that anymore. There will be an incredible traffic of people travelling back to the year 2030 or so, where the most durable time machines were build, just so they can pick up a quality time machine.
Turns out the URL has changed over time. Knowing what the URL used to be allows looking up earlier versions.
The allocation was made between 2010 Aug 08 and 2010 Nov 24.
The oldest version of oui.txt I could find is dated 2010. And the allocation was made before that. Which means it has been more than three years since this was news. Anybody know how to look up more precisely, when it was allocated?
It's scheduled for widespread deployment some time between the domestic service rollout of IPv6 and the year of linux on the desktop.
Some of the IPv6 transition mechanisms are incompatible with DNSSEC. Because of the potential problems caused by that, I think it is a good idea to focus on IPv6 deployment now and start focusing on DNSSEC once you have gotten so far with IPv6 deployment, that you have resources to spare.
/64 for recursive resolvers and use a random client IP address when sending queries to authoritative servers. With that one trick you have more than doubled the amount of entropy in the request and thus made cache poisoning much harder. (DNSSEC is of course still relevant because it protects against other classes of attacks as well.)
Additionally IPv6 can improve the security of DNS lookups, even if you are not using DNSSEC. Simply allocate an entire
Finally, I think DNSSEC is not entirely ready for deployment yet. I think DNSSEC need a challenge-response protocol, that can be used as counter measure against amplification attacks. For me that is just another reason to put off DNSSEC deployment a little bit longer.
Considering that IPv6 deployment is at a level that should have been reached 13 years ago, I think moving ahead with IPv6 is more urgent than deploying DNSSEC.
Let's get this misunderstanding sorted out. Because that sentence is indeed describing a non-existent problem. In reality anycast DNS is not part of the problem, it is part of the solution.
/64 for each resolver.
Anycast DNS works by having a large number of resolvers spread throughout the world with the same IP address on each of them. A request from a client to this IP will reach the closest of those resolvers. What happens next is that the resolver will query authoritative servers (unless it already has a cached result). If the request from the resolver to the authoritative server was send using the anycast IP as source IP, it would not work. The reason it would not work is, that the reply from the authoritative server would be sent to the closest resolver, which is not necessarily the same as the one, which is closest to the client. You'd have most replies end up at the wrong resolver, which would simply discard it, as it would look like a failed poisoning attempt.
In order to solve that problem you have to give each of those resolvers two IP addresses. It will have the anycast IP address (which is the same on all servers in the pool) and a unicast IP address, which is different on each of those resolvers. The client will still use the anycast IP in order to send a query to the resolver, but the resolver will then use its unicast IP when sending the request to the authoritative server. That way the reply from the authoritative server will make it back to the correct resolver.
Incidentally this also solves the geolocation problem mentioned. The authoritative servers will indeed see different IP addresses depending on which resolver in the pool the request came through. The content providers just have to figure out the geographic location of each of those resolvers, which is mostly the same they have to do for the resolvers for any ISP. Additionally providers of resolvers such as Google do have an incentive to make this easy to figure out, since that will make their resolvers provide a faster overall experience.
The above is of course slightly simplified, because any well operated resolver is dual stack. That means it need both IPv4 and IPv6 addresses. The anycast addresses can be separate pools such that each resolver has only one anycast address, which is either IPv4 or IPv6. Alternatively you can let one resolver be part of one IPv4 anycast pool and of one IPv6 anycast pool. However the unicast side of these resolvers need to be dual stack, so each resolver needs at least two unicast addresses, one IPv4 and one IPv6.
You could even assign multiple unicast addresses to each resolver. The extra addresses could be used to provide additional protection against poisoning. An attack would then have to not only guess a request ID and port number, but also the IP address. Alas that is really not feasible with IPv4 due to shortage of addresses, but for IPv6 you could easily affort a
If you want to know the IPv6 unicast address of the resolver you are currently using, I have a special domain for that. If you look up the AAAA record for the domain mydnsv6.kasperd.net, it will actually respond with the IPv6 unicast address of the resolver you are using (or server error if the resolver has no IPv6 address). I could have made an identical service to find the IPv4 unicast address of the resolver, but I didn't have a spare IPv4 address to host the authoritative server on.
If any of the above is compromised, you are no better off than with a hardware based router.
If you by hardware router mean a device that truly forwards packets in hardware without involving any sort of CPU, then your best guarantee is the economical one. It is cheaper for the vendor to manufacture hardware without snooping capabilities than with.
To me even asking that question is indication, that you should include parenthesis. If the author or any of the readers are unsure if parenthesis is required or not, it is better to use parenthesis more often than strictly required. In other words, you can omit the parenthesis only if you know for sure, it will work and that everybody who will read it, also understand the rules.
Of course not. After all, most cipher modes sent the IV directly on the wire. However it is only sent once the data has been encrypted. If the adversary knew the IV before you encrypted the data, the adversary could influence the content of the data based on her knowledge about the IV, and break the encryption that way. If you are using a cipher mode, which requires the IV to be random, then you must choose a random IV after the data to be encrypted has been set in stone, and no sooner than that. SSL was broken due to encrypting data in CBC mode, where the data was not yet known, when the IV was chosen.
That depends a lot on the mode. CBC mode is vulnerable to plenty of attacks, if the IV is predictable. And what predictability means in this context has taken some people by surprise. If the end of the stream of data is not set in stone once you start encrypting, does that mean the IV is predictable? The way CBC has been used in SSL did have a weakness because of that. The cipher blocks sent across the network are used as IV for successive blocks. But once you have sent a cipher block, it is no longer unpredictable. And if the adversary can influence the next data block once he has seen the previous cipher block, CBC can be exploited.
It is true that counter mode is one of those modes, that do not require unpredictable IVs. In fact you can just use a counter to generate your IV. But if you do not choose IVs carefully, counter mode is one of the weakest modes, you can choose. If you ever reuse an IV, you have effectively reduced the encryption to a multi-time pad. CBC mode with a constant IV would be more secure than that.
The thing is, that counter mode is actually a stream cipher, which operates by generating a stream of bits, which is XORed with the message. All ciphers constructed in this way are vulnerable, if the IV is reused. That is exactly the problem with WEP.
I have seen at least one published article recommending the use of counter mode for storage encryption. It did not explicitly say you should use the sector number as IV, but it was hinting, that's what you were expected to do. Additionally using sector number as IV has been common practice in storage encryptions. Any storage encryption following that practice would be broken if an adversary was able to get the data which has existed at one logical sector number at two different points in time. Ways that could happen includes:
Even if you had compromised a CA, there would be a huge risk of being exposed the very first time you abused it. You have to send a legitimate certificate to the site owner, otherwise they would not be able to setup their https site in the first place. However a CA cannot abuse the legitimate certificate because they don't know the corresponding secret key. So in order to do any abuse, you have to forge another certificate.
Now there are two certificates each of which is definitely visible to a small set of legitimate users. If certificate pinning was widespread, then that would be enough to guarantee exposure. We just need a standard for chaining the legitimate certificates over time, such that certificate pinning can work well when the legitimate certificate is replaced with a new legitimate certificate before the old has expired. Ideally it would be designed in a way, that does not require cooperation from the CAs, because they might be afraid of losing control, if such a chaining was readily available.
It is useful and important to focus on as strong security against passive attacks as possible, even if it doesn't improve security against active attacks. Strong security against passive attacks will mean active attacks are needed in more cases, and it also means it is hard to make those active attacks well targeted. And systematic active attacks is both difficult to pull off and also easily detected. Additionally widespread deployment of cryptography, which is only resilient to passive attacks is easier, since it does not rely on key distribution.
It is just important to ensure that you still do use methods secured against active attacks, when the extra security is really needed. Additionally protocols must be designed such that an active attack is required to find out if a connection was protected against them. If you can passively tell if a connection is secured against active attacks, then passive security is practically worthless.
For the same reasons that you would rotate passwords. It is just a precaution in case it accidentally was leaked. When changing certificate anyway there is no inconvenience to the users from replacing the key, so you might as well replace it. It would for example help a bit in case an old backup of the webserver had been leaked. The difference in security is minor though, there are much greater threats from insecure CAs.
Certificates have an expiry date. They are supposed to be changed before the expiry date is reached. On a well managed system, you'll never see a certificate which has less than a week left of its validity period. Once the certificates are changed, it should be considered best practice to rotate the server key as well, so the new certificate will always be signing a different key from the previous certificate.
It would be nice to have more information to verify the correctness of the new certificate than just the existing CA certificate chain. I would like to see a small extension to SSL where the server can tell the client that any new certificate will be signed using the current certificate. When the client is told that, it can cache the current certificate and warn the user if it sees a new certificate lacking a chain from the old to the new certificate.
When parties on both sides of a firewall are cooperating in getting data through the firewall, there is little you can do to stop them. The solution is to limit what software gets to run on the trusted side of the firewall. If you don't want Skype on your network, then don't install it. Some corporations do use Skype as part of their work. Those corporations are happy that Skype is so easy to get working through their firewall.
The point where it gets difficult to get data through is when there are two firewalls in play, and each of them blocks traffic in opposite directions. The only reason any communication is possible at all in such a scenario is, that somebody between the two firewalls is cooperating with the parties, which want to communicate.
Schneier has been speculating about the possibility of an NSA planted backdoor in Dual_EC_DRBG since 2007. Which by the way took me a few attempts to find again since there are many hits if you search for NSA backdoor on his site.
Goodwill might be an exaggeration. Learning that NSA had improved security of DES did reduce the distrust in NSA, but it did not eliminate it. The first evidence of the Dual_EC_DRBG probably brought that distrust back to the previous level. By now I guess the trust in NSA is at an absolute low. (If it got any lower you would start trusting anything from the NSA not to be trustworthy.)