CyberAbc

Every year since 2008, Apple has released new flagship iPhones in a predictable cadence: on even years we get a new external design; on odd years we get a refinement of the previous year's design with upgraded insides and new hardware features. Apple continues to issue updates in this comfortable, almost leisurely stride even as the Android vendors are releasing new high-end, tentpole products every six months or so. This year is no exception. Apple's iPhone 5S is a tweaked version of the iPhone 5 that retains the same screen and physical dimensions of its predecessor. It swaps out the A6 chip for the faster A7 and adds some features that its predecessors aren't privy to. But the 5S also arrives alongside the iPhone 5C and iOS 7, and taken together the three new products are the biggest overhaul the iPhone line has gotten in years. Our review will take a dive into the most important new features of the 5S, comparing them not just to the iPhone 5 (and thus, the 5C) but also to the iPhone 4Ss that many will be looking to upgrade. Is the phone significant enough that you should run out and get it, or should you wait for the inevitable iPhone 6? Body, build quality, and screen The black iPhone 5 (left) compared to the much lighter "space gray" iPhone 5S (right). Andrew Cunningham Specs at a glance: Apple iPhone 5S Screen 1136×640 4-inch (326PPI) touchscreen OS iOS 7 CPU 1.3GHz Apple A7 RAM 1GB DDR3 GPU "Apple A7 GPU" (likely an Imagination Technologies 6-series variant) Storage 16, 32, or 64GB NAND flash Networking 802.11a/b/g/n, Bluetooth 4.0 Ports Lightning connector, headphone jack Size 4.87" × 2.31" × 0.30" (123.8 × 58.6 × 7.6 mm) Weight 3.95oz (112 g) Battery 1560mAh Starting price $199 with two-year contract, $649 unlocked Other perks Charger, earbuds, Lightning cable The short version: The 5S is a whole lot like an iPhone 5. The long version: This is always the shortest part of the "S" phone reviews. In terms of weight and physical dimensions, the iPhone 5S is every bit the equal of the iPhone 5. It's 0.30 inches thick and weighs 3.95 ounces, which makes it thinner and lighter than many competing (albeit larger-screened) Android phones and also the iPhone 4S models that at least a few people will be upgrading from. What looked sort of awkward and tall last year (at least when compared to previous iPhones) now looks completely familiar. There are a handful of ways to tell a 5S from a 5 at a glance. One is the new Home button, which has been changed to accommodate the fingerprint sensor. Another is the oval cutout to the right of the upgraded camera that shows off the dual-LED flash. If you happen to actually get your hands on one, you may notice that it feels substantially faster than the iPhone 5 as well (and the 5 is definitely not slow). If you're looking for something even more obvious, you can look for the new colors the 5S comes in. The silver-and-white option from last year is still around, but the black model has been replaced with a new, lighter model that Apple calls "space gray." This new color uses aluminum with a lighter anodization than the old black model. While it's difficult to say for sure, it seems like the new color will display scratches and scuffs less readily than the old black model did. And of course there's the gold model, which as we know can prompt people to get a little crazy. The power button on top of the 5S. Andrew Cunningham #The round volume buttons and mute switch on the left side. Andrew Cunningham The headphone jack, speaker grilles, and Lightning port on the bottom of the phone. Andrew Cunningham The SIM tray on the right side. Andrew Cunningham The iPhone 5C, iPhone 5S, and fifth-generation iPod touch stacked on top of one another. Andrew Cunningham Having the same body as last year's phone means it shares the same screen as well, which is a blessing and a curse. The good part is that the 1136×640 326 PPI screen still looks pretty good, especially with the lighter design of iOS 7. The bad part is that the screen has been surpassed in size and density by other phones within its price range. Even if you don't care much for truly big phones like the Galaxy S 4 and HTC One, phones like the Moto X have shown that it's possible to squeeze a larger screen into a body that isn't uncomfortable to hold. Rumors that Apple is testing different screen sizes crop up regularly—if you were hoping for a larger iPhone, you're just going to have to cross your fingers and look toward next year. If you enjoy that the iPhone is a premium device that maintains a relatively small screen size, the 5S will keep you happy. The 5S looks stunted next to the expansive HTC One (center) and Samsung Galaxy S 4 (right). The size you prefer is exactly that—your preference. The look-and-feel of the phone remains the same as last year, but the fingerprint scanner, the camera, and the new internals are the real reason to upgrade. We'll spend the remainder of the review on these new aspects, but if you want to read more about how this phone looks and feels (and how it compares to older models like the iPhone 4 or 4S) our original iPhone 5 review will give you the gist of it. Scanning fingerprints (and other things) with Touch ID The iPhone 5S' fingerprint sensor is embedded in the phone's Home button, which loses the rounded square imprint present on other Home buttons but is otherwise clickable just as it is on any other iOS device. Andrew Cunningham The short version: Touch ID isn't perfect, but it ought to prompt most iPhone users to practice better security. The long version: Even more than the camera or the A7 chip, the iPhone 5S' fingerprint reader is one of the strongest arguments in favor of the new phone. I unlock my phone dozens of times in a normal day, and anything that makes it easier or quicker to do without substantially reducing my security could easily save me a couple of hours in a given month (though definitions of what constitutes a substantial reduction of security will vary from person to person). To use the feature, you must first register each individual finger you'd like to use in the phone's settings, found in the same place where you can set and change your passcode in other iOS devices. The software will walk you through the registration process, which asks that you rest your finger on the sensor repeatedly until it has completed a satisfactory scan of your fingerprint. Once scanned, you can delete and rename your different fingers within the software—if you get mixed up, hold your finger down on the sensor and the listing for that finger will flash briefly to indicate that it recognizes you. You can register up to five different fingers with the software. I find that registering both thumbs and the index finger on my dominant hand covers me in most circumstances, but some recommend using a less-common finger like your pinky or ring finger to reduce the chance of someone opening the phone up with a lifted fingerprint. You can register up to five fingers with Touch ID. These fingerprints are stored in something Apple refers to as a "secure enclave" on board the phone's A7 chip. While Apple doesn't usually like to divulge the specifics of such things, some intelligent speculation says that the "secure enclave" is an implementation of ARM's TrustZone technology. TrustZone as described by ARM calls for separate "Secure" and "Normal" worlds with a barrier between the two that keeps (potentially malicious) user applications from accessing the secure data. At this moment, Touch ID can only be used to unlock the 5S and authenticate App Store and iTunes Store purchases. Apple has provided no API that allows third-party applications access to this data. This is probably for the best, and we honestly don't see Apple opening this up any time soon—remember, this is the same Apple that has yet to issue an API for the two-year-old Siri. Apple won't even let third-party apps use its speedy JavaScript renderer in the name of security. It's fun to speculate about what developers could do with Touch ID if they were allowed access to it, but don't hold your breath. What you register with the software doesn't have to be a finger, strictly speaking. I was able to register my pinkie toe and the heel of my right palm (though my tongue wouldn't register no matter how hard I tried). TechCrunch was able to register a cat's paw (my own cat refused to cooperate). Senior Reviews Editor Lee Hutchinson documented his Touch ID adventures in the video below. He was also able to register a toe as well as his own nose but not a tomato. Many parts of the body can apparently be registered, provided they're large enough to touch the detection ring that surrounds the Home button and triggers the sensor—I'll leave you to figure out how big that makes Lee's nose. Lee also demonstrates the sensor's "sub-epidermal" scanning by registering a banana peel but demonstrating that the phone would only scan the peel and unlock his 5S if his finger was behind it. "More to the point, it would only unlock if the same finger was behind it in roughly the same orientation that it was registered," he noted. Senior Review Editor Lee Hutchinson goes nuts on the iPhone 5S' fingerprint scanner. No matter what I registered, the software remained reassuringly free of false positives. While every now and again one of my fingers would fail to unlock the phone on the first attempt, I would say that 19 out of 20 times the feature works exactly as advertised. So far the only known exploit of the software requires the attacker to create what is essentially an exact replica of your finger, so for now the technology is as secure as any biometric authentication can be. A thief can get into your house with a replica of your house key; it doesn't mean you shouldn't lock your door, but it does mean you should perhaps consider multiple locks. That's something Apple's implementation doesn't let you do just yet. Before we go celebrating the "death of passwords," it's extremely important to talk about the nuances of how Touch ID works. First, you must have a passcode of some sort set to use Touch ID. If you don't use a passcode, the Touch ID options remain grayed out and inaccessible. This is because using Touch ID does not disable or in any way supersede the standard "slide to unlock" function. Even with Touch ID enabled, you can still slide over and put in your passcode just like always. This means that if you already protect your phone with a passcode, Touch ID doesn't make your phone more secure in and of itself. It offers an easier, alternative way to unlock your device, but it doesn't offer a second layer of security or any sort of two-factor authentication option. For my part, what Touch ID did do was make me more comfortable with using a complex passcode to protect my phone. I protected my previous iPhones with a standard four-digit passcode and by turning the "wipe phone after 10 unsuccessful unlock attempts" option on (which we recommended if you're using a simple passcode, since otherwise a determined attacker will eventually be able to input the correct code from one of the 10,000 possible combinations). Previously, a complex passcode was too inconvenient for me to bother with, since it made quickly unlocking my phone too difficult. Now, Touch ID makes it so that you only need to input that passcode in a limited number of scenarios—if your phone has just rebooted, if you haven't unlocked your phone in 48 hours, or if you're trying to change your phone's security settings. The feature really seems to be aimed at the half of iOS 7 users that Apple's Phil Schiller says don't protect their phones with any kind of passcode. The emphasis placed on Touch ID during the phone's first-time setup process and in Apple's promotional materials will hopefully convince some of those people to begin taking any measures at all to protect their devices, and some security is always preferable to no security. For users like me who are already using simple passcodes, Touch ID makes it easier to justify using a complex passcode. Touch ID doesn't increase security all by itself, but it should encourage people to make use of the security options that exist in iOS. Camera performance The iPhone 5S' improved camera and dual-LED flash. Andrew Cunningham The short version: The iPhone 5S' camera is a subtle upgrade over the camera in the 5 and 5C. It generally captures sharper pictures with less noise, and low-light performance is improved, though it can't come near the Lumia 1020's low-light shooting. Burst Mode and Slo-Mo video are entertaining distractions, and the former enables faster HDR shooting. The long version: Apple is sticking with an 8MP camera for the third year in a row, but megapixels are much like MHz in that by themselves they don't tell you a whole lot about image quality. Among the many small tweaks Apple has made to its camera hardware this year, two are particularly significant: first, the imaging sensor has increased in size by 15 percent, meaning that more light can hit the sensor at once. It's using that increased sensor size to make its pixels larger (1.5µm, up from 1.4µm), meaning that each pixel in the 3264×2448 image created by the 5S will actually contain more image data than the same pixel in a 3264×2448 image made by an iPhone 4S or iPhone 5. The second upgrade is the camera's larger f/2.2 aperture, up from f/2.4 in the iPhone 5 and 4S. This will narrow your depth of field ever so slightly compared to the older shooters (i.e., less of your photograph may be in focus at once depending on how near or far away your subject is), but it will also increase the amount of light that can hit the sensor. Both the larger pixels and the larger aperture should improve low-light shooting without negatively impacting most other kinds of shots. What the 5S doesn't have that competing cameras are beginning to implement is true optical image stabilization (OIS), something that is included in the HTC One, LG's G2, and several of the Lumia phones. That feature requires extra hardware that isn't easy to fit into a phone this thin. Apple has attempted to compensate for this in software with its "auto-image stabilization" feature, which takes multiple pictures when you tap the shutter button and combines the sharpest parts of each into a composite photo. Neither OIS nor Apple's software approximation of the feature is going to rid your photo library of blurry action shots, but they each seem to combat the motion of the camera as you tap the shutter button equally well. Apple's OIS equivalent requires a camera that can take photos very quickly, and that's where Burst Mode comes in. The feature, invoked by holding down on the shutter button, takes 10 photos a second until you take your finger off the button. The software groups all photos taken during a Burst Mode session into one group within the Photos app to prevent it from spamming your camera roll with near-identical shots. You can dive in and pick the ones you'd like to keep to break them out from the group. Apple has an algorithm that chooses what it thinks is the "best" shot out of all of them and offers it to you first, but in my usage I didn't usually find myself agreeing. One other side-effect of the camera's speedy performance is that taking HDR photos happens near-instantaneously now, an especially noticeable upgrade if you're coming from a 4S. If you take an HDR photo with the 4S, there's an approximately 2.42 second lag before the Camera app will let you take another one. Compare that to about 1.36 seconds in the iPhone 5 and 5C and 0.87 seconds in the iPhone 5S. It's not quite the real-time HDR promised by chips like Nvidia's Tegra 4, but for most people it will be close enough that it won't make a difference. Senior Reviews Editor Lee Hutchinson gets slow with Slo-mo video capture mode. Note that while Lee has replaced the videos' native sound with the smooth sounds of royalty-free music, Slo-mo videos right off the phone also include slow-motion sound from the nightmare dimension. Finally, there's the new camera's video shooting. Like the iPhone 5 and 5C, the iPhone 5S can shoot stabilized 1080p video at 30 FPS, though Apple claims that the video stabilization in the 5S is "improved" compared to the same feature in the iPhone 5. The more entertaining new option is the Slo-mo mode, which can capture snippets of 720p at 120 FPS to create a slow-moving but smooth video. You can switch dynamically between regular and Slo-mo modes while shooting, and the Camera app will stitch them together for you seamlessly. Senior Reviews Editor Lee Hutchinson demonstrates the feature in the eminently soothing video above. Now let's examine photo quality. I took six phones for a spin—the iPhone 4S, iPhone 5C, iPhone 5S, Lumia 1020, HTC One Google Play edition, and Samsung Galaxy S 4 Google Play edition. With each phone, I took a series of photos outside on a sunny day, in a dark Brooklyn bar, in a room with overhead lighting, and in that same room bathed only in the glow of a computer monitor. Outdoor shooting The iPhone 4S outdoors. Not a bad shot, but it's perhaps a little dark and a little washed-out looking compared to the newer iPhones Moving indoors, the story is the same for the three iPhones: they take superficially similar images, but the 5S edges out both the 5C and 4S in sharpness, noise, and white balance. The 1020 takes sharp, clear pictures that are frustratingly greenish, and even playing with the white balance settings won't yield anything that looks true to life. The S4 and the One both take good shots inside that I'd say are roughly equivalent to the 5C in sharpness and noise, though again the HTC One's aggressive noise removal results in some softness when zoomed in all the way (notice the cat's fur especially). Low-light shooting The iPhone 4S in low light. Things are very dark and indistinct. The iPhone 4S. This is the same shot of desk junk as before, just with the lights turned out. In the low-light tests, the 5S shows the most improvement over the 4S and 5C. What's a black, noisy mess on the 4S and a grainy collection of blurs on the 5C is at least more true to life on the 5S. Low-light scenarios are where the Lumia cameras excel, though, and especially in the bar shot the 1020 captures a much more visible, grain-free image than the other cameras. The 5S still produces a sharper image than the HTC One, and the less said about how the Galaxy S 4 handled the dark rooms the better. Dual-LED flash testing The 5S' dual-LED camera is one of its more unique features, and one of the more welcome given the generally terrible state of on-camera flashes. The camera combines one traditional blue LED with one warmer amber LED that work together to match the ambient light of a given scene. We'll compare the 5S against the single-LED flash in the 5C (which will stand in for most single-LED shooters in smartphones today) and the Xenon flash in the 1020. Andrew Cunningham The iPhone 5S with flash disabled, taking a picture of a backlit subject. The thing on the floor in the background is not random detritus, just a nearly destroyed cat toy. The dual-LED flash in the 5S does produce a light that's a better match for the warm indoor light in the background of the shot. What isn't changed is how harsh the on-camera flash can be—there's still a glare on the Android even if the glare happens to match the rest of the room pretty well. The subject in the foreground ends up being emphasized over the background simply because more light is bouncing off it and returning to the camera's sensor. The Xenon flash on the 1020 also matches color better than the 5C's traditional LED, but the colors all tend to be oversaturated and the result is not especially natural. On the plus side, the background and the foreground are more evenly lit in this shot. Internals and performance: Apple’s A7 and the transition to 64-bit Andrew Cunningham The short version: The move to 64-bit (and the ARMv8 instruction set support the move implies) can double performance compared to the A6 depending on the app, but only for developers who recompile their apps with 64-bit support. Existing 32-bit apps running on the A7 can expect performance increases of around 50 percent over the A6—not too bad for a dual-core CPU running at about the same clock speed. Benchmarks show the A7's GPU meeting Apple's claims of doubled performance, but the dual-band 802.11n support and 100Mbps LTE support are the same as last year. A 1560 mAh battery slightly larger than the one in the iPhone 5 is included, but most of that extra capacity is spent on the faster, more power-hungry chip. Finally, a separate M7 coprocessor will help the phone process sensor input without waking up the main SoC and consuming extra power. The long version: Here's something I wrote toward the end of the performance section of our iPhone 5 review last year: That's exactly what Apple has done with the A7. Apple's largest marketing bullet point here—that it has the world's first 64-bit smartphone—is true, but it's not as though Apple has done anything special to get there. It has implemented the natively-64-bit ARMv8 architecture like most performance-focused ARM SoC vendors were eventually going to do, it just got there months before anyone was expecting it. On the software side, Apple has taken the opportunity to recompile every one of iOS 7's built-in apps to be 64-bit compatible on day one, earning them a substantial performance boost (which we'll examine in a minute). The importance of Apple's decision to go its own way with CPU designs shouldn't be understated—rather than being beholden to ARM's schedule, Apple is now going to control its own fate, possibly beating its competitors to market with new designs and creating CPUs designed specifically to complement its software. Apple's decision to design its own ARM chips has enabled it to take what otherwise could have been a routine hardware upgrade (the move from the 32-bit ARMv7 and the 64-bit ARMv8) and use it as a marketing tentpole. The company's software integration is making the 64-bit transition relatively smooth and completely invisible to the user. The Android ecosystem's move to 64-bit will inevitably be more protracted and piecemeal by comparison, with various SoC vendors implementing 64-bit support one at a time before operating system support and then, later, application support follow later on. It's during transitions like these that Apple's integration is at its most useful. And what of the real-world benefits of 64-bit in a mobile device? Too many conversations on this topic begin and end with the 4GB memory limit that mobile devices aren't really in danger of running up against. This observation is true especially in iPhones, which tend to use about half the RAM of their Android counterparts at any given point in time. Ultimately for iPhones the benefits come not from running 64-bit code in and of itself, but from switch to the more efficient next-generation ARMv8 architecture that supersedes the older ARMv7 architecture. To get a bit more insight on the A7's performance, we spoke with John Poole from Primate Labs, which makes the cross-platform Geekbench tool that we use for CPU benchmarks in our reviews. According to Apple, Geekbench 3.1 was the first 64-bit third-party application to hit the App Store. "You'll definitely see a boost just from running 32-bit applications on the new 5S, but then with the move to 64-bit, it's not just a plain move to 64-bit," Poole explained. "[ARM has] cleaned up the architecture, they've removed a lot of the cruft that's built up over the years. They've also gone ahead and updated with things like more registers and better SIMD instructions, all while keeping the instruction encoding size exactly the same. There's roughly a comparable number of instructions." Poole explained that most (but not all) integer code should see a small performance increase in the neighborhood of 10 to 35 percent because of the 64-bit move, but that floating point code especially would benefit from the transition. "With the extra floating point registers and the extra SIMD instructions, especially if you've got numerically intensive code that can vectorize well… you're going to see a great increase in performance," he said. "I think in some cases it went up 200 percent." In essence, it's not necessarily the move to 64-bit itself that is beneficial to performance, but the move to a cleaner and more efficient underlying architecture. Apps compiled to support 64-bit on iOS—as all of Apple's built-in applications already are—can take full advantage of these optimizations and will see a larger performance benefit because of them. On the RAM question, while iPhones might not have enough memory to really necessitate 64-bit in the here-and-now, there's also a real benefit to future-proofing the platform this early aside from the performance benefits. "[Apple] could have very easily just gone ARMv8 32-bit and they would've avoided all of these sort of pitfalls that come with the transition between 32-bit to 64-bit," Poole said. "I think this was really smart on their part because, I mean, memory is only going to increase in phones. This is a great way to sort of future-proof it and avoid yet another architecture change down the road. Sort of like what happened with the Intel Macs—there was that one generation [in 2006 and early 2007] of Intel Macs that were 32-bit, and that meant you had to drag support around for them… I think people are still shipping 32-bit support in some cases." Apple tends to sell iPhones for around three years after their introduction, and it's not difficult to imagine iPhones or iPads in that not-so-distant future coming with enough RAM that 64-bit support would be required. By baking it into the A7, Apple is essentially guaranteeing that its app developers will be able to start throwing out their 32-bit code in three or four years as current 32-bit hardware ages and drops off Apple's supported hardware list. It's not unlike the transition that happened in OS X in the late 2000s and into the early part of this decade. The 64-bit future looks good, but in the present, most apps are going to be 32-bit. Primate Labs sent us a 32-bit version of Geekbench to test along with the 64-bit version currently in the App Store, and examining the results from the different versions tells us quite a bit about what we can expect from the A7's CPU performance when running apps compiled for either architecture. Without being touched by their developers, 32-bit applications currently in the App Store should be able to expect a performance increase of around 50 percent going from the A6 to the A7. This is a more-than-respectable generational improvement, and it beats the (incorrect) leaked "31 percent" figures that were floating around a month or so ago. Things really get interesting when you look at 64-bit code running on the A7, though. This is where you find that "up to" 100 percent performance increase over the A6 that Apple promised. Integer scores are roughly doubled, memory bandwidth is slightly less than doubled, and floating point performance is slightly more than doubled. The downside is that developers won't see these performance gains automatically, as they (mostly) have in past years—they'll have to recompile their applications to be 64-bit compatible. As an example of the performance jumps that are possible when an application is recompiled for 64-bit, let's take a look at our standard browser benchmarks. Mobile Safari is a 64-bit app on the iPhone 5S, and as such is capable of taking full advantage of the A7. 64-bit Safari running on the iPhone 5S is much, much faster than anything else. In each case, the 64-bit version of Safari on the A7 outruns the 32-bit version on the A6 by around 100 percent, usually by a little more. These scores also outdo Android SoCs like the mighty Snapdragon 800 with ease, though these browser scores should be taken with a small grain of salt in this case. Apple's ability to fine-tune its software for its specific hardware has almost always allowed its phones to post the JavaScript scores of more powerful Android phones, and heavily threaded tasks in real apps may still favor more cores to faster ones. The GPUAll of this CPU talk almost overshadows the GPU, which like the CPU has gotten a new architecture and supposedly doubled performance over the A6. All A5 and A6 chips (and the variants thereof) use some configuration of Imagination Technologies' Series 5 XT GPUs. When it wanted more performance, Apple would either add more GPU cores, increase clock speeds, widen the memory interface, or sometimes do all three at once. The A7 makes the jump to what is almost certainly one of Imagination's Series 6 GPUs, codenamed "Rogue." Apple's developer site lists it as merely an "Apple A7 GPU," a hint that perhaps Apple wants to quietly switch to its own GPU architecture later on (it's been a while since we've heard rumors about Apple's supposed GPU team, but seeing what Apple is doing in CPUs makes me think that the company would like to custom-build its own GPUs as well). For now, OpenGL ES 3.0 support, support for an 8x anti-aliasing mode, and a few other references dug up by AnandTech in the developer documentation point fingers at a next-generation Imagination GPU. Whatever the underlying architecture, the takeaway is that the GPU appears more than capable of doubling the performance of the A6's GPU, especially in GFXBench's demanding T-Rex HD benchmark. Note that GFXBench hasn't yet been recompiled to run in 64-bit mode, so it's possible that if any of these benchmarks are in any way CPU-limited, we may see further gains when the benchmark is updated. Pay special attention to the Offscreen versions of the test, which runs the benchmark at 1080p on all phones without interference from framerate-limiting Vsync. The A7 is slightly better than the Adreno 330 GPU in the Snapdragon 800 (one of the best, if not the best, GPUs in an Android phone right now), and it handily outperforms the older Snapdragon 600 and all previous iPhone generations. What’s next?Given how surprising Apple's 64-bit announcement was this year, it's difficult to say just what the company might pull out of its hat in a potential A8 next year. I'd say that an Apple-designed GPU is a possibility, though I think it's also possible that Apple could repeat what it did in the transition between the A5 and the A6—take the same basic Imagination-built GPU architecture and beef it up as much as is necessary to hit its desired performance target. The next iPhone will probably make an effort to upgrade its wireless interfaces, too. The 5S includes the same dual-band 802.11n and Qualcomm MDM9615M (capable of up to 100Mbps LTE speeds) as the iPhone 5, and while those are still reasonably fast interfaces, some Android phones are already moving on to 802.11ac and 150Mbps LTE Advanced speeds. Neither of those standards are in wide use yet, but by next year we'd like to see them in most high-end phones in the name of future-proofing. In the more immediate future, let's talk about iPads, since they're allegedly right around the corner. First, it's pretty likely that Apple will develop a beefier "A7X" to pair with the next 10-inch iPad. If it follows in the footsteps of the A5X and A6X, it will pair the same dual-core CPU that the A7 uses with a more powerful version of the same GPU and a wider memory interface to help drive that high-resolution display. And what of the iPad mini? Specifically, what of a Retina iPad mini, which I believe is more likely than ever given the way iOS 7 looks on the current mini's display? Let's assume that screen technology has advanced sufficiently that Apple can include a high-density display in the mini without making it into a brick or killing its battery life (the 2013 Nexus 7 suggests both are possible). What about packing in an SoC that is powerful enough to push all of those pixels? Take a look at the A7's GPU performance compared to the A6X's (remember, the Offscreen tests render the same scene at 1080p, putting the two GPUs on even footing here). Now, the A7 still only has half the memory bandwidth that the A6X does (it uses a 64-bit interface, compared to 128-bit), so it may not be a perfect fit for a Retina iPad mini. It may also make things just a tiny bit more complicated for developers, since it adds another device to test on—right now the iPad mini and iPad 2 are substantially identical, but a mini with an A7 instead of an existing SoC like a die-shrunk A6X or some such thing in it would give developers something else they'd need to target. It remains nevertheless an intriguing possibility. Whatever Apple does, we hope that the end of non-Retina iOS devices is close at hand. Battery lifeSince before our iOS 7 review ran, I've been running battery tests on an iPhone 5 running iOS 7 over and over again to try to get a handle on its apparent battery life issues. For those of you who didn't make it to the end, every single iOS 6 device we tested (including an iPad 2 tested independently by Associate Writer Casey Johnston for another article) posted a slight loss in battery life in iOS 7 when performing our Wi-Fi browsing battery life test. The iPhone 5 lost over three hours of use in iOS 7 compared to the exact same phone running iOS 6—seven hours and 44 minutes compared to 11 hours and one minute. Our test loops a series of pages continuously in Safari every 15 seconds until the phone dies. It's not exactly a common real-world use case, but it's a simple and repeatable test that yields reasonably consistent results. After reading this ExtremeTech writeup of our findings and several comments and reader e-mails asking whether the drop could be attributed to this-or-that specific iOS 7 feature, I began experimenting with a few different things. My first item of business was to find and test an AT&T model iPhone 5, which ran the test for eight hours exactly—slightly improved, but in the same ballpark as the Verizon phone that I originally tested. I disabled the Background App Refresh feature and ran the test on the Verizon phone again, which yielded no significant improvements. I ran the test with the phone's SIM completely removed and cellular data disabled, again with no significant change to the results. By changing the series of pages our test loads, I was able to get the Verizon iPhone 5 to post an improved result of eight hours and 34 minutes, but that's still short of our 11-hour figure in iOS 6, the official Apple-provided estimate of 10 hours, and AnandTech's 10.27 hours in its own iOS 6 Wi-Fi browsing test. The upshot of all of this is that, like many mobile battery life issues, the problems the iPhone 5 seems to be having are hard to nail down and workload-dependent. For those of you who aren't having issues, we hope it stays that way. For those of you who are, we'll continue to pay attention to this as Apple begins to issue updates for iOS 7. As for the iPhone 5S itself, our AT&T model ran the modified Wi-Fi browsing test for eight hours and 27 minutes, suggesting that its more powerful SoC and larger 1560 mAh battery basically cancel each other out. This is still short of Apple's advertised 10 hours, but it compares favorably the Google Play editions of the Galaxy S 4 and HTC One (five hours and 57 minutes and five hours and 37 minutes, respectively). LG's G2 outdoes it with 11 hours and 30 minutes of battery life, however. The best iPhone there is This year's iPhone lineup: the iPhone 4S, iPhone 5C, and iPhone 5S. Andrew Cunningham Like all of Apple's S series phones, the 5S presents a nice collection of upgrades over last year's iPhone 5, but it's not really for people who bought an iPhone last year. Most people keep their smartphones for at least a couple of years before upgrading, and even if the 5S sometimes feels a little incremental compared to the 5 it's still a huge upgrade over the 4S (and I was pretty happy with how my 4S was handling iOS 7). The fingerprint sensor is a genuinely useful addition, even if it isn't completely fool-proof. We still hope that Apple adds some sort of two-factor authentication option for the feature in a later update. In the meantime, the feature plus new iOS 7 features—the default prompting to enable a passcode, and the Find My iPhone addition that won't allow malicious users to wipe a phone without the Apple ID it's attached to—should improve the general state of basic user security in iOS. Equally momentous is the A7 SoC, which continues Apple's streak of doubling its flagship phone's performance once a year. We can't help but think the company has to hit a wall there some time, but at least for this year Apple has caught its competitors flat-footed and gotten its own mobile 64-bit transition kickstarted. This is all while giving users a performance increase that they'll notice even if they don't know or care how many bits their phone has. Long story short, if you currently own an iPhone that is not an iPhone 5, this is the one you should get, if only because the 5S will guarantee you the best software experience for the longest amount of time. If you do own an iPhone 5, stick with it until next year and you'll probably end up with all the 5S' improvements and more. The fact of the matter is that most people already know whether they want an iPhone at this point. It's a thoroughly known quantity. If you know you want an iPhone, this is the best iPhone that there is—at least until the next one comes out. The goodThe iPhone 5 design is still sturdy and attractive, and "space gray" should hold up better to scuffs than last year's black model Excellent performance Good camera with improved low-light performance, though in low light especially some Lumia phones can best it Lovely screen, even if some others are larger and denser Decent battery life, which we hope is improved by future iOS updates Fingerprint sensor is a useful addition that should encourage people to practice some security rather than none The badThe fingerprint sensor is imperfect as a standalone authentication tool, and Apple doesn't (yet?) support two-factor authentication Dual-band 802.11n and 100Mbps LTE aren't bad at all in the here-and-now, but they might be feeling a little dated by the time your two-year contract is up The uglyDevelopers will have to recompile their applications to take full advantage of the A7

