Re: [Cryptography] /dev/random is not robust

2013-10-14 Thread James A. Donald
On 2013-10-15 10:35, d...@deadhat.com wrote: http://eprint.iacr.org/2013/338.pdf No kidding. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?

2013-10-12 Thread James A. Donald
On 2013-10-11 15:48, ianG wrote: Right now we've got a TCP startup, and a TLS startup. It's pretty messy. Adding another startup inside isn't likely to gain popularity. The problem is that layering creates round trips, and as cpus get ever faster, and pipes ever fatter, round trips become a

Re: [Cryptography] Elliptic curve question

2013-10-09 Thread James A. Donald
On 2013-10-08 03:14, Phillip Hallam-Baker wrote: Are you planning to publish your signing key or your decryption key? Use of a key for one makes the other incompatible.� Incorrect. One's public key is always an elliptic point, one's private key is always a number. Thus there is no reason

Re: [Cryptography] Iran and murder

2013-10-09 Thread James A. Donald
On 2013-10-08 02:03, John Kelsey wrote: Alongside Phillip's comments, I'll just point out that assassination of key people is a tactic that the US and Israel probably don't have any particular advantages in. It isn't in our interests to encourage a worldwide tacit acceptance of that stuff.

Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?

2013-10-07 Thread James A. Donald
On 2013-10-07 01:18, Phillip Hallam-Baker wrote: We are not at war with Iran. We are not exactly at peace with Iran either, but that is irrelevant, for presumably it was a Jew that did it, and Iran is at war with Jews. (And they are none too keen on Christians, Bahais, or Zoroastrians

Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?

2013-10-06 Thread James A. Donald
On 2013-10-04 23:57, Phillip Hallam-Baker wrote: Oh and it seems that someone has murdered the head of the IRG cyber effort. I condemn it without qualification. I endorse it without qualification. The IRG are bad guys and need killing - all of them, every single one. War is an honorable

Re: [Cryptography] Sha3

2013-10-05 Thread James A. Donald
On 2013-10-05 16:40, james hughes wrote: Instead of pontificating at length based on conjecture and conspiracy theories and smearing reputations based on nothing other than hot air But there really is a conspiracy, which requires us to consider conjectures as serious risks, and people

Re: [Cryptography] encoding formats should not be committee'ised

2013-10-04 Thread James A. Donald
On 2013-10-04 09:33, Phillip Hallam-Baker wrote: The design of WSDL and SOAP is entirely due to the need to impedance match COM to HTTP. That is fairly horrifying, as COM was designed for a single threaded environment, and becomes and incomprehensible and extraordinarily inefficient security

Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?

2013-10-03 Thread James A. Donald
On 2013-10-03 00:46, John Kelsey wrote: a. Most attacks come from protocol or mode failures, not so much crypto primitive failures. That is, there's a reaction attack on the way CBC encryption and message padding play with your application, and it doesn't matter whether you're using AES or

Re: [Cryptography] encoding formats should not be committee'ized

2013-10-03 Thread James A. Donald
On 2013-10-02 23:09, Phillip Hallam-Baker wrote: No, the reason for baring multiple inheritance is not that it is too clever, it is that studies have shown that code using multiple inheritance is much harder for other people to understand than code using single inheritance.� That is

Re: [Cryptography] TLS2

2013-10-02 Thread James A. Donald
On 2013-10-02 13:18, Tony Arcieri wrote: LANGSEC calls this: full recognition before processing http://www.cs.dartmouth.edu/~sergey/langsec/occupy/ http://www.cs.dartmouth.edu/%7Esergey/langsec/occupy/ I disagree slightly with langsec. At compile time you want an extremely powerful language

Re: [Cryptography] NIST about to weaken SHA3?

2013-10-01 Thread James A. Donald
On 2013-10-01 08:51, Watson Ladd wrote: On Mon, Sep 30, 2013 at 2:21 PM, James A. Donald jam...@echeque.com mailto:jam...@echeque.com wrote: Weaker in ways that the NSA has examined, and the people that chose the winning design have not. This isn't true: Keccak's designers proposed

Re: [Cryptography] NIST about to weaken SHA3?

2013-10-01 Thread James A. Donald
On 2013-10-01 10:17, John Kelsey wrote: Yeah, that plot to weaken sha3 is so secretive, we've been discussing it in public slide presentations and on public mailing lists for six months. All big conspiracies get exposed - I would make a list, but that would derail the conversation. It does

Re: [Cryptography] Sha3

2013-10-01 Thread James A. Donald
On 2013-10-01 10:24, John Kelsey wrote: If you want to understand what's going on wrt SHA3, you might want to look at the nist website If you want to understand what is going on with SHA3, and you believe that NIST is frank, open, honest, and has no ulterior motives, you might want to look

Re: [Cryptography] encoding formats should not be committee'ized

2013-10-01 Thread James A. Donald
On 2013-10-01 18:06, Ben Laurie wrote: On 1 October 2013 01:10, James A. Donald jam...@echeque.com mailto:jam...@echeque.com wrote: Further, google is unhappy that too-clever-code gives too-clever programmers too much power, and has prohibited its employees from ever doing

Re: [Cryptography] encoding formats should not be committee'ized

2013-10-01 Thread James A. Donald
On 2013-10-01 22:08, Salz, Rich wrote: Further, google is unhappy that too-clever-code gives too-clever programmers too much power, and has prohibited its employees from ever doing something like protobufs again. Got any documentation for this assertion? The google style guide prohibits

Re: [Cryptography] encoding formats should not be committee'ized

2013-10-01 Thread James A. Donald
On 2013-10-02 05:18, Jerry Leichter wrote: To be blunt, you have no idea what you're talking about. I worked at Google until a short time ago; Ben Laurie still does. Both of us have written, submitted, and reviewed substantial amounts of code in the Google code base. Do you really want to

Re: [Cryptography] TLS2

2013-10-01 Thread James A. Donald
On 2013-10-01 14:36, Bill Stewart wrote: It's the data representations that map them into binary strings that are a wretched hive of scum and villainy, particularly because you can't depend on a bit string being able to map back into any well-defined ASN.1 object or even any limited size of

Re: [Cryptography] TLS2

2013-10-01 Thread James A. Donald
On 2013-10-01 14:36, Bill Stewart wrote: It's the data representations that map them into binary strings that are a wretched hive of scum and villainy, particularly because you can't depend on a bit string being able to map back into any well-defined ASN.1 object or even any limited size of

Re: [Cryptography] NIST about to weaken SHA3?

2013-09-30 Thread James A. Donald
On 2013-09-30 14:34, Viktor Dukhovni wrote: On Mon, Sep 30, 2013 at 05:12:06AM +0200, Christoph Anton Mitterer wrote: Not sure whether this has been pointed out / discussed here already (but I guess Perry will reject my mail in case it has):

Re: [Cryptography] NIST about to weaken SHA3?

2013-09-30 Thread James A. Donald
On 2013-10-01 00:44, Viktor Dukhovni wrote: Should one also accuse ESTREAM of maliciously weakening SALSA? Or might one admit the possibility that winning designs in contests are at times quite conservative and that one can reasonably standardize less conservative parameters that are more

Re: [Cryptography] TLS2

2013-09-30 Thread James A. Donald
On 2013-09-30 18:02, Adam Back wrote: If we're going to do that I vote no ASN.1, and no X.509. Just BNF format like the base SSL protocol; Granted that ASN.1 is incomprehensible and horrid, but, since there is an ASN.1 compiler that generates C code we should not need to comprehend it.

Re: [Cryptography] RSA equivalent key length/strength

2013-09-30 Thread James A. Donald
On 2013-10-01 08:24, John Kelsey wrote: Maybe you should check your code first? A couple nist people verified that the curves were generated by the described process when the questions about the curves first came out. And a non NIST person verified that the curves were /not/ generated by

Re: [Cryptography] RSA equivalent key length/strength

2013-09-30 Thread James A. Donald
On 2013-10-01 08:35, John Kelsey wrote: Having read the mail you linked to, it doesn't say the curves weren't generated according to the claimed procedure. Instead, it repeats Dan Bernstein's comment that the seed looks random, and that this would have allowed NSA to generate lots of curves

Re: [Cryptography] encoding formats should not be committee'ized

2013-09-30 Thread James A. Donald
On 2013-10-01 04:22, Salz, Rich wrote: designate some big player to do it, and follow suit? Okay that data encoding scheme from Google protobufs or Facebook thrift. Done. We have a complie to generate C code from ASN.1 code Google has a compiler to generate C code from protobufs source The

Re: [Cryptography] RSA recommends against use of its own products.

2013-09-29 Thread James A. Donald
On 2013-09-27 09:54, Phillip Hallam-Baker wrote: Quite, who on earth thought DER encoding was necessary or anything other than incredible stupidity? I have yet to see an example of code in the wild that takes a binary data structure, strips it apart and then attempts to reassemble it to

Re: [Cryptography] RSA equivalent key length/strength

2013-09-29 Thread James A. Donald
On 2013-09-30 03:14, Lodewijk andré de la porte wrote: 2013/9/29 James A. Donald jam...@echeque.com mailto:jam...@echeque.com (..) fact, they are not provably random, selected (...) fixed that for you It seems obvious that blatant lying about qualities of procedures must have some

Re: [Cryptography] RSA equivalent key length/strength

2013-09-29 Thread James A. Donald
Gregory Maxwell on the Tor-talk list has found that NIST approved curves, which is to say NSA approved curves, were not generated by the claimed procedure, which is a very strong indication that if you use NIST curves in your cryptography, NSA can read your encrypted data. As computing power

Re: [Cryptography] NIST about to weaken SHA3?

2013-09-29 Thread James A. Donald
On 2013-09-30 13:12, Christoph Anton Mitterer wrote: https://www.cdt.org/blogs/joseph-lorenzo-hall/2409-nist-sha-3 This makes NIST seem somehow like liars If one lie, all lies. ___ The cryptography mailing list cryptography@metzdowd.com

Re: [Cryptography] RSA recommends against use of its own products.

2013-09-29 Thread James A. Donald
On 2013-09-29 23:13, Jerry Leichter wrote: BTW, the *idea* behind DER isn't inherently bad - but the way it ended up is another story. For a comparison, look at the encodings Knuth came up with in the TeX world. Both dvi and pk files are extremely compact binary representations - but

Re: [Cryptography] RSA equivalent key length/strength

2013-09-28 Thread James A. Donald
On 2013-09-28 01:23, Phillip Hallam-Baker wrote: Most cryptolibraries have a hard coded limit at 4096 bits and there are diminishing returns to going above 2048. Going from 4096 to 8192 bits only increases the work factor by a very small amount and they are really slow which means we end up

Re: [Cryptography] Random number generation influenced, HW RNG

2013-09-11 Thread James A. Donald
On 2013-09-10 4:30 PM, ianG wrote: The question of whether one could simulate a raw physical source is tantalising. I see diverse opinions as to whether it is plausible, and thinking about it, I'm on the fence. Let us consider that source of colored noise with which we are most familiar:

Re: [Cryptography] Usage models (was Re: In the face of cooperative end-points, PFS doesn't help)

2013-09-11 Thread James A. Donald
On 08/09/2013 21:51, Perry E. Metzger wrote: I wrote about this a couple of weeks ago, see: http://www.metzdowd.com/pipermail/cryptography/2013-August/016872.html In short, https to a server that you /do/ trust. Problem is, joe average is not going to set up his own server. Making setting

[Cryptography] Squaring Zooko's triangle

2013-09-10 Thread James A. Donald
On 2013-09-10 3:12 AM, Peter Fairbrother wrote: I like to look at it the other way round, retrieving the correct name for a key. You don't give someone your name, you give them an 80-bit key fingerprint. It looks something like m-NN4H-JS7Y-OTRH-GIRN. The m- is common to all, it just says

Re: [Cryptography] [cryptography] Random number generation influenced, HW RNG

2013-09-09 Thread James A. Donald
would you care to explain the very strange design decision to whiten the numbers on chip, and not provide direct access to the raw unwhitened output. On 2013-09-09 2:40 PM, David Johnston wrote: #1 So that that state remains secret from things trying to discern that state for purposes of

Re: [Cryptography] Bruce Schneier has gotten seriously spooked

2013-09-08 Thread James A. Donald
On 2013-09-08 4:36 AM, Ray Dillinger wrote: But are the standard ECC curves really secure? Schneier sounds like he's got some innovative math in his next paper if he thinks he can show that they aren't. Schneier cannot show that they are trapdoored, because he does not know where the magic

Re: [Cryptography] Techniques for malevolent crypto hardware

2013-09-08 Thread James A. Donald
On 2013-09-09 11:15 AM, Perry E. Metzger wrote: Lenstra, Heninger and others have both shown mass breaks of keys based on random number generator flaws in the field. Random number generators have been the source of a huge number of breaks over time. Perhaps you don't see the big worry, but real

Re: [Cryptography] Impossible trapdoor systems (was Re: Opening Discussion: Speculation on BULLRUN)

2013-09-08 Thread James A. Donald
On 2013-09-09 4:49 AM, Perry E. Metzger wrote: Your magic key must then take any block of N bits and magically produce the corresponding plaintext when any given ciphertext might correspond to many, many different plaintexts depending on the key. That's clearly not something you can do.

Re: [Cryptography] Market demands for security (was Re: Opening Discussion: Speculation on BULLRUN)

2013-09-08 Thread James A. Donald
On 2013-09-09 6:08 AM, John Kelsey wrote: a. Things that just barely work, like standards groups, must in general be easier to sabotage in subtle ways than things that click along with great efficiency. But they are also things that often fail with no help at all from anyone, so it's hard

Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-06 Thread James A. Donald
On 2013-09-06 12:31 PM, Jerry Leichter wrote: Another interesting goal: Shape worldwide commercial cryptography marketplace to make it more tractable to advanced cryptanalytic capabilities being developed by NSA/CSS. Elsewhere, enabling access and exploiting systems of interest and inserting

Re: [Cryptography] NSA and cryptanalysis

2013-09-02 Thread James A. Donald
On 2013-09-01 9:11 PM, Jerry Leichter wrote: Meanwhile, on the authentication side, Stuxnet provided evidence that the secret community *does* have capabilities (to conduct a collision attacks) beyond those known to the public - capabilities sufficient to produce fake Windows updates. Do we

Re: [Cryptography] NSA and cryptanalysis

2013-08-31 Thread James A. Donald
On 2013-09-01 4:02 AM, Ray Dillinger wrote: On 08/30/2013 08:10 PM, Aaron Zauner wrote: I read that WP report too. IMHO this can only be related to RSA (factorization, side-channel attacks). I have been hearing rumors lately that factoring may not in fact be as hard as we have heretofore

Re: [Cryptography] Thoughts about keys

2013-08-31 Thread James A. Donald
On 2013-09-01 11:16 AM, Jeremy Stanley wrote: At free software conferences, where there is heavy community penetration for OpenPGP already, it is common for many of us to bring business cards (or even just slips of paper) with our name, E-mail address and 160-bit key fingerprint. Useful not

Re: [Cryptography] Petnames Zooko's triangle -- theory v. practice (was Email and IM are...)

2013-08-29 Thread James A. Donald
On 2013-08-28 7:33 PM, ianG wrote: On 28/08/13 02:44 AM, radi...@gmail.com wrote: Zooko's triangle, pet names...we have cracked the THEORY of secure naming, just not the big obstacle of key exchange. Perhaps in a sense of that, I can confirm that we may have an elegant theory but practice

[Cryptography] Communicating public keys: A functional specification

2013-08-29 Thread James A. Donald
Communicating public keys: A functional specification A functional specification tells us how the user uses it, what he sees, and what it does for him. It does not tell us how we manage to do it for him. The problem is that you want to tell someone over the phone, or on a napkin, or face

Re: [Cryptography] Implementations, attacks on DHTs, Mix Nets?

2013-08-25 Thread James A. Donald
On 2013-08-26 11:04 AM, Christian Huitema wrote: Of course the data can be signed, encrypted, etc. But the rule of the game is that the adversary can manufacture as many peers as they want -- something known as the Sybil attack. They can then perform various forms of denial. We need, and have

Re: [Cryptography] What is the state of patents on elliptic curve cryptography?

2013-08-23 Thread James A. Donald
On 2013-08-21 3:38 AM, Perry E. Metzger wrote: What is the current state of patents on elliptic curve cryptosystems? (It would also be useful to know when the patents on such patents as exist end.) Perry Such a question will be answered not with light but with darkness.

Re: 2048 bits, damn the electrons! [...@openssl.org: [openssl.org #2354] [PATCH] Increase Default RSA Key Size to 2048-bits]

2010-10-02 Thread James A. Donald
On 2010-10-01 3:23 PM, Chris Palmer wrote: In my quantitative, non-hand-waving, repeated experience with many clients in many business sectors using a wide array of web application technology stacks, almost all web apps suffer a network and disk I/O bloat factor of 5, 10, 20, ... Which does

Re: 'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps

2010-09-29 Thread James A. Donald
On 2010-09-28 1:58 PM, Thai Duong wrote: On Sat, Sep 18, 2010 at 8:43 PM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: I'm one of the authors of the attack. Actually if you look closer, you'll see that they do it wrong in many ways. The FormsAuth as well, not just the view state?

Re: A mighty fortress is our PKI, Part III

2010-09-16 Thread James A. Donald
On 2010-09-16 6:12 AM, Andy Steingruebl wrote: The malware could just as easily fake the whole UI. Is it really PKI's fault that it doesn't defend against malware? Did even the grandest supporters ever claim it could/did? That is rather like having a fortress with one wall rather than four

Re: Hashing algorithm needed

2010-09-09 Thread James A. Donald
On 2010-09-09 6:35 AM, Ben Laurie wrote: What I do in Nigori for this is use DSA. Your private key, x, is the hash of the login info. The server has g^x, from which it cannot recover x, Except, of course, by dictionary attack, hence g^x, being low entropy, is treated as a shared secret. and

Re: towards https everywhere and strict transport security

2010-08-25 Thread James A. Donald
On 2010-08-25 11:04 PM, Richard Salz wrote: Also, note that HSTS is presently specific to HTTP. One could imagine expressing a more generic STS policy for an entire site 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

Re: Has there been a change in US banking regulations recently?

2010-08-17 Thread James A. Donald
On 2010-08-15 7:59 AM, Thor Lancelot Simon wrote: Indeed. The way forward would seem to be ECC, but show me a load balancer or even a dedicated SSL offload device which supports ECC. For sufficiently strong security, ECC beats factoring, but how strong is sufficiently strong? Do you have

Re: 2048-bit RSA keys

2010-08-17 Thread James A. Donald
On 2010-08-17 3:46 PM, Jonathan Katz wrote: Many on the list may already know this, but I haven't seen it mentioned on this thread. The following paper (that will be presented at Crypto tomorrow!) is most relevant to this discussion: Factorization of a 768-bit RSA modulus,

Re: A mighty fortress is our PKI, Part II

2010-08-06 Thread James A. Donald
On 2010-08-05 11:30 AM, David-Sarah Hopwood wrote: Signatures are largely a distraction from the real problem: that software is (unnecessarily) run with the full privileges of the invoking user. By all means authenticate software, but that's not going to prevent malware. A lot of devices

Re: A mighty fortress is our PKI, Part II

2010-07-29 Thread James A. Donald
On 2010-07-29 12:18 AM, Peter Gutmann wrote: This does away with the need for a CA, because the link itself authenticates the cert that's used. Then there are other variations, cryptographically generated addresses, ... all sorts of things have been proposed. The killer, again, is the refusal

Re: 1280-Bit RSA

2010-07-12 Thread James A. Donald
On 2010-07-11 10:11 AM, Brandon Enright wrote: On Fri, 9 Jul 2010 21:16:30 -0400 (EDT) Jonathan Thornburgjth...@astro.indiana.edu wrote: The following usenet posting from 1993 provides an interesting bit (no pun itended) of history on RSA key sizes. The key passage is the last paragraph,

Re: The EC patent issues discussion

2010-04-22 Thread James A. Donald
On 2010-04-22 9:17 AM, Paul Hoffman wrote: At 9:40 PM -0400 4/20/10, Victor Duchovni wrote: EC definitely has practical merit. Unfortunately the patent issues around protocols using EC public keys are murky. This is starting to turn around. More vendors are questioning the murk.

Re: Question regarding common modulus on elliptic curve cryptosystems

2010-03-25 Thread James A. Donald
On 2010-03-22 11:22 PM, Sergio Lerner wrote: Commutativity is a beautiful and powerful property. See On the power of Commutativity in Cryptography by Adi Shamir. Semantic security is great and has given a new provable sense of security, but commutative building blocks can be combined to build

Re: Question regarding common modulus on elliptic curve cryptosystems AND E-CASH

2010-03-25 Thread James A. Donald
On 2010-03-23 1:09 AM, Sergio Lerner wrote: I've read some papers, not that much. But I don't mind reinventing the wheel, as long as the new protocol is simpler to explain. Reading the literature, I couldn't find a e-cash protocol which : - Hides the destination / source of payments. - Hides

Re: Security of Mac Keychain, Filevault

2009-11-08 Thread James A. Donald
Jerry Leichter wrote: NFC? Near Field Communications - the wireless equivalent of whispering in someone's ear. Ideally, a NFC chip should only be able to talk to something that is an inch or so away, and it should be impossible to eavesdrop from more than a foot or so away. Lots of people

Re: [Barker, Elaine B.] NIST Publication Announcements

2009-09-30 Thread James A. Donald
The Haber Stornetta scheme provides a timestamping service that doesn't require terribly much trust, since hard to forge widely witnessed events delimit particular sets of timestamps. The only issue is getting sufficient granularity. I don't know if their scheme was patented in Germany.

Re: Bringing Tahoe ideas to HTTP

2009-09-15 Thread James A. Donald
Ivan Krsti wrote: What you're proposing amounts to a great deal of complex and complicated cryptography. If it were implemented tomorrow, it would take years for the most serious of implementation errors to get weeded out, and some years thereafter for proper interoperability in corner cases.

Re: Client Certificate UI for Chrome?

2009-09-09 Thread James A. Donald
Steven Bellovin wrote: Several other people made similar suggestions. They all boil down to the same thing, IMO -- assume that the user will recognize something distinctive or know to do something special for special sites like banks. Not if he only does it for special sites like banks,

Re: [tahoe-dev] Bringing Tahoe ideas to HTTP

2009-09-08 Thread James A. Donald
Nicolas Williams wrote: One possible problem: streaming [real-time] content. Brian Warner wrote: Yeah, that's a very different problem space. You need the low-alacrity stuff from Tahoe, but also you don't generally know the full contents in advance. So you're talking about a mutable stream

Re: Client Certificate UI for Chrome?

2009-09-04 Thread James A. Donald
Steven Bellovin wrote: This returns us to the previously-unsolved UI problem: how -- with today's users, and with something more or less like today's browsers since that's what today's users know -- can a spoof-proof password prompt be presented? When the user clicks on a button generated by

Re: [tahoe-dev] a crypto puzzle about digital signatures and future compatibility

2009-08-31 Thread James A. Donald
Zooko Wilcox-O'Hearn wrote: On Wednesday,2009-08-26, at 19:49 , Brian Warner wrote: Attack B is where Alice uploads a file, Bob gets the filecap and downloads it, Carol gets the same filecap and downloads it, and Carol desires to see the same file that Bob saw. ... The attackers (who may

Re: SHA-1 and Git (was Re: [tahoe-dev] Tahoe-LAFS key management, part 2: Tahoe-LAFS is like encrypted git)

2009-08-25 Thread James A. Donald
Perry E. Metzger wrote: Yet another reason why you always should make the crypto algorithms you use pluggable in any system -- you *will* have to replace them some day. Ben Laurie wrote: In order to roll out a new crypto algorithm, you have to roll out new software. So, why is anything

Re: [tahoe-dev] Tahoe-LAFS key management, part 2: Tahoe-LAFS is like encrypted git

2009-08-19 Thread James A. Donald
[*] Linus Torvalds got the idea of a Cryptographic Hash Function Directed Acyclic Graph structure from an earlier distributed revision control tool named Monotone. OT trivia: The idea actually predates either monotone or git; opencm (http://opencm.org/docs.html) was using a similiar

Re: Client Certificate UI for Chrome?

2009-08-18 Thread James A. Donald
James A. Donald jam...@echeque.com writes: [Incredibly complicated description of web scripting plumbing deleted] Peter Gutmann wrote: We seem to be talking about competely different things here. For a typical application, say online banking, I connect to my bank at www.bank.com or whatever

Re: Client Certificate UI for Chrome?

2009-08-12 Thread James A. Donald
Thomas Hardjono wrote: I'm not sure if the Chrome folks would be prepared to ship their browser without any CA certs loaded, Excessive distrust is inconvenient, excessive trust is vulnerable. It is better to remedy flaws by expanding functionality rather than restricting it. On the one hand,

Re: Client Certificate UI for Chrome?

2009-08-12 Thread James A. Donald
James A. Donald jam...@echeque.com writes: [In order to implement strong password based encryption and authentication] on the server side, we need a request object in the script language that tells the script that this request comes from an entity that established a secure connection

Re: Client Certificate UI for Chrome?

2009-08-11 Thread James A. Donald
-- James A. Donald jam...@echeque.com writes: For password-authenticated key agreement such as TLS-SRP or TLS-PSK to work, login has to be in the chrome. Peter Gutmann wrote: Sure, but that's a relatively tractable UI problem Indeed. You know how to solve it, and I know how to solve

Re: Client Certificate UI for Chrome?

2009-08-09 Thread James A. Donald
Peter Gutmann wrote: This is predicated on the assumption that it's possible to make certificates usable for general users. All the empirical evidence we have to date seems to point to this not being the case. Wouldn't it be better to say What can we do to replace certificates with

Re: Client Certificate UI for Chrome?

2009-08-09 Thread James A. Donald
Thomas Hardjono wrote: Having worked at a large CA for along time (trying to push for client-side certs with little luck), here are some thoughts on what Chrome could provide: There are use cases where a centralized authority is useful. Client side is not one of them. Typical usage is is

Re: Client Certificate UI for Chrome?

2009-08-06 Thread James A. Donald
Ben Laurie wrote: So, I've heard many complaints over the years about how the UI for client certificates sucks. Now's your chance to fix that problem - we're in the process of thinking about new client cert UI for Chrome, and welcome any input you might have. Obviously fully-baked proposals are

Re: Fast MAC algorithms?

2009-08-02 Thread James A. Donald
Joseph Ashwood wrote: RC-4 is broken when used as intended. ... If you take these into consideration, can it be used correctly? James A. Donald: Hence tricky Joseph Ashwood wrote: By the same argument a Viginere cipher is tricky to use securely, same with monoalphabetic and even Ceasar

Re: Fast MAC algorithms?

2009-07-26 Thread James A. Donald
From: Nicolas Williams nicolas.willi...@sun.com For example, many people use arcfour in SSHv2 over AES because arcfour is faster than AES. Joseph Ashwood wrote: I would argue that they use it because they are stupid. ARCFOUR should have been retired well over a decade ago, it is weak, it

Re: 112-bit prime ECDLP solved

2009-07-16 Thread James A. Donald
Tanja Lange wrote: So with about 1 000 000 USD and a full year you would get 122 bits already now and agencies have a bit more budget than this! Furthermore, the algorithm parallelizes extremely well and can handle a batch of 100 targets at only 10 times the cost. No it cannot handle a bunch

Re: 112-bit prime ECDLP solved

2009-07-14 Thread James A. Donald
Hi all, We are pleased to announce that we have set a new record for the elliptic curve discrete logarithm problem (ECDLP) by solving it over a 112-bit finite field. The previous record was for a 109-bit prime field and dates back from October 2002. See for more details our announcement at

Re: Warning! New cryptographic modes!

2009-05-21 Thread James A. Donald
Jerry Leichter wrote: Consider first just updates. Then you have exactly the same problem as for disk encryption: You want to limit the changes needed in the encrypted image to more or less the size of the change to the underlying data. Generally, we assume that the size of the encrypted

Re: Security through kittens, was Solving password problems

2009-02-25 Thread James A. Donald
John Levine jo...@iecc.com writes: Clever though this scheme [kittens] is, man-in-the middle attacks make it no better than a plain SSL login screen. Peter Gutmann wrote: You don't even need a MITM, just replace the site image on your phishing site with either a broken- image picture or a

Re: full-disk subversion standards released

2009-02-13 Thread James A. Donald
Ben Laurie wrote: If I have data on my server that I would like to stay on my server and not get leaked to some third party, then this is exactly the same situation as DRMed content on an end user's machine, is it not? No. You want to keep control of the information on your server. DRM wants

Re: Why the poor uptake of encrypted email?

2008-12-18 Thread James A. Donald
Nicolas Williams wrote: Providing a suitable e-mail security solution for the masses strikes me as more important than providing anonymity to the few people who want or need it. Not that you can't have both, unless you want everyone to use PGP or S/MIME as a way to hide anonymized traffic

Re: Why the poor uptake of encrypted email?

2008-12-18 Thread James A. Donald
Peter Gutmann wrote: ... to a statistically irrelevant bunch of geeks. Watch Skype deploy a not- terribly-anonymous (to the people running the Skype servers) communications system. Actually that is pretty anonymous. Although I am sure that Skype would play ball with any bunch of goons that

Re: CPRNGs are still an issue.

2008-12-11 Thread James A. Donald
Jack Lloyd wrote: I think the situation is even worse outside of the major projects (the OS kernels crypto implementations and the main crypto libraries). I think outside of those, nobody is even really looking. For instance - This afternoon I took a look at a C++ library called JUCE which

Re: Why the poor uptake of encrypted email? [Was: Re: Secrets and cell phones.]

2008-12-11 Thread James A. Donald
-- We discovered, however, that most people do not want to manage their own secrets StealthMonger wrote: This may help to explain the poor uptake of encrypted email. There is very good uptake of skype and ssh, because those impose no or very little additional cost on the end

e-gold and e-go1d

2008-11-29 Thread James A. Donald
To implement Zooko's triangle, one has to detect names that may look alike, for example e-gold and e-go1d This is a lot of code. Has someone already written such a collision detector that I could swipe? The algorithm is to map all lookalike glyphs to canonical glyphs - thus l and 1 are mapped

Re: Bitcoin P2P e-cash paper

2008-11-18 Thread James A. Donald
Ray Dillinger wrote: Okay I'm going to summarize this protocol as I understand it. I'm filling in some operational details that aren't in the paper by supplementing what you wrote with what my own design sense tells me are critical missing bits or obvious methodologies for use. There

Re: Bitcoin P2P e-cash paper

2008-11-18 Thread James A. Donald
Nicolas Williams wrote: How do identities help? It's supposed to be anonymous cash, right? Actually no. It is however supposed to be pseudonymous, so dinging someone's reputation still does not help much. And say you identify a double spender after the fact, then what? Perhaps you're

Re: Bitcoin P2P e-cash paper

2008-11-17 Thread James A. Donald
Satoshi Nakamoto wrote: Fortunately, it's only necessary to keep a pending-transaction pool for the current best branch. This requires that we know, that is to say an honest well behaved peer whose communications and data storage is working well knows, what the current best branch is - but of

Re: Bitcoin P2P e-cash paper

2008-11-13 Thread James A. Donald
Satoshi Nakamoto wrote: When there are multiple double-spent versions of the same transaction, one and only one will become valid. That is not the question I am asking. It is not trust that worries me, it is how it is possible to have a a globally shared view even if everyone is well

Re: Bitcoin P2P e-cash paper

2008-11-10 Thread James A. Donald
-- James A. Donald wrote: OK, suppose one node incorporates a bunch of transactions in its proof of work, all of them honest legitimate single spends and another node incorporates a different bunch of transactions in its proof of work, all of them equally honest legitimate single

Re: Bitcoin P2P e-cash paper

2008-11-09 Thread James A. Donald
-- 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 transaction

voting by m of n digital signature?

2008-11-09 Thread James A. Donald
Is there a way of constructing a digital signature so that the signature proves that at least m possessors of secret keys corresponding to n public keys signed, for n a dozen or less, without revealing how many more than m, or which ones signed?

Re: Bitcoin P2P e-cash paper

2008-11-09 Thread James A. Donald
Satoshi Nakamoto wrote: Increasing hardware speed is handled: To compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour. If they're generated too

Re: Bitcoin P2P e-cash paper

2008-11-09 Thread James A. Donald
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

Re: Bitcoin P2P e-cash paper

2008-11-05 Thread James A. Donald
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 transactions that occurred recently

Secrets and cell phones.

2008-11-05 Thread James A. Donald
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

Re: Bitcoin P2P e-cash paper

2008-11-02 Thread James A. Donald
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

  1   2   3   4   >