Cryptography-Digest Digest #970, Volume #11 Wed, 7 Jun 00 16:13:00 EDT
Contents:
Re: testing non linearity of arithmetic-logic combinations (Terry Ritter)
Re: DH-Key Exchange Questions. ([EMAIL PROTECTED])
Re: software protection schemes (Mike Rosing)
Re: Thoughts on an encryption protocol? (Mike Rosing)
Re: Request for review of "secure" storage scheme (Rodd Snook)
Re: Enigma Variations (Jim)
Re: testing non linearity of arithmetic-logic combinations ("Adam Durana")
Re: DES -- Annoyed ([EMAIL PROTECTED])
Re: Some dumb questions (Bryan Olson)
Re: Enigma Variations (Joseph Reuter)
Re: Call for evaluating and testing a stream cipher program
([EMAIL PROTECTED])
Re: RIP Bill 3rd Reading in Parliament TODAY 8th May (zapzing)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: testing non linearity of arithmetic-logic combinations
Date: Wed, 07 Jun 2000 17:16:38 GMT
On 7 Jun 2000 16:27:09 GMT, in <[EMAIL PROTECTED]>,
in sci.crypt [EMAIL PROTECTED] (Mark Wooding) wrote:
>tomstd <[EMAIL PROTECTED]> wrote:
>
>> Latin squares have the problem of consuming too much memory,
>
>That depends on how large they are, surely. A pair of 4 x 4 squares
>wouldn't be any larger than a standard S-box.
We have 64MB+ in the usual computer, and 2nd level cache is going
on-chip and increasing rapidly. The raw store is available.
Since hardware continues to change, it seems more useful to
concentrate on the structure of the cipher per se than to limit the
structure to what current computing hardware does best. What current
hardware does best is simple "linear" computation, which is just what
we do not want a cipher to be.
A single Latin square is most likely to be used as a replacement for
the XOR operation in a stream cipher, thus opposing known-plaintext
attacks on the confusion sequence. Such an Ls can be a 2 dimension
index of bytes, a total of 64KB. But a far smaller alternative is to
use my patented Dynamic Substitution technique:
http://www.io.com/~ritter/#DynSubTech
http://www.io.com/~ritter/DYNSUB.HTM
in which case we have a little more computation, and the usual small
table. I have described such a cipher:
http://www.io.com/~ritter/CLO2DESN.HTM
>> and even still I have yet to see any published results on good sboxes
>> formed by Latin Squares.
>
>Surely you could analyse it in pretty much the same way as you do a
>normal S-box: look at the output difference probabilities for each input
>difference as usual; look at its nonlinearity in a similar way, and so
>on.
http://www.io.com/~ritter/ARTS/PRACTLAT.HTM
>In any event, it can't be much weaker than XOR, so you're onto a winner
>from a strength point of view.
If we describe this sort of strength as an unknowable transformation
(the ability to key-select one from among a large number of different
transformations), at least a keyed Latin square *has* strength; XOR
has none at all. And if we describe this strength as nonlinearity, at
least a Ls *can* have strength; again, XOR has none at all.
>The only question is whether it's worth
>it for the performance penalty.
A Latin square is a table look-up, an array access. In general, the
reason to use an explicit Latin square instead of a computation is
that the Ls can be far more complex. In the end, a complex
transformation is what we want.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: DH-Key Exchange Questions.
Date: Wed, 07 Jun 2000 17:27:10 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Mark Wooding) wrote:
> [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> > I've been playing with DH-Key exchange and come across few problems
> > with large numbers before doing the mod part.
>
> This sounds like you're doing it wrong. Do the modular reduction
after
> each multiplication. You need a multiprecision maths library of some
> kind to deal with (at least) 700-odd bit numbers.
>
The problem I'm having is storing the results when doing the
claculations using VBScript. It doesn't like big numbers. So you are
right I'm doing something wrong - using VBScript. I just wondered if I
could get away with a prime number of 71 ... well at least I now know.
I'll start looking for a maths lib and use a proper language although
my work mates are quite impressed with the idea of using an insecure
medium to generate keys. The Dan Quail version I have knocked up -
using JavaScript and ASP's - I'll make available for political
reasons. Namely that governments want to control maths, when you get to
play with the maths in question it makes it more real and the position
of the "controller" look really silly.
Anyway enough ranting and thanks for the help.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: software protection schemes
Date: Wed, 07 Jun 2000 12:42:27 -0500
maxim wrote:
>
> Does anyone know where I can find some ratings on software protection
> schemes (particularly the ones that do not rely on a dongle)
> thanx,
> max
Look at Embedded Systems Programming. A month or 2 ago they had an
article describing a few. They all have problems, they can be defeated
by anyone determined enough. But it will give you an overview of what's
out there.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Thoughts on an encryption protocol?
Date: Wed, 07 Jun 2000 12:56:23 -0500
Dido Sevilla wrote:
>
> Volker Hetzer wrote:
>
> > So it's a secret key protocol. Are there any constraints that forbid
> > the use of public key stuff?
>
> One of the problems with public key crypto that I'd like to avoid are
> patents (not that they apply where I live...). Also, symmetric block
> ciphers tend to be much simpler to code than asymmetric public-key
> systems. I only have one year and 32 KB code size on my 80186-based
> embedded system to fit everything, so all the firmware may probably have
> to be in pure assembly language...
There are plenty of PK systems that aren't patented. Code size for many
are pretty small, about 2k if you're in assembler should be more than
adequit. And code is available for free too.
>
> > How do you change keys over the lifetime of your devices?
> >
>
> Basically, some high-ranking person will go to each terminal, swipe a
> special card across its barcode swipe reader, punch in a password, and
> then punch in the new start key. This would be done every three months.
If you use a PK system you can eliminate this weak link. It would
reduce
your maintanance costs substantually if a person doesn't have to travel
around to every box (except for repairs) every so often. Might not mean
much with a few boxes, but if you get to have lots of them, it'll add
up.
> > Why not use a stream cipher or cryptographically secure PRNG to
> > generate the session keys?
> >
>
> Where can I find information on any of these entities?
>
> > Should work as long as the number of messages desn't get too large.
Handbook of Applied Cryptography and Applied Cryptography are good
starting points.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Rodd Snook)
Subject: Re: Request for review of "secure" storage scheme
Date: 7 Jun 2000 18:03:38 GMT
Thanks for the response, please see my comments below...
[EMAIL PROTECTED] (Baruch Even) wrote in
<[EMAIL PROTECTED]>:
<-- some content snipped throughout -->
>note that you can mark cookies to be sent ONLY over encrypted
>channels and for a cookie that carries sensitive informations this
>should be used.
Thanks for the hint about marking cookies as secure. I'll certainly use
that feature.
>Assuming that you have SSL for this whole session you can simply
>hash the password that the user gives you (possibly together
>with his userid and a fixed salt), cut the sensitive data in two
>encrypt one part with half of the hash result as key and encrypt
>the other part with the other half hash result.
I thought about using the password as a source of a changing key, but the
user can change their password which would mean re-encrypting the data (and
there can be several numbers for each user in the current scheme).
>The encryption can be any AES finalist and thus will be much
>faster than any PK crypto-system around.
Certainly faster, but an asymmetric system splits the authority between
two machines requiring an attacker to compromise both in order to have
free-range over the data. Reviewing my scheme I think it would be better to
have the database server do the encrypton and the web server do the
decryption. That way the decryption key and the data itself are not in the
same location.
>A problem with the method you suggest is that PK (specifically RSA)
>normally are considered secure for RANDOM data, your data is
Can you point me to a reference on this?
>not random so you would be required to pad it with random data
>before RSA encryption.
My scheme does specify that this should be done. What kind of ratio of
predictable-to-random is considered "good"?
>
>See also some comments below.
>
>In article <[EMAIL PROTECTED]>,
>[EMAIL PROTECTED] (Rodd Snook) wrote:
>>
>> 4. The remainder of the card number is converted to a packed
>> format (e.g. hex encoding of integer or BCD number) and combined
>> with some padding and length information, in a parseable
>> format(1). For
>> increased defence against differential cryptanalysys the
>> position of the card number within the string should be
>> varied randomly.
Here is where I pad the string. I will ensure the padding is random at your
suggestion.
>> Weaknesses:
>> 2. Card details are passed in clear text from the database server
>> to the web server.
>
>Using SSL and cookies over SSL solves this.
Not really. I'm talking about communication between the web server and
database server on the internal, "private" network. This is not a big issue
as this network is a trust-worthy as the machines that are on it (which
have access to the sensitive data anyway).
>
>> 3. Revealing part of the ciphertext in the cookie would allow a
>> brute-force attack -- provided that the format of the plaintext
>> string is known to the attacker.
>
>Brute force attack here are useless since there are many possibly
>combinations quite a few of them correct and the attacker will never
>know which one corresponds to this users cc.
Good point!
Thanks again,
Rodd
------------------------------
From: [EMAIL PROTECTED] (Jim)
Subject: Re: Enigma Variations
Date: Wed, 07 Jun 2000 17:12:19 GMT
Reply-To: Jim
On Wed, 07 Jun 2000 09:01:59 +0100, John Spicer <[EMAIL PROTECTED]> wrote:
>There is a vast wealth of literature and folklore on how the British
>broke the Enigma at Bletchley Park in the Second World War and the
>successes against the Japanese codebooks, but other aspects of cipher
>use are less well covered.
The successes against the Japanese machine 'Magic' was an American
success, not British. They don't always get the credit for that, at
least in this newsgroup.
>In particular, I was reading an account of the Battle of the Atlantic
>and was surprised to see a statement that the Germans were able to
>decipher signals sent from lone merchantmen to the Admiralty and thus
>discover their intended route.
That is so, and the Admiralty were bloody slow in changing it
when it was suspected to be broken.
>
>This led me to wonder what was the state of the cryptography used by the
>Allies and what in-roads had the Germans and Japanese made? Did the
>Allies learn from their successes against the Axis cryptos and
>strengthen their own, or did they fall into the same traps?
The BAMS (Merchant Ships Code) apart, the allied ciphers were very
good. There was the Typex machine, a contemporary of the Enigma,
but very much more secure. The Germans never broke it. They did
break, for a short time the voice scrambler circuit between
Churchill and Roosevelt. They had very little success with any
thing else. I don't recall reading of any significant Jap successes
in this field.
The Allies used one-time-tape to secure teleprinter traffic, which
was equivalent to an OTP. Later shift-register-generated long-period
stream ciphers were (and still are) used for on-line encryption
of data and (digitised) voice.
Read Kahn, 'The Codebreakers' the non-abridged version if possible,
although it's long been out of print. A definitive history of
cryptography up to around the early '70s I think.
>If anyone has any ideas on this or can point me to any books or
>published accounts, I would be grateful.
Also by Kahn, 'Seizing the Enigma'. Should still be in print.
There are also quite a few books written by former members of the
Bletchley Park team.
--
amadeus at netcomuk.co.uk
nordland at lineone.net
g4rga at thersgb.net
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: testing non linearity of arithmetic-logic combinations
Date: Wed, 7 Jun 2000 14:19:42 -0400
They are talking about linear boolean functions. I don't believe the linear
correlation function could be used here. If you want more information on
what boolean functions are and the linearness/nonlinearness of these
functions check out Terry Ritter's website at http://www.io.com/~ritter/
- Adam
"Dark Nebular" <[EMAIL PROTECTED]> wrote in message
news:Cit%4.591$[EMAIL PROTECTED]...
> I was wondering.... is the Linear Correlation function good enough to test
> linearness?
>
> JULIEN DERIVIERE - SPIRITED J. DERIVIERE ([EMAIL PROTECTED]) ICQ# :
> 27913909 --------------------------------------------------------------
The
> SPIRITED Homepage http://www.spirited.fr.fm You can subscribe to the
> SPIRITED Newsletter by sending a blank e-mail to
>
[EMAIL PROTECTED] ----------------------------------------
> ----------------------
> tomstd <[EMAIL PROTECTED]> a écrit dans le message :
> [EMAIL PROTECTED]
> > In article <[EMAIL PROTECTED]>, "cranky cransky"
> > <[EMAIL PROTECTED]> wrote:
> > >could somebody point me towards some research, if there is any,
> > on non
> > >linearity or linearity of certain chip level operations
> > (addition,
> > >subtraction, xor, shift, etc..) i was thinking of coding
> > something to try
> > >different combinations of these operands on integers and
> > examine the
> > >results for the combinations that produce the most non
> > linearity. is such an
> > >extensive test necessary? is this a well worn path? is it
> > possible to
> > >examine the nature of the function itself ( like boolean logic,
> > or addition
> > >axioms or whatever ) and work it out, instead of
> > testing????!?!?!
> > >aaargh...anywho, help appreciated.
> > >
> >
> > Simple. Build a table using your arithmetic operations then
> > perform the WalshTransform (or FWT) on it. it will give you the
> > linearness of it.
> >
> > Tom
> >
> >
> > * Sent from RemarQ http://www.remarq.com The Internet's Discussion
Network
> *
> > The fastest and easiest way to search and participate in Usenet - Free!
> >
>
>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: DES -- Annoyed
Date: Wed, 07 Jun 2000 18:57:28 GMT
In article <[EMAIL PROTECTED]>,
tomstd <[EMAIL PROTECTED]> wrote:
> I will glady just copy/paste/credit someone elses code for
> 3des...
Tom, I have heard many good things about Wei Dai's Crypto++ library, if
C++ (C?) is your language of choice. If your language of choice is Java,
check out cryptix.com, I think. If your language of choice is something
else, then I cannot help you.
(If your language of choice is C, then perhaps Bruce's code for DES will
suffice, though you may end up retyping it as well as wrapping it for
use in des-ede.)
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Some dumb questions
Date: Wed, 07 Jun 2000 19:00:37 GMT
In article,
[...]
> 2. If an ideal OTP is misused, in that it is used a small
> number n of times, how is one going to attack, if
> absolutely no known plaintext is available?
>
As a final project in an under grad crypto course I worked on
finding the smallest n such that I could, in practice, break
the n-time pad. I assumed english language text coded in
ASCII, and XOR as the OTP combiner. I found n=2.
I created a table of 4-gram frequencies from about ten
megabytes of text, and a program to interactively try these
against the target ciphertext. The user would enter a
position in the text, and the program would run through all
the known 4-grams, and for each 4-gram it would compute what
4-gram would appear in the other text, and rank each pair by
the product of the two 4-gram probablities. It would list
the top several 4-gram pairs, and the user could select one
to place into the texts.
The process was slow-going, but recovered most of the texts.
The right 4-gram pair was not usually the best ranked. There
were some sections which seemed to contain names or some
strange terms that I could not recover. Of course I could
not tell which of the two plaintexts corresponded to which
ciphertext. (In fact I actually worked on the XOR of two
plaintexts.)
Since my plaintext was ordinary English in ASCII, the most
common character was blank space. Those spaces were
extremely helpful.
I would guess that 5-gram frequencies would work even
better, and today PC's could handle the mass of data
involved. A Markov model could work better still. I think a
nice project would be a fully automatic 2TP decryptor using
a Markov model with search-and-backtrack.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Joseph Reuter <[EMAIL PROTECTED]>
Subject: Re: Enigma Variations
Date: Wed, 07 Jun 2000 12:10:52 -0700
Jim wrote:
>
> Read Kahn, 'The Codebreakers' the non-abridged version if possible,
> although it's long been out of print. A definitive history of
> cryptography up to around the early '70s I think.
>
Funny! Amazon.com shows
The Codebreakers; The Comprehensive History of Secret
Communication from Ancient Times to the Internet
by Daivd Kahn, David A. Kahn
List Price: $65.00
Our Price: $45.50
You Save: $19.50 (30%)
Hardcover - 1181 pages Revised edition (December 1996)
Scribner; ISBN: 0684831309 ; Dimensions (in inches): 2.44 x 9.61
x 6.50
Surely 1181 pages is not the abridged version!
--
Joseph A. Reuter, Wizard-in-Training [EMAIL PROTECTED]
"Olorin I was in my youth in the West that is forgotten."--Tolkien
You can't win, you can't break even, and it's the only game in town.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Call for evaluating and testing a stream cipher program
Date: Wed, 07 Jun 2000 19:43:27 GMT
Cascade Research, am I correct that I need to give you information of
the sort of my name/address/etc in order to see the cipher? I would
certainly appreciate seeing a privacy statement before giving that
information away.
As for general thoughts concerning what upset Tom so much: I am not as
experienced as Tom, but I can certainly understand why you would want to
make the most of the bits coming from your BBS generator. But, if you
are only using, say, six bits from BBS to seed some other function,
recognize that someone could brute-force the 64 possible inputs to the
function (as well as the 2^[|states|] of the function before being
reseeded, if it depends in part on previous states). Sure, they would
need to re-brute-force attack every time you reseed from the BBS, but if
you are extending the bits too far (say, six bits more than 64 bytes of
cipher stream) it shouldn't pose too much of a problem to a determined
attacker. So, ensure to reseed often enough with a significant amount of
bits from BBS. Whether it will still be fast is another issue. :)
But, without seeing the paper/source, I don't know what sort of
tradeoffs you have made.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Crossposted-To: uk.media.newspapers,uk.legal,alt.security.pgp
Subject: Re: RIP Bill 3rd Reading in Parliament TODAY 8th May
Date: Wed, 07 Jun 2000 19:53:48 GMT
In article <[EMAIL PROTECTED]>,
"Scotty" <[EMAIL PROTECTED]> wrote:
>
> zapzing wrote in message <8hhog6$3ru$[EMAIL PROTECTED]>...
> >In article <[EMAIL PROTECTED]>,
> > Charles Bryant <[EMAIL PROTECTED]> wrote:
> >> In article <8hf4cd$5j0$[EMAIL PROTECTED]>, zapzing
> ><[EMAIL PROTECTED]> wrote:
> >> >In article <[EMAIL PROTECTED]>,
> >> > David Hartley <[EMAIL PROTECTED]> wrote:
> >> ...
> >> >> Does the bill actually require this? i.e. disclosure of your
> >private PGP
> >> >> key.
> >> ...
> >> >And the reason that one would not want to hand this
> >> >over (beisides the fact that it reveals ones guilt)
> >> >would be what? Because then you would lose the
> >> >ability to authenticate messages in a way that
> >> >others could verify that you are the same person
> >> >as you were before?
> >>
> >> That, and because anyone who can demand all your keys can
impersonate
> >> you, to the extent that they can spend all your money, enter into
> >> contracts as you, put 'your' signature on documents, etc.
> >>
> >> >Well if that is the reason then couldn't you just
> >> >authenticate messages with a different key than
> >> >the one you use to exchange session keys ? I believe
> >> >that is what is reccomended anyway, isn't it?
> >> >Then after you were forced to reveal your private
> >> >key for exchanging session keys, you would (after
> >> >getting out of prison) just make an announcent
> >> >concerning your new public key, authenticated with
> >> >your uncompromized authentication key.
> >>
> >> And go straight back into prison because it's also an offence to
> >> reveal that your key was handed over.
> >>
> >> So, to put it all together, the government wants the power to take
> >> away all your money, to pretend that you signed a confession to
being
> >> a child molestor, and to throw you in jail if you complain. Now do
> >> you think its reasonable?
> >>
> >
> >I was suggesting a way that one could hand over all
> >keys that would give the government all substantive
> >information that it would possibly need, but *not*
> >the ability to do the things that you described.
> >Like I said above, You could have two public keys,
> >one for communicating and one for authenticating.
> >
>
> Doesn't work, they will demand both public keys. I suspect they will
do this
> by sending you test messages encrypted with each key, then issue a
warrant
> requiring that you decrypt them. In effect public key encryption is no
> longer secure in the UK.
>
It occurs to me that there are other protocols
for authentication that do not rely on anything
like a key. One of them has to do, I think, with
graph isomorphism. I remember reading about it
somewhere.
You start out with two graphs, A and B, that
are isomorphic but noone but you knows the
isomorphism. The idea is that you authenticate
a message by hashing the message plus the graphs
A and B plus a set of n challenge graphs (which
are isomorphic to both of the abovementioned
graphs )into a challenge string n bits long.
If the ith bit of the challenge string is "0"
you show the isomorphism of challenge graph i
with "A" and if it is "1" you show the isomorphism
with "B". If n is big enough only someone who
knows the isomorphism could do that.
Since the isomorphism is not a "key" in any
way that would probably not be covered by
the law so you would not be required to
give it.
--
If you know about a retail source of
inexpensive DES chips, please let
me know, thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
