[swugenerator][PATCH] Add support for PSS padding when signing with RSA

[Philippe Reynes]

From: Paul HENRYS <paul.he...@softathome.com>

SWUpdate supports both PKCS#1 and PSS padding with RSA but swugenerator only
implements PKCS#1 padding. PSS padding support is therefore added in SWUSignRSA.
One can use the keyword RSAPSS to sign the sw-description file with RSA and PSS
padding. For instance:
"-k RSAPSS,myprivatekey.pem"

Signed-off-by: Paul HENRYS <paul.he...@softathome.com>
Signed-off-by: Philippe Reynes <philipp...@softathome.com>
---
swugenerator/main.py | 18 +++++++++++++-----
swugenerator/swu_sign.py | 19 ++++++++++++++++++-
2 files changed, 31 insertions(+), 6 deletions(-)

diff --git a/swugenerator/main.py b/swugenerator/main.py
index b5ede6b..c543313 100644
--- a/swugenerator/main.py
+++ b/swugenerator/main.py
@@ -94,6 +94,8 @@ def parse_signing_option(
CMS,<private key>,<certificate used to sign>
RSA,<private key>,<file with password>
RSA,<private key>
+ RSAPSS,<private key>,<file with password>
+ RSAPSS,<private key>
PKCS11,<pin>[,<module>,<slot>,<id>]
CUSTOM,<custom command>

@@ -124,16 +126,22 @@ def parse_signing_option(
# Format : CMS,<private key>,<certificate used to sign>
else:
return SWUSignCMS(sign_parms[1], sign_parms[2], None, None, engine, keyform)
- if cmd == "RSA":
+ if cmd[:3] == "RSA":
if len(sign_parms) not in (2, 3) or not all(sign_parms):
raise InvalidSigningOption(
"RSA requires private key and an optional password file"
)
- # Format : RSA,<private key>,<file with password>
+ if cmd == "RSA":
+ mode = SWUSignRSA.RSAMode.PKCS1
+ elif cmd == "RSAPSS":
+ mode = SWUSignRSA.RSAMode.PSS
+ else:
+ raise InvalidSigningOption(f"Unknown RSA mode: {cmd}")
+ # Format : RSA(PSS),<private key>,<file with password>
if len(sign_parms) == 3:
- return SWUSignRSA(sign_parms[1], sign_parms[2])
- # Format : RSA,<private key>
- return SWUSignRSA(sign_parms[1], None)
+ return SWUSignRSA(sign_parms[1], sign_parms[2], mode=mode)
+ # Format : RSA(PSS),<private key>
+ return SWUSignRSA(sign_parms[1], None, mode=mode)
if cmd == "PKCS11":
# Format : PKCS11,<pin>[,<module>,<slot>,<id>]
if len(sign_parms) not in range(2, 6) or not all(sign_parms[0:2]):
diff --git a/swugenerator/swu_sign.py b/swugenerator/swu_sign.py
index 53b6727..1eeeff5 100644
--- a/swugenerator/swu_sign.py
+++ b/swugenerator/swu_sign.py
@@ -6,6 +6,8 @@ import logging
import subprocess
import sys

+from enum import Enum
+

class SWUSign:
def __init__(self):
@@ -85,16 +87,31 @@ class SWUSignCMS(SWUSign):


class SWUSignRSA(SWUSign):
- def __init__(self, key, passin):
+ class RSAMode(Enum):
+ PKCS1 = "pkcs1"
+ PSS = "pss"
+
+ def __init__(self, key, passin, mode=RSAMode.PKCS1):
super().__init__()
self.type = "RSA"
self.key = key
self.passin = passin
+ self.mode = mode
+
+ def _get_rsa_mode_args(self):
+ if self.mode == self.RSAMode.PSS:
+ return ["-sigopt", "rsa_padding_mode:pss",
+ "-sigopt", "rsa_pss_saltlen:-2"]
+ elif self.mode == self.RSAMode.PKCS1:
+ return []
+ else:
+ raise ValueError(f"Unknown or unsupported RSA mode: {self.mode}")

def prepare_cmd(self, sw_desc_in, sw_desc_sig):
self.signcmd = (
["openssl", "dgst", "-sha256", "-sign", self.key]
+ self.get_passwd_file_args()
+ + self._get_rsa_mode_args()
+ ["-out", sw_desc_sig, sw_desc_in]
)

--
2.43.0

[Philippe Reynes]

swugenerator may add sha256 to image, it may be interesting
to also add the size of the image. For exemple, with sha256
and size, swupdate may avoid to flash the same binary.

Signed-off-by: Philippe Reynes <philipp...@softathome.com>
---

swugenerator/generator.py | 6 +++++-
swugenerator/main.py | 8 ++++++++
2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/swugenerator/generator.py b/swugenerator/generator.py
index 6578f75..3015c5b 100644
--- a/swugenerator/generator.py
+++ b/swugenerator/generator.py
@@ -31,7 +31,8 @@ class SWUGenerator:
no_compress=False,
no_encrypt=False,
no_ivt=False,
- no_hash=False
+ no_hash=False,
+ no_size=False
):
self.swdescription = template
self.artifacts = []
@@ -51,6 +52,7 @@ class SWUGenerator:
self.noencrypt = no_encrypt
self.noivt = no_ivt
self.nohash = no_hash
+ self.nosize = no_size

@staticmethod
def generate_iv():
@@ -197,6 +199,8 @@ class SWUGenerator:
entry["filename"] = new.newfilename
if not self.nohash:
entry["sha256"] = new.getsha256()
+ if not self.nosize:
+ entry["size"] = new.getsize()
if "encrypted" in entry and entry["encrypted"] is True:
entry["ivt"] = new.ivt
if entry.get("compressed") and not self.nocompress:
diff --git a/swugenerator/main.py b/swugenerator/main.py
index c543313..a1c6015 100644
--- a/swugenerator/main.py
+++ b/swugenerator/main.py
@@ -209,6 +209,7 @@ def create_swu(args: argparse.Namespace) -> None:
args.no_encrypt,
args.no_ivt,
args.no_hash,
+ args.no_size
)
swu.process()
swu.close()
@@ -271,6 +272,13 @@ def parse_args(args: List[str]) -> None:
help="Do not store sha256 hash in sw-description",
)

