Cryptography-Digest Digest #73, Volume #12 Tue, 20 Jun 00 17:13:01 EDT
Contents:
Re: Flattening of frequency distributions (Stefan Schlott)
Re: New Hash Function (David A. Wagner)
URL for The Gold Bug (Re: Classical Crypto Books) ([EMAIL PROTECTED])
Re: Variability of chaining modes of block ciphers (Mok-Kong Shen)
Q: Computing with Gaussian numbers (Mok-Kong Shen)
Re: Variability of chaining modes of block ciphers (Mok-Kong Shen)
Re: Variability of chaining modes of block ciphers (Mok-Kong Shen)
Linear Feedback Shift Register *with* lock-up? (Ponder)
Re: Is this a HOAX or RSA is REALLY broken?!? (Anton Stiglic)
Re: How RSA SecurID tokens work? (Vin McLellan)
Re: How RSA SecurID tokens work? (Vin McLellan)
Re: Linear Feedback Shift Register *with* lock-up? (Nick Maclaren)
Re: Encryption on missing hard-drives (Paul Rubin)
Re: small subgroups in Blum Blum Shub (Mok-Kong Shen)
Re: Weight of Digital Signatures (Mok-Kong Shen)
Re: Cryptographic voting ("Rick Braddam")
Re: Is this a HOAX or RSA is REALLY broken?!? ("Trevor L. Jackson, III")
Re: Is this a HOAX or RSA is REALLY broken?!? (JCA)
Re: Double Encryption Illegal? (JCA)
Re: small subgroups in Blum Blum Shub (lcs Mixmaster Remailer)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Stefan Schlott)
Subject: Re: Flattening of frequency distributions
Reply-To: [EMAIL PROTECTED] (Stefan Schlott)
Date: 20 Jun 2000 20:12:27 +0100
On Mon, 19 Jun 2000 20:24:36 +0200,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>> That's what the following encryption process is for.
>But if a secret key is involved in the flattening process, you have
>in effect a multiple encryption.
I did make a distinction between multiple encryption and simply
flattening distributions.
>> You asked for a way to flatten distributions in natural language,
>> because exploiting uneven distributions are a classic tool of crypt-
>> analysis.
>> Compressing your text before encrypting it will do that. You might
>> run into trouble with data which cannot be compressed with the codec
>> in use. Further (as I already mentioned), special care should be given
>> when storing the data necessary for decompression; when not done
>> properly, this will lead to known-plaintext attacks.
>Are you assuming that the compression algorithm is secret? If not,
>and there is no secret key involved, then the opponent can decompress,
>so that he is in the same situation as if no compression has been done.
The analysis is more difficult since you cannot exploit distributions
of natural language. But: Yes, anyone can decompress the compressed
text - after decrypting it. As I already said: I thought you wanted to
go for something different than multiple encryption.
Stefan.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: New Hash Function
Date: 20 Jun 2000 11:14:58 -0700
Well, for one, there is an inversion attack with 2^96 complexity,
which is much less than you'd expect for a 192-bit hash. The reason
is that your chaining function can be computed in both the forward
and backwards direction, so you can do a meet-in-the-middle attack.
The fix? Use a Davies-Meyer-like construction, i.e., change
/* perform the rounds */
for (r = 0; r < ROUNDS; ) {
F(out, out+3, &W[3*r++]); F(out+3, out, &W[3*r++]); }
to
for (i=0; i<6; i++)
oldout[i] = out[i];
/* perform the rounds */
for (r = 0; r < ROUNDS; ) {
F(out, out+3, &W[3*r++]); F(out+3, out, &W[3*r++]); }
for (i=0; i<6; i++)
out[i] += oldout[i];
------------------------------
From: [EMAIL PROTECTED]
Subject: URL for The Gold Bug (Re: Classical Crypto Books)
Date: Tue, 20 Jun 2000 18:07:30 GMT
The Gold Bug is also available free online at
http://bygosh.com/Features/062000/goldbug.htm
It is the current featured short fiction on http:/byGosh.com
--> Westcoasting
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (CryptoBook) wrote:
<snip>
> THE GOLD BUG
> by Edgar Allen Poe
> Published at $13.95.
<snip>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Variability of chaining modes of block ciphers
Date: Tue, 20 Jun 2000 20:36:56 +0200
Runu Knips wrote:
> Mok-Kong Shen wrote:
> > The most popular block chaining mode seems to be CBC.
> > There is also PBC which chains with plaintext blocks.
> > One can also accumulate the previous blocks for doing the
> > chaining and use plaintext as well as ciphertext for
> > chaining. (I used this in one of my own designs.) By
> > combinatorics this gives 8 variants. Obviously one can
> > also use modular addition instead of xor and do some
> > random rotations if one likes. I think that the variability
> > of chaining modes could be advantageousy exploited such
> > that the actual chanining mode used in a message has to be
> > guessed by the opponent, thus redering his task much more
> > difficult.
>
> I don't like that. While ciphertexts have the known property
> of having no statistical properties and depend upon all
> texts before the actual one, XOR'ing with the previous
> plaintext has no such property. Just think about the case
> that the plaintext consists of nothing but zero. PBC is much
> more like EBC than like CBC.
Ciphertext is always available to opponent, so he knows what is
to be xor-ed out. Plaintext is not always available. That I suppose
can be an essential difference.
> XOR'ing with both the previous plaintext block and the last
> cipherblock is possible but I can't see the big advantage, as
> well as using '+' instead of XOR etc.
The first point is answered above. The second is to provide a
variability, i.e. the opponent has to guess whether + or xor
is used.
> And using a different chaining method than CBC might confuse
> the opponent, but not much more than using a nonstandard
> cipher algorithm, isn't it so ?
But, in case you (like plenty of people) have only one single favourite
algorithm, you can at least do something in that direction.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Q: Computing with Gaussian numbers
Date: Tue, 20 Jun 2000 20:37:38 +0200
The factorization problem and the discrete logarithm problem
can obviously have parallels in the domain of Gaussian
numbers (if the exponent of the latter problem is restricted
to integers).
Question: Do the problems with the Gaussian numbers have
advantages/disadvantages from the point of view of
cryptography? Why?
Thanks.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Variability of chaining modes of block ciphers
Date: Tue, 20 Jun 2000 20:37:07 +0200
Guy Macon wrote:
> Runu Knips wrote:
>
> >And using a different chaining method than CBC might confuse
> >the opponent, but not much more than using a nonstandard
> >cipher algorithm, isn't it so ?
>
> I like the idea that you nassume that your attacker knows everything
> except the plaintext and the key, and has more resources and cleverness
> than you do. Limiting yourself to improvements that still improve
> your security under this standard seemms wiser than adding improvements
> that require secrets algorithms, chaining methods, etc (unless the
> algorithm, etc is selected by a part of the key not used elsewhere).
To exploit the variability, the chaining mode is determined by the key
or a separate 'key'.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Variability of chaining modes of block ciphers
Date: Tue, 20 Jun 2000 20:37:27 +0200
Paul Koning wrote:
> Mok-Kong Shen wrote:
> > ...I think that the variability
> > of chaining modes could be advantageousy exploited such
> > that the actual chanining mode used in a message has to be
> > guessed by the opponent, thus redering his task much more
> > difficult.
>
> Make that "very slightly more difficult".
It depends on the situation. Sometimes a factor of 2 could make a
difference, especially if value of information is time dependent. Of
course, if one's opponent is omnipotent, say possessing an oracle,
then one could just as well send plaintexts.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Ponder)
Crossposted-To: comp.theory,sci.math
Subject: Linear Feedback Shift Register *with* lock-up?
Date: 20 Jun 2000 18:19:09 GMT
I'm looking to use a Linear Feedback Shift Register to implement
a counter with minimal resources (i.e. fewer gates and wires than
an additive incrementor). I've seen quite a bit of cryptographic
literature on how to use an N-bit LFSR to count through (2^N)-1
values before repeating. There is one value (usually all 0's or
all 1's) where the LFSR would be "stuck" at the same value as
it counts.
What I'm really looking for, though, is an LFSR that counts
through 2^N values and then *does* get stuck in the last state.
This way when I find it stuck, I would know that it counted through
all the values since its initial state. There would be one
"minimal" value for the initial state, that would cause it to
count through all 2^N values before sticking; if I want to count
fewer steps I would pick an initial value further along the
sequence.
Does anyone out there know how to do this? I've looked at some
of the polynomial theory on LFSR's, but guess that it only
applies to counters that actually loop through a sequence rather
than iterating through a sequence and looping on a final value.
Also, is there a good algorithm for converting the elements of
an LFSR sequence into the actual value of the count? (Or more
precisely, for mesuring the number of iterations between two
values). For small N you could just count through the sequence
until you find a match, but I'm interested in N around 32 or 64
so this would take too long.
Thanks in advance,
Carl Ponder
[EMAIL PROTECTED]
--
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Carl Ponder, Ph.D. Carl Ponder [EMAIL PROTECTED]
AIX Performance Tools IBM Server Division Phone: (512) 838-1638
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Is this a HOAX or RSA is REALLY broken?!?
Date: Tue, 20 Jun 2000 14:37:35 -0400
tomstd wrote:
>
> [EMAIL PROTECTED] (Mark Wooding) wrote:
> >S. T. L. <[EMAIL PROTECTED]> wrote:
> >> <<The optimists in the field believe that in 5 or 10 years
> >> it will be possible to build a quantum computer that can
> >> factor the number 4 as 2x2.>>
> >>
> >> I believe that 15's already been factored. Now for something
> big,
> >> like 77....
> >
> ><fx: hand in the air> Ooh! Ooh! I can do that one!
>
> Simple 77 = 23 * 9. I am glad I am doing goodly in math.
>
> Tom
Well of course he was working mod 130, we all knew that!
:)
Anton
------------------------------
From: Vin McLellan <[EMAIL PROTECTED]>
Subject: Re: How RSA SecurID tokens work?
Date: Tue, 20 Jun 2000 14:45:11 -0400
Daniel James wrote:
> I notice from RSA's website that it's possible to use a PalmPilot device as a
> SecurID. How is the key initialized in this case, and how securely is it
> protected in the handheld device?
>
Prescient questions.
The PalmPilot-hosted SecurID is a wholly-software token-emulation
module, equivalent to the "soft-token" SecurID (aka "SoftID") for
desktop PCs that RSA has sold for many years. The SoftID is typically
used on PCs in corporate networks which can boast strong physical access
control and workgroup security.
The PalmPilot SecurID modules are freely available off the RSA website.
(You can even "beam" the module from one PalmPilot to another, and it
will run in demo mode!) RSA manages the commercial market by controlling
access to the true-randon keys which become the shared secret between a
PalmPilot SecurID and the ACE/Server it is registered on.
When you buy traditional SecurID tokens, RSA ships you a box of
physical tokens and a floppy or CD with an encrypted file of the keys
embedded in those tokens which is loaded on the ACE/Server.
When you buy SecurID modules for the PalmPilot, RSA ships you a floppy
or CD with an installer which will embed a key in each Palm SecurID
module, and an encrypted file of those keys, indexed, which is loaded
among the user records on the ACE/Server.
The relative security of that token-specific key in each the PalmPilot
SecurID is, inevitably, an issue. As with any software-based security
device, the integrity of the SecurID module for the Palm Pilot -- and
the security with which the code module holds its secrets -- is largely
dependent upon its physical security of its host.
RSA designed a series of internal defensives into the PalmPilot module,
of course, just as it did with the SoftID module for PCs.
The protocol which allows the PalmPilot SecurID to store a backup copy
of itself on a PC, for instance, protects the backup key file with 3DES
encryption. In another feature, the SecurID module -- when it is
initialized on the user's PalmPilot -- grabs some Pilot-specific
information and integrates it in a cryptographic defense which should
make it difficult to transfer an initialized SecurID module from its
PalmPilot host to another CPU and make it work.
These are not negligible defenses, but they do not obviate the fact
that this is a software-based app -- with all the increased risk and
inevitable vulnerabilities that entails, should a SecurID-enabled
PalmPilot fall into the hands of an enemy for any length of time.
To a degree considerably greater than is the case with a physical
SecurID token, it is the responsiblity of the hands-on user to
guarrantee that a SecurID-enabled PalmPilot is kept at hand, physically
(and virtually) safe, and that its loss or theft be quickly reported to
the Network or Security Admin.
Suerte,
_Vin
------------------------------
From: Vin McLellan <[EMAIL PROTECTED]>
Subject: Re: How RSA SecurID tokens work?
Date: Tue, 20 Jun 2000 14:53:37 -0400
Daniel James wrote:
> I notice from RSA's website that it's possible to use a PalmPilot device as a
> SecurID. How is the key initialized in this case, and how securely is it
> protected in the handheld device?
>
Thoughtful questions.
The PalmPilot-hosted SecurID is a wholly-software token-emulation
module, similar and equivalent to the "soft-token" SecurID (aka
"SoftID") for desktop PCs that RSA has sold for many years. The SoftID
is typically used on PCs in corporate environments which can boast
strong physical access control and workgroup security.
The PalmPilot SecurID modules are freely available off the RSA website.
(You can even "beam" the module from one PalmPilot to another, and it
will run in demo mode!) RSA manages the commercial market by controlling
traffic in the true-randon keys (which become the shared secret between
a PalmPilot SecurID and the ACE/Server it is registered on.)
When you buy traditional SecurID tokens, RSA ships you a box of
physical tokens and a floppy or CD with an encrypted file of the keys,
which are embedded in those tokens, to be loaded on the enterprise's
ACE/Server.
When you buy SecurID modules for the PalmPilot, RSA ships you a packet
of keys essentially -- a floppy or CD with an installer which will embed
a key in each Palm SecurID module, and an encrypted file of those keys,
indexed, which is to be loaded among the SecurID user records on the
ACE/Server.
The relative security of the token-specific key in each the PalmPilot
SecurID is, inevitably, an issue. As with any software-based security
device, the integrity of the SecurID module for the Palm Pilot -- and
the security with which the code module holds its secrets -- is largely
dependent upon the physical security of its host.
RSA designed a series of internal defensives into the PalmPilot module,
of course, just as it did with the SoftID module for PCs. The protocol
which allows the PalmPilot SecurID to store a backup copy of itself on a
PC, for instance, protects the backup key file with 3DES encryption.
In another feature, the SecurID module -- when it is initialized on the
user's PalmPilot -- grabs some Pilot-specific information and integrates
it in a cryptographic defense which should make it difficult to transfer
an initialized SecurID module from its PalmPilot host to another CPU and
make it work.
These are not negligible defenses, but they do not obviate the fact
that this is still a software-based app -- with all the increased risk
and inevitable vulnerabilities that entails, should a SecurID-enabled
PalmPilot fall into the hands of an enemy for any length of time.
To a degree considerably greater than is the case with a hardware
SecurID token, it is the responsiblity of the hands-on user to
guarrantee that a SecurID-enabled PalmPilot is kept at hand, physically
(and virtually) safe; and that its loss or theft be quickly reported to
the Network or Security Admin.
Suerte,
_Vin
------------------------------
From: [EMAIL PROTECTED] (Nick Maclaren)
Crossposted-To: comp.theory,sci.math
Subject: Re: Linear Feedback Shift Register *with* lock-up?
Date: 20 Jun 2000 19:35:19 GMT
In article <8iocit$1ghu$[EMAIL PROTECTED]>,
Ponder <[EMAIL PROTECTED]> wrote:
>
>What I'm really looking for, though, is an LFSR that counts
>through 2^N values and then *does* get stuck in the last state.
>This way when I find it stuck, I would know that it counted through
>all the values since its initial state. There would be one
>"minimal" value for the initial state, that would cause it to
>count through all 2^N values before sticking; if I want to count
>fewer steps I would pick an initial value further along the
>sequence.
Sorry - no such thing. Such generators have algebraic properties
that make such characteristics impossible.
There are generators that have such properties, but I know of
none that are pseudo-random in any reasonable sense.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: [EMAIL PROTECTED]
Tel.: +44 1223 334761 Fax: +44 1223 334679
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Encryption on missing hard-drives
Date: 20 Jun 2000 20:01:39 GMT
In article <[EMAIL PROTECTED]>,
Paul Koning <[EMAIL PROTECTED]> wrote:
>"Trevor L. Jackson, III" wrote:
>> ...
>> There may be a simpler method. Due to the volume of cooling air required,
>> most laptops and all PCs quickly become coated with a layer of dust. Merely
>> opening the case will disturb the dust sufficiently to be detectable.
>
>Yes, if the issue were detection of the fact that a drive has
>been removed from a PC. I don't think that's the issue here.
>First of all, that's known to be the case (because they were
>found outside a PC). Second, this is probably one of those
>places that removes hard drives all the time for security
>reasons. (You can store a drive more easily in a safe than
>a whole desktop PC.)
They were laptop disk drives in removable cartridges, or at least
that's what they looked like on CNN.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: small subgroups in Blum Blum Shub
Date: Tue, 20 Jun 2000 22:20:02 +0200
Mark Wooding wrote:
> [snip]
>
> OK. Let p, q be prime numbers, p = q = 3 (mod 4), and let n = p q.
> Choose an integer x, 0 < x < n. Then y = x^2 (mod n) is a quadratic
> residue, mod n.
>
> I claim (a) that y has four square roots, mod n, and (b) that exactly
> one of these square roots is a quadratic residue.
Counter-example: p=3, q=7, n=21. 7 is quadratic residue, since
7^2 = 49 = 7 mod n. However 7 has only 2 square roots: 7 and 14.
(Bryan Olson's proof must also have a bug somewhere.)
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Weight of Digital Signatures
Date: Tue, 20 Jun 2000 22:45:14 +0200
"Douglas A. Gwyn" wrote:
> Greg wrote:
> > ... Kudos to all who have had any
> > hand in helping the government see the light (finally)...
>
> Unfortunately, that probably means that even when an insecure
> digital signature scheme is used, you cannot refuse personal
> responsibility when you're forced to use it anyway.
Indeed it seems impossible to totally eliminate the risk. But consider
a parallel issue: If I get $100 from a teller machine and my account
is deducted $500, could I do anything?
M. K. Shen
------------------------------
From: "Rick Braddam" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Cryptographic voting
Date: Tue, 20 Jun 2000 15:07:20 -0500
Reply-To: "Rick Braddam" <[EMAIL PROTECTED]>
"zapzing" <[EMAIL PROTECTED]> wrote in message
news:8io3oj$cva$[EMAIL PROTECTED]...
[ In article <[EMAIL PROTECTED]>,
[ [EMAIL PROTECTED] wrote:
[ > In sci.crypt zapzing <[EMAIL PROTECTED]> wrote:
[ > > In article <[EMAIL PROTECTED]>,
[ > > [EMAIL PROTECTED] wrote:
[ > >> Back to crypto voting, I'm going to point out something that is a
[> > > slight variation of what has been discussed.
[ > >>
[ > >> When you register to vote, which, at least in Florida you must do
[ > >> in person, you could be issued a key pair. They would fill out
[ > >> the registration card on paper. You would then go over to a
computer
[ > >> and get your random key pair, the public key key would be
registered
[ > >> by the computer as "in use" but your name would not be attached,
although
[ > >> a "registered to voter 193687" could be also issued, with the
193687
[ > >> just being a number that has no links to a specific individual.
[ > > The real problem would probably be that there would be
[ > > nothing stopping someone from registering in one place,
[ > > then going somewhere else and registering there.
[ >
[ > The fact that their name was checked off doesn't show an extra vote.
The voter could be required to show a picture ID (driver's license) which
has their address on it to establish identity (as is done in Florida), and
registration could be limited in the sense that you must register within
the county where you reside. The county's computers could easily determine
if you were already registered.
[ Well if you are going to have a name check
[ off system you are going to have to deal with the
[ issues of how do you compile the list initially
[ and how do you identify people when they are
[ registering so that they don't register as their
[ neighbor whom they know sleeps late, and then
[ go somewhere else and register as themselves.
[
[ > Of course, this brings up the question of what happens when I lose
[ > my key? Oh well, back to the drawing board. :)
Just go in a rer
egister... which could require multiple proofs of identity instead of just
one. The system would invalidate the previously issued keys and issue new
ones.
[ Such people simlply do not deserve to vote!
Rick
------------------------------
Date: Tue, 20 Jun 2000 16:52:11 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Is this a HOAX or RSA is REALLY broken?!?
Anton Stiglic wrote:
> tomstd wrote:
> >
> > [EMAIL PROTECTED] (Mark Wooding) wrote:
> > >S. T. L. <[EMAIL PROTECTED]> wrote:
> > >> <<The optimists in the field believe that in 5 or 10 years
> > >> it will be possible to build a quantum computer that can
> > >> factor the number 4 as 2x2.>>
> > >>
> > >> I believe that 15's already been factored. Now for something
> > big,
> > >> like 77....
> > >
> > ><fx: hand in the air> Ooh! Ooh! I can do that one!
> >
> > Simple 77 = 23 * 9. I am glad I am doing goodly in math.
> >
> > Tom
>
> Well of course he was working mod 130, we all knew that!
Ah yes, the invisible implicit modulus. Aren't they supposed to be prime?
------------------------------
From: JCA <[EMAIL PROTECTED]>
Subject: Re: Is this a HOAX or RSA is REALLY broken?!?
Date: Tue, 20 Jun 2000 13:35:41 -0700
Jerry Coffin wrote:
>
> I think there's another basic point to keep in mind: what's
> considered AI changes over time. 50 years ago, speech recognition,
> hand-writing recognition and OCR were all considered legitimate
> subjects of AI research. Now, they're all just normal programs, and
> nobody thinks of them as related to AI at all.
Hmm... I cheerfully disagree. Maybe the AI community does not
consider them AI problems any longer, but these issues are far from
closed. To my knowledge no existing system in the classes you mention
even begins to approach human prowess at those tasks.
I find speech recognition systems particularly irritating (at least
those
I have had the chance to check) because of their inveterate stupidity and
narrowness. This is not an insult thrown at their designers, who surely
are the best of the best. Rather, it is a manifestation of the enormous
difficulty of the problem, which was grossly underestimated by AI
practitioners during the late 60s and 70s.
To my view, those are open problems in AI for which we have partial
solutions that are not really up to the task of catering for human
consumption in mass.
> IOW, for the most part "AI" is simply used to refer to areas we don't
> know how to deal with effectively yet.
Precisely. And I think the three problems you mentioned qualify
big time. I would also add that of machine translation. Though
undeniably useful, its results are more often than not a source of
laughs rather than real information. I recall having interacted over
the email with a Japanese woman who typed her messages to me
in Japanese, having them automatically translated into English
before sending them. The results were quite often amusing, and
most of the time almost unintelligible.
------------------------------
From: JCA <[EMAIL PROTECTED]>
Crossposted-To: comp.databases.oracle
Subject: Re: Double Encryption Illegal?
Date: Tue, 20 Jun 2000 13:39:53 -0700
Our friends from the NSA, when doing their customary review of crypto
products used to demand, till recently, that a check be put in place to
prevent
double encryption from being carried out. They might not require this any
more in light of the new regulations though.
Crypto-Boy wrote:
> On page 10-10 and 10-14 of the Oracle Advanced Security Administrator's
> Guide (from release 8.1.6 December 1999), it says the following (in bold
> no less):
>
> "Warning: You can use SSL encryption in combination with another Oracle
> Advanced Security authentication method. When you do this, you must
> disable any non-SSL encryption to comply with government regulations
> prohibiting double encryption."
>
> Since when is it illegal to double encrypt in the US? I don't believe
> this is true.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
Date: 20 Jun 2000 21:00:09 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: small subgroups in Blum Blum Shub
Terry Ritter writes:
> I do have a different model, but it is not a model of computation. My
> model is what I perceive as the basis for the entire field of
> cryptography: The need to find a system which is secure against any
> possible attack. Mathematics being presumably the way to reach such a
> result, "proven secure" is well-understood to be the goal of
> cryptography itself. It is not a term to be usurped and re-defined as
> something less. The general unqualified use of it as a term-of-art is
> deceptive to newbies, managers, and managing directors. It might even
> be seen as a marketing term.
You are the main person spreading the misinformation that BBS is "proven
secure" in your bizarre sense if you use special primes and seeds.
Do you honestly think that doing so makes for an RNG which is "secure
against any possible attack" (your words)? What about factoring?
Isn't that a possible attack?
The fact is, the proof of security with BBS is what is standard in
cryptography. It is a reduction proof. BBS is as secure as factoring
(actually quadratic reciprocity). That's all the BBS paper claims.
They never said that the RNG was "secure against any possible attack".
Only a fool would make a claim like that.
------------------------------
** 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
******************************
