Cryptography-Digest Digest #302, Volume #9 Tue, 30 Mar 99 11:13:03 EST
Contents:
Re: What is fast enough? (Chem-R-Us)
Re: newbie question ("Kryspin Ziemski")
ANN: Self-restoring encrypted archives (Andy Jeffries)
Re: Twofish Book Published by Wiley (Bruce Schneier)
Re: How do I determine if an encryption algorithm is good enough? (wtshaw)
Re: Wanted: free small DOS Encryption program - rc4.exe (0/1) (Frank Andrew
Stevenson)
Re: newbie question ("Michal Brzozowski")
Re: True Randomness & The Law Of Large Numbers (Dave Knapp)
Re: Prof Shamir, was: Live from the Second AES Conference (Serge Vaudenay)
Does anyone know how to solve vigenere and tranposition cipher? ("colgates")
Re: newbie question ("Douglas A. Gwyn")
Re: fast enough (sequel) (Thomas Pornin)
Re: newbie question (Peter Gunn)
Re: How to avoid double random numbers? (Patrick Juola)
Re: newbie question (Patrick Juola)
Re: True Randomness & The Law Of Large Numbers (Herman Rubin)
Re: ---- Two very easy secret key Cryptosystems ([EMAIL PROTECTED])
Re: Wanted: free small DOS Encryption program (Albert P. Belle Isle)
----------------------------------------------------------------------------
From: Chem-R-Us <[EMAIL PROTECTED]>
Subject: Re: What is fast enough?
Date: Tue, 30 Mar 1999 00:24:36 -0800
[EMAIL PROTECTED] wrote:
>
> 100baseT is 12.5MB/sec.
>
> --
> Lamont Granquist ([EMAIL PROTECTED])
> ICBM: 47 39'23"N 122 18'19"W
Hi Lamont,
No time, long see.
You do realize that's not including overhead...
--
Chem-R-Us
PGP Key available upon request, just email me.
mailto:[EMAIL PROTECTED]
------------------------------
From: "Kryspin Ziemski" <[EMAIL PROTECTED]>
Subject: Re: newbie question
Date: Tue, 30 Mar 1999 03:28:19 -0500
fine still does not change the fact that ..
hey you're polish, cool.. just noticed the pl in the ip address
well fine assuming that you have the recipient's public key, you can find
his private key
by simply debugging the code and looking for the part that actually
manipulates that public key
to find the private key. how do you prevent this dilema which should occur
because there is no way to hide the actual function from being observed on
the byte level.
Michal Brzozowski <[EMAIL PROTECTED]> wrote in message
news:6w%L2.33449$[EMAIL PROTECTED]...
>
> Kryspin Ziemski wrote in message <[EMAIL PROTECTED]>...
> >My understanding of public key cryptography is that each person is
assigned
> >to keys one private and one public. the sender encrypts the message with
> >his private key and then sends the message to the reader.
> >the reader gets the sender's public key from a directory and then
converts
> >the public key to the private key using some mathematical relation and
> >decrypts the message using the private key. If this is how public key
> >cryptography works what stops me obtaining the sender's public key and
> >debugging the program to find the code that works on the public key to
> >convert it to the private key which i'm assuming is done locally on the
> >computer.
>
>
> Wrong. Sender encrypts message with receipient's public key,
> and receipient decrypts it using his (receipient's) private key,
> Nobody (except owner) has access to private key.
>
> Michal Brzozowski
> [EMAIL PROTECTED]
>
>
>
------------------------------
From: [EMAIL PROTECTED] (Andy Jeffries)
Crossposted-To: alt.privacy,alt.security.pgp,comp.security.pgp.discuss
Subject: ANN: Self-restoring encrypted archives
Date: Tue, 30 Mar 1999 13:43:12 +0100
Announcement
============
Stevenage, Herts - Kwik-Rite Development has today released the first
public beta of Kwik-Crypt (development announced on 11 March 1999) - an
encrypting/compressing archive utility.
Kwik-Crypt produces a multi-file compressed archive encrypted with Blowfish
using an SHA-1 password hash. The file format is extensible and other
algorithms may be implemented in due course.
Users can either distribute just the archive file or Kwik-Crypt can create a
self-restoring file that when run on a target machine will decompress and
decrypt each file.
The most important part of the announcement, Kwik-Crypt is released as
Freeware and will have full Delphi 4 source code posted after beta-testing
is complete.
Sam Simpson is providing advice on the cryptographic elements of the
program.
Another announcement will be made when the product is fully released.
For those of you interested in downloading it, please go to
www.kwikrite.clara.net
--
Andy Jeffries
Kwik-Rite Development
--See http://www.kwikrite.clara.net/ for Kwik-Crypt BETA - Self-restoring
archive maker for Windows 95/98/NT using Blowfish (FREEWARE)
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: Twofish Book Published by Wiley
Date: Tue, 30 Mar 1999 12:40:28 GMT
On Tue, 30 Mar 1999 02:28:19 GMT, [EMAIL PROTECTED] (Paul Rubin) wrote:
>In article <[EMAIL PROTECTED]>,
>Bruce Schneier <[EMAIL PROTECTED]> wrote:
>>A book about Twofish has been published by John Wiley & Sons. This
>>book contains all the information in the initial Twofish submission
>>and the first three Twofish tech reports, expanded and corrected.
>>The book costs $50, but I am offering it at a 20% discount. See:
>>
>> http://www.counterpane.com/twofish-book.html
>
>Is there anything in the book that's not on your web site?
>One exception might code listings, due to export controls.
The book is more clearly written; there were several sections that we
updated and expanded. Mostly, though, it's on the website in a
variety of forms.
Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: How do I determine if an encryption algorithm is good enough?
Date: Tue, 30 Mar 1999 01:08:27 -0600
In article <7donnj$3hb$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Patrick Juola) wrote:
> In article <[EMAIL PROTECTED]>,
> R. Knauer <[EMAIL PROTECTED]> wrote:
> >On Mon, 29 Mar 1999 11:43:14 -0800, "Harv" <[EMAIL PROTECTED]>
> >wrote:
> >
> >>Extraordinary claims require extraordinary evidence.
> >
> >Occam's Razor states otherwise. It is usually the less extraordinary
> >claims that requires the more extraordinary evidence.
>
> What?
>
> Add William of Occam to your suggested re-reading list.
>
One can hide behind such generalized methods of evaluation by doing the
unexpected. No where is this more true than it can be in crypto, where
deceit and fraud are applicable qualitites to use in defining ciphertext,
making it look like a certain type of algorithm was used when it wasn't.
But, there is something pleasing in finding simple but elegant solutions
as opposed to complex and almost incomprehensible ones.
--
Ethnic clensing does not appear to be a response to a high moral calling.
------------------------------
From: [EMAIL PROTECTED] (Frank Andrew Stevenson)
Crossposted-To: comp.security.misc
Subject: Re: Wanted: free small DOS Encryption program - rc4.exe (0/1)
Date: Tue, 30 Mar 1999 09:47:33 GMT
Reply-To: [EMAIL PROTECTED]
Milton Pomeroy <[EMAIL PROTECTED]> wrote:
>Wanted - a free DOS-based encryption program which is small, fast,
> strong and friendly
>
>Explanation
>
>I want recommendations of encryption software to store small amounts of
>sensitive information (up to 30kbytes) for my own use - i.e. I encrypt it,
>and I decrypt it. Since I plan to carry the encrypted datafile and
>encryption software on floppy disk and use it on various PCs (some of which
>may not be owned by me), I plan to use it from DOS (don't want to load it on
>PC, don't want any temporary decrypted data left on the PC's hard-disk). The
>PCs will be running DOS, Win95/8, or WinNT. Typically, I'd run it from the
>floppy in a DOS-Window.
>
>The mandatory requirements therefore are:
>
> [List of requirments snipped]
>
>-----------== Posted via Deja News, The Discussion Network ==----------
>http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
The following code was thrown together in a 15 minutes bout of anger
after Norway accepted the latest Wassenaar list of controlled goods.
I was just trying to find out how fast and easy it is to throw together
something that will be considered unexportable.
But as it can be usefull to you (seems to meet all requirements)
, and I think it should suit your needs. I will happily release it.
Some words of caution:
1) Do not encrypt more than 1 file with any password, as RC4 will XOR
both files with the same pseudorandom stream ( Ask Microsoft for
details on this weakness ( .pwl ) )
2) The algorthim has not been verified against Test vectors ( there is
limits to how much you can do in 15 minutes )
3) The .exe file is compiled on Borland C++ (16bits), and will definetly
fail before filesizes gets anywhere near 600 kb.
4) And yes, I know, I should have some random IV, but see 1) & 3)
This is my recomendation as a first improvement.
5) RC4 may or may not be copyrighted in the country where you abide,
it is your own responsibilty to make sure that this copyright is
not violated.
Good luck, frank
/////////////////////////////////////////////////////////////////////////////
/* Released on a GNU license, ha Wassenaar !!! */
/* Written by Frank A. Stevenson */
#include <stdio.h>
#include <string.h>
unsigned char S[256];
unsigned char key[256];
void RC4Setup( unsigned char* key, int keysize ) {
int i,j,tmp;
for( i=0 ; i < 256 ; i++ ) S[i]=i;
j = 0;
for( i=0 ; i < 256 ; i++ ) {
j = ( j + S[i] + key[ i % keysize ] ) & 0x0ff;
tmp = S[i]; S[i] = S[j]; S[j] = tmp;
}
}
void RC4Crypt( unsigned char* pData , long numbytes ) {
long i;
int j,t,tmp;
j = 0;
for( i = 0 ; i < numbytes ; i++ ) {
tmp = ( i+1 ) & 0x0ff;
j = ( j + S[ tmp ] ) & 0x0ff;
t = S[tmp];
S[tmp] = S[j];
S[j] = t;
t = ( S[j] + S[tmp] ) & 0x0ff;
pData[i] ^= S[t];
}
}
main( int argc, char* argv[] ) {
FILE *fd;
long size;
unsigned char* pData;
unsigned char ch;
int i;
if( argc < 2 ) {
printf( "Usage: %s filename (key)\n", argv[0] );
exit( 0 );
}
if( argc == 3 ) {
RC4Setup( argv[2] , strlen(argv[2]) );
} else {
pData = key;
for( i = 0 ; i < 256 ; i++ ) {
ch = fgetc( stdin );
if( ch ) {
if( ch == 0x0a ) {
*pData = 0;
break;
}
*pData++ = ch;
}
}
RC4Setup( key , strlen( key ) );
}
fd = fopen( argv[1], "rb" );
if( fd == NULL ) {
printf( "Error: can't read %s\n", argv[1] );
exit( 0 );
}
fseek( fd, 0L, SEEK_END );
size = ftell( fd );
fseek( fd, 0L, SEEK_SET );
pData = (unsigned char*)malloc( size );
if( pData == NULL ) {
printf( "Error: Out of memory\n" );
fclose( fd );
exit( 0 );
}
fread( pData, size, 1 , fd );
fclose( fd );
RC4Crypt( pData, size );
fd = fopen( argv[1], "wb" );
if( fd == NULL ) {
printf( "Error: can't write %s\n", argv[1] );
exit( 0 );
}
fwrite( pData, size, 1 , fd );
fclose( fd );
return( 0 );
}
///////////////////////////////////////////////////////////////////////////////////
------------------------------
From: "Michal Brzozowski" <[EMAIL PROTECTED]>
Subject: Re: newbie question
Date: Tue, 30 Mar 1999 08:57:54 GMT
Kryspin Ziemski wrote in message <[EMAIL PROTECTED]>...
>fine still does not change the fact that ..
>hey you're polish, cool.. just noticed the pl in the ip address
yep! i am :)
>well fine assuming that you have the recipient's public key, you can find
>his private key
>by simply debugging the code and looking for the part that actually
>manipulates that public key
>to find the private key. how do you prevent this dilema which should occur
>because there is no way to hide the actual function from being observed on
>the byte level.
>
you can't easily find recipient's private key, because there is no
conversion
from public key to private key during decryption.
there are (afaik) algorithms to find the private key, but it takes a LONG
time,
to find one (you have to find prime factors of huge number, or something).
and there's no need to do byte-level debugging, because source code
for both encrypting and decrypting programs are publicly available. :-)
Michal Brzozowski
[EMAIL PROTECTED]
------------------------------
From: Dave Knapp <[EMAIL PROTECTED]>
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Tue, 30 Mar 1999 09:16:45 GMT
"R. Knauer" wrote:
>
> Calculate the frequency of particles that are within +- 5% of the mean
> in n steps for the uniform Bernoulli process. The mean for the random
> walk is zero, namely the origin. And the extremes are at +- n.
Your great argument is based on _this_? That correlated measurements
don't give the same answer as uncorrelated measurements?
So you are claiming that true random numbers are correlated how?
-- Dave
------------------------------
From: [EMAIL PROTECTED] (Serge Vaudenay)
Subject: Re: Prof Shamir, was: Live from the Second AES Conference
Date: 30 Mar 1999 10:19:47 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Reuben Sumner) writes:
|> On Tue, 23 Mar 1999 01:19:57 GMT,
|> [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
|> > The first paper was presented by Adi Shamir. I don't know whether
|> > Shamir is a teacher, but if he is then he must be a very good one
|> > indeed. First he explained about Paul Kocher's power attacks
|>
|> Indeed I can assure you that Prof Shamir is an excellent teacher.
|> I have taken two one semester courses in algorithms taught by him
|> and am now taking the second of his one semester courses in
|> cryptography. He is faculty at the Weizmann Institute of Science
|> together with Professors Oded Goldreich, Shafi Goldwasser,
|> and Moni Naor. All very accomplished cryptographers, together
|> with other fields of research.
|>
This reminds me the chair of the session who was supposed to introduce him by
"if you don't know Adi Shamir, please have a look to your badge in order to
check that you are in the right conference".
Serge Vaudenay
------------------------------
From: "colgates" <[EMAIL PROTECTED]>
Subject: Does anyone know how to solve vigenere and tranposition cipher?
Date: Tue, 30 Mar 1999 20:44:00 +1000
Hi I need help from anyone who know how to decipher tranposition and
vigenere/Beaufort cipher.
I got a ciphertext but no sure how to decipher them. Please help. Thanks.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: newbie question
Date: Tue, 30 Mar 1999 10:10:09 GMT
Kryspin Ziemski wrote:
> ... So all the recipient has to do is check somehow if this message
> was encrypted just for him and then decrypt it using his private key. Do we
> know anything about the mathematical relation between the two numbers? Is
> the general formula given out or is that all secret?
Public-key encryption is described in almost every book on cryptology.
RSA, a typical scheme, involves picking two very large primes randomly
and secretly, choosing some encryption- and decryption-power numbers
with certain properties relative to those primes, then publishing the
encryption power and product of the two primes as the public key,
keeping the decryption power secret as the private key. The original
two primes are discarded and forgotten. So far as is known, there is
no reliable, effective way to compute the private key from the public
key.
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: fast enough (sequel)
Date: 30 Mar 1999 13:38:10 GMT
According to <[EMAIL PROTECTED]>:
> Why on earth should the algorithm work at 50mb/s on a PC? Unless you have
> specialized hardward or something...
You may want to encipher all network traffic on a 100baseT card (fairly
common these days) and not spending your whole cpu on this. On true
multitasking systems, the cpu may perform other tasks while doing some
I/O.
Moreover, it seems that network bandwidth grows faster these days than
cpu power.
--Thomas Pornin
------------------------------
From: Peter Gunn <[EMAIL PROTECTED]>
Subject: Re: newbie question
Date: Tue, 30 Mar 1999 15:07:51 +0100
Or check out some of Barwood's stuff on elliptic curves at
http://www.geocities.com/SiliconValley/Network/2811/ec/ec_faq.htm
or
http://ds.dial.pipex.com/george.barwood/
basically in Pegwit V8.7 (GF(2^255)) he provides 3 operations (which
Im drastically simplifying here)...
F=fixed point on curve
R=pseudo random number
S=session key
Ak=sender's private key
AP=sender's public key
Bk=recipient's private key
BP=recipient's public key
1) Computes public keys from private keys
AP = F*Ak
where F is a fixed curve point, and Ak is a secret key generated
by hashing (*lots*) the pass phrase (SHA-1 variant). The public key is
represented as a 256bit unsigned integer (output as 64 hex chars).
(obviously BP=F*Bk)
2) Encrypt file using recipients public key BP
BP is read in as a 64char hex... then converted to a 256bit integer.
R=BP+PRNG+digest of file (SHA-1)
(basically a PRNG.. note: '+' means 'combines')
M=F*R
S=R*BP
He then writes M out as part of the encoded file, followed by the
plaintext file encrypted using the session key S (using SQUARE).
3) Decryption of an encrypted file using recipients secret key Bk
Read in M from encrypted file...
since M=F*R
=> M*Bk=(F*R)*Bk
=> M*Bk=R*(F*Bk)
=> M*Bk=R*BP
=> M*Bk=S
=> S=M*Bk
Decipher remainder of file with S (using SQUARE) and output as plaintext.
DISCLAIMER: I discovered cryptography last Monday, and havent done
any maths for years, so I hope this is right :-)
"Douglas A. Gwyn" wrote:
> Kryspin Ziemski wrote:
> > ... So all the recipient has to do is check somehow if this message
> > was encrypted just for him and then decrypt it using his private key. Do we
> > know anything about the mathematical relation between the two numbers? Is
> > the general formula given out or is that all secret?
>
> Public-key encryption is described in almost every book on cryptology.
> RSA, a typical scheme, involves picking two very large primes randomly
> and secretly, choosing some encryption- and decryption-power numbers
> with certain properties relative to those primes, then publishing the
> encryption power and product of the two primes as the public key,
> keeping the decryption power secret as the private key. The original
> two primes are discarded and forgotten. So far as is known, there is
> no reliable, effective way to compute the private key from the public
> key.
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: How to avoid double random numbers?
Date: 30 Mar 1999 09:15:04 -0500
In article <[EMAIL PROTECTED]>,
Henrik Zawischa <[EMAIL PROTECTED]> wrote:
>Hi there,
>
>I'm rather new to the stuff, so this might be a really simple question
>to answer. Nonetheless I'd like to know.
>
>in Bruce Schneiers's Applied Cryptography there is a chapter about
>secure elections. On Page 126 it says:
>"Each message also contains a randomly generated identification number,
>large enough to avoid duplicates with other voters"
>What is large enogh? Isn't the meaning of randomness that you can't
>predict the numbers, i.e. you can't predict that you won't get doubles?
>I mean, there might be just e tiny chance, neglectable in other cases.
>But if it happended an I found my ID-number on the list of votes for the
>opponets party, I'd be rather displeased. I'd think, that would spoil
>the whole effort.
As in most things statistical, you can't get absolute certainty out
of random numbers. However, if you are willing to define a stipulated
risk level you're willing to take -- for example, that there be
no more than one chance in ten (or one chance in a billion) of
duplicate entries -- then you can calculate how large you need the
numbers to be, given a particular voter pool.
If the probability were low enough -- one in a million, for instance --
I'd be more inclined to suspect (and prosecute) electoral fraud than
a conspiracy of the random numbers. We *KNOW* that electoral fraud
is a serious risk.
-kitten
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: newbie question
Date: 30 Mar 1999 09:18:23 -0500
In article <[EMAIL PROTECTED]>,
Kryspin Ziemski <[EMAIL PROTECTED]> wrote:
>fine still does not change the fact that ..
>hey you're polish, cool.. just noticed the pl in the ip address
>well fine assuming that you have the recipient's public key, you can find
>his private key
>by simply debugging the code and looking for the part that actually
>manipulates that public key
>to find the private key. how do you prevent this dilema which should occur
>because there is no way to hide the actual function from being observed on
>the byte level.
Because the problem is computationally intractable.
The private key might be the two factors of a number N, while
the public key might be the product N itself. If N is large enough
(thousands of digits), then factoring N would take hundreds and
hundreds of years. And the (public) encryption process doesn't
require that you know the factors, only the number N.
-kitten
>
>Michal Brzozowski <[EMAIL PROTECTED]> wrote in message
>news:6w%L2.33449$[EMAIL PROTECTED]...
>>
>> Kryspin Ziemski wrote in message <[EMAIL PROTECTED]>...
>> >My understanding of public key cryptography is that each person is
>assigned
>> >to keys one private and one public. the sender encrypts the message with
>> >his private key and then sends the message to the reader.
>> >the reader gets the sender's public key from a directory and then
>converts
>> >the public key to the private key using some mathematical relation and
>> >decrypts the message using the private key. If this is how public key
>> >cryptography works what stops me obtaining the sender's public key and
>> >debugging the program to find the code that works on the public key to
>> >convert it to the private key which i'm assuming is done locally on the
>> >computer.
>>
>>
>> Wrong. Sender encrypts message with receipient's public key,
>> and receipient decrypts it using his (receipient's) private key,
>> Nobody (except owner) has access to private key.
>>
>> Michal Brzozowski
>> [EMAIL PROTECTED]
>>
>>
>>
>
>
------------------------------
From: [EMAIL PROTECTED] (Herman Rubin)
Subject: Re: True Randomness & The Law Of Large Numbers
Date: 30 Mar 1999 10:14:12 -0500
In article <[EMAIL PROTECTED]>,
R. Knauer <[EMAIL PROTECTED]> wrote:
................
>You build a TRNG and output an n-bit sequence. According to what is
>being claimed, you cannot submit that sequence to statistical tests to
>determine if the TRNG is either truly random or not truly random. The
>best that you can hope for is that such statistical tests will give
>you a diagnostic warning that the TRNG *might* be random or
>non-random.
I suggest you try to understand the terms. The result of a physical
process is "truly random", in that it has a probability distribution.
This does not mean that it has the particular independence and
distribution properties which you seem to think can be assumed;
the actual probability distribution is unknowable, and it is not of
the simple parametric type usually posited. It may or may not be
so for practical purposes.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
[EMAIL PROTECTED] Phone: (765)494-6054 FAX: (765)494-0558
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: sci.math.symbolic
Subject: Re: ---- Two very easy secret key Cryptosystems
Date: Tue, 30 Mar 1999 15:00:29 GMT
In article <[EMAIL PROTECTED]>,
kctang8 <[EMAIL PROTECTED]> wrote:
> Dear all,
>
> --------Two very easy secret key Cryptosystems-----------------
>
> a,b,c and e denote positive integers.
>
> Please crack the following systems:
>
> (Q1)
> plaintext: [a,b,c]
> encryption: choose a secret number e,
> cyphertext = [A,B,C] = [e*a, e*b, e*c]
> decryption: the partner know e,
> get plaintext [a,b,c]= [A/e, B/e, C/e]
>
Part of the game crypto peole play is to assume the
enemy has a copy of your program and possibly a plain
text example with the corresponding encrypted data.
So if that is true the enemy would easily determine e
from "A/a" So it would be considered very weak. If you want
to look at a stronger system take a look at the source
code I have in SCOTT16U.ZIP you can get it world wide also
while your getting it take a look at my website for the
use of compression for ascii messages to increase the
entropy per bit of message. Your second question is
not that much different than the first. But it seems
like people all most universeally come up with the same
ideas when they first get an interest in encyryption.
But most people quickly get lead astray in this field
since governments like to keep people misinformed so
that they can read everything you send on the net.
Take Care
David Scott
> (Q2)
> Now n denote a positive integer of around 310 digits.
> a,b,c and e denote positive integers less than n.
> e and n are relatively prime.
>
> plaintext: [a,b,c] and n
> encryption: choose a secret number e,
> cyphertext =
> [A,B,C] = [e*a mod n , e*b mod n , e*c mod n]
> decryption: the partner know e, he compute inv = e^(-1) mod n
> get plaintext
> [a,b,c]= [A*inv mod n, B*inv mod n, C*inv mod n]
>
> Thanks, kctang8
>
> P.S. Forgive me if these questions are trivial, but this is my
> best efforts at the moment.
>
>
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Albert P. Belle Isle)
Crossposted-To: comp.security.misc
Subject: Re: Wanted: free small DOS Encryption program
Date: Tue, 30 Mar 1999 14:43:31 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 30 Mar 1999 06:20:20 GMT, Milton Pomeroy
<[EMAIL PROTECTED]> wrote:
>Wanted - a free DOS-based encryption program which is small, fast,
> strong and friendly
>
>Explanation
>
>I want recommendations of encryption software to store small amounts of
>sensitive information (up to 30kbytes) for my own use - i.e. I encrypt it,
>and I decrypt it. Since I plan to carry the encrypted datafile and
>encryption software on floppy disk and use it on various PCs (some of which
>may not be owned by me), I plan to use it from DOS (don't want to load it on
>PC, don't want any temporary decrypted data left on the PC's hard-disk). The
>PCs will be running DOS, Win95/8, or WinNT. Typically, I'd run it from the
>floppy in a DOS-Window.
>
>The mandatory requirements therefore are:
>
> (1) runs from DOS (and DOS-prompt in a DOS-Window)
>
> (2) freeware/public domain
>
> (3) be accessible to someone (like me in Australia) who is outside USA
> (no export restrictions)
>
> (4) works in 450kBytes or less of RAM
>
> (5) already compiled i.e. an EXE or COM version is available
> (I don't want the uncertainty of my doing a poor compilation
> resulting in a poor security implementation)
>
> (6) EXE or COM file must be small - less than say 80kbytes
> (if it's large, like PGP for DOS at around 400kbytes, it takes
> over 10sec to load from floppy-drive)
>
> (7) fast execution - less than say 5 seconds to load from floppy
> and complete encryption/decryption of up to 30kBytes of data
> on a 486-66
>
> (8) can run from a floppy with any temporary files being stored on the
> floppy
>
> (9) strong (at least 80-bit-key strength)
>
> (10) user-ready incl enough documentation to be used directly without doing
> programming, compilation etc
>
> (11) algorithm has some pedigree - i.e. has widespread degree of respect
> in the crypto community
>
> (12) implementation (inc. compilation) should have some pedigree - i.e. has
> widespread degree of respec
>
>-----------== Posted via Deja News, The Discussion Network ==----------
>http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Mr. Pomeroy:
Since our products are neither free nor exportable (except to Canada),
all I can offer is some advice.
Do not assume that "running in a DOS window" won't leave plaintext,
passphrases or keying materials "on the hard disk."
A "DOS Window" is a Virtual Machine run under Windows, with all the
"help" from its virtual memory manager that that implies: i.e. use of
the swapfile.
Assuming that you verify the cipher implementation with independent
tets vectors; assuming that you verify the overwriting of the
plaintext on the floppy and are certain that the floppy will never be
subject to laboratory attacks (which are pretty easy with floppies, as
opposed to high-density hard drives); and assuming that you verify the
absence of covert channels in the implementation that leak the key
into/onto the ciphertext file or elsewhere on your floppy, then
running under DOS - NOT in a DOS Window - should meet your
requirements.
Good luck.
Albert P. BELLE ISLE
Cerberus Systems, Inc.
================================================
ENCRYPTION SOFTWARE
with Forensic Software Countermeasures
http://www.cerberus-sys.com/~infosec/
================================================
------------------------------
** 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
******************************
