Cryptography-Digest Digest #481, Volume #11 Tue, 4 Apr 00 01:13:01 EDT
Contents:
Re: novice in crypting ("Dan Coyle")
Re: GSM A5/1 Encryption (Tom St Denis)
Re: Key exchange using Secret Key Encryption ([EMAIL PROTECTED])
Re: Massey-Omura protocol & ECC ([EMAIL PROTECTED])
Re: NSA ([EMAIL PROTECTED])
Keys in blowfish ("Joey Moose")
Re: Key exchange using Secret Key Encryption ("Lyalc")
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Anthony Stephen Szopa)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Anthony Stephen Szopa)
Re: GSM A5/1 Encryption (David A Molnar)
Re: I will make ANY software for ANYBODY (David A Molnar)
Re: The lighter side of cryptology (David A Molnar)
----------------------------------------------------------------------------
From: "Dan Coyle" <[EMAIL PROTECTED]>
Subject: Re: novice in crypting
Date: Mon, 3 Apr 2000 22:30:24 -0500
Handbook of Applied Cryptography, (by Alfred J. Menezes, Paul C. van
Oorschot, and Scott A. Vanstone), is also a good book, it has something for
everybody. Math skills are pretty much a requirement. But cryptography
requires more creativity than anything. The book also covers Pseudo Random
Number Generators, a big plus in my book. Pseudo Random Number Generators
and Cryptography are interconnected in many ways.
As for the XOR usage, just think of it this way. Let's Xor A and B, for each
Bit in B, that has a value of 1, switch the value of the bit in the same
location, in A, and place that bit in the result. Which, by itself isn't
much, but notice that if you do the same operation, with the same B, I.E. (A
Xor B Xor B) you get A. So think of it this way, Take a message, and Xor
each Byte in the message by a number, it changes each byte to a different
number, and to get the original message back, just Xor each byte of the
ciphertext by the same number, then you will get your original message back.
Thing is if you use the same number over and over again, all you have to do
to break it is Xor it by all possible bytes, which can be done with a
maximum of 256 tries. Now start thinking about the Pseudo Random Number
Generator, and how it can reproduce the same series of, near, random numbers
using the same Seed. That's when you start needing the Good Pseudo Random
Number Generators.
Actually DES would be a good algorithm to start with, then 3DES. It's a
basic algorithm, and it's covered in a lot of texts.
DC
"Lionel Firmery" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi every body!!!
>
> I'm a novice in the great domain of crypting. Can someone give me sites
> for helping me in starting?? I'm currently making a crypting program (in
> C), but i don't know very far the XOR usage...
>
> many thanks!!
>
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: GSM A5/1 Encryption
Date: Tue, 04 Apr 2000 03:34:49 GMT
Matt Linder wrote:
>
> I am new to this group, but enjoy reading it. I also like the humor :)
> I know just enough about cryptology to know that most of it is over my
> head.
Bah just submerge yourself. Most of the stuff going on here is not that
advanced... :(
> I am into cell phones, and I know that the days of the old analog FM
> phones are gone, replaced by the digital guys.
> My question is how difficult is it or would it be to decrypt (in real
> time) the over the air voice traffic in GSM (and TDMA) that have been
> encrypted using the A5/1 stream cypher?
Not very.
> I have done some research on the internet, and have found conflicting
> information. some make it sound like its not so hard, but others make
> it sound almost impossible (especially in real time) I think the latter
> is the general consensus.
> My naive understanding is that with a 64 bit key, it would take forever
> to try each key.
> What is the truth?
Truth is very real attacks with O(2^40) exist and probably much lower.
There is an attack given two large hard disks you can find the key in
seconds. But that's very unpractical for the avg joe. Doing O(2^40) of
A5/1 will take a while, but is not impossible.
> I have seen some ads from companies like G-com in new york that
> advertise GSM intercept equipment for sale (to law enforcement only of
> course !)
> P.S. Some people imply that the NSA made it weak on purpose, but after
> doing some research it sounds like it would be difficult even for
> them. Do you think they have a machine that can do it?
> thanks.
Nope. The avg joe can decrypt A5/1 encrypted messages in a matter of a
week or so at the most. It's just not a secure cipher.
I think it's www.iyj.com or something that talks about it in more
detail.
Tom
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Key exchange using Secret Key Encryption
Date: Tue, 04 Apr 2000 03:32:37 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
>
> That is a fair question to ask (at least from a novice), but as you
> probably have seen from the replies, nobody knows a way to do this.
>
> In fact, even _with_ public-key methods, to prevent a
> man-in-the-middle attack the normal practice is to use another
> channel, which does not have to be secret, but which has to be
> resistant to tampering, to exchange key certificates: signed documents
> from a trusted authority indicating that a given public key actually
> belongs to a given party.
>
> However, some protocols have been proposed that obtain resistance to a
> man-in-the-middle attack in other ways than by using another channel
> for certificates, so if you relax your conditions to allow public-key
> techniques, there *might* be something that would meet your other
> requirements. (The ones I remember seeing, though, only make MITM
> harder, not impossible.)
>
> If there were a way to do this, it would revolutionize cryptography,
> but this is generally felt (although it has not been proven) to be
> impossible in principle.
>
> John Savard (jsavard<at>ecn<dot>ab<dot>ca)
> http://www.ecn.ab.ca/~jsavard/crypto.htm
>
Cryptography certainly have a dark past Mr Savard, and thank you very
much for your reply.
>From the replies that I have gotten it seems that there are actually
two issues involved. One is that of the security of the messages, and
the other is that of the authentication of the players.
I am now considering allowing a Public Key Encryption to be allowed
into the scenario but I could not yet formalize the scenario. I am
considering the Massey-Omura protocol with Elliptic Curve Cryptography.
Maybe I am not reading it right but from Mike Rosing's book it would
seem the Massey-Omura protocol would make MITM impossible. Am I
mistaken ?
Petang
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Massey-Omura protocol & ECC
Date: Tue, 04 Apr 2000 03:39:14 GMT
In article <[EMAIL PROTECTED]>,
Mike Rosing <[EMAIL PROTECTED]> wrote:
> I believe you are correct in that it is not patented under ECC. Public
> domain ECC versions have been around for several years. Given the way
> the US patent office works, this doesn't mean much. But chances are
> good
> you can use it without infringing on what patents are there.
>
> Patience, persistence, truth,
> Dr. mike
>
Thank you Dr. Mike. I presume you must be Mike Rosing, the author of
the book Implementing Elliptic Curve Cryptography ?
May I ask your opinion in the following matter ?
In another thread in sci.crypt I have ben asking for a method of key
exchange using only Secret Keys. From the response that I have been
receiving It would seem that the there seem to be no way of doing that
with only secret keys.
I have copied below a posting that I made in reply to John Savard
comment.
I am now considering allowing a Public Key Encryption to be allowed
into the scenario but I could not yet formalize the scenario. I am
considering the Massey-Omura protocol with Elliptic Curve Cryptography.
Maybe I am not reading it right but from Mike Rosing's book it would
seem the Massey-Omura protocol would make MITM impossible. Am I
mistaken ?
Would you mind adding you comment to this ?
Petang
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NSA
Date: Tue, 04 Apr 2000 03:52:47 GMT
In article <
[EMAIL PROTECTED]
om>,
Johnny Bravo <[EMAIL PROTECTED]> wrote:
> On Mon, 03 Apr 2000 23:55:31 GMT, [EMAIL PROTECTED] wrote:
> >I cannot tell if you are just making a funny.
>
> It was a joke, but it sounds so possible I'd bet $5 that there are
> government agents using computer assisted search to read USENET.
>
I'd place a side bet that you'd win your bet.
Supposedly, the UK's Defence Evaluation &
Research Agency maintains the last 90 days of
usenet messages (which are meant to be
analyzed by computers and then humans if
necessary). It's illegal for the NSA to spy on
Americans living in the U.S., and, thus, it
might be illegal for them to gather potentially
incriminating intel from or about Americans
here who are using the Internet, usenet, etc.
Perhaps Britain, e.g., does collect the intel and
shares some of its findings with the U.S. Also,
to help cover its ass for legal reasons, the U.S.
government might gather intel from usenet,
etc. through non- official channels.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Reply-To: "Joey Moose" <[EMAIL PROTECTED]>
From: "Joey Moose" <[EMAIL PROTECTED]>
Subject: Keys in blowfish
Date: Mon, 3 Apr 2000 21:17:13 -0700
I am looking at using blowfish to encrypt information within a Web page that
is being transferred between servers. Do I need to worry about using
different keys for each message I send? My guess is that a different key
should be used each time to avoid someone comparing two messages...
Thank-you,
Tj (newbie extreme)
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: Key exchange using Secret Key Encryption
Date: Tue, 4 Apr 2000 14:12:42 +1000
Assuming you are comfortable with the need to securely and reliably
distribute at least one master key (either Symmetric or Public). then it is
a trivial process to use existing toolsets or knowledge to implement
one-time keys, using Secret keys, for bulk encryption or integrity (via
keyed hash or industry standard MAC functions).
If you don't want to invest in secure distribution of keys, then give up
now.
If you do, then ensure the root CA public key gets distributed and cannot be
replaced, or ensure a Secret master key is distributed, along with reliable
versions of software to store, process and manage these keys.
Lyal
John Savard wrote in message <[EMAIL PROTECTED]>...
>[EMAIL PROTECTED] wrote, in part:
>
>>I am looking for a method of key exchange that only involves secret key
>>encryption. The method should also be immune to man-in-the-middle
>>attack. The scenario I am looking at is described below.
>
>>Alice and Bob are complete strangers and have only one channel of
>>communication. The Channel being the Internet. They only have at their
>>disposal a secret key encryption method. For the sake or argument, this
>>method is Bob Schnier's Twofish. It can be assumed that Alice and Bob
>>are both connected to the internet concurrently, so multiple pass
>>protocals can be used. How can Alice and Bob start communicating and
>>protect their messages.
>
>That is a fair question to ask (at least from a novice), but as you
>probably have seen from the replies, nobody knows a way to do this.
>
>In fact, even _with_ public-key methods, to prevent a
>man-in-the-middle attack the normal practice is to use another
>channel, which does not have to be secret, but which has to be
>resistant to tampering, to exchange key certificates: signed documents
>from a trusted authority indicating that a given public key actually
>belongs to a given party.
>
>However, some protocols have been proposed that obtain resistance to a
>man-in-the-middle attack in other ways than by using another channel
>for certificates, so if you relax your conditions to allow public-key
>techniques, there *might* be something that would meet your other
>requirements. (The ones I remember seeing, though, only make MITM
>harder, not impossible.)
>
>If there were a way to do this, it would revolutionize cryptography,
>but this is generally felt (although it has not been proven) to be
>impossible in principle.
>
>John Savard (jsavard<at>ecn<dot>ab<dot>ca)
>http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Mon, 03 Apr 2000 21:36:23 -0700
"Trevor L. Jackson, III" wrote:
>
> Anthony Stephen Szopa wrote:
>
> > Now, for any of those interested, Version 4.3 will be available
> > very soon. Here are the additions to OAP-L3 in Version 4.3:
> >
> > 1) you will get two more random number generators: they are
> > exactly the same as the current one where only MixFile1 is
> > rotated except that PRNG2 will only rotate MixFile2, and PRNG3
> > will only rotate MixFile3.
> >
> > 2) you will get several other processes:
> >
> > you will be able to scramble every subsequent set of 14 arrays in a
> > MixFile to any one of 14! sequences
> >
> > you will be able to reverse the order of each element in each array
> > in a MixFile
> >
> > you will be able to reverse the byte sequence of an entire MixFile.
> > (Keep in mind that each MixFile is compressed using BCD so each
> > byte contains information for two digits.)
> >
> > you will be able to reverse the array sequence of an entire MixFile
> >
> > you will be able to add 1 - 9 to each element in all arrays in a
> > MixFile
> >
> > you will be able to shift all elements in each array in an entire
> > MixFile
> >
> > These additional processes will greatly increase the possibilities
> > of ordering the MixFiles thus making the MixFiles that much more
> > difficult to determine
>
> But according to your advertising the older product provided "absolute
> privacy". Why would anyone want more than that?
>
> >
> >
> > The additional PRNGs will provide more random numbers from which
> > to create the OTPs, again making predicting the OTPs that more
> > improbable.
> >
> > (I like to say that much more impossible.)
>
> If your claim that much more is possible is true than it must be the case that
> there are very many holes in your absolute privacy. One can only improve an
> imperfect product.
>
> Please stop posting in sci.crypt until you believe your product does not need
> more strength.
As you may be aware, there is an extremely large key space
available with OAP-L3. Adding a few more processes is
tantamount to approximately doubling the "through put"
to this very large key space. It does make determining
the key phenomenally that much more difficult. No one
has to use them. They are simply made available. Their use
is up to the user. And my position remains the same.
Address the software theory and processes and procedures with
factual support. Are you not up to it?
You should spend more time devising your own encryption method
and impress us with that. You are not very convincing telling
me of what I should do.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Mon, 03 Apr 2000 21:37:37 -0700
lordcow77 wrote:
>
> >
> >The digits themselves are enough.
> >
>
> That's only if he gives you the real digits and then doesn't lie
> about them later. Insist that he make a public bitstring
> committment of the digits and the complete initial keystate of
> his algorithm (sufficient to recreate the digits that he
> provides you with, as well as the digits that will be checked),
> so that he does not have the ability to, say, substitute output
> from RC4 or a block cipher in OFB mode as the output of his own
> algorithm.
>
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
> The fastest and easiest way to search and participate in Usenet - Free!
What Mr. Huuskonen is saying is that you should put it to rest.
My suggestion is acceptable to him.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: GSM A5/1 Encryption
Date: 4 Apr 2000 04:52:56 GMT
Matt Linder <[EMAIL PROTECTED]> wrote:
> My question is how difficult is it or would it be to decrypt (in real
> time) the over the air voice traffic in GSM (and TDMA) that have been
> encrypted using the A5/1 stream cypher?
Do a web search for "Fast Software Encryption 2000". On the program is
a paper by Biryukov, Shamir, and Wagner on a "Real-Time Cryptanalysis
of the Alleged A5/1 Stream Cipher." There is some information about it
online at
http://cryptome.org/a51-bs.htm (preliminary draft with Biryukov and
Shamir only; I don't know what Wagner
added, but am confident it was cool)
http://cryptome.org/a51-crack.htm (discussion)
The preliminary version required 128 MB RAM and 2 73 GB hard disks.
> My naive understanding is that with a 64 bit key, it would take forever
> to try each key.
Marc Briceno, Ian Goldberg, and David Wagner announced last year (or is
it the year before?) that they had discovered that in fact only a
shorter key was _actually_ being used by the GSM phones. Even the ones
sold in Western Europe. What happened is that 64 bits of key material
are used, but the top bits set to 0s.
Unfortunately I don't recall how many 0s were set right now. I have a
vague recollection of 16, which would leave 48 real key bits.
> P.S. Some people imply that the NSA made it weak on purpose, but after
> doing some research it sounds like it would be difficult even for
> them. Do you think they have a machine that can do it?
> thanks.
I don't know what happens with standards committees and implementations.
Certainly people seem to be quite capable of shooting themselves in the
foot both with and without the help of the NSA. The "top bits all set to
0" does look pretty suspicious.
As for your other question, I think it would be prudent to assume that
even if the NSA did not previously posess a real-time A5/1 cracking
machine, in the wake of the above result, they have one now. Plus I
personally believe that they had one before, anyway.
Thanks,
_David
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: I will make ANY software for ANYBODY
Date: 4 Apr 2000 04:42:00 GMT
Paul Schlyter <[EMAIL PROTECTED]> wrote:
> Perhaps the ultimate porting project would be to port Win-2000 to
> a Turing machine.... :-)))))))))))))))))
Only if it is an object-oriented Turing machine. :-)
ObCrypto : Does there exist a general construction which will
allow me to take a Turing machine, and then create a "blinded" Turing
machine -- such that
* L(blinded TM) = L(TM)
I can give you a description (5-tuple) of the blinded TM and
* You can determine whether an input is accepted or rejected by
said blinded TM
* You gain no information about the transition table of the
original TM
* You can do no better than guessing to determine in advance
whether a given input will be accepted by the blinded TM
There was a recent thread on comp.theory about determining if two
NDFAs are equivalent which seemed somewhat relevant. The problem there
was that they were considering whether you could determine if two NDFAs
are equivalent given only black-box access to the NDFA. Here you might
get to see the transition table as well.
(why? don't want to decompile Windows 2000 for Turing Machines, do we?
that's valuable intellectual property!)
Thanks,
-David
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: The lighter side of cryptology
Date: 4 Apr 2000 04:32:34 GMT
[EMAIL PROTECTED] wrote:
> DES users do it in blocks and chains.
> (Markov also did it in chains.)
said about a friend of mine
"She's whispering sweet DES in his ear..."
------------------------------
** 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
******************************
