One big difference is that encrypt is reversible and messagedigest is not.
Generally for password “storage” you want to use a hash that is one way. You
don’t actually store anything that can be reversed to obtain the actual
password. For that, you are probably better off just doing a couple of
I'm learning this along with you. But this is what I think I know so
far. If you do a test in the message box:
encrypt "mysecret" using "aes256" with password "mypass";put it
You get this:
Salted__«!óÈ/rm55ı it @ˇrȨßQ -- (there's a return in there)
The salt is prepended to the
Bill Prothero wrote:
> On Jun 6, 2018, at 7:32 PM, Richard Gaskin wrote:
>> Are we talking about hashing or encrypting?
>
> Richard,
> I’m talking about using the LC encrypt command, with aes-256
> encryption.
Thanks. The mention of passwords in this discussion threw me.
> I’m trying to
If you are using a known salt, then I would say it makes sense to strip it. It
would make it easier to decrypt if included, but still not easy to break a
cipher that isn’t already cracked.
Since only 8 bytes of the salt are unique/used, it may be better to generate
your own key instead of
Hmmm
If the salt is included in the encrypted text, doesn’t that enable anyone who
intercepts it to decrypt it more easily, invalidating the purpose of using the
salt in the first place.
Or, if the server decrypting the text uses a standard, but secret, salt that is
known by both parties,
Richard,
I’m talking about using the LC encrypt command, with aes-256 encryption. I’m
trying to figure out how the “salt” works, because my php code sends me a
warning that I am not using a salt, or IV to encrypt the sql query. I bought
Andre Garza’s database software and have modified it
I’m not sure what the original thread was using the salt for but the initial
post in this one was more about hashing. The question about encryption was
introduced so I answered that.
For encryption, it looks like there is only an effective 8 byte salt (the first
8 are static - “Salted__”).
Yes, My description was about hashing.
If your main concern is encrypting …. not something I know. sorry.
Kee
> On Jun 6, 2018, at 7:32 PM, Richard Gaskin via use-livecode
> wrote:
>
> Brian Milby wrote:
> > From the dictionary:
> >
> > The password and salt value are combined and scrambled
Brian Milby wrote:
> From the dictionary:
>
> The password and salt value are combined and scrambled to form the key
> and IV which are used as described above. The key derivation process
> is the same as that used in the openSSL utility. A 16-byte salt prefix
> is prepended to the encrypted
Brian,
This, accidentally, didn’t go to the list. Sorry.
Thanks for your reply. I will look into the OpenSSL utility. But, from what I
can figure, it seems that the decode process extracts the salt from the
encrypted password. And for me, I’m encrypting a MySQL query, so I assume it
will be
From the dictionary:
The password and salt value are combined and scrambled to form the key and IV
which are used as described above. The key derivation process is the same as
that used in the openSSL utility. A 16-byte salt prefix is prepended to the
encrypted data, based on the salt value.
If you need to use the box method, and the control rect isn't perfect, it
might be easier to create the rect on your own. Go through the points and
find the topmost, left most, rightmost, bottom most coordinates and that
gives you your box. Alternatively, if you just want the area and don't
Kee,
So does the decrypt need the salt somehow? Or does it get it from the stuff
that is encrypted with the salt? That is, when I encrypt “with salt my salt”
does the decode function somehow get the salt from the encoded data, because it
has the “key”?
Btw, thanks for responding,
Bill
If a regular polygon has 4 or 8 sides it seems to be inscribed so that all
points touch the square defined by the object’s height and width, which means
that it should be fairly easy to deduce the polygon’s area.
But with 3 sides, the triangle appears slightly smaller than the maximum size
There is a bunch of basic info on the use of a salt on the web. The wikipedia
article is a good start. It depends upon where and how you are using it. Mostly
they discuss using a salt with a hash function. They recommend a long salt.
They recommend storing the salt with the hashed password.
Does anyone have a workaround to completely quit an Android app? I just
re-opened this bug report that claimed to have fixed the problem but it
didn't really: https://quality.livecode.com/show_bug.cgi?id=19420
I can block the backKey message and do nothing, but then the user can't
use the
I’m in LC 9.0.0 and Encryption is discussed, and the code is shown to set a
salt. However, the docs say it’s beyond the scope of the docs to explain how to
choose a salt. For example, how many characters need to be in a salt. Are any
characters permissible? Are all character formats
The encrypt command in the dictionary has that info.
Bob S
> On Jun 6, 2018, at 14:16 , prothero--- via use-livecode
> wrote:
>
> I’ve been having questions about aes 256 encryption lately. I encrypt MySQL
> queries and data ,(in livecode) before sending it to a php script on my
> remote
I’ve been having questions about aes 256 encryption lately. I encrypt MySQL
queries and data ,(in livecode) before sending it to a php script on my remote
server. The php version returns a warning message that I am not using a salt,
which reduces security. Ok, but I can’t find info about how to
yupgood point Richard
On Wed, Jun 6, 2018 at 4:51 PM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:
> Tom Glod wrote:
>
> > what if for example you want to hard code a hash salt into your
> > code?.
>
> Most auth DBs store a salt in plain text, but unique for
Tom Glod wrote:
> what if for example you want to hard code a hash salt into your
> code?.
Most auth DBs store a salt in plain text, but unique for each user.
A single RAM dump doesn't slow attacks; eating up clock cycles does.
--
Richard Gaskin
Fourth World Systems
Software Design and
I do the same thing, but if they can get to your code, they can discern how you
get your salt. I guess that is the upshot of what Mark was saying. If they
cannot get to your code however and read it, then it seems safe enough for me.
My salts are dynamically generated using a method only I
thanks for that reply marktotally hear you on that my
application works fully on 1 local machine..I will have a central
registration server, but it will be optional. So everything is on a local
drive or on a server on a lan. my task is to follow standards and add to
the
On 2018-06-06 18:09, Tom Glod via use-livecode wrote:
what if for example you want to hard code a hash salt into your
code?.
if the code is readable, then so is the salt. I would vote for
unreadable
code 100% of the time.
Technically even if the code isn't readable, then the salt will
Never tried it for Livecode because as in my previous message - Just encode
their name - you dont even have to tell them its encoded
but check on boot up - which I do and wait 6 Months and then tell them -
that will F**Ck them up when they thought they got away with it.
Revenge is a dish best
Oh
and for those who do want to make totally sure ..
https://www.cybrary.it/0p3n/advanced-exe-multi-protection-reverse-engineering-free-tools/
shows you how to modify the UPX compressor so that someone with the source
code (it's open source) will have difficulty.
I don't use it - my copy
after trying UPX on my win32 standalone executable i got a upx: UMP.exe:
NotCompressibleException :)
On Wed, Jun 6, 2018 at 1:00 PM, Tom Glod wrote:
> great suggestion Lagi... thats a great solution for anyone who needs an
> extra layer of obfuscation on the binaries.
>
> Yes indeed...the
great suggestion Lagi... thats a great solution for anyone who needs an
extra layer of obfuscation on the binaries.
Yes indeed...the .livecode files must be made available.
On Wed, Jun 6, 2018 at 12:51 PM, Lagi Pittas via use-livecode <
use-livecode@lists.runrev.com> wrote:
> The code doesn't
The code doesn't need to be available "in the clear" either in Community or
Business in the executable.
So there is nothing stopping us using something like
https://www.pelock.com/products/pelock/buy
or a free one here
https://upx.github.io/
http://www.pazera-software.com/products/free-upx/
You
Can’t do that with community... code must be available.
On Jun 6, 2018, 11:09 AM -0500, Tom Glod via use-livecode
, wrote:
> what if for example you want to hard code a hash salt into your code?.
> if the code is readable, then so is the salt. I would vote for unreadable
> code 100% of the
what if for example you want to hard code a hash salt into your code?.
if the code is readable, then so is the salt. I would vote for unreadable
code 100% of the time.
On Wed, Jun 6, 2018 at 10:38 AM, Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:
> For commercial I
For commercial I would think so, but don’t see any issue on the community side.
On Jun 6, 2018, 9:34 AM -0500, Bob Sneidar via use-livecode
, wrote:
> Don't we want that NOT to be possible?? Otherwise bring back the runtime
> engine and run the app as a stack file of the runtime.
>
> Bob S
>
>
>
Trevor you are brilliant. Now that you put it that way, that is *exactly* what
is happening. The datagrid works so seamlessly it's easy to forget it's not
data I am working with but groups of objects that must be deleted and recreated
as needed.
Bob S
> On Jun 5, 2018, at 21:50 , Trevor
Don't we want that NOT to be possible?? Otherwise bring back the runtime engine
and run the app as a stack file of the runtime.
Bob S
> On Jun 5, 2018, at 19:37 , Brian Milby via use-livecode
> wrote:
>
> Looking at the code, “deflate” is called on the stack as it is being written
> out
!???
Heather Laine
Customer Services Manager
LiveCode Ltd
www.livecode.com
> On 6 Jun 2018, at 14:18, Richmond Mathewson via use-livecode
> wrote:
>
> Please ignore the previous post: something to do with too much . . .
>
> Richmond.
>
> On 6/6/2018 4:16 pm, Richmond Mathewson wrote:
>>
Please ignore the previous post: something to do with too much . . .
Richmond.
On 6/6/2018 4:16 pm, Richmond Mathewson wrote:
saadfs
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and
saadfs
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Enhancement request: https://quality.livecode.com/show_bug.cgi?id=21337
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
Hi Tore,
Sorry, the line:
put "file:" & specialFolderPath("resources")& "/Kommunedata.txt" into tFile
should be:
put url ("file:" & specialFolderPath("resources")& "/Kommunedata.txt") into
tFile
Does it work now?
>although I am certain I should use textDecode when importing text to
Hi Panos.
This does not work, and it is somewhat similar to what I tried initially,
although I am certain I should use textDecode when importing text to LiveCode,
as per the Dictionary. Also note that tFile only holds the url to the file
containing the JSON, and your suggestion only encodes
Hi Tore,
jsonToArray uses the mergJSON external. The mergJSON external expects the
data passed to JSONtoArray() to be utf-8 encoded (this is the case with any
LC external, such revDB etc).
So something like this should work:
global kommuneArray
on preOpenStack
put empty into kommuneArray
I have run into a problem with jsonToArray and the special Norwegian chars æøå.
They do not show up in the keys of the array when the array is made from an
external file. The external file is generated by LiveCode and the arrayToJSON
function. All text are encoded to “UTF-8” before the array is
42 matches
Mail list logo
