On 09/30/13 04:41, ianG wrote:
Experience suggests that asking a standards committee to do the encoding format
is a disaster.
I just looked at my code, which does something we call Wire, and it's 700 loc.
Testing code is about a kloc I suppose. Writing reference implementations is a
piece
We had been asked to come in and help wordsmith the cal. state digital signature act. Several of
the parties were involved in privacy issues and also working on Cal. data breach notification act
and Cal. opt-in personal information sharing act. The parties had done extensive public surveys on
note when the router hughes references was 1st introduced in in IETF gateway
committee meeting as VPN it caused lots of turmoil in the IPSEC camp as well as
with the other router vendors. The other router vendors went into standards
stall mode ... their problem was none of them had a product
On 09/07/13 05:19, ianG wrote:
If so, then the domain owner can deliver a public key with authenticity using
the DNS.
This strikes a deathblow to the CA industry. This threat is enough for CAs to
spend a significant amount
of money slowing down its development [0].
unfortunately as far as
we were brought in as consultants to a small client/server startup that wanted to do payment transactions on
their server, they had this technology they called SSL they wanted to use, the result is now
frequently called electronic commerce. The two people at the startup responsible for the
recent post with email discussing PGP-like implementation ... a decade before
PGP in financial crypto blog
http://www.garlic.com/~lynn/2013i.html#69
and then a little later realizing there were 3-kinds of crypto (when I was told
I could make as many boxes as I wanted ... but could only sell to
On 08/26/2010 06:38 AM, d...@geer.org wrote:
While I am *not* arguing that point, per se, if having a
better solution would require, or would have required, no
more investment than the accumulated profits in the sale
of SSL domain name certs, we could have solved this by now.
the profit from
On 08/25/2010 10:40 PM, James A. Donald wrote:
This is inherent in the layering approach - inherent in our current crypto
architecture.
one of the things ran into the (ISO chartered) ANSI X3S3.3 (responsible for
standards
related to OSI level3 level4) meetings with regard to standardization
On 08/25/2010 09:04 AM, Richard Salz wrote:
Also, note that HSTS is presently specific to HTTP. One could imagine
expressing a more generic STS policy for an entire site
A really knowledgeable net-head told me the other day that the problem
with SSL/TLS is that it has too many round-trips. In
On 08/13/2010 03:16 PM, Chris Palmer wrote:
When was this *ever* true? Seriously.
re:
http://www.garlic.com/~lynn/2010m.html#50
... original design/implementation. The very first commerce server
implementation
by the small client/server startup (that had also invented SSL) ... was mall
On 08/13/2010 02:12 PM, Jon Callas wrote:
What on earth happened? Was there a change in banking regulations in the last
few months?
Possibly it's related to PCI DSS and other work that BITS has been doing. Also,
if one major player cleans up their act and sings about how cool they are, then
Zeus malware used pilfered digital certificate
http://www.computerworld.com/s/article/9180259/Zeus_malware_used_pilfered_digital_certificate
Zeus Malware Used Pilfered Digital Certificate
http://www.pcworld.com/businesscenter/article/202720/zeus_malware_used_pilfered_digital_certificate.html
Kaspersky: Sham Certificates Pose Big Problem for Windows Security
http://www.ecommercetimes.com/story/70553.html
from above ..
Windows fails to clearly indicate when digital security certificates have been
tampered with, according to Kaspersky Lab's Roel Schouwenberg, and that
opens a door for
On 08/01/2010 01:51 PM, Jeffrey I. Schiller wrote:
I remember them well. Indeed these protocols, presumably you are
talking about Secure Electronic Transactions (SET), were a major
improvement over SSL, but adoption was killed by not only failing the
give the merchants a break on the fraud
minor addenda about speeds feeds concerning the example of mid-90s payment
protocol specification that had enormous PKI/certificate bloat ... and SSL.
The original SSL security was predicated on the user understanding the
relationship between the webserver they thought they were talking to,
On 07/28/2010 08:55 AM, Anne Lynn Wheeler wrote:
disclaimer: the inventor of domain name infrastructure did a stint at the
science center a decade earlier
... working on various and sundry projects.
other public key science center trivia; former RSA CEO also at science center
corollary to security proportional to risk is parameterized risk management
... where variety of technologies with varying integrity levels can co-exist within the same
infrastructure/framework. transactions exceeding particularly technology risk/integrity threshold
may still be approved given
On 07/28/2010 11:52 PM, Pat Farrell wrote:
A lot of the smart card development in the mid-90s and beyond was based
on the idea that the smart card, in itself, was the sole authorization
token/algorithm/implementation.
some ssl, payment, smartcard trivia ...
those smartcards were used for the
On 07/28/2010 11:52 PM, Pat Farrell wrote:
I'd like to build on this and make a more fundamental change. The
concept of a revocation cert/message was based on the standard practices
for things like stolen credit cards in the early 1990s. At the time, the
credit card companies published telephone
On 07/28/2010 10:34 PM, d...@geer.org wrote:
The design goal for any security system is that the number of
failures is small but non-zero, i.e., N0. If the number of
failures is zero, there is no way to disambiguate good luck
from spending too much. Calibration requires differing outcomes.
for the fun of it ... from today ...
Twenty-Four More Reasons Not To Trust Your Browser's Padlock
http://blogs.forbes.com/firewall/2010/07/29/twenty-four-more-reasons-not-to-trust-your-browsers-padlock/?boxes=Homepagechannels
from above:
On stage at the Black Hat security conference Wednesday,
On 07/28/2010 12:10 AM, Paul Tiemann wrote:
I like the idea of SSL pinning, but could it be improved if statistics were
kept long-term (how many times I've visited this site and how many times it's
had certificate X, but today it has certificate Y from a different issuer and
certificate X
On 07/28/2010 10:05 AM, Perry E. Metzger wrote:
I will point out that many security systems, like Kerberos, DNSSEC and
SSH, appear to get along with no conventional notion of revocation at all.
long ago and far away ... one of the tasks we had was to periodically go by project athena to audit
On 07/28/2010 11:05 AM, Nicolas Williams wrote:
Are you arguing for Kerberos for Internet-scale deployment? Or simply
for PKI with rp-only certs and OCSP? Or other federated
authentication mechanism? Or all of the above? :)
as i've mentioned ... the relying-party-only certificates are
On 07/28/2010 12:02 PM, Nicolas Williams wrote:
Sorry, but this is wrong. The OCSP protocol itself really is an online
certificate status protocol. Responder implementations may well be
based on checking CRLs, but they aren't required to be.
Don't be confused by the fact that OCSP borrows
On 07/27/2010 10:11 AM, Peter Gutmann wrote:
So a general response to the several well, what would you do? questions is
I'm not sure, that's why I posted this to the list. For example should an
SSL cert be held to higher standards than the server it's hosted on? In other
words if it's easier
On 07/27/2010 12:09 PM, Pat Farrell wrote:
Most of which we avoided by skipping the cert concept. Still, better
technology has nothing to do with business success.
Public Key Crypto with out all the cruft of PKI. Its still a good
idea.
that became apparent in the use of SSL between all the
On 07/27/2010 12:09 PM, Pat Farrell wrote:
In that same time, I was at CyberCash, we invented what is now
sometimes called electronic commerce. and that and $5 will get
you a cup of coffee. We predated SSL by a few years. Used RSA768 to
protect DES sessions, etc. Usual stuff.
somewhat as
welcome back
announcement of RFC 5830, 5831, 5832 in today's RFC distribution
abstract for 5830:
This document is intended to be a source of information about the
Russian Federal standard for electronic encryption, decryption, and
message authentication algorithms (GOST 28147-89), which is
On 11/21/2009 04:56 PM, John Levine wrote:
we claimed we do something like two orders magnitude reduction in
fully-loaded costs by going to no personalization (and other things)
...
My concern with that would be that if everyone uses the the same
signature scheme and token, the security of the
On 11/21/2009 05:56 PM, Jerry Leichter wrote:
On Nov 18, 2009, at 6:16 PM, Anne Lynn Wheeler wrote:
... we could moved to a person-centric paradigm ... where a person
could use the same token for potentially all their interactions ...
we claimed we do something like two orders magnitude
On 11/21/2009 06:31 PM, Jerry Leichter wrote:
Well, my building card is plain white. If anyone duplicated it, there'd be nothing
stopping them from going in. But then the actual security offered by those cards - and
the building controls - is more for show (and I suppose to keep the riffraff
On 11/18/2009 12:22 PM, Bill Frantz wrote:
Perhaps I'm missing something, but my multiple banks will all accept my
signature when made with the same pen. Why wouldn't they not accept my
signature when made with the same, well protected, signing/user verifying
device. I might have to take it to
On 11/10/2009 09:44 AM, Jerry Leichter wrote:
Not that this should block the use of devices like the ZTIC! They're
still much more secure than the alternatives. But it's important to keep
in mind the vulnerabilities we engineer *into* systems at the same time
we engineer others *out*.
On 11/08/2009 02:07 AM, John Levine wrote:
At a meeting a few weeks ago I was talking to a guy from BITS, the
e-commerce part of the Financial Services Roundtable, about the way
that malware infected PCs break all banks' fancy multi-password logins
since no matter how complex the login process,
On 08/20/09 00:11, Ray Dillinger wrote:
No. This juvenile fantasy is complete and utter nonsense, and
I've heard people repeating it to each other far too often. If
you repeat it to each other too often you run the risk of starting
to believe it, and it will only get you in trouble. This is a
On 08/06/09 07:33, James A. Donald wrote:
The fundamental problem with certificates is getting them.
digital certificate design point supposedly was the dial-up email of the early
80s,
dial-up, exchange email, hang-up ... and then faced with how to deal with first
time email from complete
On 07/01/2009 02:10 PM, Nicolas Williams wrote:
I should add that a hardware token/smartcard, would be even better, but
the same issue arises: keep it logged in, or prompt for the PIN every
time it's needed? If you keep it logged in then an attacker who
compromises the system will get to use
On 05/09/09 07:33, Jerry Leichter wrote:
I had a discussion with a guy at a company that was proposing to create
secure credit cards by embedding a chip in the card and replacing some
number of digits with an LCD display. The card would generate a unique
card number for you when needed. They
On 05/09/09 07:33, Jerry Leichter wrote:
On May 8, 2009, at 3:39 PM, Ian G wrote:
The difficulty with client certs is that I need them to also work on my
laptop. And my other laptop. And my phone.
So, how do I get hold of them when I'm on the road?
Good point. The difficulty with my
On 05/05/09 14:01, Thierry Moreau wrote:
Before the collapse of the .com market in year 2000, there were
grandiose views of global PKIs, even with support by digital signature
laws.
Actually, it turned out that CA liability avoidance was the golden rule
at the law and business model abstraction
On 11/27/08 05:13, Nicholas Bohm wrote:
I've never been quite sure whether Public qualifies Key or
Infrastructure - this may make a difference to what you count as a PKI.
SWIFT (interbank messaging), BOLERO (bills of lading) and CREST (dealing
in dematerialised stocks and shares) all use public
Secure64 Develops First Automated DNSSEC Signing Application to Help
Secure the Internet Worldwide
http://www.businesswire.com/news/google/20080730005428/en
from above:
Secure64 Software Corporation has developed a product that
dramatically simplifies the implementation and management of
Thierry Moreau wrote:
Anne Lynn Wheeler wrote about various flavors of certificateless
public key operation in various standards, notably in the financial
industry.
Thanks for reporting those.
No doubt that certificateless public key operation is neither new nor
absence from today's scene
Thierry Moreau wrote:
In draft-ietf-sip-dtls-srtp-framework, the detailed scheme uses
self-signed certificates created by client end-entities themselves.
The basic idea is identical. At the detailed level in my document, the
client end-entity auto-issues a security certificate with a
breached
Thierry Moreau wrote:
A)The big picture refers to the PKC-only application security
scheme, in which client-server applications may be secured with
client-side public key pairs, but *no trusted certification authority*
is involved (server operators are expected to maintain a trusted
Perry E. Metzger wrote:
My bank doesn't provide any sort of authentication for logging in to
bank accounts other than passwords. However, Blizzard now allows you
to get a one time password keychain frob to log in to your World of
Warcraft account.
post in thread here a yr ago (1jul07)
James A. Donald wrote:
Committees of experts regularly get cryptography wrong - consider, for
example the Wifi debacle. Each wifi release contains classic and
infamous errors - for example WPA-Personal is subject to offline
dictionary attack.
One would have thought that after the first
archeological email about proposal for doing pgp-like public key
(from 1981):
http://www.garlic.com/~lynn/2006w.html#email810515
the internal network was larger than the arpanet/internet from
just about the beginning until sometime summer of '85. corporate
guidelines had become that all
John Ioannidis wrote:
This is no different than suffering a disk crash. That's what backups
are for.
At Jim Gray's tribute on the 31st, Bruce Lindsay gave a talk about Jim's
formalization of transaction processing enabled online transactions ... i.e.
needed trust in the integrity of
Bill Frantz wrote:
really used for strangers. For people we know, recognition and
memory are more compelling ways of trusting.
We can use this recognition and memory in the online world as well.
SSH automatically recognizes previously used hosts. Programs such
as the Pet Names
Allen wrote:
I don't know what the policy is in Ireland, but here in the USA there
is no stop loss on debit cards so the banks are not obligated to make
good on fraudulent withdrawals. I believe that most have out of fear
of bad PR, but you have to fight for it if it is just a few that it
*Irish Bank Debit Card Skimmers Net €1m*
http://www.epaynews.com/index.cgi?survey=ref=browsef=viewid=121179135013743148197block=
from above:
Most of the withdrawals took place at the end of April and early May
2008. Many of the victims contacted their banks to notify them of the
withdrawals,
I've periodically posted that certain assumptions were made about safe
SSL deployment for electronic commerce that were almost immediately
invalidated.
The original assumptions assumed that the enduser knew the binding
between the webserve that they thot they were talking to and the
Leichter, Jerry wrote:
While analysis of the actual silicon will clearly have to be part of
any solution, it's going to be much harder than that:
1. Critical circuitry will likely be tamper-resistant.
Tamper-resistance techniques make it hard to see what's
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.
David Wagner wrote:
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 least, the problem of theft of web authenticators
-- it obviously won't help with theft of SSNs). If users don't
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
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 going
Victor Duchovni wrote:
SMTP does not need TCP to provide reliability for the tail of the session,
the application-level . (end-of-data) and server 250 response complete
a transaction, everything after that is optional, so for example Postfix
will send (when PIPELINING).
DATACRLF
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
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
Victor Du
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
1. ACK 220
Philipp Gühring wrote:
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 have the paradox situation that I have to tell people that they should use
HTTPS with server-certificates and
Perry E. Metzger wrote:
This evening, a friend of mine who shall remain nameless who works for
a large company that regularly processes customer credit card payments
informed me of an interesting fact.
His firm routinely discovers attempted credit card fraud. However,
since there is no way for
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
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
Leichter, Jerry wrote:
Virtualization has become the magic pixie dust of the decade.
When IBM originally developed VMM technology, security was not a primary
goal. People expected the OS to provide security, and at the time it
was believed that OS's would be able to solve the security
Bill Frantz wrote:
My favorite virtual machine use is for the virus to install itself
as a virtual machine, and run the OS in the virtual machine. This
technique should be really good for hiding from virus scanners.
re:
http://www.garlic.com/~lynn/aadsm28.htm#2 Death of antivirus software
re:
Storm, Nugache lead dangerous new botnet barrage
http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1286808,00.html
from above:
The creators of these Trojans and bots not only have very strong
software development and testing skills, but also clearly know how
security
Jack Lloyd wrote:
The only reason this 'must' be true is because an anonymous and secure
payment system is a terror which thankfully our federal governments
and central banks protect us from. While Amazon and others obviously
like being able to build customer profiles of everyone, I don't
zooko wrote:
Suppose you did have a convenient way to display the SSL certificate for
every site whenever you loaded a page from the site. You probably
wouldn't want to memorize all the certificates for the secure sites that
you care about, so you might instead write some notes on a piece of
re:
http://www.garlic.com/~lynn/aadsm27.htm#39 a fraud is a sale, Re: The bank
fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#40 a fraud is a sale, Re: The bank
fraud blame game
recent item with the other side of the issue (as opposed to being able
to profit when merchants have
R. Hirschfeld wrote:
- differential pricing: electronic purse payments are potentially
cheaper to process than those of debit cards because they are
offline, but consumers find it more convenient to keep money in
their bank account than on a smart card and will likely continue to
do so
R. Hirschfeld wrote:
During the course of the CAFE project some commercial electronic purse
systems emerged, notably Proton (from Banksys in Belgium, replicated
in other counties under other names) and Mondex. These were in many
ways less sophisticated than CAFE's system (which was
Adam Shostack wrote:
It may be, indeed. You're going (as Lynn pointed out in another post)
to be fighting an uphill battle against the last attempts. I don't
think smartcards (per se) are the answer. What you really need is
something like a palm pilot, with screen and input and a reasonably
Ed Gerck wrote:
Yes. Today, under current practice, there's actually a strong
incentive to keep existing fraud levels than to try to scrub
it out -- fraud has become a sale:
thread from earlier this year ... when over a period of a month or
so there were several releases that essentially had
Adam Shostack wrote:
I'd suggest starting from the deployment, training, and help desk
costs. The technology is free, getting users to use it is not. I
helped several banks look at this stuff in the late 90s, when cost of
a smartcard reader was order ~25, and deployment costs were estimated
at
Florian Weimer wrote:
Oh really?
In Germany, early digital banking had no cryptographic protection at
all. Integrity and confidentiality were inherited from the underlying
phone system. There were no end-to-end digital signatures. Nothing.
Just a one-time password for each transaction, but
Peter Gutmann wrote:
I have a friend who implemented a basic trusted-boot mechanism for a student
project, so we have evidence of at least one use of a TPM for TC, and I know
some folks at IBM Research were playing with one a few years ago, so that's at
least two users so far. Anyone else?
as
Peter Gutmann wrote:
Smart cards are part of the problem set, not the solution set - they're just
an expensive and awkward distraction from solving the real problem. What I
was suggesting (and have been for at least ten years :-) is a small external
single-function device (no need for an OS)
Peter Gutmann wrote:
(The usage model is that you do the UI portion on the PC, but perform the
actual transaction on the external device, which has a two-line LCD display
for source and destination of transaction, amount, and purpose of the
transaction. All communications enter and leave the
re:
http://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game
slight addendas ...
1) EU finread
http://www.garlic.com/~lynn/subintegrity.html#finread
http://www.garlic.com/~lynn/subintegrity.html#assurance
one of the issues that we looked at early on in x9.59 standard ... somewhat
Ian G wrote:
Unfortunately for the banks, there is a vast body of evidence that we
knew and they knew or should have known that the PC was insecure [1].
So, by fielding a system -- online commerce -- with a known weakness,
they took responsibility for the fraud (from all places).
re:
Alex Alten wrote:
SSL seems to be hanging by a thread, mainly the name to public key mapping
depends on how thorough the checking is done in to SSL vs application
layers
inside of the web browser. If this is hosed then unrestricted MITM is
in the cards
sometime in the near future.
re:
A secure Internet requires a secure network protocol
http://www.infoworld.com/article/07/06/22/25OPsecadvise_1.html
from above:
Implementing -- and requiring -- stronger authentication and cryptography standards
is the next step toward a new Internet
... snip ...
i would contend that
James A. Donald wrote:
Many protocols use some form of self describing data format, for example
ASN.1, XML, S expressions, and bencoding.
Why?
gml (precursor to sgml, html, xml, etc)
http://www.garlic.com/~lynn/subtopic.html#sgml
was invented at the science center in 1969
re:
http://www.garlic.com/~lynn/aadsm27.htm#24 Why self describing data formats:
for other archaeological trivia ... later i transferred from the science center
to SJR and got to do some of the work on the original relational/sql
implementation,
System/R.
a few years later, the L in GML also
re:
http://www.garlic.com/~lynn/aadsm27.htm#22 A crazy thought?
for some other topic drift regarding certification authorities ... having been
certification
authorities for digital certificates targeted at the (electronic but)
offline market
... they encountered a number of issues in the
Ian G wrote:
What you are suggesting is called Web of Trust (WoT). That's what the
PGP world does, more or less, and I gather that the SPKI concept
includes it, too.
However, x.509 does not support it. There is no easy way to add
multiple signatures to an x.509 certificate without running
Allen wrote:
Hi Gang,
In a class I was in today a statement was made that there is no way that
anyone could present someone else's digital signature as their own
because no one has has their private key to sign it with. This was in
the context of a CA certificate which had it inside. I tried
StealthMonger wrote:
This would destroy the protection of one who depends on off-line,
message-based communication for self-defense.
Such a person may create and maintain a persistent pseudonym through
untraceable chains of random latency, anonymizing remailers which
thwart traffic analysis
Anne Lynn Wheeler wrote:
for other topic drift ... a recent post with some DNS related trivia ...
more than a decade before DNS (about half-way down the post mentioning former
MIT student)
http://www.garlic.com/~lynn/2007k.html#33 Even worse than UNIX
and for other topic drift, old email
James A. Donald wrote:
The problem is organizational. To get one decision
centrally made and imposed on everyone requires a
central body capable of making decisions and imposing
them on everyone, and before it can get that authority,
that central body usually has to raze Atlanta and burn
the
re:
http://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?
http://www.garlic.com/~lynn/aadsm27.htm#17 dnssec?
http://www.garlic.com/~lynn/aadsm27.htm#19 307 digit
Ivan Krstić wrote:
That can't happen until we make sure you can trust DNS, which in turn
can't happen until we get a concrete proposal that has clearly defined
goals and isn't braindead. As has been amply pointed out, it's not clear
that DNSSEC will cut it anytime soon.
A big part of the issue
Victor Duchovni wrote:
The other issue is that sites will need multiple certs during any
transition from RSA to ECC, because the entire Internet won't upgrade
overnight. I am not expecting public CAs to cooperate by charging the
same price for two certs (RSA and ECC) for the same subject
Ivan Krstić wrote:
I think it's anything but surprising. There's only so much you can do to
significantly improve systems security if you're unwilling to break
backwards compatibility -- many of the fundamental premises of desktop
security are fatally flawed, chief among them the idea that all
Jason Holt wrote:
ERM/DRM/TPM are such poorly defined and implemented products that people
have started referring to a DRM fairy who people assume will wave her
wand and solve whatever problem is at hand. I used to try to draw out
the mentioner's claims into a concrete proposal that everyone
Travis H. wrote:
This reminds me a bit of a suggestion I once heard for protocol
designers that the messages of the various steps of the protocol
include a step number or something like it to prevent cut-and-paste
attacks (presumably each message has some redundancy to protect the
1 - 100 of 397 matches
Mail list logo
