Cryptography-Digest Digest #919, Volume #10 Mon, 17 Jan 00 16:13:01 EST
Contents:
Re: Triple-DES and NSA??? (Jose Castejon-Amenedo)
RSA survey (Tom St Denis)
Re: Triple-DES and NSA??? (mdc)
Re: ECC vs RSA - A.J.Menezes responds to Schneier (Jose Castejon-Amenedo)
Re: crypt() (fvw)
Re: Cracking an ADFGVX cipher (John Savard)
Re: 1on1lite (Was: Re: Echelon monitors this group) (Jim)
free C crypto API (Tom St Denis)
Re: New Crypto Regulations (wtshaw)
Re: "1:1 adaptive huffman compression" doesn't work (Tim Tyler)
Re: is signing a signature with RSA risky? (Tim Tyler)
Re: New Crypto Regulations (John Savard)
Re: New Crypto Regulations (John Savard)
Re: LSFR (Eric Bach)
Question about factoring method. (MENIER Clement)
Suitable hash for this application - in the public domain? (Troed)
Help -Perl encryption
If enough is good, why is more better ? Re: Triple-DES and NSA??? (Padgett 0sirius)
Re: Why is EDI dead? Is S/MIME 'safe'? Who and why? (Padgett 0sirius)
----------------------------------------------------------------------------
From: Jose Castejon-Amenedo <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.security
Subject: Re: Triple-DES and NSA???
Date: Mon, 17 Jan 2000 09:21:28 -0800
anonymous wrote:
> Did the NSA screw around with Triple-DES like they did with DES back in
> the 70s? How secure is it in comparison to blowfish and other
> algorithms?
Why do you mean 'screw around'? My understanding is that most of the
mysteries surrounding DES (e.g. the S-boxes design, number of rounds)
turned out to be precautions that NSA took against attacks at at the time
were known to them but not to academia (e.g. differential cryptanalysis.)
For all we know, the NSA's intervention made DES more (not less)
robust than it would have otherwise been.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: RSA survey
Date: Mon, 17 Jan 2000 17:48:48 GMT
Just a quick survey... What size of RSA key would you feel safe with
for your crypto needs?
[ignoring the symmetric side of things...]
I ask just to get a feel for things as I write Peekboo III [my freeware
crypto program].
BTW if you check out Peekboo II and have comments let me and the group
know. I hope this doesn't seem like spam... the source is online as
well so it can be slightly educational.
BTWx2 as a added bonus I will be releasing a free crypto API [in C] in
a few days. It will be up at http://www.dasoft.org/tom/cb.html in a
few days... All free stuff!!!
Tom
--
[EMAIL PROTECTED]
http://peekboo.dasoft.org
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (mdc)
Crossposted-To: alt.privacy,alt.security
Subject: Re: Triple-DES and NSA???
Date: Mon, 17 Jan 2000 17:57:25 GMT
On Sat, 15 Jan 2000 03:41:19 GMT, Greg <[EMAIL PROTECTED]> wrote:
>
>> ... On the other hand, this variant of DES has an effective key
>> length of 112 bits (two 56-bit keys) while Blowfish can use
>> up to 468 bits.
>
>Is Twofish a next generation work from Blowfish, or are they
>similar in name only?
It is the next generation in the sense that Bruce Schneier, who
designed Blowfish, was on the TwoFish team and and all his
experience on the former was applied to the latter. However,
I think TwoFish was created "from scratch" rather than being a
direct evolution of the Blowfish design.
>And can one use a key size larger than 256 on Twofish?
Twofish can use 128-, 192-, and 256-bit keys. Details at
http://www.counterpane.com/twofish.html
Michael
------------------------------
From: Jose Castejon-Amenedo <[EMAIL PROTECTED]>
Subject: Re: ECC vs RSA - A.J.Menezes responds to Schneier
Date: Mon, 17 Jan 2000 09:56:49 -0800
[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?
>
I have just attended a series of lectures on ECC given by A. Menezes
and S. Vanstone. AM expressed his views on the subject in a sort-of
colophon lecture, in which he expanded somewhat on what he says on the
article above.
My feelings overall are that ECC is a serious contender in the realm of
public key cryptography. In a number of senses, it can be argued that its
potentiality goes beyond that of RSA - not only does it require shorter key
lengths to provide security levels analogous to those of RSA but, in
addition, the hardness of the mathematical problem that one needs to solve
in order to crack ECC (to wit, that of computing discrete logarithms on
elliptic curves defined on an appropriately chosen finite field) seems to
rest on a more solid mathematical footing than its RSA counterpart: the
modular cube root problem, which corresponds to e=3 in RSA, might be easier
than integer factorization. And we don't even know for sure if IF is NP.
On the other hand, it seems to be the case that the resources argument
in pro of ECC over RSA is losing strength all the time, as the hardware
associated with smartcards, PDAs and similar gadgets becomes more powerful
all the time. Likewise, I am not sure AM's arguments on ECC's scrutiny are
convincing. I still believe that RSA has been subjected to more thorough
studies, although it is true that any abstract results on the discrete
logarithm problem apply to ECC.
Perhaps a more serious issue ath this stage a comparative lack of
standardization in the ECC world. There are standards all right, but they
don't yet have the pervasiveness that the de facto RSA one has. My feeling
is that one of the problems in the way of a wider ECC adoption might be
this one.
The bottom line is, ECC is a valid, quite mature technology that should
coexist and compete with RSA on an equal footing. I don't think that the
shorter keys it has to offer really justify an en masse migration from RSA,
at least not yet. At any rate, a leading edge crypto product should
certainly support them both -- RSA's BSAFE crypto kit already does.
------------------------------
From: [EMAIL PROTECTED] (fvw)
Subject: Re: crypt()
Reply-To: [EMAIL PROTECTED]
Date: Mon, 17 Jan 2000 18:36:09 GMT
In <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>I am trying to take a password and encrypt it on Linux (Slackware 7). I
>have tried using the crypt() function. However, this function generates
>a 13 character string. In my Linux shadow file, the password field is 34
>characters. Is there a function similar to crypt() that I can use to
>encrypt my passwords? I am trying to incorporate this into a C program.
Most current linux distro's use md5 passwords. For some code that does md5,
have a look at the source for md5sum at ftp.gnu.org (It's in the textutils
package iirc).
--
Frank v Waveren
[EMAIL PROTECTED]
ICQ# 10074100
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Cracking an ADFGVX cipher
Date: Mon, 17 Jan 2000 11:51:38 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.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
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: Mon, 17 Jan 2000 19:13:19 GMT
Reply-To: [EMAIL PROTECTED]
On Sun, 16 Jan 2000 18:18:20 +0100, "Thomas J. Boschloo" <[EMAIL PROTECTED]>
wrote:
>> We have even bypassed the arguments about how random a
>> random number generator can be. Passwords are derived from truly
>> random and totally unpredictable sources such as stock market quotes,
>> background noise from several university radio telescopes, and
>> internet search times.
>
>Wow, stock quotes. Now *THAT* is a good source of randomness. I'm
>getting a warm fuzzy feeling. I wonder where they get their random
>background noise BTW <grin> www.nasa.org?
And radio-telescopes now radiate, do they?
--
Jim,
nordland at lineone.net
amadeus at netcomuk.co.uk
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: free C crypto API
Date: Mon, 17 Jan 2000 19:13:39 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!!!
Check it out at
http://www.dasoft.org/tom/cb.html
If you want to check out Peekboo II, my ultra cool and free crypto
program [it has many features as well] it's at
http://peekboo.dasoft.org
--
Currently I am working on PB III, so stay tuned!! If you have
suggestions for PB III please email me, I would love to hear em.
Tom
--
[EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: New Crypto Regulations
Date: Mon, 17 Jan 2000 13:49:40 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED]=NOSPAM (Arturo) wrote:
> On Fri, 14 Jan 2000 10:27:17 -0700, "John E. Kuslich"
> <[EMAIL PROTECTED]> wrote:
>
> >I hereby dare anyone to tell me that he/she has read and understood the
> >new crypto regulations. They are simply beyond comprehension and
> >deliberately so. These regs will make many a lawyer rich!
> >
> >see http://www.cdt.org/crypto/admin/000110cryptoregs.shtml
> >
> >What kind of government can get away with making laws the meaning of
> >which are not clear until such time as one is prosecuted for violating
> >such laws?
>
> Currently, about 90% of them
When a government acts this way, it runs the risk of being replaced or
simply ignored.
If a blank piece of paper was defined as they address any crypto export
problem, the government whole define a list of things not to put one the
problem.
Here is my simple proposed regulation: If you know a county or individual
is on unfriendly terms with our country, is on a list as an enemy or
realistic potential enemy, do not trade, sell, or funinsh any information
to them. If they are publically defined as bad kind of folks, you will be
in big trouble under laws against trading with an enemy and may even be
punished as a traitor, conspiring to help known criminals as you become
one yourself, or acting really, really stupid for which you will be
publically denounced as as stupid as would any offical caught with their
pants down. If in doubt, the government should be able to tell you the
status of the intended receiver, investigate the threat for you, or become
a direct party in the transaction so as to catch them redhanded.
--
To prevent the comprimise of with the most common configuration
of computers is something like preventing a sculptor from being too original. If a
computer design is corruptable, it will be.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: "1:1 adaptive huffman compression" doesn't work
Reply-To: [EMAIL PROTECTED]
Date: Mon, 17 Jan 2000 19:16:00 GMT
Peter Rabbit <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> I'll give an example, which should demonstrate how an analyst might be
:> helped.
:>
:> He has a bunch of messages, which he knows from the context of
:> their interception contain encyphered-compressed password data.
:>
:> The passwords were generated by a random number generator.
:>
:> Each password is encyphered with its own key.
:>
:> The analyst wants access to the passwords.
:>
:> [In this instance compression doesn't help, but the compressor was built
:> into the cypher-machine.]
:>
:> The analyst has access to a captured table of keys to the cypher
:> - but he doesn't know where the user started in his key table, so he tries
:> starting positions one at a time, assuming consecutive keys were used
:> for consecutive messages, as specified in the manual of a captured
:> machine.
:>
:> Since the messages themselves are random, his only source of information
:> is the padding used by the compressor. If he decyphers a large number of
:> password files in a row, and they exhibit the same statistical anomalies
:> that are introduced by the padding scheme of the compressor, he knows he
:> has found the correct starting key.
:>
:> None of this would have bneen possible, were it not for a very few
:> non-random bits information appended to the files.
: I've been following this argument for a while now and find the whole
: thing to be moot! The only time a generic Zipper becomes a problem is if
: the encryption program that takes the zipped file and encrypts it
: without changing the position of the BYTES. [...]
: After encryption I'd like to see where the bad Zipper left its
: fingerprints so that a smart attacker can use them to attack the file.
The example I gave (and which I've left quoted above) would cause problems
/whatever/ encryption method was used - even if it was a OTP.
All that seems to be needed is for the compression routine to
leave some information in the file in a manner that can be detected -
by the analyst.
Whether the encryption rearranges the bytes or not does not seem to matter
in that instance.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Mary had a little RAM - about a MEG or so.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: is signing a signature with RSA risky?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 17 Jan 2000 19:30:05 GMT
David Hopwood <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Anton Stiglic <[EMAIL PROTECTED]> wrote:
:> : Tim Tyler wrote:
:> :> If the message's signature verification fails, you /know/ you are not
:> :> using the correct key to decrypt (assuming the message is not corrupt).
:>
:> : O.k., I see. But then again, there are plenty of ways
:> : for you to found out if you are decrypting with the
:> : write key or not, simply by observing the message you
:> : get when you decrypt, depending on the system, you will
:> : probably be looking for something specific.
:>
:> Perhaps your file will be compressed? If so - if the compression is
:> good enough - all your decrypts may resemble plausible messages - or
:> they may resemble them closely enough that rejecting them
:> *automatically* is a little bit tricky.
: No, this is a myth. Compressed text (and most other compressed structured
: data) is usually not significantly more difficult to detect than
: uncompressed text or structured data.
It's strange that you say this. What I said is true if - as I
specified - the compression is good enough.
A compressor with an accurate model of the data will not just make it more
difficult to detect a correct message from an incorrect one, it can make
it *massively* more difficult.
Pretty accurate models of some types of textual data are not /that/ hard
to create.
Consider the compression technique that gives all the expected messages
numbers from (say) 0 to 999 - with higher-frequency messages being
represented by more numbers. Any other non-numeric messages are
spelt out longhand.
This might /easily/ compress the target data in a manner that the analyst
can learn next-to-nothing about whether a key is valid from a typical
decrypted text alone.
In this case, he is likely to have no halting criteria available.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
A good traveller leaves no track.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: New Crypto Regulations
Date: Mon, 17 Jan 2000 12:45:38 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
>The question everyone should be asking is, by what *right* does our
>government control exportation of privately-developed cryptologic
>technology? Is it necessary to protect the natural rights of our
>citizens, or is it infringing on those rights? (I say the latter.)
That is certainly one of the questions to ask.
But the claim is made that there is a sufficiently urgent necessity
involved that worrying too hard about the former question is
unrealistic. All over the world, there are terrorist groups, all over
the world there are countries with unstable governments that might
someday be replaced with regimes that will perpetrate aggression
against their neighbors.
Signals intelligence was, during World War II, and for some time
thereafter, *the* major form of intelligence collection.
With export controls on encryption, the U.S. is at least doing what it
can to prevent the world - a world that uses U.S.-made operating
systems on its computers - from changing over to unbreakable ciphers.
That is almost a persuasive argument. Wars of aggression and terrorist
bombs do kill people. The freedom to publish cryptographic source code
on the Internet would, I think, quite reasonably seem to most people
to be a rather small matter beside that.
Thus, while the question of whether we're dealing with an action which
is, or should be, covered by the First Amendment is certainly a part
of the issue, taking time to also argue whether or not the cited
threat is bogus is not a waste of time.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: New Crypto Regulations
Date: Mon, 17 Jan 2000 12:51:40 GMT
"Trevor Jackson, III" <[EMAIL PROTECTED]> wrote, in part:
>And we're long overdue for fertilization of the Tree of Liberty.
Most people think that the fact that the United States hasn't
undergone the overthrow of its government for over 200 years now,
unlike the typical bannana republic, is one of the United States'
_good_ points.
It shows that the Founding Fathers built well.
Now, it certainly is true that the United States has departed from its
original vision in some respects. Do enough people nowadays understand
the original vision well enough, or care enough about the issues
involved, in order to change things? If so, enough democracy still
survives that it is unlikely that resort to arms would be needed. If
not, no measures of any kind will succeed.
Democracy in the United States may have a bad cold, but it isn't
terminal.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Eric Bach)
Subject: Re: LSFR
Date: 17 Jan 2000 20:14:53 GMT
>> Anyone point me to a link describing algorithms that solve the 2^49 LSFR.
>> I've been trying to find some. Is there any other reference material
>> which has details of these algorithms?
Here's some prior art:
D.W. Clark, P.J. Bannon, and J.B. Keller, Measuring
VAX 8800 performance with a histogram hardware monitor,
Proc. 15th Ann. Intern. Symp. on Computer Architecture, pp. 176-185,
1988.
The idea was to use LFSR's to rapidly collect some information that
could then be recovered off-line by solving a discrete log problem. The
LFSR was specially chosen to make the discrete log problem easy to solve.
-Eric Bach
[EMAIL PROTECTED]
------------------------------
From: MENIER Clement <[EMAIL PROTECTED]>
Subject: Question about factoring method.
Date: Mon, 17 Jan 2000 21:29:42 +0100
Reply-To: [EMAIL PROTECTED]
Hi,
I have several questions about the Quadratic Sieve method (and
others).
It requires two numbers x,y such that x^2 = y^2 mod N
and in such case pgcd(x-y,N) divides N. But if x = +/-y N then we
cannot conclude. How often does this happen in the QS algorithm.
If we use r primes in the algorithm why do we try to find r+b (where b
is small)
relations. Just r should be enough to find a linear dependency? Is it to
avoid my first remark?
Thank you very much.
Cl�ment
M�nier.
e-mail : [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Troed)
Subject: Suitable hash for this application - in the public domain?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 17 Jan 2000 20:29:32 GMT
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. I've also looked at RIPE-MD, which I heard has a 256 bit
variant (no more secure than the 160 bit version though)
Are the various C-implementations of RIPE-MD 160 free for private and
commercial use? Any pointers to a 256 bit implementation?
If RIPE-MD isn't free, what other options do I have?
thanks for any help,
___/
_/
------------------------------
From: <[EMAIL PROTECTED]>
Subject: Help -Perl encryption
Date: Mon, 17 Jan 2000 20:50:20 -0000
I'm looking for help in setting up an encryption system for a shopping cart
in perl.
It is for use after an SSL connection in order to keep the info safe on the
server and when being collected over ftp.
Once the information arrives on the ssl server I need to set a perl script
to encrypt it using a strong system
I have searched all over the internet with little luck, if there is anyone
that can point me in the right directionor even help out in return for a fee
please let me know.
(UK based )
thanks
Ben
------------------------------
From: [EMAIL PROTECTED] (Padgett 0sirius)
Crossposted-To: alt.privacy,alt.security
Subject: If enough is good, why is more better ? Re: Triple-DES and NSA???
Date: Tue, 18 Jan 2000 04:45:00
> On the other hand, this variant of DES has an effective key
>length of 112 bits (two 56-bit keys) while Blowfish can use up to 468 bits.
There is another factor here, quantum economics or "good enough". If 112 or
128 bits is currently strong enough that the only practical attack is to buy
someone who has access to the key or steal it some other way, what is the
purpose of a longer key ?
Can see some people wanting to protect for "life plus" but with increased
lengths, attacks against the algorithm become more efficient than brute
force. For 3-Des, this is why 112 bits (two keys) are used rather than 3 (
168 bits), there is no increase in strength so why add the computer cycles ?
A. Padgett Peterson, P.E. CISSP: Cybernetic Psychophysicist
http://www.freivald.org/~padgett/index.html
to avoid antispam use mailto:[EMAIL PROTECTED] PGP 6.5 Public Key Available
------------------------------
From: [EMAIL PROTECTED] (Padgett 0sirius)
Crossposted-To: comp.security.misc,alt.security.pgp
Subject: Re: Why is EDI dead? Is S/MIME 'safe'? Who and why?
Date: Tue, 18 Jan 2000 04:32:43
Electronic Data Interchange or communications with people you know is being
subhumed into Electronic Commerce. S/Mime v3 is "safe", S/Mime v2 is not.
Who's on first.
A. Padgett Peterson, P.E. CISSP: Cybernetic Psychophysicist
http://www.freivald.org/~padgett/index.html
to avoid antispam use mailto:[EMAIL PROTECTED] PGP 6.5 Public Key Available
------------------------------
** 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
******************************
