Cryptography-Digest Digest #924, Volume #10 Tue, 18 Jan 00 16:13:01 EST
Contents:
Re: apology ([EMAIL PROTECTED])
Re: MIRDEK: more fun with playing cards. ([EMAIL PROTECTED])
Re: Questions about message digest functions (Tim Tyler)
Re: Suitable hash for this application - in the public domain? (Paul Koning)
Re: Implementing access controll in embeded controller (Mike Rosing)
Re: apology (Mike Rosing)
Re: NTRU Cryptosystems Inc. (Mike Rosing)
Re: 1on1lite (Was: Re: Echelon monitors this group) (Jim)
Re: Cracking an ADFGVX cipher (Jim)
Re: ECC vs RSA - A.J.Menezes responds to Schneier (Mike Rosing)
Re: 1on1lite (Was: Re: Echelon monitors this group) (Gary Woods)
Re: Suitable hash for this application - in the public domain? (Troed)
Re: UK Government challenge? (Angus Walker)
Re: ECC vs RSA - A.J.Menezes responds to Schneier (Greg)
Re: ECC (lordcow77)
Re: free C crypto API (Greg)
Re: ECC vs RSA - A.J.Menezes responds to Schneier (Greg)
Neue Site mit guten Links ("Peter Dassow")
Re: Cracking an ADFGVX cipher (Jim Gillogly)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: apology
Date: Tue, 18 Jan 2000 18:04:49 GMT
Don't be too hard on yourself. Phil Zimmerman, the
programmer who brought us PGP, had just such a false
start. Besides: I, as an extreme novice at all this,
enjoyed listening in - and it gave me some insight on
how to break a version of Dynamic Substitution (similar
to the one by Terry Ritter) I had been working on.
Saved me from posting mine, which would have had pretty
much the same result. I kind of wish we had a newsgroup
just for making and breaking this kind of "nonsense" :-)
Rex Stewart
In article
Jeff Lockwood <[EMAIL PROTECTED]> wrote:
>
> I finally realised what has happened.
>
<<cut>>
>
> Jeff Lockwood <[EMAIL PROTECTED]>
>
> PGP public key:
>
> homepages.ihug.com.au/~satan/pgpkey.asc
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: MIRDEK: more fun with playing cards.
Date: Tue, 18 Jan 2000 18:27:50 GMT
Actually, I like your idea, and will be trying it out in
the next couple of days. As a long time user of cyphers,
I have never found a stong hand cypher fast enough to
be practical. Solitaire is to slow (IMHO). I cannot seem
to get better than about 50 char per minute.
In the first year or so after it was published, I even
tried creating three of them myself, and got two to four
times the speed of Solitaire - but have managed to break
two out of three. The third one seems a lot like your
idea, but I will actually have to try it out to see what
the differences are.
Rex Stewart
In article "r.e.s." <[EMAIL PROTECTED]> wrote:
> :
<<cut>>
>
> Thanks for repeating my questions. I posted those ideas 3 days ago
> -- "Changing ARC4's State-Space Size") -- and have seen no reply.
> In that posting I also explain how to translate ARC4 source code into
> card-manipulations. (Is it too much to ask that replies to these
> ideas be posted in that thread which originated them?)
>
> --
> r.e.s.
> [EMAIL PROTECTED]
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Questions about message digest functions
Reply-To: [EMAIL PROTECTED]
Date: Tue, 18 Jan 2000 17:43:51 GMT
[EMAIL PROTECTED] wrote:
: Tim Tyler wrote
[snip]
:> I've already raised the issue that for a hash that needs
:> to exhibit collision-resistance (e.g. a hash used for signing
:> messages) a PRF is likely to fail to exhibit a distribution
:> that makes brute-force searching as hard as possible, under
:> what seem to me to be plausible assumptions.
: Actually the even distribution makes brute-force search for
: a second preimage *easier*. Suppose we have a hash that
: produces 160-bit digests that is a permutation (for messages
: that are also 160-bits), and we need to find a collision
: with a given message of any size larger than the digest. If
: we search the space of 160-bit messages, we will find a
: match in an average of 2^159 + 0.5 tries. That's almost
: exactly a factor of two faster than against a random
: function.
This is an interesting point. I agree with the conclusion.
If the attacker can choose any-sized message, having a bijective
map between hashes and some clearly-defined group of messages
seems to be undesirable.
:> While for smaller messages, it can become interesting
:> - particularly when getting a beter distribution
:> completely eliminates the has collisions that would
:> otherwise occur.
: As David Hopwood pointed out in hist post (worth re-reading)
: of 12/30/1999, all that shows is that some applications call
: for something other than a hash. It does nothing to redeem
: your claim that the random function model is "dead wrong"
: for cryptographic hash functions.
It appeared to me that the "applications that call for something other
than a hash" included signing messages and concentrating the
entropy-per-bit of a random file.
If hashes are not the appropriate tool for these sorts of application -
then I would consider renaming the appropriate tool, a hash.
It still appears that some signing applications (those with
restrictions placed on the message size) and (AFAICS) most practical
entropy-concentration applications, call for a distribution different
from the conventional model of a hash.
However, I'm inclined to agree that - in the case of signature
applications where there's an active attacker able to choose messages
of virtually any size - my suggestion that there should be a bijection
between hashes and messages of the size of the hash now appears to
have been pretty dubious.
:> IIRC, I said from the start my argument was only of any real practical
:> interest when dealing with messages that were typically small.
: From the start, myself and other have been explaining how
: hashes really are, and really should be modeled.
: You have yet to state your model. Obviously you want the
: preimages to map evenly to the digests [...]
Yes, exactly.
: [...] but from what probability space of functions do you think a hash
: should model a random choice? [...]
This will depend on the application. I'm trying to define the best
frequency-distribution of hashes in terms of the space of messages
it can be expected to be fed. This may well be different in different
applications.
It still appears to me that if there are /any/ limits placed on the size
of the possible messages, a random function will deviate from the ideal.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Fat people eats accumulates.
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Suitable hash for this application - in the public domain?
Date: Tue, 18 Jan 2000 13:20:58 -0500
Troed wrote:
>
> Hi,
>
> I need a good hash algorithm for storing user passwords. The hash will
> later be used in encryption routines. At the moment 32 bytes are used
> to store the hash, which far exceeds MD5 (not secure enough?) and
> SHA-1.
So what? MD5 is arguably long enough, and certainly SHA-1 is long
enough. So take the hash output from whichever one of those you
like, and either ignore the leftover bytes of that 32 byte field or
just cut it down to the size you have.
32 bytes for the hash is overkill.
paul
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Implementing access controll in embeded controller
Date: Tue, 18 Jan 2000 13:06:01 -0600
Niels Erik Danielsen wrote:
> I would prefer a system with a possibility of issuing a login name, and
> password to everyone, with optional time and serial number limitation of the
> passwords.
> And if a technician is having a problem that can't be solved by his present
> access level, he can contact the Service Support department, and get a new
> password, with a 'promotion' to 'superuser' on the machine with a particular
> serial-number valid for one week.
I assume that "remote" operation isn't desired in this situation? Would
it
be possible to add or change the users access level remotely?
>
> This technique resembles a software license key system, where the software
> distributed to all the customers is the same.
> But in order to use the software on a machine with a given Network card MAC
> address, you need a special license key in order to activate the software.
>
> We have the following information in our equipment.
> Serial number
> Time and Date from a GPS receiver.
> Name of the site where it's installed.
>
> I imagine an algorithm like this.
>
> 1) User enters login-name and password.
> 2) By analyzing the password it's determined if it have any limitations,
> e.g.. Year and Serial-number.
> 3) The login-name and password is string hashed.
> 4) The login-name, password, the year from the GPS receiver, and the serial
> number is passed trough an algorithm (S-Box'es ?) and is verified against
> the keys for the different access levels.
A simple hash will work fine. I assume that the physical access to the
internal
guts of your software is difficult to reverse engineer.
You just need to save access rights with hash data. As long as the hash
matches,
the rights are granted. If you must burn the data into rom by being
physically
present, then you can't include a time stamp. If you can reload the
data from
your central location, then you can change the password when the user
has
completed the job at the higher access level. This would allow you to
give the
user the same password each time, but it won't work unless they contact
you first.
>
> A PC program should then be able to generate a password to match any given
> username, and limitations, and access level, and keep track of the issued
> passwords.
As long as the user doesn't have access to the program, no problem. If
the
user runs the program, they can create any access level they want for
themselves.
> Questions
> I this the way to go ? I guess others have solved the same kind of problem.
> What kind of algorithms can be used in this application ?
> Is there any commercial products ? Freeware pieces of C code etc. ?
It depends on how you access the internal password tables. If you can
do it remotely over dedicated com links, it's very straight forward. If
you go over a phone line, and your customers are smart enough to tap the
line, you may want to protect the password tables. It's not a bad
solution,
but it's not clear what your full problem is either.
There are lots of algorithms to choose from, many of them free C code.
the most useful would be a hash function, so look for RIPEM-160 or
SHA-1.
There are many encryption algorithms too, but it's not clear you need
any.
(Depends on how you transfer the data to the RTOS).
> What worries me is how keys is distributed, is it always possible to
> generate a password for a user with a given login name, limitations, and
> access level ?
It is not easy to find a duplicate hash, but it's really easy to compute
the hash. So it's always possible to create the key in a very secure
way.
The hard part is putting the key into the system without the rest of the
world seeing it.
An example (which may not apply to your situation) would be to hash the
name,
password, limitations and access level into one chunk, then send the
name,
limitations, access level and hash to the user over the phone. When the
user
needs a higher access level, they call you up and get the new name and
password.
The RTOS checks that the name, input password, limitations and access
level
create the same hash as what is stored. The problem is that this has no
time limit, so you'd have to send a new table over the phone at the end
of
a week.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: apology
Date: Tue, 18 Jan 2000 13:17:02 -0600
Jeff Lockwood wrote:
>
> I finally realised what has happened. The silly thing I came up with is
> rubish. The methods I used would have been learned by some of you very
> early on, as examples of what not to do. If I were to continue with it, I
> would be most likely to only come up with more such examples.
>
> I will waste no more of your time with nonsense , and apologise for the
> time I have wasted already.
It's not wasted if you consider it one step on the learning ladder.
Keep reading, keep learning, and keep trying. It's a tall ladder :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: NTRU Cryptosystems Inc.
Date: Tue, 18 Jan 2000 13:13:13 -0600
David Wagner wrote:
>
> In article <85tp8l$465$[EMAIL PROTECTED]>,
> David A Molnar <[EMAIL PROTECTED]> wrote:
> > It's probably better just to ignore all the text and go straight to the
> > conference papers.
>
> Yes, I've read several of them, and the one I saw were fascinating and
> generally very well written. My complaint is, of course, not with the
> technical work, but rather with NTRU's marketing department.
That's a good sign tho! If they are putting their efforts into math
instead of marketing, there really is something there to pay attention
to.
I've enjoyed learning the math behind NTRU. It's actually pretty
straight forward. However, the cracking of it is way over my head,
so there's no easy way to describe how secure it is. Rather than
marketing, I'd like to see more math (but at a level I might be able
to understand!)
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Jim)
Crossposted-To:
alt.anarchism,alt.computer.security,alt.security,alt.security.espionage,alt.security.pgp
Subject: Re: 1on1lite (Was: Re: Echelon monitors this group)
Date: Tue, 18 Jan 2000 19:20:41 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 18 Jan 2000 07:59:19 GMT, [EMAIL PROTECTED]=NOSPAM (Arturo)
wrote:
>On Mon, 17 Jan 2000 19:13:19 GMT, [EMAIL PROTECTED]
>(Jim) wrote:
>
>>On Sun, 16 Jan 2000 18:18:20 +0100, "Thomas J. Boschloo" <[EMAIL PROTECTED]>
>>wrote:
>>
>>And radio-telescopes now radiate, do they?
>
> No, they don�t. They merely pick incoming radiation.
That's what I thought.
--
Jim,
nordland at lineone.net
amadeus at netcomuk.co.uk
------------------------------
From: [EMAIL PROTECTED] (Jim)
Subject: Re: Cracking an ADFGVX cipher
Date: Tue, 18 Jan 2000 19:20:46 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 17 Jan 2000 01:34:52 GMT, [EMAIL PROTECTED] (John
Savard) wrote:
>On Sun, 16 Jan 2000 22:30:13 GMT, [EMAIL PROTECTED]
>wrote, in part:
>
>>how do you crack an ADFGVX cipher that has over 36 character (64) and
>>possibly homophones?
>
>The account of how the original ADFGX cipher was broken in David
>Kahn's book "The Codebreakers" is the only one I'm familiar with, and
>that one depended on the interception of two messages which had
>identical beginnings.
Actually, a message sent in the new ADFGVX was repeated in the old
ADFGX because the recipient didn't yet have the new cipher and had to
have it repeated in the old. :o((
They compromised it on day one!
--
Jim,
nordland at lineone.net
amadeus at netcomuk.co.uk
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: ECC vs RSA - A.J.Menezes responds to Schneier
Date: Tue, 18 Jan 2000 13:26:04 -0600
JCA wrote:
>
> While this is true, I can't help wondering if it has any value beyond
> the
> purely academic one?
Moore's law isn't academic. ECC will replace RSA over time in new
applications.
Old applications will keep on using RSA, until the key sizes get too
unwieldy.
ECC will make things run faster (and "faster better cheaper" is the
mantra),
no matter what the thing is.
It won't happen in a year. But in 5 years, ECC will be in as many
applications
as RSA is, and in 10 years, ECC will be in twice as many applications.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Gary Woods)
Crossposted-To:
alt.anarchism,alt.computer.security,alt.security,alt.security.espionage,alt.security.pgp
Subject: Re: 1on1lite (Was: Re: Echelon monitors this group)
Date: Tue, 18 Jan 2000 19:52:01 GMT
[EMAIL PROTECTED]=NOSPAM (Arturo) wrote:
>>And radio-telescopes now radiate, do they?
>
> No, they don´t. They merely pick incoming radiation.
Unless they're being used as radars to probe, say, Venus. It's all what
you hang out there at the prime focus.
------------------------------
From: [EMAIL PROTECTED] (Troed)
Subject: Re: Suitable hash for this application - in the public domain?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 18 Jan 2000 19:55:57 GMT
Paul Koning <[EMAIL PROTECTED]> wrote:
>So what? MD5 is arguably long enough, and certainly SHA-1 is long
>enough. So take the hash output from whichever one of those you
>like, and either ignore the leftover bytes of that 32 byte field or
>just cut it down to the size you have.
>
>32 bytes for the hash is overkill.
Since it's later used for encryption, it would be a lot more
interesting if you answer my question instead.
Are these algorithms (RIPE-MD was the example) free for commercial
use? Does that apply to the verious implementations on the net? (they
have no special copyright headers etc)
(And is MD5 considered secure enough today?)
___/
_/
------------------------------
From: Angus Walker <[EMAIL PROTECTED]>
Subject: Re: UK Government challenge?
Date: Tue, 18 Jan 2000 08:31:04 +0000
>Any chance that you'll be helping then to run 'Echelon' in the near
>future, then?
No
--
Angus Walker
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: ECC vs RSA - A.J.Menezes responds to Schneier
Date: Tue, 18 Jan 2000 20:20:06 GMT
> > I believe that if ECC were to replace RSA as the standard pub key
> > cipher in massively available and commonly used software packages
> > like SSL, perception over ECC's quality of strength and its
commercial
> > acceptance would change in one year's time.
>
> Well, yes. But that is precisely the issue. There are no solid
reasons
> why
> ECC should replace RSA, at least not as of today.
IMHO the key size is THE compelling reason to begin making the
change today. Or does anyone seriously believe that an RSA
key size exceeding 10k is acceptable?
--
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: lordcow77 <[EMAIL PROTECTED]>
Subject: Re: ECC
Date: Tue, 18 Jan 2000 12:48:04 -0800
I think that the original poster's comment that the operations in F_p
seem much simplier refers not to efficiency, but rather to
implementation difficult. The math in F_p would seem more familiar to a
person who has already had experience implementing, for example, RSA.
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: free C crypto API
Date: Tue, 18 Jan 2000 20:47:54 GMT
> Well I decided to release CB a bit early. I am looking for
> comments/suggestions/improvements.
>
> Basically CB is a complete crypto API. It can make/use RSA crypto,
> symmetric crypto, has data compression, a RNG, base64 routines and
more.
>
> It doen't read/write PGP messages/keys since that was not part of the
> plan.
>
> I am using CB in my Peekboo III release [which is gonna rock].
>
> All of this is free!!!
I downloaded a copy of your stuff and noticed that you did not
ask me anything. Where is the server located?
--
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: ECC vs RSA - A.J.Menezes responds to Schneier
Date: Tue, 18 Jan 2000 20:45:33 GMT
In article <[EMAIL PROTECTED]>,
JCA <[EMAIL PROTECTED]> wrote:
> Greg wrote:
>
> > In article <85ve97$do2$[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] wrote:
> > > Alfred Menezes comments on B.Schneiers article comparing RSA vs
ECC.
> > >
> > > Available at:
> > > http://www.cacr.math.uwaterloo.ca/~ajmeneze/misc/cryptogram-
> > article.html
> > >
> > > Comments?
> >
> > He goes on to say...
> >
> > The rough estimates of RSA key lengths for equivalent security
> > are 3072 bits, 7680 bits, and 15630 bits. Imagine the performance
> > degradation incurred with RSA implementations at these key sizes,
> > even with e=3!!
> >
> > Exactly...
>
> While this is true, I can't help wondering if it has any value
beyond
> the
> purely academic one?
Yes, it could be. But on the other hand, if there are going to
be any advancements against either, then ECC has a lot more room
to grow than RSA/IFP.
In fact, you can use 571 ECC field sizes today on your PC with
reasonable performance. And this field size is likely to remain
formidable even against a sub ex attack discovery- that is, such
a discovery does not necessarily spell "exposure" right away.
Can you say this about RSA? Is a 20k RSA key reasonable with PCs
today? Or is a 3k RSA key likely to remain formidable in the face
of the next advancement against RSA/IFP?
That is how I see it. I see both being searched for weaknesses
and if any can be found, it is just a matter of time.
--
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Peter Dassow" <[EMAIL PROTECTED]>
Subject: Neue Site mit guten Links
Date: Tue, 18 Jan 2000 22:05:56 +0100
Schaut doch mal nach unter der URL: www.email-security.de , vielleicht
findet Ihr ein paar interessante Infos...
Gruss
Peter
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Cracking an ADFGVX cipher
Date: Tue, 18 Jan 2000 21:07:28 +0000
"Douglas A. Gwyn" wrote:
> I vaguely recall that Friedman's monograph on the subject had been
> declassified and released to the National Archives. But I could be
> mistaken..
You're correct. I liberated a copy during my xerox orgy at NARA
last October. It's called "General Solution for the ADFGVX Cipher
System", and it's in SRH-331, Box 103, record group 457. The method
is based on inhomogeneities in the substitution checkerboard.
Based on the description of the particular variant of ADFGVX of
interest to the original poster here, I'll add that the attack I
used on the cipher he's trying to crack used this entry also,
although I hadn't seen the Friedman paper at that point. Your
main problem is to reverse the transposition in such a way that
the distribution of the resulting checkerboard is what you expect...
whatever that might be.
--
Jim Gillogly
Highday, 27 Afteryule S.R. 2000, 21:02
12.19.6.15.17, 13 Caban 5 Muan, Second Lord of Night
------------------------------
** 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
******************************
