RSA public key

[Eddy]

For every new message? I imagined using the same key for each session with a possible maximum timeframe of for instance 4 hours.. That isnt good enough?

That would totally depend on the symmetric key algo that you are using.
If you use one of the common block ciphers (AES, CAST,...) you can use the same key for multiple messages. Although using a new key for every message is still safer.
Especially, if you are using RC4, you must use a different key for every message!! This is vital!

maybe i should consider RC4 then since its simple to implement. Implementing the other ones would take soo long i suspect, don't you agree?

That depends on what you mean by 'implementing'. Do you mean you need to write the code for this algo? Or just integrate existing source code into your program?
(A)RC4 assembly source code should be readily available. AES also I presume. But RC4 is much shorter and simpler to implement. And it is faster. This could be an issue for very large plaintext.
If you have RC4 source code, use that. If you have other symmetric key algo source code, you can use that also.

Kind regards

[niox]

For every new message? I imagined using the same key for each session with a possible maximum timeframe of for instance 4 hours.. That isnt good enough?

That would totally depend on the symmetric key algo that you are using.
If you use one of the common block ciphers (AES, CAST,...) you can use the same key for multiple messages. Although using a new key for every message is still safer.
Especially, if you are using RC4, you must use a different key for every message!! This is vital!

maybe i should consider RC4 then since its simple to implement. Implementing the other ones would take soo long i suspect, don't you agree?

That depends on what you mean by 'implementing'. Do you mean you need to write the code for this algo? Or just integrate existing source code into your program?
(A)RC4 assembly source code should be readily available. AES also I presume. But RC4 is much shorter and simpler to implement. And it is faster. This could be an issue for very large plaintext.
If you have RC4 source code, use that. If you have other symmetric key algo source code, you can use that also.

Kind regards

Awesome Eddie :) You really know your stuff.

Yeah ideally i want is to implement it all myself. Therefore the less complexity of encryption algo the better.. So that i don't mess stuff up.
I'll now also consider having using RC4 and just using new keys for each message like you are saying..
Otherwize there might be some open source source code for one of the other encryptions that i can reimplement..

But first i will try to get the RSA thing solved :)

thx alot

[Ghandi]

Yes, I read it today.
There is one thing that needs to be clarified. And that is the meaning of the word 'broken' in this context.

Before saying that RSA-768 is unbroken, we should consider that they made over 5TB of rainbow tables, and now its a matter of a lookup, which will take minutes to hours. Imho i dont condider RSA-768 unbroken in its vanilla (RFC) form. Now that they've done this, what's the next keysize to fall? I seriously doubt that organizations like the NSA would have a problem with 100TB, 1000TB worth of HDD and the mind boggles at the computational power they could lay their hands on if they want to build insane sized tables.

Also the fact it was broken once, irrespective of MIPS time taken, means it has been broken and will be again.

HR,
Ghandi

[Eddy]

what's the next keysize to fall? I seriously doubt that organizations like the NSA would have a problem with ...

Again, what does 'broken' mean and in what way does it affect us? (see my other post in this thread).
In other words: do you have encrypted data that the NSA is enough interested in to spend millions of dollars of computing resources on ?
Even if it is possible, that does not mean that someone is willing to spend enough money and resources on cracking your encrypted data.

[Eddy]

If you live in the USA, UK .. be warned the 'psycho boys' will be after you if you go public with very good encryption code -

As a little anecdote on this. I do not live in the US. I live in Belgium, Europe. To comply with the law in my country, I had to apply for an export license in order to sell my crypto library HIME.
I had to request such an export license to the Arms Control Department of my governement, which I did.
There I was, asking these guys, that are normally occupied issuing licenses for the export of cannons, heavy machine guns, grenades, ammunition, jet fighter radars, etc. for an export license of a little piece of software worth 59 USD...  :bg
Telling from their reaction, I was the first in Belgian history to do so ...  :dazzled:
Obviously this was new terrain for them. Nevertheless they were awfully helpfull and friendly. And the license did not cost me a cent. I have to renew it every year though ....

Kind regards

[Ghandi]

