Cryptography-Digest Digest #553
Cryptography-Digest Digest #553, Volume #14 Thu, 7 Jun 01 15:13:00 EDT
Contents:
Re: Notion of perfect secrecy (Tim Tyler)
Re: Notion of perfect secrecy (Tim Tyler)
Re: CBC variant (John Savard)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: Best, Strongest Algorithm (gone from any reasonable topic)
([EMAIL PROTECTED])
Alice and Bob Speak MooJoo ("Robert J. Kolker")
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: Notion of perfect secrecy ("Paul Pires")
Re: CBC variant (John Savard)
Re: Knapsack security??? Ahhuh (John Bailey)
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
Re: Notion of perfect secrecy ("Tom St Denis")
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
better yet, perfect secrecy => who cares? ("Tom St Denis")
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Notion of perfect secrecy
Reply-To: [EMAIL PROTECTED]
Date: Thu, 7 Jun 2001 18:05:56 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: "Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
:> Tom St Denis <[EMAIL PROTECTED]> wrote:
:> : "Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
:> :> Tom St Denis <[EMAIL PROTECTED]> wrote:
:> : In his model WHO, WHEN, LENGTH were not the information he wanted to
:> protect.
:>
:> "Who" and "when" are not modelled by Shannon. However length /is/
:> information that relates to the identity of the plaintext
:> (except in the case where all possible plaintexts are the same length)
:> and *is* covered by Shannon's definition of perfect secrecy.
: No they are not.
Yes it is - read Shannon's definition of perfect secrecy.
: When will you realize that the contents of the message are
: what an OTP protects. So if the contents are random than an OTP is
: perfectly secure.
An OTP doesn't have perfect secrecy - the cyphertext leaks information
about the length of the plaintext.
If you don't believe me, just read the definition of perfect secrecy.
:> : You're really mocking the dead here. I sincerely hope you are some
:> : 12yr kid trying to get a rise out of people, otherwise I wonder how you
:> : did in College challenging all your profs without listening to their
:> : proofs... No offense Tim but you have a lot of growing up todo. Even
:> : if you are 76 yrs old you're an immature brat as far as I am concerned.
:>
:> Sorry you feel that way Tom. It seems this is the thanks I get for
:> pointing out your errors. Maybe I won't bother in the future.
: So far it seems #[sci.crypt] vs #[scott, tim].
: I don't think it's my errors
You never do - but it almost always is.
"Unicity distance", "bijection", "ctr mode", "perfect secrecy" - it
seems to be just one thing after another these days in a long stream
of mistakes ;-/
--
__
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
--
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Notion of perfect secrecy
Reply-To: [EMAIL PROTECTED]
Date: Thu, 7 Jun 2001 18:15:53 GMT
Paul Pires <[EMAIL PROTECTED]> wrote:
: Tim Tyler <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
:> Perfect secrecy says that knowledge of the cyphertext must not allow the
:> space of possible plaintexts to be narrowed down at all.
: The space of the possible plaintexts hasn't been narrowed down
: by the application of the OTP. This narrowing is a characteristic
: of the message, not the method.
Yes indeed.
: By this logic no system could have perfect secrecy since that would
: require the method to have control over the composition of all possible
: messages before encryption.
No system can have perfect secrecy and deal with an infinite set of finite
messages.
However perfect secrecy if you are only dealing with a finite set of
messages is possible, and perfect secrecy is possible with ininite sets
of messages as well, as demonstreated in Shannon's original paper.
: Nothing is leaked that was not already plain. No compromise has occured by
: the application of the OTP. It is perfect without the constraint you
: are proposing.
That doesn't seem to make any sense. The length of the message is leaked
to the attacker. What are you talking about?
: This is one clear piece stable ground in a murky field. One thing you can
: know. I don&#
Cryptography-Digest Digest #553
Cryptography-Digest Digest #553, Volume #13 Fri, 26 Jan 01 03:13:00 EST
Contents:
Re: Durstenfeld Transpositions & ARC4 ("r.e.s.")
Re: What do you do with broken crypto hardware? (Nicol So)
Re: Durstenfeld Transpositions & ARC4 (David Wagner)
Re: What do you do with broken crypto hardware? (Paul Rubin)
Re: Mr Szopa's encryption (was Why Microsoft's Product Activation (Anthony Stephen
Szopa)
Re: Why Microsoft's Product Activation Stinks (Anthony Stephen Szopa)
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Durstenfeld Transpositions & ARC4
Date: Thu, 25 Jan 2001 23:11:02 -0800
"Terry Ritter" wrote...
| "r.e.s." wrote:
| >In 1964 Durstenfeld published his well-known Shuffle algorithm
| >that generates a random N-permutation by means of successive
| >pairwise transpositions, which seems to be the "dynamic" part
| >of Terry Ritter's "Dynamic Transposition" cipher. Has there
| >been substantive improvement in such algorithms since 1964, or
| >does Durstenfeld's remain about as good as any?
|
| There exist other permutation techniques of similar age. Shuffle
| seems about as good as any, and is widely understood. For the
| state of the art up to 1991, see:
|
|http://www.io.com/~ritter/ARTS/CRNG2ART.HTM#Sect6.7
Thanks, I'll take a look.
| >Also, is ARC4's byte-stream generator adequate as a CSPRNG?
|
| The ARC4 state is awfully small for Dynamic Transposition,
| especially
| if we shuffle twice. We want more active state in the RNG than is
| used in a single encryption, and probably do want at least 128 bits
| in
| the block. Since rejection in Shuffle (to achieve variable-range)
| throws away values (and may throw away a lot), probably it is not
| large enough.
I wasn't proposing to use Dynamic Transposition, but what you
say is interesting -- especially since the Ciphersaber FAQ says...
"RC4 is a powerful pseudo-random number generator, with a much
bigger internal state, then [sic] the ones that come with most
programming systems."
| >If
| >so, is there a straightforward way to adapt such a byte-stream
| >to generate PRNs uniformly distributed on 1..n?
|
| The conventional technique is "rejection." I have described this
| many times. See, for example:
|
|http://www.io.com/~ritter/KEYSHUF.HTM
|
| in "The Shuffling Subsystem" section.
Ah, well... I had hoped there might be something more efficient
than rejection methods -- they can be so inefficient that I had
ruled them out without saying so.
| >If the answers to these last questions are in the affirmative,
| >then I wonder whether it might be reasonable to have a 2-stage
| >cipher that first uses ARC4 as usual (e.g. as in Ciphersaber),
| >followed by Durstenfeld Transpositions (Shuffles or equivalent)
| >whose rand(1..n) procedure also uses ARC4's stream. (?)
|
| Durstenfeld did not invent bit-permutation ciphers, nor did he
| invent
| the idea of bit-balancing the data for a bit-permutation cipher.
| That type of cipher is called Dynamic Transposition.
The Shuffle algorithm is for generating random permutations
of *anything*, right? So surely you don't consider that
simply using it for bit-permutations is proprietary? (One
could also use Shuffle for byte-permutations, but I believe
both to be non-proprietary uses. NB: I'm specifically *not*
referring to other cipher components such as bit-balancing.)
--r.e.s.
--
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: What do you do with broken crypto hardware?
Date: Fri, 26 Jan 2001 02:40:10 -0500
Reply-To: see.signature
Nicol So wrote:
>
> Paul Rubin wrote:
> >
> > Nicol So <[EMAIL PROTECTED]> writes:
> > > What you want to do with a failed security module is to retire it--stop
> > > encrypting information for it and obsolete any information stored on it.
> > > What you don't want to do is to store global/shared secrets directly in
> > > the non-volatile memory on a security module. Any such secrets should be
> > > stored off the module in encrypted form and loaded in volatile memory
> > > when they are needed. This way, the security module by itself is not
> > > enough to perform any sensitive operation, and can be sent to the
> > > manufacturer for replacement.
> >
> > This doesn't make sense--the whole point of the tamper resistant
> > module is to securely store keys internally. Any keys stored outside
> > the module are vulnerable to copying and therefore must be encrypted;
> > but then in order to load them into the module, the decryption key
> > must be stored inside the module. So if the
Cryptography-Digest Digest #553
Cryptography-Digest Digest #553, Volume #12 Mon, 28 Aug 00 04:13:01 EDT
Contents:
A more secure alternative to ADK for legitimate key recovery (David Hopwood)
Re: DeCSS ruling -- More (David Hopwood)
Re: An interesting cryptographic problem (David Hopwood)
Re: SSL protocol and unencrypted random info (David Hopwood)
Re: DeCSS ruling -- More ("Stou Sandalski")
Looking for Book Recommendations ([EMAIL PROTECTED])
Re: Pencil and paper cipher (Scott Contini)
Re: Steganography vs. Security through Obscurity (Runu Knips)
Re: UNIX Passwords (Runu Knips)
Re: My encryption algorithm (Runu Knips)
Re: SHA-1 program, wrongo ! (S. T. L.)
Re: Patent, Patent is a nightmare, all software patent shuld not be allowed (Paul
Rubin)
Re: Serious PGP v5 & v6 bug! ([EMAIL PROTECTED])
Fly ball in left field... (Greggy)
Date: Mon, 28 Aug 2000 07:15:55 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: A more secure alternative to ADK for legitimate key recovery
=BEGIN PGP SIGNED MESSAGE=
"Ron B." wrote:
> On Thu, 24 Aug 2000 13:33:30 GMT, "JL" <[EMAIL PROTECTED]> wrote:
> >"Ron B." <[EMAIL PROTECTED]> a =E9crit dans le message news:
> >[EMAIL PROTECTED]
> >
> >> If a business requires this then Jane may have no choice in her
> >> business communications.
> >
> >Then her company shouldn't complain if sensible information is
> >compromised. If you don't trust your employees you shouldn't hire
> >them in the first place.
> =
> This may not be a matter of personal trust. The company may see Jane
> as the perfect employee. If Jane is has a heart attack, has a fatal
> accident or for other reasons beyond her control is not available to
> decrypt important data, the company may have legitmate reasons to
> have access to her messages.
Which is why received messages should be reencrypted *by the recipient*
to the recipient organisation's public key designated for that purpose,
and the ciphertext stored locally. Similarly, sent messages should
be additionally encrypted by the sender to the sender organisation's
public key. In neither case does anything that allows the message to be
recovered go over a public network, in contrast to the ADK design.
Now if Jane has a heart attack, her logs of sent and received messages
can be decrypted (the ciphertext will have been backed up by the
organisation's normal backup procedures). New messages cannot be
decrypted, so they must be bounced, but that is exactly as it should
be: the sender then has the opportunity to decide whether he wants to
resend the message to Jane's coworkers, rather than to Jane specifically.=
- -- =
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 0=
1
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has b=
een
seized under the Regulation of Investigatory Powers Act; see www.fipr.org=
/rip
=BEGIN PGP SIGNATURE=
Version: 2.6.3i
Charset: noconv
iQEVAwUBOaoAezkCAxeYt5gVAQEsRggAx/FF01RBowS/GIjoW+N0MIrqKSfKKAV1
3zFMuIA53LqjlCk6oOmRh57MU+J4BadITw9HAeY+M96wBkq0i8SzdzaBVT9vYxkj
fviPe6s+zV+PqrY6B18PpMDk5XZW6YzXPFi2iVwowGub5DbtLOkQDndF7hTpHbyb
F5LtL0jyFMlEWoLaXBtPfePo3mKu/nH03qQ3sB+UdVAphHVDePHSq4JAlAxussR2
KXL5yK7NfeImi8YgeCD4vFuSQ7fKyx++BtkE+dqvR/N0/jeo3UJ8FIEIn9mpdQ59
9+nekApKSpE0G36NbsAyJ+2RbKiWWR6CkTGgNi8IgmtFuwO1vj+DQw=3D=3D
=3DWCfx
=END PGP SIGNATURE=
--
Date: Mon, 28 Aug 2000 07:16:43 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: DeCSS ruling -- More
=BEGIN PGP SIGNED MESSAGE=
Stou Sandalski wrote:
>
> I don't quite agree here, although I see your point. I don't know what they
> did with PGP... but NAI's PGP has a plug in for MS outlook which is very
> easy to use...
PGP won't be commonly used unless or until it is bundled with the most
common email clients, and set up to generate key pairs by default; plug-ins
that have to be separately downloaded won't make any substantial difference.
(Unfortunately the common email clients are hopelessly insecure in other
ways, but that's a separate issue.) At least the export restriction obstacle
to bundling PGP with mail clients has mostly gone away now.
> Their argument is that it will allow "pirates" to copy DVDs
That's their public argument. They don't actually believe it; they know as
well as anyone here that commercial pirates don't
Cryptography-Digest Digest #553
Cryptography-Digest Digest #553, Volume #11 Sat, 15 Apr 00 15:13:01 EDT Contents: Re: ? Backdoor in Microsoft web server ? (Jim Gillogly) Re: PGP for Linux as secure as Windows? ([EMAIL PROTECTED]) Re: CLOSE Encryption (Tom St Denis) Re: The use of Three DES (zapzing) Re: General principles of design (zapzing) Classical Crypto Books (CryptoBook) Why is this algorithm insecure? (Newbie flamefodder) (Richard Heathfield) Re: new Echelon article (JimD) From: Jim Gillogly <[EMAIL PROTECTED]> Subject: Re: ? Backdoor in Microsoft web server ? Date: Sat, 15 Apr 2000 17:26:24 + David A Molnar wrote: > > Mok-Kong Shen <[EMAIL PROTECTED]> wrote: > > in the original UNIX code (cf. ACM award lecture) without being > > detected, it shouldn't surprise that software not written by > > oneself may have backdoors. > > He never actually admitted to placing the backdoor in login...he simply > described in great detail how one would go about doing it. You're both mistaken. Thompson's paper described placing the back door to login in a separate version of the Unix C compiler, not in the original code nor in any shipping version of it. Thompson confirmed later that he did indeed perform this experiment, and it spread to another in-house lab before he blew the gaffe -- it was not merely theoretical. His exposition has been posted here before. -- Jim Gillogly Trewesday, 25 Astron S.R. 2000, 17:14 12.19.7.2.5, 10 Chicchan 8 Pop, Ninth Lord of Night -- From: [EMAIL PROTECTED] Subject: Re: PGP for Linux as secure as Windows? Crossposted-To: alt.security.pgp,comp.security.pgp.discuss Date: Sat, 15 Apr 2000 17:38:54 GMT In sci.crypt none <[EMAIL PROTECTED]> wrote: > Do the memory protection features work under linux? > Clearly, the secure viewer does not have the fonts needed to attempt to > emulate the Windows Secure viewer option, but is there any protection > against the data going into a Swap file? GNUPG will lock pages in memory if it's installed suid, so that's an option for you if PGP doesn't. -- Matt Gauthier <[EMAIL PROTECTED]> -- From: Tom St Denis <[EMAIL PROTECTED]> Subject: Re: CLOSE Encryption Date: Sat, 15 Apr 2000 17:44:36 GMT [EMAIL PROTECTED] wrote: > > In article , > "MeneLaus" <[EMAIL PROTECTED]> wrote: > > CLOSE is a new algorithm written by Chaos Legion, > > Thanks, i'll return the favour some day if you ever need something > testing. > > > > MeneLaus > > Sir, > > The CLOSE algorithm is not secure. Essentially, the alogorithm XOR each > byte of the plain text with multiple key bytes. No non-linear steps are > involved and no diffision among bytes is accomplished. It appears that > one know plain text will reveal a decryption key, by plain XOR cipher = > encryption key. > > A few suggestions, first if you want real security use a well known > algorithm. If you are just having fun then ... > > Add a non linear step like an s-box substistution or a modular mult, see > the IDEA cipher for mod mult. > > Instead of rotating by eight bits each round rotate by 11. After > several (6?) rounds, each bit will influence each output byte. Or rotate by any odd constant. > Add a post whitening step similiar to your pre whitening. > > By steps as in your diagram > > 1 Split the 64 bit into 8 seperate blocks > > 2 XOR a key byte with each block > > 3 Substitute each block with the Rijndael s-box byte Or any non-linear/high avalanche sbox, such as the one from SAFER, which is essentially 45^x mod 257... > 4 Rotate the 8 blocks by 11 (13,17,etc) bits in a circular left manor You cannot rotate a octet 'byte' by 11 bits, that's the same as rotating it by 3 bits. I think you meant to say rotate the entire block by 11 bits. Or better yet rotate by 2r + 1, where 'r' = round number, so each round is slightly diff. > 5 XOR a key byte with each block > > 6 loop to step 3 This is very similar to Safer, but I doubt it shares the avalanche properties. As a result you will need many more rounds. > This reminds me of the GOST algorithm. GOST has 32 rounds. GOST uses > 4-bit s-boxes that are secret. GOST does not seperate into 8 bytes, it does it into 2 32-bit words like DES. And the sboxes need not be secret, as long as they are strong [non-linear permutation of the input]. Of course GOST can be sped up to if you turn the fixed sbox into a 4kb lut. Tom -- From: zapzing <[EMAIL PROTECTED]> Subject: Re: The use of Three DES Date: Sat, 15 Apr 2000 17:38:45 GMT It sounds very similar to the VHS/Bet
Cryptography-Digest Digest #553
Cryptography-Digest Digest #553, Volume #10 Fri, 12 Nov 99 15:13:02 EST Contents: Re: Proposal: Inexpensive Method of "True Random Data" Generation (Coen Visser) slides from ECC '99 talks (Alfred John Menezes) From: Coen Visser <[EMAIL PROTECTED]> Crossposted-To: sci.math,sci.misc,sci.physics Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation Date: Fri, 12 Nov 1999 17:42:21 + "james d. hunter" wrote: > The general guiding principles concerning "sounds" and "looks" > when connected with "random" are that Quantum Mechanics looks > and -is- a randomly generated theory of the universe. That may be the case in physics. This is not the case in algorithmic information/complexity theory. I don't know enough about physics to argue/agree with you on that field. What I do know is that "random" is not a registered trademark of physicists. > > A random string has maximum information content: its information > > can not be described by a smaller string. You can find "randomness" in > > the fact that you need the complete string to get its information. [...] > If you insist on confusing yourself by using "random" for static and > dynamic properties, be my guest, it's not I like really care. What I object to is the fact that someone makes the assumption that it is useless to attribute randomness to strings. There is interesting field in theoretical computer science that is build on that definition. Your use of randomness may be as useful/equivalent as the definition I use, am not denying that. And if you don't care, you won't read and reply on this message. Regards, Coen Visser -- From: [EMAIL PROTECTED] (Alfred John Menezes) Subject: slides from ECC '99 talks Date: 12 Nov 1999 17:22:00 GMT The 3rd annual workshop on elliptic curve cryptography, ECC '99, took place from Nov 1-3 at the University of Waterloo. For those of you who may be interested, the slides from the 15 lectures are available for download from our web site (www.cacr.math.uwaterloo.ca under "Conferences"). - Alfred == | Alfred Menezes| Email: [EMAIL PROTECTED] | | Department of C&O | Phone: (519) 888-4567 x6934| | University of Waterloo| Web page: www.cacr.math.uwaterloo.ca/~ajmeneze | | Waterloo, Ontario | Web page for Handbook of Applied Cryptography: | | Canada N2L 3G1| www.cacr.math.uwaterloo.ca/hac/| | Centre for Applied Cryptographic Research: www.cacr.math.uwaterloo.ca | == -- ** 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 **
Cryptography-Digest Digest #553
Cryptography-Digest Digest #553, Volume #9 Sun, 16 May 99 02:13:06 EDT
Contents:
Re: help me crack strong RSA-DNS unicode encryption (Jim Gillogly)
Dont Read This ([EMAIL PROTECTED])
Re: [Q] Are all encryption algorithms based on primes? ("Douglas A. Gwyn")
Re: True Randomness & The Law Of Large Numbers ("Douglas A. Gwyn")
Re: On Contextual Strength ("Douglas A. Gwyn")
Hmm, I wonder if I got this right ([EMAIL PROTECTED])
Re: True Randomness & The Law Of Large Numbers (R. Knauer)
Re: Europe and USA encryption export restrictions ("Douglas A. Gwyn")
Re: Musing on and Factoring of a (special) 782-bit Modulus ("Douglas A. Gwyn")
Re: [Q] Are all encryption algorithms based on primes? ([EMAIL PROTECTED])
Re: Strength of PGP 1.0 conventional block cipher? (Nathan Kennedy)
Security ([EMAIL PROTECTED])
Re: Lemming and Lemur (David Wagner)
Re: Europe and USA encryption export restrictions (Sundial Services)
Re: AES what's up? (Fredrik Olofsson)
--- sci.crypt charter: read before you post (weekly notice) (D. J. Bernstein)
Re: Lemming and Lemur ([EMAIL PROTECTED])
Re: On Contextual Strength (wtshaw)
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: help me crack strong RSA-DNS unicode encryption
Date: Sat, 15 May 1999 13:24:57 -0700
Interesting. Is this some new candidate for an international
language? If so, it would probably be happier in
alt.language.artificial.
Nenad Aliix wrote:
>
> di wöüt braúc,t unikout
The world braucht (needs) unicode.
> in zajdn wou sijm bit aszij di no@m is obwuj $u
seven? bit ASCII?
> saijt aana ewic,kait latin aans , zwa , drai , .
was? Ewigkeit Latin-1, -2, -3, ...
> unt big fajf , d$isi unt so wajda gejm dujt unt
and Big Five , und so weiter (and so forth)
> as inglesi$e di ima me@ zu@ u@zic, wi@klic,n
English wirklich (actually)
> wöüt$brouc, auf$taijgt waj de kfrijsa hajt zu
weltbraucht, aufsteigt...
and so on. Maybe a dialect of German?
> anke mi lasas saluti na xiuj samlingvanoj ,
Woops, that looks like a dialect of Esperanto -- "alsoly
(anke isn't quite a word) I stop (?) to salute (na?) all
who speak the same language (usually meaning Eo)".
Assuming it's a new artificial language, my preference is
always to pick an orthography that maps well to 7-bit
ASCII -- but I suppose that's just Anglocentrism speaking.
--
Jim Gillogly
Hevensday, 24 Thrimidge S.R. 1999, 20:07
12.19.6.3.9, 12 Muluc 17 Uo, Sixth Lord of Night
--
From: [EMAIL PROTECTED]
Subject: Dont Read This
Date: Mon, 03 May 1999 12:56:41 GMT
l
= Posted via Deja News, The Discussion Network
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: [Q] Are all encryption algorithms based on primes?
Date: Sat, 15 May 1999 22:41:42 GMT
Jessie wrote:
> Are all encryption algorithms based on the fact that it is
> difficult to factor a number which is the product of two LARGE
> primes?
No.
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Sat, 15 May 1999 23:04:04 GMT
"R. Knauer" wrote:
> On Wed, 12 May 1999 17:20:40 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
> wrote:
> >If you dispute that the test accomplishes the above, you should
> >explain where it fails.
> It fails when the TRNG outputs an "abnormal" sequence, which is itself
> perfectly normal.
No, the test works fine, because that "abnormal" circumstance occurs
no more than once per 20,000,000,000 key bits, on average, for a
properly functioning TRNG, just as specified.
If that is your best shot, then you should give up the argument.
> You would condemn a piece of metal because the atoms that comprise it
> do not stay close to their origin when they diffuse.
If I'm trying to measure a diffusion coefficient (which I have
actually done) and leave the experiment unattended overnight, when
I return the next day to find that instead of a nice exponential
penetration, somehow the entire slug of diffusant has formed into a
Dilbert figurine, I would condemn the theory that the statistics of
diffusion properly account for the phenomenon, no matter how much
you assure me that "it could be an anomaly". It is vastly more
likely that some causal factor other than diffusion was involved.
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: On Contextual Strength
Date: Sat, 15 May 1999 23:18:56 G
