Re: Signing and encrypting software

Noob wrote:

Noob wrote:

Jonathan Wilson wrote:

Benjamin Kreuter wrote:

Really, whether this makes sense depends on what security properties you
need in your system. If someone forwards a signed, unencrypted copy of
the message to another person, is that a problem? If someone applies
their own signature to an encrypted message, is that a problem? Are you
worried about a malicious receiver publishing a specially crafted public
key, that could be used to substitute an arbitrary plain-text if you use
simple encrypt-then-sign? What you will want to do will depend on what
it is that you are trying to enforce.

Since the device is a satellite TV receiver with keys embedded in the
firmware, there is no risk of malicious keys. It seems here like the goals are:

1. To ensure that the unencrypted software can't be obtained outside
of the device
2. To verify that the software sent to the device (and running on it)
has not been tampered with

Right.

Encryption is required by the CA(*) operator because, IMO, they don't
want people reverse-engineering the security library they provide to
STB manufacturers. I suppose our PHB finds comfort in the fact that
"no one can copy our code".

(*) http://en.wikipedia.org/wiki/Conditional_access

Interestingly, not all CA operators require the firmware to be
encrypted. I suppose some are more confident than others ;-)

I saw a requirement that "the RSA implementation may not use the CRT."
Can someone explain why they would require this?
Does someone know if LTC/LTM uses the CRT in RSASSA-PSS mode?

Anyone?

Going back to my original query, "encrypt then sign" has a minor
performance advantage over "sign then encrypt" in that, if the
software has been tampered with, this will be detected in the
signature verification, and decryption can be skipped; whereas
decryption is always needed if encryption came last.

Let's add compression to the mix.

There are 3 operations to perform
Sign (S), Encrypt (E), Compress (C)

(I know that C must happen before E.)

My preference goes to C,E,S
that is (compress, then encrypt, then sign)
because if the data has been tampered with, that will be detected
at the first step, and decrypt+decompress can be avoided

Thoughts?

Regards.
.

Relevant Pages

  • Re: Portable hard drive through airport security?
    ... encrypt using the built-in MS system. ... How do you make sure you export all the keys? ... For example, if you're traveling between offices, simply transferring ... "With AEFSDR (Advanced EFS Data Recovery), ...
    (rec.travel.air)
  • Re: Java Security
    ... (We can pick a private algorithm but decompiling ... Never give encrypt keys on an application. ... give them by phone or letter, or use a SSL http website with the user login, ...
    (comp.lang.java.help)
  • Re: When does repeated encryption linearly affect time to attack it?
    ... key with n bytes of cipher text in time t, ... hash function with known salts S2 and S3 to create keys K' and K''. ... encrypt it with K', take that result and encrypt with K''. ... Would RC4 repeated 3 times with different ...
    (sci.crypt)
  • Re: Is encrypting twice much more secure?
    ... If you aren't doing one of the layering things, or belt-and-braces, or universal re-encryption, then don't double/multiple encrypt - it's usually not the best way to go. ... the lawyer can give his customers the keys and they can get the ... He wants the encrypted source code to be public. ... What I'd do is use two 256-bit block, 256-bit keyed ciphers chosen to be as dissimilar as possible. ...
    (sci.crypt)
  • Re: Encryption software?
    ... TKLM is IBMs recommended ... key manager and serves up keys to whatever hardware that requests them. ... In our environment our Java EKM serves up keys and utilizes RACF as the ... to request keys from the EKM and encrypt the data accordingly. ...
    (bit.listserv.ibm-main)