Cryptography-Digest Digest #612, Volume #12 Mon, 4 Sep 00 18:13:01 EDT
Contents:
Re: RSA Patent. (Runu Knips)
Re: Inquiry (Jerry Coffin)
Re: DES weak keys in 3DES ("Tor Rustad")
Re: PGP Bug: A note from Ralf Senderek (David Hopwood)
Re: Blum Blum Shub question (David Hopwood)
Re: A good MAC algorithm? (David Hopwood)
"ChronoCryption" algorithm - $50 reward for spotting a flaw (fwd) (Ray Dillinger)
Re: e-cash protocol concept, comments wanted (Julian Morrison)
security warning -- "www.etradebank.com" ([EMAIL PROTECTED])
Re: e-cash protocol concept, comments wanted (Julian Morrison)
Re: PKI & Crypto kits for palmtop computers required. (Matthias Bruestle)
----------------------------------------------------------------------------
Date: Mon, 04 Sep 2000 19:17:23 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: RSA Patent.
Rich Wales wrote:
>
> "ajd" wrote:
>
> > > Was the patent for USA only or did it include
> > > Europe?
>
> Runu Knips replied:
>
> > In Europe it has already expired. ;-)))
>
> To the best of my knowledge, the RSA algorithm was never patented in
> any country except the US.
Ooops, you're right.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Inquiry
Date: Mon, 4 Sep 2000 11:53:28 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
>
>
> Teo Li Xi wrote:
> >
> > Am trying to implement a few algorithms eg. DES/IDEA/RSA in MS
> > Visual C++ environment. I realise that there are many egs in the public
> > domain which are written in C++, but I can't find any in VC++.
>
> I know too little. But isn't it that any standard C++ program
> should run under VC++?
That's more or less the intent, though it's not the reality at the
present time. In fact, right now I'm reasonably certain there's NO
compiler that implements absolutely all of standard C++. Worse, VC++
is below average in this respect. OTOH, implementations of DES, IDEA
and RSA rarely have any use for any of the more exotic features of
C++ that are likely to be missing from any compiler either.
--
Later,
Jerry.
The Universe is a figment of its own imagination.
------------------------------
From: "Tor Rustad" <[EMAIL PROTECTED]>
Subject: Re: DES weak keys in 3DES
Date: Mon, 4 Sep 2000 22:05:21 +0200
"Gisle S�lensminde" <[EMAIL PROTECTED]> wrote in message
> In article <8ots2c$iif$[EMAIL PROTECTED]>, Scott Fluhrer wrote:
> >
> >Mark Wooding <[EMAIL PROTECTED]> wrote in message
> >news:[EMAIL PROTECTED]...
> >> Gisle S�lensminde <[EMAIL PROTECTED]> wrote:
> >>
> >> > DES have a number of weak and semi-weak keys, but in 3DES
> >> > (DES-EDE3) tree independent keys is used. How is the securiy if
> >> > one (or two) of these keys are weak. Shoud the key be avoided if
> >> > any of the DES-keys are weak, or must as least two of them be
> >> > weak before it becomes a problem.
> >>
> >> I believe that rejecting a single weak key is not beneficial. To notice
> >> the weak key being used, you'd have to successfully guess the other two
> >> keys, which is harder than attacking the full triple encryption (using,
> >> e.g., meet-in-the-middle or Lucks' probabilistic attack).
> >>
> >> I'd reject two weak keys out of three, though, if I were the sort of
> >> person who rejects weak keys.
> >
> >Actually, if you were worried about 3DES "weak keys", it'd worry first about
> >keys where either the first and second DES keys were the same, or the second
> >and third keys where the same. This has approximately as much likelihood of
> >happening by random chance as picking one of the three keys to be a DES weak
> >key, however, it reduces the cipher to DES, which would appear to be a more
> >severe weakness than using even two weak keys in 3DES...
>
> I so already check that k1 != k2 and k2 != k3, and rejects the key
> if that's the case. As you say, this reduce 3DES-EDE to DES, which
> not is desirable. By now I reject any weak or semi-weak keys
> just in case, but I couldn't find any analysis or advise on the
> area of weak keys. Do you know about information about this topic?
Why reduce the key space?
It is not clear to me how this improves the security, in fact I don't like the
idea at all.
--
Tor
------------------------------
Date: Mon, 04 Sep 2000 17:39:02 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: PGP Bug: A note from Ralf Senderek
=====BEGIN PGP SIGNED MESSAGE=====
"Bj=F6rn Persson" wrote:
> "Michel Bouissou" <[EMAIL PROTECTED]> wrote:
> =
> >I (and not Ralf) was using PGP 6.5.8 that I was evaluating, and that
> >is why Ralf's public key, which I extracted from my own public
> >keyring, shows a 6.5.8 version stamp. This comes from me, not from
> >Ralf.
> =
> Hey! What's the point in including a version note in a "public key
> block" if it doesn't tell which version of PGP created the key or which=
> version the key's owner is using?
Public key blocks may contain more than one key, so in general there is
no single "version of PGP that created the key". Also, even if there is
only one key, and even if the key's owner is currently using only one
version of PGP, there cannot be any way to tell from the public key block=
which version that is.
> Here we have yet another example of sloppy design in the user interface=
=2E
Frankly I don't see why the text version stamp is there at all; it can
be useful for developers trying to diagnose interoperability problems,
but they can decode the packets, so for that purpose it doesn't need to
be a text field.
Also note that it is not authenticated (e.g. the "Version: 2.6.3i" in the=
signature block of this post can be modified without invalidating the
signature, and similarly for the version stamp on public key blocks).
- -- =
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 0=
1
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has b=
een
seized under the Regulation of Investigatory Powers Act; see www.fipr.org=
/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i (can be modified after signing)
Charset: noconv
iQEVAwUBObPPjjkCAxeYt5gVAQEjYAf+P6rJR1aX0nqUbBLMUeY6OECaGD5hms7c
56Ehfnm0wB8oYh0Pia72cgLD9TAW2DXoo3KBUeoCdV4TwXfAANp+brrr1EHLAf6U
Jdoq+2/P2et3WtJNlz5SDaK+ozEalFlcKVrFkSHhvrW9TAuDFFSXRBE358YkYpsd
TIuiEkAT6jPwRWt2+Xj0BxopZKjIuccyXtEPtH0StS32ZEcSWYpQo5dJOifu7MVW
Su1uMCfGngeYANN0s4Nl4xrvgYzsCFOSHeFSafZ1TQW9WQUEI3yodEd0FEhUz4/i
t2LTBvl6gDIkesFOpObRZIE//OvfpDHQaqtqjKoSeXOjKex/KGV2vA=3D=3D
=3Dqzhm
=====END PGP SIGNATURE=====
------------------------------
Date: Mon, 04 Sep 2000 21:01:07 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Blum Blum Shub question
=====BEGIN PGP SIGNED MESSAGE=====
Benjamin Goldberg wrote:
> I was recently looking over how the BBS public key system works, And I
> think I might have an idea for a different way to use it.
>
> Set up your public and private keys, using all the special
> considerations for choosing your two primes.
>
> The person encrypting, chooses some X and some Y, uses X as the key to
> some secure block cipher, and sends Z=(X^2^Y mod n) (where n is the
> public BBS key), and Y. The steps of BBS decryption should be able to
> get X from Y and Z, and so we can get the key to decrypt. Y can be a
> fairly small number maybe even a constant (which would mean that it
> wouldn't need to be sent), and it would take far fewer steps to get Z
> from X than would be needed for using the BBS stream cipher to encrypt
> the entire message directly.
Y = 1 is Rabin encryption. Another slight variation of this is
Blum-Goldwasser encryption (see HAC section 8.7.2). However, both are
vulnerable to chosen ciphertext attacks. It is possible to use Rabin
with OAEP padding (see PKCS #1 v2.0), which prevents the chosen
ciphertext attack. Note that the padding can also be used to distinguish
which of the 4 possible solutions for X is correct, because there is
negligable probability that more than one solution will unpad correctly.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBObP/YzkCAxeYt5gVAQHcTwf/TDMc/PWBUey6Uv0lSx7i/rXRmsm08pL1
Pv7poKqN+kqYW4cPSu7DkVd38MFPzJl8vCwbdM0cicaqkxqBuEx9B8vNn5JoKCAW
HHwIWWiZbsEYF+zhneUw8M4fcWBjf2m3enzTgPOMqn90dDFKSKRPfdpBLsnrCSSq
6pR9C+QGeQSe24jahAktKKOZ0jAdvZHYZ3noSuLmlKbRghnA7G581CqkmjOLIIBC
2lccB73sM4A2fqVWjeS1MeHpi0uVALwgu3SrWphtRmNF0atc7KOQAQ8Tq4mAcvuW
ArHXg7byiV9tnlpFmPnh6tLrmqcOwC0ULTEGN0sgS67NOX+gozs+ZQ==
=adOU
=====END PGP SIGNATURE=====
------------------------------
Date: Mon, 04 Sep 2000 21:05:18 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: A good MAC algorithm?
=====BEGIN PGP SIGNED MESSAGE=====
"D. J. Bernstein" wrote:
[snip]
> Beware that the UMAC authors habitually quote performance results for
> 60-bit UMAC without mentioning that 60-bit UMAC is too small for
> Internet applications.
That depends on what the response to a MAC verification failure is.
If, for example, the MAC is being used to verify packets in a
communication protocol, and the response to a failure is to immediately
disconnect and display a warning to the user (i.e. the attacker only
gets one chance to forge the MAC per connection), then 60 bits is
perfectly sufficient. If the attacker can try to forge the MAC
arbitrarily many times, then it should be at least 96 bits or so.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBObQARDkCAxeYt5gVAQGi+wf+KBkjOhEznLts8ux60sV/uvCUCOlkk0vT
tGYyXdlIIZYsvXoDJEmIg+0UfOJO/wLQLc402HjC/OIqNpXANPjcxjm/27q06/hv
4zJKcv7G6U5d7aX9O4A1WJIbLijqLnTSr1Oo2CE57u6yt8u5gmA6ZqXwIn2c+6Ne
97tSvaY5Y6HT05Gv9+kto6gVVU1DUJsolw0blSovwhSHYgBB31ozuqA8F9jEI1zq
JqtMxDLVVfJEB1viwNwiBuHrExwSfJy4Y3BAPm0NyqC1QyWCj9PK6pT5NMNshKnz
vjZOAenq2jmgD5GPdLbZP3vgEeaBf0PzHD3/U2V7YrUoU5eI1qoxBg==
=d9xE
=====END PGP SIGNATURE=====
------------------------------
From: Ray Dillinger <[EMAIL PROTECTED]>
Subject: "ChronoCryption" algorithm - $50 reward for spotting a flaw (fwd)
Date: Mon, 04 Sep 2000 21:28:10 GMT
In the interest of making some news if you don't like the news
you're getting, I present -- the Country Mile Cipher. Algorithm
details available (for now) on
http://www.sonic.net/~bear/crypto/countrymile.html
This is a stream cipher based on the Blum-Blum-Shub pseuodo-
random number generator -- and on work done more recently by
Ronald Rivest, who "digitally sealed" a message that he expects
to take 30 years of continuous computing to unscramble.
The Country Mile Cipher has one interesting property; You can
choose when you encrypt a message how much computing power it
will require to decrypt it.
This interesting property has two useful applications: First,
you can make it that much more difficult to "brute-force" a
key, so even if you are restricted in key length, you can still
achieve reasonable security.
Second, you can use it to "digitally seal" messages to people
that will not unseal without a specified amount of computing
time. I can foresee protocols where someone not having information
for a specified length of time after it's delivered would be useful
- It could be treated as a "bit commitment scheme" where the person
making the commitment does not need to do anything else.
Anyway - there's very little here that's my own invention. The
Blum-Blum-Shub Random Number Generator is well-tested, and the
mathematics for predicting its state into the future are explained
in Schnier's book. I haven't really done anything except put some
well-known and well-tested pieces together, so I'm pretty confident
of the security of the Country Mile Cipher.
So confident, in fact, that if anyone can come up with a viable
attack on it, I will cheerfully pay the *first* person to do so
fifty US dollars. :-)
Ray Dillinger
------------------------------
From: Julian Morrison <[EMAIL PROTECTED]>
Crossposted-To: alt.cypherpunks,alt.cypherpunks.technical
Subject: Re: e-cash protocol concept, comments wanted
Date: Mon, 04 Sep 2000 22:58:52 +0100
Tor Rustad wrote:
> That isn't practical, since it will be very expensive, think about the expence
> at the bank host systems.
The main expense at the bank is storing a hash of unclaimed coins; frankly this
isn't much of a problem. A modern harddrive holds many gigabytes, costs about $100,
and would hold millions of pending coins.
> Banks do not give out electronic value without security. You don't describe the
> security mechanisms involved here (this is complicated in the real life).
The security status of the coins, from the bank's perspective is: "that's not our
problem". One given, they behave pretty much exactly as if they were (as described
in a previous example) bankers checks made out "pay to bearer". Who gets them, how
they're kept, who spends them, that's the customer's problem.
> > Coins are like offline cash - they're anonymous and not explicitly tied to an
> > owner, except by the way they're stored. A simple PGP'd zipfile would do as a
> > "safe", and for transport, SSH or SSL.
>
> These days its quite easy to steel such coins, and this system must be the dream
> for a trojan horse writer (with a little bit of Visual Basic training).
> Untracable and easy mony to steel.
A PGP'd zipfile or equivalent would be proof against all but he kind of
trick-you-into-giving-your-password trojans that would be just as effective against
other systems.
> SSH or SSL does not tell me much about the security, there is a (not small)
> topic on key-management.
The only keys used in the actual coins (as opposed to the Fling system intended to
transport them) are those of the bank.
> If there has been a security problem, then there is no way to track it down.
> Banks don't monitor people, but one of the basics is to be able to correct and
> adress security and other problems with transactions.
They do monitor people, and not always willingly - USA banks for example are
required to turn over information about large movements of cash to the IRS etc -
exactly the kind of goons this scheme is intended to confound. Also, the banks
still do know one thing - who took the money *out* in the first place. That still
lets them track a sneaky employee with a panchant for hacking.
> > Once the coins are in the user's hands, the bank is safe. It needn't care who
> > redeems the coins, and it actually gains (in terms of investable unclaimed
> money)
> > if the user loses it.
>
> You lost me on this.
The coins are stored as unclaimed money at the bank until used. The bank can play
the stock market with this money (as they do) and hence even if the money itself is
locked up, it's interest isn't. Plus I assume they'd "reap" coins over a certain
age as likely dead, and keep the money.
> >
> > The originator for each coin. They hold the unclaimed money, the hash of the
> coin,
> > and a transaction count - which can be used to check anonymously when someone
> > verifies the coin, or can be incremented at the request of the (anonymous) new
> > owner of that coin.
>
> If somebody has seen this coin, anybody can generate a valid hash.
But not a valid signed-by-the-bank usage count that matches the count held at the
bank.
> False merchants comes to mind, and that is a nightmare if it happends in the
> real world.
The other parts of the Fling idea whould help there, especially the idea of trust
guarantors. Basically, in a lawless market where force is impossible but theft
isn't, everyone trades on trust, and it's logically not gainful to betray for one
thing, as compared to profiting from many things.
> I don't think purse to purse transactions will survive in the future, when the
> national banks discover the risk involved, they will close it down. If one purse
> is broken, the hole system fall apart. In your model, there is no
> counter-measures for this.
If a purse is broken, its contents can be stolen. But no bad guy can forge coins -
except by setting up as a bank and issuing them himself - in which case, his coins
would not be trusted.
> No electronic payment system is totally secure, hence if there is a problem, you
> need counter-measures.
This system is proof against forgery unless the signature algorithm is cracked, but
it's not intrinsically proof against theft; the security of the user with his own
money is left to his own discretion.
> I think you simplify what you are trying to do here, I just point out the risk
> involved and that other people are doing a very good job on this.
They are doing a good, *different* job. Moving money beyond the reach of taxmen is
not a design goal for them.
> Well, I can't see how such a system can be made secure. Audit and traces are
> fundamental to security in electronic payments. Your design goals are in
> conflict with these basic security priciples. The card companies take huge
> losses on internet fraud to day, this can't simply go on and will be closed down
> with more security, not less.
They will take no loss from this system - the only people who could take a loss are
incautious customers. Take another look at the system and show me any way it could
be used to defraud a bank? I don't think there is one.
------------------------------
From: [EMAIL PROTECTED]
Subject: security warning -- "www.etradebank.com"
Date: Mon, 04 Sep 2000 21:46:49 GMT
I saw one of their commercials on TV so I checked out the site. They
only allow passwords *upto* six chars which is totally unacceptable.
Do not use their service.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Julian Morrison <[EMAIL PROTECTED]>
Crossposted-To: alt.cypherpunks,alt.cypherpunks.technical
Subject: Re: e-cash protocol concept, comments wanted
Date: Mon, 04 Sep 2000 23:04:36 +0100
Lyalc wrote:
> Hiding the money flow from the bank means they don't know to which account
> to credit the value. That's pretty dumb isn't it?
> "Hi, you don't know me, but can I have the $2000 that I have deposited in
> your bank under a no-name account?"
I see you don't grok the design of that system - the bank does know who to
credit, but only when a coin is *paid into* a bank account - and coins can be
used standalone many times in pure-cash transactions, without being paid into
any account. In pure cash transactions, what you're actually trading with is
*the potential to be paid in real money*.
> Earned trust only says something about the past. Ongoing trust means being
> able to back up any future claims with proof of correctness (or lack
> thereof)
This system can be used with audits and proofs, but it's designed to thwart
them when you want to trade or keep your property, and the law wants to stop
you or steal from you. Just like real bits-of-green-paper cash, you can track
it meticulously or pass it in brown paper envelopes.
> Auditable, higih integrity records are the only means to achieve ongoing and
> future trust in our present 'western' society.
Take a look at the system of "trust guarantors" as proposed also as part of
that Fling project.
------------------------------
From: [EMAIL PROTECTED] (Matthias Bruestle)
Subject: Re: PKI & Crypto kits for palmtop computers required.
Date: Mon, 4 Sep 2000 22:06:19 GMT
Mahlzeit
Ichinin ([EMAIL PROTECTED]) wrote:
> Looking for cryptokits (Public & ordinary) for PALMTOP computers (MS and
> Palmos)
SSLeay has been ported to PalmOS. I don't know the URL, but you
should find it locking by for "ssleay", "pgp", "palm", "pasta"
or variations of that.
Mahlzeit
endergone Zwiebeltuete
--
PGP: SIG:C379A331 ENC:F47FA83D I LOVE MY PDP-11/34A, M70 and MicroVAXII!
------------------------------
** 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
******************************
