Cryptography-Digest Digest #742, Volume #13 Sat, 24 Feb 01 07:13:01 EST
Contents:
Re: Encrypted Email for Business Documents ("Joseph Ashwood")
CipherText enhanced ("Prichard, Chuck")
Re: Really big numbers in C (Taylor Francis)
ECC implementation (Benjamin Goldberg)
Re: Freq analysis of a possible cyphertext. ("Eric Chowanski")
Re: Random numbers from your sound card ("Eric Chowanski")
Re: Really big numbers in C (Paul Schlyter)
Re: Really big numbers in C (Paul Schlyter)
Life cycle of keys (Mok-Kong Shen)
Re: Random number encryption (Tim Tyler)
Re: Simple, possibly flawed, stream cipher ("Henrick Hellström")
----------------------------------------------------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Encrypted Email for Business Documents
Date: Fri, 23 Feb 2001 16:56:58 -0800
Crossposted-To: alt.sources.crypto,talk.politics.crypto
[send to both newsgroups and personal e-mail]
I've taken a cursory look at your idea, and there are several areas in which
it seems to be lacking.
First why this is not a good idea. There is nothing special about business
documents as opposed to every other type of document that is already
encrypted (much like business documents are) using either PGP or similar
technology.
The fact that you do not encrypt the message just the attachments is a
distinct disadvantage of your system as opposed to every other system of
it's type in general use.
By binding yourself exclusively to Rijndael (which by the way is NOT
officially AES yet, it has merely been tapped as the one that will be
renamed AES when the FIPS comes out) is a problem.
You fail completely to address how the public keys are stored, what format
they are to be in, etc. Just an example of 2 completely incompatible formats
are X.509 and PGP.
The concept the you have dubbed "signature" this "signature" is far from a
real digital signature. I'd suggest you read up on what exactly a digital
signature is, and take a look at technology like PSS and DSA before
attempting to create your own. Then again I'd suggest that you avoid the
problem all together and use DSA or PSS. A digital signature certifies the
SENDER not the recipient, your current idea (encrypting the MD5 hash to the
recipient) is worse than useless because you identify it as a signature.
By exposing the signature outside of the encrypted block you subject the
signature to basic attacks, and fraud while protecting the payload. There
have been several attacks on signatures of similar form (reference PKCS 1
version 1).
Sending the file name is at best idiotic, filenames are designed so that
they tell the reader something about what is being sent (reference every vbs
script that took advantage of this), by sending a second copy of this you
are only forcing the leakage of information.
You fail to specifiy what chaining mode to use Rijndael in, you fail to
specify where the IV is to be placed, you fail to specify which mode RSA is
to b used in to encrypt the key.
Including the sends and recipients e-mail addresses is foolish, just place
the public keys and avoid the necessary look up who it is.
About your reference implementation: NO ONE WILL RUN IT IF YOU ONLY
DISTRIBUTE THE EXECUTABLE, people who run real operating systems (aka UNIX
OpenVMS, linux, etc) will never be able to run it. I even have a WinNT box
that it will never run on.
What I'd suggest is that you do one of two things; learn something about
computer security especially encryption, or not bother people who have some
semblance of a clue about computer security and encryption with your less
than intelligent attempts to compromise the security of business.
Joe
"Peter Harrison" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Greetings,
>
> I am developing a Open Source project to send business documents
> across the Internet. Part of the system is a secure transmission
> system based on email.
>
> I am trying to solve some of the issues around what makes encryption
> hard to use right now. For example, I want to imbed email addresses
> of the sender and recipient. This will be used to look up servers to
> obtain public keys (if a public key has not already been obtained for
> the email address).
>
> The idea is to make the encryption as invisible as possible. This way
> I can make it easy to send business documents - such as invoices -
> across the internet in reasonable security.
>
> I am inviting everyone to take a look at my (rough) spec and comment
>
> See the spec at: http://www.devcentre.org/email_spec.htm\
>
> Comments are welcome to [EMAIL PROTECTED]
>
> Regards,
>
> Peter Harrison
>
------------------------------
From: "Prichard, Chuck" <[EMAIL PROTECTED]>
Subject: CipherText enhanced
Date: Sat, 24 Feb 2001 04:22:08 GMT
The somewhat controversial patent-pending ASCII cipher has been
implemented in Visual Basic.
The new implementation as well as those in Perl, Javascript and Java now
support the use of user-friendly alpha-numeric keys and an offset in PGP
mode. This represents a significant improvement in the algorithm in PGP
mode, making the algorithm somewhat useful in this mode for niche
applications that require transfer using the default HTTP protocol, or
the 7-bit ASCII domain. PGP mode uses a single pass to XOR the message
with a key element. This CipherText mode has been demonstrated
successfully for CGI querystring encryption. CipherText is not a blocking
cipher, and it can cipher a large number of short strings rapidly.
Potential uses exist in thread authentication schemes that will prevent
user impersonation without client-side cookies. Improved content security
is possible using CipherText to encrypt querystring information. An easy
to use E-mail form has also been demonstrated in a simple email
encryption demonstration.
An advanced CipherText ASCII compatible mode is also useful in which a
second cipher pass applies a modified key and somewhat random mask
values. This mode provides greater message security in applications that
benefit from use of numeric (restricted domain) keys. This cipher mode
has also proven useful for CGI query string encryption.
For more information, or to obtain an implementation for testing contact:
C. Prichard
[EMAIL PROTECTED]
http://greentv.crosswalkcentral.com (PWS query string encryption
demonstration.)
Refer to "C Programmer's Guide to Serial Communications" for information
about the true ASCII character set and serial transmission protocols.
------------------------------
From: Taylor Francis <[EMAIL PROTECTED]>
Subject: Re: Really big numbers in C
Date: Fri, 23 Feb 2001 23:13:18 -0600
I'm using Visual C++ 6.0 but I don't know windows programming...
everything i do runs under dos.
Bob Day wrote:
>
> Taylor Francis wrote:
>
> > Anyone know how to handle really bug numbers in C? I'm talking
> > 1024-4096 bit numbers...my compiler only handles 64 bit (that I can
> > tell...)
>
> Windows or Unix-Linux?
>
> -- Bob Day
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: ECC implementation
Date: Sat, 24 Feb 2001 06:01:55 GMT
This is a multi-part message in MIME format.
==============A19AB6581AED1FE574336BB5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I'm currently tring to implement ECC in java, using BigIntegers.
I'll readily admit that I don't understand elliptic curves as well as
I'd like to, so I'm almost certain that there are mistakes in various
places throughout the code. Also, I haven't implemented everything yet.
Could someone check and tell me what errors there are? I'm just
concerned about the math, not about minor typoes I may have made (nor
about the fact that I'm missing constructors...)
--
A solution in hand is worth two in the book.
==============A19AB6581AED1FE574336BB5
Content-Type: text/plain; charset=us-ascii; name="ecc.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="ecc.txt"
final class Curve {
/* y^2 = x^3 + a*x^2 + b */
public final BigInteger p, a, b;
}
final class Point {
public static final Point O = new Point();
public final BigInteger x, y;
private Point() { x = y = null; }
public Point(BigInteger x, BigInteger y) {
this.x = x; this.y = y;
}
public Point negate(Curve c) {
return new Point(x, c.p.subtract(y) );
}
public Point add(Point p, Curve c) {
if( x.equals(p.x) && y.add(p.y).equals(c.p) )
return O;
if( this == O ) return p;
if( p == O ) return this;
if( x.equals(p.x) && y.equals(p.y) )
return double(c);
BigInteger dy = y.subtract(p.y);
BigInteger dxinv = x.subtract(p.x).modInverse(c.p);
BigInteger s = dy.multiply(dxinv).mod(c.p);
BigInteger xx = s.pow(2).subtract(x).subtract(p.x);
BigInteger yy = s.multiply(x.subtract(xx)).subtract(y);
return new Point(xx.mod(c.p), yy.mod(c.p));
}
public Point subtract(Point p, Curve c) {
return add(p.negate(),c);
}
private final static BigInteger TWO = BigInteger.valueOf(2);
private final static BigInteger THREE = BigInteger.valueOf(3);
public Point double(Curve c) {
BigInteger dx = THREE.multiply(x).pow(2).add(c.a);
BigInteger dyinv = TWO.multiply(y).modInv(c.p);
BigInteger s = dx.multiply(dyinv).mod(c.p);
BigInteger xx = s.pow(2).subtract(TWO.multiply(x));
BigInteger yy = s.multiply(x.subtract(xx)).subtract(y);
return new Point(xx.mod(c.p), yy.mod(c.p));
}
public Point multiply(BigInteger k, Curve c) {
int bits = k.bitLength();
Point a = this, b = O;
for( int i = 0; i < bits; ++i ) {
if( k.testbit(i) )
b = b.add(a,c);
a = a.double(c);
}
return y;
}
}
final class PublicKey {
public final Point P;
public final Point Q; // Q = a*P
public Point[] encrypt(Point pt, Curve E, Random rr) {
BigInteger r = new BigInteger(E.p.bitLength(),rr);
BigIngeger rQ = Q.multiply(r,E);
return new Point[] { rQ, rQ.add(pt,E) };
}
}
final class PrivateKey {
public final BigInteger a;
public Point decrypt(Point ct[], Curve E) {
BigInteger rP = ct[0];
BigIngeger rQ = rP.multiply(a,E);
return ct[1].subtract(rQ);
}
}
==============A19AB6581AED1FE574336BB5==
------------------------------
From: "Eric Chowanski" <[EMAIL PROTECTED]>
Subject: Re: Freq analysis of a possible cyphertext.
Date: Sat, 24 Feb 2001 06:56:45 GMT
Ben
The true beauty of truley random is that sometimes it does not look random
at all! ie is Yatzee (5 of one number in the game of the same name) random
to anyone's eye? How about heads, tails, heads tails? But a fair coin will
produce it. In fact, new research about large numbers of a fair coin toss
or random walks actually indicate drift away from the mean. Weird S___!
> So I'm left with a dilemma. At this point I think it's just random
>garbage. But there there appear to be patterns in this possible cyphertext.
>Why would moron spammers bother to put vaguely textual patterns in random
>spam? Am I tilting at a windmill here? Is it worth going back and doing
>a digraph and trigraph frequency analysis? Any other opinions?
E
------------------------------
From: "Eric Chowanski" <[EMAIL PROTECTED]>
Subject: Re: Random numbers from your sound card
Date: Sat, 24 Feb 2001 07:18:51 GMT
I just read this months Scientific American - and saw the design for a duel
Geiger counter / cosmic ray counter. Ionising particles from either source
are as random as you get. The data sets can become large fairly quickly and
the whole thing costs about $50.
Used in conjunction with the fish bowl might make for even more dramatic
results. 1,000 volts, fish, and a computer...
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Really big numbers in C
Date: 24 Feb 2001 09:09:59 +0100
In article <[EMAIL PROTECTED]>,
Taylor Francis <[EMAIL PROTECTED]> wrote:
> Bob Day wrote:
>
>> Taylor Francis wrote:
>>
>>> Anyone know how to handle really bug numbers in C? I'm talking
>>> 1024-4096 bit numbers...my compiler only handles 64 bit (that I can
>>> tell...)
>>
>> Windows or Unix-Linux?
>
> I'm using Visual C++ 6.0 but I don't know windows programming...
> everything i do runs under dos.
Then you cannot be using Visual C++ 6.0 but must be using Visual
C++ 1.52 or earlier, since this was the last version of Visual C++
which could generate DOS programs.
If you use Visual C++ 6.0, then your so-called "DOS program" is
really a Windows-32 Console Application. If you don't believe be,
try to run your "DOS program" on a real DOS machine, with no
Windows....
Superficially, Win-32 Console Applications may look like a "DOS
program", but "under the hood" there's a big difference: it's a
32-bit program with the entire Win32 API available. So your
"DOS program" can open new windows, call DLL's, and do a lot of
other stuff which a real DOS program cannot do.
Ironically, if you actually did go back to Visual C++ 1.52 or
earlier (including Microsoft C ver 6 or 7), you would get access
to somewhat greater precision than 64 bits, since these compilers
did support "long double" as 80-bit floating-point numbers.
IN the 32-bit versions of the MSVC++ compilers this supportr was
removed, and "long double" is there treated as synonymous with a plain
"double".
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Really big numbers in C
Date: 24 Feb 2001 09:07:13 +0100
In article <[EMAIL PROTECTED]>,
Bob Day <[EMAIL PROTECTED]> wrote:
> Taylor Francis wrote:
>
>> Anyone know how to handle really bug numbers in C? I'm talking
>> 1024-4096 bit numbers...my compiler only handles 64 bit (that I can
>> tell...)
>
> Windows or Unix-Linux?
I wasn't aware that "Windows" and "Unix-Linux" were C compilers... <g>
Perhaps he ran gcc? Runs on both Windows, Linux and many other Unices...
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Life cycle of keys
Date: Sat, 24 Feb 2001 10:54:50 +0100
In a recent thread Douglas Gwyn has proposed to dynamically
transmit new keys for block encryption, leading to much
interesting theoretical discussions.
Practically, variability is always of benefit in principle
in my humble conviction. Anyway, I suppose it wouldn't hurt,
if appropriately introduced. In fact, one generally changes
session keys for evident reasons, commonly via the public
key mechanism.
It is thus of interest to ask a practical question, which
for concretness I like to formulate thus: How many MB can
one safely encrypt with AES and a single (random) key of
128 bits?
A variant of the question involves key management, which,
again for concreteness, I suggest to consider a fairly
primitive one that I described previously as follows: One
has a (random) master key which generates for each year
the parameters and the seed of a statistically good PRNG.
Each such PRNG for the year generates 12 PRNGs for the
months. Similarly one gets a PRNG for each day of the
month which generates a pseudo-random number as the key
for each session of the day. We assume that there are 10
sessions per day. The question is then: How many MB one
can safely encrypt in each session? Note that here only
the master key is random, while the keys used for encryption
are somehow related due to the method of their derivation.
Naturally, only approximate answers could at best be
expected. However, one should also have some idea of the
actual applicatiom environment, if there can be any
concrete answers at all. For that I suggest to consider the
following: No human errors ever occur. Diverse attack
modes, e.g. known plaintext, can be considered, leading
to corresponding answers. The secret of the messages need
to be maintained only for a duration of one year. And
finally the opponent: The combined entire resources of
the topmost (most capable) one dozen angencies of the
(democratic and non-democratic) world.
Thanks for your comments and discussions in advance.
(Additional, practically reasonable, conditions could be
added, if such are needed for enabling concrete answers.)
M. K. Shen
============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Random number encryption
Reply-To: [EMAIL PROTECTED]
Date: Sat, 24 Feb 2001 11:12:19 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: John Savard wrote:
:> Taylor Francis <[EMAIL PROTECTED]> wrote, in part:
:> >Can someone tell me why random number encryption isn't (seemingly) used
:> >much?
:>
:> It's a big hassle getting all that key from point A to point B in
:> advance.
: Indeed, if you could deliver N bits of key securely, why not
: just use that capability to send the N-bit message immediately.
In the cases where it is used, the answers to that question can include:
* delivery time - the key may be transmitted before the message is
known.
* delivery speed - it may be important to transmit the message rapidly -
while delivery of the key securely can be done at
leisure.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: "Henrick Hellström" <[EMAIL PROTECTED]>
Subject: Re: Simple, possibly flawed, stream cipher
Date: Sat, 24 Feb 2001 12:40:20 +0100
It feels a bit comforting to learn that not only I, but also David Wagner,
made a mistake attempting to attack this cipher. ;-)
Self-synchronizing does not work the way David Wagner describes it. Since x
is always initialized to 1, state[0] is always incremented. This means that
the value of state[0] is predetermined by it's initial value and the
position in the stream - it will never be synchronized. Furthermore, the
value of state[1] is a function of the initial values of state[0] and
state[1] and of the position in the stream. If the SBox is carefully
selected, e.g. so that (SBox[s] and 2) is equal to zero if s is even and
equal to 2 if s is odd, then the value of state[1] will not synchronize even
if the value of State[0] is guessed correctly.
In fact, if the SBox is equal to e.g. the identity mapping, then it is not
that hard to prove that none of the internal states will ever syncronize -
the value of state will then be equal to it's initial value each time
position is congruent to zero modulo 65536.
--
Henrick Hellström [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
"David Wagner" <[EMAIL PROTECTED]> skrev i meddelandet
news:9773on$lrl$[EMAIL PROTECTED]...
> Benjamin Goldberg wrote:
> >uint8 state[8] = { key };
> >for( i = 0, x = 1; i < 8; ++i )
> > x ^= sbox[ state[i] += (x>>i) & 1 ];
> >keystreambit := x;
>
> Ahh, here's a totally deadly attack. It is based on a
> self-synchronization property combined with a total lack of avalanche
> from state[i] to state[i-1].
>
> Let S denote the state before the state-update function, and S' denote
> the state afterwards. Suppose I start with a guess G at the state, and
> run the state-update function on G to get G'. Note that if G agrees
> with S in the first N positions, then G' will necessarily agree with
> S' in the first N positions, too. Moreover, with probability 1/256,
> we will have G'[N] = S'[N]. In other words, if G agrees with S in
> the first N positions, then G agrees with S in the first N positions
> (255/256 of the time) or the first N+1 positions (1/256 of the time).
> This is a self-synchronization property.
>
> Imagine if I just start with a completely random initial guess G_0 and
> apply the state-update function to it to get a sequence G_0,G_1,G_2,...
> After about 256 iterations, I expect G_i to agree with S_i in about 1
> position, and once they agree in the first position, they'll agree in
> that position forever. After 256*k iterations, they'll agree in about
> k positions.
>
> So, pick a random key. Then, after about 4000 or so outputs, the
> keystream will be completely independent of the key value!
>
> This means that the proposal appears to be completely insecure, if I
> did not make any mistakes in my analysis.
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
