Cryptography-Digest Digest #215, Volume #10 Fri, 10 Sep 99 09:13:02 EDT
Contents:
Re: GnuPG 1.0 released (Paul Rubin)
Re: some information theory (Tim Tyler)
Re: MUM III (3 Way Matrix Uninvertable Message) (Jayant Shukla)
Re: Self decimated lfsr (Cairus)
Looking for an asymmetric system (Emmanuel Drouet)
Re: Looking for Completely-Free Strong Algorithms ("Gary")
Re: Description of SQ (Mok-Kong Shen)
Re: unix clippers that implement strong crypto. (Armin Ollig)
Re: DES and initial permutation ([EMAIL PROTECTED])
Re: Looking for Completely-Free Strong Algorithms ("Richard Parker")
Re: unix clippers that implement strong crypto. (Ernst-Udo Wallenborn)
Re: unix clippers that implement strong crypto. (Wyman Eric Miles)
Re: Looking for Completely-Free Strong Algorithms (Paul Crowley)
Re: NSAKEY as an upgrade key (Was: NSA and MS windows) (Paul Crowley)
Re: NSA and MS windows (Geoff Thorpe)
Re: SQ2 Announcement ([EMAIL PROTECTED])
Re: unix clippers that implement strong crypto. (Martin Pauley)
Re: Looking for Completely-Free Strong Algorithms (Reini Urban)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: GnuPG 1.0 released
Date: 10 Sep 1999 05:24:49 GMT
In article <[EMAIL PROTECTED]>,
Jerry Coffin <[EMAIL PROTECTED]> wrote:
>If, for example, you created a program that could
>decompress and view GIF files, this might be considered as
>contributory infringement, because it's of no real use unless used in
>some sort of overall system that can also create GIF files.
I can't make any sense of this. Just about any web browser can
decompress and view GIF files, but if that isn't direct infringement
then I don't see how it can be contributory infringement. The GIF
files are created by totally separate programs run by totally separate
people, and those GIF creation programs might have to be licensed by
Unisys. However, writing, distributing, or using unlicensed web
browsers doesn't cause anyone to distribute unlicensed GIF creation
programs.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: some information theory
Reply-To: [EMAIL PROTECTED]
Date: Thu, 9 Sep 1999 15:16:47 GMT
Anti-Spam <[EMAIL PROTECTED]> wrote:
Why limit your discussion to a particular compression algorithm?
: Compressing data/files prior to encryption with a cipher system does not
: alter the frequency of the SYMBOLS encoded in the compressed data/file
: relative to their original frequencies in the uncompressed file/data.
It will with most types of compression.
: Compressing prior to encrypting does not permutate the order of the
: SYMBOLS encoded in the compressed data/file relative to their original
: order as encoded in the uncompressed file/data.
Certainly it can do. This can be the best way of compressing the data.
: First, Compressed data is NOT necessarily random data.
If your compressed data is distinguishable from randomness, you're using
a sub-optimal compression scheme.
: Many of us assume the compressed form of a file is "equivalent" in some
: form to true random data. It is not.
It certainly /should/ be - or your compression algorithm is likely to
be behaving sub-optimally.
: Compressed files will not pass statistical tests for random bit streams.
: A compressed file is non-random.
Speak for your own compressed files ;-)
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Where you do depends on how you look.
------------------------------
From: [EMAIL PROTECTED] (Jayant Shukla)
Subject: Re: MUM III (3 Way Matrix Uninvertable Message)
Date: 10 Sep 1999 05:45:24 GMT
"Gary" <[EMAIL PROTECTED]> writes:
>How would this be cracked?
I can think of couple of ways.
>Alice has a message which she turns into an uninvertable square matrix, M.
>She picks a random invertable square matrix, A.
>Alice sends Bob the product of these 2 matrices, AM.
in your protocol, A acts as the key and M is the message.
If you can recover A you have broken the cipher. For simplicity,
say E = AM.
ATTACK I
========
Obviously your cipher is not resistant to choosen plaintext
attack......
ij th element of the ciphertext E is given by.
E_ij = sigm_k a A_ik * M_kj
collect "n" plaintexts and their corresponding ciphertexts
and you can figure out all the elements of the matrix A.
ATTACK II
=========
using matrix A to encrypt the message M is like using
"n" different knapsacks in a sequential order to encrypt
the message (first column of M is encrypted by knapsack
represented by the first row of A to produce element
AM_11). Need I say more? You can read up on how Shamir
broke the knapsack cryptosystems.
The problem is that you are using linear algebra methods
to design a cipher. They can be broken easily.
regards,
Jayant Shukla
------------------------------
From: Cairus <[EMAIL PROTECTED]>
Subject: Re: Self decimated lfsr
Date: Fri, 10 Sep 1999 06:55:53 GMT
> If I pick [1,2] and have an LFSR sequence 00101100110101100011...
> Then my output sequence is 00110010110001...
> The 0's tell me that the next bit I see really is the next bit in
> the sequence.
Thanks again for your answer. What you say is right, however my
ipothesis was that the output bit and the control bit do not coincide
(by 'control bit' I mean the bit which determines the number of steps),
whereas in your example they do, and this of course gives a big help to
the analyst. But what if they do not?
I mean: if the lfsr if L bit long, then at each step its content can be
represented by L bit, let's say R(0), R(1), ..., R(L-1). For example
you could use R(0) for the output and then look at R(3) to determine
how many steps to advance before generating the new output bit.
Cairus
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Emmanuel Drouet <[EMAIL PROTECTED]>
Subject: Looking for an asymmetric system
Date: Fri, 10 Sep 1999 09:41:59 +0100
Hello !
1/ I would like to know what is the strongest asymetric cryptosystem
2/ What do you think about :
RSA, elgamal, McEliece, elliptic curves, Merkle-hellman
3/ Do you know another asymetric cryptosystem ?
Thanks
Manu :o)
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: Looking for Completely-Free Strong Algorithms
Date: Fri, 10 Sep 1999 08:47:07 +0100
Old TEA (Tiny Encryption Algorithm) and the new block version of it is worth
looking at.
Developed by R M Needham and D J Wheeler.
http://vader.brad.ac.uk/tea/tea.shtml
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Description of SQ
Date: Fri, 10 Sep 1999 09:49:54 +0200
Kostadin Bajalcaliev wrote:
>
> Mok-Kong Shen wrote in message <[EMAIL PROTECTED]>...
> >Let the 8 bit output be denoted by H and let's append to H one bit B
> >and call BH (9 bits) the output of a new generator. If B
> >is always produced as 0101010101 or 1111111111, do you think that
> >deleting B from the output BH matters for the analysis of the new
> >generator? It is known that the output bits of e.g. LCPRNGs have
> >more or less high correlations, particularly in the lower order
> >positions. The above two points indicate that in general the effect
> >(on analysis) of omitting one bit from the outputs of a generator
> >depends very much on the 'quality' (difficult to define) of that
> >generator. Anyway, it seems safe to say that omitting one bit from
>
> Information Lose theory is applieble one if the generator is a "quality"
> one, statistically good generator, only than the lost bit will be important.
> generators producing 1111111111 or 1010101010 are not random at all.
How do you test your 'quality one'? Knuth's book, for example,
devotes much space to discuss the quality of PRNGs. But still an
universally accepted standard test for that 'quality' doesn't
exist, as far as I know.
M. K. Shen
------------------------------
From: Armin Ollig <[EMAIL PROTECTED]>
Crossposted-To: comp.security.unix
Subject: Re: unix clippers that implement strong crypto.
Date: Fri, 10 Sep 1999 09:54:16 +0200
Martin Pauley wrote:
>
> Armin Ollig <[EMAIL PROTECTED]> writes:
> > Wherer can i find an implementation of IDEA or Blowfish that comes with
> > the source code ?
>
> Eric Young's ssleay/openssl package contains Blowfish.
> You won't see it when you do 'openssl ciphers' since it is not part of
> the SSL standard, but you will see it if you do 'openssl enc help'
> ('help' is an invalid option, causing valid options to be displayed)
>
> So, you can stick a 'openssl bf -e -k wibble' in your pipe to encrypt
> (-e for encrypt; -k <passowrd> for the key)
> Change the -e to a -d to decrypt.
>
> IDEA is also there.
Martin,
thanks a lot, this is **__exactly__** what i was looking for.
Compiles like a charm even on irix64 with mipsPro compilers :-)
Source code is well documented.
I have included the as i call it "encryption pipe" in my backup script.
Note:
AFAIK it is better to first encrypt and then compress the data.
This means more cpu cycles but better security, because the compression
may leave a characteristic pattern that may be usefull for
crytpanalysis. ?!
thanks again,
best regards.
--Armin
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: DES and initial permutation
Date: Fri, 10 Sep 1999 09:08:16 GMT
In article <7r8ji9$b34$[EMAIL PROTECTED]>,
"Charlie Harrison" <[EMAIL PROTECTED]> wrote:
> From Bruce Schneir's book (sorry about the spelling!), it was
speculated
> that the initial permutation was to slow down software
> encryption/decryption, but allow for fast hardware implementations (or
> something along those lines).
>
This must be just about the most quoted line from Bruce's book, which is
a pity as it is almost certainly wrong. Compared to the rest of the DES
algorithm the initial permutation does not slow it down by any
significant amount. Therefore it was not put in to slow down the
software implementation. Adding an extra operation to the hardware does
not in anyway speed-up or simplify the hardware even in very old several
chip systems.
So it does not significantly slow down the software and it does not aid
or speed up the hardware. If someone is sure I am wrong, I would be
pleased to see your reasoning in detail.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Richard Parker" <[EMAIL PROTECTED]>
Subject: Re: Looking for Completely-Free Strong Algorithms
Date: Fri, 10 Sep 1999 09:24:18 GMT
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote:
> I'm looking for royalty-free strong algorithms. I know that AES (when it's
> decided) will meet the criteria, but I need something fairly soon, and I
> need it to have free source code available also (not enough time to do it
> right myself).
I would recommend Blowfish, CAST-128, or 3DES as strong royalty-free
algorithms that have been around for "a while." Also, the authors of
three of the five AES finalists have indicated that their algorithms
are royalty-free. These three algorithms are: Rijndael, Serpent, and
Twofish. Statements from the authors that these algorithms are
royalty-free can be found at the following URLs:
Blowfish
"...Unpatented and royalty-free, No license required..."
<http://www.counterpane.com/blowfish.html>
CAST-128
"The CAST-128 cipher described in this document is available worldwide
on a royalty-free basis for commercial and non-commercial uses."
<http://www.ietf.org/rfc/rfc2144.txt>
Rijndael
"Rijndael is available for free. You can use it for whatever purposes
you want, irrespective of whether it is accepted as AES or not."
<http://www.esat.kuleuven.ac.be/~rijmen/rijndael/>
Serpent
"Serpent is now completely in the public domain, and we impose no
restrictions on its use."
<http://www.cl.cam.ac.uk/~rja14/serpent.html>
Twofish
"Twofish is unpatented, and the source code is uncopyrighted and
license-free; it is free for all uses."
<http://www.counterpane.com/about-twofish.html>
-Richard
------------------------------
Crossposted-To: comp.security.unix
Subject: Re: unix clippers that implement strong crypto.
From: Ernst-Udo Wallenborn <[EMAIL PROTECTED]>
Date: 10 Sep 1999 12:07:59 +0200
Armin Ollig <[EMAIL PROTECTED]> writes:
> hi,
>
> iam working on a solution for encrypting backups to a mag-tape.
> The application i need would be a symetrical clipper that reads
> the unencrypted stream from standard in and writes the encrypted
> stream to standard out.
[snip]
> unfortunatly i cannot use pgp because it does create a temp file
> of the size of the input stream and writes to the output file (or std
> out)
> not until the input stream is finished. In my case this would require
> several
> GB of temp space.
[snip]
What about the gnu privacy guard, from www.gnupg.org?
I think it installs itself in a mode that prevents any hard
disk space from being used (although i could be wrong here).
Then you'd just say
| gpg --symmetric --cipher-algo BLOWFISH |
or any of 3DES, CAST5, BLOWFISH, TWOFISH.
--
Ernst-Udo Wallenborn
Laboratorium fuer Physikalische Chemie
ETH Zuerich
------------------------------
From: [EMAIL PROTECTED] (Wyman Eric Miles)
Crossposted-To: comp.security.unix
Subject: Re: unix clippers that implement strong crypto.
Date: 10 Sep 1999 11:05:36 GMT
In article <[EMAIL PROTECTED]>, Armin Ollig <[EMAIL PROTECTED]>
writes:
|> Martin Pauley wrote:
|> >
|> > Armin Ollig <[EMAIL PROTECTED]> writes:
|>
|> Note:
|>
|> AFAIK it is better to first encrypt and then compress the data.
|> This means more cpu cycles but better security, because the compression
|> may leave a characteristic pattern that may be usefull for
|> crytpanalysis. ?!
|>
|> thanks again,
|> best regards.
|> --Armin
Actually, I believe it's better to first compress, then encrypt the data. CPU
overhead is a tossup: in your scenario, the compression system spends time
attempting to compress encrypted data, which it can't. Compressing first will be
successful and have the cryptographic advantage of removing a great deal of any
repeated patterns in the data, before feeding it to the encryption program.
(ssh -C, for example, compresses first because the resulting data stream is
largely incompressible after encipherment)
Of course, if the compression is done in hardware--on the tape drive, say--you
don't lose anything by attempting to compress the extremely random data that
comes out of an encryption engine. You don't save tape space, either, though.
--
Wyman Miles
Systems Administrator, Rice University, Texas.
(713) 737-5827, e-mail:[EMAIL PROTECTED], pager:[EMAIL PROTECTED]
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Looking for Completely-Free Strong Algorithms
Date: 10 Sep 1999 10:21:43 +0100
Underspecified error! What *other* characteristics would you like the
algorithm to have?
* completely-free (stated)
* strong (of course)
* free source code available (I'll assume)
* fast (I assume - how important is this?)
It sounds like you're encrypting streams of data. How long do the
streams tend to be? Do you mind if it's a native stream cipher (like
RC4) or a block cipher (eg Blowfish) in a chaining mode? Do you care
how much memory the cipher uses in its normal operation? Does it make
a difference if that memory stays the same for all keys (like
Rijndael) or has to be re-written for a new key (like Twofish)?
There are many completely-free strong ciphers, so it'll be on the
basis of characteristics like this that we'll be able to make a
recommendation.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: NSAKEY as an upgrade key (Was: NSA and MS windows)
Date: 10 Sep 1999 10:03:55 +0100
"Thomas J. Boschloo" <[EMAIL PROTECTED]> writes:
> MS could issue a patch that disabled the first key in Windows. They can
> do anything. Allowing controls signed with the first key would not be an
> option, since the key was compromised.
PGP key revocation certificates are signed with the compromised key.
I see no security gain in signing the key replacement patch with the
backup key unless there's a way for users to explicitly disable the
primary key.
It's true that a sensible security architecture would use multiple
keys for secure key replacement, but it wouldn't look anything like
the NSAKEY mechanism.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Geoff Thorpe <[EMAIL PROTECTED]>
Subject: Re: NSA and MS windows
Date: Fri, 10 Sep 1999 12:43:53 +0100
"SCOTT19U.ZIP_GUY" wrote:
> >- for them I have to feel profoundly sad. If you regard us all as
> >"dumber countries" then I suggest you observe carefully who is allowed
> >to export crypto product to who. Also, take a look at the post-graduate
> Wake up it was satire and humor. OF course I don't really think other
> countries are dumber ( unless they keep letting the US rob them blind)
It was not satire or humour, it was more of the same old spillage.
Perhaps you didn't mention Bill Clinton, NSA, China, Bruce Schneier or
"the Feds" as much as you usually do, but you are probably the only one
who can find humour within what you wrote. Despair perhaps, but not
humour.
> I have meet people who have left the US for New Zealand some like it.
> Some say it is to socailistic. I like the weather and at one time thought
> of moving there my self. I know one person who went ther for several
> years and came back ( I wish he would have stayed).
What does any of this have to do with your previous waffling about the
NSAKEY issue?
> I have not really looked at moving there for several years and most
> likely am no longer elligable since at my age I think you need more
> cash or connections to get in. As I rember though they seemed to
Well, I'm sure we won't lose too much sleep about it, whatever the
reasons.
> but a high premium on shin color to and I have some dark friends who
> hate the place.
The shin colour in NZ is pretty varied - as with your "crypto" you seem
to have only the merest fraction of an idea of what you're talking about
here. We have Indian, Asian, South-Pacific and African shins ... shins
of all colours in fact. Skin too. Your dark friends probably hate the
place because like yourself, they prefer people with much lower
B-S-detection levels.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: SQ2 Announcement
Date: Fri, 10 Sep 1999 11:41:13 GMT
You do not sound like a broken record, only you sound interested at all.
Yes the key is the same in all rouns but the strategy is somthing else. If we
have A,B and C=F(A,B) nowing A and C without F is not enought to find B. This
is realized forcing F to be affected by the value of B and A. If A is the
data and B the key than usign SQ2 you are never going to be able to
mathematically specify which value is transformed accoring to the other one.
This is the idea of undeterminated algorithms.
In article <7r8qnj$v25$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
> I hate to sound like a broken record, but: Have you analyzed its
> security against slide attacks?
>
> If I understand correctly, it sames to use the same round subkey
> in every round, which makes me suspect that it might be susceptible
> to sliding.
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Martin Pauley <[EMAIL PROTECTED]>
Crossposted-To: comp.security.unix
Subject: Re: unix clippers that implement strong crypto.
Date: 10 Sep 1999 10:55:03 +0100
Armin Ollig <[EMAIL PROTECTED]> wrote:
> AFAIK it is better to first encrypt and then compress the data.
> This means more cpu cycles but better security, because the compression
> may leave a characteristic pattern that may be usefull for
> crytpanalysis. ?!
I compress first and then encrypt, for two reasons:
1. an encrypted file does not compress well; quite often an encrypted
file will increase in size when you try to compress it.
2. compressed files contain less of a pattern than most plain files.
This is by design, since most (all?) compression algorithms work by
detecting and removing patterns. In contrast, plain files tend to
have well-defined patterns, which is why they compress.
I'm not an encryption expert, but I met one once! :-)
-- Martin Pauley
------------------------------
From: [EMAIL PROTECTED] (Reini Urban)
Subject: Re: Looking for Completely-Free Strong Algorithms
Date: Fri, 10 Sep 1999 13:05:18 GMT
Reply-To: [EMAIL PROTECTED]
sorry off topic, but patents are such a mess.
and largely an american phenomenon only.
what is the best newsgroup to discuss the evil of software patents, esp.
with crypto. (law, social science, politics?)
David A Molnar wrote:
>Joseph Ashwood <[EMAIL PROTECTED]> wrote:
>> I'm looking for royalty-free strong algorithms. I know that AES (when it's
>> decided) will meet the criteria, but I need something fairly soon, and I
>> need it to have free source code available also (not enough time to do it
>> right myself). Now before Scott plugs himself again, let me say that this
>
>I'm assuming that you want a symmetric system.
>
>3DES is tried, true, and royalty-free. It's part of Wei Dai's crypto
>library : http://www.eskimo.com/~weidai/cryptlib.html
>
>Twofish has reference source code available from Counterpane. It has made
>it to the final round of AES, for what you think that's worth.
>http://www.counterpane.com/twofish.html
>
>Blowfish is royalty-free, as well.
>http://www.counterpane.com/blowfish.html
>
>Those are the only algorithms which I'm 100% sure are unpatented
>at this moment. There are likely other unpatented algorithms which
>may be useful to you. Maybe checking the Block Cipher Lounge would
>help determine whether another algorithm is attractive enough to
>investigate : http://www.ii.uib.no/~larsr/bc.html
--
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
------------------------------
** 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
******************************
