Not quite. NAT leads to more complex systems being built to work around NAT. More complex systems are more likely to have security holes. Ergo, NAT has a net-negative security impact.
If you call it "accidental" yourself, it's not security in the first place. That's like "hiding" a flawed service on a non-standard port and calling it secure.
if the dns server is configured to get the entire zone file and not just query for a single entry (this is the proper way to configure a dns server that intends on supporting IPv6 because if you don't get the entire zone file then you don't know which protocol to prefer
That's just plain wrong. Getting the whole zone file is done via AXFR requests and should only be allowed for slaves of the server. No client will ever do an AXFR to query a record.
The preference of IPv6 vs. IPv4 is done by the client only. If it wants IPv6 first, it will ask for an AAAA record first.
NAT. Has. Nothing. To. Do. With. Security. Period.
With plain NAT and no filter, someone on your outer segment (malicious ISP, hacked ISP, other customers of some cable ISPs,...) can simply set a route to your LAN via your external gateway. The only thing that helps security is a packet filter - which will work just fine with or without NAT.
IPv6 makes routing much easier because most of those addresses won't be allocated to anything. They serve to keep the address space non-fragmented, so routers will have much smaller routing tables. Also, routing IPv6 is much easier because of a reduced set of options and a streamlined packet format, reducing the processing required by routers.
If anything, IPv6 makes things nicer and cleaner. If you wanna know about ugly, look at NAT and CIDR and the hack it brought to reverse resolution.
If your system "runs slowly" because of an enabled but not-connected IPv6 stack, it plain sucks. If you have no IPv6 connectivity, don't set a default route for it. The fallback is instant and nothing runs slowly on a proper system.
Any vendor that relies on a custom algorithm for their encryption technology shouldn't be trusted.
Of course.
But even then there are vendors who claim to be using AES and end up introducing implementational flaws that are not obvious to the user. It's not just algorithms that need to be reviewed but complete implementations.
Re:Still not too bad
on
Crypto Snake Oil
·
· Score: 4, Interesting
I'm not so sure. Once a flawed implementation has been broken, there will be tools to crack it.
Take WEP for example. I personally wouldn't know how to crack it. But others do. They develop tools. Et voila, today it's trivial to download some tool and break WEP, even for novices.
Weak encryption is never good and should be strongly discouraged.
1 - 1069's action was arguably illegal but not immoral (considering intent)
Are you psychic? How can you know his intent? Because he said so?
3 - it was appropriate, surgical even, use of expertise - no tampering
Again, because he said so? Otherwise, breaking into a computer is as close to tampering as it can get.
4 - no risk to any third parties or innocents by his hack
Unless you assume the victim of the hack to be guilty in the first place, then yes, there were no innocents.
I can't think how this whole thing could be any more fishy. You jump to judging the guy and praising the hacker, because the subject is child porn; or to apply the meme: "Won't somebody think of the children!"
It's scary how you dismiss due process because the crime gets to you on a personal level or whatever.
Is it different if he silently broke into your house to steal some silver and happened to look into a room where you were doing the molesting? What if he happened to have a camera and took pictures?
You're mixing up things. A photo with _him_ on it (on paper or digital) is much stronger evidence than a photo which isn't related to him in any way other than it was allegedly found in his possession. If the trespasser came to the Police and said "Here, I found these photos of children in this guy's room", there would be the same level of doubt that he may just have put them there himself.
If the hacker had found some pictures with the guy on them, then I would have much less doubt about the hacker's intention. But alas, it's just a criminal with a dubious agenda and his "evidence" is worth jack shit.
Seems like encrypting twice with a 64-bit key just means that instead of breaking a 64-bit key once, you have to do it twice.
I think there's more to this problem than you realize at first. Bruteforce relies on the ability to identify when you have successfully broken the cipher text. If you encrypt random data and then try to bruteforce it, how will you know at the first layer that you have successfully broken it? It's not like some magic bit is telling you whether the key was correct or not. If you decrypt with the wrong key, you just get (truly random?) garbled data.
Wouldn't you have to do the "inner" 64bit bruteforce procedure for each possible key of the "outer" 64bit keyspace, thus making it 128bit again? I'm feeling the effective key strength is somewhere between 64bit and 128bit, certainly more than 65bit, but not really 128bit.
If ISPs want to reduce bandwidth overuse by seeders... Just IMPLEMENT MULTICAST ALREADY!
Isn't Multicast a real-time protocol, i.e. everyone would have to download a torrent at the same time to benefit from it? Multicast seems to be more suited for TV-like applications, not random access bulk data. Or am I missing something?
If you don't secure a wireless connection that spills onto other people's property, why shouldn't they use it until told otherwise?
Sure, they can use it as they wish. They just shouldn't have _any_ expectation to be 1) not monitored 2) provided unfiltered Internet 3) provided unmodified Internet.
If you let your signal spill over onto other people's space, too bad.
Exactly. And if every image they are served is goatse, too bad as well.
We all make mistakes. In production software, those mistakes are ironed out by testing
I just wanted to point out some too obvious "design" flaws, if you can call it design in the case of a quick shell line.
The world is full of clueless newbies, and sloppy code practices - even if just for a quick hack - multiply and become embedded in permanent "solutions" this way.
I think we can agree there is no reason to nitpick if you[1] come up with this line at home for a run-once-and-discard session. If you[1] post it publicly, though, you should follow some very simple rules that make the thing more readable, less specialized and generally cleaner since less experienced people _will_ pick it up.
Slashdot Mirror
If you call it "accidental" yourself, it's not security in the first place. That's like "hiding" a flawed service on a non-standard port and calling it secure.
If you had and had understood what I wrote, you wouldn't be asking.
There is no ARP with IPv6.
Why don't you go inform yourself before you go on crusades against things you don't understand?
The preference of IPv6 vs. IPv4 is done by the client only. If it wants IPv6 first, it will ask for an AAAA record first.
Your first sentence is true, I'm afraid.
NAT. Has. Nothing. To. Do. With. Security. Period.
...) can simply set a route to your LAN via your external gateway. The only thing that helps security is a packet filter - which will work just fine with or without NAT.
With plain NAT and no filter, someone on your outer segment (malicious ISP, hacked ISP, other customers of some cable ISPs,
Get rid of NAT now, the sooner the better.
Ah yes, the fear of the uninformed.
IPv6 makes routing much easier because most of those addresses won't be allocated to anything. They serve to keep the address space non-fragmented, so routers will have much smaller routing tables. Also, routing IPv6 is much easier because of a reduced set of options and a streamlined packet format, reducing the processing required by routers.
If anything, IPv6 makes things nicer and cleaner. If you wanna know about ugly, look at NAT and CIDR and the hack it brought to reverse resolution.
If your system "runs slowly" because of an enabled but not-connected IPv6 stack, it plain sucks. If you have no IPv6 connectivity, don't set a default route for it. The fallback is instant and nothing runs slowly on a proper system.
More complexity on top of bloated and horribly obscure software. That'll help security, really.
I don't see public lists of cleptomaniacs/arsonists/drunk drivers/..., either. And at least two of those can get people killed as well.
Wow, you are surely playing on one's heart strings here.
I bet anyone saying "Fuck off, his right to privacy is our right to privacy" gets a big booing and a free entry in this fascistic database now.
But even then there are vendors who claim to be using AES and end up introducing implementational flaws that are not obvious to the user. It's not just algorithms that need to be reviewed but complete implementations.
Nice read: http://www.schneier.com/crypto-gram-9902.html#sna
I'm not so sure. Once a flawed implementation has been broken, there will be tools to crack it.
Take WEP for example. I personally wouldn't know how to crack it. But others do. They develop tools. Et voila, today it's trivial to download some tool and break WEP, even for novices.
Weak encryption is never good and should be strongly discouraged.
Again, because he said so? Otherwise, breaking into a computer is as close to tampering as it can get.
Unless you assume the victim of the hack to be guilty in the first place, then yes, there were no innocents.
I can't think how this whole thing could be any more fishy. You jump to judging the guy and praising the hacker, because the subject is child porn; or to apply the meme: "Won't somebody think of the children!"
It's scary how you dismiss due process because the crime gets to you on a personal level or whatever.
If the hacker had found some pictures with the guy on them, then I would have much less doubt about the hacker's intention. But alas, it's just a criminal with a dubious agenda and his "evidence" is worth jack shit.
If such things bother you, I wonder why you keep using Linux at all..
Really, I'm sorry that your profits - that you earned so hard by putting out piles of junk - now get eaten into by recalling said junk.
Who came up with the idea anyway, that products must not harm the customer? Sheesh, won't somebody think of the profits!
Wouldn't you have to do the "inner" 64bit bruteforce procedure for each possible key of the "outer" 64bit keyspace, thus making it 128bit again? I'm feeling the effective key strength is somewhere between 64bit and 128bit, certainly more than 65bit, but not really 128bit.
IANAC(ryptologist).
Exactly. And if every image they are served is goatse, too bad as well.
The world is full of clueless newbies, and sloppy code practices - even if just for a quick hack - multiply and become embedded in permanent "solutions" this way.
I think we can agree there is no reason to nitpick if you[1] come up with this line at home for a run-once-and-discard session. If you[1] post it publicly, though, you should follow some very simple rules that make the thing more readable, less specialized and generally cleaner since less experienced people _will_ pick it up.
[1] The general "you", not you personally.
Of the three you listed, two are obscurity.
I believe in AES being secure.
I don't believe in AES in a closed app being secure.