Cryptography-Digest Digest #660, Volume #11 Sat, 29 Apr 00 10:13:01 EDT
Contents:
Re: Karatsuba threshold ("Michael Scott")
Re: sboxes for the bored... (Tom St Denis)
Re: sboxes for the bored... (Tom St Denis)
Re: New and want to learn (Tom St Denis)
Re: The Illusion of Security (Tom St Denis)
Re: Help In encryption!!! (Tom St Denis)
As long as we are asking naive questions... (Guy Macon)
Re: Speaking of HD Overwriting... (Guy Macon)
Transparent encryption for Windows CE ("Roman - do not replay")
Re: Speaking of HD Overwriting... (Mark Wooding)
Sbox Generator Update (Tom St Denis)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Anthony Stephen Szopa)
Vs: Vs: sci.crypt think will be AES? ("Helger Lipmaa")
Modification of RC5 (Tom St Denis)
----------------------------------------------------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: Karatsuba threshold
Date: Sat, 29 Apr 2000 11:17:55 +0100
The threshold depends crucially on the speed of the multiplication
instruction on the host architecture (which is really to state the obvious).
If there is no integer multiplication instruction then even 2x2 word
multiplications may benefit. The same may apply if the multiplication
instruction requires multiple cycles to complete. For this reason it is
really quite pointless to build-in a fixed threhold - its architecture
dependant.
For (an extreme) example GF(2) "multiplication" (carry-free multiplication -
in GF(2) add and subtract are both XOR) is not supported by any instruction
set I know of. Therefore it must be implemented by a shift-and-xor program.
On a Pentium Pro my best effort for a 32x32 GF(2) multiplication requires
144 instructions. Of course the regular integer MUL instruction requires
just 1 clock cycle. So in this scenario the Karatsuba thresold is right down
at the 2x2 level - helped by the fact that you don't have to keep track of
those pesky carries...
Mike Scott
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: sboxes for the bored...
Date: Sat, 29 Apr 2000 10:29:05 GMT
Terry Ritter wrote:
>
> On Sat, 29 Apr 2000 00:05:55 GMT, in <[EMAIL PROTECTED]>, in
> sci.crypt "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>
> >Terry Ritter wrote:
> >> Measuring Boolean function nonlinearity is well-known technology.
> >
> >However, there are apparently different measures of nonlinearity;
>
> Yes, of course there would be different measures, in the same sense as
> there are many different forms of linearity.
>
> >are they strictly equivalent?
>
> Within the context of Boolean functions (that is, n-bit to 1-bit
> lookup tables), such functions are likely equivalent. The extension
> to n-bit to m-bit tables, in which we measure each bit-column
> independently, seems fairly common, if that is what we want to do.
> Now, we might well *want* to do something else in which the sequences
> are not measured independently, but I'm unaware of a useful
> cryptographic measure for anything like that.
Well meseasuring n by 1 sbox non-linearnity is not what I am trying todo
here. I implemented a WT transform that goes thru all possible inputs
and outputs. Could you just look at my code to see I implemented the WT
properly please?
Tom
--
Want your academic website listed on a free websearch engine? Then
please check out http://24.42.86.123/search.html, it's entirely free
and there are no advertisements.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: sboxes for the bored...
Date: Sat, 29 Apr 2000 10:31:32 GMT
Terry Ritter wrote:
>
> On Sat, 29 Apr 2000 01:24:40 GMT, in <[EMAIL PROTECTED]>,
> in sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> >"Douglas A. Gwyn" wrote:
> >>
> >> Terry Ritter wrote:
> >> > Measuring Boolean function nonlinearity is well-known technology.
> >>
> >> However, there are apparently different measures of nonlinearity;
> >> are they strictly equivalent? E.g., do all comparable bent
> >> functions have the same "Ritter nonlinearity", and is that
> >> necessarily maximal?
> >
> >I dunno what he is talking about the walsh transform (taken from "On
> >linear cryptanalysis") will give you a negative when the function is
> >affine, a positive when it's linear and close to zero if it's neither.
>
> Is that true? I don't think so. Let's see you deliver a few examples
> where that is so.
Look at the paper, there are negative entries in the WT table of SBOX 5.
> In any case, Boolean function nonlinearity is defined as a distance,
> not a direction. Understand that this is not *my* definition; this is
> the consensus of a number of different authors. Boolean function
> nonlinearity is the number of bits which must change to reach the
> closest affine function. It is the number of bit-changes, and not
> just the result of a particularly convenient computation. We can get
> the same result by counting the bit-changes with respect to each basis
> function by hand. Indeed, I thought I covered all this on my page.
> See:
>
> http://www.io.com/~ritter/JAVASCRP/NONLMEAS.HTM
Yeah of course it's a direction, lower negative = affine, higher
positive = linear (or is it vice versa?) is what the modified WT (see my
source, it's based on the WT Matsui used) will output.
> >Question: what is the diff between linear/affine?
>
> In practice, not much. Often we see people talking about not having a
> "linear" system, and what they mean is to not have an "affine" system.
> The distinction is rarely made and often meaningless.
>
> But the academics among us may have a more precise view, in which case
> I wish they would comment on the entries in my Glossary.
I hope they do :)
Tom
--
Want your academic website listed on a free websearch engine? Then
please check out http://24.42.86.123/search.html, it's entirely free
and there are no advertisements.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: New and want to learn
Date: Sat, 29 Apr 2000 10:32:11 GMT
Monolo wrote:
>
> Hello, I am new, and wish to learn lots about cryptology. If anyone would
> mind helping me, could you e-mail me at [EMAIL PROTECTED]??? Thanks!
>
> Monolo
Just post questions.
Tom
--
Want your academic website listed on a free websearch engine? Then
please check out http://24.42.86.123/search.html, it's entirely free
and there are no advertisements.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: The Illusion of Security
Date: Sat, 29 Apr 2000 10:34:30 GMT
Joseph Ashwood wrote:
>
> Again I will state that these changes change the algorithm,
> which of course has different security properties. Changing
> the s-boxes certainly changes the security. Changing the key
> schedule is as I stated before the difference between
> Vigenere and a stream cipher. Changing them both arbitrarily
> one could claim that Blowfish, DES, IDEA, and CAST are the
> same.
> Joe
Um sure believe what you want. I am not going to continue this
irrational argument.
Points to be made:
1. You can change the keyschedule to change the resistance to
bruteforce. It's already been discussed.
2. No you cannot change the key schedule and get another block cipher,
because F functions in feistel structures are DATA dependant as well not
just key dependant
3. If you change the keying in a Vinegere cipher it's no longer that,
it's some other stream cipher. That's completely different.
Read the papers I suggested, otherwise shut up.
Tom
--
Want your academic website listed on a free websearch engine? Then
please check out http://24.42.86.123/search.html, it's entirely free
and there are no advertisements.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Help In encryption!!!
Date: Sat, 29 Apr 2000 10:35:26 GMT
[EMAIL PROTECTED] wrote:
>
> Hi:
>
> I was wondering which would be the best and
> easiest encryption algorithm to code using C++,
> such that it could be implemented for a class
> project. Also can someone point me to some
> encryption algorithms where there is a full
> description of the process.
>
> Thanks a lot!
Look up Blowfish at
http://www.counterpane.com
It's relatively easy to understand and implement.
Tom
--
Want your academic website listed on a free websearch engine? Then
please check out http://24.42.86.123/search.html, it's entirely free
and there are no advertisements.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: As long as we are asking naive questions...
Date: 29 Apr 2000 06:38:46 EDT
My extremely limited messing around with crypto has shown me that in
some systems encrypting twice with the same algorithm and key turns
the plaintext into itself. My first naive impression of multiple
encryption with different algorithms and keys would make the attackers
job much harder. But would it? Could it be that some common elements
that I don't understand are undoing each other, making the result easier
to crack rather than harder? I am very wary of deviations from normal
practices when I am dealing with things that I don't fully understand.
In many fields the real expert can break the rules because he knows the
details, but a newbie needs to stich to the rules until he knows which
ones can be broken under certain conditions.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Speaking of HD Overwriting...
Date: 29 Apr 2000 06:49:36 EDT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (NFN NMI L.
a.k.a.
S.T.L.) wrote:
>
><<What I failed to make clear is the difficulty of reading the parts where "the
>very outer edge of the area affected by the laser will not be as heated as more
>central parts of that area [and] on rewriting, jiggling of the laser, etc, may
>cause the laser to miss those outer edges and not melt the entire previous
>area".
>You will have a hard time using light, because the wavelength would be too long
>to see such small details.>>
>
>Of course. And no one said reading overwritten HDs was easy either. But my
>question still remains: IS there something left there, after a bit has been
>overwritten, that would indicate the bit's former state? Even if you have to
>go over the CD-RW atom by atom with an STM.
As an engineer who has done a LOT of work in this field, my professional opinion
is yes. There may be something left there, after a bit has been overwritten,
that would indicate the bit's former state. I can't say that there *IS* because
you might have overwritten a small spot with a larger spot. For myself, I write
sensitive data only to a floppy disk, and I toss it in my fireplace and burn it
to destroy the data.
------------------------------
From: "Roman - do not replay" <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.ms-windows.ce,comp.sys.handhelds,comp.sys.palmtops,de.comp.security,microsoft.public.de.german.windowsce,microsoft.public.windowsce
Subject: Transparent encryption for Windows CE
Date: Sat, 29 Apr 2000 13:26:10 +0200
Reply-To: "Roman - do not replay" <[EMAIL PROTECTED]>
Make sure you are the only one who has access to data
on your Windows CE computer.
SoftWinter, Inc. releases a Windows CE version of it's popular
transparent encryption product Sentry 2020. Sentry 2020/CE uses
strong encryption algorithms to seamlessly encrypt files
as they are being accessed by applications like Word, Excel, etc. Sentry
2020 for Windows CE is compatible with Sentry 2020 for Windows NT, which
allows the use of the same encrypted volumes on your desktop computer, as
well as your mobile CE computer.
Download a fully functional evaluation copy.
http://www.softwinter.com/ce.htm
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Speaking of HD Overwriting...
Date: 29 Apr 2000 11:52:13 GMT
Guy Macon <[EMAIL PROTECTED]> wrote:
> >Well, `audio, -ire, -ivi, -itum' is Latin fourth declension, while
> >`video, -ere, -i, -isum' is (slightly odd) second declension. But
> >that only begs the quesion.
>
> Good guess! Wrong, though. Think Greek vs. Latin...
Where's the factual inaccuracy? Those Latin verbs really do exist.
-- [mdw]
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Sbox Generator Update
Date: Sat, 29 Apr 2000 12:05:38 GMT
[I apologize if this appears twice, but it seems to me my news server
didn't post this...]
I updated my sboxgen program today for fun. I added the ability to make
compression sboxes and single cycle permutations. So now you can make
sboxes of size m by n (m>=n) which are either SAC and/or SC compliant.
The source:
http://24.42.86.123/sboxgen.c
Is free for anyone to use, and is mainly based on some papers I got from
Fauzan Mirza. It's relatively easy to use.
Just to show it works I have a set of "des" style 6x4 sboxes:
http://24.42.86.123/desbox.txt
Those sboxes are SAC compliant and linearly bounded to "p = 1/2 +-
10/64", I dunno about differential cryptanalysis...
Anyways enjoy and please do comment.
Tom
--
Want your academic website listed on a free websearch engine? Then
please check out http://tomstdenis.n3.net/search.html, it's entirely
free and there are no advertisements.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Sat, 29 Apr 2000 05:19:07 -0700
Taneli Huuskonen wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In <[EMAIL PROTECTED]> Anthony Stephen Szopa
> <[EMAIL PROTECTED]> writes:
>
> >Taneli Huuskonen wrote:
> [...]
> >>
> >> Usg IIP MixFile1 MixFile2 MixFile3 Digit
> >> 1 8 6327491805 5382460791 1352094678 9
> >> 2 3 7246301598 6153704298 7801354926 7
> >> 3 5 7845069213 4019682573 2184065379 1
> >> 4 9 1904735268 4273860915 8670159423 3
> >> 5 1 0819374256 6421935087 9710324865 0
> >> 6 7 3145682790 8601534279 8523419670 6
> >>
> [...]
>
> >You obviously don't have a clue what a table is for or what you are
> >looking for in this table or what you need to reply to let me know
> >that you "get it."
>
> So far, I've made an attempt to keep the discussion civil, even though
> I've often been tempted to behave otherwise. However, if you further
> insist on turning the discussion into a flamefest, I'll see what I can
> contribute in that respect.
>
> I thought you'd devised an algorithm that took the first five columns of
> your table as input and produced the digit in the sixth column as
> output, and I attempted to do the same. I came up with an algorithm
> whose output agreed with your table, and posted some sample results.
>
> I have two questions.
>
> 1) Does OAP-L3 Version 5.0 contain a pseudorandom digit generator, each
> output digit of which is generated from five data items, corresponding
> to the leftmost five columns of your table, and mine as well?
>
> 2) If those five columns of my table were used as input to the
> pseudorandom digit generator, one row at a time, would it output the
> digits in the sixth column, except that the digit in the fifth row
> should be 5?
>
> >When I release OAP-L3 Version 4.3 I will make available the paper I
> >wrote explaining the fundamentals upon which Version 5.0 will be
> >based. This table will be included, of course.
>
> OK, my questions above will be answered then. I'd just like to get
> simple yes/no answers to them now.
>
> >Also note that you have misrepresented the random number generator
> >when you say the random digit generator in OAP-L3 is not
> >cryptologically secure.
>
> No, I didn't. I was careful to distinguish between the pseudorandom
> digit generator, which is part of OAP-L3, and the whole of OAP-L3. The
> former is definitely insecure. This insecurity may or may not be
> completely covered by subsequent processing, probably depending on the
> key. I don't know what kind of keys, if any, would result in OAP-L3
> being unbreakable by a competent cryptanalyst with ample computing
> resources, but I wouldn't be surprised if such keys existed.
>
> Some people have obviously misunderstood the nature of my challenge to
> you. However, I haven't done anything deliberate to cause such
> misunderstandings; on the contrary, I've occasionally corrected other
> posters about it.
>
> [...]
>
> >Your requirements to do this only prove that the entire random number
> >generator process IS secure and here is why.
>
> My requirements prove that OAP-L3 is secure against one particular
> clueless person who doesn't want to spend more than a few hours probing
> it for potential weaknesses, nothing more.
>
> [...]
>
> >You are not in my kill file but I will only reply to honest and
> >intelligent posts from you in the future.
>
> My criteria for deciding which postings I follow up are different.
>
> Taneli Huuskonen
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 5.0i for non-commercial use
> Charset: noconv
>
> iQA/AwUBOQhQ/F+t0CYLfLaVEQLImgCfRTeqmfhDO1+0ee3hXkjJgXjnlEoAnR7B
> gAlyZUYRv+sz0wdZi1X4cNfz
> =S41S
> -----END PGP SIGNATURE-----
> --
> I don't | All messages will be PGP signed, | Fight for your right to
> speak for | encrypted mail preferred. Keys: | use sealed envelopes.
> the Uni. | http://www.helsinki.fi/~huuskone/ | http://www.gilc.org/
You are mistaken when you claim that "The former is definitely
insecure."
How can the random digit generator be insecure when its output is not
used to encrypt messages? It is not exactly the same, but the
ridiculousness of your position is just as ridiculous as someone
claiming that a safe is not secure because of the combination: someone
can get in the safe if they have the combination. You want the
combination to the random digit generator once removed (the random digit
output) then claim that it is insecure. Insecure from what? The key?
Well, I do not know of any encryption software that is not insecure
against someone who has the key?
I know, you will twist and turn and try to stuff your position into
your argument.
The standard test to determine the security of encryption software
is to have a cracker attempt to crack the encrypted messages with
only:
1) complete knowledge of the encryption software
2) substantial encrypted text
3) the corresponding plain text
The random digit generator is transparent to the random number
generator. You cannot see it: you cannot see its output or have
access to its output. The output from the random digit generator
is not used to encrypt messages.
Guess what? I intentionally do not use the output from the random
digit generator to encrypt messages in the current implementation.
You have not proven a case why your machinations have anything to do
with the security of OAP-L3.
So, why don't you first justify why your pathetic approach to show
that OAP-L3 is insecure in any respect is logically justified and
worthy of further consideration in light of the above points?
Lots of luck.
------------------------------
From: "Helger Lipmaa" <[EMAIL PROTECTED]>
Subject: Vs: Vs: sci.crypt think will be AES?
Date: Sat, 29 Apr 2000 13:14:32 +0300
David A. Wagner <[EMAIL PROTECTED]> kirjoitti
viestissä:8e9r4n$3kj$[EMAIL PROTECTED]
> In article <8e6vhc$a9e$[EMAIL PROTECTED]>,
> Helger Lipmaa <[EMAIL PROTECTED]> wrote:
> > the fastest bulk encryption
> > mode of Twofish (that is still slower than Rijndael) requires key
scheduling
> > that is at least 40 times slower than the key scheduling of Rijndael.
>
> I believe this to be untrue.
> Yes, Twofish's keyschedule is slower, but not *that* much slower.
>
> All told, if you measure this in a fair and representative way,
> the right factor seems to be about 5x, for applications where key
> scheduling time is important.
> It is true that the Rijndael key schedule is faster, but it need
> not be 40x faster.
I started the sentence with saying 'the fastest bulk encryption mode', i.e.,
in the mode were Twofish achieves the best encryption rate per block. It is
true that in other modes Twofish has faster key schedules, but in those
modes also it bulk encrypts smaller. Moreover, And as I already stressed,
implementing more than one Twofish mode is an undesirable thing from the
complexity viewpoint.
> You did not state how you arrived at the "40x" figure, but I can
> guess that it rests on some shaky premises. Here are several things
> you did not say, which I think are relevant:
I took them from Gladmans online table,
http://www.btinternet.com/~brian.gladman/cryptography_technology/aes2/
There, keying 128-bit Rijndael takes 207 cycles (together with decryption
key, 1382 cycles) and Twofish 8538 cycles. Mea culpa, I really meant
_encryption scheduling_ only. If you also count decryption key scheduling,
the difference is 6.2 times.
> If you see any omissions in the above discussion or calculation, I do
> hope you will point to where I am in error.
Not significant omissions, I quite agree with you actually:
1. If you take the zero-keying mode, Twofish encrypts even slower than
Serpent.
2. If you take the full-keying mode, Twofish has an awfully slow key
schedule, and it is only somewhat
(~20%) slower than Rijndael in encryption.
3. If you take the intermediate modes, Twofish is a moderately fast
algorithm, but nothing fancy, really.
3. Am I the only one who doesn't want to implement both modes?...
All the above is said from an implementers perspective: I did an
implementation of Twofish on Pentium II that was about 10% faster than that
of cipher designers (which I guess means Doug), but I hated implementing the
key schedule. Also the round function has properties that make Twofish
inherently slower than Rijndael...
Helger
http://www.tcm.hut.fi/~helger
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Modification of RC5
Date: Sat, 29 Apr 2000 13:26:46 GMT
It has been shown in [1] that there is a 2^-10r chance of randomly
picking a weak key where there are no rotations. Well bored as I am I
came up with a relatively quick method to avoid weak keys in RC5 all
together.
What I do is instead of rotating one register by another like "A <<< B"
I put 'B' thru four 8x5 sboxes and xor them togther to get "A <<< F(B)"
which means all bytes of 'B' affect the rotation. The sboxes of course
are SAC so that single bit changes will change the rotation count
dramatically. This means the avalanche is much higher as well which
suggest cryptanalysis would become harder. I did a "newbie" test where
I reduced RC5 to 2 rounds and switched the msb. Most of the plaintext
(after decryption) was intact. However with RC5a very little was intact
(i.e what it was suppose to be). I know this type of analysis is very
primitve... so can someone please respond!!!
I modified the RC5 REF source to include my additions, you can see it at
http://24.42.86.123/rc5a.c.
I wouldn't mind any academic analysis of sboxgen.c (my sbox generator)
or rc5a. It seems not alot of people are really responding here...
hmm..
Tom
--
Want your academic website listed on a free websearch engine? Then
please check out http://tomstdenis.n3.net/search.html, it's entirely
free
and there are no advertisements.
------------------------------
** 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
******************************
