Re: objectivity and factoring analysis
On Mon, 13 May 2002, bear wrote: One thousand years = 10 iterations of Moore's law plus one year. Call it 15-16 years? Or maybe 20-21 since Moore's seems to have gotten slower lately? Moore's law is about integration density. That has zero to do with problem-specific system performance. That one is indeed lagging. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Freedom Corps vs. Software Security?
On Mon, 22 Jul 2002, Hadmut Danisch wrote: Can american software be trusted anymore, when the US government wants to turn 4% of the US citizens into spys? Wrong question. The right (albeit rhetorical) question: can closed source software, regardless of its point of origin, be trusted, at least in principle? The answer for most people should be: no. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: building a true RNG (was: Quantum Computing ...)
On Mon, 22 Jul 2002, David Honig wrote: Yes, it is a joke. However, it is also a viable if low-bandwidth entropy source. I disagree that you need to be able to model I've got a framegrabber with a 640x480 24 bit/pixel camera. It doesn't compress, is rather noisy, and since self-adjusting I get the maximum entropy at maximum darkness. Is there any point in compressing the video before running it through a cryptohash? How does e.g. SHA-1 fare with very sparse bitvectors? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: building a true RNG
On 24 Jul 2002, Paul Crowley wrote: I can't believe any compression software could be as fast as just feeding the signal straight into SHA-1. I haven't tried this, but assuming I'm digitizing dark video and only get noise in the lower significant bits I can just mask out the constant (zero) ones and paste them together to destill the entropy with a very low computational cost before feeding it into a cryptohash. As an aside to what constitutes physical entropy of a system it is indeed depending on context of the measurement. A good source of information on entropy in all contexts is http://www.math.psu.edu/gunesch/entropy.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
adding noise blob to data before signing
1) What's the name of the technique of salting/padding an small integer I'm signing with random data? 2) If I'm signing above short (~1 kBit) sequences, can I sign them directly, or am I supposed to hash them first? (i.e. does a presence of an essentially fixed field weaken the signature) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [mnet-devel] Ditching crypto++ for pycrypto (fwd)
-- Forwarded message -- Date: Mon, 02 Dec 2002 12:25:39 -0500 From: Zooko [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [mnet-devel] Ditching crypto++ for pycrypto I have to admit that Crypto++'s build/port problems suck, a lot. I still have a weird fondness for it (Stockholm Syndrome?). One feature is that Crypto++ is going to be adopted by the OSAF, which means it will be supported even better than it is now (including new Python wrappers), and might also mean that OSAF would throw money at someone who maintained good Python wrappers for them. Requirements for backwards compatibility with v0.6: * DES-X, CTS mode (Hal Finney has contributed a patch that will implement this on OpenSSL) * RSA, OAEP (we have OAEP, or something much like it, implemented in Python) ? Things I want in the future: * Rijndael * CBC mode * SHA-1 (provided in Python Standard Library, of course, but using the crypto libraries version might be faster due to closer binding to other crypto computations) * SHA-512 * Rizzo's forward erasure code (Wei Dai has said he would consider integrating it with Crypto++ and supporting it, but again it doesn't *need* to be part of the crypto library) * integration with system random pools --Z --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ mnet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mnet-devel - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Help! (fwd)
-- Forwarded message -- Date: Fri, 6 Dec 2002 03:12:30 +0100 (CET) From: Robert Harley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Help! Help! I need access to a big fast machine ASAP, to count points on a humongous elliptic curve. That requires running a process that takes about 8 GB of memory (it can be partly swap space - the program is written to run well in virtual memory). I have't figured out how to parallelize the algorithm at all and it needs a few days of CPU on a fast 64-bit machine. Best of all is something like a 1 GHz Alpha or Itanium 2 (preferably with a friendly sysadmin to increase per-process resource limits :) If any FoRKer can think of a way of getting access, please make it happen and spend some karma points if necessary! Many thanks in advance to those who can be of assistance, Rob. .-. .-. / \ .-. .-. / \ / \ / \ .-. _ .-. / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / `-' `-' \ / \ / \ \ / `-' `-' \ / `-' `-' http://xent.com/mailman/listinfo/fork-noarchive - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Microsoft: Palladium will not limit what you can run
Unfortunately no one can accept in good faith a single word coming out of Redmond. Biddle has been denying Pd can be used for DRM in presentation (xref Lucky Green subsequent patent claims to call the bluff), however in recent (of this week) Focus interview Gates explicitly stated it does. This is merely a most recent lie in a long sequence of it. Operating from behind an anonymous remailer doesn't quite have the same handicap as having microsoft.com as part of your email address, but the heavy spinmeistering does reveal the origin as reliably. You can use your real emal address next time. Let's see, we have an ubiquitous built-in DRM infrastructure, developed under great expense and deployed under costs in an industry turning over every cent twice, and no-one is going to use it (Palladium will limit what programs people can run)? Right. It's all completely voluntary. There will be no attempts whatsoever to lock-in, despite decades of attempts and considerable economic interests involved. On Thu, 13 Mar 2003, Hermes Remailer wrote: Hopefully this will shed light on the frequent claims that Palladium will limit what programs people can run, or take over root on your computer, and similar statements by people who ought to know better. It is too much to expect these experts to publicly revise their opinions, but perhaps going forward they can begin gradually to bring their claims into line with reality. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Microsoft: Palladium will not limit what you can run
On Sat, 15 Mar 2003, Anonymous wrote: Microsoft's point with regard to DRM has always been that Palladium had other uses besides that one which everyone was focused on. Obviously Of course it's useful. Does the usefulness outweigh the support for special interests (DRM, governments, software monopolies)? There is no value for the end user which can't be achieved with smart cards, which have the additional potential of being removable and transportable. they fully expect people to use the technology. I'm not sure where you get the part about it being deployed under costs. Is this more of the XBox analogy? That's a video game system, where No, I meant it's a nonnegligible incremental cost on the system. It increases the chipcount and/or the design complexity, and requires strong encryption on interchip and intercomponent bus traffic. I don't know what the increased cost on a motherboard is, but it's probably in the dollar range at least. Very nonegligible for an industry learned caution by low profit margins. There's clearly a long-term political motivation present. the economics are totally dissimilar to commodity PC's. All video game consoles are sold under cost today. PCs generally are not. This is a misleading analogy. I notice that the technology is primarily rolled out in high-margin areas first like notbooks (and in game consoles where considerable front investments need to be protected). In any case, DRM does not limit what programs people can run, at least not to a greater degree than does any program which encrypts its data. This is a gross misrepresentation. Content (whether executable code or media, it doesn't really matter as the difference is blurring) can be keyed to individual machines. This kills copying. There's an intense battle going on between open science proponents and the likes of Elsevier. Distribution range of documents can be limited. Access to documents can be limited to specific time window. Secrets inserted at manufacture time ask for legislation demanding subpoenable records. Hardware can be made which prefers a specific vendor by selective disclosure of information. Capability for strong authentication asks for legislation making it nonfacultative, basically outlawing anonymity. Etc. etc. There are many way by which this envelope of technologies here informally called Pd will limit dissemination of information and increase control on side of governments and large companies. Above off-the-cuff list indicates it's a giant, yet untapped can of worms. Unlike subsidized smartcard readers to initial fax effect the user can only lose. Right. It's all completely voluntary. There will be no attempts whatsoever to lock-in, despite decades of attempts and considerable economic interests involved. Yes, it is completely voluntary, and we should all remain vigilant to make sure it stays that way. And no doubt there will be efforts to lock-in customers, just as there have been in the past. There is no contradiction between these two points. This is an intensely political technology, and as such ignoring the political component by just focusing on fair and useful side of it will result in a very skewed estimate of its future impacts. It doesn't pay to be naive. Under the circumstances, it is much better to just block it. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Face-Recognition Technology Improves
On Sat, 15 Mar 2003, Bill Stewart wrote: They're probably not independent, but they'll be influenced by lighting, precise viewing angles, etc., so they're probably nowhere near 100% correlated either. I notice the systems mentioned in the study rely on biometrics extracted from flat images. Recent crop of systems actually scan the face geometry by using patterned light (apparently, cheaper than using a laser scanner), resulting in a much richer and standartized (lighting and facial orientation is irrelevant) biometric fingerprint. There's a world of difference between a line of people each slowly stepping through the gate past a sensor in roughly aligned orientation and a fixed-orientation no-zoom low-resolution camera looking at a group of freely behaving subjects at varying illumination. Even with basically single-source nonintegrative biometrics one could do a lot with hi-res camera with zoom actively tracking a single person at a time, using a NIR (skin is far more transparent to IR, resulting in a far richer pigmentation pattern fingerprint to be acquired) for illumination. Then there's gait, a physical body model, etc. Shortwave SAR (SAR for THz wavelenths seems to be doable according to recent publications), so reading body geometry would appear possible. Volatile MHC fragment chemosensors are being developed, a hi-tech variant of Stasi's approach with odor samples and canines. (Calibrated sensors, no need for sensor to be exponsed to the scent before, bit vectors never grow stale). By using multichannel, integrative approaches and more sophisticated DSP the error rate can be eventually brought down arbitrarily low, and simultaneously become increasingly hard to falsify. The costs will come down eventually for such integrative telebiometrics systems realtime connected via wireless to be blanket deployable. Unlike a mobile telephone, you can't switch your body off, or leave it at home. It will be interesting to see what will happen politically once the majority of voters will realize they're living in a strictly unilateral version of Brinworld. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Face-Recognition Technology Improves
On Sun, 16 Mar 2003, Bill Stewart wrote: You're right that airport security gates are probably a pretty good consistent place to view the crowd, but getting the target images is a different problem - some of the Usual Suspects may have police mugshots, but for most of them it's unlikely that you've gotten them to sit down while you take a whole-face geometry scan to get the fingerprint. I think the security-crazed data gatherers would just want to scan biometrics of every single person passing through the metal detector gates, check them against the list of usual suspects, and insert them in realtime into a central database. Where they will remain, for indefinite time, free for any authorized party to do data mining on. Unless explict laws have been passed preventing this very eventuality, and the systems are actually audited that no data is retained beyond what is necessary for processing. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Brumley Boneh timing attack on OpenSSL (fwd)
Some clarification by Peter Gutmann [EMAIL PROTECTED] on why cryptlib doesn't do timing attack resistance default: Peter Gutmann [EMAIL PROTECTED]: cryptlib was never intended to be a high-performance SSL server (the docs are fairly clear on this), and I don't think anyone is using it to replace Apache or IIS. OTOH it is used in a number of specialised environments such as closed environments, embedded systems and mainframes. For example two real-world uses of the cryptlib SSL server are in embedded environment A and mainframe environment B. In A, the processing is handled by a low-power embedded processor. It takes 10-15s to perform an SSL handshake, and that's after the code has been optimised to death to squeeze every possible bit of performance out of it. Performing the necessary 1.5M queries at 15s each would take approximately 8 1/2 months at 100% CPU load (meaning that the device is unable to perform any other operations in that entire time). This is unlikely to go unnoticed, given that it's polled from other devices for status updates. In B, CPU resources are so scarce that the implementation uses null cipher suites because it can't afford the overhead of even RC4 for encryption (admittedly this required a custom code hack, cryptlib doesn't normally support null encryption suites). After about 100 or so attempts at a full SSL handshake, klaxons would sound and blue-suited troops would deploy onto the raised flooring to determine where all the CPU time is going. In neither of these environments (and various similar ones) would a side- channel attack requiring 1M or so queries (e.g. this one, or the Bleichenbacher attack, or the Klima-Pokorny-Rosa attack, which cryptlib shouldn't be vulnerable to since I'm paranoid about error reporting) be terribly feasible. OTOH blinding does produce a noticeable slowdown for a process that's already regarded by its users as unacceptably slow and/or CPU-intensive (I have some users who've hacked the key-exchange process to use fixed shared keys because they just can't spare the CPU time to do a real handshake, e.g. by injecting the shared key into the SSL session cache so you just do a pseudo-resume for each new connection). For this reason, cryptlib makes the use of sidechannel- attack-protection an optional item, which must be selected by the user (via use of the blinding code, now admittedly I should probably make this a bit easier to do in future releases than having to hack the source :-). This is not to downplay the seriousness of the attack, merely to say that in some cases the slowdown/CPU consumption vs.attack risk doesn't make it worthwhile to defend against. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Russia Intercepts US Military Communications?
On Sun, 30 Mar 2003, reusch wrote: I'm amazed at their claims of radio interception. One would expect that all US military communications, even trivial ones, Trivial ones are voice radio. Nontrivially to encrypt (mil people tend to be conservative), unlike teletype (I've used NEMP-proof perforated tape, teletypes and electromechanical rotor crypto keyed by a wire plug box in 1988's Bundeswehr). are strongly encrypted, given the ease of doing this. Someone, more well informed, please reassure me that this is the case. While there's no doubt comm is being intercepted the www.aeronautics.ru main analyst (forgot his name) is purported to be not very credible. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
