I only found out about the contest a couple of days before it began, and I was away at the time, so I couldn't participate in "real time", but I used the copies of the sent ciphertexts on the Bletchley website.
I worked away on a lorenz breaker for the SZ42 stuff, written in C. I was able to break ciphertext roughly an order of magnitude faster than Joachims code. Joachim worked away on his code for several weeks in advance of the contest. I had only a couple of days notice.
I think two things matter in a competition like
this:
o The *appropriateness* of the language
o The skills of the coder
Joachim got all the glory on this one, since he
was first to announce the breaks. But there are
probably a number of others who were "close"
when Joachim announced his break.
I've always felt that there's a per-person
bandwidth limit that's inherent in being human,
and our ability to pay attention to more than
one thing at once.
I think that about 1Gbit *per-person* in your
household is about right. A HDTV channel or two,
some background audio. A telephone
conversation. Some online gaming, and a few
software/media downloads going in parallel is
a reasonable model for someone with lots of
"stuff" on the go.
Obviously, if you run significant *services* out
of your house, these numbers go up. So for an
average house with 2.5 adults and 1.5 children,
something like 3-4GB/sec should do just fine.
I used to work in the IT division of a large hi-tech company. I worked there for 14 years, and one of the reasons I was happy to leave for a more R&D-oriented job in the same company was the increasingly-draconian "policies" that IT was promulgating. It made me sick.
The notion of "you may only installed approved software" only works if IT has a *very solid* handle on what it is that its customer population *does* with their computers. In a high-tech company that's full of hardware and software developers, it's rather clear that IT doesn't stand a gnats chance in hell of ever appropriately modeling what constitutes "legitimate" software and "illegitimate" software.
The policies have gotten so bad that even writing your own software, for your own use, on your own machine, is a violation of the "approved software only" doctrine. In a sense, modern IT departments have redefined what constitutes "useful work" to that which can be accomplished using the usual M$ triumvirate of applications. Which is a profound testament to the growing idiocy of technology-driven corporations particularly, and society in general.
To paraphrase the oft quoted "information wants to be free"--Computers Want to be Programmed!!!
Now, I sympathize with Comcast. Many ISPs, not just Comcast, are disrupting P2P sessions, and these sessions
are in clear violation of most ISP's Terms of Service. And P2P is horribly disruptive, a single user can
easily transmit 20 GB of data in a day.
So, if you calculate what 20GB/day is in bits/sec, assuming a saturated end-customer line for the full
24 hours, it works out to something like 2.3mbits/sec. With cable now offering 4mbit/sec service,
I fail to see how this is "horribly disruptive".
In terms of "clear violation of most ISP's Terms of Service", that's a little thin. Granted, *a lot* of
P2P traffic is "trafficking" in copyright-violation content, but it's kinda hard to justify painting
with such a wide brush. I get most of my Linux ISOs via BitTorrent, for example. That would hardly
be in violation of my ISPs T.O.S.
I think the real problem is that most company executives tend to think of computers as glorified
typewriters, and any use of them that falls outside their "world view", they tend to think of
as weird, and probably illegal.
I haven't followed the COMCAST debacle that closely, but it seems to me that if they argue that they
*must* throttle due to bandwidth exhaustion, then they'd better start throttling non-P2P data-grabbing
technologies--like FTP, and HTTP, and RSYNC, and e-mail, and...
Thank the heavens that I have an ISP that believes that its job is to convey bits, and that touching
those bits would cause them to lose customers faster than rats leaving a sinking ship. I wish all
ISPs had such a broad worldview...
The City and The Stars has got to be one of my favourite books of *any* s.f. author I've ever
read. I originally read the novella, Against The Fall of Night, which The City and the Stars is
based on. There's a Clarke/Benford book, "Beyond the Fall of Night" which I haven't read, but
I think it's based on the same "imaginiverse" as The City and the Stars.
I was there also, and found that the only thing I was missing was DNS config.
On Fedora, NetManager doesn't know enough to invoke DHCPv6 (dhcp6c), and when you run it manually,
it dumpeth the core, yeah verily.
I've been playing with V6 when I get a chance for the last couple of years, and have been pleasantly
surprised at how much of it on Linux "just works". The NetManager/dhcp6c stuff definitely needs to
be fixed, but the browser, telnet, ftp, rsync, ssh, wget, etc all seem to be V6 capable.
Some kind soul (I think it was Andrew McGregor) pointed me at sixxs.org during the plenary session,
and I could even get to V4 web content relatively easily.
The article mentions that they were doing pulsar surveys, which means that the signal arrived over a number of channels, but the pulses
showed dispersion. Radar signals won't display that kind of behaviour, as far as I know.
If it was at Parkes, it was likely at 326 or 408Mhz.
I run a small radio observatory, and I see large spikes from time to time. It's very likely that 99.9% of them
are local interference, distant thunderstorm activity, etc. But it's generally acknowledged in the Radio Astronomy
community, that there *are* unexplained transient phenomenon that are observed from time to time.
Some Pulsars, for example, occasionally emit "super pulses" that are usually orders-of-magnitude stronger than
the average pulses.
GRBs are also associated with radio afterglow, which can account for some small fraction of the observed
transient phenomenon.
One of the projects I'd like to do is to have different radio telescopes watching the same portion of sky, but
separated by enough distance that local RFI isn't a factor. Any transient pulses that arrive at all of the
telescopes are very likely to have originated from "out there".
The NSA knew about Differential Cryptanalysis a long, long time before Shamir et al re-discovered and perfected the technique
in the civilian world. Back when DES was being approved for use as a FIPS (1978 timeframe), the NSA suggested new S-boxes,
but never gave clues about *why*.
When Shamir developed Differential Cryptanalysis (DC), it became clear that the S-boxes in DES as it appears in the FIPS were
just-about perfectly robust against DC, but any other randomly-chosen S-boxes were definitely *not* robust against DC.
The NSA eventually admitted that they knew about DC long before the civilian cryptographers did.
But then Linear Cryptanalysis was born in the civilian crypto community, and *that* completely blindsided NSA.
Now, on a more (ahem) focussed topic.
I'm an amateur *radio* astronomer from time to time. Averaging is the bread and butter of making radio astronomy work at all.
With the exception of the Sun, all other celestial objects of interest are *below* the noise floor of my instrument. By using
long-term averaging, the noise floor diminishes with the sqrt() of the averaging time. I sample at 8megasamples per second,
and typically average between 15 seconds and 60 seconds of data. I can see through the atmosphere and clouds without any issue.
But there are effects from variability of the interstellar mediaum that can be seen from time to time.
Not entirely fair comparing radio telescopes to optical ones here. The radio telescopes are
*much* larger because the wavelenghts are so much larger, so to match their optical cousins
in *resolution*, they need to be bigger (either directly, or through aperture synthesis).
Now, the radio telescopes have much larger sensitivity--they have much larger effective apertures
than any of the optical telescopes we're talking about here. Many interesting astrophysics
objects have little, or no, optical signal, but produce detectable amounts of radio waves.
My modest radio telescope here at home is 3.8M in diameter, and can easily detect Cygnus A--which
is thought to be about 750million LY from here!
The analog video output of DVD players is protected with some simple sync-pulse frobbing that
most video recorders can't deal with (but video-capture hardware can get around with suitable
software).
My impression is that emerging HD-DVD and Blu-Ray players won't have a conventional analog
video output, but will use HDMI protected with HDCP. That means that there'll be an encrypted
channel between the player and the TV, which makes an "alligator clip" attack infeasible.
But, at some point, the signal has to transition from the virtual world of ones and zeros to the
ugly analog reality of the real world. Which can be rendered back into ones and zeros with
more-or-less fidelity depending on ingenuity and available budget:-)
I'm surprised that there aren't more high-fidelity, ripped from the analog world, instances of
DVDs out there. Most that I've heard of have been ripped from a handheld camera at a movie
theatre, with obviously-poor results.
The analog hole can never be patched. Even if you have to go to the extreme of taking a *video camera*
capture from a large-screen (HDMI/HDCP-protected) TV in a darkened room.
Take multiple recordings and average them together to reduce random analog noise in the process. Almost
as good as the original.
The Internet acts like a really, really big statistical multiplexer. Such schemes only work well when the statistical assumptions in
the capacity planning hold true most of the time.
This is no different than ordinary telephone service. Inter-telephone-switch trunking is planned based on assumptions about
average behaviour patterns, with a *little* bit of slop room on top. It would be economic suicide for phone companies
to make statistical assumptions that assume that everybody needs to talk at once, and capacity engineer their trunks
for that case.
The Internet is no different. Although until very recently, the *core* Internet bandwidth was over-engineered by a factor
of at least three. Video is changing that assumption fairly quickly, so I assume that the core carriers are looking to
upgrade their networks. What has *always* been true in the Internet is that the *access* network providers have been
held ransom by the economics of providing adequate bandwidth to the end users. That's a commodity market, and profit
margins tend to shrink over time, with Internet timescales being fairly short. Which means that there's less discretionary
money lying around to provide major capacity upgrades at the edge. I'm not sure how this will play out.
I live rurally, and get 2Mbit/512Kbit wireless service for about CDN$90.00/month. Given what I know about how thin the
user base is in rural locations, and how much infrastructure has to be put in place, I can't understand how my ISP
is actually making any money on providing my service. But he knows that if he increases prices, the other wireless
provider will be perfectly happy to offer service to me on razor-thin or non-existent margins.
Actually, the hack that gets the Volume ID now no longer requires that you mod the hardware--you can convince the
drive to give you the VolumeID if you ask it nicely and persistently enough. No desoldering drive electronics required.
The OLPC operating system has an "ACL" mechanism for programs. New programs by default aren't
allowed to do anything useful. Which means that user interaction is required to let new
software "do things". But that can be turned off.
I initially thought it was just more TPM/TCG-type garbage, but after reading the technical papers,
I'm impressed with the thoughtfullness of the design.
It's possible to do this sort of thing "right" (for various values of "right)". I'd like to see some
of the ideas from the OLPC security subsystem propagated into more "mainstream" OSes.
Good threat models assume that the attacker already has the code. Cryptosystems, for example, are designed
to assume that the bad guy knows *exactly* how your algorithm works. Other security mechanisms should, and do,
use the same threat model.
If the article is about "I used JTAG to dump the code from the CPU, which allowed me to find exploitable flaws",
it's rather boring.
If the article is about "I used JTAG to cause the CPU to do something other than the original software intended",
it's rather boring.
If, however, the article is about "It turns out that having a JTAG interface makes it possible to remotely
exploit a system, 'blind'" then I'm very interested.
Any attack that requires physical access to the box under attack just isn't very interesting. That's why I don't
bother with BIOS passwords.
Given that a GPU is (more-or-less) a flotilla of multiply-accumulate functional units, I wonder how much mileage you could get
by putting something like a *fast* FPGA in intimate contact with a more general CPU.
Need to do graphics? Download the graphics accelerator functions into the cpu-attached FPGA. Need to do crypto really fast?
Program it for that. Need to do radio astronomy, pulsar detection, etc? Program it for that.
Being a good parent doesn't mean that you have to spend every waking moment monitoring your
childs activities and behaviours. It means (in this context) establish, and reinforcing
whatever your family values are.
If you love your children, listen to them, provide encouragement and support, this pretty-much
happens automatically. But it doesn't need to be a case of attaching yourself to their
liver.
Now, having said that, I use a net nanny for my kids access to the web. Not because I don't
trust them, but rather because it's easy to trip over inappropriate material by accident.
I showed my 17-year-old how to bypass the "nanny", since she, naturally, has a widening
sense of herself, her community, and what her "standards" are. She only turns the nanny
off when it has blocked something inappropriately, but feels safer with it turned on.
Re: 3b
Software *can* be arbitrarily obfuscated to the point that it's extremely difficult to untangle, but at substantial
penalty in size and execution time.
But in the end, the software has to run on a real CPU that actually exists, and it must actually interact with
the memory and I/O environment. You can slow the smart ones down, but you can't stop 'em.
|In five years when the hardware costs 38cents for these there is no doubt that vendors will avoid paying a hefty fee for the |software or they won't be able to compete. I just hope Google gets around to building free wireless internet. Kids will not know |what a phone is in 10 years.
10 years ago, when my (now teenage) daughter was attending kindergarten, she came home very excited about
the new technology she had seen at school. These CDs that were much larger than ordinary CDs
and entirely *black*. You used something called a "record player" to play them...:-)
One could reasonably posit that at some point, you're going to want to use the OLPC to teach children
computer programming.
That means that in order to execute any such programs on their OLPC, those programs are going to need to be
"signed" by an "authority" before they can be executed. That gets old fairly quickly, so an alternative
obvious policy is that any program that was compiled on *this* OLPC is "safe" for this OLPC. Right.
The problem with Trusted Computing world views is that computers are simply *appliances*, with some 3rd party
in control of what this "appliance" can do. The end result is that rather than having a *truly* computer-literate
population, we instead perpetuate the elite software priesthood. Imagine a world where only the "priesthood"
are granted programming licenses, with technology like Trusted Computing (and this OLPC stuff) used to
"enforce" such licensing schemes.
There are lots and lots and lots of situations where non-programmers have reasonable need to write programs
from time to time. Think scientists writing simulations, engineers, artists, etc, etc. The minute you
actually grant your "appliance" Turing Completeness, you've lost its Trusted Computing properties.
Linux has had IRIX-style ACLs and POSIX ACLs for quite a long time: The the "chacl" and "setfacl" commands. This has
been in all the popular distributions of Linux since forever. Unix permissions started out with just the RWX model, but
ACLs were added a *long* time ago to mainstream Unixen, and Linux followed shortly after. The problem with ACL systems is
that they're generally too complicated to manage by mere mortals, and they're a pain to maintain. That's true whether you're
talking Winderz, Unix, Linux, Multics, whatever.
Further, the "sandboxing" model is nothing new. SELinux has facilities for doing this--quite ornate facilities, in fact.
Formulating apprropriate "sandboxing" policy for every application is even more of a pain than ACLs. In fact, there's
still a whole lot of "grad school fever" about automated methods for determining "correct" policy for systems like
SELinux, both based on a formal description of programs behaviour, and runtime analysis. It ain't easy.
SELinux has been standard in Linux kernels for about 1 (or is it two?) years. Many of the distributions, including
Fedora, include the high-level support tools for SELinux.
Slashdot Mirror
I only found out about the contest a couple of days before it began, and I was away at the time, so I
couldn't participate in "real time", but I used the
copies of the sent ciphertexts on the Bletchley
website.
I worked away on a lorenz breaker for the SZ42 stuff, written in C. I was able to break
ciphertext roughly an order of magnitude faster
than Joachims code. Joachim worked away on his code
for several weeks in advance of the contest. I had only a couple of days notice.
I think two things matter in a competition like
this:
o The *appropriateness* of the language
o The skills of the coder
Joachim got all the glory on this one, since he
was first to announce the breaks. But there are
probably a number of others who were "close"
when Joachim announced his break.
I've always felt that there's a per-person
bandwidth limit that's inherent in being human,
and our ability to pay attention to more than
one thing at once.
I think that about 1Gbit *per-person* in your
household is about right. A HDTV channel or two,
some background audio. A telephone
conversation. Some online gaming, and a few
software/media downloads going in parallel is
a reasonable model for someone with lots of
"stuff" on the go.
Obviously, if you run significant *services* out
of your house, these numbers go up. So for an
average house with 2.5 adults and 1.5 children,
something like 3-4GB/sec should do just fine.
I used to work in the IT division of a large hi-tech company. I worked there for 14 years, and one of the reasons I was happy to leave for a more R&D-oriented job in the same company was the increasingly-draconian "policies" that IT was promulgating. It made me sick.
The notion of "you may only installed approved software" only works if IT has a *very solid* handle on what it is that its customer population *does* with their computers. In a high-tech company that's full of hardware and software developers, it's rather clear that IT doesn't stand a gnats chance in hell of ever appropriately modeling what constitutes "legitimate" software and "illegitimate" software.
The policies have gotten so bad that even writing your own software, for your own use, on your own machine, is a violation of the "approved software only" doctrine. In a sense, modern IT departments have redefined what constitutes "useful work" to that which can be accomplished using the usual M$ triumvirate of applications. Which is a profound testament to the growing idiocy of technology-driven corporations particularly, and society in general.
To paraphrase the oft quoted "information wants to be free"--Computers Want to be Programmed!!!
Peter Lothberg has always had whatever counted as "scorching" bandwidth for a very long time.
He's really good at working "deals" to keep up with current trends in network firehoses...
nweaver writes:
Now, I sympathize with Comcast. Many ISPs, not just Comcast, are disrupting P2P sessions, and these sessions
are in clear violation of most ISP's Terms of Service. And P2P is horribly disruptive, a single user can
easily transmit 20 GB of data in a day.
So, if you calculate what 20GB/day is in bits/sec, assuming a saturated end-customer line for the full
24 hours, it works out to something like 2.3mbits/sec. With cable now offering 4mbit/sec service,
I fail to see how this is "horribly disruptive".
In terms of "clear violation of most ISP's Terms of Service", that's a little thin. Granted, *a lot* of
P2P traffic is "trafficking" in copyright-violation content, but it's kinda hard to justify painting
with such a wide brush. I get most of my Linux ISOs via BitTorrent, for example. That would hardly
be in violation of my ISPs T.O.S.
I think the real problem is that most company executives tend to think of computers as glorified
typewriters, and any use of them that falls outside their "world view", they tend to think of
as weird, and probably illegal.
I haven't followed the COMCAST debacle that closely, but it seems to me that if they argue that they
*must* throttle due to bandwidth exhaustion, then they'd better start throttling non-P2P data-grabbing
technologies--like FTP, and HTTP, and RSYNC, and e-mail, and...
Thank the heavens that I have an ISP that believes that its job is to convey bits, and that touching
those bits would cause them to lose customers faster than rats leaving a sinking ship. I wish all
ISPs had such a broad worldview...
The City and The Stars has got to be one of my favourite books of *any* s.f. author I've ever
read. I originally read the novella, Against The Fall of Night, which The City and the Stars is
based on. There's a Clarke/Benford book, "Beyond the Fall of Night" which I haven't read, but
I think it's based on the same "imaginiverse" as The City and the Stars.
I was there also, and found that the only thing I was missing was DNS config. On Fedora, NetManager doesn't know enough to invoke DHCPv6 (dhcp6c), and when you run it manually, it dumpeth the core, yeah verily. I've been playing with V6 when I get a chance for the last couple of years, and have been pleasantly surprised at how much of it on Linux "just works". The NetManager/dhcp6c stuff definitely needs to be fixed, but the browser, telnet, ftp, rsync, ssh, wget, etc all seem to be V6 capable. Some kind soul (I think it was Andrew McGregor) pointed me at sixxs.org during the plenary session, and I could even get to V4 web content relatively easily.
Don't give the morons ideas, buddy!
I buy my lamb from a Halal market, and I don't watch television, period.
I'm not Muslim, but getting decent lamb anywhere but at the local Halal market is rather difficult.
I'm doomed, I tell you, doomed!
The article mentions that they were doing pulsar surveys, which means that the signal arrived over a number of channels, but the pulses
showed dispersion. Radar signals won't display that kind of behaviour, as far as I know.
If it was at Parkes, it was likely at 326 or 408Mhz.
I run a small radio observatory, and I see large spikes from time to time. It's very likely that 99.9% of them
are local interference, distant thunderstorm activity, etc. But it's generally acknowledged in the Radio Astronomy
community, that there *are* unexplained transient phenomenon that are observed from time to time.
Some Pulsars, for example, occasionally emit "super pulses" that are usually orders-of-magnitude stronger than
the average pulses.
GRBs are also associated with radio afterglow, which can account for some small fraction of the observed
transient phenomenon.
One of the projects I'd like to do is to have different radio telescopes watching the same portion of sky, but
separated by enough distance that local RFI isn't a factor. Any transient pulses that arrive at all of the
telescopes are very likely to have originated from "out there".
This happens a lot.
The NSA knew about Differential Cryptanalysis a long, long time before Shamir et al re-discovered and perfected the technique
in the civilian world. Back when DES was being approved for use as a FIPS (1978 timeframe), the NSA suggested new S-boxes,
but never gave clues about *why*.
When Shamir developed Differential Cryptanalysis (DC), it became clear that the S-boxes in DES as it appears in the FIPS were
just-about perfectly robust against DC, but any other randomly-chosen S-boxes were definitely *not* robust against DC.
The NSA eventually admitted that they knew about DC long before the civilian cryptographers did.
But then Linear Cryptanalysis was born in the civilian crypto community, and *that* completely blindsided NSA.
Now, on a more (ahem) focussed topic.
I'm an amateur *radio* astronomer from time to time. Averaging is the bread and butter of making radio astronomy work at all.
With the exception of the Sun, all other celestial objects of interest are *below* the noise floor of my instrument. By using
long-term averaging, the noise floor diminishes with the sqrt() of the averaging time. I sample at 8megasamples per second,
and typically average between 15 seconds and 60 seconds of data. I can see through the atmosphere and clouds without any issue.
But there are effects from variability of the interstellar mediaum that can be seen from time to time.
Not entirely fair comparing radio telescopes to optical ones here. The radio telescopes are
*much* larger because the wavelenghts are so much larger, so to match their optical cousins
in *resolution*, they need to be bigger (either directly, or through aperture synthesis).
Now, the radio telescopes have much larger sensitivity--they have much larger effective apertures
than any of the optical telescopes we're talking about here. Many interesting astrophysics
objects have little, or no, optical signal, but produce detectable amounts of radio waves.
My modest radio telescope here at home is 3.8M in diameter, and can easily detect Cygnus A--which
is thought to be about 750million LY from here!
The analog video output of DVD players is protected with some simple sync-pulse frobbing that
:-)
most video recorders can't deal with (but video-capture hardware can get around with suitable
software).
My impression is that emerging HD-DVD and Blu-Ray players won't have a conventional analog
video output, but will use HDMI protected with HDCP. That means that there'll be an encrypted
channel between the player and the TV, which makes an "alligator clip" attack infeasible.
But, at some point, the signal has to transition from the virtual world of ones and zeros to the
ugly analog reality of the real world. Which can be rendered back into ones and zeros with
more-or-less fidelity depending on ingenuity and available budget
I'm surprised that there aren't more high-fidelity, ripped from the analog world, instances of
DVDs out there. Most that I've heard of have been ripped from a handheld camera at a movie
theatre, with obviously-poor results.
The analog hole can never be patched. Even if you have to go to the extreme of taking a *video camera*
capture from a large-screen (HDMI/HDCP-protected) TV in a darkened room.
Take multiple recordings and average them together to reduce random analog noise in the process. Almost
as good as the original.
The Internet acts like a really, really big statistical multiplexer. Such schemes only work well when the statistical assumptions in
the capacity planning hold true most of the time.
This is no different than ordinary telephone service. Inter-telephone-switch trunking is planned based on assumptions about
average behaviour patterns, with a *little* bit of slop room on top. It would be economic suicide for phone companies
to make statistical assumptions that assume that everybody needs to talk at once, and capacity engineer their trunks
for that case.
The Internet is no different. Although until very recently, the *core* Internet bandwidth was over-engineered by a factor
of at least three. Video is changing that assumption fairly quickly, so I assume that the core carriers are looking to
upgrade their networks. What has *always* been true in the Internet is that the *access* network providers have been
held ransom by the economics of providing adequate bandwidth to the end users. That's a commodity market, and profit
margins tend to shrink over time, with Internet timescales being fairly short. Which means that there's less discretionary
money lying around to provide major capacity upgrades at the edge. I'm not sure how this will play out.
I live rurally, and get 2Mbit/512Kbit wireless service for about CDN$90.00/month. Given what I know about how thin the
user base is in rural locations, and how much infrastructure has to be put in place, I can't understand how my ISP
is actually making any money on providing my service. But he knows that if he increases prices, the other wireless
provider will be perfectly happy to offer service to me on razor-thin or non-existent margins.
Actually, the hack that gets the Volume ID now no longer requires that you mod the hardware--you can convince the drive to give you the VolumeID if you ask it nicely and persistently enough. No desoldering drive electronics required.
I've sent an e-mail to Ms Smith, and to my local MP, Scott Reid.
It's a private-members bill, so it's unlikely to get any airtime, but it helps
to nip this stuff in the bud.
The OLPC operating system has an "ACL" mechanism for programs. New programs by default aren't
allowed to do anything useful. Which means that user interaction is required to let new
software "do things". But that can be turned off.
I initially thought it was just more TPM/TCG-type garbage, but after reading the technical papers,
I'm impressed with the thoughtfullness of the design.
It's possible to do this sort of thing "right" (for various values of "right)". I'd like to see some
of the ideas from the OLPC security subsystem propagated into more "mainstream" OSes.
to assume that the bad guy knows *exactly* how your algorithm works. Other security mechanisms should, and do,
use the same threat model.
If the article is about "I used JTAG to dump the code from the CPU, which allowed me to find exploitable flaws",
it's rather boring.
If the article is about "I used JTAG to cause the CPU to do something other than the original software intended",
it's rather boring.
If, however, the article is about "It turns out that having a JTAG interface makes it possible to remotely
exploit a system, 'blind'" then I'm very interested.
Any attack that requires physical access to the box under attack just isn't very interesting. That's why I don't
bother with BIOS passwords.
Given that a GPU is (more-or-less) a flotilla of multiply-accumulate functional units, I wonder how much mileage you could get
by putting something like a *fast* FPGA in intimate contact with a more general CPU.
Need to do graphics? Download the graphics accelerator functions into the cpu-attached FPGA. Need to do crypto really fast?
Program it for that. Need to do radio astronomy, pulsar detection, etc? Program it for that.
If you love your children, listen to them, provide encouragement and support, this pretty-much happens automatically. But it doesn't need to be a case of attaching yourself to their liver.
Now, having said that, I use a net nanny for my kids access to the web. Not because I don't trust them, but rather because it's easy to trip over inappropriate material by accident. I showed my 17-year-old how to bypass the "nanny", since she, naturally, has a widening sense of herself, her community, and what her "standards" are. She only turns the nanny off when it has blocked something inappropriately, but feels safer with it turned on.
I use Dans Guardian. It's Open Source. Everyone has their favourite.
Re: 3b Software *can* be arbitrarily obfuscated to the point that it's extremely difficult to untangle, but at substantial penalty in size and execution time. But in the end, the software has to run on a real CPU that actually exists, and it must actually interact with the memory and I/O environment. You can slow the smart ones down, but you can't stop 'em.
|In five years when the hardware costs 38cents for these there is no doubt that vendors will avoid paying a hefty fee for the |software or they won't be able to compete. I just hope Google gets around to building free wireless internet. Kids will not know |what a phone is in 10 years.
:-)
10 years ago, when my (now teenage) daughter was attending kindergarten, she came home very excited about
the new technology she had seen at school. These CDs that were much larger than ordinary CDs
and entirely *black*. You used something called a "record player" to play them...
One could reasonably posit that at some point, you're going to want to use the OLPC to teach children
computer programming.
That means that in order to execute any such programs on their OLPC, those programs are going to need to be
"signed" by an "authority" before they can be executed. That gets old fairly quickly, so an alternative
obvious policy is that any program that was compiled on *this* OLPC is "safe" for this OLPC. Right.
The problem with Trusted Computing world views is that computers are simply *appliances*, with some 3rd party
in control of what this "appliance" can do. The end result is that rather than having a *truly* computer-literate
population, we instead perpetuate the elite software priesthood. Imagine a world where only the "priesthood"
are granted programming licenses, with technology like Trusted Computing (and this OLPC stuff) used to
"enforce" such licensing schemes.
There are lots and lots and lots of situations where non-programmers have reasonable need to write programs
from time to time. Think scientists writing simulations, engineers, artists, etc, etc. The minute you
actually grant your "appliance" Turing Completeness, you've lost its Trusted Computing properties.
I see this as an unresolvable dicotomy.
Linux has had IRIX-style ACLs and POSIX ACLs for quite a long time: The the "chacl" and "setfacl" commands. This has
been in all the popular distributions of Linux since forever. Unix permissions started out with just the RWX model, but
ACLs were added a *long* time ago to mainstream Unixen, and Linux followed shortly after. The problem with ACL systems is
that they're generally too complicated to manage by mere mortals, and they're a pain to maintain. That's true whether you're
talking Winderz, Unix, Linux, Multics, whatever.
Further, the "sandboxing" model is nothing new. SELinux has facilities for doing this--quite ornate facilities, in fact.
Formulating apprropriate "sandboxing" policy for every application is even more of a pain than ACLs. In fact, there's
still a whole lot of "grad school fever" about automated methods for determining "correct" policy for systems like
SELinux, both based on a formal description of programs behaviour, and runtime analysis. It ain't easy.
SELinux has been standard in Linux kernels for about 1 (or is it two?) years. Many of the distributions, including
Fedora, include the high-level support tools for SELinux.