Re: Saving encrypted customProperties outside the app?
On Monday, September 29, 2003, at 02:45 PM, Dar Scott wrote: The biggest part of that is not the method or the speed, but the logistics of keeping up with signatures and the like to allow users to verify the integrity of the module. Users will need to depend on the integrity of signers and either their experience and dedication to managing signed code or the review-ability of the code. To me, this means that initial encryption modules must be in Transcript, but I would consider an external. Another possibility would be external programs run by shell for some needs. I change my mind slightly. There are some memory handling benefits to an external. I would move to the front an external that references a signed and well established dll or similar library. Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Saving encrypted customProperties outside the app?
What if externals were simplified to be as easy to use as native calls? Richard, et al: I guess I would find it difficult to complain too loudly IF that were the case AND the externals provided noticeable performance enhancements. In general, my vision for libIPC, revBlowfish, SDB, other output from the revolution_ipc group, is for a package that that installs seamlessly on all platforms with no differences except the runtime engine. Rob Cozens, Co Moderator revolution_ipc group ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Saving encrypted customProperties outside the app?
Rob Cozens wrote: What if externals were simplified to be as easy to use as native calls? Richard, et al: I guess I would find it difficult to complain too loudly IF that were the case AND the externals provided noticeable performance enhancements. In general, my vision for libIPC, revBlowfish, SDB, other output from the revolution_ipc group, is for a package that that installs seamlessly on all platforms with no differences except the runtime engine. libIPC and SDB are moving along well and appear ideal as Transcript libraries. My only concern is for the performance, usability, and distribution limitations of revBlowfish. Mark has done a truly amazing job and deserves many kudos and at least a six-pack of his favorite beverage in recognition of what he's accomplished. But for Blowfish to become a practical option for general use it would require revisions; like Mark pointed out, its currently more an example than a product. I'd sure like to see truly strong encryption as a pair of functions available for common use. -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Saving encrypted customProperties outside the app?
Richard, et al:
... for Blowfish to become a practical option
for general use it would require revisions; like Mark pointed out, its
currently more an example than a product.
As are libIPC, SDB, and possibly even Dar's contributions to the
revolution_ipc stack library; but given the group is less than a year
old and spent at least the first three months discussing how to
organize license its output, I think we have established our
potential to take the foundations we have constructed and mold them
into high-quality developers' tools.
And let me emphasize tools. Correct me if I misspeak, Jan: The
goal of the revolution_ipc group is to provide tools for Revolution
developers, NOT products.
I'd sure like to see truly
strong encryption as a pair of functions available for common use.
That is a kind of tool we seek to create. Whether we create the
functions as Transcript handlers in a library or externals is where
your viewpoint may differ from mine.
Mark has contributed Rev_Blowfish to the revolution_ipc group's stack
library as a starting point for incorporating support for Blowfish
encryption/decryption into the collection of IPC commands that will
be released (most likely) in one library stack, Jan's libIPC.
Anyone who would like to help turn our examples into produ... oops!,
make that tools :{`), is welcome to join our group.
Rob Cozens, Co Moderator
revolution_ipc group
http://groups.yahoo.com/group/revolution_ipc/
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Saving encrypted customProperties outside the app?
On Tuesday, September 30, 2003, at 12:29 PM, Rob Cozens wrote:
Anyone who would like to help turn our examples into produ... oops!,
make that tools :{`), is welcome to join our group.
One might use product in the sense of that which is produced. Though
that produced by the group may be broad, the initial outcome that is
key and primary will be freely usable (in some sense) components.
Dar Scott
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Saving encrypted customProperties outside the app?
One might use product in the sense of that which is produced
Ah Dar,
I knew someone would challenge that.:{`)
I considered qualifying the remark with an analogy; but I believe
there is a demonstrable difference between the concept of two
handlers in a library and an encryption product...along the same
lines as the difference between the collection of Rev socket commands
and an IPC product.
--
Rob Cozens
CCW, Serendipity Software Company
http://www.oenolog.net/who.htm
And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee.
from The Triple Foole by John Donne (1572-1631)
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Saving encrypted customProperties outside the app?
Rob Cozens wrote: I considered qualifying the remark with an analogy; but I believe there is a demonstrable difference between the concept of two handlers in a library and an encryption product...along the same lines as the difference between the collection of Rev socket commands and an IPC product. When I used product in my post I did so only to differentiate between a proof-of-concept and a finished usable work. Anything that requires consultation for installation and use will not be as widely used as a library like libURL, documented and ready to go. It's like Steve McConnel's summary of why a product takes an order of magnitude more time to make than a tool: With a tool, it only needs to be possible to use it correctly. But with a product, it should be impossible to use it incorrectly. Side note in praise of libURL: libURL is one of the most beautiful, robust, flexible libraries I've ever even dreamed of. I've been using parts of it I've never used before for an article I'm writing, and I've been pleasantly surprised to find so much in it. FTP downloads -- even with callbacks updating a progress bar -- perform on par with Interarchy. Who would have thought we'd see performamce like that in a 4GL? In more than a year of shipping WebMerge with FTP I've only had two support issues related to that -- and both were in my code; libURL was doing its job perfectly. Hats off to everyone who contributed to libURL, esp. Dave Cragg for the great options added in recent versions. -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge: Publish any database on any Web site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Saving encrypted customProperties outside the app?
On Tuesday, September 30, 2003, at 11:29 AM, Rob Cozens wrote: Mark has contributed Rev_Blowfish to the revolution_ipc group's stack library as a starting point for incorporating support for Blowfish encryption/decryption into the collection of IPC commands that will be released (most likely) in one library stack, Jan's libIPC. Rob, et al: This is how I envision using blowfish with Jan's libIPC. The Blowfish algorithm would be separated from all key authentication and encryption level handlers and would run from two parts. Part one would be the creation of the P and S boxes based on an encryption key passed to it. Part two would be encryption or decryption of data using these P and S boxes. This process would leave the algorithm's bit level wide open to developers, and in my opinion it should. In other words the developer would use 64 bit in a parameter and that would automatically limit the bit level to 64 bit encryption. function createBoxes, encryptionKey, bitLevel return P1Array return S1Array return S2Array return S3Array return S4Array end createBoxes So: createBoxes(abcdefgh, 64) gives you a set of boxes for this key these boxes could be stored as a fixed set of boxes that encrypt/decrypt can use later if you wish this capability. --- function encryptData dataToEncrypt -- uses the P1, S1, S2, S3, S4 arrays somehow. -- This is done so that preset boxes can be used that -- matches a certain encryption key. return encryptedDataChunk end encryptData function decryptData dataToDecrypt -- uses the P1, S1, S2, S3, S4 arrays somehow. -- This is done so that preset boxes can be used that -- matches a certain encryption key. return decryptedDataChunk end decryptData So: put encryptData(your data here) into blabWhat So: put decryptData(~1*^ /hd io%) into sayWhat for a higher level of libIPC security there should be this even though it will slow things down during the first half second of process. function encryptDataBest dataToEncrypt, encryptionKey, bitLevel -- P1, S1, S2, S3, S4 arrays are created here first return encryptedDataChunk end encryptDataBest function decryptDataBest dataToDecrypt, encryptionKey, bitLevel -- P1, S1, S2, S3, S4 arrays are created here first return decryptedDataChunk end decryptDataBest So: put encryptData(your data here, abcdefgh, 64) into blabWhat So: put decryptData(~1*^ /hd io%, abcdefgh, 64) into sayWhat --- So the thing here is you would have unrestricted blowfish that requires the developer to set the bit level available from the libIPC. It should be written so that if the parameter for bit level is missing that the function should exit without working. This puts the responsibility on the shoulders of the developer using the libIPC. Now what is not worked out here is a function for setting a proper access key. revBlowfish uses 56 chars everytime for the key. 32 bit encryption = 4 chars repeated 14 times = 56 64 bit encryption = 8 chars repeated 7 times = 56 96 bit encryption = 12 chars repeated 4.66 times = 56 128 bit encryption = 16 chars repeated 3.5 times = 56 So the createBoxes(abcdefgh, 64) would take the first 8 chars of the passed key and repeat them 7 times to create the key that blowfish uses to create the boxes. Proper key creation or use should be handled by the developer I think. If a generic key manipulation feature were desired then a separate function could be created for the libIPC. This would be used for situations where twelve keys where needed and only ten where provided Mark ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Saving encrypted customProperties outside the app?
On Tuesday, September 30, 2003, at 09:18 AM, Richard Gaskin wrote: Mark has done a truly amazing job and deserves many kudos and at least a six-pack of his favorite beverage in recognition of what he's accomplished. Thanks, I'll drink to that... ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Saving encrypted customProperties outside the app?
Alex Rice wrote: I would like to see a stack protection feature that does encryption- through and through. In order to open, run, read, edit, *do anything* no matter if via engine or via IDE, first one would first have to authenticate. It could be password authentication or public key authentication. Authentication could be done by prompting the user, or done by a script in an already running stack. I'd vote for that. Have you Bugzilla'd it? -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge: Publish any database on any Web site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Saving encrypted customProperties outside the app?
Mark Brownell wrote: On Saturday, September 27, 2003, at 10:59 AM, Richard Gaskin wrote: What terms is it available under? Is the final version not being posted to the Revolution_IPC group at Yahoo? It's available there under basic CUA principles. I don't want to explain it here. I'm concerned that someone will need a lot of hand holding to implement it properly. There are export restriction laws in place by different countries that need to be followed when implementing it. This becomes the responsibility and liability of the developer using it in their apps. Wouldn't the disclaimer included with the original Blowfish algorithm suffice? There are better and best user procedures when disguising the encryption key while implementing it in transcript. I made it available to the Revolution_IPC group because that small group didn't need much to understand it and they needed some encryption solution for all the work they are doing there. I did briefly explain its three major parts there. If anyone wants to use it and wants me as a consultant regarding it then I'm available to help anyone that needs my help with it. I will need to collect a consulting fee if that is the case. So money might act like an energy booster. For speed it would seem optimal to have it implemented in an external, or in the engine itself. The usability issues could be addressed along with that. Have you talked with Tuv about the possibility? -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Saving encrypted customProperties outside the app?
For speed it would seem optimal to have it implemented in an external, or in the engine itself. Richard, Mark, et al: No eternals, please! libIPC is 100% Transcript, revBlowfish is 100% Transcript. Let's keep it that way or embed it in the engine. Rob Cozens Co Moderator, revolution_ipc group. -- GOT RIGHTS? What's your color code? ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Saving encrypted customProperties outside the app?
Rob Cozens wrote: For speed it would seem optimal to have it implemented in an external, or in the engine itself. Richard, Mark, et al: No eternals, please! libIPC is 100% Transcript, revBlowfish is 100% Transcript. Let's keep it that way or embed it in the engine. What if externals were simplified to be as easy to use as native calls? I'd vote for the engine, but I'm mindul that if we put everything in the engine it'll become huge, laden with things only a few use. I'm just trying to keep options open for enhanced, high-speed capabilities without encumbering the engine. -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge: Publish any database on any Web site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Saving encrypted customProperties outside the app?
On Monday, September 29, 2003, at 09:17 AM, Richard Gaskin wrote: Alex Rice wrote: I would like to see a stack protection feature that does encryption- through and through. In order to open, run, read, edit, *do anything* no matter if via engine or via IDE, first one would first have to authenticate. It could be password authentication or public key authentication. Authentication could be done by prompting the user, or done by a script in an already running stack. I'd vote for that. Have you Bugzilla'd it? I have now :-) #723 improved stack encryption capability Alex Rice [EMAIL PROTECTED] | Mindlube Software | http://mindlube.com what a waste of thumbs that are opposable to make machines that are disposable -Ani DiFranco ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Saving encrypted customProperties outside the app?
On Monday, September 29, 2003, at 10:55 AM, Alex Rice wrote: #723 improved stack encryption capability The entry #577, put stack into variable, might be generalized to allow 'save', 'open', and 'start using' to refer to variables. Perhaps with that encrypted stacks could then be saved in custom properties and decrypted before use. A script that looks forward to this might save the stack into a temporary folder and then open or start using. This reduces the problem to an encryption problem. The biggest part of that is not the method or the speed, but the logistics of keeping up with signatures and the like to allow users to verify the integrity of the module. Users will need to depend on the integrity of signers and either their experience and dedication to managing signed code or the review-ability of the code. To me, this means that initial encryption modules must be in Transcript, but I would consider an external. Another possibility would be external programs run by shell for some needs. We might consider which possible performance enhancements might best support encryption. I think #586 would help in encryption and not just for speed reasons. Variations on Blowfish might work. (I don't mean variation as in fiddling with it, I mean in application and handling ends.) If the situation is OK for using a stream cypher that works just the same as the one with the trademarked name RC4, I'd like that. I have yet to figure out how to get a SEAL license from IBM, so that is probably out. However, for the light needs of most people here, I think we can put together a simple stream cypher that can be reviewed easily. Even though it might be weak, it might be better than some because it is reviewable. Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Saving encrypted customProperties outside the app?
On Monday, September 29, 2003, at 08:16 AM, Richard Gaskin wrote: Mark Brownell wrote: There are export restriction laws in place by different countries that need to be followed when implementing it. This becomes the responsibility and liability of the developer using it in their apps. Wouldn't the disclaimer included with the original Blowfish algorithm suffice? Richard, If you mean from here: http://www.schneier.com/paper-blowfish-fse.html it might if I didn't need to explain the first part where the rev_blowfish app tries to restrict the encryption key level to 128 bit. It checks for proper key formation and usage. I built this as a demonstration of implementing blowfish. It is not really part of the Blowfish algorithm that comes up after key checking part. Blowfish works from 32 bit to 448 bit encryption levels in 32 bit level steps. The original disclaimer does not reflect the changes in security that have come along since 1993; either that or I forgot what it said. I'm not going to look it up. For speed it would seem optimal to have it implemented in an external, or in the engine itself. The usability issues could be addressed along with that. Have you talked with Tuv about the possibility? -- Richard Gaskin No. I've talked with a few others at Rev about it though. If it were put into the engine then it would be limited to 128 and 64 bit formats because of export restrictions. That could put limitations on Rev distribution. If you add Blowfish into your own standalone apps this makes you, the developer, the person that needs to distribute the app properly under export laws. I have copyrighted the rev_blowfish.rev app so that I can claim restrictions on the actual rev_Blowfish.rev app. The source code inside rev_Blowfish.rev is free to use at your own risk if used responsibly just like it was back in 1993 by Bruce Schneier I learned from other open source examples in C, Visual Basic, and Lingo. This is just an example of it in Transcript. Mark ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Saving encrypted customProperties outside the app?
Mark Brownell wrote: Contact me off list if you are interested in getting Transcript/Blowfish. What terms is it available under? Is the final version not being posted to the Revolution_IPC group at Yahoo? -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge: Publish any database on any Web site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Saving encrypted customProperties outside the app?
On Saturday, September 27, 2003, at 10:59 AM, Richard Gaskin wrote: What terms is it available under? Is the final version not being posted to the Revolution_IPC group at Yahoo? Hi Richard It's available there under basic CUA principles. I don't want to explain it here. I'm concerned that someone will need a lot of hand holding to implement it properly. There are export restriction laws in place by different countries that need to be followed when implementing it. This becomes the responsibility and liability of the developer using it in their apps. There are better and best user procedures when disguising the encryption key while implementing it in transcript. I made it available to the Revolution_IPC group because that small group didn't need much to understand it and they needed some encryption solution for all the work they are doing there. I did briefly explain its three major parts there. If anyone wants to use it and wants me as a consultant regarding it then I'm available to help anyone that needs my help with it. I will need to collect a consulting fee if that is the case. So money might act like an energy booster. On the other hand all my comments regarding rev_blowfish at the Revolution_IPC group are contribution to that group's greater cause. Right now, I'm a little swamped developing an encrypted filing system for MTML publishing. Here is a question I've never asked in a group like this. Has anyone here worked so hard on developing a software app that was so feature rich that the scope of it began to overwhelm your ability to concentrate? It's happened to me in short term moments a few years ago that lasted only several days but I feel like I'm just coming out of a six month phase of diminished capacity. This could be related to stress but it is more like writers block. I just can't work after I hit a limit each day. I have discovered that I was trying to keep all the code in my head until it was completed. I had to learn to compartmentalize the code into smaller parts and to deliberately try to forget the full content of the app's source code just working on one or two functions at a time. I've heard of burn out after about five years, I hope this isn't that. Anyone have or had experience with this or read an article regarding these kind of issues? Mark ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Saving encrypted customProperties outside the app?
On 9/26/03 9:10 AM, Robert Hyde [EMAIL PROTECTED] wrote: So does anyone know of a good way to save custompropertyset information in a data file separate from the app itself in such a way that it would require something akin to a password to get to it even within Rev? Would it be possible to save your properties as scripts of objects in an external password-protected stack? Then when you need to save new settings to the file, you'd set the passkey of the stack and set the script of each property object (no script limit if you use a separate object to store each script). Regards, Scott Rossi Creative Director Tactile Media, Multimedia Design - E: [EMAIL PROTECTED] W: http://www.tactilemedia.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Saving encrypted customProperties outside the app?
On Friday, September 26, 2003, at 10:10 AM, Robert Hyde wrote: So does anyone know of a good way to save custompropertyset information in a data file separate from the app itself in such a way that it would require something akin to a password to get to it even within Rev? I may be overlooking something painfully obvious, but I just can't think of anything. I don't think you are overlooking anything obvious. I really appreciate any suggestions at all. Thanks! I read somewhere that the Rev password mechanism uses an encryption scheme that only works with text. I wonder why? Anyways I guess that's why it skips custom properties but encrypts scripts. Does it encrypt custom properties that are textual? I guess it would *have to* to otherwise fld text properties and control script properties would not get encrypted at all. Couple of ideas * If Rev does encrypt custom properties that are textual, then you could use base64encode()and base64decode() to convert binary custom properties into textual ones. or * Mark Brownell has written a Blowfish encryption engine in transcript. You could use blowfish to encrypt the entire data stack, instead of using Rev's password scheme. Alex Rice [EMAIL PROTECTED] | Mindlube Software | http://mindlube.com what a waste of thumbs that are opposable to make machines that are disposable -Ani DiFranco ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Saving encrypted customProperties outside the app?
Robert Hyde wrote: So does anyone know of a good way to save custompropertyset information in a data file separate from the app itself in such a way that it would require something akin to a password to get to it even within Rev? It's not custom props per se, but might tide you over until a more secure native solution becomes available: http://lists.runrev.com/pipermail/use-revolution/2003-June/017437.html -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge: Publish any database on any Web site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Saving encrypted customProperties outside the app?
Alex Rice wrote: I read somewhere that the Rev password mechanism uses an encryption scheme that only works with text. I wonder why? Anyways I guess that's why it skips custom properties but encrypts scripts. I think the bigger reason is that a good scheme to prevent accessing custom props in the IDE will also prevent them from being accessed at runtime by your scripts. An enhancement would address this: there could be a mainstack property, something like devPassword, which would prevent stacks from being opened in the IDE is set. This should be done in the engine to prevent scripted workarounds for access. -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge: Publish any database on any Web site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Saving encrypted customProperties outside the app?
On Friday, September 26, 2003, at 02:26 PM, Robert Hyde wrote: All this speedy input is great! Unfortunately, I have not been able to test any of this out this afternoon. And I am not familiar with Emacs, is it associated with Rev? No it's just a text editor that happily works with binary files. It's what I was using to look at my data stack on disk. Because I don't want anyone to be able to read the custompropertysets in Rev either. And every time I opened one of the afore-mentioned stacks within Rev, I can see all of the customproperties even though I have to enter the correct password to get to the code. At least at 2.02. But I will explore dumping the customproperties into a script as well as the blowfish option for sure. So after setting the password to something were the customproperties for both text and binary encrypted? And again, thank you for all the help! As Richard clarified for me, even though the custom properties ARE encrypted in the data stack written to disk, someone with a Rev IDE can open the stack and read the custom properties without entering the password. The only custom property requiring a password in the IDE is the script property. Therefore the weird workarounds that were posted about base64encoding custom properties and putting them into the script property of a control. Remaining questions for me: If the password itself is not part of the encryption scheme, then why is a side effect of setting the password to encrypt the stack when written to disk? If the password is not part of the encryption scheme, then at least give us a little information about how secure or insecure this stack encryption scheme is? Alex Rice [EMAIL PROTECTED] | Mindlube Software | http://mindlube.com what a waste of thumbs that are opposable to make machines that are disposable -Ani DiFranco ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Saving encrypted customProperties outside the app?
Alex Rice wrote: The only custom property requiring a password in the IDE is the script property. Therefore the weird workarounds that were posted about base64encoding custom properties and putting them into the script property of a control. Weird perhaps, but functional and available now. http://lists.runrev.com/pipermail/use-revolution/2003-June/017437.html For the future it seems useful to have another level of protection for custom props, but the hard part is coming up with a way for the engine to be able to get and set properties in your standalone without having the Rev IDE or stacks from intruders read them. If you come up with a solution Bugzilla an ehancement request for it. -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge: Publish any database on any Web site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Saving encrypted customProperties outside the app?
On Friday, September 26, 2003, at 03:38 PM, Richard Gaskin wrote: Weird perhaps, but functional and available now. http://lists.runrev.com/pipermail/use-revolution/2003-June/ 017437.html Thanks for the clarification Richard. For the future it seems useful to have another level of protection for custom props, but the hard part is coming up with a way for the engine to be able to get and set properties in your standalone without having the Rev IDE or stacks from intruders read them. If you come up with a solution Bugzilla an ehancement request for it. From my perspective the whole password+encryption mechanism convoluted. Some aspects are encrypted, some aren't, some aspects are password protected, some aren't. The engine itself has elevated privileges and can open, run and edit almost all aspects of a supposedly encrypted stack. Something just doesn't seem right about this. I would like to see a stack protection feature that does encryption- through and through. In order to open, run, read, edit, *do anything* no matter if via engine or via IDE, first one would first have to authenticate. It could be password authentication or public key authentication. Authentication could be done by prompting the user, or done by a script in an already running stack. Maybe a good idea for a 3rd party plugin. The ABC framework for Cocoa programming has something like this- encrypted media bundles you can ship inside your app bundle. Sorry for rambling, Alex Rice [EMAIL PROTECTED] | Mindlube Software | http://mindlube.com what a waste of thumbs that are opposable to make machines that are disposable -Ani DiFranco ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Saving encrypted customProperties outside the app?
On Friday, September 26, 2003, at 09:51 AM, Alex Rice wrote: * Mark Brownell has written a Blowfish encryption engine in transcript. You could use blowfish to encrypt the entire data stack, instead of using Rev's password scheme. I'm working on a method to encapsulate complete data chunks as individual parts. One way to do this would be to use a pull parser to get one part at a time. Example: page encrypted data here... /page In this text file example my encrypted data is htmlText where I deliberately remove line breaks, return numToChar(13) numToChar(10) So later when a cross-platform file is decrypted p return is used to replace p One implementation could be to save each page's encrypted data in an array that is savable in a customProperty. The reason I mention all this is Blowfish takes about a half a second to build the encryption boxes that are used to encrypt and decrypt data. If the data is encrypted in smaller sized user chunks then a Transcript/Blowfish is not noticed much. It can slow things down when you attempt to encrypt an entire data source all at once. Contact me off list if you are interested in getting Transcript/Blowfish. Mark Brownell ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
