Cryptography-Digest Digest #41, Volume #12 Fri, 16 Jun 00 02:13:01 EDT
Contents:
Re: small subgroups in Blum Blum Shub (Bryan Olson)
Re: Is there a program simlar to Norton Scecret Stuff with better encryption?
(JPeschel)
Re: Random sboxes... real info (Nicol So)
Re: Evidence Eliminator Dis-Information Center (Anonymous)
Re: Is Gretchen down? (Patrick Farrell)
Re: Cipher design a fading field? ("Douglas A. Gwyn")
Re: Cipher design a fading field? ("Douglas A. Gwyn")
Re: My lastest paper on Block Ciphers ("Douglas A. Gwyn")
Re: quantum cryptography at nytimes.com ("Douglas A. Gwyn")
Re: Is Gretchen down? ("Trevor L. Jackson, III")
Re: Cipher design a fading field? (Benjamin Goldberg)
oneway encryption for password (Sisson)
Re: salt length? ("Scott Fluhrer")
Re: oneway encryption for password (S. T. L.)
----------------------------------------------------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: small subgroups in Blum Blum Shub
Date: Fri, 16 Jun 2000 03:03:41 GMT
Terry Ritter wrote:
>
> Nicol So
>
> >Terry Ritter wrote:
> >>
> >> lordcow77
> >> >Essentially, the existence of exploitable cycles in BBS would
> >> >neccesarily lead to an efficient algorithm for decomposing RSA
> >> >moduli into primes. As such, if you believe that the factoring
> >> >of numbers in that range is a difficult problem, you need not
> >> >loose sleep over the miniscule probability that you will land in
> >> >a short cycle. The nonsense about choosing "strong primes" or
> >> >good initialization values is a remnant to the past where it was
> >> >thought that a relatively small prime (if well chosen) would be
> >> >adaquately strong.
> >>
> >> I think your interpretation is wrong, and I recommend the BB&S
paper
> >> to you:
> >>
> >> Blum, L., M. Blum and M. Shub. 1983. Comparison of Two
Pseudo-Random
> >> Number Generators. Advances in Cryptology: CRYPTO '82 Proceedings.
> >> Plenum Press: New York. 61-78.
[...]
> >lordcow77's interpretation is correct. The safety of using randomly
> >chosen primes of appropriate sizes is built into the underlying
> >intractability assumption. To put things in perspective, the whole
point
> >of using cryptography is to reduce the probability of "bad things
> >happening" to some acceptably low level, say 2^{-L} for some
> >sufficiently large L. (There's no defense against dumb luck on the
part
> >of the adversary). Not using special primes may affect the value of L
> >for a given choice of security parameter (so you may have to adjust
your
> >security parameter), but it does not affect the asymptotic behavior
of
> >security as a function of the security parameter.
>
> "To put things in perspective," I suggest you try to follow my
> reasoning before trying to refute it.
I think you didn't understand lordcow77's or Nicol So's
reasoning. There's is correct. The long-cycle analysis in
the BBS paper is interesting but not the major result.
> As you would have seen had you actually read and understood my
> comments, the statement in question was:
>
> >> >The nonsense about choosing "strong primes" or
> >> >good initialization values is a remnant to the past where it was
> >> >thought that a relatively small prime (if well chosen) would be
> >> >adaquately strong.
>
> And that is nonsense. I am unaware of any such "thoughts." Exactly
> where do you disagree, and what is your evidence?
You are unaware of the refutation of the notion of "strong
primes" for factorization-based systems? The logic here is
the same: we do not worry about special cases, other than to
choose our keys so that they are of negligible probability.
The disagreement was explained. Falling into a short cycle
from a random starting point is no more likely than falling
into a factorization. The major result of the BBS paper is
that prediction of the sequence is intractable under the
assumption that factoring the modulus is also intractable.
> On the other hand, the larger question of X^2 mod N security (not part
> of my earlier comments) is swept under your asymptotic rug. But real
> systems are *not* asymptotic. All real BB&S systems *do* have short
> cycles. And short cycles *are* weak. Yes, it is unlikely to select a
> short cycle at random. But unless the BB&S prescriptions are
> followed, that is *only* "unlikely" and *not* "impossible." In
> contrast, the BB&S prescriptions *guarantee* that one does not use a
> short cycle, and that is a qualitative difference.
Users of a broken system don't care if the system was broken
by calculating the state or finding a cycle. We cannot
reduce the chance of failure to zero, so we settle for
vanishingly unlikely. The weakest point in the "proof" of
security is of course the assumption of the intractability
of factoring.
> As I see it, the issue is *not* strength in practice, it is instead
> the claim to have a provably secure system. I think we can accept
> that all cryptography is vulnerable to opponents choosing the right
> key at random. But I claim that no system can be provably secure if
> it includes the possibility of selecting and using weakness, no matter
> how small that possibility may be.
Nonsense. Any individual key or small set of keys is weak.
If we accept the danger of the key-guessing attack, then
dumb luck ensures that we will use a system the attacker can
break with some vanishingly small probability.
If we cannot tolerate any chance of "using weakness, no
matter how small", then we must join the newbies who object
to the one-time pad on the grounds that a truly random pad
*might* be all zero.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Is there a program simlar to Norton Scecret Stuff with better encryption?
Date: 16 Jun 2000 03:14:55 GMT
[EMAIL PROTECTED] writes:
>This program I always liked, it was pretty straightforward. Uses a
>good algorythm(Blowfish), creates self-decrypting files so that those
>that don't have the program need only a password. The only thing is, I
>think it was only made in 40-bit encryption.
>Does anyone if they ever released a stronger version of Norton Secrte
>Stuff
NSS uses 32-bit Blowfish.
You might want to try Puffer:
http://www.briggsoft.com/software.htm
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: Random sboxes... real info
Date: Thu, 15 Jun 2000 23:12:13 -0400
Reply-To: see.signature
"David A. Wagner" wrote:
>
> Nope, I stand by my statement.
>
> You might want to think about this more carefully. Here's a useful
> thought experiment. Consider the following two universes:
> Universe A: We encrypt using a permutation chosen uniformly at random
> from the set of all permutations.
> Universe B: We encrypt using a permutation chosen uniformly at random
> from everything but the identity permutation.
> I claim that (A) is strictly stronger than (B).
>
> The way to think about this is to look for an attack that lets you
> read encrypted traffic. If you can find an attack which works strictly
> better against (A) then (B), you will have proven your point. I claim
> you can't. Have a try! :-)
[I haven't been following this thread. I'm commenting only on the text
quoted above.]
The simplest example would illustrate your point. Consider a 1-bit
message. (A) leaks no information, (B) everything.
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
------------------------------
Crossposted-To:
alt.privacy,alt.privacy.anon-server,alt.security.pgp,comp.security.firewalls
Subject: Re: Evidence Eliminator Dis-Information Center
Date: Fri, 16 Jun 2000 03:33:08 GMT
From: Anonymous <[EMAIL PROTECTED]>
On 15-Jun-2000, "donoli" <[EMAIL PROTECTED]> wrote:
> I really don't see how he is increasing sales, not he way he presents his
> argument.
> donoli.
I think the spamming by EE support is causing his troubles. He should just let the
hack say his peace and move on. I own EE and it does many things well, along with EE,
I use Scramdisk and Zone Alarm. I haven't had any problems. Actually EE cleared up a
locking explorer.exe problem and cleared 130Mb of data from C drive.
--------== Posted Anonymously via Newsfeeds.Com ==-------
Featuring the worlds only Anonymous Usenet Server
-----------== http://www.newsfeeds.com ==----------
------------------------------
From: Patrick Farrell <[EMAIL PROTECTED]>
Crossposted-To:
alt.security.pgp,comp.security.firewalls,alt.privacy.anon-server,alt.privacy
Subject: Re: Is Gretchen down?
Date: Thu, 15 Jun 2000 22:55:18 -0500
Reply-To: [EMAIL PROTECTED]
A telegraph signal does not fall into the same category as a high speed network
device. Hell if you add a little impedance to a 100baseT cable it will fail,
yet I saw someone stick 2 computers back to back with arcnet cards in them and
put a coat hanger in between and network them.
Little bit different :)
Patrick
"Trevor L. Jackson, III" wrote:
>
> Read some history re transatlantic cables. The telegraph companies swore that the
> messages were private, but everything was copied to the appropriate government
> agency.
>
> What do you think has changed since then?
>
> Patrick Farrell wrote:
>
> > Thanks for the input on the first few points.
> >
> > Well you would think that they would need permission from the carriers to do
> > this. I mean you can't even splice into a 10baseT connection without issues, I
> > don't see how you could tap into a fiber connection without having the carrier
> > do it for you, but maybe they just don't release that technology to the public
> > :)
> >
> > If they were having the carriers do it, I would find it hard to believe that
> > with the ammount of people that would be involved at each major carrier that
> > they could keep the secret of these taps from the public.
> >
> > Patrick
> >
> > Joseph Ashwood wrote:
> > >
> > > > A) you need a pipe equivilant to the sum of the major backbones.
> > > Not if you have a significant computer present at each of those backbones
> > > that performs a significant portion of the filtering for you, then you would
> > > only need a much smaller pipe. Also remember that the vast majority of hose
> > > pipes remain unfilled almost all the time.
> > >
> > > >
> > > > B) you need a computer or cluster that can read and filter on the fly this
> > > > ammount of information
> > > Which can be done, for proof I simply point to the fact that these pipelines
> > > are running, so it can obviously be read. The traffic is being generated by
> > > a small portion of the cpu in a small portion of the computers in the world,
> > > a trojan would be an ideal way to get the processor time needed, after all
> > > the attack is obviously not bounded by lawfulness.
> > >
> > > >
> > > > C) you need a network interface for a data pipe that doesn't exist.
> > > Except that by segmenting the necessities you require much smaller network
> > > interface, on a much smaller pipe.
> > >
> > > >
> > > > D) how does a system with IP range A, on subnet B, see data between
> > > systems C
> > > > and D with completely seperate subnets when the data is never even routed
> > > across
> > > > A's network. Unless you are implying that they have a vampire tap on
> > > every
> > > > major circuit and subcircuit that duplicates all traffic and then reroutes
> > > it to
> > > > their hosts.
> > > They would be forced to have a vampire on each of the major backbones, or at
> > > least the ones with anything of interest. It would be a massive undertaking,
> > > cost a hundred million dollars or so (just a very rough guess), but it is
> > > possible. The next questions should be: what are the necessary backbones?
> > > where is the best location to tap them?
> > > Joe
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
Date: Fri, 16 Jun 2000 04:42:32 GMT
"Norman D. Megill" wrote:
> There exists a program to determine the halting of any program whose
> executable code AND DATA are confined to a finite number of bits.
"The size of a program" in the usual context of Turing automata
means the size of the instructions the automaton is preloaded with.
The available scratch storage is taken as unbounded.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
Date: Fri, 16 Jun 2000 04:55:43 GMT
"Trevor L. Jackson, III" wrote:
> The issue isn't how difficult it is to write the program, but that
> with sufficient ingenuity it is possible to write the program. The
> halting problem states that such a program is impossible to write,
> even for Karnak, if the set of programs is infinite.
There is nothing about an infinite set of programs in the actual
theorem. If it required such a condition, that would imply that
for any given example program P there is a deterministic method M
that creates a program H = M(P) that will determine in finite time
whether or not P halts. Thus, M itself is a component of a fixed
procedure T that applied to *arbitary* P will determine in finite
time whether or not P halts.
proc T(prog P):bool def={ import M(prog):bool; return eval M(P) }
That means that T solves the general halting problem, but we know
that has been shown to be impossible. One concludes that the
starting assumption was false (so such a condition isn't required).
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: My lastest paper on Block Ciphers
Date: Fri, 16 Jun 2000 05:02:45 GMT
Beth Friedman wrote:
> Yes and no. PostScript is device independent for printing, but I've
> had times when I tried to generate a PDF from a PS file where I
> didn't have the fonts used in the file on my system.
That is essentially the *only* real portability problem with the
format, and it applies to PDF also unless the nonstandard font
definitions are embedded within the file.
PDF has some useful features that are irrelevant to this topic,
but its main relevant advantage is that PDF readers are available
from Adobe for free for almost all popular platforms, whereas
PostScript support is less common, at least in the popular Windows
environment.
If you have a PostScript printer, however, a PS format file is
easier and quicker to get printed.
What most experienced Web sites do is offer links to both PS and
PDF formats and let the viewer choose the one that best meets his
needs. These days, there are <whatever>-to-HTML converters, so a
third link to a HTML file is often also present, although some
display quality is lost in the conversion.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: quantum cryptography at nytimes.com
Date: Fri, 16 Jun 2000 05:07:12 GMT
Roger Schlafly wrote:
> The problem is that there is no "guaranteed secrecy".
> The various QC security claims are based on idealized
> systems. A practical QC system is likely to have no
> more security than a conventional one.
I know of people who would disagree with you. Quantum
cryptography is *qualitatively* different from any
conventional cryptography. The practical details are
pretty well understood and the parameters can be tweaked
as a matter of engineering to exceed any stated security
threshold.
------------------------------
Date: Fri, 16 Jun 2000 01:24:34 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To:
alt.security.pgp,comp.security.firewalls,alt.privacy.anon-server,alt.privacy
Subject: Re: Is Gretchen down?
Patrick Farrell wrote:
> A telegraph signal does not fall into the same category as a high speed network
> device.
Correct.
Duplicating telegrams required a massive amount of human effort. Rerouting or T'ing a
high speed network can be done without a man in the loop, so it's drastically easier.
> Hell if you add a little impedance to a 100baseT cable it will fail,
> yet I saw someone stick 2 computers back to back with arcnet cards in them and
> put a coat hanger in between and network them.
>
> Little bit different :)
>
> Patrick
Those who fail to learn from history are doomed to repeat it.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
Date: Fri, 16 Jun 2000 05:37:57 GMT
Mok-Kong Shen wrote:
>
> Benjamin Goldberg wrote:
>
> > Mok-Kong Shen wrote:
> > >
> > > John Savard wrote:
> > >
> > > > Well, if the size of the RAM available to a program is limited, not
> > > > just the size of the program itself, then a program with N bits of
> > > > storage available to it can have only 2^N distinct states. Hence, if
> > > > it doesn't halt after 2^N instructions, it is proven that it will
> > > > never halt.
> > >
> > > You probably mean that execution of each intruction must lead to a
> > > single unique successor state. How about the case that this doesn't
> > > hold, i.e. when the state transition depends on the history?
Hmm, the program has N bits of RAM total [call this the state], and and
to determine what will be the next state, not only uses all of those N
bits, but it magically remembers what those N bits used to be, and uses
that, too.
I *think* that's what you're claiming.
> > That would require allocating memory each time data is added to the
> > history, wouldn't it?
>
> That depends on how much history you want to consider. Compare a
> Markov chain where only the immediatly preceeding state is relevant.
------------------------------
From: Sisson <[EMAIL PROTECTED]>
Subject: oneway encryption for password
Date: Fri, 16 Jun 2000 06:11:16 GMT
hi,
i'm making a program that requires a password to gain access. i was
wondering what the most secure way of encrypting this password is. I
heard that there is a totally secure way of doing this, which cannot be
cracked; the method i heard about did only one-way encryption, so the
original password was encrypted, then the password they enter was
encrypted and then compared... you could never decrypt the password back
into plaintext.
Does someone know how to implement the method i've been describing?
Any help would be appreiciated!
Thanks,
>From Spendabuck
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: salt length?
Date: Thu, 15 Jun 2000 22:53:30 -0700
Elros <[EMAIL PROTECTED]> wrote in message
news:8iak3p$4ejql$[EMAIL PROTECTED]...
> For use with a stream cipher (e.g. RC4), what's a good length for a salt
(S)
> that gets concatenated (&) to the user supplied key (U) before S & U gets
> fed into the cipher?
The whole point of salt is for two reasons:
- Make sure that a combined S & U key is never re-used, even if the user
supplied key is reused. A reused S & U key will generate the same keystream
twice, which is insecure.
- To make sure that when an attacker does a brute force search, then he can
attack only one message at a time.
For both these properties, it is sufficient that the probability of the same
salt being used twice is sufficiently small. Assuming that:
- you pick salt values at random
- that you expect 2**A messages to ever be sent with the same key
- the maximum acceptable probability of ever re-using the same key/salt pair
for a given user key is 2**-B
- that you expect 2**C messages to ever be encrypted by all copies of the
program
- the number of acceptable duplicate salts (over all encrypted messages) for
different messages is 2**D
Then, the number of salt bits you need is approximately:
max( 2*A+B, 2*C-D )
(Proof by furious handwaving)
For example, if you expect no more than 1 million messages to ever be sent
with the same key (A=20), you want no more than a 1 in a billion chance that
you reuse the same keystream (B=30), you can expect a trillion messages over
the lifespan of the program (C=40, and you're overly optimistic about the
success of your program :-), and you wouldn't mind a single pair of messages
encrypted with the same salt (D=0), then you need about max( 70, 80 ) = 80
bits of salt. Any less, and you're likely to violate the security
parameters you requested.
--
poncho
------------------------------
From: [EMAIL PROTECTED] (S. T. L.)
Subject: Re: oneway encryption for password
Date: 16 Jun 2000 06:09:53 GMT
<<i'm making a program that requires a password to gain access. i was
wondering what the most secure way of encrypting this password is. I
heard that there is a totally secure way of doing this, which cannot be
cracked; the method i heard about did only one-way encryption, so the
original password was encrypted, then the password they enter was
encrypted and then compared... you could never decrypt the password back into
plaintext.>>
Well, if the Adversary has access to a system and can modify or run anything he
wants, then he can do anything he damn well pleases, including decompile your
program and rip out any protection. However, if the Adversary can merely view
the contents of a system but can't modify it, then an SHA-1 hash would be
appropriate. And if the Adversary can't view the program code, then there's no
need for encryption.
-*---*-------
S.T.L. My Quotes Page * http://quote.cjb.net * leads to my NEW site.
Pages up: 395 Quotes, 14 reviews of 165 science books, and a review of
the Foundation series. COMING UP: more science book reviews!
------------------------------
** 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
******************************
