Cryptography-Digest Digest #109, Volume #12 Mon, 26 Jun 00 12:13:01 EDT
Contents:
Re: software protection schemes (Mark Wooding)
Re: software protection schemes (Runu Knips)
Re: DES and questions (Eric Young)
SSL Encryption via Diffe-Hellman or DSA? (Jeffrey Parker)
Des breaking service ? ("Erik Olssen")
DES Weakness ? ("Erik Olssen")
Re: CRC-64 and 128 - Generator Polynomials? (Mack)
Re: CRC-64 and 128 - Generator Polynomials? (Mack)
Re: Comments/analysis requested ([EMAIL PROTECTED])
Re: Encryption on missing hard-drives ("Tony T. Warnock")
Re: DES Weakness ? (Mark Wooding)
Re: Quantum computing ([EMAIL PROTECTED])
Re: Idea or 3DES (dexMilano)
Re: Idea or 3DES (dexMilano)
Re: TEA-wmlscript question (dexMilano)
Re: Weight of Digital Signatures ("Trevor L. Jackson, III")
After the FIPS140-1 randomness tests for DOS (command line)... ("Sam Simpson")
Re: TEA-wmlscript question (Mark Wooding)
Re: After the FIPS140-1 randomness tests for DOS (command line)... (Mark Wooding)
Re: newbieish question ("Douglas A. Gwyn")
Re: How Uncertain? ("Douglas A. Gwyn")
Re: Quantum computing ("Douglas A. Gwyn")
Re: DES Weakness ? (Pascal JUNOD)
Re: Idea or 3DES (Simon Johnson)
Re: Key agreement in GSM phones (David A. Wagner)
Re: DES Weakness ? (Mark Wooding)
Surrendering Keys, I think not. (Simon Johnson)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: software protection schemes
Date: 26 Jun 2000 12:39:00 GMT
lament <[EMAIL PROTECTED]> wrote:
> In article <g4u35.30$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] says...
>
> > Almost any software protection scheme running on the PC suffers from
> > this same vulnerability. If the attacker finds the magic bit that
> > finally authenticates the user, the software protection will not
> > work.
>
> Big "If."
Actually, not a terribly large `if'. In fact, it's an `if' which looks
a lot more like a `when'.
> Given that billions of instructions transpire, how do you know which
> one(s) are the one?
By analysing the code and using intelligence?
> > Any scheme that is deliberately and perversely complex is likely to
> > be buggy and slow and still subject to attack by automated
> > tools. Dongle protection scheme fall into this category.
>
> "...deliberately and perversely complex" seems to be a necessary
> condition of encryption.
This perception is false. RC4, RC5 and Blowfish are extremely simple to
think about and implement. Public key systems are an even better
demonstration of the falseness of your perception. Diffie-Hellman key
exchange, to pick one example, entirely lacks complexity, deliberate,
perverse or otherwise.
> Is all encryption code "buggy and slow"?
No. Not at all.
> > Most dongle protection scheme have been broken.
>
> The CAD industry uses dongles.
I fail to see the relevance of this statement. The fact that dongles
are still used implies that marketting is more effective that fact, and
this isn't news.
> > Good, reliable software protection in the PC environment is a myth.
>
> I guess this depends on what you mean by "good," "reliable" and "a myth."
Reaplce `myth' by `fiction'. Choose your own definitions of `good' and
`reliable'.
-- [mdw]
------------------------------
Date: Mon, 26 Jun 2000 14:37:41 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: software protection schemes
lament wrote:
> In article <g4u35.30$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> > [...] If the attacker finds the magic bit that finally
> > authenticates the user, the software protection will not
> > work. Usually it is very easy to find this bit. [...]
>
> Given that billions of instructions transpire, how do you
> know which one(s) are the one?
Ever heard of "debuggers" ? Its not that hard to find the
position where such checks happen. Even if you have no
debugging information. Just track what the app is doing
and with some searching you'll find those places.
You have to be able to read and write assembly, of course.
------------------------------
From: Eric Young <[EMAIL PROTECTED]>
Subject: Re: DES and questions
Date: Mon, 26 Jun 2000 12:50:17 GMT
rick2 wrote:
>
> I have two more questions about implementing DES in a program. (Feel
> free to Dope-Slap(TM) me if these are too close to outright idiotic.)
>
> 1. It turns out that 3-DES is kind of slow, so any speed-up tricks
> would be worth it. So, not very brilliant, but what about 2-DES?
> Would that have a encryption strength of 128 (or should it be 112)
> bits? Geez, that seems pretty strong, no? Especially if people have
> been using only two different keys for 3 rounds of DES, why not just
> do the two with two keys?
I wonder how one does a 'Dope-Slap(TM)' via news :-).
Regarding 2-key vs 3-key, it make no different to encryption performance,
only key-setup, and DES has a very good key-setup vs encrypt ratio
(unlike blowfish). The cost to re-key 3-DES is probably about the same as
the cost to encrypt 24 bytes (if that), while blowfish is ~ to about 4200
bytes. I seem to remember this has been thrash under the title
'key agility' in one of the mailing lists (or was it this news group?).
This can lead to situations where triple DES is faster than blowfish,
eg if one was encrypting 512 byte blocks with a different keys
(ignoring expanded key caching).
eric (it is faster to transmit a single 20 bytes message via modem at
300 baud than 9600 baud due to the modem handshake overheads).
------------------------------
From: Jeffrey Parker <[EMAIL PROTECTED]>
Subject: SSL Encryption via Diffe-Hellman or DSA?
Date: 26 Jun 2000 12:52:51 GMT
Reply-To: [EMAIL PROTECTED]
Hi. I'm trying to get SSL to encrypt via Diffe-Hellman or DSA rather than
RSA. I've downloaded some implementations of ssleay (sslwrap, stunnel)
but can't get either of them to work. Because they're built on the ssleay
engine (which also doesn't work for me) they accept a "-cipher foo"
argument. But no matter what I specify when I try to connect with a DSA
client I get "no shared cipher." The disheartening thing is that none of
these ssleay derivatives complain if I pass them "-cipher bogus." They
apparently just pass the 'bogus' text to the SSL_CTX_set_cipher_list()
library call, which returns 1 no matter what. Has anyone else played with
this? Basically I have an incoming DSA connection connection, so it won't
do RSA. Any thoughts? Thanks. [email preferred].
--
Rick Ennis
voice: 617-354-1800x217
email: [EMAIL PROTECTED]
------------------------------
From: "Erik Olssen" <[EMAIL PROTECTED]>
Subject: Des breaking service ?
Date: Mon, 26 Jun 2000 15:02:51 +0200
Hi
Is there any company out there who has build a des-cracking maschine and
offers to break
56-bit des-keys ?
If anybody know of a way to do that in less than a month please reply !!!
PS ok, i now it is lame questions !!!
Regards Erik
------------------------------
From: "Erik Olssen" <[EMAIL PROTECTED]>
Subject: DES Weakness ?
Date: Mon, 26 Jun 2000 15:07:57 +0200
Hi
Standard des 56bit keys
Is there any known weakness if let say i can "feed" any plain/cipher-data to
encrypt/decrypt
e.g."00 00 00 00 00 00 00 00" or "ff ff ff ff ff ff ff ff ff"
Regards Erik "Crypto-newbee!"
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: CRC-64 and 128 - Generator Polynomials?
Date: 26 Jun 2000 13:22:06 GMT
Mike Rosing [EMAIL PROTECTED]
>Mack wrote:
>> I am looking for some good CRC polynomials for 64, 128, 192, 256 and
>> higher bits. Does anyone have a list of primitive polynomials of those
>degrees
>> mod 2?
>
>You can easily create lists of primitive polynomials. It wouldn't take long
>to modify lots of available code to generate several 1000 per minute.
>
>Patience, persistence, truth,
>Dr. mike
>
>
but narrowing it to which ones are 'good'
1) low degree (not too hard)
2) provide best characteristics (search em all)
is a bit more challenging
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: CRC-64 and 128 - Generator Polynomials?
Date: 26 Jun 2000 13:25:26 GMT
>Mike Rosing [EMAIL PROTECTED]
>>Mack wrote:
>>> I am looking for some good CRC polynomials for 64, 128, 192, 256 and
>>> higher bits. Does anyone have a list of primitive polynomials of those
>>degrees
>>> mod 2?
>>
>>You can easily create lists of primitive polynomials. It wouldn't take long
>>to modify lots of available code to generate several 1000 per minute.
>>
>>Patience, persistence, truth,
>>Dr. mike
>>
>>
>but narrowing it to which ones are 'good'
>1) low degree (not too hard)
sorry should read low number of terms (not hard)
>2) provide best characteristics (search em all)
>is a bit more challenging
>
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Comments/analysis requested
Date: Mon, 26 Jun 2000 13:27:08 GMT
David,
Thanks for the response. I have a couple of questions, though.
[EMAIL PROTECTED] (David A. Wagner) wrote:
> In article <[EMAIL PROTECTED]>,
> Samuel Paik <[EMAIL PROTECTED]> wrote:
> > unsigned long key[16];
> > unsigned long text[16];
> >
> > for (idx = 0; idx < 16; idx++)
> > {
> > unsigned long keyw = key[idx];
> > unsigned long text0 = text[idx];
> > unsigned long text1 = text[keyw&0xf];
> >
> > text[keyw&0xf] = ((text1 & keyw) | (text0 & ~keyw)) + keyw;
> > text[idx] = ((text0 & keyw) | (text1 & ~keyw)) + keyw;
> > }
>
> Thanks for the C code! That's much more understandable.
>
> This cipher appears to be easily breakable, with some known text.
> I strongly recommend to avoid this cipher.
>
> First, note that the least significant bit (LSB) of each of the 16
> words of the ciphertext depend only on the LSB of each of the 16 words
> of the plaintext.
How is the LSB only dependant on the LSB of each of the 16 words of the
plain text? When you add the keyw before writing to the text, wouldn't
that make it dependant on the keyw?
> Second, note that this dependency is in fact affine.
> (The only non-linearity in the above is the carry bits, but there are
no
> carry bits coming into the LSB.) Consequently, given a few dozen
known
> texts, we can find this affine transformation, using Gaussian
elimination.
Unfortunately, I am not usually able to get more that 1 known text for
each password. There are, however, always 64 0xB0 at the end. Also if
in fact the LSB of each word is only dependant on the LSB of each of
the 16 words of the plain text, couldn't the LSB of each word be
determined in 2^16 tries?
>
> Knowing this affine transformation almost gives away the low 4 bits of
> each of the key words, because it tells us how the words are permuted.
> In other words, each key word above induces a swap (i, key[i]&0xf),
> and the composition of these 16 swaps is known. This already gives us
> a lot of information on the key material, and moreover it allows us to
> read the LSB's of any subsequent encrypted traffic.
>
> At this point, any of a number of strategies are available to finish
off
> the attack. For instance, if we know the low 4 bits of each key word
> (64 bits in total), we can break the cipher trivially, since we know
> where all the swaps go. But knowing the permutation above gives a
lot of
> information on those 64 key bits (it gives about 44 bits of
information,
> in particular), so we may be able to just try all the possibilities
> (heuristically, we expect to have to try only 2^20 possibilities).
> That ought to be good enough to break it the rest of the way.
>
Do you know of a website that has info on these techniques, such as
Gaussian elimination?
Thanks, Wayne
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Encryption on missing hard-drives
Date: Mon, 26 Jun 2000 07:56:26 -0600
Reply-To: [EMAIL PROTECTED]
Guy Macon wrote:
> The people who disarm nuclear weapons in the field and the people who
> go into and out of a high security safe aren't the same people.
In this case, they are exactly the same people.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: DES Weakness ?
Date: 26 Jun 2000 14:13:59 GMT
Erik Olssen <[EMAIL PROTECTED]> wrote:
> Standard des 56bit keys
>
> Is there any known weakness if let say i can "feed" any
> plain/cipher-data to encrypt/decrypt e.g."00 00 00 00 00 00 00 00" or
> "ff ff ff ff ff ff ff ff ff"
Yes. Matsui's linear cryptanalysis can recover the key with 2^{48}
known plaintexts. They don't have to be carefully chosen, just
different.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: Quantum computing
Date: Mon, 26 Jun 2000 07:46:49 -0700
My point was that in order to solve an arbitrary NP problem you need a
machine that can compute exponential problems in polynomial time i.e.
something above and beyond a massively parallel computer, which only has
a fixed number of processing elements.
Simon Johnson wrote:
> Hasn't expodential!=p been proven?
>
> Got questions? Get answers over the phone at Keen.com.
> Up to 100 minutes free!
> http://www.keen.com
------------------------------
From: dexMilano <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk,comp.security.pgp.discuss
Subject: Re: Idea or 3DES
Date: Mon, 26 Jun 2000 14:39:33 GMT
In the systema I developed I implemented both of them.
3DES is extremely slow.
IDEA is faster (or better les slower!), and my customer acquires the
patented so...
I liked idea becauseit has a very fast initialisation process.
dex
In article <[EMAIL PROTECTED]>,
jungle <[EMAIL PROTECTED]> wrote:
> Lucks from Fast Software Encryption in 1998 explained that :
>
> - about 2^108 steps are sufficient to break triple DES ...
> - when one concentrates on the number of single DES operations &
assumes the
> other operations to be much faster, 2^90 steps are sufficient ...
>
> IDEA on the other hand needs 2^128 steps ...
>
> therefore,
> - IDEA should be considered extremely more secure than triple DES ...
> - exactly, from 2^38 to 2^20 steps more secure ...
>
> [EMAIL PROTECTED] wrote:
> >
> > In article <[EMAIL PROTECTED]>,
> > jungle <[EMAIL PROTECTED]> wrote:
> > > IDEA ...
> > >
> > > [EMAIL PROTECTED] wrote:
> > > >
> > > > Of the two ciphers IDEA and triple DES, what provides the best
> > security? I
> > > > read somewhere that DES had been broken.
> >
> > FWIW, I disagree with Jungle. My paper PGP DH vs PGP RSA
> > (http://www.scramdisk.clara.net/pgpfaq.html) explains why.
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: dexMilano <[EMAIL PROTECTED]>
Subject: Re: Idea or 3DES
Date: Mon, 26 Jun 2000 14:40:15 GMT
In the systema I developed I implemented both of them.
3DES is extremely slow.
IDEA is faster (or better les slower!), and my customer acquires the
patented so...
I liked idea becauseit has a very fast initialisation process.
dex
In article <[EMAIL PROTECTED]>,
jungle <[EMAIL PROTECTED]> wrote:
> Lucks from Fast Software Encryption in 1998 explained that :
>
> - about 2^108 steps are sufficient to break triple DES ...
> - when one concentrates on the number of single DES operations &
assumes the
> other operations to be much faster, 2^90 steps are sufficient ...
>
> IDEA on the other hand needs 2^128 steps ...
>
> therefore,
> - IDEA should be considered extremely more secure than triple DES ...
> - exactly, from 2^38 to 2^20 steps more secure ...
>
> [EMAIL PROTECTED] wrote:
> >
> > In article <[EMAIL PROTECTED]>,
> > jungle <[EMAIL PROTECTED]> wrote:
> > > IDEA ...
> > >
> > > [EMAIL PROTECTED] wrote:
> > > >
> > > > Of the two ciphers IDEA and triple DES, what provides the best
> > security? I
> > > > read somewhere that DES had been broken.
> >
> > FWIW, I disagree with Jungle. My paper PGP DH vs PGP RSA
> > (http://www.scramdisk.clara.net/pgpfaq.html) explains why.
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: dexMilano <[EMAIL PROTECTED]>
Subject: Re: TEA-wmlscript question
Date: Mon, 26 Jun 2000 14:57:35 GMT
Uhm ....
So I can say that
\phi = a/b where a/b = b/(a+b)
and a, b and the their ratio are integer.
???
SO I think there are some tables anywhere.
Why the number Golden number is so great?
dex
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Mark Wooding) wrote:
> dexMilano <[EMAIL PROTECTED]> wrote:
>
> > I love you guy.
>
> Shh! I told you: not in public!
>
> > Just a question: How can I calculate a golden number (which is the
> > theory)? Have you some reference on the web.
>
> The `Golden number' \phi keeps cropping up in all sorts of interesting
> places in mathematics. \phi is the ratio between the sides of a
> rectangle such that, when a square of side equal to the rectangle's
> longest side is added, the resulting rectangle is similar to the
> original. It appears in the study of the Fibonacci sequence. \phi^2
=
> \phi + 1; 1/\phi = \phi - 1. \phi has the continued fraction 1 + 1/
(1 +
> 1(1 + 1/...)).
>
> That should be enough to let you calculate it. ;-)
>
> -- [mdw]
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Mon, 26 Jun 2000 11:22:12 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Weight of Digital Signatures
Lyalc wrote:
> I know we are close to discussing legal issues, but
> the motive behind the signing is important (e.g. coercion repudiates an
> otherwise genuine signature). Electronically, we can't really detect or
> cater to these sorts of situations - yet.
Are you supposing a signed-under-protest bit?
>
> One day, the rule makers will decide how to handle these ambiguous
> situations.
> In the meantime, we all play elelctronic signatures "by ear"
> Lyal
>
> Robert Stonehouse wrote in message
> <[EMAIL PROTECTED]>...
> >Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >>Robert Stonehouse wrote:
> >>> [EMAIL PROTECTED] (John Savard) wrote:
> >>> ...
> >>> >A law that makes a digital signature "just as binding as one in ink",
> >>> >when it is so much easier to break into someone's house and read their
> >>> >hard drive than forge their signature perfectly makes ordinary people
> >>> >much more vulnerable to forgery than before.
> >>> ...
> >>> The thing that makes an ink signature binding is the fact that it
> >>> was written by the right person. If your bank pays out on a forged
> >>> cheque, saying 'Well, it was a perfect forgery' won't help the bank
> >>> at all. The bank has to make it good to you.
> >>>
> >>> It is hard to imagine how any law authorising digital signatures can
> >>> preserve that protection for bank customers and others who sign
> >>> documents.
> >>
> >>But a cheque forgery has to be ascertained by experts who have to
> >>use judgements and, I believe, don't always have 'absolute' certainty.
> >>So I guess that some parallel mechanism could function.
> >
> >Not necessarily. There can be other ways of showing you didn't sign
> >the document apart from an examination of the document. What matters
> >is whether you signed it or not.
> >
> >The terms of electronic transactions mostly say that, if the bank
> >gets a transaction that satisfies the conditions, it can pay. That
> >is, the electronic details are final.
> >[EMAIL PROTECTED]
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: After the FIPS140-1 randomness tests for DOS (command line)...
Date: Mon, 26 Jun 2000 16:07:33 +0100
Anyone know a download site?
Regards,
--
Sam Simpson
http://www.scramdisk.clara.net/ for ScramDisk hard-drive encryption &
Delphi Crypto Components. PGP Keys available at the same site.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: TEA-wmlscript question
Date: 26 Jun 2000 15:26:57 GMT
dexMilano <[EMAIL PROTECTED]> wrote:
> Uhm ....
> So I can say that
> \phi = a/b where a/b = b/(a+b)
> and a, b and the their ratio are integer.
No. \phi is not an integer: it's an irrational number between 1 and 2.
> SO I think there are some tables anywhere.
Nope, I don't understand this comment.
> Why the number Golden number is so great?
I think the properties I described are enough for starters. If they're
not enough to pique your interest, then you're probably just not a
mathematician.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: After the FIPS140-1 randomness tests for DOS (command line)...
Date: 26 Jun 2000 15:28:11 GMT
Sam Simpson <[EMAIL PROTECTED]> wrote:
> Anyone know a download site?
You could write your own. Catacomb contains FIPS 140-1 randomness
tests, so the hard work's done.
-- [mdw]
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: newbieish question
Date: Mon, 26 Jun 2000 14:42:31 GMT
Benjamin Goldberg wrote:
> I was wondering... are these properties always considered
> important in cryptographic functions?
It's important not to reverse cause and effect.
The actual desired property is that the system's ciphertext
not provide any "handle" for the cryptanalyst to exploit.
A consequence of working toward that is that most binary
stream ciphers do have those properties, but that is not
the primary goal.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: How Uncertain?
Date: Mon, 26 Jun 2000 14:37:53 GMT
Future Beacon wrote:
> ... ASCII is a seven bit code communicated in bytes. About a
> quarter of the text characters end with each of 00, 01, 10, and 11.
Nosirree. Take a large English-language document im ASCII and
count the number of 0 vs. 1 low-order bit. You might be surprised.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Quantum computing
Date: Mon, 26 Jun 2000 14:57:15 GMT
Rob Warnock wrote:
> But in classical error correction, *only* the channel itself is presumed
> to be subject to error. The encoder & decoder elements -- and the
> arithmetic done in them -- are themselves presumed to be error-free.
That's only because in classical error correction, reliability of the
encoder/decoder is not an issue, so only channel noise has to be dealt
with (which includes the error control bits). Why complicate the
analysis
for no purpose?
> So I'm guessing that what Bill sees as the problem is that in a quantum
> computer if you assume "noisy" qubits you must also assume that *all*
> parts of the error correction system are equally noisy, since to preserve
> superposition your error-correction arithmetic must itself also be a
> quantum computation.
Sure.
> That vastly complicates things, ...
That is where I disagree. Classical error correcting codes are not
appreciably complicated when the noise in the error control bits is
part of what is corrected, unless your point of reference is some
overly simplistic model. It is certain that one cannot add qubits
for error control in a quantum computer without including the extra
qubits in the error correction scheme. I assumed (maybe wrongly)
that Bill Unruh was thinking that the error-control bits would be
partitioned apart from the data (and cursor a la Feynman) bits, in
which case there would be the problem he envisioned.
------------------------------
Date: Mon, 26 Jun 2000 17:33:55 +0200
From: Pascal JUNOD <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: DES Weakness ?
This is a multi-part message in MIME format.
==============4753F11E4E0EFA655032E129
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
==============4753F11E4E0EFA655032E129
Content-Type: message/rfc822
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
X-Mozilla-Status2: 00000000
Message-ID: <[EMAIL PROTECTED]>
Date: Mon, 26 Jun 2000 17:32:52 +0200
From: Pascal JUNOD <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Organization: LASEC, EPFL
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.5-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Mark Wooding <[EMAIL PROTECTED]>
Subject: Re: DES Weakness ?
References: <BwI55.7181$[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
> Yes. Matsui's linear cryptanalysis can recover the key with 2^{48}
2^{43} known plaintext-ciphertext pairs are sufficient, in fact. The
average complexity of the attack is estimated to be 2^{43} DES
computations by Matsui, but
it's less in reality. Ongoing research will tell more about this topic
in very few days...
A+
Pascal
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Pascal Junod, [EMAIL PROTECTED] *
* Laboratoire de S�curit� et de Cryptographie (LASEC) *
* ++ 41 (0) 21 693 7617, INR 313, EPFL, CH-1015 Lausanne *
* Route d'Yverdon 25, CH-1028 Pr�verenges, Switzerland *
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
==============4753F11E4E0EFA655032E129==
------------------------------
Subject: Re: Idea or 3DES
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Mon, 26 Jun 2000 08:35:30 -0700
I'm more a fan of idea......
It is optimized against both linear and differential
cryptanalysis where as the original form of DES was only secure
against differential cryptanalysis.
Moreover, IDEA doesn't have any steps that might be troublesome
in software. Even better, all the operations in the F-function
work on 8-bit words, making it easier to implement in less
langaugues such as Basic.
IDEA is faster than Triple-DES, DES is prehaps the securest
cipher on the plannet, i say this because it has the weight of
30-35 years of analysis. Its only flaw, apart from the lack of
security against linear cryptanalysis, is the length of key.
Since we know DES is a long way from being a group, we must
conclude that Triple-DES has much the same cryptographic
properties as DES, making it a secure construction.
IDEA does not have this weight of knowledge behind it. I've read
that it has some impressive mathematics behind it, though i've
never looked into it. Though I like its ideology, i think it is
too new to trust, for situations were maximum security is
essiential.
In conclusion, though Triple-DES is old and clunky, its the best
out there for guaranteed security. If you want a faster,
robuster and newer algorithm, IDEA is the one to go for.
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Key agreement in GSM phones
Date: 26 Jun 2000 08:11:13 -0700
In article <[EMAIL PROTECTED]>, Gerard Tel <[EMAIL PROTECTED]> wrote:
> 1. What protocol is used by the two parties to agree on the
> 64 bit keys used?
The base station and handset share a common key, called Ki. The base
station sends a random challenge to the handset. Both ends compute a
response SRES and a session key Kc from Ki and the challenge using a
symmetric `hashing' algorithm known as A3/A8. The handset sends SRES
back to the base station to authenticate itself. Finally, both sides
use Kc as their A5 key for that call.
> 2. Is the encryption used ONLY on the ether link (between base and
> mobile) or is the data also encrypted during transportation over
> the fiber network?
The A5 encryption is only between the handset and the base station,
so everything else goes in the clear (unless the providers have added
extra encryption through some other mechanism).
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: DES Weakness ?
Date: 26 Jun 2000 16:03:09 GMT
Pascal JUNOD <[EMAIL PROTECTED]> wrote:
> > Yes. Matsui's linear cryptanalysis can recover the key with 2^{48}
>
> 2^{43} known plaintext-ciphertext pairs are sufficient, in fact.
I stand updated. ;-)
-- [mdw]
------------------------------
Subject: Surrendering Keys, I think not.
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Mon, 26 Jun 2000 09:04:47 -0700
It was either here, or in one of the daily newspapers i read a
story about the government wanting the police to be able to
demand the encryption keys for e-mails, files etc.... If it
where so needed in a criminal investigation.
I was wondering how they would ever be able to *prove* that this
key is correct. Since one of the requirements for the AES is
that the output of data encryption produces cipher-text that
cannot be told apart from random data. If some person said the
cipher-text was a message encrypted using an OTP, then the
police must brute-force the underlying algorithm to prove
otherwise.
Like i said, a law of this nature can do nothing except catch
the stupid out. ( Which criminals usally are :) )
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
** 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
******************************
