general question to aspect-oriented-programming

From: Julia Donawald (julia.donawald_at_gmx.de)
Date: 12/31/04


Date: Fri, 31 Dec 2004 00:05:27 +0100

Hi,

I am trying to write a simple aspect with AspectJ for secret-key and
public-key encryption of data. I am not that familar with the approach of
aspect-oriented-programming, so I am thinking of how to realize it.

I started to write a basic aspect for secret-key encryption which uses a
function-pointcut from which it get the data to encrypt/derypt and the key.
I defined then an advice which is always called when the pointcut is
matched. This advice (in my test-example I used an before-advice) takes as
input-parameter the data to encrypt/decrypt and the secret-key. It then
performs the encryption/decryption functionality and saves the result in a
parameter.

I wonder now if this is a senseful way writing an apspect for
encryption/decryption, cause as I know the aspect should be totally
independent from its business-logic. In my case the advice is strongly
connected to the keys and the proecessing depends from the key it gets as
parameter from the "pointcutted"-function in the business-code. I am
thinking now if it would be better to hardcode the key in the advice,
although from a security point-of-view that doesn't make much sense, cause
everyone who uses the apsect can break the encryption. Is there any senseful
possibility for writing an aspect for secret-key encryption? How would you
solve such a problem, cause I am still in a starting-phase of undestanding
the aspect-oriented-programing approach.

In fact I found the following paper
today:
http://www.cs.kuleuven.ac.be/~distrinet/events/aosdsec/AOSDSEC04_Minwell_Huang.pdf
and I wonder now why on page 3 in the around-advice of the AbstractDESAspect
the pointcut encryptOperations has a parameter for the message which should
be encrypted but no key which should be used for encryption. Rathern then
giving the key as parameter, the key is hardcoded in the body of the advice.
Is there any reason for doing this?

Thanks a lot in advance,
Julia



Relevant Pages

  • Re: own string class
    ... perhaps the same reason they'd "object" to me writing my own ... encryption or compression? ... It seems a lot of the time when I ask for advice about how to do something, ...
    (microsoft.public.vc.language)
  • Re: Protection!
    ... In addition to Mike's good advice re: ... a manual was supplied with your wireless hardware.. ... Encryption or? ... >> JCW ...
    (microsoft.public.windowsxp.newusers)
  • Re: Simple Encryption - what function/module could I use?
    ... > can give no good advice; ... easily undo the encryption in a short period of time and if the ... attacker has access to the source code then he/she will be able to ... If there are legal reasons for encrypting the ...
    (perl.beginners)
  • Re: Wireless security
    ... Since it is a criminal offence to protect data adequately using encryption* any other option is denied. ... there is only one type of encryption that is unbreakable by non-us agencies and that is not available to the likes of you and me. ... your advice to "assume that wifi devices are vulnerable and not keep anything on them that you would be unhappy to be in the public domain" is the best possible advice. ...
    (uk.business.agriculture)
  • Re: Encrypted filesystem experience
    ... > There are an old advice to NOT encrypt a file twice with the same encryption ... There are rumors that doing a ROT-13 twice ... top-secret nobody is allowed to know, like the fact that there were no ...
    (alt.os.linux.suse)