can i encypt in CF and decrypt in JS

Suggestion: read up about encryption and understand it.

never thought answers will be that quick

well sorry to give an unhelpful answer to your immediate question (I get that "RTFM" is not helpful), but you ask a lot of questions here that you could likely answer for yourself, if you just tried. You have been here for ages and kinda asking the same level / quality of questions over and over. They largely show no effort on your part to arrive at the answer yourself. There might be a stack of effort first (although, if we're honest... probably not, right?), but yer not "showing yer working" before asking us to put time into helping you. I have faith in you that if you did some of yer own research into understanding the code you are trying to write (and good on you for pushing the boat out with what yer trying to do), then you'd be able to work stuff out for yourself.

agreed @Adam Cameron eventually i do get fried something due to overwork and stuck on simple issues

Case in point: the answer to this question: "can i encypt in CF and decrypt in JS" Is... "yes" Same quality of answer as the quality of the question, right? 😉

also simone, as you do all this reading on encryption, be sure to read up on hashing. hashing things can at times be preferable to encrypting (such as password), since it's a 1 way street.

Often it's the why that will give us a clearer picture of what you're trying to achieve.

am i on the right track https://trycf.com/gist/34f6f5fa351d64d915d6a71ad8915a00/acf2021?theme=monokai

Does your example do what you expect it to do? If not, where does it fall short?

did you look at your javascript console to look for errors?

i did not checked console, let me check that

Is the CF or JS returning the wrong result?

hmm, let me try that

why is your expected result for the CF encrypt function "39EE0FE0EF686D6619BA8D55D4FC57C2AB35DDE7E692AD051F900906B0E53317"?

please ignore the commnets, i was trying to output as that but i use base64 as my output

the JS decrypt function returns an object; I'm not exactly sure how

toString()

is supposed to work on that, but I certainly don't expect it to return "top secret." What's the idea behind that?

well that is what i read from google and tried implementing it updated gist https://trycf.com/gist/14e58147bb779b9971793b8aa935496c/acf2021?theme=monokai

Do CF and JS encrypt the strings the same?

as far as i know, what google say, yes , until i miss anything using crypto JS library

Google doesn't know the results of your code. Does your code spit out the same thing when you encrypt via CF and JS?

it seems different, might need to consider iv and salt https://trycf.com/gist/270d4b0c7b03c6fb92d0c925ba19b3e3/acf2021?theme=monokai

Do either the CF or JS functions automatically add that? If not, I think that's just making thing more complicated. Keep it simple until you have a better handle on it

as of this time, i am not sure, i am trying to keep it simple by not passing unneeded values

You can use JWT "https://www.forgebox.io/?search=jwt" encrypt at CF end and decrypt at JS end. But this is not 100% secure as when you decrypt from JS side, someone can see and use that decryption key.

This raises a good point. What's the reason for doing the encryption? Is this for server to client browser comms? If so... do you really need to attempt to do something better than HTTPS will already be doing?

yes has to make it secure

yes has to make it secure

You understand what HTTPS is, right? Everything across an HTTPS connection is already encrypted. And far better than anything you would ever achieve in your first attempt at encrypting stuff. What I mean is you are probably wasting your time as anything that needs to be secure needs to be on HTTPS anyhow, and given this is 2022, you are more than likely already using HTTPS for everything anyhow.

Adam's question about what is the reason is spot on. But the response of 'it has to make it secure' could have many meanings, I cannot interpret what you mean by secure in that sense. 1. are you trying to stop people seeing it in transit? that is ssl's job as adam said 2. are you trying to ensure it's untampered, but it's ok if people can see the data? that is jwt job, and you must not forget to validate the jwt 3. are you trying to protect the content, and you don't need to allow anyone to retrieve content? that is hash() job 4. are you trying to protect the content, and you need to be able to retrieve the content? that could be an encrypt/decrypt job as far as your first question, yes, cf and js can encrypt/decrypt each others stuff, however it is regularly a pain to deal with other systems because their key lengths, paddings, algorithms, encodings, iterations, ivs all have to match ours. cf/lucee simplify it and pick stuff for those things, and don't always make it obvious about what/why they picked what. I have yet to see an external system that out of the box matches the cf or lucee defaults.

its point no 4

generate a secret key in cf/lucee for the algorithm you intend, the size of this can be important for the algorithm, but to start with simpler can be sufficient. You may have to return to this step as you work out the encrypting step in cf later. now ignore cf/lucee and go encrypt a string with the js lib using that key then decrypt with the js lib, until you get back to your exact original message (in your gists, I didn't see the js decrypt function to the point of a useful result, if you can't decrypt something created by that libraray using that library, then you should just move to some new lib) once you can do that, then move back to cf/lucee

1. are you trying to protect the content, and you need to be able to retrieve the content? that could be an encrypt/decrypt job

I am still not convinced that that's a thing done half on the server, and half on the client. @Simone it would be way better if you could actually take the time to articulate why you are trying to do this more clearly.

yes i want to do that and if it has been everything on server side, i would never ask a question but because its impending on both client/server, i had to ask because i am not sure

assuming you still need the approach, and are ready to make the move back to cf/lucee, take an encrypt value that you were successful with decrpyting in the step above, and you will try to decrypt the same message using cf/lucee. The reason for this is that you are going to use it to find out what the correct algorithm and encodings are. you are most likely going to have to modify your stuff to use an algorithm similar to AES/CBC/PKCS7Padding or AES/CBC/PKCS5Padding (*just my guess based off that sparse old library doc page) to match the definition the javascript library is using, AES alone almost never works well when sharing with something outside of cf/lucee. Once you figure out the correct algorithms/encoding, then apply those and the previous key into the encrypt method, and start passing that to js. (this is where you will likely discover that you need a different secret key length to work correctly, in which case you create the new key and start over) If you can use hex instead of base64, it can prevent some character/char encoding issues, which will make it easier to pass around and less error prone. page that includes some pretty common java algorithms https://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#impl sometimes you also need to install bouncy castle keep in mind that most of the modern encryption algorithms are correctly going to give a different result each time you encrypt, so you cannot compare an encrypt result from one system to another just by looking at it the hardest parts are always figuring out how to match what cf/lucee hid from you as far as implementation details to what those other libraries are doing.

Yeah, you raise a good point. Why would one use a javascript lib for encrypting/decrypting, seeing as how you need to expose the key, rendering the security useless. What's the use case for those libs?

@ageax the most reasonable use case for them are in things like node on the server. But, there are others I'm sure.

@Matt Jones - Ah, true. I haven't used Node much, so I forget about the server side uses, lol

@Simone (and everyone else). Just stop. What are you trying to achieve? Don't talk about code, talk about feature. What feature are you trying to implement. I still fee that your lack of clarity as to what you're actually trying to achieve is wasting a lot of people's time here.

my use case ius simple, if node is doing it, why can;t JS do it as i am using javascript and i have to hide the content from user prespective

i have to hide the content from user prespective

This is not a feature, it's implementation detail. And it's not even a very precise implementation detail because you don't say why. What feature are you trying to implement? And when you answer, and before pressing "send" read what you have typed and ask yourself "is this coherent, and does it answer the question in a helpful way?"