Searching \ for '[PIC]: Data Encryption Using PIC16F84' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/memory.htm?key=data
Search entire site for: 'Data Encryption Using PIC16F84'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Data Encryption Using PIC16F84'
2002\05\13@063139 by Werner Soekoe

flavicon
face
Hi everyone.

I'm trying the impossible. I want to design a circuit using a PIC16F84 that transmits data to a computer. I want this data to be encrypted, however. I've been looking into using RSA encryption (as low as 32-bit), but I can't imagine the F84 handling these kind of calculations (32bit value to the exponent of another 32bit value). The idea was to have it work like this:

PIC = PIC based circuit
COMP = Host Computer

PIC -> COMP : Hey, I want to send data!
*COMP* : Computer generates random public and private keys
COMP -> PIC : OK. Here is a public key to use.
*PIC* : Encodes data with public key
PIC -> COMP : Here is the encrypted data
*COMP*: Decrypts the data using private key
COMP -> PIC : Thanks, the data was decrypted and valid

Then repeat the process as required.

Does anyone have any better idea of an encryption/decryption method to use? The basic idea is just to be able to transmit data without anybody tapping into the physical wire being able to see what's being transmitted.

Thanks!

Regards,
Werner Soekoe
spam_OUTWernerSTakeThisOuTspamfsl.gov.za

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\05\13@080052 by Jinx

face picon face
Have you looked at TEA

http://vader.brad.ac.uk/tea/tea.shtml

PIC-specific TEA

http://www.brouhaha.com/~eric/crypto/

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\05\13@083653 by Mike Singer

picon face
>
>Hi everyone.
>
>I'm trying the impossible. I want to design a circuit using
>a PIC16F84 that transmits data to a computer. I want
>this data to be encrypted, however. I've been looking
>into using RSA encryption (as low as 32-bit),
.
.
.
>Does anyone have any better idea of an encryption/decryption
>method to use? The basic idea is just to be able to transmit
>data without anybody tapping into the physical wire being able
>to see what's being transmitted.
>
>Thanks!
>Regards,
>Werner Soekoe .....WernerSKILLspamspam@spam@fsl.gov.za

  Yes, the best way to keep your home secrets is to start asking
every human on the planet how you should keep them, sending
everywhere the return address.
  Create your own simple and unique method based on real time
clock for example. All this 007-agents will get crazy solving it,
thinking you are using new super-dooper-brand_american-algorithm.

  Mike.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\05\13@085714 by Amaury Jacquot

flavicon
face
Quoting Mike Singer <mikespamKILLspampoluostrov.net>:

{Quote hidden}

On the contrary, this is the proper way to do this, opposing this to the
myriad of el-cheapo-file-encryption-tools that you can find everywhere
on shareware sites.

I personnaly have done this kind of thing using DES as the encryption on
"Silver card II" devices (16F877 controllers + 24LC64 eeprom).
The trick to the system is that the program runs 2 modes.
The first mode is the "personnalise" procedure. This is the mode the card
comes in the first time after it is programmed. This mode allows for several
things to be set, such as the card's internal encryption key, stored in the
pic's internal eeprom.
The personalisation is started by a specific iso instruction which starts the
key generation procedure.
This procedure basicly takes a shitload of bytes sent by the host and generates
a key via some xor.
the bytes are generated from the system random generator

Then all data that is stored in the card is encrypted with the key via DES
before being written to the eeprom

Sincerely

Amaury

--

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\05\13@091407 by Werner Soekoe

flavicon
face
Jinx,

Thanks, I'm busy checking it out!

Cheers
Werner

----- Original Message -----
From: "Jinx" <EraseMEjoecolquittspam_OUTspamTakeThisOuTCLEAR.NET.NZ>
To: <PICLISTspamspam_OUTMITVMA.MIT.EDU>
Sent: Monday, May 13, 2002 1:59 PM
Subject: Re: [PIC]: Data Encryption Using PIC16F84


