Re: Hashing algorithm needed

On 14/09/10 2:26 PM, Marsh Ray wrote: On 09/13/2010 07:24 PM, Ian G wrote: 1. In your initial account creation / login, trigger a creation of a client certificate in the browser. There may be a way to get a browser to generate a cert or CSR, but I don't know it. But you can simply gen

Re: Hashing algorithm needed

On 11/09/10 6:45 PM, f...@mail.dnttm.ro wrote: Essentially, the highest risk we have to tackle is the database. Somebody having access to the database, and by this to the authentication hashes against which login requests are verified, should not be able to authenticate as another user. Whi

Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)

On 25/08/10 11:04 PM, Richard Salz wrote: A really knowledgeable net-head told me the other day that the problem with SSL/TLS is that it has too many round-trips. In fact, the RTT costs are now more prohibitive than the crypto costs. I was quite surprised to hear this; he was stunned to find it

Re: Five Theses on Security Protocols

On 1/08/10 9:08 PM, Peter Gutmann wrote: John Levine writes: Geotrust, to pick the one I use, has a warranty of $10K on their cheap certs and $150K on their green bar certs. Scroll down to the bottom of this page where it says Protection Plan: http://www.geotrust.com/resources/repository/leg

Re: Fwd: Introduction, plus: Open Transactions -- digital cash library

Hi Bob, On 28/07/10 9:08 PM, R.A. Hettinga wrote: Anyone out there with a coding.clue wanna poke inside this thing and see if it's an actual bearer certificate -- and not yet another book-entry -- transaction system? Sorry to get your hopes up ... Just reading the words below not the code:

Re: Trusted timestamping

On 04/10/2009 23:42, Alex Pankratov wrote: I guess my main confusion at the moment is why large CAs of Verisign's size not offering any standalone timestamping services. My view is that there is no demand for this as a service. The apparent need for it is more a paper requirement that came

Re: FileVault on other than home directories on MacOS?

On 22/09/2009 14:57, Darren J Moffat wrote: There is also a sleep mode issue identified by the NSA: An extremely minor point, that looks like Jacob and Ralf-Philipp perhaps "aka nsa.org", rather than the NSA.gov. Still useful. iang -

Re: Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI

On 17/09/2009 21:42, David Wagner wrote: Kevin W. Wall wrote: So given these limited choices, what are the best options to the questions I posed in my original post yesterday? Given these choices, I'd suggest that you first encrypt with AES-CBC mode. Then apply a message authentication code (M

Re: SHA-3 Round 1: Buffer Overflows

On 22/2/09 23:09, R.A. Hettinga wrote: This just emphasizes what we already knew about C, even the most careful, security conscious developer messes up memory management. No controversy there. Some of you are saying, so what?

Re: The password-reset paradox

On 19/2/09 14:36, Peter Gutmann wrote: There are a variety of password cost-estimation surveys floating around that put the cost of password resets at $100-200 per user per year, depending on which survey you use (Gartner says so, it must be true). You can get OTP tokens as little as $5. Barely

Re: User interface, security, and "simplicity"

David Wagner wrote: ... This struck me as poor design, not good design. Asking the user to make these kinds of choices seems like the kind of thing that only a cryptographer could consider sensible. In this day and age, software should not be asking users to choose ciphers. Rather, the softwa

Re: User interface, security, and "simplicity"

Perry E. Metzger wrote: It is obvious to anyone using modern IPSec implementations that their configuration files are a major source of pain. In spite of this, the designers don't seem to see any problem. The result has been that people see IPSec as unpleasant and write things like OpenVPN when

Re: Cruising the stacks and finding stuff

Allen wrote: Add Moore's Law, a bigger budget and a more efficient machine, how long before AES-128 can be decoded in less than a day? It does make one ponder. Wander over to http://keylength.com/ and poke at their models. They have 6 or so to choose from, and they have it coded up in th

