Re: On the orthogonality of anonymity to current market demand

[R.A. Hettinga]

At 10:22 AM -0500 10/31/05, [EMAIL PROTECTED] wrote:
>and doesn't history show that big corporations are only interested in
>revenue

One should hope so.

;-)

Cheers,
RAH

-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

Re: packet traffic analysis

[Travis H.]

Good catch on the encryption.  I feel silly for not thinking of it.

> If your plaintext consists primarily of small packets, you should set the MTU
> of the transporter to be small.   This will cause fragmentation of the
> large packets, which is the price you have to pay.  Conversely, if your
> plaintext consists primarily of large packets, you should make the MTU large.
> This means that a lot of bandwidth will be wasted on padding if/when there
> are small packets (e.g. keystrokes, TCP acks, and voice cells) but that's
> the price you have to pay to thwart traffic analysis.

I'm not so sure.  If we're talking about thwarting traffic on the link
level (real circuit) or on the virtual-circuit level, then you're
adding, on average, a half-packet latency whenever you want to send a
real packet.  And then there's the bandwidth tradeoff you mention,
which is probably of a larger concern (although bandwidth will
increase over time, whereas the speed of light will not).

I don't see any reason why it's necessary to pay these costs if you
abandon the idea of generating only equal-length packets and creating
all your chaff as packets.  Let's assume the link is encrypted as
before.  Then you merely introduce your legitimate packets with a
certain escape sequence, and pad between these packets with either
zeroes, or if you're more paranoid, some kind of PRNG.  In this way,
if the link is idle, you can stop generating chaff and start
generating packets at any time.  I assume that the length is
explicitly encoded in the legitimate packet.  Then the peer for the
link ignores everything until the next "escape sequence" introducing a
legitimate packet.

This is not a tiny hack, but avoids much of the overhead in your
technique.  It could easily be applied to something like openvpn,
which can operate over a TCP virtual circuit, or ppp.  It'd be a nice
optimization if you could avoid retransmits of segments that contained
only chaff, but that may or may not be possible to do without giving
up some TA resistance (esp. in the presence of an attacker who may
prevent transmission of segments).
--
http://www.lightconsulting.com/~travis/  -><-
"We already have enough fast, insecure systems." -- Schneier & Ferguson
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B

Re: Multiple passports?

[Jay Goodman Tamboli]

On 10/30/05, Gregory Hicks <[EMAIL PROTECTED]> wrote:
> The only people that I knew that had two passports were those with an
> "Official" (red) passport or a "Diplomatic" (black) passport.  If they
> wanted to go play tourist, they had to also have a "tourist" (Blue)
> passport.

I wasn't able to find a reference to support this on http://state.gov,
but I know it's possible to get two passports if you plan to travel to
both Israel and a country that refuses to admit people with Israeli
stamps in their passports.

/jgt

Re: On the orthogonality of anonymity to current market demand

[johns]

hi

( 05.10.26 09:17 -0700 ) James A. Donald:
> While many people are rightly concerned that DRM will
> ultimately mean that the big corporation, and thus the
> state, has root access to their computers and the owner
> does not, it also means that trojans, viruses, and
> malware does not.

do you really think this is true?

doesn't microsoft windows prove that remote control of computers only
leads to compromise? [especially in our heavily networked world]

and doesn't history show that big corporations are only interested in
revenue- so that if they get revenue by forcing you to pay them fees for
'upkeep' of your digital credentials to keep your computer working they
are going to do that.

the problems 'solved' by DRM can also be solved by moving to an
operating system where you have control of it, instead of an operating
system filled with hooks so other people can control your computer.

and that operating system is freely available ...

-- 
\js oblique strategy: don't be frightened of cliches

Re: [EMAIL PROTECTED]: [IP] more on U.S. passports to receive RFID implants start

[Bill Stewart]

At 01:42 AM 10/30/2005, Roy M. Silvernail wrote:

Tyler Durden wrote:

> One thing to think about with respect to the RFID passports...
>
> Um, uh...surely once in a while the RFID tag is going to get corrupted
> or something...right? I'd bet it ends up happening all the time. In
> those cases they probably have to fall back upon the traditional
> passport usage and inspection.


They've said they'll fall back on the traditional
"If we can't read the passport it's invalid and you'll need to
replace it before we'll let you leave the country" technique,
just as they often do with expired passports and sometimes
do with just-about-to-expire passports if you're a
Suspicious-Acting Person like Dave del Torto.


> The only question is, what could (believably) damage the RFID?


If you want to damage the RFID of a passport you're playing with,
microwave ovens should do just fine.
I don't know if Rivest's RFID-blocker chips use the same
frequency or codespace as the passport RFIDs,
but you could also leave one of them in the back of your passport.


Now put that chip-cooker in a trash can right by the main entrance to an
airport and perform some public service.


I'd be surprised if you could put out enough energy to cook
the passport RFIDs of people walking by at normal speed
without also causing lots of other electrical problems.