{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\05\13@092658 by Werner Soekoe

flavicon
face
Amaury,

The idea I had was to use a public/private key system to ensure assymetric
operation. The difference however is that the PIC device will never store
any key. It will however, request a public key from the host computer that
it will use to encrypt the data with. The host computer will however, give a
new random public key every time, and the private key for that session only
will be stored in the host computer's memory, until the session has ended.
One session should not last more than 2 seconds. Only enough time for the
PIC circuit to send 256 bytes of data at a time (including overheads).

The problem with a permanent public key programmed on the PIC device, is the
ability to "rip" the protected code and/or eeprom memory on some PIC
devices. Even though Microchip confirms that this is no longer possible, I'm
still a bit sceptical.

Another issue is the limited functionality of the 16F84, which I'm
targetting for the circuit. Even on a bit a higher MCU, like the 16F877, for
instance, I cannot see myself performing the kind of math required by the
RSA cipher, where 128-bit encryption is, according to me, the bare minimum.
I have considered going as low as 32-bit encryption, using hashing to
further encode the data, but 2^32^32 math is a bit complex for normal PICs.

Jinx recommended a cipher known as TEA, which I'm busy looking into (thanks,
Jinx).

Thanks for the advise anyway.

Cheers
Werner
@spam@WernerSKILLspamspamfsl.gov.za



{Original Message removed}

2002\05\13@101919 by Olin Lathrop

face picon face
> Does anyone have any better idea of an encryption/decryption
> method to use?

Probably, and part of what makes it better is not telling anyone how it
works.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\05\13@103412 by Werner Soekoe

flavicon
face
Olin write:

> Probably, and part of what makes it better is not telling anyone how it
> works.

Then it must be easily crackable! ;-)

Cheers
Werner

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\05\13@122459 by M. Adam Davis

flavicon
face
Of *course* the PIC can do the RSA algorithm.  Heck, you can decode MP3s
on the PIC, and even do raytracing.

The question is how fast do you want to process this data?  It sounds to
me like a computer dongle.  I hope not, I hate those things.

But if that's all it is then you can probably expect to be able to do a
fairly complex (higher bit) RSA on a several byte word in a second or
so.  If cost is not an issue then use a PIC with a single cycle 8x8
multiply.  Better yet, use the new DSpic (samples coming to a supplier
near you... maybe...Real Soon Now(tm)) which has a nifty multiply and
accumulate (among other things) instruction which simplifies just these
kinds of tasks.

Make sure that whatever data you're sending changes every time and is
not guessable - put a semi-random counter value in, the time, current
temperature, maybe a stream of ones and zeros from a noisy transister
(why don't they put a noisy transister inside the PIC as a peripheral?
Make it rotate into a register that can be accessed as an 8 bit random
value?  It wouldn't be completely random, but it couldn't take up that
much die space and will be better than a PRNG...  )

-Adam

Werner Soekoe wrote:

