Cryptography-Digest Digest #45, Volume #14 Fri, 30 Mar 01 14:13:00 EST
Contents:
SUPER RIJNDAEL BIJECTIVE CHARACTER ENCRYPTION (SCOTT19U.ZIP_GUY)
Re: Idea - (LONG) (Mok-Kong Shen)
Re: Malicious Javascript in Brent Kohler post (was: Re: Who is Brent K (Mok-Kong
Shen)
Re: SUPER RIJNDAEL BIJECTIVE CHARACTER ENCRYPTION (SCOTT19U.ZIP_GUY)
Re: Support for 1536 bit RSA keys? ("Sam Simpson")
Re: Diceware Passwords (Benjamin Goldberg)
Re: diffie hellman (Brian D Jonas)
Re: discrete log question (Mike Rosing)
Re: diffie hellman ("Henrick Hellstr�m")
Re: Malicious Javascript in Brent Kohler post (was: Re: Who is Brent K Kohler?)
(Benjamin Goldberg)
Re: public key problem (Benjamin Goldberg)
Re: Estimation of the keygen time (Benjamin Goldberg)
Re: Passthru uses to code VB code (Anonymous)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: SUPER RIJNDAEL BIJECTIVE CHARACTER ENCRYPTION
Date: 30 Mar 2001 16:53:20 GMT
Hope below cuts and pastes OK
But I think I have the first fully bijective rijndael
cypto system that allows one to fully map in a bijective
way from a set of any length files from one symbol type
those in cond1x.da to a set of files of another set of
symbols in the file cond2x.das. Any file of symbols
along with any 40bit authentication ID maps uniquely
to another file of symbols in a completely bijective
way. The compressions used are also completely bijective
there are many trnsformation programs in the batch file
such as mapping to and from FOF files and normal binary
files. This was needed to match the various programs.
AS always this should be in a directory on a PC my itself
as batch files do delete certain files. No attempt was made
to srcub file after use. It is just a deminstration of how
correctly used rijndael and bijective compression can go
with the use of authenication in it.
cut the following lines between the "{}" and use
the fully bijective rijndael procedure that is at
my site you still need to get matt's bicom since
it is used in the bat file. this message has a
40 bit authenticaion with it. it uses words
"dog" for authentication password and
"cat" as main password just like samples
found at http://members.nbci.com/ecil/rijnbest.zip
{
OJEGWHAGHKIS__CV_CETVAHSRDDN__I_FJGGWSDSM_MN_FURXINLY
SFOMBGLPF_SG_IFJMABBOSVIDXDVFRWWHFFXICA_ATYGAMJ_IBN
PQX_MCEYTNSFADRJI_DONTC_DHUV_ASSFCNPA_NYDQIUERNWMSAFJPSG
OTRAAEEGOSREROADDLITCYLAAILNBYHWEXWNNBSJNLE
ERXDEDUDWQKC_DOIYNDR_CTLSIBHX_RYUTIIVVVKHB
ZVASUYLB__DIJHJUTMJMLEOBQJPHLTRLNTK
NSSZPGPADSIKVP_HOPNLJG_PWCYPIIHUV_DSIMQIDF
FSIRCF_G_XZQWAOPDEIOQDVGTSINOEVTSNOP_KRLDDA
JIZIYAASD_K_YUEWAJV_ZDQYROUSHLV_SVRA_EBRLHIVIZY
TJRFIXOBRWH_AJHRUHVOCAXSTNSKI
}
nice message is it not.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.nbci.com/ecil/index.htm
Scott LATEST UPDATED sources for scott*u.zip
http://radiusnet.net/crypto/archive/scott/
Scott famous Compression Page
http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
A final thought from President Bill: "The road to tyranny,
we must never forget, begins with the destruction of the truth."
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Idea - (LONG)
Date: Fri, 30 Mar 2001 18:52:00 +0200
"John A. Malley" wrote:
>
[snip]
> Can we construct a block cipher with perfect secrecy by cascading
> substitution and transposition "units" in some sequence? Or with a
> Feistel cipher? Will the resulting algorithm yield that particular set
> of permutation mappings such that each message is mapped to each
> cryptogram in just one of the maps (and thus by just one of the possible
> keys.)
>
> If this cannot be done with a product cipher or Feistel cipher then we
> (possibly) establish some fundamental limits on the achievable secrecy
> of a block cipher algorithm.
You are raising a question of 'existence'. So, according to
general practice in mathematics, one is allowed to employ
'degenerate' cases, i.e. contrived ones that are so special
that they don't have much practical utility but are
nevertheless useful for the purpose of proof. You said
concatenation of substitution and tranposition. I use an
'identity' transposition, i.e. without moving any element
at all. O.k.? That means I am left to construct a suitable
substitution for the desired block cipher. Now I have
a key of n bits and a block length of n bits. I define
my substitution to be
output = input xor key
Isn't that a bijective substitution of a block of n bits?
Obviously yes. Thus I have succeeded to demonstrate that
at least one block cipher exists that has the same
perfect security as meant by Shannon (because it is
trivially doing exactly the same as the OTP). Now let perm
be any (fixed) permutation (trasposition) of n bits. Then
output = perm(input xor key)
similarly defines a block cipher that is perfectly secure.
This shows that there are more than one such block cipher
based on substitution and transposition that satisfy
what you want. I haven't considered Feistel construction
in the present context. But I think it is well possible
to come up with (contrived/special) cases that can serve
to prove the existence issue.
M. K. Shen
=======================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Malicious Javascript in Brent Kohler post (was: Re: Who is Brent K
Date: Fri, 30 Mar 2001 19:08:07 +0200
"-[tCs]-" wrote:
>
>
> How often would you use scripted mathematical formulae in news group
> postings? Creating a web page and linking to it would probably be a
> more useful solution.
It depends. If one discusses religion, one would probably
never need that. If one discusses math, then being able
to express complicated math can be useful. Certainly
posting a link will do. One could also post any stuff
to a group just with a link, without any other words,
isn't it? (Though one is likely to be flamed thereby.)
Note I was addressing the point 'never been able to find'
of OP (i.e. never vs. sometimes).
M. K. Shen
=======================
P.S. I have deleted the other groups that you cross-posted.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: SUPER RIJNDAEL BIJECTIVE CHARACTER ENCRYPTION
Date: 30 Mar 2001 17:03:03 GMT
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote in
<[EMAIL PROTECTED]>:
In case one is wondering I did use cut and paste
to note pad then saved to a file. It worked great
so all can read the message.
>
>cut the following lines between the "{}" and use
>the fully bijective rijndael procedure that is at
>my site you still need to get matt's bicom since
>it is used in the bat file. this message has a
>40 bit authenticaion with it. it uses words
>"dog" for authentication password and
>"cat" as main password just like samples
>found at http://members.nbci.com/ecil/rijnbest.zip
>{
>OJEGWHAGHKIS__CV_CETVAHSRDDN__I_FJGGWSDSM_MN_FURXINLY
>SFOMBGLPF_SG_IFJMABBOSVIDXDVFRWWHFFXICA_ATYGAMJ_IBN
>PQX_MCEYTNSFADRJI_DONTC_DHUV_ASSFCNPA_NYDQIUERNWMSAFJPSG
>OTRAAEEGOSREROADDLITCYLAAILNBYHWEXWNNBSJNLE
>ERXDEDUDWQKC_DOIYNDR_CTLSIBHX_RYUTIIVVVKHB
>ZVASUYLB__DIJHJUTMJMLEOBQJPHLTRLNTK
>NSSZPGPADSIKVP_HOPNLJG_PWCYPIIHUV_DSIMQIDF
>FSIRCF_G_XZQWAOPDEIOQDVGTSINOEVTSNOP_KRLDDA
>JIZIYAASD_K_YUEWAJV_ZDQYROUSHLV_SVRA_EBRLHIVIZY
>TJRFIXOBRWH_AJHRUHVOCAXSTNSKI
>}
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.nbci.com/ecil/index.htm
Scott LATEST UPDATED sources for scott*u.zip
http://radiusnet.net/crypto/archive/scott/
Scott famous Compression Page
http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
A final thought from President Bill: "The road to tyranny,
we must never forget, begins with the destruction of the truth."
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: Support for 1536 bit RSA keys?
Date: Fri, 30 Mar 2001 18:22:06 +0100
<[EMAIL PROTECTED]> wrote in message
news:tG0x6.1607$[EMAIL PROTECTED]...
> >ok, well I think we've both made our arguments, what do you think Texica?
;)
>
> That the whole discussion was irrelevant :-)
LOL.....Still, it's been interesting, as always ;)
> The application I am considering requires strong security guarantees that
> 1024-bit RSA keys cannot provide.
>
> See the following two papers on this subject if you remain unconvinced:
> * Selecting Cryptographic Sizes, by Lenstra and Verheul (9/1999)
> <http://www.cryptosavvy.com/Joc.pdf>
> * A Cost-Based Security Analysis of Symmetric and Asymmetric Key Lengths,
> by R. Silverman (4/2000)
<ftp://ftp.rsasecurity.com/pub/pdfs/bulletn13.pdf>)
>
> The application I am considering also has strong constraints on
performance.
> That is why we want to avoid 2048-bit keys. However if there is no vendor
> support for 1536-bit keys then we will have to go for 2048-bit keys.
According to the citations you provide, 1536-bits will not give you security
for 20 years!
--
Regards,
Sam
http://www.scramdisk.clara.net/
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Diceware Passwords
Date: Fri, 30 Mar 2001 17:46:43 GMT
Marc wrote:
>
> >>Some words on the list have only 1-3 letters, for example "s".
> >>Isn't the entropy added by "s" less than 12.9 bits? An attacker who
> >>does not follow the Diceware scheme but attacks from another angle
> >>(eg brute force) sees the "s" as one letter of 26, not 7776.
>
> >Diceware works on the principle that the words are just a convenient
> >mnemonic device for human beings -- the actual randomness comes from
> >the dice. The word-list gives us a convenient mapping between those
> >numbers and something we can remember.
>
> Thanks for your answer.
>
> Yes, I do understand why the words are _supposed_ to give 12.9 bits
> of entropy (because they are chosen among 7776). However, if the
> mnemonic in itself is easier to guess than its position in the list,
> the attacker might just ignore the passphrase history and attack it
> like tradidional passphrases.
The problem is that the traditional method of attacking passphrases is
to try all possible passphrases /in order of likelyhood/. An attacker
can almost always assume that the passphrase is ascii text, but
knowledge of the length is different. If for example the attacker knows
it's exactly 8 letters, attacking by intelligent brute force is easy.
But what if the length is unknown? Now it becomes much much harder.
> Imagine that the words on the list have 8 bits of entropy on average,
> viewed under the established common opinion that english words have
> only 1-2 bits per letter and that the list is compiled from short
> english words.
1-2 bits per letter is based on ordinary english text with >100 letters
of context. Letters in a password are often assumed to have about 3
bits of entropy. Assuming your estimate was based on 2 bits per letter,
then 8/2*3 = 12 bits per word. Either estimate, however, is based on
human's inability to pick strings that are both random and memorizable.
If dice are used for randomness, then the estimate of entropy is likely
to be higher.
> When I now build a 5 word passphrase from them, I get 5*8 = 40 bits
> of entropy. An attacker, performing a 2**40 "english ascii"
> bruteforce, will find my passphrase. He simply skips the more complex
> 2**64.5 "diceware" bruteforce in favor of the simpler one.
I get 2^60 work, not 2^40. Interestingly enough, when people are
generating a diceware passphrase, they will often discard difficult to
remember phrases until the method comes up with something 'easy' to
memorize. If one discards 15/16 as being too hard to remember, then
entropy is reduced from 64.5 to about 60.5.
> The Diceware FAQ recommends to discard passphrases <14 letters in
> length, which seems to strengthen my point. Some words are just
> weaker than others, and their common property is "being short". Too
> many weak words, and you better generate another phrase..
It's not that the words are weak, it's the passphrase as a whole.
/If the attacker knows the length of the passphrase/, it's quite a bit
weaker than 2**64.
Suppose that, offline, the attacker creates lists of all the possible
diceware passphrases, one list per length. Suppose that the attacker
learns that the passphrase is less than 14 letters. The number of all
passphrases <14 letters is very small -- he's eliminated well over half
of the search space, or AT LEAST one bit of entropy, probably much much
more (maybe 10 or 20 bits).
Actually, regardless of what the length is, the enemy learning it allows
him to significantly narrow his search space, but the if enemy learns
that the passphrase is, eg, 25 letters, this might eliminate 5 bits of
the search space (that's just a guess, don't take my word for it)... How
many bits are eliminated by the enemy's learning the length is not a
fixed value, but a curve dependent on the length.
If you want to know how much (ie, real numbers), then what you do is
calculate how many 5 word passphrases there are of each length, and draw
a chart relating length to the log2 of the number in each group. Then
turn your graph upside down, so larger values are lower... The higher on
the page (the smaller there are in that group), the more entropy will be
lost /if the enemy knows the length/. Suppose there's only one
*longest* diceware passphrase: the longest word repeated 5 times.
Suppose the length of that passphrase is is 60 letters. Then if the
enemy learns that the passphrase is exactly 60 letters, then the amount
of entropy is down to 0 bits, ie, he knows the passphrase. If he knows
the passphrase is >=59 letters, then maybe there's only 8 bits of
entropy (about 256 phrases which are 59 or 60 letters). /If he knows
that the length of the passphrase is 40 letters/, then the amount of
entropy in the passphrase is the log2 of the number of 40 letter
passphrases.
> I have the impression that the inventors think there are enough high
> entropy words on the list to compensate for the weaker words, and
> anyway if a passphrase has 50 bits already who cares if the 5th word
> adds 3 or 5 or 12.9 bits?
This isn't valid. Each word adds the same amount of entropy, but there
is still a chance (a high chance) that he might somehow learn how many
latters there are -- and *this* is what can make some passphrases
weaker.
> The diceware system IMHO can only guarantee the entropy if I were to
> enter the dice'd _numbers_ instead of the mnemonics (eg by looking
> up the numbers in a printout that I keep next to the computer).
Yes. Because all the lengths are fixed, and therefor there's zero
chance of the enemy learning the length.
> I don't doubt that diceware phrases are stronger than most phrases
> that users come up with traditionally, but I do doubt that they
> actually provide the promised entropy of 12.9 bits per word (when
> generated with the word list provided by the Diceware web site).
Feel free to doubt.
> In my opinion each and every word on the list should have an inherent
> entropy of 12.9 bits minimum (ignoring the problems of reliably
> measuring the entropy of a word). Only this would guarantee that no
> entropy is lost in the process of converting the numbers (12.9bit) to
> words.
Any known piece of information has zero entropy. It's the ungussability
of which word is used that gives them entropy. Therefor, each word does
have 5*log2(6) bits of entropy each, as long as the enemy cannot guess
that the word is one of some particular subset of the list (eg, as long
as the enemy doesn't know the length). If the enemy guesses any
information about the word, then he is able to eliminate huge portions
of the list, and reduce the number of bits of entropy. If the enemy can
eliminate all the words but one, then it has no entropy.
> Please clarify this for me, I honestly do not know if I am wrong or
> Diceware?
--
Sometimes the journey *is* its own reward--but not when you're trying to
get to the bathroom in time.
------------------------------
From: Brian D Jonas <[EMAIL PROTECTED]>
Subject: Re: diffie hellman
Date: Fri, 30 Mar 2001 13:01:21 -0500
Ok I don't think I completely understand yet, so I will say it again..
We will call the 2 people Matt and Pete..
Matt computes a=2^P mod m
Pete computes a=2^P mod m
At that step Matt and Pete BOTH use THE SAME 448bit m and the SAME 2 (I
said 3 in previous post) because the software has them hardcoded.
P is RANDOM for EACH person, 1024bit Sophie Germain Prime.
Matt sends ONLY (a) to Pete
Pete computes k=(matts' a)^P mod m
Pete sends his (a) to Matt
Matt computes k=(petes' a)^P mod m
Matts' K and Petes' K are the same, and of the size 448bits for quick use
with the blowfish aglorithm..
1.) is this implementation ok ?
2.) Is security reduced since 2 and m are hardcoded into each copy of the
software ?
3.) Is it *stronger* for m to be of size 1024bits and then changed to
448bits through some sort of function, or is the fact that P is a 1024bit
sophie germain prime supercede the size of m?
Thank you for your feedback thus far.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: discrete log question
Date: Fri, 30 Mar 2001 12:31:56 -0600
Tom St Denis wrote:
>
> (Wow I am really on a question rampant now...)
>
> To solve a trivial discrete log (say p = 11 = 2x5 +1) is it sufficient to
> use crt? i.e
>
> Given g=7, x=3, y=g^x mod p = 2
>
> Can we not compute
>
> g^x mod 5 = y' = 2
> g^x mod 2 = y'' = 1
>
> Then solve the discrete log mod 5 and mod 2 using trial and error getting us
> (x mod 4) and (x mod 1)?
>
> ... hmm somethings missing... am I approaching this right?
Sort of. p = 3*3+2 as well. So you could find y mod 3 along the way.
When you get enough factors (r_i) such that prod(r_i) >= p you can use
the crt to solve the problem. Since 3*5 > p, you only need to find y mod 3
and y mod 5 to solve this. The trick with large p is finding the fewest
r_i the quickest :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: diffie hellman
Date: Fri, 30 Mar 2001 20:41:17 +0200
The answer to your first question is, no, your implementation is not ok. The
modulus m should be a 1024 bit prime. The exponent may be any random number
generated by a secure RNG. It may be smaller than 1024 bits.
I have already answered your second question with respect to a proper
implementation of DH.
The answer to your third question is illustrated by the formula x**y = x**(y
mod phi(z)) (mod z). Hence, there is absolutely no point whatsoever in using
an exponent that is larger than (the Euler phi function value of) the
modulus. Moreover, the exponent is usually not, need not be and should not
be a prime. It is the modulus that must be prime.
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
"Brian D Jonas" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
>
> Ok I don't think I completely understand yet, so I will say it again..
> We will call the 2 people Matt and Pete..
>
> Matt computes a=2^P mod m
> Pete computes a=2^P mod m
>
> At that step Matt and Pete BOTH use THE SAME 448bit m and the SAME 2 (I
> said 3 in previous post) because the software has them hardcoded.
> P is RANDOM for EACH person, 1024bit Sophie Germain Prime.
>
> Matt sends ONLY (a) to Pete
> Pete computes k=(matts' a)^P mod m
>
> Pete sends his (a) to Matt
>
> Matt computes k=(petes' a)^P mod m
>
>
> Matts' K and Petes' K are the same, and of the size 448bits for quick use
> with the blowfish aglorithm..
>
> 1.) is this implementation ok ?
> 2.) Is security reduced since 2 and m are hardcoded into each copy of the
> software ?
>
> 3.) Is it *stronger* for m to be of size 1024bits and then changed to
> 448bits through some sort of function, or is the fact that P is a 1024bit
> sophie germain prime supercede the size of m?
>
> Thank you for your feedback thus far.
>
>
>
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Crossposted-To: alt.drugs.pot,rec.radio.swap,rec.running,rec.sport.skating.ice.figure
Subject: Re: Malicious Javascript in Brent Kohler post (was: Re: Who is Brent K
Kohler?)
Date: Fri, 30 Mar 2001 18:42:20 GMT
-[tCs]- wrote:
>
> On Fri, 30 Mar 2001 18:09:08 +0200, Mok-Kong Shen
> <[EMAIL PROTECTED]> shed a beam of light on us:
>
> >
> >
> >I Can Help wrote:
> >>
> >[snip]
> >> Agreed - I have really never been able to find any USEFUL need for
> >> HTML (much less JavaScript) in a newsreader. They should all just
> >> block the code.
> >
> >I am not quite sure of that. If you have complicated
> >mathematical formulae, you could use HTML to advantage.
> >I haven't acquainted myself with that, it is anyway a
> >feature contained in the newer XML specifications, I
> >believe.
> >
> >M. K. Shen
>
> How often would you use scripted mathematical formulae in news group
> postings? Creating a web page and linking to it would probably be a
> more useful solution.
>
> -=Cornelis
Perhaps not scripted formulae, but lots of people stick latex math
markup in their usenet postings.
--
Sometimes the journey *is* its own reward--but not when you're trying to
get to the bathroom in time.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: public key problem
Date: Fri, 30 Mar 2001 18:48:14 GMT
Mark Currie wrote:
>
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] says...
> >
> <snip>
> >In El Gamal, a key is created by the Diffie-Hellman method, and then
> >it is used for a specific encryption operation; both parties share
> >the same key, so no one is enabled to read something he is unable to
> >write, the essential condition for signatures. Elaborate methods have
> >been used, though, to allow signature methods based on El Gamal,
> >IIRC.
> >
>
> This may be a bit picky, but I would have thought that the essential
> condition for signatures was more like: Everyone can read it, but only
> one person can write it ? Perhaps my interpretation of what you meant
> is wrong though :-)
>
> Mark
Well, close. Anyone can verify it, but only one person can create it
such that it can be verified. Sure, John Random Hacker can write a sig
and claim it's mine, but anyone can attempt to verify it and see that
it's a fake.
--
Sometimes the journey *is* its own reward--but not when you're trying to
get to the bathroom in time.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Estimation of the keygen time
Date: Fri, 30 Mar 2001 19:05:29 GMT
Bob Deblier wrote:
> Try the technique I use in the BeeCrypt crypto library: take a number
> which is the product of the first N small primes (up to your
> preference - I use a number which is equal in bitsize to the
> candidates), and compute the gcd of this number and your prime
> candidate. If the gcd is one, your candidate has passed all tests in
> one operation. That should speed up your test.
What is the break even point between your method and trial division?
Surely if we are only testing, eg, small primes 2, 3, and 5, trial
division will be faster. For what value of N is your method better than
trial division?
--
Sometimes the journey *is* its own reward--but not when you're trying to
get to the bathroom in time.
------------------------------
Date: Fri, 30 Mar 2001 21:07:33 +0200
From: Anonymous <[EMAIL PROTECTED]>
Subject: Re: Passthru uses to code VB code
Crossposted-To: soc.men,alt.security.pgp
0,672823 0,8619442 0,777918 -2001/03/25 22:08:59-
Script-Kiddie MASTER of APAS/ADRU/SM/AUK
For a 21st Century completely REMAILER-FREE
That CRAP brought to you by request from Thomas J. BOSCHLOO
[EMAIL PROTECTED]
Green uses to eat NSA
Licious used most of these gentle perl scripts
------------------------------
** 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
******************************
