Cryptography-Digest Digest #281, Volume #13 Wed, 6 Dec 00 08:13:01 EST
Contents:
Re: Journal of Craptology (Mok-Kong Shen)
Re: DES and Salt (Mok-Kong Shen)
Re: ---- Are AES algorithms export restricted? (Mok-Kong Shen)
Re: DES and Salt ("Mike The Man")
Re: MD5 byte order (Herbert Kleebauer)
Re: weten we die PIN? (David Dylan)
Re: weten we die PIN? (David Dylan)
Re: weten we die PIN? (David Dylan)
Idea for ciphering? (Jorgen Hedlund)
Re: weten we die PIN? ([EMAIL PROTECTED])
Re: weten we die PIN? ([EMAIL PROTECTED])
Re: Simulataneous encryption and authentification (was IBM's new algorithm)
(Francois Grieu)
Idea for ciphering? (correction w/ addition) (Jorgen Hedlund)
Re: ---- Are AES algorithms export restricted? ("Brian Gladman")
Re: ---- Are AES algorithms export restricted? ("Brian Gladman")
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Journal of Craptology
Date: Wed, 06 Dec 2000 10:14:54 +0100
David A Molnar wrote:
>
> Eric Lee Green <[EMAIL PROTECTED]> wrote:
> > Something to think about while we talk about the effectiveness of
> > encryption algorithms and such... i.e., that you can have the
> > strongest encryption in the world and it's no good if somebody gives
> > the attacker the key (whether voluntarily or no).
>
> This is why forward security is important.
>
> At least then you can limit the damage a bit.
Sorry for my ignorance. What is 'forward security'?
As long as the 'severe' pseudo-democratic governments exist,
steganography (there are widely different forms) will remain
an important issue for information privacy. It may be of
interest to note that some leading experts in information
hiding are from regions with apparently higher demands of
such protections.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: DES and Salt
Date: Wed, 06 Dec 2000 10:14:34 +0100
[EMAIL PROTECTED] wrote:
>
> "Mike The Man" <[EMAIL PROTECTED]> wrote:
> > The first input value is all zeroes, then the DES-output is fed back
> to the
> > input for the next DES.
> > This is repeated 25 times.
>
> That's correct. But, where do you use the salt? It's used to modify
> the expansion function (there are 2^12 = 4096 variations).>
>
> > Could anyone tell me, if this is right?
I like to remark that this means that (1) One modifies a
little bit a standard algorithm to obtain varaints (mutants),
(2) One uses multiple encryption up to as much as 25 times,
and (3) These have apprarently found good acceptance and
proved useful in practice.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: ---- Are AES algorithms export restricted?
Date: Wed, 06 Dec 2000 10:35:32 +0100
Bill Unruh wrote:
>
> Greggy <[EMAIL PROTECTED]> writes:
>
> >It just seemed to me as I was reading another post here that none of
> >the AES algorithms could possibly be export restricted from within the
> >US since they were all published during the AES contest. Am I
> >correct? Or did I miss something in my thinking here?
> They are all export restricted. It is entirely legal to export printed
> copies of algorithms. It is just not legal to export code without a
> license (unless it is opensource code, in which case it does not need a
> license, ..... read the law.)
They are all freely available outside of nations having
export regulations via the web page of NIST. So I suppose
one way to cope with the situation could be to leave a
stub in the delivered code of an application containing
such an algorithm as a component and let the customer to
download the necessary piece of 'sinister' and 'forbidden'
stuff himself and plug it in.
BTW, an information for those who engage in crypto software
business: A recent motion to modify the European patent
laws to allow software patents failed. There will therefore
be no European software patents.
M. K. Shen
===============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: "Mike The Man" <[EMAIL PROTECTED]>
Subject: Re: DES and Salt
Date: Wed, 6 Dec 2000 10:36:03 +0100
Thanks, that's another step forward for me.
I'm sorry to say it's still not working.
Regarding the salt, yes it's implemented in the expansion function, I've
tried to do it two different ways and both came out with the same result, so
I think it's OK.
It's taken from an Internet-document called "UNIX Password Encryption
Considered Insecure"
An example.
I've typed in a linux password "AAAABBBB", the result was: omjTAi4EUHsh6
The salt (om) is in hex: d32.
The 25DES (jTAi4EUHsh6) is in hex: bdf32e190813e2d2.
In my application I type in the DES key (leftshifted AAAABBBB) in hex as:
8282828284848484
And the salt: d32
Then after the 25DES I get: a2987a7d32472e28
I sure appreciate all help /Mike
[EMAIL PROTECTED] skrev i meddelandet <90jgvt$kf6$[EMAIL PROTECTED]>...
>In article <90jfdn$it6$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>> In article <Rc7X5.339$[EMAIL PROTECTED]>,
>> "Mike The Man" <[EMAIL PROTECTED]> wrote:
>...
>> >
>> > From what I've gathered, the Unix password consists of thirteen
>> > base64-encoded characters. The two first make up the 12-bit salt.
>>
>> I don't think it's the standard base64, the charset is determined like
>> this (c contains the six bits):
>> c += '.';
>> if(c > '9')
>> c += 7;
>> if(c > 'Z')
>> c += 6;
>> c will now contain a printable character.
>>
> Just to make this clear the charset is "./0-9A-Za-z" while for the
>standard base64 (RFC2045 section 6.8) it's "A-Za-z0-9+/" so they're not
>quite the same.
>
>> > The other eleven is the 64bit result from doing the 25-times DES.
>> > When you type in a password the first eight ASCII characters will be
>> > leftshifted (so an A - h41 would be h82), because the 8th bit is
>> ignored as
>>
>> No I don't think they're shifted. You take the 7 most significant
>bits
>> of the 1st byte, and place them in the key as bits 1 to 7 (offset
>> starting at 1 not 0). The 8th bit is ignored (it should be the parity
>> bit as you say). Then you move to the second byte, its 7 msbits are
>> placed in the key as bits 9 to 15, bit 16 is the parity, etc...
>>
>My answer is wrong, it is the 7 low order bits that are kept not the 7
>high-order bits, so in that sense you're right, the bits in each byte
>are shifted by 1 to the left and the least significant bit is ignored.
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Herbert Kleebauer)
Subject: Re: MD5 byte order
Date: Wed, 6 Dec 2000 11:21:35
In article <90jidb$oie$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Paul Schlyter) writes:
>From: [EMAIL PROTECTED] (Paul Schlyter)
>Subject: Re: MD5 byte order
>Date: 5 Dec 2000 21:15:39 +0100
>AFAIR I've always seen the least significant bit referred to as "bit 0".
>Is the opposite convention ever used? If so, when?
As far as I rember, one of the first 16-bit processors, the
TMS9900 from Texas Instruments did this.
------------------------------
From: [EMAIL PROTECTED] (David Dylan)
Crossposted-To:
alt.cracks.nl,alt.nl.telebankieren,nl.comp.crypt,nl.financieel.bankieren,nl.juridisch
Subject: Re: weten we die PIN?
Date: Wed, 06 Dec 2000 10:26:47 GMT
On Fri, 1 Dec 2000 20:00:54 +0100, "Erwin Graumans" <me@home> wrote:
Hoi hoi,
>het fiatteringsproces van PIN-transacties loopt als volgt:
>de automaat verzamelt eerst alle transactiegegevens en stuurt die in 1
>bericht naar jouw bank (via een heel lang, maar vooral snel interbancair
>datatraject). Jouw bank keurt de transactiegegevens goed of af (incl. je
>PIN-code) en stuurt een response terug naar de automaat.
300 Baud zou ik niet snel willen noemen.......... en de meeste PIN
automaten en apparaten hebben een 300 Baud modem + een veredelde
telefoonlijn naar de bank.
Veilig zou ik dat ook niet willen noemen. Mits je de lijn kunt vinden
tussen de automaat en de PTT kast kun je de lijn met een simpel thuis
te bouwen apparaatje aftappen.
De reden waarom we nog altijd redelijk veilig zijn is omdat criminelen
economen pur-sang zijn: Het is (meestal) te veel moeite + risico voor
te weinig opbrengst.
Grappig:
Een kennis van mij heeft eens met zo'n winkelding gespeeld, het LCD
display is gewoon lokaal programmeerbaar, theoretisch kun je dus na de
transactie niet "Bedankt" printen maar: "We hebben je centen, rot nu
maar op!" ;-)
------------------------------
From: [EMAIL PROTECTED] (David Dylan)
Crossposted-To:
alt.cracks.nl,alt.nl.telebankieren,nl.comp.crypt,nl.financieel.bankieren,nl.juridisch
Subject: Re: weten we die PIN?
Date: Wed, 06 Dec 2000 10:32:38 GMT
On 23 Nov 2000 10:33:00 GMT, Mark Wormgoor <[EMAIL PROTECTED]> wrote:
Hoi hoi,
>Dit kun je in Nederland eenvoudig proberen (is me wel eens gebeurd). Type
>een foute pincode in en je kunt rustig doorgaan met de transactie. Je
>kiest het saldo, transactiebon of niet, dan gaat het apparaat lekker
>printen en komt dan pas met de melding dat je pincode niet geldig is.
Maar niet te vaak. Ik heb eens in een automaat (op het Spui te A'dam)
twee keer de verkeerde PIN ingevoerd (ik gebruikte het pasje van de
ene rekening en voerde de PIN in van de andere) Na de tweede keer kies
ik natuurlijk eieren voor mijn geld en ontdek mijn fout.... Weken
later (voor mijn gevoel dan) kom ik terug en maak... stom stom stom,
dezelfde fout met hetzelfde pasje. Prompt krijg ik mijn pasje terug
met de melding dat de PIN ongeldig is geworden.....
Groetz.
DD.
------------------------------
From: [EMAIL PROTECTED] (David Dylan)
Crossposted-To:
alt.cracks.nl,alt.nl.telebankieren,nl.comp.crypt,nl.financieel.bankieren,nl.juridisch
Subject: Re: weten we die PIN?
Date: Wed, 06 Dec 2000 10:37:31 GMT
On Wed, 06 Dec 2000 10:32:38 GMT, [EMAIL PROTECTED] (David Dylan) wrote:
PS: Iemand enig idee waar dit wordt bijgehouden? Bij de bank of op de
automaat?
Groetz.
DD.
--
Kijk eens op mijn community site:
http://www.grep.nu/beleggers
Of op mijn persoonlijke site:
http://www.xs4all.nl/~nobeard
------------------------------
From: Jorgen Hedlund <[EMAIL PROTECTED]>
Subject: Idea for ciphering?
Date: Wed, 06 Dec 2000 11:50:53 +0100
Reply-To: [EMAIL PROTECTED]
I was trying to sleep last night when I got to think of this
cipher algorithm. Well, not exactly an algorithm, more like
an idea for one.
Imagine a statemachine, and its state transition table (STT).
For example if the alphabet consists of {a,b,c,d, EOS} and the
machine has 4 states, this could be one STT:
chr -> a b c d
========+================
state 1| 2 3 4 1
2| 4 3 2 1
3| 1 3 2 4
4| 4 2 3 1
Then imagine that each state do some transformation of the
character. Let's denote this transformation Tn() for
state n.
For instance if the transformations are simply some kind
of substitution, then their keys could be like this:
F1() key = abcd -> EwGy
F2() key = abcd -> %thE
F3() key = abcd -> !ikz
F4() key = abcd -> &hus
Then using this presettings, a string "bddacda" would be
encoded as: (n+ = next state)
Start state = 1
F1(b) = w, n+ = 3
F3(d) = z, n+ = 4
F4(d) = s, n+ = 1
F1(a) = E, n+ = 2
F2(c) = h, n+ = 2
F2(d) = E, n+ = 1
F1(a) = E, n+ = 2
<EOS>
result "wzsEhEE"
The public key are the above STT, while a private key would
consist of a reversed STT.
Without the reversed STT, there would be really difficult to
decrypt. Right?
The Fn()'s should probably be something else than standard
substitution, but I used it as an example.
And, ofcourse, the STT would be a 256*<no of states> grid,
if we use bytes.
Well, any comments?
Any mathematical stuff that might be interesting? (I like 'em
but can't produce 'em)
BR/jh
--
==========================================
J�rgen Hedlund, Software Engineer
Ericsson Software Technology, BGw
==========================================
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
alt.cracks.nl,alt.nl.telebankieren,nl.comp.crypt,nl.financieel.bankieren,nl.juridisch
Subject: Re: weten we die PIN?
Date: 6 Dec 2000 11:10:37 -0000
In nl.juridisch David Dylan <[EMAIL PROTECTED]> wrote:
> 300 Baud zou ik niet snel willen noemen.......... en de meeste PIN
> automaten en apparaten hebben een 300 Baud modem + een veredelde
> telefoonlijn naar de bank.
ik maar denken dat dat via het 16kbits D channel ging van ISDN.
--
Grobbebol's Home | Don't give in to spammers. -o)
http://www.xs4all.nl/~bengel | Use your real e-mail address /\
Linux 2.2.16 SMP 466MHz / 256 MB | on Usenet. _\_v
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
alt.cracks.nl,alt.nl.telebankieren,nl.comp.crypt,nl.financieel.bankieren,nl.juridisch
Subject: Re: weten we die PIN?
Date: 6 Dec 2000 11:11:18 -0000
In nl.juridisch David Dylan <[EMAIL PROTECTED]> wrote:
> On Wed, 06 Dec 2000 10:32:38 GMT, [EMAIL PROTECTED] (David Dylan) wrote:
> PS: Iemand enig idee waar dit wordt bijgehouden? Bij de bank of op de
> automaat?
_wat_ wordt bijgehouden ?
--
Grobbebol's Home | Don't give in to spammers. -o)
http://www.xs4all.nl/~bengel | Use your real e-mail address /\
Linux 2.2.16 SMP 466MHz / 256 MB | on Usenet. _\_v
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Simulataneous encryption and authentification (was IBM's new algorithm)
Date: Wed, 06 Dec 2000 13:31:21 +0100
[EMAIL PROTECTED] (David Wagner) wrote:
> Francois Grieu wrote:
>> I tentatively propose the following symetric key encryption and
>> message authentication technique:
>>
>> Message Authentication and Encryption
>> - pad message as usual to make it n blocks of b bits M[i]
>> - compute S = M[0] XOR M[1].. XOR M[n-1]
>> - encipher and transmit the ciphertext
>> C[0] = ENC(S)
>> C[i] = ENC(M[i-1] XOR C[i-1]) for i in [1..n]
>
> This is not secure under chosen-message attack (as) the adversary
> can get the encryption of any block B he likes with a single
> chosen-message query.
Yes this is very weak under ITERATIVELY chosen message attack. The
attack cost is low, only 1 more query than the padded message size,
much below the O(2^(b/2)) attack I was thinking of [*], which contrary
to what I wrote was designed for NON-ITERATIVELY chosen messages.
I still tend to hope my countermeasure of inserting a random
initialisation vector at M[0] (that the attacker can not choose)
is somewhat effective.
Francois Grieu
[*] Rapvcure zrffntrf Z bs gur sbez Z[0], Z[1]=~Z[0], Z[2]=~Z[3], Z[3]
jvgu enaqbz Z[0], naq enaqbz Z[3] jvgu cebccre cnqqvat, hagvy
gurer vf n pbyyvfvba ba P[2] va gur plcuregrkg sbe zrffntrf Zn naq Zo.
F vf 0 ba nyy zrffntrf, naq nyy P[0] ner vqragvpny.
Jr pna pbzchgr gjb nqqvgvbany inyvq pvcuregrkg:
P[0], Pn[1], Pn[2], Po[3], Po[4] tvivat Zn[0], Zn[1], Zo[2], Zo[3]
P[0], Po[1], Po[2], Pn[3], Pn[4] tvivat Zo[0], Zo[1], Zn[2], Zn[3]
NB: Rot-13 was hardly secure enough for this one !
------------------------------
From: Jorgen Hedlund <[EMAIL PROTECTED]>
Subject: Idea for ciphering? (correction w/ addition)
Date: Wed, 06 Dec 2000 13:48:38 +0100
Reply-To: [EMAIL PROTECTED]
(correction with some additions)
I was trying to sleep last night when I got to think of this
cipher algorithm. Well, not exactly an algorithm, more like
an idea for one.
Imagine a statemachine, and its state transition table (STT).
For example if the alphabet consists of {a,b,c,d, EOS} and the
machine has 4 states, this could be one STT:
chr -> a b c d
--------+----------------
state 1| 2 3 4 1
2| 4 3 2 1
3| 1 3 2 4
4| 4 2 3 1
Then imagine that each state do some transformation of the
character. Let's denote this transformation Tn() for
state n.
For instance if the transformations are simply some kind
of substitution, then their keys could be like this:
T1() key = abcd -> EwGy
T2() key = abcd -> %thE
T3() key = abcd -> !ikz
T4() key = abcd -> &hus
Then using this presettings, a string "bddacda" would be
encoded as: (n+ = next state)
Start state = 1
T1(b) = w, n+ = 3
T3(d) = z, n+ = 4
T4(d) = s, n+ = 1
T1(a) = E, n+ = 2
T2(c) = h, n+ = 2
T2(d) = E, n+ = 1
T1(a) = E, n+ = 2
<EOS>
result "wzsEhEE"
The public key are the above STT, while a private key would
consist of a reversed STT.
Without the reversed STT, there would be really difficult to
decrypt. Right?
# addition: I see my own flaw in this public/private STT thing
# because if you have the public STT, you can calculate the
# private one. Doh! Any suggestions to make it otherwise?
The Tn()'s should probably be something else than standard
substitution, but I used it as an example.
And, ofcourse, the STT would be a 256*<no of states> grid,
if we use bytes.
The STT should be randomly generated, ofcourse.
Well, any comments?
Any mathematical stuff that might be interesting? (I like 'em
but can't produce 'em)
BR/jh
--
==========================================
J�rgen Hedlund, Software Engineer
Ericsson Software Technology, BGw
==========================================
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: ---- Are AES algorithms export restricted?
Date: Wed, 6 Dec 2000 12:57:35 -0000
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Bill Unruh wrote:
> >
> > Greggy <[EMAIL PROTECTED]> writes:
> >
> > >It just seemed to me as I was reading another post here that none of
> > >the AES algorithms could possibly be export restricted from within the
> > >US since they were all published during the AES contest. Am I
> > >correct? Or did I miss something in my thinking here?
> > They are all export restricted. It is entirely legal to export printed
> > copies of algorithms. It is just not legal to export code without a
> > license (unless it is opensource code, in which case it does not need a
> > license, ..... read the law.)
>
> They are all freely available outside of nations having
> export regulations via the web page of NIST. So I suppose
> one way to cope with the situation could be to leave a
> stub in the delivered code of an application containing
> such an algorithm as a component and let the customer to
> download the necessary piece of 'sinister' and 'forbidden'
> stuff himself and plug it in.
This won't necessarily solve the problem because any software that contains
an interface designed to support a plug-in cryptographic capability may
itself be subject to export controls even though it contains no
cryptography.
This has changed a bit recently but I believe that some controls on such
software still exist in the US.
Brian Gladman
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: ---- Are AES algorithms export restricted?
Date: Wed, 6 Dec 2000 13:02:37 -0000
"Greggy" <[EMAIL PROTECTED]> wrote in message
news:90jucc$ik$[EMAIL PROTECTED]...
> It just seemed to me as I was reading another post here that none of
> the AES algorithms could possibly be export restricted from within the
> US since they were all published during the AES contest. Am I
> correct? Or did I miss something in my thinking here?
You are correct in respect of 'public domain' source code but the situation
in respect of actual implementations is more complex.
For example, it seems unlikely that a high grade AES implementation in
hardware would be free of export controls from the ***US***.
But things have changed a lot recently so even this might now be possible -
I am not up to date on where things stand in the US.
Brian Gladman
------------------------------
** 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
******************************
