In message <[EMAIL PROTECTED]>, "John Brothers"
writes:
>
>> Any license that you may
>> believe you acquired with the Software is void, revoked and terminated.
>
>
>Can you void and/or revoke the GPL?
It doesn't matter if the GPL statement wasn't inserted by the real
owner of the work. Note
The AP wire reports that the founder of Nullsoft, Justin Frankel, plans
to resign in the wake of WASTE being pulled.
http://www.nytimes.com/aponline/technology/AP-AOL-Nullsoft.html
--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com
In message <[EMAIL PROTECTED]>, Anne & Lynn Whee
ler writes:
>
>at a recent cybersecurity conference, somebody made the statement that (of
>the current outsider, internet exploits, approximately 1/3rd are buffer
>overflows, 1/3rd are network traffic containing virus that infects a
>machine beca
In message <[EMAIL PROTECTED]>, "Matt Crawford" writ
es:
>> The worst trouble I've had with https is that you have no way to use host
>> header names to differentiate between sites that require different SSL
>> certificates.
>
>True as written, but Netscrape ind Internet Exploder each have a hack
>
Let me point folk at http://www.securityfocus.com/news/5654
for a related issue. To put it very briefly, *real* authentication is
hard.
--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com (2nd edition of "Firewalls" book)
-
In message <[EMAIL PROTECTED]>, John Young writes:
>
>Related: We have a three-year-old FOIA request to NSA for
>information on:
>
> The invention, discovery and development of "non-secret
> encryption" (NSE) and public key cryptography (PKC) by
> United Kingdom, United States, or any other
In message <[EMAIL PROTECTED]>, martin f krafft writes
:
>As far as I can tell, IPsec's ESP has the functionality of
>authentication and integrity built in:
>
>RFC 2406:
>
> 2.7 Authentication Data
>
> The Authentication Data is a variable-length field containing an
> Integrity Check Value (
>It's a toolbar for Mozilla (and related web browsers) that automatically
>displays the SHA1 or MD5 fingerprint of the SSL certificate when you visit
>an SSL secured web site. You could of course click the little padlock icon
>and dig through a couple of dialogs to see it, but it's much easier
In message <[EMAIL PROTECTED]>, Ian Grigg writes:
>
>Also, to impune the plug-in arrangement is to
>impune all plug-ins, and to impune the download
>from an unknown is to impune all downloads from
>unknowns.
Sounds about right...
...
>
>I.e., "download this fantastic tool" which
>just so annoyi
In message <[EMAIL PROTECTED]>, Bill Stewart writes:
>Somebody did an interesting attack on a cable network's customers.
>They cracked the cable company's DHCP server, got it to provide a
>"Connection-specific DNS suffic" pointing to a machine they owned,
>and also told it to use their DNS server.
In message <[EMAIL PROTECTED]>, Simon Josefsson writes:
>
>Of course, everything fails if you ALSO get your DNSSEC root key from
>the DHCP server, but in this case you shouldn't expect to be secure.
>I wouldn't be surprised if some people suggest pushing the DNSSEC root
>key via DHCP though, becau
In message <[EMAIL PROTECTED]>, Simon Josefsson writes:
>Bill Stewart <[EMAIL PROTECTED]> writes:
>
>>>* Your laptop see and uses the name "yahoo.com.attackersdomain.com".
>>> You may be able to verify this using your DNSSEC root key, if the
>>> attackersdomain.com people have set up DNSSEC for
[Moderator's note: I've been choking back the LibTomNet argument but I
thought Steve's specific references here are interesting, even if the
point has already been made. --Perry]
In message <[EMAIL PROTECTED]>, tom st denis w
rites:
>
>The RFC looks like it was written by a member of the ACLU a
In message <[EMAIL PROTECTED]>, "John S. Denker" writes:
> Or perhaps more relevantly, what
>is the chance that an enemy black-bag artist or a
>traitor or a bungler will compromise all my keys
>and/or all my plaintext? The latter is not to
>be sneezed at, and puts an upper bound on what
>I'm willi
In message <[EMAIL PROTECTED]>, Ian Grigg writes:
>M Taylor wrote:
>
>MITM is a real and valid threat, and should be
>considered. By this motive, ADH is not a recommended
>mode in TLS, and is also deprecated.
>
>Ergo, your threat model must include MITM, and you
>will pay the cost.
>
>(Presumably
In message <[EMAIL PROTECTED]>, "Perry E. Metzger" writes:
>
>Unfortunately, those parts are rather dangerous to omit.
>
>0) If you omit the message authenticator, you will now be subject to a
> range of fine and well documented cut and paste attacks. With some
> ciphers, especially stream cip
half of the first ciphertext, Mitch can't
>decrypt it, and thus not pass on the correct thing to Bob in the first
>step and to Alice in the second, so both can actually be sure to have
>the public key of the person that made the other move.
>
You have to be careful how you a
In message <[EMAIL PROTECTED]>, "Perry E.Metzger" writes:
>Hmm. You need a cipher such that given B(A(M)) and A you can get
>B(M). I know of only one with that property -- XOR style stream
>ciphers. Unfortunately that makes for a big flaw, so I'm not sure we
>should throw out our Diffie-Hellman im
In message <[EMAIL PROTECTED]>, "J Harper" writes:
>SSLv3 protocol implementation
>Simple ASN.1 parsing
>Cipher suites:
>TLS_RSA_WITH_RC4_128_MD5
>TLS_RSA_WITH_RC4_128_SHA
>TLS_RSA_WITH_3DES_EDE_CBC_SHA
I understand the need to conserve space; that said, I strongly urge you
to consid
In message <[EMAIL PROTECTED]>, "Anton Stiglic" writes
:
>
>By the way, is the paper by Phong Q. Nguyen describing the vulnerability
>available somewhere?
This note appeared on the IETF OpenPGP mailing list.
--
Subject: Re: Removing Elgamal signatures
From: David Shaw <[EMAIL PROTECTED]>
Date:
In message <[EMAIL PROTECTED]>, "Jeroen C.va
n Gelderen" writes:
>
>On Dec 6, 2003, at 3:26, Jeremiah Rogers wrote:
>
>> I'm having trouble pinpointing the origin of the initial hash values
>> for SHA 224 and, for that matter, 128. These values are defined as hex
>> representations of cube roots
In message <[EMAIL PROTECTED]>, bear writes:
>
>>But you should be sending mails via *your* SMTP server, and should be
>>connecting to that SMTP server using SSL and authentication. Open relays
>>encourage spam. People shouldn't be relaying mail via just any SMTP server.
>
>This is generally how
In message <[EMAIL PROTECTED]>, Dan Geer writes:
>
>> So, in capsule: this proposal assumes that you use the same machine for
>> outgoing and incoming e-mail.
>
>I'm actually experimenting with sending mail directly,
>per this little hack[1], which does have separate paths
>for incoming and out
In message <[EMAIL PROTECTED]>, Ian Grigg writes:
> Security architects
>will continue to do most of their work with
>little or no crypto.
And rightly so, since most security problems have nothing to do with
the absence of crypto.
>
>j. a cryptographic solution for spam and
>viruses won't be fou
In message <[EMAIL PROTECTED]>, "Anton Stiglic" writes:
>
>- Original Message -----
>From: "Steven M. Bellovin" <[EMAIL PROTECTED]>
>
>> >
>> >j. a cryptographic solution for spam and
>> >viruses won't be found.
&
In message <[EMAIL PROTECTED]>, Ben Laurie writes:
>Steven M. Bellovin wrote:
>> In message <[EMAIL PROTECTED]>, "Anton Stiglic" write
>s:
>>
>>>- Original Message -
>>>From: "Steven M. Bellovin" <[EMAIL PROTECTED]>
In message <[EMAIL PROTECTED]>, "Perry E. Metzger" writes:
>
>I view link encryption for SMTP -- i.e. SMTP over TLS -- as having two
>functions.
>
>1) It frustrates "vacuum cleaner" mail tapping efforts to some degree.
>2) It can be used effectively for authenticating the posting of a
> mail mess
Although I'm not a professional in the nuclear weapons field, I have
done a fair amount of research on the subject of PALs (Permissive
Action Links); you can find a summary of my results at
http://www.research.att.com/~smb/nsam-160/pal.html. I'll be updating
the page soon, to add more informati
In message <[EMAIL PROTECTED]>, Ben Laurie writes:
>
>What you _may_ have shown is that there's an infinite number of bugs in
>any particularly piece of s/w. I find that hard to believe, too :-)
>
Or rather, that the patch process introduces new bugs. Let me quote
from Fred Brooks' "Mythical M
In message <[EMAIL PROTECTED]>, Jason H
olt writes:
>
>[...]
>
>I had the same question about the NSA when some friends were interviewing
>there. Apparently investigators will just show up at your house and want to
>know all sorts of things about your friends, who you may or may not know to be
>i
In message <[EMAIL PROTECTED]>, John Gilmore writes:
>If they could read the license plates reliably, then they wouldn't
>need the EZ Pass at all. They can't. It takes human effort, which is
>in short supply.
>
There are, in fact, toll roads that try to do that; see, for example,
http://www.whe
In message <[EMAIL PROTECTED]>, Ian Grigg writes:
>>
>> Don't be silly. It's not a threat because people generally use
>> SSL. Back in the old days, password capture was a very serious
>> threat. It went away with SSH. It seems to me quite likely that
>> it would be a problem with web browsing in
In message <[EMAIL PROTECTED]>, John Denker writes:
>Here's a challenge directly relevant to this group: Can you
>design a comsec system so that pressure against a code clerk
>will not do unbounded damage? What about pressure against a
>comsec system designer?
>
That is, of course, one of the p
In message <[EMAIL PROTECTED]>, Peter Gutmann writes:
>Eugen Leitl <[EMAIL PROTECTED]> writes:
>
>
>Maybe it's worth doing some sort of generic RFC for this security model to
>avoid scattering the same thing over a pile of IETF WGs, things like the
>general operational principles (store a hash of
In message <[EMAIL PROTECTED]>, Ian Grigg writes:
>Peter Gutmann wrote:
>> "Steven M. Bellovin" <[EMAIL PROTECTED]> writes:
>>>>Maybe it's worth doing some sort of generic RFC for this security model to
>>>>avoid scattering the same thing
In message <[EMAIL PROTECTED]>, Nicolai Moles
-Benfell writes:
>Hi,
>
>A number of sources state that the NSA changed the S-Boxes (and reduced the ke
>y
>size) of IBM's original DES submission, and that these change were made to
>strengthen the cipher against differential/linear/?? cryptanalysis.
>
In message <[EMAIL PROTECTED]>, Steve Bellov
in writes:
>Readers of this list may be interesting the the SRUTI -- Steps Towards
>Reducing Unwanted Traffic on the Internet -- workshop. See
>http://www.research.att.com/~bala/srut for details.
>
CORRECTION: it's http://www.research.att.com/~bala/sr
nizations)
became technologically obsolete.
One of the reviews on Amazon.com noted skeptically Kahn's claim that
Friedman was jealous of Yardley's success with women. I have no idea
if that's true, though moralistic revulsion may be closer. But I
wonder if the root of
uts? (Remember the purported escrow key
generation algorithm for Clipper? See
http://www.eff.org/Privacy/Newin/Cypherpunks/930419.denning.protocol
for details. The algorithm was later disavowed, but I've never been
convinced that the disavowal was genuine.)
--Prof. Stev
ate a new
IV. The consequences are obvious to readers of this list
--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe crypto
ys or SpeedPasses in aluminum
foil. I suspect that a more practical form factor is a spring-loaded
conductive sleeve that normally surrounds the RFID chip, but is push
back either manually or on key insertion.
--Prof. Steven M. Bellovin, http://www.
In message <[EMAIL PROTECTED]>, Aram Perez writes:
>Hi Folks,
>
>I hate to bother you with what I consider a dumb question, but I'm
>trying to give a person the benefit of my doubts. There's a person on a
>legal forum that I participate in that claims that 3DES has been
>broken/cracked. However,
xt?
>rot-13?
There are a lot of ways to tell, but you generally have to have some
idea what you're looking for. For two examples of how to do it, see
http://www1.cs.columbia.edu/~smb/papers/probtxt.ps (or .pdf) and
http://www1.cs.columbia.edu/~smb/papers/recog.ps (or .pdf)
In message <[EMAIL PROTECTED]>, bear writes:
>
>
>On Mon, 31 Jan 2005, Steven M. Bellovin wrote:
>
>
>>>[Moderator's note: The quick answer is no. The person who claims
>>> otherwise is seriously misinformed. I'm sure others will chime
>>>
s right -- getting it
easy to use *and* secure -- is the real challenge. Nor are competing
products immune; the drive to make KDE and Gnome (and for that matter
MacOS X) as easy to use (well, easier to use) than Windows is likely to
lead to the same downward security sprial.
I'm ranting, a
Are there any commercial link-layer encryptors for Ethernet available?
I know that Xerox used to make them, way back when, but are there any
current ones, able to deal with current speeds (and connectors)?
--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb
In message <[EMAIL PROTECTED]>, Russell Nelson writes:
>Steven M. Bellovin writes:
> > Are there any commercial link-layer encryptors for Ethernet available?
> > I know that Xerox used to make them, way back when, but are there any
> > current ones, able to de
Layer 2? It seems to be an IPsec box. At the least, their
Administrator's Guide talks about using IP Protocol 50.
--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-
The Cryptography Mailin
g them, because of
how frequently a transoceanic fiber would be cut and the circuits
rerouted to satellite.
--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-
The Cryptography Mailing List
Unsu
xpecting and reading ASCII characters. But think of, say, the
Japanese user who would like to see that the certificate really was
issued to , and instead sees the IDN encoding?
That's less than helpful -- he or she would have no way whatsoever of
verifying t
ot; or "KO" is government, and not what I'm
looking for. The KG-235, which your second URL took me to, is for
TS/SCI traffic -- *way* above what I need...
--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-
In message <[EMAIL PROTECTED]>, Amir Herzberg writes:
>Steve, my point was not the trivial fact that TrustBar would not display
>the homograph; suppose it did... even then, the user is _asked_ about
>the certificate, since it was signed by an unusual CA that the user did
>not specify as `to be t
built massively parallel hash
function collision finders, but it's an impressive achievement
nevertheless -- especially since it comes just a week after NIST stated
that there were no successful attacks on SHA-1.
--Prof. Steven M. Bellovin, http://www.
In message <[EMAIL PROTECTED]>, Alexandre
Dulaunoy writes:
>On Tue, 15 Feb 2005, Steven M. Bellovin wrote:
>
>> According to Bruce Schneier's blog
>> (http://www.schneier.com/blog/archives/2005/02/sha1_broken.html), a
>> team has found collisions in full SH
ate count. Beyond
that, SHA1 has a 160-bit data path; DES uses a 32-bit path. I
won't try to estimate the relative complexities of the mixing
functions at each round.
--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-
repair the MD*/SHA* family is to risk the cry of "epicycles".
--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
In message <[EMAIL PROTECTED]>, Thor Lancelot Simon writes:
>On Thu, Mar 03, 2005 at 05:31:34PM +0100, Poul-Henning Kamp wrote:
>> In message <[EMAIL PROTECTED]>, "ALeine" writes:
>>
>> >Not necessarily, if one were to implement the ideas I proposed
>> >I believe the performance could be kept at t
my own opinions, which I know some of you have seen, but on this
list I'll remain silent for now to see if any consensus develops.
--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-
The Cryptog
http://www.nytimes.com/aponline/national/AP-Spy-Agency-Documents.html
WASHINGTON (AP) -- The National Security Agency warned President
Bush in 2001 that monitoring U.S. adversaries would require a
``permanent presence'' on networks that also carry Americans'
messages that are protected from govern
In message <[EMAIL PROTECTED]>, Peter Gutmann writes
:
>>From a news.com story about features of gcc 4.0, available at
>http://news.com.com/Key+open-source+programming+tool+due+for+overhaul/2100-734
>4_3-5615886.html
>
> Key open-source programming tool due for overhaul
> Published: March 14, 200
ld we as a community be doing now? There's no emergency
on SHA1, but we do need to start, and soon.
--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-
The Cryptography Mailing List
Unsubscrib
A few days ago, I posted this:
>
>WASHINGTON (AP) -- The National Security Agency warned President
>Bush in 2001 that monitoring U.S. adversaries would require a
>``permanent presence'' on networks that also carry Americans'
>messages that are protected from government eavesdropping.
>
>...
>
>
>``
yption, many implementations support PGP
encryption between correspondents. I don't know of any support for
e2e-encrypted chat rooms.
I haven't played with OTR, nor am I convinced of the threat model.
That said, what you really need to watch out for is the transcript
files on your own
n based on discrete
log will be slow enough that no one will use it.
--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
I found this on Simson Garfinkel's blog (http://www.simson.net/blog/):
March 13, 2005 kohnfelder78
I have put Lauren Kohnfelder's 1978 undergraduate thesis
into a single PDF file, OCR'ed it, and put it online (with
his permission).
If you are interested in
http://www.vnunet.com/news/1162433
"Something like this cannot continue forever," he said.
"The dimensions are small enough now that we're approaching
the size of atoms and that's a fundamental block. I think
the law has another 10-20 years before fundamental limits
]>[EMAIL PROTECTED], with "Comments on SP 800-57,
Part 2" in the subject line.
Elaine Barker
100 Bureau Drive, Stop 8930
Gaithersburg, MD 20899
Phone: 301-975-2911
--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb
--
ing -- that's what's behind "pharming" attacks. In
other words, it's a real threat, too.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
In message <[EMAIL PROTECTED]>, Ian G writes:
>On Tuesday 31 May 2005 02:17, Steven M. Bellovin wrote:
>> In message <[EMAIL PROTECTED]>, "James A. Donald" writes:
>> >--
>> >PKI was designed to defeat man in the middle attacks
>> >bas
ress.20050526.03.htm
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
of information
that the authors could gather about network configurations at different
sites: as we all know, traffic analysis is a powerful technique.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-
Th
ipment of tapes to a credit bureau.) 2 involved
hacking, one was an inside job, one was a stolen laptop, and 2 were
fraudulent use of logins and passwords.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-
w few pages people would visit on the
site, though, he estimated that it would increase his costs by a factor
of about 15. (I didn't verify the numbers; I know from experience that
he's competent and has his hear in the right place re security).
--Steven M. Bellovin, h
In message <[EMAIL PROTECTED]>, "Perry E. Metzger" writes:
>
>"Steven M. Bellovin" <[EMAIL PROTECTED]> writes:
>>>They're still doing the wrong thing. Unless the page was transmitted
>>>to you securely, you have no way to trust th
in Google's
>cache is the intro page, with an abstract. The paper (pdf and ps) and a slide
>
>show are inaccessible, and are not in Google's cache.
>
>Anyone saved a copy?
It's on Vern's web page:
http://www.icir.org/vern/papers/witty-draft.pdf or
h now says he's
warning people even against doing their own implementations.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
l sorts of other channels -- application data,
timing data (the remote fingerprinting paper mentioned this one), etc.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-
The Cryptography Mailing List
Unsub
rise there
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
umber of questions that need
to be answered about any such system before it's even possible to
discuss it intelligently.
> And
>whenever I enter the US, I have to give the fingerprints of my index
>fingers and they take a picture of me. That's worse than an ID card.
Agreed.
http://www.baltimoresun.com/news/nationworld/bal-te.nsa07jul07,1,6042171.story?coll=bal-home-headlines&cset=true&ctrack=1&cset=true
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-
The
for you to log int o E-Gold, checks
your balance, and drains your account except for .004 grams of gold.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-
The Cryptography Mailing List
Unsubscribe
ental fees if I
don't present the card separately. Hmm -- the account is old enough
that the expiration date on my credit card has long since expired.
They've never asked me for an update. Maybe they're using a reputation
system?)
--Steven M. Bellovin, ht
on is really being authenticated?
(I alluded to this in a 1997 panel session talk; see
http://www.cs.columbia.edu/~smb/talks/ncsc-97/index.htm )
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-
The Cryptog
sibly, it simply didn't
fit their real purpose of attracting more customers.)
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Eric Rescorla and I have written a paper "Deploying a New Hash Algorithm".
A draft is available at http://www.cs.columbia.edu/~smb/papers/new-hash.ps
and http://www.cs.columbia.edu/~smb/papers/new-hash.pdf .
Here's the abstract:
As a result of recent discoveries, the strength of hash
the next version of the paper.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
l enough. (Besides, how do you know
if you'll actually notice it?)
\endns
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
as a cryptographic key with known plaintext (i.e., in challenge/
response protocols).
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-
The Cryptography Mailing List
Unsubscribe by sending "u
nbelievably
cumbersome".
I don't disagree with Perry's basic statement -- that a lot of people
try to solve the wrong problem. Here, though, we have a tool. It
remainds to be determined if it's a hammer, screwdriver, or wrench, and
hence what problems to a
use of the new path, there is reason to think the attack will get
even better. Shamir noted that 2^63 is within reach of a distributed
Internet effort to actually find one.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
---
>
One can easily conceive of schemes that don't have such problems, such
as simply publishing the hash of revoked certificates, or using a Bloom
filter based on the hashes.
Of course, that doesn't mean that was how it was done...
In message <[EMAIL PROTECTED]>, Florian Weimer writes:
>* Steven M. Bellovin:
>
>> In message <[EMAIL PROTECTED]>, Florian Weimer writes:
>>
>>>
>>>Can't you strip the certificates which have expired from the CRL? (I
>>>know that with
ves
to 64 characters, mirroring the password styles of the day, unsalted.
That's 64^8. It still comes to 1.5 million reels of tape, however, so
I still don't believe it.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
easy
to read, given their length and the complexity of the protocol.)
Do I support e2e crypto? Of course I do! But the cost -- not the
computational cost; the management cost -- is quite high; you need to
get authentic public keys for all of your corresponden
In message <[EMAIL PROTECTED]>, Chris Kuethe writes:
>On 8/26/05, Steven M. Bellovin <[EMAIL PROTECTED]> wrote:
>> ...
>> If you don't trust your (or your correspondents') IM servers, it may be
>> a different situation. I haven't read Google
In message <[EMAIL PROTECTED]>, Adam Back writes:
>On Fri, Aug 26, 2005 at 11:41:42AM -0400, Steven M. Bellovin wrote:
>> In message <[EMAIL PROTECTED]>, Adam Back writes:
>> >Thats broken, just like the "WAP GAP" ... for security you want
>> >
In message <[EMAIL PROTECTED]>, Ben Laurie writes:
>I wrote some code to show the internal state of MD5 during a collision...
>
>http://www.shmoo.com/md5-collision.html
>
Very nice, though you need to give a scale of rounds -- how many
horizontal lines per round?
if *all necessary patent rights* are owned (or licensed) by
Sun. For obvious reasons, it's remarkably hard to get someone to say
that they don't have a claim on some product.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
---
Under some circumstances, you could do a
call-out to a C module just for the crypto, but it's by no means
obvious that that's a major improvement.
Again -- what is your threat model?
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
,
James Hughes and Paul Leyland.
--- End of Forwarded Message
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
1 - 100 of 364 matches
Mail list logo
