0

How to generate a private key with AES 256-CTR ? I need a private key with CTR as CBC is no longer supported by my client. Please advise

Details:

We need to connect to an SFTP instance of client using a .ppk file. This file will contain algo when we generate that using puttygen. Ex:

-----BEGIN RSA PRIVATE KEY----- 
Proc-Type: 4,ENCRYPTED DEK-Info: AES-128-CBC,6C3E08378BC131E1C99A6A70044DC9D0 ------------- 

Now the problem is SFTP instance of client is not using CBC any more. They are asking us to generate a ppk file with AES-128-CTR/AES-256-CTR. Is there any other way where i can generate this ? I have tried using powershell with openssh as well. But, still i am getting key with AES-128-CBC.

migrated from crypto.stackexchange.com Aug 14 at 8:22

This question came from our site for software developers, mathematicians and others interested in cryptography.

  • Using puttygen. But, it is giving a default one as CBC. – Krishna Aug 14 at 7:19
  • We need to connect to an SFTP instance of client using a .ppk file. This file will contain algo when we generate that using puttygen. Ex: -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: AES-128-CBC,6C3E08378BC131E1C99A6A70044DC9D0 ------------- Now the problem is SFTP instance of client is not using CBC any more. They are asking us to generate a ppk file with AES-128-CTR/AES-256-CTR. Is there any other way where i can generate this ? I have tried using powershell with openssh.. But, still i am getting key with AES-128-CBC. – Krishna Aug 14 at 7:25
  • 1
    By 'SFTP instance of client' do you actually mean an SFTP server belonging to someone else and you are failing to connect to that server with a client program? The example you show is OpenSSL-and-OpenSSH format NOT ppk plus ppk ONLY supports aes256-cbc encryption -- but ssh connection is completely unaffected by any local keyfile encryption. Are you sure they don't want you to use aes(N)-ctr from rfc4344 as the data cipher for the connection? That would make a lot more sense, as SSH2's use of cbc has the same 'chaining' vulnerability as SSL3/TLS1.0 did. – dave_thompson_085 Aug 14 at 10:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy