- cypherpunks-legacy - lists.cpunks.org

Fwd: "Bedazzled" Log-in Method Whitepaper
by Steve Schear 25 Nov '03

25 Nov '03

>"Bedazzled" Log-in Method Whitepaper > >Author: George Hara >(http://www.filematrix.xnet.ro/ideas/whitepapers/login.htm) > > >Introduction >------------ > >Using strings of characters as passwords has always been a security issue >because they are hard to remember and can be stolen by key-loggers or >screen-text harvesters. It will still be an issue for personal computers, >but there is another method available for authentication over the Internet >(where are the highest security concerns). This method involves no special >technologies, but simply a new vision on how to bring existing technologies >together. The method is easier to use than text passwords, but it requires, >from the users, the protection of their personal computers (where they need >text-password log-in and encryption), just as they do now. > >The "Bedazzled" log-in method uses a (public) user name / ID (for example, >the user's email address) and a number of images, called password images, >for authentication. The images have to be generated (by the authentication >service) during the creation of the account for which the authentication >will be later required. Each image is a small, PNG compressed, bulk of >pixels with random colors. The PNG compression is used because a true-color >image is compressed without losses, with a very high rate. In the case of >random images this doesn't help, but, as you'll read below, in the User >images section, this is the best format. > >Each image should contain something like 50 * 50 true-color pixels (24 >bits). This means that the total number of combinations of such a random >image is 24 ^ (50 * 50), that is over 10 ^ 3450. Basically, a particular >case is unbreakable through brute force search. > > >Authentication >-------------- > >The authentication is the classic method: the user is identified by his user >name, and then he is authenticated by comparing all images specified in the >log-in form, with the images stored on the computer which makes the >authentication. If all images are *identical*, and put in the same order (im >age 1 as password 1, image 2 as password 2...), the user is authenticated. >If they are not identical, the user is rejected. > > >Implementation >--------------- > >To make the "Bedazzled" log-in method easy to use, the password images must >be saved on the user's computer, preferably in encrypted files (see file >encryption under WindowsXP, or PGP encrypted drives). > >Since the "Bedazzled" log-in method is supposed to be used over Internet, it >is necessary for the user to be able to drag-and-drop each image onto the >browser, in the log-in form. This way, the log-in form has access to the >password images, and can download them to the authentication server when the >user clicks the "Log-in" button. > >As you can see, the method is very eay to use, but in order to make it even >easier, the log-in form should display a small file browser which should be >used to navigate to the password images (they should all be in the same >directory, for easy user access). The log-in form should save a cookie on >the user's computer in order to automatically open the file browser at the >same location, the next time the user attempts to authenticate himslef. > > >User images >------------ > >There is no need for the images to be random. The user could choose his own >images when he creates an authentication account, being only limited to a >specific file size (like 20 KB / image). He could simply take some images >from his computer and resize them to fit the size limit; the images should >be compressed without loss (preferably in a PNG format), just in case they >are lost but the original bigger images still exist and can be resized again >with the same algorithm (to generate the same password image). > >Another method requires a small program which takes a string of characters >typed by the user, and converts them through a hash algorithm into an >apparently random image. This method makes it possible to recreate the >password images if the user remembers the string of characters, without the >need of storing any information. > > >TEMPEST protection >---------------------- > >First of all, since the user doesn't need to type anything and the password >images don't need to be displayed, the passwords are protected from TEMPEST >atacks. However, the user may need to navigate through his pictures and >choose the correct password images for each log-in form. This would create a >potential security breach. > >The "Bedazzled" log-in method has intrinsic TEMPEST protection to this kind >of breach because when a monitor displays an image, the colors of each pixel >is not displayed exactly as indicated by the bits that make the picture. > >Each monitor has its own way of displaying the image. Besides, users always >alter the image by chaging various parameters of the monitor's image: >brightness, contrast, color balance, color temperature, gamma. > >On the other end of the TEMPEST technology, the "reader" takes a snapshot of >the image displayed by the monitor. This is like making a scan of a print of >a digital image. Though the resulting image looks similar with the original >for the human eye, the binary picture will be quite different. Actually, the >whole "reading" process makes it impossible to detect those minute details >(= changes in colors) of the original image, details that give to the owner >of the original picture a unique way to authenticate himself. > >Another help comes from the fact that when the user navigates through the >images, these are displayed as thumbnails, and thus altered (if the size of >the thumbnail is smaller than the size of the original image). > > >Last Word >----------- > >The "Bedazzled" log-in method makes key-loggers and screen-text harvesters >useless. However, there is still the danger of specially designed viruses >that would look for the password images. The only protection from such >malware I can think of, is for the log-in form to require quite a few >password images, and ask for them (using pictures of the picture order >index) in random order each time the user logs-in. > > >George Hara --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com

1 0

Re: [Mac_crypto] MacOS X (Panther) FileVault
by R. A. Hettinga 25 Nov '03

25 Nov '03

--- begin forwarded text

2 1

RE: e voting (receipts, votebuying, brinworld)
by Trei, Peter 25 Nov '03

25 Nov '03

Tim May [mailto:timcmay@got.net] wrote: >On Nov 25, 2003, at 9:56 AM, Sunder wrote: >> Um, last I checked, phone cameras have really shitty resolution, >> usually >> less than 320x200. Even so, you'd need MUCH higher resolution, say >> 3-5Mpixels to be able to read text on a printout in a picture. >> >> Add focus and aiming issues, and this just won't work unless you carry >> a >> good camera into the booth with you. >1. Vinnie the Votebuyer knows the _layout_ of the ballot. He only needs >to see that the correct box is punched/marked. Or that the screen >version has been checked. I realize you big city types (yes, Tim, Corralitos is big compared to my little burg) have full scale voting booths with curtains (I used the big mechanical machines when I lived in Manhatten), but out here in the sticks, the 'voting booth' is a little standing desk affair with 18 inch privacy shields on 3 sides. If someone tried to take a photo of their ballot in one of those it would be instantly obvious. All I want is a system which is not more easily screwed around with then paper ballots. Have some imagination - you could, for example, set things up so the voter, and only the voter, can see the screen and/or paper receipt while voting, but still make it impossible to use a camera without being detected. Peter

1 0

Re: e voting (receipts, votebuying, brinworld)
by Tim May 25 Nov '03

25 Nov '03

On Nov 25, 2003, at 9:56 AM, Sunder wrote: > Um, last I checked, phone cameras have really shitty resolution, > usually > less than 320x200. Even so, you'd need MUCH higher resolution, say > 3-5Mpixels to be able to read text on a printout in a picture. > > Add focus and aiming issues, and this just won't work unless you carry > a > good camera into the booth with you. > 1. Vinnie the Votebuyer knows the _layout_ of the ballot. He only needs to see that the correct box is punched/marked. Or that the screen version has been checked. Pretty easy to see that "Bush" has been marked instead of "Gore." (For a conventional ballot. For a printed receipt is likely in the extreme that the text will be large, at least for the results.) 2. I don't know about cellphone cameras, but my 1996-vintage one megapixel camera has more than enough resolution, even at the "not so great" setting (about 360 x 500) to pick up text very well. (I used it to snap photos of some things with labels attached, for insurance reasons.) 3. If Vinnie is serious about this votebuying (I'm not even slightly convinced this would happen nationally, for obvious logistical and "who cares?" reasons, plus the inability of Palm Beach Jews to punch a conventional ballot, let alone work a digital camera and send the images to Vinnie), he can provide a camera he knows will do the job. Google shows that as of May 2003 the high-end cellphone cameras use CCDs with 640 x 480. This will become the baseline within a short time, certainly long before any of the "receipt" electronic voting systems are widely deployed. (e.g., this article at <http://www.what-cellphone.com/articles/200305/ 200305_Easy_Snapping.php>) But the resolution of today's very inexpensive digital cameras, and probably those in today's cellphone cameras, is more than enough to handle a ballot or reasonable-font receipt. --Tim May

1 0

Re: Appeals court OKs no-knock warrant as perfectly appropriate
by Freematt357＠aol.com 25 Nov '03

25 Nov '03

In a message dated 11/25/2003 1:23:08 PM Eastern Standard Time, s.schear(a)comcast.net writes: > I know that there have been cases which determined that its illegal to use > an indiscriminate weapon (e.g., a shotgun tied to a door) to deter such > entries, but what about a discriminate, automated, weapon system? By > coupling night vision optics and a video pickup, image recognition > software, a robotic gimbal and an semi-automatic firearm, such a system > could discriminate forced entry situations from more normal entry means, > target intruders and initiate deterrence. What then? > In the 1996 release of the film, "The People vs. Larry Flynt", there is a scene where a warrant is served on Flynt's home. His bedroom typified the ultimate "safe room" where the agents serving the warrant couldn't get in until the room was opened from the inside. Obviously everyone doesn't have the money that Flynt has in order to effectively harden ones house, but you can cheaply and rather effectively improve your haunts to allow more warning. The system you describe would in most jurisdiction still be considered illegal and premeditative. You're better off with passive measures. Regards, Matt-

1 0

Appeals court OKs no-knock warrant as perfectly appropriate
by Declan McCullagh 25 Nov '03

25 Nov '03

UNITED STATES OF AMERICA, Plaintiff-Appellee, v. ROBERT JUNIOR WARDRICK, Defendant-Appellant. No. 02-4494 UNITED STATES COURT OF APPEALS FOR THE FOURTH CIRCUIT September 24, 2003, Argued November 20, 2003, Decided OUTCOME: Defendant's convictions and sentence were affirmed. As Judge Widener has recently recognized, the knock and announce requirement serves three purposes: "(1) protecting the safety of occupants of a dwelling and the police by reducing violence; (2) preventing the destruction of property; and (3) protecting the privacy of occupants." United States v. Dunnock, 295 F.3d 431, 434 (4th Cir. 2002) (quoting Bonner v. Anderson, 81 F.3d 472, 475 (4th Cir. 1996)). We have recognized that, HN6[]under appropriate exigent circumstances, strict compliance with the knock and announce requirement may be excused. United States v. Grogins, 163 F.3d 795, 797 (4th Cir. 1998) (holding no-knock entry justified where officers had reasonable suspicion that entering drug "stash house" would be dangerous and drug dealer frequenting house could not be found elsewhere). When the authorities "have a reasonable suspicion that knocking and announcing their presence ...would be dangerous or futile, or that it would inhibit the effective investigation of []crime by, for example, allowing the destruction of the evidence," an entry without knocking [*13] is justified. Richards, 520 U.S. at 394; see also United States v. Ramirez, 523 U.S. 65, 140 L. Ed. 2d 191, 118 S. Ct. 992 (1998) (upholding no-knock entry where suspect had violent past, access to weapons, and vowed not to do "federal time"). In this situation, the state court judge made a specific determination that the circumstances explained in the Overfield Affidavit justified the issuance of a no-knock search warrant. As the Overfield Affidavit recounts, Wardrick had a violent criminal history, including a battery conviction stemming from resisting arrest. Moreover, the affidavit suggested that Wardrick, a convicted felon, illegally possessed firearms. Indeed, Wardrick had threatened, in the presence of Det. Overfield, that he always carried a loaded gun and that he "never missed." Lastly, Det. Overfield reasonably believed that Wardrick would be present when the warrant was executed. As the Overfield Affidavit reflects, several records indicated that 1808 Division Street was Wardrick's primary residence, and two automobiles registered in his name had been parked outside the residence only days before the search warrant was secured. Based on [*14] our review of the Overfield Affidavit, we agree with the district court that it was reasonable for Det. Overfield and the state court to believe that execution of the search warrant would be dangerous. See Ker v. California, 374 U.S. 23, 40-41 n. 12, 10 L. Ed. 2d 726, 83 S. Ct. 1623 (1963) HN7[](determining lawfulness of entry depends on "what the officers had reason to believe at the time of their entry") (emphasis in original). In such circumstances, the issuance of the no-knock search warrant was justified, and the district court did not err in declining to suppress the evidence on this basis.

2 1

RE: e voting (receipts, votebuying, brinworld)
by Major Variola (ret) 25 Nov '03

25 Nov '03

At 01:04 PM 11/24/03 -0500, Trei, Peter wrote: >Thats not how it works. The idea is that you make your choices on >the machine, and when you lock them in, two things happen: They >are electronically recorded in the device for the normal count, and >also, a paper receipt is printed. The voter checks the receipt to >see if it accurately records his choices, and then is required to >put it in a ballot box retained at the polling site. > >If there's a need for a recount, the paper receipts can be checked. > >I imagine a well designed system might show the paper receipt through >a window, but not let it be handled, to prevent serial fraud. Vinny the Votebuyer pays you if you send a picture of your face adjacent to the committed receipt, even if you can't touch it. Since the voting booth is private, no one can see you do this, even if it were made illegal. (And since phones can store images, jamming the transmission at the booth doesn't work.) You send your picture from the cellphone that took it, along with a paypal account number as a text message. Vinny knows the vote is committed at that point. Vinnie can bin diff compare pix to assure non-duplicates, hires someone (probably offshore :-) to verify its not a quick and dirty photoshop job, and that its a vote for the "right" candidate. Further resisting photoshop, Vinny accepts pictures only during voting hours. Vinny has some kind of front business which could be expected to pay lots of people in bursts --a political polling service that reimburses interviewees would be ideal. On a small scale (coerce your voting age household members) its untraceable. On a medium scale (free drinks if you can show you voted for Caesar) its easy too. On a larger scale you might need confidentiality for the image and traffic analysis resistance. Maybe anon cash. Fundamentally, its just like the analog hole for DRM ---you can't show a human a commit message without the human being able to reproduce it for others. The booths could cycle through fake commit messages for all possible candidates, so that you could take a picture of yourself with a bogus commit message, vote as you will, and still collect. That might be confusing but is a counter. NB: Collect = avoid retribution.

5 5

Re: [mnet-devel] Grid Of Trust -- pre-design (fwd from zooko@zooko.com)
by Eugen Leitl 25 Nov '03

25 Nov '03

----- Forwarded message from Zooko O'Whielacronx <zooko(a)zooko.com> -----

1 0

RE: [Asrg] Re: [Politech] Congress finally poised to vote on anti -spam bill [sp]
by Hallam-Baker, Phillip 25 Nov '03

25 Nov '03

> Especially for domains, it's important to do some validation, > though in the absence of widely-deployed DNSSEC, it's hard to > do automatically. DNSSEC is not happening, blame Randy Bush and the IESG for refusing the working group consensus and imposing their own idea that cannot be deployed. An experimental protocol that increases the volume of data in the .com zone by an order of magnitude (read Gbs of data) is simply unacceptable. We do not need DNSSEC, we just need a notice in the DNS. It would be a relatively easy task to walk the .com zone and dump out a list of all the zones which contain a 'do not spam' TXT property record. This has the secondary advantage that it is not necessary to actualy consult the list, the authoritative information is in DNS. > There's a scalability problem that has to be solved, > which is how to prevent a DOS-by-signing-up-too-many-addresses attack. I do not expect that to be a problem, that would be a problem for the contractor. Limit the number of direct registrations from a particular IP address within a given time interval. It is likely to result in the cost of the system being considerably more than the cost of a couple of mid range servers and some software. This is not a new phenomena. Phill

1 0

polygonal sequences
by Nomen Nescio 25 Nov '03

25 Nov '03

Hello I was trying to find some old references I used to have concerning an idea men tioned in sci.crypt way back. It was Phil Zimmermann I think who mentioned something about a possibly new idea for a new public key scheme. He called it "The cryptographic uses of polygonal sequences" and is found here I think: http://groups.google.com/groups?selm=12044%40ncar.ucar.edu&oe=UTF-8&output=… thanks

1 0