Re: Bitcoin P2P e-cash paper

-- Satoshi Nakamoto wrote: > The proof-of-work chain is the solution to the > synchronisation problem, and to knowing what the > globally shared view is without having to trust > anyone. > > A transaction will quickly propagate throughout the > network, so if two versions of the same transacti

Re: Bitcoin P2P e-cash paper

Satoshi Nakamoto wrote: > The bandwidth might not be as prohibitive as you > think. A typical transaction would be about 400 bytes > (ECC is nicely compact). Each transaction has to be > broadcast twice, so lets say 1KB per transaction. > Visa processed 37 billion transactions in FY2008, or > an

WPA broken even further

WPA was known from the beginning to be vulnerable to offline dictionary attack, for which the workaround was to use a key that is not human memorable. Now WPA is cracked even with a strong key: --

Secrets and cell phones.

A sim card contains a shared symmetric secret that is known to the network operator and to rather too many people on the operator's staff, and which could be easily discovered by the phone holder - but which is very secure against everyone else. This means that cell phones provide authenticati

Re: Bitcoin P2P e-cash paper

James A. Donald: > > To detect and reject a double spending event in a > > timely manner, one must have most past transactions > > of the coins in the transaction, which, naively > > implemented, requires each peer to have most past > > transactions, or most past

Re: Bitcoin P2P e-cash paper

Satoshi Nakamoto wrote: I've been working on a new electronic cash system that's fully peer-to-peer, with no trusted third party. The paper is available at: http://www.bitcoin.org/bitcoin.pdf We very, very much need such a system, but the way I understand your proposal, it does not seem to sc

Cloning resistance in bluetooth

Suppose one has a system that automatically signs you on to anything if your cell phone is within bluetooth range of your computer, and automatically signs you off out of everything, and puts up a screen saver that will not go away, when your cell phone is out of range of your computer. What

Re: once more, with feeling.

Peter Gutmann wrote: The problem is that the default has always been to be insecure, and there's no effective way to get people to move to the secure non-default, or at least none that isn't relatively easily circumvented by a bit of creative thinking and/or social engineering. If the user is

Re: once more, with feeling.

Leichter, Jerry wrote: The problem is what that "something else" should be. Keyfobs with one-time passwords are a good solution from the pure security point of view, but (a) people find them annoying; (b) when used with existing input mechanisms, as they pretty much universally are, are subject

Re: once more, with feeling.

Eric Rescorla wrote: This is precisely the issue. There are any number of cryptographic techniques that would allow clients and servers to authenticate to each other in a phishing resistant fashion, but they all depend on ensuring that the *client* has access to the password and that the attacke

Re: Cookie Monster

EMC IMAP wrote: > Yet another web attack: > > > My own conclusion from this: This is yet another indication that > the whole browser authentication model is irretrievably broken. It's > just way too complex, with way too many movin

Re: once more, with feeling.

Peter Gutmann wrote: Unfortunately I think the only way it (and a pile of other things as well) may get stamped out is through a multi-pronged approach that includes legislation, and specifically properly thought-out requirements rather than big-business- bought legislation like UCITA/UCC or ea

Re: SRP implementation - choices for N and g

