Cryptography-Digest Digest #94, Volume #9 Wed, 17 Feb 99 13:13:03 EST
Contents:
Re: True Randomness (och)
Re: How to get gov't approval (Jean Hague)
Re: Barcodes ("Scott Berg")
Re: Barcodes ("Scott Berg")
Re: More Security for Single-DES? (John Savard)
Re: More Security for Single-DES? (John Savard)
Re: Block ciphers vs Stream Ciphers (John Savard)
Re: Cyclic attack on RSA ([EMAIL PROTECTED])
Re: New high-security 56-bit DES: Less-DES (DM Lanza)
Telephone Encryption (R. Knauer)
Re: encryption debate (wtshaw)
Re: encryption debate (Dennis Suchta)
Re: More Security for Single-DES? ("Peter K. Boucher")
Re: Randomness based consciousness?. (Was: Re: *** Where Does The Randomness Come
From ?!? *** ) (R. Knauer)
Re: New high-security 56-bit DES: Less-DES ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (och)
Subject: Re: True Randomness
Date: Wed, 17 Feb 1999 14:13:11 GMT
On 15 Feb 1999 18:05:00 GMT, Noah Paul <[EMAIL PROTECTED]> wrote:
Target? There's just one target and only one can enter
(thus reaching it's target)..
erhm..?
>1. Tag half of the sperm.
>2. If a tagged sperm reaches it's ... uh ... target, the bit is 1.
>3. Otherwise it is 0.
>
>>
>>hoo haaa+ACE- NSA, masturbation hmmm....
>>
>>now that gets me thinking, how about a microscopic viewing device that
>>observes the flaggelating spermatozoa and creates a +ACI-random element+ACI- fr
>>om
>>some aspect of their orientation as they thrash themselves to some death+ACE-
>>
>>--
>>best regards
>>hapticz+AEA-email.msn.com
/* --------------------------------------------
Correct my email address in order to reply to me personally,
by removing XXX@ and inserting the @ instead of .
*/
------------------------------
From: Jean Hague <[EMAIL PROTECTED]>
Subject: Re: How to get gov't approval
Date: Wed, 17 Feb 1999 16:22:26 +0200
This is a cryptographically signed message in MIME format.
==============msF7B30E07CF19397C51080C21
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
It is legal to export anytype of book from the US
If you print your code out and get it out of the
country you can recompile and sell it to whom you
please.
==============msF7B30E07CF19397C51080C21
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIIHoAYJKoZIhvcNAQcCoIIHkTCCB40CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BcMwggKCMIIB66ADAgECAgJ7VTANBgkqhkiG9w0BAQQFADCBuTELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRo
YXd0ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElLIDE5OTguOS4xNiAx
Nzo1NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJTQSBJc3N1ZXIgMTk5
OC45LjE2MB4XDTk5MDIwNTEzNDM0N1oXDTAwMDIwNTEzNDM0N1owQTEfMB0GA1UEAxMWVGhh
d3RlIEZyZWVtYWlsIE1lbWJlcjEeMBwGCSqGSIb3DQEJARYPamVhbkB0aGF3dGUuY29tMFww
DQYJKoZIhvcNAQEBBQADSwAwSAJBAOdmzHTSMTiBVOEQIfMR0o56cKWEDmm3gwehq1jH2qKs
DbVbrFW+Ch1VrQ57S0Qs7Rq4pE0njG/Zwb+nEVKDsRECAwEAAaNUMFIwEQYJYIZIAYb4QgEB
BAQDAgWgMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaAFP4+YJxr
jA+w2DPGysYeWLBxOLXgMA0GCSqGSIb3DQEBBAUAA4GBADfnWYCmIthoT8qGPRW8XZJQrmjN
7nOAH+0vDdxlrOP2ry2g9MTH+EmoxrH1dvhIUg+KXjMh7zUZUdSDIP94uVZrfTWpTLhJnbdL
eo6vK+pnLtVKUqy9yE93UzzTG5tRtlyfBvl/8p0LnyZY1+aWuANvfMuWttv4WA+CTVQqYtb2
MIIDOTCCAqKgAwIBAgIBCjANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNV
BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg
Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEk
MCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxw
ZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk4MDkxNjE3NTUzNFoXDTAwMDkxNTE3
NTUzNFowgbkxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcT
C0R1cmJhbnZpbGxlMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEpMCcGA1UECxMgVGhh
d3RlIFBGIFJTQSBJSyAxOTk4LjkuMTYgMTc6NTUxNjA0BgNVBAMTLVRoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBSU0EgSXNzdWVyIDE5OTguOS4xNjCBnzANBgkqhkiG9w0BAQEFAAOBjQAw
gYkCgYEAxKXl1NTQXwgC7gchfSS/q2uOHusgBwIVhGuP0JMkHxud7miyuSxP6ZNnFxAXHqH5
Q0EjuTCqdpe78+f9gcC1MYv2plAmVPKVKOsZpB6XHrDiuJvBBJoy0DwJbE/kNU/wdr8AEwNP
RQhg8/y00JABihLJnLp/UuoqkzU2PDzkNS8CAwEAAaM3MDUwEgYDVR0TAQH/BAgwBgEB/wIB
ADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQAs
x4IfAUM+B4/uaVypZIL4wJatkyvLm1DXQJqBwrqmdp08lUDcVcHhVYJ5qwopptUM4VcoPo/5
u9XfDZNYqlsti48z5N1YFTV2chUpvUL0WpILd1+dJ9uaLU4bggaO0o1Wu5Xe2wxlBd6VngLd
Uxe+vvxrwxoiehQrYb3Cn156WjGCAaUwggGhAgEBMIHAMIG5MQswCQYDVQQGEwJaQTEVMBMG
A1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEaMBgGA1UEChMRVGhh
d3RlIENvbnN1bHRpbmcxKTAnBgNVBAsTIFRoYXd0ZSBQRiBSU0EgSUsgMTk5OC45LjE2IDE3
OjU1MTYwNAYDVQQDEy1UaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgUlNBIElzc3VlciAxOTk4
LjkuMTYCAntVMAkGBSsOAwIaBQCgfTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw05OTAyMTcxNDIyMjZaMB4GCSqGSIb3DQEJDzERMA8wDQYIKoZIhvcNAwIC
ASgwIwYJKoZIhvcNAQkEMRYEFLmBoFSHIu4vOYwO6vhluREwmG7wMA0GCSqGSIb3DQEBAQUA
BEDjh7h195F39cQU+owGvsNgLOtOcxoxhWnOPOg3YPFLh6nnhGoDi+ZFv9T5qhwOzB81Xnbc
Vsax7sG79djFKCjI
==============msF7B30E07CF19397C51080C21==
------------------------------
From: "Scott Berg" <[EMAIL PROTECTED]>
Subject: Re: Barcodes
Date: Wed, 17 Feb 1999 09:02:28 -0600
I used to write the software for decoding bar codes. There are industry
standards describing how the codes work.
UPC codes (the kind on consumer products) are regulated by the Uniform Code
Council. Try:
http://www.uc-council.org/ucchp.htm
Another big trade group is AIM. They sell the standards but have a good web
site at: http://www.aimusa.org/
You might want to review the I-2-of-5 code since it is much easier to
understand than UPC and has many of the same basic concepts. That
symbology is used on large shipping cartons (check your local grocery
store). The other really popular one is Code-30 which can encode alphabetic
as well as numeric information.
Hope this helps!
Scott
------------------------------
From: "Scott Berg" <[EMAIL PROTECTED]>
Subject: Re: Barcodes
Date: Wed, 17 Feb 1999 09:02:28 -0600
I used to write the software for decoding bar codes. There are industry
standards describing how the codes work.
UPC codes (the kind on consumer products) are regulated by the Uniform Code
Council. Try:
http://www.uc-council.org/ucchp.htm
Another big trade group is AIM. They sell the standards but have a good web
site at: http://www.aimusa.org/
You might want to review the I-2-of-5 code since it is much easier to
understand than UPC and has many of the same basic concepts. That
symbology is used on large shipping cartons (check your local grocery
store). The other really popular one is Code-30 which can encode alphabetic
as well as numeric information.
Hope this helps!
Scott
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: More Security for Single-DES?
Date: Wed, 17 Feb 1999 16:02:48 GMT
fungus <[EMAIL PROTECTED]> wrote, in part:
>DESX is only secure against brute force attacks, it has very little
>extra strangth against differential cryptanalysis. Banks tend to
>send a lot of very similar messages, perfect for a differential
>cryptoanalyser...
Of course: if one bit is different between two plaintext blocks, the
same will be true of the DES input - and the same bits will be
different in the output as in the ciphertext.
>Having said this, DESX with frequent key changes should be as secure
>as Triple DES.
Hmm. In that case, I may have hit on something, since I've made the
whitening part of the key into a changeable IV.
John Savard
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: More Security for Single-DES?
Date: Wed, 17 Feb 1999 16:06:54 GMT
[EMAIL PROTECTED] (Terry Ritter) wrote, in part:
>That is the claim for DESX. But DESX is fairly well known, and has
>been an option for years. So why are the bankers going to Triple-DES
>instead of DESX? I *know* they hate tripling their encryption
>overhead....
Well, I can't speak for the banks (and the other reply pointed out a
limitation on DESX that I hadn't thought of), but I simply took the
claim for DESX as a given - and so, when I saw my original line of
thought was flawed, but that I could modify it to make use of the
principle behind DESX (which I acknowledged by name), I thought that I
had found something useful enough to be worth mentioning.
John Savard
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Block ciphers vs Stream Ciphers
Date: Wed, 17 Feb 1999 16:20:37 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
>John Savard wrote:
>> A stream cipher can only be used as a stream cipher, while it is very
>> easy to make a secure stream cipher out of a secure block cipher.
>I think it's obvious that a stream cipher can also be used as a block
>cipher. Then you stick in the word "secure"; well, security of any
>form of encryption is a separate matter from whether it is a stream
>or block cipher or something else.
An _impure_ stream cipher can be used directly as a block cipher, but
a much less secure one, by holding the stream cipher part static.
Also, any stream cipher can be used as a block cipher on large blocks,
by running it over the block.
While you are right that security is a separate issue - either kind of
cipher can be secure or insecure - what I'm claiming is this, and it
seems like you've missed it:
The *easy, convenient, and obvious* methods of changing stream and
block ciphers to ciphers of the other class
do not cause a loss of security when applied to block ciphers to
change them to stream ciphers, but
tend to cause a rather drastic loss of security when applied to stream
ciphers to change them to block ciphers.
And this, an aspect of the greater _versatility_ of block ciphers, is
to my mind the only legitimate reason for their fashionability
compared to stream ciphers. Block ciphers can produce equivalently
secure stream ciphers through OFB and counter mode. And applying this
transformation to a block cipher doesn't require a great deal of
thought or care.
Converting a stream cipher to a block cipher is a much trickier
business. Stream ciphers derive much of their strength from their
constantly changing nature, but this also means that a stream cipher
can, I believe, offer more security per unit of computational effort
than a block cipher. This is perhaps why block ciphers only came into
their own when computing power became really cheap.
John Savard
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Cyclic attack on RSA
Date: Wed, 17 Feb 1999 15:20:17 GMT
In article <OUc1N0eW#GA.189@upnetnews03>,
"HypSoft" <[EMAIL PROTECTED]> wrote:
> Does anyone have any information on the "cyclic attack" on the RSA
> algorithm, where encryption muliple times reverts to the original message.
> I had seen an article in an issue of Mathematics Magazine on this topic.
Yes.
The attack is hopelessly impractical. Forget about it for anything larger
than 256 bit keys. It can be shown to be equivalent to the P-1 factoring
attack. See my forthcoming article with R. Rivest (probably to appear
in J. Cryptology on this subject).
Here is the gist of a simple, group-theoretic argument. For cycling to succeed
the order of e mod lambda(N) must be reasonably small.
We are looking for p (say) with N = pq. suppose r is a moderately large prime
(100-200 bits) dividing LCM(p-1, q-1). wlog suppose r | p-1, so p-1 =
Rr. if r divides ord(e) mod lambda(N), the the order of e is at least r,
making the order large and cycling attacks out of reach. Now suppose r does
NOT divide ord(e) mod lambda(N). It follows immediately that e must be an
r'th power mod lambda(N). There are no more than r such integers and the
probability that e is one of them is less than r/lambda(N). It is easy to
show that r < sqrt(N/4) and that lambda(N) > r sqrt(N), so the chance that e
is an r'th power is no more than 1/(4r). This is vanishingly small.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
Date: Wed, 17 Feb 1999 09:58:46 -0500
From: DM Lanza <[EMAIL PROTECTED]>
Subject: Re: New high-security 56-bit DES: Less-DES
[EMAIL PROTECTED] wrote:
> In article <7a2hpk$cih$[EMAIL PROTECTED]>,
> "lyal collins" <[EMAIL PROTECTED]> wrote:
> > >For M=14, Alice should take approximately one minute to solve the
> > >14-bit problem, while EFF's DES Cracker (a powerful DES cracker in
> > >hardware) would take approximately 75 years to solve the 70-bit
> > >problem. To compare, the EFF DES Cracker would take approximately 40
> > >hours for the usual 56-bit DES key.
> >
> > These would seem to impose an upper limit of around 60 decrypted received
> > messages per hour - provided that machine isn't used for anything else.
>
> This is true. Note however that the expected Pentium run-time is perhaps
> one-tenth of that (8,000 DES one-block decryptions). Further, as I wrote in
> the message, Less-DES is a special case of the M-DES protocol -- which allows
> the definition of an "unknown-key" for those 14-bits and does not impose a
> new "key-discovery" task for every message. Please, see the M-DES protocol
> definition and key-reusage discussion in
> http://www.mcg.org.br/unicity.htm#5.2
>
> An important point is that (56+M)-bit key-lifetime in M-DES does not depend
> on usage (ie, number or length of messages sent) but on time, so that Bob and
> Alice can leverage Alice's discovery burden over many messages (not just
> one).
>
This leverage principle applies to the attacker as well. Thus recycling
auxilliary information is probably not going to be worth it. In the limit, where
there is a unique piece of auxilliary information discovered once, the situation
reduces to pure 56-bit DES.
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Telephone Encryption
Date: Wed, 17 Feb 1999 17:00:22 GMT
Reply-To: [EMAIL PROTECTED]
Is there anything commercially available to the consumer for creating
secure telehone conversations anywhere that the correspondents have
the capability?
IOW, is there a secure public key telephone encryption system
available that hooks up to standard telephone equipment?
Bob Knauer
"Towering genius disdains a beaten path. It seeks regions hitherto
unexplored. It sees no distinction in adding story to story, upon
the monuments of fame, erected to the memory of others. It denies
that it is glory enough to serve under any chief. It scorns to tread
in the footsteps of any predecessor, however illustrious. It thirsts
and burns for distinction; and, if possible, it will have it, whether
at the expense of emancipating slaves, or enslaving free men."
-- Abraham Lincoln
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: encryption debate
Date: Wed, 17 Feb 1999 09:42:45 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> On Tue, 16 Feb 1999 20:17:59 -0600, [EMAIL PROTECTED] (wtshaw) wrote:
>
> >> We all realize that the Constitution can never be properly restored.
> >> That is why the only solution to this nightmare is secession.
>
> >What makes you think that our local gaggle of political geese have more
> >sense than those somewhere else?
>
> Local political geese can more easily have their goose cooked by the
> local citizens they work for.
Come to think of it, our town's police chief just got canned. I suppose
that defeats my argument partly.
>
> Democracy only works at the local level. As soon as politicians become
> distant, demagoguery sets in because there is nothing citizens can do
> about it.
The more distant they are the more that their decisions tend to be
ignored. There are occasions where a local official can be told that
certain decisions are out of their jurisdiction. One horse towns can be
ride for you or against you, for no good reason.
>
> >At least, when most of them are in a
> >highly decorated place, inside the beltway, they are easier to keep an eye
> >on, and have difficulty in directing enforcing wild notions in the
> >hinterlands.
>
> Politicians are much easier to keep an eye on when they are local.
Ever seen a local feud? This is when two or more major forces in a
community square off against each other. It gets personal and dirty.
>
> >Even though not in the realistic cards, we here in Texas do reserve the
> >treaty right to divide into six different states and get ten more
> >senators.
>
> Secession is much easier and much better.
>
As Tweety would say, "I don't know about that." It would depend lots on
who set the terms. Some people feel that the Civil War was partly about
the right of states to go their own way. Fine legal details are a bit
murky there, especially during the reconstruction period. I'm old enough
to have visited extensively with people who lived in that period; it was
not pretty.
--
A much too common philosophy:
It's no fun to have power....unless you can abuse it.
------------------------------
From: Dennis Suchta <[EMAIL PROTECTED]>
Subject: Re: encryption debate
Date: Wed, 17 Feb 1999 07:18:25 -0800
There is no common law right but that dates from a time of communal
living where the concept was not commonly accepted. Times change so
does he law.
Dennis
Michael Sierchio wrote:
> Dennis Suchta wrote:
> >
> > "secure in person..." sure sounds like a right to privacy to me.
>
> Knauer is correct in stating that there is no common law right
> to privacy. That's why Amendments IV and IX are significant.
------------------------------
From: "Peter K. Boucher" <[EMAIL PROTECTED]>
Subject: Re: More Security for Single-DES?
Date: Wed, 17 Feb 1999 10:21:39 -0700
[EMAIL PROTECTED] wrote:
>
> Here is a description of a block cipher mode for DES that appears to
> increase security at no significant computational cost.
>
> Generate a 64-bit random value, call it T.
>
> Encipher it using K1, and transmit the result.
>
> For every block of the message, first XOR the plaintext block with T, then
> encrypt it using K2 and transmit it, then increment T.
Instead of incrementing T, how about using T as the seed for a PRNG?
Or how about making T a 256-bit value, use it as a key for RC4, encrypt
the plaintext with RC4, encrypt the result with DES K2, and encrypt the
result of that with RC4.
C = RC4_T(DES_K2(RC4_T(P)))
Somewhere along the route from your original suggestion, past the PRNG,
and arriving at 256-bit RC4, I suspect the line of unexportable multiple
encryption has been passed.
Maybe if you just pre-encrypt with 256-bit RC4 and then append the RC4
key to the result, before post-encrypting with DES:
C = DES(RC4_T(P) || T)
This last would be particularly strong in PCBC mode, and I don't know
what your chances are of getting mass-market approval for such a beast
(some 56-bit algorithms are more equal than others).
--
Peter
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Crossposted-To:
sci.skeptic,sci.philosophy.meta,sci.psychology.theory,alt.hypnosis,sci.logic
Subject: Re: Randomness based consciousness?. (Was: Re: *** Where Does The Randomness
Come From ?!? *** )
Date: Wed, 17 Feb 1999 17:37:07 GMT
Reply-To: [EMAIL PROTECTED]
On Wed, 17 Feb 1999 12:57:41 GMT, [EMAIL PROTECTED] wrote:
>Isn't random such a fantastic word?
Yep.
Berry's Paradox: "Randomness cannot be described".
Bob Knauer
"Towering genius disdains a beaten path. It seeks regions hitherto
unexplored. It sees no distinction in adding story to story, upon
the monuments of fame, erected to the memory of others. It denies
that it is glory enough to serve under any chief. It scorns to tread
in the footsteps of any predecessor, however illustrious. It thirsts
and burns for distinction; and, if possible, it will have it, whether
at the expense of emancipating slaves, or enslaving free men."
-- Abraham Lincoln
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: New high-security 56-bit DES: Less-DES
Date: Wed, 17 Feb 1999 17:40:39 GMT
In article <[EMAIL PROTECTED]>,
DM Lanza <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
> > In article <7a2hpk$cih$[EMAIL PROTECTED]>,
> > "lyal collins" <[EMAIL PROTECTED]> wrote:
> > > >For M=14, Alice should take approximately one minute to solve the
> > > >14-bit problem, while EFF's DES Cracker (a powerful DES cracker in
> > > >hardware) would take approximately 75 years to solve the 70-bit
> > > >problem. To compare, the EFF DES Cracker would take approximately 40
> > > >hours for the usual 56-bit DES key.
> > >
> > > These would seem to impose an upper limit of around 60 decrypted received
> > > messages per hour - provided that machine isn't used for anything else.
> >
> > This is true. Note however that the expected Pentium run-time is perhaps
> > one-tenth of that (8,000 DES one-block decryptions). Further, as I wrote in
> > the message, Less-DES is a special case of the M-DES protocol -- which
allows
> > the definition of an "unknown-key" for those 14-bits and does not impose a
> > new "key-discovery" task for every message. Please, see the M-DES protocol
> > definition and key-reusage discussion in
> > http://www.mcg.org.br/unicity.htm#5.2
> >
> > An important point is that (56+M)-bit key-lifetime in M-DES does not depend
> > on usage (ie, number or length of messages sent) but on time, so that Bob
and
> > Alice can leverage Alice's discovery burden over many messages (not just
> > one).
> >
>
> This leverage principle applies to the attacker as well.
No -- not at all. The attacker has NO leverage because he does NOT know the
56-bit shared-secret.
This defines different time scales to discover the full (56+M)-bit key --
even considering widely different resources. In essence the key-lifetime,
where you consider a threat model and define how long can a key will "live"
in that situation for a given probability of discovery. For the EFF DES
Cracker, the key half-life (ie, 50% probability of discovery) is 75 years for
M=14 in M-DES.
Cheers,
Ed Gerck
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
** 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
******************************
