Cryptography-Digest Digest #210, Volume #10 Thu, 9 Sep 99 15:13:03 EDT
Contents:
Digital Certificates and Authentication ([EMAIL PROTECTED])
Re: THE NSAKEY ("Douglas A. Gwyn")
Re: arguement against randomness ("Douglas A. Gwyn")
Re: simple key dependent encryption ("Douglas A. Gwyn")
Re: Random and pseudo-random numbers ("Douglas A. Gwyn")
Re: Unix Crypt on MS Windows platform ("Douglas A. Gwyn")
Re: Plaintext block size ("Douglas A. Gwyn")
Re: Difference between Encryption and scrambling..?
Re: DES and initial permutation ("Charlie Harrison")
Re: compression and encryption (Tom St Denis)
Re: some information theory (Tom St Denis)
Re: GnuPG 1.0 released (Tom St Denis)
Re: Digital Certificates and Authentication (Tom St Denis)
Re: Description of SQ ("Kostadin Bajalcaliev")
Re: unix clippers that implement strong crypto. (Bill Unruh)
Re: compression and encryption ("Douglas A. Gwyn")
Re: SQ2 Announcement (David Wagner)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Digital Certificates and Authentication
Date: Thu, 09 Sep 1999 14:45:34 GMT
This may be a dumb question, but let's say you have a system that server
that requires authentication to access. My question is, if the
authentication process uses Digital Certificates, do you need to deal
with passwords? Since you can verify a Digital Certificate for
authenticity, why bother with a password?
Casey
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: THE NSAKEY
Date: Thu, 9 Sep 1999 14:33:23 GMT
fungus wrote:
> Ask yourself why the hell the NSA would give cash to Netscape?
Perhaps they are dependent on Netscape Navigator and wanted to
ensure that they had access to the source code.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: arguement against randomness
Date: Thu, 9 Sep 1999 14:39:35 GMT
Tim Tyler wrote:
> elarson <[EMAIL PROTECTED]> wrote:
> : It doesn't take a pompous genuis to see the randomness of Nature.
> If the universe is deterministic, all this is dead wrong.
No, randomness and determinism are not exact opposites.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: simple key dependent encryption
Date: Thu, 9 Sep 1999 14:38:29 GMT
steve cator wrote:
> 1. the user enters a key.
> 2. the program reads in a file, byte by byte.
> 3. the value of each byte is added to the next ascii value of the key,
> and written back to the file.
> for decryption, the ascii value of the each key character is SUBTRACTED
> from the byte.
> a) what is this type of encryption called?
All sorts of epithets come to mind, but if you use a finite,
repeating key it is called a "periodic Caesar polyalphabetic".
> b) am i wrong in thinking this type of key dependent encryption would be
> tough to crack?
You're not only wrong, you're way wrong. Such systems are
used as exercises in elementary courses on cryptanalysis.
It is much safer to use an encryption system designed by an
experienced cryptographer than to roll your own as a newbie.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Random and pseudo-random numbers
Date: Thu, 9 Sep 1999 14:44:03 GMT
Eric Lee Green wrote:
> None of these are working for me if I'm wanting my code to run on
> HPUX, Solaris, or SCO Unix in unattended mode.
There is (so far as I know) no POSIX-standard true-random generator.
You can attach a hardware RNG to a serial port, for example, and fetch
however many random bits you need when you need them; or, if all your
systems are attached to a net, they could fetch random bits from some
random bit server that has the appropriate hardware. I think there's
even a publicly-accessible Internet site serving random bits, if you
want to trust it.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Unix Crypt on MS Windows platform
Date: Thu, 9 Sep 1999 14:57:53 GMT
John Brugioni wrote:
> Anybody have a utility to do unix crypt on Windows NT, 95 or 98?
Sure, just use the freely available binary release of 7th Edition
UNIX with one of the freely available PDP-11 emulations.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Plaintext block size
Date: Thu, 9 Sep 1999 14:49:02 GMT
Kwong Chan wrote:
> My understanding is that for a stream cipher, both the input plaintext
> alphabets, the ciphertext alphabets and the key alphabets consists of
> {0,1}. And the substitution mapping is defined by S=p xor z
No. A stream cipher operates on a plaintext alphabet one symbol
at a time and produces one ciphertext symbol per plaintext symbol.
A symbol can have any number of bit, or even a variable number of
bits. And the ciphertext isn't necessarily obtained by XORing
anything with the plaintext. How the information in the key is
used to initialize the system's cryptovariables depends very
strongly on the particular system.
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Difference between Encryption and scrambling..?
Date: 9 Sep 99 14:37:14 GMT
Jae-Yong Kim. ([EMAIL PROTECTED]) wrote:
: I wanna know exactly what difference is between scrambling and encryption.
: thanks in advance..
Well, the difference is that scrambling has no key. The pseudorandom
sequence used to make a modem's data stream irregular is public
information, part of the modem standards. So anyone can build a modem
conforming to the standards, and no-one is prevented from listening in.
John Savard
------------------------------
From: "Charlie Harrison" <[EMAIL PROTECTED]>
Subject: Re: DES and initial permutation
Date: Thu, 9 Sep 1999 16:27:25 +0100
>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).
jerome wrote in message ...
>i try to understand the aim of the initial permutation in DES. several
>sources said that there is no cryptanalisys influence.
>But DES has been designed by knowledgeable people and i dont think
>they will add a component without explicit reasons.
>
>anyone know what is the aim of this initial permutation ?
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: compression and encryption
Date: Thu, 09 Sep 1999 15:23:46 GMT
In article <7r89em$2oe8$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> This is the SHIT part Tommy show me DEFALTE in a program that
> has the ONE to ONE porperrty as I dedined it. YOu can't becasue you
> lied. Maybe you can get a job as a PR person for the NSA I think that
> would wnat one such as you who lacks any real understanding.
Ok well... I don't know if C(D(M)) = M for deflate but I know there are
no restrictions on the input (to either function).
> So where do you get this Comprss(Decompress(B))=B code for the
> LZ77 file compression. Again I guesss this is to complicated for you.
> It does not have to say LZ77 in the file. The structure of the
compressed file
> itself can give that information away. LIke I have said if there is a
version
> that is one to one SHOW ME. Stop saying it is easy to find one. Just
> do it or SHUT UP.
The thing is your huffman coder has structure... point finale.
> If you are still so stupid to think that if a compression routine
> adds so much structure that most files if looked at were not
> uncompressable. That this fact could not be used by the NSA
> when trying to break a system then there is no point in arguing.
> You might as well be using a compression system that adds the
> words some where in the file "this is the correct file". Becasue
> that in effect is what your doing when you use most compression
> routines. IF it isn't staring you in the face in the first 3 bytes you
> think it is not there. But as usual your worng. I have told you how
> to test for "one to one"ness in a compression decompression routine
> but even that is over your head. Your thinking is the compression
routine
> does not put out a constant first few bytes it is OK. But your to
> dam lazy to check anything.
> Since you think that compressions sole purpose is to make the file
> smaller with out any consideration that it could weaken the overall
> encryption system then you will fail in your efforts to write strong
> encryption. Because you lack the ability to think. I am sorry the
> crypto gods could not help you in this thread. It is my guess this
> is one area they just as soon have you kept stupid as well as the
> masses.
The thing is the compression should not increase or decrease the
security of the cryptosystem. What if you are sending messages that do
not compress? What if I told you the amount of entropy in the message
and compressed message where the same? What if I told you that your
method has structure that could possibly be exploited (given a known
language). What if I told you, that you are paranoid?
Tom
--
damn windows... new PGP key!!!
http://people.goplay.com/tomstdenis/key.pgp
(this time I have a backup of the secret key)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: some information theory
Date: Thu, 09 Sep 1999 15:13:28 GMT
In article <[EMAIL PROTECTED]>,
"Sam Simpson" <[EMAIL PROTECTED]> wrote:
> I suggest you take a look at: D.Wagner, S.Bellovin, "A Programmable
> Plaintext Recognizer", 1994 - it shows that compression IS useful
> against some attacks.
I will just wait till there is a 'programmable compressed text
recognizer". My point is that the amount of information has not changed
thus the message is no more random.
Tom
--
damn windows... new PGP key!!!
http://people.goplay.com/tomstdenis/key.pgp
(this time I have a backup of the secret key)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: GnuPG 1.0 released
Date: Thu, 09 Sep 1999 15:29:59 GMT
In article <7r89mu$2oe8$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> In article <7r77c9$hmf$[EMAIL PROTECTED]>, Tom St Denis
<[EMAIL PROTECTED]> wrote:
> >In article <7r6kqd$2rog$[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> >> Joe I am sure the Chinese may know as much as we do about
encryption
> >> have you ever tried to read Chinese. But I think the NSA would
endorse a
> >> system for banks that they could break. I think that they think
they are so
> >> far ahead that no one but them would be able to break it. Besides
if the
> >> President gets pissed at some leader like the Yugoslavian leader.
They may
> >> be tasked with stealing his money from foreign banks. It makes
their job
> >> harder if they can't break the encyption the bank is using. Yet I
am sure
> >> the NSA though farther ahead in certain areas of encryption. Are
still unable
> >> to break certain ciphers between people. Becasue half the battle is
finding
> >> out what the enemy is using. Then you try to break it.
> >> If people just combine in secret 2 or 3 methods that are different
from each
> >> other and don't change the lenght or add headers or structure that
can be
> >> exploited then I doubt if the NSA can break it if only the
encrypted messages
> >> are used. Even if all of the methods are ones that they could
easyly break.
> >> But again I ask I thought I asked in this thread somewhere. Is
there any
> >> thought about having the option of dropping those freindly weak
features
> >> fhat are in PGP that could be BackDoors for the NSA.
> >
> >
> >The chinese and nsa... seems like a theme.
> >
> >First off the NSA does not control foreign banks.... The germans
control
> >german banks, the french theirs, the brits theirs etc... etc...
> >
> >Second PGP source code is avail... why not check it yourself instead
of
> >spreading stupid crappy dump brain erasing rumours that are only good
for a
> >laugh.
>
> Tom I have looked at PGP 2.6.3 code which I am sure is more than
what
> a lazy little boy like you would do.
I have the pgp263s.zip file on my disk, I did peek thru it a bit as
well. I am by no means a crypto specialist so I don't really have any
insightful comments. sorry.
Anyways, mr smart@@# you read the source, where are the NSA backdoors?
Tom
--
damn windows... new PGP key!!!
http://people.goplay.com/tomstdenis/key.pgp
(this time I have a backup of the secret key)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Digital Certificates and Authentication
Date: Thu, 09 Sep 1999 15:33:29 GMT
In article <7r8h6a$f29$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> This may be a dumb question, but let's say you have a system that
server
> that requires authentication to access. My question is, if the
> authentication process uses Digital Certificates, do you need to deal
> with passwords? Since you can verify a Digital Certificate for
> authenticity, why bother with a password?
I would sign a timestamp using my private key that can be verified with
a public key that has been fixed into the server (presumably by myself).
Tom
--
damn windows... new PGP key!!!
http://people.goplay.com/tomstdenis/key.pgp
(this time I have a backup of the secret key)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Kostadin Bajalcaliev" <[EMAIL PROTECTED]>
Subject: Re: Description of SQ
Date: Thu, 9 Sep 1999 16:33:54 +0200
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.
>the outputs of a generator does not mean that the analyst has
>to guess one full bit but something less than that.
>
>M. K. Shen
>-----------------------------
>http://home.t-online.de/home/mok-kong.shen (new addr.)
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Crossposted-To: comp.security.unix
Subject: Re: unix clippers that implement strong crypto.
Date: 9 Sep 1999 16:03:09 GMT
In <[EMAIL PROTECTED]> Armin Ollig <[EMAIL PROTECTED]> writes:
>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.
>
>I currently know of three implementations that could do the work.
>-> 4.4 BSDs 'bdes' implements DES
>-> Eric Young's implementation of DES and 3DES
This is fine for what you want.
>-> A joke called 'crypt' that ships with irix (Enigma based)
Yes, this is a joke. It is easily (ie by a 286 over coffee) broken.
>I do not want to use any *DES* algorithms.
Why not? It is the most studied of algorithms and has withstood 20 years
of attacks. Ordinary DES is breakable by exhaustive search, 3DES is not.
>The Enigma based 'crypt' tool that comes with irix must be worse than
>DES.
Uh, "must be worse" is one of the biggest understatements I have heard.
>Wherer can i find an implementation of IDEA or Blowfish that comes with
>the source code ?
IDEA is patented. It is illegal to use it without a license.
For Blowfish, try Gutman's libcrypt.
>Or do i really need to mess around with pgps source in order to stop
>this temp
>file nonsense .....
PGP is overkill.
Note all you would be using is the symmetrical encryption in PGP.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: compression and encryption
Date: Thu, 9 Sep 1999 16:26:38 GMT
Tom St Denis wrote:
> The thing is the compression should not increase or decrease the
> security of the cryptosystem.
But usually it does.
> What if you are sending messages that do not compress?
For any decent compression scheme, that would mean that
the original message already contains very little redundancy,
and in that particular case compression buys very little.
But the way to evaluate a system is in terms of its
performance for the entire expected gamut of application,
not just for isolated cases.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: SQ2 Announcement
Date: 9 Sep 1999 10:28:19 -0700
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.
------------------------------
** 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
******************************
