Cryptography-Digest Digest #958, Volume #12 Thu, 19 Oct 00 09:13:01 EDT
Contents:
Re: CHAP security hole question (Vernon Schryver)
Re: CRC vs. HASH functions (Tim Tyler)
Re: Is it trivial for NSA to crack these ciphers? (CiPHER)
Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom (CiPHER)
idea for spam free email ("G. Orme")
Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom (Andre)
Q: Message length in RSA (=?iso-8859-1?Q?Tom=E1s?= Perlines Hormann)
Re: Is it trivial for NSA to crack these ciphers? (Arturo)
RSA codes ([EMAIL PROTECTED])
Re: RSA codes (Tom St Denis)
Re: srp-1.6.0 released (Philip MacKenzie)
Re: Q: Message length in RSA (Tom St Denis)
Re: RSA codes (Bob Silverman)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: CHAP security hole question
Date: 18 Oct 2000 14:23:43 -0600
In article <8sksoq$b87$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> ...
>What are other authentication and key-exchange protocols besides CHAP?
>From my perspective, that's a lot like asking "what other encryption
schemes are there besides DES?" I know of a bunch, but that means nothing
interesting.
>It seems to me that CHAP originated from PPP. I am trying to search
>for all authentication and key-exchange protocols so that I can compare
>which one can better suit my need. BTW, my need is, first, to
>authenticate a user, second, to prevent socket connections from
>unauthenciated user.
How do you authenticate a user before establishing a way to exchange
authenticating information?
In the classic sockets API, you can prevent either all TCP connections or
none. After accept() returns, you have a connection.
TLI and other ISO OSI implementations had other ideas, but they didn't
make a lot of sense. You can't trust network addresses for authentication
(see TCP ISN predicting or the "Mitnick attack"), and so you must exchange
a bunch of bits in addition to the connection establishment handshake.
You may as well complete the lower layer (e.g. TCP) connection before
worrying about upper layer (application) authentication.
> ...
>> lists of passwords from Microsoft systems. Anything based on shared
>> secrets is no stronger than the secrecy of those secrets.
>
>Does this mean that a general weakness of CHAP is its sharing of secret
>keys between a server and all its clients?
No, it means that anything base on shared secrets is broken when the
secrets aren't secret, and that Microsoft products have reputations
concerning their abilities to keep secrets.
>> The second is that Microsoft uses a single secret to authenticate both
>> a source of PPP packets and access to a user account. The ability to
>> send PPP packets to a system is generally no worse than what can be done
>> to the same system through its other network connections by any random
>> bad guy without any secret knowledge, while access to an account is the
>> whole thing. Other brands of systems can distinguish the two. If a bad
>> guy gets a CHAP secret, all that need be compromised is IP packet access,
>> but an MS-CHAP secret is often useful for more serious dirty work.
>
>You said "other brands of systems can distinguish the two". Can you
>name some of these "other systems"?
Any PPP system such as router that does only PPP, or at least keeps the
authenticating secrets for PPP connections distinct from the configuration
changing secrets.
Most UNIX PPP implementations, if only because the UNIX user account
/etc/passwd file does not contain secrets that can be used with CHAP
(at least not in a reasonable systems, since even with shadow passwords,
it's not smart to assume the password hashes are secret)
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: CRC vs. HASH functions
Reply-To: [EMAIL PROTECTED]
Date: Thu, 19 Oct 2000 09:03:38 GMT
Bryan Olson <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> While hash functions take longer to evaluate in software,
:> they often have a layered structure that allows hardware
:> implementations to accept new inputs before the last
:> inputs have been completely processed, allowing
:> concurrent processing to take place. [snip CRC comparison]
: What hashes are you talking about? In cryptographic hashes
: such as SHA-1 [...]
This type.
: [...] there exist opportunities for parallelism but
: the number of stages that must be sequential is a hardware
: nightmare compared to a CRC.
While subsequent rounds require processing sequentially, this affects
the time taken to produce an output from an input. AFAIK, there is
not necessarily any effect on the "throughput" time - since the rounds
can be laid out in rows in hardware, and new inputs can be fed into the
construction before previous outputs have been processed.
This might not greatly affect (say) the time taken to produce the hash
of a file - or where blocks need to be sequentially chained together.
However, it could make a big difference for instances where the processing
of the hash is used to generate confusion sequences - e.g. in a RNG based
on a counter-driven hash.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: CiPHER <[EMAIL PROTECTED]>
Subject: Re: Is it trivial for NSA to crack these ciphers?
Date: Thu, 19 Oct 2000 09:16:08 GMT
In article <8smb29$h14$[EMAIL PROTECTED]>,
David Bernier <[EMAIL PROTECTED]> wrote:
> Some options that come to mind:
*snip*
Exactly...
I would not be suprised if the intelligence agencies don't concentrate
much at all on breaking the actual ciphers and instead try to get the
information through other more easier methods... like say, a mole... or
using key logging trojans... etc. etc.
But of course, people at a crypto newsgroup are gonna want to think that
crypto is the be all and end all, when it can broken simply by
retrieving the 'plain-text' info by person or before it's encrypted.
How many of you have lead-lined (or some similar/better working
techno guff) walls in your houses? Yeah, y'see...
--
Marcus
---
[ www.cybergoth.cjb.net ] [ alt.gothic.cybergoth ]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: CiPHER <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom
Date: Thu, 19 Oct 2000 09:30:42 GMT
In article <[EMAIL PROTECTED]>,
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> Stolen German Code Machine Turns Up in BBC Mailroom
>
> http://ap.tbo.com/ap/breaking/MGA5JU6YFEC.html
Update :
# 'No ransom paid' for Enigma
# http://news6.thdo.bbc.co.uk/hi/english/uk/newsid%5F978000/978274.stm
...also quoted from the text :
> The stolen Enigma is a rare four-rotor version, one of only three
> still known to be in existence.
Rare = worth a lot = likely to get stolen
--
Marcus
---
[ www.cybergoth.cjb.net ] [ alt.gothic.cybergoth ]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "G. Orme" <[EMAIL PROTECTED]>
Subject: idea for spam free email
Date: Thu, 19 Oct 2000 10:06:01 GMT
Any suggestions are most welcome on the folowing.
Basically the idea involves having two email addresses, a public known one
such as e.g. [EMAIL PROTECTED], and a private address, e.g.
[EMAIL PROTECTED]
As part of Outlook Express for example, there would be an attached program.
This program stores the private email addresses in a way that they cannot be
read by anyone, but links them to the corresponding public address like
[EMAIL PROTECTED] In the above example, you could not find out the secret
email address as it would be encrypted inside the program. If you wanted to
send an email to it, you would put in the address [EMAIL PROTECTED] and the
program sends the email to [EMAIL PROTECTED]
Say you wish to exchange email addresses with someone. The program sends an
email to their ordinary address with your secret email address encrypted,
and the public email address in plain view. They do the same back to you.
The receiver loads this into their special program as part of Outlook
Express, and now they can email you at your secret address without their
ever knowing what it is. All they can give anyone is your public address
which will not work without the linked private one. Of course the program
knows it but won’t tell them, only redirecting to your private address when
they send to your public address. As part of using this program they must
accept a license agreement that they will never send spam to you.
In this way people exchange public and private email addresses with people
who all must agree not to spam each other. Once you have done this you can
freely advertise your public email address, but even if it is harvested it
cannot be used as they cannot know the private email address associated with
it. Periodically, perhaps once a month the private email addresses are
changed and this information is either sent in encrypted form to users, or
the program can check in at the main server and update its list of public
addresses with the new private ones. If someone has abused the system then
they can be blacklisted and denied updates, so their list of email addresses
becomes unusable.
As another part of the program carbon copy would be disabled, so you could
send only one email at a time to discourage bulk mailers. Of course whoever
uses the program must agree as part of the license not to send advertising
by email anyway.
------------------------------
From: Andre <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom
Date: Thu, 19 Oct 2000 09:58:36 GMT
In article <[EMAIL PROTECTED]>,
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> James Felling wrote:
> >
> > Andre wrote:
> >
> > > In article <[EMAIL PROTECTED]>,
> > > [EMAIL PROTECTED] (John Savard) wrote:
> > > > On Wed, 18 Oct 2000 01:25:23 +0100, Mathew Hendry
> > > > <[EMAIL PROTECTED]> wrote, in part:
> > > >
> > > > >Three of the four rotors are missing. (Why steal only those?)
> > >
> > > Its an enigma (sic) why they'd remove the rotors .
> > >
> > > Here's my theory why they were removed .
> > >
> > > I suspect that it has to do with the secret Tesla files relating
to
> > > zero point energy and wireless power .
> > >
> > > As this information was sensitive, after the end of WW2 it was
> > > encrypted with one of these machines. (best technology available
at the
> > > time) . I suspect that the thieves knew this, as they had gotten
hold
> > > of one of the documents concerned.
> > >
> > > Therefore, they needed the original machine that the document(s)
were
> > > encrypted on to read the documents.
> > >
> > > This also explains why the rotors were removed.
> > > (to allow the code wheels to be copied onto computer in order to
read
> > > any other documents they might obtain) ...
> > >
> > > Any comments ? (apart from "are you taking your medication" ? :-
) )
> > >
> > > BTW I would *really* appreciate it if anyone could shed any light
on
> > > this particular theory ...
> >
> > <snip logical sensible part>
> >
> > An enigma machine can be easily simulated in software.(
Ridiculously easily
> > to do). The design of this enigma was unusual, but there was
nothing that
> > prevenetd people from using publicly available information to
create a
> > piece of software that would do exactly what it does. The theory
is crap.
>
> Are you sure the exact specification of this version of the Enigma
> is public information?
>
> It might make an intriguing story if there are many Enigma
> encryptions that are held by the government hidden away or
> forgotten somewhere that might contain clues to hidden Nazi
> treasure. Or there may be Enigma encryptions that reside only
> in private hands.
Yeah, sounds plausible .
Who knows, maybe my idea could turn out to be true .
>
> Anyway, don't you think you were rather harsh in saying that his
> suggestion was "crap?"
>
--
Andre de Guerin
Email <[EMAIL PROTECTED]>
Who is "General Failure" and why is he reading my disk drive ?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: =?iso-8859-1?Q?Tom=E1s?= Perlines Hormann <[EMAIL PROTECTED]>
Subject: Q: Message length in RSA
Date: Thu, 19 Oct 2000 12:21:17 +0200
Hi all,
I have a question regarding RSA signing and encrypting.
If I take a 160 bit SHA-1 hash and sign it with my private key (1024
bits), how long is the signature going to be?
And if I encrypt another message (some session key) which is e.g. 256
bits long? How long is this message going to be?
Is there a difference in the length of my private key and my public key?
Everybody speeks about 1024 bit keys, but I read somewhere that both
lengths are different. Is this true?
TIA
--
Quick answering: mailto:[EMAIL PROTECTED]
Check it out: http://www.weh.rwth-aachen.de/~tomas
Do it Now!
:o) Tomás Perlines (o:
------------------------------
From: Arturo <[EMAIL PROTECTED]=NOSPAM>
Subject: Re: Is it trivial for NSA to crack these ciphers?
Date: Thu, 19 Oct 2000 12:10:17 +0200
On Thu, 19 Oct 2000 09:16:08 GMT, CiPHER <[EMAIL PROTECTED]> wrote:
>In article <8smb29$h14$[EMAIL PROTECTED]>,
> David Bernier <[EMAIL PROTECTED]> wrote:
>
>I would not be suprised if the intelligence agencies don't concentrate
>much at all on breaking the actual ciphers and instead try to get the
>information through other more easier methods... like say, a mole... or
>using key logging trojans... etc. etc.
>
>But of course, people at a crypto newsgroup are gonna want to think that
>crypto is the be all and end all, when it can broken simply by
>retrieving the 'plain-text' info by person or before it's encrypted.
>
Let´s face the fact. If a 3-letter-agency want our secrets, they´ll get
it, one way or another. What they won´t be able to do is sit comfortably at the
Fort and intercept any person´s communications at the push of a botton. If they
want to eavesdrop us, they´ll have to get theirs bottoms up the chair and do
some real work. That is, if we use encryption so the easy way in is blocked.
------------------------------
From: [EMAIL PROTECTED]
Subject: RSA codes
Date: Thu, 19 Oct 2000 11:31:55 GMT
Just a small question. RSA relies on people not being able to work out
the prime numbers that where used to generate the keys right? Well,
can't we just adapt the knapsack solution to break the key down into
it's part.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: RSA codes
Date: Thu, 19 Oct 2000 11:53:29 GMT
In article <8smm3b$op0$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Just a small question. RSA relies on people not being able to work out
> the prime numbers that where used to generate the keys right? Well,
> can't we just adapt the knapsack solution to break the key down into
> it's part.
Actually it's relies on the difficulting of finding logarithms modulo
the composite.
I fail to see how the "knapsack problem" applies...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Philip MacKenzie <[EMAIL PROTECTED]>
Subject: Re: srp-1.6.0 released
Date: Thu, 19 Oct 2000 07:57:56 -0400
Thomas Wu wrote:
>
> Philip MacKenzie <[EMAIL PROTECTED]> writes:
> >
> > SRP 1.5.2 is ***vulnerable*** to active attacks by
> > corrupt/spoofing servers!!!! That is, a spoofing server
> > can obtain enough information to launch an offline-dictionary
> > attack on a user, without the user even realizing it!
> > If you do not upgrade, you will be using software that
> > is potentially **weaker than ssh**, which is a shame since the
>
> Actually, since ssh is also vulnerable to active attacks by
> spoofing servers, it's potentially **as weak as** ssh UserAuth,
> but never weaker than.
>
It is weaker in the following way:
1. ssh is only vulnerable the first time you connect to a server
from a particular machine. After that, the server's public
key is stored on the user's machine.
2. When ssh receives a new public key from a server, it
informs the user that it has received an untrusted public key,
and so the user has some warning about a possible vulnerability.
In SRP 1.5.2, there is no warning, at least not an explicit one.
In fairness, SRP 1.5.2 does have the advantage that the spoofing
server still has to run an offline dictionary attack on the password
info, whereas in ssh, the spoofing server obtains the password
directly.
-Phil
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Q: Message length in RSA
Date: Thu, 19 Oct 2000 11:56:59 GMT
In article <[EMAIL PROTECTED]>,
=?iso-8859-1?Q?Tom=E1s?= Perlines Hormann <[EMAIL PROTECTED]>
wrote:
> Hi all,
>
> I have a question regarding RSA signing and encrypting.
> If I take a 160 bit SHA-1 hash and sign it with my private key (1024
> bits), how long is the signature going to be?
> And if I encrypt another message (some session key) which is e.g. 256
> bits long? How long is this message going to be?
> Is there a difference in the length of my private key and my public
key?
> Everybody speeks about 1024 bit keys, but I read somewhere that both
> lengths are different. Is this true?
Arrg... so many misconceptions so little time.
If your RSA modulus is 'n-bits' long then all of the RSA messages
are 'n-bits' long regardless of how many bits you fill up. For example
decrypting (signing) the 160-bit hash can be considered as signing 160-
bit hash + n-160 bits of padding. The result is always n-bits long.
Your RSA private key is the decryption exponent and is the same size as
well. Your RSA public key will most likely consist of the encryption
exponent (257 or 65537) and the modulus.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: RSA codes
Date: Thu, 19 Oct 2000 12:01:03 GMT
In article <8smnbo$pjg$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <8smm3b$op0$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > Just a small question. RSA relies on people not being able to work
out
> > the prime numbers that where used to generate the keys right? Well,
> > can't we just adapt the knapsack solution to break the key down into
> > it's part.
>
> Actually it's relies on the difficulting of finding logarithms modulo
> the composite.
>
> I fail to see how the "knapsack problem" applies...
This last comment does not surprise me. Tom often comments
on subjects for which he has inadequate knowledge.
The lattice basis reduction attacks on knapsack can be adapted
to factoring the modulus. But they are much more inefficient than
existing sieve methods.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
