Slashdot Mirror


User: scdeimos

scdeimos's activity in the archive.

Stories
0
Comments
1,581
First seen
Last seen
Profile
(view on slashdot.org)

Comments · 1,581

  1. How did you come-up with a 24bit TFT? on Specs for Sony PSP Handheld · · Score: 1

    Sure, the specs posted at ZDNet (Japanese) say that the graphics core is rendering 24-bit RGBA, but there's no mention of the TFT's colour depth.

    Sony's official media releases (Japanese)/(English) on the PSP are understandably light on specs. Even they skip over the specs of the graphics core chips.

    Unless someone's got a better Sony URL for specs, I'm expecting that the PSP will be released with a 16-bit or 18-bit TFT to keep the costs down.

  2. Not impossible. on Single-Chip NIC Solutions? · · Score: 1

    I just treated it as a matter of subsystems.

    The system core is currently based on a 20MHz PIC which reads and encodes the CCD image data and also controls the position of the pan and tilt sub-micro servos with regular 1.5-2.5ms pulse trains. The frequency of the pulse trains isn't critical (PPM/PCM radio control systems are typically using between 50 and 60 frames per second) so it only needs to update the servos ocassionally. I figured it was a lot easier to use off-the-self servos instead of trying to build my own gear trains and position encoders.

    The system core then only needs to talk to the USB comms hardware. This is currently an FTDI FT232BM which takes care of all the USB interfacing, protocols and packetizing the traffic. I don't need to worry about the USB side of it at all. The core CPU only needs to encapsulate the image and status information into different packet types (packets in the context of my own serial protocol) which are then extracted for use by the application on the Host System which just thinks of the device a serial port.

    Once I've chosen the appropriate 10/100Base-T chip or module, it should be a simple matter to change the core PIC's comms software to provide the status and image information as separate entities, particularly if I go for a module which has a HTTP server built in.

    Hope this helps you with your project, too!

  3. How does this scheme actually improve security? on U.S. Biometric Passports By Late 2004 · · Score: 1

    I fail to see how having a 32k ROM with just my digital photo encrypted in it actually improves passport security, let alone national/international security. Why? Well:

    • Security of Public Key Encryption is only as good as the security of the private key. If the US wants this to be a world standard then the governments of every country in the world will require a copy of the private key so they can issue their own passports. (Which country in their right mind is going to send all of their passport applications to the US to have the US government issue their passports for them?)
    • Governments are fallible because the people in their employ are fallible. It's only a matter of time before non-government entities get a hold of the private key and start making passports for themselves. How this happens will be the only interesting thing: payoffs, extortion, eavesdropping, theft or sheer CPU brute-forcing.
    • The new ROM image can only be used to verify that the person possessing the passport actually looks like the photo in the passport. It doesn't verify their identity. It will still be possible to have John Smith's twin brother, Edgar, use John's passport to get around.
    • Perhaps having additional biometric data, like fingerprints, would improve identity verification, but only so long as the private key is secure.
    • There's no "Terrorist Quotient" built into the data. It's not going to be any more or less likely that Fred J. Smith (or the person using his passport) is a terrorist after this scheme has been introduced.
    • The new passport isn't going to create any new restrictions on access to aircraft crew cabins, baggage areas, munitions facilities, etc. - they will be just as secure/vulnerable.

    After that there's privacy issues:

    • All of this proposed digital data has to be kept somewhere before it gets into the card. How secure is the government database storing this? How long is the data retained before it is erased, if ever? What other uses could it be put to: criminal photo ident matching; driver's licence photo and other data matching; public venue surveillance; etc.
    • These are going to be contactless chips: this implies some kind of RF interface with maybe a 1-3 foot operational radius. Every official device (at airport check-in gates, for example) will require the public key to decrypt and display the ROM data. It's going to be even easier to obtain the public key than the private key. What's to stop XYZ corporation from placing their own RF devices at public places like airports, train stations, bus stations, etc., and using the public key to secretly gather identity information for their own purposes? Get enough idents and you can still sell a *copy* of a digital passport if the buyer still looks like an original passport owner you have on file. Encryption will be meaningless in this context.

    Does this system actually solve any existing security problems? Probably not. What can be done to enhance the proposed identity matching:

    • Include other biometric details, such as height and eye colour. This wouldn't stop the John/Edgar twin scenario, but would make it more difficult to sell passports to look-alikes. Fingerprint encoding would stop both.
    • Use an optical or electro-mechanical interface to the passport chip. This would elliminate the RF tag logger attack mentioned above.
    • Encode valid-to and valid-from dates in the cards with the time span agreed by international standard. eg: 5 years. This would stop someone creating a passport which was valid from 01-Jan-2003 through to 31-Dec-9999 because it could be rejected and red-flagged by the screening hardware.
    • Renew the private keys on a regular basis. eg: Assuming a 5-year life cycle on a passport, changing the private key annually only requires 5, at most 6, public keys in the screening hardware. It's not computationally intensive to try 5 or 6 public keys on a 32k block of data. Presumably the screening hardware will be linked to a central c
  4. Thanks everyone! on Single-Chip NIC Solutions? · · Score: 1

    Thank you to everyone who posted a serious response. There are some really useful suggestions there which I'll assess for my project.

    For those who were curious as to what I'm up to, this particular project is essentially a security monitor using colour CCD module on a gimbal mount driven by sub-micro servos (as you'd use on remote controlled aircraft). This gives it around 270 degrees pan and tilt. The beast is currenlty hooked-up to a host computer using a USB bus.

    The eventual aim is to move this into a self-contained unit on a 10- or 10/100 LAN with a web server built in, serving lossless images (probably .pcx or .png format) up at selectable intervals.

    Unfortunately hanging this from a ceiling with an attached P200 system wouldn't be practical. :)

    And yes, I know Pansonic and Sony have LAN Cameras with superior functionality, but they're also about 10 times the price of this system.

    Thanks again!

  5. Re:Safety on 42-Volt Autos · · Score: 1

    Except that it's current that kills, not voltage.

    Stick your finger on the output needles of a Negative Ion Generator. You'll get a little tingle from a 10,000 volt shock, but it won't kill you.

  6. How to cause spammers legal grief... on AOL Sues Spammers · · Score: 2, Interesting

    A recent Slashdot article, "Super-DMCA" Outlaws Ph.D. Thesis, references a change to Michigan law which outlaws any effort to "... Conceal the existence or place of origin or destination of any telecommunications service." Since (a) SMTP is a telecommunications service and (b) a large proportion of Spam/UCE headers are forged in an effort to hide their source, (c) let's route all the world's SMTP mail through servers located in Michigan.