Cryptography-Digest Digest #829, Volume #13 Wed, 7 Mar 01 14:13:01 EST
Contents:
Re: Problem with BBS implementation ("Dobs")
Re: => FBI easily cracks encryption ...? (Richard Herring)
Re: PKI and Non-repudiation practicalities (Anne & Lynn Wheeler)
Re: => FBI easily cracks encryption ...? (Richard Herring)
Re: Buy a PDF edition of Applied Cryptography of Bruce SCHNEIER ("Ryan Phillips")
Re: Encryption software (Joe H. Acker)
Re: HPRNG ("Simon Johnson")
Re: Voting ("Simon Johnson")
Re: How to find a huge prime(1024 bit?) (Gregory G Rose)
Re: The Foolish Dozen or so in This News Group (Darren New)
Re: TV Licensing (Was: => FBI easily cracks encryption ...?) ("Sam Simpson")
Re: Encryption software (Neil Cuuture)
Re: Super-strong crypto......................(As if). ("Simon Johnson")
Re: Encryption software (Ben Cantrick)
crypto short course (Christof Paar)
Re: Cipher idea ("Simon Johnson")
Re: Buy a PDF edition of Applied Cryptography of Bruce SCHNEIER (DJohn37050)
Re: Question re Asymmetric Encr'n (Gregory G Rose)
----------------------------------------------------------------------------
From: "Dobs" <[EMAIL PROTECTED]>
Subject: Re: Problem with BBS implementation
Date: Wed, 7 Mar 2001 18:10:02 +0100
ok thanks for answer, maybe U can also tell me where can I find a source
code of such a large prime numbers generator which can I use in this program
::)))))))))))))
Użytkownik Tom St Denis <[EMAIL PROTECTED]> w wiadomości do grup
dyskusyjnych napisał:e9sp6.38659$[EMAIL PROTECTED]
>
> "Dobs" <[EMAIL PROTECTED]> wrote in message news:985hnk$h0p$[EMAIL PROTECTED]...
> > Hello,
> > I am trying to implement blum blym shub generator , however I came
accross
> a
> > problem. As some of U might know in BBS generator I have to generate two
> > large random prime p and q, each congruated to 3 moulo 4, and compute
> > n=pq.Then select integer s( the seed) in the interval [1,n-1] such that
> > gcd(s,n)=1.
> > And here is the problem.
> > It is difficult to find such an s that it will have gcd witch n equal
to
> 1
> > (gcd(s,n)=1.)
> > Everythink is ok for small primes as p=11 and=7, but if I will take
> p=104683
> > q=103483(large primes as it shoul be), than computer is starting to look
> for
> > it and it could take ages.
>
> The product is 34 bits long which is why it won't work. You must use a
big
> integer package to use large numbers.
>
> BTW what they mean by "large prime" is >= 512 bits in length not 17
bits...
>
> <snip>
>
> Tom
>
>
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: 7 Mar 2001 17:27:58 GMT
Reply-To: [EMAIL PROTECTED]
In article <Wknp6.291$[EMAIL PROTECTED]>, John Niven
([EMAIL PROTECTED]) wrote:
> > > what their citizens are watching on TV or listening to
> > > on radios. (Does England still do that?).
> > Can you post details about this? I've always thought it was an urban
> > myth except under lab conditions.
> Britain's TV Licensing Department used to claim that they had handheld
> detectors capable of not only detecting that you were watching TV, but also
> which channel. I don't know anyone who's been caught by such a device,
> though I do know people who have been caught for other reasons. The current
> advertising drive suggests that all they know, and need to know, is who
> doesn't own a TV license.
See http://www.tvlicensing.co.uk
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
Subject: Re: PKI and Non-repudiation practicalities
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Wed, 07 Mar 2001 17:37:51 GMT
Anne & Lynn Wheeler <[EMAIL PROTECTED]> writes:
> oops, that should be 10,959 person years with the rubber hose method
> compared to possibly a couple person weeks to come up with approx. the
> same potential fraud "yield".
also, possibly unnecessary observation is that paper signatures are
also subject to rubber hose attacks. various legislation that i'm
aware of attempts to put digital signatures on somewhat equal footing
with paper signatures ... not a stronger footing; and procedures for
handling rubber hose extraction of signatures have been around for
possibly hundreds (? depends on how far back you want to take things
defined as signatures) of years
there are possible trade-offs; paper signatures are probably a little
easier to counterfeit than hardware token digital signatures. the
rubber hose bit is probably about the same. in any kind of
token/public key registration environment ... it should be
straight-forward to report lost/stolen/compromised (in the AADS model
it should be the same as existing card lost/stolen).
--
Anne & Lynn Wheeler | [EMAIL PROTECTED] - http://www.garlic.com/~lynn/
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: 7 Mar 2001 17:35:39 GMT
Reply-To: [EMAIL PROTECTED]
In article <97vqou$2q5u4$[EMAIL PROTECTED]>, kroesjnov ([EMAIL PROTECTED]) wrote:
> > <snip>
> > >
> > >I am willing to trade some privacy for safety.
> > <snip>
> >
> > So basically, you are saying that you'll trade your privacy to be a sheep?
> I.e.
> > you'll give up your rights so that the government can play the role of
> > sheepherder?
> I believe the keyword is 'some' as you should understand.
> And no, I am not willing to do everything my government say`s, and no, I
> will not let them in full control off my life.
> I just think that safety from terrorists and foreign army`s weights more
> me, then absolute privacy. This does not mean I do not want any privacy...
Your entire argument is based on a fallacy, a false dichotomy.
The number of possible outcomes is not limited to two.
You are assuming that if *you* give up *your* privacy, so will the
terrorists and foreign armies. Is that a reasonable assumption?
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: "Ryan Phillips" <[EMAIL PROTECTED]>
Subject: Re: Buy a PDF edition of Applied Cryptography of Bruce SCHNEIER
Date: Wed, 7 Mar 2001 09:43:17 -0800
I'm surprised no one has mentioned this link:
http://www.cacr.math.uwaterloo.ca/hac/
The fourth edition of the book is in pdf or postscript format is and is a
free download. It is only for personal use.
Regards,
Ryan Phillips
"Latyr Jean-Luc FAYE" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi
>
> It's the 2nd post of this message as I haven't seen the first one appear
on
> the NG.
>
> I bought one printed copy of the book Applied Cryptography in a Book
shop.
> But I have to share it with four other people. So I think that it can be
> easier for us to have it in PDF and put it in our Intranet.
> Where can I buy the PDF version of the book
> Thanks in advance.
> Latyr
>
>
>
> --
> Latyr Jean-Luc FAYE
> http://faye.cjb.net
>
>
------------------------------
From: [EMAIL PROTECTED] (Joe H. Acker)
Subject: Re: Encryption software
Date: Wed, 7 Mar 2001 18:50:02 +0100
Curtis R. Williams <[EMAIL PROTECTED]> wrote:
> Has anyone in this group (or elsewhere on the net) evaluated commonly
> available encryption software programs. I'm pretty good at spotting
> the obvius phonies, but there are many programs that look reasonable.
Problem is that most people don't have the resources to test such
programs, and the people who have the resources might not be allowed to
admit they have or publish test results.
Second problem: Most encryption programs use special file formats,
headers or internal compression/encoding. Thus, you cannot use official
test vectors to see if the algorithms return the correct result. Ask the
vendor if he has tested his implementations with the official test
vectors. Anyway, you really need to get in touch with the author(s) of
the product, except the unlikely case that you have a lot of time and
the skills to reverse-engineer the product.
Here are some criterias from my own experience as shareware crypto
author (most are in the SnakeOil FAQ as well):
1. Does the app hash passwords? Which secure hashing algorithm is used?
Any programmer should be able to answer this question and name the
algorithm. In fact, this should be in the docs.
2. Does the app use session keys?
If yes, ask the programmer, what he uses the session keys for and how he
creates them. If the app uses session keys but does not collect entropy
from the system (like mouse-movements), it might be vulnerable. Anyway,
ask the programmer what kind of PRNG he is using. His answer should at
least indicate, that he has a reasonable idea of the difference between
a PRNG and a cryptographically strong PRNG.
3. Is the encryption stronger than that of PGP?
If the programmer asserts that his app is stronger than PGP without
giving very detailed reasons (and perhaps source code), his app is
likely to be less strong than PGP. In my opinion, when you ask about
very strong encryption, any responsible crypto author should not only
answer with considerations about the strength of the algorithms used,
but also point out that there are many many possible side-channel
attacks you have to watch for.
4. If the app can produce binary files without special encoding, or you
can seperate the plain binary ciphertext (no special encoding) from such
files, try compressing that data. The compression rate should be very
low. (anyone please correct me if that's wrong)
5. How does the app know which key was the right one?
If the programmer asnwers that the key in any way is stored somewhere,
but assures you that there's no way to retrieve it (because it's
encrypted or such), throw away his program. If he exaplains another
procedure but doesn't mention hashing, the app is more likely to be
vulnerable than if hashing is involved. (this is just a rule of thumb,
of course)
Well, that's just my opinion and you probably knew these points. I don't
think there's much more you can do than asking a programmer and judge
his answers.
Greetings,
Erich
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: HPRNG
Date: Wed, 7 Mar 2001 17:59:36 -0800
Darren New <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Simon Johnson wrote:
> > I'm not saying physics isn't a religion (in many senses it is),
>
> Err, no, it's not. Science tells you how the universe works. Technology
> tells you how to use science to get what you want. Religion tells you what
> you want. Faith enters into science only to the extent that you assume the
> universe isn't trying to fool you and that the laws of physics aren't
> changing. Faith enters into religion only to the extent that religious
> leaders want you to want the same things they want.
I agree with most of this.... Science requires faith, but in your light, its
not a Religion.... when I said science was a religon, I meant that religons
were replaced by science as a tool to describe the nature of our and the
universes existance....
Simon....
> --
> Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
> San Diego, CA, USA (PST). Cryptokeys on demand.
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: Voting
Date: Wed, 7 Mar 2001 18:02:25 -0800
Paul Rubin <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Benjamin Goldberg <[EMAIL PROTECTED]> writes:
> > The voting machines in NY, while a bit old, fit this requirement quite
> > well. However, I will admit that there are some ways improvements could
> > be made. The NY machines have (IIRC) a mechanical counter, which has an
> > odometer-like display.
>
> I bet by mounting a small hidden microphone on or near one of those
> machines, you could tell who was being voted for, because the internal
> levers make different sounds. So much for the secret ballot.
Not if the machine is contained in a vacuum, but this is getting a bit
ridiculous.
Simon.
------------------------------
From: [EMAIL PROTECTED] (Gregory G Rose)
Crossposted-To: alt.security.pgp,sci.math
Subject: Re: How to find a huge prime(1024 bit?)
Date: 7 Mar 2001 09:59:38 -0800
In article <[EMAIL PROTECTED]>, Dik T. Winter <[EMAIL PROTECTED]> wrote:
>Well, I say it is correct. The premissa is: "there is a finite number
>of primes". Multiplying them all together and adding 1 shows that the
>resultant number is not divisible by any prime. Hence by the definition
>of prime it must be prime, contradicting the premissa.
I'm sure someone else has already pointed this
out, but my news feed is flaky at the moment, so
I'll chime in anyway.
The number you get by multiplying all the primes
together and adding one might not be prime itself;
however, it must have prime factors which are not
in the list. For example:
2*3*5*7*11*13 = 30030
30031 = 59*509
So, you've constructed a number which is not
prime, but still proves that there are an infinite
number of them, since it has (not one but two or
more!) prime factors which weren't on the list.
In fact, as your theoretical finite set of primes
gets larger, the probability that the constructed
number is prime approaches zero.
regards,
Greg.
--
Greg Rose INTERNET: [EMAIL PROTECTED]
Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199
Level 3, 230 Victoria Road, http://people.qualcomm.com/ggr/
Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Wed, 07 Mar 2001 18:00:45 GMT
Eric Lee Green wrote:
> filesystem, and probably NTFS (since NTFS also claims to be a transactional
> filesystem), will *NOT* reuse the same blocks for the file.
>From what I've read (www.sysinternals.com I think), the NTFS 4 file system
doesn't do transactional data, but only transactional metadata. Of course,
if compression is turned on, you aren't using the same blocks either. Also,
NTFS 5 (with Win2K) might have transactional data as well now.
> call on Unix called 'fsync', which supposedly guarantees that all
> blocks currently in the buffer cache will be flushed out to disk
> before 'fsync()' returns.
Actually, the fsync()/sync() call doesn't guarantee the blocks will be
written. It guarantees that the blocks will be scheduled to be written. But
it doesn't always wait for the hardware to complete. This is probably
enough, if the hardware buffers don't interfere.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: TV Licensing (Was: => FBI easily cracks encryption ...?)
Date: Wed, 7 Mar 2001 17:58:26 -0000
John Niven <[EMAIL PROTECTED]> wrote in message
news:WOtp6.930$[EMAIL PROTECTED]...
> > (You have to own a license to watch TV in Britain? Fortunately I have a
> > simple solution for that, having not watched TV at all for years... by
> > choice.)
>
> Not quite right - you have to own a license to own a TV. Subtle, but it
> meant that the small colour set I had solely to use with my
"micro-computer"
> during the 80's required a license.
>
> If you have no aerial (eg. you used
> your TV just for watching pre-recorded videos or DVDs) you're still
required
> to buy a license.
That's not true at all. The TV Licensing Authority hardly trumpets the
fact, but "using television receiving equipment to receive or record
television programme services you are required by law to have a valid TV
licence." Owning a TV to watch DVD's, videos or use connected to a computer
DOES NOT require a license.
As a student I used to sell electrical goods (including TVs!) and we were
given these instructions by the TV Licensing.
Don't believe me, call them on: 08457 77 55 44 - I just did (to confirm that
the rules haven't changed!).
Regards,
Sam
http://www.scramdisk.clara.net/
------------------------------
From: Neil Cuuture <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Encryption software
Date: Wed, 07 Mar 2001 18:03:31 GMT
Good serious Security software tends to be Open Source.
Another good way to verify by yourself is to look what API
the program is made of. For example i do use ( in Java ) the Cryptix lib
( www.cryptix.org ) and BouncyCastle API ( www.bouncyCastle.org ). In
c/c++ i will use Wei Dai Crypto++ Lib
and OpenSSL lib. All theses API and lib have test vectors and test
programs that come with them.
So look for what API these app are made this could be a good clue.
Note that there is also commercial API for cryptographic primitives.
( i do not remember their name... ):-) )
Neil,
"Curtis R. Williams" wrote:
> Has anyone in this group (or elsewhere on the net) evaluated commonly
> available encryption software programs. I'm pretty good at spotting
> the obvius phonies, but there are many programs that look reasonable.
> Does anyone actually try and verify that algorithms are properly
> implemented?
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: Super-strong crypto......................(As if).
Date: Wed, 7 Mar 2001 18:12:02 -0800
Keill_Randor <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> The only way to have a secure encryption system, (and uncrackable), is to
make sure that the only way to crack an encrypted peice of data - (or any
other peice of information - (I just concentrate on computing)), is to run
through every peice of data known to a computer - (Even the NSA won't be
able to deal with that).
>
> I.e. the only secure system, is one that allows you to encrypt any peice
of data (or stream), using any other peice / peices or stream / streams of
data.
>
> (Like what mine does, but I don't think it's a good idea to post it,
somehow..:). (I'm trying to deal with GCHQ, but they don't seem to want to
know...(Idiots))). The word random shouldn't really be needed...
>
> Keill Randor
> [EMAIL PROTECTED]
>
well clearly it depends on how the streams are combined as to how secure
your system is, but since your unwilling to disclose the details of the
algorithm.... its unlikely you'll be taken seriously.
Simon.
------------------------------
From: [EMAIL PROTECTED] (Ben Cantrick)
Subject: Re: Encryption software
Date: 7 Mar 2001 11:14:24 -0700
In article <[EMAIL PROTECTED]>,
Joe H. Acker <[EMAIL PROTECTED]> wrote:
>Problem is that most people don't have the resources to test such
>programs, and the people who have the resources might not be allowed to
>admit they have or publish test results.
>
>Second problem: Most encryption programs use special file formats,
>headers or internal compression/encoding. Thus, you cannot use official
>test vectors to see if the algorithms return the correct result. Ask the
>vendor if he has tested his implementations with the official test
>vectors. Anyway, you really need to get in touch with the author(s) of
>the product, except the unlikely case that you have a lot of time and
>the skills to reverse-engineer the product.
Very well said.
>3. Is the encryption stronger than that of PGP?
>
>If the programmer asserts that his app is stronger than PGP without
>giving very detailed reasons (and perhaps source code), his app is
>likely to be less strong than PGP. In my opinion, when you ask about
>very strong encryption, any responsible crypto author should not only
>answer with considerations about the strength of the algorithms used,
>but also point out that there are many many possible side-channel
>attacks you have to watch for.
This is a biggie. A lot of people, time and work have gone into
making PGP what it is now. Anyone who claims they're better than PGP
all around is naive/stupid, lying, or a flippin' genius. You can
probably guess the radio of stupids and shysters to geniuses...
>4. If the app can produce binary files without special encoding, or you
>can seperate the plain binary ciphertext (no special encoding) from such
>files, try compressing that data. The compression rate should be very
>low. (anyone please correct me if that's wrong)
Not necessarily "very low", but it should be significantly lower than
the plaintext. The key and algorithm should add a good bit of randomness
into the data, which should make compression less efficient.
>5. How does the app know which key was the right one?
>
>If the programmer asnwers that the key in any way is stored somewhere,
>but assures you that there's no way to retrieve it (because it's
>encrypted or such), throw away his program. [...]
Guess we better throw away PGP then. ;] The versions I'm familiar with
keeps your private key on disk, encrypted with IDEA(?). The passphrase you
enter acts as a key for the IDEA encryption.
But yeah, in general this is a bad idea. Cryptographic hashes are
probably a better idea, provided they're using a good one.
-Ben
--
Ben Cantrick ([EMAIL PROTECTED]) | Yes, the AnimEigo BGC dubs still suck.
BGC Nukem: http://www.dim.com/~mackys/bgcnukem.html
The Spamdogs: http://www.dim.com/~mackys/spamdogs
"I went looking for trouble... and boy... I found her." -Type O Negative
------------------------------
From: Christof Paar <[EMAIL PROTECTED]>
Subject: crypto short course
Date: Wed, 7 Mar 2001 13:12:39 -0500
I am offering again a 4 day short course in applied crypto. A brief
outline is below. For more info about the course contents and
registration, please see our web site at
http://www.ece.wpi.edu/Research/crypt/courses/short_course.html
Regards,
Christof
! WORKSHOP ON CRYPTOGRAPHIC HARDWARE AND EMBEDDED SYSTEMS (CHES 2001) !
! Paris, France, May 13-16, 2001 !
! www.chesworkshop.org !
***********************************************************************
Christof Paar, Assistant Professor
Cryptography and Information Security (CRIS) Group
ECE Dept., WPI, 100 Institute Rd., Worcester, MA 01609, USA
fon:(508) 831 5061 email: [EMAIL PROTECTED]
fax:(508) 831 5491 www: http://www.ece.wpi.edu/People/faculty/cxp.html
***********************************************************************
Worcester Polytechnic Institute
4-Day Short Course
April 16,17 & 26,27
WPI Southborough Campus
APPLIED CRYPTOGRAPHY AND DATA SECURITY
Seminar Leader: Dr. Christof Paar
COMPLETE COURSE INFORMATION AND REGISTRATION:
www.ece.wpi.edu/Research/crypt/courses/short_course.html
COURSE OUTLINE
Day 1, AM - Introduction to Cryptography and Data Security
Overview. Private-Key Cryptosystems. Cryptanalysis.
Day 1, PM - Stream Ciphers
Random Number Generators. Synchronous Stream Ciphers and LFSRs.
Attacks. One Time Pad. Unconditional and Computational Security.
Day 2, AM - Block Ciphers: DES and AES
DES Functionality and History; Implementation: Hardware and Software;
Attacks and Security Estimations. AES: Functionality and History;
Hardware and Software Implementations. Other block ciphers. Key
length and security.
Day 2, PM - Modes and Variants of Block Ciphers
Operation modes of block ciphers. Multiple encryption. Key whitening.
Day 3, AM - Public-key Cryptography
Principle. Some Number Theory. Overview of Practical
Schemes. Public-Key standards (ANSI, IEEE).
Day 3, PM - Public-key Algorithms
RSA Cryptosystem: Functionality, implementational aspects, recent
attacks and security estimations. Diffie-Hellman key exchange.
Elliptic curve cryptosystems: principle, practical and security
aspects.
Day 4, AM - Digital Signatures and Protocols
Digital Signatures. Authentication Codes (MACs). Hash Functions.
Protocols for Privacy, Authentication, Integrity, Non-Repudiation.
Challenge-and-response protocols.
Day 4, PM - Key Distribution and Case Study
Key Distribution: Private-key approaches, public-Key approaches.
Certificates. Key Derivation. Case Study: Secure Socket Layer
Protocol.
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: Cipher idea
Date: Wed, 7 Mar 2001 18:29:14 -0800
Benjamin Goldberg <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> This idea is rather similar to some of Terry Ritter and Tom Denis'
> ideas, but I'll post it anyway :)
>
> t(0..15) = data being enciphered
> k(0..15) = encryption key
> k(i) = k(i-1)^k(i-4)^k(i-15)^k(i-16) = round keys (0 <= i < 512)
> xtimes(z) = (z<<1) ^ ((z&0x80) ? (0x11b) : 0)
> s(x) = sbox with LP_max <= 1/4 and DP_max <= 1/8, and no fixed points.
> AES's sbox will do fine, or a random one made with Tom's sboxgen.
>
> for r = 0..3: for i = 0..3: for j = 0..7:
> (a, b) = t(FFT(i,j))
> off = r*128 + i*32 + j*4
> a = s(s(a^k(off+0))^k(off+1))
> b = s(s(b^k(off+2))^k(off+3))
> c = xtimes(a^b)
> t(FFT(i,j)) = (a^c, b^c)
> end for; end for; end for
>
> Number of rounds is chosen to be >2 (to avoid mitm attacks), and as a
> power of 2 (for aesthetics), giving a minimum of 4 rounds.
>
> Key scheduling is simply an LFSR with the order 16 polynomial (0,1,4,15,
> 16). This means that the cipher can work with very little extra RAM;
> very useful for limited memory architectures. Transforming the last 16
> bytes of round key into the starting key is a linear op, and easy to
> calculate. Also, for decrypting, I need to start with the last bytes,
> and run the LFSR backwards; also easy to do. Of course, if you've lots
> of memory, you just expand the key into a 512 byte array, and don't
> worry about such silly things.
>
> 0x11b is taken from Rijndael. I see nothing about it that makes it
> better than any other order 8 polynomial, except that I think it's
> primitive.
>
> LP_max is chosen for security against linear analysis:
> (1/LP_max)^2x >= 256, x=2,
> 1/LP_max^4 >= 256,
> -4 lg LP_max >= 8,
> lg LP_max <= -2
> LP_max <= 1/4
>
> DP_max is chosen for security against differential analysis:
> (2/DP_max)^x >= 256, x=2,
> 2 lg 2/DP_max >= lg 256
> 2 (1 - lg DP_max) >= 8
> lg DP_max <= -3
> DP_max <= 1/8
>
> This makes the substitutions of a and b approximately SPRPs. I say
> approximate, since it's only differential and linear analysis that
> they're resistant to, not anything else. They are definitely vulnerable
> to dictionary attacks and brute force.
As every cipher is, this is no worry ;)
>They are probably vulnerable to
> related key attacks. However, since (I hope) attacking the substitution
> depends on getting at it in isolation, and (I hope) this is impossible,
> I'm not worried.
Making the round-key generator self-shrinking would remove the possibility
of related key attacks. But of course, you'd have to store all the
round-keys in arrays or something because you couldn't run the generator
backwards.
> Can anyone suggest any theoretical (or worse, practical!) attacks?
I can't suggest a break :)
A quick question, if dpmax is low and using (2/dpmax)^x (where x is the
number of rounds) is the plain-text requirement to exploit this dpmax.... if
the number of plain-texts required is greater than the number in existance
does this prove security against all diff attacks (like truncated
differentials etc....)....
Is the same true for linear cryptanalysis as well?
Simon.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 07 Mar 2001 18:33:19 GMT
Subject: Re: Buy a PDF edition of Applied Cryptography of Bruce SCHNEIER
It is on the Dr. Dobb's Journal CDROM on Cryptography, along with many others.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (Gregory G Rose)
Subject: Re: Question re Asymmetric Encr'n
Date: 7 Mar 2001 10:42:56 -0800
In article <Jasp6.38667$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
>
>"Arnold Shore" <[EMAIL PROTECTED]> wrote in message
>news:987lij$9cv$[EMAIL PROTECTED]...
>> I'm using a product that's based on CAST-128 and Elliptic Curve
>> implementation, and will appreciate information on how these work.
>> Specifically, I see that given fixed values for a private key and
>cleartext,
>> the encrypted output varies - but nonetheless decrypts correctly.
>>
>> How can this be? Apparently, there's some other input - how acquired?
>
>Well most likely CAST is used in a chaining mode such as CBC where the
>InitialVector (IV) is different for each ciphertext message you make.
That's one possible explanation but there are two
others that are much more fundamental.
First, if the package is any good, it will be
choosing a random symmetric key to be used for
CAST, and encrypting that using the ECC public-key
crypto. Using a different random key for each
message will certainly make the encrypted output
entirely different.
Second, the Elliptic Curve algorithms are all
discrete-log based, and the discrete log
algorithms all *require* random input as well as
the key and data to be signed/encrypted. This,
too, will mean that the ECC-encrypted output must
be different for different runs, even if all else
was the same.
Greg.
--
Greg Rose INTERNET: [EMAIL PROTECTED]
Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199
Level 3, 230 Victoria Road, http://people.qualcomm.com/ggr/
Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
