Commit 30800a9e authored by Hank Hoffmann's avatar Hank Hoffmann

Lots and lots of merge conflicts

parents 2ed0b9ce c212222a
......@@ -9,9 +9,9 @@ by balancing competing security and latency requirements via \emph{cipher
switching} in space or time. We implement SwitchCrypt on an ARM big.LITTLE
mobile processor and test its performance under the popular F2FS LFS. We provide
empirical results demonstrating the conditions under which different switching
strategies are optimal and explore four related cases. In all cases, we find
that SwitchCrypt achieves at least \TODO{XXX} improvement compared to static
approaches.
strategies are optimal and explore four related cases. We find that SwitchCrypt
achieves at least 3.3x in total energy use reduction and a 1.6x to 4.8x
reduction in I/O latency in our cases when compared to static approaches.
\end{abstract}
......@@ -35,8 +35,6 @@ big.LITTLE mobile processor and test its performance under the popular F2FS LFS.
We provide empirical results that demonstrate the conditions under which
different switching strategies would be optimal. We then study SwitchCrypt's
dynamic flexibility through four case studies where latency, energy, and desired
security properties change dynamically. In all cases, we find that SwitchCrypt
achieves at least \TODO{XXX} improvement compared to static approaches that must
pick only a single operating point. \TODO{We need a much stronger statement
about the results, but let us wait until the overhead data is crunched before
constructing that sentence.}}
security properties change dynamically. We find that SwitchCrypt achieves at
least 3.3x in total energy use reduction and a 1.6x to 4.8x reduction in I/O
latency in our cases when compared to static approaches.}
......@@ -65,14 +65,13 @@ desired security properties, and adhering to changing OS energy budgets.
Hence, any common-case configuration will inevitably sacrifice one concern for
another, even when it is not optimal to the end user. \emph{But what if our
system did not have to sit at some generic configuration point, especially when
another configuration becomes more desirable later on?}
\subsection{Our Contributions}
another configuration becomes more desirable later on?}\\
\\
\textbf{Our Contributions}\\
To realize the goal of flexibly adjusting storage tradeoffs, we first introduce
a scheme to \emph{quantify} the usefulness or relative ``strength'' of ciphers
based on key security properties relevant to FDE. We call these ``security
scores.'' Using these security scores, we then define a tradeoff space of cipher
scores.'' Using these security scores, we define a tradeoff space of cipher
configurations over competing concerns: total energy use, desirable security
properties in the FDE context, read and write performance, total writable space
on the drive, and how quickly the drive can converge to a single configuration.
......@@ -84,9 +83,13 @@ dynamically with acceptable overhead. \TODO{I just realized the order on these
I think the whole paragraph needs a rewrite to reflect the updated
structure of section 3 (and the challenges at the end of section 2).}
\TODO{Overhead summary of empirical paragraph here that expounds a bit on the
final sentence of the abstract. We support up to X security configurations, etc.
And then present some empirical results showing the wide range of security and
energy tradeoffs that become available with various state-of-the-art ciphers as
a result.} We find that SwitchCrypt achieves at least \TODO{XXX} improvement
compared to static approaches that must pick only a single operating point.
We implement SwitchCrypt and three switching strategies---\emph{Forward},
\emph{Selective}, and \emph{Mirrored}---to dynamically change between
the ChaCha and Freestyle
stream ciphers using our novel API. We then study SwitchCrypt's dynamic
flexibility through four case studies where latency, energy, and desired
security properties change dynamically. SwitchCrypt achieves a reduction of at
least 3.3x in total energy use when compared to static approaches; further, we
see a reduction of 3.1x to 4.8x for read latency and 1.6x to 2.8x for write
latency compared to static approaches that must pick a single point in the
latency/energy/security tradeoff space.
......@@ -303,23 +303,22 @@ ciphers can co-exist on the backing store securely, depending on the use case
\subsection{Quantifying Cipher Security Properties} \label{subsec:quantify}
Every cipher mentioned in this paper has been proven formally secure in that
\emph{there are no known efficient attacks against any of them}~\cite{All,
Ciphers, Again}. This implies data is kept confidential versus an adversary with
limited resources, however it is often desirable to secure data at rest in
special contexts or considering future adversaries with abundant resources. In
this way, a cipher that is more resilient to cryptanalysis or brute-force than
is currently required might be more desirable than a cipher with properties that
meet current standards.
Every cipher mentioned in this paper is considered secure in that \emph{there
are no known practical attacks against them}~\cite{All, Ciphers, Again}. This
implies data is kept confidential versus any adversary, however it is often
desirable to secure data at rest in special contexts or considering future
adversaries with abundant resources. In this way, a cipher that is more
resilient to cryptanalysis or brute-force or round count than is currently
required or a cipher that elegantly handles nonce-reuse might be more desirable.
To simplify reasoning about trading off such disparate cryptographic properties
in the FDE context, we must have a way to quantitatively compare a cipher's
``desirability'' or usefulness to SwitchCrypt and to FDE more broadly. Hence, we
do not attempt to define a generally applicable \textit{ranking} of
\emph{security strength}. Instead, we score ciphers (\ie{a so-called ``security
score''}) based on three key security properties that, when summed, give a
relative estimate of the difficulty (or resources required) to attack data
secured under SwitchCrypt FDE (see: \tblref{security-quant}).
``desirability'' for SwitchCrypt and for FDE more broadly. Hence, we do not
attempt to define a generally applicable \textit{ranking} of \emph{security
strength}. Instead, we score ciphers (\ie{a so-called ``security score''}) based
on three key security properties that, when summed, give a relative estimate of
the difficulty (or resources required) to attack data secured under SwitchCrypt
FDE (see: \tblref{security-quant}).
Our scoring scheme is a combination of well understood schemes: scoring ciphers
on their confusion and diffusion of plaintext bits during
......@@ -333,9 +332,15 @@ defender})~\cite{scrypt,Freestyle,others2}.
\textbf{1) Output randomization (OR).} A cipher with output randomization
generates different ciphertexts non-\\deterministically given the same key,
nonce, and message. This makes chosen-ciphertext (CCA) and other attacks where
the ciphertext is in full control of the adversary much more difficult.
%<<<<<<< HEAD
%nonce, and message. This makes chosen-ciphertext (CCA) and other attacks where
%the ciphertext is in full control of the adversary much more difficult.
%\TODO{Can you add a citation here?}
%=======
nonce, and message. This makes chosen-ciphertext (CCA) and other attacks
where the ciphertext is in full control of the adversary much more difficult.
\TODO{Can you add a citation here?}
%>>>>>>> c212222a366c7b905b6d580af590a606317a93c2
This is a binary feature in that a cipher either outputs deterministically given
the same input or it does not. A cipher with non-deterministic output given the
......@@ -351,7 +356,8 @@ resistance to brute force and offline/dictionary attacks has no kind of
slower when given the incorrect key versus the correct key. Similarly, we
consider ciphers with so-called ``enhanced resistance,'' where they are expected
to take longer to finish decrypting ciphertext given an incorrect key versus a
correct key with high probability.
correct key with high probability. This property is also useful in instances
where SwitchCrypt is initialized with a weak password/key.
Scores for this feature range from 0 to 1, where 0 represents no resistance, 0.5
is standard resistance to brute-force and offline/dictionary attacks, and 1 is
......@@ -359,11 +365,11 @@ the aforementioned ``enhanced resistance''.
\textbf{3) Relative round count and key length (RR/RK).} The ciphers we examine
in this research are all constructed around the notion of \emph{rounds}, where a
higher number of rounds typically implies a stronger confidentiality guarantee
given there are no fatal related-key attacks. This feature represents how many
rounds the cipher executes compared to the accepted ``standard'' round count for
that cipher. For instance, ChaCha8 is a reduced round version of the standard
ChaCha20.
higher number of rounds or longer key typically imply a stronger confidentiality
guarantee given there are no fatal related-key attacks. This feature represents
how many rounds the cipher executes compared to the accepted ``standard'' round
count for that cipher. For instance: ChaCha8 is a reduced round version of the
standard ChaCha20, both using 256-bit keys.
Scores for variants are distributed evenly from 0-1. For instance, ChaCha8
scores 0 and ChaCha20 scores 1\@.
......@@ -398,17 +404,24 @@ scores 0 and ChaCha20 scores 1\@.
We revisit the motivating example from \secref{motivation}. Initially, I/O
requests come down from the LFS and are received by the cryptographic driver,
which divides the request by which nuggets it touches. For each nugget, the
per-nugget metadata is consulted to determine the cipher with which the nugget is
%<<<<<<< HEAD
%per-nugget metadata is consulted to determine the cipher with which the nugget is
%encrypted. If it is encrypted with the active cipher, which must be true if we
%have not initiated a cipher switch, the write is handled like prior work:
%encrypted data is read in from the backing storage, the merkle tree and
%=======
per-nugget metadata is consulted to determine with which cipher the nugget is
encrypted. If it is encrypted with the active cipher, which must be true if we
have not initiated a cipher switch, the write is handled like prior work:
encrypted data is read in from the backing storage, the merkle tree and
have not initiated a cipher switch, the write is handled similarly to prior
work: encrypted data is read in from the backing storage, the merkle tree and
%>>>>>>> c212222a366c7b905b6d580af590a606317a93c2
monotonic counter are consulted to ensure the integrity of encrypted data, the
transaction journal is consulted during write operations so that overwrites are
handled and pad-reuse violations are avoided, and then the keycount store is
handled and pad reuse violations are avoided, and then the keycount store is
consulted to derive the nugget's unique encryption key from some master secret.
Using the generic stream cipher API to call out to the active stream cipher
implementation, SwitchCrypt encrypts/decrypts the nugget's
contents~\cite{StrongBox} and commits any updates back to backing storage.
implementation, SwitchCrypt encrypts/decrypts the nugget's contents and commits
any updates back to storage~\cite{StrongBox}.
When the device enters ``battery saver'' mode, the energy monitoring software
downclocks the CPU and indicates to SwitchCrypt that a more energy-efficient
......
......@@ -26,12 +26,12 @@ the active cipher or the inactive cipher. However, there is no technical
limitation preventing various different nuggets encrypted with three, four, or
more unique ciphers.
we use POSIX message queues to indicate intent to switch. A production-ready
We use POSIX message queues to indicate intent to switch. A production-ready
implementation would be greatly simplified by adding an ``intent'' parameter to
the POSIX \textit{read()} and \textit{write()} system calls, allowing
SwitchCrypt to more exactly map individual I/O operations to specific areas of
the backing store when spatially switching. We simulate this with IPC.
\TODO{This intent parameter could also be a security score or something right?
\TO\DO{This intent parameter could also be a security score or something right?
You should spell out exactly what that intent parameter means and maybe change
its name so its use is clearer.} \PUNT{This is especially important when
considering the selective switching strategy; a production-ready implementation
......@@ -52,9 +52,10 @@ three different configurations: a ``fast'' mode with parameters
$R_{max}$=$28$, $H_I$=$2$, $I_C$=$10$)}, and a ``secure'' mode with parameters
\texttt{FreestyleSecure($R_{min}$=$20$, $R_{max}$=$36$, $H_I$=$1$, $I_C$=$12$)}.
Thanks to Freestyle's output randomization, we can skip the overhead of
tracking, detecting, and handling overwrites when nuggets are using it,
offsetting the 1.6x to 3.2x slowdown compared to the ChaCha20~\cite{Freestyle}.
Thanks to Freestyle's output randomization (see \secref{design}), we can skip
the overhead of tracking, detecting, and handling overwrites when nuggets are
using it, offsetting the 1.6x to 3.2x performance loss of using Freestyle versus
ChaCha20~\cite{Freestyle}.
\PUNT{\subsubsection{Implementing Cipher Switching}
......@@ -62,7 +63,7 @@ A naive implementation is trivial (\eg{execute the chosen strategy on every I/O
operation}), this navigation must occur with acceptable overhead by preserving
performance wherever possible. The cryptographic driver provides such a
mechanism, tying together cipher switching strategies and the generic stream
cipher API. \TODO{Which cryptographic driver? You need to clarify if you are
cipher API. \TO\DO{Which cryptographic driver? You need to clarify if you are
talking about a piece of our design or something we are using from prior work.}
In the cases of Mirrored and Selective switching, we use offset to determine in
......@@ -71,7 +72,7 @@ which area of the backing store receives I/O.
In the case of Forward switching, it is tempting to implement it such that a
nugget is completely re-ciphered during I/O every time its metadata indicates
that it was previously encrypted using a non-active cipher. However, such a
naive implementation can have disastrous effects on performance. \TODO{It is not
naive implementation can have disastrous effects on performance. \TO\DO{It is not
clear why that would be disastrous.}
First, a nugget is considered \emph{pristine} if it has not had any data written
......@@ -94,7 +95,7 @@ re-keying operation every time. On the other hand, during hard re-cipher, the
nugget's metadata is changed to match the active cipher configuration \emph{and}
the nugget data is encrypted using the new cipher.
\TODO{Maybe repeat that mirrored relies on someone to implement the fast secure
\TO\DO{Maybe repeat that mirrored relies on someone to implement the fast secure
erase, so that you can read the fast region until it is time to panic and then
you quickly erase? Are there other uses of mirrored?}}
......
......@@ -66,8 +66,8 @@ In this section we answer the following questions:
\figref{tradeoff-no-ratios} shows the security score versus median normalized
latency tradeoff between different stream ciphers when completing our sequential
and random I/O workloads. Trends for median hold when looking at tail latencies
as well. Each line represents one workload. From left to right: 4K, 512K, 5M,
and 40M respectively. Each symbol represents one of our ciphers. From left to
as well. Each line represents one workload. From left to right: 4KB, 512KB, 5MB,
and 40MB respectively. Each symbol represents one of our ciphers. From left to
right: ChaCha8, ChaCha20, Freestyle Fast, Freestyle Balanced, and Freestyle
Secure. As expected, of the ciphers we tested, those with higher security scores
result in higher latency for I/O operations while ciphers with less desirable
......@@ -75,10 +75,10 @@ security properties result in lower latency. The relationship between these
concerns is not simply linear, however, which exposes a rich security vs
latency/energy tradeoff space.
Besides the 4K workload, each workload follows a similar superlinear
latency-vs-security slope and shape, hence we will mostly focus on 40MB and 4K
Besides the 4KB workload, the shape of each workload follows a similar
superlinear latency-vs-security trend, hence we will mostly focus on 40MB and 4KB
workloads going forward. Due to the overhead of metadata management and the fast
completion time of the 4K workloads (\ie{little time for amortization of
completion time of the 4KB workloads (\ie{little time for amortization of
overhead}), ChaCha8 and ChaCha20 take longer to complete than the higher scoring
Freestyle Fast. This advantage is not enough to make Freestyle Balanced or
Secure complete faster than the ChaCha variants, however.
......@@ -86,7 +86,7 @@ Secure complete faster than the ChaCha variants, however.
Though ChaCha8 is generally faster than ChaCha20, there is some variability in
our timing setup when capturing extremely fast events occurring close together
in time. This is why ChaCha8 sometimes appears with higher latency than
ChaCha20 for normalized 4K workloads. ChaCha8 is not slower than ChaCha20.
ChaCha20 for normalized 4KB workloads. ChaCha8 is not slower than ChaCha20.
\subsection{Reaching Between Static Configuration Points}\label{subsec:2}
......@@ -113,14 +113,14 @@ and 3:1 described above}).
The point of this experiment is to determine if SwitchCrypt can effectively
transition the backing store between ciphers without devastating performance.
For the 40M, 5M, and 512K workloads (40M is shown), we see that SwitchCrypt can
achieve dynamic security/energy tradeoffs reaching points not accessible with
prior work, all with minimal overhead.
For the 40MB, 5MB, and 512KB workloads (40MB is shown), we see that SwitchCrypt
can achieve dynamic security/energy tradeoffs reaching points not accessible
with prior work, all with minimal overhead.
Again, due to the overhead of metadata management for non-Freestyle ciphers (see
\secref{implementation}) and the fast completion time of the 4K workloads
\secref{implementation}) and the fast completion time of the 4KB workloads
preventing SwitchCrypt from taking advantage of amortization, ChaCha8 and
ChaCha20 take longer to complete than the higher scoring Freestyle Fast for 4K
ChaCha20 take longer to complete than the higher scoring Freestyle Fast for 4KB
reads. This advantage is not enough to make the ratios involving Freestyle
Balanced or Secure complete faster than the ChaCha ratio variants, however.
......@@ -144,21 +144,21 @@ means these penalties are paid more often, ballooning latency.
and Selective strategies with the same configuration of ratios as
\figref{tradeoff-with-ratios}.
For the 40M, 5M, and 512K workloads (40M is shown), we see that Mirrored and
For the 40MB, 5MB, and 512KB workloads (40MB is shown), we see that Mirrored and
Selective \emph{read} workloads and the Selective \emph{write} workload achieve
parity with the Forward strategy experiments. This makes sense, as the only
overhead for Selective and Mirrored reads is determining which part of the
backing store to commit data to, a trivial process. The same applies to
Selective writes.
For the 4K Mirrored and Selective \emph{read} workloads and the Selective
For the 4KB Mirrored and Selective \emph{read} workloads and the Selective
\emph{write} workload, we see behavior similar to that in
\figref{tradeoff-with-ratios}, as expected.
Mirrored writes across all workloads are very slow. This is to be expected,
since the data is being mirrored across all areas of the backing store. In our
experiments, the backing store can be considered partitioned in half. This
overhead is most egregious for the 4K Mirrored write workload. This makes
overhead is most egregious for the 4KB Mirrored write workload. This makes
Selective preferable to Mirrored; however, Selective can never converge the
backing store to a single cipher configuration or survive the loss of an entire
region (see: \secref{usecases}).
......@@ -167,21 +167,21 @@ region (see: \secref{usecases}).
From the results of the previous three experiments, we calculate that Forward
switching has between \TODO{X} and \TODO{Y} latency overhead compared to
baseline I/O, with average overhead at \TODO{XX} for 40M, 5M and 512K workloads
and average overhead at \TODO{YY} for 4K read workloads and \TODO{YYY} for 4K
write workloads. There is no spatial overhead with the Forward switching
strategy.
baseline I/O, with average overhead at \TODO{XX} for 40MB, 5MB and 512KB
workloads and average overhead at \TODO{YY} for 4KB read workloads and
\TODO{YYY} for 4KB write workloads. There is no spatial overhead with the
Forward switching strategy.
Similarly, we calculate that Selective switching has between \TODO{X} and
\TODO{Y} latency overhead compared to baseline I/O, with average overhead at
\TODO{XX} for 40M, 5M and 512K workloads and average overhead at \TODO{YY} for
4K read workloads and \TODO{YYY} for 4K write workloads. Read overhead. Spatial
overhead was half of all writable space on the backing store.
\TODO{XX} for 40MB, 5MB and 512KB workloads and average overhead at \TODO{YY}
for 4KB read workloads and \TODO{YYY} for 4KB write workloads. Read overhead.
Spatial overhead was half of all writable space on the backing store.
Finally, we calculate that Mirrored switching has between \TODO{X} and \TODO{Y}
read latency overhead and between \TODO{X} and \TODO{Y} write overhead compared
to baseline I/O, with average overhead at \TODO{XX}/\TODO{XXX} for 40M, 5M and
512K read/write workloads and average overhead at \TODO{YY}/\TODO{YYY} for 4K
to baseline I/O, with average overhead at \TODO{XX}/\TODO{XXX} for 40MB, 5MB and
512KB read/write workloads and average overhead at \TODO{YY}/\TODO{YYY} for 4KB
read/write workloads. Spatial overhead was half of all writable space on the
backing store.
......
This diff is collapsed.
\section{Related Work}\label{sec:related}
The standard approach to FDE, using AES-XTS, introduces significant overhead.
Within the last year and a half it has been established that encryption
using \emph{stream ciphers} for FDE is faster than using
AES~\cite{StrongBox, AnotherPaper1, AnotherPaper2}. However, when used naively
in drive encryption, stream ciphers are widely known to be vulnerable to
``overwrite attacks'' like pad reuse and rollback~\cite{KatzLindell, StrongBox}.
To enable FDE using stream ciphers, prior work explores several approaches:
The standard approach to FDE, using AES-XTS, introduces significant overhead.
Recently, it has been established that encryption using \emph{stream ciphers}
for FDE is faster than using AES~\cite{StrongBox, AnotherPaper1, AnotherPaper2}.
However, when used naively in drive encryption, stream ciphers are widely known
to be vulnerable to ``overwrite attacks'' like pad reuse and
rollback~\cite{KatzLindell, StrongBox}. To enable FDE using stream ciphers,
prior work explores several approaches:
\begin{itemize}
\item Use a non-deterministic CTR mode with specially designed cipher and
......@@ -18,25 +18,24 @@ To enable FDE using stream ciphers, prior work explores several approaches:
to prevent overwrites (StrongBox~\cite{StrongBox}).
\end{itemize}
Though the tradeoffs and ideas explored in this paper can apply to any use of
stream ciphers in FDE using some binary additive operation, we focus on the
lattermost prior approach with SwitchCrypt: a stream cipher based FDE and
metadata layer that exploits LFS overwrite-averse behavior to achieve
high-performance encryption.
Unlike StrongBox and other work, which focuses on optimizing performance despite
re-ciphering due to overwrites, SwitchCrypt maintains overwrite protections
while abstracting the idea of re-encrypting nuggets out into cipher switching;
instead of myopically pursuing a performance win, this allows the trade off of
various cipher configurations dynamically.
Unlike prior work, which focuses on optimizing performance despite re-ciphering
due to overwrites, SwitchCrypt maintains overwrite protections while abstracting
the idea of re-encrypting nuggets out into re-ciphering or \emph{cipher
switching}, where a nugget's contents are decrypted using the old key and
inactive cipher configuration and encrypted using a new key and the active
cipher configuration before completing the I/O operation; instead of myopically
pursuing a performance win, this allows users (or the operating system) to trade
off different ciphers and their characteristics dynamically.
However, trading off security for energy, performance, and other concerns is not
a new idea~\cite{ScalableSecurity, WolterReinecke, ZengChow1, ZengChow2,
HaleemEtAl, LiOmiecinski}. For instance, Goodman et al. introduced trading
security for decreased energy dissipated to encrypt a bit back in
1998~\cite{ScalableSecurity}. Similar in intent to VSRs and the Selective
strategy (see \secref{usecases}), Goodman minimizes energy consumption by
separating low-priority data from high-priority and encrypting them differently.
Further, Wolter and Reinecke study performance and security tradeoffs, exploring
approaches to quantifying security~\cite{WolterReinecke}.
\TODO{A paragraph on FDE prior work; include StrongBox, Google Adiantum using a
reduced round version of ChaCha for real life crypto, dm-crypt?, Secure Block
Device; include other ciphers in the same vein as Freestyle}
\TODO{Include papers that trade energy/perf vs securty; Scalable Encryption
paper, energy saving cryptosystems, LastPass whitepaper trading crypto for
reduced latency in PBKDF2, etc.} \TODO{Agreed that this last one is critical. PErhaps cut the prior todo for space.}
In the wild, companies like Google~\cite{AndroidM} and Apple~\cite{iOSFDE} have
explored performance-security tradeoffs in hardware when considering FDE
support. Google's Adiantum uses a less secure reduced round version of
ChaCha~\cite{Adiantum}. LastPass (LogMeIn) has dealt with scaling the number of
iterations of its PBKDF\#2, trading performance for security~\cite{LastPass}.
\section{Conclusion}\label{sec:conclusion}
This paper advocates for a more agile approach to full
drive encryption where the storage system can dynamically
alter the tradeoffs between security and latency (or energy)
for data at rest. To support this vision of agile encryption,
we have proposed an API that allows mulitple stream ciphers, with
different input and output characteristics to be composed in a
generic manner. We have identified three strategies for using
this API to switch ciphers dynamically, but with low overhead.
We have also proposed a scoring method for determining when to
use one cipher over another. Our case studies show how different
strategies can be used to achieve different goals in practice.
We believe that agile encryption will become increasingly important
as successful operation of computer systems increasingly requires
balancing seemingly conflicting operational requirements. We hope
that this work inspires further research into achieving this balance,
including both mechanisms and policies for exposing and navigating
the underlying tradeoff spaces.
%This paper advocates for a more agile approach to full
%drive encryption where the storage system can dynamically
%alter the tradeoffs between security and latency (or energy)
%for data at rest. To support this vision of agile encryption,
%we have proposed an API that allows mulitple stream ciphers, with
%different input and output characteristics to be composed in a
%generic manner. We have identified three strategies for using
%this API to switch ciphers dynamically, but with low overhead.
%We have also proposed a scoring method for determining when to
%use one cipher over another. Our case studies show how different
%strategies can be used to achieve different goals in practice.
%We believe that agile encryption will become increasingly important
%as successful operation of computer systems increasingly requires
%balancing seemingly conflicting operational requirements. We hope
%that this work inspires further research into achieving this balance,
%including both mechanisms and policies for exposing and navigating
%the underlying tradeoff spaces.
\TODO{I really wanted a conclusion in here.
Feel free to edit it in any way you want.}
%<<<<<<< HEAD
%\TODO{I really wanted a conclusion in here.
% Feel free to edit it in any way you want.}
%\TODO{That is all, folks!}
%=======
Stream ciphers are fast and offer strong security properties, but optimizing for
performance often conflicts with other key concerns. In this paper we presented
SwitchCrypt to navigate the security and latency/energy tradeoff space via
\emph{cipher switching} in space and time. We provided empirical results
demonstrating the conditions under which different switching strategies are
optimal and explored four related cases. In all cases, we found that SwitchCrypt
achieves reduced energy usage and I/O latency compared to static approaches.
Perhaps more importantly, though, in all cases SwitchCrypt achieves flexibility that
is simply not possible with prior designs. We hope
that this work inspires further research into balancing competing security,
energy, and performance tradoeffs,
including both mechanisms and policies for exposing and navigating
these tradeoff spaces.
%>>>>>>> c212222a366c7b905b6d580af590a606317a93c2
\PUNT{\TODO{Add David to acknowledgements once we get out of anon reviews.}}
\PUNT{\TO\DO{Add David to acknowledgements once we get out of anon reviews.}}
......@@ -65,7 +65,7 @@
legend style={ column sep=1ex },
legend entries={%
{\scriptsize Mirrored Scores (Without SwitchCrypt)},
{\scriptsize Desired Minimum Score (Exclusive)},
{\scriptsize Desired Minimum Score},
{\scriptsize Actual Minimum Score (SwitchCrypt)}
},
legend style={
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment