Encrypt the json

[UnveilTech]

Hi Toni,
another suggestion is to encrypt the json sent to the sock/UDP client.

• architecture:
  nDPId -> internet -> client (sock/UDP)

• issue:
  the json is clear text and could be intercepted by anyone
  json part contains important data that can not be visible by all

• solution/proposal:
  encrypt with openssl (ex: cipher method AES-128-CTR) using a special encryption text
  encrypted json must be decrypted by the client (sock/UDP) using C, Go, PHP, etc...

• ndpid.conf:
  passkey="blablabla..." # take care the value should double quoted because spaces could be allowed
  #'passkey' or whatever you think it'll be the best way
  #argument (ex: -P "blablabla...") also in the command line

what do you think ?

bye Fred

[utoni]

That is an idea that I already had in my mind. (See: https://github.com/utoni/nDPId/milestone/3)
I wanted to encrypt the nDPIsrvd connections to it's distributor clients. But doing this within nDPId UDP send is also something I'll consider as it should be more easy to implement as kinda "first crypto support".

[UnveilTech]

excellent !
we'll be happy for testing it as soon as it'll be available...

bye Fred

[UnveilTech]

Toni,
but think that our proposal is a bit different what you mean with the milestone 1.8 or maybe we're wrong here ;o)
the idea is that the nDPId sends encrypted json to another daemon (ex: ncat, socat, personal tool, etc...)

bye Fred

[utoni]

The idea is bit similar so far as it's the same JSON messages which are getting encrypted, but by a different application.

I'll probably start with the nDPId UDP encryption as this might be easier to achieve and may also be reused for other applications such as nDPIsrvd.

[UnveilTech]

you rock man !!!
we would be happy to test it 👍

bye Fred

[UnveilTech]

Hi Toni,
we've tested the OpenSSL part to encrypt the Json:
x.zip

we have tested the process and it works fine... so if you could add that to your source code it'll be cool :o)

bye Fred

[utoni]

Hi Fred,

thanks for your proposal. Is there any reason why you've used aes256-cbc and not an AEAD i.e. aes256-gcm ?

[UnveilTech]

Toni,
that's the source from Mistral (French IA, https://mistral.ai/) that we have modified a bit.
we don't care if CBC or GCM, use the mode you think is the best...
the only point we take care is that it must be Go langage compatible, we do use Go as our receiver daemon (nDPId -> Go daemon)
anyway, CBC or GCM or etc..., I think we should find the way with Go :o)

bye Fred