Michael Tschannen wrote: Hi list Has anybody already gained experience concerning the technical implementation of SRP (http://srp.stanford.edu)? There is one point I couldn't find in any documentation: Should the modulus and the generator (N and g) be unique for each client or can they be chosen

Mifare

http://www.youtube.com/watch?v=NW3RGbQTLhE shows the researchers breaking Mifare. And in the comments, we see posts (I presume from mifare people) complaining that what is happening cannot possibly be happening. Everyone on this list knows the correct way to do what Mifare does wrong. So, sin

Re: Strength in Complexity?

Peter Gutmann wrote: For most crypto protocols, usability is job #8,107, right after "did we get the punctuation right in the footnotes for the third appendix?". Usability disasters such as DNSSEC are more common than strictly cryptographic disasters such as wifi. DNSSEC is near impossible to

Re: The wisdom of the ill informed

Arshad Noor wrote: While programmers or business=people could be ill-informed, Allen, I think the greater danger is that IT auditors do not know enough about cryptography, and consequently pass unsafe business processes and/or software as being secure. Committees of experts regularly get crypto

Re: User interface, security, and "simplicity"

> > The same is true in the source code, unsafe > > practices are avoided globally, (e.g. both strcpy() > > and strncpy() are absent together with fixed size > > automatic buffers) rather than used with care > > locally. I won't bore you with all the > > implementation safety "habits", but there a

Re: OpenSparc -- the open source chip (except for the crypto parts)

Perry E. Metzger wrote: > What you can't do, full stop, is > know that there are no unexpected security related behaviors in the > hardware or software. That's just not possible. Ben Laurie wrote: Rice's theorem says you can't _always_ solve this problem. It says nothing about figuring out spe

Re: OpenSparc -- the open source chip (except for the crypto parts)

Marcos el Ruptor wrote: > If you want a guarantee or a proof, better ask all the > reverse engineers you know to take a closer look at > the program and tell you if there is a backdoor, > anything malicious or anything sneaky or suspicious. If it was easy to find deliberate flaws, it would be eve

Re: User interface, security, and "simplicity"

Thor Lancelot Simon wrote: And, in fact, most VPN software of any type fails this test. My concern is that an excessive focus on "how hard is it to set this thing up?" can seriously obscure the important second half of the question "and if you set it up in the easiest possible way, is it safe?"

Re: User interface, security, and "simplicity"

Steven M. Bellovin wrote: > IPsec operates at layer 3, where there are (generally) > no user contexts. This makes it difficult to bind > IPsec credentials to a user, which means that it > inherently can't be as simple to configure as ssh. > > Put another way, when you tell an sshd whom you wish >

Re: User interface, security, and "simplicity"

Thor Lancelot Simon wrote: It's fashionable in some circles (including, it seems, this one) to bash IPsec (particularly IKE) and tout SSL VPNs (particularly OpenVPN) on what are basically user interface grounds. I cannot help repeatedly noting that -- I believe more so than with actual IPsec dep

Re: "Designing and implementing malicious hardware"

Assume the hook works by waiting for a very specific sequence of bits to arrive along a wire, then causing an interrupt giving ring zero control to the memory location following that which the bits came from. No amount of testing is going to reveal the hook until it is used by the attacker.

Re: [p2p-hackers] convergent encryption reconsidered

Ivan Krsti? wrote: 1. take partially known plaintext 2. make a guess, randomly or more intelligently where possible, about the unknown parts 3. take the current integrated partial+guessed plaintext, hash to obtain convergence key 4. verify whether that key exists in the storage index 5. if

Re: how to read information from RFID equipped credit cards

Ben Laurie wrote: > Then we get to the next problem: we don't trust the > device with the keypad and display. So, we need to add > that to the GTCYM (Gadget That Controls Your Money). > > And so we end up at the position that we have ended up > at so many times before: the GTCYM has to have a > de

How is DNSSEC

From time to time I hear that DNSSEC is working fine, and on examining the matter I find it is "working fine" except that Seems to me that if DNSSEC is actually working fine, I should be able to provide an authoritative public key for any domain name I control, and should be able to obtai

Re: Dutch Transport Card Broken

Steven M. Bellovin wrote: > There's another issue: initial account setup. [Even > with SRP] people will still need to rely on > certificate-checking for that. It's a real problem at > some hotspots, where Evil Twin attacks are easy and > lots of casual users are signing up for the first > time.

Re: Dutch Transport Card Broken

Nicolas Williams wrote: > Sounds a bit like SCTP, with crypto thrown in. SCTP is what we should have done http over, though of course SCTP did not exist back then. Perhaps, like quite a few other standards, it still does not quite exist. > I thought it was the latency cause by unnecessary > rou

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

StealthMonger wrote: > They can't be as "anonymous as cash" if the party > being dealt with can be identified. And the party can > be identified if the transaction is "online, > real-time". Even if other clues are erased, there's > still traffic analysis in this case. > > What the offline paradi

Re: Gutmann Soundwave Therapy

James A. Donald wrote: >> I have figured out a solution, which I may post here >> if you are interested. Ian G wrote: > I'm interested. FTR, zooko and I worked on part of > the problem, documented briefly here: > http://www.webfunds.org/guide/sdp/index.html I have po

Re: Gutmann Soundwave Therapy

-- Ivan Krstic' wrote: > The wider point of Peter's writeup -- and of the > therapy -- is that developers working on security > tools should _know_ they're working in a notoriously, > infamously hard field where the odds are > _overwhelmingly_ against them if they choose to > engineer new solu

Re: Gutmann Soundwave Therapy

Guus Sliepen wrote: Peter's write-up was the reason I subscribed to this cryptography mailing list. After a while the anger/hurt feelings I had disappeared. I knew then that Peter was right in his arguments. Nowadays I can look at Peter's write-up more objectively and I can see that it is not as

Re: Dutch Transport Card Broken

Victor Duchovni wrote: Jumping in late, but the idea that *TCP* (and not TLS protocol design) adds round-trips to SSL warrants some evidence (it is very temping to express this skepticism more bluntly). With unextended SMTP for example, the minimum RTT count is: 0. SYN SYN-ACK

Re: Dutch Transport Card Broken

Perry E. Metzger wrote: > (No, I'm not a fan of X.509 certs, but those are not > core to the protocol, and you can think of them as > nothing more than a fancy key container format if you > like. Key management is not addressed by SSL, so there > is no reason that fixing key management has anythin

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

Eric Rescorla wrote: > Huh? What are you claiming the problem with sending > client certificates in plaintext is (as if anyone uses > client certificates anyway)? Well that is one problem - no one uses them, and no one should use them, while PKI was designed under the assumption that everyone wou

Re: Dutch Transport Card Broken

James A. Donald: >> SSL is layered on top of TCP, and then one layers >> one's actual protocol on top of SSL, with the result >> that a transaction involves a painfully large number >> of round trips. Richard Salz wrote: > Perhaps theoretically painful, but in

Re: Dutch Transport Card Broken

Ivan Krstic' wrote: > Some number of these muppets approached me over the > last couple of years offering to donate a free license > for their excellent products. I used to be more polite > about it, but nowadays I ask that they Google the > famous Gutmann Sound Wave Therapy[0] and mail me > after

Re: Lack of fraud reporting paths considered harmful.

Perry E. Metzger wrote: > The call-the-customer-and-reissue mechanism is a > mediocre solution to the fraud problem, but it is the > one we have these days. Why is it a mediocre solution? The credit card number is a widely shared secret. It has been known for centuries that widely shared secret

Re: Dutch Transport Card Broken

Perry E. Metzger wrote: Ed Felten has an interesting post on his blog about a Dutch smartcard based transportation payment system that has been broken. Among other foolishness, the designers used a custom cryptosystem and 48 bit keys. http://www.freedom-to-tinker.com/?p=1250 The Dutch governme

Re: Death of antivirus software imminent

Alex Alten wrote: > Generally any standard encrypted protocols will > probably eventually have to support some sort of CALEA > capability. For example, using a Verisign ICA > certificate to do MITM of SSL, or possibly requiring > Ebay to provide some sort of legal access to Skype > private keys.

Re: Question on export issues

Peter Gutmann: > > That's because there's nothing much to publish: In > > the US, notify the BIS via email. Ivan Krstic' wrote: > Our outside counsel -- specializing in this area -- > thought this was insufficient. You were probably asking your counsel the wrong question. Never ever ask the que

Re: Death of antivirus software imminent

Leichter, Jerry > > Why not just require that the senders of malign > > packets set the Evil Bit in their IP headers? > > > > How can you possibly require that encrypted traffic > > *generated by the attackers* will allow itself to be > > inspected? Alex Alten wrote: > You misunderstand me. We c

Re: Death of antivirus software imminent

Perry E. Metzger wrote: > I think Steve is completely correct in the case of > cryptography. We have a lot of experience of real > world security failures these days, and they're not > generally the sort that crypto would fix. They are the sort that a different sort of way of using crypto could f

Re: Death of antivirus software imminent

> Detecting viruses is a fundamentally losing battle: a > sufficiently advanced virus can fully simulate a clean > computer for the scanner to run in. > > On the other hand, writing an OS that doesn't get > infected in the first place is a fundamentally winning > battle: OSes are insecure because

Re: PlayStation 3 predicts next US president

William Allen Simpson wrote: > The whole point of a notary is to bind a document to a > person. That the person submitted two or more > different documents at different times is readily > observable. After all, the notary has the > document(s)! The notary does not want to have the documents, or

Re: Intercepting Microsoft wireless keyboard communications

Steven M. Bellovin wrote: > Believe it or not, I thought of CFB... > > Sending keep-alives will do nasties to battery > lifetime, I suspect; most of the time, you're not > typing. As for CFB -- with a 64-bit block cipher (you > want them to use DES? they're not going to think of > anything differ

Re: PlayStation 3 predicts next US president

Francois Grieu wrote: >> That's because if Tn is known (including chosen) to >> "some person", then (due to the weakness in MD5 we >> are talking about), she can generate Dp and Dp' such >> that >> S( MD5(Tn || Dp || Cp || Cn) ) = S( MD5(Tn || Dp' >> || Cp || Cn) ) >> whatever Cp, Cn and S() a

Re: Intercepting Microsoft wireless keyboard communications

Steven M. Bellovin wrote: It's moderately complex if you're trying to conserve bandwidth (which translates to power) and preserve a datagram model. The latter constraint generally rules out stream ciphers; the former rules out things like encrypting the keystroke plus seven random bytes with a 6

Re: PlayStation 3 predicts next US president

gt; > was submitted by some person before some >> > particular time. James A. Donald: > > And how does it identify this "other document"? William Allen Simpson wrote: > Sorry, obviously I incorrectly assumed that we're > talking to somebody skilled in the a

Re: PlayStation 3 predicts next US president

William Allen Simpson wrote: > The notary would never sign a hash generated by > somebody else. Instead, the notary generates its own > document (from its own tuples), and signs its own > document, documenting that some other document was > submitted by some person before some particular time. A

Re: PlayStation 3 predicts next US president

Dirk-Willem van Gulik wrote: >> Keep in mind that the notary is still 'careful' -- >> effectively they sign the hash -- rather than the >> document; and state either such (e.g. in the case of >> some software/code where you do not hand over the >> actual code) or state that _a_ document was presen

Re: PlayStation 3 predicts next US president

James A. Donald wrote: Not true. Because they are notarizing a signature, not a document, they check my supporting identification, but never read the document being signed. William Allen Simpson wrote: This will be my last posting. You have refused several requests to stick to the

Re: PlayStation 3 predicts next US president

James A. Donald wrote: A notary is a certifier. Have you ever seen a notary read the stuff he notarizes, let alone generate it? William Allen Simpson wrote: Actually, I deal with notaries regularly. I've always had to physically sign while watched by the notary. They always read the

Re: PlayStation 3 predicts next US president

James A. Donald wrote: >> A notary is a certifier. Have you ever seen a notary >> read the stuff he notarizes, let alone generate it? William Allen Simpson wrote: > Actually, I deal with notaries regularly. I've always > had to physically sign while watched by the not

GOST's resistance to this attack

GOST resists the attacks that have recently been discovered against commonly used hashes because it has 512 bits of internal state. It combines a simple 256 bit checksum with a simple 256 bit digest. I cannot see any use for the checksum other than to resist this type of attack against the diges

Re: PlayStation 3 predicts next US president

things yet give the same MD5 hash, it does not do what it was intended to do. James A. Donald: >> If it is a certifier, these are not "its" documents. William Allen Simpson: > If it is a certifier, it damn well better be its own > documents! A notary is a certifier. Have you

Re: PlayStation 3 predicts next US president

> There are no circumstances in which any reputable > certifier will ever certify any of the "multitude" > containing a hidden pdf image, especially where > generated by another party. So the certifier is going to go through each thing he certifies, to make sure there is nothing funny about it? T

Re: PlayStation 3 predicts next US president

William Allen Simpson wrote: > Weger, B.M.M. de wrote: >> See http://www.win.tue.nl/hashclash/Nostradamus if >> you want to know the details of what this has to do >> with cryptography. >> > It always bothers me as these things are announced, > but are based on presumptions that have absolutely no

Re: PlayStation 3 predicts next US president

Weger, B.M.M. de wrote: > We also announce two different Win32 executables that > have identical MD5 hash values. This can be made to > happen for any two executable files. This implies a > vulnerability in software integrity protection and > code signing schemes that still use MD5. See > http://w

Re: refactoring crypto handshakes (SSL in 3 easy steps)

[EMAIL PROTECTED] wrote: > The obvious way - doing a specific step just to verify > the handshake - is the kind of code-centric thinking > that I'm trying to avoid. I'm having trouble finding > the right words for it. Basically an encrypted > network protocol is a language in which a transmissio

Re: refactoring crypto handshakes (SSL in 3 easy steps)

[EMAIL PROTECTED] wrote: > I wonder if we here could develop a handshake that was > cryptographically secure, resistant to CPU DoS now, > and would be possible to adjust as we get faster at > doing crypto operations to reduce latency even > further. Basically an easy knob for balancing high > lat

Re: fyi: Adi Shamir's microprocessor bug attack

James Muir wrote: > Can anyone think of a deployed implementation of RSA > signatures that would be vulnerable to the attack > Shamir mentions? Hashing and message blinding would > seem to thwart it. As I said, public key encryption has long been known to be weak against chosen plaintext and cho

Re: fyi: Adi Shamir's microprocessor bug attack

' =JeffH ' wrote: > Adi Shamir Computer Science Department The Weizmann > Institute of Science Israel > > With the increasing word size and sophisticated > optimizations of multiplication units in modern > microprocessors, it becomes increasingly likely that > they contain some undetected bugs. Th

Re: refactoring crypto handshakes (SSL in 3 easy steps)

[EMAIL PROTECTED] wrote: > The "extra messages" might be irrelevant for > cryptography, but they're not irrelevant for security > or functionality. > > E.g. in SSL, you have capability/feature negotiation > (cipher suites, trusted CAs, in TLS 1.2 also signature > algorithms, etc.) You can handle

Re: refactoring crypto handshakes (SSL in 3 easy steps)

[EMAIL PROTECTED] wrote: Three messages is the proven minimum for mutual authentication. Last two messages all depend on the previous message, so minimum handshake time is 1.5 RTTs. Nicolas Williams wrote: Kerberos V manages in one round-trip. And it could do one round-trip without a replay

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

an 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 ... all the secrets were revealed >> to everyone t

Re: 307 digit number factored

| > AFAIK, the only advantage of ECC is that the keys are | > shorter. The disadvantage is that it isn't as well | > studied. | James A. Donald: | On past performance, elliptic curves are safer than | integers. From time to time, integer based asymmetric | encryption i

Avoiding certicom patents.

don't have the additional steps listed in ECMQV, how are they going to justify the claim that it somehow really is ECMQV? Note that that point compression avoids the attacks that motivate ECMQV has not been examined in the literature, nor have patent lawyers looked at any of the information I pr

Re: 307 digit number factored

A 307 digit number is 1024 bits, near enough. 1024 bits was scheduled to fail in 2013. It has failed early, due to modest advances in factorization. Thus past comparisons of the strength of encryption key sizes are no longer entirely accurate. Further, they never were that accurate to start wi

Re: 307 digit number factored

[EMAIL PROTECTED] wrote: AFAIK, the only advantage of ECC is that the keys are shorter. The disadvantage is that it isn't as well studied. Nate Lawson wrote: Again, this is well covered. The reason is the fundamental difference in the performance of the best-known attacks (GNFS vs. Pollard's

Re: 307 digit number factored

as been a long time since any such has been discovered for elliptic curves, long enough to give a plausible hope that no further such will ever be discovered. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG ibAQXQ+Yoy5neOvRwKJwdxVLDGSPwTxKobkv566h

Re: using SRAM state as a source of randomness

Netsecurity wrote: > Back in the late 60's I was playing with audio and a > magazine I subscribed to had a circuit for creating > warble tones for standing wave and room resonance > testing. > > The relevance of this is that they were using a > "random" noise generating chip that they acknowledged

What is a proof?

If a proof is a record of a mental journey in which one person has discovered an important truth, and then made a record of that journey adequate so that a second person can walk the same path and see the same truth, then cryptography could do with more and better proofs. If, on the other hand

Re: Neal Koblitz critiques modern cryptography.

Victor Duchovni wrote: > This part is not too radical. The more specific > skepticism of security proofs (I am reluctant to agree > that these are actively harmful), seems to be a > combination of the peer review issue above, and > (often?) lack of tight bounds that make the proofs > applicable to

Good news on crypto patents:

Good news on patents, particularly crypto patents. The CAFC, the US patent court, has recently ruled that the patent holder cannot hit you with punitive damages unless, on the preponderance of the evidence, you were objectively reckless - that you knew or strongly suspected you were violating

Re: a new way to build quantum computers?

-- Steven M. Bellovin wrote: > http://www.tgdaily.com/content/view/33425/118/ > > "Ann Arbor (MI) - University of Michigan scientists > have discovered a breakthrough way to utilize light in > cryptography. The new technique can crack even complex > codes in a matter of seconds. Scientists bel

Re: The bank fraud blame game

Philipp � wrote: * An external device that lets the user verify the transaction independently from the PC. The second possiblity has been realized by some european banks now, based on SMS and mobile phones, which sends the important transaction details together with a random authorisation cod

Re: Why self describing data formats:

James A. Donald: > > In the case of XML, yes there is a parsing engine, > > and if the structure of the DTD reflects the > > structure of the algorithm, then indeed it makes > > things much easier. But usually the committee have > > not thought about the

Re: question re practical use of secret sharing

James A. Donald: > > Is anyone aware of a commercial product that > > implements secret sharing? If so, can I get a > > pointer to some product literature? Peter Gutmann > It's available as part of other products (e.g. nCipher > do it for keying their HSMs), but

Re: Why self describing data formats:

James A. Donald wrote: Many protocols use some form of self describing data format, for example ASN.1, XML, S expressions, and bencoding. Why? Presumably both ends of the conversation have negotiated what protocol version they are using (and if they have not, you have big problems) and when

Re: Free Rootkit with Every New Intel Machine

Initially I did not believe it, thought it must be hype or hoax. Nope, it is a rootkit in hardware. http://www.intel.com/business/vpro/index.htm : : Isolate security tasks—in a separate : : environment that is hidden to the user : : : : [...] : : : : Perform hardware and softwar

Why self describing data formats:

Many protocols use some form of self describing data format, for example ASN.1, XML, S expressions, and bencoding. Why? Presumably both ends of the conversation have negotiated what protocol version they are using (and if they have not, you have big problems) and when they receive data, they

Re: 307 digit number factored

-- Anne & Lynn Wheeler wrote: > So one of the proposals (somewhat backed by the domain > name certification authority industry) is that domain > name owners place a public key on file when they > register a domain name with the domain name > infrastructure. They all future communication with t

Re: Public key encrypt-then-sign or sign-then-encrypt?

James A. Donald: > > Assume Ann's secret key is a, and her public key is A > > = G^a mod P > > > > Assume Bob's secret key is b, and his public key is B > > = G^b mod P > > > > Bob wants to send Ann a message. > > > > Bob gen

Re: Enterprise Right Management vs. Traditional Encryption Tools

Jason Holt wrote: > So I guess the answer to your question is "We'd better > assume that DRM+TPM will be ineffective until we've > subjected a specific implementation of it to the same > level of scrutiny we apply to other cryptosystems, and > since DRM+TPM proposals tend to be much more > complic

Re: Public key encrypt-then-sign or sign-then-encrypt?

Florian Weimer wrote: With sign, then encrypt, it's also possible that the receiver decrypts the message, and then leaks it, potentially giving the impression that the signer authorized the disclosure. There has been a fair bit of buzz about this confusion. But the lesson from that seems to be

Re: DNSSEC to be strangled at birth.

Nicolas Williams wrote: > Which means that the MITM would need the cooperation > of the client's provider in many/most cases (a > political problem) in order to be able to quickly get > in the middle so close to a leaf node (a technical > problem). Not a very large political problem. Most ISPs n

Re: Cracking the code?

. By and large, security systems that are covered by an NDA are covered by an NDA because they are not very good, and the seller of the system intends to send anyone to jail who widely publicizes the fact that they are not very good. Approach with care. --digsig Jame

Re: Failure of PKI in messaging

criticism of using the same password all over the net. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG hyNNu45kHRCn/6vEXQhYdbU/w1YW4J/TF8BDsJz0 495s+VYSd3RjDiopACgr9JccOdvE7cTtQV6xgA8sK

Re: Failure of PKI in messaging

-- John Levine wrote: > To the extent that people use a single system it can > be secure, but that doesn't scale. Globally unique true names do not scale. Relationships scale. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG

Re: Failure of PKI in messaging

ot had a trojan or a virus for a year, and the guys at OLPC and capabilities are working on solutions to the problem of trojans and viruses. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG KFNxwdPt55zr/lrMF3JJdyxCUs8vIC5/

Re: Failure of PKI in messaging

em resembling IM buddy lists - the computer tracks relationship information, rather than true name information. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG NMb/3lhm5wj1jn9bea0UJsViLkPWzA2jR+GCO

Re: Failure of PKI in messaging

ation, just as with the Katrina disaster. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG hHUR4oItlqyjOJrgB5g69WubFGEXSD2fFY+PslCK 4pIw1gBia7di4K0uJB1p+FcZC9yxi1vCIFI3tot1u - The

Re: Failure of PKI in messaging

Ed Gerck wrote: I am using this insight in a secure email solution that provides just that -- a reference point that the user trusts, both sending and receiving email. Without such reference point, the user can easily fall prey to con games. Trust begins as "self-trust". Anyone interested in tryi

Re: Failure of PKI in messaging

Ivan Krstić wrote: > This is, in my experience, exactly right. I'm trying > to take some steps for the better on the OLPC: all > e-mails and IMs will be signed transparently and by > default, with the possibility of being encrypted by > default in countries where it's not a problem. This'll > help

Failure of PKI in messaging

when they get such a message, and at best they present an opaque, incomprehensible, and useless interface. Has anyone done marketing studies to see why banks and massively phished organizations do not sign their messages to their customers? --digsig James A. Donald 6YeGpsZR+nOTh

Re: One Laptop per Child security

could structure the code so that automatic code checks make it impossible to compile code that is bad in certain ways - again a big project. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG txnLOsPeyJqwn5LYEMAdBUQoBArt6OJO8Rp8P6Vn 4GQB25JeU

Re: One Laptop per Child security

y, and report all your video files to the copyright lawyers. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG x4p2u5+Go3URK4IvzoJkO/+K0lr4p4XW2aNmlbEi 4dlOW8vAN4GsnWBzDGfvyjQYPosBfDEqrH3rKQ451 ---

Re: One Laptop per Child security

Steven M. Bellovin wrote: > The AV decision is more problematic. While a good > security model can prevent system files from being > overwritten, most worms use purely user-level > abilities. It would take a fairly radical OS design > to prevent a user-level worm from spreading. It is a fairly

Re: "Free WiFi" man-in-the-middle scam seen in the wild.

d sharing it through bittorrent. Cyberlink's statement echoes the statement made by earlier by many on this list and related lists that PKI fulfills its specification just fine. The DRM people wanted something that could not be done, so unsurprisingly they winded up buying something that does n

<    1   2   3   4   >