Cryptography-Digest Digest #242, Volume #11 Fri, 3 Mar 00 01:13:01 EST
Contents:
Re: Passphrase Quality ? (Johnny Bravo)
Re: First contact, establishing password without public keys (David A Molnar)
Re: Crypto.Com, Inc. (David A Molnar)
Re: Best language for encryption?? (Bryan Olson)
Re: Best language for encryption?? (Paul Schlyter)
Re: Best language for encryption?? (Paul Schlyter)
Re: Best language for encryption?? (Paul Schlyter)
Re: Ciphering = deciphering; is this a weakness? ([EMAIL PROTECTED])
Re: Best language for encryption?? ("Trevor Jackson, III")
Random bit generators ([EMAIL PROTECTED])
Re: very tiny algorithm - any better than XOR? (Paul Rubin)
New US export regs (was Re: Crypto.Com, Inc.) (David Hopwood)
Re: very tiny algorithm - any better than XOR? (David Hopwood)
Re: Microcontroller Cipher (David Hopwood)
----------------------------------------------------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Passphrase Quality ?
Date: Thu, 02 Mar 2000 20:17:17 +0000
On Fri, 03 Mar 2000 00:33:30 GMT, jungle <[EMAIL PROTECTED]> wrote:
>there is no recommendation / reference to ROT-13,
It was the exact example in the original post I responded to, do try to
keep up.
>I'm using very often ROT-35 on 70 common characters from keyboard, but again
>this will not help you much to find how my encoding works
>
>the next point is, do you really believing me that I'm using ROT-35 and not
>ROT-36 instead, on 80 char set ?
It doesn't really matter, ROT-X, where x<128 adds at most 6 bits to the
passphrase. If your passphrase sucks, ROT won't save you.
>for pure cryptography terms, the "Dictionary Attacks" are / obsolete / bulshit
>/ non existent distinctions, only bit space is relevant
Many people use simple one or two word passphrases, so they are very
relevant.
>there is a small problem in your thinking ...
The problem seems to be in your thinking.
>it's very likely that you will not remember [ from your 128 bit equivalent key
>space ] 10 words randomly chosen, for some very stupid or valid reason & as the
>result you will never be able to recreate your pass text ...
Odd, I have no trouble remembering both of my 10 word passphrases, takes
me about 3 seconds to type each. Why do you think that
.&Xq6:~mG_[Q>A)i3w'K is a better alternative for 128 bits?
>you will end up in your own protection trap ...
Just because you can't remember a simple two sentence mnemonic, don't
expect everyone else to be as limited.
--
Best Wishes,
Johnny Bravo
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: First contact, establishing password without public keys
Date: 3 Mar 2000 01:08:56 GMT
Ken Savage <[EMAIL PROTECTED]> wrote:
> Alice can randomly generate strings until she comes across a pair that
> happen to collide. This will take an average of 2^20 attempts.
> Eve, OTOH, will have to do 2^40 attempts to come up with a pair of
> strings that match the SAME partial-MD5 that Alice broadcasts.
> A wee bit o' difference in computation time :)
Hey cool - I just heard about this from an different source a little
while ago. Apparently the idea is originally due to Ralph
Merkle. Applied Cryptography has a slightly different formulation, but
the same idea -- exploit the n vs. n^2 work factor for a birthday attack
vs. target collision.
Here's what I wonder : you can think of this as both
Alice and Bob are trying to agree on a function. They agree by showing
that the output of their respective functions is equal on some known
input. Fine. In some sense, they are showing each other that their
functions are "maximally consistent with each other" - i.e. the
functions are equal.
What if you had some other consistency check, besides just straight
equality? Can you do better than n vs. n^2 ?
Thanks,
-David
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Crypto.Com, Inc.
Date: 3 Mar 2000 01:15:36 GMT
[EMAIL PROTECTED] wrote:
> reminds me of Ramsey Theory which, as part
> of graph theory and combinatorics, should
> have some role in cryptology. I don't know
> what this role is.
Ramsey Theory is about the largest clique size in a graph, isn't it?
I honestly don't know much about the theory; I keep planning to take
the graph theory course here and then finding something else to do
during that term.
Anyway, finding maximum cliques is NP-complete, so it's a candidate
problem for building a trapdoor one way function. The problem, of
course, is building a secure trapdoor one way function from a graph
problem (look what happened to knapsacks...). Maybe Ramsey Theory would
give some idea of what kinds of graphs not to pick?
There was a post on this newsgroup a while back from a graph theorist
who had a student interested in cryptology. If he/she's still reading,
maybe he/she can comment...
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Best language for encryption??
Date: Fri, 03 Mar 2000 01:55:21 GMT
In article <89m4k9$aik$[EMAIL PROTECTED]>,
"Brian Hetrick" <[EMAIL PROTECTED]> wrote:
[...]
> the real drawback to using Visual Basic for everything
> is that one's market becomes "limited" --
> to a mere 95% of the boxes and 90% of the CPU cycles
> in the world....
Not even close. The real market for crypto, like most
of the CPU market, is in the mobil and embedded devices.
Cell-phones, Palm Pilots and smart-cards do not run VB.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Best language for encryption??
Date: 3 Mar 2000 01:56:01 +0100
In article <[EMAIL PROTECTED]>,
wtshaw <[EMAIL PROTECTED]> wrote:
> In article <89l43v$9vk$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Paul
> Schlyter) wrote:
>
>> In article <[EMAIL PROTECTED]>,
>> Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
>>
>>
>> #include <stdio.h>
>>
>> #define PRINT int main() { printf (
>> #define END "\n" ); return 0; }
>>
>> PRINT "Hello, world"
>> END
>
> What about:
>
> PRINT "Goodby, Mr. Gates.":END
The compiler will puke at the colon there. Replace with a comma, and
the syntax will be accepted by the compiler, but no newline will be
printed. Replace with a space instead, and the newline *will* be printed.
> I suppose one could easily replace <stdio.>, etc., and the commands they
> might support with politically incorrect speech. The problem is the
> encouragement of non-standard jargon that can make code non-transportable
> and even, dare we say, more cryptic.
Perhaps you should enter the yearly C Obfuscated Code Contest?
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Best language for encryption??
Date: 3 Mar 2000 01:56:30 +0100
In article <[EMAIL PROTECTED]>,
wtshaw <[EMAIL PROTECTED]> wrote:
> In article <89l42r$9uc$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Paul
> Schlyter) wrote:
>
>> If you want to go farther than that in C, use setjump/longjump instead.
>> These are library functions which allow you to jump between functions.
>> longjump() is most often used to directly jump out of several nested
>> function calls, in e.g. an error situation.
>>
>> And then you also have signal().....
>
> No mention of these is in the literature I have on C/C++,
Are you sure? Really sure? If so, your literature is bad and should
be replaced.
> more than you can carry at once,
It's not quantity that counts, but quality. Unfortunately, too many
garbage books are published today.
> which makes my point...that there is too little standardization
> in how the languages are fully used, as opposed to a set of commands
> that are easily learned, at least by many who I have taught.
I'm sorry, but these are deficiencies in the literature and/or the
programmers -- not in the languages themselves!
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Best language for encryption??
Date: 3 Mar 2000 01:55:33 +0100
In article <[EMAIL PROTECTED]>,
wtshaw <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
> <[EMAIL PROTECTED]> wrote:
>
>> "Structured programming" denotes a specific programming style,
>> typified by limiting control flow to the use of sequencing,
>> alternation, and repetition. It also has a heavy emphasis on
>> functional modularity, for which BASIC's GOSUB is woefully
>> inadequate.
>
> I call individual functions by name. Basic has gone through a few
> revisions as has C.
C has only gone through one revision so far: in 1979 the first ANSI C
standard was released. Before that there was the older "K&R C",
which wasn't a formal standard, but still fairly uniform across
implementations, although there still were some non-standard oddball
compilers like e.g. BDS C.
Perhaps Basic has gone through too many revisions -- all nonstandard ???
> GOSUB subroutines are not the same thing as functions, which I use
> exclusively instead of GOSUB's...
You mean stuff like:
100 DEF FNA(X) = 1.2 + 2.3*X + 3.4*X*X
???? Sure, they're handy, but quite limited.....
> but, they are still allowed.
I know -- they were there already in the original BASIC from 1964....
>> I don't know where you get the idea that BASIC involves event
>> loops, etc.; perhaps by confusing it with Microsoft's so-called
>> "Visual Basic"?
>
> Visual Basic guided by the Invisible Hand....What a security disaster that is!
Very true....
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Ciphering = deciphering; is this a weakness?
Date: 3 Mar 2000 03:20:49 GMT
In a previous article, David Hopwood <[EMAIL PROTECTED]> writes:
>[EMAIL PROTECTED] wrote:
---- snip ---
>> BTW. Any cipher run in OFB mode posses the property of having the same
>> encoding function as decoding function.
>
>A cipher in OFB mode is only used as a keystream generator, with the
>keystream used exactly once, and therefore chosen plaintext attacks aren't
>applicable. I.e. it's not valid to infer that the involution property is
>safe for a block cipher in ECB or CBC mode, just because OFB has this
>property.
True, but not relevant since I did not state the opposite. The accurate
interpretation is that someone who likes the aesthetics of identical encoding
and decoding functions, might as well settle for using any cipher in OFB
mode.
----- Posted via NewsOne.Net: Free Usenet News via the Web -----
----- http://newsone.net/ -- Discussions on every subject. -----
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
Date: Thu, 02 Mar 2000 23:14:47 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Best language for encryption??
Jerry Coffin wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] says...
> > In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
> > <[EMAIL PROTECTED]> wrote:
> >
> > > wtshaw wrote:
> > > > I do use a compiled BASIC, not interpreted.
> > >
> > > Even compiled BASIC doesn't support efficient linked data structures,
> > > etc. (Or if it does, it's via a nonstandard extension, not BASIC.)
> >
> > You are going out of you way to qualify Basic as not being extendable.
>
> It looks to me like you've completely missed what he's talking about.
>
> > If it were not simple enough to write a complex Basic application in one
> > file generally, you might be right.
>
> He said "linked data structures." That's not referring to linking
> modules of a program together. It's talking about creating things
> like linked lists, binary trees, R-B trees, AVL trees, hash tables
> that use linked-lists for collision resolution, etc. There's no
> reasonable way of doing any of these things in the typical
> implementation of BASIC.
>
> IMO, languages, even programming languages, are about expressing
> ideas. BASIC makes it difficult to even express ideas that require
> pointers to implement. It's long been agreed by most that we think
> primarily in language, and if we use a language that makes it
> difficult to express a concept, that also makes it difficult to think
> about the concept until we think up a vocabulary to express the ideas
> more easily.
>
> > Choice of programming language is a minor one of your choices. Pick wisely
> > as to platform first, then pick a language and define a style.
>
> Yes and no. Choosing a language in which to implement a particular
> program is indeed hardly worth discussing in most cases. OTOH, the
> languages you choose to learn have lasting and pervasive effects, not
> only on the projects you implement, but even on your ability to think
> clearly about entire classes of problems.
>
> In fairness, I should add that neither C nor C++ is the be-all or
> end-all in this respect. Just for example, I'm strongly of the
> opinion that nobody can really be a good programmer without knowing
> some form of functional language like LISP or ML to at least some
> degree. Even if you never write a single production program in such
> a language, knowing the language helps you acquire the vocabulary
> needed to think in a clear and straightforward manner about many
> problems that can appear nearly unapproachable if all you know is
> someething like BASIC.
Djikstra commented on this issue, claiming that people he encountered (students)
who learned languages like BASIC first were mentally damaged in that it was very
difficult for them to think certain ways. I'd be willing to bet the effect is
measurable.
------------------------------
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Random bit generators
Date: Thu, 02 Mar 2000 20:39:14 -0800
Sometime ago Erik proposed this scheme for combining 2 PRNGs:
>> Just for the sake of argument, what if you seed two such PRNGs (A &
B),
then
1) Get a number from A, Na, from 1 to 32,
2) Get a number from B, Nb, which is Na bits long.
3) XOR the next Na bits of plaintext with Nb.
and repeat
To me it seems difficult for an attacker to determine the output of
thePRNGs or the seeds, even if he knew a large chunk of the plaintext.
There are too many possibilities for where a number might start or end.
<<
How about this variant? Let's say we have 3 congruential random number
generators and we combine them this way:
C[i] = (R1[i] & R3[i]) || (R2[i] & ~R3[i])
What is happening here is that R3 selects which bits will be used from
R1 and which bits from R2. I would appreciate your thoughts and
comments.
Joseph Poe
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: very tiny algorithm - any better than XOR?
Date: 3 Mar 2000 04:59:37 GMT
Carl Byington <[EMAIL PROTECTED]> wrote:
>Each device has the cpu, 512 bytes of ram, and 1MB of eeprom. A fixed
>key in flash eeprom (set during the manufacturing process, unique for
>each device) is used to decode a small packet containing the key that
>will be used to decode content. Content (roughly 1MB) is decrypted using
>that content key. Multiple devices (owned by the same person) will share
>the same content key.
>
>Since the key(s) are stored in eeprom, it does not count against the
>50 byte code space restriction. All the instructions on this processor
>are either 16 or 32 bits long, so we have 25 instructions to work with.
Hmmm, if you don't mind using a little over half the ram and burning a
little more eeprom space and communication overhead than optimal,
I think you could code the rc4 algorithm in 25 instructions, especially
if you simplify/eliminate the key setup phase. The "key" in eeprom
would be a 256 byte permutation that is copied straight into the
S-box. I don't know the Atmel instruction set but in pseudocode you'd
have something like this. The rc4 X and Y pointers are in rx and ry,
and r0 is a temporary / return value / key byte. Syntax is (OPCODE
dest, src). S is a 256 byte temporary table in ram.
keyload: # fold in a key byte from r0
add ry, r0 # rc4.x += key byte
# fall through to getbyte
getbyte:
inc rx # ++rc4.x
add ry, S[rx] # rc4.y += S[rc4.x]
mov r0, S[ry]
mov S[ry], S[rx] # maybe 2-3 instructions if no mem-mem moves
mov S[rx], r0
add r0, S[ry] # r0 = S[rx] + S[ry]
mov r0, S[r0]
return
I'm guessing there is an indexed mem-mem move instruction since there
are 32-bit instructions. Otherwise you may need another instruction
or two and another register. So this is 9-11 instructions plus you'll
need a few more to initialize things (see below). 50 bytes total
sounds doable.
The key loading packet would be 256 bytes long. Presumably you can
live with that, given how long the content is. You don't have to
store the key loading packet, but just process the bytes off the input port.
To decrypt, you'd load the 256 byte S table from eeprom, set rx=ry=0,
then call keyload 256 times (ignoring the return values) on the key loading
packet bytes, then call getbyte as needed to get cipher stream bytes in r0.
As is normal with stream ciphers, you'd have to be careful to never
re-use a key.
I haven't tested that code so maybe there's mistakes, but you get the
idea. This is a very compact scheme code-wise and I'm going to add it
to my bag of tricks ;-). Let me know how this sounds.
PS, If you (or other readers) implement code based on this suggestion,
I'd appreciate a credit in your source file--thanks.
Paul
------------------------------
Date: Fri, 03 Mar 2000 02:35:34 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: New US export regs (was Re: Crypto.Com, Inc.)
=====BEGIN PGP SIGNED MESSAGE=====
wtshaw wrote:
> In article <[EMAIL PROTECTED]>, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote:
> =
> > Another possibility: Telepathy! Believe it or not, it was only
> > a few days ago that pre-cognition of animals and such stuffs
> > were earnestly discussed in a French radio broadcast.
>
> Do you suppose that we can better communicate with BXA this way, or is
> that the technique they are trying to use in lieu of sending email to
> us.
You don't need them to send email to you:
# =A7 740.13 Technology and software =97 unrestricted (TSU)
#
# (e) Unrestricted encryption source code.
# (1) Encryption source code controlled under 5D002, which would be
# considered publicly available under =A7 734.3(b)(3) and which is
# not subject to an express agreement for the payment of a licensing
# fee or royalty for commercial production or sale of any product
# developed with the source code, is released from =91=91EI=92=92 con=
trols
# and may be exported or reexported without review under License
# Exception TSU, provided you have submitted written notification
# to BXA of the Internet location (e.g., URL or Internet address)
# or a copy of the source code by the time of export.
^^^^^^^^^^^^^^^^^^^^^
and for products that don't satisfy the above definition but are still
exportable (e.g. "retail" products):
# =A7 740.17 Encryption commodities and software (ENC).
#
# (e) Eligibility for License Exception ENC.
# (1) Review and classification. You may initiate review and
# classification of your encryption commodities and software as
# required by paragraph (a) of this section by submitting a
# classification request in accordance with the provisions of
# =A7 748.3(b) and Supplement 6 to part 742 of the EAR.
# Indicate =91=91License Exception ENC=92=92 in Block 9: Special purp=
ose,
# on form BXA=96748P. Submit the original request to BXA in
# accordance with =A7 748.3 of the EAR and send a copy of the
# request to ENC Encryption Request Coordinator (see paragraph
# (g)(5) of this section for mailing addresses).
# Thirty days after receipt of a complete classification
^^^^^^^^^^^
# request by BXA, unless otherwise notified by BXA, exporters
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
# may export and reexport to any non-government end-user any
# encryption product eligible under paragraphs (a)(2), (a)(4)
# and (a)(5) of this section. [...]
- -- =
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 0=
1
"Attempts to control the use of encryption technology are wrong in princi=
ple,
unworkable in practice, and damaging to the long-term economic value of t=
he
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOL8kuTkCAxeYt5gVAQESaAgAhyiFD3WBiAa7lDLRAKyVzNpqyNzwSimJ
pnRMeh11+Scd318amHZik1Nlk8PDe7oQxhwusWgOfqJCc9MeUI70QJVOTvnuJjVa
kBPbaUL/FIu6TP8YSeh6ZSB/f6gKiBQRizB5eZKuUhbLexK1n/09iCtW2cDNy1qA
BxCsrTkas0UcYkQN8RVpH3305VSJIgxg7+p77Zt6ZwEV43gFOA3S/kZbQZ+LvSGH
hjeUpKobiF+GgCvbAJ7vPOUAOMDYzD37OnV8WrUvzS4AvZ/NwNYmJKZwYwpqvHA3
pn0t1PdnXDMUflXn6wEOYH8+AbTnrY9xsc3GcbCA31UqG5nuuKguBA=3D=3D
=3D/Hyz
=====END PGP SIGNATURE=====
------------------------------
Date: Fri, 03 Mar 2000 03:24:01 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: very tiny algorithm - any better than XOR?
=====BEGIN PGP SIGNED MESSAGE=====
Carl Byington wrote:
> Consider an 8 bit processor that does not have enough code space memory
> to run TEA. This processor only needs the decrypt side - it never encrypts
> any output. We have about 50 bytes of code space, which should be enough
> for something like the algorithm below. [...]
How much data space do you have? I would seriously recommend against trying
to create a new algorithm, but it may be possible to use a smaller variant
of an already analysed algorithm.
For example, RC4 can certainly be implemented in 50 bytes of code space
(probably much less), so the only potential problem is its RAM requirement.
The standard, 8-bit version of RC4 requires 256 bytes, but I think it is
probably safe to go down to about 6-bit RC4, which has a memory requirement
of 64 elements each of 6 bits (in that case it's probably best to store each
table element as a byte, and iterate the algorithm 4 times to encrypt 3 bytes).
Here is psuedo-code for one iteration of n-bit RC4 encryption/decryption
["^" means "to the power", not XOR]:
i = (i + 1) mod 2^n
t = S[i]
j = (j + t) mod 2^n
S[i] = u = S[j]
S[j] = t
t = (t + u) mod 2^n
next n bits of keystream = S[t]
and for key scheduling:
let K[0..len-1] be the key.
for i = 0 to (2^n)-1 {
S[i] = i
}
for i = 0 to (2^n)-1 {
t = S[i]
j = (j + t + K[i mod len]) mod 2^n
S[i] = S[j]
S[j] = t
}
Note that, as for any stream cipher, you should not use the same key for
more than one message, without adding a random salt.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOL8uuDkCAxeYt5gVAQEEKwf9EzwhzgyKuWkBNqL26sIbwrom/zgpXGR4
Q6n/X3oqc4Z7qawKI0IFAqGhotVTFmdHiMzBalP2JveCVgH6J2oipcNG3kcyYDTV
b6HTMr+59oORfK2DJ5xze19KtH9Q6vOMx1hN8EnBFXDoeA4XveEd6mrb7mszt4Z2
kXtfqU0cmpANKpiRjxwq4zRngFnZkP/3tuLDpDEW03adIUVhyA+e2W/u82HTsQL1
o7/PYId+pHcSf6zndU+AhDv5jyPyUe+66h532cZtPDxx7iK8Fyei8GOtTMapFgxr
O0XfmaVM4kZLFmHYDOB9DJkkzgJZRdtiWGAEZ0Dq1yPRd6RdLx5NJw==
=tmeA
=====END PGP SIGNATURE=====
------------------------------
Date: Fri, 03 Mar 2000 04:05:08 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Microcontroller Cipher
=====BEGIN PGP SIGNED MESSAGE=====
Gary wrote:
> Purely from an academic point of view is it possible to use a key's bits
> ONLY to conditionally (using the choice of 2 exclusively non linearly
> compatible mixing operations) mix two halves 'securely'?
> No S-Boxes, No accumulating sums to mix in, just the original data.
I'd be extremely skeptical about such an approach: it sounds as though it
would be very vulnerable to known or chosen plaintext attacks. Any common
property of the two mixing operations could potentially be used in much
the same way as a linear or differential characteristic. Even if it could
be made secure, it would probably require so many rounds that it would
not be at all competetive with other modern ciphers.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOL850TkCAxeYt5gVAQGuKgf9HeoRVo+zet8tbZ+vVlfbo9bujSqYFoRw
F32P0/gAmfvKWX+gsWp7lrIrbMyLtZdG5a4mWmNEGZd763E4/vH1gzCVocn+DBc0
P6sKl9kRDKRslJRAigdadGtS31aZBC2nmIjL6kcsWNCpOxa+924gbku54wgUgKZ8
QCCBjpIdFIuXc/wWB0v42vFstmNP51Nw9hfJJj1XtrmwqiwmnsUVl5rgu5glPeva
RMbgQrTf+ob3felzm9zBxKU2nGYBem7Kpaz3tg/ZXEnXaB6ZyBtQHeS8u74bC8y9
RS+JziETX7bl4L/OzywKxdTDLhPHiZS5ZlUzSkzmaGyyjMKz4yhh5A==
=3vYb
=====END PGP SIGNATURE=====
------------------------------
** 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
******************************
