It's the same solution that's been used with RSA for ages. When 512-bit keys were broken, 1024-bit keys were recommended. Now when they're almost broken, 2048-bit keys are recommended. I hear that some are already recommending 4096-bit keys.
There's no fool-proof "solution" to this problem. The key (no pun intended) is to keep a high enough ratio between hash length (or key length) and the kind of processing power that potential crackers (including the NSA) can be thought to have access to.
Thus, as the processing power of the world increases, so do we increase the hash/key lengths. There's nothing strange about that, if you ask me -- especially considering how the required processing power increases exponentially with the hash/key length in use.
Yeah, really -- get the actual 'puter out of your room, rig some ethernet, set up XDMCP and get a thin client (such as a PXE-booting fanless Mini-ITX running an X terminal). Then enjoy the sound of complete silence.
Sure, it won't work for gamers, but it ought to be fine for most other purposes.
While both of the above algorithms are "broken" in the sense that a collision may be found relatively easily, if a signature is done on both hashes, the attacker has to find a message that provides the same MD5 hash and the same SHA-1 hash, which I strongly doubt is possible theoretically.
It's certainly theoretically possible. If you use SHA1, which is 160 bits, and MD5, which is 128 bits, then you have a hash that is 160+128=288 bits in length. That yields 2^288 combinations.
There are, however, 2^296 messages that are 37 bytes in length, which means that for any 37-byte message, there are by necessity 255 other 37-byte messages that yield the exact same hashes. Sure, most (all?) of the others will be binary gibberish, but there are nonetheless 255 colliding messages for any given 37-byte message.
And that's just for 37-byte messages. If you send a 1 KiB message, there are 2^7904, or around 10^2379 colliding messages.
I'm sorry, my post was a bit out of context -- in fact, I hadn't even seen that VeriSign issues certs to fake names. What I was protesting against is all these people saying things such that VeriSign should not issue certificates to makers of malware, regardless of what they call their companies.
That is abusing the technology in the sense of using authentication for authorization, which is, objectively speaking, wrong.
Of course, as you say, VeriSign shouldn't grant certificates to obviously faked names.
What you seem to be missing is the fact that certificates are meant for authentication, not authorization. While it would most likely help if VeriSign wouldn't issue certificates to dubious software vendors, that would be as much abuse of the technology as the idea of setting "sex bits" on IP packets to indicate sexual content.
Thus, authentication already works the way it should. This is not a case where I should say "don't fix what already works", but rather "don't break that which works". Instead, work should be done on the authorization part. I have no suggestion as to how authorization should be fixed, but at least authentication shouldn't be broken just to get an ad-hoc fix to authorization.
The way to deal with this is thinking ahead. It's actually not hard to write portable code - the problem is porting code which wasn't designed for it.
I partly agree. It's just that sometimes (quite often for my part), thinking ahead often means writing less portable programs.
I often want to write programs that work as well as they can on my platform (GNU/Linux, of course), and that means taking full advantage of and really adapting to the system in question. For example, using "POSIX-like" directory layouts and file formats, forking and piping, using regexes (which, AFAIK, aren't even available in the basic Win32 API), and sometimes (though I prefer to stay strictly POSIX) using GNU extensions.
That certainly makes the program less portable, and I'm aware of it, but it makes it more integrated with the platform for which it was intended. Sure, you could seperate the core logic algorithms from the O/S-specific code, but that always forces you to rely less on O/S-specific behavior, and often forces you to spend a lot of time on constructing generic abstract interfaces to functionality that exists in different forms on both platforms.
Thus, if one doesn't intend to port ones programs, one does benefit a lot from writing non-portable code (provided that it's done correctly, of course).
It's not like having 100% open source doesn't give you anymore functionality.
Some people don't realize this, but open source does yield more functionality in itself, even regardlessly of what program is in question, in that you can modify programs that don't work quite as you want them to in order to make them work precisely the way you want them to.
That's one of my foremost reasons for running free software on my systems. It's not like I do large changes to every program I work with, but small ones every here and there. For example, I patched gaim to spellcheck in a different language than my current locale, xscreensaver to blank my TV instead of launch a screenhack on it, and so on. Small changes every here and there.
That's why I get "something that actually works" with free software.
If the product turns out to be faulty, it means their's a problem with Red Hat or SuSE's distribution, regardless of whether it's located in the kernel or not.
Yes. However, if it's a local non-root exploit in a program that noone ever uses, that means that it's not actually a threat to security.
It's still their problem, and that's why they issue patches. It's nothing to worry about, however.
Then again, there was the ASN.1 bug that Microsoft didn't patch until half-a-year or so after they discovered it.
Admittedly, they didn't release their knowledge of it to the rest of the world either, but who's to say that no crackers knew about it? I believe that security through obscurity has been said not to be the best solution.
More patches from Linux vendors means they're actually working on the freaking problem.
While that's true, there's another implication as well.
While the patches for Windows includes faults in, precisely, Windows (which is what I'm guessing that he's referring to by saying "15 patches"), the patch count for Linux distros include patches for all programs in the distro. That includes not only the core parts of the operating system. In the @RISK newsletter I'm recieving from SANS, I see almost only patches for more seldomly used software, such as ncpfs, Konversation, Dillo, xdvizilla, mpg321, and so on.
Considering how a Linux distro probably contains at least 10 times as many software packages as a Windows installation (the vast majority of which are optional to install), I can't see how it would be in Microsoft's favor that they're issuing one third as many patches as Linux distributors do.
I realize this may be thought of as flamebait, but that's honestly not how it's intended.
Seriously, aren't these environmental issues takes much too seriously. I mean, does it really hurt so badly if a rare bird species dies out because of a new bridge getting built. Likewise, does a redwood tree become worth more just 'cause it's 500 years old?
Nature is always in constant flux, and all that we humans do is at most accelerating the process a bit (if even that much... probably we are rather altering it slightly). It's not like there's a purpose is keeping a rare species in existance. Right? In particular, species die out and come into existance every day anyway -- I don't see the point in keeping one alive just because it would have lived if humans weren't there. It makes it sound as if humans were somehow "outside" the rest of nature, and that it would somehow serve a purpose to leave nature alone. That purpose I cannot see.
In the webcast transcript on Microsoft's site, Taylor said this:
Roughly about 72 percent of 800 IT professionals in North America all said that Microsoft has done the most versus any other vendor to offer interoperability.
I'm certain that that is true. What I suspect is that UNIX/Linux vendors don't do much as much actual work for interoperability, because they don't need to.
POSIX systems are, and have always been, inherently built upon open standards (in particular ASCII file formats). As such, almost all programs that run on POSIX don't need extra work to be interoperable. They are interoperable by default since they all communicate through the same standards and interfaces.
On Windows, however, there's nothing of the sort of common standards for programs interoperating with each other. For that reason, Microsoft must work manually for interoperability between programs. Microsoft has only lately begun to look at XML for similar levels of interoperability (which I have also commented on before).
For the casual sysadmin (the one that either doesn't know how to connect UNIX programs, or expects the original developers to do it for him), it may seem that Microsoft is much more on the "offensive" for interoperability, while the POSIX system vendors think that they don't need to do anything about it, since it ought to be so simple to interconnect compliant program anyhow (like "after all, it's been done in the same way since UNIX was first invented, why should we even have to tell anyone about it?").
Isn't that the (pseudo-)benefit customers see in Microsoft and interoperability?
I like how this is the comment that is most likely to run through a MPAA employee's mind at the moment of reading this article, and at the same time is rated Funny on slashdot.:)
These efforts are centered on using XML, which makes information self-describing - and thus more easily understood by different systems. For example, when two systems exchange a purchase order, the attributes of that purchase order are described in XML, so any receiving system can use that description to translate and use the enclosed information.
This kind of reasoning never ceases to amaze me.
Sure, XML can make information more self-describing, but:
Microsoft doesn't even do that. The MS Office XML Schemas are about as non-descriptive as is possible with XML.
Self-describing information doesn't mean interoperability. Just because the information tells you what it is doesn't mean you will no longer need an adapter to get it into your system. In BizTalk, Microsoft talks about using XSLT to convert XML schemas used in one application to the ones used in another. Honestly, just because the adapter is written in XSLT instead of C doesn't stop it from being an adapter.
Even disregarding the two previous points, self-describing information exchange has been available since at least the 1950's as LISP s-exprs (which are also more capable than XML, for that matter). Even disregarding s-exprs, it's not as if ASCII files (as so often used in POSIX systems for configuration) aren't self-describing.
The only thing that using XML provides is that there is are already-written parsers for most languages that are ready for use.
And honestly, no matter how great XML is for describing documents, it's among the most awkward formats I've ever seen for describing arbitrary data structures, so the fact that there are parsers available just isn't worth it. It's like as if, when the cars were first invented, people would ignore them and keep on using horse carriages just because "there are already horse carriages, so if we use them, we won't have to manifacture new cars".
Great...
Re:Cramming a PC into a Shell not hacking.
on
Mac mini to PC Hack
·
· Score: 1
Well, see meaning 6 and 7 in the definition of a hacker according to the Jargon File:
6. An expert or enthusiast of any kind.
One might be an astronomy hacker, for example.
7. One who enjoys the
intellectual challenge of creatively overcoming or circumventing
limitations.
This $500 Apple is still insanely overpriced.
GotApex? has a "headless Dell" on their site for $449.
It is worth noting, however, that you can probably fit around 10+ Mac Minis in the same volume that that Dell chassis takes. I don't know if you didn't RTFA, but the Mac Mini is 6.5x6.5x2 (inches).
If you want a PC with the same physical configuration, you'll probably pay the same price for a MiniITX computer that has considerably worse performance.
Furthermore, this is also an advance in Mac pricing. I don't think Apple has ever sold computers this cheap before. It'll probably make many more people consider getting a Mac instead of a PC the next time they buy a new computer.
Slashdot Mirror
In short, having two different hashes doesn't add more security (at least not significantly more) than just doubling the hash length.
There's no fool-proof "solution" to this problem. The key (no pun intended) is to keep a high enough ratio between hash length (or key length) and the kind of processing power that potential crackers (including the NSA) can be thought to have access to.
Thus, as the processing power of the world increases, so do we increase the hash/key lengths. There's nothing strange about that, if you ask me -- especially considering how the required processing power increases exponentially with the hash/key length in use.
I may be mistaken, but I think the POSIX and SUS "design documents" are fairly strict...
Yeah, really -- get the actual 'puter out of your room, rig some ethernet, set up XDMCP and get a thin client (such as a PXE-booting fanless Mini-ITX running an X terminal). Then enjoy the sound of complete silence.
Sure, it won't work for gamers, but it ought to be fine for most other purposes.
I don't see the need to lock down preferences if you make backups. Is that just me?
There are, however, 2^296 messages that are 37 bytes in length, which means that for any 37-byte message, there are by necessity 255 other 37-byte messages that yield the exact same hashes. Sure, most (all?) of the others will be binary gibberish, but there are nonetheless 255 colliding messages for any given 37-byte message.
And that's just for 37-byte messages. If you send a 1 KiB message, there are 2^7904, or around 10^2379 colliding messages.
That is abusing the technology in the sense of using authentication for authorization, which is, objectively speaking, wrong.
Of course, as you say, VeriSign shouldn't grant certificates to obviously faked names.
Thus, authentication already works the way it should. This is not a case where I should say "don't fix what already works", but rather "don't break that which works". Instead, work should be done on the authorization part. I have no suggestion as to how authorization should be fixed, but at least authentication shouldn't be broken just to get an ad-hoc fix to authorization.
I often want to write programs that work as well as they can on my platform (GNU/Linux, of course), and that means taking full advantage of and really adapting to the system in question. For example, using "POSIX-like" directory layouts and file formats, forking and piping, using regexes (which, AFAIK, aren't even available in the basic Win32 API), and sometimes (though I prefer to stay strictly POSIX) using GNU extensions.
That certainly makes the program less portable, and I'm aware of it, but it makes it more integrated with the platform for which it was intended. Sure, you could seperate the core logic algorithms from the O/S-specific code, but that always forces you to rely less on O/S-specific behavior, and often forces you to spend a lot of time on constructing generic abstract interfaces to functionality that exists in different forms on both platforms.
Thus, if one doesn't intend to port ones programs, one does benefit a lot from writing non-portable code (provided that it's done correctly, of course).
Some people don't realize this, but open source does yield more functionality in itself, even regardlessly of what program is in question, in that you can modify programs that don't work quite as you want them to in order to make them work precisely the way you want them to.
That's one of my foremost reasons for running free software on my systems. It's not like I do large changes to every program I work with, but small ones every here and there. For example, I patched gaim to spellcheck in a different language than my current locale, xscreensaver to blank my TV instead of launch a screenhack on it, and so on. Small changes every here and there.
That's why I get "something that actually works" with free software.
It seems that speed and memory footprint isn't exactly a priority at the Mozilla Foundation.
It's still their problem, and that's why they issue patches. It's nothing to worry about, however.
Admittedly, they didn't release their knowledge of it to the rest of the world either, but who's to say that no crackers knew about it? I believe that security through obscurity has been said not to be the best solution.
While the patches for Windows includes faults in, precisely, Windows (which is what I'm guessing that he's referring to by saying "15 patches"), the patch count for Linux distros include patches for all programs in the distro. That includes not only the core parts of the operating system. In the @RISK newsletter I'm recieving from SANS, I see almost only patches for more seldomly used software, such as ncpfs, Konversation, Dillo, xdvizilla, mpg321, and so on.
Considering how a Linux distro probably contains at least 10 times as many software packages as a Windows installation (the vast majority of which are optional to install), I can't see how it would be in Microsoft's favor that they're issuing one third as many patches as Linux distributors do.
Seriously, aren't these environmental issues takes much too seriously. I mean, does it really hurt so badly if a rare bird species dies out because of a new bridge getting built. Likewise, does a redwood tree become worth more just 'cause it's 500 years old?
Nature is always in constant flux, and all that we humans do is at most accelerating the process a bit (if even that much... probably we are rather altering it slightly). It's not like there's a purpose is keeping a rare species in existance. Right? In particular, species die out and come into existance every day anyway -- I don't see the point in keeping one alive just because it would have lived if humans weren't there. It makes it sound as if humans were somehow "outside" the rest of nature, and that it would somehow serve a purpose to leave nature alone. That purpose I cannot see.
POSIX systems are, and have always been, inherently built upon open standards (in particular ASCII file formats). As such, almost all programs that run on POSIX don't need extra work to be interoperable. They are interoperable by default since they all communicate through the same standards and interfaces.
On Windows, however, there's nothing of the sort of common standards for programs interoperating with each other. For that reason, Microsoft must work manually for interoperability between programs. Microsoft has only lately begun to look at XML for similar levels of interoperability (which I have also commented on before).
For the casual sysadmin (the one that either doesn't know how to connect UNIX programs, or expects the original developers to do it for him), it may seem that Microsoft is much more on the "offensive" for interoperability, while the POSIX system vendors think that they don't need to do anything about it, since it ought to be so simple to interconnect compliant program anyhow (like "after all, it's been done in the same way since UNIX was first invented, why should we even have to tell anyone about it?").
Isn't that the (pseudo-)benefit customers see in Microsoft and interoperability?
I like how this is the comment that is most likely to run through a MPAA employee's mind at the moment of reading this article, and at the same time is rated Funny on slashdot. :)
Sure, XML can make information more self-describing, but:
- Microsoft doesn't even do that. The MS Office XML Schemas are about as non-descriptive as is possible with XML.
- Self-describing information doesn't mean interoperability. Just because the information tells you what it is doesn't mean you will no longer need an adapter to get it into your system. In BizTalk, Microsoft talks about using XSLT to convert XML schemas used in one application to the ones used in another. Honestly, just because the adapter is written in XSLT instead of C doesn't stop it from being an adapter.
- Even disregarding the two previous points, self-describing information exchange has been available since at least the 1950's as LISP s-exprs (which are also more capable than XML, for that matter). Even disregarding s-exprs, it's not as if ASCII files (as so often used in POSIX systems for configuration) aren't self-describing.
The only thing that using XML provides is that there is are already-written parsers for most languages that are ready for use.And honestly, no matter how great XML is for describing documents, it's among the most awkward formats I've ever seen for describing arbitrary data structures, so the fact that there are parsers available just isn't worth it. It's like as if, when the cars were first invented, people would ignore them and keep on using horse carriages just because "there are already horse carriages, so if we use them, we won't have to manifacture new cars".
Great...
If you want a PC with the same physical configuration, you'll probably pay the same price for a MiniITX computer that has considerably worse performance.
Furthermore, this is also an advance in Mac pricing. I don't think Apple has ever sold computers this cheap before. It'll probably make many more people consider getting a Mac instead of a PC the next time they buy a new computer.