Cryptography-Digest Digest #140, Volume #12 Fri, 30 Jun 00 05:13:01 EDT
Contents:
Re: When you know the PT is ascii ("Douglas A. Gwyn")
Re: Idea or 3DES (Boris Kazak)
Re: Another chaining mode (Boris Kazak)
Re: Remark on practical predictability of sequences ("John A. Malley")
Re: Remark on practical predictability of sequences (David A. Wagner)
Re: security problem with Win 2000 Encryption File System (Greg)
Re: Blowfish for signatures? (Runu Knips)
Re: Certificate authorities (CAs) - how do they become trusted authorities ?? (Greg)
Re: Distribution of keys in binaries? (Shawn Willden)
Re: Certificate authorities (CAs) - how do they become trusted authorities ?? (Greg)
Re: Is this a HOAX or RSA is REALLY broken?!? (Greg)
Re: TEA question ([EMAIL PROTECTED])
Re: Certificate authorities (CAs) - how do they become trusted authorities ?? (David
A Molnar)
Re: TEA question ([EMAIL PROTECTED])
Re: Remark on practical predictability of sequences (Mok-Kong Shen)
Re: Remark on practical predictability of sequences (Mok-Kong Shen)
Re: Remark on practical predictability of sequences (Mok-Kong Shen)
Re: Another chaining mode (Mok-Kong Shen)
Re: Key agreement in GSM phones (Michael Schmidt)
Re: How Uncertain? (Mark Wooding)
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: When you know the PT is ascii
Date: Fri, 30 Jun 2000 00:09:18 -0400
Andrew John Walker wrote:
> How secure are encryption methods such as DES, IDEA etc when you
> know the PT consists of printable text or some other subset of
> the ascii character set?
In principle, the more one knows about the plaintext, the easier
cryptanalysis becomes. For example, knowing that every 8th bit
of the DES input block is 0 allows one to reduce the sizeable set
of DES encryption equations to a measurably smaller set of
equations. This *may* permit solution for the key (given multiple
blocks using the same key) in cases that would just take too long
otherwise.
In practice in the "open" cryptologic world today, DES would be
attacked by a brute-force key search machine like EFF's and the
known PT characteristics would be used solely to determine when
a likely decryption had occurred. Testing for a bunch of 0 bits
at known locations (for example) is faster and more accurate
than computing a statistical measure on the decrypted block.
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Idea or 3DES
Date: Fri, 30 Jun 2000 05:04:41 GMT
Arturo wrote:
**************
> And what if we accept the fact that not even the USG is all-powerful?
> They can�t stop the flow of drugs into the US or prevent a starving-to-death
> country like North Korea from becoming a nuclear power, so what makes you think
> they could block the Internet out of the US?
===================
Absolutely correct. From the point of view of a mouse, the most
terrible
predator is the cat. Thus the first and foremost duty of any cat is to
plant
and support this illusion among mice.
So what if cats cannot break ciphers? Mice are abundant around...
Best wishes BNK
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Another chaining mode
Date: Fri, 30 Jun 2000 05:24:38 GMT
Mok-Kong Shen wrote:
****************
> I have a question about this: If one decrpyts two consecutive pairs
> to (x_i, y_i) and (x_(i+1), y_(i+1)), wouldn't one get (x_i, x_(i+1)),
> i.e. one original block? So what do you mean by doing decryption
> in the 'reverse direction' above? Another point: If one does with any
> block cipher in double rounds and hence consumes double time,
> wouldn't avalanche also improve substantailly as you noted? Thanks.
>
> M. K. Shen
=====================
Many attacks are based on different and distinct behavior of individual
bytes and words during encryption. Advancing by half-blocks gives you
additional advantage of thoroughly mixing all your block into one single
entity. Borders between bytes and words exist no more, any analyst must
attack the block as a whole - 128 or 256 bits.
This allows to use reduced number of rounds - for example MMBOOZE has
only 6 rounds, and I cordially invite you to have a look at the cipher.
<http://www.wizard.net/~echo/crypto-contest.html>
Best wishes BNK
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Remark on practical predictability of sequences
Date: Thu, 29 Jun 2000 22:53:54 -0700
Mok-Kong Shen wrote:
>
> Although the details of the paper by Bellare et al. are too
> involved for me to comprehend, it is evident that their
> result does not affect the issue in the present thread. Let
> me quote them:
>
> We assume the cryptanalyst knows the parameters a, b, M
> defining the LCG. (They are chosen at random but then
> made public.) What is unknown to the cryptanalyst is the
> seed k_0 used by the signer to start the LCG.
>
> Since in our case the parameters a, b, M are naturally also
> kept secret (one may for convenience of implementation even
> use a fixed M, but a and b are certainly randomly chosen and
> kept secret), their result cannot be directly or indirectly
> transferred to the present context to apply for any useful
> purpose.
I agree with Mr. Molnar - there may be means of extending the algorithms
to solve the simultaneous modular linear equations in different moduli
to take into account secret parameters for the LCG.
Perhaps the most important point made by M. Bellare, S.Goldwasser and D.
Micciancio is this:
A cipher and a pseudo-random number generator can interact in a way that
permits "easier" cryptanalysis of the ciphertext. The choice of PRNG may
actually weaken the effectiveness of the cipher intended to obfuscate
the weak PRNG into a strong PRNG output.
They show their attack extends to any modular PRNG expressed as modular
linear equations. The modular nature of the pseudo-random number
generator and the modular nature of the cipher interact and permit their
described attack.
Perhaps PRNGs employing mathematical operations not in common with the
operations employed by the cipher prove more resistant to cryptanalysis
and result in output sequences "practically" unpredictable.
For example, consider enciphering the output of a LCG with known
coefficients a, b and M, with a block cipher. (Choose M < 2^block size.
) It can be enciphered in ECB form for speed since no PRN repeats in the
output sequence of the PRNG if we use only up to one cycle of its
output.
The block cipher permutates each pseudo-random number produced by the
LCG. There's no modular relationship between the LCG output and the
permutation output of the block cipher. It seems it *should* be harder
to cryptanalyize the block cipher output to get the initial seed value
used in the LCG than it is with DSS using a LCG.
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Remark on practical predictability of sequences
Date: 29 Jun 2000 22:20:07 -0700
In article <[EMAIL PROTECTED]>,
John A. Malley <[EMAIL PROTECTED]> wrote:
> Perhaps PRNGs employing mathematical operations not in common with the
> operations employed by the cipher prove more resistant to cryptanalysis
> and result in output sequences "practically" unpredictable.
>
> For example, consider enciphering the output of a LCG with known
> coefficients a, b and M, with a block cipher. (Choose M < 2^block size.)
If the cipher is secure, there is no need to worry about using
incompatible mathematical operations -- enciphering any sequence of
non-repeating blocks is secure up to about O(2^{n/2}) blocks, where n
is the blocksize.
Thus, if the cipher is secure, enciphering a counter, a LFSR, or a LCG
should all provide good security regardless of what the internals of
the cipher look like.
The difference between a block cipher and DSA is that a block cipher
acts as a pseudorandom permutation of its input, whereas there is a lot
of structure in the map Randomness -> DSA(Randomness).
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: security problem with Win 2000 Encryption File System
Date: Fri, 30 Jun 2000 06:40:20 GMT
> EFS ( encryption file system ) in Windows 2000 is a big shit.
You sound like you believe this massive hole in MS's security
architecture was a mistake.
> ... but the original file that wasn't encrypted, remains on the
> disk ( deleted ). ... No one can trust EFS !
More specifically, it is Microsoft that cannot be trusted.
--
Tyranny is kept at bay by guns and will. Our government
knows we have the guns, but they don't know if we have
the will. Nor do we.
The only lawful gun law on the books- the second amendment.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Fri, 30 Jun 2000 08:46:15 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Blowfish for signatures?
Thierry Nouspikel wrote:
> My question is: can I use Blowfish to produce a digital signature? I
> mean, the kind of thing that lets you verify that the document you are
> reading is indeed the original, and wasn't doctored in any fashion.
Well, to get a digital signature, you need to have a
(cryptographical) hash function and an asymmetric cipher.
An asymmetric cipher is one which has a public and a private key.
You can encrypt a message with the public key, and the result might
only get decrypted using the private key. Likewise, if you encrypt
with the private key, the message might only be decrypted with the
public key. Therefore you can sign a message if you compute the
hash function of the document and encrypt that value with the
private key. Everyone which has your public key can then verify
that you have signed that document.
You can use Blowfish as a hash function, but you also need some
asymmetric cipher such as ElGamal, RSA etc.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: Certificate authorities (CAs) - how do they become trusted authorities ??
Date: Fri, 30 Jun 2000 06:29:45 GMT
> The presence or lack of presence of a root CA in the
> trusted list maintained by netscape/ie/etc generally
> depends on the presence of money given to the
> browser maker, or the user installing the cert.
> So basically money decides who's trusted, or they are
> trusted through popularity.
And thus they are NOT trusted for their ability to provide
authentication, which is the sole purpose of their existance.
--
Tyranny is kept at bay by guns and will. Our government
knows we have the guns, but they don't know if we have
the will. Nor do we.
The only lawful gun law on the books- the second amendment.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: Distribution of keys in binaries?
Date: 30 Jun 2000 00:31:52 -0600
"Anonymous Coward" <[EMAIL PROTECTED]> writes:
> How secure is it to distribute a key (for encryption/decryption)
> somehow hidden inside a binary? How difficult is it to
> reverse-engineer the binary to extract the key, if the exact
> encryption algorithm (2fish, blowfish, idea, 3des, etc.) is not
> known?
Not very difficult at all. Run the program in a debugger, find the
system call where it writes/sends the ciphertext, back up from there
until you find out where it does the encryption and snag the key.
Even if the key is obscured, it's necessary to recover the key in
order to do the encryption, and the attacker can just pick it up after
reassembly.
In much "modern" software it's even easier. Good modular design
coupled with the use of shared libraries (DLLs or shared objects)
often leads to a situation where I can just poke through the library
entry points looking for something called "encrypt" (or similar) and
set my breakpoint there.
Recently, due to some delays in my company's procurement process, I
took the liberty of hacking some software that required a registration
string to activate it fully. The job took about 5 minutes, because
the application directory had a file called "license.dll", which
contained named entry points, one of which was something like
"checklicense". I felt like writing a thank-you note to the
developers :)
What was especially ironic is that the legitimate registration process
takes about 30 minutes, even after you get your registration
certificate. After 10 minutes waiting on hold to get the other part
of my license data, I hung up the phone, dropped the registration
certificate in a drawer and went back to work.
While this bit is a little off-topic, the point remains that it's
useless to try to hide anything in binary code, if the potential
attackers are sufficiently knowledgeable (and care).
Shawn.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: Certificate authorities (CAs) - how do they become trusted authorities ??
Date: Fri, 30 Jun 2000 06:27:55 GMT
> In doing a bit of research on internet security I naturally came
> across "Certificate authorities (CAs)" (ie: Verisign, twaite, etc) ...
> can anyone tell me (or give me a URL) from where these companies get
> *their* certification - who says they are 'trusted' ?? ...I suppose I
> am asking as well what/who is the root of all authorities!
Yes you are, no there is no answer, and that is the problem that CAs
face.
IMHO, CAs are to solve a business model by tricking the consumer into
unwarranted confidence of security.
The only question you have to ask yourself is, "Does it make sense to
you?" It sure does not to me.
--
Tyranny is kept at bay by guns and will. Our government
knows we have the guns, but they don't know if we have
the will. Nor do we.
The only lawful gun law on the books- the second amendment.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: Is this a HOAX or RSA is REALLY broken?!?
Date: Fri, 30 Jun 2000 06:51:06 GMT
> I mean... it can`t... Is this a Hoax or quantum computing is really
> there? Tell me what you think.
Note the following about the story:
1. Only European banks were mentioned as targets for the device.
2. We know that American banks are just as strong or vulnerable,
yet were not mentioned at all.
3. While such a device is unlikely from a technical stand point,
the effects of the story on the confidence of consumers can be
quite alarming for the banks in Europe.
Give all of this, it would appear to be an intel op against European
banks by possibly Isreali intelligence using the news paper as a pawn.
--
Tyranny is kept at bay by guns and will. Our government
knows we have the guns, but they don't know if we have
the will. Nor do we.
The only lawful gun law on the books- the second amendment.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: TEA question
Date: Fri, 30 Jun 2000 07:14:47 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Adam Durana wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Adam wrote:
> > > > yes..
> > > > but if you choose different number it anyway should be 32 bit number
> > > > so you cant use 1569234 - its too small - only 21 bit (1569234 == 0x17f1d2 ==
>101111111000110110010 )
> > >
> > > You can put 1569234 into a 32-bit variable and that would work just fine.
> >
> > realy? and if i put 5 into a 32-bit variable ? or even 1 or 0 ?
>
> Its a constant, if you want to use 5, 1, or 0 then do it. But it is
> possible to choose a bad constant, depending on how it's used.
so i mean 5, 1, or 0 is a definitely bad constant and
i guess 1569234 is also a bad constant
== <EOF> ==
Disastry http://i.am/disastry/
http://disastry.dhs.org/pgp.htm <-- PGP half-Plugin for Netscape
http://disastry.dhs.org/pegwit <-- Pegwit - simple alternative for PGP
remove .NOSPAM.NET for email reply
=====BEGIN PGP SIGNATURE=====
Version: Netscape PGP half-Plugin 0.14 by Disastry / PGPsdk v1.7.1
iQA/AwUBOVwswzBaTVEuJQxkEQIIxQCg/H7fy9d6wJC0edlGG3IwNCWCLbgAoM8q
rx86kqQIQVh8zCDWmqEIT2VS
=vi1e
=====END PGP SIGNATURE=====
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Certificate authorities (CAs) - how do they become trusted authorities ??
Date: 30 Jun 2000 07:07:36 GMT
Greg <[EMAIL PROTECTED]> wrote:
> IMHO, CAs are to solve a business model by tricking the consumer into
> unwarranted confidence of security.
> The only question you have to ask yourself is, "Does it make sense to
> you?" It sure does not to me.
What would you do instead to deal with the issues for which CAs are
selling themselves as solutions?
-dmolnar
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: TEA question
Date: Fri, 30 Jun 2000 07:42:21 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Shawn Willden wrote:
> dexMilano wrote:
>
> > Let's make the point.
> >
> > I don't have unsigned
so use signed negative, its same
> > so I have an upper limit of f7777777 (absolute
> > value).
7FFFFFFF
>
> No unsigned integers? You must be using Java (I never have figured out why
> Gosling did that, BTW. He claims it was a decision to simplify the
> language, but it seems to make mine more complex on a regular basis).
>
> There's no problem. Just use a long instead of an int to store this
> number. It will be slower, but it can be made to work.
delta=0x9E3779B9 is already unsigned long not int
> If the magic number is only used in bitwise operations, (no arithemetic),
> you can even put it in an int and just allow it to be negative.
> Shawn.
it is used in arithemetic operations in TEA/XTEA (sum += delta; sum -= delta;)
but still you can use negative number
0x9E3779B9 == -0x61C88647 == 2654435769 == -1640531527
0xC6EF3720 == -0x3910C8E0 == 3337565984 == -957401312
so you can use delta=-1640531527; sum=-957401312;
== <EOF> ==
Disastry http://i.am/disastry/
http://disastry.dhs.org/pgp.htm <-- PGP half-Plugin for Netscape
http://disastry.dhs.org/pegwit <-- Pegwit - simple alternative for PGP
remove .NOSPAM.NET for email reply
=====BEGIN PGP SIGNATURE=====
Version: Netscape PGP half-Plugin 0.14 by Disastry / PGPsdk v1.7.1
iQA/AwUBOVwzPDBaTVEuJQxkEQJBNQCg+oqiQiGbR0C6lgYobjRl/kpTr+UAoJE8
p+NqfKSxkxKZ1XyGiEKFPsup
=J5JV
=====END PGP SIGNATURE=====
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Remark on practical predictability of sequences
Date: Fri, 30 Jun 2000 10:23:03 +0200
"John A. Malley" wrote:
> Mok-Kong Shen wrote:
> >
> > Although the details of the paper by Bellare et al. are too
> > involved for me to comprehend, it is evident that their
> > result does not affect the issue in the present thread. Let
> > me quote them:
> >
> > We assume the cryptanalyst knows the parameters a, b, M
> > defining the LCG. (They are chosen at random but then
> > made public.) What is unknown to the cryptanalyst is the
> > seed k_0 used by the signer to start the LCG.
> >
> > Since in our case the parameters a, b, M are naturally also
> > kept secret (one may for convenience of implementation even
> > use a fixed M, but a and b are certainly randomly chosen and
> > kept secret), their result cannot be directly or indirectly
> > transferred to the present context to apply for any useful
> > purpose.
>
> I agree with Mr. Molnar - there may be means of extending the algorithms
> to solve the simultaneous modular linear equations in different moduli
> to take into account secret parameters for the LCG.
>
> Perhaps the most important point made by M. Bellare, S.Goldwasser and D.
> Micciancio is this:
>
> A cipher and a pseudo-random number generator can interact in a way that
> permits "easier" cryptanalysis of the ciphertext. The choice of PRNG may
> actually weaken the effectiveness of the cipher intended to obfuscate
> the weak PRNG into a strong PRNG output.
>
> They show their attack extends to any modular PRNG expressed as modular
> linear equations. The modular nature of the pseudo-random number
> generator and the modular nature of the cipher interact and permit their
> described attack.
>
> Perhaps PRNGs employing mathematical operations not in common with the
> operations employed by the cipher prove more resistant to cryptanalysis
> and result in output sequences "practically" unpredictable.
>
> For example, consider enciphering the output of a LCG with known
> coefficients a, b and M, with a block cipher. (Choose M < 2^block size.
> ) It can be enciphered in ECB form for speed since no PRN repeats in the
> output sequence of the PRNG if we use only up to one cycle of its
> output.
>
> The block cipher permutates each pseudo-random number produced by the
> LCG. There's no modular relationship between the LCG output and the
> permutation output of the block cipher. It seems it *should* be harder
> to cryptanalyize the block cipher output to get the initial seed value
> used in the LCG than it is with DSS using a LCG.
I am not sure that I understand you correctly. Are you endorsing my
view that it is o.k. to use a common PRNG with all parameters
secret to generate sequences for input to a good block cipher for
obtaining practically (not provably) non-predictable sequences?
Note that we also have good practical means to enhance security,
e.g. combining a number of such output sequences, even though
we'll never achieve thereby theorectical provable security, which
is an utopic goal for the practice anyway.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Remark on practical predictability of sequences
Date: Fri, 30 Jun 2000 10:23:14 +0200
Rick Braddam wrote:
[snip]
> I hope this helps those not familiar with Yarrow. I just checked at
> Counterpane's site at
> http://www.counterpane.com/yarrow.html and found that version 0.8.71 is
> the one currently
> available for download. The paper available describes one which uses both
> SHA1 and 3DES,
> but the paper does not present any algorithms, and two figures which might
[snip]
The wording of the paper concerning the input sequence seems to
suggest that it should come from hardware. My point is that a software
source, typically a common PRNG, should be o.k., if a good block
cipher is used for post-processing.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Remark on practical predictability of sequences
Date: Fri, 30 Jun 2000 10:22:54 +0200
David A Molnar wrote:
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> > result does not affect the issue in the present thread. Let
> > me quote them:
>
> > We assume the cryptanalyst knows the parameters a, b, M
> > defining the LCG. (They are chosen at random but then
> > made public.) What is unknown to the cryptanalyst is the
> > seed k_0 used by the signer to start the LCG.
>
> > Since in our case the parameters a, b, M are naturally also
> > kept secret (one may for convenience of implementation even
> > use a fixed M, but a and b are certainly randomly chosen and
> > kept secret), their result cannot be directly or indirectly
> > transferred to the present context to apply for any useful
> > purpose.
>
> I would like to point out that there is some work on
> recovering the seed, even when a, b, and M are NOT KNOWN.
> In fact, even when the generator outputs only a few bits of each
> state, you can eventually reconstruct the seed. These results apply to
> the case where the outputs are accessible directly.
> One such analysis is in the paper by Antoine Joux and Jacques Stern,
> "Lattice Basis Reduction ; A Toolbox for the Cryptanalyst."
> Another is in the forbidding paper
> "Reconstruction of Truncated Linear Congruences" (I think that's the
> title; my memory is a little screwy right now)
> by Lagrarias, Kannan, Shamir, and Freize (and maybe more?).
>
> You may protest that these results only apply to the case in which the
> linear congruential generator's output is directly accessible. Fine.
> I have not tried to do it yet, but it would not suprise me
> if one could use the results to extend Miccancio et al.'s analysis to
> account for a DSS case in which a, b, and M are not known.
> It would also not surprise me if such an extension was messy beyond
> belief, which may have been one of the reasons the DSS paper made
> the above simplifying assumption. I would not bet a real system
> on the difficulty of doing such analysis if I expected a sophisticated
> adversary.
>
> Terry Ritter posted a pretty complete bibliography on the subject of
> why LCGs are unfortunate about a year ago. It should be in deja.com
> and is worth searching for. Klaus Pommerening also has software which
> does LCG predicting, although I forget whether it requires a, b, or M.
If the LCPRNG output is directly accessible, then it is insecure even
if only a tiny fraction of bits of each number generated is used. One
of the earlier essential work on that is by J. Boyar. But that's not the
issue here. For we let the sequence from the generator to be post-
processed by a block cipher. If that cipher is considered good enough
to encrypt natural language texts, there is no reason I can conceive of
why it should perform poorer to 'encrypt' the generator output. As
said, the assumption made in the paper of Bellare et al. is different
from that of ours.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Another chaining mode
Date: Fri, 30 Jun 2000 10:23:20 +0200
Boris Kazak wrote:
> Mok-Kong Shen wrote:
> > I have a question about this: If one decrpyts two consecutive pairs
> > to (x_i, y_i) and (x_(i+1), y_(i+1)), wouldn't one get (x_i, x_(i+1)),
> > i.e. one original block? So what do you mean by doing decryption
> > in the 'reverse direction' above? Another point: If one does with any
> > block cipher in double rounds and hence consumes double time,
> > wouldn't avalanche also improve substantailly as you noted? Thanks.
> >
> > M. K. Shen
> ---------------------
> Many attacks are based on different and distinct behavior of individual
> bytes and words during encryption. Advancing by half-blocks gives you
> additional advantage of thoroughly mixing all your block into one single
> entity. Borders between bytes and words exist no more, any analyst must
> attack the block as a whole - 128 or 256 bits.
> This allows to use reduced number of rounds - for example MMBOOZE has
> only 6 rounds, and I cordially invite you to have a look at the cipher.
>
> <http://www.wizard.net/~echo/crypto-contest.html>
>
I am mainly interested in what you meant by the expression of doing
decryption of your cipher in the 'reverse' direction? I don't see
anything different from a normal cipher in this context.
M. K. Shen
------------------------------
Date: Fri, 30 Jun 2000 10:59:53 +0200
From: Michael Schmidt <[EMAIL PROTECTED]>
Subject: Re: Key agreement in GSM phones
Hi,
the almost complete GSM security architecture specification can be
downloaded at the ETSI web site (http://www.etsi.org). You only need to
register with your e-mail address.
Check for the following documents:
- GSM 02.09 (...Security Aspects...)
- GSM 03.20 (...Security related network functions...)
...and maybe others. Search for the keywords "GSM security", "A3", "A5",
"A8", "encryption" etc.
The ETSI documents do not contain the actual implementations of A3
(authentication), A5/1 ("strong" voice encryption), A5/2 ("weak" voice
encryption for countries where strong encryption is not allowed) and
A8 (key generation for A5).
However, the common implementation for A3/A8 ("COMP128") as well as
the A5/1 algorithm have been broken and cracked; info and the algorithm
source codes can be found at http://www.scard.org/gsm.
Additional material may be found at http://jya.com/cryptout.htm#GSM.
There is an excellent German book about GSM security:
"Sicherheit mobiler Kommunikation" by Hannes Federrath, Vieweg Verlag,
Braunschweig/Wiesbaden 1999, ISBN 3-528-05695-9
I don't know of any equivalent English book.
I hope this helps...
Michael
Arturo wrote:
>
> On Mon, 26 Jun 2000 13:18:24 +0200, Gerard Tel <[EMAIL PROTECTED]> wrote:
>
> >
> >Two questions on GSM protection, left after reading Biryukov/Shamir/
> >Wagner's account on breaking the A5/1 stream cipher:
> > 1. What protocol is used by the two parties to agree on the
> > 64 bit keys used?
> > 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?
> >
> >Gerard Tel
> >http://www.cs.uu.nl/~gerard/
>
> A technical paper describing the GSM algorithms in full will be much
> appreciated.
--
===================================================
Michael Schmidt
===================================================
Institute for Data Communications Systems
University of Siegen, Germany
www.nue.et-inf.uni-siegen.de
===================================================
The 'Thin Client Security Homepage':
www.nue.et-inf.uni-siegen.de/~schmidt/tcsecurity/
===================================================
http: www.nue.et-inf.uni-siegen.de/~schmidt
e-mail: [EMAIL PROTECTED]
phone: +49 271 740-2332 fax: +49 271 740-2536
mobile: +49 173 3789349
===================================================
### Siegen - The Arctic Rain Forest ###
===================================================
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: How Uncertain?
Date: 30 Jun 2000 09:01:37 GMT
Mark Wooding <[EMAIL PROTECTED]> wrote:
> Assuming that all of these bits are independent, I get a joint entropy
> for that lot of 3.10.
Arithmetic error. That should be 6.05, actually.
> Even with this extended model, I think we've a way to go before we get
> down to Schneier's estimate. It's a pretty poor model, really.
A *really* long way.
-- [mdw]
------------------------------
** 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
******************************
