Thank you,
Here is a conjunction that makes individually locked verbs, and a more useful example. The right argument does take 0 : 0 as argument or a string. Its a use of 3!:6 that is meant to protect the user from his code being snooped, rather than protect your code from the user. require 'format/printf' lockedV =: 2 : 0 a =. m sprintf n (3!:6 ] a) 1!:2 fl =. < jpath '~temp\test.ijl' 0!:0 fl 1!:55 fl ) an example hashsalter (modifies hashes with a fixed "secret" padding. Applications include storing passwords resistant to lookup tables) HashSalter =: 'SaltedHash_hashes_ =: ''sha256'' gethash ''%j'' , ]' lockedV above creates an adverb that will create a locked verb when given a parameter. Multiple (boxed) parameters work too... format is sprintf. It deletes all temporary files it creates, and so no complete raw script is left on computer. I believe localization has to be done within the m expression. 'asdf' HashSalter a =. conew 'hashes' NB. not necessary, but just proving locked object code SaltedHash__a f. SaltedHash__a SaltedHash__a 'sdfg' 31f8800596f7aace882b1fac7bfcd347fe7c5c015a44de03771d09843d04b89b 'sha256' gethash 'asdfsdfg' 31f8800596f7aace882b1fac7bfcd347fe7c5c015a44de03771d09843d04b89b I have absolutely no idea how secure this is. One potential application involves securing encryption keys such as PGP. You want to use an expensive disk encryption function so that if your computer is ever stolen, brute force attacks cannot unlock it. But no matter what you do the unencrypted data is going to be in memory at some point. Without 3!:6, a relatively safe architechture is to only store the expensive decryption in a local variable, and repeat it every time you need access to PGP sign something. With this 3!:6 approach I can consider a cheaper decryption function in a locked function. 3!:6 would be secure to J's built in debugger. Security vs. low level debuggers seems like worrying about how sturdy your windows are when your door is left unlocked. If someone has access to your computer to run low level debuggers on it, they can also install keyloggers, which has no real defense to it. My big question is: Whatever weakness of 3!:6, is snooping on stack considered just as easy? ________________________________ From: bill lam <[email protected]> To: 'Pascal Jasmin' via Programming <[email protected]> Sent: Wednesday, August 5, 2015 9:37 PM Subject: Re: [Jprogramming] unlock.ijs I think protection for verb is quite safe, but nouns are not encrypted for obvious reason. Thus if you define a verb by put it into a noun (0 : 0) or linear representation and then derive the verb by 0!:0 or ". then it is susceptible to attack. However I suspect security can never be enforced if the script file is distributed and run by users, eg, someone can redefine pwdcheck=: 1: (untested) Ср, 05 авг 2015, jprogramming написал(а): > Dan Bron created a program that reverses 3!:6 > > > http://www.jsoftware.com/jwiki/DanBron/Temp/Unlock > > but the link to the SVN is dead. > > My main question assuming it comes back, or someone else duplicates it, > > does the unlock script need access to the locked file, or does it do > everything in memory? > > Dan alluded that he could attack it in memory with undocumented 15!:6 > > The reason I ask is consider this script > > (3!:6 ] 0 : 0) 1!:2 fl =. < jpath '~temp\test.ijl' > pwdcheck =: 'password' -: ] > ) > 0!:0 fl > 1!:55 fl > > (erases file after load) > > then > > > pwdcheck > pwdcheck > > > pwdcheck 'password' > 1 > pwdcheck 'not password' > 0 > My goal is not the above example. Its to protect "casually sensitive" > information in memory from being snoopable when walking away form computer. > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm -- regards, ==================================================== GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
