Cryptography-Digest Digest #276, Volume #11 Wed, 8 Mar 00 06:13:00 EST
Contents:
Re: An RC5-like cipher (Samuel Paik)
Re: Protocol question -- detecting patching of software (Paul Rubin)
Re: are self-shredding files possible? (Michael Sierchio)
Re: ascii to binary (Dennis Ritchie)
Re: An RC5-like cipher (Paul Rubin)
TEA analysis (Raphael Phan Chung Wei)
authentication ("Ghislaine Resplandy")
Re: PC risks analysis? ("ink")
Cyberrella ("Nasser Ismaily")
Re: Best language for encryption?? (Paul Schlyter)
Re: Passphrase Quality ? (John Underwood)
Re: differential cryptanalysis ([EMAIL PROTECTED])
Re: libdes / Linux ELF shared library (Eric Young)
Re: Universal Language: was The Voynich manuscript (Mok-Kong Shen)
Re: why xor?(look out,newbie question! :) (Mok-Kong Shen)
Re: Cellular automata based public key cryptography (Mok-Kong Shen)
Re: Excel password remover (_Andy_)
Re: Best language for encryption?? ("Douglas A. Gwyn")
Re: Free-MAC mode (Wei Dai)
----------------------------------------------------------------------------
From: Samuel Paik <[EMAIL PROTECTED]>
Subject: Re: An RC5-like cipher
Date: Wed, 08 Mar 2000 05:24:25 GMT
Paul Rubin wrote:
> I'd thought of something like this too, but with 64-bit blocks and 12
> "rounds" (an RC5 round is like two of what most other ciphers call a
> round), it needs 50 bytes of key-dependent S-box data, which is more
> than the available amount of RAM in the system under discussion.
If I'm not misunderstanding RFC 2040, 64-bit RC5 with 12 rounds uses
12*8 = 96 bytes for the expanded key data
I was thinking that perhaps Carl could store the key data in
FLASH/EEPROM, since it doesn't need to change unless the key changes,
unlike RC4 which changes the internal state.
> If that much RAM is available, it might also be possible to code
> CAST in 50 bytes, again using a precomputed key schedule.
I'd suggest you try coding anything in this architecture, it's
painful to get anything into 50 bytes. I'd almost rather try
this on a 6502, at least some instructions are 1 byte here...
Scott Contini wrote:
> I question whether you really want to leave out the pre-whitening.
> I haven't read the most recent attacks on RC5, but I would suspect
> that leaving out this pre-whitening will allow differential attacks
> to extend a few more rounds. Therefore, my comments in the next
> paragraph assume you put the prewhitening back in (well, at least
> putting A = A + S[0] back in).
Well, I was trying to trade code memory for data space on the hope
that Carl could free up a bit of the megabyte of EEPROM even if
he couldn't free up any more program memory, so more rounds for
simpler code. Handling the whitening adds a few instructions.
BTW, I had been working from the assembly for decryption, when
I posted the outline, I had to transliterate back into C encryption,
which I screwed up. I'll probably post a revised C description later.
The structure you noticed was intentional, I tried to keep it as
similar to RC5 as I could.
--
Samuel S. Paik | http://www.webnexus.com/users/paik/
3D and multimedia, architecture and implementation
You dont know enough about X86 or kernel architectures to argue with me.
- <38b2dc12$0$[EMAIL PROTECTED]> "Leon Trotsky" to Terje Mathisen
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Protocol question -- detecting patching of software
Date: 8 Mar 2000 05:32:42 GMT
Edward A. Falk <[EMAIL PROTECTED]> wrote:
>Is it possible to design a protocol by which the server could
>challenge the user's software to ensure that it hasn't been
>modified?
>
>Any thoughts on this?
You're trying to make tamper-resistant software when it's already very
difficult to make tamper-resistant HARDWARE. Basically you face the
same problems as everyone else who's tried to devise a software based
copy protection scheme. They pretty much all get broken.
There are noises that forthcoming Intel cpu's will include hardware
support for doing what you want, e.g. by allowing digitally signed (or
even encrypted) code segments. I personally see that as even worse
Big Brother-wise than the Pentium III serial number, but my opinion
isn't likely to stop it. :-P
------------------------------
From: Michael Sierchio <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: are self-shredding files possible?
Date: Tue, 07 Mar 2000 21:40:33 -0800
Paul Koning wrote:
> That's not how I read what they say on the website. What you
> describe makes no sense at all. If you only think about
> two parties and neither is malicious, all you need is
> plaintext email.
It's clear that you just don't get it -- what DI is protecting
against is: unwanted disclosure of sensitive emails that
are internal to a company (cf. US vs. Microsoft). So, even
deleted files that might normally be retrieved from backups
or forensic analysis are safe from disclosure.
What is provided is a secure deletion (retention policy)
mechanism for any kind of electronic doc -- email is just
an obvious first step.
The whole point of the exercise is to be able to explain to
a judge why your hard drives shouldn't be surrendered...
------------------------------
From: Dennis Ritchie <[EMAIL PROTECTED]>
Subject: Re: ascii to binary
Date: Wed, 08 Mar 2000 05:52:10 +0000
Paul Koning wrote a snippet amidst a large post, the rest of
which I don't quarrel with:
> BTW, Teletype is not Ma Bell, it's a separate company.
Teletype did become "Ma Bell" around 1930, as a subsidiary
of Western Electric, itself a subsidiary of AT&T. Teletype,
along with WE, disappeared in the wake of the 1984 divestiture.
There does seem to be a www.teletype.com now, but it looks
entirely unrelated.
Dennis
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: An RC5-like cipher
Date: 8 Mar 2000 05:53:40 GMT
In article <[EMAIL PROTECTED]>,
Samuel Paik <[EMAIL PROTECTED]> wrote:
>Paul Rubin wrote:
>> I'd thought of something like this too, but with 64-bit blocks and 12
>> "rounds" (an RC5 round is like two of what most other ciphers call a
>> round), it needs 50 bytes of key-dependent S-box data, which is more
>> than the available amount of RAM in the system under discussion.
>
>If I'm not misunderstanding RFC 2040, 64-bit RC5 with 12 rounds uses
>12*8 = 96 bytes for the expanded key data
Whoops, yes, you're right, that's even worse than 50.
>I was thinking that perhaps Carl could store the key data in
>FLASH/EEPROM, since it doesn't need to change unless the key changes,
>unlike RC4 which changes the internal state.
I think the idea was to download a large encrypted content file once,
then load it into several devices that use different keys. So the
content was going to be accompanied by a small header encrypted
by the device key, giving the key for the content file. To program
several units you'd send several headers but only have to send the
content once. But it means you have to be able to load different
content keys into the device.
>> If that much RAM is available, it might also be possible to code
>> CAST in 50 bytes, again using a precomputed key schedule.
>
>I'd suggest you try coding anything in this architecture, it's
>painful to get anything into 50 bytes. I'd almost rather try
>this on a 6502, at least some instructions are 1 byte here...
Maybe you're right, I don't know.
------------------------------
Date: Wed, 08 Mar 2000 14:31:02 +0800
From: Raphael Phan Chung Wei <[EMAIL PROTECTED]>
Subject: TEA analysis
I note that there was a post by R. Fleming to sci.crypt in 1996 about an
attack on a weakened version of TEA. Anyone has a record of that, or
are the posts to sci.crypt archived anywhere?
--
Regards,
Raphael Phan
Faculty of Engineering
Cyberjaya Campus
Multimedia University
+603-83125314
------------------------------
Reply-To: "Ghislaine Resplandy" <[EMAIL PROTECTED]>
From: "Ghislaine Resplandy" <[EMAIL PROTECTED]>
Subject: authentication
Date: Wed, 8 Mar 2000 08:38:03 +0100
Using authentication without non-repudiation based on public key technology,
bob can forge alice's signature on a message to himself (he knows the secret
key alice used for a message m).Why can't he forge alice's signature on a
message to someone else?
Thanks
--
Ghislaine Resplandy
------------------------------
From: "ink" <[EMAIL PROTECTED]>
Subject: Re: PC risks analysis?
Date: Wed, 8 Mar 2000 09:11:50 +0100
Mykhailo Lyubich wrote...
>Hi there
>
>does somebody know an official source (report, standard)
>with "how vulnerable be a PC environment"?
>I look for risk analysis survey or research report
>for software encryption and password based data storing
>on user's workstation.
>
>I appreciate your help.
>
>Mykhailo Lyubich
You might want to take a look at the FIPS publication
800-12 An Introduction To Computer Security: The NIST Handbook.
HTH
Kurt
------------------------------
From: "Nasser Ismaily" <[EMAIL PROTECTED]>
Subject: Cyberrella
Date: Wed, 8 Mar 2000 01:23:13 +0400
Does anyone know how I can get hold of encryption software written by
Cyberella?
Thanks in advance......
Nasser
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Best language for encryption??
Date: 8 Mar 2000 08:49:12 +0100
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> Paul Koning wrote:
>
>> C is indeed very weakly typed.
>
> People keep saying that, but I don't think they're right.
> Except for mixed-mode arithmetic (a deliberate feature),
> C is quite strongly typed.
If you think so, you don't know what "strongly typed" is.
In C, unsigned ints and signed ints can be assigned to one another
without a cast -- that would not be the case in a strongly typed
language.
In C, short ints and long ints can be assigned to one another wihtout
a cast -- that would not be the case in a strongly typed language.
In C, a typedef'ed data type merely becomes a synonym for the base
data type, and can be freely assigned from/to it -- that would not be
the case in a strongly typed language, where it would become its own
distinct data type.
In C, enum's are really int's with some symbolic constants added, and
they can freely be assigned to/from regular int's -- that would not
be the case in a strongly typed language, where enums would become
their own distinct data types.
> There are explicit loopholes (casts),
In C, virtually anything can be cast into virtually anything else --
that would not be the case in a strongly typed language, where the
ability to cast a data type into another data type is restricted
on purpose.
> and, alas, a "generic" pointer type void* that
> freely interconverts with all object-pointer types,
I guess that's the last nail in the coffin for your idea of C as a
"stronlgy typed language".... such a "feature" would be a cardinal
sin in a truly stronlgy typed language.
> but these occur only if the programmer chooses to use them.
> The default style of programming in C is quite tightly
> constrained by the types of the entities.
I think you should try to do some programming in Ada or Pascal
(Standard Pascal, not Turbo Pascal or Delphi, which is considerably
more permissive) -- that would probably be an eye-opener on your view
of "quite tightly constrained by the types of the entities": in
comparison to Ada and Pascal, C has very few restrictions and allows
the programmer to do virtually anything.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: John Underwood <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Passphrase Quality ?
Date: Wed, 8 Mar 2000 08:47:02 +0000
On Tue, 7 Mar 2000 at 21:02:21, Michael A. Greenly
<[EMAIL PROTECTED]> wrote in alt.security.pgp:
(Reference: <nnjx4.182$[EMAIL PROTECTED]>)
>It seems to me there is no solution? If you can be tortured into giving
>up the password you can also be tortured into giving up the password
>generation mechanism....
Is anyone in this whole discussion undertaking any risk analysis? What
information are you trying to protect that you are considering
countering torture as a means of getting it out of you?
--
John Underwood
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: differential cryptanalysis
Date: 8 Mar 2000 09:41:50 GMT
Why isn't the message from "Douglas A. Gwyn" you're responding to present on
the server any more?
Anyway, using "+" to denote exclusive disjunction might do in a context were
it is clear that addition is not referred.
In a previous article, netpal2u <[EMAIL PROTECTED]> writes:
>In article <[EMAIL PROTECTED]>,
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] wrote:
>> > The most appropriate symbol for xor would be a "V" with a cross
>> > stroke. That's how the boolean operator is denoted in formal logic.
>>
>> Except when some other symbol is used.
>> (Most of us use "+" and establish that the context is GF(2).)
>>
>Hello Douglas,
>I know nothing about this "crypto" stuff, just wanted to say hello.
>Why are you using your real name?
>
>Ah yes could you tell me why "they" where putting so much craps about
>aliens and ufo stuff on "that" "your?" web site? I real wonder?
>Another hoax area51 style?
>
>"NSA's activities are conducted in accordance with the highest
>constitutional, legal and ethical standards and in compliance with
>statutes and regulations designed to protect the privacy rights of U.S.
>persons"
>a reminder because I am not using for this post an anonymous news
>posting.
>
>My regards to Dr. Sadler.
>take care...
>
>
>
>--
>Charlie Chan
>"Chips off the Old Chopstick..."
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
----- Posted via NewsOne.Net: Free Usenet News via the Web -----
----- http://newsone.net/ -- Discussions on every subject. -----
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
From: Eric Young <[EMAIL PROTECTED]>
Subject: Re: libdes / Linux ELF shared library
Date: Wed, 08 Mar 2000 19:58:16 +1000
Matthias Bruestle wrote:
> I want to compile libdes as position independent code because I
> want to compile it into a PAM module which is a shared library.
> I have not yet decided if I compile it into a shared library or
> not (security?).
>
> Can I use the assembler files for this or not? I ask this, because
> position independent code reserves one register. Has someone maybe
> build already a source rpm for this? I haven't found one.
Assuming this is the libdes I'm familiar with :-), the code saves
esi, edi, ebp and ebx.
Some x86 calling conventions require ebx to be saved, this is probably the
'extra register' you are talking about.
So it should be shared library safe (I've compiled it that way in the past :-)
eric
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Universal Language: was The Voynich manuscript
Date: Wed, 08 Mar 2000 11:17:13 +0100
Douglas A. Gwyn wrote:
>
> Mok-Kong Shen wrote:
> > I agree with you. However, I think that it is possible to design,
> > first of all, a grammar that is simple, i.e. rational and without
> > exception rules, redundancies etc. etc. ... The vocabulary should
> > also be well designed, ...
>
> Yes, artificial languages have tried to do all that. It isn't as
> simple as you might think. For one thing, if the language is meant
> to remain a "living" language, it needs to accommodate expansion as
> new entities and concepts develop. If you try to plan in advance
> for the categories for such things, you are bound to fail.
>
> Besides Esperanto, another artificial language that has been of
> some mild interest in the crypto community is Lincos.
I see the matter from a somewhat different point of view. To cater
for the expansion of the language one can either design the
language to be 'extendable' (cf. attempts in doing that in programming
languages), providing standard conventions for extentions and
let the public to do that as is in most natural languages today,
or establish an academie as is the case in French. Much bigger
barriers to success are likely to be elsewhere. English speaking
people wouldn't wellcome that idea for diverse reasons. English
is already defacto 'universal', why waste resources to learn
another? Loosing the status of being universal could have impacts
on infrastructures that are tightly connected to English. Further,
what I think could be a major disadvantage of an artificilly
created universal language, is that there is a probability that the
new language succeeds so well as to obsolete the natural languages,
leading to very substantial losses of the values accumulated in the
literatures of these.
Isn't Lincos that language invented for establishing communication
with extracelestial intelligent beings? I am a bit surprised by
what you mentioned, since I thought Lincos was designed so that
any 'dumb' person would be able to understand the communications.
Now, if that is the case, wouldn't an opponent have an exceptionally
easy task in his hands?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: why xor?(look out,newbie question! :)
Date: Wed, 08 Mar 2000 11:17:19 +0100
Mike Rosing wrote:
>
> doesn't matter. Most processors have a bit you can flip which will
> change the
> storage order in ram. It just passes the data thru a permutation
> register
> which doesn't take very many gates.
At least in three types of machine I have worked previously at
the assembly level, including the IBM/360, I don't remember to have
seen the instruction manuals mentioning the bit you called attention
to. I am not familiar with Intel's instructions. Are you sure there
is such a bit? Does it have a particular name in the manuals?
Thanks.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Cellular automata based public key cryptography
Date: Wed, 08 Mar 2000 11:17:26 +0100
[EMAIL PROTECTED] wrote:
>
> If "ordinary" CA are given an appropriate
> initial configuration then they can simulate a
> universal Turing Machine (TM) and thus
> perform general computation. The key feature
Doesn't this mean that an ordinary CA is as powerful as a
universal TM? Could you give references? Thanks.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (_Andy_)
Subject: Re: Excel password remover
Reply-To: [EMAIL PROTECTED]
Date: Wed, 08 Mar 2000 10:53:48 GMT
On Wed, 08 Mar 2000 01:53:22 GMT, [EMAIL PROTECTED] (Steve K)
wrote:
>On Tue, 7 Mar 2000 17:58:19 +0100, "Tobiass Mai" <[EMAIL PROTECTED]>
>wrote:
(snip)
>
>Time to kick the security "issues" that come attached to MS Office off
>our Windows boxes? I think so...
>
>:o)
My particular favourite being setting byte 0x42 in a "password
protected" Office 97 MDB to 0x86, and disabling the "protection"! =)
Andy
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Best language for encryption??
Date: Wed, 08 Mar 2000 10:56:21 GMT
Paul Schlyter wrote:
> Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> > Paul Koning wrote:
> >> C is indeed very weakly typed.
> > People keep saying that, but I don't think they're right.
> > Except for mixed-mode arithmetic (a deliberate feature),
> > C is quite strongly typed.
> In C, unsigned ints and signed ints can be assigned to one another
> without a cast -- that would not be the case in a strongly typed
> language.
> In C, short ints and long ints can be assigned to one another wihtout
> a cast -- that would not be the case in a strongly typed language.
That's part of the "mixed-mode" arithmetic I referred to. Since
such operations are value-preserving, it is relatively benign. It
could be "fixed" by having only one integer type, but that would
be a disservice to the intended applications.
> In C, a typedef'ed data type merely becomes a synonym for the base
> data type, and can be freely assigned from/to it -- that would not
> be the case in a strongly typed language, where it would become its
> own distinct data type.
Typedef is a syntactic convenience, and despite the name does *not*
create a new type in C. The actual formation of a new *type* in C
is done via declaration of a structure (or union) type.
> In C, enum's are really int's with some symbolic constants added,
C enumeration types are indeed a kludge, actually specified as
being chosen from the available integer types rather than making
a new type.
> In C, virtually anything can be cast into virtually anything else --
> that would not be the case in a strongly typed language, where the
> ability to cast a data type into another data type is restricted
> on purpose.
No, a strictly conforming C program may convert types (via cast)
only when there are well-defined semantics. When it does make
sense, what benefit would there be in not allowing the conversion?
> I think you should try to do some programming in Ada or Pascal
> (Standard Pascal, not Turbo Pascal or Delphi, which is considerably
> more permissive) -- that would probably be an eye-opener on your view
> of "quite tightly constrained by the types of the entities": in
> comparison to Ada and Pascal, C has very few restrictions and allows
> the programmer to do virtually anything.
I have used Pascal, and indeed it does make it hard to do perfectly
reasonable things that C cleanly supports. Is that an advantage?
Note that Pascal has *only* a generic pointer type, not the more
strongly typed pointers of C (disregarding void*).
------------------------------
From: Wei Dai <[EMAIL PROTECTED]>
Subject: Re: Free-MAC mode
Date: Wed, 8 Mar 2000 03:08:00 -0800
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> Following on from the discussion of block modes which try to exhibit error
> propagation to give a MAC or MDC combined with a block mode in the thread
> with subject "avoid man-in-the-middle known plaintext attack using a stream
> cipher", here's a block mode Anton and I have been working on.
>
> encryption is:
>
> y_i = E_k( x_i + y_{i-1} ) + x_{i-1}
>
> and decryption is:
>
> x_i = D( y_i + x_{i-1} ) + y_{i-1}
>
> In practice to make a MAC out of this you would append a fixed block to the
> message and verify that this fixed block was preserved on decryption. This
> block could be public, or perhaps could be the IV, or a separate key.
There seems to be a problem when the attacker has known plaintext. Let's
take a one-block message example x1, and supppose the fixed check block
is x2 and x0 is used as IV and y0 is fixed (a similar attack exists when
x0 is fixed and y0 is used as IV).
The attacker changes the IV to a0 = y2+x1+D(y1+x0)+x2, the ciphertext to
b1 = D(y1+x0)+x2, and the MAC to b2 = y1+x0+D(y2+x1)+y0. That should be
a valid ciphertext+MAC for the forged plaintext a1 = D(y2+x1)+y0.
------------------------------
** 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
******************************
