Cryptography-Digest Digest #602, Volume #9 Thu, 27 May 99 11:13:02 EDT
Contents:
Re: DSA (Digital Signature Standard) and the Schnorr Patents (Vin McLellan)
Re: Why would a hacker reveal that he has broken a code? (Wesley Horton)
Re: Review of Scottu19 (Thomas Pornin)
Re: Hot on the heels of hushmail.... ([EMAIL PROTECTED])
Re: What good is hushmail? (John Kennedy)
Re: AES tweaks ([EMAIL PROTECTED])
Re: Review of Scottu19 (SCOTT19U.ZIP_GUY)
Re: Review of Scottu19 ([EMAIL PROTECTED])
Re: Review of Scottu19 (SCOTT19U.ZIP_GUY)
Re: AES tweaks (SCOTT19U.ZIP_GUY)
Re: crack a hash function? ("Jean Marc Dieu")
Re: Why would a hacker reveal that he has broken a code? (John Savard)
Re: non-computerized cryptography (John Savard)
----------------------------------------------------------------------------
From: Vin McLellan <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: DSA (Digital Signature Standard) and the Schnorr Patents
Date: Thu, 27 May 1999 03:41:06 -0300
Vin McLellan <[EMAIL PROTECTED]> wrote:
>> [Even today -- a year after the NSA gave up on Fortezza
>>(because, said the Agency internally, it couldn't get secure
>>workstations for network management)-- it still takes a formal Waiver
>>Proclamation by the Director or CIO of a federal agency to allow any
>>federal entity to escape the DSS FIPS. The EPA announced such a FIPS
>>140 Waiver a week ago, so that the EPA could use the RSAPKC in Lotus
>>Notes. (See: <http://jya.com/epa051099.txt>)
Joshua E. Hill <[EMAIL PROTECTED]> noted:
>A minor point:
>This was only for signatures. FIPS 140-1 (the standard that crypto
>modules must meet in order to be used by the US government) allows
>"commercially available public key methods" to be used for key
>distribution.
My typo. Sorry. I meant to write FIPS 186 (DSS) but
mistakenly typed FIPS 140 (which specifies the requirements for a
validation of FIPS-compliant crypto modules).
Teach me not to toss out something like this off the cuff;-)
The EPA's May 10th waiver proclamation -- required so EPA
could continue to use the RSA-based cryptosystems distributed with
Lotus Notes -- specified that the waiver applied to FIPS PUB 186
(DSS), FIPS 180-1 (Secure Hashing Standard), the FIPS 46-2 (DES). The
jya.com URL cited above has the full text of the waiver.
>You could always have used RSA for encryption, just
>not signatures. In fact, you could have included RSA for signatures,
>as long as you also included DSA for signatures, and specified a
>mode that didn't use RSA for signing.
I don't believe that is completely accurate, although it is
true that the FIPS, per se, allowed all that, and required no more
than that.
The ESS (FIPS 185) is, after all, a uniquely "voluntary" federal
procurement standard -- just because its long-classified algorithms
were not open for the public comment required for a mandated FIPS.
What this comment overlooks, however, is the pervasive full-court
press the NSA (and for awhile, NIST) put on the other federal agencies
to eschew RSA (and D-H, for that matter) and to wait for Fortezza.
I know of major IRS and NASA networks which were designed around PKC,
but which were ultimately brought into service without cryptographic
protection because of direct NSA intervention. I understand that other
examples abound.
The only major exception, so far as I know, was the CIA (which used
Lotus Notes extensively and wasn't about to ask the NSA for permission
to turn on its cryptographic features.) The NSA apparently found it
difficult to overawe the CIA.
There are many on these Lists who could surely address this better
than I, as I recall, but from about 199l to 1997, the US civil
agencies and the military services were subjected to a display of
bureaucratic muscle perhaps unprecidented since WWII to keep them in
line, and to keep commercial PKC out of federal networks.
Managing the aggregate federal purchasing power in InfoSec was
crucial to the NSA's strategy for promoting the commercialization of
GAKed cryptosystems.
>Of course, this is all moot today, as ANSI x9.31 (rDSA) was adopted
>in FIPS 186-1. (rDSA is RSA without the name problems...) So today,
>you can use RSA for both encryption and signing in FIPS compliant
>crypto modules...
There are still a few (FIPS 140-type) "I"s to be dotted and "T"s to
be crossed, but doubtless SDTI -- RSA's parent company, and a
long-time client of my firm -- will be estatic if that soon becomes
true.
_Vin
========
"Cryptography is like literacy in the Dark Ages. Infinitely potent,
for good and ill... yet basically an intellectual construct, an idea,
which by its nature will resist efforts to restrict it to bureaucrats
and others who deem only themselves worthy of such Privilege."
_A Thinking Man's Creed for Crypto _vbm
* Vin McLellan + The Privacy Guild + <[EMAIL PROTECTED]> *
53 Nichols St., Chelsea, MA 02150 USA <617> 884-5548
------------------------------
From: Wesley Horton <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Why would a hacker reveal that he has broken a code?
Date: Thu, 27 May 1999 04:24:44 -0500
So, John..
Just as a matter of question, roughly how long would it take a new 550
mhz Pentium to do an exhaustive key search on single DES?
Also, isn't it fair to say (as an aside) that a system such as the
SIGABA, with new rotor sets which were used only once (for the message
enciphered) would be secure as a matter of principal?
Thanks,
Wesley Horton
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: Review of Scottu19
Date: 27 May 1999 09:27:29 GMT
According to SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>:
> I am not a C purist in case you could not figure it out. But I see
> C as a tool to help one write code. But only a modern lazy programmer
> would blindly code without giving the underlying machine some serious
> thought.
You are missing the point. The C specification provides a 'virtual
machine' and the compiler job is to implement this machine on the real
one. If you make assumptions about the way it will be done, you produce
code that cannot be ported to other architectures; this is considered
horrible engineering and really poor way of coding.
The only excuse for doing so is that in some cases you may gain some
speed of execution, but this is rare on modern architectures (using a
decent compiler, such as djgpp) and, anyway, you do not seem to care
about speed. Moreover, your huuuuuge table imply that the speed of your
algorithm will be at best the speed of the memory bus, whatever the code
does after that.
To sum up: by coding like this, you obfuscate your code, make it less
portable and understandable and advocate yourself as a lamer, which does
not help people considering your algorithm worth the effort. And with no
gain whatsoever. If you really want to know the hardware, learn the
'ANSI C hardware' (where endianness is not a relevant notion).
However, the fact that your are proud of such coding is funny.
--Thomas Pornin
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Hot on the heels of hushmail....
Date: Thu, 27 May 1999 08:36:18 GMT
In article <[EMAIL PROTECTED]>,
fungus <[EMAIL PROTECTED]> wrote:
>
> A new service called ziplip has just appeared.
>
> http://www.ziplip.com/
>
> It's a variation on Hushmail but uses private keys - you have to agree
> on a key with the recipient. It has a "hint" feature so you can send
> messages without arranging a password (eg. "Where we had lunch last
> week....").
Passwords are limited to 15 characters, the Web site doesn't explain
what algorithm they use for encryption, and they display part (not all)
of the ciphertext when you receive encrypted email. It's in a box,
with the password dialog on top. It can be selected and copied
to the clipboard.
15 characters is enough if and only if you're genuinely random.
Question for the real experts: if ziplip is using one of the well-known
algorithms, could an attacker do anything useful with a dictionary
attack on fragmentary ciphertext? I suspect not, but I wouldn't
be surprised to learn differently.
-Fred
Permanent address:
f r e d e r w @ p o b o x . c o m
(sorry, spammers have been scanning message bodies for email
addresses lately).
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: [EMAIL PROTECTED] (John Kennedy)
Subject: Re: What good is hushmail?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 27 May 1999 12:02:02 GMT
On Thu, 27 May 1999 01:06:11 GMT, [EMAIL PROTECTED] wrote:
>At least in some foreign countries we all know, It's pretty easy for
>the relevant gov. agency to get your friendly neighborhood isp to
>redirect the DNS entry for hushmail to a "clone" site that looks just
>like it...so if you really need to protect yourself against Big
>Brother and the Holding Company, clearly this ain't the way....sorry
>suckers.
In principle on a hushmail type system you can validate that the code
runnining on your machine is secure and you can validate your target's
key. If you validate those Big Brother can't read your mail at the
redirected site without cracking strong crypto.
--
John Kennedy
--
The causal world imposes a nonarbitrary distinction between detecting in one's visual
array
the faint outline of a partly camouflaged stalking predator and not detecting it
because of
alternative interpretative procedures. Nonpropagating designs are removed from the
population, whether they believe in naive realism or that everything is an arbitrary
social
construction.
(Tooby and Cosmides, in _The Adapted Mind_, Barkow,
Cosmides and Tooby, editors )
=======
Best Anarchy Links:
David Friedman -> http://www.best.com/~ddfr/
Niels Buhl -> http://www.math.ku.dk/~buhl/
Billy Beck -> http://www.mindspring.com/~wjb3/promise.html
========
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: AES tweaks
Date: Thu, 27 May 1999 12:13:44 GMT
> why? I think again this is due to the fact the NSA is very
comfortable with
> the weak way block ciphers are chained together today.
> Another area of void is the use of headerless compression before
encryption
> again the crypto gods say little about this because it may make the
NSA
> job harder.
Really. So block ciphers are weak hmm? That's nice but prove it. I
bet you ten bucks someone (maybe including me) could break your
algorithm faster then you think. They just don't care because you
algorithm is inefficiently detailed.
For gods sake (pardon that) just document the @##@ cipher and be done
with. It's not that hard, just open ms-dos edit and write into a file,
save and send. I can guarantee people will appreciate it much more
then 'I am so good look at my messy code' you keep writing.
Block ciphers like stream ciphers are only as safe as implement. How
safe is a cipher with only 2 keys? Or public keys, or if you give the
keys away, or if you .... You have to be smart. For the most part the
algorithms are resistant to analysis (IDEA, RC5, CAST, Blowfish are
good examples). They haven't been broken because of the number of
rounds and the structure.
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Review of Scottu19
Date: Thu, 27 May 1999 13:10:39 GMT
In article <7ij361$et8$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Thomas Pornin) wrote:
>According to SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>:
>> I am not a C purist in case you could not figure it out. But I see
>> C as a tool to help one write code. But only a modern lazy programmer
>> would blindly code without giving the underlying machine some serious
>> thought.
>
>You are missing the point. The C specification provides a 'virtual
>machine' and the compiler job is to implement this machine on the real
>one. If you make assumptions about the way it will be done, you produce
>code that cannot be ported to other architectures; this is considered
>horrible engineering and really poor way of coding.
>
C is meant so that programers can code quickly from one machine to another
but it lacks many features that would be of use to a encryption programer.
For example ASCII C does not have a nice way of speciifing number of bytes
per variable. There are ways to find out be the number of bits (bytes)
which varies from machine to machine or even form even which C complier
on your machine.
>The only excuse for doing so is that in some cases you may gain some
>speed of execution, but this is rare on modern architectures (using a
>decent compiler, such as djgpp) and, anyway, you do not seem to care
>about speed. Moreover, your huuuuuge table imply that the speed of your
>algorithm will be at best the speed of the memory bus, whatever the code
>does after that.
>
>To sum up: by coding like this, you obfuscate your code, make it less
>portable and understandable and advocate yourself as a lamer, which does
>not help people considering your algorithm worth the effort. And with no
>gain whatsoever. If you really want to know the hardware, learn the
>'ANSI C hardware' (where endianness is not a relevant notion).
>
>However, the fact that your are proud of such coding is funny.
>
Actually I like C for its convenicene I have implimented the critcal
routines of scott16u to assemble where it does run faster. But I do like
the use of C since it is faster to write code on my PC. I can't please
everyone and I am sure if I released scott19u as aseembly it would please
even fewer. I did have a version of scott16u that ran on a SUN when my local
ISP provider in california allowed access and I got a Mac version to run at
that time on a friends machine but both invovled code cahnges. However the
PC version ran the best and I no longer have copies but it can be done.
Maybe they exist in an NSA storage area at this time. IF they don't have a
copy of the SUN version any more maybe the Chinese embassy can point
you to such an implimentation.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Review of Scottu19
Date: Thu, 27 May 1999 12:08:12 GMT
> However, the fact that your are proud of such coding is funny.
Yeah I know. Oh well.
Scott, if you can't explain your algorithm properly then what's the
point? I could implement CAST or Blowfish which are easier to
understand and implement. Scottu19 is not only non-portable but it's
difficult to follow. It's hard to see the 'actual' security of the
algorithm.
It's easy to say I have 19x19 s-boxes (x * (x + x + 1)) mod 2^w is a a
large s-box.
The large s-box you have need not be actually in memory. Have you
though of using a function instead? Like IDEA or SAFER?
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Review of Scottu19
Date: Thu, 27 May 1999 14:16:02 GMT
In article <7ijcjb$hc1$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
>> However, the fact that your are proud of such coding is funny.
>
>Yeah I know. Oh well.
>
>Scott, if you can't explain your algorithm properly then what's the
>point? I could implement CAST or Blowfish which are easier to
>understand and implement. Scottu19 is not only non-portable but it's
>difficult to follow. It's hard to see the 'actual' security of the
>algorithm.
>
>It's easy to say I have 19x19 s-boxes (x * (x + x + 1)) mod 2^w is a a
>large s-box.
>
>The large s-box you have need not be actually in memory. Have you
>though of using a function instead? Like IDEA or SAFER?
>
>Tom
Yes Tom I have thought of using function like IDEA but I don't like the
small key space they give. I feel that the NSA has advanced quatun computers
and that key space of less than 100K bytes are to small to be practical.
But you must realize I give the NSA much more credit for there ability and
the rest seem to think the NSA spends billions of dollars for nothing.
Maybe some day soon I hope the Chinese may make public the NSA
methods that they bought through the Clinton administration. But they may
work in secrest with us so we can team up against the Europeans. I think
we still share our data with them with the signal bases in China.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: AES tweaks
Date: Thu, 27 May 1999 14:08:31 GMT
In article <7ijctn$hf8$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
>> why? I think again this is due to the fact the NSA is very
>comfortable with
>> the weak way block ciphers are chained together today.
>> Another area of void is the use of headerless compression before
>encryption
>> again the crypto gods say little about this because it may make the
>NSA
>> job harder.
>
>Really. So block ciphers are weak hmm? That's nice but prove it. I
>bet you ten bucks someone (maybe including me) could break your
>algorithm faster then you think. They just don't care because you
>algorithm is inefficiently detailed.
>
It is not that all block ciohers are inherently weak it is just that so much
focus on them limits the amout to testing groups like the NSA have to do
when something encrypted is encountered. So people should be working
on other types as well.
But as a proof of weakness in the chaining methods and a proof that the
chaining methods in use suck big time. Here is a simple procedure that even
someone with very limited resouces can do. You wnat see this in the
crypto gods book since it is so obvious and the crypto gods really don't
want you to learn.
Taka a long file of your chioce but many thousands of bytes in length use
any AES candidate and use CBC with an IV of your choice. Now btye swap
the file ( I have reverse at my site in the compression section) now pick
any other or the SAME AES candidate pick a new IV and new key and encrypt
the file again. Take this resultant file hex edit it change ine bit in the
middle of the file. Now reverse the encryption with last method used. reverse
file and decrypt with the first method used. You know have a file that matches
exactly the original file except for a few blocks in the area of where you
twiddled the bit. For laughs you can do the same thing again but use the wrong
IV's for the decryption this time besdies the same area where the bit was
twiddled the front and back few block are messed up. This is because the
crypto gods want people to use methods where only a small portion of a file
needs to be examined and studied for a break to occur. This allows for easy
attack if you start your files the same or use stuff like woud where Mr gates
can easily place small streches of plain text to help the NSA.
Try the same thing with scott19u or scott16u but you don't even need the
IV( ranom padding) just use one pass and the option where file lenght out
matches file lenght in and then encrypt hex edit one bit anywhere in the file
then decrypt. You get garabage compared to the first file.
Now if you don't like SCOTT19u you can take you favorite AES block method
and do 3 rounds of "wrapped PCBC" and get the same results as my method
but the crypto gods would not want you to do this since it makes breaking
your message much harder and they really don't want that.
Actually people have tried to break it. There is a large cash contest for
the scott16u version that I am running at my site. And know that scott19u
is open to the world I will run it as a cash contest after the scott16u
contest ends on Nov 11 1999.
Right now there is a wram up contest for the scott19u where I do things
that the AES people can not do. Since the methods in the AES pale
in comparsion to my methods. ( I may call my next version OIL of Black Mamba
since they Fishy names are already taken it will be OBM for short)
I will run the contest like the current 19u contest where there is at most
only 80 bits of data not known and when those are discovered it will be
self evident that there is an anwser.
>For gods sake (pardon that) just document the @##@ cipher and be done
>with. It's not that hard, just open ms-dos edit and write into a file,
>save and send. I can guarantee people will appreciate it much more
>then 'I am so good look at my messy code' you keep writing.
>
It is documented on my page Host Ossiffrage(bad spelling) spent weeks
trying to do that.
>Block ciphers like stream ciphers are only as safe as implement. How
>safe is a cipher with only 2 keys? Or public keys, or if you give the
>keys away, or if you .... You have to be smart. For the most part the
>algorithms are resistant to analysis (IDEA, RC5, CAST, Blowfish are
>good examples). They haven't been broken because of the number of
>rounds and the structure.
>
>Tom
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: "Jean Marc Dieu" <[EMAIL PROTECTED]>
Subject: Re: crack a hash function?
Date: Thu, 27 May 1999 16:18:49 +0200
>> A hash is cracked if a second text can be found which hashes to the same
>> value as the first. A hash is NOT a cryptosystem, and thus it is not one
>> to one. It is a verification system, that the original has not been
>> changed. If you find a second, then the original can be changed.
But does that mean that you can make ANY change you wish on the original
message once you found one particular text which leads to the same result? I
mean, maybe there is collusion, but you cannot manipulate the other "fake
originals" so as to have whatever you want. I suppose there shall be some
rules to follow when you want to make a change, and that when you want to
change, say, the value of the contract, you should change almost all the
text around and this forged message has nothing else to do with the "true
original".
>One might consider that being able to find the original input would be a
>break. So, having multiple possible inputs, perhaps many, would help
>protect the original words.
It would be interesting that among the many inputs possible for one specific
result, only one would have a language structure (such as: "This contract
..." in opposition to "H�#2@|&~^+U ...").
I'm not a mathematician, so I'll probably be wrong (but I expect somebody to
tell me why... :). I think there isn't any possible collusion-free hash
function as you "lose" information by doing so. The only collusion-free
"hash" function in my view, is a very well compressed message (I mean you
try to have a compression that leads to the maximum average self information
(entropy=1/2 right?) ) and followed by encryption - but then it wouldn't be
a hash function, isn't that right? As long as you "remove" some information
from a message (to obtain a hash of it), collusion will be possible?
(I know that this is very intuitive and probably not mathematically
rigourous at all, but I am only a humble management student very keen on
crypto... :-)
>One interesting approach, at least I think so, is to use multiple hash
>functions that each have considerable collision, and combine all the
>results.
I have been thinking about multiple hashes too. Please correct me if I'm
wrong:
"Multiple hash reduces tremendously the probability of collusion, but
doesn't eliminate this possibility"
What do you mean by multiple hash?
-Paralell (you have an input M and you hash it with k different hash
functions in paralell; that leads to the following output: M1, M2, ... Mk)
- Serial (You use the (k-1) output as the input for the next round (k),
etc...)
- A combination of both?
Which one is the best way?
>In accepting a lower level of security, you increase the number of
>collisions. What constitutes a break would not necessarily follow. The
>only thing that you can ask is whether the algorithms involved met your
>level of desired security. Short keys are otherwise called dumb keys for
>good reason.
Thanks to all for your help.
To be or not to be. -- Shakespeare
To do is to be. -- Nietzsche
To be is to do. -- Sartre
Do be do be do. -- Sinatra ;-D
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Why would a hacker reveal that he has broken a code?
Date: Thu, 27 May 1999 14:19:00 GMT
Wesley Horton <[EMAIL PROTECTED]> wrote, in part:
>Just as a matter of question, roughly how long would it take a new 550
>mhz Pentium to do an exhaustive key search on single DES?
Way too long. Hundreds of years? Perhaps a bit less. (But a $250,000
customized system can do it in weeks, as was recently proven.)
>Also, isn't it fair to say (as an aside) that a system such as the
>SIGABA, with new rotor sets which were used only once (for the message
>enciphered) would be secure as a matter of principal?
Yes, that is likely to be a secure system as well. I suppose if you
use a poor PRNG to generate the rotor sets, there might be *some* kind
of an attack in theory, but not one that anyone could ever use.
I'm not trying to say that everything must be insecure, although I
acknowledge the validity of Terry Ritter's point on the other hand:
even when a cipher _is_ secure, it's very hard to *prove* that it is,
since somebody could have an analytic method of attack of a kind that
we hadn't even begun to think of.
It's sort of like trying to predict what mathematicians will discover
next year.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: non-computerized cryptography
Date: Thu, 27 May 1999 14:12:57 GMT
[EMAIL PROTECTED] (David Eppstein) wrote, in part:
>Schneier's Solitaire (http://www.counterpane.com/solitaire.html) doesn't
>count?
I had forgotten that particular example; I was thinking of the general
situation. Anyhow, other respondents mentioned it.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
** 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
******************************
