Cryptography-Digest Digest #251, Volume #12 Thu, 20 Jul 00 06:13:01 EDT
Contents:
Re: News about quantum computer ("Peter Grotrian")
Re: RC4 free for noncommercial ? (Volker Hetzer)
Re: Has RSADSI Lost their mind? (Vin McLellan)
Re: Has RSADSI Lost their mind? (Vin McLellan)
microwave cd (Paul Rubin)
Re: RC4 free for noncommercial ? (Tom Anderson)
----------------------------------------------------------------------------
From: "Peter Grotrian" <[EMAIL PROTECTED]>
Subject: Re: News about quantum computer
Date: Thu, 20 Jul 2000 11:20:53 +0200
"Runu Knips" <[EMAIL PROTECTED]> wrote in news article
news:[EMAIL PROTECTED]...
> In the german computer magazine c't, issue 15/2000 (from this monday),
> page 40 they say that the current record is 8 qubits, implemented with
> rydberg states of a single atom.
Sorry, that's a wrong quote. The above c't issue says that in January 2000
scientists of U. Michigan, Ann Arbor realized 8 states, called octal Qubit,
using Rydberg states. This is equivalent to 3 Qubit.
--
Peter Grotrian - computer science student - hamburg university
[EMAIL PROTECTED] [EMAIL PROTECTED]
+49 40 29823720
> Mok-Kong Shen wrote:
> >
> > Bill Unruh wrote:
> >
> > > Mok-Kong Shen <[EMAIL PROTECTED]> writes:
> > >
> > > >The German newspaper Computer Zeitung reported in its 13 July
> > > >issue that a team consisting of US and German researchers
> > > >has succeeded to synthesize a molecule that can store 5 qubits,
> > > >while the best previous result was 3 qubits.
> > >
> > > ??? I do not know what this means. The record is 7 bits for an NMR
> > > system.
> >
> > Could you give a reference? I would with that write a letter to the
editor
> > of the newpaper.
> >
> > M. K. Shen
>
> Hmm I've written a news to the newsgroup, but unfortunatley it seems
> that it has been lost.
>
> In the german computer magazine c't, issue 15/2000 (from this monday),
> page 40 they say that the current record is 8 qubits, implemented with
> rydberg states of a single atom.
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: RC4 free for noncommercial ?
Date: Thu, 20 Jul 2000 11:38:51 +0200
Runu Knips wrote:
>
> Runu Knips wrote:
> > I'm looking for a good & free stream cipher algorithm.
> > Does anybody have a suggestion ?
>
> My crypto book states that 'RC4 requires a license fee
> for commercial use'. Does that mean it is free for
> non-commercial use ?
Why don't you ask rsalabs?
Greetings!
Volker
--
The early bird gets the worm. If you want something else for
breakfast, get up later.
------------------------------
From: Vin McLellan <[EMAIL PROTECTED]>
Subject: Re: Has RSADSI Lost their mind?
Date: Thu, 20 Jul 2000 06:04:35 -0400
Mark Wooding asked a famous question:
Why, in the fall of 1994, did Netscape's management choose to build SSL
around RSApkc -- as opposed to D-H/El Gamal -- and
RSADSI's BSAFE crypto toolkit?
Roger Schlafly, who unsuccessfully challenged the RSApkc patent,
offered his analysis of the why RSA was chosen for SSL.
> RSADSI controlled the patents for Diffie-Hellman and RSA, but it
> much preferred customers to use RSA because it got higher
> royalties and the RSA patent lasts longer.
>
> Netscape needed either Diffie-Hellman or RSA for SSL. It got
> a favorable license from RSADSI on the conditions that:
>
> 1. Netscape gives big chunks of stock to RSADSI and Bidzos
> personally.
> 2. Netscape uses RSA for SSL, rather than Diffie-Hellman.
> 3. Netscape uses BSAFE and calls the deal a software license,
> rather than a patent license.
>
> Netscape was happy to comply with (2), because it created a
> barrier to entry for its competition.
>
> The purpose of (3) was for Bidzos (CEO of RSADSI) to cheat MIT,
> Stanford, Cylink, etc. out of royalties. (This last scheme was
> later ruled illegal, but RSADSI never paid the royalties it owed.)
I don't want to challenge anyone's Conspiratorial Creed. We all cling
to what we can.
Still, questions like this arise repeatedly just because so many
newbies are coming fresh to these issues, and it seems unfair to leave
them with only one poisonous interpretation of the history of this
Craft.
Crypto politics are truly Byzantine, and the active role of the US
spooks in manipulating the market tilted everything (usually against
RSA), so simplicity in this industrial history is largely a matter of
perspective. I assert, nonetheless, that it is misleading in the extreme
to suggest that RSA's current dominance in commercial crypto, and the
web in particular, was the result of some venial conspiracy.
(Much of this thread reads like proto-Luddite hysteria, with RSA prices
plucked out of context and floated into the air like keys on a kite in a
lightning storm. Old PGPers are gleefully predicting a September Doom
for RSA, while others accuse RSA of being downright ungenerous to PGP
Inc., that notable bastion of neo-Capitalist self- righteousness and
prematurely post-patent profit-seeking;-)
I suggest, respectfully, that anyone interested in US commercial crypto
history would benefit from the recollections of others who were perhaps
closer to the SSL design decisions...and perhaps less emotionally
committed to a devil/angel perspective on RSADSI than the articulate Mr.
Schlafly (or me, for that matter, since I've been a consultant to RSA
for many years.)
Last December, in a discussion on the OpenSSL-users mailing list
entitled "Navigator, IE & RSApck-based SSL" several leading SSL
pioneers -- from Netscape and elsewhere -- offered their perspectives on
the decision to use RSApkc for SSL.
Someone in one of the followup messages referred back to Mr. Schlafly's
post to reassure someone else that his cynicism was well founded: that
the choice of RSApkc over D-H was "just politics."
From another point of view, that's sheer bullshit. There was no big
decision. RSApkc and the RSA BSAFE crypto toolkit were the obvious
choices for Netscape.
RSA offered Netscape a deal in which this hungry little startup got an
unrestricted license to use RSA's BSAFE code, cash-free, in exchange for
a legendary 1 percent of Netscape. What isn't clear in Mr. Schlafly's
summary was that that deal merely settled -- on relatively generous
terms, I think -- what was always a foregone conclusion. D-H was simply
a non-starter in 1994, according to most informed observers.
Mr. Shlafly offers a malovalent interpretation of the fact that RSADSI
preferred to license its BSAFE toolkit -- to Netscape and everyone else
-- as opposed to allowing OEMs a full patent license to roll their own
RSApkc (and/or other RSA cryptosystems.)
Putting aside the obvious risks -- to the users, (to the web), and to
the reputation of all RSA-enabled security products -- of allowing OEMs
write their own cryptographic implemention code, isn't there also a
clear business case for this marketing strategy? (So clear, in fact,
that any software firm which didn't use it would look silly -- as well
as be damned by many here for simply licensing, not developing, its
patents.)
The bottom line: the more OEMs which purchase a BSAFE license, the more
products which use (compatable, potentialy interoperable) BSAFE code
modules -- and thus, the more valuable each individual BSAFE license,
current and future, would be to all BSAFE licensees, current and
future. And to RSADSI, of course!
(There are now over a *half-billion* BSAFE installations, embedded in
thousands of different commercial products, from over a thousand
different OEM vendors who have licensed BSAFE code.
(SSL-enabled browsers are a big part of that: more than a third, less
than half, according to homeboy RSA Lore. OTOH, RSA is still closing
something like a deal a day on BSAFE. Most of these new RSA customers --
Intel and Compaq are prominent examples -- are buying BSAFE code for
apps they almost certainly won't ship or use until *after* the RSApkc
patent expires in September. Others are non-US firms which never had to
worry about the US patent. Weatherman, weatherman, which way is that
wind blowing?? ;-)
Back to the Question: Why, in 1994, did Netscape chose RSApkc as the
basis for Kipp Hickman's SSL v.1 and SSL v.2?
Paul Kocher, one of the designers of SSL 3 for Netscape, now president
of Cryptography Research, Inc. and a leading US cryptographer,
summarized the logic in a post to the OpenSSL list:
> Although I wasn't involved with SSL 2, the choice of RSA makes sense
> even ignoring the licensing issues -- people trust the RSA
> algorithm, while DSA was relatively new and was the subject
> trustworthiness/patent status concerns. The main purpose of SSL was
> to help people to trust the web with personal data like credit
> card numbers, so perceptions did matter. Also, Verisign only
> supported RSA (no coincidence, since they were spun-off from RSA).
>
> On the SSL 3.0 design, Phil, Alan, and I had pretty much complete
> freedom to do whatever made sense, except that we had to support
> Fortezza and weak crypto (which none of us were enthusiastic about).
> We did what we could -- for example, each party uses a different
> 40-bit key to squeeze an extra bit of effective security, strong
> authentication is used no matter what algorithm is selected, etc.
>
> For the benefit of non-web uses and standards bodies we added the
> non-RSA options, but never expected it to gain much use on the web.
[Source URL:
<http://www.mail-archive.com/[email protected]/msg05384.html>]
Former Netscape cryptographer Tom Weinstein <[EMAIL PROTECTED]> also
offered his interpretation of events:
.> I think there were two major factors that motivated the choice
.> of RSA.
.>
.> First BSAFE was existing code that could just be used. In a
.> startup, it's very important that you not waste time reinventing
.> wheels that you can buy off the shelf. Finally, the most popular
.> piece of crypto software at the time was PGP, which also used RSA.
[Source URL:
<http://www.mail-archive.com/[email protected]/msg05378.html>]
Eric Rescorla, a competitive critic of BSAFE and a prominent
independent crypto designer, studied Hickman's early SSL code while he
was developing a competitor, S-HTML. His recollection:
/> At the time (94-95) getting DH was no easier than getting RSA due
/> to the existence of PKP. Moreover, it was pretty clear that
/> RSA was the popular choice: There were certificate formats (X.509)
/> and an email format (PEM) based on it. From our perspective the
/> DH/DSS situation was much less evolved. <snip>
/>
/> 1998 seemed impossibly far away at the time and so it didn't
/> even occur to us to worry about the DH patent expiring. This
/> would not have been a convincing reason not to use RSA.
[Source URL:
<http://www.mail-archive.com/[email protected]/msg05382.html>]
In the OpenSSL thread and elsewhere I put forth my own interpretation
of these events. Admittedly, my perspective is biased by my association
with RSA, and by my long-term fascination with the impact of the US
spooks upon the industrial infosec market. Anyway, for yet another
alternate view of reality, the curious might consider my fragmentary SSL
spiel at:
<http://www.mail-archive.com/[email protected]/msg05377.html>
I don't really want to get into a prolongued pissing match here
(although it could be entertaining, at least to observers;-) I only
suggest that anyone with a real interest in crypto history should roam a
bit beyond this forum -- or at least this thread -- and sort out the
politics, economics, and morality of the RSA story for themselves.
Suerte,
_Vin
----
"Cryptography is like literacy in the Dark Ages. Infinitely potent, for
good and ill... yet basically an intellectual construct, an idea, which
by its nature will resist efforts to restrict it to bureaucrats and
others who deem only themselves worthy of such Privilege."
_A Thinking Man's Creed for Crypto _vbm
* Vin McLellan + The Privacy Guild + <[EMAIL PROTECTED]>
------------------------------
From: Vin McLellan <[EMAIL PROTECTED]>
Subject: Re: Has RSADSI Lost their mind?
Date: Thu, 20 Jul 2000 06:04:48 -0400
Mark Wooding asked a famous question:
Why, in the fall of 1994, did Netscape's management choose to build SSL
around RSApkc -- as opposed to D-H/El Gamal -- and
RSADSI's BSAFE crypto toolkit?
Roger Schlafly, who unsuccessfully challenged the RSApkc patent,
offered his analysis of the why RSA was chosen for SSL.
> RSADSI controlled the patents for Diffie-Hellman and RSA, but it
> much preferred customers to use RSA because it got higher
> royalties and the RSA patent lasts longer.
>
> Netscape needed either Diffie-Hellman or RSA for SSL. It got
> a favorable license from RSADSI on the conditions that:
>
> 1. Netscape gives big chunks of stock to RSADSI and Bidzos
> personally.
> 2. Netscape uses RSA for SSL, rather than Diffie-Hellman.
> 3. Netscape uses BSAFE and calls the deal a software license,
> rather than a patent license.
>
> Netscape was happy to comply with (2), because it created a
> barrier to entry for its competition.
>
> The purpose of (3) was for Bidzos (CEO of RSADSI) to cheat MIT,
> Stanford, Cylink, etc. out of royalties. (This last scheme was
> later ruled illegal, but RSADSI never paid the royalties it owed.)
I don't want to challenge anyone's Conspiratorial Creed. We all cling
to what we can.
Still, questions like this arise repeatedly just because so many
newbies are coming fresh to these issues, and it seems unfair to leave
them with only one poisonous interpretation of the history of this
Craft.
Crypto politics are truly Byzantine, and the active role of the US
spooks in manipulating the market tilted everything (usually against
RSA), so simplicity in this industrial history is largely a matter of
perspective. I assert, nonetheless, that it is misleading in the extreme
to suggest that RSA's current dominance in commercial crypto, and the
web in particular, was the result of some venial conspiracy.
(Much of this thread reads like proto-Luddite hysteria, with RSA prices
plucked out of context and floated into the air like keys on a kite in a
lightning storm. Old PGPers are gleefully predicting a September Doom
for RSA, while others accuse RSA of being downright ungenerous to PGP
Inc., that notable bastion of neo-Capitalist self- righteousness and
prematurely post-patent profit-seeking;-)
I suggest, respectfully, that anyone interested in US commercial crypto
history would benefit from the recollections of others who were perhaps
closer to the SSL design decisions...and perhaps less emotionally
committed to a devil/angel perspective on RSADSI than the articulate Mr.
Schlafly (or me, for that matter, since I've been a consultant to RSA
for many years.)
Last December, in a discussion on the OpenSSL-users mailing list
entitled "Navigator, IE & RSApck-based SSL" several leading SSL
pioneers -- from Netscape and elsewhere -- offered their perspectives on
the decision to use RSApkc for SSL.
Someone in one of the followup messages referred back to Mr. Schlafly's
post to reassure someone else that his cynicism was well founded: that
the choice of RSApkc over D-H was "just politics."
From another point of view, that's sheer bullshit. There was no big
decision. RSApkc and the RSA BSAFE crypto toolkit were the obvious
choices for Netscape.
RSA offered Netscape a deal in which this hungry little startup got an
unrestricted license to use RSA's BSAFE code, cash-free, in exchange for
a legendary 1 percent of Netscape. What isn't clear in Mr. Schlafly's
summary was that that deal merely settled -- on relatively generous
terms, I think -- what was always a foregone conclusion. D-H was simply
a non-starter in 1994, according to most informed observers.
Mr. Shlafly offers a malovalent interpretation of the fact that RSADSI
preferred to license its BSAFE toolkit -- to Netscape and everyone else
-- as opposed to allowing OEMs a full patent license to roll their own
RSApkc (and/or other RSA cryptosystems.)
Putting aside the obvious risks -- to the users, (to the web), and to
the reputation of all RSA-enabled security products -- of allowing OEMs
write their own cryptographic implemention code, isn't there also a
clear business case for this marketing strategy? (So clear, in fact,
that any software firm which didn't use it would look silly -- as well
as be damned by many here for simply licensing, not developing, its
patents.)
The bottom line: the more OEMs which purchase a BSAFE license, the more
products which use (compatable, potentialy interoperable) BSAFE code
modules -- and thus, the more valuable each individual BSAFE license,
current and future, would be to all BSAFE licensees, current and
future. And to RSADSI, of course!
(There are now over a *half-billion* BSAFE installations, embedded in
thousands of different commercial products, from over a thousand
different OEM vendors who have licensed BSAFE code.
(SSL-enabled browsers are a big part of that: more than a third, less
than half, according to homeboy RSA Lore. OTOH, RSA is still closing
something like a deal a day on BSAFE. Most of these new RSA customers --
Intel and Compaq are prominent examples -- are buying BSAFE code for
apps they almost certainly won't ship or use until *after* the RSApkc
patent expires in September. Others are non-US firms which never had to
worry about the US patent. Weatherman, weatherman, which way is that
wind blowing?? ;-)
Back to the Question: Why, in 1994, did Netscape chose RSApkc as the
basis for Kipp Hickman's SSL v.1 and SSL v.2?
Paul Kocher, one of the designers of SSL 3 for Netscape, now president
of Cryptography Research, Inc. and a leading US cryptographer,
summarized the logic in a post to the OpenSSL list:
> Although I wasn't involved with SSL 2, the choice of RSA makes sense
> even ignoring the licensing issues -- people trust the RSA
> algorithm, while DSA was relatively new and was the subject
> trustworthiness/patent status concerns. The main purpose of SSL was
> to help people to trust the web with personal data like credit
> card numbers, so perceptions did matter. Also, Verisign only
> supported RSA (no coincidence, since they were spun-off from RSA).
>
> On the SSL 3.0 design, Phil, Alan, and I had pretty much complete
> freedom to do whatever made sense, except that we had to support
> Fortezza and weak crypto (which none of us were enthusiastic about).
> We did what we could -- for example, each party uses a different
> 40-bit key to squeeze an extra bit of effective security, strong
> authentication is used no matter what algorithm is selected, etc.
>
> For the benefit of non-web uses and standards bodies we added the
> non-RSA options, but never expected it to gain much use on the web.
[Source URL:
<http://www.mail-archive.com/[email protected]/msg05384.html>]
Former Netscape cryptographer Tom Weinstein <[EMAIL PROTECTED]> also
offered his interpretation of events:
.> I think there were two major factors that motivated the choice
.> of RSA.
.>
.> First BSAFE was existing code that could just be used. In a
.> startup, it's very important that you not waste time reinventing
.> wheels that you can buy off the shelf. Finally, the most popular
.> piece of crypto software at the time was PGP, which also used RSA.
[Source URL:
<http://www.mail-archive.com/[email protected]/msg05378.html>]
Eric Rescorla, a competitive critic of BSAFE and a prominent
independent crypto designer, studied Hickman's early SSL code while he
was developing a competitor, S-HTML. His recollection:
/> At the time (94-95) getting DH was no easier than getting RSA due
/> to the existence of PKP. Moreover, it was pretty clear that
/> RSA was the popular choice: There were certificate formats (X.509)
/> and an email format (PEM) based on it. From our perspective the
/> DH/DSS situation was much less evolved. <snip>
/>
/> 1998 seemed impossibly far away at the time and so it didn't
/> even occur to us to worry about the DH patent expiring. This
/> would not have been a convincing reason not to use RSA.
[Source URL:
<http://www.mail-archive.com/[email protected]/msg05382.html>]
In the OpenSSL thread and elsewhere I put forth my own interpretation
of these events. Admittedly, my perspective is biased by my association
with RSA, and by my long-term fascination with the impact of the US
spooks upon the industrial infosec market. Anyway, for yet another
alternate view of reality, the curious might consider my fragmentary SSL
spiel at:
<http://www.mail-archive.com/[email protected]/msg05377.html>
I don't really want to get into a prolongued pissing match here
(although it could be entertaining, at least to observers;-) I only
suggest that anyone with a real interest in crypto history should roam a
bit beyond this forum -- or at least this thread -- and sort out the
politics, economics, and morality of the RSA story for themselves.
Suerte,
_Vin
----
"Cryptography is like literacy in the Dark Ages. Infinitely potent, for
good and ill... yet basically an intellectual construct, an idea, which
by its nature will resist efforts to restrict it to bureaucrats and
others who deem only themselves worthy of such Privilege."
_A Thinking Man's Creed for Crypto _vbm
* Vin McLellan + The Privacy Guild + <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: microwave cd
Date: 20 Jul 2000 10:01:23 GMT
In article <[EMAIL PROTECTED]>,
Johnny Bravo <[EMAIL PROTECTED]> wrote:
> Does anyone have any info on how effective a microwave oven is in
>destroying data on a CD? I know there is a good deal of physical
>destruction of the media, but could any of the remaining material be
>recovered or would it be scrambled?
The CD is basically a very thin layer of metal foil laminated to a
polycarbonate disc. The microwave makes a very pretty display of sparks
and the foil disintegrates into a lot of itty bitty pieces. That
sounds great but the pieces are often a few mm or bigger; which means
they could conceivably have quite a few bytes of data that could be
read with a microscope.
CD's, especially recordable CD's, are also made with fairly noxious
chemicals that you probably don't want to vaporize in your microwave
on a regular basis so they can recondense on your food that you also
use your microwave for.
I had to destroy a CD recently and decided against microwaving.
Instead I decided to use a wire wheel on a cordless drill. I don't
recommend this either since it ripped away the foil in big slabs and
made a mess.
Next time I have to do it I think I'll use a propane torch, in a well
ventilated outdoor area. That may also end in disaster, but as usual
one doesn't find out til afterwards.
Probably the most convenient and effective thing to do, especially if
you have a lot of CD's to destroy, is take them to the city dump and
toss them into a high temperature incinerator.
------------------------------
From: Tom Anderson <[EMAIL PROTECTED]>
Subject: Re: RC4 free for noncommercial ?
Date: Thu, 20 Jul 2000 11:02:32 +0100
On Thu, 20 Jul 2000, Runu Knips wrote:
> Runu Knips wrote:
>
> > I'm looking for a good & free stream cipher algorithm.
> > Does anybody have a suggestion ?
>
> My crypto book states that 'RC4 requires a license fee
> for commercial use'. Does that mean it is free for
> non-commercial use ?
dunno. how about arcfour?
<quote
src="http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-07.txt">
The "arcfour" is the Arcfour stream cipher with 128 bit keys. The Arcfour
cipher is believed to be compatible with the RC4 cipher [Schneier]. RC4 is
a registered trademark of RSA Data Security Inc.
</quote>
i think arcfour is an open-source clone of RC4; i'm not entirely sure how
you clone an algorithm, but then i was never sure how you patent an
algorithm either. there were some internet drafts on it, but they've
vanished. in fact, almost everything about arcfour except the SSH docs
seems to have vanished. will i be next?
an interesting note on RC4:
<quote src="http://cryptome.org/bcf.htm">
In passing it is worth observing that, in spite of some assertions to the
contrary, RC4 (and thus ArcFour) is not subject to any third party
intellectual property rights, since would be many hundreds of older
generation programmers who could testify that the algorithm was common
knowledge and practice in the mid-1960s for the production of sampling
arrays for Monte Carlo simulations. This fact may be the reason why the
company chose to protect RC4 by simple trade secrecy, rather than
attempting to obtain patent protection.
</quote>
okay, okay, so this should probably be in comp.misc.legal ...
tom
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