Re: TLS-SRP & TLS-PSK support in browsers (Re: Dutch Transport Card Broken)

Peter Gutmann wrote: Victor Duchovni <[EMAIL PROTECTED]> writes: While Firefox should ideally be developing and testing PSK now, without stable libraries to use in servers and browsers, we can't yet expect anything to be released. Is that the FF devlopers' reason for holding back? Just wonde

Re: TLS-SRP & TLS-PSK support in browsers (Re: Dutch Transport Card Broken)

Peter Gutmann wrote: There's always the problem of politics. You'd think that support for a free CA like CAcert would also provide fantastic marketing opportunities for free browser like Firefox, but this seems to be stalled pretty much idefinitely because since CAcert doesn't charge for certif

Re: TLS-SRP & TLS-PSK support in browsers (Re: Dutch Transport Card Broken)

Frank Siebenlist wrote: Why do the browser companies not care? I spent a few years trying to interest (at least) one browser vendor with looking at new security problems (phishing) and using the knowledge that we had to solve this (opportunistic cryptography). No luck whatsoever. My view

Re: Gutmann Soundwave Therapy

James A. Donald wrote: I have been considering the problem of encrypted channels over UDP or IP. TLS will not work for this, since it assumes and provides a reliable, and therefore non timely channel, whereas what one wishes to provide is a channel where timeliness may be required at the expe

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

Eric Rescorla wrote: (as if anyone uses client certificates anyway)? Guess why so few people are using it ... If it were secure, more people would be able to use it. No, if it were *convenient* people would use it. I know of absolutely zero evidence (nor have you presented any) that people ch

Re: two-person login?

John Denker wrote: We need to talk about threat models: a) The purveyors of the system in question don't have any clue as to what their threat model is. I conjecture that they might be motivated by the non-apt analogies itemized above. b) In the system in question, there are myriad rea

Re: Lack of fraud reporting paths considered harmful.

John Ioannidis wrote: Perry E. Metzger wrote: That's not practical. If you're a large online merchant, and your automated systems are picking up lots of fraud, you want an automated system for reporting it. Having a team of people on the phone 24x7 talking to your acquirer and reading them cred

Re: PlayStation 3 predicts next US president

[EMAIL PROTECTED] wrote: If on the one hand, the correct procedure is sign-encrypt-sign, then why, on the other hand, is the parallel not sign-hash-sign ? What is "correct" depends on requirements and semantics, and neither is well addressed in that paper nor in standards, w.r.t. email and si

Re: forward-secrecy for email? (Re: Hushmail in U.S. v. Tyler Stumbo)

Adam Back wrote: On Fri, Nov 02, 2007 at 06:23:30PM +0100, Ian G wrote: I was involved in one case where super-secret stuff was shared through hushmail, and was also dual encrypted with non-hushmail-PGP for added security. In the end, the lawyers came in and scarfed up the lot with subpoenas

Re: Hushmail in U.S. v. Tyler Stumbo

Jon Callas wrote: On Nov 1, 2007, at 10:49 AM, John Levine wrote: Since email between hushmail accounts is generally PGPed. (That is the point, right?) Hushmail is actually kind of a scam. In its normal configuration, it's in effect just webmail with an HTTPS connection and a long password

Re: Commercial CAPTCHA-breakers for sale

Peter Gutmann wrote: http://www.lafdc.com/captcha/ is a site that sells commercial CAPTCHA-breaking software. It also shows success rates for different types of CAPTCHAs. While the ratings are merely representative of this particular site's software and not a universal measure, it's interesting

Re: Full Disk Encryption solutions selected for US Government use

Peter Gutmann wrote: Ben Laurie <[EMAIL PROTECTED]> writes: Peter Gutmann wrote: Given that it's for USG use, I imagine the FIPS 140 entry barrier for the government gravy train would be fairly effective in keeping any OSS products out. ? OpenSSL has FIPS 140. But if you build a FDE produc

