Cryptography-Digest Digest #80, Volume #13 Fri, 3 Nov 00 03:13:01 EST
Contents:
Re: End to end encryption in GSM ([EMAIL PROTECTED])
Re: Hardware RNGs (Greggy)
Re: Is RSA provably secure under some conditions? (David Wagner)
Re: Is RSA provably secure under some conditions? (Roger Schlafly)
Re: Open Request to Dr. Kaliski, Jr. at RSA Research - looking for your ("John A.
Malley")
Re: RSAREF and RSADSI ([EMAIL PROTECTED])
Re: Crypto Export Restrictions (Matthew Montchalin)
Re: Crypto Export Restrictions (David Schwartz)
Re: On introducing non-interoperability ("Scott Fluhrer")
Re: On introducing non-interoperability (David Schwartz)
Re: Crypto Export Restrictions (Anthony Stephen Szopa)
Re: Crypto Export Restrictions (Anthony Stephen Szopa)
Re: Crypto Export Restrictions (Anthony Stephen Szopa)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.cellular.gsm
Subject: Re: End to end encryption in GSM
Date: Fri, 03 Nov 2000 00:56:37 GMT
In article <8tssju$19vi$[EMAIL PROTECTED]>,
"Big Jase" <[EMAIL PROTECTED]> wrote:
> You contradict yourself. You still don't know 3DES is secure do you?
Likely
> is not enough.
Likely is all you can get. Based on your statement I assume you have
not been significantly enlightened with regards to cryptography, and
the measurement of security. There is one and only one cipher that has
ever been proven secure against all methods of getting the plaintext
without already knowing what it is, that method is called One-Time-Pad,
and to use it you have to securely transfer an enormously huge key (the
size of the data to be sent encrypted), I won't go into the other
reasons that it can not be realized here in the real world. Outside of
that one cipher, we can only say "Cipher X offers at most Y strength of
security."
We can also make judgements on the security of a cipher based on how
long it has been examined, DES has been examined for 20+ years without
significant headway being made against it, 3DES has one attack against
it, the Meet-in-the-Middle attack, which takes 2^112 compute effort
(keep in mind that the 3DES key is 112-bits, or equivalently it's
keyspace is 2^112). It also inherits many of the desirable parts of
DES, mostly an absurdly high resistance to other known attacks (which
is further amplified by the application of DES 3 times, which is where
3DES gets it's name). To contrast this with a few other ciphers, CSS
was examined for a matter of weeks before finding the fatal flaw,
Skipjack had barely been released to the public before an attack was
found against it, DFC was around for about a year before a sucessful
attack, even Rijndael (the new AES) has academic attacks on it that
push it towards potential problems. 3DES is the most conservative
choice for ciphers available today (unless you care to try One-Time-
Pad), in 10 years I may side on the side of AES, but not right now.
We can prove breaking a cipher to be equivalent to a problem P, and
many ciphers have done that, Rabin public key is equivalent to
factoring (but has other problems), I've proposed a cipher equivalent
to breaking SHA-256, Diffie-Hellman is equivalent to Discrete
Logarithm, Elliptic Curve Cryptography is equivalent to Discrete Log on
Elliptic Curves, etc. However we can't prove that these are hard
problems, we can't prove that factoring is hard, we can't prove that
discrete log is hard, we can't prove that breaking SHA-256 is hard, but
we can trust them by knowing what we rely on.
Using 3DES we rely on the abilties of dozens of professional
cryptanalysts, thousands of amateurs, and millions of students who have
never found a significant flaw in DES to tell us that finding one now
is not likely. We further trust that tripling the encryption will
strengthen the system further. I think those are safe assumptions, and
I would put the likelihood of someone finding a significant attack
against 3DES in my lifetime at about the same as me being struck by
lightning during an earthquake, while inside, or approximately nil, and
that's a professional opinion.
Joe
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: Hardware RNGs
Date: Fri, 03 Nov 2000 01:08:22 GMT
In article <[EMAIL PROTECTED]>,
Paul Crowley <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> > > then get your random bits from there. If you can make a half-
decent
> > > estimate of the entropy, you're away.
> >
> > You're assuming the stuff you feed Yarrow is random. Yarrow is a
> > perfectly predictable PRNG otherwise :-)
>
> Well, if you correctly estimate the entropy of all of your sources as
> zero, then you still won't get any biased or guessable bits from
Yarrow
> :-)
You can never guess the bits from the RDTSC instruction.
But I don't know why he would suggest Yarrow. The LSBs from the RDTSC
are truly random in themselves.
--
I would prefer to live in a free society than
a drug free society - even if the latter could
actually be achieved.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Is RSA provably secure under some conditions?
Date: 3 Nov 2000 01:25:33 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Roger Schlafly wrote:
>But look at the typical snake-oil claim. Someone will say his
>system is provably secure because he uses a one-time pad.
>After reading all the fine print, you discover that he is just
>XORing with a pseudo-random number generator. Bogus, right?
>
>But if your claims are legitimate, then he should be able to
>legitimately claim that his scheme is "provably secure in the
>pseudo-random number generator model of random numbers". The
>only flaw is that the instantiation of the pseudo-random number
>generator might be less than ideal.
Good point. And, if you mention a scheme that xors the i-th
bit with F(i) where F is some homebrew PRNG, you could go even
further and say that this scheme is secure in the random oracle
model where F is replaced with a random oracle.
I think it raises a good point about how one must interpret
these random oracle proofs. They do not prove that the underlying
primitive is any good at all; one must assume something about
them.
Of course, once you've got a random oracle proof of some protocol,
that doesn't say anything about whether SHA1 is buggy or not, just
as a random oracle proof of the above snake-oil "OTP" system says
nothing about whether their PRNG F is any good or not. But that's
just what we would hope for, anyway! In a snake-oil "OTP" system,
it is indeed the strength of the homebrew F which is likely to make
or break the system, and if one uses 3DES, the result is likely to
be secure -- so the random oracle proof of security for the snake-oil
system is telling us exactly what is going on.
Now the above might make you think that random oracle proofs can't
tell you anything at all. But don't give up hope: What random oracle
proofs _do_ show is that the scheme is somehow "structurally sound"
-- if the primitives are instantiated with ciphers/hashes/etc. that
don't have any cryptanalytic flaws, we can expect that the result
will likely be secure.
Now this form of "structural soundness" result is quite trivial
when you're talking about encrypting messages by xor-ing them with
pseudorandom values, and we don't need any fancy formal reasoning
to see that the strength of the snake-oil system stands or falls
according to the strength of its PRNG F. But, "structural soundness"
is not at all trivial when we talk about sophisticated protocols,
which may involve several rounds of interaction, public-key
primitives with various properties combined with hash functions
that we hope don't interact poorly with the public-key stuff,
concerns about whether we've included all the right names and
nonces in every protocol message, and so on.
Thus, random oracle proofs can provide evidence that we've got the
structure of our protocol correct. For trivial protocols, these
proofs are likely to be trivial and unhelpful, because maybe trivial
protocols are easy enough to verify by hand. But, for non-trivial
protocols, verifying by hand is sufficiently error-prone that we
really need some sort of formal methods to reduce the risk of bugs.
Random oracle methods fulfill this requirement.
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: Is RSA provably secure under some conditions?
Date: Thu, 02 Nov 2000 17:54:50 -0800
David Wagner wrote:
> ... Now the above might make you think that random oracle proofs can't
> tell you anything at all. But don't give up hope: What random oracle
> proofs _do_ show is that the scheme is somehow "structurally sound"
> -- if the primitives are instantiated with ciphers/hashes/etc. that
> don't have any cryptanalytic flaws, we can expect that the result
> will likely be secure.
Yes the random oracle proofs are saying something useful, but exactly
what is a bit subtle. I just don't think that phrases like "proved
secure" adequately label what those arguments are really doing.
But that's just my opinion. People are going to say whatever
sounds good, I guess.
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Open Request to Dr. Kaliski, Jr. at RSA Research - looking for your
Date: Thu, 02 Nov 2000 19:13:57 -0800
David Wagner wrote:
>
> Oh. You mean that that the prng sequence is s, p(s), p(p(s)), ...,
> where s in G is a random seed and p : G -> G is a group homomorphism.
> Then you take a cipher c : G -> G (also a group homomorphism), and
> apply it to the current item in the prng sequence; thus, the output
> of the enciphered-prng-sequence is c(s), c(p(s)), c(p(p(s)), etc.
> Did I get that right? Is that what you meant? Seems like an
> interesting question.
Yes! Your description captures the scenario succinctly. And I, too,
think it's a interesting question.
Something to keep me productively occupied :-)
>
> (Note, by the way, that the composition c o p of homomorphisms c,p
> is itself a homomorphism. This might be useful.)
Yes - and that will prove helpful. Thank you.
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RSAREF and RSADSI
Date: Fri, 03 Nov 2000 03:58:59 GMT
It's quite simple. They simply wanted to "hide" the source code and
force their licensees to use the API that RSADSI was willing to support.
They did not want to support licensees who built up an application by
modifying the functions found in RSAREF. So, RSAREF is now part of the
BSAFE library which you cannot tweak or modify for your own purposes.
At the time I paid for an RSA license for an application and RSADSI
would not let me use my application code built by modifying aspects of
RSAREF.
James Muir wrote:
>
> I've gathered that RSADSI no longer distributes their reference crypto
> toolkit RSAREF. I'm sure this is old news ( 5 years maybe ) but I can't
> seem to find any information about why this happened. Did RSADSI sell
> their rights to RSAREF to someone? or was it just too much trouble for
> them to bother with anymore?
>
> -James
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Matthew Montchalin <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech,alt.hacker
Subject: Re: Crypto Export Restrictions
Date: Thu, 2 Nov 2000 21:50:00 -0800
On Thu, 2 Nov 2000, David Schwartz wrote:
|Its algorithmic principles are quite sound. WebMaster's RNG is based
|upon it, and it's achieved independent certification by TST. The
|primary source of raw entropy is clock skew between independent
|oscillators as well as inherent randomness in processes that interact
|with human beings.
Like the time between keypresses?
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech,alt.hacker
Subject: Re: Crypto Export Restrictions
Date: Thu, 02 Nov 2000 22:03:15 -0800
Matthew Montchalin wrote:
>
> On Thu, 2 Nov 2000, David Schwartz wrote:
> |Its algorithmic principles are quite sound. WebMaster's RNG is based
> |upon it, and it's achieved independent certification by TST. The
> |primary source of raw entropy is clock skew between independent
> |oscillators as well as inherent randomness in processes that interact
> |with human beings.
>
> Like the time between keypresses?
Yes, like the time between keypresses measured to an accuracy of better
than a millionth of a second.
DS
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: On introducing non-interoperability
Date: Thu, 2 Nov 2000 22:11:07 -0800
Mok-Kong Shen <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Bryan Olson wrote:
> >
> > Mok-Kong Shen wrote:
> > >
> > > Interoperability is the generally acknowledged benefit of
> > > standardization and is commonly to be strived at as best
> > > as possible. However, for a non-trivial amount of crypto
> > > applications, where there is a fixed communication path
> > > between two given partners, the interoperability needs
> > > only to exist between these alone, without requiring the
> > > same desirable property being extended to any third party.
> > > In fact, to the contrary, it is evidently very much to
> > > their benefit, if the opponent's system turns out to be
> > > not interoperable with theirs.
> >
> > That's what cryptosystems do. They're designed so that
> > control of the keys provides exactly the interoperability
> > and non-interoperability desired. No hack-on obscurity
> > required.
>
> The idea is to obtain a system that differs from the
> one the opponent has at hand. If the key scheduling
> is modified, he wouldn't be able to do brute force,
> for example.
Ahhh... security through obscurity... What a concept.
--
poncho
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: On introducing non-interoperability
Date: Thu, 02 Nov 2000 22:25:39 -0800
Mok-Kong Shen wrote:
> The idea is to obtain a system that differs from the
> one the opponent has at hand. If the key scheduling
> is modified, he wouldn't be able to do brute force,
> for example.
Let's start with a few definitions:
1) Key (for symmetric crypto): Whatever is kept secret between the two
parties using the cryptosystem
2) Brute Force (for symmetric crypto): An attach wherein one tries
every possible key.
Now, do you still believe that modifying the key scheduling prevents a
brute force attack?
DS
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech
Subject: Re: Crypto Export Restrictions
Date: Thu, 02 Nov 2000 23:13:55 -0800
Scott Craver wrote:
>
> Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> >CiPHER wrote:
> >>
> >> *waggles fingers* OoooOOOooo! 'Nasty person'! lol
> >>
> >
> >Thank you for your intelligent input.
> >
> >Like we really need more of this.
>
> ...," he says, posting a follow-up.
>
> Have you posted the algorithm yet for your pseudorandom
> number generator, or is it still just the "help files?"
> IIRC people could not gleen exactly how the algorithm
> worked by reading those files, and thus could not subject
> it to analysis.
>
> By the way, since your PRNG uses permutations, it uses
> "mathematical equations." If you don't think it involves
> math because it uses compositions of permutations rather
> than products of large integers, then you need to read some
> abstract algebra textbooks. And your customers need to
> _know_ that you need to read some abstract algebra textbooks.
>
> You don't need to give out the source code, but something
> like pseudocode for the generator part would be ideal.
>
> -S
>
>
"IIRC people could not gleen exactly how the algorithm worked by
reading those files,..."
How do you know?
What does "gleen" mean? Is that a new toothpaste?
If you don't get it from reading the Help files you need to learn
how to read. Many many people have read the Help files and ran
the software and are using the software and they understand it all
perfectly well.
You, like so many before you, have a wild hair up your ass and do
not have the slightest ability to simply sit down and work it
through. It is very very simple. If you are not interested then
forget about it. You have no excuses. Many others have done
perfectly well. You have not even tried or have given up.
No one listens to a loser.
If you have some valid criticism of the software post it and support
your position with facts.
So far you are just a whiner who does not do his homework.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech
Subject: Re: Crypto Export Restrictions
Date: Thu, 02 Nov 2000 23:19:32 -0800
Greggy wrote:
>
> In article <[EMAIL PROTECTED]>,
> David Schwartz <[EMAIL PROTECTED]> wrote:
> >
> > Anthony Stephen Szopa wrote:
> >
> > > Suspect?
> > >
> > > Anyone who would make such a claim and not support it is clearly a
> > > nasty person.
> >
> > I'll let people judge for themselves, but the following
> statements on
> > your web site are not exactly encouraging:
>
> > [... snip the talk ...]
>
> Where's the source code? That is all I want. Show me the source code!
>
> What? No source code? (sound of my sneakers walking away...)
>
> --
> I would prefer to live in a free society than
> a drug free society - even if the latter could
> actually be achieved.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
Good bye.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Crypto Export Restrictions
Date: Thu, 02 Nov 2000 23:35:16 -0800
Darren New wrote:
>
> Richard Heathfield wrote:
> > c) Source code in /printed/ form is also widely available, and my
> > understanding is that the USA's First Amendment was (rightly)
> > instrumental in allowing American cryptographic techniques to be
> > disseminated in this way. Does the US Government think that terrorists
> > are incapable of typing, or of hiring (or coercing) a programmer to type
> > for them? The books are on the shelves, all over the world. But even if
> > this were false:
>
> Not only this, but the US government will gladly mail you a copy of the
> patent protecting unexportable crypto, from which you're supposedly able to
> reconstruct the invention.
>
> --
> Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
> San Diego, CA, USA (PST). Cryptokeys on demand.
> The tragedy of the commons applies to monitizing eyeballs, too.
Yeah. If you have half a brain and/or are practiced in the art.
------------------------------
** 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
******************************
