Computing desk
< August 30	<< Jul \| August \| Sep >>	September 1 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

August 31[edit]

Googling caribou in reindeer country[edit]

I noticed that Googling for "reindeer" in the Canadian woods brings up the Caribou factbox instead, but titles it "Reindeer". Can a Scandanavian (or any European, secondly) confirm or deny that Googling for "caribou" brings up Reindeer titled "Caribou"? InedibleHulk (talk) 02:09, 31 August 2016 (UTC)[reply]

For me in the UK, googling "caribou" gets me Dan Snaith. Googling "reindeer" gets me the same result as you. Rojomoke (talk) 03:19, 31 August 2016 (UTC)[reply]

That's even weirder than I feared. Caribou gets caribou for me, but the box is still called "Reindeer". InedibleHulk (talk) 03:33, 31 August 2016 (UTC)[reply]

You can click on the "feedback" button below the box to report this.--Shantavira|^{feed me} 06:45, 31 August 2016 (UTC)[reply]

I'm in Denmark and dont get any factbox (Google Knowledge Graph) on "reindeer" or "caribou". On "reindeers" and "caribous" I get the same factbox titled "Reindeer" but with a linked paragraph from our Caribou article. Note that caribou and reindeer are sometimes used as synonyms as our articles say. See Template:HD/GKG for the limited relationship between a Google Knowledge Graph and Wikipedia. PrimeHunter (talk) 10:56, 1 September 2016 (UTC)[reply]

Good to know, thanks. And yeah, they're basically the same creatures in different environments, so it's not something that really needs to be fixed. Just a bit of an odd choice for the Googlebot. If New World porcupine starts redirecting to Old World porcupine (or vice versa), that would be serious. InedibleHulk (talk) 00:03, 2 September 2016 (UTC)[reply]

Layering different encryption methods[edit]

IIRC, it's a standard result that layering several encryption methods does not increase the security compared to the best of the employed methods. But is that really true? I can see the result for perfect algorithms, when the only possible attack is brute force. But real cyphers often have other weaknesses that make breaking the cypher a lot easier than simply brute-forcing it. Wouldn't layering different algorithms (say AES/Rijndael, 3DES and Blowfish) mask the respective weaknesses of each individual algorithm? --Stephan Schulz (talk) 06:07, 31 August 2016 (UTC)[reply]

AFAICT multiple encryption doesn't seem to mention that "layering several encryption methods does not increase the security compared to the best of the employed methods" but does suggest care needs to be taken in implementation. There's also [1] by a cryptographer. The general consensus I'm getting also in non RS [2] is that multiple encryption may have some advantages but you have to be careful about implementation and it doesn't help with what tends to be the biggest weakness in encryption systems. Nil Einne (talk) 09:28, 31 August 2016 (UTC)[reply]

Much of this depends on HOW you do multiple encryption. What if I take one key and use that key for 100 different encryption schemes, one after the other. Once you figure out the key for the final encryption scheme, the rest are quickly decrypted. It is like locking a door with a dozen locks that all use the same key. So, asking the user to type in one key for encryption and then using that for all forms of encryption won't work. What if I go the DVD/BluRay method and I package the key with the encryption? I ask for one encryption key from the user and then pack random keys for all the other encryption methods into the encrypted code. Once you decrypt the first stage with the key from the user, it will contain the key for the next stage, which contains the key for the next stage, and so on. It is like locking a box with a padlock. Inside that is a smaller box with they key taped to it. Inside that is a smaller box with the key taped to it, etc... You can hard-code how the key the user types in is manipulated to create a vast set of keys for multiple encryption schemes. That assumes that people trying to hack your system won't know anything about disassembler techniques. Obviously, they will. You are essentially back to the one key for all encryption schemes again. So, you end up with asking the user for a vast set of keys, one for each encryption scheme. Commonly, we ask users for two or three forms of "key". We ask for a password. Many times, we ask for the user's public key from a public/private keyset. It is also becoming common to do something with the user's phone. That is just three forms of security for a single transaction. If you want to get into multiple forms of encryption, imagine being asked for 8 unique passwords to encrypt something - and then you need them in the reverse order to decrypt on the other end. While it is functional on paper, it isn't really any better than one good encryption scheme. 209.149.113.4 (talk) 11:31, 31 August 2016 (UTC)[reply]

You have it backwards: layering several encryption methods can't decrease the security compared to the best one (if they use independent random keys). Proof: if it could, the attacker could break the best method alone by composing it with the others, which is a contradiction.

Layered encryption can certainly increase security, even if you use the same cipher for each layer: 3DES is an example. But you have to be careful: "2DES" would be hardly more secure than DES because of the meet-in-the-middle attack, and 3DES can be broken in 2¹¹² (not 2¹⁶⁸) time by the same attack.

