February 2006 - cypherpunks-legacy

Fwd: Abridged -> Financial Cryptography Update: Identity on the move II - Microsoft's "Identity Metasystem" TM, R, Passport-redux
by coderman 28 Feb '06

28 Feb '06

user centric identity management is coming. big improvements here but i'm going to dismiss it by saying the InfoCard system is still managed by a huge proprietary code base mired in an ecosystem of vulnerability. the rootkits of the future will simply be hooking into userspace to steal data off the pages you use to communicate over InfoCard secured sessions back to your bank. (see the Haxdoor rootkit as an example of this) ---- https://www.financialcryptography.com/mt/archives/000666.html ... That aside, what is this InfoCard? Well, that's not spelt out in so many words as yet: """ In the client user interface, each of the user's digital identities used within the metasystem is represented by a visual "Information Card" (a.k.a. "InfoCard", the source of this technology's codename). The user selects identities represented by InfoCards to authenticate to participating services. The cards themselves represent references to identity providers that are contacted to produce the needed claim data for an identity when requested, rather than claims data stored on the local machine. Only the claim values actually requested by the relying party are released, rather than all claims that the identity possesses (see Law 2). """ ... Now we come to the user-centric part of the InfoCard system: """ 2.7. Authenticating Users to Sites InfoCards have several key advantages over username/password credentials: * Because no password is typed or sent, by definition, your password can not be stolen or forgotten. * Because authentication is based on unique keys generated for every InfoCard/site pair (unless using a card explicitly designed to enable cross-site collaboration), the keys known by one site are useless for authentication at another, even for the same InfoCard. * Because InfoCards will resupply claim values (for example, name, address, and e-mail address) to relying parties that the user had previously furnished them to, relying parties do not need to store this data between sessions. Retaining less data means that sites have fewer vulnerabilities. (See Law 2.) """ What does that mean? Although it wasn't mentioned there, it turns out that there are two possibilities: Client side key generation and relationship tracking, as well as "provider generated InfoCards" written up elsewhere: """ Under the company's plan, computer users would create some cards for themselves, entering information for logging into Web sites. Other cards would be distributed by identity providers -- such as banks or governmental agencies or online services -- for secure online authentication of a person's identity. To log in to a site, computer users would open the InfoCard program directly, or using Microsoft's Internet Explorer browser, and then click on the card that matches the level of information required by the site. The InfoCard program would then retrieve the necessary credentials from the identity provider, in the form of a secure digital token. The InfoCard program would then transmit the digital token to the site to authenticate the person's identity. """ Obviously the remote provision of InfoCards will depend on buy-in, which is a difficult pill to follow as that means trusting Microsoft in oh so many ways - something they haven't really got to grips with. But then there are also client-generated tokens. Are they useful? If they have client-side key generation and relationship caching, then these are two of the missing links in building a sustainable secure system. See my emphasis further above for a hint on relationship tracking and see Kim Cameron's blogfor this comment: "Cameron: A self-issued one you create yourself." Nyms (as per SSH and SOX) and relationship tracking (again SSH, and these days Trustbar,Petname and recent other suggestions) are strong. These ideas have been around for a decade or more, we call it opportunistic cryptography as a school. Alternatively, notice how the credentials term is slipped in there. That's not how Stefan Brands envisages it (from Identity on the move I - Stefan Brands on user-centric identity management), but they are using his term. What that means is unclear (and see Identity on the move III - some ramblings on "we'll get it right this time, honest injun!" for more). Finally, one last snippet: """ 3.6. Claims != "Trust" A design decision was to factor out trust decisions and not bundle them into the identity metasystem protocols and payloads. Unlike the X.509 PKIX [IETF 05], for example, the metasystem design verifies the cryptography but leaves trust analysis for a higher layer that runs on top of the identity metasystem. """ Hallelujah! Trust is something users do. Crypto systems do claims about relationships.

1 0

The vice president can't handle a gun
by Rubin M. Broussard 28 Feb '06

28 Feb '06