Re: Multiple passports?

[Gregory Hicks]

> Date: Sun, 30 Oct 2005 03:05:25 +
> From: Justin <[EMAIL PROTECTED]>
> 
> If I apply for a new one now, and then apply for a another one once
> the gov starts RFID-enabling them, will the first one be
> invalidated?  Or can I have two passports, the one without RFID to
> use, and the one with RFID to play with?

I am not a State Dept person, but my experiences in this are...

If you get a new one, the old one has to accompany the application and
is invalidated when the new one is issued.  (Invalidated by stamping
the 'data' page with big red block letters "INVALID".)  The old, now
invalid is returned with the new one...

The only people that I knew that had two passports were those with an
"Official" (red) passport or a "Diplomatic" (black) passport.  If they
wanted to go play tourist, they had to also have a "tourist" (Blue)
passport.

As for applying for one now, I think the deadline for the non-RFID
passwords is about 3 days away (31 Oct 2005), but I could be wrong.
(In other words, if your application is not in processing by 31 Oct,
then you get the new, improved, RFID passport.)

Regards,
Gregory Hicks

> 
> -- 
> The six phases of a project:
> I. Enthusiasm. IV. Search for the Guilty.
> II. Disillusionment.   V. Punishment of the Innocent.
> III. Panic.VI. Praise & Honor for the Nonparticipants.

-
I am perfectly capable of learning from my mistakes.  I will surely
learn a great deal today.

"A democracy is a sheep and two wolves deciding on what to have for
lunch.  Freedom is a well armed sheep contesting the results of the
decision." - Benjamin Franklin

"The best we can hope for concerning the people at large is that they
be properly armed." --Alexander Hamilton

Re: packet traffic analysis

[John Denker]

In the context of:

>>If your plaintext consists primarily of small packets, you should set the MTU
>>of the transporter to be small.   This will cause fragmentation of the
>>large packets, which is the price you have to pay.  Conversely, if your
>>plaintext consists primarily of large packets, you should make the MTU large.
>>This means that a lot of bandwidth will be wasted on padding if/when there
>>are small packets (e.g. keystrokes, TCP acks, and voice cells) but that's
>>the price you have to pay to thwart traffic analysis.

Travis H. wrote:


I'm not so sure.  If we're talking about thwarting traffic on the link
level (real circuit) or on the virtual-circuit level, then you're
adding, on average, a half-packet latency whenever you want to send a
real packet. 


I very much doubt it.  Where did that factor of "half" come frome.


I don't see any reason why it's necessary to pay these costs if you
abandon the idea of generating only equal-length packets 


Ah, but if you generate unequal-length packets then they are
vulnerable to length-analysis, which is a form of traffic analysis.
I've seen analysis systems that do exactly this.  So the question is,
are you trying to thwart traffic analysis, or not?

I should point out that encrypting PRNG output may be pointless, 


*is* pointless, as previously discussed.


and
perhaps one optimization is to stop encrypting when switching on the
chaff. 


A better solution would be to leave the encryption on and use constants
(not PRNG output) for the chaff, as previously discussed.


Some minor details
involving resynchronizing when the PRNG happens to


The notion of synchronized PRNGs is IMHO crazy -- complicated as well as
utterly unnecessary.

Re: Blood, Bullets, Bombs and Bandwidth

[R.A. Hettinga]

At 11:59 PM + 10/30/05, Justin wrote:
>Tyler likes the high-speed lifestyle so much that he ditched it and
>moved to London?

He and Jayme are back in Kurdistan, now. Don't know for how long, though.
He's teaching a new class of engineers, including crypto and security
stuff. Watched their jaws drop when he 'em how to break WEP, that kind of
thing.

They handed him his Browning at the airfield when he landed. :-)

Of course, they're touchy-feely liberals through-and-through, but here's
hoping they've learned a little about anarchocapitalism having watched it
firsthand, albeit temporarily.

Cheers,
RAH

-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

Re: Any comments on BlueGem's LocalSSL?

[R.A. Hettinga]

At 7:51 PM -0400 10/28/05, R.A. Hettinga wrote:
>OTOH, if markets overtake the DRM issue,
^" moot", was what I meant to say...

Anyway, you get the idea.

Cheers,
RAH

-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

Multiple passports?

[Justin]

If I apply for a new one now, and then apply for a another one once the
gov starts RFID-enabling them, will the first one be invalidated?  Or
can I have two passports, the one without RFID to use, and the one with
RFID to play with?

-- 
The six phases of a project:
I. Enthusiasm. IV. Search for the Guilty.
II. Disillusionment.   V. Punishment of the Innocent.
III. Panic.VI. Praise & Honor for the Nonparticipants.

Re: On Digital Cash-like Payment Systems

[John Kelsey]

>From: cyphrpunk <[EMAIL PROTECTED]>
>Sent: Oct 27, 2005 9:15 PM
>To: "James A. Donald" <[EMAIL PROTECTED]>
>Cc: cryptography@metzdowd.com, [EMAIL PROTECTED]
>Subject: Re: On Digital Cash-like Payment Systems

