Cryptography-Digest Digest #189, Volume #13 Sun, 19 Nov 00 16:13:00 EST
Contents:
Re: Cryptogram Newsletter is off the wall? ([EMAIL PROTECTED])
Re: Cryptogram Newsletter is off the wall? (Tim Tyler)
Re: Cryptogram Newsletter is off the wall? (wtshaw)
Re: Cryptogram Newsletter is off the wall? (Tim Tyler)
Re: Mode of operation to maintain input size with block ciphers? (Tim Tyler)
Re: Mode of operation to maintain input size with block ciphers? (Terry Ritter)
Re: Big-block cipher, perhaps a new cipher family? (Tim Tyler)
Re: vote buying... (David Schwartz)
Re: vote buying... (David Schwartz)
Re: Big-block cipher, perhaps a new cipher family? (Mok-Kong Shen)
Re: Cryptogram Newsletter is off the wall? (Vernon Schryver)
Re: A poorman's cipher (Mok-Kong Shen)
Re: Mode of operation to maintain input size with block ciphers? (Terry Ritter)
Re: Mode of operation to maintain input size with block ciphers?
([EMAIL PROTECTED])
Re: XOR Software Utility (freeware) available from Ciphile Software (Alan Mackenzie)
Re: Hitachi - on what grounds ?? (Mok-Kong Shen)
Re: Cryptogram Newsletter is off the wall? (Mok-Kong Shen)
Crypt FAQ Comments; Section 8.15 ([EMAIL PROTECTED])
Re: XOR Software Utility (freeware) available from Ciphile Software (root1657)
Re: XOR Software Utility (freeware) available from Ciphile Software (root1657)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Cryptogram Newsletter is off the wall?
Date: Sun, 19 Nov 2000 17:59:29 GMT
In article <kyTR5.977$17.26932@stones>,
"Brian Gladman" <[EMAIL PROTECTED]> wrote:
> <[EMAIL PROTECTED]> wrote in message
> news:8v8jmm$a3p$[EMAIL PROTECTED]...
> > There are methods of detecting Trojan horses such as BO etc,
BlackIce
> > is one good Intrusion Detection Software. I am really surprised
that
> > Bruce seems to have given up on Trojans. I understood that Bruce
> > Schneier has set up a new outfit dealing exclusively with things
like
> > Intrusion Detection, Security access etc...If he has already given
up
> > on things like BO well...what is it exactly is he recommending to
his
> > Clients...
>
> The issue here is not that of the best computer environments we can
think of
> for making digital signatures but rather that of the security we can
expect
> from typical computer environments in which such signatures will be
made.
> And this is pretty poor at the moment.
>
Brian you dont have to make the DS on the computer being open to abuse
and intrusion.
Why not make the DS on a smart card, e.g a Javacard....
The Keys never leave the card, and you can write the whole DS process
on the card....this is now feasible with the high end 32 bit Javacards.
> Brian Gladman
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Cryptogram Newsletter is off the wall?
Reply-To: [EMAIL PROTECTED]
Date: Sun, 19 Nov 2000 18:12:08 GMT
Bruce Schneier <[EMAIL PROTECTED]> wrote:
: Why Digital Signatures Are Not Signatures
[snip problems]
: Imagine Alice in court, answering questions about a document she
: signed. "I never saw it," she says. "Yes, the mathematics does prove
: that my private key signed the document, but I never saw it." And then
: an expert witness like myself is called to the stand, who explains to
: the judge that it is possible that Alice never saw the document, that
: programs can be written to sign documents without Alice's knowledge,
: and that Alice's digital signature doesn't really mean anything about
: Alice's intentions.
: Solving this problem requires a trusted signing computer. If Alice
: had a small hand-held computer, with its own screen and keyboard, she
: could view documents on that screen and sign them with that keyboard.
: As long as the signing computer is trusted, her signatures are
: trusted. (But problems remain. [...)].
You're right that problems remain. A trusted computer doesn't appear to
solve the problem at all. Alice can still claim that she stupidly wrote
her private key down on a piece of paper which she threw into the trash
can.
Such an action may be irresponsible - but it's not usually *criminally*
irresponsible. The area seems to be a problem without a solution.
This was a stimulating article - though you could write another one called
``Why Signatures Are Not Signatures'' easily enough...
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Cryptogram Newsletter is off the wall?
Date: Sun, 19 Nov 2000 11:35:55 -0600
In article <[EMAIL PROTECTED]>, Bruce Schneier
<[EMAIL PROTECTED]> wrote:
...
>
> Lots of things are secure when done properly; this is why so many
> security products are completely insecure. The job of the good
> security engineer is to imagine how things could not work properly,
> and to prepare for those eventualities.
>
> Bruce
>
Note that a boat will sink if any hole admits water sufficiently to
overcome its less density less 1.0 structure. The security of the vessel
is in preventing/containing and in outpumping any leak, both of which
techniques are seen in trying to maintain electronic security. Good
design fights the battle in structure first rather than looking for
whimsical dynamic action.
--
Pangram: Move zingy, jinxed products; hawk benign quality fixes.
Another: Bold information superhighway vexs quizzical jocks.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Cryptogram Newsletter is off the wall?
Reply-To: [EMAIL PROTECTED]
Date: Sun, 19 Nov 2000 18:17:05 GMT
David Hopwood <[EMAIL PROTECTED]> wrote (in his signature):
: If I revoke a public key but refuse to specify why, it is because the
: private key has been seized under the Regulation of Investigatory
: Powers Act; see www.fipr.org/rip
Goodness - sad times in the UK ;-(
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Free gift.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Mode of operation to maintain input size with block ciphers?
Reply-To: [EMAIL PROTECTED]
Date: Sun, 19 Nov 2000 18:24:20 GMT
Benny Nissen <[EMAIL PROTECTED]> wrote:
: Is there a mode of operation where I can maintain the size in all cases
: (input/output). [...]
: I have heard about a method called byte stealing, but I do not know what it
: is all about!
You're thinking about "cyphertext stealing", I believe. Look it up in
(for example) Applied Cryptography.
It works - but not "in all cases". There are "special difficulties" when
the size of the message becomes small. You /could/ use something like OFB
to deal with those - but OFB mode is crap...
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Florist: Petal pusher.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Mode of operation to maintain input size with block ciphers?
Date: Sun, 19 Nov 2000 18:40:16 GMT
On Sun, 19 Nov 2000 12:31:06 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt Paul Crowley
<[EMAIL PROTECTED]> wrote:
>[...]
>What you want usually isn't a good idea: if you tell us more about your
>application you'll get better advice. However, what you've asked for I
>think is a Variable Sized Block Cipher, and so you should check out the
>Bibliography in my paper on the subject
>
>http://hedonism/homepgs/new/paul/mercy/mercy-paper/bibliography.html
>
>particularly 1, 2, and 11.
This discussion was not originally about "Variable Size Block
Ciphers," but, rather, about ciphers with huge block sizes. I was one
of the early voices promoting huge block designs at a time (1994) when
they were not popular (see, for example:
http://www.io.com/~ritter/NEWS/LBDNEWS.HTM
). [And, in fact, Crowley was there, as we see:
http://www.io.com/~ritter/NEWS/94031603.HTM
]. To make this possible, I introduced the concept of mixing whole
blocks with orthogonal Latin square mixings using huge mixing
polynomials. Later development moved to mixing bytes in FFT-like
patterns, thus completely covering a block of arbitrary power-of-2
size with linear or -- eventually -- *keyed* nonlinear mixings; both
techniques give *guaranteed* mixing as opposed to academic handwaves
(see:
http://www.io.com/~ritter/#MixTech
). None of this was known to cryptography before my work and
publication. However, if the discussion is now about Variable Size
Block Ciphers, I played a somewhat greater role:
I personally originated the term "Variable Size Block Cipher" and
introduced it to cryptography in my work published here on sci.crypt,
dated 1995 Aug 20 (see:
http://www.io.com/~ritter/NEWS/VSBCNEWS.HTM
).
I note that Crowley claims to have a paper and bibliography covering
the subject of VSBC's. I also note that reference (1) there is Ross
Anderson and Eli Biham. Oddly, Anderson did in fact make the first
comment on my proposal, on 1995 Aug 21. But, from our current
perspective, we can now see from the content of that message that Ross
obviously was clueless about just what a Variable Size Block Cipher
would be (see:
http://www.io.com/~ritter/NEWS/95082101.HTM
). The clear implication is that I taught Ross the meaning of the
term.
As far as I know, I was the first in cryptography to publish and
describe ciphering technology that provided full diffusion across a
block of variable and potentially huge size in a fixed number of
processing layers.
SO EXACTLY WHERE IS THE REFERENCE TO RITTER IN THIS VSBC PAPER?
The origin of Variable Size Block Ciphering was not academic, but in
fact occurred right here in public view on sci.crypt.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Big-block cipher, perhaps a new cipher family?
Reply-To: [EMAIL PROTECTED]
Date: Sun, 19 Nov 2000 18:35:40 GMT
Paul Crowley <[EMAIL PROTECTED]> wrote:
: Mok-Kong Shen wrote:
:> It is in my (and also some others, I presume) view that one
:> need not very sharply distinguish between stream and block ciphers.
: No, I think it's just you.
Hmm.
As soon as you apply chaining modes to a block cypher, it starts to take
on "stream"-like elements.
Similarly stream cyphers may examine the stream over a significant area
before producing any output - and may perform chunking internally.
So while you can distinguish sharply between the two types of primitive,
in practical systems the lines between them can become a little blurred.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Free gift.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: vote buying...
Date: Sun, 19 Nov 2000 10:45:41 -0800
Paul Rubin wrote:
> If we're talking about poll voting, they authenticate you at the polls
> (photo ID etc). If we're talking about voting over the internet,
> that's a bad idea because it sacrifices non-coercability (the
> receipt-free property) by letting you vote with someone else watching.
> Even if there is some kind of foolproof biometric authentication
> device that you can plug into your computer when you vote, you can
> still sell your vote by just letting the buyer see how you vote.
This ignores blinding codes.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: vote buying...
Date: Sun, 19 Nov 2000 10:45:04 -0800
David Wagner wrote:
>
> David Schwartz wrote:
> > I'm not seriously suggesting that this technique be used, I'm simply
> >presenting it as proof that the problems alleged are not fundamental to
> >electronic voting.
>
> But others have shown that your suggested system does not work.
> The chits can be sold (or you can be coerced into giving your chit
> to the coercer), and hence we're back to the starting point.
Again, I'm not saying that this technique "works" in the sense of
meeting _all_ requirements. I'm simply saying that it meets two
requirements that others have alleged are mutually contradictory. I am
refuting arguments, not advancing suggestions.
DS
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Big-block cipher, perhaps a new cipher family?
Date: Sun, 19 Nov 2000 19:53:24 +0100
Paul Crowley wrote:
>
> Mok-Kong Shen wrote:
> > It is in my (and also some others, I presume) view that
> > one need not very sharply distinguish between stream and
> > block ciphers.
>
> No, I think it's just you.
Then you probably have forgotten the contents of some old
postings. If that were not the case, I should have been
pleased to claim a new perspective as I have explained
(which unfortunately isn't new).
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: Cryptogram Newsletter is off the wall?
Date: 19 Nov 2000 11:44:20 -0700
In article <kyTR5.977$17.26932@stones>,
Brian Gladman <[EMAIL PROTECTED]> wrote:
><[EMAIL PROTECTED]> wrote in message
>news:8v8jmm$a3p$[EMAIL PROTECTED]...
>> There are methods of detecting Trojan horses such as BO etc, BlackIce
>> is one good Intrusion Detection Software. I am really surprised that
>> Bruce seems to have given up on Trojans. I understood that Bruce
>> Schneier has set up a new outfit dealing exclusively with things like
>> Intrusion Detection, Security access etc...If he has already given up
>> on things like BO well...what is it exactly is he recommending to his
>> Clients...
>
>The issue here is not that of the best computer environments we can think of
>for making digital signatures but rather that of the security we can expect
>from typical computer environments in which such signatures will be made.
>And this is pretty poor at the moment.
Detecting the traffic from famous, old Trojan horses such as BO is
completely different from detecting other Trojans, such those that might
corrupt signed documents or votes. The latter need not announce their
existence on the net, and so can be completely invisible to intrusion
detection systems.
In the 15 or more years since I first heard people selling intrusion
detection software, I've not seen anything useful. All intrusion detection
systems have been either academic toys or frauds, such as the current
flood of purely bogus snake-oil "personal firewalls." The biggest trouble
with real intrusion detection software (as opposed to unreal personal
firewall frauds) is that if you can teach a program to detect an intrusion,
then you can and would be smarter to exclude the intrusion and so have
nothing to detect. It is only during the "window of exposure" described
in http://www.counterpane.com/window.html that intrusion detection makes
sense. That window is after some but before all of your systems have
been taught about the attack. As http://www.counterpane.com/ says,
"Security is a process, not a product." Perhaps that's why Counterpane
seems to be selling the equivalent of human financial auditing and human
guards instead of snake-oil such as "personal firewalls."
A secondary problem with any intrusion detection software is that a
complete job sounds like a halting problem. If the legitimate traffic on
a network is anything that can be generated by any legitimate application
program and if you cannot characterize legitimate programs, then how do
you distinguish the output from legitimate programs from the output of
naughty programs? Even if you can characterize legitimate applications,
there are insurmountable problems, such as the tunneing of arbitrary
traffic through DNS. See http://slashdot.org/articles/00/09/10/2230242.shtml
and imagine a trojan that phones home usind DNS traffic. That famous
cases such as BO and smurf attacks can be detected shows merely that you
can detect attacks take no effort to hide their traffic and only after
you know about them.
SYN bombing is an illuminating example. Every busy web server continually
suffers from orphan TCP SYN's that cannot be distinguished from intentional
SYN attacks. Every time a random PC is disconnected just after sending
a SYN to start fetching an HTTP page, the target HTTP server will see a
TCP/IP packet that cannot be distinguished from a SYN attack. The only
distinguishing characteristic of a SYN attack is enough orphan SYN's to
cause problems, and that depends more on the nature of the system under
"attack" than on other people's intentions, good or otherwise.
Vernon Schryver [EMAIL PROTECTED]
P. S. Yes, I've read RFC 2267. Not only is ingress filtering not intrusion
detecting, but there are many legitimate cases where ingress filtering
should not be applied. And no, solving crypto puzzles in the middle of
the TCP 3-way handshake is not a good way to deal with SYN attacks. Other
tactics such as D.A.Borman's in 4.*BSD UNIX are far better and cheaper
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: A poorman's cipher
Date: Sun, 19 Nov 2000 19:57:27 +0100
Addendum:
There are of course other non-linear expressions that can
be used in chaining, e.g.
S:= S + P[i]*C[i] (mod 2^m);
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Mode of operation to maintain input size with block ciphers?
Date: Sun, 19 Nov 2000 19:57:58 GMT
On Sun, 19 Nov 2000 18:40:16 GMT, in <[EMAIL PROTECTED]>,
in sci.crypt [EMAIL PROTECTED] (Terry Ritter) wrote:
>[...]
>This discussion was not originally about "Variable Size Block
>Ciphers," but, rather, about ciphers with huge block sizes.
That is wrong; there is such a thread but this is not it. Sorry.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Mode of operation to maintain input size with block ciphers?
Date: 19 Nov 2000 12:10:03 -0800
Tim Tyler <[EMAIL PROTECTED]> writes:
> You're thinking about "cyphertext stealing", I believe. Look it up in
> (for example) Applied Cryptography.
Cyphertext stealing does not maintain size. It is a modification of CBC
mode and so requires an IV, which will add to the size.
Ob
------------------------------
From: Alan Mackenzie<[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker,talk.politics.misc
Subject: Re: XOR Software Utility (freeware) available from Ciphile Software
Date: Sun, 19 Nov 2000 18:57:21 +0000
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote on Sat, 18 Nov 2000 23:12:42 -0800:
> Alan Mackenzie wrote:
>> Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote on Tue, 07 Nov 2000
>> 20:39:23 -0800:
>> > You can be sure that OAP-L3 performs exactly as described and you can
>> > prove it to yourself.
>> Anthony, I think you are mistaken here. Suppose a copy of OAP-L3 somehow
>> got infected with a virus - it happens, some people are not as careful as
>> they might be.
>> The infected copy of the software would pass all tests, whether supplied
>> by the author or constructed by the user, apparently behaving identically
>> to the clean version. Yet OAP-L3-infected does _not_ perform exactly as
>> OAP-L3-clean. Since these tests do not distinguish between the clean and
>> dirty versions of the software, they cannot be said to test every aspect
>> of it.
>> > I don't know how many crypto software products provide you with the
>> > means to check every process included with the software and allow you
>> > to create your own verification files?
Any product with open source does.
>> The point people are making is that they cannot know that OAP-L3 is
>> totally clean without having access to the source code, and no amount of
>> testing can demonstrate this cleanliness.
>> I think it's been mathematically proven that testing _cannot_ demonstrate
>> a program to be flawless.
> Sounds like this is a possibility that every software program in
> the world is susceptible to. ....
Yes, indeed.
> Have you checked all your software lately?
No, but I've checked some of it, and the vast bulk of what I use at home
is open source, so _somebody_ will have checked it. If I have any reason
to doubt a piece of software I can always rebuild it from its source and
compare with the existing version. I have more confidence in such
software than in binary-only distributions. This is particularly
important for security-critical programs, such as OS kernels and
cryptographic software.
For example, Outlook Express has some ghastly misfeatures in it (the
susceptibility to email viruses being only one of them), yet it
certainly will have passed the vast bulk of Microsoft's test suite.
> But if one were to get the software from a reputable source and maybe
> make a CD-R copy so it could not be altered and compare it with other
> copies of the software using perhaps the MSDOS fc command, then you
> would know you had a pristine copy.
But anyhow, you're missing my point - I was not trying to suggest the
virus scenario as a practical difficulty to overcome. I was using it to
demonstrate my point that testing the functionality of software cannot
prove that it corresponds exactly with its specification.
> ..... But I realize you and others are holding out the possibility that
> I have intentionally tampered with my own software.
I strongly doubt you would do any such thing. But, given its relevance to
cryptography, it would be nice to be sure, for example, that there are no
subtle coding bugs which might allow a rogue input file to overrun its
allocated buffer and insert rogue code into the code segment which might
follow it in memory. Such possibilities can not be tested for, they can
only be found by inspecting the code, and most of the time, they can only
be found by somebody OTHER THAN THE AUTHOR inspecting the code. Even the
best of software engineers are capable of not seeing their own bugs.
Do you have a buddy who checks your code (possibly in exchange for your
checking his code)?
> Of course, a dirty trick would be for someone or group to take some
> software and infect it then redistribute it themselves. For instance,
> do what you suggested with a copy of Microsoft Windows ME, or Office
> 2000, or Adobe Photoshop, etc. then sell it on the black market. You'd
> get plenty of buyers because you would sell it cheap. You might even
> just give it away.
And an even dirtier trick would be for them to assert that it was _their_
version which was the clean one, and your original version the rogue one.
Publishing the source code would make this manoevre impossible.
[ .... ]
> Make your own tests based on the specification of OAP-L3. Then test
> the software. You do this by testing one function at a time. And
> the functions are simple shuffle / transform functions and the XOR
> function.
How do I test that there can be no buffer overrun? What would happen if,
say, some sort of escape sequence took 2 or 3 bytes in a buffer, but the
code erroneously counted it as a single byte? How can I test that this
can never happen?
> I mean, do you actually think that the software is going to let all
> the test files process normally but when the fate of the world is at
> stake the software will recognize this and the virus or bug or
> trojan or whatever will activate and allow the world to be destroyed?
> That's an extraordinary suggestion.
There have been quite a few security bugs found by engineers in the Linux
kernel, for example. Had the source not been open, those engineers would
not have found them. However, crackers might well have found them in the
binaries.
--
Alan Mackenzie (Munich, Germany)
Email: [EMAIL PROTECTED]; to decode, wherever there is a repeated letter
(like "aa"), remove one of them (leaving, say, "a").
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Hitachi - on what grounds ??
Date: Sun, 19 Nov 2000 21:26:12 +0100
In C there is no rotation operation and one has to achieve
that with masking and linear shift (or linear shift alone)
and then OR the results. In how far does Hitachi's claim
cover this on grounds of patent laws? I am just curious.
(I suppose that e.g. in chemistry certain technical
processes of making certain chemicals can be patented.
Would different processes leading to the same chemicals
be violating the patents?)
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Cryptogram Newsletter is off the wall?
Date: Sun, 19 Nov 2000 21:26:21 +0100
Bruce Schneier wrote:
>
[snip]
> Digital signatures prove, mathematically, that a secret value known as
> the private key was present in a computer at the time Alice's
> signature was calculated. It is a small step from that to assume that
> Alice entered that key into the computer at the time of signing. But
> it is a much larger step to assume that Alice intended a particular
> document to be signed. And without a tamperproof computer trusted by
> Alice, you can expect "digital signature experts" to show up in court
> contesting a lot of digital signatures.
Isn't it that there is the additional general problem of
identifying a public key with the (physical) person?
Trust centres presumably should solve that problem. But
there is a problem of trusting the persons at the trust
centres as well as trusting the mechanisms it employs,
isn't it? Thanks.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Crypt FAQ Comments; Section 8.15
Date: Sun, 19 Nov 2000 20:18:04 GMT
For Section 8.15:
Regarding reference [SPI93]:
The following web site has a link to the PC program that was used in the
article. It attempts to solve simple substitution ciphers using a
genetic algorithm which evaluates possible keys based on digram
frequencies. Includes Pascal source code and is GPL'd.
http://www.mit.edu/~average/home.html
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: root1657 <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto,alt.hacker,talk.politics.misc
Subject: Re: XOR Software Utility (freeware) available from Ciphile Software
Date: Sun, 19 Nov 2000 20:44:27 GMT
Anthony Stephen Szopa wrote:
> > Without even having seen the program, or it's code, i would caution anyone
> > against using a program written or endorced by a person with an attitude like
> > that..... It just gives off a "malicious code" vibe....
> > xxx
>
> I bet you could spot a pregnant chad a mile away blindfolded.
And if the wind is blowing the right direction, sometimes even further...
xxx
------------------------------
From: root1657 <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto,alt.hacker,talk.politics.misc
Subject: Re: XOR Software Utility (freeware) available from Ciphile Software
Date: Sun, 19 Nov 2000 20:44:29 GMT
Anthony Stephen Szopa wrote:
> I mean, do you actually think that the software is going to let all
> the test files process normally but when the fate of the world is at
> stake the software will recognize this and the virus or bug or
> trojan or whatever will activate and allow the world to be destroyed?
>
> That's an extraordinary suggestion.
Not so extraordinary. It could be done with an AND function.... and the AND
function and your reported XOR function should both fit well inside the size of
that file....
xxx
------------------------------
** 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
******************************
