Memory Alpha
Register
Memory Alpha
Line 35: Line 35:
 
I said, "If I know the encrypted version of your password", didn't I? Even without that, OK, well, you know what, YES indeed, knowing the algorithm DOES astronomically narrow the possibilities. If don't know the password BUT I know that the system encrypts it with ROT-13, then I know that there are ONLY 26^n possibilities, even if I don't know the length n, so, I start with n=1 and proceed. But a cipher with mixed cases where numbers and symbols are permitted goes more toward 80^n, which is enourmously larger no matter what the length n is. A completely different scheme, like a true encryption instead of a cipher, yields a number of possibilities going toward (one example) publickeybitlength^privatekeybitlength^messagelength, but in real life many such algorithms have been shown to have weaknesses that reduce the possibilities by astronomical amounts. Or, how about my second example above, in which I show that out of an apparent 14.8x10^18 possibilities, knowledge of the system and algorithm narrowed the possible inputs to 10^5. So if you think that an attacker's knowing something about the system or the algorithm does not help, you're just not informed. I don't know if a "mistake" was made or what, but, there's nothing inconceivable about what was portrayed. Does that background note belong? You decide. [[User:SwishyGarak|SwishyGarak]] 22:03, 25 May 2008 (UTC)
 
I said, "If I know the encrypted version of your password", didn't I? Even without that, OK, well, you know what, YES indeed, knowing the algorithm DOES astronomically narrow the possibilities. If don't know the password BUT I know that the system encrypts it with ROT-13, then I know that there are ONLY 26^n possibilities, even if I don't know the length n, so, I start with n=1 and proceed. But a cipher with mixed cases where numbers and symbols are permitted goes more toward 80^n, which is enourmously larger no matter what the length n is. A completely different scheme, like a true encryption instead of a cipher, yields a number of possibilities going toward (one example) publickeybitlength^privatekeybitlength^messagelength, but in real life many such algorithms have been shown to have weaknesses that reduce the possibilities by astronomical amounts. Or, how about my second example above, in which I show that out of an apparent 14.8x10^18 possibilities, knowledge of the system and algorithm narrowed the possible inputs to 10^5. So if you think that an attacker's knowing something about the system or the algorithm does not help, you're just not informed. I don't know if a "mistake" was made or what, but, there's nothing inconceivable about what was portrayed. Does that background note belong? You decide. [[User:SwishyGarak|SwishyGarak]] 22:03, 25 May 2008 (UTC)
 
:Um...ok...taking this a bit overboard. My point was that simply they didn't state that they knew what it was and thus limited the # of possibilities. You did limit it with stated knowledge (rot-13 example and hash example) so you were able to limit the combinations. I said it's a nitpick. Nothing more. [[User:Morder|Morder]] 22:30, 25 May 2008 (UTC)
 
:Um...ok...taking this a bit overboard. My point was that simply they didn't state that they knew what it was and thus limited the # of possibilities. You did limit it with stated knowledge (rot-13 example and hash example) so you were able to limit the combinations. I said it's a nitpick. Nothing more. [[User:Morder|Morder]] 22:30, 25 May 2008 (UTC)
  +
  +
