Cryptography-Digest Digest #2, Volume #11 Sat, 29 Jan 00 16:13:00 EST
Contents:
ascii to binary ("Chris Engstrom")
Re: NIST, AES at RSA conference (Terry Ritter)
Re: NIST, AES at RSA conference ("A [Temporary] Dog")
Re: Block chaining ("Adam Durana")
Re: "Trusted" CA - Oxymoron? (wtshaw)
Re: How to password protect files on distribution CD ("John E. Kuslich")
Re: ascii to binary (Keith A Monahan)
Re: How to password protect files on distribution CD ("John E. Kuslich")
Re: ascii to binary ("Jonas")
Re: Strong stream ciphers besides RC4? (Gregory G Rose)
Re: NIST, AES at RSA conference ("Joseph Ashwood")
Re: Help needed on peculiar use of cryptography (David Wagner)
----------------------------------------------------------------------------
From: "Chris Engstrom" <[EMAIL PROTECTED]>
Subject: ascii to binary
Date: Sat, 29 Jan 2000 13:13:12 -0600
I am having difficulty converting (visually) ascii to binary.
for learning purposes, i want to take some text and print it out in binary.
What i will then do is manipulate the text and compare the binary
differences. I have been trying to do this in C with no luck.
I was wondering if anyone could point me in the right direction?
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: NIST, AES at RSA conference
Date: Sat, 29 Jan 2000 19:41:51 GMT
On Sat, 29 Jan 2000 17:42:33 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (John Savard) wrote:
>On Fri, 28 Jan 2000 00:09:44 GMT, [EMAIL PROTECTED] wrote, in
>part:
>
>>But where is the proof that the adversary will have to
>>attack it that way? If in fact he has a general solution,
>>then the argument is irrelevant. Does adding additional
>>cipher layers seem stronger? Absolutely. Does it help us
>>prove strength? No, at least it hasn't yet.
>
>If the only response to a situation where "we lack proof" is to find
>some way to get proof, your objection would be fatal.
>
>However, if "we can't get proof" is also considered as a reason to,
>failing some way to obtain proof, try to at least do everything we can
>to make our ciphers stronger - without proof that we have done enough,
>without the knowledge whether or not we may have done more than is
>necessary - then things like Mr. Ritter's multi-ciphering are entirely
>sensible responses to the situation.
Look, I'm not going to debate with that guy, since I know from long
experience that it would be a waste of time. But I am surprised those
debating do not address his logic.
Background: In the middle ages, alchemists sought what they called
"the philosopher's stone." This was not really a stone, but instead a
mythical alchemy product which could somehow transform any substance,
instantly and magically.
The Counterargument: There may exist a "cryptographer's stone" which,
by some wave of the hand, will decipher any possible cipher. So *if*
a "cryptographer's stone" exists, *then* using multiple ciphers would
*not* be stronger than using just one.
The effectiveness of the counterargument thus rests on whether we can
be forced to accept the myth of a "cryptographer's stone" in rational
argument.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "A [Temporary] Dog" <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Sat, 29 Jan 2000 14:45:16 -0500
On Sat, 29 Jan 2000 18:58:21 +0000, CLSV <[EMAIL PROTECTED]> wrote:
>John Savard wrote:
>
>> Being able to say that a given cipher can't be broken requires one to
>> know all the ways that a cipher could possibly be attacked, and to
>> have checked them all, and found them all to be ineffective.
>
>If breaking a cipher is equivalent to solving (a hard
>instance of) a problem in NP and someone would prove
>that P != NP then the cipher can not be broken with
>polynomial effort.
A big if. Perhaps I'm missing everthing, but I thought the whole
point of the thread was that we had no way of knowing that, in your
words "breaking a cipher is equivalent to solving (a hard instance of)
a problem in NP."
- A (Temporary) Dog |"Intelligent, reasonable
The Domain is *erols dot com* |people understand that -
The Name is tempdog |unfortunately, we're dealing
http://users.erols.com/tempdog/ |with elected officials"
Put together as name@domain | - name withheld
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: Block chaining
Date: Sat, 29 Jan 2000 14:49:50 -0500
> Interesting. But do you have any applications in mind where this mode
> provides a compelling advantage over the standard chaining modes?
I am thinking mostly file encryption.
> One disadvantage is that one must have the entire ciphertext in memory
> before one can start decrypting, so this is not very suitable for
streaming
> applications. For non-streaming applications, the performance overhead
may
> be problematic.
Well no you don't have to have the entire ciphertext in memory to decrypt
it. If it is a file you would just have to start from the end and work your
way backwards. But this is not ideal, I know. In other applications you
would have to have all the ciphertext in memory, but when thinking about
chaining method I was planing on using it mostly for file encryption.
> Also, the space overhead of your method is slightly larger (256 bits;
> standard methods waste 128 bits). This is irrelevant for large messages,
> but might be problematic if you frequently encrypt short ones.
I don't see what you are talking about. Are you refering to the space that
would be needed for padding? If so no space at all is required if you just
stop encrypting when there is no more plaintext since the data left is
already encrypted. Or you could keep encrypting the same buffer, say you
have 128 bit block size and a "small block size" of 8 bits, you would just
encrypt the buffer 16 times (128 / 8). But the latter seems some what
pointless since the buffer is already encrypted and there is no new data
being added to the buffer.
> It's not clear to me why you want to spread data across everything after
> itself, but I'll note that many of the standard chaining modes also
provide
> this property, if you prefer it. (But one should not rely on this
property
> for message authentication purposes.)
Its ideal to spread data across the whole file, it hides redundences in the
plain text. David Scott brought up an idea I was also thinking about, if
you encrypt a file from the beginging to the end with this method then
encrypt it from ending to beginging then you would spread the data across
the whole file. I know other chaining methods spread data across the output
such as CBC, but even though it has not been proven that CBC itself gives a
cryptanalysist extra information, I am still not to crazy about mixing data,
that a cryptanalysist will have, with the plaintext that is being encrypted.
I guess I'm just paranoid.
> As always, you'll probably want to use this with a random IV, because
> otherwise stereotyped header sequences will show through in the
ciphertext.
Yes you would want to use an IV, and it would be just like using an IV in
any other chaining method, just make your first block of plaintext the IV.
Thanks for the comments.
- Adam Durana
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To:
alt.privacy,alt.security.pgp,comp.security.pgp,comp.security.pgp.discuss
Subject: Re: "Trusted" CA - Oxymoron?
Date: Sat, 29 Jan 2000 12:45:13 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Topher) wrote:
>
> They don't even care about that. What they care about is that any
> transactions they make (transfers of money on your orders) aren't
> repudiated in such a way that they have to take the loss.
>
Then, the goal is to eliminate losses? It seems that banks figure that
they and other can have no losses, but that is a dream. In search for
permanence and absolute identity, too many get away from the adventure
that it is to be alive. Even with the best intentions, things don't always
work out as planned, for businesses, for individuals, for investors.
So, the attention is on when things go wrong, not when things go right. If
a trust is broken, things go wrong, either before, during, or after the
fact; it might be somebodys fault, or it might be due to circumstances
beyond anyone to foresee. In as mcu as there is trust, it may be merely
ones trust in the futre that is not fulfilled.
It is easier to try to blame than to take a share of loss. The question
is that if a bank was willing to take a risk in the first place, why
should it complain later. If taken in, they are not as smart as they
should have been, and whose fault is that?
It is wrong to commit fraud, but not wrong to find adverse circumstances.
The later might lead to the former, and should be dealt with up front by
government serving people rather than leading or forcing some to crime.
Now, who is at fault when a person is given no better choice to survive?
That is a hard question. Helping people is the right thing to do,
regardless of whether you see an immediate profit in it. Businesses exist
at the pleasure of a society with needs. Giving people bad options cause
problems that cannot be swept away by seeking to blame the same victims.
There is something wrong with people who fight agaist birth control while
cutting or denying assistance to those who have no other realistic choice
than child abandonment or abortion.
--
About injustice, the stronger I get the meaner I feel, or is it the
other way around. Do not respect sacred cows that seek to trample you while preaching
about the good they do.
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.unix,comp.security
Subject: Re: How to password protect files on distribution CD
Date: Sat, 29 Jan 2000 13:02:18 -0700
I concur.
If you read the writings of +ORC and his ilk, you will soon discover
that the goal cannot be achieved. What ca be done in software can be
un-done in software! Even the much touted dongles have been cracked.
Resistance is futile, give up.
JK
Johnny Bravo wrote:
>
> On Fri, 28 Jan 2000 18:02:17 -0800, GJJ
> <[EMAIL PROTECTED]> wrote:
>
> >BTW - I have no personal or professional interests in the above
> >companies and have not tried any of their products so I can't vouch for
> >them...
>
> I can; copy protection can't.
> There is no possible copy protection that can't be recopied or bypassed.
> If nothing else than by distributing the encrypted files with a valid
> decryption key. For those silly schemes where the customer's name is used
> to make an encryption key, a key generator is easy enough to reverse
> engineer as the program has to take the customer name, compute the same
> key to compare it against the entry. Anything the computer can do, a
> cracker can duplicate, then put it into a program that does the same
> calculations and generates the keys.
> For larger and more complicated programs, for some it will be worth the
> cost to purchase a bound manual and tech support. Some companies are
> offering an outstanding product for free and making money of the support,
> ala Sun Systems and the massive package Star Office.
>
> Best Wishes,
> Johnny Bravo
--
John E. Kuslich
Password Recovery Software
CRAK Software
http://www.crak.com
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: ascii to binary
Date: 29 Jan 2000 20:09:06 GMT
Hi Chris,
Let me be a little more careful and generic, and say this is how
to convert from DECIMAL -> BINARY. ASCII is usually just a 8-bit
binary representation of letters, numbers, symbols, characters, etc.
Most of the time, we see ASCII characters within C expressed as
unsigned integers.
Let's say we have the ASCII letter A, it's decimal equivalent is 65.
What we do is we write some numbers representing 8 different positions.
Then what we do is we start from the most significant bit (128) and pick
the positions which, when added up, match the decimal equivalent. We turn
those positions ON, by putting a 1 in the position. For positions we
don't use, we simply put a 0.
128 64 32 16 8 4 2 1
0 1 0 0 0 0 0 1
This one was easy, so the binary equivalent of dec 65 is 01000001. Notice
I picked to turn on 64 and 1, so 64 + 1 = 65.
Let's do a harder one.
Let's convert the letter Z, it's decimal equivalent is 91.
128 64 32 16 8 4 2 1
0 1 0 1 1 0 1 1
so the binary equivalent of 91 is 01011011. I picked to turn on
64 + 16 + 8 + 2 + 1 = 91. Notice that step by step what you are doing is
this.
Step 1. Is the bit position value larger than my remainder? if so, go
to step 3. If not, turn on that bit(ie use that position).
Step 2. Subtract bit position value from current remainder & make that
the new remainder.
Step 3. Move to the next bit position.
Step 4. if remainder = 0 you're finished
Step 5. go to step 1
I know this is a little off-topic, but I hope that helps.
Keith
P.S. You can use windows95/98 calculator application to see if you get
the correct answer when doing it manually. Just remember that calc
will chop of the leading 0's...
Chris Engstrom ([EMAIL PROTECTED]) wrote:
: I am having difficulty converting (visually) ascii to binary.
: for learning purposes, i want to take some text and print it out in binary.
: What i will then do is manipulate the text and compare the binary
: differences. I have been trying to do this in C with no luck.
: I was wondering if anyone could point me in the right direction?
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.unix,comp.security
Subject: Re: How to password protect files on distribution CD
Date: Sat, 29 Jan 2000 13:09:31 -0700
Dongles are routinely cracked. If you search the Net you will discover
how.
Likewise, security codes are only a defense against the software
challenged.
We use these codes but must change them constantly to keep up with the
crackers.
There are some obfuscation techniques that will defeat the most often
used cracking techniques under Windows but a good cracker will
eventually see his way around them.
JK
--
John E. Kuslich
Password Recovery Software
CRAK Software
http://www.crak.com
Dave Mundt wrote:
>
> I concur. Hence the reason that SOME companies resort to the
> hardware solution of a "dongle", a hardware key that hangs off the
> parallel port and is queried by the software to see if it can run.
> These things are an adequate solution, but, inconvenient for the
> user, and, are guarenteed to shut them down when damaged. Also,
> although the technology workes pretty well now, there can be conflicts
> that make it hard to print through these devices.
> I wonder, though, WHY you think this is necessary? It would be
> much simpler to distribute the software, and, like most other software
> packages, require a license number to be entered before it can install
> or run.
> Seems to work for Microsoft well enough...
> Regards
> Dave Mundt
>
> Johnny Bravo <[EMAIL PROTECTED]> wrote:
>
> >On Fri, 28 Jan 2000 18:02:17 -0800, GJJ
> ><[EMAIL PROTECTED]> wrote:
> >
> >
> >>BTW - I have no personal or professional interests in the above
> >>companies and have not tried any of their products so I can't vouch for
> >>them...
> >
> > I can; copy protection can't.
> > There is no possible copy protection that can't be recopied or bypassed.
> >If nothing else than by distributing the encrypted files with a valid
> >decryption key. For those silly schemes where the customer's name is used
> >to make an encryption key, a key generator is easy enough to reverse
> >engineer as the program has to take the customer name, compute the same
> >key to compare it against the entry. Anything the computer can do, a
> >cracker can duplicate, then put it into a program that does the same
> >calculations and generates the keys.
> > For larger and more complicated programs, for some it will be worth the
> >cost to purchase a bound manual and tech support. Some companies are
> >offering an outstanding product for free and making money of the support,
> >ala Sun Systems and the massive package Star Office.
> >
> > Best Wishes,
> > Johnny Bravo
> >
>
> Remove the "REMOVE_THIS_" from my email address to get to me...
> I hate Cullers who gather from newsgroups
>
> Visit my home page at http://www.esper.com/xvart/index.html
------------------------------
From: "Jonas" <[EMAIL PROTECTED]>
Subject: Re: ascii to binary
Date: Sat, 29 Jan 2000 21:22:18 +0100
Some javascript code, hope you find out how to in C
//********************ASCI 2 DEC****************************************//
function ASCI2DEC(){
k=0;
decut="";
document.asci2dec.decoutput.value= "";
//Fetch ASCI to string
Tstring = asci2dec.textinput.value+" ";
//Convert asci values to decimal
for (m=0;m<Tstring.length-1;++m){thisval=Tstring.charAt(m);
dec = new Object();
decstream = new Object();
if (thisval=="NUL"){save=0;}
if (thisval=="SOH"){save=1;}
if (thisval=="STX"){save=2;}
if (thisval=="ETX"){save=3;}
if (thisval=="EOT"){save=4;}
if (thisval=="ENQ"){save=5;}
if (thisval=="ACK"){save=6;}
if (thisval=="BEL"){save=7;}
if (thisval=="BS") {save=8;}
if (thisval=="TAB"){save=9;}
if (thisval=="LF") {save=10;}
if (thisval=="VT") {save=11;}
if (thisval=="FF") {save=12;}
if (thisval=="CR") {save=13;}
if (thisval=="SO") {save=14;}
if (thisval=="SI") {save=15;}
if (thisval=="DLE"){save=16;}
if (thisval=="DC1"){save=17;}
if (thisval=="DC2"){save=18;}
if (thisval=="DC3"){save=19;}
if (thisval=="DC4"){save=20;}
if (thisval=="NAK"){save=21;}
if (thisval=="SYN"){save=22;}
if (thisval=="ETB"){save=23;}
if (thisval=="CAN"){save=24;}
if (thisval=="EM") {save=25;}
if (thisval=="SUB"){save=26;}
if (thisval=="ESC"){save=27;}
if (thisval=="FS") {save=28;}
if (thisval=="GS") {save=29;}
if (thisval=="RS") {save=30;}
if (thisval=="US") {save=31;}
if (thisval==" ") {save=32;}
if (thisval=="!") {save=33;}
if (thisval=="\""){save=34;}
if (thisval=="#") {save=35;}
if (thisval=="$"){save=36;}
if (thisval=="%"){save=37;}
if (thisval=="&"){save=38;}
if (thisval=="'") {save=39;}
if (thisval=="(") {save=40;}
if (thisval==")") {save=41;}
if (thisval=="*") {save=42;}
if (thisval=="+") {save=43;}
if (thisval==",") {save=44;}
if (thisval=="-") {save=45;}
if (thisval==".") {save=46;}
if (thisval=="/") {save=47;}
if (thisval=="0") {save=48;}
if (thisval=="1") {save=49;}
if (thisval=="2") {save=50;}
if (thisval=="3") {save=51;}
if (thisval=="4") {save=52;}
if (thisval=="5") {save=53;}
if (thisval=="6") {save=54;}
if (thisval=="7") {save=55;}
if (thisval=="8") {save=56;}
if (thisval=="9") {save=57;}
if (thisval==":") {save=58;}
if (thisval==";") {save=59;}
if (thisval=="<") {save=60;}
if (thisval=="=") {save=61;}
if (thisval==">") {save=62;}
if (thisval=="?") {save=63;}
if (thisval=="@") {save=64;}
if (thisval=="A") {save=65;}
if (thisval=="B") {save=66;}
if (thisval=="C") {save=67;}
if (thisval=="D") {save=68;}
if (thisval=="E") {save=69;}
if (thisval=="F") {save=70;}
if (thisval=="H") {save=72;}
if (thisval=="I") {save=73;}
if (thisval=="J") {save=74;}
if (thisval=="K") {save=75;}
if (thisval=="L") {save=76;}
if (thisval=="M") {save=77;}
if (thisval=="N") {save=78;}
if (thisval=="O") {save=79;}
if (thisval=="P") {save=80;}
if (thisval=="Q") {save=81;}
if (thisval=="R") {save=82;}
if (thisval=="S") {save=83;}
if (thisval=="T") {save=84;}
if (thisval=="U") {save=85;}
if (thisval=="V") {save=86;}
if (thisval=="X") {save=88;}
if (thisval=="Y") {save=89;}
if (thisval=="Z") {save=90;}
if (thisval=="�") {save=91;}
if (thisval=="�"){save=92;}
if (thisval=="�") {save=93;}
if (thisval=="^") {save=94;}
if (thisval=="_") {save=95;}
if (thisval=="`") {save=96;}
if (thisval=="a") {save=97;}
if (thisval=="b") {save=98;}
if (thisval=="c") {save=99;}
if (thisval=="d") {save=100;}
if (thisval=="e") {save=101;}
if (thisval=="f") {save=102;}
if (thisval=="g") {save=103;}
if (thisval=="h") {save=104;}
if (thisval=="i") {save=105;}
if (thisval=="j") {save=106;}
if (thisval=="k") {save=107;}
if (thisval=="l") {save=108;}
if (thisval=="m") {save=109;}
if (thisval=="n") {save=110;}
if (thisval=="o") {save=111;}
if (thisval=="p") {save=112;}
if (thisval=="q") {save=113;}
if (thisval=="r") {save=114;}
if (thisval=="s") {save=115;}
if (thisval=="t") {save=116;}
if (thisval=="u") {save=117;}
if (thisval=="v") {save=118;}
if (thisval=="w") {save=119;}
if (thisval=="x") {save=120;}
if (thisval=="y") {save=121;}
if (thisval=="z") {save=122;}
if (thisval=="�") {save=123;}
if (thisval=="�"){save=124;}
if (thisval=="�") {save=125;}
if (thisval=="~") {save=126;}
if (thisval=="DEL"){save=127;}
decut=decut+save;
decut=decut+",";
}
//Output decimal
document.asci2dec.decoutput.value=decut;
}
//********************DEC 2 BIN****************************************//
function decTobin(){
document.dec2bin.binoutput.value="";
decstring = asci2dec.decoutput.value+" ";
dec=new Object;
binut="";
i=0;
m=0;
bit = new Object();
bitstream = new Object();
//For every char(decvalue)
while (m<decstring.length-1)
{j="";
while (decstring.charAt(m)!="," && m<decstring.length-1)
{j=j+decstring.charAt(m);++m}
//Convert decimal to binary
if (j>=128) {bit[8]=1;j=j-128;} else {bit[8]=0;}
if (j>=64) {bit[7]=1;j=j-64;} else {bit[7]=0;}
if (j>=32) {bit[6]=1;j=j-32;} else {bit[6]=0;}
if (j>=16) {bit[5]=1;j=j-16;} else {bit[5]=0;}
if (j>=8) {bit[4]=1;j=j-8;} else {bit[4]=0;}
if (j>=4) {bit[3]=1;j=j-4;} else {bit[3]=0;}
if (j>=2) {bit[2]=1;j=j-2;} else {bit[2]=0;}
if (j>=1) {bit[1]=1;j=j-1;} else {bit[1]=0;}
for (i=8;i>0;--i){bitstream[k+1]=bit[i];binut=binut+bitstream[k+1];}
++m;
}
document.dec2bin.binoutput.value=binut;
}
Chris Engstrom skrev i meddelandet ...
>I am having difficulty converting (visually) ascii to binary.
>
>for learning purposes, i want to take some text and print it out in binary.
>What i will then do is manipulate the text and compare the binary
>differences. I have been trying to do this in C with no luck.
>
>I was wondering if anyone could point me in the right direction?
>
>
>
>
------------------------------
From: [EMAIL PROTECTED] (Gregory G Rose)
Subject: Re: Strong stream ciphers besides RC4?
Date: 29 Jan 2000 12:36:09 -0800
In article <[EMAIL PROTECTED]>,
Uri Blumenthal <[EMAIL PROTECTED]> wrote:
>Stefan Lucks wrote:
>> Daniel Bleichenbacher and Savar Patel have broken SOBER, see
>> Daniel Bleichenbacher and Savar Patel: "SOBER Cryptanalysis",
>> Fast Software Encryption =B499, Springer LNCS 1636.
>
>Yuck! Do you know if the paper is available in softcopy?
I apologise that I don't have the preceding
articles to comment on directly, but anyway...
Comparitively minor tweaks to SOBER fix the
important problems found by Bleichenbacher and
Patel (and independently by Royal Holloway).
We've been doing a lot of research into what we
call "extended guess-and-determine attacks" to
try to understand the exact strength of the
cipher, and are submitting a paper about this
soon [1]. In the meantime, a design paper about
"the t-class SOBER Stream Ciphers" is online at
http://www.home.aone.net.au/qualcomm . This gives
details of 8, 16 and 32 bit wide versions thought
to have strengths of 88, 176, and 352 bits. [2]
[1]: one outcome of this work is a demonstration
that no Linear register based design can ever be
as strong as its total state, which makes statements
about breakability hard to quantify and certainly
not black-and-white. Nevertheless, it's true that
the original SOBER was broken. We don't think the
current version is.
[2]: Free for non-embedded use, we only care about
cellphones and such stuff. Individual export
licenses happily applied for. Currently undergoign
a one-time review for online export (note: from
Australia, not the US).
Greg.
--
Greg Rose INTERNET: [EMAIL PROTECTED]
QUALCOMM Australia VOICE: +61-2-9181 4851 FAX: +61-2-9181 5470
Suite 410, Birkenhead Point http://people.qualcomm.com/ggr/
Drummoyne NSW 2047 B5 DF 66 95 89 68 1F C8 EF 29 FA 27 F2 2A 94 8F
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Sat, 29 Jan 2000 12:54:08 -0000
> If breaking a cipher is equivalent to solving (a hard
> instance of) a problem in NP and someone would prove
> that P != NP then the cipher can not be broken with
> polynomial effort.
As I learned not so long ago, the reality is that does not
quite work. The P != NP proof will likely be single problem
oriented. This is a very important distinction, the proof of
P != NP will mean quite a bit for security, but it will not
be proof against knownplaintext attacks, more work is needed
to protect against that. I think the best example right now
of this is DFC (?), it was the only AES candidate that had a
proof of security against a type of attack, other flaws were
found in the design.
Joe
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Help needed on peculiar use of cryptography
Date: 29 Jan 2000 12:56:58 -0800
In article <[EMAIL PROTECTED]>,
David P Jablon <[EMAIL PROTECTED]> wrote:
> John, don't fool yourself. Given the small space of SS #s, a
> brute-force search will reveal which # matches the hash very quickly.
> The attacker's job is equivalent to cracking a 20-bit key.
>
> That said, there's still value in hashing the #'s to prevent
> efficient large-scale disclosure of the entire database.
I'm not sure even large-scale disclosure is guaranteed to be prevented.
Cracking the entire database can be done as quickly as cracking a single
SS #, unless you're willing to prepend a random salt to each SS #.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