>On 10/26/05, James A. Donald <[EMAIL PROTECTED]> wrote:
>> How does one inflate a key?

>Just make it bigger by adding redundancy and padding, before you
>encrypt it and store it on your disk. That way the attacker who wants
>to steal your keyring sees a 4 GB encrypted file which actually holds
>about a kilobyte of meaningful data. Current trojans can steal files
>and log passwords, but they're not smart enough to decrypt and
>decompress before uploading. They'll take hours to snatch the keyfile
>through the net, and maybe they'll get caught in the act.

Note that there are crypto schemes that use huge keys, and it's
possible to produce simple variants of existing schemes that use
multiple keys.  That would mean that the whole 8GB string was
necessary to do whatever crypto thing you wanted to do.  A simple
example is to redefine CBC-mode encryption as

C[i] = E_K(C[i-1] xor P[i] xor S[C[i-1] mod 2^{29}])

where S is the huge shared string, and we're using AES.  Without
access to the shared string, you could neither encrypt nor decrypt.

>CP

--John

Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems

[Daniel A. Nagy]

On Fri, Oct 28, 2005 at 02:18:43PM -0700, cyphrpunk wrote:

> In particular I have concerns about the finality and irreversibility
> of payments, given that the issuer keeps track of each token as it
> progresses through the system. Whenever one token is exchanged for a
> new one, the issuer records and publishes the linkage between the new
> token and the old one. This public record is what lets people know
> that the issuer is not forging tokens at will, but it does let the
> issuer, and possibly others, track payments as they flow through the
> system. This could be grounds for reversibility in some cases,
> although the details depend on how the system is implemented. It would
> be good to see a critical analysis of how epoints would maintain
> irreversibility, as part of the paper.

I agree, this discussion is missing, indeed. I will definitely include it,
should I write another paper on the subject.

Irreversibility of transactions hinges on two features of the proposed
systetm: the fundamentally irreversible nature of publishing information in
the public records and the fact that in order to invalidate a secret, one
needs to know it; the issuer does not learn the secret at all in some
implementnations and only learns it when it is spent in others.

In both cases, reversal is impossible, albeit for different reasons. Let's
say, Alice made a payment to Bob, and Ivan wishes to reverse it with the
possible cooperation of Alice, but definitely without Bob's help. Alice's
secret is Da, Bob's secret is Db, the corresponding challenges are,
respectively, Ca and Cb, and the S message containing the exchange request
Da->Cb has already been published.

In the first case, when the secret is not revealed, there is simply no way to
express reverslas. There is no S message with suitable semantics semantics,
making it impossible to invalidate Db if Bob refuses to reveal it.

In the second case, Db is revealed when Bob tries to spend it, so Ivan can,
in principle, steal (confiscate) it, instead of processing, but at that
point Da has already been revealed to the public and Alice has no means to
prove that she was in excusive possession of Da before it became public
information.

Now, one can extend the list of possible S messages to allow for reversals
in the first scenario, but even in that case Ivan cannot hide the fact of
reversal from the public after it happened and the fact that he is prepared
to reverse payments even before he actually does so, because the users and
auditors need to know the syntax and the semantics of the additional S
messages in order to be able to use Ivan's services.

-- 
Daniel

RE: Return of the death of cypherpunks.

[Tyler Durden]

I don't agree.

One thing we do know is that, although Crypto is available and, in special 
contexts, used, it's use in other contexts is almost counterproduct, sending 
up a red flag so that those that "Protect Our Freedoms" will come sniffing 
around and bring to bear their full arsenal of technologies and, possibly, 
dirty tricks. Merely knowing that you are using stego/crypto in such 
contexts can cause a lot of attention come your way, possibly in actual 
meatspace, which in many cases is almost worse than not using crypto at all


In addition, although strong and "unbreakable" Crypto exists, one thing a 
stint on Cypherpunks teaches you is that it is only rarely implemented in 
such a way as to actually be unbreakable to a determined attacker, 
particularly if there are not many such cases to examine in such contexts.


The clear moral of this story is that, to increase the odds of truly secure 
communication, etc, Crypto in such contexts must become much more 
ubiquitous, and I still think Cypherpunks has a role to play there and 
indeed has played that role. Such a role is, of course, far more than a mere 
cheerleading role,a fact that merits a continued existence for Cypherpunks 
in some form or another.


-TD






Only when Crypto is used ubiquitousl


From: "James A. Donald" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Return of the death of cypherpunks.
Date: Fri, 28 Oct 2005 12:09:36 -0700

--
From:   Eugen Leitl <[EMAIL PROTECTED]>
> While I don't exactly know why the list died, I
> suspect it was the fact that most list nodes offered a
> feed full of spam, dropped dead quite frequently, and
> also overusing that "needs killing" thing (okay, it
> was funny for a while).
>
> The list needs not to stay dead, with some finite
> effort on our part (all of us) we can well resurrect
> it. If there's a real content there's even no need
> from all those forwards, to just fake a heartbeat.

