Cryptography-Digest Digest #922, Volume #10 Tue, 18 Jan 00 08:13:01 EST
Contents:
Re: ECC vs RSA - A.J.Menezes responds to Schneier (Safuat Hamdy)
Re: anyone heard of DDEZI encryption? (Jerry Coffin)
Re: how to encipher ([EMAIL PROTECTED])
Re: Why is EDI dead? Is S/MIME 'safe'? Who and why? (James Redfern)
Re: LSFR ("Michael Darling" noral<dot>co<dot>uk>)
Re: Triple-DES and NSA??? (John Savard)
Re: Forward secrecy for public key encryption (was Re: Question about ... Z*_n)
(John Savard)
Re: Forward secrecy for public key encryption (was Re: Question about ... Z*_n)
(John Savard)
Re: Mispronounce words. (OT Re: How to pronounce "Vigenere"?) (John Savard)
Re: Blowfish & pi. (John Savard)
Re: Forward secrecy for public key encryption (was Re: Question about ... Z*_n)
(John Savard)
Re: RSA (John Savard)
Re: Forward secrecy for public key encryption (was Re: Question about ... Z*_n)
(John Savard)
Re: Triple-DES and NSA??? (John Savard)
Re: Cracking an ADFGVX cipher (John Savard)
Re: My Encryption system (John Savard)
Re: Mispronounce words. (OT Re: How to pronounce "Vigenere"?) (John Savard)
Re: My Encryption system (John Savard)
Re: can someone encrypt for me? (John Savard)
Re: can someone encrypt for me? (John Savard)
----------------------------------------------------------------------------
From: Safuat Hamdy <[EMAIL PROTECTED]>
Subject: Re: ECC vs RSA - A.J.Menezes responds to Schneier
Date: 18 Jan 2000 09:19:59 +0100
Jose Castejon-Amenedo <[EMAIL PROTECTED]> writes:
> And we don't even know for sure if IF is NP.
Pardon? IF: Given n given x < n, has n a factor larger than x which is
smaller than n (yes/no) *is* definitively in NP. I'm sure you mean it is
unknown whether IF is NP-complete.
--
S. Hamdy | All primes are odd except 2,
[EMAIL PROTECTED] | which is the oddest of all.
|
unsolicited commercial e-mail | D.E. Knuth
is strictly not welcome |
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: anyone heard of DDEZI encryption?
Date: Tue, 18 Jan 2000 01:20:09 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> >
> >HeuyWorld wrote:
> >> supposedly produces text output where each byte displayed as 0 thru
> >> 9, represents between 28 and 51 characters with the majority being
> >> displayed as 0 thru 5. ?the final output can also be 'spun' in
> >> simulated-geometric patterns
> >
> >I think someone was pulling your leg.
> >
> Why?? could this NOT be able to be produced? ..
No, it could not. Many years ago a guy named Shannon did some studies
that showed that the "entropy content" of normal English text is
around one bit per character.
Even if we ignore encryption for the moment, that translates to the
fact that the best compression you could theoretically hope for would
encode each character of input using a single bit, giving a
compression ratio of approximately 8:1. There are really only two
ways to get compression better than that: restrict the possible
inputs, or else use lossy compression, which basically translates to
"compressing" by throwing away some of the content. In the case of
things like graphics, you can often use lossy compression perfectly
well (e.g. JPEG does so) but for things like text files or executable
files, your decompression has to yield the original file to be of any
real use.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: how to encipher
Date: 18 Jan 2000 05:34:24 -0500
Christopher <[EMAIL PROTECTED]> wrote:
> Yes, I know 2^17 mod n = (((((2^2 mod n) ^ 2 mod n) ^ 2 mod n) ^ 2 mod
> n) * 2 mod n, but M is a very large number that M^2 cannot calculate
> in my computer using long int. I am considering using the chinese
> remainder theorem to break it into 2 equation.
Well, one does have to take the product of two numbers (which can be as
large as n) modulo n. And your math system cannot handle M*M.
Can it handle an addition of two numbers mod n?
In that case, to get the square of a number u (u^2 mod n) you can
... break u up into its binary components!
Write u=SUM[b_j*2^j]
Consider u^2 mod n = (u*b_0 +u*2*b_1 + u*4*b_3...) mod n.
Consider the sequence:
u_0 = u
u_(j+1) = u_j+u_j mod n
(u_j=u*2^j mod n)
Now let
SQR=0:j=0
LOOP:
If b_j=1, SQR=SQR+u_j mod n
j=j+1
if not finished with all the bits in u, then GOTO LOOP:
(to calculate u*v mod n, expand v in binary and use the above)
(basically, one notes that u^2 mod n is just, by replacing one of the u's
by its binary expansion, the sum of terms u*2^j for those j where b_j<>0
(b_j is 1 or 0) - you can get the sequence of the u_j=u*2^j mod n by
successively doubling u_0=u mod n - similar to the way we got M^d by
expanding d in binary)
As your n satisfies 2n is smaller than the long integer limit on your
system (I hope) you can add things together mod n.
You can do the same thing to get u*v mod n (expand one of them, say, v in
binary and just successively double the other and accumulate the terms
where the bits in the second are not zero) (you need that to get
things line x_1*x_4 mod n, etc.).
Usually it is assumed you can do the multiplications of two numbers mod n
(in describing the way to calculate M^d mod n), but if you can't, to
calculate u*v mod n, all you need is another subroutine (to expand v in
base two and accumulate sums) and all you need be able to do, really, is
add two numbers mod n.
------------------------------
From: James Redfern <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,alt.security.pgp
Subject: Re: Why is EDI dead? Is S/MIME 'safe'? Who and why?
Date: Tue, 18 Jan 2000 11:11:37 +0000
Reply-To: James Redfern <redfern[AT]privacyx[DOT]com>
On Thu, 13 Jan 2000 20:07:54 GMT, Anne & Lynn Wheeler <[EMAIL PROTECTED]>
wrote:
| XML/internet, etc related EDI reasonably can move it into higher
| volume & lower valued transactions (lot of existing, more expensive
| EDI is wrapped around high value activities).
Just to conclude, thanks to you and others, here's my opinion.
The value in remote publishing at the DOD (Document on Demand) end is clear.
I also see that as e-Commerce grows out of the US, remote instruction and
billing is an ideal problem waiting for an XML solution. Both all of these
are subject to XML vagaries (The W3C and IETF are developing XML-aware
cryptography standards), which will take time to resolve. EDI applications
should become cheaper and faster to build with the spread of XML use. While,
doubtless, there has been an excessive amount of hype surrounding XML, it
seems to me its most promising domain of application will be EDI. The
resulting productivity improvements will be important for the continuing
prosperity of the world economy in general. Many commercial applications
already exist, and will appear, but until 'strong' security becomes
universally available, I do not yet see the so called 'killer application/s'
emerging in the XML realm.
The case for remote publishing can be one of logistics. For example, USA Today
has been operating multiple printing plants across the US to print their
nationally-distributed paper near where it is to be delivered. You can access
your corporate WAN and print documents at any office in the country. This is
really handy as you get a better quality document for folks at the remote
office to look at than I can by faxing it and it takes less time. But what if
I wanted to ensure that only one copy was made? Then connecting to the remote
printer and transmitting the job would be one way of being reasonably sure
that only one original copy was printed. The printer might be in a book store
and I might be printing a book on site.
Also, as its effective operation becomes global, e-commerce business will
start to need remote, variable output and billing as they evolve from their
current 'centralist' modality. You don't need to bring the goods from Taiwan
to the US in order to ship them back to your Japanese or Chinese customers.
But your US web-site does need to have a method to produce your Taiwan
warehouse pick-list and billing documents in Mandarin and Kanji.
If not 'terminally wounded', then EDI is certainly quite 'ill' as the standard
is usually associated with value-added networks which cost $$$/transaction.
The world is moving toward low-cost TCP/IP solutions such as 'extra-nets', but
the cost per transaction figure is still the 'great unknown'. AFP should
establish this figure for PR consumption and work hard to have the definitive
research associated with their name/product.
The biggest problem with EDI is in getting all implementations to interpolate.
The biggest role a VAN plays in the success of an extranet is its ability to
test implementations to insure interoperability. No small thing as format
errors can turn an order for a single item into a multi-truck delivery of the
things. VANs still have and will continue to have a roll to play.
The XML 'standard', isn't! There is a group currently working on the XML
version of X.12 but standards groups always move more slowly than the market.
There are some trading communities like Rosettanet for IT components that have
created their own XML standards, but there is nothing like universal consensus
out there. The XML-Based Standards section of DTD.COM (an online clearinghouse
of DTD standards and pseudo-standards), lists over 180 current XML-based
language standards, pseudo-standards and developing standards in progress. I
would expect that people will use S/MIME to embed XML data (as MIME object)
and that there might eventually emerge DTDs which describes how to embed
encrypted/signed data into XML.
The whole idea of web-based computing is that the heavy-duty computation is
done elsewhere and the average user only has a smart terminal. The S/MIME
transport structure over the Internet is up to the job if the selected crypto
algorithms are strong enough. However, without the crypto algorithms being
universally available, the solution is limited to specific extra/intra-net
users. Until this is resolved, it makes it almost impossible for companies in
the financial, insurance, stocks/shares transaction market-space to take up
the offer of using the Internet to transmit documents securely to their
customers. They are too paranoid, no matter what you or I believe to be the
reality.
Using XML technology as a means to link diverse data sources on the web is a
move to create an EDI-like standard for XML transactions. Basically, EDI
requires both agreement on the data elements that are to be exchanged as well
as the data formats (data type descriptions). In the XML world, you only have
to agree on the data elements to be transmitted (that is to say, what items
are part of a purchase order for example) and then establish a DTD that is
valid for linking a given buyer and seller. In the XML world, each pair of
buyer/sellers can have their own DTD such that legacy html web sites and/or
data formats can be used.
There is a lot of space for products that web-enable the vast wasteland of
'big iron' and client-server systems that are starting to appear on the scene.
Many good systems are being discarded just because they can't 'talk' on the
internet. Companies such as WebMethods already make tool-sets and are
supporting software servers that make such activities relatively easy.
That's what I think I've learned. Feel free to disagree.
JR.
--
James Redfern <redfern AT privacyx DOT com> The Redfern Organization
PGP key ID 0x8244C43A from <mailto:[EMAIL PROTECTED]?subject=0x8244C43A>
...ActiveNames delivers my undeliverable mail at <www.ActiveNames.com>
------------------------------
From: "Michael Darling" <michaeld<at>noral<dot>co<dot>uk>
Subject: Re: LSFR
Date: Tue, 18 Jan 2000 11:49:44 -0000
Thanks for your reply, I can't find this document on the web - plenty of
references but no actual content.
Anyone know if this doc is on line?
Cheers,
Mike.
Eric Bach <[EMAIL PROTECTED]> wrote in message
news:85vt7t$[EMAIL PROTECTED]...
> Here's some prior art:
>
> D.W. Clark, P.J. Bannon, and J.B. Keller, Measuring
> VAX 8800 performance with a histogram hardware monitor,
> Proc. 15th Ann. Intern. Symp. on Computer Architecture, pp. 176-185,
> 1988.
>
> The idea was to use LFSR's to rapidly collect some information that
> could then be recovered off-line by solving a discrete log problem. The
> LFSR was specially chosen to make the discrete log problem easy to solve.
>
> -Eric Bach
> [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: alt.privacy,alt.security
Subject: Re: Triple-DES and NSA???
Date: Tue, 18 Jan 2000 06:25:52 GMT
On Sat, 15 Jan 2000 03:41:19 GMT, Greg <[EMAIL PROTECTED]> wrote:
>Is Twofish a next generation work from Blowfish, or are they
>similar in name only?
I'd tend to say the latter, although others might dispute that.
>And can one use a key size larger than 256 on Twofish?
I'm not sure offhand, but I know several AES candidates do have
additional key size flexibility beyond the mandatory key lengths of
128, 192, and 256 bits.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Forward secrecy for public key encryption (was Re: Question about ...
Z*_n)
Date: Sat, 15 Jan 2000 14:48:25 GMT
On Sat, 15 Jan 2000 07:47:49 +0000, David Hopwood
<[EMAIL PROTECTED]> wrote, in part:
>Normally, I wouldn't trust an identity-based protocol, because
>the identity-based model has several inherent security problems:
> - the "trusted" authority has enough information to calculate
> any user's private key, and therefore is a weak point of the
> whole system (to a greater extent than root CAs in a CA-based
> system).
> - it's impossible for users to verify that their keys aren't
> being "escrowed".
> - private keys have to be sent from the authority to each user,
> which is likely to be another weak point.
>However, none of these objections apply to a forward-secure
>scheme constructed using this method, because each user is their
>own trusted authority.
I am puzzled about how such a scheme is going to work. If the
condition that must be fulfilled for an identity-based scheme is that
to send messages to user X, all you need to know is user X's identity,
and don't have to download a public key, then if I can compute the key
for sending messages to user X from that identity myself, and if user
X can compute the key for reading those messages himself from his
identity, doesn't it follow that *everybody* who knows user X's
identity can compute both keys, and read all the messages?
On the other hand, two users certainly can engage in ordinary
public-key communication without the help of a trusted authority, and
the identity can play some trivial additional role in complicating the
protocol without changing its security.
I hope you can supply a simple explanation of how what you are trying
to achieve differs from either of the two scenarios above, and can
genuinely be thought of as being, in some sense, an identity-based
scheme without a trusted authority (which would indeed be immensely
useful if it were possible).
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Forward secrecy for public key encryption (was Re: Question about ...
Z*_n)
Date: Sat, 15 Jan 2000 14:58:47 GMT
On Sat, 15 Jan 2000 07:47:49 +0000, David Hopwood
<[EMAIL PROTECTED]> wrote:
>The security property I'm trying to achieve is this: The validity
>period of each public key is split into several time periods,
>numbered say 1..T. Each time the current period changes, the
>holder of the private key applies a one-way "key evolution" function
>to his/her current private key value, and deletes the old value. When
>a message is encrypted, the current time period (say t) is specified
>as input to the encryption algorithm. It should not be possible to
>decrypt that message without having the private key value for
>period t or earlier.
Ah, so you're not trying to construct an identity-based encryption
scheme, you are merely using one as a component.
>The alternative approach involves constructing a forward-secure
>encryption scheme from an "ideal" identity-based encryption
>scheme.
>The basic idea is that the private key holder (Bob) takes on the
>role of the trusted authority (Trent) at key generation time, and
>then each of the users of the identity-based scheme in turn; each
>"user" corresponds to a time period.
In an identity-based scheme, Trent has to generate private keys whose
corresponding public keys are unpredictable small numbers
corresponding to the identities; the scheme is secure because the time
required to do this is large, but doing this once for all users is
acceptable, while doing it once to crack a single user's mail is not.
So in this type of method, both users, in order to communicate, have
to spend as much time computing as a cracker would to read their
messages! Unless one isn't using a totally "identity-based" scheme,
but is also using "Trent's public key" to carry part of the load.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Mispronounce words. (OT Re: How to pronounce "Vigenere"?)
Date: Tue, 18 Jan 2000 06:25:41 GMT
On Sat, 15 Jan 2000 01:24:00 -0500, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>Case in point: the reduction of all verbs to only five fundamental verbs as a
>basis for linguistic comprehension. The reduction causes so much loss of
>context that true comprehension is probably impossible.
Well, in Basic English that simply resulted in replacing every verb by
a unique combination of a verb and a noun or preposition. (e.g., "take
heart" or "go out")
That didn't change anything fundamentally, it simply required people
to learn an entirely new vocabulary for no particular reason.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Blowfish & pi.
Date: Sat, 15 Jan 2000 14:29:39 GMT
On Sat, 15 Jan 2000 06:30:38 GMT, XTR <[EMAIL PROTECTED]> wrote:
> Problem when to initialize P-array and S-array, that is,
>by taking fractional part of pi.
>After taking correct values for P[0] and P[1], the fractional
>part of pi goes all 0.00000....
>I'm using Turbo C++3.0, and the 'double' gives 64 bits datatype.
>Any better tip to overcome this?
Well, obviously you have to use something that can hold more than 64
bits of pi in it if you want to get more than 64 bits out.
Multi-precision arithmetic is what is needed.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Forward secrecy for public key encryption (was Re: Question about ...
Z*_n)
Date: Tue, 18 Jan 2000 06:26:42 GMT
On Sat, 15 Jan 2000 07:47:49 +0000, David Hopwood
<[EMAIL PROTECTED]> wrote, in part:
>Normally, I wouldn't trust an identity-based protocol, because
>the identity-based model has several inherent security problems:
> - the "trusted" authority has enough information to calculate
> any user's private key, and therefore is a weak point of the
> whole system (to a greater extent than root CAs in a CA-based
> system).
> - it's impossible for users to verify that their keys aren't
> being "escrowed".
> - private keys have to be sent from the authority to each user,
> which is likely to be another weak point.
>However, none of these objections apply to a forward-secure
>scheme constructed using this method, because each user is their
>own trusted authority.
I am puzzled about how such a scheme is going to work. If the
condition that must be fulfilled for an identity-based scheme is that
to send messages to user X, all you need to know is user X's identity,
and don't have to download a public key, then if I can compute the key
for sending messages to user X from that identity myself, and if user
X can compute the key for reading those messages himself from his
identity, doesn't it follow that *everybody* who knows user X's
identity can compute both keys, and read all the messages?
On the other hand, two users certainly can engage in ordinary
public-key communication without the help of a trusted authority, and
the identity can play some trivial additional role in complicating the
protocol without changing its security.
I hope you can supply a simple explanation of how what you are trying
to achieve differs from either of the two scenarios above, and can
genuinely be thought of as being, in some sense, an identity-based
scheme without a trusted authority (which would indeed be immensely
useful if it were possible).
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: RSA
Date: Sat, 15 Jan 2000 15:01:59 GMT
On Fri, 14 Jan 2000 14:44:23 +0100, "Kreuzer Michael"
<[EMAIL PROTECTED]> wrote:
>Hello,
>
>i have a big big problem. i must decode a rsa code. its my homework *g* can
>anyone help me?
>
>the code :
>
>key : 51,3
>
>616
That key must be wrong. If the key is a modulus and an exponent, then
all the cipher blocks should be <= the modulus. But 616 is bigger than
51.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Forward secrecy for public key encryption (was Re: Question about ...
Z*_n)
Date: Tue, 18 Jan 2000 06:26:30 GMT
On Sat, 15 Jan 2000 07:47:49 +0000, David Hopwood
<[EMAIL PROTECTED]> wrote:
>The security property I'm trying to achieve is this: The validity
>period of each public key is split into several time periods,
>numbered say 1..T. Each time the current period changes, the
>holder of the private key applies a one-way "key evolution" function
>to his/her current private key value, and deletes the old value. When
>a message is encrypted, the current time period (say t) is specified
>as input to the encryption algorithm. It should not be possible to
>decrypt that message without having the private key value for
>period t or earlier.
Ah, so you're not trying to construct an identity-based encryption
scheme, you are merely using one as a component.
>The alternative approach involves constructing a forward-secure
>encryption scheme from an "ideal" identity-based encryption
>scheme.
>The basic idea is that the private key holder (Bob) takes on the
>role of the trusted authority (Trent) at key generation time, and
>then each of the users of the identity-based scheme in turn; each
>"user" corresponds to a time period.
In an identity-based scheme, Trent has to generate private keys whose
corresponding public keys are unpredictable small numbers
corresponding to the identities; the scheme is secure because the time
required to do this is large, but doing this once for all users is
acceptable, while doing it once to crack a single user's mail is not.
So in this type of method, both users, in order to communicate, have
to spend as much time computing as a cracker would to read their
messages! Unless one isn't using a totally "identity-based" scheme,
but is also using "Trent's public key" to carry part of the load.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: alt.privacy,alt.security
Subject: Re: Triple-DES and NSA???
Date: Sat, 15 Jan 2000 15:04:19 GMT
On Sat, 15 Jan 2000 03:41:19 GMT, Greg <[EMAIL PROTECTED]> wrote:
>Is Twofish a next generation work from Blowfish, or are they
>similar in name only?
I'd tend to say the latter, although others might dispute that.
>And can one use a key size larger than 256 on Twofish?
I'm not sure offhand, but I know several AES candidates do have
additional key size flexibility beyond the mandatory key lengths of
128, 192, and 256 bits.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Cracking an ADFGVX cipher
Date: Mon, 17 Jan 2000 01:34:52 GMT
On Sun, 16 Jan 2000 22:30:13 GMT, [EMAIL PROTECTED]
wrote, in part:
>how do you crack an ADFGVX cipher that has over 36 character (64) and
>possibly homophones?
The account of how the original ADFGX cipher was broken in David
Kahn's book "The Codebreakers" is the only one I'm familiar with, and
that one depended on the interception of two messages which had
identical beginnings.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: My Encryption system
Date: Sat, 15 Jan 2000 14:36:37 GMT
On Sat, 15 Jan 2000 12:01:38 +1100, Jeff Lockwood <[EMAIL PROTECTED]>
wrote:
> Variables:
>
> X This contains the data byte to be encoded
> A This is used as an index into the key array
> B This is used as an index into the key array, and for
> the encoded output byte.
> A1 This is used for temporary storage
> B1 This is used for temporary storage
>The Encode function:
>
> 1) Initialise variable A with the value 0 and B with 128.
>
> 2) read 1 byte into X.
>
> 3) The value in X is XORed with the byte in the key indexed by B,
> and the result is stored in A1.
>
> 4) The value in A1 is XORed with byte in the key indexed by A,
> and the result replaces the value stored in B.
>
> 5) Write out the the byte in B
>
> 6) Replace the value in A with the value in A1
>
> 7) Loop back to step 2 until all bytes have been encoded.
> The above functions are relesed into the public domain. You may use them
> in any program (even commercial ones). they may also implemented directly
> in hardware. I place no restrictions upon their use.
I was thinking that your method might be too similar to Terry Ritter's
Dynamic Substitution to be usable, but I see that that is not the
case. Although the values in the pointers A and B are replaced, based
on the byte being enciphered, the table of 256 bytes is never changed.
Therefore, essentially, we have an autokeyed rotor machine with two
rotors. Without any cryptanalysis of the cipher itself, this
immediately indicates that it is unlikely to be strong enough to
compete with DES as a cipher system suitable for serious use at the
present time.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Mispronounce words. (OT Re: How to pronounce "Vigenere"?)
Date: Sat, 15 Jan 2000 15:08:51 GMT
On Sat, 15 Jan 2000 01:24:00 -0500, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>Case in point: the reduction of all verbs to only five fundamental verbs as a
>basis for linguistic comprehension. The reduction causes so much loss of
>context that true comprehension is probably impossible.
Well, in Basic English that simply resulted in replacing every verb by
a unique combination of a verb and a noun or preposition. (e.g., "take
heart" or "go out")
That didn't change anything fundamentally, it simply required people
to learn an entirely new vocabulary for no particular reason.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: My Encryption system
Date: Tue, 18 Jan 2000 06:27:03 GMT
On Sat, 15 Jan 2000 12:01:38 +1100, Jeff Lockwood <[EMAIL PROTECTED]>
wrote:
> Variables:
>
> X This contains the data byte to be encoded
> A This is used as an index into the key array
> B This is used as an index into the key array, and for
> the encoded output byte.
> A1 This is used for temporary storage
> B1 This is used for temporary storage
>The Encode function:
>
> 1) Initialise variable A with the value 0 and B with 128.
>
> 2) read 1 byte into X.
>
> 3) The value in X is XORed with the byte in the key indexed by B,
> and the result is stored in A1.
>
> 4) The value in A1 is XORed with byte in the key indexed by A,
> and the result replaces the value stored in B.
>
> 5) Write out the the byte in B
>
> 6) Replace the value in A with the value in A1
>
> 7) Loop back to step 2 until all bytes have been encoded.
> The above functions are relesed into the public domain. You may use them
> in any program (even commercial ones). they may also implemented directly
> in hardware. I place no restrictions upon their use.
I was thinking that your method might be too similar to Terry Ritter's
Dynamic Substitution to be usable, but I see that that is not the
case. Although the values in the pointers A and B are replaced, based
on the byte being enciphered, the table of 256 bytes is never changed.
Therefore, essentially, we have an autokeyed rotor machine with two
rotors. Without any cryptanalysis of the cipher itself, this
immediately indicates that it is unlikely to be strong enough to
compete with DES as a cipher system suitable for serious use at the
present time.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: can someone encrypt for me?
Date: Tue, 18 Jan 2000 06:25:29 GMT
On 16 Jan 2000 08:48:27 GMT, [EMAIL PROTECTED] (Cutedoggy99) wrote,
in part:
>crypto version 0:
What's "crypto version 0"?
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: can someone encrypt for me?
Date: Sun, 16 Jan 2000 13:15:08 GMT
On 16 Jan 2000 08:48:27 GMT, [EMAIL PROTECTED] (Cutedoggy99) wrote,
in part:
>crypto version 0:
What's "crypto version 0"?
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
** 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
******************************
