Cryptography-Digest Digest #886, Volume #9 Thu, 15 Jul 99 19:13:03 EDT
Contents:
Re: TLS and stream cipher padding (Thierry Moreau)
Re: zip or replacement ([EMAIL PROTECTED])
Re: randomness of powerball, was something about one time pads (Patrick Juola)
Re: linear complexity of Lagged Fibo Generators ([EMAIL PROTECTED])
Re: linear complexity of Lagged Fibo Generators (David A Molnar)
zip or replacement (Paul Edwards)
Re: Why this simmetric algorithm is not good? ([EMAIL PROTECTED])
Re: zip or replacement (JPeschel)
Re: What is the "real" length of a key in 3-key 3DES? (David Wagner)
Re: Why this simmetric algorithm is not good? ([EMAIL PROTECTED])
Re: Canadian Crypto (Winner)
Re: How Big is a Byte? (was: New Encryption Product!) (wtshaw)
Re: Why public key in PGP (Sundial Services)
Re: zip or replacement (Sundial Services)
Compression and security (was: Re: How to crack monoalphabetic ciphers) (Sundial
Services)
----------------------------------------------------------------------------
From: Thierry Moreau <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: TLS and stream cipher padding
Date: Thu, 15 Jul 1999 13:15:32 -0400
Gabriel Belingueres wrote:
>
> Does anyone out there knows why in the TLS 1.0 spec (RFC 2246), when it
> is used with a stream cipher, it does NOT generate a random padding,
> just like
> for block ciphers?
Simply because stream ciphers do not process data in blocks, but rather
in bytes (or even bits).
> If you read the paper "Analysis of the SSL 3.0 protocol" by Bruce
> Schneier & David Wagner (you can find it at http://www.counterpane.com),
> they talk about an attack based in the aproximated length of the HTTP(S)
> GET request, in witch an attacker can figure out witch html page you
> have accessed.
>
> Why this padding was not contemplated for stream ciphers in TLS?
This type of padding is not intended for "traffic flow confidentiality".
If your application really needs traffic flow confidentiality, you
should look for traffic flow confidentiality padding (and even maybe
encryption of addressing information ...).
- Thierry Moreau
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: zip or replacement
Date: Thu, 15 Jul 1999 19:29:56 GMT
In article <7mlboi$omn$[EMAIL PROTECTED]>,
Paul Edwards <[EMAIL PROTECTED]> wrote:
> I want to back up my hard disk onto CD-R using
> zip. My plan was to do a
>
> zip -0 -r fred c:\*.*
>
> zip -9 -e mary fred.zip
>
> and use a password which was say 6 random
> alpha characters.
>
> Is that crackable? If so, can someone suggest a
> replacement for zip's encryption? Thanks. Paul.
the PKZIP attack
http://www.funet.fi/~bande/docs/crypt/analysis/cs842.ps.gz
requires 13 known plaintexts to find the key. .ZIP files have headers
which are probably much longer. I would say 'this is not a secure
method'.
What I would do is get a hold of ZLIB and make your own program where
the header is not encrypted. Then pick out a better stream cipher such
as RC4 and SEAL. That's just me.
If you are paranoid zip up the files and encrypt the zip file. There
are many public domain algorithms (TEA, ICE, Blowfish, CAST, IDEA,
etc..) and most are simple to write from memory (well 3 of them are...).
PGP has a file encrypt function with 'convential passwords'.
I also would not use 6 char passwords this provides about 72^6 or about
37 bits of private 'key' material. This could be searched on a desktop
in about 3 days at the most.
Basically
a) Don't use PKZIP cipher
b) Use longer passwords.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: randomness of powerball, was something about one time pads
Date: 15 Jul 1999 15:04:54 -0400
In article <[EMAIL PROTECTED]>,
fungus <[EMAIL PROTECTED]> wrote:
>> (If you don't know which of these is
>> the case, then switching can't hurt and might help.)
>
>No. Switching *always* helps (always!).
Switching doesn't always help if the host has the option to
offer the switch or not -- and chooses appropriately. Reductio
ad absurdam : the host only offers a switch *if* you've chosen
the correct door.
-kitten
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: linear complexity of Lagged Fibo Generators
Date: Thu, 15 Jul 1999 18:51:57 GMT
<snip>
Follow up question. Would MUSH be any better (even a little) if one
generator used addition and the other subtraction? It should function
just the same. The way I see it when you do
C = A xor B
(A and B are the generators)
Making simple relations for the various bits (especially the first
which is just xor) should be harder. It should also mean that every
bit is just as 'complex' (based on carries and such) as any other bit.
Is there any truth to this? Am I even close? I need help... so many
ideas no real training... arrrrg...
Tom
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: linear complexity of Lagged Fibo Generators
Date: 15 Jul 1999 19:39:22 GMT
[EMAIL PROTECTED] wrote:
> Not really. I would have to check with the universities. But I am not
> a student so I would have to buy the books... (no fun).
Sometimes it is possible to get library privileges without having to be a
full-time student. Summer school is good for this (and you can learn
something cool). You might also see if your local library (if you have one
- the comment below doesn't sound encouraging) can arrange inter-library
loan, purchasing requested books, or guest privileges at a state-supported
university.
-David Molnar
------------------------------
From: Paul Edwards <[EMAIL PROTECTED]>
Subject: zip or replacement
Date: Thu, 15 Jul 1999 19:11:26 GMT
I want to back up my hard disk onto CD-R using
zip. My plan was to do a
zip -0 -r fred c:\*.*
zip -9 -e mary fred.zip
and use a password which was say 6 random
alpha characters.
Is that crackable? If so, can someone suggest a
replacement for zip's encryption? Thanks. Paul.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why this simmetric algorithm is not good?
Date: Thu, 15 Jul 1999 19:55:48 GMT
In article <7mldf7$pfa$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> You mean that since you don't see any difference you assert
> as fact that they are equally secure? That clearly falls
> into the "just making it up" category.
No I mean because each element is used with equal prob it shouldn't
matter. Maybe it is but I really don't see that as a plasuaible
weakness, can you?
> The first is normally faster for some compilers, but they
> both
> > have a similar effect. All 'x' is used for is to make sure each
> > element is used at some point.
>
> There are many ways to make sure each element is used
> that are not secure. Your claim is completely
> unjustified.
Well I don't see how you could ensure proper usage of the elements and
make it unsecure at the same time. Can you give an example?
> > Well it would have to optimize it by only using the lower 8 bits.
>
> Obviously using only the lower 8 bits is a valid
> optimization. You claimed the compiler cannot
> optimize the "&" operation away. Nothing you wrote
> justifies this claim.
>
> > How would a C compiler optimize
> >
> > c = (a + b) & 255
> >
> > in your books?
>
> If c is an 8-bit integer type, optimize by omitting
> the and. My books call it a "peep-hole optimization"
> which is about the simplest kind.
But what is an 8-bit type again? Would that be a 'char' or would that
be a 'int'? The code generator could optimize it by assuming char=8 or
whatever then only using the lower part (like AL in x86). I see this
as a machine dependant optimization, hardly worth it unless you code in
ASM.
I treat char=8 for my reasons. It's not ANSI but it works for me.
Relying on the compiler to clean things up is why a lot of code is
messy (i.e Windows).
This is OT though so drop it? M'kay?
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: zip or replacement
Date: 15 Jul 1999 20:11:10 GMT
> Paul Edwards <[EMAIL PROTECTED]>writes:
>I want to back up my hard disk onto CD-R using
>zip...
>and use a password which was say 6 random
>alpha characters.
>
>Is that crackable?
If you meant 6 lower-case letters from the alphabet,
it is crackable by brute-force in a short time.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: What is the "real" length of a key in 3-key 3DES?
Date: 15 Jul 1999 12:45:55 -0700
In article <7mia8t$fea$[EMAIL PROTECTED]>,
Patrick Juola <[EMAIL PROTECTED]> wrote:
> Not so. New article in J. Cryptology by our old friend Eli Biham
> takes 3DES apart in about 2^64 steps.
Enough people seem to be confused about this that I should try to clear
up the misunderstanding. Eli Biham did not break 3DES. Rather, he
broke some triple modes of operation (in fact, nearly all the triple
modes _except_ the usual 3DES construction).
The Triple-DES with outer feedback, which is what most everyone means
when they talk about 3DES, still seems secure. The best attack on
outer feedback is apparently the codebook attack, where you try to
learn the entire codebook by obtaining the encryption of 2^64 texts.
Codebook attacks are, of course, entirely impractical due to the large
amount of known text required.
What Eli Biham shows is how to break "all" the other triple modes of
operation, i.e. the inner feedback modes. To quote from his paper:
``We [consider] only multiple modes, namely, cascaded (pipelined)
modes in which the plaintext is encrypted under a single mode at a
time, whose output becomes the input to the next single mode.''
His results provide compelling evidence that inner feedback is dangerous,
and that outer feedback is the right way to go.
Therefore, you shouldn't view his paper as breaking the 3DES, but rather,
quite the opposite: he provides strong evidence that 3DES is maybe the
strongest way to triple DES.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why this simmetric algorithm is not good?
Date: Thu, 15 Jul 1999 19:40:25 GMT
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
Tom had written:
> > > It matters not when concerning security issues.
> >
> > Can you prove that, or are you just making it up?
>
> My logic is what makes 'y += state[++x]' more secure then 'y += state
> [x++]'?
You mean that since you don't see any difference you assert
as fact that they are equally secure? That clearly falls
into the "just making it up" category.
> The first is normally faster for some compilers, but they
both
> have a similar effect. All 'x' is used for is to make sure each
> element is used at some point.
There are many ways to make sure each element is used
that are not secure. Your claim is completely
unjustified.
> > > If I put a &255 the compiler CAN NOT optimize it away.
> >
> > Of course it can. What are you talking about?
>
> Well it would have to optimize it by only using the lower 8 bits.
Obviously using only the lower 8 bits is a valid
optimization. You claimed the compiler cannot
optimize the "&" operation away. Nothing you wrote
justifies this claim.
> How would a C compiler optimize
>
> c = (a + b) & 255
>
> in your books?
If c is an 8-bit integer type, optimize by omitting
the and. My books call it a "peep-hole optimization"
which is about the simplest kind.
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Winner <[EMAIL PROTECTED]>
Subject: Re: Canadian Crypto
Date: Thu, 15 Jul 1999 21:20:40 GMT
> For example, a Canadian firm can sell an encryption DLL that can be
> linked into many applications. In the US, the agency insists on
> tightly coupled crypto and forbids the use of DLL. ("Crypto with a
> hole" is the term.) I was with a US firm who was looking at being a
> reseller of the Canadian firm's capability and we couldn't do it. The
> US is clearly at a disadvantage in the marketplace.
Can you tell us the agency's name that did not allow use of DLLs and
can you tell us why?
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Thu, 15 Jul 1999 16:47:17 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> The IBM 7074 was a decimal based machine. Ours had 10,000 ten digit
> signed words. Each of the digits used five bits with a two-out-of-five
> coding scheme.
>
> So perhaps God did mean for us to think in decimal....
>
Please try not to confuse IBM with God; on the other hand, God is not apt
to be confused, just perplexed.
Occasionally, people, individuals, families, have other then ten fingers;
God allows options and gives all of them a chance.
--
Most wrestlers and politicians seem to have pretty the same
agenda, seek various kinds of by appearing to do things they are
not doing, catering to specialty groups of supporters, and as a
result of deals, learn to take falls when they know better. Those
who do not go along tend to be excluded and punished.
------------------------------
Date: Thu, 15 Jul 1999 15:31:11 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Why public key in PGP
[EMAIL PROTECTED] wrote:
>
> > sundialservices.com wrote:
> > As to the lifetime of a public key... I suspect that keys used for
> > ordinary signature-purposes are kept for a long time. Keys used by
> > people who are actually conducting private conversations are probably
> > retired when the conversation is through, or when people leave the
> > organizations in question, or when the security afforded by the prior
> > public-key is doubted in any way by anyone.
>
> This gets into the worthness-length arugment. How much is the private
> info worth to you compared to the cost of cracking it. If it takes 1000
> $ to factor a 50digit modulus will it be worth 1000$ to get the info?
>
> If I use 200+ digit moduli will it be worth it to factor it? Rivest
> did a 1990 study of key lengths for appropriate security as did Scheier
> (I think).
More than mathematics, I think what's relevant here is basic
key-management... how you would employ a cipher-system depending on the
value and lifespan of the data being protected by it in a particular
conversation.
Public keys can be "really public," or they can simply be "one of the
two keys in a key-pair." The terminology is the same; the implication
isn't.
I think that the main use of a "truly public" public-key is simply to
validate digital signatures that are issued by the owner of the key. Of
course it also provides a convenient way for "any John Q. Public" to
send a message in confidence, but if a REALLY confidential conversation
is about to take place, common-sense says that a new key-pair should be
exchanged that is specific to that conversation.
Using a published public-key and other authentication methods (or
perhaps a flesh-and-blood curior), the public portion of a key-pair
would be sent to cover that particular confidential exchange, and the
key might be changed very frequently indeed. But it's unlikely that the
key would ever be published on anyone's key-server.
[ As for the NSA, I'm quite content to let them churn away on their own
devisings... Anyone who's at the beck and call of every Senator,
Representative, and Lieutenant Colonel in the world might not have such
a wunnerful job after all... ;-) ]
------------------------------
Date: Thu, 15 Jul 1999 15:43:01 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: zip or replacement
Paul Edwards wrote:
>
> I want to back up my hard disk onto CD-R using
> zip. My plan was to do a
>
> zip -0 -r fred c:\*.*
>
> zip -9 -e mary fred.zip
>
> and use a password which was say 6 random
> alpha characters.
>
> Is that crackable? If so, can someone suggest a
> replacement for zip's encryption? Thanks. Paul.
As for me, Paul, I'd use a good commercial backup-utility, specify
compression, and keep the backup in a safe-deposit box.
If that's not practical, how about using a commercial backup-utility to
back up to a file on the hard disk, then use PGP to encipher the backup
file? Then copy the ciphertext to CD.
ZIP is not adequate as a backup tool, given the alternatives. This
makes its security a moot point.
------------------------------
Date: Thu, 15 Jul 1999 15:41:04 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Compression and security (was: Re: How to crack monoalphabetic ciphers)
[EMAIL PROTECTED] wrote:
>
> If it was compressed, I would perhaps try digram and trigram frequency
> analysis. Digrams are two-letter combinations, trigrams are three
> letter combinations. Since compression works by substituting single
> characters for digrams, trigrams, and higher, this might work.
You know, there's a lot of talk that compression provides security to
the information, but I wonder if this is so or if perhaps the case is
precisely the opposite.
[ "Pure conjecture here!" he exclaimed, pulling on his asbestos
bunny-suit... "But lissen..." ]
When I was last exploring the vagaries of the PKZip stream cipher, I
noticed that the bit-frequency characteristics of any particular *block
of* data in a compressed archive were anything but random. They were
actually very predictable. Take any 128 consecutive bits and count the
number of ones, the number of zeroes and the space in-between them (and
so on...), and you find that -- although it's quite impossible to
predict whether a particular bit is 1 or 0 -- you can certainly look at
that block of bits and say "yep, it looks like it's compressed with
PKZip"... or not.
This produced a tantalizing shadow of what I'd call a "well, I don't
know the plaintext but I do know what the compressed plaintext looks
like" attack. Bezillions of possible PKZip cipher-keys produce a
frequency distribution that does not look anything like what one can
safely predict it should be. Even though the decryption-problem cannot
be reduced nearly as far as the published known-plaintext attack enables
it to be, the problem certainly *is* reduced, and in these days of
300mHz microprocessors, it's reduced to be well within reach.
So the question before the house is: does compression make the
effective-plaintext more predictable (therefore less secure), or less
predictable (more secure)?
Makes ME wonder, anyway... :-)
------------------------------
** 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
******************************
