Cryptography-Digest Digest #786, Volume #8 Tue, 22 Dec 98 14:13:03 EST
Contents:
HELP ! SMARTCARD GEMPLUS GPM2K ("Leandro")
Re: Enhancement of EBC mode ([EMAIL PROTECTED])
Re: Make Fast Random Number Generator? (Robert Davies)
Re: Meet in the middle attack? (Lutz Donnerhacke)
'Trithemius' - ever heard from? (Georg Doll)
Re: HELP! Who can decrypt this?
Journal of Craptology - first issue (Lars Ramkilde Knudsen)
Re: On living with the 56-bit key length restriction (Mok-Kong Shen)
Re: On living with the 56-bit key length restriction (Mok-Kong Shen)
Re: RSA-NULL security&Back Door (Frank Paehlke)
Re: How much of CipherSaber is it OK to post on the web? (was: CS for Dummies)
([EMAIL PROTECTED])
Re: Cryptography board game! (was: CipherSaber for Dummies?) (Paul Rubin)
Re: What is Randomness? (R. Knauer)
Re: On living with the 56-bit key length restriction (Mok-Kong Shen)
----------------------------------------------------------------------------
From: "Leandro" <[EMAIL PROTECTED]>
Subject: HELP ! SMARTCARD GEMPLUS GPM2K
Date: Tue, 22 Dec 1998 12:09:08 +0100
Hi,
I'm Leandro (MOEBIUS) i just have a problem with a Smart-card of GEMPLUS
!
I want to read an Application Area of card GPM2K (GEMPLUS) !
when i send to a Reader the ApduCommand , Reader return error number 6D00 !
The code was i use is this:
CString Lettura_GPM2K (WORD16 IDCanale)
{
int i;
INT16 Responso;
unsigned char Data[3];
BYTE DataOut[200];
G4_APDU_COMM G_FAR ApduComm;
G4_APDU_RESP G_FAR ApduResp;
CString Risultato="0";
Data[0]=0xAA;
Data[1]=0xAA;
Data[2]=0xAA;
// Presentazione della chiave alla carta
ApduComm.Command[1]=0x00;
ApduComm.Command[2]=0x20;
ApduComm.Command[3]=0x00;
ApduComm.Command[4]=0x00;
ApduComm.LengthIn=0x03;
ApduComm.DataIn=Data;
ApduComm.LengthExpected =0x00;
Responso=G4_ExchangeApdu (IDCanale,&ApduComm,&ApduResp);
if (Responso < G_OK)
{
Risultato="18"; // La chiave presentata alla carta
// risulta errata.
}
else
{
MessageBeep ((WORD)-1);
ApduComm.Command[1] = 0x00;
ApduComm.Command[2] = 0xB0;
ApduComm.Command[3] = 0x00;
ApduComm.Command[4] = 0x1F;
ApduComm.LengthIn = 0x00;
ApduComm.LengthExpected = 0x0C;
ApduResp.DataOut;
ApduResp.Status;
Responso=G4_ExchangeApdu (IDCanale,&ApduComm,&ApduResp); /* This is the
line was returned 6D00 */
Risultato=(char)Responso;
}
return Risultato;
};
Tanks in advanced !
Leandro
Sorry for my bad English!
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Enhancement of EBC mode
Date: Tue, 22 Dec 1998 11:06:56 GMT
Consider the following:
As for plaintext patterns not being concealed place a 8-byte block containing
a random value at the beginning of the file. XOR this value with your key
before decrypting-encrypting. Further XOR the key with the data block offset
from the beginning of the file. (The key is then unique per file and per
block)
To prevent manipulation of the data, split your plain-text data into 4-byte
long blocks. At the end of each block add a two byte block offset value
(offset from the beginning of the file) and a two byte checksum making an
8-byte block for encryption. (each block is then fixed to a particular
position in the file and manipulation can be discovered with the checksum.)
I believe this should solve problems 1, 2 and 3.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Robert Davies)
Subject: Re: Make Fast Random Number Generator?
Date: Tue, 22 Dec 1998 10:43:48 GMT
Reply-To: [EMAIL PROTECTED]
Jim Trek <[EMAIL PROTECTED]> wrote:
>Does anybody here make a fast random number generator or have the
>capability to design and build one that will provide 2 million or
>more bits per second for a PCI slot or a universal serial bus?
The Tundra generator goes at 20,000 bytes per second, but it
plugs into an ISA slot. You could put 4 of them in a single
PC and run them at double speed to get 1,280,000 slightly biased
slightly correlated bits per second. Quite expensive.
Quantum world claims to be making a high speed version of their
generator.
See my article on true RNGs at webnz.com/robert for address details
of the manufacturers.
Robert
------------------------------
From: [EMAIL PROTECTED] (Lutz Donnerhacke)
Subject: Re: Meet in the middle attack?
Date: 22 Dec 1998 11:25:39 GMT
* Gramps wrote:
>What is a meet in the middle attack? I have books on crypto, but they do
Assume a sequence of independed keyed block chiffres. If you are able to
tabular all possible plaintexts of the last chiffre on a given ciphertext or
all ciphertexts of the first chiffre on a given plaintext, you only need to
break the rest of the sequence and look up your result in the table.
------------------------------
From: Georg Doll <[EMAIL PROTECTED]>
Subject: 'Trithemius' - ever heard from?
Date: Tue, 22 Dec 1998 14:40:12 +0100
Hello there,
for a scientific exercise I am looking for the (complete)
"Ave-Maria-Code" from Johannes Trithemius (1462 - 1516). Can anybody
help?
cu
Georg
mailto:[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: HELP! Who can decrypt this?
Date: 22 Dec 1998 12:50:45 GMT
>77 digits is far too easy for the factoring experts and too hard for the
>factoring newbies. I think I'm somewhere in between so I did this little RSA
>exercise.
as i am a complete factoring newby, i wonder if the factorisation
is done completly automaticaly or is a more or less manually
as you suggest (if an expert is faster than a newbie)?
------------------------------
From: Lars Ramkilde Knudsen <[EMAIL PROTECTED]>
Subject: Journal of Craptology - first issue
Date: Tue, 22 Dec 1998 14:57:21 +0100
Hi
First issue can be downloaded from
http://www.ii.uib.no/~larsr/crap.html
Happy holidays.
-Lars
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On living with the 56-bit key length restriction
Date: Tue, 22 Dec 1998 15:21:58 +0100
Dr.Gunter Abend wrote:
> Why not using a common compression algorithm in order to make
> frequency analysis unfeasible? A common prefix of the compressed data
> would be some kind of "known plaintext", hence it must be avoided.
> Then the only problem would be that all people should agree to use
> that specific compression algorithm as a standard - even if it doesn't
> append its identifying prefix to the data.
>
> It is not necessary that this algorithm produces very good
> compression. The most important feature is not the reduction of the
> message size but the impossibility of a frequency test of the coded
> data. Of course, this doesn't increase the key length, but it makes
> brute force attacks slower.
>
> Is there any such kind of compression algorithm that doesn't itself
> produce a strongly non-random frequency distribution?
I guess that compression could well be a good alternative, though my
knowledge about compression methods is too poor for answering
the question you posed. So let's add compression to the list of itmes
of my original post.
I like presently to add another, namely the opposite of compression:
homophones. Using homophones has the disadvantage of increasing the
volume of transmission but does mean added trouble to the analyst.
(Note that we have to somehow lower our requirement of efficiency in
order to be able to practically meet the situation created by the
56-bit restriction.)
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On living with the 56-bit key length restriction
Date: Tue, 22 Dec 1998 15:44:14 +0100
[EMAIL PROTECTED] wrote:
>
> The problem is not export of algorithms - nobody is able to control this,
> and - much more important: There are already enough algorithms for all
> purposes. This may change with the development of new computers and new
> cryptographic attacks, but surely blowfish and AES will be strong
> algorithms while this stupid crypto law will be gone.
>
> The problem is software: Keep people from using strong algorithms in
> commercial mailtools and other IP tools, in office programs and databases
> and you are able to destroy most of the cryptographic infrastructure.
If nobody is able to control export, why does there exist export
regulations as such and why does there exist authorities whose
duty it is to exercise such controls?? (Or why did the government
officials take the trouble to agree on export controls?) In US there
exists since long time export regulations. There is no limitation to
sell or to use strong cryptos inside US at all. Only people of other
countries may not obtian strong cryptos from US, unless one offences
the law, i.e. becomes a criminal in some sense or really (I know
too little about legal matters to say about this).
> A program that does the complete job from reading from your soundcard to
> sending data to the phone line doesn't allow to add a second program to
> superencipher your communication.
>
> Once superencipherment is a single module it isn't exportable.
Modern software is structured into modules. There is certainly a
module that does a mapping from bits to bits, i.e. the proper
encryption part. If one can export two encryption pieces into a
foreign country, it shouldn't require an expert in software to
concatenate them, provided that these have compatible interfaces.
>
> > > Even export of OTPs from the US is allowed, so I'm quite sure.
> > >
> > > The main reason is: OTPs are not very useful.
> >
> > I prefer not to go far into OTP here (I plan to initiate a thread
> > related to that sometime later.) But back to the main item above,
> > employing multiple channels means simply to divide a given message
> > into several pieces and encrypt these (preferably with different
> > keys, but still using 56-bit algorithms) and send these through
> > different channels. The analyst then has the trouble of keeping track
> > of the separation done. Note in particular that the pieces may be
> > sent at different time points, i.e. intentionally non-synchron, so
> > that the identification of those pieces that belong to one and a
> > single message is a formidable one.
>
> This doesn't work for real-time communication or in cases where it is
> impossible to add communication channels.
Haven't you perpaps heard of the related subject of spread spectrum
transmissions? The availability of channels is a resource problem.
You may have that or may not. Why should there be 'impossibility'?
> > > > > > 6. Using code books.
>
> Why not simply compress data?
I acknowledge this to be an alternative. See my response to Dr. Abend.
M. K. Shen
------------------------------
From: Frank Paehlke <[EMAIL PROTECTED]>
Subject: Re: RSA-NULL security&Back Door
Date: Tue, 22 Dec 1998 17:17:32 +0100
Hello Alex,
> 2. I do not believe that in such implementation is calculated
> really an exponent m^e mod n . There is no computer
> architecture which can keep such numbers during normal
> RSA encryption process with a big enough key.
you don't need to compute m^e in order to get m^e mod n, which would
indeed be quite impractical if m, n, and e were sufficiently large.
The modular exponentiation can be done much more efficienty using a
"square and multiply" algorithm:
Let the binary representation of e be e =
e[0]+2*e[1]+4*e[2]+...+2^n*e[n].
Then m^e mod n can be calculated as follows (in pseudo C syntax):
res=1;
for (i=n; i>=0; i--) {
res = (res*res) mod n;
if (e[i] == 1) res = (res*m) mod n;
}
/* now, res==m^e mod m */
There are, of course, speedups to this simple scheme, but I just wanted
to point out the basic principle.
Hope that helps,
Frank
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto
Subject: Re: How much of CipherSaber is it OK to post on the web? (was: CS for Dummies)
Date: Tue, 22 Dec 1998 15:05:39 GMT
My primary goal in creating CipherSaber, http://ciphersaber.gurus.com, was to
demonstrate that it is impossible to ban strong cryptography. Any activity
within the law that furthers this aim is welcome. I have no claim on RC4 or
ARCFOUR, of course, and to the extent that I have added anything to the art
by coming up with CipherSaber, it is in the public domain.
If someone wants to post a complete CipherSaber program on the Internet or
incorporate CipherSaber in a commercial product, and believes they can do so
legally where they live, I have no objection.
My two restrictions are that people should display a CipherKnight certificate
only if they decoded it with a program they themselves wrote, and that the
name CipherSaber should only be used on programs or devices that actually
implement the CipherSaber 1 or 2 algorithm. The latter goal is to insure
interoperability and to prevent profiferation of a zillion variants. (If
people can agree on a simplified version for a board game, I'd be glad to
approve a name (CipherSaber Lite?) for the consensus version.)
I like the idea of publishing source code for applications that would benefit
from cryptography. There are lots of possibilities:
Crypto for hand held commputers such as PalmPilot and Windows CE
Clients for IRC, MUDs and MOOs
Utilities for encoding messages that can be pasted into chat rooms, IM and
ICQ
A simple word processor that only stores data in encrypted form (There was a
program like that for the Mac a while back called SecureEdit.)
Maybe something for the PIC microprocessors or the Basic Stamp.
And so on.
One possible way to do this would be to publish programs that use CAESER-256,
which I define as follows:
For encryption, add the first character of the input key to each character
of plaintext, mod 256.
For decryption, subtract the first character of the input key from each
character of ciphertext, mod 256.
Since the key length for CAESER-256 is only 8 bits, I don't think an object
version would be restricted in most juristictions. Whether source code would
be subject to export controls is a very interesting question. I am not a
lawyer and do not give legal advice.
Arnold Reinhold
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (marek jedlinski) wrote:
> Having very narrowly escaped a dummy award of the week (my problem with CS
> implementation was a plain old off-by-one error in array indexing that I
> took hours to spot) I'm finding myself more and more interested in the
> concept itself. I first wrote my CS program in TurboPascal for DOS, and
> then as a nice little Win95 app (Delphi 3.0). All the cryptographic
> routines (the state initialization and the actual RC4 code) live in a
> separate unit of their own; the same unit is used for the DOS and Win95
> versions.
>
> As is often the case, writing a program's engine takes significantly less
> time than devising the user-interface. I didn't put many bells and whistles
> in mine, but all the file selection, command-line parsing, passphrase
> input, error checking routines etc. are in place, and I plan to develop the
> program further. I suppose others may find my code useful - anyone would
> just drop in their own RC4 code and immediately compile a working app,
> without having to write the interface from scratch.
>
> It may or may not be a good idea to post the full application in binary
> form (possible crypto restrictions and the very idea of CipherSaber
> convince me not to) but I'd be glad to share my source code for the DOS and
> Windows interfaces. Would it be a good idea to do so? If anyone'd like to
> link to the code on my website or, better still, archive it on their own
> crypto sites, please let me know. (I don't yet have a crypto-related page,
> though this is bound to change eventually ;) I am thinking of distributing
> the ready-to-compile source code minus the RC4.PAS unit (but including the
> unit's interface section for documentation - I suppose it's equivalent to
> distributing a C header file). Would I be running afoul of any crypto
> regulations (say, US-style) in doing so? Would this be against the CS
> spirit?
>
> .marek
>
> --
> General Frenetics, Discorporated: http://www.lodz.pdi.net/~eristic/
> "I fought the Dharma, and the Dharma won." (Allen Ginsberg)
>
>
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
Crossposted-To: talk.politics.crypto
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Cryptography board game! (was: CipherSaber for Dummies?)
Date: Tue, 22 Dec 1998 05:29:02 GMT
In article <75liuo$shs$[EMAIL PROTECTED]>,
Robert Munyer <[EMAIL PROTECTED]> wrote:
>I bet you could think of some kind of similar real-world analogy
>for describing RC4. Try to think about things children do in
>elementary school. Putting pegs into holes, or marbles on a
>chinese-checker board, that kind of stuff. Remember those wooden
>IQ tests (with golf tees) that roadside diners used to have on the
>tables, to keep people busy while waiting for their food?
It's pretty straightforward to do 52-element RC4 with a deck of cards.
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: What is Randomness?
Date: Mon, 21 Dec 1998 13:07:55 GMT
Reply-To: [EMAIL PROTECTED]
On 21 Dec 1998 04:42:09 GMT, [EMAIL PROTECTED] (Dr. Yongge Wang) wrote:
>Indeed, for the randomness you may go to
>Martin-Loef's definition of randomness.
>(Chaitin has an equivalent difinition)
>but all these definitions are for infinite sequences.
One of the definitions of randomness given by Chaitin is based on
algorithmic complexity for finite sequences. You may be thinking of
another paper in which he discusses his "halting probability", Omega,
which is an infinite sequence. But then that latter discussion is
about undecideability rather than just randomness itself.
In the former paper he defines randomness as a level of algorithmic
complexity that is nearly the same as the size of the number under
consideration. He works out the probability that a number of size N is
more complex than N-10 and comes up with 0.999. He then takes that as
the working definition of randomness.
For those who may not be aware what algorithmic complexity is, it is
the same essentially as Kolmogorov complexity, namely the size of the
smallest algorithm which will output the number under consideration.
Randomness in that sense is a lack of irreducibility, since a random
number cannot be output by an algorithm unless it contains the number
in entirety.
See http://www.cs.auckland.ac.nz/CDMTCS/chaitin/
Bob Knauer
"In the general course of human nature, a power over a man's
subsistence amounts to a power over his will."
--Alexander Hamilton
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On living with the 56-bit key length restriction
Date: Tue, 22 Dec 1998 17:54:03 +0100
[EMAIL PROTECTED] wrote:
>
> > If nobody is able to control export, why does there exist export
> > regulations as such and why does there exist authorities whose
> > duty it is to exercise such controls?? (Or why did the government
> > officials take the trouble to agree on export controls?)
> > ...
>
> It is impossible to control algorithms, but it is possible to control the
> export of software.
>
> US law allows to export algorithms as long as they aren't in
> mashine-readable form while the export of cryptographic software isn't
> allowed.
In the present context we are discussing export of hardware/software.
It is these that are handled by the Wassenaar agreement. The officials
evidently suppose that the other countries are technically so weak
that they are unable to develop hardware/software from description
of cryptos. BTW, I am yet ignorant of whether it is without problems
in US to put a pure but strong crypto algorithm on the Web.
>
> It's quite a hard job to change a module without knowledge of the sources
> of the program.
It is an engineering problem, like to have bolts and nuts that have
to fit. It can be done with proper software engineering.
ne.
> > >
> > > This doesn't work for real-time communication or in cases where it is
> > > impossible to add communication channels.
> >
> > Haven't you perpaps heard of the related subject of spread spectrum
> > transmissions? The availability of channels is a resource problem.
> > You may have that or may not. Why should there be 'impossibility'?
> >
>
> Try to use spread spectrum in a phone wire or when transmitting data via
> internet.
Spread spectrum was used in this context to show you that one can
usually get more than one channel, nothing more nor less.
M. K. Shen
------------------------------
** 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
******************************
