Cryptography-Digest Digest #633, Volume #10 Fri, 26 Nov 99 14:13:01 EST
Contents:
Re: smartcard idea? ("Craig Inglis")
Re: Random Noise Encryption Buffs (Look Here) (Tim Tyler)
Re: FEAL-8 algorithm (Johnny Bravo)
Re: FEAL-8 algorithm (Tom St Denis)
Re: Ask about Certification-less Public Key (Anne & Lynn Wheeler)
Re: The Code Book (UBCHI2)
Re: Ask about Certification-less Public Key (Anne & Lynn Wheeler)
prime density (Tom St Denis)
Re: Random Noise Encryption Buffs (Look Here) (Tom St Denis)
Re: Stretching low-entropy keys (Johnny Bravo)
Re: Stretching low-entropy keys (Johnny Bravo)
Re: brute force versus scalable repeated hashing (Bill Unruh)
Re: Why Aren't Virtual Dice Adequate? (Sundial Services)
New Probabilistic Stream Cipher ([EMAIL PROTECTED])
Re: brute force versus scalable repeated hashing (Johnny Bravo)
Re: How safe is Mobile Phone ? (Sundial Services)
----------------------------------------------------------------------------
From: "Craig Inglis" <[EMAIL PROTECTED]>
Subject: Re: smartcard idea?
Date: Fri, 26 Nov 1999 17:14:11 -0000
Shawn Willden wrote in message <[EMAIL PROTECTED]>...
>> >Craig Inglis schrieb:
>> >>
>> >> I wonder what it would cost to design a credit card sized smartcard
>> >> with a numeric keypad, a little LCD display, and a processor
>> >> powerful enough to a 2048bit modular exponentiation?
>
>That much hardware isn't necessary, IMO. The PIN pad and display can be on
>the ATM rather than the card as long as (1) the card can authenticate the
ATM
>and (2) the card can communicate the result of that authentication to the
>user.
>
>(2) can be accomplished by embedding an LED in the card which can be turned
on
>and off by the smart card microprocessor. (1) can be accomplished through
>shared triple-DES keys. The keys stored on the card should be derived and
>changed periodically, of course.
>
>In practice, we would probably forgo the LED because in a smart card-based
>scheme the PIN would only be known to the card and the holder, meaning the
PIN
>is completely useless without the card. A bogus ATM that grabbed peoples
>cards would get noticed and shut down in a hurry.
>
>Of course, the authentication of the card to the ATM or network could also
be
>accomplished with shared triple-DES keys -- no need for a large-integer
>coprocessor.
This is just a move back to the traditional approach where the smartcard
holds sensitive information.
My original suggestion had the benefits that you could have
complete trust in the system because you controlled the
interface and the card didnt store any private information and
therefore would be immune to any form of attack even if stolen
taken apart or whatever. You dont have to worry about things
like "bogus ATMs" at all since they would never work :-)
Craig.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Reply-To: [EMAIL PROTECTED]
Date: Fri, 26 Nov 1999 17:04:55 GMT
John Savard <[EMAIL PROTECTED]> wrote:
: Effectively guessing the next number in a sequence of numbers produced
: from the conventional physical randomizers commonly used, such as
: dice, or better, a drawing of lots or a roulette wheel, is
: _definitely_ not known, or even suspected, of being possible.
I was not intending to refer to guessing the next number with any
certaintly.
Given enough cyphertext, the smallest bias is sufficent to gave the
attacker of the resulting OTP information.
Dice, drawing lots, or a roulette wheel /often/ have biases that produce
less than perfect random numbers. A whole book was written devoted
largely to successful attempts to win money by exploiting the
non-randomness in commercial roulette wheels. This means that the bias
exceeded 1/61.
Of course, while custom RNGs in hardware are not perfect, they /are/ the
best way of generating randomness that we have - and may even defeat
analysis when normal message sizes are used.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Nature always sides with the hidden flaw!
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: FEAL-8 algorithm
Date: Fri, 26 Nov 1999 12:21:05 GMT
On Fri, 26 Nov 1999 12:42:45 GMT, "Simon Odermatt"
<[EMAIL PROTECTED]> wrote:
>I'm sorry, I can't choose another algorithm. It's given by the customer.
If your customer is actually using this for crypto you may want to
point out how insecure it is and suggest an alternative. And if the
customer wants it anyway, print up a disclaimer stating that the
customer is fully aware that they are ordering a system that uses a
broken crypto system and that you will not be held responsible for
compromise of data under any circumstances.
If they understand that, sign it, and want it anyway, they deserve
what happens to them.
Best Wishes,
Johnny Bravo
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: FEAL-8 algorithm
Date: Fri, 26 Nov 1999 17:16:19 GMT
In article <9fv%3.241$U67.169628@news>,
"Simon Odermatt" <[EMAIL PROTECTED]> wrote:
> I'm sorry, I can't choose another algorithm. It's given by the
customer.
So you are building a *new* cryptosystem for a customer using a weak
cipher. Are they informed FEAL has been masacred?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: Ask about Certification-less Public Key
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Fri, 26 Nov 1999 17:33:01 GMT
"Lyal Collins" <[EMAIL PROTECTED]> writes:
> I think you are talking about a Public Key registered or stored with a
> counter-part.
> When you exchange messages, the counter-part retrieves your public key and
> uses it to verify a message signature. You no longer have to send around
> your public key or certificate, saving a lot of bandwidth - 5kbytes/message.
>
> Search for AADS or ANSI X9.59 to see a standard that uses this model.
>
> The deployment costs are similar - you need a secure database, and a
> reliable, trusted registration process to store the public key.
the deployment costs are similar if you are starting from scratch
... however if you already have a secure infrastructure (like for
financial transactions) ... the incremental costs to upgrade the
existing facility may only be a couple percent and the public key
specific operationl costs of the overall infrastructure may can even
be a smaller percentage.
http://www.garlic.com/~lynn/aadsmail.htm#variations
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1
other opportunities possible for incremental costs is to leverage the
existing pin debit ... where the card is personalized, pin is securely
recorded, handled, and transmitted. Incremental costs for adding a
chip to magstrip card, generating key pair, and securely recording
public key is also rather small. In many respects, the
shared-secret/pin actually requires higher integrity processes than
corresponding processes for public key (i.e. the infrastructure isn't
compromised just by learning a person's public key).
http://www.garlic.com/~lynn/aadsm2.htm#straw
the scenerio is that it is possible to deploy PKI small pilots for
relatively small up front investment ... much less than the 2%-3%
costs to modify an existing infrastructure (public key enabling an
existing infrastructure is well under the Y2K remediation
costs).
Claim has alwas been that the trade-off cross-over is approx. when the
public key enabled market penetration exceeds 4%-5% it becomes much
less expensive to modify the existing infrastructure than building a
new infrastructure from scratch.
the biggest actually costs is the customer call center ... general
consumer market expectation is that they have a 1-800 to contact if
anything hiccups (one of the things that small pilots frequently pass
over).
misc. other references:
http://www.garlic.com/~lynn/aadsover.htm
http://www.garlic.com/~lynn/aadswp.htm
& of course
http://www.garlic.com/~lynn/
--
--
Anne & Lynn Wheeler | [EMAIL PROTECTED], [EMAIL PROTECTED]
http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/
------------------------------
From: [EMAIL PROTECTED] (UBCHI2)
Subject: Re: The Code Book
Date: 26 Nov 1999 17:44:51 GMT
Singh repeated lots of material from Kahn's The Codebreakers. However, the
material on the discovery of public key systems and quantum cryptography was
excellent.
------------------------------
Subject: Re: Ask about Certification-less Public Key
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Fri, 26 Nov 1999 17:46:45 GMT
... also ....
Subject: AADS/X9.59 cost sharing intuition
Several times at X9A10 meetings there have been statements about the
advantages of infrastructure cost sharing associated with AADS
operation.
assertion #1: majority of a certificate authority is account-based
management
assertion #2: cryptography for digital signature infrastructure can be
added to existing financial account infrastructure at 1%-5% of the
cost of the current infrastructure
corollary: cost sharing with integration of digital signatures into an
existing financial account based infrastructure will have existing
non-digital signature applications carrying 95%-99% of the total
account costs.
assertion #3: high value digital signature financial applications can
carry 90%-95% of the digital signature infrastructure cost
corollary: non-financial application use of a integrated financial
digital signature infrastructure can be done at 1/200th to 1/2000th
the per account cost of an independent non-financial digital signature
infrastructure.
In a financial AADS infrastructure:
fraction of account costs covered by non-digital signature
applications
.95 to .99
fraction of account costs covered by digital signature applications
.05 to .01
fraction of digital signature account costs covered by financial
digital signature applications
.90 to .95
fraction of digital signature account costs covered by non-financial
digital signature applications
.10 to .05
fraction of account costs covered by non-financial digital signature
applications
.1*.05 to .05*.01
or
.005 to .0005 (1/200th to 1/2000th)
This is applicable to the integration and use of AADS/X9.59 in an
existing financial account infrastructure.
--
--
Anne & Lynn Wheeler | [EMAIL PROTECTED], [EMAIL PROTECTED]
http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: prime density
Date: Fri, 26 Nov 1999 17:41:38 GMT
Knowing x/lnx I tried to develope the prime density using x/lnx/x which
is similar to the 1.12/lnx
Where did the 1.12 come from? Obviously it would have been
1.12x/lnx/x
Which means the prime number theorem is accepted as 1.12x/lnx?
And what is
0.99 = 1 - 1.12/lnx
I can't solve it reasonably [i.e I got 1.01226]
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Fri, 26 Nov 1999 17:48:24 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> Tim Tyler wrote:
> > I feel it's far from easy. Generating "genuinely" secure random
numbers
> > is not even known to be possible.
>
> It's not *trivial*, and may not be "known" to amateurs, but
> we do it all the time. There are commercial crypto chips that
> implement this function (among other, more important functions).
>
Yeah I think they get a bit confused [ I know I do ].
Real random data does not have to be universially random. If I give
you numbers like [1, 3, 5, 7] you may not know the correlation [well
they are odd ...]. If you didn't know how they came about [their
correlation] they would be perfectly random to you.
Thus random is only a subjective term. I.e my private key is totally
random since you can't guess it any better then guessing all possible
keys. [or solving it].
In this case those 'chips' [or the winrng] are random since we can't
predicts it's output. Universially randomness does not exist though....
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: Stretching low-entropy keys
Date: Fri, 26 Nov 1999 13:09:11 GMT
On Fri, 26 Nov 1999 10:53:50 GMT, [EMAIL PROTECTED] wrote:
>Here a question still arises if we have really increased with the key
>space by t-bits. b'cos still a interceptor may do a key search on s-bits
>key space and carry on the same iteration as above to create a l-bit key
>for a brute force attack! Assuming that the algorithm is available after
>implementation as well as the scheme for selecting the salt.
The actual increase in the effective length of the key would be
log2(n) where n is the max possible number of iterations if a random n
is chosen. i.e. using from 1 to a million iterations, picking at
random, would add about 20 bits to the key length.
Using a constant n doesn't add any security as your attacker will
just stretch each key n times before testing it but it might have
another advantage. A timed iteration might be of use (say you ran it
for 10 seconds). The attacker might not need to run for the full 10
seconds to reach your n due to superior hardware; but compared to
running for only 1/10 of a second on your machine to reach your n,
your attacker will have to spend 100 times longer brute forcing your
key. While this doers't actually add any security, it does slow down
brute force attempts on your key and can be adjustable to the desires
of the user. If you didn't want to wait 10 seconds you could run with
just a couple of seconds and make the brute force take 20 times longer
to complete. You just have to be sure there are no shortcuts to your
mixing operation that can reduce n iterations to less than that amount
of work.
Best Wishes,
Johnny Bravo
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: Stretching low-entropy keys
Date: Fri, 26 Nov 1999 13:39:49 GMT
On Fri, 26 Nov 1999 15:03:25 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
> I have not read there paper. But not reading has never stopped Mr BS or
>Wagner form commenting on my code.
You admit you have no idea what they are talking about, then you go
on to attack it. You are doing exactly what you accuse Bruce of
doing, how exactly does this make you any better than your admittedly
low opinion of them?
<admittedly clueless drivel snipped>
Johnny Bravo
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Crossposted-To: comp.security.misc
Subject: Re: brute force versus scalable repeated hashing
Date: 26 Nov 1999 18:44:51 GMT
In <[EMAIL PROTECTED]> Juergen Thumm
<[EMAIL PROTECTED]> writes:
]to encrypt data by use of a passphrase and a symmetric cipher,
]it is common practice to build an md5 or sha hash from the
]passphrase, and use this as key material for the symmetric cipher.
]cracking this with brute-force is, however, relatively easy.
]RFC 1810 assumes that an MD5 implemented in pure hardware
]could hash 256 Mbps per second, or 32 Megabytes.
]assuming an 8-character passphrase, this means a hardware-md5
Why are you assuming an 8 byte passphrase? Why not a one character
passphrase? That is eaven easier to crack. Ie, you passphrase MUST
contain as much "entropy" as you want your key to have. This is very
well known, and if it does not, you are in trouble.
]for this reason, open bcrypt v 1.5 implements scalable
]repeated passphrase hashing: the passphrase is not hashed
]just once, but thousands of times. not using only md5,
]but md5, sha, and a simple mathematical combination of the
]intermediate results.
And is still susceptible to dictionary lookup. The enemy can simply
prehash all of your 8 character pass phrases, and do a lookup when he
gets your message. 8 characters is too little, no matter how you massage
it.
] this requires more time both on the encrypting machine
]and the attacker's system.
] open bcrypt performs as many hashing rounds as the encrypting
]machine can do within 500 milliseconds;
]this mechanism reduces the effort of brute-force cracking
]to what it should be:
]the pure difference in hardware power available
]to the encryptor and the attacker.
Well, there is also the difference in stupidity between teh encryptor
and the attacker. You assume a stupid encryptor. In that case, there are
loads of attacks available to the attacker, most of which do not involve
breaking the crypto engine.
------------------------------
Date: Fri, 26 Nov 1999 11:50:18 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Tim Tyler wrote:
>
> :>Really? How do you judge how secure they are?
>
> : If the output is _unbiased_, few other problems are likely.
>
> Bias was my primary concern:
>
> How can you make an unbiased die? If you make one, how can you be certain
> it will not pick up dust? What makes you certain it is so uniform it will
> be immue to thermal fluctuatiuons? Do you control the temperature of the
> environment? Or try for a dice that can retain its lack of bias over a
> range of temperatures? In what environment do you roll your dice?
> Is the dice likely to be struck by cosmic rays, that cause it to gain
> or lose matter from its surfaces? How far is the rolling arm from the
> flat surface. Does the arm pick the dice up as it fell before rolling it
> again? Does it shake the dice? Before rolling it? For how long?
My understanding of the problem is that, "it's not the dice, it's how
you roll them." Someone with another pair of dice shouldn't be able to
predict what the outcome of your dice-rolls will be. I suspect that you
could carry that to the "nth degree," as in cosmic rays... but there
must be a law of diminishing returns that kicks in there fairly quickly.
Decent dice -- and a decent throwing hand -- would probably give much
better security than any "virtual dice" (computer program) ever could.
Here's why: even with identical dice, I can't produce identical
throws. (Or at least you hope so, see next paragraph.) A computer
program is always vulnerable: I can steal it, reverse engineer it, and
eventually, perhaps only theoretically, I can reproduce those "virtual"
throws. Two machines, set up the same way with the same inputs, must
produce the same output. Two dice, set up the same way, may or may not.
Therein is the difference; the only one.
One of the things that was recently declassified from the Cold War era
is that the Russian "one time pads" were produced using a
million-monkeys approach in which typists hammered out numbers "at
random." Turns out they weren't so random after all -- the typists
unconsciously alternated hands, chose number-patterns that were easy to
type, and no doubt were bored out of their gourds while doing this work
all day. This was a one-time pad that was not only theoretically but
practically weak. It allowed some messages to be deciphered
successfully.
But even under perfect conditions, OTPs remain in the world of spies and
diplomats, not for security reasons but for logistics... one time pads
have to be distributed, and in equal volume to the number of messages
transmitted (and, re-transmitted) in them. They have to be transmitted
in a secure channel. Trouble is, if such a secure channel existed in
the real world you'd simply convey your messages using it, and you would
not need a cipher at all. :-)
Real-world cryptography does not demand perfect security: every message
has some shelf life, some finite limit to its value and importance. But
there might be millions of messages per day. It's the Day after
Thanksgiving, after all... how many millions of credit-card number
messages are flowing through telephone wires to bank computers right
now? (Ugh...) One-time pads cannot serve this requirement at all. SSL
can. DES can. IDEA can. Each of these ciphers can serve the
operational needs of its users, including the need to make decipherment
"NOT impossible, but damned difficult." ;-)
======================================================================
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
mailto:[EMAIL PROTECTED] (PGP public key available.)
> High-speed, script-driven, table repair/support for Paradox/BDE...
> ChimneySweep{tm}: "Click click, it's fixed!" {tm}
> http://www.sundialservices.com/cs3web.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: New Probabilistic Stream Cipher
Date: Fri, 26 Nov 1999 10:56:15 -0800
The following is a new probabilistic stream cipher. All
matrix/vector elements are bits. All operations are done modulo
2. The message size is expanded by a factor of (m+k). Assume
n=1024, m=k=256.
S[0] = random set of n vectors, each m bits long
S[1] = random set of n vectors, each m bits long, distinct from
S[0]
M = random, invertible, (m+k) by (m+k) bit matrix
Key = (M,S[0],S[1])
P[i] = ith bit of plaintext
C[i] = ith block of ciphertext (m+k bits)
V[i] = random element of S[P[i]]
R[i] = k random bits
ENCRYPT: C[i] = M * concatenate(V[i], R[i])
DECRYPT: P[i] = which S[] contains the first m bits of M^(-1) *
C[i]
Choosing m=1+log(n) would ensure that every possible ciphertext
block can be generated. It isn't clear how this would affect the
security of the system.
Assume a known-plaintext attack, where the attacker has access to
a large number of encrypted zeros. If the attacker XORs pairs of
ciphertext vectors, the result is as if the codebook S[0]
contained n^2 vectors, one of which is the all-zero vector. That
might be helpful in cracking this.
Does anyone see an easy way to break this system?
______________________________________________________________________________
Total Internet privacy -- get your Freedom pseudonym at http://www.freedom.net
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Crossposted-To: comp.security.misc
Subject: Re: brute force versus scalable repeated hashing
Date: Fri, 26 Nov 1999 13:56:16 GMT
On Fri, 26 Nov 1999 15:20:34 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
> This whole concept is a very bad idea for creating a key. If Mr BS
>and his buddies support something like this they most think people have
>oat meal for brains.
Since you have no idea what is in the paper, how can you pretend to
know what they are supporting, much less know what they actually
proposed? You admit you are completely clueless about the contents of
the paper, yet here you are spouting off as if you are the one true
font of wisdom. I nominate you for the sci.crypt Kook of the Month
for December. I know it's a bit early, but your only competition
would be Charles Booher, and I haven't seen him around since his last
run at alt.security.pgp.
>One should never use any deterministic means
>like this one to get a large key if one want to take advantage of a large
>keyspace. It would be best to get as large a source of random data as
>possible and then try to some what secure it with a password much like
>the way PGP encyrpts its secret keys. If you have a large random key and
>then you protect it with your passpharse this file is the only one protected
>by the short key.
And any system protected by a short key is only as strong as that
key. The point of the paper which you admit you didn't read, yet
still felt you knew enough about to attack, is that if your keyspace
is 2^32 you have 32 bits of security. If you force your attacker to
perform 10 million hashes of your key in order to test it, your
attacker can not test your keys in 2^32 time, instead he must take
2^55 time to test all the keys. Methods were also shown to defeat
dictionary attacks that attempt to precompute the hashes.
Massively parallel systems like the DES cracker can also resisted
against by using computations that are prohibitive to implement in
hardware due to memory requirements and require 32 bit arithmetic.
>the code and you enter your phase phrase. Th pharse its self is a low
>entropy key that was used to encrypt the key that you actually going to
>use. An enemy intecepting a message and having the source could would
>have far more to do that guessing you pass phrase he has to guess the
>full key and it is "MILLIONS OF BITS LONGER" than any of the AES methods.
Too bad your cipher doesn't actually use random data. Pseudo-random
numbers do not a One Time Pad make.
Johnny Bravo
------------------------------
Date: Fri, 26 Nov 1999 12:05:00 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: How safe is Mobile Phone ?
Essentially, yes they are all true.
Digital telephones do use an encryption mechanism to conceal the
station-number of the phone, but this encryption mechanism can be and
has been broken. Cellular phone companies lose millions of dollars in
revenue each year to counterfeit phone-numbers. Most of us have had the
experience, or know of someone who has had the experience, of dealing
with a phone-bill full of bogus phone calls. The phone company has to
eat them.
But wait, it gets worse. Your conversation is transmitted by radio and
it is transmitted in the clear; your voice is not scrambled. Anyone
with a scanner, suitably and easily modified, can intercept your call
and I think it's a safe bet to assume, any time you use a cell phone,
that someone has done so. You can't detect a passive receiver. It's
not legal to sell one but it's trivial to produce one.
The cellular-telephone media provides a tradeoff: ultimate convenience,
no security. Trouble is, even though the phone-company discloses risks
to consumers, most of them act as though those risks did not exist and
-- when and if they are faced with a situation where confidentiality
really matters -- forget to take reasonable precautions.
Scrambled cellular telephones do exist. Technologies like PGP and
PGPPhone also exist. If your communications requirements carry a legal
or due-diligence requirement of privacy, non disclosure, and so forth,
then (IMHO) you probably cannot consider an ordinary digital or analog
cellular telephone to be adequate protection. But someone out there
does produce the product that you need which will be adequate.
>Hank wrote:
>
> I am curious if the mobile phone system uses any data encryption mechanism.
> For example, if the handshaking process is not encrypted, someone might
> easily intercept the ID of my phone and forge it to make a fake call. And
> if the communicaion is not encrypted, someone can easily eavesdrop on
> my conversation with friends. Are these all true ?
------------------------------
** 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
******************************
