Cryptography-Digest Digest #292, Volume #12 Wed, 26 Jul 00 18:13:01 EDT
Contents:
Re: Random Appearance (Future Beacon)
Re: purpose of final swap in Twofish? (Eric Smith)
"Symmetric" RSA encryption (John Myre)
Re: Database encryption (Mok-Kong Shen)
Re: Random Appearance (Mok-Kong Shen)
Re: AESC-stream cipher (Mok-Kong Shen)
Re: purpose of final swap in Twofish? (David A. Wagner)
Re: purpose of final swap in Twofish? (David A. Wagner)
Re: How is the security of Outlook Express encryption ? ("Donald L. Nash")
Re: AESC-stream cipher (David A. Wagner)
Re: Database encryption ("Kevin Crosbie")
Re: Database encryption (Paul Rubin)
Re: AESC-stream cipher (David A. Wagner)
Re: "Symmetric" RSA encryption (Steve Weis)
Re: 8 bit block ciphers (David A. Wagner)
Re: Elliptic Curves encryption ("diana")
Re: 8 bit block ciphers (Paul Rubin)
Re: "Symmetric" RSA encryption (David A. Wagner)
----------------------------------------------------------------------------
From: Future Beacon <[EMAIL PROTECTED]>
Subject: Re: Random Appearance
Date: Wed, 26 Jul 2000 15:09:53 -0400
On Tue, 25 Jul 2000, Mok-Kong Shen wrote:
>
>
> Future Beacon wrote:
>
> > I agree with you that if the sentences are to make sense together
> > in a reasonable context, the problem is enormous; however, I there
> > is no disproof of the possibility. I believe that there is no basis
> > for a disproof and that the problem is simply very hard to solve.
> >
> > For the moment, please consider the problem of making an isolated
> > sentence or a series of isolated sentences from a string of random
> > numbers. One approach is to have a data base of characters, words,
> > and frequently used phrases and for this data base to be shared by
> > the sender and receiver. The words and phrases would need to be
> > organized by grammatical function. It should be possible to select
> > a noun or noun phrase when you want one or to select any part of
> > speech similarly. You must have a strictly defined grammar which
> > may not be identical to any of the popular ones (which tend to be a
> > little vague). Let us call the parts of speech P1 through Pn.
> >
> > Sentence structures requiring rules of composition might be called
> > S1 through Sm and the ith one might be
> >
> > Si = P4 P17 P20 P9 P2.
> >
> > If you have 4000 words and phrases that function as a P4, you might
> > use two bytes to encode it. Notice that few words are conveyed
> > with only two bytes. Few random numbers make for many sent letters.
> > If disguise were done independent of the encryption, sent files
> > would be large. For that reason, I feel that the plain text message
> > should undergo a grammatical analysis in order to benefit from the
> > compression it would get. I believe that the two processes about
> > balance out while providing an opportunity for encryption at the
> > random-like number stage (the intermediate stage).
> >
> > Requiring the sentences to make sense together is a daunting task.
> > If vocabulary is restricted as it is in real messages (you are
> > talking about cars so you don't say car and then house and then
> > computer, you say car and then car and then car), then the pattern
> > of repeats cannot be correlated with similar kinds of repetition
> > in the plain text.
> >
> > All of this prompts me to suspect that the disguise process cannot
> > be independent of the encryption process but must be tailored to it
> > in one sense to make sure that it is independent in the other sense.
> >
> > There is a factor (a small one) that makes the task less demanding
> > than it might otherwise be: The relatedness of the sentences in
> > real messages is not often as high as it is in a mathematical proof
> > or in a textbook account of a concept. People put paragraph endings
> > almost anywhere. The wiretapper cannot expect to understand why
> > things are said unless a long history is involved. If the task is
> > not to raise suspicion and not to motivate a long historical record,
> > maybe a little daftness actually helps.
>
> If you just want to have the transform of one single sentence from a
> fixed set of sentences to be natural, then, as I mentioned, the task is
> trivial.
.
.
.
This is not the idea at all. I am sorry for rushing through
my explanation. I think I will try to explain a smaller piece
of it first.
This a description of compression using grammatical analysis:
You have constructed a formal grammar for English and you have
a number of parts of speech (P1 through Pn). For each part of
speech there is a list of words (let's forget punctuation and
phrases for now). List Pi contains all of the English words that
can function as that part of speech. A given word may appear in
more than one list. The full collection of lists is held by both
the sender and the receiver.
Let us suppose that the plain text is this:
one if by land and two if by sea
For the sake of a concrete image, let us also assume that the
encryption method is the one-time pad. It could be any method.
First, we assign part-of-speech list names to each word
in the message in order:
P7 P53 P20 P2 P6 P7 P53 P20 P2
Merely to keep things simple, let's assume that all of the lists
have the same number of entries and this number is less than a
65000. This means that we have two bytes for each word. There
are nine words, so we have 18 bytes (for now, we can assume
that every word is followed by a space). Without the parts-
of-speech lists being shared by the sender and receiver, we
would have 32 bytes to encrypt and would therefore need to use
32 bytes from the one-time pad.
There are plenty of opportunities for improving on this compression,
and, of course, there are many ways to further obscure repeats of
parts of speech; but the general idea is that English has a lot of
redundancy in it that can be taken out before encryption. This
redundancy is actually desirable for ease of reading; but no harm is
done to the one-time-pad encryption by first compressing the plain
text in this way.
It is this compression that gives us some latitude to expand the
message length in the subsequent process aimed at disguising it.
Does this part make any sense to you?
Respectfully,
Jim Trek
Future Beacon Technology
http://eznet.net/~progress
[EMAIL PROTECTED]
------------------------------
From: Eric Smith <[EMAIL PROTECTED]>
Subject: Re: purpose of final swap in Twofish?
Date: 26 Jul 2000 12:40:03 -0700
I asked about Twofish:
> Is there any particular reason for this extra swap (or equivalently,
> for eliminating the swap of the last round)?
=?iso-8859-1?Q?H=E5vard?= Raddum <[EMAIL PROTECTED]> writes:
> Undoing the last swap is common in all Feistel ciphers. The reason for
> this is that decryption becomes the same as encryption with the round
> keys in reversed order, so one can use the implementation for encryption
> to decrypt also. If you draw a diagram of a general Feistel cipher and
> trace the halves of the intermediate ciphertexts you will see that this
> is so.
Well, since some of the bit rotations aren't part of F, the encryption and
decryption functions can't be the same anyhow.
It seems that the extra swap means either:
1) The first or last round has to be done differently, to avoid the swap.
This is how the 6805 implementation works. This might save a few
cycles per block, but increases the code size.
2) An extra swap is done, at the expense of both code size and execution
time.
So the only valid reason I can see for the extra swap (or missing swap)
is to reduce the cycles per block by a small amount, for the first case
above. It doesn't seem like a good tradeoff since code size is really
at a premium on 8-bit microcontrollers (some more than others, such as
the Microchip PIC), and the number of cycles saved on 32-bit processors
is negligible.
Oh well.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: "Symmetric" RSA encryption
Date: Wed, 26 Jul 2000 13:50:19 -0600
I was explaining how RSA works (not why, just how) the
other day, and an odd idea came up. Has anyone heard of
this? Can anyone think of a reason to use it?
Let n be the modulus, and e and d be the exponents, as
usual. The idea is to let one party (say, Alice) know
n and e, and the other party (Bob) knows n and d, and that
is it. In particular, the factors of n are gone. Now Alice
and Bob can exchange authenticated secret messages:
Alice computes and sends X^e mod n.
Bob computes (X^e)^d mod n = X.
Bob computes and send Y^d mod n.
Alice computes (Y^d)^e = Y.
So e is not public; it is randomly chosen. Also, whoever
generated the values in the first place (maybe a third party)
must be trusted to forget anything he doesn't need to know.
Signing and encryption are the same operation. Decrypting
a message means you have verified the signature (assuming
the message has some verifiable structure, of course). Alice
exponentiates by e, Bob by d, that's all they ever do.
Maybe this could be handy if there is a trusted third party,
but Alice and Bob don't trust each other? I suppose you
could get the same security properties in other ways; in
particular Alice and Bob could each have the normal pair
of RSA keys (encryption and signing), and use them. Still,
it's kind of cute.
Given randomly selected e's, could some number of pairs of
people use the same n? (Assuming the factors of n are
never learned by any adversary.)
JM
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Database encryption
Date: Wed, 26 Jul 2000 22:15:28 +0200
Paul Rubin wrote:
> Kevin Crosbie <[EMAIL PROTECTED]> wrote:
> >Encryption is not a problem, the problem is in the storage of the primary
> >key... Where do I store such a sensitive piece of data. I don't want it
> >possible to have my system compromised by someone find the single system
> >secret.
> >
> >I figured a smart-card or dongle would be a viable storage area for such a
> >key.
>
> I see what you mean, you want to make sure there's no hot data on your
> backup tapes and stuff like that.
>
> You need a hardware encryption module. For low traffic, a smart card
> or dongle would be ok, but they are very slow. You could use one to store
> a secret key and load it into your computer, but that would be much
> less secure than doing the encryption in the module.
Question: Why does one unconditionally need hardware to store the
encryption key? Couldn't one e.g. have it written down somewhere
and manually type it in from keyboard? Thanks.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Random Appearance
Date: Wed, 26 Jul 2000 22:17:16 +0200
Future Beacon wrote:
> This is not the idea at all. I am sorry for rushing through
> my explanation. I think I will try to explain a smaller piece
> of it first.
>
> This a description of compression using grammatical analysis:
>
> You have constructed a formal grammar for English and you have
> a number of parts of speech (P1 through Pn). For each part of
> speech there is a list of words (let's forget punctuation and
> phrases for now). List Pi contains all of the English words that
> can function as that part of speech. A given word may appear in
> more than one list. The full collection of lists is held by both
> the sender and the receiver.
>
> Let us suppose that the plain text is this:
>
> one if by land and two if by sea
>
> For the sake of a concrete image, let us also assume that the
> encryption method is the one-time pad. It could be any method.
>
> First, we assign part-of-speech list names to each word
> in the message in order:
>
> P7 P53 P20 P2 P6 P7 P53 P20 P2
>
> Merely to keep things simple, let's assume that all of the lists
> have the same number of entries and this number is less than a
> 65000. This means that we have two bytes for each word. There
> are nine words, so we have 18 bytes (for now, we can assume
> that every word is followed by a space). Without the parts-
> of-speech lists being shared by the sender and receiver, we
> would have 32 bytes to encrypt and would therefore need to use
> 32 bytes from the one-time pad.
>
> There are plenty of opportunities for improving on this compression,
> and, of course, there are many ways to further obscure repeats of
> parts of speech; but the general idea is that English has a lot of
> redundancy in it that can be taken out before encryption. This
> redundancy is actually desirable for ease of reading; but no harm is
> done to the one-time-pad encryption by first compressing the plain
> text in this way.
>
> It is this compression that gives us some latitude to expand the
> message length in the subsequent process aimed at disguising it.
>
> Does this part make any sense to you?
>
Unfortunately not. Let's forget about the compression issue etc., for
that's secondary for security. (We are primarily interested in security,
aren't we?) You analyze a sentence and get its sturcture. For example,
the sentence is 'John plays football'. The structure is noun-verb-object.
What do you do in this case? In the scheme I indicated, 'John' is
mapped to a corresponding set of other nouns, say, {Mary, cat, .....},
and similarly for the other two words. So the transform could turn out
to be e.g. 'Mary hears music'. In order to obtain such sufficiently
natural transforms, the domain of discourse has obviously to be very
limited and even then it is not a easy task. That is what I meant in
my previous follow-up. Now could you show how you would
operate with my example sentence to get a transform that looks
natural according to your scheme?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: AESC-stream cipher
Date: Wed, 26 Jul 2000 22:16:11 +0200
[EMAIL PROTECTED] wrote:
> Idea of this algorithm goes up to Vigenere cipher.
> Plain text stream is a sequence of bytes.
> Key stream is generated as stream of words but it
> is used for encryption as stream of bytes.
> Key has length 256 byte.
> Vigenere Tableau is implemented as multiplication table
> of finite group of the order 256.
>
> Key stream is generated using finite group of the order
> 65536 and chained encryption.
>
> Key schedule.
>
> 1. A key is interpreted as sequence of automorphisms of 256-group.
> 2. The key is interpreted as sequence of automorphisms of 65536-group.
> 3. The key is a start segment of key sequence generation using
> 65536-group and chained encryption, which may be called as
> Quasi One Time Pad.
>
While there is much discussion on the computational efficiency, I
still miss an explanation of how the key stream is actually generated
from a user-given 256 byte key based on a group of the order
65536. (Note that a group has only one operation defined on it.)
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: purpose of final swap in Twofish?
Date: 26 Jul 2000 14:00:45 -0700
Eric Smith <[EMAIL PROTECTED]> wrote:
> I asked about Twofish:
> > Is there any particular reason for this extra swap (or equivalently,
> > for eliminating the swap of the last round)?
>
> =?iso-8859-1?Q?H=E5vard?= Raddum <[EMAIL PROTECTED]> writes:
> > Undoing the last swap is common in all Feistel ciphers. The reason for
> > this is that decryption becomes the same as encryption with the round
> > keys in reversed order, so one can use the implementation for encryption
> > to decrypt also.
>
> Well, since some of the bit rotations aren't part of F, the encryption and
> decryption functions can't be the same anyhow.
Yes, but they're the same up to those bit rotations.
There's no reason to do the extra swap (omitting it doesn't affect
security), and it makes the decryption engine more similar to the
encryption engine, and may also make implementations of both
operations slightly faster by, say, 1% or so (because they don't
need to do an unnecessary swap).
Note that most software implementations typically have the
encryption loop fully unrolled, for speed. (I've never programmed
in a constrained environment, so I would assume that if you are in
that situation you might not unroll the loops, but the common case
seems to be unconstrained environments where unrolling helps.)
Note that there's nothing special about Twofish here; most Feistel
ciphers do it this way. Even DES omits the final swap, I believe
(but that's from memory, so I could be wrong).
I must admit I don't understand why, if you're programming a
microcontroller, you don't just do an extra swap yourself. Sure,
it slows the thing down a tiny amount (surely << 1%, no?), but
let's face it, the encryption rate on microcontrollers is already
pretty darn slow.
Do you really need to squeeze out every last epsilon of speed?
(I ask, honestly curious in the answer; I'm not familiar with
typical embedded applications.)
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: purpose of final swap in Twofish?
Date: 26 Jul 2000 14:07:35 -0700
Eric Smith <[EMAIL PROTECTED]> wrote:
> I asked about Twofish:
> > Is there any particular reason for this extra swap (or equivalently,
> > for eliminating the swap of the last round)?
>
[...]
> It seems that the extra swap means either:
[...]
> 2) An extra swap is done, at the expense of both code size and execution
> time.
Oh, I missed this somehow the first time I read your post. Ok, how large
is the impact on code size and execution time? Is it large, and does it
truly matter? I would have expected execution time to be affected by <<
1% and code size to be increased by a few instructions, and I would have
expected those overheads to be in the noise. Do either of those make a
difference in your application? If they do, it seems that changing your
algorithm to one designed specifically for constrained environments might
make much more of a difference than any tweaking of the swaps in Twofish.
------------------------------
From: "Donald L. Nash" <[EMAIL PROTECTED]>
Subject: Re: How is the security of Outlook Express encryption ?
Date: Wed, 26 Jul 2000 16:07:27 -0500
In article <8ln7o1$q7g$[EMAIL PROTECTED]>, "???"
<[EMAIL PROTECTED]> wrote:
>Actually, I want to know which encryption algorithm and what key lenghth
>are used by Outlook Express.
It depends. OE uses the Cryptographic API ("CAPI") provided by Windows,
and CAPI is modular. The algorithm and key size used depend on the
modules installed and on what the application asks for. I think the
default is either 40-bit or 56-bit DES and 512-bit RSA, but it has been
a long time since I looked at CAPI so I'm not positive about that. I
just remember that the default is pretty weak.
But Greg makes a good point: CAPI can be subverted by inserting a DLL
between the CAPI DLL and the application, which would allow the
attacker's DLL to intercept all the plaintext and do anything it wants
to it. This requires that the attacker be able to install DLLs on your
system, but with all the security holes in Internet Explorer how hard
can that be? This isn't an indictment against CAPI per se, but is yet
another illustration that the weakest link determines the strength of
the chain.
--
Donald L. Nash, <[EMAIL PROTECTED]>, PGP Key ID: 0x689DA021
The University of Texas System Office of Telecommunication Services
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: AESC-stream cipher
Date: 26 Jul 2000 14:15:36 -0700
In principle, you might be right that it is best to do end-to-end
measurements of time to encrypt a large file rather than microbenchmarks
of time to encrypt memory repeatedly, but in practice, I disagree.
End-to-end measurements can give us a very good understanding of
performance in one very limited niche -- e.g., file encryption -- but
it is hard to generalize from them to other settings where the cost of
I/O may differ dramatically. Therefore, the most useful measurements
seem to be raw encryption time (from memory, caches warm, etc.).
We should all remember the caveat that, in some important cases,
I/O time may dominate encryption time, in which case the speed of the
cipher doesn't matter; but in other cases, encryption time dominates,
and then speed does matter. Nonetheless, this judgement must be made
on an application-by-application basis, whereas it is useful to compare
the performance of various ciphers in a less limited context.
Also, remember that cryptographers rarely have time or skill to optimize
their I/O subsystem (you're lucky if they have the time and skill to
optimize their cipher implementation!), which means that any end-to-end
measurements you see are likely to be unrepresentative of how the cipher
would be used in any case where speed truly mattered.
You may well be right that the AESC cipher is far too slow to be of any
real interest, and/or that the originally posted performance measurements
for AESC were truly lacking. I just wanted to take exception to your
general point, not to specifically defend AESC.
------------------------------
From: "Kevin Crosbie" <[EMAIL PROTECTED]>
Subject: Re: Database encryption
Date: 26 Jul 2000 17:19:42 EDT
it's an automatic process. Many encryptions/decryptions must be carried
out, for multiple accounts and database entries.
A hardware device also has the added benefit of even me not seeing the key.
I see what you are getting at though, load the key into memory at
initialization, and store it centrally in the encryption module... this
could be open to attacks, like if the system crashed, a core dump could
produce the secret key...
Kevin
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Paul Rubin wrote:
>
> > Kevin Crosbie <[EMAIL PROTECTED]> wrote:
> > >Encryption is not a problem, the problem is in the storage of the
primary
> > >key... Where do I store such a sensitive piece of data. I don't want
it
> > >possible to have my system compromised by someone find the single
system
> > >secret.
> > >
> > >I figured a smart-card or dongle would be a viable storage area for
such a
> > >key.
> >
> > I see what you mean, you want to make sure there's no hot data on your
> > backup tapes and stuff like that.
> >
> > You need a hardware encryption module. For low traffic, a smart card
> > or dongle would be ok, but they are very slow. You could use one to
store
> > a secret key and load it into your computer, but that would be much
> > less secure than doing the encryption in the module.
>
> Question: Why does one unconditionally need hardware to store the
> encryption key? Couldn't one e.g. have it written down somewhere
> and manually type it in from keyboard? Thanks.
>
> M. K. Shen
>
>
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Database encryption
Date: 26 Jul 2000 21:20:30 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>Question: Why does one unconditionally need hardware to store the
>encryption key? Couldn't one e.g. have it written down somewhere
>and manually type it in from keyboard? Thanks.
In some situations that's ok. I guess I should have asked, but I had
guessed that the poster wanted a higher security solution. That's mutually
exclusive with having a key written down on a piece of paper somewhere.
The supposedly highly secure Los Alamos nuclear bomb lab accidentally
leaves hard disks containing weapons data behind xerox machines. I
don't see the mere misplacement of a piece of data as a sign of
outrageous incompetence; it's a normal human error. Stuff like that
happens despite military security practices. Any civilian
organization will almost certainly have even less discipline.
So in general, one should not use cryptography software to secure
highly sensitive data. It's simply too easy for keys to escape by
accident or on purpose. If the software crashes and leaves a core
dump, the keys may be in it. If the computer gets a virus, that might
scan memory and find the keys. And so on. Sensitive data should be
secured by hardware.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: AESC-stream cipher
Date: 26 Jul 2000 14:20:01 -0700
In article <8lm6vi$4uf$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> New feature.
> ' Braking cycles in key stream'
>
> Encryption and decryption procedures are modified in order to brake
> cycles in key stream generation. Periodically two bytes of plain text
> stream are inserted in the input of key stream generator. This brakes
> cycles in key stream and makes key stream dependent on parts of the
> plain text.
Is it just me, or does this really call into question the security of
this cipher? If it has short cycles without this feature, I think that
really raises a red flag about the internal structure of the cipher.
If the internal structure generates short cycles, maybe it is fundamentally
flawed and better discarded.
And, I have real concerns about whether the proposed countermeasure
can truly fix weaknesses with short cycles in a robust way; what if the
plaintext is highly patterned, so that each time you extract a pair of
plaintext bytes you get the same 16-bit value? Won't devastating cycles
then remain?
Note that I haven't looked at the internals of this particular version
of the AESC cipher, and without more context, I wouldn't want to come to
any definite conclusions about the security of the cipher; nevertheless,
I found the above statements a bit troubling.
------------------------------
From: Steve Weis <[EMAIL PROTECTED]>
Subject: Re: "Symmetric" RSA encryption
Date: Wed, 26 Jul 2000 14:29:25 -0700
John Myre wrote:
> Let n be the modulus, and e and d be the exponents, as
> usual. The idea is to let one party (say, Alice) know
> n and e, and the other party (Bob) knows n and d, and that
> is it. In particular, the factors of n are gone. Now Alice
> and Bob can exchange authenticated secret messages:
> Alice computes and sends X^e mod n.
> Bob computes (X^e)^d mod n = X.
> Bob computes and send Y^d mod n.
> Alice computes (Y^d)^e = Y.
> So e is not public; it is randomly chosen. Also, whoever
> generated the values in the first place (maybe a third party)
> must be trusted to forget anything he doesn't need to know.
> Signing and encryption are the same operation.
This is similar to Diffe-Hellman key agreement, except Alice and Bob
must have prior private knowledge or rely on a trusted third party.
Specifically, they need to know that e and d are relatively prime mod
phi(n). If they can securely distribute e and d, they might as well just
distribute keys to a strong symmetric cipher instead. Another note is
like DH it is vunerable to a man in the middle attack.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: 8 bit block ciphers
Date: 26 Jul 2000 14:29:41 -0700
Scott Fluhrer <[EMAIL PROTECTED]> wrote:
> One thought is looking at a design like NewDES (by Robert Scott, it's in
> Schneier).
I'd personally wouldn't favor NewDES. It was designed quite a while ago,
before many of the advances in differential and linear cryptanalysis, so
there was no way for the author to benefit from that. And, my understanding
is that it has not received much scrutiny from the research community.
Have you looked at Skipjack? It seems remarkably well-suited for low-RAM
environments. There are also GOST and Treyfer, which both seem quite good
for low-RAM environments, and don't require 256 bytes of ROM for their S-box.
(Make sure to get the updated version of Treyfer, which adds a round counter
to prevent slide attacks.) All of these have received some analysis in the
open community, certainly not as much as DES or the AES candidates and not
as much as I'd like, but at least they seem to be holding up ok so far.
------------------------------
From: "diana" <[EMAIL PROTECTED]>
Subject: Re: Elliptic Curves encryption
Date: Thu, 27 Jul 2000 17:32:27 -0400
Reply-To: "diana" <[EMAIL PROTECTED]>
I'm wondering if elliptic curves is the next trend in encryption.... is it?
or can anyone think of something else?
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: 8 bit block ciphers
Date: 26 Jul 2000 21:40:19 GMT
In article <[EMAIL PROTECTED]>,
Mack <[EMAIL PROTECTED]> wrote:
>Does anyone have any information on 8 bit block
>ciphers? I don't mean simply shuffling an array.
>And I am aware that it is simple to do a dictionary
>attack. I am looking for methods that can be used
>instead of array shuffling.
If you mean a block cipher suitable for implementation on 8-bit
microcomputers, Skipjack is probably the best choice. For 4 bits,
try GOST. DES is also doable. Skipjack uses the least RAM (about 3
bytes plus the key).
See http://www.brouhaha.com/~eric/crypto for PIC microcontroller
implementations of DES and Skipjack.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: "Symmetric" RSA encryption
Date: 26 Jul 2000 14:41:23 -0700
In article <[EMAIL PROTECTED]>, John Myre <[EMAIL PROTECTED]> wrote:
> Let n be the modulus, and e and d be the exponents, as
> usual. The idea is to let one party (say, Alice) know
> n and e, and the other party (Bob) knows n and d, and that
> is it. In particular, the factors of n are gone. Now Alice
> and Bob can exchange authenticated secret messages:
>
> Alice computes and sends X^e mod n.
> Bob computes (X^e)^d mod n = X.
> Bob computes and send Y^d mod n.
> Alice computes (Y^d)^e = Y.
Yes. What you have suggested is very similar to the Pohlig-Hellman
cipher, which also uses number theory for symmetry crypto. The key
is a prime p and an exponent e with gcd(e,p-1) = 1; Encrypt_{e,p}(X) =
X^e mod p, and Decrypt_{e,p}(Y) = Y^{e^{-1} mod p-1} mod p. You must
pick p large enough to ensure that discrete logs in Z/pZ are hard.
Note that if you know e, d, and n, you can factor n.
By the way, it's not such a good idea to encrypt both directions in
a related way. You should pick entirely independent keys for both
directions. (For instance, if you can convince Bob to encrypt chosen
messages for you, you can also read anything encrypted by Bob, with your
above idea.)
------------------------------
** 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
******************************
