Bug 1591166

Use the following template to for the 'fedpkg update' request to submit an
update for this issue as it contains the top-level parent bug(s) as well as
this tracking bug.  This will ensure that all associated bugs get updated
when new packages are pushed to stable.

=====

# bugfix, security, enhancement, newpackage (required)
type=security

# testing, stable
request=testing

# Bug numbers: 1234,9876
bugs=1591163,1591166

# Description of your update
notes=Security fix for [PUT CVEs HERE]

# Enable request automation based on the stable/unstable karma thresholds
autokarma=True
stable_karma=3
unstable_karma=-3

# Automatically close bugs when this marked as stable
close_bugs=True

# Suggest that users restart after update
suggest_reboot=False

======

Additionally, you may opt to use the bodhi web interface to submit updates:

https://bodhi.fedoraproject.org/updates/new

In his original Technical Advisory Keegan Ryan states that
"Side-channel attacks are explicitly excluded from Cryptlib's threat model."

However, I contacted the creator of CryptLib, Peter Gutmann, for a
statement about the impact of Keegan's findings. With his permission
I'll post Peter's reply to me here as a comment. And close the bug.

Here is Peter's reply :

The cryptlib manual's comment on this is:

-- Snip --

Cloud computing is fundamentally incompatible with secure crypto operations.
If you’re running your crypto on someone else’s computer then you have no way
of telling what they’re doing with your crypto or your keys.  By extension if
you’re running your crypto on a platform that’s shared with hostile processes
that can access information like CPU statistics and cache information then you
can’t guarantee the safety of your crypto keys.  Although cryptlib employs
countermeasures to try and reduce the threat, it’s not possible to guarantee
the safety of your crypto or keys when they’re exposed on someone else’s
hardware or to someone else’s software (the same applies to anyone else’s
crypto in such an environment, at best you can try and obscure or hide your
crypto operations and keys and hope that no-one figures out how to get at
them).  In other words if you’re running your crypto in a cloud or shared
computing environment then your security guarantees are void.

Similarly, if you allow someone to probe the system that you’re running
cryptlib on with measuring equipment that can analyse internal electrical or
similar signals then your security guarantees are void.  As with the
cloud/shared computing problem, this issue isn’t specific to cryptlib but
affects all crypto implementations, no matter what their salespeople may tell
you.

The solution to these issues is simple, don’t run your sensitive crypto
operations on systems controlled by others or that allow hostile code to run
alongside, and attack, your crypto code, and don’t allow them to probe your
systems with measuring equipment to capture its internal operations.

-- Snip --

Or, as I told someone earlier today, this isn't a WONTFIX, this is a CANTFIX.
If the attacker can run their code on the same CPU as you with access to
hardware-level diagnostic capabilities, you're hosed.  There's nothing you can
do to defend against that, so the solution is "don't do that, then", not try
and patch up every new vuln as it's published while thinking you're immune.
This is a problem that cannot be fixed or patched, and we're realistic about
it and tell the users that.

(OK, that's not quite true, if you can write code that never ever exhibits any
data-dependent behaviour, no branches, all operations take the same time, etc,
then you're OK).

If you're really worried about it, cryptlib's ECDSA is disabled by default and
I don't know if anyone ever uses DSA, so at least it's mitigated that way, but
the only actual solution is "don't do that, then", because if you do there'll
always be further side channels there to get you no matter how many of them
you try and patch up.

Peter.