Just in case you don't know what this topic is about, it's about [http://memory-alpha.org/en/index.php?title=Cold_Station_12_%28episode%29&diff=836984&oldid=836687 this edit] which got reverted with the comment "augments can't change the laws of math". I spoke up here in order to explain why I restored it: that wasn't a good reason to revert the contribution. A good reason may exist, but that isn't it. If anybody thinks there's a nitpick present in the article, one should be free to do something about it. If one thinks the original contribution is a nitpick, it would be pretty hard to argue that the bullet which it got added to is not one. [[User:SwishyGarak|SwishyGarak]] 23:24, 25 May 2008 (UTC)

Revision as of 23:24, 25 May 2008

Episode talk page

Maintenance links

  • T: I AM ERROR
  • A: I AM ERROR
  • N: I AM ERROR
  • P: I AM ERROR
  • C: I AM ERROR
  • CP: I AM ERROR
  • CR: I AM ERROR
  • CT: I AM ERROR
  • D: I AM ERROR
  • M: I AM ERROR
  • Y: I AM ERROR


Removed nit

The following has been charged with nit-pickery and personal opinion and has thus been removed from the article. Re-inclusion of said information should be discussed herein before said re-inclusion can take place. --From Andoria with Love 05:31, 29 January 2007 (UTC)

The Enterprise's sensors are able to tell genetically-engineered humans from regular humans, as Tucker is able to report the Denobulan shuttle has Augments and one human. However, the 100 years more advanced USS Enterprise (NCC-1701) in "Space Seed" is unable to do so. It seems unlikely that any ship's sensors (even as far as the 24th century) would be able to tell the difference, as the Augments were also humans and the only way to tell would be a comprehensive scan of their DNA.
The "However," makes me want to poke someone in the eyeball. Other than that, it is a good point, I think that if you removed everything after "It seems," it would be a notable fact worthy of inclusion. --Bp 09:54, 29 January 2007 (UTC)

Nitpickery?? I've seen several instances of continuity errors mentioned from articles. The NX-01 could tell which lifesigns on a shuttle were regular human and augments, while a ship 100 years more advanced had an augment SITTING IN THEIR OWN SICKBAY and had no clue. That's hardly saying "T'Pol gave a neck pinch in the left shoulder in one shot and the right shoulder in the next." 24 century ship sensors have been able to tell only race, gender, approximate age (TNG: Bloodlines) and and general health (ie- weak life signs). But a ship 200 years inferior can tell manipulations to specific sequences in a human's genetic code and that's somehow personal opinion?? How about:

  • "The Enterprise's sensors are apparently able to tell genetically-engineered humans from regular humans, as Tucker reports the Denobulan shuttle has nine Augments and one human. However, the 100 years more advanced USS Enterprise (NCC-1701) in "Space Seed" was unable to tell there were augments aboard the SS Botany Bay."
It is still a nitpick. Why do you see them in other articles? Because the decision to remove them was only made last summer, so there are 3 or more some odd years of nitpicks people have added. When we notice them, we remove them. --OuroborosCobra talk 05:34, 30 January 2007 (UTC)
I think this is ok: "The Enterprise's sensors are able to tell genetically-engineered humans from regular humans, as Tucker is able to report the Denobulan shuttle has nine augments and one human. In "Space Seed", 100 years later, the USS Enterprise (NCC-1701) was unable to detect the augments aboard the SS Botany Bay."
Maybe it would be better on some sensor page, or the page on augemnts. I say keep it somewhere, sans "However". --Bp 10:28, 30 January 2007 (UTC)

Did the word "however" kill your parents or something? It wouldn't really make sense on the augment page, and while it wouldn't be that unreasonable to put it on the sensor entry it seems most appropriate here. Of course there's no reason it can't be in both. BTW, where is this "no nitpicking" rule? I didn't see it in the FAQs, Policies and guidelines, ie- anywhere rules should be. --Species 8675309 03:36, 31 January 2007 (UTC)

Interesting note

It is interesting to see that the picture with the children listening to Arik Soong has plants growing outside, yet in the episode Cold Station 12 (11 years later) the crew of the Enterprise land on Trialas IV and find it void of all green plant life. It is mentioned that they had to survive, yet the food replicators are also mentioned; this parallels the movie The Wrath of Khan as the Augments also had to survive after their lush planet became a barren wasteland. --203.211.74.138 10:00, 22 November 2007 (UTC)

Encryption algorithm/laws of math

I'm not the original contributor, but I reverted a revert. Before this escalates, let me explain: The "hexadecimal password", at 16 digits, would have 18.4 quintillion possibilities. Somebody noted that if the Augments knew something about the encryption algorithm, they could have narrowed it down to the "few hundred thousand" possibilities stated in dialog. While it's true that nobody can change the laws of math, knowledge of the algorithm can indeed narrow down the possibilities. A real-life example: If I know the encrypted version of your password, and I know that the "encryption" algorithm is ROT-13, then no matter how many characters long your password is, I've narrowed down the decryption possibilities to exactly ONE. No changing of laws of math required. Another real-life example: If I know that your system requires your password to be 5 decimal digits, and the system encrypts this into a hash of 16 hexadecimal digits, there are exactly 100,000 possibilities, even though that hash might appear more complex. See? Knowing something about the algorithm can yield great decryption power. You don't even have to be an Augment. Now: I leave open the question of whether this entire background item is anything but a nitpick. SwishyGarak 18:44, 25 May 2008 (UTC)

You may know the algorithm but that doesn't change the # of possibilities. You say my password may have been encrypted with ROT-13, yet depending on the length of my password there are still 26^n possibilities for my password. No amount of knowledge would change that unless you knew what keys I press when I type my password. In the end I say it's a nitpick. The writers just screwed up. Simple as that. --Morder 21:22, 25 May 2008 (UTC)

I said, "If I know the encrypted version of your password", didn't I? Even without that, OK, well, you know what, YES indeed, knowing the algorithm DOES astronomically narrow the possibilities. If don't know the password BUT I know that the system encrypts it with ROT-13, then I know that there are ONLY 26^n possibilities, even if I don't know the length n, so, I start with n=1 and proceed. But a cipher with mixed cases where numbers and symbols are permitted goes more toward 80^n, which is enourmously larger no matter what the length n is. A completely different scheme, like a true encryption instead of a cipher, yields a number of possibilities going toward (one example) publickeybitlength^privatekeybitlength^messagelength, but in real life many such algorithms have been shown to have weaknesses that reduce the possibilities by astronomical amounts. Or, how about my second example above, in which I show that out of an apparent 14.8x10^18 possibilities, knowledge of the system and algorithm narrowed the possible inputs to 10^5. So if you think that an attacker's knowing something about the system or the algorithm does not help, you're just not informed. I don't know if a "mistake" was made or what, but, there's nothing inconceivable about what was portrayed. Does that background note belong? You decide. SwishyGarak 22:03, 25 May 2008 (UTC)

Um...ok...taking this a bit overboard. My point was that simply they didn't state that they knew what it was and thus limited the # of possibilities. You did limit it with stated knowledge (rot-13 example and hash example) so you were able to limit the combinations. I said it's a nitpick. Nothing more. Morder 22:30, 25 May 2008 (UTC)

Just in case you don't know what this topic is about, it's about this edit which got reverted with the comment "augments can't change the laws of math". I spoke up here in order to explain why I restored it: that wasn't a good reason to revert the contribution. A good reason may exist, but that isn't it. If anybody thinks there's a nitpick present in the article, one should be free to do something about it. If one thinks the original contribution is a nitpick, it would be pretty hard to argue that the bullet which it got added to is not one. SwishyGarak 23:24, 25 May 2008 (UTC)