Cryptography-Digest Digest #636, Volume #9 Tue, 1 Jun 99 23:13:03 EDT
Contents:
Re: 8Bit encryption code. Just try and break it. (Phoenix)
Re: SHA-1 output random? (Boris Kazak)
----------------------------------------------------------------------------
From: Phoenix <[EMAIL PROTECTED]>
Subject: Re: 8Bit encryption code. Just try and break it.
Date: Tue, 01 Jun 1999 19:12:45 -0700
This is a multi-part message in MIME format.
==============BE513227A9A5BDF1E9E813DA
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Fine I will post the algorithm.
But I would like anyones findings on it to be sent to [EMAIL PROTECTED],
or [EMAIL PROTECTED]
Thanks for you time and thanks for joining this thread.
--
The IDSA will find you. You cannot escape the IDSA. -Phoenix
Like a wild ass in the desert I go forth to my work. -Gurney Halleck
The buyer must never tell the seller how much he has! If you can't
tell a lie then be still. Its the first rule of fair trade.
-Leland Gaunt
My friends, let us design unique, fun software with new appeal. Let us
take on new challenges so that the world of gaming is not left behind as
a separate, closed off world. And in the process, let’s see if we can’t
make a little money. -Mr. Miyamoto :)
==============BE513227A9A5BDF1E9E813DA
Content-Type: application/x-unknown-content-type-VisualBasic.Module;
name="cryptmdi.bas"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="cryptmdi.bas"
QXR0cmlidXRlIFZCX05hbWUgPSAiY3J5cHRpdCINClB1YmxpYyBicGFyayBBcyBTdHJpbmcN
ClB1YmxpYyBicDc2NyBBcyBCb29sZWFuDQpQdWJsaWMgc3RvcGl0IEFzIEJvb2xlYW4NClB1
YmxpYyBicDY3IEFzIEJvb2xlYW4NClB1YmxpYyBicDY4IEFzIEJvb2xlYW4NClB1YmxpYyBi
cDU4IEFzIEJvb2xlYW4NClB1YmxpYyBicDU5IEFzIEJvb2xlYW4NClB1YmxpYyBicDYwIEFz
IEludGVnZXINClB1YmxpYyBicDYxIEFzIEludGVnZXINClB1YmxpYyB3aGF0IEFzIFN0cmlu
Zw0KUHVibGljIGxvYWR2YXIgQXMgU3RyaW5nDQpQdWJsaWMgc2F2ZXZhciBBcyBTdHJpbmcN
ClB1YmxpYyBicDM0IEFzIEludGVnZXINClB1YmxpYyBvdXR2YXIyIEFzIFN0cmluZw0KUHVi
bGljIGludmFyMiBBcyBTdHJpbmcNClB1YmxpYyBvdXR2YXIgQXMgU3RyaW5nDQpQdWJsaWMg
cGFzcyBBcyBTdHJpbmcNClB1YmxpYyBpbmIgQXMgU3RyaW5nDQpQdWJsaWMgb3V0YiBBcyBT
dHJpbmcNClB1YmxpYyBidWYgQXMgU3RyaW5nDQpQdWJsaWMgcGVyIEFzIERvdWJsZQ0KUHVi
bGljIGJpdGl0IEFzIEludGVnZXINClB1YmxpYyBpbnZhciBBcyBTdHJpbmcNClN1YiBlbmNy
ZigpDQpPcGVuIGludmFyIEZvciBCaW5hcnkgQXMgIzMNCmxlbnQgPSBMT0YoMykNClBhc3NM
ZW4yID0gTGVuKHBhc3MpDQp3ID0gMTogQWRkID0gMQ0KbXVsdGVyID0gSW50KDI1NSAqIEFi
cyhTaW4oUGFzc0xlbjIgKiA1NykpKQ0KYWRkZXIgPSBJbnQoMjU1ICogQWJzKENvcyhQYXNz
TGVuMiAqIDU3KSkpDQpGb3IgUGFzc0xlbiA9IDEgVG8gTGVuKHBhc3MpDQp0ZW1wID0gQXNj
KE1pZCQocGFzcywgUGFzc0xlbiwgMSkpDQp3ID0gQWJzKHcgWG9yICh0ZW1wICogSW50KCgy
NTUgXiBiaXRpdCkgKiBDb3MoUGFzc0xlbiArICgyNTUgXiBiaXRpdCkgKiBTaW4odGVtcCkp
IE1vZCAoMjU1IF4gYml0aXQpKSBYb3IgbXVsdGVyKSkNCkFkZCA9IEFicyhBZGQgRXF2ICgo
dGVtcCAqIEludCgoMjU1IF4gYml0aXQpICogU2luKFBhc3NMZW4gKyAoMjU1IF4gYml0aXQp
ICogQ29zKHRlbXApKSBNb2QgKDI1NSBeIGJpdGl0KSkgRXF2IGFkZGVyKSkpDQpOZXh0DQp3
ID0gdyBNb2QgMjU0DQpBZGQgPSBBZGQgTW9kIDI1NA0KSWYgdyA9IDAgVGhlbiB3ID0gMQ0K
T3BlbiBvdXR2YXIgRm9yIE91dHB1dCBBcyAjMQ0KT3BlbiAicGhyYXNlcy50eHQiIEZvciBB
cHBlbmQgQXMgIzINCnggPSAxDQpQcmludCAjMiwgb3V0dmFyICYgIiBQYXNzIFBocmFzZSA9
ICIgJiBwYXNzDQpQcmludCAjMSwgZW5jciQoU3RyJChsZW50ICsgQWRkICsgMTApKTsgcmFu
ZG9tJDsNCkRvDQpBMiQgPSAiICINCkdldCAjMywgeCwgQTIkDQp4ID0geCArIDENCkEgPSBB
c2MoQTIkKQ0KQSA9IEEgWG9yIEludCgyNTUgKiBBYnMoU2luKHggLSAxKSkpDQpBID0gQSAr
IEFkZCArIDEwDQpBID0gQSAqICgoeCBNb2QgMykgKyAzKQ0KQSA9IEEgKiB3DQpwYXJzZW91
dCQgPSBlbmNyJChMVHJpbSQoUlRyaW0kKFN0ciQoQSkpKSkNClByaW50ICMxLCBwYXJzZW91
dCQ7IHJhbmRvbSQ7DQpJZiBMZW4oa2lkLm91dGIxKSA+IDY1MDAwIFRoZW4gYnA2OCA9IEZh
bHNlDQpJZiBMZW4oa2lkLm91dGIxKSA8IDY1MDAwIFRoZW4gYnA2OCA9IFRydWUNCklmIGJw
NjggPD4gRmFsc2UgVGhlbg0Ka2lkLm91dGIxID0ga2lkLm91dGIxICYgcGFyc2VvdXQkICYg
cmFuZG9tJA0KSWYgbWFpbmZybS5DMS5WYWx1ZSA9IFRydWUgVGhlbiBEb0V2ZW50cw0KRW5k
IElmDQpMb29wIFVudGlsIHggPSBsZW50ICsgMSBPciBzdG9waXQgPSBUcnVlDQpDbG9zZQ0K
c3RvcGl0ID0gRmFsc2UNCkVuZCBTdWINCkZ1bmN0aW9uIHJhbmRvbSQoKQ0KQSA9IEludChS
bmQgKiAxNTQpDQpJZiBBIDw9IDUzIFRoZW4NCnJhbmRvbSQgPSBDaHIkKEludChBIC8gNikg
KiAxNiArIDEwICsgKEEgTW9kIDYpKQ0KRWxzZQ0KcmFuZG9tJCA9IENociQoQSArIDEwMSkN
CkVuZCBJZg0KRW5kIEZ1bmN0aW9uDQoNCkZ1bmN0aW9uIGVuY3IkKGRlYyQpDQpwYXJzZW91
dCQgPSAiIg0KSWYgTGVuKGRlYyQpIC8gMiA8PiBJbnQoTGVuKGRlYyQpIC8gMikgVGhlbiBk
ZWMkID0gIjAiICsgZGVjJA0KRm9yIFAlID0gMSBUbyBMZW4oZGVjJCkgLyAyDQp0ZW1wMiUg
PSBWYWwoTWlkJChkZWMkLCAyICogUCUgLSAxLCAxKSkgKiAxNiArIFZhbChNaWQkKGRlYyQs
IDIgKiBQJSwgMSkpDQpJZiB0ZW1wMiUgPSAwIFRoZW4gdGVtcDIlID0gMTU0DQpwYXJzZW91
dCQgPSBwYXJzZW91dCQgKyBDaHIkKHRlbXAyJSkNCk5leHQNCmVuY3IkID0gcGFyc2VvdXQk
DQoNCkVuZCBGdW5jdGlvbg0KDQpTdWIgZW4oKQ0KUGFzc0xlbjIgPSBMZW4ocGFzcykNCncg
PSAxOiBBZGQgPSAxDQptdWx0ZXIgPSBJbnQoMjU1ICogQWJzKFNpbihQYXNzTGVuMiAqIDU3
KSkpDQphZGRlciA9IEludCgyNTUgKiBBYnMoQ29zKFBhc3NMZW4yICogNTcpKSkNCkZvciBQ
YXNzTGVuID0gMSBUbyBMZW4ocGFzcykNCnRlbXAgPSBBc2MoTWlkJChwYXNzLCBQYXNzTGVu
LCAxKSkNCncgPSBBYnModyBYb3IgKHRlbXAgKiBJbnQoKDI1NSBeIGJpdGl0KSAqIENvcyhQ
YXNzTGVuICsgKDI1NSBeIGJpdGl0KSAqIFNpbih0ZW1wKSkgTW9kICgyNTUgXiBiaXRpdCkp
IFhvciBtdWx0ZXIpKQ0KQWRkID0gQWJzKEFkZCBFcXYgKCh0ZW1wICogSW50KCgyNTUgXiBi
aXRpdCkgKiBTaW4oUGFzc0xlbiArICgyNTUgXiBiaXRpdCkgKiBDb3ModGVtcCkpIE1vZCAo
MjU1IF4gYml0aXQpKSBFcXYgYWRkZXIpKSkNCk5leHQNCncgPSB3IE1vZCAyNTQNCkFkZCA9
IEFkZCBNb2QgMjU0DQpJZiB3ID0gMCBUaGVuIHcgPSAxDQpsZW50ID0gTGVuKGluYikNCk9w
ZW4gb3V0dmFyIEZvciBPdXRwdXQgQXMgIzENCk9wZW4gInBocmFzZXMudHh0IiBGb3IgQXBw
ZW5kIEFzICMyDQp4ID0gMQ0KUHJpbnQgIzIsIG91dHZhciAmICIgUGFzcyBQaHJhc2UgPSAi
ICYgcGFzcw0KUHJpbnQgIzEsIGVuY3IkKFN0ciQobGVudCArIEFkZCArIDEwKSk7IHJhbmRv
bSQ7DQpEbw0KQSQgPSBNaWQkKGluYiwgeCwgMSkNCnggPSB4ICsgMQ0KQSA9IEFzYyhBJCkN
CkEgPSBBIFhvciBJbnQoMjU1ICogQWJzKFNpbih4IC0gMSkpKQ0KQSA9IEEgKyBBZGQgKyAx
MA0KQSA9IEEgKiAoKHggTW9kIDMpICsgMykNCkEgPSBBICogdw0KcGFyc2VvdXQkID0gZW5j
ciQoU3RyJChBKSkNClByaW50ICMxLCBwYXJzZW91dCQ7IHJhbmRvbSQ7DQpJZiBMZW4oa2lk
Lm91dGIxKSA+IDY1MDAwIFRoZW4gYnA2OCA9IEZhbHNlDQpJZiBMZW4oa2lkLm91dGIxKSA8
IDY1MDAwIFRoZW4gYnA2OCA9IFRydWUNCklmIGJwNjggPD4gRmFsc2UgVGhlbg0Ka2lkLm91
dGIxID0ga2lkLm91dGIxICYgcGFyc2VvdXQkICYgcmFuZG9tJA0KSWYgbWFpbmZybS5DMS5W
YWx1ZSA9IFRydWUgVGhlbiBEb0V2ZW50cw0KRW5kIElmDQpMb29wIFVudGlsIHggPSBsZW50
ICsgMSBPciBzdG9waXQgPSBUcnVlDQpDbG9zZQ0Kc3RvcGl0ID0gRmFsc2UNCkVuZCBTdWIN
ClN1YiBkZWNyZigpDQpvdXRwdXRmaWxlJCA9ICIiDQpPcGVuIG91dHZhciBGb3IgQmluYXJ5
IEFzICM0DQpQYXNzTGVuMiA9IExlbihwYXNzKQ0KdyA9IDE6IEFkZCA9IDENCm11bHRlciA9
IEludCgyNTUgKiBBYnMoU2luKFBhc3NMZW4yICogNTcpKSkNCmFkZGVyID0gSW50KDI1NSAq
IEFicyhDb3MoUGFzc0xlbjIgKiA1NykpKQ0KRm9yIFBhc3NMZW4gPSAxIFRvIExlbihwYXNz
KQ0KdGVtcCA9IEFzYyhNaWQkKHBhc3MsIFBhc3NMZW4sIDEpKQ0KdyA9IEFicyh3IFhvciAo
dGVtcCAqIEludCgoMjU1IF4gYml0aXQpICogQ29zKFBhc3NMZW4gKyAoMjU1IF4gYml0aXQp
ICogU2luKHRlbXApKSBNb2QgKDI1NSBeIGJpdGl0KSkgWG9yIG11bHRlcikpDQpBZGQgPSBB
YnMoQWRkIEVxdiAoKHRlbXAgKiBJbnQoKDI1NSBeIGJpdGl0KSAqIFNpbihQYXNzTGVuICsg
KDI1NSBeIGJpdGl0KSAqIENvcyh0ZW1wKSkgTW9kICgyNTUgXiBiaXRpdCkpIEVxdiBhZGRl
cikpKQ0KTmV4dA0KdyA9IHcgTW9kIDI1NA0KQWRkID0gQWRkIE1vZCAyNTQNCklmIHcgPSAw
IFRoZW4gdyA9IDENCk9wZW4gaW52YXIgRm9yIEJpbmFyeSBBcyAjMQ0Kc2ljMiQgPSAiIg0K
c2lhMiQgPSAiICINCkZvciBzaWRlY3VycmJ5dGUyID0gMSBUbyBMT0YoMSkNCiBHZXQgIzEs
IHNpZGVjdXJyYnl0ZTIsIHNpYTIkDQogc2liMiA9IEFzYyhzaWEyJCkNCiBJZiAoc2liMiA+
IDkgQW5kIHNpYjIgPCAxNikgT3IgKHNpYjIgPiAyNSBBbmQgc2liMiA8IDMyKSBPciAoc2li
MiA+IDQxIEFuZCBzaWIyIDwgNDgpIE9yIChzaWIyID4gNTcgQW5kIHNpYjIgPCA2NCkgT3Ig
KHNpYjIgPiA3MyBBbmQgc2liMiA8IDgwKSBPciAoc2liMiA+IDg5IEFuZCBzaWIyIDwgOTYp
IE9yIChzaWIyID4gMTA1IEFuZCBzaWIyIDwgMTEyKSBPciAoc2liMiA+IDEyMSBBbmQgc2li
MiA8IDEyOCkgT3IgKHNpYjIgPiAxMzcgQW5kIHNpYjIgPCAxNDQpIE9yIHNpYjIgPj0gMTU1
IFRoZW4NCiAgbGVudCQgPSBzaWMyJDogc2ljMiQgPSAiIjogc2lyZXN1bWVieXRlID0gc2lk
ZWN1cnJieXRlMiArIDE6IEV4aXQgRm9yDQogRWxzZQ0KICBzaWMyJCA9IHNpYzIkICsgc2lh
MiQNCiBFbmQgSWYNCk5leHQNCmxlbnQgPSBJbnQoVmFsKGRlY3IkKGxlbnQkKSkgLSBBZGQg
LSAxMCkNCiBzaWEkID0gIiAiDQogRm9yIHNpZGVjdXJyYnl0ZSA9IHNpcmVzdW1lYnl0ZSBU
byBMT0YoMSkNCiAgR2V0ICMxLCBzaWRlY3VycmJ5dGUsIHNpYSQNCiAgc2liID0gQXNjKHNp
YSQpDQogIElmIChzaWIgPiA5IEFuZCBzaWIgPCAxNikgT3IgKHNpYiA+IDI1IEFuZCBzaWIg
PCAzMikgT3IgKHNpYiA+IDQxIEFuZCBzaWIgPCA0OCkgT3IgKHNpYiA+IDU3IEFuZCBzaWIg
PCA2NCkgT3IgKHNpYiA+IDczIEFuZCBzaWIgPCA4MCkgT3IgKHNpYiA+IDg5IEFuZCBzaWIg
PCA5NikgT3IgKHNpYiA+IDEwNSBBbmQgc2liIDwgMTEyKSBPciAoc2liID4gMTIxIEFuZCBz
aWIgPCAxMjgpIE9yIChzaWIgPiAxMzcgQW5kIHNpYiA8IDE0NCkgT3Igc2liID49IDE1NSBU
aGVuDQogICBQYXJzZTIkID0gZGVjciQoc2ljJCkNCiAgIHNpYyQgPSAiIg0KICAgeCA9IHgg
KyAxDQogICBBID0gVmFsKFBhcnNlMiQpDQogICBBID0gQSAvIHcNCiAgIEEgPSBBIC8gKCgo
eCArIDEpIE1vZCAzKSArIDMpDQogICBBID0gQSAtIEFkZCAtIDEwDQogICBBID0gQSBYb3Ig
SW50KDI1NSAqIEFicyhTaW4oeCkpKQ0KICAgSWYgQSA+IDI1NSBPciBBIDwgMCBUaGVuIE1z
Z0JveCAiSW52YWxpcyBQYXNzcGhyYXNlISEhIjogRXhpdCBTdWINCiAgIHNpdGVtcDEyNTMk
ID0gQ2hyJChBKQ0KICAgUHV0ICM0LCB4LCBzaXRlbXAxMjUzJA0KICBFbHNlDQogICBzaWMk
ID0gc2ljJCArIHNpYSQNCiAgRW5kIElmDQogIElmIExlbihraWQub3V0YjEpID4gNjUwMDAg
VGhlbiBicDY4ID0gRmFsc2UNCklmIExlbihraWQub3V0YjEpIDwgNjUwMDAgVGhlbiBicDY4
ID0gVHJ1ZQ0KSWYgYnA2OCA8PiBGYWxzZSBUaGVuDQogIGtpZC5vdXRiMSA9IGtpZC5vdXRi
MSAmIG91dHB1dGZpbGUkICYgdmJDckxmDQogIElmIG1haW5mcm0uQzEuVmFsdWUgPSBUcnVl
IFRoZW4gRG9FdmVudHMNCkVuZCBJZg0KDQogIElmIHN0b3BpdCA9IFRydWUgVGhlbiBHb1Rv
IDU5NDk0DQogTmV4dA0KNTk0OTQNCkNsb3NlDQpzdG9waXQgPSBGYWxzZQ0KRW5kIFN1Yg0K
RnVuY3Rpb24gZGVjciQoQSQpDQpQYXJzZTIkID0gIiINCkZvciBiID0gMSBUbyBMZW4oQSQp
DQpEID0gQXNjKE1pZCQoQSQsIGIsIDEpKQ0KSWYgRCA9IDE1NCBUaGVuIEQgPSAwDQpKID0g
KEQgQW5kIDI0MCkgLyAxNg0KSyA9IEQgQW5kIDE1DQpQYXJzZTIkID0gUGFyc2UyJCArIExU
cmltJChSVHJpbSQoU3RyJChKKSkpICsgTFRyaW0kKFJUcmltJChTdHIkKEspKSkNCk5leHQN
CmRlY3IkID0gUGFyc2UyJA0KDQpFbmQgRnVuY3Rpb24NClN1YiBkZSgpDQpQYXNzTGVuMiA9
IExlbihwYXNzKQ0KdyA9IDE6IEFkZCA9IDENCm11bHRlciA9IEludCgyNTUgKiBBYnMoU2lu
KFBhc3NMZW4yICogNTcpKSkNCmFkZGVyID0gSW50KDI1NSAqIEFicyhDb3MoUGFzc0xlbjIg
KiA1NykpKQ0KRm9yIFBhc3NMZW4gPSAxIFRvIExlbihwYXNzKQ0KdGVtcCA9IEFzYyhNaWQk
KHBhc3MsIFBhc3NMZW4sIDEpKQ0KdyA9IEFicyh3IFhvciAodGVtcCAqIEludCgoMjU1IF4g
Yml0aXQpICogQ29zKFBhc3NMZW4gKyAoMjU1IF4gYml0aXQpICogU2luKHRlbXApKSBNb2Qg
KDI1NSBeIGJpdGl0KSkgWG9yIG11bHRlcikpDQpBZGQgPSBBYnMoQWRkIEVxdiAoKHRlbXAg
KiBJbnQoKDI1NSBeIGJpdGl0KSAqIFNpbihQYXNzTGVuICsgKDI1NSBeIGJpdGl0KSAqIENv
cyh0ZW1wKSkgTW9kICgyNTUgXiBiaXRpdCkpIEVxdiBhZGRlcikpKQ0KTmV4dA0KdyA9IHcg
TW9kIDI1NA0KQWRkID0gQWRkIE1vZCAyNTQNCklmIHcgPSAwIFRoZW4gdyA9IDENCk9wZW4g
aW52YXIgRm9yIEJpbmFyeSBBcyAjMQ0Kc2lhMiQgPSAiICINCkZvciBzaWRlY3VycmJ5dGUy
ID0gMSBUbyBMT0YoMSkNCiBHZXQgIzEsIHNpZGVjdXJyYnl0ZTIsIHNpYTIkDQogc2liMiA9
IEFzYyhzaWEyJCkNCiBJZiAoc2liMiA+IDkgQW5kIHNpYjIgPCAxNikgT3IgKHNpYjIgPiAy
NSBBbmQgc2liMiA8IDMyKSBPciAoc2liMiA+IDQxIEFuZCBzaWIyIDwgNDgpIE9yIChzaWIy
ID4gNTcgQW5kIHNpYjIgPCA2NCkgT3IgKHNpYjIgPiA3MyBBbmQgc2liMiA8IDgwKSBPciAo
c2liMiA+IDg5IEFuZCBzaWIyIDwgOTYpIE9yIChzaWIyID4gMTA1IEFuZCBzaWIyIDwgMTEy
KSBPciAoc2liMiA+IDEyMSBBbmQgc2liMiA8IDEyOCkgT3IgKHNpYjIgPiAxMzcgQW5kIHNp
YjIgPCAxNDQpIE9yIHNpYjIgPj0gMTU1IFRoZW4NCiAgbGVudCQgPSBzaWMyJDogc2ljMiQg
PSAiIjogc2lyZXN1bWVieXRlID0gc2lkZWN1cnJieXRlMiArIDE6IEV4aXQgRm9yDQogRWxz
ZQ0KICBzaWMyJCA9IHNpYzIkICsgc2lhMiQNCiBFbmQgSWYNCk5leHQNCmxlbnQgPSBJbnQo
VmFsKGRlY3IkKGxlbnQkKSkgLSBBZGQgLSAxMCkNCiBzaWEkID0gIiAiDQogRm9yIHNpZGVj
dXJyYnl0ZSA9IHNpcmVzdW1lYnl0ZSBUbyBMT0YoMSkNCiAgR2V0ICMxLCBzaWRlY3VycmJ5
dGUsIHNpYSQNCiAgc2liID0gQXNjKHNpYSQpDQogIElmIChzaWIgPiA5IEFuZCBzaWIgPCAx
NikgT3IgKHNpYiA+IDI1IEFuZCBzaWIgPCAzMikgT3IgKHNpYiA+IDQxIEFuZCBzaWIgPCA0
OCkgT3IgKHNpYiA+IDU3IEFuZCBzaWIgPCA2NCkgT3IgKHNpYiA+IDczIEFuZCBzaWIgPCA4
MCkgT3IgKHNpYiA+IDg5IEFuZCBzaWIgPCA5NikgT3IgKHNpYiA+IDEwNSBBbmQgc2liIDwg
MTEyKSBPciAoc2liID4gMTIxIEFuZCBzaWIgPCAxMjgpIE9yIChzaWIgPiAxMzcgQW5kIHNp
YiA8IDE0NCkgT3Igc2liID49IDE1NSBUaGVuDQogICB4ID0geCArIDENCiAgIEEgPSBWYWwo
ZGVjciQoc2ljJCkpDQogICBBID0gQSAvIHcNCiAgIEEgPSBBIC8gKCgoeCArIDEpIE1vZCAz
KSArIDMpDQogICBBID0gQSAtIEFkZCAtIDEwDQogICBBID0gQSBYb3IgSW50KDI1NSAqIEFi
cyhTaW4oeCkpKQ0KICAgSWYgQSA+IDI1NSBPciBBIDwgMCBUaGVuIE1zZ0JveCAiSW52YWxp
ZCBQYXNzIFBocmFzZSI6IEV4aXQgU3ViDQogICBJZiBMZW4oa2lkLm91dGIxKSA+IDY1MDAw
IFRoZW4gYnA2OCA9IEZhbHNlDQpJZiBMZW4oa2lkLm91dGIxKSA8IDY1MDAwIFRoZW4gYnA2
OCA9IFRydWUNCklmIGJwNjggPD4gRmFsc2UgVGhlbg0KICAga2lkLm91dGIxID0ga2lkLm91
dGIxICsgQ2hyJChBYnMoQSkpDQogICBJZiBtYWluZnJtLkMxLlZhbHVlID0gVHJ1ZSBUaGVu
IERvRXZlbnRzDQogICBFbmQgSWYNCiAgIHNpYyQgPSAiIg0KICBFbHNlDQogICBzaWMkID0g
c2ljJCArIHNpYSQNCiAgRW5kIElmDQogSWYgc3RvcGl0ID0gVHJ1ZSBUaGVuIEdvVG8gNTY3
Njk5DQogTmV4dA0KNTY3Njk5DQpDbG9zZQ0Kc3RvcGl0ID0gRmFsc2UNCkVuZCBTdWINCg==
==============BE513227A9A5BDF1E9E813DA==
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Subject: Re: SHA-1 output random?
Date: Tue, 01 Jun 1999 20:05:12 -0400
Reply-To: [EMAIL PROTECTED]
Florian Weimer wrote:
>
> [EMAIL PROTECTED] (Lincoln Yeoh) writes:
>
> > Right now for a program running on Linux, I'm supplying it about 31
> > variably random bytes from /dev/urandom, and trying to use SHA-1 to
> > concentrate stuff a bit. I'm not sure if the trade off is worth it - coz
>
> I don't think so, because the data you get from /dev/urandom is
> generated based on an entropy pool using SHA-1. That's the reason why
> I'm interested in this property of SHA-1. ;)
>
> Are there any one-way hash functions which could be used instead?
=====================
Try this. It reads a file, writes a file...
The program takes the filename from the simple dialog
and writes the hash into a new file with the name of the
original file and extension "h32".
This proposed function is based on multiplication
(mod 2^32+1) with two "twists". First, however, some
background information.
The function uses 256 different modular multipliers
derived from one initial number "SEED". This number is
0x6A09E667, which happens to be the first 8 hex digits of
SQRT(2), less initial 1. The use of this number should
dispel any suspicions about a "trap door" built into SEED.
The multipliers themselves are simply the powers of SEED,
so that Mult[k] = SEED^(k+1), this way SEED^0 = 1 is
avoided, we don't want any trivial multipliers. Also, this
number produces a 33,502,080 long cycle of its powers
until it comes back to 1, so there are no duplicate
multipliers in the array.
The multiplier array can be precomputed in advance or
can be filled at the program start. The latter case saves
some code (no need for a big data table), but implies a
time penalty of 255 modular multiplications.
Original message is divided into segments of the size
twice that of the final hash, e.g. if the final hash will
be 160 bit, the segments will be 320 bit each. The size of
the hash and segments is #defined by the HASHBLOCKSIZE
constant and can be altered according to need.
Now about the "twists". The first twist boils down to
the plaintext-dependent choice of the multiplier. If a
certain 4-byte number is going to be hashed, the
corresponding multiplier is chosen from the table with the
index I = XOR(all 4 bytes of the number).
Second twist regards the progression along the block.
After the multiplication, when the bytes of the product
are returned to their places and it is time to proceed
with the subsequent multiplication, the two LS bytes of
the previous product become the two MS bytes of the new
number to be multiplied, and two adjacent bytes of
the plaintext are appended to them in order to make this
new 32-bit number. When the end of the block is reached,
the index wraps cyclically over the BlockLength.
For each block, there are three rounds (for those
paranoid among us, there is a #define, where one can
change the ROUNDS constant to whatever desired).
Graphically a round can be visualized in the
following sketch:
( the index is circular mod "2*HASHBLOCKSIZE" )
___________________________________________________________
1-st multiplication
XXXXxxxxxxxxxxxxxxxxxxxxxxxxxxxx
( XXXX - 32-bit number to multiply, multiplier
index is computed as X^X^X^X)
___________________________________________________________
2-nd multiplication
ppPPXXxxxxxxxxxxxxxxxxxxxxxxxxxx
(ppPP - product of the first multiplication,
PPXX - 32-bit number to multiply, multiplier
index is computed as P^P^X^X)
___________________________________________________________
3-d multiplication
ppppPPXXxxxxxxxxxxxxxxxxxxxxxxxx
( PPXX - 32-bit number to multiply, multiplier
index is computed as P^P^X^X)
...........................................................
Last multiplication
XXppppppppppppppppppppppppppppPP
( The index is cyclically wrapped over -
PPXX - 32-bit number to multiply, multiplier
index is computed as P^P^X^X)
___________________________________________________________
This arrangement allows an ultra-rapid propagation
of all changes across the entire block - there is complete
avalanche after the 2-nd round and then after each
subsequent round.
It should be also noted that this arrangement
effectively molds the entire hash into an inseparable
entity, where the junctions between the adjacent bytes and
words don't exist any more, they are all blurred by
overlapping and by cyclical wrapover of the index. This
strongly discourages any attacks based on different
behavior of the distinct bytes and words during hashing.
In this function the entire hash is just a circular
sequence of bits without beginning or end, without the
junctions between bytes or words, without any realistic
possibility to trace the output changes back to the changes
in any particular word or byte. The cryptanalyst would
either be forced to attack the hash as a whole (128 or
even 256 bits), or just give up, which I hope will
precisely happen.
After 3 rounds, the new subsequent block is read from
the message and XOR-ed with the hash obtained in the previous
cycles. Then the hashing procedure repeats again for 3
rounds, and so on until the last message block is read.
If the last message block is shorter than needed, it is
padded with 0-s.
Thereafter one more block is added to the
hash, containing the full message length as a 64-bit binary
number padded with 0-s. The final operation XOR-s the two
halves of the hash buffer, producing the output hash value.
Since in each multiplication step the multiplicand is
replaced with the product, there is no practical way of
reconstructing the multiplier index (other than computing
multiplicative inverses for all 256 multipliers and testing
the product to find out the match for the index used,
however, the final XOR-ing defeats this option).
Initially the hash buffer contains either 0's or an
appropriate IV. No hashing is done on this value, the first
message block is just XOR-ed into the hash buffer.
If the secret key will be used as the IV, the function
will produce a MAC.
The source code was compiled under Borland C++ 4.52
and should compile under any ANSI-compliant C compiler.
The routines for breaking and making the 32-bit integers
from 4 bytes should assure identical results on both big-
endian and little-endian platforms (not tested).
No attempt has been made in order to optimize the
program in any way. After all, it is supposed to be just
a working model, not a racing car. One simple possible
optimization might reverse the direction of scanning
over the "text" block for little-endian Intel processors.
Any comments would be appreciated.
/********************* Start of code ************/
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#define byte unsigned char
#define word16 unsigned int
#define word32 unsigned long int
#define LO 0x0000FFFFUL
#define HI 0xFFFF0000UL
#define HASHBLOCKSIZE 16
#define ROUNDS 3
#define SEED 0x6A09E667UL /* Modular Multiplier seed */
/* First 8 hex digits of SQRT(2), less initial 1 */
/* variables */
word32 mult[256]; /* multiplier array */
word32 message_length; /* size of input file */
int end_of_file;
byte inbuffer[2*HASHBLOCKSIZE], outbuffer[HASHBLOCKSIZE];
byte text[2*HASHBLOCKSIZE]; /* the working array */
/*file handling functions*/
char read_char_from_file(FILE *fp);
void read_block_from_file(FILE *fp);
void write_char_to_file(char data,FILE *fp);
/* Functions */
word32 Mul (word32 x, word32 y) /* Returns (x * y) mod
(2^32+1) */
/* For the purposes of this algorithm 0 =
2^32 */
/* Modular Multiplication "CORRECT BUT SLOW" (mod 2^32+1)
If your compiler does not handle the "double long"
integers (64 bit), you have to split the 32-bit words
into 16-bit halves, multiply them, then juggle the
intermediate products until you get the correct result.
*/
{
word32 t[4]; word16 u[2], v[2];
if (x == 0) return (1 - y);
if (y == 0) return (1 - x);
u[0] = (word16)(x & LO);
v[0] = (word16)(y & LO);
u[1] = (word16)((x >> 16) & LO);
v[1] = (word16)((y >> 16) & LO);
t[0] = (word32) u[0] * (word32) v[0] ;
t[1] = (word32) u[1] * (word32) v[0] ;
t[2] = (word32) u[0] * (word32) v[1] ;
t[3] = (word32) u[1] * (word32) v[1] ;
/* intermediate 32-bit products */
t[3] = t[3] + ((t[1] >> 16) & LO)
+ ((t[2] >> 16) & LO);
/* no overflow possible here */
t[1] = (t[1] & LO) + (t[2] & LO)
+ ((t[0] >> 16) & LO);
/* collect them all in t[1]. Overflow into the
17-th bit possible here */
t[0] = (t[0] & LO) + ((t[1] << 16) & HI);
t[3] = t[3] + ((t[1] >> 16) & LO); /* add eventual overflow */
return (t[0] - t[3] + (t[3] > t[0]));
} /* Mul */
#define MUL(x,y) (x=Mul(x,y))
void MultSetup (word32 *mul)
{
int k;
*mul = SEED; /* Initialize multiplier array */
for (k = 1; k < 256; k++)
{
*(mul+k) = *(mul+k-1); /* Copy next <- previous */
MUL (*(mul+k),SEED); /* Subsequent power */
}
} /* MultSetup */
void DissH1( word32 H, byte *D )
/*
Disassemble the given word32 into 4 bytes.
We want it to work on all kinds of machines,
Little-Endian or Big-Endian.
*/
{
word32 T ;
T = H ;
*D++ = (byte)((T & 0xff000000UL) >> 24) ;
*D++ = (byte)((T & 0x00ff0000UL) >> 16) ;
*D++ = (byte)((T & 0x0000ff00UL) >> 8) ;
*D = (byte) (T & 0x000000ffUL) ;
} /* DissH1 */
word32 MakeH1( byte *B )
/*
Assemble a word32 from the four bytes provided.
We want it to work on all kinds of machines,
Little-Endian or Big-Endian.
*/
{
word32 RetVal, temp ;
temp = *B++ ;
RetVal = (temp << 24) ;
temp = *B++ ;
RetVal += (temp << 16) ;
temp = *B++ ;
RetVal += (temp << 8) ;
RetVal += *B ;
return RetVal ;
} /* MakeH1 */
void Scramble (void) /* This subroutine scrambles the "text" block */
/* It uses the global variables */
/* mult[], text[] and inbuffer[] */
{
int i,k,m;
word32 temp1, temp2;
/* XOR-ing the input into the text array */
for (m=0; m < 2*HASHBLOCKSIZE; m++) text[m] ^= inbuffer[m];
/* Now we can start squashing the block */
for (m=0; m<ROUNDS; m++)
{
for (k=0; k<2*HASHBLOCKSIZE; k+= 2)
{
/* Build a 32-bit multiplicand and multiplier index */
/* We want this to produce same results on big-endian
*/
/* and little-endian machines alike */
temp2 = text[k % (2*HASHBLOCKSIZE)] ; /* Essentially this
procedure */
i = (int)temp2; /* is identical to MakeH2
function */
temp1 = (temp2 << 24) ; /* However, it is
impossible to use */
temp2 = text[(k+1)%(2*HASHBLOCKSIZE)] ; /* MakeH2 function
directly, because */
i ^= (int)temp2; /* the loop index must be
wrapped */
temp1 += (temp2 << 16) ; /* mod 2*HASHBLOCKSIZE, and
also the */
temp2 = text[(k+2) % (2*HASHBLOCKSIZE)] ; /* multiplier index is
computed, */
i ^= (int)temp2; /* which is not provided in
MakeH2 */
temp1 += (temp2 << 8) ;
temp1 += text[(k+3) % (2*HASHBLOCKSIZE)] ;
i ^= (int)temp2;
/* Get the modular product into "temp1" */
MUL(temp1, mult[i]);
/* Return the bytes where they belong */
text[k % (2*HASHBLOCKSIZE)] = (byte)((temp1 & 0xff000000UL) >>
24) ;
text[(k+1) % (2*HASHBLOCKSIZE)] = (byte)((temp1 & 0x00ff0000UL) >>
16) ;
text[(k+2) % (2*HASHBLOCKSIZE)] = (byte)((temp1 & 0x0000ff00UL) >>
8) ;
text[(k+3) % (2*HASHBLOCKSIZE)] = (byte) (temp1 & 0x000000ffUL) ;
}
}
} /* Scramble */
char read_char_from_file(FILE *fp)
{
char temp=0;
message_length++;
if ((fread(&temp,sizeof(char),1,fp))!=1)
{
end_of_file=1;
message_length--;
}
return (temp);
} /* read_char_from_file */
void read_block_from_file(FILE *fp)
{
int i;
for (i=0; i<2*HASHBLOCKSIZE; i++)
{
inbuffer[i]=read_char_from_file(fp);
}
} /* read_block_from_file */
void write_char_to_file(char data,FILE *fp)
{
if ((fwrite(&data,sizeof(char),1,fp))!=1)
{
printf("Fatal Error writing output file!!!\n");
exit(-1);
}
} /* write_char_to_file */
void main()
{
FILE *in,*out;
char infile[100], outfile[100], *dot;
int k;
/* Opening files */
printf("\nEnter input filename:");
gets(infile);
if ((in=fopen(infile,"r+b"))==NULL)
{
printf("\nError opening input file: %s\n",infile);
exit (-1);
}
strcpy(outfile,infile);
dot=strrchr(outfile,'.'); dot++;
*dot++='h'; *dot++='3'; /* Changing file extension */
*dot++='2'; *dot='\0'; /* to .h32 */
if ((out=fopen(outfile,"w+b"))==NULL)
{
printf("\nError opening output file: %s\n",outfile);
exit(-1);
}
printf("\nOutput file is: %s\n",outfile);
/* Setting up the multipliers */
MultSetup(mult);
/* Clearing the text buffer */
for (k=0; k<2*HASHBLOCKSIZE; k++) text[k]=0;
/* Reading and squashing the input file */
while(end_of_file != 1)
{
read_block_from_file(in);
Scramble();
}
/* Building up and squashing the final block */
for (k=0; k<4; k++) inbuffer[k]=0;
DissH1(message_length, (inbuffer+4));
for (k=8; k<2*HASHBLOCKSIZE; k++) inbuffer[k]=0;
Scramble();
/* Building and writing the final hash */
for (k=0; k<HASHBLOCKSIZE; k++)
outbuffer[k] = text[k]^text[k+HASHBLOCKSIZE];
for (k=0; k<HASHBLOCKSIZE; k++)
{
write_char_to_file(outbuffer[k],out);
}
fclose(in); fclose(out);
}
------------------------------
** 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
******************************
