Re: Symmetric encryption sample code

"Bertrand LUPART - Linkeo.com" <[email protected]> Wed, 1 May 2019 09:38:05 +0200
Newsgroups gmane.comp.lang.pike.user
Message-ID <[email protected]>

> On 1 May 2019, at 02:27, H. William Welliver III <[email protected]> wrote:
> 
> So, you are seeing that cryptography is hard… it’s not as simple as saying, “decrypt this using AES”. There are a fairly large number of parameters that you’d need to specify and most tools aren’t that flexible. A solution for you might involve providing a decryption program configured using the same parameters that you use to encrypt. 
> 
> It’s hard to know what the problem here is, as the source isn’t available. There are a number of things that can affect whether encryption and decryption will work: how the key is specified (we provide it as a series of n bytes, but a lot of tools assume a key is an ascii string and expand it to the correct number of bytes), etc. 
> 
> I was able to get the encrypted result from [1] to work with the example decryptor I sent. I was /unable/ to get the encrypted output to work with the same tool regardless of whether I used ECB or CBC, with an error of “final block not properly padded”.  I am assuming that the Buffer pads according to either ISO 10126 or the like; it’s unclear what the various online decryptors expect.
> 
> Perhaps there’s something in the Crypto.PGP support that could be a short-cut for you?
> 
> Bill
> 
> [1] https://www.devglan.com/online-tools/aes-encryption-decryption <https://www.devglan.com/online-tools/aes-encryption-decryption>

Hell, yeah. What are the details of the default parameters of Pike's AES? Is that possible to change that?

I'd be more comfortable if i could decipher my own data using a mainstream language. I need to be confident about the data sent before asking the another party to decipher it.

I'll give Java a try for AES first, then PGP could be good alternative path.


Thank you,

-- 
Bertrand LUPART
smime.p7s (application/pkcs7-signature, 3.8 KB) - not displayed