{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\05\13@130503 by Bob Ammerman

picon face
It is well accepted that the most secure encryption schemes are based on
publicly known and well tested algorithms. Security depends on proper key
management rather than obscurity of tecnique.

Bob Ammerman
RAm Systems

{Original Message removed}

2002\05\13@132215 by Sean H. Breheny

face picon face
What about doing both? Make your own obfuscated system and use it to
encrypt the well-tested system's ciphertext. Seems to me that this has all
the advantages of both and very few disadvantages. Beware of doing it the
other way around, though, since your system could easily make things less
secure if you used it to encrypt the plain text first (because your method
could introduce some known text into the plaintext).

Sean

At 12:59 PM 5/13/02 -0400, you wrote:
>It is well accepted that the most secure encryption schemes are based on
>publicly known and well tested algorithms. Security depends on proper key
>management rather than obscurity of tecnique.
>
>Bob Ammerman
>RAm Systems

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\05\13@200920 by Ashley Roll

flavicon
face
Hi Werner

If you're trying to protect the data being transferred between the PIC and
the host computer because you're worried about people looking at the data on
the connection cable your going to have problems here for an attacker with
half a clue.

It would be simple enough to implement a "man in the middle" attack where a
device is inserted into the data stream and captures your public key and
sends a different one to the pic. The pic then happily encrypts the data,
the attacker decrypts it because they know the key they sent. Then they can
encrypt it with the key you issued and send it on and you'll be none the
wiser.

Note also that if they have access to the communication it would be trivial
to just ask for the data from the pic as if they were the host.

The problem is that in your scheme, the PIC has no way to authenticate that
the request is from the correct host. Also I hope the PC is "secure" and
under your control because if its not, then the user could get the data with
a little messing around.

Cheers,
Ash.

---
Ashley Roll
Digital Nemesis Pty Ltd
http://www.digitalnemesis.com
Mobile: +61 (0)417 705 718



{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\05\13@203101 by Jon Baker

flavicon
face
----- Original Message -----
From: "Werner Soekoe" <RemoveMEWernerSTakeThisOuTspamfsl.gov.za>
Sent: Monday, May 13, 2002 2:24 PM
Subject: Re: [PIC]: Data Encryption Using PIC16F84


> The problem with a permanent public key programmed on the PIC device, is
the
> ability to "rip" the protected code and/or eeprom memory on some PIC
> devices. Even though Microchip confirms that this is no longer possible,
I'm
> still a bit sceptical.

If you're serious about the need for data encryption, then the slightest
chance that the code and or eeprom could be extracted should make you steer
clear of /whichever microcontroller/.

There seems little point in encrypting things, if a hacker can just read
your chip and reverse engineer your code. - or am I missing something?

--
Jon Baker

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\05\14@022039 by Werner Soekoe

flavicon
face
Jon,

Even if the code could be ripped of a microcontroller, implementing a
public/private key encryption would render the code useless, especially if
the PIC is assigned a new public key for every new transmission. Or am I
wrong at assuming this?

Cheers
Werner


{Original Message removed}

2002\05\14@025410 by Mike Singer

picon face
Bob Ammerman wrote:

>It is well accepted that the most secure encryption schemes are based on
>publicly known and well tested algorithms. Security depends on proper key
>management rather than obscurity of tecnique.

>Bob Ammerman
>RAm Systems

  Look Bob, this boy who asked for the help is from somewhere
at the other end of the Earth, not US. You propose him US $ Europe
"publicly known and well tested algorithms". You better should
propose him to keep his big secrets directly in the White House
and a copy in the Kremlin, Moscow for more safety.

  Best regards.
  Mike.

P.S.:
  Sorry, if my postings looks like a bit offensive. I didn't want it.
  It is due to my limited command of English.

----------------------------------------------------------------------------
  Thanks to James Newton, Dale Botkin & others for supporting this forum.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\05\14@035406 by Jon Baker

flavicon
face
From: "Werner Soekoe" <spamBeGoneWernerSspamBeGonespamfsl.gov.za>


> Jon,
>
> Even if the code could be ripped of a microcontroller, implementing a
> public/private key encryption would render the code useless, especially if
> the PIC is assigned a new public key for every new transmission. Or am I
> wrong at assuming this?

I suppose the application has a lot to do with how successful you will be in
implementing good security.

For example, if the physical location of the pic is secure, then it would be
safer to store the public key in the pic, than risk a man in the middle type
attack as Ashley said.

If the pic is accessible and I can read the code, I would be able to
duplicate its function so that the PC end could not tell any difference, but
also add extra functions to transmit the data before it got transmitted.

Im sure there's lots of other scenarios, but the way you solve the problem
really depends on your application, the location of the parts, and the
reason you are encrypting the data.

Jon Baker
--

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\05\14@040901 by System Administrator

flavicon
face
Security by obscurity? I'd rather sceptic...

Imre

On Mon, 13 May 2002, Olin Lathrop wrote:

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\05\14@074145 by Olin Lathrop

face picon face
> > > Does anyone have any better idea of an encryption/decryption
> > > method to use?
> >
> > Probably, and part of what makes it better is not telling anyone how it
> > works.
>
> Security by obscurity? I'd rather sceptic...

As Bob and others have pointed out, security by obscurity is not a good
defense.  In theory you should be able to publish your algorithm and it
still couldn't be cracked.  However, all things being otherwise equal, I
would rather have a good algorithm AND keep it secret than have the same
algorithm and tell everyone how it works.  It's just one more hurdle an
attacker has to overcome.

In the end, security is really an economic issue.  Anything can be broken
into given enough resources.  In this light, security is achieved by raising
the cost to break in beyond an attackers means.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\05\14@083507 by Bob Ammerman

picon face
Olin stated:

> As Bob and others have pointed out, security by obscurity is not a good
> defense.  In theory you should be able to publish your algorithm and it
> still couldn't be cracked.  However, all things being otherwise equal, I
> would rather have a good algorithm AND keep it secret than have the same
> algorithm and tell everyone how it works.  It's just one more hurdle an
> attacker has to overcome.

The problem with this is that you never really know if you have a good
algorithm. Only by exposing it to the massed minds of crypto-folk can you
start to build any confidence in it.

> In the end, security is really an economic issue.  Anything can be broken
> into given enough resources.  In this light, security is achieved by
raising
> the cost to break in beyond an attackers means.

or...

Security is acheived by raising the cost to break in beyond the value of the
secured information.

Bob Ammerman
RAm Systems

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\05\14@171505 by Mike Singer

picon face
Olin stated:

> As Bob and others have pointed out, security by obscurity is not a
> good defense.  In theory you should be able to publish your algorithm
> and it still couldn't be cracked.

  I could scarcely believe, that someone would pay his taxes to his
government if it would not will to control data encryption algorithms.
The horror of the september events is still in my mind.
  This boy who asked for the help was from one of the third countries.
His address was like .gov. What's the sense in recomending him
data encryption algorithm, controlled by someone's government?

Sincerely.
Mike.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\05\14@173127 by Peter L. Peres

picon face
On Tue, 14 May 2002, System Administrator wrote:

>Security by obscurity? I'd rather sceptic...

Obscurity has nothing to do with it. It's just that they prefer to choose
who reviews their algorythms.

Peter

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\05\14@180109 by Peter L. Peres

picon face
On Wed, 15 May 2002, Mike Singer wrote:

>Olin stated:
>
>> As Bob and others have pointed out, security by obscurity is not a
>> good defense.  In theory you should be able to publish your algorithm
>> and it still couldn't be cracked.
>
>   I could scarcely believe, that someone would pay his taxes to his
>government if it would not will to control data encryption algorithms.
>The horror of the september events is still in my mind.
>   This boy who asked for the help was from one of the third countries.
>His address was like .gov. What's the sense in recomending him
>data encryption algorithm, controlled by someone's government?

Maybe because most people outside the ex-ussr still believe that you can
exchange knowledge safely with people who are not in jail and not sheduled
to be shot at dawn. It's one of those unexplainable things often done in
the west, you know. It's similar to their unexplainable attitude towards
their populace, letting them travel like that unherded, uncounted and
unchecked, own things that are not confiscated the next day, have valid
passports and actual money that is not just cheap pictures on cheap paper
nobody wants etc. Rumors say it has to do with their early recognition of
the fact that most people are innocent and honest and there are few of
other kinds who need to be seeked out individually. I know that your
country and some others are inclined towards the more wholesale way of
implementing this. Sorry.

Peter

PS: I'd like the 'boy' to state his age just to put the things into
context ;-)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\05\14@181224 by Dale Botkin

flavicon
face
OK, we can take *THIS* discussion either [OT] or off-list...

Thanks...

Dale
--
"Curiosity is the very basis of education and if you tell me that
curiosity killed the cat, I say only the cat died nobly."
         - Arnold Edinborough


On Wed, 15 May 2002, Peter L. Peres wrote:

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\05\15@023556 by Werner Soekoe

flavicon
face
Mike Singer said:
>   Look Bob, this boy who asked for the help is from somewhere
>at the other end of the Earth, not US. You propose him US $ Europe
>"publicly known and well tested algorithms". You better should
>propose him to keep his big secrets directly in the White House
>and a copy in the Kremlin, Moscow for more safety.

>  I could scarcely believe, that someone would pay his taxes to his
>government if it would not will to control data encryption algorithms.
>The horror of the september events is still in my mind.
>   This boy who asked for the help was from one of the third countries.
>His address was like .gov. What's the sense in recomending him
>data encryption algorithm, controlled by someone's government?

Peter L. Peres Added:
>PS: I'd like the 'boy' to state his age just to put the things into
>context ;-)

