Cryptography-Digest Digest #202, Volume #13 Wed, 22 Nov 00 02:13:01 EST
Contents:
Re: Legal issues for hobbiests (Bill Unruh)
Re: Entropy paradox (Bill Unruh)
Re: My new book "Exploring RANDOMNESS" ("ralphv")
Re: "unsecure data structures" ? ("Rainer Nausedat")
Re: A Simple Voting Procedure (David A Molnar)
Re: A Simple Voting Procedure (David Wagner)
---- How can I get a copy of the latest Yarrow? (Greggy)
Re: A Simple Voting Procedure (David Schwartz)
How to find celebrity ([EMAIL PROTECTED])
Re: vote buying... (nemo outis)
SET Protocol -- Question ([EMAIL PROTECTED])
SET; was Re: Why trust root CAs ? ("David Thompson")
Re: Cryptogram Newsletter is off the wall? (Mark Currie)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Legal issues for hobbiests
Date: 21 Nov 2000 22:24:40 GMT
In <[EMAIL PROTECTED]> Steve Portly <[EMAIL PROTECTED]> writes:
>What are the legal issues if an amateur crypto hobbyist in the USA
>creates an encryption program that falls outside of the guidelines for
>accepted key spaces? Certainly the program could not be sold
>commercially. I also read somewhere that if the program is posted on
>the internet in a useable form, NIST would need to be notified. Is
>there any legal reason why the program could not be shared amongst
>friends within the USA via private Email?
The rules have changed in the past year. If the program is "public
domain" then there are essentially no rules, no matter what the key
space. If it is a binary only program then you still need a license. But
read the regulations for yourself.
Note that the internet is not the place to get legal advice and the
above is not legal advice. If you are concerned see a lawyer.
Note also that as far as I know there are no restrictions whatsoever on
the use or transfer of crypto between US citizens within the USA. If
your friends are not US citizens then the rules may be different.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Entropy paradox
Date: 21 Nov 2000 22:30:26 GMT
]Mok-Kong Shen wrote:
]
]> This is a re-formulation of an issue that I questioned
]> previously. Suppose one has m perfectly random bits and
]> uses that in some appropriate way to get a BBS generator
]> to generate u bits, with u >> m. We know that (accepting
]> certain plausible assumptions) the u bits are provably
]> secure. It seems thus that we have obtained more entropy
]> that way, i.e. having obtained an amount of additional
]> entropy from nothing. How is this apparent paradox to be
]> properly explained? (Or does each bit of the generated
]> sequence have in average m/u bits of entropy?) Thanks in
]> advance.
There is no paradox, just bad assumptions. Assume I have an engine into
which I can put 1 liter of gasoline, and the engine when it burns the
gasoline puts out 1000 times as much energy as were in that liter of
gasoline. How do you explain the paradox? By pointing out that the
assumption is bad.
You claim "We know that the u bits are provably secure" How do you know
that (I sure do not so am not included in the "we")?
Since you have not told us what the BBS generator is or what your
"proof" is noone can be more exact as to where you went wrong.
------------------------------
From: "ralphv" <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.logic
Subject: Re: My new book "Exploring RANDOMNESS"
Date: Tue, 21 Nov 2000 19:16:36 -0700
"Richard Heathfield" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] wrote:
> >
> > In article <[EMAIL PROTECTED]>,
> > Richard Heathfield <[EMAIL PROTECTED]> wrote:
> >
> > > Counter-examples, all of which (IMHO) are relevant to sci.crypt: >
> > > "The Art of Computer Programming" - Knuth
> > > "The C Programming Language" - Kernighan and Ritchie
> > > "Applied Cryptography" - Schneier
> > >
> > > If any of these /are/ available online, I'd be astonished (and I want
> > > the URL!).
> >
> > Why would that be surprising ? Is it not logical to spread
> > best books first ? Nowadays most of security and computer related
> > best-sellers are available in electronic format : from your list,
> > at least AC2 and K&R do exist (.htm and .txt, respectively). However,
> > for obvious reasons you will have to search a bit to get them.
>
>
> Pardon me for being dense, but why would one need to search terribly
> hard for them?
>
> If AC2 is available electronically, it would be either on the Wiley site
> or on Counterpane. As for K&R, it would be on Prentice Hall's Web site,
> or possibly Lysator.
>
>
> --
> Richard Heathfield
> "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
> C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
> K&R answers, C books, etc: http://users.powernet.co.uk/eton
http://www.lysator.liu.se/c/bwk-tutor.html
sixty something K tutorial, found by pasting Kernighan and Ritchie into
dogpile. looked at other search results, saw covers of the book in many
languages, also found out it is available at amazon and other book sites.
ralphv
------------------------------
From: "Rainer Nausedat" <[EMAIL PROTECTED]>
Subject: Re: "unsecure data structures" ?
Date: Wed, 22 Nov 2000 03:27:15 +0100
Rainer Nausedat <[EMAIL PROTECTED]> schrieb in im Newsbeitrag:
8vcd80$c3s$[EMAIL PROTECTED]
>
> Am I right if I assume that one could easily break such a header if is
> encrypted ? dwFileCrc for example could be least any 32bit value, but
> dwFileAttribute is one of say 12 known possible values, and
> cCompressionMethod is one 6 known possible values etc.
Thank you very much for all your input. After reading all your arcticles it
seems to me that best and 'most secure' solution is to *make sure* that the
archive headers and the archive data itself are going to be encrypted always
with two different keys.
So one may break the encrypted archive header since it contains some known
text (and we cannot remove all known text from the archive headers), but the
raw data of the archive files still remains protected/encrypted.
Thank you very much again,
Rainer Nausedat
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: A Simple Voting Procedure
Date: 22 Nov 2000 02:14:24 GMT
David Schwartz <[EMAIL PROTECTED]> wrote:
> David Wagner wrote:
>>
>> David Schwartz wrote:
>> > Now, the question I'm asking is, is there any objection to a system
>> >where the voter and an official can, with mutual consent, determine how
>> >the voter voted?
>>
>> Yes. Vote buying.
> You can buy votes now if you trust the voter to consent, so this
> changes nothing.
It changes *everything*. A stable market for votes depends on the sellers
actually following through and then being able to convince the buyers that
they *did* follow through. Your ``if you trust the voter to consent" hides
a hell of a lot.
As it is now, if you buy my vote and I tell you I'll vote for someone,
you have no idea whether I'll really vote that way or whether I'll
laugh and walk away. I can *sell my vote to both sides* and then vote
a third party if I feel like it!
Without some way of auditing the transaction, you only have trust between
the buyer and seller...who probably don't know each other very well. and
they're both breaking the law to boot. Neither of them are ``nice people."
-David
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: A Simple Voting Procedure
Date: 22 Nov 2000 02:53:39 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
David Schwartz wrote:
> Consider a system where each voter has an ID but no voter can prove
>which ID is his and no official can map an ID to a particular voter.
How do you do this? This is the part that I don't see how to do
while maintaining complete deniability.
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: ---- How can I get a copy of the latest Yarrow?
Date: Wed, 22 Nov 2000 02:49:16 GMT
Counterpane's web site has the source code for Yarrow, but they say it
is not compliant with the latest paper they published on Yarrow. Can
anyone tell me where or how I can get a copy of the latest software?
--
I prefer my fourth amendment rights over a dope free
society, even if the latter could actually be achieved.
Al Gore - quite possibly America's greatest threat today
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: A Simple Voting Procedure
Date: Tue, 21 Nov 2000 19:03:08 -0800
David Wagner wrote:
>
> David Schwartz wrote:
> > Consider a system where each voter has an ID but no voter can prove
> >which ID is his and no official can map an ID to a particular voter.
>
> How do you do this? This is the part that I don't see how to do
> while maintaining complete deniability.
You could assign the voter his ID when he votes. Each voter could have
a device that can store both IDs and receipts. When you vote, your ID
and receipt is sent to your machine by infrared and a sequence numher
(that starts at 1) is displayed on the screen. You can also, if you
want, download any number of random receipts into your machine and they
will get their own sequence numbers. You can also delete receipts from
your machine if you want. Of course, you know which sequence number was
displayed when your actual vote went into the machine, but you have no
way to ever prove that to seomeone else.
Note that I'm not actually suggesting this scheme, it's just a
possibility proof.
DS
------------------------------
From: [EMAIL PROTECTED]
Subject: How to find celebrity
Date: Wed, 22 Nov 2000 03:10:39 GMT
Among n people, a celebrity is someone who everyone knows but who knows
no one. To identify the celebrity, if one exists, you are allowed to
ask questions of any of the n people, but only of the form: "Excuse me,
do you that person over there?" Assume that all answers are correct.
Minimize the number of questions you need to ask to determine the
celebrity, if one exists, or to determine no celebrity exists in a
given set of n people.
suggestions please
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (nemo outis)
Subject: Re: vote buying...
Date: Wed, 22 Nov 2000 03:20:52 GMT
I had a Canadian relative many years ago get a voter registration card In
Alaska with no ID! It was a couple of old ladies in some grocery store
recruiting.
In article <[EMAIL PROTECTED]>, Jeffrey Williams
<[EMAIL PROTECTED]> wrote:
>Although I'll point out that voting in person doesn't prevent fraud. According
>to my American friends, to get a voter registration card, one needs a valid
>picture id (driver's licence, for example) and a social security card. I have
> a
>Texas driver's licence and a social security number. I'm a Canadian living in
>Texas.
>
>Even those qualifications are suspect; I know people who presented neither and
>were given voter registration.
>
>It would seem to me that foreigners can vote, and that it is possible for
> anyone
>to register to vote multiple times. I do not see how your system is fair,
>honest, or trustworthy. I do not see how it can be without some form of
> national
>(or state-wide) identification card.
>
>
------------------------------
From: [EMAIL PROTECTED]
Subject: SET Protocol -- Question
Date: Wed, 22 Nov 2000 05:10:35 GMT
I was reading through the SET Protocol specifications and I realized
that all documentation point towards the use of RSA and DES.
RSA makes sense (i.e., it has proven strength), but does anyone know if
DES is still used for SET's symmetric algorithm?
To me, DES would seem way to weak. I would hope they are at least using
3DES.
-Jeff
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "David Thompson" <[EMAIL PROTECTED]>
Subject: SET; was Re: Why trust root CAs ?
Date: Wed, 22 Nov 2000 05:53:12 GMT
(Sorry for the delay, I was away; several responses combined)
Lyalc <[EMAIL PROTECTED]> wrote :
> A couple of other things SET doesn't protect against:
> 1. The order and certificate can be transmitted without SSL protection,
> allowing any "every sniffer and server along the route" to match
> order/delivery details (such as name, address etc) with the cardholder cert
> alias
SET does transmit the cardholder cert (and its parents) in clear,
or at least allow such transmission: since the spec doesn't
define transport, it would actually be "legal" to (super)encrypt,
such as with SSL/TLS, but I doubt anyone will.
SET does not transmit the order information _at all_; that must
have been handled by other means. It is perfectly possible,
and recommended but not required, to "shop" with SSL/TLS
confidentiality and then pay with SET. One capability this
does not provide is for the cardholder to prevent disclosing
delivery information to a merchant who has been "revoked",
as SET does prevent disclosing payment (card) information.
(The X9.59 approach has the same limitation, as I read it.)
> 2. The cert being revoked around the time of the transaction. SET has an
> inherent "Originating party" liability model. The US Govt's PKI schema
> requires Relying parties to validate certificates before relying upon the
> digital signature as an electronic signature. In a large dispersed
> environment, this is perhaps the only way cert validity can be managed with
> any reasonable granularity, and the expense of very high bandwidth and
> CA/Revocation server availabiltiy requirements (AFAICS, all workable CRL
> models require very high bandwidth, and very high availability).
>
SET (as I and Tor already said) does not use revocation of
cardholder certs; instead it uses existing mechanisms for the
Issuing bank to block the underlying account. And similarly
uses Acquirer blocking rather than revoking merchants.
SET does prescribe CRLs for revocation of Acquirer gateways
and CAs, but before there are enough of these for bandwidth
to be noticeable people will reject the scheme entirely.
The primary distribution of CRLs (and BCIs) is via gateways,
which already have high availability requirements anyway.
> There are working, high volume, secure environments out there today which
> don't require cardholder keys, but do require secure key management. For
> certificate based schema to get to that level of security, low exposure and
> reliability, they need to be implemented on ATM or EFTPOS -like devices.
ATM and POS verify possession of the physical card;
no Internet scheme can do that directly, although if you deploy
smartcards (and readers or other interfaces) you can prove
(current) access to a key known to have been in the card.
ATM and POS don't authenticate themselves to the user,
and there are already occasional problems with crooks
faking, or subverting, them. SET *does* authenticate
the merchant to the cardholder (partially before the PReq
is even generated, and fully through the Acquirer before
payment is made). This is an additional benefit
if you don't (as I believe this thread starting out saying)
trust current SSL/TLS CAs to do this; for the payment system
to do this without certs, since the cardholder has no trust
relationship with the Acquirer, you need either to tunnel
back from the Issuer (through Acquirer and merchant),
or add online communication between Issuer and cardholder.
> Since this level of hardware protection is needed to make certificate
> schemes even moderately secure, why use certs as the hardware already does
> all the necessary security?
> Keeping cert vendor share prices high seems to be the only reason to me.
>
Key security is required for any cryptographic scheme,
with or without certs; special hardware is best,
but for now getting hardware into the hands of all
cardholders, in a form that can be used, is expensive.
Although I'm sure that'll get fixed before long.
If you want to authenticate strangers, certs are the
most straightforward way; _if_ it is sufficient to use
preexisting relationships, you don't need them.
Anne & Lynn Wheeler <[EMAIL PROTECTED]> wrote
in message news:[EMAIL PROTECTED]...
...
> the issue is relying on existing infrastructure ... built around the
> 80-160 byte messages. FOr instance, I've seen reports that SET
> certificates ranged in size from 2k bytes to a high of 12kbytes.
>
Individual SET certs are usually 1-2kbyte, maybe somewhat less
if the CAs make effective use of policyQualifier inheritance.
The compliance tests require that software handle 20kbyte certs,
but no one was (or I think will be) perverse enough to deploy such.
The full trust *chain* can be 5-10 certs = 10kbyte or more.
Usually with a little care you can eliminate most of this,
but not always and not all.
On *most* of today's Internet links, several kbyte doesn't matter
*much*. (To be pedantic, make those all kilo-octets.)
Anne & Lynn Wheeler <[EMAIL PROTECTED]> wrote
in message news:[EMAIL PROTECTED]...
[ and several others, this is the most convenient ]
> and besides ... it is superfulous and redundant to transmit a copy of
> something (and appended transaction certificate) possibly thousands of
> times a day ... to somebody that has the original. Even HTTP browswers
> know about caching and trying to avoid superfulous and redundant
> transmission.
>
(The word is "superfluous". Once is a typo, four or five
times gets annoying.)
To be clear, sending and even having a cardholder cert is
superfluous *if*, as you propose and said earlier, we defer
authentication (along with authorization) to the Issuer only.
If we want any Acquirer and/or merchant authentication
of the cardholder (which I understand you don't)
and we want to allow customers to shop with any merchant
(which presumably everyone does) either a cardholder cert
or equivalent, or a four-party protocol, is needed.
Web browsers are not a particularly good argument;
HTTP caches only in the reply=downstream direction,
and SET does suppress certs (and CRLs and BCIs)
downstream in a very similar fashion. Sending
substantial data upstream is much less common
on the Web, but when done is not optimized;
if you fill out a large form in your browser and submit it,
and then submit it again, it is all sent again.
--
- David.Thompson 1 now at worldnet.att.net
------------------------------
Subject: Re: Cryptogram Newsletter is off the wall?
From: [EMAIL PROTECTED] (Mark Currie)
Date: 22 Nov 2000 06:30:27 GMT
In article <8vbej1$cmp$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>For online transactions you could have a smartcard with a keypad that
>created a secure session through the terminal/ATM/whatever to a
>remote server that stored the private key using the a PIN and a protocol
>like SNAKE (plug plug :-), SPEKE, or SRP. The document/data could
>then be sent to the remote server for signing either via the card, or
>directly from the terminal/ATM/whatever with a MAC generated by the
>card. Its even feasible that the card could have a little LCD display
>so that you could visibly verify the document, data or content hash.
>
>This would avoid private keys being sent all over the place, and you
>dont have to trust the software to do what it says. All you trust is
>the your own personal smartcard which doesnt even need to
>store your private key (I guess you might want it to for offline
>transactions tho).
Smart cards can help and a remote secure signing server may also, but the thing
that worries me is that the basic principle is the same. You are letting a
machine act as a proxy for signing. There is no biological binding such as in a
hand-written signature. Smart cards are starting to become complex machines in
their own right. They now have operating systems and they can download and
execute third party code.
Hand-written signatures can easily be forged, digital ones cannot easily be
forged, but you know that you are signing the document that you have just read
with a hand-written signature whereas you do not with a digital one.
Mark
------------------------------
** 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
******************************