Google and Samsung have become increasingly frequent contributors to Linux, and each is now among the top 10 companies sponsoring the open source kernel that powers operating systems from mobile devices to desktops and servers. A new Linux Kernel Development report (informally known as "Who Writes Linux") released today by the Linux Foundation names Samsung and Google as the seventh and eighth most frequent corporate contributors, behind Red Hat, Intel, Texas Instruments, Linaro, SUSE, and IBM. The report covers almost 92,000 changes to Linux from 3,738 individuals since version 3.3 in March 2012. Most Linux developers contribute to the kernel as part of their employment. Here's a look at the top corporate contributors: Linux Foundation "None" refers to developers working on their own without corporate sponsorship, while "unknown" covers developers for whom a corporate affiliation could not be determined. For the purpose of assigning numerical rankings to individual corporations in this article, we're ignoring those two categories as well as the "consultants" category. Linaro, which makes open source software for ARM systems-on-a-chip, made a huge jump from 0.7 percent of total changes in the 2012 list to 4.1 percent on the latest one. The Linux Foundation noted that Linaro, Samsung, and Texas Instruments, combined, have risen from 4.4 percent of changes to 11 percent, reflecting the growing importance of mobile and embedded systems. 17 million lines of codeThe Who Writes Linux reports aren't released precisely on an annual schedule, so the percentage of contributions rather than the total number is the best way to track changes in corporate involvement from one report to the next. The previous report released in April 2012, covering the period since December 2010, put Google in 11th place with 1.5 percent of contributions. Samsung did not make the top 30 list in that report. The March 2012 report also compiles all stats since 2005, with Google registering at one percent in that seven-year period and Samsung at 0.6 percent. As noted in the chart above, Samsung and Google now clock in at 2.6 percent and 2.4 percent, respectively. Google and Samsung have clearly stepped up their contributions to Linux at the same time that Android, which is based on Linux, has increased in popularity and importance. But as it turns out, Android wasn't the main driver pushing the companies into the top 10. "Google contributions were not Android-related, given there really wasn't much Android code in the first place (7,000 lines of code, much smaller than your serial port driver), and it was all merged a while ago," Greg Kroah-Hartman, who co-authored the report and is the maintainer of the Linux kernel's stable branch, told Ars. "Google's been doing work all over the kernel (networking, security, scheduler, cgroups), all good stuff." Samsung has likewise made contributions all over the place with a "new filesystem, core kernel work, new driver subsystems, fixes everywhere," Kroah-Hartman said. The report is being released in conjunction with the start of the LinuxCon conference today in New Orleans. The overall pace of development has increased, with the community merging patches at the rate of 7.14 per hour, up from 6.71 per hour in the last report. The kernel now has almost 17 million lines of code, up nearly two million lines. The report did not rank contributors by lines of code. Important features merged into the mainline kernel code since early 2012 include "full tickless operation [to lower power consumption], user namespaces, KVM and Xen virtualization for ARM, per-entity load tracking in the scheduler, user-space checkpoint/restart, 64-bit ARM architecture support, the F2FS flash-oriented filesystem, many networking improvements aimed at the latency and bufferbloat problems, two independent subsystems providing fast caching for block storage devices, and much more," the report said. Linux Foundation Executive Director Jim Zemlin noted that while Apple touted 64-bit support in the new iPhone, "that's done in Linux, has been done for a long time. The Android ecosystem just picks that up by default, they don't have to go through any special development process to do that." More good news is that the "longstanding squabble over Android-specific kernel features has faded completely into the background," the report said. "The much discussed 'wakelocks' [power management] feature has been quietly replaced by a different mainline solution which is used in the latest Android devices." Microsoft isn't dumping Windows for Linux, it turns outAmong other notable changes, Microsoft fell off the list after briefly being one of Linux's most prolific contributors. Microsoft's 688 changes accounted for one percent of the total in the 2012 list. Microsoft, in 2009, submitted drivers for its Hyper-V virtualization platform to the Linux kernel. The project hit a bunch of delays, with Microsoft struggling to get its drivers out of the staging area and into the mainline kernel. In 2011, Microsoft became the fifth largest corporate contributor to Linux kernel version 3.0 as it attempted to clean up its code. Redmond's contributions have predictably dropped off now that the code is more stable. Nvidia (which famously pissed off Linus Torvalds with allegedly low-quality work) is in 13th place with 1.3 percent of changes on the most recent list. Nvidia did not make the 2012 list. Canonical contributed 548 changes in the period studied in today's report and would have cracked the top 30 if the foundation hadn't included "none" and "unknown" in the rankings. The maker of Ubuntu has been criticized for years for not contributing more to the kernel (and recently clashed with Intel over patches submitted to the company's graphics driver), but Zemlin isn't upset. "I am not at all mad at them. I think they do good work," he said. "You just kind of choose what's important to your org and where you can add the most value to the project and how it intersects with your business. They choose to focus a lot of their time and energy at higher levels of the software stack." Among individuals submitting code to Linux, longtime contributor Al Viro led the way with 4,124 changes, 1.2 percent of the total. Linus Torvalds, who created Linux and makes the final decisions on what goes into the kernel, did not make the top 30 list. But that's no surprise. Torvalds and many of the other senior kernel developers "spend much of their time getting other developers’ patches into the kernel; this work includes reviewing changes and routing accepted patches toward the mainline," the report said. Besides tracking the submitted changes, the Linux Foundation report measures "signoffs," the review process conducted by kernel leads. Here's another chart showing the number of signoffs by company affiliation: Linux Foundation These are just approximate numbers since "the signoff metric is a loose indication of review," the report said. For individuals, getting your name in the Who Writes Linux report is a path to prosperity, Zemlin said. "The competitiveness to hire all these people is palpable," he said. "That's one of the top calls I get: 'How do I hire these guys? How can I hire more kernel guys?' If you're even just getting a few patches into the Linux kernel regularly, that is a guaranteed employment type of thing." The number of contributions from unpaid developers decreased from 14.6 percent to 13.6 percent in the latest report. Even though the source code is free, Linux is no volunteer project—it's enormously important to the businesses of Intel, IBM, Red Hat, and others, as their appearances at or near the top of every list reflect. The most plausible explanation for the decrease in volunteer developers may be that they are getting hired because of their demonstrated ability to write code, the Linux Foundation said.

