Cryptography-Digest Digest #119, Volume #13 Wed, 8 Nov 00 05:13:01 EST
Contents:
Re: Brute force against DES (Benjamin Goldberg)
Whole file encryption (Benjamin Goldberg)
Re: algorithms before 1939 ("John A.Malley")
Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile (Scott Craver)
Re: Hardware RNGs (Benjamin Goldberg)
Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile (Anthony
Stephen Szopa)
Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile (Cory C.
Albrecht)
Re: Updated XOR Software Utility (freeware) Version 1.1 from (Anthony Stephen Szopa)
Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile ("Trevor L.
Jackson, III")
Re: hacker...beware (yogi)
Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile (Anthony
Stephen Szopa)
Re: Whole file encryption (Mok-Kong Shen)
Re: Purported "new" BXA Encryption software export restrictions (CiPHER)
Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile (Richard
Heathfield)
Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile Software
(CiPHER)
Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile Software
(Andre van Straaten)
----------------------------------------------------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Brute force against DES
Date: Wed, 08 Nov 2000 06:11:27 GMT
David Wagner wrote:
>
> John A. Malley wrote:
> >If the plaintext block of eight, 8-bit bytes consists of 8 different
> >values - b1, b2, b3, b4, b5, b6, b7, b8 - then when checking the
> >candidate plaintext resulting from trial decryption with candidate
> >key K - d1, d2, d3, d4, d5, d6, d7, d8 - check first that b1 == d1.
> >If not, throw away this key.
>
> But this is a very weak test: Over 89% of all incorrect key guesses
> will survive this test.
>
> Also, it requires knowing something about the byte-repetition patterns
> in the plaintext, a questionable assumption. (Otherwise, you might
> discard the correct key value.)
>
> Compare to the following heuristic: If the high bit is set in any of
> the bytes of the decryption, throw away this key. This eliminates
> all but .4% of the wrong key guesses, and is a reliable test. (It
> requires not much knowledge of the plaintext, and has a very low
> chance of discarding correct keys when the plaintext is, e.g., ASCII
> English.)
This can be optomized even further, if you are using a bit-sliced DES
implementation... Only calculate the ciphertext values for those
particular bits.
For those who don't know, bit-slicing means using just OR, AND, XOR, NOT
(and cominations thereof), run your PC as a SIMD parrallel processor,
caluculating 32 (or whatever your word size is) DES encryptions
simultaneously, by simulating the gates that would be used in a hardware
implementation.
A single bit-sliced DES call is significantly faster than doing 32
seperate normal software DES calls. Additionally, by not calculating
all 64 bits of ciphertext, we further speed things up. Lastly, by doing
an OR of the 8 words containing the high bits of the trial decryption,
and a comparison of the result with 0xFFFFFFFF, we can very quickly
discard whole bunches of keys at once.
For those wondering what I mean... If any of the 32 keys being tested
results in 0s in the 8 high bits, then ORing together those 8 high bits
will result in a 1 in that key's offset. Since getting a correct or
probably correct key is highly unlikely, most of the time the bitslice
OR of the high bits will be 32 1s (0xFFFFFFFF).
> Thus, even the very simple high-bit heuristic seems to be more
> effective than a heuristic based on repeated bytes.
>
> For strategies that are even more effective (yet still quite simple to
> implement), you might take a look at the following paper:
> A programmable plaintext recognizer, David Wagner and Steven M.
> Bellovin.
> http://www.cs.berkeley.edu/~daw/papers/recog.ps
OH! you wanted simple to implement. Bleh... there are one or two
bitsliced DES implementations out there, though. I would definitely NOT
advise you to create your own, unless you can implement DES using wires
and gates (no adds, subtracts, or multiplies, just operations that input
two bit values, and output one bit value).
--
"Mulder, do you remember when I was missing -- that time that you
*still* insist I was being held aboard a UFO?"
"How could I forget?"
"Well, I'm beginning to wonder if maybe I wouldn't have been
better off staying abo-- I mean, wherever it was that I was
being held." [from an untitled spamfic by [EMAIL PROTECTED]]
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Whole file encryption
Date: Wed, 08 Nov 2000 06:11:43 GMT
The following is a simple idea for whole file encryption.
sbox is actually a keyed sbox.
encrypt_r( data, length, sbox )
tmp1 = length, tmp2 = tmp1/2, tmp3 = tmp1-tmp2
ptr1 = &data[0], ptr2 = &data[tmp3]
for( i = 0; i < tmp2; ++i, ++ptr1, ++ptr2 )
*ptr1 += sbox[*ptr2]
*ptr2 += sbox[*ptr1]
*ptr1 += sbox[*ptr2]
if( tmp2 != tmp3 )
*ptr1 = sbox[*ptr1]
if( tmp2 > 0 )
encrypt_r( data, tmp2, sbox )
if( tmp3 > 0 )
encrypt_r( ptr1, tmp3, sbox )
encrypt( data, length, sbox )
encrypt_r( data, length, sbox )
encrypt_r( data, length, sbox )
Yes, I realize that I've not defined a keyschedule, and that decrypt
will need both the sbox (for the 3 round fiestel) and it's inverse (for
the occasional substitution), but this is after all just a sketch of an
idea.
If anyone thinks that it might be a *good* idea, let me know, and I'll
write some C code.
--
"Mulder, do you remember when I was missing -- that time that you
*still* insist I was being held aboard a UFO?"
"How could I forget?"
"Well, I'm beginning to wonder if maybe I wouldn't have been
better off staying abo-- I mean, wherever it was that I was
being held." [from an untitled spamfic by [EMAIL PROTECTED]]
------------------------------
From: "John A.Malley" <[EMAIL PROTECTED]>
Subject: Re: algorithms before 1939
Date: Tue, 07 Nov 2000 22:19:14 -0800
Michal z Sopotu wrote:
>
> Hi
> I`m looking for some internet pages,magazines, books (or other sources) of
> cipher/decipher algorithms used before 1939.
>
> Michal
John Savard's web site covers cryptographic machinery and ciphers prior
to 1939 - see
http://home.ecn.ab.ca/~jsavard/crypto.htm
A classical cryptology course is on-line at
http://www.fortunecity.com/skyscraper/coding/379/lesson1.htm
Books covering ciphers from the 19th Century, World War I, the
Between-the-Wars Years, and World War II are available from Aegean Park
Press at
http://www.aegeanparkpress.com/
Hope this helps,
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Scott Craver)
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
Subject: Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile
Date: 8 Nov 2000 06:48:36 GMT
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>Andre van Straaten wrote:
>>
>> I posted a Tcl/Tk file on alt.sources.crypto which does just this.
>At least you try.
He did a much better job than you, so your snide remarks are
uncalled for. Your program appears to be ridiculously huge, only
works on one platform, and provides no source code. Andre's program
will work on multiple platforms, is open, and clearly smaller.
AAAND, your program didn't even let you specify different
directories for the files in your first revision. How is it even
possible to write a program that bad? In MFC and even in Win32
file open dialogues already provide this functionality _for_ you,
don't they?
-S
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Hardware RNGs
Date: Wed, 08 Nov 2000 06:56:13 GMT
Alan Rouse wrote:
>
> David Schwartz wrote:
> >Let me give you an example. I have an input stream which is truly
> >random but highly biased. Say one bit in a thousand is a '0' and the
> >rest are all '1's. This stream is guessable in the sense that if you
> >guess that a given bit is a '1', you'll be read 99.9% of the time.
> >
> >Now I take 1Mb of data from this stream and run a SHA1 on it. You
> >couldn't guess a single bit in the output of that hash with a
> >probability any better than half.
>
> Agreed. But it is of more practical interest in the real world to
> obtain the entire 160 bits than to obtain just one. And biases in the
> input do make this easier to accomplish.
>
> To make illustration easier, let's take 160 bits from the input stream
This seems to be a very stupid thing to do; It would be far more
intelligent to calculate the amount of bias, then the number of bits per
bit of order-0 entropy (call this H), and then take 160/H bits from the
input stream. If you calculate H to be 1 (no bias), then my model
simplified to taking 160 bits of input.
> (same size as the output of SHA-1). An informed attacker would start
> guessing with all bits = 1. Then he would try all the possibilities
> with a single bit = 0. Then he would try all the possibilities with
> two bits = 0. etc. He would expect to find the actual input value in
> FAR FAR less than half of 2^160 attempts. Finding the input is the
> easiest way to find the output.
If, with my scheme, you wrongly calculate H to be 1, when it's much less
than that, then the attacker has the advantage you have described above.
--
There are two methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
Subject: Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile
Date: Tue, 07 Nov 2000 23:45:20 -0800
Scott Craver wrote:
>
> Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> >Andre van Straaten wrote:
> >>
> >> I posted a Tcl/Tk file on alt.sources.crypto which does just this.
>
> >At least you try.
>
> He did a much better job than you, so your snide remarks are
> uncalled for. Your program appears to be ridiculously huge, only
> works on one platform, and provides no source code. Andre's program
> will work on multiple platforms, is open, and clearly smaller.
>
> AAAND, your program didn't even let you specify different
> directories for the files in your first revision. How is it even
> possible to write a program that bad? In MFC and even in Win32
> file open dialogues already provide this functionality _for_ you,
> don't they?
>
> -S
You clearly sound neurotic.
Are you not a little self conscious about your ravings?
You are certainly giving many of us much amusement.
------------------------------
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
From: [EMAIL PROTECTED] (Cory C. Albrecht)
Subject: Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile
Date: Wed, 08 Nov 2000 07:49:08 GMT
In article <8uat04$9kb$[EMAIL PROTECTED]>, [EMAIL PROTECTED] =
(Scott Craver) wrote:
> AAAND, your program didn't even let you specify different=20
> directories for the files in your first revision. How is it even=
=20
> possible to write a program that bad? In MFC and even in Win32=20
> file open dialogues already provide this functionality _for_ you,
> don't they?
Yes, they do, but it's even simpler than that. :-)
C:\TEMP> programe ..\dir1\file1.dat ..\dir2\file2.dat
Not exactly that hard to do fopen(argv[1], "rt"), with either relative or=20
absolute pathnames. :-) Or even if it was Win32 GUI programme and he just u=
sed=20
a simple dialog box with a couple of text fields.... *shrug*
I, like you, marvel at how poor the programming had to have been such that =
1.0=20
couldn't open up files in 2 different directories. :-)
By the by - I tried to make a little xor programme myself, too, as an Win32=
=20
console programme. I hit 157kB - albeit with every debugging feature turned=
=20
on. :-) Oh, and I could open files from different directories, too. :-)
--
Cory C. Albrecht
http://members.home.com/cory.albrecht/
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
Subject: Re: Updated XOR Software Utility (freeware) Version 1.1 from
Date: Wed, 08 Nov 2000 00:08:28 -0800
"Cory C. Albrecht" wrote:
>
> In article <8uat04$9kb$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Scott
>Craver) wrote:
> > AAAND, your program didn't even let you specify different
> > directories for the files in your first revision. How is it even
> > possible to write a program that bad? In MFC and even in Win32
> > file open dialogues already provide this functionality _for_ you,
> > don't they?
>
> Yes, they do, but it's even simpler than that. :-)
>
> C:\TEMP> programe ..\dir1\file1.dat ..\dir2\file2.dat
>
> Not exactly that hard to do fopen(argv[1], "rt"), with either relative or
> absolute pathnames. :-) Or even if it was Win32 GUI programme and he just used
> a simple dialog box with a couple of text fields.... *shrug*
>
> I, like you, marvel at how poor the programming had to have been such that 1.0
> couldn't open up files in 2 different directories. :-)
>
> By the by - I tried to make a little xor programme myself, too, as an Win32
> console programme. I hit 157kB - albeit with every debugging feature turned
> on. :-) Oh, and I could open files from different directories, too. :-)
>
> --
> Cory C. Albrecht
> http://members.home.com/cory.albrecht/
With all your (all those in this news group) experience in
programming and encryption and aesthetics, it is I and not most of
you with the ideas and the software products and the strategy and
the GOOD will to get these fully functional products out to the
public.
If any of you were Gore supporters just think if you had given as
much energy to his getting elected as you have squandered in my
threads he might have won.
------------------------------
Date: Wed, 08 Nov 2000 04:13:04 -0500
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
Subject: Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile
Anthony Stephen Szopa wrote:
> Scott Craver wrote:
> >
> > Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> > >Andre van Straaten wrote:
> > >>
> > >> I posted a Tcl/Tk file on alt.sources.crypto which does just this.
> >
> > >At least you try.
> >
> > He did a much better job than you, so your snide remarks are
> > uncalled for. Your program appears to be ridiculously huge, only
> > works on one platform, and provides no source code. Andre's program
> > will work on multiple platforms, is open, and clearly smaller.
> >
> > AAAND, your program didn't even let you specify different
> > directories for the files in your first revision. How is it even
> > possible to write a program that bad? In MFC and even in Win32
> > file open dialogues already provide this functionality _for_ you,
> > don't they?
> >
> > -S
>
> You clearly sound neurotic.
>
> Are you not a little self conscious about your ravings?
>
> You are certainly giving many of us much amusement.
Pointing out the limitations of your software is to amusement as Jerry Springer is
to entertainment.
------------------------------
From: yogi <[EMAIL PROTECTED]>
Subject: Re: hacker...beware
Crossposted-To:
alt.lang.basic,alt.permaculture,alt.surfing,alt.surfing.europe.uk,aus.computers.linux,comp.os.linux.setup
Date: Wed, 8 Nov 2000 19:27:58 +1000
On Wed, 08 Nov 2000, Gary wrote in various dribble:
>The following person (who posts on the above newsgroups)has been detected by
>my firewall as attempting to hack into my system. He/she has been reported
>to the isp concerned and details are as follows.
I think you really have to put things into proper perspective here.
Quite often people scan a group of IPs looking for the last person to occupy
that address. Maybe they want to play a game, maybe something a little more
serious but the fact is... Your firewall is there to stop them unless you give
your permission.
The best thing to do is just chill out... System administrators turn off the
monitoring facility of firewalls once they are satisfied their rules work...
What about you?
Yogi
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
Subject: Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile
Date: Wed, 08 Nov 2000 01:17:21 -0800
"Trevor L. Jackson, III" wrote:
>
> Anthony Stephen Szopa wrote:
>
> > Scott Craver wrote:
> > >
> > > Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> > > >Andre van Straaten wrote:
> > > >>
> > > >> I posted a Tcl/Tk file on alt.sources.crypto which does just this.
> > >
> > > >At least you try.
> > >
> > > He did a much better job than you, so your snide remarks are
> > > uncalled for. Your program appears to be ridiculously huge, only
> > > works on one platform, and provides no source code. Andre's program
> > > will work on multiple platforms, is open, and clearly smaller.
> > >
> > > AAAND, your program didn't even let you specify different
> > > directories for the files in your first revision. How is it even
> > > possible to write a program that bad? In MFC and even in Win32
> > > file open dialogues already provide this functionality _for_ you,
> > > don't they?
> > >
> > > -S
> >
> > You clearly sound neurotic.
> >
> > Are you not a little self conscious about your ravings?
> >
> > You are certainly giving many of us much amusement.
>
> Pointing out the limitations of your software is to amusement as Jerry Springer is
> to entertainment.
You said it: so what are the limitations of the XOR software
utility?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Whole file encryption
Date: Wed, 08 Nov 2000 10:39:36 +0100
Benjamin Goldberg wrote:
>
> The following is a simple idea for whole file encryption.
> sbox is actually a keyed sbox.
>
> encrypt_r( data, length, sbox )
> tmp1 = length, tmp2 = tmp1/2, tmp3 = tmp1-tmp2
> ptr1 = &data[0], ptr2 = &data[tmp3]
> for( i = 0; i < tmp2; ++i, ++ptr1, ++ptr2 )
> *ptr1 += sbox[*ptr2]
> *ptr2 += sbox[*ptr1]
> *ptr1 += sbox[*ptr2]
> if( tmp2 != tmp3 )
> *ptr1 = sbox[*ptr1]
> if( tmp2 > 0 )
> encrypt_r( data, tmp2, sbox )
> if( tmp3 > 0 )
> encrypt_r( ptr1, tmp3, sbox )
>
> encrypt( data, length, sbox )
> encrypt_r( data, length, sbox )
> encrypt_r( data, length, sbox )
I don't see why you have
*ptr1 += sbox[*ptr2]
*ptr2 += sbox[*ptr1]
*ptr1 += sbox[*ptr2]
and don't have simply the first two statements. (Compare
a normal Feistel cipher).
Does
encrypt( data, length, sbox )
encrypt_r( data, length, sbox )
encrypt_r( data, length, sbox )
simply mean that you want to repeat encrypt_r exactly
two times? If yes, why?
If I understand correctly, what you do in encrypt_r
is equivalent to doing a permutation of the elements
of the array data (or segments of that array in the
recursive calls) thru bringing those at some distance
away to become neighbours and then perform a normal
Feistel cycle. There is some similarity to an idea I
posted recently in the thread 'On block encrpytion
processing with intermediate permutations' (25th Sep),
the difference being that I use pseudo-random
permutations, while you employ special permutations,
if I don't err.
It may be of interest to note that, if the file, i.e.
the array data, has 2^m elements, then one way of
applying a Feistel cipher is doing recursion, i.e.
first dividing the whole into two halves for Feistel
processing which is itself done by subdivision and so
on. See the thread 'On higher order Feistel schemes'
posted by me on 13th May.
M. K. Shen
------------------------------
From: CiPHER <[EMAIL PROTECTED]>
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
Subject: Re: Purported "new" BXA Encryption software export restrictions
Date: Wed, 08 Nov 2000 09:44:34 GMT
In article <[EMAIL PROTECTED]>,
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> Purported "new" BXA Encryption software export restrictions
Will you please stop crossposting every single one of your messages? Not
everything about you or your 'wonderful' product is relevant to these
newsgroups... especially not to sci.crypt.
--
Marcus
---
[ www.cybergoth.cjb.net ] [ alt.gothic.cybergoth ]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Wed, 08 Nov 2000 09:54:07 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
Subject: Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile
Scott Craver wrote:
>
> Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> >Andre van Straaten wrote:
> >>
> >> I posted a Tcl/Tk file on alt.sources.crypto which does just this.
>
> >At least you try.
>
> He did a much better job than you, so your snide remarks are
> uncalled for. Your program appears to be ridiculously huge, only
> works on one platform, and provides no source code. Andre's program
> will work on multiple platforms, is open, and clearly smaller.
>
> AAAND, your program didn't even let you specify different
> directories for the files in your first revision. How is it even
> possible to write a program that bad? In MFC and even in Win32
> file open dialogues already provide this functionality _for_ you,
> don't they?
>
I was wondering whether it was because he didn't want to push the file
size up too much.
I've run the binary through "strings" and found nothing suspicious
(although I only looked at "in clear" stuff). He doesn't seem to have
bothered to tell the compiler to omit useless junk, as a result of which
much debugging information is still in there. No apparent sockets calls
or links to sockets libraries.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
------------------------------
From: CiPHER <[EMAIL PROTECTED]>
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
Subject: Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile Software
Date: Wed, 08 Nov 2000 09:52:37 GMT
In article <[EMAIL PROTECTED]>,
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> Have you provided something of real use to any of us, besides your
> opinions?
Well, have you? A shitty coded XOR program, that is inherently
pointless and even more obviously badly coded?
I mean, _I_ could even write a more useful cross-platform XOR program in
Java if I had the time and didn't have to spend it making stupid
maze-solving programs.
--
Marcus
---
[ www.cybergoth.cjb.net ] [ alt.gothic.cybergoth ]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Andre van Straaten <[EMAIL PROTECTED]>
Subject: Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile
Software
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
Date: Wed, 08 Nov 2000 10:06:36 GMT
In sci.crypt Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> Andre van Straaten wrote:
>>
>> In sci.crypt Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>> > Tom St Denis wrote:
>> >>
>> >> In article <[EMAIL PROTECTED]>,
>> >> Hawke <[EMAIL PROTECTED]> wrote:
>> >> > sorry for the massive crosspost...
>> >> >
>> >> > too bad this software is winblows only.
>> >> > it'd be nice to have an app like this in linux...
>> >>
>> >> You are kidding right?
>> >>
>> >> Tom
>> >>
>> >> Sent via Deja.com http://www.deja.com/
>> >> Before you buy.
>>
>> > The software does what it says it does and this fellow seems to
>> > think he has need or feels he may have need for such a program.
>>
>> > So you feel you have the right and need to ridicule him?
>>
>> > Can you stoop any lower?
>>
>> > Show this fellow some respect and write him a similar program for
>> > Linux.
>>
>> > Here are the specs: the ability to select any two files from any
>> > two drives/directories and logically XOR them outputting the
>> > resulting file to any drive/directory. Stopping the XOR process
>> > upon reaching the end of file of the shortest file selected. And
>> > allow for any file length to be processed.
>>
>> Eh ... apart from the "unlimited" length of the file ...I read the
>> files into memory ...
>> I posted a Tcl/Tk file on alt.sources.crypto which does just this.
>>
>> If he has Tcl on his Linux box, he can use this in the meantime or
>> forever, until someone posts a C/C++ GUI version.
>>
>> If he can't access alt.sources.crypto, he can e-mail me.
>>
>> (But a few people only please, I don't want to become an "XOR"
>> monger.)
>>
>> -- avs
>>
>> Andre van Straaten
>> http://www.vanstraatensoft.com
>> ______________________________________________
>> flames please to [EMAIL PROTECTED]
>>
>> -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
>> http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
>> -----== Over 80,000 Newsgroups - 16 Different Servers! =-----
> At least you try.
> That's certainly more than just giving lip service.
I posted this piece of software only because someone indirectly asked for
it.
The OTP has only a few applications in real-life cryptography, but for
private people are there some interesting points as key management for
private people is somewhat different as in organizations.
I wrote this script particularly for my own needs and have no interest in
the work to be done to make it idiot-proof for every user and write a
short introduction about OTPs and XOR ciphers. I would take this a
responsibility.
The discussion in these threads began, as sci.crypt discusses (less often
in the last time) generally ALGORITHMS or PROTOCOLS with any relation to
cryptography.
The xor algorithm can be found in many FAQs of the frequent posters. Few
people discuss it.
Personal behavior and considerations why to use it seem also to me quite
irrelevant.
The problems started as you posted the promotion of your program in
different newsgroups where it might be appropriate, but unfortunately not
in sci.crypt, as there is no algorithm to discuss.
Many people in sci.crypt can write their own xor programs, at least
without GUI.
What people was concerned about is the fact that no source code has been
given and the program COULD bear additional hidden features as
backdoors, trojans, etc.
That there exist people who are not programmers and who are not interested
in cryptography, but want to encrypt their files, and have to be happy
with a solution like yours, is another point, which should also be
discussed better in the other NGs of your first postings.
It bears always various risks to use XOR and OTPs, without at least a
little knowledge about what somebody is doing.
I only hope that this was the last promotion of a program where is nothing
to discuss from the view of _sci_._crypt_.
If not it ends up in discussing programming techniques and compiler
settings, and everything ...
Many people subscribe to only a few NGs and discuss there everything,
alt.2600 is an example.
Well, I have to blame myself, too, as I easily get off-topic, and there
is a question which recently was a thread in alt.2600: Why do we respond
to these inappropriate messages, blow up irrelevant threads, and make the
NG more difficult to read ?
-- avs
Andre van Straaten
http://www.vanstraatensoft.com
______________________________________________
flames please to [EMAIL PROTECTED]
------------------------------
** 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
******************************