Thanks Peter.

Yes, I'm not a boy. I really feel deeply offended by Mike Singer's comments.
I'm aged 25, work for the Legislature in one of the provinces (also known as
Provincial Parliament) where I run, manage and maintain all of the IT,
Audio/Visual and Electronic aspects of the Legislature. I also handle
programming of network applications, from logon script processors to
database systems for logging Internet access by our users.

Mike's further statement that I'm from a third world country is even more
offensive. While South Africa still has a long way to go to get there, at
least something is happening. Take for instance the South African
Government's commitment to the African continent and the uplifting and
rebuilding thereof. We strive to better our own circumstances and develop
our country and community.

The request for an encryption algorithm is/was for use in an access control
system to our building. For controlling who gets in and out. The encryption
was to prevent unauthorized people from tapping into the data lines and rip
the access codes to use themselves for access. Yet, Mike was convinced that
I am from a secret government institution that wanted to know exactly how to
use a 10 billion bit cipher to use on a secret nuclear weapon to blow up
Ukraine (that's where your from, right?). No my friend. Those days are gone.
I even stated that I wanted to use a PIC16F84 or similar in the application.
Can you imagine, a big secret weapon controlled and guided by a PIC16F84???

The threat to society is terrorism, which was the cause of the September
11th catastrophe. My heart went out to America and their great loss (my
sister is an American), like most honest people over the world. Privacy,
however, is every person's constitutional right, and proper encryption is
the way to achieve this. Privacy to protect information, intellectual
property and oneself. I can see no harm in this context.

Mike, I suggest that you think twice before insulting people like this. The
wheel is turning, and someday it will be your turn. I also wish to suggest
that you learn to speak English properly, because I'm not quite sure what
you really tried to say, and I'm sure I'm not the only person.

Thanks to everyone who did give useful input. Like most people, I feel the
urge to do everything to the best of my ability. And even though a simple
XOR every byte with 10110011 *could* have done the trick, I would not have
been satisfied with my effort. So at this stage I'm considering DES, TEA or
a scaled down RSA.

Best Regards,
Werner Soekoe
Information Systems Manager
Free State Legislature
South Africa
TakeThisOuTWernerSEraseMEspamspam_OUTfsl.gov.za

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2002\05\15@174245 by Stephen Wrobleski

flavicon
face
I would suppose that you do not want a public key/private key encryption
system, but instead you want a one-way cryptographic hash. A cryptographic
hash works by taking some input data and computing a value for the data that
can be used to verify the accuracy of the data, but is very hard or
impossible to come up with the input data, or any other possible input data
that would yield the same hash value. Two examples of these that come to
mind are MD5 and SHA-1. I'm not sure if these are applicable to your
application (you'd have to figure that out.. if memory serves correctly,
hashing small and repeatable things might be a bad idea. i forget the exact
circumstances, -definitely- investigate this).

I'm assuming that you're worried about people inside the organization
tapping into the line, getting a list of codes, and distributing them to
outside agencies, or using them after they quit working there, or something
where somebody wishes to be able to open the door in the future.

So you have the server, and client. The server has a list of the keys, and
the client is your keypad device. I would propose the following scheme..

1. Client tells server 'Somebody just entered a number, I need to verify it'
2. Server sends client a string of bytes (and remembers it)
3. Client hashes the string of bytes, plus whatever the user entered on the
  keypad and possibly some extra stuff, and sends the result back to the
  server
4. The server computes the hash as well, from the same data as the client
  (it uses the real keycode of course), and then compares the two hashed
  values. They will match if the user entered the right keycode

This in general is known as a challenge-response scheme.

The 'extra stuff' could consist of the time, if the clocks were
synchronized, or maybe a shared secret. You might have to do a little extra
to check a few times depending on the precision of the clocks on either
end of the system, or how much they were synchronized. The string of bytes
the server sends should be unique for every challenge.

Now of course, if you want to have the 16F84 open the door as well, you
probably want a secure way of triggering that opening as well (so somebody
cannot have a tap on the line that triggers the door to open). I'd imagine
you could have another challenge-response system in the reverse direction,
with a shared secret for authentication (unique to every 16F84). You could
store your incrementing string of bytes in flash, so when you lose power,
you don't go back to the beginning of the secret (which would allow a replay
attack, where the hash has already been computed and sent over the wire).
And when writing to flash, keep in mind that an attacker might toggle power
in the middle of the write or somesuch, so that's an area of consideration
by itself.


