SHARE
TWEET

derp_more.txt

a guest Apr 12th, 2014 139 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. **** BEGIN LOGGING AT Thu Mar 20 20:06:54 2014
  2.  
  3. Mar 20 20:06:54 <ninjashogun>   hello :)
  4. Mar 20 20:07:06 <asciilifeform> hi
  5. Mar 20 20:08:05 <ninjashogun>   I've further analyzed the high-level Cardano architecture and have some extremely confidential architectural information I would like to donate to you.  You should not discuss it in public.
  6. Mar 20 20:08:33 <ninjashogun>   (it's not that it's insecure per se - you'll see in a sec)
  7. Mar 20 20:08:36 <asciilifeform> telepathy?
  8. Mar 20 20:08:54 <ninjashogun>   No, it is the following fact/vector/etc inherent in the chosen architecture.
  9. Mar 20 20:09:03 <asciilifeform> fire away
  10. Mar 20 20:09:34 <ninjashogun>   So, because it is going to be a USB device, for better or for worse there are standard USB devices that are usually installed silently and without much change or warning to the user.  And so, suppose someone didn't trust you / Cardano:
  11. Mar 20 20:10:05 <asciilifeform> if you had read the announcement on mp's site, you would know that the device emulates a standard usb hard drive.
  12. Mar 20 20:10:14 <asciilifeform> this is not a secret.
  13. Mar 20 20:10:42 <ninjashogun>   then they could fear that after behaving normally for 6 months, 1 year, 2 years, 5 years, or once in a blue moon, when connecting, the Cardano will expose itself as a USB host, and on that virtual host emulates/adds  both the normal Cardano device as well as a USB keyboard.
  14. Mar 20 20:11:06 <ninjashogun>   (or just a USB keyboard once in a blue moon instead of the normal Cardano device characteristics).
  15. Mar 20 20:11:38 <ninjashogun>   Now, a USB keyboard is usually installed used without any further intervention from the user.  It is silently added, because of a measure of implicit security trust between the user (who could type anything they want anyway) and the USB connection next to the user.
  16. Mar 20 20:11:42 <asciilifeform> let's suppose a malicious 'cardano.' it could do 1000 things
  17. Mar 20 20:11:47 <asciilifeform> such as, for instance, generating weak keys
  18. Mar 20 20:11:53 <ninjashogun>   wait a moment.
  19. Mar 20 20:11:55 <ninjashogun>   yes, that's true
  20. Mar 20 20:12:04 <asciilifeform> or, as you described, 'rubber ducky'
  21. Mar 20 20:12:06 <ninjashogun>   but under normal circumstances the damage would be limited to misbehaving, being weak, etc.
  22. Mar 20 20:12:12 <asciilifeform> (this is a commercial pentesting product you may be familiar with)
  23. Mar 20 20:12:15 <ninjashogun>   please let me finish :)
  24. Mar 20 20:12:32 <asciilifeform> 'evil keyboard' is old hat
  25. Mar 20 20:12:42 <asciilifeform> presented at defcon '10 i believe.
  26. Mar 20 20:13:01 <ninjashogun>   So, because USB's are physically trusted and silently added, it can be added as a USB device that can then generate any input.  It could then launch, as though it were the user, input meant to do something specific (such as recreate a programmed shell script, etc.)
  27. Mar 20 20:13:30 <asciilifeform> as i said - this among 1000 things a malicious usb device could do.
  28. Mar 20 20:13:54 <ninjashogun>   The basic issue is that there is a trust model where the Operating Systems do not care about USB input devices, however the user would not think of the device as potentially compromising their PC.
  29. Mar 20 20:13:54 <asciilifeform> there are also interesting attacks which involve the bus itself, or enumerating as a device for which a given os has buggy drivers, etc.
  30. Mar 20 20:14:08 <ninjashogun>   Yes, those are similar.
  31. Mar 20 20:14:37 <asciilifeform> i should probably note here that (again this is not a secret) my day job consists of studying such matters.
  32. Mar 20 20:14:38 <ninjashogun>   But the difference between keyboard (or 'evil keyboard' as you put it) is 1) the Cardano is not actually physically a keyboard 2) nothing needs to be be buggy.  This is the explicit trust of the operating system when usb keyboards are added.
  33. Mar 20 20:14:50 <asciilifeform> yes, this is, at this point, a classic attack.
  34. Mar 20 20:14:58 <asciilifeform> demonstrated in public many times.
  35. Mar 20 20:15:26 <asciilifeform> let me guess - you would like to ask - how does a given user know that his particular unit is not malicious in this, or the 999 other ways.
  36. Mar 20 20:15:27 <ninjashogun>   So in this case in what way can you not require that the user have to trust you completely, and explicitly?
  37. Mar 20 20:15:36 <ninjashogun>   No, not in this or 999 other ways.
  38. Mar 20 20:15:57 <ninjashogun>   Only in this particular way since I am not asking about exploiting some buffer overflow.  This is if everything behaves explicitly by design.
  39. Mar 20 20:16:05 <ninjashogun>   including the operating system.
  40. Mar 20 20:16:20 <asciilifeform> answer is simple, though i do not know if you will like it
  41. Mar 20 20:16:31 <asciilifeform> it depends on the particular user's level of paranoia.
  42. Mar 20 20:16:50 <asciilifeform> a user who does not trust me - or mp - or his post office - is faced with a choice
  43. Mar 20 20:16:55 <ninjashogun>   I don't think that's a very good answer for architectural decisions :)
  44. Mar 20 20:17:15 <asciilifeform> the 'gold standard' is - he can actually construct his own cardano.
  45. Mar 20 20:17:37 <asciilifeform> (literally. sufficient information will be published to make this possible)
  46. Mar 20 20:18:33 <asciilifeform> if the user trusts my component supplier -and- s.nsa - but not his post office - he can verify the firmware checksum (signed with my personal key)
  47. Mar 20 20:18:39 <ninjashogun>   Yes.  Point being is his own cardano could also become an attack vector if someone manages to reflash it.  That is to say, the "worst thing that can happen" (risk mitigation) is no longer "the cardano divulges its key" or "the cardano loses its memory state and private key".  Insterad it's: "The previously secure PC becomes totally insecure because the Cardano is a vector that explicitly roots
  48. Mar 20 20:18:39 <ninjashogun>   it through an architecturally accepted means."
  49. Mar 20 20:19:20 <ninjashogun>   That is quite a bit worse than if it had to be "through a buggy driver or 0-day" because those can be patched.
  50. Mar 20 20:19:20 <asciilifeform> cardano is built in such a way that it cannot be re-flashed from the usb connector
  51. Mar 20 20:19:40 <asciilifeform> but it is theoretically possible that a captured unit can be re-programmed to behave like some other device, certainly.
  52. Mar 20 20:19:41 <ninjashogun>   I mean in any way.  If the chip were silently replaced by another that doesn't even have the caradano's signing information.
  53. Mar 20 20:19:48 <asciilifeform> entirely possible
  54. Mar 20 20:20:09 <ninjashogun>   But it's not just possible - this is a mobile device that a user can take with him, while leaving his secure computer behind a faraday cage, for example.
  55. Mar 20 20:20:12 <asciilifeform> it is also possible that the victim's keyboard, or entire pc, is replaced
  56. Mar 20 20:20:20 <asciilifeform> or he himself is replaced with a double
  57. Mar 20 20:20:21 <asciilifeform> etc
  58. Mar 20 20:20:53 <ninjashogun>   So if someone manages to nab it from him for 1 instant and replace it with a decoy, then under correct architecture the thing that happens is the attacker now has his physical Cardano, as well he sees that his decoy no longer functions.  It no longer signs properly.  Or he sees that it's not his.
  59. Mar 20 20:21:14 <ninjashogun>   the second he after "as well" is the victim
  60. Mar 20 20:21:24 <asciilifeform> a malicious actor could certainly replace a cardano with a pseudo-cardano
  61. Mar 20 20:21:42 <asciilifeform> disassembling the unit, extracting keys, and pulling switcheroo
  62. Mar 20 20:21:54 <ninjashogun>   Under correct architecture nabbing the Cardano and replacing with a decoy should result in: a) attacker has physical cardano.  b) victim sees he nolonger has it when he gets home, or it no longer works properly.
  63. Mar 20 20:21:55 <asciilifeform> he could also simply walk away with the stolen device and use it as he wishes.
  64. Mar 20 20:22:16 <ninjashogun>   But under the present architecutre, B becomes: "This can become an attack vector that roots a PC that had been totally secure"
  65. Mar 20 20:22:52 <ninjashogun>   So, the second point you mentino "he could simply walk away with the stolen device and use it as he wishes" is a true vector as well.  Have you considered any mitigation strategies by the way?
  66. Mar 20 20:22:52 <asciilifeform> incidentally
  67. Mar 20 20:23:10 <asciilifeform> anyone concerned with the 'rubber duck' attack (the common name for the pseudo-keyboard trick)
  68. Mar 20 20:23:19 <asciilifeform> can carry out very simple countermeasures
  69. Mar 20 20:23:30 <asciilifeform> my particular machine, for instance, does not enumerate usb keyboards.
  70. Mar 20 20:23:37 <asciilifeform> it's a 1-line patch under linux
  71. Mar 20 20:23:49 <ninjashogun>   What happens when you add a USB host controller?
  72. Mar 20 20:23:52 <asciilifeform> same thing
  73. Mar 20 20:23:54 <ninjashogun>   (such as a hub)
  74. Mar 20 20:24:02 <ninjashogun>   That is good, but requires a patch.
  75. Mar 20 20:24:05 <asciilifeform> certainly.
  76. Mar 20 20:24:14 <ninjashogun>   You should probably suggest that patch explicitly (in the documentation and on your page).
  77. Mar 20 20:24:27 <ninjashogun>   If you suggest this patch it is one resolution to the architectural flaw.
  78. Mar 20 20:24:27 <asciilifeform> it is common knowledge among those concerned with such matters
  79. Mar 20 20:24:33 <asciilifeform> if you don't believe me, search.
  80. Mar 20 20:24:48 <ninjashogun>   I know.  But it would improve your product architecture today.
  81. Mar 20 20:25:02 <asciilifeform> likewise, resisting physical attack is a matter for the makers of safes, locks, alarms - not us.
  82. Mar 20 20:25:17 <asciilifeform> cardano is explicitly not designed as a physically hard target
  83. Mar 20 20:25:24 <ninjashogun>   You've said the same thing about wifi leaking information about nearby circuits (not connected to the wifi module or explicitly going over the wire), including the CPU.  That's hardly "common knowledge" :)
  84. Mar 20 20:25:41 <ninjashogun>   asciilifeform let's hold off on "B" for a moment.
  85. Mar 20 20:25:53 <asciilifeform> it is common knowledge among those professionally concerned with actual security
  86. Mar 20 20:25:53 <ninjashogun>   (perhaps what you call physical attack)
  87. Mar 20 20:26:03 <asciilifeform> physical attack - theft, substitution, fire, etc
  88. Mar 20 20:26:49 <ninjashogun>   If you include that as an explicit step in your instructions, before the Cardano is properly usable on a PC, it reduces by over 99% the attack surface the Cardano can mount through architecturally accepted means.
  89. Mar 20 20:27:03 <ninjashogun>   It does not require nearly the same level of trust in you.
  90. Mar 20 20:27:13 <asciilifeform> include what?
  91. Mar 20 20:29:44 <ninjashogun>   Include a line stating: "IMPORTANT SECURITY NOTE: Before you can use a Cardano securely, you must include the following patch on Linux () Mac () and Windows () [j/k].  Following this step you will no longer have to trust the Cardano as a USB device that can behave in any other way other than as a mass storage device, for example by adding a keyboard which can type a script.  This patch would al
  92. Mar 20 20:29:44 <ninjashogun>   so protect you against this vector should your Cardano be nabbed and replaced with a USB emulator, though in this scenario specific privilege escalation vectors might still exist on patched systems, as 0-days."
  93. Mar 20 20:30:19 <ninjashogun>   that text is generic, it's not very well-written but I mean something like that.
  94. Mar 20 20:30:28 <ninjashogun>   I would consider this architectural fix correct and acceptable.
  95. Mar 20 20:30:29 <asciilifeform> i suppose i ought to explain something, though i was fairly certain that it is obvious. a prospective buyer who does not trust me, or, more importantly, MP, should not buy a cardano.
  96. Mar 20 20:30:47 <asciilifeform> because there are numerous other dirty tricks that could be contained therein
  97. Mar 20 20:31:02 <asciilifeform> that no amount of patching will protect against.
  98. Mar 20 20:31:13 <ninjashogun>   asciilifeform the point is to mitigate what happens if they do trust you but something bad happens.  It's called attack mitigation.
  99. Mar 20 20:31:18 <ninjashogun>   security is not all or nothing.
  100. Mar 20 20:31:33 <asciilifeform> the 'something bad' in this case is...
  101. Mar 20 20:31:54 <asciilifeform> an enemy substitutes a faux-cardano? he could easily substitute any other usb appliance purchased by the victim
  102. Mar 20 20:32:03 <asciilifeform> e.g. keyboard proper, mouse, thumb drive
  103. Mar 20 20:32:11 <ninjashogun>   Let me give you an example.  I worked at  a telecommunications company which did conferencing software.  Their software had a huge hole.  After registering, you were given the primary key of your account, and by simply changing it (for example you could just change to the account before), you could bill any amount of services to somebody else's account.
  104. Mar 20 20:32:34 <ninjashogun>   (asciilifeform yes, exactly.  But after the patch "any other usb appliance" could only act as a mass storage device, nothing else.)
  105. Mar 20 20:32:47 <asciilifeform> actually there are thumb drives with generic microcontrollers
  106. Mar 20 20:32:52 <ninjashogun>   The solution is, obviously, that the user MUST authenticate and receive a token associated with the authenticated account, to bill to that account.
  107. Mar 20 20:32:54 <asciilifeform> that can be re-flashed and act as keyboard, etc.
  108. Mar 20 20:32:57 <ninjashogun>   yes
  109. Mar 20 20:33:07 <asciilifeform> for that matter, an enemy can sell you a thumb drive with arbitrary electronics inside
  110. Mar 20 20:33:09 <ninjashogun>   but if the patch explicitly keeps USB drives from being enumerated, you've mitigated that vector.
  111. Mar 20 20:33:11 <ninjashogun>   yes
  112. Mar 20 20:33:31 <ninjashogun>   but if Linux will only mount a mass storage device but stops autoenumerating USB devices, you've mitigated it for all of the above that you've just mentioned.
  113. Mar 20 20:33:35 <ninjashogun>   so to get back to my example:
  114. Mar 20 20:34:10 <ninjashogun>   The solution is to receive a token associated with the authenticated account.  And if you don't have another account's token, you can't just bill to them.  This theoretically closes the loophole.
  115. Mar 20 20:34:26 <asciilifeform> how does this relate to the matter at hand?
  116. Mar 20 20:34:28 <ninjashogun>   But we went farther, and at my suggestion users were no longer given their primary keys, but instead a hash salted with a secret.
  117. Mar 20 20:34:47 <ninjashogun>   This meant that a user could not register, and then automatically know another valid account (by decrementing, or waiting a while and incrementing.)
  118. Mar 20 20:35:16 <ninjashogun>   So that even if the vector remained, and some part allowed unauthenticated billing to an account just knowing that account number, you still didn't know anyone's account number except through an outside channel.
  119. Mar 20 20:35:18 <asciilifeform> this is SOP in any online service where the author had half a brain
  120. Mar 20 20:35:40 <asciilifeform> no great discovery, this.
  121. Mar 20 20:35:47 <ninjashogun>   But you see - it closes a vulnerability but also mitigates what would have happened if the vulnerability had remained open.
  122. Mar 20 20:36:03 <ninjashogun>   because even if authentication were NOT required, it would be very good mitigation if there is no way to guess active account ID's.
  123. Mar 20 20:36:07 <asciilifeform> closing a vulnerability, by definition, mitigates 'what would have happened'
  124. Mar 20 20:36:11 <asciilifeform> or do i misunderstand
  125. Mar 20 20:36:17 <ninjashogun>   Yes.
  126. Mar 20 20:36:37 <ninjashogun>   Because if you close the vulnerability, it can open back up.  If you close it by requiring authentication, then it opens back up if there is any way to bypass authentication.
  127. Mar 20 20:36:57 <asciilifeform> if you're willing to listen for a moment, i will explain my approach.
  128. Mar 20 20:37:00 <ninjashogun>   But if you BOTH close the vulnerability, and mitigate/reduce the fallout were it to reopen, then it wouldb e stronger.
  129. Mar 20 20:37:03 <ninjashogun>   yes, okay.
  130. Mar 20 20:37:10 <asciilifeform> when you go to a hardware store, you can buy, say, an electric saw
  131. Mar 20 20:37:18 <asciilifeform> and it will come with a thick booklet of warnings of various kinds
  132. Mar 20 20:37:25 <asciilifeform> about how to avoid detaching your fingers
  133. Mar 20 20:37:50 <asciilifeform> but if you buy a saw from a 'professional' outlet which caters to construction contractors, it will come with no such thing
  134. Mar 20 20:38:13 <asciilifeform> and will, in general, be a more powerful if dangerous instrument. because it presumes that the buyer is competent in operating a saw.
  135. Mar 20 20:38:35 <asciilifeform> and knows all that there is to know about keeping his fingers attached while near a turning blade.
  136. Mar 20 20:38:38 <ninjashogun>   Yes, but it may well have a resettable circuit breaker inside instead, that trips if it's dropped in a bucket of paint.
  137. Mar 20 20:38:49 <ninjashogun>   it might very well have stronger protections in some senses.
  138. Mar 20 20:38:52 <asciilifeform> it is not my intention to run an academy on computer security in general.
  139. Mar 20 20:38:58 <ninjashogun>   I agree with you.
  140. Mar 20 20:39:10 <ninjashogun>   Let me put it to you this way.  What happens if the user doesn't trust you?
  141. Mar 20 20:39:25 <asciilifeform> the buyer of the product (cardano) is presumed to be competent and aware of the intrinsic limitations.
  142. Mar 20 20:39:27 <ninjashogun>   Or, if you receive a competitor who copies your MO and produces something untrustworthy.
  143. Mar 20 20:39:52 <asciilifeform> the user who does not trust me (or mp) - and why should he ? - can purchase a product from someone he does trust. or build his own.
  144. Mar 20 20:39:59 <ninjashogun>   The current architecture is as follows: "In theory you are giving us the easy ability to silently root 100% of unpatched Linux systems."
  145. Mar 20 20:40:16 <ninjashogun>   Yes, but it's a matter of degree.  What are you asking them to trust you with?
  146. Mar 20 20:40:34 <asciilifeform> btw the 'rubber duck silently roots' claim is exaggerated.
  147. Mar 20 20:40:40 <ninjashogun>   Most of the 999 scenarios you listed,you're asking them to trust that you won't try to escalate a 0-day USB driver bug on Debian to gain root access.
  148. Mar 20 20:40:44 <asciilifeform> usb keyboard is a 1-way channel
  149. Mar 20 20:40:54 <ninjashogun>   This is true, yes.
  150. Mar 20 20:41:06 <asciilifeform> which means, for instance, that it has no way of knowing that victim has just typed 'sudo bash' and that now is the time to inject 'rm -rf /', say
  151. Mar 20 20:41:07 <ninjashogun>   But most Linuxes have command combinations to do a variety of things such as dropping out of x briefly
  152. Mar 20 20:41:13 <ninjashogun>   Yes
  153. Mar 20 20:41:17 <asciilifeform> mine doesn't
  154. Mar 20 20:41:19 <asciilifeform> mp's doesn't
  155. Mar 20 20:41:29 <asciilifeform> no one i know uses this kind of setup.
  156. Mar 20 20:41:35 <ninjashogun>   Are you sure?
  157. Mar 20 20:41:39 <asciilifeform> quite.
  158. Mar 20 20:41:46 <asciilifeform> because this is basic.
  159. Mar 20 20:42:03 <ninjashogun>   Are there standard USB devices that would make it two-way?
  160. Mar 20 20:42:13 <asciilifeform> specifically keyboard?
  161. Mar 20 20:42:14 <asciilifeform> nope.
  162. Mar 20 20:42:18 <ninjashogun>   No, not keyboard.
  163. Mar 20 20:42:21 <ninjashogun>   Any standard USB device.
  164. Mar 20 20:42:34 <ninjashogun>   (That would be mounted automatically and come with drivers on, say, Ubuntu and Debian.()
  165. Mar 20 20:42:43 <asciilifeform> well, there are attacks which involve malformed packets, or enumerating as a device whose driver is buggy
  166. Mar 20 20:42:49 <ninjashogun>   which would allow the Cardano to learn what the screen or user is doing
  167. Mar 20 20:42:52 <asciilifeform> but nothing involving standard usb commands.
  168. Mar 20 20:43:24 <ninjashogun>   There is no kind of USB peripheral that would expose any part of the current state of the user's PC (what is open, how the screen looks, what the user is typing on antoher keyboard, etc)?
  169. Mar 20 20:43:31 <asciilifeform> incidentally, the standard usb 'device classes' are well-documented and you are invited to read the standards on your ow.
  170. Mar 20 20:43:32 <asciilifeform> n
  171. Mar 20 20:44:21 <asciilifeform> no standard usb peripheral, behaving as specified (that is, not relying on kernel bugginess) does this.
  172. Mar 20 20:44:49 <asciilifeform> if you discover a counter-example, don't tell me! tell 'vupen.' or any one of 100 other outfits that will pay.
  173. Mar 20 20:44:55 <asciilifeform> you could handily fund your operation this way.
  174. Mar 20 20:45:29 <ninjashogun>   I suppose it could do the following.  If it is 4 AM it could try pressing enter once, then writing a small file to its mass storage device through one very short cat command and pressing enter.  if it is written then it can write the rest of the script, otherwise it can press delete as many times as it has entered characters (including the enter)
  175. Mar 20 20:45:53 <ninjashogun>   by "if it is written" I mean "if the file is written".  This would be a way it can learn if it is in bash.
  176. Mar 20 20:46:16 <ninjashogun>   As it undoes what it has just entered, in case it's in a text processor it can remove the attempt.  If it is not in a text processor, not in bash, there is a good chance it would go undetected.
  177. Mar 20 20:46:28 <asciilifeform> in bash & presently 'cd'd into the mounted volume?
  178. Mar 20 20:46:44 <ninjashogun>   doesn't the volume mount to a standard location?
  179. Mar 20 20:46:54 <asciilifeform> again, not on my box
  180. Mar 20 20:46:59 <asciilifeform> or any other educated person's
  181. Mar 20 20:47:20 <asciilifeform> you need to understand who the intended audience is.
  182. Mar 20 20:47:48 <asciilifeform> i.e. persons who have already familiarized themselves with state-of-the-art in 'hygiene', but are not satisfied.
  183. Mar 20 20:48:29 <ninjashogun>   if you type 'lsusb' can the Cardano tell it has just been typed?
  184. Mar 20 20:48:33 <asciilifeform> also understand that neither i nor mp have any ability to prevent malefactors from distributing false cardanos
  185. Mar 20 20:48:39 <asciilifeform> and to claim otherwise would be folly
  186. Mar 20 20:48:56 <ninjashogun>   it can type, at 4 am, lsusb-enter and then press delete 6 times if it did not just get polled.
  187. Mar 20 20:49:15 <ninjashogun>   this is a very VERY small hint that it has just done so.
  188. Mar 20 20:49:20 <asciilifeform> if you would actually like to explore the subject, study linux kernel's usb stack.
  189. Mar 20 20:49:36 <asciilifeform> but i have some time and will tell you the essential fact
  190. Mar 20 20:49:42 <ninjashogun>   I was just giving an example. I study the architecture at a higher level.
  191. Mar 20 20:49:44 <asciilifeform> a usb device, when plugged in, 'enumerates'
  192. Mar 20 20:49:48 <ninjashogun>   yes
  193. Mar 20 20:50:02 <asciilifeform> this is when the kernel asks it to power up and describe which standard class, if any, it falls into
  194. Mar 20 20:50:07 <asciilifeform> 'lsusb' does not re-enumerate devices
  195. Mar 20 20:50:08 <ninjashogun>   right
  196. Mar 20 20:50:11 <ninjashogun>   ok
  197. Mar 20 20:50:20 <asciilifeform> it simply dumps the cached table of results of previously enumerated hw
  198. Mar 20 20:50:31 <asciilifeform> don't take my word for it - read the source
  199. Mar 20 20:50:44 <ninjashogun>   What do you think the shortest way is to get a signal to the Cardano?  Obviously if it mounted to a standard location you could just do an ls at that point
  200. Mar 20 20:50:48 <ninjashogun>   or cat a file to that point
  201. Mar 20 20:51:02 <ninjashogun>   (if it also mounts as a mass storage device)
  202. Mar 20 20:51:10 <ninjashogun>   But you are saying that will be system-dependent, where it mounts to
  203. Mar 20 20:51:21 <ninjashogun>   oh.
  204. Mar 20 20:51:28 <asciilifeform> one could, in principle, assume a foolish user who has his mountpointed at '/mnt/cardano' or whatever, and left bash open, logged in as a user with write privilege to the location, and currently 'cd'd to it
  205. Mar 20 20:51:37 <ninjashogun>   that is too much
  206. Mar 20 20:51:40 <asciilifeform> correct
  207. Mar 20 20:51:42 <ninjashogun>   it should work from any prompt
  208. Mar 20 20:51:49 <ninjashogun>   and then if it does work, it should check if the prompt is root
  209. Mar 20 20:51:56 <ninjashogun>   and if not then it should delete the previous short history
  210. Mar 20 20:52:03 <ninjashogun>   it can do all this very very subtlely.
  211. Mar 20 20:52:10 <ninjashogun>   But all this depends on figuring out if it is in a terminal at 4 am.
  212. Mar 20 20:52:23 <asciilifeform> once again, if you can make this work from 'any prompt', don't settle for small change
  213. Mar 20 20:52:24 <ninjashogun>   The major hurdle is figuring out if it's in a terminal, or Open Office.
  214. Mar 20 20:52:49 <ninjashogun>   How can we figure out with 1 short universal command whether it is in Open Office writing a technical report at the time, or at a prompt?
  215. Mar 20 20:53:02 <asciilifeform> you can't - one-way channel.
  216. Mar 20 20:53:04 <ninjashogun>   assuming it can also automount usb devices
  217. Mar 20 20:53:09 <ninjashogun>   I just gave you some examples of how it could :)
  218. Mar 20 20:53:31 <ninjashogun>   For example if it knew where its mass storage mount pouint was, it could type an ls command to it.
  219. Mar 20 20:53:46 <asciilifeform> you could, hypothetically, 'type' a shell script that enumerates through the output of 'mount' and attempts to unmount everything but '/'
  220. Mar 20 20:54:11 <ninjashogun>   no, that is way too obvious :)
  221. Mar 20 20:54:18 <asciilifeform> but usb mass storage drive has no way of knowing that it has been unmounted.
  222. Mar 20 20:54:27 <ninjashogun>   it should be something as short as an lsusb command, something that just causes all usb devices to be polled somehow
  223. Mar 20 20:54:40 <asciilifeform> the only result of umounting from the standpoint of a drive is that any unwritten cached data is flushed to it
  224. Mar 20 20:55:19 <asciilifeform> what you ask for is certainly doable on particular flavours of linux
  225. Mar 20 20:55:42 <asciilifeform> where the fool leaves himself inside an open shell, logged in as root
  226. Mar 20 20:55:47 <ninjashogun>   there are other examples, I can think of a bunchk, but they're very long ways of seeing.  For example, it could identify as a camera, and then use a command that reads the camera.  this assumes a really large space of drivers and software present however.
  227. Mar 20 20:55:53 <asciilifeform> do you routinely leave your own machine unattended in this condition?
  228. Mar 20 20:56:01 <ninjashogun>   It doesn't have to be routine...
  229. Mar 20 20:56:11 <ninjashogun>   And yes, I leave long operations running all the time.  Not as root usually.
  230. Mar 20 20:56:25 <ninjashogun>   I've often come back to something being finished in the morning.
  231. Mar 20 20:56:27 <asciilifeform> all of these scenarios rely on a very particular set of assumptions
  232. Mar 20 20:56:39 <asciilifeform> that are unlikely to be true simultaneously in a particular time and place.
  233. Mar 20 20:56:39 <ninjashogun>   And I probably wouldn't think twice on an 'lsusb' command I hadn't typed, for example.
  234. Mar 20 20:57:01 <ninjashogun>   Well, that is how real attack vectors are given out.  That's how millions in bitcoins are stolen.
  235. Mar 20 20:57:20 <asciilifeform> nope. i recommend studying the details of how they were actually stolen.
  236. Mar 20 20:57:32 <ninjashogun>   Do you have a good link?
  237. Mar 20 20:57:35 <ninjashogun>   I've read conflicting things.
  238. Mar 20 20:57:40 <asciilifeform> in no publicly-known case so far has the perpetrator done anything but exploit a truly idiotic hole
  239. Mar 20 20:58:08 <asciilifeform> e.g. the 500 or so known winblows trojans which look for unencrypted 'wallet.dat'
  240. Mar 20 20:59:12 <asciilifeform> many attacks - such as the most recently published exchange breach - rely on social engineering and are uninteresting from the engineering point of view
  241. Mar 20 20:59:42 <ninjashogun>   I found the solution to what I was asking.
  242. Mar 20 20:59:48 <ninjashogun>   You can simply type this at a prompt: setleds -D +num
  243. Mar 20 21:00:00 <ninjashogun>   this turns the numlock on.  The USB device would be told.
  244. Mar 20 21:00:59 <ninjashogun>   so if the numlock were toggled after that command were entered, it would know that it was at a prompt and could proceed to write scripts.  For starters it could write a script to spam the numlock if the real user types anything.  then it could disappear if this is done.
  245. Mar 20 21:01:24 <ninjashogun>   it also needs to become silent, by opening a process it can write to that doesn't put anything on screen.  this should be a very short command.
  246. Mar 20 21:01:31 <asciilifeform> this would theoretically work to see if your victim left a root shell, sure
  247. Mar 20 21:01:34 <asciilifeform> but also tip him off
  248. Mar 20 21:01:42 <ninjashogun>   I know, in retrospect
  249. Mar 20 21:01:47 <ninjashogun>   but we try to delete it if it didn't work
  250. Mar 20 21:01:58 <ninjashogun>   we are talking a total of 100 milliseconds done in a blip of an eye at 4 AM
  251. Mar 20 21:02:11 <ninjashogun>   even if someone did see it at 4 AM, they would doubt their sanity
  252. Mar 20 21:02:33 <asciilifeform> likewise, one could theoretically 'type' a script that writes a small file to everything outputted by 'mount', then dismounts and remounts each drive, and watches for its own volume being written by cache flush.
  253. Mar 20 21:02:34 <asciilifeform> what of it?
  254. Mar 20 21:02:53 <ninjashogun>   and then even if they see the very short script that would be visible (we have to minimize this length, it's the main means of discovery) they could assume something is corrupt, like a corrupt driver or something
  255. Mar 20 21:03:11 <ninjashogun>   well, what of it is if you mount usb devices someone might think of the cardano
  256. Mar 20 21:03:30 <asciilifeform> a malicious device can do anything whatsoever
  257. Mar 20 21:03:39 <asciilifeform> e.g. explode, sending shrapnel through the room
  258. Mar 20 21:03:44 <asciilifeform> release poison gas
  259. Mar 20 21:03:45 <asciilifeform> etc
  260. Mar 20 21:03:58 <asciilifeform> how is this a problem particular to cardano?
  261. Mar 20 21:04:05 <ninjashogun>   but if you write "setleds -D +num" and the user sees it - what will they think?
  262. Mar 20 21:04:16 <ninjashogun>   they will not connect it to a polling attack
  263. Mar 20 21:04:18 <ninjashogun>   they will not think of that
  264. Mar 20 21:04:22 <asciilifeform> an educated user will know that he is being fucked with
  265. Mar 20 21:04:23 <ninjashogun>   so the point is to do this:
  266. Mar 20 21:04:37 <ninjashogun>   1) write setleds -D +num   2) write a very very short garbage-looking script that looks like line noise
  267. Mar 20 21:04:49 <ninjashogun>   oh and if 1) didn't work then send as many deletes as what you just typed.
  268. Mar 20 21:05:20 <ninjashogun>   The garbage looking script has the following requirement: 1) it MUST look like corruption of some kind.  2) it must drop what's visible to user as quickly as possible, and let the rest of the scripts be typed in a way that doesnt' show on screen.
  269. Mar 20 21:05:46 <asciilifeform> incidentally, have you checked the published catalogue of rubber duck payloads?
  270. Mar 20 21:05:49 <ninjashogun>   3) once given a chance to type the rest silently, it should quickly try to determine if a real user is doing anything (such as pressing delete) and if so to disappear.
  271. Mar 20 21:05:59 <asciilifeform> i would not be surprised to discover that this particular trick is already found therein.
  272. Mar 20 21:06:22 <asciilifeform> going back a little, i will say that if i wanted to design a malicious usb device, i would not settle for small change
  273. Mar 20 21:06:23 <ninjashogun>   Well, in evaluating architectures I like to go from first principles to be honest.
  274. Mar 20 21:06:34 <ninjashogun>   What else would your malicious device do?
  275. Mar 20 21:06:35 <asciilifeform> buggy drivers are 'where it's at'
  276. Mar 20 21:06:39 <ninjashogun>   I understand this.
  277. Mar 20 21:06:47 <ninjashogun>   but people with patched systems would require a 0-day.
  278. Mar 20 21:07:42 <ninjashogun>   Beyond buggy drivers, what are the main things you have in mind?  Is it mostly buggy drivers?
  279. Mar 20 21:07:47 <asciilifeform> a system such as 'ubuntu', which ships with every conceivable usb device driver by default, probably contains something usable
  280. Mar 20 21:08:20 <asciilifeform> if i'm not mistaken, what you originally meant to ask was, how does a purchaser know that his unit behaves 'as printed on the box'
  281. Mar 20 21:08:32 <ninjashogun>   No I didn't mean to ask that :)
  282. Mar 20 21:08:36 <ninjashogun>   obviously there's no way of knowing that
  283. Mar 20 21:09:02 <asciilifeform> the answer is either 1) he trusts the supplier and the designer 2) he trusts a third party who has judged the device fit for its advertised purpose 3) he personally studied the device to his satisfaction
  284. Mar 20 21:09:04 <asciilifeform> there is no (4)
  285. Mar 20 21:09:05 <ninjashogun>   I mean, when you refer to 999 attack vectors via USB, you're thinking of all the device drivers or a specific architectural flaw?
  286. Mar 20 21:09:21 <ninjashogun>   There are levels of trust in the supplier and designer.
  287. Mar 20 21:09:57 <ninjashogun>   For example I trust Google to give me an https session if I ask for it.  (No comments on what they do once my queries are on the other side.)  Then again, I don't "really" trust them not to forward all that trafffic to a third party, asking as their own MITM
  288. Mar 20 21:10:07 <asciilifeform> sure
  289. Mar 20 21:10:39 <asciilifeform> at the moment, most pc users are happy buyers of countless thumb drives, mice, keyboards, printers, etc, etc. of every conceivable origin
  290. Mar 20 21:10:41 <ninjashogun>   I googled rubber ducky payloads.  most are funny - https://github.com/hak5darren/USB-Rubber-Ducky/wiki/Payload---reverse-shell
  291. Mar 20 21:11:01 <asciilifeform> most of these gadgets have 100% closed design specs, and often use unlabeled asian ICs
  292. Mar 20 21:11:02 <ninjashogun>   Yes.  And they will not plug ANY of them into a secure device, EVAR
  293. Mar 20 21:11:23 <ninjashogun>   I never plug a single usb device into a secure PC, ever.  The moment I do it's not a secure PC in my eyes.
  294. Mar 20 21:11:58 <ninjashogun>   There's just too much that you're trusting in the architectural.  By design.  It's an implicit level of trust.
  295. Mar 20 21:12:04 <ninjashogun>   architecture*
  296. Mar 20 21:12:10 <asciilifeform> surely you understand that the rubber duck attack works just as well with 'ps/2.'
  297. Mar 20 21:12:34 <ninjashogun>   No, that's not true.
  298. Mar 20 21:12:59 <ninjashogun>   Because if you only accept a ps/2 keyboard then a Cardano acting as usb mass storage device doesn't have any vectors that are architecturally open to it, by design.
  299. Mar 20 21:13:13 <asciilifeform> if you own something you think of as 'secure pc', and you use a keyboard of some description with it, then evidently there is someone you trust to supply a keyboard which does not emit curious commands by itself at night.
  300. Mar 20 21:13:34 <ninjashogun>   For an example of what I mean: a usb mass storage device, by design, can write out any data it wants for the files you ask for.  (Not just what you wrote there.)  This would be designed into the architecture.
  301. Mar 20 21:13:45 <asciilifeform> certainly.
  302. Mar 20 21:13:50 <ninjashogun>   So for example it's obvious that an external hard-drive could silently rewrite any file you asked for that ends in .sh
  303. Mar 20 21:14:01 <ninjashogun>   this doesn't require going outside the architecture.
  304. Mar 20 21:14:02 <asciilifeform> incidentally, an internal (traditional) hard drive can be modified to do the very same thing.
  305. Mar 20 21:14:07 <ninjashogun>   yes.
  306. Mar 20 21:14:11 <asciilifeform> this is a published experiment.
  307. Mar 20 21:14:20 <ninjashogun>   and it's the kind of thing that's important to mitigate by design.  Yes, I read about that.
  308. Mar 20 21:14:40 <ninjashogun>   Whenever the high-level architecture leaves something possible by design, it is something that must be considered worse than if the same thing can be done via 0-day.
  309. Mar 20 21:14:51 <ninjashogun>   by the way I didn't mean to spend this long on this conversation, but it's interesting
  310. Mar 20 21:14:53 <asciilifeform> the buyer of the disk, if he wishes to be certain, must either reverse-engineer it - or trust the maker, or trust a third party who did reverse it
  311. Mar 20 21:14:57 <asciilifeform> what alternative do you propose?
  312. Mar 20 21:14:58 <ninjashogun>   I started by saying it doesn't make the cardano insecure - and so it doesn't.
  313. Mar 20 21:15:15 <ninjashogun>   So, the alternative I propose is as follows:
  314. Mar 20 21:15:32 <ninjashogun>   You remove this vector from the architecture, thereby mitigating what would happen if you fucked up.
  315. Mar 20 21:16:04 <asciilifeform> care to be more specific?
  316. Mar 20 21:16:05 <ninjashogun>   And one possible means of doing so is by mentioning it as a warning to patch systems so that the Cardano can only identify as a mass storage device and nothing else.  I would accept that as an acceptable resolution.
  317. Mar 20 21:16:16 <ninjashogun>   I would think the warning is sufficient for starters.
  318. Mar 20 21:16:29 <asciilifeform> see the point about the electric saw.
  319. Mar 20 21:16:47 <ninjashogun>   Yes, you're right.
  320. Mar 20 21:16:50 <asciilifeform> i cannot hope to teach an entirely 'green' user everything that is to be known about comsec
  321. Mar 20 21:16:55 <ninjashogun>   well, let me think about what else you can do.
  322. Mar 20 21:17:43 <asciilifeform> i'm quite happy to settle for supplying a tool with clearly defined functionality to folks who understand the basic limitations.
  323. Mar 20 21:17:52 <ninjashogun>   (You're not going to like this answer, but for my suggested Version 2:  Wifi has less trust implicit architecturally it is not possible to automount a usb keyboard over wifi.  You woudl have to break the wifi protocol, or use it in an unintended way as a carrier for other internal data)
  324. Mar 20 21:18:15 <ninjashogun>   (should be period after architecturally.)
  325. Mar 20 21:18:39 <asciilifeform> if you did not already known, it is possible to do virtually anything to an operating wifi net because wep (and wep2) are breakable in real time.
  326. Mar 20 21:19:14 <ninjashogun>   would you write the same about WPA2?
  327. Mar 20 21:19:14 <asciilifeform> this is not even including the purely physical (that is, layer 0/1) trickery using radio.
  328. Mar 20 21:19:17 <asciilifeform> yes
  329. Mar 20 21:19:53 <asciilifeform> i meant wpa2
  330. Mar 20 21:20:00 <ninjashogun>   Okay, I am curious.  What makes you say WPA2 is breakable in real time, and why - is this implementation specific, and which implementations?
  331. Mar 20 21:20:27 <ninjashogun>   oh.  that's a considerably stronger statement (saying wpa2 is breakable in real time), wep is obviously a joke like telnet.
  332. Mar 20 21:20:35 <asciilifeform> google. this is not a deep secret.
  333. Mar 20 21:21:00 <ninjashogun>   so why do public places have wpa2 access?
  334. Mar 20 21:21:17 <asciilifeform> because it is slightly more difficult to break than wep
  335. Mar 20 21:21:35 <ninjashogun>   I mean any wireless access at all.
  336. Mar 20 21:21:50 <ninjashogun>   I mean if it's so hackable how can any public place have any wpa2 access at all - why isn't it too insecure to exist in public?
  337. Mar 20 21:22:04 <asciilifeform> wait till you find out how 'gsm' uses toy crypto
  338. Mar 20 21:22:22 <asciilifeform> the reason is not hard to guess.
  339. Mar 20 21:22:29 <asciilifeform> (political)
  340. Mar 20 21:22:38 <ninjashogun>   I know this.
  341. Mar 20 21:22:46 <ninjashogun>   Nobody considers gsm to be secure...
  342. Mar 20 21:23:11 <asciilifeform> it used toy crypto by design, and this fact has gone from mere allegation into the solidly known
  343. Mar 20 21:23:15 <asciilifeform> long ago.
  344. Mar 20 21:23:33 <ninjashogun>   I know this.
  345. Mar 20 21:23:43 <asciilifeform> so what part do you find surprising?
  346. Mar 20 21:24:15 <ninjashogun>   so I asked in the wireless channels, this is news to them that wpa2 is breakable in real time.  They are saying it depends on the router, but the protocol itself is not broken/deprecated (like for example md5 is)
  347. Mar 20 21:24:52 <asciilifeform> if you wish to be tutored in the exact means whereby wpa2 is broken in real time, i suggest you pay a consultant
  348. Mar 20 21:24:57 <ninjashogun>   so at least on the protocol level #Linux is disagreeing with you - <curatrix> ninjashogun: It depends on the length of the key ..... if the key length is greaater than 22 characters .... then no .... it would take a supercomputer to break it in real time
  349. Mar 20 21:25:09 <asciilifeform> known-plaintext attack, for one.
  350. Mar 20 21:25:52 <ninjashogun>   http://wiki.answers.com/Q/Which_encryption_type_does_WPA2_use
  351. Mar 20 21:26:09 <ninjashogun>   wow that's a horrible link, sorry
  352. Mar 20 21:26:15 <ninjashogun>   it seemed better from the google summary
  353. Mar 20 21:26:43 <ninjashogun>   anyway it says it uses several types; "wpa2 introduced CCMP, a new AES-based encryption mode."
  354. Mar 20 21:27:12 <ninjashogun>   so are you saying that at the protocol level CCMP succumbs to known-plaintext attacks due to a flawed implementation?  (In the sense that AES-256 does not have a known-plaintext attack.)
  355. Mar 20 21:27:22 <asciilifeform> the simplest attack, incidentally, involves forcing a router (of whatever variety is present) off the air
  356. Mar 20 21:27:29 <asciilifeform> and substituting oneself for it
  357. Mar 20 21:27:34 <asciilifeform> many consumer widgets will auto-connect.
  358. Mar 20 21:27:45 <asciilifeform> this does not require breaking anything, in the usual sense.
  359. Mar 20 21:27:49 <ninjashogun>   yes
  360. Mar 20 21:28:12 <asciilifeform> likewise, channel control info (e.g. MAC) is sent plaintext
  361. Mar 20 21:28:16 <ninjashogun>   architecturally, obviously you have to consider the channel insecure from the sense of the stack that data is written over
  362. Mar 20 21:28:34 <ninjashogun>   for example the MITM attack you just stated.
  363. Mar 20 21:29:06 <asciilifeform> let's imagine that there were no architectural problems whatsoever with wifi
  364. Mar 20 21:29:08 <ninjashogun>   but the thing about the MITM attack is that you can establish a secure channel stepping over the heads of any number of men in the  middle.
  365. Mar 20 21:29:13 <asciilifeform> and that NONSTOP physical effects did not exist.
  366. Mar 20 21:29:15 <asciilifeform> (they do)
  367. Mar 20 21:29:28 <asciilifeform> wifi in a cardano is still a non-starter.
  368. Mar 20 21:29:35 <ninjashogun>   wait - by the way do you think you can jam NONSTOP effects?
  369. Mar 20 21:29:48 <asciilifeform> because the user we have in mind owns no wifi gadgets
  370. Mar 20 21:29:51 <ninjashogun>   by jamming the frequency until the S/N ratio is too high for subtle effects?
  371. Mar 20 21:29:57 <asciilifeform> or if he does, they are not permitted near anything valuable.
  372. Mar 20 21:30:04 <ninjashogun>   seriously?
  373. Mar 20 21:30:10 <asciilifeform> yes.
  374. Mar 20 21:30:11 <ninjashogun>   Don't every one of them have an android phone?
  375. Mar 20 21:30:15 <asciilifeform> nope.
  376. Mar 20 21:30:32 <ninjashogun>   so this is like a lock-down security bunker in the hills of switzerland?
  377. Mar 20 21:30:39 <asciilifeform> not entirely unlike.
  378. Mar 20 21:31:03 <ninjashogun>   well, I will say that that is nto very "mass-market" :) though it might pay better.  But if you have an open design it would be hard to charge much if anything.
  379. Mar 20 21:31:16 <asciilifeform> the purpose of 'cardano' and future s.nsa products is clearly described on mp's site
  380. Mar 20 21:31:19 <ninjashogun>   if you made version2 wifi you might be able to ship 10,000 of them at $100 each.
  381. Mar 20 21:31:29 <asciilifeform> no engineering compromises whatsoever.
  382. Mar 20 21:31:32 <ninjashogun>   that's a cool $1M.
  383. Mar 20 21:31:51 <asciilifeform> some folks sell toyotas
  384. Mar 20 21:31:54 <ninjashogun>   Regarding NONSTOP effects -
  385. Mar 20 21:31:57 <asciilifeform> others, bugati. mazerati.
  386. Mar 20 21:31:58 <ninjashogun>   do you think it can be jammed?
  387. Mar 20 21:32:03 <ninjashogun>   yes, true
  388. Mar 20 21:32:36 <ninjashogun>   but bugati and maserati are extremely differentiated and don't have open designs :) they have very high prices, and you can't just build your own maserati :)
  389. Mar 20 21:32:38 <asciilifeform> if you are concerned with the phenomena called 'tempest' and 'nonstop', the simplest solution is to use a faraday cage.
  390. Mar 20 21:32:46 <asciilifeform> if you own a microwave oven, you already own a faraday cage.
  391. Mar 20 21:32:59 <asciilifeform> but, notice that the gadget used therein cannot rely on radio for normal operation.
  392. Mar 20 21:33:16 <ninjashogun>   I understand this, but regardless, I would be interested in knowing whether the subtle NONSTOP transmission of external circuits (not even in use by the radio) is an effect that can be jammed by increasing the S/N ratio over the whole channel?
  393. Mar 20 21:33:29 <ninjashogun>   sure it can.  Both devices could be in the microwave (faraday cage)
  394. Mar 20 21:33:30 <asciilifeform> hypothetically.
  395. Mar 20 21:33:44 <ninjashogun>   for example if a room is a faraday cage, it could still have wifi inside for usability.
  396. Mar 20 21:33:46 <asciilifeform> how do you intend to operate your, say, smartphone inside the oven?
  397. Mar 20 21:33:52 <asciilifeform> do you own one which is large enough to stand in?
  398. Mar 20 21:34:04 <ninjashogun>   a faraday cage?  Me personally no, but loads of people do.  entire rooms.
  399. Mar 20 21:34:09 <asciilifeform> room-sized cages are commercially available, certainly.
  400. Mar 20 21:34:22 <ninjashogun>   They're easy to make.  you can make it yourself using $10 in metal.
  401. Mar 20 21:34:27 <asciilifeform> if you wish to sell hardware which requires the ownership of such a cage, go ahead
  402. Mar 20 21:34:39 <ninjashogun>   well, no, it would be better if it weren't required :)
  403. Mar 20 21:34:45 <asciilifeform> correct. hence no radio.
  404. Mar 20 21:34:58 <ninjashogun>   or iPad integration :)
  405. Mar 20 21:35:22 <asciilifeform> are you familiar with the saying 'spoon of shit in a barrel of honey' ?
  406. Mar 20 21:35:29 <ninjashogun>   No.
  407. Mar 20 21:35:36 <asciilifeform> perhaps you can guess the meaning
  408. Mar 20 21:35:39 <ninjashogun>   sure
  409. Mar 20 21:35:49 <asciilifeform> 'ipad integration' would be analogous to 'spoon of honey in barrel of shit'
  410. Mar 20 21:36:15 <ninjashogun>   where you say "hypotehtically" could you elaborate -- you've mentioned before that you can see the NONSTOP effect on a scope.  So, if you subtlely jam those frequencies would that disappear?  The signal to noise must be fairly low to let a CPU's internal state come through....
  411. Mar 20 21:36:36 <ninjashogun>   (I'm guessing)
  412. Mar 20 21:36:53 <asciilifeform> if you market a product which actively jams radio, of whatever variety, during normal operation, you will run into legal problems in most civilized countries.
  413. Mar 20 21:36:56 <ninjashogun>   I meant "high" not "low" just now.  Very HIGH signal to noise.
  414. Mar 20 21:36:57 <asciilifeform> and for good reason
  415. Mar 20 21:37:09 <ninjashogun>   I knwo but I was thinking that the level of jamming could be lower than that.
  416. Mar 20 21:37:18 <ninjashogun>   you're just trying to soften the edges of the carrier waves....
  417. Mar 20 21:37:25 <ninjashogun>   not jam the waves themselves.
  418. Mar 20 21:37:40 <ninjashogun>   they can still be recognizable, just without the meta information coming through clearly enough.
  419. Mar 20 21:37:51 <ninjashogun>   just add some white noise at that low level.
  420. Mar 20 21:38:02 <asciilifeform> in ww2, germany experimented with a radio-controlled flying bomb, similar to the modern 'tomahawk.' american sailors found that it would drop into the sea when they switched on an electric razor.
  421. Mar 20 21:38:07 <asciilifeform> (spark gap noise.)
  422. Mar 20 21:38:19 <ninjashogun>   But to know if that would work as a mitigation strategy I would have to know a bit more about the physics of NONSTOP, and I don't have a good specan yet.
  423. Mar 20 21:38:34 <ninjashogun>   that is certainly interesting :)
  424. Mar 20 21:38:53 <asciilifeform> in principle, you can jam anything
  425. Mar 20 21:39:11 <asciilifeform> but unless i'm mistaken, you supposed the presence of some radio functionality that is to actually work
  426. Mar 20 21:39:15 <ninjashogun>   asciilifeform right but we're talkinga bout something that is at a lower-level, like a timing attack.
  427. Mar 20 21:39:32 <asciilifeform> the simplest countermeasure is to omit radio entirely
  428. Mar 20 21:40:03 <ninjashogun>   asciilifeform let me give you an example.  Here is an easy way to bruteforce a naive password-checking program that does not lock you out, but has a 256-bit keyspace. and takes a thirty-digit password:
  429. Mar 20 21:40:15 <asciilifeform> and thus allow for a device that can be operated, as designed, in a sealed, grounded metal countour of small size.
  430. Mar 20 21:41:03 <ninjashogun>   You can assume that the password checking algorithm at some point uses a string comparison, and terminates earlier if less of the string matches.  You can then brute-force the timing information about whether at least the first character matched, because for that character, all of the fails would be slightly slower than for the other characters, since the algorithm takes one extra loop to get t
  431. Mar 20 21:41:03 <ninjashogun>   o the next letter.
  432. Mar 20 21:41:20 <asciilifeform> this is very basic stuff, sure
  433. Mar 20 21:41:27 <asciilifeform> how does it relate ?
  434. Mar 20 21:41:35 <ninjashogun>   Yes.  But this can be "jammed" by simply going through all letters regardless of whether they match.
  435. Mar 20 21:41:49 <ninjashogun>   you're just removing info that shouldn't be there anyway.  Timing is a side channel.
  436. Mar 20 21:41:51 <asciilifeform> sure
  437. Mar 20 21:41:55 <ninjashogun>   it's not something is supposed to be communicated.
  438. Mar 20 21:42:02 <asciilifeform> none of this is any kind of revelation.
  439. Mar 20 21:42:06 <ninjashogun>   likewise NONSTOP is a side channel.  it shouldn't actually be communicated.  it's not actually certified.
  440. Mar 20 21:42:18 <ninjashogun>   it's not an explicit layer.
  441. Mar 20 21:42:33 <asciilifeform> ok here's 1 more free physics lesson
  442. Mar 20 21:42:42 <ninjashogun>   so you could simply jam it by fudging or smoothing the wave without affecting anything else - just as if you normalize timing you remove a side channel leak that was not explicit.
  443. Mar 20 21:43:05 <asciilifeform> the physics of radio are such that any antenna that is designed to transmit at a particular frequency, also effectively receives at that frequency.
  444. Mar 20 21:43:14 <ninjashogun>   ok
  445. Mar 20 21:43:16 <asciilifeform> ('is resonant' at, the textbook will say)
  446. Mar 20 21:43:19 <ninjashogun>   sure
  447. Mar 20 21:43:19 <ninjashogun>   yes
  448. Mar 20 21:43:38 <asciilifeform> if your machine contains an antenna, your opponent can walk up to your facility and 'illuminate' it
  449. Mar 20 21:43:50 <asciilifeform> with, say, 1kW transmitter
  450. Mar 20 21:44:00 <asciilifeform> then watch for what bounces back
  451. Mar 20 21:44:04 <ninjashogun>   ok..
  452. Mar 20 21:44:10 <asciilifeform> this is, as you probably know, the basic principle behind 'rfid'
  453. Mar 20 21:44:16 <ninjashogun>   but this applies to every thing that happens to be a dipole in the whole damn place, right?
  454. Mar 20 21:44:21 <asciilifeform> correct.
  455. Mar 20 21:44:28 <ninjashogun>   so go on
  456. Mar 20 21:44:35 <asciilifeform> so don't be a dipole.
  457. Mar 20 21:45:06 <ninjashogun>   what's step 2?
  458. Mar 20 21:45:11 <asciilifeform> there is no step 2.
  459. Mar 20 21:45:36 <ninjashogun>   I mean, what do you get out of illuminating every dipole with a 1 kW transmitter and getting some stuff bounced back?
  460. Mar 20 21:45:44 <asciilifeform> well this depends on what is near the 'receiver'
  461. Mar 20 21:45:48 <asciilifeform> (intentional or otherwise)
  462. Mar 20 21:45:58 <ninjashogun>   in our case for example
  463. Mar 20 21:46:05 <ninjashogun>   what's near it wuold be the rest of this version of a cardano
  464. Mar 20 21:46:05 <asciilifeform> sometimes, the intention is merely to determine that receiver is present.
  465. Mar 20 21:46:15 <ninjashogun>   yes, that would happen.
  466. Mar 20 21:46:18 <asciilifeform> read about how british government determined who owns a tv set.
  467. Mar 20 21:46:22 <asciilifeform> (to collect tax)
  468. Mar 20 21:46:27 <ninjashogun>   right, have heard this
  469. Mar 20 21:46:36 <ninjashogun>   This is a good point.
  470. Mar 20 21:46:50 <asciilifeform> or how germany, during ww2, searched for folks who owned shortwave sets (illegal)
  471. Mar 20 21:46:59 <asciilifeform> this is 1940s state-of-the-art.
  472. Mar 20 21:47:19 <ninjashogun>   yes
  473. Mar 20 21:47:31 <ninjashogun>   I know about this.
  474. Mar 20 21:47:50 <ninjashogun>   btw you would enjoy a spy tell-all by an ex mi5 or mi6 guy, talks about some of this stuff
  475. Mar 20 21:48:05 <ninjashogun>   I don't remember the title off-hand give me a few and i'll come up with it
  476. Mar 20 21:48:07 <asciilifeform> there is a wealth of material on the net on the subject
  477. Mar 20 21:48:19 <asciilifeform> most of the good stuff is in russian
  478. Mar 20 21:48:28 <ninjashogun>   but so the basic attack vector is that the presence can be determined, as long as it's outside of a faraday cage?
  479. Mar 20 21:48:36 <ninjashogun>   do you speak Russian?
  480. Mar 20 21:48:37 <asciilifeform> (no worries if you don't speak russian - when usa collapses the archives will open)
  481. Mar 20 21:48:42 <asciilifeform> as you can probably guess
  482. Mar 20 21:48:53 <ninjashogun>   No, I can't guess :)
  483. Mar 20 21:48:57 <ninjashogun>   my guess is "no".
  484. Mar 20 21:49:18 <ninjashogun>   You don't have to say either way.
  485. Mar 20 21:49:37 <asciilifeform> this is not a secret
  486. Mar 20 21:49:49 <ninjashogun>   in that case - that's a yes?
  487. Mar 20 21:50:02 <asciilifeform> i sometimes post translations of various things on my site, etc.
  488. Mar 20 21:50:03 <asciilifeform> right
  489. Mar 20 21:50:07 <ninjashogun>   ok
  490. Mar 20 21:50:17 <ninjashogun>   The book I was referring to is Spycatcher
  491. Mar 20 21:50:18 <asciilifeform> just as you know that mp speaks romanian, italian, german, greek, latin, etc
  492. Mar 20 21:50:22 <asciilifeform> (and english)
  493. Mar 20 21:50:27 <ninjashogun>   I can send you it in .epub format if you'd like, I happen to have a copy on hand.
  494. Mar 20 21:50:40 <asciilifeform> actually i happen to have a copy.
  495. Mar 20 21:50:42 <asciilifeform> but thank you.
  496. Mar 20 21:50:45 <ninjashogun>   I like his Latin, I "speak" it too.
  497. Mar 20 21:51:10 <ninjashogun>   it's funny
  498. Mar 20 21:51:18 <ninjashogun>   I like his writing style actually, it's very erudite.
  499. Mar 20 21:51:23 <asciilifeform> incidentally, don't hesitate to speak to mp. he doesn't bite
  500. Mar 20 21:51:28 <ninjashogun>   I know.
  501. Mar 20 21:51:34 <ninjashogun>   He's very accessible.
  502. Mar 20 21:51:41 <asciilifeform> perhaps he can explain certain matters we have spoken of better than i
  503. Mar 20 21:51:53 <ninjashogun>   His style on the blogs he writes is in some cases a bit trollish, but he also anonimizes the people he quotes so it doesn't really matter.
  504. Mar 20 21:52:16 <ninjashogun>   On the other hand for text analysis reasons I don't think he should post even anonymized quotes.  Most people's writing is extremely characteristic
  505. Mar 20 21:52:23 <ninjashogun>   especially if they use examples (that they like to mention) and so forth.
  506. Mar 20 21:52:34 <ninjashogun>   anonymizes*
  507. Mar 20 21:52:38 <asciilifeform> my advice to you is to regard anything transmitted as plaintext as - public.
  508. Mar 20 21:53:02 <ninjashogun>   I don't think that's fair.  For example I've hired developers from IRC for confidential projects.  So how does that work?
  509. Mar 20 21:53:13 <ninjashogun>   i.e. for prelaunch products that had pending IP protections.
  510. Mar 20 21:53:19 <ninjashogun>   or just were not public.
  511. Mar 20 21:53:25 <asciilifeform> it means that any freenode admin can read your communications at his leisure.
  512. Mar 20 21:53:37 <asciilifeform> and so can anyone who happens to share a LAN with one of the parties involved
  513. Mar 20 21:53:38 <ninjashogun>   that's pretty far from 'public' :)
  514. Mar 20 21:53:38 <asciilifeform> etc
  515. Mar 20 21:53:40 <ninjashogun>   yes
  516. Mar 20 21:53:45 <ninjashogun>   which is pretty far from 'public' :)
  517. Mar 20 21:53:54 <ninjashogun>   The thing about MP's blog is it's public in the sense of being Google-indexed.
  518. Mar 20 21:53:56 <asciilifeform> it is about as public as conversing in a restaurant.
  519. Mar 20 21:53:59 <asciilifeform> or a crowded train.
  520. Mar 20 21:54:04 <ninjashogun>   no, more public.
  521. Mar 20 21:54:09 <asciilifeform> i would not undertake to conduct important business in either
  522. Mar 20 21:54:15 <ninjashogun>   because MP's blog is indxed by Google, restaurants and trains aren't.
  523. Mar 20 21:54:20 <asciilifeform> sure
  524. Mar 20 21:54:27 <asciilifeform> i meant business-over-irc
  525. Mar 20 21:54:32 <ninjashogun>   so if someone writes three very characteristic, unusual words one after the other, they would find it.
  526. Mar 20 21:54:39 <ninjashogun>   well, yes.  that's the default assumption, I agree.
  527. Mar 20 21:54:54 <asciilifeform> i, for instance, live in usa, and therefore assume that every packet that leaves my home is recorded for all eternity.
  528. Mar 20 21:54:56 <ninjashogun>   and when he posts logs it goes a bit beyond that.  However it does help that he anonymizes the parties.  that's important and good.
  529. Mar 20 21:55:09 <asciilifeform> and seen by some unknown but sizable number of government-employed idlers
  530. Mar 20 21:55:25 <ninjashogun>   sure
  531. Mar 20 21:55:57 <ninjashogun>   for Cardano, would you like to sell a mass-market version (thousands or tens of thousands of them)?
  532. Mar 20 21:56:10 <asciilifeform> one of the things i try to teach people (and this pertains not only to cardano) - is that it is direly important to have realistic expectations.
  533. Mar 20 21:56:24 <asciilifeform> people with unrealistic expectations are sure to be unpleasantly surprised.
  534. Mar 20 21:56:27 <asciilifeform> it is only a question of when.
  535. Mar 20 21:56:32 <ninjashogun>   oh come on.  your stated goal is 'absolute security by design' :)
  536. Mar 20 21:56:47 <ninjashogun>   that is not realistic :)  but it is a fine goal, I don't object.
  537. Mar 20 21:57:14 <asciilifeform> if you read the prospectus, you will note that certain classes of attack (theft, etc) are explicitly not dealt with
  538. Mar 20 21:57:29 <asciilifeform> because physical security is the domain of folks selling safes, concrete bunkers, mercenaries, etc.
  539. Mar 20 21:57:30 <asciilifeform> not us
  540. Mar 20 21:57:48 <asciilifeform> to suggest otherwise would be dishonest.
  541. Mar 20 21:58:08 <ninjashogun>   I understand
  542. Mar 20 21:58:23 <ninjashogun>   but at the same time, for the parts you do address, your explicit goes is absolute security
  543. Mar 20 21:58:24 <asciilifeform> any questions regarding whether cardano is intended for mass market, or how many units will be built, or pricing - straight to mp
  544. Mar 20 21:58:29 <asciilifeform> he will choose to answer them - or not
  545. Mar 20 21:58:47 <ninjashogun>   all right
  546. Mar 20 21:58:56 <asciilifeform> also note that mp employs a 'pr'
  547. Mar 20 21:59:01 <ninjashogun>   what you've just written reminds me of (B) that I postponed above
  548. Mar 20 21:59:05 <ninjashogun>   pr?
  549. Mar 20 21:59:06 <asciilifeform> who is paid to answer such questions (or not, as she chooses)
  550. Mar 20 21:59:11 <ninjashogun>   oh that's fine
  551. Mar 20 21:59:20 <asciilifeform> i, on the other hand, am not employed in this capacity
  552. Mar 20 21:59:32 <asciilifeform> and would not, therefore, propose to say anything informative about marketing, etc
  553. Mar 20 21:59:34 <ninjashogun>   so (B) was about physical security.  Threat mitigation in case of theft.
  554. Mar 20 21:59:39 <ninjashogun>   sure yes okay
  555. Mar 20 21:59:41 <ninjashogun>   that's fine
  556. Mar 20 21:59:43 <asciilifeform> ok...
  557. Mar 20 21:59:53 <asciilifeform> what about it ?
  558. Mar 20 22:00:06 <ninjashogun>   so, your current design is that if it is stolen, the attacker has absolute knowledge of everything inside immediately with no effort?
  559. Mar 20 22:00:16 <ninjashogun>   (as a design goal)
  560. Mar 20 22:00:28 <asciilifeform> if he wishes to extract the key, and replace the device before victim notices, he will have to expend some effort
  561. Mar 20 22:00:28 <ninjashogun>   in the sense that a physical key (to a deadbolt on a door) works that way for example?
  562. Mar 20 22:00:40 <ninjashogun>   I don't mean about replacement
  563. Mar 20 22:00:41 <asciilifeform> how much effort depends on the user's personal decisions re: physical protection
  564. Mar 20 22:01:02 <ninjashogun>   I just mean what happens if he steals it.  Or if someone leaves it on a train, it falls out of their pocket.  Does whoever picks it up immediately have the same level of access as a physical house key?
  565. Mar 20 22:01:10 <asciilifeform> certainly.
  566. Mar 20 22:01:28 <asciilifeform> this, as you probably understand, is not a problem peculiar to cardano
  567. Mar 20 22:01:35 <ninjashogun>   It's not a problem at all.
  568. Mar 20 22:01:56 <ninjashogun>   But we could explore certain architectural additions that would change this status quo to some extent and may be of interest.
  569. Mar 20 22:02:12 <asciilifeform> user is free to, for example, pour his unit into a block of concrete.
  570. Mar 20 22:02:18 <ninjashogun>   That's not what I mean :)
  571. Mar 20 22:02:31 <ninjashogun>   I mean, a cardano without the user still functions in its key services.
  572. Mar 20 22:02:35 <ninjashogun>   but we can change this.
  573. Mar 20 22:02:36 <asciilifeform> certainly.
  574. Mar 20 22:02:37 <ninjashogun>   if we want.
  575. Mar 20 22:03:02 <asciilifeform> you realize that you are perhaps the 20th person to suggest passwords, key pads for entry thereof, etc.
  576. Mar 20 22:03:06 <ninjashogun>   One way is through some physical access mechanism (I hate those, never EVER use them).  a fingerprint reader for example (ugh ugh ugh ugh ugh)
  577. Mar 20 22:03:19 <ninjashogun>   I haven't suggested passwords, key pads for entry or anything else so far :)
  578. Mar 20 22:03:26 <ninjashogun>   Where do you see a suggestion? :) :) :)
  579. Mar 20 22:03:30 <asciilifeform> well the general idea of 'multi-factor' whatever
  580. Mar 20 22:03:42 <ninjashogun>   It's not about multi-factor.
  581. Mar 20 22:03:48 <asciilifeform> where a cardano lying on a table, sans owner, is somehow resistant to being put to use.
  582. Mar 20 22:03:54 <ninjashogun>   It's about what happens in the case that someone finds yours on a bus.
  583. Mar 20 22:04:08 <asciilifeform> then he can do whatever he wishes
  584. Mar 20 22:04:16 <ninjashogun>   I'll give you an example.
  585. Mar 20 22:04:20 <asciilifeform> just as if he finds a bag full of secret docs, etc
  586. Mar 20 22:04:27 <asciilifeform> these have also been misplaced on buses, trains.
  587. Mar 20 22:04:43 <ninjashogun>   There's more secure version of a normal housekey and a less secure version of a normal housekey.  Both are made of metal, both work EXACTLY THE SAME.  What's the diifference?
  588. Mar 20 22:04:43 <asciilifeform> 'doctor, it hurts when i do that.' - 'so don't do that.'
  589. Mar 20 22:05:02 <ninjashogun>   It's a puzzle :)
  590. Mar 20 22:05:19 <ninjashogun>   There's a more secure version of a housekey and a less secure version of a housekey, but both are made of metal and both work EXACTLY THE SAME.  What's the difference?
  591. Mar 20 22:05:53 <ninjashogun>   I can give a hint :)
  592. Mar 20 22:05:57 <asciilifeform> ok...?
  593. Mar 20 22:06:13 <ninjashogun>   The hint is it concerns exactly this scenario we just talked about..
  594. Mar 20 22:06:27 <asciilifeform> one of the keys has address engraved on it
  595. Mar 20 22:06:29 <asciilifeform> other does not
  596. Mar 20 22:06:33 <ninjashogun>   yep :)
  597. Mar 20 22:06:36 <ninjashogun>   exactly
  598. Mar 20 22:06:49 <ninjashogun>   And you see, they both work exactly the same.
  599. Mar 20 22:07:06 <asciilifeform> except that this scenario is inapplicable to cardano.
  600. Mar 20 22:07:20 <ninjashogun>   So the question is - if someone finds the Cardano, can they realize exactly who it belongs to?
  601. Mar 20 22:07:29 <asciilifeform> because, having possession of an rsa private key (integers 'p', 'q') one readily computes public key (product 'p'*'q')
  602. Mar 20 22:07:43 <asciilifeform> public key, traditionally, is distributed as widely as possible.
  603. Mar 20 22:07:47 <ninjashogun>   this is true. Very good.
  604. Mar 20 22:07:47 <ninjashogun>   yes.
  605. Mar 20 22:07:53 <ninjashogun>   very very good.
  606. Mar 20 22:08:01 <ninjashogun>   so the question is - can we break this symmetry and mitigate it without really changing anything else?
  607. Mar 20 22:08:19 <asciilifeform> not if you wish to use public key crypto.
  608. Mar 20 22:08:25 <asciilifeform> which operates in exactly this way, by definition.
  609. Mar 20 22:08:31 <ninjashogun>   this is true.
  610. Mar 20 22:09:32 <ninjashogun>   it would I think somewhat increase the security architecture if we could break this symmetry, so that it became impossible to know which public key the private key (which obviously could be recovered) belongs to
  611. Mar 20 22:09:49 <asciilifeform> if you have devised a fundamentally new concept of cryptography, don't settle for small change.
  612. Mar 20 22:10:01 <ninjashogun>   It doesn't have to be fundamentally new.
  613. Mar 20 22:10:11 <asciilifeform> don't tell me - commercialize, and solve the unfortunate financial problems you spoke of
  614. Mar 20 22:10:23 <asciilifeform> it would, in fact, need to be fundamentally new
  615. Mar 20 22:11:02 <asciilifeform> this is not a bad idea, per se - just as 'antigravity' is a great idea
  616. Mar 20 22:11:05 <ninjashogun>   For example, the other suggestions you mentioned have this side-effect.  If the Cardano takes a symmetric key from the user and then discards it when finished, uses this key to unencrpyt its own contents, It has BOTH the side effect of making the private key unrecoverable AND the side-effect of making a key not divulge its owner.
  617. Mar 20 22:11:12 <asciilifeform> what is lacking is - any notion of how it could physically work.
  618. Mar 20 22:11:18 <ninjashogun>   well you already have one
  619. Mar 20 22:11:34 <asciilifeform> 'takes a symmetric key from the user' reduces to 'password'
  620. Mar 20 22:11:42 <asciilifeform> which, as i explained, has been suggested in the past
  621. Mar 20 22:11:54 <ninjashogun>   That's true.  But just as a point of fact this, as a side-effect, solves the problem.  So we can't call it unsolveable.  We just have to find a better solution.
  622. Mar 20 22:12:08 <asciilifeform> well this is not a solution to the problem described earlier
  623. Mar 20 22:12:21 <asciilifeform> that is, public key crypto where the public key is not inferrable from a working private key.
  624. Mar 20 22:12:25 <ninjashogun>   It literally solves the problem of learning which public key a found cardano belongs to.
  625. Mar 20 22:13:14 <ninjashogun>   Here is a solution.  I've just come up with it.
  626. Mar 20 22:13:16 <asciilifeform> keeping cardano in a safe also solves the same problem.
  627. Mar 20 22:14:25 <ninjashogun>   If every Cardano has a hundred private keys on it then it is shorter than a password to name which ones need to be used in sequence.  (For example #5, #44, #192) but someone would have to try a ton of possibilities to see if they can find a pbulic key matching it.
  628. Mar 20 22:14:48 <ninjashogun>   this is a quick and dirty solution, it's obviously not final, but something like this might be possible.
  629. Mar 20 22:14:52 <asciilifeform> one can trivially query public key servers for any number of keys
  630. Mar 20 22:14:58 <asciilifeform> even a million
  631. Mar 20 22:15:18 <asciilifeform> or simply take the private key p,q and search using my search engine
  632. Mar 20 22:15:20 <asciilifeform> 'phuctor'
  633. Mar 20 22:15:22 <ninjashogun>   I am sensing that there could be an algorithm based on this.
  634. Mar 20 22:15:30 <asciilifeform> nosuchlabs.com
  635. Mar 20 22:15:33 <ninjashogun>   because you can combine them several times
  636. Mar 20 22:15:41 <asciilifeform> it's right there.
  637. Mar 20 22:15:44 <ninjashogun>   ok
  638. Mar 20 22:15:50 <ninjashogun>   where do you get your data?
  639. Mar 20 22:15:53 <asciilifeform> http://nosuchlabs.com/theory
  640. Mar 20 22:16:12 <asciilifeform> user submissions.
  641. Mar 20 22:16:29 <ninjashogun>   ok
  642. Mar 20 22:16:37 <asciilifeform> nothing about that widget is secret, it's all described on that page
  643. Mar 20 22:16:46 <asciilifeform> in sufficient detail that you could, if you wish, write your own.
  644. Mar 20 22:16:55 <ninjashogun>   what language does it use on the backend to process the form at http://nosuchlabs.com/
  645. Mar 20 22:17:08 <asciilifeform> what interest is it to you?
  646. Mar 20 22:17:21 <ninjashogun>   well, I'm building a web site that takes user generated content.
  647. Mar 20 22:17:31 <ninjashogun>   I haven't decided on a technical stack
  648. Mar 20 22:17:39 <asciilifeform> use whatever language strikes your fancy
  649. Mar 20 22:17:50 <ninjashogun>   is yours in Perl?
  650. Mar 20 22:17:51 <asciilifeform> it is an intensely personal choice, like what to eat
  651. Mar 20 22:17:54 <asciilifeform> no comment
  652. Mar 20 22:17:56 <ninjashogun>   (The usual reason someone wouldn't mention it)
  653. Mar 20 22:18:00 <ninjashogun>   :)
  654. Mar 20 22:18:07 <ninjashogun>   ok
  655. Mar 20 22:18:30 <ninjashogun>   I'm deciding between PHP (which leads to awful sites but I could make very quick progress and instantly google anything - big technical debt) and Go or Python
  656. Mar 20 22:18:38 <ninjashogun>   I know Perl though
  657. Mar 20 22:18:48 <asciilifeform> my recommendation is to use the language you are most familiar with.
  658. Mar 20 22:19:16 <ninjashogun>   okay, but for people for whom that's C++ or assembly, "You're going to have a bad time"
  659. Mar 20 22:19:21 <asciilifeform> certainly.
  660. Mar 20 22:19:26 <ninjashogun>   or PIC microcontroller code
  661. Mar 20 22:19:33 <asciilifeform> these should become more familiar with another language.
  662. Mar 20 22:19:37 <ninjashogun>   or circuit diagrams in EAGLE
  663. Mar 20 22:19:43 <asciilifeform> until it becomes 'the language they are most familiar with.'
  664. Mar 20 22:20:09 <ninjashogun>   yes.  Though, "Use the language you're more familiar with, if it sucks then learn another language until that's the one you're most familiar with and then use that" :)
  665. Mar 20 22:20:19 <asciilifeform> e.g. if all you know is fortran (like one fellow i know) you may wish to study another.
  666. Mar 20 22:20:23 <ninjashogun>   and logically, it means a C++ programmer with 15 years of experience couldn't put up a web site for...15 years :)
  667. Mar 20 22:20:39 <ninjashogun>    I don't think the new language has to be more familiar before fortran before he can start using it though :)
  668. Mar 20 22:20:51 <ninjashogun>   more familiar than fortran*
  669. Mar 20 22:21:17 <ninjashogun>   so I'd be willing to start with something I barely know or don't know (for example I don't know Ruby butr would consider it, same with Erlang/Clojure - zero knowledge - and no PHP either.)
  670. Mar 20 22:21:21 <asciilifeform> i regret that i cannot offer you useful advice in the design and construction of web services
  671. Mar 20 22:21:31 <ninjashogun>    it's fine.  I like your site :)
  672. Mar 20 22:21:34 <asciilifeform> because this is not what i do for a living.
  673. Mar 20 22:21:58 <ninjashogun>   right
  674. Mar 20 22:22:03 <asciilifeform> i actually do not program for a living at all.
  675. Mar 20 22:22:07 <ninjashogun>   no?
  676. Mar 20 22:22:09 <asciilifeform> (this is not a secret)
  677. Mar 20 22:22:13 <ninjashogun>   obviously not
  678. Mar 20 22:22:18 <ninjashogun>   what do you do? security audits?
  679. Mar 20 22:22:24 <asciilifeform> i'm a reverse engineer.
  680. Mar 20 22:22:28 <ninjashogun>   seriously?
  681. Mar 20 22:22:38 <asciilifeform> this is not an uncommon profession
  682. Mar 20 22:22:40 <ninjashogun>   of hardware or software?
  683. Mar 20 22:22:44 <asciilifeform> either.
  684. Mar 20 22:22:47 <ninjashogun>   it's a *very* uncommon profession.
  685. Mar 20 22:22:48 <ninjashogun>   extremely.
  686. Mar 20 22:22:54 <ninjashogun>   it's more common as a pastime than a profession.
  687. Mar 20 22:22:58 <asciilifeform> it simply isn't advertised in newspapers
  688. Mar 20 22:23:06 <asciilifeform> hence appearing uncommon
  689. Mar 20 22:23:11 <ninjashogun>   maybe
  690. Mar 20 22:23:15 <asciilifeform> but virtually all large concerns employ them.
  691. Mar 20 22:23:16 <ninjashogun>   and maybe people don't talk about it
  692. Mar 20 22:23:24 <ninjashogun>   do you work for one? (a large concern)
  693. Mar 20 22:23:27 <asciilifeform> no comment
  694. Mar 20 22:23:40 <ninjashogun>   ha - okay
  695. Mar 20 22:23:58 <asciilifeform> if you really wish to know - i study virii.
  696. Mar 20 22:24:01 <asciilifeform> (at present)
  697. Mar 20 22:24:04 <ninjashogun>   going back to the Cardano design.  Is there a reason you wouldn't offer a password as an option? (disabled by default, but it can be added)?
  698. Mar 20 22:24:10 <ninjashogun>   that is very interesting
  699. Mar 20 22:24:19 <ninjashogun>   for like FSecure or one of the big labs?
  700. Mar 20 22:24:22 <asciilifeform> how do you suggest one is to enter said password ?
  701. Mar 20 22:25:03 <ninjashogun>   well, for example, for the mitigation strategy I talked about (finding a cardano on a bus and Googling wtf did I just find - it looks kind of like a USB stick...) - it doesn't really matter
  702. Mar 20 22:25:22 <asciilifeform> remember, i did explain that people have asked before, 'why no keypad' etc.
  703. Mar 20 22:25:26 <ninjashogun>   it doesn't have to be kept secure - it just has to be kept OFF the cardano, after it's unplugged, and that's the only requirement
  704. Mar 20 22:25:52 <asciilifeform> the answer is that the user is expected to understand that a cardano used for some important purpose is -never- to leave his personal control.
  705. Mar 20 22:26:01 <ninjashogun>   so if the only hard requirement is the password has to be off of the cardano once it's unplugged, we realize that it's not that hard to get it on there.
  706. Mar 20 22:26:10 <ninjashogun>   I understand this
  707. Mar 20 22:26:24 <ninjashogun>   but the same is true of a house key.  You can copy it in within 5 seconds by putting an imprint onto clay or something
  708. Mar 20 22:26:31 <asciilifeform> entirely true.
  709. Mar 20 22:26:42 <asciilifeform> house key is an entirely different class of device than cardano.
  710. Mar 20 22:26:42 <ninjashogun>   and yet it's better not to write your address on it
  711. Mar 20 22:26:57 <asciilifeform> let me give you an example
  712. Mar 20 22:27:03 <ninjashogun>   ok
  713. Mar 20 22:27:08 <asciilifeform> soviet nuclear submarines have manually-operated reactor controls.
  714. Mar 20 22:27:12 <asciilifeform> can you guess why?
  715. Mar 20 22:27:25 <ninjashogun>   hmmm
  716. Mar 20 22:27:35 <ninjashogun>   against a virus? :)
  717. Mar 20 22:27:46 <ninjashogun>   or trojan, etc
  718. Mar 20 22:27:52 <asciilifeform> considering that the present designs date to the 1960s, this is not the answer.
  719. Mar 20 22:28:09 <ninjashogun>   then why?
  720. Mar 20 22:28:33 <asciilifeform> because 1) always a man in the loop 2) he is expected to understand the gravity of his situation.
  721. Mar 20 22:28:39 <asciilifeform> no mechanism will take over for him
  722. Mar 20 22:28:55 <asciilifeform> psychologists call this 'risk homeostasis'
  723. Mar 20 22:28:59 <ninjashogun>   I don't quite understand....
  724. Mar 20 22:29:01 <asciilifeform> (look it up)
  725. Mar 20 22:29:05 <ninjashogun>   ok
  726. Mar 20 22:29:15 <ninjashogun>   ah
  727. Mar 20 22:29:19 <ninjashogun>   so it's to keep the person more alert
  728. Mar 20 22:29:23 <ninjashogun>   since he has more responsibility
  729. Mar 20 22:29:24 <asciilifeform> correct
  730. Mar 20 22:29:38 <ninjashogun>   that is good.
  731. Mar 20 22:29:44 <ninjashogun>   This is an EXTREMELY good answer.
  732. Mar 20 22:29:49 <ninjashogun>   I like it very much.
  733. Mar 20 22:29:50 <asciilifeform> for this same reason, recent luxury cars which brake automatically are a terrible idea
  734. Mar 20 22:29:57 <asciilifeform> and people will come to regret buying them
  735. Mar 20 22:30:01 <ninjashogun>   This is why it has to be as exposed as a house key you can copy in 5 seconds with a clay impresssion.
  736. Mar 20 22:30:06 <asciilifeform> right.
  737. Mar 20 22:30:14 <ninjashogun>   This is a good design decision.
  738. Mar 20 22:30:35 <asciilifeform> naturally, an individual owner is welcome to make his 'house key' more difficult to copy quckly
  739. Mar 20 22:30:40 <asciilifeform> e.g. by encasing it in concrete
  740. Mar 20 22:30:42 <ninjashogun>   so, then if we want to marry it with reducing the exposurre for the branch where a cardano IS discovered, we would have to add this mechanism in a way that did NOT reduce the perceived risk.
  741. Mar 20 22:30:50 <ninjashogun>   I understand
  742. Mar 20 22:30:59 <asciilifeform> there's the rub. any such mechanism always reduces perceived risk.
  743. Mar 20 22:31:13 <ninjashogun>   No, for example a single-digit PIN (#1-#10) wouldn't.
  744. Mar 20 22:31:27 <ninjashogun>   because of the users.  nobody would consider that any different from no pin.
  745. Mar 20 22:31:51 <asciilifeform> i have to say, i disagree.
  746. Mar 20 22:31:56 <ninjashogun>   really?
  747. Mar 20 22:32:07 <ninjashogun>   a three-digit luggage lock is considered secure by your target audience?
  748. Mar 20 22:32:10 <asciilifeform> most people would regard a safe with a keypad lock as in some sense more secure than a similar box with no lock.
  749. Mar 20 22:32:20 <asciilifeform> well, more secure than no such lock.
  750. Mar 20 22:32:38 <ninjashogun>   ok
  751. Mar 20 22:32:59 <asciilifeform> one of the things i hope to explain to you (and anyone else who asks) is that secure design is about more than mere mechanics
  752. Mar 20 22:33:05 <asciilifeform> it is also about encouraging correct psychology
  753. Mar 20 22:33:09 <ninjashogun>   so the design challenge is to somehow keep recovery of the private key from instantly divulging the public key, without increasing a user's sense of security of the physical device.
  754. Mar 20 22:33:18 <ninjashogun>   I agree with you 100%.
  755. Mar 20 22:34:22 <ninjashogun>   Couldn't this be done as simply as having to give the Cardano a copy of the public key you want it to sign?  This doesn't seem like a password.  It can then take that public key, hash it with salt, and then use the hash to decrypt the private key.
  756. Mar 20 22:34:24 <asciilifeform> incidentally, a cardano which is stolen (vs. misplaced) will be put to use without any difficulty whatsoever by the thief, given that he knows who he meant to steal from.
  757. Mar 20 22:34:37 <asciilifeform> regardless of any hypothetical mathematical curiosities
  758. Mar 20 22:34:50 <ninjashogun>   This is obviously useless as a security measure for anyone who knows hwo the intended victim is or what theyy're trying to attack.  However, it would keep the private key from divulging the public key, without alerting the user that he is doing something less secure.
  759. Mar 20 22:35:01 <ninjashogun>   yes, this is true.
  760. Mar 20 22:35:08 <asciilifeform> once again - risk homeostasis.
  761. Mar 20 22:35:19 <ninjashogun>   But it doesn't seem like a password.
  762. Mar 20 22:35:28 <ninjashogun>   Nor is it one.
  763. Mar 20 22:35:42 <asciilifeform> owner must understand that losing his cardano is equivalent to losing his entire bank account, converted into gold, or whatever else the device was meant to protect in his particular case.
  764. Mar 20 22:35:43 <ninjashogun>   But I agree ,this "solution" was just a first approximation, as you can see I came up with it in just 2 minutes.
  765. Mar 20 22:35:49 <ninjashogun>   yes
  766. Mar 20 22:36:03 <ninjashogun>   Let me ask you this.
  767. Mar 20 22:36:36 <ninjashogun>   If the user had a physical key to a bank vault.  And that key is the only thing the bank asks for.  He (or anyone in its possession) can then open the vault (after showing the key) and empty it of its contents....
  768. Mar 20 22:36:49 <asciilifeform> certainly.
  769. Mar 20 22:37:25 <ninjashogun>   In this case you wouldn't consider it more secure if hte key actually had a 20-digit symmetric key that needed to be entered before it worked?
  770. Mar 20 22:37:36 <ninjashogun>   (I'm not saying this is GOOD design.  just, wouldn't it be more secure?)
  771. Mar 20 22:37:44 <asciilifeform> more secure in one way - less, in another
  772. Mar 20 22:37:49 <asciilifeform> user is more likely to lose the key.
  773. Mar 20 22:38:11 <ninjashogun>   For a moment consider that I agree with you that this is a bad design.  I'm not arguing for it.
  774. Mar 20 22:38:22 <asciilifeform> are you familiar with the phrase 'safe if used as prescribed' ?
  775. Mar 20 22:38:30 <ninjashogun>   I mean, I do agree iwht you that the 20 digit symmetric key on a bank vault key is bad design, it shouldn't need a keypad, etc.
  776. Mar 20 22:38:31 <ninjashogun>   yes
  777. Mar 20 22:38:50 <ninjashogun>   but setting that aside for a moment - if the user loses this badly-designed key, what happens?
  778. Mar 20 22:39:04 <asciilifeform> note that anyone who wishes to keep his cardano inside a safe, secured by a combination lock, is free to do so.
  779. Mar 20 22:39:16 <ninjashogun>   yes
  780. Mar 20 22:40:04 <asciilifeform> i don't dispute that some folks would like a device similar to cardano, but having a keypad for password.
  781. Mar 20 22:40:17 <asciilifeform> they are free to build such.
  782. Mar 20 22:41:19 <ninjashogun>   But I mean theoretically in this case is there a way to recover the key?
  783. Mar 20 22:41:21 <asciilifeform> incidentally, any such design which requires a key to be entered merely once per power-up is vulnerable to a very simple kind of theft
  784. Mar 20 22:41:27 <asciilifeform> where the thief patches power cable
  785. Mar 20 22:41:35 <asciilifeform> to continue powering the unit as it is carried away.
  786. Mar 20 22:41:52 <ninjashogun>   do people really want you to have a physical keypad?
  787. Mar 20 22:41:55 <ninjashogun>   I don't like that idea.
  788. Mar 20 22:41:58 <asciilifeform> thereby leaving the owner worse off than had he understood that the loss of his cardano inevitably means defeat.
  789. Mar 20 22:42:16 <ninjashogun>   yes, that is a good point
  790. Mar 20 22:42:44 <ninjashogun>   this is a very good design consideration
  791. Mar 20 22:43:37 <ninjashogun>   I still can't help but feel that it increases the intrinsic value of the cardano in some sense.
  792. Mar 20 22:43:52 <ninjashogun>   For example, a cardano protecting $1M in gold would at all times be worth $1M
  793. Mar 20 22:44:39 <asciilifeform> i do not know where you come from, or what your trade is, or what you've studied - but please try to apprehend that i have a certain trade, and understand it quite well. as does, for instance, a machinist, or a watchmaker.
  794. Mar 20 22:44:46 <ninjashogun>   whereas with some means of symmetrically unencrypting the password, it is only worth intrinsically $1M whenever it is powered on, at other times it is worth $0 + the weighted chances of getting the pin out of the user before he can empty the account elsewhere
  795. Mar 20 22:44:49 <asciilifeform> likewise, mp has a certain trade that he knows quite well.
  796. Mar 20 22:45:04 <ninjashogun>   okay
  797. Mar 20 22:45:19 <ninjashogun>   I do feel your design decisions are very good
  798. Mar 20 22:45:38 <ninjashogun>   the perfect solution would be one where hte users didn't know, but, secretly, the thiefs would find the powered-down cardano useless.
  799. Mar 20 22:45:52 <ninjashogun>   thieves*
  800. Mar 20 22:45:56 <asciilifeform> no part of cardano design is to remain a secret from the owner.
  801. Mar 20 22:46:02 <asciilifeform> this is rather intrinsic to the idea.
  802. Mar 20 22:46:07 <ninjashogun>   Well, perhaps they know but don't think about it.
  803. Mar 20 22:46:15 <asciilifeform> you are welcome to avoid thinking about it...
  804. Mar 20 22:46:22 <ninjashogun>   Let me put it this way.  A cardano is like a root prompt.
  805. Mar 20 22:46:40 <asciilifeform> google for 'steering wheel spike'
  806. Mar 20 22:46:40 <ninjashogun>   There is a reason people use sudo.  Even though they are technically root, they still want to not have that power ALL the time.
  807. Mar 20 22:46:47 <ninjashogun>   ok
  808. Mar 20 22:47:07 <ninjashogun>   this is hilarious :)
  809. Mar 20 22:47:38 <asciilifeform> there is an entire field of study, called game theory, which you may be familiar with, concerning such matters.
  810. Mar 20 22:47:55 <asciilifeform> it is outside the scope of the matter at hand.
  811. Mar 20 22:48:22 <ninjashogun>   yes I know some game theory
  812. Mar 20 22:48:24 <ninjashogun>   sure
  813. Mar 20 22:48:53 <ninjashogun>   well, I suggest having it as a design goal, even though it is unsolved as-present.
  814. Mar 20 22:48:55 <ninjashogun>   at-present.
  815. Mar 20 22:49:08 <asciilifeform> may as well suggest antigravity, or cold fusion, as a design goal.
  816. Mar 20 22:49:11 <ninjashogun>   the goal being not to decrease perceived risk while mitigating the actual fallout from theft or abandonment.
  817. Mar 20 22:49:21 <asciilifeform> the objective is to solve problems which have actual solutions
  818. Mar 20 22:49:26 <asciilifeform> of cardano, that is
  819. Mar 20 22:49:39 <asciilifeform> there are folks who devote their lives to learning the secret of antigravity, etc.
  820. Mar 20 22:49:53 <ninjashogun>   Unlike antigravity, or cold fusion, I've already suggested something that solves the second problem without increasing security.  Everyone knows your PUBLIC key is PUBLIC.  Giving it to the cardano wouldn't count as a password. But it could prevent identification of the public key if randomly found.
  821. Mar 20 22:50:20 <ninjashogun>   and it would in no way increase actual security.
  822. Mar 20 22:50:37 <asciilifeform> nope. it would take at most a few weeks to gather all known public keys and test each one
  823. Mar 20 22:50:44 <asciilifeform> against an extracted crypted private key block.
  824. Mar 20 22:50:56 <ninjashogun>   That is a long time :)  The person might have nothing :)
  825. Mar 20 22:51:01 <asciilifeform> this is doable at minimal expense
  826. Mar 20 22:51:07 <ninjashogun>   okay
  827. Mar 20 22:51:09 <asciilifeform> because the public keys, are, well, public.
  828. Mar 20 22:51:13 <ninjashogun>   yes, they're public
  829. Mar 20 22:51:24 <asciilifeform> so it is a uniquely poor choice of password
  830. Mar 20 22:51:31 <ninjashogun>   it's not a password
  831. Mar 20 22:51:38 <ninjashogun>   precisely because it's public
  832. Mar 20 22:51:39 <asciilifeform> well, symmetric 'ignition key'
  833. Mar 20 22:51:52 <asciilifeform> it still functions as a password, in your proposed scenario.
  834. Mar 20 22:51:58 <asciilifeform> regardless of what you call it.
  835. Mar 20 22:52:34 <ninjashogun>   how about combined with a file that definitely doesn't look like a password but that the user has on their PC.  A photo for example.
  836. Mar 20 22:52:45 <ninjashogun>   nobody uses a photo as a password, it's silly.
  837. Mar 20 22:53:00 <ninjashogun>   but you cna't very well try EVERY public key combined with EVERY picture from the internet
  838. Mar 20 22:53:10 <asciilifeform> cardano is meant to be self-contained.
  839. Mar 20 22:53:18 <ninjashogun>   not used in conjunction with a pc though?
  840. Mar 20 22:53:22 <asciilifeform> no loss, save that of the unit itself, will prevent the owner from using it.
  841. Mar 20 22:53:25 <asciilifeform> think of it that way.
  842. Mar 20 22:53:52 <asciilifeform> the point is to make it crystal clear what the valuable object is.
  843. Mar 20 22:53:56 <ninjashogun>   yes
  844. Mar 20 22:54:04 <asciilifeform> and where the owner's responsibility to protect lies.
  845. Mar 20 22:54:04 <ninjashogun>   although public pictures could always be found again.
  846. Mar 20 22:54:25 <ninjashogun>   but you're right it is getting silly to add a scheme like this just to prevent accidentally found cardano's from being used.
  847. Mar 20 22:54:56 <asciilifeform> the very notion of an 'accidentally found cardano' should be thought of as ridiculous - on par with an 'accidentally found bag of diamonds.'
  848. Mar 20 22:55:04 <asciilifeform> that is, physically possible, but you will never find one.
  849. Mar 20 22:55:06 <ninjashogun>   that happens.
  850. Mar 20 22:55:14 <ninjashogun>   sure it does.  happens all the time.
  851. Mar 20 22:55:25 <asciilifeform> it would be odd to suggest that diamond rings should be permanently affixed to safes.
  852. Mar 20 22:55:31 <ninjashogun>   yes
  853. Mar 20 22:55:32 <asciilifeform> on account that they might be stolen or lost.
  854. Mar 20 22:55:39 <ninjashogun>   yes :)
  855. Mar 20 22:56:02 <ninjashogun>   So you really want a cardano to have the same value as a diamond.
  856. Mar 20 22:56:08 <asciilifeform> right.
  857. Mar 20 22:56:15 <asciilifeform> or as whatever it is meant to protect
  858. Mar 20 22:56:21 <asciilifeform> whether diamond or dirt
  859. Mar 20 22:56:29 <asciilifeform> this is the purchaser's concern, not mine.
  860. Mar 20 22:56:55 <ninjashogun>   you said, if someone wants to keep it in a safe they can do so
  861. Mar 20 22:57:01 <asciilifeform> certainly.
  862. Mar 20 22:57:13 <asciilifeform> i would not undertake to supply the safe.
  863. Mar 20 22:57:22 <asciilifeform> because there are other people who specialize in the matter of safes.
  864. Mar 20 22:57:37 <asciilifeform> nor will i offer to supply a house in which to keep the safe, etc.
  865. Mar 20 22:57:40 <ninjashogun>   would you include functionality for a password folder on the USB mass storage device - and if they physically create ".password" as a folder and put a password in, it will be used symmetrically and then deleted every time it is unplugged?  (requiring the user to recreate it to work)
  866. Mar 20 22:57:59 <asciilifeform> this is a terrible idea, for reasons that i have already explained.
  867. Mar 20 22:58:13 <asciilifeform> if you disagree, you are welcome to construct and market a device which behaves this way.
  868. Mar 20 22:58:16 <ninjashogun>   The problem is that users can't create a safe physically.
  869. Mar 20 22:58:19 <ninjashogun>   no
  870. Mar 20 22:58:27 <ninjashogun>   but users cannot actually create a safe as you suggest.
  871. Mar 20 22:58:33 <asciilifeform> why not?
  872. Mar 20 22:58:40 <asciilifeform> safes are sold in every part of the world
  873. Mar 20 22:58:51 <asciilifeform> of whatever quality your budget and space constraints permit
  874. Mar 20 22:59:01 <ninjashogun>   Because it would work at a physical level (put the cardano in a safe) - that can be cracked physically.  It wouldn't work at the cryptographic level (use a symmetric key that gets discarded on powerdown)
  875. Mar 20 22:59:27 <ninjashogun>   the former is insecure.  a physical safe isn't secure, for anything, ever.  (In a cryptographic sense.)
  876. Mar 20 22:59:33 <asciilifeform> if you are not familiar with 'memory remanence', i suggest that you read about it.
  877. Mar 20 22:59:38 <asciilifeform> google 'cold boot attack'
  878. Mar 20 22:59:48 <ninjashogun>   I've heard of these yes
  879. Mar 20 23:00:12 <asciilifeform> or, more simply, the scenario with a portable battery patched into the power supply of an operating cardano that is to be lifted.
  880. Mar 20 23:00:33 <ninjashogun>   why would you need that, if you have access to the cardano plugged into a pc?
  881. Mar 20 23:01:07 <ninjashogun>   by the way any safe a user could buy is easier to crack then getting cold boot attack working.
  882. Mar 20 23:01:25 <asciilifeform> both are fairly simple in practice.
  883. Mar 20 23:01:38 <ninjashogun>   Maybe.  But at the moment only the former is possiible for the user.
  884. Mar 20 23:01:56 <asciilifeform> the point, which i am failing to explain to you, is that there is a deliberate emphasis on the catastrophic nature of losing physical control of cardano.
  885. Mar 20 23:01:56 <ninjashogun>   they would have to write their own firmware to use a symmetric key if they wanted that, against your wishes.
  886. Mar 20 23:02:26 <ninjashogun>   okay
  887. Mar 20 23:02:30 <asciilifeform> anyone who wishes can load his own firmware into the device - or, for that matter, construct a similar - or different - device which serves the same purpose.
  888. Mar 20 23:03:03 <asciilifeform> he could, hypothetically, even sell it as 'cardano' and in practice i would be quite powerless to stop him
  889. Mar 20 23:03:16 <ninjashogun>   I think mirceau might not be :)
  890. Mar 20 23:03:19 <asciilifeform> perhaps
  891. Mar 20 23:03:22 <ninjashogun>   if he has a whole PR person
  892. Mar 20 23:03:37 <asciilifeform> but the buyer will have a rather easy time determining whether his unit is the genuine article.
  893. Mar 20 23:03:49 <ninjashogun>   ok
  894. Mar 20 23:04:07 <ninjashogun>   you bring up a really good point
  895. Mar 20 23:04:14 <ninjashogun>   so I see where your design decision comes from
  896. Mar 20 23:04:20 <asciilifeform> glad to hear it.
  897. Mar 20 23:04:44 <ninjashogun>   it would be interesting to know whether there is anything that could be subtlely added
  898. Mar 20 23:04:47 <asciilifeform> i do not begrudge people some explanation of the how/why of the design, if they seem interested.
  899. Mar 20 23:04:49 <ninjashogun>   maybe not though
  900. Mar 20 23:04:58 <ninjashogun>   sure, it makes sense
  901. Mar 20 23:05:39 <ninjashogun>   btw how long do cold boot attacks last in your opinion?
  902. Mar 20 23:06:39 <asciilifeform> this subject is beaten to death in the literature
  903. Mar 20 23:06:44 <asciilifeform> google.
  904. Mar 20 23:06:54 <asciilifeform> or, if you wish, experiment personally
  905. Mar 20 23:07:10 <asciilifeform> ('canned air' duster will work as a freezer)
  906. Mar 20 23:07:33 <ninjashogun>   ok
  907. Mar 20 23:08:33 <asciilifeform> i should note that if you wish to converse at length with me, i prefer email (unlike mp, who is partial to real-time chat)
  908. Mar 20 23:08:42 <asciilifeform> my site contains an addr.
  909. Mar 20 23:08:44 <ninjashogun>   I will think a bit more about this design decision and see if there is any way to increase the benefits.  For example, in your Soviet Submarine example, perhaps there can still be a choice between a feedback loop that makes a meltdo possible, or if it's not going to actually happen for some reason that is still very uncomfortable.
  910. Mar 20 23:08:53 <ninjashogun>   no it's fine
  911. Mar 20 23:08:57 <ninjashogun>   this has been a fine chat
  912. Mar 20 23:09:11 <asciilifeform> i hope that i have taught you something useful.
  913. Mar 20 23:09:24 <ninjashogun>   you have good thoughts, though I'm not quite through to your exact solution.  I think there is more to be discovered that meets BOTH your design constraints, and some other things.
  914. Mar 20 23:09:41 <ninjashogun>   but you have very good constraints for starters.  you've chosen them very well
  915. Mar 20 23:10:47 <ninjashogun>   I'll see you next time.  later*
  916. Mar 20 23:10:56 <asciilifeform> good night
  917. **** BEGIN LOGGING AT Sun Mar 23 13:29:50 2014
  918.  
  919. Mar 23 13:29:50 <ninjashogun>   I have some more questions :)
  920. Mar 23 13:30:04 <ninjashogun>   do you think when you sell the Cardano you will keep a customer list?  i.e. know who you've shipped to?
  921. Mar 23 13:30:09 <asciilifeform> ask them in the channel plz
  922. Mar 23 13:30:14 <asciilifeform> i do so hate repeating things
  923. Mar 23 13:30:16 <ninjashogun>   nah, they're very trollish at hte moment
  924. Mar 23 13:30:21 <ninjashogun>   I mean in general
  925. Mar 23 13:30:31 <ninjashogun>   I will probably leave the channel, possibly I'll be back in a few months under a different nick.
  926. Mar 23 13:31:04 <ninjashogun>   I've done that before (in #startups) where originally I had a terrible, trollish reception but then everyone is fine.  I'm good friends with them (for IRC), including rmah from there.  Who had  been extremely trollish with me under an earlier nick.
  927. Mar 23 13:31:35 <ninjashogun>   so I don't hold it against people if they are trollish. It just comes with the Internet.
  928. Mar 23 13:32:54 <ninjashogun>   The reason I ask about customer lists is because it is another vector.  It is quite interesting if there is a list "These 1,000 people have bought a Cardano and in stock configuration categorically it is equivalent to their bare plaintext private key.  Here is where they live."
  929. Mar 23 13:33:14 <ninjashogun>   I wonder if you plan on mitigating that
  930. Mar 23 13:33:20 <asciilifeform> what do you think the answer is.
  931. Mar 23 13:35:59 <ninjashogun>   I think the answer must be yes, as it is very difficult to ship a physical product without leaving traces EVERYWHERE - from postal tracking information (after you send parcels) to payment linked to shipping, etc.  If you take shipping details it is a bit silly to think of it as being destroyed, while considering that you can stil actually ship the parcels.  It would be in the database of your c
  932. Mar 23 13:35:59 <ninjashogun>   ourrier company under your account, as well.
  933. Mar 23 13:36:16 <ninjashogun>   So overall I would think your answer is, "Yes, they should assume we have that information.  They have to trust us."
  934. Mar 23 13:36:16 <asciilifeform> this is a question for mp, not for me.
  935. Mar 23 13:36:25 <ninjashogun>   oh
  936. Mar 23 13:36:30 <ninjashogun>   I thought you did the security architecture?
  937. Mar 23 13:36:30 <asciilifeform> write to him, he'll answer, if he feels like it.
  938. Mar 23 13:37:21 <ninjashogun>   btw here is an interesting article - http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/ I wonder how you feel about it.  It was just discussed here:
  939. Mar 23 13:37:26 <asciilifeform> you perhaps notice that the project has more than one person.
  940. Mar 23 13:37:36 <asciilifeform> i do certain things; mp, other things; yet other people - do what remains
  941. Mar 23 13:37:39 <ninjashogun>   I thought you said that in the main you developed it with MP.
  942. Mar 23 13:37:44 <asciilifeform> correct
  943. Mar 23 13:37:53 <ninjashogun>   you also told me he does sales and marketing.
  944. Mar 23 13:38:59 <ninjashogun>   Well, so far I haven't discussed security design details of Cardano with him.  When I discussed this briefly in-channel, he didn't contribute thoughts.  (On the other hand some people, e.g. benkay, were annoyed.)
  945. Mar 23 13:39:21 <asciilifeform> try to understand why they were annoyed.
  946. Mar 23 13:40:08 <ninjashogun>   Probably juts their impression.  Like I said, I have a good relationship in another channel with others, yet if I came in with an earlier nick I no longer use, they would become trolls.  It's just impressoins.
  947. Mar 23 13:41:26 <ninjashogun>   For example, I've seen MP actively troll (in my opinion) the ughlol person, through to writing an article on it.  In the same amount of effort, a rape whistle app (if it works, he says he has tested the volume of mobile phones and can annoy people with them) could have been submitted to the app store and downlodaed 50,000 times.  It's a big pain point/problem in India.  It would also let some m
  948. Mar 23 13:41:26 <ninjashogun>   en "white knight" and help rescue a person in trouble, which some men are interested in doing.
  949. Mar 23 13:42:25 <ninjashogun>   So it is a very real problem.  He has a solution he's tested.  It is marketable today, in under a week.  Rather than help this 19 year old do so (and could have bought an option for half his company for $10,000, the option would have cost $1) they chose (from what I understand) to troll him.
  950. Mar 23 13:42:36 <ninjashogun>   I wasn't in channel at that time, though.
  951. Mar 23 13:43:25 <ninjashogun>   I think people online have a propensity to become trolls, and this needs to be actively dealt with or handled.
  952. Mar 23 13:43:57 <asciilifeform> let me teach you a russian saying - 'one oughtn't come with ones own vows to another man's monastery.'
  953. Mar 23 13:44:15 <asciilifeform> you came to the channel, and to you it seems like a broken, perverted version of the world you're accustomed to
  954. Mar 23 13:44:24 <asciilifeform> because it is different. but it isn't broken.
  955. Mar 23 13:44:50 <asciilifeform> try to understand this. it will save you much headache.
  956. Mar 23 13:45:44 <asciilifeform> if you want to actually have conversations with folks in #btca, vs. mere flamefests, try to figure out why you end up setting off everybody's immune system.
  957. Mar 23 13:57:59 <ninjashogun>   Yes.
  958. Mar 23 13:58:07 <ninjashogun>   I understand this.
  959. Mar 23 13:58:14 <ninjashogun>   Probably because it is a much lower-volume channel than I was used to.
  960. Mar 23 13:58:26 <ninjashogun>   I didn't realize how few people are in it (same people all the time) as compared with, for example, #bitcoin
  961. Mar 23 13:59:56 <ninjashogun>   At any rate given my previous experience of this I would probably just come back in a few months under a different nick.  I suppose I can mention at that time that I was in before.
  962. Mar 23 15:19:47 <ninjashogun>   I've thought more about your arguments, and the thing that tips it in favor of a default passphrase on the private key is the vector from your side.  There is no way to keep your or MP's account with the shipping company from locating all the addresses you've shipped Cardanos to.  It is a VAST difference whether thiefs know that those are unencrypted, or encrypted with a passphrase.  Yes, they
  963. Mar 23 15:19:47 <ninjashogun>   can still get around the passphrase, but they're not just going to randomly start visiting people hope to find a live Cardano that is still plugged in.  Cold booting attacks are possible to work around by rewriting the memory 35x.
  964. Mar 23 15:21:22 <ninjashogun>   so it is a vast difference between saying "these 2000 address possess a totally unprotected cardano" and "these 2000 addresses possess a cardano with a passphrase."  That is a totally different level of vector.
  965. Mar 23 15:22:27 <ninjashogun>   It's also the reason that servers are supposed to store only hashes of passwords, not the passwords.  There is a vast difference between "we are storing 20,000 passwords in the clear - get htem and you can access any of those accounts" and "we are storing 20,000 hashes of passwords.  Getting them won't tell you the password, you still have to break our authentication method as well."
  966. Mar 23 16:43:06 *       ninjashogun has quit (Disconnected by services)
RAW Paste Data
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand
 
Top