* It's impossible given this rotten design to really achieve decent * performance at 100Mbps, unless you happen to have a 400Mhz PII or * some equally overmuscled CPU to drive it.
That being said, wow, that's a truly awful design.
OpenNX operates on X streams; I don't see why things would be any different if you operated inside of SSH instead of being a front end to it. If I'm wrong, please mail me, dan@doxpara.com.
Yeah, I was pretty stoked when they finally ported it over. Here's the latest build of PuTTY hosted off a web page -- quite convenient for Internet Cafes. (If ActiveX is going to be insecure, we can at least make it useful.)
So, a couple years ago I put together a patch for OpenSSH that added what I referred to as "Dynamic Forwarding" -- put simply, it turned SSH into a sort of "poor man's VPN". You could (and in fact, I do) access almost all Internet services, tunnelled and encrypted, over an SSH session.
After I first presented this hack, I had these three Chinese guys walk up to me, and start asking quite literally the most detailed questions about my architecture that I had ever heard. It quickly became clear that, for the rest of the world, censorship avoidance is a sort of "first step" that anyone who's serious about network access learns to master. The whole line about censorship being damage that the Internet routes around is astonishingly true; the level to which complete non-geeks participate in proxy bouncing, encrypted tunnelling, and whatever else it takes to get out is quite astonishing.
Because wildcards are not necessarily a bad thing. The concept is that you have a single SSL accelerator in front of a whole pool of servers, and it absorbs the "security context" of all the hosts behind it.
If you want universal SSL deployment, this is one of the ways you get it.
The scan is a result of sweeping 64.* . XYZ = 64.x.y.z. I'm not saying it's a brilliant advance, because it's not -- just that visualization design is very easy to do wrong, and that's what makes it so interesting to work with. It fails in a manner so very different than most code, which seems to die because of either scalability concerns or an inability to manage its own bloat. It succeeds on something much softer, which are theories of human perceptivity.
If you're interested, email me privately and I'll send you code.
Yeah, but this is OpenNX encapsulating SSH, rather than SSH encapsulating OpenNX. The latter is, architecturally, the most simple and straightforward way to deploy NX.
So much fun. And so, so utterly useless 95% of the time.
I've been working on particle systems for large scale data visualization. Even got some working code up -- see this for the results of my DNS server research (every particle is a host). It's...OK. The problem is that while a good chunk of our brain is devoted to visual processing, a good chunk of what we do is decidedly abstract and non-visual. Playing across these mental lines can usefully employ underutilized computation frameworks, but that doesn't mean that it will.
Think -- crypto on a GPU, not particularly fast (floating point and crypto only work well together in one extraordinarily obscure context).
It's alot of fun to play in this domain, and occasionally the results are really really useful (like this rendering of failed entropy generators). But...yeah. Way too often, your output isn't as useful as a quickly resortable log file.
That's what makes it such a great challenge, of course. Few other fields show themselves to be empty of value so late in the dev cycle. (Biotech people have it worse, of course.)
NX really needs to be ported to into OpenSSH as an optional compression module for its X Forwarding component. That way, there's literally nothing more than:
ssh -X user@host...and if both client and server support NX, things just fly.
This is somewhat likely to be an innoculation against a real threat being taken seriously. Oh, the warning was likely "real", in the sense that those who made it probably spoke those words, but it was probably "amplified" by press so that we'd watch it fail and not trust the next warning.
There's really a fine art of preventing panic. This is part of how it's done.
It's worth pointing out that it was widely assumed that there was a serious flaw in the original SHA, enough that NSA saw fit to add that final left shift at the end of each round. SHA-1 *exists* because there's a problem in SHA-0. The original SHA is not "slightly less secure" because it just lacks the fix; the nature of the algorithm is such that the slight variation NSA introduced created enormous deviations in the output function. Unless there's a fundamental architectural hole -- possible, see MD4/MD5 -- the original SHA could fall to pieces and it wouldn't mean SHA-1 was dead in the water.
I don't really know what Ed Felten means regarding "weaker cousins" of SHA-1 being the only other popular hashes. SHA-256 is a cousin, but has a larger hash size and is generally considered to be stronger. SHA (SHA-0?) is a cousin, but I've never seen it deployed anywhere. MD4/MD5 are still mildly popular, but they're at best design ancestors and not cousins -- there's no way a break in SHA-1 is going to make them any less secure (they have their own issues, of course). RIPE-160 and TIGER are the only two other hashes I've seen in the field, and they too have nothing to do with SHA-1.
There might be something here -- the left shift could have been a band-aid solution to an architectural fault in the SHA design, and there may be lots of curiosity about whether the new SHA-0 attack routes neatly around the fix. We'll see.
MP3 is a bitstream, so you can basically use the language of your choice to seek to arbitrary offsets, slice wherever you like for as long as you like, and whatever frames are broken will simply not get decoded. You may of course want to actually have on-frame-boundry edits (they generally sound better and play more reliably, especially on ipod which doesn't have great stream reassembly code). cutmp3 can work:
http://www.puchalla-online.de/cutmp3.html
There's lots of pure windows code to do this too:
http://www.programurl.com/software/cutter.htm
But if you want to code this yourself, there's some excellent Perl libraries for managing MP3:
It's not too bad to use Perl either, especially with the Perl Packager. Given only one host with the full Cygwin Perl install, you can create compiled executables that encapsulate everything you need down to a single file. It rocks!
http://search.cpan.org/~autrijus/PAR-0.85/script /p p
I imagine though that you'd eventually want to only analyze random chunks that contain speech, or at least speech like frequency distributions. This is trickier, and I don't know if there's Perl code to do it. Maybe you could investigate Praat's internal scripting language?
http://www.fon.hum.uva.nl/praat/
Praat is pretty mind-bogglingly cool -- it's worth checking out no matter what.
--Dan
P.S. Yes, I've been working on some mildly related stuff. How could you tell?:-)
Then it's just a matter of frequency, not coverage. Remember, at the end of the day, light is just another wavelength of EMF, just like RADAR. And I doubt we'd go to a global laser system, if only because the higher the frequency, the worse the penetration -- the whole thing about seeing clouds is because they block and scatter optical frequencies. (They also scatter radar, but less, and in a correctable fashion -- see SAR, synthetic aperature radar).
But if we did, we'd really have to pump the power up, and since we're illuminating the sky, we'd have to pump far more energy out into the wild blue yonder than for the equivalent space in low frequency RADAR bands.
We dump pretty enormous amounts of energy at RADAR wavelengths, 24/7, across the night sky. That'll stop approximately when we have no fear of hostile aircraft showing up at our borders.
Most trojans need to poll the outside world periodically, to determine whether they have a new set of operations to execute. With this approach, no polling is necessary -- there's an open pipe _into_ the organization, and the trojan can remain perfectly silent.
Yeah, check out the slides. I rather obsessively follow the spec (limit to Base32 my upstream queries, Base64 my downstream TXT records, though I could just as easily use Base32'd CNAME's or MX's).
The whole point is that DNS is equivalent to every web server proxying, and that this proxy service does have security implications.
But please, cache stuff locally:-) It makes my radio hack work much much better.
Recursive lookup support isn't required to achieve incoming connectivity (see induced lookups), and being able to do lookups against the outside world isn't identified by anyone as a risk.
Even doing network tunneling over DNS -- ALSO not that big a deal; NSTX has been doing this for a while.
DNS radio is new. By segmenting audio into small chunks, we actually get universal caching of the streaming signal -- a functionality we've never really had before. Generally, audio broadcast over the Internet falls apart after a few thousand users. Based on this ring-buffer-into-BIND architecture, combined with the utterly minimal bandwidth load of Speex, we should be able to host audio for a much greater number of listeners.
The entire suite of incoming attacks to firewalls are also new. DNS trusts the hierarchy to tell it the next hop to its target name; since I can acquire second level domains in the hierarchy for minimal cost, it's trivial for me to insert arbitrary destinations along the DNS route path. In technical terms, whenever a recursing resolver comes to my name server to resolve a name, rather than providing an answer, I can redirect that request to another, supposedly authoritative server. That server can be at any address -- even one I cannot IP route to -- but if the resolver communicating with me can route to that address (say 10.0.1.11) my communication will reach that host. If there's an SSH over DNS daemon running on 10.0.1.11, I've now achieved incoming connectivity to the network of my choice, completely bypassing firewalls and a trojan's need to poll.
Recursion on dual hosted interfaces is not even necessary. There are large numbers of applications that, upon receiving untrusted traffic, execute DNS name lookups. Most commonly, they are reverse PTR lookups, but occasionally there are other types (MX from mail servers, most notably) that can be easily induced. When they are induced, the hierarchy is followed. When the hierarchy is followed, the attacks previously discussed start working. In practice, this means an IDS triggers the DNS server to start proxying traffic between an external attacker host and an internal trojaned machine. Nasty.
There's some other stuff -- check out the slides and the code -- but long story short, there's some new stuff out:-)
MS's giant cash pile is too deep of a pocket for international juries and governments to ignore. The disbursement is being directly driven by the fact that the company has enough cash on hand to be able to shrug off $600M judgements.
You know how the more fuel a rocket has, the more fuel it needs, due to the additional weight of that fuel? Understand how most of the fuel is ultimately spent in complete waste, as it's just carrying itself?
Kind of the same with water. Water is HEAVY -- seven pounds a gallon. We blow quite a bit of it just dragging it around -- and don't worry, it provides all of no calories; it's useful as a catalyst and a cooler, but not as a fuel. Almost all the water we consume is just excreted back out, pretty clean too (urine is one of the purer substances to leave the body). It's be pretty useful to be able to fully filter the stuff and reintroduce it to our food. Perfectly efficient, no, but would you rather lug around 50 pounds of water?
Slashdot Mirror
That being said, wow, that's a truly awful design.
--Dan
OpenNX operates on X streams; I don't see why things would be any different if you operated inside of SSH instead of being a front end to it. If I'm wrong, please mail me, dan@doxpara.com .
--Dan
No way! They patched my hack to death?!?!
Can you send me a screen shot? dan@doxpara.com
--Dan
Yeah, I was pretty stoked when they finally ported it over. Here's the latest build of PuTTY hosted off a web page -- quite convenient for Internet Cafes. (If ActiveX is going to be insecure, we can at least make it useful.)
--Dan
So, a couple years ago I put together a patch for OpenSSH that added what I referred to as "Dynamic Forwarding" -- put simply, it turned SSH into a sort of "poor man's VPN". You could (and in fact, I do) access almost all Internet services, tunnelled and encrypted, over an SSH session.
After I first presented this hack, I had these three Chinese guys walk up to me, and start asking quite literally the most detailed questions about my architecture that I had ever heard. It quickly became clear that, for the rest of the world, censorship avoidance is a sort of "first step" that anyone who's serious about network access learns to master. The whole line about censorship being damage that the Internet routes around is astonishingly true; the level to which complete non-geeks participate in proxy bouncing, encrypted tunnelling, and whatever else it takes to get out is quite astonishing.
--Dan
Because wildcards are not necessarily a bad thing. The concept is that you have a single SSL accelerator in front of a whole pool of servers, and it absorbs the "security context" of all the hosts behind it.
If you want universal SSL deployment, this is one of the ways you get it.
--Dan
The scan is a result of sweeping 64.* . XYZ = 64.x.y.z. I'm not saying it's a brilliant advance, because it's not -- just that visualization design is very easy to do wrong, and that's what makes it so interesting to work with. It fails in a manner so very different than most code, which seems to die because of either scalability concerns or an inability to manage its own bloat. It succeeds on something much softer, which are theories of human perceptivity.
If you're interested, email me privately and I'll send you code.
--Dan
Yeah, but this is OpenNX encapsulating SSH, rather than SSH encapsulating OpenNX. The latter is, architecturally, the most simple and straightforward way to deploy NX.
--Dan
So much fun. And so, so utterly useless 95% of the time.
I've been working on particle systems for large scale data visualization. Even got some working code up -- see this for the results of my DNS server research (every particle is a host). It's...OK. The problem is that while a good chunk of our brain is devoted to visual processing, a good chunk of what we do is decidedly abstract and non-visual. Playing across these mental lines can usefully employ underutilized computation frameworks, but that doesn't mean that it will.
Think -- crypto on a GPU, not particularly fast (floating point and crypto only work well together in one extraordinarily obscure context).
It's alot of fun to play in this domain, and occasionally the results are really really useful (like this rendering of failed entropy generators). But...yeah. Way too often, your output isn't as useful as a quickly resortable log file.
That's what makes it such a great challenge, of course. Few other fields show themselves to be empty of value so late in the dev cycle. (Biotech people have it worse, of course.)
--Dan
NX really needs to be ported to into OpenSSH as an optional compression module for its X Forwarding component. That way, there's literally nothing more than:
...and if both client and server support NX, things just fly.
ssh -X user@host
--Dan
This is somewhat likely to be an innoculation against a real threat being taken seriously. Oh, the warning was likely "real", in the sense that those who made it probably spoke those words, but it was probably "amplified" by press so that we'd watch it fail and not trust the next warning.
There's really a fine art of preventing panic. This is part of how it's done.
--Dan
That's Dr. Jose Nazario to you :-)
(Friendly props, Dr. J. See ya at Toor.)
--Dan
It's worth pointing out that it was widely assumed that there was a serious flaw in the original SHA, enough that NSA saw fit to add that final left shift at the end of each round. SHA-1 *exists* because there's a problem in SHA-0. The original SHA is not "slightly less secure" because it just lacks the fix; the nature of the algorithm is such that the slight variation NSA introduced created enormous deviations in the output function. Unless there's a fundamental architectural hole -- possible, see MD4/MD5 -- the original SHA could fall to pieces and it wouldn't mean SHA-1 was dead in the water.
I don't really know what Ed Felten means regarding "weaker cousins" of SHA-1 being the only other popular hashes. SHA-256 is a cousin, but has a larger hash size and is generally considered to be stronger. SHA (SHA-0?) is a cousin, but I've never seen it deployed anywhere. MD4/MD5 are still mildly popular, but they're at best design ancestors and not cousins -- there's no way a break in SHA-1 is going to make them any less secure (they have their own issues, of course). RIPE-160 and TIGER are the only two other hashes I've seen in the field, and they too have nothing to do with SHA-1.
There might be something here -- the left shift could have been a band-aid solution to an architectural fault in the SHA design, and there may be lots of curiosity about whether the new SHA-0 attack routes neatly around the fix. We'll see.
MP3 is a bitstream, so you can basically use the language of your choice to seek to arbitrary offsets, slice wherever you like for as long as you like, and whatever frames are broken will simply not get decoded. You may of course want to actually have on-frame-boundry edits (they generally sound better and play more reliably, especially on ipod which doesn't have great stream reassembly code). cutmp3 can work:
- 0. 08/Frame.pm
/ Sp litter.pm
t /p p
:-)
http://www.puchalla-online.de/cutmp3.html
There's lots of pure windows code to do this too:
http://www.programurl.com/software/cutter.htm
But if you want to code this yourself, there's some excellent Perl libraries for managing MP3:
http://search.cpan.org/~nuffin/MPEG-Audio-Frame
(and most directly speaking to what you're working on)
http://search.cpan.org/~ilyaz/MP3-Splitter-0.02
It's not too bad to use Perl either, especially with the Perl Packager. Given only one host with the full Cygwin Perl install, you can create compiled executables that encapsulate everything you need down to a single file. It rocks!
http://search.cpan.org/~autrijus/PAR-0.85/scrip
I imagine though that you'd eventually want to only analyze random chunks that contain speech, or at least speech like frequency distributions. This is trickier, and I don't know if there's Perl code to do it. Maybe you could investigate Praat's internal scripting language?
http://www.fon.hum.uva.nl/praat/
Praat is pretty mind-bogglingly cool -- it's worth checking out no matter what.
--Dan
P.S. Yes, I've been working on some mildly related stuff. How could you tell?
Then it's just a matter of frequency, not coverage. Remember, at the end of the day, light is just another wavelength of EMF, just like RADAR. And I doubt we'd go to a global laser system, if only because the higher the frequency, the worse the penetration -- the whole thing about seeing clouds is because they block and scatter optical frequencies. (They also scatter radar, but less, and in a correctable fashion -- see SAR, synthetic aperature radar).
But if we did, we'd really have to pump the power up, and since we're illuminating the sky, we'd have to pump far more energy out into the wild blue yonder than for the equivalent space in low frequency RADAR bands.
--Dan
We dump pretty enormous amounts of energy at RADAR wavelengths, 24/7, across the night sky. That'll stop approximately when we have no fear of hostile aircraft showing up at our borders.
You know, never.
--Dan
Uh, ever fired a gun with one hand?
Or ever fired a gun for that matter?
You been watchin' too much John Woo, AC.
--Dan
I'm sticking to 512byte DNS for now, as the goal is to show proxied connectivity (i.e. evading mere filters is too simple).
Most trojans need to poll the outside world periodically, to determine whether they have a new set of operations to execute. With this approach, no polling is necessary -- there's an open pipe _into_ the organization, and the trojan can remain perfectly silent.
--Dan
Yeah, check out the slides. I rather obsessively follow the spec (limit to Base32 my upstream queries, Base64 my downstream TXT records, though I could just as easily use Base32'd CNAME's or MX's).
:-) It makes my radio hack work much much better.
The whole point is that DNS is equivalent to every web server proxying, and that this proxy service does have security implications.
But please, cache stuff locally
--Dan
Recursive lookup support isn't required to achieve incoming connectivity (see induced lookups), and being able to do lookups against the outside world isn't identified by anyone as a risk.
--Dan
OK, let me repeat.
:-)
Throwing arbitrary data in DNS -- NOT a big deal.
Even doing network tunneling over DNS -- ALSO not that big a deal; NSTX has been doing this for a while.
DNS radio is new. By segmenting audio into small chunks, we actually get universal caching of the streaming signal -- a functionality we've never really had before. Generally, audio broadcast over the Internet falls apart after a few thousand users. Based on this ring-buffer-into-BIND architecture, combined with the utterly minimal bandwidth load of Speex, we should be able to host audio for a much greater number of listeners.
The entire suite of incoming attacks to firewalls are also new. DNS trusts the hierarchy to tell it the next hop to its target name; since I can acquire second level domains in the hierarchy for minimal cost, it's trivial for me to insert arbitrary destinations along the DNS route path. In technical terms, whenever a recursing resolver comes to my name server to resolve a name, rather than providing an answer, I can redirect that request to another, supposedly authoritative server. That server can be at any address -- even one I cannot IP route to -- but if the resolver communicating with me can route to that address (say 10.0.1.11) my communication will reach that host. If there's an SSH over DNS daemon running on 10.0.1.11, I've now achieved incoming connectivity to the network of my choice, completely bypassing firewalls and a trojan's need to poll.
Recursion on dual hosted interfaces is not even necessary. There are large numbers of applications that, upon receiving untrusted traffic, execute DNS name lookups. Most commonly, they are reverse PTR lookups, but occasionally there are other types (MX from mail servers, most notably) that can be easily induced. When they are induced, the hierarchy is followed. When the hierarchy is followed, the attacks previously discussed start working. In practice, this means an IDS triggers the DNS server to start proxying traffic between an external attacker host and an internal trojaned machine. Nasty.
There's some other stuff -- check out the slides and the code -- but long story short, there's some new stuff out
--Dan
MS's giant cash pile is too deep of a pocket for international juries and governments to ignore. The disbursement is being directly driven by the fact that the company has enough cash on hand to be able to shrug off $600M judgements.
What, did you think the timing was accidental?
--Dan
Here, lets talk in some geek terms.
You know how the more fuel a rocket has, the more fuel it needs, due to the additional weight of that fuel? Understand how most of the fuel is ultimately spent in complete waste, as it's just carrying itself?
Kind of the same with water. Water is HEAVY -- seven pounds a gallon. We blow quite a bit of it just dragging it around -- and don't worry, it provides all of no calories; it's useful as a catalyst and a cooler, but not as a fuel. Almost all the water we consume is just excreted back out, pretty clean too (urine is one of the purer substances to leave the body). It's be pretty useful to be able to fully filter the stuff and reintroduce it to our food. Perfectly efficient, no, but would you rather lug around 50 pounds of water?
--Dan
Email me if you're an RSS developer.