Since cryptography these days is routine and
uncontroversial, there is no longer any strong reason
for the cypherpunks list to continue to exist.

I recently read up on the Kerberos protocol, and
thought, "how primitive".  Back in the bad old days, we
did everything wrong, because we did not know any
better.  And of course, https sucks mightily because the
threat model is both inappropriate to the real threats,
and fails to correspond to the users mental model, or to
routine practices on a wide variety of sites, hence
users glibly click through all warning dialogs, most of
which are mere noise anyway.

These problems, however, are no explicitly political,
and tend to be addressed on lists that are not
explicitly political, leaving cypherpunks with little of
substance.

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 AnKV4N6f9DgtOy+KkQ9QsiXcpQm+moX4U09FjLXP
 4zfMeSzzCXNSr737bvqJ6ccbvDSu8fr66LbLEHedb

Re: Return of the death of cypherpunks.

[James A. Donald]

--
James A. Donald:
> > Since cryptography these days is routine and 
> > uncontroversial, there is no longer any strong 
> > reason for the cypherpunks list to continue to 
> > exist.

John Kelsey
> The ratio of political wanking to technical posts and 
> of talkers to thinkers to coders needs to be right for 
> the list to be interesting.

These days, if one is seriously working on overthrowing 
the state by advancing to crypto anarchy (meaning both 
anarchy that is hidden, in that large scale cooperation 
procedes without the state taxing it, regulating it, 
supervising it, and licensing it, and anarchy that 
relies on cryptography to resist the state) it is not 
necessary or advisable to announce what one is up to.

For example, Kerberos needs to be replaced by a more 
secure protocol.  No need to add "And I am concerned 
about this because I am an anarchist"  And so one
discusses it on another list.

(Kerberos tickets are small meaningful encrypted packets 
of information, when they should be random numbers. 
Being small, they can be dictionary attacked.) 

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 Y068Cy3Zv9GExXRbP24QJP5WmHGLz5VKyqNYFKbx
 45fkOIGeiTkFnaM7p/URjB/kgn+0mcg8fMsMLmDy7

Re: Blood, Bullets, Bombs and Bandwidth

[Justin]

On 2005-10-22T01:51:50-0400, R.A. Hettinga wrote:
> --- begin forwarded text
> 
>  Tyler and Jayme left Iraq in May 2005. The Arbil office failed; there
>  wasn't enough business in Kurdistan. They moved to London, where Tyler
>  still works for SSI. His time in Iraq has transformed him to the extent
>  that, like Ryan, he doesn't think he can ever move back to the USA. His
>  years of living hyperintensely, carrying a gun, building an organization
>  from scratch in a war zone, have distanced him from his home. His friends
>  seem to him to have stagnated. Their concerns seem trivial. And living with
>  real, known, tangible danger has bred contempt for what he calls America's
>  "culture of fear."

Tyler likes the high-speed lifestyle so much that he ditched it and
moved to London?  I doubt he's carrying a gun there.

-- 
The six phases of a project:
I. Enthusiasm. IV. Search for the Guilty.
II. Disillusionment.   V. Punishment of the Innocent.
III. Panic.VI. Praise & Honor for the Nonparticipants.

Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems

[cyphrpunk]

One other point with regard to Daniel Nagy's paper at
http://www.epointsystem.org/~nagydani/ICETE2005.pdf

A good way to organize papers like this is to first present the
desired properties of systems like yours (and optionally show that
other systems fail to meet one or more of these properties); then to
present your system; and finally to go back through and show how your
system meets each of the properties, perhaps better than any others.
This paper is lacking that last step. It would be helpful to see the
epoint system evaluated with regard to each of the listed properties.

In particular I have concerns about the finality and irreversibility
of payments, given that the issuer keeps track of each token as it
progresses through the system. Whenever one token is exchanged for a
new one, the issuer records and publishes the linkage between the new
token and the old one. This public record is what lets people know
that the issuer is not forging tokens at will, but it does let the
issuer, and possibly others, track payments as they flow through the
system. This could be grounds for reversibility in some cases,
although the details depend on how the system is implemented. It would
be good to see a critical analysis of how epoints would maintain
irreversibility, as part of the paper.

CP

Re: Multiple passports?

[Peter Gutmann]

Gregory Hicks <[EMAIL PROTECTED]> writes:

>As for applying for one now, I think the deadline for the non-RFID passwords
>is about 3 days away (31 Oct 2005), but I could be wrong. (In other words, if
>your application is not in processing by 31 Oct, then you get the new,
>improved, RFID passport.)

Ahh, but if you get one of the first passports issued then there are likely to
still be some teething problems present, leading to sporadic failures of the
first batch of RFID devices.  I have a funny feeling that this is going to
happen to my new passport when it arrives.

Peter.

Re: Multiple passports?

