Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:Good! (Score 3, Interesting) 25

by hankwang (#49415191) Attached to: Google In Talks To Create International Roaming Network

Telecom is hugely profitable, mobile telecom even more so.

Could you provide some data to support that statement? Not that I think the roaming charges are reasonable (since they are completely disconnected from actual costs for the operators), but that would just mean that domestic charges should go up and international/roaming rates should go down.

Look for example at the Vodafone annual report (big PDF), income statement on page 96. On 38 bn UK pounds annual revenue, the made 5 bn loss (before taxes, not including the profitable sale of their stake in Verizon).

Or the T-mobile US numbers on 2014 (full year). Page 6: US$ 14 bn revenue; net income US$ 0.25 bn. That does not look like a hugely profitable business to me. Or the balance sheet on page 5: US$ 57 bn assets, and only US$ 16 bn of stockholder's equity; a ratio of 3.6:1, which I'd consider pretty large for a company that is not making a large profit and that has to deal with rapidly depreciating infrastructure.

Here's Verizon 2014 full year: US$ 127 bn revenue, US$ 12 bn net income. That looks more healthy. But look at the balance sheet: US$ 232 bn assets, and just US$ 14bn in equity (16:1 ratio). I would be very hesitant to invest in a company with such a balance sheet. To my surprise, the stock market thinks differently with a P/E of 21.

I'm not a finance expert, so if I misinterpret the numbers, please correct me.

Comment: Re:The big advantage of XOR (Score 2) 277

example is the AES-NI instructions, which exist on essentially all modern desktop and laptop CPUs, and many of the newest mobile CPUs as well.

What's the difference between "mobile CPU" and "laptop CPU"? In any case, most 4th generation i3 mobile/laptop CPUs don't support AES-NI, nor do the current Intel Celeron CPUs. Many of those have been released as recently as 2014, so I would count them as "modern".

Comment: Re:What are you protecting? (Score 1) 277

You can build a sophisticated cypher that does not require polynomials, massive primes or any of the stuff that RSA uses

That stuff is for secure key exchange over an untrusted channel. The actual ciphers that are used to process the bulk of the data is not much more complicated than what you describe. You can look up the algorithms for RC4, AES, and blowfish.

Create a two dimensional array each dimension being 64K in size of 64 bit integers (...) If you exhaust the length of the key simply wrap it around.

Several big problems with that: 1. You'll need to calculate 2^32 (4 billion) 64-bit entries, i.e. 32 GiB, which is a lot of CPU time and memory if you just wanted to encrypt 10 kB of plaintext. (I'm not completely sure how you want to implement it; maybe you "only" need to calculate 64 k random values for each word of plaintext). 2. You need a really good (cryptographic-grade) random generator. If you have one, you could just as well use it directly - it's called "stream cipher". 3. If you wrap around your 32 GiB "two-time" pad over a low-entropy plaintext source, it is broken, since you can xor the plaintext at offset 0 with itself at offset 32 GiB to cancel out the pad. If you know that the message is plain English language, that may be enough reconstruct the two plaintext messages. [English has about 1 bit of entropy per character; xoring two texts with itself wlil result in about 2 bits of entropy per byte (8 bits) of message.] 4. If you encrypt two plaintext messages with the same key, your encryption is broken, for the same reason as under #3.

Comment: Re:xor unbreakable with long (stretched) key (Score 1) 277

RC4 is simple, it's fast, (...) and it is *broken*.

