Cryptography-Digest Digest #112, Volume #13 Tue, 7 Nov 00 00:13:00 EST
Contents:
Re: BENNY AND THE MTB? ("Matt Timmermans")
Re: XOR Software Utility (freeware) available from Ciphile Software (Andre van
Straaten)
Re: example code for your use (Roger Schlafly)
Re: XOR Software Utility (freeware) available from Ciphile Software (Tom St Denis)
Re: Random Number Newsgroup ([EMAIL PROTECTED])
Re: Crypto Export Restrictions (CiPHER)
Re: PGP 7.0 - Key Reconstruction - White Paper now online ("Michael Young")
Re: PGP 7.0 - Key Reconstruction - White Paper now online (Imad R. Faiad)
Re: CHAP security hole question (Thomas Wu)
----------------------------------------------------------------------------
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: BENNY AND THE MTB?
Date: Tue, 07 Nov 2000 01:59:41 GMT
"Bryan Olson" <[EMAIL PROTECTED]> wrote in message
news:8u7lf4$bhn$[EMAIL PROTECTED]...
> I think the term is O.K., but each description of what
> it means should be clear about the 000... case. The
> definition in the paper is fine. I had the misfortune
> of first reading the comment in the source file
> "trivial.h", which is clearly not what you meant:
>
> [...] where a finitely odd bit stream is of infinite
> length, but the position of the rightmost 1 bit is finite,
> i.e., there is a final 1 bit somewhere in the stream, which
> is followed by an infinite number of zero bits
It says that?!?! Oh. That will be fixed in bicom 1.1, which will have a
better and faster PPM model as well.
------------------------------
From: Andre van Straaten <[EMAIL PROTECTED]>
Subject: Re: XOR Software Utility (freeware) available from Ciphile Software
Crossposted-To: talk.politics.crypto,alt.hacker,talk.politics.misc
Date: Tue, 07 Nov 2000 02:09:04 GMT
In sci.crypt Tim Tyler <[EMAIL PROTECTED]> wrote:
> In sci.crypt Andre van Straaten <[EMAIL PROTECTED]> wrote:
> : In sci.crypt Richard Heathfield <[EMAIL PROTECTED]> wrote:
> :> Anthony Stephen Szopa wrote:
> :>> http://www.ciphile.com
> :> I tried to have a look at this, but failed. No source code. Just the
> :> binary. On the system I'm using right now, I couldn't have run it even
> :> if I'd wanted to.
> :> Since it's such a simple program to write, why no source code?
> : The intended audience has only a rough understanding of what source
> : code is.
> No doubt that same audience will be advised by those who /do/ know what
> source code is not to use a system which might (for all anyone knows) take
> your precious files and email them to some unnamed third party at the
> first opportunity.
> --
> __________ http://alife.co.uk/ http://mandala.co.uk/
> |im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
Unfortunately, most of those people don't read NGs. Where do you start
campaigning?
The problem is: without knowledge and effort no self-defense.
Instead, consumer protection by law for crypto products?
-- avs
Andre van Straaten
http://www.vanstraatensoft.com
______________________________________________
flames please to [EMAIL PROTECTED]
------------------------------
Subject: Re: example code for your use
From: Roger Schlafly <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.lang.c.moderated
Date: 07 Nov 2000 02:56:53 GMT
Richard Heathfield wrote:
> No. You can print out the source code and snailmail it. Legally! Just
> don't send it on a floppy disk or CD-ROM. Those might well be illegal.
> You gotta love USA logic...
Not any more. The USA no longer has any restrictions on sending
crypto to Europe, Japan, and several other countries. I think
they wanted to make Al Gore more electable. Meanwhile, the UK
is becoming one of the most crypto-unfriendly countries in the
free world.
--
comp.lang.c.moderated - moderation address: [EMAIL PROTECTED]
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker,talk.politics.misc
Subject: Re: XOR Software Utility (freeware) available from Ciphile Software
Date: Tue, 07 Nov 2000 02:58:17 GMT
In article <[EMAIL PROTECTED]>,
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> >
> > In article <[EMAIL PROTECTED]>,
> > Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> > > XOR Software Utility (freeware) available from Ciphile Software
> > >
> > > This software simply performs the universally available logical
XOR
> > > process on two files chosen by the user and outputs the resulting
> > > file.
> > >
> > > http://www.ciphile.com
> > >
> > > goto the Downloads Currently Available web page.
> > > scroll to the bottom of the page.
> > >
> > > Click on the blue anchor tag: CiphileXOR_10.zip (155kb)
> >
> > How on earth did you make such a simple program take 155kb?
> >
> > Tom
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
> Updated XOR Software Utility (freeware) Version 1.1 from Ciphile
> Software
>
> This updated XOR software utility Version 1.1 from Ciphile Software
> now allows for the two input files AND the output file to each be
> in a different directory if the user chooses.
>
> http://www.ciphile.com
>
> go to the Downloads Currently Available web page.
> scroll to the bottom of the page.
>
> Click on the blue anchor tag: CiphileXOR_11.zip (156kb)
Why didn't you answer my question?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Random Number Newsgroup
Date: Tue, 07 Nov 2000 03:27:53 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>> Does anyone know how the new random number newsgroup is coming along? I
>> haven't heard anything since I (and other voters) were notified that the
>> vote was to establish a newsgroup dealing with random numbers.
> We have since quite a time sci.crypt.random-numbers.
It passed 134:12 on 29 March 2000, the control message was sent on 3
Apr 2000. I wouldn't feel left out if you don't get it, however, it
never showed up here, either.
You should be able to have your isp add it painlessly though, by
pointing out that it passed the vote and is in the isc active file.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: CiPHER <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech
Subject: Re: Crypto Export Restrictions
Date: Tue, 07 Nov 2000 03:21:30 GMT
In article <[EMAIL PROTECTED]>,
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> Continue to spend more of your time posting about something you
> know nothing of if it amuses you.
>
> I don't know why you are bothering, either.
Now talk about useful responses... that's really shown the weaknesses
in our arguements... phew! You're a mastermind!
--
Marcus
---
[ www.cybergoth.cjb.net ] [ alt.gothic.cybergoth ]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Michael Young" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.pgp.tech,comp.security.pgp.discuss,alt.security.pgp
Subject: Re: PGP 7.0 - Key Reconstruction - White Paper now online
Date: Mon, 6 Nov 2000 21:34:46 -0500
Imad seems to have read this as a key escrow scheme, saying:
>IMHO it is futile to devise any scheme to recover the
>key or the message. This is so because, it does not
>work in practice. More important this undermines
>a user's faith in the product.
And blanket statements like this undermine it even more.
What NAI is providing is an ENTIRELY OPTIONAL user-directed
key reconstruction service. If you don't want it, don't use it.
But don't assume that it has no value, or that it doesn't
work without checking out the details.
A summary for those who don't want to read the whole whitepaper:
The user's private key (K) is encrypted to a randomly-generated key (X).
That key is Blakely-Shamir split into 5 shares (3 required).
User chooses 5 personal questions (Q) and answers (A).
The answers are hashed to produce symmetric keys; each key
encrypts a share.
The user will get back these E[A](shares(X))+E[X](K) (call this S).
To allow a server to pre-screen requests for S, repeat:
another random key (Y) encrypts (keyID+S) and is split;
the answers are hashed differently to encrypt these shares;
the server stores Q, E'[A](shares(Y)), and E[Y](keyID+S);
the server will vend Q and E'[A](shares(Y)) to anyone;
the server vends S only if the user provides Y to decrypt
the E[Y](keyID+S) and the keyID matches;
a secure connection (or other authentication) is used to
ensure that Y is not stolen in the process.
Basically, a server-based split key store. Very similar to something
Bruce Schneier described in a Crypto-Gram a while ago. Individuals
could do roughly the same thing without a server -- I have. It
doesn't seem novel, but NAI claims to have a patent pending on some
part of it (presumably something about the server mediation).
Yes, a server could do a brute-force search for Y, and then a
brute-force search for X. And if you do a reconstruction once, then
it's down to an attack on X. A smart attack on the answers would
probably be more fruitful. If you don't like the risk, don't use it.
For many users, this looks like a fair compromise.
------------------------------
From: Imad R. Faiad <[EMAIL PROTECTED]>
Crossposted-To: comp.security.pgp.tech,comp.security.pgp.discuss,alt.security.pgp
Subject: Re: PGP 7.0 - Key Reconstruction - White Paper now online
Date: Tue, 07 Nov 2000 04:32:50 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hello Michael,
I am sorry that you misunderstood what I said.
I never said that this scheme is key escrow.
What I mean to say first of all, that any such
scheme sure undermines a users faith in the
product which support it.
The other point is that to me the key recovery
scheme seems to be more complicated than
trying to remember the lost passphrase.
For it to work, one is assuming that the user
who has say forgotten his passphrase, will
not forget the right answers to those five
questions.
In other words, one is back to square one.
So, it is like the chicken and the egg
problem.
I have read the paper, it is very interesting.
Technically, if I am deemed qualified to
comment on it, I find no flows in it.
However, most PGP users will conceive this
as key escrow. In the same manner that
ADK is termed as a backdoor in some
quarters, when this is clearly not the
case.
Best Regards
Imad R. Faiad
On Mon, 6 Nov 2000 21:34:46 -0500, in alt.security.pgp "Michael
Young" <[EMAIL PROTECTED]> wrote:
>Imad seems to have read this as a key escrow scheme, saying:
>>IMHO it is futile to devise any scheme to recover the
>>key or the message. This is so because, it does not
>>work in practice. More important this undermines
>>a user's faith in the product.
>
>And blanket statements like this undermine it even more.
>
>What NAI is providing is an ENTIRELY OPTIONAL user-directed
>key reconstruction service. If you don't want it, don't use
>it. But don't assume that it has no value, or that it doesn't
>work without checking out the details.
>
>A summary for those who don't want to read the whole
>whitepaper:
> The user's private key (K) is encrypted to a
> randomly-generated key (X).
> That key is Blakely-Shamir split into 5 shares (3
> required).
> User chooses 5 personal questions (Q) and answers (A).
> The answers are hashed to produce symmetric keys; each key
> encrypts a share.
> The user will get back these E[A](shares(X))+E[X](K) (call
> this S).
> To allow a server to pre-screen requests for S, repeat:
> another random key (Y) encrypts (keyID+S) and is split;
> the answers are hashed differently to encrypt these shares;
> the server stores Q, E'[A](shares(Y)), and E[Y](keyID+S);
> the server will vend Q and E'[A](shares(Y)) to anyone;
> the server vends S only if the user provides Y to decrypt
> the E[Y](keyID+S) and the keyID matches;
> a secure connection (or other authentication) is used to
> ensure that Y is not stolen in the process.
>
>Basically, a server-based split key store. Very similar to
>something Bruce Schneier described in a Crypto-Gram a while
>ago. Individuals could do roughly the same thing without a
>server -- I have. It doesn't seem novel, but NAI claims to
>have a patent pending on some part of it (presumably something
>about the server mediation).
>
>Yes, a server could do a brute-force search for Y, and then a
>brute-force search for X. And if you do a reconstruction
>once, then it's down to an attack on X. A smart attack on the
>answers would probably be more fruitful. If you don't like
>the risk, don't use it. For many users, this looks like a fair
>compromise.
>
>
=====BEGIN PGP SIGNATURE=====
Version: PGP 7.0
iQEVAwUBOgeE8bzDFxiDPxutAQF7Ggf+IsX4FI7BvL179/Bf5KJUmlO3vUByWpNR
EsASnsQz00RxNha4XCuXC5e4i8gDzB3FHVrrbCSAV1NS2Wok2c+wZwnEWYY1pcHS
xBozlMlj2UC/wnXms/74i41aLeHZH2OI1VZf1BS2llL4QHB37SuXFa0329f3EA/P
/SdFY4tU6ZIgp+wEudi7rN1V7S3KmyhPF5o6kZY6f8RAODv6d1/FyNZ3IZpLrZOg
QrZZR/sBD43ckVHkILqlSPnbwhPMVBKS38g6SQTT+A1xfKzsK/5VoC+r/tRC0n7t
L+crfXeQmgEDFDY7mvWr1sMRhtKkXRq0FZ1N8wl0EVJWsmCa40NjJQ==
=26tO
=====END PGP SIGNATURE=====
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: CHAP security hole question
Date: 06 Nov 2000 20:51:26 -0800
[EMAIL PROTECTED] (Vernon Schryver) writes:
>
> No, while humans can remember 1 or 2 passwords, they *cannot* remember
> the literally dozens that they must remember to operate on the Net. The
> dozens of distinct but poor passwords that we each need are much more
> difficult to remember than a single good password. Strong password
> protocols do *nothing* to solve this problem.
While it's hard to remember lots of "good" passwords, it's a lot easier
to remember different but related passwords, if the human is allowed
more freedom to choose them. For example, most people might have
difficulty remembering ten arbitrary English words, but would have
an easier time remember the names of ten US states or Presidents'
names, if *they* were allowed to pick which ones they had to
remember. Strong passwords make it more difficult to carry out
attacks against these imperfect passwords.
> Consider the passwords for your on-line medical records, on-line
> pharmacy, bank accounts, stock brokers, credit-card account, cell-phone
> account, 401K, vacation and sick pay, vacation travel agent, private
> mail or ISP account, and the other dozen outfits that you *really*
> should not trust to share passwords. You *really* don't want to use
> the same password with your on-line bank account that you use to do
> things to your MasterCard so that if a bad guy (such as a bad employee)
> gets one you're whole life is compromised.
>
> Assume that strong password protocols let you use poor passwords
> for each of those on-line accounts. How do you remember them?
> My personal experience with the dozens of passwords I've been juggling
> for decades (until recent years only computer and network server things)
> is that without writing down the dozens of individually easy to remember
> (and so bad) passwords I'm given, I'm unable to keep them straight. When
> I remember which passwords belong to a given account, I can't remember
> which is the current one.
You're right - it's difficult enough as it is to keep lots of passwords
memorized. While it's nice to be able to think about smartcards that
might help out, strong password technologies are something that can
be deployed today, and they have the nice property that their security
doesn't rely entirely on forcing users to pick harder-to-remember passwords,
the way broken protocols like CHAP do.
> >> [scheme for negotiating a strong password
>
> >How is this long, random password exchanged
> >securely? Are you assuming
> >that on-line communication to your ISP is already
> >secure?
>
> I'm assuming something obvious and simple, such as a DH exchange to get a
> secure channel, authenticated with a side channel consisting of you
> speaking on the phone to someone at the ISP. You would download a program
> (if you wish, deal with authenticating the program). The guy at the ISP
> would tell you to type a short string to the program that would let the
> program on your PC and a matching program at the ISP exclude a man in the
> middle. Then the two programs would do the usual stuff to generate a
> random key that would be jammed into the Micrsoft PPP configuration stash
> along with phone numbers, TCP windows and MRU, and other stuff.
> No human would never know the authenticating secret, just as with
> most PKI authenticating.
You've described a complicated protocol that can be easily simplified
with a strong password protocol. Hint: you can replace the long hex
checksums with an out-of-band password. More human-friendly.
> And yes, as I said before, that idea founders on the insecurity
> and unreliability of Windows.
>
>
> > ...
> >It is better to design an authentication system
> >that acknowledges
> >the limitations of human factors and takes them
> >into account, rather than one
> >that imposes significant inconvenience upon users
> >in order to achieve security.
>
> Exactly. In today's world that means acknowledging that we all must
> authenticate ourselves in literally dozens of independent contexts, and
> that means passwords kept in human memories are largely irrelevant.
Funny, I think the opposite conclusion is warranted - that forcing
harder password choices on people is a loser's game.
> Smartcards have all of those problems, but at least they have a hope
> of working. Your own assumption that people cannot handle a single
> good passphrase of a password implies that people cannot handle the
> dozens of passwords that we all must use even if those dozens of
> passwords are each 1 and 2 syllable words.
I'm not sure this matches the current understanding of human factors.
People have excellent long-term memories, but they just don't happen
to be good at memorizing arbitrary strings or bits like a computer.
> > ...
> >> In other words, the current reality of dozens of
> >passwords forces people
> >
> >Sites that force artificial "good password" rules
> >on human users do this.
> >Let's be clear on our assumptions.
>
> My assumption has nothing to do with 'forced artificial good passwords'.
> I assume that it is a Very Bad Idea(tm) to use the same password, whether
> good or not, with your banker, your employer, and your doctor. Evidently
> you assme the opposite, that it is just fine to make it possible for a
> clerk in your doctor's office to poke around your MasterCard account, or
> vice versa.
Once again, strong password technologies make these attacks difficult.
If you were talking about, say, ssh or some other disclosing authentication
method, you'd be right.
> Or for someone at the the last web-site that you used to get sports
> scores to use your single global, easy to remember password to poke
> around your medical and financial records.
>
>
>
> > ...
> >No, it's better to bet that humans won't
> >spontaneously develop better memories and
> >to design around that.
>
> We agree on that point. You also seem to assume that people can live with
> at most 3 or 4 simple passwords, since we agree that is an upper bound on
> the compliations that people can remember. That makes no sense unless
> you are student without a mortgage, two car loans, a bank account, your
> wife's bank account, at least one on-line brokerage account, 3 bank credit
> cards, a cell phone, three 401K's from previous employers, 4 doctor's
> offices (pediatrican, your own GP, your wife's GP, your wife's OBY/GYN),
> a dentist, your employer's medical insurance account, your employer's
> dental insurance account, your employer's "human resources" web pages,
> and the last 15 online newspapers and merchants you've dealt with. My
> own list of consumer passwords (i.e. not servers, routers, or otherwise
> unusual) is longer than that, although I'll admit that my medical stuff
> is not yet on the Net (as far as I know).
> --
>
>
> Vernon Schryver [EMAIL PROTECTED]
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
** 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
******************************
