Hi Scott,
The increase of main CPU computational power will change the picture only
when taken out of the context.
In the reality the storage throughput is growing too. This holds the ratio
pretty much stable. For example the
Introduction of 6G SATA products will require encrypt/decrypt 4.8Gb/s of
data instead of 2.4Gb/s for 3G SATA.
4K sectors will increase the latency of software solutions ~8 times.
SED hardware can be considered as cryptographic co-processor that always
match the throughput of the storage.
Do we need graphic co-processor? Do we need floating point co-processor? It
depends on the definition of "need".
Coming back to the power consumption, the experimental measurement is
complicated. The theoretical part is:
Please pay attention that I intentionally used only generic public
information, for the info on specific products, please contact their
vendors.
SW Cipher performance 30 I/B (true for ECB, CBC
will require as minimum 4 more operations)
Throughput 200000000 B/S
(http://en.wikipedia.org/wiki/Solid-state_drive)
Cipher load 6000 MIPS
CPU, max 14564 MIPS -->
http://en.wikipedia.org/wiki/Instructions_per_second
Cipher overhead 41.1975 %
CPU pwr cons 89 Watt -->
http://en.wikipedia.org/wiki/Athlon_64_X2
Cipher pwr cons 36.6658 Watt
So, on the active read operations 41% of the computational power will be
spent on decryption. This matches my experimental data.
If we will assume that electrical power overhead is proportional to the
computational power overhead, we will have ~37 Watt.
WBR,
Dmitry Obukhov,
Samsung Secure Storage
-----Original Message-----
From: fde-boun...@www.xml-dev.com [mailto:fde-boun...@www.xml-dev.com] On
Behalf Of Scott S
Sent: Monday, June 08, 2009 12:00 PM
To: fde@www.xml-dev.com
Subject: Re: [FDE] how FDE is implemented at system layer
Bryan,
I would agree that with increase processing power of computers, the
performance hit by software encryption diminishes. However, this also does
not fully capture the picture of performance. The setup of the initial
encryption process or the removal of the encryption task few hours to
complete, whereas with self-encrypting hard drive it is instant on and
instant off.
One could argue that these tasks do not occur that often, and if they
happens, they are the background processes and don't impede the user from
using the computer. True, but if one needs to wait for these tasks to be
completed it is a major impact. For example, due to letigations and layoffs,
I have seen repeated request first hand for whole batches of drives to be
encrypted or decrypted for archival or discovery purposes.
Scott
On Thu, 4 Jun 2009, Glancey, Bryan wrote:
>
> Darren ?
>
>
>
> There is extensive scientific data on this, no need to
> speculate. Software FDE does cause some extra battery usage due to
> extra CPU utilization (Bias stated, Mobile Armor makes BOTH software
> FDE and authentication and management modules for encrypting hardware
> drives like Opal SSC).
>
>
>
> I wouldn?t categorize the data as ?significant?,
> unless your use of mathematical exponentials differs from mine. Given
> that we make both drives with embedded authentication and software
> based FDE, we have seen battery time changes in minutes ? not hours as
> your use of SIGNIFICANT would denote.
>
>
>
> Perhaps your calculus is different than mine?
>
>
>
>
>
> Regards;
>
>
>
> Bryan
>
> ------------------------------------
> Mobile Armor
> Bryan E. Glancey
> Senior Vice President & Chief Technology Officer br...@mobilearmor.com
> 400 South Woods Mill Rd.
> Suite 300
> Chesterfield, MO 63017
> http://www.mobilearmor.com/
> ------------------------------------
>
>
>
>
>
> From: fde-boun...@www.xml-dev.com [mailto:fde-boun...@www.xml-dev.com]
> On Behalf Of Darren Lasko
> Sent: Tuesday, April 28, 2009 5:45 PM
> To: fde@www.xml-dev.com
> Subject: Re: [FDE] how FDE is implemented at system layer
>
>
>
>
> Hi Tim,
>
> I'd also like to make a point regarding your statement that, "the
> marginal cost of additional CPU usage is zero unless your CPU meter is
> pegged." This might be true if you are running software-based FDE on
> a desktop system or on a notebook PC that is using wall power.
> However, for notebook PCs that are on BATTERY, additional CPU usage
greatly impacts your on-battery time.
>
> I've experimented with software-based FDE (granted, not BitArmor, but
> I can't imagine the results will be much different), and there is a
> SIGNIFICANT decrease in the amount of time you can stay on battery
> when using software-based FDE compared to using a self-encrypting
> drive. The difference is significant even under light workloads where
> the drive I/O activity is low.
>
> Best regards,
> Darren Lasko
> Principal Engineer
> Advanced Development Group, Storage Products Fujitsu Computer Products
> of America
>
>
> Dmitry Obukhov <d.obuk...@samsung.com> Sent by:
> fde-boun...@www.xml-dev.com
>
> 04/27/2009 02:40 PM
>
> Please respond to
> fde@www.xml-dev.com
>
> To
>
> fde@www.xml-dev.com
>
> cc
>
> Subject
>
> Re: [FDE] how FDE is implemented at system layer
>
>
>
>
>
>
> Hi Tim,
>
> It is not about "archaic". It is about ratio between storage
> throughput and CPU computational power. If you use very fast storage
> (SSD, as I did, or RAID controller), it can make any CPU relatively
"archaic".
>
> "Up to" was received on Dell D630 with SSD (fresh Vista Ultimate) and
> intensive read access. On the same machine you can get lower values of
> CPU load with lower intensity of storage access. Obviously, CPU load
> will be 0 if you don't access the data at all. If your results are
> about 3%, it means that your storage is "archaic" relatively to CPU or
> you do not exercise it on its full speed.
>
> WBR,
>
> Dmitry
>
>
>
>
>
>
> -----Original Message-----
> From: fde-boun...@www.xml-dev.com [mailto:fde-boun...@www.xml-dev.com]
> On Behalf Of Tim Hollebeek
> Sent: Thursday, April 16, 2009 8:19 AM
> To: fde@www.xml-dev.com
> Subject: Re: [FDE] how FDE is implemented at system layer
>
>
> > > It is very CPU-consuming
> > > process. Up to 48% of the CPU power can be spent on encryption.
> >
> > Really?
>
> Maybe on archaic hardware. The numbers we've seen are closer to 3%.
> And of course, the marginal cost of additional CPU usage is zero
> unless your CPU meter is pegged. "Up to" can be very misleading. Up
> to 100% of the information in this email might be wrong. That doesn't
mean it is.
>
> Encryption is not a CPU intensive operation on modern machines.
> I run our FDE product on my machines, and I often forget it's there.
> The overhead is not noticeable.
>
> -Tim
>
>
>
> _______________________________________________
> FDE mailing list
> FDE@www.xml-dev.com
> http://www.xml-dev.com/mailman/listinfo/fde
>
> _______________________________________________
> FDE mailing list
> FDE@www.xml-dev.com
> http://www.xml-dev.com/mailman/listinfo/fde
>
>
>
>
> This message contains information which may be confidential and
privileged.
> Unless you are the addressee (or authorized to receive for the
> addressee), you may not use, copy or disclose to anyone the message or
> any information contained in the message. If you have received the
> message in error, please advise the sender by reply [email], and delete
the message.
>
>
>
_______________________________________________
FDE mailing list
FDE@www.xml-dev.com
http://www.xml-dev.com/mailman/listinfo/fde
