Cryptography-Digest Digest #423, Volume #12 Sat, 12 Aug 00 01:13:01 EDT
Contents:
Re: Best AES candidates ?? ("Douglas A. Gwyn")
Re: 1-time pad is not secure... (JPeschel)
Re: idear for new cipher (tomstd)
Re: Random Number Generator (Frank M. Siegert)
Preserving confidentiality while linking data? ([EMAIL PROTECTED])
Re: chap authentication scheme? (Thomas Wu)
Re: New William Friedman Crypto Patent (filed in 1933) (John Savard)
Re: obtaining RSA intemediate variables (Wei Dai)
Re: OTP using BBS generator? (Benjamin Goldberg)
Re: OTP using BBS generator? (Benjamin Goldberg)
Re: Not really random numbers (Benjamin Goldberg)
Re: Huge S-boxes! ("Scott Fluhrer")
Re: Random Number Generator ("Scott Fluhrer")
Re: PKCS#7 ("Tomas Rosa")
Re: chap authentication scheme? (Cryptocol)
Re: Random Number Generator ("Scott Fluhrer")
Re: Pentium III h/w RNG (Mack)
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Best AES candidates ??
Date: Fri, 11 Aug 2000 22:09:36 -0400
Roger Schlafly wrote:
> Here is what NIST said in the original announcement.
> It is intended that the AES will specify an unclassified, publicly
> disclosed encryption algorithm available royalty-free worldwide...
Indeed, the original stated goal was for a single algorithm,
and I suspect that had it been different, some of the entrants
might not have entered (which meant surrendering property rights).
It was only after no clear winner emerged that we heard talk
about perhaps adopting multiple algorithms. I *hope* NIST
sticks to the originally stated intent.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Date: 12 Aug 2000 02:14:33 GMT
Subject: Re: 1-time pad is not secure...
Douglas A. Gwyn [EMAIL PROTECTED] writes:
>Guy Macon wrote:
>> So why haven't you published it yourself on the Internet?
>
>I haven't had time to set up a Web site. Whenever I get
>a round tuit, that will be one of the things I'll include.
How many wags so far have sent you one of your very
own? :-)
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
Subject: Re: idear for new cipher
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 11 Aug 2000 19:21:41 -0700
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>tomstd wrote:
>> Try doing a few million 1024 bit adds per second and tell me
>> bignum libs are practical.
>
>They're not only practical, they're used all over the place.
Not to mention the codesize bloat...
Tom
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: [EMAIL PROTECTED] (Frank M. Siegert)
Subject: Re: Random Number Generator
Date: Sat, 12 Aug 2000 02:32:30 GMT
On Thu, 10 Aug 2000 16:49:11 -0600, Jerry Coffin <[EMAIL PROTECTED]>
wrote:
>You PRNG fails some of the FIPS 140-2 tests fairly regularly. It
>fails quite a few of the DieHard tests very consistently. Your PRNG
>is clearly NOT suitable for cryptographic use.
Ok, so I tried the diehard tests on my algorithm
(http://www.this.net/~frank/stepfive.c) - it passed them all ok as far
as I can judge from the p values distribution I got [0-1, evenly
distributed]. Also Ueli M Maurer's "Universal Statistical Test for
Random Bit Generators" worked out ok. Some trival tests (Mean,
Distribution, Tripples, Monte Carlo Pi) are part of the test code of
the implmentation and also worked out fine.
Where can I find an implementation of the FIPS 140-2 test? Is there a
way to prove some cryptographic quality of a random number generator
(except for breaking it of course, I tried this too)?
Thanks
Frank
------------------------------
From: [EMAIL PROTECTED]
Subject: Preserving confidentiality while linking data?
Date: Sat, 12 Aug 2000 02:38:02 GMT
Looking for methods to reliably link unit record personal information
in large administrative data sets without the identity of the people
being accessible to those using the linked data.
The proposed approach is for the custodians of each data set to
standardise the name, address and birthdate information according to
an agreed protocol and then apply a standard one way hash to generate
a unique id string. This id string then replaces the identifying
information and the resulting de-identified unit record data can be
linked with other similarly treated datasets for analysis.
The basis of the approach is that by standardising the format of the
input data and using a standard hash, then each custodian will
generate the same hash value given the same input data. To avoid
simple reverse lookups of has values to input identity an additional
step is proposed.
A third party would take each dataset with hashed id and link the
records using the hash values, then strip the hash values and assign a
random number id before making the linked data available for analysis
back to both the data custodians and other researchers.
There remains the problem that if the patterns of values in the fields
of a record in one data set are sufficiently unique, that a data
custodian will be able to use that pattern to match a lined record
back to the identifying information in their own data set and so link
an identity with the data from another custodian's recordset. Apart
from deliberately scrambling the data values (and so making the linked
data valueless for analysis) it is not clear how this can be avoided
other than by controls on the practices of data custodians such as
separating within data custodians systems the storage of identifying
data and the balance of data.
The biggest source of failed linkages (ie no linkages even though the
records are for the same person) or spurious linkages (linkages of
records where they are actually for different people) will be problems
with the address information - classic issues such as surnames
changing with marriage, or different spellings. In this context the
level of collisions in the hash (ie the same hash being produced from
different inputs) is less likely to be an issue. Nevertheless it is
worth minimising all sources of error, so a hash algorithm with
minimal collisions is preferred. This should be seen in the context of
records covering several million people. In the interests of economies
of data handling, it is is also preferable to have a unique hash
output that is as short as feasible.
Can someone pls offer views as to the most approporiate has
algorithms?
Any other comments on the scheme also welcome.
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: chap authentication scheme?
Date: 11 Aug 2000 19:40:08 -0700
[EMAIL PROTECTED] (Cryptocol) writes:
> communication cost too. By the way, the above protocol, so-called A-CHAP, is
> not secure at all. I already posted it in the morning. Yesterday, I just
> proposed it abruptly for Mr. Unruh who was struggling against the restricted
> environment but I think it was not a good proposal. A-CHAP is totally useless
> if BOB is not really BOB. Morevoer, it makes salt useless. I just thought that
> making a secure password protocol using two messages is just similar to making
> a safe car using two wheels. :) Can we do it? ;)
I think it's provably impossible. If you allow only one server challenge
and one client response message, and you assume that the server in the
first message doesn't know the identity of the user, the server can't
make the first message a function of some user-specific secret. A
fake server can always issue a legitimate first challenge and then
dictionary-attack the response from the client.
I'm not sure we gain much by operating within this arbitrary and
fundamentally limited authentication model. Allow at least an
initial message from the client, and that opens up the door for
secure protocols like SRP and its functional equivalents.
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: New William Friedman Crypto Patent (filed in 1933)
Date: Sat, 12 Aug 2000 03:23:20 GMT
On Fri, 11 Aug 2000 14:28:42 +0200, "Bjarne Carlsen"
<[EMAIL PROTECTED]> wrote, in part:
>seven is not a magic number ;-)
Of course not. The magic numbers are 2, 8, 20, 28, 50, 82, and 126. :)
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Wei Dai <[EMAIL PROTECTED]>
Subject: Re: obtaining RSA intemediate variables
Date: Fri, 11 Aug 2000 20:30:09 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> Hi,
>
> I've written an RSA implementation using Montgomery's exponentiation method,
> and it works (woo-hoo). However, I'm now looking to make the design
> smaller - especially with regard to obtaining the intermediate variables
> required for the montgomery technique. I would like to know if there is
> another way of finding the inverse of m mod R (the orignal modulus, modulo
> the new modulus). I am currently using Euclids extended algorithm. Is there
> another way?
There is an exercise in Knuth's Seminumerical Algorithms about
computing inverses mod a power of 2. The answer is, if you have u = 1/v
mod 2^e, you can compute 1/v mod 2^2e as (2u-vu^2) mod 2^2e. This gives
you a fast and simple recursive algorithm, and you can start with v =
1/v mod 2^3 (for any odd v).
--
cryptopp.com - a free C++ class library of cryptographic schemes
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Sat, 12 Aug 2000 03:54:43 GMT
lcs Mixmaster Remailer wrote:
>
> Benjamin Goldberg writes:
> > With BBS, short cycles occur with low probability, and the system is
> > very secure when we don't have a short cycle. There's no known way
> > to detect weather short cycles will occur without explicit testing,
> > but explicit testing is trivial. If a short cycle does occur, the
> > system is wide open.
>
> The same reasoning applies to accidentally choosing easy-to-guess
> primes. What if you are so unlucky as to choose a prime which exactly
> matches the ASCII representation of a Shakespeare sonnet? Or what if
> it turns out to be one more than a power of two? Or what if p/q
> happens to be very close to a simple rational fraction?
That's entirely different. What your describing is like saying "Suppose
I search for my primes by testing each N bit number up to sqrt(pq), in
random order, for being one of the primes, and BY RANDOM CHANCE, I
happen to get it as my guess". If PQ has some property such as you
describe, it would be non-trivial [*very* difficult] to discover that it
is so.
I'm saying, you've picked some PQ, and some X[0]. The X[i] values go
through a short cycle and repeat. Perhaps the cycle length is 1, and
the keystream is then either all 0's or all 1's. If this has occured,
there is 100% chance of it being noticable.
> The point is, if any of these things happen, the rsa modulus is easy
> to factor, with a proper program. But the chances of any of them
> happening are infinitisimal. And the same is true with choosing a
> seed that leads to a short cycle.
Erm. "What if you are so unlucky as to choose a prime which exactly
matches the ASCII representation of a Shakespeare sonnet?" Sure, I
suppose that it would be easy to find a program that tests for that
specific modulus, and that program would of course already have the
factors. It's a bit like saying, I've generated X many private
key/public key pairs, and I want to try factor person Z's public key by
testing if it's in my list. "Or what if it turns out to be one more
than a power of two?" Supposing PQ is N bits long, you've the same
likelyhood of P or Q happening to be 2^N+1, as you have of finding PQ on
a list of N known products of pairs of big primes. "Or what if p/q
happens to be very close to a simple rational fraction?" I don't see
how this would help us factor PQ.
> Don't forget: if *you* could find a short-cycle seed, so could someone
> else. And if he can, he can break your RSA modulus, and all bets are
> off. If you truly think short cycles are a problem, you should
> conclude that RSA is not safe.
Bzzt! No, BBS is not quite the same as RSA.
Here's a BBS example of a short cycle: P is 23, Q is 47, X[0] is 46.
X[i+1]=X[i]^2%PQ The short cycle that occurs is that for X[1] onward,
the value is 1035. This means [assuming we use the lowest bit] that the
keystream is all 1's, and the plaintext message can be seen by XORing 1
with every bit. HE'S FOUND THE MESSAGE!
Now suppose we're using RSA, with some P and Q and message M and
encryption exponent E with the same properties as the BBS example: that
means X[0]=M, X[i+1]=X[i]^E%(PQ) and we've somehow got a message that
degenerates into a short cycle: all X[i] where i>=1 are the same as
X[1]. We've encrypted M, which mean's we've got (and sent) X[1]. Our
opponent might learn that X[2] and X[3] and X[4], etc happen to all be
the same as X[1], but that tells him nothing about X[0]. HE DOESN'T
HAVE THE MESSAGE!
See the difference? Opponent has message vs. opponent doesn't have
message. Simple.
--
Galibrath's Law of Human Nature: "Faced with the choice between changing
one's mind and proving that there is no need to do so, almost everybody
gets busy on the proof."-Vejita/Joel on #afd
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Sat, 12 Aug 2000 03:54:47 GMT
Mok-Kong Shen wrote:
[snip]
> I have just do an example with p=11, q=19, n=209. There is
> a cycle of length 4: (38, 190, 152, 114). Taking the LSB,
> we have all 0's. Isn't this extremely predictable? Would
> some experts please comment on this? Many thanks in advance.
Your q isn't a Blum Integer, I don't think.
--
Galibrath's Law of Human Nature: "Faced with the choice between changing
one's mind and proving that there is no need to do so, almost everybody
gets busy on the proof."-Vejita/Joel on #afd
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Not really random numbers
Date: Sat, 12 Aug 2000 03:54:51 GMT
Joseph Ashwood wrote:
>
> Depending on your speed requirements, what kind of proofs
> you need/want. Your choices are quite large. Just to name a
> few:
> ARC4
> ISAAC
> Mersenne Twister
> BBS
> Or you could grab a copy of the DIEHARD source code which
> includes code for a dozen or so algorithms for testing
> purposes.
The problem with these is that there will be collisions in
the output. He needs it so no number occurs more than once.
> You could also use a block cipher in counter mode
> (given a key K, and a location in sequence N, value =
> Encrypt(K, N)), this has the added help of not repeating
> until you've exhausted all N (by invertability), so that
> should give you an extra several thousand possibilities.
Now this is probably what is needed.
--
Galibrath's Law of Human Nature: "Faced with the choice between changing
one's mind and proving that there is no need to do so, almost everybody
gets busy on the proof."-Vejita/Joel on #afd
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Huge S-boxes!
Date: Fri, 11 Aug 2000 20:52:43 -0700
Simon Johnson <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> This is really two questions in one:
You know, we charge twice as much for two questions...
>
> 1. If we pick a random number, N, then pick a random prime, P,
> such that it is less than N. We then iterate F(X) from 0 to 0.95N
> where F(X) = (X^p) mod N. Can we derive the remaining 5% mapping
> without doing the expodentation.
Yes. By using the formula (assuming the "random prime" isn't two, and is
hence odd)
F(N-X) = ((N-X)^p) mod N = -(X^p) mod N = N-F(X) mod N
The P=2 is even simpler -- F(N-X)=F(X).
And so, as long as you have the values of F(X) for X from 0 to 0.5N,
computing the rest of the values is trivial
--
poncho
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Random Number Generator
Date: Fri, 11 Aug 2000 20:56:36 -0700
Joseph Ashwood <[EMAIL PROTECTED]> wrote in message
news:upwZiG8AAHA.565@cpmsnbbsa08...
> > If only one bit of key/seed is changed this produces
> > 57% changed bits in random sequence.
> > Please test algorithm and all it's properties.
> And you tested this on your "infinite" sequence how?
>
>
> > > >- The probability to find in random sequence 0/1
> > > > value bits is exactly 50%
> > >
> > > Gosh really?
> > >
> >
> > Yes!Gosh.
> And you measured this how? You're dealing with infinite sequence that you
> are pretending are completely random.
Actually, he does it by construction. The algorithm outputs 256 bit blocks.
Each 256 bit block consists of precisely 128 zeros and 128 ones.
As others have noted, this is not a really desirable property in something
that's supposed to look like a random sequence...
--
poncho
------------------------------
From: "Tomas Rosa" <[EMAIL PROTECTED]>
Subject: Re: PKCS#7
Date: Fri, 11 Aug 2000 15:13:20 +0200
"Kevin Crosbie" <[EMAIL PROTECTED]> wrote in message
news:8muqmu$[EMAIL PROTECTED]...
> Yeah that looks cool. That will do what I want. Thanks.
>
> Does anyone know if the WinAPI or CryptoAPI can do PKCS#7 encoding
directly
> rather than using outside source code.
>
WinAPI wont help - CryptoAPI is the place for crypto in M$ products.
It could be used for encoding/decoding of PKCS#7 messages, but it takes some
time to make these "user friendly" functions do what you want to do. Some
APIs also expect that you will use the CSP modules for performing basic
crypto operations (signing, etc.).
Anaway, by using CryptoAPI you have a chance to use all the nice certificate
managing properties of IE.
Tom
------------------------------
From: [EMAIL PROTECTED] (Cryptocol)
Subject: Re: chap authentication scheme?
Date: 12 Aug 2000 04:28:07 GMT
Tom Wu wrote:
>[EMAIL PROTECTED] (Cryptocol) writes:
>> communication cost too. By the way, the above protocol, so-called A-CHAP, is
>> not secure at all. I already posted it in the morning. Yesterday, I just
>> proposed it abruptly for Mr. Unruh who was struggling against the restricted
>> environment but I think it was not a good proposal. A-CHAP is totally
useless
>> if BOB is not really BOB. Morevoer, it makes salt useless. I just thought
that
>> making a secure password protocol using two messages is just similar to
making
>> a safe car using two wheels. :) Can we do it? ;)
>
>I think it's provably impossible. If you allow only one server challenge
>and one client response message, and you assume that the server in the
>first message doesn't know the identity of the user, the server can't
>make the first message a function of some user-specific secret. A
>fake server can always issue a legitimate first challenge and then
>dictionary-attack the response from the client.
>
>I'm not sure we gain much by operating within this arbitrary and
>fundamentally limited authentication model. Allow at least an
>initial message from the client, and that opens up the door for
>secure protocols like SRP and its functional equivalents.
Right, that's what I am saying. :) I mentioned A-CHAP also fails unless there
is such a unreasonable assumption that Bob should be always Bob, not Bap(fake
Bob). So I said, "Making a secure password protocol using two messages is just
similar to Making a safe car using two wheels." That means, I also thought it
was impossible in a reasonable way. ;) sorry for confusing the matter.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Random Number Generator
Date: Fri, 11 Aug 2000 21:19:42 -0700
<[EMAIL PROTECTED]> wrote in message news:8n0aae$3fv$[EMAIL PROTECTED]...
> In article <8mviek$ki1$[EMAIL PROTECTED]>,
> "Scott Fluhrer" <[EMAIL PROTECTED]> wrote:
> >
> > <[EMAIL PROTECTED]> wrote in message
> news:8mtu40$9ck$[EMAIL PROTECTED]...
> > > Alex Random Number Generator
> > >
> > > The objective of this algorithm is to map finite
> > > key/seed to an infinite sequence of random bytes.
> > > The implementation has following characteristics:
> > >
> > > - 16 byte Key/Seed
> > > - 57% Avalanche Effect
> > > - 760Kbyte/sec performance
> > > - 64 Kbyte generated random string shows Null ZIP
> > > compression
> > > - The probability to find in random sequence 0/1
> > > value bits is exactly 50%
> >
> > I looked at the algorithm, and it's dreadful. It basicly works by
> having 32
> > bytes of internal states, and going through these steps:
> >
> > - An "arithmetic operation" that replaces various bytes within the
> state
> > with sums and products of the original values (mod 256). I suspect
> this may
> > be weak, but it is not the source of the problem.
> >
> > - A "reflection operation", which throws away half the state, and
> replaces
> > it with the complement of the other half.
> >
> > - A "permutation operation", which does a fixed permutation on the
> bits of
> > the state.
> >
> > - At this point, you output all of the state as a 32 byte block
> >
> > Obvious problems:
> >
> > - This is not a CSRNG. Since there is no hidden state and no key
> dependance
> > on the operation, the second 32 byte block is a publicly computable
> function
> > of the first 32 byte block.
>
> It is absolutely wrong statement.
>
> Arithmetic operations with lose of overflow bit by addition and overflow
> byte by multiplication implement one way function. It is impossible to
> calculate previous state from current one. Third randomness factor means
> that during consequently interpretation of words some of them may be
> already modified by previous steps and probably not only one time.
> Got knows how you can calculate previous state from the current one.
If you look real closely at my claim, I don't talk about computing the
previous state from the current one (which would be somewhat difficult). I
talk about computing the next state from the current one. Your argument in
no way answers my claim.
Although, computing a potential previous state (there's likely to be many of
them) doesn't sound that difficult -- the permutation step is trivially
inverted and the inverse of the reflection step leaves lots of bits that the
attacker can choose as convienent. Then, the last step is inverting the
arithmetic operation, and by chosing the free bits (from the reflection
step) carefully, I imagine you could come up with a preimage without too
much backtracking...
>
>
> >
> > - The reflection operation enforces that exactly 128 bits of the block
> is 0
> > and 128 bits is 1. The permutation operation does not change this.
> This
> > means that each 32 byte block will have exactly 128 0's and 128 1's.
> > Obviously, real random sequences don't do this.
> >
> > - Even worse, since the permutation operation is fixed, any linear
> > relationships generated by the reflection operation will appear at
> > predictable places in the output. For example, immediately after the
> > reflection operation, bit 0 of byte 0 is the complement of bit 0 of
> byte 1.
> > The permutation operation moves bit 0 of byte 0 to bit 5 of byte 5,
> and bit
> > 0 of byte 1 to bit 3 of byte 12 (decimal). And so, in each block of
> the
> > output, bit 5 of byte 5 will always be the complement of bit 3 of byte
> 12 --
> > know one and you immediately know the other.
> >
> > Other comments:
> >
> > - The documentation of the algorithm was hideous (in no way could you
> > reconstruct the algorithm from that), and the only detailed
> description was
> > the source, which was mostly x86 assembly. This is ridiculous.
> >
>
> Let me ask you how can man implement permutation of bits not using
> Assembler?
Ummm, C? Pascal? Fortran? Cobol? AWK? Perl? APL? It's hard to think
of a turing-complete language that fundementally would be unable to handle
it...
>
> > - If I wasn't worried about the above weakness, another thing I would
> worry
> > about is that the above operation throws away a *lot* of entropy. The
> > reflection operation itself throws away 128 bits each iteration, and
> the
> > arithmetic operation may throw away a considerable amount itself.
> >
> > --
> > poncho
>
> There are no weakness and holes in this algorithm.
Wow, that's a broad statement. Especially since you did not disagree with
my contention that bits in the output have fixed relationships (which makes
distinguishability from randomness trivial). Especially since others have
since verified that it fails Diehard.
In any case, exactly what claims are you making for this algorithm? That it
is computationally indistinguishable from a random oracle? That it is an
acceptable random number generator (apart from any cryptographical
requirements)? That it does produce lots and lots of bytes?
>
> It is absolutely new idea how to map key to infinite sequence of random
> bytes.
> Let you time to understand this.
Well, it certainly is a way to map a key to an infinite sequence of bytes.
It's the "random" part people have a problem with. To quote von Neumann,
"Anyone who considers arithmetical methods of producing random digits is, of
course, in a state of sin".
--
poncho
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Pentium III h/w RNG
Date: 12 Aug 2000 04:53:08 GMT
>Joseph Ashwood wrote:
>
>> I think we all kind of gave up when it was discovered that if it wasn't
>> present the motherboard gave back random garbage. Actually some analysis
>was
>> done, but the only stuff I'm aware of was funded by Intel.
>
>I question the use of the term "random garbage". Either the motherboard
>works
>to spec without the chip installed or the garbage is predictable.
>
>;-)
>
>
>
Two other possibilities come to mind.
1) It works to spec some of the time
2) It returns correlated random output.
Ie. it is patterned but not totally so.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
** 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
******************************
