unsubscribe cypherpunks
unsubscribe cypherpunks
Re: Elngsih (was "")
Interesting idea, but it seems like that would be easy enough to foil. Why not just put the "inner" characters in a canonical order when scanning? (searching via google or another strict keyword-based search engine is another matter) Then you can cheaply match on a single form regardless of how they have permuted the word. I think the existing techniques that I've seen on the binaries channels on usenet and some of the spam I've been getting lately are already more effective. They just inject noise characters and use creative phonetic spellings. Maybe reducing the "words" to an improved soundex-like hash would be a more effective technique for dealing with this issue. Anyone know of any work in this area? (spell-checker research would probably yield the most results) Adam Lydick On Mon, 2003-09-22 at 15:39, Thomas Shaddack wrote: > Could be the l33t sp3ak next generation for the cases when the > communication is monitored by automated tools for keywords. Could foil > both alerting on keywords and keyword searching on intercepted and stored > material (unless the keyword search would look also for all the possible > permutations of the words).
curious about covert channels
Had a random thought and was curious if anyone had an opinion on this: Would message-ID, and other realated mail headers that contain pseudo-random data, make a good covert channel? Eg: instead of choosing a pseudo-random value for the message ID, encrypt a block of data of the same length as the ID with a preshared secret key. Issues that spring to mind: * small, you would need quite a few overt messages to transfer anything sizeable over the covert channel. * Is it possible to tell the difference between pseudo-randomly picked values (typical mail client), encrypted data (depending on algorithm), and real randomness? (I suppose this could make the channel detectable) Thanks, Adam Lydick
Re: idea: brinworld meets the credit card
You might find "facecerts" interesting. http://www.computer.org/proceedings/dcc/1896/18960435.pdf This is more for face-to-face checking, however. For your remote scenario some sort of one-way hash to verify the image might be intersting. It would have to allow for fuzzy matching after hashing (for obvious reasons). I think this just raises the bar a tiny bit though, as an attacker could stalk their victim before stealing their card to get an idea about what appearance to forge. (or capture webcam traffic before lifting the card / identity info) Cheers, Adam Lydick On Tue, 2003-07-08 at 12:16, Major Variola (ret) wrote: > Authentication is "Something you have / know / are." > > A simple plastic credit card + PIN provides the first > two, > including a photo provides the third "something you are". > A face is more often checked than the readily forgable > signature, in live authentication. > > But as cameras become ubiquitous > (e.g., in cell phones) some extra security could be obtained > for *remote* authentication by sending a trusted photo of the > account holder plus a live picture of the card user. > > A picture glued into the card could be forged, but a > smartcard (with more data area than a magstripe) > could include a picture of the account holder, > so a thief has no idea what to look like. But the vendor can > check the encrypted smartcard face to the face on the phone > or webcam. For high-value remote transactions, where you > pay someone to check faces, this might be viable in a few years. > In a few years after that, machines might be able to check faces > more cheaply, as reliably. > > The live face-check with embedded digital photos is already standard > practice > on high-security building-entry cards (and passports?), > with the guard comparing the card-embedded face to the one before him. > Ubiquitous cameras will bring that face-check to remote transactions, > reducing cost due to lower fraud. > > Thoughts?
Re: An attack on paypal --> secure UI for browsers
The faq (see attached) claims that "anyone can write a nexus" and that "users control which nexus(s) run". I certainly didn't see anything that suggests that anyone can force you to run arbitrary code, regardless of who has signed it. I also find it absurd to worry about what code Microsoft is running on your system. If you are running their operating system, you are already running arbitrary code from them. If you install a security or functional patch, you are running arbitrary code from them. How would this be different? My only real concern is that once this becomes widespread, having the correct "nexus" + DRM software installed will be the only way to get play digital media. I have a feeling I won't be playing any of that content from the MythTv box in my living room... AdamL -- http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/news/NGSCB.asp Q: What is the "nexus" component of NGSCB? A: The nexus is a new Windows OS component that will be introduced as part of NGSCB. The nexus, what we used to refer to as a "nub" or "trusted operating root," is essentially the kernel of an isolated software stack that runs alongside the existing software stack. The nexus provides a limited set of APIs and services for applications, including sealed storage and attestation functions. Think of nexus-aware applications as residing in the user mode space of the parallel execution environment and the nexus as residing in the kernel mode space. Anyone can write a nexus for use with nexus-aware systems. The user always has the ultimate authority over what nexuses are allowed to run. Only one nexus at a time will be able to run on a machine. Q: What is the privacy model associated with NGSCB? A: The user is always in control of whether or not nexus-aware technology is enabled on his or her PC and what nexuses have access to specific functions. The technology being developed as part of NGSCB provides a fine-grained access control model that allows users to specify (by hash) whether an individual nexus has the right to invoke a specific security operation. In addition, SSC functions that reveal potentially machine-identifying information, such as the RSA public key, can only be performed once per SSC reset (and the SSC cannot be reset from software; you have to power-cycle the PC). -- Adam Lydick <[EMAIL PROTECTED]>
