Cryptography-Digest Digest #887, Volume #9 Thu, 15 Jul 99 21:13:03 EDT
Contents:
Re: What is the "real" length of a key in 3-key 3DES? (wtshaw)
Re: Why public key in PGP ([EMAIL PROTECTED])
Re: linear complexity of Lagged Fibo Generators ([EMAIL PROTECTED])
Research Assistantship - Quantum Cryptography, University of London (Ian Geldard)
Re: Why this simmetric algorithm is not good? ([EMAIL PROTECTED])
Re: Why public key in PGP ([EMAIL PROTECTED])
Re: How Big is a Byte? (was: New Encryption Product!) (Peter Seebach)
Re: How Big is a Byte? (was: New Encryption Product!) ("donald tees")
Re: Why this simmetric algorithm is not good? ([EMAIL PROTECTED])
Re: Why public key in PGP (Patrick Juola)
Re: zip or replacement ([EMAIL PROTECTED])
Re: Compression and security (was: Re: How to crack monoalphabetic ciphers)
([EMAIL PROTECTED])
Re: Why public key in PGP ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: What is the "real" length of a key in 3-key 3DES?
Date: Thu, 15 Jul 1999 16:41:40 -0600
In article <[EMAIL PROTECTED]>, fungus
<[EMAIL PROTECTED]> wrote:
> In article <7mia8t$fea$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> > (Patrick Juola) writes:
> > ...
> >
> > > Not so. New article in J. Cryptology by our old friend Eli Biham
> > > takes 3DES apart in about 2^64 steps.
> >
> > Ouch. History in the making. "May you live in interesting times."
>
> The web page says he needs 2^56 - 2^66 chosen plaintexts, so this
> isn't much of a practical weakness.
>
And, in practical use, getting a few if any chosen plaintexts is not
practical. Whenever a *break* is considered, think about exactly what has
to happen in the real world for it to have importance.
--
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.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why public key in PGP
Date: Thu, 15 Jul 1999 23:01:28 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
> >
> > Question:
> >
> > Now that you publish your public key for a PGP encrypted file,
why
> > do you need such a public key?
> > Do you really need a key server to dynamically generate new
> > public keys? How if you just use one public key for a long time
(say, 1
> > month or 10 years)?
> > Thank you so much.
> If you send a message to me encrypted with my public key, no one can
> decrypt it but me 'n the NSA. This allows you to send personal
messages
> to me.
If only you and the NSA know the public key, the level of privacy
is the same as the private key, then why is it called a "public" key? If
the public key is published, everybody knows it, why does it help to
protect?
Thanks you.
Weeldet
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: linear complexity of Lagged Fibo Generators
Date: Thu, 15 Jul 1999 21:57:50 GMT
In article <7mldda$b42$[EMAIL PROTECTED]>,
David A Molnar <[EMAIL PROTECTED]> wrote:
> 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.
Well I will check with Ottawa U, but I don't know. In my city we have
one library and well it doesn't have anything really educational...
Does anybody have excerpts, quotes or snippets? I would like to hear
comments on ideas..
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] (Ian Geldard)
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,talk.politics.crypto,sci.crypt.research
Subject: Research Assistantship - Quantum Cryptography, University of London
Date: 15 Jul 1999 23:22:39 -0000
[The following was advertised in The Guardian (UK) on 15th July 1999
and may be of interest.]
Royal Holloway
University of London
Department of Mathematics
Research Assistantship - Quantum Cryptography
An ESPRC funded postdoctoral research assistantship is available for
a period of two years starting 1 October 1999 or soon thereafter.
Applications are invited from candidates with a PhD in mathematics,
theoretical physics or computer science. Applicants should have a
strong background in quantum mechanics and will be expected to
acquire the necessary cryptographic skills early in the project.
The appointment is on the research salary scale 1A and the initial
salary will be 19,704 pounds a year including London Allowance (pay
award pending). For further details please contact Professor Fred
Piper Tel: +44(0) 1784 443098, e- mail [EMAIL PROTECTED] or Dr
Ruediger Schack Tel: +44(0) 1784 443097, e-mail [EMAIL PROTECTED]
To apply please send your CV to Prof F Piper, Department of
Mathematics, Royal Holloway, University of London, Egham, Surrey,
TW20 0EX, Fax: +44(0) 1784 430766. Please quote Ref: CRB/1488
The closing date for applications is 30th July 1999
--
Ian Geldard
London, England
PGP DH/DSS Key ID: 0x07CB87A6
PGP RSA Key ID: 0xE5FD80A1
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why this simmetric algorithm is not good?
Date: Thu, 15 Jul 1999 23:09:55 GMT
In article <7mlebt$prs$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> 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?
If you want to claim that no one has shown your
version to be weaker, fine. You asserted as fact
that it's not a security flaw and you do not know
any such thing.
[...]
> > 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.
What are you talking about? The question is whether
the compiler can optimize out the "& 255" when the
result will be truncated to eight bits. The compiler
knows how large the types are, so it can apply the
optimization. You claimed it could not.
> 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?
Crypto programs tend to depend on use of certain
sizes of integers. We use things like "& 255"
quite a bit to write portable code.
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why public key in PGP
Date: Thu, 15 Jul 1999 23:05:35 GMT
In article <7ml4rm$lkg$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > PGP uses a -pair- of keys: one for encryption, the other to
decrypt.
> > One may be made public while the other remains private.
> >
> > If you send a message to me encrypted with my public key, no one can
> > decrypt it but me 'n the NSA. This allows you to send personal
> messages
> > to me.
>
> I seriously doubt that the NSA has the power (or knowledge) on how to
> factor large numbers (say 200+ digits).
Has the NSA to factor the large number? Can't he just know the number
after it's generated?
> 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
Thanks for mentioning the key length. How about the lifetime of a
key? How often do you need to change a public key?
Weedlet
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
From: [EMAIL PROTECTED] (Peter Seebach)
Date: Thu, 15 Jul 1999 22:59:44 GMT
In article <7mlo64$h57$[EMAIL PROTECTED]>,
donald tees <[EMAIL PROTECTED]> wrote:
>Interesting that you were the only one to pick up on the she. The religious
>ones always make the pious claim that god is sexless, until someone takes
>them at their word and figures that one adjective is the same as another
>under the circumstances. You should hear the cries, though, when I use
>"it". Lip service is a wonderful thing.<G>.
This is partially because "he" is a gender-neutral pronoun in English, while
"she" isn't, and "it" is a pronoun for the inanimate. "he" is correctly used
both for typeless entities and for male entities.
Another argument against overloading words.
-s
--
Copyright 1999, All rights reserved. Peter Seebach / [EMAIL PROTECTED]
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Will work for interesting hardware. http://www.plethora.net/~seebs/
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
------------------------------
From: "donald tees" <[EMAIL PROTECTED]>
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Thu, 15 Jul 1999 18:26:28 -0400
[EMAIL PROTECTED] wrote in message
>
>She???!!?? Octal plus a parity bit with one left to suck.
>
I have to admit that though I grew up on octal, I have been immersed in hex
for years. I don't think in octal anymore, and it has been years since I
balanced my bankbook wrong because I did the addition base eight.
Interesting that you were the only one to pick up on the she. The religious
ones always make the pious claim that god is sexless, until someone takes
them at their word and figures that one adjective is the same as another
under the circumstances. You should hear the cries, though, when I use
"it". Lip service is a wonderful thing.<G>.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why this simmetric algorithm is not good?
Date: Thu, 15 Jul 1999 23:32:37 GMT
In article <7mlpna$ufj$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> If you want to claim that no one has shown your
> version to be weaker, fine. You asserted as fact
> that it's not a security flaw and you do not know
> any such thing.
If you want to claim RC4 is secure and wait for it to be shown weak,
fine. (this works either way...)
<snip>
I don't have a clue on what I was saying... You're right that the
compiler can optimize it as long as it produces the same effect. I
guess the post was too long and I just jump quickly on it.
Can we drop this thread? It's bad news for me because of the stuff I
wrote. I think I have some stuff to learn about compilers (and ANSI-C)
before I can effectively join this conversation. (maybe I should just
think before I post...)
I mainly code for one compiler (somes two) so you have to excuse my
close-mind point of view. I don't have as much exposure to other
platforms as others.
> Crypto programs tend to depend on use of certain
> sizes of integers. We use things like "& 255"
> quite a bit to write portable code.
Well this is not always so. Some code I have seen makes assumptions.
but generally you are right.
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: Why public key in PGP
Date: 15 Jul 1999 19:57:16 -0400
In article <7mlp7i$ua4$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>> [EMAIL PROTECTED] wrote:
>> >
>> > Question:
>> >
>> > Now that you publish your public key for a PGP encrypted file,
>why
>> > do you need such a public key?
>> > Do you really need a key server to dynamically generate new
>> > public keys? How if you just use one public key for a long time
>(say, 1
>> > month or 10 years)?
>> > Thank you so much.
>
>> If you send a message to me encrypted with my public key, no one can
>> decrypt it but me 'n the NSA. This allows you to send personal
>messages
>> to me.
>
> If only you and the NSA know the public key, the level of privacy
>is the same as the private key, then why is it called a "public" key? If
>the public key is published, everybody knows it, why does it help to
>protect?
Because the public key is useless -- or next to useless -- for
decryption. To *decrypt* a message, I need the *private* key associated
with a given public key. I know it because I created the key-pair;
the NSA knows it because they and only they know how to reconstruct
the private from the public key. Everyone else only knows the public
key and can therefore encrypt messages but not decrypt them.
-kitten
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: zip or replacement
Date: Fri, 16 Jul 1999 00:39:04 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> 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.
Asides from being OT, ZIP is free and commercial products are not. I
would use ZIP if I had to backup my HD.
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]
Subject: Re: Compression and security (was: Re: How to crack monoalphabetic ciphers)
Date: Fri, 16 Jul 1999 00:37:25 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> 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.
Well compression is not designed to do either. It's designed to remove
redundancies by recongnizing patterns. In the case of DEFLATE (what
you all pkzip) it tries to match strings. These strings are then LZ77
coded then huffman coded. Literals are huffman coded as well (in a
seperate tree).
> [ "Pure conjecture here!" he exclaimed, pulling on his asbestos
> bunny-suit... "But lissen..." ]
Do you have a spare?
> 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.
Well in .LZH files (from LHA) I found that the average distance between
the same byte value is not 256.0 (like it should) but +- 15 from that
(in a 7MB file). In the output from a Lagged Fibo Sequence I got a
distance of 256.0 +- 2. This indicates that the compressed stream is
dependant on the input (which makes sense).
However predicting the next output based on the previous (order-1) is
not as easy. On average I found I got ~1/256 which is what is
expected. Note this is huffman coding techniques. Basically you can't
easily guess the next byte since it is already huffman coded.
> So the question before the house is: does compression make the
> effective-plaintext more predictable (therefore less secure), or less
> predictable (more secure)?
Well compressing plaintext makes sense. You reduce transmission time
and ciphertext. The actual plaintext is more difficult to simply guess
(i.e brute force) since it's not restricted to the plaintext (well
before compression)
Obviously any compression scheme that leaves predictable headers or
info should be question in efficiency. I.e in DEFLATE you can read the
file (plaintext) and see it's in DEFLATE form because of the headers.
If you look at the DATA STREAM though you should not be able to predict
it.
Generally it's a good idea, PGP for example uses ZLIB (DEFLATE lib) to
compress before encrypting...
> Makes ME wonder, anyway... :-)
think about this, what about the first bunch of bytes where there is no
history to guess?
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]
Subject: Re: Why public key in PGP
Date: Thu, 15 Jul 1999 23:26:23 GMT
In article <7mlpf8$uda$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Has the NSA to factor the large number? Can't he just know the
number
> after it's generated?
Well it depends on the algorithm. In RSA you have three numbers
e, d, n=pq
Where (e, n) form the public key and (d, p, q) form the private info
(although you only need to keep n to make it work). The attaker [*]
will have to factor n into 'q' and 'p'. From this point they can make
the private key.
You can't just guess the factors it would take too long. So [*] yes
the NSA would have to factor your modulus into the primes.
> Thanks for mentioning the key length. How about the lifetime of a
> key? How often do you need to change a public key?
Well if 200 digit keys can be cracked by say a large company in 2^20
years... I don't think you have to change it often. If you change your
key too often others might not want to keep up with your keys. In my
case (my PGP key is a diffie-hellman key though) I made the largest
possible. It's probably no more secure then a medium key but why wait?
They conjecture that factoring a 1024 bit number would require too much
memory to make it feasible. I dunno. you should research current
attacks on factoring (TWINKLE might be a good place to look).
I implicitly trust that my 4096 bit key is secure. I will not change
it because I think others might have my public key (and I want to do
them a favor by keeping the same key pair). If I made a 512 bit key I
may question it because anyone can pick it off the net and factor it..
(well try to).
Tom
[*] It's a guess that you have to factor n to crack RSA. Same for
Diffie-hellmann where your private key is x, and your public key is g^x
mod p. (p and g are public parameters). In DH you have to perform a
discrete logarithm which is suppose to be at least as hard as factoring.
--
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.
------------------------------
** 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
******************************
