Re: [Cryptography] /dev/random is not robust
On Tue, Oct 15, 2013 at 12:35:13AM -, d...@deadhat.com wrote: http://eprint.iacr.org/2013/338.pdf *LINUX* /dev/random is not robust, so claims the paper. I wonder how various *BSDs or the Solarish family (Illumos, Oracle Solaris) hold up under similar scrutiny? Linux is big, but it is not everything. Dan ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Sha3
Because not being fast enough means you don't ship. You don't ship, you
didn't secure anything.
Performance will in fact trump security. This is the empirical reality.
There's some budget for performance loss. But we have lots and lots of
slow functions. Fast is the game.
(Now, whether my theory that we stuck with MD5 over SHA1 because variable
field lengths are harder to parse in C -- that's an open question to say
the least.)
On Tuesday, October 1, 2013, Ray Dillinger wrote:
What I don't understand here is why the process of selecting a standard
algorithm for cryptographic primitives is so highly focused on speed.
We have machines that are fast enough now that while speed isn't a non
issue, it is no longer nearly as important as the process is giving it
precedence for.
Our biggest problem now is security, not speed. I believe that it's a bit
silly to aim for a minimum acceptable security achievable within the
context of speed while experience shows that each new class of attacks is
usually first seen against some limited form of the cipher or found to be
effective only if the cipher is not carried out to a longer process.
Original message
From: John Kelsey crypto@gmail.com javascript:_e({}, 'cvml',
'crypto@gmail.com');
Date: 09/30/2013 17:24 (GMT-08:00)
To: cryptography@metzdowd.com javascript:_e({}, 'cvml',
'cryptography@metzdowd.com'); List
cryptography@metzdowd.comjavascript:_e({}, 'cvml',
'cryptography@metzdowd.com');
Subject: [Cryptography] Sha3
If you want to understand what's going on wrt SHA3, you might want to look
at the nist website, where we have all the slide presentations we have been
giving over the last six months detailing our plans. There is a lively
discussion going on at the hash forum on the topic.
This doesn't make as good a story as the new sha3 being some hell spawn
cooked up in a basement at Fort Meade, but it does have the advantage that
it has some connection to reality.
You might also want to look at what the Keccak designers said about what
the capacities should be, to us (they put their slides up) and later to
various crypto conferences.
Or not.
--John
___
The cryptography mailing list
cryptography@metzdowd.com javascript:_e({}, 'cvml',
'cryptography@metzdowd.com');
http://www.metzdowd.com/mailman/listinfo/cryptography
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
For those not familiar with TL1, supposed to be readable here means encoded in ASCII rather than binary. It's about as readable as EDIFACT and HL7. utter_tangent The (U.S.) medical records system that started at the Veterans' Administration and has now spread to all but all parts of the U.S. Federal government that handle electronic health records is ASCII encoded, and readable. Called The Blue Button,[1] there is even an HL7-Blue Button file converter.[2] Score one for human readable. /utter_tangent --dan [1] www.va.gov/BLUEBUTTON/Resources.asp [2] www.hl7.org/implement/standards/product_brief.cfm?product_id=288 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NIST about to weaken SHA3?
excerpting, we have James A. Donald wrote: Weaker in ways that the NSA has examined, and the people that chose the winning design have not. Viktor Dukhovni replies: Just because they're after you, doesn't mean they're controlling your brain with radio waves. Don't let FUD cloud your judgement. As we (here) are fond of saying, anything can be broken, therefore the question at hand is Who can break what at this strength? This question does not have a time-invariant answer, and, in any case, as Adi Shamir so adequately said, Cryptography is typically bypassed, not penetrated.[*] Nevertheless, the value of scepticism is profound; it is the chastity of the intellect. --dan [*] www.financialcryptography.com/mt/archives/000147.html ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The paranoid approach to crypto-plumbing
On Sep 17, 2013, at 7:18 PM, Jerry Leichter wrote: On Sep 17, 2013, at 6:21 PM, John Kelsey crypto@gmail.com wrote: I confess I'm not sure what the current state of research is on MAC then Encrypt vs. Encrypt then MAC -- you may want to check on that. Encrypt then MAC has a couple of big advantages centering around the idea that you don't have to worry about reaction attacks, where I send you a possibly malformed ciphertext and your response (error message, acceptance, or even time differences in when you send an error message) tells me something about your secret internal state. On a purely practical level, to reject a damaged message, with decrypt-then-MAC (ordering things on the receiver's side...) I have to pay the cost of a decryption plus a MAC computation; with MAC-then-decrypt, I only pay the cost of the MAC. On top of this, decryption is often more expensive than MAC computation. So decrypt-then-MAC makes DOS attacks easier. One could also imagine side-channel attacks triggered by chosen ciphertext. Decrypt-then-MAC allows an attacker to trigger them; MAC-then-decrypt does not. (Attacks on MAC's seems somewhat less likely to be data dependent, but who knows for sure. In any case, even if you had such an attack, it would get you the authentication key - and at that point you would be able to *start* your attack not the decryption key. People have made these attacks mildly practical (and note how old this and the cited paper are). http://kebesays.blogspot.com/2010/11/mac-then-encrypt-also-harmful-also-hard.html Dan ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Radioactive random numbers
On 9/11/2013 6:47 PM, Dave Horsfall wrote: Given that there is One True Source of randomness to wit radioactive emission, has anyone considered playing with old smoke detectors? I did that a decade ago, to wit: http://etoan.com/random-number-generation/index.html Cheers, Dan ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Bruce Schneier has gotten seriously spooked
On Sep 7, 2013, at 2:36 PM, Ray Dillinger wrote: SNIP! Schneier states of discrete logs over ECC: I no longer trust the constants. I believe the NSA has manipulated them through their relationships with industry. Is he referring to the standard set of ECC curves in use? Is it possible to select ECC curves specifically so that there's a backdoor in cryptography based on those curves? That very statement prompted me to start the Suite B thread a couple of days ago. What concerns me most about ECC is that your choices seem to be the IEEE Standard curves (which have NSA input, IIRC), or ones that will bring down the wrath of Certicom (Slogan: We're RSA Inc. for the 21st Century!). I've said this repeatedly over the past year, but if whomever ends up buying Certicom-owner Blackberry would set them free, it would help humanity (at the cost of the patent revenues, alas). Dan ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] I have to whistle to blow...
... but I must scream. http://kebesays.blogspot.com/2013/09/i-have-no-whistle-to-blow-but-i-must.html FYI, and thanks, Dan McD. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Suite B after today's news
Consider the Suite B set of algorithms: AES-GCM AES-GMAC IEEE Elliptic Curves (256, 384, and 521-bit) Traditionally, people were pretty confident in these. How are people's confidence in them now? Curious, (first-time caller) Dan McD. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] dead man switch [was: Re: Snowden fabricated digital keys to get access to NSA servers?]
for a novel treatment of a dead man switch, read _Daemon_ by Leinad Zeruas spoiler botnet that uses MainStreamMedia news feeds as a covert channel insofar as the MSM cannot help themselves but to publicize nasty events that the botnet is itself capable of causing, thus allowing the botnet to know collectively what each part of it is doing and that without a CC channel other than the repurposed MSM; the fun begins when the botnet reads the obituary of a certain person /spoiler --dan ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: Obama administration wants encryption backdoors for domestic surveillance
as usual, there's an XKCD for that http://xkcd.com/504/ --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
as previously mentioned, somewhere back behind everything else ... there is strong financial motivation in the sale of the SSL domain name digital certificates. While I am *not* arguing that point, per se, if having a better solution would require, or would have required, no more investment than the accumulated profits in the sale of SSL domain name certs, we could have solved this by now. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Haystack
Based on those statements, I'm going to speculate that the client connects to a static list of innocuous-looking proxies and that they are relying on keeping those proxies secret. Hmm, what is the chance that the static ones redirect to other proxies (some of which might even be unwitting)? Probably too out there. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Cars hacked through wireless tire sensors
| | Unlike the work earlier this year, these attacks are more of a | nuisance than any real danger; the tire sensors only send a message | every 60-90 seconds, giving attackers little opportunity to compromise | systems or cause any real damage. Nonetheless, both pieces of research | demonstrate that these in-car computers have been designed with | ineffective security measures. | Of course, in a place where surveillance infrastructure is already capitalized (think London), adding the ability to track bluetooth tire sensors would be so easy... and self-initializing at the toll stations where the license plates are read and correlation between plate number and current radio fingerprint trivially recorded. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
Wow, I was just going to recommend Dan's book, Security Metrics. It is actually Andy Jaquith's book, I only wrote the intro. In the meantime, though, couple of years ago I did a tutorial on security metrics which you may find useful http://geer.tinho.net/measuringsecurity.tutorial.pdf Best, --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
False metrics are rampant in the security industry. We really need to do something about them. I propose that we make fun of them. You might consider joining us in D.C. on 10 August at http://www.securitymetrics.org/content/Wiki.jsp?page=Metricon5.0 --dan, program committee - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
random but not by chance
http://jqi.umd.edu/news/215-random-numbers-but-not-by-chance.html Random Numbers -- But Not By Chance April 2010 Researchers have devised a new kind of random number generator, for encrypted communications and other uses, that is cryptographically secure, inherently private and - most importantly - certified random by laws of physics. article cut there as there both a diagram and a video --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
1280-Bit RSA
All, I've got a perfect vs. good question. NIST is pushing RSA-2048. And I think we all agree that's probably a good thing. However, performance on RSA-2048 is too low for a number of real world uses. Assuming RSA-2048 is unavailable, is it worth taking the intermediate step of using RSA-1280? Or should we stick to RSA-1024? --Dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: [TIME_WARP] 1280-Bit RSA
Dan, I looked at the GNFS runtime and plugged a few numbers in. It seems RSA Security is using a more conservative constant of about 1.8 rather than the suggested 1.92299... See: http://mathworld.wolfram.com/NumberFieldSieve.html So using 1.8, a 1024 bit RSA key is roughly equivalent to a 81 bit symmetric key. Plugging in 1280 yields 89 bits. I'm of the opinion that if you take action to improve security, you should get more than 8 additional bits for your efforts. For example, 1536 shouldn't be that much slower but gives 96 bits of security. Here's the actual data, in terms of transactions per second, I'm getting for a sample app: 512: 710.042382 1024: 187.187719 1280: 108.592265 1536: 73.314751 2048: 20.645645 2048 ain't happening. The relative diff between 1280 and 1536 is interesting though. For posterity, here is a table using 1.8 for the GNFS constant: RSASymmetric 256 43.7 512 59.8 768 71.6 1024 81.2 1280 89.5 1536 96.8 2048 109.4 3072 129.9 4096 146.5 8192 195.1 Do other cracking mechanisms have similar curves to GNFS (with different constants)? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
High assurance cryptographic interface specification
I have been involved for the past several years in the development of a specification Common Interface to Cryptographic Modules (CICM) that defines an application programming interface specifically for high assurance cryptographic modules. High assurance modules are typically developed by countries for their government, diplomatic and military communications. The interface differs from commercial interface standards like PKCS#11 primarily for its support for domain separation, but also for the richer module and key management capabilities required by high assurance modules. To my knowledge, CICM is the first generic high assurance API that has been developed. There has been considerable interest in the specification in the high assurance community. The specification has recently been submitted to the Internet Engineering Task Force (IETF) as an Internet Draft and is available at https://datatracker.ietf.org/drafts/draft-lanz-cicm/ . I would like to encourage interested individuals to participate in the standardization process through the IETF. If you have an interest in this effort, feel free to sign up for the IETF CICM mailing list by visiting https://www.ietf.org/mailman/listinfo/cicm . Dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Law Enforcement Appliance Subverts SSL
Rui Paulo writes: -+--- | http://www.wired.com/threatlevel/2010/03/packet-forensics/ | | At a recent wiretapping convention however, security researcher Chris = | Soghoian discovered that a small company was marketing internet spying = | boxes to the feds designed to intercept those communications, without = | breaking the encryption, by using forged security certificates, instead = | of the real ones that websites use to verify secure connections. To use = | the appliance, the government would need to acquire a forged certificate = | from any one of more than 100 trusted Certificate Authorities. | I rather like Cormac Herley's paper: http://preview.tinyurl.com/yko7lhg So Long, And No Thanks for the Externalities: The Rational Rejection of Security Advice by Users which I cite here for this line: It is hard to blame users for not being interested in SSL and certificates when (as far as we can determine) 100% of all certificate errors seen by users are false positives. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
Matt Crawford writes: -+--- | Imagine a couple of hundred million devices with updatable | firmware on them, and one or more rogue updates in the wild. So should or should not an embedded system have a remote management interface? If it does not, then a late discovered flaw cannot be fixed without visiting all the embedded systems which is likely to be infeasible both because some will be where you cannot again go and there will be too many of them anyway. If it does have a remote management interface, the opponent of skill focuses on that and, once a break is achieved, will use those self-same management functions to ensure that not only does he retain control over the long interval but, as well, you will be unlikely to know that he is there. This leads to a proposal on what to do about the future: Embedded systems, if having no remote management interface and thus out of reach, are a life form and as the purpose of life is to end, an embedded system without a remote management interface must be so designed as to be certain to die no later than some fixed time. Conversely, an embedded system with a remote management interface must be sufficiently self-protecting that it is capable of refusing a command. Long live HAL, --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: TLS break
| | This is the first attack against TLS that I consider to be | the real deal. To really fix it is going to require a change to | all affected clients and servers. Fortunately, Eric Rescorla | has a protocol extension that appears to do the job. | ...silicon... --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: [Barker, Elaine B.] NIST Publication Announcements
It is also completely impossible to prove you've deleted a record. Someone who can read the record can always make a copy of it. Cryptography can't fix the DRM problem. If, and only if, the document lives solely within an airtight surveillance system, then it is possible to prove deletion. Put differently, only within airtight surveillance will the absence of evidence be the evidence of absence. In factually, if not politically, correct terms, the Electronic Health Record is the surest path to a surveillance state, but I digress. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: The latest Flash vulnerability and monoculture
It would also help quite a bit if we had better encapsulation technology. Binary plug-ins for browsers are generally a bad idea -- having things like video players in separate processes where operating system facilities can be used to cage them more effectively would also help to mitigate damage. I think this is one of those circumstances where if you can get the criminal to go to the house next door you've won and that is all the winning you can do. That everyone else uses Famous Vendor Software Latest Version and you don't is your win. Now it would be entirely ironic if the complexity of something (think ASN.1) caused a single working open source version (think ASN.1 compiler) to eclipse all other versions just because the complexity has made it too hard to go forward. As Mike O'Dell used to say, left to themselves, competent engineers will deliver the most complex code they can debug. This may apply to the world at large. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: New Technology to Make Digital Data Disappear, on Purpose
The pieces of the key, small numbers, tend to =93erode=94 over time as they gradually fall out of use. To make keys erode, or timeout, Vanish takes advantage of the structure of a peer-to-peer file system. Such networks are based on millions of personal computers whose Internet addresses change as they come and go from the network. One would imagine that as IPv6 rolls out, the need for DHCP goes to zero excepting for mobile devices attaching to public (not carrier) nets. Yes? --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Weakness in Social Security Numbers Is Found
I don't honestly think that this is new, but even if it is, a 9-digit random number has a 44% chance of being a valid SSN (442 million issued to date). Similarly, with Chase and Citi each at about 100M cards issued, and the 16-digit card number having 7 of those digits fixed-in-advance, a 16-digit random number has a 10% chance of being a valid card number. Amex cards are 15-digits and there are 50M in play, so a random 15-digit number has a 50% chance of being a valid card number. As such, an attacker is better off holding the password constant and cycling through account numbers than holding the account number constant and cycling through password guesses. Yes, these are approximations for the purpose of argument, but I don't see what the big deal is for the All The News That's Fit to Print paper in learning that there ain't much entropy in SSNs. Hell, my brother and I have sequential numbers. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
MetriCon 4.0
On behalf of the program committee, may I please direct your attention to your possible participation MetriCon 4.0. The MetriCon 4.0 Workshop will be held on Tuesday, August 11, 2009, in Montreal, Quebec, co-located with the USENIX Security Symposium. All who are interested in participating should review the formal Call for Participation and, as it says, soon communicate via email to the MetriCon 4.0 program committee. As with all MetriCon events, MetriCon 4.0 is by invitation with both invitations for attendance-only and for attendance with presentation possible. Please be in touch. The theme of this episode is The Importance of Context. This workshop series is intense, and is focused on progress rather than claims of first discovery. See http://securitymetrics.org/content/Wiki.jsp?page=Metricon4.0 Dan Geer - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Has any public CA ever had their certificate revoked?
No, but a few years ago I looked at all the certs in IE and Netscape and found that about 30% of them were from companies that were at that time no longer in existence. The expiries on those where-are-they-now certs were often as not three decades into the future. N.B., if you are willing to take no longer baked into the browser as effectively revocation, there is a retrospective clerical job that might be a fun project if you had some graduate student labor to assign. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
anyone know Morris Code?
Does anyone know what the Morris Code is inside Peachinc's mobile ticketing appliance/kiosk is? Reference URL (video advert) at http://www.peachinc.com/moviePage.htm UK patent, but for the reading mechanism only, at http://www.ipo.gov.uk/p-find-publication-getPDF.pdf?PatentNo=GB2446424DocType=AJournalNumber=6221 As always, the phrase proprietary coding readable only by us caught my ear. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Bitcoin v0.1 released
Bill Frantz writes: -+- | Some people tell me that the 0wned machines are among the most | secure on the network because botnet operators work hard to | keep others from compromising their machines. I could see the | operators moving toward being legitimate security firms, | protecting computers against compromise in exchange for some of | the proof of work (POW) money. I'm one of those people. Quoting from my speech of 1/20: Virus attacks have, of course, become rarer over time, which is to say that where infectious agents once ruled, today it is parasites. Parasites have no reason to kill their hosts -- on the contrary they want their hosts to survive well enough to feed the parasite. A parasite will generally not care to be all that visible, either. The difference between parasitism and symbiosis can be a close call in some settings, and of the folks who famously bragged of being able to take the Internet down in twenty minutes, one has said that a computer may be better managed once it is in a botnet than before since the bot-master will be serious about closing the machine up tight against further penetration and similarly serious about patch management. Therefore, since one can then say that both the machine's nominal owner and the bot master are mutually helped, what we see is evolution from parasite to symbiont in action. According to Margulis and Sagan, Life did not take over the globe by combat, but by networking. On this basis and others, bot-nets are a life form. Rest of text upon request. Incidentally, I *highly* recommend Daniel Suarez's _Daemon_; trust me as to its relevance. Try this for a non-fiction taste: http://fora.tv/2008/08/08/Daniel_Suarez_Daemon_Bot-Mediated_Reality --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: [heise online UK] Secure deletion: a single overwrite will do it
Peter Gutmann has responded http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html (see the Further Epilogue section well down the page) --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Security by asking the drunk whether he's drunk
or asking Can I trust you? --- http://blog.startcom.org/?p=145 Slashdot and others are reporting on this story about how it was possible for a person to receive a completely valid certificate for a random domain of his choosing without any questions or verification. In this case he generated a certificate for mozilla.com from a reseller of the Comodo certificate authority. I'm hoping this is just a single instance but it makes you remember that the browser pre-trusted certificate authorities really needs to be cleaned up. If it's not obvious enough, this is not good for Tor users due to the fact that we try to rely on SSL certificates to make sure that traffic isn't sniffed while using Tor. -Roc Tor Admin --- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: AES HDD encryption was XOR
Victor Duchovni writes: -+- | The computing power of the microprocessor is still under | 32 powers of 2 from its inception, naive extrapolation | to the next 32 powers of 2 is unwise. Well taken, indeed. But what I am myself interested in is the relationship of the three main up-curves, Moore's for CPU horsepower per unit of money, and its two un-named siblings for storage and for bandwidth. As I read the tea-leaves, storage is doubling at perhaps a 12-month rate while bandwidth is faster still. Yes, these are laboratory figures, but the lab is where the action is. This tells me, I think, that the future of computing is ever more data-rich but, at the same time, that that data-richness is eclipsed by ever-increasing data-mobility. Suppose the doubling times are 18/12/9; then a decade is two orders of magnitude for CPU, three for storage, and four for bandwith. I do not see how this does not radically alter the economically optimal computing infrastructure or, for that matter, the nature of the problems we here are collectively paid to solve. This is, of course, all irrelevant if and when the Singularity occurs. Kurzweil's guess of 2035 is 27 years away, which is to say 18 powers of two out, not 32. Perhaps relevant to this list, imagine that the research described here: http://technology.newscientist.com/channel/tech/mg20026805.500-cultured-robots- make-sweet-music-together--.html was of two programs creating not music but a cipher. Thinking out loud, --dan [ just for amusement, 2008 world production of wheat and rice would each cover 53 squares, with maize coming in at 51 squares ] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: voting by m of n digital signature?
James A. Donald writes: -+--- | Is there a way of constructing a digital signature so | that the signature proves that at least m possessors of | secret keys corresponding to n public keys signed, for n | a dozen or less, without revealing how many more than m, | or which ones signed? | quorum threshhold crypto; if Avishai Wool or Moti Yung or Yvo Desmedt or Yair Frankel or... are here on this list, they should answer a *tiny* contribution on my part http://geer.tinho.net/geer.yung.pdf humbly, --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: street prices for digital goods?
Damien Miller writes: -+--- | | David Molnar [EMAIL PROTECTED] writes: | | Dan Geer's comment about the street price of heroin as a metric for | success has me thinking - are people tracking the street prices of | digital underground goods over time? | | I've been (very informally) tracking it for awhile, and for generic | data (non- Platinum credit cards, PPal accounts, and so on) it's | essentially too cheap to meter, you often have to buy the stuff in | blocks (10, 20, 50 at a time) to make it worth the sellers while. | | At such cheap prices, it must be close to the point where it would | be worth it for the the card issuers to buy the numbers as a loss | mitigation measure. | I have had a guy who wished to remain nameless claim that he makes a fine living breaking into the machines of black-market card sellers and copying the card numbers they have for sale. He then (he says) takes those card numbers to the issuing banks and sells those numbers to the banks so that the banks can prophylactically cancel the soon-to-be-affected cards. He claimed to get 50c/card. All hearsay... --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: street prices for digital goods?
David Molnar writes, in part: -+--- | Dan Geer's comment about the street price of | heroin as a metric for success has me thinking - | are people tracking the street prices of digital | underground goods over time? This material is in fact tracked but not so publicly reported. You named the obvious sources, but no one to my knowledge publishes regularly. I previously committed myself to doing this annually, and am about to convince myself to go quarterly. See http://geer.tinho.net/ieee/ieee.geer.0801.pdf for what I am (lightheartedly) talking about. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: street prices for digital goods?
Sigh... typing in a moving vehicle. This is the right URL, verified by cutpaste. http://geer.tinho.net/ieee/ieee.sp.geer.0801.pdf Sorry. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
Peter Gutmann writes, in part: -+ | ... - the rate-limiting step is the fact that | the crooks simply can't use all the stolen identities | they have, not any security measures that may be present. | ... To my knowledge, you are correct. It seems that the price of stolen credentials (on the black market) is falling, which, as with the street price of heroin, would tend to indicate that the opposition is winning. I have a slide for this somewhere (not on this machine) and will dig it up if needed, but the disparity between actual crime and a naive estimate of the opportunity for crime seems to be widening. If correct, then such a disparity would either indicate that our countermeasures are winning -or- the predators are leaving prey on the field. I'm sadly of the opinion that it is the latter. In their Internet Security Threat Report, Symantec used to publish the number of bots detected. The last one of those I have at hand showed a leveling out of the number found de novo per unit interval (per month). Again, this permits two interpretations; on the one hand, we are winning in that we are preventing the problem from worsening while on the other hand it can be read to mean that as fast as we remove bots from hosts that other hosts are botted and, as such, the supply of bots being stable implies that it is easy enough to replace them that the lost of an individual host does not slow down our opposition. What does (in the Symantec graphs) vary is the variance of in-and-out-flow, but not the fraction that are botted. This would tend to strengthen the argument that any periodic sweep of bots off networks is compensated for relatively quickly. In public health, widely varying incidence (new infection rate) but stable prevalence (infected fraction) tends to indicate a high degree of infectability and not a particularly effective immune response. We see this in a way in the AIDS data -- every advance in treatability seems to be followed by increases in risky behavior while prevalence remains to a degree stable. This idea of replacement of cured machines by infected machines seems corroborated in a different way as well. The opposition seems to have lately decided that the advantages of stealth outway the advantages of persistence, which is to say that in-core-only infection is now the preferred mechanism and not writing to disk so as to preserve infected status through a reboot cycle. If this is correct, then it signals that the opposition can replace machines lost through reboot easily enough that the availability of penetrated machines can be better enhanced through making infections harder to find (latent, in medical parlance) than through making a once penetrated machine stay penetrated as to do the latter you have to expose yourself to periodic clean-up of that which is persistent (on disk). For anyone looking ahead, the interaction between this phenomenon (if it is indeed a phenomenon) and the growing role of virtual machines should be of intense interest. Inferentially yours, --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: road toll transponder hacked
Steven M. Bellovin writes, in part: -+--- | There's a limit to how far they can go with that, because of the fear | of people abandoning the transponders. | snip | As for usage-based driving -- the first question is the political will | to do so. | snip | Finally, the transponders may not matter much longer; OCR on license | plates is getting that good. | I don't think whether it is a transponder or not actually matters, Steve, since, as you say, OCR of the license plates makes whether a transponder is in place totally irrelevant. As to public resistance -- look at the revenue coming in to, say, Chicago from the red-light cameras and tell me that this won't spread. Similarly, per-mile road-use pricing will be all about revenue enhancement but it will be painted DHS-faireness-green (So as to fairly fund the maintainance of this State's critical infrastructure, this Act converts the funding mechanisms over to a fairer road-use policy but, at the same time, it leaves in place the State gasoline tax, thereby penalizing the people who continue to drive gas guzzlers). Which leads back to the recording of travel and the handling of those recordings. When New Jersey signed up with EZ-Pass it required the company involved to retain toll records for ten years (as an aid to law enforcement). Since that is the same company in lots of states even if it is called something else (like FastLane in Massachusetts), the rational thing for the company to do is to just keep everything forever. With disk prices falling as they are, keeping everything is cheaper than careful selective deletion, that's for sure. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: road toll transponder hacked
Bill Frantz writes, in part: -+-- | In the San Francisco Bay Area, they are using the transponder codes | to measure how fast traffic is moving from place to place. They | post the times to various destinations on the electric signs when | there are no Amber alerts or other more important things to | display. It is quite convenient, and they promise they don't use it | to track people's trips. | Look for general tracking to appear everywhere. Fast declining gasoline tax revenues will be replaced with per-mile usage fees, i.e., every major road becomes a toll road. Most likely first in will be California and/or Oregon. The relationship to this list may then be thin excepting that the collection and handling of such data remains of substantial interest. Of course, everyone who carries a cell phone has already decided that convenience trumps security, at least the kind of security that says they can't misuse what they ain't got. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: road toll transponder hacked
Personally, I don't want to have a history of my travel stored in any database. Right now, purchasing a one-time CharlieTicket is a 30 cent surcharge per ride, but it is the only way to take the subway in Boston without creating a travel history. Privacy in public transportation should be equally accessible to all citizens, regardless of financial resources. I suspect that you, as do I, pay for as many things in cash as humanly possible though, of course, we are well past the point at which paying for an airline ticket, say, in cash does anything more than make you even more inspected than you would be if you used credit. That said, the 30c surcharge for having no record kept for riding the subway is at once a price for privacy that is at least expressed in the coin of the realm and, at the same time, not a guarantee, just a side effect. If the MBTA general manager were to say For 30c more, we promise to forget you were a passenger he would be out of a job in the morning at the Governor's demand and there'd be wide agitation against the idea that better off people get privacy when poor folks don't. Do you suppose that we can, just possibly, make privacy into a class warfare issue? We sort of do that already in that the people who make privacy law, legislature and executive alike, are afforded precisely zero privacy by both the courts and the press. As such, one has to be a truly addled optimist to imagine that those who have no privacy are nevertheless willing to grant you more privacy than they have, unless they are somehow nostalgic for what they themselves lost in becoming a member of government. Me, I think that the loss of privacy required to become part of government is a sieve for not caring about such issues because, if you did care, you wouldn't go into government in the first place. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Voting machine security
Paul Hoffman writes: -+-- | At 9:24 AM -0700 8/18/08, Eric Rescorla wrote: | (and because of the complexity of US elections, | hand counting is quite expensive) | | This is quite disputable. Further, hand vs. machine counting is core | to the way we think about the security of the voting system. | The keynote talk for the USENIX Security Symposium was Dr. Strangevote or: How I Learned to Stop Worrying and Love the Paper Ballot Debra Bowen, California Secretary of State and her talk had one slide only. I do not have the slide, but I can reproduce it. It was a photo of the tail end of her car and on it a bumper sticker. That bumper sticker read PREVENT UNWANTED PRESIDENCIES MAKE VOTE COUNTING A HAND JOB In no other state could a Constitutional Officer get away with such a bumper sticker, but... --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
another proprietary symmetric cipher ?
yet another proprietary symmetric cipher ? http://www.pureentropy.com ... Encryption Security Solutions provides unprecedented encryption security, efficiency, and performance for business applications ensuring critical information is secure. Encryption Security Solutions, LLC (ES²) has developed an innovative, proprietary symmetrical encryption algorithm (JUMBLE) for commercial applications. This algorithm provides an end-to-end or site solution, for use by individuals or across an enterprise environment. Using the newly developed and proprietary JUMBLE encryption engine allows ES² to provide multiple encryption solutions for all digital data formats, including real-time streaming high definition digital video. The JUMBLE engine can be integrated directly in the client, at the web server, application server, or database layer. This unique software solution goes beyond current platforms that contain such things as centralized cryptographic processing, key management, policy management, and security administration because it does not rely on human procedure-based security practices. JUMBLE provides unprecedented advantages in security, scalability and manageability. ... - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: OpenID/Debian PRNG/DNS Cache poisoning advisory
Eric Rescorla wrote: At Fri, 8 Aug 2008 17:31:15 +0100, Dave Korn wrote: Eric Rescorla wrote on 08 August 2008 16:06: At Fri, 8 Aug 2008 11:50:59 +0100, Ben Laurie wrote: However, since the CRLs will almost certainly not be checked, this means the site will still be vulnerable to attack for the lifetime of the certificate (and perhaps beyond, depending on user behaviour). Note that shutting down the site DOES NOT prevent the attack. Therefore mitigation falls to other parties. 1. Browsers must check CRLs by default. Isn't this a good argument for blacklisting the keys on the client side? Isn't that exactly what Browsers must check CRLs means in this context anyway? What alternative client-side blacklisting mechanism do you suggest? It's easy to compute all the public keys that will be generated by the broken PRNG. The clients could embed that list and refuse to accept any certificate containing one of them. So, this is distinct from CRLs in that it doesn't require knowing which servers have which cert... Funnily enough I was just working on this -- and found that we'd end up adding a couple megabytes to every browser. #DEFINE NONSTARTER. I am curious about the feasibility of a large bloom filter that fails back to online checking though. This has side effects but perhaps they can be made statistically very unlikely, without blowing out the size of a browser. Updating the filter could then be something we do on a 24 hour autoupdate basis. Doing either this, or doing revocation checking over DNS (seriously), is not necessarily a bad idea. We need to do better than we've been. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
With the caveat that I am reading mail in reverse order (i.e., panic-mode), I do have to say one thing and it isn't even to mount a stirring defense of Kerberos, which does not need defending anyhow... The design space for practical network security has always been: I'm OK You're OK The Internet is a problem A gathering storm of compromised machines, now variously estimated in the 30-70% range depending on with whom you are talking, means that the situation is now: I'm OK, I think I have to assume that you are 0wned The Internet might make this worse Put differently, network security has now come close to Spaf's famous line about netsec in the absence of host security being assured delivery of gold bars from a guy living in a cardboard box to a guy sleeping on a park bench. BTW, it is probably time to turn off your software's autoupdate feature. http://www.infobyte.com.ar/down/isr-evilgrade-Readme.txt Likely off-topic, --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The wisdom of the ill informed
Ed Gerck writes: -+-- | ... | Not so fast. Bank PINs are usually just 4 numeric characters long and | yet they are considered /safe/ even for web access to the account | (where a physical card is not required). | | Why? Because after 4 tries the access is blocked for your IP number | (in some cases after 3 tries). | ... So I hold the PIN constant and vary the bank account number. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Beowulf] Re: hobbyists
Eugen Leitl writes: -+- | I think that's a wise decision. Skype is a giant black | box. Fabrice Desclaux published a fair amount of | cryptanalysis papers about Skype, each one more | frightening than the previous ([1], [2] and [3]) My read on Skype is that they are doing a world leading job when it comes to avoiding vulnerabilities, better, indeed than the operating systems on which they run. One could call it a design weakness that to interface with the plain old telephone system there has to be a knowable, fixed in-the-clear peering to the POTS. If I am a state actor or equivalent, I do not need to bother myself with breaking VoIP crypto -- I just insert some tool into the peering point where the Skype caller reverts to the ordinary. Yes, a state may be interested in two parties each of whom has a Skype instance and thus the demodulation for POTS does not occur, but two such parties, if they really care, would do their own end-to-end protections even if it is a simple as speaking Navajo. All hail Saltzer, Reed, and Clark. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: reminder of upcoming deadline
MetriCon 3.0 agenda at this URL http://www.securitymetrics.org/content/Wiki.jsp?page=Metricon3.0 Workshop is limited attendance though some small number of requests can still be granted; send same by e-mail to [EMAIL PROTECTED] Best, --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: not crypto, but fraud detection + additional
Allen writes: -+--- | I don't know what the policy is in Ireland, but here in the USA | there is no stop loss on debit cards so the banks are not | obligated to make good on fraudulent withdrawals. snip There is also a legal distinction between a personal credit card and a corporate card in terms of the regulated upper bound on the losses due to a stolen card and fraudulent charges on it, though the credit companies tend never to stand on their right to not rescind fraudulent charges on non-personal cards. Factoid: Had the $50 stop-loss limit been indexed for inflation, then it would today be $300. (1968-present) --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
reminder of upcoming deadline
Call for Participation MetriCon 3.0 Third Workshop on Security Metrics Tuesday, 29 July 2008, San Jose, California Overview Security metrics -- an idea whose time has come. No matter whether you read the technical or the business press, there is a desire for converting security from a world of adjectives to a world of numbers. The question is, of course, how exactly to do that. The advantage of starting early is, as ever, harder problems but a clearer field though it is very nearly too late to start early. MetriCon is where hard progress is made and harder problems brought forward. The MetriCon Workshops offer lively, practical discussion in the area of security metrics. It is a, if not the, forum for quantifiable approaches and results to problems afflicting information security today, with a bias towards practical, specific implementations. Topics and presentations will be selected for their potential to stimulate discussion in the Workshop. Past events are detailed here [1] and here [2]; see, especially, the meeting Digests on those pages. MetriCon 3.0 will be a one-day event, Tuesday, July 29, 2008, in San Jose, California, USA. The Workshop begins first thing in the morning, meals are taken in the meeting room, and work/discussion extends into the evening. As this is a workshop, attendance is by invitation (and limited to 60 participants). Participants are expected to come with findings, to come with problems, or, better still, both. Participants should be willing to discuss what they have and need, i.e., to address the group in some fashion, formally or not. Preference will naturally be given to the authors of position papers/presentations who have actual work in progress. Presenters will each have a short 10-15 minutes to present his or her idea, followed by a another 10-15 minutes of discussion. If you would like to propose a panel or a group of related presentations on different approaches to the same problem, then please do so. Also consistent with a Workshop format, the Program Committee will be steered by what sorts of proposals come in response to this Call. Goals and Topics Our goal is to stimulate discussion of, and thinking about, security metrics and to do so in ways that lead to realistic, early results of lasting value. Potential attendees are invited to submit position papers to be shared with all, with or without discussion on the day of the Workshop. Such position papers are expected to address security metrics in one of the following categories: Benchmarking of security technologies Empirical studies in specific subject matter areas Financial planning Long-term trend analysis and forecasts Metrics definitions that can be operationalized Security and risk modeling including calibrations Tools, technologies, tips, and tricks Visualization methods both for insight and lay audiences Data and analyses emerging from ongoing metrics efforts Other novel areas where security metrics may apply Practical implementations, real world case studies, and detailed models will be preferred over broader models or general ideas. How to Participate Submit a short position paper or description of work done or ongoing. Your submission must be brief -- no longer than five (5) paragraphs or presentation slides. Author names and affiliations should appear first in or on the submission. Submissions may be in PDF, PowerPoint, HTML, or plaintext email and must be submitted to metricon3 AT securitymetrics.org. These requests to participate are due no later than noon GMT, Monday, May 12, 2008 (a hard deadline). The Program Committee will invite both attendees and presenters. Participants of either sort will be notified of acceptance quickly -- by June 2, 2008. Presenters who want hardcopy materials to be distributed at the Workshop must provide originals of those materials to the Program Committee by July 21, 2008. All slides, position papers, and what-not will be made available to all participants at the Workshop. No formal academic proceedings are intended, but a digest of the meeting will be prepared and distributed to participants and the general public. (Digests for previous MetriCon meetings are on the past event pages mentioned above.) Plagiarism is dishonest, and the organizers of this Workshop will take appropriate action if dishonesty of this sort is found. Submission of recent, previously published work as well as simultaneous submissions to multiple venues is entirely acceptable, but only if you disclose this in your proposal. Location MetriCon 3.0 will be co-located with the 17th USENIX Security Symposium at the Fairmont Hotel in San Jose, California. Cost $225 all-inclusive of meeting space, materials preparation, and meals for the day. Important Dates Requests to participate: by May 12, 2008 Notification of acceptance: by June 2, 2008 Materials for distribution: by July 21, 2008 Workshop Organizers Dan Geer, Geer Risk Services
Re: Toshiba shows 2Mbps hardware RNG
Peter Gutmann wrote: David G. Koontz [EMAIL PROTECTED] writes: Military silicon already has RNG on chip (e.g. AIM, Advanced INFOSEC Machine, Motorola), That's only a part of it. Military silicon has a hardware RNG on chip alongside a range of other things because they know full well that you can't trust only a hardware/noise-based RNG, there are too many variables and too many things that can go wrong with that single source. That's why I was sceptical of the we've solved the RNG problem with our custom hardware claim, they've created one possible source of input but not a universal solution. Peter. Peter, you've just hit on something that's genuinely confused me for quite some time. Combining hash functions has always seemed naive -- the problem with chaining two different functions is that it creates a midpoint; you can collide half the bitspace independently of the other half. Better to just thoroughly mix them both. But shouldn't it be an improvement to XOR a theoretically correct RNG with a well seeded PRNG, based on the theory that: 1) Either generator could be safely XOR'd against a repeated series of 0x41's, and the output would still be just as random 2) The flaws of a subtlety broken RNG would be difficult to exploit through the noise of a sufficiently validated cryptographic function, and vice versa For example, the following construction: Start with an RNG. Retrieve 64K of random data. Assume there might be a bias somewhere in there, but that at least 256 bits are good. SHA-256 the data. AES-256 encrypt the data with the result from the SHA-256. XOR the random data against its encrypted self. Return 64K of PNRG-hardened RNG data. Aside from the obvious rejoinder to maybe XOR *another* batch of entropy against the previous batch's encrypted self (a change that halves performance), I can't see much wrong. I rather deeply doubt I'm the first to come up with a suggestion like that either. So, uh, why do weak RNG's keep showing up? Is there something fundamentally breakable in the above design? --Dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Gutmann Soundwave Therapy
Amateurs talk about algorithms. Professionals talk about economics. That would be Amateurs study cryptography; professionals study economics. -- Allan Schiffman, 2 July 04 Quotationally yours, --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Interesting editorial comment on security vs. privacy
Udhay Shankar N writes: -+- | http://www.claybennett.com/pages/security_fence.html | Earlier this week, I heard Dr. Donald Kerr, Principal Deputy Director, ODNI, say that the greatest challenge of the next (U.S.) administration would be a fundamental re-thinking of the inter-relation of security privacy. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
(as if anyone uses client certificates anyway)? Guess why so few people are using it ... If it were secure, more people would be able to use it. People don't use it because the workload of getting signed up is vastly beyond their skillset, and the user experience using the things is pretty bad too. And there are hundreds of internal systems I heard of that are using client certificates in reality every day. There's always a few people using a technology. It's certainly a nonplayer out there. Probably more servers out there authing with Digest, honestly. Validated email addresses for spamming. Spear-phishing perhaps, ... There are CA´s on this planet that put things like social security numbers into certificates. Who? Seriously, that's pretty significant, I'd like to know who does this. Where does the SSL specification say that certificates shouldn´t contain sensitive information? I am missing that detail in the security consideration section of the RFC. The word public in Public Key isn't exactly subtle. Do we have any more ideas how we can get this flaw fixed before it starts hurting too much? Make it really easy to use some future version of SSL client certs, and quietly add the property you seek. Ease of use drives technology adoption; making the tech actually work is astonishingly secondary. Heh, you asked :) We have an issue here. And the issue isn´t going to go away, until we deprecate SSL/TLS, or it gets solved. To be clear, we'd *have* an issue, if any serious number of people used SSL client certs. I think you have a point that if SSL client certs become very popular going forward, then every website you go to will quietly grab your identity through their ad banners. * We fix SSL Does anyone have a solution for SSL/TLS available that we could propose on the TLS list? If not: Can anyone with enough protocol design experience please develop it? What solution could there be? You're actually going to SSL to the banner ad network, and you're going to give them your client cert. * We deprecate SSL for client certificate authentication. We write in the RFC that people MUST NOT use SSL for client authentication. (Perhaps we get away by pretending that client certificates accidently slipped into the specification.) People by in large do not use SSL client cert authentication. This is problematic, as there's some very nice cryptographic aspects of the system. * We switch from TLS to hmmm ... perhaps SSH, which has fixed the problem already. Hmm, there we would have to write all the glue RFCs like HTTP over SSH again ... I used to code for SSH. SSL is an entire top-to-bottom stack, replete with a deep PKI infrastructure. SSH? Tunneling transport, barely even librarized. Try to send a DVD iso image (4GB) over a SSL or SSH encrypted link with bit errors every 1 bits with a client software like scp that cannot resume downloads. I gave up after 5 tries that all broke down in average after 1 GB. (In that case it was a hardware (bad cable) initiated denial of service attack ;-) The problem here isn't checksums. SSH is notoriously buggy when packets are dropped. I think there are certain windows in which OpenSSH assumes it will get a response. If it doesn't, it just dies. So, outages more than a few hundred milliseconds have a small percentage chance of causing the session to permanently stall. Corrupted MAC on input -- this is a decent sign of corruption at the app layer. Did you really try this with OpenSSL? I've had much better luck there. If the link layer gives you 1/256, and the TCP layer gives you 1/65536, and the SSL layer demands 0/16777216, then end up with 1/16777216 too much. Actually, 256*65536 = 1677216 :) In actuality, you have both IP and TCP checksums. So you get 8 bits from link, 16 bits from IP, and 16 bits from TCP. A random corrupt packet has about 2^40 odds of getting through. Of course, one real problem is that the checksum algorithms don't exactly distribute noise randomly, and noise is not random. Still, corruption doesn't start being a problem until you get some pretty serious amounts of transfer. (Interestingly, I've been looking at IPsec lately, not for encryption, but for better checksumming.) Best regards, Philipp Gühring - 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: patent of the day
I wonder whether this was research to see how hard it was to get the PTO to grant an absurd patent. Get Simson's opinion, please. It is not insane to patent something so that you can control its use and to do so for reasons other than wanting to lay about in the Caribbean/Vegas. As to prior art, consider A Revocable Backup System, by Boneh and Lipton, 6th USENIX Security Symposium, presented 25 July 1996. (see [1] below) BTW, I can personally attest that the USPTO makes both Type I (false positive) errors (in granting patents that should not be classified as useful and unobvious) *and* Type II (false negative) errors (when confronted with something sufficiently unobvious that they find it impossible to understand that it is either unobvious or useful much less both). --dan [1] http://www.usenix.org/publications/library/proceedings/sec96/boneh.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 2008: The year of hack the vote?
Well, for all of you who want to prove that hacking the vote is easy, here's your chance to do something: http://apnews.myway.com/article/20080121/D8UA8VGG0.html [ ObDebate: is a winner-take-all state more or less attractive to vote hacking? ] --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DRM Helps Sink Another Content Distribution Project
So, what is Apple doing for its brand-new iTunes movie rental thing? 1/3rd of the way into Jobs' song-and-dance http://stream.qtv.apple.com/events/jan/f27853y2/m_972345688g_650_ref.mov --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Death of antivirus software imminent
Crypto solves certain problems very well. Against others, it's worse than useless -- worse, because it blocks out friendly IDSs as well as hostile parties. Yawn. IDS is dead, has been for a while now. The bottom line discovery has been that: 1) Anomaly detection doesn't work because anomalies are normal, and 2) Unless you're scrubbing up and down the application and network stacks, you just have no idea what the host endpoint is parsing. At the point where crypto shows up, it's already too late. --Dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Death of antivirus software imminent
however, another interpretation is that the defenders have chosen extremely poor position to defend ... and are therefor at enormous disadvantage. it may be necessary to change the paradigm (and/or find the high ground) in order to successfully defend. First, it is evident that the malware writers have reached a level of sophistication where stealth is more attractive than persistence, i.e., prey are sufficiently abundant that it does not matter if your code survives reboot -- you can always get a new machine soon enough. Second, as soon as one of these guys figures out how to hook the memory manager (which may already have happened), then the ability to find the otherwise in-core-only malware goes away as your act of scanning memory will be seen by the now-corrupted memory manager and the malware will be thus relocated as you search such that you are playing blindman's bluff without knowing that you are. Third, targetted malware does not defeat the AV paradigm technically, rather it defeats the business model as no AV company can afford to craft, test, and distribute signatures for any malware that does not already have, say, 50,000 victims. Fourth, under so-called Service-Oriented-Architecture, there is no one anywhere who knows where all the moving parts are. The aspect of this that is directly relevant to this list is that while we have labored to make network comms safe in an unsafe transmission medium, the world has now reached the point where the odds favor the hypothesis that whomever you are talking to is themselves already 0wned, i.e., it does not matter if the comms are clean when the opponent already owns your counterparty. I blogged on this recently (guest for Ryan Naraine) and it made the top of Slashdot. Apologies for boring those who've already seen it. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Question on export issues
Alan writes: -+ | What are the rules these days on crypto exports. Is a review | still required? If so, what gets rejected? | The following is a recent interaction with specialty export counsel, though somewhat modified as I detoxed it from base64 to ASCII plaintext and from infinite line length to fixed line length. When you file, you have immediate permission to export to, essentially, the anglophone democracies and western Europe. If you have heard nothing in 30 days elapsed time, you are then free to export generally but you will never be permitted to export to the embargoed country list (Cuba, Iran, Sudan, Syria, North Korea, and Libya). YMMV. --dan -8cut-here8- A. BIS Checklist of Questions: 1. Does your product perform cryptography, or otherwise contain any parts or components that are capable of performing any of the following information security functions? (Mark with an X all that apply) a. _ encryption b. _ decryption only (no encryption) c. _ key management / public key infrastructure (PKI) d. _ authentication (e.g., password protection, digital signatures) e. _ copy protection f. _ anti-virus protection g. _ other (please explain) : ___ h. _ NONE / NOT APPLICABLE 2. For items with encryption, decryption and/or key management functions (1.a, 1.b, 1.c above): a. What symmetric algorithms and key lengths (e.g., 56-bit DES, 112 / 168-bit Triple-DES, 128 / 256-bit AES / Rijndael) are implemented or supported? b. What asymmetric algorithms and key lengths (e.g., 512-bit RSA / Diffie-Hellman, 1024 / 2048-bit RSA / Diffie-Hellman) are implemented or supported? c. What encryption protocols (e.g., SSL, SSH, IPSEC or PKCS standards) are implemented or supported? d. What type of data is encrypted? B. BIS Review Requirements for Form 748-P. If any inquiry is not applicable, please state N/A. (a) State the name of the encryption item being submitted for review. i. Enter the name of the manufacturer of the software. ii. Provide a brief technical description of the basic purpose to be served by the encryption; iii. Provide a brief description of the type of encryption used in the software; e.g., 168-bit Triple DES for xyz purpose, and 1024-bit RSA for abc purpose. (b) You would also need to provide brochures or other documentation as well as specifications related to the software, relevant product descriptions, architecture specifications and, if required by BIS, source code. You must also indicate whether there have been any prior reviews of the product, if such reviews are applicable to the current submission. In addition, you must provide the following information in a cover letter accompanying your review request: (1) Description of all the symmetric and asymmetric encryption algorithms and key lengths and how the algorithms are used. Specify which encryption modes are supported (e.g., cipher feedback mode or cipher block chaining mode). (2) State the key management algorithms, including modulus sizes, that are supported. (3) For products with proprietary algorithms, include a textual description and the source code of the algorithm. (4) Describe the pre-processing methods (e.g., data compression or data interleaving) that are applied to the plaintext data prior to encryption. (5) Describe the post-processing methods (e.g., packetization, encapsulation) that are applied to the cipher text data after encryption. (6) State the communication protocols (e.g., X.25, Telnet or TCP) and encryption protocols (e.g., SSL, IPSEC or PKCS standards) that are supported. (7) Describe the encryption-related Application Programming Interfaces (APIs) that are implemented and/or supported. Explain which interfaces are for internal (private) and/or external (public) use. (8) Describe the cryptographic functionality that is provided by third-party hardware or software encryption components (if any). Identify the manufacturers of the hardware or software components, including specific part numbers and version information as needed to describe the product. Describe whether the encryption software components (if any) are statically or dynamically linked. (9) For commodities or software using Java byte code, describe the techniques (including obfuscation, private access modifiers or final classes) that are used to protect against decompilation and misuse. (10) State how the product is written to preclude user modification of the encryption algorithms, key management and key space. (11) For products which incorporate an open cryptographic interface as defined in part 772 of the EAR, describe the Open Cryptographic Interface. (12) We must provide sufficient information for BIS to determine whether the software qualifies for mass market consideration. The regulations offer examples
Re: 2008: The year of hack the vote?
May I point out that if voting systems have a level of flaw that says only an idiot would use them, then how can you explain electronic commerce, FaceBook, or gambling sites? More people use just those three than will *ever* vote. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 2008: The year of hack the vote?
John Denker writes: | | There is every reason to believe that the 2000 presidential | election was stolen. A fair/honest/lawful election would | have made Al Gore the 43rd president. | Let's not do this or we'll have to talk about JF Kennedy who, at least, bought his votes with real money. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 2008: The year of hack the vote?
Kevin Kretz writes: | [EMAIL PROTECTED] wrote: | More people use just those three | than will *ever* vote. | More people under 40, certainly. But in '04 there were 36 million | people over 65, most of whom are eligible to vote. You know a lot of | 70-year old e-gamblers or FaceBook members? I don't but my many over-70 relatives all have some sort of e-mail now, many from AOL where we know from history the price of buying the AOL screenames in bulk from an insider was at the rate of $0.001/name. Quoting my friend Marcus Ranum, the Internet will remain as insecure as it can and still apparently function. Why should voting be different? We are approaching a rat hole... --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: PlayStation 3 predicts next US president
If on the one hand, the correct procedure is sign-encrypt-sign, then why, on the other hand, is the parallel not sign-hash-sign ? --dan = http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.ps Donald T. Davis, Defective Sign Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML., Proc. Usenix Tech. Conf. 2001 (Boston, Mass., June 25-30, 2001), pp. 65-78.(180 Kbytes) (PDF, 200 Kbytes) (HTML, 80 Kbytes) Summary of the paper. Abstract: Simple Sign Encrypt, by itself, is not very secure. Cryptographers know this well, but application programmers and standards authors still tend to put too much trust in simple Sign-and-Encrypt. In fact, every secure e-mail protocol, old and new, has codified naïve Sign Encrypt as acceptable security practice. S/MIME, PKCS#7, PGP, OpenPGP, PEM, and MOSS all suffer from this flaw. Similarly, the secure document protocols PKCS#7, XML- Signature, and XML-Encryption suffer from the same flaw. Naïve Sign Encrypt appears only in file-security and mail-security applications, but this narrow scope is becoming more important to the rapidly-growing class of commercial users. With file- and mail-encryption seeing widespread use, and with flawed encryption in play, we can expect widespread exposures. In this paper, we analyze the naïve Sign Encrypt flaw, we review the defective sign/encrypt standards, and we describe a comprehensive set of simple repairs. The various repairs all have a common feature: when signing and encryption are combined, the inner crypto layer must somehow depend on the outer layer, so as to reveal any tampering with the outer layer. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: In all the talk of super computers there is not...
True, the contestants are given extra information, though. They know ahead of time that the words make up the name of a place, or a common saying, for example. That helps decrease the entropy considerably. They also know the exact number of characters in the final answer and are able to probe multiple characters in the phrase simultaneously. If a system is setup correctly, you should never be able to get a hint as to whether you have guessed any portion of a password correctly, and you probably don't know what sort of phrase the target has chosen, so it would seem like most of the entropy-reducing information the Wheel of Fortune contestant is able to take advantage of are not available to a password cracking algorithm. --dan While 2.5 bits/word seems low, the TV game show Wheel Of Fortune is evidence that people can correctly guess phrases even when a large proportion of the letters are missing. Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: interesting paper on the economics of security
Jerry/Hal, This lemon-car analogy is interesting. One sidebar that might be worked into the argument is the apparently widespread side-line business where a car is auctioned on eBay but before the sale is consumated the buyer engages a mechanic to check the car out pre-sale. The car and the mechanic are generally remote from the buyer but local to each other, and the mechanic is paid by the prospective buyer. The prospective buyer does not know the mechanic and is instead relying on some (to me) unknown combination of eBay endorsement and personal reputation. Note that all of what I just said is hearsay, though my office-mate says that he has bought three cars by this method. It almost causes me to say relying party out loud... If this idea is a rathole, then my fault and my apology. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Skype new IT protection measure
Ed Gerck writes: | We've heard it so many times: There's nothing to worry about. | Now, Skype adds a new IT protection measure -- love: | | The Skype system has not crashed or been victim of a cyber | attack. We love our customers too much to let that happen. | -- Forwarded message -- From: Valery Marchuk [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Fri, 17 Aug 2007 10:30:50 +0300 Subject: [Full-disclosure] Skype Network Remote DoS Exploit Hi all! On SecurityLab.ru forum an exploit code was published by an anonymous user. Reportedly it must have caused Skype massive disconnections today. The PoC uses standard Skype client to call to a specific number. This call causes denial of service of current Skype server and forces Skype to reconnect to another server. The new server also freezes and so on ... the entire network. Liks: http://www.securitylab.ru/news/301422.php PoC: http://en.securitylab.ru/poc/301420.php Best regards, Valery Marchuk www.SecurityLab.ru ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
[ This may well be OT; I leave that to the moderator. ] Leichter, Jerry writes: -+--- | As always, banks look for ways to shift the risk of | fraud to someone - anyone - else. The New Zealand | banks have come up with some interesting wrinkles on | this process. | This is *not* a power play by banks, the Trilateral Commission, or the Gnomes of Zurich. It is the first echo of a financial thunderclap. As, oddly, I said only yesterday, I think that big ticket Internet transactions have become inadvisable and will become more so. I honestly think that the party could be over for e-commerce, with eBay Motors as its apogee. Now what I think I know and what I am about to say are all based on hearsay. It is surely wrong in part, but until I am corrected in public it is true enough for lemonade making. The story begins with E-Trade's 10-Q filing of 17 November, which filing is at [1] and elsewhere. In that 10-Q, we have this paragraph: Other expenses increased 97% to $45.7 million and 55% to $101.9 million for the three and nine months ended September 30, 2006, respectively, compared to the same periods in 2005. These increases were primarily due to fraud related losses during the third quarter of 2006 of $18.1 million, of which $10.0 million was identity theft related. The identity theft situations arose from recent computer viruses that attacked the personal computers of our customers, not from a breach of the security of our systems. We reimbursed customers for their losses through our Complete Protection Guarantee. These fraud schemes have impacted our industry as a whole. While we believe our systems remain safe and secure, we have implemented technological and operational changes to deter unauthorized activity in our customer accounts. In other words, remote exploitation of individual customer's computers, doubtless many of them home machines and the laptops of road warriors, eventually lead to a loss for E-Trade that was material enough to appear on the 10-Q. This is not a pumpdump scheme where rubes are snookered into buying some worthless stock. No, it is the actual entry of trades into legitimate trading systems by legitimate users, only with the special case that those users are actually the alien malware using the captured credentials of the legitimate user and entering the trades from the legitimate users' legitimate machine. As I understand it, some of this malware is clever enough to piggyback sessions that are opened by the legitimate user using the much vaunted 2-factor authentication; thus proving that 2-factor auth is a mere palliative. As you are well aware, stealing data is now and everywhere the name of the game, and we have lots of supporting evidence that such theft is fully professionalized. As one example, the APWG has already shown that phishing e-mails are transmitted in a pattern that suggests the transmitters are enjoying a conventional 5-day work week, and there are many other examples. Mike D'Anseglio, Security Program Director at Microsoft, said two interesting things in the last six months: (1) that 2/3rds of all PCs have unwanted software running on them and (2) that state-of-the-art attack tools cannot be eliminated without a clean install from the raw iron up. Well, ironically due to SOx, as the loss amounts get bigger -- and bigger is an assured eventuality -- then those losses will hit Earnings Per Share, and disclosure from the governance and the financial points of view is thus made requirement as those losses are material. Data security has nothing to do with the disclosure as the disclosure is purely driven by the materiality. So, let's do a little math. E*Trade, call symbol ET, has an approximate market cap of $9.66B with approximately 440M shares outstanding. Their estimated annual earning per share is $1.36. Since the fraud loss goes directly the bottom line, an $18M loss in the one quarter is a $0.04 hit in earning per share for the quarter, which on an expected quarterly earning of $0.34/share is a 12% hit to the quarter. This is sufficiently material that it MUST be disclosed, and thus we have, like it or not, data sharing about the impact of digital security lapse -- even if we do not have data sharing about the mechanism of digital security lapse. What some of the banks now want to do is to have you download fresh code each time you go to trade, code that would theoretically protect the bank from the fact that your (user's) machine is almost surely compromised. To get that protection, such ideas as seizing control of the keyboard from the operating system so that keylogging can't happen while trades are being booked, are being floated. Think about what that would mean -- training users to use their Admin privilege to accept ActiveX controls that strip the OS of this or that subsystem, and to do so in the name of security. --dan P.S., The S.E.C. tackling some Estonian clown for $353,609 [2
Re: 0wned .gov machines (was Re: Russian cyberwar against Estonia?)
A while ago, I did a rough calculation that made me state that 15-30% of all machines are no longer under the sole control of their owner. In the intervening months, I got some hate mail on this, but in those same intervening months Vint Cerf said 40%, Microsoft said 2/3rds, and IDC said 3/4ths. Whatever it is, it is 0. And, of course, definitions matter. I don't think that 0wned is a binary variable any more; there are degrees of 0wned-ness with a wide range between the optimist (I replaced` the only program that was trojaned) to the pessimist (Any compromise of any sub-component makes the entire edifice untrustable). --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DNSSEC to be strangled at birth.
Dave, For the purposes of discussion, (1) Why should I care whether Iran or China sign up? (2) Who should hold the keys instead of the only powerful military under democratic control? (a) The utterly porous United Nations? (b) The members of this mailing list, channeling for the late, lamented Jon Postel? (c) The Identrus bank consortium (we have your money, why not your keys?) in all its threshhold crypto glory? (d) The International Telecommunication Union? (e) Other: _ Hoping for a risk-analytic model rather than an all-countries-are-created-equal position statement. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
virtualization as a threat to RNG
Quoting from a discussion of threat posed by software virtualization as found in Symantec's ISTR:xi, released today: The second type of threat that Symantec believes could emerge is related to the impact that softwarevirtualized computers may have on random number generators that are used inside guest operating systems on virtual machines. This speculation is based on some initial work done by Symantec Advanced Threat Research in a paper on GS and ASLR in Windows Vista. This research showed that the method used to generate the random locations employed in some security technologies would, under certain circumstances, differ wildly in a software-virtualized instance of the operating system. If this proves to be true, it could have considerable implications for a number of different technologies that rely on good randomness, such as unique identifiers, as well as the seeds used in encryption. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
news story - Jailed ID thieves thwart cops with crypto
http://news.com.com/Jailed+ID+thieves+thwart+cops+with+crypto/2100-7348_3-6144521.html Jailed ID thieves thwart cops with crypto By Tom Espiner Story last modified Tue Dec 19 06:46:45 PST 2006 Three men have been jailed in the U.K. for their part in a massive data theft operation. One of the accused ringleaders of the gang, Anton Dolgov--also known as Gelonkin--was sentenced to six years at London's Harrow Crown Court on Wednesday for his part in the theft of millions of dollars from victims in countries including the U.K. and the U.S. The ID thieves used stolen credit card numbers and created false identities to buy high-end electronics and other goods, which they then resold on eBay, prosecutors said. The gang pleaded guilty to conspiracy to defraud, obtain services by deception, acquire, use and possess criminal property, and conceal, disguise, convert, transfer or remove criminal property. One of the gang members, Aleksei Kostap, was also found guilty of perverting the course of justice, and was sentenced to four years' imprisonment. When the gang's premises were raided by the members of the Serious and Organised Crime Agency (SOCA), Kostap was handcuffed with his hands in front of his body. He managed to leap up and flick an electrical switch that wiped databases that could have contained records of the gang's activities stretching back more than 10 years, SOCA said. Kostap's action also triggered intricate layers of encryption on the gang's computer systems, which SOCA's experts were unable to crack, the court heard. SOCA was not prepared to discuss what encryption was used or why it was unable to decrypt it, as such information would enable other criminals to use the same methods. According to the Crown Prosecution Service (CPS), which confirmed that Kostap had activated the encryption after being arrested, it would take 400 computers 12 years to crack the code. Because much data was inaccessible to the police, it is not known how much the criminals profited from their operation, but it is believed that they made millions of dollars. Police were able to find evidence of 750,000 pounds ($1.46 million) worth of transactions between 2003 and 2006, but the gang had been operating since the mid-'90s. The true scale of the gang's crimes will probably never be known, said a representative for the CPS. Identify theft is a growing problem worldwide. Figures released by Sainsbury's Bank last week found that more than 4 million British citizens have suffered financial losses through ID fraud. And last year, in the U.S, identity theft for the third straight year topped the list of fraud complaints reported to the Federal Trade Commission. Consumers filed more than 255,000 identity theft reports to the FTC in 2005, accounting for more than a third of all complaints the agency received. Police became aware of the gang after a reported break-in at the gang's base of operations. When they raided the premises they found the gang hard at work at their computers and arrested them. They were very busy when they were arrested, the CPS said. The gang used fake identities, and falsified and forged passports to open bank and PayPal accounts, and sent the goods they purchased to residential addresses for later sale. They had already requested the mail be redirected from the addresses. Goods including Manchester United strips and cameras, which have a high resale value, were then auctioned on eBay. The CPS told ZDNet UK, CNET News.com's sister site, that the gang also had data containing registries of births and deaths, local tax documents and electoral registration applications, and that they had 120 different checkbooks in their possession. Fraud was their bread and butter, the CPS representative said. There is an outstanding arrest warrant for another member of the gang, believed to be a ringleader. Known as Mr. Kaljusaar, police have evidence of his involvement but as yet have no idea who or where he actually is, the CPS said. After the break-in at the gang's premises, the police became aware of an outstanding international arrest warrant for Gelonkin/Dolgov in the name of Anthony Peyton, which had been issued after the arrest of gang member Andreas Furhmann by Spanish authorities. Another gang member, Romanos Vasiliauskas, was jailed for 18 months on Thursday. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
ATM vulnerability
I hesitate to use the syllable crypto in describing this paper, but those who have not seen it may find it interesting. http://www.arx.com/documents/The_Unbearable_Lightness_of_PIN_Cracking.pdf Or profitable. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
randomness in space..
http://news.zdnet.com/2100-1009_22-6142935.html?part=rsstag=feedsubj=zdnn - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Read the reviews
http://www.amazon.com/gp/product/customer-reviews/0833030477/ref=cm_cr_dp_pt/102-8179025-1336125?ie=UTF8n=283155s=books - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
obituary
http://www.boston.com/news/globe/obituaries/articles/2006/10/01/mildred_hayes_78_decoded_russian_messages_for_nsa/ Mildred Hayes, 78; decoded Russian messages for NSA By Joe Holley, Washington Post | October 1, 2006 WASHINGTON -- Mildred Louise Hayes, a retired Russian-language cryptologist with the National Security Agency, died of respiratory failure Sept. 23 at her home in Gulfport, Miss. She was 78. The former resident of Fairfax Station, Va., had lived in Gulfport since 2005. At the National Security Agency, Ms. Hayes was involved with Venona, a computer-created code name for a small, very secret program set up to examine Soviet diplomatic communications. Established in 1943, Venona soon expanded its message traffic to include espionage efforts. The Central Intelligence Agency finally unveiled the project in 1995, 15 years after it ended, hailing it as one of the most significant counterespionage accomplishments of the Cold War. Over the years, the program uncovered information about Soviet efforts to acquire information about US atomic bomb research and the Manhattan Project and about Soviet spy networks in the United States. It led to the unmasking of Klaus Fuchs, the German-born scientist convicted of spying for the Soviets; Julius and Ethel Rosenberg, who were executed for espionage in 1953; and British intelligence officer Kim Philby, who after defecting to Moscow in 1963 admitted that he had been a Soviet spy for two decades. Ms. Hayes was one of the dozens of language teachers and professors, many of them young women, who were recruited by the US Army's Signal Intelligence Service, forerunner to the National Security Agency, to come to Washington and work as code breakers after the Japanese attack on Pearl Harbor. Based at the headquarters of Signal Intelligence at Arlington Hall in Northern Virginia, the Venona cryptanalysts sifted through thousands and thousands of encrypted cable messages from the Soviet Union. Ms. Hayes, who was recruited for the program in 1952, was born in Cisco, Texas. Her father died when she was 6, and when her mother remarried, her stepfather decided he didn't want to raise the girl and her sister, only their little brother. An aunt and uncle in Little Rock took in the two girls. She grew up in Little Rock and received a bachelor's degree in languages from Arkansas State University in 1944. She received a master's degree in Russian language and linguistics from George Washington University in 1980. Her marriage to Paul Hayes ended in divorce. Ms. Hayes leaves a daughter, Sharon Hayes of Gulfport, and a brother. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
de-certification of Open-SSL
Anyone know what is up with this? http://www.gcn.com/online/vol1_no1/41371-1.html --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Interesting bit of a quote
You're talking about entirely different stuff, Lynn, but you are correct that data fusion at IRS and everywhere else is aided and abetted by substantially increased record keeping requirements. Remember, Poindexter's TIA thing did *not* posit new information sources, just fusing existing sources and that alone blew it up politically. As a security matter relevant here, we can't protect un-fused data so fused data is indeed probably worse. On the prove-a-negative area, every time I say this in front of CISO-level audiences I get nodding assent. Ain't making it up, in other words. Innocent until proven guilty seems now to be true in criminal matters; guilty until proven innocent holds sway in the civil arena. On the idea that our version of it is just one of many versions of the same phenomenon in all fields, not just the crypto-security one, today (literally) I was ordered by the State of Rhode Island to install smoke and fire detectors with direct tie-in to the Fire Department in my farm's riding arena (a steel frame building with dirt floor and three doors big enough for a semi). Why? Because the regulators couldn't figure out whether I was a place of assembly or not so, therefore, I must be a place of assembly and my next hearing is whether I need sprinklers. Mind you, klaxons strobes, now required, guarantee killing any non-expert riders who are in the ring when they go off, but since the regulators themselves cannot prove to themselves that they don't have to impose the same requirements as a movie theater, to protect their own asses it is me that has to now prove to them that I am not covered -- which appears to mean getting the Legislature to specifically exempt riding arenas since if that Legislature is silent the regulators will assume the worst and that means their ass versus mine. The core issue here is thus runaway positive feedback loops. When you hold regulators (fire inspectors, financial auditors, whatever) liable for not having proven that their clients cannot have anything wrong (which is why Arthur Anderson went out of business, e.g.), then you get prove-a-negative from the regulators and auditors -- madness on the same scale as tulip mania or the defenestration of Prague. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Interesting bit of a quote
Jerrold,
I can corroborate the quote in that much of SarbOx and
other recent regs very nearly have a guilty unless proven
innocent quality, that banks (especially) and others are
called upon to prove a negative: X {could,did} not happen.
California SB1386 roughly says the same thing: If you cannot
prove that personal information was not spilled, then you
have to act as if it was. About twenty states have followed
California's lead. The surveillance requirements of both
SEC imposed-regulation and NYSE self-regulation seem always
to expand. One of my (Verdasys) own customers failed a
SarbOx audit (by a big four accounting firm) because it
could not, in advance, *prove* that those who could change
the software (sysadmins) were unable in any way to change
the financial numbers and, in parallel, *prove* those who
could change the financial numbers (CFO reports) were
unable to change the software environment.
Jeffrey Ritter, partner in the electronic practice at
(big-name) D.C. law firm Kirkpatrick Lockhart gave the
major address at the annual meeting of the Cyber Security
Industry Alliance recently. In it he said that what he
and his firm tell their (big-name) clients is this:
* That which was not recorded did not happen.
* That which is not documented does not exist.
* That which has not been audited is vulnerable.
and he did not mean this in the paths to invisibility
sense but rather that you have liability unless you can
prove that you don't.
While one can say that this has always been true or that
the insider has always been the real threat, or whatever
variation you like, as a consultant for nearly two decades
the burgeoning prove a negative focus feels unprecedented
to me. And it is not just our field -- today's Boston
newspaper has the State of Massachusetts' building inspectors
being suspended en masse' for refusing en masse' to accept
GPS position tracking as a newly imposed job requirement.
By next summer, every animal in the country is supposed to
be chipped and the owner's home address recorded in GPS
form (google for NAIS) with a requirement to file with
USDA any off premises transportation (taking the kids'
heifer to the the 4H show included).
--dan
===
The great distinction:
A conservative is a socialist who worships order.
A liberal is a socialist who worships safety.
-- Victor Milan', 1999
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Phil Zimmerman and voice encryption; a Skype problem?
Steven M. Bellovin writes: -+-- | .. -- that leaves open the possibility of a | protocol change that implemented some sort of Clipper-like functionality. | A silent change like that would be *very* ominous. | I'm reminded of Adi Shamir's 2004 Turing Award Lecture * Absolutely secure systems do not exist * To halve your vulnerability, you have to double your expenditure * Cryptography is typically bypassed, not penetrated --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NSA knows who you've called.
alan writes: -+-- | | Probably because most Americans believe they are being spied on | anyways. (And have for a very long time.) | Au contraire', it is precisely what, for example, my spouse would say: I live a decent life and have nothing to hide. As this and all security-related lists are composed of people who are off-center when it comes to risk, it is us what be the outliers in the distribution and in no way are our various paranoias widely shared. Not trying to debate the hive mind, etc., --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NSA knows who you've called.
Nick Owen writes: -+--- | ... | Or to teach pollsters to ask the correct questions. | ... All, Mr. Owen is dead-on. Speaking as someone who has had a formal education in statistics including the design of survey instruments, I will say that of all the ways in which it is possible for the dishonest to skew the results of quantitative analysis, survey design is hands down the most vulnerable. You want the numbers to come out your way? Sure, you can manipulate any data set of numbers to lean the direction you want them to lean, but if you control the survey instrument used to collect the raw data in the first place you 0wn the analysis in ways that re-analysis by others cannot erase. Case in point: Allowing those who care about Issue XYZ to self-select whether to take your survey guarantees overweighting the tails of your distribution and in ways that you may not be able to see (such as organized survey takers who talk to each other). Sort of like an Internet-mailing-list, no? --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NSA knows who you've called.
Alan, You and I are in agreement, but how do we get the seemingly (to us) plain truth across to others? I've been trying for a good while now, reaching a point where I'd almost wish for a crisis of some sort as persuasiveness is not working. We are probably well off-topic for this list. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NSA knows who you've called.
alan writes: -+-- | | I guess the big question is one of trust. I cannot see why people | trust the Bush administration. Any time they have been given power | they have abused it or used it to destroy their rivals. | I don't think this has anything to do with any particular administration. As Gilmore would say now (hi, John), don't give any government a power you would not want a despot to have. --dan = What's on my car https://www.protestwarrior.com/store/files/master/democrat_president.gif - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NSA knows who you've called.
Perry E. Metzger writes: -+ | | And a personal note to you all: | | Let me again remind people that if you do not inform your elected | representatives of your displeasure with this sort of thing, | eventually you will not be in a position to inform them of your | displeasure with this sort of thing. | Perry, While I agree with you, the public does not, so far as I can tell, find itself willing to risk insecurity for the benefit of preserving privacy, as this article in today's Boston Globe would tend to confirm. http://www.boston.com/news/nation/articles/2006/05/12/most_put_security_ahead_of_privacy/ Most put security ahead of privacy (By Bruce Mohl, Globe Staff) Mark Jellison, a Verizon customer in Quincy, isn't fazed that his phone company may have turned over his calling records and those of millions of others to the National Security Agency as part of an effort to thwart terrorism. snip --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
MetriCon 1.0
Security Metrics Three of us put together a discussion group; it's grown to 150 over the course of a year. We've now decided to hold an official Workshop. See http://www.securitymetrics.org/content/Wiki.jsp?page=Welcome_blogentry_180406_1 If security metrics are your game, this will be the place. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: fyi: Deniable File System - Rubberhose
OK, I'll say it. This site: http://www.truecrypt.org/ makes me visualize tinfoil hats. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: History and definition of the term 'principal'?
I was manager of development for Project Athena beginning in 1985. Amongst our projects was Kerberos, and, as you know, it was a direct implementation of Needham-Schroeder. Schroeder had been Jerome Saltzer's Ph.D. student and Saltzer was the MIT faculty member in charge of the technical side of Athena, and to whom I reported. The word principal was solidly in place from the moment the Kerberos work began, and comes directly from the work of Saltzer and Schroeder. At least as early as 1975 the term principal was in use in their work; see [1] for my own earliest reference. I suspect it was in place at Project MAC and might thus have some lineage with Multics, but now I am speculating. Needham is sadly gone, but Schroeder and Saltzer are still with us. If it is worth my pursuit of the matter I'll make the time for it, but I now forget why this was asked. If it is curiousity, perhaps the canoe is now far enough upriver. If it is a patent claim or the like and one needs to find the exact wet spot in the ground that the river starts, well, let me know. --dan [1] Proceedings of the IEEE. Vol. 63, No. 9 (September 1975), pp. 1278-1308; Manuscript received October 11, 1974; revised April 17, 1975. Copyright 1975 by J. H. Saltzer. The authors are with Project MAC and the Department of Electrical Engineering and Computer Science, Massachusetts Institute of Technology Cambridge, Mass. 02139. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
Usability should by now be recognized as the key issue for security - namely, if users can't use it, it doesn't actually work. % man gpg | wc -l 1705 % man gpg | grep dry -n, --dry-run Don't make any changes (this is not completely implemented). I rest my case. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: thoughts on one time pads
In our office, we have a shredder that happily takes CDs and is designed to do so. It is noisy and cost $500. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A small editorial about recent events.
Chris Palmer writes: -+-- | | [EMAIL PROTECTED] writes: | You know, as a security person, I say all the time that the greatest | threat is internal threat, not external threat. In my day job, I/we | make surveillance tools to prevent data threat from materializing, and | to quench it if it does anyhow. I tell clients all day every day that | when the opponent can attack location independently, and likely | without self identification, your only choice is pre-emption, which | requires intell, which requires surveillance, which requires listening | posts. | | Are you saying we need to carefully surveil our government and pre-empt | it from attacking us, or that our government should carefully surveil us | and pre-empt us from attacking it? | | And I'm just talking about intellectual property in the Fortune 1000, | not the freaking country. | | Let's hope society as a whole never resembles life inside the Fortune | 1000 too closely. | IF ( I believe what I tell my customers ) THEN ( it applies more broadly than them ) That's all. I do believe what I tell them, and I am certain it is a fundamental truth rather than an advertising slogan. As such, I should (and do) snap to attention and salute it when it appears in other guises in other venues. As to whether you should surveil the government or the other way around, David Brin's book, _The Transparent Society_, and the mountains of commentary it has spawned probably answer the question better than I ever will. As to society looking like the Fortune 1000, I (also) agree that I'd rather it did not, but I look at globalized competition, the first-world's populace that beyond all else wants to be protected/taken care of, and a planet where jihadists and sociopaths have an increasing edge, and I ask myself why I shouldn't imagine that the Fortune 1000 are not anomalies but avatars, that they are merely the first to adopt what we will soon demand as a societal entitlement? The more crowded we get the more controls we have to have to keep the jihadists and sociopaths in their place, the populace protected, and so forth. The Internet is a crowded place in that sense; everyone is your next door neighbor. Personally, I am working on my farming skills as fast as I can and do, in truth, intend to drop out of sight / get off the grid. What some may interpret as apologies for the first or second estate are, at least as I mean them, nothing but an attempt at Real Politik. Hope I'm wrong, but I don't bet against my intuition. Probably a rat hole, --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A small editorial about recent events.
You know, as a security person, I say all the time that the greatest threat is internal threat, not external threat. In my day job, I/we make surveillance tools to prevent data threat from materializing, and to quench it if it does anyhow. I tell clients all day every day that when the opponent can attack location independently, and likely without self identification, your only choice is pre-emption, which requires intell, which requires surveillance, which requires listening posts. And I'm just talking about intellectual property in the Fortune 1000, not the freaking country. --dan, who doesn't like reality any more - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A small editorial about recent events.
Clinton's Asst. A.G. http://www.chicagotribune.com/news/opinion/chi-0512210142dec21,0,3553632.story? coll=chi-newsopinioncommentary-hed Dick Morris http://www.drudgereport.com/flash7.htm --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Clips] Banks Seek Better Online-Security Tools
You know, I'd wonder how many people on this list use or have used online banking. To start the ball rolling, I have not and won't. --dan Cryptography is nothing more than a mathematical framework for discussing the implications of various paranoid delusions. -- Don Alvarez - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Clips] Read two biometrics, get worse results - how it works
RAH, et al., It is true that one can combine two diagnostic tests to a worse effect than either alone, but it is not a foredrawn conclusion. To take a medical example, you screen first with a cheap test that has low/no false negatives then for the remaining positives you screen with a potentially more expensive test that has low/no false positives. There is a whole health policy management literature on this. I reproduce the barest precis of same below, assuming the reader can manage to view it in a fixed width font while respecting my hard carriage returns as writ. --dan cheat sheet on terminology of medical diagnostic testing _ \ the true situation \ \+ - +---+---+--- | | | + | a | b | a+b what the | | | diagnostic +---+---+--- test returns | | | - | c | d | c+d | | | +---+---+--- | | | | a+c | b+d | t true positives a = positive testers who have disease true negatives d = negative testers who are without disease false positives b = positive testers who are without disease false negatives c = negative testers who have disease prevalence (a+c)/t = fraction of population that has disease sensitivity a/(a+c) = what fraction of those with disease test positive specificity d/(b+d) = what fraction of those without disease test negative predictive value positive a/(a+b) = what fraction of positive tests have disease predictive value negative a/(a+b) = what fraction of negative tests are without disease Notes: Information retrieval people know sensitivity as recall and predictive value positive as precision. Screening with a cheap test with high sensitivity then an expensive test with high specificity is often the best (most cost effective) strategy. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: PKI too confusing to prevent phishing, part 28
snipped | | Talking about users as being able only to hold one bit continues an | unfortunate attitude that, if only users weren't so dumb/careless/whatever, | we wouldn't have all these security problems. | | This is an important point. In November, 2003, the Computing Research Association, and the NSF held a sequestered workshop in Virginia to ascertain what Grand Challenges should drive the NSF funding priorities for the ensuing ten years. You can see more on this here[1], but one of the four Grand Challenges was that there be enough advances that one did not have to be an expert to be safe. --dan [1] http://www.cra.org/Activities/grand.challenges/security/home.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Defending users of unprotected login pages with TrustBar 0.4.9.93
Dare I say that the best must not be the enemy of the good? --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: MD5 Collision, Visualised
Ben Laurie wrote: I wrote some code to show the internal state of MD5 during a collision... http://www.shmoo.com/md5-collision.html Cheers, Ben. Ben-- http://www.doxpara.com/md5_anim.gif Thpt ;) (That being said -- I do like your output. Very nice.) --Dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: online MD5 crack database
Perry E. Metzger writes: | | This website has a large database of MD5 hashes of common passwords: | | http://gdataonline.com/ | | Presumably, as storage continues to get cheaper, this sort of thing | will only become easier. | .. | None of this is new -- I'm just noting that the trend continues apace. | In 1985 I was told by an MIT professor with DoD connections and a clearance that certainly no later than 1979 the folks at Fort Meade had every possible BSD password indexed by its /etc/passwd representation. Reversing a password meant to simply look up the /etc/password text on-disk to see what tape it was on and to then read that tape. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
