Cryptography-Digest Digest #410, Volume #14 Tue, 22 May 01 18:13:00 EDT
Contents:
Re: survey (Ichinin)
Re: "computationally impossible" and cryptographic hashs (Ichinin)
Decrypt magneti card
Re: survey ("Tom St Denis")
Re: RSA private key size ("Tom St Denis")
ECB plus padding instead of CBC? ("Julian Morrison")
Re: DES ENCRYPTIOn:64-bit key ("Simon Johnson")
Re: A simple encryption algorithm based on OTP ("Simon Johnson")
Re: ECB plus padding instead of CBC? ("Tom St Denis")
Re: Best, Strongest Algorithm (SCOTT19U.ZIP_GUY)
Re: survey ("Tom St Denis")
Re: survey ("Tom St Denis")
Re: ECB plus padding instead of CBC? ("Julian Morrison")
Re: A difficult cryptogram ("jonas jakobsson")
Re: ECB plus padding instead of CBC? ("Tom St Denis")
Re: survey (Paul Rubin)
Re: survey ("Tom St Denis")
----------------------------------------------------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: survey
Date: Fri, 18 May 2001 10:31:22 +0200
Tom St Denis wrote:
<SNIP>
f) I like surveys.
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: "computationally impossible" and cryptographic hashs
Date: Fri, 18 May 2001 10:47:39 +0200
Daniel Graf wrote:
> Does "computationally impossible" mean literally that such a
> thing cannot happen?
If the attacker is equipped with a large dictonary and your users
haven't gone through basic security training (i.e. Why is "password"
a bad password?), it is possible. (Note: it still takes a little while
to spin through the dictionary file though.)
Finding hashes of "*&_YF|7A8)AfX['å" are way harder than "password",
but "password" is easier to remember, hence security is ultimately
broken by users poor choise of passwords.
/Ichinin
------------------------------
From: <[EMAIL PROTECTED]>
Subject: Decrypt magneti card
Date: Tue, 22 May 2001 21:36:21 +0100
Hi i need help i need one program or explain for decod credit cardīs and i
want to now what model i have to buy to read and write magnetic cardīs
(hardware)
Anyone explaine me the schematics for this situation.
Sorry my english .:)
please send me mail
[EMAIL PROTECTED]
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: survey
Date: Tue, 22 May 2001 21:02:28 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> > Is the reason I get zero feedback on my papers ...
>
> None of the above. I don't comment because I don't want
> to spend time looking at new ideas for building cryptosystems.
> It is easy to generate those. What is hard is finding ways
> to attack cryptosystems. Building them is a waste of time
> if they don't provide something new, e.g. resistance to a
> previously overlooked attack.
Well my design is simple and faster than most other known block ciphers.
Does that count?
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: RSA private key size
Date: Tue, 22 May 2001 21:07:11 GMT
"Morten Primdahl" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> Thanks for the replies. What are the odds that there's
> more than one valid private key in the entire keyspace
> (in a proper implementation)?
>
> I've tested the validity of my implementation for small
> encryptions (eg. 16 bit), and I experience several matches
> when I test all keys in the keyspace. I'd assume this to be
> a modulo problem, but I'm certain that my block size
> is smaller than my key strength. Here's what I do:
By private key I assume you mean the decryption exponent?
Well any value such that
de = 1 mod lcm(p-1,q-1)
Is a valid value. That includes multiples of lcm(p-1,q-1) ... i.e if p=3,
q=7, then lcm(p-1, q-1) is 6. If e=5, then d=5 (note e!=3), but also 6a + 5
is a proper key..
Tom
------------------------------
From: "Julian Morrison" <[EMAIL PROTECTED]>
Subject: ECB plus padding instead of CBC?
Date: Tue, 22 May 2001 22:09:06 +0100
Will this work? I have a block cypher, say Rijndael, which has an input of
16 bytes. I use the first 12 of those bytes for data and fill the last
four from /dev/urandom.
The intent is to avoid CBC, so that any 16 byte data chunk can be
separately decoded despite missing data chunks.
Is this a good approach? What security do I lose from this (if any)?
--
I like e-gold. Digital currency based 100% in real physical gold.
This link ( http://www.e-gold.com/e-gold.asp?cid=281798 ) takes you to
their site and shows me as the introducer if you open an account.
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: DES ENCRYPTIOn:64-bit key
Date: Tue, 22 May 2001 22:12:49 +0100
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:jRTN6.145187$[EMAIL PROTECTED]...
>
> "Simon Johnson" <[EMAIL PROTECTED]> wrote in message
> news:9e90um$35t$[EMAIL PROTECTED]...
> >
> > ritesh <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > Hi:
> > >
> > > Can anyone help me in the development and source code of a 64-bit DES
> > > PRNG key..
> > >
> > >
> > > Regards
> > > Ritesh
> > >
> >
> > Make no difference (except to an exhaustive search) to the complexity of
> > breaking DES. With the required known-plain-text the cipher will still
be
> > breakable with the same work because the attack assume the round-keys
are
> > random anyway.
> >
> > But if your really want to design a new key-shedule.. you'll prolly want
> > something like an LFSR or something along those lines.
>
> The original poster was discussing using DES as a PRNG which is perfectly
> possible using a CTR mode.
>
> As for key schedules LFSRs are generally bad ideas since they are ...
LINEAR
> ... which means given some subset of the entire round keys a linear
> dependency may be problematic.
>
> Tom
As far as I was aware, linearness in key-schedules is not exploitable...
though this is probably not the case. I'll further/correct my suggestion and
make the LFSR self-shrinking... this should be sufficiently non-linear.
Simon.
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: A simple encryption algorithm based on OTP
Date: Tue, 22 May 2001 22:26:33 +0100
> George W. Bush is the weakest link...guh bye.
You know Anne rawks =)
As for bush, he's prolly doesn't know where the toilet is let alone
europe... =)
Simon.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: ECB plus padding instead of CBC?
Date: Tue, 22 May 2001 21:26:35 GMT
"Julian Morrison" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Will this work? I have a block cypher, say Rijndael, which has an input of
> 16 bytes. I use the first 12 of those bytes for data and fill the last
> four from /dev/urandom.
>
> The intent is to avoid CBC, so that any 16 byte data chunk can be
> separately decoded despite missing data chunks.
>
> Is this a good approach? What security do I lose from this (if any)?
Not a good idea. It's harder to exploit but there is a better method.
Just encode a binary counter so you can seek etc..
Tom
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm
Date: 22 May 2001 21:40:00 GMT
[EMAIL PROTECTED] (John Savard) wrote in
<[EMAIL PROTECTED]>:
>
>>At one point you specifically stated that BICOM could
>>output a single byte output that was Rijndael encrypted, that always
>>has been, and always will be the problem.
>
>But that _is_ possible. Just use counter mode, for example. I agree
>you can't use ECB mode, or CBC mode, to produce a one-byte
>Rijndael-encrypted output. But other modes allow one to encipher
>messages in fractions of a block, although they may require an IV the
>size of a block in addition.
>
Mr J. You seem to be big on theroy but I never see code at your
site. BICOM does use RIJNDAEL in full block mode. Obviously its
not your NSA approved variation of CBC but its a carefully mated
bijective compression encryption combination. I suppose you
think it doesn't work. Sorry but the weak CTR mode does not give
full bijectiveity like BICOM. If you use straight weak CTR mode
and tried to make it bijective which it really is not you have two
major problems that the big boys don't address.
1) Your encryptying consecutive values for the input block namely
ctr then ctr+1 ... Which requires a unque starting value for each
message or the one time pad probken occurs. And the very fact of
using consecutive values is giving a big plus to the NSA boys in
breaking this weak chaining mode.
2) Its not bijective anyway. Proof take the stupid method as proposed.
Suppose you have a one byte output file. What could the input have
been? The anwser is only one of 256 values. Not to good. Who cares
what the real key was you only have 2**8 possibliites.
Compare this to a real bijective encryption BICOM which actaully
uses a modifed impedanced mathc CBC mode. For a one byte output
file. Any key could have been used. Meaning that there are 2**256
possible messages that could have been the original files. So for
this simple example CTR suck big time since I think you can even
see that 2**256 is a little more secure than 2**8. Or at least I
hope you can see that.
The big boys will deny problem one exists. Yet that there is
a simple realationship between blocks is undeniable.
THe second is a problem they we say exists in only small files.
Meaing they don't really want to look at the problem and want
you to use weak chaining.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: survey
Date: Tue, 22 May 2001 21:41:04 GMT
"Surendra Rana" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I haven't been on to this newsgroup until today, when I am looking for an
urgent
> help with my RSA PKCS1 (rfc 2313) encryption process.
> But I have found your help, answers, ideas very informative and
interesting.
> keep it up, your good work for this group.
Thanks. I think I should work more on my "Tack" (is that how you spell it?)
than my Analysis skills.. heheheh
BTW If you wnt info on PKCS goto RSAs website!
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: survey
Date: Tue, 22 May 2001 21:43:34 GMT
"Pascal Junod" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Tue, 22 May 2001, Tom St Denis wrote:
>
> > Is the reason I get zero feedback on my papers (other than when my ideas
are
> > obviously stupid) (and other than stuff by Scott Fluhrer) because?
> >
> > a) This "tom" guy is a crank and I don't want to read his stuff.
> > b) This "tom" guy is a retard and what he writes makes my 12 yr olds
laugh
> > c) I read his stuff but I don't want to comment.
> > d) I read his stuff but I can't think of anything to comment
> > e) I read his stuff and do comment and tom just doesn't listen or
forgot.
> > f) I like surveys.
>
> g) Most of us are quite busy and don't have enough time to read carefully
> what you write.
Which is ironic because I know with 90% certainity that you have downloaded
all my papers including MDFC, NA and TC15 ...
Do you just download them and not read them?
I don't want to be pushy, I know you guys are busy (I am out of the house
most of the day too). But most of my papers are under 15 pages (in fact all
my LaTeX formated papers are 15 or under) so they should only take about 10
mins to read. Comments don't always have to be "here is a detailed
dissertation of your paper" Just "neat keep it up" or "I don't like it" or
"thank god for recycling" would be nice. Just short comments if possible.
Tom
------------------------------
From: "Julian Morrison" <[EMAIL PROTECTED]>
Subject: Re: ECB plus padding instead of CBC?
Date: Tue, 22 May 2001 22:47:42 +0100
"Tom St Denis" <[EMAIL PROTECTED]> wrote:
> "Julian Morrison" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
>> Will this work? I have a block cypher, say Rijndael, which has an input
>> of 16 bytes. I use the first 12 of those bytes for data and fill the
>> last four from /dev/urandom.
>>
>> The intent is to avoid CBC, so that any 16 byte data chunk can be
>> separately decoded despite missing data chunks.
>>
>> Is this a good approach? What security do I lose from this (if any)?
>
> Not a good idea. It's harder to exploit but there is a better method.
>
> Just encode a binary counter so you can seek etc..
I don't follow.
The intended use in secure and small-as-possible UDP-alike datagrams,
where no amount of dropped messages will stop decryption of those
successfully recieved, immediately they arrive. In this circumstance it
would be quite possible to recieve a data chunk and neither the one
preceding nor the one following, or entirely out of sequence, so no simple
XOR chaining will work.
--
I like e-gold. Digital currency based 100% in real physical gold.
This link ( http://www.e-gold.com/e-gold.asp?cid=281798 ) takes you to
their site and shows me as the introducer if you open an account.
------------------------------
From: "jonas jakobsson" <[EMAIL PROTECTED]>
Subject: Re: A difficult cryptogram
Date: Tue, 22 May 2001 23:47:50 +0200
Check the FAQ for the answear
"daniel gerard mcgrath" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
> Can anyone try to decipher this message? Does anything look familiar?
> The solution is a well-known poem.
>
> 74401 47111 40125 11701 12908 26061 63347 17069 42565 00164
> 45116 40912 11711 13154 58565 10900 01626 01541 62685 06890
> 33433 20521 09014 60650 01909 16567 11144 72235 32053 94143
> 13177 05019 45111 23131 90069 46635 11050 62632 05741 14471
> 10153 90506 03153 60146 74071 67456 61005 67111 43145 11123
>
> 13161 13140 44143 14006 69042 61001 64445 15603 21511 13330
> 26114 86131 61461 34324 03729 47600 13566 76941 00201 12532
> 15111 33325 60026 50502 45046 70320 55663 51430 61306 15050
> 23130 19805 05610 02391 69065 67404 26102 54670 45430 08540
> 10863 04014 36700 29425 65109 17240 40256 42087 15111 43120
>
> 64085 66910 61001 42074 01433 37820 50509 35395 11121 12572
> 44126 86101 54401 47111 37074 01430 16509 45245 11146 63005
> 54662 44268 66315 12016 60142 90543 14075 65151 11442 91740
> 14365 05027 11626 89159 02566 50661 71113 90740 24040 25604
> 31206 90529 51114 00685 70436 14037 10942 00806 71113 67890
>
> 62652 88221 00467 24051 35609 06511 36546 94256 51661 01540
> 53988 74005 14332 05069 26686 15456 61002 75601 30459 00093
> 20600 74162 66661 32511 01005 13251 17403 21862 63202 12664
> 66351 10083 40716 14066 10263 36066 44536 34234 48010 05615
> 62140 61550 38630 00473 76515 13519 58900 26690 50603 54743
>
> 14301 13057 11010 06005 16144 26340 74584 41436 90256 92204
> 56010 05256 86133 90426 10020 26615 45901 25010 05050 43612
> 57111 37194 00045 65109 41003 61143 51094 10020 11435 10945
> 82050 11430 10058 13714 02400 40676 72400 45762 25400 55402
> 03620 50203 63409 56515 24511 14524 15295 11141 54306 17245
>
> 11145 24152 95111 46504 36510 94100 36101 65092 50142 50850
> 92501 42508 50920 43601 41139 36120 80669 02507 01129 08267
> 11146 62810 59164 33020 50316 69466 11404 02569 37614 54434
> 02505 10516 90001 42647 45715 40545 11144 41867 45790 54511
> 13154 58567 24171 11240 91644 14369 02569 28614 69434 02902
>
> 56666 13251 11914 36529 52486 50502 69050 60315 36014 72405
> 05027 11140 13000 74432 07433 01031 11206 25540 40256 64072
> 95111 41620 50132 05005 02550 86301 05276 00126 63407 16131
> 54057 06622 62686 30198 25050 20100 58506 90784 01301 00135
> 45702 11094 51511 12313 19006 94472 06031 53601 40504 56863
>
> 51100 07457 02256 85065 56266 85610 01643 30095 82935 38133
> 61120 11523 13359 07450 05022 63406 65451 11448 56626 00844
> 50064 01342 56116 63511 01425 66505 02674 09000 09150 24265
> 29524 86611 31002 16677 05240 11335 10014 00202 25644 07351
> 25432 71205 56102 42663 47890 54114 01301 02634 55006 52634
>
> 14814 42746 90256 94544 32074 26105 63410 61914 26661 54667
> 66439 31335 31126 41485 66264 32714 35441 44263 45108 56432
> 71200 61143 64826 34113 53643 63407 16139 09171 18506 55620
> 87157 66315 12004 09401 00571 11211 20625 52813 35313 21650
> 65069 42635 06014 71114 45109 47111 44741 47727 05631 13113
>
> 11361 15125 11713 01133 90126 71101 00571 11444 73513 35065
> 01332 36125 26342 56002 43271 20882 60151 12562 50100 01640
> 50104 00112 05020 08340 71614 35457 02026 43694 51101 53615
> 40658 61140 11136 01560 25610 83151 20040 94429 56652 84136
> 44825 68506 53175 10480 10055 66769 10133 10290 37364 48536
>
> 10342 70502 31601 56025 61166 11401 34016 61318 30376 35065
> 28986 56427 08630 15528 13356 92601 00501 54433 90528 13361
> 12011 45407 05008 06456 72355 10943 11002 51090 26301 07225
> 62600 22566 77351 40245 00874 31009 17441 40406 90620 31029
> 07231 33945 43400 20216 28426 10016 44511 14472 23532 05390
>
> 25651 54164 00611 66351 10065 66350 10054 20933 01026 34163
> 01014 30143 05140 58133 71085 60100 52136 13010 01022 57790
> 25606 13190 06931 14354 41311 44582 05054 05313 38661 32511
> 72313 39012 04600 16060 16613 39042 60100 50165 09451 11480
> 08428 61466 63151 45111 25546 71057 07113 39042 60459 03111
>
> 20625 26291 47066 00617 66262 56113 54606 54590 52943 10290
> 25057 96061 63347 17069 05204 36010 05722 04360 05240 55506
> 1029
>
> --------------------------------------------------
> daniel g. mcgrath
> a subscriber to _word ways: the journal of recreational linguistics_
> http://www.wordways.com/
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: ECB plus padding instead of CBC?
Date: Tue, 22 May 2001 21:56:21 GMT
"Julian Morrison" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Tom St Denis" <[EMAIL PROTECTED]> wrote:
>
> > "Julian Morrison" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> >> Will this work? I have a block cypher, say Rijndael, which has an input
> >> of 16 bytes. I use the first 12 of those bytes for data and fill the
> >> last four from /dev/urandom.
> >>
> >> The intent is to avoid CBC, so that any 16 byte data chunk can be
> >> separately decoded despite missing data chunks.
> >>
> >> Is this a good approach? What security do I lose from this (if any)?
> >
> > Not a good idea. It's harder to exploit but there is a better method.
> >
> > Just encode a binary counter so you can seek etc..
>
> I don't follow.
>
> The intended use in secure and small-as-possible UDP-alike datagrams,
> where no amount of dropped messages will stop decryption of those
> successfully recieved, immediately they arrive. In this circumstance it
> would be quite possible to recieve a data chunk and neither the one
> preceding nor the one following, or entirely out of sequence, so no simple
> XOR chaining will work.
Um, read up. CTR doesn't use chaining.
The idea works like this.
1. Start a binary counter at 0, call it I
2. For each new block increment I and encrypt it with the key. Call the
ciphertext of the counter C1.
3. Take the message block and xor it against C1.
4. Go backto #2 as needed.
The nice thing is that you can seek with this method since you use the block
cipher regardless of the message being encoded. So you simply use a 128-bit
counter for all your UDP packets (or blocks within them) and as long as you
don't reuse counter values the method is secure (asuming all else is ok like
random keys, etc...)
Tom
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: survey
Date: 22 May 2001 15:00:07 -0700
"Tom St Denis" <[EMAIL PROTECTED]> writes:
> Well my design is simple and faster than most other known block ciphers.
> Does that count?
No.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: survey
Date: Tue, 22 May 2001 22:09:49 GMT
"Paul Rubin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Tom St Denis" <[EMAIL PROTECTED]> writes:
> > Well my design is simple and faster than most other known block ciphers.
> > Does that count?
>
> No.
Why not? It seems to be a hot topic amongst "crypto gods".
Oh I know it's because I am a kid and you don't have the time... gah...
At least my paper includes some analysis... the paper isn't done though. My
goal is to break the sucker not replace AES. I've broken 5 out of the eight
rounds... I can't seem to get any further. My attacks are not very
sophisticated though...
Tom
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
