- cypherpunks - lists.cpunks.org

Brazil and Germany issue joint UN resolution on Digital Privacy
by Griffin Boyce 14 Nov '13

14 Nov '13

In it, they state that they are "deeply concerned" at human rights violations resulting from digital surveillance and the overall trend away from privacy. It's a great read, and I *highly* recommend sharing it with your friends. http://daccess-dds-ny.un.org/doc/UNDOC/GEN/N13/544/07/PDF/N1354407.pdf best, Griffin (please excuse double post, if any) -- Be kind, for everyone you meet is fighting a hard battle. PGP: 0xD9D4CADEE3B67E7AB2C05717E331FD29AE792C97 OTR: saint(a)jabber.ccc.de

4 5

expanded security model (was passwords! (p2) deux)
by brian carroll 13 Nov '13

13 Nov '13

i need to clarify a point that opens up the interpretation of entropy into a realm of information involving people and technology and nature, because in the modeling i am referencing all information must ground to truth in order to be verified or validated as true, and that nature and technology and people who exist 'in truth' are in this way grounded within it, whereas those who are short-circuiting are partly or partially grounded, as this relates to patterns, exchange, and exploits. the realm of concepts, communication, and ideas also are involved as if a mental-dimension for the physicality of information, and to not include this in a security model seems falsely limiting if not allowing or relying upon a state of distortion, to begin with. thus the overall goal here is to account for truth as a basis for entropy in a security context or empirical evaluation... [machine N] patterns <===> patterns [machine 2] previously the above relation was established between two machines that interact and 'exchange' information, in some dimension, knowingly or unknowingly (as if consciously and subconsciously even). (machine N) ===> (machine 2 (machine N)) and if one of these machines *investigates or interrogates* the other, and somehow gains access, it could be thought that in the successful matching of patterns that what it has achieved _validates its model of relation, by default, even if only in a partially grounded framework. thus to distinguish the _belief of how this structural relation is occurring, with its actuality, the actual condition of this relation in terms of its truth. in other words the relation between 'machine 2' and 'machine N' that is achieved as a relation, via the matching of patterns, could be believed to validate the truth of the worldview of machine N, though the pattern match could instead be pT=pT, due to inaccurate modeling or framework. and thus a false perspective could be the relation, yet validate a perception of things, as if accurate, while not grounded in the larger reality. likewise, what can occur is a two-way relation whereby this inaccuracy is accounted for by the entity interacted with, perceived 'known' via such faulty pattern matching, and thus provide or leak information from itself that is in a context of truth, though the tells as if subconscious or unconscious, resulting from a TSCM-like scanning of relational frameworks, that is if 'machine 2' is functioning within grounded truth. (machine N (machine 2)) <=== ((machine N) machine 2') in this way the real exploit is not occurring through granting or gaining access to validate further _inaccurate pattern matching by 'machine N', it is that this entity is leaking unknown information as part of this balancing process, about its hidden state that is insecure due to its not being based in truth, and thus distortion, bias, warping, and skew reveal frameworks and structuring, allowing perspectives to be traced back to originating beliefs and equations within the pseudo-, where a running cosmological constant occurs to make everything onesidedly correct. and in this way, the relation on the left side is in a context of truth, via the errors betraying 'machine N' via its reliance on pseudo-truth and falsity, and the condition on the right side is a false perspective of a relation that establishes and verifies inaccurate pattern matches, false positives, due to a protected limited onesided evaluation *confirming* true belief which is itself not grounded beyond its partialty. (machine N (machine 2)) <===> ((machine N) machine 2') [truth <-----> truth] [pT <-----> pT] in this way, the advantage is with 'machine 2' (that may actually have more patterns or n-dimensionality) yet this imbalance may not be revealed or accounted for, and thus the balancing could appear onesided, as if from oneside data is being extracted while the other remains protected and static behind a given boundary, versus betraying its secrets unintentionally, via this structural, informatic relation (matter/energy) in other words (more complexity..) there could be more going on than believed, in this basic relation, and /appearances/ may not accurately match the reality, and yet this can also be accounted for, in truth, or become a threshold condition enabling camouflage... in this way the roles may be reversed yet not accounted for by the naive, ungrounded, mistaken, or inaccurate 'true believer' observers... such that machine 2 could actually in its truth be 'N' and likewise, 'machine N' in its unchecked falsity could be binary... (machine 2 (machine N)) <===> ((machine 2) machine N') [truth <-----> truth] [pT <-----> pT] in this way, the 'real machine N' could be granted access to unrestricted pattern matching in a subconscious or unaccounted for realm of the ' 'real machine 2', though this condition could begin by the 'real machine 2' trying to continuously exploit 'the realm Machine N' and in this way, the false perspective of the latter (N->2'), allowing the *belief* that the binary view is actually N-potential in its accuracy and scope even while this is ungrounded beyond its own skewed, relativist accounting. thus patterns are verified in pseudo-truth, and in allowing this relation, also enables the inaccuracies to leak about its actual state to align with the greater patterning of the 'real machine N', via automatic grounding or snap-to-fit correlations that occur in their accuracy, vetted and error-corrected, though in parameters unshared by the differing worldviews keeping it abstract, this is the same scenario for 'smartness' versus intelligence... (smartness N (intel 2)) <===> ((smartness N) intel 2') [truth <-----> truth] [pT <-----> pT] when instead the situation in terms of equilibrium, entropy, and exploit tends toward... (smartness 2 (intel N)) <===> ((smartness 2) intel N') [truth <-----> truth] [pT <-----> pT] and as mentioned many times before, any given concept has its validity established within truth, whether the concept of [entropy] or [information] or smartness, intelligence, or whatever. and so just taking it at face (sign) value, does not make that interpretation true simply because it is *believed* to be true. and yet that rigor can be missing in the evaluation process, often a kind of self-corruption accompanying the ungrounded observation and especially true believers who operate within a protected boundary, 'managing' outside influences, and yet in this very interaction, per entropy, they reveal their own state beyond their own accounting for it and control over it, via energy and other relations. [pseudo-truth 2] patterns <===> patterns [truth N] getting to the essence of the structural situation, of relativism versus the empirical accounting for truth, shared and unshared, grounded and ungrounded, and involving both accurate and inaccurate pattern matching and if it is corrected or relied upon in its error, the above model in an context of entropic two-way exchange... (a balancing of the forces if you will...) though through a false perspective, this basic relation could be reversed via tromp-l'oiel effects, such that a masked condition exists and the structural relation is asymmetrical and of masquerade... [pseudo-truth N] patterns <===> patterns [truth 2'] whereby: (pseudo-truth N) ===> ((pseudo-truth N) truth 2') though in this structural imbalance, via the ungrounded condition, it is an unintentional two-way interaction that through this opening allows unintended access to the protected perimeter via this basic exchange... (pseudo-truth N (truth 2)) <=== ((pT N) truth 2') ...in other words, the *appearance* may exist one of a one-way hierarchical exchange where information is being extracted from oneside via an attack or interrogation or biased relation... where pseudo-truth "knows" the state of 'machine 2' from its island viewpoint of relativistic truth... (pseudo-truth N) ===> ((pT N) truth 2') [truth <-----> truth] ...and yet this viewpoint or belief can be _ungrounded, the perception of truth illusory, inaccurate, even while achieving a pattern match verifying and validating its inaccurate, corrupted model of truth. in addition, via transference, the reverse occurs, whereby the observer is theirself effected by the observation and thus 'observed' in the entropic exchange, via structural information that aligns with or is at odds with the given modeling and its parameters of existence, that leak data that compares or contrasts with unknowns and vetted truth and thus can establish and correlate with this truth even while restricted or protected externally, believed inaccessible (even invisible people in other dimensionality betray themselves this way, via allegiance with or hostility to higher truth) (pseudo-truth N) ===> ((pT N) truth 2') "true!" [pT <-----> pT] so what is proposed to occur is that in this biased situation, ungrounded belief can be confirmed and match a pattern (A=A -> B=B) whereby it can verify or validate limitless notions (pseudo-N equivalent) yet that is not accurate or actually true, yet uncorrected and due to protected boundary, allowed to be 'real' within given constraints- for lack of feedback that would challenge the belief system, else to censor or have deception going on that promotes this relation as a false perspective, the setup necessary for the subsequent takedown. (pseudo-truth N (truth 2)) <===> ((pT N) truth 2') [truth <-----> truth] the idea then was that this goes both ways, and the appearance of 'machine 2' within the domain of 'machine 1' may go unrecognized in its hidden and unaccounted for dimensionality that is active within a realm of entropy and information exchange as it ties into energy and matter in terms of patterning and perhaps provides a basis for imagining its intuitive or felt quality, as knowing is accurately grounded and becomes compass and navigational aid, versus ungrounded knowing that leads to being lost and having inaccurate maps and wrong directions and sensibility, at odds with actual nature... (pseudo-truth N (truth 2)) <===> ((pT N) truth 2') the point of seeking to account for this condition of masquerade in terms of its shared and unshared patterning and in terms of its groundedness in relation to empirical truth, is that the situation could *appear* from a given perspective, and within restricted parameters, to validate a given viewpoint while actually existing or operating beyond it, in other parameters and boundaries that remain a protected threshold, that cannot be observed or that goes unrecognized more finite observers, thereby the limit of sensibility, or computability, of patterning, as it relates to what is and what cannot be matched, via its identification, recognition in real terms versus terms of belief that can be in error, inaccurate, unreal, or self-serving to a given bias, predetermined viewpoint, or values that restrict, seek to control, and-or rationalize existence in a too-small framework (in this way, the belief in 'N-awareness' can actually be that of a restricted binary finiteness, where expansion of view and its limitlessness could result from warping, skew, distortion serving falsity than in truth that is expansive... in this way, the boundary folds upon itself, encompasses itself as ideology, creating a false dome and constellations, given enough time) (pseudo-truth N (truth 2)) <===> ((pT N) truth 2') [truth <---> truth] [pT <---> pT] the unintended consequence would be that 'machine 1' betrays and grants access to its inner state via this exchange and interaction, yet unknowingly. and thereby its unaccounted for truth is accessible to another who exists and observes truth, while it may be denied within operational beliefs, (left) thus the leaking of information that balances the interaction, the seeming benefit of onesidedness (right) actually has a hidden cost, a revealing involves via equilibrium and entropy, balancing the exchange. yet the evaluation of data, its parsing and verification, may also not be accurate across this span, and thus 'pseudo-intelligence' could glean factoids that validate ideological beliefs, via relations in masquerade between pT and T, as pT assumes the role of TRUTH and truth related to and perceived as if the 'known' mimic, when in actuality the situation is reversed. (pseudo-truth 2 (truth N)) <===> ((pT 2) truth N) [truth <---> truth] [pT <---> pT] this modeling remains abstract, a story about these dynamics, like a cave diagram seeking to convey the communicative or other aspects of information exchange as symmetry and asymmetry are involved, and how this relates to pattern matching, and resources based in comprehensive pattern evaluations and how this differs between grounded and ungrounded observations and relations by default. (pseudo-truth 2 (truth N)) <===> ((pT 2) truth N) [pT <---> T] [pT <---> T] ...these are the more accurate dynamics, though even moreso: (pseudo-truth 2 (truth N)) <===> ((pT 2) truth N) [pT.2 <---> t.N) [pT.2 <---> t.N) though the appearance may indicate otherwise, from a biased perspective. >>> truth would be moving throughout this system, and the emulation of it (its >>> mask) would likewise be transferred, yet only one version is accurate at >>> the level of verification as truth, while the other validates and relies >>> upon its [signage] instead. this is the fundamental issue of patterns and >>> their connection with truth, in a security context, as related to >>> "information" and quasi-entropy, entropy-as-sign and entropy-as-truth. >>> >> E1335, 42, 812

1 0

re: passwords! (p2)
by brian carroll 13 Nov '13

13 Nov '13

for instance, registration process to access a website could involve something akin to the following... input a word: [mordify] input a image: (choose 1 of 20 icons) -> [sunflowers] input a place: [fort lauderdale] input a number: [3.124] the website could then create the password from this data, such as translating a word between languages, into another character set, then xor'ing various fields together (if grokking the concept), such that when blended, the string would be multicharacterset, perhaps unseen by the user, and then only interfaced via these keywords that could be written down as parameters and not be readily utilized via UI for password management, using the encrypted string itself. in other words; the password would not be: [mordify][sunflower-icon][fort%20lauderdale][3.124] it would be a computation based on those variables, such that, in an impressionist rendering as example: [mord][3][unz][.][for][-]...[fy][4][iconID][whatever] though further, if 'translated' across unicode character sets and alphabets, then perhaps: [морд][3][માટે][.][for][-]...[جو][4][iconID][cibé] and then even this could be further mixed if necessary or helpful in terms of decohering patterns and making the computational stretch the maximum effort per unit of password character space, vs. restricting it to minimum as seems the standard, weakened by the default "rules" Ȉ ͆ ͡ ͤͮ Σ Ж ༎ ༬ ℍ § נ

2 2

The second operating system hiding in every mobile phone
by Eugen Leitl 13 Nov '13

13 Nov '13

http://www.osnews.com/story/27416/The_second_operating_system_hiding_in_eve… The second operating system hiding in every mobile phone posted by Thom Holwerda on Tue 12th Nov 2013 23:06 UTC I've always known this, and I'm sure most of you do too, but we never really talk about it. Every smartphone or other device with mobile communications capability (e.g. 3G or LTE) actually runs not one, but two operating systems. Aside from the operating system that we as end-users see (Android, iOS, PalmOS), it also runs a small operating system that manages everything related to radio. Since this functionality is highly timing-dependent, a real-time operating system is required. This operating system is stored in firmware, and runs on the baseband processor. As far as I know, this baseband RTOS is always entirely proprietary. For instance, the RTOS inside Qualcomm baseband processors (in this specific case, the MSM6280) is called AMSS, built upon their own proprietary REX kernel, and is made up of 69 concurrent tasks, handling everything from USB to GPS. It runs on an ARMv5 processor. The problem here is clear: these baseband processors and the proprietary, closed software they run are poorly understood, as there's no proper peer review. This is actually kind of weird, considering just how important these little bits of software are to the functioning of a modern communication device. You may think these baseband RTOS' are safe and secure, but that's not exactly the case. You may have the most secure mobile operating system in the world, but you're still running a second operating system that is poorly understood, poorly documented, proprietary, and all you have to go on are Qualcomm's Infineon's, and others' blue eyes. The insecurity of baseband software is not by error; it's by design. The standards that govern how these baseband processors and radios work were designed in the '80s, ending up with a complicated codebase written in the '90s - complete with a '90s attitude towards security. For instance, there is barely any exploit mitigation, so exploits are free to run amok. What makes it even worse, is that every baseband processor inherently trusts whatever data it receives from a base station (e.g. in a cell tower). Nothing is checked, everything is automatically trusted. Lastly, the baseband processor is usually the master processor, whereas the application processor (which runs the mobile operating system) is the slave. So, we have a complete operating system, running on an ARM processor, without any exploit mitigation (or only very little of it), which automatically trusts every instruction, piece of code, or data it receives from the base station you're connected to. What could possibly go wrong? With this in mind, security researcher Ralf-Philipp Weinmann of the University of Luxembourg set out to reverse engineer the baseband processor software of both Qualcomm and Infineon, and he easily spotted loads and loads of bugs, scattered all over the place, each and every one of which could lead to exploits - crashing the device, and even allowing the attacker to remotely execute code. Remember: all over the air. One of the exploits he found required nothing more but a 73 byte message to get remote code execution. Over the air. You can do some crazy things with these exploits. For instance, you can turn on auto-answer, using the Hayes command set. This is a command language for modems designed in 1981, and it still works on modern baseband processors found in smartphones today (!). The auto-answer can be made silent and invisible, too. While we can sort-of assume that the base stations in cell towers operated by large carriers are "safe", the fact of the matter is that base stations are becoming a lot cheaper, and are being sold on eBay - and there are even open source base station software packages. Such base stations can be used to target phones. Put a compromised base station in a crowded area - or even a financial district or some other sensitive area - and you can remotely turn on microphones, cameras, place rootkits, place calls/send SMS messages to expensive numbers, and so on. Yes, you can even brick phones permanently. This is a pretty serious issue, but one that you rarely hear about. This is such low-level, complex software that I would guess very few people in the world actually understand everything that's going on here. That complexity is exactly one of the reasons why it's not easy to write your own baseband implementation. The list of standards that describe just GSM is unimaginably long - and that's only GSM. Now you need to add UMTS, HSDPA, and so on, and so forth. And, of course, everything is covered by a ridiculously complex set of patents. To top it all off, communication authorities require baseband software to be certified. Add all this up, and it's easy to see why every cellphone manufacturer just opts for an off-the-shelf baseband processor and associated software. This does mean that each and every feature and smartphone has a piece of software that always runs (when the device is on), but that is essentially a black box. Whenever someone does dive into baseband software, many bugs and issues are found, which raises the question just how long this rather dubious situation can continue. It's kind of a sobering thought that mobile communications, the cornerstone of the modern world in both developed and developing regions, pivots around software that is of dubious quality, poorly understood, entirely proprietary, and wholly insecure by design.

2 1

Fwd: the new 2014 Add-Only Sets
by coderman 13 Nov '13

13 Nov '13

---------- Forwarded message ---------- From: Zooko O'Whielacronx <zookog(a)gmail.com> Date: Tue, Nov 12, 2013 at 11:09 PM Subject: the new 2014 Add-Only Sets To: tahoe-dev <tahoe-dev(a)tahoe-lafs.org> Folks: (This is a copy of https://tahoe-lafs.org/trac/tahoe-lafs/ticket/795#comment:13 .) Here's my rendition of our discussion of add-only sets at the Tahoe-LAFS Summit today. (As usual, I altered and embellished this story significantly while writing it down, and people who were present to witness the original discussion are invited to chime in.) An add-only cap doesn't have to also be a write-only cap. It might be good for some use cases that you can give someone a cap that lets them read the whole set, and add elements into the set, without letting them remove elements or change previously-added elements. It might be good in some other use cases to have an "add-only&write-only" cap, which allows you to add elements into the set but doesn't let you read elements of the set, nor remove nor change previously-added elements. We agreed to focus on the former case for now, because it is easier to design and implement a solution to it. (See #796 for discussion of write-only caps.) We agreed to forget about erasure-coding, which makes an already-confusing problem (how to implement add-only sets without allowing a few malicious servers, adders, or set-repairers to perform rollback attack or selection attack), into a very-confusing problem that exceeded my brain's ability to grapple with it. So, for now, assume that add-only sets don't use erasure-coding at all. Now, the basic design we came up with is like this. I'll explain it in multiple passes of successive refinement of the design. FIRST PASS: DESIGN "0" An authorized adder (someone who holds an add-cap) can generate "elements", which are bytestrings that can be added into the set. (I mispronounced "elements" as "elephants" at one point, and from that point forward the design was expressed in terms of a circus act involving elephants.) Elephants have an identity as well as a value (bytestring), so: aos = DistributedSecureAddOnlySet() aos.add_elephant(b"\xFF"*100) aos.add_elephant(b"\xFF"*100) results in aos containing two elephants, not one, even though each elephant has the same value (the bytestring with one hundred 0xFF bytes in it). aos.add_elephant() generates a random 256-bit nonce to make this elephant different from any other elephant with the same value. I call this "putting a tag on the elephant's ear" — a "tagged elephant" is a value plus a nonce. Even if two elephants are identical twins, they can be distinguished by the unique nonce written on their ear-tags. aos.add_elephant() then puts a digital signature on the tagged-elephant (using the add-only-cap, which contains an Ed25519 private key), and sends a copy of the tagged-elephant to every one of N different servers. Putting a digital signature on a tagged-elephant is called "wrapping a net around it". A reader downloads all the tagged-elephants from all the servers, checks all the signatures, takes the union of the results, and returns the resulting set of elephants. Design "A" relies on at least one of the servers that you reach to save you from rollback or selection attacks. Such a server does this by knowing, and honestly serving up to you, a fresh and complete set of tagged-elephants. “Rollback” is serving you a version of the set that existed at some previous time, so the honest server giving you a copy of the most recent set protects you from rollback attack. “Selection” is omitting some elephants from the set, so the honest server giving you a complete copy of the set protects you from selection attack. SECOND PASS: DESIGN "1" We can extend Design "0" to make it harder for malicious servers to perform selection attacks on readers, even when the reader doesn't reach an honest server who has a complete copy of the most recent set. The unnecessary vulnerability in Design "0" is that each tagged-elephant is signed independently of the other tagged-elephants, so malicious servers can deliver some tagged-elephants to a reader and withhold other tagged-elephants, and the reader will accept the resulting set, thus falling for a selection attack. To reduce this vulnerability, adders will sign all of the current tagged-elephants along with their new tagged-elephant with a single signature. More precisely, let the "identity" of a tagged-elephant be the secure hash of the tagged-elephant (i.e. the secure hash of the nonce concatenated with the value). The signature on a new tagged-elephant covers the identity of that tagged-elephant, concatenated with the identities of all extant tagged-elephants, under a single signature. In circus terms, you add the new tagged-elephant into a pile of tagged-elephants and throw a net over the entire pile, including the new tagged-elephant. Now, malicious servers can't omit any of the older tagged-elephants without also omitting the new tagged-elephant. Readers will not accept the new tagged-elephant unless they also have a copy of all of the other tagged-elephants that were signed with the same signature. This limits the servers's options for selection attacks. THIRD PASS: DESIGN "2" We can refine Design "1" to make it cleaner and more CPU-efficient and network-efficient. This will also lay the groundwork for an efficient network protocol. The unnecessary "dirtiness" in Design "1" is that the digital signatures on older tagged-elephants become extraneous once you add a new digital signature. We have a mass of tagged-elephants, we throw a net over the whole mass, then later when we add a new tagged-elephant to the pile, we throw a new net on top of the new (slightly larger) pile. Now the underlying net has become redundant: once you've verified the signature of the outermost net, there is no need to check the signature of the inner net. In fact, if one implementation checks the signature of the inner net and another implementation does not check it, then a malicious adder colluding with a malicious server could cause the implementations to differ in their results, by putting an invalid net (an invalid signature) topped by a new tagged-elephant with a valid net. (Daira was the one who noticed that issue.) To make this cleaner and more efficient, we will never put a net around a net, and instead we'll keep each tagged-elephant in a box. When you want to add a new tagged-elephant to a set, you rip off and throw away any extant nets, then you put the new tagged-elephant in a box which is nailed on top of the previous topmost box. Then you wrap a net around the new topmost box. "Nailing" box Y on top of box X means taking the secure hash of box X and appending that to box Y (before signing box Y). A "box" is a tagged-elephant concatenated with any number of "nails", each of which is the secure hash of a previous box. (Note that you can sometimes have two or more boxes precariously perched at the top of a stack, when two adders have simultaneously added a box before each saw the other's new box. That's okay — the next time an adder adds a box on top of this stack, he'll nail his new box to each of the previous topmost boxes.) Boxes are a lot more CPU-efficient than nets, and more importantly nobody (neither readers, adders, nor servers) needs to revisit a lower-down box in order to add a new top-most box. Once you nail box Y on top of box X, then you can later add box Z just by taking the hash of box Y, without revisiting box X. Note that we need two different secure hashes here: one is the identity of a tagged-elephant, which is the secure hash of: the nonce concatenated with the value. The other is the hash of the box, which is the secure hash of: the identity of a tagged-elephant concatenated with the hashes of any previous boxes. We need the identity of a tagged-elephant for finding out whether a certain tagged-elephant already exists in a stack (regardless of what position it occupies within that stack), and we need the hash of the box for efficiently verifying that all the tagged-elephants in a stack were approved by an authorized adder. This also leads to the efficient network protocol: an adder can remember (cache) the Directed Acyclic Graph of boxes which a given server previously told the adder about. When the adder wants to add a new tagged-elephant or a set of new tagged-elephants to that server, he can send just the boxes which would be new to that server, assuming that the server hasn't learned anything new since the last time they talked. Readers can do likewise, remembering what each server previously told them about, and asking the server to just tell them about things that are not already covered the topmost box(es) that the reader already knows about. CONCLUSION Okay, that's it! I think Design "2" is a good one. It has good security against rollback or selection attacks by malicious servers (assuming some kind of whitelisting of servers! Which is ticket #467 and is not yet implemented.) And, it doesn't go too far over the top in terms of complexity; it seems more intuitive to me than (my vague memories of) previous attempts to design add-only sets for LAFS. (By the way, there are a few other possible ways to strengthen defenses against rollback attack, which we've previously considered in the context of mutable files, but they probably also apply to add-only sets.) I'm excited about this design being feasible, because I think add-only sets could be a critical building block in valuable use-cases such as secure logging, secure email, secure backup, and more. Regards, Zooko P.S. Thanks to Isis and Mike for showing up today and, when asked what Tahoe-LAFS improvements they were interested in, suggesting add-only sets.

2 1

Re: passwords! (including long passwords with poor entropy)
by coderman 13 Nov '13

13 Nov '13

On Tue, Nov 12, 2013 at 6:08 PM, brian carroll <electromagnetize(a)gmail.com> wrote: >... > yet what if the passwords 'length' were not the issue, such that a 20 > character string (of several number.words with several intermixed > special characters) could still be successfully attacked, given those > limited parameters. this summer oclHashCat-plus got an upgrade (experimental) for support to 64 characters of search space (55 or more depending on algo). obviously this length implies a more intelligent / direct search through the key space, which, if limited to a much smaller character set, becomes practically attack-able... in fact, optimizing the path of a dict cruncher like oclHashCat or Hashkill for best performance against a particular target set is an enjoyable art unto itself ;)

1 0

Fwd: Talk at Paypal on "The Grand Challenge to Kill Passwords for Good"
by Bill Stewart 13 Nov '13

13 Nov '13

This just arrived; seems germane to the discussion, for any of you who are local to Silicon Valley area. >From: "PayPal's TechXploration" <info(a)meetup.com> >Subject: Monday: Join 347 Xplorers at "The Grand Challenge to Kill Passwords > for Good" > >Monday >The Grand Challenge to Kill Passwords for Good >PayPal's TechXploration >Monday, November 18, 2013 >6:00 PM >PayPal Town Hall >2161 North 1st Street San Jose, CA 95131 >Will you attend? >Yes >No >347 Xplorers attending, including: >Max Gorbunov >"Physicist, software developer" >Van Riper >"I work in Google Developer Relations as the >Global Program Manager for Google Developer >Groups: http://developers.google.com/groups/" >Sanjay Shroff >"Sanjay Shroff >http://www.linkedin.com/in/shroffsanjay >http://www.shroff.ca http://www.facebook.com/sanjays..." >Lourdes >"Hi" >Alvin Wang >"hi" >Suyash Joshi >"devloper" >"Our intention is to really obliterate, within a >certain number of years, both passwords and PINs >and see the whole Internetincluding internally >in enterprisessobliterate user IDs and >passwords and PINs from the faace of the planet.â > >Michael Bar... >Learn more >Sponsored by NextSpace San Jose, PayPal and Content Magazine >Follow us! > >Meetup HQ in NYC is hiring! meetup.com/jobs

1 0

re: passwords! (p4)
by brian carroll 13 Nov '13

13 Nov '13

completeness is its own thing... need to mention case of 'partial passwords' where user and site merge into a final password yet the user password cannot be cracked without the hidden variables blended into the final working password that is either static or changing... for instance, a previous example... [морд][3][માટે][.][for][-]...[جو][4][iconID][cibé] what if [iconID] was hidden as to its bit-set size, it could be 1 character space or twelve, and yet it would remain hidden at password entry by the user yet required to gain access. [морд][#][3][###][માટે][.][for][##][-]...[جو][4][##][cibé][#] such that some algorithm processes the input in another framework and if somehow this is processes is not normal or it triggers a particular mechanism, a threshold condition could activate blocking access within the password itself vague, i do not know exactly how it could be engineered such that it would be needed and unseen by the user and yet be able to distinguish the actual user from imitator or hostile attacker, though in this way, the moat/drawbridge mechanism that would be 'missing information' within the structure of the password, such that the STRING in itself, input by the user, is not the password, until it is mixed in with the other piece via the site security. [#|#|x|ம்|7|#|#|#|ன்] in other words, a password could only be partially that of the user, and perhaps this is already how it exists today, though that each variable could be more than a character and this could be a bit-set computation, as an icon/other coordinates are blended together, some data of which is not in the user domain and would remain unknown and beyond the ordinary boundary, inside a further interior realm of protected data, a second security vestibule, in the above case, all the wildcards could be data that is in the password yet zoned for another level of access, such that the administrators must provide the data else that it could also be variable in size and 'timing', such that real-time or other permutive functioning could be rolling, 'living code' that is masked - "unknown", and potentially has a calculative or image-based input that is not visible on the outside, yet also entangled with it. perhaps it is not of classical physics, this, yet why must the password unit be assumed a single static character and not something in movement, existing beyond perception and operating by unknown rules that influences what the actual password is, at any given point or place in time. unique perspective as the basis for a universal security approach (UID) lime, tequila, [#], triple-sec

1 0

[SOT] {FWD} [Dailydave] Don't use vowels in passwords! (fwd)
by J.A. Terranson 13 Nov '13

13 Nov '13

Mildly interesting, for those who have an interest ? //Alif -- Those who make peaceful change impossible, make violent revolution inevitable. An American Spring is coming: one way or another. ---------- Forwarded message ---------- Date: Thu, 7 Nov 2013 14:01:15 -0500 From: William Arbaugh <warbaugh(a)gmail.com> To: dailydave(a)lists.immunityinc.com Subject: [Dailydave] Don't use vowels in passwords! According to the Defense Finance and Accounting Service (DFAS), you shouldn't use vowels in your password! The DFAS web site myinvoice.csd.disa.mil is instituting new password requirements starting tomorrow. The details can be found at the site (if you're willing to read a PDF hosted by DOD that is). DFAS brings us two significant improvements to password/PIN security by forbidding the use of vowels, and requiring that password/PINs be EXACTLY 15 characters long (no more, no less). I'd guess that the first requirement is to prevent people from using dictionary words. The second requirement is probably due to some obscure issue with their use of an Oracle Java front-end. This is from a web site that until recently ( and I believe still does) required the use of IE and Java 6. Logging in use to require clicking through no less than 3-4 security warning pop-ups. _______________________________________________ Dailydave mailing list Dailydave(a)lists.immunityinc.com https://lists.immunityinc.com/mailman/listinfo/dailydave

8 11

re: passwords! (p3)
by brian carroll 13 Nov '13

13 Nov '13

yet another approach, user registration involves time-based parameter, which is based on NIST shared clock set to a particular city or time-zone, minus a mystery variable, which then runs a 'tally' as the password as it has been transmuted via calculation: thus the password is rolling, every changing and cannot be computed as a string because it is never the same (if designed that way, to include rolling variables within a longer bit string)... in this way, example: [var1] = [Pacific Time Zone] minus (skew variable) - "3.14" [var2] = [DAYDATE spelled out] plus (translation) such that ==> [var1]*[var2] (list fool's magic xor goes here) ==> [var1a][var2c][var1b.var2d]...[var1w][var2i] whereby, the entire variable of [var1] and [var2] when combined is *changing* and transforming in real-time, via hidden, unknown clock and date correspondence, though could involve GPS, weather, other variability that is essentially entangled into a living password. in the realm of impossible to crack, in my estimation. any computation that cannot stop time itself in order to run the brute force would be losing time and then it would be purely chance, never less than the odds of trillion to one, or whatever it could be, every attempt no matter how many dictionaries parsed in parallel... this is not a password: [password]

1 0