Re: Scare tactic?

Ivan Krsti? wrote: On Sep 19, 2007, at 5:01 PM, Nash Foster wrote: Any actual cryptographers care to comment on this? I don't feel qualified to judge. If the affected software is doing DH with a malicious/compromised peer, the peer can make it arrive at a predictable secret -- which would be

Re: open source digital cash packages

Steven M. Bellovin wrote: Are there any open source digital cash packages available? I need one as part of another research project. I can think of a few ways to answer this question. 1. blinded money demo programs: there is magic money, in C and in Java. Also I think Ben Laurie wrote an

Re: Another Snake Oil Candidate

Hagai Bar-El wrote: Hi, On 12/09/07 08:56, Aram Perez wrote: The IronKey appears to provide decent security while it is NOT plugged into a PC. But as soon as you plug it in and you have to enter a password to unlock it, the security level quickly drops. This would be the case even if they suppo

Re: New article on root certificate problems with Windows

[EMAIL PROTECTED] wrote: From a security point of view, this is really bad. From a usability point of view, it's necessary. I agree with all the above, including deleted. The solution is to let the HCI people into the design process, something that's very rarely, if ever, done in the sec

Re: The bank fraud blame game

Florian Weimer wrote: * Jerry Leichter: OK, I could live with that as stated. But: The code also adds: "We reserve the right to request access to your computer or device in order to verify that you have taken all reasonable steps to protect your computer or device and

Re: Blackberries insecure?

Steven M. Bellovin wrote: According to the AP (which is quoting Le Monde), "French government defense experts have advised officials in France's corridors of power to stop using BlackBerry, reportedly to avoid snooping by U.S. intelligence agencies." That's a bit puzzling. My understanding is t

Re: A crazy thought?

Allen wrote: Which lead me to the thought that if it is possible, what could be done to reduce the risk of it happening? It occurred to me that perhaps some variation of "separation of duties" like two CAs located in different political environments might be used to accomplish this by having

Re: no surprise - Sun fails to open source the crypto part of Java

Nicolas Williams wrote: On Mon, May 14, 2007 at 11:06:47AM -0600, [EMAIL PROTECTED] wrote: Ian G wrote: * Being dependent on PKI style certificates for signing, ... The most important motivation at the time was to avoid the risk of Java being export-controlled as crypto. The theory within

Re: no surprise - Sun fails to open source the crypto part of Java

Nicolas Williams wrote: Subject: Re: no surprise - Sun fails to open source the crypto part of Java Were you not surprised because you knew that said source is encumbered, or because you think Sun has some nefarious motive to not open source that code? Third option: the architecture of Sun'

no surprise - Sun fails to open source the crypto part of Java

Does anyone know what Sun failed to opensource in the crypto part of Java? http://news.com.com/Open-source+Java-except+for+the+exceptions/2100-7344_3-6182416.html They also involve some elements of sound and cryptography, said Tom Marble, Sun's OpenJDK ambassador. "We have already contacted t

Re: Was a mistake made in the design of AACS?

Hal Finney wrote: Perry Metzger writes: Once the release window has passed, the attacker will use the compromise aggressively and the authority will then blacklist the compromised player, which essentially starts the game over. The studio collects revenue during the release window, and sometimes

Re: Cryptome cut off by NTT/Verio

Perry E. Metzger wrote: Slightly off topic, but not deeply. Many of you are familiar with John Young's "Cryptome" web site. Apparently NTT/Verio has suddenly (after many years) decided that Cryptome violates the ISP's AUP, though they haven't made it particularly clear why. The following link wi

Re: crypto component services - is there a market?

Stefan Kelm wrote: Same with digital timestamping. Here in Europe, e-invoicing very slowly seems to be becoming a (or should I say "the"?) long-awaited application for (qualified) electronic signatures. Hmmm... last I heard, qualified certificates can only be issued to individuals, and invo

