Cryptography-Digest Digest #148, Volume #13 Mon, 13 Nov 00 10:13:01 EST
Contents:
Re: On an idea of John Savard (Mok-Kong Shen)
Re: so many fuss about impossibility to backtrace from MD to original (Ariel
Burbaickij)
Re: Q: Rotor machines (Mok-Kong Shen)
Q: timing attacks on cryptographic algorithms ("kihdip")
Thouhts on changes to rotor systems (Wesley Horton)
Re: Book recommendation, please (CiPHER)
Re: On an idea of John Savard (Tom St Denis)
Re: On an idea of John Savard (Tom St Denis)
Re: so many fuss about impossibility to backtrace from MD to original text. (Eric
Lee Green)
RC4 on FPGAs? ("ajd")
Re: "Secrets and Lies" at 50% off (Paul Crowley)
Re: Book recommendation, please (Dido Sevilla)
Chimera ciphers (WAS Re: On an idea of John Savard) (Paul Crowley)
Re: Why remote electronic voting is a bad idea (was voting through pgp) (Eric Lee
Green)
Re: Type 3 Feistel? (Paul Crowley)
Re: help with website (Dido Sevilla)
Re: RC4 on FPGAs? (Panu =?iso-8859-1?Q?H=E4m=E4l=E4inen?=)
Re: Q: timing attacks on cryptographic algorithms (Dido Sevilla)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On an idea of John Savard
Date: Mon, 13 Nov 2000 11:12:54 +0100
John Savard wrote:
>
> Tom St Denis <[EMAIL PROTECTED]>wrote:
>
> >If you mean to interleave the rounds of one cipher with another I
> >strongly suggest against this. Some ciphers such as RC2 or MARS only
> >work well if used in a particular fashion because of the directed
> >avalanche affect caused by unbalanced data networks.
>
> Yes, one would have to choose the particular ciphers with care.
>
> >Generally I do not think multiple encryptions or "permutations on the
> >encryption" are good ideas. Just add more rounds or use a better
> >cipher.
>
> But this is a way of constructing a better cipher. Alternating rounds
> - actually, for a Feistel cipher, pairs of rounds, but I think my
> suggestion with respect to SAFER+ and Rijndael is perhaps what is
> being referred to - by producing a cipher with a more varied structure
> makes it harder, I would think, to find the sort of things that
> differential and linear cryptanalysis can exploit.
As I understand, a common block cipher (there are certainly
exotic exceptions) is 'homogeneous' in the sense that the
rounds (cycles) are equivalent and relies on more rounds
(cycles) to reach the desired strength with the same
principle as multiple encryption with different ciphers.
Thus each round (cycle) could be regarded as an individual
cipher. From this your interleaving and my permutation
are most easily understandable. Any influence on strenth,
if there are any, is evidently easily compensated by
the ensuring complexity of the resulting combined algorithm.
M. K. Shen
------------------------------
From: Ariel Burbaickij <[EMAIL PROTECTED]>
Subject: Re: so many fuss about impossibility to backtrace from MD to original
Date: Mon, 13 Nov 2000 11:21:00 +0100
Paul Crowley wrote:
>
> Ariel Burbaickij wrote:
> > Why is it so many discussion about this point ? Surely everyone should
> > expect that let us say 4gb digested to 256 bytes or whatsoever are
> > not backtraceable.Why should one expect that is backtraceable?
> > Otherwise you have the very best compression algorithm ever suggested.
>
> A message digest function is considered broken if you can find *any*
> preimage of the hash; the challenge is not finding the exact preimage
> that generated a particular hash, which is as you say impossible if you
> don't have enough information to choose between the infinitely many
> possible preimages.
Have we indeed to do with infinite many original messages to do that maps
to one and the same digest ?At least in theory.If so why? And if indeed
infinite many why the fuss about the length of message digest.After all
you can have infinite messages that maps all to 1 or 0 . And it was then.
So I suppose that you have not infinite many but rather finite many.
Anbd the more the length the fewer the original messages that maps
to this particular message.But I can be false surely.
> __
> \/ o\ [EMAIL PROTECTED]
> /\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: Rotor machines
Date: Mon, 13 Nov 2000 11:25:02 +0100
Scott Contini wrote:
> John Savard <[EMAIL PROTECTED]> wrote:
> John,
>
> Can you give me a reference that gives the mathematical details of how
> the British broke Enigma? I have a brilliant article written by
[snip]
A recent thread led to writings of Tony Sale on that.
I haven't read then. But you can access
http://www.codesandciphers.org.uk/
for pointers.
M. K. Shen
------------------------------
From: "kihdip" <[EMAIL PROTECTED]>
Subject: Q: timing attacks on cryptographic algorithms
Date: Mon, 13 Nov 2000 11:31:24 +0100
Timing attacks uses the difference in computation time vs. the number of
zero's and one's in the input parameters.
Which is faster - zero's or one's ?? ;-)
I know it'll be highly dependant on the processor and the nature of the
algorithm, but can one in generel say that the 32-bit word of only zero's as
an input is faster than a 32-bit word of one's ??
Or is the answer that the only thing we know for certain is, that there is a
difference ??
Kim
------------------------------
From: Wesley Horton <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Thouhts on changes to rotor systems
Date: Mon, 13 Nov 2000 04:53:13 -0600
Does anyone care to share any thoughts on the a rotor system with the
following changes: (I recognize that these days rotor systems are not
secure per se.)
If you had a system similar to say the SIGABA, but had the encryption
rotors in such a fashion that certain rotors could be switched between
at odd intervals. For instance, say that the machine would use the
first rotor in normal fashion and then the second rotor could actually
be switched between two different rotors (machine controlled with
"regular irregular" switching. For example:
1 2A 3A 4B 5A . . . 1st letter enciphered
1 2A 3B 4B 5A . . . 2nd letter encipherment
1 2B 3A 4A 5B . . .3rd letter encipherment
As you can see some of the rotors would be switched between two
different rotors.
Would such a change offer any significant improvement in a rotor system?
(given the assumption of small to medium traffic volumes,)
Thanks for your thoughts,
Wesley Horton
------------------------------
From: CiPHER <[EMAIL PROTECTED]>
Subject: Re: Book recommendation, please
Date: Mon, 13 Nov 2000 10:57:50 GMT
In article <[EMAIL PROTECTED]>,
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> What book or books can this group recommend as
> an introduction to the science of Cryptography?
At one end of the scale I'd advise either Simon Singh's 'The Code Book'
or 'The Science of Secrecy' (Basically the same book)... at the other
end, yes 'Applied Cryptography' would be rather good.
I'd advise most people to start off on The Code Book really...
especially as it gives more of the facts behind what runs through
Cryptonomicon.
--
Marcus
---
[ www.cybergoth.cjb.net ] [ alt.gothic.cybergoth ]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: On an idea of John Savard
Date: Mon, 13 Nov 2000 13:12:47 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> On Sun, 12 Nov 2000 23:18:59 GMT, Tom St Denis <[EMAIL PROTECTED]>
> wrote, in part:
>
> >If you mean to interleave the rounds of one cipher with another I
> >strongly suggest against this. Some ciphers such as RC2 or MARS only
> >work well if used in a particular fashion because of the directed
> >avalanche affect caused by unbalanced data networks.
>
> Yes, one would have to choose the particular ciphers with care.
>
> >Generally I do not think multiple encryptions or "permutations on the
> >encryption" are good ideas. Just add more rounds or use a better
> >cipher.
>
> But this is a way of constructing a better cipher. Alternating rounds
> - actually, for a Feistel cipher, pairs of rounds, but I think my
> suggestion with respect to SAFER+ and Rijndael is perhaps what is
> being referred to - by producing a cipher with a more varied structure
> makes it harder, I would think, to find the sort of things that
> differential and linear cryptanalysis can exploit.
This construction becomes harder to analyze, not essentially harder to
attack.
Also ciphers may interact poorly together creating a weaker cipher.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: On an idea of John Savard
Date: Mon, 13 Nov 2000 13:14:32 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> John Savard wrote:
> >
> > Tom St Denis <[EMAIL PROTECTED]>wrote:
> >
> > >If you mean to interleave the rounds of one cipher with another I
> > >strongly suggest against this. Some ciphers such as RC2 or MARS
only
> > >work well if used in a particular fashion because of the directed
> > >avalanche affect caused by unbalanced data networks.
> >
> > Yes, one would have to choose the particular ciphers with care.
> >
> > >Generally I do not think multiple encryptions or "permutations on
the
> > >encryption" are good ideas. Just add more rounds or use a better
> > >cipher.
> >
> > But this is a way of constructing a better cipher. Alternating
rounds
> > - actually, for a Feistel cipher, pairs of rounds, but I think my
> > suggestion with respect to SAFER+ and Rijndael is perhaps what is
> > being referred to - by producing a cipher with a more varied
structure
> > makes it harder, I would think, to find the sort of things that
> > differential and linear cryptanalysis can exploit.
>
> As I understand, a common block cipher (there are certainly
> exotic exceptions) is 'homogeneous' in the sense that the
> rounds (cycles) are equivalent and relies on more rounds
> (cycles) to reach the desired strength with the same
> principle as multiple encryption with different ciphers.
> Thus each round (cycle) could be regarded as an individual
> cipher. From this your interleaving and my permutation
> are most easily understandable. Any influence on strenth,
> if there are any, is evidently easily compensated by
> the ensuring complexity of the resulting combined algorithm.
The problem with interleaving other block ciphers is that, while it's
true I iterate a function many times for security, I am relying on
specific constructions of the function for security. If you mix two
ciphers they may be individually secure, but as a composition their
requirements may not be compatible (re: CAST mixed with Twofish...)
Your better off using a single good design repetitively.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Eric Lee Green)
Subject: Re: so many fuss about impossibility to backtrace from MD to original text.
Reply-To: [EMAIL PROTECTED]
Date: Mon, 13 Nov 2000 13:48:37 GMT
On Mon, 13 Nov 2000 08:53:01 GMT, Paul Crowley wrote:
>Ariel Burbaickij wrote:
>> Why is it so many discussion about this point ? Surely everyone should
>> expect that let us say 4gb digested to 256 bytes or whatsoever are
>> not backtraceable.Why should one expect that is backtraceable?
>> Otherwise you have the very best compression algorithm ever suggested.
>
>A message digest function is considered broken if you can find *any*
>preimage of the hash;
The most important preimage of the hash, of course, being 16 bytes or
so immediately prior to the hash, which, in many authentication
schemes based upon a Diffie-Helman algorithm, is some sort of shared
authentication key. Mucho badness if that is compromised!
--
Eric Lee Green There is No Conspiracy
[EMAIL PROTECTED] http://www.badtux.org
------------------------------
From: "ajd" <[EMAIL PROTECTED]>
Subject: RC4 on FPGAs?
Date: Mon, 13 Nov 2000 10:26:22 -0000
Hi,
Has anyone implemented the RC4 algorithm on an FPGA (or can anyone point me
to someone who has)? What sort of throughput did you get?
thanks
ajd.
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: "Secrets and Lies" at 50% off
Date: Mon, 13 Nov 2000 14:19:49 GMT
John Savard wrote:
>
> On Mon, 13 Nov 2000 08:49:52 GMT, Paul Crowley
> <[EMAIL PROTECTED]> wrote, in part:
>
> >Does anyone know if Grady Ward ever bought him dinner? I remember a bet
> >being made over Skipjack which Sternlight won...
>
> While I have no idea about that, whatever could they have bet on?
Ward bet that Skipjack would be published within a year of Clipper being
unveiled. In fact it was more like three or four years. I'm sure that
Grady Ward would honour the bet, but I don't know if they ever got it
together.
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: Book recommendation, please
Date: Mon, 13 Nov 2000 22:24:34 +0800
Paul Crowley wrote:
>
> Eek. Don't take fear: I understand how Rijndael works pretty well, and
> I didn't tread this terrifying course. My understanding of those parts
> of mathematics that involve real numbers is pretty weak, and I don't
> think I even know what analytic geometry is.
>
Which is why I say later on that such background isn't really needed.
Read the rest of my post. I think it should be possible to create a
course and write a corresponding text in abstract algebra and algebraic
field theory that doesn't require the kind of mathematical background
dictated by the traditional modern algebra course. It's actually
frightfully simple, it just requires a sort of mathematical maturity
that you usually get only after going through these somewhat involved
courses, especially linear algebra, as it introduces vector spaces,
which are perhaps the first axiomatically-defined algebraic structure a
mathematics student encounters, and modern algebra is nothing but
mathematical structures.
The real difficulty with abstract algebra is that it's perhaps the
ultimate expression of axiomatic mathematics. The closest a high-school
age kid like the son of the originator of this thread has to it while in
hs is geometry, and that's somewhat easier than algebra, because it
deals with things that you can usually visualize and draw.
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Chimera ciphers (WAS Re: On an idea of John Savard)
Date: Mon, 13 Nov 2000 14:32:37 GMT
Tom St Denis wrote:
> > But this is a way of constructing a better cipher. Alternating rounds
> > - actually, for a Feistel cipher, pairs of rounds, but I think my
> > suggestion with respect to SAFER+ and Rijndael is perhaps what is
> > being referred to - by producing a cipher with a more varied structure
> > makes it harder, I would think, to find the sort of things that
> > differential and linear cryptanalysis can exploit.
>
> This construction becomes harder to analyze, not essentially harder to
> attack.
Tom is right. Look at the beautiful proof of resistance to differential
and linear cryptanalysis in the Rijndael paper - no such proof would be
possible with a mixed-up cipher like you propose. Look at the way the
different layers do different work, but interact to create a strong
cipher. Look at the way the structure can be re-jigged to give
decryption the same structure as encryption. I'd have far more
confidence in pure Rijndael than in any such chimera cipher.
(http://www.unifi.it/unifi/surfchem/solid/bardi/chimera/origins.html)
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: [EMAIL PROTECTED] (Eric Lee Green)
Subject: Re: Why remote electronic voting is a bad idea (was voting through pgp)
Reply-To: [EMAIL PROTECTED]
Date: Mon, 13 Nov 2000 14:35:43 GMT
On 13 Nov 2000 09:29:04 +0100, Jon Haugsand <[EMAIL PROTECTED]> wrote:
>* [EMAIL PROTECTED]
>> > 5. verifiability of software and hardware,
>>
>> Not an issue, modulo existing electronic voting systems.
>
>Well, I do not believe this is not an issue. Too much of comments like
>"this cannot happen" from people in charge of electronic voting or
>other important integrety and availability systems are seen. In fact,
Absolutely agreed. One problem with most electronic voting systems is
the complete and utter lack of a paper trail. No CPA would give a
corporate accounting system a clean bill of health if it did not
incorporate a paper trail at many important junctures, the most
important being at the point of sale. Why in the world do we account
for $$$ using a system that incorporates checks, balances, and paper
trails, but we propose accounting for votes using a system that lacks
such checks? Is it just ignorance of basic accounting principles on
the part of people proposing voting systems?
>I do not think most people who specifies and gets delivered such
>systems know anything about such issues.
That may very well be true.
>> > 7. attacks against insecure end-points (both voters' PCs, and servers),
>> > 8. there is arguably more scope for *undetectable* corruption than in
>> > a paper-based system,
>>
>> These are probably valid.
>
>Yes, and must be seen in connection with no 5.
One thing to think about: We know a hammer (cryptography), and are
attempting to use it to insert a screw. This is an application where,
in my opinion, all attempts at use of cryptography run into a brick
wall because they do not incorporate a paper trail (the most important
one being the signature book at the voting precinct, the number of
signatures in which is used as a "checksum" against the number of votes
counted).
A paper trail AND easy electronic re-processing of data could be done in this
way WITHOUT encryption, as long as we keep the requirement that people must
go to the voting precinct to vote:
1) Person votes. He gets a receipt with a randomly-generated transaction
number on it, which has a list of how he voted. That transaction is stored
into the voting machine's database. Just like the setup at the local grocery
store, except using a random transaction number (well, pseudo-random) rather
than a sequential one. The voting machine, just like those cash registers,
also has an internal paper roll recording votes and the times at which they
occurred.
2) The voting machines are told to total up votes at the end of the
day, just like the cash registers at the grocery store. These vote
totals are committed to paper and witnessed by all concerned. The
databases are then merged into the central elections office, and the
paper rolls signed by the elections observers and put into sealed bags
to be used if we ever need to audit things.
3) The central elections office puts the merged database online along with
a web front end so that anybody can look up a particular transaction number
and see how he voted. That way, people can check their receipts against what
was reported to make sure that their vote was properly recorded, and can
download the database and run their own totals process against it if they
wish to break it down by precinct, candidate, whatever. If what is generated
does not match what was totalled up at the voting machine, well, it's time
to do an audit, all the way down to the paper roll level.
Basic, fundamental accounting procedures are at work above. Anonymity is
preserved for those who want it, while accountability is preserved for
those who want a system where fraud can be easily detected. Voila!
Doesn't work for absentee ballots, alas...
--
Eric Lee Green There is No Conspiracy
[EMAIL PROTECTED] http://www.badtux.org
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Type 3 Feistel?
Date: Mon, 13 Nov 2000 14:40:34 GMT
kihdip wrote:
>
> Do you have a link for that paper ?
http://www.counterpane.com/unbalanced_feistel.html
In general, anything with Schneier as an author will be available here:
http://www.counterpane.com/publish.html
hope this helps,
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: help with website
Date: Mon, 13 Nov 2000 22:37:35 +0800
[EMAIL PROTECTED] wrote:
>
> hello,
>
> im in the process of building a website on crypto, stego, theory,
> design, attacks, current crypto laws, discussions, mathmatics, etc
> if interested please contact me at [EMAIL PROTECTED]
> thanks
>
Well, I suggest you also try to find non-US webhosting for it, lest the
odd US crypto regulations bite you. :-)
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
------------------------------
From: Panu =?iso-8859-1?Q?H=E4m=E4l=E4inen?= <[EMAIL PROTECTED]>
Subject: Re: RC4 on FPGAs?
Date: Mon, 13 Nov 2000 16:57:34 +0200
ajd wrote:
> Has anyone implemented the RC4 algorithm on an FPGA (or can anyone point me
> to someone who has)? What sort of throughput did you get?
I did. However, I don't know how good the implementation was. Throughput was
same as in software.
See paper Hämäläinen Panu, Hännikäinen Marko, Hämäläinen Timo, Saarinen Jukka,
"Hardware Implementation of the Improved WEP and RC4 Encryption Algorithms for
Wireless Terminals", The X European Signal Processing Conference
(EUSIPCO'2000), September 5 - 8, 2000, Tampere, Finland, pp. 2289-2292.
-- Panu Hämäläinen
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: Q: timing attacks on cryptographic algorithms
Date: Mon, 13 Nov 2000 22:57:16 +0800
kihdip wrote:
>
> Timing attacks uses the difference in computation time vs. the number of
> zero's and one's in the input parameters.
>
> Which is faster - zero's or one's ?? ;-)
>
> I know it'll be highly dependant on the processor and the nature of the
> algorithm, but can one in generel say that the 32-bit word of only zero's as
> an input is faster than a 32-bit word of one's ??
This is a meaningless question to ask in general! Whether zeroes or
ones are faster is depends only on the specifics of the implementation
of some algorithm, so unless you have a specific algorithm and a
specific implementation of that algorithm, your question has no meaning.
> Or is the answer that the only thing we know for certain is, that there is a
> difference ??
>
I think you've missed the most important thing about the nature of
timing attacks. Timing attacks are an implementation-specific attack on
a particular cryptographic algorithm, not a general-purpose attack like
to differential cryptanalysis. It depends not only on the cryptographic
algorithm, but also on practically all of the implementation details in
a specific incarnation of the algorithm. You can't talk about timing
attacks in the completely general sense that you seem to be trying to
take. The vulnerability exploited in a timing attack is that some
implementations of cryptosystems take different amounts of time to
operate depending on the input cryptovariables, meaning that if you can
measure the time it takes for the cryptosystem to operate given a
certain input, that will give you clues as to what the cryptovariables
happen to be. Algorithms are designed to make such vulnerabilities
easier to eliminate, meaning they have to take time that should not be
dependent on the values of the cryptovariables it uses. Implementations
of algorithms are written with this in mind.
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
------------------------------
** 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
******************************
