Check gpg signatures with RPM - carefully!
on
Linux Virus Alert
·
· Score: 1
The best way to avoid malicious software is to expect and
check good public key signatures before installing packages.
I've always been surprised that there isn't more attention
paid to this. E.g. rpm makes it easy to check sigs, but
does a poor job of telling you the results. There is no
safety at all from checking them unless you actually have
certified the key of the person who signed the package.
For example, this is what the average rpm user would see
when "checking signatures":
This results in an even worse result:
$ rpm --checksig ntp-4.0.99k-15.i386.rpm
ntp-4.0.99k-15.i386.rpm: md5 gpg OK
"Cool," the crypto-newbie says - "I can trust this package".
Absurd! Anyone can easily create a key, name it anything they
want, put the key on the keyservers, and sign packages, completely
anonymously.
The careful user will always add "-v" to --checksig attempts:
$ rpm -v --checksig ntp-4.0.99k-15.i386.rpm
ntp-4.0.99k-15.i386.rpm:
MD5 sum OK: ffc21af83f558c7b6c23d7097ee86fac
gpg: Signature made Sun 08 Apr 2001 12:56:21 PM MDT using DSA key ID DB42A60E
gpg: Good signature from "Red Hat, Inc <security@redhat.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
gpg: Fingerprint: CA20 8686 2BD6 9DFC 65F6 ECC4 2191 80CD DB42 A60E
Here I wish the "WARNING" made it clearer that we still have no
reliable evidence that this is from Red Hat.
To get evidence it is necessary to have signatures on your keyring
which directly or indirecly lead to the signing key in question. The
direct way is to investigate Red Hat's key and figure out if a
reliable independent source says it is really worth trusting for
installation purposes. E.g. by comparing the fingerprint on it to the
key on the install CD you bought. The indirect route is to collect
and sign keys which provide a chain of signatures to Red Hat's key.
This is riskier since there are more assumptions to make, but it is
still infinately better than simply trusting a random "OK" in the RPM
output.
Now the fully-validated signature can be seen, if you carefully use
the "-v" option:
$ rpm --checksig -v ntp-4.0.99k-15.i386.rpm
ntp-4.0.99k-15.i386.rpm:
MD5 sum OK: ffc21af83f558c7b6c23d7097ee86fac
gpg: Signature made Sun 08 Apr 2001 12:56:21 PM MDT using DSA key ID DB42A60E
gpg: Good signature from "Red Hat, Inc <security@redhat.com>"
One option is to just see if you trust any of the keys that sign Red
Hat's key:
A more extensive source is keyanalyze - Analysis of a large OpenPGP ring:
http://dtype.org/keyanalyze/ site, where you will find that Red Hat's
key is "reachable from the strongly-connected set of keys":
I'd like to see rpm by default only install packages if they are
signed by someone you "trust" in the pgp/gpg sense. And then someone
who signs the keys of respected, careful and popular signers like
Redhat. Then we would just have to sign the key of that intermediary
if we wanted convenience. The more paranoid could personally sign
distributor keys based on good out-of-band evidence that they are who
they claim to be.
Ms Rosen complains about the impact of technology
on her business, and exhorts the audience to
come up with ways to fix the problem.
But I think there is unlikely to be a
solution that also preserves freedom. The solutions the RIAA and crew come up with
end up taking away fair use. We are faced with a choice
between freedom and control.
When people use replicators in Star Trek, no one
runs up and sues them. The ability to copy
at such low cost is a deeply important advance,
and restricting it in the ways the RIAA proposes
via DMCA et.al, because it hurts certain
business models, is contrary to the progress
of the useful arts, which is the whole basis
on which copyright law is based in the
constitution.
The National Academy of Sciences has covered
this Digital Dilemma in a thoughtful way:
http://books.nap.edu/html/digital_dilemma/exec_sum m.html
Unlike a normal software license which only takes rights away, the GPL grants rights which Sony is
relying on to redistribute the code.
No, that's *exactly* like a normal software license. They grant you a specific list of rights above and
beyond what you get under copyright law. The GPL is just like a Microsoft EULA in that regard.
Wrong. If all Microsoft was trying to do was give
you more rights, why would they attempt to
force you to agree to the EULA? You don't have to click on the GPL to use GPL'd software. You must abide by it if you want the right
to copy it.
A normal software license tries to limit
how you can use a product even in cases where
you don't copy the product at all - i.e. it
is applied to areas outside of the copyright
system entirely. E.g. by claiming that you can't
disassemble something, or can't use it for
commercial purposes (like rsaref).
How can a donor give money exclusively for development of free software?
That would mean all software would be "OSI Certified Open Source
Software" and the research cannot result in royalty-generating
patents.
E.g. many people (especially firms in the open source realm) would
like to give money to a university, and guarantee that any
Intellectual Property that results is available to all. I.e. all
software is open source, and all patents are open ala
http://www.openpatents.org/
Has anyone seen any grant RFPs like that?
The US government often requires that they be allowed to use
the fruits of research they fund. Their regulations would contain
a lot of the appropriate legal boilerplate, I would think:
One of the things that
made lynx and Mosaic far more successful in
the real world was that anyone could use them for
free. Gopher died an earlier death because of
all the bruhaha surrounding the university's
licensing terms.
UIUC and Berkeley (with BSD Unix) knew how to
change the world. Trying to make a business
out of things usually
just gets in the way of research and progress.
You are right the Internet was not designed to survive a nuclear war, the concept of a
distributed digital packet switching network was designed to survive a nuclear war. But
the Internet is a distributed digitsl packet switching network.
But the folks that independently designed
the packet switching that was used in the
ARPANET (predecesor to the Internet) didn't
have war-survival in mind. They designed
an academic network to link researchers
together in an interoperable way.
Only later on did they run across the folks
at RAND that were worried about survivability.
Check out Where Wizards Stay Up Late - the Origins of the Internet
The truth is
much more inspirational.
than this old misconception.
This version applies the "intent" language
to both 1) and 2), as you suggested, and
thus appears to addresse the 11 (b) issue also of contributing
to open source software. Section 11 has also
changed.
There still may be lots of problems here, but I
agree with those that urge us to get involved.
It has clearly finally had at least some impact.
I too was very saddened that
slashdot columnists and nearly all the readers
didn't ever talk about the actual study.
They mostly talked about an opinionated posting
based on a newspaper's version of a wire
story, none of which had the courage to point
readers to the real study.
I urge journalists, and
especially slashdot, to always point to the
original source.
Worth noting:
1) Monday is not the final step. NIST will announce
their encryption algorithm selection which will be proposed for the
Advanced Encryption Standard as a replacement for DES. There will be
public commentary on their proposal, and we should have an official
standard by next summer.
2) The new algorithm will be both faster and contain more key bits (choice
of 128, 192 or 256) than either DES or Triple-DES. Hopefully over
time no flaws will be discovered....
3) See http://www.nist.gov/aes/ for information on viewing the webcast.
Given how much I enjoyed his previous writings, I expected to be
thrilled with this book. There is lots of good stuff, but also some
places where he seems to be out of his depth (as would anyone writing
a book as broad as this....).
I haven't finished it yet, but the section on access control
was a relatively unhelpful mix of theory and practice with
some confusion. E.g.:
p. 124 "In Unix, ownership is per file, and is usually determined by
which directory the file is in."
The ownership may be statistically correlated with direcory ownership,
as in any system, but never "determined" by the direcory.
On p. 100 it says that a 128-bit symmetric key "will be secure for a
millennium". I thought that quantum computers (if we figure out how
to make them in the next millennium) would mount a very plausible
attack on 128-bit keys, and I assume this is why AES specifies a
256-bit key option.
On page 74 a distinction is drawn between integrity (accurate copying)
and authentication. But the examples on p. 75 demonstrate the very
confusion that was highlighted. Kurt Vonnegut's "1997 MIT
commencement address" was an authentication problem, not an integrity
problem, since the speech was presumably not modified since its
creation by Mary Schmich. The same goes for the next two examples on
that page.
On p. 103 it describes most residential locks as having 5 pins, 10
positions per pin => 100,000 possible keys. It would be fun in some
medium sized group (about 350 keys, less than 100 people?) to look for
a key collision - I think the odds would favor it.... A bit unnerving
also.
An example on p. 109 describes, by way of
analogy, physical certified checks as an element
in a protocol which helps with selling cars. It makes me wonder
how one would really go about verifying that a "certified check"
is actually worth anything.
None of this detracts from the main points of the book. Again, I
haven't finished it, but I don't see much warning about ineffective
security decrees that just waste people's time. E.g. I often see
commercial security organizations mandate time-consuming or
inconvenient practices to guard against threats that pale in
comparison to other threats which they ignore. This can hurt the
security of the bottom line without really improving the security,
and without a positive bottom line, the security of the assets can
become irrelevant.
He clearly makes the point that security is a business decision, but
some examples of the sort of unnecessary "security" overhead that
just wastes time and resources would add a lot.
The first thing I'd like to see is for someone
to run Argus (source code available!) on it, which would produce
a nice overall picture of which hosts, ports,
pairs of hosts, etc were involved.
Coming up with a private algorithm to "fingerprint" audio files sounds like a fun
thing to do, and you may well have clever ideas.
Some of the uses you suggest would work just
fine, as long as no one has the incentive
to modify the file so it still sounds fine
but has a different fingerprint.
Keeping it a "secret" and selling it to
the clueless music industry for "watermark-like" purposes
might make some money and work for a little while.
But as soon as people know how the algorithm
works
it is clear that someone will come up with
a way to subtly change the file so your
particular scheme is not a reliable fingerprint.
I.e. the modified file will have a different
fingerprint but it will still sound
good enough to folks that the music industry
will want to cry foul about the technique.
And people will figure out how the algorithm
works whether you want them to or not.
That is
just the way the world of security works.
Thanks for a good explanation (and to
bgalehouse for yet more insight).
But Brumleve describes another problem with
BOURLConnection and BOURLInputStream that
allows the applet to read local files. Can
someone help us with that one also?
Here is a letter I wrote last week to WaSP. No reply yet....
Re: http://www.webstandards.org/
I was excited to hear that WaSP was advising web authors to avoid browser-specific tags.
But I'm tempted to write you off as clueless because you use HTML and CSS features that produce horrid pages in one of the most common browsers - netscape.
For people like me who try to save our eyesight by configuring netscape to use large fonts, your pages yield unreadable text. It may be that this is a problem with netscape browsers (I'm using 4.72 on Solaris), but all it does is restrict your readership.
E.g., on your home page, the text "LATEST BUZZ" overlapps itself. It uses the 'class="buzz"' attribute.
Please stop selecting specific fonts and sizes in your wsp.css file. Fonts are platform-specific. Help users to control their own browser experience. See
Learning HTML 3.2 by examples: http://www.hut.fi/~jkorpela/HTML3.2/ for more of the technical issues and background philosophy.
Keep on advocating for standards-compliance, and hold netscape's toes to the fire also, but advocate for interoperability also.
An explanation why TCP over TCP, PPP over SSH and similar solutions are not a good idea.
Unfortunately, it doesn't work well. Long delays and frequent connection aborts are to be expected. Here is why.... Use ipsec or CIPE instead....
http://sites.inka.de/~bigred/devel/ tcp-tcp.html
Normal TCP: when a segment timeouts, the following timeout is increased (exponentially, in fact, because that has been shown to avoid the meltdown effect)....
Stacked TCP: the upper layer can queue up more retransmissions faster than the lower layer can process them. TCPs reliability provisions backfire here. The upper layer retransmissions are completely unnecessary, since the carrier guarantees delivery - but the upper layer TCP can't know this, because TCP always assumes an unreliable carrier.
The Boulder Community Network also matches volunteers with opportunities at local non-profits. We went online in April 1994 and were perhaps the second web site dedicated to providing content hosting for community groups. We also do classes, special projects, etc.
So if you have connections in Boulder County CO, check us out! E.g. a slashdot clone focussed on Boulder issues would be a great community-builder, and the model could be replicated elsewhere.
This is an option that should be considered more often.
The Fortune 500 firm I work for has to look at both the short term and the long term. Many of us focus on the long term, where it is important to avoid becoming locked into proprietary systems which may lose support when the original owners either go out of business or decide to force us into costly upgrades by designing in incompatibility.
Others are focussed on the short term where active support is more important because the software is new/buggy and is being integrated into other systems.
So for situations where traditional reasons for going Open Source don't look attractive to you, consider something like a contract with FSF that in a few years a given body of source becomes assigned to them and GPL'd. This would help sell the original product to folks like us so it would be a win for you also. And in n years you could leave the support headaches to the community and embark on your next cool idea.
Note that the first syllable of the name of the binary-multiple prefix should be pronounced in the same way as the first syllable of the name of the corresponding SI prefix, and that the second syllable should be pronounced as "bee."
To: lois.boland@uspto.gov Subject: Proposed Patent Law Treaty changes are bad for the public
This is a response to: http://www.uspto.gov/web/offices/com/sol/notices/p atlawtrty.pdf [Federal Register: March 9, 2000 (Volume 65, Number 47)] [Notices] [Page 12515-12517] From the Federal Register Online via GPO Access [wais.access.gpo.gov] [DOCID:fr09mr00-46]; http://www.wipo.int/scp
The current patent rules already are bad for the general public, and your "Basic Proposal" would make the situation worse. To summarize:
"Innovate, don't Litigate!"
The proposal is focussed on helping those who want to claim patent monopoly rights:
The objective of the meetings has been to develop a Basic Proposal, consisting of articles and regulations, which will minimize the formal requirements associated with patent applications and patents. Upon adoption, these articles and rules will simplify the formal obligations and reduce associated costs for patent applicants and owners of patents in obtaining and preserving their rights in inventions in many countries of the world.
Why do we grant patent monopolies in the first place? The US Constitution, in Article I, section 8, gives the congress power:
"To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries;"
Rights are only to be offered to inventors in order to "promote the Progress of Science and useful Arts".
But the current patent rules, especially as applied to the field of computer software, are hindering rather than promoting progress.
Your proposal to minimize formal requirements and reduce costs for patent applications benefits those who claim to have invented things, but the net result is an increased set of requirements and costs for those actually making progress in science and useful arts. In the current marketplace the innovative programmer is driven to invent things in order to be "first to market" and they require no patent protection as incentive. Instead, they must guard against the fear that others with money to spend on patent lawyers will prevent them from using obvious ideas or charge them fees in ways that limit the possible distribution methods for their work.
I endorse the proposals at http://lpf.ai.mit.edu/ which I incorporate by reference into this response.
There is wide support (see editorials in Forbes, Barrons and The Economist, among others) for the notion that software patents are impeding many aspects of technology today. Many high-tech firms support this notion, but are forced to divert precious recources into the filing of "defensive patents".
I'm particularly alarmed at the notion that people from other countries would be able to claim a "filing date" in our country after submitting a minimal set of material in "any language":
[A country] must provide a filing date for an application as of the date on which its Office has received the following elements:
(i) An indication that submitted elements are intended to be an application; (ii) Indications allowing the identity of the applicant to be established or allowing the applicant to be contacted; and (iii) A description.
This filing date requirement is fairly minimal and would greatly simplify the conditions imposed upon the grant of filing dates to patent applications throughout the world. Note that this article would mandate the acceptance, for filing date purposes, of patent applications in any language, subject to the furnishing of later translations. The USPTO has supported this article, with the knowledge that our claim requirement, for filing date purposes, in section 111(a) of title 35, United States [[Page 12517]] Code, would have to be deleted.
We need to raise, not lower, the cost of patent applications so that we can have more competent patent examiners.
We need to exclude software from the domain of patents. Inventors should use copyright and trade secret protections instead.
Since the rate of progress is faster, the term of patents should be lowered substantially.
We need to make patents public upon initial application so that experts can comment on their innovativeness before they are granted.
Please fight any proposals that would disadvantage the general public by stifling rather than encouraging innovation. We must grant patents for the benefit of the general population, not to provide lopsided benefits to those who want to use the system to prevent others from delivering innovations to the public.
Thank you.
--Neal
Re:Who says SRP is not patented?
on
SSH v. SRP
·
· Score: 1
Cool. This is positive, though ambiguous news, but it comes from an anonymous source, "tjw99 on slashdot" (ironic for a debate about authentication:-)
Is this really is the very inventor of SRP, Thomas Wu, speaking? Assuming that it is, welcome to the party! I'll make the same plea I made in email to you 2 years ago - splash this news all over the web page! I think the world will take SRP far more seriously if you will put that in writing and avoid ambiguity. E.g. can people sell their own SRP implementations without a license? Without a fee?. The appropriate way to do so is to write a letter to the IETF along the lines of
It will need to be in legal language. In my experience, IETF won't be interested in putting it on the standards track unless it uses the model of the SSL patent from Netscape: free for *all* uses (not just open-source or non-commercial), reserving only the right to use it defensively, i.e. preventing other companies from going after you for infringing patents on SRP-related stuff that they may assert. E.g.: from RFC2246 on TLS (the successor to SSL):
Netscape Communications has issued the following statement:
Intellectual Property Rights Secure Sockets Layer
The United States Patent and Trademark Office ("the PTO") recently issued U.S. Patent No. 5,657,390 ("the SSL Patent") to Netscape for inventions described as Secure Sockets Layers ("SSL"). The IETF is currently considering adopting SSL as a transport protocol with security features. Netscape encourages the royalty-free adoption and use of the SSL protocol upon the following terms and conditions:
If you already have a valid SSL Ref license today which includes source code from Netscape, an additional patent license under the SSL patent is not required.
If you don't have an SSL Ref license, you may have a royalty free license to build implementations covered by the SSL Patent Claims or the IETF TLS specification provided that you do not to assert any patent rights against Netscape or other companies for the implementation of SSL or the IETF TLS recommendation.
What are "Patent Claims":
Patent claims are claims in an issued foreign or domestic patent that: 1) must be infringed in order to implement methods or build products according to the IETF TLS specification; or 2) patent claims which require the elements of the SSL patent claims and/or their equivalents to be infringed.
Thanks, Thomas!
--Neal
Who says SRP is not patented?
on
SSH v. SRP
·
· Score: 1
You write "SRP isn't encumbered by patents".
I see little evidence for this, and there are lots of hints otherwise. Previous versions of the SRP license contained the warning
"Some of the algorithms in this distribution may be covered by patents in some countries; it is up to the user to ensure that any required licenses are obtained."
The page http://srp.stanford.edu/ says "This link is currently limited to Stanford users pending resolution of patent negotiations. Sorry!"
Two years ago I sent email to Thomas Wu asking if it was patented and got no response. Other people I've talked to also are concerned about this.
So while I can't point to clear evidence of patents, I urge great caution with SRP until a definitive answer on this question is provided. I like SRP, but the advantages over SSH are marginal enough that the intellectual property questions are far more important.
On another front, SRP is promoted because it allows users to choose their own easily-remembered passwords. But Bruce Schneier notes that computers are already fast enough to basically search the entire space of passwords that are easy for humans to remember. So if the password file on an SRP server is compromised, the passwords can be cracked if you try hard enough. I'm sure it is very expensive now, but over time the cost of doing this will drop since human memory capacity is not increasing.
Cruithne is more similar to our moon than you may think. Our moon actually is more closely bound, gravitationaly, to the sun than to the earth, like Cruithne. If you look at Moon's path for a year, it is always concave towards the sun, with twelve or thirteen flatter points (when the earth was further from the sun than the moon).
So both Cruithne and Moon trace out a repeatable path with respect to the Earth, but both can be considered to really orbit the Sun.
In Boston in 1978 or 1979 I saw a demo of a CAD program that used "unistrokes" to enter CAD commands. It is hard to believe that no one thought of using "unistrokes" for entering text until Xerox did in October of 1995, or that that isn't an obvious derivation of the CAD work, which even if it was patented would already be expired.
Slashdot Mirror
The best way to avoid malicious software is to expect and
x &search=0xDB42A60E]
t ed.txt:
A 60E
check good public key signatures before installing packages.
I've always been surprised that there isn't more attention
paid to this. E.g. rpm makes it easy to check sigs, but
does a poor job of telling you the results. There is no
safety at all from checking them unless you actually have
certified the key of the person who signed the package.
For example, this is what the average rpm user would see
when "checking signatures":
$ rpm --checksig ntp-4.0.99k-15.i386.rpm
ntp-4.0.99k-15.i386.rpm: md5 (GPG) OK (MISSING KEYS: GPG#DB42A60E)
This says that the signatures are "OK"! And the user is thus tempted
to just ignore the confusing "MISSING KEYS" message. Absurd!
More diligent users will actually get the key:
$ gpg --keyserver wwwkeys.pgp.net --recv-keys 0xDB42A60E
This results in an even worse result:
$ rpm --checksig ntp-4.0.99k-15.i386.rpm
ntp-4.0.99k-15.i386.rpm: md5 gpg OK
"Cool," the crypto-newbie says - "I can trust this package".
Absurd! Anyone can easily create a key, name it anything they
want, put the key on the keyservers, and sign packages, completely
anonymously.
The careful user will always add "-v" to --checksig attempts:
$ rpm -v --checksig ntp-4.0.99k-15.i386.rpm
ntp-4.0.99k-15.i386.rpm:
MD5 sum OK: ffc21af83f558c7b6c23d7097ee86fac
gpg: Signature made Sun 08 Apr 2001 12:56:21 PM MDT using DSA key ID DB42A60E
gpg: Good signature from "Red Hat, Inc <security@redhat.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
gpg: Fingerprint: CA20 8686 2BD6 9DFC 65F6 ECC4 2191 80CD DB42 A60E
Here I wish the "WARNING" made it clearer that we still have no
reliable evidence that this is from Red Hat.
To get evidence it is necessary to have signatures on your keyring
which directly or indirecly lead to the signing key in question. The
direct way is to investigate Red Hat's key and figure out if a
reliable independent source says it is really worth trusting for
installation purposes. E.g. by comparing the fingerprint on it to the
key on the install CD you bought. The indirect route is to collect
and sign keys which provide a chain of signatures to Red Hat's key.
This is riskier since there are more assumptions to make, but it is
still infinately better than simply trusting a random "OK" in the RPM
output.
Now the fully-validated signature can be seen, if you carefully use
the "-v" option:
$ rpm --checksig -v ntp-4.0.99k-15.i386.rpm
ntp-4.0.99k-15.i386.rpm:
MD5 sum OK: ffc21af83f558c7b6c23d7097ee86fac
gpg: Signature made Sun 08 Apr 2001 12:56:21 PM MDT using DSA key ID DB42A60E
gpg: Good signature from "Red Hat, Inc <security@redhat.com>"
One option is to just see if you trust any of the keys that sign Red
Hat's key:
[http://wwwkeys.pgp.net:11371/pks/lookup?op=vinde
A more extensive source is keyanalyze - Analysis of a large OpenPGP ring:
http://dtype.org/keyanalyze/ site, where you will find that Red Hat's
key is "reachable from the strongly-connected set of keys":
http://dtype.org/keyanalyze/output/200112/msd-sor
27567 219180CD DB42A60E 6.8680
and which other strong-set keys sign it:
http://dtype.org/keyanalyze/output/200112/DB/DB42
I'd like to see rpm by default only install packages if they are
signed by someone you "trust" in the pgp/gpg sense. And then someone
who signs the keys of respected, careful and popular signers like
Redhat. Then we would just have to sign the key of that intermediary
if we wanted convenience. The more paranoid could personally sign
distributor keys based on good out-of-band evidence that they are who
they claim to be.
But I think there is unlikely to be a solution that also preserves freedom. The solutions the RIAA and crew come up with end up taking away fair use. We are faced with a choice between freedom and control.
When people use replicators in Star Trek, no one runs up and sues them. The ability to copy at such low cost is a deeply important advance, and restricting it in the ways the RIAA proposes via DMCA et.al, because it hurts certain business models, is contrary to the progress of the useful arts, which is the whole basis on which copyright law is based in the constitution.
The National Academy of Sciences has covered this Digital Dilemma in a thoughtful way: http://books.nap.edu/html/digital_dilemma/exec_sum m.html
A normal software license tries to limit how you can use a product even in cases where you don't copy the product at all - i.e. it is applied to areas outside of the copyright system entirely. E.g. by claiming that you can't disassemble something, or can't use it for commercial purposes (like rsaref).
--Neal
That would mean all software would be "OSI Certified Open Source Software" and the research cannot result in royalty-generating patents.
E.g. many people (especially firms in the open source realm) would like to give money to a university, and guarantee that any Intellectual Property that results is available to all. I.e. all software is open source, and all patents are open ala http://www.openpatents.org/
Has anyone seen any grant RFPs like that?
The US government often requires that they be allowed to use the fruits of research they fund. Their regulations would contain a lot of the appropriate legal boilerplate, I would think:
Federal Acquisition Regulation PART 27--PATENTS, DATA, AND COPYRIGHT: http://www.arnet.gov/far/current/html/27.html#Subp art27.3
Other related stuff:
OpenScience: http://www.openscience.org/
http://www.sourcexchange.com/
--Neal
UIUC and Berkeley (with BSD Unix) knew how to change the world. Trying to make a business out of things usually just gets in the way of research and progress.
--Neal
But the folks that independently designed the packet switching that was used in the ARPANET (predecesor to the Internet) didn't have war-survival in mind. They designed an academic network to link researchers together in an interoperable way. Only later on did they run across the folks at RAND that were worried about survivability. Check out Where Wizards Stay Up Late - the Origins of the Internet
The truth is much more inspirational. than this old misconception.
--Neal
Version 22 rev 2 from 2 October 2000 is now online in HTML format at: http://conventions.coe.int/treaty/EN/projets/cyber crime22.htm
This version applies the "intent" language to both 1) and 2), as you suggested, and thus appears to addresse the 11 (b) issue also of contributing to open source software. Section 11 has also changed.
There still may be lots of problems here, but I agree with those that urge us to get involved. It has clearly finally had at least some impact.
--Neal
I too was very saddened that slashdot columnists and nearly all the readers didn't ever talk about the actual study. They mostly talked about an opinionated posting based on a newspaper's version of a wire story, none of which had the courage to point readers to the real study.
I urge journalists, and especially slashdot, to always point to the original source.
Sigh.
--Neal
1) Monday is not the final step. NIST will announce
their encryption algorithm selection which will be proposed for the
Advanced Encryption Standard as a replacement for DES. There will be
public commentary on their proposal, and we should have an official
standard by next summer.
2) The new algorithm will be both faster and contain more key bits (choice
of 128, 192 or 256) than either DES or Triple-DES. Hopefully over
time no flaws will be discovered....
3) See http://www.nist.gov/aes/ for information on viewing the webcast.
--Neal
I haven't finished it yet, but the section on access control was a relatively unhelpful mix of theory and practice with some confusion. E.g.:
p. 124 "In Unix, ownership is per file, and is usually determined by which directory the file is in."
The ownership may be statistically correlated with direcory ownership, as in any system, but never "determined" by the direcory.
On p. 100 it says that a 128-bit symmetric key "will be secure for a millennium". I thought that quantum computers (if we figure out how to make them in the next millennium) would mount a very plausible attack on 128-bit keys, and I assume this is why AES specifies a 256-bit key option.
On page 74 a distinction is drawn between integrity (accurate copying) and authentication. But the examples on p. 75 demonstrate the very confusion that was highlighted. Kurt Vonnegut's "1997 MIT commencement address" was an authentication problem, not an integrity problem, since the speech was presumably not modified since its creation by Mary Schmich. The same goes for the next two examples on that page.
On p. 103 it describes most residential locks as having 5 pins, 10 positions per pin => 100,000 possible keys. It would be fun in some medium sized group (about 350 keys, less than 100 people?) to look for a key collision - I think the odds would favor it.... A bit unnerving also.
An example on p. 109 describes, by way of analogy, physical certified checks as an element in a protocol which helps with selling cars. It makes me wonder how one would really go about verifying that a "certified check" is actually worth anything.
None of this detracts from the main points of the book. Again, I haven't finished it, but I don't see much warning about ineffective security decrees that just waste people's time. E.g. I often see commercial security organizations mandate time-consuming or inconvenient practices to guard against threats that pale in comparison to other threats which they ignore. This can hurt the security of the bottom line without really improving the security, and without a positive bottom line, the security of the assets can become irrelevant.
He clearly makes the point that security is a business decision, but some examples of the sort of unnecessary "security" overhead that just wastes time and resources would add a lot.
--Neal
The latest is argus-1.8.1 from
ftp://ftp.andrew.cmu.edu/pub/argus/
See also recent discussions on future plans:
http://www.veriguard.com/Archive/Argus/2000/msg001 61.html
--Neal
Some of the uses you suggest would work just fine, as long as no one has the incentive to modify the file so it still sounds fine but has a different fingerprint.
Keeping it a "secret" and selling it to the clueless music industry for "watermark-like" purposes might make some money and work for a little while.
But as soon as people know how the algorithm works it is clear that someone will come up with a way to subtly change the file so your particular scheme is not a reliable fingerprint. I.e. the modified file will have a different fingerprint but it will still sound good enough to folks that the music industry will want to cry foul about the technique. And people will figure out how the algorithm works whether you want them to or not. That is just the way the world of security works.
--Neal
But Brumleve describes another problem with BOURLConnection and BOURLInputStream that allows the applet to read local files. Can someone help us with that one also?
Cheers,
--Neal
No reply yet....
Re: http://www.webstandards.org/
I was excited to hear that WaSP was advising web authors to
avoid browser-specific tags.
But I'm tempted to write you off as clueless because you use
HTML and CSS features that produce horrid pages in one of
the most common browsers - netscape.
For people like me who try to save our eyesight by configuring
netscape to use large fonts, your pages yield unreadable text. It may
be that this is a problem with netscape browsers (I'm using 4.72 on
Solaris), but all it does is restrict your readership.
E.g., on your home page, the text "LATEST BUZZ" overlapps itself.
It uses the 'class="buzz"' attribute.
Please stop selecting specific fonts and sizes in your wsp.css file.
Fonts are platform-specific. Help users to control their own browser
experience. See
Learning HTML 3.2 by examples: http://www.hut.fi/~jkorpela/HTML3.2/
for more of the technical issues and background philosophy.
Keep on advocating for standards-compliance, and hold netscape's toes
to the fire also, but advocate for interoperability also.
--Neal
--Neal
So if you have connections in Boulder County CO, check us out! E.g. a slashdot clone focussed on Boulder issues would be a great community-builder, and the model could be replicated elsewhere.
See also our list of community network information at Community Networking and Building Community: Online Resources
--Neal
The Fortune 500 firm I work for has to look at both the short term and the long term. Many of us focus on the long term, where it is important to avoid becoming locked into proprietary systems which may lose support when the original owners either go out of business or decide to force us into costly upgrades by designing in incompatibility.
Others are focussed on the short term where active support is more important because the software is new/buggy and is being integrated into other systems.
So for situations where traditional reasons for going Open Source don't look attractive to you, consider something like a contract with FSF that in a few years a given body of source becomes assigned to them and GPL'd. This would help sell the original product to folks like us so it would be a win for you also. And in n years you could leave the support headaches to the community and embark on your next cool idea.
--Neal
For more details on this IEC/IEEE/CIPM standard, adopted December 1998, see http://physics.nist.gov/cuu/Units/binary.html
Note that the first syllable of the name of the binary-multiple prefix should be pronounced in the same way as the first syllable of the name of the corresponding SI prefix, and that the second syllable should be pronounced as "bee."
--Neal
Subject: Proposed Patent Law Treaty changes are bad for the public
This is a response to:
http://www.uspto.gov/web/offices/com/sol/notices/
[Federal Register: March 9, 2000 (Volume 65, Number 47)] [Notices]
[Page 12515-12517] From the Federal Register Online via GPO Access
[wais.access.gpo.gov] [DOCID:fr09mr00-46];
http://www.wipo.int/scp
The current patent rules already are bad for the general public, and
your "Basic Proposal" would make the situation worse. To summarize:
"Innovate, don't Litigate!"
The proposal is focussed on helping those who want to claim
patent monopoly rights:
The objective of the meetings has been to develop a Basic Proposal,
consisting of articles and regulations, which will minimize the
formal requirements associated with patent applications and
patents. Upon adoption, these articles and rules will simplify the
formal obligations and reduce associated costs for patent applicants
and owners of patents in obtaining and preserving their rights in
inventions in many countries of the world.
Why do we grant patent monopolies in the first place? The US
Constitution, in Article I, section 8, gives the congress power:
"To promote the Progress of Science and useful Arts, by securing for
limited Times to Authors and Inventors the exclusive Right to their
respective Writings and Discoveries;"
Rights are only to be offered to inventors in order to "promote the
Progress of Science and useful Arts".
But the current patent rules, especially as applied to the field of
computer software, are hindering rather than promoting progress.
Your proposal to minimize formal requirements and reduce costs for
patent applications benefits those who claim to have invented things,
but the net result is an increased set of requirements and costs for
those actually making progress in science and useful arts. In the
current marketplace the innovative programmer is driven to invent
things in order to be "first to market" and they require no patent
protection as incentive. Instead, they must guard against the fear
that others with money to spend on patent lawyers will prevent them
from using obvious ideas or charge them fees in ways that limit the
possible distribution methods for their work.
I endorse the proposals at
http://lpf.ai.mit.edu/
which I incorporate by reference into this response.
There is wide support (see editorials in Forbes, Barrons and The
Economist, among others) for the notion that software patents are
impeding many aspects of technology today. Many high-tech firms
support this notion, but are forced to divert precious recources into
the filing of "defensive patents".
I'm particularly alarmed at the notion that people from other
countries would be able to claim a "filing date" in our country
after submitting a minimal set of material in "any language":
[A country] must provide a filing date for an application as of the
date on which its Office has received the following elements:
(i) An indication that submitted elements are intended to be an
application;
(ii) Indications allowing the identity of the applicant to be
established or allowing the applicant to be contacted; and
(iii) A description.
This filing date requirement is fairly minimal and would greatly
simplify the conditions imposed upon the grant of filing dates to
patent applications throughout the world. Note that this article
would mandate the acceptance, for filing date purposes, of patent
applications in any language, subject to the furnishing of later
translations. The USPTO has supported this article, with the
knowledge that our claim requirement, for filing date purposes, in
section 111(a) of title 35, United States [[Page 12517]] Code, would
have to be deleted.
We need to raise, not lower, the cost of patent applications so that
we can have more competent patent examiners.
We need to exclude software from the domain of patents. Inventors
should use copyright and trade secret protections instead.
Since the rate of progress is faster, the term of patents should be
lowered substantially.
We need to make patents public upon initial application so that
experts can comment on their innovativeness before they are granted.
Please fight any proposals that would disadvantage the general public
by stifling rather than encouraging innovation. We must grant patents
for the benefit of the general population, not to provide lopsided
benefits to those who want to use the system to prevent others
from delivering innovations to the public.
Thank you.
--Neal
Is this really is the very inventor of SRP, Thomas Wu, speaking? Assuming that it is, welcome to the party! I'll make the same plea I made in email to you 2 years ago - splash this news all over the web page! I think the world will take SRP far more seriously if you will put that in writing and avoid ambiguity. E.g. can people sell their own SRP implementations without a license? Without a fee?. The appropriate way to do so is to write a letter to the IETF along the lines of
http://www.ietf.org/ipr.html
It will need to be in legal language. In my experience, IETF won't be interested in putting it on the standards track unless it uses the model of the SSL patent from Netscape: free for *all* uses (not just open-source or non-commercial), reserving only the right to use it defensively, i.e. preventing other companies from going after you for infringing patents on SRP-related stuff that they may assert. E.g.: from RFC2246 on TLS (the successor to SSL):
Thanks, Thomas!--Neal
I see little evidence for this, and there are lots of hints otherwise. Previous versions of the SRP license contained the warning
The page http://srp.stanford.edu/ says "This link is currently limited to Stanford users pending resolution of patent negotiations. Sorry!"Two years ago I sent email to Thomas Wu asking if it was patented and got no response. Other people I've talked to also are concerned about this.
So while I can't point to clear evidence of patents, I urge great caution with SRP until a definitive answer on this question is provided. I like SRP, but the advantages over SSH are marginal enough that the intellectual property questions are far more important.
On another front, SRP is promoted because it allows users to choose their own easily-remembered passwords. But Bruce Schneier notes that computers are already fast enough to basically search the entire space of passwords that are easy for humans to remember. So if the password file on an SRP server is compromised, the passwords can be cracked if you try hard enough. I'm sure it is very expensive now, but over time the cost of doing this will drop since human memory capacity is not increasing.
--Neal
current aurora activity:
Auroral Activity Extrapolated from NOAA POES
http://www.sec.noaa.gov/pmap/index.html
gopher://sec.noaa.gov/00/forecasts/ALTS.txt
http://www.sec.noaa.gov/info/kp-aurora.html
http://uvisun.msfc.nasa.gov/UVI/current_image.h
http://solar.uleth.ca/www/auroras.html
--Neal
So both Cruithne and Moon trace out a repeatable path with respect to the Earth, but both can be considered to really orbit the Sun.
--Neal
Complain to antitrust@ftc.gov and newcase.atr@usdoj.gov (see http://www.usdoj.gov/atr/contact/newcase.htm ). They do listen sometimes!
--Neal
In Boston in 1978 or 1979 I saw a demo of a CAD program that used "unistrokes" to enter CAD commands. It is hard to believe that no one thought of using "unistrokes" for entering text until Xerox did in October of 1995, or that that isn't an obvious derivation of the CAD work, which even if it was patented would already be expired.
--Neal