You are looking at the result of the adverb. In that sense, verbs don't stay hidden, either, since you can see their results.
That said, the population of people who can read non-trivial J programs is rather small - I expect that most programmers would consider unlocked verbs unreadable. But, of course, most people are not programmers. Also, given any useful set of non-trivial functionality, and some new real-world context, I have found it's often easier to implement from scratch than it is to figure out how to adapt some existing program. (For example, recently, I found it easier to write a specialized web server and data store from scratch than it was to figure out how to get an existing web server and database server to do everything I needed them to do.) I'd be far more worried about writing useful documentation than about people unlocking J adverbs. Maybe that's just me though? Thanks, -- Raul On Thu, Aug 6, 2015 at 1:25 PM, 'Pascal Jasmin' via Programming <[email protected]> wrote: > A variation on lockedV adverb is an a conjunction that assigns any expression > to any locked variable > > lockedE =: 2 : 0 > a =. '%j =: %j' sprintf m;n > (3!:6 ] a) 1!:2 fl =. < jpath '~temp\test.ijl' > 0!:0 fl > 1!:55 fl > ) > 'wa' lockedE '@+:' > 1 > +: wa 4 > 16 > > > woops... adverbs don't stay hidden. > > +: wa > +:@+: > > > > ----- Original Message ----- > From: 'Pascal Jasmin' via Programming <[email protected]> > To: "[email protected]" <[email protected]> > Cc: > Sent: Thursday, August 6, 2015 12:08 PM > Subject: Re: [Jprogramming] unlock.ijs > > 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 > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
