> But the DOS goes away with the Challenge Response mode!
Perhaps you missed the point of the posting
that you replied too... in cases where CR
more is not possible, the DoS issue exists.
For example, there are people who cannot
use the commercial ssh (due to cost);
do not want to use the commercial ssh
(due to flaws in the product); or operating
in a non-SSH environment.
There are applications that were not designed
to use CR.
There are user interface situations where CR
is not available or desirable.
CR is better, but not always possible
(for good or poor reasons).
The point is in places were CR is not possible
in any form,
the DoS flaw was exists.
Unless CRYPTOcard fixed it in the lest year or
so, it still exists for a number of configurations
and applications.
Even worse than the CRYPTOcard DoS flaw was how
CRYPTOcard responded to the issue.
We really DID want CRYPTOcard to win, but
we were unable to get CRYPTOcard to respond
effectively.
It was too bad.
In many ways CRPTOcard had the better product.
One important aspect of token selection
is how well they survive hard conditions.
Sure you may have a token that works in
your OpenSource environment, but will it
continue to work in the physical environment?
Your users will, hopefully by mistake,
subject your tokens to abuse.
To see how the tokens held up we created
a torture test that simulated the real
world token stress.
We subjected several copies of
each vendor's token to 3 cycles
of the following test:
Day 1: Send your token thru a typical laundry
wash cycle and tumble dry cycle.
Day 2: Leave the token on the dash of
your card
for 1/2 day (if on a warm day) or subject
the token to a hair dryer on a warm
setting at close range
for 15 minutes.
Day 3:
Leave the token in your back packet and
go about your normal day routine (sit on it).
Day 4:
Place the token freezer
(to simulate it being left out in the cold)
overnight.
Day 5:
Take it to meetings and fidget with it
(in the on state if applicable).
If it has keys or buttons, poke at them.
Mildly flex it.
Or, if you watch TV/videos, play with it while
you veg-out.
The SecureID tokens had 100% failures.
Many of them failed the laundry test, sometimes
on the 1st try.
Most of the keychain FOBs cracked around
the chain hole.
We had 100% failure on these tokens.
Some CRYPTOcard non-FOB tokens
(the credit card sized ones) failed the
freezer test on the 1st try.
Some non-FOB tokens momentarily
lost their battery
during the heat test and had to be
re-initialized.
About 2 in 5 passed.
Some CRYPTOcard FOB tokens failed the wash
test after the 2nd week.
Opening them up showed that water leaked...
we presume that the seal cracked during the
1st week.
About 3 in 5 passed.
All of the Safeword non-FOB (credit card sized)
tokens passed.
All of the Dallas-Semi iButtons passed.
Of 3 other vendors, all of whom are no longer
in business, 1 passed 100% and 2 failed 100%.
Initially CRYPTOcard looked like a wonderful
solution. I was forced to reject them because
of a design flaw back in 2000.
CRYPTOcard is really a challenge-response (CR) token.
There are several security advantages to CR.
Unfortunately many protocols do not support CR
at all, or only in certain instances.
Out of the box implementations of ftp, ssh,
rlogin are examples of non-CR based protocols.
Sure, you can modify them to do CR but do you
want to / can you do this?
Let us assume the answer is no for
any number of reasons/excuses:
``I don't want
to modify / I cannot modify (someone else
owns/admins the box) / I don't know how to
modify / I don't have the time to modify
and maintain /...'. What can you do?
No problem, you simply
operate in sequence mode.
In sequence mode, CRYPTOcard hides the CR.
When the CRYPTOcard is initialized, a
shared secret is established between their
easyRADIUS server and your token.
Let us call this secret N.
When you 1st use the card acts as if a
challenge of f(N+1) was given.
There is no visible challenge - the card
simply assumes what the challenge is and
displays the response.
Your CR unfriendly protocols and applications
work nicely.
The next time you login, the card and
easyRADIUS server assume f(N+2) is used.
So what happens if your CRYPTOcard and your
easyRADIUS server get our of sync?
Say you start the login process, operate
your token but get distracted with a phone
call before you can login?
After you call you try to login again.
Now your token is at f(N+m+1) and the
easyRADIUS (for your token) is at f(N+m).
No problem, there is a ``grace window''.
As long as the value you supply is within
a few steps your token AND it is not
prior to any previously used value you are
allowed in.
In our phone distraction example the
easyRADIUS server would jump ahead to
f(N+m+1).
The next token operation would occur with
f(N+m+2).
If your token and the easyRADIUS server
get too far out of sync, you will need to
have a token admin re-sync the token.
Until the token is re-synced, you are
out of luck.
So what was the flaw in 2000 that
eliminated CRYPTOcard from consideration?
Well whenever someone attempts to login
to your account, the easyRADIUS increments
the secret value!
Here is how the CRYPTOcard DoS works:
Attempt to login to a card user's account
a number of times.
It doesn't matter what password you give,
just fail a bunch of times.
Before the DoS the poor users token
and easyRADIUS server were at f(N+m).
After the DoS the easyRADIUS server is
at f(N+m+several)... too far out of
the ``grace window'' to be used.
The user is locked out until the the
token and easyRADIUS are resynced!
This flaw was presented to CRYPTOcard.
At first they didn't seem to understand.
Next they didn't believe it.
When it was demonstrated to them they
responded that they ``never heard of
anyone attempting to lock out an account
in that way.''.
I responded that system crackers and
script-kids try dictionary attacks...
sometimes attempting many 1000's of logins
just to see if the account has a easy password.
That folks looking for an open ftp server
sometimes bang away at an ftp password
for a while.
That web crackers will launch password
guessing attacks as well.
If ANY of those (plus others) were to
(unsuccessfully) attempt to login to your
account, YOU LOSE!
To be fair CRYPTOcard, after some effort
said they were going
to ``look into the problem''.
They may have fixed it by now.
Their work-a-round may be OK,
or it may not-good-enough
(you can't fix it be simply making the window
wider) or it may be flawed/insecure (allowing
replay attacks or CR guessing).
There are a number of wrong ways to fix it,
there are a number of ways that seem OK but
contain a subtile flaw.
Hopefully the CRYPTOcard folks did it
the right way.
Before I were to deploy CRYPTOcard
I would take a hard look at the DoS
issues related to their tokens in non-challenge
response environment... or commit to
only doing CR logins for every device
in question (if that is possible).
Typically each year we find that at least
1 entry that will
cause someone's C compiler to dump core
or go haywire.
Over the years, gcc has survived the best.
It has chucked core cookies on a few entries,
but not nearly as often as some of the
commercial C compilers.
If a winning entry does cause problems for
somebody's C compiler, we usually file a
bug report.
They may not be pleased with the code sample,
but that is the break;'s.:-)
p.s. The entry that broke causde the most
problems on the most platforms was the
1988 Best of show.
Not only did it crash a few C
pre-processors, it cause one system to turn
casters-up when it ran out of swap space!
Yes, your
1990 Best Language Tool was an outstanding entry. It was one of several of
outstanding wins that I have had the
pleasure of judging over the years.
However,
the greatest and longest laugh at a IOCCC BOF
occurred when I presented your
1998 Best abuse of the rules.
For those you were not there, his entry
consisted of a single, simple Un*x portable
line of code:
#include "/dev/tty"
That Truely twisted entry is listed
in my top 10 all time best IOCCC progs.
Leading scientist saying that Fusion power is
'within reach' in the next decade
It all depends on who this 'scientist' is.
When I worked on a fusion power project
in the late 70's we had two major
milestones:
Physicist breakeven: When the fusion power plant
produces more power than is required to build
and operate it.
Engineering breakeven: When the fusion power plant
produces more money than it takes to build and
operate it.:-)
Even back in the 70's people said that ``Success was
just around the corner''.
For years now,
predictions almost always said
''demo in the
next 10 years with commercial plants 10 years
after that''.
You will know that significant process has been made
when that '10' is reduced to a number such as
'5' or smaller.
It is my guess that in 10 years they will start
saying success is slightly less than 10 years
away.
At that rate by 2035 hopes and reality will meet.
A few years back, while playing around with a
highly directional receiver (phase-shift antenna array)
we were able to clearly ``hear'' the radio emissions from
one of our keyboards at a distance of about 1/4 mile.
Each key presented a unique waveform on an oscilloscope.
If I were going to log keystrokes, I would be tempted to
use the parked van approach.
I'm sure with a reasonable budget and access to better
technology, reading keystrokes would be easy
at moderate distances.
And how the disclaimers:
The list above by no means complete.
The browers above were listed in j-random order.
Some browsers are in early alpha stage, some in Beta and others
are in full release.
Some of the browsers may suck, some are OK and some are good.
Your mileage may vary.
Sorry If I left out your favorite browser.
IE was left off the list for obvious reasons.
Good while supply lasts or until Bill Gates takes over.
I'm not a member of the FCIA.
Void where cast as (void).
a cryptographic
string should be indistinguishable from
random data.
Most cyphers are pseudo-random to some
degree.
Nearly all of them will pass various
statistical tests for randomness and
entropy measurements to some degree.
How well they pass is another matter
and it something on which one can
construct an entropy signature.
In Steganography you want your plaintext
to appear statistically as identical as you
can to your chaff / image / noise stream.
Creating a good match is difficult.
Hany Farid, for example, is attempting to
use various tests to identify plaintext
within an image.
With the right tests
one should help
identify which is noise and which is plaintext.
To combat Farid's method one needs a
cryptographically strong PRNG or true
random source.
Then bias the output in a fashion that
is identical to the noise (big handwave
here... this is hard to do well).
Finally mix the plaintext with the
biased stream and inject it into the
noise in a way that is known to you
and the receiver.
I have yet to come across something that could
generate as random a number in as closed a space...
The next generation
LavaRnd
will give you that in a very compact space,
using a patent-free
algorithm and open source demo software.
Final hacking is going on now.
Code completion and demos will soon follow.
Paper to be published sometime after...
p.s.: Gotta love moderating. My original article
stays a 1 and your reply gets a 2.
Both are directly on topic while some joke
gets a 4.
Maybe moderation scores are a good source
of random noise?:-)
random noise detection: entropy signature analysis
on
Battling Steganography
·
· Score: 1
This is nothing new... well not brad new. One
must use a method known as entropy signature
analysis.
The 1 minute explanation of entropy signature
analysis
is that it seeks to quantify in
R^(n+m)
space,
the
statistical properties of a stream of data
by applying
n
statistical tests to the data.
How well or poorly the data passes these tests
helps identify the method of generation.
With the right tests and the same data one can
distinguish between DES CBC and RC2 for example.
With enough traffic, given two different streams
of similar data (say encrypted human language
text) one can also
distinguish between cyphers as well.
Mixing a 3DES stream with random bits can be
unmixed if the random generator is not
cryptographically strong.
For example if you use
Linux's/dev/random to mix
random data with cryphertext, you can be
undone with sufficient entropy signature
analysis.
Mixing plaintext with random bits makes the
cracking job easier.
Using something non-random such as an image
makes the job even easier.
To do Steganography well, you need a
cryptographically strong random or
pseudo-random number generator,
a good mixing function and method
to transform your hidden text into a
sufficiently similar data stream
so that its entropy signature is similar
to that of your base pattern / image /
noise stream.
Doing Steganography really well is hard.
Reducing the signal to noise ratio
and keeping the amount of signal text
to a minimum also helps, BTW.
In case anyone was wondering why I spend
time working with LavaRnd, cryptographically
strong PRNGs, Lava Lite
® lamps and other random oddiments...:-)
Mann arguments found wanting 3 out of 3 times
on
Taming the Web
·
· Score: 1
Charles Mann's 1st false argument:
``The Internet Is Too International to Be Controlled''
Mann then goes on to describe some theory about offshore outlaws always being on the run from the law.
This argument makes a number of false assumptions:
The host country has the same laws as the people seeking to stop the activity.
Not everyone has a DCMA.
Not everyone has the same patent laws.
Not everyone has the same laws!
The host country will be happy to help the foreigners obtain justice.
In some cases, being chased by country ``X'' is a badge of honor that grant you protection in country Y.
Even when international treaties are signed, it can be nearly impossible for a foreigner to enforce them.
Ask anyone who is stuck in an international custody battle how easy it is to obtain justice overseas.
Ask anyone who seeking the recovery of stolen property.
It is hard enough to asset your rights in a friendly foreign country when dealing with kids or physical objects... let alone trying to deal with cyber-space objects.
All nations will be willing to target local servers.
There as a number of nations that would like to become the ``Swiss banking'' center for cyberspace.
They see value in shielding cyberspace activity within their country.
These locations are competing for such offshore server locations.
Everyone has the energy and ability to pursue legal action in every corner of the world.
Sorry, some might, but not everyone
Mann also uses some bogus example where the foreign-hosted server winds up in the US near the RIAA headquarters:
Well Duh!
If you are going to break US laws, you might want to host your stuff outside the US!
Mann also offers some US-centric view that a foreign installation will be sub-standard.
He says ``most out-of-the-way places don't have the requisite equipment'':
Sorry Charley, there are a number of out of the way places that have excellent facilities and/or are building them.
Why?
Because these places have found that beings money into their economy, for one thing!
In addition, in terms of connectivity: the exist places where major trans-ocean cables ``come up for air'' on their island that have fantastic connectivity.
Because these places that have created cyber-parks and server-farms (see the shielding cyberspace example above).
Perhaps Mann should have said:
``The Net's international nature makes it difficult to control''
Charles Mann's 2nd false argument:
``The Net is too Interconnected to control''
Mann brings out a particular peer-to-peer response to Napster.
He then shows how its digital traffic signature allows it to be identified, targeted, and stopped.
Well if Mann were to use a creditable protocol and service design, his argument won't sound so legitimate!
You even acknowledge this fact by talking about an ``up and coming bleeding-edge solution'' has a work-a-round and then dismiss it because it is not ready.
Sorry Charley: there are solutions with various levels of sophistication that exist today:
HTTP/IP and HTTPS/IP
Where TCP/IP traffic hides and tunnels as HTTP or HTTPS protocols.
Zero-Knowledge networks
With true anonymous network activity.
Entropy signature mimic proxies
Proxies that convert a TCP/IP connection into a data stream that mimics the entropy signature analysis of another data stream.
Perhaps Mann should have said:
``True decentralized communication combined with cryptographically strong anonymous and pseudo-anonymous protocols will make the Net very difficult to control.''
Charles Mann's 3rd false argument:
``The Net it too filled with hackers to control''
Mann constructs a world where hardware chip ID and built-in copy protection hardware make it impossible for a hacker to do what they want.
Mann presents this idea is that hardware can make it impossible for software to do what it wants.
Hardware can make it annoying for software. Nevertheless, your argument assumes that:
The hardware copy protection system cannot be defeated.
Look at the clipper.
Look at Cell phones.
Look at WEP.
How many examples does one have to give in order to cast doubt on such schemes?
People will only have access to hardware copy protected systems.
There is an awful lot of non-copy protected hardware out there already.
In addition, if the user is motivated to extract the data, will they not be motivated to buy something on the user market?
Won't some manufactures be interested in selling equipment that can be easily modified or configured by the end user to defeat the copy protection?
(There are in the cases of DVD and DAT hardware, for example).
Hackers won't be cleaver enough to defeat the copy protection system.
Heck, just having a copy protection system is an invitation for someone to try to break it.
Its existence alone presents a challenge that some hackers love to tackle.
End users won't expend effort to get around copy protection schemes.
Just check out the conditions on the Sat TV or Cable TV market.
Do you know how many sports fans buy equipment on a neighboring country just to get around local broadcast blackouts?
BTW Mann: In argument #2 you dismissed a potential peer-to-peer work-a-round as not being ready yet.
However, in argument #3 you present a future world with lots of hardware copy protection enabled computers.
You don't get to play the future-VS-now argument both ways!
Perhaps Mann should have said:
``The Net will remain the heart of a back-and-forth battle between schemes to restrict information and methods to pry it lose.''
Sorry Charley, you present 3 losing arguments that are full of holes.
Maybe if you had used something along the lines of the ''should have said'' arguments, you would have presented a more realistic thesis and your arguments would have been stronger.
Then again, you would have to have completely re-written your article.
Speaking as the 1st person to ever engage
in legal action to enforce a GPL (against
an employer who wanted to violate a GPL
back in 1989), I can say with reasonable
certaintly:
The GPL is enforceable!
#include <the_following_disclaimers.h>:
under US law
in the general case
results will depend on the
quality of your legal team and the
quantity of your $'s...
while copyright laws have changed since
1989, I recently received advice which
suggested that these changes have not
impacted the GPL enforceability
IANAL...:-)
We won.
The employer was forced to obey the GPL.
We even got my next employer to cover
our legal bills... but that is a story
for another time that is
best told over a good bottle of port.:-)
Not only are the employee home pages are
going away, but so are the other services
that are co-hosted on
reality.
The classic
lavarand
site (random numbers via Lava Lite Lamps),
which is hosted on reality, is going
away as well.
We are planning to bring on-line a and improved
version of
LavaRnd
(open sourced and patent-free)
at
www.LavaRnd.org
hopefully before reality goes away.
I went to microsoft's web site and used their
'contact us' feedback form to send them the
following letter:
Dear Steve Ballmer,
In recent interview with the Sun-Times you state:
> Open source is not available to commercial companies. The way the license
> is written, if you use any open-source software, you have to make the
> rest of your software open source.
I do not know if this is an accurate quote, but it is consistent with
statements you have made in the past.
Re: Open source is not available to commercial companies.
Why do you persist in repeating statements that are clearly not true?
You do know that MANY commercial companies are using open source.
So clearly open source is available to them.
Re:... if you use any open-source software, you have to make rest of your software open source.
You also know that many commercial companies make use of open
source products and yet they do not forced to release rest of
your software. Had IBM been forced to release all of its code?
Has Netscape? Has Sun? Has... You know the answer is NO.
Why are you persist on making blatantly false and defamatory statements
about open source?
When I hit SUBMIT, this was Microsoft's reply:
Feedback.asp - setData() - Error: Update failed: Code: 500, Desc: SetDataError - Cannot insert
the value NULL into column 'FeedbackLogID', table 'CURD.dbo.FeedbackLog'; column does not
allow nulls. INSERT fails.
Russell H. Falconer
212.408.2564
FAX 212.705.5020
russell.falconer@bakerbotts.com
30 ROCKEFELLER PLAZA 44TH FLOOR
NEW YORK, NEW YORK
Dear Mr. Falconer,
This letter is in response to your "cease and desist" letter to Mr. Templeton dated April 9, 2001.
I am neither associated with the netfunny.com web site nor do I read its associated newsgroup rec.humor.funny. While I personally know Mr. Templeton and can vouch for his outstanding commitment to 1st amendment principles; I alone am writing the letter.
I am very familiar with the technology used over Usenet and on the web, having been one of many people who helped in its creation. I am very proud of role that this technology has played in the exercise of free expression throughout the Internet. While I do not always agree with the content, I do defend their right of free expression.
From the tone of your letter your client (MasterCard International) appears to take their issue seriously, otherwise they would not have instructed you to submit such a letter and incur the legal costs of its processing. I want you and your client to understand that I take threats to the freedom of expression seriously as well.
We all have certain rights. However you and your client apparently believe you have the right to intimidate others who are simply exercising their own constitutionally protected rights. The exercise of rights sometimes comes with consequences: This letter is one of YOUR consequences. I hereby am "creasing and desisting" the use your client's services until such time as you retract the legal threats made in the above-mentioned letter.
The lack of new purchases from my account may do little to persuade your client from their present course of action. However through the use of the same technology that you and your client are attacking, I may be able to encourage others to do the same.
Maybe someone should just tell
them about OpenBSD, save some time and
money.
Remember that DARPA resources can promote development
an improvements in operating systems. After all
that is in part how BSD came into existence
in the first place!
Much of the OpenBSD code came about as a
direct or indirect result from DARPA efforts
(via CSRG and friends).
A fair amount BSD code DARPA helped fund
found its was into the GNU and
Linux efforts as well.
If DARPA wants to fund more research
and development let them!
Slashdot Mirror
Whole countries? Liechtenstein or Vatican City: easy. Russia or Canada: not so easy. :-)
Perhaps you missed the point of the posting that you replied too ... in cases where CR
more is not possible, the DoS issue exists.
For example, there are people who cannot
use the commercial ssh (due to cost);
do not want to use the commercial ssh
(due to flaws in the product); or operating
in a non-SSH environment.
There are applications that were not designed
to use CR.
There are user interface situations where CR
is not available or desirable.
CR is better, but not always possible (for good or poor reasons). The point is in places were CR is not possible in any form, the DoS flaw was exists. Unless CRYPTOcard fixed it in the lest year or so, it still exists for a number of configurations and applications.
Even worse than the CRYPTOcard DoS flaw was how CRYPTOcard responded to the issue. We really DID want CRYPTOcard to win, but we were unable to get CRYPTOcard to respond effectively. It was too bad. In many ways CRPTOcard had the better product.
Your users will, hopefully by mistake, subject your tokens to abuse. To see how the tokens held up we created a torture test that simulated the real world token stress. We subjected several copies of each vendor's token to 3 cycles of the following test:
The SecureID tokens had 100% failures. Many of them failed the laundry test, sometimes on the 1st try. Most of the keychain FOBs cracked around the chain hole. We had 100% failure on these tokens.
Some CRYPTOcard non-FOB tokens (the credit card sized ones) failed the freezer test on the 1st try. Some non-FOB tokens momentarily lost their battery during the heat test and had to be re-initialized. About 2 in 5 passed.
Some CRYPTOcard FOB tokens failed the wash test after the 2nd week. Opening them up showed that water leaked ...
we presume that the seal cracked during the
1st week.
About 3 in 5 passed.
All of the Safeword non-FOB (credit card sized) tokens passed.
All of the Dallas-Semi iButtons passed.
Of 3 other vendors, all of whom are no longer in business, 1 passed 100% and 2 failed 100%.
CRYPTOcard is really a challenge-response (CR) token. There are several security advantages to CR. Unfortunately many protocols do not support CR at all, or only in certain instances. Out of the box implementations of ftp, ssh, rlogin are examples of non-CR based protocols. Sure, you can modify them to do CR but do you want to / can you do this?
Let us assume the answer is no for any number of reasons/excuses: ``I don't want to modify / I cannot modify (someone else owns/admins the box) / I don't know how to modify / I don't have the time to modify and maintain / ...'. What can you do?
No problem, you simply
operate in sequence mode.
In sequence mode, CRYPTOcard hides the CR. When the CRYPTOcard is initialized, a shared secret is established between their easyRADIUS server and your token. Let us call this secret N. When you 1st use the card acts as if a challenge of f(N+1) was given. There is no visible challenge - the card simply assumes what the challenge is and displays the response. Your CR unfriendly protocols and applications work nicely. The next time you login, the card and easyRADIUS server assume f(N+2) is used.
So what happens if your CRYPTOcard and your easyRADIUS server get our of sync? Say you start the login process, operate your token but get distracted with a phone call before you can login? After you call you try to login again. Now your token is at f(N+m+1) and the easyRADIUS (for your token) is at f(N+m). No problem, there is a ``grace window''. As long as the value you supply is within a few steps your token AND it is not prior to any previously used value you are allowed in. In our phone distraction example the easyRADIUS server would jump ahead to f(N+m+1). The next token operation would occur with f(N+m+2).
If your token and the easyRADIUS server get too far out of sync, you will need to have a token admin re-sync the token. Until the token is re-synced, you are out of luck.
So what was the flaw in 2000 that eliminated CRYPTOcard from consideration? Well whenever someone attempts to login to your account, the easyRADIUS increments the secret value!
Here is how the CRYPTOcard DoS works: Attempt to login to a card user's account a number of times. It doesn't matter what password you give, just fail a bunch of times. Before the DoS the poor users token and easyRADIUS server were at f(N+m). After the DoS the easyRADIUS server is at f(N+m+several) ... too far out of
the ``grace window'' to be used.
The user is locked out until the the
token and easyRADIUS are resynced!
This flaw was presented to CRYPTOcard. At first they didn't seem to understand. Next they didn't believe it. When it was demonstrated to them they responded that they ``never heard of anyone attempting to lock out an account in that way.''. I responded that system crackers and script-kids try dictionary attacks ...
sometimes attempting many 1000's of logins
just to see if the account has a easy password.
That folks looking for an open ftp server
sometimes bang away at an ftp password
for a while.
That web crackers will launch password
guessing attacks as well.
If ANY of those (plus others) were to
(unsuccessfully) attempt to login to your
account, YOU LOSE!
To be fair CRYPTOcard, after some effort said they were going to ``look into the problem''. They may have fixed it by now. Their work-a-round may be OK, or it may not-good-enough (you can't fix it be simply making the window wider) or it may be flawed/insecure (allowing replay attacks or CR guessing). There are a number of wrong ways to fix it, there are a number of ways that seem OK but contain a subtile flaw. Hopefully the CRYPTOcard folks did it the right way.
Before I were to deploy CRYPTOcard I would take a hard look at the DoS issues related to their tokens in non-challenge response environment ... or commit to
only doing CR logins for every device
in question (if that is possible).
Larry Ellison? :-)
p.s. Speaking of twisted array references I like Korn's: 1987 Best One Liner:
Try to figure out what it does without compiling it first. Over the years I have not found very many people who could do it correctly the first time.
It compiles with out any special flags:
Hint: it does not work the same on a Microsoft based system. :-)
Over the years, gcc has survived the best. It has chucked core cookies on a few entries, but not nearly as often as some of the commercial C compilers.
If a winning entry does cause problems for somebody's C compiler, we usually file a bug report. They may not be pleased with the code sample, but that is the break;'s. :-)
p.s. The entry that broke causde the most problems on the most platforms was the 1988 Best of show. Not only did it crash a few C pre-processors, it cause one system to turn casters-up when it ran out of swap space!
FYI: This year we are allowing use of OpenMotif which should improve things for folks writing new X-Windows progs.
However, the greatest and longest laugh at a IOCCC BOF occurred when I presented your 1998 Best abuse of the rules. For those you were not there, his entry consisted of a single, simple Un*x portable line of code:
That Truely twisted entry is listed in my top 10 all time best IOCCC progs.(We gotta keep up with the code bloat like everyone else
(why 521? Well 521 is prime and 2^521-1 is a Mersenne prime and I like primes
It all depends on who this 'scientist' is. When I worked on a fusion power project in the late 70's we had two major milestones:
Even back in the 70's people said that ``Success was just around the corner''. For years now, predictions almost always said ''demo in the next 10 years with commercial plants 10 years after that''.
You will know that significant process has been made when that '10' is reduced to a number such as '5' or smaller. It is my guess that in 10 years they will start saying success is slightly less than 10 years away. At that rate by 2035 hopes and reality will meet.
I'd like to see something similar for the IIS developers along other selected members of Microsoft.
If I were going to log keystrokes, I would be tempted to use the parked van approach. I'm sure with a reasonable budget and access to better technology, reading keystrokes would be easy at moderate distances.
chongo () /\__/\
The article did not review a number of browsers. Here are a some more that you may want to try:
And how the disclaimers: The list above by no means complete. The browers above were listed in j-random order. Some browsers are in early alpha stage, some in Beta and others are in full release. Some of the browsers may suck, some are OK and some are good. Your mileage may vary. Sorry If I left out your favorite browser. IE was left off the list for obvious reasons. Good while supply lasts or until Bill Gates takes over. I'm not a member of the FCIA. Void where cast as (void).
Most cyphers are pseudo-random to some degree. Nearly all of them will pass various statistical tests for randomness and entropy measurements to some degree. How well they pass is another matter and it something on which one can construct an entropy signature.
In Steganography you want your plaintext to appear statistically as identical as you can to your chaff / image / noise stream. Creating a good match is difficult. Hany Farid, for example, is attempting to use various tests to identify plaintext within an image. With the right tests one should help identify which is noise and which is plaintext.
To combat Farid's method one needs a cryptographically strong PRNG or true random source. Then bias the output in a fashion that is identical to the noise (big handwave here ... this is hard to do well).
Finally mix the plaintext with the
biased stream and inject it into the
noise in a way that is known to you
and the receiver.
I have yet to come across something that could generate as random a number in as closed a space...
The next generation LavaRnd will give you that in a very compact space, using a patent-free algorithm and open source demo software. Final hacking is going on now. Code completion and demos will soon follow. Paper to be published sometime after ...
p.s.: Gotta love moderating. My original article stays a 1 and your reply gets a 2. Both are directly on topic while some joke gets a 4. Maybe moderation scores are a good source of random noise? :-)
The 1 minute explanation of entropy signature analysis is that it seeks to quantify in R^(n+m) space, the statistical properties of a stream of data by applying n statistical tests to the data. How well or poorly the data passes these tests helps identify the method of generation.
With the right tests and the same data one can distinguish between DES CBC and RC2 for example. With enough traffic, given two different streams of similar data (say encrypted human language text) one can also distinguish between cyphers as well.
Mixing a 3DES stream with random bits can be unmixed if the random generator is not cryptographically strong. For example if you use Linux's /dev/random to mix
random data with cryphertext, you can be
undone with sufficient entropy signature
analysis.
Mixing plaintext with random bits makes the
cracking job easier.
Using something non-random such as an image
makes the job even easier.
To do Steganography well, you need a cryptographically strong random or pseudo-random number generator, a good mixing function and method to transform your hidden text into a sufficiently similar data stream so that its entropy signature is similar to that of your base pattern / image / noise stream. Doing Steganography really well is hard.
Reducing the signal to noise ratio and keeping the amount of signal text to a minimum also helps, BTW.
In case anyone was wondering why I spend time working with LavaRnd, cryptographically strong PRNGs, Lava Lite ® lamps and other random oddiments ... :-)
- The host country has the same laws as the people seeking to stop the activity.
- The host country will be happy to help the foreigners obtain justice.
- All nations will be willing to target local servers.
- Everyone has the energy and ability to pursue legal action in every corner of the world.
Mann also uses some bogus example where the foreign-hosted server winds up in the US near the RIAA headquarters:Not everyone has a DCMA. Not everyone has the same patent laws. Not everyone has the same laws!
In some cases, being chased by country ``X'' is a badge of honor that grant you protection in country Y. Even when international treaties are signed, it can be nearly impossible for a foreigner to enforce them. Ask anyone who is stuck in an international custody battle how easy it is to obtain justice overseas. Ask anyone who seeking the recovery of stolen property. It is hard enough to asset your rights in a friendly foreign country when dealing with kids or physical objects ... let alone trying to deal with cyber-space objects.
There as a number of nations that would like to become the ``Swiss banking'' center for cyberspace. They see value in shielding cyberspace activity within their country. These locations are competing for such offshore server locations.
Sorry, some might, but not everyone
Well Duh! If you are going to break US laws, you might want to host your stuff outside the US!
Mann also offers some US-centric view that a foreign installation will be sub-standard. He says ``most out-of-the-way places don't have the requisite equipment'':
Sorry Charley, there are a number of out of the way places that have excellent facilities and/or are building them. Why? Because these places have found that beings money into their economy, for one thing! In addition, in terms of connectivity: the exist places where major trans-ocean cables ``come up for air'' on their island that have fantastic connectivity. Because these places that have created cyber-parks and server-farms (see the shielding cyberspace example above).
Perhaps Mann should have said:
Charles Mann's 2nd false argument: Mann brings out a particular peer-to-peer response to Napster. He then shows how its digital traffic signature allows it to be identified, targeted, and stopped.Well if Mann were to use a creditable protocol and service design, his argument won't sound so legitimate! You even acknowledge this fact by talking about an ``up and coming bleeding-edge solution'' has a work-a-round and then dismiss it because it is not ready. Sorry Charley: there are solutions with various levels of sophistication that exist today:
Where TCP/IP traffic hides and tunnels as HTTP or HTTPS protocols.
With true anonymous network activity.
Proxies that convert a TCP/IP connection into a data stream that mimics the entropy signature analysis of another data stream.
Perhaps Mann should have said:
Charles Mann's 3rd false argument: Mann constructs a world where hardware chip ID and built-in copy protection hardware make it impossible for a hacker to do what they want. Mann presents this idea is that hardware can make it impossible for software to do what it wants.Hardware can make it annoying for software. Nevertheless, your argument assumes that:
- The hardware copy protection system cannot be defeated.
- People will only have access to hardware copy protected systems.
- Hackers won't be cleaver enough to defeat the copy protection system.
- End users won't expend effort to get around copy protection schemes.
BTW Mann: In argument #2 you dismissed a potential peer-to-peer work-a-round as not being ready yet. However, in argument #3 you present a future world with lots of hardware copy protection enabled computers. You don't get to play the future-VS-now argument both ways!Look at the clipper. Look at Cell phones. Look at WEP. How many examples does one have to give in order to cast doubt on such schemes?
There is an awful lot of non-copy protected hardware out there already. In addition, if the user is motivated to extract the data, will they not be motivated to buy something on the user market? Won't some manufactures be interested in selling equipment that can be easily modified or configured by the end user to defeat the copy protection? (There are in the cases of DVD and DAT hardware, for example).
Heck, just having a copy protection system is an invitation for someone to try to break it. Its existence alone presents a challenge that some hackers love to tackle.
Just check out the conditions on the Sat TV or Cable TV market. Do you know how many sports fans buy equipment on a neighboring country just to get around local broadcast blackouts?
Perhaps Mann should have said:
Sorry Charley, you present 3 losing arguments that are full of holes. Maybe if you had used something along the lines of the ''should have said'' arguments, you would have presented a more realistic thesis and your arguments would have been stronger. Then again, you would have to have completely re-written your article.
Better luck next time Charley!
Speaking as the 1st person to ever engage in legal action to enforce a GPL (against an employer who wanted to violate a GPL back in 1989), I can say with reasonable certaintly:
#include <the_following_disclaimers.h>:- under US law
- in the general case
- results will depend on the
quality of your legal team and the
quantity of your $'s
...
- while copyright laws have changed since
1989, I recently received advice which
suggested that these changes have not
impacted the GPL enforceability
- IANAL
... :-)
We won. The employer was forced to obey the GPL. We even got my next employer to cover our legal billsThe classic lavarand site (random numbers via Lava Lite Lamps), which is hosted on reality, is going away as well.
We are planning to bring on-line a and improved version of LavaRnd (open sourced and patent-free) at www.LavaRnd.org hopefully before reality goes away.
When I hit SUBMIT, this was Microsoft's reply:
FAX 212.705.5020
russell.falconer@bakerbotts.com
30 ROCKEFELLER PLAZA 44TH FLOOR
NEW YORK, NEW YORK
Dear Mr. Falconer,
This letter is in response to your "cease and desist" letter to Mr. Templeton dated April 9, 2001.
I am neither associated with the netfunny.com web site nor do I read its associated newsgroup rec.humor.funny. While I personally know Mr. Templeton and can vouch for his outstanding commitment to 1st amendment principles; I alone am writing the letter.
I am very familiar with the technology used over Usenet and on the web, having been one of many people who helped in its creation. I am very proud of role that this technology has played in the exercise of free expression throughout the Internet. While I do not always agree with the content, I do defend their right of free expression.
From the tone of your letter your client (MasterCard International) appears to take their issue seriously, otherwise they would not have instructed you to submit such a letter and incur the legal costs of its processing. I want you and your client to understand that I take threats to the freedom of expression seriously as well.
We all have certain rights. However you and your client apparently believe you have the right to intimidate others who are simply exercising their own constitutionally protected rights. The exercise of rights sometimes comes with consequences: This letter is one of YOUR consequences. I hereby am "creasing and desisting" the use your client's services until such time as you retract the legal threats made in the above-mentioned letter.
The lack of new purchases from my account may do little to persuade your client from their present course of action. However through the use of the same technology that you and your client are attacking, I may be able to encourage others to do the same.
Signed,
Landon Curt Noll
Sunnyvale, CA
cc: Master Card International /.
+1 914.249.2000
Fax: 202.414.8010 (public affairs)
cc:
Remember that DARPA resources can promote development an improvements in operating systems. After all that is in part how BSD came into existence in the first place!
Much of the OpenBSD code came about as a direct or indirect result from DARPA efforts (via CSRG and friends). A fair amount BSD code DARPA helped fund found its was into the GNU and Linux efforts as well. If DARPA wants to fund more research and development let them!