Cryptography-Digest Digest #246, Volume #11 Fri, 3 Mar 00 14:13:01 EST
Contents:
Re: Best language for encryption?? (wtshaw)
Re: Best language for encryption?? (wtshaw)
Re: Best language for encryption?? (wtshaw)
Re: CRC-16 Reverse Algorithm ? (Scott Nelson)
Cellular automata based public key cryptography (Tim Tyler)
Re: Best language for encryption?? (wtshaw)
Re: Best language for encryption?? ("Brian Hetrick")
Re: Cryonics and cryptanalysis (Darren New)
Re: Cryonics and cryptanalysis (Darren New)
Re: New US export regs (was Re: Crypto.Com, Inc.) (wtshaw)
Re: Hidden computation (Re: Cryonics and cryptanalysis) (Mike Rosing)
Re: very tiny algorithm - any better than XOR? (Terry Ritter)
Re: IDEA question. (Chris DiTrani)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Best language for encryption??
Date: Fri, 03 Mar 2000 10:17:29 -0600
In article <89n2ju$np6$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Paul
Schlyter) wrote:
> In article <[EMAIL PROTECTED]>,
> wtshaw <[EMAIL PROTECTED]> wrote:
>
> >
> > No mention of these is in the literature I have on C/C++,
>
> Are you sure? Really sure? If so, your literature is bad and should
> be replaced.
When clear and conciseness is obvious, fine. It is not, so programming in
C/C++ remains art rather than science. I'll play along.
...
>
> > which makes my point...that there is too little standardization
> > in how the languages are fully used, as opposed to a set of commands
> > that are easily learned, at least by many who I have taught.
>
> I'm sorry, but these are deficiencies in the literature and/or the
> programmers -- not in the languages themselves!
>
Stroustrup omits it too.
--
Present Government Security is a sandcastle build on a beach
beside a lagoon at low tide. Figure that they will expense it all
before figuring out what is wrong with their planning personel.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Best language for encryption??
Date: Fri, 03 Mar 2000 10:38:44 -0600
In article <[EMAIL PROTECTED]>, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>
> Djikstra commented on this issue, claiming that people he encountered
(students)
> who learned languages like BASIC first were mentally damaged in that it
was very
> difficult for them to think certain ways. I'd be willing to bet the effect is
> measurable.
This could be that people trained to cut through the crap are unsettled
when they meet those that like to pile it on.
BASIC was developed before C. It was based largely on Fortran, rather an
offshoot of it. The difference is simply a single versus double
bookkeeping system of logic. People natively think in single entry. It
is more that lawyers and bureaucrats do double entry so that they can
check each others' work. Computers are generally dumb, so something like
Cobol works, but is uninspired when compared with mature languages.
Higher language compillers are more intelligent, to take some of the
burden away from programmers, find myrids of mistakes early, and guide
correction. Programming is not the end, it is the means, and the same for
computers and humans. Depending on compiler of any language, the code
produced can rival honed assembly.
This has lots to say about crypto, and the deficiency of thinking in
limited ways. It isthe big myth that we fight against, that things must
be difficult that are not inately required to be. Progress is doing away
with the innane.
Good algorithms are not that hard to fine, and good immplementations not
that hard to write if you think top-down and use the tools that get better
every day. The same goes for security matters in gneral. I am learning why
so many think otherwise; what a shame. The unwelcomed result of the
prevalence of how things are is that many live to cultivate problems
rather than using adequate solutions.
--
Present Government Security is a sandcastle build on a beach
beside a lagoon at low tide. Figure that they will expense it all
before figuring out what is wrong with their planning personel.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Best language for encryption??
Date: Fri, 03 Mar 2000 10:46:42 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
> I sure as heck hope you're not trying to "teach" C as you see it.
> C is *quite* well standardized, and how to use Standard C to
> program portably has also been quite fully developed.
Of course not, you are the authority there. I yield to your expertise,
but I am not afraid of analysing the philosophy and methods of lower
versus higher languages, or deficiencies of any.
Technology generally has outrun console programs as final product, and
people need not continue to walk when the can or need to fly.
--
Present Government Security is a sandcastle build on a beach
beside a lagoon at low tide. Figure that they will expense it all
before figuring out what is wrong with their planning personel.
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: CRC-16 Reverse Algorithm ?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 03 Mar 2000 17:42:23 GMT
On Thu, 02 Mar 2000, Paul Koning <[EMAIL PROTECTED]> wrote:
[snip]
>In addition, there's a burst length such that not all burst errors of
>that length are detected. For CRC-32 (again working from possibly
>faulty memory) I believe that length is 33 bits. Is it N+1 bits for
>any CRC-N?
>
If you feed all possible N bit values into an N bit crc,
(regardless of how it is initialized) you will get all possible
N bit values. It only takes a 32 bit error burst, not 33.
Also, any crc has a pattern which will not change
when fed a 1 bit. Therefore it is always possible
to construct a message 2N bits long which can be
extended indefinitely by inserting 1's after N bits,
without changing the CRC.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Cellular automata based public key cryptography
Reply-To: [EMAIL PROTECTED]
Date: Fri, 3 Mar 2000 17:36:38 GMT
I've recently developed an interest in public key cryptography based on
cellular automata.
This was pioneered in the 1980s by the Chinese cryptographer, Tao Renji.
I've compiled a bibliography of his work at http://alife.co.uk/ca/taorenji/
Since this work was largely published in Chinese - and is thus not
terribly accessible to me - I've redeveloped the basic ideas behind the
system.
A preliminary description of my explorations is available on the web.
The basic idea is a technique for generating reversible finite automata
whose inverses have domains that are unboundedly large.
This technique generates "quasi-linear" automata with "weak" inverses.
I describe this technique at http://alife.co.uk/ca/largeinverse/
This technique can be used as the basis of a public key cryptosystem:
The basic idea involves generating two finite invertable cellular automata.
At least one of the automata should contain a significant number of
non-linear components. The two automata are combined, to form a third
automata which is then published as the public key.
Combining the two automata is done by creating a third automata
which is equivalent to applying them in sequence. This is done by
algebraic combination, and expanding out the resulting terms.
To encrypt data, it is passed through the published automata.
To decrypt, the inverses of the two automata are applied in sequence.
This relies on the fact that finding the inverse of the public automata
- without knowledge of its components - is a difficult problem.
It can be difficult to decompose a composite automata into its component
parts - in very much the same way that it is difficult to factor the
product of two large primes.
http://alife.co.uk/ca/publickey/ describes the proposed process in
a little more detail.
I have not yet built any sort of system based on these ideas.
It appears that the resulting system should work /extremely/ rapidly when
implemented in appropriate hardware - but may have large keys.
I have not yet managed to read a single one of Tao Renji's papers, or
any of those cryptanalysing his system. /All/ my knowledge of his work
comes from the pages of "Applied Cryptography" (2nd ed. p.500) :-(
I am keen to learn more about the original work, so I can avoid
duplicating it, and to learn from previous exploration of the area.
If anyone can help me by providing me with details that I do not already
have access to, that would be very helpful. For example, if there are any
books in print containing any of the papers in my bibliography, I'd be
interested to learn about this.
I do not yet have much familiarity with other public key cryptosystems.
If there are other methods - which do not rely on large prime numbers,
the discrete logarithm problem, etc - and which might bear some possible
relationship to the system I describe - a pointer might be useful to me.
Any comments about the proposed system would also be welcomed.
Please don't advise me that my descriptions are currently vague and
incomplete, though - since I'm aware of that already.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Never call a man a fool. Instead, borrow from him.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Best language for encryption??
Date: Fri, 03 Mar 2000 11:00:38 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
> Which is why you find that you are out of stock on an item when it
> is critically needed.
>
> Lack of discipline is not something to be proud of in an engineering
> profession.
Anyone can outwardly showgood discipline if they have little to do.
It depends on the heirarchy of the needs. Premium treatment for those
able to pay is not the same as saving lives, but the former often competes
with the latter, both with routine. Having done lots of purchasing in my
years, and being on the supply side as well, I know the difference.
>
> > You just solved a problem I have been having in C, make it run
> > through a set of dummy values to get all the labels identifed...
> > what a crock, ...
>
> It certainly is a crock, but it's your fault for having a crappy
> program design. Instead of trying to write BASIC in C, you should
> learn to use C on its own merits. (Same for *any* language.)
One has to start somewhere, and I have not the time to waste if I can help it.
Meanwhile, I am just about to complete yet another pending project, but,
as Lubarsky's Rule of Cybernetic Entomology suggests, there is always one
more bug.
--
Present Government Security is a sandcastle build on a beach
beside a lagoon at low tide. Figure that they will expense it all
before figuring out what is wrong with their planning personel.
------------------------------
From: "Brian Hetrick" <[EMAIL PROTECTED]>
Subject: Re: Best language for encryption??
Date: Fri, 3 Mar 2000 13:04:48 -0500
It occurs to me there is much smoke and heat, and little light, in this
discussion; and it occurs to me we have different ideas of what "Basic" is.
The people suggesting Basic as a "structured" language are not talking about
DTSS Basic, or Apple ][ Basic, or even BASICA. They are talking about
current Basics -- where, for example, you cannot GOTO into the middle of a
subroutine because the subroutine has a different lexical scope.
Firstly, I like C. C in a wonderful language. I use it all the time. I've
written compilers for it, and it's nifty.
I also like Basic. Basic is a wonderful language. I use it all the time.
I've written compilers for it, and it's nifty.
Attached is a "typical" module in a "modern" Basic. It is a class that
implements a doubly linked list of objects. The major difference (besides
syntax, of course) between this and the equivalent abstract data type in C
is that it is more convenient to use values, rather than references, in
Basic for everything other than objects. So while a typical generic list in
C would use pointers to the things of interest, a typical generic list in
Basic uses values and the polymorphic scalar type for everything except
classes, and references rather than values for classes. Hence the checks
for whether things are objects and the use of 'set' rather than (implicit)
'let' for objects....
Oh, and divisions between routines/methods are supplied by the IDE, so form
feeds and such aren't used here.
=====
Option Explicit
Private litFirstItem As ListItem
Private litLastItem As ListItem
Private intCount As Integer
Private Sub Class_Initialize()
Set litFirstItem = Nothing
Set litLastItem = Nothing
intCount = 0
End Sub
Private Sub Class_Terminate()
Clear
End Sub
Public Sub Clear()
Dim varThisItem As Variant
Do
If Count = 0 Then
Exit Do
End If
If HeadIsObject Then
Set varThisItem = PopHead
Else
varThisItem = PopHead
End If
varThisItem = Empty
Loop
End Sub
Public Function PopHead() As Variant
Dim litThisItem As ListItem
If litFirstItem Is Nothing Then
PopHead = Empty
Exit Function
End If
Set litThisItem = litFirstItem
Set litFirstItem = litThisItem.NextItem
If litFirstItem Is Nothing Then
Set litLastItem = Nothing
Else
Set litFirstItem.PrevItem = Nothing
End If
intCount = intCount - 1
If litThisItem.ValueIsObject Then
Set PopHead = litThisItem.Value
Else
PopHead = litThisItem.Value
End If
Set litThisItem = Nothing
End Function
Public Function PopTail() As Variant
Dim litThisItem As ListItem
If litLastItem Is Nothing Then
PopTail = Empty
Exit Function
End If
Set litThisItem = litLastItem
Set litLastItem = litThisItem.PrevItem
If litLastItem Is Nothing Then
Set litFirstItem = Nothing
Else
Set litLastItem.NextItem = Nothing
End If
intCount = intCount - 1
If litThisItem.ValueIsObject Then
Set PopHead = litThisItem.Value
Else
PopHead = litThisItem.Value
End If
Set litThisItem = Nothing
End Function
Public Sub InsertHead(ByVal varNewValue As Variant)
Dim litThisItem As ListItem
Set litThisItem = New ListItem
If IsObject(varNewValue) Then
Set litThisItem.Value = varNewValue
Else
litThisItem.Value = varNewValue
End If
Set litThisItem.NextItem = litFirstItem
If litFirstItem Is Nothing Then
Set litLastItem = litThisItem
Else
Set litFirstItem.PrevItem = litThisItem
End If
Set litFirstItem = litThisItem
intCount = intCount + 1
End Sub
Public Sub InsertOrder(ByVal varNewValue As Variant)
Dim litThisItem As ListItem
Dim litPrevItem As ListItem
Dim litNextItem As ListItem
Dim blnAdvance As Boolean
Set litThisItem = New ListItem
If IsObject(varNewValue) Then
Set litThisItem.Value = varNewValue
Else
litThisItem.Value = varNewValue
End If
Set litPrevItem = Nothing
Set litNextItem = litFirstItem
Do
If litNextItem Is Nothing Then
Exit Do
End If
blnAdvance = False
On Error Resume Next
blnAdvance = litThisItem.Value > litNextItem.Value
On Error GoTo 0
If Not blnAdvance Then
Exit Do
End If
Set litPrevItem = litNextItem
Set litNextItem = litNextItem.NextItem
Loop
If litPrevItem Is Nothing Then
Set litFirstItem = litThisItem
Else
Set litPrevItem.NextItem = litThisItem
End If
If litNextItem Is Nothing Then
Set litLastItem = litThisItem
Else
Set litNextItem.PrevItem = litThisItem
End If
Set litThisItem.PrevItem = litPrevItem
Set litThisItem.NextItem = litNextItem
intCount = intCount + 1
End Sub
Public Sub InsertTail(ByVal varNewValue As Variant)
Dim litThisItem As ListItem
Set litThisItem = New ListItem
If IsObject(varNewValue) Then
Set litThisItem.Value = varNewValue
Else
litThisItem.Value = varNewValue
End If
Set litThisItem.PrevItem = litLastItem
If litLastItem Is Nothing Then
Set litFirstItem = litThisItem
Else
Set litLastItem.NextItem = litThisItem
End If
Set litLastItem = litThisItem
intCount = intCount + 1
End Sub
Public Property Get Count() As Integer
Count = intCount
End Property
Public Property Get Head() As Variant
If litFirstItem Is Nothing Then
Head = Empty
Else
If litFirstItem.ValueIsObject Then
Set Head = litFirstItem.Value
Else
Head = litFirstItem.Value
End If
End If
End Property
Public Property Get HeadIsObject() As Boolean
If litFirstItem Is Nothing Then
HeadIsObject = False
Else
HeadIsObject = litFirstItem.ValueIsObject
End If
End Property
Public Property Get Tail() As Variant
If litLastItem Is Nothing Then
Head = Empty
Else
If litLastItem.ValueIsObject Then
Set Head = litLastItem.Value
Else
Head = litLastItem.Value
End If
End If
End Property
Public Property Get TailIsObject() As Boolean
If litLastItem Is Nothing Then
TailIsObject = False
Else
TailIsObject = litLastItem.ValueIsObject
End If
End Property
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Cryonics and cryptanalysis
Date: Fri, 03 Mar 2000 18:11:11 GMT
Ralph C. Merkle wrote:
> But can people be described by bits? In the past several years, quite a
> few authors have pointed out that a sufficiently precise description of
> a human being -- a description in bits -- provides a "snapshot" of that
> human being at a specific point in time. Given the "snapshot," we could
> in principal restore the human being.
Well, Penrose points out that there are quantum structures in the brain
which he believes are necessary to concious thought. Regardless of whether
you agree with him, there is the question of whether quantum states of the
atoms making up the human are necessary to the continued existance of that
person as the same person. If so, you'd be unable to record that
information, and anyone you managed to wake up would be someone else.
--
Darren New / Senior MTS / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
There is no safety in disarming only the fearful.
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Cryonics and cryptanalysis
Date: Fri, 03 Mar 2000 18:14:21 GMT
Trevor Jackson, III wrote:
> Niven assumed that making a copy was destructive of the original
Actually, there's an interesting story called "The Man on the Moon Must
Die". (I don't remember the author, tho.) They have teleportation (for rich
folks at least), and someone tries to murder said rich dude by disabling the
part of the transmitter that destroys the original after the copy has been
transmitted. Of course, the law is such that this makes the original a
shoot-on-sight non-person.
An interesting twist to it. Completely off-topic for sci.crypt, tho. Sorry.
--
Darren New / Senior MTS / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
There is no safety in disarming only the fearful.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: New US export regs (was Re: Crypto.Com, Inc.)
Date: Fri, 03 Mar 2000 11:29:58 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> You don't need them to send email to you:
>
If yo are requested to send them something, it is comforting to know that
a communication was actually received. I guess I remember the chronic
loss of AOL mail experienced here long ago. But, anything can happen
enroute.
Figure that if they say they did not receive it, they have no reason to
complain. Perhaps the dog ate it, I forgot to send it, I thought I sent
it, or my program did not work right, or they just lost it themselves. It
must not be a big deal anyway, so why bother in the first place?
--
Present Government Security is a sandcastle build on a beach
beside a lagoon at low tide. Figure that they will expense it all
before figuring out what is wrong with their planning personel.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Hidden computation (Re: Cryonics and cryptanalysis)
Date: Fri, 03 Mar 2000 12:33:21 -0600
Kim G. S. OEyhus wrote:
> Cryptography can protect information in transmission, but here the
> problem is to protect information when the storage device is
> accessible and contains plaintext, i.e. memories in a frozen brain.
>
> So, my question is: Is it possible to do computation where data is
> encrypted on all stages, all the time? Say, an encrypted
> universal Turing machine?
You can perform operations on encrypted data, but you'll lose the
mapping to the original data. If you have an encryption form
which satisfies T(E(d)) = E(T(d)) then it will work (E is encryption,
T is turing operation). Most systems don't work that way.
> What I am thinking about, is a computer doing computations, but where
> it is not possible to understand what the computation does, unless one
> decrypts it. Is this possible at all? If so, how efficient can it be
> done?
Sounds like neuroscience to me :-) We have no idea how our brains work,
but we have no problem making them work. In a few hundred years we
may have decrypted most of it tho.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: very tiny algorithm - any better than XOR?
Date: Fri, 03 Mar 2000 18:57:38 GMT
On Fri, 03 Mar 2000 12:06:13 GMT, in <89o9rk$9vo$[EMAIL PROTECTED]>, in
sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
>[...]
>You should look up LFSR and Lagged Fibonacii generators. If you have
>some ram space [around 300 bytes] you could do AlgM :).
Of course that would be insecure.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Chris DiTrani)
Subject: Re: IDEA question.
Date: Fri, 03 Mar 2000 17:58:54 GMT
Yeah, this is pretty obvious, isn't it. It occured to me shortly after
posting here.
CD
On Thu, 2 Mar 2000 18:04:45 -0500, "Brian Sipos" <[EMAIL PROTECTED]>
wrote:
>You could use a hash of the unencrypted file as the known block, so that it wouldn't
>be a static number.
>
>Chris DiTrani <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> I wrote a little utility to en/decrypt files using IDEA, building the
>> encryption key from a user provided pass phrase. In order to confirm
>> that a file is being decrypted with the correct pass phrase, I encrypt
>> a block containing known (but not secret) data and append it to the
>> file before encrypting the file (so this block is encrypted twice). I
>> can look at the block after decrypting the file to confirm (to some
>> certainty). My question is, am I appreciably weakening the encryption
>> with this approach? Is there a better way?
>>
>> Thanks,
>>
>> CD
>
>
------------------------------
** 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
******************************
