Cryptography-Digest Digest #712, Volume #10 Thu, 9 Dec 99 22:13:01 EST
Contents:
Re: Shamir announces 1 sec break of GSM A5/1 (Quisquater)
Re: Shamir announces 1 sec break of GSM A5/1 (Lauri Pesonen)
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 (Steve K)
Re: Synchronised random number generation for one-time pads
([EMAIL PROTECTED])
Re: Digitally signing an article in a paper journal ("Roger Schlafly")
Re: Synchronised random number generation for one-time pads ("Charles Meigh")
Re: low exponent in Diffie-hellman? (Scott Fluhrer)
Re: Random Noise Encryption Buffs (Look Here) (Tim Tyler)
Re: weak algorithm, too hard for me (Gaccm)
Re: weak algorithm, too hard for me (Olan I. Merky)
Absent source code now available (Avi Rubin)
Re: NSA future role? (Tim Tyler)
Re: Shamir announces 1 sec break of GSM A5/1 (Tim Tyler)
Re: weak algorithm, too hard for me (JPeschel)
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: Shamir announces 1 sec break of GSM A5/1 ("Douglas A. Gwyn")
Re: NSA future role? ("Douglas A. Gwyn")
Re: NSA future role? ("Douglas A. Gwyn")
Re: NSA future role? ("Douglas A. Gwyn")
Re: NSA future role? ("Douglas A. Gwyn")
Re: Random Noise Encryption Buffs (Look Here) ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: Quisquater <[EMAIL PROTECTED]>
Subject: Re: Shamir announces 1 sec break of GSM A5/1
Date: Thu, 09 Dec 1999 22:22:42 +0100
See
http://cryptome.org/a51-paper.htm
------------------------------
From: Lauri Pesonen <[EMAIL PROTECTED]>
Subject: Re: Shamir announces 1 sec break of GSM A5/1
Date: 09 Dec 1999 23:25:48 +0200
[EMAIL PROTECTED] (Troed) writes:
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> >Ok first off GSM is a european standard is it not? So what does this
> >have todo with america?
>
> What do you have to do with this? GSM is used in the US too, yes, and
> this newsgroup isn't for americans only, no.
>
> >Second I seriously doubt the size of their HD affects the attack speed.
>
> Of course the amount of data you can play with affects the attack
> speed.
There is a known time-memory trade-off attack against A5/1 in which
case the HD space is very usefull and speeds the attack up.
See
http://jya.com/a5-hack.htm
> >Third the majority of the data from the cell phones is unencrypted
> >anyways. I seriously doubt the majority of privacy violations are
> >based on broken crypto.
>
> No, GSM voice communication is always encrypted.
Actually that is not quite true. The A5 algorithm is always used, but
the used A5 algorithm does not have to implement any crypto. There are
different A5 implementations for different countries. The 'strong' A5
(called A5/1) is used mainly in European countries. The time
complexity of A5/1 used to be around 2^45 (I did not read the Shamir
article). A weaker A5/2 algo is used in other countries e.g. the
U.S. The time complexity of A5/2 is assumed to be around 2^16. There
is also a A5/0 algo, which means no encryption at all. A5/1 is the
interesting algo from a academic point of view.
--
! Lauri
------------------------------
From: [EMAIL PROTECTED] (Steve K)
Crossposted-To: alt.privacy
Subject: Re: If you're in Australia, the government has the ability to modify your
files. >> 4.Dec.1999
Date: Thu, 09 Dec 1999 22:17:38 GMT
On Thu, 09 Dec 1999 19:05:34 GMT, zapzing <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> "fuck echelon" <[EMAIL PROTECTED]> wrote:
>
>Love the name. You had celebrity parents too,huh?
>
>But seriously, I agree that the main problem would be
>that somebody (probably _not_ the police, actually)
>would break in and covertly install a bug or alter the
>software in the computer.
>
>I think the best that can be done is to make it
>impossible for them to do it _covertly_.
>And there may be ways to do this in software,
>or at least I suspect that there are,
>but apparently anyone who knows anything
>is not talking.
>At least not in this group.
Oooooh!
:o)
Steps in the right direction:
1) PGP sign your registry (ole.reg in /windows/system/). Test it
regularly. Test it before, and update it after, installing or
removing any software. This should guard against most hidden trojans.
2) PGP sign the .exe files of every network application you use, and
your anti-virus .exe files. These are the most likely programs to be
patched to add "special" functions. Add any crypto and file wiping
utilities you may have, to the signature list.
3) Get and use a firewall, and yes, PGP sign its .exe file(s).
You will be more likely to keep up the practice of testing these sigs,
if you put shortcuts to all of them in a handy folder on your desktop.
I haven't tried putting shortcuts to signatures in the start-up file,
but it sounds like a fun experiment.
What about the operating system itself? Okay, reinstall from a known
good copy, and go and sign every executable that is shown in the task
manager list (hit ctrl-alt-del once), and add them to your pile of sig
shortcuts. (If the "known good" copies have real back doors, we're
all doomed, and you better migrate to Free BSD.)
Computers being what they are, there are no 100% airtight methods to
guarantee that a drive has not had some nasty little program installed
behind your back, other than to carry the drive, or an image of it,
with you 24/7. But I suspect that the measures suggested above would
knock the top 98% off the threat, as long as those signatures do get
checked on a regular basis. (Also a good idea to sign the PGP
executables, and keep copies of all these signatures on a floppy in a
well hidden location. Belt and suspenders.)
If you think that files may have alredy been compromised, uninstall
them and install known good copies. And go through your registy and
bootlog files with a fine toothed comb. Then revoke your PGP keys,
and replace your distribution with a fresh one, before signing
anything.
There. Nyah.
Steve K
---Continuing freedom of speech brought to you by---
http://www.eff.org/ http://www.epic.org/
http://www.cdt.org/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Synchronised random number generation for one-time pads
Date: Thu, 09 Dec 1999 23:00:53 GMT
[EMAIL PROTECTED] wrote:
> amadeus wrote:
>
> : OTP is totally secure given it is properly used. The problems are
key
> : distribution and key cancellation/deletion. [...]
>
> Then there's the issue that a known-plaintext attack reveals the key -
and
> possibly allows inauthentic messages to be passed off as the real one.
>
> Authenticity is a problem for OTPs.
It's a solved problem. In fact the only theoretically
proven authentication methods are, like provable
privacy, based on a one-time random key stream.
For perfect secrecy, the condition required is that
for any message m, the ciphertext of m is independent
of m. For authentication we want the stronger
property that for any pair of messages m and m', the
signature of m is independent of the triple
(m, m', signature(m')).
> With your typical block cypher, knowing the plaintext does *not*
> instantly reveal the message key, and allow forged message(s) to be
sent.
Block ciphers allow existential forgery; they
only prevent the attacker from controlling the
plaintext of the forgery. Ciphers are privacy
mechanisms and provide miserable authentication
by modern standards. Verification functions should
detect forgeries, not pass along garbage as if it
were plaintext.
One-time pads, public key ciphers, and conventional
secret-key ciphers each have a corresponding class
of authentication mechanisms that have essentially
the same relative essential advantages and
disadvantages. In most cases, if we encrypt with
conventional block cipher we would want to
authenticate with a MAC; if using a public key
cipher, use a public key digital signature. If we
need a one-time pad for provable, information
theoretic secrecy and can pay the price in key
distribution, then we probably also want to use
one-time keys with universal hash functions for
provable authentication.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: Digitally signing an article in a paper journal
Date: Thu, 9 Dec 1999 14:25:08 -0800
KloroX <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> >I'd be surprised if any respectable journals were willing to publish
> >articles under such conditions, by the way.
>
> The situation is unusual, admittedly, and I would have to count on
> sympathetic treatment by the editors. But, on the other hand, science
> should be judged on its objective value, not on who writes it.
And what is the objective value of your authorship games?
Science also depends on the credibility and good will of
authors, editors, and referees.
You might be able to sneak it in. An MD5 hash is only 32 hex
digits, so you might slip in:
The author acknowledges the benefit of grants 143DD59E0,
49ACA831, A3984578, 4FF3A801.
It is unlikely that the editor will suspect anything.
------------------------------
From: "Charles Meigh" <[EMAIL PROTECTED]>
Subject: Re: Synchronised random number generation for one-time pads
Date: Thu, 9 Dec 1999 23:17:10 -0000
Thanks everyone, I hadn't come across the problem of interception and
forgery yet. I think I'll add a decent physics textbook to my shopping
list as well as cryptology. I'm still thinking that there might be some
vastly wide choice of 'celestial' events that could produce truly random
numbers that will still be sufficiently similar observed from any two (or
more) points on the globe, which would make OTP use more economical.
Can I ask if there are any resources anyone could point me too that cover
cryptographic or non-cryptographic means of preventing or reducing the
effectiveness of known-plaintext attacks; my searches have found nothing so
far, and I can only think of the use of code-words?
--
Charles Meigh
------------------------------
From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: low exponent in Diffie-hellman?
Date: Fri, 10 Dec 1999 00:10:19 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (jerome) wrote:
>i perform a calculation g^x mod p. g=2 and p a prime of 768bits.
>The algorithm i used is based on the 'square and multiply'
>exponantiation so the smaller x is, the faster is the computation.
>as far as i know the only constraint for x is to be 0 > x > p-2.
>
>can i reduce x to 128bits (enougth to prevent a brute force) ?
>or there is a special attack for the low exponent ? (some RSA
>implementations got issues about that but i don't have the papers
>so i can't say if it can be used against Diffie-hellman)
I'll let bobs respond to the security implications, but if you
are using 'square and multipy', why don't you go to a more
efficient modular exponentiation algorithm. In particular, why
don't you look at the algorithms in 14.6 of the Handbook of
Applied Cryptography, which should speed you up by 30% with *no*
reduced security.
--
poncho
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 9 Dec 1999 23:54:08 GMT
John Myre <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> *Perhaps* you thought I was talking about the frequency of the *radiation*
:> rather than the frequency of the rays hitting the Earth - and didn't
:> consider the other interpretation.
: *Perhaps* if you had written "intensity" (as per the quoted material!)
: instead of "frequency" then your post would not have needed
: "interpretation".
The point I was trying to make was clear enough - you can't
generate completely random streams of data due to (for one thing)
inability to completely eliminate non-random influences from the
environment.
Had I believed for a moment somebody would try to criticise my post
based on the assertion that cosmic rays were not a totally random
phemnomenon, I might have cited a dozen scientific references to
avoid any possibility of criticism.
I had no idea my post would get mis-interpreted - if indeed that's what
happened.
For all I know the poster who brought me up might have been under the
impression that "cosmic rays" were rays from the cosmos - i.e. from
outside the solar system - and were thus unlikely to be affected by
sunspots. Should I clarify what I mean there as well, in order to avoid
every possible last drop of ambiguity?
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Nuns do it out of habit.
------------------------------
From: Gaccm <[EMAIL PROTECTED]>
Subject: Re: weak algorithm, too hard for me
Date: Thu, 09 Dec 1999 16:10:01 -0800
Reply-To: [EMAIL PROTECTED]
Thanks!
Could you tell me how you solved that, so i don't have to ask for help
again.
P.S. Thanks again
------------------------------
From: [EMAIL PROTECTED] (Olan I. Merky)
Subject: Re: weak algorithm, too hard for me
Date: Fri, 10 Dec 1999 00:40:11 GMT
[EMAIL PROTECTED] (JPeschel) wrote:
>Gee, it's not that tough, guy!
>I already gave him the password.
>
>Joe
>__________________________________________
>
>Joe Peschel
>D.O.E. SysWorks
>http://members.aol.com/jpeschel/index.htm
>__________________________________________
If you're so smart, how come you're on AOL?
------------------------------
Crossposted-To: alt.security,comp.security.misc
From: [EMAIL PROTECTED] (Avi Rubin)
Subject: Absent source code now available
Date: Fri, 10 Dec 1999 00:36:49 GMT
We are pleased to announce the public release of the Absent, secure
remote access system.
A description, the paper, and the code are available at
http://www.research.att.com/projects/absent
Absent is a system for secure remote access to the internal web from
outside. It addresses the problem of secure remote access to a site's internal
web server from outside the firewall. The goal is to give authorized users
access to sensitive information, while protecting the information from others.
We implemented our solution using a one-time password scheme for client
authentication and SSL for confidentiality. Our main design considerations
were security, performance, ease of use, availability, and scale. We were
further constrained by the desire to leave our firewall and local infrastructure
unchanged.
Christian Gilmore, Dave Kormann, Avi Rubin
AT&T Labs - Research
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: NSA future role?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 10 Dec 1999 00:21:22 GMT
CLSV <[EMAIL PROTECTED]> wrote:
: "SCOTT19U.ZIP_GUY" wrote:
:> To even quote Mr BS himself he even stated on this forum that for him
:> designing long key crypto methods that are secure would be much harder
:> for him.
: Long key crypto certainly has its uses. But I also believe that
: it is *much* harder to write an algorithm that uses a long key
: in a useful way. It doesn't make much sense to design an algorithm
: that uses 16384-bits keys but can be broken using *only* 1024-bits.
I don't really see much difficulty there. Many encryption systems
use large numbers of s-boxes. These can often be configured randomly
(given a bunch of constraints designed to eliminate weak keys), and the
resulting algorithm will still be quite strong.
There are arguments for and against using arrangements that try to defeat
cryptanalysis - but these can only work against currently known methods.
DES optiimised its s-boxes against differential cryptanalysis, but was
then subsequently found wanting when linear cryptanalysis was used.
Generally speaking, constrained, but randomly configured s-boxes will
work well enough.
Since a constrained random selection of s-boxes can be used - and the
number and size of the s-boxes does not have any /real/ limit - outside
the world of caches, and diffusion rates - making an algorithm which makes
reasonably effective use of large keys is not that difficult.
You won't find an algorithm whose strength depends on the size of its
key-space, but provided your expectations are more modest, large keys
/should/ fairly easily translate into real security advantages.
:> This was to help foster the flase impression that the NSA wants
:> people to belive. Yes he and the NSA will do a good job on selling the
:> AES stuff as secure. But do you really think the NSA would allow a
:> secure crypto system to become a US standard that they could
:> not easily brake.
: I think you look up too much to the NSA. If the NSA can brake
: an algorithm than there are probably two or three other agencies
: that can brake it. The NSA knows this as well and I think they
: rather have a secure algorithm than one that gives the Russians,
: Chinese, Israeli, French (...) easy access to commercial secrets.
Hmm. NSA is responsible for national /security/, not commercial profits.
Profits are often secondary to security - without security, profits can
be stolen, or the country can be invaded.
The NSA has a /long/ history of restricting public access to cryptography:
Consider for example its funding of a (1980) study designed to presuade
congress to give it power over publications in the field of cryptography.
Then there's the export controls. Any US company who wants to use a
single product at home and in the world market needs to cripple its
encryption. Then there's the key-escrow chips. And so on.
Those who have urged us to look twoards the NSA's involvement with DES
should be reminded that the NSA are supposed to have characterised DES
off the record as "one of their biggest mistakes".
Apparently the situation was a result of confusion between the NSA and the
NBS. The NSA understood that DES would be hardware-only. Had they known
what would be done with it it seems unlikely they would have agreed to it.
I expect they will have learned from this mistake.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Marriage? Sorry - I don't mate in captivity.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Shamir announces 1 sec break of GSM A5/1
Reply-To: [EMAIL PROTECTED]
Date: Fri, 10 Dec 1999 01:32:12 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
[GSM encryption break]
: Ok first off GSM is a european standard is it not? So what does this
: have todo with america?
This is sci.crypt, not sci.american.crypt.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
New regulations mean new jobs for new regulators.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: weak algorithm, too hard for me
Date: 10 Dec 1999 02:02:20 GMT
[EMAIL PROTECTED] (Olan I. Merky) quips:
>If you're so smart, how come you're on AOL?
>
>
Now that isn't that clever! :-)
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Fri, 10 Dec 1999 02:14:15 GMT
Tim Tyler wrote:
> What if this guy is the radio operator? You expect him to memorise
> the text of every message he sends?!
> He may no longer have access to the plaintext of the message - while he
> may still remember the password he used as a key to encrypt it.
Your model of encrypted radio operations is nothing like
what has really been done, and even farther from the current
mode of operation. Traditionally, encryption was performed
by a different person than the radio operator, and keys were
not usually memorized by the encryptor. These days it's all
automated, and no person sees the key, much less memorizes it.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Shamir announces 1 sec break of GSM A5/1
Date: Fri, 10 Dec 1999 02:18:25 GMT
> > Guess the NSA didnīt invite them to their annual
> >see-all-our-surveillance-hardware, hmm?
"SCOTT19U.ZIP_GUY" wrote:
> No he probily came. But like most management when they go to
> such meetings. Its the partys and free booze and hookers that
> these kind of meetings unite that they really go for.
What nonsense (on both sides).
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NSA future role?
Date: Fri, 10 Dec 1999 02:21:49 GMT
Jim Dunnett wrote:
> I have difficulty understanding how a country so technologically
> advanced as the USA still uses the medieval imperial system!
Maybe there is a connection.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NSA future role?
Date: Fri, 10 Dec 1999 02:23:50 GMT
"SCOTT19U.ZIP_GUY" wrote:
> ... But do you really think the NSA would allow a
> secure crypto system to become a US standard that they could
> not easily brake.
The INFOSEC side of the house certainly would.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NSA future role?
Date: Fri, 10 Dec 1999 02:25:56 GMT
Tim Tyler wrote:
> I don't really see much difficulty there. Many encryption systems
> use large numbers of s-boxes. These can often be configured randomly
> (given a bunch of constraints designed to eliminate weak keys), and the
> resulting algorithm will still be quite strong.
It is usually not a good idea to choose S-boxes randomly.
(There is a famous paper about this, but I don't have the
reference at hand at the moment.)
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.nsa
Subject: Re: NSA future role?
Date: Fri, 10 Dec 1999 02:28:36 GMT
Jim Dunnett wrote:
> Do you really think they'd have the technology and funds to be able
> to handle plutonium without killing themselves in the process?
This has strayed off-charter...
Plutonium won't kill you under normal handling procedures,
and anyway, terrorists are often prepared to sacrifice themselves
for their cause, especially when it is a religious cause.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Fri, 10 Dec 1999 02:32:46 GMT
Guy Macon wrote:
> I was under the impression that the exponential decay came
> from the fact that there are a finite number of atoms in
> the sample and that each atom decays only once. I don't
> think (correct me if I am wrong) that individual radium
> atoms have an exponential decay expectation.
Okay: you're wrong. Even an individual nucleus in an excited
state has a well-defined decay "half-life" and thus an
exponential function of time for its decay probability.
------------------------------
** 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
******************************