[Eugen Leitl]

On Sun, Oct 30, 2005 at 03:05:25AM +, Justin wrote:
> If I apply for a new one now, and then apply for a another one once the
> gov starts RFID-enabling them, will the first one be invalidated?  Or
> can I have two passports, the one without RFID to use, and the one with
> RFID to play with?

Here in Germany the current ID (sans smartcard/rfid/biometics) will
be valid until expiry date.

-- 
Eugen* Leitl http://leitl.org";>leitl
__
ICBM: 48.07100, 11.36820http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE


signature.asc
Description: Digital signature

RE: [EMAIL PROTECTED]: [IP] more on U.S. passports to receive RFID implants start

[Tyler Durden]

One thing to think about with respect to the RFID passports...

Um, uh...surely once in a while the RFID tag is going to get corrupted or 
something...right? I'd bet it ends up happening all the time. In those cases 
they probably have to fall back upon the traditional passport usage and 
inspection.


The only question is, what could (believably) damage the RFID?

-TD


From: Eugen Leitl <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [EMAIL PROTECTED]: [IP] more on U.S. passports to receive RFID  
implants starting in October 2006 [priv]]

Date: Sat, 29 Oct 2005 20:54:13 +0200

- Forwarded message from David Farber <[EMAIL PROTECTED]> -

From: David Farber <[EMAIL PROTECTED]>
Date: Fri, 28 Oct 2005 17:49:06 -0400
To: Ip Ip 
Subject: [IP] more on U.S. passports to receive RFID implants starting in
October 2006 [priv]
X-Mailer: Apple Mail (2.734)
Reply-To: [EMAIL PROTECTED]



Begin forwarded message:

From: Edward Hasbrouck <[EMAIL PROTECTED]>
Date: October 28, 2005 11:07:28 AM EDT
To: [EMAIL PROTECTED]
Subject: Re: [IP] more on U.S. passports to receive RFID implants
starting in October 2006 [priv]


>From: "Lin, Herb" <[EMAIL PROTECTED]>
>
>*Front* cover?  Does that mean that if I hold the passport the wrong
>way, the skimmer will have a free ride?
>

FWIW:

(1) The sample RFID passports that Frank Moss passed around at CFP,
which
looked like , had
the RFID chip (which was barely detectable by feel) in the *back* cover.
The visible data page was/is, as with current passports, in the *front*
cover.  This is not compliant with the ICAO specifications, which
recommend having the chip in the same page as the visible data, to
make it
more difficult to separate them.  I can only guess that it was hard to
laminate the visible data without damaging the chip, if it was in the
same
page.  But it's interesting in light of the importance supposedly being
placed on compliance with ICAO standards.

(2) Moss had 2 sample RFID passports, 1 with and 1 without the
shielding.
He cliamed it was a layer in the entire outer cover (front and back),
but
it wasn't detectable by feel.

I have more threat scenarios for the latest flavor of RFID passport at:

http://hasbrouck.org/blog/archives/000869.html



Edward Hasbrouck
<[EMAIL PROTECTED]>

+1-415-824-0214




-
You are subscribed as [EMAIL PROTECTED]
To manage your subscription, go to
 http://v2.listbox.com/member/?listname=ip

Archives at: http://www.interesting-people.org/archives/interesting-people/

- End forwarded message -
--
Eugen* Leitl http://leitl.org";>leitl
__
ICBM: 48.07100, 11.36820http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE

[demime 1.01d removed an attachment of type application/pgp-signature which 
had a name of signature.asc]

Re: Any comments on BlueGem's LocalSSL?

[R.A. Hettinga]

At 11:10 AM -0700 10/28/05, James A. Donald wrote:
>I am a reluctant convert to DRM.  At least with DRM, we
>face a smaller number of threats.

I have had it explained to me, many times more than I want to remember,
:-), that strong crypto is strong crypto.

It's not that I'm unconvinceable, but I'm still unconvinced, on the balance.

OTOH, if markets overtake the DRM issue, as most cypherpunks I've talked to
think, then we still have lots of leftover installed crypto to play around
with.

Cheers,
RAH
Who still thinks that digital proctology is not the same thing as financial
cryptography.
-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

Re: Multiple passports?

[Justin]

On 2005-10-29T21:17:25-0700, Gregory Hicks wrote:
> > Date: Sun, 30 Oct 2005 03:05:25 +
> > From: Justin <[EMAIL PROTECTED]>
> > 
> > If I apply for a new one now, and then apply for a another one once
> > the gov starts RFID-enabling them, will the first one be
> > invalidated?  Or can I have two passports, the one without RFID to
> > use, and the one with RFID to play with?
> 
> I am not a State Dept person, but my experiences in this are...
> 
> As for applying for one now, I think the deadline for the non-RFID
> passwords is about 3 days away (31 Oct 2005), but I could be wrong.
> (In other words, if your application is not in processing by 31 Oct,
> then you get the new, improved, RFID passport.)

