Cryptography-Digest Digest #816, Volume #8 Wed, 30 Dec 98 15:13:04 EST
Contents:
Re: WEAK4-EX -- Another Poorman's 56-bit Data Encryption Algorithm (long) (Mok-Kong
Shen)
Re: Decoder for Reed-Solomon codes? (Jyrki Lahtonen)
Re: New Book "The Unknowable" (John Savard)
Secure Credit Card Transactions (Benzbrood)
Re: Session keys in Elliptic Curve (liminal)
Re: Secure Credit Card Transactions ("Steve Sampson")
Re: Session keys in Elliptic Curve (Anonymous)
Re: Security through obscurity in the smartcard world (liminal)
Re: "Encrypted Magic Folders" substitute ("Sam Simpson")
Re: biometrics (Anthony Stephen Szopa)
Re: Opinions on S/MIME ("Sam Simpson")
Re: "should have" for an encrypting filesystem ("Sam Simpson")
Re: Session keys in Elliptic Curve (Mr. Tines)
Re: Blowfish assembler (i386) help needed (Paul Rubin)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: WEAK4-EX -- Another Poorman's 56-bit Data Encryption Algorithm (long)
Date: Wed, 30 Dec 1998 15:34:51 +0100
Sorry for a typing error in text. Corrected:
do
with probability 1/scf3:
output( input() XOR pbit(scf2) );
with probability 1 - 1/scf3:
output( pbit(1) );
od;
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Jyrki Lahtonen)
Crossposted-To: comp.dsp,sci.math
Subject: Re: Decoder for Reed-Solomon codes?
Date: 30 Dec 1998 06:57:36 GMT
You probably also need to find a primitive
>element modulo 929. This shouldn't be too hard - I will come back to
>this later.
If I didn't make any typos when plugging the numbers into Mathematica,
3 (or its residue class, if you want to be pedantic) is a primitive
element of GF(929), i.e. all the other non-zero elements are of the
form 3 raised to power i for a unique i in the range from 0 to 927
inclusive.
Jyrki Lahtonen, Ph.D.
Department of Mathematics,
University of Turku,
FIN-20014 Turku, Finland
Note to human e-mailers! To obtain my real e-mail address form the
string consisting of my first name, a period, my family name (names in
lower case) and an at-sign followed by utu.fi
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: New Book "The Unknowable"
Date: Wed, 30 Dec 1998 15:37:39 GMT
[EMAIL PROTECTED] wrote, in part:
>Hi folks, this is to let everyone know that I've
>just finished a new book, "The Unknowable".
>It's a prequel/sequel to my book on "The Limits
>of Mathematics". "The Unknowable" is available
>in html and in postscript at these two URL's:
>http://www.umcs.maine.edu/~chaitin/unknowable
>http://www.cs.auckland.ac.nz/CDMTCS/chaitin/unknowable
>Best wishes for 1999,
Ah. I read about you in Rudy Rucker's "Mind Tools".
His description of your famous proof was somewhat ambiguous.
Obviously, there is a simple proof that for any t, there _exist_
strings of complexity greater than t; as there are 2^(t+2) strings of
length t+2, there are insufficient strings of length t (2^(t+1)-1) to
generate them all.
What you had proved, I believe, was that for some t sufficiently
large, any finite system/machine cannot prove, for any specific
string, that that particular string has complexity greater than t.
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (Benzbrood)
Subject: Secure Credit Card Transactions
Date: 30 Dec 1998 16:08:30 GMT
I need the info, progs, urls, or whatever I need to make a web site with secure
transactions for an online store, subscriptions, etc. Please reply.
------------------------------
From: liminal <[EMAIL PROTECTED]>
Subject: Re: Session keys in Elliptic Curve
Date: Wed, 30 Dec 1998 08:58:15 -1000
> Hello again.
>
> Big thanks to both Mr. Tines and Harpy-34 for their
> graceful handing of information regarding elliptic
> curve cryptography.
My pleasure.
> Now, as the session key-thing is effectively settled
> (as far as matters anyway,) now I'd like to ask a bit
> about the private key in elliptic curve, and generation
> of private/public keypair.
>
> What would be the process of generating a 160 bit
> elliptic curve key?
This is so difficult that I would not even consider attempting to explain
the method. But I will outline the hurdles you would fail to surmount.
First, chose an elliptic curve which satisfies the MOV condition and
which has enough Points on it so that a search is intractible for your
adversaries. For a discussion of these tasks see:
http://ds.dial.pipex.com/george.barwood/ec_faq.txt
which George Barwood has generously posted on the WWWeb.
>Public/private keylengths?
All numbers are less than 170 bits.
> Does the generation of the keys correspond to
> the generation methods in RSA et all?
No.
>And is
> a hash algorithm used in the generation, which
> would impose a limit of 160 bits if for example
> SHA-1 was used?
No.
> - --EO
Please read these books cover to cover, and after you fail to comprehend
78% of the equations, give up and purchase software that was written by a
team of 6 PhD mathematicians over the course of 2 years.
A Course in Number Theory and Cryptography (2nd edition)
by Neal Koblitz
Springer-Verlag (New York) 1994
ISBN 0-387-94293-9
Elliptic curve public key cryptosystem
by A.J. Menezes
Kluwer Academic Publications 1993
------------------------------
From: "Steve Sampson" <[EMAIL PROTECTED]>
Subject: Re: Secure Credit Card Transactions
Date: Wed, 30 Dec 1998 11:04:51 -0600
How much money do you want to spend?
Go to CCNow http://www.ccnow.com/
People can order products from you, and not pay sales tax
(CCNow is a Delaware company). No startup or monthly fees.
@ 8% of each sale.
Go to the Netscape Website
http://merchant.netscape.com/netstore/servers/suitespot.html
1) Purchase the Suitespot Server (includes LDAP, etc).
2) Order an annual Server Certificate from Verisign.
@ $4000 or so.
Benzbrood wrote in message <[EMAIL PROTECTED]>...
>
>I need the info, progs, urls, or whatever I need to make a web site with
secure
>transactions for an online store, subscriptions, etc. Please reply.
------------------------------
From: Anonymous <[EMAIL PROTECTED]>
Subject: Re: Session keys in Elliptic Curve
Date: 30 Dec 1998 17:26:07 +0100
=====BEGIN PGP SIGNED MESSAGE=====
Hello again.
Big thanks to both Mr. Tines and Harpy-34 for their
graceful handing of information regarding elliptic
curve cryptography.
Now, as the session key-thing is effectively settled
(as far as matters anyway,) now I'd like to ask a bit
about the private key in elliptic curve, and generation
of private/public keypair.
What would be the process of generating a 160 bit
elliptic curve key? Public/private keylengths?
Does the generation of the keys correspond to
the generation methods in RSA et all? And is
a hash algorithm used in the generation, which
would impose a limit of 160 bits if for example
SHA-1 was used?
- --EO
=====BEGIN PGP SIGNATURE=====
Version: PGP 6.0.2
iQEVAwUBNoqMH8gXRmWyooNRAQGkyAf8D+di1pZCZ3GQr6t5acTExn8FNXZMuLdK
o74e7NiNHA+1aQbABwD6kzJPTb6eqmQGheHoHbYn4aEroGrAQHwiekMl9kDbMDy9
ukzJlGfw55w8j+afu0xAbHPo1Wi8G6uix5Wlf5SOe4li8SrUAZt0m1+viCQfC3Aj
QWZWtg0CReQD3XfCCkkr5+2WEWZgV3Ta7ojNAG0IkPdDEVIYbJ+LM1X2RTGOV7v4
C9Nvcj4XtEm0gQ6IkjgBFY9mMsswT5TPCV3rz5EvjFjN0pWCMnvOLgUKP/EzHtUS
hw761A9JctLG8UbU7Ra70JAwHMOaoiBVrAKvrx+WdGT+RpetAplG0Q==
=M/CA
=====END PGP SIGNATURE=====
------------------------------
From: liminal <[EMAIL PROTECTED]>
Subject: Re: Security through obscurity in the smartcard world
Date: Wed, 30 Dec 1998 09:22:00 -1000
Gary Howland wrote:
SNIP...
> I want comment on
> the priniciple of adding security (i.e. cost and expense) using
> obscurity. My reason for wanting debate, first on the question of
> "is security through obscurity" valid, and second on "how?", is
> because I intend to write a report on the benefits of obscurity,
> and the techniques one should use when creating proprietary
> algorithms. So in addition to comments on the validity of the
> proprietary algorithms, I would also like comments on the best ways
> of creating such proprietary algorithms.
SNIP...
> Best regards,
>
> Gary Howland <[EMAIL PROTECTED]>
People who care about the privacy of their own files and messages should
write their own obsure software. They should not try to sell it to the
public. If hundreds of people did this, they would be almost safe from
professional cryptanalysis, since that task is so difficult and there are
far fewer cryptanalysts than programmers. People who try to sell obscure
crypto create a laughing stock. The comedy warehouse is half full of
laughingstock, there is room for much more.
Ciphertext files can be obscured so they look like either random data or
innocent data. Keep similar files around to hide the real files. Traffic
analysis can be made harder by fake traffic. In other words, send files
that "seem encrypted" every day.
Key Protection
The key file can optionally be protected by a password so, if it is
found, it cannot be easily
used. You should record the hex checksum that you are given by the
program when you use
the password option. Then, when you use the program the next time, and
you give your
password, you can compare the hex checksum that the program gives you
with the
checksum you were given the last time. If the two checksums are equal,
you are sure that
you have used the same password. Also, David recommends NOT keeping the
keyfiles on
your hard drive, but to put it on a 1.44 Megabyte floppy.
Store the floppy in a heavy safe, preferably in a bunker that is
radiation-hardened using standard methods which typically
require that the bunker be lined with lead or boron at least 4mm thick,
encased in a vacuum envelope composed of
magnesium that is separated from, and magnetically suspended by, a
gadolinium-nickel alloy cable that is at least 12
meters long over an earthen pit containing a shallow pool of fuming red
nitric acid so that if these precautions are taken,
and the Big One does not hit, then an insurance policy may become
available for a nominal fee which would absolutely
reimburse you for the cost of the floppy disk in case it is stolen while
being transported by trusted courier to the person
with whom you wanted to share the secret key. Alternatively, you could
use public-key cryptography to send the secret
key to your friend, in which case, the potential offer of an insurance
policy would be null and void.
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: "Encrypted Magic Folders" substitute
Date: Wed, 30 Dec 1998 10:16:39 -0000
Try ScramDisk (URL in my sig). It's free and comes with source.
It may meet your requirements for speed... If speed is the primary concern
then I recommend TEA or, if speed doesn't prevent you, try Blowfish wish is
far more secure.
>From the quote below, EMF does seem like bad news!
Regards,
Sam Simpson
Comms Analyst
-- http://www.hertreg.ac.uk/ss/ for ScramDisk hard-drive encryption & Delphi
Crypto Components. PGP Keys available at the same site.
Chuck Harrison wrote in message <[EMAIL PROTECTED]>...
>A colleague of mine is building an MSWindows/PC based system which
>streams multimedia data from disk. The multimedia data should be
>encrypted ('cause someone else owns the copyright). For demo purposes
>he's using "Encrypted Magic Folders", a shareware program
> (http://www.pc-magic.com/des.htm#emf).
>
>From the manufacturer's description of this product --
>> * How Secure is it?
>>
>> EMF's encryption offers good protection and excellent speed. It
>> hasn't been broken yet [...]
>> We developed our own encryption instead of using a standard
>> because we wanted EMF to be able to decrypt at the byte level.
>
>-- it seems likely it's an easy crack. What can be used for disk
>encryption that's pretty secure but also decrypts fast enough to do
>multimedia on the fly?
>
>Thanks for any pointers,
> Chuck Harrison
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Subject: Re: biometrics
Date: Wed, 30 Dec 1998 09:05:03 -0800
Reply-To: [EMAIL PROTECTED]
Withheld wrote:
> In article <75kv35$jhd$[EMAIL PROTECTED]>, David A Molnar
> <[EMAIL PROTECTED]> writes
> >Myself <[EMAIL PROTECTED]> wrote:
> >> Handy, and the menu system could even track eye movements, instead of
> >> requiring keypresses, to make selections. No more busted keys at the
> >> ATM (just spraypainted iris-cams). and a messy sneeze would be
> >> disastrous. How physically reliable and vandal-resistant are
> >> fingerprint readers?
> >
> >am I the only one who would worry about pranksters putting something nasty
> >n the eyepieces ?
> >
> >On a different note, what prevents me from setting up a fake ATM and
> >capturing your biometric data the same way I capture PIN numbers, then
> >using it elsewhere? Perhaps it won't be of much use with an ATM's iris
> >scanner, but what if I pop the lid off the ATM , cut the wire from the
> >scanner, and then hook it to my "handy bank of people" ? or if biometrics
> >are widespread, used as passphrases and such, and so I can go look for
> >easier targets ?
> >
> >It is a neat idea, and it's no work to remember, but it sounds
> >fundamentally like a very long and complicated passphrase that can't ever
> >be changed.
> >
> >-David
>
> Retinal scanners overcome a lot of the "info grabbing" approach as they
> look for a pulse in the retina as well. If the pulse is missing it knows
> it is looking at either a fake eye or a corpse.
>
> My main concern is the potential for long term harm, caused by
> repeatedly having lasers shone directly into my eyes.
>
> --
> Return address removed for anti-spam purposes.
> Email replies to news at maelstrom dot demon dot co dot uk
> Email replies to this address may be copied to relevant newsgroups
I think our real concern is caring for all the people who will have their eyes
ripped out from their sockets!
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: Opinions on S/MIME
Date: Wed, 30 Dec 1998 09:27:20 -0000
Roger,
The table was taken from Applied Cryptography. The figures do seem
conservative, but "bits are cheap" these days....
Once again, my apologies for the "draftness" of the previous post.
Once quick question; you state that "Breaking a 512-bit DSA key is
significantly more difficult. [than an RSA key]". Could you please explain
(in laymen terms - I'm not that bright <g>). I thought ElGamal and RSA keys
of the same length were thought to be equivalently secure?
Thanks in advance,
Sam Simpson
Comms Analyst
-- http://www.hertreg.ac.uk/ss/ for ScramDisk hard-drive encryption & Delphi
Crypto Components. PGP Keys available at the same site.
Roger Schlafly wrote in message <76b9g1$[EMAIL PROTECTED]>...
>
>Sam Simpson wrote in message <[EMAIL PROTECTED]>...
>>Asymmetric key size is of great importance in PGP and S/Mime. The
>following
>>table, from [Sch96] lists the recommended public key length to protect
>>against attack by a single corporation (keys should be substantially
bigger
>>to protect against intelligence agencies!):
>>
>> --------------------------------------
>> Year Recommended Key Length
>> --------------------------------------
>> 1995 1280
>> 2000 1280
>> 2005 1536
>> 2010 1536
>> 2015 2048
>> --------------------------------------
>
>I don't know that reference, but these recommendations seem quite
>paranoid to me. No one has publicly broken a 512-bit RSA key yet.
>Breaking a 512-bit DSA key is significantly more difficult.
>
>By my estimates, breaking a 1280-bit key is about a billion times
>more work. This is way out range for anyone today.
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: "should have" for an encrypting filesystem
Date: Wed, 30 Dec 1998 11:37:40 -0000
Florian,
I am involved with ScramDisk - so I know just about all there is to know
about disk encryption under Win95/98 :-)
If I can help in any way, please feel free to contact me off list.
Having a multiuser EFS is an interesting problem. Currently, probably the
best way of providing this is via something like the NT v5 NTFS encryption
scheme (though I am not vouching for the cryptographic strength of the
implementation!) - which enables a properly authorised set of users to
decrypt and use the file.
Providing an encrypted container file (a la ScramDisk, PGPDisk, BestCrypt)
_may_ present consistency issues not covered by the file-locking semantics
of the underlying operation system.
Regards,
Sam Simpson
Comms Analyst
-- http://www.hertreg.ac.uk/ss/ for ScramDisk hard-drive encryption & Delphi
Crypto Components. PGP Keys available at the same site.
Florian Erhard wrote in message
<76d1qb$mhi$[EMAIL PROTECTED]>...
>I'm writing my diploma thesis on the subject of an encrypting file system.
>I already looked at many existing products and of course have my own
>thoughts, too. But perhaps you could write me some things, that come
>to your mind when you think of what an encrypting file system should
>look like. Your ideas shouldn't be lead by the problem how to solve them -
>just think you have got some whishes granted.
>For example one point on my list is, that I want to have a real multiuser
>filesystem.
>
>Thanks for your answers!
>Florian
>
>BTW: Since I read this ng, you don't have to reply by email.
------------------------------
From: Mr. Tines <[EMAIL PROTECTED]>
Subject: Re: Session keys in Elliptic Curve
Date: 30 Dec 1998 16:41 +0000
###
On 30 Dec 1998 17:26:07 +0100, in <[EMAIL PROTECTED]>
Anonymous <[EMAIL PROTECTED]> wrote.....
> What would be the process of generating a 160 bit
> elliptic curve key? Public/private keylengths?
> Does the generation of the keys correspond to
> the generation methods in RSA et all? And is
> a hash algorithm used in the generation, which
> would impose a limit of 160 bits if for example
> SHA-1 was used?
You start with the generator prime, which is public;
the private key is any random collection of bits -
in this case 160 bits, generated for the purpose by any
means you care to apply. The multiplication
to yield the public key is then entirely deterministic.
This is a lot simpler than for RSA, in which you have to
generate a suitably large random number, apply a
probabilistic test for primality, and if it fails, try
again. Then once you have one prime, repeat the exercise
to get another. Then all the arithmetic happens to compute
n, d and e.
George Barwood's Pegwit public key system uses GF(2^255)
with an effective key size of about 240 bits; in this
system, an arbitrary file is used as the raw secret, and a
PRNG using SHA-1 is used to crank out 30 bytes of transient
but reproducible secret key, which is then multiplied
by the prime generator to yield the public key. This
point in the arithmetic is then distilled down into a
plain bit-stream for publication (as below).
Source is available via my web page (URL in .sig)
-- PGPfingerprint: BC01 5527 B493 7C9B 3C54 D1B7 248C 08BC --
_______ {pegwit v8 public key =581cbf05be9899262ab4bb6a08470}
/_ __(_)__ ___ ___ {69c10bcfbca894a5bf8d208d001b829d4d0}
/ / / / _ \/ -_|_-< www.geocities.com/SiliconValley/1394
/_/ /_/_//_/\[EMAIL PROTECTED] PGP key on page
### end pegwit v8 signed text
0cbbad36ef6950984237dac678adc33499544648ba97c96429186bc1b89f
2822683f0e0823032ea9f20e4fe690fab02bc4605615dcee6cd60af271e6
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Blowfish assembler (i386) help needed
Date: Wed, 30 Dec 1998 18:23:49 GMT
In article <[EMAIL PROTECTED]>,
Allan Latham <[EMAIL PROTECTED]> wrote:
>Can anyone out there help with this one.
>
>The enclosed is an assembler (i386) version of Blowfish which
>compiles under linux using the C compiler. I know almost nothing
>about assembler so I cannot comment on it except that it is very fast
>and produces identical results to C versions.
>
>It is public domain and was not written by myself however I would
>dearly love to have the same thing but on Microsoft Visual
>C++. According to the MSVC++ documentation this should be easy - just
>put "asm" on each line!
The linux assembler and the MS assembler use completely different
syntax. You need to translate from one to the other and while
that's not especially hard, you need to know what you're doing.
I'm sure there is MS asm code for Blowfish around though, so you
can probably get it somewhere and not translate that code you posted.
Btw it looks to me like your code can be sped up considerably
by rewriting it to use fewer shifts and to get better pairing
on the Pentium. Doing a really good job of that takes detailed
knowledge of the processors and considerable ingenuity, but as
before, I think it's already been done for Blowfish.
------------------------------
** 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
******************************