If you lock your valuables in a safe and lock that safe in another safe, a vulnerability in one safe isn't enough to get the valuables. If you lock your valuables in a safe and lock the key to that safe in another safe, a vulnerability in either safe is enough to get the valuables. When people say "a system is only as strong as its weakest link", they're talking about the latter situation. In TLS, for example, the payload is protected by a symmetric cipher, the key to that cipher is protected by an asymmetric cipher, the key to that cipher is protected from tampering by a certificate authority, that certificate authority is certified reliable by another one, and so on up to a trusted root that ships with the web browser. If you can compromise any link of that chain (the chain of trust), you can compromise the payload. -- BenRG (talk) 19:20, 1 September 2016 (UTC)[reply]

I would say that layering multiple encryptions can be correctly implemented as a form of defense in depth. This is widely regarded as good practice.

For example, I (sometimes) use 802.11ac with WPA2 and I also use secure sockets (TLS). On top of this, I sometimes use application encryption.

When a serious error was discovered in some versions of SSL - CVE-2014-0160 - I had confidence that my potential exposure was lower than it could have been. As Stephan Schultz has aptly pointed out, " real (algorithms) often have other weaknesses...." The bug in that case was not actually an error in the cryptographic mathematics. It was, roughly speaking, a privilege escalation bug that took advantage of an error in the memory allocation code.

Nimur (talk) 22:05, 31 August 2016 (UTC)[reply]

I think you have some misconceptions. WPA2 and friends only encrypt traffic while it travels via radio waves from you to the access point. You should definitely use WPA(2), but it only protects you from someone physically nearby sniffing your Wi-Fi transmissions. None of what you mentioned made you any safer from Heartbleed. Heartbleed is a "buffer over-read" that allows an attacker to read data they shouldn't be able to from the server's memory. An attacker can use this to grab all your data in plaintext from the server, or obtain the server's private key and decrypt your traffic. For that matter, Heartbleed works on clients as well, so if you were using a vulnerable OpenSSL version, an attacker could have exploited you if they were able to get you to connect to a system they controlled. --47.138.165.200 (talk) 02:03, 1 September 2016 (UTC)[reply]

I understand: my point was, an attacker can't sniff my SSL traffic (or try to attack my SSL server) if they can't get on my WiFi network (in my case, I do not publish my SSL services to the external network). Even if I have a compromised SSL server, having my link layer remain encrypted provides a different, orthogonal layer of protection. And even if the attacker breaks all those layers, if my SSL session is transferring data files that are additionally encrypted, the attacker still cannot make use of a successful breach of my network traffic. In principle, the attacker could use Heartbleed to disclose memory, but if the contents of that memory are just more encrypted data, there is minimal harm from the unwanted disclosure! Obviously, having all the encryption schemes operating correctly provides even more protection. But by encrypting at many different layers, an attacker isn't successful unless every single layer of the system is compromised. Nimur (talk) 07:21, 1 September 2016 (UTC)[reply]

An attacker can be somewhere other than on your LAN. And on the Web you frequently don't have the option of adding encryption layers. Your bank probably doesn't let you force your online banking to use only PGP-encrypted messages. Anyway this is a largely academic discussion; most real-world attacks involve attackers breaking into the systems of banks, merchants, etc. or malware being planted on your computer, neither of which will be impeded by encrypting your traffic. --47.138.165.200 (talk) 03:11, 2 September 2016 (UTC)[reply]

What is "just an academic exercise" to some readers is "just a day job" for others!

Consider Apple Pay. Yes, major financial institutions do engage with Apple, and both sides do emplace (and enforce) their individual technical security needs on the protocol stack! Apple's major press statements explain, in simple terms, how financial data is protected at many layers - and if you would like more technical information, Apple's chief of security just spoke at BlackHat a few weeks ago in an unprecedented public session exploring the technology that makes Apple software and hardware more secure!

The iOS Security Guide also describes how Apple Pay works. Even if a malicious attacker breaks NFC and eavesdrops or tampers - analogous, in some respects, to "breaking the WPA2 encryption key on a WiFi network" - the attacker cannot make forward progress to compromise or replay a financial transaction - because of a different, orthogonally encrypted part of the security system.

Some additional information is in our article on Apple Pay in the NFC protocol stack.

The long and short of it - encrypt everything everywhere, at every layer, so that a single point of failure is harder to exploit.

On iPhone, Apple encrypts (and/or cryptographically verifies) the network traffic, the user data, the application-layer protocol, the file system, the executable code, ... because security is taken very seriously.

Nimur (talk) 16:51, 2 September 2016 (UTC)[reply]

Mistake - Age Of Death[edit]

On Wikipedia when a person dies this displays in their info box Died 1st January 2000 (aged 12) (change date/age) I've recently noticed a mistake in one so I went to change I was really confused by your coding, there must be easier ways or ones that don't cause mistake Like: 1.Just Write it like I did on 2nd line of this article or 2. Get Wikipedia to calculate the age byear- dyear and the bmonth-dmonth if =>1 -1 from age. (Or similar)

69.165.177.132 (talk) 12:34, 31 August 2016 (UTC)[reply]

I think you might want to ask this question on the wikipedia: help desk instead of here. Margalob (talk) 02:20, 1 September 2016 (UTC)[reply]