Cryptography-Digest Digest #551, Volume #12 Sun, 27 Aug 00 23:13:01 EDT
Contents:
Re: PRNG Test Theory (Bryan Olson)
Re: PGP Bug: A note from Ralf Senderek (Bill Unruh)
Re: How strong is this algorithm? (Jeff Davies)
Re: avalanche characteristic ("Paul Pires")
Re: PGP ADK Bug: What we expect from N.A.I. ("Ed Suominen")
Re: Steganography question (zapzing)
Patent, Patent is a nightmare, all software patent shuld not be allowed (qun ying)
Re: Steganography question (zapzing)
Pencil and paper cipher (Benjamin Goldberg)
Re: PGP ADK Bug: What we expect from N.A.I. (Ed Reppert)
----------------------------------------------------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: PRNG Test Theory
Date: Sun, 27 Aug 2000 23:55:36 GMT
Tom St.Dennis wrote:
> > > > > Since any PRNG test can tell when a stream of bits
> > > > > is empiracly random, that should suggest that any
> > > > > PRNG test can be turned into a PRNG itself.
[Big snip]
> There is no real problem. All you do is this
>
> 1. Start off with a state of 'n' bits.
> 2. Append a '1' to the state, Perform all 'x' tests on the bits.
> Record the results and remove the bit.
> 3. Append a '0' to the state, perform all 'x' tests on the bits.
> Record the result and remove the bit.
>
> Now if '1' behaves *closer* to what is random as determined by the
> tests, then output a 1 and append it to the state, etc.
>
> There is no reason why this PRNG would fail to output bits that are
> seemingly random as required by your battery of tests. The entropy of
> the output is determined solely by the entropy of the state.
>
> Perhaps this PRNG could be degenerative, slow, cumbersome, but it's a
> neat idea.
True, but I'd say this thread has taken something of a
wrong-turn in interpretation. The result we should infer is
that algorithmic measures of randomness can always be
fooled. Given a battery of deterministic tests, if random
bit streams usually pass, then there is also a finite
deterministic generator that produces bits that always pass.
There is no universal test of randomness. There is no
algorithm that can distinguish bits produced by an algorithm
from truly random bits.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: PGP Bug: A note from Ralf Senderek
Date: 28 Aug 2000 00:11:48 GMT
In <8oafhv$ro7$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Jonathan
Thornburg) writes:
]Another similar irony: During much of the US government's prosecution
]of Phil Zimmermann, CERT (funded by the US government) included in each
]CERT advisory text such as the following:
There is no irony here. The government never prosecuted Zimmermann.
What there was was a public prosecutor's investigation whether charges
should be laid for the export of PGP. The decision was not to prosecute.
This had nothing to do with the use of PGP within the USA nor the sale or giving away
of PGP within the USA (and Canada). Only RSADSI had problems with that,
not the government.
]> Using encryption
]>
]> We strongly urge you to encrypt sensitive information sent by email.
]> Our public PGP key is available from
]>
]> http://www.cert.org/CERT_PGP.key
------------------------------
From: Jeff Davies <[EMAIL PROTECTED]>
Subject: Re: How strong is this algorithm?
Date: Mon, 28 Aug 2000 01:34:19 +0100
Scott Fluhrer wrote:
> Jeff Davies <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Scott Fluhrer wrote:
> >
> > > Jeff Davies <[EMAIL PROTECTED]> wrote in message
> > > news:[EMAIL PROTECTED]...
> > > > I have an idea for a non-profit electronic cash system (a bank)
> > > > for which I have devised I think a new algorithm.
> > > Why? What's wrong with 3DES, Serpent or AES? Seriously: the banking
> > > industry currently uses (I believe) 3DES, Serpent was designed by
> someone in
> > > the banking industry (Ross Anderson), and AES (which might turn out to
> be
> > > Serpent) is considered "good enough" for the US government uses. Why
> should
> > > I trust my money to a bank that uses home-brew crypto?
> > >
> >
> > The idea is that all IP is free (in Gnu public licence way) including the
> > crypto.Is 3DES, Serpent or AES?
> Yes. DES (and hence 3DES) and Serpent are public domain (which, for my
> money, is even better than Gnu public licence). AES will be as well, once
> NIST decides what it will be.
>
There are very good reasons for going the route of GPL.
I will find out how to evaluate strength mathematically, and work it out myself
since I don't
trust always folks (PGP fiasco).
> >
> > > If each key is used to transmit a single message, it looks safe, if
> rather
> > > crude. If it is used to transmit multiple messages (and that includes
> > > multiple messages from the same "transaction"), then it looks easy
> enough to
> > > break (or at least, give the attacker enough idea about the messages to
> know
> > > which bits to manipulate). And, not putting in any sort of MAC allows
> bored
> > > attackers to have fun flipping random bits, and seeing what happens...
> > >
The initial post doesn't include something I thought was obvious - checksums
foreach field, and random inversions of the bits. The bits are (as stated)
strafed by the
encryption mechanism in a packet 100 times the size, which is filled with
random
data. (and there is a 32 bit secret in the packet).
> BTW: if you are doing that, why aren't you using OTP (One Time Pad)? What
> advantage does your approach have over that? As far as I can tell, your
> scheme uses strictly more keybits, and it is certainly no more secure than
> OTP...
>
I have advice that the method is stronger than otp.I think I will put up a
server soon, and invite people to crack it.
Perhaps with reward.
The fact that data is buried in noise makes this technique somewhat similar to
spread spectrum fm
supposedly in use awhile covertly (and now for wireless lan).
> > What does MAC mean?
> Message Authentication Code. This is an algorithm that detects (with high
> probability) changes by anyone which doesn't have the private key. One
> simplistic way of looking at it is as a "keyed checksum".
>
> If I may be free to submit a totally frank opinion: someone as ignorant of
> cryptography as you should not be designing new cryptosystems to secure
> banking transactions.
>
Looks like the ones around at the moment use SSL which isn't secure at allby
definition since many people including a 14 year old boy from a town 100km away
assembled a list of something like 140,000 credit card numbers.
I'd hate to be a 'security consultant' and have this happen to me.
> > Maybe I don't need to say it but the keys are hashed by a phrase so that
> they
> > aren't totally
> > open to someone opening your snailmail etc..
> Actually, yes, you do need to say everything your system does, if you expect
> any sort of coherent analysis of it.
>
> >
> > > So, if someone manages to grab the smartcode out of the mailbox, he will
> be
> > > able to impersonate you, and withdraw all your funds from the bank?
>
Like your debit card and it's pin.
> > >
> >
> > As far as I can tell, this impersonation is easy in any case where your
> client
> > is compromisedregardless of security system employed.
> > i.e. just about any Microsoft OS.
>
> However, I thought the whole idea of the key cards was to try to prevent
> client subversion -- if it doesn't do that, then why not drop the whole idea
> of key cards, and use public key crypto, which doesn't need the bother of
> monthly mailings...
>
Asymmetric keys are far easier to break than symmetric ones.If your client is
compromised, your private key is compromised.
By this time, your server's public key is also compromised. Traditional
mechanisms:
SSL, Lotus Notes etc have one server public key for EVERYONE and there is
NO EASY WAY
to recover from that being compromised.
> >
> > > Oh, and what do you do if someone's a bit busy, and needs to exchange
> more
> > > than 2048 messages with the bank in a month?
> > >
> >
> > Then you get the "platinum service" of 4096 keys per card. Or perhaps,
> like a
> > chequebook, youget another sent out when you're 50% through the last one.
> (or
> > when you order one).
> Order one? I thought this whole service was free (except for not giving
> interest on money in the account, which my local bank is happy to do...)
>
This comment is silly.
> --
> poncho
Jeff Davies
[EMAIL PROTECTED]
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: avalanche characteristic
Date: Sun, 27 Aug 2000 17:57:50 -0700
A good first step when these questions come up is:
http://www.io.com/~ritter/GLOSSARY.HTM
Paul
Future Beacon <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Would sombody please explain what avalanche characteristic means?
>
> Thank you for your help.
>
> Jim Trek
> Future Beacon Technology
> http://eznet.net/~progress
> [EMAIL PROTECTED]
>
------------------------------
From: "Ed Suominen" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: PGP ADK Bug: What we expect from N.A.I.
Date: Sun, 27 Aug 2000 18:01:56 -0700
Michel Bouissou wrote:
> Should N.A.I. choose to ignore these comments, this would surely lead
> many people to distrust the PGP software and move on to new systems
> such as GnuPG, which many of us are already seriously considering.
That's the direction I'm moving in. My current goal is to release a
customized installation package for GPG to clients and colleagues with a
group of batch file shortcuts that will avoid the need to use the command
line for the simpler operations like "installation" and key generation,
encryption, and decryption. When GPA (GNU Privacy Assistant) is released, if
it can be compiled into a user-friendly Win98/NT/2000 binary, I predict a
serious diversion of interest from PGP to it. (See
http://www.gnupg.org/gpa.html)
And no, GPG does *not* support ADK.
Contact Werner Koch at mailto:[EMAIL PROTECTED] if you're interested in the GPA
project and possibly want to lend a hand with the coding.
Ed Suominen
Registered Patent Agent
Web Site: http://eepatents.com
PGP Public Key: http://eepatents.com/key
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Steganography question
Date: Mon, 28 Aug 2000 01:03:58 GMT
In article <8o985b$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Guy Macon) wrote:
> >> There is no requirement that encrypted messages
> >> look like random numbers. It's a common practice,
> >> but often not done (especially in the header part).
> >
> >Ok I'd like to post a follow-up on this. Is there a way to prove
that
> >encryption is used (in england for instance) if I rip the PGP
headers
> >and footers off? Let's assume that the receivers public key is
available.
>
> I believe that it is always, in theory, possible through
> cryptanalysis to tell encrypted data from random data, with
> the usual exception of One Time Pad encryption, which can
> not be decoded or identified even by an opponent with infinite
> cleverness and resources.
>
> From a practical standpoint, this may by very hard to do.
> I have studied ARCFOUR and it's implementation found at
> http://www.ciphersaber.gurus.com and it looks like you need
> examine gigabytes of encrypted messages to identity them as
> the product of ARCFOUR encryption. I am curious about how
> PGP is in this respect.
That was my point exactly. From a practical standpoint,
encrypted data looks like random numbers .
--
"Sarcasm: the last refuge of modest and
chaste-souled people when the privacy of
their soul is coarsely and intrusively invaded."
--Dostoyevsky--
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: qun ying <[EMAIL PROTECTED]>
Subject: Patent, Patent is a nightmare, all software patent shuld not be allowed
Date: Mon, 28 Aug 2000 01:08:40 GMT
Hi All,
I just encountered this patent while surfing the net. How can the
patent office issue a patent on such fundamental things? Anyone has
some knowledge of PKI system will come out on this as a solutions. And
PGP has long history of using public key to encrypted symmetric key for
e-mail, document transferred, long before the so call patent. Any one
has comments on this issue?
=======
Title: Method and system for dynamic server document encryption
Assignee & Date: Tumbleeweed Comm. Corp. may/09/2000
Abstract
A method and system are provided for secure document delivery over a
wide area network,
such as the Internet. A sender directs a Delivery Server to retrieve an
intended
recipient's public key. The Delivery Server dynamically queries a
certificate authority
and retrieves the public key. The public key is transmitted from the
Delivery Server to
the sender. The sender encrypts the document using a secret key and
then encrypts the
secret key using the public key. Both encrypted document and encrypted
secret key are
uploaded to the Delivery Server, and transmitted to the intended
recipient. The intended
recipient then uses the private key associated with the public key to
decrypt the secret
key, and uses the secret key to decrypt the document. In an
alternative, equally preferred
embodiment of the invention, the sender uses the public key to encrypt
the document.
In yet another embodiment, the server transmits the document to the
Delivery Server for
encryption.
Claims:
1. A method for secure document delivery from a sender over a wide area
network, comprising the
steps of:
a sender encrypting a document using a secret key;
the sender contacting a Delivery Server to query a public key
associated with an intended recipient;
the Delivery Server dynamically retrieving the public key in real time
from a certificate authority;
the Delivery Server transmitting the public key back to the sender;
the sender encrypting the secret key with the public key; and
the sender transmitting the encrypted document and the encrypted secret
key to the Delivery Server
for transmission to the recipient.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Steganography question
Date: Mon, 28 Aug 2000 01:13:21 GMT
In article <8oamdo$2bn$[EMAIL PROTECTED]>,
"Harris Georgiou" <[EMAIL PROTECTED]> wrote:
>
> zapzing <[EMAIL PROTECTED]> wrote in message
> news:8o6jdv$ehq$[EMAIL PROTECTED]...
> > First of all I would like to say, personally, that
> > I think it would be very very silly to rely on
> > steganography alone to hide a message. It
> > should always be encrypted first. Always.
> >
>
> Of course it is. Still, my question is even if someone knew the
existence of
> the message (encrypted or not), how could he devise a generic method
of
> retrieving it from the data block in a way that does not depend on
details
> of the steganographic algorithm? The issue here is not the message
secrecy
> but the strength of any given steganographic method and the
difficulty of
> cracking it.
Ithink I see. You are asking about the ability
of someone to recognize that stego exists in
the message, right?
> > And, if your message is encrypted it will be
> > indistinguishable from random numbers. So
> > hiding random numbers in random numbers should
> > not be all that difficult.
> >
> > An interesting case is when the random numbers you
> > are trying to hide your message in have some
> > other distribution, such as Gaussian for example.
> > ..........
>
> This is correct, it can be done theoretically if random data volume
is much
> much larger than the real data, but there are various problem in
practice.
> Since the random vs usable data ratio cannot be very large in real
> applications, only little can be done in "fusing" real and random
data into
> one unified distribution. I 've tried implementing a variant of this:
rather
> than fusing the two distributions together, I "hide" the real data of
> Gaussian distribution in another Gaussian of larger volume (mean,
variance)
> so that the statistical attributes of it overwrite the ones of the
usable
> data. Still, I have not found a solid theory in analyzing
steganographic
> data even for trivial cases such as this.
Well if the "random" data were *really* random there
would be no problem. But I think I see what you are
getting at: no data is ever really random, or why would
you be transmitting it? what good would it be to the reciever
to just recieve a bunch of random data ???
It would look very suspicious.
It reminds me somewhat of contract bridge (yes, the card
game). In which the players engage in "bidding" for
the right to name trump, but they are at the same time
using the bid values to "communicate" information to
their partners. I know that sounds fuzzy but I'm not really
clear on the specifics.
Anyway, you're right. You can't put in too much
steganography in relation to the amount of actual
background data you are transmitting, otherwise
eve will become suspicious.
--
"Sarcasm: the last refuge of modest and
chaste-souled people when the privacy of
their soul is coarsely and intrusively invaded."
--Dostoyevsky--
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Pencil and paper cipher
Date: Mon, 28 Aug 2000 02:05:28 GMT
I have a new idea for a pencil and paper cipher, which is based partly
on a Vernam cipher, and partly on a rotor system.
First, choose a key, the longer the better.
In my example, the key is "ANTIDISESTABLISHMENTARIANISM."
Write the key plus the alphabet, removing duplicate letters, in 2-row
fence form:
A N T I D S E B L H M R C
F G J K O P Q U V W X Y Z
Split the alphabet into 4 words, length 3, 5, 7, 11:
AFN GTJIK DOSPEQB ULVHWMXRYCZ
Now, multi-encipher the message using Vernam's method, using each string
as a seperate key:
ThisI sTheP laint extIH opeTh atItI sUnde ciphe rable
AFNAF NAFNA FNAFN AFNAF NAFNA FNAFN AFNAF NAFNA FNAFN
GTJIK GTJIK GTJIK GTJIK GTJIK GTJIK GTJIK GTJIK GTJIK
DOSPE QBDOS PEQBD OSPEQ BDOSP EQBDO SPEQB DOSPE QBDOS
ULVHW MXRYC ZULVH WMXRY CZULV HWMXR YCZUL VHWMX RYCZU
=====================================================
QLDAM WCXMS GYEJV TPKKS TPKML CUOLQ DDXGW IBNAG KTYIC
How would one break this cipher, and is a computer needed?
Assume that no two messages use the same key, since this
would make the code as easy to break as an N-Time-Pad (N>1),
and assume that messages are less than 3*5*7*11 letters long,
since this would make breaking it like a vernam cipher with
known key length.
--
... perfection has been reached not when there is nothing left to
add, but when there is nothing left to take away. (from RFC 1925)
------------------------------
From: Ed Reppert <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: PGP ADK Bug: What we expect from N.A.I.
Date: Mon, 28 Aug 2000 02:15:14 GMT
In article <JSiq5.13991$[EMAIL PROTECTED]>, "Ed
Suominen" <[EMAIL PROTECTED]> wrote:
> When GPA (GNU Privacy Assistant) is released, if
> it can be compiled into a user-friendly Win98/NT/2000 binary, I predict a
> serious diversion of interest from PGP to it. (See
> http://www.gnupg.org/gpa.html)
I didn't see any evidence of an effort to develop a Mac version of this
thing on the web site. I don't suppose there is one, is there?
------------------------------
** 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
******************************
