Cryptography-Digest Digest #256, Volume #11 Sun, 5 Mar 00 03:13:02 EST
Contents:
Re: Explaination of method question (Nemo psj)
Re: Decompiling/Tamper Resistent (Dave Hazelwood)
THE CIA ... please deport me ... or FBI/NSA or any of people ... please, ("Markku
J. Saarelainen")
In the information security field there are people who can handle the ("Markku J.
Saarelainen")
Re: Large interger package for VB? ("Scott Sherer")
Re: Best language for encryption?? (wtshaw)
Re: Best language for encryption?? (wtshaw)
Re: On jamming interception networks ("Douglas A. Gwyn")
Re: Can someone break this cipher? ("Douglas A. Gwyn")
Re: Best language for encryption?? ("Douglas A. Gwyn")
Re: Crypto.Com, Inc. ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Nemo psj)
Subject: Re: Explaination of method question
Date: 05 Mar 2000 04:27:16 GMT
I'm curious as to why you would like me to explain it in these ways <<Could you
please reformulate the entire algorithm in terms of either cyclic
decomposition of permutations, or integer addition modulo 256 and integer
addition modulo 2.>> I thaught the explaination was pretty straight forward.
I will in any case do my best to explain it for you and post it in a few days
but i'd still like to know why..
-Pure
------------------------------
From: Dave Hazelwood <[EMAIL PROTECTED]>
Subject: Re: Decompiling/Tamper Resistent
Date: Sun, 05 Mar 2000 07:54:23 +0800
So what are you saying?
Here is the source code and oh by the way trust me that
that is whats really inside the device because you can't
verify it?
[EMAIL PROTECTED] wrote:
>In article <[EMAIL PROTECTED]>,
> Andru Luvisi <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] writes:
>> > I am refering to your post and the above poster. It appears that
>you
>> > dont have a clue of real crypto systems. Have you heard of FIPS-140
>> > levels 1-4. Most crypto manufacturers have a
>> > tamper-resistent/tamper-proof module (for keys and programs). This
>is
>> > not to stop customers having access to the source code...customers
>dont
>> > go snooping around bits of hardware and disassembling code.. There
>is
>> > an easier way of getting the source code.. You just ask...Isnt that
>> > simple..
>>
>> Your original post refered to protecting your intellectual property
>> from "decompiling freaks". Decompiling is a way to get the source
>> code, hence it sure *seems* like you wanted a way to keep the workings
>> of your system secret. Are you now claiming that you only want a way
>> to keep keys secret?
>
>No..I have explained that in detail. But I will explain it again for
>you. The issue is not keeping the internals of the system secret from
>customers or potential customers. Any customer who is serious about our
>systems can view the source code and the algorithnms....
>
>What we want to do is keep our stuff out of the hands of copycats...and
>I think this is something that is perfectly ligit....As I said
>before..no customer is going to go to the length of decompiling
>code..they just need to ask for it...and any credible crypto person is
>also welcome to review our code...its all open...I hope I made this
>clear...
>
>Please visit NCipher....and other hardware crypto vendors...not only do
>they keep their keys in tamper resistant boxes...but also their
>softwrare...
>
>
>Samuel Paik in his post got it right....some chip makers offer tamper
>resistent EEPROMS and System on a chip precisely for this reason...
>
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
------------------------------
From: "Markku J. Saarelainen" <[EMAIL PROTECTED]>
Crossposted-To:
alt.politics.org.cia,soc.culture.nordic,soc.culture.russian,soc.culture.soviet
Subject: THE CIA ... please deport me ... or FBI/NSA or any of people ... please,
Date: Sun, 05 Mar 2000 05:59:45 GMT
THE CIA ... please deport me ... or FBI/NSA or any of people ...
please deport me and replace me .. you can find some Mexican street drug
runners or some other people .... I have been tired of being in the USA
for years and I do not want to stay here .... I am on my way to
Vladivostok as I planned in 1990 and I have already been going there
since 1990 or so .... it is my train .. your train is HUUHAA (and a
person C2 discussed this HUUHAA train with a person B4 .. :) HAHAHAHAHA
) that was captured by my train .. my train is the LOVE train going
through the whole Russia ... and this is my dream ...
Yours,
Markku
------------------------------
From: "Markku J. Saarelainen" <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.cia
Subject: In the information security field there are people who can handle the
Date: Sun, 05 Mar 2000 06:05:33 GMT
In the information security field there are people who can handle the
pressure and they start taking PAMMEJA .. I learned this from one AALIO
.. joukaa vaan sita viinaa siella .... no real info sec expert has ever
drunk to control himself or herself .. .. JOUKAA VIINAA NIIN MINA VOIN
CONTROLLOIDA TEITA ENEMMAN ..
------------------------------
From: "Scott Sherer" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.basic.visual.3rdparty,comp.lang.basic.visual.misc,sci.math
Subject: Re: Large interger package for VB?
Date: Sun, 05 Mar 2000 06:15:54 GMT
Actually, I had to create a dll that did LARGE_INTEGER math. What I did,
was I wrote a simple dll in VC6 that uses the __int64 variable type. From
VB, I would pass in my LARGE_INTEGER's and receive a new LARGE_INTEGER with
the results. I still use it to do large integer math when calling the
QueryPerformanceCounter API. (high-resolution timers).
Here's the code:
// 64Math.cpp : Defines the entry point for the DLL application.
//
#include "stdafx.h"
#include "math.h"
#include "string.h"
#include "stdio.h"
BOOL APIENTRY DllMain( HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
return TRUE;
}
typedef struct _L64 {
unsigned dwLow;
unsigned dwHigh;
} L64, *LPL64;
__int64 L64ToInt64(IN L64 lp64)
{
__int64 i64;
i64 = (__int64)lp64.dwHigh<<32;
i64 += lp64.dwLow;
return i64;
}
BOOL WINAPI Add ( IN LPL64 lpAdd1,
IN LPL64 lpAdd2,
OUT LPSTR pL64
)
{
__int64 i64 = L64ToInt64(*lpAdd1) + L64ToInt64(*lpAdd2);
memcpy(pL64, &i64, 8);
return true;
}
BOOL WINAPI Neg ( IN LPL64 lpAdd1,
IN LPL64 lpAdd2,
OUT LPSTR pL64
)
{
__int64 i64 = L64ToInt64(*lpAdd1) - L64ToInt64(*lpAdd2);
memcpy(pL64, &i64, 8);
return true;
}
BOOL WINAPI Mul ( IN LPL64 lpAdd1,
IN LPL64 lpAdd2,
OUT LPSTR pL64
)
{
__int64 i64 = L64ToInt64(*lpAdd1) * L64ToInt64(*lpAdd2);
memcpy(pL64, &i64, 8);
return true;
}
BOOL WINAPI Div ( IN LPL64 lpAdd1,
IN LPL64 lpAdd2,
OUT LPSTR pL64,
OUT LPSTR pL64R
)
{
__int64 i64 = L64ToInt64(*lpAdd1) / L64ToInt64(*lpAdd2);
__int64 i64r = L64ToInt64(*lpAdd1) % L64ToInt64(*lpAdd2);
memcpy(pL64, &i64, 8);
memcpy(pL64R, &i64r, 8);
return true;
}
BOOL WINAPI Str ( IN LPL64 lpAdd1,
OUT LPSTR pString
)
{
sprintf(pString,"%I64d\0",L64ToInt64(*lpAdd1));
return 0;
}
Ed Pugh <[EMAIL PROTECTED]> wrote in message
news:88sit3$34i$[EMAIL PROTECTED]...
>
> Hi.
>
> I want to use Visual BASIC (5.0, pro ed'n, SP3) to do some
> prototyping and experimenting with algorithms involving very
> large natural numbers or integers.
>
> Does anyone know if and where I can find and download a
> *FREEWARE* (or *UNCRIPPLED* shareware) VB class or "library"
> that can handle arbitrarily large natural numbers or integers
> (up to a few thousand bits long)? (And it has to work with
> VB 5.0.)
>
> The package must be able to handle large integer arithmetic
> and, at the very least, must include functions to perform
> basic math operations on large integers including addition,
> subtraction, multiplication, division, and finding least
> positive residues (i.e. the "remainder" of one large integer
> divided by another).
>
> If the package also includes any of the following, that would
> be a bonus:
>
> o modulo arithmetic including modulo addition, subtraction,
> multiplication and exponentiation
>
> o "shifting" left or right by an arbitrary number of bits
>
> o concatenating two large integers each of any arbitrary bit
> size, into one larger integer whose bit size is the sum
> of the bit sizes of the two original integers
>
> o splitting a large integer at any arbitrary bit, into two
> smaller integers
>
> o finding the gcd (or lcm) of two large integers (e.g.
> Euclid's Algorithm for gcd)
>
> o finding the multiplicative inverse of one large integer
> modulo another (when the two integers are co-prime; e.g.
> Extended Euclid Algorithm)
>
> o probabilistic primality testing (or deterministic or both;
> e.g. Fermat's test and/or Miller-Rabin test)
>
> o UI for display and input of large numbers (I would like to
> be able to input and display large numbers in hexadecimal,
> decimal and binary).
>
> o generate a good pseudo-random number of any arbitrary bit
> size
>
> Yes, I *could* write such a package myself, but why re-invent
> the wheel if it has already been done and is freely available?
>
> (And, yes, I know that these operations on very large integers
> will be painfully slow in VB, but this is just for prototyping
> and experimenting; i.e. "playing around". :-)
>
> If you follow-up here, that's great; but if you also cc: my
> E-mail address:
>
> [EMAIL PROTECTED] (alias [EMAIL PROTECTED])
>
> that would be even greater (due to the number of cross-posts
> for this query).
>
> With thanks and regards,
> --
> Ed Pugh, <[EMAIL PROTECTED]>
> Richmond, ON, Canada (near Ottawa)
> "Bum gall unwaith-hynny oedd, llefain pan ym ganed."
> (I was wise once, when I was born I cried - Welsh proverb)
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Best language for encryption??
Date: Sat, 04 Mar 2000 23:58:08 -0600
In article <89s61m$vdp$[EMAIL PROTECTED]>, Bryan Olson
<[EMAIL PROTECTED]> wrote:
> wtshaw wrote:
> [...]
> > 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.
>
>
> A programmer's code speaks for itself.
>
>
> On 03 Jan 2000 in sci.crypt, wtshaw wrote:
> | Here is a demo function that converts come
> | characters to trits. The code characters list
> | can be easily extended to whatever you care to
> | include.
> [...]
What is the problem Bryan?
Imagine that some snippits of code may not be worthy implementations, but
bread- boarded ideas to illustrate a point.
The fact that it was written console fashion was because it seems that is
what many want....I was sorta slumming with the style, certainly not
pretending to make a high grade application. That it took only a few
minutes to write and ran perfectly the first time should speak to saving
time.
In fully implementing the related family of ciphers, Fractuated Morse,
Morbit, Pollux, I see the main problem in clean exception handling of
nonsense sequences. In fact, it appears that it is almost as practical to
produce something that solves for unknown keys as to make something that
does not.
The code posted was sufficient to get some statistics on compression that
is used in traditional trits, morse code. Remember that the resulting
trit format identifes spaces as well as letters. The result is even more
impressive regarding compression than when a simple letter count is made.
That was the purpose of it. Remember...compression?
Perhaps useful is a dynamic assignment of trits to build the best
compression scheme one could with pattern text. The question remains as
to whether much improvement can be made over traditional assignments.
There are other ways to solve the same problem, arrays, even external
files, heaven forbid. Such snippits for investigating ideas are not worth
permanent compilation anyway.
When and if I actually make a full implementation of one of these ciphers,
I would expect to have a handle on something to be proud of, or I will be
doing something else.
In the classics lineup, grilles are on that agenda for now, and this is
not as simple as you might at first believe from a programming point of
view, however, it will likely come down to constucting a linear template
for candidate configurations.
--
Imagine an internet on an up and up basis, where there are no subversive techniques to
rob a person of their privacy or computer
functionality, no hidden schemes used to defraud anyone. :>)
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Best language for encryption??
Date: Sat, 04 Mar 2000 23:55:54 -0600
In article <89s61m$vdp$[EMAIL PROTECTED]>, Bryan Olson
<[EMAIL PROTECTED]> wrote:
> wtshaw wrote:
> [...]
> > 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.
>
>
> A programmer's code speaks for itself.
>
>
> On 03 Jan 2000 in sci.crypt, wtshaw wrote:
> | Here is a demo function that converts come
> | characters to trits. The code characters list
> | can be easily extended to whatever you care to
> | include.
> [...]
What is the problem Bryan?
Imagine that some snippits of code may not be worthy implementations, but
bread- boarded ideas to illustrate a point.
The fact that it was written console fashion was because it seems that is
what many want....I was sorta slumming with the style, certainly not
pretending to make a high grade application. That it took only a few
minutes to write and ran perfectly the first time should speak to saving
time.
In fully implementing the related family of ciphers, Fractuated Morse,
Morbit, Pollux, I see the main problem in clean exception handling of
nonsense sequences. In fact, it appears that it is almost as practical to
produce something that solves for unknown keys as to make something that
does not.
The code posted was sufficient to get some statistics on compression that
is used in traditional trits, morse code. Remember that the resulting
trit format identifes spaces as well as letters. The result is even more
impressive regarding compression than when a simple letter count is made.
That was the purpose of it. Remember...compression?
Perhaps useful is a dynamic assignment of trits to build the best
compression scheme one could with pattern text. The question remains as
to whether much improvement can be made over traditional assignments.
There are other ways to solve the same problem, arrays, even external
files, heaven forbid. Such snippits for investigating ideas are not worth
permanent compilation anyway.
When and if I actually make a full implementation of one of these ciphers,
I would expect to have a handle on something to be proud of, or I will be
doing something else.
In the classics lineup, grilles are on that agenda for now, and this is
not as simple as you might at first believe from a programming point of
view, however, it will likely come down to constucting a linear template
for candidate configurations.
--
Imagine an internet on an up and up basis, where there are no subversive techniques to
rob a person of their privacy or computer
functionality, no hidden schemes used to defraud anyone. :>)
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: On jamming interception networks
Date: Sun, 05 Mar 2000 07:09:03 GMT
Mok-Kong Shen wrote:
> Douglas A. Gwyn wrote:
> > David A Molnar wrote:
> > > I do not think that's what was meant by the statement "That
> > > argument isn't even worthy of a sophomore", however.
> > Right; it meant "calling that argument sophomoric would be an
> > insult to sophomores!"
> But nobody was 'calling that argument sophomoric' ...
I would have, except that calling that argument sophomoric would
be an insult to sophomores. (You're supposed to recognize the
reference to "A Fish Called Wanda".)
> ... and it isn't very
> clear what 'that arguemt' being referred to exactly is.
It was your argument (quoted in my posting) to which my statement
"That argument isn't even worthy of a sophomore." was the response.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Can someone break this cipher?
Date: Sun, 05 Mar 2000 07:17:06 GMT
Daniel wrote:
> Of course, there's no reward for breaking someone's cipher other than
> intellectual glory - unless one works in a modern black chamber :-)
That's not true -- if you have the morals of a criminal, there is a
lot of money to be made by stealing encrypted information.
> What would a professional cryptographer do besides collecting
> messages and hope for some human error?
Cryptanalysts, not cryptographers, are the breakers of cryptosystems.
As I said in another response very recently, an in-depth explanation
of how cryptanalysis is done would be impossible in this forum, but
it is explained in various texts; see the sci.crypt FAQ for references.
*There is no easy recipe; it requires experience and understanding.*
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Best language for encryption??
Date: Sun, 05 Mar 2000 07:25:14 GMT
wtshaw wrote:
> Programing has one effect, it either does what you want it to do,
> or it doesn't; all else is unimportant.
Wrong! There are a *lot* more important factors in programming
than just that one. The attitude you expressed was responsible
for major disasters in software during the late 1960s and early
1970s, to the extent that it was generally considered a crisis
situation. Out of that crisis rose the development of software
engineering as a disciplined activity. One of the most readable
surveys of different approaches to this area is P.J. Plauger's
book "Programming on Purpose", which is mainly reprints of some
of his magazine columns.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Crypto.Com, Inc.
Date: Sun, 05 Mar 2000 07:30:54 GMT
Mok-Kong Shen wrote:
> We can see light only in a limited frequency range. However, I
> suppose transmission over radio can be over a very large range.
> If a message is split and sent over a number of frequencies and
> if these frequencies could be managed to be varying with time,
> I wonder how easy is this for the opponent to track in practice.
> Crpto textbooks don't seem to treat this. Could someone please say
> a bit about that issue? Thanks.
It's called "spread spectrum" communications and is a well developed
field. It offers advantages in noise reduction as well as privacy.
The form you seem to have in mind is called "frequency hopping", and
is used in many radios, including current combat gear. If you know
the terms to search for, given in quotes above, you should be able
to find numerous references on the Web.
------------------------------
** 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
******************************