On side note...
Look at this vulnerability in your current system. If one can tap the line,
assume they can also put something in the middle. A very feasable attack
(even if you had 'secret' encyption algorithms) would be to steal one of the
units off of the outside of the building, or whatever is being controlled. A
clone of the 'master' unit could be developed which communicated with the
unit effectively to read the code. You could then combine this clone of the
master with the stolen unit on the middle of a line somewhere as follows..

Real Master <-----> Stolen Unit+Fake Master <-----> Door Keypad

When someone goes to use the keypad, they communicate with the fake master,
which gives them the key. The fake master can then decrypt whatever they
typed, and pass it to the stolen unit (which communicates perfectly with the
real master, even if there are some unknown protocol options, its a keypad,
so the master will like it completely).


And by the way, I'll have to mention this point... If he develops this
system in obscurity, and the security is based on it being secret, other
organizations cannot reuse this system (even in the same country. I'm sure
you don't trust all employees at all organizations to everything). If the
knowledge is public, it can be shared freely, greatly reducing work. I would
also surmise that security agencies of foreign governments have
sophisticated tools to figure out poorly implemented security schemes
easily. I bet simple schemes based on XOR/ADD/SHIFT could be mathmatically
reduced to one trivial encryption problem, and easily analyzed. Using
something home-brewed and hiding your algorithm/implementation
does not allow it to the millions of prying eyes that have been looking at
MD5/SHA1/RSA/DES/etc for a long time now, but probably does not help secure
it against even casual foreign attackers.

Steve


On Wed, May 15, 2002 at 08:33:43AM +0200, Werner Soekoe wrote:
-snip-
> The request for an encryption algorithm is/was for use in an access control
> system to our building. For controlling who gets in and out. The encryption
> was to prevent unauthorized people from tapping into the data lines and rip
> the access codes to use themselves for access.
-snip-

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservEraseMEspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2002\05\17@024742 by o-8859-1?Q?Tony_K=FCbek?=

flavicon
face
Hi,
now here's a tie in if ever :)

Secrecy, Security, and Obscurity:

http://www.counterpane.com/crypto-gram-0205.html#1


/Tony

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\05\17@034233 by Alan B. Pearce

face picon face
>Hi,
>now here's a tie in if ever :)
>
>Secrecy, Security, and Obscurity:
>
>http://www.counterpane.com/crypto-gram-0205.html#1

Yeah, now go further down the page and read about gummy bear fingerprints
:)))

