Cryptography-Digest Digest #808, Volume #12 Mon, 2 Oct 00 01:13:01 EDT
Contents:
Re: Why is TwoFish better than Blowfish? (Tom St Denis)
Re: The algorithm that can be broken by the U.S. mil and NSA/CIA/FBI wins .... check
out the developers .... they just want to violate people's freedom of speech rights
... (Terry Ritter)
Re: Question about encryption. (John Savard)
Re: Chaos theory (Terry Ritter)
Re: Slow but unbreakable? ("Paul Pires")
Re: How Colossus helped crack Hitler's codes (Helger Lipmaa)
Re: Is RC4 a serious cipher? (Guy Macon)
Signature size ([EMAIL PROTECTED])
Re: HELP ME SOLVE THIS SECRET CODE... ("Supreme Commander")
Re: Signature size (Tom St Denis)
Re: Big CRC polynomials? (David Schwartz)
Re: Adobe Acrobat -- How Secure? (Nogami)
Re: Choice of public exponent in RSA signatures (D. J. Bernstein)
Re: The algorithm that can be broken by the U.S. mil and NSA/CIA/FBI wins .... check
out the developers .... they just want to violate people's freedom of speech rights
... (John Savard)
Re: Choice of public exponent in RSA signatures (Francois Grieu)
Re: Shareware Protection Schemes ("musashi_x")
Re: Choice of public exponent in RSA signatures (Roger Schlafly)
Re: Choice of public exponent in RSA signatures (Paul Rubin)
Re: On block encrpytion processing with intermediate permutations (Bryan Olson)
Re: Deadline for AES... ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Why is TwoFish better than Blowfish?
Date: Sun, 01 Oct 2000 22:59:42 GMT
In article <[EMAIL PROTECTED]>,
Anonymous <[EMAIL PROTECTED]> wrote:
> On Thu Sep 28 12:58:17 PDT 2000 "Joseph Ashwood" <[EMAIL PROTECTED]>
wrote:
>
> ><most of excellent post snipped>
> >
> >Blowfish: should be used where speed is an issue, where the security
limits
> >must exceed 2^64, there will never be more than 2^40 unique blocks
encrypted
> >with the same key
> >
>
> Where does this 2^40 block limit for blowfish come from?
> Can you post a pointer?
Look up Serge Vaudenay's paper on "weak keys in Blowfish". In fact the
attack requires 3x2^51 plaintexts to work and is largely infeasible.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: The algorithm that can be broken by the U.S. mil and NSA/CIA/FBI wins
.... check out the developers .... they just want to violate people's freedom of
speech rights ...
Date: Sun, 01 Oct 2000 23:09:53 GMT
On Sun, 01 Oct 2000 20:36:41 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (John Savard) wrote:
>On Sun, 01 Oct 2000 15:57:55 GMT, [EMAIL PROTECTED]
>(John Savard) wrote, in part:
>
>>would presumably have disclosed (or at least hinted at) loads of
>>highly classified information, which is why a statement was issued
>>that was worded to reveal as little as possible.
>
>The specific problem that led to the excess of ambiguity is likely to
>be that it is hard to say, in the English language, that all five
>algorithms met "Type 3" requirements without also indicating whether
>or not one or more exceeded them.
How odd. The description of meeting minimum requirements is very
common in most forms of engineering.
How about: All five algorithms meet "Type 3" requirements.
Sounds easy enough to me, even in English, but maybe that was not what
was meant.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Question about encryption.
Date: Sun, 01 Oct 2000 23:02:26 GMT
On Sun, 01 Oct 2000 19:03:44 GMT, Tom St Denis <[EMAIL PROTECTED]>
wrote, in part:
>"strong encryption program called ANEC" what exactly is ANEC anyways?
A while back, there was a post which explained the "real story" behind
ANEC. Called "Official Reply to the Secret Journal" (but in all caps)
it was in talk.politics.crypto.
Apparently, this is a publicity campaign for a novel.
ANEC is a cipher algorithm that apparently includes everything but the
kitchen sink: "hieroglyphic cipher base charts" and the "clairvoyance
of recursive computational processes", whatever that might be, are
involved.
It's a pity that ANEC isn't real: I would have loved to see an
algorithm that was even more bizarre and complicated than Quadibloc
VIII MR7.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Chaos theory
Date: Sun, 01 Oct 2000 23:27:37 GMT
On Sun, 1 Oct 2000 11:23:12 -0700, in
<%gLB5.309$[EMAIL PROTECTED]>, in sci.crypt "CMan"
<[EMAIL PROTECTED]> wrote:
>[...]
>If you want to learn about Chaos and randomness, I suggest you engage in the
>fine art of precision oscillator design. You will discover something
>interesting, I assure you.
Having already designed and built such oscillators, I would like a bit
more discussion on exactly what one might "discover" from this.
What I usually "discover" from building and testing my designs is how
much reality I ignored in the design process. This is the way we
learn about reality and so produce better designs. Presumably that is
not what was meant.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Slow but unbreakable?
Date: Sun, 1 Oct 2000 16:35:52 -0700
Simon Johnson <[EMAIL PROTECTED]> wrote in message
news:8r83ug$4kc$[EMAIL PROTECTED]...
> It's reasonable to assume that for most of the security of a cipher
> comes from its s-boxes. The bigger an s-box that smaller the chance
> that a randomly s-box configuration will have bad characteristics. So
> here's what i propose (its stupdily inpracticle but should be secure.)
All ciphers aren't block ciphers. Following your example, A stream
cipher like RC4 with a two day setup routine on 1 meg state would
probably be equally unbreakable. I think that what it shows is that
we can always generate confusion faster than the ability to deal with
it.
I find it interesting for a different reason. Implicit in this is the
idea that "Perfect security" will be slow, impractical and therefore
not interesting because of the presence of "Darn secure", fast and
efficient alternatives. OTP seems to support this allegorically. But it
must be acknowledged that this is using a sample of one to predict
the future.
It is not obvious to me that a "Magic Secure cipher" will not
be devised that is fast and efficient also. Of course, Being able
to recognize it as such is a different matter.
Paul
------------------------------
From: Helger Lipmaa <[EMAIL PROTECTED]>
Subject: Re: How Colossus helped crack Hitler's codes
Date: Mon, 02 Oct 2000 05:00:26 +0300
Helger Lipmaa wrote:
> Quite interesting report at
>
>http://www.telegraph.co.uk/et?ac=003549412141223&rtmo=wAfMMQKb&atmo=gggggg3K&pg=/et/00/9/30/ncol30.html
>
I especially liked the next paragraphs:
[...]
For Colossus II, we had the resources of the country at our
disposal," said Fensom. "We were top priority. We could
demand anything and we got it."
[...]
But many stories about Colossus remain untold, said Mr
Fensom.
"Some of it is still secret."
Techniques pioneered at Bletchley could be used to crack
ciphers employed by banks and credit card companies to
protect customer data, he explained.
[...]
Scary, isn't it... If the old guy is not making it up, of course.
Helger
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Is RC4 a serious cipher?
Date: 02 Oct 2000 00:08:36 GMT
CMan wrote:
>"Guy Macon" <[EMAIL PROTECTED]> wrote in message
>news:8r3n83$[EMAIL PROTECTED]...
>>
>> Another advantage is that you can be pretty sure that your RC4
>> implementation does not have back doors or implementation errors
>> in it. If you examine the source and see nothing funny, and the
>> result properly encodes and decodes the test cases, it's hard to'
>> see where a back door could be hidden.
>
>Right, if you assume a perfectly secure computer. On almost any real world
>computer, the possibilities are limitless. Trust nothing. Even this article.
>They are all in cahoots...
Nonsense. Computer security, like cryptographic security, isn't that
hard, if you are willing to take the advice of the people who do the
real hard work and if you are willing to spend the resources to
folow that advice (which in this case includes physically securing
your computer).
Of course no security is perfect, but you could, with a bit of effort,
set up a computer in such a way as to make it far easier for your
attacker to use rubber hose key recovery than to defeat your security
system.
------------------------------
From: [EMAIL PROTECTED]
Subject: Signature size
Date: Mon, 02 Oct 2000 00:47:41 GMT
Hi all!
I am looking for a PK signature algorithm generating small yet secure
signatures. The message to be signed is very short (let's say 32 bits)
and signature size is thus important.
After reading a lot of postings/web pages I became a bit confused.
I think I know the following (correct me if I am wrong):
RSA generates signatures about as long as the key size (1024 for secure
signatures)
DSA and ECDSA like schemes generate signatures about 4 times their
brute force bit security (bit field security). DSA in particular
generates 320 bit signatures.
Now my questions:
At http://home.hetnet.nl/~ecstr/techdetails.html it is claimed that ECC
signatures are 170 bits long (comparing it to 1024 bits RSA security).
How is this achieved?
Does XTR which is claimed to generate signatures of 170 bits as well
scale down in this with less security?
How long is a signature generated with NTRU?
Thanks a lot for your help!
greetings
kryps
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Supreme Commander" <[EMAIL PROTECTED]>
Crossposted-To: rec.puzzles
Subject: Re: HELP ME SOLVE THIS SECRET CODE...
Date: Mon, 02 Oct 2000 01:11:11 GMT
"Andreas Gunnarsson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I haven't seen any answers yet so "spoiler" is after the message...
>
> (btw, are you sure that 611713 shouldn't be 6112713?)
I copied it down carefully and it reads 611713.
SC.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Signature size
Date: Mon, 02 Oct 2000 01:25:00 GMT
In article <8r8lvc$hkm$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Hi all!
>
> I am looking for a PK signature algorithm generating small yet secure
> signatures. The message to be signed is very short (let's say 32 bits)
> and signature size is thus important.
>
> After reading a lot of postings/web pages I became a bit confused.
>
> I think I know the following (correct me if I am wrong):
>
> RSA generates signatures about as long as the key size (1024 for
secure
> signatures)
>
> DSA and ECDSA like schemes generate signatures about 4 times their
> brute force bit security (bit field security). DSA in particular
> generates 320 bit signatures.
>
> Now my questions:
>
> At http://home.hetnet.nl/~ecstr/techdetails.html it is claimed that
ECC
> signatures are 170 bits long (comparing it to 1024 bits RSA security).
> How is this achieved?
>
> Does XTR which is claimed to generate signatures of 170 bits as well
> scale down in this with less security?
>
> How long is a signature generated with NTRU?
>
> Thanks a lot for your help!
>
> greetings
What is your platform? What are the exact requirements?
My suggestion is to consider ECC since 163-bit prime fields in GF(2)
appear to be secure (I would use a slightly larger field). They
essentially use the ElGamal type math if I am not mistaken.
Why would you need to sign a 32 bit value though?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Big CRC polynomials?
Date: Sun, 01 Oct 2000 19:18:24 -0700
Bryan Olson wrote:
> Too much what? At these sizes I'd expect a
> cryptographic hash to be competitive with the CRC
> in terms of speed, space, and code size. If it
> provides more security than we need, so what?
> There's no such thing as a quality over-run or
> cost deficiency.
And, on the bright size, if you use MD5 or SHA1 and you do in fact ever
get a collision, you can publish it. ;)
DS
------------------------------
From: Nogami <[EMAIL PROTECTED]>
Subject: Re: Adobe Acrobat -- How Secure?
Date: Sun, 01 Oct 2000 20:28:11 -0700
On Sun, 01 Oct 2000 22:46:01 GMT, Tom St Denis <[EMAIL PROTECTED]>
wrote:
>I was specifically hinting at the "altering" or "printing" part. I can
>alter a document you send me, I can copy/print/resend a document you
>send me. I can't fake a signature, but that wasn't my point.
There's really no way of letting someone read a document without being
able to alter or print it. If they want to do so badly enough, they
will find a way.
Acrobat is a reasonable compromise which should keep most people out
of it, but if you're going to be publishing the secret receipe for
Coke, or McDonald's "secret sauce", then you're probably safer just
not sending it at all ;P
There are programs which will brute-force Acrobat files, and you can
buy them for around $35. Depending on the length of time required, it
can take up to 2 weeks to brute-force the entire file on a single PC.
This is just opening an encrypted file to read, mind you.
There are utilities which can instantly disable the "do not print" and
"do not modify" flags once a document is open if it's not encrypted.
N.
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Subject: Re: Choice of public exponent in RSA signatures
Date: 2 Oct 2000 03:29:54 GMT
Exponent 3, used properly, is fine for both encryption and signatures.
Exponent 2 is even better. Exponent 65537 is a horrible waste of time;
random exponents---the original RSA proposal---are even worse.
---Dan
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: The algorithm that can be broken by the U.S. mil and NSA/CIA/FBI wins
.... check out the developers .... they just want to violate people's freedom of
speech rights ...
Date: Mon, 02 Oct 2000 03:33:06 GMT
On Sun, 01 Oct 2000 23:09:53 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
>How odd. The description of meeting minimum requirements is very
>common in most forms of engineering.
>How about: All five algorithms meet "Type 3" requirements.
>Sounds easy enough to me, even in English, but maybe that was not what
>was meant.
Yes, but some people could interpret that sentence to mean that no
algorithm *exceeds* Type 3 requirements.
The alternative: 'All five algorithms meet or exceed "Type 3"
requirements' could be interpreted to mean that at least one algorithm
exceeds the Type 3 requirements.
Thus, they groped for a phrasing which was _completely_ neutral on
this subject. And they got one which was even more neutral than they
bargained for.
I suspect, though, that their first draft looked more like this:
"Each one of the five finalist algorithms in the AES process has been
determined to provide security adequate for the purpose of protecting
sensitive but unclassified data for agencies of the U.S. Government."
Which actually is *not* too bad on that particular issue; but had they
tried to use the word 'equivalent' instead of 'adequate' or
'sufficient', they would have run into trouble.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Choice of public exponent in RSA signatures
Date: Mon, 02 Oct 2000 06:09:21 +0200
D. J. Bernstein <[EMAIL PROTECTED]> wrote:
> Exponent 3, used properly, is fine for both encryption and
> signatures.
That my view, too. The operative word is properly.
> Exponent 2 is even better.
That's my view too in theory, but in practice I hesitate to recommend
Rabbin signatures, because if things go wrong with the padding, they
tend to go wrong so badly that the factorization of the public key is
revealed. This occurs in the attack of ref[3], as well as my attack
against ISO 9796-1 [proceedings of Eurocrypt 2000, or just ask].
Also, the Jacobi symbol is hard to grasp by the implementor of the
signature application, and the marketing guys like the sound of RSA.
> Exponent 65537 is a horrible waste of time.
I'm trying to understand why so many professionals swear by it !
Francois Grieu
[3] Jean-Sebastien Coron, David Naccache, Julien P. Stern:
On the Security of RSA Padding, Advances in Cryptology
CRYPTO '99; for sale at
<http://www.springer.de/cgi-bin/search_book.pl?isbn=3-540-66347-9>
------------------------------
From: "musashi_x" <m u s a s h i _ [EMAIL PROTECTED]>
Subject: Re: Shareware Protection Schemes
Date: Mon, 2 Oct 2000 00:16:03 -0400
>
> Ask yourself a few questions:
>
> - Who is the "protection" targeted at? The honest people or do
> you seriously belive that copy protection will work against
> everyone?
I would be trying to prevent crackers/keygens from coming out. I know that
Deerfield had pretty successfully used RSA for their key scheme.
> - What would stop a cracker from killing your key validation
> code in the software?
Hash of the exe and dll's. Compressing the .exe to make reverse engineering
a good bit harder.
> - HOW will you validate the purchaser?
Suggestions needed....like i stated, this is my first time dealing with this
situation.
> - What would stop anyone from distributing the software WITH
> a (stolen or compromised) legitemate key?
THAT I haven't got worked out yet. Mostly what i'm concerned about right
now is preventing serial number posting or the creation of key generators.
Hoping for suggestions on this one.
>
> Just my 0.02 strips of latinum,
>
> Glenn
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: Choice of public exponent in RSA signatures
Date: Sun, 01 Oct 2000 21:44:37 -0700
Francois Grieu wrote:
> ? Exponent 65537 is a horrible waste of time.
> I'm trying to understand why so many professionals swear by it !
A lot of crypto is based on superstitition. For several years
it has been agreed that 3-prime RSA is superior to 2-prime RSA,
but no one uses it.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Choice of public exponent in RSA signatures
Date: 01 Oct 2000 21:51:48 -0700
Roger Schlafly <[EMAIL PROTECTED]> writes:
> A lot of crypto is based on superstitition. For several years
> it has been agreed that 3-prime RSA is superior to 2-prime RSA,
> but no one uses it.
Agreed by who?!!
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: On block encrpytion processing with intermediate permutations
Date: Mon, 02 Oct 2000 04:50:57 GMT
Mok-Kong Shen wrote:
> Bryan Olson wrote:
> >
> [snip]
> > I assumed the attacker could get the same permutation in
> > different messages. Your only specific suggestion of how
> > the PRNG is seeded divided the message in half and used each
> > half to determine the permutation for the other, which is
> > obviously repeatable in a chosen plaintext attack. If the
> > attacker cannot re-start the PRNG, then choosing all blocks
> > of x the same, except the block that differs from x', looks
> > like a promising tactic.
>
> In my original post, I first said of using a PRNG,
> which I intend not to reseed (see answer to Tom St. Denis),
> i.e. the permutations are different for different messages.
I see nothing about how the sender and receiver syncronize,
only that the key for the permutation should be independent
of the key to the block cipher.
Given a non-restartable PRNG, keeping all the blocks
constant looks promising.
[...]
> I doubt that the answer is yet very
> clear to me owing to the not too small volume of texts of
> debate involved in a number of follow-ups:
So you've noticed that a large volume of texts devoid
of any actual result is counter-productive have you?
> In your opinion
> does my introduction of the permutation steps diminish or
> enhance the security, i.e. whether the additional
> computational cost involved has caused a negative or
> positive effect? Thanks.
Hard to sell exposing the key as a good thing.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Deadline for AES...
Date: Mon, 02 Oct 2000 04:54:36 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> If I were NIST, I'd be strongly tempted to go with something such as a
> block cipher that consisted of four rounds of RC6, alternating with
> two rounds of DFC, and so on: 42424 would total to sixteen rounds. Or
> even a combination of FROG and LOKI-97!
As long as there is no way to measure the strength of a cipher it will
be a good idea to cascade two ciphers (using different keys),
especially when they have very different designs. By the way, for the
same reason it may be a good idea to create digital signatures or
session keys in parallel.
I have a feeling that NIST will choose only one winner. I suppose they
could define one winner as the concatenation of two candidate
algorithms, but I am sure this will not happen.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