"The Department intends to begin the electronic passport program in 
December 2005. The first stage will be a pilot program in which the 
electronic passports will be issued to U.S. Government employees who 
use Official or Diplomatic passports for government travel. This pilot 
program will permit a limited number of passports to be issued and 
field tested prior to the first issuance to the American traveling 
public, slated for early 2006. By October 2006, all U.S. passports, 
with the exception of a small number of emergency passports issued by 
U.S. embassies or consulates, will be electronic passports."

http://edocket.access.gpo.gov/2005/05-21284.htm (2005-10-25 Fed. Reg.)

It sounds like it's fairly safe to get a new passport after Halloween...
at least until January.

-- 
The six phases of a project:
I. Enthusiasm. IV. Search for the Guilty.
II. Disillusionment.   V. Punishment of the Innocent.
III. Panic.VI. Praise & Honor for the Nonparticipants.

Re: [EMAIL PROTECTED]: [IP] more on U.S. passports to receive RFID implants start

[Roy M. Silvernail]

Tyler Durden wrote:

> One thing to think about with respect to the RFID passports...
>
> Um, uh...surely once in a while the RFID tag is going to get corrupted
> or something...right? I'd bet it ends up happening all the time. In
> those cases they probably have to fall back upon the traditional
> passport usage and inspection.
>
> The only question is, what could (believably) damage the RFID?

EMP?  Could be tuned, even, since the RFID is resonant at a known
frequency.  There's a standard for excitation field strength, so all one
should need to do would be hit the chip with 50-100x the expected
input.  Unless the system is shunted with a zener or some such, you
should be able to fry it pretty easily.

Now put that chip-cooker in a trash can right by the main entrance to an
airport and perform some public service.

-- 
Roy M. Silvernail is [EMAIL PROTECTED], and you're not
"It's just this little chromium switch, here." - TFT
Dspam->pprocmail->/dev/null->bliss
http://www.rant-central.com

Re: packet traffic analysis

[Travis H.]

> I assume that the length is
> explicitly encoded in the legitimate packet.  Then the peer for the
> link ignores everything until the next "escape sequence" introducing a
> legitimate packet.

I should point out that encrypting PRNG output may be pointless, and
perhaps one optimization is to stop encrypting when switching on the
chaff.  The peer can then encrypt the escape sequence as it would
appear in the encrypted stream, and do a simple string match on that. 
In this manner the peer does not have to do any decryption until the
[encrypted] escape sequence re-appears.  Another benefit of this is to
limit the amount of material encrypted under the key to legitimate
traffic and the escape sequences prefixing them.  Some minor details
involving resynchronizing when the PRNG happens to produce the same
output as the expected encrypted escape sequence is left as an
exercise for the reader.
--
http://www.lightconsulting.com/~travis/  -><-
"We already have enough fast, insecure systems." -- Schneier & Ferguson
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B

Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems

[cyphrpunk]

On 10/28/05, Daniel A. Nagy <[EMAIL PROTECTED]> wrote:
> Irreversibility of transactions hinges on two features of the proposed
> systetm: the fundamentally irreversible nature of publishing information in
> the public records and the fact that in order to invalidate a secret, one
> needs to know it; the issuer does not learn the secret at all in some
> implementnations and only learns it when it is spent in others.
>
> In both cases, reversal is impossible, albeit for different reasons. Let's
> say, Alice made a payment to Bob, and Ivan wishes to reverse it with the
> possible cooperation of Alice, but definitely without Bob's help. Alice's
> secret is Da, Bob's secret is Db, the corresponding challenges are,
> respectively, Ca and Cb, and the S message containing the exchange request
> Da->Cb has already been published.
>
> In the first case, when the secret is not revealed, there is simply no way to
> express reverslas. There is no S message with suitable semantics semantics,
> making it impossible to invalidate Db if Bob refuses to reveal it.

The issuer can still invalidate it even though you have not explicitly
defined such an operation. If Alice paid Bob and then convinces the
issuer that Bob cheated her, the issuer could refuse to honor the Db
deposit or exchange operation. From the recipient's perspective, his
cash is at risk at least until he has spent it or exchanged it out of
the system.

The fact that you don't have an "issuer invalidates cash" operation in
your system doesn't mean it couldn't happen. Alice could get a court
order forcing the issuer to do this. The point is that reversal is
technically possible, and you can't define it away just by saying that
the issuer won't do that. If the issuer has the power to reverse
transactions, the system does not have full ireversibility, even
though the issuer hopes never to exercise his power.


> In the second case, Db is revealed when Bob tries to spend it, so Ivan can,
> in principle, steal (confiscate) it, instead of processing, but at that
> point Da has already been revealed to the public and Alice has no means to
> prove that she was in excusive possession of Da before it became public
> information.

That is an interesting possibility, but I can think of a way around
it. Alice could embed a secret within her secret. She could base part
of her secret on a hash of an even-more-secret value which she would
not reveal when spending/exchanging. Then if it came to where she had
to prove that she was the proper beneficiary of a reversed
transaction, she could reveal the inner secret to justify her claim.


