Cryptography-Digest Digest #790, Volume #12 Thu, 28 Sep 00 14:13:01 EDT
Contents:
Re: Josh MacDonald's library for adaptive Huffman encoding (SCOTT19U.ZIP_GUY)
Re: Why is TwoFish better than Blowfish? (SCOTT19U.ZIP_GUY)
Re: Adobe Acrobat -- How Secure? (Dave Ashley)
Deadline for AES... (Volker Hetzer)
Re: I am only an egg... ("Trevor L. Jackson, III")
new Pegwit ([EMAIL PROTECTED])
Re: Chaos theory (Derek Bell)
Re: Chaos theory (Derek Bell)
How to get Certificate content after HTTPS Authentication ("Joyce")
Re: Cipher Illiteracy (Mike Rosing)
Re: RSA and Chinese Reminder Theorem (Bob Silverman)
Re: Notice: Problems with DiehardC. ("Paul Pires")
Chaining for authentication (Marc)
Re: Non-Repudiation mechanism ("Kevin Crosbie")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: comp.compression,comp.theory
Subject: Re: Josh MacDonald's library for adaptive Huffman encoding
Date: 28 Sep 2000 13:50:36 GMT
[EMAIL PROTECTED] (Mok-Kong Shen) wrote in <39D2FDEB.E8BD92EA@t-
online.de>:
>
>
>Alex Vinokur wrote:
>>
>> Josh MacDonald's library for adaptive Huffman encoding :
>> http://www.xcf.berkeley.edu/~ali/K0D/Algorithms/huff/
>
>I like to repeat a question I asked before. How does
>adaptive Huffman compare with static Huffman that
>employs an exact frequency distribution of the texts?
>Thanks.
>
I see where you can get confused. I was reading an
article on the net the other day which claimed it was
talking about adaptive huffman compression but it was
talking static huffman compression,
There are articles that tell what bounds adaptive
huffman compression to static huiffman compression,
But doing tests on my own static huffman compression
( if you don't count space for table) usually beats
adaptive huffman compression. But not always. Some files
are such that adaptive hufman compression beats the static
even if you don't count the table space.
Hay its not that hard to test this yourself, but one
word of warning not all adaptive huffman compression programs
the same most use what you called a NYT followed by the ascii
coding of the symbol when a new symbol is incountered in
the input stream. Mine do not.
My main one starts with a full tree and then the tree
changes based on input. There is no reason that if you always
compressing simialar files not to use a different starting tree
and a different amount of adapting. If one is only using a certain
class of files. I think a mod like above would beat static most
of the time since you can tune it the types of file you like.
But like I said it is not that hard to play with it.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Why is TwoFish better than Blowfish?
Date: 28 Sep 2000 14:03:52 GMT
[EMAIL PROTECTED]=NOSPAM (Arturo) wrote in
> I doubt it. The author is Bruce Schneier, boss-in-chief of
> Counterpane
>security and writer of the "bible" in crypto, Applied Cryptography. Not
>the kind of guy I think most likely to have been bought by the NSA
>
Then please tell me the kind of guy you think the NSA would own.
Terry who seems not to have press conections or do you think I am
the type Arturo.
>> At least these
>>are my feelings about these fishy ciphers. It seems like NSA humour
>>to give both ciphers FISHY names.
>
> Rather blame the author.
I see blame the author because this is nit the kind of twist
the NSA would do?
>
>> But since the idea of a cipher is security. It is plain stupid to
>>say Twofish is better than Blowfish becasue Blowfish is a PC cipher.
>>If one has a PC and is sending messages to someone with a PC then why
>>use a cipher that could becasue of its ability to be run on many
>>machines would ecpoxe it to more attacks. Even if they algoritmically
>>had the same level security which can't be proved anyway.
>>
> Right, maybe. But the AES is not being chosen just to play with on
> a
>PC. It is intended to be used as a general-purpose standard, PC,
>software, hardware or whatever. It has to be strong, resistant to
>cryptanalysis, fast, have several block + key size features, and so on.
>
There are a lot of conflicting requiremesnts. For one make it
secure but make it fast. For my purposes secure is a much more
valuable requirement. The problem is you really can't measure security
becasue what is secure today is insecure tomorrow. Why does there
need to be cipher that runs easily on all machines. If it can run
on a common machine very easily and is "secure" why should one drop
it for one that works on all machines. I don't use one wrench for
all the times I need one. But I have to admit vice grips come close
90% of the time.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Dave Ashley <[EMAIL PROTECTED]>
Subject: Re: Adobe Acrobat -- How Secure?
Date: Thu, 28 Sep 2000 14:23:24 GMT
This is a very interesting discussion. It appears that if you put an
Acrobat document out there, the security features are meaningless. I
knew this already, but you've gone an extra step and said that even if
the Acrobat Reader program can't be cracked, the dedicated few might
use a screen snapshotting method. True, true, true.
FYI, there is a company in Oregon that sells software to law
enforcement to allow them to nearly instantly crack password-protected
Word and Excel files, pursuant to investigations and search warrants.
Lesson, if you're a drug dealer or a contract killer, do not keep your
records with just a Word or Excel password!
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> On Thu, 28 Sep 2000 13:25:45 +0800, Dido Sevilla <[EMAIL PROTECTED]>
> wrote, in part:
>
> >If someone's determined enough, all they
> >need to do is fire up a screen capture program, or to open a copy of
MS
> >Word or whatever, open your file reading program, share the screen
with
> >your file reader and Word, and just type whatever he or she sees on
the
> >file reader's window to the Word window. Nothing to it.
>
> Well, Acrobat certainly can't prevent typing, although it does have an
> option to disable cut and paste. However, IIRC, the .PDF file format
> is fully documented - including the keys - so it is possible to write
> a rogue version of Reader that ignores security.
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm
>
--
====================================
Dave Ashley, [EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Deadline for AES...
Date: Thu, 28 Sep 2000 16:31:04 +0200
Hi!
Did anyone notice the Announcement of the NISSC?
The program on monday has an entry "AES and Beyond" which starts
"The end of the AES development process is now in sight. The
algorithm has been selected, and the draft standard is ready
for public comment."
Does this mean that on oct, 16 latest, the waiting will be over
or are the guys from the NISSC just speculating?
Greetings!
Volker
--
The early bird gets the worm. If you want something else for
breakfast, get up later.
------------------------------
Date: Thu, 28 Sep 2000 10:34:28 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: I am only an egg...
Dido Sevilla wrote:
> David Rush wrote:
> >
> > So at the risk of opening the door to those wiser than I patenting
> > ideas I don't know how to develop (*yet*), I'm wondering what has been
> > done in the area of using the convolution operation (from signals
> > analysis) as an encryption transformation. It certainly would combine
> > every bit of the key with every bit of the plaintext. Of course,
> > convolution is also computationally expensive to perform, although
> > there are ways to work around/with that.
> >
>
> Interesting thought. However, if my DSP classes back in college have
> not gone the way of /dev/null in my brain, a convolution is essentially
> polynomial multiplication. For the convolution to be invertible by an
> inverse convolution (polynomial division), your signal (message) would
> have to become longer by the length of the kernel (key). Another
> problem is the frequency domain representation. In the frequency
> domain, a convolution is just a multiplication, so cryptanalysis may be
> much easier after performing a discrete Fourier transform, or its
> analogue (whatever that may be). I have no idea how the DFT-equivalent
> would be formulated if your signals are elements of a finite field, but
> my guess is it would involve choosing a set of orthogonal functions over
> the finite field in which your signal is expressed, as with any other
> integral transform. I can't imagine what these functions would look
> like in a finite field like, say, GF(2^8), but I'm not going to say that
> they don't exist (I wouldn't know).
There is also the possibility of using a curve other than cosine. Wavelet
research might produce ciphers in which the key is the curve used.
------------------------------
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
From: [EMAIL PROTECTED]
Subject: new Pegwit
Date: Thu, 28 Sep 2000 15:07:32 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
###
Hello
I made a new Pegwit version which uses secure curve
(old version used curve F2^255 was found insecure because 255 is not prime:
http://www.hpl.hp.com/news/ecc.html
http://www.hpl.hp.com./techreports/2000/HPL-2000-10.html )
If you are interested in pegwit I can send you new version for testing
(I don't want to put it now in the web, because I am not sure that I made
everything properly and there are no obvious flaws)
new:
+ all old ECC code replaced with Mike Rosing's ECC code
(http://www.manning.com/Rosing/ http://mendota.terracom.net/~eresrch/ )
+ uses one of curves recommended by NIST F2^233
(http://csrc.nist.gov/encryption/ )
+ Square replaced with Blowfish in CBC mode (160 bit for conventional encryption,
224 bit for public key encryption)
+ Public keys and signatures now use BASE64 encoding instead of HEX(BASE16) encoding
so public key now is only 40 character long an signature 80
+ added possibility to encrypt to multiple public keys (encrypt to self)
*-very slow
performance (sec)
PIII533 P120
key gen: 2 12
encrypt: 4 24
decrypt: 2 12
sign: 2 12
verify: 4 24
== <EOF> ==
Disastry http://i.am/disastry/
http://disastry.dhs.org/pgp <-- PGP plugins for Netscape and MDaemon
remove .NOSPAM.NET for email reply
### end pegwit v9 signed text
R8i2YRl+WMoI5mXUcJxHnOjRBBXU/LtRO3Fv9HAA
65fzD1rJbIcFRdsc+jajyt49+ukXJIvtY7snlnYA
=====BEGIN PGP SIGNATURE=====
Version: PGP 6.5.8
iQA/AwUBOdNBqjBaTVEuJQxkEQLYsACfWyvWODqpvI+k36I1nvqFFGhzmssAoJtH
1OQ9TY3OA8npTdqIkDcyHGAI
=xhbO
=====END PGP SIGNATURE=====
------------------------------
From: Derek Bell <[EMAIL PROTECTED]>
Subject: Re: Chaos theory
Date: 28 Sep 2000 16:36:31 +0100
Jim Gillogly <[EMAIL PROTECTED]> wrote:
: It can be worse than this: because chaotic systems have attractors,
: a close guess rather than a spot-on guess may yield islands of
: plaintext. Other guesses may get into other attractor orbits,
: allowing the plaintext to be stitched together from the different
: passes, all without ever finding the actual key or state. This of
: course depends on specific implementations of how one uses chaos,
: but it worked for one challenge posted to sci.crypt some years ago.
Similar problems plague chaotic PRNGs - they also have the problem that
the distribution may be quite different from what is desired.
Derek
--
Derek Bell [EMAIL PROTECTED] | Socrates would have loved
WWW: http://www.maths.tcd.ie/~dbell/index.html| usenet.
PGP: http://www.maths.tcd.ie/~dbell/key.asc | - [EMAIL PROTECTED]
------------------------------
From: Derek Bell <[EMAIL PROTECTED]>
Subject: Re: Chaos theory
Date: 28 Sep 2000 16:41:54 +0100
Tim Tyler <[EMAIL PROTECTED]> wrote:
: Chaos, by definition means "sensitive dependence on initial conditions".
When I did a course in nonlinear dynamics, nearly ten years ago,
it was stated that a consensus on exactly what properties a chaotic system
had to have wasn't reached yet.
Derek
--
Derek Bell [EMAIL PROTECTED] | Socrates would have loved
WWW: http://www.maths.tcd.ie/~dbell/index.html| usenet.
PGP: http://www.maths.tcd.ie/~dbell/key.asc | - [EMAIL PROTECTED]
------------------------------
From: "Joyce" <[EMAIL PROTECTED]>
Subject: How to get Certificate content after HTTPS Authentication
Date: Fri, 29 Sep 2000 00:36:08 +0800
Dear all,
Would you tell me how to get Client Certificate content (eg. Signature
Algorithm, Issuer information, Subject information, Public key and etc)
after HTTPS Client Authentication is successful ?
My program is run under
Environment: apache + openSSL + tomcat
Platform: NT
Thanks a lot.
Best Regards,
Joyce
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Cipher Illiteracy
Date: Thu, 28 Sep 2000 11:24:57 -0500
[EMAIL PROTECTED] wrote:
> Thank you all for your Reply's there greatly appreciated.
> Is there a Cipher group for moron's hehe cuz i don't wanna
> bother you guy's with my measly questions
Nothing wrong with asking questions! Best thing to do is to
read up on stuff, then ask specific questions about something
that doesn't make sense to you. There'll be somebody here
who can explain it. You'll learn faster that way and find
that most people won't mind helping you out too.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: RSA and Chinese Reminder Theorem
Date: Thu, 28 Sep 2000 17:13:43 GMT
In article <[EMAIL PROTECTED]>,
Soeren Gammelmark <[EMAIL PROTECTED]> wrote:
> Hi
>
> I know that you can use the CRT to solve a system of equations: x mod
> p(i) =3D a(i) where p(i) is prime.
A minor nit. System of congruences. Not "system of equations".
>I've been trying to realise how this
> can be combined with the RSA-decryption equation.
Decryption computes (ciphertext)^e mod N.
So simply compute (ciphertext)^e mod p and (ciphertext)^e mod q,
then use the CRT to compute (ciphertext)^e mod pq.
>So far I havent been
> able to see how to form these two equations from the RSA decryption
> equation.
Congruences. Not equations.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Notice: Problems with DiehardC.
Date: Thu, 28 Sep 2000 10:26:43 -0700
Mok-Kong Shen <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Paul Pires wrote:
> >
> > I believe I have detected a problem with DiehardC v1.03
> > and menu item #8 (31x31 and 32x32 binary matrix tests).
>
> I recommend that you ask the author of DiehardC (not Diehard).
> He will certainly be friendly engough to help you.
Yes, Scott is both freindly and helpfull.
Paul
>
> M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Marc)
Subject: Chaining for authentication
Date: 28 Sep 2000 17:30:27 GMT
Hi..
My current project involves handling of small variable sized messages
(10-100 bytes in length) that are meant to be unreadable and unmodifyable
for outsiders. There will be a great number of messages protected
by the same key, and expectedly even with near-identical contents.
The algorithm to be used is a generic 64bit block cipher. It is
considered secure.
The protected message may be longer than the plaintext, but should not
exceed the size by much (ie less than the block size of 8 bytes would be
preferable).
After reading "Applied Cryptography" I am not sure how to apply the
block cipher to accomplish my goals. I see that chaining is of
advantage, because the messages will be near-identical. I can put
the non-identical parts of a message to its head, and thereby achive
different (chained) ciphertext for each message.
But how can I authenticate the contents of the message, preferably
in the same pass? My plans are to encrypt like this:
1. only on first call: chain = known_value;
2. crypt = blockcipher_function( data_input ^ chain );
3. chain ^= crypt;
4. chain += data_input;
5. return crypt as output
This appears (to me) to carry on any ciphertext modification in
the chain register, without automatic re-syncronization.
Also, attacking single bits in a plaintext-block n by modifying the
same bits in ciphertext-block n-1 seems to be impossible because
the (then destroyed) plaintext n-1 also influences the chain
register (on contrast to normal CBC mode).
In step 4 I intentionally avoid XOR (and prefer ADD) because during
decryption a datablock is recovered with XOR chain, and later XOR-
modifying chain with the result would cancel away the influence
of plaintext-blocks n-2 and older. At least that's what I think,
am I right here?
To achive the goal of unmodifyable messages I plan to add a fixed
constant to the message, probably 4 bytes (smaller than 1 block).
I plan to use ciphertext stealing to avoid further bloating of the
message size, and expect that after decrypting the 4 byte fixed
and known constant is OK when the message has not been tampered with,
or BROKEN when "any imaginable" modification has been done.
Am I on the right way, or do you see obvious traps?
------------------------------
From: "Kevin Crosbie" <[EMAIL PROTECTED]>
Subject: Re: Non-Repudiation mechanism
Date: 28 Sep 2000 17:52:18 GMT
Layal,
Comments below:
"Lyalc" <[EMAIL PROTECTED]> wrote in message
news:rpyA5.7514$[EMAIL PROTECTED]...
> Sigh...
>
> What happens when a valid user gets 2 or more valid certificates (as per
the
> bogus cert attack described)?
Well the user can only have one valid cert registered in my database, they
can't apply for a second as long as there is one in existence in the
database. If they manage to get a second using an insider's help, it won't
match the PKCS#7 signer certificate, and I can say that foul play has
occured. I'm not sure of the legal aspects of this.
>
> Smartcards need a 'secure' reader that incorporates a keypad or biometric
> entry device, especially if you want to move beyond an expensive
duplication
> of a password mechanism towards something that has some amount of legal
> validity.
What are the current legal guidelines regarding this form of security at
present (password/browser cert/Smartcard)?
>From my perspective, you can only do so much. If a smartcard password were
duplicated or stolen, I don't think that is my liability, but the liability
of the user... proving that is another question though.
My Company works through browsers on the web. It is a contract processing
system. A smartcard must me installed into the browser as a PKCS#11
device. It is up to the user or their company to ensure that this is a
secure system, otherwise, I don't see why I should take liability. The
choice of the authentication mechanism is not something I have too much
control over, but if a company wishes to have Non-Repudiation strengthened,
let's say for expensive transactions(the company will want this as much as
us) they will be responsible for their smartcards.
>
> How does the RA know this will be a valid cert request?
> Simply by duplicating all the validation mechanism at another location.
It doesn't. But the cert returned by the RA has to go into my system and
saved to the database to be of any use, as it is a method for verifying the
PKCS#7 signed data of a non-repudiable signature.
>
> More procedures, more systems/services holding duplicate info 9or with
> access to a master copy.
> The management hassles of the above aren't worth it unless you're a
> government dept which can bury losses for decades.
The database need only be on one or two machines. The relevant fields
shall be encrypted using a HSM, and access to the HSM for
developers(insiders) is restricted to smartcard usage. For the system to
use the HSM, on bootup, three or more smartcards must be present to load the
system, ensuring that more than one insider is necessary.
>
> Lyal
Thanks for the feedback Lyal. I'm not sure if my counterarguments are
convincing, so tell me what you think.
Cheers,
Kevin
>
> Kevin Crosbie wrote in message <8qu32m$[EMAIL PROTECTED]>...
> >Hi all,
> >
> >I have been searching for a solution for performing cross-platform
> >non-repudiation for web-sites.
> >I have not been in the security field for long enough to know if this
> >solution is good enough, or if it has major flaws, so I decided to put it
> >into the public domain for feedback. This solution is similar to that
> >given by Baltimore's FormSecure signed applet system.
> >
> >The System works as follows:
> >
> >We have a Client Browser, a Web-Server, and a Certificatation
> >Authority/Registration Authority.
> >
> >First of all, to use the Service I provide, the user must authenticate by
> >either a username/password, Browser Cert or Smartcard.
> >
> >When the client goes to a certain page, they are requested to download a
> >signed-persistent applet. The applet on first load will generate an RSA
> >KeyPair, and a Certificate request. The Private key is stored, and the
> >Cert Request is posted to a servlet on the web-browser. The servlet
will
> >check the request, and send it to an RA, which will automatically send
this
> >on to the CA, who will sign the cert, return it to the RA, who will in
turn
> >return it to the servlet.(Is this structure in place anywhere, I think
> >Unicert does this automatic process.)
> >
> >Point: The cert doesn't tie to the user, as it was an automatic process,
> >using an ARM, or worse, nothing, the only thing I have is that the user
> >authenticated using their authentication mechanism, and that I can see
the
> >generated cert at a time that they were authenticated.
> >
> >On receipt of the CA signed cert, the servlet will save the
cert(encrypted)
> >to a database, and return it to the applet (anybody know how long it
takes
> >for the cert registration process to complete?) The applet will then
save
> >this to a disk(password protected in a PFX file in the JVM
> >System.getProperty(" user.home") directory)
> >
> >When a signature for non-repudiation takes place, the applet is called to
> >sign a piece of data, prompt the user for their password, and return a
> piece
> >of PKCS#7 data containing the signed data object, which is sent to the
> >servlet, timestamped and stored in the users account for arbitration in
the
> >case of a dispute. Before the signature is stored, it is validated
> against
> >a CRL on the CA, and with the signing cert stored in the database, to
make
> >sure it is still the cert first applied for, otherwise it is rejected.
> >
> >That is the system. I can see one obvious point of attack:
> >
> >Someone inside my company could apply for a new certificate using the
same
> >automatic process, encrypt it, and store it, give the cert components
> >including the private exponent to the user. The user will authorize a
> >transaction which is supposed to be non-repudiable, and this validates
ok,
> >and the signed data get's stored.
> >The insider replaces the origional encrypted cert. A dispute takes
place
> >and we see, hey the signature certificate doesn't match that in the
PKCS#7
> >object. Non-Repudiation fails.
> >
> >Notes:
> >The user must authenticate with the authentication mechanism, thus,
unless
> >this is also replaced, and a bogus user created, we can show that the
user
> >had a part in this, or that their authentication mechanism was stolen by
a
> >malicious party.
> >
> >When a signature doesn't match in the arbitration process, we can tell
> >straight off that the system was tampered with.
> >
> >Points:
> >1. Without smartcards being used exclusively, the is no way to say for
sure
> >that the person is who they say they are.
> >2. We can make this system as secure as we can from an insider attack by
> >requiring smartcards to use database encryption/decryption functions
which
> >are done through a Hardware Security Module.
> >3. The way that we are using the certs, a trail is left in the case of
> >tampering, showing us that the user was wither negligent, or fraudulent,
> >posing the question, would we be expected to take liability in the case
of
> >negligence or fraudulence?
> >
> >That is basically all I can say about the system. Please review this
and
> >give me feedback. It is a solution, but I'm not sure if it is the best
> >solution.
> >
> >Best Regards,
> >
> >Kevin
> >
> >
>
>
------------------------------
** 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
******************************
