Re: fyi: Storm Worm botnet numbers, via Microsoft
[EMAIL PROTECTED] said: I have two problems with this report. thanks for commenting on it. I pointed to it in order to see what denizens of this list might have to say about it. I'm simply curious. Also, as I'd noted, I haven't really seen any estimates of Storm's extent -- other than that article [0] -- that actually go into any details about how the number is arrived at (however bogus or not the approach might be). Also, I'm personally mostly just curious and have done only modest searches for info. And based on that, I've only come across the (typically) unsubstantiated one or two million zombies [1] to (breathless) maybe /50 million/ out there [2] articles/posts. Firstly, I don't think this is a very representative sampling technique compared to the estimates from security companies. I haven't come across any detailed Storm extent analysis, even with having Google search specific security company sites (e.g. using site:sec-corp.com). So if anyone has pointers to pages (other than the MSFT blog article pointed to in an earlier post) that present a sane and substantiated analysis of Storm extent, please post 'em. Maybe folks don't want to (post 'em or point to 'em)? Are there papers in submission? ;-) If you look at the sample that's being used, Windows machines that have automatic updates turned on, then the typical machine is going to be configured with something like Windows XP SP2 with all available hotfixes and updates applied, in other words the very systems that are (one would hope :-) the *least* likely to be affected by malware. agreed. If you take the rule-of- thumb estimate that's sometimes used on MSDN blogs of 1B Windows machines out there then 2.6M machines is 0.3% of that total. Now this in itself wouldn't be so bad if it was an unbiased sample, but in fact it's probably a rather non-representative 0.3%. ..as compared to the overall population of windows machines, on the Internet, globally. agreed. Although some of the numbers from security companies for infections may be just guesswork, they also use broad sampling across all Windows machines (not just ones with Windows Defender), honeypots, monitoring of botnet traffic patterns, and other methods as well. pointers? So while it's valid to say that this [the Anti-Malware Engineering Team blog post [0]] provides data for Storm on fully patched, up-to-date machines running Windows Defender, I don't think this generalises for all Windows machines. agreed. Secondly, the text completely contradicts the figures given. If the figures really are accurate and not a typo, then 274K machines infected out of 2.6M puts Storm on 10% of Windows PCs, which would make the worldwide infection rate 100M systems, or ten times larger than the previous worst-possible case estimate. a resonably-substantiated worst-case estimate? Because it's only twice as many as the 50M number thrown around in the likes of [2]. But yes, it'd be alarming if there's really 1B windows machines on the Internet (one way or another) and there's a reasonable probability of 10% being Storm zombies. Storm may be big, but it's not *that* big. I think there's something wrong with the figures. Yeah, one hopes so. So, it'd seem to me (tho I'm not a statistician) that if one could get a set of articles wrt Storm extent that say at least something to substantiate how they arrived at the numbers, and then do some back-of-the-envelope calcs, we'd have a better idea of what's going on, at least here in the public domain. I have to believe that there's folks working hard on this given the down-the-road risks, and are just keeping the info close to their collective chest. =JeffH [0] http://blogs.technet.com/antimalware/archive/2007/09/20/storm-drain.aspx [1] http://www.secureworks.com/media/press_releases/20070802-botstorm [2] http://www.neoseeker.com/news/story/7103/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: fyi: Storm Worm botnet numbers, via Microsoft
[EMAIL PROTECTED] said: Detailed analysis of the Storm network, how it works, its size, etc is being activly worked on by several research groups 8^) Storm is nowhere near 50 million nodes and never was. Good. I will be presenting /some/ of this work at Toorcon in San Diego this Saturday: http://www.toorcon.org/2007/event.php?id=38 excellent, how'd it go? Anyone else present on Storm? The presentation is not academic paper quality and takes more of a code-monkey approach to the network. Real (sane and substantiated) numbers, stats, and graphs will be presented. To the best of my knowledge, it will be the first publicly released estimates of the size of the network with actual supporting data and evidence. are your slides now available? =JeffH - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
fyi: Report on Workshop on Next Steps for XML Signature and XML Encryption
of possible interest to some... Scott Cantor and I represented the perspective of xmldsig is broken/mess/complex from some non-trivial number of implementors' perspective, we spec'd 'just sign the blob' in a SAML binding spec recently because of this, perhaps if xmldsig is rev'd these sorts of concerns/approaches should be taken into account, to promote interoperability, and didn't get ignored, interestingly enough. Also, a few other participants explicitly mentioned the streaming use case, which is a key concern in Peter Gutmann's xmldsig critique: http://www.cs.auckland.ac.nz/~pgut001/pubs/xmlsec.txt. As the report described below indicates, there's an effort emerging to charter a W3C working group to rev the xmldsig spec, which might be of interest to various folk. =JeffH Original Message Subject: Report on Workshop on Next Steps for XML Signature and XML Encryption Date: Tue, 23 Oct 2007 19:40:41 +0200 From: Thomas Roessler [EMAIL PROTECTED] To: [EMAIL PROTECTED] On 25 and 26 September 2007, W3C held a Workshop on Next Steps for XML Signature and XML Encryption [1] in Mountain View, CA, USA, hosted by VeriSign. The group has published its summary report [2]. The Workshop report indicates strong interest in additional work on XML security and interest in a Working Group. Attendees identified the areas of highest interest: - Create a basic profile of XML Signature - Review and possibly update the referencing model using xml:id and other mechanisms - Update cryptographic algorithms - Revisit XML canonicalization - Update the transform model. Areas of ongoing and medium interest that were identified are scalable profiling, implementation guidance, key management issues, XKMS, XML 1.1, EXI, and interaction with other security organizations. The Workshop report will serve as input for the deliverable of the XML Security Specification Maintenance Working Group to propose a draft charter for possible follow-up work. To enable discussion among Workshop attendees, Working Group participants, and the broader community, this mailing list, [EMAIL PROTECTED] (public archive [3]), has been created. Participation in the mailing list is open to all interested parties. Current list subscribers include the members of the XML Security Specifications Maintenance Working Group, and workshop participants. If you want to be removed from the list, please let me know. [1] http://www.w3.org/2007/xmlsec/ws/cfp [2] http://www.w3.org/2007/xmlsec/ws/report [3] http://lists.w3.org/Archives/Public/public-xmlsec-discuss/2007Oct/ -- Thomas Roessler, W3C [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
fyi: Colossus in action
BP being Bletchley Park of course. http://www.bletchleypark.org.uk/ =JeffH From: David Hansen [EMAIL PROTECTED] Subject: Colossus in action To: [EMAIL PROTECTED] Organization: Spidacom Limited Just in case anyone is as ill informed as me, I was delighted to read at http://news.bbc.co.uk/1/hi/technology/7094881.stm that the rebuilt Colossus is or is about to be used on a message enciphered on a Lorenz machine and transmitted from Germany. Following the links from that page I see that the message will be intercepted using the radio equipment of the time before the Colossus tries to work out the settings. There will be parallel effort with modern radio equipment and computers. It should be an interesting race. I admire those who had the enthusiasm to rebuild the machine and who had the contacts to get hold of the plans and notes that remained. The last time I took a particular interest in the project, some years ago, they were trying to find the right sort of valve and had just completed the framework for hurtling paper tape round and round. - -- David Hansen, Edinburgh I will *always* explain revoked encryption keys, unless RIP prevents me http://www.opsi.gov.uk/acts/acts2000/00023--e.htm#54 --- Message 2 From: John Wilson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Colossus in action Date: Thu, 15 Nov 2007 14:06:02 + On Nov 15, 2007 9:51 AM, David Hansen [EMAIL PROTECTED] wrote: I admire those who had the enthusiasm to rebuild the machine and who had the contacts to get hold of the plans and notes that remained. The last time I took a particular interest in the project, some years ago, they were trying to find the right sort of valve and had just completed the framework for hurtling paper tape round and round. We visited a couple of weeks ago and I took some snaps of the rebuild project http://flickr.com/photos/tug/sets/72157602953115982/ BP has improved markedly since we last visited (about three years ago). However the guided tours are even worse than ever (our guide remonstrated with passers by for taking whilst he was droning on). Take one of the excellent electronic guides and do your own tour. John Wilson -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Ross Anderson: Searching For Evil
Of possible interest... =JeffH Ross Anderson: Searching For Evil http://youtube.com/watch?v=7WlHhZUayUw Google Tech Talks August 23, 2007 ABSTRACT Computer security has recently imported a lot of ideas from economics, psychology and sociology, leading to fresh insights and new tools. I will describe one thread of research that draws together techniques from fields as diverse as signals intelligence and sociology to search for artificial communities. Evildoers online divide roughly into two categories - those who don't want their websites to be found, such as phishermen, and those who do. The latter category runs from fake escrow sites through dodgy stores to postmodern Ponzi schemes. A few of them buy ads, but many set up fake communities in the hope of having victims driven to their sites for... --- end - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
2008: The year of hack the vote?
2008: The year of hack the vote? http://blogs.zdnet.com/security/?p=753 December 17th, 2007 Posted by Larry Dignan @ 2:12 am The state of Ohio has released a comprehensive study of voting machine security and the report will have you longing for paper. A 334-page PDF report http://www.sos.state.oh.us/sos/info/EVEREST/14-AcademicFinalEVERESTReport.pdf from the Ohio Secretary of State reveals insufficient security, poor implementation of security technology, lax auditing and shoddy software maintenance. The report, which covers voting systems from Election Systems and Software (ESS), Hart InterCivic and Premier Election Solutions formerly known as Diebold, was conducted by Ohio\u2019s EVEREST (Evaluation and Validation of Election-Related Equipment, Standards and Testing) initiative in conjunction with research teams from Penn State, University of Pennsylvania and WebWise Security. The EVEREST report was released Dec. 7 and I found it via Slashdot. Overall, the report really raises questions about election systems. Buffer overflows, leaky encryption, audit problems and firmware issues abound. One machine, the M100, from ESS accepts counterfeit ballots. The Premier AV-TSX allows an unauthenticated user to read or tamper with its memory. The Hart EMS has audit logs that can be erased. In fact, the first 17 pages of the report\u2013essentially the table of contents\u2013is an indictment of these systems. To make matters worse, these machines don\u2019t run constantly. That means malicious software could be planted and not turn up until election time. These machines aren\u2019t patched regularly either. The report is too massive to detail completely here, but at a high level here are the takeaways from the EVEREST report: * Systems uniformly stunk at security and \u201cfailed to adequately address important threats against election data and processes.\u201d * A root cause of these security failures was \u201cpervasive mis-application of security technology.\u201d Standard practices for cryptography, key and password management and security hardware go ignored. * Auditing capabilities are a no show. \u201cIn all systems, the logs of election practices were commonly forgeable or erasable by the principals who they were intended to be monitoring.\u201d Translation: If there\u2019s an attack the lack of auditing means you can\u2019t isolate or recover from the problem. * Software maintenance practices \u201cof the studied systems are deeply flawed.\u201d The EVEREST report calls the election software \u201cfragile.\u201d Why would these machines be so enticing as a target? You could swing an entire election, produce incorrect results, block groups of voters, cast doubt on an election or delay results. And it may not take a brain surgeon to alter these systems. The EVEREST teams reported that they were able to subvert every voting system and not be detected \u201cwithin a few weeks.\u201d Meanwhile, the EVEREST teams found the issues with only limited access since vendors weren\u2019t exactly cooperative (Section 2.4 of the PDF has the details). The researchers say: Any argument that suggests that the attacker will somehow be less capable or knowledgeable than the reviewer teams, or that they will not be able to reverse engineer the systems to expose security flaws is not grounded in fact. As for the attackers, EVEREST ranks the following folks in ascending order of capabilities: * Outsiders have no special access to voting equipment, but could affect equipment to an extent that it is connected to the Internet. All of the systems reviewed run Microsoft Windows and occasionally connect to the Internet. In addition, an attacker could create a counterfeit upgrade disk and mail it to install malware. * Voters have limited and partially supervised access to voting systems while casting a vote. * Poll workers have extensive access to polling place equipment, management terminals before, during and after voting. They can authorize who votes and who doesn\u2019t and opportunities to tamper with equipment abound. * Election officials have extensive access to back-end election systems and voting equipment. Access is only loosely supervised if at all. One possibility: Bad software prompts election officials to \u201ccorrect\u201d results. * Vendor employees have access to the hardware and source code of system during development. Employees may also be on site to assist workers and election officials. \u201cSome vendors use third-party maintenance and election day support whose employees are not tightly regulated,\u201d according to EVEREST. Add it up and any hack the vote opportunities will most likely be an inside job of some sort. The attacks may or may not be detectable. --- end - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography
Storm, Nugache lead dangerous new botnet barrage
Storm, Nugache lead dangerous new botnet barrage By Dennis Fisher, Executive Editor 19 Dec 2007 | SearchSecurity.com http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1286808 ,00.html?track=NL-358ad=614777asrc=EM_NLN_2785475uid=1408222 In early 2006, Dave Dittrich, a senior security engineer and researcher at the University of Washington in Seattle, got a sample of a new strain of malware from a colleague, and began monitoring its activity. The Trojan was a bit lazy at first, making just a few outbound connections. But it quickly became obvious that this was no ordinary piece of malware, because each of the connections was to a peer and not a central command and control server. This was strange behavior for PCs that have been compromised by this type of malware. The members of a distributed network like this typically communicate only with one central machine, called the command and control server. It's a top-down structure; the CC server gives the commands and the compromised PCs carry them out. However, this new network didn't seem to have one CC server that was running the show, and the malware itself couldn't really even be classified as a bot as it didn't make its first IRC connection for more than a month. IRC, or Internet Relay Chat, is the preferred method of communication for botnet controllers. But with this network, in lieu of one CC server, there were a number of peers around the network that were sending out commands and serving as download sites for various pieces of the network. So if one of the peers in the network that the attacker is using to issue commands to the rest of the network is shut down, the attacker could simply begin sending orders through another peer. This made the entire network of compromised PCs equal partners and made the prospect of disabling the network incredibly daunting. As troubling as this new development was, more troubling was the fact that the peers sending out the commands changed on the fly and, as Dittrich watched, various members of the network would drop off botnet, only to reappear days or weeks later. So the shape and size of the botnet was changing almost constantly, with entire branches going dark for extended periods of time and peers jumping from one portion of the network to another seemingly on a whim. And, to add to the pile of bad news, the bots were communicating with each other over an encrypted channel, making it all but impossible to listen in on their conversations. Dittrich, one of the top botnet researchers in the world, has been tracking botnets for close to a decade and has seen it all. But this new piece of malware, which came to be known as Nugache, was a game-changer. With no CC server to target, bots capable of sending encrypted packets and the possibility of any peer on the network suddenly becoming the de facto leader of the botnet, Nugache, Dittrich knew, would be virtually impossible to stop. The authors are making these subtle little changes to keep it under the radar, and they're succeeding, said Dittrich. This is the future of malware and it's not a pretty picture. What it is, is a nightmare: a new breed of malicious software developed, tested and sold by professionals and engineered to change on the fly, adapt to its environment and evade traditional defenses. Nugache, and its more famous cousin, the Storm Trojan, are not simply the next step in the evolution of malware. They represent a major step forward in both the quality of software that malware authors are producing and in the sophistication of their tactics. Although they're often referred to as worms, Storm and Nugache are actually Trojans. The Storm creator, for example, sends out millions of spam messages on a semi-regular basis, each containing a link to content on some remote server, normally disguised in a fake pitch for a penny stock, Viagra or relief for victims of a recent natural disaster. When a user clicks on the link, the attacker's server installs the Storm Trojan on the user's PC and it's off and running. Various worms, viruses, bots and Trojans over the years have had one or two of the features that Storm, Nugache, Rbot and other such programs possess, but none has approached the breadth and depth of their feature sets. Rbot, for example, has more than 100 features that users can choose from when compiling the bot. This means that two different bots compiled from an identical source could have nearly identical feature sets, yet look completely different to an antivirus engine. The creators of these Trojans and bots not only have very strong software development and testing skills, but also clearly know how security vendors operate and how to outmaneuver defenses such as antivirus software, IDS and firewalls, experts say. They know that they simply need to alter their code and the messages carrying it in small ways in order to evade signature-based defenses.
Re: Foibles of user security questions
of possible relevance... Mike Just. Designing and Evaluating Challenge-Question Systems. IEEE SECURITY PRIVACY, 1540-7993/04, SEPTEMBER/OCTOBER 2004. =JeffH - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
fyi: independent contactless card e-money scheme called sQuid (UK)
independent contactless card e-money scheme called sQuid (UK) squidcard.com From:Peter Tomlinson [EMAIL PROTECTED] Subject: Re: Fwd: ID Stronghold To: [EMAIL PROTECTED] Date:Mon, 28 Jan 2008 16:02:51 + Roland Perry wrote: In article [EMAIL PROTECTED], Peter Tomlinson [EMAIL PROTECTED] writes I have yet to find a Paywave enabled retailer. Saw one on Saturday in London - a small newsagent. Although I should perhaps mention that Barclays variously call it OnePulse and OneTouch, and never mention Paywave; just to keep the confusion marketing in top gear. I'm looking for a Mastercard Paypass Is this yet another brand name? (Four and counting...) Does it interoperate with Paywave/OnePulse/OneTouch ? Here is another one: Barclays use the Visa method, which was initially called Visa Wave, and early news of it came out of Singapore. Both methods (Mastercard and Visa) should work through the same terminal, but I don't yet have proof. Then there is a independent contactless card e-money scheme called sQuid just launching (squidcard.com), and they will want to use the same terminals... Peter -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
questions on RFC2631 and DH key agreement
So AFAICT from perusal of RFC2631 Diffie-Hellman Key Agreement Method and
RFC2630 CMS, when one executes a simple DH static profile between two parties,
the only things that really need to go over the wire are each party's public
keys (ya and yb) if { p, q, g, j } are known to both parties. And thus,
Generation of Keying Material is done by each party separately, using the
value of ZZ that each independently calculates, yes? Thus keying material
doesn't cross the wire and risk exposure (among various things).
So if p, q, g are not static, then a simplistic, nominally valid, DH profile
would be to..
a b
-- --
g, p, ya
--- yb
[calculates ZZ] [calculates ZZ]
[calculates keying material][calculates keying material]
. .
. .
. .
..yes?
Other than for b perhaps wanting to verify the correctness of { p, q, g, j }
(group parameter validation), is there any reason to send q ?
thanks,
=JeffH
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: questions on RFC2631 and DH key agreement
Oh, yeah, sorry, your diagram (or whoever drew it) does in fact answer my second question wrt what one needs to send over the wire wrt a simplistic DH profile. Just g, p, and a public key (y). thanks again, =JeffH - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: questions on RFC2631 and DH key agreement
I'd scrawled..
Other than for b perhaps wanting to verify the correctness of { p, q, g,
j } (group parameter validation), is there any reason to send q ?
[EMAIL PROTECTED] replied:
I would actually recommend sending all the public data. This does not take
significant additional space and allows more verification to be performed.
That's what I thought.
BTW, I'm not myself working on something employing a DH exchange -- I'm
analyzing/reviewing something that does.
I would also suggest looking at what exactly the goal is. As written this
provides no authentication just privacy,
Indeed, b could be any entity because it isn't proving possession of any
known-only-to-it information.
and if b uses the same private key
to generate multiple yb the value of b['s private key?] will slowly leak.
Yep, I suspected that too. Thanks.
So, another question or two:
If a purportedly secure protocol employing a nominal DH exchange in order to
establish a shared secret key between a requester and responder, employs
widely known published (on the web) fixed values for g (2) and p (a
purportedly prime 1040 bit number) for many of it's implementations and
runtime invocations, what are the risks its designers are assuming with
respect to the resultant properties of ZZ?
I suspect that many implementations will simply use the equivalent of whatever
rand() function is available to get the bits for their private keys directly,
and will likely not reallocate private keys unless the implementation or
machine are restarted. So if the random number generator has known flaws, then
there may be some predictability in both the public keys and in ZZ, yes?
Additionally there's the previously noted issue with the values of static
private keys slowly leaking.
thanks again,
=JeffH
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: questions on RFC2631 and DH key agreement
Ok thanks, I'm going to risk pedanticism in order to nail things down a bit more rigorously.. ' =JeffH ' [EMAIL PROTECTED] writes: [EMAIL PROTECTED] said: http://www.xml-dev.com/blog/index.php?action=viewtopicid=196 thanks, but that doesn't actually answer my first question. It only documents that a and b (alice and bob) arrive at the ZZ value independently. My question is actually concerning section 2.1.2 Generation of Keying Material in RFC2631. [EMAIL PROTECTED] said: I'm going to approach the answer somewhat differently: Why are you using this mechanism? Are you referring to the above mentioned mechanism of arriving at the ZZ value independently, which is implied in RFC2631? (btw, I am not myself designing anything at this time that uses DH, I'm reviewing/analyzing. I am _not_ reviewing RFC2630/2631 themselves, rather it's a (non-IETF) spec that references 2631) The only reason that it's present in the spec is politics, it being an attempt to avoid the RSA patent. So by the spec you're referring to RFC2631 here? Or are you referring to X9.42? Or something else? Its adoption was severely hampered by the fact that US vendors already had RSA licenses, non-US vendors didn't care (and in any case the patent has now expired, so they care even less), no CA's of note will issue X9.42 certificates, and even if they did almost no S/MIME implementations support it. snippage/ So here, and in the snippage, are you referring to X9.42 itself, or CMS (Cryptographic Message Syntax) ? A few years after the expiry of the RSA patent, the matter was corrected by changing the standard so that vendors were no longer required to even pretend to support X9.42. My comments at the time were: Exactly which standard ? From grepping all RFCs, it seems you're referring to CMS when you say the standard, which has indeed been revised a few times since RFC2630. thanks, =JeffH - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: questions on RFC2631 and DH key agreement
I'd scrawled: If a purportedly secure protocol employing a nominal DH exchange in order to establish a shared secret key between a requester and responder, employs widely known published (on the web) fixed values for g (2) and p (a purportedly prime 1040 bit number) for many of it's implementations and runtime invocations, what are the risks its designers are assuming with respect to the resultant properties of ZZ? Joseph Ashwood graciously replied: It is assuming that the total value of the data protected by those parameters never crosses the cost to break in the information value lifetime. yes. I suspect that many implementations will simply use the equivalent of whatever rand() function is available to get the bits for their private keys directly, Very bad idea, for two reasons, the rand() function does not have sufficient internal state, and the rand() function is far from cryptographically strong. what about just using bytes from /dev/urandom on *nix? and will likely not reallocate private keys unless the implementation or machine are restarted. So if the random number generator has known flaws, then there may be some predictability in both the public keys and in ZZ, yes? All flaws in the private key generator will show in the public key selection, do yes. ^^ so? Additionally there's the previously noted issue with the values of static private keys slowly leaking. Only if the value of p changes, if the value of p remains static, then the private key doesn't leak. Ok, I can see that from ya = g ^ xa mod p ... ya doesn't change if g, xa, and p don't change. A simple proof of this is simple, Eve can easily, and trivially generate any number of public/private key pairs and thereby generate any number of viewable sets to determine the unknown private key. Are you saying here that if p (and g) are static, then one has some opportunity to brute-force guess the private key that some long-running instance is using, if it doesn't otherwise re-allocate said private key from time to time? thanks again, =JeffH - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: questions on RFC2631 and DH key agreement
[EMAIL PROTECTED] said: *nix /dev/urandom should work well, the entropy harvesting is reasonably good, and the mixing/generating are sufficient to keep it from being the weak link. yeah, that's the way it sounds from the man page (on linux). thx. Actually I'm saying that if p and g do not change, then there is no additional leakage of the private key beyond what Eve can compute anyway. ok, gotcha. thanks again, =JeffH - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: questions on RFC2631 and DH key agreement
Thanks Hal. It turns out the supplied default for p is 1024 bit -- I'd previously goofed when using wc on it.. DCF93A0B883972EC0E19989AC5A2CE310E1D37717E8D9571BB7623731866E61EF75A2E27898B057 F9891C2E27A639C3F29B60814581CD3B2CA3986D2683705577D45C2E7E52DC81C7A171876E5CEA7 4B1448BFDFAF18828EFD2519F14E45E3826634AF1949E5B535CC829A483B8A76223E5D490A257F0 5BDFF16F2FB22C583AB =JeffH - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: questions on RFC2631 and DH key agreement
Thanks for your thoughts on this Hal. Quite educational. Jeff Hodges wrote: It turns out the supplied default for p is 1024 bit -- I'd previously goofed when using wc on it.. DCF93A0B883972EC0E19989AC5A2CE310E1D37717E8D9571BB7623731866E61EF75A2E27898B057 F9891C2E27A639C3F29B60814581CD3B2CA3986D2683705577D45C2E7E52DC81C7A171876E5CEA7 4B1448BFDFAF18828EFD2519F14E45E3826634AF1949E5B535CC829A483B8A76223E5D490A257F0 5BDFF16F2FB22C583AB This p is a strong prime, one where (p-1)/2 is also a prime, a good property for a DH modulus. Ok, so what tools did you use to ascertain that? I'm curious. The generator g=2 generates the entire group, which is an OK choice. Same here. But that shouldn't matter, the shared secret should be hashed and/or used as the seed of a PRNG to generate further keys. It is hashed, but isn't used to gen further keys. I'm crafting a review of the full DH exchange in the target spec that I'll post to the list today. The main problem as I said is that 1024 bit moduli are no longer considered sufficiently safe for more than casual purposes. That's what I thought. Particularly with discrete logs that use a widely-shared modulus like the one above, it would not be surprising to see it publicly broken in the next 5-10 years, or perhaps even sooner. And if a public effort can accomplish it in a few years, conservatively we should assume that well funded secret efforts could already succeed today. Yep. thanks again, =JeffH - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: questions on RFC2631 and DH key agreement
I think I already know the answer to this question, but I just want to test my understanding... How wise (in a real-world sense) is it, in a protocol specification, to specify that one simply obtain an ostensibly random value, and then use that value directly as the signature key in, say, an HMAC-based signature, without any further stipulated checking and/or massaging of the value before such use? E.g., here's such a specfication excerpt and is absolutely everything said in the spec wrt obtaining said signature keys: When generating MAC keys, the recommendations in [RFC1750] SHOULD be followed. ... The quality of the protection provided by the MAC depends on the randomness of the shared MAC key, so it is important that an unguessable value be used. How (un)wise is this, in a real-world sense? [yes, I'm aware that using a only a SHOULD here leaves a huge door open compliance-wise, but that's a different issue] thanks, =JeffH - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
fyi: Encrypted laptop poses legal dilemma
From:[EMAIL PROTECTED] (Dewayne Hendricks) Subject: [Dewayne-Net] Encrypted laptop poses legal dilemma To: Dewayne-Net Technology List [EMAIL PROTECTED] Date:Thu, 07 Feb 2008 15:38:22 -0800 [Note: This item comes from reader Randall. DLH] From: Randall [EMAIL PROTECTED] Date: February 7, 2008 1:53:24 PM PST To: David Farber [EMAIL PROTECTED], Dewayne Hendricks [EMAIL PROTECTED] http://news.yahoo.com/s/ap/computer_privacy http://snipurl.com/1z7t0 Encrypted laptop poses legal dilemma By JOHN CURRAN, Associated Press Writer When Sebastien Boucher stopped at the U.S.-Canadian border, agents who inspected his laptop said they found files containing child pornography. But when they tried to examine the images after his arrest, authorities were stymied by a password-protected encryption program. Now Boucher is caught in a cyber-age quandary: The government wants him to give up the password, but doing so could violate his Fifth Amendment right against self-incrimination by revealing the contents of the files. Experts say the case could have broad computer privacy implications for people who cross borders with computers, PDAs and other devices that are subject to inspection. It's a very, very interesting and novel question, and the courts have never really dealt with it, said Lee Tien, an attorney with the Electronic Frontier Foundation, a San Francisco-based group focused on civil liberties in the digital world. For now, the law's on Boucher's side: A federal magistrate here has ruled that forcing Boucher to surrender the password would be unconstitutional. The case began Dec. 17, 2006, when Boucher and his father were stopped at a Derby Line, Vt., checkpoint as they entered the U.S. Boucher, a 30-year-old drywall installer in Derry, N.H., waived his Miranda rights and cooperated with agents, telling them he downloads pornography from news groups and sometimes unknowingly acquires images that contain child pornography. Boucher said he deletes those images when he realizes it, according to an affidavit filed by Immigration and Customs Enforcement. At the border, he helped an agent access the computer for an initial inspection, which revealed files with names such as Two year old being raped during diaper change and pre teen bondage, according to the affidavit. Boucher, a Canadian with U.S. residency, was accused of transporting child pornography in interstate or foreign commerce, which carries up to 20 years in prison. He is free on his own recognizance. The laptop was seized, but when an investigator later tried to access a particular drive, he was thwarted by encryption software from a company called Pretty Good Privacy, or PGP. A grand jury subpoena to force Boucher to reveal the password was quashed by federal Magistrate Jerome Niedermeier on Nov. 29. Producing the password, as if it were a key to a locked container, forces Boucher to produce the contents of his laptop, Niedermeier wrote. The password is not a physical thing. If Boucher knows the password, it only exists in his mind. Niedermeier said a Secret Service computer expert testified that the only way to access Boucher's computer without knowing the password would be to use an automated system that guesses passwords, but that process could take years. The government has appealed the ruling. Neither defense attorney James Budreau nor Vermont U.S. Attorney Thomas Anderson would discuss the charge. This has been the case we've all been expecting, said Michael Froomkin, a professor at the University of Miami School of Law. As encryption grows, it was inevitable there'd be a case where the government wants someone's keys. [snip] -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: questions on RFC2631 and DH key agreement
E.g., here's such a specfication excerpt and is absolutely everything said in the spec wrt obtaining said signature keys: When generating MAC keys, the recommendations in [RFC1750] SHOULD be followed. One point, RFC1750 has been superceded by RFC4086. I'll point that out, thanks. ... The quality of the protection provided by the MAC depends on the randomness of the shared MAC key, so it is important that an unguessable value be used. How (un)wise is this, in a real-world sense? It seems pretty reasonable to me. They are referring to an RFC with lots of good advice about random number generators, and they emphasize that the key value should be unguessable. It's probably out of scope to go into a lot more detail than that. Referring to other standards like RFC1750/4086 is the right way to handle this kind of issue. agreed (thx for the ptr to RFC4880) after doing some further reading and such. RFC4086 covers the notion of mixing functions etc, so the above-quoted SHOULD statement covers those bases. I am the co-author of the OpenPGP Standard, RFC4880. All we say is: The sending OpenPGP generates a random number to be used as a session key for this message only. and * Certain operations in this specification involve the use of random numbers. An appropriate entropy source should be used to generate these numbers (see [RFC4086]). Not all that different in thrust than the spec you are looking at. agreed, thanks again. =JeffH - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
wrt Cold Boot Attacks on Disk Encryption
From:David Farber [EMAIL PROTECTED] Subject: [IP] Cold Boot Attacks on Disk Encryption -- report on To: ip [EMAIL PROTECTED] Date:Thu, 21 Feb 2008 16:25:43 -0500 Begin forwarded message: From: Declan McCullagh [EMAIL PROTECTED] Date: February 21, 2008 3:57:43 PM EST To: [EMAIL PROTECTED] Cc: Jacob Appelbaum [EMAIL PROTECTED] Subject: Re: [IP] Cold Boot Attacks on Disk Encryption Dave, The paper published today makes some pretty strong claims about the vulnerabilities of Microsoft's BitLocker, Apple's FileVault, TrueCrypt, Linux's dm-crypt subsystem, and similar products. So I put the folks behind it to a test. I gave them my MacBook laptop with FileVault turned on, powered up, encrypted swap enabled, and the screen saver locked. They were in fact able to extract the 128-bit AES key; I've put screen snapshots of their FileVault bypass process here: http://www.news.com/2300-1029_3-6230933-1.html And my article with responses from Microsoft, Apple, and PGP is here: http://www.news.com/8301-13578_3-9876060-38.html Bottom line? This is a very nicely done attack. It's going to make us rethink how we handle laptops in sleep mode and servers that use encrypted filesystems (a mail server, for instance). - -Declan Jacob Appelbaum wrote: With all of the discussions that take place daily about laptop seizures, data breech laws and how crypto can often come to the rescue, I thought the readers of IP might be interested in a research project that was released today. We've been working on this for quite some time and are quite proud of the results. Ed Felten wrote about it on Freedom To Tinker this morning: http://www.freedom-to-tinker.com/?p=1257 - --- Archives: http://www.listbox.com/member/archive/247/=now RSS Feed: http://www.listbox.com/member/archive/rss/247/ Powered by Listbox: http://www.listbox.com -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
fyi: Traitor Tracing for Anonymous Attack in AACS Content Protection
From:Adam Barth [EMAIL PROTECTED] Subject: TOMORROW 3 Jun - Hongxia Jin - Traitor Tracing for Anonymous Attack in AACS Content Protection To: [EMAIL PROTECTED] Date:Mon, 02 Jun 2008 18:48:48 -0700 Title: Traitor Tracing for Anonymous Attack in AACS Content Protection Speaker: Hongxia Jin, IBM Almaden Abstract: Broadcast encryption and traitor tracing are two active problems in cryptography community. In this talk I will give an overview on how broadcast encryption and traitor tracing can be used for content protection. My focus of the talk is on tracing traitors for anonymous attack. It is a way to trace the source of unauthorized copies of the content or content encrypting keys when the system is broadcasted. I will give the talk in the context of AACS, the new industry content protection standards for next generation high definition DVDs, It is the first large-scale commercial deployment of a traitor tracing technology. Along the way we have had to solve both practical and theoretical problems that had not been apparent in the literature to date. In this talk I will focus on addressing some of those problems in our process of bringing a theoretical solution to practice. 3 Jun (Tuesday) at 1630 hrs Gates 4B (opposite 490) Stanford Security Seminar on Google Calendar: http://www.google.com/calendar/embed?src=98e49qo62mapd82qi9468tahls%40group.cal endar.google.com - --++**==--++**==--++**==--++**==--++**==--++**==--++**== security-seminar mailing list [EMAIL PROTECTED] https://mailman.stanford.edu/mailman/listinfo/security-seminar -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
fyi: Researchers Hack Biometric Faces
apropos to the biometrics essay in the Jan 2009 crypto-gram: Researchers Hack Biometric Faces slashdot.org/palm/18/09/02/17/216216_1.shtml from the face-off dept. posted by kdawson on 2009-02-18 01:35:00 yahoi sends in news from a week or so back: Vietnamese researchers have cracked the facial recognition technology [1] used for authentication in Lenovo, Asus, and Toshiba laptops in lieu of the standard logon/password. The researchers were able to easily bypass the biometric authentication system built into the laptops by using photos of an authorized user, as well as by presenting multiple phony facial images in brute-force attacks. One of the researchers will demonstrate the hack at Black Hat DC this week. He says the laptop makers should remove the facial biometrics feature from their products because the vulnerability of this technology can't be fixed. [1] http://www.darkreading.com/security/vulnerabilities/showArticle.jhtml;jsess ionid=1TT4XOGIHD2DCQSNDLRSKHSCJUNN2JVN?articleID=213901113 --- end - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
fyi: Accelerating computation with FPGAs
of possible (topical) interest... Stanford EE Computer Systems Colloquium 4:15PM, Wednesday, May 13, 2009 HP Auditorium, Gates Computer Science Building B01 http://ee380.stanford.edu[1] Topic:Accelerating computation with FPGAs with a seismic computation example Speaker: Michael Flynn Maxeler Technologies (and Stanford) About the talk: For many high performance applications the alternative to the multicore rack is to use an accelerator assist to each multicore node. There are a number of instances of these accelerators: GPGPU, Specialized processors (E.G.IBM's Cell) and FPGAs. At Maxeler we've found that the FPGA array technology wins out on performance for most relevant applications. Given the initial area-time-power disadvantage of the FPGA in (say) a custom designed adder this is a surprising result. The sheer magnitude of the available FPGA parallelism overcomes the initial disadvantage. Using Maxeler's FPGA compiler toolkit, it is now feasible to transform a software application into a data flow graph mapped to an unconstrained systolic array. The array structure can be matched to the applications structure and is not constrained to nearest neighbor communications as the FPGA provides a generalized interconnect. As an example we consider modeling problems in seismic data processing. In a typical problem we realize a 2000 node systolic array on 2 FPGA's, each node performing an operation each 4 ns. About the speaker: Michael Flynn is now Professor Emeritus of EE at Stanford. He directed the Architecture and Arithmetic group in CSL for many years. He is now Senior Adviser and Board Chairman at Maxeler. Contact information: Michael J Flynn fl...@maxeler.com[2] Embedded Links: [ 1 ]http://ee380.stanford.edu [ 2 ]mailto:fl...@maxeler.com ABOUT THE COLLOQUIUM: See the Colloquium website, http://ee380.stanford.edu, for scheduled speakers, FAQ, and additional information. Stanford and SCPD students can enroll in EE380 for one unit of credit. Anyone is welcome to attend; talks are webcast live and archived for on-demand viewing over the web. MAILING LIST INFORMATION: This announcement is sent to multiple mailing lists. If you are signed up on our private EE380 list you can remove yourself using the widget at the upper left hand corner of the Colloquium web page. Other lists have other management protocols. ++ | This message was sent via the Stanford Computer Science Department | | colloquium mailing list. | | To be added to, or removed from, the list, please go to: | | https://mailman.stanford.edu/mailman/listinfo/colloq-local-list| | For more info, send an empty message to colloq-requ...@cs.stanford.edu | | For directions to Stanford, see http://www-forum.stanford.edu | +-xcl+ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
TLS/SSL Survey (Ristic/Qualsys) (was: Re: A mighty fortress is our PKI)
Internet SSL Survey 2010 is here! (blog post) http://blog.ivanristic.com/2010/07/internet-ssl-survey-2010-is-here.html Actual report: Qualys Internet SSL Survey 2010 v1.6 (PDF, 3.2 MB) http://blog.ivanristic.com/Qualys_SSL_Labs-State_of_SSL_2010-v1.6.pdf =JeffH - 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?)
A really knowledgeable net-head told me the other day that the problem with SSL/TLS is that it has too many round-trips. In fact, the RTT costs are now more prohibitive than the crypto costs. Yes, although that's a different class of issue from the ones we're trying to address in hasmat and keyassure. these two drafts comprise the approach Adam Langley (of google) is presently pursuing wrt both fast TLS startup (snapstart) and support for NextProtocolNegotiation (during TLS handshake).. http://tools.ietf.org/html/draft-agl-tls-nextprotoneg http://tools.ietf.org/html/draft-agl-tls-snapstart Note that the motivation for draft-agl-tls-nextprotoneg is so-called websockets, which are being worked on in the IETF HYBI (hypertext bidirectional) WG http://datatracker.ietf.org/wg/hybi/ =JeffH - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Overclocking TLS/SSL (was: towards https everywhere and strict transport security)
Peter Gutmann pgut...@cs.auckland.ac.nz asked.. Has anyone published any figures for this, CPU speed vs. network latency vs. delay for crypto and the network? there's this (by Adam Langley).. Overclocking SSL http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html ..but it doesn't appear to have (yet) the experimental results you're curious about. =JeffH - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Wrong Direction on Privacy - using NSLs to obtain communication transactional information
another facet of The Administration's We Hear You efforts.. Wrong Direction on Privacy Susan Landau 2-Aug-2010 http://www.huffingtonpost.com/susan-landau/wrong-direction-on-privac_b_666915.html The White House wants to make it easier for the FBI to get at your email and web browsing records; the plan is to make transactional information surrounding your Internet communications --- the to/from information and the times and dates of those communications --- subject to National Security Letters (NSLs), meaning the FBI could get these records without going through a judge. NSLs were created in 1978 to give FBI investigators an easy way to obtain various business records, including the transactional information of phone records (not the content, which is subject to more stringent protections). The easy part of NSLs is that no courts are involved in issuing an NSL; the bureau does so itself. FBI guidelines require NSLs to be issued only on a written request of an FBI Special Agent in Charge (or other specially delegated senior FBI official), and there are four approval steps in the process. Originally NSLs were to be used against foreign powers and people believed to be their agents. But proving someone was an agent of a foreign power was not all that easy, and NSLs were rarely used. That situation changed with the PATRIOT Act, which allowed NSLs to be used to gather information relevant to international terrorism cases. In an Orwellian touch, under the PATRIOT Act the bureau could require that the recipient of an NSL keep the order secret. NSL numbers shot up; between 2003-2006, the FBI issued 192,000 NSLs. Many were to phone companies. Why is clear; knowing who the bad guys are communicating with leads to untangling plots, often before law enforcement understands exactly what the plot might be. Such appears to be what happened, for example, in the case of Najibullah Zazi, who recently pled guilty to a plot to bomb the New York City subways. At first in the initial aftermath of September 11th, telephone company workers were sharing offices with the FBI Communications Assistance Unit, and many times the required procedures went by the wayside. And instead of NSLs, the FBI begun using exigent letters'' requesting immediate access to telephone records with claims to the phone companies that the appropriate subpoenas were in process. Many times that wasn't true. Sometimes there wasn't even a paper trail for the requests; they were just issued verbally. Dates and other specifics were often missing from the requests, which meant law enforcement got many more months of data than there was need for. Why does this matter? It turns out that communications transactional information is remarkably revelatory. When NSLs were created in 1978, phones were fixed devices, and the information of who was calling whom provided a useful past history of behavior. The information is much richer with mobile devices; knowing who is calling whom, or whose cellphone is repeatedly located in the same cellphone sector as whose, provides invaluable information --- information that is simultaneously remarkably invasive. Transactional data reveals who spends time together, what an organization's structure is, what business or political deals might be occurring. ... snip/ --- end - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
