On Fri, Jun 10, 2011 at 12:53 AM, Marsh Ray wrote:
>>> A few GB of state would hopefully put it in that size range where it's
>>> too large to fit on any attacker's ASIC,
>>
>> In the scrypt design, there was no attempt to make something too large
>> to fit, but rather simply to consume more die a
On 06/09/2011 08:08 PM, Solar Designer wrote:
The rest of your numbers passed my double-checking just fine. BTW,
0.35 um process is not state of the art, so things might actually be
even worse.
(I never had an HP RPN calculator, but I still have two different
Soviet-made programmable RPN calcu
On Fri, Jun 10, 2011 at 4:34 AM, Sandy Harris wrote:
> One indicator is the Copacobana machine, built from FPGAs, The first
> version a few
> years back cost 9,000 euro and broke DES in a week. There's a later version.
> http://www.copacobana.org/
Concerning COPACOBANA, there are now "productize
On Fri, Jun 10, 2011 at 08:44:39AM +0400, Solar Designer wrote:
> Some more relevant numbers are: 27k gates, 250 MHz, 3 Gbps in a 130 nm
> CMOS process:
>
> http://www.heliontech.com/downloads/aes_asic_helioncore.pdf
>
> Still, 3 Gbps gives something like 23 million AES block encryptions per
> se
On Thu, Jun 09, 2011 at 04:22:16PM -0500, Marsh Ray wrote:
> The article is behind a paywall, but Google quotes the relevant statistic:
> http://scholar.google.com/scholar?cluster=14788671232027796805
> "The standard-cell implementation on a 0.35 ??m CMOS process from Philips
> Semiconductors occu
On 06/09/2011 09:34 PM, Sandy Harris wrote:
One indicator is the Copacobana machine, built from FPGAs, The first
version a few years back cost 9,000 euro and broke DES in a week.
There's a later version. http://www.copacobana.org/
This box was from a few years ago:
http://picocomputing.com/pdf
On Fri, Jun 10, 2011 at 1:14 AM, Paul Hoffman wrote:
> Greetings again. I am helping someone design a system that will involve
> giving someone
> a randomly-generated key that they have to type in order to unlock data that
> is private
> but not terribly valuable. Thus, we want to keep the key
Although even non-augmented ZKPPs should a good KDF because even though the
server stores a password equivalent there is still value in protecting the
actual password.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mai
On Thu, Jun 9, 2011 at 7:34 PM, Solar Designer wrote:
> On Thu, Jun 09, 2011 at 05:22:59PM -0500, Nico Williams wrote:
>> And for remote password-based authentication we'll want to start using
>> ZKPPs
>
> This doesn't prevent offline password guessing attacks after a
> (temporary) server compromi
On Thu, Jun 09, 2011 at 05:49:38PM -0500, Marsh Ray wrote:
> On 06/09/2011 04:53 PM, Solar Designer wrote:
> >That's scary. Even more so if you actually multiply by $0.07, which
> >gives $42.
>
> Hmm, I thought I had included that.
>
> I left my trusty old HP RPN calculator at home today and whi
On 2011-06-10 3:14 AM, Paul Hoffman wrote:
Greetings again. I am helping someone design a system that will involve giving
someone a randomly-generated key that they have to type in order to unlock data
that is private but not terribly valuable. Thus, we want to keep the key as
short as practic
On Thu, Jun 09, 2011 at 05:22:59PM -0500, Nico Williams wrote:
> The KDF needs to have a short run time on mobile devices, which are at
> the lower end of end-user computational power, but anything that
> amounts to a millisecond of extra compute power for the attacker
> greatly slows them down (fr
On Thu, Jun 09, 2011 at 11:37:16PM +0100, Paul Crowley wrote:
> On 09/06/11 20:35, Solar Designer wrote:
> > ... if we expect
> >attackers with GPUs but maybe not with custom hardware (FPGA, ASIC), we
> >could want to stay away from SHA-2 family functions and use something
> >like Blowfish (Eksblow
On Thu, Jun 9, 2011 at 5:49 PM, Marsh Ray wrote:
> A few GB of state would hopefully put it in that size range where it's too
> large to fit on any attacker's ASIC, while at the same time being of a size
> for which a defender's commodity hardware is heavily optimized.
Smartphones don't have that
On 06/09/2011 04:53 PM, Solar Designer wrote:
On Thu, Jun 09, 2011 at 04:22:16PM -0500, Marsh Ray wrote:
Which neatly fits 2^32 trials per watt-second. A real engineer would
probably design the chips to minimize energy-per-trial, but I think our
estimate is probably still within an order of magn
On 09/06/11 20:35, Solar Designer wrote:
Right. We also know that it is very GPU-friendly, so if we expect
attackers with GPUs but maybe not with custom hardware (FPGA, ASIC), we
could want to stay away from SHA-2 family functions and use something
like Blowfish (Eksblowfish, bcrypt) in the KDF
On Thu, Jun 9, 2011 at 4:53 PM, Solar Designer wrote:
> On Thu, Jun 09, 2011 at 04:22:16PM -0500, Marsh Ray wrote:
>> Which neatly fits 2^32 trials per watt-second. A real engineer would
>> probably design the chips to minimize energy-per-trial, but I think our
>> estimate is probably still within
On 2011-06-10 7:22 AM, Marsh Ray wrote:
Last I checked, in the US electric power is around $0.07 per kWh in
areas considered "cheap". So each trial costs $4.53e−18 in electric power.
For an 64-bit key, you expect the adversary to need 2^63 trials for
which he might pay a power bill of $597.
For
On Thu, Jun 09, 2011 at 04:22:16PM -0500, Marsh Ray wrote:
> Which neatly fits 2^32 trials per watt-second. A real engineer would
> probably design the chips to minimize energy-per-trial, but I think our
> estimate is probably still within an order of magnitude or two.
>
> Last I checked, in the
On 06/09/2011 12:14 PM, Paul Hoffman wrote:
What is the current state of brute-force attacks on AES-128 blobs?
Are there recent results where we can estimate the cost of
brute-forcing 64-bit and 80-bit keys?
The article is behind a paywall, but Google quotes the relevant statistic:
http://scho
On Thu, Jun 09, 2011 at 08:11:00PM +0100, Paul Crowley wrote:
> We know *lots* about how fast SHA-256 can be run because of its use in
> BitCoin:
>
> https://en.bitcoin.it/wiki/Mining_hardware_comparison
Right. We also know that it is very GPU-friendly, so if we expect
attackers with GPUs but m
Paul -
On Thu, Jun 09, 2011 at 10:37:56PM +0400, Solar Designer wrote:
> If you add 1 million iterations of stretching in your KDF, 47 bits
> encoded in a passphrase is roughly equivalent to a 67-bit AES key, which
> sounds sufficient for something "not terribly valuable" (although
> another facto
On 09/06/11 18:14, Paul Hoffman wrote:
Greetings again. I am helping someone design a system that will involve giving
someone a randomly-generated key that they have to type in order to unlock data
that is private but not terribly valuable. Thus, we want to keep the key as
short as practical t
On Thu, Jun 9, 2011 at 1:14 PM, Paul Hoffman wrote:
> Greetings again. I am helping someone design a system that will involve
> giving someone a randomly-generated key that they have to type in order to
> unlock data that is private but not terribly valuable. Thus, we want to keep
> the key as
Hi,
On Thu, Jun 09, 2011 at 10:14:49AM -0700, Paul Hoffman wrote:
> Greetings again. I am helping someone design a system that will involve
> giving someone a randomly-generated key that they have to type in order to
> unlock data that is private but not terribly valuable. Thus, we want to keep
On Jun 9, 2011, at 1:14 49PM, Paul Hoffman wrote:
> Greetings again. I am helping someone design a system that will involve
> giving someone a randomly-generated key that they have to type in order to
> unlock data that is private but not terribly valuable. Thus, we want to keep
> the key as s
On Jun 9, 2011, at 10:43 AM, Ian G wrote:
> On 10/06/11 3:14 AM, Paul Hoffman wrote:
>> Greetings again. I am helping someone design a system that will involve
>> giving someone a randomly-generated key that they have to type in order to
>> unlock data that is private but not terribly valuable.
On 10/06/11 3:14 AM, Paul Hoffman wrote:
Greetings again. I am helping someone design a system that will involve giving
someone a randomly-generated key that they have to type in order to unlock data
that is private but not terribly valuable. Thus, we want to keep the key as
short as practical
Greetings again. I am helping someone design a system that will involve giving
someone a randomly-generated key that they have to type in order to unlock data
that is private but not terribly valuable. Thus, we want to keep the key as
short as practical to reduce typing and mis-typing, but long
29 matches
Mail list logo
