Cryptography-Digest Digest #947, Volume #10 Fri, 21 Jan 00 13:13:02 EST
Contents:
Re: Mispronounce words. (OT ) (Paul Gover)
Re: ECC vs RSA - A.J.Menezes responds to Schneier (Bob Silverman)
Re: simplistic oneway hash (John Myre)
Re: ECC vs RSA - A.J.Menezes responds to Schneier (Bob Silverman)
Re: Cracking an ADFGVX cipher (Jim Gillogly)
Re: Combination of stream and block encryption techniques (Mok-Kong Shen)
Re: NIST, AES at RSA conference (wtshaw)
Re: MIRDEK: more fun with playing cards. (Paul Crowley)
Re: MIRDEK: more fun with playing cards. (Paul Crowley)
Re: SRP optimisation (Paul Crowley)
Re: MIRDEK: more fun with playing cards. (Paul Crowley)
Calculating A^-1 Mod P ("HRook")
Re: Java's RSA implimentation (Tim Tyler)
Re: What's with transposition? (Tim Tyler)
----------------------------------------------------------------------------
From: Paul Gover <[EMAIL PROTECTED]>
Subject: Re: Mispronounce words. (OT )
Date: Fri, 21 Jan 2000 14:15:41 +0000
William Rowden wrote:
> ...
> I don't understand this. In both "annihilation" and "omnipotent," as
> I say those words (now that I've heard others say them :-)), the
> emphasis is on the second syllable (with a secondary emphasis on the
> penultimate syllable in "annihilation"). What's your pronunciation of
> "omnipotent"?
> ...
om-nip-otent, with emphasis on the second; but not omni-potent. I think
I'm now convinced by the penultimate syllable rule. Which of course
agrees with the third syllable rule, provided we stick to
con-vol-ut-ed wording :-)
Paul Gover.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: ECC vs RSA - A.J.Menezes responds to Schneier
Date: Fri, 21 Jan 2000 15:03:23 GMT
In article <[EMAIL PROTECTED]>,
Mike Rosing <[EMAIL PROTECTED]> wrote:
> Bob Silverman wrote:
>
> > Solving the matrix for a 1024 bit RSA key will take 6 x 10^6 times
as
> > long as solving one for 512 bits and will require ~10 Terabytes of
> > memory to hold the matrix. That's about 100,000 machines each with
> > 100 Mbytes of memory.
>
> But only 1000 machines each with 1GB of memory. Or 100 machines with
> 10 GB of memory. The former is off the shelf today, the latter will
> be soon (and at a reasonable price).
>
> > While I readily believe that one could probably get several hundred
> > PC's working in parlallel to solve the matrix, I also know that
these
> > will NOT yield linear speedup. This has been proven repeatdly in
many
> > experiments in many contexts involving large linear algebra
problems.
> > And the speed improvement will fall off even further from linear as
> > more machines are added. Suppose a set of 1024 machines gives
> > a 350 fold speed improvement. Doubling the number of machines might
> > then yield only a 500 fold improvement over 1 machine.
>
> This is clearly a hardware problem. If the bandwidth can be scaled,
> then the problem can be solved with "closely coupled" machines.
90+% correct. But the problem isn't just bandwidth; it is latency
as well. This is a worse problem.
The current *model* we use for crypto key breaking assumes that the
computation can be distributed for free using idle time on a loosely
coupled net. If some machines are unavailable or become busy, the
rest take up the slack.
But this does not work at all for a parallel matrix software.
Suppose (hypothetically) that bandwidth/latency on the internet
improved by 3 to 4 orders of magnitude. (It won't happen soon!)
The "idle time" model still does not work because if one machine
goes to sleep it stalls EVERYTHING. The other machines will be waiting
for data from the stalled machine. Yes, one could build in redundancy,
but detecting a stall event itself takes time. One needs to set a
"timeout threshhold". When this is exceeded, the work being done by the
stalled machine is given to another. But this incurs a very LARGE
latency every time a machine stalls. And the larger the network, the
more likely it is that *some* machine will be stalled at any given time.
I am speaking from actual experience here. You wind up spending a
large fraction of the total time managing stalls.
You need a DEDICATED, tightly coupled parallel processor with enough
memory. (it will need to have 64-bit processors). And this means
someone has to PAY for such a machine.
Also please note that I have seen it suggested that in some cases,
one might want to use keys as big as 3000 bits (or so). The matrix
for such a key can't even be addressed on a 64 bit machine. I don't
see 128 bit processors coming any time soon. [and 10^22 bytes of memory
is going to be expensive!]
> It will be an interesting hardware problem. Possibly a combination
> of algorithms and hardware would make 1024 viable in 1 year of
> computation.
We will not see any improvement in algorithms. The block-Lanczos
algorithm is about as close to the theoretically best possible as
any algorithm in existence. (Theoretical best possible is
Omega(N^(2 + epsilon)) for any epsilon > 0 (maybe depending on N).
B-L achieves O(N^2 d)
where d is avg. density per row. Even in practice now, epsilon is
small (.25 or so)
> But that probably won't happen any time soon, so I agree that 1024 is
> pretty safe.
But Lenstra's paper argues that space is not an issue and says 1024
bit keys are safe only for a couple more years. Further, his paper
uses the very model of computation I discussed above: free idle time.
And that just won't work.
Yet many have latched onto his paper as if it were gospel.
>
> Patience, persistence, truth,
> Dr. mike
>
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: simplistic oneway hash
Date: Fri, 21 Jan 2000 09:10:09 -0700
[EMAIL PROTECTED] wrote:
>
> I have what is probably a rather unusual request. I need a very simple
> to code and understand one-way hash. I don't care a great deal as to
> whether it is truly secure at all, as long as it can be implemented
> in no more than a couple dozen lines of code in Fortran 90.
My favorite algorithm for simplicity is RC4. You can use it as a
hash if the input is no more than 256 bytes; then the output is as
many bytes as you care to get. Although I've seen doubts expressed
about its cryptographic strength, it's probably enough to defeat
a programming class.
>
> The reason for my needing such a function is that I have been asked by
> a professor at my university to help construct a project for his
> Programming Languages class. He would like to introduce his students
> to parallel processing by assigning them a project that required them
> to code in High Performance Fortran on our school's beowulf cluster.
> He asked for a suggestion of an appropriate project, and the idea of
> brute-forcing the plaintext given a one-way hashing function and the
> ciphertext came to mind.
I wonder - do you really mean a hash function? Or would a cipher
be better? The output of a hash function is usually called a hash,
or digest, not ciphertext. In fact, a regular "crack" of a message
would be easier to understand. That is: "well students, here is the
secret message, and here is the algorithm; we don't know the key,
so you have to search for it - you can tell when you got the answer
when it's all (7-bit) ASCII." So instead of looking directly for the
message, they are looking for a key that will produce the message.
In this case, RC4 is even better, since it is still just as easy to
code, and is being used as it is intended: to encrypt a message!
(If you have different secret messages for different students, or
teams, make sure you have different keys, as well. Besides the cheating
aspect, this is a cryptographic requirement.)
If RC4 is too simple, you might try RC5 or RC6; the latter might be
attractive as you could say "this algorithm is one of five being
considered for the next U.S. Government standard for encryption".
I can just imagine the students perk up at that.
<snip rest of original post>
Good luck -
John M.
P.S.
RC4 is defined in lots of places; it is called ARC4 in one of the
internet RFC's. I like this site:
http://ciphersaber.gurus.com/faq.html#getrc4
For RC6, I'd go to NIST's AES site:
http://csrc.nist.gov/encryption/aes/round2/AESAlgs/RC6/cipher.pdf
RC4, RC5, and RC6 all are by Ron Rivest, of RSA. You *might*
want to check with them as far as copyright/patent/etc. I doubt
they'd care about a school project, and RC4 is pretty much
unencumbered anyway.
P.P.S.
If you really want a hash function, a real one, maybe MD2 would
do for you. I don't know what it looks like, actually; but it's
by Rivest, and is a precursor to his MD4 and MD5. Given how simple
a lot of his algorithms are, maybe MD2 is easy, also. Of course,
it's been declared "broken", but that's not the same thing as
saying a programming class can do anything about it.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: ECC vs RSA - A.J.Menezes responds to Schneier
Date: Fri, 21 Jan 2000 16:11:30 GMT
In article <867pg9$jc5$[EMAIL PROTECTED]>,
Greg <[EMAIL PROTECTED]> wrote:
>
> > There are composite numbers that will work as P/Q for RSA.
> > They are VERY, VERY rare-- it is much much more likely
> > that a randomly chosen number is prime than a usable
> > composite number.
>
> At first, I thought you were saying that the composite would
> be stronger than a prime. Is that correct?
This is gibberish. What does "stronger than a prime" mean?
>
> But the real question is can you find a composite number that you
> think is prime,
Yes.
> that appears to work
Yes. But it won't happen in the lifetime of the Universe. The
probability is too small.
> and yet can weaken the key?
Not in practice. The security of the key generally depends only on the
size of the key. Theoretically one could construct a key N = pq where
both p and q are Carmichael numbers and each of p and q have 3 or more
approximately equal factors. (for 512 bit p,q and at least 8 rounds
of Miller Rabin the probability is something less than 10^-125)
Such a key could be attacked with ECM. But how would an opponent guess
that an attack with ECM might succeed? Why would anyone spend money
attacking a random key with ECM (and succeeding only with low
probability) when NFS can do it with certainty in less time?
However, probabilistic tests filter out
Carmichael numbers with VERY high probability and the probability that
a Carmichael number possessing several equal factors gets by a test is
even lower.
However, noone is forcing you to test your primes with probabilistic
methods. Fast deterministic methods are available for the truly
paranoid.
> IFP differs from ECC in that the strength of IFP is determined
> randomly
This statement is nonsense. The complexity of factoring N
with the best method (NFS) is exp( (c + o(1)) (log N)^1/2 (loglog N)
^2/3) This depends only on the size of N. It is not 'random'
> and with a quick check because the strength lies in the
> key itself. With ECC, the strength lies in the curve, not the
> key,
BZZT. Wrong. Thank you for playing.
The private key is a randomly chosen integer bounded by the size
of the underlying field.
The security of ECC certainly does depend on the choice of private key
because if it is small, then it can be found by direct search. It
will be small with low probability, but it CAN happen. The probability
here however, is vastly GREATER than that of choosing a bad "prime"
for RSA. Say we have a 160 bit field. A direct search will work
readily if the private key is less than (say) 2^40. The probability of
this happening is 2^-120. Still very small, but much greater than
10^-125.
Further, if it can be guessed that the private key lies in a restricted
range, then a square root attack can be applied whose run time will be
proportional to the square root of that range.
With RSA, if the top 20 bits of a key somehow get revealed, that info
is of no use to NFS. But with ECC if the top 20 bits get revealed, then
you can speed up attacks on the key by a factor of 1000.
Do us a favor. Go study the algorithms before making any further
"pronouncements".
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Cracking an ADFGVX cipher
Date: Fri, 21 Jan 2000 16:59:19 +0000
UBCHI2 wrote:
>
> ADFGVX coordinates implies a 6x6 checkerboard.
> With computer brute force tactics, you could create every variation of
> alphabetic checkerboards and then all transposition grids for the 6x6
> checkerboard force attempts. This would not be hard if you had a plaintext
> crib either.
It wouldn't be hard to write the code, but executing it is something else.
There are 36! different checkerboards, assuming no homophony is being used.
Typical periods used for ADFGVX in the Friedman/Rowlett/Kullback/Sinkov
paper are up to 27, which means 27! different transposition arrangements,
for a total of 36! x 27! different things to try in your brute force search.
That's about 3 x 10^32 x 10^28, or 3 x 10^60. If my calculations are right,
you're suggesting brute-forcing a 200-bit space.
There are much easier ways to attack this problem.
--
Jim Gillogly
30 Afteryule S.R. 2000, 16:53
12.19.6.16.0, 3 Ahau 8 Muan, Fifth Lord of Night
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Combination of stream and block encryption techniques
Date: Fri, 21 Jan 2000 18:45:35 +0100
Terry Ritter wrote:
>
> <[EMAIL PROTECTED]> wrote:
>
> >[...]
> >The point worthy to be repeated is that one need not keep a strict
> >distinction between stream and block ciphers, i.e. there is no sharp
> >boundary between these...
>
> I claim there *is* a useful distinction between a cipher which can
> work on the minimum possible amount of information -- a bit -- and one
> which inherently requires multiple bits before it can start to
> operate. Moreover, the distinction helps clarify various
> characteristics of cipher operation.
>
> The alternative is to say that stream and block ciphers are the same.
> Indeed, we might as well say "all ciphering is substitution" and leave
> it at that. But these claims are singularly unhelpful in providing
> insight to cipher design.
>
> Now, most real stream ciphers do in fact work on tiny byte-size
> "blocks," and most block ciphers are in fact operated as stream
> meta-ciphers. Thus, real use tends to blur a distinction which is
> both clear and important for analytic purposes: A block cipher will
> have data diffusion across the entire fundamental block, even from
> latest data to "earlier" ciphertext within the block, and that will
> not happen in a stream cipher. The distinction is thus measurable and
> not just academic. It is just as useful to see a block cipher as a
> huge keyed substitution, which has diffusion as a consequence. The
> block width thus limits both the number of possible keys and code
> values, and establishes a direct correspondence both to Simple
> Substitution and classic codes.
>
> Shall we see a stream cipher as a block cipher with a 1-bit-width
> block? I don't think so: I don't see much diffusion there. The
> reductio ad absurdum argument fails specifically because the useful
> distinction first appears when we have a block whose size is larger
> than one element.
Could we perhaps say that the fundamental component of a stream
cipher is its key stream, which is commonly supplied by a pseudo-
random number generator etc., while a block cipher doesn't have
that (or at least doesn't have that explicitly). I am not very sure
whether this is o.k., hence I should appreciate discussions on
this point. In case the answer is yes, then we don't have to
consider the bit-width (i.e. whether 1 bit or more) as a
distinguishing criteria between stream and block ciphers and we
could consequently discuss the topic of this thread in an
easier way, I guess.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: NIST, AES at RSA conference
Date: Fri, 21 Jan 2000 12:08:01 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> Serge Vaudenay wrote:
> >
>
> > Actually, if an expert do not have any personal interest about AES, he
> > should better wait
> > for the final standard before doing some substantial work. In the
> > meanwhile he can work
> > for other standards.
>
> Very probably I misunderstood. But my (superficial) interpretation
> of your sentence means that the AES winner would not have got much
> study by the majority of the experts at the time point the winner
> is declared to be a standard by NIST for use by people of the
> whole world. That's pretty bad, isn't it?
>
New and fresh analysis is sure to be legacy of winning. Finding a flaw in
it would be a bigger coup that knocking off an also-ran in additional
ways.
--
To prevent the comprimise of with the most common configuration
of computers is something like preventing a sculptor from being too original. If a
computer design is corruptable, it will be.
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: 21 Jan 2000 08:28:16 -0000
CLSV <[EMAIL PROTECTED]> writes:
> So it does pay to use a strong password. If you are not able to
> communicate a 52-card key one time I don't believe you have any
> chance to communicate securely.
When you say "one time", you mean "once per message". If you're in a
position to communicate big strings of random nonsense once per
message, you can use the most successful secure hand cipher in the
world, the one time pad.
On the other hand, six randomly-chosen six digit words can be
memorised readily, and searches will not reveal them. If you use
Diceware to generate them, this will give you 77.5 bits of entropy in
your keyphrase - enough to keep even the best funded attackers off
your back for quite a while.
> In the context of civil rights you'll need a semi-secret
> communication channel anyway. If someone catches you sending letters
> with content like "AXQZV WXYXZ OINAF ..." I think you can expect a
> visit of the local Gestapo pretty soon.
Or at least a channel by which, if messages are intercepted, they
can't be traced back to you.
> Well you could use two decks of cards, say a blue deck
> and a red deck. There are quite a few card games using
> two decks so it would not look too suspicious.
True, but I'd rather the output consisted only of the letters A-Z,
which fixes the input to those letters for any convenient variant of
Mirdek. Unless you use some sort of input transformation which
converts the input to a string of characters drawn from A-Z...
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: 21 Jan 2000 08:40:46 -0000
[EMAIL PROTECTED] (Paul Rubin) writes:
> You'd lay out 4 rows of 13 cards face up, with a pair of coins
> (not identical) to mark where the X and Y pointers are. Losing
> your place swapping cards doesn't sound like a problem. Since 4 and 13
> are co-prime, you'd do the arithmetic mod 4 and 13 separately, so
> you'd go up 2 columns and over 5, or etc. I've gone through this
> in my head and it doesn't seem too bad.
ISTR this exact cipher was proposed on this very newsgroup long before
Solitaire was ever published - was it you perchance? I'm not
surprised to learn that it's fast, but finding enough table space to
lay out all the cards is a pain, and when you do the arithmetic as you
suggest you're looking at a very different cipher than RC4 - possibly
one far more biased. If you ever code it up, though, please let us
know and I'll do some statistics on the output.
In general, I recommend *everyone* write a machine implementation of
their proposals, because without one it's hard to assess the accuracy
you can achieve. I've been testing Mirdek by decrypting random
outputs from Unix "fortune".
I also think that only randomised ciphers are practical proposals,
since you can't keep exchanging keyphrases! So I'd be interested to
hear ideas about how to make a randomised cipher out of ARC-13-4.
> I'll have to try it with an actual deck of cards sometime when I get
> around to borrowing one (I don't have one handy and don't feel like
> buying one just for this).
Oh go on, this is fun! I currently have three decks of cards lying
about, two of which are now marked with letters because they're too
old and marked to be used for card games...
> One character/minute sounds pretty painful.
No, it's more like two characters per minute, with a ten minute
overhead. Actually it's slightly faster than two characters per
minute for me at the moment. With a friend transcribing the
ciphertext, I wouldn't have to stop to reach for a pen and I could
probably get it done in about 20 seconds per character.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: SRP optimisation
Date: 21 Jan 2000 08:53:11 -0000
John Myre <[EMAIL PROTECTED]> writes:
> Paul Crowley wrote:
> > Unfortunately, it seems you *can* mount a password-guessing attack if
> > you can fool a client into thinking you're the server. That's quite a
> > bit harder, though.
>
> Actually, I don't think so. This is because the server does not
> send an unadorned B = g^b, but B = g^b + v (where v is the verifier
> based on the password and salt). If you are pretending to be the
> server, of course you can send any B you want. But since you don't
> know v, you don't actually know the effective b (your purportedly
> private key) either!
Ouch! All this cleverness makes my HEAD hurt!
I'll try venturing an observation again and see if I get shot down:
you can't use the same trick for the client end only because the
client doesn't have the password salt when the ephemeral public key A
is generated. You could send it and save a pass at the end, but you
introduce a pass at the beginning!
Hmm. On the other hand, if you *could* pull such a trick with that
caveat, it might be worth it anyway, since lots of clients could cache
salts. Hmm.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: 21 Jan 2000 08:42:06 -0000
"r.e.s." <[EMAIL PROTECTED]> writes:
> For ARC4 using 54 cards in the way I described, it's certainly 52!, because
> the jokers are used strictly as pointers.
The position of the pointers is part of the state of both pure ARC4
and ARC4-52, thus 52! * 52 * 52.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: "HRook" <[EMAIL PROTECTED]>
Subject: Calculating A^-1 Mod P
Date: Fri, 21 Jan 2000 10:00:24 -0800
I'm trying to teach my self the rudiments of Elliptic Curves. I noticed that
when adding two points together, one of the calculations is x3=
((y2-y1)/(x2-x1))^2 - x1 - x2 MOD P
This leads to the question, "How does one divide by (x2-x1) MOD P. I assume
the answer to that is "multiply by (x2-x1)^(-1) mod P.
So, how do you calculate A^-1 Mod P. I have a vague memory that the Extended
Euclidian algorithm can do this, but I can't remember the details of this
algorithm. Any help would be appreciated.
Thanks,
Harv.
[EMAIL PROTECTED]
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Java's RSA implimentation
Reply-To: [EMAIL PROTECTED]
Date: Fri, 21 Jan 2000 17:23:58 GMT
Paul Schlyter <[EMAIL PROTECTED]> wrote:
[BigInteger objects are "immutable". They can't be altered once created...]
: What would happen if you instead of A=A+1 tried e.g. B=A+1; A=0; ???
No juice. New A (=0) object created. Old A object still floats around
the system like an unwanted turd.
A BigInteger method to explicity overwrite the memory normally occupied by
a would probably be simple to implement for anyone with source code.
However, there's a deeper problem - AFAIK, "a = b + 1" offers no sort of
guarantee that the memory a occupied is overwritten - even when a is an
integer.
You might think that "for (i = 26; i-- != 0; ) { a = rnd.nextInt(); }"
might be /fairly/ effective at scrubbing out the relevant memory traces.
However, AFAIK, the JVM may keep a copy of a hanging around the system
without telling you e.g. as part of it's JITting optimisations.
This may still be a problem, even if you can turn off swap file usage.
I don't know if this is ever at all important in practice - but it
might be something to bear in mind.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Female programmers get their bits twiddled.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: What's with transposition?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 21 Jan 2000 17:34:25 GMT
KitKat <[EMAIL PROTECTED]> wrote:
: He affirms (twice) that transposition is "as a general rule"
: easily broken. My first reaction, in its purest form, was something in the
: vincinity of "Dang it!". My problem is that he doesn't seem to explain why
: anywhere close to that statement. I'd like to have the explanation as to
: why transposition (-only) cryptosystems are easily defeated (as in: "no
: matter how "complex" your transposition scheme may look to you"). [...]
I'd have thought one primary problem with transposition is that
it immediately gives away supposedly secret information about the
message contents.
Suppose your plaintext reads (in hex) "0000000000000000000000".
Try encyphering that using different "transposition keys" - and see
what secrecy of the message is provided.
Random padding might help "dilute" the severity of this problem - while
bulking up your messages.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
All programmers want arrays.
------------------------------
** 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
******************************
