On Mon, Jun 29, 2015 at 09:40:56AM +0200, Fabio Pietrosanti (naif) - lists
wrote:
Now that Scrypt has been used by cryptocurrency a new generation of
hardware optimized miner (that can be converted to password-cracking)
went out https://www.hashcoins.com/buy-scrypt-miners/ .
What's so new
Hi,
Disclosure: I am the designer of yescrypt (building upon Colin Percival's
scrypt, obviously), and I am on the PHC panel (along with many others).
On Fri, May 08, 2015 at 10:34:28AM +0200, stef wrote:
On Fri, May 08, 2015 at 09:04:47AM +0200, Fabio Pietrosanti (naif) - lists
wrote:
Do
On Mon, May 04, 2015 at 11:48:25AM +0200, Fabio Pietrosanti (naif) - lists
wrote:
Also for upcoming implementation extending scrypt concept, like
yescrypt/yescrypt-lite it would be very interesting to think how to make
it faster in the context of the browser/javascript/html5.
Taylor Hornby
On Fri, Mar 13, 2015 at 12:29:58PM -0600, Jeffrey Goldberg wrote:
OK. So I guess we return to the original question, does anyone know of
an scrypt implementation in JavaScript?
I had already posted these links:
https://github.com/dchest/scrypt-async-js
I agree with Jeffrey's suggestion to implement server-side KDF as well,
with higher settings.
Just some minor detail on what (little) can be done on client side in
JavaScript:
On Thu, Mar 12, 2015 at 10:57:47AM -0600, Jeffrey Goldberg wrote:
2. Use SHA-512 in PBKDF2
This will make PBKDF2
On Fri, Mar 13, 2015 at 10:25:11AM +0100, Fabio Pietrosanti (naif) - lists
wrote:
SRP is a very cool authentication protocol, not yet widely deployed, but
with very interesting properties.
I'm wondering how strong is considered the storage of the password's
related material strength?
I
On Wed, Mar 11, 2015 at 02:20:42PM +, Alfonso De Gregorio wrote:
Until more browsers start supporting PBKDF2 with HMAC-SHA-256, you
might be better of reverting to a JavaScript library, to be plugged in
your scrypt implementation. I never took the chance to look at it, but
I heard that
On Wed, Feb 04, 2015 at 08:22:03AM -0500, Thor Lancelot Simon wrote:
For at least 15 years there's been general grumbling that the MD5 based
stream cipher used for confidentiality in RADIUS looks like snake oil.
Given how widely used the protocol is, and the failure of various successor
On Wed, Jun 04, 2014 at 09:45:16AM -0400, Peter Todd wrote:
Create a secret key that can be decrypted in a known amount of time
using parallel-serial hash chains. The creator can compute the timelock
in parallel, taking advantage of the large amount of cheap parallelism
available today, while
On Mon, Nov 19, 2012 at 02:19:22AM -0500, Jeffrey Walton wrote:
Has anyone come across a paper on how to migrate an existing database
with, for example, unsalted MD5 hashes, to something more appropriate
for 2012? Naively, I don't see why MD5(password) cannot be an input to
an improved system.
On Mon, Oct 29, 2012 at 04:06:58PM -0400, Jeffrey Walton wrote:
On Sun, Oct 28, 2012 at 3:01 PM, Solar Designer so...@openwall.com wrote:
The OPENSSL_cleanse() function is such that the memory is overwritten
with the counter values, whereas the counter is incremented in ways
dependent
On Sat, Oct 27, 2012 at 06:47:05PM -0700, Patrick Pelletier wrote:
For the most part, I would say that OpenSSL is not badly written, just
badly documented. I am not a cryptography expert (just a smart,
experienced programmer, trying to use TLS) so I'm not in a particularly
good position to
On Thu, Aug 16, 2012 at 02:46:58AM +0200, Patrick Mylund Nielsen wrote:
Blizzard Entertainment has been receiving a lot of flak from tech and mass
media lately for choosing to employ SRP in their Battle.net clients and
games. A lot of these outlets have been suggesting that SRP is weaker
than
On Thu, Aug 16, 2012 at 02:25:34AM +0200, Patrick Mylund Nielsen wrote:
PBKDF2 is certainly decent, and often the easiest choice if you intend to
comply with e.g. FIPS 140-2/ISO 27001, but the biggest argument against it
is that it _isn't_ difficult to parallelize, since it is just e.g.
Hi,
On Mon, Aug 06, 2012 at 11:27:45PM +0300, Elias Yarrkov wrote:
I use a custom KDF. I intend to write about this manner of constructing KDFs
later. The goal is to cause a high area*time cost for massively parallel brute
force via ASIC, similar to scrypt.
Please do write about this.
It is
Elias -
On Tue, Aug 07, 2012 at 03:36:32AM +0400, Solar Designer wrote:
On Mon, Aug 06, 2012 at 11:27:45PM +0300, Elias Yarrkov wrote:
I use a custom KDF. I intend to write about this manner of constructing KDFs
later. The goal is to cause a high area*time cost for massively parallel
Hi,
I've just posted the slides from my PHDays talk online:
http://www.openwall.com/presentations/PHDays2012-Password-Security/
The title is:
Password security: past, present, future
(with strong bias towards password hashing)
A few of you have already seen the historical background slides
On Sun, Feb 19, 2012 at 05:57:37PM +, Ben Laurie wrote:
In any case, I think the design of urandom in Linux is flawed and
should be fixed.
Do you have specific suggestions?
Short of making it block, I can think of the following:
1. More distros may follow the suggestion in the Ensuring
On Mon, Jan 02, 2012 at 09:40:36PM -0500, Jonathan Katz wrote:
Say passwords are chosen uniformly from a space of size N. If you never
change your password, then an adversary is guaranteed to guess your
password in N attempts, and in expectation guesses your password in N/2
attempts.
If
On Tue, Dec 27, 2011 at 03:54:35PM -0500, Jeffrey Walton wrote:
We're bouncing around ways to enforce non-similarity in passwords over
time: password1 is too similar too password2 (and similar to
password3, etc).
I'm not sure its possible with one way functions and block cipher residues.
On Thu, Dec 01, 2011 at 11:16:14PM -0600, Marsh Ray wrote:
On 12/01/2011 10:15 PM, Solar Designer wrote:
http://whitepixel.zorinaq.com is probably the fastest single MD5 hash
cracker. This one tests 33.1 billion of passwords per second against a
raw MD5 hash on 4 x AMD Radeon HD 5970 (8 GPUs
On Mon, Nov 28, 2011 at 04:57:03PM +1300, Peter Gutmann wrote:
Marsh Ray ma...@extendedsubset.com writes:
* Here's an example of RSA-512 certificates being factored and used to sign
malware:
http://blog.fox-it.com/2011/11/21/rsa-512-certificates-abused-in-the-wild/
That's an example of
On Mon, Nov 28, 2011 at 06:06:45PM +1300, Peter Gutmann wrote:
Solar Designer so...@openwall.com writes:
Here are some examples of 512-bit RSA keys factored:
Right, but that doesn't say anything about what happened here. [...]
Sure. I was not arguing with you, but rather I thought I'd
On Sat, Sep 03, 2011 at 03:02:42AM +1200, Peter Gutmann wrote:
Another point is that minting 200-250 certs isn't something you can do with a
mouse click, you need to prepare all the cert requests with site-specific data
customised to each site, and that takes time. They must have had the run
Hi,
We've just released those, as part of John the Ripper 1.7.8, but freely
licensed for reuse anywhere else. Our understanding is that S-box
expressions themselves are mathematical formulas and thus are not
subject to copyright. The specific code implementing them is licensed
under a heavily
On Tue, Jun 21, 2011 at 03:38:39PM +1200, Peter Gutmann wrote:
Jeffrey Walton noloa...@gmail.com writes:
The 'details' mentioned above is at http://www.schneier.com/blowfish-bug.txt,
and here's the crux of Morgan's report:
[bfinit] chokes whenever the most significant bit
of
On Wed, Jun 15, 2011 at 04:22:55AM +0400, Solar Designer wrote:
3. Order of ExpandKey()s in the costly loop:
http://www.openwall.com/lists/crypt-dev/2011/04/29/1
BTW, this inconsistency is seen even in bcrypt.c in OpenBSD - source
code comment vs. actual code.
Then I released my bcrypt code
On Mon, Jun 20, 2011 at 12:11:38PM -0500, Marsh Ray wrote:
On 06/20/2011 09:59 AM, Solar Designer wrote:
On Wed, Jun 15, 2011 at 04:22:55AM +0400, Solar Designer wrote:
Yesterday, I was informed of a bug in
JtR, which also made its way into crypt_blowfish, and which made the
hashes
://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/crypt/bcrypt.c.diff?r1=1.11;r2=1.12
That was in 1998. The commit message not surprisingly says:
fix base64 encoding, this problem was reported by
Solar Designer so...@false.com some time ago.
So it was indeed a deliberate decision not to break
On Fri, Jun 10, 2011 at 11:55:10AM -0400, Thierry Moreau wrote:
- Anybody has examples of source code distribution practical
arrangements for other specialized Linux distributions?
I don't quite see a problem with distributing source code for a
specialized Linux distribution. For example, we
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 factor
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
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 US
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 (Eksblowfish
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 (from
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 while
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
second
37 matches
Mail list logo
