Philipp Gühring wrote:
I had the feeling that Microsoft wants to abandon the usage of client
certificates completely, and move the people to CardSpace instead.
But how do you sign your emails with CardSpace? CardSpace only does the
realtime authentication part of the market ...
It's not rocket
Thierry Moreau <[EMAIL PROTECTED]> writes:
>At first, it seems neat. But then, looking at how it works in practice: the
>client receives an e-mail notification soliciting him to click on a HTML link
>and then enroll for a security certificate, the client is solicited exactly
>like a phishing crimi
Leichter, Jerry wrote:
While trying to find something else, I came across the following
reference:
Title: Sender driven certification enrollment system
Document Type and Number: United States Patent 6651166
Link to this page: http://www.freepatentsonline.com/665116
Is anyone aware of any third-party usability studies on CardSpace,
OpenID, ...?).
I'm not. It would be a good opportunity for security usability
researchers to contribute though.
[0] I'm not sure whether putting "CardSpace" and "Liberty" in such close
proximity in the above line was a
Imagine if a website could instruct your browser to transparently
generate a public/private keypair for use with that website only and
send the public key to that website. Then, any time that the user
returns to that website, the browser would automatically use that
private key to authentica
Philipp =?iso-8859-1?q?G=FChring?= <[EMAIL PROTECTED]> writes:
>I had the feeling that Microsoft wants to abandon the usage of client
>certificates completely, and move the people to CardSpace instead.
While there's an obvious interpretation of that ("Microsoft want to lock
everyone into CardSpac
On Feb 11, 2008, at 8:28 AM, Philipp Gühring wrote:
I had the feeling that Microsoft wants to abandon the usage of client
certificates completely, and move the people to CardSpace instead.
But how do you sign your emails with CardSpace? CardSpace only does
the
realtime authentication part of
Hi,
> Microsoft broke this in IE7... It is no longer possible to generate and
> enroll a client cert from a CA not on the trusted root list. So private
> label CAs can no longer enroll client certs. We have requested a fix,
> so this may come in the future, but the damage is already done...
>
> Al
> "Werner" == Werner Koch <[EMAIL PROTECTED]> writes:
Werner> The last time I checked the Mozilla code they used their own crypto
Werner> stuff. When did they switched to OpenSSL and how do they solve the
Werner> GPL/OpenSSL license incompatibility?
Indeed they do. It is called nss, is avai
On Sun, Feb 10, 2008 at 07:27:28PM +0100, Werner Koch wrote:
> On Thu, 7 Feb 2008 16:37, [EMAIL PROTECTED] said:
>
> > I don't have any idea why or why not, but all they can release now is
> > source code with #ifdef openssl >= 0.9.9 ... do PSK stuff ... #endif,
>
> The last time I checked the
On Thu, 7 Feb 2008 16:37, [EMAIL PROTECTED] said:
> I don't have any idea why or why not, but all they can release now is
> source code with #ifdef openssl >= 0.9.9 ... do PSK stuff ... #endif,
The last time I checked the Mozilla code they used their own crypto
stuff. When did they switched to
Peter Gutmann wrote:
Victor Duchovni <[EMAIL PROTECTED]> writes:
While Firefox should ideally be developing and testing PSK now, without
stable libraries to use in servers and browsers, we can't yet expect anything
to be released.
Is that the FF devlopers' reason for holding back? Just wonde
Peter Gutmann wrote:
There's always the problem of politics. You'd think that support for a free
CA like CAcert would also provide fantastic marketing opportunities for free
browser like Firefox, but this seems to be stalled pretty much idefinitely
because since CAcert doesn't charge for certif
| By the way, it seems like one thing that might help with client certs
| is if they were treated a bit like cookies. Today, a website can set
| a cookie in your browser, and that cookie will be returned every time
| you later visit that website. This all happens automatically. Imagine
| if a we
re:
http://www.garlic.com/~lynn/aadsm28.htm#30 Fixing SSL
so lots of the AADS
http://www.garlic.com/~lynn/x959.html#aads
scenarios are that every place a password might appear, have
a public key instead.
for various of the cookie authentication operations ... also
think kerberos tickets. recent
Steven M. Bellovin wrote:
> There's another issue: initial account setup. [Even
> with SRP] people will still need to rely on
> certificate-checking for that. It's a real problem at
> some hotspots, where Evil Twin attacks are easy and
> lots of casual users are signing up for the first
> time.
On Sat, Feb 09, 2008 at 05:04:28PM -0800, David Wagner wrote:
> By the way, it seems like one thing that might help with client certs
> is if they were treated a bit like cookies. Today, a website can set
> a cookie in your browser, and that cookie will be returned every time
> you later visit th
On 2/9/08, David Wagner <[EMAIL PROTECTED]> wrote:
> By the way, it seems like one thing that might help with client certs
> is if they were treated a bit like cookies.
I don't see how this helps with phishing. Phishers will just go after
the password or other secrets used to authenticate a new sy
David Wagner <[EMAIL PROTECTED]> writes:
>Tim Dierks writes:
>>(there are totally different reasons that client certs aren't being
>>widely adopted, but that's beside the point).
>
>I'd be interested in hearing your take on why SSL client certs aren't widely
>adopted.
Because they're essentially u
ww.garlic.com/~lynn/aadsm28.htm#20 Fixing SSL (was Re: Dutch
Transport Card Broken)
http://www.garlic.com/~lynn/aadsm28.htm#24 Fixing SSL (was Re: Dutch
Transport Card Broken)
http://www.garlic.com/~lynn/aadsm28.htm#26 Fixing SSL (was Re: Dutch
Transport Card Broken)
--
Tim Dierks writes:
>(there are totally different reasons that client certs aren't being
>widely adopted, but that's beside the point).
I'd be interested in hearing your take on why SSL client certs aren't
widely adopted. It seems like they could potentially help with the
phishing problem (at leas
On Thu, Feb 07, 2008 at 08:47:20PM +1300, Peter Gutmann wrote:
> Victor Duchovni <[EMAIL PROTECTED]> writes:
>
> >While Firefox should ideally be developing and testing PSK now, without
> >stable libraries to use in servers and browsers, we can't yet expect anything
> >to be released.
>
> Is tha
Victor Duchovni <[EMAIL PROTECTED]> writes:
>While Firefox should ideally be developing and testing PSK now, without
>stable libraries to use in servers and browsers, we can't yet expect anything
>to be released.
Is that the FF devlopers' reason for holding back? Just wondering... why not
releas
"Steven M. Bellovin" <[EMAIL PROTECTED]> writes:
>There's another issue: initial account setup. People will still need to rely
>on certificate-checking for that. It's a real problem at some hotspots,
>where Evil Twin attacks are easy and lots of casual users are signing up for
>the first time.
On Thu, 07 Feb 2008 17:37:02 +1300
[EMAIL PROTECTED] (Peter Gutmann) wrote:
> The real issues occur in two locations:
>
> 1. In the browser UI.
> 2. In the server processing, which no longer gets the password via an
> HTTP POST but as a side-effect of the TLS connect.
>
> (1) is a one-off cost f
Frank Siebenlist <[EMAIL PROTECTED]> writes:
>With the big browser war still going strong, wouldn't that provide fantastic
>marketing opportunities for Firefox?
There's always the problem of politics. You'd think that support for a free
CA like CAcert would also provide fantastic marketing oppor
"James A. Donald" <[EMAIL PROTECTED]> writes:
>However, seems to me that logging into the website using SRP is a non trivial
>refactoring, and not just a matter of dropping in TLS-SRP as a simple
>replacement of TLS-DSA-X509
I've discussed this with (so far) a small sample of assorted corporate T
On Wed, Feb 06, 2008 at 09:21:47AM -0800, Frank Siebenlist wrote:
> With the big browser war still going strong, wouldn't that provide
> fantastic marketing opportunities for Firefox?
>
> If Firefox would support these secure password protocols, and the banks
> would openly recommend their cust
a recent reference
Research unmasks anonymity networks
http://www.techworld.com/security/news/index.cfm?newsID=11295
Research unmasks anonymity networks
http://www.networkworld.com/news/2008/020108-research-unmasks-anonymity.html
Research unmasks anonymity networks
http://www.arnnet.com.au/index.
Peter Gutmann wrote:
Frank Siebenlist <[EMAIL PROTECTED]> writes:
That's actually a sad observation.
I keep telling my colleagues that this technology is coming "any day now" to
a browser near you - didn't realize that that there was no interest with the
browser companies to add support for th
On Tue, Feb 05, 2008 at 08:17:32AM +1000, James A. Donald wrote:
> Nicolas Williams wrote:
> > Sounds a bit like SCTP, with crypto thrown in.
>
> SCTP is what we should have done http over, though of
> course SCTP did not exist back then. Perhaps, like
> quite a few other standards, it still does
Nicolas Williams wrote:
> Sounds a bit like SCTP, with crypto thrown in.
SCTP is what we should have done http over, though of
course SCTP did not exist back then. Perhaps, like
quite a few other standards, it still does not quite
exist.
> I thought it was the latency cause by unnecessary
> rou
Frank Siebenlist <[EMAIL PROTECTED]> writes:
>That's actually a sad observation.
>
>I keep telling my colleagues that this technology is coming "any day now" to
>a browser near you - didn't realize that that there was no interest with the
>browser companies to add support for this...
I know of a
On Feb 1, 2008, at 9:34 PM, Ian G wrote:
* Browser vendors don't employ security people as we know them on
this mailgroup [...] But they are completely at sea when it comes
to systemic security failings or designing new systems.
I don't know about other browsers, but Mozilla's CSO-type is W
"Steven M. Bellovin" <[EMAIL PROTECTED]> writes:
>On Fri, 01 Feb 2008 13:29:52 +1300
>[EMAIL PROTECTED] (Peter Gutmann) wrote:
>> Actually it doesn't even require X.509 certs. TLS-SRP and TLS-PSK
>> provide mutual authentication of client and server without any use of
>> X.509. The only problem h
StealthMonger wrote:
> They can't be as "anonymous as cash" if the party
> being dealt with can be identified. And the party can
> be identified if the transaction is "online,
> real-time". Even if other clues are erased, there's
> still traffic analysis in this case.
>
> What the offline paradi
On Sun, Feb 03, 2008 at 09:24:48PM +1000, James A. Donald wrote:
> Nicolas Williams wrote:
> >What, specifically, are you proposing?
>
> I am still writing it up.
>
> > Running the web over UDP?
>
> In a sense.
>
> That should have been done from the beginning, even before security
> became a
>They can't be as "anonymous as cash" if the party being dealt with
>can be identified. And the party can be identified if the
>transaction is "online, real-time". Even if other clues are erased,
>there's still traffic analysis in this case.
If I show up at a store and pay cash for something eve
StealthMonger wrote:
They can't be as "anonymous as cash" if the party being dealt with can
be identified. And the party can be identified if the transaction is
"online, real-time". Even if other clues are erased, there's still
traffic analysis in this case.
What the offline paradigm has goin
At 09:34 PM 2/1/2008 +0100, Ian G wrote:
* Browser vendors don't employ security people as we know them on this
mailgroup, they employ cryptoplumbers. Completely different layer. These
people are mostly good (and often very good) at fixing security bugs. We
thank them for that! But they are
Anne & Lynn Wheeler <[EMAIL PROTECTED]> write:
> one of my favorite exchanges from the mid-90s was somebody claiming
> that adding digital certificates to the electronic payment
> transaction infrastructure would bring it into the modern age. my
> response was that it actually would regress the i
On Thu, Jan 31, 2008 at 11:12:45PM -0500, Victor Duchovni wrote:
> On Fri, Feb 01, 2008 at 01:15:09PM +1300, Peter Gutmann wrote:
> > If anyone's interested, I did an analysis of this sort of thing in an
> > unpublished draft "Performance Characteristics of Application-level Security
> > Protocols"
Frank Siebenlist wrote:
Why do the browser companies not care?
I spent a few years trying to interest (at least) one
browser vendor with looking at new security problems
(phishing) and using the knowledge that we had to solve this
(opportunistic cryptography). No luck whatsoever. My view
On Fri, Feb 01, 2008 at 07:58:16PM +, Steven M. Bellovin wrote:
> On Fri, 01 Feb 2008 13:29:52 +1300
> [EMAIL PROTECTED] (Peter Gutmann) wrote:
> > (Anyone have any clout with Firefox or MS? Without significant
> > browser support it's hard to get any traction, but the browser
> > vendors are
On Fri, 01 Feb 2008 13:29:52 +1300
[EMAIL PROTECTED] (Peter Gutmann) wrote:
> Actually it doesn't even require X.509 certs. TLS-SRP and TLS-PSK
> provide mutual authentication of client and server without any use of
> X.509. The only problem has been getting vendors to support it,
> several sma
Peter Gutmann wrote:
"Perry E. Metzger" <[EMAIL PROTECTED]> writes:
SSL involves digital certificates.
Not really, James Donald/George W. Bush. It involves public keys, and it
provides a channel by which X.509 certificates can be exchanged,
Actually it doesn't even require X.509 certs. TLS-
On Fri, Feb 01, 2008 at 06:24:25PM +1000, James A. Donald wrote:
> You are asking for a layered design that works better than the existing
> layered design. My claim is that you get an additional round trip for
> each layer - which your examples have just demonstrated.
>
> SSL has to be on top
Ian G wrote:
The PII equation is particularly daunting, echoing Lynn's early '90s
experiences. I am told (but haven't really verified) that the
certificate serial number is PII and therefore falls under the full
weight of privacy law & regs ... this may sound ludicrous, but privacy
and securi
Nicolas Williams wrote:
I don't have one that exists today and is practical. But we can
certainly imagine possible ways to improve this situation: move parts of
TLS into TCP and/or IPsec. There are proposals that come close enough
to this (see the last IETF SAAG meeting's proceedings, see the I
>> (as if anyone uses client certificates anyway)?
>>
>
> Guess why so few people are using it ...
> If it were secure, more people would be able to use it.
>
>
People don't use it because the workload of getting signed up is vastly
beyond their skillset, and the user experience using the
Victor Duchovni wrote:
Jumping in late, but the idea that *TCP* (and not TLS protocol design)
adds round-trips to SSL warrants some evidence (it is very temping to
express this skepticism more bluntly).
With unextended SMTP for example, the minimum RTT count is:
0. SYN SYN-ACK
On Fri, Feb 01, 2008 at 01:15:09PM +1300, Peter Gutmann wrote:
> Victor Duchovni <[EMAIL PROTECTED]> writes:
>
> >Jumping in late, but the idea that *TCP* (and not TLS protocol design) adds
> >round-trips to SSL warrants some evidence (it is very temping to express this
> >skepticism more bluntly
Eric Rescorla wrote:
(as if anyone uses client certificates anyway)?
Guess why so few people are using it ...
If it were secure, more people would be able to use it.
No, if it were *convenient* people would use it. I know of absolutely
zero evidence (nor have you presented any) that people ch
"Perry E. Metzger" <[EMAIL PROTECTED]> writes:
>> SSL involves digital certificates.
>
>Not really, James Donald/George W. Bush. It involves public keys, and it
>provides a channel by which X.509 certificates can be exchanged,
Actually it doesn't even require X.509 certs. TLS-SRP and TLS-PSK pro
Victor Duchovni <[EMAIL PROTECTED]> writes:
>Jumping in late, but the idea that *TCP* (and not TLS protocol design) adds
>round-trips to SSL warrants some evidence (it is very temping to express this
>skepticism more bluntly).
If anyone's interested, I did an analysis of this sort of thing in an
Dave Howe <[EMAIL PROTECTED]> writes:
>SSL - Cludge thrown together by a browser manufacturer,
To paraphrase Winston Churchill, "SSL is the worst secure-pipe protocol,
except for all the others". Like most people here, I can find assorted nits
to pick with it (mostly message-formatting stuff and
tion setup. Everything else is SMTP not TCP, and running
SMTP over UDP (with ideal conditions and no lost packets, ...) would
save just 1 RTT.
re:
http://www.garlic.com/~lynn/aadsm28.htm#21 Dutch Transport Card Broken
sorry, I didn't say that TCP required seven round-trips for reliable
On Wed, Jan 30, 2008 at 02:47:46PM -0500, Victor Duchovni wrote:
> If someone has a faster than 3-way handshake connection establishment
> protocol that SSL could leverage instead of TCP, please explain the
> design.
I don't have one that exists today and is practical. But we can
certainly imagin
On Thu, Jan 31, 2008 at 02:28:30PM -0500, Anne & Lynn Wheeler wrote:
> TCP requires minimum of seven message exchange for reliable transport
> VMTP (rfc 1045) got that down to minimum of five messages, and XTP
> then
> got it down to three messages minimum for reliable transport (disclaimer
On Jan 30, 2008 9:04 PM, Philipp Gühring <[EMAIL PROTECTED]> wrote:
> Hi,
>
> > Huh? What are you claiming the problem with sending client certificates
> > in plaintext is
>
> * It´s a privacy problem
> * It´s a security problem for people with a security policy that requires
> the
> their identit
4. ... stream of message content segments
250
re:
http://www.garlic.com/~lynn/aadsm28.htm#15 Dutch Transport Card Broken
http://www.garlic.com/~lynn/aadsm28.htm#16 Dutch Transport Card Broken
http://www.garlic.com/~lynn/aadsm28.htm#20 Fixing SSL (was
enero de 2008 3:04
Para: Eric Rescorla
CC: Cryptography; Rasika Dayarathna
Asunto: Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Hi,
> Huh? What are you claiming the problem with sending client certificates
> in plaintext is
* It´s a privacy problem
* It´s a security problem for pe
"James A. Donald" <[EMAIL PROTECTED]> writes:
> Perry E. Metzger wrote:
>> (No, I'm not a fan of X.509 certs, but those are not
>> core to the protocol, and you can think of them as
>> nothing more than a fancy key container format if you
>> like. Key management is not addressed by SSL, so there
>
Philipp Gühring wrote:
Hi,
SSL key distribution and management is horribly broken,
with the result that everyone winds up using plaintext
when they should not.
Yes, sending client certificates in plaintext while claiming that SSL/TLS is
secure doesn´t work in a world of phishing and iden
At Thu, 31 Jan 2008 03:04:00 +0100,
Philipp Gühring wrote:
>
> Hi,
>
> > Huh? What are you claiming the problem with sending client certificates
> > in plaintext is
>
> * It´s a privacy problem
> * It´s a security problem for people with a security policy that requires the
> their identities t
Hi,
> Huh? What are you claiming the problem with sending client certificates
> in plaintext is
* It´s a privacy problem
* It´s a security problem for people with a security policy that requires the
their identities to be kept secret, and only to be used to authenticate to
the particular serve
Perry E. Metzger wrote:
> (No, I'm not a fan of X.509 certs, but those are not
> core to the protocol, and you can think of them as
> nothing more than a fancy key container format if you
> like. Key management is not addressed by SSL, so there
> is no reason that fixing key management has anythin
Eric Rescorla wrote:
> Huh? What are you claiming the problem with sending
> client certificates in plaintext is (as if anyone uses
> client certificates anyway)?
Well that is one problem - no one uses them, and no one
should use them, while PKI was designed under the
assumption that everyone wou
On Wed, Jan 30, 2008 at 06:08:37PM -, Dave Korn wrote:
> On 30 January 2008 17:01, Jim Cheesman wrote:
>
> > James A. Donald:
> SSL is layered on top of TCP, and then one layers
> one's actual protocol on top of SSL, with the result
> that a transaction involves a painfully lar
Philipp Gühring wrote:
I once implemented SSL over GSM data channel (without PPP and without
TCP), and discovered that SSL needs better integrity protection than
raw GSM delivers. (I am quite sure that´s why people normally run PPP
over GSM channels ...) SSH has the same problems. It also assumes
On 30 January 2008 17:03, Perry E. Metzger wrote:
> My main point here was, in fact, quite related to yours, and one that
> we make over and over again -- innovation in such systems for its own
> sake is also not economically efficient or engineering smart.
Hear hear! This maxim should be bur
On 30 January 2008 17:01, Jim Cheesman wrote:
> James A. Donald:
SSL is layered on top of TCP, and then one layers
one's actual protocol on top of SSL, with the result
that a transaction involves a painfully large number
of round trips.
>
> Richard Salz wrote:
> > Perhaps the
At Wed, 30 Jan 2008 17:59:51 -,
Dave Korn wrote:
>
> On 30 January 2008 17:03, Eric Rescorla wrote:
>
>
> >>> We really do need to reinvent and replace SSL/TCP,
> >>> though doing it right is a hard problem that takes more
> >>> than morning coffee.
> >>
> >> TCP could need some stronger in
On 30 January 2008 17:03, Eric Rescorla wrote:
>>> We really do need to reinvent and replace SSL/TCP,
>>> though doing it right is a hard problem that takes more
>>> than morning coffee.
>>
>> TCP could need some stronger integrity protection. 8 Bits of checksum isn´t
>> enough in reality. (1 ou
scratch and replacing SSL makes much sense,
since it´s just one huge flaw ...)
re:
http://www.garlic.com/~lynn/aadsm28.htm#15 Dutch Transport Card Broken
http://www.garlic.com/~lynn/aadsm28.htm#16 Dutch Transport Card Broken
aka ... that was part of the relying-party-only certificates from the
> Folks on this list and its progenitors have long noted that
cryptography is a matter of economics.
Agreed, but using an insecure technology doesn't make sense from even an
economic perspective. They spent enough money that they could have
implemented a secure system, but instead, made two fund
"James A. Donald" <[EMAIL PROTECTED]> writes:
> James A. Donald:
>>> SSL is layered on top of TCP, and then one layers
>>> one's actual protocol on top of SSL, with the result
>>> that a transaction involves a painfully large number
>>> of round trips.
>
> Richard Salz wrote:
>> Perhaps theoretica
I don't disagree with your posting in general. I will note one thing:
"Steven M. Bellovin" <[EMAIL PROTECTED]> writes:
> A transit system has to move people. For all that the New York City
> Metrocard works, it's slower than a contactless wireless system.
As a consultant, I happen to have a lot
At Wed, 30 Jan 2008 11:25:04 +0100,
Philipp Gühring wrote:
>
> Hi,
>
> > SSL key distribution and management is horribly broken,
> > with the result that everyone winds up using plaintext
> > when they should not.
>
> Yes, sending client certificates in plaintext while claiming that SSL/TLS is
James A. Donald:
> >> SSL is layered on top of TCP, and then one layers
> >> one's actual protocol on top of SSL, with the result
> >> that a transaction involves a painfully large number
> >> of round trips.
Richard Salz wrote:
> Perhaps theoretically painful, but in practice this is
> not the
At Wed, 30 Jan 2008 09:04:37 +1000,
James A. Donald wrote:
>
> Ivan Krstic' wrote:
> > Some number of these muppets approached me over the
> > last couple of years offering to donate a free license
> > for their excellent products. I used to be more polite
> > about it, but nowadays I ask that
Hi,
> SSL key distribution and management is horribly broken,
> with the result that everyone winds up using plaintext
> when they should not.
Yes, sending client certificates in plaintext while claiming that SSL/TLS is
secure doesn´t work in a world of phishing and identity theft anymore.
We h
James A. Donald:
>> SSL is layered on top of TCP, and then one layers
>> one's actual protocol on top of SSL, with the result
>> that a transaction involves a painfully large number
>> of round trips.
Richard Salz wrote:
> Perhaps theoretically painful, but in practice this is
> not the case; com
> SSL is layered on top of TCP, and then one layers one's
> actual protocol on top of SSL, with the result that a
> transaction involves a painfully large number of round
> trips.
Perhaps theoretically painful, but in practice this is not the case;
commerce on the web is the counter-example. The
> Why require contactless in the first place?
>
> Is swiping one's card, credit-card style too difficult for the average
> user? I'm thinking two parallel copper traces on the card could be
> used to power it for the duration of the swipe, with power provided
> by the reader. Why, in a billion-
Ivan Krstic' wrote:
> Some number of these muppets approached me over the
> last couple of years offering to donate a free license
> for their excellent products. I used to be more polite
> about it, but nowadays I ask that they Google the
> famous Gutmann Sound Wave Therapy[0] and mail me
> after
Harald Koch <[EMAIL PROTECTED]> writes:
> Crawford Nathan-HMGT87 wrote:
>> Why require contactless in the first place?
>>
>> Is swiping one's card, credit-card style too difficult for the average
>> user?
>
> As compared to slapping your wallet on the reader? yes.
>
> I swipe my Visa / debit / Tim
Crawford Nathan-HMGT87 wrote:
Why require contactless in the first place?
Is swiping one's card, credit-card style too difficult for the average
user?
As compared to slapping your wallet on the reader? yes.
I swipe my Visa / debit / Tim Horton's cards regularly. With the
plethora of bad read
M
To: Aram Perez
Cc: Cryptography
Subject: Re: Dutch Transport Card Broken
> Not to defend the designers in any way or fashion, but I'd like to
> ask, How much security can you put into a plastic card, the size of a
> credit card, that has to perform its function in a secure man
On Jan 25, 2008, at 4:27 PM, Perry E. Metzger wrote:
However, you should be very skeptical when someone claims that they
"need" to use a home grown crypto algorithm or that they "need" to
use a home grown protocol instead of
a well proven one.
I'm beginning to suspect that more often than
Not to defend the designers in any way or fashion, but I'd like to ask,
How much security can you put into a plastic card, the size of a credit
card, that has to perform its function in a secure manner, all in under
2 seconds (in under 1 second in parts of Asia)? And it has to do this
while rec
The per-card cost need not be such a big problem. Singapore has a
proximity-card-based system. They use the same card both for the
long-term cards and for the single-use cards. There is a S$ 2 (IIRC)
deposit on the card, which is refunded after the card is used. Waste
not want not!
/ji
-
t's failed so spectacularly
here...
Regards,
Jim Cheesman
-Mensaje original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
En nombre de Aram Perez
Enviado el: viernes, 25 de enero de 2008 5:59
Para: Cryptography
Asunto: Re: Dutch Transport Card Broken
Hi Folks,
> Ed Felten has an in
Moin,
Am Thu, 24 Jan 2008 20:58:38 -0800 schrieb Aram Perez:
> Not to defend the designers in any way or fashion, but I'd like to
> ask, How much security can you put into a plastic card, the size of
> a credit card, that has to perform its function in a secure manner,
> all in under 2 seconds
Aram Perez wrote:
Not to defend the designers in any way or fashion, but I'd like to
ask, How much security can you put into a plastic card, the size of a
credit card, that has to perform its function in a secure manner, all
in under 2 seconds (in under 1 second in parts of Asia)? And it has to
my impression has been that with lack of takeup of various kinds of security
solutions that were extensively marketed in the 90s ... that the current
situation has many of those same organizations heavily involved in behind
the scenes lobbying
saw some of that nearly a decade ago when we were bro
> How much security can you put into a plastic card, the size of a
> credit card, that has to perform its function in a secure manner, all
> in under 2 seconds (in under 1 second in parts of Asia)? And it has to
> do this while receiving its power via the electromagnetic field being
> generated by
Aram Perez <[EMAIL PROTECTED]> writes:
>> Ed Felten has an interesting post on his blog about a Dutch smartcard
>> based transportation payment system that has been broken. Among other
>> foolishness, the designers used a custom cryptosystem and 48 bit keys.
>
> Not to defend the designers in any
Hi Folks,
Ed Felten has an interesting post on his blog about a Dutch smartcard
based transportation payment system that has been broken. Among other
foolishness, the designers used a custom cryptosystem and 48 bit keys.
Not to defend the designers in any way or fashion, but I'd like to
ask,
Perry E. Metzger wrote:
Ed Felten has an interesting post on his blog about a Dutch smartcard
based transportation payment system that has been broken. Among other
foolishness, the designers used a custom cryptosystem and 48 bit keys.
http://www.freedom-to-tinker.com/?p=1250
The Dutch governme
1 - 100 of 101 matches
Mail list logo
