Cryptography-Digest Digest #773, Volume #12 Mon, 25 Sep 00 18:13:01 EDT
Contents:
Re: On block encrpytion processing with intermediate permutations (Tom St Denis)
Re: Again a topic of disappearing e-mail? ("David C. Barber")
Re: Again a topic of disappearing e-mail? ("David C. Barber")
Re: What am I missing? (Scott Craver)
Re: Proper way to intro a new algorithm to sci.crypt? (SCOTT19U.ZIP_GUY)
Re: What make a cipher resistent to Differential Cryptanalysis? (Mok-Kong Shen)
Re: What make a cipher resistent to Differential Cryptanalysis? (Tom St Denis)
Re: What make a cipher resistent to Differential Cryptanalysis? (David Empey)
Re: Letter substitution decoder (David Eppstein)
Re: What am I missing? ("David C. Barber")
Re: What make a cipher resistent to Differential Cryptanalysis? (Mok-Kong Shen)
Re: Again a topic of disappearing e-mail? ("Paul Pires")
Re: Tying Up Loose Ends - Correction (Tim Tyler)
Re: Question on biases in random-numbers & decompression ("D.A.Kopf")
Re: HELP ME SOLVE THIS SECRET CODE... (daniel mcgrath)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: On block encrpytion processing with intermediate permutations
Date: Mon, 25 Sep 2000 20:57:49 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> I should very much appreciate comments on the following idea:
>
> Given a common block cipher of m cycles (for a Feistel
> cipher, a cycle means 2 rounds, i.e. processing steps
> resulting in all bits of the block being processed once),
> we can, in case of software implementation, does processing
> of one cycle for all blocks of the message, then perform
> a pseudo-random permutation of the words of the entire
> message, thus rearranging the contents of each individual
> block, before doing processing of the next following cycle
> (again for all blocks of the message), and so on till all
> m cycles are done.
>
> This seems to be a viable alternative to achieve interaction
> among blocks via block chaining. It may incur more computing
> costs. It offers on the other hand the means of introducing
> more secret informations than the key of the cipher, e.g.
> via the seed of a PRNG to effect the pseudo-random
> permutation. But one can also avoid providing that additional
> secret information by dividing the message into two halves
> and applying sorting of the words of one half to obtain data
> to rearrange the words of the other half and vice versa.
> (See the thread 'On pseudo-random permutation' initiated by
> me on 21st Aug. We neglect for our purpose here the fact
> that the bits in each half are unlikely to be sufficiently
> random.)
>
> Apparently, the scheme is not well suited for hardware
> implementation. On the other hand, the scheme could be
> scaled down in the sense that one does pseudo-random
> permutation of the bytes of the block, thus limiting
> all operations to within each individual block being
> processed.
>
> We note that for multiple encryptions with several block
> encryption algorithms, the pseudo-random permutation of
> the words of the message may also be done at the
> interfaces of the algorithms instead of at the interfaces
> of the cycles of the individual algorithms.
This only will work when
1) You both have the same PRNG, possibly key derivied, thus the PRNG
must be salted, or something
2) The messages are over several blocks long.
Still you have to consider the possibilty that some halves are not
mixed as well with the others (i.e disjoint cycles in the shuffling).
Consider the halves (paired means they go thru a cycle together)
R1: ab cd ef gh
R2: ac be df gh
R3: ae cf db gh
...gh is never moved...
Obviously that's not likely but low diffusion is a probable consequence
over the entire message with this scheme. It gets worse as the message
size increases... (more chance that two halves never interact, or
interact an equal amount of times).
It's a neat idea, but not terribly secure I would think.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "David C. Barber" <[EMAIL PROTECTED]>
Subject: Re: Again a topic of disappearing e-mail?
Date: Mon, 25 Sep 2000 14:13:43 -0700
I gather the only way this program can work is that the program itself is
required for display of the message. Each time the message is recalled for
display the program decides to either Display or Delete.
Otherwise I'd like to see how it deletes the backup copy on a
write-protected floppy disc.
*David Barber*
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> The following is in the ACM Technews:
>
> Email users will soon be able to erase the messages they send
> from the recipient's hard drive using software called SafeMessage
------------------------------
From: "David C. Barber" <[EMAIL PROTECTED]>
Subject: Re: Again a topic of disappearing e-mail?
Date: Mon, 25 Sep 2000 14:14:56 -0700
I'm tired of bashing "oil executives". I don't see you taking all uses of
their product out of your life.
*David Barber*
"Matthew Skala" <[EMAIL PROTECTED]> wrote in message
> An oil executive, huh? Sounds reptilian to me.
------------------------------
From: [EMAIL PROTECTED] (Scott Craver)
Subject: Re: What am I missing?
Date: 25 Sep 2000 21:17:16 GMT
Joseph Ashwood <[EMAIL PROTECTED]> wrote:
Hi,
>I am not in a position to make use of this idea at the moment, and I won't
>be until after the award period is over, so I'm going to publish it, and if
>it works, I hope someone will be kind. I am placing it in this thread
>because it very much applies to SDMI, and the difficulty in creating a
>watermark that can survive an attacker that is highly determined. The idea
>is thus:
This sounds like the notion of a detector mismatch attack,
the goal being not to destroy the mark but to make the detector
miss it. Sometimes these are based on invertible scrambling
operations, such that the messed-up audio/video/image can
be recorded, then un-messed before it hits a TV or speakers.
If you can do this, you can violate the Big Important Rule(tm)
of watermarking, towit: any operation that hurts the mark
distorts the media beyond usefulness. In this case you happily
distort the media beyond usefulness, knowing that later you
can resurrect it.
>Take the Stream S, seperate it by frequency (use low/high pass filtering at
>various frequencies) into several S[i] (where i goes from 0 to N). Using a
>good random number generator create a small random shift of the substreams
>S[i], call these T[i]. Generate a new stream T, which technically still has
>the watermark data (it should simply be illegible),
Well, this depends on whether the watermark is spread-spectrum
or narrowband. A narrowband signal may yet be detected in one of
the streams.
Also, the watermark is not necessarily additive, i.e. best
modeled as a signal added to the audio. I suspect that a few
wackier schemes could survive this attack.
Here's another idea: keep the audio in pieces, successfully
record each piece, and somehow rig it so the pieces can be
properly combined when played. I have doubts about this because
it seems SDMI might involve screening in players as well as
recorders. But if you can buy two cheap portable devices, and
somehow hook them both up so that you can start a track playing on
each isochronously, maybe you can play a trick.
A third idea, closer to a one-time pad: pick a wide-band
noisy signal S, and record both -S and SONG+S on separate tracks.
Combining these would be tougher because you'd really have to
do it in the digital domain, and they'd have to be synchronized
down to the sample or else you'd hear serious noise.
> Joe
Thanks,
Scott
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Proper way to intro a new algorithm to sci.crypt?
Date: 25 Sep 2000 21:12:52 GMT
[EMAIL PROTECTED] (Albert Yang) wrote in <[EMAIL PROTECTED]>:
>Thank you very much. I am just about finished with some preliminary
>crypto-analysis.
>
>This is my observation as far as new algorithm postings:
>
>First, there is Pedigree. When Bruce or Eli says they have a new
>algorithm, then people give them quite a bit of attention. But I feel
>rightly so, Pedigree plays a large roll, and so for a "newbie" to throw
>out a new algorithm for someone to take a look at, there is a hill to go
>over because there is no "name recognition". I mean, we know them on a
>first name basis, Lars, Eli, Bruce etc...
>
>So what I have done (what I am doing) to remedy this is that when I do
>stick my algorithm up for all of you wolves out there to tear apart, I
>will have done some preliminary crypto-analysis for it. I'll
>(hopefully) have pointed out some of the weaknesses of the algorithm. I
>think this, more than anything, shows that a lot of thought and care
>went into the algorithm, the writing of it, the architecture of it. I
>think this is the part that gives an algorithm credibility.
>
>Also, I hope that my documentation will be concise and clear. I give
>examples, sample code, sample reference code, sample optimized code, and
>describe in great details some thinking and logic behind the choices and
>selections made. Oh, and hopefully throw a little math and pepper in
>there to spice up the dish.
>
>I'm thinking (hoping) this is what the crypto community (specifically
>sci.crypt) would like to see as far as an algorithm release, and that
>any attacks that come this way will be against the algorithm itself, and
>not against me for making claims that just are unfounded and untrue, or
>for lack of leg work...
>
>But of course, every newbie has to make some rediculous claim, and so
>I'll do it below, so I will have gotten it out of my system and we can
>get on with real cryptoanalysis.
>
>Thank you all.
>Albert
>~~~~~~~~~~~~~
>
>My algorithm:
>
>cures cancer, athelete's foot, and cold sores.
>it is unbreakable,
>and most importantly, does not clash with plaid pants, a claim that
>cannot be said by any other algorithm in current existance.
>
I am glad it cures cancer. But to be honest if your method
is any good it is unlikely to recieve high praise here. If it is
easy to break and one that common newbies do. Then you may get a
response from Mr BS saying something to the effect that it's junk
and more proof to his claim that newbies can't design crypto.
If it is good you could get a comment from his side kick Wagner
who may says its "dead meat" and his slide attact proves it. But
of course Wagner will never test it. And if some kind person does
and then shows to people here the slide attack does not work on it.
Wagner will brush it off and say he really never followed what the
code did in the first place. But then of course of you don't
follow what actaully happens here you will never know.
But if your really lucky you may get into an excahnge with Ritter
or Mr Onions who would take the time to look at it and they would
give you honest anwsers that may be of some help.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: What make a cipher resistent to Differential Cryptanalysis?
Date: Mon, 25 Sep 2000 23:41:08 +0200
Tom St Denis wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >
> > Tom St Denis wrote:
> > >
> > > Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > > >
> > > >
> > > > "Paul L. Hodgkinson" wrote:
> > > > >
> > > > > "Mok-Kong Shen" wrote
> > > > >
> > > > > > No practical cipher is absolutely secure.
> > > > >
> > > > > Which isn't entirely true.
> > > > > A one-time pad can be shown to be theoretically unbreakable,
> which
> > > requires
> > > > > a random key of the same length as the message.
> > > > > Such a pad was used in the Cold War to encrypt communications
> > > between Moscow
> > > > > and Washington, sent by secure courier.
> > > >
> > > > The ideal OTP is 'theoretical' and, as you said,
> > > > 'theoretically' unbreakable. No practical 'ideal' OTP
> > > > exists (or knowable to be ideal, if given one),
> > > > however.
> > >
> > > Actually an OTP is unconditionally secure if you can't guess my
> secret
> > > pad better then a prob of 1/2. If I make a CDROM full of random
> bits
> > > (or two, one for either direction) and the CDs *are not* compromised
> > > then the communication is *provably* secure until the pads run out.
> >
> > The catch is with the term 'random'. The randomness
> > required by an ideal OTP, i.e. the exact theoretical
> > assumptions of it, cannot be absulutely verified for
> > any given sequence pretended to be an ideal OTP.
> > That's why an ideal OTP can't be obtained in practice,
> > even it could exist in the world according to theory.
>
> Are you sure about that?
>
> In the series "111111111111111" what is the next bit?
I am not sure of whether we are talking about the
same thing. Given a a source in practice, we have no
way of absolutely confirming that it satisfies the
assumptions for generating an ideal OTP. One can
tell that something does not satisfy being OTP,
e.g. a code that emits alternatingly O and 1. That
is, you could give negative answers but never positive
answers.
M. K. Shen
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What make a cipher resistent to Differential Cryptanalysis?
Date: Mon, 25 Sep 2000 21:24:18 GMT
In article <8qofdr$gq8$[EMAIL PROTECTED]>,
David Empey <[EMAIL PROTECTED]> wrote:
> In article <8qo99r$8tn$[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> > In article <[EMAIL PROTECTED]>,
> > Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > Tom St Denis wrote:
> > > >
> > >
> > > > Oh sorry, yes you're right. Let's consider DES with ultra weak
> > sboxes,
> > > > at most you add 8! work to the attack (or 16(8!) if you use
round
> > > > independent reorderings) which is not a heck of alot)
> > >
> > > But how LARGE would be the figure, if each round has a
> > > different ordering? And if one has 16 S-boxes available
> > > for choice?
> >
> > 16! is only 2^44 still not large enough.
>
> Not large enough for what? If you need to guess the s-box
> order to apply a differential attack, you've multiplied the
> time to crack the cipher by 2^44, haven't you? This would
> turn a 1-second attack into an effectively impossible one.
>
> Or do you have in mind some less obvious attack on
> key-dependent s-box order?
>
> And choosing a different order of (say) 8 different s-boxes
> for each of (say) 16 rounds gives (8!)^16 = about 2^245.
I meant with ultra weak sboxes... as if the sbox order is not enough.
And perhaps a diff will work in several perms.... anyways...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: David Empey <[EMAIL PROTECTED]>
Subject: Re: What make a cipher resistent to Differential Cryptanalysis?
Date: Mon, 25 Sep 2000 21:18:09 GMT
In article <8qo99r$8tn$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >
> >
> > Tom St Denis wrote:
> > >
> >
> > > Oh sorry, yes you're right. Let's consider DES with ultra weak
> sboxes,
> > > at most you add 8! work to the attack (or 16(8!) if you use round
> > > independent reorderings) which is not a heck of alot)
> >
> > But how LARGE would be the figure, if each round has a
> > different ordering? And if one has 16 S-boxes available
> > for choice?
>
> 16! is only 2^44 still not large enough.
Not large enough for what? If you need to guess the s-box
order to apply a differential attack, you've multiplied the
time to crack the cipher by 2^44, haven't you? This would
turn a 1-second attack into an effectively impossible one.
Or do you have in mind some less obvious attack on
key-dependent s-box order?
And choosing a different order of (say) 8 different s-boxes
for each of (say) 16 rounds gives (8!)^16 = about 2^245.
--
Cordially,
Dave Empey
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: David Eppstein <[EMAIL PROTECTED]>
Subject: Re: Letter substitution decoder
Date: Mon, 25 Sep 2000 14:26:32 -0700
In article <[EMAIL PROTECTED]>, mls wrote:
> am looking for a program that will try all possible letter substitution
> combinations, with small library of plaintext for matching. Maybe even
> in BASIC. Assumes that the text to be decrypted is simple substitution
> and not one time pad.
I just wrote a Java applet for this.
http://www.ics.uci.edu/~eppstein/cryptogram/
There are several others in different languages at
http://www.gtoal.com/wordgames/cryptograms.html
--
David Eppstein UC Irvine Dept. of Information & Computer Science
[EMAIL PROTECTED] http://www.ics.uci.edu/~eppstein/
------------------------------
From: "David C. Barber" <[EMAIL PROTECTED]>
Subject: Re: What am I missing?
Date: Mon, 25 Sep 2000 14:29:24 -0700
Digimarc can clearly be detected, because Digimarc does detect it.
If I had time and the curiosity (which I don't right now), I'd probably try
a before and after compare of a 1 pixel tiff file with a binary editor.
Reverse engineering the Digimarc plug-in would also be an attack if it
actually mattered enough to someone to break their system.
And since it's a plug-in, you can remove it if it is causing you grief.
I suspect that their watermark is for little more than proving that a
picture came from a known source, given that the source watermarks their
images.
"Scott Craver" <[EMAIL PROTECTED]> wrote in message
news:8qjnrr$r3$[EMAIL PROTECTED]...
> Here's a challenge for you: watermark an image in Photoshop
> using Digimarc's watermarking plug-in (last I checked this came free
> with Photoshop,) and see if you can gain ANY INFORMATION WHATSOEVER
> about how the watermark works just by clicking any of those buttons.
> Throw in a program to do various tranforms like DCTs or FFTs if
> you want.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: What make a cipher resistent to Differential Cryptanalysis?
Date: Mon, 25 Sep 2000 23:45:58 +0200
Tom St Denis wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >
> > Tom St Denis wrote:
> > >
> > > Oh sorry, yes you're right. Let's consider DES with ultra weak
> sboxes,
> > > at most you add 8! work to the attack (or 16(8!) if you use round
> > > independent reorderings) which is not a heck of alot)
> >
> > But how LARGE would be the figure, if each round has a
> > different ordering? And if one has 16 S-boxes available
> > for choice?
>
> 16! is only 2^44 still not large enough. Plus you need sufficient
> diffusion to make the cipher work.
The implicit assumption is of course that you have some
not too bad S-boxes.
M. K. Shen
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Again a topic of disappearing e-mail?
Date: Mon, 25 Sep 2000 14:41:48 -0700
David C. Barber <[EMAIL PROTECTED]> wrote in message
news:8qofbd$1np2$[EMAIL PROTECTED]...
> I'm tired of bashing "oil executives". I don't see you taking all uses of
> their product out of your life.
>
> *David Barber*
Er... Either you didn't get his joke or I didn't get yours.
The Oil executive in question is herptologic, not petrolum based.
Herpatologic? Snakes! man.
Paul
>
> "Matthew Skala" <[EMAIL PROTECTED]> wrote in message
> > An oil executive, huh? Sounds reptilian to me.
>
>
>
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Tying Up Loose Ends - Correction
Reply-To: [EMAIL PROTECTED]
Date: Mon, 25 Sep 2000 21:39:42 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> I was trying to talk about arbitrary-length padding - not just the case of
:> < 8 bits.
:>
:> The more padding there is, the more potential information you're giving
:> the attacker by using an "inefficient" representation of the length of the
:> padding.
: For padding to 64 bit block boundary, one needs only
: maximal 63 bits padding (per message).
I was still wanting to talk about adding "arbitrary" lemngths of padding
- with the idea being to hide the location of the message, and to conceal
the length of the message as far as is possible.
A 64-bit block boundary requires 6 bits of length specifier - I'd agree
that again, this isn't terribly much - even being able to reject 63/64
keys (which is a very pessimistic worst case) shouldn't normally be the
end of the world.
: I don't think there is sufficient amount there for predicting the
: pseudo-random source of the padding [...]
Ah, I was hypothesizing a genuinely random source, and asking what the
be way of using information from this as padding was, while retaining the
ability to distinguish the message from the padding.
: BTW, could you answer my question of whether Scott's
: 1-1 scheme can deal with arbitrary boundaries, since
: you are apparently fairly familiar with that?
I believe David found that Matt Timmerman's scheme could be simply adapted
to allow for abritrary block boundaries. IIRC David advised Matt of
this, and Matt implemented it. I might be making all this up, though ;-|
Anyway, on http://members.nbci.com/ecil/compres5.htm David has code that
bijectively goes to and from Matt's finitely odd files - i.e. binary
strings that end with a 1 followed by an infinite zero tail.
The code...
Converts to/from files made of any number of bytes;
Converts to/from even byte length files;
Converts to/from odd byte length files;
Converts to/from 8 bytes multiple file.
I don't know if David's used other types of granularity. I figure he
knows how to do it if he wants to.
His original compression programs only worked with byte-oriented files.
I don't know if this has changed since I last looked at them.
You could probably chain their output through the "finitely odd"
convertors, if you wanted other types of granularity.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: "D.A.Kopf" <[EMAIL PROTECTED]>
Crossposted-To: comp.compression
Subject: Re: Question on biases in random-numbers & decompression
Date: 25 Sep 2000 22:01:14 GMT
Reply-To: [EMAIL PROTECTED]
Trevor L. Jackson, III wrote:
>
> Bruno Wolff III wrote:
<snip>
> >
> > Since random bits are fairly valuable compared to a few cpu cycles,
> > you want to try to extract as much of the randomness as possible out of
> > the random bits you get.
>
> hrubin has posted on this topic several times. His generator consumes the the random
> stream one bit at a time capturing almost all of the entropy of source in the
>resulting
> stream of numbers. I'm sure you can find this on a usenet archive.
Why not just take enough bits from the random bitstream to get a max-min,
and add any remainder to the next chunk. E.G., for numbers in the range 6-10
take 3 bits modulo 5 and add 6. If the bits were 111 that would give 8 with
remainder 5 to be added to the next 1 bit chunk.
Isn't it that simple? What am I missing?
------------------------------
From: [EMAIL PROTECTED] (daniel mcgrath)
Crossposted-To: rec.puzzles
Subject: Re: HELP ME SOLVE THIS SECRET CODE...
Date: Mon, 25 Sep 2000 22:12:05 GMT
On Sat, 23 Sep 2000 04:05:50 GMT, "Supreme Commander"
<[EMAIL PROTECTED]> wrote:
>I live in Vancouver. A coworker and I went for a walk at lunch along the
>Fraser River yesterday and stopped to admire the river on a new boardwalk.
>On the wooden railing of the boardwalk, someone had written an encoded
>message in felt pen. I returned to the boardwalk today and wrote the
>message down.
>
>Maybe it is unsolvable, but maybe it isn't. Maybe it's just a joke. It's a
>real mystery to me. Who would bother to write this down unless they wanted
>to see if someone solved it? Or maybe it is intended for one person only?
>
>We noticed a lot of patterns, and the liberal use of 1s and 7s. We also
>noticed the "time stamp" on it of midnight. Maybe it was some drunk techie
>guys from Ballard Power having fun? Who knows? Does each "-" separate a
>character?
>
>Being engineers, we are trying to decode this message. Does anyone have any
>ideas? Any discussion? We've had a few ideas that haven't seemed to lead
>anywhere.
>
>Here is a copy of the message exactly as seen on the railing...
>
>--------
>
>1774-611713-407713-5324-5*11133713-8883
>
>~19~
>143-50-1771164-17-
>1771551176-11-70175-
>17-15-(09/15/00)-(11:57pm)-
>1177-43123-50-1-6817-
>7011-17-7411715-940-
>115-17-743-9857-7-
>177017745-17-485-
>83317-50-81113501773-
>111487-1113-48113-15-
>50-12381-1-48113-17311312-
>94317-7415-11184-
>83940123-11-12-743-
>612387357-741176-1-
>111177-10113-11-4-311312
> ~486~
>
>-------
>
>* = This may be a 5 or 3. It's hard to read. I think it's a 5. My friend
>thinks it is a 3.
>
>This was written beside the message...
>
>19-17-486-
>4-311312
I've been experimenting with this too, but I can't solve it. Since I
would like to know the solution (if there is one), I have added
sci.crypt so that some more expert cryptologists there may have a
better idea. I have vague thoughts that this may be some sort of a
"consonantal" cipher, with all the vowels removed.
BTW SupCom, in reference to:
>1774-611713-407713-5324-5*11133713-8883
you said:
>* = This may be a 5 or 3. It's hard to read. I think it's a 5. My friend
>thinks it is a 3.
In "5*11133713", is there a definite 5 in front of the digit you are
uncertain of? Or does the 5 in front of the asterisk merely represent
your guess as to what it is?
==================================================
daniel g. mcgrath
a subscriber to _word ways: the journal of recreational linguistics_
http://www.wordways.com/
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
