Ben's blinding, plus pre-publishing

2002-06-10 Thread Jason Holt


>Maybe you could say more about the details of your credential system.
>Such a system built on Wagner blinding might be very interesting.

I've been thinking it would be nice to post my entire paper here (and
maybe on sci.crypt.research) before sending it off to the journals.  What are
the issues surrounding that, though?

The academic folks here seem uncomfortable when I talk about it, like
I'd be leaking something secret.  AFAICT, nobody else would be able to apply
for a patent on the idea without telling a lot of lies in the process.  So
that leaves the possibility that somebody whips out another paper on the topic
before mine's all the way done.  Are the journals going to be snippy about
copyright issues?  Why haven't I seen other papers published on usenet and
such before going to press?


>> If I replace h1 with (g^b0) and get the issuer to sign:
>>
>> ((g^b0)*g^b1 *h2*g^b2 *h3*g^b3...)^k
>>
>> I should be able to divide the two results and get h1^k.  But part of the
>> cut-and-choose protocol will be to require that the n/2 checked documents
>> are all valid and different from any previous instances of the protocol.  
>> So it should be extremely hard for the user to sneak lots of previously
>> used values and fake h's (which are really blinding factors) into the
>> unrevealed documents.  But are there other ways to separate out signatures
>> on individual h's?

>You're really going to remember all the discarded h values from all the
>previous instances of credential issuing?  Seems like it might be a lot of
>data.  How many h values do you typically expect?

I get around that by having the issuer issue a new random value for
each issuing session which gets hashed several times along with some other
data before going into the blinded messages.  You have to prove that the value
properly descends from the issuer's random value, which makes it tough to
reuse values from a previous session.

-J




RE: PGP and Speak Freely (fwd)

2002-06-10 Thread Trei, Peter

What these people ought to be doing is using the
PGP messages only to transmit authentication data.
eg: "When I talk today, I'm going to mention the Yankess".
That way if a criminal cracks their system and reads
plaintext copies of their email, they can't decrypt stored
traffic. What they propose destroys the Perfect
Forward Secrecy property of SF. 

SF also should display part of the parameters used to
generate the ephemeral key, allowing the users to
assure themselves that there is no Man In The Middle
attack underway.

(yes, this is obvious to most cpunk subscribers, but
apparently not to all SF users)

Peter Trei


