Cryptography-Digest Digest #951, Volume #13 Tue, 20 Mar 01 13:13:00 EST
Contents:
Re: What do we mean when we say a cipher is broken? (John Myre)
How do you test a Blowfish encryption routine? ("Ace Bezerka")
What the Hell...Here's what my system can do at it's best... (Keill Randor -
([EMAIL PROTECTED]))
Re: Is SHA-1 Broken? (Jim Steuert)
Re: Codes that use *numbers* for keys (Mok-Kong Shen)
Re: FIPS 140-1 does not adress eavesdropping (Frank Gerlach)
Re: NSA in the news on CNN (Ichinin)
Re: Idea - (LONG) (amateur)
Re: How do you test a Blowfish encryption routine? (Frank Gerlach)
Strong Primes (Peter Engehausen)
Re: What the Hell...Here's what my system can do at it's best... (SCOTT19U.ZIP_GUY)
Re: How do you test a Blowfish encryption routine? (Frank Gerlach)
----------------------------------------------------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: What do we mean when we say a cipher is broken?
Date: Tue, 20 Mar 2001 09:31:33 -0700
(More thoughts on terminology)
If we use "broken" only when a cipher is insecure in actual
practice, we need another term for "not useless but not
exactly performing to spec, either". The phrase "academic
break" has been used, although it doesn't seem to be popular.
Perhaps this is due to the negative connotations for academia,
or maybe just because it's clumsy: who wants to say
"academically broken"?.
Perhaps we could say, for example, "flawed". "Limited"?
Doubtless there are better possibilities...
The same problem exists for "secure". In that case, I think
I'd rather use the academic point of view. That is, a cipher
is "secure" only when not even certificational attacks exist.
Thus, for me, many ciphers are neither secure nor broken:
flaws exist but cannot be practically exploited. Yet.
Actually what I'd really like is a scheme for describing
ciphers in a much more comprehensive way. The different
types of vulnerabilities and the attacks that exploit them
are not equivalent, and therefore a particular cipher can
be appropriate in once circumstance and not in another.
A lattice of evaluations, with "secure" at the top and
"broken" at the bottom, and other terms based on the types
and severity of weaknesses, could be defined. A linear
"strength" scale is just too simplistic, but we still need
a way to summarize.
(I suppose one could say that we will create (and perhaps
have, already, in AES) a secure, fast, cheap cipher, and
therefore anything else is pointless. I think that this
is wrong, because it isn't obvious that such a holy
grail is even possible. Certainly our current state of
knowledge is insufficient to prove it one way or another.)
JM
------------------------------
From: "Ace Bezerka" <[EMAIL PROTECTED]>
Subject: How do you test a Blowfish encryption routine?
Date: Tue, 20 Mar 2001 11:07:56 -0500
How can I test a blowfish encryption to see if it performs properly? Are
there test vectors available to use to ensure the proper operation of my
routine? What about SHA, SHA-1, and SHA256?
------------------------------
From: Keill Randor - ([EMAIL PROTECTED]) <[EMAIL PROTECTED]>
Subject: What the Hell...Here's what my system can do at it's best...
Date: Tue, 20 Mar 2001 16:14:56 +0000
What my system allows you to do, (at it's best), is turn one peice of data - (or
text), into two or more peices, (neither of which can be proven to be encrypted), in
such a way that is unsolvable - i.e. you need to know what the original peice of data
was in order to get it back - (not difficult, trust me). (In addition to being
unsolvable, it is also uncrackable). Then, you work out an alternative solution, for
the real one, which also involves an existing peice of data (or part thereof), which
cannot individually be proven to be encrypted. This is where being able to turn any
peice of data into any peice of data comes in.... Being able to manufacture any
solution from an encrypted (or not) peice of data or text.
This system is a TRUE asymmetrical system. The method by which you encrypt a peice of
data, may be COMPLETELY different from the method used to decrypt it.
This system obeys my three rules of encryption:
1) Make the actual solution as convoluted as necessary.
2) Have more than one viable solution, (preferably any).
3) Have no way of knowing that it's encrypted in the first place.
The following paragraphs contain all three parts to a puzzle, I do not expect you to
find them and solve it - it's merely here as a demonstration:
Keill Randor, is a name taken from a series of books written by a Canadian Science
fiction author, Douglas Hill, called the Last Legionary Quintet. (They are meant for
the teenage market, but they're still fun even now).
Oh Dear. I fell over my spare box of computer stuff earlier, and found an old
graphics card I did not know I had. Ati crap. Still at least it still works. P.S.
Unreal Tournament actually works (fairly well - to crap, depending on the level), on
my old P-150, with 32mb RAM and a 12Mb Voodoo 2.
Go on, prove any of that lot's encrypted................... (The plaintext,
ciphertext and key are all in there....;).
You might like to talk about it, but I've gone and DONE IT.
1 uncrackable, unprovable, and (at it's best/worst) unsolvable encryption system.
(And it's not technically a one pad cipher either, since I can use the same key more
than once without making it any easier to crack, - (though if the key is known, then
it will compromise them - (though it will take as long to SOLVE this system as it will
to crack some others - the amount of options I have available are OBSCENE)).
I hope you understand what it is I have a little better now, and realise that I DO
UNDERSTAND the subject. (Trust me when I say that this problem is a VERY simple one -
don't look for complicated solutions for simple problems, you won't get ANYWHERE).
I also hope that someone from GCHQ also understands this system a little better - (I
have passed along the system to them to look at. If they turn it away now, they will
never be trusted again.
Keill randor
[EMAIL PROTECTED]
_______________________________________________
Submitted via WebNewsReader of http://www.interbulletin.com
------------------------------
From: Jim Steuert <[EMAIL PROTECTED]>
Subject: Re: Is SHA-1 Broken?
Date: Tue, 20 Mar 2001 12:22:47 -0500
That is a good point. Based on your point about multiplication,
I propose a simple modification of SHA-1 (call it SHA-1*)
The problem is that SHA-1 doesn't have a multiplication in its step.
Only a couple of constant length circular rotates. While I know
that multiplication is really shifts and adds, it's adds are conditional
on the input bits, so multiplication has a lot more binary expression
complexity than do constant length shift/rotates, even when mixed
with later adds, etc.
I am looking at ways to add an invertible balanced multiply to SHA-1's
step without weakening it. Here is one example:
currently, from the spec, the step iteration is:
where <<< means left 32-bit rotate, and
which F depends on the specific step.
NEW: al' = ( ( (al+1)*(dl+1) ) mod 65537 ) -1
NEW: ah' = ( ( (ah+1)*(dh+1) ) mod 65537 ) -1
WHERE al means low order 16-bits and ah means high order 16 bits
a' = (a'<<<5) + F(b,c,d) + e + w[t] + k[t]
e' = d
d' = c
c' = (b <<< 30)
b'= a
This works because 65537 (2^16+1) happens to be prime
so that, given any low order 16 bit dl+1
or al+1 gives 1-65536 all with equal probability.
Given any mod 65537 values x', x, y such that x' = x*y mod 65537,
then if x' and y are given (as in the inverse hash), then x can be
found easily as ((y^-1)*x') mod 65537). Since every possible
value of y from 1-65536 has a unique inverse (call it y^-1),
then we can compute the original x = ((y^-1)*x', where
x ranges from 1 to 65536 mod 65537. Finally, we subtract 1 again
to represent these values from 0-65535, or with 16 bits.
Thus, in the forward hash direction, given any input al, every different dl
generates
a different value of al'. Likewise in the reverse direction, for every
possible output al', then varying dl gives all possible values of al,
and for every possible value of dl, then varying al' gives all possible
and different values of al. Thus this multiplication mod 65537 is
a multipermutation, which yields a balanced mix of al and dl.
-Jim Steuert
Volker Hetzer wrote:
> Steve Meyer wrote:
> >
> > On Mon, 19 Mar 2001 17:19:39 -0500, Jim Steuert <[EMAIL PROTECTED]> wrote:
> > >No, you didn't miss anything. I did. I jumped to conclusions.
> > >
> > <snip>
> >
> > >
> > >Do you know of any research using BDD's to invert cipher or
> > >hash functions? I am off to learning more about BDDs.
> >
> > There has been quite a large amount of experiene with BDDs in electronic
> > design. BDD have a serious problem is determining the value computed by
> > a combinatorial electronic circuit. Namely, size of BDD's can and
> > does grow exponentially with the number of inputs. In electronic
> > design, designers learn to design in such a way as to minimize this
> > exponential explosion. But converting a encryption algorithm into
> > a BDD may be an interesting test for quality of encryption algorithm.
> > /Steve
> Right now, in electronic design, only one special case is known,
> where the size of the bdd explodes exponentially. It's multiplication.
> IMHO, as long as ciphers mix shifts and xors and all that stuff,
> they're probably secure. However, anybody that reads this and uses
> a model checker at work can download NSA's reference vhdl implementations
> and try them on it.
> Shouldn't be that difficult.
>
> Greetings!
> Volker
> --
> They laughed at Galileo. They laughed at Copernicus. They laughed at
> Columbus. But remember, they also laughed at Bozo the Clown.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Codes that use *numbers* for keys
Date: Tue, 20 Mar 2001 18:07:04 +0100
"Henrick Hellstr�m" wrote:
>
> "Mok-Kong Shen" <[EMAIL PROTECTED]> wrote:
> >
> >
> > Juuichiketajin wrote:
> > >
> >
> > > They need not.
> > > I have at my disposal a financial and a scientific calculator that both
> work
> > > in decimal. I have reason to believe that the internal number-storage
> format
> > > is decimal.
> >
> > It would be very interesting to know a modern processor
> > working internally on decimals and not on bits. Ask your
> > manufacturer and please post your results (including the
> > name of chip) if the answer is positive.
>
> Most modern processors work internally on bits. Most modern processors also
> work internally on decimals. Intels x86- & x87-processors support Binary
> Coded Decimals, instructions like e.g. DAA, decimal adjust after addition,
> etc.
That doesn't mean that at the 'lowest' level these
instructions aren't operating on bits, pretty like in C
you have macros that allow you to use some compact
'instruction' of pretty arbitrary form of your own
design that is expanded into normal C statements.
M. K. Shen
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: FIPS 140-1 does not adress eavesdropping
Date: Tue, 20 Mar 2001 18:09:44 +0100
Paul Rubin wrote:
> The designers of these things show up at crypto conferences and talk
> about their work. They do measure it.
Maybe the IBM guys. But even then, where is the standard ?
>
> > > I'm somewhat more concerned about firmware back doors being built into
> > > devices.
> >
> > Then better start doing you own CPU, memory, display, OS, email client.....
> > For governments this is actually a necessity, from my point of view :-)
>
> From the crypto processor's point of view, the surrounding host is assumed
> to be insecure.
I was referring to the crypto processor's components. Just look at how
complex a "simple" serial line controller is. Are you sure they do not
pose a risk ? (First irritate their synchronization circuit, then
manipulate throught the serial controller the CPU bus it is connected to
- just a wild guess)
Better burn the interface circuitry into your own ASIC. This creates
some kind of hardware-level firewall. But yeah, we know about the
pitfalls in using a firewall :-))
>
> > > I'd like to see the sci.crypt community design its own
> > > device with standard parts
> >
> > Standard parts like the very popular CPU, which could be halted by
> > an instruction sequence of a user-level program ? (And might expose
> > something worse to the three-letter agencies ?) There are no
> > standard parts you can 100% trust into.
>
> The device shouldn't run any untrusted software.
Ok, my example wasn't appropriate. Just wanted to demonstrate that
hardware components are as error-prone as software. The only difference
is that hardware is more thoroughly reviewed and tested, but in most
cases not formally verified. Doesn't apply to a crypto device.
This is btw. the achilles heel of products like "Security Enhanced
Linux". They assume a processor will assure isolation of processes by
its hardware mechanisms (MMU etc). It was demonstrated how to stop a
popular microprocessor (why do they call these multi-million transistor
monsters "micro.." ?) with *user*-level code. Wouldn't be surprised if a
certain instruction sequence could "accidently" switch to supervisory
mode.
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.security.pgp.discuss,alt.security.pgp
Subject: Re: NSA in the news on CNN
Date: Thu, 15 Mar 2001 18:42:20 +0100
Mxsmanic wrote:
They are supposed to talk about
> encryption in days to come, but I don't know to what extent. The series
> even shows pictures from inside the NSA! Those people at Fort Meade
> must be getting desperate for funding, or something!
Actually, someone made a 60 minute documentary on NSA they showed some
of the crypto (making) classes and the hardware lab on the bottom floor
of the main NSA building. I saw it on Discovery Europe ~1-1,5 years ago.
Quite intresting.
/Ichinin
------------------------------
From: amateur <[EMAIL PROTECTED]>
Subject: Re: Idea - (LONG)
Date: Tue, 20 Mar 2001 12:16:28 -0400
Thank you for your rich comments. Now, I'm happy. Just because you tooke
your your time to read carefully my idea. I'm going to try to read it
carefully and try to answer.
Thank you, thank you, thank you. :)))
"John A. Malley" wrote:
>
> amateur wrote:
> >
> > Don't forget that with my idea the same clear could produce multiple
> > cyphertext.
> > Schneier is defining restricted algorithm when algo is kept secret.
> > That's not my case.
> > All my algo is public. The secret who is to find and distinguish two
> > categories of symbols is not secret at all.
> > But the sender has the freedom to imagine any kind of two categories
> > before encrypting.
> > This secret is disclose if the recipient has the key.
> > All modern cryptography is based on power of computing.
> > What I'm proposing is to found a new cryptography based on the inability
> > of computer to analyse a text trying to distinguish two categories.
>
> Humans write programs. Algorithms employed by humans to decide
> something can be transcribed to a computer program (encoded as binary
> numbers.) A human recognizes the symbols in the ciphertext correspond
> to one or another category. The ability of a human to spot patterns can
> be encoded as an algorithm acting on the data. So a computer program
> can be written to do the same thing.
>
> Computers sort through data faster than humans. That's the advantage of
> a computer.
>
> > Computer has no this attribute.
>
> Computers are glorified adding machines. We tell them to add, subtract,
> multiply and divide numbers. We encode information as numbers and
> manipulate information as numbers. No program "means" anything to a
> computer. Computers do literally what we tell them to do with a program.
>
> For a time the word "computer" meant a person who carried out
> particular numerical calculations. "Computers" did not necessarily know
> what they were working on or what the calculation results meant.
>
> > So the cryptanalist even if he use the
> > computer is helpless. The only strategy for him is to try to guess what
> > a sender has choosen to encrypt every bit.
> > And this domain is infinite.
>
> So you encode binary-represented ciphertext with members of two set of
> symbols, each set with the same number of elements. The two sets differ
> in one property - one set has the property, the other set does not. The
> absence and presence of the property corresponds to binary 0 or 1.
>
> This "encoded" ciphertext is human-readable - it must be, or how can a
> human decode it? So a computer program can be written to recognize it
> same as a human did.
>
> This "encoded" ciphertext is program-readable if a program is written to
> generate the "encoded" ciphertext to send it electronically or to print
> it onto paper. And that which is generated by a program is recognized by
> a program.
>
> I read the "idea" post and the proposed cipher. A human cryptanalyst
> *can* figure out which symbols correspond to 0 and 1 no matter what
> symbols are used, due to the statistics of the plaintext as exposed in
> the ciphertext.
>
> How! you ask...
>
> Well, (1) the first thing the cipher does it apply a Caesar substitution
> to a fixed length of plaintext message.
>
> OK. This preserves the frequencies of occurrence of every letter,
> digraph
> and trigraph in the plaintext message. And the structure of every
> sentence. And the order of every plaintext word.
>
> Next, (2) convert each character in the substitution output into its hex
> equivalent, and then to binary (0 and 1.)
>
> OK. This preserves the frequencies of occurrence of every letter,
> digraph and trigraph in the plaintext message. And the structure of
> every sentence. And the order of every plaintext word.
>
> All (2) does it substitute a binary string for each character in the
> output of (1). That's why all the salient statistical information in the
> plaintext comes sailing on through.
>
> Now here's a interesting fact:
>
> The number of 1s and 0s in the resulting binary string produced in the
> output of step (2) are NOT equal. There are either more 1s than 0s or
> there are more 0s than 1s.
>
> Why?
>
> Well, some characters in the plaintext occurred far more often than
> others. And after the substitution cipher in step (1), their ciphertext
> character equivalents occur far more often than the ciphertext
> equivalents of the others. And after (2), the binary string
> representations of the ciphertext character equivalents occur far more
> often than the binary string equivalents of the ciphertext equivalents
> of
> the others.
>
> So what comes next?
>
> In step (3) of your idea, form two sets of symbols, each set with equal
> numbers of elements. Take the binary string representation output of
> step (2) and substitute an element out of one set selected uniformly at
> random for a 0 and a substitute an element out of the other set selected
> uniformly at random for a 1.
>
> OK. But remember, the number of 1s and 0s in the binary string
> representation are NOT equal! So symbols from one set appear more often
> than symbols from the other set. And the symbols selected from a set
> are selected uniformly a random. For a quantity of ciphertext encrypted
> this way, every symbol from the set corresponding to 1 should appear
> the same number of times and every symbol from the set corresponding to
> 0 should appear the same number of times.
>
> This information allows a cryptanalyst to determine which symbols
> correspond to which of the two sets representing 0 and 1.
> It can be determined by frequency count of each symbol in the encoded
> ciphertext. Half of the symbols in the "encoded" ciphertext will occur
> with the same frequency, f_a, and half of the symbols in the "encoded"
> ciphertext will occur with the same frequency f_b, and f_a will NOT
> equal f_b. Which set corresponds to 1 and 0? It's one or the other -
> but a clever cryptanalyst knows already what the binary coding of
> characters is, so therefore already knows if 1s or 0s occur with more
> frequency in the binary representation of the plaintext alphabet.
>
> So in step (3) the 0s are represented with {0,1,2,3,4} and 1s are
> represented with {5,6,7,8,9}.
>
> Again, the number of 0s, 1s, 2s, 3s, 4s will tend to be equal and the
> number of 5s, 6s, 7s, 8s, and 9s will tend to be equal but the number of
> 0s will not equal the number of 5s, #1s will not equal #5s, etc.
>
> In Step (4) a further Caesar substitution (? there's no modulo operation
> though, it's just addition) is done by adding a constant key value to
> the numerical result
> of Step (3).
>
> Does this hide the fact that the number of 0s and 1s in the binary
> representation output of step (2) are not equal?
>
> No.
>
> In fact, take any two message blocks encrypted with this cipher (using
> your notation, E1' + K and E2' + K, and just subtract one from the
> other to get E1' - E2'.
>
> No key involved here now. It's possible for the cryptanalyst to examine
> the statistics of the plaintext directly. What are the statistics of the
> differences between plaintext binary representations - they show up
> directly in the ciphertext.
>
> The addition of a fixed constant (key) in step (4) will not change the
> statistics of the underlying plaintext as revealed by the substituted
> ciphertext in step (2).
>
> Once a cryptanalyst determines which symbols represent 0s and 1s in a
> manner like the described, he replaces the symbols with 0s and 1s and
> gets the binary string equivalent to the Caesar substitution on the
> original plaintext (output of step 3.) Then all the known tools for
> cracking simple substitution ciphers apply to rapidly crack this cipher.
>
> The attack is even quicker and easier with known plaintext! Try it
> yourself and see. :-)
>
> In summary, here's the core of the attack:
>
> Homophonic substitution of the 0s and 1s of the binary string
> equivalents of the ciphertext output of a simple substitution cipher
> keeps the statistics of the plaintext (and its binary string equivalent
> ) intact. Any bias in the number of occurrences of 0s and 1s shows up
> in the frequencies of the symbols used to encode 0s and 1s.
>
> Hope this helps,
>
> John A. Malley
> [EMAIL PROTECTED]
>
>
>
>
> > You have multiple combinations using only the characters of ASCII table.
> > If using others codes, you have to understand thas it's quite impossible
> > to attack.
> >
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: How do you test a Blowfish encryption routine?
Date: Tue, 20 Mar 2001 18:14:36 +0100
Ace Bezerka wrote:
>
> How can I test a blowfish encryption to see if it performs properly? Are
> there test vectors available to use to ensure the proper operation of my
> routine? What about SHA, SHA-1, and SHA256?
Ask google.com or altavista.com, not us.
------------------------------
From: Peter Engehausen <[EMAIL PROTECTED]>
Subject: Strong Primes
Date: Tue, 20 Mar 2001 16:28:42 -0100
Reply-To: [EMAIL PROTECTED]
Hello!
I need some with a publication of Rives & Silverman.
The paper is called "Are Strong Primes needed for RSA?"
and is available at
ftp://ftp.rsasecurity.com/pub/pdfs/sp2.pdf
or
ftp://ftp.rsasecurity.com/pub/ps/sp2.ps .
The part that causes me trouble is page 17-18.
I tried to contact both authors, but they seem to busy to help me.
Here is a portion the last e-mail I wrote to Mr. Silverman before he
went silent.
The "�Yes" is his reply on a question I asked before.
--- zip ---
>> Is it necessary for this argumentation to assume that
>> r does not divide ord(e) mod \lambda(N)?
> ...Yes
Hm... That�s the crunch point. Why is it necessary to go over to the
order of e mod \lambda(N)?
Why can�t we keep looking at the order of e mod p and finish the
argumentation with:
"If r does not divide ord(e) mod p than e is an r-th power mod p. The
number of solutions..." without looking at the order of e mod \lambda(N)
at all?
I sort of assume that it�s necessary to discuss the order of e mod
\lambda(N) in order to estimate the size of k in equation 16: C^e^k = C
(mod N). If this is so I still fail to understand the following part:
"Suppose r does not divide ord(e) mod \lambda(N). It follows immediately
that e must be an r-th power mod p. This follows form Lagrange's
Theorem: ord(e) must divide p-1, and we have assumed that r divides p-1
but r does not divide ord(e). Hence e must be an r-th power mod p."
ord(e) mod \lambda(N) must divide p-1? I�m not sure if I remember
Lagrange's Theorem well... The order of a subgroup divides the order of
it�s group. Hence for every e which is coprime to \lambda(N) the order
of e mod \lambda(N) must divide the order of (Z/\lambda(N)Z)^*. This is
\phi(\lambda(N)), isn�t it? I can�t see why ord(e) divides p-1...
And further on: You say, if r and ord(e) divide both p-1 and r doesn�t
divide ord(e) than e must be an r-th power.
Sounds obvious, but why? I�m still too blind to see through.
--- zip ---
Thank you!
Peter Engehausen
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: What the Hell...Here's what my system can do at it's best...
Date: 20 Mar 2001 17:11:10 GMT
[EMAIL PROTECTED] (Keill Randor - ([EMAIL PROTECTED]))
wrote in <[EMAIL PROTECTED]>:
>
>What my system allows you to do, (at it's best), is turn one peice of
>data - (or text), into two or more peices, (neither of which can be
>proven to be encrypted), in such a way that is unsolvable - i.e. you
>need to know what the original peice of data was in order to get it back
>- (not difficult, trust me). (In addition to being unsolvable, it is
>also uncrackable). Then, you work out an alternative solution, for the
>real one, which also involves an existing peice of data (or part
>thereof), which cannot individually be proven to be encrypted. This is
>where being able to turn any peice of data into any peice of data comes
>in.... Being able to manufacture any solution from an encrypted (or
>not) peice of data or text.
>
>This system is a TRUE asymmetrical system. The method by which you
>encrypt a peice of data, may be COMPLETELY different from the method
>used to decrypt it.
>
I am not sure I followed exactly what your meant.
when you say "data - (or text)" does it encrypt any file to
text as your example?
>This system obeys my three rules of encryption:
>
>1) Make the actual solution as convoluted as necessary.
>
>2) Have more than one viable solution, (preferably any).
>
>3) Have no way of knowing that it's encrypted in the first place.
>
>The following paragraphs contain all three parts to a puzzle, I do not
>expect you to find them and solve it - it's merely here as a
>demonstration:
>
>
>Keill Randor, is a name taken from a series of books written by a
>Canadian Science fiction author, Douglas Hill, called the Last Legionary
>Quintet. (They are meant for the teenage market, but they're still fun
>even now).
>
>Oh Dear. I fell over my spare box of computer stuff earlier, and found
>an old graphics card I did not know I had. Ati crap. Still at least it
>still works. P.S. Unreal Tournament actually works (fairly well - to
>crap, depending on the level), on my old P-150, with 32mb RAM and a 12Mb
>Voodoo 2.
>
>
>Go on, prove any of that lot's encrypted................... (The
>plaintext, ciphertext and key are all in there....;).
>
Still not sure what your did. I take you use a piece of
plain text. Then spilt it into 2 encrypted texts. In the
above I take it Keil... is first part of split.
and Oh Dear... is second part of split
if so what do you claim the plain text and key are?
Could you expand on the example and explain the parts?
Do you have the key hidden in file afer the spit?
I hate to tell you but the way the game seems to be played
here is that the attacker has full knowledge of your program
and only the key is secret. If you have the key in the system
then you encryption program relies on keeping the whole
system secret. That is not what most are interested in.
However I think that for many situations keeping the whole
thing secrect is ideal. But to get anyone to look at it
they would have to study the "whole source" just sending
an encrypted text is not going to cut it. Except during a war.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: How do you test a Blowfish encryption routine?
Date: Tue, 20 Mar 2001 18:43:06 +0100
Ace Bezerka wrote:
>
> How can I test a blowfish encryption to see if it performs properly? Are
> there test vectors available to use to ensure the proper operation of my
> routine? What about SHA, SHA-1, and SHA256?
Go to Bruce's site at www.counterpane.com.
------------------------------
** 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
******************************
