On 5 Dec 2006, at 3:22 PM, Brian Gladman wrote:
For AES the round function and key scheduling cost per round are
basically the same for both AES-128 and AES-256. In consequence I
would
expect the speed ratio to be close to the ratio of the number of
rounds,
which is 14 / 10 or 40%.
My o
Jon Callas wrote:
> I just ran a speed test on my laptop. Here are some relevant excerpts:
>
> CipherKey Size Block Size Enc KB/sec Dec KB/sec
> -- -- --
> IDEA 128 bits 8 bytes 24032.0924030.66
> 3DES 192 bits 8 bytes
I just ran a speed test on my laptop. Here are some relevant excerpts:
CipherKey Size Block Size Enc KB/sec Dec KB/sec
-- -- --
IDEA 128 bits 8 bytes 24032.0924030.66
3DES 192 bits 8 bytes 10387.6710399.30
CAST5
Leichter, Jerry wrote:
| Jon Callas wrote:
| >
| >
| > Moreover, AES-256 is 20-ish percent slower than AES-128.
| Compared to AES-128, AES-256 is 140% of the rounds to encrypt 200% as much
| data.
AES-256 has a 256-bit key but exactly the same 128-bit block as AES-128
(and AES-192, for that m
David Johnston wrote:
> Jon Callas wrote:
>>
>>
>> Moreover, AES-256 is 20-ish percent slower than AES-128.
> Compared to AES-128, AES-256 is 140% of the rounds to encrypt 200% as
> much data. So when implemented in hardware, AES-256 is substantially
> faster.
AES-256 does not encrypt any more da
On Sun, 3 Dec 2006, David Johnston wrote:
> > Moreover, AES-256 is 20-ish percent slower than AES-128.
> Compared to AES-128, AES-256 is 140% of the rounds to encrypt 200% as
> much data. So when implemented in hardware, AES-256 is substantially faster.
AES-256 means AES with 128-bit block and 256
Compared to AES-128, AES-256 is 140% of the rounds to encrypt 200% as much
data. So when implemented in hardware, AES-256 is substantially faster.
Excuse me, AES-256 has the same block size as AES-128, that is 128 bits.
It's in fact slower, not faster, and in hardware it also occupies a
substa
Jon Callas wrote:
Moreover, AES-256 is 20-ish percent slower than AES-128.
Compared to AES-128, AES-256 is 140% of the rounds to encrypt 200% as
much data. So when implemented in hardware, AES-256 is substantially faster.
AES-256 - 18.26 bits per round
AES-128 - 12.8 bits per round
I imagi
On Mon, 6 Nov 2006, Derek Atkins wrote:
>Quoting "Leichter, Jerry" <[EMAIL PROTECTED]>:
>> Just wondering about this little piece. How did we get to 256-bit
>> AES as a requirement? Just what threat out there justifies it?
> It's a management requirement. The manager sees "AES128" and "AES2
On Wed, 8 Nov 2006, Travis H. wrote:
> On Wed, Nov 08, 2006 at 05:58:41PM -0500, Leichter, Jerry wrote:
> > Sorry, that doesn't make any sense. If your HWRNG leaks 64 bits,
> > you might as well assume it leaks 256. When it comes to leaks of
> > this sort, the only interesting numbers are "0" an
At 17:58 -0500 2006/11/08, Leichter, Jerry wrote:
No, SHA-1 is holding on (by a thread) because of differences in the
details of the algorithm - details it shares with SHA-256. I
don't think anyone will seriously argue that if SHA-1 is shown to
be as vulnerable as we now know ND5 to be, then SHA
| On Wed, Nov 08, 2006 at 05:58:41PM -0500, Leichter, Jerry wrote:
| > Sorry, that doesn't make any sense. If your HWRNG leaks 64 bits,
| > you might as well assume it leaks 256. When it comes to leaks of
| > this sort, the only interesting numbers are "0" and "all".
|
| Nonsense. I can cite num
| > | > Just wondering about this little piece. How did we get to 256-bit
| > | > AES as a requirement? Just what threat out there justifies it? ...
|
| I can see it as useful if some bits of the key got leaked somehow.
| For example, if you're using a HWRNG to generate keys, and it's
| bits are
Just wondering about this little piece. How did we get to 256-bit
AES as a requirement? Just what threat out there justifies it?
There's no conceivable brute-force attack against 128-bit AES as far
out as we can see, so we're presumably begin paranoid about an
analytic
attack. But is there e
-Original Message-
From: Saqib Ali [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 07, 2006 08:16
Hello Alexander,
> My guess is that slow compilation is a result of access time
> misconfiguration: if a filesystem has access time
enabled, th
| > | ...Compusec is great for home / personal use. It is cheap i.e. $0.00
| > | (Free), and does not slow down the computer as much as the other
| > | products. But that is because it only support 128 bit AES, which is a
| > | major drawback as most enterprise settings require at least 256 bit
| >
"Saqib Ali" <[EMAIL PROTECTED]> writes:
>> My guess is that slow compilation is a result of access time
>> misconfiguration: if a filesystem has access time enabled, then each
>> time a file is read, the file system updates access time on disk. A
>> solution is to set noatime option on the filesys
Hello Alexander,
My guess is that slow compilation is a result of access time
misconfiguration: if a filesystem has access time enabled, then each
time a file is read, the file system updates access time on disk. A
solution is to set noatime option on the filesystem used for
compilation.
This
On Tue, 7 Nov 2006, Peter Gutmann wrote:
> "Saqib Ali" <[EMAIL PROTECTED]> writes:
>
> >I compile a lot of software on my laptop, and I *certainly notice* the
> >difference between my office laptop (no encryption) and my travel laptop
> >(with FDE). The laptops are exactly the same, with the same
"Saqib Ali" <[EMAIL PROTECTED]> writes:
>I compile a lot of software on my laptop, and I *certainly notice* the
>difference between my office laptop (no encryption) and my travel laptop
>(with FDE). The laptops are exactly the same, with the same image loaded. The
>only difference is the FDE softw
Quoting "Leichter, Jerry" <[EMAIL PROTECTED]>:
| ...Compusec is great for home / personal use. It is cheap i.e. $0.00
| (Free), and does not slow down the computer as much as the other
| products. But that is because it only support 128 bit AES, which is a
| major drawback as most enterprise set
On Sat, 4 Nov 2006, Ralf Senderek wrote:
On the unencrypted filesystem:
# > time dd if=/dev/zero of=cryptogram bs=1MB count=50
50+0 records in
50+0 records out
5000 bytes (50 MB) copied, 0.216106 seconds, 231 MB/s
real0m0.257s
user0m0.000s
sys 0m0.252s
Unless you have a disk
| ...Compusec is great for home / personal use. It is cheap i.e. $0.00
| (Free), and does not slow down the computer as much as the other
| products. But that is because it only support 128 bit AES, which is a
| major drawback as most enterprise settings require at least 256 bit
| AES
Just wond
On Thu, 2 Nov 2006, Alexander Klimov wrote:
> I guess many people here have tried full disk encryption for
> themselves, do you notice any difference in performance or not?
I've been using Matt Blaze's CFS (cryptographic file system) to encrypt
personal E-mail archives since 1994 or so. CFS is ab
On Thu, 2 Nov 2006, Alexander Klimov wrote:
I guess many people here have tried full disk encryption for
themselves, do you notice any difference in performance or not?
Yes and no!
I use dm-crypt on a Linux laptop with FC5.
On the encrypted filesystem:
# > df
/dev/mapper/secure 309895
Alexander Klimov <[EMAIL PROTECTED]> writes:
>If a PC is used by an interactive user, it is irrelevant how much access time
>is increased, as far as the user cannot see a difference without a timer.
>Several times I have read that disk encryption is not noticeable.
I agree that in most cases the
I compile a lot of software on my laptop, and I *certainly notice* the
difference between my office laptop (no encryption) and my travel
laptop (with FDE). The laptops are exactly the same, with the same
image loaded. The only difference is the FDE software that is
installed on the travel laptop.
On Thu, 02 Nov 2006 10:42:29 -0500, Ivan Krsti?
<[EMAIL PROTECTED]> wrote:
> Adam Shostack wrote:
> > Just a nit: as I understand things, Bitlocker is available, but not
> > on, by default. Someone needs to actively flip a switch to make it
> > go.
>
> Ah, okay. The notes I jotted down from Mac
On Wed, 1 Nov 2006, Saqib Ali wrote:
> Well for one thing, any software based FDE is extremely slow, doubles
> the file access times, and is a serious drain on the laptop battery.
If a PC is used by an interactive user, it is irrelevant how much
access time is increased, as far as the user cannot
Adam Shostack wrote:
> Just a nit: as I understand things, Bitlocker is available, but not
> on, by default. Someone needs to actively flip a switch to make it
> go.
Ah, okay. The notes I jotted down from MacIver's talk at HITB in
Malaysia indicate he said it was on by default in the upper versi
On Tue, Oct 31, 2006 at 06:50:20PM -0500, Ivan Krsti?? wrote:
| On the other hand, Vista is shipping with BitLocker enabled by default
| in the upper editions (Enterprise or somesuch), and doesn't rely on
Just a nit: as I understand things, Bitlocker is available, but not
on, by default. Someone
Well for one thing, any software based FDE is extremely slow, doubles
the file access times, and is a serious drain on the laptop battery.
See the URL below for a software based FDE benchmark/analysis:
http://www.xml-dev.com/blog/index.php?action=viewtopic&id=250
What if the encryption key for th
On Mon, 30 Oct 2006, Saqib Ali wrote:
> http://www.sfgate.com/cgi-bin/article.cgi?file=/chronicle/archive/2006/10/30/BUGU2M1ETT1.DTL&type=printable
> http://www.theglobeandmail.com/servlet/story/RTGAM.20061030.wharddrive1029/BNStory/Front/?page=rss&id=RTGAM.20061030.wharddrive1029
> http://www.inf
Saqib Ali wrote:
> Well for one thing, any software based FDE is extremely slow, doubles
> the file access times, and is a serious drain on the laptop battery.
Here's the relevant excerpt of the Elephant paper [0]:
"A typical desktop machine today has a 3 GHz P4 CPU and a hard disk that
can read
Saqib Ali wrote:
> http://www.infoworld.com/article/06/10/30/HNseagateagain_1.html
Notably, none of the three articles mention Vista's BitLocker, which
provides FDE in software and establishes trust via a TPM chip. (For
those who haven't heard about it, BitLocker also uses a clever diffuser
that N
http://www.sfgate.com/cgi-bin/article.cgi?file=/chronicle/archive/2006/10/30/BUGU2M1ETT1.DTL&type=printable
http://www.theglobeandmail.com/servlet/story/RTGAM.20061030.wharddrive1029/BNStory/Front/?page=rss&id=RTGAM.20061030.wharddrive1029
http://www.infoworld.com/article/06/10/30/HNseagateagain_1
36 matches
Mail list logo