Re: Governance of anonymous financial services

Steve Schear wrote: Here is the situation. An on-line financial service, for example a DBC (Digital Bearer Certificate), operator wishes his meat space identity, physical whereabouts, the transaction servers and at least some of the location(s) of the service's asset backing to remain secret.

Re: Failure of PKI in messaging

Steven M. Bellovin wrote: On Mon, 12 Feb 2007 17:03:32 -0500 Matt Blaze <[EMAIL PROTECTED]> wrote: I'm all for email encryption and signatures, but I don't see how this would help against today's phishing attacks very much, at least not without a much better trust management interface on email

Re: NPR : E-Mail Encryption Rare in Everyday Use

Peter Saint-Andre wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ian G wrote: To get people to do something they will say "no" to, we have to give them a freebie, and tie it to the unpleasantry. E.g., in SSH, we get a better telnet, and there is only the encrypted version.

Re: NPR : E-Mail Encryption Rare in Everyday Use

Steven M. Bellovin wrote: Certainly, usability is an issue. It hasn't been solved because there's no market for it here; far too few people care about email encryption. Usability is the issue. If I look over onto my skype window, it says there are 5 million or so users right now. It did th

Re: long-term GPG signing key

Alexander Klimov wrote: On Wed, 11 Jan 2006, Ian G wrote: Even though triple-DES is still considered to have avoided that trap, its relatively small block size means you can now put the entire decrypt table on a dvd (or somesuch, I forget the maths). This would need 8 x 2^{64} bytes of

Re: long-term GPG signing key

Perry E. Metzger wrote: Ian G <[EMAIL PROTECTED]> writes: Travis H. wrote: I'd like to make a long-term key for signing communication keys using GPG and I'm wondering what the current recommendation is for such. I remember a problem with Elgamal signing keys and I'm

Re: long-term GPG signing key

Travis H. wrote: On 1/10/06, Ian G <[EMAIL PROTECTED]> wrote: 2. DSA has a problem, it relies on a 160 bit hash, which is for most purposes the SHA-1 hash. Upgrading the crypto to cope with current hash circumstances is not worthwhile; we currently are waiting on NIST to lead rev

Re: long-term GPG signing key

Amir Herzberg wrote: Ian G wrote: Travis H. wrote: I'd like to make a long-term key for signing communication keys using GPG and I'm wondering what the current recommendation is for such. I remember a problem with Elgamal signing keys and I'm under the impression that the 10

Re: long-term GPG signing key

Travis H. wrote: I'd like to make a long-term key for signing communication keys using GPG and I'm wondering what the current recommendation is for such. I remember a problem with Elgamal signing keys and I'm under the impression that the 1024 bit strength provided by p in the DSA is not suffici

Re: browser vendors and CAs agreeing on high-assurance certificat es

Ben Laurie wrote: Ian G wrote: http://wiki.cacert.org/wiki/VhostTaskForce (The big problem of course is that you can use one cert to describe many domains only if they are the same administrative entity.) If they share an IP address (which they must, otherwise there's no problem),

Re: browser vendors and CAs agreeing on high-assurance certificat es

Ben Laurie wrote: Ian G wrote: ... http://wiki.cacert.org/wiki/VhostTaskForce (The big problem of course is that you can use one cert to describe many domains only if they are the same administrative entity.) If they share an IP address (which they must, otherwise there's no pr

Re: browser vendors and CAs agreeing on high-assurance certificat es

Ben Laurie wrote: ... Hopefully over the next year, the webserver (Apache) will be capable of doing the TLS extension for sharing certs so then it will be reasonable to upgrade. In fact, I'm told (I'll dig up the reference) that there's an X509v3 extension that allows you to specify alternate

Re: browser vendors and CAs agreeing on high-assurance certificat es

