Thanks for the link Steve. Are you affiliated with RSA? RE: Step #4 "The laptop's hard drive was destroyed". Cute touch, but I can't help wondering why they just don't instead temporarily remove the laptop's hard drive, boot and run the test from a CD, and save hundreds of dollars per contest?
OmniGeek asked: (Why does a home-network router need a clock so badly, anyway? It's not like they do useful remote logging or anything...)
As the article points out, some uses of the time-of-day clock "include logging, policy scheduling, and email notifications".
While it is true that "only a small subset of the customers are even aware of the time-related features of these products", I personally find some of them useful.
The feature wasn't the problem, the problem was its implementation.
I became a Mac user only after Apple moved to MacOS X - a modern, UNIX-based OS.
I have neither the desire, the time, nor the inclination to learn anything about Mac OS 9, 8, or earlier versions. I avoided these for many years ( because they were unstable, unpreemptive, un-interoperable, and unneccessary for an ungraphic artist like myself.) and it is even less neccessary for me to learn them now that they are legacy.
I love MacOS X. It gives me a great, pretty, powerful, easy-to-use environment that I don't have to think about 95% of the time, with the option of a CLI terminal/shell for those 5% of the times when I do. It would be fun to learn more about MacOS X, which is - as you know - a very very different OS than its predecessors.
Won't someone write an indepth book on Mac OS X that doesn't contain uneccessary and often confusing references to obsolete virgins I know little (and care less) about.
So where's a guy go to get...
on
Solar Surgery
·
· Score: 2
Yeah, you are correct. I didn't read his post before submitting mine.
Last night I wrote some (rough) C code simulating my method. It took something like 500 million days! If I have time I'll try the list method and the other methods mentioned in some of the recent posts that are much much more efficient, and also clean up the code and post it.
I suspect that some of the better ideas will actually get the prisoners out before one of them dies (which could kill them all!).
I have a different solution to the 100 Prisoners and a Lightbulb problem:
At the meeting the prisoners each get assigned a unique number Px where x=0-99. Prisoners carefully count the number of days since the meeting. On any given day, let n be [(number of days since meeting) MOD 100]. Each prisoner simply follows the rule that he turns/leaves the light on iff he knows for certain that every prisoner up to including
P(n) has been to living room. How does he know? Three ways:
It is day 1 and he is Prisoner 1 (trivial).
he has noted the information previously. For example, prisoner 86 might have previously entered on day 32 and noticed the light on. He knows, therefore, that prisoners 0-31 have all been there. He can safely turn on light on any day up to including day 31.
It is his (that prisoners')day (i.e. n=x) AND the light was on when he came in. This last case is, of course, progress, as it allows him to signal to the following prisoner that everyone up to himself has been there.
So word will slowly get out that Prisoner 1 then 2 then 3 and so have been there till prisoner 99 finally arrives on day 99 and sees the light! He can then safely make the assertion that "We have all been here before!".
The question remaining, is "what the expected number of days for each of these solutions"?
You mentioned that the Distributed Folding Project takes care of user's privacy and security.
Any successful "master program", of course would have to do this as well. You mentioned that you "know a person who is in fact working on exactly such a piece of software".
Would you be so kind as to post a pointer if/when he/she publishes information on this.
Cheers!
Toronto screening (mod this up please)
on
Revolution OS
·
· Score: 1
I have contacted the producers about renting the movie for a screening in Toronto, Ontario, Canada, probably at the Bloor Theatre.
If you are interested in being notified when it will be playing here please send email to revolution@lowy.com. .
What if you don't know what you'll receive? A binary file?
Why assume that there is no structure to the messages? Require that all valid messages contain XML headers describing message number, bytes count, checksum, filename, etc. Are you worried that an adversary will send enough random messages to fake all the above and still get the checksum and byte counts correct? Ok, then add an arbitrarily large number of digits of pi till you are happy.
Can't the other party [include a checksum]?
No, not a valid one. The adversary doesn't know the OTP.
Is the index coming from the right source? The problem is still there i guess...
Nope. Let's say Bob receives an encrypted message claiming to use index nnnn. He XORs it with OTP nnnn and if the message does not decrypt to expected headers with valid checksum he simply rejects the message as bogus. The index does not have to be serial, by the way.
None of the issues you mentioned are disadvantages of One Time Pads (OTP):
how can the receiver of the message know whether the source of the original message is trully caming from the expect source, and not a hijacked source.
If the receiver can read the message he knows it came from the correct source. Any other message would "decrypt" to random bits (the OTP is random and unknown to man-in-middle). For total certainty one can include a checksum prior to encryption.
Even if parties have and infinite secuence of random pads, they can never know whcih ones the other party has already "wasted" in hijaked messages
You can overcome this easily by numbering the random pads, sending this index (in the clear) along with every encrypted message, and (of course) ensuring that you never reuse the pads by destroying them *immediately* after use.
The primary disadvantage of OTP remains the pad distribution problem.
CodeCon is being broadcast live from the DNA Lounge over streaming video.
They just announced Ryan at HavenCo has changed the password to the codecon.org server and conference organizers can no longer log in. They have setup a New Server for CodeCon which has updated info on the conference.
The source to the Freedom Network servers linked from this new server is now at Linux Fund. Yeah!
For those who prefer clicking to cut-and-pasting, the Steganography update is here.
I suspect there are several reasons why they haven't found any Stegonography in Usenet pictures:
Very few people find it necessary to hide information in Usenet.
Of those who might find it necessary, few actually have heard of Steganography and know how to use it.
Those who know enough about Stego have encypted their messages first; you won't find these with dictionary attacks - the method the article suggests they used on "suspicious" images.
It is impossible to differentiate between random numbers (noise) and strong encryption. Are there not places within certain images where low order bits have noise that is completely random and thus a perfect hiding place for encrypted messages?
This Article seems to suggest that it isn't possible to hide info in gifs such that it is undetectable and that more research should be done on JPEGs. Anyone know the state of the art on this?
Slashdot Mirror
Thanks for the link Steve. Are you affiliated with RSA? RE: Step #4 "The laptop's hard drive was destroyed". Cute touch, but I can't help wondering why they just don't instead temporarily remove the laptop's hard drive, boot and run the test from a CD, and save hundreds of dollars per contest?
So removing the Slashdot button from my bookmark bar might not be sufficient?
This 1927 gem of a video is a "must see" for anyone who has never used a rotary dial phone and for everyone who has!s e1927_256kb.mp4
http://www.archive.org/stream/HowtoUse1927/HowtoU
FWIW when I submitted this article I did so under the "United States" category. Not sure why the editor (Timothy?) changed it.
Hey Allerca,
If you can design a dog that doesn't crap please sign me up for one right now!
lowy
Alas, such stories don't get referenced by Yahoo! Finance and most SCO investors don't search Google News, (but should).
(Why does a home-network router need a clock so badly, anyway? It's not like they do useful remote logging or anything...)
As the article points out, some uses of the time-of-day clock "include logging, policy scheduling, and email notifications".
While it is true that "only a small subset of the customers are even aware of the time-related features of these products", I personally find some of them useful.
The feature wasn't the problem, the problem was its implementation.
http://action.eff.org/action/index.asp?step=2&item =2718
I became a Mac user only after Apple moved to MacOS X - a modern, UNIX-based OS.
I have neither the desire, the time, nor the inclination to learn anything about Mac OS 9, 8, or earlier versions. I avoided these for many years ( because they were unstable, unpreemptive, un-interoperable, and unneccessary for an ungraphic artist like myself.) and it is even less neccessary for me to learn them now that they are legacy.
I love MacOS X. It gives me a great, pretty, powerful, easy-to-use environment that I don't have to think about 95% of the time, with the option of a CLI terminal/shell for those 5% of the times when I do. It would be fun to learn more about MacOS X, which is - as you know - a very very different OS than its predecessors.
Won't someone write an indepth book on Mac OS X that doesn't contain uneccessary and often confusing references to obsolete virgins I know little (and care less) about.
SPF 15,000 Sunscreen??
Also, the first line should read "A pair of coders is now suggesting..." since 'pair' is singular.
Yeah, you are correct. I didn't read his post before submitting mine.
Last night I wrote some (rough) C code simulating my method. It took something like 500 million days! If I have time I'll try the list method and the other methods mentioned in some of the recent posts that are much much more efficient, and also clean up the code and post it.
I suspect that some of the better ideas will actually get the prisoners out before one of them dies (which could kill them all!).
At the meeting the prisoners each get assigned a unique number Px where x=0-99. Prisoners carefully count the number of days since the meeting. On any given day, let n be [(number of days since meeting) MOD 100]. Each prisoner simply follows the rule that he turns/leaves the light on iff he knows for certain that every prisoner up to including P(n) has been to living room.
How does he know? Three ways:
So word will slowly get out that Prisoner 1 then 2 then 3 and so have been there till prisoner 99 finally arrives on day 99 and sees the light! He can then safely make the assertion that "We have all been here before!".
The question remaining, is "what the expected number of days for each of these solutions"?
Antique clawfoot tub............$450
CD of the Wiener Philharmoniker playing Mozart's Requiem
A dozen or so candles $.....6
Time soaking in the tub *away* from video screens.... Priceless
Any successful "master program", of course would have to do this as well. You mentioned that you "know a person who is in fact working on exactly such a piece of software".
Would you be so kind as to post a pointer if/when he/she publishes information on this.
Cheers!
If you are interested in being notified when it will be playing here please send email to revolution@lowy.com.
.
Why assume that there is no structure to the messages? Require that all valid messages contain XML headers describing message number, bytes count, checksum, filename, etc. Are you worried that an adversary will send enough random messages to fake all the above and still get the checksum and byte counts correct? Ok, then add an arbitrarily large number of digits of pi till you are happy.
Can't the other party [include a checksum]?
No, not a valid one. The adversary doesn't know the OTP.
Is the index coming from the right source? The problem is still there i guess...
Nope. Let's say Bob receives an encrypted message claiming to use index nnnn. He XORs it with OTP nnnn and if the message does not decrypt to expected headers with valid checksum he simply rejects the message as bogus. The index does not have to be serial, by the way.
One time pads cannot (by themselves)...
Who said they have to be used by themselves?
how can the receiver of the message know whether the source of the original message is trully caming from the expect source, and not a hijacked source.
If the receiver can read the message he knows it came from the correct source. Any other message would "decrypt" to random bits (the OTP is random and unknown to man-in-middle). For total certainty one can include a checksum prior to encryption.
Even if parties have and infinite secuence of random pads, they can never know whcih ones the other party has already "wasted" in hijaked messages
You can overcome this easily by numbering the random pads, sending this index (in the clear) along with every encrypted message, and (of course) ensuring that you never reuse the pads by destroying them *immediately* after use.
The primary disadvantage of OTP remains the pad distribution problem.
The "Mictation Flex Rate"? The "Eyebrow Lift/Tongue Roll"?
wtf is "Mictation"?
Here is the Corante article.
"What we have done with PCs so far is not natural"
Couldn't agree with you more, Craig.
The cartoonist kicked the bucket,
The cartoonist kicked the bucket...
CodeCon is being broadcast live from the DNA Lounge over streaming video.
They just announced Ryan at HavenCo has changed the password to the codecon.org server and conference organizers can no longer log in. They have setup a New Server for CodeCon which has updated info on the conference.
The source to the Freedom Network servers linked from this new server is now at Linux Fund. Yeah!
I suspect there are several reasons why they haven't found any Stegonography in Usenet pictures:
- Very few people find it necessary to hide information in Usenet.
- Of those who might find it necessary, few actually have heard of Steganography and know how to use it.
- Those who know enough about Stego have encypted their messages first; you won't find these with dictionary attacks - the method the article suggests they used on "suspicious" images.
It is impossible to differentiate between random numbers (noise) and strong encryption. Are there not places within certain images where low order bits have noise that is completely random and thus a perfect hiding place for encrypted messages?This Article seems to suggest that it isn't possible to hide info in gifs such that it is undetectable and that more research should be done on JPEGs. Anyone know the state of the art on this?
What's next, the Groundhog Memo?
The Thanksgiving letter?
Inquiring minds want to know! :-)