Cryptography-Digest Digest #232, Volume #10 Tue, 14 Sep 99 13:13:03 EDT
Contents:
Re: Looking for Completely-Free Strong Algorithms (Paul Crowley)
Re: Sources of randomness (Paul Crowley)
Re: primes in dh (Tom St Denis)
Re: H.235 Keys from Passwords algorithm (David A Molnar)
Re: Make a point on KRYPTOS ("collomb")
Re: Can you believe this?? (John Savard)
Re: Neal Stephenson's Cryptonomicon: Crypto Cop-Out (John Savard)
Can you believe this?? (Anonymous)
Re: Creation of Tokens ! (Vin McLellan)
Re: RSA Algorithm (Michael J. Fromberger)
bug in peekboo (Tom St Denis)
Re: Mystery inc. (Beale cyphers) ([EMAIL PROTECTED])
How strong is RC4 ? (yoni)
Re: RSA Algorithm (Walter Hofmann)
Mathematical models and encryption ("Tom Pedersen")
Re: Mystery inc. (Beale cyphers) ("Douglas A. Gwyn")
Re: Make a point on KRYPTOS (Jim Gillogly)
Re: RC4-40 Cracking (Ian Goldberg)
----------------------------------------------------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Looking for Completely-Free Strong Algorithms
Date: 14 Sep 1999 09:40:23 +0100
"Joseph Ashwood" <[EMAIL PROTECTED]> writes:
> > OK, are all the different streams in the session protected by the same
> > shared secret?
> There will be different key for each one, or if it's the same key there will
> be obfuscation put in place so that they are no longer the same key (e.g.
> different initialization vectors).
Using a new initialisation vector is much cheaper than using a new
key: you don't have to schedule an IV. Also, you can simply send the
IV in plaintext along with the new stream: you don't have to negotiate
a new secret.
> It's also extremely doubtful that any of the information will ever
> be repeated, probably a 1:2^36 for a 64-bit block, but I'm trying to
> lower it further.
You shouldn't have to craft your data to suit the crypto: select the
crypto so it'll protect the data no matter what it is. Otherwise you
have a whole raft of extra code that has to be correct and secure for
your protocol to be secure.
And anyway, it's not two repeated plaintext blocks that cause the
trouble with a chaining mode, it's repeated ciphertext blocks.
Counter modes don't have this problem.
Conservative choice: Triple-DES in counter mode
Fast and sexy choice: Twofish or Rijndael in CBC or CFB mode.
hope this helps,
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Sources of randomness
Date: 14 Sep 1999 09:52:52 +0100
[EMAIL PROTECTED] writes:
> We wouldn't want to filter out the non-randomness, so
> much as condense down the randomness. A good method
> is to XOR the low entropy source bit stream into the
> feedback of a large linear feedback shift register
> (with taps corresponding to a primitive polynomial,
> as usual). The nice fact about the technique is that
> as long as the source stream is independent of the
> register state, the register never loses entropy.
Even better would be to PUSH all of the random data into Panama, which
keeps a 1kbyte-wide shift register as part of its state, as well as a
big non-linear mixer. Then you can PULL all the words you like out
of it. See http://www.esat.kuleuven.ac.be/~rijmen/daemen.html
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: primes in dh
Date: Tue, 14 Sep 1999 11:31:13 GMT
In article <RubD3.1011$[EMAIL PROTECTED]>,
"Michael Scott" <[EMAIL PROTECTED]> wrote:
b478a3fa33b1eac4ac8838ff8118999aacd9ea174143f0a9e06b68004836c63598897ae0e873
> 8764659b3902926258df809a5453b50d57438a3c765b1ea9e64089606376fd6da94a43686d8e
> 3fe574eb5b77d55d1b84a9de2dd96042938036837082f753f42296696a808e5df937a48c3b5f
> fe5c509752227b14c17f612d9950370337d62dcad7031071a3710b5ed7c59e061eb6540a8b10
> 8318f0334a6bd6780da6ebdc4988b658a42d8a57548019811f41af62aa463562c3cdd3db018a
> 91fb956d6663ddea34c427935177611d3eaa883f1665eb036e3423dbfea9bafe81513dde34f3
> 056d6014b081404ca205ba2858434d55b91764a2703e46578f9e254f
> > ......
> > >
> > > > Can I iterate this to find one or is there a more efficient method? I
> just
> > need a single generator. So I iterate this from G = 2 to n can I expect
> to
> > find a generator soon?
> > (all new to me :) )
>
> Simpler than that. Use G=3 or G=4. Either will generate the prime order
> subgroup, of order (p-1)/2.
Ok well for now I will use G=3 and the prime as previously posted. The code
actually works in peekboo (hehehe) but I want to make sure I got the math
right...
A 'beta' (i.e hack me to death) version with source will be out on friday.
Tom
--
damn windows... new PGP key!!!
http://people.goplay.com/tomstdenis/key.pgp
(this time I have a backup of the secret key)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: H.235 Keys from Passwords algorithm
Date: 14 Sep 1999 12:20:36 GMT
Douglas Clowes <[EMAIL PROTECTED]> wrote:
>>> Douglas Clowes wrote:
>>>>
>>>> Section 10.3.2 of ITU-T H.235 states in part:
>>>>
>>[a hash function which doesn't look collision resistant]
>>
>>When was this standard written?
> Oh, 1997 - yep, just two years ago :-(
Yuck. Do people actually have to conform to this?
(and who are they, so I can avoid them?)
------------------------------
From: "collomb" <[EMAIL PROTECTED]>
Subject: Re: Make a point on KRYPTOS
Date: 14 Sep 1999 12:37:32 GMT
Jim Gillogly wrote :
> However, the only thing I've seen in the news articles indicating they
were
<intended> to be
> solved with pencil and paper was from David Stein of the CIA -- not
> from Sanborn or Scheidt. I'd be very interested if someone had an
> authoritative reference on this.
I visited two months ago the website IA'S which mentionned John Markoff
article
in the N.Y.Times of June 16, 1999 in which he write that M. Stein told :
-il is <intended> to be solved only with paper and pencil.
Best regards
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Can you believe this??
Date: Tue, 14 Sep 1999 14:04:59 GMT
Anonymous <[EMAIL PROTECTED]> wrote, in part:
>Can you all believe that someone is actually trying to get $59.95 for a
>program that uses an algorithm that they refuse to publish? It is not mine!
>Is this a joke?
No. After all, if they published the algorithm, anyone could write a
program using the same algorithm!
That there is a teensy little problem in the *specific* area of
cryptography, making it impossible to know if a program is secure or
not unless one knows the algorithm, is something not every software
developer quite understands.
So it is no joke; it sadly happens *all too often*.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: rec.arts.sf.written,alt.cyberpunk
Subject: Re: Neal Stephenson's Cryptonomicon: Crypto Cop-Out
Date: Tue, 14 Sep 1999 14:13:45 GMT
[EMAIL PROTECTED] (Ian) wrote, in part:
>And
>when you are talking about fundamental aspects of a national economy and
>tax base, and issues that will be very important to the individual citizens
>as well, there is one thing you will NOT see. And that is the people and
>the government saying "Oh gee whiz, it's hard to keep up with this new
>system, guess we have no choice but to give in and fly wherever the wind
>happens to blow us".
There are those who believe we are already seeing this right now,
which is why we aren't seeing a vast grassroots political movement
saying "This globalization stuff is putting money in the pockets of
the rich; we've got to ban cheap overseas imports, and return to the
good old days when unions were strong and TV sets and cars were made
in America (or Canada, as the case may be)".
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
Date: Tue, 14 Sep 1999 15:44:49 +0200 (CEST)
From: Anonymous <[EMAIL PROTECTED]>
Subject: Can you believe this??
Can you all believe that someone is actually trying to get $59.95 for a
program that uses an algorithm that they refuse to publish? It is not mine!
Is this a joke?
http://www.coredcs.com/~encrypt/secure.html
------------------------------
From: Vin McLellan <[EMAIL PROTECTED]>
Subject: Re: Creation of Tokens !
Date: Tue, 14 Sep 1999 09:54:40 -0300
Robert Depenbrock wrote:
> is ther somewhere a documentation, how to get Tokens ?
> I have some experience with the use of the SecurID Token Cards, and i
> wonder, if there are
> any Freeware Token Creation Hardware, or Software available ?
SecurID, with ACE/Server support, from SDTI (now RSA Security) is a
time-synched authentication token which uses a proprietary hash to
mangle a token-specific secret seed and Current Time. A SecurID token
continuously calculates and displays a 6-8 digit (or alphanumeric)
token-code which changes every 60 seconds.
For "ease of use," you're probably spoiled I you have been using
SecurIDs -- but the mechanics of a servicable token should not be very
difficult to figure out, and with PDA palmtops like the 3Com's
PalmPilot, no great challenge to code.
You might check out the (not-free) SecurePilot
<http://www.securepilot.com> as one example of this. I presume there
are freeware competitors, but I don't know them by name. SecurePilot's
token emulator, pSNK, is compatable with, variously, CryptoCARD,
Activcard, SafeWord, and SNK-004 tokens.(SDTI/RSA, for which I've done
a lot of consulting, offers SecurID functionality in software for the
PalmPilot too. See: <http://www.securid.com/go/palmdemo.html>.)
SDTI has a patent on the way Current Time on the server and in each
SecurID are kept synchronized, but I don't believe there are any
meaningful patents that restrict anyone from using the technologies
common to the whole class of challenge/response tokens (or wholly
software token-emulators.)
In the classical asynchronous or challenge/response (C/R) scheme, a
pseudo-random "challenge" is broadcast from the authentication server,
manually typed into a calculator or smart token, and then encrypted or
hashed, in the token, with a secret key that is shared between the
token and the server. The user then types the calculated "response" on
a keyboard and ships it off to the authentication server.
In practice, most Administrators will want to buttress any one-time
password (OTP) generator with a memorized secret, so that they get the
benefit of two-factor authentication.
One still popular token option would be an S/key (aka OPIE or OTP)
calculator. See: <http://inner.net/opie> and
<http://www-v4.ipv6.nrl.navy.mil/ist/pub/rfc2289.txt>.
Smartcards and readers for PKC keys and certs, typically used to
digitally sign a nonce "challenge," are readily available. While
seldom free, they are not very expensive in developer startup or pilot
kits.
Your choices will depend a great deal upon what you seek to secure,
and against what range of threats, and how small or large your user
community is. Managing user data and the authentication process
(securely) at the authentication server can be a challenge for a user
community of any size.
For Apache, the popular freeware webserver, however, I believe you
will find a number of Perl C/R modules at CSPAN:
<http://theory.uwinnipeg.ca/CPAN/by-category/14_Security_and_Encryption.html>.
For a broader perspective, you may also want to look at the "RSA
Authentication" scheme used in SSH, and maybe read RFC 2095: "IMAP/POP
Authorize Extension for Simple Challenge/Response," at:
<http://www.isi.edu/in-notes/rfc2195.txt>.
You might also check out the EKE options like David Jablon's SPEKE
<http://www.IntegritySciences.com/> or Tom Wu's SRP
<http://srp.stanford.edu/srp>, which hide a user's password in the
dense tangle of a D-H key exchange.
Tokens, per se, supported by any basic authentication server, usually
defend against passive eavesdropping and replay attacks -- but a
network needs real link or session crypto to defend against active
network attacks like TCP splicing or session hijacking.
Hope this helps.
Suerte,
_Vin
------------------------------
From: Michael J. Fromberger <[EMAIL PROTECTED]>
Subject: Re: RSA Algorithm
Date: 14 Sep 1999 12:58:19 GMT
In <01befe93$7ab0b040$0164640a@server> "Gary Partis" <[EMAIL PROTECTED]> writes:
>Hi,
>We have implemented a sub-set of RSA (the EXP bit) in Z80 and even
>after extensive optimisation (and dedicated hardware to handle big
>numbers), it is still slow.... :-(
>In the standard algorithm, the MULMOD (C=A * Z MOD P) code is called
>extensively, and this code it's self is highly iterative (128 times
>for a 128bit key) per call, and it is called a few hundred times per
>encryption and decryption.
>Does any one know of an algorithm which overcomes this performance
>issue, or if there is a set of 128bit keys/modulus which minimises
>the need to call the MULMOD code from the EXP code?
>I realise this is an implementation problem - as the Z80 is an old
>8bit micro, but any help would be useful.
A lot of this depends on how your MULMOD code works. If you're
multiplying, then using the division algorithm to compute the
remainder, you could probably improve on this somewhat using Barrett's
reduction algorithm instead. A good description of this is given in
Chapter 14 of the _Handbook of Applied Cryptography_ (Menezes, et
al.). Basically, instead of doing division at each step, you perform
one precomputational division, and then the reductions at each step of
modular exponentiation are reducible to shift and mask operations,
along with subtraction.
Especially on a little 8-bit micro, that could significantly improve
your runtimes for modular exponentiation.
-M
--
Michael J. Fromberger Software Engineer, Thayer School of Engineering
sting <at> linguist.dartmouth.edu http://www.dartmouth.edu/~sting/
7Y+Am9Ot9EbLLcCgT/BdGdprlj9L6Cy4v1n+KCbbPoU9ucMcLa6wfvoN4NWRMAZdOvBPTJzj
Remove clothing if you wish to reply to this message via e-mail.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: bug in peekboo
Date: Tue, 14 Sep 1999 13:52:38 GMT
I found the first bug in peekboo :)
The keyschedule in the serpent code does not work... I will have it
fixed for the v1.4. I also want to test against some vectors....
If anyone else wants to test the code or help find bugs...
http://www.cell2000.net/security/peekboo/index.html
Tom
--
damn windows... new PGP key!!!
http://people.goplay.com/tomstdenis/key.pgp
(this time I have a backup of the secret key)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Mystery inc. (Beale cyphers)
Date: Tue, 14 Sep 1999 14:11:59 GMT
In article <[EMAIL PROTECTED]>,
sha99y00000 <[EMAIL PROTECTED]> wrote:
> <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
> <html>
> <blockquote TYPE=CITE>
> <br>Carl Hammer wrote a paper discussing the statistical properties of
> B1 and <br>B2, and concluded that they were enciphered in the same
general system. <br> </blockquote>
>
> <p><br>People keep quoting work that other people have done. This is
not attack against you Jim, but I can't find these papers. I've
tried the search engines. I came across Hart's but that ended up
a dead link. I've tried the crypto drop box,. again no luck. Is there
any chance of posting or forwarding me to where I can find these works.
>>
I see you are posting from the UK and I don't know what your
options are there. However, in the US, the Interlibrary Loan
department of any public library can get copies of articles from other
libraries. Perhaps this service is available in the UK as well.
Hammer, Dr. Carl, "Signature Simulation and Certain Cryptographic
Codes", Communications of the ACM, January 1971, Volume 14,
Number 1, pp. 3-14.
By the way, can you turn off the <.html> coding when you post? It
would make your posts easier to read.
-- Jeff Hill
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Tue, 14 Sep 1999 16:30:07 +0200
From: yoni <[EMAIL PROTECTED]>
Subject: How strong is RC4 ?
Hello,
I want to use a secured socket that uses RC4 to encrypt data sent from a
client to a server, The key is known to both sides.
An attacker can collect the messages passed and analyze them or even try
to make a chosen text attack and reconstruct the key.
What is the streangth of RC4 (and stream ciphers generally) against such
attacks ?
How much time can I use a 128 bits key before I need to replace it ?
Thank you,
Yoni.
------------------------------
From: Walter Hofmann <[EMAIL PROTECTED]>
Subject: Re: RSA Algorithm
Date: Tue, 14 Sep 1999 17:45:05 +0200
Gary Partis <[EMAIL PROTECTED]> wrote:
> Does any one know of an algorithm which overcomes this performance issue,
> or if there is a set of 128bit keys/modulus which minimises the need to
> call the MULMOD code from the EXP code?
You could try to see how other implementations do that. The GNU MPI
library has the required functions, is pretty fast and the source is
available.
I cannot see how 128 bits can provide any security, though.
Walter
------------------------------
From: "Tom Pedersen" <[EMAIL PROTECTED]>
Subject: Mathematical models and encryption
Date: Thu, 9 Sep 1999 20:53:56 +0200
How would you characterize a mathematical model in the field of cryoptology?
Can you in fact speak of models and cryptology at the same time?
For instance is RSA-encryption a model for sending a message from a
transmitter to a reciever or is it only a method/algorithm?
If there _are_ models - then where is the line between a model and a simple
method?
-Tom Pedersen
[EMAIL PROTECTED]
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Mystery inc. (Beale cyphers)
Date: Tue, 14 Sep 1999 13:56:40 GMT
Curt Welch wrote:
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> > Curt Welch wrote:
> > > The alphabetic strings that appear when #1 is decoded with the DOI
> > > is far from random so that's a _big_ clue to the encoding.
> > Unfortunately, the better those clues, the *more* likely that it is
> > all a hoax. The reason is, this *type* of cipher does *not* produce
> > long alphabetic runs
> A multiple substitution cypher has enough degrees of freedom to make
> it very easy to create the long alphabetic runs when decoding the cypher
> with the wrong key.
No, this *type* of cipher (keyed as in Beale #2) is *not* at all
likely to produce long alphabetic runs from decrypting with the
wrong key. Remember, the key is constrained to be an actual,
readily available document; it is not constructed artificially
to produce that particular phenomenon.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Make a point on KRYPTOS
Date: Tue, 14 Sep 1999 16:28:58 +0000
collomb wrote:
>
> Jim Gillogly wrote :
> > However, the only thing I've seen in the news articles indicating they
> were
> <intended> to be
> > solved with pencil and paper was from David Stein of the CIA -- not
> > from Sanborn or Scheidt. I'd be very interested if someone had an
> > authoritative reference on this.
>
> I visited two months ago the website IA'S which mentionned John Markoff
> article
> in the N.Y.Times of June 16, 1999 in which he write that M. Stein told :
> -il is <intended> to be solved only with paper and pencil.
Yes, but Mr. Stein is neither the sculptor nor the cryptographic consultant.
I have seen no justification of Stein's remark from a source who knows.
There are certainly no ground rules cut into the sculpture.
--
Jim Gillogly
Highday, 23 Halimath S.R. 1999, 16:27
12.19.6.9.11, 4 Chuen 19 Mol, Second Lord of Night
------------------------------
From: [EMAIL PROTECTED] (Ian Goldberg)
Subject: Re: RC4-40 Cracking
Date: 14 Sep 1999 16:26:49 GMT
In article <7rlqth$47u$[EMAIL PROTECTED]>,
Dafydd Richards <[EMAIL PROTECTED]> wrote:
>Please could somebody post/email rough estimates for the following please
>:-
>
>1) How much time would a machine on a $30,000 budget take to crack RC4-40.
>
>2) How much would it cost to construct a machine to crack RC4-40 in say half
>an hour.
Well, I just ran the old BruteSSL 1.0 code (from 1995) on my PIII-450,
and (without even recompiling), it searches 139800 keys per second.
That works out to 2185 hours, or about 3 months, on one processor.
So it would take about 4000 similar processors to break it in half an hour.
(Actually, only 2000 processors for the average case.)
But talking about "budget" is pretty meaningless; you've *got* these machines
already. distributed.net, for example, is eating more computrons than
this. And I'm not going to try to work out how much it would cost to
*design and build* a custom machine; commodity processors are pretty cheap.
- Ian
------------------------------
** 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
******************************