You're taking this all a little too personally Eddy. The fact of the matter remains that people use RSA in the hope that it will be offering security. Yes, for the average Joe Bloggs, even a 512 bit key *seems* to be safe enough. You could argue the same point about a simple XOR/ADD/SUB/ROL/ROR encryption, even a substitution cipher, using the age old mistake of security through obscurity, because who would want my data? But to make a decision to use such an encryption scheme based on incorrect and outdated information is plain folly. If we were talking strength and keysize, i'd much rather use ECC and a symmetric key system such as Rijndael or Camellia.

The other point you argue is incorrect also, regardless of whether the NSA would be interested in my data. They have and will continue to build rainbow tables for lookup, not for any one single case, but to increase their capabilities. So, while i agree that no, the NSA wont be spending millions of dollars to crack my data, they will spend that money as a matter of course in a years expenditure doing what they do: Trying to keep American information secret and trying to break any encryption which draws their interest.

There is no need to go puffing your chest out and beating your fists against it, nobody is criticizing you or your commercial product, merely sharing the facts as they are. As i can see this conversation sinking into a schoolyard fight over a matter which should be able to be discussed objectively, i am now going to take this opportunity to withdraw and leave it to the experts, i am nobody and i know nothing.

HR,
Ghandi

[dedndave]

lol Ghandi
i need an encryptor so i can d/l torrents without my ISP knowing what they are   :bg
i wouldn't want to use any known standard for that
obscurity is the best security

[Eddy]

You're taking this all a little too personally Eddy.

I wasn't aware that I gave that impression. That was not my intention. I just gave my opinion and stated some facts.

even a 512 bit key *seems* to be safe enough.

True, it all depends on the value of the data you are trying to protect. Nobody is going to spend a million dollars to decrypt/crack data that is worth 10 dollars.

You could argue the same point about a simple XOR/ADD/SUB/ROL/ROR encryption,

Well you might want to get maximum security using software that is readily available, so why not go for the best that is available to the general public?

If we were talking strength and keysize, i'd much rather use ECC

Sorry to sound like a know-it-all, but ECC has received a lot less scrutiny than say RSA, so the experts (and I am not one of these) remain cautious about the security of ECC. The main benefit of ECC is that it needs smaller key lengths to provide (what seems like) simular security as RSA. So ECC is mainly used on banc and credit cards. Systems with very little resources and calculation power. On pc's you do not have these limitations, so why not stick with proven technology?
In a few years from now, it might be proven that ECC provides you with the same security as the current public key algos.

and a symmetric key system such as Rijndael or Camellia.

Symmetric key algos (AES/Rijndael) are entirely different beasts than assymmetric key algos (RSA, Diffie-Hellman,..)
They can hardly be compared in key strength.

The other point you argue is incorrect also, regardless of whether the NSA would be interested in my data. They have and will continue to build rainbow tables for lookup, ...to increase their capabilities. the NSA .. will spend that money as a matter of course in a years expenditure doing what they do: Trying to keep American information secret and trying to break any encryption which draws their interest.

Yes, that is true ... So...which part of what I said was incorrect?

There is no need to go puffing your chest out and beating your fists against it, nobody is criticizing you or your commercial product,

Ok. Did I give you the impression that I thought that this was the case ...?  :dazzled: I am sorry if I did.

As i can see this conversation sinking into a schoolyard fight over a matter which should be able to be discussed objectively,

Who is fighting over what? I thought I was merely giving information to Niox regarding his encryption project. This information, I gave to the best of my knowledge and with the best of intentions. Part of that information was indeed to mention that I sell a commercial product that might be of interest to Niox. As far as I know, that is not forbidden on these forums.

i am nobody and i know nothing.

