Cryptography-Digest Digest #237, Volume #12 Mon, 17 Jul 00 14:13:00 EDT
Contents:
Re: mirror bit !! (Mark Wooding)
Re: Difference between A5/1 and A5/2 ([EMAIL PROTECTED])
Overview of different padding schemes (Niko Schweitzer)
Re: RC5 Question (Runu Knips)
Re: what is the symmetric algorithm for protection of classified info by (Runu
Knips)
Re: RC5 Question (Casper H.S. Dik - Network Security Engineer)
Re: SECURITY CLEAN freeware text editor in win95 ? (Richard Herring)
Re: Quantum Computing (Was: Newbie question about factoring) ("Tony T. Warnock")
Re: Questions!!!! (Vladimir Castro Alves)
Re: stes-0.0.0 released (was: Steganographic encryption system) (Paul Martin)
Re: Skipjack source in C (stanislav shalunov)
News about quantum computer (Mok-Kong Shen)
Re: RC5 Question (phil hunt)
Re: a file security proposal (Michael Gu)
Re: RC5 Question (Jeffrey Williams)
Re: Has RSADSI Lost their mind? (Paul Koning)
Re: Has RSADSI Lost their mind? (Paul Koning)
Re: Win2000 Encryption (Paul Koning)
Re: stes-0.0.0 released (was: Steganographic encryption system) (phil hunt)
Re: Bit Shuffling ("Paul Pires")
Re: stes-0.0.0 released (was: Steganographic encryption system) ("Trevor L. Jackson,
III")
Re: Bit Shuffling (John Myre)
Re: a file security proposal ([EMAIL PROTECTED])
Re: Bit Shuffling (Jayant Shukla)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: mirror bit !!
Date: 17 Jul 2000 12:30:50 GMT
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
[M. K. Shen's `mirror' operation]
> could you give me some example please with 32 bit number !!!
OK. The integers 2329946913 and 2228488017 are mirrors (level 1) of
each other.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Difference between A5/1 and A5/2
Date: Mon, 17 Jul 2000 12:35:35 GMT
In article <[EMAIL PROTECTED]>,
Michael Schmidt <[EMAIL PROTECTED]> wrote:
> Hi,
>
> The source code of both A5/1 and A5/2 is available at
> http://cryptome.org/gsm-a512.htm.
> Furthermore, http://www.scard.org/gsm contains info about A5/1.
>
> I hope this helps,
The first link leads to a broken page (at least when you select "yes"
to all the yank-wank questions).
try changing the URL to:
http://cryptography.org/pub/crypto/GfDSe3Xb/Misc/
and you'll find a5 in there.
Gary
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Mon, 17 Jul 2000 14:56:56 +0200
From: Niko Schweitzer <[EMAIL PROTECTED]>
Subject: Overview of different padding schemes
Hello.
I'm looking for an overview of different padding schemes/ standards.
Especially I would like a description of the padding defined in X 9.23,
ISO 10126 respectively.
Could anybody help?
Kind regards,
Niko
------------------------------
Date: Mon, 17 Jul 2000 15:15:41 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: RC5 Question
Brian Patterson wrote:
> What exactly is a "u4" datatype?
>From the context I would say it has to be an unsigned
32 bit integer. Traditionally, one defines this to be
unsigned long, however this wouldn't work on modern
64 bit cpu's where long is 64 bit, therefore I would
suggest:
typedef unsigned int u4;
------------------------------
Date: Mon, 17 Jul 2000 15:28:07 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: Re: what is the symmetric algorithm for protection of classified info by
jungle wrote:
> which is paraphrase of "I don't know." ?
Which is a paraphrase of "Those which know won't tell you".
------------------------------
From: [EMAIL PROTECTED] (Casper H.S. Dik - Network Security Engineer)
Subject: Re: RC5 Question
Date: 17 Jul 2000 14:10:27 GMT
[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]
Runu Knips <[EMAIL PROTECTED]> writes:
>Brian Patterson wrote:
>> What exactly is a "u4" datatype?
>From the context I would say it has to be an unsigned
>32 bit integer. Traditionally, one defines this to be
>unsigned long, however this wouldn't work on modern
>64 bit cpu's where long is 64 bit, therefore I would
>suggest:
>typedef unsigned int u4;
Or, perhaps more typical these days:
#include <inttypes.h>
typedef uint32_t u4;
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Crossposted-To: alt.privacy
Subject: Re: SECURITY CLEAN freeware text editor in win95 ?
Date: 17 Jul 2000 14:14:09 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Richard Heathfield
([EMAIL PROTECTED]) wrote:
> jungle wrote:
> >
> > most of the programs are very smelly & dirty ...
> >
> > any help for freeware in win95 :
> > SECURITY CLEAN text editor [ like NOTEPAD ] that can be used to edit
> > up to 1 MB files ?
> >
> > SECURITY CLEAN =
> > - no temp files
> > [ permanent or / and intermittent = deleted after program closed ]
> > - no entries in registry
> > - no windows folder messing
> vi -n foo.txt
> vi can easily edit files larger than 1MB.
> The -n switch says "don't use a swap file" - of course, recovery after a
> crash will be impossible, but then crashing vi is quite difficult.
> Since Linux doesn't have a registry, vi puts no entries there.
> vi doesn't mess with the Windows folder, not least because there isn't a
> Windows folder on a Linux system.
> So vi would appear to meet all your requirements. Happy hacking.
> Oh! You said win95. Sorry, just saw that now. Hmm - if you're so
> concerned about security that you are worried about temporary files
> being used by an editor while you're editing with it, I think you might
> want to reconsider your choice of operating system.
The Windows NT Workstation Resource Kit contains two different
implementations of vi-for-windows, one or both of which might
run under 95. I don't know how security-clean they might be.
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Crossposted-To: comp.theory
Subject: Re: Quantum Computing (Was: Newbie question about factoring)
Date: Mon, 17 Jul 2000 08:42:09 -0600
Reply-To: [EMAIL PROTECTED]
Jeffrey Shallit wrote:
> In article <8kg1gj$5mk$[EMAIL PROTECTED]>,
> Nick Maclaren <[EMAIL PROTECTED]> wrote:
> >In article <[EMAIL PROTECTED]>,
> >Tony T. Warnock <[EMAIL PROTECTED]> wrote:
> >>
> >>That's true. I was basing my comment on the article by van der Poorten and
> >>Loxton in Crelle's Journal vol 392, p57, that (purported, there may be an
> >>error) that the bits of an algebraic number can not be generated by a finite
> >>state machine. Bit strings generated by finite state machines must be either
> >>rational or transcendental.
> >
> >Well, as it stands, that statement is clearly false! As finite state
> >machines necessarily repeat, they can generate only rational numbers.
> >And, obviously, they can generate any rational number.
> >
> >
> >Regards,
> >Nick Maclaren,
> >University of Cambridge Computing Service,
> >New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
> >Email: [EMAIL PROTECTED]
> >Tel.: +44 1223 334761 Fax: +44 1223 334679
>
> Well, unfortunately, you're both wrong.
>
> Maclaren is wrong because he misunderstands the model used to generate
> real numbers with a finite automaton that Warnock is referring to. In this
> model, the finite automaton is equipped with an output function for each
> state, say from Q (the state set) to {0, 1, ..., b-1} for some integer
> b >= 2. We say such a machine generates the real number
> . a_0 a_1 a_2 ... in base b
> if, when fed with the base-k expansion of i, the machine reaches a state
> q whose output is a_i.
>
> Under this model, it is easy to create finite automata to generate
> transcendental numbers. For example, a 2-state machine can
> generate the Thue-Morse real number
> .0110100110010110 ...
> whose i'th bit is the sum (mod 2) of the bits in the binary expansion of i.
> This number is known to be transcendental; Dekking proved this some
> time ago (although his published proof has an flaw that can be repaired).
>
> And Warnock is wrong because the van der Poorten-Loxton "proof" that all
> such numbers are either rational or transcendental has a flaw in it that
> no one has yet been able to repair. Van der Poorten acknowledged this at
> a conference at Penn State a couple of years ago.
>
> Partial results are known; in particular Allouche and Zamboni have
> proved the "either rational or transcendental" result for binary
> alphabets. (For exact details see their 1998 paper in Journal of
> Number Theory.)
>
> Jeffrey Shallit, Computer Science, University of Waterloo,
> Waterloo, Ontario N2L 3G1 Canada [EMAIL PROTECTED]
> URL = http://www.math.uwaterloo.ca/~shallit/
I did note the possibility of error. See above.
------------------------------
From: Vladimir Castro Alves <[EMAIL PROTECTED]>
Subject: Re: Questions!!!!
Date: Mon, 17 Jul 2000 16:57:15 +0200
Hi,
I found your answer interesting.
Do you think that key dependent S-boxes can improve the robustness
of a given Feistel network ? Why?
Thanks,
Vladimir
> > 4) Do the key-dependant S-boxes and the key-dependant subkeys in
> > Blowfish interact in any way to weaken the cipher or reduce it's
> > bijectivity?
>
> There's no risk to Blowfish's bijectivity: its (almost) Feistel
> structure guarantees this. And I can't see any particular problem with
> the cipher's strength cuased by the similar way in which the round keys
> and S-boxes are generated.
>
> Blowfish's key schedule is an interesting (if heavyweight) way of
> ensuring that each of the round keys (and S-box entries) depends
> strongly on all of the input user key.
>
> Note that the limitation of the user key to 448 bits, rather than the
> perhaps more intuitively obvious 512 bits: this is because, if you have
> a key that long, P[2] and P[3] will not depend on P[0] and P[1].
>
> I've not done an analysis of Blowfish with the default S-boxes. The
> mixing of the S-box outputs is slightly nonlinear; I suspect that the
> main worry will be the least significant bits of the output, which are a
> linear combination of the least significant bits of the S-box outputs.
> I suspect that the default S-boxes won't be bad enough to allow an
> analysis of this type to derive information about the final S-boxes.
>
> > Thanks for any answers,
>
> I hope I've been helpful.
>
> Can you ask easy questions next time, please? ;-)
>
> -- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Paul Martin)
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: stes-0.0.0 released (was: Steganographic encryption system)
Date: 17 Jul 2000 15:21:12 GMT
In article <[EMAIL PROTECTED]>,
phil hunt wrote:
>This is a highly unfinished version, as the version number suggests: it
>encrypts but it doesn't decrypt. I've included a README file which explains
>how it works.
I remember a certain relativistic compression program, over ten years
ago, which compressed any file to a single bit, or singularity. No
decompression program existed.
--
Paul Martin <[EMAIL PROTECTED]>
at home, swap dash to dot to email.
------------------------------
From: stanislav shalunov <[EMAIL PROTECTED]>
Subject: Re: Skipjack source in C
Date: 17 Jul 2000 11:17:47 -0400
Chem-R-Us <[EMAIL PROTECTED]> writes:
> Anybody got a link to Skipjack in C?
ftp://ftp.funet.fi/pub/crypt/cryptography/symmetric/skipjack/
Search engines are your friends. (There are, supposedly, better
optimized versions, but Skipjack is optimized for hardware anyway.)
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: News about quantum computer
Date: Mon, 17 Jul 2000 17:45:24 +0200
The German newspaper Computer Zeitung reported in its 13 July
issue that a team consisting of US and German researchers
has succeeded to synthesize a molecule that can store 5 qubits,
while the best previous result was 3 qubits.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Subject: Re: RC5 Question
Date: Mon, 17 Jul 2000 16:06:57 +0100
Reply-To: [EMAIL PROTECTED]
On 17 Jul 2000 14:10:27 GMT, Casper H.S. Dik - Network Security Engineer
<[EMAIL PROTECTED]> wrote:
>>typedef unsigned int u4;
>
>Or, perhaps more typical these days:
>
>
>#include <inttypes.h>
>
>typedef uint32_t u4;
Is this standard C/C++ now?
--
***** Phil Hunt ***** send email to [EMAIL PROTECTED] *****
Moore's Law: hardware speed doubles every 18 months
Gates' Law: software speed halves every 18 months
------------------------------
From: Michael Gu <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.system,comp.os.linux.security
Subject: Re: a file security proposal
Date: Mon, 17 Jul 2000 15:44:24 GMT
Colin Smith wrote:
> On Sun, 16 Jul 2000 01:08:05 +0100, phil hunt <[EMAIL PROTECTED]> wrote:
> >On Sat, 15 Jul 2000 19:38:49 GMT, Michael Gu <[EMAIL PROTECTED]> wrote:
> >>If this has already been done, please ignore this message.
> >
> >It has been done. There's a system that does this for Windows 95, &
> >which is now being poerted to Linux.
> >
> >>I suggest to add file encryption capability to the system ( kernal, or
> >>whatever ). The general idea I have is following:
> >>
> >> 1. system distinguish whether a file is encrypted or not
> >> 2. when access an encrypted file, system will get the key by some
> >>means. e.g. prompt for a password, read user config file ...
>
> Linux already has an encrypted file system. Search for cryptfs.
>
It seems to be a filesystem encryption program. I doubt it will offer user-level or
file-level encryption, that is, individual user choose their own key or choose
different keys for different files.
>
> [snip]
>
> --
> |Colin Smith: [EMAIL PROTECTED] | Windows 2000 |
> | 86% of Americans support the banning | AKA |
> |of Dihydrogen monoxide... Where do you stand??? | The W2K Bug |
------------------------------
From: Jeffrey Williams <[EMAIL PROTECTED]>
Subject: Re: RC5 Question
Date: Mon, 17 Jul 2000 11:00:17 -0500
Well, you want to be carefull about that. Much depends upon your
compiler, your OS, and the phase of the moon (well, you can skip the
phase of the moon, mostly).
C does not explicitely define the size of it datatypes. This makes
assumptions about size as dangerous as all get out. If you want to port
your code to another machine, or another OS, you'll need to check things
out. Using a typedef would be a very good idea. That way, you'd only
need to change the typedef when porting to a non-compatible system.
For once, a question about which I truly know something. Go figure.
Jeff
Runu Knips wrote:
> Brian Patterson wrote:
> > What exactly is a "u4" datatype?
>
> From the context I would say it has to be an unsigned
> 32 bit integer. Traditionally, one defines this to be
> unsigned long, however this wouldn't work on modern
> 64 bit cpu's where long is 64 bit, therefore I would
> suggest:
>
> typedef unsigned int u4;
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Has RSADSI Lost their mind?
Date: Mon, 17 Jul 2000 11:08:25 -0400
Bill Unruh wrote:
>
> That letter is incredible. Absolutely everything there sounds like
> algorithms, which cannot be patented.
What country are you speaking of? Certainly that isn't correct
in case of the USA...
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Has RSADSI Lost their mind?
Date: Mon, 17 Jul 2000 11:09:05 -0400
Mack wrote:
>
> The original DH patent used knapsack didn't it?
No, that's the original public key algorithm you're
thinking about.
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Win2000 Encryption
Date: Mon, 17 Jul 2000 11:13:17 -0400
> >>Have you tried booting from linux or some other OS and accessing
> >>the same file? Possibly with a disk editor from DOS?
> >
> > Don't try to use linux to access the drive. Linux doesn't
> >handle NTFS very well. I believe it reads NT4's file system
> >without many errors. However any writes to win2000 or NT4's file systems
> >WILL corrupt the filesystem enough that nt or win2000 probably
> >won't be able to mount the filesystem.
The ntfs implementation I've found in Linux (2.3 and 2.4 kernels)
explicitly checks for win2k and refuses to write that version
of ntfs. Don't know why. Actually, the checks aren't complete;
it is willing to do a chmod. But it won't create or write files.
paul
--
!-----------------------------------------------------------------------
! Paul Koning, NI1D, D-20853
! Lucent Corporation, 50 Nagog Park, Acton, MA 01720, USA
! phone: +1 978 263 0060 ext 115, fax: +1 978 263 8386
! email: [EMAIL PROTECTED]
! Pgp: 27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "A system of licensing and registration is the perfect device to deny
! gun ownership to the bourgeoisie."
! -- Vladimir Ilyich Lenin
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: stes-0.0.0 released (was: Steganographic encryption system)
Date: Mon, 17 Jul 2000 17:35:30 +0100
Reply-To: [EMAIL PROTECTED]
On 17 Jul 2000 15:21:12 GMT, Paul Martin <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> phil hunt wrote:
>
>>This is a highly unfinished version, as the version number suggests: it
>>encrypts but it doesn't decrypt. I've included a README file which explains
>>how it works.
>
>I remember a certain relativistic compression program, over ten years
>ago, which compressed any file to a single bit, or singularity. No
>decompression program existed.
:-)
The decryption program will be written in a few days time.
--
***** Phil Hunt ***** send email to [EMAIL PROTECTED] *****
Moore's Law: hardware speed doubles every 18 months
Gates' Law: software speed halves every 18 months
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Bit Shuffling
Date: Mon, 17 Jul 2000 09:47:19 -0700
The "Bandwidth" of the US PTO is putrid. If it was filed in mid 98, I
wouldn't expect to see anything until late 2000 IF it flew perfectly with no
pesky office actions to deal with. If it is a US application you will see
nothing unless and until it is granted. It is held in secret until then.
Paul
Adam Durana <[EMAIL PROTECTED]> wrote in message
news:8krc95$89b$[EMAIL PROTECTED]...
> Oddly enough I found no patents or patents pending for 'bit shuffling'
> or ones filed by Shukla for something along the lines of 'bit
> shuffling' in 1998, 1999, or 2000.
>
> - Adam
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
Date: Mon, 17 Jul 2000 13:21:21 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: stes-0.0.0 released (was: Steganographic encryption system)
Paul Martin wrote:
> In article <[EMAIL PROTECTED]>,
> phil hunt wrote:
>
> >This is a highly unfinished version, as the version number suggests: it
> >encrypts but it doesn't decrypt. I've included a README file which explains
> >how it works.
>
> I remember a certain relativistic compression program, over ten years
> ago, which compressed any file to a single bit, or singularity. No
> decompression program existed.
Was it necessary to accelerate the computer to near the speed of light or would
the algorithm work on a newtonian computer?
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Bit Shuffling
Date: Mon, 17 Jul 2000 11:14:06 -0600
Paul Pires wrote:
>
> The "Bandwidth" of the US PTO is putrid. If it was filed in mid 98, I
> wouldn't expect to see anything until late 2000 IF it flew perfectly with no
> pesky office actions to deal with.
I'd call that "response time" rather than "bandwidth".
:)
JM
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: a file security proposal
Crossposted-To: comp.os.linux.development.system,comp.os.linux.security
Date: Mon, 17 Jul 2000 17:33:51 GMT
In comp.os.linux.development.system Michael Gu <[EMAIL PROTECTED]>
wrote:
> It seems to be a filesystem encryption program. I doubt it will offer
> user-level or file-level encryption, that is, individual user choose
> their own key or choose different keys for different files.
I would guess that's mainly because, for most people, either loopback
encryption (www.kerneli.org) or an application such as gpg meet their
needs.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Jayant Shukla)
Subject: Re: Bit Shuffling
Date: 17 Jul 2000 17:34:56 GMT
[EMAIL PROTECTED] (Mark Wooding) writes:
>The main problem with bit permutations is that they can do nothing with
>single active bits except move them around. Thus, the best differential
>or linear hull for a cipher may take in only a single active S-box per
>round.
You are assuming that there is only one round and a single operation
(bit shuffle) used in the cipher. I'll grant that your conclusions
are correct in that case. How many ciphers you know have only one
round and use only one mathematical operation in each round? Can
you support your arguement if this function is used with a data
dependent non-linear operation and the cipher has more than one
round?
>Constructing ciphers which are based around bit permutations as the main
>diffusion element is extremely hard, requiring a great deal of care in
>the design of the permutations and nonlinear elements and the way in
Constructing ciphers based on bit-permutation is inefficient. Designing
any cipher is hard and requires a great deal of care. The main point
was to introduce a way to shuffle bits that is efficient and does not
take up a lot of clock cycles or silicon area.
>which they interact. MDS matrices and PHT networks (e.g., in Rijndael
>and SAFER) are both more effective in increasing the number of active
^^^^^^
>components per round and easier to use in new designs.
How do you know that? Any references? I have looked up the
papers on Rijndael, TwoFish, and SAFER, and the authors
do not claim any such thing.
>This is beside the fact that the usual way to implement bit permutations
>is to combine them with S-boxes in big tables, making the permutation
>free.
Words fail me here! The whole point of using this shuffle is that you
not have to rely on look up tables. Look up tables are expensive.
If you implement 128 bit shuffle using look up table, you are toast.
Please do read the previous thread started by Mok-Kong to get
a better picture of why this might be important.
regards,
Jayant
------------------------------
** 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
******************************
