Hey people
Im new here and thrilled to be here. I've been programming assembly for a year or so, mostly small projects. And now im doing yet another little project.
Since my latest project is a small PE that needs to communicate small chunks of data securely to my server, my solution is to base the encryption on the RSA public key algo (no way around using a public/private key algo).
Since my server will hold the pre generated private key and that server uses an existing RSA implementation, all i really need to have working in masm is encryption using the public key (so that encryption with the public key happens on the client side and the decryption of with the private key happens on the server side.).
The PE written in masm should be as portable as possible and of course the faster i can get this working the better.
So my question is; should i implement this RSA encryption myself? Or should i use the CryptoAPI (Crypt32.dll) in Windows?
I usually prefer implementing the stuff myself, but from my research so far it seems that this will be taking a while, since i have no experience handling big numbers in masm. But maybe i'm wrong?
How much time could i save using the CryptoAPI? And how much portability would i loose using CryptoAPI?
Also whatever documents or guides you could point me at related either of the solutions would be appreciated.
Hope you got some advice for me :)
Best regards
Niox
Do it yourself :wink
It is not advisable to create your own encryption standards unless you have a lot of experience. It might not necessarily be hard. But to create a secure one will require a lot more effort and expertise. If you intend your application only to be used on Windows then I would advise CryptoAPI. However if you also intend for your app to be portable to *nix you'll have to consider other options
Hi Niox,
I develop and sell a crypto library, called HIME. It is not free but you can use it for free for testing purposes. The only limitation it then has is that it has a nagscreen that pops up regularly. There is no time limit for using it with the nagscreen. The library comes as a standard Windows 32 bits dll (so it is Windows-only).
http://www.devotechs.com/HIMEMain.html .
That said. According to me, your main concern with this project will very likely have to do with "your server using an existing RSA implementation".
If you use one RSA application on your server, and another one on your client, that is very likely going to cause you some headache figuring out how to let these two formats match.
Unless you wrote the server encryption yourself and know every detail about the key and data padding and formats.
You see, before encrypting data with RSA, the data is (or should be) padded; that is: extra data is added to your plaintext data before it is encrypted.
After decrypting, the padded bytes must be removed. In order to do that, you must know exactly the format of the data.
Also, RSA ciphertext is binary data. To send over the internet, that must be converted to ascii data, using formats like Base64 etc.
If you use the same cryptosystem on both client and server, you are spared from handling all this padding and formatting stuff because encryption and decryption then have complementary functions to handle this for you. In other words: in this case you could limit yourself to using high-level crypto functions. Whereas when using two different crypto systems, very likely you need to get your hands dirty handling some low-level formatting and byte filtering stuff.
Just something to consider.
Kind regards
Hey guys thx for your answers
Slugsnack: Good point but im not creating my own encryption standard, just using the aldready existing RSA. I would think that i could implement it safely with some research. Even though its been a while, I do have some experience with cryptography although im nothing near an expert.
Eddy:
Very good point with the padding. But maybe i could get around this issue simply by encrypting for instance a 1024bit message with a 1024bit RSA key (1024 bit module number)?
Luckily i can easily modify the server implementation if this isn't the case.
Actually i already implemented a Base64 encoding routine in masm a while ago for the purpose as you suggest. However since then i realized it would be much easier and simpler just to make my own simple protocol that isn't restricted by ascii chars for this purpose. Of course there are some extra security considerations in doing that ..
You HIME library looks really nice. It might be overkill for this little project i will concider using it for testing as you suggest. :)
Kind regards
Niox
Quote from: niox on January 06, 2010, 08:26:08 PM
Very good point with the padding. But maybe i could get around this issue simply by encrypting for instance a 1024bit message with a 1024bit RSA key (1024 bit module number)?
For anyone interested. This isn't possible if the padding specified in PKCS (#1) is used, which it is in many implementations of RSA. It seems likely to work with other padding schemes though.
>by encrypting for instance a 1024bit message with a 1024bit RSA key (1024 bit module number)?
--- Yes, that is basically 'padding' what you are doing then.
One vital thing that you should consider when padding your plaintext upto the modulus length is this:
The padded plaintext must always be of smaller value than the modulus! Otherwise, decryption will fail!
In practice, you could do it like this. If the key generation function of your crypto package is good, the generated modulus (in case of a 1024 bit key strength) will have 1024 significant bits. By this I mean that the most significant bit of the modulus will be 1.
You can make sure that your padded plaintext is smaller than this modulus by adding bytes on the most significant side of the plaintext. Then, make the most significant bit of the padded plaintext zero. Now, the padded plaintext is smaller than the modulus.
To make sure, you can make the two most significant bits zero, or mathematically compare padded plaintext and modulus.
Is your plaintext always (considerably) smaller than the modulus length?
Because, (as you probably know) if the plaintext is large, public key encryption becomes very slow. In that case, you better use a different approach, using a combination of public key encryption (RSA) and secret key encryption (AES/Rijndael).
>Luckily i can easily modify the server implementation if this isn't the case.
---- That is definitely a benefit.
>You HIME library ... might be overkill for this little project i will concider using it for testing as you suggest. :)
---- It is a toolkit with lots of functions related to data security (it also has bignum math functions), and it might be overkill if you only need a few functions of it or if it is not for a commercial application.
But you can use it for free without any time limit.
Kind regards
Eddy
Quote from: niox on January 06, 2010, 10:27:17 PM
Quote from: niox on January 06, 2010, 08:26:08 PM
Very good point with the padding. But maybe i could get around this issue simply by encrypting for instance a 1024bit message with a 1024bit RSA key (1024 bit module number)?
For anyone interested. This isn't possible if the padding specified in PKCS (#1) is used, which it is in many implementations of RSA. It seems likely to work with other padding schemes though.
---- Yes, your unpadded plaintext length must always be atleast one byte smaller than the modulus length. Otherwise, you cannot pad it.
Quote from: Eddy on January 06, 2010, 10:33:26 PM
One vital thing that you should consider when padding your plaintext upto the modulus length is this:
The padded plaintext must always be of smaller value than the modulus! Otherwise, decryption will fail!
In practice, you could do it like this. If the key generation function of your crypto package is good, the generated modulus (in case of a 1024 bit key strength) will have 1024 significant bits. By this I mean that the most significant bit of the modulus will be 1.
Ouh yeah ok! So lets say the modulo had 0 on the most significant bit and 1 on the second most significant bit. That would in effect mean a 1023 bit encryption?
Was just checking and luckily my key does have all of the bits being significant, so at least this key will be fine for padded messages of 1024.
Quote from: Eddy on January 06, 2010, 10:33:26 PM
Is your plaintext always (considerably) smaller than the modulus length?
Because, (as you probably know) if the plaintext is large, public key encryption becomes very slow. In that case, you better use a different approach, using a combination of public key encryption (RSA) and secret key encryption (AES/Rijndael).
Yeah I'm only using RSA to transmit the key for a symmetric encryption algo.. I was planning on looking into something like TEA for that purpose, since its easy to implement. I haven't gotten to research the security of TEA, do you have any experience with this algo? This project is still just a hobby project so no need to have extremely good security but still i would like to know.
Thx for all your help so far :)
Niox
Quote from: niox on January 07, 2010, 07:43:30 PM
So lets say the modulo had 0 on the most significant bit and 1 on the second most significant bit. That would in effect mean a 1023 bit encryption?
Correct!
QuoteWas just checking and luckily my key does have all of the bits being significant, so at least this key will be fine for padded messages of 1024.
A (good) public key generation routine makes sure that this is the case.
QuoteYeah I'm only using RSA to transmit the key for a symmetric encryption algo..
That's the way to go, yes. Just make sure to generate a new (pseudo)random key for every new message.
Quote...TEA, do you have any experience with this algo?
I once planned to integrate it into HIME, because the algo itself is simple and I expected it to be fast. But I did some research on it (back then) and the experts seemed to be in agreement that TEA was/is not terribly secure. I seem to remember that there where two versons of it at the time (about 4 years ago).
For symmetric key encryption I would recommend AES/Rijndael (or any other block cipher: TwoFish, BlowFish, CAST, Serpent,...) or even ARC4/RC4. RC4 is fast and still good to use,
provided it is correctly used.
Kind regards
The problem with the available crypto code is that it's probably been cracked already, which renders it useless if attacked by determined 'hackers', or the FED
Besides being a great educational exercise, if you create your own, your encrypted stuff stays secret for longer.
There's lots of nice juicy educational material out there and it's a good idea to move into the DSP area of encryption.
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 - Remember PGP, they lay claim to your hard work.
:bg
Just on RSA, did anybody else see that RSA-768 was broken?
http://arstechnica.com/security/news/2010/01/768-bit-rsa-cracked-1024-bit-safe-for-now.ars?utm_source=rss&utm_medium=rss&utm_campaign=rss
HR,
Ghandi
Quote from: Eddy on January 07, 2010, 08:27:20 PM
QuoteYeah I'm only using RSA to transmit the key for a symmetric encryption algo..
That's the way to go, yes. Just make sure to generate a new (pseudo)random key for every new message.
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?
Quote from: Eddy on January 07, 2010, 08:27:20 PM
I once planned to integrate it into HIME, because the algo itself is simple and I expected it to be fast. But I did some research on it (back then) and the experts seemed to be in agreement that TEA was/is not terribly secure. I seem to remember that there where two versons of it at the time (about 4 years ago).
For symmetric key encryption I would recommend AES/Rijndael (or any other block cipher: TwoFish, BlowFish, CAST, Serpent,...) or even ARC4/RC4. RC4 is fast and still good to use, provided it is correctly used.
Oh i see, well 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?
Best regards
Niox
Quote from: vanjast on January 08, 2010, 05:02:05 PM
The problem with the available crypto code is that it's probably been cracked already, which renders it useless if attacked by determined 'hackers', or the FED
.... if you create your own, your encrypted stuff stays secret for longer.
--- Not quite. This is a common laymans misconception.
The benefit of using generally accepted crypto algorithms (such as RC4, AES/Rijndael, DES3, etc.) is that they are designed by real cryptographers (experts in their field of work) and that the algorithms receive a lot of scrutiny. Meaning, that every Crypto Tom, Crypto Dick and Crypto Harry is trying to 'break' it, trying to get their names in the papers. You can rest assured that if AES or any other generally accepted crypto algo was actually 'broken', it would be headline news (See the news today about 768 bit RSA). If no such news is published, that means that these algos are still secure.
Creating your own crypto algorithm is fun, by all means. I once did it too. It is easy to write an algorithm that turns readable text into gibberisch characters. Such algorithms are perfect for preventing your kid sister from reading your 'personal' mail messages. However, it will take expert crytographers about 3 minutes max to decrypt your 'cipher text' back into plaintext. Especially with the tools that these people have.
Cryptography is a very specialised field of expertise. Especially designing encryption algorithms is not for the faint of heart, atleast if you want to be taken seriously.
Quoteif you create your own, your encrypted stuff stays secret for longer.
----
Particularly this sentence is a big 'no no!' in cryptography!
It is in fact the
opposite! If you rely on the secrecy of your algorithm for your data to be secure, it will only be a matter of time before someone reverse engineers your code and will unravel your algorithm, rendering it useless.
In encryption, the rule is this: for a secure encryption algorithm, the security lies only (!) in the key, not in the algorithm. Because the algo will be unraveled sooner or later.
That's why, in the recent years, any encryption algo that wants to be taken seriously has its source code published for scrutiny.
QuoteRemember PGP, .
Yep, Paul Zimmerman fought hard to provide us good citizens with solid crypto software. :U
Kind regards
Quote from: Ghandi on January 08, 2010, 06:01:14 PM
Just on RSA, did anybody else see that RSA-768 was broken?
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.
For us layman, if we hear that an algorithm is 'broken' we tend to think that all of our data, encrypted with that algorithm, can be read by an attacker without any effort, and especially without knowing the key.
That is totally not so.
You must know that you can decrypt ciphertext by brute-forcing it. That is, you can 'simply' try every possible key for that algo and see if any key decrypts the ciphertext into readable text.
For example, if you were to invent an encrypton algo that allows the use of 100 possible different keys, an attacker would only have to try to decrypt your ciphertext with all of the 100 possible keys.
One of the 100 possible keys would decrypt your ciphertext into readable text. That is brute-forcing an encryption algo.
The strength of todays common encryption algos lies in the fact that they have an enormous amount of possible keys.
For example, AES-256 (from the hand of my fellow countrymen Joan Daemen and Vincent Rijmen) has 2^256 possible keys. That is: 115792089237316195423570985008687907853269984665640564039457584007913129639936 keys. :bg
Brute-forcing that would take an enormous amount of time, even with a giant cluster of todays computers, so it is considered unfeasable.
Of course, with increasing performance of computers, that time will decrease in the future, requiring the need of stronger keys or stronger algos.
Now, back to an algorithm being considered 'broken'.
If it is published that an algo is 'broken' it means that a team of specialists has found a way of decrypting ciphertext back into plaintext with an effort (slightly) less than the effort required to brute-force it.... And sometimes there are even some special requirements that the plaintext/ciphertext needs to fullfil.
What does it mean in practice? Say that RSA 768 bits takes 1500 years on one pc to brute force it. If cryptographers find a way so that it only takes them 1499 years to decipher the ciphertext, they consider the algo broken .... No more, no less.
Do you now need to worry if your sensible data is encrypted with RSA 768 bits? Not very likely. The signal this should give you is that you should consider encrypting your data in the near future with a stronger key. That's all...
Kind regards
Quote from: niox on January 08, 2010, 07:23:24 PM
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!
Quotemaybe 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
Quote from: Eddy on January 08, 2010, 09:35:47 PM
Quote from: niox on January 08, 2010, 07:23:24 PM
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!
Quotemaybe 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
Quote
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
Quotewhat'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.
Quote from: vanjast on January 08, 2010, 05:02:05 PM
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
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
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
QuoteYou'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.
Quoteeven 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.
QuoteYou 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?
Quote
If we were talking strength and keysize, i'd much rather use ECC
Quote
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.
Quoteand 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.
QuoteThe 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?
QuoteThere 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.
QuoteAs 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.
Quotei am nobody and i know nothing.
Everybody is someone and everybody knows something. Sorry to contradict you ... :(
Kind regards
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:
Quote
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
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
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
Quote from: dedndave on January 09, 2010, 01:36:47 AM
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.
Quote from: NervGaz on January 10, 2010, 12:17:46 PM
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
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
>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
Quote from: Eddy on January 10, 2010, 09:47:27 PM
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.
We have imaginative burglars down here...
No Key = Throw brick through window - walk in.
No Key = Climb through roof and ceiling.
:wink
Quote from: vanjast on January 11, 2010, 08:21:01 PM
No Key = Throw brick through window - walk in.
That probably could be considered as brute-forcing ... :bg
Quote from: Eddy on January 10, 2010, 09:47:27 PM
>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.
I think you have too much confidence in cryptographers and their tools. What if Dave used a one-time pad, or used some simple algorithm but started out with random garbage?
Quote from: MichaelW on January 12, 2010, 11:44:10 AM
I think you have too much confidence in cryptographers and their tools.
Well, if the FBI comes to get you, don't say that I haven't warned you ... :bg
Quote from: MichaelW on January 12, 2010, 11:44:10 AM
What if Dave used a one-time pad,
A one-time pad (XOR'ing plaintext with random data) is the only unbreakable encryption method.
Unfortunately, it has a few drawbacks and is therefore not very practical:
- True random data is hard to come by. You could attach a radio receiver to your pc and convert the noise to random data, but even then. A practical way to produce pseudo-random data that is cryptographically secure is the Blum-Blum-Shub PRNG. If you want to experiment with that, download HIME.zip here ( http://www.devotechs.com/HIMEDownloads.html ) and run HIMETestbench.exe.
- You need as much random data as there is plaintext (you need as much random bytes as there are plaintext bytes). The random data serves as the key.
- The same random data (key) may only be used once!
- Both sender and recipient must have the same random data. So they are practically obligated to meet in person to exchange the data (CD, DVD,..).
The Russians used one-time pad during the cold war. To produce 'random data', they had Russian women type 'random characters' on typewriters all day long. At the peek of the cold war, the Russians needed so much of random data to encrypt their messages that the typists could not keep up. That's why they started re-using their random data. And that's why the Americans could decipher some of the Russians code.
Quote from: MichaelW on January 12, 2010, 11:44:10 AM
or used some simple algorithm but started out with random garbage?
Not sure what you mean. You mean using a one-time pad but with
pseudo-random data instead of
true random data?
i am not a cryptographer, Eddy :P
i have always enjoyed math, though
i could give them a run for their money - lol
QuoteNot sure what you mean.
I mean start out with a plaintext that is random garbage. Even if they managed to decrypt it, how would they know they had succeeded? How would they know that they were not dealing with a meaningful message encrypted with an unknown algorithm?
lol Michael
you gave me away
i was going to take three files of pseudo-random garbage and call it "encrypted data" - lol
if they decrypt into something that resembles a picture of a naked lady, they need to get away from the computer a little more often :bg
Quote from: MichaelW on January 12, 2010, 04:13:03 PM
I mean start out with a plaintext that is random garbage.
In that case, 'they' would not be able to do anything with it. How could they :P
But then again, it would be a pretty useless exercise for you too, wouldn't it? :bg
No, in order to have a chance to decrypt ciphertext without having the key,
a lot of ciphertext messages are necessary, so these can be analysed and to discover a pattern.
Quote from: Eddy on January 12, 2010, 12:14:43 PM
A practical way to produce pseudo-random data that is cryptographically secure is the Blum-Blum-Shub PRNG.
For a second or so, I thought you were pulling our legs. Blum-Blum-Shub sounds like, ehm, music :wink
But I learnt that Blum Blum Shub (B.B.S.) is a pseudorandom number generator proposed in 1986 by Lenore Blum, Manuel Blum and Michael Shub (Blum et al., 1986). (http://en.wikipedia.org/wiki/Blum_Blum_Shub)
For a quick-and-dirty OTP: How unsafe would it be to use an
invoke Sleep, 0 loop, and to extract from the 64 bits of a QPC the least significant 8 bits? Jumping from interrupt to interrupt should generate so much uncertainty that patterns are unlikely to appear... but I admit I am pretty ignorant on encryption, so apologies if what I write is stupid. I am just curious :bg
I swear by my monkey with a typewriter
ummm - they need a way to recreate the key at the receiving end
unless they bought their monkey at the same pet-shop you did, it won't be easy :bg
blum-blum-shub - i as gonna say a dance, Jochen - lol
Quote from: jj2007 on January 12, 2010, 04:28:20 PM
How unsafe would it be to use an invoke Sleep, 0 loop,....
To get an impression of just how 'random' your generated data is, you can use following software:
- ENT ( http://www.fourmilab.ch/random/ )
- George Marsaglia's Diehard Battery of Tests ( http://www.stat.fsu.edu/pub/diehard/ , download under "Windows Software")
Both programs (or suites) need a sufficiently large file (around 10 MB) with your random data. They run a series of tests on the data. The produced output gives you an impression of the degree of randomness of the input data.
Note that the output will not be a 'yes/no' answer. You need to interprete the figures that are produced.
You could be surprised of how difficult it can be to have a computer produce 'good enough' random data.
Here's a good PRNG: http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html. It has a period of (2^19937-1).
So, it is not
cryptographically secure as is Blum-Blum-Shub.
Heh, didn't exactly mean to cause an argument, but hey it's all fun. Can't remember who said it, but it think it was Bruce Schneier,
but the quote is something along the lines of "There is is no such thing as unbeakabkle crypto, just a question of time and computing power.".
admittedly some stuff would require more time than what is left in the sun, but I'm in no hurry. >;)
That was me.. I've just said that... well not exactly the same words :U
:green2 :bg
Quote from: NervGaz on January 13, 2010, 06:15:56 PM
but it think it was Bruce Schneier,.. "There is is no such thing as unbeakabkle crypto, just a question of time and computing power.".
Another quote of Bruce Schneier:
Quote"One-time pads are the only provably secure cryptosystem we know of.
It's also pretty much useless."
:bg
Read Schneiers full article here: http://www.schneier.com/crypto-gram-0210.html#7
Quote from: Eddy on January 12, 2010, 07:44:10 PM
You could be surprised of how difficult it can be to have a computer produce 'good enough' random data.
I believe you :toothy
Some years ago somebody played with the idea of using the 2 seconds delay between a message exchanged between two points on Earth and another one sent from Earth to the Moon and back for safely transmitting an OTP. But I can't remember the details...
Quote from: Ghandi on January 09, 2010, 12:09:20 AM
Quote
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
Absolutely right.
The hard work is done, and now they know every possible key for 768-bit RSA. It is just a matter of trying every key with the ciphertext.
You are ill-advised to continue using it.
Bruce Schneier thinks 1024-bit will be factored within 5-8 years.
Use 4096-bit or longer for serious use. The whole point is for the data to be worthless/useless at the time it is recovered. If your data is OK to be exposed in 5 years time, then 1024-bit will be fine, otherwise you need something stronger. It is also recommended to build in a bit of "extra time" into the life of your keys anyway to allow for progress in the field.
All of the above assumes there is no faster way to factor primes than is currently known (not including more/faster computers).
Best regards,
Robin.
Back to the original topic:
See rsa.cpp from the library!
http://www.cryptopp.com/
Quoteif you create your own, your encrypted stuff stays secret for longer.
Not true, unless you really do hit on The Next Big Thing.
Eddys site worries me a bit - he states on one of his pages that you can "access an internet server for truely random data".
1) Who owns the server?
2) What is the source of the "truely random" data?
3) Isn't the 'net insecure, and thus no good for obtaining key material?
Crypto systems security always collapses to the strength of the weakest link, and I certainly wouldn't be trusting the result of some unknown server.
Fact: nearly all crypto systems are "broken" via some problem with the random number generator. To have a true break requires the algorithm itself to be flawed.
Best regards,
Robin.
Quote
1) Who owns the server?
2) What is the source of the "truely random" data?
Hi Robin,
The site that this particular HIME function retrieves the random data from is http://www.random.org/. You can find the answer to your questions there.
Quote
3) Isn't the 'net insecure, and thus no good for obtaining key material?
Very true. That's why I specifically state in the HIME help file:
QuoteSince the random data is retrieved over an insecure channel, it is not a good idea to use the data as-is for a session key or a password. You should use some kind of scrambling algorithm before using it for security purposes.
Random data retrieved from that server should not be directly used for security purposes. It can be useful for experiments though.
For generating key material, I recommend using the HIME Blum-Blum-Shub PRNG or the RSA PRNG.
Quote
Fact: nearly all crypto systems are "broken" via some problem with the random number generator.
That's why I always suggest using the Blum-Blum-Shub PRNG. That is probably the best software PRNG around. If you need better, you'll have to use a hardware RNG.
Kind regards
I've working in research most of my life. Iin the late 70's I read a paper by two researchers, who were doing prime number research, and cracked RSA 512. That was almost 35 years ago, who knows where the NSA is now. So RSA would not be my choice.
Don,
Yes, the NSA could crack 'xxx-bits' RSA if they want to. But this would require a lot of computing capacity. Computing capacity they have a shortage of.
Nowadays, 2048 or 4096 bits RSA is fairly common. This, even for NSA, requires an enormous amount of calculating power to (try to) decrypt.
So, the question you have to ask yourself is: Is the information that I want to encrypt potentially SO valuable to the NSA that they want to spend a large piece of their computing capacity trying to decrypt it ..?
Also, you can make it a lot harder for them, if you encrypt two (or more) times in a row. That way, the plaintext of the last encryption is not readable text but ciphertext of the previous encryption round. So, how do 'they' know if they have decrypted your (outer) ciphertext correctly..?
Oops ... hope this 'tip' doesn't get me blacklisted with NSA ... :eek :bg
Kind regards
Eddy
Use TLS (Transport Layer Security) - this is what it's designed for.
Don't make the mistake of assuming your own implementation and/or algorithm will somehow be more secure - it won't.
RSA is believed to be secure based on the difficulty of factoring integers, and that no-one (publicly) knows of any better way to do it. (There are various shortcuts based on certain forms of numbers, but in general it's a difficult problem.) So, while you could fill a room with terabyte drives and fill them with 'rainbow tables,' it quickly becomes pointless. You get to a point where the mass of your storage array has so much mass that it collapses into a black-hole.
Here's an interesting page
http://www.kremlinencrypt.com/algorithms.htm