It's only provably broken if you don't use the straightforward workaround for its weakness, i.e., discarding the first few hundred bytes (2 KiB to be on the safe side) of cipher stream. This was a problem in WEP encryption and may be a problem in the SSL implementation (not sure about today's status) and it kind of negates the speed advantage if RC4 is used for transmitting short messages. But run ssh with RC4 (it will drop the first 2 kB of the key stream) for large file transfers and you're safe and fast.

Comment: Re:Don't make it impossible, just make it hard (Score 1) 385

by hankwang (#49355915) Attached to: Modern Cockpits: Harder To Invade But Easier To Lock Up

"Why would the cabin crew have the code? The code is for the pilots."

Here is airbus's own explanation: http://m.youtube.com/watch?v=R...

TL;DW: if the pilots are incapacitated, the cabin crew can punch a code to save the day; the door will unlock after 30 seconds unless the pilot pushes the button to deny access. (the pilots are alerted by a beeping signal.) Actually, a pretty sensible way to do it.

Comment: Re:Waste of time (Score 1) 253

"like that will collect dust in megaton quantities. And you can't hard-seal the device away to avoid moisture because it'll overheat in short order."

Dust and moisture are being mentioned again and again here. I don't get that. Most dust is generated in places where humans shed skin flakes, rub clothes, and walk over carpets. Where does all that dust come from in a crawlspace? From that tiny amount of airflow? Spores of massive fungal growth? (then you have another problem to deal with first).

As for humidity: a running server will always be slightly higher in temperature than the environment. I don't see how water vapor that has been flowing along lots of cooler surfaces can condense on the server. It would only be a problem if you put the server very close to a ventilation opening, if warm humid air enters from there. Or if condensation is actually dripping from the crawlspace ceiling, onto the server.

Comment: Re:Do that for the laptops as well (Score 2) 51

by hankwang (#49265319) Attached to: Fujitsu Could Help Smartphone Chips Run Cooler

"That would reduce the fans work (and their own heat!)"

Years ago, I bought a Shuttle barebones Pentium 4 with a heat pipe, hoping that it would be as quiet as the Mac Minis of the time. It was disappointing. It saved having separate CPU and PSU fans and it was a bit less noisy than the average beige box pc, but still very noticeable.

A problem with heat pipes is that they are not flexible, so the motherboard, case-mounted fan, and heat pipe must match exactly. Not so suitable for do-it-yourself pc building. And in order to reduce noise, you still need to spread the heat over a large surface, i.e. attach a lot of lamellas to the heat pipe, that you could just as well have attached directly onto the cpu cooler.

Comment: Re:Speed penalty of encryption (Score 1) 124

by hankwang (#49263165) Attached to: Google Backs Off Default Encryption on New Android Lollilop Devices

I don't know about TWRP though, stcok CM does

ClockworkMod (if that's what you mean by "Stock CM" bootloader) on my older Android-2.3 device has an option "Backup", which will write a backup of /data on the removable SD card; I don't even need to connect over adb (but if I try, it doesn't complain). Maybe this has changed with more recent CWM releases, but for me this was a major reason to encrypt /data on all my Android 4.x devices that run CM.

I'm using TWRP because CWM cannot handle an encrypted data partition, so it has nowhere to store the new ROM image on devices without a physical unencrypted SD card. TWRP will happily accept an ADB connection from an unknown device. (Just to make sure: I just revoked all ADB authentications, rebooted into Fastboot (Power+Volume), selected Recovery, and connected over adb.) Anyway, because the device is encrypted with a long passphrase, I don't care that much.

Comment: Re:$30 Timex (Score 1) 389

If a watch is watertight for 50 m static water pressure, then it is also watertight for 45 m static water pressure in combination with an enormous amount of dynamic pressure. So that cannot be the reason why usually the depth ratings are translated as "splash proof" (30 m), "you can swim" (50 m), and "you can dive to the bottom of the swimming pool" (100 m).

Comment: Re:$30 Timex (Score 1) 389

You also need to take into account peak water pressures; the rating is measured as a static object in water, doing something like diving into a swimming pool subjects the watch to significantly more water pressure

That's a common misconception. The dynamic pressure is additive (not multiplicative) and amounts to about 0.5 rho v^2, where rho=1000 kg/m3 is the densitiy and v the velocity. For example, at v = 10 m/s, the added dynamic pressure is 50 kPa, equivalent to only 5 m extra depth under water.

Comment: Re:$30 Timex (Score 1) 389

"50m or 100m, which are adequate for any practical purpose. Above that you're paying for fantasy value. Watches rated at 200m and above might as well claim a gazillion meters; you'll never be the wiser."

I thought that these ratings have more to do with the reliability/longevity. At least, I've owned two 300 euro "100m" Seiko watches that lost their water-tightness over the course of a few years, because the seals of the crown degraded from exposure to sweat, soap, and the occasional sea water. Repairs were quoted as 150 euros, so I didn't bother.

Now I have a a Pebble.

Comment: Re:Kaspersky Lab (Score 1) 129

by hankwang (#49239359) Attached to: New Evidence Strengthens NSA Ties To Equation Group Malware

With a rainbow table you can brute-force a password if you know the password hash. You need only one login attempt -- and you need the hash, for which you normally need root access to start with, at least for the last 20 years. Unix/Linux passwords have always been stored as salted hashes, which makes rainbow tables not practical. The practical way to brute-force a password is therefore a dictionary attack.

Shortest distance between two jokes = A straight line

Working...