+ parser.add_argument(
+ "-z",
+ "--no-size",
+ action="store_true",
+ help="Do not store file size in sw-description",
+ )
+
parser.add_argument(
"-k",
"--sign",
--
2.43.0

[Stefano Babic]

Hi Philippe,

On 6/10/26 11:11, Philippe Reynes wrote:
> swugenerator may add sha256 to image, it may be interesting
> to also add the size of the image. For exemple, with sha256
> and size, swupdate may avoid to flash the same binary.
>

Not convinced about this because it is already supported and SWUpdate
has a versioning way to detect if an artifact should be skipped.

Size can be simply added to own sw-description with :

size = "$swupdate_get_size(@@VAR@@)

and swugenerator will added the requested size.

Apart of this, SWUpdate will install an artifact based on version, and
yes, version can be also a hash, that is the following is fully allowed:

version = "$swupdate_get_sha256(....)";

So yes, we can unconditionally even add the "size" attribute, butis this
not a duplication of a feature that currently exists ?

Best regards,
Stefano Babic

_______________________________________________________________________
Nabla Software Engineering GmbH
Hirschstr. 111A | 86156 Augsburg | Tel: +49 821 45592596
Geschäftsführer : Stefano Babic | HRB 40522 Augsburg
E-Mail: sba...@nabladev.com

[Philippe Reynes]

Hi Stefano,


Le 10/06/2026 à 12:34, Stefano Babic a écrit :
> [Vous ne recevez pas souvent de courriers de
> stefan...@swupdate.org. Découvrez pourquoi ceci est important à
> https://aka.ms/LearnAboutSenderIdentification ]
>
> This Mail comes from Outside of SoftAtHome: Do not answer, click links
> or open attachments unless you recognize the sender and know the
> content is safe.

>
> Hi Philippe,
>
> On 6/10/26 11:11, Philippe Reynes wrote:
>> swugenerator may add sha256 to image, it may be interesting
>> to also add the size of the image. For exemple, with sha256
>> and size, swupdate may avoid to flash the same binary.
>>
>
> Not convinced about this because it is already supported and SWUpdate
> has a versioning way to detect if an artifact should be skipped.
>
> Size can be simply added to own sw-description with :
>
>        size = "$swupdate_get_size(@@VAR@@)
>
> and swugenerator will added the requested size.
>

Oh, thanks, I wasn't aware that we could do that with swugenerator.

> Apart of this, SWUpdate will install an artifact based on version, and
> yes, version can be also a hash, that is the following is fully allowed:
>
>        version = "$swupdate_get_sha256(....)";
>

On our board, we may have binaries provided by partners without any easy
way to gather a version. So to avoid flashing the same binary, we want
to compare hashes and if both had the same hash, swupdate just skips
this binary. The hash may be used as version, but my concern is how to
compute this hash before swupdate starts. It is not possible to compute
the hash of a binary in a partition without the size, and we don't have
this size in the rootfs. But swupdate knows the partition and the size,
so it could easily compute the hash and compare it with the hash in
sw-description.

So I think that a property "install-if-hash-different"  may be useful in
this case.

> So yes, we can unconditionally even add the "size" attribute, butis this
> not a duplication of a feature that currently exists ?
>

As the size is needed on some case but not all the time, I think that
the option should be "add the image size" and not "do not add the image
size". So we add the image size only when requested.

The question become are you agree  to have an option that add the size
on all images or do you prefer to use "$swupdate_get_size(filename)" on
all image that need it ?


> Best regards,
> Stefano Babic
>
Best regards,

Philippe

> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/swupdate/0dbf9b5c-5857-4d37-afd9-476116f7357e%40swupdate.org.

[Stefano Babic]

Hi Philippe,

Yes, but you do not need the size of the artifact in the SWU (what you
add here), you need the size (maybe different) of the artifact when it
was installed because this is what you need to compare.

That means if you want such kind of versioning, you need to save the
size (first option) or to add a marker / magic (second option) to the
partition, so that you can detect the size at run time.

I did the same in some cases, for example for the bootloader and I do
not want to replace if not strictly required.

>
> So I think that a property "install-if-hash-different"  may be useful in
> this case.

But we have installed-if-different. If it is different due to hash, or
to version number, or whatever else, it does not matter.

You need a way before starting SWUpdate to version the artifacts that
are already installed and to populate the sw-versions file, read by
SWUpdate to check if an artifact must be installed.

>
>
>> So yes, we can unconditionally even add the "size" attribute, butis this
>> not a duplication of a feature that currently exists ?
>>
> As the size is needed on some case but not all the time, I think that
> the option should be "add the image size" and not "do not add the image
> size". So we add the image size only when requested.

Yes, but this cannot be per artifact, it will be added unconditionally
to all artifacts. And I think this doesn't help again, you need the size
of the installed to compute the hash, not of the new artifacts. For
them, you have already hash that can be used as version without
computing another time.

>
> The question become are you agree  to have an option that add the size
> on all images or do you prefer to use "$swupdate_get_size(filename)" on
> all image that need it ?

I think the current behavior is already fine and generic. The generator
just calls a function if an attribute starts with "$" (as in Yocto
world), and the mechanism is generic: we can attach any function we want.

Best regards,
Stefano

[Philippe Reynes]

Hi Stefano,

I agree that we could use the checksum as version and the property
install-if-different should work fine.

But, I also think that it more difficult to use on real projects.
All artifacts may not have a static size, so different version of an
artifact may
have different size. We could save the size of all artifact on the rootfs,
but I would prefer to avoid any dependencies between rootfs and all
artifacts.
So I won't consider the first option.

For the second option (adding a marker/trailer at the end of all
artifact), it seems
more interesting, but I see several issues. As we don't always decide
the layout
of the flash, a partition storing an artifact may be the exact size of
the artifact
or bigger than the artifact. If the partition has the same size as the
artifact, then
the marker/trailer should not be added to the artifact. If the partition
is bigger than
the artifact, the marker/trailer should be added to the artifact. So it
adds is a dependency
on the layout to know if the marker/trailer should be added or not to
the artifact,
which (I think ) is not very nice.

And the case where the partition is bigger than the artifact but the
space left is not enough
to store the marker/trailer may become a nightmare.

I also see another issue if the update of an artifact should not happen
on a project. So
this artifact don't have a marker/trailer. But ........ six month later
a project manager decides
to update this artifact. As the artifact don't have a marker/trailer,
the script that compute the
version for swupdate don't handle this artifact. So it is not possible
to use the
property install-if-different. Yes, it should not happen, but it happens.

In summary, compute the hash with a script in the rootfs to provide it
to swupdate leads to several issue:
- dependency between image/binary generation and flash layout
- artifact update must be anticipated
- size issue with not enough space on the partition to add the
marker/trailer.

Most of those issue may be managed (not the last one), but it adds more
work.
On the other size, a property "install-if-sha256-different" manage all
those case
very easily.

In conclusion, I think that a new property "install-if-sha256-different"
is a
nice to have.

Would you accept it if I send a patch please ?

>>
>> So I think that a property "install-if-hash-different"  may be useful in
>> this case.
>
> But we have installed-if-different. If it is different due to hash, or
> to version number, or whatever else, it does not matter.
>
> You need a way before starting SWUpdate to version the artifacts that
> are already installed and to populate the sw-versions file, read by
> SWUpdate to check if an artifact must be installed.
>
>>
>>
>>> So yes, we can unconditionally even add the "size" attribute, butis
>>> this
>>> not a duplication of a feature that currently exists ?
>>>
>> As the size is needed on some case but not all the time, I think that
>> the option should be "add the image size" and not "do not add the image
>> size". So we add the image size only when requested.
>
> Yes, but this cannot be per artifact, it will be added unconditionally
> to all artifacts. And I think this doesn't help again, you need the size
> of the installed to compute the hash, not of the new artifacts. For
> them, you have already hash that can be used as version without
> computing another time.
>
>>
>> The question become are you agree  to have an option that add the size
>> on all images or do you prefer to use "$swupdate_get_size(filename)" on
>> all image that need it ?
>
> I think the current behavior is already fine and generic. The generator
> just calls a function if an attribute starts with "$" (as in Yocto
> world), and the mechanism is generic: we can attach any function we want.

I agree, adding the size automatically for all images is not so useful.
We can
use "$swupdate_get_size(filename)" when needed.

>
> Best regards,
> Stefano


Best regards,

Philippe

> https://groups.google.com/d/msgid/swupdate/f01f78a6-0af3-4962-bc20-43465ac6741e%40swupdate.org.