Cryptography-Digest Digest #159, Volume #14 Mon, 16 Apr 01 12:13:01 EDT
Contents:
Re: Data dependent arcfour via sbox feedback
Re: Password tool! (those who know me have no need of my name)
Re: Data dependent arcfour via sbox feedback
Re: Reusing A One Time Pad ("Mark G Wolf")
Re: LFSR Security ("Scott Fluhrer")
Re: NSA is funding stegano detection ([EMAIL PROTECTED])
Re: NSA is funding stegano detection (Walter Roberson)
P1363 draft ("Full Name")
Re: Reusing A One Time Pad ([EMAIL PROTECTED])
Re: NSA is funding stegano detection ([EMAIL PROTECTED])
Re: C Encryption (Steve Portly)
----------------------------------------------------------------------------
From: <[EMAIL PROTECTED]>
Subject: Re: Data dependent arcfour via sbox feedback
Date: Mon, 16 Apr 2001 10:32:55 -0400
I tried to read this thread and related topics, but there are too many
posts for me. Does Ritter say anywhere whether or not he has tested his
broad position in court? I don't think his broad interpretation would
hold. Lets see what he does if a wealthy company like IBM (deep pockets
in the legal dept.) implements something similar to that described in
this thread.....
"Bryan Olson" <"nospam"@"nonsuch.org"> wrote in message
<7FdC6.1$D_.85@interramp>...
>Terry Ritter wrote:
>>
>>Bryan Olson wrote:
>>
>>>Terry Ritter wrote:
>>>>
>>>>On Sat, 07 Apr 2001 06:24:00 GMT, in <4oyz6.6$4G.143@interramp>, in
>>>>sci.crypt "nospam"@"nonsuch.org" ("Bryan Olson") wrote:
>>>>
>>>>>In article <[EMAIL PROTECTED]>, Terry Ritter wrote:
>>>>>>
>>>>>>On Wed, 04 Apr 2001 19:53:09 -0700, in
>>>>>><[EMAIL PROTECTED]>, in sci.crypt Bryan Olson
>>>>>><[EMAIL PROTECTED]> wrote:
>>>>>>
>>>>>>>Bryan Olson wrote:
>>>>>>>> > Terry Ritter wrote:
>>>>>>>
>>>>>>>> > >The "second data source" is modified by said "result data"
before use,
>>>>>>>> > >but no part of the claims excludes that possibility.
>>>>>>>> >
>>>>>>>> > The word "source" excludes the possibility. The sequence of
>>>>>>>> > y values is in fact a _product_ of the substitution process,
>>>>>>>> > not a source. If unclear of the interpretation of "source",
>>>>>>>> > just read the background and look at the diagrams in the
>>>>>>>> > patent.
>>>>>>>
>>>>>>>> Any sequence of data values is "a source." We can see this
>>>>>>>> throughout the patent, including: "A first data source and
>>>>>>>> a second data source are combined into a complex
>>>>>>>> intermediate form or result. . . ." Note the lack of
>>>>>>>> description about the "ultimate" origin of any data sequence
>>>>>>>> treated as a "source."
>>>>>>>
>>>>>>>It may be any sequence of values, but it must be a source,
>>>>>>>not a product. Neither does the ultimate origin matter;
>>>>>>>just that it comes in from the outside.
>>>>>>
>>>>>>The ultimate origin is of course outside *the* *combiner*, but not
>>>>>>necessarily outside the system containing the combiner.
>>>>>
>>>>>The source in question is produced _from_ the table as the
>>>>>"combiner" updates it.
>>>>
>>>>That's fine with me. The Dynamic Substitution claims place no
>>>>limitations on the source of these values.
>>>
>>>Right. But it's not a source. It's a product of the same
>>>table.
>>
>>No problem. It *becomes* a source.
>
>By the simple process of ignoring what "source" means.
>
>
>>>>>>When you present a system which is more than just the combiner, I
am
>>>>>>free to select what signals there are and try to match them to a
>>>>>>claim. You don't get to decide what signals I select. You can
add
>>>>>>whatever you want around an invention in an attempt to obscure
which
>>>>>>parts actually constitute the invention, but the invention is
still
>>>>>>there somewhere, and I get to find it.
>>>>>
>>>>>Exactly. The sequence _you_ chose depends upon the dynamic
>>>>>update of the table. It is necessarily a function of the
>>>>>combiner, and cannot be outside.
>>>>
>>>>I have no idea what your point may be. The claims do not specify a
>>>>particular origin for the sequences.
>>>
>>>It's not a combiner of data sources. It's producing one
>>>from state alone.
>>
>>It is combining two parts of that RNG state.
>
>And not two data sources, as the term is used in the patent.
>
>
>>>>>>>> But, if you don't like the word "source," perhaps you would
>>>>>>>> prefer the word "value": [...]
>>>>>>>
>>>>>>>Which is not the word in the claim at issue.
>>>>>>
>>>>>>It only takes one claim. Any claim counts.
>>>>>
>>>>>The one you had cited is claim 1. If you want to instead go
>>>>>through claim 15, note that it's not only a "value" it's an
>>>>>"input value". Claim 15 also states one output, and if you
>>>>>use that value for the output, the cipher cannot function.
>>>>
>>>>I *think* the intent here is to recall an argument made earlier that
>>>>"the cipher" has an XOR combiner, so "the" combiner obviously is not
>>>>DynSub.
>>>
>>>Not really. You tried to show claim 1 fit; then when I
>>>argued it didn't, you appealed to the wording of a different
>>>claim.
>>
>>When the question is whether the patent covers whatever, any claim
>>counts.
>
>What happened here is that you appealed to the wording of
>claim 15 since the statement of claim 1 doesn't fit. Yes
>any claim counts, but claim 1 with certain wording replaced
>by text from claim 15 doesn't count.
>
>>>[...]
>>>>>From "actual words from a claim" to what you are happy with
>>>>>is a huge change.
>>>>
>>>>Fine. So what?
>>>
>>>So I said the standard changed and you disagreed. If it's
>>>a "so what" then fine.
>>
>>It's an expected consequence of the ground rules I stated in the
>>beginning: we cannot remove legal judgment -- which requires a
>>background in the law and the rules -- from the debate. The closer
>>one gets, the more the issue depends on those rules instead of
>>technology, and the less sure I can be.
>
>You are pretending the issue is something it is not.
>
>[...]
>>>>I started out this endless river of text by pointing out that the
>>>>interpretation of an issued patent is a *legal* issue, not a
technical
>>>>one, and you responded to that with something deliberately intended
to
>>>>have me address the technical issues -- under those conditions.
>>>
>>>This is a "sci" group and I'm not interested in armature
>>>lawyering. The legal issues have not even come up. In the
>>>case of recent proposed cipher, no one is using it, or
>>>making or selling any product that includes it. It's a
>>>technically flawed symmetric cipher so doubtless it will
>>>remain unused. In the case of RC4, millions of people use
>>>it and many products include it.
>>
>>Really? Where do you get your information? How about a few names and
>>addresses?
>
>I work with SSL, TLS and WTLS, so from many sources I'm
>aware of their popularity and their use of RC4. Would you
>want the addresses of Netscape and Microsoft? I'm not sure
>I see the relevance.
>
>
>>>Despite some assertions
>>>about trade secrecy years ago, the actions that might raise
>>>legal issues simply do not exist.
>>
>>Perhaps you can testify from your personal knowledge of the trade
>>secret cipher, but I can't. All I know is rumor.
>
>I can testify to what I wrote, not your misunderstandings.
>
>
>>>>>>The body of the patent is used as a dictionary to interpret the
>>>>>>meaning of words used in the claims. I have quoted several times
>>>>>>where it does not support your interpretations.
>>>>>
>>>>>You have quoted such zero times. I never said it couldn't
>>>>>be used to combine confusion sequences, or the various
>>>>>things you cited.
>>>>
>>>>*I* have to follow and respond to -- what? -- 8 or 10 different
>>>>threads, and I am not going to necessarily put every quote in every
>>>>thread. If you don't read all I write, you are going to miss out.
If
>>>>you want to keep talking, you have to do at least as much homework
as
>>>>me, and you are behind.
>>>
>>>Done. (Well, I think so - my news server sucks.) I stand by
>>>my reporting.
>>
>>The issue wasn't "reporting," the issue was asking questions which had
>>been asked and answered.
>
>False. If you are going to accuse me of not doing my
>homework, you might at least read and follow.
>
>
>[...]
>>A decision has been made. If you are going to say it was wrong, you
>>will have to cite chapter and verse in nothing less than a detailed
>>legal argument. And it won't take much of that before you are beyond
>>any comment from me.
>
>That's not what I'm saying. Shuffle doesn't fit, and RC4
>doesn't fit for similar reasons.
>[...]
>>>It refers specifically to a post of yours from April 2.
>>>Here's the "fit" at issue:
>>>
>>> >Here's the proposed modified RC4:
>>> >
>>> >byte x, y, z, sbox[256];
>>> >encipher(byte data) {
>>> > x = (x + 1) & 255;
>>>
>>> Here x might be the "first data source."
>>>
>>> > y = (y + sbox[x]) & 255;
>>>
>>> Here y might be the "second data source," and sbox[] might be the
>>> "substitution means for translating values from said first data
source
>>> into said result data or substitute value."
>>>
>>> The "second data source" is modified by said "result data" before
use,
>>> but no part of the claims excludes that possibility. Quite the
>>> contrary, as we see . . . .
>>>
>>>The y is not a source; the sequence of values is product of
>>>the table state and cannot be produced outside the combiner.
>>>The x isn't really a source either.
>>
>>They are sources with respect to the combiner.
>
>No, claim one clearly puts the table and the mechanism that
>sets its state inside the combiner. The table state
>produces the stream at issue, so it does not fit as a
>"source" to the combiner. The mechanism you identified is
>not even shaped like dynamic substitution.
>
>
>>>Using the rest of the patent as a dictionary, we see that
>>>"data source" is used as usual in the description of
>>>algorithms. The "fit" dosn't.
>>
>>Sure it does.
>
>You are only fooling yourself. Do you disagree that the
>patent shows "source" is used as usual in the description of
>algorithms to mean an input sequence?
>
>
>>>>"The combiner can also be used to combine two pseudo-random
confusion
>>>>streams into a more-complex confusion stream.
>>>
>>>How is that relevant? Are you going to say that x, which
>>>steps through the table locations sequential order is a
>>>confusion sequence? There is no confusion sequence there
>>>until it is produced from the table state.
>>
>>What "I am going to say" is that the code is intended to generate a
>>sequence of x values; that is a sequence, and a source.
>
>So then the quote is not relevant. We've dealt with the
>"source" issue elsewhere.
>
>[...]
>>>It's producing
>>>one source from the table state. It is not, and does not
>>>use, the invention disclosed in your patent.
>>
>>The limits of a patent are the claims. It is not necessary to
>>describe a particular application in detail in the specification to
>>enforce a claim which reads on it. But of course the specification in
>>this case did clearly describe the use of combining RNG sequences.
>
>The patent discloses, or teaches some technique. The patent
>also "claims" what is a new invention. You cannot
>re-interpret the terms, to make internally produced data a
>source. The mechanism you claimed to be dynamic
>substitution is not combining two sources or two RGN
>sequences; it's generating one PRNG sequence from state.
>
>
>--Bryan
------------------------------
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Crossposted-To: comp.unix.aix
Subject: Re: Password tool!
Date: Mon, 16 Apr 2001 14:40:47 -0000
[f-u set]
<sklC6.42519$[EMAIL PROTECTED]> divulged:
>Yes, there is a password changer in AIX.
please use it.
>But that tool works like this:
>$ passwd
>Enter user's password:
>Enter user's password again:
>Enter user's new password:
suexec and expect are your friends.
>And I wan't to make a web based application, which can change users
>passwords. But this web based application can't enter any text in these
>inputs!
i hope you use ssl.
--
okay, have a sig then
------------------------------
From: <[EMAIL PROTECTED]>
Subject: Re: Data dependent arcfour via sbox feedback
Date: Mon, 16 Apr 2001 11:04:27 -0400
-snip-
>
>The patent discloses, or teaches some technique. The patent
>also "claims" what is a new invention. You cannot
>re-interpret the terms, to make internally produced data a
>source. The mechanism you claimed to be dynamic
>substitution is not combining two sources or two RGN
>sequences; it's generating one PRNG sequence from state.
>
>
>--Bryan
I tried to read this thread and related topics, but there are too many
posts for me. Does Ritter say anywhere whether or not he has tested his
broad position in court? I don't think his broad interpretation would
hold. Lets see what he does if a wealthy company like IBM (deep pockets
in the legal dept.) implements something similar to that described in
this thread.....
------------------------------
From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Mon, 16 Apr 2001 10:06:58 -0500
> I'd have thought the reuse of part of a OTP and the use of random fill
> are independent. The exception is if the overlap between the OTPs is
> for the random parts of one or another message (or both), in which
> case the randomness equates to there being no overlap, but if the
> overlap occurs for the non-random bits of the messages, then the
> random fill is esoteric. So the only effects of random fill are to
> decrease the likelihood of overlap to the same extent as if there were
> no fill and the messages were simply smaller (and so the OTP pad
> chunks smaller and the need for overlap reduced or eliminated).
Oh yeah. Silly me. Well not totally, I think. My objective is basically
to use only the OTP as much as possible. What if for the random fill I used
"other" portions of the pad. This starts getting a bit convoluted, but it
would involve algorithms(random no less) that made sure the fill was taken
from "further" away from the portion of the pad that is being used to code
the block. There are other things that could be done as well. Once again
it comes down to determining how much brute force crunching time it would
take in relation to the size of my pad while I "rotate my shields" before
someone could realistically "penetrate".
Beam me up Scotty!
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: LFSR Security
Date: Mon, 16 Apr 2001 08:21:08 -0700
Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Ian Goldberg wrote:
>
> > In article <[EMAIL PROTECTED]>,
> > Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote:
> > >With N unknown you just use Berlekamp-Massey. The invariant in BM is
> > >that one always has the smallest configuration that explains the
> > >sequence up to the current bit. By continuing this process through the
> > >gaps, assigning each unknown bit the subsequent output of the current
> > >machine, one can maintain the invariant and preserve the validity of
> > >the result.
> >
> > So after reading this thread this morning, I spent the day studying the
> > BM algorithm. I now Understand it.
> >
> > The above isn't true. For example, find the LFSR that generates:
> >
> > 1 0 0 0 ? 0 ? 0 1 1
> >
> > The answer is actually the LFSR of size 5: 111101 which generates
> >
> > 1 0 0 0 1 0 1 0 1 1
> >
> > But if you use Trevor's technique, you get that after the first 4 bits,
> > you're working with the LFSR of size 1: 10 which generates
> >
> > 1 0 0 0 0 0 0 0 0 0 ...
> >
> > and you'll only see a problem when you get to the 1's at the end,
> > at which point you're forced to change it to the LFSR of length 8:
> > 110000001.
>
> Not quite. You can assume that the most recent known bit is the culprit,
as
> in your example, but there's no reason to prefer that bit, and good reason
> to believe that the culprit is earlier in the sequence. So when a
conflict
> is found one must backtrack by trying (toggling) each of the assumed bits
in
> turn and use the smallest machine created. The backtracking is complete
> when no single-bit change of the assumed bits produces a smaller machine.
(I
> need to show that any change to a smaller machine can be found by
successive
> single-bit changes -- can't quite do that yet).
>
> The idea is to, at all times, have as small a machine as is necessary to
> produce as much of the sequence as possible. In your example the machine
> found at bit nine was not the smallest machine that could generate the
first
> nine bits, so it violates the BM invariant.
If you're going to do all that back-tracking, wouldn't it be easier to, if
you have N unknown bits, to scan through all 2**N possible settings for them
at the outset, and simply run BM 2**N times, and select the smallest output?
--
poncho
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.security.misc,talk.politics.crypto
Subject: Re: NSA is funding stegano detection
Date: Mon, 16 Apr 2001 15:35:22 GMT
The nearest example I can find is that already cited earlier in the
thread by Niels Provos. A paper by him on the subject can be found at:
http://www.citi.umich.edu/techreports/reports/citi-tr-01-4.ps.gz
Despite the file name being citi-tr-01-4_ps.gz it appears to be a
straight postscript file. As you appear to be using windows, you may
need GSview or similar to read it, and it may help to rename the file
after downloading to just citi-tr-01-4.ps so windows doesn't
misassociate it.
He describes an approach to analysis of JPEG using chi square as
proposed by Westfeld and Pfitzmann, and then extends their approach,
and then describes simple transforms on those LSB not used for the
message so as to frustrate this approach to statistical analysis.
On Mon, 16 Apr 2001 13:48:03 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>
>
>[EMAIL PROTECTED] wrote:
>>
>[snip]
>> I wasn't contemplating a simple analysis of overall patterns. No doubt
>> the diversity between Monets, Rothkos, family snaps and a superman
>> comic are sufficient to confuse analysis which simply looks for gross
>> patterns in total picture information.
>>
>> I am not an expert in digitised image tech, but if one is looking for
>> hidden messages in an image file, one might, for example, analyse the
>> patterns in the least significant bits, between eachother and given
>> the values in the other bits. This follows the logic that one cannot
>> hide the message in bits that would affect the image's appearance, so
>> the LSBs are the prime suspects. Are the LSBs in a straight jpeg
>> without any pattern either in themselves (ie the value of each bit is
>> independent of the others) as well as wrt to the more significant
>> bits? If so, they must be, by definition, redundant. If not, then
>> presumably altering them may be detectable, given large enough samples
>> of tampered and untampered files to analyse, and a knowledge of JPEG
>> algorithms (or GIFs etc, as approp).
>
>No doubt that the possibilty exists, at least theoretically.
>(Anyway, it is absolutely impossible to prove the opposite.)
>I think it is on the other hand interesting to know which
>practically significant methods of analysis that exploit
>statistical properties and are applicable to general cases,
>where the sender intentionally try to avoid sending pictures
>of the same statistical 'category' (term left undefined,
>sorry), have already been developed or in the course of
>promising studies.
>
>M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Walter Roberson)
Crossposted-To: comp.security.misc,talk.politics.crypto
Subject: Re: NSA is funding stegano detection
Date: 16 Apr 2001 15:42:42 GMT
In article <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
:I am not an expert in digitised image tech, but if one is looking for
:hidden messages in an image file, one might, for example, analyse the
:patterns in the least significant bits, between eachother and given
:the values in the other bits. This follows the logic that one cannot
:hide the message in bits that would affect the image's appearance, so
:the LSBs are the prime suspects.
One can hide data even in gross-level picture elements.
"If I'm wearing a tie in the picture, add one to all numbers in the
hidden message. If I'm holding a dog, negate everything. If
I'm looking at my watch, please send more beer hidden in the next
shipment."
------------------------------
From: "Full Name" <[EMAIL PROTECTED]>
Subject: P1363 draft
Date: Mon, 16 Apr 2001 08:36:12 -0700
Anyone know how to get a copy of the P1363 draft? It's available at the
IEEE web site, but in order to download it one hash to be a member of
something and supply a username and a password. Can anybody join, or is
this an insiders-only option?
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Reusing A One Time Pad
Date: Mon, 16 Apr 2001 15:57:12 GMT
On Mon, 16 Apr 2001 12:33:25 GMT, "Tom St Denis"
<[EMAIL PROTECTED]> wrote:
><[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
<snip>
>> Of course one can re-use a OTP, its just that in doing so you make
>> cryptanalysis trivially simple.
>
>No you cannot reuse an OTP it's impossible. If you somehow did reuse a pad
>then it's not a *******ONE TIME****** pad.
>
<snip>>
>Tom
>
>
Semantics. It is ackowledged that the classic breach of a OTP is to
reuse it. Of course if you do reuse it it becomes a two timing pad
;-) not a "*******ONE TIME****** pad".
But leaving the semantics to one side, the question Mark has, in
effect, asked is what is the effect of *partially* reusing a OTP?
If the reuse is of one bit only, does it in fact matter? If it is of
two bits presumably it matters more, but how much easier is it to
cryptanalyse two messages made using two one time pads in which the
last two consecutive bits of the first pad are the same as the first
two consecutive bits of the second? What about if the overlap is of
three bits? What about four? etc etc. This is not an entirely
meaningless question, as you seem to suggest.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.security.misc,talk.politics.crypto
Subject: Re: NSA is funding stegano detection
Date: Mon, 16 Apr 2001 16:02:16 GMT
On 16 Apr 2001 15:42:42 GMT, [EMAIL PROTECTED] (Walter Roberson)
wrote:
>In article <[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED]> wrote:
>:I am not an expert in digitised image tech, but if one is looking for
>:hidden messages in an image file, one might, for example, analyse the
>:patterns in the least significant bits, between eachother and given
>:the values in the other bits. This follows the logic that one cannot
>:hide the message in bits that would affect the image's appearance, so
>:the LSBs are the prime suspects.
>
>One can hide data even in gross-level picture elements.
>"If I'm wearing a tie in the picture, add one to all numbers in the
>hidden message. If I'm holding a dog, negate everything. If
>I'm looking at my watch, please send more beer hidden in the next
>shipment."
No s**t! I'm looking at my watch, OK? But this is neither strong
encryption, nor steganograhy. It is a simple (and possibly effective)
pre-agreed visual code.
------------------------------
From: Steve Portly <[EMAIL PROTECTED]>
Subject: Re: C Encryption
Date: Mon, 16 Apr 2001 12:03:49 -0400
Small modification, you had a memory leak that could give access to your pass phrase.
:-)
Jan Panteltje wrote:
> On a sunny day (15 Apr 2001 16:32:18 -0600) it happened [EMAIL PROTECTED]
> (Ben Cantrick) wrote in <9bd7hi$[EMAIL PROTECTED]>:
>
> >In article <hWlC6.42589$[EMAIL PROTECTED]>,
> >Logan Raarup <[EMAIL PROTECTED]> wrote:
> >>Anyone know how to encrypt a string in C?
> >
#include <stdio.h>
char inStr[17];
int count;
>
> >
> >void main(void)
> >{
> >/* char inStr[17]; Gratitous buffer overflow error part 1. */
> >
> > printf("Enter the string to be encrypted: ");
> > gets(inStr); /* Gratitous buffer overflow error part 2. */
> > printf("The string encrypted is: ");
> > printf("djlkakjfdLI3nklFD9Fklklfasj(3jmklFD3#@23jklas;j(32lkjr*");
> > printf("\n");
printf("\nMemory containing pass phrase which will be swapped to disk\n");
for (count = 0; count < 17; count++)
printf("%c", inStr[count]);
printf("\nLets overlay this array before we exit the program\n");
for (count = 0; count < 17; count++)
{
inStr[count] = '0';
printf("%c", inStr[count]);
}
>
> > return(0);
> >}
> >
> > This encryption program has perfect security - the output is essentially
> >random and has no dependecy whatsover on the input.
> >
> > But you're going to have to figure out the decryption routine on your own. ;]
> >
> >
> > -Ben
> >--
> >Ben Cantrick ([EMAIL PROTECTED]) | Yes, the AnimEigo BGC dubs still suck.
> >BGC Nukem: http://www.dim.com/~mackys/bgcnukem.html
> >The Spamdogs: http://www.dim.com/~mackys/spamdogs
> >"I don't think so," said Rene Descartes. And then he vanished.
> >
> Yes, but it is not user friendly,
> printf("This is the encrypted string with a truly random OTP\n");
> is a lot better.
> I always use this, end select the OTP accordingly, since it has to change
> anyways.
> Message should be shorter then the above text of cause.
> ;-)
> Over to you
------------------------------
** 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
******************************
