Re: Logging of Web Usage
Bill Frantz wrote: At 6:16 PM -0800 4/2/03, Seth David Schoen wrote: Bill Frantz writes: The http://cryptome.org/usage-logs.htm URL says: Low resolution data in most cases is intended to be sufficient for marketing analyses. It may take the form of IP addresses that have been subjected to a one way hash, to refer URLs that exclude information other than the high level domain, or temporary cookies. Note that since IPv4 addresses are 32 bits, anyone willing to dedicate a computer for a few hours can reverse a one way hash by exhaustive search. Truncating IPs seems a much more privacy friendly approach. This problem would be less acute with IPv6 addresses. I'm skeptical that it will even take a few hours; on a 1.5 GHz desktop machine, using openssl speed, I see about a million hash operations per second. (It depends slightly on which hash you choose.) This is without compiling OpenSSL with processor-specific optimizations. Ah yes, I haven't updated my timings for the new machines that are faster than my 550Mhz. :-) The only other item is importance is that the exhaustive search time isn't the time to reverse one IP, but the time to reverse all the IPs that have been recorded. You only need to build the dictionary once. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Logging of Web Usage
John Young wrote: Ben, Would you care to comment for publication on web logging described in these two files: http://cryptome.org/no-logs.htm http://cryptome.org/usage-logs.htm Cryptome invites comments from others who know the capabilities of servers to log or not, and other means for protecting user privacy by users themselves rather than by reliance upon privacy policies of site operators and government regulation. This relates to the data retention debate and current initiatives of law enforcement to subpoena, surveil, steal and manipulate log data. I don't have time right now to comment in detail (I will try to later), but it seems to me that, as someone else commented, relying on operators to not keep logs is really not the way to go. If you want privacy or anonymity, then you have to create it for yourself, not expect others to provide it for you. Of course, it is possible to reduce your exposure to others whilst still taking advantage of privacy-enhancing services they offer. Two obvious examples of this are the mixmaster anonymous remailer network, and onion routing. It seems to me if you want to make serious inroads into privacy w.r.t. logging of traffic, then what you want to put your energy into is onion routing. There is _still_ no deployable free software to do it, and that is ridiculous[1]. It seems to me that this is the single biggest win we can have against all sorts of privacy invasions. Make log retention useless for any purpose other than statistics and maintenance. Don't try to make it only used for those purposes. Cheers, Ben. [1] FWIW, I'd be willing to work on that, but not on my own (unless someone wants to keep me in the style to which I am accustomed, that is). -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Russia Intercepts US Military Communications?
Eric Rescorla wrote: John Gilmore [EMAIL PROTECTED] writes: Remember, the cypherpunks ... secured any Web traffic Credit where it's due. Netscape was responsible for this. Only for the client side (and the protocol, of course). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
Ed Gerck wrote: BTW, this is NOT the way to make paying for CA certs go away. A technically correct way to do away with CA certs and yet avoid MITM has been demonstrated to *exist* (not by construction) in 1997, in what was called intrinsic certification -- please see www.mcg.org.br/cie.htm Phew, that is a lot of pages to read (40?). Its also rather though material for me to digest. Do you have something like an example approach written up? I couldn't find anything on the site that did not require study. ;-) If anyone comes across a way to explain it, that does not require study, please let me know and I'll post it. AFAICS, what it suggests, in a very roundabout way, is that you may be able to verify the binding between a key and some kind of DN by being given a list of signatures attesting to that binding. This is pretty much PGP's Web of Trust, of course. I could be wrong, I only read it quickly. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
Ed Gerck wrote: Ben Laurie wrote: Ed Gerck wrote: ;-) If anyone comes across a way to explain it, that does not require study, please let me know and I'll post it. AFAICS, what it suggests, in a very roundabout way, is that you may be able to verify the binding between a key and some kind of DN by being given a list of signatures attesting to that binding. This is pretty much PGP's Web of Trust, of course. I could be wrong, I only read it quickly. This would still depend on what the paper calls extrinsic references, that are outside the dialogue and create opportunity for faults (intentional or otherwise). The resulting problems for PGP are summarized in www.mcg.org.br/cert.htm#1.2. It seems to me that the difference between PGP's WoT and what you are suggesting is that the entity which is attempting to prove the linkage between their DN and a private key is that they get to choose which signatures the relying party should refer to. Am I wrong? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Lucre paper updated
I have updated the Lucre paper with a new section on choosing parameters, in response to question from the lucrative project. It can be found in the usual place: http://anoncvs.aldigital.co.uk/lucre/. If I find (or write) free software that does primality proofs, then I guess I'll update it again! Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Proven Primes
Tero Kivinen wrote: Ben Laurie writes: Jack Lloyd wrote: Check RFC 2412, draft-ietf-ipsec-ikev2-05.txt, and draft-ietf-ipsec-ike-modp-groups-05.txt However, I don't seen any primality proof certificates included in the texts. I considered adding the ecpp certificates to draft-ietf-ipsec-ike-modp-groups document, but as the certificates are several magabytes in total, there is no point of adding them to this kind of document (the document would be several hundred pages long consisting only numbers...). RFC 2412 looks good, however, as you say, no certificates are included, nor is it made clear that (p-1)/2 has been proven. I-Ds are less useful to me, since I can't give a long-term reference for them :-( The draft-ietf-ipsec-ike-modp-groups used to have pointer to the ftp site having the certificates (ftp://ftp.ssh.fi/pub/ietf/ecpp-certificates), but that was removed during the IESG review, because url references are not stable enough in general (the ftp://ftp.ssh.fi/pub/ietf/ecpp-certificates site is supposed to be there forever). That site also includes certificates of modp groups from the RFC 2412 (and (p-1)/2 also). Thanks. I actually just finished finding the 16384 bit Diffie-Helman group with same kind of parameters. It took about 9.5 months to generate. The 12288 bit group took only about 15 days to generate. I have to admit to surprise at the time involved - what s/w are you using to do the generating? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Proven Primes
Jack Lloyd wrote: I believe the IPSec primes had been proven. All are SG primes with a g=2 Check RFC 2412, draft-ietf-ipsec-ikev2-05.txt, and draft-ietf-ipsec-ike-modp-groups-05.txt However, I don't seen any primality proof certificates included in the texts. RFC 2412 looks good, however, as you say, no certificates are included, nor is it made clear that (p-1)/2 has been proven. I-Ds are less useful to me, since I can't give a long-term reference for them :-( Thanks! Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Proven Primes
I'm looking for a list or lists of sensibly sized proven primes - all the lists I can find are more interested in records, which are _way_ too big for cryptographic purposes. By sensibly sized I mean in the range 512-8192 bits. I'm particularly after Sophie Germain primes right now, but I guess all primes are of interest. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [open-source] Open Source TCPA driver and white papers
Douglas Lee Schales wrote: In reply to your message dated: Wed, 22 Jan 2003 13:09:30 EST This is has descended into the ridiculous. TCPA has been tossed about as being a great coming evil, the end of the open computing world. We finally get some technical information published about TCPA that's not only of keen interest to the Open Source community, but also of use (source code). The only result of this publication is an inane discussion about the use of hacker vs cracker. Get a grip... discuss the technical content! Actually, I think its important to be clear about the differences between TCPA and Palladium. It seems quite obvious that _this version_ of TCPA is not designed (unlike Palladium) to provide DRM, though it is equally clear that they've failed to point out the obvious attack (which is to intercept the content once it has been decrypted, an attack Palladium explicitly defends against). In the meantime, the arguments demonstrating their weakness as a DRM platform are rather unsound. They make two main points: 1. Variations in BIOS, OS and application will render it impossible to check PCR values. However, this argument also renders the chip useless for its intended purpose (i.e. if the PCR values change, you can no longer unseal your keys!). 2. The chip is vulnerable to power analysis and other advanced trickery. This may be true, but is quite probably not in reach of the ordinary user. So, one must wonder why they mention these points but not the easy attack (snarf the content after decryption)? Presumably because they intend to close that at some point in the future, so using it as a defence now would be bad. Of course, once that hole is closed TCPA _is_ Palladium. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Patents as a security mechanism
Matt Blaze wrote: Patents were originally intended, and are usually used (for better or for worse), as a mechanism for protecting inventors and their licensees from competition. But I've noticed a couple of areas where patents are also used as a security mechanism, aiming to prevent the unauthorized production of products that might threaten some aspect of a system's security. One example close to home is the DVD patents, which, in addition to providing income for the DVD patent holders, also allows them to prevent the production of players that don't meet certain requirements. This effectively reduces the availability of multi-region players; the patents protect the security of the region coding system. FWIW, the precedent was set in a lesser way with CDs - there is an area that isn't writable on CD-Rs, which can be prefilled at manufacture time. AFAIK, no-one ever actually used it as a security mechanism, but it was there. On a related note, you could licence either data-only or data and music from Phillips (or is it Philips?), and they were pretty aggressive about protecting it (I know because I wrote one of the first rippers [CD-Grab] and they used to get excited about it periodically, since it worked on data-only drives). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Prime numbers guru 'factors' down success
William Knowles wrote: Prime numbers (such as 1, 5, 11, 37...) are divisible only by themselves or 1. While smaller prime numbers are easy to make out, for very large numbers, there never had been a formula for primality testing until August 2002. Doh! This is so untrue. The point is that they discovered a test that wasn't NP, for the first time. OK, so its P but with a vast constant, but even so, there must be a point at which it gets better than the best NP methods. I wonder if anyone's worked out where that point is? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: What email encryption is actually in use?
Matthew Byng-Maddick wrote: On Wed, Oct 02, 2002 at 10:04:03AM -0500, Jeremey Barrett wrote: BTW, most and probably all of the major mail clients out there will do STARTTLS *for SMTP*. It's a matter of servers offering it and clients being configured to actually use it. It'd be nice if they always used it if it's available, but right now I think they all require being told to. I have to say that much as it is a laudable goal to get widespread encryption on the SMTP server network, I'm rapidly coming to the conclusion that opportunistic encryption in this way doesn't really work. Consider where one side believes that it will only accept certificates signed by a particular CA (a perfectly plausible scenario in the case of SSL/TLS), and I hand it a self-signed one - this is not communicable before the connection starts up, and in-protocol, a failure to apply policy causes the connection to be shut down (this is by no means the only one, consider one side that only use DES and the other that never use it), leaving the connection in an undefined state. The problem with this is obvious. You have to treat the failure as a temporary failure and try again in a bit. Of course, we know that the only way you're going to send this system mail is by sending it in plaintext, because otherwise you won't adhere to policy, but also, given that it's an automated service, there's no human to turn round and try something slightly different, as there is in the case of the Web Browser or mail client talking SSL. I remain to be convinced on the value of opportunistic encryption. In my mind it doesn't, apparently, do anything useful. Of course, properly configured SSL, I'd agree with, but that means advertising what you're going to talk in some way that means you won't get half way through the protocol and leave it in an undefined state. If you are going to do opportunistic encryption, then you have to be prepared to be opportunistic. Clearly, configuring your server so it can't encrypt opportunistically is a barrier to opportunistic encryption. It isn't hard to set up SSL so it will interoperate with everything (this is why there are mandatory ciphersuites). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Real-world steganography
Peter Gutmann wrote: I recently came across a real-world use of steganography which hides extra data in the LSB of CD audio tracks to allow (according to the vendor) the equivalent of 20-bit samples instead of 16-bit and assorted other features. According to the vendors, HDCD has been used in the recording of more than 5,000 CD titles, which include more than 250 Billboard Top 200 recordings and more than 175 GRAMMY nominations, so it's already fairly widely deployed. Yeah, right - and green felt-tip around the edges of your CD improves the sound, too. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Sun donates elliptic curve code to OpenSSL?
Markus Friedl wrote: On Mon, Sep 23, 2002 at 02:50:20PM +0100, Ben Laurie wrote: (1) they promise not to sue Sun for infringing any of their own patents which might cover the use of the donated code (2) don't modify Sun's code as provided by Sun, don't use only parts of the donated code, and don't remove the license text from the code. Note that if you don't want to be bound by Sun's licence, there's a flag to remove all their donated code (at least, there's supposed to be, I haven't checked). This is a very bad move, especially since the code and copyright in question are spread all over the source tree. so a flag does not really help. You still have to 'use' the source files for building libssl. Actually, the flag does help (and it defaults off, I'm told). With this code OpenSSL is turning into a non-free project. Thank you very much. Thank you for moving patent litigation licenses into OpenSSL. As has been observed elsewhere, the patent stuff only applies if you make a similar promise to Sun. If you don't want to have Sun not sue you when you infringe, then don't promise not to sue them. Have you actually read the licence? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: unforgeable optical tokens?
David Wagner wrote: What is it, then? The ultimate pokemon card! Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cryptographic privacy protection in TCPA
Nomen Nescio wrote: Some of the claims seem a little broad, like this first one: 1. A method for establishing a pseudonym system by having a certificate authority accepting a user as a new participant in said pseudonym system, the method comprising the steps of: receiving a first public key provided by said user; verifying that said user is allowed to join the system; computing a credential by signing the first public key using a secret key owned by said certificate authority; publishing said first public key and said credential. Wouldn't this general description cover most proposed credential systems in the past, such as those by Chaum or Brands? Or, indeed, X.509. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cryptographic privacy protection in TCPA
Nomen Nescio wrote: It looks like Camenisch Lysyanskaya are patenting their credential system. This is from the online patent applications database: http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2Sect2=HITOFFp=1u=/netahtml/PTO/search-bool.htmlr=1f=Gl=50co1=ANDd=PG01s1=camenischOS=camenischRS=camenisch Hmmm. I see they've made the usual mistake with the rest of the world, though. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Palladium and buffer over runs
bear wrote: On Thu, 29 Aug 2002, Frank Andrew Stevenson wrote: What is there to prevent that one single undisclosed buffer overrun bug in a component such as Internet Explorer won't shoot down the whole DRM scheme of Palladium ? Presumably IE will be able to run while the machine is in a trusted state, but if the IE can be subverted by injecting compromising code through a buffer overrun, the security of DRM material that is viewed in one window could be compromised through malicious code that has been introduced through another browser window. It's my understanding of Palladium that it can enforce a separate data space for applications by creating a memory space which is encrypted with a key known to only that application. Given that, I think a cracker could subvert IE normally, but that wouldn't result in any access to the protected space of any other applications. And as long as IE is actually separate from your OS (if you're running it on your Mac, or under WINE from Linux, for example), it shouldn't give him/her access to anything inside the OS. Apart from the content being accessed by IE, of course, which is quite likely to be the stuff that is supposed to be DRMed. Oh, but Palladium isn't for that. I forgot. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Palladium and malware
Paul Crowley wrote: I'm informed that malware authors often go to some lengths to prevent their software from being disassembled. Could they use Palladium for this end? Are there any ways in which the facilities that Palladium and TCPA provide could be useful to a malware author who wants to frustrate legitimate attempts to understand and defeat their software? That would depend on what facilities the OS layers on top of TCPA/Palladium. Certainly I could believe an OS would exist that would simply refuse read access to executables, and Palladium/TCPA could be used to encrypt them such that they were inaccessible except under that OS. So, in short. Yes. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Overcoming the potential downside of TCPA
Joseph Ashwood wrote: - Original Message - From: Ben Laurie [EMAIL PROTECTED] Joseph Ashwood wrote: There is nothing stopping a virtualized version being created. What prevents this from being useful is the lack of an appropriate certificate for the private key in the TPM. Actually that does nothing to stop it. Because of the construction of TCPA, the private keys are registered _after_ the owner receives the computer, this is the window of opportunity against that as well. The worst case for cost of this is to purchase an additional motherboard (IIRC Fry's has them as low as $50), giving the ability to present a purchase. The virtual-private key is then created, and registered using the credentials borrowed from the second motherboard. Since TCPA doesn't allow for direct remote queries against the hardware, the virtual system will actually have first shot at the incoming data. That's the worst case. The expected case; you pay a small registration fee claiming that you accidentally wiped your TCPA. The best case, you claim you accidentally wiped your TCPA, they charge you nothing to remove the record of your old TCPA, and replace it with your new (virtualized) TCPA. So at worst this will cost $50. Once you've got a virtual setup, that virtual setup (with all its associated purchased rights) can be replicated across an unlimited number of computers. The important part for this, is that TCPA has no key until it has an owner, and the owner can wipe the TCPA at any time. From what I can tell this was designed for resale of components, but is perfectly suitable as a point of attack. If this is true, I'm really happy about it, and I agree it would allow virtualisation. I'm pretty sure it won't be for Palladium, but I don't know about TCPA - certainly it fits the bill for what TCPA is supposed to do. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Overcoming the potential downside of TCPA
Joseph Ashwood wrote: Lately on both of these lists there has been quite some discussion about TCPA and Palladium, the good, the bad, the ugly, and the anonymous. :) However there is something that is very much worth noting, at least about TCPA. There is nothing stopping a virtualized version being created. There is nothing that stops say VMWare from synthesizing a system view that includes a virtual TCPA component. This makes it possible to (if desired) remove all cryptographic protection. Of course such a software would need to be sold as a development tool but we all know what would happen. Tools like VMWare have been developed by others, and as I recall didn't take all that long to do. As such they can be anonymously distributed, and can almost certainly be stored entirely on a boot CD, using the floppy drive to store the keys (although floppy drives are no longer a cool thing to have in a system), boot from the CD, it runs a small kernel that virtualizes and allows debugging of the TPM/TSS which allows the viewing, copying and replacement of private keys on demand. Of course this is likely to quickly become illegal, or may already, but that doesn't stop the possibility of creating such a system. For details on how to create this virtualized TCPA please refer to the TCPA spec. What prevents this from being useful is the lack of an appropriate certificate for the private key in the TPM. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: dangers of TCPA/palladium
AARG!Anonymous wrote: Adam Back writes: - Palladium is a proposed OS feature-set based on the TCPA hardware (Microsoft) Actually there seem to be some hardware differences between TCPA and Palladium. TCPA relies on a TPM, while Palladium uses some kind of new CPU mode. Palladium also includes some secure memory, a concept which does not exist in TCPA. This is correct. Palladium has ring -1, and memory that is only accessible to ring -1 (or I/O initiated by ring -1). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Challenge to David Wagner on TCPA
Lucky Green wrote: Ray wrote: From: James A. Donald [EMAIL PROTECTED] Date: Tue, 30 Jul 2002 20:51:24 -0700 On 29 Jul 2002 at 15:35, AARG! Anonymous wrote: both Palladium and TCPA deny that they are designed to restrict what applications you run. The TPM FAQ at http://www.trustedcomputing.org/docs/TPM_QA_071802.pdf reads They deny that intent, but physically they have that capability. To make their denial credible, they could give the owner access to the private key of the TPM/SCP. But somehow I don't think that jibes with their agenda. Probably not surprisingly to anybody on this list, with the exception of potentially Anonymous, according to the TCPA's own TPM Common Criteria Protection Profile, the TPM prevents the owner of a TPM from exporting the TPM's internal key. The ability of the TPM to keep the owner of a PC from reading the private key stored in the TPM has been evaluated to E3 (augmented). For the evaluation certificate issued by NIST, see: http://niap.nist.gov/cc-scheme/PPentries/CCEVS-020016-VR-TPM.pdf Obviously revealing the key would defeat any useful properties of the TPM/SCP. However, unless the machine refuses to run stuff unless signed by some other key, its a matter of choice whether you run an OS that has the aforementioned properties. Of course, its highly likely that if you want to watch products of Da Mouse on your PC, you will be obliged to choose a certain OS. In order to avoid more sinister uses, it makes sense to me to ensure that at least one free OS gets appropriate signoff (and no, that does not include a Linux port by HP). At least, it makes sense to me if I assume that the certain other OS will otherwise become dominant. Which seems likely. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: building a true RNG
David Wagner wrote:
Amir Herzberg wrote:
So I ask: is there a definition of this `no wasted entropy` property, which
hash functions can be assumed to have (and tested for), and which ensures
the desired extraction of randomness?
None that I know of. I'm not aware of much work in the crypto literature
on this topic.
Actually, there is not much hope for such a property. It is pretty easy
to see that, if we make no assumptions on the entropy inputs other than
they have sufficient entropy, then no single deterministic algorithm can
ever be good at extracting randomness. If we fix any single extraction
algorithm A, there exists a distribution D on the inputs which make it
give non-uniform output (for example, D might be the uniform distribution
on the set {x : A(x) has its first ten bits zero}). This is a standard
observation from the theory community's work on derandomization.
That's the kind of thing mathematicians like to say - but how much does
it apply to the real world? For example, you can't produce your example
set for SHA-1 or MD5, can you?
If you are prepared to factor in cost, then the landscape changes, I
would contend. Mathematicians generally assume uncountable resources.
Even constructivists assume countable resources. However, we can assume
_finite_ resources. Big difference.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
Available for contract work.
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: crypto/web impementation tradeoffs
John Saylor wrote: Hi I'm passing some data through a web client [applet-like] and am planning on using some crypto to help ensure the data's integrity when the applet sends it back to me after it has been processed. The applet has the ability to encode data with several well known symmetric ciphers. The problem I'm having has to do with key management. Is it better to have the key encoded in the binary, or to pass it a plain text key as one of the parameters to the applet? I know that the way most cryptosystems work is that the security is in the key. But having a compiled-in key just seems like a time bomb that's going to go off eventually. Is it better to have a variable key passed in as data [i.e. not marked as key] or to have a static key that sits there and waits to be found. If all you want to ensure is integrity, why are you using symmetric encryption? Surely a keyed HMAC would make more sense? Not that this changes your question. However, you haven't specified your threat model, so I feel unable to answer. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Shortcut digital signature verification failure
David Wagner wrote: Bill Frantz wrote: If there is a digital signature algorithm which has the property that most invalid signatures can be detected with a small amount of processing, then I can force the attacker to start expending his CPU to present signatures which will cause my server to expend it's CPU. My 800MHz PIII can do about 2800 512-bit RSA verifies per second. Dan Bernstein has a signature algorithm where verification is significantly faster still [1], and his ideas could probably be used to quickly reject most invalid signatures with even better efficiency. What David left out here is that this should be about 10 times as fast as signing. 20 times for 1024 bit, 30 for 2048 and 60 for 4096 - so the answer is use bigger keys. Note that even using 4096 bit keys my (totally non-optimal debugging build of) OpenSSL can do over 80 verifies a second on a PIII of average speed (and less than two signs). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
[Fwd: More on biometric shortcomings:]
-- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff ---BeginMessage--- http://www.theregister.co.uk/content/55/25444.html Palm Beach International Airport security workers would be racking up heaps of overtime pay dealing with more than fifty false positives daily if their bosses were to install Visionics http://www.visionics.com' terror-busting face recognition gear, the airport administrators have concluded. ## dave ## ---End Message---
[Fwd: E-Money]
-- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff ---BeginMessage--- This gem of crypto-related news seems to have slipped by unobserved... UK leads e-Money revolution By IT Analysis Posted: 29/04/2002 at 15:41 GMT It is not everyday that the United Kingdom is seen to be leading the European Union (EU), never mind the rest of the world, but on Saturday April 27 2002-E Day--Britain became the first member state to implement the EU directive covering the issuing of electronic money. The British, of course, responded to this momentous event with traditional disinterest. snip full story at: http://www.theregister.co.uk/content/23/25070.html Cheers, Bob. ---End Message---
Re: authentication protocols
John Saylor wrote: Hi I'd like to find an authentication protocol that fits my needs: 1. 2 [automated] parties 2. no trusted 3rd party intemediary ['Trent' in _Applied_Crypto_] Most of the stuff in _Applied_Crypto_ requires that third party. It may be an impossible task, nothing seems obvious to me. Pointers, suggestions, or aphorisms all welcome. You need to specify what you are trying to achieve! For example, its easy to avoid third parties if you have already exchanged keys. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: biometrics
Dan Geer wrote: In the article they repeat the recommendation that you never use/register the same shared-secret in different domains ... for every environment you are involved with ... you have to choose a different shared-secret. One of the issues of biometrics as a shared-secret password (as opposed to the interface between you and your chipcard) is that you could very quickly run out of different, unique body parts. Compare and contrast, please, with the market's overwhelming desire for single-sign-on (SSO). Put differently, would the actual emergence of an actual SSO signal a market failure by the above analysis? Surely the point about (good) SSO is that you control the domain you share secrets with and that domain then certifies you to other domains - thus avoiding the problem of sharing your secrets across domains. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Unbreakable? (fwd)
This suffers from the same flaw as the last proposal: the security lies in the idea that you can't store the data for long enough to be able to decrypt the message that says where in the bitstream your data is. However, this is defeatable by a delay line of sufficient length, just like the last idea (where, if you remember, the keying material was in the fast random stream instead). Cheers, Ben. Sean McGrath wrote: -- Forwarded message -- Date: Sun, 3 Feb 2002 15:49:51 -0500 From: R. A. Hettinga [EMAIL PROTECTED] To: Digital Bearer Settlement List [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Unbreakable? http://www.idg.net/crd_idgsearch_1.html?url=http://www.cio.com/archive/020102/et_development.html UNDER DEVELOPMENT Encryption Unbreakable? AS MYSTICS SEARCH for the lost island of Atlantis and UFO buffs seek out alien spacecraft, cryptologists are continuing their own quest to create an unbreakable code. Michael Rabin, a Harvard University computer science professor, believes he has moved cryptology a step closer to its Holy Grail by developing a code that's undecipherable, even by those who have access to both the cypher text and unlimited computing power. Advertisers Rabin's Hyper-Encryption technology, which uses a device that quickly generates a deluge of random bits, relies on both time and money to thwart even the most dedicated code breaker. A coded message would be hidden within the bits like raisins in a pudding, quips Rabin. While anyone can read the random bits, the transmission rate is so high that storing all of the stream for analysis would be either technically unfeasible or cost prohibitive. Hyper-Encryption has sparked the interest of several U.S. government agencies, says Rabin. He also claims to have received inquiries from some wealthy investors and at least one major venture capital fund. But Rabin states he's not currently interested in the technology's commercial potential. Right now, commerce comes second to science, he says. Hyper-Encryption, however, is not entirely trouble free. The chief concern is cost, since the technology requires users to send continuous, intense streams of high-speed data across already bandwidth-starved networks. Rabin's solution is to create a dedicated global satellite system. The cost could be shared by its users, he says. In any case, Hyper-Encryption is designed to safeguard highest-level government secrets, not routine commercial and personal transmissions. It's most appropriate for protecting national interests and large sums of money, says Rabin. Although Hyper-Encryption exists only on the blackboard, Rabin maintains that the technology is ready for use. There's mathematical proof the Hyper-Encryption provides everlasting security, so there's nothing left to do but implement it, he says. -John Edwards -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Losing the Code War by Stephen Budiansky
Amir Herzberg wrote: The `meet in the middle` attack works against double encryption; that's why Triple DES is performing three DES operations with two keys. Some variants use 3 keys, in fact. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Losing the Code War by Stephen Budiansky
marius wrote: But there was an utterly trivial fix that DES users could employ if they were worried about security: they could simply encrypt each message twice, turning 56-bit DES into 112-bit DES, and squaring the number of key sequences that a code breaker would have to try. Messages could even be encrypted thrice; and, indeed, many financial institutions at the time were already using Triple DES. Not quite true. Encrypting each message twice would not increase the effective key size to 112 bits. There is an attack named meet in the middle which will make the effective key size to be just 63 bits. ?? 56 bits plus a little, surely. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Perdue Done (Watermarked) It (was Re: Edupage, February 1, 2002)
R. A. Hettinga wrote: At 5:54 PM -0700 on 2/1/02, EDUCAUSE wrote: DIGITAL WATERMARKING MAKES INTERNET VIDEO SPLASH Purdue University researchers have found a way to ensure Internet-delivered video maintains its watermark and keeps channel disturbance to a minimum, protecting the content from copyright infringement and hackers. Purdue professor of computer engineering Edward Delp said the technique allows for resynchronization at the receiving end that can decipher and piece together Internet video streams that are often chopped and mixed up while traveling over noisy networks. The result, said Delp, is the integrity of the watermark and image, while the stream is still delivered in real time. Traditional methods of piecing together Internet-delivered content largely do not work for audio and video, he added. The technique also helps guard against hackers because of the way it controls channel disturbance, and could also be used to decipher terrorist messages embedded in Internet-delivered video. (NewsFactor Network, 31 January 2002) Yeah right, and it makes coffee and will prevent kiddyporn, too. Oh, did they mention that it also does biometrics through your mouse? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: biometrics
Bill Frantz wrote: At 4:06 PM -0800 1/28/02, [EMAIL PROTECTED] wrote: at least part of the fingerprint as a PIN ... isn't the guessing issue /or false positives it is the forgetting issue (and the non-trivial number of people that write their PIN on the card). Or to state it another way. These cards attempt to use two factor authentication, what you have (the card) and what you know (the PIN). When a user writes the PIN on the card, it becomes one factor authentication. Almost anything that returns it to being two factor security would be an improvement. (Biometrics offers the possibility of 3 factor authentication. What would be really nice is to be able to have the same PIN/password for everything. With frequent use, forgetting it would be less of a problem, as would the temptation to write it down. However, such a system would require that the PIN/password be kept secret from the verifier (including possibly untrusted hardware/software used to enter it. This is why you need to carry your verifying equipment around with you - a PDA with a decent OS is the way to go, IMO. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: biometrics
P.J. Ponder wrote: Without think about it some more, I don't know whether to place the entire notion of security controls based on biometric telemetry in with _pure_ bullshit like copy protection, watermarking, non-repudiation, tamper proofing, or trusted third parties. Admittedly, there is a lot of bullshit in the idea, I'm just not sure it is pure. Why are trusted third parties pure bullshit? Surely there are circumstances where a third party really can be trusted? Or are you talking about the tainted meaning of TTPs (i.e. spooks that hold your private keys)? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A risk with using MD5 for software package fingerprinting
David Honig wrote: At 12:07 PM 1/27/02 -0500, Arnold G. Reinhold wrote: if an attacker had an agent working inside the organization that produced the package, the agent could simply insert the Trojan software patch in the original package. However such an insertion is very risky. A sophisticated software company would likely have code reviews that would make introduction of the Trojan code difficult. Um, right. A good company would have *design* reviews, but would it really spend time having skilled engineers review *all* the actual codelines One of the duties of a person with commit access to an Apache Software Foundation project is, indeed, to review _all_ commits to that package. Admittedly any particular individual will sometimes only glance at the commit, but bugs are picked up at this stage with such regularity that I am confident that the vast majority of commits are, in fact, reviewed. I believe this practice is pretty common in free software. Oh, I should note that commits are emailed to all committers, so it does not require the committers to actively seek out commits to review. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Horseman Number 3: Osama Used 40 bits
Trei, Peter wrote: [Moderator's note: It wasn't a direct quote, and I generally assume reporters misquote people anyway. Also, note that the general confusion because the UK uses thousand million for the US billion makes the whole thing even less clearly the expert and not the reporter. --Perry] Actually, to my perpetual dismay, we are now supposed to use a billion in the US sense (it used to mean a million million). As a result, I don't use the word at all, since it predictably has become ambiguous in the UK. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
Eric Rescorla wrote: Ben Laurie [EMAIL PROTECTED] writes: Michael Sierchio wrote: Carl Ellison wrote: If that's not good enough for you, go to https://store.palm.com/ where you have an SSL secured page. SSL prevents a man in the middle attack, right? This means your credit card info goes to Palm Computing, right? Check the certificate. To be fair, most commercial CA's require evidence of right to use a FQDN in an SSL server cert. But your point is apt. And most (all?) commercial CAs then disclaim any responsibility for having actually checked that right correctly... While this is true, I'd point out that all the security software you're using disclaims any responsibility for not having gaping security holes. I have the source to all the security software I'm using... in fact, I wrote quite a lot of it :-) Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Steganography covert communications - Between Silk andCyanide
Matt Crawford wrote: David Honig wrote: Unbeknown to the latter, Marks had already cracked General de Gaulle's private cypher in a spare moment on the lavatory. -from the obit of Leo Marks, cryptographer But this was because it was, in fact, one of his own ciphers. Cheers, Ben. Not one that he invented or approved of, but one that he knew and had to work with, yes. Indeed, it was the cipher he inherited (and spent much time and energy to have replaced, for excellent reasons). Cheers, Ben. -- http://www.apache-ssl.org/ben.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
Nelson Minar wrote: Of course, client side certificates barely even exist, although people made substantial preparation for them early on in the history of all of this. I used to be puzzled by this. Then a couple of years ago I went through the process of getting a client-side certificate to access my student records at MIT. MIT is the only place I've ever seen to require client-side certs for authentication, bless 'em. It took me 30 minutes to establish a client side certificate, just so I could view a web page with my own data on it. *thirty minutes*. And I know a lot about cryptography. How would someone who'd never heard of a public key do? This was on Netscape 4.0 on Linux. Maybe MSIE things have improved since then, but I doubt it. (Anyone know?) I've never found it particularly hard to generate a client cert in either Netscape or IE - but the time consuming part is the meatspace component - verifying your identity to the CA/RA so they'll sign the certificate. Of course, going through all of this to access a single page is silly. The two useful aspect of client certs (IMNSHO) are firstly that they allow single sign-on with access control in a way that does not require all systems to communicate with some central authority and secondly they give a way to bind an identity (or simply a set of permissions/privileges/capabilities/whatevers) to a private key. Of course, if your threat model means you must check a certificate's validity immediately, then the first advantage is mostly gone. However, you almost always need the second property, AFAICS, to do anything useful with PKC. If you have some kind of entity that binds a private key to some other stuff, then that is a certificate, IMO. Equating certificates with X.509 is missing the point. As for the certificateless model - all this really does is move the binding from something you can carry around with you to something that has to be done by a central authority. It is not clear to me why this is such a marvellous improvement. Unless you happen to want to own the central authority, of course, which, unlike certificates and CAs, is far harder to replicate privately and therefore, presumably, potentially even more profitable than Verisign's cash cow. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: quantum computer factors number
Steve Bellovin wrote: A quantum computer has been built that has actually factored a number: 15. It's not a very interesting number from a cryptographic perspective, but it is real. http://www.nature.com/nature/links/011220/011220-2.html Its worth noting that not only is the number not very interesting (15), but various properties of it have been used to make the quantum computer simpler. The quantum computer would not be capable of performing any other calculation. In particular, addition has been substituted for multiplication in one part of the calculation, and the other multiplication has been changed to a completely different operation (bit swapping). Once simplified thus, several operations were omitted because they were known to not actually influence the outcome or because enough of their inputs were known to make them guaranteed to be null operations. These changes are described as optimisations - but since in any real case they would involve performing most of the calculation on a classical computer (AFAICS), its difficult to see how this experiment demonstrates anything other than a remarkable ability to control and measure the quantum state of 7 atoms in a molecule. Which is impressive in itself, but it seems hardly fair to describe it is factorisation. Probably the coolest thing about this experiment is that they have produced what appears to be a very accurate model of the decoherence effects, which should allow quantum computers to be modelled with some certainty in the future. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: private-sector keystroke logger...
[EMAIL PROTECTED] wrote: Jay D. Dyson writes: -BEGIN PGP SIGNED MESSAGE- On Tue, 27 Nov 2001 [EMAIL PROTECTED] wrote: Hrm, how about a worm with a built-in HTTP server that installs itself on some non-standard port, say TCP/28462 (to pick one at random)? Craftier still, backdoor an existing service that behaves normally until it receives a few specially-crafted packets, then it opens a high port for direct login or data retrieval. Neither of these will get past a firewall on an uncompromised machine. While I didn't enumerate the service that could be backdoored, I do believe Eric Murray hit the nail on the canonical head when he mentioned that such a beastie could target the firewall's configuration, forcing it to relax its stance enough to allow the automated intrusion agent plenty of latitude to conduct its business. I am assuming a firewall on a separate machine, which simply does not allow incoming connections to the window's boxes, and constrains the outgoing connections. I do not claim that this prevents all covert loss of data, but it constrains the options, and certainly does not permit the described backdoor to work. Yeah right - so it sets up an outgoing connection to some webserver to pass on the info. Firewall that. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
SciAm conference on privacy and security
Just came across this: http://www.globalprivacysummit.net/ I notice a few of the Usual Suspects amongst the more blatant commercial interests... Cheers, Ben. -- http://www.apache-ssl.org/ben.html There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: limits of watermarking (Re: First Steganographic Image in theWild)
Roop Mukherjee wrote: On Thu, 18 Oct 2001, Marc Branchaud wrote: This analogy doesn't quite hold. Copy protection need only be broken once for the protection to be disabled for a particular piece of work. Also, once the scheme is known for one piece of work, it is extremely easy to break the scheme for other pieces, and in particular to write an application that will do so. With crypto's bar-raising, OTOH, breaking one instance, like an SSL stream or an AES key, does not break all other uses of SSL or AES. In particular, SSL AES will provide the same degree of protection for any other communication of the same data between the same or other parties. Also, good crypto schemes are already widely known and designed explicitly so that knowledge of the scheme does not break the scheme. M. I am not certain which scheme of copy protection you are refering to. But I agree that any scheme that relies on a secret recipie (ala Coca Cola) would not be effective. The analogy was intended towards publicy know provably strong means of copy protection. Most security measures these days would be foolish to choose otherwise. My impression of the DRM work that was being undertaken is that most of it aiming towards open specifications that are provably secure. For instance the SDMI charter says, ...to develop open technology specifications that protect the playing, storing, and distributing of digital music Measures like this would indeed raise the bar in much the same way as some other security measures like SSL did. If it were possible, it would indeed raise the bar. The problem is, it would seem, that it is not possible to have a provably strong means of copy protection, publicly known or otherwise. The SDMI charter can say what it wants, but that doesn't mean it can be achieved. The arguments that support the impossibility of the goal have been well rehearsed, so I won't repeat them here. Cheers, Ben. -- http://www.apache-ssl.org/ben.html There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: limits of watermarking (Re: First Steganographic Image in theWild)
Marc Branchaud wrote: This analogy doesn't quite hold. Copy protection need only be broken once for the protection to be disabled for a particular piece of work. Also, once the scheme is known for one piece of work, it is extremely easy to break the scheme for other pieces, and in particular to write an application that will do so. With crypto's bar-raising, OTOH, breaking one instance, like an SSL stream or an AES key, does not break all other uses of SSL or AES. In particular, SSL AES will provide the same degree of protection for any other communication of the same data between the same or other parties. Also, good crypto schemes are already widely known and designed explicitly so that knowledge of the scheme does not break the scheme. Although I agree with the general point, I should just mention that if an SSL break is a break of a private key, then future communications between the broken party and others may be compromised. Cheers, Ben. -- http://www.apache-ssl.org/ben.html There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: limits of watermarking (Re: First Steganographic Image in the Wild)
Adam Back wrote: Another framework is to have players which will only play content with certified copy marks (no need for them to be visible -- they could be encoded in a logo in the corner of the screen). The copymark is a signed hash of the content and the identity of the purchaser. This could be relatively robust, except that usually there is also a provision for non-certified content -- home movies etc -- and then the copy mark can be removed while still playing by converting the content into the home movie format, which won't and can't be certified. The other obvious weakness in such a scheme is that the player can be modified to ignore the result of the check - rather like defeating dongles, which have yet to exhibit any noticable resistance to crackers. Cheers, Ben. -- http://www.apache-ssl.org/ben.html There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: limits of watermarking (Re: First Steganographic Image in the Wild)
Adam Back wrote: In my opinion copymarks are evil and doomed to fail technically. There always need to be playble non-certified content, and current generation watermarks seem easy to remove; and even if some really good job of spread spectrum encoding were done, someone would reverse engineer the players to extract the location parameters and then they too would be removable -- and in the end even if someone did manage to design a robust watermarking scheme respecting Kerchoff's principle, the identity information is weakly authenticated, and subject to identity theft or the content itself could be stolen or plausibly deniably claimed to have been stolen and this only has to happen once for each work. The thing that gets me about all this is that exactly the same argument can be made for all existing media - and, although piracy is rife, no-one is attempting to mark videotapes or CDs, AFAIK. So why all the fuss about more modern digital media? Has no-one noticed all the ripped videotapes, CDs and DVDs? Are we really expected to believe the whole media reproduction industry is ever going to switch over to producing each disc individually, expensively watermarked? So what's the real agenda? And don't tell me its because broadband will eliminate physical media: a) I believe physical media will always have higher bandwidth than broadband - why? Because you have to feed the broadband from somewhere, and archive it somewhere. b) Even if physical media goes away, individual watermarking blows away multicast - and broadband will just never work without that. It seems to me that putting the details of the purchaser in plaintext on the beginning of the file and making it illegal to remove it is as good a protection as you are ever going to get - but that would ruin a whole bunch of business plans, so I guess no expert is going to admit that. In short, the agenda, it seems to me, is the business plans of companies in the watermarking business. No more, no less. I'm amazed the media moguls are willing to waste so much of their time and money on it. Cheers, Ben. -- http://www.apache-ssl.org/ben.html There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: limits of watermarking (Re: First Steganographic Image in the Wild)
Matt Crawford wrote: a) I believe physical media will always have higher bandwidth than broadband - why? Because you have to feed the broadband from somewhere, and archive it somewhere. You can use an expensive physical medium to drive your transmission. If you sell atoms, you have to use a cheap medium. I'll admit that my argument doesn't stand up to severe testing - but I think it is important that in general the receivers of the stream will also want to store it (certainly my almost complete transition to TiVo-ized TV viewing [what little I do] would support that theory :-). Which is what I meant by archive it somewhere, but I see now was far from clear. Cheers, Ben. -- http://www.apache-ssl.org/ben.html There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Scarfo keylogger, PGP
Trei, Peter wrote: Windows XP at least checks for drivers not signed by MS, but whose security this promotes is an open question. Errr ... surely this promotes MS's bottom line and no-one's security? It is also a major pain if you happen to want to write a device driver, of course. Cheers, Ben. -- http://www.apache-ssl.org/ben.html There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AGAINST ID CARDS
Carl Ellison wrote: Declan, we already have a national ID card: a passport. Are you required to have one? Certainly in the UK its only required if you want to leave the EU (though there are still some people manning the borders that believe it is required for travel within the EU). Cheers, Ben. -- http://www.apache-ssl.org/ben.html There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Rijndael in Assembler for x86?
Ian Goldberg wrote something above this: [Moderator's note: The best DES implementations for i386s in assembler are several times faster than the best in C. I'm not sure about AES but I'd prefer to try and see. Perhaps it's a feature of DES's odd bit manipulation patterns, perhaps not. I have yet to see GCC produce code for almost anything that was just as fast as hand tuned assembler, though. --Perry] By far the best assember I ever saw from a C compiler came from Watcom's. I'm sure I remember hearing they open sourced it a while back. Or did I dream that? Cheers, Ben. -- http://www.apache-ssl.org/ben.html There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: nettime Pirate Utopia, FEED, February 20, 2001
Grant Bayley wrote: --- begin forwarded text Status: U From: Julian Dibbell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: nettime Pirate Utopia, FEED, February 20, 2001 Date: Thu, 20 Sep 2001 08:37:20 -0500 Sender: [EMAIL PROTECTED] Reply-To: Julian Dibbell [EMAIL PROTECTED] Key concepts: steganography, encryption, Osama bin Laden, intellectual property, temporary autonomous zone, pirates. It's a shame that Niels Provos, one of the main developers of open-source Steganography software at the moment wasn't able to detect a single piece of information hidden steganographically in a recent survey of two million images... Sort of destroys the whole hype about the use of it by criminals. He did only look for one particular encoding technique (at least, that was true when we discussed it in April), so his failure to find anything cannot be considered to be conclusive. Cheers, Ben. -- http://www.apache-ssl.org/ben.html There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: chip-level randomness?
Bram Cohen wrote: On Wed, 19 Sep 2001, Peter Fairbrother wrote: Bram Cohen wrote: You only have to do it once at startup to get enough entropy in there. If your machine is left on for months or years the seed entropy would become a big target. If your PRNG status is compromised then all future uses of PRNG output are compromised, which means pretty much everything crypto. Other attacks on the PRNG become possible. Such attacks can be stopped by reseeding once a minute or so, at much less computational cost than doing it 'continuously'. I think periodic reseedings are worth doing, even though I've never actually heard of an attack on the internal state of a PRNG which was launched *after* it had been seeded properly once already. There was a bug in OpenSSL's PRNG (and BSAFEs) which permitted recovery of the internal state from a largish number of small outputs. It has been fixed, of course. Cheers, Ben. -- http://www.apache-ssl.org/ben.html There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Compression side channel
Greg Rose wrote: At 12:44 AM 9/9/2001 -0400, Sandy Harris wrote: Does using non-adaptive compression save the day? Huffman coding using a fixed code table is not a bad way to go. You can even peek at the characteristics of the input and choose a table based on that... having standardised tables for English text, intel machine code, MS-word documents, C code, other languages, etc. Fax machines do something like this, with a huffman code table conditioned on a set of standard documents, but I'm not sure whether it is just a single table or a set of choose one of these. Choosing one of a set of tables would be a bad idea - I can then use the chosen plaintext to force the choice of particular tables, which would then leak information copiously. Cheers, Ben. -- http://www.apache-ssl.org/ben.html There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Field slide attacks and how to avoid them.
John Kelsey wrote: -BEGIN PGP SIGNED MESSAGE- [ To: Perry's Crypto List ## Date: 09/08/01 07:35 pm ## Subject: Field slide attacks and how to avoid them. ] Guys, I've been noticing a lot of ways you can mess up a cryptographic protocol due to the sliding around of fields within a signed or MACed message. The classic example of this is the old attack on PGP fingerprints, which let you use some odd keysize, and thus get two different keys (with different keysizes) with the same hash, without breaking the hash function. (The raw bits of the two keys are the same, but the fields are broken up differently.) The natural way to resist this is to ensure that all information used to parse a hashed/MACed/signed message is included in the signature. But I was curious whether anyone knows of other standard, simple ways to deal with this problem? ASN.1/DER. Note that I am not advocating it, merely pointing out that it a standard (if not entirely simple) way to deal with the problem. d. Encode the fields first, in such a way that there is a single unambigous field separator between fields. For example, use the simple encoding rule that anytime three bytes of successive 0x00s are encoded, we always insert a 0x01 byte next. Use four successive 0x00 bytes as the field separator. The decoding rules work just the opposite: Whenever we run into 0x00,0x00,0x00, if the next byte is 0x00, we've hit a field separator; if it's a 0x01, we discard the 0x01 and continue decoding. Its more efficient to insert the 0x01 (in the 4th position) only if there is a run of 4 0x00, or 0x00,0x00,0x00,0x01. Cheers, Ben. -- http://www.apache-ssl.org/ben.html There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Compression side channel
Peter Wayner wrote: b. I'm hoping to find out if anyone else has seen similar work anywhere. I've not been able to find any references to this kind of attack, though once you've had the idea to try it, it's really pretty straightforward. (And I know there are a couple of occasional posters on this list who know a heck of a lot more about compression algorithms than I do. Peter, are you listening?) These are all good ideas, but I don't know how often you'll get to try them, much less use them enough to extract enough information. I wrote a paper a long time ago that tweaked compression algorithms. It wasn't meant to be secure, only ensure that the compression algorithms constantly changed the set of bits assigned to each character. This meant that a Huffman algorithm encoding 'e' as '0010' at one point would use '1011' later. It was a simple remapping of the compression tree so it wouldn't cost much. But I don't think it had any security on its own. It also wouldn't help at all in this context, since all that is used is the length, not the bits (which, inherently, you don't know anyway). Cheers, Ben. -- http://www.apache-ssl.org/ben.html There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: moving Crypto?
Richard Schroeppel wrote: It's time to consider moving the annual Crypto conference out of Santa Barbara. The obvious places are Vancouver, Toronto, or Mexico. I know zilch about these places as conference venues. Could someone knowledgable summarize the relative merits? How about London? Cheers, Ben. -- http://www.apache-ssl.org/ben.html There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: HushMail 2.0 released, supports OpenPGP standard
Declan McCullagh wrote: Phil Zimmermann, Managing Director of the OpenPGP Alliance And, err, Hush employee... (www.openpgp.org) said, I am very encouraged by the support given to the OpenPGP Alliance by founding members such as Hush Communications. As an early adopter of the OpenPGP standard, Hush is encouraging the widespread adoption of secure platforms and improvements with technical interoperability. I am confident that more users will quickly come to recognize and appreciate the added security benefits and ease of use that HushMail Version 2.0 offers. Cheers, Ben. -- http://www.apache-ssl.org/ben.html There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypographically Strong Software Distribution HOWTO
Rich Salz wrote: Oh? How? All you are suggesting is that the role key is held by a CA - well, who is that going to be, then? Unh, no. The same way the ASF determines who gets commit access could be teh same way the ASF determines who their CA will give release-signing keys to. The same way the ASF takes away someone's commit access is the same way they could update the CRL. All those key update, distribution, revocation, etc., stuff -- all those hard problems you said you want to automate -- go away. Recipients need only trust the Apache CA and its CRL. So how does this work in practice? How does an ASF subproject instruct the CA? How does one that's more divorced from any kind of formal structure? Seems to me you are introducing a monster security hole unless you somehow secure the instructions to the CA - and I can't see how to do that at all - at least, not without doing what I already proposed (and having the CA as the sole monitor of the correctness of the process). If Verisign can be spoofed into signing a Microsoft key, what hope for this model? None, IMO. Cheers, Ben. -- http://www.apache-ssl.org/ben.html There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypographically Strong Software Distribution HOWTO
V. Alex Brennen wrote: In the case of such a large project, perhaps you could issue a separate role key pair to each developer and generate revocation certificates which are held by the core group for those keys. When a developer leaves the group, the revocation certificate for his key would be circulated. Role keys could be identified by signatures from a Master Key in a traditional model (much like PKI), through the posting of a list of authorized keys digitally signed with a master key, or in an anarchistic model (which it sounds to me is what you're describing) by signatures from other core developers. A threshhold could be established to consider a key officially certified for release, or a single signature could be acceptable. Maybe this is what you're looking for, a model of authorization like PKI except that it is based in the model of PGP's decentralized web of trust? I am, but I don't like the idea of core developers - you are merely pushing back the place where you want a single key (or a well-defined set of keys) - and I claim that is not a realistic plan. You have to also allow the set of core developers to gradually change over time. Granted totally decentralized project like Apache cannot adopt the steps of the howto exactly as they are written with out altering their release model. However, such projects can make extremely beneficial use of third party testimonials, as the Apache Project does. Third party signatures on releases could be distributed with the release and the third parties performing those signatures could be the core developers. Core developers are obviously in a strong position to speak about authenticity and content. While the use of core developer signatures as third party testimonials would make such a group slightly more vulnerable to trojan horse attacks via faked key pairs, this level of increased vulnerability is not (in my opinion) very significant. Agreed. I think it would be good to see the Apache Project make a policy as to request (require) the signature of releases by the individual responsible for the release. It would also be good to ask apache core members to generate new version 4 openPGP keys to replace older keys and continue to build the excellent web of trust that the group has established. The October ApacheCon in Europe would be an excellent time to integrate new version 4 keys into the Apache web of trust. I'm not sure I understand the significance of this request - why are version 4 keys better? Also, it would be nice to see the Apache group make its use of PGP signatures more prominent by posting a signature policy (if one is developed), and by linking to keys on a trusted keyserver as well as distributing them from the site so that new signatures are immediately available to people who wish to verify the testimonials of the core developers. Finally, perhaps the Apache Foundation would be willing to pick up the standards put forth in the HOWTO for files names of signatures? Everyone is pretty much doing their own thing right now - I tried to pick up the most popular stuff for standards I put forth in the howto. So, you pretty clearly have to do something that allows multiple keys to be used. It seems to me that the way to do this is to have tools that manage a set of keys which may change over time. The keys sign each other (the signatures would have to be tagged as signatures that allow a particular software distribution to be signed) and the user trusts the _set_ of keys, using the tools to check how keys get added and removed, ensuring that appropriate signatures are on new keys, and that revocations of old keys/signatures are checked. Organisations like the Apache Software Foundation can also have cross-checking between sets of keys to reduce the pain of building initial trust in a set of keys for a new piece of software from that organisation. [...] It is a non-trivial task, so if anyone wants to help with it, please let me know! I've been working on code similar to what you're describing as prototype perl scripts which I intend to port to patches against GnuPG. I'd be happy to help develop the tools necessary to allow Apache to embrace a strong distribution model more easily. Further, I would be greatfull to have an opportunity to contribute to a project such as Apache. Just let me know what you have and what you need. OK, looks like a new project is about to be born. Apache guys: does the ASF want to adopt this (given that the substrate is likely to be GPLed)? Or shall I set it up on my servers? Cheers, Ben. -- http://www.apache-ssl.org/ben.html There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL
Re: [JXTA Security] Anonymity Snake Oil in JXTA
Philippe Coupe wrote: Here is some answer to Ben Laurie legitimate questions (sorry for the delay but I was off last week) ... [...]They have chosen (by what process?) a thing called EPocketCash (http://www.epocketcash.com/[1]) to do this[...] JXTA neither SUN did not chose to implement EPocketCash. I, as CEO of IPassport Corporation (who operates EPocketCash) proposed to the JXTA governance to implement our payment system (inside JXTA). Again, we will implement the JXTA merchant and client parts of our payment system. The source code will be fully available and will follow open source licence guidelines set by JXTA governance. If you want to create another payment system project you are free to propose and implement it yourself... Later, the market will decide (and not you, me or JXTA community/governance) ... OK, this has been pointed out by a few other people. It should be _much_ clearer on the website. [...] it is tied to bank accounts [...] You like it or not but, worldwide, banks manage the money. Without a bank accout there is no way to put money to/from any payment system of anykind. A payment system is only a process to debit/credit a bank account. Oh yeah? So what are these banknotes and coins in my pocket, then? With EPocketCash, this account is not a regular account or a checking account but an EPocketCash/Your_Bank (co-branded like your VISA card) account opened at this branch of this bank (of course it must be a bank who partner with us). Your checking/saving (or any existing) account are not linked to your EPocketCash account... So can I open one without presenting ID? Can I transfer cash into one without ID? [...]Oh, except a judge[...] Like it or not but we are a US corporation and as such we have to follow the laws and regulations of the USA. And those do _not_ state that you are required to track money. [...]Oh, and probably either side of the transaction (so they can take you to court, see? Isn't that a marvellous benefit? [well, they told me it was, and they should know, right?]) [...] No, the merchant never know the identity/account number of the client. Test our technology yourself as a client and as a merchant and check it yourself. Through JXTA, try to understand the system and if needed, help us fix it... So how do I get to take legal action against the merchant as you described? How does a merchant take action against a fraudulent client? Remember, here, we all work on the JXTA project and it's a community based work... So publish your technical documentation, in its entirety. Cheers, Ben. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ben Laurie Sent: Thursday, June 28, 2001 7:43 PM To: Coderpunks; Cryptography; UKCrypto Cc: JXTA Security Subject: [JXTA Security] Anonymity Snake Oil in JXTA JXTA (http://www.jxta.org/) claims to have a payment project which will implement anonymous and secure financial transactions. See: http://payment.jxta.org/servlets/ProjectHome They have chosen (by what process?) a thing called EPocketCash (http://www.epocketcash.com/[1]) to do this. Here's the marketing droidlish: The goal is to implement the Epocketcash payment protocol for financial transactions for JXTA. EPocketCash is the first payment system designed exclusively for the Internet. It allows anybody to be a merchant and/or a customer at the same time with the same account. This anonymous payment system will work on any gizmos connected to the internet. Currently we support the WEB, WAP and I-Mode phones. Sounds great, no? There's just one teeny problem. It isn't anonymous. Not even a little bit. It is merely secret. That is, it is tied to bank accounts, and they promise (no, really) that they won't tell anyone who you are. Oh, except a judge. Oh, and probably either side of the transaction (so they can take you to court, see? Isn't that a marvellous benefit? [well, they told me it was, and they should know, right?]). Oh, and anyone who breaks into their system. But it is anonymous really. They said so. Cheers, Ben. [1] I can't actually read this, it renders horribly on Netscape, but my information comes from Philippe Coupe, President and CEO of IPassport Corp (who own EPocketCash?). -- http://www.apache-ssl.org/ben.html In Boston 'til 1st July. -- http://www.apache-ssl.org/ben.html There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: crypto flaw in secure mail standards
Enzo Michelangeli wrote: - Original Message - From: Greg Broiles [EMAIL PROTECTED] To: Enzo Michelangeli [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, June 25, 2001 1:32 AM Subject: Re: crypto flaw in secure mail standards [...] The digital signature laws I've seen don't mention and don't support the notion of non-repudiation, which seems to be an obsession among computer security people and a non-issue among legal people. The idea that something is non-repudiable or unarguable or unavoidable is nonsense. I use it as a clue detector - if someone talks about non-repudiation, they don't know much about US contract law. I don't know about US contract law, but under Common Law repudiation _is_ an issue, and that's why witnessing is required. Moreover, there are attempts to change the legal implications of signing a document if this is done in an electronic environment, shifting the onus of proof of the claim of forgery to the (alleged) signatory. See e.g. http://www.firstmonday.dk/issues/issue5_8/mccullagh/#m4 about the controversial Article 13 of the UNCITRAL Model Law. I think you are missing the point - repudiation is an issue, but nothing is non-repudiable. It seems pretty fundamental to me - I can deny anything. I might have a hard time getting away with it, but at the very least you'll have to demonstrate that my denial is implausible (which is why witnesses help). It also seems to me that one of the problems with electronic signatures is that witnessing is harder, at least if you want to be disconnected from the witness. To make it stick as well as physical witnessing does would require the witness to actually watch my screen and say yes, he definitely intended to sign that document I see on the screen (note that I say intended because witnesses could also be useful to protect against fraudulent software). I'd guess that a phone call to discuss the fingerprint of the document would have some value if presence cannot be achieved, but it would be hard to deal with fraudulent software by that mechanism. Reading the whole document over the phone is presumed to not be an option :-) Cheers, Ben. -- http://www.apache-ssl.org/ben.html In Boston 'til 1st July. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: septillion operations per second
Barry Wels wrote: Hi, In James Bamford's new book 'Body of Secrets' he claims the NSA is working on some FAST computers. http://www.randomhouse.com/features/bamford/book.html --- The secret community is also home to the largest collection of hyper-powerful computers, advanced mathematicians and skilled language experts on the planet. Within the city, time is measured in femtosecondsone million billionth of a second, and scientists work in secret to develop computers capable of performing more than one septillion (1,000,000,000,000,000,000,000,000) operations every second. --- If they ever build such a computer (or 1.000.000 of them) what would that mean for today's key lengths ? I am curious how long a computer capable of a septillion operations per second would take to crack one 128 bit or 256 bit key. Or a RSA 1024 or 2048 bit key for that matter ... 10^24 is roughly 2^80. So, to _count_ to 2^128 would take 2^48 seconds. That's around 9 million years. Or, for a million of them, 9 years. Cheers, Ben. -- http://www.apache-ssl.org/ben.html In Boston 'til 1st July. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NTT offering free licenses for algorithms (incl. Camellia)
Kristen Tsolis wrote: According to Nikkan Kogyo News, NTT is offering four patented algorithms under royalty-free license for limited purposes. These algorithms include Camellia, EPOC, PSEC, and ESIGN. http://news.yahoo.co.jp/headlines/nkn/010418/nkn/08100_nkn13.html NTT made this announcement on the same day as the last CRYPTREC meeting. The CRYPTREC project was initiated by Japan's Information-technology Promotion Agency (IPA). The goal of CRYPTREC is to define standard cryptographic algorithms for use within the Japanese government. http://www.ipa.go.jp/security/enc/CRYPTREC/index-e.html There was extensive discussion on the inclusion of Camellia in TLS ciphersuites recently - I can't remember the outcome, though, sorry. Cheers, Ben. -- http://www.apache-ssl.org/ben.html There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff ApacheCon 2001! http://ApacheCon.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