> --
> From: Major Variola (ret)[SMTP:[EMAIL PROTECTED]]
> Sent: Saturday, June 08, 2002 10:16 AM
> To:   [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject:  RE: PGP and Speak Freely (fwd)
> 
> [stuff y'all knew but for the record]
> 
> Basically the authors of the below post find that Speak Freely's
> reliance on out-of-band symmetric key exchange is solved with PGP email.
> 
> PGPfone does this for you over the same channel --using the
> mathemiracle of public-key crypto.  Since you're both
> necessarily online, it can and does use Diffie-Hellman instead of RSA.
> It does not save the negotiated key pair so if no endpoint is taping,
> the
> conversation is lost to the wind.
> 
> Speak Freely is a nice piece of work, however compared to PGPfone
> it 1. requires OOB key exchange 2. isn't supported on Macs FWIW.
> I don't recall if SF works both ways, but PGPfone supports both IP
> and direct modem to modem links.
> 
> (Just for completeness, anyone researching the field should evaluate
> Nautilus too.)
> 
> 
> At 12:25 PM 6/8/02 +0200, Eugen Leitl wrote:
> >Date: Sat, 08 Jun 2002 03:42:12 -0500
> >From: "Benjamin T. Moore, Jr." <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> >Subject: RE: PGP and Speak Freely
> >
> >-BEGIN PGP SIGNED MESSAGE-
> >Hash: SHA1
> >
> >Ok, let me see if I can maybe clarify what the issue is... Speak Freely
> 
> >offers the ability to encrypt your voice conversations in real time. If
> you
> >have the "Crypto capable" version, when you've made a connection to
> >someone, you both can enter an agreed upon key and your conversation
> will
> >be secure from that point forward. This of course creates several
> problems.
> >If someone is listening in, monitoring your conversation/traffic or
> packet
> >sniffing, if for instance, you were to say in the conversation, lets
> use
> >the word "monkey" for an IDEA key and you both typed in the word
> "monkey,"
> >your conversation would be encrypted using "monkey" as an IDEA key. The
> 
> >problem of course is, if someone is monitoring your conversation,
> they'd of
> >heard you agree upon a key and they'd simply enter in the same key and
> >continue to monitor.
> >
> >Thus, you need a method of securely exchanging either an agreed upon
> key or
> >a generated key - Speak Freely will generate keys that you may copy and
> 
> >paste into any of the various windows for  the various encryption
> >algorithms. PGP, Pretty Good Privacy, is one damn good method of
> securely
> >exchanging those keys. You may of course e-mail the key in an encrypted
> 
> >e-mail or file to the intended recipients or you could even send the
> >encrypted file using several of the Instant Messaging Clients with a
> file
> >transfer protocol. These methods will certainly work very well.
> However,
> >take this example which happened to me just last evening. A friend and
> I
> >were needing to set up a secure conversation. After we couldn't get
> Speak
> >Freely to handle the key exchange, we decided to e-mail the key in a
> PGP
> >encrypted e-mail. Trouble was, the mail server was down on his ISP. He
> >could neither receive or send mail. If he hadn't had an auxiliary
> web-based
> >e-mail account, things might have been more complex than they were.
> >
> >If Speak Freely were functioning correctly... let me amend that, IF we
> KNEW
> >how to make Speak Freely handle the key exchange as described in the
> help
> >file... It would have been a simple matter for us to allow Speak Freely
> to
> >handle the key exchange. What is supposed to happen is... in the
> >"connection" tab, you should be able to type the key identifier for the
> 
> >person(s), Speak Freely will then launch PGP - which it does - encrypt
> the
> >generated key and transmit it to the intended recipients. This would
> >automate secure communications.




Re: Degrees of Freedom vs. Hollywood Control Freaks

2002-06-10 Thread Ken Brown

"Major Variola (ret)" wrote:

> Jeezum, how old *are* you?   We haven't called vacuum tubes 'valves' for
> some time..  

Oh yes we do!  I never call them anything but "valves".




Re: PKI: Only Mostly Dead

2002-06-10 Thread lynn . wheeler

I think there is even less "I" than most people suspect. I've recently
taken to some manual sampling of  SSL domain name server certificates ...
and finding certificates that have expired ... but being accepted by
several browsers that i've tested with (no complaints or fault
indications).

there was thread in another forum where I observed that back when
originally working on this payment/ecommerce thing for this small
client/server startup that had invented these things called SSL & HTTPS ...
my wife and I had to go around to various certificate manufactures with
regard to some due diligence activity. I think w/o exception that they all
made some comment about the "PK" being technical ... and the "I" being
service ... and providing "service" is an extremely hard thing to do (and
they hadn't anticipated how really hard it is).

some past ssl domain name certificate threads:
http://www.garlic.com/~lynn/subtopic.html#sslcerts

As i've observed previously there are a number of ways that the technical
stuff for "PK" can be done w/o it having to equate to (capital) PKI ...
some recent threads on this subject:
http://www.garlic.com/~lynn/aepay10.htm#31 some certification &
authentication landscape summary from recent threads
http://www.garlic.com/~lynn/aepay10.htm#32 some certification &
authentication landscape summary from recent threads
http://www.garlic.com/~lynn/aepay10.htm#34 some certification &
authentication landscape summary from recent threads
http://www.garlic.com/~lynn/aepay10.htm#35 some certification &
authentication landscape summary from recent threads
http://www.garlic.com/~lynn/aadsm11.htm#18 IBM alternative to PKI?
http://www.garlic.com/~lynn/aadsm11.htm#19 IBM alternative to PKI?
http://www.garlic.com/~lynn/aadsm11.htm#20 IBM alternative to PKI?
http://www.garlic.com/~lynn/aadsm11.htm#21 IBM alternative to PKI?
http://www.garlic.com/~lynn/aadsm11.htm#22 IBM alternative to PKI?
http://www.garlic.com/~lynn/aadsm11.htm#23 Proxy PKI. Was: IBM alternative
to PKI?
http://www.garlic.com/~lynn/aadsm11.htm#24 Proxy PKI. Was: IBM alternative
to PKI?
http://www.garlic.com/~lynn/aadsm11.htm#25 Proxy PKI. Was: IBM alternative
to PKI?
http://www.garlic.com/~lynn/aadsm11.htm#26 Proxy PKI
http://www.garlic.com/~lynn/aadsm11.htm#27 Proxy PKI
http://www.garlic.com/~lynn/aadsm11.htm#30 Proposal: A replacement for 3D
Secure
http://www.garlic.com/~lynn/aadsm11.htm#32 ALARMED ... Only Mostly Dead ...
RIP PKI
http://www.garlic.com/~lynn/aadsm11.htm#33 ALARMED ... Only Mostly Dead ...
RIP PKI
http://www.garlic.com/~lynn/aadsm11.htm#34 ALARMED ... Only Mostly Dead ...
RIP PKI
http://www.garlic.com/~lynn/aadsm11.htm#35 ALARMED ... Only Mostly Dead ...
RIP PKI .. addenda
http://www.garlic.com/~lynn/aadsm11.htm#36 ALARMED ... Only Mostly Dead ...
RIP PKI .. addenda II
http://www.garlic.com/~lynn/aadsm11.htm#37 ALARMED ... Only Mostly Dead ...
RIP PKI
http://www.garlic.com/~lynn/aadsm11.htm#38 ALARMED ... Only Mostly Dead ...
RIP PKI ... part II
http://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead ...
RIP PKI .. addenda
http://www.garlic.com/~lynn/aadsm11.htm#40 ALARMED ... Only Mostly Dead ...
RIP PKI ... part II
http://www.garlic.com/~lynn/aadsm11.htm#42 ALARMED ... Only Mostly Dead ...
RIP PKI ... part III



[EMAIL PROTECTED] at 6/1/2002 2:18am wrote:


>Peter Gutmann should be declared an international resource.

Thankyou Nobody.  You should have found the e-gold in your acount by now :
-).

>Only one little thing mars this picture.  PKI IS A TREMENDOUS SUCCESS
WHICH IS
>USED EVERY DAY BY MILLIONS OF PEOPLE.  Of course this is in reference to
the
>use of public key certificates to secure ecommerce web sites.  Every one
of
>those https connections is secured by an X.509 certificate infrastructure.
>That's PKI.

  "Opinion is divided on the subject" -- Captain Rum, Blackadder, "Potato".

The use with SSL is what Anne|Lynn Wheeler refer to as "certificate
manufacturing" (marvellous term).  You send the CA (and lets face it,
that's
going to be Verisign) your name and credit card number, and get back a
cert.
It's just an expensive way of doing authenticated DNS lookups with a ttl of
one
year.  Plenty of PK, precious little I.

>The truth is that we are surrounded by globally unique identifiers and we
use
>them every day.  URLs, email addresses, DNS host names, Freenet selection
>keys, ICQ numbers, MojoIDs, all of these are globally unique!
>"[EMAIL PROTECTED]" is a globally unique name; you can use that
>address from anywhere in the world and it will get to the same mailbox.

You can play with semantics here and claim the exact opposite.  All of the
cases you've cited are actually examples of global distinguisher + locally
unique name.  For example the value 1234567890 taken in isolation could be
anything from my ICQ number to my shoe size in kilo-angstroms, but if you
view
it as the pair { ,  } then it makes
sense
(disclaimer: I have no idea whether that's either a valid ICQ number or my
shoe
size