Cryptography-Digest Digest #976, Volume #9 Tue, 3 Aug 99 05:13:04 EDT
Contents:
Re: Algorithm/Code for Public Key Encryption? (Nick Roosevelt)
Re: Cryptanalysis of R250
pkcs#7 help! ([EMAIL PROTECTED])
Re: bits and bytes (Jerry Coffin)
Re: Bad Test of Steve Reid's SHA1 (Jerry Coffin)
Blowfish x86 assembler ("Kasper Pedersen")
Re: Warning! The eclipse approaches... {5.6b}
(Airbrush4u)
Re: PC Encrypt (JPeschel)
Re: A most useful cipher (wtshaw)
Re: Pencil-and-paper compression algorithms [Re: Between Silk and Cyanide] (wtshaw)
Re: Americans abroad/Encryption rules? (wtshaw)
Re: PC Encrypt ("Radoslav P�r")
----------------------------------------------------------------------------
From: Nick Roosevelt <[EMAIL PROTECTED]>
Subject: Re: Algorithm/Code for Public Key Encryption?
Date: Tue, 03 Aug 1999 04:53:06 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Keith Reeves) wrote:
> On Sat, 24 Jul 1999 23:37:47 GMT, Nick Roosevelt <[EMAIL PROTECTED]>
> wrote:
>
> >I am hoping to be able to implement encryption for a feature on a web
> >site. It involves encrypting some data. I would like to use a
double
> >key/public key encryption algorithm. I am unable to use a component.
>
> I'm not sure what you mean by component - if you're talking about an
> exponent, you can pretty much forget about using RSA, which is the
> primary technique for public-key encryption. However, I don't see a
> reason why you can't get your hands on a modular exponentiation
> algorithm which will do the job on any decent PC.
By component I meant a COM component or DLL.
>
> Anyhow, if you're thinking of using encryption on the web, the
> standard is SSL, if I'm not mistaken. Try to find some documentation
> on the subject, if you want to be compatible with the rest of the
> world.
SSL is for encryption between the browser and the server. I am looking
for encryption to encrypt data in my database. I am using SSL.
>
>
--
Nick Roosevelt
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Cryptanalysis of R250
Date: 3 Aug 99 05:38:24 GMT
[EMAIL PROTECTED] wrote:
: The overwhelming majority of characters in plain ASCII text are lowercase
: alphabetic characters. For these characters, the first three bits in the
: byte are constant: (010). Thus, because there will be many cases where the
Of course, that should have been 011.
000 - control characters
001 - spaces, digits, and most punctuation
010 - capital letters
011 - small letters
John Savard
------------------------------
From: [EMAIL PROTECTED]
Subject: pkcs#7 help!
Date: Tue, 03 Aug 1999 06:03:02 GMT
Hi,
I want to create a pkcs#7 file which can be imported to
Internet Explorer.Below is what I have done(on openssl-0.9.3):
rfp=fopen("root.pem","r");
X509 * x509=PEM_read_X509(rfp,NULL,NULL);
PKCS7 * p7=PKCS7_new();
PKCS7_set_type(p7,NID_pkcs7_signed);
EVP_PKEY * pkey=EVP_PKEY_new();
PKCS7_SIGNER_INFO *si=PKCS7_add_signature(p7,x509,pkey,EVP_sha1());
PKCS7_add_certificate(p7,x509);
PKCS7_set_detached(p7,1);
PKCS7_content_new(p7,NID_pkcs7_data);
si=PKCS7_SIGNER_INFO_new();
X509_ALGOR *mdalgor=X509_ALGOR_new(); /* add md_algs of signed data */
mdalgor->algorithm=OBJ_nid2obj(NID_md5);
mdalgor->parameter=NULL;
sk_push(p7->d.sign->md_algs,(char *)mdalgor);
X509_ALGOR *dealgor=X509_ALGOR_new();
dealgor->algorithm=OBJ_nid2obj(NID_rsaEncryption); /* add
digest_enc_alg */
dealgor->parameter=NULL;
si->digest_enc_alg=dealgor;
wfp=fopen("root.p7b","w+");
i2d_PKCS7_fp(wfp,p7);
When I use IE to import root.p7b ,it says "not know the file type".
To import .p7b successfully,what should I do?
And where can I find detailed documents or examples about pkcs#7.I have
read rfc2315 and .c under openssl-0.9.3/crypto/pkcs7,but I still
have many problems(maybe they are simple and trival to you) such as
what's the meaning of asn1,lenth,state in struct pkcs7?
Thanks in advance.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: bits and bytes
Date: Tue, 3 Aug 1999 00:08:54 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> > I would like to insist on that point: the range is -127..127, not
> > -128..127. This is for computers that store signed types with a sign
> > bit and the absolute value; this was the case for the PDP-11 (I think,
> > correct me if I am wrong). This is rare nowadays since it makes addition
> > and substraction a bit more complicated, and it also means that there is
> > a 'negative 0' that is not equal to 0 in memory.
>
> The name for this arithmetic ones-complement as opposed to the alternate
> twos-complement arithmetic (TCA). PDP-8, PDP-11, LSI-11, DECsystem 10 & 20,
> and VAXen all use TCA
Not quite. He mentioned "sign bit and absolute value" -- this is
generally referred to as sign-magnitude representation. There's also
one's complement representation and (of course) twos complement
representation. While both sign-magnitude and one's complement have
negative zero, they have different representations for negative
numbers. For example:
decimal 2's 1's sign-mag
-0 - 11111111 10000000
-1 11111111 11111110 10000001
-2 11111110 11111101 10000010
In a few situations, it's also common to use what's referred to as a
bias representation -- in this you simply use unsigned numbers to
represent the value, but you have to subtract something from the
unsigned number to get the real value. This is rather common as a
representation for the exponent in a floating point number. E.g. in
this, a 0 might represent -127, 127 represents 0, and 255 represents
128. This representation is also handy if you need to represent
substantially different ranges of positive and negative numbers. E.g.
a bank might allow you to deposit lots of money in a checking account,
but will bounce your checks rather than allow the balance to become
negative by more than a small amount.
> > What ANSI says (according to K&R and other sources) is that the integer
> > types may represent any number in the following ranges:
> >
> > char 0 127
Sort of correct -- I.e. a char certainly must be able to represent
this range, but on any given implementation it must also be able
represent more than that -- it has to include either -127 to 0 or else
128 to 255 in addition to the range you've given.
> > -- A char is either a signed char or an unsigned char, not a third and
> > different type. Usually, a char is signed, but on some platforms (the
> > MacIntosh for instance) the char is unsigned (by tradition). If you want
> > a signed char, say it explicitely.
Actually, a char is always a third type that happens to have the same
range as either signed char or unsigned char. This is of little
consequence in C, but makes a real difference in C++ -- for example,
you can legally overload a function on all three types. Some C++
compilers don't implement this properly, but that's a compiler bug,
not part of the language.
> Bit fields are in no way portable, and they are absolutely not
> interoperable.. They are one of the first features to avoid when writing
> multi-platform software.
Only sort of true -- if you want to take some external data and read
it into a bitfield, you're absolutely correct. OTOH, if you want to
have math wrap around at, say, 11 bits, it's portable to use an
unsigned bitfield to force it to happen. Some compilers may have bugs
in the area and many will produce terrible code, but the code _should_
give dependable results.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: Bad Test of Steve Reid's SHA1
Date: Tue, 3 Aug 1999 00:08:50 -0600
In article <7nste6$ss7$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> So far no-one has told me what LITTLE_ENDIAN does. Does it refer to
> one of the alternate methods referred to as 7. and 8. on the NTIS site
> (thanks to Jerry Coffin for that URL)? I would assume not since, as D.
> L. Keever mentions, you do need to define LITTLE_ENDIAN to get the
> right digest. Or does it refer to the "technical correction" that
> generated SHA-1 (FIPS 180) in the first place? Something else? Just
> curious.
SHA-1 works with 32-bit quantities. On the NTIS site, they assume
that if you start with bytes like:
00 01 02 03
and treat them as a single 32-bit quantity, they should end up as:
00010203
I.e. the first byte becomes the mistyping of the four, and the fourth
byte ends up as a the least significant. This is what's generally
referred to as big-endian ordering. By contrast, on a little-endian
machine, the first byte will end up as the least-significant byte of
the whole, and the fourth will end up as the most significant. I.e.
if you take the string above and simply cast a pointer to its
beginning as a pointer to long, you'll end up with 03020100 as your
number. Therefore, on a little-endian machine, you have to take the
inputs and swap them around to produce the right number.
------------------------------
From: "Kasper Pedersen" <[EMAIL PROTECTED]>
Subject: Blowfish x86 assembler
Date: Mon, 2 Aug 1999 22:40:55 +0200
I got hold of the Blowfish implementation from Eric Young's SSL
implementation (pointed to as reference by counterpane), and found it a
little slow on Celeron/P-2/P-3/K6-2.
On counterpane.com it is listed as being able to do encryptions at 18
clocks/byte. This is 144 clocks pr. 16 rounds /9 clocks per round. Now, on
the K6-2 the asm code from 'SSLey' required 16 clocks, and on the P-3 24 (!)
clocks.
After K6 optimization and pure chance on the P-x, I have got it down to 11
on K6-2 and 12 on P-3.
(The P2/P-3 might drop a clock or two when I get the time and a P-2 PC)
Was the Pentium (-1) just better at this, or is there a really smart way?
Does anyone have some even faster code that I can learn from?
So far, on a K6-2-350 I get
Blowfish: 1.95 MHz (179 clk)
DES+schedule increment: 1,19/1.02 MHz (293/343 clk without/with
schedule)
As always, if anyone wants this code, I'll happily mail it, provided that
you tell me if you make it faster (and how)..
/Kasper Pedersen
kasper at traceroute dot dk
------------------------------
From: [EMAIL PROTECTED] (Airbrush4u)
Crossposted-To:
sci.geo.petroleum,alt.pets.ferrets,alt.sport.bowling,comp.os.ms-windows.ce,comp.os.linux.misc,soc.culture.europe,alt.prophecies.nostradamus,alt.catastrophism,alt.prophecies.cayce,alt.messianic,alt.atheism,sci.skeptic,sci.astro,sci.archaeology,alt.current-events.earth-changes
Subject: Re: Warning! The eclipse approaches... {5.6b}
Date: 03 Aug 1999 05:44:22 GMT
>That "monstriferous" Comet Lee will be seen during the
>solar eclipse this August 11th, followed by WWIII, the
>1300-meter "King of Terror" meteoroid impact before 10
>October 1999, and *many* catastrophic events, including
>the >20 degree shifting of the polar axis before 2002!
>The Tribulation prophesied even by our Lord and Savior
>Jesus Christ is begun. ANSWER THIS: Are you prepared?
I am a student of scripture and it is obvious that you are not!
Mike V
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: PC Encrypt
Date: 03 Aug 1999 07:32:31 GMT
>ALF <[EMAIL PROTECTED]> writes:
>I just purchased PC Encrypt. PC Encrypt - Is public-key encryption that
>lets you communicate securely with people you've never met, with no
>secure channels needed for prior exchange of keys. Much easier to use
>than PGP.
>
>http://www.a-lock.com/_site/pce/index.mhtml
>
>Question: How many have tried it, and do you think it is a strong
>as PGP or stronger?
The company is Canadian and distribution of
its crypto software is regulated by laws
akin to the US EAR.
I don't see anything that suggests the
program uses public key encryption at
all. The comapny does claim to use Blowfish.
The version available on-line uses,
according to the company, 40-bit Blowfish
keys. Registered international users
get to use 56-bit keys. Domestic users,
that is Canadian and US residents get to
use 448-bit keys after the program is
registered.
If it is really using Blowfish, then it
doesn't seem to bad. You might want to
ask if you could see their source code.
After they refuse :-) to let you see it,
you could do basic trial encryptions:
encrypt fields of x00s with similar
passwords and look for similarities.
You might later want to disassemble or
the debug program to find out, at least,
how it is handling passwords. If it's
really using Blowfish, it going to be
hard. But if it's handling passwords
incredibly poorly, you might be surpsrised
at what you see within your debugger.
(That's not a hint; I haven't looked at it.)
The comapny's web page talks about a "One-Way
(Self-Extracting) Option." I found no info
on this in the readme or the help file,
but I may have missed it. Anyway, if self-
extracting encrypted files are really an
option, look at them closely. Remember
some of the problems UBE98 had?
You might want to note that the Blowfish
author, Bruce Schneier, maintains a list
on his web site of products that use
Blowfish. PC-Encrypt isn't one of the
them. Could be he doesn't know about it.
I don't think Schneier tests those products:
there are over 100, so I doubt he would
have the time.
On his site, Peter Gutmann lists PC-Encrypt
under the heading "Data Encryption" not
under "Snake Oil." He does note,
parenthetically: "web page smells
slightly of snake oil."
PC-Encrypt Inc. does have a novel (and
scary) idea: a key exchange. It's scary
because it looks like a way to create
and exchange private-key passwords.
Here's what the readme says:
"No need for you to try to dream
up passwords that are hard to
guess but easy to remember.
Key-Exchange does it all for
you - and its a FREE service."
In short, this program doesn't appear
to be a public key system at all. I
would have suggested that you pass it up,
but I see that you've already purchased
it.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: A most useful cipher
Date: Mon, 02 Aug 1999 23:34:21 -0600
In article <7o4agq$13l2$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
> However I for one would not like to see the "new line or double new line" as
> a symbol in the subset beause it is easy to make a reader program that does
> line wrapping so why waste a symbol for it.
The state of the art is word-wrap for text, but the exception is when
lists are made, otherwise, no need for single returns at all at any time.
Then, I never plan to worry about tabs, probably famous last words.
Due to the constraints of characters, the most efficient thing is to use a
double space pair of characters for a double space, if you see what I
mean. Since all standard of the 94 characters are already handled with 47
keys and shift, I had to pick an unusual for internal representation of
space and shift to avoid conflicts. These are merely seen in display, and
likely not to be entered.
There are other sets that might include special characters for various
format functions. Indeed, the space and blank-line were represented as
specials in my base 100 set. Various numbers of available characters
present different problems in regards at to how much usable functionality
you can cram into the sets at hand.
> Is there any one interested in this idea for compression. The user is still
> free to pick the encryption method of his choice. It just would be nice that
> as a first pass before encryption we could use a common method to greatly
> increase the entropy of the message with out using a compression that
> has headers or is not "one to one".
>
>
>
>
> David A. Scott
> --
> SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
> http://www.jim.com/jamesd/Kong/scott19u.zip
> http://members.xoom.com/ecil/index.htm
> NOTE EMAIL address is for SPAMERS
--
MY lock, MY key.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Pencil-and-paper compression algorithms [Re: Between Silk and Cyanide]
Date: Mon, 02 Aug 1999 23:51:12 -0600
In article <7o2gg0$278$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Xcott Craver) wrote:
> >In 1983 another member, Larry Loen, proposed the "Compressocrat", which
> >does what you're suggesting: he started with a ternary encryption of
> >the alphabet, with ETAON getting two trits each, IRSHD getting three,
> >PFCUMWY getting four, BGVKQ getting five, and XJZ getting six, using a
> >fixed alphabet. They were then re-encrypted into 26 letters with a
> >keyed alphabet. This worked well for compressing English and squeezing
> >out redundancy, and was tried for a few times before getting dropped
> >through lack of problem submissions from the members.
>
> Cool. If it's prefix-free (and complete) then you could
> convert to trinary, perform some encryption on the trits, then
> convert the result back using the original compression table,
> adding dummy bits on the end if necessary to get a whole # of
> symbols. Now your ciphertext looks like transposition no
> matter what you used for encryption. Cheap distribution
> matching.
>
The historic compression scheme is in the form of morse code, as I
represent in strings of trits as 1's for dits, 2's for dahs, 0 for between
characters, 00 for between words. Lots of other characters besides
letters are available, most standardized. To do funny things with trits,
break the stream into short lengths, remembering that 27 characters can be
assigned as 3-trit characters and 81 can be assigned as 4-trit characters.
I will take the time to post the full list of characters with their
variable trit values if asked, mostly given historic values.
--
MY lock, MY key.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Americans abroad/Encryption rules?
Date: Mon, 02 Aug 1999 23:56:44 -0600
In article <7o4nvm$qa0$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
>
> if your off us soil and you send encryption to any one you can"t be accussed
> of exporting from the us since your exporting from some where else.
>
It would seem that way since we allow foreigners access to crypto in the
US now, but that is probably because we want to be nice to these foreign
technicians. If you are overseas, don't think that all of your rights
travel with you, as government all too often does things it can and
shouldn't when it thinks it can get away with them.
--
MY lock, MY key.
------------------------------
From: "Radoslav P�r" <[EMAIL PROTECTED]>
Subject: Re: PC Encrypt
Date: Tue, 3 Aug 1999 08:21:04 +0200
-> Blowfish.
http://www.a-lock.com/_site/pce/features.mhtml
Looks interesting. I'll test it soon.
Radek
<[EMAIL PROTECTED]> p��e v diskusn�m
p��sp�vku:7o5c6f$fn0$[EMAIL PROTECTED]
> In article <7o579h$c35$[EMAIL PROTECTED]>,
> Greg <[EMAIL PROTECTED]> wrote:
> > Don't take this wrong, but how many have heard of it?
>
> Also there is no list of what algorithms it uses or how it makes the
> private keys (PRNG). It's closed source so unless something changes I
> would say it's snake oil.
>
> Tom
> --
> PGP key is at:
> 'http://mypage.goplay.com/tomstdenis/key.pgp'.
> Free PRNG C++ lib:
> 'http://mypage.goplay.com/tomstdenis/prng.html'.
>
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
------------------------------
** 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
******************************
