Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crypto.fromHex feature request #2907

Closed
georeb opened this issue Sep 9, 2019 · 2 comments
Closed

crypto.fromHex feature request #2907

georeb opened this issue Sep 9, 2019 · 2 comments

Comments

@georeb
Copy link

georeb commented Sep 9, 2019

Missing feature

crypto.fromHex

The missing counterpart to crypto.toHex

Provides an ASCII char representation of a (hex) Lua string. Each hex byte in the input string is represented as two hex characters.

For example: "48656c6c6f576f726c64"

Justification

The use of encrypt and decrypt is for purposes where the original value is required at a later date. Using toHex is very useful, but when this is later required, the hex data string must be converted back into the original char string.

Workarounds

Currently using this code:

--First encrypt the data

    local output = crypto.toHex(crypto.encrypt("AES-ECB","mykey","data"))

--Then decrypt the data WITHOUT the use of 'crypto.fromHex'

    local input

    for i=1, #output, 2 do
        if not input then
            input=string.char("0x"..string.sub(output,i,i+1))
        else
            input=input..string.char("0x"..string.sub(output,i,i+1))
        end
    end

    return crypto.decrypt("AES-ECB", "mykey", input):match("(.-)%z*$")

--Or decrypt the data WITH the use of 'crypto.fromHex'

    local input = crypto.fromHex(output)

    return crypto.decrypt("AES-ECB", "mykey", input):match("(.-)%z*$")
@nwf
Copy link
Member

nwf commented Sep 28, 2019

I think we should get deprecate then remove crypto.toHex and crypto.toBase64 and redirect to the encoder module (https://nodemcu.readthedocs.io/en/master/modules/encoder/), which provides the inverse functions as well.

nwf added a commit to nwf/nodemcu-firmware that referenced this issue Sep 28, 2019
The internal implementation already preferrentially forwards to the
encoder module, so we should just remove these functions as they confuse
people into thinking that we don't have their inverses (see the feature
request nodemcu#2907).

Update the docs to refer to the encoder version and add deprecation
warnings to the runtime implementations.
nwf added a commit to nwf/nodemcu-firmware that referenced this issue Sep 28, 2019
The internal implementation already preferentially forwards to the
encoder module, so we should just remove these functions as they confuse
people into thinking that we don't have their inverses (see the feature
request nodemcu#2907).

Update the docs to refer to the encoder version and add deprecation
warnings to the runtime implementations.
nwf added a commit that referenced this issue Sep 30, 2019
The internal implementation already preferentially forwards to the
encoder module, so we should just remove these functions as they confuse
people into thinking that we don't have their inverses (see the feature
request #2907).

Update the docs to refer to the encoder version and add deprecation
warnings to the runtime implementations.
@georeb
Copy link
Author

georeb commented Oct 2, 2019

Didn't spot the encoder.fromHex function. Thanks!

@georeb georeb closed this as completed Oct 2, 2019
vsky279 pushed a commit to vsky279/nodemcu-firmware that referenced this issue Dec 27, 2019
The internal implementation already preferentially forwards to the
encoder module, so we should just remove these functions as they confuse
people into thinking that we don't have their inverses (see the feature
request nodemcu#2907).

Update the docs to refer to the encoder version and add deprecation
warnings to the runtime implementations.
marcelstoer pushed a commit that referenced this issue Jun 9, 2020
The internal implementation already preferentially forwards to the
encoder module, so we should just remove these functions as they confuse
people into thinking that we don't have their inverses (see the feature
request #2907).

Update the docs to refer to the encoder version and add deprecation
warnings to the runtime implementations.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants