Cryptography-Digest Digest #941
Cryptography-Digest Digest #941, Volume #13 Mon, 19 Mar 01 13:13:01 EST
Contents:
Re: Q: ANSI X9.68 certificate format standard (Anne Lynn Wheeler)
Re: How to eliminate redondancy? (SCOTT19U.ZIP_GUY)
Re: Are prime numbers illegal ? (SCOTT19U.ZIP_GUY)
Re: SSL secured servers and TEMPEST (Mark Currie)
Re: How to eliminate redondancy? (SCOTT19U.ZIP_GUY)
Re: [OT] Why Nazis are evil (SCOTT19U.ZIP_GUY)
Re: How to eliminate redondancy? (SCOTT19U.ZIP_GUY)
Re: IP ("Henrick Hellström")
AES encryption speed vs decryption speed ("Thierry Falissard")
Re: NTRU, continued... ("Dr. Yongge Wang")
My cypher system ("bookburn")
Re: Is SHA-1 Broken? (David Wagner)
Re: Is SHA-1 Broken? (David Wagner)
Subject: Re: Q: ANSI X9.68 certificate format standard
Reply-To: Anne Lynn Wheeler [EMAIL PROTECTED]
From: Anne Lynn Wheeler [EMAIL PROTECTED]
Date: Mon, 19 Mar 2001 15:54:22 GMT
Tomás Perlines Hormann [EMAIL PROTECTED] writes:
I was wondering whether someone of you have a clue where to get the
draft (or already standard) from ANSI X9.68 certificate format as I have
been searching through ANSI webpages and some other sites and just found
a draft dated from march 1st, 1999.
I guess there must be a recently updated draft versionor even the full
standard.
Does anybody know anything about the current state of this certificate
format for mobile applications?
I would be very satisfied if you could pelase help me out regarding this
issue.
x9.68 work on compressed/compact certificates for account-based
financial transactions addresses a situation that would frequently be
associated with relying-party-only certificates. The X9.59 work
demonstrates that X9.68 techniques for relying-party-only certificates
can compress all redundant fields located in the certificate (and at
the relying-party) to zero resulting in a X9.68 certificate of zero
bytes ...
... or since the relying party built and kept the original certificate
at publickey registration time and transmitted a copy of the
certificate to the public key owner; to then have the publickey owner
return a copy of the original certificate appended to every
transaction sent to the relying-party ... when the relying party has
the original certificate is redundant and superfulous.
the nominal objective of x9.68 compatc/compressed certificate was to
operate in a highly optimized account-based financial transaction
environment that typically might involve existing transaction sizes of
80 bytes or less. The addition to such transactions of both a digital
signature and a 4k-12k byte publickey certificate would represent
significant bloat in the size of the financial transactions
random refs:
http://www.garlic.com/~lynn/aadsm5.htm#x959
http://www.garlic.com/~lynn/2001c.html#72
http://www.x9.org/
from old x9.68 draft introduction (ISO 15782-1 is the work of ISO
TC68/SC2 international financial standards body):
This standard defines syntax for a more compact certificate than that
defined in ISO 15782-1 and X.509. This syntax is appropriate for use
in environments with constraints imposed by mobility and/or limited
bandwidth (e.g., wireless communications with personal digital
assistants), high volumes of transactions (e.g., Internet commerce),
or limited storage capacity (e.g., smart cards). This syntax is also
geared towards use in account-based systems.
--
Anne Lynn Wheeler | [EMAIL PROTECTED] - http://www.garlic.com/~lynn/
--
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: How to eliminate redondancy?
Date: 19 Mar 2001 15:29:17 GMT
[EMAIL PROTECTED] (Benjamin Goldberg) wrote in
[EMAIL PROTECTED]:
Actaully most Lossless compressors that are not bijective
A compressor which is lossless is bijective.
Actually for encryption purposes we should be compressing
to the set of message which can be encrypted. The problem
is that when you start the decryption process and use a different
key than what the encryptor used you get a file that will not
compress properly. Since it does decompress correctly you don't
have a BIJECTION from your message set to the set of files
the encryptor is working with. Most lossless compressor fail
this,
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: Are prime numbers
Cryptography-Digest Digest #941
Cryptography-Digest Digest #941, Volume #12 Tue, 17 Oct 00 01:13:00 EDT
Contents:
Re: MS's fast modular exponentiation claims II (David A Molnar)
Re: Pegwit group started to make a alternative to PGP based on ECC (Paul Rubin)
Counting one bits is used how? (Peter van der Linden)
Re: DNA encoding (Tom St Denis)
Simple Intro Encryption Info Wanted (Chris Frost)
Re: Pegwit group started to make a alternative to PGP based on ECC (Frank M. Siegert)
Re: Basic skills and equipment... (Scott Craver)
Re: Pegwit group started to make a alternative to PGP based on ECC (Paul Rubin)
Re: Basic skills and equipment... (Scott Craver)
Re: Basic skills and equipment... (Paul Rubin)
Re: Algorithm Performance (David A Molnar)
Re: DNA encoding ([EMAIL PROTECTED])
Re: Pegwit group started to make a alternative to PGP based on ECC ("Benny Nissen")
Re: SDMI - Answers to Major Questions (David A Molnar)
Re: Pegwit group started to make a alternative to PGP based on ECC ("Benny Nissen")
Re: DNA encoding ("John A. Malley")
Re: Counting one bits is used how? (David Wagner)
Re: Pegwit group started to make a alternative to PGP based on ECC (Paul Rubin)
From: David A Molnar [EMAIL PROTECTED]
Subject: Re: MS's fast modular exponentiation claims II
Date: 17 Oct 2000 02:29:40 GMT
Jim Gillogly [EMAIL PROTECTED] wrote:
JCA wrote:
I asked a few days ago a question about some claims the MS made (at
Crypto '95,
I believe) to the effect that they possess an algorithm that outperforms
Montgomery's
techniques when doing modular exponentiation. Much to my surprise, given
the high
caliber of some of the regulars in this group, nobody has said anything
yet.
I don't see anything in the Crypto '95 table of contents that looks like
what you describe. Do you have an author or title? Perhaps there would
be more comment if there were enough information to identify the claim you
reference.
The original post mentioned that this was a presentation at the rump
session, so it's unlikely that the table of contents would reveal it.
The question arises because it seems that MS decided to not to publish the
algorithm in the next series of conferences. So it's a "where is it now?"
kind of question.
I *do* vaguely remember hearing about this algorithm in 1996 or so, but
can add nothing more than that. Sorry.
-David
--
From: Paul Rubin [EMAIL PROTECTED]
Subject: Re: Pegwit group started to make a alternative to PGP based on ECC
Date: 16 Oct 2000 19:40:47 -0700
"Benny Nissen" [EMAIL PROTECTED] writes:
Pegwit is a program for performing public key encryption and authentication
using an elliptic curve. Pegwit is a simple Open Source alternative to PGP
Is there a web page somewhere about pegwit's goals? There's already
a perfectly good free PGP-compatible crypto program, www.gnupg.org.
--
From: [EMAIL PROTECTED] (Peter van der Linden)
Subject: Counting one bits is used how?
Date: 17 Oct 2000 02:46:12 GMT
How does counting the number of 1 bits in a word
relate to crypto?
Just curious about why this seemingly recondite instruction
pops up in various instruction sets. How is it useful?
--
From: Tom St Denis [EMAIL PROTECTED]
Subject: Re: DNA encoding
Date: Tue, 17 Oct 2000 02:37:29 GMT
In article KkOG5.111791$[EMAIL PROTECTED],
"binary digit" [EMAIL PROTECTED] wrote:
Hey, if any of you heard last year the winner of the inetl science
research
contest took a message and encoded it in DNA. When I first heard
this I was
skeptical on how she did this task. I searched around to see if
theer was
any explanatyion on how she did it and i found a video of her at the
rewards
explaining how it worked. She said she took a group of acids and
made them
reprtesent a letter of the alphabet. for ie 'ccc' = x and so on. I
also
read that she claimed her encryption to be 'unbreakable', which i
giggled at
cause if thats the way she actually did her project, how did she win
the
intel contest and how could she even claim that was unbreakable. Can
anyone
verify any of this, on how she actually encoded a message 'into' dna?
Like always the facts are all fudged up.
She "encoded" a message in DNA not "encrypted" and "unbreakable" is not
an issue considering it's not cryptography.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Chris Frost [EMAIL PROTECTED]
Subject: Simple Intro Encryption Info Wanted
Date: Tue, 17 Oct 2000 03:29:56 -
I've read some about computer-targeted methods of encryption, but have only
really dabbeled. I'd like to start learning more, starting with more
human-targetted methods and see what is like. Anyway, to spur my interests
a friend gave me these t
Cryptography-Digest Digest #941
Cryptography-Digest Digest #941, Volume #11 Sun, 4 Jun 00 22:13:01 EDT
Contents:
Re: Could RC4 used to generate S-Boxes? (tomstd)
Rectification (Ake Tyvi)
Re: AES times on the Alpha 21164 with Parallel encryption (Kenneth Almquist)
Re: Could RC4 used to generate S-Boxes? ([EMAIL PROTECTED])
Re: Could RC4 used to generate S-Boxes? (tomstd)
Re: Could RC4 used to generate S-Boxes? ("Scott Fluhrer")
Donald Davies has died ([EMAIL PROTECTED])
Re: Improving DES based MAC ("Scott Fluhrer")
Improved Tiny Crypto Lib (tomstd)
Re: Observer 4/6/2000: "Your privacy ends here" (Charles Bryant)
Re: RSA Algorithm ("Joseph Ashwood")
Re: RSA Algorithm (tomstd)
Re: RSA Algorithm (S. T. L.)
Re: RIP Bill 3rd Reading in Parliament TODAY 8th May (Dave Howe)
Re: Concerning UK publishes "impossible" decryption law (Dave Howe)
Re: RSA Algorithm ("Joseph Ashwood")
Re: AES times on the Alpha 21164 with Parallel encryption (Helger Lipmaa)
Subject: Re: Could RC4 used to generate S-Boxes?
From: tomstd [EMAIL PROTECTED]
Date: Sun, 04 Jun 2000 15:07:05 -0700
In article 8hej6v$[EMAIL PROTECTED],
[EMAIL PROTECTED] (Guy Macon) wrote:
tomstd wrote:
In article 8hdt3k$apl$[EMAIL PROTECTED], Simon Johnson
[EMAIL PROTECTED] wrote:
I've read somewhere that RC4 is secure against both diff lin
cryptanalyis. I figure this secuirty must be derived from its
s-
box. My
real question is, is the secrecy of the s-box that makes it
secure or
does the algorithm generate diff lin optimized s-boxes?
Chances are you have a bit of reading todo on sbox
construction.
The reason RC4 is secure is that it's hard to model the
internal
state based on output only. Some 'weak keys' have been
identified which leak more information about the state.
The sboxes RC4 makes are by no means secure on their own (i.e
in
a feistel cipher), and don't always have optimial cryptographic
properties (SAC, BIC, non-linear, bijective, low xor-pairs).
Tom
Sorry for being a bother, but I am a clueless newbie who has a
special interest in RC4 (the ciphersaber implementation, really)
and the above went over my head. Could someone explain the
above
in simple terms?
Sure no prob. RC4 is a STREAM CIPHER, not a sbox generator.
The only reason RC4 is secure is that it's hard to model the
internal state (i.e the table) from only the output.
RC4 does not always make secure sboxes for block ciphers or
other components. In a block cipher generally you use the same
sbox over and over (without any change) so it has to have some
ideal cryptographic properties. Such as being non-linear (avoid
the output and keybits being expressed by one boolean expression
with a higher probability), or low input-output xor pairs to
avoid differential cryptanalysis (all pairs are equally low
probable), or satisfy SAC which states "If bit j of the input
changes bit i of the output will change with prob 1/2", or BIC
which states "bit j and i (j != i) of the output are not
linearly dependant". RC4 is not designed to make 8x8 boxes that
fulfill these requirements.
Asides from that RC4 is not a super prng anyways, it's better
then nothing but that's about it.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
--
Date: Mon, 05 Jun 2000 01:09:42 +0300
From: Ake Tyvi [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Crossposted-To: alt.discuss.computers,comp.security.misc
Subject: Rectification
Dear Sirs,
Yes Sir, the place is actually called Institute of Information Technology,
even it should be called Institute of Information Science, since
universities do not give damn about these things at Finland.
Yes Sir, the letter in only memorandum with typing mistakes.
Thank You.
Mr Åke Tyvi
--
From: [EMAIL PROTECTED] (Kenneth Almquist)
Subject: Re: AES times on the Alpha 21164 with Parallel encryption
Date: Sun, 04 Jun 2000 22:20:18 GMT
[EMAIL PROTECTED] (Jonathan Thornburg) wrote:
Why compare times on obselete chips? [...]
A comparison using reasonably contemporary chips would be much more
interesting, i.e. any of Pentium III, AMD K7, Alpha 21264 EV67, and
their kin. Unlike the 21164, these chips are all heavily out-of-order,
so their relative performance might be quite different.
Unfortunately, any chip available today will be obsolete during most
of the lifetime of the AES. I would have used the Alpha 21264 EV67
or the Intel Itanium as the basis for comparison if I had had access
to information concerning these chips when I started this project. The
Pentium III and AMD K7 processors are designed to be backward compatable
with a chip designed twenty years ago, so I do not consider them to be
particularly good representatives of the c
Cryptography-Digest Digest #941
Cryptography-Digest Digest #941, Volume #9 Tue, 27 Jul 99 01:13:04 EDT
Contents:
Location of Crypto (Ryan Phillips)
Re: Advances in Cryptology 1981--1997 (CryptoBook)
Re: Novice question ..
Re: Location of Crypto ([EMAIL PROTECTED])
OK. Maybe I am missing something here. (Shktr00p1)
Re: OK. Maybe I am missing something here. (Shktr00p1)
Re: OTP export controlled? ("Douglas A. Gwyn")
Re: another news article on Kryptos ("Douglas A. Gwyn")
Re: How Big is a Byte? ("Douglas A. Gwyn")
Re: OK. Maybe I am missing something here. ([EMAIL PROTECTED])
Re: Kryptos morse code ("Douglas A. Gwyn")
Re: another news article on Kryptos ("Douglas A. Gwyn")
Re: OK. Maybe I am missing something here. (John Savard)
Re: OTP export controlled? ([EMAIL PROTECTED])
to the group, trust me, this does have to do with cryptography in the long run
("Jeffery Nelson")
Re: Location of Crypto (Jerry Coffin)
Re: Location of Crypto (fungus)
Re: Location of Crypto (fungus)
Re: Location of Crypto (Shktr00p1)
Date: Mon, 26 Jul 1999 15:53:49 -0700
From: Ryan Phillips [EMAIL PROTECTED]
Subject: Location of Crypto
I was wondering if it was illegal in the United States to tell someone
(on a newsgroup or in any other means) the location (ie. ftp site, web
site, etc) or give addresses to sourcecode and/or strong-crypto
executables to foreign-nationals outside the United States?
I'm assuming this newsgroup is reachable from anywhere in the world and
I see people giving addresses out, is there a problem with this
practice?
Thanks for the Help
-Ryan Phillips-
--
From: [EMAIL PROTECTED] (CryptoBook)
Subject: Re: Advances in Cryptology 1981--1997
Date: 27 Jul 1999 00:20:32 GMT
Sorry for the typo. The correct period is: 1981 -- 1997.
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Francois Grieu) writes:
ADVANCES IN CRYPTOLOGY 1981-- 1997: Electronic Proceedings and Index
of the CRYPTO and EUROCRYPT Conferences 1981 -- 1987
Is it 1981 -- 1997 or 1981 -- 1987 ?
Sounds like a must, anyway.
Francois Grieu
--
From: [EMAIL PROTECTED] ()
Subject: Re: Novice question ..
Date: 27 Jul 99 00:16:19 GMT
Neil ([EMAIL PROTECTED]) wrote:
: I am just curious...
: If one took a fairly long message, say 200-300 words, and enciphered
: it wwith playfair and THEN used a second encipherment with a good
: transposition cipher ... wouldn't that be very tough to break??
: Even with multiple messages, using different keys would still make it
: pretty tough, wouln't it?
If you had a *lot* of multiple messages with the same key, it probably
would be possible to begin work on cracking it.
Some simpler ciphers using that principle have been broken: the ADFG(V)X
cipher is the closest parallel.
But if you use a different key for each message, how do you arrange that?
Do you include, along with the message, the different part of the key? If
so, the quality of the scheme you use so that the overall key prevents the
part that comes with the message from revealing anything is very
important.
John Savard
--
From: [EMAIL PROTECTED]
Subject: Re: Location of Crypto
Date: Mon, 26 Jul 1999 21:11:35 -0400
I was wondering if it was illegal in the United States to tell someone
(on a newsgroup or in any other means) the location (ie. ftp site, web
site, etc) or give addresses to sourcecode and/or strong-crypto
executables to foreign-nationals outside the United States?
No, links to source code/executables are just fine as long as they are not
on an american server. In fact I have found some very good source code
posted on this newsgroup.
--
From: [EMAIL PROTECTED] (Shktr00p1)
Subject: OK. Maybe I am missing something here.
Date: 27 Jul 1999 01:42:47 GMT
Ok Experts,
I've been reading all kinds of post on this group about encryption schemes, and
still I am confused. Is there something that the computer leaves behind to
make it easy to crack. I mean I know you can undelete something (There's ways
around this)but more specifically, when you change one byte value to another
byte value, it's different in binary? How do you come back to the original
through cracking unless you use a small key?
Here's what I use. I'm new to encryption software so tell me whats wrong with
this. Maybe I'm just totaly clueless! (I wouldn't doubt it.)
Take the ascii values of two characters one is from the file and one from the
key.
FILE: d (100) KEY: F (70) File+Key= ¬(170)
You write ascii char 170 to the file as the encrypted byte.
Now you use a file containing 1000 random bytes and use that as the key. I
know "One-Time-Pad". Each file is encrypted with a password(8 bytes) as well.
The password is used to encrypt the key file, then th
