Cryptography-Digest Digest #94, Volume #10 Sun, 22 Aug 99 16:13:03 EDT
Contents:
Re: Quadibloc VI Taking Shape
Re: Angewandte Kryptographie von Bruce Schneier (Ted Kaliszewski)
Where to find (John)
Can I export software with decryption code only? (John)
Re: What is "the best" file cryptography program out there? (John)
Re: Can I export software with decryption code only? (SCOTT19U.ZIP_GUY)
Re: Ciphile Software (Jerry Coffin)
Re: Ciphile Software (Jerry Coffin)
Re: Quadibloc VI Taking Shape (wtshaw)
Re: Blowfish algorithm - Is it full proof? (wtshaw)
Re: all or nothing (wrapped pcbc) (Tom St Denis)
Re: Ciphile Software (JPeschel)
Key exchange options? ("Kasper Pedersen")
elliptic curve primality proving ("John Lampe")
Re: Where to find (David Hamilton)
Re: Blowfish algorithm - Is it full proof? (David A Molnar)
Re: CRYPTO DESIGN MY VIEW (Mok-Kong Shen)
Re: Ciphile Software (Enterrottacher Andreas)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Quadibloc VI Taking Shape
Date: 22 Aug 99 15:00:46 GMT
[EMAIL PROTECTED] wrote:
: At
: http://www.ecn.ab.ca/~jsavard/co040709.htm
: is a description of Quadibloc VI
: I'll be
: adding the key schedule later.
Well, the key schedule is now added, in all its baroque complexity.
John Savard
------------------------------
From: Ted Kaliszewski <[EMAIL PROTECTED]>
Subject: Re: Angewandte Kryptographie von Bruce Schneier
Date: Sun, 22 Aug 99 11:25:10 -0500
It is refreshing to see a message in a language other than English. The
German text of the leading message is clear enough, however, I do not own
the book in question in either the English or German version, so I am
sorry I cannot help you.
------------------------------
From: John <[EMAIL PROTECTED]>
Subject: Where to find
Date: Sun, 22 Aug 1999 08:33:19 -0700
http://www.aasp.net/~speechfb
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: John <[EMAIL PROTECTED]>
Subject: Can I export software with decryption code only?
Date: Sun, 22 Aug 1999 08:49:29 -0700
I don't think there is any restriction, but you can check
the DoD or Dept. of commerce for regulations. You aren't
really putting out anyting that would endanger the
national security, are you?
http://www.aasp.net/~speechfb
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: John <[EMAIL PROTECTED]>
Subject: Re: What is "the best" file cryptography program out there?
Date: Sun, 22 Aug 1999 08:55:25 -0700
I'll wait for the video.
http://www.aasp.net/~speechfb
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Can I export software with decryption code only?
Date: Sun, 22 Aug 1999 18:02:25 GMT
In article <[EMAIL PROTECTED]>, John <[EMAIL PROTECTED]> wrote:
>I don't think there is any restriction, but you can check
>the DoD or Dept. of commerce for regulations. You aren't
>really putting out anyting that would endanger the
>national security, are you?
>
I think the only thing that really damages the national security
is clinton's whole sale give way to china of out nuclear weapons.
All kidding aside it the "endanger the national security' is a fucking
joke. AES is more apt to endanger it. But as far as legality goes it
is purely arbitrary. Why do you think the prison population is at
an all time high. Anything you do is illegal if some one in power
wants it to be.
Look the former CIA directory got caught with highly classified
secrets on his machine does he go to jail. No but a kid in portland
who had music recordings on his harddrive that people could get
access gets canned.
Which rasies one more question. Microtrash or whatever as come
up with an encryption shceme that allows people to "only play"
the music when they pay them bucks. Is it illegal to give this
kind of software. OF course someone already write unfuck.exe to
remove the trivial encryption protection that microsoft has on it.
>http://www.aasp.net/~speechfb
>
>* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
>The fastest and easiest way to search and participate in Usenet - Free!
>
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Crossposted-To: talk.politics.crypto
Subject: Re: Ciphile Software
Date: Sun, 22 Aug 1999 11:05:09 -0600
In article <7pon8p$54s$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> > in many cases, they do things like storing an encrypted key,
> > then decrypting it at run-time and comparing it to the key you typed
> > in. It's trivial to run things like this under a debugger and get
> > the key to decrypt something almost without doing any real work at
> > all.
>
> Generally though this type of attack isn't even remotely possible.
> Otherwise many systems would fail. It's easier for example to exploit
> a bad RNG when examining public keys then it is to drivel thru a HD
> that you can't actually touch.
Would that you were right -- unfortunately, I've personally broken
about a half dozen (or so) products in roughly the fashion I describe.
Others have done the same in similar ways as well. The problem is
that you're just not taking into account how awful the designs of many
real products truly are.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Crossposted-To: talk.politics.crypto
Subject: Re: Ciphile Software
Date: Sun, 22 Aug 1999 11:05:07 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> I don't suppose retrieving the software and looking at the
> included help files would tell you what you want to know, would it?
It might -- based on what's easily seen on the web page, I think it
would be a waste of time though. Finding proof one way or the other
is of little interest to me. It's a bit like deciding whether I
should take up a new hobby: when something interests me, I might get
involved in it, and eventually it might become a hobby. Life,
however, is too short for me to try absolutely everything, so I don't
spend a lot of time trying to do things that (at least initially)
strike me as boring and stupid.
> Apparently it seems better to you to refer to the software as garbage
> (indirectly, of course). Btw, if you want to know something about the
> software, why not just ask him? Anthony has been very willing to answer
> just about any question I've ever put to him.
Aye, there's the rub. I _don't_ want to know any more about the
software. Reading the web page for 10 minutes or so left me wanting
to take a shower, not wanting to investigate it further.
> I'm not saying the Ciphile software is the be-all and end-all of
> OTPs. But claiming that it probably uses a stream cipher when you
> obviously haven't even taken the time to look at it is really weird to me.
I took the time to look at their web page, and based on it, I'm pretty
sure I spent more time on it than it really deserves. I'm not going
to try to spend the next week trying to defend my position -- you
asked for opinions and you got one. Since you're now making it quite
apparent that you were NOT really asking for opinions, but for
confirmations of a position you've already taken, so be it. I'm not
going to sit around arguing about it.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Quadibloc VI Taking Shape
Date: Sun, 22 Aug 1999 12:00:25 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] () wrote:
>
> Well, the key schedule is now added, in all its baroque complexity.
>
Whatever turns you on....but, seriously, keep up the good work. Baroque is
apt to be dull, and pursuit of the undull is worthwhile.
--
All's fair in love, war, and crypto. ERACE
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: comp.lang.clipper,comp.security.misc
Subject: Re: Blowfish algorithm - Is it full proof?
Date: Sun, 22 Aug 1999 11:32:45 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Dave Hazelwood) wrote:
> Humm....does this mean that if after encrypting a file with blowfish I
> change a few bytes here and there that it becomes even more secure?
>
.....
>
> Seriously...can the experts out there comment on whether changing
> say a dozen random bytes in a Blowfish encrypted file is a worthwhile
> step to improve security?
Many of the exprets fear that you will trifle with their ciphertext and
add to the root security, but any additional chained steps, of say
transposition, may muck up hacking lots of algorithm, particularly if you
do it seemlessly. The odds of weakening the underlying process are slim,
poor, and nil. Experiment and see where minor modifications can have the
most effect.
An attacker would be confronted with not knowing that a change was made,
much less where to start shuffling things about. There are lots of
possibilities beyond simple shifting of two characters in ciphertext, like
reversing the whole or part of it. Simple substitution of some or all of
the characters may have a *nice* effect.
The bully boys would have you not be able to do these things, but they
can't prevent it by law or actuality since computers are *so* flexible,
and you can edit anything you originate to your heart's content.
--
All's fair in love, war, and crypto. ERACE
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: all or nothing (wrapped pcbc)
Date: Sun, 22 Aug 1999 18:24:38 GMT
In article <7poo7q$5j9$[EMAIL PROTECTED]>,
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
> It is best to not do what PGP (at least in there DOS
> version). They allow a very short amount of work to be
> done to test the key. This reduces the work of the attackeer.
> I think it is Ok to have a fast check such as going a pkzip
> of the encrypted file. This expands the file and allows one a
> "small level of confidence" that the file was recieved correctly
> but it does not allow the attacker to get any information about
> the encrypted file. Yes an attacker could change the encrypted
> text and change the outside CRC so that you think you have a valid
> file. But when you decrypt the file you would get garbage since
> WPCBC is for "all or nothing encryption".
Are you really that off-beet?
Let's see 128-bit IDEA key, even if you could do a million searches per
msec, it would take 2^72 years (avg).
Still by not knowning the key the attacker doesn't get any further
info. The hash won't match wheter you are using ECB, CBC or your
wpcbc. They won't get the plaintext unless they know the key either...
So I ASK AGAIN, what is the benefit? Either the attacker has the key
or he doesn't. Where does 'flipping one bit' come into this?
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Ciphile Software
Date: 22 Aug 1999 18:35:35 GMT
Tom St Denis <[EMAIL PROTECTED]>writes:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Jerry Coffin) wrote:
>> They don't tell us what (if anything) they do about key management,
>> how they hash pass-phrases to derive keys, etc., etc. Even if we
>were
>> to blindly assume that they encryption they're using is itself highly
>> secure, they might well have all sorts of other problems. If you
>look
>> around at breaks on encryption programs (as opposed to encryption
>> algorithms) you quickly find that lots are based on absolutely STUPID
>> things in the programs, and it wouldn't matter what algorithms they
>> used -- in many cases, they do things like storing an encrypted key,
>> then decrypting it at run-time and comparing it to the key you typed
>> in. It's trivial to run things like this under a debugger and get
>the
>> key to decrypt something almost without doing any real work at all.
>
>Generally though this type of attack isn't even remotely possible.
>Otherwise many systems would fail. It's easier for example to exploit
>a bad RNG when examining public keys then it is to drivel thru a HD
>that you can't actually touch.
Yes, Jerry's attack is possible and it works with a
lot of real-world, commercial,crypto systems. The attack
assumes we know which crypto system is used and that
we have access to the victim's computer or, at
least, to all of his ciphertext. It's helluva
lot of easier than cryptanalysis and faster.
It's also the same sort of technique known to
any regstration cracker. The method, when used
against a crypto program takes advantage of
major implementation errors.
First, set a breakpoint on a Windows API
(getwindowtexta, getdlgitemtexta, hmemcpy),
enter a bad password, look for the
comparison of the bad and good password. In
the case of UBE98 (it uses RC4) the good password
is revealed about as fast as you can type.
In other cases, the code can be re-assembled,
while its running, to force the good password
to be compared to itself.
Sometimes, as I'm sure you know, it's not
quite so easy. If, however, the password is
still handled poorly, it can be traced,
reverse-engineered, and often, a dedicated
crack can be written for the systems.
Examples, of course, are on my web page.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: "Kasper Pedersen" <[EMAIL PROTECTED]>
Subject: Key exchange options?
Date: Sun, 22 Aug 1999 20:38:10 +0200
I've been searching the web for a key exchange protocol, like
Diffie-Hellman, and have
been unable to find any source whatsoever.
If I want a common-key-establishment-method (like DH), what are my options?
Second, DH is relatively heavy to do, how is this solved in smaller
appliances like GSM phones?
/Kasper
------------------------------
From: "John Lampe" <[EMAIL PROTECTED]>
Subject: elliptic curve primality proving
Date: Mon, 23 Aug 1999 02:48:09 -0000
where could I find an algorithim that would demonstrate elliptic curve
primality proving (preferrably in C)?
thanks in advance
John
------------------------------
From: [EMAIL PROTECTED] (David Hamilton)
Subject: Re: Where to find
Date: Sun, 22 Aug 1999 19:10:15 GMT
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
(snip)
> Your a very dishonest man and I use that term losely.
In other words, your usage has no meaning. And I guess it's pointless to ask
for your 'evidence'.
> Bescasue my writting
>sucks and I think your an asshole. You feel that you have to tell
>beginners that my software program is weak.
They are not the reasons at all. What I do is to repeat things you have said,
compare what you have said with other information and draw my own
conclusions. Other people can draw different conclusions if they wish.
To choose just one example among many, it is a fact that you said you
designed all the algorithms and code used in your software. Contrast that
with the fact that the algorithms used in PGP were developed by teams of
cryptographers with distinguished reputations. This is just one reason why I
suggest to beginners that they don't use your software.
> Well you don't have a fucking
>clue as to if is weak.
There are a number of clues that lead me to conclude that it is almost
certain that your software is much, much weaker than, eg, PGP. One of them is
above and a couple more appear later.
>Even Wagner who at first thought it might be weak was
>wrong and appeartly accoording to Joe P. had the balls to admit it. But
>since you lack the mental ability to test code you have to make judgements
>with out any real tests.
Firstly, you have no evidence that I am unable to 'test code'. Secondly, you
have failed, and continually fail, a number tests. Some of these are:
1) you have poor natural language (English) skills and this may be a
programming (nb not just a coding) risk;
2) you have declined to give information about the formal inspection
processes used in your development method.
>As if your fucking judgements mean shit.
So why worry?
>My code
>is better than any thing you can code.
Whether or not this is true is irrelevant. (Incidentally, I see you are still
fixated on code: you don't mention any other parts of the system development
process or lifecycle.) For example, if I make an average of 1 error in every
2 lines of code and you make an average of 1 error in every 3 lines of code,
your code is better than mine ... but your code is still not 'good'.
>IF you don't like my style tough shit
>but that is no indication that the code is weak.
>It just shows your a belly
>aching asshole with nothing better to do. Than to try to make fun of one
>poor
>in English.
But, as I said above, poor natural language (in your case, English) skills
may mean poor programming skills.
>But your judgements have nothing to do with scott16u or scott19u.
>But I doubt you have the brains to understand this.
My judgements have to do with any of your software to which the above facts
apply. Once again though, your whole 'argument' is based on insults instead
of facts. I wonder why.
David Hamilton. Only I give the right to read what I write and PGP allows me
to make that choice. Use PGP now.
I have revoked 2048 bit RSA key ID 0x40F703B9. Please do not use. Do use:-
2048bit rsa ID=0xFA412179 Fp=08DE A9CB D8D8 B282 FA14 58F6 69CE D32D
4096bit dh ID=0xA07AEA5E Fp=28BA 9E4C CA47 09C3 7B8A CE14 36F3 3560 A07A EA5E
Both keys dated 1998/04/08 with sole UserID=<[EMAIL PROTECTED]>
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
Comment: Signed with 2048 bit RSA key
iQEVAwUBN8BAwMo1RmX6QSF5AQHiUwf+LPUpMrXIaxyfXX5jwFOHh3Yvn+xQFVS3
TCeOq7iLBbf8So75koiZXLsB8F8k0dB0MB1NML5uxmS9RPJe51zm53j4/+//I95n
edch7aSA/+GF4RFKOB4YnNz1DsKbc5iz5iQUh2zLxRt7343JtxrxcJcvavwejOSM
WhUUsl3ehWMcycwizYuWnI7A6Qid/gdnmIqJoOR27Va6ea3kD67bushPaEG7BL8I
04zcCIyeZ2flN9DvNNUXQi58rwcbSYsAO4Xe4ylaQQTC/XE7JPC84VW/M8f9RDI7
aoGZSb+w9o9Ud0CmHiI91TZwpC2zmw5gFln5N4bFnNmQ6fdZt9ncDA==
=aucT
=====END PGP SIGNATURE=====
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.clipper,comp.security.misc
Subject: Re: Blowfish algorithm - Is it full proof?
Date: 22 Aug 1999 19:05:52 GMT
In sci.crypt Dave Hazelwood <[EMAIL PROTECTED]> wrote:
> Humm....does this mean that if after encrypting a file with blowfish I
> change a few bytes here and there that it becomes even more secure?
> 1. Because even if the key should be compromised or found only I
> know that the 69th byte was changed from 13 to 22 and must be restored
> before the message can be decrypted?
Note that this makes the series of changes part of the key. You still
need to keep it safe, remember it, etc. etc. In particular, you don't want
to build it into your decryption program if you're worried about the
adversary gaining access to your computer.
Depends on what chaining mode you use. With ECB, for a pathological
example, only that block is corrupted. Ideally you want something which
will munge all the plaintext from flipping one ciphertext bit. Plus makes
it difficult to tell which block the error occurs in.
-David
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Sun, 22 Aug 1999 20:58:56 +0200
SCOTT19U.ZIP_GUY wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> >In the detailed example I gave the 9 bits were 0 10111010. You
> >agreed above that these are all written out. So the 'correct' file
> >terminates there (with neither additions nor deletions that could
> >take place with your modified Huffman scheme in other more general
> >situations). Hence we don't have disagreement as to the content
> >of the last 2 bytes of the 'correct' output file. I must nevertheless
> Your word "correct" is misleding and wrong. File A which
> is a compress file ends in 2 byte in byte 1 there is 7 bits for the x's
> the remaining 9 bits forn the next huffman symbol. When the
> file is decompressed you get 2 8 bit characters for these lats 2
> symobls.
To be exact, you can't say how many input symbols are obtained from
the x's. For instance, it could be that there are Huffman codes
that occupies only 3 x positions. All one knows (by our assumption)
is that the last 9 bits of the original output file constitute one
single Huffman code and therefore these 9 bits will be decompressed
to one input character (which, if it is 8 bit ASCII, occupies a byte).
But this fact is unimportant for the present discussion.
> In your next example the compressed file is shorter by one byte
> so the symobl that has the X token is followed by the trailing zero
> bit. When decompressed you get exactly the same as first file
> except that it is shorter by one character. Note neither is correct
> or incorrect they are just two seperate cases. And the mapps
> are still one to one for the cmpressed and decompressed files
EXACTLY here has been my question all the time!! What does your program
do with the 0 bit????? If on decompressing the wrong file one simply
gets one character less (in comparison to decompression of the original
output file) as you said above, then it means that your program simply
ignores the hanging unprocessed (undecodable) 0 bit (or bits in a more
general situation). Am I right??? (If not, please say so.) Now if yes,
it means that your program simply suppresses the message of abnormality
which it should display according to elementary requirements of program
correctness. (Do you accept any software, crypto or not, that fails
to report abnormal conditions to you???) But your original claim was
that any abnormalities should not be detectable by the analyst. Do
you think that simply because the particular program written by you
purposedly (and incorrectly) suppresses (conceals) the error message
he wouldn't be able to detect the error situation that results
at the end of the processing??? (He can either write his own program
that does not suppress the error message or else do some simple fixes
to your program!!)
>
> >take this opportunity to say here that I have never understood
> >why you ever attempted to omit writing certain bits out at the end
> >of the process in case the (unmiodified original) Huffman algorithm
> >generate these. Why did you ever do modifications to a well-known
> >algorithm?? Why did you want to make the output file a (very) tiny
> >bit shorter at all?? Does the saving of one single byte count in
> >practice? How many bytes does an output file in practice have? Have
> >you ever computed for a concrete example in practice the percentage
> >of your 'saving'?? By how much have you complicated your program
> >logic through your persuit for this trivial 'economy'? Further,
> >since your device (modification) has not been discussed and examined
> >in the public, I can't even be sure that your modification is sound
> >theoretically. (Sorry to say that. Note that a discussion in the
> >public presupposes that you explain your modification either in plain
> >English or else in precise and short pseudo-code and not require
> >others to dig into your lenghty C code or, even worse, to simply run
> >tests with the program!)
> It is sound I have never found a failure in the one to one mapping.
> Obviously the saving in space is best for small files. The reasin I made
> it one to one. Is so that no information leakage. If the file is not one to
> one if you compress anad then encyrpt the file. Lets say an enemy gets
> the file. He tries a key ( or math reduction of some type) He then exaims
> the output file that was produced with the guessed key. He then notices
> that when he decompress the file and recompressed the file is not the
> same. There fore the key was wrong and he goes on to next key. That
> is why the one to one feature is critical. But I bet you haven't the foggest
> notion of what I am saying.
Sorry that I am not absolutely sure whether I correctly understand
your term 'one to one' above. Do you mean here the same thing that
we have been arguing till now, namely whether a 'wrong' file (in my
example simply with 8 bits missing, in the more general case almost
entirely different from the original compressed file due to usage of
the wrong key in decryption) can be decompressed without abnormality?
If yes (I guess so), then please see my answer above concerning the
processing of the hanging 0 bit. If not, please kindly explain.
Any way, it is well-known in software engineering that absence
of errors (found todate) in actual runs does not prove the absence
of bugs. Similarly one has to show in the present case that
the algorithm (i.e. your modification to the Huffman algorithm)
is correct. In order for that to be done, you have to present
what you have done to the public in the way I suggested previously.
M. K. Shen
------------------------------
From: Enterrottacher Andreas <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Ciphile Software
Date: Sun, 22 Aug 1999 21:15:05 +0200
"[ Dr. Jeff ]" schrieb:
>
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Jerry Coffin) wrote:
> >
> >I suspect you'll find a comparison of Ciphile's web site with the
> >Snake Oil FAQ quite interesting. IIRC, the Snake Oil FAQ itself will
> >tell you that the degree of similarity doesn't guarantee that
> >Ciphile's product is garbage, but it certainly gives a strong
> >indication. Just for the most obvious example, almost anything that
> >tries to compare itself to a one-time pad is nearly guaranteed to have
> >problems. This usually means little more than that they're using a
> >stream cipher, but the fact that they don't just say that is
> >indicative of problems by itself.
>
> I don't suppose retrieving the software and looking at the
> included help files would tell you what you want to know, would it?
> Apparently it seems better to you to refer to the software as garbage
> (indirectly, of course). Btw, if you want to know something about the
> software, why not just ask him? Anthony has been very willing to answer
> just about any question I've ever put to him.
>
> I'm not saying the Ciphile software is the be-all and end-all of
> OTPs. But claiming that it probably uses a stream cipher when you
> obviously haven't even taken the time to look at it is really weird to > me.
I had a look at the descriptions that were at the webpage as well as at
the helpfiles that contained that same information.
The program uses definitively a stream cipher that was developed by
Anthony.
I don't think anybody tried a cryptanalysis since it is very hard to
separate the real information from all the claims and other comments on
the page and to use this information to reconstruct the algorithm.
Andreas Enterrottacher
[EMAIL PROTECTED]
[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
******************************
