Cryptography-Digest Digest #680, Volume #9 Wed, 9 Jun 99 00:13:02 EDT
Contents:
Re: being burnt by the NSA (Jim Gillogly)
Re: what cipher? ([EMAIL PROTECTED])
Re: rc4 vs. rand() ([EMAIL PROTECTED])
Re: being burnt by the NSA (fungus)
Re: any cryptosystems using variable length keys? (fungus)
Re: HushMail -- Free Secure Email ([EMAIL PROTECTED])
Re: KRYPTOS (Jim Gillogly)
I KICKED HER HARD IN THE CUNT I KNOCKED HER ON HER ASS THEN I STEPPED ON HER NECK
AND WATCHED HER DIE (Anonymous)
Re: rc4 vs. rand() (fungus)
Re: being burnt by the NSA (fungus)
Re: DES ("Ulrich Kuehn")
nice links to crypto world ([EMAIL PROTECTED])
$1000 PASSPHRASE GENERATION CONTEST (JPeschel)
my simple cipher ([EMAIL PROTECTED])
Re: Generating Random Numbers ([EMAIL PROTECTED])
Re: What good is hushmail? ([EMAIL PROTECTED])
Re: Key lengths vs cracking time (Nicol So)
Re: DES (Jerry Coffin)
----------------------------------------------------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: being burnt by the NSA
Date: Tue, 08 Jun 1999 15:58:12 -0700
[EMAIL PROTECTED] wrote:
> The fact still remains that people complain about the NSA (Dave scott
> likes to do this) and I have never heard anything from the NSA. In
> fact I have seen bad things, such as DES and skipjack. Both ciphers
> have been broken which means they are human too.
Scott has his own agenda -- I'd take what he says about the NSA with
a handful of salt. I think slagging off DES and SKIPJACK is also
unfair. While the DES key size was recognized from the inception to
be too short, that's the only serious defect that's been found with
it -- you get what you pay for, with about 56 bits of protection for
your 56 bits of key, and its usefulness outlived its initial target
lifetime by many years. In any case, DES is more an IBM achievement
than an NSA one. I haven't heard of a break on the full SKIPJACK,
either: although Biham has attacks on various weakened versions of it,
so far as I know the full-strength version lives on.
You also neglected to mention SHA-1, which is an NSA product and is
widely respected and trusted in the open-literature community.
--
Jim Gillogly
Sterday, 18 Forelithe S.R. 1999, 22:51
12.19.6.4.13, 10 Ben 1 Zotz, Third Lord of Night
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: what cipher?
Date: Tue, 08 Jun 1999 22:11:30 GMT
Viewing the NLFSR as a UFN is a very good observation. I don't think
encrypting bit per bit on any sort of general purpose process is a good
idea. Most UFN are word oriented (CAST-256, MacGuffin, etc..) and are
therefore a little faster.
Is there any good description of using the LFSR or NLFSR as a
encryption algorithm avail? What is the secret key the stepping
count? (Timing attack) or the polynomial (timing again, and possibly
power consumption in black boxes...) ?
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: rc4 vs. rand()
Date: Tue, 08 Jun 1999 22:13:50 GMT
> Somebody with enough money to buy a license I expect.
Or someone who reverse engineered the source...
> Call it ARCFOUR instead of RC4 - instant free license to use it...
That is unprofessional. Call it what you want it's still RSAs design.
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: being burnt by the NSA
Date: Wed, 09 Jun 1999 00:24:02 +0200
Nicholas Landau wrote:
>
> >[EMAIL PROTECTED] wrote
> >>Who has actually been burnt by the NSA? As far as I know they are so
> >>secretive they don't exist.
>
> The secretive nature of the NSA is overstated in the popular media.
> They exist. You can go visit their headquarters if you want. Take
> the Baltimore-Washington Parkway North from DC and they have an exit
> somewhere North of Laurel. The sign says "NSA Next Exit." Big secret.
That they exist physically is no big secret, but do you know what
they're listening in to, or what they do with their results?
How big is their annual budget compared to (for example) the CIA?
etc...
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: any cryptosystems using variable length keys?
Date: Wed, 09 Jun 1999 00:21:07 +0200
Medical Electronics Lab wrote:
>
> David Ross wrote:
> > Can anyone speak to the benefits or disadvantages of a variable
> > length key?
>
How about: "so the same program can come in exportable and
non-exportable versions"... ;-)
Or maybe: "It's easier to program".
eg. If RC4 needed a hash function to force the key to a particular
size then CipherSaber would be looking for another algorithm.
http:://www.ciphersaber.gurus.com/
> If you have a lot of data moving between lots of people, you can
> specify how important it is to be fast versus how important it
> is to be secure. More security costs more time, so smaller
> keys mean more speed. If you have variable length keys within
> a single system, you can adjust time and security to meet the
> need at the moment.
>
For RSA you have a point. For RC4 the difference would be negligable.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: HushMail -- Free Secure Email
Date: Tue, 01 Jun 1999 21:26:02 GMT
Dear Sci.Crypt newsgroup:
It's not that our technical people aren't talking about the supposed
problems with HushMail. The problem is we're a very small company; and
our chief technical guy, who would have the answers to your questions,
is deeply involved with other matters right now. I would be happy to
take your questions to him, and when I get fifteen minutes with him, I
can try to get answers for you and post them back to this group. Would
that help?
Please send your questions directly to [EMAIL PROTECTED] Please
identify the newsgroup you are writing from so I will know where to
post the answers to. I will try to get the answers to you as soon as
possible.
Team Hush
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Terry Ritter) wrote:
>
> On Sat, 29 May 1999 20:40:28 -0400, in
> <7iq4i4$4ct$[EMAIL PROTECTED]>, in sci.crypt "rosi"
> <[EMAIL PROTECTED]> wrote:
>
> > Any info on what scheme(s) used? How it works? Or where I can get
> >a look at such? Sorry, not good at reading code and lack of math
> >background. Any 'technical' info in layman's terms would be good.
>
> I have downloaded the purported Java source code and it does seem to
> include some operations I expected. But I have not looked at it in
> detail.
>
> HushMail does seem to be missing things, including the ability to
> validate public keys end-to-end, and some way to check that the
> executable applet corresponds to the examined source. Without these
> features the system cannot reasonably be called secure, so there would
> seem to be scant reason to really get into the code.
>
> As far as I know, none of their technical people are talking about
> these problems, or what they intend to do about them. It is a beta
> system, but maybe they are just selling the site as is.
>
> ---
> Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
> Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
>
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: KRYPTOS
Date: Tue, 08 Jun 1999 07:09:24 -0700
Douglas A. Gwyn wrote:
> One section of Kryptos is clearly a transposition cipher, which means
> that it is solvable with enough trial and error by someone who knows
> the general methodology.
I've tried several things on the transposition cipher -- I think it's
shorter than the section suggested by the CIA in the letter posted at
the ACA site, or 336 letters total, from ENDYA to TVDOH W. The
individual letter frequencies are much more convincing that way. I've
made some progress on it (I think) but don't have a solution to anything.
--
Jim Gillogly
Sterday, 18 Forelithe S.R. 1999, 13:56
12.19.6.4.13, 10 Ben 1 Zotz, Third Lord of Night
------------------------------
Date: Wed, 9 Jun 1999 03:50:14 +0200 (CEST)
From: Anonymous <[EMAIL PROTECTED]>
Subject: I KICKED HER HARD IN THE CUNT I KNOCKED HER ON HER ASS THEN I STEPPED ON HER
NECK AND WATCHED HER DIE
Don't get on my bad side now ya hear
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: rc4 vs. rand()
Date: Wed, 09 Jun 1999 04:21:13 +0200
[EMAIL PROTECTED] wrote:
>
> > Call it ARCFOUR instead of RC4 - instant free license to use it...
>
> That is unprofessional. Call it what you want it's still RSAs design.
>
If you're going to make a lot of money then feel free to make
a donation to Ron Rivest.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: being burnt by the NSA
Date: Wed, 09 Jun 1999 04:27:03 +0200
Jim Gillogly wrote:
>
> I haven't heard of a break on the full SKIPJACK,
> either: although Biham has attacks on various weakened versions of it,
> so far as I know the full-strength version lives on.
>
I heard there's an attack on it which works if you remove just
one round from the cipher, but no weakness in the full number
of rounds.
Again, this shows to me that the NSA knows *exactly* what they
are doing. Many ciphers have a few extra rounds "just in case".
Not Skipjack, skipjack has exactly the number of rounds it needs,
no more, no less.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: "Ulrich Kuehn" <[EMAIL PROTECTED]>
Subject: Re: DES
Date: 08 Jun 1999 16:20:12 +0200
[EMAIL PROTECTED] writes:
> > DES;
>
> > 2 The fixed s-boxes? Surely if they are known, they are worthless?
> > Wouldn't it make more sense to have key dependant s-boxes?
>
> Well's it is not the s-boxes that make it strong (well they do... but
> wait a sec). The secret information is the key, or more specifically
> the round keys. It's expected that for the last output you didn't know
> the plaintext so it's not easy to eliminate the roundkey/plaintext from
> the output. The s-boxes are designed to promote avanlanche.
In fact, the S-Boxes are a main part where DES gets its strength from.
They are designed in combination with the E expansion and the P
permutation. Biham and Shamir did an analysis that most changes to
either of these elements is likely to make the cipher weaker against
differential cryptanalysis.
Ciao,
Ulrich
--
Ulrich Kuehn ------------------ [EMAIL PROTECTED]
[EMAIL PROTECTED]
http://wwwmath.uni-muenster.de/~kuehn/
------------------------------
From: [EMAIL PROTECTED]
Subject: nice links to crypto world
Date: Wed, 09 Jun 1999 00:58:15 GMT
go to http://www.multimania.com/darkmage !
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: $1000 PASSPHRASE GENERATION CONTEST
Date: 9 Jun 1999 02:33:54 GMT
Help crack a PGPDisk passphrase.
I've just added this contest to my
site.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED]
Subject: my simple cipher
Date: Wed, 09 Jun 1999 00:02:17 GMT
I added the keyed final permutation to the cipher to strengthen it a
bit. You can view the source at
http://people.goplay.com/tomstdenis/simple.c
Which is really easy to read. I made the code as clear as possible I
hope.
Any feedback would be appreciated. I would like to write a paper or
document this cipher. If anyone wants to help I would appreciate it!
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Generating Random Numbers
Date: Mon, 31 May 1999 15:55:20 GMT
> I was wondering how to generate random numbers which will be used for
> encryption keys. My main concern is how to generate a random seed
which is
> random enough to ensure that the generated bits are indeed random.
Hmm, you could hash a passwd. That's the most common method. If you
are making public/private keys then try a BBS generator.
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: What good is hushmail?
Date: Tue, 01 Jun 1999 15:53:26 GMT
In article <[EMAIL PROTECTED]>,
Bruce Stephens <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
>
> > With access to the encrypted keys, their security depends entirely
on
> > the strength of
> > 1) The uniqueness of the pass phrase - how difficult is it to guess?
> > 2) The strength of the crypto algorthm that secures the key -
blownfish?
> > 3) The strength of the hash algorithm used to randomize the pass
phrase
> > data - sha1
>
> Sure, but they're open about all this.
Yes. However, I still think the process of an independent review would
hash out some of their weaknesses.
> I haven't looked at the code, but it would be straightforward for an
> applet to put limits on the passphrase, ensuring that it's of a
> certain length, or something.
It is. However, it does not check for famous quotes or pat phrases
which would be the first ones that I would try if I were to mount a
brute force attack to get the private key for someone.
> And you can check the implementation of
> the symmetric algorithm and the hash algorithm (presuming that the
> source code and the bytecode correspond (and that the JVM lacks bugs
> that the bytecode might hit)).
The next time I have a spare couple of hours, I will code review their
blowfish implementation. I want to at least check if they are using
Blownfish ;) However, they can accidentally write in some bugs
with 'slick' shortcuts.
> (More worrying is that I seem to remember that half the hash gets sent
> before the server sends the encrypted key, to make it hard to get the
> encrypted key. That would obviously reduce the search space, but
> almost certainly I'm misremembering, and the half-a-hash that gets
> sent is actually a quite different hash---or perhaps half a hash (80
> bits, presuming SHA1) is still easily big enough.)
Yes, as you state they use the half of the SHA1 hash to authenticate
you. However, if you have access to their server (which you must
assume has to be black), none of this actually should matter.
However, I am still sceptical. If any significant clues are sent to
the server about your encrypted private key, or the secret key to
decrypt it, this whole thing could be a sham.
Still checking it out,
Art Gecko
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: Key lengths vs cracking time
Date: Tue, 08 Jun 1999 23:49:23 -0400
[EMAIL PROTECTED] wrote:
>
> > One word: assurance. Having a known lower bound on security outweighs
> > the inconvenience of slightly longer keys, at least in some
> > applications.
>
> Assuarance that people can break the cipher faster then trying all the
> keys? No thanks.
What can I say to convince you of the value of assurance and certainty,
other than to suggest that you go look for some *rigorous*, non-trivial
lower bounds on the complexity of cryptanalyzing your favorite ciphers?
> It's not flat. It's that simple. You really should view a RSA key as
> say 256 bits, and that being an index into a table of primes. It's that
> simple. For a 1000 bit prime there are about 2^128 others, so yes you
> could compare 1000 <-> 128 bits, but really the 1000 bit prime is only
> the entry in a table.
I don't understand your math (not that I'm stupid, but I just don't know
how you came up with your numbers).
In most implementations/specifications I've seen, the factors p and q of
an RSA modulus m are chosen to be half the size of m. In my example, we
are dealing with 1024-bit moduli, so p and q are 512 bits each.
According to the prime number theorem, there are approximately
2^512/ln(2^512) primes <= 2^512. Excluding 511-bit or shorter primes,
we have approximately 2^512/(512*ln 2) - 2^511/(511* ln 2) = 2^502.5
choices for p (and q). That gives us approximately 2^1005 choices for m
(which implicitly defines the key). With the most efficient encoding,
it would take about 1005 bits to encode a 1024-bit RSA modulus. But
factoring a 1024-bit RSA modulus requires nowhere near 2^1005 steps!
Based on the criterion you seem to be using to judge ciphers, I guess
you would not use 1024-bit RSA because it doesn't take 2^1005 steps to
break.
> In a flat key space all keys from 0 to 2^n-1 are secure. In RSA they
> will not work properly, so not all keys from 0 to 2^n-1 are secure.
> This represents a reduced key space. But they are not the same things.
> It like viewing the blowfish s-table as a 32768 bit key but in reality
> it is much shorter (2176 bits). So you could view the s-table as a
> really large key which 'waste' space, but this is not a realistic view.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: DES
Date: Tue, 8 Jun 1999 22:05:29 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> I've always wondered, why not just have completely
> independent keys for each round of DES?
This has been tried.
> wouldn't that be better compared to using the
> same key and shifting it around every round?
It doesn't help very much. You increase the key from 56 bits to 768
bits, but it can be attacked with 2^61 chosen plaintexts. The usual
attack on DES is brute-force, using 2^56 operations. IOW, a 712 bit
increase in actual key length leads to only about a 5 bit increase in
the effective key length.
Just for contrast, consider that 3DES increases the actual key length
to 168 bits, but increases the effective key length to 112 bits. This
obviously makes MUCH better use of the key supplied.
A 768-bit key presents a problem for many situations anyway. You
typically hash a pass-phrase to get a key. You can typically plan on
a pass-phrase in English having no more than about 3 bits of entropy
per character. That means that even assuming your hash is _perfect_
at distilling the entropy from the pass-phrase, your pass-phrase would
have to be about 256 characters long to generate a reasonably
unpredictable 768-bit key. In reality, you'd want to increase that at
least a little, so you'd probably want to use a pass-phrase more like
300 characters long. From a practical viewpoint, I doubt that many
people want to deal with a 300-character pass-phrase -- in fact, I
think it's safe to say that simply won't do so.
------------------------------
** 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
******************************