spheroid incometary seeeratosthenes theteletype butcombinate butaudubon indiscreet atwenty mayalumni and acorn maydjakarta tryoctillion andamateurish seebelshazzar somewilt seeturmoil someabsolve somecerebral ,emulate orbamberger theaback aberman notimpolitic try

1 0

Stronger climaxes and orgasms
by Rhea Colvin 28 Feb '06

28 Feb '06

A recent survey showed that 68% of women are unsatisfied with their sexual partners. Of course most of these women would never tell their partner that they are unhappy. Not being able to fully satisfy a woman can result in depression and feelings of inadequacy. Thankfully, men of all ages can now safely and naturally enhance their body and penis anatomy and renew sexual vitality without resorting to dangerous surgery. The all natural proprietary blend of unique herbs found in Maxaman is designed to restore blood flow to your penis, unleash stored testosterone, and heighten sensation by activating the body's natural hormone production and supplying vital nutrients necessary for peak sexual performance. http://ejabcdghimfl.worldwebonline.info/?kflxwqowyejzmmabcdghim

1 0

FAQ: How to subscribe and or contribute to cypherpunks
by coderman 27 Feb '06

27 Feb '06

by popular demand (for some degree of popular that includes a few emails to my inbox seeking additional information :) ::Question:: How do I observe/participate in cypherpunks list discussions? subscription requests consist of a simple text body with the list name and your email address sent to a special email list manager account. a subscribe request typically looks like: "subscribe cypherpunks coderman(a)gmail.com" for example. some popular/common list administration services/hosts are: majordomo(a)jfet.org majordomo(a)al-qaeda.net [ maybe majordomo(a)toad.com ? :P ] a full example just for clarification: ---begin--- To: majordomo(a)jfet.org Subject: subscribe cypherpunks Body: subscribe cypherpunks coderman(a)gmail.com ---end--- ::Question:: what can i do to contribute? anything that would be helpful / interesting to facilitate easier and most useful conversations via this list: - more nodes and more contributors, be that code, design or philosophical tangents of tenuous relation to encryption or privacy. - a public web based subscription interface for users - a RSS/Atom/feed based distribution of list contents - a sister best of / abridged / digest version of list traffic distributed in daily and monthly digests. - write secure code to protect your privacy and facilitate trusted social interactions with your peers and associates. - SEND ADDITIONAL COMMENTS / SUGGESTIONS TO THIS LIST :)

3 4

shape-up
by Mindy C. Mccain 27 Feb '06

27 Feb '06

This is what they said on 60 Minutes, Oprah's show and reports from both the medical and controlled clinical studies: "Turns back aging while burning fat, without dieting or exercise." Forget aging and dieting forever And it's Guaranteed. Boosts your Energy Increases Strength Lose weight without exercise or diets Decreases cellulite Increase lean muscle mass Decreases body fat Decreases wrinkles, sags and loose skin Revitalizes hair and nail growth while restoring natural hair color Improves Sexual Performance Refresh memory, mood and mental energy Sleep soundly and awake more rested Help eliminate stress, fatigue and depression Improved Vision, Speeds injury recovery and helps relieve chronic pain Please visit our website to see the actual reports, learn the facts about this quality health product and view our absolute "satisfaction with results" guarantee. Start here to see info http://di-blue.com or no thanks offlist here http://di-blue.com/?page=rmdl barnettspringfieldcoates a losable some horsehairbreakwater and. A paulinepromcoworker. A devilprestohooligan.mask see abbey be protrudewino or

1 0

Fwd: [cap-talk] Re: [e-lang] Introducing Emily, "...capabilities are useless too..."
by coderman 27 Feb '06

27 Feb '06

