(probably Firefox):
http://crypto.stanford.edu/PwdHash/
iang
--
Advances in Financial Cryptography, Issue 2:
https://www.financialcryptography.com/mt/archives/000498.html
Mark Stiegler, An Introduction to Petname Systems
Nick Szabo, Scarce Objects
Ian Grigg, Triple Entry Accounting
://www.financialcryptography.com/mt/archives/000498.html
Mark Stiegler, An Introduction to Petname Systems
Nick Szabo, Scarce Objects
Ian Grigg, Triple Entry Accounting
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe
--
Advances in Financial Cryptography, Issue 2:
https://www.financialcryptography.com/mt/archives/000498.html
Mark Stiegler, An Introduction to Petname Systems
Nick Szabo, Scarce Objects
Ian Grigg, Triple Entry Accounting
Szabo, Scarce Objects
Ian Grigg, Triple Entry Accounting
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
(Dan, in answer to your question on certs, below.)
On Thursday 14 July 2005 14:19, Perry E. Metzger wrote:
Ian Grigg [EMAIL PROTECTED] writes:
It's 2005, PKI doesn't work, the horse is dead.
He's not proposing PKI, but nymous accounts. The
account is the asset, the key is the owner
Szabo, Scarce Objects
Ian Grigg, Triple Entry Accounting
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Cryptography, Issue 2:
https://www.financialcryptography.com/mt/archives/000498.html
Mark Stiegler, An Introduction to Petname Systems
Nick Szabo, Scarce Objects
Ian Grigg, Triple Entry Accounting
-
The Cryptography Mailing List
:
https://www.financialcryptography.com/mt/archives/000458.html
Daniel Nagy, On Secure Knowledge-Based Authentication
Adam Shostack, Avoiding Liability: An Alternative Route to More Secure Products
Ian Grigg, Pareto-Secure
, Issue 1:
https://www.financialcryptography.com/mt/archives/000458.html
Daniel Nagy, On Secure Knowledge-Based Authentication
Adam Shostack, Avoiding Liability: An Alternative Route to More Secure Products
Ian Grigg, Pareto-Secure
What CR does instead is much simpler and more direct. It tries to cut off
any player that has been used for mass piracy.
Let me get this right. ...
When a pirate makes a copy of a film encoded as SPDC, the output file is
cryptographically bound to a set of player decryption keys. So it is
Hi,
I'm working on a project for a company that involves the use of 3DES. They
have
asked me to find out what the overheads are for encrypting a binary file.
There
will be quite a lot of traffic coming in (in the region of hundreds of
thousands of files per hour). Has anyone got any figures
Ben raises an interesting thought:
There was some question about whether this is possible for connections that
use client-certs, since it looks to me from the spec that those connections
should be using one of the Diffie Hellman cipher suites, which is obviously
not vulnerable to a passive
Ian Grigg writes:
I note that disctinction well! Certificate based systems
are totally vulnerable to a passive sniffing attack if the
attacker can get the key. Whereas Diffie Hellman is not,
on the face of it. Very curious...
No, that is not accurate. Diffie-Hellman is also insecure
Enzo Michelangeli writes:
In the world of international trade, where mutual distrust between buyer
and seller is often the rule and there is no central authority to
enforce
the law, this is traditionally achieved by interposing not less than
three
trusted third parties: the shipping line,
Yes, I'm looking at ideas like this for ecash gambling, but you have
a who-goes-first problem. One side or the other has to rip their
own cash first, and then the other side can just go away and leave the
first side screwed. The act of ripping cash is relatively atomic and
involves a
Ben,
Ian Grigg wrote:
It should be obvious. But it's not. A few billions
of investment in smart cards says that it is anything
but obvious.
That assumes that the goal of smartcards is to increase security instead
of to decrease liability.
On whether the goal of smart cards is to reduce
Alan Barrett wrote:
On Sat, 23 Oct 2004, Aaron Whitehouse wrote:
Oh, and make it small enough to fit in the pocket,
put a display *and* a keypad on it, and tell the
user not to lose it.
How much difference is there, practically, between this and using a
smartcard credit card in an external
Ben Laurie wrote:
This only works if the marks are not such that the identity of the
printer is linked to the marks (as opposed to being able to test whether
a particular document was produced by a particular printer).
To be really safe, I'd suggest going somewhere without surveillance
http://www.financialcryptography.com/mt/archives/000219.html
[EMAIL PROTECTED] wrote:
... to break the conundrum Ballmer finds himself
in where the road forks towards (1) fix the security
problem but lose backward compatibility, or (2) keep
the backward compatibility but never fix the problem.
I
Aaron Whitehouse wrote:
None. But a machine that had one purpose in life:
to manage the bearer bond, that could be trusted
to a reasonable degree. The trick is to stop
thinking of the machine as a general purpose
computer and think of it as a platform for one
single application. Then secure that
R.A. Hettinga wrote:
http://worldnetdaily.com/news/printer-friendly.asp?ARTICLE_ID=41030
An engineer and RFID expert with Intel claims there is little danger of
unauthorized people reading the new passports. Roy Want told the newssite:
It is actually quite hard to read RFID at a distance,
R.A. Hettinga wrote:
http://news.bbc.co.uk/2/low/technology/3753886.stm
US scientists have discovered that every desktop printer has a signature
style that it invisibly leaves on all the documents it produces.
I don't think this is new - I'm pretty sure it was
published about 6 or 7 years back
Hi John,
John Kelsey wrote:
Today, most of what I'm trying to defend myself from online is done as either a kind of hobby (most viruses), or as fairly low-end scams that probably net the criminals reasonable amounts of money, but probably don't make them rich. Imagine a world where there are a
James A. Donald wrote:
we already have the answer, and have had it for a decade:
store it on a trusted machine. Just say no to Windows XP.
It's easy, especially when he's storing a bearer bond worth a
car.
What machine, attached to a network, using a web browser, and
sending and receiving
Jack Lloyd also passed along lots of good comments I'd
like to forward (having gained permission) FTR. I've
edited them for brevity and pertinence.
Jack Lloyd wrote:
If it's small messages, CCM would probably work pretty well. Personally I think
CCM is really poorly designed (in terms of easy
Zooko provided a bunch of useful comments in private mail,
which I've edited and forward for list consumption.
Zooko Wilcox-O'Hearn wrote:
EAX is in the same class as CCM. I think its slightly better. Also
there is GCM mode, which is perhaps a tiny bit faster, although maybe
not if you have to
Hadmut Danisch wrote:
On Thu, Sep 16, 2004 at 12:41:41AM +0100, Ian Grigg wrote:
It occurs to me that a number of these ideas could
be written up over time ... a wiki, anyone? I think
it is high past time to start documenting crypto
patterns.
Wikis are not that good for discussions, and I do
lrk wrote:
Perhaps it is time to define an e-mail definition of crypto to keep the
postman from reading the postcards. That should be easy enough to
implement for the average user and provide some degree of privacy for
their mail. Call it envelopes rather than crypto. Real security
requires more
Adam Shostack wrote:
Given our failure to deploy PKC in any meaningful way*, I think that
systems like Voltage, and the new PGP Universal are great.
I think the consensus from debate back last year on
this group when Voltage first surfaced was that it
didn't do anything that couldn't be done with
Peter Gutmann wrote:
A depressing number of CAs generate the private key themselves and mail out to
the client. This is another type of PoP, the CA knows the client has the
private key because they've generated it for them.
It's also cost-effective. The CA model as presented
is too expensive.
Steve,
thanks for addressing the issues with some actual
anecdotal evidence. The conclusions still don't
hold, IMHO.
Steven M. Bellovin wrote:
In message [EMAIL PROTECTED], Ian Grigg writes:
Right... It's easy to claim that it went away
because we protected against it. Unfortunately,
that's
Eric Rescorla wrote:
Ian Grigg [EMAIL PROTECTED] writes:
Notwithstanding that, I would suggest that the money
already lost is in excess of the amount paid out to
Certificate Authorities for secure ecommerce certificates
(somewhere around $100 million I guess) to date. As
predicted, the CA-signed
Amir Herzberg wrote:
(Amir, I replied to your other comments over on the
Mozilla security forum, which is presumably where they
will be more useful. That just leaves this:)
So while `SSL is harmful` sounds sexy, I think it is misleading. Maybe
`Stop SSL-Abuse!`
Ha! I wondered when someone would
Enzo Michelangeli wrote:
Can someone explain me how the phishermen escape identification and
prosecution? Gaining online access to someone's account allows, at most,
to execute wire transfers to other bank accounts: but in these days
anonymous accounts are not exactly easy to get in any country,
At 10:46 AM 7/10/2004, Florian Weimer wrote:
But is it so harmful? How much money is lost in a typical phishing
attack against a large US bank, or PayPal? (I mean direct losses due
to partially rolled back transactions, not indirect losses because of
bad press or customer feeling insecure.)
I
Aram,
It's now pretty clear that PGP had no clue what this was
all about. Apologies to all, that was my mistake. Also,
to clarify, there was no SSL involved.
What we are looking at is a case of being able to put a
padlock on the browser in a place that *could* be confused
by a user. This is an
Anton Stiglic wrote:
You stated that http://www.pgp.com is an SSL-protected page, but did you
mean https://www.pgp.com? On my Powerbook, with all the browsers I get an
error that the certificate is wrong and they end up at http://www.pgp.com.
What I get is a bad certificate, and this is due to
Financial Cryptography Update: New Attack on Secure Browsing )
July 15, 2004
http://www.financialcryptography.com/mt/archives/000179.html
J Harper wrote:
This barely deserves mention, but is worth it for the humor:
Information Security Expert says SSL (Secure Socket Layer) is Nothing More
Than a Condom that Just Protects the Pipe
http://www.prweb.com/releases/2004/7/prweb141248.htm
I guess the intention was to provide more
(( Financial Cryptography Update: Jabber does Simple Crypto - Yoo Hoo! ))
July 12, 2004
http://www.financialcryptography.com/mt/archives/000176.html
Florian Weimer wrote:
There are simply too many of them, and not all of them implement
checks for conflicts. I'm pretty sure I could legally register
Metzdowd in Germany for say, restaurant service.
This indeed is the crux of the weakness of the
SSL/secure browsing/CA system. The concept
called
John Gilmore wrote:
[By the way, [EMAIL PROTECTED] is being left out of this conversation,
by his own configuration, because his site censors all emails from me. --gnu]
Sourceforge was doing that to me today!
Well, I am presuming that ... the EZ Pass does have an account
number, right? And
Date: Fri, 2 Jul 2004 21:34:20 -0400
From: Dave Emery [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: EZ Pass and the fast lane
No mention is made of encryption or challenge response
authentication but I guess that may or may not be part of the design
(one would think it had better
Security Theatre: From the man who made hundreds of
millions selling signatures on your keys:
--
It is your data, why do you have to pay a licence
fee for the application needed to access the data?
-- Mark Shuttleworth
http://www.tectonic.co.za/default.php?action=viewid=309topic=Open%20Source
John Gilmore wrote:
It would be relatively easy to catch someone
doing this - just cross-correlate with other
information (address of home and work) and
then photograph the car at the on-ramp.
Am I missing something?
It seems to me that EZ Pass spoofing should become as popular as
cellphone
Original Message
Subject: Financial Cryptography Update: The Ricardian Contract
Date: Wed, 7 Jul 2004 11:17:46 +0100
From: [EMAIL PROTECTED]
( Financial Cryptography Update: The Ricardian Contract )
July 07, 2004
John Denker wrote:
[identity theft v. phishing?]
That's true but unhelpful. In a typical dictionary you will
find that words such as
Identity theft is a fairly well established
definition / crime. Last I heard it was the
number one complaint at the US FTC.
Leaving that aside, the reason that
[EMAIL PROTECTED] wrote:
I shared the gist of the question with a leader
of the Anti-Phishing Working Group, Peter Cassidy.
Thanks Dan, and thanks Peter,
...
I think we have that situation. For the first
time we are facing a real, difficult security
problem. And the security experts have shot
Hi John,
thanks for your reply!
John Denker wrote:
The object of phishing is to perpetrate so-called identity
theft, so I must begin by objecting to that concept on two
different grounds.
1) For starters, identity theft is a misnomer. My identity
is my identity, and cannot be stolen.
I think I'd
The phishing thing has now reached the mainstream,
epidemic proportions that were feared and predicted
in this list over the last year or two. Many of
the solution providers are bailing in with ill-
thought out tools, presumably in the hope of cashing
in on a buying splurge, and hoping to turn
Has anyone tried out the threat modelling tool
mentioned in the link below, or reviewed the
book out this month:
http://aeble.dyndns.org/blogs/Security/archives/000419.php
The Threat Modeling Tool allows users to create threat
model documents for applications. It organizes relevant
data points,
Dave Howe wrote:
Peter Gutmann wrote:
It *is* happening, only it's now called STARTTLS (and if certain vendors
(Micromumblemumble) didn't make it such a pain to set up certs for
their MTAs
but simply generated self-signed certs on install and turned it on by
default,
it'd be happening even
Dave Howe wrote:
Ian Grigg wrote:
Dave Howe wrote:
TLS for SMTP is a nice, efficient way to encrypt the channel.
However, it offers little or no assurance that your mail will
*stay* encrypted all the way to the recipients.
That's correct. But, the goal is not to secure email to the extent
Ben Laurie wrote:
Steven M. Bellovin wrote:
The spammers are playing with other people's money, cycles, etc. They
don't care.
We took that into account in the paper. Perhaps you should read it?
http://www.dtc.umn.edu/weis2004/clayton.pdf
(Most of the people on this list are far too
Original Message
http://www.financialcryptography.com/mt/archives/000141.html
In a rare arisal of a useful use of cryptography in real life, the
mutual funds industry is looking to digital timestamping to
Original Message
Subject: Financial Cryptography Update: US intelligence exposed as student decodes
Iraq memo
http://www.financialcryptography.com/mt/archives/000137.html
13 May 2004 DECLAN BUTLER
Original Message
Subject: Financial Cryptography Update: SSL secure browsing - attack tree Mindmap
http://www.financialcryptography.com/mt/archives/000136.html
Here is a /work in progress/ Mindmap on the
Graeme Burnett wrote:
Hello folks,
I am doing a presentation on the future of security,
which of course includes a component on cryptography.
That will be given at this conference on payments
systems and security: http://www.enhyper.com/paysec/
Would anyone there have any good predictions on how
Ivan Krstic wrote:
I have to agree with Perry on this one: I simply can't see a compelling
reason for the push currently being given to ridiculously overpriced
implementations of what started off as a lab toy, and what offers - in
all seriousness - almost no practical benefits over the proper
( Financial Cryptography Update: El Qaeda substitution ciphers )
April 19, 2004
http://www.financialcryptography.com/mt/archives/000119.html
Brian McGroarty wrote:
On Wed, Apr 07, 2004 at 03:42:47PM -0400, Ian Grigg wrote:
It seems to me that the requirement for after-the-vote
verification (to prove your vote was counted) clashes
rather directly with the requirement to protect voters
from coercion (I can't prove I voted
Trei, Peter wrote:
Frankly, the whole online-verification step seems like an
unneccesary complication.
It seems to me that the requirement for after-the-vote
verification (to prove your vote was counted) clashes
rather directly with the requirement to protect voters
from coercion (I can't prove
http://www.theregister.co.uk/content/6/35078.html
http://www.eetimes.com/at/news/OEG20040123S0036
=
All Internet voting is insecure: report
By electricnews.net
Posted: 23/01/2004 at 11:37 GMT
Get The Reg wherever you are, with The Mobile Register
Ed Gerck wrote:
Likewise, in a communication process, when repudiation of an act by a party is
anticipated, some system security designers find it useful to define
non-repudiation
as a service that prevents the effective denial of an act. Thus, lawyers should
not squirm when we feel the
John Gilmore wrote:
Sarbanes-Oxley Act in the US. Section 1102 of that act:
Whoever corruptly--
(1) alters, destroys, mutilates, or conceals a
record, document, or other object, or attempts to
do so, with the intent to impair the object's
integrity or
Carl Ellison wrote:
From where I sit, it is better to term these
as legal non-repudiability or cryptographic
non-repudiability so as to reduce confusion.
To me, repudiation is the action only of a human being (not of a key) and
therefore there is no such thing as cryptographic
Ben Laurie wrote:
Ian Grigg wrote:
Carl and Ben have rubbished non-repudiation
without defining what they mean, making it
rather difficult to respond.
I define it quite carefully in my paper, which I pointed to.
Ah. I did read your paper, but deferred any comment
on it, in part
Richard Johnson wrote:
On Sun, Dec 21, 2003 at 09:45:54AM -0700, Anne Lynn Wheeler wrote:
note, however, when I did reference PAIN as (one possible) security
taxonomy i tended to skip over the term non-repudiation and primarily
made references to privacy, authentication, and
In response to Ed and Amir,
I have to agree with Carl here and stress that the
issue is not that the definition is bad or whatever,
but the word is simply out of place. Repudiation is
an act of a human being. So is the denial of that
or any other act, to take a word from Ed's 1st definition.
Amir Herzberg wrote:
Ben, Carl and others,
At 18:23 21/12/2003, Carl Ellison wrote:
and it included non-repudiation which is an unachievable,
nonsense concept.
Any alternative definition or concept to cover what protocol designers
usually refer to as non-repudiation
Ed Reed wrote:
Ian Grigg [EMAIL PROTECTED] 12/20/2003 12:15:51 PM
One of the (many) reasons that PKI failed is
that businesses simply don't outsource trust.
Of course they do. Examples:
DB and other credit reporting agencies.
SEC for fair reporting of financial results
Rich Salz wrote:
The IP2Location(TM) database contains more than 2.5 million records for all
IP addresses. It has over 95 percent matching accuracy at the country
level. Available at only US$499 per year, the database is available via
download with free twelve monthly updates.
And
Anne Lynn Wheeler wrote:
At issue in business continuity are business requirements for things like
no single point of failure, offsite storage of backups, etc. The threat
model is 1) data in business files can be one of its most valuable assets,
2) it can't afford to have unauthorized access
Bill Frantz wrote:
[I always considered the biggest contribution from Mondex was the idea of
deposit-only purses, which might reduce the incentive to rob late-night
business.]
This was more than just a side effect, it was also
the genesis of the earliest successes with smart
card money.
The
Bill Stewart wrote:
At 09:38 AM 12/16/2003 -0500, Ian Grigg wrote:
In the late nineties, the smart card world
worked out that each smart card was so expensive,
it would only work if the issuer could do multiple
apps on each card. That is, if they could share
the cost with different uses
Ross Anderson's Trusted Computing FAQ has a lot
to say about recent threads:
http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html
iang
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
What is the source of the acronym PAIN?
Lynn said:
... A security taxonomy, PAIN:
* privacy (aka thinks like encryption)
* authentication (origin)
* integrity (contents)
* non-repudiation
I.e., its provenance?
Google shows only a few hits, indicating
it is not widespread.
iang
J Harper wrote:
1) Not GPL or LPGL, please. I'm a fan of the GPL for most things, but
for embedded software, especially in the security domain, it's a
killer. I'm supposed to allow users to modify the software that runs
on their secure token? And on a small platform where there
(link is very slow:)
http://theregister.co.uk/content/68/34096.html
Cryptophone locks out snoopers
By electricnews.net
Posted: 20/11/2003 at 10:16 GMT
A German firm has launched a GSM mobile phone that
promises strong end-to-end encryption on calls,
preventing the possibility of anybody
Tom Weinstein wrote:
The economic view might be a reasonable view for an end-user to take,
but it's not a good one for a protocol designer. The protocol designer
doesn't have an economic model for how end-users will end up using the
protocol, and it's dangerous to assume one. This is
Tom Otvos wrote:
As far as I can glean, the general consensus in WYTM is that MITM attacks are very
low (read:
inconsequential) probability. Is this *really* true?
The frequency of MITM attacks is very low, in the sense
that there are few or no reported occurrences. This
makes it a
Tom Weinstein wrote:
Ian Grigg wrote:
Nobody doubts that it can occur, and that it *can* occur in practice.
It is whether it *does* occur that is where the problem lies.
This sort of statement bothers me.
In threat analysis, you have to base your assessment on capabilities
Perry E. Metzger wrote:
Ian Grigg [EMAIL PROTECTED] writes:
In threat analysis, you base your assessment on
economics of what is reasonable to protect. It
is perfectly valid to decline to protect against
a possible threat, if the cost thereof is too high,
as compared against
Jon Snader wrote:
On Mon, Oct 13, 2003 at 06:49:30PM -0400, Ian Grigg wrote:
Yet others say to be sure we are talking
to the merchant. Sorry, that's not a good
answer either because in my email box today
there are about 10 different attacks on the
secure sites that I care about
Eric Rescorla wrote:
Ian Grigg [EMAIL PROTECTED] writes:
I'm sorry, but, yes, I do find great difficulty
in not dismissing it. Indeed being other than
dismissive about it!
Cryptography is a special product, it may
appear to be working, but that isn't really
good enough
As many have decried in recent threads, it all
comes down the WYTM - What's Your Threat Model.
It's hard to come up with anything more important
in crypto. It's the starting point for ... every-
thing. This seems increasingly evident because we
haven't successfully reverse-engineered the threat
Minor errata:
Eric Rescorla wrote:
I totally agree that the systems are
insecure (obligatory pitch for my Internet is Too
Secure Already) http://www.rtfm.com/TooSecure.pdf,
I found this link had moved to here;
http://www.rtfm.com/TooSecure-usenix.pdf
which makes some of the same
Eric,
thanks for your reply!
My point is strictly limited to something
approximating there was no threat model
for SSL / secure browsing. And, as you
say, you don't really disagree with that
100% :-)
With that in mind, I think we agree on this:
[9] I'd love to hear the inside scoop, but
Anton Stiglic wrote:
- Original Message -
From: Peter Gutmann [EMAIL PROTECTED]
[...]
The problem is
that what we really need to be able to evaluate is how committed a vendor
is
to creating a truly secure product.
[...]
I agree 100% with what you said. Your 3 group
Anne Lynn Wheeler wrote:
what i said was that it was specifying a simplified SSL/TLS based on the
business requirements for the primary use of SSL/TLS as opposed to a
simplified SSL/TLS based on the existing technical specifications and
existing implementations.
I totally agree that
Anton Stiglic wrote:
- Original Message -
From: Ian Grigg [EMAIL PROTECTED]
[...]
In terms of actual practical systems, ones
that implement to Brands' level don't exist,
as far as I know?
There were however several projects that implemented
and tested the credentials
Steve Schear wrote:
[I wonder what if any effect this might have on crypto patents, e.g.,
Chaumian blinding?]
My guess is, nix, nada. Patents are a red herring
in the blinding skirmishes, they became a convenient
excuse and a point to place the flag when rallying
the troops. The battle was
Jill Ramonsky wrote:
First, the primary design goal is simple to use.
This is the highest goal of all. If it is not simple
to use, it misses out on a lot of opportunities. And
missing out results in less crypto being deployed.
If you have to choose between simple-but-incomplete,
versus
Anton Stiglic wrote:
We need a practical system for anonymous/pseudonymous
credentials. Can somebody tell us, what's the state of
the art? What's currently deployed? What's on the
drawing boards?
The state of the art, AFAIK, is Chaum's credential system.
The state of the art is
Zooko O'Whielacronx wrote:
I imagine it might be nice to have Goal B achievable in a certain setting
where Goal A remains unachievable.
In a strictly theoretical sense, isn't this essentially
the job of the (perfect) TTP? At least that's the way
many protocols seem to brush away the
Merchants who *really* rely on their web site being
secure are those that take instructions for the
delivery of value over them. It's a given that they
have to work very hard to secure their websites, and
it is instructive to watch their efforts.
The cutting edge in making web sites secure is
Arnold G. Reinhold wrote:
At 11:50 PM -0400 10/1/03, Ian Grigg wrote:
...
A threat must occur sufficiently in real use, and incur
sufficient costs in excess of protecting against it, in
order to be included in the threat model on its merits.
I think that is an excellent summation
Steven M. Bellovin wrote:
In message [EMAIL PROTECTED], Ian Grigg writes:
M Taylor wrote:
MITM is a real and valid threat, and should be
considered. By this motive, ADH is not a recommended
mode in TLS, and is also deprecated.
Ergo, your threat model must include MITM, and you
Guus Sliepen wrote:
Some advice on licensing wouldn't go amiss either. (GPL? ... LGPL? ...
something else?)
I'd say LGPL or BSD, without any funny clauses.
With crypto code, we have taken the view that it
should BSD 2 clause. The reason for this is that
crypto code has enough other
Matt Blaze wrote:
I imagine the Plumbers Electricians Union must have used similar
arguments to enclose the business to themselves, and keep out unlicensed
newcomers. No longer acceptable indeed. Too much competition boys?
Rich,
Oh come on. Are you willfully misinterpreting what I
1 - 100 of 125 matches
Mail list logo
