Cryptography-Digest Digest #984, Volume #9 Wed, 4 Aug 99 11:13:03 EDT
Contents:
Re: Infallible authentication scheme (Michelle Davis)
Re: With all the talk about random... (Dave Knapp)
Re: The Acronym MDC (Paul Gover)
Re: Is this procedure sound ? (JPeschel)
Re: Help with caculation (Francois Grieu)
Re: Is this procedure sound ? (Krunoslav Leljak)
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a Byte?)
(Anders Thulin)
Re: OTP export controlled? (W.G. Unruh)
Re: Americans abroad/Encryption rules? (W.G. Unruh)
Re: Blowfish x86 assembler (Gord)
Re: Americans abroad/Encryption rules? (Serge Paccalin)
Construction of permutation matrix ("Kwong Chan")
Re: Construction of permutation matrix (Robert Scott)
Re: Prime numbers wanted (Paul Crowley)
Re: How to keep crypto DLLs Secure? (John McDonald, Jr.)
Microsoft Word 97 (Nicolussi Paolaz Walter)
Re: Prime number. (John McDonald, Jr.)
Re: Prime number. (Paul Koning)
Re: CFB mode with same initialization vector (Paul Koning)
Re: Americans abroad/Encryption rules? (wtshaw)
Re: Americans abroad/Encryption rules? (wtshaw)
Re: Construction of permutation matrix (wtshaw)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Michelle Davis)
Subject: Re: Infallible authentication scheme
Date: Wed, 04 Aug 1999 06:53:24 GMT
On Tue, 03 Aug 1999 13:55:28 GMT, [EMAIL PROTECTED] wrote:
>Even if
>you know 159 bits of the 160 bits input you shouldn't be able to guess
>the last bit with a probability p != 1/2. Otherwise the hash function
>is not strong.
>
>So even if you know R and I, but not A (say A is 160 bits, R is 128 and
>I is 64). You can't learn anything about A from R or I. The only
>method left to attack would be to guess A. A replay attack would not
>work since you have the counter. Both sides would share (A, I)
>(privately) and R can be generated anyway they want (as long as it's a
>good quality PRNG).
>
>Tom
Of course, you're right. But since the security requirements of the
scheme are extreme, there is the possibility that someone will try to
utilise known elements in the string to be hashed (in your example,
A||R||I) to facilitate a dictionary attack (a dictionary attack tasked
at getting back to the hash input from the MD, and discovering your
secret key A). There just wouldn't be sufficient entropy in the
message digest if you know half the hash input, and so your attacker
might just try to "guess," and could succeed. At least, that's what
I've been advised by someone who develops solutions quite similar to
this (not a cryptographer, I should mention). If it's complete
bollocks, let me know, but I thought there was something to this
entropy business, so I threw in DES to make it totally foolproof.
Michelle
p.s. Just thinking about this - if you're trying to get back to your
hash input from a truncated SHA-1 message digest, you essentially have
to find on the order of 2^80 collissions until you get to the correct
512-bit string. Now, any known elements in your hash input would
greatly narrow this down, since you'd know that the correct string can
only end with R||I. This brings you down to far less than 2^80
collissions (how much less, I can't say). Van Oorson and Wiener
estimate a six million dollar machine (in today's terms) can find a
collission in SHA-1 over twenty days or so. If the number of
collissions was reasonable, some kind of net-based massive parrallel
attack would then be able to compromise my scheme. With 3DES thrown
in, they can brute-force it for the next quarter-million years, and it
wouldn't do them any good.
------------------------------
From: Dave Knapp <[EMAIL PROTECTED]>
Subject: Re: With all the talk about random...
Date: Wed, 04 Aug 1999 07:52:27 GMT
Andras Erdei wrote:
>
> Jim Felling <[EMAIL PROTECTED]> wrote:
>
> >It is IMPOSSIBLE to do. Quantum phenomena are FUNDAMENTALLY unpredicatble,
> >and indeterminate. There are physical quantities such that the
> >error_in_measurment_Q1* error_in_measurment_Q2 >= fixed constant.
> >
> >This results in those phenomena being FUNDAMENTALLY indeterminate.
>
> Isn't it just a model?
>
> [Which means that those phenomena are not necessarily "FUNDAMENTALLY
> indeterminate" (although personally i'd like them to be such).]
No, it's not just a model. There are experiments that back it up. That
makes it a theory.
Go look up Bell's inequality and the EPR experiment; papers about those
will explain the issues and experiments quite well, I think.
-- Dave
------------------------------
From: Paul Gover <[EMAIL PROTECTED]>
Subject: Re: The Acronym MDC
Date: Wed, 04 Aug 1999 10:02:50 +0100
John Savard wrote:
>
> I had thought that MDC stood for Message Digest Code, but according
> the Handbook of Applied Cryptography, it stands for Modification
> Detection Code!
> ...
I think Modification Detection Code is IBM usage. I suspect Message
Digest Code came from academia. Fortunately, most uses of Message
Digests are for Modification Detection :-)
Paul Gover
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Is this procedure sound ?
Date: 04 Aug 1999 09:12:08 GMT
<[EMAIL PROTECTED]>
>I would like to know if the following procedure is a sound one, if this is
>stupid please tell me.
>
>Encrypt the plaintext with something like Blowfish.
>Use PGP to encrypt the Blowfish output so that it may be transmitted by
>e-mail etc.
>
>The Blowfish key is personally handed to the proposed recipient.
>The PGP key would be a public one as normal.
Sound? Maybe. Redundant? Yes.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (Francois Grieu)
Subject: Re: Help with caculation
Date: Wed, 04 Aug 1999 11:51:17 +0200
[EMAIL PROTECTED] wrote:
> How should I select the values of e and d if I want to encrypt a message
> m of 64 bits, so that a hacker using a 300Mb/s PC can't crack the code
> by brute force attack in a month?
>
> RSA Algorithm
>
> n=pq
> ed=1 mod (p-1)(q-1)
> c=m^e mod n
> m=c^d mod n
We'll assume the hacker knows n e c and has a 300 MHz PC.
[If the attacker only knows c, drop RSA and simply use XOR with a random
constant key if you encipher a single message, or single DES with a random
constant key if you encipher a few million messages.]
To decrypt m , the hacker can
1) factor n; this might be attempted using a public domain program avaible
on the internet if n is say 320 bits, or if n has been choosen poorly,
or compromised; decipherement is trivial once n is factored.
2) guess m and verify by computing m^e mod n and comparing with c ; a
random 64 bits message is not guessable with the mentionned hardware, but
if the message is an english word in ASCII a dictionnary attack will
succeed.
3) if e=3 we have m^e < n for any decent n. In this case c = m^3
so recovering m from c is simply computing a plain cube root. The
attack is easily extended to the case where m^e / n is small enough to
be enumerated.
The above problems are usually avoided by
1) carefull choice of p q ; a 512 bit key generated according to
X9.31-1998 is probably out of reach from your hacker.
2) padding enough randomly choosen bits to m , making it unguessable;
these bits are removed in the decryption process.
3) choosing e big enough or padding enough prescribed bits to m ,
making is about the size of n; these bits are removed in the decryption
process.
If this is an exercise in which you can't specify m p q n, the right
answer might be: choose e odd, relatively prime to p-1 and q-1, and at
least (96+log2(n))/(64-48) which makes 3) unlikely to suceed; then
compute d as the multiplicative inverse of e mod (p-1)(q-1).
Francois Grieu - Innovatron
------------------------------
From: Krunoslav Leljak <[EMAIL PROTECTED]>
Subject: Re: Is this procedure sound ?
Date: 4 Aug 1999 10:10:30 GMT
JPeschel <[EMAIL PROTECTED]> wrote:
: <[EMAIL PROTECTED]>
:>I would like to know if the following procedure is a sound one, if this is
:>stupid please tell me.
:>
:>Encrypt the plaintext with something like Blowfish.
:>Use PGP to encrypt the Blowfish output so that it may be transmitted by
:>e-mail etc.
:>
:>The Blowfish key is personally handed to the proposed recipient.
:>The PGP key would be a public one as normal.
: Sound? Maybe. Redundant? Yes.
Maybe a short explanation why...
Redundant is encryption with Blowfish, why...
Because PGP does same job...
So,
Text -(Blowfish)->Ciphertext -(PGP-> Ciphertext
or
Text -(PGP)-> Ciphertext...
Blowfish stage is redundand, except if you want double encryption
with two different algorhythms...
Arivederci,
Kruno.
------------------------------
From: [EMAIL PROTECTED] (Anders Thulin)
Crossposted-To:
alt.folklore.computers,alt.comp.lang.learn.c-c++,comp.lang.c++,microsoft.public.vc.language
Subject: Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a
Byte?)
Date: 4 Aug 1999 13:03:55 +0200
In article <[EMAIL PROTECTED]>,
Jerry Coffin <[EMAIL PROTECTED]> wrote:
>Also note that contrary to an implication of an earlier post,
>orthodontia is NOT particularly related to orthodontics.
Yet I recall a note in one issue that a dentist had requested his
subscription to be cancelled.
But perhaps that was in one of the April issues?
--
Anders Thulin [EMAIL PROTECTED] 013-23 55 32
Telia ProSoft AB, Teknikringen 6, S-583 30 Linkoping, Sweden
------------------------------
From: [EMAIL PROTECTED] (W.G. Unruh)
Crossposted-To: talk.politics.crypto
Subject: Re: OTP export controlled?
Date: 4 Aug 99 11:28:09 GMT
Paul Koning <[EMAIL PROTECTED]> writes:
>"W.G. Unruh" wrote:
>> ...
>> >It is ludicrous to think that export regulations can really keep
>> >foreigners from implementing decent encryption.
>>
>> Not their purpose.
>It IS the stated purpose. It has to be for it not to be laughed
>out of the room.
>> Their purpose is to pervent US residents from providing
>> foreigners with decent encryption.
>I don't think so. If you mean the unstated purpose (or not so
>clearly stated purpose), that is to keep strong crypto out of
>the hands of US residents. Look at Freeh's testimony, it's
>clear enough if you read it carefully.
Freeh did not set up the crypto regulations. In fact under EAR the regulations
have been loosened up, not tightened.
The purpose of all export reguations is to prevent US citizens from supplying
things to foreigners. It says nothing anywhere that it is to prevent the
foreigners for doing things themselves. The stated or unstated purpose is not
to keep it out of the hands of citizensi, although it is clear that there are
some who would love to do that.
------------------------------
From: [EMAIL PROTECTED] (W.G. Unruh)
Subject: Re: Americans abroad/Encryption rules?
Date: 4 Aug 99 11:38:12 GMT
[EMAIL PROTECTED] (wtshaw) writes:
>In article <wgu20.933677090@riemann>, [EMAIL PROTECTED] (W.G.
>Unruh) wrote:
>>
>> (A) The access control system, either through automated
>> means or human intervention, checks the address of every
>> system requesting or receiving a transfer and verifies that
>> such systems are located within the United States or
>> Canada;
>Of course, if you hand someone a disk, you know where you are.
You forgot to include the previous sentences. This referes to transfer via the
internet (ftp web, etc)
...
>As crypto is of varied strengths, surely something like ROT13 is beyond
>any serious control regulations?
NO, it is controlled as well. (Of course whether they would actually prosecute
is another question.)
------------------------------
From: Gord <[EMAIL PROTECTED]>
Subject: Re: Blowfish x86 assembler
Date: Wed, 04 Aug 1999 07:14:09 -0500
[EMAIL PROTECTED] wrote:
>
> In article <[EMAIL PROTECTED]>,
> Gord <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] wrote:
> > [snip]
> > > If you could send the file(s) to '[EMAIL PROTECTED]' I wouldn't
> > > mind checking it out. no guarantees though. I promise I won't 'run
> > > off' with your code though.
> >
> > Is that the same empty promise you made when you ran off with SCOTT19U
> > ?! :P
>
> What are you talking about? I downloaded his code, posted my initial
> thoughts to the group. When I had severe questions like
Whoa Tom!
I was making a joke (hence ":P" above)
------------------------------
From: [EMAIL PROTECTED] (Serge Paccalin)
Subject: Re: Americans abroad/Encryption rules?
Date: Wed, 4 Aug 1999 14:20:04 +0200
Reply-To: [EMAIL PROTECTED]
On/le 4 Aug 99 11:38:12 GMT,
W.G. Unruh <[EMAIL PROTECTED]> wrote/a �crit...
> >As crypto is of varied strengths, surely something like ROT13 is beyond
> >any serious control regulations?
>
> NO, it is controlled as well. (Of course whether they would actually prosecute
> is another question.)
I don't think ROT-13 is controlled since there is no key, no secret
needed to access the info. Info is scrambled but not encrypted, just
as it woud be in case of compression, for example.
ROT-{n} where n is "secret" would be another matter.
--
___________
_/ _ \_`_`_`_) Serge PACCALIN
\ \_L_) [EMAIL PROTECTED]
-'(__) L'hypoth�se la plus �labor�e ne saurait remplacer
_/___(_) la r�alit� la plus bancale. -- San Antonio
------------------------------
From: "Kwong Chan" <[EMAIL PROTECTED]>
Subject: Construction of permutation matrix
Date: Wed, 4 Aug 1999 20:57:36 +0800
I am looking for algorithms to construct a permutation matrix from a random
seed.
For example:
Seed Permutation
000 -> (0,1,2)
001 -> (2,0,1)
:
:
111 -> (1,2,0)
Any suggestions are appreciated.
------------------------------
From: [EMAIL PROTECTED] (Robert Scott)
Subject: Re: Construction of permutation matrix
Reply-To: [EMAIL PROTECTED]
Date: Wed, 04 Aug 1999 13:39:41 GMT
On Wed, 4 Aug 1999 20:57:36 +0800, "Kwong Chan"
<[EMAIL PROTECTED]> wrote:
>I am looking for algorithms to construct a permutation matrix from a random
>seed.
>For example:
>
> Seed Permutation
> 000 -> (0,1,2)
> 001 -> (2,0,1)
> :
> :
> 111 -> (1,2,0)
This is not too difficult as long as you don't demand perfectly
uniform coverage. The number of permutations is not a power
of 2 like the number of seeds. But if the size of the permutation
is large and so is the seed, you can approach nearly uniform
coverage. The usual method is to use the seed to generate a
sequence of indices into the permuation array. Also generate
another (possibly fixed) sequence of indices. Then, for each
pair of indices, swap the indexed entries in the permuation
array. The number of swaps should be several times the
number of elements in the permutation array so that each
entry gets moved several times.
Bob Scott
Ann Arbor, Michigan (email: rscott (at) wwnet (dot) net )
(My automatic return address is intentionally invalid.)
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Prime numbers wanted
Date: 4 Aug 1999 09:56:31 +0100
"Vincent" <[EMAIL PROTECTED]> writes:
> Is there any faster algorithm than the following one, which, given an (odd)
> number n, returns the first prime number p>=n ?
> Assuming that I have a function is_prime tellimg me if a number is (or has
> enough odd to be) prime (The Miller-Rabin test).
Yes. Sieving can help a great deal. Use a mask of m bits to
represent the odd numbers between n and n + 2m -2 (assuming n odd);
choose m large enough that this interval is very likely to contain a
prime. Then set to 1 all the bits representing numbers divisible by
3, and repeat for a further 10,000 primes or so (this figure depends
on what n is and is fairly tricky to work out; for PGP we calculated
that it was worth storing all the primes below 65536). Each sieving
step has one expensive step, determining n % p_i where n is a bignum,
but actually knocking out the relevant bits once this is done can all
be done with standard integer arithmetic and is basically instant by
comparison. This leaves you with a list of candidate primes
represented by clear bits, which have already been tested for
divisibility against all the small primes. You can then test each in
order with Miller-Rabin.
If you're feeding a random n to the routine and hoping to get a random
prime back, however, note that it will be biased against primes that
are close to other primes; the lower of the pair will tend to shield
the higher from being found. Better to make m fairly big so the
interval is likely to contain several primes, then after the sieving
step, make a list of the candidates and shuffle it randomly before
going through it; this isn't wholly unbiased but it's better, and
improves as m gets larger.
hth,
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: [EMAIL PROTECTED] (John McDonald, Jr.)
Subject: Re: How to keep crypto DLLs Secure?
Date: Wed, 04 Aug 1999 14:16:59 GMT
On Wed, 4 Aug 1999 08:59:32 +1000, "Lyal Collins"
<[EMAIL PROTECTED]> wrote:
>What happens if the .EXE is modified ie the constant is changed to reflect
>the checksum of the changed/substituted .DLL ?
I hadn't considered this much, for the fact that I assumed
that the author of the program could take care of this himself. One
solution to this follows:
Once the program is compiled, run a checksum on the .EXE, and remember
this number, as a kind of passcode. Then you could simply create a
batch file that would checksum the .exe, pause, then run if you didn't
ctrl-C/Break. Why not remember the .DLLs Checksum? Well, this would
be okay if you are only working with a single DLL, but if you are
using several, you can have checksum tests for all of them in the
EXE, and you only have to remember the one. Now we get into a debate
Also, the question comes up now, can't someone just alter the checksum
command, so that it always comes up with the same or proper checksum?
Absolutely they can. But look at the problems with it.
1) Replacing the checksum before any of this takes place would require
that the attacker knew in advance something important was happening on
this machine.
2) Replacing the checksum after the DLL is compiled, but before the
EXE would take impecable timing, and would result in incorrect
results for the summation of the DLL, and so would cause the .EXE to
terminate.
3) Replacing the checksum after the EXE is compiled and summed would
be easiest, but the code to make sure that everything worked properly
would be fairly difficult.
>This is simply one extra step in an attack sequence - addmittedly targetted
>against a single program, and probably carried out in a script-like fashion.
There are always steps on any Windows machine I'm afraid. If
you want total security for any program, you have to move it to *nix.
I suppose you could even move it to NT, but I am really not convinced
on its security model. (But that's another thread and newsgroup
entirely).
[-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-]
John K. McDonald, Jr. Alcatel, USA
[EMAIL PROTECTED]
please remove -delete- for responses.
--
"I speak for me and not this company"
TO SPAMMERS:
Please view the definitions for
"telephone facsimile machine,"
"unsolicted advertisement," and the
prohibition and penalty for sending
unsolicited faxes before sending Un-
solicited Commercial E-mail to the
above address. Violators WILL BE
PROSECUTED. These can be found
in:
The Telephone Consumer Protection Act
of 1991, Title 47, Chapter 5,
Subchapter II, Section 227.
[=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=]
------------------------------
From: Nicolussi Paolaz Walter <[EMAIL PROTECTED]>
Subject: Microsoft Word 97
Date: Wed, 04 Aug 1999 15:19:43 +0200
Reply-To: [EMAIL PROTECTED]
I lost the password for a Microsoft Word 97 document.
Help me !!!
Thank's
NPW
------------------------------
From: [EMAIL PROTECTED] (John McDonald, Jr.)
Subject: Re: Prime number.
Date: Wed, 04 Aug 1999 14:01:38 GMT
On Tue, 3 Aug 1999 16:14:08 -0600, [EMAIL PROTECTED] (Jerry Coffin)
wrote:
>The most obvious method of doing this would be to use the Sieve of
>Eratosthenes. Running the Sieve on a 400 MHz Pentium II (with no
>particular attempt at optimization) the first 1,000,000 primes can be
>found in under .2 seconds. As I recall, there was a thread sometime
>back in which a clever implementation of the Sieve was used to find
>the first 200,000,000+ primes in around 2 minutes or so on a machine
>of roughly similar speed. I believe the thread included source code
>to a couple of different programs.
[*Ahem*]
I sit corrected. <G>
[-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-]
John K. McDonald, Jr. Alcatel, USA
[EMAIL PROTECTED]
please remove -delete- for responses.
--
"I speak for me and not this company"
TO SPAMMERS:
Please view the definitions for
"telephone facsimile machine,"
"unsolicted advertisement," and the
prohibition and penalty for sending
unsolicited faxes before sending Un-
solicited Commercial E-mail to the
above address. Violators WILL BE
PROSECUTED. These can be found
in:
The Telephone Consumer Protection Act
of 1991, Title 47, Chapter 5,
Subchapter II, Section 227.
[=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=]
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Prime number.
Date: Tue, 03 Aug 1999 18:26:41 -0400
"John McDonald, Jr." wrote:
>
> On Tue, 03 Aug 1999 10:15:52 +0800, Teh Yong Wei <[EMAIL PROTECTED]>
> wrote:
>
> >I have writing a simulation of elliptic curve cryptography. Can anybody
> >tell me that what is the best algorithm to generate random prime number
> >and why? Then, what is the most efficient way to prove that it is really
> >a prime number?
>
> As far as generating a random prime, you'll need someone elses
> response, but the fastest way to test a prime involves having all the
> primes less that the square root of your prime number. (So what
> you'll need to do is generate the first Z primes.)
No. That isn't even close to the best test.
Look for "Miller-Rabin primality test" in a good reference book.
(Scheier or Menezes).
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: CFB mode with same initialization vector
Date: Tue, 03 Aug 1999 11:45:45 -0400
Peter Pearson wrote:
>
> Daniel Vogelheim wrote:
> >
> > why is encryption in CFB mode insecure, if you use the same
> > initialization vector multiple times?
>
> The danger is that you might encrypt plaintexts whose
> beginnings are identical, thereby producing ciphertexts
> whose beginnings are identical. It is not respectable
> for an encryption system to reveal the fact that messages
> X and Y have the same beginning, even if the system doesn't
> reveal what that beginning is.
>
> If some convention in your plaintext guarantees that
> the first block of plaintext will be different every
> time, the system is as strong as the underlying block
> cipher, even with fixed IV. (Corrections, you other guys?)
No... And the reasoning is simpler than that.
CFB is a stream cypher, i.e., it generates a pseudorandom
bitstream which is XORed into the data. The bitstream
is fixed for a particular choice of key and IV.
So if you use the same IV twice, you use the same bitstream
twice. If the attacker has both cyphertexts, he can XOR them,
which cancels out the bitstream and gives him simply the XOR
of the two plaintexts. English language plaintext only has
a few bits of entropy per byte, so the XOR of two independent
English strings can be broken.
paul
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Americans abroad/Encryption rules?
Date: Wed, 04 Aug 1999 08:53:43 -0600
In article <wgu20.933766692@riemann>, [EMAIL PROTECTED] (W.G.
Unruh) wrote:
> ...
> >As crypto is of varied strengths, surely something like ROT13 is beyond
> >any serious control regulations?
>
> NO, it is controlled as well. (Of course whether they would actually prosecute
> is another question.)
Which demonstrates the silliness of the regulations. Any prosecution
would be thrown out of court be cause of its trivial nature, certainly
would bring a jury to tears of laughter if it ever got that far, and
highlight some improper aspects of the regulations.
--
MY lock, MY key.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Americans abroad/Encryption rules?
Date: Wed, 04 Aug 1999 08:56:43 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> On/le 4 Aug 99 11:38:12 GMT,
> W.G. Unruh <[EMAIL PROTECTED]> wrote/a �crit...
> > >As crypto is of varied strengths, surely something like ROT13 is beyond
> > >any serious control regulations?
> >
> > NO, it is controlled as well. (Of course whether they would actually
prosecute
> > is another question.)
>
> I don't think ROT-13 is controlled since there is no key, no secret
> needed to access the info. Info is scrambled but not encrypted, just
> as it woud be in case of compression, for example.
> ROT-{n} where n is "secret" would be another matter.
>
Under that argument, I could freely distribute any of my base translation
algorithms, fully implemented, as long as I made them only work with a
single key.
The proper next question if ROT13 is controlled would be what about the
ability to do all Caesar shifts, which includes the former.
--
MY lock, MY key.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Construction of permutation matrix
Date: Wed, 04 Aug 1999 09:07:14 -0600
In article <7o9cv1$[EMAIL PROTECTED]>, "Kwong Chan"
<[EMAIL PROTECTED]> wrote:
> I am looking for algorithms to construct a permutation matrix from a random
> seed.
> For example:
>
> Seed Permutation
> 000 -> (0,1,2)
> 001 -> (2,0,1)
> :
> :
> 111 -> (1,2,0)
>
> Any suggestions are appreciated.
This is a simple problem, but it thoughts it requires a middle to make it
work. Use any seeded generator to produce a series of characters in a
handy set; then, hash the output using a counting method to get the
permutation of the desired final set.
When I started doing lots of block ciphers which needed lots of
permutation keys, at first I included pseudorandom means. But, it seemed
more useful to instead work directly with text, which is more likely to be
what a user would like to do, enter text.
--
MY lock, MY key.
------------------------------
** 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
******************************