forwarding an interesting discussion on the nature of a "secure domain" where key based capabilities can be utilized securely. When you get mired into threat models involving well fundend adversaries using exotic interdiscplinary vulnerability assesment and exploitation the definition of "secure domain" becomes extremely verbose and difficult (some would argue effectively impossible for anyone but large TLA's) given the amount of context required to state security in the exotic threat model with sufficient trust and defense in depth. [exotic threat models == tempest, global active adversary, DoS/attacks expending significant network and real world resources (very wide spectrum attacks at high power), domain specific physical access side channel attacks, etc, etc, etc in an ongoing cycle since we all know these parameters change over time] ---------- Forwarded message ---------- From: Jed at Webstart <donnelley1(a)webstart.com> Date: Feb 27, 2006 11:51 AM Subject: [cap-talk] Re: [e-lang] Introducing Emily, "...capabilities are useless too..." To: Discussion of E and other capability languages <e-lang(a)mail.eros-os.org>, Capability Talk <cap-talk(a)mail.eros-os.org> My main point is #3 below. Please skip down to that if reading time is limited. At 01:53 PM 2/23/2006, Constantine Plotnikov wrote: >David Wagner wrote: > >>Constantine Plotnikov writes: >> >>>This is a good analogy. If you close one door, you have one less >>>door to watch out during program design. >> >>But now I come back to the distinction I was trying to draw between >>unintentional leakage of secrets vs deliberate leakage of secrets. >> >>I agree that there is value in looking for programming language mechanisms >>that reduce the likelihood of unintentional leakage of secrets. But what >>I'm arguing is that there's no point trying to forbid malicious code from >>deliberately leaking secrets. Given the existence of covert channels, you >>probably can't prevent it anyway. "Don't forbid what you can't prevent." #1. While I agree with the difficulties in preventing covert communication, I don't more generally agree with "Don't forbid what you can't prevent", at least in this instance. If confinement is a natural effect of tokenized permission transfers (e.g. via capabilities) where capabilities to objects are bundled with the permission to communicate to the server of whatever object the capability grants access to, then it seems quite natural and effective to include that permission to communicate along with the permission to access the object. It may well be that communication is possible in any case (e.g. via a covert channel), but by bundling it explicitly with a permission to access an object it makes other communication outside that explicitly granted only possible by extraordinary means such as covert channels - which are available in any case. In my opinion it's preferable to explicitly limit such communication rather than simply give up in the face of covert channels and open all communication. I admit that I do find it amusing finding myself on this side of this argument in that the network operating system that I designed and implemented through much of the 1980s (NLTSS, e.g.: http://www.webstart.com/jed/papers/Components/ ) took the opposite position on this issue - arguing that the 'natural' condition of processes is to be able to freely communicate on a general network and that only object access (not the right/permission to communicate) should be limited by capability transfers. At some point I came to accept that I was wrong in taking that approach, I think mostly as a result of dealing with so many situations where limiting communication (e.g. with firewalls) can indeed be useful, even accepting the potential presence of covert channels. I generally feel that covert channels are more of a theoretical than a practical threat, except in cases of dealing with quite sensitive information like classified information or sensitive intellectual property or business information. >There are ways to prevent covert channels in some situations for >some tasks. Examples of mechanisms that can be used to construct a >solution for specific task are: >- scheduled message exchange >- limiting amount of messages >- denying access to timer >- mutually exclusive execution >- isolation (process that is run on separate computer cannot use >memory timing to leak data) >- replay > >If task is not solvable in general, it does not means that it cannot >be solved in some particular case. And if we are solving the problem >in particular case, it is better have some foundation problems like >capability confinement and exception data leaks solved. #2. I won't explicitly address the above means to prevent covert channels except to say that given the history of analysis of covert channels I'm somewhat skeptical of such efforts. One thing I think it's important to keep clear is that the mechanisms that have generally been discussed for covert channels require cooperation on both ends of the channel. No mechanisms that I'm aware of have been demonstrated which 'force' communication from one process into another unwilling recipient (e.g. to access an object without explicit permission). #3. My main reason for writing is to dispute this statement: >Also if we extend your argument, capabilities are useless too, >because capabilites do no limit authority exchange use in presense >of covert channels. If we have bidirectional covert channel, we can >just forward requests to capabilites on other end by proxying. I hope in the above you are meaning that capabilities are useless too <in preventing communication through covert channels> vs. being useless in general. Of course the primary use for capabilities is in explicitly transferring permissions between processes (subjects, active objects, domains, whatever you choose to call active computing entities). One such permission is the permission to communicate which, in the strongest capability systems, always explicitly accompanies any transferred capability. That is, when a capability is transmitted from one process to another the permissions of the capability include the authority to communicate to whatever service provides the explicit permissions granted by the capability. For example, a capability to a file includes permission to communicate to the appropriate file server. However, most permissions explicitly transferred by capabilities are some form of object access beyond the authority to communicate to the object server. While it's true that in the face of covert channels the value of transferring a permission to communicate via a capability (e.g. as above the permission to communicate to a file server) may be somewhat constrained (the process and the file server may be able to communicate in any case via a covert channel), the primary value of the capability in transferring permissions (in the example the permission to access a file, which is not compromised by the presence of covert channels) is still present. Providing confinement in the face of covert channels is indeed a difficult problem. However, I think it's important not to suggest that capability tokenized transfers of permissions have no value simply because one permission, the permission to communicate, is difficult to control (with or without capabilities). Most permissions are not so difficult to control and can be perfectly adequately managed with capabilities. I'm not alone in arguing that tokenizing permissions via capabilities provides many advantages over conveying permissions by other means such as access lists or ambient authority mechanisms (e.g. users/groups and permission bits/configurations for users/groups). These values of capability transfers are not rendered useless simply because covert channels limit the ability of capabilities to also manage the permission to communicate. You (Constantine Plotnikov) may be arguing that a capability infrastructure can't prevent a process from communicating permissions via covert channels (e.g. by proxy). This is true just as one can't prevent data from being communicated via covert channels. However, this is again only dealing with the potential confinement value in capabilities as distinct from what I see as their primary value in providing for transfer of permissions for object access. Covert channels can thwart efforts at confinement, but they cannot thwart efforts to limit object access to those processes which have been explicitly granted access - even if via a covert channel through a proxy means. --Jed http://www.webstart.com/jed/ _______________________________________________ cap-talk mailing list cap-talk(a)mail.eros-os.org http://www.eros-os.org/mailman/listinfo/cap-talk

1 0

hamachi p2p vpn nat-friendly protocol details
by coderman 27 Feb '06

27 Feb '06

--- various interesting forwards related to decentralized (p2p) authenticity and privacy favorite quote: ">> Designing security protocols is hard... Yes, it is. This is why I like it." --- 'Cypherpunks Write [Secure] Code!' An open question for anyone reading this: is the critically wounded, barely beating cypherpunks list languishing in such a sad state due to apathy or impending irrelevance/death? i see embers of life awaiting some minimal votes of confidence (i'd go so far as to offer sexual favors for a toad node back* :) but any kind of renewed interest is meager at best. [would a public list archive help? an rss feed? a abridged list / digest? [ala kernel trap]] such volatile times, so little interest... ---- http://www.mail-archive.com/cryptography@metzdowd.com/msg05790.html "" Alex Pankratov Sun, 26 Feb 2006 07:18:15 -0800 ... Tero Kivinen wrote: >> Travis H. writes: >> > >>>>http://www.hamachi.cc/security >>>> >>>>Based on a cursory look over this, I'm impressed by both the level of >>>>detail and the level of security apparently afforded. Too bad I can't >>>>see the source code. > >> >> >> I can see couple of problems in the system. Firstly it seems it uses >> same key for both directions for the encryption and for >> authentication, i.e. the KEYMAT is only split to Ke and Ka keys, which >> are used for encryption and authentication. In general using same keys >> for different directions is bad. The description on a page was not updated properly. Recent clients use per-direction keys after they complete P2P KE. >> Secondly I cannot find where it >> authenticates the crypto suite used at all (it is not included in the >> signature of the AUTH message). Crypto suite is essentially just a protocol number. It requires no authentication. If the server side responds with HELO.OK, it means that it can comprehend specified protocol revision. Similar to what happens during the SSH handshake. >> Also it seems that the identity itself >> is not authenticated at all, as it (or it's MACed form) is not >> included in the signature. It is not. >> There might be (I am not sure whether AUTH >> packet is encrypted and MACed) a MAC over it, but the MAC key is not >> yet authenticated as it is generated from the anonymous >> Diffie-Hellman. That might give it some protection, but I am not sure >> if that is enough. A protection against what kind of attack ? Identity is used to specify which public key the client wants to be authenticated with on the server side. Assuming it is swapped in transition by a man in the middle, it would still require an attacker to re-sign authentication hash in the message. Assuming he has a private key to do that, he will effectively succeed in authenticating under substituted ID. He then will need to re-sign server's auth hash to complete the attack, which is not going to happen. There is an off chance that the attacker might swapped the identity to one that has the same public key. The chances of this happening are infinitely small unless an attacker also has an access to victim's keypair, which becomes a trivial attack case. . . . >> The protocol is also tied to use SHA1. If you are referring to HMAC-SHA1 for authentication hashes, it is a part of a crypto suite (protocol revision) spec. >> In general it would be much better to use standard protocol, instead >> of generating your own. This is the second revision of Hamachi system. First revision was using SSL for cli-srv and IKE/ESP for p2p security. It was a prototype and it soon become obvious that both SSL and IKE were overkills for our purposes. We did not need certificate authentication of SSL, we did not want to run our own auth protocol over SSL/AnonDH, which would've increased the number of packets per login sequence. We didn't need the flexibility (ie complexity) of IKE either. After stripping down IKE (ie removing SA negotiation, reworking ID payloads and not doing quick mode), we essentially ended up with a protocol that was also fit for securing cli-srv session. It was further tweaked and replaced SSL. I should probably add that I implemented IKE (v1) keying daemon from scratch with all bells and wistles (NATT, extended MODP groups, etc) at some point in the past. Some remnants of it are still floating around, the library name was libike. >> Designing security protocols is hard... Yes, it is. This is why I like it. "" ===== http://www.mail-archive.com/cryptography@metzdowd.com/msg05796.html Travis H. Sun, 26 Feb 2006 07:22:06 -0800 > Crypto suite is essentially just a protocol number. It requires > no authentication. If the server side responds with HELO.OK, it > means that it can comprehend specified protocol revision. Similar > to what happens during the SSH handshake. In SSL, the lack of authentication of the cryptosuite could be used to convince a v3 client that it is communicating with a v2 server, and the v3 server that it is communicating with a v2 client, causing them to communicate using SSL v2, which is called the "version rollback attack". This is not relevant to the hamachi protocol because there is no negotiation. Nevertheless, authenticating the previous plaintext fields once a secure channel is established is considered good form. In Schneier's "Practical Cryptography", he suggests computing the MAC over the entire history of sent messages, which ensures that any tampering is detected at the next MAC. This is eventually what was done in SSLv3, for reasons Tero alluded to and which are successfully thwarted for the reasons you describe. . . . I sort of wonder at the utility of a TCP implementation of the p2p VPN... tunnelling TCP over TCP is well known to be a Bad Thing with regard to interaction of the TCP timeouts. Aside: Can anyone tell me why the constants used in ipad and opad for HMAC were chosen? If they're not arbitrary, I'd like to know the rationale behind them. ===== http://www.mail-archive.com/cryptography@metzdowd.com/msg05801.html Alex Pankratov Sun, 26 Feb 2006 07:24:20 -0800 > Presumably he wants to make sure that the messages like the following > have an unambiguous interpretation: > AUTH Identity Signature(Ni | Nr | Gi | Gr, Kpri_cli) > Merely concatenating them is insufficient unless all but one have a > fixed length. > I think a terse "unambiguous representation" rationale is the whole > reason for ASN.1, although it seems awfully complex for such a simple > goal. Nonces and DH exponents are serialized using PER-style ASN.1 encoding. So the whole concatenation is unambigious. > I sort of wonder at the utility of a TCP implementation of the p2p > VPN... tunnelling TCP over TCP is well known to be a Bad Thing with > regard to interaction of the TCP timeouts. Just to be clear, Hamachi tunnels VPN/P2P traffic over UDP. TCP is used for client-server session only. VPN over TCP is bad for two reasons. One you listed, and another is that it becomes trivial to DoS this kind of VPN. TCP packets are not authenticated (unless MD5/BGP extension is used, which is unlikely), so the state of VPN transport layer and consequently the state of a tunnel can be altered by 3rd party. That's why SSL VPNs make very little sense in non-proxied setups and that's why (I'd guess) OpenVPN 'tweaked' SSL to run over UDP instead. ---end-cut---

1 0

National Security, Secrecy, Diffusion of Responsibility, and Meaningful Accountability
by coderman 27 Feb '06

27 Feb '06

speaking of least privilege, what institution is more deserving of strong least privilege applied to authorization and accountability than a the military-industrial complex and it's government? the current highly classified, highly compartmentalized, broad swath privileges in place right now are akin to giving a company full of employees a single shared account login and trying to apply any kind of oversight and policy restriction. what would a Key KOS government/industry look like? full disclosure of all decisions and resource allocations (and associated delegations involved if any) for all government activities declared in advance and then denied until quorum based consensus as to their reasonableness (?) a fun exercise for thought, as anything you communicate (in any medium/representation) is essentially a social (and thus political) activity... ---cut--- "A Fabric of Illegality" http://www.thenation.com/docprint.mhtml?i=20060313&s=editors Click here to return to the browser-optimized version of this page. This article can be found on the web at http://www.thenation.com/doc/20060313/editors A Fabric of Illegality [from the March 13, 2006 issue] Now we know the truth: For months in 2002, when George W. Bush and his top lieutenants were publicly insisting on their adherence to the Geneva Conventions, they were privately torpedoing efforts by Alberto Mora, the Navy's courageous general counsel, to prevent, and establish accountability for, brutal treatment of detainees. Two years before the publication of the Abu Ghraib photos, Mora confronted the highest-level Pentagon officials over abuse of prisoners at Guantanamo and warned the Administration that its interrogation policies invited torture and cruelty. The New Yorker's Jane Mayer revealed Mora's lonely campaign just as Kofi Annan and a team of United Nations investigators declared Guantanamo a torture camp that should be closed and its prisoners either tried or released. If the Administration has so far been able to resist demands for accountability, whether from the Pentagon's own lawyers or the UN, it is because of the collusion of the courts and Congress in abuses both international and within the United States. Exhibit A: the grotesque February 16 ruling by US District Judge David Trager denying his court's jurisdiction over the rendition to Syria and torture of Canadian national Maher Arar, who spent nearly a year in secret captivity (see David Cole on page 5). Exhibit B: the bipartisan effort to avoid Congressional investigation of the NSA's warrantless surveillance of American citizens. Although key leaders remain angry at the White House for not seeking Congressional approval for the NSA wiretap program, debate over surveillance has been sidelined. Leaders from both parties are lining up behind proposals to bleach the stain of illegality from warrantless wiretaps--either by incorporating warrantless eavesdropping into the Foreign Intelligence Surveillance Act or by simply declaring warrantless taps legal. Lost is the simple fact that both plans broaden domestic spying far beyond the Patriot Act and make hash of the venerable constitutional demand for search warrants. That Guantanamo and NSA spying on citizens--the Administration's abuses abroad and at home--are part of the same fabric of illegality was brought home by a February 14 House national security subcommittee hearing. Led by Christopher Shays and Henry Waxman, the subcommittee heard firsthand evidence of what becomes of truth-tellers in the Bush military and intelligence services. In this sense Mora was lucky: He was merely blocked at every turn. He wasn't demoted like Specialist Samuel Provance, who was kicked downstairs after confronting a general with horrifying details about interrogations at Abu Ghraib. Mora wasn't declared by his bosses to be mentally ill, like NSA whistleblower Russell Tice--who indicated to the subcommittee that the agency's illegal "black ops" extend well beyond the wiretap program. No one spread false rumors about Mora's sex life, as the Defense Intelligence Agency did about Lieut. Col. Anthony Shaffer after he revealed the extent of the government's pre-9/11 knowledge about Mohamed Atta (gained through the "Able Danger" data-mining program). The dark arts of trashing whistleblowers, who are supposedly protected by federal law, add yet another layer of illegality to the "war on terror." Still, Congress and the courts dodge their responsibilities while the White House maintains its right to stand above the law--and torture, imprisonment without trial and warrantless spying on Americans go on, and on. ---end cut---

1 0

Re: [funsec] Re: AT&T's database of 1.92 trillion phone calls (Sprint does it too, and i'm sure they aren't the only ones)
by coderman 27 Feb '06

27 Feb '06

On 2/27/06, Brian Loe <knobdy(a)gmail.com> wrote: > ... > This kind of thing doesn't scare me. What they wind up doing with it, > at times, does scare me. What scares me even more is that no one will > ever do anything about it on a scale that matters. i'd have to agree, with regards to corporate or government entities making strong individual privacy a priority _on their own accord_ with this kind of applied information technology.[1] so the only feasible solution is empowering users to take responsibility for their own information security and privacy. if "johnny can't encrypt"[2] this is a very tall order indeed[3]. what would the ideal minimum amount of information exposed consist of if you could apply usable security/encryption and privacy enhancing technologies to the usual communications today (voice, text, video, data)? - no content of payloads, due to end to end encryption - strong anonymous mix networks for non interactive messaging - weakly anonymous low latency onion/relay networks for near real time messaging - seamless wireless and sneaker net support to offload locally/out of band whenever possible you'd still be exposing: - location of endpoints used (except in the strong and latent mix scenario perhaps) - distinct parties involved (social network analysis) - volume of encrypted traffic exchanged i suppose the real question is how long would it take to design and implement (and the hardware to support it prevalent for all users). 5 years seems extremely optimistic given the difficulties involved. [and i suppose this also means the paranoid will all become proficient TSCM technicians.] ah, we can dream :) until then, the fraction of unusual end lusers making use of strong privacy enhancing technologies will be a function of how annoying they are to use vs. how annoying the government privacy invasion programs become. single digits for the near future... --- [1.] "DoJ strikes back against Google (your privacy concerns are unfounded (lol))" http://www.theinquirer.net/?article=29918 [2.] "NPR : E-Mail Encryption Rare in Everyday Use" http://www.mail-archive.com/cryptography@metzdowd.com/msg05769.html [3.] " User Interaction Design for Secure Systems" http://www.cs.berkeley.edu/~pingster/sec/uid/ MANDATORY REQUIREMENTS:: A. Path of Least Resistance. The most natural way to do any task should also be the most secure way. B. Appropriate Boundaries. The interface should expose, and the system should enforce, distinctions between objects and between actions along boundaries that matter to the user. C. Explicit Authorization. A user's authorities must only be provided to other actors as a result of an explicit user action that is understood to imply granting. D. Visibility. The interface should allow the user to easily review any active actors and authority relationships that would affect security-relevant decisions. E. Revocability. The interface should allow the user to easily revoke authorities that the user has granted, wherever revocation is possible. F. Trusted Path. The interface must provide an unspoofable and faithful communication channel between the user and any entity trusted to manipulate authorities on the user's behalf. G. Identifiability. The interface should enforce that distinct objects and distinct actions have unspoofably identifiable and distinguishable representations.

1 1

Do you want to have a safe rate?
by Zimdi 27 Feb '06

27 Feb '06

It is possible to get a new home-loan even if you are scoring lower than normal. And with some of our programs you can reduce the monthly, and still walk away with some liquidity for your own pocket. Check out our simple and fast programs at http://www.ji91.net/53

1 0