BTW, illustrating points made here, the cert is for financialcryptography.com but your link was to www.financialcryptography.com. So of course Firefox generated a warning Indeed and even if that gets fixed we still have to contend with: * the blog software can't handle the nature o

Re: [Clips] Banks Seek Better Online-Security Tools

[EMAIL PROTECTED] wrote: okay, i read this story from 7/2005 reporting an incident in 5/2005. the short form of it is: Not a bad summary. I'd say that when one is dealing with any such crime, there are always unanswered questions, and issues of confusion (probably as much for the attacker as

Re: [Clips] Banks Seek Better Online-Security Tools

[EMAIL PROTECTED] wrote: dan, maybe you should just keep less money in the bank. i use online banking and financial services of almost every kind (except bill presentment, because i like paper bills). i ccannot do without it. it seems to me the question is how much liability do i expose myself

Re: [Clips] Banks Seek Better Online-Security Tools

[EMAIL PROTECTED] wrote: You know, I'd wonder how many people on this list use or have used online banking. To start the ball rolling, I have not and won't. I have not! I declined the chance when my bank told me that I had to download their special client that only runs on windows... Howe

Re: Session Key Negotiation

Will Morton wrote: I am designing a transport-layer encryption protocol, and obviously wish to use as much existing knowledge as possible, in particular TLS, which AFAICT seems to be the state of the art. In TLS/SSL, the client and the server negotiate a 'master secret' value which is passed thr

Haskell crypto

Someone mailed me with this question, anyone know anything about Haskell? Original Message I just recently stepped into open source cryptography directly, rather than just as a user. I'm writing a SHA-2 library completely in Haskell, which I recently got a thing for in a bad w

Re: "ISAKMP" flaws?

Florian Weimer wrote: Photuris uses a baroque variable-length integer encoding similar to that of OpenPGP, a clear warning sign. 8-/ Actually, if one variable-length integer encoding is used instead of 5 other formats in all sorts of strange places, I'd say this is a good sign. Although I did

Re: Some thoughts on high-assurance certificates

Ed Reed wrote: Getting PKI baked into the every day representations people routinely manage seems desirable and necessary to me. The pricing model that has precluded that in the past (you need a separate PKi certificate for each INSURANCE policy?) is finally melting away. We may be ready to wa

Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems

R. Hirschfeld wrote: Date: Thu, 20 Oct 2005 11:31:39 -0700 From: cyphrpunk <[EMAIL PROTECTED]> 2. Cash payments are final. After the fact, the paying party has no means to reverse the payment. We call this property of cash transactions _irreversibility_. Certainly Chaum ecash has this prope

Re: NSA Suite B Cryptography

Sidney Markowitz wrote: Excerpt from "Fact Sheet on NSA Suite B Cryptography" http://www.nsa.gov/ia/industry/crypto_suite_b.cfm "NSA has determined that beyond the 1024-bit public key cryptography in common use today, rather than increase key sizes beyond 1024-bits, a switch to elliptic curv

Re: [EMAIL PROTECTED]: [IP] more on ARMSTRONG LECTURE on Quantum Crypto and Optical Networks (Forwarded)]]

Eugen Leitl forwarded: The one possibly interesting use of QKD is for the super-paranoid: those who believe their traffic is being snooped today, and don't want it decrypted fifty years from now when theoretical and technological advances render all classical cryptography breakable (!?!). The

Re: [Anti-fraud] simple (&secure??) PW-based web login (was Re: Another entry in theinternet security hall of shame....)

