The suggestion is that if data is being hidden in the LSB of a photo then you can use statistical analysis to spot this anomoly.
The problem here seems to be that if you were to compress your hidden data prior to hiding it, then the data inserted would appear random and should thwart statistical analysis.
The problem is, the LSBs of a photo do not appear to be random; there are many subtle correlations between them, some of them human-visible and some of them computer-visible. A given known machine-visible one can be foiled with enough statistics (see Outguess), but when a new one comes along the steg will be broken (as is Outguess).
In any case, it is assumed that you are compressing the data to save space and protect your cipher, and then encrypting it (stripping any headers added by your encryption program) to give data that would be difficult to prove non-random. The question remains how to find places in the file which appear sufficiently random to hide your data.
You'd need some redundancy there if you intent to jpeg compress the image, but it might work.
No, you'd just fudge the low-order bits (after quantization) of the coefficients of the discrete cosine transform. Of course, these also have correlations that you'd have to watch out for.
Use a portable email program on a USB thumbdrive. Think McFly, think!
You do understand that this is a pain in the ass, right? Most people do not have thumbdrives. I do have a thumbdrive, but to use it everytime I check email (on Windows, Mac and *n?x, no less) would be annoying.
Webmail might be a more reasonable solution, but webmail is annoying in its own ways.
"Specifically, your plan fails to account for nothing. That's a good sign. Maybe the Slashdot groupthink can suggest improvements?"
I'll toss a couple in. Bandwidth and joe-jobs. Most CAPTCHA images are fairly big; having to send a bounce for every incoming spam would eat up a fair amount of bandwidth, and being joe-jobs would be devastating in terms of storage and bandwidth.
Where? The only impracticality is forcing large-scale adoption. That is a problem. In particular, I don't think his ideas on "partially-locked" addresses and such have been seen before.
I've seen several proposals to add CAPTCHAs to email. None of them have halted the spam problem, largely for the reason that dealing with CAPTCHAs on a regular basis is a pain in the ass.
I should be able to e-mail myfriend;a2b2c2@example.com for the rest of my life.
Suppose you are at a public terminal or someone else's computer. You won't be able to send an email to your friend without remembering his random subaddress.
Leave off, dude. The document was FOUO 15 years ago, it either got leaked or was declassified, and now it's here. The thing talks about substitution ciphers and transpositions, which any government should know are broken. I haven't read the whole thing, but I'd bet that all the techniques outlined are public domain. Otherwise, it would be classified SECRET at least.
You'd have a point if it contained the latest (or even latest as of 1990) research on RSA, elliptic curves, Feistel ciphers, shift registers, or AES (well, that wasn't around in 1990, but you get the idea). Those don't belong in a field manual anyway, because if the ciphers are breakable at all, it would be far easier to send them home to be broken by the guys with Ph.D.s and supercomputers (like yourself).
The method of attack for most stack buffer-overflows is to write enough data into a stack-allocated object to clobber the return pointer, which is allocated above it.
So why not make the stack grow upwards instead of downwards?
As I understand it, the innovation is being able to express this domain logic in the form of SQL-like queries as well as C++ or whatever code. This makes it a lot easier to write.
Some financials company is using this software to check incoming stock feeds for problems. It takes thousands of messages per second, and if certain stocks don't come in at least once in 5 seconds, it counts a miss. For others it's 1 in 30 seconds.
If a given provider is consistently slow, it sounds a low-level alarm against the provider, not to trust their data because it's slow. Similarly for various markets, and probably other groupings too. It probably does other processing on the data.
This data is almost useless within 5 minutes, and it has to be processed very fast. If you change your application, nothing will matter within 5 minutes. If your machine crashes, you have bigger problems, as is generally the case when you want real-time processing. And you don't need a lot of history.
Streambase is much faster than the company's previous custom-coded C++ program, largely because it has better multithreading and more query optimization. It's designed to cut across multiple layers of a traditional database platform (transport, database, application).
Of course, Stonebraker could be puffing his product, but it sounds pretty effective to me.
Many methods use something called hash saturation to distill randomness. This isn't as provably strong, but in practice it tends to be better (more efficient with the entropy in your stream) than the von Neumann whitener (which is what GP described).
The Optiplex S280 is about 50% larger than the Mac Mini in each dimension, and it has Intel shared (read: crappy) graphics. It therefore has enough room for a desktop hard drive, which is why the drive is cheaper. The CD drive doesn't come standard on the Optiplex either. It does, however, have more USB ports and faster Ethernet.
As for RAM, you're right. Apple gouges you on RAM. So you have to get your own and figure out how to install it, which is probably painful and/or warranty-voiding.
For $500 you can get a propriatory system that is half the power of a system for half the money.
Show me a $250 SFF system which is twice as powerful as the Mac Mini. Heck, show me a $500 SFF system which is substantially more powerful than the Mac Mini. Remember that the Mini has graphics with dedicated video RAM and laptop components to get down to size. I'll bet the Nanode will cost at least $500, and it won't be any smaller.
I built a SFF machine for just under $400 last year. It's still 5 times bigger than the mini (it's a Mini-ITX tower), it has a shitty VIA processor and no graphics card. Same LAN. Bigger HD, but that's because I didn't mind the size of a 3.5" drive. Better sound and more ports. Homebuilt wooden case, looks nice, but cost me in labor. DVD burner, but those are expensive in slimline (available on the Mini, but not the $500 version). More RAM, but RAM is cheap. Didn't get an OS with it, it runs FreeBSD right now, might switch to Linux eventually. Works real nice as a file/web/print/backup server, sucks for anything else.
Had the Mac Mini existed then, I wouldn't have bothered.
A couple friends and I were working on an Objective-C to Objective-Caml bridge, to enable Mac OS X-native applications to be written with O'Caml components. I hacked up in a day or two a working bridge core that's independent of header files, but to get reasonable performance and nice syntax out of it, I or one of my friends would have to either modify the O'Caml parser (which is possible through CamlP4), or better, write an Objective-C parser to generate per-class glue and O'Caml modules.
We were doing it for fun, not for a job... and we decided that the performance and syntax of the independent bridge were too terrible for most purposes, and the complexity of writing even a C parser wasn't worth the effort, nor was stripping out gcc's parser. So it didn't get done.
If instead of Objective-C it had been XML or Lisp, any one of us could have done it in a weekend or two.
SSH is not so weak as you suggest. It is certainly more complex, but it uses stack canaries and privilege separation to reduce its vulnerabilities. While its protocol is nastier, some level of nastiness is necessary to securely encrypt things.
OpenBSD ships SSH open by default, and has only had one root hole in what, 8 years? Any reasonably exploitable SSH root hole would count (although holes which are exploitable on Linux might not be on OpenBSD). And there have been buffer overflows in telnetd, too...
Why do people not use dump? I have a small file/print/web backup server which doesn't have anything critical, but I'd like to back up my stuff on it every week or so. Nightly BSD snapshots deal with 'oh shit I erased that file' so backups only have to deal with 'oh shit the hard drive died.' I run dump to a separate partition, and then burn it to DVD once every so often (generally at the end of the month).
I don't run level 0 dumps because I'd rather have nodump flags work without having to specify -h. I don't want the ports tree or the 50 gigs of backups from other machines to get burned to DVD.
dump.sh:
#!/usr/local/bin/bash
level=$1
if [ "$level" == '' ]; then
echo "Usage: dump.sh level fs... " fi shift
I think you're being too cynical. Perhaps PR was a factor, but does it not help relief efforts to give relief efforts a large fraction of their valuable screen real-estate? I mean, it amounts to a tremendous amount of free advertising.
For example, for days after the tsunami, Apple replaced their entire 5-section news/ads, which takes up almost all their main page, with links to relief organizations. Amazon also had large redirection signs. Google added tsunami-relief links to their home page. Sure, these made the companies look good, but they also must have brought in hundreds of thousands, even millions of dollars in contributions.
But it doesn't... say you've written a program and BSD licensed it... someone else takes your code, fixes some bugs you weren't aware of, makes improvements to it and sells the result under a closed source license... how the f do you get those bugfixes and improvements back into your own program now... they're under absolutely NO obligation to put their improvements back into the common pot. Those who persist in advocating the BSD license are fools... why else do you think Microsoft loves BSD and hates the GPL so much...
Most companies are interested in remaining competitive, in having their product dominate or at least compete in the market. Note that it is the success of their product they are interested in, not their technology; they would rather their technology remain in their product alone, instead of flourishing in the hands of their competition. To secure this technological edge, they need to release their work in a closed-source or otherwise semi-free or non-free form. Otherwise they will only make money on support and not on licensing of technology, which for many companies would be a ruinous drop in revenue.
Furthermore, for internal products, most companies would rather have the option of re-using the libraries or modules in proprietary outside products should they prove useful. For this reason, they would rather not encumber any of their IP with GPL restrictions. Thus Microsoft hates the GPL, or at least refuses to use GPLed libraries, for fear of encumbering useful code, thereby wasting programmer time on software which cannot be profitably released.
The upshot is that even an excellent piece of GPLed software will be passed up in favor of an inferior internal rewrite or BSD-licensed piece. Look what happened to Mac OS X: Apple could not have incorporated a Linux kernel or API the way they incorporated the FreeBSD API, because it is not free enough to be linked with Mach or with their proprietary improvements.
Even within Open Source projects, the encumbering nature of the GPL is a problem: as Mozilla is available under a BSD license as well as GPL, Konqueror can take patches from it but not vice-versa.
I certainly like the GPL, and contribute to GPL projects, but I recognize that in many cases, a greater gain for the universe of software (free and non-free) can be had by releasing software under a BSD license or even into the public domain. The best of both worlds is available, too: one can release code into the public domain or under a BSD license, and also link it into a GPL project under the GPL.
Meh. AppleWorks is a Bad Carbon Port, which is shameful coming from Apple. Its user interface is not consistent with the rest of OS X, even with other Carbon apps. And the text rendering is pretty terrible. I'd rather use TextEdit. Or TeX. And that's saying a lot.
the act of going back in time and being able to pass information when you do it completly negates cause and effect.
"Cause and effect" is not necessarily a fundamental law of the universe, but rather a convenient notion from our perspective (going in the same direction in time as entropy decreases).
At least for certain small systems, it has been proved that objects travelling back in time cannot render the system inconsistent, that is, there is no grandmother paradox. One such (toy) system is a pool table where the balls are particles and the pockets are wormholes. A ball coming out of a pocket cannot prevent itself from entering the corresponding pocket in the first place.
Also, passing information backward in time, while it hasn't been shown experimentally (yet?) is not a completely insane notion. Quantum erasure experiments appear to do something very much like that (send information outside its own light-cone), but as far as I know in the current ones, sending the information back to within its own light-cone tends to collapse the system.
No it doesn't. Would time travel negate free will? Suppose someone could know what you were going to do, before you did it, because they'd seen it already through their future-o-scope. Does that negate your free will?
Slashdot Mirror
The suggestion is that if data is being hidden in the LSB of a photo then you can use statistical analysis to spot this anomoly.
The problem here seems to be that if you were to compress your hidden data prior to hiding it, then the data inserted would appear random and should thwart statistical analysis.
The problem is, the LSBs of a photo do not appear to be random; there are many subtle correlations between them, some of them human-visible and some of them computer-visible. A given known machine-visible one can be foiled with enough statistics (see Outguess), but when a new one comes along the steg will be broken (as is Outguess).
In any case, it is assumed that you are compressing the data to save space and protect your cipher, and then encrypting it (stripping any headers added by your encryption program) to give data that would be difficult to prove non-random. The question remains how to find places in the file which appear sufficiently random to hide your data.
You'd need some redundancy there if you intent to jpeg compress the image, but it might work.
No, you'd just fudge the low-order bits (after quantization) of the coefficients of the discrete cosine transform. Of course, these also have correlations that you'd have to watch out for.
Use a portable email program on a USB thumbdrive. Think McFly, think!
You do understand that this is a pain in the ass, right? Most people do not have thumbdrives. I do have a thumbdrive, but to use it everytime I check email (on Windows, Mac and *n?x, no less) would be annoying.
Webmail might be a more reasonable solution, but webmail is annoying in its own ways.
"Specifically, your plan fails to account for nothing. That's a good sign. Maybe the Slashdot groupthink can suggest improvements?"
I'll toss a couple in. Bandwidth and joe-jobs. Most CAPTCHA images are fairly big; having to send a bounce for every incoming spam would eat up a fair amount of bandwidth, and being joe-jobs would be devastating in terms of storage and bandwidth.
Where? The only impracticality is forcing large-scale adoption. That is a problem. In particular, I don't think his ideas on "partially-locked" addresses and such have been seen before.
I've seen several proposals to add CAPTCHAs to email. None of them have halted the spam problem, largely for the reason that dealing with CAPTCHAs on a regular basis is a pain in the ass.
I should be able to e-mail myfriend;a2b2c2@example.com for the rest of my life.
Suppose you are at a public terminal or someone else's computer. You won't be able to send an email to your friend without remembering his random subaddress.
Leave off, dude. The document was FOUO 15 years ago, it either got leaked or was declassified, and now it's here. The thing talks about substitution ciphers and transpositions, which any government should know are broken. I haven't read the whole thing, but I'd bet that all the techniques outlined are public domain. Otherwise, it would be classified SECRET at least.
You'd have a point if it contained the latest (or even latest as of 1990) research on RSA, elliptic curves, Feistel ciphers, shift registers, or AES (well, that wasn't around in 1990, but you get the idea). Those don't belong in a field manual anyway, because if the ciphers are breakable at all, it would be far easier to send them home to be broken by the guys with Ph.D.s and supercomputers (like yourself).
There may exist a faster laptop out there that comes with all the stuff the Mac Mini does but faster, but they're hardly ubiquitous.
IBM Thinkpad comes to mind. Expensive, but for the same reason that Macs are: they're high quality.
The method of attack for most stack buffer-overflows is to write enough data into a stack-allocated object to clobber the return pointer, which is allocated above it.
So why not make the stack grow upwards instead of downwards?
Does this remind anyone else of Pipe Dream?
As I understand it, the innovation is being able to express this domain logic in the form of SQL-like queries as well as C++ or whatever code. This makes it a lot easier to write.
Some financials company is using this software to check incoming stock feeds for problems. It takes thousands of messages per second, and if certain stocks don't come in at least once in 5 seconds, it counts a miss. For others it's 1 in 30 seconds.
If a given provider is consistently slow, it sounds a low-level alarm against the provider, not to trust their data because it's slow. Similarly for various markets, and probably other groupings too. It probably does other processing on the data.
This data is almost useless within 5 minutes, and it has to be processed very fast. If you change your application, nothing will matter within 5 minutes. If your machine crashes, you have bigger problems, as is generally the case when you want real-time processing. And you don't need a lot of history.
Streambase is much faster than the company's previous custom-coded C++ program, largely because it has better multithreading and more query optimization. It's designed to cut across multiple layers of a traditional database platform (transport, database, application).
Of course, Stonebraker could be puffing his product, but it sounds pretty effective to me.
Many methods use something called hash saturation to distill randomness. This isn't as provably strong, but in practice it tends to be better (more efficient with the entropy in your stream) than the von Neumann whitener (which is what GP described).
The Optiplex S280 is about 50% larger than the Mac Mini in each dimension, and it has Intel shared (read: crappy) graphics. It therefore has enough room for a desktop hard drive, which is why the drive is cheaper. The CD drive doesn't come standard on the Optiplex either. It does, however, have more USB ports and faster Ethernet.
As for RAM, you're right. Apple gouges you on RAM. So you have to get your own and figure out how to install it, which is probably painful and/or warranty-voiding.
For $500 you can get a propriatory system that is half the power of a system for half the money.
Show me a $250 SFF system which is twice as powerful as the Mac Mini. Heck, show me a $500 SFF system which is substantially more powerful than the Mac Mini. Remember that the Mini has graphics with dedicated video RAM and laptop components to get down to size. I'll bet the Nanode will cost at least $500, and it won't be any smaller.
I built a SFF machine for just under $400 last year. It's still 5 times bigger than the mini (it's a Mini-ITX tower), it has a shitty VIA processor and no graphics card. Same LAN. Bigger HD, but that's because I didn't mind the size of a 3.5" drive. Better sound and more ports. Homebuilt wooden case, looks nice, but cost me in labor. DVD burner, but those are expensive in slimline (available on the Mini, but not the $500 version). More RAM, but RAM is cheap. Didn't get an OS with it, it runs FreeBSD right now, might switch to Linux eventually. Works real nice as a file/web/print/backup server, sucks for anything else.
Had the Mac Mini existed then, I wouldn't have bothered.
A couple friends and I were working on an Objective-C to Objective-Caml bridge, to enable Mac OS X-native applications to be written with O'Caml components. I hacked up in a day or two a working bridge core that's independent of header files, but to get reasonable performance and nice syntax out of it, I or one of my friends would have to either modify the O'Caml parser (which is possible through CamlP4), or better, write an Objective-C parser to generate per-class glue and O'Caml modules.
We were doing it for fun, not for a job... and we decided that the performance and syntax of the independent bridge were too terrible for most purposes, and the complexity of writing even a C parser wasn't worth the effort, nor was stripping out gcc's parser. So it didn't get done.
If instead of Objective-C it had been XML or Lisp, any one of us could have done it in a weekend or two.
Extrans is your friend here.
And that should be a <comma/>.
SSH is not so weak as you suggest. It is certainly more complex, but it uses stack canaries and privilege separation to reduce its vulnerabilities. While its protocol is nastier, some level of nastiness is necessary to securely encrypt things.
OpenBSD ships SSH open by default, and has only had one root hole in what, 8 years? Any reasonably exploitable SSH root hole would count (although holes which are exploitable on Linux might not be on OpenBSD). And there have been buffer overflows in telnetd, too...
Compression artifacts. Don't use JPEG for text. Really. Don't.
My backup script is run on a cronjob asI don't run level 0 dumps because I'd rather have nodump flags work without having to specify -h. I don't want the ports tree or the 50 gigs of backups from other machines to get burned to DVD.
dump.sh:
I think you're being too cynical. Perhaps PR was a factor, but does it not help relief efforts to give relief efforts a large fraction of their valuable screen real-estate? I mean, it amounts to a tremendous amount of free advertising.
For example, for days after the tsunami, Apple replaced their entire 5-section news/ads, which takes up almost all their main page, with links to relief organizations. Amazon also had large redirection signs. Google added tsunami-relief links to their home page. Sure, these made the companies look good, but they also must have brought in hundreds of thousands, even millions of dollars in contributions.
But it doesn't... say you've written a program and BSD licensed it... someone else takes your code, fixes some bugs you weren't aware of, makes improvements to it and sells the result under a closed source license... how the f do you get those bugfixes and improvements back into your own program now... they're under absolutely NO obligation to put their improvements back into the common pot. Those who persist in advocating the BSD license are fools... why else do you think Microsoft loves BSD and hates the GPL so much...
Most companies are interested in remaining competitive, in having their product dominate or at least compete in the market. Note that it is the success of their product they are interested in, not their technology; they would rather their technology remain in their product alone, instead of flourishing in the hands of their competition. To secure this technological edge, they need to release their work in a closed-source or otherwise semi-free or non-free form. Otherwise they will only make money on support and not on licensing of technology, which for many companies would be a ruinous drop in revenue.
Furthermore, for internal products, most companies would rather have the option of re-using the libraries or modules in proprietary outside products should they prove useful. For this reason, they would rather not encumber any of their IP with GPL restrictions. Thus Microsoft hates the GPL, or at least refuses to use GPLed libraries, for fear of encumbering useful code, thereby wasting programmer time on software which cannot be profitably released.
The upshot is that even an excellent piece of GPLed software will be passed up in favor of an inferior internal rewrite or BSD-licensed piece. Look what happened to Mac OS X: Apple could not have incorporated a Linux kernel or API the way they incorporated the FreeBSD API, because it is not free enough to be linked with Mach or with their proprietary improvements.
Even within Open Source projects, the encumbering nature of the GPL is a problem: as Mozilla is available under a BSD license as well as GPL, Konqueror can take patches from it but not vice-versa.
I certainly like the GPL, and contribute to GPL projects, but I recognize that in many cases, a greater gain for the universe of software (free and non-free) can be had by releasing software under a BSD license or even into the public domain. The best of both worlds is available, too: one can release code into the public domain or under a BSD license, and also link it into a GPL project under the GPL.
The goal of the GPL is to make all software free.
The goal of the BSD license is to make all software better.
garcia@shitbox:~$ sudo su
shitbox:/home/garcia#
sudo -s
Padlock is just security function acceleration. It makes existing DRM faster, but doesn't really enable any new kind of DRM.
Meh. AppleWorks is a Bad Carbon Port, which is shameful coming from Apple. Its user interface is not consistent with the rest of OS X, even with other Carbon apps. And the text rendering is pretty terrible. I'd rather use TextEdit. Or TeX. And that's saying a lot.
the act of going back in time and being able to pass information when you do it completly negates cause and effect.
"Cause and effect" is not necessarily a fundamental law of the universe, but rather a convenient notion from our perspective (going in the same direction in time as entropy decreases).
At least for certain small systems, it has been proved that objects travelling back in time cannot render the system inconsistent, that is, there is no grandmother paradox. One such (toy) system is a pool table where the balls are particles and the pockets are wormholes. A ball coming out of a pocket cannot prevent itself from entering the corresponding pocket in the first place.
Also, passing information backward in time, while it hasn't been shown experimentally (yet?) is not a completely insane notion. Quantum erasure experiments appear to do something very much like that (send information outside its own light-cone), but as far as I know in the current ones, sending the information back to within its own light-cone tends to collapse the system.
Then that negates free will.
No it doesn't. Would time travel negate free will? Suppose someone could know what you were going to do, before you did it, because they'd seen it already through their future-o-scope. Does that negate your free will?