From: Dan Moniz (dnm pobox.com)
Date: Thu Dec 28 2000 - 07:34:10 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
I figured I'd reply to your original mail, although I've been following the
thread thus far.
At 11:41 PM 12/24/2000 -0800, you wrote:
>Given the current total lack of encrypted mail in the world, I would like
>to undertake to create a new format which only stops passive attacks but
>is usable. It should meet the following criteria -
>
>1) Encrypts a reasonably large amount of mail
>
>2) Invisible to the user under normal circumstances
>
>3) Easy to recover when it malfunctions/user loses state
>
>4) Easy to implement
>
>Previous encrypted mail projects have shown outright disdain for goals 2,
>3, and 4.
Indeed. Everyone (although I'm sure most already have) should read the
paper _Why Johnny Can't Encrypt_.
>My vision is as follows -
[snip]
>When Alice sends her first piece of mail to Bob, it's plaintext, but with
>a MIME attachment (or maybe a header line) included giving her public key.
>
>When Bob responds, he encrypts using the key Alice sent, and sends a
>key of his own. Hence, all mail after the first piece is encrypted.
In the commercial arena, there's a product that might suit most of these
needs, assuming I understand them correctly. It's probably a bit
heavyweight, but I'll explain that below.
Viasec Limited (http://www.viasec.com/) makes a product called Consus that
serves as a server-based (NT) mail encryption gateway. It's targeted to the
small-business and enterprise markets, and prides itself on absolutely zero
user training.
Bias disclosure: I used to work in R&D for Viasec.
>The public key format consists of a public key, the corresponding private
>key encrypted with some symmetric key, and a MAC for the private key. This
>way everything is based on a nice short symmetric key, so if Bob starts
>using a new mail client which also supports Envelope Mail, he can get his
>password from his previous mail client and add it to the new one, thus
>being able to read all his mail.
Consus attempts to be a complete X.509 CA within your organization. This
is, of course, massively heavyweight for your proposed design, and I have
my own gripes with X.509, but it does mean you get that S/MIME support if
you want it.
I submit that there's nothing that Consus does w/r/t your proposal that you
couldn't hack together with toolkits like OpenSSL or Cryptlib for free.
>In case Bob starts using a mail client which doesn't support envelope mail
>at all, Alice has a policy of reverting to plaintext mail to Bob every
>time she gets mail from him with no crypto information. That way, if Bob
>gets mail he can't read from Alice he can respond saying 'uh, what was
>that?' and she can send again. Of course, it's necessary to recognize mail
>which was sent via a mailing list and not revert to plaintext because of
>that, but most mailing lists (unlike one run by a certain Dr. Goldberg)
>munge headers in reasonably identifiable ways.
Again, Consus tries to overcome the client support issue, but obviously
you're tied to a certain location with a server-based product (all mail has
to be sent such that it comes from the internal network and then through
Consus to the outside world to derive it's benefit. Although, for purely
passive attacks, I suppose you could make Consus an open gateway), and then
we're potentially talking VPN etc.
--
Dan Moniz <dnmpobox.com> [http://www.pobox.com/~dnm/]
From: Dan Moniz (dnmpobox.com)
Date: Thu Dec 28 2000 - 08:56:09 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Hi all,
I was wondering if anyone had any information on freely available
(preferably public domain or artistic license, other open source licenses
are potentially okay too) OpenPGP libraries in C (or, should I be really
lucky, as VB 6 controls).
Essentially, I want to be able to perform OpenPGP certificate generation,
signature verification, revocation certificate generation, etc. etc. from
VB, either by interfacing C DLLs or using VB controls (if anyone's tackled
this). The only way I see to do this currently is to munge the GNUPG
codebase into the appropriate DLLs and then interface those to VB.
Anyone else have better ideas/some pointers?
Thanks in advance,
--
Dan Moniz <dnmpobox.com> [http://www.pobox.com/~dnm/]
From: Alex Alten (AltenHome.Com)
Date: Fri Jan 05 2001 - 02:41:36 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
A rumor over on the ipsec mailing list mentions that there is
a sniff tool that can crack SSL. Would anyone here know anything
at all about this? Is there a man-in-the-middle attack that
doesn't require a trusted server certificate?
- Alex
--
Alex Alten
AltenHome.Com
From: sao19677terra.com.br
Date: Fri Jan 05 2001 - 03:59:21 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Hi,
Is there any standard format (defined in terms of ASN.1,
etc.) to represent Shamir shares? Or at least an OID?
Thanks in advance for any hints/links,
Paulo Barreto.
From: James A. Donald (jamesdecheque.com)
Date: Fri Jan 05 2001 - 02:06:35 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
--
t 01:05 PM 1/2/2001 -0500, Peter Wayner wrote:
> I realize I should know the answer to this, but I've been buried for
> the last several months.
No you should not, because nobody knows the rules, and the government likes
it that way.
> What are the export rules for crypto code that is covered by the GNU
> license? Can you just put it on a website?
Arguably recent court cases and policy indications mean that you can. Lots
of people do. None of us have got in trouble yet.
> Are those 7 bad countries still on the list?
All crypto laws are still arguably in effect, and also arguably not in
effect. New laws have been passed, and old laws not repealed.
> Has anyone written any perl scripts to filter out those countries?
> Do I have to send some notice to someone?
Arguably you do, but I would not bother.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
18Kz1RlM4vOdUJYulOHInrVl1io0nvLujG8FS1ij
4qjiVY5KOzIAVEDlxn7pjBDsAmixgSe7hWECSk3NG
From: Pete Chown (Pete.Chownskygate.co.uk)
Date: Fri Jan 05 2001 - 04:56:28 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
With all the talk about making crypto usable, I thought I would find
out what people thought of my own system.
I haven't yet found anyone who can't use Whisper. Whisper does PKCS#5
but with a particular emphasis on usability. I might extend it later
to do other things but the emphasis will always be on producing
something that is easily understood. Whisper currently runs on Linux
and Windows.
Whisper also produces messages that you can write down if you have to.
The output avoids characters that are likely to be mistyped, for
example "O" and "0". Because there is no session key to exchange,
short messages have short ciphertexts. The shortest possible message
is nine characters. (The plaintext is a single character.)
Whisper has a home page at:
http://234.cx/whisper.php
and there is a SourceForge project at:
http://sourceforge.net/projects/whisper/
--
Pete
From: Peter Gutmann (pgut001cs.auckland.ac.nz)
Date: Sat Jan 06 2001 - 00:53:01 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
sao19677terra.com.br writes:
>Is there any standard format (defined in terms of ASN.1, etc.) to represent
>Shamir shares? Or at least an OID?
No. I asked Burt Kaliski about doing this as a PKCS some time ago and from
memory there had been some vague interest in this but nothing more than that.
I have a format I created years ago for SFS which it might be possible to
adapt, but it's actually a considerable job to come up with a design capable
of handling all the necessary complexities (when I last did this five or so
years ago what killed it wasn't the implementation but the complexity of
managing the shares and handling the user interface to it).
Is there any interest in this sort of thing (by "real interest" I mean one or
more people who'd be willing to work on a PKCS or RFC)?
Peter.
From: Nelson Brito (a.k.a. stderr) (stderrsekure.org)
Date: Fri Jan 05 2001 - 06:45:57 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Alex Alten wrote:
> A rumor over on the ipsec mailing list mentions that there is
> a sniff tool that can crack SSL. Would anyone here know anything
> at all about this?
Yeah, and can sniff a SSH connections etheir. The prodiggy's name is
"dsniff".
> Is there a man-in-the-middle attack that
> doesn't require a trusted server certificate?
No, It's not a man-in-the-midle attack, it's only capture the certify
and the key, I think so.
>
> - Alex
> --
>
> Alex Alten
>
> AltenHome.Com
>
>
>
>
If you wanna to know more about this program, just look at:
http://www.monkey.org/~dugsong/dsniff/
Sem mais,
--
Nelson Brito
Security Analyst
Security Networks AG / IBQN
http://www.secunet.de/
From: Lewis McCarthy (pseudonymacm.org)
Date: Fri Jan 05 2001 - 07:01:30 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Hi,
Alex Alten wrote:
> A rumor over on the ipsec mailing list mentions that there is
> a sniff tool that can crack SSL. Would anyone here know anything
> at all about this? Is there a man-in-the-middle attack that
> doesn't require a trusted server certificate?
This was apparently in reference to the earlier posted URL
http://securityportal.com/cover/coverstory20001218.html
for an article by Kurt Seifried entitled "The End of SSL and
SSH?". Seifried discusses dsniff 2.3, a suite of sniffers
put together by Dug Song.
Dug has a good FAQ linked from the dsniff home page.
See e.g.
http://www.monkey.org/%7Edugsong/dsniff/faq.html#How do I sniff / hijack HTTPS / SSH connections
As some people have written on the IPsec list, dsniff isn't
using (nor claiming to use) attacks on the SSL protocol per se.
Seifried implies that dsniff exploits the known protocol weaknesses
of SSHv1 against MITM attacks. There are people out there still
*installing* SSHv1 these days, not to mention all the folks still
using SSHv1 rather than a v2 release.
-Lewis
--
http://home.att.net/~lewis.mccarthy
pseudonymacm.org 1-408-499-5708 UTC-07
"...it seems to me that women want men to be men.
This is a new idea to me. In my quite misguided youth,
I believed what the quite misguided women of my age
said when they told me and my fellows that what was
required for a happy union was a man who was, in all
things save plumbing, more or less a woman."
--David Mamet, 'In the Company of Men', 1990
From: Ben Laurie (benalgroup.co.uk)
Date: Fri Jan 05 2001 - 07:44:16 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Alex Alten wrote:
>
> A rumor over on the ipsec mailing list mentions that there is
> a sniff tool that can crack SSL. Would anyone here know anything
> at all about this? Is there a man-in-the-middle attack that
> doesn't require a trusted server certificate?
There's a sniffer that cracks SSL given appropriate keying material.
Naturally, this is not usually available.
http://www.rtfm.com/ssldump/
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
From: Niels Möller (nisselysator.liu.se)
Date: Fri Jan 05 2001 - 09:22:44 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Eric Rescorla <ekrspeedy.rtfm.com> writes:
> More or less. Actually it's bits 4-9 (counting from the low order)
> because we need the prime to be 3 mod 8 in order for two to be
> a generator.
...
> The hint is intended to be memorized by the user and therefore must be
> fairly small.
Would it break something to have the server provide the hint (together
with any needed salt)?
> For more information, see the draft: draft-perlman-strong-cred-00.txt.
Thanks for the reference. I have to read that. It does sound interesting.
Regards,
/Niels
From: Werner Koch (wkgnupg.org)
Date: Fri Jan 05 2001 - 08:52:50 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
On Thu, 28 Dec 2000, Dan Moniz wrote:
> VB, either by interfacing C DLLs or using VB controls (if anyone's tackled
> this). The only way I see to do this currently is to munge the GNUPG
> codebase into the appropriate DLLs and then interface those to VB.
I am currently working on GPGME which is a library to do that all.
Currently it uses GnuPG as it's backend but there are enhancements
(coming) which will let GnuPG run as a Coprocess and thereby
avoiding the fork/exec overhead. The big advantage of this lib is
that it brings you an easy to use interface.
And yes, it runs on Windows. Furthermore I started to work on a
COM+ component, so that it can be used vom VB.
GPGME is currently used to bring OpenPGP support to several MUAs:
Evolution, Spruce and Sylpheed are in the works and at least Spruce
has shown to be able to run on Windows.
See the http://cvs.gnupg.org or
ftp://ftp.guug.de/pub/gcrypt/alpha/gpgme
Werner
From: R. A. Hettinga (rahshipwright.com)
Date: Fri Jan 05 2001 - 10:48:17 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
--- begin forwarded text
Date: Fri, 5 Jan 2001 09:46:30 -0500
From: t byfield <tbyfieldpanix.com>
To: Nettime <nettime-lbbs.thing.net>
Subject: <nettime> [udhaypobox.com: Announcing Cypherpunks-India]
Sender: nettime-l-requestbbs.thing.net
Reply-To: t byfield <tbyfieldpanix.com>
----- Forwarded
Date: Fri, 05 Jan 2001 18:57:08 +0530
To: A Whole Bunch Of People and Mailing Lists <udhaypobox.com>
From: Udhay Shankar N <udhaypobox.com>
Subject: [IRR] Announcing Cypherpunks-India
-----BEGIN PGP SIGNED MESSAGE-----
***Please circulate to all interested parties***
This is to announce the Cypherpunks-India mailing list. The list is
for cypherpunks in India, and for those who want to track the
convergence of cryptography, politics and society here.
As you know, I volunteered to organise cypherpunks fleshmeets in
Bangalore a few months ago. We had an initial meet with some hoopla,
along with the Linux-India monthly meet in Bangalore. Public
meetings, however, have not happened since then (as opposed to the
private meetings and interactions - you know who you are.). It's been
difficult co-ordinating with people, who are mostly madly busy and
geographically distributed throughout India. This list, therefore, is
a first step towards giving some structure to the various
behind-the-scenes interactions we've been having, and to spread
awareness of crypto and how it impacts commerce and politics today.
The list is kindly hosted by Vipul Ved Prakash, who needs no
introduction to crypto observers here. Vipul also hosts
http://munitions.vipul.net - which is an archive of crypto software
that is mirrored across multiple locations. Vipul also was one of the
finalists in the 3rd Annual Obfuscated Perl Contest with his
dimunitive implementation of the Russian GOST algorithm.
To subscribe, use any ONE of the following URLs:
<http://lists.vipul.net/mailman/listinfo/cpunks-india>
<mailto:cpunks-india-requestlists.vipul.net?subject=subscribe>
In the next few days, as things evolve, we will put up some more
information at the URLs above.
Thanks for all your support, and see you on the list!
Udhay
- --
((Udhay Shankar N)) ((udhay pobox.com)) ((www.digeratus.com))
God is silent. Now if we can only get Man to shut up.
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
iQEVAwUBOlV+M6iP/rXKpnQVAQFmMwf+NYjR8zHda7dK+UIEuO22SC2vVPxa2OTc
q1wUc9x9BTuco0aQi5cS2CE/sgFzr/RC2BZ20CZh9D1wbgOa5Vv7hVPZa1EmOYS/
hBNHYPDdnEPGoJV9KSW1KBxe1roz8ydDVqJAdxLlQmr6+aQpKba1ORgqZGuAF1jB
1SpKZhZkeoRG2r1+kOek2p7XG1NthOVvkV7iu0iA76Uw3/alButlqjASCVRkUK4D
hPM9VO1/9Ao7KpnfOVmO4FJiHeO7/U/fMMn5q0bC5/qQzTZj0kLEst3FJbsTtgzy
GjC8lmoU5mjt7XqlHRVgpF2NZpb2Au+8JOi3uIcy03zfEOB4ceQRFA==
=ivkC
-----END PGP SIGNATURE-----
----- Backwarded
--
\|/ ____ \|/
~/ oO \~ <http://www.tbtf.com/roving_reporter/>
/_( \__/ )_\
\_U__/
# distributed via <nettime>: no commercial use without permission
# <nettime> is a moderated mailing list for net criticism,
# collaborative text filtering and cultural politics of the nets
# more info: majordomobbs.thing.net and "info nettime-l" in the msg body
# archive: http://www.nettime.org contact: nettimebbs.thing.net
--- end forwarded text
--
-----------------
R. A. Hettinga <mailto: rahibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
From: David Jablon (dpjworld.std.com)
Date: Fri Jan 05 2001 - 12:09:40 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
At 04:22 PM 1/5/01 +0100, Niels Möller wrote:
>Would it break something to have the server provide the hint (together
>with any needed salt)?
The hint represents several bits of information about the password.
In an application where the user can have a role in choosing the password,
it is bad for the server to leak out such information to anyone who asks.
In an application that strictly uses machine-selected passwords, one would have
to increase the password space by an appropriate amount to compensate for
such leakage, so the user effectively must remember the same number of bits.
Nothing particularly "broken" in this case, but there's no net improvement in
convenience and security.
-- David
At 04:22 PM 1/5/01 +0100, Niels Möller wrote:
>Eric Rescorla <ekrspeedy.rtfm.com> writes:
> > More or less. Actually it's bits 4-9 (counting from the low order)
> > because we need the prime to be 3 mod 8 in order for two to be
> > a generator.
>...
> > The hint is intended to be memorized by the user and therefore must be
> > fairly small.
>
>Would it break something to have the server provide the hint (together
>with any needed salt)?
>
> > For more information, see the draft: draft-perlman-strong-cred-00.txt.
>
>Thanks for the reference. I have to read that. It does sound interesting.
>
>Regards,
>/Niels
From: Daniel Roethlisberger (adminroe.ch)
Date: Fri Jan 05 2001 - 15:07:21 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
>> A rumor over on the ipsec mailing list mentions that there is
>> a sniff tool that can crack SSL. Would anyone here know anything
>> at all about this? Is there a man-in-the-middle attack that
>> doesn't require a trusted server certificate?
-snip-
It all boils down to: you do not need a trusted server
certificate, but if you are using an untrusted cert, some clients
(browsers) may pop up a window asking the user whether the cert
is ok to use, while some other clients don't allow communicating
with untrusted servers.
It's essentially the same with SSH, which can be attacked in the
exact same way by dsniff's MITM tools. Only that some SSH
implementations (in default configuration) only notify the user
about a changed server certificate, and do not state too clearly
that this is possibly a MITM-attack. Most common users will just
say yes to such questions and use the new server cert anyway.
All this is no news. In my eyes, it's all about the basic problem
of trust that every PKI system has, which allows users to trust
untrusted/uncertified public keys. However, Dug's dsniff appears
to be the first publically available toolkit to provide the means
to actually run such an attack. With the latest hype following
its release, this has now become a real world threat to SSH/SSL
systems, while it was somewhat theoretical before.
Cheers,
Dan
--
Daniel Roethlisberger
PGP 0x8DE543ED 6C10 83D7 2BB8 D908 10AE 7FA3 0779 0355 8DE5 43ED
From: Alex Alten (Altenhome.com)
Date: Fri Jan 05 2001 - 21:48:09 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
At 10:07 PM 1/5/2001 +0100, Daniel Roethlisberger wrote:
>
>>> A rumor over on the ipsec mailing list mentions that there is
>>> a sniff tool that can crack SSL. Would anyone here know anything
>>> at all about this? Is there a man-in-the-middle attack that
>>> doesn't require a trusted server certificate?
>
>-snip-
>
>It all boils down to: you do not need a trusted server
>certificate, but if you are using an untrusted cert, some clients
>(browsers) may pop up a window asking the user whether the cert
>is ok to use, while some other clients don't allow communicating
>with untrusted servers.
>
I guess things would get real interesting if the private key to a trusted
intermediate or root certificate authority got stolen and published. It
might take a while to update all the browsers out there to not accept it
as a valid signer of server certificates.
- Alex
--
Alex Alten
AltenHome.Com
From: Bram Cohen (bramgawth.com)
Date: Fri Jan 05 2001 - 23:17:25 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
On Fri, 5 Jan 2001, Alex Alten wrote:
>
> I guess things would get real interesting if the private key to a trusted
> intermediate or root certificate authority got stolen and published. It
> might take a while to update all the browsers out there to not accept it
> as a valid signer of server certificates.
Yeah, lots of web sites would start signing their own certificates because
they'd see no reason to fork over the $700 or whatever it is to Verisign,
then Verisign would start threatening to sue all of them for violating
trade secrets and copyright on the root key.
Ironically, it probably wouldn't have any effect on security whatsoever -
you can MITM web sites just fine anyway and just make client connections
unencrypted, hardly anyone would notice. The real security behind credit
card transactions is in the difficulty of cashing in on a whole bunch of
credit card numbers anonymously.
-Bram Cohen
"Markets can remain irrational longer than you can remain solvent"
-- John Maynard Keynes
From: Marcus Watts (mdwumich.edu)
Date: Sat Jan 06 2001 - 00:13:55 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Bram Cohen <bramgawth.com> writes:
> Yeah, lots of web sites would start signing their own certificates because
> they'd see no reason to fork over the $700 or whatever it is to Verisign,
> then Verisign would start threatening to sue all of them for violating
> trade secrets and copyright on the root key.
Um, probably not. Firstly, most people who are trying to operate a
legitimate business have little interest in going "pirate". It's
simply not worth their while. Secondly, you can only copyright an
original creative work that you publish - it would be quite a stretch
to claim copyright on something that is not a creative work and
by definition is only useful if it's not published. Trade secret
might work, depending on *how* it was stolen. Electronic fraud and
theft of data is more likely than either, I should think. Not that
it really matters-- there's bound to be something, but it may vary
from state to state, and certainly varies country by country.
>
> Ironically, it probably wouldn't have any effect on security whatsoever -
> you can MITM web sites just fine anyway and just make client connections
> unencrypted, hardly anyone would notice. The real security behind credit
> card transactions is in the difficulty of cashing in on a whole bunch of
> credit card numbers anonymously.
You obviously aren't familiar with the stolen credit card industry.
There's a well developed industry that does this. At one point, the
typical scheme is to transmit the #'s to various cohorts in other parts
of the country. The cohorts then go and use each number to make a
bunch of expensive purchases, throws the number away, turns the
expensive goods into cheap cash, and moves on to another state. This
typically takes only a day. By the time the legitimate owner finds all
this out, it's ancient history. The cohort is long gone, the goods are
vanished, &etc. The last figure I heard is that the fraud figure is
something like 8%. That figure is just another *expense* to credit
card companies - a cost of doing business. Naturally, credit card
companies *do* try to make this not work - but there's only so much
they can do without annoying legitimate customers, and the crooks are
pretty smart and can change their game as well.
Like all the rest of us, the credit card companies find that security
is a two-edged sword -- lax security costs in fraud, while tight
security annoys customers. What they're looking for is the happy
median which maximizes customer satisfaction while minimizing losses.
Not too long ago, there was a news report about a web site that had
been compromised, with the result that the bad guy had *many* thousands
of credit card #'s. I believe they were caught because they hadn't
figured out how to sell the credit card #'s to the right people to
exploit it. It's only a matter of time until credit card criminals
link up with computer vandals, and this becomes more common-place. I'm
not at all sure we'll hear about that, however. Apparently, in this
particular incident, a list of compromised credit card numbers had
been turned over to the credit card companies, but they never
bothered to contact their customers, so nobody was sure if the
credit card numbers got exploited or not.
-Marcus
From: Ian Grigg (iangsystemics.com)
Date: Sat Jan 06 2001 - 07:59:02 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Marcus Watts wrote:
> You obviously aren't familiar with the stolen credit card industry.
> There's a well developed industry that does this.
Hey, I've lurked on this thread, but you just hit the issue which
has bugged me about SSL for the last 5 or 6 years... Assuming
that you are familiar with the stolen credit card industry, can
you answer the following question?
> Not too long ago, there was a news report about a web site that had
> been compromised, with the result that the bad guy had *many* thousands
> of credit card #'s.
Were the credit card numbers sniffed?
As in, were the numbers lifted off the connections? I'd
find that so unlikely as to be news in itself. In fact,
in the history of the net, I have never ever seen a report
that credit card numbers were lifted off of a connection.
Sure, plenty of hack jobs to dive into the database and
pull out thousands or millions of numbers, like that which
happened to egghead a while back. But there has never been
a single report, to my knowledge, of a credit card being
lifted off a connection and used in anger.
And, you'd think that there was ample justification for
this. After all, the nominal design goal for SSL and for
SET must have been something like "protect those numbers..."
Here's the clanger - sucking credit card numbers of the
net by sniffing is *so* unlikely that the presence or
otherwise of SSL makes, IMHO, no difference. In the early
days, a lot of merchants simply accepted credit cards over
email or over HTTP. And many still do, AFAIK (probably in
contravention of their agreement). Still no sniffing.
To swap the order of the words:
> Like all the rest of us, the credit card companies find that security
> is a two-edged sword -- lax security costs in fraud, while tight
> security annoys customers. What they're looking for is the happy
> median which maximizes customer satisfaction while minimizing losses.
Which is what SSH does, and it wins. SSH is a beautiful,
practical piece of engineering, because it makes the precise
compromise that avoids the uneccessary and thus achieves
universal acceptance in its field.
SSL, OTOH, is a broken piece of engineering, because it
tried to solve something that doesn't matter in the real
world. The added piece of complexity, certs, increase
its cost by a couple of orders of magnitude. And thus,
it failed to achieve dominance, it is only used where it
has to be used, rather than used everywhere it could be
used.
All of which is really based on the question: has the
credit card number ever been sniffed off the net, and
used in anger?
--
iang
From: Eric Rescorla (ekrspeedy.rtfm.com)
Date: Sat Jan 06 2001 - 09:57:38 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Ian Grigg <iangsystemics.com> writes:
> SSL, OTOH, is a broken piece of engineering, because it
> tried to solve something that doesn't matter in the real
> world. The added piece of complexity, certs, increase
> its cost by a couple of orders of magnitude. And thus,
> it failed to achieve dominance, it is only used where it
> has to be used, rather than used everywhere it could be
> used.
I don't think this assessment holds up in the real world. SSL *is*
universally accepted. It's implemented in every browser and server and
a large number of them have turned it on.
Here's a good test: has your mother ever used SSH? I bet
she's used SSL. I know both my parents have--though they probably
don't know it.
-Ekr
[Eric Rescorla ekrrtfm.com]
From: Ian Grigg (iangsystemics.com)
Date: Sat Jan 06 2001 - 10:36:49 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Hi Eric!
> Ian Grigg <iangsystemics.com> writes:
> > SSL, OTOH, is a broken piece of engineering...
Eric Rescorla wrote:
> I don't think this assessment holds up in the real world. SSL *is*
> universally accepted. It's implemented in every browser and server and
> a large number of them have turned it on.
This is where we differ. If SSL was universally accepted,
my site would run SSL, and so would yours. In practice,
it is only used where it is needed: where companies find
themselves browbeaten or scared into setting it up so that
they can conduct secure commerce (whatever that means!).
In contrast, SSH is used well in excess of actual need.
Once people try it, they use it for every terminal connection.
The only time people ever go back to telnet is if they are
stuck on some windows machine and can't install it easily
(a different sort of problem that we can't blame on the
design of SSH).
The difference is clear - SSH works out of the box. SSL
requires a whole bunch of nastiness with certificates and
such. Who has time for that nonsense, unless they *really*
need it?
Solution? Easy - add anon key exchange to servers (and
browsers), out of the box. But that's bound to spark another
thread :)
> Here's a good test: has your mother ever used SSH? I bet
> she's used SSL. I know both my parents have--though they probably
> don't know it.
Sure, but that's apples and oranges. SSH's user base is
people who use terminal connections, and in that user base
it dominates (at least in the Unix world, see above).
SSL's user base is people who browse. My point is not
that it is *not* out there, but that it is only used in a
tiny fraction of web sessions. It's almost unmeasurable,
less than 1% is my guess.
(As we are comparing engineering here, it is important to
isolate what the usage of the tool is going to be, not to
mix and match the user bases... Another way of looking at
this is to compare secure telnet against SSH. Same user base,
but secure telnet failed to be adopted and SSH cleaned the
boards.)
(Oh, and as an irrelevant aside, the one time my mother
bought something over the net using a credit card was over
an unencrypted HTTP session. (Flowers in Jersey, CI, if
anyone is interested in sniffing :) She asked me to check
out the site before doing it, and I confirmed who it was
by cross-linking it with the Jersey town council site via
an altavista search. She still doesn't know that her CC
was "exposed" to the unlikely risk of sniffing, and she
doesn't care. Her CC company will sort out any problems...)
--
iang
From: Eric Rescorla (ekrrtfm.com)
Date: Sat Jan 06 2001 - 10:58:03 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Ian Grigg writes:
> Eric Rescorla wrote:
>
> > I don't think this assessment holds up in the real world. SSL *is*
> > universally accepted. It's implemented in every browser and server and
> > a large number of them have turned it on.
>
> This is where we differ. If SSL was universally accepted,
> my site would run SSL, and so would yours. In practice,
> it is only used where it is needed: where companies find
> themselves browbeaten or scared into setting it up so that
> they can conduct secure commerce (whatever that means!).
> Solution? Easy - add anon key exchange to servers (and
> browsers), out of the box. But that's bound to spark another
> thread :)
Both browsers and servers ALREADY support anonymous connections. Just
use self-signed certificates. Sure the browser warns you but so what?
You can do EXACTLY the same thing with SSL (at least with Netscape)
that you can do with SSH: tell it to accept an unsigned certificate in
perpetuity.
> Sure, but that's apples and oranges. SSH's user base is
> people who use terminal connections, and in that user base
> it dominates (at least in the Unix world, see above).
Even this isn't true. Telnet is still very widely used.
I suspect that the problem here is availabity bias: you don't
see a random sample of users--and users who use terminal
connections aren't a random sample of Interent users.
> SSL's user base is people who browse. My point is not
> that it is *not* out there, but that it is only used in a
> tiny fraction of web sessions. It's almost unmeasurable,
> less than 1% is my guess.
I'm not convinced that the problem here is certificates. Rather, I
suspect that the problem is performance: Consider that even sites that
already have certificates still carry the vast majority of their
traffic over HTTP.
I agree with you to the following extent: SSH is better adapted to its
environment than SSL (though using some Zero-Knowledge Password
Protocol would make it even better suited), but this isn't a result of
SSH being better engineered but of the environment being easier to
adapt to: the user base is more clueful and you only connect to
a few machines.
-Ekr
From: Bram Cohen (bramgawth.com)
Date: Sat Jan 06 2001 - 12:12:55 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
On Sat, 6 Jan 2001, Marcus Watts wrote:
> Bram Cohen <bramgawth.com> writes:
> > Yeah, lots of web sites would start signing their own certificates because
> > they'd see no reason to fork over the $700 or whatever it is to Verisign,
> > then Verisign would start threatening to sue all of them for violating
> > trade secrets and copyright on the root key.
>
> Um, probably not. Firstly, most people who are trying to operate a
> legitimate business have little interest in going "pirate".
Most legitimate businesses would also be offended if you asked them to pay
you several hundred dollars for a cert which they could get for free and
provided no improvement in security whatsoever.
> Secondly, you can only copyright an original creative work that you
> publish - it would be quite a stretch to claim copyright on something
> that is not a creative work and by definition is only useful if it's
> not published.
That's exactly what's being done in the DVD case.
> Trade secret might work, depending on *how* it was stolen.
> Electronic fraud and theft of data is more likely than either, I
> should think.
Once the secret's out, trade secret no longer has a legal leg to stand on,
except against whoever originally leaked it. That wouldn't stop anyone
from suing.
> Not that it really matters-- there's bound to be something, but it may
> vary from state to state, and certainly varies country by country.
Lawyers will tell you the legal system works very well. Litigants will
tell you something else.
-Bram Cohen
"Markets can remain irrational longer than you can remain solvent"
-- John Maynard Keynes
From: Eric Murray (ericmlne.com)
Date: Sat Jan 06 2001 - 12:28:59 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
On Sat, Jan 06, 2001 at 09:59:02AM -0400, Ian Grigg wrote:
[..]
> SSL, OTOH, is a broken piece of engineering, because it
> tried to solve something that doesn't matter in the real
> world. The added piece of complexity, certs, increase
> its cost by a couple of orders of magnitude. And thus,
> it failed to achieve dominance, it is only used where it
> has to be used, rather than used everywhere it could be
> used.
>
> All of which is really based on the question: has the
> credit card number ever been sniffed off the net, and
> used in anger?
The CC companies don't publish instances of individuals CC numbers being
misuses. They just quietly reimbuse the victims to $50. Only big breaks
of many cards get publicised.
Even if these was no instances of CC nubers getting sniffed, it wouldn't
prove that SSL is broken or pointless... rather it's because there's
easier ways to get CC numbers, like stealing a file full of unencrypted
numbers from a poorly-secured server. If CC numbers were always protected
even as well as passwords are, there would be more instances of sniffing,
as there are with passwords.
--
Eric Murray Consulting Security Architect SecureDesign LLC
http://www.securedesignllc.com PGP keyid:E03F65E5
From: Ben Laurie (benalgroup.co.uk)
Date: Sat Jan 06 2001 - 13:02:11 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Ian Grigg wrote:
> The difference is clear - SSH works out of the box. SSL
> requires a whole bunch of nastiness with certificates and
> such. Who has time for that nonsense, unless they *really*
> need it?
>
> Solution? Easy - add anon key exchange to servers (and
> browsers), out of the box. But that's bound to spark another
> thread :)
The difference is that an ssh user typically owns both ends of the
connection. An SSL user only owns one. Which is why all that "nastiness
with certificates" goes on. If you want to avoid the nastiness the
modification to SSL is trivial: don't show the scary warning when the
server cert is not signed by the right guy.
Of course, this exposes you to the same vulnerability that ssh has (when
used incorrectly), i.e. a MitM attack. In the ssh case, this is
avoidable if people can be bothered to be careful enough, because of the
favourable ownership pattern, but it cannot be in the case of SSL.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
From: Bram Cohen (bramgawth.com)
Date: Sat Jan 06 2001 - 13:19:24 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
On Sat, 6 Jan 2001, Ben Laurie wrote:
> The difference is that an ssh user typically owns both ends of the
> connection. An SSL user only owns one. Which is why all that "nastiness
> with certificates" goes on. If you want to avoid the nastiness the
> modification to SSL is trivial: don't show the scary warning when the
> server cert is not signed by the right guy.
>
> Of course, this exposes you to the same vulnerability that ssh has (when
> used incorrectly), i.e. a MitM attack. In the ssh case, this is
> avoidable if people can be bothered to be careful enough, because of the
> favourable ownership pattern, but it cannot be in the case of SSL.
Uh ... oh no?
You can actually force the MitM attack to be pretty thorough by having
clients store the first key they get from a server and not accept any
others after that. This has the problem that someone could DoS by
redirecting dns to a bogus site with a bogus key though.
-Bram Cohen
"Markets can remain irrational longer than you can remain solvent"
-- John Maynard Keynes
From: Ian Grigg (iangsystemics.com)
Date: Sat Jan 06 2001 - 13:14:47 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Eric Rescorla wrote:
> Both browsers and servers ALREADY support anonymous connections.
There is a huge difference between SUPPORT and working out
of the box. In my world, httpd would work out of the box if
the server started up and created a self signed certificate
straight away and ran without any more intervention. Just
like sshd.
> Just
> use self-signed certificates. Sure the browser warns you but so what?
Right, and the five screens it subjects me too is definately
a turn-off for the average user, especially if they get to
the end and it warns you about the insecurity of this
communication for credit card numbers and so forth.
If we look at the engineering picture in the large, SSH
accepts that connection and doesn't worry the user if the
only risk is the infinitesimally small chance of an MITM.
Then, it saves the self-signed cert and matches it in
future sessions, warning if there is a change.
SSL (or more properly, any brower that implements it)
assumes that the MITM is a serious danger and proceeds
to warn the user - to such an extent that everyone is
led to the belief that this is a broken site. This is
a travesty of risk management - which is why I'm real
keen on finding documented evidence of a real live MITM
(other than demos), or even just a credit card being
sniffed from an open connection.
If the SSL browser were well engineered to cope with
reasonable risks, it would connect immediately to the
self-authenticated server, and it would display a small
symbol down where the "lock" is that meant self-authenticated.
(It would also save that cert and maybe pop up a box if the
cert changed. Just like SSH.)
> You can do EXACTLY the same thing with SSL (at least with Netscape)
> that you can do with SSH: tell it to accept an unsigned certificate in
> perpetuity.
After the five boxes, sure. And what I can't seem to do is
turn off the paranoid behaviour for all self-signed sites.
> > Sure, but that's apples and oranges. SSH's user base is
> > people who use terminal connections, and in that user base
> > it dominates (at least in the Unix world, see above).
> Even this isn't true. Telnet is still very widely used.
> I suspect that the problem here is availabity bias: you don't
> see a random sample of users--and users who use terminal
> connections aren't a random sample of Interent users.
Well, this is why I qualify it to the Unix world, the original
user base for SSH. Telnet itself is widely used where SSH is
not easily available out of the box, sure, but those problems
are related to lack of good windows clients and distribution,
not to the overall engineering choices we are discussing here.
> > SSL's user base is people who browse. My point is not
> > that it is *not* out there, but that it is only used in a
> > tiny fraction of web sessions. It's almost unmeasurable,
> > less than 1% is my guess.
> I'm not convinced that the problem here is certificates. Rather, I
> suspect that the problem is performance: Consider that even sites that
> already have certificates still carry the vast majority of their
> traffic over HTTP.
True, performance is another consideration. But a secondary
one. The majority of sites that make this choice are large,
and thus are up against performance considerations because
they accept thousands of connections. But the real majority
of all sites couldn't care less about performance. They would
use SSL if it came by default, I suggest. Just like the nobody
cares about SSH performance.
(I once had a Sun IPC that consumed 12% of CPU for a single
SSH. So I switched from t-des to blowfish and it disappeared
from view... PCs these days can do a hundred public key
operations a second [type 'openssl', then 'speed rsa']. So,
yes, for the big sites this might be an issue. But not for
the vast majority.)
> I agree with you to the following extent: SSH is better adapted to its
> environment than SSL (though using some Zero-Knowledge Password
> Protocol would make it even better suited), but this isn't a result of
> SSH being better engineered but of the environment being easier to
> adapt to: the user base is more clueful and you only connect to
> a few machines.
I'm not actually sure of that - the browser base is apparently
good enough to understand what the little lock symbol is about.
(I don't see what number of machines has to do with it?
Hmm, maybe Ben's point pertains....)
Security is about risk management more than it is about
perfect protocols. The success of a good security system
is in protecting the most for the least cost. Within its
environment, SSH wins and SSL loses on a risk management
scorecard; SSL tried to be 100% secure and thus sacrificed
99% of its potential utility. SSH accepts 99% security
(the 1% being an exaggeration of the infamous MITM), and
achieved a dominating usage penetration.
Multiple those numbers to get a utility ratio. Call
SSH's market share in Unix terminal connections as 50%
and you get 4950. Half the uses are protected 99% of the
time.
Against SSL's paltry 100. Sure, we can debate this formula
for another 100 threads, but it is as good an index of the
success of the engineering choices as any other we're likely
to come up with.
--
iang
From: Eric Rescorla (ekrrtfm.com)
Date: Sat Jan 06 2001 - 13:58:53 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
> Eric Rescorla wrote:
>
> > Both browsers and servers ALREADY support anonymous connections.
>
> There is a huge difference between SUPPORT and working out
> of the box. In my world, httpd would work out of the box if
> the server started up and created a self signed certificate
> straight away and ran without any more intervention. Just
> like sshd.
As I said earlier, SSL operates under a different threat model
than SSH. SSH connections are by and large to servers you've
already contacted before. SSL needs to support spontaneous
connections to many hosts which you've never seen before and have
absolutely no prior relationship with.
> SSL (or more properly, any brower that implements it)
> assumes that the MITM is a serious danger and proceeds
> to warn the user - to such an extent that everyone is
> led to the belief that this is a broken site. This is
> a travesty of risk management - which is why I'm real
> keen on finding documented evidence of a real live MITM
> (other than demos), or even just a credit card being
> sniffed from an open connection.
I don't consider this to be a reasonable attitude when
designing a security system. There are lots of attacks on TCP
which were known when the protocol was designed (or shortly
thereafter) but which we're only now starting to see real attacks
based on.
One of the guiding principles of network security is to design
based on an attacker's capabilities, not his current behavior.
> After the five boxes, sure. And what I can't seem to do is
> turn off the paranoid behaviour for all self-signed sites.
It's a matter of opinion whether this is a bug or a feature. You can turn
it off for any SPECIFIC site.
We're now far off the track of discussing SSL the protocol. We're
discussing specific implementations. Not the same thing.
> > > Sure, but that's apples and oranges. SSH's user base is
> > > people who use terminal connections, and in that user base
> > > it dominates (at least in the Unix world, see above).
> > Even this isn't true. Telnet is still very widely used.
> > I suspect that the problem here is availabity bias: you don't
> > see a random sample of users--and users who use terminal
> > connections aren't a random sample of Interent users.
>
> Well, this is why I qualify it to the Unix world, the original
> user base for SSH.
Telnet is still widely used in the Unix world.
> Telnet itself is widely used where SSH is
> not easily available out of the box, sure, but those problems
> are related to lack of good windows clients and distribution,
> not to the overall engineering choices we are discussing here.
I disagree. Your argument hinges around the claim that SSH's
ubiquity is a result of superior engineering. The observation
that SSH isn't really ubiquitous destroys the very foundation of
your argument.
> True, performance is another consideration. But a secondary
> one. The majority of sites that make this choice are large,
> and thus are up against performance considerations because
> they accept thousands of connections. But the real majority
> of all sites couldn't care less about performance. They would
> use SSL if it came by default, I suggest. Just like the nobody
> cares about SSH performance.
>
> (I once had a Sun IPC that consumed 12% of CPU for a single
> SSH. So I switched from t-des to blowfish and it disappeared
> from view... PCs these days can do a hundred public key
> operations a second [type 'openssl', then 'speed rsa']. So,
> yes, for the big sites this might be an issue. But not for
> the vast majority.)
SSH has completely different perfromance behavior than SSL.
SSL performance is dominated by handshake, not data transmission
so the RSA operation is very important. Moreover, 'openssl speed rsa'
rather overestimates the performance of SSL on real systems.
Since you can't just switch out RSA, your story about switching from
3DES to Blowfish isn't really relevant. In fact, most SSL connections
already use RC4, which is even faster.
> > I agree with you to the following extent: SSH is better adapted to its
> > environment than SSL (though using some Zero-Knowledge Password
> > Protocol would make it even better suited), but this isn't a result of
> > SSH being better engineered but of the environment being easier to
> > adapt to: the user base is more clueful and you only connect to
> > a few machines.
>
> I'm not actually sure of that - the browser base is apparently
> good enough to understand what the little lock symbol is about.
>
> (I don't see what number of machines has to do with it?
> Hmm, maybe Ben's point pertains....)
The point is that the attacker only has a very few chances to
MITM SSH, because you have the one or two relevant keys cached.
This doesn't apply to SSL where you are likely to connect to a large
number of secure sites.
> Security is about risk management more than it is about
> perfect protocols. The success of a good security system
> is in protecting the most for the least cost. Within its
> environment, SSH wins and SSL loses on a risk management
> scorecard; SSL tried to be 100% secure and thus sacrificed
> 99% of its potential utility. SSH accepts 99% security
> (the 1% being an exaggeration of the infamous MITM), and
> achieved a dominating usage penetration.
The problem is that it your utility index is highly environment
specific. Sure, at the moment people don't actively attack SSL because
the tools weren't available and there was low hanging fruit. As other
easier security holes get closed, attackers will turn to the more
difficult ones. That's the case I believe we should design for.
If you don't agree with that design principle, I propose we
agree to disagree.
-Ekr
From: Bram Cohen (bramgawth.com)
Date: Sat Jan 06 2001 - 15:25:19 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
On Sat, 6 Jan 2001, Eric Rescorla wrote:
> > SSL (or more properly, any brower that implements it)
> > assumes that the MITM is a serious danger and proceeds
> > to warn the user - to such an extent that everyone is
> > led to the belief that this is a broken site. This is
> > a travesty of risk management - which is why I'm real
> > keen on finding documented evidence of a real live MITM
> > (other than demos), or even just a credit card being
> > sniffed from an open connection.
>
> I don't consider this to be a reasonable attitude when
> designing a security system. There are lots of attacks on TCP
> which were known when the protocol was designed (or shortly
> thereafter) but which we're only now starting to see real attacks
> based on.
So what? TCP/IP has been very successfull, and part of that success comes
from what at the time it was created were emminently reasonable tradeoffs
between performance and security. It's certainly better in that regard
than many of the protocols it beat out, which would go down accidentally,
without any sort of malicious intervention at all.
Besides, there's no way all the potential problems in TCP could have been
forseen and fixed beforehand. The correct way to deal with such problems
is to plan on a transition to something like IPv6, which is slowly in the
process of happening.
Projects which try to be perfect the first time always fail.
-Bram Cohen
"Markets can remain irrational longer than you can remain solvent"
-- John Maynard Keynes
From: Niels Möller (nisselysator.liu.se)
Date: Sat Jan 06 2001 - 15:32:00 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Jim Choate <ravagessz.com> writes:
> If I already trust the key why am I authenticating it?
This sounds confused. There are two things that have to be checked
before allowing access based on "public key" authentication:
1. That the public key is "authorized" or "trusted". This sounds
pretty vague, but what it really means is that there is some reason
to believe that every user who knows the corresponding _private_
key should be allowed access. Or put another way: that the owner of
the resource being accessed has delegated access to the owner of
that private key (whoever that owner is).
2. That the user at the other end indeed knows the corresponding
private keys.
For the basic public-key mechanisms in ssh (all versions), checking
(1) is simple but primitive: A public key is considered authorized iff
it is present in the authorized_keys database (or known_hosts
database, for server keys). It's up to the user and sysadm's to make
sure that databases matches reality. The protocol exchange only checks
(2).
If you use x509/spki/openpgp certificates, the server software and
protocol will do more of the work to check (1). No ssh implementation
I know of really implements that, though. Mine (lsh) aims at using
spki, but that support is still very limited.
Bottom line: The "auth" part in "SSH public-key authentication" refers
to authentication of a *user* (or server), not a key.
Regards,
/Niels
From: Eric Rescorla (ekrrtfm.com)
Date: Sat Jan 06 2001 - 15:48:02 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
> On Sat, 6 Jan 2001, Eric Rescorla wrote:
>
> > > SSL (or more properly, any brower that implements it)
> > > assumes that the MITM is a serious danger and proceeds
> > > to warn the user - to such an extent that everyone is
> > > led to the belief that this is a broken site. This is
> > > a travesty of risk management - which is why I'm real
> > > keen on finding documented evidence of a real live MITM
> > > (other than demos), or even just a credit card being
> > > sniffed from an open connection.
> >
> > I don't consider this to be a reasonable attitude when
> > designing a security system. There are lots of attacks on TCP
> > which were known when the protocol was designed (or shortly
> > thereafter) but which we're only now starting to see real attacks
> > based on.
>
> So what? TCP/IP has been very successfull, and part of that success comes
> from what at the time it was created were emminently reasonable tradeoffs
> between performance and security.
A number of the TCP security holes could have been prevented with
only trivial changes to the protocol--SYN flooding and TCP sequence number
prediction both come to mind.
-Ekr
From: Josh Crane (jcranebit.net.au)
Date: Sat Jan 06 2001 - 16:52:19 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
I've been watching this post for a while now, amongst others, and I think I
probably need an explanation in defence of SSL and any other session
encyption for that matter. You will understand what I mean after my
following comments.
To be honest, I'm not so sure I find any data xfer protection between hosts
all that relevant when there is so much capacity for direct host exploiting.
By and large, I believe there is far more apropriate vulnerabilities already
existing on the hosts themselves which would obviously allow interception of
pre encrypted data.
Despite what I've encountered to be popular belief, no server is wrapped up
so tight that it has become an iron box with a mere peephole, not even the
"big suckers". Why waste time in sniffing encrypted sessions when a simple
insertion point between data generation / aggregation and encryption
routines, or even better, manual data extraction, is near trivial compared
to all this talk of POTENTIAL, sometimes successful encryption breach.
All due credit to static encyption for long or even short term storage on
any given host, but again there is always a routine before encryption or
after decryption that can be penetrated or dis-assembled for exploitation.
Still, it is nice to (with ease) wrap up your stuff nice and tight to add an
extra step in potential accessibility, but certainly not to the point that
where we're so concerned with it that we seemingly try to make it the be all
and end all solution, because in reality I believe, it's almost nothing in
the link to actual breach.
Basically, if you've taken out the target, why must we concern ourselves
with actual data session encryption at all?
In argument to my point, I suppose it could be good to limit self-exposure
to the actual source and target of a given session to maintain anonymity,
but often times if you've exploited a hop on route for sniffing purposes,
you'd be cleaning your mess up as you go, hence making for a clear path of
attack directly to the host itself. Why not do it properly and really set
yourself up, instead of a mere sniff of what's in the link.
The only benefit of sniffing these sessions I guess is to identify what's
there in the first place, only if it can't be done through other means.
Though again, as I've seen in some discussion, it seems to me that it can be
somewhat of an effort or even cost to set up session encryption, which would
suggest that if it's there, it's worthwhile, otherwise they typcially
wouldn't have bothered, right?
Assuming that this is the type of predator that we'd ever be talking
about... i.e. not lazy and good at what they do, would they not take a
direct look anyway. Certainly anyone I know or have heard anything about
wouldn't stuff around and get directly in the host.
Cheers.
From: Boot Man (freesignupearthlink.net)
Date: Sat Jan 06 2001 - 16:24:15 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Dear coderpunkstoad.com,
*********STOCKING STUFFER***********
Got a New Hard Drive?
Are you a professional that builds or fixes computers?
Like To Play DUKE 3D or other DOS BASED GAMES?
Has your Computer ever CRASHED?
Just want to FORMAT and Start Over?
THE ABSOLUTE MUST HAVE FOR ANY COMPUTER USER!!
This Jam Packed Disk has Auto Drivers for Every CD-ROM on the Planet!
100% Guaranteed to work perfectly!
**********ORDER INFORMATION************
Get This Disk Now
http://greatbootdisk.allhere.com/
Secure Visa/MC through paypal.com
**********ORDER INFORMATION************
This disk is designed to aid with the install of Windows 95/98. This disk has been thoroughly tested and has worked every time!
The Ultimate Boot Disk also comes with a two page instruction guide to help with
Formatting your Hard Drive
AND
Setting Up Windows 95/98
**********ORDER INFORMATION************
Get This Disk Now
http://greatbootdisk.allhere.com/
Secure Visa/MC through paypal.com
**********ORDER INFORMATION************
ORDER FORM for Check/Money Order Payments:
--------------------------------------------------------------
Please send $7.50 to:
Boot Disk
2204 Florida Dr.
Fort Wayne, IN 46805
Name_____________________________________________
Address__________________________________________
City_____________________________________________
State / Zip______________________________________
Phone #: ________________________________________
(For problems with your order only. No salesmen will call.)
Email Address____________________________________
[ ] YES! Please rush my Ultimate Boot Disk. I
understand I have a 100% Satisfaction Guarantee and can return
my order for the purchase price at any time.
[ ] DOUBLE YES! I am ordering before January 31st 2000!
Please include the extra special bonuses!
Note - If ordering outside continental US, please add $2 to S&H
Get This Disk Now
http://greatbootdisk.allhere.com/
Secure Visa/MC through paypal.com
You are receiving this list because you were targeted as a person who prefers to pay through the online service paypal.com. This email was not sent out by Paypal or endorsed by the company itself.
To Remove Yourself From This List: reply to this email with the email
address that you would like removed and the word REMOVE in the subject heading.
From: Eric Rescorla (ekrrtfm.com)
Date: Sat Jan 06 2001 - 22:06:26 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
> I've been watching this post for a while now, amongst others, and I think I
> probably need an explanation in defence of SSL and any other session
> encyption for that matter. You will understand what I mean after my
> following comments.
>
> To be honest, I'm not so sure I find any data xfer protection between hosts
> all that relevant when there is so much capacity for direct host exploiting.
> By and large, I believe there is far more apropriate vulnerabilities already
> existing on the hosts themselves which would obviously allow interception of
> pre encrypted data.
>
> Despite what I've encountered to be popular belief, no server is wrapped up
> so tight that it has become an iron box with a mere peephole, not even the
> "big suckers". Why waste time in sniffing encrypted sessions when a simple
> insertion point between data generation / aggregation and encryption
> routines, or even better, manual data extraction, is near trivial compared
> to all this talk of POTENTIAL, sometimes successful encryption breach.
The whole purpose of encryption is to ensure that attacking the traffic is
not the easiest attack.
-Ekr
From: James H. Cloos Jr. (cloosjhcloos.com)
Date: Sat Jan 06 2001 - 23:04:53 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
>>>>> "Bram" == Bram Cohen <bramgawth.com> writes:
Bram> This has the problem that someone could DoS by redirecting dns
Bram> to a bogus site with a bogus key though.
Not really any different than redirecting toa bogus site w/ bogus
data, though, eh? Ie, no more of a problem than the status quo.
-JimC
--
James H. Cloos, Jr. <http://jhcloos.com/public_key> 1024D/ED7DAEA6
<cloosjhcloos.com> E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6
From: Olivier Galibert (galibertpobox.com)
Date: Sun Jan 07 2001 - 12:23:30 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
I have 32768 16bit values that are the result of the hardware
decryption of the same value (ffff) at 32768 consecutive adresses
(starting at f0000). Nobody knows how the encryption work, except
that it only depends on the address and the 16 bit value at that
address (no hidden state).
With these 36768 values, it should at least be possible to get a clue
on how the address indluences the process. Problem is, I have no idea
where to start. So it would be nice if you could point me to
resources (books, websites, whatever) on the subject. All I can find
is of the "algorithm known, key unknown" category.
OG.
PS: The 64K file is available on request for the curious.
From: Ben Laurie (benalgroup.co.uk)
Date: Sun Jan 07 2001 - 15:01:45 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Olivier Galibert wrote:
>
> I have 32768 16bit values that are the result of the hardware
> decryption of the same value (ffff) at 32768 consecutive adresses
> (starting at f0000). Nobody knows how the encryption work, except
> that it only depends on the address and the 16 bit value at that
> address (no hidden state).
>
> With these 36768 values, it should at least be possible to get a clue
> on how the address indluences the process. Problem is, I have no idea
> where to start. So it would be nice if you could point me to
> resources (books, websites, whatever) on the subject. All I can find
> is of the "algorithm known, key unknown" category.
Spot the guy who is trying to hack a ROM. What's the bets its in a
phone?
BTW, I did this once, many years ago - it helps to remember that
whatever the algorithm is is likely to be realisable in a relatively
small number of gates, and not involve arithmetic (as such). Since it
also has to be reversible (or, to put it another way, entropy
conserving), it is likely to be entirely composed of transpositions and
XORs.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
From: Olivier Galibert (galibertpobox.com)
Date: Sun Jan 07 2001 - 15:41:23 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
On Sun, Jan 07, 2001 at 09:01:45PM +0000, Ben Laurie wrote:
> Spot the guy who is trying to hack a ROM. What's the bets its in a
> phone?
Bet lost. Anybody reading slashdot recently should be able to guess
where the ROM is coming from ;-)
> BTW, I did this once, many years ago - it helps to remember that
> whatever the algorithm is is likely to be realisable in a relatively
> small number of gates, and not involve arithmetic (as such). Since it
> also has to be reversible (or, to put it another way, entropy
> conserving), it is likely to be entirely composed of transpositions and
> XORs.
Yup, that's what I'm thinking too. Also, this particular hardware
exists since 1993. It can't be that advanced.
OG.
From: Bram Cohen (bramgawth.com)
Date: Sun Jan 07 2001 - 17:00:15 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
On 6 Jan 2001, James H. Cloos Jr. wrote:
> >>>>> "Bram" == Bram Cohen <bramgawth.com> writes:
>
> Bram> This has the problem that someone could DoS by redirecting dns
> Bram> to a bogus site with a bogus key though.
>
> Not really any different than redirecting toa bogus site w/ bogus
> data, though, eh? Ie, no more of a problem than the status quo.
With the current system once the dns entry is fixed the end user can view
the site properly, if clients accepted all keys initially didn't allow
sites to change them later that wouldn't be the case.
-Bram Cohen
"Markets can remain irrational longer than you can remain solvent"
-- John Maynard Keynes
From: James H. Cloos Jr. (cloosjhcloos.com)
Date: Sun Jan 07 2001 - 19:01:50 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
>>>>> "Bram" == Bram Cohen <bramgawth.com> writes:
Bram> With the current system once the dns entry is fixed the end user
Bram> can view the site properly, if clients accepted all keys initially
Bram> didn't allow sites to change them later that wouldn't be the case.
I was thinking just of current clients and not of new ones.
Point well taken.
-JimC
--
James H. Cloos, Jr. <http://jhcloos.com/public_key> 1024D/ED7DAEA6
<cloosjhcloos.com> E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6
From: Bram Cohen (bramgawth.com)
Date: Sun Jan 07 2001 - 20:20:01 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Hey everyone, I have another question related to Envelope Mail :)
The way Envelope Mail uses crypto is pretty clear now, and it looks like
it might be possible for it to use PGP. Mostly, this depends on being able
to get an implementation of the following API -
String encrypt(String plaintext, String[] public_keys)
String decrypt(String ciphertext, String private_key)
String[] get_key_identifiers(String ciphertext)
I think this is essentially a very simplified version of the API for PGP,
so specific parameters would have to be picked. Does anyone know if my
sense is accurate, and if so, would you have suggestions for what the
parameters should be? (PGP version, cipher, key length, etc.)
-Bram Cohen
"Markets can remain irrational longer than you can remain solvent"
-- John Maynard Keynes
From: sbrown249excite.com
Date: Sat Jan 06 2001 - 11:50:02 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Looking For Sales, or Exposure,
we offer fresh targeted or general emails
sent for you with current email addresses.
Watch your business grow.
We GUARANTEE response !
* Daily reports on your email send !
* 2001 Introductory Special !!!
* We can even create your ad or announcement for you !
CALL 8 am. - 3:30 pm. P.S.T.
702-242-5725 or 702-528-2400
For removal see below.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Sorry if you received this message in error.
If you wish to be removed. Please, type "REMOVE"
in the subject line:MAILTO: remove101excite.com
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Looking For Sales, or Exposure,
we offer fresh targeted or general emails
sent for you with current email addresses.
Watch your business grow.
From: Alex Alten (Altenhome.com)
Date: Mon Jan 08 2001 - 02:27:10 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
At 11:58 AM 1/6/2001 -0800, Eric Rescorla wrote:
>> Eric Rescorla wrote:
>>
>> > Both browsers and servers ALREADY support anonymous connections.
>>
>> There is a huge difference between SUPPORT and working out
>> of the box. In my world, httpd would work out of the box if
>> the server started up and created a self signed certificate
>> straight away and ran without any more intervention. Just
>> like sshd.
>As I said earlier, SSL operates under a different threat model
>than SSH. SSH connections are by and large to servers you've
>already contacted before. SSL needs to support spontaneous
>connections to many hosts which you've never seen before and have
>absolutely no prior relationship with.
>
Ian has a very valid point. The MitM threat model that SSL is trying
to prevent was overkill for the vast majority of web users. A decent
privacy-only design with say replay protection is all that's needed in
general. Then you get rid of the lengthy handshake, the high cpu
overhead of RSA and the cumbersome certificate management (for example,
remember a year ago when many older browsers had their RSA certs expire,
it was worse than Y2K).
The only counter point I can think of is that you want to cover all
types of transactions, including very high value ones. But, the
default behavior of SSL (with server-only authentication) is no good
anyway for those types of transactions.
--
Alex Alten
AltenHome.Com
From: Derek Atkins (warlordMIT.EDU)
Date: Mon Jan 08 2001 - 09:41:21 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Unfortunately this is a VERY simplistic version of the PGP API... You
would at least still need to supply the following for encryption:
1) encryption cipher
2) random numbers (for key generation)
For decryption, you would need to pass a callback to ask for a
password to decrypt the private key, and perhaps a pointer to a
keyring. Unless your 'get_key_identifiers' is supposed to return the
list of keys that can decrypt a ciphertext, in which case you would
need to make two calls to the PGP API (it attempts to build a one-pass
system).
This all presumes you are not signing the ciphertext.
-derek
Bram Cohen <bramgawth.com> writes:
> Hey everyone, I have another question related to Envelope Mail :)
>
> The way Envelope Mail uses crypto is pretty clear now, and it looks like
> it might be possible for it to use PGP. Mostly, this depends on being able
> to get an implementation of the following API -
>
> String encrypt(String plaintext, String[] public_keys)
> String decrypt(String ciphertext, String private_key)
> String[] get_key_identifiers(String ciphertext)
>
> I think this is essentially a very simplified version of the API for PGP,
> so specific parameters would have to be picked. Does anyone know if my
> sense is accurate, and if so, would you have suggestions for what the
> parameters should be? (PGP version, cipher, key length, etc.)
>
> -Bram Cohen
>
> "Markets can remain irrational longer than you can remain solvent"
> -- John Maynard Keynes
>
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlordMIT.EDU PGP key available
From: Bill Stewart (bill.stewartpobox.com)
Date: Mon Jan 08 2001 - 11:30:32 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
At 12:27 AM 1/8/01 -0800, Alex Alten wrote:
>Ian has a very valid point. The MitM threat model that SSL is trying
>to prevent was overkill for the vast majority of web users. A decent
>privacy-only design with say replay protection is all that's needed in
>general. Then you get rid of the lengthy handshake, the high cpu
>overhead of RSA and the cumbersome certificate management (for example,
>remember a year ago when many older browsers had their RSA certs expire,
>it was worse than Y2K).
I disagree - it's much easier to do a DNS hack and implement MITM
than to sniff bits off the wire except in special environments
like universities. If DNSSEC had been widely deployed at the time
the web commercialized, much of the need for complexity in SSL
would have been eliminated, but that wasn't the case,
and getting SSL out at all was a major end-run around crypto export laws.
It's unnecessarily ugly, and much of the cumbersome cert management
came from the X.509 world, but the authentication job has to be done,
either in DNS or in SSL, so you won't dodge the RSA computation.
Doing it in SSL has the advantage that you can protect the full pathname,
while virtual servers let lots of machines share the same IP address,
limiting what you can do with reverse lookups.
Thanks!
Bill
Bill Stewart, bill.stewartpobox.com
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
From: lcs Mixmaster Remailer (mixanon.lcs.mit.edu)
Date: Mon Jan 08 2001 - 13:20:01 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
I've been looking at implementing "Practical Techniques for Searches
on Encrypted Data", by Dawn Song, David Wagner, and Adrian Perrig,
available from http://www.cs.berkeley.edu/~daw/papers/encsearch-oak00.ps.
The purpose of this is to allow a server to hold encrypted data that
it can't decrypt, but still be able to search for selected words in the
data when requested by the owner of the decryption key.
The basic idea is to encrypt using a stream cipher on a per-plaintext-
word basis. The encryption stream (which gets xored with the plaintext)
is the concatenation of stream cipher data and a keyed hash of the
stream cipher data, where the key depends on the plaintext word and the
user's password.
Searching the encrypted data can be done by releasing the plaintext
word (in the simplest model), allowing the server to recover the stream
cipher output and then to compute the keyed hash and compare with the
actual data. See the paper for elaborations which hide the word being
searched for from the server.
There are a couple of parameters in the paper which are left to the
implementor to choose. One is n, the word size; another is m, the size
of the "checksum" data which is appended to the stream cipher.
The choice of m is free of security issues. Making it smaller saves
space at the expense of increasing the chance of false positives -
cases where the checksum gets matched solely by accident. For typical
searches over documents with perhaps tens of thousands of words at most,
24 or 32 bits would be more than large enough for m.
Choosing n does involve security. As defined in the paper, n includes
the m checksum bits. Therefore n-m bits of the stream cipher are used
per word. The risk is that the same stream cipher encryption value may
come up twice if n-m is too small; in that case the keyed hash would
produce the same output if the same word were encrypted, and this could
conceivably be detected by an attacker.
Therefore it is necessary for n-m to be large enough to prevent duplicates
in the stream cipher data. Probably 64 bits would be a minimum choice
to maintain strong security, for the same reasons that it is the minimum
reasonable block size for ciphers.
This then makes n be a minimum of about 88 to 96 bits. Each word will
be expanded to this size, about 12 bytes. This is about a factor of 2.5
expansion for typical English text.
Other implementation issues that arise relate to non-text words,
punctuation and such. It is necessary for each word to be within
its own encryption block of 12 bytes in order for the search to work.
We'd like a word to be found regardless of what punctuation terminates
it, whether it is a comma, a space or a period. (or something else like
a parenthesis). This seems to require that inter-word punctuation be
within its own 12-byte encryption block.
In my implementation I assume that words are separated by single spaces,
since that is the most common case, and only use a punctuation block when
there is non-single-space punctuation between the two words. This means
that each comma, newline, period or other punctuation expands to 12 bytes.
It's costly, and contributes to text expansion.
Words 12 bytes or longer get stored as more than one block in my
implementation, meaning that you can only search on the first 12 letters
of a long word (and might get some false positives by hits on the second
12 letters of words). However few words are this long so it is hopefully
not a big problem.
After all this analysis, it seems that there might be a simpler method
of achieving the goals of the paper. Rather than building a checksum
into the encryption stream, consider encrypting the message in some fully
conventional way, but also outputting a separate keyed hash of each word
of the document. Decryption would ignore the hash list and just use
the encrypted data, while searching would use only the hash list and
not the encryption.
After some trial and error, a suitable form for the hash would seem to be:
H( sequence_number, H( key, word ) ). Sequence_number is the sequence
number of the word in the document (1, 2, 3, etc.), present to keep it
from being obvious when the same word appears more than once. Key is the
user's passphrase, and word is the word being searched for. The user
reveals H( key, word ) and the server hashes that with consecutive
sequence numbers, comparing with the correspondingly numbered entries
in the hash list.
Are there security weaknesses in this which I have overlooked?
If it works OK (or any weaknesses can be repaired) then this would seem
to have some efficiency advantages. First, the document itself can be
encrypted conventionally, improving compatibility with existing systems
and also allowing for compression to be used, which is impossible in the
Song/Wagner/Perrig method. Second, punctuation can be left entirely out
of the hash table, eliminating one of the causes of ciphertext expansion.
These two factors should hopefully lead to smaller ciphertexts.
Thanks for any comments.
From: RecruitmentKSM2000.com
Date: Mon Jan 08 2001 - 14:53:43 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
SOFTWARE BETA TESTERS REQUIRED
Welcome to KSM2000, we are the fulfilment agents for our clients MicroService.
Our client is actively seeking to recruit 1000 beta software testers throughout Europe and we have been placed with the challenge of locating them.
So where better than here in your newsgroup, will we find possible candidates. This is not a SPAM mail.
If you thing that this type of opportunity would be of interest to you, we would be grateful if you would use the link below to mail us your interest.
The subject line should contain: Beta Microservice
And the contents: Your full name, address, postcode and of course your E-mail address. On receipt of this mail we will forward you full details of the positions available.
Please note this is not a full time employment opportunity.
Mailto: Microservice.Ksm2000.com
From: Bram Cohen (bramgawth.com)
Date: Mon Jan 08 2001 - 17:08:30 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
On 8 Jan 2001, Derek Atkins wrote:
> Unfortunately this is a VERY simplistic version of the PGP API...
That's fine. Just so long as the PGP API doesn't have too much weird crap
in it.
> You would at least still need to supply the following for encryption:
>
> 1) encryption cipher
> 2) random numbers (for key generation)
Those are both doable, in fact the second one I left off as a feature
'cause I thought it would be a problem.
> For decryption, you would need to pass a callback to ask for a
> password to decrypt the private key, and perhaps a pointer to a
> keyring. Unless your 'get_key_identifiers' is supposed to return the
> list of keys that can decrypt a ciphertext, in which case you would
> need to make two calls to the PGP API (it attempts to build a one-pass
> system).
*sigh*
One *could* use the whole public key as the identifier. I foolishly
assumed PGP actually had some decent engineering somewhere in there.
But it is, essentially, possible to do the wrapping I want? Are the only
arbitrary decisions I need to make along the lines of picking 3des for the
cipher, picking the number of bits for the public keys, and picking some
way of making a stream cipher for the random numbers?
> This all presumes you are not signing the ciphertext.
No signing right now. That might be added later, but not now.
-Bram Cohen
"Markets can remain irrational longer than you can remain solvent"
-- John Maynard Keynes
From: ispypost.com
Date: Mon Nov 08 1999 - 17:48:55 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
////////////////////////////////////////
one time mailing-
no need to remove
////////////////////////////////////////
CONFIDENTIAL INFORMATION YOU WANT TO KNOW.
This is the software they want banned from the INTERNET!
"The Internet Desktop Spy" shows you how to get the facts on anyone using the
Internet.
LOCATE MISSING PERSONS, find lost relatives, obtain addresses and phone
numbers of old school friends, even skip trace dead beat spouses. This is
not a Private Investigator, but a SOFTWARE program DESIGNED to automatically
CRACK YOUR CASE with links to thousands of Public Record Databases
Find out SECRETS about your relatives, friends, enemies, and everyone else!
-- even your spouse! With the New - "Internet Desktop SPY"
You will be AMAZED at what you can discover:
LICENSE PLATE NUMBER - Get anyone's name and address with just a license
plate number! (Find that girl you met in traffic!)
DRIVING RECORD - Get anyone's driving record!
SOCIAL SECURITY NUMBER - Trace anyone by social security number!
ADDRESS - Get anyone's address with just a name!
UNLISTED PHONE NUMBERS - Get anyone's phone number with just a name- even
unlisted numbers!
LOCATE - Long lost friends, relatives, a past lover who broke your heart!
E-MAIL - Send anyone anonymous e-mail that's completely untraceable!
DIRTY SECRETS - Discover dirty secrets your in-laws don't want you to know!
INVESTIGATE ANYONE - Use the sources that private investigators use (all on
the Internet) secretly!
EX-SPOUSE - Learn how to get information on an ex-spouse that will help you
win in court! (Dig up old skeletons)
CRIMINAL SEARCH - BACKGROUND CHECK - Find out about your daughter's
boyfriend! (or her husband)
FIND OUT - If you are being investigated!
NEIGHBORS - Learn all about your mysterious neighbors! Find out what they
have to hide!
PEOPLE YOU WORK WITH - Be astonished by what you'll learn about the people
you work with!
EDUCATION VERIFICATION - Did he really graduate college? Find out!
"The Internet Desktop Spy" will help you discover ANYTHING about anyone, with
clickable hyperlinks and no typing in Internet addresses! Just download the
software and go! You will be shocked and amazed by the secrets that can
be discovered about absolutely everyone! Find out the secrets they don't
want you to know! About others, about yourself!
LIMITED TIME OFFER -- ORDER TODAY! ONLY $20 (US)
You can dowmload the "The Internet DeskTop Spy" software NOW so you can begin
discovering all the secrets you ever wanted to know! You can know EVERYTHING
about ANYONE with "The Internet DeskTop Spy" software.
- Works with all browsers and all versions of AOL
- PC Versions available Only!
DON'T WAIT TO GET STARTED… It's as easy as 1, 2, 3.
ORDER TODAY - While this software is still legal!
VISA/MC ONLY
STEP 1: Print out the below ORDER FORM
STEP 2: Type or Print your order information into the form
STEP 3: FAX Your order to us.
FAX to: 650-745-3345
(Order with confidence. This is a secure fax area. Only our qualified sales team will have access to your order information)
***************************************************************************************************************************
"The Internet DeskTop Spy" ORDER FORM - PLEASE WRITE CLEARLY
Name: ________________________________
Address: ________________________________ (BILLING ADDRESS ON CREDIT CARD ONLY)
City, State, ZIP: ________________________________
Country: ______________ (International Orders)
Phone Number: ______________ (In case we can't make out your order)
TOTAL COST OF ORDER IS $20.00
ALL ORDERS WILL BE PROCESSED WITHIN 48 HOURS OF RECEIPT
METHOD OF PAYMENT – ID Code AXXX
[ ]Visa [ ]MasterCard
Credit Card #: __________________________________
Exp Date: _______________
Signature: ____________________________ (Required)
E-Mail Address: ____________________________ *(VERY IMPORTANT-PRINT CLEARLY!! THIS MUST BE LEGIBLE)
-NOTES: - This program will not work on Windows 3.11 and older.
- Sorry, Mac versions not yet available.
- DISCLAIMER - The seller of this powerful software resource will not be held responsible for how the purchaser chooses to use its resources.
From: Microserviceksm2000.com
Date: Tue Jan 09 2001 - 02:21:46 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
SOFTWARE BETA TESTERS REQUIRED
Welcome to KSM2000, we are the fulfilment agents for our clients MicroService.
Our client is actively seeking to recruit 1000 beta software testers throughout Europe and we have been placed with the challenge of locating them.
So where better than here in your newsgroup, will we find possible candidates. Please ignore this mail and/or accept our apologies if it is not relevant to your newsgroup, but some of your users might just be interested.
If you think that this type of opportunity would be of interest to you, we would be grateful if you would use the link below to mail us your interest.
The subject line should contain: Beta Microservice
And the contents: Your full name, address, postcode and of course your E-mail address. On receipt of this mail we will forward you full details of the positions available as soon as possible.
Please note this is not a full time employment opportunity.
mailto:MicroserviceKsm2000.com
From: Nelson Brito (a.k.a. stderr) (stderrsekure.org)
Date: Tue Jan 09 2001 - 07:58:29 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
-------- Original Message --------
Subject: Advisory: PGP 7.0 signature verification vulnerability
Date: Mon, 8 Jan 2001 15:58:58 +0100
From: Michael Kjorling <michaelKJORLING.COM>
Reply-To: Michael Kjorling <michaelKJORLING.COM>
To: BUGTRAQSECURITYFOCUS.COM
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Product: Pretty Good Privacy
Severity: Medium to high
Impact: Users with write access to signed exported key blocks may
replace them with arbitrary keys without any warning being issued
upon import of those keys
Local: Yes
Remote: No (though man-in-the-middle attacks is a possibility)
Vendor status: Network Associates was contacted December 20; see
below
Confirmed vulnerable: PGP for Desktop Security, version 7.0.0.0 build
242, on Windows 2000
Suspected vulnerable: All versions of PGP 7.0
Confirmed not vulnerable: none
Disclaimer:
This information is provided "as is", with no warranties of any kind,
either expressed or implied. It was discovered through trial and
error; the source code has not been examined as it has been out of my
reach. I take no responsibility for how the information contained
within this advisory is utilized.
Description:
There seems to be a vulnerability in the key import code in PGP 7.0
on the Win32/Intel platform, causing a signature on a full exported
and ASCII armored key block not to be checked when "Decrypt/Verify"
is selected to import the key(s). This means that any signatures on
the full exported key block is not checked, opening the possibility
for anyone who have write access to the file to replace the keys
without having to generate a new signature. Key signature
verification, however, is not affected by this vulnerability.
Exploit:
Given the possibility to write to the PGP signed file containing the
exported key(s), replace the keys without altering the signature. PGP
will not warn the user upon import of the keys that the signature has
become invalid. Man-in-the-middle attacks are also a possibility,
given an eavesdropper listening on the communications channel and
replacing the key material as it flows through the wires.
Workaround:
There is no known workaround, besides always verifying fingerprints
with the owner of the key as well as not trusting keys that have no
or just a few signatures.
Vendor status:
Network Associates was contacted by email to <pgpsupportnai.com> as
per instructions from their support department on December 20th,
2000, and they were advised that an advisory would be posted to
Bugtraq on Jan 8. The email was encrypted with their "Software
Release Key" which was the key I was pointed to when asking to whom I
should encrypt the email, but I still have not heard back from them.
Michael Kjörling
michaelkjorling.com
-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0
Comment: All computers wait at the same speed.
iQA/AwUBOlnVfSqje/2KcOM+EQLUgACePUxBaAKla2jBZzdquOeba3nESYYAoNdt
0vzBXN6YIZ1V50EboF4maM3/
=hJXy
-----END PGP SIGNATURE-----
--
Nelson Brito
Security Analyst && Penetration Tester
Security Networks AG / IBQN - http://www.secunet.de/
From: cablewageslave.co.uk
Date: Tue Jan 09 2001 - 09:09:44 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
NOTE: THIS IS AN ADVERTISEMENT FOR LEGAL TV
DE-SCRAMBLER IF YOU HAVE NO INTEREST IN THIS INFORMATION
PLEASE CLICK DELETE NOW. THANK YOU--
LEGAL CABLE TV DE-SCRAMBLER
Want to watch Sporting Events?--Movies?--Pay-Per-View??
*This is the Famous R-D-O Shack TV Descrambler
You can assemble it from R-D-O Shack parts for about $12 or $15.
We Send You:
E-Z To follow Assembly Instructions.
E-Z To read Original Drawings.
The Famous R-D-O Shack Parts List.
PLUS SOMETHING NEW YOU MUST HAVE!
Something you can't do without.
THE UP-TO-DATE REPORT: USING A DESCRAMBLER LEGALLY
Warning: You should not build a TV Descrambler without
reading this report first.
Frequently Asked Questions--CABLE TV DESCRAMBLER
Q: Will the descrambler work on Fiber, TCI, Jarrod
and satellite systems?
A: The answer is YES. In respect to satellite,
you just get more stuff! There is one exception:
The descrambler will not work with DSS satellite.
Q: Do I need a converter box?
A: This plan works with or without a converter box.
Specific instructions are included in the plans for each!
Q: Can the cable company detect that I have the descrambler?
A: No, the signal descrambles right at the box and does
not move back through the line!
Q: Do I have to alter my existing cable system,
television or VCR?
A: The answer is no!
Q: Does this work with my remote control?
A: The answer is yes. The descrambler is
manually controlled--but very easy to use!
Q: Can you email me the plans?
A: No the program comes with an easy to follow picture guide.
Q: Does this work everywhere across the country?
A: Yes, every where in the USA plus England,
Brazil, Canada and other countries!
Q: When I order, when will I get my stuff?
A: We mail out all orders within 48 hours of receiving them.
YOU SUPPLY A SELF-ADDRESSED, STAMPED, #10 LONG ENVELOPE, WITH
TWO-FIRST CLASS STAMPS.
Q: How much does it cost to get the instruction
plans, the easy to follow diagram, and most
important of all the Using a Descrambler LEGALLY.
A: You get the complete package all for just--$10.00
(Cash, Check or Postal Money Order.)
(Arizona residents include 7% Arizona State Sales Tax)
(All orders outside the U.S.A. add $5.00)
ORDERS OUTSIDE THE US MUST BE IN THE FORM OF AN
INTERNATIONAL MONEY ORDER PAYABLE FROM A US BANK OR US CASH!
NO POSTAGE COUPONS ACCEPTED!
FOREIGN CHECKS WILL BE RETURNED!
Q: How do I order?
A: Fill out form below and send it, along with your payment
AND YOUR SELF ADDRESSED 2 STAMPED ENVELOPE to:
N Duran
PO BOX 8051
Mesa, AZ 85214-8051
MAKE CHECKS PAYABLE TO: N Duran
PRINT YOUR:
(orders without an envelope or stamps will be processed
up to 2 weeks later than complete orders)
DO NOT FORGET YOUR STAMPS!
NAME_____________________________________________
ADDRESS__________________________________________
CITY/STATE/ZIP_____________________________________
DO NOT FORGET YOUR 2, 34 cent stamps and #10 evenlope!
*N Duran is NOT ASSOCIATED in any way with RADIO SHACK.
Neither the design nor instructions were developed
by, are sold by, or are endorsed by Radio Shack.
Parts for this fine-tuning device are available
at many electronics stores (including Radio Shack)
This is not a Radio Shack product.
**********************************************************************
All REMOVE requests AUTOMATICALLY honored upon receipt.
PLEASE understand that any effort to disrupt, close or block this
REMOVE account can only result in difficulties for others wanting
to be removed from our mailing list as it will be impossible to take
anyone off the list if the remove instruction can not be received.
To be removed from our mailing list please
send an email to: movemeplease13looksmart.com.au
and place remove in the subject
Thank you
*********************************************************
From: partnersgetyourcasinonow.com
Date: Tue Jan 09 2001 - 12:23:13 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Hello,
I recently visited your website and believe you may be interested in forming a strategic partnership. Our company owns and operates fully licensed online casinos. We have over 30,000 clients and 8,500 partner websites.
The online gaming industry is the most explosive on the net, with over $10 billion projected by 2002. We would like to offer you the following proposal:
Qwest Global Intertainment provides:
* Casino / sportsbook front end design (for an example, go to www.GetYourCasinonow.com)
* All gaming software, customer service, credit card processing, and logistical support
* Up to 50% of casino net-win (tracked in real-time)
* Profit checks mailed each Friday, rain or shine
You provide:
* Website Promotion via banners, email, or search engine placement.
Without assuming any of the risk, you can drive traffic to your personal
Internet casino and immediately increase your company's residual income.
I invite you to look at our corporate website at the following address:
http://www.GetYourCasinonow.com
I look forward to hearing from you!
Partner Manager
partnersgetyourcasinonow.com
http://www.getyourcasinonow.com
From: R. A. Hettinga (rahshipwright.com)
Date: Tue Jan 09 2001 - 15:02:47 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
--- begin forwarded text
Date: Tue, 9 Jan 2001 14:58:50 -0500
To: dcsbai.mit.edu, dcsb-announceai.mit.edu
From: "R. A. Hettinga" <rahshipwright.com>
Subject: DCSB: Ted Byfield; ICANN, Intellectual Property, and Digital
Commerce
Cc: Ted Byfield <tbyfieldpanix.com>, Scott Moskowitz <scottbluespike.com>
Sender: bounce-dcsbreservoir.com
Reply-To: "R. A. Hettinga" <rahshipwright.com>
-----BEGIN PGP SIGNED MESSAGE-----
[Note that the Harvard Club is now "business casual". No more jackets
and ties... --RAH]
The Digital Commerce Society of Boston
Presents
Ted Byfield,
Moderator, Nettime
(among other things...)
ICANN, Intellectual Property,
and Digital Commerce
Tuesday, February 6th, 2000
12 - 2 PM
The Downtown Harvard Club of Boston
One Federal Street, Boston, MA
Through an erratic process intended to "lessen the burdens of
government," the Clinton administration transferred governance of the
Internet's essential functions to the Internet Corporation for
Assigned Names and Numbers. In trying to cement its status, ICANN has
sought to transform the net's cooperative structures into a
hierarchical contractual regime geared toward expanding and enforcing
intellectual property claims. The result of ICANN's deviation from
its technical coordination mandate into a captured policy-making
proxy for an absent-minded US government is a centralized namespace
that privileges the demands of late-adopters over innovative
expansions of DNS. This talk will provide a survey of ICANN's
activities to date and how they may advance alternative models and
extensions of DNS as a decentralized, cooperative system that is more
secure and less subject to political whim.
After working for over a decade as decade as an editor focusing on
intellectual and cultural history, Ted Byfield joined the faculty of
Parsons School of Design in New York City, where he teaches about the
social and political aspects of design. In addition to writing and
lecturing about areas where the technical and cultural collide, he is
a member of the rump Boston Working Group, co-moderates the Nettime
mailing list, and serves as an boardmember and advisor for various
New York-area cultural organizations.
This meeting of the Digital Commerce Society of Boston will be held
on Tuesday, February 6th, 2000, from 12pm - 2pm at the Downtown
Branch of the Harvard Club of Boston, on One Federal Street. The
price for lunch is $35.00. This price includes lunch, room rental,
A/V hardware if necessary, and the speakers' lunch. The Harvard Club
has relaxed its dress code, which is now "business casual", meaning
no sneakers or jeans. Fair warning: since we purchase these luncheons
in advance, we will be unable to refund the price of your meal if the
Club finds you in violation of what's left of its dress code.
We need to receive a company check, or money order, (or, if we
*really* know you, a personal check) payable to "The Harvard Club of
Boston", by Saturday, January 3rd, or you won't be on the list for
lunch. Checks payable to anyone else but The Harvard Club of Boston
will have to be sent back.
Checks should be sent to Robert Hettinga, 44 Farquhar Street, Boston,
Massachusetts, 02131. Again, they *must* be made payable to "The
Harvard Club of Boston", in the amount of $35.00. Please include your
e-mail address so that we can send you a confirmation
If anyone has questions, or has a problem with these arrangements
(we've had to work with glacial A/P departments more than once, for
instance), please let us know via e-mail, and we'll see if we can
work something out.
Upcoming speakers for DCSB are:
March 6 TBA
April 3 Scott Moskowitz Watermarking and Bluespike
As you can see, :-), we are actively searching for future speakers.
If you are in Boston on the first Tuesday of the month, are a
principal in digital commerce, and would like to make a presentation
to the Society, please send e-mail to the DCSB Program Committee,
care of Robert Hettinga, <mailto: rahshipwright.com>.
-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0
iQEVAwUBOlttV8UCGwxmWcHhAQHyQgf9EFME11YN9QQUHfMidGJW/Jl4JYS4kz+c
O+aS217xG7jrHhSzcobImq4Be16XkSz90hNEGfPEikOhOjbv0MHDQue5nOnJy9dN
5TCydlsSbD3Sz2f29FdpU+yV0MM2/puGDFGzZ3mdLFJJENGmAUdmy4FJGZbyLuSI
PWeOikiuRYfuJlsQrzGNT+v6AzvB0DbzufCgGN2nNFRVXdHJny/p3HYj2ZH+53ZR
e4pR1fhRzsK0xA3aQrMBErdGZcOR7iWrDj5va0DMjhw8ZdXQhQDNcQWigdCOnNx6
heY6pvuvSJDLMWb0sV+1QB6NKagKdiYP8U1S6iU1/49/lXToJH2LLw==
=zbvY
-----END PGP SIGNATURE-----
--
-----------------
R. A. Hettinga <mailto: rahibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this list, send a letter to: Majordomoreservoir.com
In the body of the message, write: unsubscribe dcsb-announce
Or, to subscribe, write: subscribe dcsb-announce
If you have questions, write to me at Owner-DCSBreservoir.com
--- end forwarded text
--
-----------------
R. A. Hettinga <mailto: rahibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
From: Xiao, Peter (pxiaoLiberate.com)
Date: Tue Jan 09 2001 - 17:42:45 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Hi,
I am currently looking for crypto implementation that can fit into small
footprint (in the order of 50K or less) devices. Ideally, an SSL type of
protocol meets my requirements but it is almost impossible to implement it
within 50K even with selected cipher suites. So, I am looking for
alternatives (either symmetric key or public key based). I was thinking
about WTLS but looks like its implementation can not be significantly
smaller than that of TLS since it is also based on Public Key cryptography
(I am wondering how it fits into a cellphone). Can any one tell me what is
the approximate size of the client implementation of WTLS. Also, would
anyone send some pointers to me regarding what I am looking for.
Thanks in advance!!
Peter
From: Tim Dierks (timdierks.org)
Date: Tue Jan 09 2001 - 19:38:05 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Peter -
We may well be able to help you. Our SSL library for Palm OS weighs in at
under 64K, including all necessary crypto. Our WTLS library is, I believe,
smaller. I'm certain we can build custom protocols that are much, much
smaller, but with similar functionality. Depending on what your platform and
needs are, I'm sure we can solve your problem.
Thanks,
- Tim Dierks
Certicom
tdierkscerticom.com
> -----Original Message-----
> From: owner-coderpunkstoad.com [mailto:owner-coderpunkstoad.com]On
> Behalf Of Xiao, Peter
> Sent: Tuesday, January 09, 2001 3:43 PM
> To: 'coderpunkstoad.com'; cypherpunkstoad.com
> Subject: crypto implementation for small footprint devices
>
>
> Hi,
>
> I am currently looking for crypto implementation that can fit into small
> footprint (in the order of 50K or less) devices. Ideally, an SSL type of
> protocol meets my requirements but it is almost impossible to implement it
> within 50K even with selected cipher suites. So, I am looking for
> alternatives (either symmetric key or public key based). I was thinking
> about WTLS but looks like its implementation can not be significantly
> smaller than that of TLS since it is also based on Public Key cryptography
> (I am wondering how it fits into a cellphone). Can any one tell me what is
> the approximate size of the client implementation of WTLS. Also, would
> anyone send some pointers to me regarding what I am looking for.
>
> Thanks in advance!!
>
> Peter
>
From: Phillip Zakas (pzakastoucancapital.com)
Date: Tue Jan 09 2001 - 20:07:24 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
what kind of platform? are you counting on an internal processor, or are you
just storing a key to be acted on via a second device? need more info.
pz
-----Original Message-----
From: owner-cypherpunksAlgebra.COM
[mailto:owner-cypherpunksAlgebra.COM]On Behalf Of Xiao, Peter
Sent: Tuesday, January 09, 2001 6:43 PM
To: 'coderpunkstoad.com'; cypherpunkstoad.com
Subject: crypto implementation for small footprint devices
Hi,
I am currently looking for crypto implementation that can fit into small
footprint (in the order of 50K or less) devices. Ideally, an SSL type of
protocol meets my requirements but it is almost impossible to implement it
within 50K even with selected cipher suites. So, I am looking for
alternatives (either symmetric key or public key based). I was thinking
about WTLS but looks like its implementation can not be significantly
smaller than that of TLS since it is also based on Public Key cryptography
(I am wondering how it fits into a cellphone). Can any one tell me what is
the approximate size of the client implementation of WTLS. Also, would
anyone send some pointers to me regarding what I am looking for.
Thanks in advance!!
Peter
From: Josh Richards (jrichardcubicle.net)
Date: Tue Jan 09 2001 - 20:20:36 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
* Xiao, Peter <pxiaoLiberate.com> [20010109 16:01]:
>
> I am currently looking for crypto implementation that can fit into small
> footprint (in the order of 50K or less) devices. Ideally, an SSL type of
> protocol meets my requirements but it is almost impossible to implement it
> within 50K even with selected cipher suites. So, I am looking for
> alternatives (either symmetric key or public key based). I was thinking
> about WTLS but looks like its implementation can not be significantly
> smaller than that of TLS since it is also based on Public Key cryptography
> (I am wondering how it fits into a cellphone). Can any one tell me what is
> the approximate size of the client implementation of WTLS. Also, would
> anyone send some pointers to me regarding what I am looking for.
How small of footprint? 50K (presuming you mean in currency) isn't really
a measurement of footprint size to me. :) Would something along the lines
of a Java iButton <URL:http://www.ibutton.com/> match your requirements?
It truly depends on what you need the device to be capable of...and I don't
just mean the crypto implementation but is this a device to be self-powered?
How do you need to interface with it? Etc.
-jr
----
Josh Richards [JTR38/JR539-ARIN]
<jrichardgeekresearch.com/cubicle.net/fix.net/freedom.gen.ca.us>
Geek Research LLC - <URL:http://www.geekresearch.com/>
IP Network Engineering and Consulting
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjpbxvEACgkQ8VgqD3XNPNUL9ACglfLcpuNY0XcMnVYCcWQk56hJ
sB8AoNpFRri73QCLINanyn45m1QUw74O
=Fcz4
-----END PGP SIGNATURE-----
From: Xiao, Peter (pxiaoLiberate.com)
Date: Tue Jan 09 2001 - 21:12:43 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
-----Original Message-----
From: Josh Richards [mailto:jrichardcubicle.net]
Sent: Tuesday, January 09, 2001 6:21 PM
To: coderpunkstoad.com; cypherpunkstoad.com
Subject: Re: crypto implementation for small footprint devices
* Xiao, Peter <pxiaoLiberate.com> [20010109 16:01]:
>
> I am currently looking for crypto implementation that can fit into small
> footprint (in the order of 50K or less) devices. Ideally, an SSL type of
> protocol meets my requirements but it is almost impossible to implement it
> within 50K even with selected cipher suites. So, I am looking for
> alternatives (either symmetric key or public key based). I was thinking
> about WTLS but looks like its implementation can not be significantly
> smaller than that of TLS since it is also based on Public Key cryptography
> (I am wondering how it fits into a cellphone). Can any one tell me what is
> the approximate size of the client implementation of WTLS. Also, would
> anyone send some pointers to me regarding what I am looking for.
How small of footprint? 50K (presuming you mean in currency) isn't really
a measurement of footprint size to me. :) Would something along the lines
of a Java iButton <URL:http://www.ibutton.com/> match your requirements?
It truly depends on what you need the device to be capable of...and I don't
just mean the crypto implementation but is this a device to be self-powered?
How do you need to interface with it? Etc.
The device is a DCT2000 set-top box with very limited footprint. Since the
box needs to run a lot of other applications, 50K is the space that we would
like to spend on the security purpose. The platform supports C interface.
-jr
----
Josh Richards [JTR38/JR539-ARIN]
<jrichardgeekresearch.com/cubicle.net/fix.net/freedom.gen.ca.us>
Geek Research LLC - <URL:http://www.geekresearch.com/>
IP Network Engineering and Consulting
From: Phillip Zakas (pzakastoucancapital.com)
Date: Tue Jan 09 2001 - 21:53:30 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
I know RSA B-Safe stuff is made to fit onto cell phones and pagers. They
also are the public key vendor for DOCSIS cable boxes. Maybe they can help
you. www.rsa.com
pz
-----Original Message-----
From: owner-cypherpunksAlgebra.COM
[mailto:owner-cypherpunksAlgebra.COM]On Behalf Of Xiao, Peter
Sent: Tuesday, January 09, 2001 10:13 PM
To: 'Josh Richards'; coderpunkstoad.com; cypherpunkstoad.com
Subject: RE: crypto implementation for small footprint devices
-----Original Message-----
From: Josh Richards [mailto:jrichardcubicle.net]
Sent: Tuesday, January 09, 2001 6:21 PM
To: coderpunkstoad.com; cypherpunkstoad.com
Subject: Re: crypto implementation for small footprint devices
* Xiao, Peter <pxiaoLiberate.com> [20010109 16:01]:
>
> I am currently looking for crypto implementation that can fit into small
> footprint (in the order of 50K or less) devices. Ideally, an SSL type of
> protocol meets my requirements but it is almost impossible to implement it
> within 50K even with selected cipher suites. So, I am looking for
> alternatives (either symmetric key or public key based). I was thinking
> about WTLS but looks like its implementation can not be significantly
> smaller than that of TLS since it is also based on Public Key cryptography
> (I am wondering how it fits into a cellphone). Can any one tell me what is
> the approximate size of the client implementation of WTLS. Also, would
> anyone send some pointers to me regarding what I am looking for.
How small of footprint? 50K (presuming you mean in currency) isn't really
a measurement of footprint size to me. :) Would something along the lines
of a Java iButton <URL:http://www.ibutton.com/> match your requirements?
It truly depends on what you need the device to be capable of...and I don't
just mean the crypto implementation but is this a device to be self-powered?
How do you need to interface with it? Etc.
The device is a DCT2000 set-top box with very limited footprint. Since the
box needs to run a lot of other applications, 50K is the space that we would
like to spend on the security purpose. The platform supports C interface.
-jr
----
Josh Richards [JTR38/JR539-ARIN]
<jrichardgeekresearch.com/cubicle.net/fix.net/freedom.gen.ca.us>
Geek Research LLC - <URL:http://www.geekresearch.com/>
IP Network Engineering and Consulting
From: Declan McCullagh (declanwell.com)
Date: Wed Jan 10 2001 - 01:00:23 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
It also might be worth checking out the elliptic curve apps that run
on Palm OS. --Declan
On Tue, Jan 09, 2001 at 10:53:30PM -0500, Phillip Zakas wrote:
>
> I know RSA B-Safe stuff is made to fit onto cell phones and pagers. They
> also are the public key vendor for DOCSIS cable boxes. Maybe they can help
> you. www.rsa.com
>
> pz
>
>
> -----Original Message-----
> From: owner-cypherpunksAlgebra.COM
> [mailto:owner-cypherpunksAlgebra.COM]On Behalf Of Xiao, Peter
> Sent: Tuesday, January 09, 2001 10:13 PM
> To: 'Josh Richards'; coderpunkstoad.com; cypherpunkstoad.com
> Subject: RE: crypto implementation for small footprint devices
>
>
>
>
>
> -----Original Message-----
> From: Josh Richards [mailto:jrichardcubicle.net]
> Sent: Tuesday, January 09, 2001 6:21 PM
> To: coderpunkstoad.com; cypherpunkstoad.com
> Subject: Re: crypto implementation for small footprint devices
>
>
> * Xiao, Peter <pxiaoLiberate.com> [20010109 16:01]:
> >
> > I am currently looking for crypto implementation that can fit into small
> > footprint (in the order of 50K or less) devices. Ideally, an SSL type of
> > protocol meets my requirements but it is almost impossible to implement it
> > within 50K even with selected cipher suites. So, I am looking for
> > alternatives (either symmetric key or public key based). I was thinking
> > about WTLS but looks like its implementation can not be significantly
> > smaller than that of TLS since it is also based on Public Key cryptography
> > (I am wondering how it fits into a cellphone). Can any one tell me what is
> > the approximate size of the client implementation of WTLS. Also, would
> > anyone send some pointers to me regarding what I am looking for.
>
> How small of footprint? 50K (presuming you mean in currency) isn't really
> a measurement of footprint size to me. :) Would something along the lines
> of a Java iButton <URL:http://www.ibutton.com/> match your requirements?
> It truly depends on what you need the device to be capable of...and I don't
> just mean the crypto implementation but is this a device to be self-powered?
> How do you need to interface with it? Etc.
>
> The device is a DCT2000 set-top box with very limited footprint. Since the
> box needs to run a lot of other applications, 50K is the space that we would
> like to spend on the security purpose. The platform supports C interface.
>
> -jr
>
> ----
> Josh Richards [JTR38/JR539-ARIN]
> <jrichardgeekresearch.com/cubicle.net/fix.net/freedom.gen.ca.us>
> Geek Research LLC - <URL:http://www.geekresearch.com/>
> IP Network Engineering and Consulting
>
>
From: Robert Guerra (rguerrayahoo.com)
Date: Wed Jan 10 2001 - 06:53:42 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
--On Wednesday, January 10, 2001 2:00 AM -0500 Declan McCullagh
<declanwell.com> wrote:
> It also might be worth checking out the elliptic curve apps that run
> on Palm OS. --Declan
>
Declan:
A Canadian company, Certicom <www.certicom.com> has been developping
Elliptic curve crypto libraries for quite a while. Thier software is in
many embedded devices and several PDA's including the palm.
hope it's of help
regards
robert
From: mailmanjournalist.com
Date: Wed Jan 10 2001 - 06:27:23 CST
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Hello,
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
