Cryptography-Digest Digest #928, Volume #12 Sat, 14 Oct 00 21:13:00 EDT
Contents:
ECDSA ("Jesper Stocholm")
Re: Is it trivial for NSA to crack these ciphers? ("Stephen M. Gardner")
Re: Why trust root CAs ? ([EMAIL PROTECTED])
Re: SDMI - Answers to Major Questions (David A Molnar)
Re: Why trust root CAs ? (David Schwartz)
Re: block-cipher silly question? (David Schwartz)
Re: Why trust root CAs ? ([EMAIL PROTECTED])
Re: Is it trivial for NSA to crack these ciphers? (David Wagner)
Re: Is it trivial for NSA to crack these ciphers? (John Savard)
Re: Why trust root CAs ? ([EMAIL PROTECTED])
Re: Why trust root CAs ? (Anne & Lynn Wheeler)
Re: ANNOUNCE: SandMark -- A Software Watermarking Tool for Java (Christian S.
Collberg)
Re: BlowFry... ("Vic Drastik")
Re: block-cipher silly question? (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: "Jesper Stocholm" <[EMAIL PROTECTED]>
Subject: ECDSA
Date: Sun, 15 Oct 2000 01:11:16 +0200
I am working with ECDSA for the moment, and currenty I am studying the paper
by Alfred Menezes (et al) at
http://cacr.math.uwaterloo.ca/~ajmeneze/publications/ecdsa.ps
But I would like some other information (from other sources) as well - about
the mathematical background of ECDSA/ECC. Can you give me some pointers in
the right direction ?
Thanks,
Jesper Stocholm
------------------------------
From: "Stephen M. Gardner" <[EMAIL PROTECTED]>
Subject: Re: Is it trivial for NSA to crack these ciphers?
Date: Sat, 14 Oct 2000 17:44:20 -0500
"John A. Malley" wrote:
> The Manhattan Project springs to mind as a historical example of a group
> of scientists working in secret, whose membership was restricted by
> security clearance, who accomplished more than a larger group of
> scientists working in the open and thus subject to wider peer review
> (first controlled fission reactor, first fission weapon).
The Manhattan Project was a very special circumstance. Because of the war
and the fact that the Nazis stupidly drove much of the European physics
community into exile the critical mass of research shifted very lopsidedly to
the Manhattan project. It should also be remembered that all of the scientists
in the Manhattan Project had been entirely formed outside of the secret labs.
There was no inbreeding. The NSA crowd is extremely insular in comparison.
How long would a wag like Feynman last at NSA?
> Bletchley Park in England during World War II (cryptanalysis of
> state-of-the-art crypto systems, some of the first programmable
> computers) is another example.
These WWII era analogies are suspect because of the entirely different
conditions today.
> I won't argue the morality of the innovations, only the fact that these
> significant bursts in applied mathematics and applied physics and
> engineering fit your billing. Significant strides without significant
> peer review, publication or openness.
All took place in special circumstances with people *temporarily* brought
together out of the open scientific community. To compare the Manhattan
Project to the NSA is to neglect the stultifying role of huge
self-perpetuating bureacraties and the invigorating effect of having a world
menacing evil to work against in a relatively short term and exciting project.
--
Take a walk on the wild side: http://www.metronet.com/~gardner/
There is a road, no simple highway, between the dawn and the
dark of night. And if you go no one may follow. That path is
for your steps alone.
The Grateful Dead ("Ripple")
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why trust root CAs ?
Date: Sun, 15 Oct 2000 00:24:05 GMT
On Sat, 14 Oct 2000 14:24:22 -0700, David Schwartz
<[EMAIL PROTECTED]> wrote:
>
>[EMAIL PROTECTED] wrote:
>
>> If the key is associated with your chosen id at each bank or whatever,
>> then there is no need for a central repository.
>
> Then how will the bank know that your id is associated with you? It
>must store that information somewhere -- and the logical format to store
>it in is a certificate.
>
Sorry, when I said central repository, I meant there is no need for a
*third party* central repository outside the bank (a la Verisign or
Thawte), let alone such third party PKI across a number of banks. The
bank's systems are the repository for the ids used by its customers.
This also gets around the problem of Joe's Discount Browser Session
Hijacking, since if someone impersonates your bank's server, they can
verify that it is you by sending a session id and receiving it back
signed by your private key, but that doesn't compromise your private
key, as would be the case if they hijacked a password based session.
PB
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: SDMI - Answers to Major Questions
Date: 14 Oct 2000 23:21:06 GMT
Scott Craver <[EMAIL PROTECTED]> wrote:
> Alas, I do research in the field of watermarking and watermarking
> attacks, and my ears are pretty crummy. Plus I have to do most of
> my work in a room with big loud fans.
Can't you just find some music majors on campus and use them as guinea
pigs (I'm assuming their ears are relatively good)? Maybe you could even
get a psych major to set up and run experiments as a thesis topic, thus
saving you the trouble...
-David
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Why trust root CAs ?
Date: Sat, 14 Oct 2000 16:46:53 -0700
[EMAIL PROTECTED] wrote:
> > Then how will the bank know that your id is associated with you? It
> >must store that information somewhere -- and the logical format to store
> >it in is a certificate.
> Sorry, when I said central repository, I meant there is no need for a
> *third party* central repository outside the bank (a la Verisign or
> Thawte), let alone such third party PKI across a number of banks. The
> bank's systems are the repository for the ids used by its customers.
There is no distinction in this case between a third and a second
party. In any arrangement, who does what can be changed. If banks want
to be CAs, they can be. It is, however, logical for banks to specialize
in banking. On the other hand, it's not necessarily logical for a CA to
specialize in certifying _financial_ transactions.
Somebody must vouch for the fact that your key belongs to you. Someone
must have you physically present your key and some form of
identification and vouch that the person who proferred the key and the
person who proferred the ID are one and the same. If you and your bank
are in the same geogrpahical region, it is sensible for you to go to
your bank and do this. If not, not.
> This also gets around the problem of Joe's Discount Browser Session
> Hijacking, since if someone impersonates your bank's server, they can
> verify that it is you by sending a session id and receiving it back
> signed by your private key, but that doesn't compromise your private
> key, as would be the case if they hijacked a password based session.
What you really need are different levels of trust in keys. If I choose
to use a bank, I may choose to trust their keys at a very high level. On
the other hand, I'd rather accept a self-signed cert than send data in
the clear -- but I like to know that I have no protection against MITM
attacks.
The problem with PKI is not that's defective in principle, it's that
it's defective as implemented. The defects are not easy to fix either.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: block-cipher silly question?
Date: Sat, 14 Oct 2000 16:48:11 -0700
Richard Heathfield wrote:
>
> David Schwartz wrote:
> >
> > "N. Weicher" wrote:
> >
> > > I hope this isn't too silly a question to ask, but is there such a
> > > thing as a credible block cipher that works on a single-byte block?
> >
> > Usually we would call such a thing a stream cipher.
>
> What if the machine has 64-bit bytes? Would you still call it a stream
> cipher then?
I would. Perhaps others wouldn't. Remember, he said it had to be
"credible". If it was a mere one-to-one substitution by octet, it would
not be credible. So some sort of chaining or feedback would have to be
built in.
DS
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why trust root CAs ?
Date: Sun, 15 Oct 2000 01:01:52 GMT
On Sat, 14 Oct 2000 14:59:59 GMT, Anne & Lynn Wheeler
<[EMAIL PROTECTED]> wrote:
>David Schwartz <[EMAIL PROTECTED]> writes:
>> I think you'll find that if you do this, you recreate the PKI. First,
>> you'll want a central repository of whose key is whose. Second, you'll
>> want one place to go to revoke a key should it be compromised. And so
>> on.
>
>you just don't need a certificate based PKI ... you go with an online,
>real-time PKI.
Yes but it can be done without a 3rd party PKI, ie purely between the
customer and the bank.
>The paradigm for the certificate model PKI was the offline email case
>between parties that had no prior relationship and/or knowledge of
>each other (i.e. connect to the network, download email, disconnect,
>read email ... and perform various actions as specified by the email,
>even tho you had no prior knowledge of &/or relationship with the
>person sending the email).
Yes. If one establishes a relationship through key registration, then
therie is prior knowledge/a prior relationship for every subsequent
transaction. This is essentially how the world works now. My bank
knows me becasue I open an account with them - ie establish my
identity and a relationship with them.
The thing I am interested in is how to implement authentication in a
*retail* environment, without severely compromising privacy. By
*retail* I mean not just in the commercial sense, but in the sense
that every member of the public must be able to be authenticated in
some fashion, but in a way that avoids the need to build central
repositories of their actual identities linked to their electonic
identities held across all the entities they deal with. The thought
is that if they have an unlimited number of unique electronic
identities (ie public keys), and use one or t'other of these to
register with each entity which needs to recognise them, then they can
use the private key to authenticate themselves to that party in any
subsequent transaction (as people use their signatures now). If they
are concerned about an entity profiling them, or being profiled across
a range of enitities, they can use different keys for different
entities (ie multiple electronic ids), and so split their information
between several identities - this only works where they aren't
required to provide other identifying information (name address etc),
but that is the case now, and I am only seeking to preserve existing
levels of privacy/control over one's own information, not increased
levels.
The problem, as noted elsehwere, is not with the basic scheme, it is
with key revocation. Worst case, as with credit cards now, is that
one would have to individually notify everyone with whom you have
registered an id of its revocation and replacement. This may be able
to be avoided by having an authorative central revocation register
which one could notify. If this is *not* also used to issue the
replacement key, then one can still avoid centralisation of
identifying information. One would have to re-register bilaterally
with each of the entities where the previous key had been revoked, and
with whom one still wished to exchange data. In this way one still has
separation of information across multiple ids; the revocation
authority only knows those which have been revoked and not those which
are still current; and the revocation authority doesn't know with whom
your ids are lodged, since entities would simply check with the
revocation authority prior to accepting a signature - if there is no
revocation then the revocation authority has no way of knowing what
identities being checked are associated with what people.
PB
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Is it trivial for NSA to crack these ciphers?
Date: 15 Oct 2000 00:07:26 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Stephen M. Gardner wrote:
> How do we know that? How many scientists are there at NSA engaged in
>cryptanalysis research?
Precisely my point! This cannot be settled a priori; you need to
know some facts to answer the question. This is why we should not
dismiss out of hand the possibility that the NSA is ahead of the open
community; nor should we ignore the chance the NSA and the open
community are at roughly equal levels of competency.
We just don't have all the facts.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Is it trivial for NSA to crack these ciphers?
Date: Sat, 14 Oct 2000 23:11:32 GMT
On Fri, 13 Oct 2000 23:21:05 GMT, CiPHER <[EMAIL PROTECTED]>
wrote, in part:
>You see, otherwise, they'd really be shitting it and export laws would
>be tougher than you could possible imagine...
Let's not _totally_ dismiss this sentence out of hand.
Now, it's true that the old export laws - which we don't have to
imagine, but can remember - were pretty stupid. A printed description
of DES in a magazine was _doubly_ legal under the old export laws,
since it was in print, and it wasn't source code.
(Actually, I remember a Ciarcia's Circuit Cellar project that was
simplified for fear of running afoul of export law: I think it was the
courts that got printed source code out from under.)
Could a policy of greater secrecy in cryptographic methods make the
ciphers in use more breakable?
The Encyclopedia Brittanica article on codes and ciphers by W. F.
Friedman mentioned Hagelin machines and rotor machines, but didn't
explain how they worked. David Kahn's book, "The Codebreakers", did so
for both. But the Hagelin lug and pin machines, and Hebern's rotor
machines, were the subject of publicly available patents, dating from
before World War II.
Before DES came out, I had the idea of writing a BASIC program that
simulated a rotor machine whose rotors were moved by lug and pin
machines of the Hagelin type, all the pinwheels of each one being
relatively prime to all the other pinwheels.
But I didn't think of inventing the SIGABA principle.
Still, if that would have done almost as well, even if rather less
efficiently, then one could say the cat was out of the bag.
Or, again with BASIC on a simple little 8-bit computer - naturally,
your next-door neighbor could see your "secret" message on his TV set,
if he was looking, but leaving out that detail - one could, say,
subject a message to a simple columnar transposition eight times -
and, between each two times, perform Playfair on it.
And there are a lot of other interesting ideas that might be inspired
by Gaines.
Now then: here is the question. Suppose that IBM's LUCIFER sent the
NSA into a tizzy. Sure, it was weak with respect to differential
cryptanalysis, which the NSA knew about. But suppose they were
resolved upon seeing it that "they are starting to do this; now, they
will not find it impossible to achieve anything they might
imagine"...what would their options be?
We can cross out "creating a confusion of tongues" from the list.
I suppose they certainly could have whispered in IBM's ear, however.
Could they, indeed, have managed to suppress virtually all public
discussion of the application of electronics to cryptography? I
suppose so, with a bit of exertion.
But they could hardly have suppressed public knowledge that computers
can be used to manipulate numbers - and printed characters. It was too
late to "uninvent" the computer.
Censorship restrictions in any major war would normally result in a
shutdown of the Internet in the countries involved; since the T1 lines
all go to a telephone or telegraph company in the end, that isn't that
hard to do...in this case, though, it would have been simple enough to
avoid having the Internet invented in the first place.
Presumably, the NSA could have gotten the equally panicked Western
allies to go along with any regime not too onerous, not too
anti-technological.
But we don't have to venture into alternate history to determine if
the NSA would have "done something" sufficient to prevent the
development of ciphers it cannot break. Because we know that such
ciphers exist, that how to construct them is public knowledge, and the
NSA has not suppressed it!
Take DES. Scale it up. Use 128-bit blocks, and eight S-boxes with
4,096 entries: 16 permutations of the numbers from 0 to 255. Make
those S-boxes key-dependent. Use 32 rounds.
Or if that isn't enough, scale it up some more. If David A. Scott can
do it, you can do it.
Change the subkeys with every block enciphered.
Maybe the NSA can break Triple-DES and Rijndael like nobody's
business. But the major cipher designs in use are *scalable*. What
exactly is the NSA going to do...classify the number 5? Or the number
16? Or the number 128?
Unless one is willing to claim that the NSA is capable of breaking a
block cipher with an infinite block size, an infinite number of
rounds, and an infinitely long key...their abilities must stop
somewhere. Since "where" is classified, and properly so, that means a
few wasted cycles, but not much more.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why trust root CAs ?
Date: Sun, 15 Oct 2000 01:12:25 GMT
On Sat, 14 Oct 2000 15:04:01 GMT, Anne & Lynn Wheeler
<[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] writes:
>
>> On Sat, 14 Oct 2000 19:43:28 +1000, "Lyalc" <[EMAIL PROTECTED]>
>> wrote:
>>
>> >If you replace Public Key with Password, this models works just as well, and
>> >works today, at zero incremental cost.
>>
>> Scheme outlined has advantages over passwords which may justify the
>> incremental costs. EG:
>> - a password is inherently less secure since it relies on keeping the
>> password secret, and yet password is known to all entities/devices for
>> which you use that password. A public key can be put on a bill board
>> without lessening security.
>> - using a public key approach allows enables encryption of data unique
>> to the user, increasing security.
>> - the use of a device to handle the registration and authentication
>> simplifies the process from the point of view of the end user and
>> obviates the need to handle, remember and keep secure multiple
>> passwords.
>
>replacing a password registerd in an account record with a public key,
>the public key part of the protocol is the same whether the private
>key is stored in a password protected software file, a hardware token
>w/o any activiation, a hardware token with PIN activation, or a
>hardware token with biometric activation, or a hardware token with
>both PIN & biometric activation.
Yes.
>the public key part of the protocol is the same whether the consumer
>registers the same public key with one location or the same public key
>with 15 locations. In the case of multiple public key registration,
>one might be the bank and another might be the consumer's ISP. Using a
>common public key at both an ISP and the bank ... doesn't have the
>downside of somebody at the ISP doing fraudulent transactions at the
>bank.
Indeed.
>deploying a common public key protocol would give the consumer a great
>deal of freedom and choice as to the level of security and integrity
>that they would like to use (software files, different tokens at
>different integrity levels, activation, etc)
Yep.
>The PIN/biometric activation ... as opposed to authorization is an
>issue. In the case of flowing an authorization PIN/password ... which
>might get compromized, it is realitively easy to get a new
>PIN/password. Biometric authorization in an open environment is much
>harder to deal with (effectively biometric authorization is a complex
>PIN/password that the person doesn't have to remember). In the case of
>biometric authorization compromize, it is much harder to issue a new
>body part. It is also harder to make sure that a unique body part is
>used for each entity that the consumer wishes to authenticate with.
Agreed, but I wasn't proposing that biometric be used except on the
local device which holds the private key. Ideally this would be a
tamper proof print recognition smartcard, so people would have the
convenience of just thumbing their card while it is slotted to
authorise/authenticate a transaction, but the print recognition data
would be *not* be held or used anywhere off the card. This way the
critical authentication info in the wider system is still the key pair
for which the private key is held on the card, *not* the
bio-recognition data which is used purely locally to authorise the use
of the private key.
cheers
PB
------------------------------
Subject: Re: Why trust root CAs ?
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Sun, 15 Oct 2000 00:15:32 GMT
David Schwartz <[EMAIL PROTECTED]> writes:
> There is no distinction in this case between a third and a second
> party. In any arrangement, who does what can be changed. If banks want
> to be CAs, they can be. It is, however, logical for banks to specialize
> in banking. On the other hand, it's not necessarily logical for a CA to
> specialize in certifying _financial_ transactions.
the bank doesn't really care if somebody certifies that you are you,
the bank really does care if the person they are dealing with is the
person that has rights to the account ... they surely can't use a 3rd
party to tell them which person has what rights to which account.
given that a bank can be sure that you are the person that has rights
to a particular account and that you own a private key (by
self-signing the corresponding public key) ... then the bank can
record the associated public key for that account.
the bank recording a public key may or may not involve the bank
returning a copy of a manufactored certificate. if there is a case
where they would return a copy of a manufactored certificate, the
original of that certificate is stored in the bank account record.
if the bank finds that the consumer is alwas returning a copy of the
manufactored certificate attached to a transaction sent to the bank,
then the bank can advise the consumer to do a little bit of knowledge
compression ... i.e. every field that exists in the copy of the
manufactored certificate that is also in the original of the
manufactored certificate stored at the bank ... can be compressed from
the copy of the manufactored certificate. Such compression can lead to
the efficiency of attaching zero byte certificates on every
transaction.
if the bank finds that the consumer is only attaching the copy of the
bank's manufactored certificate to transactions sent to the bank, the
bank can can save the consumer extra effort by precompressing the copy
of the manufactored certificate returned to the consumer (during
registration) ... i.e. by providing the consumer a zero byte
certificate that has been pre-compressed.
--
Anne & Lynn Wheeler | [EMAIL PROTECTED]
http://www.garlic.com/~lynn/
------------------------------
From: [EMAIL PROTECTED] (Christian S. Collberg)
Crossposted-To: comp.lang.java.security,comp.security.misc,comp.lang.java.programmer
Subject: Re: ANNOUNCE: SandMark -- A Software Watermarking Tool for Java
Date: 14 Oct 2000 08:19:25 -0700
In article <[EMAIL PROTECTED]>,
Roedy Green <[EMAIL PROTECTED]> wrote:
>On 13 Oct 2000 11:03:45 -0700, [EMAIL PROTECTED] (Christian S.
>Collberg) wrote or quoted :
>
>>SandMark is a system for embedding a watermark in a Java program.
>
>It might me useful to tell the world what a watermark is and why you
>would want to embed one in a Java program.
>
>This is so typical of technical announcements. They leave off the
>"obvious" - what is it for?
In a nutshell, software watermarking allows you to embed a
copyright notice or a customer identification number into
a program. The copyright notice allows you to assert your
intellectual property rights, and the customer identification
number allows you to track pirated copies of the code.
Or, in a slightly more technical language:
Watermarking embeds a secret message into a cover message.
In media watermarking the secret is usually a copyright
notice and the cover a digital image. Watermarking an
object discourages intellectual property theft, or
when such theft has occurred, allows us to prove ownership.
Fingerprinting is similar to watermarking,
except a different secret message is embedded in
every distributed cover message. This may allow us
not only to detect when theft has occurred, but
also to trace the copyright violator.
The Software Watermarking problem can be described
as follows. Embed a structure W into
a program P such that: W can be reliably located and
extracted from P even after P has been subjected to
code transformations such as translation,
optimization and obfuscation; W is stealthy; W has
a high data rate; embedding W into P does not
adversely affect the performance of P;
and W has a mathematical property that allows us to
argue that its presence in P is the result of deliberate
actions.
Christian
------------------------------
From: "Vic Drastik" <[EMAIL PROTECTED]>
Subject: Re: BlowFry...
Date: Sun, 15 Oct 2000 11:24:36 +1000
> > "Runu Knips" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > > To this end I have produced an 8bit version of BlowFish
> > > > which for fun I have christened BlowFry.
>
> I still wonder why Schneier gave his algorithm this name.
He intended to call his AES algorithm "TwoFish" , so he chose a name for
his first algorithm which would match this.
Seriously , though , the WWII German naval codes , which were quite strong ,
were given fishy names like Shark and Tunny by BP. I think he wanted to
follow in this tradition.
Vic
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: block-cipher silly question?
Date: 15 Oct 2000 00:16:25 GMT
[EMAIL PROTECTED] (David Wagner) wrote in
<8san55$7ug$[EMAIL PROTECTED]>:
>Douglas A. Gwyn wrote:
>>John Savard wrote:
>>> A true block cipher with an 8-bit block would be a monalphabetic
>>> substitution on a 256-character alphabet. That could not be secure.
>>
>>In ECB mode, sure, but there are reasons why ECB is not much used
>>even with large block sizes.
>
>The original poster stated that he was not interested in feedback modes,
>so I do not see how stream ciphers are relevant.
>
>In this case, I cannot see how a cipher with a 8-bit block can be
>secure. (Perhaps this is just my lack of imagination; I'd be happy to be
>corrected!)
If the user can prevent certain attacks such as chosen plain text
attacks. And if the files are prewhittened and compressed with 1-1
compressors. IN a secret way. Like using my compressor with a secret
condition file. He could then encrypt the resultant file with a normal
8 bit block cipher and it would not be trival to break.
So yes your imagination seems to be lacking alot.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
** 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
******************************
