Cryptography-Digest Digest #558, Volume #14 Thu, 7 Jun 01 21:13:01 EDT
Contents:
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mok-Kong Shen)
Re: Simple C crypto ("Dirk Bruere")
Re: Notion of perfect secrecy ("Jeffrey Walton")
Re: Notion of perfect secrecy ("Boyd Roberts")
Re: Simple C crypto ("Tom St Denis")
Re: Notion of perfect secrecy (John Savard)
Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and Large Primes
(David Wagner)
Re: PRP => PRF (TRUNCATE) (David Wagner)
Re: Any Informed Opinions? ("Jeffrey Walton")
Re: Medical data confidentiality on network comms (David Wagner)
Re: PRP => PRF (TRUNCATE) ("Tom St Denis")
Re: Some questions on GSM and 3G (David Wagner)
Re: Simple C crypto ("Dirk Bruere")
Re: DES not a group proof (David Wagner)
Re: MD5 for random number generation? (David Wagner)
Re: CBC variant (David Wagner)
Re: DES not a group proof ("Patrick Aland")
Re: Simple C crypto ("Joseph Ashwood")
Re: Alice and Bob Speak MooJoo ("Robert J. Kolker")
----------------------------------------------------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Thu, 07 Jun 2001 22:27:12 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (JPeschel) wrote in
> <[EMAIL PROTECTED]>:
>
> >Tim Tyler [EMAIL PROTECTED] writes, in part:
> >
> >>If you nitpick the examples without actually attacking the basic point,
> >>we will only find other ones.
> >>
> >
> >Tim, "we" appears to only you and maybe Dave. :-)
> >
> >You posted an example where you thought it was obvious that a
> >two-character encrypted response meant "no," and three letters meant
> >"yes." I pointed out that it isn't neccesarily so. You might as well
> >flip a coin.
> >
>
> Off hand I would say you have not seen many proofs or tests of
> theorms. You don't understand that it perfectly valid to define
> a system that contains 2 messages 'YES" and "NO". To reject it
> saying you want to do somthing else is irrelivent. I gave a model
> and showed "zero security". I don't care if you have other models
> since it only takes one failure to prove something is wrong.
By your logic RSA is an insecure system completely since it is possible to
make and use 32-bit primes.
Just because you mis-used an OTP doesn't make the OTP non-secure.
Typically if your situation calls for a boolean you dont send the ascii
"YES" or ascii "NO".
If you had a three letter call code you would use 3 ascii bytes.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Thu, 07 Jun 2001 22:29:33 GMT
"Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> : "Tim Tyler" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> :> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> :> : Perhaps if you defined your threat model this would make sense. Why
in
> :> : your world is knowing the length of the message a threat?
> :>
> :> See David's "Yes"/"No" example.
>
> : What 1/0? [...]
>
> No. Where the attacker has a priori knowledge that the message is going
> to be either "yes" or "no" - but doesn't know which.
That's just a contrived example of how to not use an OTP. Obviously in this
case the two messages are vastly different.
If your system calls for sending booleans send bits not ASCII words.
I mean seriously, outside of a contrived example an OTP is perfectly secure.
By this logic RSA is insecure because a naive user can make 32-bit primes,
or RC6 is insecure because you can supply 16-bit keys, or CTR mode is
insecure because you could have "THEANSWERISYES" and "NO" as texts, or BICOM
is insecure because the user could just forget to supply a key at all...
or...
Making contrived ways to break something is not only pointless but futile.
It proves nothing.
Tom
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Fri, 08 Jun 2001 00:26:38 +0200
"SCOTT19U.ZIP_GUY" wrote:
>
> [EMAIL PROTECTED] (Mok-Kong Shen) wrote in <3B1FBAF6.1DD02E47@t-
> online.de>:
>
> >
> >
> >"SCOTT19U.ZIP_GUY" wrote:
> >>
> >> [EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
> >>
> >> >Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >> snap...
> >>
> >> >To see how a particular 8 bit cyphertext could map to more than 256
> >> >different plaintexts, just get an 8 bit cyphertext, decrypt it with
> >> >BICOM under a number of keys.
> >> >
> >> >You will see *many* different plaintexts come out - not just 256.
> >>
> >> Mok likes to talk but getting him to actually do anthing
> >> is quite impossible. He would rather say its impossible than
> >> actually check it out. A lot like TOMMY. Sometimes I think
> >> He and Tommy are not real people. Since if they were you would
> >> think Wagner who at least pretends to know something about
> >> crypto would set them straight. Why he does not bother to
> >> make an honest useful comment on a thread like this makes
> >> me wonder just how much he wants the average person to know
> >> about crypto. He could help people like TOMMY on these concepts
> >> but refuses any useful real help. WHY??
> >
> >Argue with scientific stuffs. Don't waste bandwidth
> >like this! There are many who read this thread for
> >scientific reasons not for such stuffs, even if they
> >were valuable in a literature sense (This group has
> >the prefix sci.). Economize THEIR time! If you want
> >to scold me or do whatever in a negative sense on me
> >psychologically or otherwise, send e-mails to me
> >directly. I promise you in honest words that I'll read
> >every line you sent. (Response is however not
> >guaranteed.)
> >
> >M. K. Shen
>
> Acataully I have trusted you before and it was a
> mistake. Way back when we exchanged email several times.
> You and tom are just being asses. You may not be
> smart enough to understand "perfect security" But I
> give a model. Where like any model it can be used
> as a learning tool. The model was you answer either
> yes or no and you use an OTP. IF you use it the mode
> of TOMMY DUNGER HEAD you would send two characters for
> "NO" possiblely "WE" and three characters for "YES"
> possibly "DRF" in which case regardless of what you
> sent I know that exactly which message you sent. This
> is one way things are tested. You can see its not secure
> at all. Let alone "prerfectly secure". Instead of engaging
> your brain to realize that models shows your concept of
> an OTP being used for "prefect secrecy" is flawed you
> want to change the model. You seen to lack the intelligence
> that I don't need to change the model. Since that model
> shows your concept is false. Have you ever read his paper.
> If not I don't see what good talking to you is. I might
> as well aruge physics with a 3 year old.
I cannot reply better than what I already have written above.
D O N ' T W A S T E T H E B A N D W I D T H L i K E T H A T !
M. K. Shen
------------------------------
From: "Dirk Bruere" <[EMAIL PROTECTED]>
Subject: Re: Simple C crypto
Date: Thu, 7 Jun 2001 23:37:17 +0100
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote in message
news:uEJgR657AHA.262@cpmsnbbsa09...
> It won't take anything even approximating custom software to break your 16
> bit number scheme. The best advise I can give you without knowing a lot
more
> about what you need is to use a real encryption algorithm. If you want
more
> information than that I'd suggest you offer a respected person
> cryptographically a sum of money for consulting.
> Joe
Well, that's just not going to happen.
The requirement is for text comments (for example) to be written to a file
along with data. We simply don't want people to get into the file to read
and/or alter the text. We're not talking about professional hackers or the
NSA, just (say) lab technicians who use the equipment. Detecting alteration
of the text is something else.
So, no freeware solution to such a simple problem?
Dirk
------------------------------
Reply-To: "Jeffrey Walton" <[EMAIL PROTECTED]>
From: "Jeffrey Walton" <[EMAIL PROTECTED]>
Subject: Re: Notion of perfect secrecy
Date: Thu, 7 Jun 2001 18:42:40 -0400
: Also, it violates Shannon's perfect secrecy (which is what this
: thread is about).
Correct. My apologies.
"Tim Tyler" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
: Jeffrey Walton <[EMAIL PROTECTED]> wrote:
:
: : I think I understand your point with padding.
: : But I'm not sure I agree with it.
:
: : For example, if blocks are 64 Bytes, on average the last
: : block of 64 bytes will contain 32 padded bytes (again, on
: : average). This would imply that the adversary would know
: : what the plain text padded bytes are (some hand waving, but
: : a possible assumption). But this additional information
: : does not lend itself to plain text or key recovery (except
: : for the average of 32 trailing bytes).
:
: : I don't feel this is in opposition to Shannon's theories.
: : But there are clearly much more astute minds that visit this
: : NG. They could probably reveal my flawed thinking. I think
: : other cryptosystems could be vulnerable, but not the one
: : time pad.
:
: The OTP leaks information about the length of the plaintext.
:
: This is a clear security hazzard, and it may be necessary
: to take stops to prevent this information being used by the attacker.
:
: Also, it violates Shannon's perfect secrecy (which is what this
: thread is about).
:
: The OTP that is proven perfectly secure is in a system where only
: plaintexts of a given length are possibilities. That is not the
: OTP as commonly used.
:
: : For whatever reason, padding may be beneficial; but I don't
: : feel its required for the OTP. I also don't feel it
: : compromises the plain text either.
:
: It's lack gives away the length of the plaintext - a clear
: route for possible compromises.
: --
: __________
: |im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: "Boyd Roberts" <[EMAIL PROTECTED]>
Subject: Re: Notion of perfect secrecy
Date: Fri, 8 Jun 2001 00:50:52 +0200
"Tom St Denis" <[EMAIL PROTECTED]> a écrit dans le message news:
XrIT6.49363$[EMAIL PROTECTED]
> By your logic the TIME you send the message leaks just as much information
> as the LENGTH of the message.
time does leak information. that's what traffic analysis is all about.
even if you can't decrypt 'em the variation of the frequency of messages
tells you something is up.
isn't this the DC pizza delivery metric?
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Simple C crypto
Date: Thu, 07 Jun 2001 23:00:45 GMT
"Dirk Bruere" <[EMAIL PROTECTED]> wrote in message
news:gjTT6.16622$[EMAIL PROTECTED]...
>
> "Joseph Ashwood" <[EMAIL PROTECTED]> wrote in message
> news:uEJgR657AHA.262@cpmsnbbsa09...
> > It won't take anything even approximating custom software to break your
16
> > bit number scheme. The best advise I can give you without knowing a lot
> more
> > about what you need is to use a real encryption algorithm. If you want
> more
> > information than that I'd suggest you offer a respected person
> > cryptographically a sum of money for consulting.
> > Joe
>
> Well, that's just not going to happen.
> The requirement is for text comments (for example) to be written to a file
> along with data. We simply don't want people to get into the file to read
> and/or alter the text. We're not talking about professional hackers or the
> NSA, just (say) lab technicians who use the equipment. Detecting
alteration
> of the text is something else.
>
> So, no freeware solution to such a simple problem?
There are tons of public domain crypto tools (tools = algorithms). Whether
your a competent enough cryptographer to use them is another question.
Also if your application that you distribute can read these "magically
encoded files" then so can anyone else. This is a re-hash of the
CSS/SDMI/etc designs. Here's a tip, they don't work.
If you application is based on secrets like passwords or what have not just
use a cipher like Blowfish in CTR mode to encode the files. Alterations
will show up in the plaintext but if you need more assurance append a hash
of the pre-image to the plaintext. That should stop all attacks on "the
math". At that point it's upto physical and password security.
Tom
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Notion of perfect secrecy
Date: Thu, 07 Jun 2001 23:01:34 GMT
On Thu, 7 Jun 2001 00:39:15 -0700, "Neil Couture"
<[EMAIL PROTECTED]> wrote, in part:
quoting David A. Scott:
>> DUH??? GEE WHIZ length may mean something so pad to make it
>> match longest message for "perfect security" READ SHANNON YOU IDOIT
>> you can't have it both ways little BOY.
>Maybe i read Shannon wrong but as I understand a key of lenght n is enough
>for encrypting
>a msg of lenght n. that's it.
You're both right.
If the longest message has length N, but your current message is of
length n (and includes an end-of-message indication) you only require
a key of length n for perfect secrecy, because the N-n bits remaining
may be generated at random by the sender without the intended
recipient requiring any additional key bits.
John Savard
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and Large
Primes
Date: Thu, 7 Jun 2001 23:57:10 +0000 (UTC)
Joseph Ashwood wrote:
>Take a simpler
>problem 1+1=2, everyone learns that in 1st grade (some earlier, some a
>little later), but it takes a doctorate in mathematics, and a few hundred
>pages of very intricate math to prove it without assuming things.
Bah. One cannot prove 1+1=2 without assuming things.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: PRP => PRF (TRUNCATE)
Date: Fri, 8 Jun 2001 00:03:51 +0000 (UTC)
Tom St Denis wrote:
>Reading the paper David pointed to a bit ago I see they have one way to go
>from PRP to PRF by truncating bits of the output.
>
>Obviously there will be alot of PRPs that make the same PRF. Wouldn't a
>better method of truncating be reducing modulo a prime?
No. Any unkeyed map g:Y->Z that is k-to-1 (i.e., any g such that
#{y in Y : g(y)=z} = k for all z in Z) is no better or worse than
truncation. This is easily seen; here is a sketch of a proof
outline. Truncation is a k-to-1 map. Moreover, if g,g' are any
pair of such maps, then there exists a bijection p:Y->Y so that
g' = g o p. Consequently g' o E_k is a secure PRF if g o E_k is
(since p o E_k is a uniformly random permutation if and only if E_k).
In other words, all ways of truncating the output of a PRP are
equally good (so long as they are unkeyed and balanced). All that
matters is how many PRP-outputs are mapped onto a single PRF-output.
------------------------------
Reply-To: "Jeffrey Walton" <[EMAIL PROTECTED]>
From: "Jeffrey Walton" <[EMAIL PROTECTED]>
Subject: Re: Any Informed Opinions?
Date: Thu, 7 Jun 2001 20:09:24 -0400
Quantum cryptography has been demonstrated at AT&T labs (is the lab
correct?) upto a distance of about 15 km in a fibre. This number has
probably improved. Bennet and Brassard built the protoype. See the
section Technical Limits in Quantum Cryptography in
http://www.aro.ncren.net/phys/proceed.htm for a more complete treatment
(but somewhat out of date). A recent but less technical article can be
found at http://www.wired.com/news/privacy/0,1848,40969,00.html
The computers that will factor and solve DLP are still in their infancy.
>From what I understand, they have been demonstarted; but only exist for
less than nanoseconds. I don't have a reference for the demonstartion.
I think it was read in a journal.
It does not appear a quantum computer will break a quantum cryptosystem.
A quantum computer will probably break all classical computer based
cryptosystems. Mollin, An Introduction to Cryptography, p.267.
"Robert J. Kolker" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
: Does anyone have informed opinions
: on what influence quantum computing
: will have on cryptography and
: cryptanalysis?
:
: Qbits are alive and real. It remains to
: be seen if genuine computers can be
: made from them.
:
: Bob Kolker
:
:
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Crossposted-To: comp.security.misc
Subject: Re: Medical data confidentiality on network comms
Date: Fri, 8 Jun 2001 00:07:55 +0000 (UTC)
Barry Margolin wrote:
>If we could trust all professionals to act ethically, we wouldn't need
>privacy laws in the first place.
I disagree. A big part of the problem of medical privacy is
that it's not just doctors who have access to my data: It is
insurance companies, law enforcement, receptionists, databases,
accountants, ... Many of those are not trusted to the same
extent that doctors are (and probably for good reason).
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: PRP => PRF (TRUNCATE)
Date: Fri, 08 Jun 2001 00:15:50 GMT
"David Wagner" <[EMAIL PROTECTED]> wrote in message
news:9fp4p7$2s77$[EMAIL PROTECTED]...
> Tom St Denis wrote:
> >Reading the paper David pointed to a bit ago I see they have one way to
go
> >from PRP to PRF by truncating bits of the output.
> >
> >Obviously there will be alot of PRPs that make the same PRF. Wouldn't a
> >better method of truncating be reducing modulo a prime?
>
> No. Any unkeyed map g:Y->Z that is k-to-1 (i.e., any g such that
> #{y in Y : g(y)=z} = k for all z in Z) is no better or worse than
> truncation. This is easily seen; here is a sketch of a proof
> outline. Truncation is a k-to-1 map. Moreover, if g,g' are any
> pair of such maps, then there exists a bijection p:Y->Y so that
> g' = g o p. Consequently g' o E_k is a secure PRF if g o E_k is
> (since p o E_k is a uniformly random permutation if and only if E_k).
>
> In other words, all ways of truncating the output of a PRP are
> equally good (so long as they are unkeyed and balanced). All that
> matters is how many PRP-outputs are mapped onto a single PRF-output.
Wow. That's the first math related concept I understood in a long time.
So the short of it. My method of reducing modulo a prime is no better
since it could be made by another random k => 1 map...?
Makes sense!. Thanks for the precise reply :-)
Tom
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Crossposted-To: alt.privacy
Subject: Re: Some questions on GSM and 3G
Date: Fri, 8 Jun 2001 00:16:47 +0000 (UTC)
Arturo wrote:
> - It seems like the GSM consortium is updating its algorithms: COMP128-2
>(to replace COMP128) and A5/3 (a stronger version than A5/1). Anybody got
>confirmation?
I've found a number of official GSM documents discussing this, so I
presume it is coming, but I don't know first-hand. I just did a google
search (or maybe I looked through the GSM documents available online at
ETSI, I can't remember).
I hope you'll post a summary of what information you were able to find!
------------------------------
From: "Dirk Bruere" <[EMAIL PROTECTED]>
Subject: Re: Simple C crypto
Date: Fri, 8 Jun 2001 01:18:28 +0100
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:xITT6.52725$[EMAIL PROTECTED]...
>
> > The requirement is for text comments (for example) to be written to a
file
> > along with data. We simply don't want people to get into the file to
read
> > and/or alter the text. We're not talking about professional hackers or
the
> > NSA, just (say) lab technicians who use the equipment. Detecting
> alteration
> > of the text is something else.
> > So, no freeware solution to such a simple problem?
> There are tons of public domain crypto tools (tools = algorithms).
Whether
> your a competent enough cryptographer to use them is another question.
I don't have to be a competent crypographer if someone else has done the
work.
I use other peoples programs to do jobs so I don't have to write them
myself, or even know how they work. Am I supposed to be able to code .jpg
before I can embed a picture viewer?
> Also if your application that you distribute can read these "magically
> encoded files" then so can anyone else. This is a re-hash of the
> CSS/SDMI/etc designs. Here's a tip, they don't work.
The files are output from a data logger, we just don't want people casually
changing the data.
I rather doubt the ability and motivation of normal users to reverse
engineer the application to determine the crypo method in order to change
the comments in a file. If they are that keen then they will have faked the
whole thing from start to finish. The algorithm is not in a file viewer they
will have access to, unless, of course, they do that reverse engineering.
They can encode a comment (if it is theirs), but not decode anything.
All I am looking for is something that will require a few hours of work by a
competent engineer with the right tools to break. That is the level of
deterrence required.
> If you application is based on secrets like passwords or what have not
just
> use a cipher like Blowfish in CTR mode to encode the files. Alterations
> will show up in the plaintext but if you need more assurance append a hash
> of the pre-image to the plaintext. That should stop all attacks on "the
> math". At that point it's upto physical and password security.
Done a search on Blowfish, but could not find any code. If its more than
about 100 lines of C then I'm not interested. I just need a key of length N,
and two functions
#include "encryption.h"
CString Encrypt( Cstring )
CString Decrypt( Cstring )
something as simple as that to drop into existing code.
Dirk
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: DES not a group proof
Date: Fri, 8 Jun 2001 00:20:56 +0000 (UTC)
Patrick Aland wrote:
>Anyone got a link to the proof from Crypto '92 that showed that DES is
>not a group? The links I seem to be finding are either dead or simply
>reference it.
Why not get it from the library? Not all papers are available online.
(Failing that, you can call Springer-Verlag and order the proceedings,
or even order their CD-ROM with scanned versions of the proceedings.)
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: MD5 for random number generation?
Date: Fri, 8 Jun 2001 00:22:41 +0000 (UTC)
Phil Carmody wrote:
>A first guess is that it is used to hash a selection of
>not-on-their-own-particularly-random values together, and use that as a
>seed for a more traditional generator? (e.g. Process ID, CPU tick count,
>time, IP stack activity, detuned frame-grabber input.)
That's about right. See http://www.cs.berkeley.edu/~daw/rnd/
for quite possibly more detail than you ever wanted to know
about this topic.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: CBC variant
Date: Fri, 8 Jun 2001 00:24:37 +0000 (UTC)
This uses two block cipher encryptions per block of plaintext,
so the performance cost is large. Probably it will be much better
to simply change session keys before you get near the birthday limit;
CBC mode is fine so long as you don't try to go beyond the birthday
bound.
------------------------------
From: "Patrick Aland" <[EMAIL PROTECTED]>
Subject: Re: DES not a group proof
Date: Fri, 08 Jun 2001 00:24:57 GMT
Unfortunately my campus library isn't the best stocked.
While I realize that not all are available online it was still frustrating
to see lots of papers from Crypto'92 online but this one absent.
"David Wagner" <[EMAIL PROTECTED]> wrote in message
news:9fp5p8$2s77$[EMAIL PROTECTED]...
> Patrick Aland wrote:
> >Anyone got a link to the proof from Crypto '92 that showed that DES is
> >not a group? The links I seem to be finding are either dead or simply
> >reference it.
>
> Why not get it from the library? Not all papers are available online.
> (Failing that, you can call Springer-Verlag and order the proceedings,
> or even order their CD-ROM with scanned versions of the proceedings.)
>
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Simple C crypto
Date: Thu, 7 Jun 2001 17:14:06 -0700
"Dirk Bruere" <[EMAIL PROTECTED]> wrote in message
news:gjTT6.16622$[EMAIL PROTECTED]...
>
> "Joseph Ashwood" <[EMAIL PROTECTED]> wrote in message
> news:uEJgR657AHA.262@cpmsnbbsa09...
> > It won't take anything even approximating custom software to break your
16
> > bit number scheme. The best advise I can give you without knowing a lot
> more
> > about what you need is to use a real encryption algorithm. If you want
> more
> > information than that I'd suggest you offer a respected person
> > cryptographically a sum of money for consulting.
> > Joe
>
> Well, that's just not going to happen.
Sorry, my personal policy is that I do solid consulting for free if the
result will be free, I charge if you will charge.
> So, no freeware solution to such a simple problem?
There are plenty of them; FEAL, Rijndael, Twofish, Serpent, Blowfish, 3DES,
DES, RSA, ElGamal, RC2, ARC4, SHACAL, MacGuffin, Leviathan, CAST, MARS,
SKIPJACK just to name a few off the top of my head (by the way several of
the ones I listed are weak, one of them almost as weak as your idea). Of
course if you'd like to figure out which one you should use that's a much
more difficult question.
Joe
------------------------------
From: "Robert J. Kolker" <[EMAIL PROTECTED]>
Subject: Re: Alice and Bob Speak MooJoo
Date: Thu, 07 Jun 2001 20:56:42 -0400
Joseph Ashwood wrote:
> Actually it is not entirely difficult to solve for a language given a
> significant sample. This is aptly demonstrated by the work that was done to
> decipher Egyptian Antiquities before the discovery of the translation tablet
> (it gave conjugations and translations to/from latin/ancient greek/ancient
> egyptian). Prior to that discovery there was a body of knowledge that had
> been gained about what each symbol meant, and the linguists were actually
> getting close to decipherment of several of the texts, which would have
> quickly led to decipherment of many others. The discovery of the carved
> tablet expedited this process, but was not solely responsible for this.
> Using a unique language does not mean that it will not be recovered.
The Rosetta stone helped a bit. In fact, w.o. the Rosetta Stone and
a correlation to a known language (i.e. Greek) hieratic and hyroglyphic
Egyptian would still be a mystery.
Bob Kolker
------------------------------
** 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
******************************
