-
Notifications
You must be signed in to change notification settings - Fork 2
/
discussions.mbox
10327 lines (9301 loc) · 519 KB
/
discussions.mbox
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
From [email protected] Jeu fév 14 20:43:56 2013 +0000
Return-Path: <[email protected]>
Mailing-List: contact [email protected]; run by ezmlm
Delivered-To: mailing list [email protected]
Received: (qmail 10147 invoked by uid 89); 14 Feb 2013 20:43:55 -0000
Received: by simscan 1.4.0 ppid: 10141, pid: 10143, t: 0.2557s
scanners: attach: 1.4.0 spam: 3.2.5
X-Spam-Flag: YES
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on
qmailtoaster.cryptyx.com
X-Spam-Level: *****
X-Spam-Status: Yes, score=5.5 required=4.0 tests=EMPTY_MESSAGE,HTML_MESSAGE,
MISSING_SUBJECT,RDNS_NONE,TVD_SPACE_RATIO autolearn=no version=3.2.5
X-Spam-Report:
* 0.0 HTML_MESSAGE BODY: HTML included in message
* 2.2 TVD_SPACE_RATIO BODY: TVD_SPACE_RATIO
* 1.8 MISSING_SUBJECT Missing Subject: header
* 1.4 EMPTY_MESSAGE Message appears to have no textual parts and no
* Subject: text
* 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS
Received: from unknown (HELO mail-qe0-f53.google.com) (209.85.128.53)
by qmailtoaster.cryptyx.com with (RC4-SHA encrypted) SMTP; 14 Feb 2013 20:43:55 -0000
Received-SPF: pass (qmailtoaster.cryptyx.com: SPF record at _netblocks.google.com designates 209.85.128.53 as permitted sender)
Received: by mail-qe0-f53.google.com with SMTP id 1so1269882qee.26
for <[email protected]>; Thu, 14 Feb 2013 12:43:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:x-received:date:message-id:subject:from:to
:content-type;
bh=AIbW4PAf3wW9lT9Gz5qZ9vE2P8LlZ3wy00PsknJ4Yzg=;
b=Jo1QweNm4epMJfY9Sm9itbUcIwijyJBbKSjdW0SG3GfpK1qZ/JgvgZufLD1iMm6Q7D
YR0PgWl62+34ef+yJreGJujJXc02ieUC2OrpU36U4D6bTW3IXALGMx3pTIc1wrHV7LG6
5bUIBxXL1TwJxzAYZOs/U4nvK47CuskTgUlaA6jap834tIW0Vpeny/XbuMWmkIzNDzPn
QZxFHqlYj+9mofi2hOnb6yXBZWRhhR6L/ddIFev2R56T4sxqK1cyI+GZzV54U3xpHKDV
sTAvgzFtPkm1IzvgZcnIIyJ8lgvd+uM+pFttRgzDfJmhnpRE2LUDsCtKFZPeizRJxPCt
tG1A==
MIME-Version: 1.0
X-Received: by 10.49.127.240 with SMTP id nj16mr34401qeb.13.1360874634444;
Thu, 14 Feb 2013 12:43:54 -0800 (PST)
Received: by 10.229.92.13 with HTTP; Thu, 14 Feb 2013 12:43:54 -0800 (PST)
Date: Thu, 14 Feb 2013 21:43:54 +0100
Message-ID: <CADPYE1EAFp4Dw=07gfHRVD4JT-2yXY6P0-B11a=FOQthenXMVw@mail.gmail.com>
Subject: [SPAM?]
From: Iraklis <[email protected]>
Content-Type: multipart/alternative; boundary=047d7b6d96242b814904d5b551d8
X-Spam-Prev-Subject:
--047d7b6d96242b814904d5b551d8
Content-Type: text/plain; charset=ISO-8859-1
--047d7b6d96242b814904d5b551d8
Content-Type: text/html; charset=ISO-8859-1
<div dir="ltr"><br></div>
--047d7b6d96242b814904d5b551d8--
From [email protected] Ven fév 15 21:45:24 2013 +0000
Return-Path: <[email protected]>
Mailing-List: contact [email protected]; run by ezmlm
Delivered-To: mailing list [email protected]
Received: (qmail 19989 invoked by uid 89); 15 Feb 2013 21:45:24 -0000
Received: by simscan 1.4.0 ppid: 19983, pid: 19985, t: 0.2563s
scanners: attach: 1.4.0 spam: 3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on
qmailtoaster.cryptyx.com
X-Spam-Level:
X-Spam-Status: No, score=0.3 required=4.0 tests=AWL,RDNS_NONE autolearn=no
version=3.2.5
Received: from unknown (HELO mail-ob0-f178.google.com) (209.85.214.178)
by qmailtoaster.cryptyx.com with (RC4-SHA encrypted) SMTP; 15 Feb 2013 21:45:23 -0000
Received-SPF: pass (qmailtoaster.cryptyx.com: SPF record at _netblocks.google.com designates 209.85.214.178 as permitted sender)
Received: by mail-ob0-f178.google.com with SMTP id wd20so3995931obb.23
for <[email protected]>; Fri, 15 Feb 2013 13:45:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=x-received:mime-version:from:date:message-id:subject:to
:content-type;
bh=4UFX+iEaTE7LsZ7kXfjm21QyrM4CJc4IRotBxKNfntI=;
b=Jc6twTynnJHW7vnPpTI1os5z9BmTXe1gzUAVGEaoFtAxDGtvlZItfwruEWR/Zk0UrT
bDFOwj/EcBUoILxxTa2+mFWSrwh6yhesO4fVieXBHvNa/Y8c9D7qdFTcKVw6kH48wjgg
9GfCFVXwlAxwuz/+Xse6yR9sgOK3hO2idWXAcT4t4+csL47DkcI0R5zu6mtPvKFrAo6S
9rrdJ8eH1XWq/EHmqy3tUp+6qm3KsEySBXVB77zkEIMf/E6AokfNTYt9MUoVJNGI53JK
sT3zKUwESzpA26ltG11pfeKTTGck72P3QKCvnRjIdhE2VXec8qegAfJOWPKeBX/mi3xy
6E7g==
X-Received: by 10.182.160.106 with SMTP id xj10mr2760038obb.98.1360964722391;
Fri, 15 Feb 2013 13:45:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.76.172.70 with HTTP; Fri, 15 Feb 2013 13:45:02 -0800 (PST)
From: Jean-Philippe Aumasson <[email protected]>
Date: Fri, 15 Feb 2013 22:45:02 +0100
Message-ID: <CAGiyFdcG1_1jLfR4_mi033V1AnL-gVPGeLPW1dkQ5dO731cfqA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Subject: FAQ
Hi, welcome to our discussions mailing list!
Earlier today we published an FAQ page, with only 1 Q&A so far
(https://password-hashing.net/faq.html). What other questions would
you like to see there?
Thanks!
JP
From [email protected] Ven fév 15 21:56:30 2013 +0000
Return-Path: <[email protected]>
Mailing-List: contact [email protected]; run by ezmlm
Delivered-To: mailing list [email protected]
Received: (qmail 20519 invoked by uid 89); 15 Feb 2013 21:56:30 -0000
Received: by simscan 1.4.0 ppid: 20513, pid: 20515, t: 0.3836s
scanners: attach: 1.4.0 spam: 3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on
qmailtoaster.cryptyx.com
X-Spam-Level:
X-Spam-Status: No, score=0.4 required=4.0 tests=AWL,RDNS_NONE autolearn=no
version=3.2.5
Received: from unknown (HELO out1-smtp.messagingengine.com) (66.111.4.25)
by qmailtoaster.cryptyx.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 15 Feb 2013 21:56:29 -0000
Received-SPF: pass (qmailtoaster.cryptyx.com: SPF record at goldmark.org designates 66.111.4.25 as permitted sender)
Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42])
by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 5448C204EC
for <[email protected]>; Fri, 15 Feb 2013 16:56:28 -0500 (EST)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
by compute2.internal (MEProxy); Fri, 15 Feb 2013 16:56:28 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=goldmark.org; h=
from:content-type:content-transfer-encoding:subject:message-id
:date:to:mime-version; s=mesmtp; bh=9Qnr3LfTKLE93SQMDUnmB5uowO4=; b=
Y1n0Kplrv1/y/yqwWhK9hcRNL07ElDJnH0HHX7PauA3bEOW/3WGbFnlkLO1Dsk7u
Mc1ahVQ0Jl2mC28VYfSQDJx89jMAE853dH4y1M5T5I6hNgFy/7qDfK1KLs0ktq4S
YEXUXQRAvbPXcGq7PmYg057+vWe6fKzKzrBnZA4MpzM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
messagingengine.com; h=from:content-type
:content-transfer-encoding:subject:message-id:date:to
:mime-version; s=smtpout; bh=9Qnr3LfTKLE93SQMDUnmB5uowO4=; b=A1F
awNIK6RQgrZn2YOWAIF7TTKNoN4eqdHSZLekBWeCwZuoqszqgc0LHQ3f4+bC69rn
sNa84CL9iLz1CU76yzV5GigByWuX80H7ahfwaG6bV/hXy6Mz5BXmyw/Q/nGrriiA
L9ASsXt6Q847oorlc0HB6SIGMbfHOTEsmTUS+/M8=
X-Sasl-enc: 0W4HHrzx/6ws/MPmmJUd+RUPC+78GPZH7tsyozsuObyH 1360965388
Received: from olympe.ewd.goldmark.org (unknown [72.64.118.114])
by mail.messagingengine.com (Postfix) with ESMTPA id 0382D48257F
for <[email protected]>; Fri, 15 Feb 2013 16:56:27 -0500 (EST)
From: Jeffrey Goldberg <[email protected]>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Message-Id: <[email protected]>
Date: Fri, 15 Feb 2013 15:56:25 -0600
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
X-Mailer: Apple Mail (2.1499)
Subject: History question
To what extent is it fair to write "the PHC grew out of discussion from =
#passwords12" ?
I'm writing an article for http://blog.agilebits.com that mentions the =
PCH but isn't focusing on it.
Cheers,
-j
=96-=20
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits
http://agilebits.com=
From [email protected] Ven fév 15 22:02:42 2013 +0000
Return-Path: <[email protected]>
Mailing-List: contact [email protected]; run by ezmlm
Delivered-To: mailing list [email protected]
Received: (qmail 20930 invoked by uid 89); 15 Feb 2013 22:02:42 -0000
Received: by simscan 1.4.0 ppid: 20924, pid: 20926, t: 0.3273s
scanners: attach: 1.4.0 spam: 3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on
qmailtoaster.cryptyx.com
X-Spam-Level:
X-Spam-Status: No, score=0.1 required=4.0 tests=AWL,RDNS_NONE autolearn=no
version=3.2.5
Received: from unknown (HELO mother.openwall.net) (195.42.179.200)
by qmailtoaster.cryptyx.com with SMTP; 15 Feb 2013 22:02:42 -0000
Received-SPF: pass (qmailtoaster.cryptyx.com: SPF record at openwall.com designates 195.42.179.200 as permitted sender)
Received: (qmail 29842 invoked from network); 15 Feb 2013 22:02:41 -0000
Received: from localhost (HELO pvt.openwall.com) (127.0.0.1)
by localhost with SMTP; 15 Feb 2013 22:02:41 -0000
Received: by pvt.openwall.com (Postfix, from userid 503)
id 19A846FB04; Sat, 16 Feb 2013 02:02:38 +0400 (MSK)
Date: Sat, 16 Feb 2013 02:02:38 +0400
From: Solar Designer <[email protected]>
To: Jeffrey Goldberg <[email protected]>
Message-ID: <[email protected]>
References: <[email protected]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email protected]>
User-Agent: Mutt/1.4.2.3i
Subject: Re: [PHC] History question
On Fri, Feb 15, 2013 at 03:56:25PM -0600, Jeffrey Goldberg wrote:
> To what extent is it fair to write "the PHC grew out of discussion from #passwords12" ?
Disclaimer: I was not at Passwords^12, at least not physically. ;-)
I think it mostly did not, although Passwords^12 has helped get some of
the panel members involved.
I think JP's interest in running this competition and his prior
experience with the SHA-3 competition played a bigger role. Without
that, we would probably not be having a competition (although some of us
would probably propose new password hashing schemes in 2013-2015
anyway - just fewer and without this competition process).
Alexander
From [email protected] Ven fév 15 22:14:21 2013 +0000
Return-Path: <[email protected]>
Mailing-List: contact [email protected]; run by ezmlm
Delivered-To: mailing list [email protected]
Received: (qmail 21419 invoked by uid 89); 15 Feb 2013 22:14:21 -0000
Received: by simscan 1.4.0 ppid: 21413, pid: 21415, t: 0.3409s
scanners: attach: 1.4.0 spam: 3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on
qmailtoaster.cryptyx.com
X-Spam-Level: **
X-Spam-Status: No, score=2.8 required=4.0 tests=AWL,RDNS_NONE autolearn=no
version=3.2.5
Received: from unknown (HELO mail-pa0-f54.google.com) (209.85.220.54)
by qmailtoaster.cryptyx.com with (RC4-SHA encrypted) SMTP; 15 Feb 2013 22:14:21 -0000
Received-SPF: pass (qmailtoaster.cryptyx.com: SPF record at _netblocks.google.com designates 209.85.220.54 as permitted sender)
Received: by mail-pa0-f54.google.com with SMTP id fa10so1958179pad.41
for <[email protected]>; Fri, 15 Feb 2013 14:14:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=x-received:message-id:date:from:user-agent:mime-version:to:subject
:references:in-reply-to:content-type:content-transfer-encoding;
bh=l6I5yx9iH8s+47vtNGqQsqcIb1W0Soxa8WeDLe4EHbM=;
b=ASry1IqRbdeqx3/znDUimF9E/CethLTRhYADpLcV4LHtYE3yFtDLpv49QQLZEfkVSh
enwhlCgX67DzA9cpGxN/N5/moIhsOnzRgxongnAbrxndX00jTMlwqYDF3oBYHitjufmV
hZS48BxFV8DdDOku7J9gfcYDc++SSqJJACZLxutqsd6voeTiqk0dmcC9b64qAEFxCkdK
rC35mXv1R1ObfauP5QLbHWpkmxM8atSEYoy8njIqMqIdjHgSGndikRsX02agSjq8EUUs
YxFCpJBizNxl09qY347kvJjztYSXXhosDnoE2fdcE/Vyx8o6q86Qjm9rIG3TTaHyvWBJ
RYQQ==
X-Received: by 10.68.224.199 with SMTP id re7mr9571742pbc.108.1360966458806;
Fri, 15 Feb 2013 14:14:18 -0800 (PST)
Received: from [192.168.2.100] (c-67-182-173-133.hsd1.ca.comcast.net. [67.182.173.133])
by mx.google.com with ESMTPS id ri1sm5893383pbc.16.2013.02.15.14.14.17
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Fri, 15 Feb 2013 14:14:18 -0800 (PST)
Message-ID: <[email protected]>
Date: Fri, 15 Feb 2013 14:14:17 -0800
From: ravin wind <[email protected]>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
References: <CAGiyFdcG1_1jLfR4_mi033V1AnL-gVPGeLPW1dkQ5dO731cfqA@mail.gmail.com>
In-Reply-To: <CAGiyFdcG1_1jLfR4_mi033V1AnL-gVPGeLPW1dkQ5dO731cfqA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHC] FAQ
On 02/15/2013 01:45 PM, Jean-Philippe Aumasson wrote:
> Hi, welcome to our discussions mailing list!
>
> Earlier today we published an FAQ page, with only 1 Q&A so far
> (https://password-hashing.net/faq.html). What other questions would
> you like to see there?
>
>
> Thanks!
>
>
> JP
On 02/15/2013 01:45 PM, Jean-Philippe Aumasson wrote:
> Hi, welcome to our discussions mailing list!
>
> Earlier today we published an FAQ page, with only 1 Q&A so far
> (https://password-hashing.net/faq.html). What other questions would
> you like to see there?
>
>
> Thanks!
>
>
> JP
I assume memory-hard problems are in play. Example: SHA-256 hashing and
filling the whole 4GB memory space with PRN to derive the next address
in memory, add a 128-bit salt, repeat hash again, and so on. Thus
overcoming low-memory requirements of PBKDF2 and forcing the use of the
whole memory. Pipelined FPGA, parallel CPUs or GPUs can't then be used.
Clustering will not work. A Critical-Path is formed due to mixing with
the password key (hashed 44-64 character Yubikey) at each hashing.
Whole memory space must always be filled to get the next hash correct.
Memory jumps will seem random. Scrypt comes to mind.
From [email protected] Sam fév 16 11:22:42 2013 +0000
Return-Path: <[email protected]>
Mailing-List: contact [email protected]; run by ezmlm
Delivered-To: mailing list [email protected]
Received: (qmail 21806 invoked by uid 89); 16 Feb 2013 11:22:41 -0000
Received: by simscan 1.4.0 ppid: 21800, pid: 21802, t: 0.4152s
scanners: attach: 1.4.0 spam: 3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on
qmailtoaster.cryptyx.com
X-Spam-Level:
X-Spam-Status: No, score=0.1 required=4.0 tests=RDNS_NONE autolearn=no
version=3.2.5
Received: from unknown (HELO mail-oa0-f47.google.com) (209.85.219.47)
by qmailtoaster.cryptyx.com with (RC4-SHA encrypted) SMTP; 16 Feb 2013 11:22:41 -0000
Received-SPF: pass (qmailtoaster.cryptyx.com: SPF record at _netblocks.google.com designates 209.85.219.47 as permitted sender)
Received: by mail-oa0-f47.google.com with SMTP id o17so4530935oag.20
for <[email protected]>; Sat, 16 Feb 2013 03:22:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:x-received:date:message-id:subject:from:to
:content-type;
bh=xUPOfO+2NBuG28t1UUni0WsCDOMdaXXsM6VoW/f9PtI=;
b=hwnRgHvxkj8z5OkL+W94uP4VFYlKvn4e860L1byvHS+0r9wynon4MM5nlMF5KjCgBS
aSyFtb6pYZwqJm/u+UlloLT2UDqbBnyVPKXCbpO7WOqlV4t6Nehno141Ei16FBUxwHKa
1D7U574kxRh7VR2mxEUaHZ99QV5PBBE84Glech8zAXNfL/AZCpFVd2LOiAS5q7cr+Y0/
VoOmMnRZGNyr0BKBpZHXXbvQ/iZyyGG5reeQHJFoFJkp+hqL5ox9DocHZOFGwV4wwLbo
gOElTf22ZOlKrzPPte2RZq0rYCYXi1LVrpvfYp5bPC5Owc887zcHzFD9x23l4jBgxJPY
/uJg==
MIME-Version: 1.0
X-Received: by 10.60.169.237 with SMTP id ah13mr3549462oec.41.1361013759611;
Sat, 16 Feb 2013 03:22:39 -0800 (PST)
Received: by 10.60.20.167 with HTTP; Sat, 16 Feb 2013 03:22:39 -0800 (PST)
Date: Sat, 16 Feb 2013 12:22:39 +0100
Message-ID: <CAJm7-NswdHAeMCdpjfW5+id=gaFn-m7tXOX7kLfrvXd4vD+iPQ@mail.gmail.com>
From: Jens Steube <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Different cost settings and optional input
Hey Guys,
even if gat3way's (coder of hashkill) comments were written in a way
so that they sound like a joke they should be taken seriously.
If you missed them, here they are:
> 09:29:30 gat3way | Hey are you sure about that criterion:
> 09:29:32 gat3way | "Ability to transform an existing hash to a different cost setting without knowledge of the password."
> 09:29:52 gat3way | assuming that was possible, it means I can change cost to 1 then attack the hash :)
> 09:39:47 jchillerup | i think it implies transforming it into only *more* expensive versions
> 09:40:02 jchillerup | Otherwise it wouldn't make sense :)
Of course, jchillerup is right. I think we should update the CFS to
make that clear. In a world full of wrong or partially wrong
information troublemaker can simply abuse this lack of clarity to
create an Illusion of a weakness in the PHC hash. Such an Illusion can
easily cost its credibility.
> 09:45:02 gat3way | Is it allowed to rely on a secret parameter other than the password then?
> 09:45:36 gat3way | otherwise I am afraid such requirement would very likely inherently weaken security
I am not sure what his concern is about. I think it is the following:
We allow the use of a "optional input":
> Other optional inputs include local parameters such as a personalization string, a secret key, or any application-specific parameter.
It is possible that a coder who is using the PHC hash in his
applications misuse such an optional parameter intenionally or
unintenionally. For example by storing the entire plaintext or parts
into it. At least we should write a note about not doing that or even
better completly not allow the use of an optional parameter.
--
Jens
From [email protected] Sam fév 16 11:31:47 2013 +0000
Return-Path: <[email protected]>
Mailing-List: contact [email protected]; run by ezmlm
Delivered-To: mailing list [email protected]
Received: (qmail 22440 invoked by uid 89); 16 Feb 2013 11:31:47 -0000
Received: by simscan 1.4.0 ppid: 22434, pid: 22436, t: 0.3534s
scanners: attach: 1.4.0 spam: 3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on
qmailtoaster.cryptyx.com
X-Spam-Level:
X-Spam-Status: No, score=0.1 required=4.0 tests=HTML_MESSAGE,RDNS_NONE
autolearn=no version=3.2.5
Received: from unknown (HELO mail-la0-f50.google.com) (209.85.215.50)
by qmailtoaster.cryptyx.com with (RC4-SHA encrypted) SMTP; 16 Feb 2013 11:31:46 -0000
Received-SPF: pass (qmailtoaster.cryptyx.com: SPF record at _netblocks.google.com designates 209.85.215.50 as permitted sender)
Received: by mail-la0-f50.google.com with SMTP id ec20so4193735lab.37
for <[email protected]>; Sat, 16 Feb 2013 03:31:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=patrickmylund.com; s=pmylund;
h=mime-version:x-received:x-originating-ip:in-reply-to:references
:date:message-id:subject:from:to:cc:content-type;
bh=ta9kDfKuO9wRq1/OAmZwyE/PkTCrX16SitcNRvV3UBw=;
b=BSl5lYj8HxAyIzvjMSB55cTZU63tzUxmvgm1/rtT7M1o/0YSkhAnOLLV8lyNFuxouY
1T+kRZVFVNOK9MOoc9eP81Ev3+8mXStSJfyg1Wqdl+GeM3RqqpFLN/eVNn74T/CKR95u
z4R/35PnVqz7lpqE3ndx3tfpkfa/vctp9EpSY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=mime-version:x-received:x-originating-ip:in-reply-to:references
:date:message-id:subject:from:to:cc:content-type:x-gm-message-state;
bh=ta9kDfKuO9wRq1/OAmZwyE/PkTCrX16SitcNRvV3UBw=;
b=pgwVMyCr/MEZ7JctTvDOaxN3QkB37nBXbOf6igtYtvlwy9If0b3PKD5qYBtC1j/pY3
xmtWlN9NCJGK8B3WV2CKT/FS7GobzSp/jKDOYt0yKE/eujeNbkQvGCZ33BVOPUoWKA5Q
XSL7dhiqRg6nfS4AEBULMRZkvg7JGK0ELlQVLqOe5mbuNaaZHl/Zx+I+Tsei3q6VSA2A
JN1QIEH38KW0E+BZWLpXvluEybelaV6JMu79S19kgHUY5MFNkWK1rxGRKheX/mrSfvU7
FHv94gYsj9OGeTQA16dE3x5YdFx77Dp+/hMXG1LvCRrWH6UeirAOVw00mqIOCxXKJ0ZC
MmYA==
MIME-Version: 1.0
X-Received: by 10.112.47.168 with SMTP id e8mr3286807lbn.46.1361014306156;
Sat, 16 Feb 2013 03:31:46 -0800 (PST)
Received: by 10.112.74.162 with HTTP; Sat, 16 Feb 2013 03:31:45 -0800 (PST)
X-Originating-IP: [85.224.171.72]
In-Reply-To: <CAJm7-NswdHAeMCdpjfW5+id=gaFn-m7tXOX7kLfrvXd4vD+iPQ@mail.gmail.com>
References: <CAJm7-NswdHAeMCdpjfW5+id=gaFn-m7tXOX7kLfrvXd4vD+iPQ@mail.gmail.com>
Date: Sat, 16 Feb 2013 12:31:45 +0100
Message-ID: <CAEw2jfw0q-1bkZjNja_-Ne4HDJg7Owv5FAuqRyf+Q=LEYm88rg@mail.gmail.com>
From: Patrick Mylund Nielsen <[email protected]>
To: Jens Steube <[email protected]>
Content-Type: multipart/alternative; boundary=bcaec553fde040b20304d5d5d6d3
X-Gm-Message-State: ALoCoQnjJVAMOPH0/qO33o9g947p4sjxp5FfYoH8zFFskHGesaWe8CT4wwASTyctriTd40lttERn
Subject: Re: [PHC] Different cost settings and optional input
--bcaec553fde040b20304d5d5d6d3
Content-Type: text/plain; charset=UTF-8
Agree on the first point. On the second point, I think he is suggesting
that you would have to save some of the initial input, but there is no
reason that you wouldn't be able to apply the hypothetical construction to
its own output to increase the required work per verification (similar to
how some developers are currently upgrading MD5(pwd) to bcrypt(MD5(pwd)) to
increase cost without requiring users to log in.)
On Sat, Feb 16, 2013 at 12:22 PM, Jens Steube <[email protected]> wrote:
> Hey Guys,
>
> even if gat3way's (coder of hashkill) comments were written in a way
> so that they sound like a joke they should be taken seriously.
>
> If you missed them, here they are:
>
> > 09:29:30 gat3way | Hey are you sure about that criterion:
> > 09:29:32 gat3way | "Ability to transform an existing hash to a different
> cost setting without knowledge of the password."
> > 09:29:52 gat3way | assuming that was possible, it means I can change
> cost to 1 then attack the hash :)
> > 09:39:47 jchillerup | i think it implies transforming it into only
> *more* expensive versions
> > 09:40:02 jchillerup | Otherwise it wouldn't make sense :)
>
> Of course, jchillerup is right. I think we should update the CFS to
> make that clear. In a world full of wrong or partially wrong
> information troublemaker can simply abuse this lack of clarity to
> create an Illusion of a weakness in the PHC hash. Such an Illusion can
> easily cost its credibility.
>
> > 09:45:02 gat3way | Is it allowed to rely on a secret parameter other
> than the password then?
> > 09:45:36 gat3way | otherwise I am afraid such requirement would very
> likely inherently weaken security
>
> I am not sure what his concern is about. I think it is the following:
> We allow the use of a "optional input":
>
> > Other optional inputs include local parameters such as a personalization
> string, a secret key, or any application-specific parameter.
>
> It is possible that a coder who is using the PHC hash in his
> applications misuse such an optional parameter intenionally or
> unintenionally. For example by storing the entire plaintext or parts
> into it. At least we should write a note about not doing that or even
> better completly not allow the use of an optional parameter.
>
> --
> Jens
>
--bcaec553fde040b20304d5d5d6d3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div style>Agree on the first point. On the second point, =
I think he is suggesting that you would have to save some of the initial in=
put, but there is no reason that you wouldn't be able to apply the hypo=
thetical construction to its own output to increase the required work per v=
erification (similar to how some developers are currently upgrading MD5(pwd=
) to bcrypt(MD5(pwd)) to increase cost without requiring users to log in.)<=
/div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sat,=
Feb 16, 2013 at 12:22 PM, Jens Steube <span dir=3D"ltr"><<a href=3D"mai=
lto:[email protected]" target=3D"_blank">[email protected]</a>><=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hey Guys,<br>
<br>
even if gat3way's (coder of hashkill) comments were written in a way<br=
>
so that they sound like a joke they should be taken seriously.<br>
<br>
If you missed them, here they are:<br>
<br>
> 09:29:30 gat3way | Hey are you sure about that criterion:<br>
> 09:29:32 gat3way | "Ability to transform an existing hash to a di=
fferent cost setting without knowledge of the password."<br>
> 09:29:52 gat3way | assuming that was possible, it means I can change c=
ost to 1 then attack the hash :)<br>
> 09:39:47 jchillerup | i think it implies transforming it into only *mo=
re* expensive versions<br>
> 09:40:02 jchillerup | Otherwise it wouldn't make sense :)<br>
<br>
Of course, jchillerup is right. I think we should update the CFS to<br>
make that clear. In a world full of wrong or partially wrong<br>
information troublemaker can simply abuse this lack of clarity to<br>
create an Illusion of a weakness in the PHC hash. Such an Illusion can<br>
easily cost its credibility.<br>
<br>
> 09:45:02 gat3way | Is it allowed to rely on a secret parameter other t=
han the password then?<br>
> 09:45:36 gat3way | otherwise I am afraid such requirement would very l=
ikely inherently weaken security<br>
<br>
I am not sure what his concern is about. I think it is the following:<br>
We allow the use of a "optional input":<br>
<br>
> Other optional inputs include local parameters such as a personalizati=
on string, a secret key, or any application-specific parameter.<br>
<br>
It is possible that a coder who is using the PHC hash in his<br>
applications misuse such an optional parameter intenionally or<br>
unintenionally. For example by storing the entire plaintext or parts<br>
into it. At least we should write a note about not doing that or even<br>
better completly not allow the use of an optional parameter.<br>
<br>
--<br>
Jens<br>
</blockquote></div><br></div>
--bcaec553fde040b20304d5d5d6d3--
From [email protected] Sam fév 16 11:43:58 2013 +0000
Return-Path: <[email protected]>
Mailing-List: contact [email protected]; run by ezmlm
Delivered-To: mailing list [email protected]
Received: (qmail 22866 invoked by uid 89); 16 Feb 2013 11:43:58 -0000
Received: by simscan 1.4.0 ppid: 22860, pid: 22862, t: 0.2762s
scanners: attach: 1.4.0 spam: 3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on
qmailtoaster.cryptyx.com
X-Spam-Level: *
X-Spam-Status: No, score=1.5 required=4.0 tests=AWL,RDNS_NONE autolearn=no
version=3.2.5
Received: from unknown (HELO mail-qe0-f53.google.com) (209.85.128.53)
by qmailtoaster.cryptyx.com with (RC4-SHA encrypted) SMTP; 16 Feb 2013 11:43:58 -0000
Received-SPF: pass (qmailtoaster.cryptyx.com: SPF record at _netblocks.google.com designates 209.85.128.53 as permitted sender)
Received: by mail-qe0-f53.google.com with SMTP id 1so1803213qee.40
for <[email protected]>; Sat, 16 Feb 2013 03:43:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=x-received:mime-version:sender:in-reply-to:references:from:date
:x-google-sender-auth:message-id:subject:to:cc:content-type;
bh=16f7l6Lvqs0r3Tfk6crKQBKrAcp9MK8IwzHUS/uIwmU=;
b=rEv9PaCSXCbzP5zYuMj6dlz7laQcowWIbCnCf8b4tTOOp62yaO1Ap+eTe+IyqzLgOg
DbnNmAvg+okWD0JuLKSKsNeFSzrc01jyScp3qaFyYJCH4LQ/SG1bnn+4dHJQyib1fsXS
0z3oG2bolnwYV6ttDdz/RZ/c/LBNG07jWx+EVNsvF2/GOOQsTEF9LGR6dMM9oRMe9zCa
+4RMxFhtyMXQ715SgWy4LNKTziE2hHwKX0q5RONiprMr567gt7TuqwSDpoc7Sb1SCKht
JhhLU7oH8JdM5U413WwqovAVyv1r9OK0unYJ/s+VzwvnyMD27MFTChWi9m4xlfeSjv1u
9NrA==
X-Received: by 10.229.252.208 with SMTP id mx16mr443971qcb.37.1361015037033;
Sat, 16 Feb 2013 03:43:57 -0800 (PST)
MIME-Version: 1.0
Sender: [email protected]
Received: by 10.49.117.201 with HTTP; Sat, 16 Feb 2013 03:43:36 -0800 (PST)
In-Reply-To: <CAJm7-NswdHAeMCdpjfW5+id=gaFn-m7tXOX7kLfrvXd4vD+iPQ@mail.gmail.com>
References: <CAJm7-NswdHAeMCdpjfW5+id=gaFn-m7tXOX7kLfrvXd4vD+iPQ@mail.gmail.com>
From: Jens Christian Hillerup <[email protected]>
Date: Sat, 16 Feb 2013 12:43:36 +0100
X-Google-Sender-Auth: cjLk1ChmYto7DmtTMVnsAXKFJho
Message-ID: <CAMGhuPFhk4tsmN0h5tcd8cFKhV6teeR9HFfKy4A42ypCP7yVQw@mail.gmail.com>
To: Jens Steube <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHC] Different cost settings and optional input
On Sat, Feb 16, 2013 at 12:22 PM, Jens Steube <[email protected]> wrote:
> Of course, jchillerup is right. I think we should update the CFS to
> make that clear. In a world full of wrong or partially wrong
> information troublemaker can simply abuse this lack of clarity to
> create an Illusion of a weakness in the PHC hash. Such an Illusion can
> easily cost its credibility.
>
>> 09:45:02 gat3way | Is it allowed to rely on a secret parameter other than the password then?
>> 09:45:36 gat3way | otherwise I am afraid such requirement would very likely inherently weaken security
>
> I am not sure what his concern is about. I think it is the following:
> We allow the use of a "optional input":
(I'm jchillerup from the previous IRC discussion - hi)
I also had some doubts when I read that. Given two hashes, it'd be
trivial to determine if they share a preimage; just, in parallel,
increase the work for both of them by 1 until you see a hash you've
seen before in the chain (hit), or you've increased-by-one for too
long (miss).
However, this attack is not that important I'd argue, because if two
equal passwords *exist* it is likely that that password is in some
dictionary anyway, or that they originate from the same person. For
the former case the attacker could perform a dictionary attack on the
variant that requires lesser work. But hopefully the final PHC
candidate will require too much work for dictionary attacks, even at
its lightest setting. For the latter case the attacker would know that
the two passwords are equal, and not a lot more than that.
JC
From [email protected] Sam fév 16 11:54:29 2013 +0000
Return-Path: <[email protected]>
Mailing-List: contact [email protected]; run by ezmlm
Delivered-To: mailing list [email protected]
Received: (qmail 23402 invoked by uid 89); 16 Feb 2013 11:54:29 -0000
Received: by simscan 1.4.0 ppid: 23396, pid: 23398, t: 0.2753s
scanners: attach: 1.4.0 spam: 3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on
qmailtoaster.cryptyx.com
X-Spam-Level:
X-Spam-Status: No, score=0.1 required=4.0 tests=HTML_MESSAGE,RDNS_NONE
autolearn=no version=3.2.5
Received: from unknown (HELO mail-la0-f51.google.com) (209.85.215.51)
by qmailtoaster.cryptyx.com with (RC4-SHA encrypted) SMTP; 16 Feb 2013 11:54:29 -0000
Received-SPF: pass (qmailtoaster.cryptyx.com: SPF record at _netblocks.google.com designates 209.85.215.51 as permitted sender)
Received: by mail-la0-f51.google.com with SMTP id fo13so4225459lab.38
for <[email protected]>; Sat, 16 Feb 2013 03:54:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=patrickmylund.com; s=pmylund;
h=mime-version:x-received:x-originating-ip:in-reply-to:references
:date:message-id:subject:from:to:cc:content-type;
bh=QIFWyGShEZXcVEwTsSn6VmpigHnMkZF7ihKruOnTn78=;
b=h3GYijEtK+WymaHTB+S22bkieB+pphORPYToGe5u0yqARv/LQJr8s5t0jOSUmjccu5
JN0mvHTEwW0hIafKmlmeqi3s9CgxLS3sowrMJve0ELRr1LtxeJuaIqnlueuWM9b8945s
MHOPPuMpY4S4tmoJBy6dVkVCwRZr5YHado4sI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=mime-version:x-received:x-originating-ip:in-reply-to:references
:date:message-id:subject:from:to:cc:content-type:x-gm-message-state;
bh=QIFWyGShEZXcVEwTsSn6VmpigHnMkZF7ihKruOnTn78=;
b=KfYOAWVN3MPYcGOqGpI8KHceNQCmBnZ3G1TnHUrN1ipRbJsyzE52loaD1j+Cgp4hah
Mci7f3ACqIB92BXjl2ZeQEMIF++mbkSHodM/3bVw+UcTRW9N5c2hoGyWVqQkjcZdN0vv
Tqe+cbfPiCAH/ykqKvGOLbOtwcfSgAQfzq1PdwkE01LR9urdcsM8C7LBU6T1zLtJ9wdl
CVN0v0KZQjRY5yt1BiANOqPktkwNZmMa0fE9wz9AB80UbsED6WmjSJ1WP29n9kwbnRkl
dRspwa+eSkj4Gq9mvJkVdQBdW/src/9nuBhxvpMAo7TXlFkXbdDF36tNzGvjTEWoSUwQ
lQ7g==
MIME-Version: 1.0
X-Received: by 10.112.41.101 with SMTP id e5mr3174925lbl.120.1361015668426;
Sat, 16 Feb 2013 03:54:28 -0800 (PST)
Received: by 10.112.74.162 with HTTP; Sat, 16 Feb 2013 03:54:28 -0800 (PST)
X-Originating-IP: [85.224.171.72]
In-Reply-To: <CAMGhuPFhk4tsmN0h5tcd8cFKhV6teeR9HFfKy4A42ypCP7yVQw@mail.gmail.com>
References: <CAJm7-NswdHAeMCdpjfW5+id=gaFn-m7tXOX7kLfrvXd4vD+iPQ@mail.gmail.com>
<CAMGhuPFhk4tsmN0h5tcd8cFKhV6teeR9HFfKy4A42ypCP7yVQw@mail.gmail.com>
Date: Sat, 16 Feb 2013 12:54:28 +0100
Message-ID: <CAEw2jfzDh6d61PTMp3U2YqiBvYbuRA=skQGazsJuYJ7SWFS6CQ@mail.gmail.com>
From: Patrick Mylund Nielsen <[email protected]>
To: Jens Christian Hillerup <[email protected]>
Cc: Jens Steube <[email protected]>, [email protected]
Content-Type: multipart/alternative; boundary=e0cb4efe2f9c73480204d5d627ae
X-Gm-Message-State: ALoCoQnFYQEjN7vCHOX3/ceOpP2etU8dex/Kpq3ojv4hsTQiHEW4jIFQmJlnVdGor5MsXyIxQl0T
Subject: Re: [PHC] Different cost settings and optional input
--e0cb4efe2f9c73480204d5d627ae
Content-Type: text/plain; charset=UTF-8
A non-secret parameter (salt) would presumably solve that problem.
On Sat, Feb 16, 2013 at 12:43 PM, Jens Christian Hillerup <[email protected]
> wrote:
> On Sat, Feb 16, 2013 at 12:22 PM, Jens Steube <[email protected]>
> wrote:
> > Of course, jchillerup is right. I think we should update the CFS to
> > make that clear. In a world full of wrong or partially wrong
> > information troublemaker can simply abuse this lack of clarity to
> > create an Illusion of a weakness in the PHC hash. Such an Illusion can
> > easily cost its credibility.
> >
> >> 09:45:02 gat3way | Is it allowed to rely on a secret parameter other
> than the password then?
> >> 09:45:36 gat3way | otherwise I am afraid such requirement would very
> likely inherently weaken security
> >
> > I am not sure what his concern is about. I think it is the following:
> > We allow the use of a "optional input":
>
> (I'm jchillerup from the previous IRC discussion - hi)
>
> I also had some doubts when I read that. Given two hashes, it'd be
> trivial to determine if they share a preimage; just, in parallel,
> increase the work for both of them by 1 until you see a hash you've
> seen before in the chain (hit), or you've increased-by-one for too
> long (miss).
>
> However, this attack is not that important I'd argue, because if two
> equal passwords *exist* it is likely that that password is in some
> dictionary anyway, or that they originate from the same person. For
> the former case the attacker could perform a dictionary attack on the
> variant that requires lesser work. But hopefully the final PHC
> candidate will require too much work for dictionary attacks, even at
> its lightest setting. For the latter case the attacker would know that
> the two passwords are equal, and not a lot more than that.
>
> JC
>
--e0cb4efe2f9c73480204d5d627ae
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">A non-secret parameter (salt) would presumably solve that =
problem.</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"=
>On Sat, Feb 16, 2013 at 12:43 PM, Jens Christian Hillerup <span dir=3D"ltr=
"><<a href=3D"mailto:[email protected]" target=3D"_blank">jens@hillerup.=
net</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Sat, Feb 16, 2013 at 12=
:22 PM, Jens Steube <<a href=3D"mailto:[email protected]">jens.steub=
[email protected]</a>> wrote:<br>
</div><div class=3D"im">> Of course, jchillerup is right. I think we sho=
uld update the CFS to<br>
> make that clear. In a world full of wrong or partially wrong<br>
> information troublemaker can simply abuse this lack of clarity to<br>
> create an Illusion of a weakness in the PHC hash. Such an Illusion can=
<br>
> easily cost its credibility.<br>
><br>
>> 09:45:02 gat3way | Is it allowed to rely on a secret parameter oth=
er than the password then?<br>
>> 09:45:36 gat3way | otherwise I am afraid such requirement would ve=
ry likely inherently weaken security<br>
><br>
> I am not sure what his concern is about. I think it is the following:<=
br>
> We allow the use of a "optional input":<br>
<br>
</div>(I'm jchillerup from the previous IRC discussion - hi)<br>
<br>
I also had some doubts when I read that. Given two hashes, it'd be<br>
trivial to determine if they share a preimage; just, in parallel,<br>
increase the work for both of them by 1 until you see a hash you've<br>
seen before in the chain (hit), or you've increased-by-one for too<br>
long (miss).<br>
<br>
However, this attack is not that important I'd argue, because if two<br=
>
equal passwords *exist* it is likely that that password is in some<br>
dictionary anyway, or that they originate from the same person. For<br>
the former case the attacker could perform a dictionary attack on the<br>
variant that requires lesser work. But hopefully the final PHC<br>
candidate will require too much work for dictionary attacks, even at<br>
its lightest setting. For the latter case the attacker would know that<br>
the two passwords are equal, and not a lot more than that.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
JC<br>
</font></span></blockquote></div><br></div>
--e0cb4efe2f9c73480204d5d627ae--
From [email protected] Sam fév 16 14:24:24 2013 +0000
Return-Path: <[email protected]>
Mailing-List: contact [email protected]; run by ezmlm
Delivered-To: mailing list [email protected]
Received: (qmail 29525 invoked by uid 89); 16 Feb 2013 14:24:24 -0000
Received: by simscan 1.4.0 ppid: 29519, pid: 29521, t: 0.9415s
scanners: attach: 1.4.0 spam: 3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on
qmailtoaster.cryptyx.com
X-Spam-Level:
X-Spam-Status: No, score=0.1 required=4.0 tests=AWL,RDNS_NONE autolearn=no
version=3.2.5
Received: from unknown (HELO mother.openwall.net) (195.42.179.200)
by qmailtoaster.cryptyx.com with SMTP; 16 Feb 2013 14:24:23 -0000
Received-SPF: pass (qmailtoaster.cryptyx.com: SPF record at openwall.com designates 195.42.179.200 as permitted sender)
Received: (qmail 23653 invoked from network); 16 Feb 2013 14:24:21 -0000
Received: from localhost (HELO pvt.openwall.com) (127.0.0.1)
by localhost with SMTP; 16 Feb 2013 14:24:21 -0000
Received: by pvt.openwall.com (Postfix, from userid 503)
id 02B2A6FB04; Sat, 16 Feb 2013 18:24:15 +0400 (MSK)
Date: Sat, 16 Feb 2013 18:24:15 +0400
From: Solar Designer <[email protected]>
Cc: Milen Rangelov <[email protected]>
Message-ID: <[email protected]>
References: <CAJm7-NswdHAeMCdpjfW5+id=gaFn-m7tXOX7kLfrvXd4vD+iPQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAJm7-NswdHAeMCdpjfW5+id=gaFn-m7tXOX7kLfrvXd4vD+iPQ@mail.gmail.com>
User-Agent: Mutt/1.4.2.3i
Subject: Re: [PHC] Different cost settings and optional input
Milen - I don't know if you have joined us on the discussions list or
not yet, so I am CC'ing you just in case. Please join us! :-)
On Sat, Feb 16, 2013 at 12:22:39PM +0100, Jens Steube wrote:
> > 09:29:30 gat3way | Hey are you sure about that criterion:
> > 09:29:32 gat3way | "Ability to transform an existing hash to a different cost setting without knowledge of the password."
> > 09:29:52 gat3way | assuming that was possible, it means I can change cost to 1 then attack the hash :)
> > 09:39:47 jchillerup | i think it implies transforming it into only *more* expensive versions
> > 09:40:02 jchillerup | Otherwise it wouldn't make sense :)
>
> Of course, jchillerup is right. I think we should update the CFS to
> make that clear.
I noticed this curious wording too (in one of the drafts), but I did not
object to it because:
1. We specify nearby that we'll evaluate "Effectiveness of the cost
parameter (e.g. can the time and space expected requirements be
bypassed?)" Thus, password hashing schemes that allow for cost
downgrades are discouraged.
2. There may be time-memory trade-offs. If someone clever comes up with
a password hashing scheme where an existing hash may be transformed to a
higher CPU cost but lower memory cost, or vice versa, without knowledge
of the password - this may be fine, as long as this property is known
and considered in the evaluation. A password hashing scheme should not
be automatically disqualified, nor necessarily discouraged, just for
possessing this property. In some cases, this property may be useful.
Note that this potentially differs from scrypt's TMTO. In scrypt, the
TMTO is available for each individual scrypt computation, without having
to do any precomputation (transforming the stored hash). In #2 above, I
am referring to a broader class of possible TMTOs, including those that
may require significant amount of precomputation (just not knowledge or
cracking of the actual password).
In other words, I did not object because I did not want us to throw the
potential baby out with the water. I also did not explain this until
now, though - perhaps I should have. :-)
And maybe we should revise the wording somehow... or link to this sort
of explanation, which we'd put somewhere (near the end of the FAQ, as
perhaps this is not a very frequent question, yet it may come up more
than once?)
As to TMTOs in general, there are some pros and cons to having and not
having them in a password hashing scheme. (In fact, "not having" only
means that the TMTOs are such that they're not lucrative for almost any
attacker. Not that they literally don't exist.) I expect that some of
the submissions of sequential memory-hard schemes will (deliberately?)
allow for TMTOs, some will (deliberately?) defeat TMTOs, and some will
have a Boolean parameter controlling that. All of these are welcome.
Alexander
From [email protected] Sam fév 16 15:47:23 2013 +0000
Return-Path: <[email protected]>
Mailing-List: contact [email protected]; run by ezmlm
Delivered-To: mailing list [email protected]
Received: (qmail 405 invoked by uid 89); 16 Feb 2013 15:47:22 -0000
Received: by simscan 1.4.0 ppid: 399, pid: 401, t: 0.5511s
scanners: attach: 1.4.0 spam: 3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on
qmailtoaster.cryptyx.com
X-Spam-Level:
X-Spam-Status: No, score=0.1 required=4.0 tests=RDNS_NONE autolearn=no
version=3.2.5
Received: from unknown (HELO out1-smtp.messagingengine.com) (66.111.4.25)
by qmailtoaster.cryptyx.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 16 Feb 2013 15:47:22 -0000
Received-SPF: pass (qmailtoaster.cryptyx.com: SPF record at goldmark.org designates 66.111.4.25 as permitted sender)
Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41])
by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 2D1FD20978
for <[email protected]>; Sat, 16 Feb 2013 10:47:20 -0500 (EST)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
by compute1.internal (MEProxy); Sat, 16 Feb 2013 10:47:20 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=goldmark.org; h=
from:content-type:message-id:mime-version:subject:date
:references:to:in-reply-to; s=mesmtp; bh=7K/7amQEcl8CxjAVy5F/f1Q
CFpk=; b=sDijbZFmDt55Tckye+c+tcRID0wCiP6R/N7pIPMXpJaefdC9ZMGvCPo
d53jr3XPLjVFpAyMd6v8VUgFliZhxf/NosBX9l/NFyKghdpaI3XaxlE4F6RH+j2S
S4AIxDiPnUYHJh28w2kFvWd3ef7Eku841xvNHWbUaqurC3KKC9rk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
messagingengine.com; h=from:content-type:message-id:mime-version
:subject:date:references:to:in-reply-to; s=smtpout; bh=7K/7amQEc
l8CxjAVy5F/f1QCFpk=; b=Y6kYSFn7RiWUtNvHSnC9OBsfSAljpls8RLbCYlUij
tJsVzHCXg01UxfkQyAY/nZijDYQJz24hjSU6E8eICgVt/vgIc5vLIt9PUqnWAWqe
N/gj350XNOJVtdvvp74IfZQboDrqQhocGVq2SPN2lj/TVydvMcMr6LSj47GRkImZ
xA=
X-Sasl-enc: uV/ao0rUlpOiwQeWmEyUWpsuezh8IFDW20Ko5ziNu63E 1361029639
Received: from [10.137.0.26] (unknown [23.20.101.138])
by mail.messagingengine.com (Postfix) with ESMTPA id 9C0F5482624
for <[email protected]>; Sat, 16 Feb 2013 10:47:19 -0500 (EST)
From: Jeffrey Goldberg <[email protected]>
Content-Type: multipart/signed; boundary="Apple-Mail=_0EA9298F-527A-4BEA-BF13-FB98241154DA"; protocol="application/pkcs7-signature"; micalg=sha1
Message-Id: <[email protected]>
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Date: Sat, 16 Feb 2013 09:47:18 -0600
References: <[email protected]>
To: "[email protected]" <[email protected]>
In-Reply-To: <[email protected]>
X-Mailer: Apple Mail (2.1499)
Subject: Re: [PHC] Answered: History question
--Apple-Mail=_0EA9298F-527A-4BEA-BF13-FB98241154DA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Feb 15, 2013, at 3:56 PM, Jeffrey Goldberg <[email protected]> =
wrote:
> To what extent is it fair to write "the PHC grew out of discussion =
from #passwords12" ?
Thank you everyone who responded. The answer is that PHC did not evolve =
out of discussion at #passwords12.
I''m glad I asked.
Cheers,
-j
--Apple-Mail=_0EA9298F-527A-4BEA-BF13-FB98241154DA
Content-Disposition: attachment;
filename=smime.p7s
Content-Type: application/pkcs7-signature;
name=smime.p7s
Content-Transfer-Encoding: base64
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMYDCCBWow
ggRSoAMCAQICEAUsQ0Zoth21zr3tmEkHHA8wDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMzAxMDEwMDAwMDBaFw0x
NDAxMDIyMzU5NTlaMIIBFzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh
bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2
aWNlMRkwFwYDVQQDFBBKZWZmcmV5IEdvbGRiZXJnMSMwIQYJKoZIhvcNAQkBFhRqZWZmcmV5QGdv
bGRtYXJrLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOvq3f2egwTyS3lokjD7
i8R3AXPFw+qPHbIhrmoAenCnG02a1zbgEdLSJm+JM9uawV9KnkBES3fix+bX4R/1sf9LS0NGbfGD
sh+zLoKwUrkJdyUJOGwiCy2IKoWNEXEKKxxfqzicVZV21gbq+ae3eftCbEd8jNHplIBbXHufdCIE
3qK6wAybuhmz8oY3SieJ0GkE1Tk+nY2Vjq6DkR03lhQaBmVUPXIQoMZapvvPslwI6brIfnGCPxq+
JuIfTxgT9Ov9Ta1C3j/7ZojPu/SElFo5Y7gKOyFvTOoTCXPmx/lPfxlxT0ltbTefOy7bPkxJS/W5
h6CS3TwjYFj0Fw7MnXMCAwEAAaOB6DCB5TAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4
RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E
BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBQGCmCGSAGG+EUBBgcEBhYETm9u
ZTBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQtZzMtY3JsLnZlcmlzaWdu
LmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQADggEBAL5teo2eDuKR9nvw
HwnUNxMtgydljXGSQLiJIpzzAJAeN+cjmuwTy3i4RKZNJD8y6evsiW1Xofg+yKCJ+/S2dTHaUgmv
EAPzUIVaJsMJsqpChZyYPE8d45FSlq3jMLvgOCgq1Qqww3JrUE9wV0SVCymDAnl20nZwz3/S6VW7
mMvl9JWnesngfxjhdC3ack+82L/qIEMoHlm0CR1qvFb0gxBX5GAQuaRnZPv/BX/zmHoixnnSI7nc
wv+6rdwAEogFgcFIsuSwjnx6FEKb6nXQ6JWhN/1A1uXWzgAnjt7413eiAEyrujZDXtqGQK88yJh6
+Fn65Jn4B87PL+crC53oe+8wggbuMIIF1qADAgECAhBxFWYFSuSRIU3pvET5rNPcMA0GCSqGSIb3
DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT
FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMu
IC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0wOTA1MDEwMDAwMDBa
Fw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x
HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBh
dCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5v
dCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3Jp
YmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtxEffKigdfAZru9ch
MslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+P8aRCbtMNJ6NbqGCUWL3
aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZtKRSXvS3aiUcZiNhLBD3r
tjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrYbKlHwVQpZUM+SsCWH8Gt
93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJIGnfy1VAnminTlvso9bok
dmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGG
GGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEAMHAGA1UdIARpMGcw
ZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL2Nw
czAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1UdHwQtMCsw
KaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3JsMA4GA1UdDwEB/wQEAwIB
BjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAfMAcGBSsOAwIaBBRLa7ko
lgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5jb20vdnNsb2dvMS5naWYw
LgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0OC0xMTgwHQYDVR0OBBYE
FHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0wgcoxCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug
b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFAAOCAQEA
OU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hjWmf+NYUrocNdo0rCOhnd
MNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVyF+X8Kl2H04oNwtFFKvjA
9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUkZkxdkR92sxc+fw3GIYkv
sze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4xcQaH+mxZUy7X3yvtX2MA
rBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHyMIHdMQswCQYDVQQGEwJV
UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv
cmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh