Cryptography-Digest Digest #883
Cryptography-Digest Digest #883, Volume #13 Tue, 13 Mar 01 12:13:01 EST
Contents:
Re: One-time Pad really unbreakable? (Tim Tyler)
Re: NTRU - any opinions ("Dr. Yongge Wang")
Re: One-time Pad really unbreakable? (Tim Tyler)
Re: Noninvertible encryption (SCOTT19U.ZIP_GUY)
Re: Text of Applied Cryptography .. do not feed the trolls (Thomas Boschloo)
Re: [REQ] SHA-1 MD5 hashing software (Thomas Boschloo)
Re: Popularity of AES (Thomas Boschloo)
Re: GPS and cryptography (br)
Crypto idea (br)
Re: Text of Applied Cryptography .. do not feed the trolls (Thomas Boschloo)
Re: GPS and cryptography ("Tom St Denis")
Re: [REQ] SHA-1 MD5 hashing software (Thomas Boschloo)
Re: Popularity of AES (Thomas Boschloo)
Re: Noninvertible encryption (SCOTT19U.ZIP_GUY)
Re: GPS and cryptography (Steve Portly)
Re: Text of Applied Cryptography .. do not feed the trolls ("Tom St Denis")
Re: Anonymous web surfing? ("Mario Contestabile")
Re: Is this book interesting (Ben Cantrick)
Re: Is this book interesting (Jim Haynes)
Re: Anonymous web surfing? (Curtis R Williams)
Re: Is this book interesting (Richard Herring)
Re: Potential of machine translation techniques? ("Henrick Hellström")
From: Tim Tyler [EMAIL PROTECTED]
Subject: Re: One-time Pad really unbreakable?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 13 Mar 2001 14:58:20 GMT
Ben Cantrick [EMAIL PROTECTED] wrote:
: Point is, given the preconditions, an OTP is provably unbreakable.
: Are those conditions very hard, perhaps impossible to meet? Possibly.
: But if you have that random stream, you have unbreakable encryption -
: and provably so.
If you have that random stream, you have perfect secrecy.
The problem with the OTP proof is that it assumes something which can
never - in practice - be demonstrated to hold true. This is
not a flaw - since most proofs do this somewhere - but those applying
the proof need to keep it in mind.
The proof is valuable and useful, with practical implcations for real
systems - but it's silly to base claims of "perfect security" and
"unbreakability" of real world systems on it.
--
__ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
--
From: "Dr. Yongge Wang" [EMAIL PROTECTED]
Subject: Re: NTRU - any opinions
Date: 13 Mar 2001 15:20:05 GMT
Dan Bailey [EMAIL PROTECTED] wrote:
: Anyone (even those who work for Certicom!) who would like a document on
: the extensive scrutiny NTRU has received in the literature can feel free
: to email me. I'll be happy to oblige.
: Here's the executive summary: "Better attacks or better lattice reduction
: algorithms are required in order to break NTRU" (Nguyen and Stern, in
: ANTS-2000).
Unfortunately, I cannot agree with that. NTRU signature scheme
presented in Crypto'00 was broken without any use of lattice technique.
NTRU is not a lattice scheme. there might algebraic method to break it.
: Cheers
: Dan
: PS Yes, I work for NTRU.
: On 9 Mar 2001, DJohn37050 wrote:
: So, ECC has a space advantage and perhaps NTRU has a speed advantage on a
: Pentium, if you believe NTRU is strong. I notice that the NTRU sig method
: presented at Crypto is no where to be found (anymore) on the NTRU webstie,
: instead a new one from fall 2000 is being offered. What happened to the old
: one, did someone break it? Do you think this inspires confidence?
: Don Johnson
:
:
--
From: Tim Tyler [EMAIL PROTECTED]
Subject: Re: One-time Pad really unbreakable?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 13 Mar 2001 15:03:46 GMT
Frank Gerlach [EMAIL PROTECTED] wrote:
: Tim Tyler wrote:
: Nope. The proof of perfect secrecy rests on the availability of a shared
: unguessable stream. No such thing has ever been demonstrated to exist.
:
: Consequently the proof of secrecy of the OTP cannot be transferred onto
: real-world systems used for actual communication without qualifications
: being made.
: Then you also cannot trust any other crypto system, as you cannot be
: sure your key has been created in a (deterministically or not)random
: process.
Yes, exactly.
: The question of determinism and proper key generation applies to OTP as
: much as to any other crypto system. It is absolutely pointless to blame
: bad physical random key generators on OTP [...]
Indeed. Has anyone been doing that?
: Paperpencil based OTP will be most probably the only method, which one
: can trust in a time of extremely powerful antennas and signal
: processing. Maybe some organizations don't like that and to spread
: rumors...
Personally I think a paper-and-pencil OTP is rather likely to be insecure,
due to key-distribution problems. There's a good reason why OTPs are
little used.
--
Cryptography-Digest Digest #883
Cryptography-Digest Digest #883, Volume #12 Mon, 9 Oct 00 22:13:00 EDT Contents: Re: A new paper claiming P=NP (glenn) Re: Quantized ElGamal (Tom St Denis) Re: What is "freeware"? (was: Re: Any products using Rijndael?) (John Savard) Re: Microsoft CAPI's PRNG seeding mechanism (dbt) Re: RC5 Test Vectors (David Hopwood) Re: SDMI challenge (dbt) Re: xor algorithm (Tom St Denis) Re: SDMI - Answers to Major Questions (Tom St Denis) Re: Any products using Rijndael? (Tom St Denis) Re: Why wasn't MARS chosen as AES? (Greggy) Re: NSA quote on AES (Greggy) Re: NSA quote on AES (Greggy) Re: NSA quote on AES (Greggy) From: glenn [EMAIL PROTECTED] Crossposted-To: comp.theory,sci.math,sci.op-research Subject: Re: A new paper claiming P=NP Date: Tue, 10 Oct 2000 04:03:23 +0300 On Tue, 10 Oct 2000 13:23:26 +1300, Ross Smith [EMAIL PROTECTED] wrote: Ah, but that "...or worse" gives them an out. If reviewing a proof is P-time, but *finding* the proof is *worse* than NP-time, then reviewing can still be easier than finding without contradicting P=NP. I'm not aware of the technicalities of the N=NP problem, but I know that it is a major problem. Can someone say for sure if the presented proof is right? -- glenn -- From: Tom St Denis [EMAIL PROTECTED] Subject: Re: Quantized ElGamal Date: Tue, 10 Oct 2000 01:13:28 GMT In article [EMAIL PROTECTED], "William A. McKee" [EMAIL PROTECTED] wrote: What is Quantized ElGamal? What is a timing-attack? Is ElGamal secure or has it been broken? Quantification means to reduce with loss of information. PCM audio is quantised for example, so are DCT coefficients of MP3 and JPEG images. Quantized ElGamal does not make sense. A timing attack is based on the *implementation* of an algorithm. For example in ElGamal I must raise something with my private exponent. I could time how long it takes to guess at the bits of my exponent (see the multiply-square method). ElGamal is vaguely as difficult as the discrete logarithm problem. So when implemenented and used properly it's secure. For example a proper implementation of ElGamal with a 200 bit prime is not secure no matter how good the hardware, but ElGamal with a 2000 bit prime is not guaranteed to provide security. Tom Sent via Deja.com http://www.deja.com/ Before you buy. -- From: [EMAIL PROTECTED] (John Savard) Subject: Re: What is "freeware"? (was: Re: Any products using Rijndael?) Date: Tue, 10 Oct 2000 01:10:49 GMT On 10 Oct 2000 01:12:49 +0200, [EMAIL PROTECTED] (Paul Schlyter) wrote, in part: I don't understand that "in between freeware and public domain" stuff. Either the program is copyrighted, or it is not copyrighted. It cannot be "in between", can it? Therefore open source is copyrighted freeware. But it is a special category. Ordinary freeware is free, but otherwise subject to the usual conditions associated with commercial packages: you can't distribute a modified version, you don't get the source, and so on. Open source software, on the other hand, lets you do most of the things you can do with public-domain software - except hide it in something that you can pass off as all your own work, which others cannot use as you used the original. So it is a distinct class of program. It is copyrighted, but the copyright is put to a different use. John Savard http://home.ecn.ab.ca/~jsavard/crypto.htm -- From: [EMAIL PROTECTED] (dbt) Crossposted-To: sci.crypt.random-numbers Subject: Re: Microsoft CAPI's PRNG seeding mechanism Date: Tue, 10 Oct 2000 01:19:43 GMT Jack Love [EMAIL PROTECTED] says: MS is well-known for not taking security seriously. Windows 2k was recently given a C2 rating. C2 is extremely meaningless. It's a marketing label required to get your foot in the door for most government contracts. -- David Terrell| "Instead of plodding through the equivalent of Prime Minister, NebCorp | literary Xanax, the pregeeks go for sci-fi and [EMAIL PROTECTED] | fantasy: LSD in book form." - Benjy Feen, http://wwn.nebcorp.com | http://www.monkeybagel.com/ "Origins of Sysadmins" -- Date: Mon, 09 Oct 2000 23:51:46 +0100 From: David Hopwood [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Subject: Re: RC5 Test Vectors =BEGIN PGP SIGNED MESSAGE= Chris Kerslake wrote: I am looking for test vectors for RC5 (and eventually other ciphers). http://www.users.zetnet.co.uk/hopwood/crypto/scan/ For RC5, see RFC 2040 (this only includes test vectors for CBC mode, but it's easy to derive single-block test vectors from them). If you're thinking of using RC5, bear in mind that it is patented. I have downloaded three different crypto-libraries off the Net and ha
Cryptography-Digest Digest #883
Cryptography-Digest Digest #883, Volume #11 Mon, 29 May 00 03:13:01 EDT
Contents:
Re: Another sci.crypt Cipher ([EMAIL PROTECTED])
Re: A Family of Algorithms, Base78Ct (wtshaw)
Re: Anti-Evidence Eliminator messages, have they reached a burn-out po (James K)
Re: Anti-Evidence Eliminator messages, have they reached a burn-out po (James K)
Re: Anti-Evidence Eliminator messages, have they reached a burn-out po (James K)
Re: Is OTP unbreakable?/Station-Station (Joaquim Southby)
Re: No-Key Encryption (Michael Pellaton)
Re: No-Key Encryption (Decklin Foster)
Re: My simple cipher ("Scott Fluhrer")
Re: Crypto patentability (Anders Thulin)
Re: encryption without zeros (zapzing)
From: [EMAIL PROTECTED]
Subject: Re: Another sci.crypt Cipher
Date: Mon, 29 May 2000 04:59:31 GMT
...
I believe the differential for 16 rounds will be 2^-60. A 2R or 3R
attack could probably be mounted requiring 2^48 plain/cipher text.
R p1 p0
0 0 cprob = 1
1 c 02^-6
2 c c2^-6
3 0 c1
4 c 02^-6
5 c c2^-6
6 0 c1
7 c 02^-6
8 c c2^-6
9 0 c1
A c 02^-6
B c c2^-6
C 0 c1
D c 02^-6
E c c2^-6
F 0 c1
c 0cipher text
Tom,
I have extended this attack via related keys. TC1 is vulnerable to
differential related key cryptanalysis. For best results the attack
requires chosen plain text.
The attack requires a related key query. Basically, I want to two keys
that have only a difference in the 0 word with the XOR being 0x00 00 00
0c
The attack requires some text be run under one key, and some text be
run under the related key.
The key schedule is
0,1,2,3, 1,0,3,2, 2,3,1,0, 3,2,0,1
Now since the attack can chose the plain text, the input will always be
equal to 0x00 00 00 0c thus offseting the difference in the first round.
With such a situation, the attack will have equal input to the fifth
round i.e. differential 0x00 00 00 00.
K R p1 p0
c 0plain text
0 0 0 0prob = 1, Since key 0 differential is 0xc
1 1 0 01
2 2 0 01
3 3 0 01
1 4 0 01
0 5 c 02^-6 the 0 key introduces a difference
3 6 c 02^-6 the key difference does not carry forward
2 7 c c2^-6
2 8 0 c1
3 9 c 02^-6
1 A c c2^-6
0 B c c2^-6 the difference is caused by the key difference
3 C 0 01
2 D 0 01
0 E c 02^-6 the zero key cancels the difference
1 F c 01
x cassume the differential held if p0 = c
The full differential has a 2^-42 chance. A 2R attack has a chance of
2^36, now we are getting somewhere! The attack is similar to the
differential related key attack on GOST proposed by Wagner, Scheiner,
et al.
The full attack would need one related key query and around 2^36 texts.
The counting requirements would run up the RAM to 2^32 or so.
I noticed you have modified the cipher from the original so this attack
may no longer be valid. The addition of round counters will be
irrelevant to this attack.
This is a great cipher for study. Not to hard, not to easy, just right.
--Matthew
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: A Family of Algorithms, Base78Ct
Date: Sun, 28 May 2000 23:20:19 -0600
In article [EMAIL PROTECTED], Mok-Kong Shen
[EMAIL PROTECTED] wrote:
While I have from personal experiences certain reservations against
introducing complexity, which can be a considerable source of
troubles/errors for implementations of all kinds of software, crypto
or not, I think you are right in the opinion that computers have
rendered the balance of crypto designers and analysts in favour of
the former. For it is now not very difficult and indeed quite speedy
to incorporate into an encryption scheme a tiny piece of additional
this and that, which could considerably confound the opponent,
who by nature has to play the passive role in the game. The diversity
or variability in crypto design is in my humble view somewhat
analogous to the mutations of bacteria and viruses in the microbiology.
While in the case of e.g. flus the pharmaceutical industry is known to
have some success in developing vaccines anticipating new mutations
in the natural environment, it is not apparent at all, however, that the
analyst could do anything parallel to face the variations of encryption
algorithms. Presumably, though, this view is unlikely to be accepted
by those who advocate the use of one single (almost) perfect
algorithm.
M. K. Shen
I admit it: I am and was never much good with pencil and paper, even
though it once that was the only cipher option. I tend to use computer
helps that I write myself, starting with constructions to understand
algorithm mechanisms.
There is a debate amongst ACA
Cryptography-Digest Digest #883
Cryptography-Digest Digest #883, Volume #10 Tue, 11 Jan 00 09:13:01 EST
Contents:
Re: How about this for a "randomly" generated bitstream? (Guy Macon)
Re: Intel 810 chipset Random Number Generator (Guy Macon)
Re: Simple Encryption ... (Johnny Bravo)
Intel 8282 firmware hub RNG internals (Guy Macon)
Re: Intel 810 chipset Random Number Generator (Bradley Yearwood)
Re: Intel 810 chipset Random Number Generator (Bradley Yearwood)
Re: Little "o" in "Big-O" notation ("Scott Fluhrer")
Re: Square root attacks against DSA? (David Hopwood)
Re: Questions about message digest functions (David Hopwood)
another newbie ("Markus Eiber")
Re: Square root attacks against DSA? (Paulo S. L. M. Barreto)
Re: The Cipher Challenge from the Code Book (Staffan Ulfberg)
Rijndael (was: Square?) (Paulo S. L. M. Barreto)
Re: Simple Encryption ... ("Derek Potter")
Re: AES satellite example ([EMAIL PROTECTED])
Re: another newbie (Jeff Williams)
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: How about this for a "randomly" generated bitstream?
Date: 11 Jan 2000 01:17:19 EST
Your post got mangled somehow. It was one long line that got truncated.
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Trevor Jackson, III) wrote:
No, he's _adding_ 8 bit data to 24 bit data, which will occasionally overflow the low
byte into bit 8. It's a form of probabilistic roundin
I think I get it, though, and you are right. The 16th bit (the new LSB)
will clearly have a probabalistic "error" imposed that is assosiated with
the 8 bits that don't fit.
The existance of a method of preserving something related to the lost
bits during 24 bit to 16 bit conversions does not exclude modifying
the LSB of true 16 bit material with a PRNG
--
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Intel 810 chipset Random Number Generator
Date: 11 Jan 2000 01:23:19 EST
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Trevor Jackson, III) wrote:
Because the example for a multi-threaded app works when applied at the OS level. To
the OS the applications look like threads. The fact th
Your posts bare all exceeding 80 collumns today, and somewhere between
you and me everything after the 160th character disapears. Could you
repost? I am interested in what you have to say.
--
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: Simple Encryption ...
Date: Tue, 11 Jan 2000 01:04:49 GMT
On Tue, 11 Jan 2000 02:03:58 -, "Derek Potter"
[EMAIL PROTECTED] wrote:
"r.e.s." [EMAIL PROTECTED] wrote
Wouldn't it be easier, and just as well, to simply
identify yourself in the plaintext document, then
publish a 1-way hash of the document (say with SHA1),
avoiding the use of keys altogether?
How big would the hash be compared with the
original document?
Not big at all. 20 bytes gives you 2^160 possible hashes,
that should be more than enough.
Best Wishes,
Johnny Bravo
--
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Intel 8282 firmware hub RNG internals
Date: 11 Jan 2000 01:58:15 EST
I found out what goes on under the hood today. Read this:
[ ftp://download.intel.com/design/security/rng/CRIwp.pdf ]
--
Subject: Re: Intel 810 chipset Random Number Generator
From: [EMAIL PROTECTED] (Bradley Yearwood)
Date: Tue, 11 Jan 2000 07:35:02 GMT
In article [EMAIL PROTECTED],
Doug Stell [EMAIL PROTECTED] wrote:
On 7 Jan 2000 14:13:16 -0800, [EMAIL PROTECTED] (Bradley Yearwood)
wrote:
... appears to indicate a worst-case rate of
random byte production of around 222 bytes/sec.
This doesn't sound very useful. A randomizer should be able to quickly
supply a random block the size of a symmetric key, a Diffie-Hellman
private key or a prime 1/2 the size of an RSA modulus.
By contrast, the Motorola Advanced INFOSEC Machine (AIM) supplies of
random data up to 1024 bits in length, organized as a buffer of 32
32-bit words. Blocks may be requested as often as every 146 usec.
Also, this is a true, NSA-certified randomizer, not a PRNG. The AIM is
dedicated to performing crypto, particularily high-grade crypto.
Depends upon the application. Big difference in capabilities required
and cost structure appropriate for generating session keys for a zillion
concurrent clients in hot ecommerce, vs. applying signatures to occasional
pieces of information originating at one client machine.
--
Subject: Re: Intel 810 chipset Random Number Generator
From: [EMAIL PROTECTED] (Bradley Yearwood)
Date: Tue, 11 Jan 2000 07:40:51 GMT
In article [EMAIL PROTECTED],
Scott Nelson [EMAIL PROTECTED] wrote:
On 7 Jan 2000 [EMAIL PROTECTED] (Bradley Yearwood) wrote:
... which appears to indicate a worst-case rate of
random byte pro
