Cryptography-Digest Digest #670, Volume #10 Fri, 3 Dec 99 00:13:01 EST
Contents:
Re: Any negative comments about Peekboo free win95/98 message encryptor (Tom McCune)
Re: Encrypting short blocks ("Dan Schwartz")
Re: What part of 'You need the key to know' don't you people get? (Johnny Bravo)
Re: Quantum Computers and PGP et al. (Johnny Bravo)
Re: NSA should do a cryptoanalysis of AES (Johnny Bravo)
Re: The $10,000.00 contesta (Johnny Bravo)
Re: Any negative comments about Peekboo >> how to confirm designer
([EMAIL PROTECTED])
Re: Any negative comments about Peekboo >> How to verify that promised
([EMAIL PROTECTED])
Re: NSA should do a cryptoanalysis of AES (SCOTT19U.ZIP_GUY)
repeated DH over MOD P (jerome)
Re: NP-hard Problems (Bill Unruh)
Re: Elliptic Curve Public-Key Cryptography (Paul Rubin)
Re: Why Aren't Virtual Dice Adequate? ("r.e.s.")
----------------------------------------------------------------------------
Crossposted-To: alt.security.pgp
From: Tom McCune <[EMAIL PROTECTED]>
Subject: Re: Any negative comments about Peekboo free win95/98 message encryptor
Date: Fri, 03 Dec 1999 01:09:42 GMT
In article <8274av$hn0$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Keith A
Monahan) wrote:
>I trust it's security enough to send a message across irc, but I wouldn't
>choose to use it to say, encrypt my credit card to another person.
This thread has gained enough of my interest to download it, and I'm
generating a key right now - actually it didn't take very long and I have
already made another one so I can use the program with myself. I am a little
puzzled with the above level of trust - since I often hand my credit card over
to all kinds of strangers (for purchases), I personally consider credit card
info encryption to require very little confidence.
-Tom
I use PGP for Privacy and Authenticity:
http://www.Tom.McCune.net/PGP.htm
------------------------------
From: "Dan Schwartz" <[EMAIL PROTECTED]>
Subject: Re: Encrypting short blocks
Date: Thu, 2 Dec 1999 20:36:03 -0500
Markus Peuhkuri wrote in message ...
> What I want is following property: given message M1 (length N
> bits) produces same encrypted message E1 (length N bits) every
> time run. Message M2 produces message E2, which is different
> from E1 iff message M2 is different from M1. However, I'm
> willing to accept some probability of collisions, less than
> 1/1000 (different messages M1 and M2 produce same result E1).
It sounds like you don't need to decrypt the messages, i.e. derive M1 from
E1. If that's the case, just pad each message to a standard block length
(e.g. 64 bits), use any encryption algorithm, and take N bits of the result.
Any good encryption algorithm should produce results that "look" random,
making the likelihood of a collision between any two messages roughly 1 in
2^N.
If you want a very simple algorithm, and don't require super strong
security, check out TEA.
Dan Schwartz
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Thu, 02 Dec 1999 20:43:21 GMT
On Thu, 02 Dec 1999 11:36:08 -0600, [EMAIL PROTECTED] (wtshaw) wrote:
>There are so many cases of everybody being wrong when someone else is
>right. You honestly cannot reject a single detractor on sight. I assure
>you that I want to see evidence of his claims if possible, or define them
>at least worth more study.
If they have a claim and offer evidence to support this claim, then
we can define the claim as worth more study.
Making a claim and offering no proof other than the assertion "I'm
right, and you are wrong." is not worth further study. This is
because even if you prove that one claim wrong, they will just throw
out more claims. It is easier to make claims that to support or
disprove them, why should the community be tasked with debunking every
crackpot theory that anyone could ever come up with. If you want
people to consider your claims, you need evidence that your claim is
valid.
>The last thing I am going to do is reject
>claims if there is reason to believe that they might be true.
Really? I claim you are a murderer. Given that the other people on
this group don't personally know either of us (and have no idea if I
know you personally or not), there is a reason to believe that it
might be true. So now you should prove to the group that you are NOT
a murderer.
>Being open
>to such things may seem a burden, but it is a requirement nonetheless.
There is no requirement that we should accept spurious claims
without evidence. Logic suggests otherwise.
>Personaly, I have a few rather unpopular ideas myself, backed up by my
>experience; if they prove accurate according to additional data, mine or
>others, I surely will mention them again.
This is where you diverge from the topic of discussion. You are
willing to test your ideas according to existing data. Only when you
are sure that your ideas have merit would you mention them here.
Would you expect due consideration of your idea if you had no data
to back it up other than hurling insults at anyone who asked you to
supply proof?
>When working on the idea of
>strength, a don't-touch subject in the minds of many, surely there are
>lots of Pandora's boxes to be appraised; fear of what I will find is not
>my guide, just see what is there.
Lack of proof of strength is not the same as proof of weakness. The
reason we avoid this subject is that it is nearly impossible to give a
mathematical proof that any given cipher is strong. We cannot use
this fact as a claim that any given cipher is weak because we can't
prove it is strong. If someone claims that a weakness exists, that
someone has to demonstrate evidence of that weakness.
Johnny Bravo
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Crossposted-To: talk.politics.crypto,talk.politics.misc
Subject: Re: Quantum Computers and PGP et al.
Date: Thu, 02 Dec 1999 20:44:53 GMT
On Thu, 02 Dec 1999 18:35:10 GMT, amadeus @DELETE_THIS.netcomuk.co.uk
(Jim Dunnett) wrote:
>>In any event, there's no public key crypto system in existence
>>today that will be useful when quantum computers work.
>>
>Not even OTP?
A OTP is not a public key cryptosystem.
Best Wishes,
Johnny Bravo
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Thu, 02 Dec 1999 20:48:19 GMT
On Thu, 02 Dec 1999 11:54:43 -0600, [EMAIL PROTECTED] (wtshaw) wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Johnny
>Bravo) wrote:
>
>> If they really care they have plenty of other means to get your key.
>> After all, how many of us are using TEMPST shielded computer equipment
>> at home, regularly inspect both hardware and software for tampering,
>> and sweep the room with the computer in it for monitoring devices.
>>
>Look at the activities of high-tech thieves. If security is so important,
>then the ability of government to use obscure methods should be a warning
>that dedicated others could do the same things. As always, identifying
>the easy mark is the best preliminary step for a criminal to take before
>the crime. Most users are not worthy targets, but who is to tell that
>they might not be scammed or skimmed by specialists.
This was my point, with all these other easier ways to get your
information, the NSA would not be willing to risk the destruction of
the US economy by letting the banking system use a known weak cipher
just so the can read your email.
Best Wishes,
Johnny Bravo
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: The $10,000.00 contesta
Date: Thu, 02 Dec 1999 21:07:25 GMT
On Thu, 02 Dec 1999 15:51:42 GMT, [EMAIL PROTECTED] (Bruce
Schneier) wrote:
>I think that almost all algorithm designers would be happy to see a
>new attack on their algorithms. New attacks means that we're learning
>something.
I'd imagine that it would be a bit tempered by the disappointment at
being knocked out of the AES competition. As much as our love of
knowledge is, you guys have a right to feel proud of your creations.
The represent very large quantities of work and creative effort.
Seeing one of them knocked out of the running couldn't feel good,
though I suppose it would feel much worse if it was accepted and it
was broken after everyone was using it. :)
Best Wishes and Good Luck,
Johnny Bravo
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp
Subject: Re: Any negative comments about Peekboo >> how to confirm designer
Date: Thu, 02 Dec 1999 21:36:41 -0500
Keith A Monahan wrote:
> Well I can't answer all the questions but...
> 1. possible back-door entry questions is answered easy enough.
>
I do not have any way to link source with executable >> none is SIGNED by
developer.
>From the above, examined source could be completely different as executable.
>From other point of view, Peekboo is extremely small & 1 file only !!! >> which
is very promising for robustness & security. What do you think ?
By testing only executable, how to confirm designer claims ?
--
Thanks, Richard
=======================================================
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp
Subject: Re: Any negative comments about Peekboo >> How to verify that promised
Date: Thu, 02 Dec 1999 21:46:15 -0500
Steve K wrote:
> On Thu, 02 Dec 1999 12:09:41 -0500, [EMAIL PROTECTED] wrote:
> >Any / negative comments / evaluations / possible back-door entry / stableness /
> .......................
> I have been playing with Peekboo for a couple of weeks, and at least
> it is bug free as far as a user can tell. Key and shared secret
> generation, as well as text and file encryption, work without a hitch.
.......................>
> It is too soon to grant Peekboo a "highly trusted" status, because it
> has yet to be reviewed by recognized authorities on crypto software.
> However, I expect it to pass with flying colors, because it uses only
> previously published cipher and PRNG algorithms, that are considered
> quite strong.
How to verify that promised algorithms are included when no link between source
& executable can be establish ?
The claimed algorithms are stronger than one's from PGP ?? >> for example
Blowfish.
--
Thanks, Richard
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Fri, 03 Dec 1999 04:00:44 GMT
In article <[EMAIL PROTECTED]>, "Brian Gladman"
<[EMAIL PROTECTED]> wrote:
>
>Jim Gillogly <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> Keith A Monahan wrote:
>> > My concern is that if they DID break one of the algorithms and
>> > didn't tell us(or NIST) about it. I don't know how likely that
>> > is, but it is certainly a possible case.
>> >
>> > It wouldn't be _as_ bad as if the NSA broke it, told us about it,
>> > but didn't tell us how. That would still keep me wondering, but
>> > at least we'd know the cipher isn't secure. Even without telling
>> > us how they did it, we might be able to draw some conclusions about
>> > ciphers of that same nature.
>>
>> If they say they broke it and demonstrate that they can break an
>> arbitrary challenge, then I agree that's useful information. If
>> they say they have an attack that reduces a 128-bit keyspace to
>> a 70-bit keyspace, I'd want to see the attack before making a
>> decision to eliminate the candidate. Sorry if this appears paranoid,
>> but we must always remember that NSA has two responsibilities: to
>> read traffic, and to protect US infrastructure (mainly military).
>> If you're going to accept their help uncritically, you'd better
>> know which side of the house is giving it to you. There's no
>> question that they could provide valuable insight on the candidates;
>> the only question is how they can convey it credibly.
>
>As others have said, those that distrust NSA are not going to be swayed by
>their arguments but for those of us who believe that they are a force for
>good in respect of the strength of cryptographic algorithms would consider
>what they have to say very seriously. I also believe that they should say
>something and I don't see much reason why they should not do so this time
>round.
>
>In retrospect, all the ***covert*** actions that NSA took on DES improved
>the algorithm and it is not obvious why they would behave differently now.
>The US is the most advanced 'information economy' in the world and this
>means that the US has more to loose than anyone if AES turns out to be weak.
>And this also allows those of us outside the US to trust AES since we are in
>a sort of 'Mutually Assured Destruction (MAD) situation' where any NSA
>action to bring us down would bring the US down as well.
>
>NSA did reduce the key length of DES from 64 to 56 bits and many thought
>that this was so that they could break it but I very much doubt this. Given
>the technology available at the time, and their 'volume' cracking needs, I
>cannot see that this conclusion stands up under retrospective scrutiny.
This is one fact where your wrong the design of MECL logic boards
was will known at that time. It would be foolish to think they did not build
hardware to conviently break the 56 bit keys.
>
>Although I do not know the answer here, I suspect what it might be. My
>guess is that NSA were breaking much poorer algorithms than DES at the time
>and desperately needed a way of convincing their targets not to move to DES.
>The key length reduction, leaving people to draw the (wrong) conclusions,
>was a masterful bit of psychological warfare that did exactly this.
You have got to be joking. Who would belive such nonsense.
>
>As a result of this brilliant deception I suspect that NSA targets went on
>using broken algorithms for years even though a great algorithm - DES - was
>right in front of their very eyes. And the fact that DES was strong and yet
>seemed to outsiders to be weak provided a rare occasion in which the good
>guys were able to 'have their cake and eat it' by being able to use DES for
>true protection while ensuring that the bad guys were far too suspicious of
>it to ever contemplate its use.
You are not even close to reality.
>
>And another crucial aspect of keeping DES away from the 'bad guys' was that
>of never being seen to use it for anything 'serious' even though it was
>perfectly capable of meeting such needs (i.e. steps to avoid a MAD inference
>by their targets).
>
>I can only congratulate those who developed and implemented this plan
>(assuming that I am right). To do this, to succeed, and yet not to be able
>to tell anyone about it must be a truly terrible fate!
I would tell you that you are full of shit but then you probably
already know that.
>
>But this is all in the past and circumstances now require a different
>approach. Anyone who thinks that NSA will get at information in future by
>breaking such algorithms (rather than their implementations) has not
>understood the closing of the cryptographic knowledge gap between the open
>and closed worlds.
And I suspose you think you do know.
>
>The sad fact is that computer security is many orders of magnitude less
>effective than algorithmic security and this will increasingly mean that
>there is little point in climbing almost infinitely high walls when there
>are plenty of gaping holes to exploit (i.e. I agree with Bruce Schneier's
>previous comments here).
>
> Brian Gladman
I sure that the NSA is laughing out loud about your rediculous statements.
You have made them Glad Man.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: repeated DH over MOD P
Reply-To: [EMAIL PROTECTED]
Date: Fri, 03 Dec 1999 03:34:06 GMT
hello,
i want to do diffie-hellman over MOD P (p a prime of 2^512 bits).
so 2 calculations: g^x mod p and then (g^x)^y mod p
In my case, g is always 2 and p is predefined and look like
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
but for a fixed g and p, several calculations are done with multiples
random (x,y). How can i take advantage of there caracteristics to
speed up the calculations ?
1. the low generator
2. the 0xFFFFFFFF at the begining/end of P
3. several calculations with the same (g,p)
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: NP-hard Problems
Date: 3 Dec 1999 03:59:46 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (James Pate Williams,
Jr.) writes:
>What are some problems that are NP-hard but not NP-complete? I know
Well, it is not known if there are any NP hard problems. But assuming
that say factoring is NP hard, I believe it is not NP complete.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Elliptic Curve Public-Key Cryptography
Date: 3 Dec 1999 04:16:53 GMT
Michael Scott <[EMAIL PROTECTED]> wrote:
>
>DJohn37050 <[EMAIL PROTECTED]> wrote in message
>> I said I had seen a performance sheet at least a year ago where ECC
>>163-bit was more like the performance of 17 bit exponent RSA 1024 bit
>>key. (ballpark). I know this info was presented at a PKS conference a
>>few years back.
>
>This rather surprising claim is made in
>
>http://www.certicom.com/ecc/wecc4.htm
Thanks. I looked at that page and it says BSAFE 3.0 took 12.7 msec to
do a 1024 bit RSA verification, and that Certicom's two ECC methods in
Security Builder 1.2 took 9.9 and 10.7 msec respectively, both on a
167 MHz Ultrasparc.
I don't have a 167 mhz Ultrasparc available but have been doing some
timings on a 300 mhz unit (Sparc Ultra 5) so have some scaled figures.
It makes me think the BSAFE 3.0 numbers are way slower than what can
be done on that Ultrasparc. I've been told that BSAFE 3.0 is a
portable C implemetation without any assembler speedups. I believe
RSA has something better by now.
Meanwhile, the web page says the ECC implementation uses "performance
enhancing techniques" which I'm guessing means using precomputed
powers of the generator (as is commonly done for El-Gamal) burning a
lot more storage space.
With the OpenSSL library as distributed (www.openssl.org), on the Ultra 5,
I get 411 verifications/sec with the built-in benchmark
("openssl speed rsa1024"). Scaling by a factor of 2 for the 166 mhz
processor that would be about 5 msec/verification, better than twice as
fast as either BSAFE 3.0 or the Security Builder ECC implementation.
It doesn't stop there. Although it's written in assembler, OpenSSL's
RSA implementation on the Ultrasparc isn't very good either. The
reason is that the Ultrasparc has a slow integer multiply instruction
(similar to the original Pentium), and OpenSSL's implementation
depends on it. OpenSSL on the 300 Mhz Ultrasparc is almost twice as
slow as OpenSSL on a 300 mhz Pentium II (which has fast integer
multiplication). The fastest way to do RSA on the Ultrasparc is to
use floating point arithmetic, similar to how MIRACL does it on the
Pentium. I've heard that this produces about a 3x speedup compared to
what OpenSSL comes with. I don't have a floating point Ultrasparc
implementation to play with right now, but am trying to get one. That
should bring the verification speed to under 2 msec.
Finally, the Security Builder benchmark appears to have been done with
a Koblitz curve, according to some email I've received. (I don't know
if this is the ANSI X9 curve that Don mentioned). My correspondent
says produces a 4x speedup over a randomly chosen curve. (Me, I know
close to squat about the math of ECC, but I'm really a lot happier
doing things in characteristic p than characteristic 2).
Conclusion: I believe at this point that the claim that 163-bit ECC
signature verification speed is comparable to 1024 bit RSA, at least
compared to a good implementation on the Ultrasparc, is thoroughly
bogus. Bruce's estimate that it's comparable in speed to 1024 bit RSA
with 64-bit random e sounds a lot closer to reality. I don't hold the
confusion against Don, since as he says, speed measurements aren't his
specialty; but some of us out here need to deal with real
implementations, and we do worry about such things and like to have
accurate numbers.
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Date: Thu, 2 Dec 1999 20:30:42 -0800
"Trevor Jackson, III" <[EMAIL PROTECTED]> wrote ...
: Mickey McInnis wrote:
: > "r.e.s." <[EMAIL PROTECTED]> writes:
[...]
: > |> In practice, though, who would use a "pure OTP" without
: > |> further strengthening? (Even if the OTP is theoretically
: > |> "unbreakable", it seems appropriate to say that any
: > |> OTP *implementation* can, in practice, be relatively
: > |> strong or weak.)
: > |>
: > |> (I notice that
: > |> http://www.io.com/~ritter/GLOSSARY.HTM#MessageKey
: > |> explains how the use of message keys can thwart
: > |> exactly the type of scenario envisioned above.)
: > |>
: > |> --
: > |> r.e.s.
: > |> [EMAIL PROTECTED]
: > |>
: >
: > This is a well known and much discussed "weakness" of a one-time-pad.
: >
: > A properly used OTP "absolutely" prevents the enemy from determining
: > the cleartext from the cyphertext by cryptographic means. It doesn't
: > "absolutely" prevent him from sending a false message that looks
: > real.
: >
: > It can also happen if the enemy can somehow "guess" the cleartext, even
: > if it's only sent to one correspondent. If the enemy thinks he might
: > know the text, he could try to substitute text this way and would
: > send a "proper" message if he guessed right. If he gets it wrong,
: > the correspondent would get garbage.
: >
: > There is another well-known cryptographic "weakness" in OTP and many
: > other cryptosystems. Unless you pad the messages, the enemy knows the
: > length of the message.
: >
: > I wonder if there's something analagous to an OTP that will provide
: > the same degree of "absolute" protection from "spoofing" as OTP
: > does from "breaking".
:
: A simple mechanism is to use a shared secret. Assume that in addition
: to the (large) message key repository each pair of correspondents is
: given a unique "signature" value. For purposes of illustration this
: could be small; 64-256 bits. To send an authenic message one appeads
: the "signature" to the message, encoding it with the keypad. On
: receipt of a message the decoder unmasks the "signature" region and
: compares the result with the secret value. Since the premise of the
: "signature" is that only the sender and receiver known the valid
: signature value, and because the signature ciphertext is not reused,
: the message must have come from one of the two inposession of the
: secret "signature" value. This approach does not prevent replay attacks.
In addition to its other functions, doesn't a message key (as defined
above) accomplish the same thing as the type of "signature" you describe?
(It is, after all, a kind of "shared secret", being sent along with the
enciphered message.)
The message key is created by the sender to be random and unique to each
transmission, is accessible only to possessors of the primary key, is
necessary if the decipherment is not to produce garbage, and strengthens
any stream cipher -- including an OTP -- by helping to ensure that keys
are really used only once.
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
** 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
******************************