Everybody is someone and everybody knows something. Sorry to contradict you ...  :(

Kind regards

[Ghandi]

I must apologize to all, i let another situation get the better of me and posted while not thinking clearly.

I understand that asymmetric and symmetric encryption are two entirely different beasts, which is why i said about using the two in conjunction with each other. The security of ECC at this point in time can be questioned, but currently it has only been broken in smaller keysizes or due to poor/incorrect implementation. Another reference to the NSA, i know, but:

As for other popular public key cryptosystems, no mathematical proof of difficulty has been published for ECC as of 2009[update]. However, the U.S. National Security Agency has endorsed ECC technology by including it in its Suite B set of recommended algorithms and allows their use for protecting information classified up to top secret with 384-bit keys.

http://en.wikipedia.org/wiki/Elliptic_curve_cryptography

The US Govt is happy with the security of ECC-384 at this moment, i don't think that the technology is that under-researched, those guys are paranoid about who hears them fart, let alone what they're sending each other.

We could go around in circles saying that this or that is/isnt safe, but like most things, mathematics is a constantly evolving field. As this happens, we see old ideals and concepts fall to the wayside and new/more robust methods are developed on both sides of the fence. So, what is seen as secure today may not be tomorrow. It doesnt mean that any method is inherently bad, it just means that if you wish to employ these methods in a secure sense, that you need to keep up to date with current technology.

dedndave, i agree that while it remains obscure, it is secure. But it only takes once for it to be broken and then its a known factor and the security is gone. Having said this, unless you are drawing the interest of individuals or organizations who make it their business to pull it apart, a simple home rolled encryption is just as safe as RSA-4096 for the purposes you mentioned. :)

Once again, sorry for my rant, i'll get off my soapbox and allow the more knowledgable of the forum discuss these matters. You didnt make feel like anything, i said that i am nobody and that i know nothing because that is honestly how i feel about myself when i see the knowledge and skill present on this board.

Peace,
Ghandi

[vanjast]

I think the book's title was 'Ultra', on how they broke the Japanese maritime/navy codes in WW2, using tables as mentioned

The interesting thing was that they didn't have to crack every piece of info, and could fill in the missing spaces from educated guesses.
The same applies to crypto algorithms.. With enough computing power.. and a determined 'decrypter'.. it certainly will not take long.

:bg

[dedndave]

i saw an interesting documentary on the Brits cracking the German u-boat codes
Alan Turing used what amounted to a mechanical computer to break the enigma codes
their "windows" were actually made of glass - lol

[NervGaz]

obscurity is the best security

I hope to god or whatever else supreme being that that was sarcasm. One thing that has been known as a security thruth for
a long time is that security through obscurity is essentially no security. just look at WPA/WGA from microsoft, proprietary algo's
that there was no info on. Both defeated withing weeks.

and as far as implementing your own crypto goes, always a bad plan if you want actual security. When even the pro's manage
to get sidechannel attacks and such in their code, how well would amateurs fare.

Just my 0.2.

[Eddy]

One thing that has been known as a security thruth for a long time is that security through obscurity is essentially no security.

Quite right. I already stated that in one of my previous posts here, so I did not want to repeat myself ...  :bg

[dedndave]

i am not trying to be argumentative, but...
it seems to me that a known method gives a would-be code breaker a starting point, as well as a resource of previous efforts
with an unknown method, they have to start at 0
i wager to say that i could create a code that you could not break in my life-time
if i handed you a few files that looked like garbage data - and gave you only those files and no information about them,
you'd be pulling your hair out trying to figure out where to start   :bg

several years ago, i worked on a project where i combined a compression algo with the encryption
the files looked like random garbage - if you didn't know the (possibly very long) password, you were lost

[Eddy]

>i wager to say that i could create a code that you could not break in my life-time
--- I believe you. I will not be able to decipher your code without knowing the key or the algorithm. But.. I am not a cryptographer. An experienced cryptographer, with the proper tools, could (no, WILL) break your code in a few minutes time. Atleast, if you are not a cryptographer also.

Developing secure encryption algorithms is a very specialised business, for experts only.
If you are a programmer but not a cryptographer, you will be able to write software to turn plaintext into gibberish that I, or any other common programmer will never be able to decipher.
But again, most cryptographers will be able to decipher your code, assuming they would be interested to do so.

You can compare it with a lock on the door of your house. If you lock your door, a common person will not be able to open that door if he does not have the key.
A burglar on the other hand, with the proper tools and knowledge, will be able to break into your house.
This would be the case, even if you would invent and install a new type of lock of your own.

Keep this in mind: Inventing encryption algorithms can be fun, but for 'real' security, use a common and proven 'industrial strength' encryption algorithm.

Kind regards