> Now, one can extend the list of possible S messages to allow for reversals
> in the first scenario, but even in that case Ivan cannot hide the fact of
> reversal from the public after it happened and the fact that he is prepared
> to reverse payments even before he actually does so, because the users and
> auditors need to know the syntax and the semantics of the additional S
> messages in order to be able to use Ivan's services.

That's true, the public visibility of the system makes secret
reversals impossible. That's very good - one of the problems with
e-gold was that it was never clear when they were reversing and
freezing accounts. Visibility is a great feature. But it doesn't keep
reversals from happening, and it still leaves doubt about how final
transactions will be in this system.

CP

Re: [EMAIL PROTECTED]: [IP] more on U.S. passports to receive RFID implants start

[Eugen Leitl]

On Sat, Oct 29, 2005 at 08:42:35PM -0400, Tyler Durden wrote:
> One thing to think about with respect to the RFID passports...
> 
> Um, uh...surely once in a while the RFID tag is going to get corrupted or 
> something...right? I'd bet it ends up happening all the time. In those 
> cases they probably have to fall back upon the traditional passport usage 
> and inspection.

Actually, an RFID can be ridiculously reliable. It will also
depend on how much harassment a traveler will be exposed to, 
when travelling. Being barred from entry will definitely prove
sufficient deterrment.
 
> The only question is, what could (believably) damage the RFID?

Microwaving it will blow up the chip, and cause a scorched spot.
Severing the antenna would be enough for the chip to become mute.
Violetwanding or treating with a Tesla generator should destroy
all electronics quite reliably -- you always have to check, of
course.

Also, the ID is quite expensive, and a frequent traveller
will wind up with a considerable expense, and hassle.

-- 
Eugen* Leitl http://leitl.org";>leitl
__
ICBM: 48.07100, 11.36820http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE


signature.asc
Description: Digital signature

Re: Return of the death of cypherpunks.

[John Kelsey]

>From: "James A. Donald" <[EMAIL PROTECTED]>
>Sent: Oct 28, 2005 12:09 PM
>To: [EMAIL PROTECTED]
>Subject: Return of the death of cypherpunks.

>From: Eugen Leitl <[EMAIL PROTECTED]>
..
>> The list needs not to stay dead, with some finite 
>> effort on our part (all of us) we can well resurrect 
>> it. If there's a real content there's even no need 
>> from all those forwards, to just fake a heartbeat.

>Since cryptography these days is routine and uncontroversial, there
>is no longer any strong reason for the cypherpunks list to continue
>to exist.

Well, political controversy seems like the least interesting thing
about the list--to the extent we're all babbling about who needs
killing and who's not a sufficiently pure
libertarian/anarchocapitalist and which companies are selling out to
the Man, the list is nothing special.  The cool thing is the
understanding of crypto and computer security techology as applied to
these concerns that are political.  And the coolest thing is getting
smart people who do real crypto/security work, and write working code,
to solve problems.  The ratio of political wanking to technical posts
and of talkers to thinkers to coders needs to be right for the list to
be interesting.  

..
>--digsig
> James A. Donald
> 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
> AnKV4N6f9DgtOy+KkQ9QsiXcpQm+moX4U09FjLXP
> 4zfMeSzzCXNSr737bvqJ6ccbvDSu8fr66LbLEHedb

--John Kelsey

Re: [EMAIL PROTECTED]: [IP] more on U.S. passports to receive RFID implants start

[Major Variola (ret)]

At 01:31 AM 10/30/05 -0700, Bill Stewart wrote:
>They've said they'll fall back on the traditional
>"If we can't read the passport it's invalid and you'll need to
>replace it before we'll let you leave the country" technique,
>just as they often do with expired passports and sometimes

What is the procedure (or are they secret :-) for passports which
become damaged whilst travelling out of country?

With a drivers license, if the magstrip doesn't work, they type
in the numbers.  But the biometrics are not encoded, its just
a convenience.  With a passport, they're relying on the
chip or no?

(Mechanical damage to the chip should work as well as
RF or antenna damage.  You will have to find the chip
and crack it, mere flexing of the paper carrier doesn't work
by design.)

Re: Multiple passports?

[Bill Stewart]

When I saw the title of this thread,
I was assuming it would be about getting Mozambique
or Sealand or other passports of convenience or coolness-factor
like the Old-School Cypherpunks used to do :-)


On 10/30/05, Gregory Hicks <[EMAIL PROTECTED]> wrote:
> The only people that I knew that had two passports were those with an
> "Official" (red) passport or a "Diplomatic" (black) passport.  If they
> wanted to go play tourist, they had to also have a "tourist" (Blue)
> passport.


