Cryptography-Digest Digest #506, Volume #9 Thu, 6 May 99 06:13:03 EDT
Contents:
Re: A challenge for you ! ("Douglas A. Gwyn")
Re: Some thoughts on Diffusion (Piso Mojado)
Re: True Randomness & The Law Of Large Numbers ("Douglas A. Gwyn")
Re: Pentium3 serial number is based on who you [server/exterior] claimed ("Douglas
A. Gwyn")
Re: Some thoughts on Diffusion ("Malcolm Herring")
Re: Commercial PGP for Linux? (Bernie Cosell)
Automatic CRL delivery ("Johannes Farmer")
Re: Commercial PGP for Linux? (Jim Gillogly)
Re: Discrete Logarithm Question ("Antoine Joux")
Re: The simplest to understand and as secure as it gets. (SCOTT19U.ZIP_GUY)
Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO (Mok-Kong Shen)
Re: Shamir's Discover: to those in the know (Piso Mojado)
Re: Commercial PGP for Linux? (J.H.M. Dassen (Ray))
Re: DECT/GAP cordless phone encryption algorithm (Stephen Early)
Re: Roulettes (Paul Rubin)
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: A challenge for you !
Date: Thu, 06 May 1999 03:56:44 GMT
Bob Silverman wrote:
> In article <[EMAIL PROTECTED]>,
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> > It's the encryption that wants cracking, not necessarily the
> > original program used to perform the encryption
> And doing that is IMPOSSIBLE. Under any circumstances.
>
> ...
>
> With ciphertext ONLY, it can decode to ANYTHING. And one can always give a
> key which makes that decoding correct.
> --
> Bob Silverman
> "You can lead a horse's ass to knowledge, but you can't make him think"
What an appropriate end quote.
------------------------------
From: Piso Mojado <[EMAIL PROTECTED]>
Subject: Re: Some thoughts on Diffusion
Date: Wed, 05 May 1999 19:33:51 -1000
Malcolm Herring wrote:
>
> > Robert Scott wrote:
> > >
> > > While experimenting with different Feistel-like symmetric
> > > ciphers, I had some thoughts on ways of quantifying diffusion.
> > >
> > > While the overall security of a cipher can never be known
> > > for certain until it is broken, diffusion has been at least
> > > a good indicator of probable security. By diffusion I mean the
> > > action of an input data bit having an effect on a large
> > > part (hopefully all) of the output block. When applied to ciphers
> > > with rounds, I mean diffusion to apply specifically to the rate
> > > at which the effect of an input bit spreads as a function of
> > > rounds.
> ...
>
> Surely diffusion says nothing at all about the security of an algorithm.
Block ciphers are not provably secure, but they all have diffusion.
If you would belittle diffusion, what would you propose as a trait
that says something about security?
>One
> can propose any number of keyless scrambling systems (LFSRs, for example)
> which have very high diffusions of input data but which are otherwise
> equivalent to plain text.
One can create bad ciphers easily. All of the good ones have diffusion.
I have heard your kind of comments before, but they are not
persuasive. All 15 AES candidates have diffusion. If someone
made an AES candidate without diffusion, it would be rejected
immediately. It is a requirement. It is so basic that sophisticated
people want it to be called trivial and unimportant, but they
are mistaken. Conservative ciphers have more diffusion then ones
which emphasize speed to excess.
Sophisticated people such as yourself would overlook the
requirement for diffusion, and look to Authority to fail to
break the cipher. Thinking designers, provide diffusion with
emphasis on plenty of diffusion, as well as other traits.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Thu, 06 May 1999 04:14:20 GMT
"R. Knauer" wrote:
> So now you appear to be saying that each bit in the sequence is a
> separate measurement of the random generation process.
Each bit is certainly supposed to be an *independent sample* of the
output of the process, when the process meets its randomness specs.
Perhaps it may clarify something if you consider the testing as an
attempt at "proof by contradiction", which is of course a standard
method in mathematics and other rational disciplines. It goes
something like this:
1) We assume the TRNG instance is functioning correctly.
2) We deduce from (1) and the definition of correct
functioning that the output stream has certain simple
(UBP) statistical characteristics.
3) We observe the actual output and find that it does
not have those statistical characteristics.
4) (2) and (3) are contradictory; therefore the assumption
(1) cannot have been correct.
5) Therefore the TRNG instance is not functioning correctly.
In the above, I intentionally neglected the distinction between exact
knowledge and probabilistic knowledge (with high degree of certainty),
for pedagogical reasons -- because it is easier to understand the
argument in a purely Aristotelian (Boolean) setting.
Of course, not every test "proves" that the TRNG is malfunctioning.
If the TRNG is in fact functioning correctly, (3) rarely happens,
so we don't arrive at (5). Note that failure to demonstrate a
malfunction is *not* logically the same as proving correct function!
In the context of FIPS-140, the tests were wanted to check at run
time that a system, which had presumably already had its design
validated by other means, was still operating as designed.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: alt.security
Subject: Re: Pentium3 serial number is based on who you [server/exterior] claimed
Date: Thu, 06 May 1999 04:16:47 GMT
What is really stupid about the whole thing is that not every node on
the Internet can be presumed to be a Pentium III.
------------------------------
From: "Malcolm Herring" <[EMAIL PROTECTED]>
Subject: Re: Some thoughts on Diffusion
Date: Wed, 5 May 1999 21:07:09 -0700
Piso Mojado <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> > Surely diffusion says nothing at all about the security of an algorithm.
>
> Block ciphers are not provably secure, but they all have diffusion.
> If you would belittle diffusion, what would you propose as a trait
> that says something about security?
>
> >One
> > can propose any number of keyless scrambling systems (LFSRs, for
example)
> > which have very high diffusions of input data but which are otherwise
> > equivalent to plain text.
>
> One can create bad ciphers easily. All of the good ones have diffusion.
> I have heard your kind of comments before, but they are not
> persuasive. All 15 AES candidates have diffusion. If someone
> made an AES candidate without diffusion, it would be rejected
> immediately. It is a requirement. It is so basic that sophisticated
> people want it to be called trivial and unimportant, but they
> are mistaken. Conservative ciphers have more diffusion then ones
> which emphasize speed to excess.
>
> Sophisticated people such as yourself would overlook the
> requirement for diffusion, and look to Authority to fail to
> break the cipher. Thinking designers, provide diffusion with
> emphasis on plenty of diffusion, as well as other traits.
I did not say that secure ciphers need not exhibit high diffusion, merely
that it is possible have high diffusion without any security at all - i.e. a
cypher whose key is a constant.
------------------------------
From: [EMAIL PROTECTED] (Bernie Cosell)
Crossposted-To: comp.security.unix
Subject: Re: Commercial PGP for Linux?
Date: Thu, 06 May 1999 04:29:49 GMT
[EMAIL PROTECTED] (Bernie Cosell) wrote:
} Andrew Kay <[EMAIL PROTECTED]> wrote:
}
} } Bernie Cosell wrote:
} } > I am trying to locate PGP for Linux that I can use for a commercial
} } > application. ...
} ... It seems
} that the catch with NAI is that you have to call them up and talk to a
} salesperson if you want their commercial package... Since there's not a
} *hint* of how much it costs, I'm almost afraid to call.. :o)
Well, just to close off this thread, I thought I'd mention that I called
NAI and discovered that a _one_year_, _single_server_ license for PGP for
Linux is *two*thousand*dollars*. Ouch!!
/Bernie\
--
Bernie Cosell Fantasy Farm Fibers
[EMAIL PROTECTED] Pearisburg, VA
--> Too many people, too few sheep <--
------------------------------
From: "Johannes Farmer" <[EMAIL PROTECTED]>
Subject: Automatic CRL delivery
Date: Thu, 6 May 1999 10:29:20 +0200
Hi,
I am implementing some trust managing software for a PKI environment.
I want my software to draw a CRL from the Internet in a self-acting way.
Does anybody know a certification authority that provides CRLs which can be
requested via http, ftp, mailto or LDAP (my favorite).
Thank you very much for any response.
--
Johannes Farmer
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Crossposted-To: comp.security.unix
Subject: Re: Commercial PGP for Linux?
Date: Thu, 06 May 1999 00:40:57 -0700
Bernie Cosell wrote:
> Well, just to close off this thread, I thought I'd mention that I called
> NAI and discovered that a _one_year_, _single_server_ license for PGP for
> Linux is *two*thousand*dollars*. Ouch!!
Good heavens! That certainly doesn't close off the thread!
Are they talking about a central server that handles enterprise PGP-ing
for a very large company? Or is "server" in this case an individual
Linux workstation? It surely can't be the latter unless they're trying
to kill off the product.
--
Jim Gillogly
15 Thrimidge S.R. 1999, 07:38
12.19.6.3.0, 3 Ahau 8 Uo, Sixth Lord of Night
------------------------------
From: "Antoine Joux" <[EMAIL PROTECTED]>
Subject: Re: Discrete Logarithm Question
Date: Thu, 6 May 1999 10:42:58 +0200
Bill Unruh Wrote:
: >>I wanted to know if there is a method to find x in
: >>a_i^x == b_i ( mod N )
: >>if I can calculate b_i for *every* 1 < a_i < N. And N is not a prime
: >number.
: >In order to solve the discrete logarithm mod N, the only solution is to
: >factor N, ...
: But his is not the discrete logarithm problem. The discrete log problem
: is if you know a and a^x, (mod N) find x. But this is for a single value
: of a. He is asking if you know a^x and a for all possible values of a,
: can you find x.
This is true, however the two problems are very similar. In fact, starting
from
a single equation a^x=b (Mod N), you can get many such equations:
(a^i)^x=b^i (Mod N).
When working modulo a prime, if $a$ is a generator of the multiplicative
group, you
even get all the equations.
With a composite N, you need more than one equation to generate all of them.
However, I know no technique to use the extra information.
: Vedat Hallac a �crit dans le message
<7gqlhe$fmf$[EMAIL PROTECTED]>...
: >Thanks for the quick reply. I found your answers most enlightnening.
However
: >I have a few questions.
: >>3) The fact that the only solution is to factor N, is easily proven.
The
: >>proof follows:
: >Hmmm.... I can see why finding x solves factorization. But what is
missing
: >in the proof is why factorization has to be the only way to find x. I
: >understand that if there was a way, factorization problem would have
been
: >solved by now, but the proof as you have stated does not say that there
is
: >no other way of doing it. Or does it?
No using everyday logic it doesn't, but this kind of reduction is a standard
technique
to prove that a given computing problem is harder than another one. Thus
first solving
the easiest problem cannot hurt and thus the standard way to state such a
fact is
to say "The only way to solve Y is first to solve X".
: >Also I cannot see why you need to write D as 2^t*O. If D is a multiple
of
: >Phi(N), then it would be sufficient to write D as 2*O (should I assume
N is
: >odd? Of course), and try a single squaring. I bet you would get a
: >non-trivial square root of one with equal chance with the method you
: >suggested. If you choose a t > 1, you can find another square root of
one
: >before you square W t times, but it does not seem too important.
I took out all the 2's in D to ensure that O is odd. That way, everything
works even
is D is a even multiple of Phi(N). I agree that with care you can be quite
sure that D is
Phi(N), but why bother ?
: >The problem came up from something along the lines of the proof you
have
: >posted (a more primitive version, you might say). If N = p*q, with p
and q
: >prime, and Phi(N) > p+q,
: >then for any 0<a<N,
: >a^(N+1) == a^(p+q) ( mod N )
Note that in that case, p and q are the two solutions of
x^2-(N+1-Phi(n))x+N=0 (i.e x^2-(p+q)+N=0)
so it is even easier to factor N given Phi(N).
Antoine Joux
------------------------------
From: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: The simplest to understand and as secure as it gets.
Date: Thu, 06 May 1999 04:17:04 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> The simplest encryption software, the easiest to understand, and as
> secure as it gets.
>
> Original Absolute Privacy - Level3 Version 4.0 Windows GUI - SHAREWARE
>
> http://www.ciphile.com
>
>
Actually I think scott19u.zip is stronger.
Get it free executable and source code visit my site.
David A. Scott
--
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
to email me use address on WEB PAGE
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO
Date: Thu, 06 May 1999 11:30:50 +0200
SCOTT19U.ZIP_GUY wrote:
>
> In article <[EMAIL PROTECTED]>,
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> > > Do you really want me to find the reference. And would it shut you
> > > up or just piss you off more?
> >
> > Do you think that I am joking????? Let's see who is the liar!!
>
> Well I figured you are either joking or have a very bad memory
> as you said your English is not very good.
What kind of arguments are you using???!!! Are you very good in,
say, Russian, if you don't have a Russian parent or haven't studied
Russian as major in a university? This kind of 'sidetracking' in
arguments clearly demonstrates that you are a liar. Actually it isn't
worth my answering to such stuff. If you have evidence, then show
it!!! Most part of this thread is still online. You just have to name
the date and time and everyone in this group can immediately verify
whether what you claim is true or not. But I do answer to this point
in order that more people know (or remember once again) what kind of
truth value your postings can generally be expected to have!
>
> ...snip..
> > >
> > > Well if you bothered to look at my code or examples then you can
> > > see what the method does. But your mind up to this point is to closed
> > > and to lazy to look. The point is you don't have to put all zeros
> > > or ones in. It just seems that most people who code sompression routines
> > > never give much thought about how to end the file in a nice way.
> >
> > I wrote (or didn't real my post carefully??) that, among others
> > it is illegal for me to fetch crypto-code from US. Any if you have
> > any good method, it is certainly possible to express that in
>
> I have read your posts though I can't figure out why. You can never
> seem capable of simple reasoning. Since I guess I must state AGAIN
> that the COMPRESSION CODE is not ENCRYPTION why you can't see that
> is beyond me. Yes the compression code with examples sources and
> an executable is at me site. But if you could read and was able to
> retain this fact you would already know that since THIS WAS EXPLAINED
> very carefully to you before.
> But I realize that even after reading this again you still will
> not understand what I have said. So I will no longer anwser posts
> in this thread with you until you make some sense. So good bye.
You stated previously that compression is now incorporated into your
crypto code. So unless you posted the compression part entirely separate
from the crypto code there is no legal way I can access that. And
if a site contains crypto code and non-crypto stuff, I am not sure
whether accessing the non-crypto stuff is without problem, if the
site does not provide a mechanism to separate those that want to
download codes into two groups, one for US and the other for the rest
of the world. (I should appreciate it, if someone would say something
definite to this point.)
But if you really have an ingenious method of dealing with the file
ending problem of Huffman encoding, why do you take the trouble of
writing such lengthy 'augumentations' as you have done till now? It
would take you, I estimate, a maximum of 20 lines of plain English to
explain how you deal with that without employing an EOF. Let me put
the problem once again in the clear: Suppose we use a file type for
output of compression that needs to have a multiple of 32 bits. The
Huffman encoding of the proper input text has a length equal to
m*32 + k. If k > 0, what shall one put into the last 32 - k bit
positions? Isn't this a very clearcut question?? Now please say in
simple English sentences what you are going to put there. There must
be something there, it can't be vacuum. Your operating system might
allow you to do nothing, in which case it would let you have just
what by chance was there, i.e. some rubbish. You can put some regular
or irregular (random) bits there. Are there any other possibilities???
Evidently none can exist. In all cases there is a chance that
on decompression the algorithm will deliver a bogous symbol back to
the user because these 32 - k bits could be interpreted by the
Huffman table you use, unless there is an EOF marking the end of
the proper message. Now PLEASE react exactly to what I wrote
above and not use anything to 'sidetrack' and avoid the proper
point of discussion through throwing in other topics that are not
or only remotely connected to this!!
You have always been putting up unsubstantiated claims. When one
asks you detailed questions (or ask for evidence as is the issue
about 'Yes and No' above) you simply throw in something ununderstanable
or false or just do sidetracking, diverting the readers' attention
to something quite different. Up till now I have been very reluctant
in suspecting that your crypto codes are not of good quality as
a number of people have claimed in this group. But your strange
behaviours in discussion alone lead me to think that there is an
essentially high probability that these people are indeed right.
M. K. Shen
------------------------------
From: Piso Mojado <[EMAIL PROTECTED]>
Subject: Re: Shamir's Discover: to those in the know
Date: Thu, 06 May 1999 02:36:06 -1000
> > In article <7gnsm8$316$[EMAIL PROTECTED]>, SCOTT19U.ZIP_GUY
> <[EMAIL PROTECTED]> writes:
> >
> > > I wonder if any one has been smart enough to see how rapidly
> > > RSA key lengths have been increasing over the last few year to
> > > be safe. All one gets to read about is that key lenght of X can
> > > be found in Y time but keys of X+N are safe till the sun burns
> > > out. But it seems that new methods are found every year so it
> > > seems reasonable that newer methods will be found in just a few short
> > > years but the articles just replace the old X+N with a new value
> > > for X and never mention a few years ago it was safe forever.
> > > Are there any plots based on this kind of projection.
Yes. The Sun was originally projected to last forever, but the
estimates have changed greatly over the years. An estimate was made
in the second century, that accepted the fate of Damoclese to include
solar extinction in 2000 years. This was increased with the hydrogen
consumption calculations of Gilbert, which concluded that the burning
would only last for 1 million years. Nucular reactions were proposed
in this century that put the Sun's demise in the 10 millionth
millenium ( or 10,000,001 millenium for perfectionists). Fortunately
for cryptographers, there are not enough zeros and ones in the
known universe to exhaust the supply of estimates which that time span
allows us.
------------------------------
From: [EMAIL PROTECTED] (J.H.M. Dassen (Ray))
Crossposted-To: comp.security.unix
Subject: Re: Commercial PGP for Linux?
Date: 6 May 1999 09:35:41 GMT
[Followup-To: set]
Bernie Cosell <[EMAIL PROTECTED]> wrote:
>Well, just to close off this thread, I thought I'd mention that I called
>NAI and discovered that a _one_year_, _single_server_ license for PGP for
>Linux is *two*thousand*dollars*. Ouch!!
The GNU Privacy Guard (http://www.gnupg.org) is free software (GPL),
implements OpenPGP and is largely interoperable with PGP5. Depending on your
location, you may also be able to use the RSA and IDEA modules that are
available for it separately to achieve interoperability with PGP2.
HTH,
Ray
--
Cyberspace, a final frontier. These are the voyages of my messages,
on a lightspeed mission to explore strange new systems and to boldly go
where no data has gone before.
------------------------------
From: Stephen Early <[EMAIL PROTECTED]>
Subject: Re: DECT/GAP cordless phone encryption algorithm
Date: 6 May 1999 10:03:02 GMT
In article <[EMAIL PROTECTED]>,
Rene Laederach <[EMAIL PROTECTED]> wrote:
>Does anybody have a good link or information about the
>encryption algorithm used in DECT/GAP cordless telephones
>(like the Siemens Gigaset series) or is this one more of
>these 'security through obscurity' schemes?
It's another 'security through obscurity' scheme, I'm afraid. The DECT
standards documents define a 'DECT Standard Authentication Algorithm'
which all DECT/GAP equipment manufacturers are required to implement,
and a 'DECT Standard Cipher' which manufacturers may implement if they
wish. They may also choose to implement their own algorithms in
addition.
The algorithms are defined in Annexes H and J of EN 300 175-7 (Digital
Enhanced Cordless Telecommunications Common Interface Part 7: Security
features) which you can download from the ETSI document search page,
http://webapp.etsi.org/PublicationsSearch/home.htm - but unfortunately
the published version just says:
The DECT Standard Authentication Algorithm is only available on a
restricted basis. For further information please contact ETSI.
and
The DECT Standard Cipher (DSC) is only available on a restricted
basis. For further information please contact ETSI.
Annex A of this document (Security threats analysis) is quite
interesting.
Steve Early
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Roulettes
Date: Thu, 6 May 1999 09:31:11 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>Boris Kazak wrote:
>>
>
>> Just use octahedric dice (8faces) and get your random numbers in octal.
>
>Are such dices on sale? BTW, maybe Rubik's cube (there is also a
>4*4*4 variant) and similar toys could be of use.
Yes, go to a game store and you can get N-sided dice for
various N including N=4, 6, 8, 10, 12, 20, etc.
Of course N=6 is the easiest to find. N != 6 is mostly
used for role playing games like Dungeons and Dragons.
------------------------------
** 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
******************************
