Cryptography-Digest Digest #425, Volume #12 Sat, 12 Aug 00 10:13:01 EDT
Contents:
Re: Interesting new Rijndael paper by Robshaw & Murphy: (Mok-Kong Shen)
Re: WAP gateway to WWW - Will this configuration really fly from a security
perspective ? ("Tor Rustad")
Re: BBS and the lack of proof (Mark Wooding)
Re: Best AES candidates ?? (DJohn37050)
Car Radio Code Encryption. (No Name)
Re: 1-time pad is not secure... (Guy Macon)
Re: 1-time pad is not secure... (Guy Macon)
Re: 1-time pad is not secure... (Guy Macon)
Re: 1-time pad is not secure... (Guy Macon)
Question? ("Melinda Harris")
Re: 1-time pad is not secure... (Guy Macon)
Re: Secure Operating Systems (Guy Macon)
Re: Multiple encryption passes (ArchimeDES)
Re: Multiple encryption passes (ArchimeDES)
Re: Question? ("Trevor L. Jackson, III")
Re: chap authentication scheme? (David P Jablon)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Interesting new Rijndael paper by Robshaw & Murphy:
Date: Sat, 12 Aug 2000 10:38:04 +0200
Sam Simpson wrote:
>
> "Rijndael splits very cleanly into a layer of S-box transformations,
> a linear diffusion layer designed to provide mixing across the block,
> and a subkey layer.
>
> In this note we consider the linear diffusion layer of Rijndael. We
> derive the interesting property that any input text (or any input
> difference) to the linear diffusion component of Rijndael is always
> mapped to itself after at most 16 applications of the linear
> diffusion transformation. "
The layer you treated, which is the pair ShiftRow and
MixColumn, is, as you described, sandwitched between the
ByteSub and the AddRoundkey layers. You are evidently
having concerns that, if the protection contributed by
the outer layers thereby is not sufficiently good, then
there would be a problem. But that 'if' is not yet
substantiated by evidence and seems unlikely. I guess
that one of the high and admirable arts of designers of
all AES candidates is to satisfy the requirement that
the algorithm should be runnable on low-end hardware,
which means eliminating as much 'complexities' as
possible in elegant and optimal ways but YET offering
high enough strength, thus enabling the code to be small
and fast running. In another occasion, I have questioned
whether it wouldn't have been better to relinquish the
'one thing fits all' philosophy underlying the requirement
and have instead a number of 'levels' of implementation of
the algorithms to suit the application needs. One could
then farily easily permit more 'complexities' at higher
'levels'. An example case would be substituting the single
constructs with poly-alphabetical substitutions, more
complex transpositions and more complex Hill matrices in GF
and have these vary in different rounds. But that would
mean requiring software implementation, I guess.
M. K. Shen
------------------------------
From: "Tor Rustad" <[EMAIL PROTECTED]>
Subject: Re: WAP gateway to WWW - Will this configuration really fly from a security
perspective ?
Date: Sat, 12 Aug 2000 11:33:22 +0200
"Paul Rubin" <[EMAIL PROTECTED]> wrote in message
> Mark Currie <[EMAIL PROTECTED]> wrote:
< snip >
> >The only way that I can see an acceptable security model for
> >wireless-WWW commerce with end-to-end security is to have WWW hosts
> >implement WTLS or run WAP servers. This sounds like a tall order to me.
>
> I think the e-commerce sector isn't delighted about the situation, but
> it doesn't mind that much. The idea is the WAP gateway is located at
> the wireless telco and is supposed to be secure. (Of course, that's
> the same wireless industry operating it that brilliantly gave us the
> A5 ciphers and millions of cloned phones, so some of us stay skeptical
The problem here is not only technical, but also political. Telecom controls the
SIM (or WIM), but the financial institutions controls our bank account. Hence,
there is two worlds which clashes together, and they need time to put the
borders down. The sad part, is that as long as the two parts have difficulties
talking together, we will see poor technical solutions out there.
There is also two different securty worlds (at least in my country), and the
finacial security community for does not trust the telecom security community.
There is simply too big difference in securing real big mony, compared to
securing phone calls. This 'high value' expierence is not learned overnight, and
for those of us who works on the finacial security side, we very much keep our
expierence internally.
The WAP GW is a true man-in-the-middle, but this is not the most difficult
sucurity problem for me. Today many transactions go trough GW and routers
without being a major security risk, we already have secure means/protocols of
doing this. The problem starts with the chip (SIM/WIM), as long as the banks
have no control over this security, we simply can't design a system with
end-to-end security. It doesn't matter how secure the WAP GW is, if we can't
trust the chip card used the mobile phone, there is no way to trust the
transaction.
There is a chain of trust, and it begins even before the chip is produced.
However, it doesn't help much that the A3, A5/1,A5/2 and A8 has been reversed
engineered, and some major design flaws where discovered during the proccess.
Even if these algorithms had been cryptographic strong, there are many other
important security issues like key management, card production, card issuance
etc.for which there are lessons yet to be learned for the mobile community.
We don't need to go into difficult areas at all, how can we view the mobile as a
secure PIN entering device, when it is not designed as such? ATM and POS PIN
entring devices has encrypted keyboard controllers, my personal mobile bip a
different tone for each PIN digit I enter!
We have already seen some results of the two world problem, I know one mobile
phone which have internally two chip slots, one for the SIM and the other for a
bank ICC. In many pilots, the mobile has a built in smartcard reader, where you
can insert your bank card. Given the small size of a modern wireless phone, and
the size of a bankcard, this seem to lead into some practical difficulties. I
don't know yet any pilots where telecom and banks uses the same chip, I guess
there is a reason for this.
For the time being, the e-commerce fraud is mainly with creditcards on the net.
Visa and Mastercard are well on their way to stop this, with their push towards
EMV and SET. When this migration path has completed, I expect we will see the
real test of the mobile e-commerce security. The fraud will never stop, only
take other forms.
--
Tor K Rustad
Technical Chief of Security
Norwegian Banking Payment Central (BBS)
(Opinions expressed here are my own.)
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: BBS and the lack of proof
Date: 12 Aug 2000 10:24:45 GMT
Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote:
> There appears to be a gap here. I'll try to approach from the other
> end. Please indicate the point at which this sequence goes astray.
>
> (1) A BBS generator can have a short (traversable) cycle.
I'll buy that.
> (2) From (1): Given a short cycle, the output is predictable by
> traversal.
Yes. However, this glosses over the more difficult point of where you
get the cycle from. Given your previous numbers, we see that there's a
2^{-224} probability of choosing one by accident, and no particularly
obvious better way. And certainly a normal user isn't going to be going
out of his way to use clever algorithms to find short cycles.
>From the attacker's point of view, waiting for a user to accidentally
use a short cycle is 2^{224} effort, but at least it doesn't cost much,
and he can watch telly while he's waiting for a short cycle to turn up.
Note, however, that 2^{224} effort is considerably more than what's
required to factor 2048-bit numbers (extrapolating wildly from the
numbers given in Silverman's `A Cost-Based Security Analysis of
Symmetric and Asymmetric Key Lengths', RSA Security Bulletin 13). So
waiting for a short cycle to turn up by the user stumbling over it isn't
a clever attack, and factoring looks much better.
The (Vazirani and Vazirani) security warranty only says `as difficult as
factoring'. Worrying about things harder than factoring probably isn't
a good use of braincells.
Now, I don't know whether your numbers are right, but they pass a quick
plausibility test this early in the morning.
> (3a) From (2): Given predictable output enciphered messages can be
> deciphered.
Yes.
>
> (3b) From (2): Given predictable output a QR solution is easy (as
> previously defined).
Yes.
> (4) From (3b): short cycle imp-> predictable generator imp-> QR
> solution imp-> QR is not hard.
That depends. We have certainly found the relationship that finding a
short cycle is no easier than the quadratic residuosity problem, since
we can solve the latter easily given the former (and, indeed, we can
factor too). The big question now is how we interpret that.
I'll start talking about factoring now, rather than QRP. It doesn't
make a great deal of difference: the only way we know of solving QRP is
to factor anyway, and the argument about BBS doesn't change that.
I start with the assumption, because it seems a good one, that factoring
is hard. If finding short cycles in a BBS is at least as hard as
factoring, that's good enough for me. We've proven a reduction. Now
all I need to do is worry about how hard factoring really is.
Maybe cycle-finding is a good way of factoring. I doubt it; it's
certainly not where the factoring experts are looking to solve the
problem.
> In your conclusion you used the opposite sequence, starting with QRP
> difficulty as an assumption and concluding that predicting the
> generator is hard.
Yes, indeed. That's what Blum, Blum and Shub's 1982 paper tells us.
> It appears that this conclusion contradicts item (2). Yet item (2) is
> a simple deduction from item (1). So either a BBS generator cannot
> have short cycles or the deduction from (1) to (2) is flawed. Which
> is it?
The assumption in 2 is the problem.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 12 Aug 2000 12:19:17 GMT
Subject: Re: Best AES candidates ??
Well, I did hear it from the horse's mouth (that is, NIST) that the IP
statement required for all submittals was carefully crafted to not imply a
single winner and would be valid if multiple winners were chosen.
Don Johnson
------------------------------
From: No Name <[EMAIL PROTECTED]>
Subject: Car Radio Code Encryption.
Date: Sat, 12 Aug 2000 10:58:15 +0100
Reply-To: [EMAIL PROTECTED]
Hi,
I am not sure if this is the best newsgroup for this kind of question,
or if you will entertain such a question.
I have an encryption problem as follows.
A sequence of four number digits is converted to a sequence of two hex
bytes.
For example, 1737 is converted to 69AB
That is the first byte is hex69 and the second byte is hexAB
I know that isn't much to go on but thats all I have.
It is commonly used in applications where a four digit code like a PIN
number or a car radio code is used.
Does anyone know how anything about this type of encryption algorithm?
If so, I would like to reverse the process and discover the 4 digit code
which is encrypted to be 3A0D
Any help appreciated.
Kind Regards
Nick
--
Nick Thomas
Email: [EMAIL PROTECTED](Removezz)
WWW: http://www.nhthomas.freeserve.co.uk
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: 1-time pad is not secure...
Date: 12 Aug 2000 12:26:42 GMT
Mickey McInnis wrote:
>That's why I said, "if you don't do it right". Don't most such
>methods of removing bias only work if you know what kind of bias
>you're removing? i.e. it's easy to remove the bias of a coin
>that has a 1% bias for heads, but if a RNG device has
>some more complicated bias, is there a generic bias removal
>system? For instance, if there was some slight bias toward every
>bit to be identical to the bit 10 positions before it, would a
>generic bias removal algorithm catch it?
There is such an algorithm. As in all things related to randomness,
you cannot prove perfect randomness or demonstrate perfect knowledge
of all possible biases, but you can use methods that make the odds
of bias above a certain very low level very unlikely.
Here is the algorithm:
First, generate a sequence of random bits using whatever method
you wish, and using bias removal for all known biases (in the case
of your coin flip, use a Von Neuman compensator). Call this RAND1.
Next, generate a sequence of random bits using a method that you
believe does not have the same sources of bias. Call this RAND2.
Repeat as often as your resources or ingenuity allows, thus creating
a collection from RAND1 to RAND[N]. Use of methods that are known
to be biased or predictable is allowed. Some of the methods that
have been suggested as inputs into this algorithm are:
Differences in time between radioactive decay events.
Noise from a Zener Diode or resistor.
Interstation FM Radio hiss.
AM Radio interference (some of which is known to be lightning on Jupiter!)
Microphone picking up traffic noise, birds singing, or children playing.
Digitized image of a lava light, bubbles in an aquarium, or a Ant Farm.
Every commercially available hardware RNG.
Various hash functions seeded by various methods.
Various PRNGs that are known to pass statistical bias detection tests.
Various chaotic systems, cellular automata, and other simulations.
Use of one of the above methods to switch between other methods.
...and the list goes on.
Final step: now that you have your collection of random sequence
candidates, XOR them with each other and call the result RANDMIX.
We know that RANDMIX will have the following properties:
[1] If a single component (RAND1 to RAND[N]) is truly random,
then RANDMIX is truly random.
[2] If a particular bias is missing from a single component,
then that bias is missing from RANDMIX.
[3] If a bias is shared by all of the methods you chose, it is
likely to also be shared by any method an attacker or crypto
researcher uses to generate random numbers.
At the end, you have a high level of confidence that RANDMIX is,
as far as any attacker can tell, unbiased and unpredictable.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: 1-time pad is not secure...
Date: 12 Aug 2000 12:57:42 GMT
Derek Bell wrote:
>
>
>Mickey McInnis <[EMAIL PROTECTED]> wrote:
>: He can also try variants of "Give me the pad for future incoming messages.
>: I'll hold you and shoot you if it doesn't work on the next message received."
>
> Then give him the fake pad and send a few dummy messages in that to
>lull him into a false sense of security.
And how do you propose letting your counterpart who is doing the sending
know to stop using the real pad and messages? Smeak out while the man
with the gun is asleep?
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: 1-time pad is not secure...
Date: 12 Aug 2000 13:16:41 GMT
Simon Johnson wrote:
>
>[EMAIL PROTECTED] (fvw) wrote:
>><8mth1u$vpt$[EMAIL PROTECTED]> ([EMAIL PROTECTED]):
>>>Can you generate truely random numbers? No.
>>yes. time between radioactive decays for instance is a
>>textbook example of a perfect random generator.
>>
>
>I query this...... Radioactive decay can be described by a
>Expodential Curve, and is therefore is not strictly speaking
>random.
That's why he specified time between radioactive decays
(Whether sucessive inter-decay times are shorter or longer.)
Also, once you start working with radioactive sources, you find
that, while the radioactive decay rate changes, this does not
imply that the rate of events detected does. Consider a sample
of Potassium isotope decaying to Argon. As the Potassium decays,
the Argon escapes, and your sample just gets smaller and lighter.
(there are compications involving Calcium, but the principle that
decay rate does not equal detected decay event rate stands).
In fact, the only reason why you hear that radioactive decay is
an exponential curve is because the rate of decay per particle
is *CONSTANT*. What you are seeing is the sample running out of
atoms that can decay. Keep the number of atoms constant and the
measured rate of deyay events will be constant.
In addition, most crypto applications measure alpha decay (we like
alpha particles because a sheet of paper blocks them - we like to
be safe). The measured rate of Alpha emission is a function of
area, not volume/mass, simply because decay events that happen
inside the sample don't make it out. This opens the door to
various geometric compensation schemes.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: 1-time pad is not secure...
Date: 12 Aug 2000 13:24:29 GMT
Douglas A. Gwyn wrote:
>
>Guy Macon wrote:
>> So why haven't you published it yourself on the Internet?
>
>I haven't had time to set up a Web site. Whenever I get
>a round tuit, that will be one of the things I'll include.
Email it to me and I will put it on the net for you.
------------------------------
From: "Melinda Harris" <[EMAIL PROTECTED]>
Subject: Question?
Date: Sat, 12 Aug 2000 13:28:17 GMT
A secret document recently intercepted discloses the following:
A virus able to infiltrate, infect and encrypt multiple hardrives? Able to
infect entire networks?
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: 1-time pad is not secure...
Date: 12 Aug 2000 13:29:38 GMT
Joseph Ashwood wrote:
>You could use a *weakened* version of OTP and use the pad as a
>key for 3DES, of course as I pointed out before there exists an
>XOR pad that will convert it to the plaintext.
There exists an XOR pad that will convert anything to anything.
The problem is deciding which one to apply.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Secure Operating Systems
Date: 12 Aug 2000 13:35:36 GMT
Mack wrote:
>
>>I keep hearing rumors of a secure version of QNX that they don't want
>>advertised...
>
>If there is it will be in the NSA approved
>security products catalog. They list other
>highly secure products as well.
Are you saying that the NSA publishes a catalog of everything they
have? I doubt it. I rather suspect that the catalog has a subset.
------------------------------
From: ArchimeDES <[EMAIL PROTECTED]>
Subject: Re: Multiple encryption passes
Date: Sat, 12 Aug 2000 13:46:04 GMT
On Thu, 10 Aug 2000 21:20:27 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote:
[...snip...]
>
>Then, surely we imagine that good care will be taken to make the key
>bits independent. Knowing some of the bits should never be allowed to
>help in knowing others.
Yes, but we have reduced the keyspace to examine in an exaustive
search.
ArchimeDES
=======================
remove DIESPAM for mail
------------------------------
From: ArchimeDES <[EMAIL PROTECTED]>
Subject: Re: Multiple encryption passes
Date: Sat, 12 Aug 2000 13:46:05 GMT
On Thu, 10 Aug 2000 23:29:47 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
[...snip..-]
>> But in this way if I the attacker could guess the algorithm used, it's
>> possible isn't it?, would know something new about the key used...
>
>If you use block ciphers, your key can e.g. consists
>of two parts, one part for selecting the algorithms and
>the other for the ciphers, or you can choose some scheme
>that is essentially equivalent. Does that cover your
>question?
Perfectly! :-)
ArchimeDES
=======================
remove DIESPAM for mail
------------------------------
Date: Sat, 12 Aug 2000 09:55:59 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Question?
Melinda Harris wrote:
> A secret document recently intercepted discloses the following:
> A virus able to infiltrate, infect and encrypt multiple hardrives? Able to
> infect entire networks?
Microsoft(tm) Office 2000?
------------------------------
From: [EMAIL PROTECTED] (David P Jablon)
Subject: Re: chap authentication scheme?
Date: Sat, 12 Aug 2000 14:05:14 GMT
A big problem with CHAP is that access to the challenge and response
provides an eavesdropper with a way to test passwords,
and enables brute-force attack. Your proposal is similarly
vulnerable, since anyone who knows s, g^x, and g^xps, can test
a guess p' by comparing ((g^x)^s)^p' ?== g^xps.
In article <8mnffc$fp4$[EMAIL PROTECTED]>,
Bill Unruh <[EMAIL PROTECTED]> wrote:
>
>One of the great advantages of the unix password authentication is tht
>the attacker cannot figure out the password from the information stored
>on the server in any way but brute force. It has the disadvantage that
>it requires the cleartext delivery of the password.
>The chap ppp authentication goes the other way-- by delivering a hashed
>response to a challenge, the attacker cannot figure out the password
>from the publically exchanged data. However the passwords need to be
>stored in the clear on the server.
>
>Would the following scheme work to overcome both? (I know srp already
>does, but it requires multiple responses which I do not believe fit
>within the chap standards.)
FYI, there are simple variations of SRP, B-SPEKE, and similar methods
that work fine for one-way authentication with just one challenge
and one response.
>The authenticator has a modulus N (prime?) and a generator g. The stuff
>stored in the database is
>username, salt s, g, N, g^ps modN
>The challenge to theuser is
>s,N, g^x modN where x is a random number
>Response is
>(g^x modN)^ps modN
>which the authenticator can compare with (g^sp modN)^x modN
>
>Does knowing g^x modN and g^xps modN for multiple (unknown) x help to find ps?
No, if you assume that p is immune to brute-force attack,
and if N is sufficiently large, etc.
======================================================
David P. Jablon
[EMAIL PROTECTED]
www.IntegritySciences.com
------------------------------
** 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
******************************
