Cryptography-Digest Digest #747, Volume #9 Tue, 22 Jun 99 09:13:03 EDT
Contents:
Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length? (Damian
Weber)
Re: Phone scrambler : what encryption used ? (sb5309)
Weakness of split PGP keys? (Anonymous)
Re: Sexual Contact Privacy :) (Karel Wouters)
Re: Phone scrambler : what encryption used ? ("Lassi Hippel�inen")
authentication wish list (Eric Boesch)
Re: authentication wish list ("Lyal Collins")
Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length? (DJohn37050)
A different method of encryption ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Damian Weber)
Subject: Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length?
Date: 22 Jun 1999 08:35:27 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (DJohn37050) writes:
> check out www.certicom.com, look at ECDSA white paper, for example.
>
> The basic idea is that the hard math problem that ECC is based on appears
> harder than the hard math problem that RSA is based on. There are no known
> subexponential-time algorithms to solve a suitable elliptic curve problem. [...]
Except from special cases.
Polynomial time for #E(Fp)=p.
Subexponential time if #E(Fq) divides q^k-1 for small k.
-- Damian
------------------------------
From: sb5309 <[EMAIL PROTECTED]>
Subject: Re: Phone scrambler : what encryption used ?
Date: Tue, 22 Jun 1999 17:01:18 +0800
Hi Dan, are you still reading this thread ?
Any web link to a description of A5 algorithm ?
Thanks.
Dan Moschuk wrote:
> Last I checked A5 was a popular algorithm in cellular phones (I know it was
> quite popular in Europe at least, I don't know if North America uses it).
>
> Dan
------------------------------
Date: Tue, 22 Jun 1999 11:44:05 +0200 (CEST)
From: Anonymous <[EMAIL PROTECTED]>
Subject: Weakness of split PGP keys?
Hi There.
Say I have a PGP key which has been created with PGP 6.0.2, and is split
into 20 parts. If 19 of these parts are known to an attacker, is the key
any less secure than if say only one part was known?
Thanks.
------------------------------
From: Karel Wouters <[EMAIL PROTECTED]>
Subject: Re: Sexual Contact Privacy :)
Date: Tue, 22 Jun 1999 12:20:06 +0200
On 20 Jun 1999, Doug Goncz wrote:
> It is for the good of the public that the government or a health agency might
> wish to keep records of sexual contacts between people. On the other hand, the
> individuals involved usually wish to retain this information as private. There
> is the possibility that an agency could misuse the information.
You'll have to define sexual contacts ...
and as showed in the past year, Americans may have some problems with that
:-))))
("I did _not_ have any sexual relationship with Ms. XXXXXXXX")
This sounds like flame bait ...
[snip]
Karel w
------------------------------
From: "Lassi Hippel�inen" <[EMAIL PROTECTED]>
Subject: Re: Phone scrambler : what encryption used ?
Date: Tue, 22 Jun 1999 13:27:39 +0300
I'm not Dan, but I might help a bit...
A5 is a stream cipher that xors the data with output from a PRNG. Sort
of pseudo-OTP. The exact algorithm has never been published officially.
Naturally somebody eventually leaked the information, and soon enough A5
was found to be less secure than promised.
A5 is not only popular, it is THE algorithm used in GSM and its
derivatives. Most likely also in the 1900 MHz variant in America.
More information at http://jya.com/crack-a5.htm
-- Lassi
sb5309 wrote:
>
> Hi Dan, are you still reading this thread ?
>
> Any web link to a description of A5 algorithm ?
>
> Thanks.
>
> Dan Moschuk wrote:
>
> > Last I checked A5 was a popular algorithm in cellular phones (I know it was
> > quite popular in Europe at least, I don't know if North America uses it).
> >
> > Dan
------------------------------
From: Eric Boesch <[EMAIL PROTECTED]>
Subject: authentication wish list
Date: Tue, 22 Jun 1999 12:50:27 +0200
Can one achieve all of these goals simultaneously? All the
methods I know of fall short.
Shortness: My password is short and easily memorized (a weak secret).
Trustlessness: I need trust no one and no machine, except possibly
the machine I type my password into. No other person or machine
knows my password or can otherwise assume my identity.
Transportability: I need only my password in order to authenticate
myself, as long as I have access to the network and to client
programs that implement this protocol.
Globality: I can use my password to prove my identity to anyone on the
network (this may be via the authority of a certifying authority,
key server, etc.).
Uncrackability: I can detect and stop dictionary/brute-force attacks
on the password before it becomes compromised. (Brute-force attacks
on strong secrets, such as random 128-bit keys, are not a problem.)
--
Here are some methods that achieve some of these goals. Do
other authentication methods do better? Has method #5 been
implemented, or is it stupid?
Method #1: Forget passwords -- use a long passphrase instead.
By sacrificing shortness, I can achieve the other four goals.
Sounds nice, but it's not realistic to expect large populations to
all memorize and reenter passphrases with 80 bits of entropy.
Method #2: Carry my protected RSA private key around with me.
If I carry around my RSA secret key in a card or a
password-encrypted file, I lose transportability and I partially
lose uncrackability (once someone has this difficult-to-access
item, he can try to defeat the tamper-resistance of the card
or crack my password).
Method #3: Kerberos with *EKE
I am forced to trust the Kerberos server. Globality is
trickier with symmetric-key systems than with public-key.
Method #4: Store my password-encrypted RSA private key on a server
Using an authentication scheme such as SRP, A-EKE, or B-SPEKE to
get in contact with a server that holds my password-encrypted RSA
private key would fix the transportability problem, but the
server itself can crack my password and secret key.
Method #5: Split my RSA private key among n widely-spread servers.
An extension of the previous method. Each server Si holds a
value Vi, where the XOR of V1 ... Vn equals my RSA private key.
I can periodically change the V values, so an attacker must gain
privileged access to all servers in a limited time in order to
crack my password. This comes close to uncrackability. Finding
n reliable independent parties to administrate all these servers
would not be trivial, though.
------------------------------
From: "Lyal Collins" <[EMAIL PROTECTED]>
Subject: Re: authentication wish list
Date: Tue, 22 Jun 1999 21:35:49 +1000
Assuming an absence of biometrics:
In all these situations, you end up using a password at some point.
Choose a good password (good being a subjective term here), and use a
reliable password verification process.
Forget certificates for now, until all the implementation issues
(transportability, storage, bandwidth, processing overheads etc) have been
resolved. The math works, now the challenge is to make PKI cost effective
to deploy in a reliable, secure manner.
Lyal
Eric Boesch wrote in message <[EMAIL PROTECTED]>...
>Can one achieve all of these goals simultaneously? All the
>methods I know of fall short.
>
>Shortness: My password is short and easily memorized (a weak secret).
>
>Trustlessness: I need trust no one and no machine, except possibly
>the machine I type my password into. No other person or machine
>knows my password or can otherwise assume my identity.
>
>Transportability: I need only my password in order to authenticate
>myself, as long as I have access to the network and to client
>programs that implement this protocol.
>
>Globality: I can use my password to prove my identity to anyone on the
>network (this may be via the authority of a certifying authority,
>key server, etc.).
>
>Uncrackability: I can detect and stop dictionary/brute-force attacks
>on the password before it becomes compromised. (Brute-force attacks
>on strong secrets, such as random 128-bit keys, are not a problem.)
>
>--
>
>Here are some methods that achieve some of these goals. Do
>other authentication methods do better? Has method #5 been
>implemented, or is it stupid?
>
>
>Method #1: Forget passwords -- use a long passphrase instead.
>
>By sacrificing shortness, I can achieve the other four goals.
>Sounds nice, but it's not realistic to expect large populations to
>all memorize and reenter passphrases with 80 bits of entropy.
>
>Method #2: Carry my protected RSA private key around with me.
>
>If I carry around my RSA secret key in a card or a
>password-encrypted file, I lose transportability and I partially
>lose uncrackability (once someone has this difficult-to-access
>item, he can try to defeat the tamper-resistance of the card
>or crack my password).
>
>
>Method #3: Kerberos with *EKE
>
>I am forced to trust the Kerberos server. Globality is
>trickier with symmetric-key systems than with public-key.
>
>
>Method #4: Store my password-encrypted RSA private key on a server
>
>Using an authentication scheme such as SRP, A-EKE, or B-SPEKE to
>get in contact with a server that holds my password-encrypted RSA
>private key would fix the transportability problem, but the
>server itself can crack my password and secret key.
>
>
>Method #5: Split my RSA private key among n widely-spread servers.
>
>An extension of the previous method. Each server Si holds a
>value Vi, where the XOR of V1 ... Vn equals my RSA private key.
>I can periodically change the V values, so an attacker must gain
>privileged access to all servers in a limited time in order to
>crack my password. This comes close to uncrackability. Finding
>n reliable independent parties to administrate all these servers
>would not be trivial, though.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length?
Date: 22 Jun 1999 12:52:50 GMT
That is why I said suitable. I was omitting some details.
Don Johnson
------------------------------
From: [EMAIL PROTECTED]
Subject: A different method of encryption
Date: Tue, 22 Jun 1999 12:06:16 GMT
Reply-To: [EMAIL PROTECTED]
With the security of one's ideas at stake, encryption has been a
necessary tool in the protection of those things which one treasures
most. Yet up to this point, we have no method of encryption absolutely
secure against those who would break the cryptographical locks.
Until now. I believe I have stumbled upon a method of encryption that
uses not mathematical but logical locks to protect the encrypted from
being decyphered. Fortunately, the method is simple enough to explain
in this text.
(Before going on, I must note that the reader will have the most to
gain from this text if he/she has an active comprehension of
mathematics and a basic understanding of the logic behind information
theory. Some fundamental knowledge of the C++ and BASIC programming
languages, including the concepts of indirection and subscripting, is
also recommended.)
Let the letter r represent the file to be encrypted, and let r(n)
represent the nth byte of that file. Let s represent a file full of
random bytes, as many bytes as there are in r, where s(n) is the nth
byte of that file. Let t represent the file that will be produced once
the encryption process is complete, t(n) representing the nth byte of
that file.
t(n) is computed as follows:
t(n) = (r(n) + s(n)) % 256,
where the % operator corresponds to the C++ modulus (remainder)
operator (identical to the BASIC MOD operator). This computation is
carried out as many times as there are bytes in r, that is, for each n.
Note that r, s, and t will all be of equal length.
Once the process is complete, the file, t, that was produced will
contain apparently random information, granted s was completely random.
Regardless of r or s, however, no information can be decyphered from t
without any knowledge of r or s. This concept is as simple as the
equation c + d = 122 (where c and d are real numbers), for no
information about c can be derived without any knowledge of d. It is
this logical lock which, in the author's opinion, makes this relatively
simple algorithm uncrackable (without s).
Decryption using this algorithm is just as simple. If t and s are
available, then the equation
r(n) = (t(n) - s(n) + 256) % 256,
evaluated for each n, will produce the plaintext file, r.
This method is not without its downsides, though. The password file,
file s from above, should be at least as long as r, though this is not
entirely necessary. If r is longer than s, then if k (an integer) is
the length of s, then this alternate equation can be used:
t(n) = (r(n) + s(n % k)) % 256,
so that s is used multiple times in the encryption process. I am
uncertain if this will compromise the security of the algorithm,
however.
Another downside is that, when you encrypt a file using this method,
you absolutely must keep track of the password file (file s) before
decrypting. If the password file is lost, then so is the encrypted file
(file r): there is no way (honest) to retrieve the useful (plaintext)
information from it. If the encrypted file is sent to a friend, then so
must the passowrd file. This is worth considering...
The author has also considered another, similar algorithm with these
same characteristics, but with one important difference: the encryption
equation is the same as decryption equation. Before giving the
equation, I must first explain the concept of inverse operations. An
inverse operator "undoes" what another operator "does". Note that
subtraction is the inverse of addition, division the inverse of
multiplication. The equation described above must use an operator that
is the inverse of itself.
One such operator, fascinatingly enough, is the bitwise exclusive-OR
operator, used in the following equation:
t(n) = r(n) ^ s(n),
where the ^ operator corresponds to the C++ bitwise exclusive-OR
operator. As stated above, the same equation (with r(n) and t(n)
switched, of course) will reconstruct the plaintext file.
Incorporating these algorithms into programs should be effortless on
the part of the programmer; nevertheless, I have provided C++ code
below that uses the algorithms to produce the encrypted files. There
are four programs in all: encrypt.cpp and decrypt.cpp, which use the
first algorithm to produce an encrypted file and plaintext file,
respectively; obscure.cpp, which uses the second algorithm to both
encrypt and decrypt files; and maker.cpp, which produces files full of
random information, ideal for the password files for the encryption
process. I should point out that my programs are best not improved
upon, as there are far better ways to implement the methods I have
described above. One should also note that, in my programs, I have
permitted the password file to be shorter than the file to be encrypted.
I have separated the programs with remarks such as /* BEGIN encrypt.cpp
*/ and /* END encrypt.cpp */. I strongly advise against building all
that follows as one big program! Separately, they build well with
DJGPP, available from the Free Software Foundation (www.fsf.org).
One last note: the code below, as is this entire document, is public
domain. Any or all of this text may be reproduced and distributed in
any way without the notification of, or obtaining permission from, the
author. May the software below give liberty of thought and
communication to all those who would seek and take advantage of it.
/* BEGIN encrypt.cpp */
#include <io.h>
#include <fcntl.h>
#include <errno.h>
#include <stdio.h>
int main(void)
{
int fi, fp, fo, e1, e2, e3;
char fni[100], fnp[100], fno[100];
unsigned char c1, c2, cn;
signed short int ci;
unsigned long int cp = 0, cpp = 0, il = 0, il2 = 0, _1;
int kg = 1;
printf("Input file?");
scanf("%s", fni);
printf(fni); printf("\n");
fi = _open(fni, O_BINARY | O_RDONLY);
if (fi==-1)
{
printf("File not found");
return 0;
}
printf("Password file?");
scanf("%s", fnp);
printf(fnp); printf("\n");
fp = _open(fnp, O_BINARY | O_RDONLY);
if (fp==-1)
{
printf("File not found");
return 0;
}
printf("Output file?");
scanf("%s", fno);
printf(fno); printf("\n");
fo = _creat(fno, 0);
il = filelength(fi);
printf("Input file length: " "%lu" "\n", il);
il2 = filelength(fp);
printf("Password file length: " "%lu" "\n", il2);
for (_1=0; _1<il; _1++)
{
e1 = _read(fi, &c1, 1);
if (e1==-1)
{
printf("1Error %d", errno);
return 0;
}
e2 = _read(fp, &c2, 1);
if (e2==-1)
{
_close(fp);
fp = _open(fnp, O_BINARY | O_RDONLY);
e2 = _read(fp, &c2, 1);
}
ci = c1 + c2;
ci %= 256;
cn = (unsigned char)ci;
e3 = _write(fo, &cn, 1);
if (e3==-1)
{
printf("3Error %d", errno);
return 0;
}
}
return 0;
_close(fi), _close(fp), _close(fo);
}
/* END encrypt.cpp */
/* BEGIN decrypt.cpp */
#include <io.h>
#include <fcntl.h>
#include <errno.h>
#include <stdio.h>
int main(void)
{
int fi, fp, fo, e1, e2, e3;
char fni[100], fnp[100], fno[100];
unsigned char c1, c2, cn;
signed short int ci;
unsigned long int cp = 0, cpp = 0, il = 0, il2 = 0, _1;
int kg = 1;
printf("Input file?");
scanf("%s", fni);
printf(fni); printf("\n");
fi = _open(fni, O_BINARY | O_RDONLY);
if (fi==-1)
{
printf("File not found");
return 0;
}
printf("Password file?");
scanf("%s", fnp);
printf(fnp); printf("\n");
fp = _open(fnp, O_BINARY | O_RDONLY);
if (fp==-1)
{
printf("File not found");
return 0;
}
printf("Output file?");
scanf("%s", fno);
printf(fno); printf("\n");
fo = _creat(fno, 0);
il = filelength(fi);
printf("Input file length: " "%lu" "\n", il);
il2 = filelength(fp);
printf("Password file length: " "%lu" "\n", il2);
for (_1=0; _1<il; _1++)
{
e1 = _read(fi, &c1, 1);
if (e1==-1)
{
printf("1Error %d", errno);
return 0;
}
e2 = _read(fp, &c2, 1);
if (e2==-1)
{
_close(fp);
fp = _open(fnp, O_BINARY | O_RDONLY);
e2 = _read(fp, &c2, 1);
}
ci = c1 - c2 + 256;
ci %= 256;
cn = (unsigned char)ci;
e3 = _write(fo, &cn, 1);
if (e3==-1)
{
printf("3Error %d", errno);
return 0;
}
}
return 0;
_close(fi), _close(fp), _close(fo);
}
/* END decrypt.cpp */
/* BEGIN obscure.cpp */
#include <io.h>
#include <fcntl.h>
#include <errno.h>
#include <stdio.h>
int main(void)
{
int fi, fp, fo, e1, e2, e3;
char fni[100], fnp[100], fno[100];
unsigned char c1, c2, cn;
signed short int ci;
unsigned long int cp = 0, cpp = 0, il = 0, il2 = 0, _1;
int kg = 1;
printf("Input file?");
scanf("%s", fni);
printf(fni); printf("\n");
fi = _open(fni, O_BINARY | O_RDONLY);
if (fi==-1)
{
printf("File not found");
return 0;
}
printf("Password file?");
scanf("%s", fnp);
printf(fnp); printf("\n");
fp = _open(fnp, O_BINARY | O_RDONLY);
if (fp==-1)
{
printf("File not found");
return 0;
}
printf("Output file?");
scanf("%s", fno);
printf(fno); printf("\n");
fo = _creat(fno, 0);
il = filelength(fi);
printf("Input file length: " "%lu" "\n", il);
il2 = filelength(fp);
printf("Password file length: " "%lu" "\n", il2);
for (_1=0; _1<il; _1++)
{
e1 = _read(fi, &c1, 1);
if (e1==-1)
{
printf("1Error %d", errno);
return 0;
}
e2 = _read(fp, &c2, 1);
if (e2==-1)
{
_close(fp);
fp = _open(fnp, O_BINARY | O_RDONLY);
e2 = _read(fp, &c2, 1);
}
ci = c1 ^ c2;
cn = (unsigned char)ci;
e3 = _write(fo, &cn, 1);
if (e3==-1)
{
printf("3Error %d", errno);
return 0;
}
}
return 0;
_close(fi), _close(fp), _close(fo);
}
/* END obscure.cpp */
/* BEGIN maker.cpp */
#include <io.h>
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
int f; char fn[20]; int s; unsigned char c; int hm, _1;
// unsigned char *cc = new unsigned char;
printf("What file?");
scanf("%s", fn);
printf("How many characters?");
scanf("%d", &hm);
printf("What seed?");
scanf("%d", &s);
f = _creat(fn, 0);
srandom(s);
for (_1=0; _1<hm; _1++)
{
c = (unsigned char)((+random())%256);
_write(f, &c, 1);
}
return 0;
}
/* END maker.cpp */
--
Order breeds knowledge. Knowledge breeds order.
Chaos breeds ignorance. Ignorance breeds chaos.
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
******************************
