Cryptography-Digest Digest #18, Volume #12 Tue, 13 Jun 00 09:13:01 EDT
Contents:
Re: OT: Starmath font (tomstd)
Re: Onefish (Twofishes sibbling) (tomstd)
Re: SBOX finder client (tomstd)
Re: Session key transmission (jkauffman)
Re: Finding prime numbers (Bob Silverman)
Re: encoding of passwords ("Al Grant")
Re: Finding prime numbers (tomstd)
Re: Finding prime numbers (Bob Silverman)
Re: Random sboxes... real info (Tim Tyler)
Re: Interesting Magazine Article (Mike, Copperhead) (John Savard)
Re: Random sboxes... real info (tomstd)
Re: Cipher design a fading field? (Tim Tyler)
Re: Finding prime numbers (tomstd)
Re: Session key transmission (Mark Currie)
Re: Enigma Variations (John Savard)
Re: Updated: Evidence Eliminator Dis-Information Center (Includes info on false SPAM
accusations) (Richard Herring)
Maurer & Massey's result on cascade ciphers (was: Multiple encryptions) (Nicol So)
----------------------------------------------------------------------------
Subject: Re: OT: Starmath font
From: tomstd <[EMAIL PROTECTED]>
Date: Tue, 13 Jun 2000 04:08:09 -0700
In article <[EMAIL PROTECTED]>, Runu Knips
<[EMAIL PROTECTED]> wrote:
>tomstd wrote:
>> In article <[EMAIL PROTECTED]>, Runu Knips
>> <[EMAIL PROTECTED]> wrote:
>> >tomstd wrote:
>> >> You can get the starmath True Type Font off my website at
>> >> http://tomstdenis.com/files/starmath.ttf
>> >Thank you, but my Windows says its corrupted :-(
>>
>> Hmm just pick up the ps copy of the paper then
>>
>> http://tomstdenis.com/ffunctions.ps.gz
>
>Thank you Tom, I can read you paper now without problems
>with Linux.
>
>(Paper itself looks very good)
Thanks, I can't wait to get working on it again.
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!
------------------------------
Subject: Re: Onefish (Twofishes sibbling)
From: tomstd <[EMAIL PROTECTED]>
Date: Tue, 13 Jun 2000 04:09:20 -0700
In article <[EMAIL PROTECTED]>, Runu Knips
<[EMAIL PROTECTED]> wrote:
>tomstd wrote:
>> The source is at:
>>
>> http://tomstdenis.com/tc4.c
>>
>> Have a peek, it's rather neat. I doubt it's secure so I
>> wouldn't bother analyzing it (I just made it in 30 mins).
>
>Its not portable. The values of kb[] in the key initialization
>depend upon the endianness of the current architecture.
If it's not my endianness it's wrong. That's simple :)
>I think because you don't use the pseudo hadamard
>transformation of twofish you'll run into big problems.
>However, GF things still make me running away except if they
>are female ;-)
I have no clue what you are talking about.
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!
------------------------------
Subject: Re: SBOX finder client
From: tomstd <[EMAIL PROTECTED]>
Date: Tue, 13 Jun 2000 04:10:34 -0700
In article <[EMAIL PROTECTED]>, Runu Knips
<[EMAIL PROTECTED]> wrote:
>Runu Knips wrote:
>> tomstd wrote:
>> > Sorry there is no other ports at this time (I know somebody
is
>> > gonna comment). However the FULL source code is given and
it's
>> > a very dirty hack of SBOXGEN anyways..
>>
>> See www.wxwindows.org. LGPL GUI for Windows (16 and 32 bit) +
>> Unix (GTK+ and Motif/Lesstif), other systems in development
>> (early BETA for MacOS). Currently still in BETA (if you want
to
>> use the 2.x version, which is far cooler than 1.x. 1.x is
already
>> final, frozen, done, for Windows/OS2/Unix etc.), but fairly
>> useable.
>>
>> At the moment, I've even stopped working at my cipher (whirl)
>> and started to write a little program with that lib.
FASCINATING !
>> ;-)))
>
>Ooops, forget it. Such kind of program doesn't need to be
>graphic on systems other than Windows anyway...
>
I am working on optimizing my code for the task. Last night I
brought the code from 6000sboxes/sec to 13000sboxes/sec. I just
have to check to make sure it's still doing the same test :)
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: jkauffman <[EMAIL PROTECTED]>
Subject: Re: Session key transmission
Date: Tue, 13 Jun 2000 04:00:14 -0700
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> Certainly, if the communication partners have no way of
> obtaining a shared secret key, then using public key is
> a necessity. Suppose, however, they have a secret key.
> Then
> they can use that as a master key to create the
> session key
> when it is needed through encrypting a random number
> with
> an algorithm (the same as used to encrypt the message
> proper
> or a different one) and prefix the random number to the
> ciphertext (obtained with the session key). The
> receiver first
> uses the random number to get the session key and then
> decrypts the ciphertext. In that way, the risk of the
> master
> key being compromised would be the same as that for the
> private key, I suppose. (On the other hand, I can see
> an
> essential advantage of the public key in case n
> persons need
> to communicate with one another, since only n private
> keys
> need be kept secret, while there are n(n-1) secret keys
> (n(n-1)/2 different ones) with symmetric cryptography.)
> Thanks for you help in advance.
> M. K. Shen
This is still less secure than the public/private key
solution because two parties need to hold a secret key, as
opposed to the pki solution where only one party holds its
private key. From the point of view of party A who wants to
protect their data, having to share a key with party B is a
clear risk. How can A trust B to keep the key secret in the
long term?
* Sent from AltaVista http://www.altavista.com Where you can also find related Web
Pages, Images, Audios, Videos, News, and Shopping. Smart is Beautiful
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Finding prime numbers
Date: Tue, 13 Jun 2000 11:09:44 GMT
In article <8i3v16$uo4$[EMAIL PROTECTED]>,
AllanW <[EMAIL PROTECTED]> wrote:
> Suppose I had an algorithm so that, given a prime number P(n),
> I could find the next prime number P(n+1) extremely quickly.
> Let's say it was as quick as four or five integer additions.
> (I don't actually have such an algorithm, but let's say I did.)
>
> I'm guessing that an algorithm like this would make brute-force
> attacks on private keys easier.
Why do you say this? On what basis do you make such a "guess"?
What facts do you use which lead you to this "guess"?
Given a public key it would be
> possible to derive the private key in a practical amount of
> time,
This must mean you think you have an attack. Please tell us
what it is.
Your "guess" , BTW, has nothing to do with reality.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Al Grant" <[EMAIL PROTECTED]>
Subject: Re: encoding of passwords
Date: Tue, 13 Jun 2000 12:24:03 +0100
"Mark Wooding" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> That's one of the OpenBSD team's arguments against using faster hashes.
> They use Blowfish, with a configurable number of iterations,
> specifically *because* it's slow. It makes dictionary attacks harder.
Are you aware of any quantitative data on the number
of operations (or cycles on typical CPUs) per key,
required for various hashes?
------------------------------
Subject: Re: Finding prime numbers
From: tomstd <[EMAIL PROTECTED]>
Date: Tue, 13 Jun 2000 04:22:48 -0700
In article <[EMAIL PROTECTED]
darmstadt.de>, Safuat Hamdy <[EMAIL PROTECTED]
darmstadt.de> wrote:
>tomstd <[EMAIL PROTECTED]> writes:
>
>whatever you wrote in your posting, it is wrong. If you
believe, that
>your statements are true, cite or prove.
That's rather vague isn't it. Yea, Ok I admit it I read "Primes
for dummies".
Important fact: Tom is not on the leading edge of number
theory. Tom is looking at number theory through very narrow
channel (a straw from Wendy's to be precise).
I was trying to make conversation.
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: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Finding prime numbers
Date: Tue, 13 Jun 2000 11:16:34 GMT
In article <[EMAIL PROTECTED]>,
tomstd <[EMAIL PROTECTED]> wrote:
> In article <8i3v16$uo4$[EMAIL PROTECTED]>, AllanW <allan_w@my-
> deja.com> wrote:
<snip>
> >Is that right?
>
> Yes, if you can find primes in linear time then you should be
> able to factor much quicker, espescially RSA style naturals.
>
> I don't have a proof for that, but I am just guessing it's true.
Oh?
I suggest you stop guessing and start doing some analysis.
Please explain the "reasoning" behind your guess.
>
> However, it's been proven that finding primes can't be done with
> some deterministic polynomial (I think, again I am more then
> likely wrong).
If you believe that you are wrong, then why do you post?
Your assertion is gibberish. It "isn't even wrong", because it is
a total misstatement of what is known. For it to be wrong, your
statement would have to make some sense. And it doesn't.
The term "deterministic polynomial" is pure gibberish.
>--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Random sboxes... real info
Reply-To: [EMAIL PROTECTED]
Date: Tue, 13 Jun 2000 11:12:36 GMT
tomstd <[EMAIL PROTECTED]> wrote:
: There is alot of merit in the idea of keyed substitution boxes,
: however alot of care has to go into their construction. Large
: random sboxes are rarely secure which is why they have to be
: specifically constructed. For example look at a block 64-bit
: cipher, only a handful of the 2^64! possible 64-bit
: substitutions boxes are possible, but out of all of the possible
: tables very few are weak. Try to think of the block cipher has
: a big sbox and it will help you design smaller tables.
There seems to be some irony here. AFAIK, most folks agree that a
block cypher should attempt to emulate a random permutation.
Some random permutations are weak, but the chances of any of them
coinciding with one of your keys is considered extremely remote.
So, following the advice of looking at a block cypher and thinking of it
as a large s-box (in the hope of this helping you design smaller tables)
apparently leads to the idea that smaller s-boxes should be constructed
as random permutations...
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ UART what UEAT.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Interesting Magazine Article (Mike, Copperhead)
Date: Tue, 13 Jun 2000 12:02:54 GMT
On Tue, 13 Jun 2000 02:39:22 GMT, [EMAIL PROTECTED]
(John Savard) wrote, in part:
>An "Invention and Technology" special by American Heritage magazine
>has an article on "Breaking Codes Without Computers", which talks
>about many of the special-purpose codebreaking machines used by the
>U.S. during World War II. The author has a book coming out this
>October.
It is the Summer 2000 issue of "American Heritage of Invention &
Technology"; cover story "Making Teflon Stick". The cover is generally
black in color for this issue; although the magazine is published by
American Heritage, it is a quarterly to which subscriptions are
available in its own right.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/
------------------------------
Subject: Re: Random sboxes... real info
From: tomstd <[EMAIL PROTECTED]>
Date: Tue, 13 Jun 2000 05:06:25 -0700
In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]>
wrote:
>tomstd <[EMAIL PROTECTED]> wrote:
>
>: There is alot of merit in the idea of keyed substitution
boxes,
>: however alot of care has to go into their construction. Large
>: random sboxes are rarely secure which is why they have to be
>: specifically constructed. For example look at a block 64-bit
>: cipher, only a handful of the 2^64! possible 64-bit
>: substitutions boxes are possible, but out of all of the
possible
>: tables very few are weak. Try to think of the block cipher
has
>: a big sbox and it will help you design smaller tables.
>
>There seems to be some irony here. AFAIK, most folks agree
that a
>block cypher should attempt to emulate a random permutation.
>
>Some random permutations are weak, but the chances of any of
them
>coinciding with one of your keys is considered extremely remote.
>
>So, following the advice of looking at a block cypher and
thinking of it
>as a large s-box (in the hope of this helping you design
smaller tables)
>apparently leads to the idea that smaller s-boxes should be
constructed
>as random permutations...
No you failed to see my point.
Let's take RC5 with a 128 bit key. There are about 2^128
possible permutations right?
Well those 2^128 permutations out of the entire (2^64)!
permutations are strong with respect to diff and linear
analysis. They are hardly any random permutation, the
permutations are *dictated* by the algorithm itself. Remember
that 2^128 is only a TINY fraction of (2^64)!. Even if you add
up the permutations allowed by RC5, CAST, IDEA, DES, Blowfish,
TEA and SAFER, you still only barely cover the surface of all
possible permutations.
That's why constructions like that are more favourable. We can
tell to some degree what permutations constructed using a
particular structure will behave like.
You could make a 8-bit feistel with close-to-ideal properties
and use that as a 8x8 sbox. If you know that the best fixed
difference is not probable then your sbox is secure.
* 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: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 13 Jun 2000 11:57:47 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
:> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
:> >John Savard wrote:
:> >> But some people have expressed a wish for proofs of security for
:> >> ciphers, and in my opinion, that looks like something equivalent to
:> >> solving the halting problem.
:> >
:> >Maybe an attempt to prove that equivalence would prove enlightening.
[snip John Savard on the halting problem]
:> Well, to see if such an attempt is feasible, let us review ...
:> This, however, assumes that the time a computer program that will
:> eventually halt will take to run is unbounded, thus, the term
:> "computer program" is meant in the abstract, and includes programs of
:> unbounded size, requiring unbounded amounts of memory.
: Actually the programs involved don't have to be very large.
: Chaitin has a rather small one for his specialized version of LISP.
They *have* to be potentially unboundedly large for the halting problem to
exist.
If the size of the program is constrained, a halting determination program
could be written which enumerates all programs of that size or shorter and
lists whether they halt or not.
I don't have much useful to say about whether cryptanalysis mirrors the
difficulty of the halting problem in some way - the analogy between the
two does not do much for me.
However, I don't think such an equivalence is necessary for deciding the
issue at hand.
I cannot myself envisage a proof of security for a cypher system.
This personal incredulity is by no means conclusive evidence - but
I am pretty certain that no such proof currently exists for any cypher
system, at least without making use of un-physical assumptions.
The basic problem is that it is not possible to realistically place bounds
on the capabilities of our opponents. We can be pretty sure that they
can't violate the laws of physics - but we are also pretty certain that we
do not know what the laws of physics actually are - indeed we do not even
know if your knowledge of the laws of physics is under the control of our
opponents :-(
Are we /ever/ going to be able to say that our opponents are fundamentally
incapable of performing action X. It seems unlikely.
Any proof of security is likely to rest on the assumption of the weakness
of our unknown opponents.
Assuming that your opponents have a particular weakness is unlikely to
convince the sceptic.
Another problem is that cryptography is supposed to be the art of secret
writing - a subject that soars briefly into mathematics while messages are
encrypted - but which comes firmly down onto the ground at either end
where messages are written and received.
While a mathematical proof that secrecy is preserved in transit seems at
least conceivable, this isn't of much practical use unless you can also
prevent leaks at either end of the pipe - something which seems to
be firmly outside the scope of mathematical demonstrations.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Breast is best.
------------------------------
Subject: Re: Finding prime numbers
From: tomstd <[EMAIL PROTECTED]>
Date: Tue, 13 Jun 2000 05:09:03 -0700
In article <8i556b$o83$[EMAIL PROTECTED]>, Bob Silverman <bobs@my-
deja.com> wrote:
>In article <[EMAIL PROTECTED]>,
> tomstd <[EMAIL PROTECTED]> wrote:
>> In article <8i3v16$uo4$[EMAIL PROTECTED]>, AllanW <allan_w@my-
>> deja.com> wrote:
>
><snip>
>
>> >Is that right?
>>
>> Yes, if you can find primes in linear time then you should be
>> able to factor much quicker, espescially RSA style naturals.
>>
>> I don't have a proof for that, but I am just guessing it's
true.
>
>
>Oh?
>
>I suggest you stop guessing and start doing some analysis.
>Please explain the "reasoning" behind your guess.
>
>>
>> However, it's been proven that finding primes can't be done
with
>> some deterministic polynomial (I think, again I am more then
>> likely wrong).
>
>If you believe that you are wrong, then why do you post?
>Your assertion is gibberish. It "isn't even wrong", because it
is
>a total misstatement of what is known. For it to be wrong, your
>statement would have to make some sense. And it doesn't.
>The term "deterministic polynomial" is pure gibberish.
>
>
Whoa boy, down. I have already stated my credentials in the
area (which are lame-high-school-education-no-teach-math-worth-
crap). I was just responding to insane "gibberish" with
insane "gibberish".
Ok your right I should not have posted, but what are you gonna
do about it? Start World War 3?
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!
------------------------------
Subject: Re: Session key transmission
From: [EMAIL PROTECTED] (Mark Currie)
Date: 13 Jun 2000 12:16:05 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>
>
>Mok-Kong Shen wrote:
>
>> Certainly, if the communication partners have no way of
>> obtaining a shared secret key, then using public key is
>> a necessity.
Not necessarily, to initialise either system, you need to exchange some
information securely whether it be secret keys, public keys or certificates
from a CA. In the public key case secrecy is not an issue but trust is.
>> Suppose, however, they have a secret key. Then
>> they can use that as a master key to create the session key
>> when it is needed through encrypting a random number with
>> an algorithm (the same as used to encrypt the message proper
>> or a different one) and prefix the random number to the
>> ciphertext (obtained with the session key). The receiver first
>> uses the random number to get the session key and then
>> decrypts the ciphertext. In that way, the risk of the master
>> key being compromised would be the same as that for the
>> private key, I suppose. (On the other hand, I can see an
>
>[snip]
>
>Perhaps I may ask an additional question: Is the method of
>session key transmission I described secure or are there
>vulnerabilities in comparison to the public key scheme of
>doing that? Many thanks in advance.
>
>M. K. Shen
>
It is difficult to simply say whether the symmetric key (SK) method is better
or worse than the PK method. As I am sure you will agree, it is highly
dependent on application and implementation.
The method that you describe is vulnerable to replay attacks which may or may
not be a problem depending on the application. Replay attacks however are not
restricted to symmetric key systems. In both PK and SK cases some form of
protocol must be used to protect against replay. As noted in your original
post, the more nodes, the greater the master key vulnerability and if one of
the nodes is compromised, then ALL nodes are compromised. Also, master key
compromise allows both passive and active attacks on ALL nodes, on ALL future,
present and past messages (i.e. no perfect forward secrecy PFS). A properly
designed public key system can provide PFS, prevent passive attacks in the
case of a compromised node, and limit active attacks only to the node that has
been compromised.
However, if the security of the master key can be ensured at all nodes, one
could see an SK system as being stronger in some ways, since PK systems add
other algorithms, protocols and PKI's into the pot, each of which can be
attacked.
Mark
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Enigma Variations
Date: Tue, 13 Jun 2000 12:07:47 GMT
On Thu, 08 Jun 2000 11:05:04 -0400, Paul Koning <[EMAIL PROTECTED]>
wrote, in part:
>Jim wrote:
>> Read Kahn, 'The Codebreakers' the non-abridged version if possible,
>I would put it more strongly. The paperback version is
>utterly worthless. I once made the mistake of buying it,
>and actually threw it into the trash -- which is a very
>rare event indeed for a bookworm like me.
The paperback version is abridged to about 1/3 the size of the
original book, and specifically omits what many may find to be the
most interesting, the technical side of things.
However, I would say that it is still valuable to have, particularly
for those who cannot find or afford a copy of the original book. (It
was even printed in hardcover form, with a red cover; the library at
the local University has a copy, in addition to copies of the original
at other locations.)
It does have some value; it includes some updates. For example, its
account of the capture of a German submarine by Daniel V. Gallery
specifically states that it had Enigmas on board; and at the start of
the book, it noted that the NSA requested _three_ omissions from the
original book (*one* of which appeared in "The Puzzle Palace",
presumably).
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Crossposted-To:
alt.security.pgp,comp.security.firewalls,alt.privacy.anon-server,alt.privacy
Subject: Re: Updated: Evidence Eliminator Dis-Information Center (Includes info on
false SPAM accusations)
Date: 13 Jun 2000 12:20:58 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> Let me remind you of one thing about cops. Do you know who it was who
> turned over all the Jewish children in France to the Nazis for
> extermination?
I claim Godwin's Law. You lose. Nwo go away.
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Maurer & Massey's result on cascade ciphers (was: Multiple encryptions)
Date: Tue, 13 Jun 2000 08:32:42 -0400
Reply-To: see.signature
Bryan Olson wrote:
>
> If the keys are independant, then against ciphertext-only or
> known plaintext, the composition must be at least as strong
> as the first cipher applied, but there's a theoretical
> possibility that the chain is not as strong as the second
> cipher. See:
> Ueli M. Maurer and James L. Massey. Cascade ciphers:
> The importance of being first. Journal of Cryptology,
> 6(1):55-61, 1993.
>
> Against chosen plaintext, (again assuming independent keys)
> the composition must be at least as strong as the stronger
> of the two.
I've had a problem with the result of Maurer and Massey for a long time.
Basically, I think the result is "wrong". The (counter-)example they
gave in the paper does not demonstrate the informal statement of the
result. The definition of a secure cipher implicitly used in the paper
is, in my opinion, unnatural. For a cipher to be secure, it should be
secure w.r.t. all distributions of inputs. That's not the case with the
"secure" ciphers in their example.
[I don't have the paper handy and it's been a long while since I last
look at it, so I could be missing something. Anyone interested in the
problem should read the paper to see if my objection correctly applies.]
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
------------------------------
** 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
******************************
