Re: [mbed-tls] SSH client sample (Gilles Peskine) - mbed-tls

23 Jul 2020


      Hi Gilles,
I checked one you recommended and looks like it is very complicated.
Do you have any sample project(SSH client) based on MbedTLS+LWIP?
Thanks,
Christie
-----Original Message-----
From: mbed-tls mbed-tls-bounces@lists.trustedfirmware.org On Behalf Of mbed-tls-request@lists.trustedfirmware.org
Sent: July-22-20 11:35 AM
To: mbed-tls@lists.trustedfirmware.org
Subject: mbed-tls Digest, Vol 5, Issue 15
Send mbed-tls mailing list submissions to
    mbed-tls@lists.trustedfirmware.org
To subscribe or unsubscribe via the World Wide Web, visit
    https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
or, via email, send a message with subject or body 'help' to
    mbed-tls-request@lists.trustedfirmware.org
You can reach the person managing the list at
    mbed-tls-owner@lists.trustedfirmware.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of mbed-tls digest..."
Today's Topics:
1. Problem with decrypt aes 128 in ecb mode. HELP ME!
      (dany_banik2000@yahoo.com)
   2. Re: SSH client sample (Gilles Peskine)
   3. Re: patches for low memory (Gilles Peskine)
----------------------------------------------------------------------
Message: 1
Date: Wed, 22 Jul 2020 14:42:33 +0000 (UTC)
From: "dany_banik2000@yahoo.com" dany_banik2000@yahoo.com
To: mbed-tls@lists.trustedfirmware.org
Subject: [mbed-tls] Problem with decrypt aes 128 in ecb mode. HELP ME!
Message-ID: 1371131400.5486983.1595428953399@mail.yahoo.com
Content-Type: text/plain; charset="utf-8"
I developed a server application that obtains the data from a dht11 sensor, I encrypt it with aes 128 and publish it on the server. The client application makes a request to the server, and I would like to decrypt the answer.
When I want to display decrypted message, it shows garbage
The message retrieved from the server is in hex. I think that must to convert hex in binary, but i don’t know how can do it…
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.trustedfirmware.org/pipermail/mbed-tls/attachments/20200722/a5ad530f/attachment-0001.htm
------------------------------
Message: 2
Date: Wed, 22 Jul 2020 17:10:18 +0200
From: Gilles Peskine gilles.peskine@arm.com
To: mbed-tls@lists.trustedfirmware.org
Subject: Re: [mbed-tls] SSH client sample
Message-ID: 4a7265ac-7b3e-33ef-7222-4cd29c3cda08@arm.com
Content-Type: text/plain; charset=windows-1252
Hi Christie,
Libssh2 (https://github.com/libssh2/libssh2) supports Mbed TLS.
I've never used it or investigated it, so I can't vouch for it, I just know that it's there.
--
Gilles Peskine
Mbed TLS developer
On 21/07/2020 18:40, Christie Su via mbed-tls wrote:
...
Hi,
ï¿½
I am using FRDM-K64F with LWIP+mbedTLS for our control system. Now, I 
want to develop the SSH client(or telnet 22) to access my SSH server.
ï¿½
Could you give me some indications how to do it? Or do you have any 
sample project?
ï¿½
Thanks,
ï¿½
Christie
------------------------------
Message: 3
Date: Wed, 22 Jul 2020 17:34:44 +0200
From: Gilles Peskine gilles.peskine@arm.com
To: mbed-tls@lists.trustedfirmware.org
Subject: Re: [mbed-tls] patches for low memory
Message-ID: 152f6571-6972-8262-c38d-d200dcc7c0b7@arm.com
Content-Type: text/plain; charset=utf-8
Hi Nick,
A TLS stack in 6kB of RAM sounds impressive, congratulations!
We'd certainly be interested in all the improvements you can contribute.
The process is documented in CONTRIBUTING.md (https://github.com/ARMmbed/mbedtls/blob/development/CONTRIBUTING.md). I just need to warn you that the limiting factor is reviewers' time. For a significant contribution, it may take a while before the Mbed TLS team can look at it in detail. Small patches are usually easier than large
ones: if something only takes half an hour to review, someone will probably do it when they're stuck on some other task. If a review takes several days, it needs to be scheduled.
It would probably be better to discuss the general nature of the changes on this mailing list first. Is a new compilation option needed? Is an API change needed? What is the risk that the change might break existing code? How is the new code tested? etc.
Which version of Mbed TLS have you been using? We've made a few changes that are of interest to low-memory platforms recently, such as the option MBEDTLS_SSL_VARIABLE_BUFFER_LENGTH to resize SSL buffers after the handshake (new in 2.22).
I don't know what the issue with the incoming SSL packet header length could be. If you could give precise steps to reproduce the issue, this would be very helpful. Eventually we'd want to construct a test in tests/ssl-opt.sh for this.
--
Gilles Peskine
Mbed TLS developer
On 17/07/2020 21:00, Nick Setzer via mbed-tls wrote:
...
Hi, I have been working with Mbed TLS for the last 6 months in an 
extremely low memory use case. This library has been an absolute joy 
to work with because of how flexible it is. I have an interesting use 
case with how little RAM I have to work with (around 6kb on one
microprocessor) and I have made some changes that I thought would be 
of interest. I'm not sure if I should submit them as a single 
changeset or a set of changes. I'll describe the changes and if there 
is interest I can clean them up for submission.
The first change that I made was for a scenario with two 
microprocessors communicating over a UART. I was already using TLS 
offloading so that the private key was on one processor (with only 6kb 
of RAM free) and the SSL context stored on the other. I required 
generating a CSR and thus made some changes to the CSR code to be able 
to generate the CSR using a similar private key offloading strategy.
I found an issue with downloading firmware for OTA from openssl web 
servers. This is a little tricky to describe. The server was not 
responsive to requests for reducing the max fragment length, which 
forced me to use MBEDTLS_SSL_MAX_CONTENT_LEN set to 16384. But I 
needed to have multiple ssl sessions open for other activities and did 
not have enough RAM to hold multiple large buffers. I have made a set 
of changes to allow setting the content length when the ssl context is 
initialized, as well as setting different IN and OUT content lengths 
to save memory. This change allowed me to set up one session with 16kb 
for the IN content length, and then 4kb for OUT content length, while 
a second session could use 2kb for a total of 24kb  instead of 64kb.
Related to the openssl issue, I found that the incoming ssl packet 
header length can sometimes be 8 or 16 bytes larger than expected 
depending on which AES method is selected. I'm not actually sure what 
the best way to solve this is. One way may be to change 
MBEDTLS_SSL_HEADER_LEN from 13 to 29 bytes. However I ended up solving 
it by adding 16 to both MBEDTLS_SSL_IN_BUFFER_LEN and 
MBEDTLS_SSL_OUT_BUFFER_LEN. This way I could handle the larger ssl 
header as well as receive the content body.
If these three changes sound interesting I can start work on cleaning 
up the code to be less specific to my company and then submit the 
changes. Also I would like to know if there is any process I should be 
following when submitting these changes.
Thanks,
Nick Setzer
SimpliSafe, Inc.
294 Washington Street, 9th Floor
Boston, MA 02108
------------------------------
Subject: Digest Footer
mbed-tls mailing list
mbed-tls@lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
------------------------------
End of mbed-tls Digest, Vol 5, Issue 15
***************************************