For more than a year, Ars has advised readers to use long, randomly generated passwords to protect their digital assets. Now comes definitive proof that too much password length can be detrimental to security. It comes in the form of just-patched vulnerability in the Django Web development framework. By default, it uses the PBKDF2 algorithm to transform plain-text passwords into long strings called cryptographic hashes. Like scrypt and bcrypt, it's one of the most secure ways websites can store "at rest" passwords, because it passes them through multiple hashing rounds that significantly increase the time and computational resources required. In the event of a breach that spills a large password database, the additional effort can literally add centuries to the process of cracking the raw passwords. But as Django developers have learned, this enhanced security can be a double-edged blade. In an advisory posted Monday they explained why: Shortly after someone disclosed the DoS vulnerability on a public forum for Django developers, maintainers quickly scrambled to patch it. The updates, which limit passwords to 4096 bytes, are linked to Monday's advisory. The post went on to reminded users that Django developers prefer to receive security disclosures privately at security@djangoproject.com so they can fix the vulnerability before it becomes widely known.

Raising troubling questions about the reliability of government-mandated cryptography certifications used around the world, scientists have unearthed flaws in Taiwan's secure digital ID system that allow attackers to impersonate some citizens who rely on it to pay taxes, register cars, and file immigration papers. The crippling weaknesses uncovered in the Taiwanese Citizen Digital Certificate program cast doubt that certifications designed to ensure cryptographic protections used by governments and other sensitive organizations can't be circumvented by adversaries, the scientists reported in a research paper scheduled to be presented later this year at the Asiacrypt 2013 conference in Bangalore, India. The flaws may highlight shortcomings in similar cryptographic systems used by other governments around the world since the vulnerable smartcards used in the Taiwanese program passed the FIPS 140-2 Level 2 and the Common Criteria standards. The certifications, managed by the National Institute of Standards and Technology (NIST) and its counterparts all over the world, impose a rigid set of requirements on all cryptographic hardware and software used by a raft of government agencies and contractors. “Trivially broken keys”The team of scientists uncovered what their paper called a "fatal flaw" in the hardware random number generator (RNG) used to ensure the numbers that form the raw materials of crypto keys aren't based on discernible patterns. Randomness is a crucial ingredient in ensuring adversaries can't break the cryptographic keys underpinning the smartcards issued to Taiwanese citizens. Out of slightly more than 2 million 1024-bit RSA keys the researchers examined, an astonishing 184 keys were generated so poorly they could be broken in a matter of hours using known mathematical methods and standard computers to find the large prime numbers at their core. Had the keys been created correctly, breaking them so quickly would have required a large supercomputer or botnet. That even such a small percentage of keys were found to be so easily broken underscores the fragility of cryptographic protections millions of people increasingly rely on to shield their most intimate secrets and business-sensitive secrets. "The findings are certainly significant for the citizens who have been issued flawed cards, since any attacker could impersonate them online, the research team wrote in an e-mail to Ars. "More broadly, our research should give pause to any of the many countries that are rolling out this kind of national public key infrastructure. These smart cards were certified to respected international standards of security, and errors led to them generating trivially broken cryptographic keys. If a technologically advanced government trying to follow best practices still has problems, who can get this right?" Stacking the deckThe research is being published two weeks after documents leaked by former National Security Agency (NSA) contractor Edward Snowden outlined the covert hand intelligence agents have played in deliberately weakening international encryption standards. As a result, the NSA and its counterparts in the UK can most likely bypass many of the encryption technologies used on the Internet. Cryptographers involved in, and independent of, the research agreed that the weaknesses exposed in the paper were almost certainly the result of human error, rather than deliberate sabotage. They based that assessment on the observation that the predictable patterns caused by the malfunctioning PRNG were so easy to spot. "Some of the primes discovered in this work are so obviously non-random that, if they were the result of deliberate weaknesses, then I'd be asking for my money back from my three-letter agency," Kenneth G. Paterson, a Royal Holloway scientist who has seen the paper, told Ars. "Because they would clearly not have been doing a very good job in hiding their footprints." Still, the fact that Taiwan's extremely weak RNGs passed stringent validation processes is troubling. An RNG that picks prime numbers in predictable ways is in some ways the cryptographic equivalent of a blackjack croupier who arranges a deck of cards so they're dealt in a way that puts the gambler at a disadvantage. Properly implemented RNGs, to extend the metaphor, are akin to a relief dealer who thoroughly shuffles the deck, an act that in theory results in the strong likelihood the cards never have and never again will be arranged in that exact same order. A slide from a recent presentation detailing the 119 primes shared among 103 of the weak cards used in Taiwan's Citizen Digital Certificate program. There's no way to rule out the possibility that the NSA, or intelligence agencies from other nation states, didn't already know about the vulnerability in Taiwan's crypto program or about programs in other countries that may suffer from similar weaknesses. The inability of the certifications to spot the fatally flawed RNGs suggests the standards offer far less protection than many may think against subtle flaws that either were intentionally engineered by intelligence agencies or were exploited after being discovered by them. The researchers began their project by examining almost 2.2 million of the Taiwanese digital certificates secured with 1024-bit keys (newer cards have 2048-bit RSA keys). By scanning for pairs of distinct numbers that shared a common mathematical divisor, they quickly identified 103 keys that shared prime numbers. A little more than 100 keys that shared primes out of a pool of 2 million makes for an infinitesimally small minuscule percentage, but in the eye of a trained cryptographer, it flags a fatal error. When generating a 1024-bit RSA key, there are an almost incomprehensible 2502 prime numbers that can be picked to form its mathematical DNA, Mark Burnett, an IT security analyst and author, estimates. That's many orders of magnitude more than the 2266 atoms in the known universe. If all these primes are properly mixed up and evenly distributed in a large digital pot—as is supposed to happen when being processed by a correctly functioning RNG—no two primes should ever be picked twice. By definition a prime is a number greater than one that has no positive divisors other than 1 and itself. A summary of the data flow leading to successful factorizations of the Digital Citizen Card used in Taiwan. Bernstein, et al. And yet, 103 of the keys flagged by the researchers factored into 119 primes. The anomaly was the first unambiguous sign that something horribly wrong had gone on during the key-generation process for the Taiwanese smartcards. But it wasn't the only indication of severe problems. The researchers sifted through the shared primes and noticed visible patterns of non-randomness that allowed them to factor an additional 81 keys, even though they didn't share primes. Once the primes are discovered, the underlying key is completely compromised. Anyone with knowledge of the primes can impersonate the legitimate card holder by forging the person's digital signature, reading their encrypted messages, and accessing any other privileges and capabilities afforded by the card. The researchers said they informed officials in Taiwan's government of the problems and were told that as many as 10,000 cards might suffer similar weaknesses. The estimate, the researchers told Ars, were based on internal records from the Ministry of Interior Certificate Authority and Chunghwa Telecom, Taiwan's official digital certificate authority and the smartcard manufacturer, respectively. "The government claims that they will track down and replace all the flawed cards but hasn't done so at the time of writing," the researchers told Ars. "So everybody with an RSA-1024 card could have a weak one." The newer RSA 2048-bit cards they examined didn't suffer from the same weaknesses, although they didn't rule out the possibility those cards contain more subtle flaws that make them just as vulnerable. Not the first timeOne of the affected smartcards, from Chunghwa Telecom Co., Ltd. NIST The discovery has roots in research published last year that made another astonishing discovery: four of every 1,000 1024-bit keys found on the Internet provided no cryptographic security at all. The reason: as with Taiwan's Citizen Digital Certificate keys, the almost 27,000 cryptographically worthless keys they found shared primes with at least one other key. One of the research teams that discovered the keys later released a detailed analysis of what went wrong. Since almost all the keys were from "self-signed" certificates used to protect routers and other devices, the researchers speculated the hardware lacked the robust RNGs found in more advanced platforms and applications. Two of the three mathematical techniques used to factor the keys in the Taiwanese smartcards are well-known and unsophisticated. They are trial division and use of things like the Binary Greatest Common Divisory Algorithm for finding greatest common divisors. A third technique know as Coppersmith's attack is significantly more advanced, and the researchers said it represents the first recorded time it has been used to break a cryptographic system. All three techniques can be carried out on unsophisticated computers to factor weak keys in a matter of hours. Using the same methods and hardware to factor 1024-bit keys that are generated properly would "not have found those primes within the expected lifetime of the universe," the researchers said. (Other, more sophisticated algorithms, when carried out on supercomputers, represent a much bigger threat to 1024-bit keys.) "Our results make it pretty clear that the more computational effort we expend, the more keys we were able to factor," the researchers wrote. "We did enough computation to illustrate the danger, but a motivated attacker could easily go further." As crucial as random number generation (RNG) is to cryptographic security, the task remains maddeningly difficult to do. It requires a computer to carry out what scientists call non-deterministic behavior, which typically causes malfunctions in most other contexts. Frequently, extremely subtle bugs can cause RNGs, assumed to be robust, to produce highly predictable output. One example was an almost catastrophic vulnerability in the Debian distribution of Linux. The overlooked bug caused vulnerable machines to generate dangerously weak cryptographic keys for more than 20 months before it was diagnosed and fixed in mid 2008. The FIPS 140-2 Validation Certificate for one of the affected smartcards. NIST To prevent these common mistakes, standards bodies sponsored by governments around the world have created a set of rigid criteria cryptographic systems must pass to receive certifications that can be trusted. The certifications are often a condition of a hardware or software platform being adopted or purchased by the government agency or contractor. But despite passing both the FIPS 140-2 Level 2 and Common Criteria standards, the RNG process used to generate the weak cards clearly didn't meet their mandated requirements. FIPS 140, for instance, specifies that output of a hardware RNG on the processor of the smartcard must (a) be fed through tests to check whether it's random and unbiased, and only then can the output (b) be used as a seed for a so-called deterministic random bit generator, which in many settings is referred to as a pseudo RNG. The hardware RNG was provided by the AE45C1, a CPU manufactured by Renesas that sits on top of the smartcard. The deterministic random bit generator was driven by the smartcard firmware provided by Chunghwa Telecom. "It's pretty clear that neither step happened in this case," the researchers told Ars. "Even without performing step (a), step (b) should have made the keys appear individually random, even if they were not. Instead, the factored keys contained long strings of 0 bits or periodic bit patterns that suggest that step (b) was skipped, and what we see is the direct unwhitened output from the malfunctioning hardware." The seven researchers are Daniel J. Bernstein, Yun-An Chang, Chen-Mou Cheng, Li-Ping Chou, Nadia Heninger, Tanja Lange, and Nicko van Someren. The failure has implications not only for the citizens of Taiwan but for internationally certified cryptographic technologies everywhere. "It is a common practice to advertise chips as certified if they get certification on some part of it, but the certification actually means very little," the researchers told Ars. "The whole system is broken. "Two certifications didn't stop the bad hardware RNG on the card; how can we trust them to find more sophisticated flaws such as intentional back doors?

