Re: [Forwarded] RealID: How to become an unperson.
Don't laugh. This is exactly the problem I had with my german identity card. In Germany, you are required to possess either an identity card or a passport once you reach the age of 16. If you're younger you can just have a children's passport in case you need for travelling. Usually applying for an ID card is not a problem at all. For reasons far beyond cryptography my father chose an unusual given name for me, one that was usual in around the 8th-10th century. He named me Hadmut. Most people in Germany have never heard that name before and don't believe, that this name exists. There is another name, Hartmut, which is ethymologically different, but sounds similar. Therefore, most people assume that my name is just misspelled and would correctly be Hartmut. When we moved to a different town some years ago, someone made a mistake in the municipal register, and entered 'Hartmut' instead of 'Hadmut', obviously because he or she believed it was misspelled. When I applied for an ID card after my 16th birthday, they told me that they can't issue one, because my children's passport said my given name is 'Hadmut', while the register said that I am 'Hartmut'. Whoever I decided to be, I would not receive an ID card before I could prove which of both I am. They asked me to bring a certified copy of my birth certificate. For reasons even more beyond cryptography, that copy was lost years ago. So I had to go to the registry office where I was born to get another copy. Fortunately, this was just 20 minutes by bicycle away. For privacy reasons, you can't just go to a registry office and ask for anyone's birth certificate. You have to proof your identity - with your ID card. Exactly that circular problem as mentioned in the posting. But when I explained that circular problem, they checked by phone with the town's registry office and gave me the copy of the birth certificate without an ID card to solve the problem. But nevertheless, I do not understand why americans are so afraid of an ID card. It has by far more advantages than disadvantages, and actually the US driving license is already a kind of ID card. And whenever I enter the US, I have to give the fingerprints of my index fingers and they take a picture of me. That's worse than an ID card. Remember the PGP signing party at the 1994 IETF meeting in San Jose? Several participants who had never seen me before did sign my PGP key after I showed them my german ID card (including Perry). Funny side effect: Since most americans don't know that we have ID cards in germany the card is almost always believed to be a driving license in the US. regards Hadmut (currently in Boston, MA, after giving fingerprints at the airport immigration) - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
[OT] The Nazification Of America, Part 2 (Day 5) (fwd)
I was unaware that (a) this had hit Farber, or that (b) it had been cross posted to cryptography, prior to my second posting - which is attached below (for the sake of completeness). //Alif -- Yours, J.A. Terranson [EMAIL PROTECTED] 0xBD4A95BF -- Forwarded message -- Date: Tue, 5 Jul 2005 19:01:21 -0500 (CDT) From: J.A. Terranson <[EMAIL PROTECTED]> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: The Nazification Of America, Part 2 (Day 5) When last I wrote, I was facing a dilemma: how to get a copy of my brith certificate so that I could get a copy of my birth certificate :-/ I managed to "clear the hurdle" of the missing brith certificate. Kinda. Sorta maybe... So, new certificate in hand, I went off to the DMV to get my picture taken (wearing my "Frisk Me, I'm A Terrorist" T-Shirt of course). At 8:50am I was eagerly awaiting the opening of the local DMV office, and by the opening bell at 9:00, there was actually a *line* behind me! I rushed to the counter, plopped down my proof of insurance, proof of address (a recent mailed in voter reg card), my old Illinois drivers license, social security card, and held my breath. They took them, and handed me back a form to check that everything was correct prior to snapping the pic. Oddly, it wasn't: the date of birth was wrong, and it took them about 15 minutes to fix it (apparently the computers are programmed to avoid the changing of a DOB, and they were dumbfounded at how to proceed). Finally, the moment arrived, and I was the proud owner of not just a new Missouri driver's license (with clearly shoing T-Shirt on the photo), but a Missouri state ID as well. Then it was my wife's turn. Unfortunately, she was turned away: even though she had everything I did, she forgot to bring a certified copy of our marriage license! Without it, they refused to use her married name for the license... I trudged over to the city for a copy of said marriage license, and lo, of course, there was aline out the door - women of every age and description suddenly finding it necessary to get a certified copy of their marriage license! What a shocker - the Collector of Revenue is having a field day with this. She will try again tomorrow, and I certain that this time it will all "work out", but still, I am left with disturbing questions. For instance, when we went to get *her* birth certificate, why did they not give a damn *who* was asking for it? Why is everyone on earth getting to charge an extra $12.00 here and $12.00 there to allow us the privelege of complying with this absurd law (which, BTW, even the fucking British refuse to pass)? This country is out of control, bouncing endlessly between administrative fiat and endless taxation, and all we can worry about is that some ephemeral "Terrorist" is going to blow up a bus? To be honest, I'm *far* more worried that George will blow up another country that I am about some guy stealing my ID and using it to defeat democracy in Quebec -- Yours, J.A. Terranson [EMAIL PROTECTED] 0xBD4A95BF "Never belong to any party, always oppose privileged classes and public plunderers, never lack sympathy with the poor, always remain devoted to the public welfare, never be satisfied with merely printing news, always be drastically independent, never be afraid to attack wrong, whether by predatory plutocracy or predatory poverty." Joseph Pulitzer 1907 Speech - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
[ANNOUNCE] OpenSSL 0.9.8 released
OpenSSL version 0.9.8 released == OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 0.9.8 of our open source toolkit for SSL/TLS. This new OpenSSL version is a major release and incorporates many new features as well as major fixes compared to 0.9.7x. For a complete list of changes, please see http://www.openssl.org/source/exp/CHANGES . The most significant changes are: o Major work on the BIGNUM library for higher efficiency and to make operations more streamlined and less contradictory. This is the result of a major audit of the BIGNUM library. o Addition of BIGNUM functions for fields GF(2^m) and NIST curves, to support the Elliptic Crypto functions. o Major work on Elliptic Crypto; ECDH and ECDSA added, including the use through EVP, X509 and ENGINE. o New ASN.1 mini-compiler that's usable through the OpenSSL configuration file. o Added support for ASN.1 indefinite length constructed encoding. o New PKCS#12 'medium level' API to manipulate PKCS#12 files. o Complete rework of shared library construction and linking programs with shared or static libraries, through a separate Makefile.shared. o Rework of the passing of parameters from one Makefile to another. o Changed ENGINE framework to load dynamic engine modules automatically from specifically given directories. o New structure and ASN.1 functions for CertificatePair. o Changed the ZLIB compression method to be stateful. o Changed the key-generation and primality testing "progress" mechanism to take a structure that contains the ticker function and an argument. o New engine module: GMP (performs private key exponentiation). o New engine module: VIA PadLOck ACE extension in VIA C3 Nehemiah processors. o Added support for IPv6 addresses in certificate extensions. See RFC 1884, section 2.2. o Added support for certificate policy mappings, policy constraints and name constraints. o Added support for multi-valued AVAs in the OpenSSL configuration file. o Added support for multiple certificates with the same subject in the 'openssl ca' index file. o Make it possible to create self-signed certificates using 'openssl ca -selfsign'. o Make it possible to generate a serial number file with 'openssl ca -create_serial'. o New binary search functions with extended functionality. o New BUF functions. o New STORE structure and library to provide an interface to all sorts of data repositories. Supports storage of public and private keys, certificates, CRLs, numbers and arbitrary blobs. This library is unfortunately unfinished and unused withing OpenSSL. o New control functions for the error stack. o Changed the PKCS#7 library to support one-pass S/MIME processing. o Added the possibility to compile without old deprecated functionality with the OPENSSL_NO_DEPRECATED macro or the 'no-deprecated' argument to the config and Configure scripts. o Constification of all ASN.1 conversion functions, and other affected functions. o Improved platform support for PowerPC. o New FIPS 180-2 algorithms (SHA-224, -256, -384 and -512). o New X509_VERIFY_PARAM structure to support parametrisation of X.509 path validation. o Major overhaul of RC4 performance on Intel P4, IA-64 and AMD64. o Changed the Configure script to have some algorithms disabled by default. Those can be explicitely enabled with the new argument form 'enable-xxx'. o Change the default digest in 'openssl' commands from MD5 to SHA-1. o Added support for DTLS. o New BIGNUM blinding. o Added support for the RSA-PSS encryption scheme o Added support for the RSA X.931 padding. o Added support for BSD sockets on NetWare. o Added support for files larger than 2GB. o Added initial support for Win64. o Added alternate pkg-config files. We consider OpenSSL 0.9.8 to be the best version of OpenSSL available and we strongly recommend that users of older versions upgrade as soon as possible. OpenSSL 0.9.8 is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): o http://www.openssl.org/source/ o ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-0.9.8.tar.gz MD5 checksum: 9da21071596a124acde6080552deac16 SHA1 checksum: 7350b0f0d1a6d257cb24b9d4dc5e30b80e49d6ac The checksums were calculated using the following command: openssl md5 < openssl-0.9.8.tar.gz openssl sha1 < openssl-0.9.8.tar.gz Yours, The OpenSSL Project Team... Mark J. Cox
Time-Memory-Key tradeoff attacks?
The following has appeared in the IACR preprint archive. I would
appreciate comments. The author certainly has reasonable credentials,
but the document is low on detail:
http://eprint.iacr.org/2005/207
Some Thoughts on Time-Memory-Data Tradeoffs
Author: Alex Biryukov
Abstract: In this paper we show that Time-Memory tradeoff by Hellman
may be extended to Time-Memory-Key tradeoff thus allowing attacks much
faster than exhaustive search for ciphers for which typically it is
stated that no such attack exists. For example, as a result AES with
128-bit key has only 85-bit security if $2^{43}$ encryptions of an
arbitrary fixed text under different keys are available to the
attacker. Such attacks are generic and are more practical than some
recent high complexity chosen related-key attacks on round-reduced
versions of AES. They constitute a practical threat for any cipher
with 80-bit or shorter keys and are marginally practical for 128-bit
key ciphers. We also show that UNIX password scheme even with
carefully generated passwords is vulnerable to practical tradeoff
attacks. Finally we also demonstrate a combination of rainbow tables
with the time-memory-data tradeoff which results in a new tradeoff
curve.
By the way, much thanks to Eric Rescorla for pointing this out to me.
Perry
--
Perry E. Metzger[EMAIL PROTECTED]
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Feature or Flaw?
Florian Weimer wrote: * Lance James: And as stated above, reverse the effect and it would be the banks in scenarios such as XSS. In case of XSS or CSRF, you have lost anyway. The web was not designed as a presentation service for transaction processing, especially if the transactions involve significant value. If you use the web for this purpose, it's always a tradeoff. Maybe it's time to realize that all these web applications together form a huge monoculture, and to move on and diversify again. Thank you - that was my point essentially. SSL is and always will be for web a broken concept. -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://www.securescience.net/amazon/ Find out how malware is affecting your company: Get a DIA account today! https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Feature or Flaw?
* Lance James: > And as stated above, reverse the effect and it would be the banks in > scenarios such as XSS. In case of XSS or CSRF, you have lost anyway. The web was not designed as a presentation service for transaction processing, especially if the transactions involve significant value. If you use the web for this purpose, it's always a tradeoff. Maybe it's time to realize that all these web applications together form a huge monoculture, and to move on and diversify again. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Feature or Flaw?
> This site is set so that there is a frame of https://www.bankone.com > inside my https://slam.securescience.com/threats/mixed.html site. The > imaginative part is that you may have to reverse the rolls to understand > the impact of this (https://www.bankone.com with > https://slam.securescience.com frame -> done via cross-user attacks > trivially). Let me get this right: here we have a page which appears to be from domain A, but in fact it has frame(s) which display domain B. This allows a page to have the content from domain B but the outward appearance is of domain A, including the SSL lock on the page which indicates "this page is safe" to the user. It looks like this allows one to spoof domain A quite successfully, unless I'm missing something. Jeremiah - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
[Forwarded] RealID: How to become an unperson.
I'm forwarding this article, originally from the Cypherpunks mailing
list (I saw it on Dave Farber's "Interesting People") because I find
the security implications important.
HOWEVER, I'm warning in advance that I'm not going to forward a lot of
followups, especially if they are unoriginal and/or contain lots of
ranting language and little content. (I'm mildly uncomfortable with
the original, actually, because I prefer light to heat, but it makes a
very interesting point...)
From: [apparently] J.A. Terranson
Sent: Friday, July 01, 2005 6:34 PM
Cc: [EMAIL PROTECTED]
Subject: The Nazification Of America ("Show Me Your Papers" - Day 1)
For those of you who may have missed it, today was the first day of the
new "Real ID Act", a/k/a, the American Nazification Papers Act. I
wouldn't have know myself except that I recently moved, and wanted to
exchange my current Illinois drivers license for a Missouri one.
Not so fast...
"You have a passport?"
"No, I don't travel."
"A certified copy of your original birth certificate?"
"Haven't had one since I was born, fifty years ago. And since I was
born about 1500 miles from here, getting one is no small task."
"Too bad. Your old license is invalid and you can't get another one in
any state, starting today, without at least one of the two documents,
PLUS secondary ID to back them up."
Even though I have a current license, and even though I am in their
system as having held a valid Missouri license for 15+ years, photo
included, none of it is good enough.
OK, so I have no choice, I go to the post office to get a Passport -
same thing.
Fine, I'll just order the birth certificate and get it over with, right?
Wrong. New York wants affirmative proof of identity for a copy now:
passport or your [missing] original birth certificate. Anyone else
see a circular problem here?
"I need a new birth certificate because the old one was lost about forty
years ago. And I don't have a passport to prove my identity."
"Get your parents to testify who you are, and make sure they bring their
passports."
"They are both dead."
"Sorry Sir, I'm afraid we won't be able to help you then."
Durbin was right. And he didn't even scratch the surface! Anyone who
thinks this "Real ID Act" is about getting false ID out of the hands
of "The Terrorists" is an idiot: they will simply print their own
drivers licenses - this is about forcing the regular population to get
used to intrastate passports. This act essentially forces you to have
a passport for everyday things like banking, car purchases and certain
repairs, checks, etc.
We have literally allowed the Nazification to begin, and we've even
welcomed it with eager open arms - all in the name of "Fighting Terror".
Crystal clear, pure unadulterated bullshit.
--
Yours,
J.A. Terranson
[EMAIL PROTECTED]
0xBD4A95BF
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Feature or Flaw?
Amir Herzberg wrote: Lance James wrote: ... > https://slam.securescience.com/threats/mixed.html This site is set so that there is a frame of https://www.bankone.com inside my https://slam.securescience.com/threats/mixed.html site. The imaginative part is that you may have to reverse the rolls to understand the impact of this (https://www.bankone.com with https://slam.securescience.com frame -> done via cross-user attacks Ok, I can do the `mental exercise` and understand the attack. But I'm not sure what is new here. Yes, if a web-site allows such XSS, then even SSL won't help it - it could end up sending the _wrong_ page, protected by SSL... And in this case I don't even think we can blame browser UI; the browser actually got this `bad` page from the server... It's not the "new" issue - it's the concern that frames with other SSL protect information is not being indicated to the user, thus you can encrypt data with another valid cert within a frame(s) and the user will only know of the main cert from the domain that is indicated by the address bar. Maybe I miss something? BTW, there is a new list focsed on such issues, at http://lists.cacert.org/cgi-bin/mailman/listinfo/anti-fraud -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://www.securescience.net/amazon/ Find out how malware is affecting your company: Get a DIA account today! https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Feature or Flaw?
Florian Weimer wrote: * Lance James: Couldn't you just copy (or proxy all content) and get the same effect without using frames at all? How would you go about doing that and still get the SSL Lock to remain as the banks? Can you give an example? In both cases, you have the SSL lock on your own certificate. And as stated above, reverse the effect and it would be the banks in scenarios such as XSS. The Banks SSL cert is actually handling all the data, my concern is that the user is not aware of this and only trusts the domain that's indicated in the address bar's cert. At least my browser does not provide a user interface to access the certificates of the servers from which embedded objects (or frames) were downloaded. -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://www.securescience.net/amazon/ Find out how malware is affecting your company: Get a DIA account today! https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Feature or Flaw?
* Lance James: >>Couldn't you just copy (or proxy all content) and get the same effect >>without using frames at all? > How would you go about doing that and still get the SSL Lock to remain > as the banks? Can you give an example? In both cases, you have the SSL lock on your own certificate. At least my browser does not provide a user interface to access the certificates of the servers from which embedded objects (or frames) were downloaded. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Feature or Flaw?
Florian Weimer wrote: * Lance James: Feature, or flaw? Couldn't you just copy (or proxy all content) and get the same effect without using frames at all? How would you go about doing that and still get the SSL Lock to remain as the banks? Can you give an example? Maybe I'm just missing something. -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://www.securescience.net/amazon/ Find out how malware is affecting your company: Get a DIA account today! https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Feature or Flaw?
Amir Herzberg wrote: Lance James wrote: ... > https://slam.securescience.com/threats/mixed.html This site is set so that there is a frame of https://www.bankone.com inside my https://slam.securescience.com/threats/mixed.html site. The imaginative part is that you may have to reverse the rolls to understand the impact of this (https://www.bankone.com with https://slam.securescience.com frame -> done via cross-user attacks Ok, I can do the `mental exercise` and understand the attack. But I'm not sure what is new here. Yes, if a web-site allows such XSS, then even SSL won't help it - it could end up sending the _wrong_ page, protected by SSL... And in this case I don't even think we can blame browser UI; the browser actually got this `bad` page from the server... Maybe I miss something? Ok, XSS or not, my concern is that you have multiple Certificates within a session, and the user is not aware of the others. Yes, they are valid, but define valid within SSL certs means, I go to geotrust or some CA, use my stolen credit card and buy a valid cert. BTW, there is a new list focsed on such issues, at http://lists.cacert.org/cgi-bin/mailman/listinfo/anti-fraud -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://www.securescience.net/amazon/ Find out how malware is affecting your company: Get a DIA account today! https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: /dev/random is probably not
>From: "Charles M. Hannum" <[EMAIL PROTECTED]> >Sent: Jul 3, 2005 7:42 AM >To: Don Davis <[EMAIL PROTECTED]> >Cc: cryptography@metzdowd.com >Subject: Re: /dev/random is probably not ... >Also, I don't buy for a picosecond that you have to gather >"all" timings in order to predict the output. As we know >from countless other attacks, anything that gives you some >bits will reduce the search space and therefore weaken the >system, even if it does not directly give you the result. I think you're landing on the genuinely hard problem here. Designing a PRNG intelligently is an exercise in design and cryptanalysis, so long as you get to assume that you know how much entropy you're getting. But actually getting reliably entropy estimates is: a. A data analysis problem, where you never really get a final answer, you just get the best model you knew how to test and don't find strong evidence to discard it, and b. Enormously sensitive to implementation details that are hard to deal with in software. In a hardware RNG design, you can at least analyze test-mode raw outputs of the ring oscillator or whatever, build a statistical model, and know that the same basic model will also describe the devices in the field. They may vary because of manufacturing defects, changes in the field (like heating/cooling or component failure), etc., but you at least know what kind of thing you've got. With software sources, there's pretty much no limit to what changes the designer of the hardware is allowed to make to your devices, so long as he keeps the interface the same. You do lots of analysis on a machine with a spinning disk drive, and end up on one with one networked drive and one flash drive, or some such horrible thing. Additionally, building a probability model for stuff you observe on a general purpose computer is *hard*, because there's so much complicated deterministic stuff going on. Even if you're using the same machine and setup to collect entropy in production as you did to build your probability model for entropy estimation, it's hard to have enormous confidence in the correctness of your estimates. How much of that apparently random behavior you were getting when you sampled the cycle counter in a tight loop was because of genuine unpredictability, and how much was because of the very patterned but complicated stuff going on behind the scenes on your machine? --John - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Feature or Flaw?
* Lance James: > Feature, or flaw? Couldn't you just copy (or proxy all content) and get the same effect without using frames at all? Maybe I'm just missing something. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Feature or Flaw?
Lance James wrote: ... > https://slam.securescience.com/threats/mixed.html This site is set so that there is a frame of https://www.bankone.com inside my https://slam.securescience.com/threats/mixed.html site. The imaginative part is that you may have to reverse the rolls to understand the impact of this (https://www.bankone.com with https://slam.securescience.com frame -> done via cross-user attacks Ok, I can do the `mental exercise` and understand the attack. But I'm not sure what is new here. Yes, if a web-site allows such XSS, then even SSL won't help it - it could end up sending the _wrong_ page, protected by SSL... And in this case I don't even think we can blame browser UI; the browser actually got this `bad` page from the server... Maybe I miss something? BTW, there is a new list focsed on such issues, at http://lists.cacert.org/cgi-bin/mailman/listinfo/anti-fraud -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: /dev/random is probably not
On 07/03/05 15:19, Dan Kaminsky wrote: > So the funny thing about, say, SHA-1, is if you give it less than 160 > bits of data, you end up expanding into 160 bits of data, but if you > give it more than 160 bits of data, you end up contracting into 160 bits > of data. This works of course for any input data, entropic or not. > Hash saturation? I don't know what it means to talk about "data, entropic or not". That's because for the purpose of analyzing randomness genreators, nobody cares whether the input has a large amount of "data"; what matters is _entropy_. If you feed the hash function less than 160 bits of entropy, it will not "end up expanding" it to 160 bits of entropy. No function can expand the amount of entropy. For a hash function with output width W=160 bits, if the input has 5 bits of entropy the output will have very nearly 5 bits of entropy. The input/output relationship is very nearly linear, with unit slope, until we get close to saturation. > Hash saturation? Is not every modern hash saturated with as much > entropy it can assume came from the input data (i.e. all input bits have > a 50% likelihood of changing all output bits)? That's not what "saturation" means. I introduced and defined the term "hash saturation", so I ought to know. Saturation is what happens when the input entropy is large, such that the output entropy smashes up against the horizontal asymptote. This is discussed in detail at http://www.av8n.com/turbid/paper/turbid.htm#sec-saturation along with a tabulated numerical example. > Incidentally, that's a more than mild assumptoin that it's pure noise > coming off the sound card. I have no idea what is meant by "pure noise", but I'm pretty sure I didn't assume any such thing. > It's not, necessarily, not even at the high > frequencies. Consider for a moment the Sound Blaster Live's E10K chip, I recommend against using any Creative Labs (aka SoundBlaster) products for any serious or even halfway-serious purpose. Far too many of their products have deceptive specifications, and/or don't meet specifications at all. > internally hard-clocked to 48khz. This chip uses a fairly simple > algorithm to upsample or downsample all audio streams to 48,000 samples > per second. It's well known that scaling algorithms exhibit noticable > properties -- this fact has been used to detect photoshopped works, for > instance. Take a look how noise centered around 15khz gets represented > in a 48khz averaged domain. Would your system detect this fault? I'm not sure exactly what fault is being described, and I don't know what "simple algorithm" is alluded to. However, my guess is that the "simple algorithm" is linear, and that the gain contour is a fairly smooth function of frequency, with no strong singularities at 15kHz. And since my method calls for _measuring_ the gain as part of the calibration process, this so-called "fault" should not AFAICT be classified as a fault; most likely it is just one of the many factors that affect the calibration constants. > Of course not. Proof by bold assertion. Unsubstantiated opinion. > No extant system can yet detect the difference between a > quantum entropy generator and an AES or 3DES stream. First of all, there is nothing special about "quantum" entropy that makes it better than other types of entropy (e.g. thermal entropy), in any practical sense. This point is discussed in detail at http://www.av8n.com/turbid/paper/turbid.htm#sec-hesg-attack Secondly, it simply is not correct to say that their is no difference between a genuinely entropic randomness generator and a pseudo-randomness generator. Proof by construction: a) On a system that relies on /dev/urandom in the absence of sources of real entropy, capture a backup tape containing the /var/lib/.../random-seed file. Then provoke a crash and restart, perhaps by interrupting the power. Then you know the output of /dev/urandom for all time thereafter. To repeat: One difference between a genuinely entropic randomness generator and a pseudo-randomness generator is whether I have to be paranoid about crash/restart scenarios, and whether I have to be paranoid about protecting my backup tapes. b) A related point: Suppose we are running a high-stakes lottery. Who provided the _original_ seed for the randomness generator we will use? Even assuming (!) we can protect the seed for all times greater than t=0, where did the t=0 seed come from? If you provided it, how do I know you didn't keep a copy? This is important, because the historical record shows that randomness generators are not necessarily broken by attacking their cryptologic primitives, by direct cryptanalysis of the PRNG output; more commonly they are broken by attacking the seed-generation and seed-storage. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
ECRYPT Workshop on RFID and Light-Weight Crypto
** CALL FOR PARTICIPATION ** ECRYPT Workshop on RFID and Light-Weight Crypto July 14-15, 2005 IAIK, Graz University of Technology , Austria Organizers: Vincent Rijmen, Graz University of Technology Elisabeth Oswald, Graz University of Technology The use of state-of-the-art cryptographic methods on RFID tags opens a new range of applications for these tags and for cryptography. The aims of the workshop are to increase the awareness for cryptographic methods and solutions among RFID developers, and for the requirements of this heavily constrained environment among cryptographers. The scope includes, but is not limited to, the following topics: * Applications for RFID tags * Cryptographic algorithms for constrained environments * Cryptographic protocols adapted to RFID applications * Low-power implementations There are contributed and invite talks. Gildas Avoine, Dieter Gollmann, Ari Juels and Johannes Wolkerstorfer are confirmed as invited speakers. For more information about the workshop program, location and the registration procedure, please look at: http://www.iaik.tugraz.at/research/krypto/events/index.php The workshop is sponsored by ECRYPT - The European Network of Excellence in Cryptology, Siemens and Philips. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Feature or Flaw?
Hi all, I wanted to introduce something that has probably been known for some time now, but has never been really addressed due to possible conflicting views of how SSL certificates should work, and where the CA's should (or should not) fit in. As we all know, the recent attention to the phishing threat vector has spawned some interesting views of how we look at certain responses that a web browser might appropriate in regards to certain conditions set by the server. Some of these include the recent "javascript dialog" box vulnerability, since there are requests that a javascript dialog box should display it's origin, etc... (see http://secunia.com/multiple_browsers_dialog_origin_vulnerability_test). In light of that, I thought it might be relevant to address a question that's been on my mind, and figure that the cryptography list may be the best place to find the answer. (the answer is 42, just kidding). I've set up a site that requires a bit of imagination since I don't wish to expose any financial institutions (bankone is just a random example that I chose) that may be vulnerable to cross-user attacks, but I can tell you that this discovery of impact was done within an audit that explicitly demonstrated a problem. Also, I use a thawte signed certificate, so some mozilla browsers do not seem to regard it as a valid CA, please ignore that if you get a warning, as it is only a distraction of the real problem (aka, if it were a verisign cert it would not warn). https://slam.securescience.com/threats/mixed.html This site is set so that there is a frame of https://www.bankone.com inside my https://slam.securescience.com/threats/mixed.html site. The imaginative part is that you may have to reverse the rolls to understand the impact of this (https://www.bankone.com with https://slam.securescience.com frame -> done via cross-user attacks trivially). At the bottom you will see the securescience.com certificate, but no indication of the bankone certificate. You will also not get any warnings due to the fact that the bankone certificate is validly signed by a CA. With the Cross-User threat vector, a phisher can easily use a validly signed Cert to perform a site takeover with no warning that an outside (the domain) certificate exists within the site. The lock does show that it's secure, and there are no indications that this site should not be "trusted" according to the rules that are dispersed to the mainstream public. Unfortunately, this "Mixed" attack in a cross-user scenario could be encrypting/decrypting the login page with the attacker cert and no one is the wiser without heavy inspection of the source code. Feature, or flaw? -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://www.securescience.net/amazon/ Find out how malware is affecting your company: Get a DIA account today! https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: /dev/random is probably not
So the funny thing about, say, SHA-1, is if you give it less than 160 bits of data, you end up expanding into 160 bits of data, but if you give it more than 160 bits of data, you end up contracting into 160 bits of data. This works of course for any input data, entropic or not. Hash saturation? Is not every modern hash saturated with as much entropy it can assume came from the input data (i.e. all input bits have a 50% likelihood of changing all output bits)? Incidentally, that's a more than mild assumptoin that it's pure noise coming off the sound card. It's not, necessarily, not even at the high frequencies. Consider for a moment the Sound Blaster Live's E10K chip, internally hard-clocked to 48khz. This chip uses a fairly simple algorithm to upsample or downsample all audio streams to 48,000 samples per second. It's well known that scaling algorithms exhibit noticable properties -- this fact has been used to detect photoshopped works, for instance. Take a look how noise centered around 15khz gets represented in a 48khz averaged domain. Would your system detect this fault? Of course not. No extant system can yet detect the difference between a quantum entropy generator and an AES or 3DES stream. (RC4's another story.) You can't externally calculate entropy levels; you can only assume. --Dan John Denker wrote: > On 07/01/05 13:08, Charles M. Hannum wrote: > >> Most implementations of /dev/random (or so-called "entropy gathering >> daemons") rely on disk I/O timings as a primary source of randomness. > > >> ... I believe it is readily apparent that such exploits could be >> written. > > > So don't do it that way. > > Vastly better methods are available: > http://www.av8n.com/turbid/ > > ABSTRACT: We discuss the principles of a High-Entropy Symbol Generator > (also called a Random Number Generator) that is suitable for a wide > range of applications, including cryptography and other high-stakes > adversarial applications. It harvests entropy from physical processes, > and uses that entropy efficiently. The hash saturation principle is used > to distill the data, resulting in virtually 100% entropy density. This > is calculated, *not* statistically estimated, and is provably correct > under mild assumptions. In contrast to a Pseudo-Random Number Generator, > it has no internal state to worry about, and does not depend on > unprovable assumptions about ``one-way functions''. We also describe a > low-cost high-performance implementation, using the computer's audio I/O > system. > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to > [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: /dev/random is probably not
On Sunday 03 July 2005 05:21, Don Davis wrote: > > From: "Charles M. Hannum" <[EMAIL PROTECTED]> > > Date: Fri, 1 Jul 2005 17:08:50 + > > > > While I have found no fault with the original analysis, > > ...I have found three major problems with the way it > > is implemented in current systems. > > hi, mr. hannum - > > i'm sorry, but none of your three "problems" is substantial. > > > a) Most modern IDE drives... ship with write-behind > >caching enabled. > > i've addressed this caching question quite a bit > over the years. for an early mention of the issue, > please see: > http://www.cs.berkeley.edu/~daw/rnd/disk-randomness > anyway, to deal with caching controllers, any disk rng > needs to discard sub-millisecond access-times, or at > least needs not to count such fast accesses as contributing > any entropy to the RNG's entropy-pool. otherwise, the > rng will tend to overestimate how much entropy is in > the entropy pool, and dev/random will tend to become > no more secure than /dev/urandom. Remember that I specifically stated that I'm talking about problems with real-world implementations, not your original analysis. Unfortunately, a few implementations (FreeBSD's implementation of "Yarrow" and NetBSD's "rnd" come to mind immediately) do not appear to implement the behavior you describe -- they simply always count disk I/O as contributing some entropy (using the minimum of the first-, second- and third-order differentials, which is likely to be non-0, but small and predictable, due to other timing variance). > > b) At least one implementation uses *all* "disk" type > >devices... > > yes, that would be broken., though it's not a total > security loss, as long as the machine has at least one > hard drive. this memory-disk question too was raised > and answered, long ago. Again, this problem exists in real-world implementations. > > By timing how long this higher-level operation (read(), > > or possibly even a remote request via HTTP, SMTP, etc.) > > takes, we can apply an adjustment factor and determine > > with a reasonable probability how long the actual disk > > I/O took. > > this remote-timing approach won't work in any useful way. > > you'd need to get the same timing accuracy as the > /dev/random driver gets; No, you just need to be able to estimate it with a high probability. I don't see any reason this is not possible, given that response times are directly proportional to the interrupt timing. This may be especially bad in implementations such as OpenBSD and NetBSD which limit the precision of the time samples to 1 microsecond. Also, I don't buy for a picosecond that you have to gather "all" timings in order to predict the output. As we know from countless other attacks, anything that gives you some bits will reduce the search space and therefore weaken the system, even if it does not directly give you the result. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Menezes on HQMV
Eric Rescorla wrote: There's an interesting paper up on eprint now: http://eprint.iacr.org/2005/205 Another look at HMQV Alfred Menezes ... In this paper we demonstrate that HMQV is insecure by presenting realistic attacks in the Canetti-Krawczyk model that recover a victim's static private key. We propose HMQV-1, a patched version of HMQV that resists our attacks (but does not have any performance advantages over MQV). We also identify the fallacies in the security proof for HMQV, critique the security model, and raise some questions about the assurances that proofs in this model can provide. Obviously, this is of inherent interest, but it also plays a part in the ongoing debate about the importance of proof as a technique for evaluating cryptographic protocols. From which it is easy to draw two contrdicting conclusions... 1. Proofs are useless, see how (even) Hugo got a flaw 2. Proofs are very useful, see how the presentation of a supposed-proof led to improved analysis and realization that more work needs be done. I vote for #2. Amir - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: /dev/random is probably not
* Jason Holt: > You may be correct, but readers should also know that, at least in Linux: > > /usr/src/linux/drivers/char/random.c: > * All of these routines try to estimate how many bits of randomness a > * particular randomness source. They do this by keeping track of the > * first and second order deltas of the event timings. I somewhat doubt that moving the mouse around slowly resulting in about 800 entropy bits per second is an accurate estimate. But I have to admit that I haven't run statistical tests on the unmixed data, which would be necessary to back up my claim that this figure is grossly exaggerated. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: RSA gets a reprieve?
* Michael Heyman: > > > ATTEMPTS to build quantum computers could run up > against a fundamental limit on how long useful > information can persist inside them. My local source of quantum computing knowledge says that the conclusions of the paper are somewhat questionable. The authors examine a specific kind of measurement model; it's not immediately obvious if their results apply to all measurements, as they claim. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
