Cryptography-Digest Digest #548, Volume #11 Fri, 14 Apr 00 16:13:01 EDT
Contents:
Re: BlowWire ([EMAIL PROTECTED])
Re: BlowWire ([EMAIL PROTECTED])
Re: BlowWire ([EMAIL PROTECTED])
Re: Q: NTRU's encryption algorithm (Mike Rosing)
Re: ? Backdoor in Microsoft web server ? (Francois Grieu)
DES Trapdoor Claims ([EMAIL PROTECTED])
Re: from table to function (Mike Rosing)
Re: Biggest Public-key Cryptography Crack Ever (Mike Rosing)
Re: JOKER:Ask for Cryptosystem (Mike Rosing)
Re: ? Backdoor in Microsoft web server ? ("Robert J. Clark")
Re: DES ("Douglas A. Gwyn")
Re: new Echelon article ("Douglas A. Gwyn")
Re: O(...) - Newbie question ("Douglas A. Gwyn")
Re: Biggest Public-key Cryptography Crack Ever (John Myre)
SHA1 algorithm verification ([EMAIL PROTECTED])
Re: new Echelon article (JimD)
Re: from table to function (John Myre)
Re: JOKER:Ask for Cryptosystem ("Douglas A. Gwyn")
Re: One way hashing function (Tom St Denis)
Bug in CryptoBag (Tom St Denis)
Re: The use of Three DES (Tom St Denis)
Hayden briefing on so-called "Echelon" ("Douglas A. Gwyn")
Re: Q: Entropy (Bryan Olson)
Re: from table to function (Tom St Denis)
CryptoBag Source (update) (Tom St Denis)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: BlowWire
Date: Fri, 14 Apr 2000 16:58:49 GMT
In article <8d66ti$7up$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Paul Rubin) wrote:
> It's worse than that. If you look at how the Blowfish key schedule
> works, you'll see that the pi table is replaced at key initialization.
> You need 4k bytes of *RAM* at each round, not ROM.
I didn't think Mr. Spleen was going to unroll the loop... if so, he'd
need 32 32-bit adders...
And if you have
> several keys active at the same time, you need another 4k of ram
> for each of them.
Yep
> Blowfish is designed for software implementation and it's inefficient
> in hardware. It's not really the right cipher to implement with the
> methods you're describing.
No, its possible, and its a fascinating challenge. DES is dead.
AES ain't here, too green, will take twice the hardware resources.
IDEA can be done with no memory, but you spend more gates on
those multipliers. There's a group in .ee that's done an IDEA + RSA
chip, 25 Mhz, a few years ago. Their cleverness was building
multipliers that could be used for both. IDEA is key-agile, BTW.
=====
"There are no ifdefs in hardware."
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: BlowWire
Date: Fri, 14 Apr 2000 17:07:52 GMT
In article <HZxJ4.7246$[EMAIL PROTECTED]>,
"Spleen Splitter" <Spleen*no spam*[EMAIL PROTECTED]> wrote:
>But for layout, I'm looking at making 4 copies of
the pi
> table with 4 banks and 4 ports, 4 copies of the keys in 4 port
register files,
> and so on, and fun with wires arranging the pipelined rounds in a 2x8
pattern.
> So I'm actually looking at 16KB in the pi tables and 4KB in the keys.
No, you don't have it right. You load the pi table into the equal
sized RAM; then you mix in your key and grind for 521 [sic] iterations.
Mind your bit order; you'll find big and little endian Pi
out there. Unless you calculate your own :-) In hardware :-) :-)
> I was just curious to hear about other folks trying to implement such
things,
> since software is too slow
And bandwidth is growing too fast
> and FPGAs don't quite make it.
You'd be surprised, and they have a lot of memory these days.
Better
insight into
> the algorithm helps, too.
You will dream of round functions by the end...
> Plus, I don't have to worry about how many
gates
> I burn on this project.
Workin' for the spooks?
=====
"There are no ifdefs in hardware."
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: BlowWire
Date: Fri, 14 Apr 2000 17:20:10 GMT
In article <F1zJ4.3613$[EMAIL PROTECTED]>,
"Spleen Splitter" <Spleen*no spam*[EMAIL PROTECTED]> wrote:
> I'm interested in the general mapping of algorithms to hardware. The
random
> tides swung to Blowfish. I don't care how big it is. The more gates
the
> example burns the better as far as I'm concerned, as long as the
objective
> is met.
That "mapping" is really a redesign process, and the reason
why design engineers get paid well. You use the general-purpose
(e.g., "C") implementation as a reference. Add lots of printfs.
Watch the halves swap. Zero the subkeys and watch it.
If you want to burn gates but not spend transistors on RAM, do IDEA.
Use lots of multipliers, and go ahead, unroll a few stages. Or do an
RSA accelerator. Commerce servers need them badly.
> > I think it would be much more interesting and useful to build a
FULLY
> > pipelined version of triple-DES, with separate S-boxes at each of
all
> > 48 rounds, so it's a completely asynchronous circuit (no clocking)
whose
> > speed is limited only by the gate and lookup delays through the
pipeline.
>
> Ok. This can be good, too. I'll go look for the code. Not sure
about that
> asynchronous stuff, tho. Dynamic logic is getting somewhat out of
favor as
> we go below 100nm.
Really?
Paul's async idea is interesting because self-timed design is
interesting, though largely confined to research, but unrolling DES is
not very challenging by itself.
=====
"There are no ifdefs in hardware."
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Q: NTRU's encryption algorithm
Date: Fri, 14 Apr 2000 11:24:48 -0500
Mok-Kong Shen wrote:
> Many thanks. How big is the factor of expansion (in average cases)?
About 3. If you use the same key for signitures it can be lowered
to almost 1.1 , so it depends on how it's used.
> Is the comparison with RSA on the web page of NTRU fair?
Kind of. The math is definitly faster. I don't think anyone is
really sure about the security yet.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: ? Backdoor in Microsoft web server ?
Date: Fri, 14 Apr 2000 19:38:56 +0200
Update on previous post
Disclaimer: I have NOT verified this story, which may be bogus.
According to CBS marketwatch and CNET, both citing The Wall Street
Journal, Steve Lipner (Microsoft's lead program manager on security
issues) has acknowledged the existence of a "backdoor" in one of the
company's web server software. Knowledge of a global password would
grant [?read-all?] privileges on thousands of web servers that use the
Microsoft software.
The backdoor is said to be in "dvwssr.dll", containing text [?related to
the password?] "Netscape engineers are weenies".
I'm seeking first-hand confirmation of the story. I did NOT find it in
the Friday 14th EUROPEAN paper edition of The Wall Street Journal.
Please advise if it is found in the US or electronic edition.
Francois Grieu
Links working at time of writing (some may be short-lived):
<http://news.cnet.com/news/0-1003-200-1696137.html>
<http://cbs.marketwatch.com/news/current/msft.htx>
<http://aolpf.marketwatch.com/source/blq/aolpf/archive/20000414/news/curr
ent/press_briefing.asp>
<http://www.marketwatch.newsalert.com/bin/story?StoryId=CopAxWdicvJa2mtC&;
FQ=Microsoft&ED=04/14/2000&Title=Headlines%20for%3A%20Microsoft%0A#Hilite
>
------------------------------
From: [EMAIL PROTECTED]
Subject: DES Trapdoor Claims
Date: Fri, 14 Apr 2000 17:33:08 GMT
At least two posters here have stated in this forum that DES has trap
doors...including Jack Diamond..
Jack...I repeatedley asked you in private email, and also publicly in
this forum that since you claim that DES has a trap door, you should
come out and make your statement in full but you have refused to do that
publicly or privately. I believe also others have responded to your
message in this forum but you have refused to substantiate your claim.
In the interest of Privacy for Joe Public and in the spirit of those who
fought hard for the liberlisation of crypto and privacy laws
(Diffe Hellman/Zimmerman)...your position goes against the grain..If you
know something as you claim you do..Publish it here..as I told you in my
email...
As you know DES has been studied more then any other cipher by top
crypto experts...
Your implication of a trap door..suggest that you are thinking either
about the Modification of the original IBM S-Box design (according to
Alan Konheim of IBM)....or more ominously....there could be some really
clever trap door in the Feistal Design which by some clever and not
known or published algorithm reverses or traverses the Feistal network
to yield the key...If that is the case , heavens help us, because most
of the modern ciphers are based on the original Feistal Network
design...
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: from table to function
Date: Fri, 14 Apr 2000 11:51:34 -0500
Tom St Denis wrote:
>
> How exactly did they expand the Serpent Sboxes into a series of
> algebraic instructions? Can you do this to any random permutation?
Don't know the answer to the first question. but I can see at least
one hard way to solve the second :-)
You basicly write out a system of equations. You know what the inputs
are and what the outputs are, and if it's just a permutation then you
know there's a one-to-one map between them. If you have as many pairs
of inputs/outputs as there are bits, you can solve for the permutation
directly.
S-boxes aren't permutations. They are non-linear functions. The
serpent design probably started from a set of functions and created
the S-box tables from that. Knowing the functions allowed them to
create the list of algebraic instructions trivially, but going
backwards from the S-boxes would be almost impossible.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Biggest Public-key Cryptography Crack Ever
Date: Fri, 14 Apr 2000 11:45:35 -0500
Robert Harley wrote:
>
> Readers of sci.crypt might be interested in the following press-release.
>
> Enjoy!
Congratulations!!
> Harley remarked "Even so, it was only about one tenth of what should
> normally be required for a 109-bit curve. That's because Certicom
> chose a particular curve with some useful properties but we used those
> same properties to speed up our attack". He went on to say "This
> underlines the danger in adopting particular curves and the need to
> pick random ones with no special characteristics. I'm concerned about
> Koblitz curves and complex-multiplication curves, which some people
> advocate using in order to avoid the point-counting problem".
So we need another 4 bits. The speed advantage is rather significant,
especially for an 8 bit microcontroller. In other words, we can make
the cracking task 10 times harder rather easily by simply choosing
larger field sizes.
My understanding is that *all* curves over a finite field have a
complex multiplication isogeny. Finding it isn't so simple.
There are specific curves over complex quadratic fields that make
point counting trivial, but again, we can just increase the field
size and make the cracking effort harder by a few orders of
magnitude.
In any case, nice work. You're going to need more machines for the
next one, so post the start of that project here!
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: JOKER:Ask for Cryptosystem
Date: Fri, 14 Apr 2000 12:00:19 -0500
José Antonio Fuentes Fernández wrote:
>
> I have done a little cryptosystem but I don't know how smart is. Is
> there some software to prove it or some place where can prove it?
> I agree any answer. Thanks for all.
> Sorry for my English.
---------------------------------------------------------------
Post it here:
http://www.wizard.net/~echo/crypto-contest.html
Patience, persistence, truth,
Dr. mike
------------------------------
From: "Robert J. Clark" <[EMAIL PROTECTED]>
Subject: Re: ? Backdoor in Microsoft web server ?
Date: Fri, 14 Apr 2000 14:01:13 -0400
http://www.securityfocus.com/templates/archive.pike?list=1&date=2000-04-8&[EMAIL PROTECTED]
It also has code to test the backdoor.
- Rob
Francois Grieu wrote:
>
> Disclaimer: I have NOT verified this story, which may be bogus.
>
> According to <http://cbs.marketwatch.com>, citing The Wall Street
> Journal, Microsoft has acknowledged the existence of a "backdoor" in one
> of it's consumer web server software. Knowledge of a global password
> would grant [?read-all?] privileges on thousands of deployed web servers.
>
> The backdoor is said to be in "dvwssr.dll", containing text [?related to
> the password?] "Netscape engineers are weenies!".
>
> Anyone can confirm this story ?
>
> Francois Grieu
>
> sources (these URL may be short-lived):
>
> <http://cbs.marketwatch.com/news/current/msft.htx?source=htx/http2_mw>
>
> <http://aolpf.marketwatch.com/source/blq/aolpf/news/current/press_briefin
> g.asp>
>
> <http://www.marketwatch.newsalert.com/bin/story?StoryId=CopAxWdicvJa2mtC&;
> FQ=Microsoft&ED=04/14/2000&Title=Headlines%20for%3A%20Microsoft%0A#Hilite
> >
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: DES
Date: Fri, 14 Apr 2000 17:36:32 GMT
Chris Williams wrote:
> Where do I sign up for the "svelte blonde cryptanalysis" ? :)
You could trying signing up with the US Marines and working
to get assigned as a guard in our embassy in Moscow. I don't
know how well known the story is, but we had an ambassador
whose disdain for security was so bad that eventually the
Soviets managed to get into the communication center and
plant a device that transmitted out the unencrypted side..
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: new Echelon article
Date: Fri, 14 Apr 2000 17:51:31 GMT
[EMAIL PROTECTED] wrote:
> Think about it. As I've noted before, how can General
> Dynamics/Electric Boat build a better submarine if it doesn't have
> information on the capabilities of the submarines built by
> allies/enemies of the U.S.? How could Lockheed build the U-2 or the
> SR-70? Doesn't the CIA/NSA keep tabs on the capabilities of fighter
> aircraft built by other countries, and then pass that info to U.S.
> makers of fighter aircraft?
The way it actually works is that intelligence on foreign
capabilities goes to the Executive branch and especially
the miltary, which factors it into the specifications for
new weapons systems. The contractors then build to those
specifications. When some aspects of the contract must be
protected for national security reasons, individual members
of the contracting companies are given access to that
specific information, after clearance etc. There is no
general attempt to provide US corporations with foreign
proprietary commercial information for economic advantage.
> ... And if the CIA/NSA are helping specific U.S.
> corporations beat their foreign competition, ...
Which as a matter of policy and law they are not. There
may well be individuals who violate the policy/law on their
own initiative, but when we catch them we punish them.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: O(...) - Newbie question
Date: Fri, 14 Apr 2000 17:56:57 GMT
Bob Silverman wrote:
> Does anyone know Auntie-Derivative's recipe for lim soup?
No, but I recently heard the answer to the following riddle:
What's yellow and equivalent to the axiom of choice?
in response to my asking the well-known riddle:
What's purple and commutes?
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Biggest Public-key Cryptography Crack Ever
Date: Fri, 14 Apr 2000 12:26:06 -0600
Mike Rosing wrote:
>
> Robert Harley wrote:
> >
<snip>
>
> > Harley remarked "Even so, it was only about one tenth of what should
> > normally be required for a 109-bit curve.
<snip>
>
> So we need another 4 bits. The speed advantage is rather significant,
> especially for an 8 bit microcontroller. In other words, we can make
> the cracking task 10 times harder rather easily by simply choosing
> larger field sizes.
Wouldn't that be 7 bits, because of the square root?
And this also assumes, of course, that 1/10 is a consistent ratio,
within a the relevant range of field sizes. Those that advocate
random curves are, I think, making the conservative assumption that
even smarter (faster) shortcuts are going to turn up.
Who knows, eh? It's crystal ball time...
John M.
------------------------------
From: [EMAIL PROTECTED]
Subject: SHA1 algorithm verification
Date: Fri, 14 Apr 2000 18:37:31 GMT
Hello,
Has anyone tried to compute the SHA1 for the third example from the
SHA1 standard document (for 1000000 'a's) ? My implementation of this
algorithm works for the first two examples, but it does not return the
correct value. I've fixed several errors on the way, but I still can't
get the right hash value. I would appreciate if someone could tell me
if that third example is ok, so I could tell if the error is in my code
or not.
Thank you,
Martin
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (JimD)
Crossposted-To:
alt.politics.org.cia,alt.politics.org.nsa,alt.journalism.print,alt.journalism.newspapers
Subject: Re: new Echelon article
Reply-To: JimD
Date: Fri, 14 Apr 2000 18:06:47 GMT
On Thu, 13 Apr 2000 10:35:23 -0700, "Stou Sandalski" <tangui
[EMAIL PROTECTED]> wrote:
>
><[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> Tell me boys, ever hear of the Glomar Explorer???
>
>wasn't that the ship howerd hugues built for the cia to raise a russian
>nuclear sub? In some book I read as a side note the author mentioned that
>the CIA had placed a 12 ton plutonium powered tap on some underwater
>telephone cable to soviets had... anyone heard about that?
All very true. The following link has full details and even a
photo' of the submarine tapping gizmo:
http://www.cyber-rights.org/interception/stoa/ic2kreport.htm
It was a military cable in the Soviet far east. Kamchatka I think.
>and what about
>that time the british and americans taped that phone cable that was on the
>east german side?
That's true as well, but I don't have a reference, although I've seen
photographs of the tunnel in some book. The Soviets discovered that
one too as well as the Kamchatka tap.
The document at the source above also gives details of the mechanism
by which the NSA/CIA distributes suitably laundered COMINT-derived
information to US industry.
--
Jim Dunnett.
dynastic at cwcom.net
Londoner? Vote for Ken!!
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: from table to function
Date: Fri, 14 Apr 2000 13:10:30 -0600
Mike Rosing wrote:
>
> Tom St Denis wrote:
> >
> > How exactly did they expand the Serpent Sboxes into a series of
> > algebraic instructions? Can you do this to any random permutation?
Have you seen the post by Gisle Saelensminde? It references the
wonderful paper by Dag Arne Osvik on exactly how he went about it.
Abstractly, since the computer can compute it, then of course you
can represent it algebraically. You could even set up a program to
do it automatically (that is, write out the formula). See below
for more.
The end result might not be very efficient.
>
> Don't know the answer to the first question. but I can see at least
> one hard way to solve the second :-)
>
> You basicly write out a system of equations. You know what the inputs
> are and what the outputs are, and if it's just a permutation then you
> know there's a one-to-one map between them. If you have as many pairs
> of inputs/outputs as there are bits, you can solve for the permutation
> directly.
>
> S-boxes aren't permutations. They are non-linear functions. The
> serpent design probably started from a set of functions and created
> the S-box tables from that. Knowing the functions allowed them to
> create the list of algebraic instructions trivially, but going
> backwards from the S-boxes would be almost impossible.
The Serpent design started with the DES S-boxes. The NSA designed
those, which means I suppose that we don't know *exactly* how
they did it.
Finding (boolean) functions for smallish S-boxes is easy; you just
write down formulas for each output bit separately. For example,
suppose we have a 3x3 S-box [4,2,7,1,2,6,0,4] (the list of 8
output values). Define "in" as the three-bit input, with the
three bits in0, in1, in2 from least to most significant. Define
"out" and out0, out1, out2 similarly.
So, note that out0 is set when in=2 or in=3. We can write this
as out0 = (in0=0 and in1=1 and in2=0) or (in0=1 and in1=1 and in2=0).
>From there you use algebra; you can convert to using whatever boolean
operations you have available (AND, OR, NOT, XOR, NAND, NOR, etc, etc).
The above could be written out0 = in1 and (not in0).
Of course, getting optimal, or even short, formulas is another
subject. But it's the sort of thing that hardware designers do
all the time (adders, multipliers, and everything else).
>
> Patience, persistence, truth,
> Dr. mike
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: JOKER:Ask for Cryptosystem
Date: Fri, 14 Apr 2000 18:06:20 GMT
There is no simple test that can prove the security
or lack of security of all cryptosystems. The usual
approach is to give it to professional cryptanalysts
and let them study the system and give you an opinion.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: One way hashing function
Date: Fri, 14 Apr 2000 19:32:01 GMT
Runu Knips wrote:
>
> [EMAIL PROTECTED] schrieb:
> >
> > Dear all,
> >
> > Would you mind telling me where can I find any one-way hashing
> > algorithm? TIA.
> >
> > Thanks,
> > Simon
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
> Many places. For example, www.openssl.org, www.gnupg.org,
> Tom St Denis' Cryptobag ....
Hey I am famous now...cool.
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Bug in CryptoBag
Date: Fri, 14 Apr 2000 19:33:30 GMT
There is a bug in the RC6 key schedule I found. So I am putting a halt
on release of CB until I can go thru all the ciphers. If anyone spots
anything else?
BTW if you are using CB right now I can private email the version I am
using in pb3 [with the fixes and few other oddities]. I will release
the next CB when I am happier with it.
Any other comments about CB?
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: The use of Three DES
Date: Fri, 14 Apr 2000 19:35:15 GMT
Runu Knips wrote:
>
> Tom St Denis wrote:
> > Why use old technology?
>
> Well not long ago I told someone (who was also a computer
> science student) AMD has released a very good new i386
> compatible cpu, the Athlon. He said he would still prefer
> to buy Intel, because that is more "secure".
>
> Or the well-known statement (of the past?) "nobody got
> ever fired for buying an IBM computer".
>
> Its always the same: people have used it for ages, now
> it is "good" just because they know it so well.
Well I seriously doubt the processors (i386) and (PIII) work the same
way, despite supporting similar instruction sets. This comparison is
not valid.
Tom
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Hayden briefing on so-called "Echelon"
Date: Fri, 14 Apr 2000 18:57:51 GMT
The following URL contains links to text and viewfoils
of a statement made by DIRNSA Wednesday (which is why
he was unable to attend the AFCEA conference):
http://www.nsa.gov/releases/speeches.html
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Q: Entropy
Date: Fri, 14 Apr 2000 19:31:50 GMT
Mok-Kong Shen wrote:
> Now, I happen to find the following:
>
> For a Turing machine M_i, and a finite string x, the Kolmogorov
> complexity of x with respect to M_i is defined as follows:
>
> K_i(x) = min{ l | (ex y) |y| = l and M_i(y) = x }
>
> K_i(x) = infinity if the above set is empty.
>
> on p.70 in O. Watanabe (Ed.) Kolmogorov Complexity and Computational
> Comlexity, Springer, 1992.
>
> Here one has only the term 'finite string', should I understand
> that the string's length has some implied (not given in the text)
> constriants, like the length must exceed certain fixed lower bound,
> etc. etc, or does it simply means ANY finite string that one chooses
> to pick out and examine?
It means what it says of course: "for any finite string x".
Note that this definition agrees with what I wrote:
| The Kolmogorov complexity of a finite sequence depends upon
| the language in which we write the programs.
And with what James Felling wrote:
: Over a given set of languages L, it is possible to make
: "K-complexity relative to L" comparisons between two strings
: S1 and S2
Here the input y is written as a program for M_i. Absent
reference to the specific machine, the definition does not
define which of two strings has greater complexity. In fact
for _any_ two finite strings x and x', there are two
machines M_i and M_j such that
K_i(x) < K_i(x') and K_j(x) > K_j(x').
Kolmogorov complexity also defines a language-independent
metric. It defines complexity to within some additive
constant, so it does not describe individual finite strings.
Of course we've been over this before.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: from table to function
Date: Fri, 14 Apr 2000 19:45:09 GMT
Mike Rosing wrote:
>
> Tom St Denis wrote:
> >
> > How exactly did they expand the Serpent Sboxes into a series of
> > algebraic instructions? Can you do this to any random permutation?
>
> Don't know the answer to the first question. but I can see at least
> one hard way to solve the second :-)
>
> You basicly write out a system of equations. You know what the inputs
> are and what the outputs are, and if it's just a permutation then you
> know there's a one-to-one map between them. If you have as many pairs
> of inputs/outputs as there are bits, you can solve for the permutation
> directly.
so if you had a 2x2 sbox you would get something like
ax + bx = A
cx + dx = B
ex + fx = C
gx + hx = D
Where (a, b) -> (A), (c, d) -> B, etc... We assume (a, b) [for example]
are pair of bits, and A is a 2 bit number? I don't quite get what you
are talking about...
>
> S-boxes aren't permutations. They are non-linear functions. The
> serpent design probably started from a set of functions and created
> the S-box tables from that. Knowing the functions allowed them to
> create the list of algebraic instructions trivially, but going
> backwards from the S-boxes would be almost impossible.
The sboxes in serpent are bijective so they are effectively a
permutation of 0..15 each [there are eight of them].
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: CryptoBag Source (update)
Date: Fri, 14 Apr 2000 19:59:29 GMT
Yet another WIP (work-in-progress) copy of CB is available from my
website at
http://24.42.86.123/cb_106b.zip
It includes a fix in the RC6 key schedule, a fix in the RSA
import/export routines, hmm a new RNG using SHA in counter mode, and the
ciphers now use a better way to load blocks.
Things todo:
1. Take into account big_endian when loading blocks for the symmetric
ciphers.
2. Similar for the hashes.
3. Similar for the RSA routines that use 'int' here and there.
Any comments please post. This is for software developpers, it's
entirely free and the source is all there. So if you like using it, or
want to see changes please let me know.
Tom
------------------------------
** 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
******************************