Scientists have developed a technique to sabotage the cryptographic capabilities included in Intel's Ivy Bridge line of microprocessors. The technique works without being detected by built-in tests or physical inspection of the chip. The proof of concept comes eight years after the US Department of Defense voiced concern that integrated circuits used in crucial military systems might be altered in ways that covertly undermined their security or reliability. The report was the starting point for research into techniques for detecting so-called hardware trojans. But until now, there has been little study into just how feasible it would be to alter the design or manufacturing process of widely used chips to equip them with secret backdoors. In a recently published research paper, scientists devised two such backdoors they said adversaries could feasibly build into processors to surreptitiously bypass cryptographic protections provided by the computer running the chips. The paper is attracting interest following recent revelations the National Security Agency is exploiting weaknesses deliberately built-in to widely used cryptographic technologies so analysts can decode vast swaths of Internet traffic that otherwise would be unreadable. The attack against the Ivy Bridge processors sabotages random number generator (RNG) instructions Intel engineers added to the processor. The exploit works by severely reducing the amount of entropy the RNG normally uses, from 128 bits to 32 bits. The hack is similar to stacking a deck of cards during a game of Bridge. Keys generated with an altered chip would be so predictable an adversary could guess them with little time or effort required. The severely weakened RNG isn't detected by any of the "Built-In Self-Tests" required for the P800-90 and FIPS 140-2 compliance certifications mandated by the National Institute of Standards and Technology. The tampering is also undetectable to the type of physical inspection that's required to ensure a chip is "golden," a term applied to integrated circuits known to not include malicious modifications. Christof Paar, one of the researchers, told Ars the proof-of-concept hardware trojan relies on a technique that requires low-level changes to only a "few hundred transistors." That represents a minuscule percentage of the more than 1 billion transistors overall. The tweaks alter the transistors' and gates' "doping polarity," a change that adds a small number of atoms of material to the silicon. Because the changes are so subtle, they don't show up in physical inspections used to certify golden chips. "We want to stress that one of the major advantages of the proposed dopant trojan is that [it] cannot be detected using optical reverse-engineering since we only modify the dopant masks," the researchers reported in their paper. "The introduced trojans are similar to the commercially deployed code-obfuscation methods which also use different dopant polarity to prevent optical reverse-engineering. This suggests that our dopant trojans are extremely stealthy as well as practically feasible." Besides being stealthy, the alterations can happen at a minimum of two points in the supply chain. That includes (1) during manufacturing, where someone makes changes to the doping, or (2) a malicious designer making changes to the layout file of an integrated circuit before it goes to manufacturing. In addition to the Ivy Bridge processor, the researchers applied the dopant technique to lodge a trojan in a chip prototype that was designed to withstand so-called side channel attacks. The result: cryptographic keys could be correctly extracted on the tampered device with a correlation close to 1. (In fairness, they found a small vulnerability in the trojan-free chip they used for comparison, but it was unaffected by the trojan they introduced.) The paper was authored by Georg T. Becker of the University of Massachusetts, Amherst; Francesco Regazzoni of TU Delft, the Netherlands and ALaRI, University of Lugano, Switzerland; Paar of UMass; Horst Gortz Institut for IT-Security, Ruhr-Universitat, Bochum, Germany; and Wayne P. Burleson of UMass. In an e-mail, Paar stressed that no hardware trojans have ever been found circulating in the real world and that the techniques devised in the paper are mere proofs of concept. Still, the demonstration suggests the covert backdoors are technically feasible. It wouldn't be surprising to see chip makers and certifications groups respond with new ways to detect these subtle changes. Story updated to change "dozen" to "hundred," after researchers clarified the "a few dozen" modified transistors applied only to the side-channel trojan. The attack on the Ivy Bridge processors requires modification of 256 or 512 transistors, depending on the entropy the attacker wants.

