Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 08 Aug 2000
Offline Last Active Today, 02:59 PM

#5226486 Random Number Generation

Posted by BitMaster on 30 April 2015 - 06:05 AM

[...] And you should shoot the other guy because you can't trust him to keep the secret.

I'm not an expert in the area but that feels to me like the wrong way to go about it. In a lot of places of the world (especially those where an actual terror attack would really be noticed) just shooting someone is bound to cause at least a little bit of investigation. Shouldn't your priority be to make it look like a plausible just-an-accident-scenario?

#5226471 Random Number Generation

Posted by BitMaster on 30 April 2015 - 04:29 AM

Well, he wants to get some data from A to B through a hostile environment. Standard internet public key cryptography is obviously one way to go. But he can also send it 'in the clear' but pre-encrypted with a symmetric block cypher. Personally I would favor symmetric block ciphers because I know a bit more about their strength than and attack feasibility than public key cryptography. Symmetric ciphers are also closer to the one-time-pad he originally targeted (well, 'still targets' although by now it's pretty clear they are an added complication without adding anything).

#5226438 Random Number Generation

Posted by BitMaster on 30 April 2015 - 12:55 AM

I have problems with that argument, mhagain. I'd personally consider it reasonable to require encrypted data to remain so in the foreseeable future (say, an expected human lifetime), not just the point of transmission. However, quoting the AES Wikipedia article:

The first key-recovery attacks on full AES were due to Andrey Bogdanov, Dmitry Khovratovich, and Christian Rechberger, and were published in 2011.[27] The attack is a biclique attack and is faster than brute force by a factor of about four. It requires 2^126.1 operations to recover an AES-128 key. For AES-192 and AES-256, 2^189.7 and 2^254.4 operations are needed, respectively. This is a very small gain, as a 126-bit key (instead of 128-bits) would still take billions of years. Also, the authors calculate the best attack using their technique on AES with a 128 bit key requires storing 2^88 bits of data. That works out to about 38 trillion terabytes of data, which is more than all the data stored on all the computers on the planet. As such this is a theoretical attack that has no practical implication on AES security.

I'd believe for myself to be on the safe side, especially when picking the largest possible key size for the cipher instead of the common size and using several different ciphers with independent keys in a cascade.
Unless of course the singularity happens. But then all bets are off anyway, including whether corresponding changes in society would still maintain the desire to keep the data hidden.

#5226338 Random Number Generation

Posted by BitMaster on 29 April 2015 - 02:00 PM

P.S.:  Lactose!, that doesn't really apply here, because I don't think it's a gut assumption that processing power increases over time (or even exponentially for that matter), or that theoretically it will eventually become much quicker to crack keys (because c is O(a^x)).  I just didn't have the specific numbers, that's all.

And now samoth gave you specific numbers. I haven't done the work myself but they look reasonable (after all, that looks a lot like the usual lecture cryptographers give people when they are confronted with fears like yours). You could have tried to objectively challenge them somehow but instead you continue to go by gut feeling instead of facts.

Remember what I said back in #44? You just moved a whole lot closer to the problem people I described.

#5226322 Random Number Generation

Posted by BitMaster on 29 April 2015 - 01:25 PM

I'll be quite blunt. The only "legitimate", and I use that word VERY loosely!, use for such an extreme encryption method is to prevent forensic snooping. In other words, the data you are trying to hide is illegal. Nothing else makes sense.

I wouldn't go that far. There are at least indications that parts of the intelligence community consider snooping on everyone about everything without any reason to be a done deal. Now, I'm an engineer with an engineer mindset. If someone tells me (or does not tell me but I have reason to believe they do regardless of what they tell me) they are going to snoop on me, the first thing I think about is "how can I stop that, or, failing that, make your life as difficult as possible". This has nothing to do with me trying to explicitly hide something dangerous, it just comes with the job.

However, another engineer trait (especially software engineers) is laziness. And I'm not going to invest work into something blindly (well, unless I want to learn about stuff in the process without considering the result). As Álvaro correctly pointed out in the meantime, myvraccount does not really need the one-time-pad. It's an added complication. I have to get a lot of random numbers. I have to store them (on two fricking ends). I have to properly get rid of them when I'm done.

The only point where a one-time-pad could be useful is if I meet someone in person and know I want to securely transmit information later (much later, when we are no longer in meeting range). Then a OTP could have an actual use. I probably would not use it though. Getting a good pad would be difficult and storing it on two ends in a way that makes it accessible to me when I need it and completely destroying it when I'm done would be a huge hazzle. All my knowledge of cryptography suggest I can get the same effect (or better) by using the more common methods. Keeping a few keys securely stored is a much easier job than megabytes or gigabytes of data.

#5226283 Random Number Generation

Posted by BitMaster on 29 April 2015 - 10:20 AM

I have every right to express my opinions!)