A few years ago, before heading on an overseas trip,
I was unable to locate my current passport.
After dealing with a voicemail system adapted from a Kafka novel,
and bringing myself, my previous expired passport and other id,
a couple official-sized photographs and cash through the
secret-handshake elevator into a big waiting room for a long morning,
they made me a new passport.   (If you need to replace a passport
more than a month before your planned travel,
you're supposed to use the regular process at the Post Office
and maybe pay extra for Express Mail if you're impatient.
If you need to replace a passport within 3 days of travel,
they've got expedited processes at major passport offices like San Francisco.
But if you need to replace your passport two weeks before the trip,
there's no way to talk to a human being, just Kafka's voicemailbot,
so you have to wait until 3 days before the trip
to get an appointment for the emergency expedited process
instead of going in when you and they aren't busy :-)

They informed me that the lost passport was now invalid
and I should turn it in if I find it, because if I were to use it
to get back into the country it would be rejected with extreme prejudice,
since its number is now on the "lost passports" list.
Of course the next day when I was packing,
the passport showed up on the closet floor under the suitcase,
and unlike the previous passport which I took in to replace
when it was about to expire, it doesn't have holes
punched in it and Expired stamped on it.

For domestic air travel since the recent military coup,
I normally bring a passport as ID, since it's a request from the
former United States government asking foreign governments
like the current TSA White People to let me pass,
and I'd rather carry the technically-invalid one with me
instead of the valid one just in case I lose it.
I think I've also used it to travel from the EU back to the US,
but I'd expect that the La Migra thugs will
eventually improve their databases, possibly even before my old one expires,
especially because Homeland Security wants to RFIDize us.

I was considering "losing" my current passport before the
RFID things get started, but it doesn't look like there's time,
so I've got about 5 years to hope that the Republicans get
thrown out on their asses in the next election and the
Democrats decide that returning to the Constitution will sell better
than continuing the Permanent State of Yellowalertness.
Given the previous Clinton Administration's behavior,
I don't expect the Hillary Clinton Administration to do any better.


At 09:27 PM 10/29/2005, Jay Goodman Tamboli wrote:
I wasn't able to find a reference to support this on http://state.gov,
but I know it's possible to get two passports if you plan to travel to
both Israel and a country that refuses to admit people with Israeli
stamps in their passports.


I don't think the US normally lets you have two passports,
or if they do they almost certainly have the same number.
But at least during the 1980s, Israel would be happy to give you
a separate piece of paper with to carry with your passport that
they'd stamp when you entered and left instead of stamping the
passport itself.  I don't remember if I did that or if I decided
not to worry about it because I'd visited the Arab countries
before going to Israel and didn't expect to get back any time soon.

RE: [EMAIL PROTECTED]: Skype security evaluation]

[Whyte, William]

A similar approach enabled Bleichenbacher's SSL attack on 
RSA with PKCS#1 padding. This sounds very dangerous to me.

William 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of cyphrpunk
> Sent: Friday, October 28, 2005 5:07 AM
> To: [EMAIL PROTECTED]; cryptography@metzdowd.com
> Subject: Re: [EMAIL PROTECTED]: Skype security evaluation]
> 
> Wasn't there a rumor last year that Skype didn't do any encryption
> padding, it just did a straight exponentiation of the plaintext?
> 
> Would that be safe, if as the report suggests, the data being
> encrypted is 128 random bits (and assuming the encryption exponent is
> considerably bigger than 3)? Seems like it's probably OK. A bit risky
> perhaps to ride bareback like that but I don't see anything inherently
> fatal.
> 
> CP
> 
> -
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to 
> [EMAIL PROTECTED]
> 
> 

AW: [EMAIL PROTECTED]: Skype security evaluation]

[Kuehn, Ulrich]

> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] Im Auftrag von cyphrpunk
> Gesendet: Freitag, 28. Oktober 2005 06:07
> An: [EMAIL PROTECTED]; cryptography@metzdowd.com
> Betreff: Re: [EMAIL PROTECTED]: Skype security evaluation]
> 
> Wasn't there a rumor last year that Skype didn't do any 
> encryption padding, it just did a straight exponentiation of 
> the plaintext?
>
> Would that be safe, if as the report suggests, the data being 
> encrypted is 128 random bits (and assuming the encryption 
> exponent is considerably bigger than 3)? Seems like it's 
> probably OK. A bit risky perhaps to ride bareback like that 
> but I don't see anything inherently fatal.
> 
There are results available on this issue: First, a paper by 
Boneh, Joux, and Nguyen "Why Textbook ElGamal and RSA Encryption 
are Insecure", showing that you can essentially half the number 
of bits in the message, i.e. in this case the symmetric key 
transmitted. 

Second, it turns out that the tricky part is the implementation 
of the decryption side, where the straight-forward way -- ignoring 
the padding with 0s "They are zeroes, aren't they?" -- gives you a 
system that might be attacked in a chosen plaintext scenario very 
efficiently, obtaining the symmetric key. See my paper "Side-Channel 
Attacks on Textbook RSA and ElGamal Encryption" at PKC2003 for 
details.

Hope this answers your question.

Ulrich