welcome bro

welcome to our family.

Microsoft has announced the pricing and packaging for Windows 8.1. Retail packages of Windows 8.1 will have a retail price of $119.99, and Windows 8.1 Pro will be $199.99. The Pro Pack, to convert 8.1 to 8.1 Pro, will be $99.99. Media Center will also remain available to Pro users for $9.99. As disclosed in May, upgrading from 8.0 to 8.1 will be no-cost. These packages will be full, supported, retail copies, suitable for installation on systems without an operating system at all, as well as for use within virtual machines. Windows 8 scrapped full Windows versions, with retail packages being only upgrades. Microsoft's rationale for this was that since almost every PC ships with Windows already, and is hence eligible for an upgrade, the demand for full non-upgrade versions was negligible. The closest thing to a full version was the System Builder package, designed primarily for small system builders to preinstall on systems that they then sold to third parties. This scheme was awkward for those seeking to virtualize the operating system and those building their own PCs. The readily available retail upgrades weren't suitable for these roles, as they required a previous operating system in order to qualify for the upgrade. The System Builder edition was suitable, thanks to a new Personal Use provision, but the System Builder edition was harder to find. Microsoft says that the reinstatement of the retail package should make these scenarios much easier. These boxed copies won't, however, be ideal for upgraders. Although Windows 8 can be installed as an upgrade to Windows 7 (preserving most settings and applications in the process), Windows 8.1 cannot. So if you stuck with Windows 7 because you felt that Windows 8 was too unpolished, but think that Windows 8.1's changes make it viable, you'll probably be better off tracking down a copy of Windows 8 and buying that, rather than 8.1, and then upgrading for free to 8.1.

