Cryptography-Digest Digest #790, Volume #8 Wed, 23 Dec 98 08:13:03 EST
Contents:
Re: Cryptography FAQ (01/10: Overview) (Gramps)
Re: On living with the 56-bit key length restriction
Re: Cryptography FAQ (01/10: Overview) (Karl-Friedrich Lenz)
Re: HELP! Who can decrypt this? (Damian Weber)
Re: md5 sample implementation (David Broughton)
Re: HELP! Who can decrypt this? ([EMAIL PROTECTED])
Re: md5 sample implementation ("Steve Sampson")
Re: Stego in jpeg files ("Steve Sampson")
Re: On living with the 56-bit key length restriction (Mok-Kong Shen)
Re: Encryption Basics ([EMAIL PROTECTED])
Re: On living with the 56-bit key length restriction (Mok-Kong Shen)
----------------------------------------------------------------------------
From: Gramps <[EMAIL PROTECTED]>
Subject: Re: Cryptography FAQ (01/10: Overview)
Date: Tue, 22 Dec 1998 23:45:42 -1000
Bruce Schneier wrote:
>
> This FAQ is over four years old.
>
> It seems reasonable to update it. Is there a cabal in charge of the
> FAQ, or has it been orphaned?
That information is available on a need to know basis, and you don't need
to know.
>Is anyone interested in working on an update?
I can neither confirm nor deny this.
> Bruce
Many cryptographers are currently busy evaluating the AES candidates, so
we don't have time to educate the unwashed masses while we try to figure
out if Twofish is a quad-round or dual-round cipher so that we can fairly
make comparisons with the other 14 candidates. You may ask David A. Scott
if he has time to revise the FAQ verbiage. If you want his e-mail
address, just ask for it.
Gramps
------------------------------
From: <[EMAIL PROTECTED]>
Subject: Re: On living with the 56-bit key length restriction
Date: Tue, 22 Dec 1998 17:38:08 +0100
On Tue, 22 Dec 1998, Mok-Kong Shen wrote:
> [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?)
> ...
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.
> > 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.
>
It's quite a hard job to change a module without knowledge of the sources
of the program.
> >
> > > > 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'?
>
Try to use spread spectrum in a phone wire or when transmitting data via
internet.
> ...
Andreas Enterrottacher
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
From: Karl-Friedrich Lenz <[EMAIL PROTECTED]>
Subject: Re: Cryptography FAQ (01/10: Overview)
Date: 22 Dec 1998 23:17:41 -0800
In article , [EMAIL PROTECTED] says...
>
>This FAQ is over four years old.
>
>It seems reasonable to update it. Is there a cabal in charge of the
>FAQ, or has it been orphaned? Is anyone interested in working on an
>update?
I posted the following message here in July 98, under the title "Old FAQ":
"The FAQ for sci.crypt has been last modified in 1994. When I sent mail in
answer to the part of the FAQ using both "cyphertext" and "ciphertext"
pointing out that contradiction, the mail bounced back to me (user unknown).
Is there any editor of that FAQ still around on the list?"
No editor answered at the time, so I suppose it is orphaned now.
Karl-Friedrich Lenz
www.toptext.com/crypt/
------------------------------
From: [EMAIL PROTECTED] (Damian Weber)
Subject: Re: HELP! Who can decrypt this?
Date: 23 Dec 1998 09:37:46 GMT
[EMAIL PROTECTED] wrote:
: >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)?
I'm not sure what you mean by "completely automatically". Basically, the
modern heuristic algorithms consist of three steps:
1) find relations mod n
2) solve a linear algebra problem mod 2
3) construct a congruence X^2=Y^2 mod n and compute
gcd(X+Y,n)
Of course you can throw this into one program which does that automatically.
But usually this is divided into some standalone programs which are called
by hand or by shell script.
The most time consuming step is 1). For becoming fast, much practical experience
is needed. Without going into details, although the algorithms are known, you
can vary a lot of parameters and you can use different implementation techniques
depending on the hardware you employ. The newbie would start with a naive but
working implementation and more or less guess which parameters could be right.
The expert guesses, too. But an expert guess tends to be optimal. That's the
difference here. We are talking about a factor of 50-100 in the running time.
If you want to learn more about modern factoring methods I suggest you start by
reading Cohen's book "A course in computational algebraic number theory",
Springer, 1993.
According to the author of the problem, that factorization has also been
carried out at "some Dutch institute". Seems that would be someone at the CWI
in Amsterdam. Best wishes to this person.
Regards
Damian
------------------------------
From: David Broughton <[EMAIL PROTECTED]>
Subject: Re: md5 sample implementation
Date: Wed, 23 Dec 1998 10:31:00 +0000
In article <75osf0$[EMAIL PROTECTED]>, John L. Allen
<[EMAIL PROTECTED]> writes
>Below is a perl version for your perusal.
[snip]
>my ($aa, $bb, $cc, $dd) = (0x67452301, 0xefcdab89, 0x98badcfe, 0x10325476);
In this and other implementations you will notice that these
initialisation constants are nibble reversed compared to those given in
Bruce Schneier's book page 436. Also, the order of the four constants
has been cycled so that the first here is the fourth in the book. Has
anyone an explanation for this?
Ref: Bruce Schneier: Applied Cryptography, second edition, John Wiley &
Sons.
--
David Broughton Home Page: http://www.ddina.demon.co.uk/
PGP fingerprint = 1F 6B 80 8D 4C 4B 18 F4 D3 C2 97 EE 2B 6E 54 99
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: HELP! Who can decrypt this?
Date: Wed, 23 Dec 1998 12:12:44 GMT
On 23 Dec 1998 09:37:46 GMT, [EMAIL PROTECTED] (Damian Weber)
wrote:
>If you want to learn more about modern factoring methods I suggest you start by
>reading Cohen's book "A course in computational algebraic number theory",
>Springer, 1993.
>
If I may interject, although I agree that Cohen's text is excellent
(one of my favorites), it may not be the best place to start for a
'newbie'. Unless one has a good background in at least modern
algebra, it would be difficult to get past even the first few pages
(out of 500) of the book. An easier read might be Hans Riesel's
"Prime Numbers and Computer Methods for Factorization", Birkhauser.
It assumes less from the reader and contains appendices for all the
algebra that is needed.
Just my $.02.
Mike
Decrypt [EMAIL PROTECTED] with ROT13 for email address.
NOTICE TO BULK EMAILERS: Pursuant to US Code,
Title 47, Chapter 5, Subchapter II, 227, any
and all nonsolicited commercial E-mail sent to
this address is subject to a download and archival
fee in the amount of $500 US. E-mailing denotes
acceptance of these terms.
------------------------------
From: "Steve Sampson" <[EMAIL PROTECTED]>
Subject: Re: md5 sample implementation
Date: Wed, 23 Dec 1998 06:34:30 -0600
I notice that in the latest PGP, that MD5 is deprecated.
In the manual it explains that the MD5 hash was all but
broken in 1996 by a German cryptographer Hans Dobbertin.
Given that assertion, what is the continuing interest in it?
Steve
David Broughton wrote in message ...
>In article <75osf0$[EMAIL PROTECTED]>, John L. Allen
><[EMAIL PROTECTED]> writes
>>Below is a perl version for your perusal.
>[snip]
>>my ($aa, $bb, $cc, $dd) = (0x67452301, 0xefcdab89, 0x98badcfe,
0x10325476);
>In this and other implementations you will notice that these
>initialisation constants are nibble reversed compared to those given in
>Bruce Schneier's book page 436. Also, the order of the four constants
>has been cycled so that the first here is the fourth in the book. Has
>anyone an explanation for this?
------------------------------
From: "Steve Sampson" <[EMAIL PROTECTED]>
Subject: Re: Stego in jpeg files
Date: Wed, 23 Dec 1998 06:36:53 -0600
Why are you using two backslashes in the URL?
Have you ever gone to any web site using backslashes?
[EMAIL PROTECTED] wrote
>> The first public version of a DOS program to hide a file in a jpeg
>> file using techniques that obscure the hidden file from statistical
>> analysis is available for anyone who wants to try it.
>>
>> http:\\pweb.uunet.de/flexsys.mtk/jphs01.zip
>>
>> please try and let me have your comments.
>>
>> Allan Latham <|alatham| at |flexsys-group.com|>
>>
>
> My browser cannot find this URL. Please check it.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On living with the 56-bit key length restriction
Date: Wed, 23 Dec 1998 13:41:08 +0100
Mr. Tines wrote:
> > BTW, I am yet ignorant of whether it is without problems
> > in US to put a pure but strong crypto algorithm on the Web.
>
> Well, RFC 2144, which describes CAST5-128 is quite widely
> available; it took me no more than a couple of hours to start
> with the text and end up with a 'C' implementation that
> passed the test vectors included.
With good programming experience relatively fast implementation
of a good and precise description of an algorithm is indeed not
a big problem. This renders the sense of export restriction of
hardware/software without restriction of algoritm texts inherently
dubious. A conjecture that recently comes to my mind is that
probably (state) economic interests could be the real issues
behind the scene. Would someone like to correct me, if I err?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Encryption Basics
Date: Wed, 23 Dec 1998 11:01:21 GMT
In article <[EMAIL PROTECTED]>,
A C Wilshere <[EMAIL PROTECTED]> wrote:
> Sorry, yes I am using w95, and ScramDisk sounds like the main thing I
> am looking for.
>
> > You don't mention the OS you use. If it is Windows 95 / 98 then I recommend
> > ScramDisk, a disk container and partition encryptor.
>
> > It supports industry standard ciphers (blowfish, IDEA, 3DES etc) and is free
> > (with source code!). Anyway, the URL is in my SIG.
>
> All questions refer to scramdisk.
>
> FREE, sounds good already, especially to a Yorkshireman, (no, its not
> true that Yorkshiremen are tight) ;-)
<g>
>
> If I used either cd-r's or cd rw to store encrypted files, there
> would be a temporary folder (drive?) created on my hard drive to read
> the files yes/no
To use ScramDisk with a cd-r you need to:
i) Create a 650Mb SD container file on a hard drive and fill it full of the
files you wish to back to CD.
ii) Write this (huge!) container file to the CD.
Then you can mount the container file held on the CD as if it were stored on
the hard drive (apart from the fact that you can't write to the CD!).
> Must I create a partition especially for encryption purposes, or can
> I encrypt individual files/folders
You can create a small (e.g. as small as 1Mb if you desire) container file on
a normal drive (e.g. c:\).
> Can I still encrypt only SELECTED cds I write, (I do not have to
> encrypt every cd) yes/no
Yes.
>
> I notice that several Ciphers can be used, do these need to be
> downloaded separately to the Scramdisk program.
Nope - they are integral.
> Does this mean I can switch and change ciphers.
You can use different ciphers on different disks. You can't encrypt a single
disk with more than one cipher.
> Thanks for all your help so far
My pleasure!
>
> Allan
>
> PS Sorry about all the questions, I did an Open University course
> this year, and it covered the basics (VERY basic theory) of
> encryption as part of secure IT commerce and communications.
That's ok. I'd be glad to answer any more questions you may have,
Sam Simpson
Comms Analyst
-- http://www.hertreg.ac.uk/ss/ for ScramDisk hard-drive encryption & Delphi
Crypto Components. PGP Keys available at the same site.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On living with the 56-bit key length restriction
Date: Wed, 23 Dec 1998 14:11:32 +0100
[EMAIL PROTECTED] wrote:
>
> I don't think so. The main target of this law are neither countries nor
> well organised criminals. This law allows to control telecommunication:
> People have to use standard software if they want to stay in contact
> with others. This software is protected by different copyrights so it
> can't be changed without breaking laws. By keeping the huge companies
> from exporting strong crypto it is possible to keep people from
> encrypting the normal correspondence and to detect encrypted data
> streams.
Those who have no secrets to hide will not use cryptos. Hence 'normal'
correspondences do not contain stuffs interesting for the intercepting
guys. Those who do want to hide something certainly can afford to
take some inconvenience of first putting the messages through some
'private' cryptos before sending them on the public lines. As
I mentioned elsewhere, the 'real' intention of the Wassenaar agreement
appears not to be crystaline clear. A remark to your last point:
If encryption is not generally forbidden, detecting encrypted data
streams may not mean very much if decryption is not feasible.
>
> > BTW, I am yet ignorant of whether it is without problems
> > in US to put a pure but strong crypto algorithm on the Web.
> >
>
> Skipjack was published this way :)
That was by the government. I meant whether private persons have
the same privilege.
>
> > >
> > > 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.
> >
>
> Not only: You'll have to break or bend laws to reverse engineer
> commercial programs, but this may be neccessary to replace modules with
> undocumented interfaces. Many programs are testing libraries before
> using them, so it may be neccessary to break the self-test algorithms of
> these programs or to rewrite large partes of these programs.
>
> At least you'll have to replace copyright-protected parts of these
> programs.
>
> Because of that you'll have to decide either to use weak algorithms or
> to break laws.
>
> Again: This law doesn't stop criminals but it keeps others from
> protecting their data.
> It makes industrial espionage simpler and it allows to spy out people
> that don't want to break the laws.
Not at all. An analogy is to be found in UNIX, where you can pipe
almost anything to anything else. Each crypto module has input
format and output format. If two modules have the same formats,
there is nothing to be done! Now returning to your previous example
of voice encryption and with commercial modules which one preferably
shouldn't meddle with, on the assumption that the signal that
ultimately gets transmitted is digital one can certainly conveniently
insert two arbitrary chosen encryption modules, one on each side,
between the line and the voice encryption device.
> And the internet is an example that shows that the generation of
> channels is not only a problem of engineering but as well of the amount
> of money one is able to pay for the neccessary infrastructure.
>
> Most of our communication uses one of the networks - inernet, the
> networks of telecommunicatino companies and so on.
>
> I'm using only two or three lines for almost all of my telecommunication
> and I wouldn't be able to add another one that would allow me to reach
> most of my partners without spending too much time or money.
If you have really top secrets to be transmitted in time, I am
not sure that money definitely counts very much for you. Even if
you have only one single line, you can send the pieces at different
time points and also use the multiplexing technique that I mentioned
in the original post. Furthermore, the higher the secret, the lower
is likely to be the volume.
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
******************************