Yes, you do. However, that goes both ways. Others have the right to disagree with your opinion. They also have the right to tell you that on this public space, whether it's by downvoting or posting in threads.

Also, since this thread already contains two xkcd references let's add a third just to continue the roll.

#5226141 Random Number Generation

Posted by BitMaster on 28 April 2015 - 01:54 PM

For some reason this comes to mind.

#5226081 Random Number Generation

Posted by BitMaster on 28 April 2015 - 09:12 AM

How can it be cryptographically secure if iy's only pseudo-random?  That doesn't sound secure at all!

According to the corresponding Wikipedia article a key property would be fulfilling the next-bit test, that is "given the first k bits of a random sequence, there is no polynomial-time algorithm that can predict the (k+1)th bit with probability of success better than 50%". That sounds pretty reasonable to me as a computer scientist without a specialization in cryptography.

Edit: Ninjaed...

#5226073 Why isn't this working (c++ templates)?

Posted by BitMaster on 28 April 2015 - 08:52 AM

Are you using a compiler which actually supports 'using' as a more capable typedef replacement? I'm not sure about the newer versions, but I know MSVC 2012 can't do it for example.

Edit: You also should get into the habit of pasting the complete errors. You only mentioned one error and not even with the complete error text.

#5225833 Basic C program what am I doing wrong?

Posted by BitMaster on 27 April 2015 - 07:32 AM

You really should be using [ code ]-tags, it's pretty much unreadable like that. Couple of thoughts:
  • the outmost for-loop will only run once
  • if p is an int, you cannot just call it as a function: 'v=p(1+r);'
Apart from that it would help to describe the actual problem. Does it compile (probably not)? Does it produce the wrong values? What do you expect at all? What do you get instead?

#5225770 Window Structure Using Classes

Posted by BitMaster on 27 April 2015 - 12:49 AM

I had a very quick look at it and would like to add a few comments.
  • using namespace std in a public header is a horrible thing to do, especially if you don't seem to need it.
  • 'void' as the single function parameter is pointless in C++. Whenever I read that I cannot help but think 'does not really know what they are doing'
  • you limit yourself to exactly one possible window instance by trying to do a quasi-singleton pointer. I say quasi because it's not really doing it's job: it's limiting you like a singleton but does not enforce anything and it is broken to begin with (a static variable does not really do what you need here). Store the this pointer with the Win32 window, there are API functions to solve exactly that problem
All in all I'm getting the impression you are still very much a beginner. I can understand the desire to teach others but I would suggest you hold off on that. If you keep working with that for a year or two you will see for yourself why it is a bad idea and how much you did not really understand at this point in time.

#5225501 How to use a unique_ptr as a member variable?

Posted by BitMaster on 25 April 2015 - 01:03 PM

You do not really need std::make_unqiue in most scenarios, although it can make code slightly less verbose. Your usage of std::unique_ptr is not wrong but unnecessary complex. This works just as well:
frame_data::frame_data(unsigned long width,unsigned long height) : _height(height), _width(width)
   _data.reset(new unsigned char(width * height * 4));
or even better by using the initializer list:
frame_data::frame_data(unsigned long width,unsigned long height) 
   :_height(height),_width(width),_data(new unsigned char(width * height * 4)
You should however declare the unique_ptr as
std::unique_ptr<unsigned char[]> _data;
because like this the unique_ptr uses 'delete' instead of 'delete[]' as it should. That's not a problem on MSVC but can and will cause problems with other compilers. You do not need an empty destructor at all. As a matter of fact I would call it bad style to add an empty, pointless destructor like that. The compiler will generate one (including the destruction of _data) with or without.

#5224985 2D (Texture) Allocator

Posted by BitMaster on 23 April 2015 - 02:45 AM

I had to deal a similar problem a while ago and after a while noticed that I found a lot of people talking about it on sites like stackoverflow and there was always this link and/or this corresponding document referenced. It certainly solved my problem back then and although I don't have much experience in the area someone who had been dealing with different bin packers in the past commented the results certainly look much nicer.

#5224486 Write ToLower As Efficient, Portable As Possible

Posted by BitMaster on 20 April 2015 - 08:04 AM

As a native German speaker living in Germany, I'd like to say that I have never heard of that before. Note that the Wikipedia article calls it 'contestable' right in the first line and makes clear it's far from accepted in the rest of the article as well.

#5222438 Helps! Errors In glGetAttribLocationARB

Posted by BitMaster on 10 April 2015 - 10:09 AM

He wants to get the attribute location of the attribute 'normal' and he got an unexpected return value (for him). He did everything correctly except not realizing that unused attributes will be removed by the driver, resulting in the invalid location index.