good post bro

yes get me a new theme thanks

For the first time in years, Mac Pro fans have something to really cheer about. Apple today unveiled a redesign of its workhorse computer, which is now a reflective cylindrical case that's only 1/8 the volume of the current Mac Pro. Apple vaguely said that the new computer won't go on sale until "later this year," but it's never too early to take a look at a device that we will put through its paces as soon as it's available. New Look Uncasing Processor: Ram: Graphics Storage: Thermal: Fan: Expansion:

welcome to our family

welcome to our family.

welcome to our family bro Read the rules first if u haven't it as may be there some changes Follow the rules and Njoy

welcome to our family bro Read the rules first if u haven't it as may be there some changes Follow the rules and Njoy

Dear members I have found that lots of members (especially newbie) facing problems while creating/posting thread after creating their account. we are need to inform you that the post count must be 10 before you can start a new thread except the introduce yourself section. (We do this to help stop drive by bots and spammers) Thanking You, CyberAbC33

gr8

good site.........

gr8 bro...

Welcome to our family. Follow the rules Njoy!

Welcome to our family. Follow the rules Njoy!

Welcome to our family. Follow the rules Njoy!

Welcome to our family. Follow the rules Njoy!

Welcome to our family. Follow the rules Njoy!

Welcome to our family. Follow the rules Njoy!