Amir Herzberg wrote: For a stationary user, the extension compares _Iterations_ and confirm it is at most one less than previous value of _Iterations_ used with this site. (Minor point - if relying on incrementing Iterations, this may impact password sharing scenarios. Whether that's a good t

Re: [Anti-fraud] Re: Another entry in the internet security hall of shame....

Alaric Dailey wrote: Thus ATMs and the weak 2 factor authentication system they use are untrustworthy, I knew that already, but as I said, its better than not having the multifactor authentication. The fact that many cards may be used as credit card and you thus bypass the second factor, is a HU

AES implementation in C - any recommendations?

I'm after an AES implementation in C, preferably with something approximating BSD/open licence. Does anyone have a view on which would be a current favourite? (I'm writing a protocol that needs it, and would like to deliver the code totally complete, but with switches to turn on ones other favou

Re: Another entry in the internet security hall of shame....

James A. Donald wrote: -- From: [EMAIL PROTECTED] (Peter Gutmann) TLS-PSK fixes this problem by providing mutual authentication of client and server as part of the key exchange. Both sides demonstrate proof-of- possession of the password (without actually communicating th

Re: Another entry in the internet security hall of shame....

Anne & Lynn Wheeler wrote: the major ISPs are already starting to provide a lot of security software to their customers. a very straight forward one would be if they provided public key software ... to (generate if necessary) and register a public key in lieu of password ... and also support the

Re: Another entry in the internet security hall of shame....

Steven M. Bellovin wrote: But this underscores one of my points: communications security is fine, but the real problem is *information* security, which includes the endpoint. (Insert here Gene Spafford's comment about the Internet, park benches, cardboard shacks, and armored cars.) *That* m

Re: e2e all the way (Re: Another entry in the internet security hall of shame....)

Steven M. Bellovin wrote: 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 correspondents. That's beyond the ability of most people. I don't think it is that hard t

Re: Another entry in the internet security hall of shame....

Tim Dierks wrote: [resending due to e-mail address / cryptography list membership issue] On 8/24/05, Ian G <[EMAIL PROTECTED]> wrote: Once you've configured iChat to connect to the Google Talk service, you may receive a warning message that states your username and passw

Re: Another entry in the internet security hall of shame....

Trei, Peter wrote: Self-signed certs are only useful for showing that a given set of messages are from the same source - they don't provide any trustworthy information as to the binding of that source to anything. Perfectly acceptable over chat, no? That is, who else would you ask to confirm

Re: Another entry in the internet security hall of shame....

In another routine event in the adventure known as getting security to work in spite of the security, I just received this ... [fwd] When creating a google talk compatible IM personality in Apple's iChat you get the following warning on the Google Help pages: -=-=- 12. Check the boxes next t

Re: ID "theft" -- so what?

Ben Laurie wrote: Ian Grigg wrote: Too many words? OK, here's the short version of why phising occurs: "Browsers implement SSL+PKI and SSL+PKI is secure so we don't need to worry about it." PKI+SSL *is* the root cause of the problem. It's just not the certificate level but the business and

Re: The summer of PKI love

Stephan Neuhaus wrote: So, the optimism of the article's author aside, where *do* we stand on PKI deployment? I have collected the criticism I've seen over many years against PKI into this document: http://iang.org/ssl/pki_considered_harmful.html It's long :) iang --

expanding a password into many keys

I'd like to take a password and expand it into several keys. It seems like a fairly simple operation of hashing the concatonatonation of the password with each key name in turn to get each key. Are there any 'gotchas' with that? iang PS: some psuedo code if the above is not clear. for k in {se

The "encrypt everything" problem

On Wednesday 08 June 2005 18:33, [EMAIL PROTECTED] wrote: > "Ken Buchanan wrote:" > Another area where I predict vendors will (should) offer built in > solutions is with database encryption. Allot of laws require need-to-know > based access control, and with DBA's being able to see all entries th

Re: Papers about "Algorithm hiding" ?

On Tuesday 07 June 2005 14:52, John Kelsey wrote: > >From: Ian G <[EMAIL PROTECTED]> > >Sent: Jun 7, 2005 7:43 AM > >To: John Kelsey <[EMAIL PROTECTED]> > >Cc: Steve Furlong <[EMAIL PROTECTED]>, cryptography@metzdowd.com > >Subject: Re: Papers abo

Re: Papers about "Algorithm hiding" ?

On Thursday 02 June 2005 13:50, Steve Furlong wrote: > On 5/31/05, Ian G <[EMAIL PROTECTED]> wrote: > > I don't agree with your conclusion that hiding algorithms > > is a requirement. I think there is a much better direction: > > spread more algorithms. If every

Re: [Clips] Storm Brews Over Encryption 'Safe Harbor' in Data Breach Bills

On Friday 03 June 2005 14:38, Greg Rose wrote: > At 00:48 2005-06-03 +0100, Ian G wrote: > >Just to make it more interesting, the AG of New York, Elliot Spitzer > >has introduced a package of legislation intended to "rein in identity > > theft" including: >

Cell phone crypto aims to baffle eavesdroppers

Cell phone crypto aims to baffle eavesdroppers By Munir Kotadia, ZDNet Australia Published on ZDNet News: May 31, 2005, 4:10 PM PT An Australian company last week launched a security tool for GSM mobile phones that encrypts transmissions to avoid eavesdroppers. GSM, or Global System for Mobile

Re: [Clips] Storm Brews Over Encryption 'Safe Harbor' in Data Breach Bills

On Thursday 02 June 2005 19:28, R.A. Hettinga wrote: > > Storm Brews Over Encryption 'Safe Harbor' in Data Breach Bills > May 31, 2005 Just to make it more interesting, the AG of New York, Elliot Spitzer has introduced a package of legi

Re: Citibank discloses private information to improve security

On Wednesday 01 June 2005 23:38, Anne & Lynn Wheeler wrote: > in theory, the KISS part of SSL's countermeasure for MITM-attack ... is > does the URL you entered match the URL in the provided certificate. An > attack is inducing a fraudulent URL to be entered for which the > attackers have a valid c

Re: "SSL stops credit card sniffing" is a correlation/causality myth

On Thursday 02 June 2005 11:33, Birger Tödtmann wrote: > Am Mittwoch, den 01.06.2005, 15:23 +0100 schrieb Ian G: > [...] > > > For an example of the latter, look at Netcraft. This is > > quite serious - they are putting out a tool that totally > > bypasses PKI/SSL i

Re: "SSL stops credit card sniffing" is a correlation/causality myth

s I interpreted this incorrectly perhaps as SSL *stopped* sniffing. Subtle distinctions can sometimes matter. So please ignore the previous email, unless a cruel and unusual punishment is demanded... iang On Wednesday 01 June 2005 16:24, Ian G wrote: > On Tuesday 31 May 2005 19:38, Steven M.

Re: Digital signatures have a big problem with meaning

On Wednesday 01 June 2005 15:07, [EMAIL PROTECTED] wrote: > Ian G writes: > | In the end, the digital signature was just crypto > | candy... > > On the one hand a digital signature should matter more > the bigger the transaction that it protects. On the > other hand, the b

Re: "SSL stops credit card sniffing" is a correlation/causality myth

On Tuesday 31 May 2005 19:38, Steven M. Bellovin wrote: > 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: > >> >-- > &

Re: "SSL stops credit card sniffing" is a correlation/causality myth

On Tuesday 31 May 2005 23:43, Perry E. Metzger wrote: > Ian G <[EMAIL PROTECTED]> writes: Just on the narrow issue of data - I hope I've addressed the other substantial points in the other posts. > > The only way we can overcome this issue is data. > > You aren't

Re: "SSL stops credit card sniffing" is a correlation/causality myth

Hi Birger, Nice debate! On Wednesday 01 June 2005 13:52, Birger Tödtmann wrote: > Am Mittwoch, den 01.06.2005, 12:16 +0100 schrieb Ian G: > [...] > > > The point is this: you *could* > > turn off SSL and it wouldn't make much difference > > to actual security

Digital signatures have a big problem with meaning

On Tuesday 31 May 2005 23:43, Anne & Lynn Wheeler wrote: > in most business scenarios ... the relying party has previous knowledge > and contact with the entity that they are dealing with (making the > introduction of PKI digital certificates redundant and superfluous). Yes, this is directly what

Re: "SSL stops credit card sniffing" is a correlation/causality myth

On Wednesday 01 June 2005 10:35, Birger Tödtmann wrote: > Am Dienstag, den 31.05.2005, 18:31 +0100 schrieb Ian G: > [...] > > > As an alternate hypothesis, credit cards are not > > sniffed and never will be sniffed simply because > > that is not economic. If you can h

Re: "SSL stops credit card sniffing" is a correlation/causality myth

On Tuesday 31 May 2005 21:03, Perry E. Metzger wrote: > Ian G <[EMAIL PROTECTED]> writes: > > On Tuesday 31 May 2005 02:17, Steven M. Bellovin wrote: > >> The next part of this is circular reasoning. We don't see network > >> sniffing for credit card numbers

"SSL stops credit card sniffing" is a correlation/causality myth

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 > >based on network sniffing, or DNS hijacking, which > >turned out to be less of a threat than expected. > > First,

Re: Papers about "Algorithm hiding" ?

On Thursday 26 May 2005 22:51, Hadmut Danisch wrote: > Hi, > > you most probably have heard about the court case where the presence > of encryption software on a computer was viewed as evidence of > criminal intent. > > http://www.lawlibrary.state.mn.us/archive/ctappub/0505/opa040381-0503.htm > htt

Re: Citibank discloses private information to improve security

On Saturday 28 May 2005 18:47, James A. Donald wrote: > Do we have any comparable experience on SSH logins? > Existing SSH uses tend to be geek oriented, and do not > secure stuff that is under heavy attack. Does anyone > have any examples of SSH securing something that was > valuable to the user

Re: Malaysia car thieves steal finger

On Friday 20 May 2005 19:22, Ben Laurie wrote: > R.A. Hettinga wrote: > > Police in Malaysia are hunting for members of a violent gang who chopped > > off a car owner's finger to get round the vehicle's hi-tech security > > system. > > Good to know that my "amputationware" meme was not just paranoi

[Fwd] Advances in Financial Cryptography - "First Issue"

Advances in Financial Cryptography - "First Issue" May 11, 2005 https://www.financialcryptography.com/mt/archives/000458.html

calling all French-reading cryptologers - Kerckhoff's 6 principles needs a translation

It's been a year or so since this was raised, perhaps there are some French reading cryptologers around now? -- Forwarded Message -- Financial Cryptography Update: HCI/security - start with Kerckhoff's 6 principles May 01, 2005 --

Garfinkel analysis on Skype withdrawn?

Has anyone got a copy of the Skype analysis done by Simson Garfinkel? It seems to have disappeared. Original Message Subject: Simson Garfinkel analyses Skype - Open Society Institute Date: Sun, 10 Apr 2005 10:32:44 +0200 From: Vito Catozzo Hi I am Italian, so forgive any possible

Re: Secure Science issues preview of their upcoming block cipher

Dan Kaminsky wrote: Have you looked at their scheme? http://www.securescience.net/ciphers/csc2/ Secure Science is basically publishing a cipher suite implemented by Tom St. Denis, author of Libtomcrypt. Aha! I seem to recall on this very list about 2 years back, Tom got crucified for trying

Re: aid worker stego

Peter Fairbrother wrote: I've been asked to advise an aid worker about stego. Potential major government attacker. This is the area that cryptorights.org has been looking at. They were looking at creation of tools to support aid workers and the like. (I'm not sure if they are still active though.

Re: how email encryption should work

Hi James, I read that last night, and was still musing on it... James A. Donald wrote: -- In my blog http://blog.jim.com/ I post "how email encryption should work" I would appreciate some analysis of this proposal, which I think summarizes a great deal of discussion that I have read. *

  1   2   >