Computing desk
< January 19	<< Dec \| January \| Feb >>	January 21 >

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

January 20

Representing bits in Magnetic Drum Digital Differential Analyzer

Magnetic Drum Digital Differential Analyzer says that it was the first machine to represent bits as voltages. I checked the reference, and it says that the machine was the first to use voltages for bits instead of pulses, as in ENIAC and UNIVAC I. I've always heard that a high voltage would represent a 1 and a low voltage would represent a 0. So I don't see the distinction between voltages and pulses to represent bits - can someone explain that? Bubba73 ^{You talkin' to me?} 19:35, 20 January 2016 (UTC)[reply]

I don't know much about it, but I think they might be trying to say that ENIAC/UNIVAC used AC pulses, and the MDDDA used DC voltage levels. Without access to the reference, I can't be sure. --Wirbelwind(ヴィルヴェルヴィント) 19:49, 20 January 2016 (UTC)[reply]

At least part of the reference is on Google books, but it has its own entry starting on page 163, which says "In contrast to ENIAC and UNIVAC, which used electrical pulses to represent bits, Maddida was the first computer to use voltage levels ..." Bubba73 ^{You talkin' to me?} 19:59, 20 January 2016 (UTC)[reply]

I think we need to revise some claims on this and related pages. The basic electronic memory device of the ENIAC[1] was the dual triode vacuum tube flip-flop, which definitely represented bits as voltage levels. In addition, ENIAC had mercury delay lines memory, which used physical pulses/waves/ripples in the mercury to represent bits. What confuses some people is the fact that digits were communicated from one unit of the ENIAC to another in pulse form. Things have not changed all that much; the computer I am writing this on has communicates with a SATA hard disk and a USB thumb drive using pulses, but the RAM and CPU use voltage levels. (BTW, in 1953, ENIAC's memory capacity was increased with the addition of a 100-word static magnetic-memory core, adding yet another way to store bits.[2]) --Guy Macon (talk) 21:39, 20 January 2016 (UTC)[reply]

ENIAC didn't have mercury delay lime memory, but most others just after it did. UNIVAC I did. I agree with a change, but I don't understand it well enough. (I stated on the article's talk page that it didn't make sense to me.) I have the book by Reilly that is used as a reference but I don't have the Annals of the History of Computing. I used to have it :-( Bubba73 ^{You talkin' to me?} 22:27, 20 January 2016 (UTC)[reply]

Thanks for catching my error. "When mercury delay lines came up for consideration as internal memory, Lt. Colonel Gillon, as the responsible supervisor for the Ordnance Department, insisted on the tried and tested decade ring counters in spite of the inherently reduced storage capacity. However, in view of the great promise of the mercury delay lines he obtained authorization for a new and separate contract calling for a new machine, using these delay lines. This machine, when completed, was the EDVAC..."[3] --Guy Macon (talk) 15:06, 21 January 2016 (UTC)[reply]

Difference between == and === in JavaScript

I have for several years thought about what exactly is difference between == and === in JavaScript. I know they are supposed to mean "equal" and "strictly equal" but don't know what this actually means in practice. Could someone give me examples where the two operators yield different results with the same operands? JIP | Talk 21:19, 20 January 2016 (UTC)[reply]

> ""==0
true
> ""===0
false
> []==0
true
> []===0
false
> false==0
true
> false===0
false

-- Finlay McWalterᚠTalk 21:43, 20 January 2016 (UTC)[reply]

Take care though, because JavaScript is treacherous. Just look at this examples:

> 1 == "1"     // true, automatic type conversion for value only
> 1 === "1"    // false, because they are of a different type

--Scicurious (talk) 22:00, 20 January 2016 (UTC)[reply]

How does a cracking program know when an encrypted string/file has been decrypted?

If it tests a password on an encrypted message, couldn't a wrong password output another string, and only the true password output the right string? For example, if the encrypted string is "no seuabn cwdiueit d osf oidistshi", a wrong password would output "stce doiitdiiu u nofbsiho nwdessa", but the right password would output "discussion about how it is defined". That would hugely delay any brute forcing attack, wouldn't it?--Scicurious (talk) 22:36, 20 January 2016 (UTC)[reply]

It's pretty quick to check each word against a database containing the English language. One technique to stymie this is to spell words improperly, so the program doesn't think it found anything useful. StuRat (talk) 22:55, 20 January 2016 (UTC)[reply]

^{[citation needed]}. It would be a very weak cracking program that relies on just dictionaries. See Ciphertext-only attack and this article. In a pinch, any text that has a character distribution that is far from random is a good candidate to inspect manually. --Stephan Schulz (talk) 23:06, 20 January 2016 (UTC)[reply]

What if the encrypted information is not human written text? It could well be a list of random passwords, credit cards numbers, or accounting information. --Scicurious (talk) 23:20, 20 January 2016 (UTC)[reply]

In general, the decrypted text will have a lot less entropy per data bit than a scrambled version (basically, because plaintexts are from the the small set of documents that make sense to us, while cyphertexts are typically from the much larger set of all documents). That is not always true - if you have a cyphertext that contains only have truly random passwords and no structure information and no known plaintext, there is no way to decrypt the file. Similarly, a good compression algorithm removes redundancy and hence increases entropy per data bit, which makes compressed files harder to decode. --Stephan Schulz (talk) 00:07, 21 January 2016 (UTC)[reply]

Yes, various randomness tests applied to brute-force recovered candidate plaintexts should be able to either find the correct key or winnow the match set down to some values that can practically be examined by other methods (e.g. file magic). I wrote a little program that brute-force decodes a (small) AES keyspace and does a Kolmogorov–Smirnov test (which is probably overkill) analysis on the recovered plaintext. By sorting for the result with the lowest p-value (when compared to a uniform distribution) it can comfortably distinguish the correct key - I've tried with text, jpg, mp3, and gzipped-jpg. As Stephan says, it won't work for genuinely random input data, but in practice the kind of thing that someone with the resources to bruteforcing a real problem will be looking for are really unlikely to be genuinely random. -- Finlay McWalterᚠTalk 16:52, 21 January 2016 (UTC)[reply]

At this point, one might thing to oneself "tee hee, then I shall fill my disk with lots of random data, to thwart those brute forcers". Indeed it would, but if one is in (or visits) a country with a mandatory key disclosure law (in law, or just de facto) then one might find oneself in the invidious position of being unable to "decrypt" the random data, and unable to prove that it's actually just random garbage and that one isn't failing to comply with the authorities' "request". -- Finlay McWalterᚠTalk 17:06, 21 January 2016 (UTC)[reply]

If you know it is text a quick check is that all the characters are printable, in fact just do a check for the characters being 0x20 or more plus some others like null, tab, newline or linefeed. If the text has more than about three times as many characters as there are bits in the key this test will start getting to only allowing the correct key through. For shorter strings one would need to do extra tests as above and you just can't tell for text which is around the same length as the key. Dmcq (talk) 00:29, 21 January 2016 (UTC)[reply]

That would apply if it's encoded in ASCII or some other code with unprintable characters, but the OP's example makes me think they are using a smaller character set, perhaps only 27 (lowercase A-Z plus space). StuRat (talk) 01:03, 21 January 2016 (UTC)[reply]

It's recommended to compress before encrypting, to make known plaintext attacks harder. So I wouldn't necessarily expect a successful decryption to yield printable characters. (Of course, with that said, one could always just attempt the decompression and, if it failed, assume that the decryption was incorrect.) —Steve Summit (talk) 23:11, 21 January 2016 (UTC)[reply]

Some encryption / decryption schemes are actually designed to have embedded headers or checksums to quickly check if a decryption attempt resulted in reasonable results. Of course whether such a quick check is present will depend entirely on the encryption approach used. Dragons flight (talk) 01:56, 21 January 2016 (UTC)[reply]

(ec) Most encrypted messages have a MAC to guarantee integrity, or failing that at least an encrypted checksum or magic number so that if you mistype the password you will get a helpful error message instead of gibberish. Otherwise, you have to know or guess something about the plaintext, which is called a crib. -- BenRG (talk) 01:59, 21 January 2016 (UTC)[reply]