Not just them - an awful lot of hardware these days is developed using emulators. Ban them all and suddenly mobile phones, VCRs, Pentium processors, even games consoles themselves, become a lot harder to develop.
'course, they probably mean that no-one should have access to software emulation except *them*.
Actually, what they really want is for you to stop playing games altogether (saves *so much* on development costs), and just give them all your money for nothing.
*Not* more exploitable, more exploit*ed*. Exploitable bugs are present in both, whether one has more or less is not necessarily the most important factor.
No, but Microsoft is. The name, the brand, "Microsoft". If doesn't matter if it's Windows XP or "Services for UNIX" - if you can attach the Microsoft name to it and exploit it you've got a surefire route to infamy. Which is why so many more people are trying to than for other vendors.
Look, I'm not saying MS products are equal in robustness to those on competing platforms, I don't think they are. But if those other platforms had as much mindshare in the general population as Microsoft does, then the number of active and publicised exploits would be a lot closer to parity.
Because it's about brand awareness, not number of units out there. Apache may have more installed units, but it has very little publicity outside the geek community - whereas Microsoft lives or dies by its marketing image, so in a sense sets itself up for attack.
It doesn't really matter to the rep whether someone's really throught about the issue or not - they're still going to vote or not vote for them at the next polls. Volume counts. Make them think: Will I still be in office next season? Will changing my own stance reduce or increase my margin?
Hmm, not really. The OS and applications often exchange time_t's, and they're often stored as 4-byte quantities in data files. Update the OS and you either break binary compatibility, or have to dual the API which provides no benefit to applications until they are updated too. Update the app and you may still have an enormous data conversion problem. Which defines the scale of the problem - there's an awful *lot* of bad application code out there. In mission critical systems. Even in places where the people using it day to day have forgotton or never known it exists.
Plus history teaches us that organisations *will* wait until the last minute before updating mission critical systems. Ignore that lesson and you're certainly doomed to a repeat of Y2K.
Even with these advances, it would still take your $10M machine longer than the lifetime of the universe to crack 2048 bits using brute force with today's algorithms.
You don't use brute force (in the sense meant against symmetric ciphers) against RSA keys - think about it: 512 bit keys have already been broken, yet enumerating 2^256 (well, closer to 2^254 unless you're *really* bored) potential factorisations would still take more time than the lifetime of the universe. (Schneier's analysis in Applied Cryptography provides a stronger bound: more energy than exists in the universe.)
Instead you take into account the structure of the RSA key (only a fraction of the 2^2048 bit values are valid RSA keys, and they have a special form - that being the product of two prime numbers) and use an algorithm such as the Number Field Sieve to shortcut the calculation. Much of the progress in analysing RSA comes through improvements to the NSF algorithm itself, rather than simply implement it on faster hardware.
The effect of this is that the cost of the algorithm rises much slower with the size of the key than the direct exponential of brute force methods. Given this I would expect that if the GDP of the world was spent on cracking hardware, then you could expect to find a factorisation of a 2048-bit key well before the universe reaches heat-death. Moore's Law and improvements in algorithms can only reduce the time/money cost, and are very likely to bring it within the same reach as this attack on 1024-bit keys within the next few decades.
A lot of the Y2K problem was caused by code written within the last 35 years. It wasn't a disaster, but it was a big problem, and a huge drain on many companies' resources as the tried to fix things up at the last minute.
Use Microsoft Windows NT and forget about the little things.
I realise you're just a troll, but I'd like to point out that Win32 also has two forms of file API for most functions - one that can do 64-bit and one limited (or at least which encourages you to use) 32-bit. For 64-bit access to work in any given application, you're relying on the language runtime making the correct mapping, and/or the end developer choosing the right set of functions to use. In many cases the easiest and most obvious ones will limit you to 32-bits - so many applications will not work with such large files.
This is a problem which has affected pretty much every system - even in an OS where *only* 64-bit file APIs exist, you'll still find an occasional app which tries to fit a file location into a 32-bit variable.
Let me start out by reminding the audience I am not a security expert.
Understood - this isn't personal, just a few points which I though were unclear or misstated.
TCPA adds a few elements to this security scheme [...] longer
keys (some keys are 160 bits, most are 2048 bits)
I would assume that the 128 and 160-bit keys are keys for some symmetric cipher,
and the 2048 bit keys are RSA keys. It is wrong to suggest that key length
correlates to strength without taking the algorithm into account, and even
then practicality limits the usefulness of longer and longer keys. 128 bits is
probably safe enough, and though I'd be happy to use a 160 or 256 bit key in
a symmetric cipher, longer than that gets silly: at 128 bits you're already never
going to see the key brute forced.
The benefits of 2048 bit RSA keys come not from strength through length, but
from the fact that they belong to a different class of algorithm, which allows
you to do very different things with them.
This enables the denial of access to data if rogue software, such as a virus, is
introduced into a platform, because such introduction necessarily changes the software state of
the platform.
I have yet to be convinced that this is true of data in the general sense and malware. All real
world software contains bugs, some of which can be exploited to subvert the system.
No amount of hardware trickery can stop this being true, the best you can hope for is to
contain the spread of corruption by compartmentalizing the system. If you only have one
compartment, or only one compartment you really care about, which I suspect will be the
case for the majority of systems, then containing malicious code to that compartment provides
little benefit. Even if you care about other compartments, the premise of containment assumes
no bugs in the boundaries between neighbouring compartments.
In all likelihood you can make things prohibitively difficult for individuals to do something
against the policy of the creator of the platform/application, even with their
own property, but you can't make the guarantee that the platform is immune from malware.
Can open-source software make use of TCPA? Yes.
This is not necessarily useful. Anyone may well be able to implement TCPA features, just
as anyone can implement an SSH client. Without access to the necessary keys, you can still
be prevented from accessing particular data or functionality, just as your own SSH client won't
allow you to login to any extra servers. With open access to
the keys, you've lost any security guarantees that rested on them. This makes the exercise
somewhat pointless in many cases.
While somebody could write a DRM application using the TPM, they could also
write one without it.
DRM without hardware support can never be secure. At some point the data being
protected has to be decrypted, and since the DRM implementation doesn't have the
secure platform guarantee the TPM provides, it can't be sure there isn't something
out there waiting to extract the data. It's even relatively easy to directly subvert
the software, but subverting secure hardware is very much more difficult. This is
significant because the R in DRM is not directly tied to law - it can be used to enforce
policy that extends beyond the data owner's rights, by restricting rights that the
end user does have.
Non-DRM applications can be developed under TCPA. The example I
thought of is an improved VPN for companies that are super-paranoid about their data
(think about it... 2048 bit keys, no hash load on the system CPU, ability to tie
accessibility to a unique platform).
This can of course be done without TCPA. You could easily push the crypto into
the NIC. nCipher make a variety of crypto
hardware accelerators for networking, storage and other uses, which don't impact
the architecture of the whole of the rest of the system.
A clear plastic 'can' and that's it? We've had these for several years in the UK - it was indeed just a 'cool' market attempt. They also had small carefully-density-controlled jelly balls floating throughout the drink. Seems to have pretty much died by now.
Payphones in the UK are required to be operated by BT
BT may well have to operate payphones (it seems unlikely that that wouldn't be an operating condition) but payphones don't have to be run by BT. About 7-8 years ago I think, there was a surge in non-BT phones going up around city centres. Most have disappeared now though (presumably because they have become much less profitable in that time.)
I think the author doesn't like technology and modern music - what's the 'infotrash' he's talking about?
He certainly makes several statements which could be either just bad translations from German, or really paranoid fantasy stuff, or both:
"But a continuous consumption of datareduced audio could possibly lead to fatal consequences" (I guess you could be suddenly struck deaf whilst crossing a road...)
"The human hearing is an extremely finely co-ordinated cybernetic system" (What? Don't you remember getting those implants?)
"which would make the human of the cyberage even more insensitive than he already yet has become by the continuous mass media infotrash bombardment he is exposed to"
"A possible advantage [could be] one could clean with it supposingly contaminated audio material (as for instance propaganda from dictatorships) from so-called subliminals (i.e. hidden hypnotic suggestion messages those are intended to get into the brain without getting into conscious awareness) before listening." (Uh-huh. You'd need to cut a hole in your tinfoil hat to be able to hear anything at all though.)
Ultimately if there is any significant effect this will be determined by clinical evidence and statistics, not the guesses of some self-proclaimed "teachmaster of LOGOLOGIE - the first cyberage-religion!"
My own thoughts are that there plausibly could be a mechanism for such an effect, but nobody is going to be listening to MP3s or whatever 100% of the time, or in environments that give 100% 'fidelity' to the MP3 stream - there will always be outside 'noise' present away from or during MP3 playback. Given that most people seem to manage despite living vastly different aural environments anyway, the introduction of significant amounts of MP3 listening is unlikely to produce measurable effects in many people at all.
Slashdot Mirror
Doh!
What?? Dammit! I demand $120 ink cartridges now with non of these sub-standard ingrediants!
Not just them - an awful lot of hardware these days is developed using emulators. Ban them all and suddenly mobile phones, VCRs, Pentium processors, even games consoles themselves, become a lot harder to develop.
'course, they probably mean that no-one should have access to software emulation except *them*.
Actually, what they really want is for you to stop playing games altogether (saves *so much* on development costs), and just give them all your money for nothing.
If it sucks they'll call it Gobble.
*Not* more exploitable, more exploit*ed*. Exploitable bugs are present in both, whether one has more or less is not necessarily the most important factor.
No, but Microsoft is. The name, the brand, "Microsoft". If doesn't matter if it's Windows XP or "Services for UNIX" - if you can attach the Microsoft name to it and exploit it you've got a surefire route to infamy. Which is why so many more people are trying to than for other vendors.
Look, I'm not saying MS products are equal in robustness to those on competing platforms, I don't think they are. But if those other platforms had as much mindshare in the general population as Microsoft does, then the number of active and publicised exploits would be a lot closer to parity.
Because it's about brand awareness, not number of units out there. Apache may have more installed units, but it has very little publicity outside the geek community - whereas Microsoft lives or dies by its marketing image, so in a sense sets itself up for attack.
The sun isn't at break-even. I think its understanding of nuclear fusion may be a little more thorough than ours.
No - she from Hong Kong!
It doesn't really matter to the rep whether someone's really throught about the issue or not - they're still going to vote or not vote for them at the next polls. Volume counts. Make them think: Will I still be in office next season? Will changing my own stance reduce or increase my margin?
Hmm, not really. The OS and applications often exchange time_t's, and they're often stored as 4-byte quantities in data files. Update the OS and you either break binary compatibility, or have to dual the API which provides no benefit to applications until they are updated too. Update the app and you may still have an enormous data conversion problem. Which defines the scale of the problem - there's an awful *lot* of bad application code out there. In mission critical systems. Even in places where the people using it day to day have forgotton or never known it exists.
Plus history teaches us that organisations *will* wait until the last minute before updating mission critical systems. Ignore that lesson and you're certainly doomed to a repeat of Y2K.
You don't use brute force (in the sense meant against symmetric ciphers) against RSA keys - think about it: 512 bit keys have already been broken, yet enumerating 2^256 (well, closer to 2^254 unless you're *really* bored) potential factorisations would still take more time than the lifetime of the universe. (Schneier's analysis in Applied Cryptography provides a stronger bound: more energy than exists in the universe.)
Instead you take into account the structure of the RSA key (only a fraction of the 2^2048 bit values are valid RSA keys, and they have a special form - that being the product of two prime numbers) and use an algorithm such as the Number Field Sieve to shortcut the calculation. Much of the progress in analysing RSA comes through improvements to the NSF algorithm itself, rather than simply implement it on faster hardware.
The effect of this is that the cost of the algorithm rises much slower with the size of the key than the direct exponential of brute force methods. Given this I would expect that if the GDP of the world was spent on cracking hardware, then you could expect to find a factorisation of a 2048-bit key well before the universe reaches heat-death. Moore's Law and improvements in algorithms can only reduce the time/money cost, and are very likely to bring it within the same reach as this attack on 1024-bit keys within the next few decades.
A lot of the Y2K problem was caused by code written within the last 35 years. It wasn't a disaster, but it was a big problem, and a huge drain on many companies' resources as the tried to fix things up at the last minute.
I realise you're just a troll, but I'd like to point out that Win32 also has two forms of file API for most functions - one that can do 64-bit and one limited (or at least which encourages you to use) 32-bit. For 64-bit access to work in any given application, you're relying on the language runtime making the correct mapping, and/or the end developer choosing the right set of functions to use. In many cases the easiest and most obvious ones will limit you to 32-bits - so many applications will not work with such large files.
This is a problem which has affected pretty much every system - even in an OS where *only* 64-bit file APIs exist, you'll still find an occasional app which tries to fit a file location into a 32-bit variable.
None of the internet is necessary. We could all go back to living in the trees if we wanted. After you...
Were you signing that Albert Einstein or Andrew Eldritch?
Understood - this isn't personal, just a few points which I though were unclear or misstated.
I would assume that the 128 and 160-bit keys are keys for some symmetric cipher, and the 2048 bit keys are RSA keys. It is wrong to suggest that key length correlates to strength without taking the algorithm into account, and even then practicality limits the usefulness of longer and longer keys. 128 bits is probably safe enough, and though I'd be happy to use a 160 or 256 bit key in a symmetric cipher, longer than that gets silly: at 128 bits you're already never going to see the key brute forced.
The benefits of 2048 bit RSA keys come not from strength through length, but from the fact that they belong to a different class of algorithm, which allows you to do very different things with them.
I have yet to be convinced that this is true of data in the general sense and malware. All real world software contains bugs, some of which can be exploited to subvert the system. No amount of hardware trickery can stop this being true, the best you can hope for is to contain the spread of corruption by compartmentalizing the system. If you only have one compartment, or only one compartment you really care about, which I suspect will be the case for the majority of systems, then containing malicious code to that compartment provides little benefit. Even if you care about other compartments, the premise of containment assumes no bugs in the boundaries between neighbouring compartments.
In all likelihood you can make things prohibitively difficult for individuals to do something against the policy of the creator of the platform/application, even with their own property, but you can't make the guarantee that the platform is immune from malware.
This is not necessarily useful. Anyone may well be able to implement TCPA features, just as anyone can implement an SSH client. Without access to the necessary keys, you can still be prevented from accessing particular data or functionality, just as your own SSH client won't allow you to login to any extra servers. With open access to the keys, you've lost any security guarantees that rested on them. This makes the exercise somewhat pointless in many cases.
DRM without hardware support can never be secure. At some point the data being protected has to be decrypted, and since the DRM implementation doesn't have the secure platform guarantee the TPM provides, it can't be sure there isn't something out there waiting to extract the data. It's even relatively easy to directly subvert the software, but subverting secure hardware is very much more difficult. This is significant because the R in DRM is not directly tied to law - it can be used to enforce policy that extends beyond the data owner's rights, by restricting rights that the end user does have.
This can of course be done without TCPA. You could easily push the crypto into the NIC. nCipher make a variety of crypto hardware accelerators for networking, storage and other uses, which don't impact the architecture of the whole of the rest of the system.
Certainly not RedHat...
A clear plastic 'can' and that's it? We've had these for several years in the UK - it was indeed just a 'cool' market attempt. They also had small carefully-density-controlled jelly balls floating throughout the drink. Seems to have pretty much died by now.
In that case, it was possibly somewhat less than wise to sell or give them so many arms while they were doing it.
BT may well have to operate payphones (it seems unlikely that that wouldn't be an operating condition) but payphones don't have to be run by BT. About 7-8 years ago I think, there was a surge in non-BT phones going up around city centres. Most have disappeared now though (presumably because they have become much less profitable in that time.)
He certainly makes several statements which could be either just bad translations from German, or really paranoid fantasy stuff, or both:
"But a continuous consumption of datareduced audio could possibly lead to fatal consequences" (I guess you could be suddenly struck deaf whilst crossing a road...)
"The human hearing is an extremely finely co-ordinated cybernetic system" (What? Don't you remember getting those implants?)
"which would make the human of the cyberage even more insensitive than he already yet has become by the continuous mass media infotrash bombardment he is exposed to"
"A possible advantage [could be] one could clean with it supposingly contaminated audio material (as for instance propaganda from dictatorships) from so-called subliminals (i.e. hidden hypnotic suggestion messages those are intended to get into the brain without getting into conscious awareness) before listening." (Uh-huh. You'd need to cut a hole in your tinfoil hat to be able to hear anything at all though.)
Ultimately if there is any significant effect this will be determined by clinical evidence and statistics, not the guesses of some self-proclaimed "teachmaster of LOGOLOGIE - the first cyberage-religion!"
My own thoughts are that there plausibly could be a mechanism for such an effect, but nobody is going to be listening to MP3s or whatever 100% of the time, or in environments that give 100% 'fidelity' to the MP3 stream - there will always be outside 'noise' present away from or during MP3 playback. Given that most people seem to manage despite living vastly different aural environments anyway, the introduction of significant amounts of MP3 listening is unlikely to produce measurable effects in many people at all.
"When I use a word," Humpty Dumpty said in a rather a scornful tone, "it means just what I choose it to mean -- neither more nor less."
Tricky. Most houses aren't hermetically sealed. Be a bummer for the neighbourhood if it imploded too.