Repeat after me What do you do after you are in the door ?
Eat the evidence :)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\05\17@104338 by Sean H. Breheny

face picon face
I don't understand why he doesn't consider there to be a small advantage to
obscurity. If you add an obscure layer (as I suggested several days ago)
and still have a published crypto layer (with the established layer
embedded within the obscure one), you get at least as good security as the
published method WITH the obscurity of the other method. This certainly
helps decrease the chances that the other side will be able to decipher
your message.

Sean

At 08:41 AM 5/17/02 +0100, you wrote:
{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\05\17@114336 by michael brown

flavicon
face
> Yeah, now go further down the page and read about gummy bear fingerprints
> :)))
>
> Repeat after me What do you do after you are in the door ?
> Eat the evidence :)

That's incredible, isn't it?  I know I'm gonna sleep better now, knowing
that.  :-(

michael brown

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\05\17@115243 by M. Adam Davis

flavicon
face
Creating one from a mold was interesting, but what interested me the
most was how to get and use latent fingerprints.  Their process uses an
etched PC board!

Something we can all do.  Would be even easier with a press-n-peel.

-Adam

michael brown wrote:

{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\05\19@054700 by Roman Black

flavicon
face
You are right Sean, and of course there IS a huge
advantage in encryption obscurity. The "encryption
community" seem to worship the standard systems and
for very obvious reasons. They are mainly employed
by firms that make products to support these standard
systems, or by govt agencies to make tools to use
and/or decipher the standard systems used by hopefully
everyone.

The focus of the article itself was on "standards" as
such, ie the cryptographic community are largely employed
making "standards" which are then licensed etc to the
end user. These people rarely build actual DEVICES.

The truth is that encryption by obscure algorithm can
be MUCH more secure, although much less licensable. :o)
Both the private sector cryptographers and govt people
have much to gain from everyone using the accepted
"standard" systems. With modern high speed computers any
teenager can scramble data so badly that it can never
be unscrambled (unless algorithm and key are known). Fact.
Use of non-standard algorythms give an enormous headache
to those that would like to decipher the data, where do
they start? The millions invested in people and tools
to break the standard systems are relatively useless.

The MOST secure systems utilise redundancy (hardly ever
used anymore) to add redundant (crap) data into the file.
They also encrypt the entire file as a whole, so there
is no starting point to compare one block to another
which is a common way of deciphering data. By comparison,
the "standard" systems usually avoid redundancy and
also encrypt data in small chunks (on the fly) which is
more suitable for incorporating in stream communications
like the internet etc. But NOT as secure.

As a crude example all you need to do is use a key longer
than the message, with a simple rotary substitution.
About 20 lines of Basic. The scrambled data can NEVER be
decrypted unless key is known, and data is 100% safe from
interception. The people who have stated that DES etc
are the most secure system are simply wrong, the real
benefits of DES and other similar systems come from ease
of use in stream communications and public/private key
systems etc, and it also offers an ACCEPTABLE level
of encryption. In short, the standard systems are superior
mainly from ease of use and benefits of standardisation,
NOT because they are safer. These people WANT you to
believe that the standard is the best, they don't want
people sending stuff back and forth using non standard
algorithms, because they just wouldn't have a prayer of
ever deciphering anything. :o)
-Roman


