Есть ли способ запутать ключи API в пакете R?

Мне нужен потребительский ключ и секрет для пакета R, который я разрабатываю. Для каждого пользователя было бы несколько обременительно применять и получать свои собственные, и на самом деле в этом нет необходимости, поскольку им придется аутентифицироваться с помощью имени пользователя/пароля, чтобы использовать функции пакета. Однако мне не разрешено делиться своими ключами в открытую. Можно ли каким-либо образом скрыть ключ+секрет (или любую информацию в этом отношении) в исходном коде моего пакета, когда он находится в CRAN? Я предполагаю, что ответ - нет, но я хотел бы убедиться, что я не пропускаю другие идеи.

Обновление: единственное злоупотребление, которое я предвижу, — это кто-то извлекает и использует ключи в другом приложении, чтобы максимизировать мои ограничения скорости. Но если бы это было так, то я мог бы просто удалить его. Но могут быть и другие формы злоупотреблений, которые я упускаю. Возможно, я должен просто позволить каждому подать заявку на свое собственное.


r api api-key
person Maiasaura    schedule 29.02.2012    source источник
comment
Определение скрытого. Тогда прочтите о безопасности через неизвестность на сайте schneier.com.   -  person Carl Witthoft    schedule 29.02.2012
comment
Карл только что получил +1. Также подумайте, насколько запутанным может быть что-то, когда исходники бесплатны. Но вы можете сделать что-то еще — например, хешировать MAC-адрес или IP-адрес.   -  person Dirk Eddelbuettel    schedule 29.02.2012
comment
@DirkEddelbuettel Конечно, я знаю, что источники бесплатны, и я обычно доверяю людям, чтобы они не делали ничего злонамеренного, но TOS запрещает мне делать это без разумного запутывания. Если выяснится, что кто-то злоупотребляет ключами, я могу удалить их в другом обновлении.   -  person Maiasaura    schedule 29.02.2012
comment
Но цель этого вопроса заключалась в том, чтобы подтвердить то, что я уже знаю, а также убедиться, что кто-то еще не нашел обходной путь.   -  person Maiasaura    schedule 29.02.2012
comment
При дальнейшем размышлении это все спорно, потому что независимо от того, как они запутаны, мои ключи будут отображаться в объекте OAuth, который необходим для каждой отдельной операции. Если кто-то хочет закрыть его, я согласен с этим.   -  person Maiasaura    schedule 29.02.2012

Ответы (1)


arrow_upward
3
arrow_downward

Что ж, пока вы знаете, что запутывание не является безопасностью, есть несколько простых способов запутывания. Вы не указываете, как хранятся ваши ключи, поэтому я предполагаю, что они хранятся в двоичном виде в файле.

Простейшее запутывание — это xor с некоторым значением — я буду использовать «DEADBEEF» только потому, что это звучит вкусно:

keyFile <- "c:/foo.bin"
obfuscatedKey <- readBin(keyFile, "raw", file.info(keyFile)$size)
key <- xor(obfuscatedKey , as.raw(c(0xde, 0xad, 0xbe, 0xef))) # xor with DEADBEEF

Поскольку xor является симметричным, тот же код можно использовать и для создания obfuscatedKey из исходного ключа.

Другой способ - зашифровать вектор. Используя генератор случайных чисел с «секретным» начальным числом (42), ключ запутывается:

# obfuscate
key <- 101:110
n <- length(key)
set.seed(42, "Mersenne-Twister") # To get the same permutation
perm <- sample.int(n)
obfuscatedKey <- key[perm]

# unobfuscate
orgKey <- integer(n)
set.seed(42, "Mersenne-Twister") # To get the same permutation
perm <- sample.int(n)
orgKey[perm] <- obfuscatedKey

identical(key, orgKey) # TRUE

...и вы, конечно, можете комбинировать оба метода...

person Tommy    schedule 29.02.2012
comment
Я ожидаю, что следующий вопрос OP будет о том, как запутать исходный код R. Мой стандартный ответ на это — использовать ROT-13 дважды. - person Spacedman; 01.03.2012