Forgot your password?
typodupeerror

Comment: Re:Not realistic indeed. (Score 1) 151

by maevius (#47473299) Attached to: LibreSSL PRNG Vulnerability Patched

From the disclosure:

The difference is that OpenSSL provides a way to explicitly reseed the PRNG by calling RAND_poll. LibreSSL, unfortunately, has turned RAND_poll into a no-op (lines 77-81). fork_rand calls RAND_poll after forking, as do all my OpenSSL-using programs in production, which is why fork_rand is safe under OpenSSL but not LibreSSL.

Just sayin'....

Comment: Re:This is not how you inspire confidence (Score 1) 151

by maevius (#47473021) Attached to: LibreSSL PRNG Vulnerability Patched

Exactly!

The disclosure is very well written, says exactly why this is a big problem and proposes a very implementable solution that would fix it. Nevertheless, the dev decided to try to dismiss the disclosure, called his daddy (de Raadt) and they both threw a tantrum, and fixed it in a way that is questionable (an update on the disclosure raises some good questions on why it is questionable)

Btw, forgetting about ssl for a minute (open/libressl are crypto libraries, not ssl libraries), a PRNG is either secure or it is not. There is no "kinda" secure in most user scenarios etc.

Comment: Re:Late on all fronts (Score 1) 210

by maevius (#46885201) Attached to: Target Moves To Chip and Pin Cards To Boost Security

the PIN vs signature subject (the cardholder verification methods) has more to do with who pays when the fraud happens. Signature is by far easier to use, and this is the reason why in europe it is usual for good customers (cards with expensive subscription fees etc.) to get chip and signature and low end cc and debit cards get chip and pin.

To me the problem is not the PIN, but the magstripe itself, which for europe is kept there for legacy reasons (and at this point, yes I am looking at you US...). If the magstripe was completely disabled then there would be no way to skim the card because you would lose one of the 2 required pieces of information (PAN/CVV).

The second problem is that even with the PAN/PIN, the card should be useless but again there are 2 problems.

1. is again legacy reasons. You steal the PAN, write it in a new card, enter the stolen PIN, bob's your uncle. This should not be possible if the cards where full EMV as the card itself is authenticated against Visa/Master PKI.

2. Internet purchases! Now this is a biggie. You don't want to inconvenience anyone so you keep it as easy as possible. No card authentication, no cardholder authentication. Everything goes. To me this problem can be best tackled with one time passwords/tokens generated by a smartcard.

As you understand this is not a technical problem - and I can assure you that the technology exists and it is solid, but an adoption problem and a backwards compatibility problem.

btw: Come on, you can't read Bruce Schneier and at the same time write the PIN on the back of the card. This is like writing your password on a postit and stick it on the screen. Sure, it's annoying but have some standards!

Comment: Re:If I wandered into the bank.. (Score 1) 210

by maevius (#46885031) Attached to: Target Moves To Chip and Pin Cards To Boost Security

I don't have experience with the american market so your mile may vary. Having said that:

The terminals are usually sold by vendors that develop the software too. If a bank decides not to work with the vendor in order to develop the software (as in testing environments, proper specifications etc.) then you simply can't use a specific terminal device (reader if you like) with a specific bank/acquirer. As you understand this has to do more with business matters/politics, but nevertheless it is true.

Now the chip and pin/EMV vs magstripe only, if the bank doesn't support it, it is end of story which the OP mentioned. The specifications/requirements are simply too different.

Comment: Re:Late on all fronts (Score 1) 210

by maevius (#46881931) Attached to: Target Moves To Chip and Pin Cards To Boost Security

Interestingly enough, EMV (c&p) cards work like this. However the card and the cardholder are both authenticated - either PIN or signature.

If someone steals your card, deactivate your card.

Ok, isn't it a bit stupid to design a system that can be circumvented by someone stealing your card? And no card deactivation for sure doesn't solve the problem

Comment: Re:Ah... (Score 1) 217

by maevius (#46658983) Attached to: .NET Native Compilation Preview Released

I program on niche embedded devices which have 16mb of ram and still cost a lot of money for what they are. C is the only way there. However through the development circle we have a lot of bugs which get attributed to improper memory management - null dereferencing, memory leaks and the like. This makes the development circle longer, which is acceptable.

Now on the mobile market, it is an implied that the consumer prefers a lot of relatively stable applications in a short period of time. The tradeoff for this is to pay $20 more (probably much less) for the cost of doubling the RAM.

I think in the end, the problem is talent. Talent is scarce. It needs talent to program in C and it needs talent to design RAM modules. However RAM modules are designed once and then produced in an ultra massive scale. On the other side, every little bit of code needs a developer to work on it. And I know from experience that there isn't enough talent in C to produce the loads and loads of software that is currently produced - and even if there was, it would cost. So in the end I think the way it is, is the only way.

Comment: Re:Ah... (Score 1) 217

by maevius (#46657805) Attached to: .NET Native Compilation Preview Released

I'm known to be a low level person and professionally a C programmer. And I agree with you on some stuff.

However...

No, I won't use C to do something in 1k memory and 3 weeks of coding, I will use python in 10mb memory and 1 day of coding. Simply because my time costs more than 10mb of memory. So stop demonising higher level languages and accept that they have their perfectly legit uses as long as their limitations are undestood. Keep in mind that if android used C and not java, we would have about 5 non crashing apps tops in the market.

Sooo, yeah...

C makes it easy for you to shoot yourself in the foot. C++ makes that harder, but when you do, it blows away your whole leg. -- Bjarne Stroustrup

Working...