Sean H. Breheny wrote:
{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\05\19@064940 by uter van ooijen & floortje hanneman

picon face
> You are right Sean, and of course there IS a huge
> advantage in encryption obscurity.

Also a huge practical disadvantage: the risk that a decision-maker chooses a
non-public algorithm because he thinks it will offer more security. I agree
that is does, but *only* when compared to a public algorithm of exactly the
same strength (whatever that may mean). A definite advantage of a public
algorithm is that when a weakness exist and is known (by someone on this
planet) it is much more likely that the users of the algorithm will hear
about this and be able to take appropriate measures.

> The MOST secure systems utilise redundancy (hardly ever
> used anymore) to add redundant (crap) data into the file.

You are confused here. Compressing is standard crypto practice, the aim is
to *remove* redundancy, bececause redundancy always weakens the security.
(It moves the job of decrypting slightly towards 'know plaintext' or at
least 'recogniseable plaintext', which is easier than 'unknown,
unrecogniseable plaintex'.) Very secure systems actually add noise, which is
essentially a data stream with zero redundancy. The aim is often to hide the
*amount* of transmitted data, because this amount can be important
information in its own right. But this has *nothing* to do with the
encryption algorithm itself.

> As a crude example all you need to do is use a key longer
> than the message, with a simple rotary substitution

You decsribe the one-time pad, which is of course the best encryption but is
moves the whole burden of security to the key distribution. (Note that you
can use each key only once, otherwise you are essentially using a key that
is shorter than the (total of) your message(s)).

Wouter van Ooijen
--
Van Ooijen Technische Informatica: http://www.voti.nl
Jal compiler, Wisp programmer, WLoader bootloader, PICs kopen

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...